Re: pkg 1.3.X changed behaviour with pkg -fR xxx

[Kevin Oberman]

On Tue, Jul 29, 2014 at 10:47 PM, Baptiste Daroussin 
wrote:

> On Tue, Jul 29, 2014 at 08:45:32PM -0300, sergio lenzi wrote:
> > see the sequence of commands
> >
> >  pkg info -qr db6
> > results
> > redland-1.0.17_3
> > serf-1.3.6_1
> > subversion-1.8.9_7
> > apr-1.5.1.1.5.3_3
> > squidGuard-1.4_9
> > cyrus-sasl-saslauthd-2.1.26_1
> > evolution-data-server-2.32.1_11
> > bogofilter-1.2.4_2
> > =
> > Now the command
> >
> > pkg install -fR db6
> >
> >
> >
> > Updating repository catalogue
> > DIST64 repository is up-to-date
> > All repositories are up-to-date
> > Checking integrity... done (0 conflicting)
> > The following 1 packages will be affected (of 1037 checked):
> >
> > Installed packages to be REINSTALLED:
> >   db6-6.1.19 (forced reinstall)
> > ===
> > look that it will reinstall db6 (which is correct)
> > but not will reinstall the other packages as the manual says so...
> >
> > Another missing thing is that pkg upgrade
> > will not reinstall the packages that changed options or
> > that changed direct dependencies (as pkg 1.2.X did)...
> >
> > Is it normal or a bug??
> >
> This is a bug can you open a ticket on github?
>
> regards,
> Bapt
>

Wouldn't the FreeBSD bugzilla be a better place?
--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
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: Problem Installing Perl inside Jail with NO_STAGE

[Kevin Oberman]

On Tue, Jul 29, 2014 at 10:22 PM, Kurt Jaeger  wrote:

> Hi!
>
> > is NO_STAGE=yes in /etc/make.conf  a switch or not ?
>
> No, it's not a switch.
>
> --
> p...@opsec.eu+49 171 3101372 6 years to
> go !
>
> And Bapt and pkgng developers have frequently warned that setting
NO_STAGE=yes in make.conf could have disastrous consequences. I really wish
someone had put a "grep NO_STAGE /etc/make.conf" in portmaster and
portupgrade to send a warning that this was a very bad idea.
--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
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 1.3.X changed behaviour with pkg -fR xxx

[Baptiste Daroussin]

On Tue, Jul 29, 2014 at 08:45:32PM -0300, sergio lenzi wrote:
> see the sequence of commands
> 
>  pkg info -qr db6
> results
> redland-1.0.17_3
> serf-1.3.6_1
> subversion-1.8.9_7
> apr-1.5.1.1.5.3_3
> squidGuard-1.4_9
> cyrus-sasl-saslauthd-2.1.26_1
> evolution-data-server-2.32.1_11
> bogofilter-1.2.4_2
> =
> Now the command
> 
> pkg install -fR db6
> 
> 
> 
> Updating repository catalogue
> DIST64 repository is up-to-date
> All repositories are up-to-date
> Checking integrity... done (0 conflicting)
> The following 1 packages will be affected (of 1037 checked):
> 
> Installed packages to be REINSTALLED:
>   db6-6.1.19 (forced reinstall)
> ===
> look that it will reinstall db6 (which is correct)
> but not will reinstall the other packages as the manual says so...
> 
> Another missing thing is that pkg upgrade 
> will not reinstall the packages that changed options or
> that changed direct dependencies (as pkg 1.2.X did)...
> 
> Is it normal or a bug??
> 
This is a bug can you open a ticket on github?

regards,
Bapt


pgpGVWkIX2tOJ.pgp
Description: PGP signature

Re: Problem Installing Perl inside Jail with NO_STAGE

[Kurt Jaeger]

Hi!

> is NO_STAGE=yes in /etc/make.conf  a switch or not ?

No, it's not a switch.

-- 
p...@opsec.eu+49 171 3101372 6 years to go !
___
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: Problem Installing Perl inside Jail with NO_STAGE

[horst leitenmueller]

hi

is NO_STAGE=yes in /etc/make.conf  a switch or not ?

if yes all Makefiles should / have to handle this means ${STAGEDIR} should be 
set correct in case of perl5.16.x
otherwise you have my error 

in the makefile of perl5.16

${INSTALL_DATA} ${WRKDIR}/perl5_version ${STAGEDIR}${PREFIX}/etc
>>> ${FIND} ${STAGEDIR} -name '*.bs' -size 0 -delete
.if ${OSVERSION} >= 900022

if not then NO_STAGE should be described at NOT USABLE at all but with this i 
have problems inside of Jails with a Read Only part
(i will describe my problems with that in a separate mail)


my problem

i just want to update my base systems to newest version of perl (from 5.14 to 
current 5.16 )
and all jails 

and change to new package system pkgng

and perl 5.16 ist not possible to install inside of jails  <=  mail will follow 
with all constellations testet




On 29 Jul 2014, at 15:16, Kurt Jaeger  wrote:

