Re: iozone3-434 fails to rebuild

[Kimmo Paasiala]

On Tue, Jun 21, 2016 at 9:32 PM, Doug Sampson  wrote:
> Trying to rebuild iozone after a recent port upgrade and it crashes as 
> follows:
>
>   ###
> <...snip...>
> iozone.c:1297:1: error: unknown type name 'off64_t'; did you mean 'off_t'?
> off64_t offset = 0;   /*offset for random I/O */
> ^~~
> off_t
> /usr/include/sys/types.h:173:18: note: 'off_t' declared here
> typedef __off_t off_t;  /* file offset */
> ^
> iozone.c:1298:1: error: unknown type name 'off64_t'; did you mean 'off_t'?
> off64_t offset64 = 0;   /*offset for random I/O */
> ^~~
> off_t
> /usr/include/sys/types.h:173:18: note: 'off_t' declared here
> typedef __off_t off_t;  /* file offset */
> ^
> iozone.c:1299:1: error: unknown type name 'off64_t'; did you mean 'off_t'?
> off64_t filebytes64;
> ^~~
> off_t
> /usr/include/sys/types.h:173:18: note: 'off_t' declared here
> typedef __off_t off_t;  /* file offset */
> ^
> fatal error: too many errors emitted, stopping now [-ferror-limit=]
> 2 warnings and 20 errors generated.
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/ports/benchmarks/iozone/work/iozone3_434/src/current
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/benchmarks/iozone
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/benchmarks/iozone
> root@pisces:/usr/ports/benchmarks/iozone#
>###
>
> root@pisces:/usr/ports/benchmarks/iozone# make showconfig
> ===> The following configuration options are available for iozone-3.434:
>  SSH=on: Use ssh in distributed measurement
>  THREADS=on: Enable threading (uses pthreads)
> ===> Use 'make config' to modify these settings
> root@pisces:/usr/ports/benchmarks/iozone#
>
> Doesn't matter which config options I select/deselect, it still fails to 
> rebuild. It occurs on both 10.3-RELEASE-p4 i386 and 10.3-RELEASE-p4 amd64 
> systems.
>
>
> ~Doug
> ___

Same here on 10.3-RELEASE. I wonder how the port got updated with
sponsorship from "Gandi.net", yet the committed changes were
apparently not tested? Shouldn't Gandi.net volunteer as the maintainer
for the port if they want it to be updated (the port is unmaintained
at the moment)?

-Kimmo
___
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: change ports default work directory prefix

[Kimmo Paasiala]

On Fri, Oct 2, 2015 at 10:21 PM, Dirk Engling  wrote:
> Today in EuroBSDCon's jail working group we discussed changing the
> default for WRKDIRPREFIX to /usr/obj/ports. This has the advantage of
> being able to share the ports tree between host system and jails.
> Another plus is that cleaning all work directories is much faster than a
> recursive make clean.
>
> With the current default, exposing the ports tree to jails potentially
> leaks information about installed programs, configured options or host
> specific generated secrets (thinking of LocalSettings.php).
>
> On the down side, developers can't by default just copy the port, hack
> away and be sure to only modify files in their respective home directories.
>
> bapt@ asked me to discuss this here, also looking for potential other
> pitfalls I have not thought about.
>
> Regards,
>
>   erdgeist


What about DISTDIR (/usr/ports/distfiles) and PACKAGES
(/usr/ports/packages)? Those are now kinda stuck under /usr/ports as
well forcing the ports tree to be read-write unless overridden to some
other directories. For the distfiles I've used /var/cache/distfiles
and I think that would follow hier(7) nicely if it was changed that
way.

-Kimmo
___
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: lang/go security problem on one but not the other

[Kimmo Paasiala]

On Wed, Sep 2, 2015 at 8:13 PM, Rob Belics  wrote:
> I found an updated vuln.xml in /usr/ports/security/vuxml/ dated today. I
> will copy that over to /var/db/pkg/ but still question why that file was
> not updated.
>

It's not updated by portsnap(8) but pkg-updating(8). Portmaster won't
update it either. There's a periodic(8) job that should update it
daily at /usr/local/etc/periodic/security/410.pkg-audit, controlled by
daily_status_security_pkgaudit_enable periodic.conf(5) setting that
defaults to YES.

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

Removal of $UNIQUENAME

[Kimmo Paasiala]

It would have been nice to have some kind of announcement about the
removal of $UNIQUENAME. I for example was depending on it in my
make.conf with declarations like these:

vim_SET= CONSOLE
vim_UNSET= GTK2 RUBY TCL

I can of course rewrite those now using $OPTIONS_NAME (editors_vim
prefix instead of vim) after reading bsd.option.mk and figuring out
the way that works...

-Kimmo
___
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: Removal of $UNIQUENAME

[Kimmo Paasiala]

On Wed, Aug 19, 2015 at 1:18 AM, Mathieu Arnold m...@freebsd.org wrote:


 +--On 18 août 2015 22:49:47 +0300 Kimmo Paasiala kpaas...@gmail.com
 wrote:
 | It would have been nice to have some kind of announcement about the
 | removal of $UNIQUENAME. I for example was depending on it in my
 | make.conf with declarations like these:
 |
 | vim_SET= CONSOLE
 | vim_UNSET= GTK2 RUBY TCL
 |
 | I can of course rewrite those now using $OPTIONS_NAME (editors_vim
 | prefix instead of vim) after reading bsd.option.mk and figuring out
 | the way that works...

 Just running make will tell you that:

 # make vim_SET=CONSOLE vim_UNSET=GTK2 RUBY TCL
 /!\ WARNING /!\
 You are using vim_SET which is not supported any more, use:
 editors_vim_SET= CONSOLE
 You are using vim_UNSET which is not supported any more, use:
 editors_vim_UNSET= GTK2 RUBY TCL



 --
 Mathieu Arnold


I see none of those warnings in my poudriere build logs, I'm not
exactly sure where the problem is but I guess that's why I missed the
change altogether. I do see the warnings fine when I run make(1)
directly in a port directory though.

-Kimmo
___
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: Removal of $UNIQUENAME

[Kimmo Paasiala]

On Wed, Aug 19, 2015 at 5:45 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Wed, Aug 19, 2015 at 1:18 AM, Mathieu Arnold m...@freebsd.org wrote:


 +--On 18 août 2015 22:49:47 +0300 Kimmo Paasiala kpaas...@gmail.com
 wrote:
 | It would have been nice to have some kind of announcement about the
 | removal of $UNIQUENAME. I for example was depending on it in my
 | make.conf with declarations like these:
 |
 | vim_SET= CONSOLE
 | vim_UNSET= GTK2 RUBY TCL
 |
 | I can of course rewrite those now using $OPTIONS_NAME (editors_vim
 | prefix instead of vim) after reading bsd.option.mk and figuring out
 | the way that works...

 Just running make will tell you that:

 # make vim_SET=CONSOLE vim_UNSET=GTK2 RUBY TCL
 /!\ WARNING /!\
 You are using vim_SET which is not supported any more, use:
 editors_vim_SET= CONSOLE
 You are using vim_UNSET which is not supported any more, use:
 editors_vim_UNSET= GTK2 RUBY TCL



 --
 Mathieu Arnold


 I see none of those warnings in my poudriere build logs, I'm not
 exactly sure where the problem is but I guess that's why I missed the
 change altogether. I do see the warnings fine when I run make(1)
 directly in a port directory though.

 -Kimmo

Disregard, the warnings do show up fine now in poudriere logs:

===phase: check-sanity   
/!\ WARNING /!\
You are using vim_SET which is not supported any more, use:
editors_vim_SET= CONSOLE

===

I was confused because the warnings apparently weren't added until the
commit yesterday that removed the support for $UNIQUENAME and I was
searching trough my old logs for the warnings and found nothing.

-Kimmo
___
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: Proposal to fix postgresql package maintainance nightmare

[Kimmo Paasiala]

On Tue, Aug 4, 2015 at 1:07 PM, Michael Grünewald michip...@gmail.com wrote:

 On 21 Jul 2015, at 11:46, Baptiste Daroussin b...@freebsd.org wrote:
 - Impossible to have tools from both old and new version at the same time 
 (which
 is necessary to upgrade db and prepare upgrades of db) …

 Could not jails be used to solve these issues by running the two (…) required 
 versions
 in jailed environments?  There is a little bit of setup, but if by any chance 
 you
 are using some variation of the immutable server pattern, it should stay very 
 low.


You can't ask an average FreeBSD user who just wants to upgrade
his/her PostgreSQL installation to set up jails that would be only
used for one task. The upgrade should be achievable with just 'pkg
upgrade' without any extra work.

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

Re: port renaming

[Kimmo Paasiala]

On Thu, Jul 16, 2015 at 8:23 PM, Vsevolod Stakhov
vsevo...@highsecure.ru wrote:
 On 16/07/2015 18:11, Henry Hu wrote:


 On Thu, Jul 16, 2015 at 7:04 AM, Vsevolod Stakhov
 vsevo...@highsecure.ru mailto:vsevo...@highsecure.ru wrote:

 On Thu, Jul 16, 2015 at 2:56 PM, Anton Yuzhaninov cit...@citrin.ru
 mailto:cit...@citrin.ru wrote:
 
  Port maintainers and port commiters, when 
 PORTNAME/PKGNAMEPREFIX/PKGNAMESUFFIX is changed, please note this change in 
 commit log and for important ports also in /usr/ports/UPDATING. Any rename 
 affect at leas some of FreeBSD users and
 
  Depends in our local ports was broken and I spent some time to figure 
 out why.
  It turns out, that PORTNAME for graphics/gd was changed in r324437.
  No singe word about this rename was added to commit message or 
 UPDATING...

 From the perspective of pkg things are even worse, as pkg can no
 longer detect that the renamed package is a replacement for some
 existing one. It breaks many stuff and solver could hardly help to
 resolve this in a pain-less matter. We need something like 'Replace'
 or 'Obsolete' field badly. 'UPDATING' does NOT help to solve this task
 at all.


 We already have the 'MOVED' file. Does it help?

 It doesn't because:

 1) it is human readable and not very convenient for parsing;
 2) we must keep this information on per-package basis and not globally;
 3) many items are missing in MOVED (and I've recently missed one when
 changing a port, for example)
 4) MOVED contains too many unnecessary information that is useful merely
 because we are using archaic version control system (namely, subversion)

 So the answer is no: we need a special field in manifests to make
 renaming transparent for pkg and, in turn, for users.

 --
 Vsevolod Stakhov


So basically you need a data structure in the pkg metadata that can
track all the previous origins for the port (not just the last because
ports might have multiple renames). That's quite a tall order I might
say.

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

security/openssl fails to stage after update to 1.0.2_2

[Kimmo Paasiala]

The error happens in stage phase:

making install in crypto/krb5...
making install in crypto/cms...
making install in crypto/pqueue...
making install in crypto/ts...
making install in crypto/srp...
making install in crypto/cmac...
making install in ssl...
making install in engines...
installing 4758cca
cp: lib4758cca.unknown: No such file or directory
*** Error code 1

Stop.
make[3]: stopped in
/var/tmp/poudriere/ports/default/security/openssl/work/openssl-1.0.2b/engines
*** Error code 1

Stop.
make[2]: stopped in
/var/tmp/poudriere/ports/default/security/openssl/work/openssl-1.0.2b
*** Error code 1

Stop.
make[1]: stopped in /poudriere/ports/default/security/openssl
*** Error code 1

Stop.
make: stopped in /poudriere/ports/default/security/openssl

All port options are at defaults. My system is:

FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #6
r284196: Wed Jun 10 08:45:24 EEST 2015
r...@firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC  amd64

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

Re: 10/stable virtualbox-ose crashes

[Kimmo Paasiala]

On Fri, May 29, 2015 at 8:45 PM, Adam McDougall mcdou...@egr.msu.edu wrote:
 On 05/29/2015 13:38, Kevin Oberman wrote:
 On Fri, May 29, 2015 at 10:10 AM, Russell L. Carter rcar...@pinyon.org
 wrote:

 Hi,
 kldload vboxsrv crashes recent 10/stables.  Last known working
 kernel/module pair is from May 5th.

 Not sure what is the optimal next step, suggestions welcome.


 Sounds like you have done this, but several reports have been made of this
 recently.  All were fixed by rebuilding virtualbox-ose-kmod. Always
 rebuild all kernel modules that are in ports when rebuilding the kernel,
 preferably by adding the appropriate PORTS_MODULES to /etc/src.conf.
 --
 Kevin Oberman, Network Engineer, Retired
 E-mail: rkober...@gmail.com

 Won't this will be a problem if people use official packages (built on
 10.x-RELEASE) on a system running -stable?  Wouldn't it mean an ABI was
 violated?


The KBI (kernel binary interface that the kernel modules use) is not
part of the promised stability, only the userland ABI is guaranteed to
stay compatible.

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

Re: Broken _DEPENDS logic

[Kimmo Paasiala]

On Mon, May 4, 2015 at 2:33 AM, Dewayne Geraghty
dewayne.gerag...@heuristicsystems.com.au wrote:
 On 4/05/2015 7:38 AM, Matthew Seaman wrote:
 On 03/05/2015 21:08, Lowell Gilbert wrote:
 But, generally, the answer to your question is no, becuase it is often
 the case that more than one port can serve as a dependency for another
 port. Your suggestion amounts to saying that only one port can satisfy a
 dependency for another port, which is not the case.
 You're correct as far as the ports goes, but not when you're dealing
 with precompiled packages.  Once you've built the package, the
 dependency on the specific version of the other port is baked into it.
 That's something which is likely to change in the not too distant
 future, but it's going to mean some fundamental changes in the ports in
 order to bring about.

 At the moment, therefore, the advice for pkg users when you want to make
 customizations like eg. using a different version of postfix is to set
 up your onw instance of poudriere and build your own.

   Cheers,

   Matthew


 I read Lowell's issue as indirectly suggesting an enhancement to the
 packaging system.

 For the sake of the discussion, lets assume a dependency hierarchy of: X
 depends upon Y.
 While building X, rather than assume the prefix for Y, and test for the
 existence of a file installed by Y (and this is very often used), use
 pkg to ascertain the dependency's origin and lookup the prefix for Y,
 prior to the test.

 And please can we not assume that everyone is using poudriere.

 Regards, Dewayne.

It is quite weird that you have to test for the existence of a file to
test for the existence of a dependency when the first thing that comes
to mind would be to just ask pkg(8). This seems to be from the time
when you couldn't assume that there is a package database that you
could query for an installed package and its properties.  Grep
NO_PKG_REGISTER in /usr/ports/Mk to see how that was possible.

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

Re: openssl and bash libcrypto

[Kimmo Paasiala]

On Thu, Apr 9, 2015 at 1:42 PM, Aristedes Maniatis a...@ish.com.au wrote:
 Starting in the last week or so, several different applications are 
 exhibiting the same symptoms of broken libcrypto libraries.

 (gdb) core bash.core
 Core was generated by `bash'.
 Program terminated with signal 11, Segmentation fault.

 (gdb) bt
 #0  0x0008029cafe5 in OPENSSL_ia32_cpuid () from 
 /usr/local/lib/libcrypto.so.8
 #1  0x0008033cf0b9 in OPENSSL_ia32cap_loc () from /lib/libcrypto.so.7
 #2  0x0008032d584e in _init () from /lib/libcrypto.so.7
 #3  0x7fffd7c0 in ?? ()
 #4  0x0008006d66bf in r_debug_state () from /libexec/ld-elf.so.1
 #5  0x0008006dad87 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1
 #6  0x0008006d7ad3 in dlopen () from /libexec/ld-elf.so.1
 #7  0x000800e5c436 in _nsdbtaddsrc () from /lib/libc.so.7
 #8  0x000800e563c9 in _nsyyparse () from /lib/libc.so.7
 #9  0x000800e5cab1 in nsdispatch () from /lib/libc.so.7
 #10 0x000800e49ebe in getpwuid () from /lib/libc.so.7
 #11 0x000800e49cbf in getpwnam () from /lib/libc.so.7


 Although that symptom is in bash, I've got the exact same symptoms in 
 asterisk. The builds are done in poudriere with the make flags:

 WITH_OPENSSL_PORT=yes


 I've tried updating to the latest 10.1-RELEASE-p6, although it is possible 
 that that is exactly what caused the problem in the first place when the 
 poudriere jail was updated to that release.

 The function calls mention ia32 but this box is purely 64bit.


 I've seen recent discussions about the problems that confusion between core 
 openssl and ports openssl can cause. But I can't for the life of me figure 
 how to avoid this problem.

 * Should bash be built with Build static executables and/or libraries?
 * Should I stop trying to use openssl from ports until this is fixed?
 * Why is /lib/libcrypto.so.7 calling /usr/local/lib/libcrypto.so.8 ?

 I've tried so many different combinations of settings, I don't know what to 
 try next.

 Thanks
 Ari


 --
 --
 Aristedes Maniatis
 ish
 http://www.ish.com.au
 Level 1, 30 Wilson Street Newtown 2042 Australia
 phone +61 2 9550 5001   fax +61 2 9550 4001
 GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A


You could build world with WITHOUT_OPENSSL but that would also disable
some other needed pieces such as OpenSSH and you'd have to install
them from ports.

WITHOUT_OPENSSL
 Set to not build OpenSSL.  When set, it also enforces the follow‐
 ing options:

 WITHOUT_KERBEROS
 WITHOUT_KERBEROS_SUPPORT
 WITHOUT_OPENSSH

 When set, the following options are also in effect:

 WITHOUT_GSSAPI (unless WITH_GSSAPI is set explicitly)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: openssl and bash libcrypto

[Kimmo Paasiala]

On Thu, Apr 9, 2015 at 3:43 PM, Dewayne Geraghty
dewayne.gerag...@heuristicsystems.com.au wrote:

 On 9/04/2015 10:02 PM, Kimmo Paasiala wrote:
 On Thu, Apr 9, 2015 at 1:42 PM, Aristedes Maniatis a...@ish.com.au wrote:
 Starting in the last week or so, several different applications are 
 exhibiting the same symptoms of broken libcrypto libraries.

 (gdb) core bash.core
 Core was generated by `bash'.
 Program terminated with signal 11, Segmentation fault.

 (gdb) bt
 #0  0x0008029cafe5 in OPENSSL_ia32_cpuid () from 
 /usr/local/lib/libcrypto.so.8
 #1  0x0008033cf0b9 in OPENSSL_ia32cap_loc () from /lib/libcrypto.so.7
 #2  0x0008032d584e in _init () from /lib/libcrypto.so.7
 #3  0x7fffd7c0 in ?? ()
 #4  0x0008006d66bf in r_debug_state () from /libexec/ld-elf.so.1
 #5  0x0008006dad87 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1
 #6  0x0008006d7ad3 in dlopen () from /libexec/ld-elf.so.1
 #7  0x000800e5c436 in _nsdbtaddsrc () from /lib/libc.so.7
 #8  0x000800e563c9 in _nsyyparse () from /lib/libc.so.7
 #9  0x000800e5cab1 in nsdispatch () from /lib/libc.so.7
 #10 0x000800e49ebe in getpwuid () from /lib/libc.so.7
 #11 0x000800e49cbf in getpwnam () from /lib/libc.so.7


 Although that symptom is in bash, I've got the exact same symptoms in 
 asterisk. The builds are done in poudriere with the make flags:

 WITH_OPENSSL_PORT=yes


 I've tried updating to the latest 10.1-RELEASE-p6, although it is possible 
 that that is exactly what caused the problem in the first place when the 
 poudriere jail was updated to that release.

 The function calls mention ia32 but this box is purely 64bit.


 I've seen recent discussions about the problems that confusion between core 
 openssl and ports openssl can cause. But I can't for the life of me figure 
 how to avoid this problem.

 * Should bash be built with Build static executables and/or libraries?
 * Should I stop trying to use openssl from ports until this is fixed?
 * Why is /lib/libcrypto.so.7 calling /usr/local/lib/libcrypto.so.8 ?

 I've tried so many different combinations of settings, I don't know what to 
 try next.

 Thanks
 Ari


 --
 --
 Aristedes Maniatis
 ish
 http://www.ish.com.au
 Level 1, 30 Wilson Street Newtown 2042 Australia
 phone +61 2 9550 5001   fax +61 2 9550 4001
 GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

 You could build world with WITHOUT_OPENSSL but that would also disable
 some other needed pieces such as OpenSSH and you'd have to install
 them from ports.

 WITHOUT_OPENSSL
  Set to not build OpenSSL.  When set, it also enforces the 
 follow‐
  ing options:

  WITHOUT_KERBEROS
  WITHOUT_KERBEROS_SUPPORT
  WITHOUT_OPENSSH

  When set, the following options are also in effect:

  WITHOUT_GSSAPI (unless WITH_GSSAPI is set explicitly)
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org



 Take care, as: geli, pkg and tar will fail to build, the latter due to
 libarchive, and libfetch as also being affected.  I went down this path
 a few years ago, but stopped when the ability to install
 security/openssl into /usr was instituted.  (geli only needs openssl
 headers).  As an FYI, I build all ports using security/openssl though
 heimdal and a few others are a challenge because they try/tried to use
 base openssl libcom_err.so.
 I'd suggest making a backup of the openssl libs (crypto, ssl),
 pkg-static and verify /rescue/tar is available, so that you have a
 recovery route.


