We are fast approaching our September release! Here's a quick summary
of current goings-ons.
* All major features have been integrated and developers are now
doing stabilization passes and dealing with bug reports.
* The actual release date this month is still a bit uncerta
I like the concept of throwing together an export hierarchy,
but it might be too much maintainance to physically separate
the git components out within the primary repo.
Can we create a secondary repo that extracts just the bits
of the hierarchy which we want to officially main
:Hi all:
:
:Here is a newbie query regarding the code in namei.h
:
:In DragonflyBSD, sys/sys/namei.h
:
:...
:
:What is the advantage of the DragonflyBSD approach in this case ?
:
:thanks
:Saifi.
DragonFly uses a completely different path lookup mechanism,
mostly embodied by sys/nlookup.h,
Simon 'corecode' Schubert wrote:
cd /usr/src/lib/pam_module/pam_krb5
env CFLAGS='-O -g -pipe '-I/usr/pkg/include/krb5 \
LDFLAGS=-L/usr/pkg/lib' -rpath /usr/pkg/lib' make
make install
That worked for me.
I can now login with a kerberos password and klist shows the ticket.
Thanks!
-
Ed Berger
Ed Berger wrote:
I wanted to enable kerberos login in dragonfly-development, since
kerberos is used at my work place, so I uncommented the krb5 related
lines in the /etc/pam.d config files and found out the hard way that the
pam_krb5.so module was missing...
Yes, I noticed that as well. The
I wanted to enable kerberos login in dragonfly-development, since
kerberos is used at my work place, so I uncommented the krb5 related
lines in the /etc/pam.d config files and found out the hard way that the
pam_krb5.so module was missing...
Hi all:
Here is a newbie query regarding the code in namei.h
In DragonflyBSD, sys/sys/namei.h
struct componentname
{
...
...
long cn_consume; /* chars to consume in lookup */
...
};
and
in FreeBSD RELENG_4, sys/sys/namei.h
struct componentname
{
...
...
char *cn_pnbuf; /* pathname buff
Michel Alexandre Salim wrote:
I plan to do that (looking at the other Linux port right now too). I
already have a custom Makefile for cpdup anyway, and before I tried
using bmake I already tried using gcc by hand. I must say the bundled
rules in Dragonfly's make are quite impressive.
I don't th
On Tue, September 1, 2009 10:55 am, Michel Alexandre Salim wrote:
> If Arch Linux is interested in this too, would it be feasible to
> maintain this in a Git submodule that can be individually cloned? If
> that's inconvenient, I will of course gladly continue cloning the
> entire Dfly repository t
On Tue, Sep 1, 2009 at 3:03 AM, Sascha Wildner wrote:
> Michel Alexandre Salim schrieb:
>>
>> Where is aliases_parse.h supposed to be generated?
>
> We do basically:
>
> yacc -d -o aliases_parse.c aliases_parse.y
Aha, thanks! This is where our bmake went wrong -- rather than
specifying the output
On Tue, Sep 1, 2009 at 5:59 AM, Simon 'corecode'
Schubert wrote:
>
>> I have question about the build process, though. I've patched some
>> files to take care of BSD-isms -- having to define __DECONST in dma.h
>> and removing the reference to st.st_mtimespec in dma.c -- but I'm
>> stuck building.
>
Hi,
* Simon 'corecode' Schubert wrote:
>
> I think the best would be if you'd write a generic non-BSD makefile. It
> is a simple enough build process.
Someone contacted me some time ago and he made a Linux port of dma. You
can find it here: http://www.mvkrauss.de/arch.html
Not sure if the ve
Michel Alexandre Salim wrote:
I saw DMA mentioned recently at the DfBSD Digest, and it just so
happened that there was a recent discussion in fedora-devel about
removing sendmail from the base install. An overriding concern was
that it would break reporting by tools like cron, even though most
de
Michel Alexandre Salim schrieb:
Where is aliases_parse.h supposed to be generated?
We do basically:
yacc -d -o aliases_parse.c aliases_parse.y
lex -t aliases_scan.l > aliases_scan.c
Sascha
--
http://yoyodyne.ath.cx
14 matches
Mail list logo
