when he is too busy)?
--
| Lucas Nussbaum
| [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |
signature.asc
Description: Digital signature
On 06/06/11 at 13:35 -0700, Don Armstrong wrote:
On Mon, 06 Jun 2011, Lucas Nussbaum wrote:
On 06/06/11 at 10:29 -0700, Don Armstrong wrote:
On Mon, 06 Jun 2011, Steve Langasek wrote:
1) Implement support for calling 'debian/rules build-arch' in place
of 'debian/rules build
On 07/06/11 at 09:41 +0200, Raphael Hertzog wrote:
Lucas, can you do a full rebuild with the packages below ?
http://people.debian.org/~hertzog/packages/dpkg-dev_1.16.1~buildarch.1_all.deb
http://people.debian.org/~hertzog/packages/libdpkg-perl_1.16.1~buildarch.1_all.deb
Hi,
Since Tollef
On 25/10/13 at 12:16 -0400, Paul Tagliamonte wrote:
In response to the recent threads, I'd like to ask the tech-ctte to
please vote on and decide on the default init system for Debian.
I agree. I don't think that many substantial new arguments are going to
be brought by waiting more on this
On 28/10/13 at 18:21 -0700, Russ Allbery wrote:
Wouter Verhelst wou...@master.debian.org writes:
Also, since all alternative init implementations under consideration do
support sysv-style init scripts, I think that whatever init system we
(well, you, the TC) end up choosing, the
On 21/01/14 at 12:27 +0100, Matthias Urlichs wrote:
Hi,
in this debate, enlightening *ahem* as it was, I think that one aspect
didn't get the attention it should get. (IMHO.)
systemd uses dependencies. Upstart uses events.
This was already discussed in the following subthreads:
On 05/02/14 at 22:41 +, Thorsten Glaser wrote:
Colin Watson dixit:
(Decide any technical matter where Developers' jurisdictions overlap).
I think it is not up to the d-i people to decide on the init system
anyway – especially as not d-i but debootstrap is the canonical way
to install
On 22/05/14 at 10:14 -0700, Steve Langasek wrote:
On Thu, May 22, 2014 at 03:56:26PM +0100, Ian Jackson wrote:
We have had some discussion about this. No-one seems to have objected
to the suggestion that the DPL, rather than the TC chairman, should
have a casting vote in TC decisions.
On 23/05/14 at 09:42 +0200, Svante Signell wrote:
On Fri, 2014-05-23 at 08:32 +0200, Lucas Nussbaum wrote:
On 22/05/14 at 10:14 -0700, Steve Langasek wrote:
On Thu, May 22, 2014 at 03:56:26PM +0100, Ian Jackson wrote:
We have had some discussion about this. No-one seems to have objected
Hi,
I think that everyone will agree that we are having a big crisis about
the role of the TC in Debian. What saddens me deeply is how some of us
framed this as a Debian vs the Technical Committee fight. The
Technical Committee _is_ Debian. If we feel it's malfunctionning, it's
our problem as
Hi,
On 11/08/16 at 20:17 +0200, Margarita Manterola wrote:
> 2) The TC will act as an advisor to the Roadmap Team
> 3) The TC will not be involved as body with the Roadmap Team
I'm not sure about those two options.
Would (2) go further than powers already available to the TC under
§6.1? What
On 29/07/19 at 17:23 -0500, Gunnar Wolf wrote:
> My opinion, based on what we talked about this bug during DebConf and
> the people I talked with, is that we should provide an advice
> following roughly:
>
> - The Release Team are empowered to set the base requirements to build
> packages for a
On 16/03/22 at 23:54 +, Wookey wrote:
> On 2022-03-16 15:29 +, Ian Jackson wrote:
> > In practice, the vast majority of packages are maintained in git on
> > salsa. The maintainers use those git repositories as the PFM.
>
> > but almost everyone is already treating git as primary.
>
>
Hi,
First, some context with numbers:
Source packages in testing: 32247
Source packages in testing using 3.0 (native): 690 (2.1%)
Source packages in testing using 3.0 (quilt): 30937 (95.9%)
Source packages in testing using 1.0: 620 (1.9%)
Those 620 packages probably fit in two categories:
A)
Hi Ian,
On 15/03/22 at 16:29 +, Ian Jackson wrote:
> Part I - belss continued use of 1.0 native format, for now at least:
>
> 1. Declare explicitly that there is nothing wrong with a package with
> a native format, but a non-native version number.
>
> 2. Request that the dpkg
Hi Sean,
On 28/03/22 at 16:21 -0700, Sean Whitton wrote:
> Hello Lucas,
>
> Many thanks for providing this summary of your position. Let me just
> note a point of disagreement:
>
> On Tue 15 Mar 2022 at 10:06PM +01, Lucas Nussbaum wrote:
>
> > A point that I find
On 08/06/22 at 21:07 +0200, Helmut Grohne wrote:
> Now we've turned a discussion about source package formats into a
> discussion about workflows and git. So when I reason about uniformity, I
> effectively want those idiosyncratic workflows to go away. If dgit
> requires 1.0-with-diff for now,
On 08/06/22 at 21:07 +0200, Helmut Grohne wrote:
> I think I take more issue with non-dgit git-first workflows than with
> dgit ones, because dgit is so well documented and is a workflow that is
> already shared by a noticeable fraction of the archive.
I'm curious: how do you measure dgit usage?
On 07/06/22 at 07:43 +0200, Helmut Grohne wrote:
> Hallo,
>
> On Tue, May 10, 2022 at 05:29:57PM -0700, Sean Whitton wrote:
> > DRAFT
> >
> > Using its powers under constitution 6.1.5, the Technical Committee
> > issues the following advice:
>
> I've given this some thought and feel uneasy
Hi,
On 15/06/22 at 07:32 +0200, Helmut Grohne wrote:
> The other model restricts itself to only adding files below
> debian/ and then using debian/rules to actually apply patches during
> build. This latter model is fairly annoying, because there are so many
> different ways of doing it (i.e. we
On 10/05/22 at 17:29 -0700, Sean Whitton wrote:
> Hello,
>
> At today's ctte meeting we considered whether we can start a vote on
> this, but two committee members were missing, and someone else at the
> meeting reported that they hadn't yet been able to spend enough time
> thinking through the
Hi,
On 10/05/22 at 16:57 +0100, Matthew Vernon wrote:
> 1.0-with-diff has advantages over 3.0 (quilt) particularly with git-based
> workflows, because in 3.0 (quilt) the diff is included inside the source
> tree
> The issue of preferred form for modification has been raised (source package
> in
Thanks for your answer.
On 11/05/22 at 12:38 +0100, Ian Jackson wrote:
> I would love for there to be something like 3.0-with-git-diff. Indeed,
> I filed this wishlist bug to ask if contribution would be welcome:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007781
> but have not had
On 11/05/22 at 17:29 +0100, Ian Jackson wrote:
> Lucas Nussbaum writes ("Re: Bug#1007717: Draft resolution for "Native source
> package format with non-native version""):
> > Out of curiosity, if 3.0 (native) supported multiple tarballs, wouldn't
> > it
24 matches
Mail list logo