Aah yes, it's no-go then if it breaks pkg(8)...

One solution that comes to my mind would be to use two-level
namespaces for symbol resolution. The first part would be the module
name and the second part the symbol name. Any shared libraries
produced by ports(7) would be required to prepend 'ports-' to the
module name. This would eliminate any possibility of dynamic symbol
clashes between ports and the base system.

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

Re: pkgng deviates from defaults?

[Kimmo Paasiala]

On Mon, Mar 9, 2015 at 5:44 PM, Adam McDougall mcdou...@egr.msu.edu wrote:
 On 03/09/2015 08:23, Carsten Jensen wrote:
 On 03/08/2015 02:41 PM, Baptiste Daroussin wrote:
 On Sun, Mar 08, 2015 at 01:46:28PM +0100, Carsten Jensen wrote:

 It seems that pkgng deviates from installing the defaults.
 one of the culprits seems to be phpMyAdmin, as trying to upgrade this
 only it wants php56
 deleting phpMyAdmin just shows I have other packages needing php56 in my
 system.

 is this a bug? and how can I prevent upgrading to the non-default php56?

 The default settings are a ports tree setting not a pkg setting. for
 now the
 ports are hardcoding the required version into the packages, this is a
 legacy of
 the old system, noone has yet been working on this. so beside building
 your own
 packages with poudriere (which will define the default you want) righ
 now there
 is no way to avoid that.

 The php case but not only php will require small changes in pkg(8) to
 activate
 smart dependencies: depend on a1=2.10 and also adding
 provides/requires (this
 is not very hard to be added in pkg.) and it should also require heavy
 changes
 on the port side!

 As far as I know noone has been working on those changes in the port
 side. the
 pkg(8) changes are mostly pending for real use cases in the port side.
 Meaning
 both should be coordinated.

 Best regards,
 Bapt


 Sorry I don't think I was clear.
 Some applications wants php5 and some applications wants php56 when
 upgrading using pkg-ng.
 Using pkg-ng one cannot upgrade i.e. both phpMyAdmin and an other web
 based application due to this conflict.

 So while the upgrade happens to upgrade to php56 it also removes the
 other web application, as it only wants php5.

 Most of the applications on the server is maintained by pkg-ng, and it
 conflicts itself.

 Basically there are now 2 default php versions used by pkg-ng
 meaning, _I_ am not trying to upgrade to php56, pkg-ng does but it also
 tries to upgrade php5.

 I can't find any hardcode to php56 in the Makefile of databases/phpmyadmin

 I don't know if this is expressed better, I hope so atleast.


 Cheers
 Carsten


 I think there is some confusion because the default PHP version in ports
 recently changed to 5.6, and now the official packages are pulling in 5.6:

 https://svnweb.freebsd.org/ports?view=revisionrevision=379433

 pkg sometimes tries to remove conflicting packages (like ones that need
 5.5) unless you pkg upgrade without specifying a package and then it
 has better information on what to reinstall so packages might not get
 removed.

In fact pkg(8) will not allow conflicting packages to be installed at
all. The result is that if you want to install a package that would
introduce a conflict in the installed package database the conflict
has to be resolved one way or another. The only solution at the moment
is to remove the offending packages from the existing installed
packages. This is not a pkg(8) limitation but the consequence of how
ports(7) system deals with conflicts and lack of infrastructure to
properly allow multiple versions of the same software to co-exist.

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

Re: Single worst bug for ports: lang/gcc* doesn't support c++11

[Kimmo Paasiala]

On Sun, Mar 8, 2015 at 2:36 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Sun, Mar 8, 2015 at 8:36 AM, Yuri y...@rawbw.com wrote:
 On 03/07/2015 21:28, Russell L. Carter wrote:


 I would like to understand better the problem here, because I use c++11
 features heavily with lang/gcc49 on a daily basis with zero problems.


 No, gcc-4.9.3 fails in the same way. Specific missing feature: std::snprintf

 error: 'snprintf' is not a member of 'std'


 Yuri

 Post an example of the offending code. I suspect that the real problem
 is that the code is not using an explicit 'using std::snprintf' when
 it should, this is a very common problem in C++ code that has been
 written at a time when including a header file was enough to bring the
 std:: namespace names in that header to the global namespace. This is
 no longer the case afaik on standard conformining implementations.

 -Kimmo

Well, scratch that sorry. I just learned that std::snprintf is indeed
a c++11 only feature...

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

Re: Single worst bug for ports: lang/gcc* doesn't support c++11

[Kimmo Paasiala]

On Sun, Mar 8, 2015 at 8:36 AM, Yuri y...@rawbw.com wrote:
 On 03/07/2015 21:28, Russell L. Carter wrote:


 I would like to understand better the problem here, because I use c++11
 features heavily with lang/gcc49 on a daily basis with zero problems.


 No, gcc-4.9.3 fails in the same way. Specific missing feature: std::snprintf

 error: 'snprintf' is not a member of 'std'


 Yuri

Post an example of the offending code. I suspect that the real problem
is that the code is not using an explicit 'using std::snprintf' when
it should, this is a very common problem in C++ code that has been
written at a time when including a header file was enough to bring the
std:: namespace names in that header to the global namespace. This is
no longer the case afaik on standard conformining implementations.

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

Re: plist problems upgrading alpine port

[Kimmo Paasiala]

On Fri, Feb 20, 2015 at 3:12 AM, Marco Beishuizen mb...@xs4all.nl wrote:
 On Fri, 20 Feb 2015, the wise Marco Beishuizen wrote:

 On Thu, 19 Feb 2015, the wise Ben Woods wrote:

 It's the opposite actually. That line was already in pkg-plist, but
 needed
 to be removed. You have now added it a second time, meaning you get the
 error twice.

 You need to now delete both instances of that line from pkg-plist.


 That won't work either. The pkg-plist is now like this:

 bin/alpine
 bin/rpdump
 bin/rpload
 %%ETCDIR%%.conf.sample
 man/man1/alpine.1.gz
 man/man1/rpdump.1.gz
 man/man1/rpload.1.gz
 %%PORTDOCSDOCSDIR%%/tech-notes.txt

 And results in this:

 install  -o root -g wheel -m 444
 /home/marco/tmp/alpine/work/alpine-2.20/doc/tech-notes/low-level.html
 /home/marco/tmp/alpine/work/stage/usr/local/share/doc/alpine/tech-notes
  Compressing man pages (compress-man)
  Running Q/A tests (stage-qa)
  Checking for pkg-plist issues (check-plist)
 === Parsing plist
 === Checking for items in STAGEDIR missing from pkg-plist
 Error: Orphaned: %%PORTDOCSDOCSDIR%%/tech-notes.txt
 === Checking for items in pkg-plist which are not in STAGEDIR
 Error: Missing: %%DOCSDIR%%/tech-notes/tech-notes.txt
 === Error: Plist issues found.
 *** Error code 1

 Regards,
 Marco


 That is: removing the last line of pkg-plist above results in the errors
 above.

 Regards,
 Marco


Is the tech-notes.txt file copied to the stage directory at all? The
error is really that you are saying in your pkg-plist file that a
%%DOCSDIR%%/tech-notes/tech-notes.txt file should be present in the
stage directory before the pkg-plist check but isn't. A line from your
first message shows low-level.html copied but is there anything in the
log about tech-notes.txt?

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

Re: Is NO_PKG_REGISTER still supposed to work?

[Kimmo Paasiala]

On Sat, Feb 7, 2015 at 10:56 AM, Matthew Seaman matt...@freebsd.org wrote:
 On 2015/02/07 01:31, Kimmo Paasiala wrote:
 From bsd.port.mk:

 # NO_PKG_REGISTER
 #   - Don't register a port installation as a package.

 However, testing this with a port results in the port installation
 performing the staging part only and the final installation from the
 stage directory on to the system being skipped when NO_PKG_REGISTER is
 set. Is this still supposed to work?

 I doubt it.  pkg(8) doesn't have the capability to install a package
 without updating the package database.  Plus why would you even want to
 do that nowadays?  As I recall NO_PKG_REGISTER was a work-around for not
 having staging or tools like poudriere where you can build a package
 without scribbling on your live system.

 Cheers,

 Matthew



Would it be a good idea to remove it completely from bsd.port.mk for
clarity and simplifying the code? I can see a few places in the file
where it it's used in conditions and those look like no-ops now
assuming NO_PKG_REGISTER is not used by anyone anymore.

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

Is NO_PKG_REGISTER still supposed to work?

[Kimmo Paasiala]

From bsd.port.mk:

# NO_PKG_REGISTER
#   - Don't register a port installation as a package.

However, testing this with a port results in the port installation
performing the staging part only and the final installation from the
stage directory on to the system being skipped when NO_PKG_REGISTER is
set. Is this still supposed to work?

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

How does a port maintainer use the bug database?

[Kimmo Paasiala]

I’m the maintainer of level/bin86 (more out of general interest in learning the 
ropes of port maintainance rather than the port itself).

I have submitted a PR to update the port to use a bit more modern practices:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193889

I submitted the PR with a different email than the one on the maintainer field, 
this made the bug database to send email to the maintainer address asking for 
approval which I in my view did but I’m not sure what was really required 
because I didn’t get any specific instructions of what to do.

Is it now just a case of waiting till someone with commit rights picks up this 
PR or something else?

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

Re: How does a port maintainer use the bug database?

[Kimmo Paasiala]

 On 2.10.2014, at 23.27, A.J. 'Fonz' van Werven free...@skysmurf.nl wrote:
 
 Kimmo Paasiala wrote:
 
 I submitted the PR with a different email than the one on the maintainer
 field
 [snip]
 Is it now just a case of waiting till someone with commit rights picks
 up this PR or something else?
 
 Do you have a Bugzilla account for the address listed as maintainer?
 
 If so, log in with that and mark the patch you submitted (assuming you did
 that) as maintainer-approved.
 
 AvW
 
 -- 
 Imbibo, ergo sum.

My only Bugzilla account is on this address I’m now posting from. I think I 
got, change the flags on the patch to maintainer-approval plus (+), is that all?

Thanks,

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

Re: How does a port maintainer use the bug database?

