On Wed, Jun 26, 2013 at 09:42:37AM +0400, Andrej Zverev wrote:
Hello, and first please accept my apologies for this situation.
Understood, I just hope this can get addressed/fixed sooner than later,
because what we have right now is reproducible breakage. :-)
pkg_add -r perl (this will
On Tue, Jun 25, 2013 at 11:12:19PM -0700, Jeremy Chadwick wrote:
On Wed, Jun 26, 2013 at 09:42:37AM +0400, Andrej Zverev wrote:
Hello, and first please accept my apologies for this situation.
Understood, I just hope this can get addressed/fixed sooner than later,
because what we have right
On Wed, Jun 26, 2013 at 08:40:52AM +0200, Baptiste Daroussin wrote:
On Tue, Jun 25, 2013 at 11:12:19PM -0700, Jeremy Chadwick wrote:
On Wed, Jun 26, 2013 at 09:42:37AM +0400, Andrej Zverev wrote:
Hello, and first please accept my apologies for this situation.
Understood, I just hope
Garrett Wollman ha scritto:
I've looked around for examples of good practice to emulate, and
haven't found much. The closest to what I want looks to be
vboxheadless, but I'm uncomfortable with the amount of mechanism from
rc.subr that it needs to reimplement. Are there any better examples?
On 2013-06-26 01:55, Michael Gmelin wrote:
...
The problem is that static initialization happens in the expected
order (same translation unit), but termination does *not* happen in the
reverse order of initialization, which - according to the C++ standard
section 3.6.3 should be guaranteed:
If
| 20130626
+-+
x11-toolkits/sakura | 2.4.2 | 3.1.0
+-+
If any of the above results are invalid, please check
On Wed, Jun 26, 2013 at 12:15:37AM -0700, Jeremy Chadwick wrote:
On Wed, Jun 26, 2013 at 08:40:52AM +0200, Baptiste Daroussin wrote:
On Tue, Jun 25, 2013 at 11:12:19PM -0700, Jeremy Chadwick wrote:
On Wed, Jun 26, 2013 at 09:42:37AM +0400, Andrej Zverev wrote:
Hello, and first please
On Wed, 26 Jun 2013 11:00:40 +0200
Dimitry Andric d...@freebsd.org wrote:
On 2013-06-26 01:55, Michael Gmelin wrote:
...
The problem is that static initialization happens in the expected
order (same translation unit), but termination does *not* happen in
the reverse order of
On 6/25/2013 8:48 PM, Adrian Murphy wrote:
Hi,
I noticed portmaster developed a problem after a recent update to
ports-mgmt/pkg where the following appears in the output:
[: false: bad number
I traced it to lines in portmaster where np_orphan is set:
np_orphan=`pkg query %a
On Fri, Jun 21, 2013 at 10:04:51AM +0200, Baptiste Daroussin wrote:
Sorry it took time for me to reply, after we last talk about this, I
thought a lot about this, and while in principe I do like the idea, I have
a couple of concerns:
1: this reduces lots of flexibility we now have with the
On Wed, Jun 26, 2013 at 07:12:41PM +0700, Alexey Dokuchaev wrote:
I've cooked something up just now, take a look at the attached diff. I've
only barely tested it, but it seems to work for a few of my hand-crafted
configurations. It also handles known options groups (single/multi/etc.),
On 6/26/2013 2:40 AM, Baptiste Daroussin wrote:
No the justification is that we use to have a perl-after-upgrade script to
workaround the fact that we used major.minor.patchlevel my bypassing the
package
tool to modify directly the content of the package database and more some
files
on the
** The following ports have an incorrect PKGORIGIN **
PKGORIGIN connects packaged or installed ports to the directory they
originated from. This is essential for tools like pkg_version or
portupgrade to work correctly. Wrong PKGORIGINs are often caused by a
wrong order of CATEGORIES after a
Hello all!
I try to update my dovecot server.
But the following error is printed.
I use pkgng.
# portmaster -d dovecot2
snip
=== Correct pkg-plist sequence to create group(s) and user(s)
=== Compressing manual pages for dovecot-2.2.4
=== Running ldconfig
/sbin/ldconfig -m
Upgrade net-mgmt/netmagis-* ports to 2.2.0
PR: ports/18
Submitted by: maintainer
-
Build ID: 20130626165800-11105
Job owner: m...@freebsd.org
Buildtime: 39 minutes
Enddate:
On Wed, Jun 26, 2013 at 07:30:55PM +0700, Alexey Dokuchaev wrote:
On Wed, Jun 26, 2013 at 07:12:41PM +0700, Alexey Dokuchaev wrote:
I've cooked something up just now, take a look at the attached diff. I've
only barely tested it, but it seems to work for a few of my hand-crafted
On Jun 26, 2013, at 13:31, Michael Gmelin free...@grem.de wrote:
On Wed, 26 Jun 2013 11:00:40 +0200
Dimitry Andric d...@freebsd.org wrote:
On 2013-06-26 01:55, Michael Gmelin wrote:
...
The problem is that static initialization happens in the expected
order (same translation unit), but
On Wed, 26 Jun 2013 21:26:09 +0200
Dimitry Andric d...@freebsd.org wrote:
On Jun 26, 2013, at 13:31, Michael Gmelin free...@grem.de wrote:
On Wed, 26 Jun 2013 11:00:40 +0200
Dimitry Andric d...@freebsd.org wrote:
On 2013-06-26 01:55, Michael Gmelin wrote:
...
The problem is that static
On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote:
This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so the
problem can also be reproduced there.
...
This is roughly gcc 4.3.0 and later. For example, gcc 4.8 generates:
I just tested the thing with gcc 4.8 on up to date
On Wed, 26 Jun 2013 23:45:21 +0300
Konstantin Belousov kostik...@gmail.com wrote:
On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote:
This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so the
problem can also be reproduced there.
...
This is roughly gcc 4.3.0 and
On Wed, Jun 26, 2013 at 10:51:37PM +0200, Michael Gmelin wrote:
Could you replicate the problem using clang on stable/9 and HEAD? (I
didn't test gcc 4.2.1 myself).
On stable no, it is not reproducable. As I understand, stable clang is
3.2-something.
On HEAD with clang, I do see the
On Jun 26, 2013, at 22:45, Konstantin Belousov kostik...@gmail.com wrote:
On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote:
This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so the
problem can also be reproduced there.
...
This is roughly gcc 4.3.0 and later. For
On Wed, Jun 26, 2013 at 10:59:24PM +0200, Dimitry Andric wrote:
On Jun 26, 2013, at 22:45, Konstantin Belousov kostik...@gmail.com wrote:
On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote:
This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so the
problem can also be
On Thu, 27 Jun 2013 00:05:34 +0300
Konstantin Belousov kostik...@gmail.com wrote:
On Wed, Jun 26, 2013 at 10:59:24PM +0200, Dimitry Andric wrote:
On Jun 26, 2013, at 22:45, Konstantin Belousov
kostik...@gmail.com wrote:
On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote:
On Jun 26, 2013, at 23:05, Konstantin Belousov kostik...@gmail.com wrote:
On Wed, Jun 26, 2013 at 10:59:24PM +0200, Dimitry Andric wrote:
On Jun 26, 2013, at 22:45, Konstantin Belousov kostik...@gmail.com wrote:
On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote:
This revision is
On Wed, 26 Jun 2013 23:11:34 +0200
Dimitry Andric d...@freebsd.org wrote:
On Jun 26, 2013, at 23:05, Konstantin Belousov kostik...@gmail.com
wrote:
On Wed, Jun 26, 2013 at 10:59:24PM +0200, Dimitry Andric wrote:
On Jun 26, 2013, at 22:45, Konstantin Belousov
kostik...@gmail.com wrote:
Am 26.06.2013 um 14:54 schrieb er...@freebsd.org:
** The following ports have an incorrect PKGORIGIN **
PKGORIGIN connects packaged or installed ports to the directory they
originated from. This is essential for tools like pkg_version or
portupgrade to work correctly. Wrong PKGORIGINs are
On Wed, Jun 26, 2013 at 11:17:41PM +0200, Michael Gmelin wrote:
Are you both on the same architecture?
I tested both on amd64 and i386. For i386, it was -m32 for clang, and
native 32bit gcc 4.8.1, stock build from the tarball.
pgpx_vSDnRqU4.pgp
Description: PGP signature
?view=revisionrevision=321820
-
Port:sysutils/acpica-tools 20130626
Buildgroup: 9.1-QAT/amd64
Buildstatus: LEFTOVERS
Log:
https://qat.redports.org//~j...@freebsd.org/20130626224800-40172
On Thu, 27 Jun 2013 00:28:33 +0300
Konstantin Belousov kostik...@gmail.com wrote:
On Wed, Jun 26, 2013 at 11:17:41PM +0200, Michael Gmelin wrote:
Are you both on the same architecture?
I tested both on amd64 and i386. For i386, it was -m32 for clang, and
native 32bit gcc 4.8.1, stock build
On Wed, Jun 26, 2013 at 2:19 PM, Stefan Bethke s...@lassitu.de wrote:
Am 26.06.2013 um 14:54 schrieb er...@freebsd.org:
** The following ports have an incorrect PKGORIGIN **
PKGORIGIN connects packaged or installed ports to the directory they
originated from. This is essential for tools
31 matches
Mail list logo
