On Oct 31, "Theodore Y. Ts'o" wrote:
> handled on a case by case basis. Exactly how much of a win do we get
> if we use a particular systemd feature in core Debian packaging? How
> hard is it to emulate that for non-systemd systems? I don't think
> that decision can be made in the abstract, un
Dear all,
with salsa and most of the packaging going on in git I wonder whether
we could add using MRs as an alternative way to communicate the diff
that is related to an NMU instead of adding a patch to the related bug.
When preparing an NMU people might already be using git anyway, and if
one
Hi,
On Wed, Oct 30, 2019 at 05:17:57PM -0700, Russ Allbery wrote:
> One can individually say that one doesn't care about those features, but
> we just cannot say Debian as a whole should not care about those features.
> It doesn't work. We have to take an affirmative stance on what Debian is
> g
Sean Whitton writes ("Re: [RFC] Proposal for new source format"):
> Sorry, I didn't phrase my suggestion carefully. I was assuming that we
> will continue to expect maintainers to accept patches in the BTS, but
> that if they *prefer* something else, they could document that in
> README.source.
>
On Wed, Oct 30, 2019 at 05:01:56PM +0100, Guillem Jover wrote:
This indeed works in Debian, but I think it's strictly speaking
incorrect according to POSIX, and as such is non-portable.
It's non portable in a way which hasn't been relevant in more than 20
years and as such isn't worth wasting
Simon Richter writes:
> On Wed, Oct 30, 2019 at 05:17:57PM -0700, Russ Allbery wrote:
>
>> One can individually say that one doesn't care about those features, but
>> we just cannot say Debian as a whole should not care about those features.
>> It doesn't work. We have to take an affirmative stanc
Russ Allbery writes:
> Josh Triplett writes:
>
>> Part of the problem is that the people interested in sysvinit don't tend
>> to care about those features and often argue that others shouldn't care
>> either, and the people interested in those features don't tend to care
>> about sysvinit. It's di
Hi!
I thought about just silently unsubscribing from debian-devel… but as I
got the impression that almost no one argues for the freedom to choose
the init system here in this thread, I decided to speak up:
Theodore Y. Ts'o - 31.10.19, 00:57:48 CET:
> And if we do this in core Debian infrastruc
Martin Steigerwald - 31.10.19, 13:19:56 CET:
> While I do not expect maintainers of Debian packages to implement
> support for alternate init systems themselves, I still believe if
> someone works constructively and consistently on making such support
> available in Debian, it would be good to be i
Martin Steigerwald writes ("Re: Integration with systemd"):
> As to this, I did not yet see that the migration of elogind to testing
> has been accepted.
Yes.
I find these conversations draining, exhausting, awful. I am sure
that most people who are sceptical of systemd agree. The constant
neg
Package: wnpp
Severity: wishlist
Owner: Gordon Ball
* Package name: python-backcall
Version : 0.1.0
Upstream Author : Thomas Kluyver
* URL : https://github.com/takluyver/backcall
* License : BSD
Programming Lang: Python
Description : Specify callback fu
Hi,
firefox-esr package doesn't migrate to testing but I cannot
find the reason at https://qa.debian.org/excuses.php?package=firefox-esr
Could someone tell me why, please?
--
Hideki Yamane
On 2019-10-31 at 10:25, Hideki Yamane wrote:
> Hi,
>
> firefox-esr package doesn't migrate to testing but I cannot
> find the reason at https://qa.debian.org/excuses.php?package=firefox-esr
>
> Could someone tell me why, please?
Quoted from that page:
>> Issues preventing migration:
>> fir
According to https://qa.debian.org/excuses.php?package=firefox-esr , firefox-
esr build-depends on nodejs, which is not available on armel anymore
(explicitly not built on armel). Since armel is an release architecture,
firefox-esr won't migrate to Testing when its armel build is missing.
The excu
On Oct 31, Simon Richter wrote:
> However, a lot of our software comes from the BSD world and will never
> fully switch to systemd, and that software is often used in server contexts
> by people who know exactly what they are doing. I don't see why we
> shouldn't support these people anymore, esp
FYI: https://bugs.debian.org/818552#15
P.
On 31/10/19 16:08, Boyuan Yang wrote:
> According to https://qa.debian.org/excuses.php?package=firefox-esr , firefox-
> esr build-depends on nodejs, which is not available on armel anymore
> (explicitly not built on armel). Since armel is an release archi
On Thu, Oct 31, 2019 at 01:19:56PM +0100, Martin Steigerwald wrote:
> alienate me away from Debian. This laptop, for the sake of packaging
> flexible I/O tester, is the last of my machines still running on Debian.
> All the others are running Devuan. I am not looking back. I have no
> intention
On Thu, Oct 31, 2019 at 11:09 PM Boyuan Yang wrote:
>
> According to https://qa.debian.org/excuses.php?package=firefox-esr , firefox-
> esr build-depends on nodejs, which is not available on armel anymore
> (explicitly not built on armel). Since armel is an release architecture,
> firefox-esr won'
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: uwsgi-apparmor
Version : 0.0.0+git.2014.09.15.7d6d7bd7eb
Upstream Author : Unbit
* URL : https://github.com/unbit/uwsgi-apparmor
* License : Expat
Programming Lang: C, Python
Descriptio
Theodore Y. Ts'o - 31.10.19, 16:03:29 CET:
> On Thu, Oct 31, 2019 at 01:19:56PM +0100, Martin Steigerwald wrote:
> > alienate me away from Debian. This laptop, for the sake of packaging
> > flexible I/O tester, is the last of my machines still running on
> > Debian. All the others are running Devua
Marco d'Itri - 31.10.19, 15:45:47 CET:
> On Oct 31, Simon Richter wrote:
[…]
> > The freedom to configure a system without things I do not want is
> > one of the main reasons that made me switch over from Windows to
> > Debian, a bit more than twenty years ago.
>
> http://www.islinuxaboutchoice.c
Russ,
On 10/29/19 11:19 PM, Russ Allbery wrote:
> [...] we do not have clear
> project consensus that sysvinit support is mandatory in new packages, so
> the support is starting to bitrot, and given the lack of clear project
> guidance, no one is clearly empowered to prevent it from bitrotting.
I
Am 31.10.19 um 16:28 schrieb Aron Xu:
This could be a reminder that we should start thinking about whether
we want to keep armel as a release architecture for bullseye.
No, but some X-based applications might simply get excluded from the
that architecture. There are still a lot armv5 based har
Russ Allbery wrote:
> Josh Triplett writes:
> > Part of the problem is that the people interested in sysvinit don't tend
> > to care about those features and often argue that others shouldn't care
> > either, and the people interested in those features don't tend to care
> > about sysvinit. It's d
On Thu, 2019-10-31 at 15:45 +0100, Marco d'Itri wrote:
> > On Oct 31, Simon Richter wrote:
> >
> > No, and that's not our job. There are a lot of people out there
> > building non-systemd systems.
> Data says: not really a lot.
When elogind enters testing there would be many more people running
Thomas Goirand schrieb:
> My understanding is that the current guidance is that doing init script
> isn't mandatory.
With policy not updated, people claim it's mandatory, see e.g.
#925473 on Tomcat.
The discussed GRs would provide clarification on what the project
at large actually wants (and wh
Package: ftp.debian.org
Hideki Yamane writes:
> firefox-esr package doesn't migrate to testing but I cannot
> find the reason at https://qa.debian.org/excuses.php?package=firefox-esr
I believe we should remove firefox-esr/armel to allow the current
version to migrate to testing.
Ansgar
On Thu, 31 Oct 2019 18:40:58 +0100
Thomas Goirand wrote:
> On 10/29/19 11:19 PM, Russ Allbery wrote:
> > of clear project guidance, no one is clearly empowered to prevent
> > it from bitrotting.
What is wrong with bitrotting if nobody cares about - in case nobody
cares about it's the logical co
Hi,
On Thu, Oct 31, 2019 at 03:45:47PM +0100, Marco d'Itri wrote:
> > That is work we have to do regardless of whether we want to support
> > alternatives or not, but in the simple case we just list what is supported
> > by the systemd version we have decided to ship in the last stable release,
>
Simon Richter dijo [Wed, Oct 30, 2019 at 12:46:21PM +0100]:
> Hi,
>
> On Tue, Oct 29, 2019 at 10:38:32PM +0100, Thomas Goirand wrote:
>
> > If we have such vote again, I'll continue on this direction: I'd prefer
> > if we didn't have to vote.
>
> >From a Policy perspective, packages are supposed
Ian Jackson writes:
> The question is: are we going to permit those technical contributions
> into Debian ? Are we going to keep making it awkward or are we actually
> going to _welcome_ them ?
> Are we going to say to those of our contributors who want to see a nice
> tidy hegemony, "sure, thr
Simon Richter writes:
>> > No, and that's not our job. There are a lot of people out there building
>> > non-systemd systems.
[...]
> My point with that sentence is a different one though: a lot of Free
> Software exists outside the Linux sphere that does neither anticipate nor
> require tight inte
Svante Signell writes:
> And as said numerous times Debian maintainers don't have to create
> sysvinit scripts, they have only to _accept_ patches to add or fix
> sysvinit scripts.
Even as someone who does not really care about the init system (being a
desktop user, I use whatever is the base the
On Thu, Oct 31 2019, Theodore Y. Ts'o wrote:
> It may be that sysvinit is doomed. But we shouldn't be accelerating
> the process.
You are quite right. I have also found myself wondering, though, what
are the BSDs doing? Clearly systemd isn't going to be workable for
them. Is their approach s
On 10/31/19 7:36 PM, Moritz Mühlenhoff wrote:
> Thomas Goirand schrieb:
>> My understanding is that the current guidance is that doing init script
>> isn't mandatory.
>
> With policy not updated, people claim it's mandatory, see e.g.
> #925473 on Tomcat.
Well, the policy is wrong, and should be
On 10/31/19 8:07 PM, Alf Gaida wrote:
> I read it the same way - and also a logical consequece: if these
> patches lead to bugs, the maintainer should not be forced to fix the
> mess. I for myself would just remove buggy things that nobody care in a
> certain amount of time.
I'd be very much fine
On Thu, Oct 31, 2019 at 01:44:58PM +, Ian Jackson wrote:
> Martin Steigerwald writes ("Re: Integration with systemd"):
> > As to this, I did not yet see that the migration of elogind to testing
> > has been accepted.
>
> Yes.
>
> I find these conversations draining, exhausting, awful. I am
Hello,
On Thu 31 Oct 2019 at 12:00PM +01, Gert Wollny wrote:
> "Then, you either prepare the NMU in a fork of the original packaging
> repository and submit a merge request referencing the bug you are
> fixing, or send a patch containing the differences between the current
> package and your prop
Thomas Goirand schrieb:
> "I’d very happily maintain the init script."
>
> I haven't read all the bug entry, but if someone is claiming that
> accepting such contribution is mandatory, then that's very much right,
> at least that the consensus we're in right now, indeed.
This isn't limited to jus
Hello,
On Thu 31 Oct 2019 at 11:59AM +00, Ian Jackson wrote:
> Well, that's fair enough as far as it goes. But I think we could do
> better.
>
> It would be possible to imagine some service that works like this:
> [...]
This would be cool!
--
Sean Whitton
signature.asc
Description: PGP sign
On 10/30/19 10:54 PM, Josh Triplett wrote:
> It seems evident based on the history of such efforts that there is
> *not* sufficient people/interest/motivation to reimplement the majority
> of systemd features, let alone doing so in a way that meets the
> additional constraints imposed on such solut
On Oct 31, Svante Signell wrote:
> When elogind enters testing there would be many more people running
> Debian with sysvinit/elogind. elogind is needed for desktop usage when
> not using systemd as PID 1. And as said numerous times Debian
elogind is already in testing: I will be delighted to see
On Fri, 1 Nov 2019 at 08:27, Thomas Goirand wrote:
> However, this doesn't mean that anything non-systemd must implement all
> things that systemd does, or just die. It really doesn't make sense to
> tell that, for example, OpenRC should be forced into implementing a
> parser of .timer files, jus
Craig Small writes:
> On Fri, 1 Nov 2019 at 08:27, Thomas Goirand wrote:
>> However, this doesn't mean that anything non-systemd must implement all
>> things that systemd does, or just die. It really doesn't make sense to
>> tell that, for example, OpenRC should be forced into implementing a
>>
On Thu, 31 Oct 2019 11:59:07 +, Ian Jackson wrote:
> * tag2upload service, or some related service:
> - determines that the maintainer is using a dgit-compatible git
> workflow, by looking at the tags, and looks at some in-dsc
> metadata to find the maintainer's repo
> - d
On 10/31/19 9:56 PM, Moritz Mühlenhoff wrote:
> This isn't limited to just shipping an init script, have a look at the
> tomcat9 9.0.13-1 changelog entry which dropped the sysvinit script.
> Continuing to support an init script also means to retain on all the
> packaging boilerplate which got obsol
On Thu, 31 Oct 2019 13:54:11 -0700, Sean Whitton wrote:
> On Thu 31 Oct 2019 at 12:00PM +01, Gert Wollny wrote:
> > "Then, you either prepare the NMU in a fork of the original packaging
> > repository and submit a merge request referencing the bug you are
> > fixing, or send a patch containing the
On 10/31/19 11:30 PM, Russ Allbery wrote:
> Craig Small writes:
>> On Fri, 1 Nov 2019 at 08:27, Thomas Goirand wrote:
>
>>> However, this doesn't mean that anything non-systemd must implement all
>>> things that systemd does, or just die. It really doesn't make sense to
>>> tell that, for exampl
On Thu, 2019-10-31 at 22:40 +0100, Marco d'Itri wrote:
> On Oct 31, Svante Signell wrote:
>
> > When elogind enters testing there would be many more people running
> > Debian with sysvinit/elogind. elogind is needed for desktop usage
> > when not using systemd as PID 1.
> elogind is already in t
On 10/31/19 9:32 PM, Theodore Y. Ts'o wrote:
> Let's take e2fsprogs for example. I had applied a patch which had a
> cron script alternative on top of the timer unit file. It turns out
> the cron script was buggy, and it took multiple tries before we got it
> right --- because I don't maintain a
Hi Martin!
On 10/31/19 5:13 PM, Martin Steigerwald wrote:
> It is similar with "the" cloud.
Why is there quotes around "the", and why do you think there's only a
single instance of a cloud out there?
> Yet, there are attempts to disrupt the cloud already by making
> machines powerful enough that
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 1259 (new: 2)
Total number of packages offered up for adoption: 249 (new: 1)
Total number of packages reques
Thomas Goirand writes:
> IMO, this type of decision should go in the policy, case by case, and
> I'm not sure a GR is the solution: it's going to be a generic "use all
> of systemd" vs a "be careful to use only things implemented elsewhere".
> I don't think this works, as often, there is maybe a
On 11/1/19 1:51 AM, Russ Allbery wrote:
> Thomas Goirand writes:
>
>> IMO, this type of decision should go in the policy, case by case, and
>> I'm not sure a GR is the solution: it's going to be a generic "use all
>> of systemd" vs a "be careful to use only things implemented elsewhere".
>> I don
Thomas Goirand writes:
> ...the bigger question is: why systemd-sysusers is part of systemd, and
> not a standalone thing, which we could make an essential package. If we
> want it to be part of a package standard toolkit, it means systemd
> becomes an essential package, which isn't really what w
55 matches
Mail list logo