[Kimmo Paasiala]

 On 2.10.2014, at 23.44, A.J. 'Fonz' van Werven free...@skysmurf.nl wrote:
 
 Kimmo Paasiala wrote:
 
 My only Bugzilla account is on this address I???m now posting from. I
 think I got, change the flags on the patch to maintainer-approval plus
 (+), is that all?
 
 Even with maintainer-approval the PR (or bug, as Bugzilla calls it) still
 has to be picked up by a committer, but having that flag set (which you
 can do from an account that matches the maintainer's address) makes it a
 lot easier than when a committer first needs to verify that both addresses
 belong to the same person.
 
 HTH,
 
 AvW
 
 -- 
 Imbibo, ergo sum.

I actually found out that Bugzilla had an account for kpaas...@gmail.com, I 
just had to use the reset password function to access it. I can from this on 
file the PRs using that account so they match the maintainer address.

Thanks,

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

Re: Pourdriere + Protocol error?

[Kimmo Paasiala]

 Date: Mon, 15 Sep 2014 18:29:22 -0700
 From: Patrick Gibson gibblert...@gmail.com
 To: FreeBSD Ports ML freebsd-ports@freebsd.org
 Subject: Pourdriere + Protocol error?
 Message-ID:
   ca+dwbmygn-exparfkfaddi8bwe9yreekayxqwanzp_0msah...@mail.gmail.com
 Content-Type: text/plain; charset=UTF-8
 
 I'm getting the following when trying to create an 8.4 jail from FreeBSD
 10. I've got the latest ports tree and updates. Has anyone seen this?
 
 # poudriere jail -c -v 8.4-RELEASE -a amd64 -j 84amd64
 
  Fetching sets for FreeBSD 8.4-RELEASE amd64
 
 /usr/local/poudriere/jails/84amd64/fromftp//CH100% of 4123  B   15 MBps
 00m00s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 4811 kBps
 00m00s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 4816 kBps
 00m00s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 4882 kBps
 00m00s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 4896 kBps
 00m00s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 4910 kBps
 00m00s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 4916 kBps
 00m00s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 4519 kBps
 00m00s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 4509 kBps
 00m00s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 5236 kBps
 00m00s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 4261 kBps
 00m00s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 4965 kBps
 00m01s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 4938 kBps
 00m00s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 4964 kBps
 00m00s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 4911 kBps
 00m00s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 4876 kBps
 00m00s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 5204 kBps
 00m01s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 5247 kBps
 00m00s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 4881 kBps
 00m00s
 
 /usr/local/poudriere/jails/84amd64/fromftp//ba100% of 1392 kB 4811 kBps
 00m00s
 
 fetch:
 ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.4-RELEASE/base/base.at:
 Protocol error
 
 fetch:
 ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.4-RELEASE/base/base.at:
 Protocol error
 
  Error: Failed to fetch from
 ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.4-RELEASE/base/base.at
 
 fetch:
 ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.4-RELEASE/dict/CHECKSUM.SHA256:
 Protocol error
 
 fetch:
 ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.4-RELEASE/dict/CHECKSUM.SHA256:
 Protocol error
 
  Error: Failed to fetch from
 ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.4-RELEASE/dict/CHECKSUM.SHA256
 
  Error while creating jail, cleaning up.
 
  Removing 84amd64 jail... done
 
 

Something is interfering with the FTP transfers midway. Are you behind a 
firewall with a proxy? You can try to use ‘-m http’ option that tells poudriere 
to use the HTTP protocol instead of FTP.

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

Re: 'make install NO_PKG_REGISTER=1'. Should that still work with staging?

[Kimmo Paasiala]

On 24.6.2014, at 19.25, Kimmo Paasiala kpaas...@icloud.com wrote:

 Hello,
 
 There’s not a whole lot of people who even know this but it used to be that a 
 port could be installed without registering it in the package database by 
 specifying NO_PKG_REGISTER=1 on make(1) command line.  It’s not documented 
 anywhere else but in bsd.port.mk as far as I know.
 
 Now with a port converted to staging it’s no longer possible to do the same 
 because if you turn off the packaging part then quite obviously nothing will 
 get installed because staged ports use pkg-plist to do the real install and 
 pkg-plist is a pkg(8) feature.
 
 Now my question is that should this NO_PKG_REGISTER trick still work with 
 staged ports? If it can not be supported anymore there should be a notice 
 somewhere that this feature will no longer work with staged ports.
 
 -Kimmo

Bug report submitted. I still think that either this feature should be made to 
work with stage-enabled ports or removed if it can not be supported.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191461

-Kimmo


signature.asc
Description: Message signed with OpenPGP using GPGMail

'make install NO_PKG_REGISTER=1'. Should that still work with staging?

[Kimmo Paasiala]

Hello,

There’s not a whole lot of people who even know this but it used to be that a 
port could be installed without registering it in the package database by 
specifying NO_PKG_REGISTER=1 on make(1) command line.  It’s not documented 
anywhere else but in bsd.port.mk as far as I know.

Now with a port converted to staging it’s no longer possible to do the same 
because if you turn off the packaging part then quite obviously nothing will 
get installed because staged ports use pkg-plist to do the real install and 
pkg-plist is a pkg(8) feature.

Now my question is that should this NO_PKG_REGISTER trick still work with 
staged ports? If it can not be supported anymore there should be a notice 
somewhere that this feature will no longer work with staged ports.

-Kimmo


signature.asc
Description: Message signed with OpenPGP using GPGMail

Stageifying various textproc/docbook* ports

[Kimmo Paasiala]

I made a quick stage conversion for textproc/docbook-sk because of a report on 
the FreeBSD forums that the port failed to install because the xml catalog 
entries were being added twice. The patch if you want to see it is on paste bin:

http://pastebin.com/24QGWh8x

Is there anyone else working on converting these docbook ports to stage? If not 
I would like to try my hand with a few more of them because they look like to 
be quite easy to convert.

One thing I’d like to ask is the handling of the ${PREFIX}share/xml and 
${PREFIX}share/xml directories. Which port should own these directories and 
should the docbook-ports try to delete these directories like the docbook-sk 
port now tries to do? In my patch I replaced the '@unexec /bin/rmdir’s with 
just '@dirrmtry share/xml/docbook'

-Kimmo


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Stageifying various textproc/docbook* ports

[Kimmo Paasiala]

On 27.11.2013, at 21.16, Kimmo Paasiala kpaas...@icloud.com wrote:

 
 One thing I’d like to ask is the handling of the ${PREFIX}share/xml and 
 ${PREFIX}share/xml directories.


${PREFIX}/share/xml and ${PREFIX}/share/xml/docbook directories *

 


signature.asc
Description: Message signed with OpenPGP using GPGMail

Few missing packages from the new PKG repositories

[Kimmo Paasiala]

Were these left out by accident or why aren’t they included?

- x11/gnome2, x11/gnome2-lite is in the repo.

- editors/vim, editors/vim-lite is in the repo as well.

-Kimmo


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Few missing packages from the new PKG repositories

[Kimmo Paasiala]

On 23.11.2013, at 20.29, Koop Mast k...@rainbow-runner.nl wrote:

 On 23-11-2013 18:13, Daniel Nebdal wrote:
 On Sat, Nov 23, 2013 at 3:27 PM, Kimmo Paasiala kpaas...@icloud.com wrote:
 
 Were these left out by accident or why aren’t they included?
 
 - x11/gnome2, x11/gnome2-lite is in the repo.
 
 - editors/vim, editors/vim-lite is in the repo as well.
 
 -Kimmo
 
 Do all the dependencies build with default options? I suspect that's why
 kde4 wasn't packaged last time I checked.
 (I guess we could take a look at the build logs from the new repository; I
 know they're out there somewhere.)
 
 To both of you, on which FreeBSD version and arch are these packages missing? 
 That will help us narrow down where to look.
 
 -Koop
 
 ---
 This email is free from viruses and malware because avast! Antivirus 
 protection is active.
 http://www.avast.com
 

This is from http://pkg0.bme.freebsd.org/ that is one of the SRV mirrors of 
pkg.freebsd.org:

x11/gnome2 is present in freebsd:8:x86:32 but is missing from freebsd:8:x86:64 

It’s also missing from freebsd:9:x86:32 and missing from freebsd:9:x86:64.

Also missing from freebsd:10:x86:32 and missing from freebsd:10:x86:64.

So it looks like the x11/gnome2 package is only available for FreeBSD 8 i386.

-Kimmo


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Few missing packages from the new PKG repositories

[Kimmo Paasiala]

On 23.11.2013, at 20.29, Koop Mast k...@rainbow-runner.nl wrote:

 On 23-11-2013 18:13, Daniel Nebdal wrote:
 On Sat, Nov 23, 2013 at 3:27 PM, Kimmo Paasiala kpaas...@icloud.com wrote:
 
 Were these left out by accident or why aren’t they included?
 
 - x11/gnome2, x11/gnome2-lite is in the repo.
 
 - editors/vim, editors/vim-lite is in the repo as well.
 
 -Kimmo
 
 Do all the dependencies build with default options? I suspect that's why
 kde4 wasn't packaged last time I checked.
 (I guess we could take a look at the build logs from the new repository; I
 know they're out there somewhere.)
 
 To both of you, on which FreeBSD version and arch are these packages missing? 
 That will help us narrow down where to look.
 
 -Koop
 
 ---
 This email is free from viruses and malware because avast! Antivirus 
 protection is active.
 http://www.avast.com
 

editors/vim seems to be in the repo for all versions and architectures after 
all, I assumed it was missing based on a thread on the FreeBSD forums.

-Kimmo


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Package building logs, http://pointyhat.freebsd.org/ ?

[Kimmo Paasiala]

On Sun, Nov 17, 2013 at 9:07 AM, Mark Linimon lini...@lonesome.com wrote:
 On Sun, Nov 17, 2013 at 08:51:38AM +0200, Kimmo Paasiala wrote:
 The porter's handbook states that the package building logs and
 errors would be found at http://pointyhat.freebsd.org/ but the site
 is not working. Where are the package building logs now?

 The porter's handbook is stale.  pointyhat is no longer operational.

 mcl

Ok but where are the build logs of the new package builder(s)?

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

Re: DESTDIR support broken?

[Kimmo Paasiala]

On Mon, Nov 18, 2013 at 10:05 AM, Dominic Fandrey kamik...@bsdforen.de wrote:
 On 18/11/2013 04:10, Eitan Adler wrote:
 On Thu, Nov 14, 2013 at 1:00 PM, Dominic Fandrey kamik...@bsdforen.de 
 wrote:
 # make DESTDIR=/root/tmpdest install
 ===  Creating some important subdirectories

 Are you sure you don't mean make PREFIX=/root/tmpdest/ ?

 Yes.

 --

I would expect DESTDIR=/some/path just work for any port. Last commit
to bsd.destdir was over a year ago so either it has been broken for a
long time or some other more recent commit has broken it.

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

Package building logs, http://pointyhat.freebsd.org/ ?

[Kimmo Paasiala]

The porter's handbook states that the package building logs and
errors would be found at http://pointyhat.freebsd.org/ but the site
is not working. Where are the package building logs now?

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

make index warning on recent ports tree

[Kimmo Paasiala]

...
--- describe.russian ---

GhostScript not found in PATH

make[5]: /usr/ports/russian/koi8r-ps/Makefile line 23: warning:
/bin/sh /usr/ports/russian/koi8r-ps/files/find-fontmap.sh returned
non-zero status

It turns out that the Makefile of this port is trying to run
ghostscript without checking if it is installed or not.

.if !defined(FONTMAP)
FONTMAP!=   ${SH} ${FILESDIR}/find-fontmap.sh
.endif


Isn't this the kind of stuff that should never be done in a port
Makefile but use proper build time dependencies?


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

Re: Perl en /etc/make.conf

[Kimmo Paasiala]

On Mon, Nov 11, 2013 at 10:34 AM, Johan Hendriks joh.hendr...@gmail.com wrote:
 Hello all.

 I have a FreeBSD 10-Beta 3 server installed to test the new pkgng and other
 things.
 On all the systems where i  installed perl there was always a line in
 /etc/make.conf like the following

 # added by use.perl 2013-09-27 14:38:36
 PERL_VERSION=5.14.4


 I just installed  perl5-5.16.3_2 and i do not see that line.
 Is this line not needed anymore or did i do something wrong.

 regards
 Johan



As far as I know it was removed because it is not used when installing
perl from a binary package. The new mechanism to select default
versions for various ports is the DEFAULT_VERSIONS make.conf variable
that only applies when building ports.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Is it or isn't it installed? (It is, but ports tries to again, doomed to fail.)

[Kimmo Paasiala]

On Fri, Nov 8, 2013 at 8:09 AM, Chad J. Milios mil...@ccsys.com wrote:

 On 11/5/2013 11:13 AM, William Grzybowski wrote:

 On Tue, Nov 5, 2013 at 2:09 PM, Dominic Fandrey kamik...@bsdforen.de
 wrote:

 On 05/11/2013 14:55, Chad J. Milios wrote:

 snip...

 Just happen to already have the dependency devel/py-boto
 (py27-boto-2.14.0) or devel/py-pyzmq (py27-pyzmq-2.2.0) installed (and 
 their
 port dirs since cleaned up) when you try to install net/py-kombu
 (py27-kombu-3.0.1) from ports with BOTO and/or ZMQ options. (In my case I
 have all its options on.)
 ...snip...

  Stop in /usr/ports/net/py-kombu.
  root@shikamaru:/usr/ports/net/py-kombu #

 That looks like the dependencies in net/py-kombu are broken. I.e. they
 refer to files that are not/no longer installed by the dependencies.


 Actually, Dominic, the dependencies were referred to using the
 package_name/version_spec functionality rather than checking the existence
 of a target file. There was an error with the way the version requirement
 was specified which William has since fixed.


 Did you get my email asking to try again after the last port update
 fixing the dependencies?

 YUP! Sure did fix it, William. THANK YOU for the super-quick response and
 fix. Sorry it took me this long to get around to a re-test for you. It looks
 like your fix did the trick:

 28c28
  BOTO_RUN_DEPENDS=
 ${PYTHON_PKGNAMEPREFIX}boto=2.6.0:${PORTSDIR}/devel/py-boto
 ---
 BOTO_RUN_DEPENDS=
 ${PYTHON_PKGNAMEPREFIX}boto=2.6.0:${PORTSDIR}/devel/py-boto
 32c32
  ZMQ_RUN_DEPENDS=
 ${PYTHON_PKGNAMEPREFIX}pyzmq=2.2.0:${PORTSDIR}/devel/py-pyzmq
 ---
 ZMQ_RUN_DEPENDS=
 ${PYTHON_PKGNAMEPREFIX}pyzmq=2.2.0:${PORTSDIR}/devel/py-pyzmq

 Anyone spot the subtle difference? Darn. That went right under my nose.

 Seems like a mistake anyone could make, with all the syntaxen floating
 around in one's head. I for one think it would be nice if make failed more
 spectacularly at the point it hits the =. Is there any legal use of = in
 make? It seems that every occurrence of = in the ports tree is now either
 just part of some inlined perl code, part of human-readable text output or
 in a comment. Food for thought: I wonder what make is thinking at that
 point of parsing and executing. Can the make makers make make see that as an
 immediate syntax error without a drastic change that breaks Makefiles
 potentially in the wild? A question for far greater minds than I. Prolly
 already wudda if they cudda. Oh well, just another make gotcha for everyone
 to remember to watch out for.

 Thanks again WG@ for fixing my issue within half an hour of my mail to
 freebsd-ports@ !!!



I don't think that make(1) is actually evaluating those conditions but
/bin/sh is. I can not find any mention in make(1) about arithmetic
operators.

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

Re: pkg install subversion broken on 9.2-R...

[Kimmo Paasiala]

On Wed, Nov 6, 2013 at 6:54 AM, John-Mark Gurney j...@funkthat.com wrote:
 Ok, I know this is partly my fault for not being specific enough, but
 after a pkg install python installed 2.7 and not 2.6 and the full set
 of 3.x versions, I was ok, lets just do the same for subversion...

 Of course I also didn't read that it was going to install 1.6.23_2,
 1.7.13 AND 1.8.3 when you run pkg install subversion so I got a bunch
 of conflicts...

 Are we planning on fixing that so that it either installs on version,
 or asks which version you'd like to install?

 Thanks.


Pkg doesn't know that those conflicting packages are different
versions of the same software, it only knows that there is a conflict
between them. The solution to this requires a change at ports level.

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

Re: Official FreeBSD Binary Packages now available for pkgng

[Kimmo Paasiala]

On Sun, Nov 3, 2013 at 12:34 AM, Lars Engels lars.eng...@0x20.net wrote:
 On Thu, Oct 31, 2013 at 05:22:44PM -0500, Bryan Drewery wrote:
 On 10/31/2013 4:54 PM, Freddie Cash wrote:
  On Thu, Oct 31, 2013 at 2:39 PM, Mehmet Erol Sanliturk 
  m.e.sanlit...@gmail.com wrote:
 
  On Thu, Oct 31, 2013 at 4:58 PM, Bryan Drewery bdrew...@freebsd.org
  wrote:
 
  At present , the packages information and themselves are available from ,
  such as :
 
  ftp://ftp1.freebsd.org/pub/FreeBSD/ports/amd64/
 
  It seems that new pkg compatible packages will not be exposed to the
  Internet such as
 
 
  http://avalon.dragonflybsd.org/dports/
  http://pkg.wolfpond.org/
  http://mirror.exonetric.net/pub/pkgng/
 
 
  This will be a very significant inconvenience for the possible users
  because without an installed FreeBSD , they will not be able to see what
  are the available packages there .
 
 
  ???From the original message:
  Mirrors you may use instead of the global
  pkg.FreeBSD.orghttp://pkg.freebsd.org/
  :
 
  pkg.eu.FreeBSD.org http://pkg.eu.freebsd.org/
  pkg.us-east.FreeBSD.org http://pkg.us-east.freebsd.org/
  pkg.us-west.FreeBSD.org http://pkg.us-west.freebsd.org/
 
 
  pkg.freebsd.org is, basically, an alias for the above (and any other
  mirrors that come online) and the pkg(1) tool will pick a local mirror
  based on the DNS response for pkg.freebsd.org.
 
  However, you are free to manually enter any of the above mirrors into your
  pkg.conf.
 
  And, you are free to browse any of the above mirrors via HTTP in any web
  browser.
 
  It's not nearly as convenient as just browsing pkg.freebsd.org, but it's
  still possible to do so.

 These are still SRV hosts as well. The real hosts can be found with

 dig SRV _http._tcp.HOST HOST being the host from above lists.


 Please add this to pkg.conf(5) as this it not intuitive and the syntax
 is a bit cumbersome.


You will never have to know that syntax unless you're one of the few
that are behind a very restrictive firewall/proxy. The pkg client does
all this SRV record magic internally to find out a suitable mirror.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Staging DOs DON'Ts

[Kimmo Paasiala]

Could we have this as an example what not to in the Makefile. It is
from the latest change to the Makefile of sysutils/kiconvtool.


MAKE_ARGS= PREFIX=${STAGEDIR}${PREFIX}

This breaks stuff that edits scripts in place trying to replace paths
that depend on the value of PREFIX.

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

www/w3m fails to build under stable/10 r256624 i386

[Kimmo Paasiala]

The error message I'm getting is

cc  -I. -I. -O2 -pipe -fno-strict-aliasing -I./libwc
-I/usr/include/openssl -I/usr/local/include -I/usr/local/include
-DHAVE_CONFIG_H -DAUXBIN_DIR=\/usr/local/libexec/w3m\
-DCGIBIN_DIR=\/usr/local/libexec/w3m/cgi-bin\
-DHELP_DIR=\/usr/local/share/w3m\  -DETC_DIR=\/usr/local/etc\
-DCONF_DIR=\/usr/local/etc/w3m\  -DRC_DIR=\~/.w3m\
-DLOCALEDIR=\/usr/local/share/locale\ -c main.c
main.c:836:23: error: assigning to 'GC_warn_proc' (aka 'void (*)(char
*, GC_word)') from incompatible type 'void'
orig_GC_warn_proc = GC_set_warn_proc(wrap_GC_warn_proc);
  ^ ~~~
main.c:2264:37: warning: incompatible pointer types passing 'char **'
to parameter of type 'wc_uchar **' (aka 'unsigned char **')
[-Wincompatible-pointer-types]
return wc_any_to_ucs(wtf_parse1(p));
^~
./libwc/wtf.h:71:41: note: passing argument to parameter 'p' here
extern wc_wchar_t wtf_parse1(wc_uchar **p);
^
1 warning and 1 error generated.
*** Error code 1

Stop.
make[1]: stopped in /wrkdirs/usr/ports/www/w3m/work/w3m-0.5.3
*** Error code 1

Anyone else seeing this? www/w3m is quite an important port because
it's required to build devel/git.

Full build log at pastebin:

http://pastebin.com/TZCxYLar

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

Re: www/w3m fails to build under stable/10 r256624 i386

[Kimmo Paasiala]

On Fri, Oct 18, 2013 at 11:50 PM, Boris Samorodov b...@passap.ru wrote:
 18.10.2013 21:55, Kimmo Paasiala пишет:
 The error message I'm getting is

 cc  -I. -I. -O2 -pipe -fno-strict-aliasing -I./libwc
 -I/usr/include/openssl -I/usr/local/include -I/usr/local/include
 -DHAVE_CONFIG_H -DAUXBIN_DIR=\/usr/local/libexec/w3m\
 -DCGIBIN_DIR=\/usr/local/libexec/w3m/cgi-bin\
 -DHELP_DIR=\/usr/local/share/w3m\  -DETC_DIR=\/usr/local/etc\
 -DCONF_DIR=\/usr/local/etc/w3m\  -DRC_DIR=\~/.w3m\
 -DLOCALEDIR=\/usr/local/share/locale\ -c main.c
 main.c:836:23: error: assigning to 'GC_warn_proc' (aka 'void (*)(char
 *, GC_word)') from incompatible type 'void'
 orig_GC_warn_proc = GC_set_warn_proc(wrap_GC_warn_proc);
   ^ ~~~
 main.c:2264:37: warning: incompatible pointer types passing 'char **'
 to parameter of type 'wc_uchar **' (aka 'unsigned char **')
 [-Wincompatible-pointer-types]
 return wc_any_to_ucs(wtf_parse1(p));
 ^~
 ./libwc/wtf.h:71:41: note: passing argument to parameter 'p' here
 extern wc_wchar_t wtf_parse1(wc_uchar **p);
 ^
 1 warning and 1 error generated.
 *** Error code 1

 Stop.
 make[1]: stopped in /wrkdirs/usr/ports/www/w3m/work/w3m-0.5.3
 *** Error code 1

 Anyone else seeing this? www/w3m is quite an important port because
 it's required to build devel/git.

 http://lists.freebsd.org/pipermail/svn-ports-head/2013-October/032845.html

 --
 WBR, Boris Samorodov (bsam)
 FreeBSD Committer, http://www.FreeBSD.org The Power To Serve


Thanks,

I can report that this patch fixes the build of www/w3m on my system.

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

Re: stagedir vs. jail

[Kimmo Paasiala]

I have actually noticed many times earlier that using symlinks for
/usr/ports, /usr/src and the related directories do cause problems,
jails or not.

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

Re: stagedir vs. jail

[Kimmo Paasiala]

On Sun, Oct 13, 2013 at 4:19 PM, Ekkehard Gehm g...@doom-labs.net wrote:
 A quick addition:

 My Jail is buid exactly as discribed in the jail handbook:
 http://www.freebsd.org/doc/handbook/jails-application.html

 So hanging around with this issue because of this staging thing is a bit 
 *argl*

 Cheers,

 Ekki


Why can't you use poudriere as the package builder? Poudriere does not
use any symbolic link tricks and that's why things just work out of
the box.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

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

[Kimmo Paasiala]

On Sat, Oct 12, 2013 at 2:35 PM, Daniel Nebdal dneb...@gmail.com wrote:
 On Sat, Oct 12, 2013 at 11:08 AM, Torfinn Ingolfsen tin...@gmail.com wrote:
 Hello,

 On Sat, Oct 12, 2013 at 10:15 AM, Matthew Seaman matt...@freebsd.org wrote:

 Staging is here to stay.  There's no way of turnng it off.  If the

 Why? Why can't it be turned off?
 What is the technical reason / reasoning behind this design decision?
 And why is staging special, compared to all other features that has
 been introduced to FreeBSD in the last few years?

 --
 Regards,
 Torfinn Ingolfsen

 As I've understood it, it's not so much a feature as an
 infrastructure *change* - asking to disable it is, from now on, about
 as meaningful as asking if you could disable the fetch stage.



Staging solves so many problems with the FreeBSD ports(7) system that
it's very worthwhile to go trough the bumpy road of fixing the
individual ports that don't play well with it. Looking at it now I
hope these developments had happened 5 years earlier but as they say,
better late than never.

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

Re: Explain staging

[Kimmo Paasiala]

On Mon, Oct 7, 2013 at 12:23 PM, Anton Shterenlikht me...@bris.ac.uk wrote:
From: Matthew Seaman m.sea...@infracaninophile.co.uk
To: freebsd-ports@freebsd.org
Subject: Re: Explain staging

On 03/10/2013 08:56, Anton Shterenlikht wrote:
 sorry, I still don't get it.
 What is achived by staging?

There are 4 main advantages:

   1) You can build a port and then create a package from the stage
  directory without having to install it on your build system.  You
  usually don't need root privileges to do this.

 What about make fetch? It puts files by default under
 ports/distfiles, which, by default, is 755:

 $ make fetch
 ===   xearth-1.2 depends on file: /usr/local/sbin/pkg - found
 = xearth-1.2.tar.xz doesn't seem to exist in /usr/ports/distfiles/.
 = /usr/ports/distfiles is not writable by you; cannot fetch.
 *** Error code 1

 Stop.
 make: stopped in /usr/ports/astro/xearth
 $

 What about make extract? Same problem:

 $ make extract
 ===   xearth-1.2 depends on file: /usr/local/sbin/pkg - found
 === Fetching all distfiles required by xearth-1.2 for building
 ===  Extracting for xearth-1.2
 = SHA256 Checksum OK for xearth-1.2.tar.xz.
 mkdir: /usr/ports/astro/xearth/work: Permission denied
 *** Error code 1

 Stop.
 make: stopped in /usr/ports/astro/xearth
 $

 make checksum works, of course, because no files are
 created:

 $ make checksum
 ===   xearth-1.2 depends on file: /usr/local/sbin/pkg - found
 === Fetching all distfiles required by xearth-1.2 for building
 = SHA256 Checksum OK for xearth-1.2.tar.xz.
 $

 Then make stage fails again:

 $ make stage
 ===  Patching for xearth-1.2
 touch: /usr/ports/astro/xearth/work/.patch_done.xearth._usr_local: Permission 
 denied
 *** Error code 1

 Stop.
 make: stopped in /usr/ports/astro/xearth
 $

 So I make it under root.
 Then make check-orphans fail:

 $ make check-orphans
 cannot create /usr/ports/astro/xearth/work/.expanded-plist: Permission denied
 *** Error code 2

 Stop.
 make: stopped in /usr/ports/astro/xearth
 $

 Finally, make package fails:

 $ make package
 ===  Building package for xearth-1.2
 mkdir: /usr/ports/astro/xearth/work/.metadir: Permission denied
 *** Error code 1

 Stop.
 make: stopped in /usr/ports/astro/xearth
 $

 I'm probably missing something important here.
 The wiki page only says: Make sure you tested
 make package as a normal user (not root).
 If that fails, add NEED_ROOT in the port. 
 Why would it not fail?

 Do I need to set up separate distfiles directory,
 or something like this?

   2) Instead of (typically) just running the install target of the
  piece of software, and then trusting that the pkg-plist contains
  an accurate list of what gets installed, now we take the pkg-plist
  and extract the matching items from the stage directory to make a
  package.  Only things on the plist get installed, and things on
  the plist but not present in the staging dir will flag up as an
  error in the port.

 This is not clear either.
 I my port I have:

 PLIST_FILES=bin/xearth \
 lib/X11/xearth/freebsd.committers.markers \
 lib/X11/xearth/freebsd.ftp.markers
 PLIST_DIRS= lib/X11/xearth

 I don't have pkg-plist at all.
 What do I need to change?

If you have an instruction in you port to install a file from the build
area into the filesystem under ${PREFIX} =3D /usr/local then you need to
change it to install to ${STAGEDIR}${PREFIX}/whatever.  Note: this only
applies to the *install* parts: when building the package, you should
configure it for the eventual final install location under /usr/local.

 Does this look right:

 do-install:
 @${INSTALL_PROGRAM} ${WRKSRC}/xearth ${STAGEDIR}${PREFIX}/bin
 @${INSTALL_MAN} ${WRKSRC}/xearth.man ${MANPREFIX}/man/man1/xearth.1
 @${MKDIR} ${STAGEDIR}${PREFIX}/lib/X11/xearth
 # Copy the list of FreeBSD sites  committers locations
 .for marker in freebsd.committers.markers freebsd.ftp.markers
 @${INSTALL_DATA} ${FILESDIR}/${marker} 
 ${STAGEDIR}${PREFIX}/lib/X11/xearth
 .endfor

 Many thanks

 Anton


Set DISTDIR  in make.conf to for example /home/memyself/distfiles and
move the existing distfiles there. There's no reasonable default for
DISTDIR I think if it's assumed that fetch operates as non-root.

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

Re: Explain staging

[Kimmo Paasiala]

On Mon, Oct 7, 2013 at 4:36 PM, Daniel Nebdal dneb...@gmail.com wrote:
 On Mon, Oct 7, 2013 at 2:52 PM, Anton Shterenlikht me...@bris.ac.uk wrote:
 From b...@passap.ru Mon Oct  7 13:36:53 2013

07.10.2013 13:23, Anton Shterenlikht пишет:

 What about make fetch? It puts files by default under
 ports/distfiles, which, by default, is 755:
[...]
 What about make extract? Same problem:

I use svn repo owned by a user for ages. When a root rights are needed,
the ports infrastructure asks for the password.

 I've read a few books on unix security.
 The typical advice is to assume the user
 passwords are compromised.
 If I build and install from a ports tree
 owned by a user, I increase the chances of
 comromising the system, if an attacker
 changes some files in the ports tree,
 i.e. the URL in the Makefile and the checksum
 in distinfo. I'll then have to add this worry
 to my already long list.

 Anton


 If that happens to an account used by an admin, don't you have larger worries?

 Let's say :
 * You have an account with no special privileges, that you typically
 log in with.
 * That account has a ports tree
 * You typically install ports by compiling them as this user, then
 installing them with root privileges.

 If you use sudo, and you haven't used targetpw or something to make it
 ask for a different password, and you haven't set any strong limits on
 it, anyone that got your password would also be able to use sudo to do
 whatever they wanted more directly. So let's assume you're not doing
 that.

 An attacker with your password could meddle with your .profile or
 .cshrc or whatever, and replace your shell with a lookalike that
 logged all input. From there, they could get hold of whatever commands
 and passwords you use to install software, and reuse that to install
 whatever they want directly.  If what you use is sudo, somehow
 restricted to only run make install, and only within that ports tree
 ... again, what would keep an attacker from just modifying any random
 port on the fly, installing it there and then, and then reverting the
 changes to reduce the risk of detection?

 It just seems like leaving a timebomb in the form of a modified ports
 directory would be a fairly inefficient thing to do if they'd already
 gotten that far., and it would run the risk of being overwritten
 and/or detected next time you updated your ports tree.  Of course, if
 you set the ports tree a+w (or, heaven forbid, 0777), you'd be asking
 for trouble ... but that's not new.


 Then again, I might have overlooked something. :)



