ing that the external training data is still accessible could be
as simple as doing a HTTPs HEAD request to the specified source data
URLs as part of packagetests and failing if that file is no longer
offered or if its size changed. It would be a good addition to Policy
for such models, if we ever get that far.
--
Best regards,
Aigars Mahinovs
On Thu, 15 May 2025 at 10:06, Stefano Zacchiroli wrote:
>
> On Wed, May 14, 2025 at 11:38:02PM +0200, Aigars Mahinovs wrote:
> > You would *actually* technically, in reality, prefer digging through
> > gigabytes of text files and do some kind of manual modifications in
> &
On Wed, 14 May 2025 at 23:13, Soren Stoutner wrote:
>
> On Wednesday, May 14, 2025 1:51:27 PM Mountain Standard Time Aigars Mahinovs
> wrote:
> > That is not what I asked. Redistributing is a completely different
> > question from a different point of DFSG and even from
On Wed, 14 May 2025 at 21:13, Soren Stoutner wrote:
>
> On Wednesday, May 14, 2025 5:31:53 AM Mountain Standard Time Aigars Mahinovs
> wrote:
> > On Wed, 14 May 2025 at 00:03, Soren Stoutner wrote:
> > > On Tuesday, May 13, 2025 12:06:05 PM Mountain Standard Time Ilu w
in non-free.
Technically - yes, and I would be fine to include OSI-free AI in
Debian non-free, but IMHO it does nothing to resolve ethical concerns.
If we limit that to only OSI-free AI then that would also be giving
the same kind of guidance to the AI community - with both upsides and
downsides.
--
Best regards,
Aigars Mahinovs
rsonally, even rank option 1) higher
than option 2a) - it is always easier later to relax requirements than
to remove something from the archive.
--
Best regards,
Aigars Mahinovs
h that opinion, but I can
see how that is a
perfectly valid and consistent opinion to hold.
--
Best regards,
Aigars Mahinovs
On Wed, 14 May 2025 at 07:00, Russ Allbery wrote:
>
> Aigars Mahinovs writes:
>
> > It would be a lot easier to have a conversation with you, if you would
> > spend more time articulating and detailing *your own* position, instead
> > of guessing about the positions
On Tue, 13 May 2025 at 18:53, Russ Allbery wrote:
>
> Aigars Mahinovs writes:
>
> > This was in response to Russ articulating that: "I don't work on free
> > software because I want to make something easier for Google's LLM. I
> > work on free software
On Tue, 13 May 2025 at 10:24, Holger Levsen wrote:
>
> On Sat, May 10, 2025 at 12:21:26AM +0200, Aigars Mahinovs wrote:
> > I find that thinking to be rather limited. LLM are not self-aware or
> > self-operating entities. There is always a human that uses an LLM.
> > It&
On Sun, 11 May 2025 at 22:12, Thorsten Glaser wrote:
>
> On Sun, 11 May 2025, Aigars Mahinovs wrote:
>
> >> If you JPEG-compress a photo of the original document then uncompress
> >> it, it *is*.
> >
> >Please, restore a document from the output of "w
n commercial
use. Because the purpose was sufficiently transformative. The purpose
of an LLM for generating new works is *far* more transformative than
making a thumbnail.
And on EU, ilulu has already replied as well.
--
Best regards,
Aigars Mahinovs
step no longer matters.
The result may acquire a new copyright (yours) as you do something
creative enough with it, or amass sufficient amount of it to qualify
for a database copyright. But the copyright of the training data
simply does not survive the step of completely destructive statistical
analysis.
--
Best regards,
Aigars Mahinovs
On Sat, 10 May 2025 at 01:17, Thorsten Glaser wrote:
> >I realized that I have one additional generic concern: You claim that
> >models are a derivate work of their training input.
>
> Yes. This is easily shown, for example by looking at how they work,
> https://explainextended.com/2023/12/31/happ
On Fri, 9 May 2025 at 19:13, Russ Allbery wrote:
>
> Aigars Mahinovs writes:
>
> > Just because something can be done cheaper or at scale with help of
> > automation does not make the method of automation for it to become
> > morally wrong. See torrent, see mass ma
On Thu, 8 May 2025 at 12:46, Wouter Verhelst wrote:
>
> On Tue, May 06, 2025 at 12:02:08AM +0200, Aigars Mahinovs wrote:
> >The transformative criteria here is that the resulting work needs to be
> >transformed in such a way that it adds value. And generating new texts
s), ...
Data is not software. Knowledge is not software. Other rules can and
should apply to it. Also in the way that DFSG is interpreted in that
context.
--
Best regards,
Aigars Mahinovs
bout non-free software.
>
> 2) Providing some mechanism (allowing recommends is the obvious solution
> to me) so that programs in main can get their model data without having
> to download it from non-Debian sources. Being able to have a complete
> system with things like spam classifiers, OCR, text to speech, only
> given a Debian mirror is very important to me.
>
> important
>
--
Best regards,
Aigars Mahinovs
stical suggestions and
LLM statistical suggestions?" and not a shadowy cabal meeting in a
secret underground room and deciding to rewrite sudo in Rust :D
--
Best regards,
Aigars Mahinovs
freely and automatically. And this movement has huge financial and
social backing as well. It has real chances to succeed. And we are
*opposing* it? Why?
Let me end this with a quote: Copyright delenda est.
--
Best regards,
Aigars Mahinovs
stem deals well with ballot options, so I've never
> bought into the desire to minimize ballot options.
> I'm absolutely happy to work with Aigars to minimize differences between
> our proposals and to highlight those differences, not out of a desire to
> get a single merged proposal, but out of a desire to be clear what we
> are voting for.
>
--
Best regards,
Aigars Mahinovs
@Debian Project Secretary
Please consider the proposal as submitted and signed to be the
official proposal.
The "Draft" part of the subject was in error. And the subject is not
actually GPG signed anyway :)
On Wed, 7 May 2025 at 15:53, Sam Hartman wrote:
>
> >>>>&
utomatically try to apply that thinking to everything around us. But
that is a simplification that only applies in the very narrow scope.
Out of that, there are many exceptions and many areas where that does
not apply at all.
--
Best regards,
Aigars Mahinovs
ian to rush into having a specific
position on this, is there?
--
Best regards,
Aigars Mahinovs
(While I find the tone of the email a bit exasperated, I will try to
reply factually and I hope it will be received as such.)
On Wed, 7 May 2025 at 11:34, Simon Josefsson wrote:
>
> Aigars Mahinovs writes:
>
> > On Wed, 7 May 2025 at 02:56, Russ Allbery wrote:
> >
> &
that any policy change would need a transition period to be
practical.
--
Best regards,
Aigars Mahinovs
21:14, Aigars Mahinovs wrote:
>
> BTW, this also inspired me to read up on the EU Artificial
> Intelligence Act ( https://artificialintelligenceact.eu/ ) and I
> noticed a very relevant notice in that text - Art 53 (
> https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32
for AI training purposes.
It is also nice to see that EU AI Act explicitly highlights open
source AI models and provides them with simplified and preferential
rules.
On Tue, 6 May 2025 at 01:26, Aigars Mahinovs wrote:
>
> This one is much simpler. Maybe because the lawyers being used are n
oZqnCLU7SoiDP9xXSBTF3UBM/iTcrW33gBE3ujKyv+p2z74eUvrn302ZFA9G
JlDoRdmTHqLlNncEA04FdJ6+VBNY6GZKGXK5r0vDMnQ26MMHWdU=
=imT+
-END PGP SIGNATURE-
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
egic decision itself could be a thing that can be
done immediately, but the technical part would need more work and
discussion.
On Tue, 6 May 2025 at 00:30, Sam Hartman wrote:
> >>>>> "Aigars" == Aigars Mahinovs writes:
>
> Aigars> Another, simpler, alterna
does not create copyright infringement.
The whole lawsuit is very sloppy IMHO, IANAL.
On Tue, 6 May 2025 at 00:10, Bill Allombert wrote:
> Le Mon, May 05, 2025 at 11:44:30PM +0200, Aigars Mahinovs a écrit :
> > On Sun, 4 May 2025 at 17:30, Wouter Verhelst wrote:
> >
> &
should be able to reproduce the data and then the model
using this information.
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#--#
| .''`.Debian GNU/Linux (http://www.debian.org)|
| : :' : |
| `. `'Software Engineer, BMW |
| `- |
#--#
On Mon, 5 May 2025 at 01:05, Wouter Verhelst wrote:
> On Sun, May 04, 2025 at 07:08:00PM +0200, Aigars Mahinovs wrote:
> >On Sun, 4 May 2025 at 17:30, Wouter Verhelst <[1]w...@uter.be> wrote:
> >
> > >Wikipedia definition is a layman's s
xed millions of books submitted by libraries for full text
search across the books (a database of the actual texts of the books) and
would provide the users with excepts from the copyrighted books as part of
responses to the queries.
All those cases were seen as fair use and thus not infringing on copyright
of the original works.
--
Best regards,
Aigars Mahinovs
start now?
This change in thinking Is what I want to communicate - learning is not
a compilation. Just because a file comes in and a file comes out does not
make the processes inside equivalent.
--
Best regards,
Aigars Mahinovs
On Sun, 4 May 2025 at 13:12, Wouter Verhelst wrote:
> On Tue, Apr 29, 2025 at 03:17:52PM +0200, Aigars Mahinovs wrote:
> >However, here we have a clear and fundamental change happening in the
> >copyright law level - there is a legal break/firewall that is
> happe
On Mon, 28 Apr 2025 at 22:02, Russ Allbery wrote:
> Aigars Mahinovs writes:
>
> > *However*, models again are substantially different from regular
> > software (that gets modified in source and then compiled to a binary)
> > because such a model can be *modified* a
s are
needed for re-creation of the model (with a limit to what Debian can
actually have in terms of hardware and afford to spend in terms of
power/rental costs if needed).
Debian has historically been a very important community voice in defining
clear criteria and targets that the rest of the community then used to
rally around. Starting with DFSG and analysis of specific copyright
licenses and to more recent projects like reproducible builds.
--
Best regards,
Aigars Mahinovs
On Mon, 28 Apr 2025 at 18:44, Russ Allbery wrote:
> Aigars Mahinovs writes:
>
> > If we take as a given that copyright does *not* survive the learning
> > process of a (sufficiently complex) AI system, then it is *not* necessary
> > that all training *data* for trainin
e advising you
what to choose for your planned build. At this point the LLM+RAG is just a
smart web browser.
(Sadly, I am *not* an expert on modern AI technologies)
--
Best regards,
Aigars Mahinovs
ntrib, and their model files to non-free?
>
> --
> -- regards
> --
> -- Matthias Urlichs
>
>
--
Best regards,
Aigars Mahinovs
On Mon, 1 Jul 2024 at 11:33, Matthias Urlichs wrote:
>
> On 30.06.24 21:30, Aigars Mahinovs wrote:
>
> The Debian developer/maintainer creates a signed git tag that contains
> (in its message, presumably, to avoid adding new communication lines)
> the file listing of the git che
an't push just a tag without also pushing the code that
you are tagging. So there is no technical way of uploading a package
via t2u without also pushing the source to some kind of git repo (that
is readable and is being monitored by t2u).
--
Best regards,
Aigars Mahinovsmailto:a
On Sun, 30 Jun 2024 at 20:47, Scott Kitterman wrote:
>
> On Sunday, June 30, 2024 1:45:15 PM EDT Aigars Mahinovs wrote:
> > On Sun, 30 Jun 2024 at 19:28, Russ Allbery wrote:
> > > Aigars Mahinovs writes:
> > > > Correct me if I'm wrong, but
On Sun, 30 Jun 2024 at 19:28, Russ Allbery wrote:
>
> Aigars Mahinovs writes:
> > Correct me if I'm wrong, but I believe the intention is to have two
> > technically redundant data points saved into the archive:
>
> > 1) checksums of the contents of
ave here would be to have the shallow git
clone on the t2u side have a variable depth that is selected so that
the commits in the resulting depth are sufficient for the source
package construction, like in case of a rebase workflow you'd need to
have git history deep enough to include all Debian patches and the
last upstream commit.
--
Best regards,
Aigars Mahinovs
Refusing to make a decision is a decision. Ansgar has explicitly set a
requirement for including the checksums of the end result Debian source
package in the tag. This requirement was not withdrawn or overridden by
other FTP masters in the public list communications. And all (detailed)
explanations
it must be good enough got tag2upload
as well.
On Tue, 25 Jun 2024, 11:23 Thomas Goirand, wrote:
> On 6/24/24 23:31, Aigars Mahinovs wrote:
> > There is no cryptographic relationship between the signed source
> > *package* and the actual source. That *is* the problem. Inspecting on
solution for code hidden in the upstream git itself
> >that the maintainer missed.
> >
> >On Mon, 24 Jun 2024, 22:03 Scott Kitterman, wrote:
> >
> >> Do you have any examples of problems that this would have avoided
> >> (xz-utils isn't one - due to the
on, 24 Jun 2024, 22:03 Scott Kitterman, wrote:
> Do you have any examples of problems that this would have avoided
> (xz-utils isn't one - due to the way it's releases are done, it wouldn't be
> suitable for tag2upload)?
>
> Scott K
>
> On June 24, 2024 6
Signing something that you did not write and something that you don't read
is a bad security practice that exposes you to various attacks.
Just because we have been doing this poor security practice for a long time
does not make it better. Now better methods are possible and we shouldn't
prevent t
On Sun, Jun 23, 2024, 19:17 Scott Kitterman wrote:
> As an example, I think the fact that I can download any source package in
> the
> archive and cryptographically verify who uploaded it and that it's
> unmodified
> from what was uploaded is an important property of our current archive
> structu
On Thu, 20 Jun 2024 at 13:19, Ian Jackson
wrote:
>
> Aigars Mahinovs writes ("Re: What is the source code (was: [RFC] General
> Resolution to deploy tag2upload)"):
> > On Wed, 19 Jun 2024 at 12:57, Gerardo Ballabio
> > wrote:
> > > 1) is the source of a
that the Debian and/or upstream developer is using to actually manage
and modify the software.
It has nothing to do with history. Unless you want to do deep dives
and do git blame research. Something that is
not possible with Debian source code packages beyond the
uploader/maintainer/develop
Removing nearly all usefulness from the system and preventing it from
getting more useful over time is not a compromise. That is blocking by a
wrecking amendment.
On Thu, 20 Jun 2024, 01:03 Ansgar 🙀, wrote:
> Hi,
>
> On Wed, 2024-06-19 at 14:43 -0700, Russ Allbery wrote:
> > I don't think it's b
On Wed, 19 Jun 2024 at 09:51, Simon Richter wrote:
> I agree with that, but it effectively changes what we consider a "source
> package", and that comes with all the baggage of archival:
>
> - we need to store the actual contents in the archive, not just a
> reference to an online service, or th
On Tue, 18 Jun 2024 at 18:11, Soren Stoutner wrote:
>
> On Tuesday, June 18, 2024 8:57:28 AM MST Aigars Mahinovs wrote:
> > On Tue, 18 Jun 2024 at 17:44, Soren Stoutner wrote:
> > > From a security perspective, it makes sense to me that the DD should
> create
> > &
security.
All this is just an extension of the source-only upload to be even
more "source".
--
Best regards,
Aigars Mahinovs
processes should take that into account and start automated processing
and signing of the source as close to the human-editable source as
possible. tag2upload moves this a full step forward.
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#---
If you have a source package already compiled locally to be
manifested/signed, then why are you not just uploading that? This
assumption completely removes the point of tag2upload.
There are plenty of valid use cases that do not create a dsc locally. Or
wouldn't if it wasn't required for upload.
On Mon, 17 Jun 2024, 18:50 Simon Richter, wrote:
> Hi,
>
> On 6/17/24 18:49, Marco d'Itri wrote:
>
> >> There is another aspect he mentioned: he thinks the uploader needs
> to test
> >> the build of the package. (I'm theory I agree, but there are
> situations
>
> > Everybody can upload to
aintainer.
You already have to go back the chain of verifications via
automatically signed files:
Release -> Packages -> binary deb -> source dsc
What difference does it make to add another step to the end: -> git tag
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.or
t a human initiated the chain of events and signatures
with an authenticated signature. Where that happens does not
really matter all that much and has changed in the past in Debian already.
--
Best regards,
Aigars Mahinovsmailto:aigar...@d
ervice, would it not be beneficial for the auditing
and back-tracing
process to actually keep the code that someone tried to upload via
tag2upload even
if their key is revoked, expired or signature is invalid?
Maybe re-tagged to something
server goes down, the archive
will remain.
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#--#
| .''`.Debian GNU/Linux (http://www.debian.org)|
| : :' : Latvian Open Source
I'll just attach the signed version, it seems like GMail plain text
mode is still a bit broken.
On Mon, 20 Nov 2023 at 08:53, Kurt Roeckx wrote:
>
> On Mon, Nov 20, 2023 at 12:40:58AM +0100, Aigars Mahinovs wrote:
> > I second adding this version to the vote
>
> I'
VqZGw/zv
VVgHZxNIRohXgprqw/98nloCQj3akCd7dKFoUNfsl+TBStTrWys6lmvAGvyg/Q00
GC7uxn454LhsGAEDdDf2155fSQsiiK7j+O/ZibwXEP/thfcJJwNmOyjVtiRvtdMg
CnpXWR4RTe+OS73T7LbaS79pDEa5ZLPuLcbGCbB3O/yi2ZUALIbFK02uwex+19Kw
///xr/s+0MXBmiUIZYs+cXZG2u33Vy+GwalbKGhvNN6nRFvvFBY=
=av62
-END PGP SIGNATURE-
--
Best regards,
Aigars Mahinovs
ir offering and what Microsoft is doing by paying
> for systemd development while they are also selling Azure cloud.
>
Why should there be a borderline between that? Microsoft has to be
responsible
for what they are selling in the Azure cloud (pre-defined images),
regardless of
the systemd developer work.
--
Best regards,
Aigars Mahinovs
Thanks for the detailed explanation! It had quite a few details that I was
not aware about. Expressing the desired position of Debian and of the
community *is* useful, especially when there are multiple variants of the
legislation that need reconciliation. I was looking at the specific version
that
On Mon, 13 Nov 2023 at 15:51, Lisandro Damián Nicanor Pérez Meyer <
perezme...@gmail.com> wrote:
> On Mon, 13 Nov 2023 at 11:50, Aigars Mahinovs wrote:
> > Whether accepting donations *in general* makes your activity in
> providing software a "commercial activity"
es of what does make
a "commercial activity" in point 10, but none of those examples directly
apply to general donations to a project or person.
On Mon, 13 Nov 2023 at 15:20, Lisandro Damián Nicanor Pérez Meyer <
perezme...@gmail.com> wrote:
> On Mon, 13 Nov 2023 at 09:54, Aigar
nks/2023/10/eff-and-other-experts-join-pointing-out-pitfalls-proposed-eu-cyber-resilience-act
Note how the open source language has become very much softened and nuanced
after changes in the
proposal removed most of the bugs that would have affected open source
previously.
--
Best regards,
Aigars Mahinovs
similar agreements on the Windows side?
Lots of interesting questions. But at no point does any responsibility get
automatically assigned to, for example, Debian or individual
open source developers.
On Mon, 13 Nov 2023 at 14:03, Luca Boccassi wrote:
> On Mon, 13 Nov 2023 at 12:57, Aigars Mahin
, 13 Nov 2023 at 13:28, Luca Boccassi wrote:
> On Mon, 13 Nov 2023 at 12:20, Simon Richter wrote:
> >
> > Hi,
> >
> > On 13.11.23 19:54, Aigars Mahinovs wrote:
> >
> > > So a commercial company releasing open source
> > > software that is *no
On Mon, 13 Nov 2023 at 13:29, Lisandro Damián Nicanor Pérez Meyer <
perezme...@gmail.com> wrote:
> On Mon, 13 Nov 2023 at 07:55, Aigars Mahinovs wrote:
> [snip]
> > Even regardless of the specific legal wording in the legislation itself,
> the point 10
> > of the pre
ngle market.
>
> Obviously repositories are not products. Software is.
>
> I'm not spreading fud. I've read the stuff, I'm working on this since
> FOSDEM, I have the necessary background and I participate in weekly
> meetings with several big FOSS organisations/foundations. This workgroup
> had frequent consultations with EU representatives. We are not spending
> considerable time on non-issues.
>
> Ilu
>
>
--
Best regards,
Aigars Mahinovs
f
multiple talk streams in parallel we would have them in succession. And
also have a party stream / chillout lounge running the whole time in
parallel as well. We can take this challenge and come up with something new
that Debconf as such could have never been. :)
--
Best regards,
n if person X feels that he is "at war", that alone does not make
his technical arguments invalid.
If you do not liek where Ian is coming from with his point of view -
do not argue with him. Argue with other people. Or, better yet, argue
with the facts.
--
Best regards,
Aigars
option in the GR says anything about what should happen to
the init system on upgrade and no GR option contradicts either
possible TC decision on the topic. So I am quite surprised to see that
it somehow " directly address this part of the question".
--
Best regards,
Aigars
On 30 October 2014 12:24, Cameron Stewart wrote:
> On Thu, Oct 30, 2014 at 9:06 PM, Aigars Mahinovs wrote:
>> Have other distros switched to _only_ supporting systemd? Changing the
>> default is not the same. This is not a rhetorical question - it would
>> actually be us
g systemd? Changing the
default is not the same. This is not a rhetorical question - it would
actually be useful to know if other distros have actually already
abandoned support for non-systemd init systems.
--
Best regards,
Aigars Mahinovsmailto:
lications will not depend on those new APIs, then
there is nothing to worry about. However, there is an opinion that the
above does not describe how systemd has been developed so far.
--
Best regards,
Aigars Mahinovs
o some special email sending
options used in the mail merge feature) and so installing LibreOffice
would also change your MTA.
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#--#
| .''`.Debian GNU/Linux
s are not supported, put systemd as essential and push all other
init systems to extra or even out of the archive;
With enough imagination it is possible to see the original GR proposal
as implementing the first option
hat whole
sub-init.
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#--#
| .''`.Debian GNU/Linux (http://www.debian.org)|
| : :' : Latvian Open Source Assoc. (http://www.laka.lv)
d be a bug with the same severity
as if it affected all users, so somewhere from 'wishlist' to at most
'normal'.
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#--#
| .''`.Debian GNU
y what I am suggesting - the reason for the clean up
would be to reduce maintenance burden and add new features by using
features easily available on the default architecture (both perfectly
fine reasons), but the side effect is loss of support for other
architectures (which is no lon
First of all, Josh, thank you for the long and reasoned replies. I do
hope this back-and-forth is useful for others as well in the context
of this decision, that is why I am still keeping the debian-vote list
in the CC.
On 24 October 2014 19:18, Josh Triplett wrote:
> Aigars Mahinovs wr
it. And even
that is kind of optional. That makes it very easy to implement new
init systems. Even in-house custom init systems for specific reasons.
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#--#
|
xist.
If some software used to work before systemd there is no technical
excuse for it not working with other init systems after systemd
integration. If there was no socket activation before, it can not be
such an essential feature that you simp
On 24 October 2014 15:33, Olav Vitters wrote:
> On Fri, Oct 24, 2014 at 01:48:33PM +0300, Aigars Mahinovs wrote:
>> No, but we set up requirements that their work must meet before it can
>> enter archive or may end up in a release. That is what the whole of
>> Debian Policy
s
the feeling of loss of control. Then asking others to implement
init-system-neutral versions of systemd-invented services just to keep
using software that used to work before is ... raising some hackles.
--
Best regards,
Aigars Mahinovsmailto:aig
r to systemd on upgrade and there has *not* been a decision about
dropping support for other init systems.
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#--#
| .''`.Debian GNU/Linux (http://www.de
ould bring great responsibility *not* to break stuff.
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#--#
| .''`.Debian GNU/Linux (http://www.debian.org)|
| : :' : Latvian Open Source
On 24 October 2014 13:15, Anthony Towns wrote:
> On Fri, Oct 24, 2014 at 12:57:49PM +0300, Aigars Mahinovs wrote:
>> No developer in that chain was compelled
>> to run this under other init systems.
>
> Well, yeah:
>
> "1. Nothing in this constitution imposes an o
nt to support
running with *both* default Debian init *and* sysvinit (as the
canonical common shared init system API implementation).
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#--#
| .''`.
On 24 October 2014 12:12, Holger Levsen wrote:
> On Freitag, 24. Oktober 2014, Aigars Mahinovs wrote:
>> This is the same requirement as with regular dependencies. If you want
>> into next release, then all your dependencies must be there. If you
>> want to be supporting two
only support
that as an alternative. Is it really that hard to imagine pushing
upstream to make their software work correctly when systemd is not
running? Even when that upstream is part of systemd.
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#
does currently. Even systemd itself might decide to change
some of its APIs at some point. Thus the actual functionality of
software should not depend on the existance of a particular API. It is
fine for socket activation feature not to work if that API is changed.
It is not ok for the software to
of view of
software being able to start with an alternative init system managing
the installation (not from the point of view of having init scripts
for all init systems).
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#---
1 - 100 of 135 matches
Mail list logo
