On Tue, Sep 1, 2009 at 12:17 PM, Simon 'corecode' Schubert
corec...@fs.ei.tum.de 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
On Thu, 03.09.2009 at 20:59:02 -0400, Michel Alexandre Salim wrote:
On Sep 3, 2009 3:34 PM, Simon apos;corecodeapos; Schubert
corec...@fs.ei.tum.de wrote:
Michel Alexandre Salim wrote:
On Tue, Sep 1, 2009 at 11:42 PM, Matthew Dillondil...@apollo.ba...
I don't want to use submodules,
On Tue, Sep 1, 2009 at 11:42 PM, Matthew
Dillondil...@apollo.backplane.com 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
Michel Alexandre Salim wrote:
On Tue, Sep 1, 2009 at 11:42 PM, Matthew
Dillondil...@apollo.backplane.com 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.
Oh, a tarball iso good enough, thanks.
--
Michel
On Sep 3, 2009 3:34 PM, Simon apos;corecodeapos; Schubert
corec...@fs.ei.tum.de wrote:
Michel Alexandre Salim wrote: On Tue, Sep 1, 2009 at 11:42 PM, Matthew
Dillondil...@apollo.ba...
I don't want to use submodules, because they change the
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
: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 be
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
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. I think
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
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
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
On Tue, Sep 1, 2009 at 5:59 AM, Simon 'corecode'
Schubertcorec...@fs.ei.tum.de 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
On Tue, Sep 1, 2009 at 3:03 AM, Sascha Wildners...@online.de 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
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 to
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
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
17 matches
Mail list logo