In my opinion fetching and building (and creating packages if using
staging ) as a non privileged user is always safer than doing the same
things as root. The common advice to security is to AVOID using
admin/root privileges as much as possible to minimize the attack
vectors.

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

Re: poudriere feature suggestion: retry with gcc

[Kimmo Paasiala]

On Fri, Oct 4, 2013 at 1:15 PM, Beeblebrox zap...@berentweb.com wrote:
 I have a pure clang world and no GCC from base (WITHOUT_GCC= yes). The same
 goes for the poudriere build environment.

 When doing massive updates (like the recent pixman-dependent ports), I get a
 number of ports that fail to build. The number of failed + skipped was about
 150 for this run for example. I also have gnome3 merged ports tree. When I
 tried to build the failed ports on host, the compile broke just as it had in
 the poudriere run, but when I re-tried with USE_GCC=4.6, most failed ports
 got built. So it looks like many of the compile breakage is related to not
 having base GCC42 on the system.

 While the gcc - clang shift is on-going, it would be very helpful if
 poudriere.conf had an option to retry only once to compile a failed port
 with the USE_GCC (or several user-defined) flags. So something like:
 RETRY_ONFAIL=yes
 RETRY_FLAGS=USE_GCC NOCCACHE

 Regards.



Why have this only on poudriere? This kind of features belong in the
ports(7) infrastructure if anywhere.

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

Re: Explain staging

[Kimmo Paasiala]

 From that stage a create can be directly created (even as a single user). or 
 the
 stage can be sync into the filesystem.


You probably meant to write: From that stage a *package* can be
directly created ;)

It's easy to understand why this is so useful because the result of
the compilation does not have to be installed for real on the build
host or build jail when the goal is just to create a package and clean
up is lot easier.

Keep up the good work,

-Kimmo


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

Re: portmaster -- preserving added files?

[Kimmo Paasiala]

On Thu, Sep 26, 2013 at 9:25 PM, Scot Hetzel swhet...@gmail.com wrote:
 On Thu, Sep 26, 2013 at 11:35 AM, Gary Aitken free...@dreamchaser.org wrote:
 Is portmaster supposed to retain files which it did not install when 
 updating /
 reinstalling a port?

 For example, jave extensions are normally installed by placing a jar file in
   /usr/local/openjdk6/jre/lib/ext/

 When reinstalling, these are wiped out.
 At least I think that's what happened when I reinstalled.

 Seems like they should be (at least optionally) retained?

 The problem is not with portmaster, as it runs the pkg or pkg_install
 commands to remove the port.  If you have files that are missing after
 uninstalling a port, then you'll need to check what that port is
 doing.  Most likely the port has a @dirrm instead of an @dirrmtry for
 that directory in it's pkg-plist file.

 I had a look at the java/openjdk6/Makefile, and it creates the list of
 directories to remove with @dirrm instead of @dirrmtry.  So it looks
 like the issue is with java/openjdk6 removing that directory.

 Scot


It's a larger problem with no clear solution. What the programs that
install additional files after the initial installation should do is
to use /var/db/xyz for the additional files so that they are contained
in a separate directory alltogether.

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

Re: portmaster -- preserving added files?

[Kimmo Paasiala]

On Thu, Sep 26, 2013 at 10:14 PM, Gary Aitken free...@dreamchaser.org wrote:
 On 09/26/13 12:39, Kimmo Paasiala wrote:
 On Thu, Sep 26, 2013 at 9:25 PM, Scot Hetzel swhet...@gmail.com wrote:
 On Thu, Sep 26, 2013 at 11:35 AM, Gary Aitken free...@dreamchaser.org 
 wrote:
 Is portmaster supposed to retain files which it did not install when 
 updating /
 reinstalling a port?

 For example, jave extensions are normally installed by placing a jar file 
 in
   /usr/local/openjdk6/jre/lib/ext/

 When reinstalling, these are wiped out.
 snip
 The problem is not with portmaster, as it runs the pkg or pkg_install
 commands to remove the port.  If you have files that are missing after
 uninstalling a port, then you'll need to check what that port is
 doing.  Most likely the port has a @dirrm instead of an @dirrmtry for
 that directory in it's pkg-plist file.

 I had a look at the java/openjdk6/Makefile, and it creates the list of
 directories to remove with @dirrm instead of @dirrmtry.  So it looks
 like the issue is with java/openjdk6 removing that directory.
 snip
 It's a larger problem with no clear solution. What the programs that
 install additional files after the initial installation should do is
 to use /var/db/xyz for the additional files so that they are contained
 in a separate directory alltogether.
 snip

 That presumes all additional files are installed via the ports mechanism,
 or at least know about it, which is highly unlikely.  With plugins of
 various types and machine-independent binaries like java .class files
 abounding, requiring every add-on to be installed by the ports mechanism
 isn't likely to work in the long run.

 I can see how a program installed by the ports mechanism should use the
 mechanism you're advocating, but I don't think it applies to all cases.

 In this case, it was a mysql driver, obtained as a binary (.jar of
 java .class files).  But things like gimp plugins have the same issue.

 Gary


I was referring to untracked files that have not been installed via
the ports system or packages. However, it seems impossible to convince
software writers that /usr and /usr/local might be read-only at
run-time :/

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

Re: pkgng: How fix dependences?

[Kimmo Paasiala]

On Wed, Aug 21, 2013 at 3:45 AM, Kevin Oberman rkober...@gmail.com wrote:
 On Tue, Aug 20, 2013 at 1:48 AM, Alex V. Petrov alexvpet...@gmail.comwrote:

 After recomendation (20130731) in ports/UPDATING I have:

 pkg check -d
 graphics/ImageMagick has a missing dependency: devel/gio-fam-backend
 devel/ORBit2 has a missing dependency: devel/gio-fam-backend
 ports-mgmt/packagekit has a missing dependency: devel/gio-fam-backend
 editors/spe has a missing dependency: devel/gio-fam-backend
 databases/akonadi has a missing dependency: devel/gio-fam-backend
   has a missing dependency: devel/gio-fam-backend
 [many skipped]

 I try:
 pkg set -a -o devel/gio-fam-backend:devel/glib20 -y
 Result:
 pkg: sqlite: columns package_id, origin are not unique (pkgdb.c:3605)

 How can I fix the dependence with portmaster or pkgng?
 --
 -
 Alex V. Petrov


 It appears that you failed to follow the instructions in 20130731. Or, it
 is also possible that you used an outdated version of portmaster that did
 the wrong thing, too. I don't use pkgng, so it may have introduced other
 issues.

 Has glib20 been updated to glib-2.36.3? If so, it now has absorbed all of
 the functions of gio-fam-backend. and re-installing any ports that depended
 on gio-fam-backend should do the trick.

 portmaster graphics/ImageMagick devel/ORBit2 ports-mgmt/packagekit
 editors/spe databases/akonadi deskutils/alacarte and others  that depend on
 gio-fam-backend.
 --
 R. Kevin Oberman, Network Engineer
 E-mail: rkober...@gmail.com
 ___

The dependencies are not inherited but copied. In this case ports that
depended on devel/gio-fam-backend via an intermediate dependency
(devel/glib20) will not stop depending on it unless recompiled with
the updated  devel/glib20 that no longer has the dependency to
devel/gio-fam-backend.

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

Re: Searching the port tree with portmaster?

[Kimmo Paasiala]

There's also ports-mgmt/psearch. Works fine for me.

-Kimmo


On Thu, Aug 15, 2013 at 6:45 PM, LuKreme krem...@kreme.com wrote:


 On 15 Aug 2013, at 06:33 , Adam Vande More amvandem...@gmail.com wrote:

  whereis sudo

 Sure, if sudo is installed. Sudo was not installed, so I had to search the
 ports tree for it. Same with openssl.

 I setup an alias

 alias pf='find /usr/ports -maxdepth 2 -type d | grep -i '

 but was afraid I was missing a command in portmaster.

 On 15 Aug 2013, at 00:56 , Sergey V. Dyatko sergey.dya...@gmail.com
 wrote:

  man ports

  /search[enter]

 cd /usr/ports  make search name=pear-
 cd /usr/ports  make search name=pear- xname='ht(tp|ml)'

 Well, OK. That seems a lot more effort, and loses your current directory,
 but that does work. It's fugly though.

 --
 The Drum jealously guarded its reputation as the most stylishly
 disreputable tavern in Ankh-Morpork and the big troll that now guarded
 the door carefully vetted customers for suitability in the way of black
 cloaks, glowing eyes, magic swords and so forth. Rincewind never found
 out what he did to the failures. Perhaps he ate them. --Sourcery

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

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

Re: libpkg, sqlite and database problems prevent building any packages

[Kimmo Paasiala]

On Mon, Aug 5, 2013 at 1:42 PM, Thomas Mueller
mueller6...@bellsouth.net wrote:
 I have smaller FreeBSD 9.1-STABLE and 9.2-BETA2 installations that I update 
 less frequently than the main hard-drive installation.

 On the USB-stick installations, I find I can't upgrade or build any ports 
 because of a database mess.  I get error messages mentioning sqlite even for 
 packages that don't depend on sqlite3.

 I tried to build or upgrade devel/subversion, ports-mgmt/pkg, 
 databases/sqlite3 and ports-mgmt/portmaster, and get error messages every 
 time like

 === Starting check for runtime dependencies
 === Gathering dependency list for ports-mgmt/pkg from ports
 pkg-static: warning: database version 19 is newer than libpkg(3) version 12, 
 but still compatible
 pkg-static: sqlite: no such column: infos (pkgdb.c:1086)
 === No dependencies for ports-mgmt/pkg

 pkg-static: warning: database version 19 is newer than libpkg(3) version 12, 
 but still compatible
 pkg-static: sqlite: no such column: infos (pkgdb.c:1086)
 pkg-static: warning: database version 19 is newer than libpkg(3) version 12, 
 but still compatible
 pkg-static: sqlite: no such column: infos (pkgdb.c:1086)
 ===  Installing for pkg-1.1.4_1
 ===   Generating temporary packing list
 ===  Checking if ports-mgmt/pkg already installed
 pkg-static: warning: database version 19 is newer than libpkg(3) version 12, 
 but still compatible
 pkg-static: sqlite: no such column: infos (pkgdb.c:1086)
 *** [check-already-installed] Error code 74

 Stop in /BETA1/usr/ports/ports-mgmt/pkg.
 *** [/BETA1/usr/ports/ports-mgmt/pkg/worki386/.install_done.pkg._usr_local] 
 Error code 1

 Stop in /BETA1/usr/ports/ports-mgmt/pkg.

 === Installation of pkg-1.1.4_1 (ports-mgmt/pkg) failed
 === Aborting update

 === Update for ports-mgmt/pkg failed
 === Aborting update

 === Update for converters/libiconv failed
 === Aborting update

 === Update for devel/gettext failed
 === Aborting update

 === Update for devel/gmake failed
 === Aborting update

 === Update for devel/icu failed
 === Aborting update

 === Killing background jobs
 Terminated

 === You can restart from the point of failure with this command line:
portmaster flags databases/sqlite3 devel/icu devel/gmake 
 devel/gettext converters/libiconv ports-mgmt/pkg

 === Exiting


 I also get messages even when running pkg, this is the new pkgng.

 You might want to see my /etc/make.conf .

 Main hard drive installation:


 PORTSDIR=/BETA1/usr/ports
 PACKAGES=/usr/packages
 WRKDIR=${.CURDIR}/work9amd64
 # WITH_NEW_XORG=yes
 # WITH_KMS=yes
 WITH_PKGNG=yes
 OPTIONS_SET=DOCS NLS
 mpop_SET=GNUTLS NLS
 # added by use.perl 2013-06-16 03:51:03
 PERL_VERSION=5.16.3


 for USB-stick installation with 9.2-BETA2 amd64:


 PORTSDIR=/BETA1/usr/ports
 PACKAGES=/usr/packages
 WRKDIR=${.CURDIR}/workusb64
 WITH_PKGNG=yes
 OPTIONS_SET.mpop=GNUTLS NLS
 # added by use.perl 2012-09-23 09:49:32
 PERL_VERSION=5.14.2


 for USB-stick installation with 9.1-STABLE i386:


 PORTSDIR=/BETA1/usr/ports
 PACKAGES=/usr/packages
 WRKDIR=${.CURDIR}/worki386
 # WITH_NEW_XORG=yes
 # WITH_KMS=yes
 WITH_PKGNG=yes
 OPTIONS_SET=DOCS NLS
 # WITHOUT_MODULES= usb/ulpt # This does not work
 SRC_BASE=/STABLE1/usr/src
 # added by use.perl 2013-06-17 12:56:10
 PERL_VERSION=5.16.3


 I know there was a major change in database format when subversion was 
 updated in ports from 1.7 to 1.8, but would this cause the problems that are 
 driving me crazy?  There ought to be a way to resolve this, but I can't see 
 what to do, everything I try leads to the same error messages.

 Tom



This has nothing to do with subversion. Your pkg(8) client  is out of
date compared to the /var/db/pkg/local.sqlite database.

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

Re: libpkg, sqlite and database problems prevent building any packages

[Kimmo Paasiala]

On Mon, Aug 5, 2013 at 5:03 PM, Matthew Seaman matt...@freebsd.org wrote:
 On 05/08/2013 14:30, Thomas Mueller wrote:
 I could see my pkg client is out of date, but how do I update it?

 Attempts to update all gave me those error messages.  Installation fails.

 Your package database has got into an inconsistent state.  pkg(8) is
 attempting to auto-update the schema to the latest version, but failing
 because it's trying to remove an 'infos' column from a table where that
 column has apparently already been removed.  (Likely this situation has
 come about because pkg got killed in the middle of doing this update
 previously.)

 How happy are you to get down'n'dirty with the source code and running
 SQL from the command line?  If you look at the updates pkg is attempting
 to run shown here:

