On Thu, May 15, 2014 at 8:47 AM, Wookey wrote:
> I'm not quite sure who actually controls these things
That would be the stable release team, the processes for uploads to
stable are documented here:
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
--
bye,
pabs
ht
+++ Manoj Srivastava [2014-05-10 23:00 -0700]:
>
> <#secure method=pgpmime mode=sign>
> On Sun, May 11 2014, Steve McIntyre wrote:
>
> > Thinking about the poor people trying to bootstrap things, I'm tempted
> > to suggest doing this as two separate source packages. Make is *so*
> > far down the
On Wed, May 14 2014, Ian Jackson wrote:
>> I know I can't do that until Jess is released and dpkg 1.17.2 is
>> in stable.
>
> Is it acceptable to put off providing a guile-enabled make.deb until
> jessie+1 ?
Talking to various people I was convinced I was overthinking
this, an
On Wed, May 14, 2014 at 01:16:05PM +0100, Ian Jackson wrote:
>Steve McIntyre writes ("Re: Guile language support in make"):
>> Russ Allbery wrote:
>> >I think building two separate binaries makes more sense than adding Guile
>> >support by default for all t
On Wed, 2014-05-14 at 13:20:32 +0100, Ian Jackson wrote:
> (It's a shame that the dpkg developers didn't adopt my suggestion of
> [ ] for build-profiles, because that would have been
> backward-compatible with old tools.)
One of the reasons [0] it was not adopted was precisely because it is
not ba
Manoj Srivastava writes ("Re: Guile language support in make"):
> Well, I was thinking of build profiles for that.
(Lesson for me: read the whole thread first.)
> I know I can't do that until Jess is released and dpkg 1.17.2 is
> in stable.
Is it accepta
Steve McIntyre writes ("Re: Guile language support in make"):
> Russ Allbery wrote:
> >I think building two separate binaries makes more sense than adding Guile
> >support by default for all the reasons you stated. We do similar things
> >with Emacs, which has a -
On Sun, May 11 2014, Marco d'Itri wrote:
> I do this for the inn2 package and it has worked well for years.
> Another (much simpler) example is kmod, which build a deb and a udeb.
> If ./configure is not buggy and works when called from a build directory
> then building two binary packages from t
On May 11, Manoj Srivastava wrote:
> Building two binary packages from a single source seems hackish,
> since make and make-guile would require ./configure to be run again,
> and each target of the ./debin/rules might need cleanup/restart. Not
> unsolvable, but messy, and I do not hav
On Sat, May 10, 2014 at 06:38:15PM -0700, Manoj Srivastava wrote:
> I would like to solicit the opinion of the developers about the
> value of adding Guile support to the default make package, at the
> expense of two smallish additional dependencies.
> http://blog.melski.net/2013/11/29/w
<#secure method=pgpmime mode=sign>
On Sun, May 11 2014, Steve McIntyre wrote:
> Thinking about the poor people trying to bootstrap things, I'm tempted
> to suggest doing this as two separate source packages. Make is *so*
> far down the bottom of the stack that adding a dependency on another
> lan
Steve McIntyre writes:
> Thinking about the poor people trying to bootstrap things, I'm tempted
> to suggest doing this as two separate source packages. Make is *so* far
> down the bottom of the stack that adding a dependency on another
> language could cause significant problems.
Oh, good point
On Sun, 2014-05-11 at 03:28 +0100, Steve McIntyre wrote:
> Russ Allbery wrote:
> >Manoj Srivastava writes:
> >
> >> Building two binary packages from a single source seems hackish,
> >> since make and make-guile would require ./configure to be run again,
> >> and each target of the ./de
Russ Allbery wrote:
>Manoj Srivastava writes:
>
>> Building two binary packages from a single source seems hackish,
>> since make and make-guile would require ./configure to be run again,
>> and each target of the ./debin/rules might need cleanup/restart. Not
>> unsolvable, but messy,
Manoj Srivastava writes:
> Building two binary packages from a single source seems hackish,
> since make and make-guile would require ./configure to be run again,
> and each target of the ./debin/rules might need cleanup/restart. Not
> unsolvable, but messy, and I do not have the moti
Hi,
I have two constituencies here; people who would like to see
guile support in make, and to explore the new features. And people who
expect a sensibly small set of packages essential to building other
packages in Debin.
Without guile suport, make just depends on libc, and no
16 matches
Mail list logo
