The following reply was made to PR alpha/148392; it has been noted by GNATS.
From: John Baldwin
To: bug-follo...@freebsd.org,
pac...@gmail.com
Cc:
Subject: Re: alpha/148392: Users of Alpha platform should stay with Dovecot
1.1.16
Date: Wed, 3 Nov 2010 09:37:39 -0400
Bah, accidentally lost
causing
segfaults when gdb tries to load symbols for a binary. The simplest fix is to
just remove the devel/libreadline support from the devel/gdb port if that is
ok to do.
--
John Baldwin
___
freebsd-ports@freebsd.org mailing list
http
/ptlib26) to use
libiodbc instead.
Can we please fix the default so that the pre-built package set works in the
future? This sort of thing is important if we want to still support desktops
in lab or corporate environments where you have a lot of identically-installed
machines.
--
John Baldwin
On Tuesday, March 22, 2011 4:20:06 pm Alex Dupre wrote:
> John Baldwin ha scritto:
> > This would appear to no longer be a supported use case in for 8.2 packages
> > (and if you believe posts on the forums, 8.1 was equally broken). Namely,
> > some package the GNOME de
rent package tools for doing batch
upgrades (i.e. upgrading from one completely package set to another). pkgng
adds that feature, and I find it a must for supporting large installations of
machines that need automated management.
--
John Baldwin
___
fr
mostly by reading/skimming a _lot_ of e-mail each
day), but even with all that there is a lot going on that I don't know the
intimate details of. Instead, I choose to trust my fellow developers to
best manage the areas over which they have expertise and detailed knowledge
until given strong
On Friday, August 31, 2012 5:59:10 am Baptiste Daroussin wrote:
> On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote:
> > On 08/30/2012 07:32 AM, John Baldwin wrote:
> > > On Thursday, August 30, 2012 1:10:24 pm Chris Rees wrote:
> > >> On 30 Aug 201
On Friday, August 31, 2012 9:41:13 am Chris Rees wrote:
> On 31 Aug 2012 13:15, "John Baldwin" wrote:
> >
> > On Friday, August 31, 2012 5:59:10 am Baptiste Daroussin wrote:
> > > On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote:
> > > &
On Thursday, July 08, 2010 6:12:39 pm Doug Barton wrote:
> On Thu, 8 Jul 2010, John Baldwin wrote:
>
> > This is a port for yet-another-/etc-merging tool that I wrote recently.
It
> > passes portlint -N with one bogus warning because /etc is in the comment.
>
>
FreeBSD), not stripped
> /boot/modules/vboxnetflt.ko: ELF 64-bit LSB relocatable, x86-64, version 1
(FreeBSD), not stripped
>
> Does vboxguest.ko have silent dependencies on other vbox modules? I only
> loaded vboxdrv.ko.
Look in dmesg for the real kldload error message.
--
John Baldwin
___
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"
On Monday 28 December 2009 11:46:36 am Brandon Gooch wrote:
> On Mon, Dec 28, 2009 at 10:04 AM, John Baldwin wrote:
> > On Monday 28 December 2009 9:25:28 am Gary Jennejohn wrote:
> [SNIP]
> >>
> >> Does vboxguest.ko have silent dependencies on other vbox modules?
to an array or some such, but it is a bogus
pointer and that is why you are faulting.
> The only thing that looks appropriate that changed in that week
> was sys/vm/vm_map.c, which had some new code added to help with
> shm mappings. I looked a
> % ldconfig -R
> % ldconfig -r | grep libicudata
> 231:-licudata.38 => /usr/X11R6/lib/libicudata.so.38
> 386:-licudata.38 => /usr/local/lib/libicudata.so.38
>
> Could anybody investigate it? I have no time now.
Drop the .0 from the filenames or add libf
s less
obvious than that, as since it isn't looking to do variable expansion
in an M modifier, it ends the $COMPS expansion when it sees the first },
so what you end up with is this:
VAR2='${COMPS:M${AA}'}
That is, it tries to match the substring '${AA' in ${COMPS} and then
t; kernel structures are changing, which means NVIDIA needs to recompile
> their binary blob aswell!
The blob does not generally use FreeBSD-specific structures. Part of
the driver is source and that interfaces with FreeBSD's APIs to implement
shim
.endif
>
> (Not that I expect that this is tied to what I've been trying
> to figure out about lack of installing into staging.)
I'm not sure why that change is needed, but I also suspect it is
needed for armv7 and was just missed. Currently there isn't a
arm-gcc port for a
ude @rmtry entries for each pyc
file or is there a better way?
--
John Baldwin
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebs
On 12/6/18 11:17 AM, Michael Gmelin wrote:
>
>
>> On 6. Dec 2018, at 19:21, John Baldwin wrote:
>>
>> The devel/gdb port installs python scripts into
>> /usr/local/share/gdb/python.
>> If you then run kgdb as root (not that unusual), it will generate .pyc fi
On 12/7/18 10:17 AM, John Baldwin wrote:
> On 12/6/18 11:17 AM, Michael Gmelin wrote:
>>
>>
>>> On 6. Dec 2018, at 19:21, John Baldwin wrote:
>>>
>>> The devel/gdb port installs python scripts into
>>> /usr/local/share/gdb/python.
>>&
stalled (php5-arcanist-20161003 from devel/arcanist) wasn't upgraded
by 'pkg upgrade -f' to the php72 version. I ended up explicitly deleting
it and installing the new version. I'm not sure what the right solution is,
but it seems like 'pkg
On 12/13/18 1:35 AM, Mathieu Arnold wrote:
> On Mon, Dec 10, 2018 at 11:22:49AM -0800, John Baldwin wrote:
>> On 12/7/18 10:17 AM, John Baldwin wrote:
>>> On 12/6/18 11:17 AM, Michael Gmelin wrote:
>>>>
>>>>
>>>>> On 6. Dec 2018, at 1
t_current_thread ();
}
static void
@@ -667,13 +689,11 @@ attach_thread (ptid_t ptid, const td_thrhandle_t *
if (!in_thread_list (ptid))
{
/* Add thread with info */
-private = xmalloc(sizeof(struct private_thread_info));
+private = xcalloc(1, sizeof(struct private_thread
as others
have stated.
I wouldn't even mind if we had both /usr/local/man and /usr/local/share/man
so long as our default MANPATH included both if that means applying fewer
patches to ports.
--
John Baldwin
___
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"
ls.
> This GDB was configured as "powerpc-marcel-freebsd"...
> Failed to open vmcore: unsupported architecture
This is a different problem with libkvm. I would start with 'ps -M' and use
a debugger to step through the _powerpc_probe and _powerpc64_probe routines in
l
g_add /some/dir
> are there any ports-mgmt/* tools for upgrades that don't need the ports
> tree present. I know portupgrade does.
>
> Thats not an argument for or against, just commentary.
There are proprietary tools that manage packages of proprietary software that
run on FreeB
OPTIONS support, so I think this *never* worked as expected.
It used to work. I was just guessing about how it might not be working now
based on reading the existing logic. I have not delved into the history to
see what has changed.
--
John Baldwin
__
de4 at
one point and did a 'make config-recursive' from that port and encountered
several config screens (libxine, qt4-gui, etc.)
--
John Baldwin
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Thursday 18 September 2008 04:51:11 am Alex Dupre wrote:
> John Baldwin ha scritto:
> > It used to work.
>
> I was thinking the same thing, but actually it never worked in that way.
Trust me, since I rebuild from scratch all the time, I quite remember when
options were firs
On Thursday 18 September 2008 03:18:17 pm Alex Dupre wrote:
> John Baldwin wrote:
> > Trust me, since I rebuild from scratch all the time, I quite remember when
> > options were first added and I'd kick off a build of kde or some such
> > overnight and check my screen s
>> activities, including using, say, devel/powerpc64-gcc on a powerpc64 machine
>> to self host with more modern tools than gcc 4.2.1 based ones.
>> As I understand, being in devel/ instead of lang/ for gcc tools is tied to
>> being constructed for the system-building activi
-gcc ports used as a FreeBSD toolchain. I would ask bapt@ and/or
manu@ what they think about having you maintain the bare metal ports.
--
John Baldwin
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd
in clang properly, though.
I think using the hack patch in devel/freebsd-gcc* is fine for now, but can
you confirm if both 6 and 9 need it or only 9?
--
John Baldwin
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/f
e that, the 12.x dialog4ports was still going to fail
as the 12.x version of those libraries were already broken. I haven't checked
to see if the affected libraries have been added to misc/compat12x.
--
John Baldwin
___
freebsd-ports@freebsd.org
need firmware bits. Radeon does, but
those could be statically compiled in for people who want this. The drivers
should be fixed. They never worked with syscons because syscons didn't work
once KMS was enabled, but they should be able to work with newcons
t due to newcons AFAIK. I don't think that setup worked
with syscons either. I think it could probably never have worked
with syscons, but it should in theory be fixable with newcons.
--
John Baldwin
___
freebsd-ports@freebsd.org mailing list
htt
On Monday, April 21, 2014 3:51:33 pm Konstantin Belousov wrote:
> On Mon, Apr 21, 2014 at 02:31:12PM -0400, John Baldwin wrote:
> > On Thursday, April 17, 2014 2:50:01 pm Konstantin Belousov wrote:
> > > The following reply was made to PR amd64/188699; it has be
36 matches
Mail list logo