https://github.com/freebsd/pkg/blob/master/libpkg/private/db_upgrades.h

 would you be capable of looking at the DB schema, working out which of
 those updates had been applied, aplying any outstanding ones by hand and
 then setting the user version to 19 by:

sql PRAGMA user_version = 19 ;

 ?

 If not, check in /var/backups for a good copy of your local.sqlite
 database and try and restore from there.  Unfortunately, there's no
 guarantee that any backup copy doesn't have the same inconsistencies as
 your live copy.

 We need to make pkg(8) databases more resilient to the effects of SIGHUP
 or similar while they are elbows-deep in the bowels of the DB schema...

 Cheers,

 Matthew






Ok this is then different problem than what I saw when I reverted back
from pkg-devel to pkg, the error message was the same though.

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

Re: UPDATING entry for devel/glib20 does not match names of installed packages of the port.

[Kimmo Paasiala]

On Fri, Aug 2, 2013 at 4:07 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Wed, Jul 31, 2013 at 11:43 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
 The installed package is named as 'glib-2.34.3'. This won't match the
 'glib20' string in the UPDATING entry and 'pkg updating' misses the
 UPDATING entry.

 -Kimmo

 Anyone else notice this? Does ports-mgmt/portaudit work differently
 than 'pkg audit' in this case?

 -Kimmo

Sorry 'pkg updating' vs. the old 'pkg_updating' of course. I'm
surprised no one else has noticed this, the UPDATING entry for
devel/glib20 is surely an important one?

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

Re: Error validating server certificate for 'https://svn0.us-east.freebsd.org:443':

[Kimmo Paasiala]

On Fri, Aug 2, 2013 at 11:10 AM, Anton Shterenlikht me...@bris.ac.uk wrote:
 # svn up /usr/ports/
 Updating '/usr/ports':
 Error validating server certificate for 
 'https://svn0.us-east.freebsd.org:443':
  - The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
  - The certificate hostname does not match.
 Certificate information:
  - Hostname: svnmir.ysv.FreeBSD.org
  - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT
  - Issuer: clusteradm, FreeBSD.org, (null), CA, US (cluster...@freebsd.org)
  - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61
 (R)eject, accept (t)emporarily or accept (p)ermanently?

 What's going on?

 Thanks

 Anton


The DNS name for the SVN mirror was changed a few days ago into a
CNAME that points to svnmir.ysv.FreeBSD.org and it no longer matches
the certificate that you have saved on your system, hence the
complaint. It's safe to accept the new cert.

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

Re: Error validating server certificate for 'https://svn0.us-east.freebsd.org:443':

[Kimmo Paasiala]

On Fri, Aug 2, 2013 at 11:19 AM, Anton Shterenlikht me...@bris.ac.uk wrote:
 From kpaas...@gmail.com Fri Aug  2 09:18:52 2013

On Fri, Aug 2, 2013 at 11:10 AM, Anton Shterenlikht me...@bris.ac.uk wrote:
 # svn up /usr/ports/
 Updating '/usr/ports':
 Error validating server certificate for 
 'https://svn0.us-east.freebsd.org:443':
  - The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
  - The certificate hostname does not match.
 Certificate information:
  - Hostname: svnmir.ysv.FreeBSD.org
  - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT
  - Issuer: clusteradm, FreeBSD.org, (null), CA, US (cluster...@freebsd.org)
  - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61
 (R)eject, accept (t)emporarily or accept (p)ermanently?

 What's going on?

 Thanks

 Anton


The DNS name for the SVN mirror was changed a few days ago into a
CNAME that points to svnmir.ysv.FreeBSD.org and it no longer matches
the certificate that you have saved on your system, hence the
complaint. It's safe to accept the new cert.

-Kimmo

 ok, great, thanks for clarifying this.

 Anton

Np.

You can always check the fingerprints of the certificates manually if
there's any lingering doubt :)

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

Re: Idea for Mk/Uses snippet

[Kimmo Paasiala]

On Thu, Aug 1, 2013 at 2:59 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Thu, Aug 1, 2013 at 2:03 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
 There are quite a few ports that require system sources to be present
 at /usr/src.

 Would it make sense to create Mk/Uses snippet (for example named as
 Mk/Uses/system-sources) that checks for let's say /usr/src/Makefile
 and throws an error if the file is not present?

 A port that requires the system sources to be present (for example
 sysutils/lsof) could then just say:

 USES= ... system-sources ..

 What do you think?

 -Kimmo

 Something as simple as this:

 .if !defined(_INCLUDE_USES_SYSTEM_SOURCES_MK)
 _INCLUDE_USES_SYSTEM_SOURCES_MK= yes


 .if !exists(${SRC_BASE}/Makefile)
 IGNORE= This port requires the system sources installed at ${SRC_BASE}
 .endif

 .endif

 Is there still a need to check for kernel sources separately? I would
 imagine that everyone checks out the whole src tree now.

 -Kimmo

Ok, I hadn't read the porter's handbook before I wrote the above and
the handbook suggests that kernel sources should be checked as:

.if !exists(${SRC_BASE}/sys/Makefile)
IGNORE= requires kernel sources to be installed
.endif

Do ports actually depend on the full system sources or is it just the
kernel sources part under ${SRC_BASE}/sys ?

If it's only the kernelt this could still be turned into
Mk/Uses/kernel-sources.mk snippet to avoid repeating the above for
every port that needs the kernel sources.

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

UPDATING entry for devel/glib20 does not match names of installed packages of the port.

[Kimmo Paasiala]

The installed package is named as 'glib-2.34.3'. This won't match the
'glib20' string in the UPDATING entry and 'pkg updating' misses the
UPDATING entry.

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

Re: www/rubygem-passenger now requires bash?

[Kimmo Paasiala]

On Tue, Jun 11, 2013 at 5:04 PM, Steve Wills swi...@freebsd.org wrote:
 I'm running FreeBSD/amd64 8-STABLE (r250276) and, yesterday, updated
 www/rubygem-passenger from 3.0.19 to 4.0.5 via portmaster.  Although the
 port upgraded without error, the resultant Passenger no longer works: it
 complains it can't find bash and Rails apps won't spawn.

 I don't have shells/bash installed, and didn't need to with version 3.0.19
 of the www/rubygem-passenger port.  The shells/bash port isn't listed as a
 runtime dependency for www/rubygem-passenger in its Makefile, either.

 If I install shells/bash and also put a symlink from /usr/bin/bash to
 /usr/local/bin/bash then Passenger will run once again.  I don't like this
 solution, though.  Does anyone know of a way of running the Passenger
 4.0.5 port without needing bash?

 I've included at the end a snippet from httpd-error.log showing the
 behaviour of the new Passenger 4.0.5 prior to the workaround I put in
 place mentioned in the preceding paragraph.

 I think it only calls bash like that when it crashes, so that it can
 generate a crash report of some kind and possibly submit it somewhere. As
 far as the crash, I'm told it's a bug in our C++ stuff and that upgrading
 to 9-STABLE should help, although I haven't had time to test that. If you
 try that, please let us know how it goes.

 Steve


My experience is that it needs bash to run in the first place, I
couldn't get the apache module working at all until I installed
shells/bash and symlinked /bin/bash to /usr/local/bin/bash.

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

Re: poudriere, pkgng, memcache and php upgrades

[Kimmo Paasiala]

On Mon, Jun 10, 2013 at 12:37 PM, bw.mail.lists bw.mail.li...@gmail.com wrote:
 We use memcache with php. When php gets updated, memcache gets rebuilt by
 poudriere, but pkgng doesn't see it as being different on 'pkg upgrade' so
 it doesn't upgrade the package. Which means that on apache restart the error
 log contains:

 PHP Warning:  PHP Startup: Unable to load dynamic library
 '/usr/local/lib/php/20100525/memcache.so' -
 /usr/local/lib/php/20100525/memcache.so: Undefined symbol
 quot;php_session_create_idquot; in Unknown on line 0
 PHP Warning:  PHP Startup: Unable to load dynamic library
 '/usr/local/lib/php/20100525/memcached.so' -
 /usr/local/lib/php/20100525/memcached.so: Undefined symbol
 quot;ps_globalsquot; in Unknown on line 0

 'pkg upgrade -f' solves the problem, but is there maybe another way?


There's no version number bump on the memcache port so the new package
is not seen as newer than the installed version.

I wish there was an elegant solution other than force the dependant
ports have their version numbers bumped every time the dependency (the
php port) gets updated.
-Kimmo
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Is latest portsnap snapshot corrupted?

[Kimmo Paasiala]

On Tue, May 28, 2013 at 12:15 AM, Bruce Cran br...@cran.org.uk wrote:
 On 27/05/2013 22:13, Gökşin Akdeniz wrote:

 Ia am not a dev, but portstree snapshot is fixed. Simply run

 '# portsnap fetch extract  portsdb -u'

 and you will get a fresh snapshot of ports tree.


 Is '# portsnap fetch update' not sufficient? It seemed to work here.

 --
 Bruce Cran


The portsdb tool is not part of the base system if anyone is
wondering, it comes from ports-mgmt/portupgrade. Not everyone is using
portupgrade so if you post any instructions like this make sure you
mention the extra tools involved and what they relate to.

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

Re: The vim port needs a refresh

[Kimmo Paasiala]

