y NMUs or multiarch support caused by such strict dependencies
don't apply in such a case of the dependency of binaries on a shared
library.
Thanks in advance for considering my request
Adrian Bunk
[1] http://bugs.debian.org/668662
[2] http://bugs.debian.org/677180
[3] http://bugs.debian.org/66
On Fri, Nov 02, 2012 at 04:41:19PM -0700, Russ Allbery wrote:
> "Didier 'OdyX' Raboud" writes:
>...
> > Le vendredi, 2 novembre 2012 23.47:11, Russ Allbery a écrit :
> >> In practice, divergence from the upstream SONAME practice is probably a
> >> bad idea. This business of having an exposed priv
Hi Josselin,
reading through the systemd position statement [1], I ran into a
statement that is either incomplete or incorrect:
The upstart position statement [2] states:
<-- snip -->
systemd is hasty. ... While we are committed to having sane upgrade
paths and not depend on such kernel fe
On Tue, Dec 17, 2013 at 12:38:50PM +0100, Josselin Mouette wrote:
> Hi Adrian,
Hi Josselin,
> Le lundi 16 décembre 2013 à 17:52 +0200, Adrian Bunk a écrit :
> > Can you give a pointer to what guarantees systemd upstream makes
> > regarding supporting older kernels?
>
>
On Tue, Dec 17, 2013 at 10:29:35AM -0800, Russ Allbery wrote:
> Adrian Bunk writes:
>
> > this hits exactly the core of the problem:
>
> > The minimum supported Linux kernel version in glibc is currently 2.6.16,
> > released in 2006. And I'd trust glibc upstreamt
On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote:
> >>>>> "Adrian" == Adrian Bunk writes:
>
>
> Adrian> Yes, it is speculation that other new features (or even
> Adrian> bugfixes) might appear in the kernel and might become
>
On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote:
> Hi Adrian,
Hi Josselin,
> Le mercredi 18 décembre 2013 à 13:34 +0200, Adrian Bunk a écrit :
> > That point you bring up is semi-orthogonal to the upgrade decision,
> > but it also brings up two important poin
On Wed, Dec 18, 2013 at 08:53:04AM -0500, Sam Hartman wrote:
> Adrian, I'm frustrated when I read your message because you put words in
> my mouth that I did not speak.
Hi Sam,
> I never said that Debian should allow systemd to dictate policy for
> multiple distributions nor did I say that Debian
On Wed, Dec 18, 2013 at 03:10:19PM +0200, Uoti Urpala wrote:
> On Wed, 2013-12-18 at 13:34 +0200, Adrian Bunk wrote:
>...
> > When not using systemd as pid 1, that risk would be confined to the
> > parts of systemd Debian would be using (currently only udev).
>
> I thi
On Wed, Dec 18, 2013 at 04:10:19PM +0100, Ansgar Burchardt wrote:
> Hi,
>
> Adrian Bunk writes:
> > On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote:
> >> > And now you bring up the point that Debian should reconsider the
> >> > lenght of
On Wed, Dec 18, 2013 at 03:50:33PM +0100, Josselin Mouette wrote:
> Hi,
Hi Josselin,
>...
> I do not consider keeping an arbitrary number of packages at the wheezy
> version an appropriate answer, regardless of the choice of init systems.
>...
how many and which packages would have to be kept at
On Wed, Dec 18, 2013 at 02:44:03PM -0800, Russ Allbery wrote:
> Adrian Bunk writes:
>...
> > When not using systemd as pid 1, that risk would be confined to the
> > parts of systemd Debian would be using (currently only udev).
>
> There appears to be near-unanimous ag
On Wed, Dec 18, 2013 at 02:53:39PM -0800, Russ Allbery wrote:
> Adrian Bunk writes:
>
> > [1] Personally, I am sceptical whether it is a good idea to switch to a
> > different init system for jessie. But I am not on a desperate rant
> > against systemd, and if
On Mon, Jan 13, 2014 at 01:57:29PM -0700, Bdale Garbee wrote:
> Ian Jackson writes:
>
> > I'm coming round to the view that we should be planning to support
> > multiple systems indefinitely.
>
> This has been my opinion all along. Various assertions that it's
> somehow just too hard really hav
On Tue, Jan 14, 2014 at 06:03:33PM +, Ian Jackson wrote:
> Adrian Bunk writes ("Bug#727708: Bits from linux.conf.au"):
>...
> > 3. Switching init systems after installation.
> > Assume I am currently using systemd.
> > What is supposed to happen when I
On Tue, Jan 14, 2014 at 11:31:09AM -0700, Bdale Garbee wrote:
> Adrian Bunk writes:
>...
> > If dependencies like "installing GNOME enforces systemd as init system"
> > would be legal, then after a few more such dependencies it would turn
> > out that systemd wil
On Thu, Jan 16, 2014 at 09:39:37PM +0100, Ansgar Burchardt wrote:
>...
> Maintainers only should not drop support for a (default) init system
> when the application supports it.
>...
So if udev (maintained by systemd upstream as part of the systemd
sources) would ever get a dependency on systemd
On Fri, Jan 17, 2014 at 05:08:51PM +0100, Christoph Anton Mitterer wrote:
> On Fri, 2014-01-17 at 16:01 +, Ian Jackson wrote:
> > The "universal operating system"
> > phrase is a slogan.
> Sure it is, but that slogan actually stands for some important
> principles in the open source world... li
On Fri, Jan 17, 2014 at 08:41:32PM -0800, Don Armstrong wrote:
>...
> With all that said, I think all of these considerations give me a slight
> preference for systemd over upstart, though I believe that whatever the
> committee decides on will be a great improvement over venerable SysV.
>...
> 3:
On Fri, Jan 17, 2014 at 08:13:30PM -0800, Russ Allbery wrote:
>...
> I believe it is reasonable to allow GNOME to require systemd as the init
> system if that's the only way to get a working logind with the software
> that we release with jessie,
Why does logind actually have to be a hard dependen
On Sat, Jan 18, 2014 at 09:45:35AM -0800, Russ Allbery wrote:
>...
> If software that people want to package for Debian is deeply entangled in
> one init system (that is supported in Debian), for good or for ill,
> regardless of what one might think of the decisions made by upstream that
> created
On Fri, Jan 17, 2014 at 12:51:48PM +, Ian Jackson wrote:
> Adrian Bunk writes ("Re: Bug#727708: Init system resolution open questions"):
> > (Only as a PM since I am repeating myself.)
>
> Thanks for your mail. I think it deserves wider consideration.
>
> >
On Sat, Jan 18, 2014 at 11:22:06AM -0800, Russ Allbery wrote:
> Adrian Bunk writes:
>...
> > We are in full agreement on that.
>
> > And my point on top of that is that if the CTTE decsion would be that
> > Debian should support multiple init systems, but it does no
On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote:
> Adrian Bunk writes:
> > On Sat, Jan 18, 2014 at 11:22:06AM -0800, Russ Allbery wrote:
>
> >> There is a natural process here, where rarely-used configurations
> >> slowly stop working and people even
On Sun, Jan 19, 2014 at 11:00:01AM +0100, Tollef Fog Heen wrote:
> ]] Adrian Bunk
>
> > I already gave my hypothetical "udev gets a hard dependency on systemd
> > as init system" worst case.
> > To make the worst case even worse, assume a new upstream versio
On Sun, Jan 19, 2014 at 02:59:01AM -0800, Russ Allbery wrote:
> Adrian Bunk writes:
> > On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote:
>...
> > No, I am not assuming bad faith.
>
> > But there will be cases where the goals like
> > 1. give user
On Sun, Jan 19, 2014 at 04:05:08PM +0100, Tollef Fog Heen wrote:
> ]] Adrian Bunk
>...
> > If I was a systemd maintainer I would consider it a reasonable option to
> > rather upload a new version of systemd that adds such a dependency to
> > udev instead of shipping a
On Sun, Jan 19, 2014 at 07:23:17PM +0100, Josselin Mouette wrote:
>...
> I also have to insist that GNOME 3.10+ *needs* a working logind even for
> basic functionality,
>...
Can you elaborate on where exactly upstream GNOME 3.10 has a hard
dependency on logind, and no alternative ConsoleKit codep
On Wed, Jan 22, 2014 at 03:23:32AM +1000, Anthony Towns wrote:
>...
> [non-essential-init] In order to allow Debian users and developers
> to easily design, test and deploy alternative init systems both now
> and in the future, no init system in Debian should be provided via an
> Essential:yes pa
On Tue, Jan 28, 2014 at 12:18:09AM +0100, Ansgar Burchardt wrote:
>...
> > == version "multiple" only ==
> >
> >2. Debian intends to support multiple init systems, for the
> > foreseeable future, and so long as their respective communities
> > and code remain healthy. Nothing outs
On Mon, Jan 27, 2014 at 08:54:13PM -0500, Michael Gilbert wrote:
> On Mon, Jan 27, 2014 at 11:59 AM, Ian Jackson wrote:
> >2. Debian intends to support multiple init systems, for the
> > foreseeable future, and so long as their respective communities
> > and code remain healthy. No
On Tue, Jan 28, 2014 at 08:40:01AM +0200, Adrian Bunk wrote:
>...
> [1] That's ignoring the possibility that a non-systemd logind
> replacement with sufficient functionality for all software following
> the latest logind features might show up one day - but
>,,,
Ple
On Tue, Jan 28, 2014 at 11:39:51AM +, Ian Jackson wrote:
>...
>M. Debian intends to support multiple init systems, for the
> foreseeable future, and so long as their respective communities
> and code remain healthy. Software outside of an init system's
> implementation ma
On Tue, Jan 28, 2014 at 01:24:12PM +0100, Olav Vitters wrote:
> On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette wrote:
> > Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit :
> >> No. My question isn't about logind, but about using a user systemd
> >> session to supervise processe
On Tue, Jan 28, 2014 at 09:12:54AM -0800, Keith Packard wrote:
> Ian Jackson writes:
>
> > I think it doesn't make sense to allow people to require a non-default
> > init.
>
> I think this position is consistent with allowing each maintainer broad
> autonomy, and not overly burdening them with r
On Tue, Jan 28, 2014 at 12:08:19PM -0800, Don Armstrong wrote:
> On Tue, 28 Jan 2014, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Jan 28, 2014 at 11:23:11AM -0800, Don Armstrong wrote:
> > > The former. So :
> > >
> > >Where feasible, software should interoperate with non-default init
> > >
On Wed, Jan 29, 2014 at 10:05:22AM +0100, Josselin Mouette wrote:
> Le mardi 28 janvier 2014 à 19:34 +0200, Adrian Bunk a écrit :
> > On Tue, Jan 28, 2014 at 01:24:12PM +0100, Olav Vitters wrote:
> > > On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette wrote:
> > > >
On Tue, Jan 28, 2014 at 07:05:01PM -0500, Michael Gilbert wrote:
> On Tue, Jan 28, 2014 at 12:42 PM, Adrian Bunk wrote:
> > For anyone intending to make Debian the laughingstock of the open source
> > world, here is a good opportunity:
> >
> > Debian decides that
On Tue, Jan 28, 2014 at 10:50:00PM +0100, Olav Vitters wrote:
>...
> Further, in my
> experience it was *way* more stable to either go for full systemd or
> always rely on the reduced functionality. The runtime detection of "is
> systemd running as PID 1" was IMO not very stable (and that wasn't ju
On Wed, Jan 29, 2014 at 06:41:11PM +0100, Josselin Mouette wrote:
> Le mercredi 29 janvier 2014 à 19:03 +0200, Adrian Bunk a écrit :
>...
> > Assuming jessie will support multiple init systems, why would GNOME need
> > a dependency on systemd?
>
> Because
On Wed, Jan 29, 2014 at 07:17:29PM +0100, Josselin Mouette wrote:
> Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit :
> > What *basic functionality* exactly is missing in GNOME 3.10 without logind?
> >
> > Note that I am not referring to bugs that are no
On Wed, Jan 29, 2014 at 11:27:53AM -0800, Russ Allbery wrote:
> Adrian Bunk writes:
> > On Wed, Jan 29, 2014 at 07:17:29PM +0100, Josselin Mouette wrote:
> >> Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit :
>
> >>> What *basic functionality*
On Wed, Jan 29, 2014 at 09:24:16PM +0100, Matthias Klumpp wrote:
> 2014-01-29 Adrian Bunk :
> > [...]
> > I do fully acknowledge that there are issues with ConsoleKit being
> > unmaintained and many non-systemd codepath in GNOME being unmaintained
> > and with G
On Fri, Jan 31, 2014 at 03:02:21PM +0100, Sébastien Villemot wrote:
> Le vendredi 31 janvier 2014 à 11:55 +, Neil McGovern a écrit :
> > On Fri, Jan 31, 2014 at 09:33:33AM +0100, Josselin Mouette wrote:
> > > Given the Condorcet voting method is susceptible to tactical voting,
> >
> > Hi Josse
On Sat, Feb 01, 2014 at 10:44:27PM -0800, Russ Allbery wrote:
>...
> I think L is a bad technical design, regardless of the relative merits of
> the possible init systems that we might switch to. It's effectively
> equivalent to requiring sysvinit support for all packages indefinitely,
> and if we
On Sun, Feb 02, 2014 at 11:44:55AM -0800, Russ Allbery wrote:
> Adrian Bunk writes:
>
> > No, it does not require sysvinit support for all packages indefinitely.
>
> > The current TC decision is *for jessie*.
>
> The D/U/O/V/GR options are for jessie. T and L aren&
On Mon, Feb 03, 2014 at 07:45:19AM -0700, Bdale Garbee wrote:
> Ian Jackson writes:
>
> > Yes. I would still prefer to see something like that. I don't
> > remember exactly what the objections were and I'm very very tired now
> > but perhaps something like
> >
> > We expect that Debian will c
On Mon, Feb 03, 2014 at 03:13:06PM +, Ian Jackson wrote:
> Bdale Garbee writes ("Bug#727708: package to change init systems"):
> > I've been trying to avoid making decisions now about what happens beyond
> > jessie, but I would not object to including that text since I think it's
> > true for a
On Wed, Feb 05, 2014 at 09:56:14AM -0800, Steve Langasek wrote:
>...
> 8. OT openrc default in jessie, requiring specific init is allowed
> 8. VT sysvinit default in jessie, requiring specific init is allowed
>...
Is this a typo or an intentional equal ranking?
cu
Adrian
--
"Is
On Fri, Jan 31, 2014 at 06:06:35PM +0200, Adrian Bunk wrote:
>...
> So if for example 4 members of the TC would say "only systemd is an
> acceptable choice", and the other 4 members of the TC would say "only
> upstart is an acceptable choice", then any result o
On Thu, Feb 06, 2014 at 10:20:02AM +0100, Didier 'OdyX' Raboud wrote:
>...
> Now, I think there is currently a shared agreement in Debian that
>
> "all Debian packages (unless there's a good reason) should run on
> sysvinit + Linux + amd64 , support outside that is best-effort"
sysvinit
On Fri, Feb 07, 2014 at 07:22:10AM +1000, Anthony Towns wrote:
> On 7 February 2014 06:20, Ian Jackson wrote:
> > Don Armstrong writes ("Bug#727708: Call for votes on init system
> > resolution"):
> >> Given the already stated preferences of the CTTE, and the previous votes
> >> we've already had
On Thu, Feb 06, 2014 at 02:20:51PM -0800, Russ Allbery wrote:
>...
> This is one of the major reasons why I'm voting GR second. I see Bdale's
> point that we shouldn't abdicate our responsibility to make the best
> decision that we can, and I followed that maxim by voting my preference
> first. B
On Fri, Feb 07, 2014 at 08:59:59AM +1000, Anthony Towns wrote:
> On 7 February 2014 08:44, Adrian Bunk wrote:
> > If Colin joins Ian, Andreas and Steve in voting DT and UT below FD,
> > then T is dead.
>
> It's really pretty terrible to actively use FD to try to block
On Fri, Feb 07, 2014 at 01:08:46AM -0800, Keith Packard wrote:
> Russ Allbery writes:
>
> > I consider the L option as currently written to be a commitment to a
> > course of action that is technically broken and unsustainable. I also
> > think the effect of L is contrary to its intended goal an
On Fri, Feb 07, 2014 at 10:42:13AM -0800, Russ Allbery wrote:
> Andreas Barth writes:
> > * Russ Allbery (r...@debian.org) [140207 02:09]:
>
> >> I also flatly disagree with Adrian over whether we're deadlocked. I
> >> don't see any point in discussing it, though.
>
> > I agree with you, I don'
On Sat, Feb 08, 2014 at 04:40:22AM +, Anthony Towns wrote:
> Bug cc dropped, replaced with -ctte.
>
> On Fri, Feb 07, 2014 at 08:29:27AM +0200, Adrian Bunk wrote:
> > On Fri, Feb 07, 2014 at 08:59:59AM +1000, Anthony Towns wrote:
> > > It's really pretty terrible
On Sun, Feb 09, 2014 at 01:17:50AM +1000, Anthony Towns wrote:
> On 8 February 2014 18:26, Adrian Bunk wrote:
> > On Sat, Feb 08, 2014 at 04:40:22AM +, Anthony Towns wrote:
>...
> > I'd actually call it a bug in the voting system that the casting vote
> > might de
On Sat, Feb 08, 2014 at 12:38:21PM -0800, Russ Allbery wrote:
>...
> I don't see any reason why,
> say, mountall or socklog-run should be required to support sysvinit.
>...
What about udev?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness.
On Tue, Feb 11, 2014 at 08:22:19PM +0100, Kurt Roeckx wrote:
> On Tue, Feb 11, 2014 at 10:59:34AM -0800, Steve Langasek wrote:
> > On Tue, Feb 11, 2014 at 12:18:41PM -0500, Sam Hartman wrote:
> > > > "Bdale" == Bdale Garbee writes:
> >
> > > Bdale> Steve Langasek writes:
> > > >> FWI
On Wed, Feb 12, 2014 at 09:56:42AM -0800, Russ Allbery wrote:
>...
> All packages should support
> smooth upgrades from wheezy to jessie, including upgrades done on a
> system booted with sysvinit.
>...
This sounds like a statement by the TC that smooth upgrades from wheezy
to jessie
On Wed, Feb 12, 2014 at 11:35:11AM -0800, Russ Allbery wrote:
> Adrian Bunk writes:
> > On Wed, Feb 12, 2014 at 09:56:42AM -0800, Russ Allbery wrote:
>
> >>...
> >> All packages should support
> >> smooth upgrades from wheezy to jessie, including up
On Wed, Feb 12, 2014 at 06:09:38PM +0100, Lucas Nussbaum wrote:
> Hi,
>
> I must admit that I only followed this part of the discussion from a
> distance.
>
> However, one thing really strikes me:
>
> On 12/02/14 at 14:08 +, Ian Jackson wrote:
> > [loose coupling]
> >
> >Software outsid
On Tue, Oct 04, 2016 at 10:30:01AM -0400, Sam Hartman wrote:
>...
> Here are some factors to consider:
>
> 1) It's not clear to several TC members that the FTP team has decided
> on this question. It seems fairly clear how they would decide if they
> did decide, but from a process standpoint, it
On Tue, Oct 04, 2016 at 05:54:55PM -0400, Sam Hartman wrote:
> >>>>> "Adrian" == Adrian Bunk writes:
>
> Adrian> In other words, the best way forward for getting any
> Adrian> decision would be an RC bug against perl claiming that the
>
On Wed, Oct 05, 2016 at 12:59:36PM +0100, Ian Jackson wrote:
>...
> I think the TC has many reasonable options.
>
> * You could say that you think you aren't authorised, by the
>constitution, to overrule a decision on DFSG-ness, and invite the
>petitioners to consider a GR.
In any case t
On Wed, Oct 05, 2016 at 10:00:53AM -0400, Sam Hartman wrote:
>...
> I think it's clear that the TC believes that this package is not DFSG
> free.
> I think it's clear that the TC believes perl would be better if the
> situation was improved.
> I thought it was clear we believed perl had a DFSG issu
On Wed, Oct 05, 2016 at 10:06:57AM -0500, Don Armstrong wrote:
> On Wed, 05 Oct 2016, Adrian Bunk wrote:
> > Please describe the relevant differences between browserified
> > javascript and perl that make the TC believe that the former has a
> > DFSG issue but the latter proba
On Wed, Oct 05, 2016 at 08:21:40PM +0200, Philip Hands wrote:
> Adrian Bunk writes:
>
> > Why are TC members complaining that they do not even properly understand
> > what "browserified" means, instead of using the power to give advice to
> > structure the
On Thu, Oct 06, 2016 at 01:13:16AM -0400, Joseph R. Justice wrote:
> For the record, I wish the message I am now responding to, and other
> subsequent responses and discussion, were being sent to the bug mail
> address *in addition to* all the other addresses they're being sent to.
>...
For the re
On Thu, Oct 06, 2016 at 10:43:00AM +0100, Ian Jackson wrote:
> Adrian Bunk writes ("Re: Bug#839570: Browserified javascript and DFSG 2
> (reopening)"):
> > Perl's Configure or SQLite are other examples of code with similar
> > issues currently in Debian, and it
On Thu, Oct 06, 2016 at 11:48:36AM +0200, Philip Hands wrote:
>...
> The security team are going to have to track down every instance of that
> code and fix it. If the bug is something to do with an interaction
> between the code and the tools used to "browserifiy" the code, that may be
> non-triv
On Thu, Oct 06, 2016 at 02:23:37PM +0200, Didier 'OdyX' Raboud wrote:
>...
> All of the above are imperfections (yes, bugs) in how src:firefox handles its
> internal sqlite3.c code copy. In an ideal world:
>
> * src:sqlite3 would provide sqlite3.c in a binary package (sqlite3-static ?)
> * src:fi
On Thu, Oct 06, 2016 at 07:26:06PM +0200, Tollef Fog Heen wrote:
>...
> I think it'd be preferable for the software to be in contrib (AFAIK
> there's nothing here which is non-free?)
>...
When a package is not DFSG-free it is non-free.
Only DFSG-free packages that depend on non-free software are
On Thu, Oct 06, 2016 at 07:48:28PM +0200, Tollef Fog Heen wrote:
> ]] Adrian Bunk
>
> > On Thu, Oct 06, 2016 at 07:26:06PM +0200, Tollef Fog Heen wrote:
> > >...
> > > I think it'd be preferable for the software to be in contrib (AFAIK
> >
On Thu, Oct 06, 2016 at 09:48:02AM +0200, Vincent Bernat wrote:
> ❦ 5 octobre 2016 22:49 CEST, Philip Hands :
>
> > If you fancy explaining what you think browserified means w.r.t. the
> > Jison stuff, go ahead of course. That might at least help to focus the
> > discussion a bit. Just don't
Hi,
looking at something where I worked on the upstream implementation ages ago:
https://sources.debian.org/src/liferea/1.12.4-1/debian/patches/ubuntu-example-feeds.patch/
It is a common problem that users should be able to get started quickly
after installing a program.
When liferea is started
On Fri, Aug 17, 2018 at 09:49:00AM +0200, Tollef Fog Heen wrote:
> ]] Adrian Bunk
>
> > Hi,
> >
> > looking at something where I worked on the upstream implementation ages ago:
> > https://sources.debian.org/src/liferea/1.12.4-1/debian/patches/ubuntu-example-feeds.
On Fri, Aug 17, 2018 at 08:58:49AM -0700, Sean Whitton wrote:
> Hello,
>
> On Fri 17 Aug 2018 at 12:01AM +0300, Adrian Bunk wrote:
>
> > On Mon, Jul 23, 2018 at 09:22:17AM +0800, Sean Whitton wrote:
> >> For example, someone might want to use a Debian system to i
On Fri, Aug 17, 2018 at 07:33:02PM +0100, Ian Jackson wrote:
> Adrian Bunk writes ("Bug#904302: Why outlawing vendor-specific patch series
> would be a bad idea"):
> > The main misconception is that there would always be *the* source.
> >
> > Steps you might
On Sat, Aug 18, 2018 at 11:31:06AM -0700, Sean Whitton wrote:
> Hello,
>
> On Fri 17 Aug 2018 at 07:36PM +0300, Adrian Bunk wrote:
>
> > The main misconception is that there would always be *the* source.
> >
> > Steps you might have before the compilation starts
On Sun, Aug 19, 2018 at 12:11:01PM -0700, Sean Whitton wrote:
>...
> On Sun 19 Aug 2018 at 09:51PM +0300, Adrian Bunk wrote:
>...
> > For a user it doesn't make a difference which tool applies the patches.
>
> In my mind, it does; it matters whether or not it is p
On Sun, Aug 19, 2018 at 10:13:56PM +0200, Philip Hands wrote:
> Adrian Bunk writes:
>
> ...
> >> "The source" is what you get after steps 1 and 2.
> >
> > Why is "The source" what you get after dpkg applied patches,
> > but before debi
On Mon, Aug 20, 2018 at 09:28:30AM +0200, Wouter Verhelst wrote:
> On Mon, Aug 20, 2018 at 12:15:00AM +0300, Adrian Bunk wrote:
> > How should we handle architecture-specific patches properly inside
> > Debian?
>
> Why should there ever be architecture-specific patches?
On Wed, Sep 19, 2018 at 02:39:23PM +0200, Philip Hands wrote:
>...
> The Committee therefore resolves that:
>
> 1. Any use of dpkg's vendor-specific patch series feature is a bug for
> packages in the Debian archive (including contrib and non-free),
This misses an important part of the p
On Thu, Oct 04, 2018 at 01:32:08PM +0100, Ian Jackson wrote:
> Adrian Bunk writes ("Bug#904302: Whether vendor-specific patch series should
> be permitted in the archive"):
> > On Wed, Sep 19, 2018 at 02:39:23PM +0200, Philip Hands wrote:
> > > The Co
On Thu, Oct 04, 2018 at 08:21:07PM +0200, Philip Hands wrote:
>...
> IMO policy should recomend the use of separate source packages as the
> prefered solution to the problem that vendor-specific patch series were
> supposed to address.
In this case please make an explicit decision on whether build
On Fri, Oct 05, 2018 at 08:49:47AM +0200, Philip Hands wrote:
> Adrian Bunk writes:
>
> > On Thu, Oct 04, 2018 at 08:21:07PM +0200, Philip Hands wrote:
> >>...
> >> IMO policy should recomend the use of separate source packages as the
> >> prefered solut
On Tue, Jul 23, 2019 at 01:54:10PM +0200, Santiago Vila wrote:
>...
> * I'm told that single-cpu systems are an oddity and that most
> physical machines manufactured today are multi-core, but this
> completely fails to account that single-cpu systems are today more
> affordable than ever thanks to
On Tue, Jul 23, 2019 at 01:30:58PM +0100, Ian Jackson wrote:
> Santiago Vila writes ("Bug#932795: Ethics of FTBFS bug reporting"):
>...
> On the point at issue, do these packages build in a cheap single-vcpu
> vm from some kind of cloud vm service ? ISTM that this is a much
> better argument than
On Tue, Jul 23, 2019 at 08:45:42PM +0200, Ansgar wrote:
> Adrian Bunk writes:
> > - An environment with at least 16 GB RAM is supported.
> >
> > Not sure about the exact number, but since many packages have
> > workarounds for gcc or ld running into the 4 GB address sp
On Wed, Jul 24, 2019 at 11:34:53AM +0200, Santiago Vila wrote:
>...
> This is a Makefile bug in gcc-8-cross, a package which would qualify
> as "big". Maintainer did not initially believe it was a real bug,
> maybe because he built the package a lot of times in the past and the
> bug never happened
On Thu, Jul 25, 2019 at 09:16:53AM +0100, Colin Watson wrote:
> On Tue, Jul 23, 2019 at 06:11:04PM +0300, Adrian Bunk wrote:
> > On Tue, Jul 23, 2019 at 01:30:58PM +0100, Ian Jackson wrote:
> > > Santiago Vila writes ("Bug#932795: Ethics of FTBFS bug reporting"):
&g
On Thu, Jul 25, 2019 at 01:22:42PM +0200, Santiago Vila wrote:
> On Wed, Jul 24, 2019 at 12:05:45PM +0100, Simon McVittie wrote:
>...
> Ok, my build environment:
>
> * Had enough RAM.
> * Had enough disk.
>...
> The only thing it did not have was more than one CPU, but AFAIK that's
> not something
On Fri, Jul 26, 2019 at 07:05:50PM +0200, Santiago Vila wrote:
>...
> https://people.debian.org/~sanvila/single-cpu/
>...
> The practical implications of this is that we are currently forcing
> users to spend extra money if they want *assurance* that all the
> packages (and not just "most" of them)
On Tue, Jul 30, 2019 at 02:40:06PM +0200, Santiago Vila wrote:
>...
> This is really like a weak form of "reproducible builds", as in "every
> time I try to build the package in a capable system, the build succeeds".
Is a single-core system capable of rebuilding a package with parallel=64 ?
> The
On Tue, Jul 30, 2019 at 09:05:04PM +0200, Santiago Vila wrote:
> Quoting Debian Policy:
>
> Packages should build reproducibly, which for the purposes of this
> document [19] means that given
>
> a version of a source package unpacked at a given path;
> a set of versions of installed bu
Package: tech-ctte
Severity: normal
This is a request to override the maintainer of debianutils on several
changes that were done to the package in unstable after the release of
bullseye.
More specifically, I am asking the Technical Committee to decide that:
1. The "which" program must be provi
On Wed, Sep 15, 2021 at 09:20:34AM +0200, Helmut Grohne wrote:
> On Wed, Sep 15, 2021 at 01:36:26AM +0300, Adrian Bunk wrote:
>...
> > 1. The "which" program must be provided by an essential package.
>
> This request seems overzealous to me. Banning the shrinking of
On Thu, Sep 16, 2021 at 03:02:57PM -0700, Sean Whitton wrote:
> Hello Adrian,
>
> On Wed 15 Sep 2021 at 01:36AM +03, Adrian Bunk wrote:
>
> > Package: tech-ctte
> > Severity: normal
> >
> > This is a request to override the maintainer of debianutils on sever
1 - 100 of 102 matches
Mail list logo
