On Wed, 27 Nov 2019 at 11:27:13 +, Chris Lamb wrote:
> May I gently request we replace the use of the word "diversity"
> throughout the "init systems and systemd" General Resolution prior to
> it being subject to a plebiscite?
Thank you for raising this, Chris.
I agree. I have been uncomforta
On Sun, 01 Dec 2019 at 11:13:46 -0800, Russ Allbery wrote:
> Simon Richter writes:
> > Right, but the dependency chain is there to make sure the package is
> > usable on systemd systems
>
> My recollection is that these dependencies are mostly about either making
> sure user sessions are available
On Sun, 01 Dec 2019 at 22:02:31 +0100, Simon Richter wrote:
> In that particular case, the user session must be available to allow
> activation of gsettingsd via dbus
There is no such thing as gsettingsd. Presumably you mean dconf-service
(which is conceptually one of many backends, although in pr
On Sun, 01 Dec 2019 at 22:14:06 +0100, Laurent Bigonville wrote:
> It's bin:libpam-systemd that pulls bin:systemd-sysv (the package that makes
> systemd the init on the system), not bin:systemd. Here it's dbus-user-session
> that pulls it because it needs a logind (dunno if it works with elogind)
>
On Mon, 02 Dec 2019 at 04:26:53 +0100, Simon Richter wrote:
> My expectation was that with systemd, dbus activation functionality
> would have moved into the main systemd binary for better process
> tracking and to avoid code duplication with the other activation methods.
Yes ish, but on an opt-in
On Mon, 02 Dec 2019 at 00:28:54 +0100, Simon Richter wrote:
> Wasn't there a plan to add support for containers managed through
> systemd that have filtered access to the system dbus, or is that just a
> special case of a service unit?
As a general rule, "heavyweight" containers with their own ini
On Sun, 08 Dec 2019 at 09:37:07 +, Anthony DeRobertis wrote:
> it seems like there is an alternative — have them provided by
> a different package. Probably one package providing quite a few of
> them. It'd need some way to only try to start installed daemons, but
> that sounds solvable.
Not o
On Thu, 12 Dec 2019 at 23:54:16 +, Scott Kitterman wrote:
> I think when people personally feel excluded/diminished/pick your term
> then it's appropriate to work on how to frame things to see how to make
> them feel welcome (e.g. if someone is more comfortable being referred
> to by they, then
On Fri, 27 Mar 2020 at 23:06:55 +, Holger Levsen wrote:
> another option would be 'unstable-proposed' (or whatever) where packages get
> uploaded to, and which only gets moved to 'unstable' if they don't fail
> piuparts,
> autopkgtests (plain build tests) and so forth...
Do you mean this to b
On Sat, 03 Apr 2021 at 21:46:08 +0200, someone claiming to be Enrico Zini wrote:
> We explicitly refuse to acknowledge irrelevant political issues
I was surprised to read this apparently coming from Enrico, particularly
since it doesn't seem consistent with what Enrico has said in other
threads re
On Tue, 28 Sep 2021 at 13:56:21 +0200, Karsten Merker wrote:
> In this case the chair surely wouldn't vote to overrule
> themselves as that would be a completely nonsensical behaviour,
The casting vote cannot be used to select an option that is not in the
Schwartz set (loosely: it can only be
I've lost track of who wrote:
> > > Suggest making this "None of the above" instead of "Further discussion"
> > > to avoid two different default options for TC decisions vs project
> > > decisions.
On Thu, 25 Nov 2021 at 10:28:55 -0600, Gunnar Wolf wrote:
> I would prefer the change to extend al
On Sat, 12 Mar 2022 at 18:09:20 +0100, Kurt Roeckx wrote:
> Choice 3: Reaffirm public voting
>
>
> ince we can either have [...]
I assume this was meant to start with "Since"?
smcv
On Mon, 12 Sep 2022 at 19:20:29 +0200, Simon Josefsson wrote:
> Steve McIntyre writes:
> > Many common laptops in the last 5-10 years don't come with wired
> > ethernet; it's becoming rarer over time. They ~all need firmware
> > loading to get onto the network with wifi. Many now need firmware for
On Wed, 05 Oct 2022 at 16:34:27 +0200, Philip Hands wrote:
> I didn't want to inflict work on the debian-cd
> team, and I assume that nobody will object if volunteers turn up to help
> build/test the free images. If they're built and tested, I'm pretty sure
> they'll be published.
As one of the pe
On Wed, 12 Jun 2024 at 08:53:40 -0400, Scott Kitterman wrote:
> On Tuesday, June 11, 2024 6:25:02 PM EDT Sean Whitton wrote:
> > - it improves the traceability and auditability of our source-only
> > uploads, in ways that are particular salient in the wake of xz-utils.
>
> As I understand it, De
On Wed, 12 Jun 2024 at 15:20:45 +0100, Ian Jackson wrote:
> tag2upload, like dgit, ensures and insists that the git tree you are
> uploading corresponds precisely [1] to the generated source package.
>
> If you base your Debian git maintainer branch on the upstream git (as
> you should) and there
On Wed, 12 Jun 2024 at 16:04:34 -, Marco d'Itri wrote:
> >Is your position here that if your upstream releases source tarballs
> >that intentionally differ from what's in git (notably this is true
> >for Autotools `make dist`), then any Good™ maintainer must generate
> >their own .orig.tar.* fr
On Wed, 12 Jun 2024 at 13:03:04 -0400, Antoine Beaupré wrote:
> On 2024-06-11 18:39:04, Russ Allbery wrote:
> > - Someone in the keyring (either a Debian Developer or a Debian Maintainer
> > for a package) uploads a malicious source package but makes it appear
> > that the package was uploaded
On Thu, 13 Jun 2024 at 15:08:15 +0100, Ian Jackson wrote:
> I think it is possible that there will be a handful of packages where
> things are significantly more awkward, which might not be able to
> adopt tag2upload.
This would presumably be the same minority of packages where maintainers
use a d
On Fri, 14 Jun 2024 at 09:12:56 +0200, Simon Josefsson wrote:
> I don't think a shallow copy will work generally. Instead you want
> to upload the entire upstream git repository as a bundle.
I believe this has been specifically ruled out by the ftp team in the past.
With a tarball or a shallow b
On Fri, 14 Jun 2024 at 08:52:38 +0200, Gerardo Ballabio wrote:
> As I understand, the proper way to resolve disagreement over technical
> issues is to bring the matter to the Technical Committee. Why are you
> proposing a GR instead?
The TC can overrule individual developers (§6.1.4 in the Debian
On Fri, 14 Jun 2024 at 12:26:50 +0100, Ian Jackson wrote:
> Note however: right now you can't do a source-only upload of a new
> upstream version, and tag2upload only supports source-only uploads.
> So this situation generally won't arise: someone will have had to
> upload the orig.tar.gz the old w
On Wed, 19 Jun 2024 at 07:54:45 +0200, Ansgar 🙀 wrote:
> Just include a hash
> similar to [1] in the signed tag data
Prior art: this is conceptually the same as git-evtag from
src:git-evtag. You can see real-world use of git-evtag in the upstream
tags (e.g. v0.9.0) of src:bubblewrap.
> it might n
On Tue, 25 Jun 2024 at 10:02:03 +0200, Thomas Goirand wrote:
> I do not think it is reasonable that a particular (git?) workflow, specific
> to the way *YOU* prefer working, gains special upload rights.
This seems to be based on a misconception. tag2upload specifically
doesn't require one specific
25 matches
Mail list logo