On Sat, May 25, 2013 at 12:23 AM, Kenta Suzumoto ken...@hush.com wrote:

 Hello all. The editors/vim port is currently a mess and needs some changes.

 - It fetches almost 700 patches from what seems like a dial-up connection in 
 AUSTRALIA.

 You might as well be downloading a 1080p movie from a rock in the north pole, 
 because that's about how fast it is.
 This can be very easily avoided by putting all the patches into a single 
 tarball and hosting it anywhere decent. I've
 seen someone in ##freebsd on freenode handing out a tarball with all the 
 patches many times, and everyone asks
 why isn't this the default? why is some random guy giving me distfiles? 
 etc. Seems like a no-brainer.

 - By default, it builds lots of gui stuff that certainly almost no one wants

 It almost seems like the vim-lite port should be renamed vim and the vim port 
 should be renamed gvim. I had to
 google to come up with this solution, because I can't even disable that stuff 
 in make config (another problem!)

 .if ${.CURDIR}==/usr/ports/editors/vim
 WITH_VIM_OPTIONS=yes
 WITHOUT_X11=yes
 .endif

 People shouldn't have to find this hack to be able to install vim normally 
 (and no, telling them to use vim-lite isn't normal).
 I'm surprised that none of these changes have been made yet. I've heard it's 
 because the maintainer won't listen to reason
 but I have no way to know if that's the case or not. I also heard bapt@ had 
 an optionsNG patch that he wouldn't
 integrate into the port for some reason. Please, let's get this stuff fixed 
 once and for all. None of it requires a large amount
 of work on anyone's part.

 P.S. we're now at 7.3.1011 - the port could use a normal update as well. 
 /minor complaint

 - kenta


As far as I know FreeBSD does not roll custom distfiles because of
very obvious issues with authenticity of the files. If you create a
custom distfile from let's say editors/vim as you suggest then who is
going to trust you to provide authentic sources of someone else's
work? Now when everything is separate and downloadable and verifiable
individually from the upstream vendor there's no problem with
authenticity.

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

Re: The vim port needs a refresh

[Kimmo Paasiala]

On Sat, May 25, 2013 at 1:29 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Sat, May 25, 2013 at 12:23 AM, Kenta Suzumoto ken...@hush.com wrote:

 Hello all. The editors/vim port is currently a mess and needs some changes.

 - It fetches almost 700 patches from what seems like a dial-up connection in 
 AUSTRALIA.

 You might as well be downloading a 1080p movie from a rock in the north 
 pole, because that's about how fast it is.
 This can be very easily avoided by putting all the patches into a single 
 tarball and hosting it anywhere decent. I've
 seen someone in ##freebsd on freenode handing out a tarball with all the 
 patches many times, and everyone asks
 why isn't this the default? why is some random guy giving me distfiles? 
 etc. Seems like a no-brainer.

 - By default, it builds lots of gui stuff that certainly almost no one wants

 It almost seems like the vim-lite port should be renamed vim and the vim 
 port should be renamed gvim. I had to
 google to come up with this solution, because I can't even disable that 
 stuff in make config (another problem!)

 .if ${.CURDIR}==/usr/ports/editors/vim
 WITH_VIM_OPTIONS=yes
 WITHOUT_X11=yes
 .endif

 People shouldn't have to find this hack to be able to install vim normally 
 (and no, telling them to use vim-lite isn't normal).
 I'm surprised that none of these changes have been made yet. I've heard it's 
 because the maintainer won't listen to reason
 but I have no way to know if that's the case or not. I also heard bapt@ had 
 an optionsNG patch that he wouldn't
 integrate into the port for some reason. Please, let's get this stuff fixed 
 once and for all. None of it requires a large amount
 of work on anyone's part.

 P.S. we're now at 7.3.1011 - the port could use a normal update as well. 
 /minor complaint

 - kenta


 As far as I know FreeBSD does not roll custom distfiles because of
 very obvious issues with authenticity of the files. If you create a
 custom distfile from let's say editors/vim as you suggest then who is
 going to trust you to provide authentic sources of someone else's
 work? Now when everything is separate and downloadable and verifiable
 individually from the upstream vendor there's no problem with
 authenticity.

 -Kimmo

One way around the problem that would not compromise authenticity
would be adding support for wrapper distfiles (if there's not already
something like that) that combine all distfiles of one port into one
tarball that  gets extracted to $DISTDIR before the distfile
verification takes place.

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

Re: png problem with tar on 8.x

[Kimmo Paasiala]

On Wed, May 15, 2013 at 12:30 AM, Albert Shih albert.s...@obspm.fr wrote:
 Hi everyone

 Just a report for a bug on 8.x about png ports


 ---  Upgrading 'png-1.5.14' to 'png-1.5.15' (graphics/png)
 ---  Building '/usr/ports/graphics/png'
 ===  Cleaning for png-1.5.15
 ===  Found saved configuration for png-1.4.1_1
 === Fetching all distfiles required by png-1.5.15 for building
 ===  Extracting for png-1.5.15
 = SHA256 Checksum OK for libpng-1.5.15.tar.xz.
 tar: Unrecognized archive format
 tar: Error exit delayed from previous errors.
 *** Error code 1

 it's « normal » because xz is not supported with tar from FreeBSD 8.x

 Regards.

 JAS

 --
 Albert SHIH
 DIO bâtiment 15
 Observatoire de Paris
 5 Place Jules Janssen
 92195 Meudon Cedex
 France
 Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71
 xmpp: j...@obspm.fr
 Heure local/Local time:
 mar 14 mai 2013 23:29:53 CEST
 ___

Check what the fetched file actually contains. If you're behind a
forced proxy that inserts a standard page for failed http requests the
file you get will contain that page in html and the fetch(1) will
succeed but the contents of the file will be wrong of course.

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

Re: png problem with tar on 8.x

[Kimmo Paasiala]

On Wed, May 15, 2013 at 12:51 AM, Albert Shih albert.s...@obspm.fr wrote:
  Le 15/05/2013 ? 00:40:58+0300, Kimmo Paasiala a écrit
 On Wed, May 15, 2013 at 12:30 AM, Albert Shih albert.s...@obspm.fr wrote:
  Hi everyone
 
  Just a report for a bug on 8.x about png ports
 
 
  ---  Upgrading 'png-1.5.14' to 'png-1.5.15' (graphics/png)
  ---  Building '/usr/ports/graphics/png'
  ===  Cleaning for png-1.5.15
  ===  Found saved configuration for png-1.4.1_1
  === Fetching all distfiles required by png-1.5.15 for building
  ===  Extracting for png-1.5.15
  = SHA256 Checksum OK for libpng-1.5.15.tar.xz.
  tar: Unrecognized archive format
  tar: Error exit delayed from previous errors.
  *** Error code 1
 
  it's « normal » because xz is not supported with tar from FreeBSD 8.x
 
  Regards.
 
  JAS
 
  --
  Albert SHIH
  DIO bâtiment 15
  Observatoire de Paris
  5 Place Jules Janssen
  92195 Meudon Cedex
  France
  Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71
  xmpp: j...@obspm.fr
  Heure local/Local time:
  mar 14 mai 2013 23:29:53 CEST
  ___

 Check what the fetched file actually contains. If you're behind a
 forced proxy that inserts a standard page for failed http requests the
 file you get will contain that page in html and the fetch(1) will
 succeed but the contents of the file will be wrong of course.

 I'm not sure to understand you...

 The file is perfectly clean

 On 8.2 :

 [root ~]# tar jtvf libpng-1.5.15.tar.xz
 tar: Unrecognized archive format
 tar: Error exit delayed from previous errors.
 [root ~]#

 on 9-stable

 [root ~]$ tar jtvf libpng-1.5.15.tar.xz
 drwxr-xr-x  0 glennrp visitor 0 28 mar 02:21 libpng-1.5.15/
 -rw-r--r--  0 glennrp visitor 35758  5 fév 05:06 libpng-1.5.15/config.sub
 -rw-r--r--  0 glennrp visitor  5403 28 mar 02:21 libpng-1.5.15/pngdebug.h
 -rw-r--r--  0 glennrp visitor 37875 28 mar 02:21 libpng-1.5.15/pngset.c
 -rw-r--r--  0 glennrp visitor  6130 28 mar 02:21 libpng-1.5.15/INSTALL
 -rw-r--r--  0 glennrp visitor 168930 28 mar 02:21 libpng-1.5.15/pngrtran.c
 -rw-r--r--  0 glennrp visitor   8695  6 jan 18:48 libpng-1.5.15/pngtest.png
 -rw-r--r--  0 glennrp visitor  21489 28 mar 02:21 libpng-1.5.15/pngconf.h
 -rw-r--r--  0 glennrp visitor   8572  4 mar 23:32 libpng-1.5.15/Makefile.am
 drwxr-xr-x  0 glennrp visitor  0 28 mar 02:21 libpng-1.5.15/projects/


 Regards.

 JAS
 --
 Albert SHIH
 DIO bâtiment 15
 Observatoire de Paris
 5 Place Jules Janssen
 92195 Meudon Cedex
 France
 Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71
 xmpp: j...@obspm.fr
 Heure local/Local time:
 mar 14 mai 2013 23:47:41 CEST

Sorry I misunderstood the problem.

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

Re: poudriere sillieness re audio/libsamplerate glib20

[Kimmo Paasiala]

On Tue, Apr 9, 2013 at 10:38 AM, Beeblebrox zap...@berentweb.com wrote:
 * One glib20 problem was in devel/qt4-corelib/Makefile
 was USE_GNOME=  _glib20 (instead should be glib20)

 * Another one was in graphics/liblqr-1/Makefile
 was USE_GNOME=  _glib20 pkgconfig  (instead should be glib20 pkgconfig)

 * graphics/colord fails with below, then built manually.
 checking for XML... yes
 checking for SQLITE... no
 configure: error: Package requirements (sqlite3) were not met:
 Package sqlite3 was not found in the pkg-config search path.
 Perhaps you should add the directory containing `sqlite3.pc'

 * x11-toolkits/wxgtk28-common is a bit strange, added to repo after manual
 build but fail message is:
 checking for GTK+ version...
 checking for pkg-config... /usr/local/bin/pkg-config
 checking for GTK+ - version = 2.0.0... Package pangox was not found in the
 pkg-config search path.
 Perhaps you should add the directory containing `pangox.pc' to the
 PKG_CONFIG_PATH environment variable Package 'pangox', required by 'world',
 not found
 
 *** The test program failed to compile or link. See the file config.log for
 the
 *** exact error that occured. This usually means GTK+ is incorrectly
 installed.
 configure: error:
 The development files for GTK+ were not found. For GTK+ 2, please ensure
 that pkg-config is in the path and that gtk+-2.0.pc is installed.

 * When poudriere is re-started, it immediately deletes stuff that it somehow
 does not like:
  Deleting colord-0.1.20_1.txz: missing dependencies
  Deleting libsoup-2.42.0.txz: missing dependencies
  Deleting wxgtk2-common-2.8.12_1.txz: missing dependencies
 Running the above 3 with poudriere -vv provides no additional info
 I'll post more debug results later.




 -
 10-Current-amd64-portstree merged with marcuscom.gnome3  xorg.devel
 --
 View this message in context: 
 http://freebsd.1045724.n5.nabble.com/poudriere-sillieness-re-audio-libsamplerate-glib20-tp5802508p5802539.html
 Sent from the freebsd-ports mailing list archive at Nabble.com.

How do you know it's supposed to be glib20 and not _glib20? To me it
looks like you're just messing around with lots of stuff that you
don't quite yet understand. Evenmore you haven't shown anything that
would point to a problem in poudriere itself.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Growing list of required(ish) ports

[Kimmo Paasiala]

On Mon, Apr 8, 2013 at 10:57 AM, Michael Gmelin free...@grem.de wrote:
 On Mon, 8 Apr 2013 09:31:50 +0200
 David Demelier demelier.da...@gmail.com wrote:


 For me I also wanted pkg to be in base but they made a bootstrap that
 does not need any other requirement so I stick with that and I'm
 happy.


 Last time I checked the bootstrapping mechanism installed an outdated
 version of pkg (1.0.2 while 1.0.9 was current in ports).


 Cheers,

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






The outdated version is simple to update, that's the whole point of it
staying in ports.

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

Poudriere-devel version 3.0.99.20130327 loads zfs kernel modules even with NO_ZFS set.

[Kimmo Paasiala]

Hi,

I couldn't find a more suitable list(s) for this so apologies.

I really like the ability of building packages using poudriere-devel
without having to use a ZFS pool by using NO_ZFS in the config file.
However there seems to be a small glitch in the implementation, the
zfs.ko and opensolaris.ko kernel modules get always loaded when the
poudriere bulk build is started because it seems to try to figure out
if a ZFS pool exists on the system by running zpool(8) regardless of
NO_ZFS setting. If NO_ZFS is set in poudriere.conf the zpool(8)
command should not be run at all.

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

Re: [CFT] add a config.site cache for the ports

[Kimmo Paasiala]

On Wed, Mar 20, 2013 at 12:17 AM, Kevin Oberman rkober...@gmail.com wrote:
 On Mon, Mar 18, 2013 at 10:41 AM, Baptiste Daroussin b...@freebsd.orgwrote:

 Hi,

 The autotools allows us to have a config.site cache where we define our
 defaults
 values for a couple of things, and prevent the slow and possibly wrong
 autodetection.

 Here is a patch that makes use of it:
 http://people.freebsd.org/~bapt/autotools_config_site.diff

 As the libiconv/gettext update has shown the configure scripts can fall
 back on
 gnu version of commands first if it find it, and in case gettext is
 removed you
 can get trouble.

 In this config.site, I hardcoded a couple of FreeBSD binaries in order to
 always
 use them, but I let the toolchain being autodetected.

 I also added a couple of headers to avoid useless checks and more can be
 added
 in the futur.

 Any thought?


 If this can be made to work reliably with provisions for exceptions, this
 would be absolutely wonderful!
 --

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

Re: OPTIONSng: Overide options in /var/db/ports/*/options ?

[Kimmo Paasiala]

On Sun, Mar 17, 2013 at 5:42 PM, Marco Steinbach
c...@executive-computing.de wrote:
 Matthew Seaman wrote on 17.03.2013 14:49:

 On 17/03/2013 12:16, Marco Steinbach wrote:

 Hi,

 is there a way to overide options stored in /var/db/ports/*/options,
 basically getting back the pre-OPTIONSng behaviour of being able to
 overide port options in /etc/make.conf ?

 Before OPTIONSng was introduced, I was able to specify options in
 /etc/make.conf (WITHOUT_X11, WITHOUT_CUPS, WITH_MAILHEAD, WITH_SSL,
 WITH_MYSQL, WITH_DOVECOT, ...), which then overode any occurency of that
 option in any port (or just specific ones, by e.g. checking .CURDIR),
 regardless of the setting the ports option file contained.


 Find the uniquename of the port[*] (by 'make -V UNIQUENAME') then in
 /etc/make.conf

 uniquename_SET= FOO BAR BAZ
 uniquename_UNSET= BLURFL

 will override the default settings in that port's Makefile for the FOO,
 BAR, BAZ and BLURFL options.

 Note: this won't override any settings you make from an options dialog.
 Might be a good idea to 'make rmconfig' if you only want to rely on
 /etc/make.conf


 [...]

 Exactly my point.  Currently, with OPTIONSng there seems to be no way to
 overide anything in /var/db/ports/*/options.

 I find it irritating, that I no longer can be sure about options in
 /etc/make.conf.  I have to check/reconfigure to make sure.

 As much as I like OPTIONSng (especially in combination with dialog4ports),
 this is one thing I'd very much like OPTIONSng to relearn: Enforce options
 regardless of what's in a ports options file.

 Enforcing invalid multi/single/radio option combinations may be a possible
 pitfall, but that's catched by OPTIONSng, and the build simply stops.





I use poudriere with a configuration where all of the stored
/var/db/ports options are thrown away after compilation. I have all
the settings I want to set in /usr/local/etc/poudrire.d/make.conf
instead.

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

Re: pam_ssh_agent_auth: ENOENT

[Kimmo Paasiala]

On Mon, Feb 25, 2013 at 7:50 PM, Stefan Bethke s...@lassitu.de wrote:

 Am 20.02.2013 um 16:34 schrieb Kimmo Paasiala kpaas...@gmail.com:

 On Wed, Feb 6, 2013 at 12:28 AM, Stefan Bethke s...@lassitu.de wrote:

 I can confirm that with the new port version on a two day old current, the 
 module doesn't work:
 $ uname -a
 FreeBSD freebsd-current.lassitu.de 10.0-CURRENT FreeBSD 10.0-CURRENT #0 
 r246283: Sun Feb  3 16:55:16 CET 2013 
 r...@freebsd-current.lassitu.de:/usr/obj/usr/src/sys/GENERIC  amd64
 $ pkg info|grep pam
 pam_ssh_agent_auth-0.9.4   PAM module which permits authentication via 
 ssh-agent
 $ sudo ls
 sudo: unable to initialize PAM: No error: 0

 If I downgrade to the previous port version (and apply Kimmo's patch), 
 it's working properly.


 Here's a slightly different error message on 9-stable:
 $ uname -a
 FreeBSD diesel.lassitu.de 9.1-STABLE FreeBSD 9.1-STABLE #7 r245996: Sun Jan 
 27 22:36:05 CET 2013 r...@diesel.lassitu.de:/usr/obj/usr/src/sys/DIESEL 
  amd64
 stb@diesel:~$ sudo ls
 sudo: unable to initialize PAM: No such file or directory

 Latest version pam_ssh_agent_auth-0.9.4_1 seems to finally work
 without any extra patches when built on a 9.1-RELEASE system.

 Hhm, with a 9.1-stable from this morning, I'm still getting ENOENT.  Can you 
 spot anything different in my setup?


 My /usr/local/etc/pam.d/sudo looks like this:
 #
 # PAM configuration for the sudo service
 #

 # auth
 authsufficient  /usr/local/lib/pam_ssh_agent_auth.so 
 file=~/.ssh/authorized_keys
 authinclude system

 # account
 account include system

 # session
 # XXX: pam_lastlog (used in system) causes users to appear as though
 # they are no longer logged in in system logs.
 session requiredpam_permit.so

 # password
 passwordinclude system

 /var/log/messages reports:
 Feb 25 17:41:01 lokschuppen sudo: in openpam_load_module(): no 
 /usr/local/lib/pam_ssh_agent_auth found
 Feb 25 17:41:01 lokschuppen sudo:  stb : unable to initialize PAM : No 
 such file or directory ; TTY=pts/0 ; PWD=/root/eisenboot ; USER=root ; 
 COMMAND=/bin/ls
 # ls -l /usr/local/lib/pam_ssh_agent_auth.so
 -rwxr-xr-x  1 root  wheel  100194 Feb 25 08:48 
 /usr/local/lib/pam_ssh_agent_auth.so*
 # pkg_info|grep pam_ssh
 pam_ssh_agent_auth-0.9.4_1 PAM module which permits authentication via 
 ssh-agent
 # ldd /usr/local/lib/pam_ssh_agent_auth.so
 /usr/local/lib/pam_ssh_agent_auth.so:
 libcrypto.so.6 = /lib/libcrypto.so.6 (0x801214000)
 libutil.so.9 = /lib/libutil.so.9 (0x8015bc000)
 libpam.so.5 = /usr/lib/libpam.so.5 (0x8017cf000)
 libcrypt.so.5 = /lib/libcrypt.so.5 (0x8019d7000)
 libc.so.7 = /lib/libc.so.7 (0x80081b000)

 What other reasons could PAM have to report ENOENT?

 This is the same configuration that used to work with the earlier version.


 Stefan

 --
 Stefan Bethke s...@lassitu.de   Fon +49 151 14070811



Looks like the port is still broken if compiled on a 9-STABLE system
with new vis(3) functions included. Compiling it on a 9.1-RELEASE
system produces a working package. I use devel/poudriere-devel for
compiling packages and I didn't test the port by compiling it
manually.

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

Re: stable/9 r245439 breaks security/pam_ssh_agent_auth on stable/9 (WAS: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9)

[Kimmo Paasiala]

On Wed, Feb 6, 2013 at 12:28 AM, Stefan Bethke s...@lassitu.de wrote:

 Am 05.02.2013 um 23:06 schrieb Stefan Bethke s...@lassitu.de:

 Am 05.02.2013 um 19:09 schrieb Kimmo Paasiala kpaas...@gmail.com:

 On Tue, Feb 5, 2013 at 12:36 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Sun, Feb 3, 2013 at 7:22 PM, Chris Rees cr...@freebsd.org wrote:
 On 3 February 2013 17:15, Stefan Bethke s...@lassitu.de wrote:

 Am 03.02.2013 um 10:57 schrieb Chris Rees cr...@freebsd.org:

 On 3 February 2013 03:55, Kimmo Paasiala kpaas...@gmail.com wrote:

 There is no PR yet with my fix and therefor no commit to ports tree
 that would fix the problem. I'll file a PR soon (TM).

 The problem was in base, and is fixed there.

 Huh? With -current r246283, I still get a segfault from sudo unless I 
 have Kimmo's patch.

 Is there some confusion about which problem is addressed by Kimmo's 
 patch?


 Hm, perhaps it might be necessary then.

 Kimmo, please would you submit the patch you had as a PR?  I'm sure
 Wesley would appreciate the hint.

 Chris

 I'll file a PR when I have recovered from a nasty flu. Right now I'm
 not fit for thinking...

 I changed the title of this thread to a better one.

 -Kimmo

 It looks like the port was updated just recently to a new version that
 has its own problems that are no longer related strnvis(3). I'll have
 to give up for now.

 (freebsd-ports added to cc:)

 I can confirm that with the new port version on a two day old current, the 
 module doesn't work:
 $ uname -a
 FreeBSD freebsd-current.lassitu.de 10.0-CURRENT FreeBSD 10.0-CURRENT #0 
 r246283: Sun Feb  3 16:55:16 CET 2013 
 r...@freebsd-current.lassitu.de:/usr/obj/usr/src/sys/GENERIC  amd64
 $ pkg info|grep pam
 pam_ssh_agent_auth-0.9.4   PAM module which permits authentication via 
 ssh-agent
 $ sudo ls
 sudo: unable to initialize PAM: No error: 0

 If I downgrade to the previous port version (and apply Kimmo's patch), it's 
 working properly.


 Here's a slightly different error message on 9-stable:
 $ uname -a
 FreeBSD diesel.lassitu.de 9.1-STABLE FreeBSD 9.1-STABLE #7 r245996: Sun Jan 
 27 22:36:05 CET 2013 r...@diesel.lassitu.de:/usr/obj/usr/src/sys/DIESEL  
 amd64
 stb@diesel:~$ sudo ls
 sudo: unable to initialize PAM: No such file or directory


 Stefan

 --
 Stefan Bethke s...@lassitu.de   Fon +49 151 14070811




Latest version pam_ssh_agent_auth-0.9.4_1 seems to finally work
without any extra patches when built on a 9.1-RELEASE system.

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

Re: ports include /etc/src.conf? i.e. graphics/libfpx

[Kimmo Paasiala]

On Wed, Feb 13, 2013 at 3:33 PM, Tom Evans tevans...@googlemail.com wrote:
 On Wed, Feb 13, 2013 at 12:30 PM, Yamaya Takashi
 yama...@kbh.biglobe.ne.jp wrote:
 On 2013/02/13 19:08, O. Hartmann wrote:
 Setting only base system source compiler optins in /etc/src.conf, for
 instance

 #
 CXXFLAGS+=  -stdlib=libc++
 CXXFLAGS+=  -std=c++11


 which do NOT appear in /etc/make.conf, make building port
 grahpics/libfpx complaining about unrecognized compiler options.

 As far a sI know, /etc/src.conf is ONLY for building the source tree of
 the operating system and make.conf is supposed to contain all stuff
 necessary for compiling both world and ports, but /etc/src.conf is world
 only.

 Am I wrong?

 Oliver

 Yes.
 Because files/Makefile.bsd includes bsd.lib.mk,
 /etc/src.conf is included.



 src.conf(5) says:

   The only purpose of src.conf is to control the compilation of the FreeBSD
   source code, which is usually located in /usr/src.

 Cheers

 Tom

If this is taken literally then could it be said that ports that use
bsd.lib.mk are broken because they are using makefile includes from
the source tree?

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

Re: how to move 9.1 ports to HEAD?

[Kimmo Paasiala]

On Fri, Feb 8, 2013 at 10:17 PM, Anton Shterenlikht me...@bristol.ac.uk wrote:
 From bf1...@googlemail.com Fri Feb  8 17:33:09 2013

I don't think it's true.
While still on 9.1 ports, the latest
entry in UPDATING was (well I lost it now)
about NOV-2012. I believe the revision was
also substantially lower.
  
AS soon as I switched to head,
the latest entry in UPDATING is from
6-FEB-2013 and the revision is 311942.
  
Or maybe I misunderstood you?
 
  You do.  :-)
  The local _subversion repository_ (I know I'm using 
 incorrent
  terminology) has a revision number: r##.  Which is the same
  across different versions of FreeBSD.
  The individual ports _maintained within that repository_ 
 have
  their individual ports numbers (e.g. libreoffice-3.6.5) ... which
  also does not vary with the FreeBSD release.  One can have
  libreoffice-3.6.5 and libreoffice 3.5.4 - but those are two separate
  ports and both work (or should) on 8.3, 9.1, and -CURRENT.  If a
  port has a minimum (or maximum) release of the OS it supports, there
  a mechanism for figuring that out and DTRT.
 
  Or did I misunderstand you?

 Yes, it is now branched, and he was probably using the equivalent of:

 http://svnweb.FreeBSD.org/ports/branches/RELENG_9_1_0/

 rather than

 http://svnweb.FreeBSD.org/ports/head/

 By the way, Anton, you may wish to use https:// rather than svn:// --
 slightly less efficient, but more secure.

 yes, got it, cool!

 root@zzz:/root # svn info /usr/ports/
 Path: /usr/ports
 Working Copy Root Path: /usr/ports
 URL: https://svn0.us-east.freebsd.org/ports/head
 Repository Root: https://svn0.us-east.freebsd.org/ports
 Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
 Revision: 311950
 Node Kind: directory
 Schedule: normal
 Last Changed Author: eadler
 Last Changed Rev: 311950
 Last Changed Date: 2013-02-08 19:18:40 + (Fri, 08 Feb 2013)

 root@zzz:/root #

 Does svn://svn.freebsd.org/base/head
 support https too?

 Thanks

 Anton



Just to repeat what others have tried to tell you. The ports tree is
NOT branched. The branches/RELENG_9_1_0 thing is a tag in subversion
terminology, a read only-snapshot of head from the time the release
was made that will never be updated.

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

Re: how to move 9.1 ports to HEAD?

[Kimmo Paasiala]

On Fri, Feb 8, 2013 at 10:45 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Fri, Feb 8, 2013 at 10:17 PM, Anton Shterenlikht me...@bristol.ac.uk 
 wrote:
 From bf1...@googlemail.com Fri Feb  8 17:33:09 2013

I don't think it's true.
While still on 9.1 ports, the latest
entry in UPDATING was (well I lost it now)
about NOV-2012. I believe the revision was
also substantially lower.
  
AS soon as I switched to head,
the latest entry in UPDATING is from
6-FEB-2013 and the revision is 311942.
  
Or maybe I misunderstood you?
 
  You do.  :-)
  The local _subversion repository_ (I know I'm using 
 incorrent
  terminology) has a revision number: r##.  Which is the same
  across different versions of FreeBSD.
  The individual ports _maintained within that repository_ 
 have
  their individual ports numbers (e.g. libreoffice-3.6.5) ... which
  also does not vary with the FreeBSD release.  One can have
  libreoffice-3.6.5 and libreoffice 3.5.4 - but those are two 
 separate
  ports and both work (or should) on 8.3, 9.1, and -CURRENT.  If a
  port has a minimum (or maximum) release of the OS it supports, 
 there
  a mechanism for figuring that out and DTRT.
 
  Or did I misunderstand you?

 Yes, it is now branched, and he was probably using the equivalent of:

 http://svnweb.FreeBSD.org/ports/branches/RELENG_9_1_0/

 rather than

 http://svnweb.FreeBSD.org/ports/head/

 By the way, Anton, you may wish to use https:// rather than svn:// --
 slightly less efficient, but more secure.

 yes, got it, cool!

 root@zzz:/root # svn info /usr/ports/
 Path: /usr/ports
 Working Copy Root Path: /usr/ports
 URL: https://svn0.us-east.freebsd.org/ports/head
 Repository Root: https://svn0.us-east.freebsd.org/ports
 Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
 Revision: 311950
 Node Kind: directory
 Schedule: normal
 Last Changed Author: eadler
 Last Changed Rev: 311950
 Last Changed Date: 2013-02-08 19:18:40 + (Fri, 08 Feb 2013)

 root@zzz:/root #

 Does svn://svn.freebsd.org/base/head
 support https too?

 Thanks

 Anton



 Just to repeat what others have tried to tell you. The ports tree is
 NOT branched. The branches/RELENG_9_1_0 thing is a tag in subversion
 terminology, a read only-snapshot of head from the time the release
 was made that will never be updated.

 -Kimmo

Actually I'm talking slightly rubbish here, the tags are in the tags/*
part of the repository, for example
http://svn.freebsd.org/ports/tags/RELEASE_9_1_0. The
branches/RELENG_9_1_0 thing is a proper branch but since there's no
announcement of what it should used for I would guess it's someone's
test branch.

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

Re: stable/9 r245439 breaks security/pam_ssh_agent_auth on stable/9 (WAS: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9)

[Kimmo Paasiala]

On Tue, Feb 5, 2013 at 12:36 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Sun, Feb 3, 2013 at 7:22 PM, Chris Rees cr...@freebsd.org wrote:
 On 3 February 2013 17:15, Stefan Bethke s...@lassitu.de wrote:

 Am 03.02.2013 um 10:57 schrieb Chris Rees cr...@freebsd.org:

 On 3 February 2013 03:55, Kimmo Paasiala kpaas...@gmail.com wrote:

 There is no PR yet with my fix and therefor no commit to ports tree
 that would fix the problem. I'll file a PR soon (TM).

 The problem was in base, and is fixed there.

 Huh? With -current r246283, I still get a segfault from sudo unless I have 
 Kimmo's patch.

 Is there some confusion about which problem is addressed by Kimmo's patch?


 Hm, perhaps it might be necessary then.

 Kimmo, please would you submit the patch you had as a PR?  I'm sure
 Wesley would appreciate the hint.

 Chris

 I'll file a PR when I have recovered from a nasty flu. Right now I'm
 not fit for thinking...

 I changed the title of this thread to a better one.

 -Kimmo

It looks like the port was updated just recently to a new version that
has its own problems that are no longer related strnvis(3). I'll have
to give up for now.

(freebsd-ports added to cc:)

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

Re: can't find pkgng command

[Kimmo Paasiala]

On Thu, Jan 17, 2013 at 9:09 PM, Chip Camden
sterl...@camdensoftware.com wrote:
 Quoth John Marino on Thursday, 17 January 2013:
 pkg which filename

 On 1/17/2013 15:08, Robert Huff wrote:
 
  Under the old package system pkg_info -Wfilename' would
  tell me what port a file belonged to.
  Perhaps due to not enough sleep, I have read the man page twice
  but am unable to construct an equivalent.  Will someone please help
  me not have to re-invent the wheel?
 
  Respectfully,
 
 
  Robert Huff
 
  ___
  freebsd-ports@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-ports
  To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

 And if you (a) don't want to type in the full path or (b) want to make
 sure that the file you execute actually does come from the port, you can
 use a double-which.  E.g.,

 $ pkg which `which ruby`
 /usr/local/bin/ruby was installed by package ruby-1.8.7.371,1

 while OTOH...

 $ pkg which `which clang`
 /usr/bin/clang was not found in the database




That is expected, the base system (/bin /usr/bin etc.) is not included
in the pkg database.

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

Re: Why delete KDE3 ports?

[Kimmo Paasiala]

On Mon, Jan 7, 2013 at 4:43 PM, John Marino freebs...@marino.st wrote:
 On 1/7/2013 15:22, Mikhail T. wrote:

 On 07.01.2013 03:33, freebsd-ports-requ...@freebsd.org wrote:

 portname: accessibility/kdeaccessibility
 description: Accessibility applications for KDE
 maintainer:po...@freebsd.org
 deprecated because: Depends on QT3; unmaintained
 expiration date: 2013-07-01
 build errors: none.

 overview:http://portsmon.FreeBSD.org/portoverview.py?category=accessibilityportname=kdeaccessibility

 Once again a working port (no build errors) is scheduled for deletion on
 the grounds of simply being unmaintained.

 Please, reconsider deleting this and other KDE-3 ports.


 I don't normally agree with Mikhail's rants to save old ports, but in the
 case of KDE-3, I am inclined to share his view.

 Are KDE-3 ports causing any problems?  I don't know if KDE-3 is still be
 developed upstream, but if it's not it doesn't really need much maintenance.

 John


I'm asking this on behalf of the port maintainers so they don't have
to. I'm not a committer nor a maintainer of any ports myself fyi.

Are you willing to step up as the maintainer of the KDE3 ports? Or
anyone else reading this? The situation with ports like KDE3 is that
they are lots of work to keep up in shape and if no one wants to
maintain them they succumb to what is called bitrot very quickly
when something changes in dependent ports or in the base system.

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

Re: pkg_libchk and lib/compat (was: Re: Notes on upgrades after libpcre update)

[Kimmo Paasiala]

On Sat, Jan 5, 2013 at 9:22 AM, Boris Samorodov b...@passap.ru wrote:
 05.01.2013 09:09, Kevin Oberman пишет:

 pkg_libchk does not count old libraries in
 the compat folder, so it will still report the problem ports even
 though you use '-w'.

 Are you sure? From PKG_LIBCHK(1):
 -
 DESCRIPTION
  The pkg_libchk script uses pkg_info(1), ldd(1) and readelf(1) to check
  whether a package is linked against missing libraries or libraries
 resid-
  ing in /usr/local/lib/compat and its subfolders.

 OPTIONS
 [...]
 -n --no-compat
  This deactivates detecting compat libraries in
  /usr/local/lib/compat as missing libraries.
 -

 --
 WBR, Boris Samorodov (bsam)
 FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
 ___

It certainly does look at the compat -directories by default and
that's the correct thing to do.

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

Re: 9.1-RC3: xorg-input-mouse, xfce4-panel

[Kimmo Paasiala]

On Fri, Dec 28, 2012 at 1:51 PM, CeDeROM cede...@tlen.pl wrote:
 On Fri, Dec 28, 2012 at 12:42 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
 You're misunderstanding a few things. There are no release packages
 for any release of FreeBSD. What you have on the install discs are
 just snapshot packages built from the ports tree as it happened (...)

 I know, I hoped 1.7.2 driver or 1.8.1 can get into a port tree before
 packages for 9.1 are built and released. When I applied a patch (some
 structure fields initialization) from 1.7.2 on current 1.7.1 driver
 problem of detection and strange mouse behavior was gone. If 1.7.1
 gets into the packages lots of people will report this issue... thats
 all.

 Best regards :-)
 Tomek

 --
 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Related to this,

It doesn't look like the FreeBSD ports SVN repository is used to its
full potential. SVN allows branching and creation of experimental
versions of the tree very easily and cheaply, yet all the experimental
repositories references so far are stored in some external
repositories, github or elsewhere.

What gives?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: 9.1-RC3: xorg-input-mouse, xfce4-panel

[Kimmo Paasiala]

On Fri, Dec 28, 2012 at 2:08 PM, CeDeROM cede...@tlen.pl wrote:
 On Fri, Dec 28, 2012 at 1:02 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
 It doesn't look like the FreeBSD ports SVN repository is used to its
 full potential. (...)

 Yea, btw why FreeBSD does not use GIT? I have been using it for some
 time and I have not seen better source code revision utility. GIT is
 really amazing, SVN/CVS seems to be a file revision control, while GIT
 is the source code revision control, this tool surprises me all the
 time with its great features :-)

 --
 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

I would personally use GIT but I'm ok with SVN too. I absolutely hate
CVS :P  My point is really that why not centralise all the development
that happens around the ports tree. The infrastructure is there
already.

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

Re: Problems with devel/apr1 or options_group

[Kimmo Paasiala]

On Thu, Dec 27, 2012 at 3:57 PM, Olli Hauer oha...@freebsd.org wrote:
 On 2012-12-27 09:38, Dewayne Geraghty wrote:
 While trying to build apache22 with ldap, the dependency apr1 passes a 
 --without-ldap flag to apr-util which results in apache
 failing.

 * Background *
 Some 450+ packages are built on a 4 monthly cycle, 149 of these are 
 controlled by ports.conf and built using portmaster. This is the
 second time since 2005 that I've been stuck and would appreciate some 
 advice/guidance whether the problem lies with something in apr
 that I am missing, or the use of ${UNIQUENAME}_SET doesn't work with new 
 OPTIONS_GROUP?

 We used a script to modify our ports.conf to accommodate the new optionng 
 _SET and _UNSET which worked nicely last time ports were
 built.

 These are the relevant options from ports.conf
 devel/apr1: WITH_THREADS | WITH_BDB | WITH_LDAP | WITHOUT_GDBM | 
 APR1_UNSET=GDBM |  APR1_SET=THREADS BDB LDAP
 [...]

 I suspect here is the mistake
 $ cd devel/apr1
 $ make -V UNIQUENAME
 apr  (- not apr1)

 I don't work with portmaster (happy tinderbox user ;).
 Can you try the following line in your ports.conf

 file ports.conf: devel/apr1: WITH_THREADS | WITH_BDB | WITH_LDAP | 
 WITHOUT_GDBM | APR_UNSET=GDBM |  APR_SET=THREADS BDB LDAP

 --
 Regards,
 olli


Is there any particular reason why the UNIQUENAME couldn't just be the
name of the port in all cases? I would make writing the options in
optionsng format lot easier.

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

Re: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

[Kimmo Paasiala]

On Tue, Dec 11, 2012 at 5:55 PM, Bryan Drewery bdrew...@freebsd.org wrote:
 (As maintainer) I'm proposing to make -w the default for portmaster.
 This will preserve old shared libraries when upgrading. This helps 2 things:

 1. Prevents a broken system during upgrades
 2. Prevents a broken system after upgrading for ports that did not get a
 PORTREVISION bump from a shared library update.

 You have certainly ran into this problem with large library updates such
 as png, pcre, openssl, etc.

 Portupgrade has always done this as default, and I have never seen any
 problems arise from it. It also cleans up prevents duplicated library
 versions. If portmaster is not already doing this, I will ensure it does.

 You could then use pkg_libchk to rebuild any lingering ports if you
 wanted to ensure your system was using the latest. Then cleanout the
 preserved shared library.

 Of course there will be a way to stick to the old default of not
 preserving the libraries.

 Someone may consider this a POLA violation, but I consider that a broken
 system from missing libraries and PORTREVISION bumps is more of a POLA
 violation.


 The other option to ensuring that all ports work correctly after a
 shared library update is to just rebuild any port which recursively is
 affected by another port being updated. I think this is fine in
 scenarios such as tinderbox/poudriere, but with end-user compiling ports
 on their system, this may quickly become too much of a burden.


 Regards,
 Bryan Drewery



Absolutely yes from me. The -w option is real lifesaver and should be
on by default.

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

Re: recent port upgrades causing missing libraries

[Kimmo Paasiala]

On Tue, Dec 11, 2012 at 6:57 PM, Jeremy Messenger
mezz.free...@gmail.com wrote:
 On Tue, Dec 11, 2012 at 10:25 AM, Bryan Drewery bryan-li...@shatow.net 
 wrote:
 On 12/11/2012 10:21 AM, Jeremy Messenger wrote:
 On Tue, Dec 11, 2012 at 9:45 AM, Bryan Drewery bryan-li...@shatow.net 
 wrote:
 On 12/11/2012 9:03 AM, Adam McDougall wrote:
 I used poudriere to build pkgng packages from the latest round
 of port updates since the freeze.  I know in the commit message
 for xcb-util it bumped some other ports, but it seems like not
 enough to make poudriere reinstall enough packages to make things
 work.


 Poudriere does the right thing here, it recompiles all affected ports.

 The pcre upgrade also caused some problems.  I'm sorry that
 I don't have time to make an extensive report of ports vs. libraries
 or a PR but I can add some brief details.  Using pkg install -fR
 on xcb-util and pcre cured the issues for now, but that doesn't mean
 I've caught them all.  pkg_libchk doesn't work with pkgng.  I could
 have told pkg to reinstall all packages but that is a big hammer.

 The problem then comes here, pkgng doesn't automatically know that ports
 have been rebuilt (without PORTREVISION bumps) or that their checksums
 do not match, unless you use pkg install -fR on the proper packages.

 I've written a script that does the same as `portmaster -w`, which will
 preserve old libraries when running `pkg upgrade`, which will at least
 prevent a broken system while you use pkg_libchk to force reinstall
 affected packages:

 https://gist.github.com/3099160

 I don't think the 'portmaster -w' will help with his issue. His issue
 is pretty mess up, because his binaries below have been compiled with
 old and new library at the same time. For some reason, it doesn't
 uninstall (or move when use 'portmaster -w') old libraries first
 before build with new libraries.

 There's no portmaster involved here. I only mention it as an example.
 This is purely pkgng using binary packages.

 He built his own package by using poudriere. The question is that why
 did it allows linked with old and new libraries at the same time? It
 should be uninstall old libraries first before compile/link with new
 libraries.


Poudriere is not the problem here because it builds everything
everytime in a clean jail. The problem is the way pkg-install(8)
detects if a package needs to re-installed, if there's no portrevision
bump it won't re-install the package even if the package has been
linked against new shared libraries.

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

Re: web FreeBSD Ports Search is out of sync

[Kimmo Paasiala]

On Sun, Dec 2, 2012 at 11:47 AM, Matthew Seaman
m.sea...@infracaninophile.co.uk wrote:
 On 02/12/2012 09:32, Ion-Mihai Tetcu wrote:
 If you're running 2.9 OPTIONSng should be handled correctly.  It
  doesn't matter much: the exact format of the OPTIONS variables
  doesn't make much difference to building the INDEX, only detecting
  when they've been changed.

  # pkg info p5-FreeBSD-Portindex
 p5-FreeBSD-Portindex-2.9   Incremental FreeBSD ports INDEX file 
 generation

 So what exactly are you checking WRT option files?

 Basically, just the timestamp on the file.  If it's newer than the last
 time cache-update was run, then the corresponding port needs rechecking.

 Or if there is a new options file.  The 'unknown options file' error
 comes about by comparing the makefiles included from the ports with the
 contents of the /var/db/ports directory.

 ... and thinking about it, after the benefit of sufficient coffee, it's
 now clear to me that logic is incorrect: it can't distinguish between a
 newly created options file and a leftover from a removed port.

 Does no harm, but won't work out that because there's a new options file
 at least one port needs rechecking, or identify the port(s) to recheck.
  I should fix that.

 Cheers,

 Matthew


Hi Matthew,

With the latest 3.0 version of p5-FreeBSD-PortIndex I get an error at
the end of portindex run:

Accumulating dependency information:
.[1000].[2000].[3000].[4000].[5000].[6000].[7000].[8000].[9000].[1].[11000].[12000].[13000].[14000].[15000].[16000].[17000].[18000].[19000].[2]Can't
locate object method accumulate_dependencies via package
FreeBSD::Portindex::Category at
/usr/local/lib/perl5/site_perl/5.14.2/FreeBSD/Portindex/Tree.pm line
815.

No INDEX file is generated.

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

ports/173593

[Kimmo Paasiala]

Hello,

Could someone with commit rights commit a fix to audio/firefly? The PR
is ports/173593.

It' a very simple fix and it's already been approved by the maintainer.

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

Re: ports/173593

[Kimmo Paasiala]

On Wed, Nov 28, 2012 at 5:04 AM, Eitan Adler li...@eitanadler.com wrote:
 On 27 November 2012 21:20, Kimmo Paasiala kpaas...@gmail.com wrote:
 Hello,

 Could someone with commit rights commit a fix to audio/firefly? The PR
 is ports/173593.

 done
 --
 Eitan Adler

Thank you!

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

Re: pkgng woes

[Kimmo Paasiala]

On Fri, Nov 9, 2012 at 2:39 PM, Beeblebrox zap...@berentweb.com wrote:
 @anton
 portmaster --check-depends does not work for me.  Shows everything as fine
 but when I specifically target a port: *# portmaster -i graphics/gimp* for
 example, I get a long list of ports to be installed - meaning not all of the
 existing ports have been registered correctly, hence --check depends will
 not work. Once I re-install all of the missing depends and run the same
 command (*# portmaster -i graphics/gimp*) then there are no problems nor
 list of missing depends.



'portmaster --check-depends' has no equivalent in PKGNG because it
deals directly with the /var/db/pkg/*/+REQUIRED_BY etc. files that are
no longer used when using PKGNG.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: dns/unbound depend

[Kimmo Paasiala]

On Tue, Nov 6, 2012 at 6:05 AM, Darrel levi...@iglou.com wrote:
 i am confused.

 why is cups-client required for dns/unbound ?

 Darrel

It probably comes from dependencies of dns/ldns if you compile it with
DOCS option on which is the default. This should turn it off in
/etc/make.conf:

ldns_UNSET=DOCS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: pkgng: lcms2-2.4 conflicts with lcms-1.19_1,1

[Kimmo Paasiala]

On Mon, Oct 8, 2012 at 6:30 PM, Andriy Gapon a...@freebsd.org wrote:

 Not sure if my environment is messed up or if it is OK, but i have both lcms 
 and
 lcms2 installed, and there is a bunch of packages that depend on them.
 I've been using pkgng for a while now and it never complained about these
 packages, but now it produces the following error:

 Installing lcms2-2.4...
 pkg: lcms2-2.4 conflicts with lcms-1.19_1,1 (installs files into the same 
 place).
 Problematic file: /usr/local/man/man1/jpegicc.1.gz

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

Are they installed from packages built in a clean jail? Many of the
fixes for this type of conflicts only work when the port is built
with the conflicting port already installed. If the ports are built in
a totally clean environment both of the packages will include the the
conflicting files. For an example, see:

http://www.freebsd.org/cgi/query-pr.cgi?pr=171584cat=
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Upgrade java/icedtea-web from 1.2_2 - 1.3 fails: tar: Pathname in pax header can't be converted to current locale

[Kimmo Paasiala]

On Sun, Sep 9, 2012 at 3:33 PM, David Wolfskill da...@catwhisker.org wrote:
 On Sat, Sep 08, 2012 at 07:00:24PM +0300, Kimmo Paasiala wrote:
 ...
 I can extract the tar file on 9-STABLE, my locale settings are the
 defaults for root:

 # locale
 LANG=
 LC_CTYPE=C
 LC_COLLATE=C
 LC_TIME=C
 LC_NUMERIC=C
 LC_MONETARY=C
 LC_MESSAGES=C
 LC_ALL=

 Try unsetting LANG and LC_ALL.
 

 I just tried a further experiment, while running head (@r240235): I
 issued

 tar tvf /usr/ports/distfiles/icedtea-web-1.3.tar.gz

 The error messages are worded slightly differently:

 g1-227(10.0-C)[4] tar -tvf /usr/ports/distfiles/icedtea-web-1.3.tar.gz
 drwxrwxr-x  0 dbhole dbhole  0 Aug 27 12:37 icedtea-web-1.3/
 ...
 drwxrwxr-x  0 dbhole dbhole  0 Aug 27 12:36 
 icedtea-web-1.3/tests/reproducers/signed/Spaces can be everywhere 
 signed/resources/
 tar: Pathname can't be converted from UTF-8 to current locale.
 -rw-rw-r--  0 dbhole dbhole   2421 Aug 27 12:36 
 icedtea-web-1.3/tests/reproducers/signed/Spaces can be everywhere 
 signed/resources/NotOnly spaces can kill 
 \304\233\305\241\304\215\305\231\305\276 too signed.jnlp
 ...
 drwxrwxr-x  0 dbhole dbhole  0 Aug 27 12:36 
 icedtea-web-1.3/tests/reproducers/simple/Spaces can be everywhere/resources/
 tar: Pathname can't be converted from UTF-8 to current locale.
 -rw-rw-r--  0 dbhole dbhole   2388 Aug 27 12:36 
 icedtea-web-1.3/tests/reproducers/simple/Spaces can be 
 everywhere/resources/NotOnly spaces can kill 
 \304\233\305\241\304\215\305\231\305\276 too.jnlp
 ...
 -rw-rw-r--  0 dbhole dbhole   5756 Aug 27 12:36 icedtea-web-1.3/README
 tar: Error exit delayed from previous errors.
 g1-227(10.0-C)[5]


 So the issue appears to be how to handle UTF-8 pathnames on the
 file system in question.

 I'm using a fairly plain UFS with soft updates.

 Peace,
 david
 --
 David H. Wolfskill  da...@catwhisker.org
 Depriving a girl or boy of an opportunity for education is evil.

 See http://www.catwhisker.org/~david/publickey.gpg for my public key.

See if the the file with a UTF-8 filename gets extracted despite the
error message.

I have three different FreeBSD 9 system, one is ZFS and other two are
UFS. I can do 'make extract patch' on all of them for java/icedtea-web
without an error. They all report the same error though if I manually
view or extract the tar file, the files extract fine despite the error
message.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Upgrade java/icedtea-web from 1.2_2 - 1.3 fails: tar: Pathname in pax header can't be converted to current locale

[Kimmo Paasiala]

On Sun, Sep 9, 2012 at 6:12 PM, David Wolfskill da...@catwhisker.org wrote:
 On Sun, Sep 09, 2012 at 04:44:08PM +0300, Kimmo Paasiala wrote:
 $...
  So the issue appears to be how to handle UTF-8 pathnames on the
  file system in question.
 
  I'm using a fairly plain UFS with soft updates.
 ...
 See if the the file with a UTF-8 filename gets extracted despite the
 error message.

 Huh; interesting point.  Yes, it appears that they do:

 g1-227(8.3-S)[12] ls -Fs icedtea-web-1.3/tests/reproducers/signed/Spaces\ 
 can\ be\ everywhere\ signed/resources/
 4 NotOnly spaces can kill ?? too signed.jnlp
 4 Spaces can be everywhere1 signed.jnlp
 4 Spaces can be everywhere2 signed.jnlp
 4 SpacesCanBeEverywhere1signed.jnlp
 4 spaces applet Tests signed.html
 g1-227(8.3-S)[13] ls -Fs icedtea-web-1.3/tests/reproducers/simple/Spaces\ 
 can\ be\ everywhere/resources/
 4 NotOnly spaces can kill ?? too.jnlp
 4 Spaces can be everywhere1.jnlp
 4 Spaces can be everywhere2.jnlp
 4 SpacesCanBeEverywhere1.jnlp
 4 spaces applet Tests.html
 g1-227(8.3-S)[14]

 (The files with names that display as having '?' in their names would be
 the files in question.)

 I have three different FreeBSD 9 system, one is ZFS and other two are
 UFS. I can do 'make extract patch' on all of them for java/icedtea-web
 without an error. They all report the same error though if I manually
 view or extract the tar file, the files extract fine despite the error
 message.

 Hmmm.  How do you do that?  :-}  Even trying a simple approach:

 g1-227(8.3-S)[1] cd /usr/ports/java/icedtea-web/
 g1-227(8.3-S)[2] sudo make
 Password:
 ===  License GPLv2 accepted by the user
 ===  Found saved configuration for icedtea-web-1.2_2
 ===  Extracting for icedtea-web-1.3
 = SHA256 Checksum OK for icedtea-web-1.3.tar.gz.

 IMPORTANT: To build IcedTea-Web 1.3, you have to turn on 'ICEDTEA' option
 for java/openjdk6 (default).  Otherwise, it will neither build nor work.

 tar: Pathname in pax header can't be converted to current locale.
 tar: Pathname in pax header can't be converted to current locale.
 tar: Error exit delayed from previous errors.
 *** Error code 1

 Stop in /common/ports/java/icedtea-web.
 *** Error code 1

 Stop in /common/ports/java/icedtea-web.
 g1-227(8.3-S)[3]


 I *suppose* I could try manually extracting it, then -- using the
 observation that the files actually are extracted -- hack the work/.*
 files to convince the ports infrastructure that the extraction is
 already completed OK, but that's just... wrong.

 Thanks for your help so far!

 Peace,
 david
 --
 David H. Wolfskill  da...@catwhisker.org
 Depriving a girl or boy of an opportunity for education is evil.

 See http://www.catwhisker.org/~david/publickey.gpg for my public key.

Hmm, you're using sudo(1) and that means you enviroment may not be
completely clean. Log on as root using 'su -l' and see if it makes a
difference.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Upgrade java/icedtea-web from 1.2_2 - 1.3 fails: tar: Pathname in pax header can't be converted to current locale

[Kimmo Paasiala]

On Sat, Sep 8, 2012 at 6:52 PM, David Wolfskill da...@catwhisker.org wrote:
 On Sat, Sep 08, 2012 at 05:42:57AM -0700, David Wolfskill wrote:
 I'm not at all clear what I can or should do in order to avoid the
 reported error condition:
 ...
 IMPORTANT: To build IcedTea-Web 1.3, you have to turn on 'ICEDTEA' option
 for java/openjdk6 (default).  Otherwise, it will neither build nor work.

 tar: Pathname in pax header can't be converted to current locale.
 tar: Pathname in pax header can't be converted to current locale.
 tar: Error exit delayed from previous errors.
 *** Error code 1

 Stop in /common/ports/java/icedtea-web.
 *** Error code 1
 

 So I tried unpacking the tarball manually, within script, then grepping
 the typescript to see if that might shed any light on what's causing the
 problem:

 g1-227(8.3-S)[25] grep -A 1 -B 2 '^tar: ' typescript
 x icedtea-web-1.3/tests/reproducers/signed/Spaces can be everywhere signed/
 x icedtea-web-1.3/tests/reproducers/signed/Spaces can be everywhere 
 signed/resources/
 tar: Pathname in pax header can't be converted to current locale.
 x icedtea-web-1.3/tests/reproducers/signed/Spaces can be everywhere 
 signed/resources/NotOnly spaces can kill 
 \304\233\305\241\304\215\305\231\305\276 too signed.jnlp
 --
 x icedtea-web-1.3/tests/reproducers/simple/Spaces can be everywhere/
 x icedtea-web-1.3/tests/reproducers/simple/Spaces can be everywhere/resources/
 tar: Pathname in pax header can't be converted to current locale.
 x icedtea-web-1.3/tests/reproducers/simple/Spaces can be 
 everywhere/resources/NotOnly spaces can kill 
 \304\233\305\241\304\215\305\231\305\276 too.jnlp
 --
 x icedtea-web-1.3/acinclude.m4
 x icedtea-web-1.3/README
 tar: Error exit delayed from previous errors.
 g1-227(8.3-S)[2] exit
 g1-227(8.3-S)[26]

 I suppose that's ... interesting -- but I don't know that I'm all
 that much closer to resolving the issue.

 Does this work for anyone else?

 Peace,
 david
 --
 David H. Wolfskill  da...@catwhisker.org
 Depriving a girl or boy of an opportunity for education is evil.

 See http://www.catwhisker.org/~david/publickey.gpg for my public key.

I can extract the tar file on 9-STABLE, my locale settings are the
defaults for root:

# locale
LANG=
LC_CTYPE=C
LC_COLLATE=C
LC_TIME=C
LC_NUMERIC=C
LC_MONETARY=C
LC_MESSAGES=C
LC_ALL=

Try unsetting LANG and LC_ALL.

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

Re: mplayer-1.1.r20120721 doesn't compile with clang release_30 142614

[Kimmo Paasiala]

On Mon, Sep 3, 2012 at 3:42 PM, Frank Seltzer fran...@bellsouth.net wrote:
 I am experiencing similar problems with mplayer and vlc.


 On Mon, 3 Sep 2012, HU Dong wrote:

 Hi!
The latest multimedia/mplayer port seems to be broken on freebsd
 9.0 i386 release. It fails to compile with clang release_30 142614.
 Hope someone could fix it.

 1. ENV:
 % uname -a
 FreeBSD hostname 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3
 07:15:25 UTC 2012
 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
 % clang --version
 FreeBSD clang version 3.0 (branches/release_30 142614) 20111021
 Target: i386-unknown-freebsd9.0
 Thread model: posix


 Ace /home/frank_s % uname -a
 FreeBSD Ace.nina.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sun Sep  2
 15:28:46 EDT 2012 r...@ace.nina.org:/usr/obj/usr/src/sys/GENERIC  i386

 Ace /home/frank_s % clang --version
 FreeBSD clang version 3.1 (branches/release_31 156863) 20120523

 Target: i386-unknown-freebsd9.0
 Thread model: posix

 Mplayer's compile begins with:

 ===  Configuring for mplayer-1.1.r20120721
 Unknown parameter: --win32codecsdir=/usr/local/lib/win32
 Unknown parameter: --x-libraries=/usr/local/lib
 Unknown parameter: --x-includes=/usr/local/include
 Unknown parameter: --build=i386-portbld-freebsd9.1

 and ends with:


 2 errors generated.
 gmake: *** [mp3lib/decode_i586.o] Error 1
 gmake: *** Waiting for unfinished jobs
 3 warnings generated.
 *** [do-build] Error code 1

 Stop in /usr/ports/multimedia/mplayer.
 *** [build] Error code 1

 Stop in /usr/ports/multimedia/mplayer.
 ** Command failed [exit code 1]: /usr/bin/script -qa
 /tmp/portupgrade20120903-14811-1ifs4ot env UPGRADE_TOOL=portupgrade
 UPGRADE_PORT=mplayer-1.0.r20120322_2 UPGRADE_PORT_VER=1.0.r20120322_2 make
 ** Fix the problem and try again.
 ** Listing the failed packages (-:ignored / *:skipped / !:failed)
 ! multimedia/mplayer (mplayer-1.0.r20120322_2)  (new compiler error)

 with hundreds and hundreds of this type of error in between:


 mp3lib/decode_i586.c:65:23: error: unknown token in expression
 pushl %%eax\n\t
   ^
 inline asm:22:18: note: instantiated into assembly here
 movl 4+(%esp),%edx
 ^
 mp3lib/decode_i586.c:68:23: error: unknown token in expression
 pushl %%eax\n\t
   ^
 inline asm:25:18: note: instantiated into assembly here
 movl 8+(%esp),%eax

 Have I fat-fingered something?

 --
 Frank



Has the building of those ports worked before with clang(1)? There are
still quite a few ports that rely on gcc's pecularities that clang can
not yet do. Use exceptions in /etc/make.conf for ports that fail to
build with clang, for example this is what I have to use for
sysutils/lsof:


.if ${.CURDIR:M*/sysutils/lsof}
CC=gcc
CXX=g++
CPP=gcc -E
.endif
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule

[Kimmo Paasiala]

On Tue, Aug 21, 2012 at 5:45 PM, Lawrence Stewart lstew...@freebsd.org wrote:
 On 08/21/12 17:04, Baptiste Daroussin wrote:
 On Tue, Aug 21, 2012 at 07:05:49AM +0100, Matthew Seaman wrote:
 On 21/08/2012 00:21, Baptiste Daroussin wrote:
 On Tue, Aug 21, 2012 at 12:09:46AM +0300, Vitaly Magerya wrote:
 Baptiste Daroussin b...@freebsd.org wrote:
 Please [...] ask question about pkgng [...]

 What would be the best practice of mixing ports with packages?

 The use case I have in mind is compiling Xorg ports locally
 WITH_NEW_XORG and WITH_KMS, and using packages from
 pkgbeta.freebsd.org for everything else. Is there some mixture of pkg
 and portmaster flags that allows this kind of setup?
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

 There is no best practice for that unfortunatly, (as actually) the best 
 for you
 is maybe to build your own pkgng repostories?
 http://wiki.freebsd.org/PkgPrimer#Using_poudriere for example?

 We are open to suggestion here :)

 At the moment, it is about as tricky as mixing locally compiled ports
 with pkg_tools packages: ie. it might work, or it might leave you a
 quivering, sobbing mess lost in a pit of dark despair.

 One thing that should help is a proposal to record metadata like the SVN
 revision number of the ports tree used to build repository packages into
 the repository catalogue (repo.sqlite), so users can in principle check
 out the same revision locally to build their own ports.  Unfortunately
 no one has written that yet, and its probably too late for it to make it
 into release-1.0.


 yes but it should definitly find its way to 1.1!


 Agreed, though ultimately we want to move to making mixing of ports 
 pkgs idiot-proof - something I suspect we're in better shape to do with
 pkgng. As a recently minted roadtester of pkgng and wanting to do the
 same as Vitaly without setting up Poudriere, I had to reverse engineer
 the ports tree svn revision to make sure I could mix and match from
 pkgbeta and stuff I built locally via ports with WITH_NEW_XORG and
 WITH_KMS. This becomes more annoying to manage going forward.

 So far I'm enjoying my pkgng experience for the most part and wish to
 thank all those involved in getting it to this stage.

 Cheers,
 Lawrence

