On Sat, 28 Dec 2019 13:49:18 +
Mo Zhou wrote:
> On Fri, Dec 27, 2019 at 04:00:33PM -0600, Michael Lustfield wrote:
> > I started a similar effort when I first became a trainee. Unfortunately, a
> > lot
> > of our non-trainees seem to be burned out, which means no reviews, and no
> > reviews m
Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 src:runc
Control: block 930440 by -1
Package name: golang-github-checkpoint-restore-go-criu
Version: 3.11
License:
> "Thomas" == Thomas Goirand writes:
Thomas> On 1/3/20 7:31 PM, Russ Allbery wrote:
Thomas> explore and develop alternate init systems and alternatives to
systemd
Thomas> features."
Thomas> Exploring alternatives is precisely what I'm doing. The same way
I've
Thomas> fe
On 2020-01-03 at 19:33, Simon McVittie wrote:
> On Fri, 03 Jan 2020 at 18:07:36 -0500, The Wanderer wrote:
>
>> What I'm concerned about is dbus socket activation, or similar,
>> leading to e.g. logind getting activated by logging in at the text
>> console.
>>
>> I thought I understood that sock
On Fri, 03 Jan 2020 at 18:07:36 -0500, The Wanderer wrote:
> What I'm concerned about is dbus socket activation, or similar, leading
> to e.g. logind getting activated by logging in at the text console.
>
> I thought I understood that socket activation via dbus was one of the
> features which didn
Am Sa., 4. Jan. 2020 um 00:16 Uhr schrieb Russ Allbery :
>
> The Wanderer writes:
>
> > What I'm concerned about is dbus socket activation, or similar, leading
> > to e.g. logind getting activated by logging in at the text console.
>
> > I thought I understood that socket activation via dbus was o
On Fri, 03 Jan 2020 at 14:43:48 -0800, Russ Allbery wrote:
> The Wanderer writes:
> > If I recall and understand correctly, installing systemd-the-package
> > will result in at least some of the daemons therein [being run]
>
> This is the bit that I'm fairly sure is not the case.
>
> All of the
The Wanderer writes:
> What I'm concerned about is dbus socket activation, or similar, leading
> to e.g. logind getting activated by logging in at the text console.
> I thought I understood that socket activation via dbus was one of the
> features which didn't require systemd as PID-1 to functio
On 2020-01-03 at 17:43, Russ Allbery wrote:
> The Wanderer writes:
>
>> If I recall and understand correctly, installing
>> systemd-the-package will result in at least some of the daemons
>> therein - including both systemd itself, and systemd-logind - being
>> set up to run automatically in the
The Wanderer writes:
> If I recall and understand correctly, installing systemd-the-package
> will result in at least some of the daemons therein - including both
> systemd itself, and systemd-logind - being set up to run automatically
> in the correct contexts (whether by scripted invocation set
(Here's another one I may later wind up regretting; I'm out on too many
if-I-remember and if-I-understand limbs, and am thus speaking based on
too many possibly-false premises, and I'm also now explaining personal
preferences which might readily be deemed too minor or too niche to be
reasonable to
On Jan 03, Thomas Goirand wrote:
> Could you please, therefore, tell me what feature is missing? If you
If I am not mistaken then you started arguing that we should consider an
hypothetical alternative implementation with missing features, so maybe
you should explain what may be missing.
> > A
Thomas Goirand writes:
> Yes, there's drawbacks in general. However, you *cannot* just say, we're
> going to use the systemd implementation "just because it's the
> refrence", without even giving me some space to at least *TRY* the
> alternative, to see if it's valuable or not.
Yes, I agree.
>
On 1/3/20 7:15 PM, Marco d'Itri wrote:
> On Jan 03, Thomas Goirand wrote:
>
>> That's where I don't agree. While it's nice to have such a declarative
>> system, I don't think it's reasonable to impose the implementation of
>> any change to systemd to all the other init systems.
> I do. Good luck
On Jan 03, Thomas Goirand wrote:
> Yes, there's drawbacks in general. However, you *cannot* just say, we're
> going to use the systemd implementation "just because it's the
> refrence", without even giving me some space to at least *TRY* the
As usual this is about much more than you, and I am qui
On 1/3/20 7:31 PM, Russ Allbery wrote:
> The guidance of option B is that we are committing to reviewing and
> working collaboratively with anyone who wants to support alternate init
> systems, but that implementation strategy is subject to technical review.
It reads:
"However, Debian remains an
On Fri, Jan 03, 2020 at 02:29:37PM -0500, The Wanderer wrote:
> The accepting of init scripts seemed to me like an essential piece of
> making sure those scripts would be present wherever they would be
> needed. Your suggestion above seems to provide a way to make it less
> essential, and thus woul
> "Russ" == Russ Allbery writes:
Russ> So far as I can tell, installing the systemd package by itself
shouldn't
Russ> do anything. It's possible that I'm wrong, but if so, it might be
easier
Russ> to just fix that problem rather than splitting out binaries. It's
also
Russ
The Wanderer writes:
> On 2020-01-03 at 13:35, Russ Allbery wrote:
>> The Wanderer writes:
>>> If the maintainers of systemd-the-package would be willing to not only
>>> split out these binaries into standalone package(s), but accept such
>>> init scripts for inclusion in those packages,
>> Why
On Fri, Jan 03, 2020 at 10:31:53AM -0800, Russ Allbery wrote:
> Support for kFreeBSD and Hurd is obviously a valid argument in favor of
> some level of support for non-systemd implementations.
But then there is the question on how much work it would be to port the
**systemd** implementations to Fr
On 2020-01-03 at 13:35, Russ Allbery wrote:
> The Wanderer writes:
>
>> Unless my understanding of the architecture of
>> systemd-the-init-system is entirely incorrect, running these
>> .service'es is handled by /bin/systemd. If having these programs
>> run at boot time is considered essential t
> "Marco" == Marco d'Itri writes:
>> You are being obviously biased toward systemd here. Just try to think a
Marco> Indeed: obviously, most people actually do not mind using systemd...
>> 2nd time: the same way, what if opentmpfiles implements a new feature
>> that is *not*
The Wanderer writes:
> Unless my understanding of the architecture of systemd-the-init-system
> is entirely incorrect, running these .service'es is handled by
> /bin/systemd. If having these programs run at boot time is considered
> essential to full functionality of these facilities - and I'd be
Thomas Goirand writes:
> I think you and many others should be extremely careful when talking
> about proposal B just as if it was a clear winner of the poll. If you
> are then discarding the opinion of everyone else who didn't want it as
> the winning option, and not consider the GR result as a
On Jan 03, Thomas Goirand wrote:
> That's where I don't agree. While it's nice to have such a declarative
> system, I don't think it's reasonable to impose the implementation of
> any change to systemd to all the other init systems.
I do. Good luck persuading the consumers of this API that they s
Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko
* Package name: tedana
Version : 0.0.8
Upstream Author : tedana developers
* URL : https://github.com/ME-ICA/tedana
* License : LGPL
Programming Lang: Python
Description : TE-dependent analysis
Package: src:linux
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ker...@lists.debian.org
libbpf source has moved to a separate github repo but keeps the kernel
as the true/first source, and updating github repo when release is ready.
In Steve's word the problem they faced
Package: wnpp
Severity: wishlist
Owner: Thomas Perret
* Package name: gfsecret
Version : 0.4.4
Upstream Author : Damien Goutte-Gattat
* URL : https://git.incenp.org/damien/gfsecret
* License : GPL-3.0+
Programming Lang: C
Description : Tools to make se
On 1/3/20 2:23 PM, Sam Hartman wrote:
> Proposal B is about letting you innovate (for example doing your own
> implementation of tmpfiles that you opt into on a per-package basis) and
> doing the integration work for alternatives like elogind where you
> cannot use the systemd interface.
>
> --Sa
On 2020-01-03 at 09:13, Ansgar wrote:
> The Wanderer writes:
>
>> However, as it remains the case that they are shipped in the same
>> package as /bin/systemd, and as I gather (mostly from this thread,
>> I think) that some of the ways they are expected to be invoked
>> probably rely on having s
On 2020-01-03 at 07:50, Ansgar wrote:
> The Wanderer writes:
>
>> On 2020-01-02 at 08:14, Thomas Goirand wrote:
>>
>>> As I wrote, no need to complain, but act.
>>>
>>> https://salsa.debian.org/debian/opentmpfiles
>>
>> For me (with no salsa account, therefore not logged in; I don't
>> know if
The Wanderer writes:
> On 2020-01-02 at 08:14, Thomas Goirand wrote:
>> As I wrote, no need to complain, but act.
>>
>> https://salsa.debian.org/debian/opentmpfiles
>
> For me (with no salsa account, therefore not logged in; I don't know if
> that makes any difference), this page states "The repos
The Wanderer writes:
> However, as it remains the case that they are shipped in the same
> package as /bin/systemd, and as I gather (mostly from this thread, I
> think) that some of the ways they are expected to be invoked probably
> rely on having systemd-the-daemon running
They don't rely on the
On 2020-01-03 at 08:50, Andrej Shadura wrote:
> Hi,
>
> On Fri, 3 Jan 2020 at 14:02, The Wanderer
> wrote:
>
>> On 2020-01-02 at 09:03, Sam Hartman wrote:
>>
>>> My understanding is that systemd's implementation of tmpfiles
>>> and sysusers works even while systemd is not pid 1. Why do we
>>>
Hi,
On Fri, 3 Jan 2020 at 14:02, The Wanderer wrote:
> On 2020-01-02 at 09:03, Sam Hartman wrote:
> > My understanding is that systemd's implementation of tmpfiles and
> > sysusers works even while systemd is not pid 1. Why do we need
> > multiple implementations for Debian ports where systemd ru
Control: reassign -1 gnome-shell
Matthias Brennwald, le ven. 03 janv. 2020 14:14:28 +0100, a ecrit:
> On Thu, 2 Jan 2020 20:15:29 +0100 Samuel Thibault
> wrote:
> > Hello,
> >
> > Matthias Brennwald, le jeu. 02 janv. 2020 20:06:27 +0100, a ecrit:
> > > the windows that have been opened before ac
Processing control commands:
> reassign -1 gnome-shell
Bug #947955 [general] general: Windows on second (external) screen are blurry
after notebook sleep
Bug reassigned from package 'general' to 'gnome-shell'.
Ignoring request to alter found versions of bug #947955 to the same values
previously
> "Thomas" == Thomas Goirand writes:
Thomas> On 1/3/20 2:33 AM, Sam Hartman wrote:
>> Secondly, by using systemd-tmpfiles when we can, we gain support for any
>> additional features that are implemented.
Thomas> That's where I don't agree. While it's nice to have such a
decl
On Thu, 2 Jan 2020 20:15:29 +0100 Samuel Thibault
wrote:
> Hello,
>
> Matthias Brennwald, le jeu. 02 janv. 2020 20:06:27 +0100, a ecrit:
> > the windows that have been opened before activating sleep mode are
> > blurry. Newly opened windows are not affected.
> > The issue happens with windows fr
On 2020-01-02 at 09:03, Sam Hartman wrote:
> My understanding is that systemd's implementation of tmpfiles and
> sysusers works even while systemd is not pid 1. Why do we need
> multiple implementations for Debian ports where systemd runs?
There are those who don't run systemd-the-daemon even as
On 2020-01-02 at 08:14, Thomas Goirand wrote:
> As I wrote, no need to complain, but act.
>
> https://salsa.debian.org/debian/opentmpfiles
For me (with no salsa account, therefore not logged in; I don't know if
that makes any difference), this page states "The repository for this
project is empt
On 03/01/2020 00:48, Simon McVittie wrote:
> Glib::Object::Introspection->invoke("GLib", undef, "set_prgname",
> "com.example.Test");
I hadn't thought of that!
Up to now, I'd only seen GIO used for gtk, and it didn't occur to me to
try it.
The user has confirmed that this solves the problem
On 1/3/20 2:33 AM, Sam Hartman wrote:
> Secondly, by using systemd-tmpfiles when we can, we gain support for any
> additional features that are implemented.
That's where I don't agree. While it's nice to have such a declarative
system, I don't think it's reasonable to impose the implementation of
On Fri, Jan 03, 2020 at 09:20:44AM +0100, Thomas Goirand wrote:
> On 1/2/20 6:01 PM, Matthias Plump wrote:
> > I don't have both of those. Since I am on an usrmerged system though,
> > /bin/systemd-sysusers and /usr/bin/systemd-sysusers are exactly the
> > same binary. Maybe that's the thing that c
On Fri, 03 Jan 2020 at 09:18:58 +0100, Thomas Goirand wrote:
> ... after this discussion, it looks like we would prefer:
> /bin/systemd-tmpfiles and /bin/systemd-sysusers
>
> For this, we need systemd to use update-alternatives for them then, so
> that opentmpfiles & opensysusers do not need to us
On 1/2/20 6:01 PM, Matthias Plump wrote:
> I don't have both of those. Since I am on an usrmerged system though,
> /bin/systemd-sysusers and /usr/bin/systemd-sysusers are exactly the
> same binary. Maybe that's the thing that caused a bit of confusion?
I'm not on a usrmerged system, and I have bot
On 1/2/20 5:13 PM, Ansgar wrote:
> Thomas Goirand writes:
>> My proposal is for Debian to standardize on:
>> /bin/tmpfiles
>> and:
>> /usr/bin/sysusers
>
> Why rename things?
I don't mind either ways, but...
... after this discussion, it looks like we would prefer:
/bin/systemd-tmpfiles and /bin
On 1/2/20 7:08 PM, Russ Allbery wrote:
> I really want to get rid of maintainer scripts as much as possible in
> favor of pure declarative syntax in the packages. I think the fewer
> Debian packages that need maintainer scripts, the easier the distribution
> as a whole will be to maintain, analyze
On 1/2/20 6:28 PM, Simon McVittie wrote:
> On systemd systems, that's approximately:
>
> - run systemd-tmpfiles when a package installs a tmpfiles.d snippet
> (this is added to the package's postinst by dh_installsystemd)
>
> - run systemd-sysusers when a package installs a sysusers.d snippet
>
49 matches
Mail list logo