> Hi!
> 
>> i have a problem installing perl inside jail 
> 
> One hint: If you add "NO_STAGE" to a Makefile, this does not
> make this Makefile an "NO_STAGE" Makefile.
> 
> So, again: What is your problem ?
> 
> -- 
> p...@opsec.eu+49 171 3101372 6 years to 
> go !
> ___
> 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: Tor web browser

[Kevin Oberman]

On Tue, Jul 29, 2014 at 12:15 PM, Carlos Jacobo Puga Medina 
wrote:

> On Tue, 29 Jul 2014 14:14:23 +0200
> Kurt Jaeger  wrote:
>
> > Hi!
> >
> > > >
> https://trillian.chruetertee.ch/svn/freebsd-gecko/trunk/www/linux-tor-browser
> > >
> > > Thanks -- is this official ? Is this supposed to be added to the
> > > ports ?
> >
> > I learned that this is the official repository of the gecko@ team:
> >
> > https://wiki.freebsd.org/PortsTeams
> > https://wiki.freebsd.org/Gecko
> >
> > So, someone has to ask them if/when they will add the port ?
>
> If this port is very requested (it's true), yes, why not? Someone could
> try to convince them to merge it into the ports tree. Otherwise, they've a
> powerful reason to not merge it.
>
> >
> > --
> > p...@opsec.eu+49 171 3101372 6 years
> to go !
>
>
Well, for one thing, at least one dependency seems unfetchable due to
security vulnerabilities. I don't know that this is the only issue, but it
kept me from building it.

I, too, would really love to see this. In theory security/tor should do the
trick, but for some time I have been unable to get it to work with privoxy
any more. But gecko@ is the place to ask. I am copying this to them.
--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
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"

pkg 1.3.X changed behaviour with pkg -fR xxx

[sergio lenzi]

see the sequence of commands

 pkg info -qr db6
results
redland-1.0.17_3
serf-1.3.6_1
subversion-1.8.9_7
apr-1.5.1.1.5.3_3
squidGuard-1.4_9
cyrus-sasl-saslauthd-2.1.26_1
evolution-data-server-2.32.1_11
bogofilter-1.2.4_2
=
Now the command

pkg install -fR db6



Updating repository catalogue
DIST64 repository is up-to-date
All repositories are up-to-date
Checking integrity... done (0 conflicting)
The following 1 packages will be affected (of 1037 checked):

Installed packages to be REINSTALLED:
db6-6.1.19 (forced reinstall)
===
look that it will reinstall db6 (which is correct)
but not will reinstall the other packages as the manual says so...

Another missing thing is that pkg upgrade 
will not reinstall the packages that changed options or
that changed direct dependencies (as pkg 1.2.X did)...

Is it normal or a bug??

___
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: Strange pkg_deinstall behaviour with pkgng

[Bryan Drewery]

On 7/29/2014 10:51 AM, Bryan Drewery wrote:
> On 7/29/2014 10:46 AM, Andrea Venturoli wrote:
>> On 07/28/14 20:28, Andrea Venturoli wrote:
>>> Hello.
>>>
>>> I was forced to switch to pkgng on a 9.2 box and I'm now noticing a
>>> strange behaviour.
>>>
>>> Before, "pkg_deinstall -R foo" would deinstall foo and all ports on
>>> which foo depended, except those who were needed by other ports.
>>>
>>> Now, "pkg_deinstall -R foo" will deinstall foo, all ports on which foo
>>> depends and all ports depending on the ports on which foo depends.
>>>
>>> E.g.
>>> Port A depends on B
>>> Port B depends on C
>>> Port D depends on C
>>>
>>> With the old behaviour, "pkg_deinstall -R A" would deinstall A and B
>>> (but not C).
>>> Now it will deinstall A, B, C and D.
>>
>> After some investigation, this broke after the upgrade to pkg 1.3, in
>> which *by default* "pkg delete" seems to be the same as "pkg delete -R".
> 
> Yes, pkg now requires -f to have the old behavior. I'll update
> portupgrade for it.

I have released a quick hack to workaround this by passing in -f. I may
rework it later though and keep the new behavior. pkg_deinstall/pkg_glob
already supports using -f optionally.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: pkg 1.3.3 has a dependency on autoconf to build?

[Baptiste Daroussin]

On Tue, Jul 29, 2014 at 03:21:21PM -0700, Craig Rodrigues wrote:
> Hi,
> 
> I downloaded a FreeBSD-CURRENT VMDK file from
> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/11.0-CURRENT/amd64/20140714/
> 
> and booted it in a brand new VirtualBox VM.
> 
> I then did:
> 
> portsnap fetch
> portsnap extract
> cd /usr/ports/ports-mgmt/pkg
> make
> 
hu

You might have something weird on your system I cannot reproduce

regards,
Bapt


pgpI_gFfAhhyF.pgp
Description: PGP signature

pkg 1.3.3 has a dependency on autoconf to build?

[Craig Rodrigues]

Hi,

I downloaded a FreeBSD-CURRENT VMDK file from
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/11.0-CURRENT/amd64/20140714/

and booted it in a brand new VirtualBox VM.

I then did:

portsnap fetch
portsnap extract
cd /usr/ports/ports-mgmt/pkg
make

I got this:

make: stopped in /usr/ports/ports-mgmt/pkg
root@:/usr/ports/ports-mgmt/pkg # make clean
===>  Cleaning for pkg-1.3.3
root@:/usr/ports/ports-mgmt/pkg # make
===>  License BSD2CLAUSE accepted by the user
===> Fetching all distfiles required by pkg-1.3.3 for building
===>  Extracting for pkg-1.3.3
===>  License BSD2CLAUSE accepted by the user
===> Fetching all distfiles required by pkg-1.3.3 for building
=> SHA256 Checksum OK for pkg-1.3.3.tar.xz.
===>  Patching for pkg-1.3.3
===>  Configuring for pkg-1.3.3
===>   FreeBSD 10 autotools fix applied to
/usr/ports/ports-mgmt/pkg/work/pkg-1.3.3/aclocal.m4
===>   FreeBSD 10 autotools fix applied to
/usr/ports/ports-mgmt/pkg/work/pkg-1.3.3/m4/libtool.m4
===>   FreeBSD 10 autotools fix applied to
/usr/ports/ports-mgmt/pkg/work/pkg-1.3.3/configure
configure: loading site script /usr/ports/Templates/config.site
checking for a BSD-compatible install... /usr/bin/install -c -o root -g
wheel
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p
checking for gawk... (cached) /usr/bin/awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for style of include used by make... GNU
checking for gcc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking whether cc understands -c and -o together... yes
checking dependency style of cc... gcc3
checking for cc option to accept ISO C99... none needed
checking build system type... amd64-portbld-freebsd11.0
checking host system type... amd64-portbld-freebsd11.0
checking how to print strings... printf
checking for a sed that does not truncate output... (cached) /usr/bin/sed
checking for grep that handles long lines and -e... (cached) /usr/bin/grep
checking for egrep... (cached) /usr/bin/egrep
checking for fgrep... (cached) /usr/bin/fgrep
checking for ld used by cc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... (cached) 262144
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... no
checking how to convert amd64-portbld-freebsd11.0 file names to
amd64-portbld-freebsd11.0 format... func_convert_file_noop
checking how to convert amd64-portbld-freebsd11.0 file names to toolchain
format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from cc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... cpp
checking for ANSI C header files... (cached) yes
checking for sys/types.h... (cached) yes
checking for sys/stat.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for memory.h... (cached) yes
checking for strings.h... (cached) yes
checking for inttypes.h... (cached) yes
checking for stdint.h... (cached) yes
checking for unistd.h... (cached) yes
checking for dlfcn.h... (cached) yes
checking for objdir... .libs
checking if cc supports -fno-rtti -fno-exceptions... yes
checking for cc option to produce PIC... -fPIC -DPIC
checking if cc PIC flag -fPIC -DPIC works... yes
checking if cc static flag -static works... yes
checking if cc supports -c -o file.o... yes
checking if cc supports -c -o file.o... (cached) yes
checking whether the cc linker (/usr/bin/ld) supports shared libraries...
yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... freebsd11.0 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build st

Re: Strange pkg_deinstall behaviour with pkgng

[Baptiste Daroussin]

On Tue, Jul 29, 2014 at 11:23:10PM +0200, Gyrd Thane Lange wrote:
> On Tue, 29 Jul 2014 20:41:18 +0200
> Baptiste Daroussin  wrote:
> 
> > On Tue, Jul 29, 2014 at 05:46:40PM +0200, Andrea Venturoli wrote:
> > > On 07/28/14 20:28, Andrea Venturoli wrote:
> > > > Hello.
> > > >
> > > > I was forced to switch to pkgng on a 9.2 box and I'm now noticing
> > > > a strange behaviour.
> > > >
> > > > Before, "pkg_deinstall -R foo" would deinstall foo and all ports
> > > > on which foo depended, except those who were needed by other
> > > > ports.
> > > >
> > > > Now, "pkg_deinstall -R foo" will deinstall foo, all ports on
> > > > which foo depends and all ports depending on the ports on which
> > > > foo depends.
> > > >
> > > > E.g.
> > > > Port A depends on B
> > > > Port B depends on C
> > > > Port D depends on C
> > > >
> > > > With the old behaviour, "pkg_deinstall -R A" would deinstall A
> > > > and B (but not C).
> > > > Now it will deinstall A, B, C and D.
> > > 
> > > After some investigation, this broke after the upgrade to pkg 1.3,
> > > in which *by default* "pkg delete" seems to be the same as "pkg
> > > delete -R".
> > > 
> > >  From what I can tell, there is no flags to "pkg delete" which
> > > makes it act as it used to and as portupgrade expects, so I cannot
> > > easily fix it.
> > > 
> > pkg delete -f is not recursive
> 
> This is true, but is very hard to guess based on the pkg-delete(8) man
> page. My first reading of the options led me to believe that -f was
> an alias for -y and that it would forcefully and recursively delete
> without asking. This could certainly be better worded in the man page.
> -f should explicitly state that it is non-recursive (now that -R is
> implicit and there is no other option to turn it off) and that a
> confirmation is still required, either interactively or through the -y
> option. It was with trepidation that I first used the -f option.
> 
> Also, since the -R option now does nothing, it should either be removed
> or complemented with an -r option (for non-recursive)
> 
> BTW, pkg info use -d for showing dependencies instead of -R (used by
> pkg_info), so the options are different from pkg_tools. Also the
> options are not consistently named across the pkg commands. 
> 
> General gripe about pkg(8): The command structure and options are very
> similar to the previous pkg_tools but with enough changes in options
> and behaviour that it trips up an unwary user. I feel this is a POLA
> violation. It is almost like it is baiting the user into making a
> mistake. Is is similar enough to the old tools that the user think it is
> sufficient to just replace the hyphen with a space (as in pkg-delete and
> pkg delete) but sometimes with subtle changes in options or behaviour,
> most of them with no clear rationale for the change.
> 
> I suppose that the superficial likeness was to make it more familiar
> for existing users of pkg_tools, but since it is not 100% compatible
> (would be better if it was) it would perhaps have been better to make a
> clean break to remove preconceptions about operations.
> 
making a clean break would have made the tool completly rejected, the fact we
were quite closed did the trick to help the project moving to pkg.

regards,
Bapt


pgpJBgHX3GJcm.pgp
Description: PGP signature

Re: Strange pkg_deinstall behaviour with pkgng

[Gyrd Thane Lange]

On Tue, 29 Jul 2014 20:41:18 +0200
Baptiste Daroussin  wrote:

> On Tue, Jul 29, 2014 at 05:46:40PM +0200, Andrea Venturoli wrote:
> > On 07/28/14 20:28, Andrea Venturoli wrote:
> > > Hello.
> > >
> > > I was forced to switch to pkgng on a 9.2 box and I'm now noticing
> > > a strange behaviour.
> > >
> > > Before, "pkg_deinstall -R foo" would deinstall foo and all ports
> > > on which foo depended, except those who were needed by other
> > > ports.
> > >
> > > Now, "pkg_deinstall -R foo" will deinstall foo, all ports on
> > > which foo depends and all ports depending on the ports on which
> > > foo depends.
> > >
> > > E.g.
> > > Port A depends on B
> > > Port B depends on C
> > > Port D depends on C
> > >
> > > With the old behaviour, "pkg_deinstall -R A" would deinstall A
> > > and B (but not C).
> > > Now it will deinstall A, B, C and D.
> > 
> > After some investigation, this broke after the upgrade to pkg 1.3,
> > in which *by default* "pkg delete" seems to be the same as "pkg
> > delete -R".
> > 
> >  From what I can tell, there is no flags to "pkg delete" which
> > makes it act as it used to and as portupgrade expects, so I cannot
> > easily fix it.
> > 
> pkg delete -f is not recursive

This is true, but is very hard to guess based on the pkg-delete(8) man
page. My first reading of the options led me to believe that -f was
an alias for -y and that it would forcefully and recursively delete
without asking. This could certainly be better worded in the man page.
-f should explicitly state that it is non-recursive (now that -R is
implicit and there is no other option to turn it off) and that a
confirmation is still required, either interactively or through the -y
option. It was with trepidation that I first used the -f option.

Also, since the -R option now does nothing, it should either be removed
or complemented with an -r option (for non-recursive)

BTW, pkg info use -d for showing dependencies instead of -R (used by
pkg_info), so the options are different from pkg_tools. Also the
options are not consistently named across the pkg commands. 

General gripe about pkg(8): The command structure and options are very
similar to the previous pkg_tools but with enough changes in options
and behaviour that it trips up an unwary user. I feel this is a POLA
violation. It is almost like it is baiting the user into making a
mistake. Is is similar enough to the old tools that the user think it is
sufficient to just replace the hyphen with a space (as in pkg-delete and
pkg delete) but sometimes with subtle changes in options or behaviour,
most of them with no clear rationale for the change.

I suppose that the superficial likeness was to make it more familiar
for existing users of pkg_tools, but since it is not 100% compatible
(would be better if it was) it would perhaps have been better to make a
clean break to remove preconceptions about operations.

Thanks for reading.

Best regards,
Gyrd ^_^

> 
> 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: PKG 3.1.0 update - Segmentation fault: 11

[Matthew Seaman]

On 27/07/2014 14:22, Michelle Sullivan wrote:
> Unless the fault smashed the stack often you can find what the
> problem/cause was.  If the stack is smashed you're screwed.
> 
> gdb  
> 
> Commands immediately useful:
> 
> backtrace full (alias: bt full)
> frame  for which you want to examine
> if you get a line number/code, 'l' (el) will give the 5 lines eitherside
> If threaded select each thread before the frame to see what was
> happening in each thread.
> 
> If I remember correctly - it's been several years since I last used gdb ;-)
> 
> If you want to catch a smashed stack problem run the binary in gdb:
> 
> gdb 
> 
> Then:
> 
> set args 
> run
> 
> When it faults most of the time you'll get the stack just prior to the
> smashing - though I have had some really bad ones when even gdb cored out..
> 
> If the process forks out, you will need to use follow-fork..

Actually pkg(8) pretty much always forks itself -- run it with the '-d'
flag to prevent that.

However, this particular crash is something we've received plenty of
reports about.  I believe bapt has a fix just about ready, but he's AFK
for a little while.  If you'ld like to help with testing and stuff,
might I suggest joining #pkgng on freenode IRC?

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.

PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matt...@infracaninophile.co.uk



signature.asc
Description: OpenPGP digital signature

Re: PKG 3.1.0 update - Segmentation fault: 11

[Matthew Seaman]

On 27/07/2014 13:30, David Wolfskill wrote:
> Errr...??!?
> 
> I haven't changed /usr/local/etc/pkg.conf at all.

The sample pkg.conf for 1.2.x
(https://github.com/freebsd/pkg/blob/release-1.2/pkg/pkg.conf.sample)
contained some ALIAS definitions, like so:

ALIAS : {
  all-depends: query %dn-%dv,
  annotations: info -A,
  build-depends: info -qd,
  download: fetch,
  iinfo: info -i -g -x,
  isearch: search -i -g -x,
  leaf: query -e "%a == 0" "%n-%v",
  leaf: query -e "%a == 0" "%n-%v",   --
  list: info -ql,
  origin: info -qo,
  provided-depends: info -qb,
  raw: info -R,
  required-depends: info -qr,
  shared-depends: info -qB,
  show: info -f -k,
  size: info -sq,
  }

It's that redefinition of 'leaf' that's causing the mayhem.  Try
deleting the duplicated line.  There will be an update going out ASAP to
cure the crashyness.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.

PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matt...@infracaninophile.co.uk



signature.asc
Description: OpenPGP digital signature

Re: where is CPPTest?

[Carlos Jacobo Puga Medina]

> Don't we have CPPTest in the ports collection? One of the ports I maintain
> will use it in its next release. I only found cppcheck and cppunit...

We don't have it yet as you have seen. I noticed that in OpenBSD is available.

Regards,
-- 
Carlos Jacobo Puga Medina 
___
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: Tor web browser

[Carlos Jacobo Puga Medina]

On Tue, 29 Jul 2014 14:14:23 +0200
Kurt Jaeger  wrote:

> Hi!
> 
> > > https://trillian.chruetertee.ch/svn/freebsd-gecko/trunk/www/linux-tor-browser
> > 
> > Thanks -- is this official ? Is this supposed to be added to the
> > ports ?
> 
> I learned that this is the official repository of the gecko@ team:
> 
> https://wiki.freebsd.org/PortsTeams
> https://wiki.freebsd.org/Gecko
> 
> So, someone has to ask them if/when they will add the port ?

If this port is very requested (it's true), yes, why not? Someone could try to 
convince them to merge it into the ports tree. Otherwise, they've a powerful 
reason to not merge it.

> 
> -- 
> p...@opsec.eu+49 171 3101372 6 years to 
> go !
___
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: Strange pkg_deinstall behaviour with pkgng

[Baptiste Daroussin]

On Tue, Jul 29, 2014 at 05:46:40PM +0200, Andrea Venturoli wrote:
> On 07/28/14 20:28, Andrea Venturoli wrote:
> > Hello.
> >
> > I was forced to switch to pkgng on a 9.2 box and I'm now noticing a
> > strange behaviour.
> >
> > Before, "pkg_deinstall -R foo" would deinstall foo and all ports on
> > which foo depended, except those who were needed by other ports.
> >
> > Now, "pkg_deinstall -R foo" will deinstall foo, all ports on which foo
> > depends and all ports depending on the ports on which foo depends.
> >
> > E.g.
> > Port A depends on B
> > Port B depends on C
> > Port D depends on C
> >
> > With the old behaviour, "pkg_deinstall -R A" would deinstall A and B
> > (but not C).
> > Now it will deinstall A, B, C and D.
> 
> After some investigation, this broke after the upgrade to pkg 1.3, in 
> which *by default* "pkg delete" seems to be the same as "pkg delete -R".
> 
>  From what I can tell, there is no flags to "pkg delete" which makes it 
> act as it used to and as portupgrade expects, so I cannot easily fix it.
> 
pkg delete -f is not recursive

regards,
Bapt


pgpiK7xR652qB.pgp
Description: PGP signature

where is CPPTest?

[Fernando Apesteguía]

Hi all,

Don't we have CPPTest in the ports collection? One of the ports I maintain
will use it in its next release. I only found cppcheck and cppunit...

Thanks in advance.
___
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"

[QAT] 363264: 68x success, 36x deleted, 2x leftovers, 2x ignored: is marked as broken: does not compile with gcc 4.2, 1x depend (ignored: is marked as broken: does not build in japanese/tcl80), 3x ???

[Ports-QAT]

Rename the rather surprising number of japanese/ patch-xy patches
to reflect the files they modify.
-

  Build ID:  20140728221600-48179
  Job owner: ad...@freebsd.org
  Buildtime: 19 hours
  Enddate:   Tue, 29 Jul 2014 17:21:02 GMT

  Revision:  363264
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=363264

-

Port:japanese/Wnn6-lib 2000.9.1_2

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386886/ja-Wnn6-lib-2000.9.1_2.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   DELETED

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386888/ja-Wnn6-lib-2000.9.1_2.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386889/ja-Wnn6-lib-2000.9.1_2.log

-

Port:japanese/Wnn7-lib 2001.10.17_3

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386890/ja-Wnn7-lib-2001.10.17_3.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   DELETED

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386892/ja-Wnn7-lib-2001.10.17_3.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386893/ja-Wnn7-lib-2001.10.17_3.log

-

Port:japanese/ack 1.39_1

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386894/ja-ack-1.39_1.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   DELETED

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386896/ja-ack-1.39_1.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386897/ja-ack-1.39_1.log

-

Port:japanese/another-htmllint 20060601

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386898/ja-another-htmllint-20060601.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   DELETED

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386900/ja-another-htmllint-20060601.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386901/ja-another-htmllint-20060601.log

-

Port:japanese/csrd 1.0_1

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386902/ja-csrd-1.0_1.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   DELETED

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386904/ja-csrd-1.0_1.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386905/ja-csrd-1.0_1.log

-

Port:japanese/e2ps 4.34

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   ???
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386906/ja-e2ps-4.34.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   DELETED

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   ???
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386908/ja-e2ps-4.34.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   ???
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386909/ja-e2ps-4.34.log

-

Port:japanese/esecanna 1.0.1_5

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~ad...@freebsd.org/20140728221600-48179-386910/ja-esecanna-1.0.1_5.log

  Buildgroup: 8.4-QAT

Re: Strange pkg_deinstall behaviour with pkgng

[Bryan Drewery]

On 7/29/2014 10:46 AM, Andrea Venturoli wrote:
> On 07/28/14 20:28, Andrea Venturoli wrote:
>> Hello.
>>
>> I was forced to switch to pkgng on a 9.2 box and I'm now noticing a
>> strange behaviour.
>>
>> Before, "pkg_deinstall -R foo" would deinstall foo and all ports on
>> which foo depended, except those who were needed by other ports.
>>
>> Now, "pkg_deinstall -R foo" will deinstall foo, all ports on which foo
>> depends and all ports depending on the ports on which foo depends.
>>
>> E.g.
>> Port A depends on B
>> Port B depends on C
>> Port D depends on C
>>
>> With the old behaviour, "pkg_deinstall -R A" would deinstall A and B
>> (but not C).
>> Now it will deinstall A, B, C and D.
> 
> After some investigation, this broke after the upgrade to pkg 1.3, in
> which *by default* "pkg delete" seems to be the same as "pkg delete -R".

Yes, pkg now requires -f to have the old behavior. I'll update
portupgrade for it.

> 
> From what I can tell, there is no flags to "pkg delete" which makes it
> act as it used to and as portupgrade expects, so I cannot easily fix it.
> 
> 
> 
> I found the previous behaviour very useful, but if it's gone I'll try
> and (sadly) live with it.
> However I think this is a serious bug: someone might light heartedly
> issue a "pkg_deinstall foo" and expect two or three ports being deleted,
> while in fact it could now deinstall more than half of the installed ports.
> At the very least, an entry in UPDATING should warn about this!!!
> 
> Just my 2c.
> 
>  bye
> av.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: Strange pkg_deinstall behaviour with pkgng

[Andrea Venturoli]

On 07/28/14 20:28, Andrea Venturoli wrote:

Hello.

I was forced to switch to pkgng on a 9.2 box and I'm now noticing a
strange behaviour.

Before, "pkg_deinstall -R foo" would deinstall foo and all ports on
which foo depended, except those who were needed by other ports.

Now, "pkg_deinstall -R foo" will deinstall foo, all ports on which foo
depends and all ports depending on the ports on which foo depends.

E.g.
Port A depends on B
Port B depends on C
Port D depends on C

With the old behaviour, "pkg_deinstall -R A" would deinstall A and B
(but not C).
Now it will deinstall A, B, C and D.


After some investigation, this broke after the upgrade to pkg 1.3, in 
which *by default* "pkg delete" seems to be the same as "pkg delete -R".


From what I can tell, there is no flags to "pkg delete" which makes it 
act as it used to and as portupgrade expects, so I cannot easily fix it.




I found the previous behaviour very useful, but if it's gone I'll try 
and (sadly) live with it.
However I think this is a serious bug: someone might light heartedly 
issue a "pkg_deinstall foo" and expect two or three ports being deleted, 
while in fact it could now deinstall more than half of the installed ports.

At the very least, an entry in UPDATING should warn about this!!!

Just my 2c.

 bye
av.
___
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: Please take my PR before next pkg freeze

[Bartek Rutkowski]

On Tue, Jul 29, 2014 at 3:39 PM, Dreamcat4  wrote:
> Hello there!
>
> If someone can please commit this update in time before the next pkg freeze.
> Then I would be very grateful. Many thanks.
>
> Update "universal-media-server" to 4.0.0 RELEASE
> Redports build success.
> SVN diff on head is attached.
>
> PR Link:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192241
>
> Kind Regards

I'll take it and will commit it after it passes all tests.

Kind regards,
B.R.
___
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"

Please take my PR before next pkg freeze

[Dreamcat4]

Hello there!

If someone can please commit this update in time before the next pkg freeze.
Then I would be very grateful. Many thanks.

Update "universal-media-server" to 4.0.0 RELEASE
Redports build success.
SVN diff on head is attached.

PR Link:

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

Kind Regards
___
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: Problem Installing Perl inside Jail with NO_STAGE

[Kurt Jaeger]

Hi!

> i have a problem installing perl inside jail 

One hint: If you add "NO_STAGE" to a Makefile, this does not
make this Makefile an "NO_STAGE" Makefile.

So, again: What is your problem ?

-- 
p...@opsec.eu+49 171 3101372 6 years to go !
___
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: Basic Question on Staging

[horst leitenmueller]

yes it is

Revision 328096 - (view) (download) (annotate) - [select for diffs] 
Modified Tue Sep 24 06:24:17 2013 UTC (10 months ago) by bapt 
File length: 224 byte(s) 
Diff to previous 327781
Remove NO_STAGE to ports natively stage ready shown by a FORCE_STAGE exp-run

Exp-run by: bdrewery



On 29 Jul 2014, at 14:38, Kurt Jaeger  wrote:

> Hi!
> 
>> example fontsproto-2.1.2  x...@freebsd.org
> 
> It's already staged ?
> 
> -- 
> p...@opsec.eu+49 171 3101372 6 years to 
> go !

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

Problem Installing Perl inside Jail with NO_STAGE

[horst leitenmueller]

hi,

i have a problem installing perl inside jail 


in the makefile of perl5.16

${INSTALL_DATA} ${WRKDIR}/perl5_version ${STAGEDIR}${PREFIX}/etc
>>> ${FIND} ${STAGEDIR} -name '*.bs' -size 0 -delete
.if ${OSVERSION} >= 900022


inside jail if you HAVE to write NO_STAGE this line creates a exception !

find -n not recognised parameter

perhaps a if would be nice here ? 

br horst

PS: reason why NO_STAGE
why i have this set? is easy because inside jails (setup with this guide 
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-application.html)
  staging is not working at all
also discussed here:  
http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086895.html
___
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: Basic Question on Staging

[Kurt Jaeger]

Hi!

> example fontsproto-2.1.2  x...@freebsd.org

It's already staged ?

-- 
p...@opsec.eu+49 171 3101372 6 years to go !
___
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: Tor web browser

[Kurt Jaeger]

Hi!

> > https://trillian.chruetertee.ch/svn/freebsd-gecko/trunk/www/linux-tor-browser
> 
> Thanks -- is this official ? Is this supposed to be added to the
> ports ?

I learned that this is the official repository of the gecko@ team:

https://wiki.freebsd.org/PortsTeams
https://wiki.freebsd.org/Gecko

So, someone has to ask them if/when they will add the port ?

-- 
p...@opsec.eu+49 171 3101372 6 years to go !
___
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: Basic Question on Staging

[Kurt Jaeger]

Hi!

> ===>   NOTICE:
> 
> This port is deprecated; you may wish to reconsider installing it:
> 
> Not staged. See 
> http://lists.freebsd.org/pipermail/freebsd-ports-announce/2014-May/80.html.
> 
> It is scheduled to be removed on or after 2014-08-31.
> 
> which is written on installation a problem when NO_STAGE=yes is
> set in /etc/make.conf?

I do not understand the question. Why would one put NO_STAGE=yes
to /etc/make.conf ? What problem would this solve ?

> causes this the Notice?

I think so, yes.

> why i have this set? is easy because inside jails (setup with
> this guide
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-application.html)
> staging is not working at all

> also discussed here:
> http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086895.html

This was approx. 9 month ago. I guess this already changed in the
meantime, have you tested it again on a recent system ?

> i reread now 5 times https://wiki.freebsd.org/ports/StageDir and
> find no problem with the ports itself?

Depends on the port. Which port are we talking about ?

> if yes would be cool to remove this message, and add a warning
> on start of port upgrade that the NO_STAGE is set

If you tested that it works, submit a PR and the NO_STAGE
setting can be removed from the Makefile ?

-- 
p...@opsec.eu+49 171 3101372 6 years to go !
___
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: Tor web browser

[Thomas Steen Rasmussen]

On 28-07-2014 20:58, Darren Pilgrim wrote:
> On 7/27/2014 12:30 PM, Jerry wrote:
>> Sun, 27 Jul 2014 15:24:21 -0400
>>
>> Is there a port of the "Tor web browser" 
>> available? The site lists one for BSD, but I would prefer to get it
>> via the
>> port's system
> 
> I think the reason it isn't in ports is because it's literally just a
> portable Firefox with a premade profile.  You can replicate it using
> parts already in ports and a few minutes work creating a Firefox profile.

This is incorrect. torbrowser contains a bunch of patches
to the firefox codebase to help anonymity:

https://github.com/flavioamieiro/torbrowser/tree/master/src/current-patches/firefox

A port of torbrowser would make a lot of sense.

/Thomas

___
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: Basic Question on Staging

[horst leitenmueller]

Hi Kurt, 

another question is the warning

===>   NOTICE:

This port is deprecated; you may wish to reconsider installing it:

Not staged. See 
http://lists.freebsd.org/pipermail/freebsd-ports-announce/2014-May/80.html.

It is scheduled to be removed on or after 2014-08-31.


which is written on installation a problem when NO_STAGE=yes is set in 
/etc/make.conf?
causes this the Notice?

why i have this set? is easy because inside jails (setup with this guide 
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-application.html)
  staging is not working at all
also discussed here:  
http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086895.html

i reread now 5 times https://wiki.freebsd.org/ports/StageDir and find no 
problem with the ports itself…
if yes would be cool to remove this message, and add a warning on start of port 
upgrade that the NO_STAGE is set


br horst



On 29 Jul 2014, at 11:03, Kurt Jaeger  wrote:

> Hi!
> 
>> just a short question to staging:
>> 
>> who is porting things handled/maintained by freebsd.org 
>> 
>> example fontsproto-2.1.2  x...@freebsd.org
>> libtool etc
>> and a bunch more
> 
> There's a wiki page which links to the team pages:
> 
> https://wiki.freebsd.org/PortsTeams
> 
> x11@ probably counts as the Xorg team.
> 
>> these are base dependencies for a lot of other packages and i'm
>> not sure who has checked this before writing they will be removed?
>> with end of august
>> 
>> perhaps somebody can explain ...
> 
> Well, we all hope that volunteers spring up and provide patches
> for as many ports as possible from the list of unstaged ports:
> 
> http://people.freebsd.org/~bapt/notstaged.txt
> 
> If you a patch, please submit a PR and some committer tries to
> work with you to get it in the ports tree.
> 
> Yes, we're backlogged/overworked, so the better the PR, the faster
> it can be committed.
> 
> -- 
> p...@opsec.eu+49 171 3101372 6 years to 
> go !
> ___
> 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"

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
deskutils/mirall| 1.6.0   | 1.6.2
+-+
graphics/bmeps  | 3.8.2   | 3.16.0
+-+
multimedia/aegisub  | 3.1.3   | 3.2.0
+-+
net-mgmt/pandorafms_agent   | 4.0.1   | 5.1-140729
+-+
net-mgmt/pandorafms_console | 4.0.1   | 5.1-140729
+-+
net-mgmt/pandorafms_server  | 4.0.1   | 5.1-140729
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.
___
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: Basic Question on Staging

[Kurt Jaeger]

Hi!

> just a short question to staging:
> 
> who is porting things handled/maintained by freebsd.org 
> 
> example fontsproto-2.1.2  x...@freebsd.org
> libtool etc
> and a bunch more

There's a wiki page which links to the team pages:

https://wiki.freebsd.org/PortsTeams

x11@ probably counts as the Xorg team.

> these are base dependencies for a lot of other packages and i'm
> not sure who has checked this before writing they will be removed?
> with end of august
> 
> perhaps somebody can explain ...

Well, we all hope that volunteers spring up and provide patches
for as many ports as possible from the list of unstaged ports:

http://people.freebsd.org/~bapt/notstaged.txt

If you a patch, please submit a PR and some committer tries to
work with you to get it in the ports tree.

Yes, we're backlogged/overworked, so the better the PR, the faster
it can be committed.

-- 
p...@opsec.eu+49 171 3101372 6 years to go !
___
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"

Basic Question on Staging

[horst leitenmueller]

hi all,

just a short question to staging:

who is porting things handled/maintained by freebsd.org 

example fontsproto-2.1.2  x...@freebsd.org
libtool etc
and a bunch more

these are base dependencies for a lot of other packages and i’m not shure who 
has checked this before writing they will be removed… with end of august

perhaps somebody can explain ...


br horst

___
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: pkg create deadlocks and hangs ZFS host

[Michael Gmelin]

> On 29 Jul 2014, at 00:20, Michael Gmelin  wrote:
> 
> 
> 
>>> On 28 Jul 2014, at 23:30, Baptiste Daroussin  wrote:
>>> 
>>> On Mon, Jul 28, 2014 at 09:19:57PM +0200, Michael Gmelin wrote:
>>> I had pkg crash[1] our build host a couple of times today. I could
>>> reproduce the issue on a local machine and opened a detailed bug
>>> report on github[2] which links to a gist containing the patch that's
>>> also attached to this email.
>>> 
>>> - Michael
>>> 
>>> [1] Crash like in "power cycle required".
>>> [2] https://github.com/freebsd/pkg/issues/897
>> 
>> This patch will break pkg register which is used by the ports tree, I'll 
>> work on
>> a better patch
>> 
>> regards,
>> Bapt
> 
> For completeness sake: bapt fixed this properly in
> https://github.com/freebsd/pkg/commit/bf4a9a6ec13824036c035ceba01076e5e30841b4
> 
> 

I would still be interested to know how a small bug in a user land tool can 
bring down the entire server. Is this a (known) ZFS issue?
___
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"