What would be needed is a mechanism to query a package repository for
a package with both name and options  used to compile the package.
Let's say you have a port installed that requires another port but
that other port must be compiled with a certain option turned on. The
packaging system should be able to tell if the package available from
the remote repository satisfies the requirements or not. The current
system accepts any version of the package because it only looks at the
package name.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule

[Kimmo Paasiala]

On Tue, Aug 21, 2012 at 6:26 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Tue, Aug 21, 2012 at 5:45 PM, Lawrence Stewart lstew...@freebsd.org 
 wrote:
 On 08/21/12 17:04, Baptiste Daroussin wrote:
 On Tue, Aug 21, 2012 at 07:05:49AM +0100, Matthew Seaman wrote:
 On 21/08/2012 00:21, Baptiste Daroussin wrote:
 On Tue, Aug 21, 2012 at 12:09:46AM +0300, Vitaly Magerya wrote:
 Baptiste Daroussin b...@freebsd.org wrote:
 Please [...] ask question about pkgng [...]

 What would be the best practice of mixing ports with packages?

 The use case I have in mind is compiling Xorg ports locally
 WITH_NEW_XORG and WITH_KMS, and using packages from
 pkgbeta.freebsd.org for everything else. Is there some mixture of pkg
 and portmaster flags that allows this kind of setup?
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

 There is no best practice for that unfortunatly, (as actually) the best 
 for you
 is maybe to build your own pkgng repostories?
 http://wiki.freebsd.org/PkgPrimer#Using_poudriere for example?

 We are open to suggestion here :)

 At the moment, it is about as tricky as mixing locally compiled ports
 with pkg_tools packages: ie. it might work, or it might leave you a
 quivering, sobbing mess lost in a pit of dark despair.

 One thing that should help is a proposal to record metadata like the SVN
 revision number of the ports tree used to build repository packages into
 the repository catalogue (repo.sqlite), so users can in principle check
 out the same revision locally to build their own ports.  Unfortunately
 no one has written that yet, and its probably too late for it to make it
 into release-1.0.


 yes but it should definitly find its way to 1.1!


 Agreed, though ultimately we want to move to making mixing of ports 
 pkgs idiot-proof - something I suspect we're in better shape to do with
 pkgng. As a recently minted roadtester of pkgng and wanting to do the
 same as Vitaly without setting up Poudriere, I had to reverse engineer
 the ports tree svn revision to make sure I could mix and match from
 pkgbeta and stuff I built locally via ports with WITH_NEW_XORG and
 WITH_KMS. This becomes more annoying to manage going forward.

 So far I'm enjoying my pkgng experience for the most part and wish to
 thank all those involved in getting it to this stage.

 Cheers,
 Lawrence

 What would be needed is a mechanism to query a package repository for
 a package with both name and options  used to compile the package.
 Let's say you have a port installed that requires another port but
 that other port must be compiled with a certain option turned on. The
 packaging system should be able to tell if the package available from
 the remote repository satisfies the requirements or not. The current
 system accepts any version of the package because it only looks at the
 package name.

