Hi,
Since my signature got lost on the way, retrying:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
> START OF PROPOSAL TEXT
>
> Debian Public Statement about the EU Cyber Resilience Act (CRA) and the
> Product Liability Directive (PLD)
>
> The CRA includes requirements for manufacturers of
Hi,
On 23.11.23 03:16, Bart Martens wrote:
START OF PROPOSAL TEXT
Debian Public Statement about the EU Cyber Resilience Act (CRA) and the
Product Liability Directive (PLD)
The CRA includes requirements for manufacturers of software, followed
up by the PLD with compulsory liability for
Hi,
On 11/20/23 08:21, Luca Boccassi wrote:
Therefore, the Debian project asks the legislators to enhance the
text of these regulations to clarify beyond any reasonable doubt that
Free and Open Source Software developers and contributors are not going
to be treated as
Hi,
On 11/15/23 20:27, Aigars Mahinovs wrote:
That is exactly why I think this is dangerous: I want GitLab and
Proxmox
to be responsible for what they release, but it is very difficult to
draw a line between their offering and what Microsoft is doing by
paying
for
Hi,
On 11/15/23 15:22, Lucas Nussbaum wrote:
The Debian project however notes that not enough emphasis has been
employed in all parts of these regulations to clearly exonerate Free
and Open Source Software Projects from being subject to the same
liabilities as commercial
Hi,
On 13.11.23 19:54, Aigars Mahinovs wrote:
So a commercial company releasing open source
software that is *not* part of their commercial activity (for example a
router manufacturer releasing an in-house written Git UI) would be
"supplied outside the course of a commercial activity" and
Hi,
On 11/13/23 02:47, Lisandro Damián Nicanor Pérez Meyer wrote:
Similarly, where the
main contributors to free and open-source projects are developers
employed by commercial entities and when such developers or the employer
can exercise control as to which modifications are accepted in the
Hi,
On 9/10/22 11:37, Andrew M.A. Cater wrote:
Multiplying installers might be a complexity too far at this or any other
stage.
We already multiply installers along several axes. Most of these work by
simply selecting different file sets and detecting at runtime whether a
specific file is
Hi,
On 9/8/22 08:00, Didier 'OdyX' Raboud wrote:
As-is (that is: "changing only SC5 with a 3:1 majority") seems to be one very
simple way to express the change we (some of us) want.
It's the change we need to do in order to be consistent, so "want" is a
pretty strong word here.
It is a
Hi Russ,
On 9/7/22 21:58, Russ Allbery wrote:
Simon Richter writes:
Do users have the right to redistribute the installer?
In this proposal it's left unspecified (in other words, it's not an
inherent position of the Social Contract one way or the other), mostly
because I'm trying to keep
Hi,
On 9/7/22 19:48, Russ Allbery wrote:
--
This ballot option supersedes the Debian Social Contract (a foundation
document) under point 4.1.5 of the constitution and thus requires a 3:1
majority.
The Debian Social
Hi Jonas,
On 8/31/22 18:43, Jonas Smedegaard wrote:
The only way I could see to solve that conflict (other than interpreting
the official installer as not part of Debian) was to keep the free-only
installer around for purity reason even though generally we would
promote another unofficial
Hi Marco,
- users need to be aware of non-free licenses
I believe that "need" here is a strong word. Some users will /like/ to
know which non-free firmwares they need to use (I do!), but I cannot
think of any reasonable scenario in which somebody /needs/ to know that.
As I've mentioned
Hi Wouter,
On 8/27/22 12:18, Wouter Verhelst wrote:
The third point is something we can and should address in the medium term:
so far, license checks for non-free components have been mostly "can Debian
redistribute this" and "can users install this".
Thus, your concern can easily be
Hi,
On 8/23/22 22:22, Bart Martens wrote:
Debian would recommend the one with non-free-firmware, for the
purposes of enabling users to install on current hardware, but both
would be available.
Do we need to recommend one above the other? I'd rather use some short
explanation per installer
Hi Ansgar,
On 8/19/22 17:09, Ansgar wrote:
I don't see a difference between having non-free files in the archive
and non-free files on the installation images. If having individual
non-free files was not acceptable then we would have to define the
archive not part of Debian as well.
Yes, and
Hi,
On 8/18/22 21:58, Steve McIntyre wrote:
We will include non-free firmware packages from the
"non-free-firmware" section of the Debian archive on our official
media (installer images and live images). The included firmware
binaries will *normally* be enabled by default where the system
Hi,
On 11/8/21 5:30 PM, Sam Hartman wrote:
* A proposal to update our voting process (which looks like it will have
a couple of options on the ballot)
And that is a good thing. The core strength of our voting system is that
there are no spoiler options, and if I look back, the most
Hi Bdale,
On Tue, Apr 20, 2021 at 11:35:21AM -0600, Bdale Garbee wrote:
> I admit to having really mixed feelings about whether Debian should
> *ever* make broad public statements about anything. So, no problem in
> my mind with making it harder for the project to do so.
One of the purposes
Hi Felix,
On 05.04.21 15:35, Felix Lechner wrote:
When a center option is likely to fail our majority requirement [1]
should I rank preferable extreme choices above FD even if I am
strictly moderately inclined?
You are making two bold assumptions here: that the options are on a
single
Hi,
On 30.03.21 09:56, Dmitry Smirnov wrote:
Nobody is perfect. Everybody said a foolish thing at least once in a
lifetime. If we cancel those who love what they do, those who are good
with what they do, those who are passionate and caring for what they do
for something they have said
Hi,
On 26.03.21 08:32, Christian Kastner wrote:
> All I'm saying is that when people speak out about the wish to be
> apolitical, the term 'apolitical' should not be taken in the widest
> possible sense, which covers any action or inaction, and then dismissed
> for being impossible.
> Rather,
Hi,
On 25.03.21 23:32, Christian Kastner wrote:
>> the "technical" decisions we make based on that also have political
>> consequences.
> That's taking meaning of the word 'political' in the widest possible
> sense, and in that sense, literally any action (or inaction) carried out
> by an
Hi Roberto,
On 25.03.21 18:59, Roberto C. Sánchez wrote:
> I understand that it is not always possible to be completely apolitical,
> even for Debian as an organization.
Pretty much everything Debian does is political.
Free software enables users' technical autonomy, and this completely
shifts
Hi,
On Mon, Mar 22, 2021 at 09:08:14PM +0100, Christian Kastner wrote:
> The (1) adoption of debhelper by my most packages and (2) the move to
> Salsa have been an absolute blessing. They have made contributing to
> other packages so much easier.
We have multiple standards at different
Hi,
On Wed, Mar 18, 2020 at 12:01:28PM +0100, John Paul Adrian Glaubitz wrote:
> > Honestly, I don't think it's a problem we can solve right now, but at
> > the very least, we should do whatever it takes to not be part of the
> > problem, and we should take every small step we can take to be the
Hi,
On Thu, Dec 05, 2019 at 08:32:28AM -0500, The Wanderer wrote:
> At minimum, "X is the default" means "you will get X if you don't take
> any action to avoid doing so". All definitions I can think of seem to
> share that baseline.
> At something like maximum, "X is the default" could be read
Hi,
On Wed, Dec 04, 2019 at 10:24:40PM +0500, Andrey Rahmatullin wrote:
> > One of the options I had in my original proposal was that we could drop the
> > requirement for transitions through apt, and instead provide transition
> > scripts that use dpkg's --force options to go through an invalid
Hi,
On Wed, Dec 04, 2019 at 04:43:39PM +0100, Ansgar wrote:
> For one of the problems (apt making unexpected decisions) that is
> pretty close to what is the case. We do find such issues again and
> again, including too late, i.e. only after a stable release, also for
> other packages that
Hi,
On 02.12.19 00:20, Simon McVittie 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 practice
Hi,
On 02.12.19 00:07, Uoti Urpala wrote:
> In short: there is little to no worthwhile work being done on any
> alternatives to systemd. What is happening is some people trying to
> keep sysvinit working to about the level it did in 2014, while doing
> very little fundamental development to the
Hi,
On 01.12.19 23:24, Simon McVittie wrote:
> dbus-user-session is not, and probably will not be, usable on non-systemd
> systems. If per-user service managers other than `systemd --user` exist
> and can be configured to provide equivalent semantics, I'd be happy
> to review the necessary
Hi,
On 01.12.19 20:13, Russ Allbery wrote:
>> Right, but the dependency chain is there to make sure the package is
>> usable on systemd systems, i.e. we'd have to accept a regression for the
>> systemd case in order to facilitate the non-systemd case, which is what
>> we don't want, or live with
Hi Russ,
On 01.12.19 18:16, Russ Allbery wrote:
>> https://lists.debian.org/debian-devel/2019/08/msg00278.html
> This is a point that Ian's proposal specifically addresses by accepting
> the possibility that packages will be installable but not usable on
> non-systemd systems in order to avoid
Hi,
On 01.12.19 10:06, Martin Michlmayr wrote:
> So there's a lot about proposal B that I like, but at the end of the
> day the proposal doesn't sound that different to the status quo.
> While it says systemd, there's no 100% commitment (there's no clear
> preference over Debian kludges for
On 01.12.19 02:54, Russ Allbery wrote:
>> Russ> Could you provide some more information about what your
>> Russ> concern is here? libsystemd-dev depends only on libsystemd0,
>> Russ> which has a pretty tiny list of dependencies and shouldn't
>> Russ> require that systemd be
On 30.11.19 18:46, Guillem Jover wrote:
> I'm thus proposing the following:
>
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
>
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that
Hi,
On Fri, Nov 29, 2019 at 10:16:10PM +0200, Martin Michlmayr wrote:
> I'd like submit the following proposal:
I guess my second is not really needed anymore for this, but it's good to
have it on the ballot.
> Proposal: Focus on systemd to promote standardization and cross-distribution
>
Hi,
On Fri, Nov 29, 2019 at 09:07:58AM -0800, Russ Allbery wrote:
> Sam, I think you misunderstood Simon's concern. He's not looking for
> guidance for packages that don't work properly with sysvinit. He's
> looking for guidance for packages that don't work properly with *systemd*
> (the
Hi Sam,
On Fri, Nov 29, 2019 at 08:46:31AM -0500, Sam Hartman wrote:
> Martin [Pitt] has publically stated he's one of the people I reached out
> to in developing my proposals.
> As I understand, he's been active in maintaining systemd both in Ubuntu and
> Debain.
Indeed, most of my
Hi,
On Fri, Nov 29, 2019 at 01:22:37PM +, Holger Levsen wrote:
> > I do not support delaying the CFV for an option that has not gained
> > sponsors.
> just sigh.
> Michael, I'm very very likely to sponsor anything you have written so
> far. Please publish something so it's on the table
Hi,
On Fri, Nov 29, 2019 at 11:44:55AM +, Ian Jackson wrote:
> > For example, it raises a (probably valid) concern about
> > "non-init-related [declarative] systemd facilities", but:
> > 1/ it mixes it with an argument that declarative facilities are better.
> > Well, maybe I can agree with
Hi,
On Mon, Nov 25, 2019 at 01:09:10PM +, Ian Jackson wrote:
[change removing regret about having another GR]
> Unless anyone objects by 1400 UTC on Wednesday, I intend to accept
> this amendment, assuming that this is procedurally kosher.
I'm also in favour of that. My understanding of
Hi,
Dmitry Bogatov proposed the following amendment:
> Being able to run Debian systems with init systems other than systemd
> continues to be of value to the project. Every package MUST work with
> pid1 != systemd, unless it was designed by upstream to work exclusively
> with systemd and no
Hi Sam,
On Thu, Nov 21, 2019 at 07:44:02AM -0500, Sam Hartman wrote:
> I'd like to ask especially those people whether choice hartmans1 should
> be removed from the ballot. Within limits, I think more options is
> better, so my general preference would be to keep the option. However
>
Ian Jackson writes:
> I hereby formally propose the following amendent (for my reference,
> 42471fd). Replace the entire text, with the text below.
>
> -8<-
>
> Title: Support non-systemd systems, without blocking progress
>
> PRINCIPLES
>
> 1. We wish to continue to support multiple init
Hi,
On Fri, Nov 15, 2019 at 10:03:35AM -0800, Russ Allbery wrote:
> My personal preference is for the project to either decide that we're
> going to use systemd facilities by default and sysvinit is going to break,
> or to decide that we're going to require standardized interfaces with the
>
Hi,
On Fri, Nov 15, 2019 at 10:29:10AM +0100, Thibaut Paumard wrote:
> I think this is very ambiguous and my immediate interpretation is
> probably not what the original proposer means. The two extreme
> interpretations I see for "designed to work exclusively with systemd" are:
> - my guess
Hi,
On Sun, Nov 10, 2019 at 12:19:24AM +0100, Bernd Zeimetz wrote:
> > Yes, that would be my desired outcome: an affirmation that Debian wants to
> > be "universal". This has been our greatest strength for years.
> Its a strength that wasted an enormous amount of ressources. See
> kfreebsd
Hi Mike,
On Sat, Nov 09, 2019 at 09:48:03PM +, Mike Gabriel wrote:
> root@minobo:~# apt-rdepends -r systemd | wc -l
> 6598
It's not as bad as you think: the important package is systemd-sysv.
In buster:
$ apt-cache rdepends systemd-sysv
In bullseye:
systemd-sysv
Reverse Depends:
Hi,
On Sat, Nov 09, 2019 at 10:01:27AM -0800, Russ Allbery wrote:
> > (Option 1)
> > The Debian Project aims at providing the greatest configuration flexibility
> > while maintaining a sensible default installation for end users. To that
> > end, we document functional dependencies in a
Hi,
the main problem I see with this GR is that it is in essence a rehash of
the GR[1] we had in 2014, with pretty much the same options minus the one
that won, "A GR is not required."
> Choice 1: Affirm Init Diversity
The way this is worded is even stronger than in the 2014 GR, which made
Hi,
On 02.04.19 05:59, Louis-Philippe Véronneau wrote:
> Some teams might dislike it, but I guess those people will also dislike
> the idea of giving all DDs commit access on all packages VCS.
Y'all are still solving social problems with technical solutions here,
and it's a bad technical
Hi,
On 17.03.19 00:51, Simon Richter wrote:
> I'd also like nominate myself for the 2019 DPL election.
As you may have noticed, life happened to me shortly after sending that
mail. I'm definitely not in a position to make a serious bid anymore, so
I'd like to withdraw. I still have opini
Hi,
I'd also like nominate myself for the 2019 DPL election.
Simon
signature.asc
Description: OpenPGP digital signature
Hi,
Upstream Developers considering a specific Free Software (including,
but not limited to, a particular init system executed as PID 1)
fundamental to deliver the best Software releases, are fully entitled
to require, link, or depend on that Software, or portions of it.
Note that
Hi,
On 17.10.2014 11:52, Marco d'Itri wrote:
for 30 years so why are some people pushing _so hard_ to replace it NOW and
by something
as controversal as the systemd stuff.
A vocal minority and a lot of trolls do not make something
controversial.
No, the majority disregarding the needs of
Hi,
On 17.10.2014 16:54, Daniel Kahn Gillmor wrote:
If the fix is not easy then we have three options: the release team
mark it `jessie-ignore', the GNOME maintainers fix it, or GNOME is
removed from jessie.
The implication here appears to be troubling for any upstream who wants
to rely on
Hi,
On 17.10.2014 22:13, Ansgar Burchardt wrote:
I note that it was *not* possible to switch init systems in Wheezy in a
supported way (in particular sysvinit is essential and various things
get very unhappy if it gets uninstalled), but you seem to treat Jessie
as more problematic even
Hi,
On 16.10.2014 17:05, Ian Jackson wrote:
I wish to propose the following general resolution, and hereby call
for seconds.
[...]
** Begin Proposal **
0. Rationale
Debian has decided (via the technical committee) to change its
default init system for the next release. The
Hi,
On Thu, Sep 16, 2010 at 06:52:02PM +0200, Kurt Roeckx wrote:
In case these changes are regarded as more than editorial (which is your
call, but I feel they are), the new proposal requires new seconds
I'm not sure why you think the proposal requires seconds if it
replaces an older
Hi,
On Wed, Sep 15, 2010 at 09:48:02PM +0200, Kurt Roeckx wrote:
I like that a lot more than the other wording, thus seconded.
Please don't go and make this more confusing for me. As far as I
can tell this wasn't meant to be amendment yet. He will probably
accept this or something
Hi,
On Wed, Sep 15, 2010 at 09:00:32PM +0900, Stefano Zacchiroli wrote:
The Debian project aims at producing the best free operating system.
To that end the project benefits from various types of contributions,
including but not limited to: package maintenance, translations,
infrastructure
Hi,
On Fri, Dec 19, 2008 at 12:36:54PM +0100, Marc Haber wrote:
On Fri, Dec 19, 2008 at 01:50:40AM -0600, Manoj Srivastava wrote:
To paraphrase: Those who give up essential freedoms for
temporary convenience and popularity deserve neither.
This is something we need to agree to
Hello,
MJ Ray wrote:
AMENDMENT PROPOSAL
Summary: reduce the campaign-only period to one week.
The change to paragraph four is replaced by:
4. For [-three weeks-] {+one week+} after that no more candidates
may be nominated; candidates should use this time for
Hi,
MJ Ray wrote:
AMENDMENT PROPOSAL
Point 2 remains as before; that is, it will still read:
2. The election begins nine weeks before the leadership post
becomes vacant, or (if it is too late already) immediately.
AMENDMENT PROPOSAL
Seconded.
Simon
Hello,
Nathanael Nerode wrote:
(There is a special exception for the license texts and similar legal
documents associated with works in Debian; modifications and derived
works of these legal texts do not need to be allowed. This is a
compromise: the Debian group encourages authors of
Hello,
Holger Levsen wrote:
DebConf, the annual Debian Developers Conference, is currently not officially
affiliated with Debian (or SPI) and its not listed on
http://www.debian.org/intro/organization
Do you think DebConf should have an official endorsement with Debian and how
do you
Hello,
Kalle Kivimaa wrote:
What is the role of the DPL? Is he a strong leader, who uses his
position to Get Things Done His Way, a public figurehead, who just
Speaks For The Project, a mediator, who tries to solve internal
squabbles, or something else?
The current role seems to be that the
I wrote:
There is a lot of gray area between those extremes, and we have to
decide on a case-by-case basis. I can see Debian spending more money
than it used to (e.g. to get some of the developer machines back up),
but I want to avoid both setting precedent and starting an internal
Hello,
What do you think of the dunc-tank initiative ? What do you think are
the result of the experiment ?
I think we should have been able to see the outcome before trying it.
The idea itself is not a bad one, however during the entire course of
the experiment it was never questioned by
Hello,
Ana Guerrero wrote:
Why do you think you will be a good DPL?
I see the role of the DPL mostly as a mediator; for that to work it is
important to listen and to be able to put one's own opinion aside; both
of which I think I can do.
What you can for Debian as DPL that you can not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I hereby nominate myself as a candidate for the post of the Debian
Project Leader in 2007.
Simon
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFF3zYRGKDMjVcGpLQRAsG9AJ9k3JWQ73U3n8ZRQSNMecZVgQh8vQCeLNMF
Hello,
it appears as if my first mail was reflowed at some point, which made
the signature go bad.
Thus, I reconfirm nominating myself as a candidate for the Debian
Project Leader 2007.
Simon
signature.asc
Description: OpenPGP digital signature
Hi,
Raul Miller schrieb:
This is silly. It seems like the constitution effectively says if the
resolution passes it required a simple majority; if it failed, it needed 3:1.
The only silliness is the verb tenses. Once some concept passes
supermajority it doesn't need to pass again, because
Hi,
Xavier Roche wrote:
I fully agree. The Holier than Stallman stuff is really getting
ridiculous. After the firmware madeness, now the documentation madeness.
And after that, the font madeness maybe ? (after all, fonts ARE also
software, and they shall be distributed with their original
Hello,
Manoj Srivastava wrote:
Here is a diff from AJ's proposal. I am now formally seeking
seconds for this modified proposal, which has explicit guidelines for
the most common case for not wantng the posts to be published.
Seconded.
Hello,
Jérôme Marant wrote:
What is this supposed to mean? If no comments have been made by the
author for eight weeks, messages will be automatically declassified?
It looks like a kind of opt out to me.
True. It may be an idea to have another proposed amendment reversing the
logic, and see
78 matches
Mail list logo
