On Tue, Sep 1, 2009 at 12:17 PM, Simon 'corecode' Schubert
wrote:
> 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 mu
On Thu, 03.09.2009 at 20:59:02 -0400, Michel Alexandre Salim wrote:
>> On Sep 3, 2009 3:34 PM, "Simon 'corecode' Schubert"
>> wrote:
>>
>> Michel Alexandre Salim wrote:
>> On Tue, Sep 1, 2009 at 11:42 PM, Matthew Dillon> I don't want to use submodules, because they change the work flow in the
>>
Oh, a tarball iso good enough, thanks.
--
Michel
On Sep 3, 2009 3:34 PM, "Simon 'corecode' Schubert" <
corec...@fs.ei.tum.de> wrote:
Michel Alexandre Salim wrote: > > On Tue, Sep 1, 2009 at 11:42 PM, Matthew >
Dillon
Michel Alexandre Salim wrote:
On Tue, Sep 1, 2009 at 11:42 PM, Matthew
Dillon wrote:
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.
Using git submodules, the main
On Tue, Sep 1, 2009 at 11:42 PM, Matthew
Dillon wrote:
> 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.
>
Using git submodules, the maintenance required should be
On Wed, September 2, 2009 1:37 pm, Simon 'corecode' Schubert wrote:
> Matthew Dillon wrote:
>> Well, not tarballs. The idea is to keep it in git so third parties
>> can
>> track and merge it trivially.
>
> The problem with creating another repo is that *we* can't merge trivially
> from it.
Matthew Dillon wrote:
Well, not tarballs. The idea is to keep it in git so third parties can
track and merge it trivially.
The problem with creating another repo is that *we* can't merge trivially from
it. I think tarballs are the best option.
cheers
simon
:I agree.
:
:> Can we create a secondary repo that extracts just the bits
:> of the hierarchy which we want to officially maintain as
:> exports? And then, say, have a 5-minute cron job to keep it
:> synchronized with the master repo (for those sub-projects)?
:
:Yes, that should
Matthew Dillon wrote:
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.
I agree.
Can we create a secondary repo that extracts just the bits
of the hierar
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
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
Hello,
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
desktop users will not see
18 matches
Mail list logo