By 'any version' I mean 'a package with any combination of options' of
course, bad wording.

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

Re: Get ports tree of the current pkgng repository

[Kimmo Paasiala]

On Thu, Aug 16, 2012 at 10:56 PM, Michael Schnell s-...@s-tlk.org wrote:
 Hi,
 I don't know if this came up already, but not as far as I know. So, I
 was thinking it would be nice to add a mechanism to pkgng, which enables
 the user to get the ports tree corresponding to the current repository.

 At least I've the problem that I really like the idea of the pkgng
 system, but I need a few custom build packages. For instance rawtherapee
 is not working for me with OpenMP, so I have to disable it to get it
 working, or I made some patches for openbox, which of course then needs
 to be compiled. In order to get not in conflict with a more recent
 ports tree the exact version of the repository build would be nice.

 At the moment I can think of two ways to implement it. The easiest way
 would be to add the ports tree as a packages into the repository. A more
 complicated thing is to add a mechanism to portsnap synchronised with
 the pkgng system to direct fetch it, or at least a revision number of
 the current repo, so you can check it out of the subversion.

 How do you guys feel about this?


 Greetings
 Michael


Why not just include the SVN revision of the ports tree that was used
to create the packages in the package metadata?

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

Re: Get ports tree of the current pkgng repository

[Kimmo Paasiala]

On Fri, Aug 17, 2012 at 6:25 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Thu, Aug 16, 2012 at 10:56 PM, Michael Schnell s-...@s-tlk.org wrote:
 Hi,
 I don't know if this came up already, but not as far as I know. So, I
 was thinking it would be nice to add a mechanism to pkgng, which enables
 the user to get the ports tree corresponding to the current repository.

 At least I've the problem that I really like the idea of the pkgng
 system, but I need a few custom build packages. For instance rawtherapee
 is not working for me with OpenMP, so I have to disable it to get it
 working, or I made some patches for openbox, which of course then needs
 to be compiled. In order to get not in conflict with a more recent
 ports tree the exact version of the repository build would be nice.

 At the moment I can think of two ways to implement it. The easiest way
 would be to add the ports tree as a packages into the repository. A more
 complicated thing is to add a mechanism to portsnap synchronised with
 the pkgng system to direct fetch it, or at least a revision number of
 the current repo, so you can check it out of the subversion.

 How do you guys feel about this?


 Greetings
 Michael


 Why not just include the SVN revision of the ports tree that was used
 to create the packages in the package metadata?

 -Kimmo

And of course in the repository metadata as you proposed, sorry not
enough coffee yet :P

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

Re: [CFT] [bsd.port.mk] ports ccache build support

[Kimmo Paasiala]

On Sun, Aug 5, 2012 at 7:18 PM, Eitan Adler li...@eitanadler.com wrote:
 On 5 August 2012 04:15, RW rwmailli...@googlemail.com wrote:
 On Sat, 4 Aug 2012 17:38:44 -0700
 Eitan Adler wrote:

 Why isn't it? In that scenario /var/cache wouldn't be writable.

 IMHO the directories used by the ports system should be predictable
 and static. Which user you happen to be shouldn't affect that choice.

Regardless of what the shared directory is the problem of setting
permissions so that multiple users can share the ccache directory is
something that the ports system shouldn't try to solve. Leave it to
the admin of the system.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org