Re: t2u in the archive
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 checkout at the point of signing
> (including file names, modes and short SHA checksum hashes). This
> extra content is added at the end of the tag message,
>
> OK, maybe I'm just not getting it, but the tag *already* contains the file
> listing you want to add to the tag, implicitly: it refers a commit which
> refers a tree which refers to exactly those files.
>
> If it ever does not, then we'd all have _way_ worse problems than figuring
> out how to safely create a t2u tag.
>
> So what would this actually buy us, in terms of additional safety?
Yes and no. See what the git tag actually contains and what the GPG
signature actually signs is just the one hash of the commit object.
This commit object then refers to the other files of the repo, but the
GPG signature does not directly sign those.
I just did a local experiment to verify this. I created a new signed
tag in one of my repos.
$ git tag -s -m "test signed tag" 24w27.1-1
Then I inspected the result with this command:
$ git cat-file -p 24w27.1-1
object 4d0e377e992901f873bfca5850eb8862b9a1f057
type commit
tag 24w27.1-1
tagger Aigars Mahinovs 1719829010 +0200
test signed tag
-BEGIN PGP SIGNATURE-
iI0EABYIADUWIQSeqa3XEFMtCKeITWHKWshbVxu0FgUCZoKCEhccYWlnYXJzLm1h
aGlub3ZzQGJtdy5kZQAKCRDKWshbVxu0Fq4fAQDSySaFH9ytCr70i+Bs0MxfPDRt
BQ4O9Xp9JCoXnrVsiAEA/i8CUFqSlU51fy1UL6YTPC/O4pq1QUYcVJP7X9V5FAo=
=r+o7
-END PGP SIGNATURE-
That looks like simple text and detached GPG signature. So to check
that I split the text part and the signature part into two files:
```
object 4d0e377e992901f873bfca5850eb8862b9a1f057
type commit
tag 24w27.1-1
tagger Aigars Mahinovs 1719829010 +0200
test signed tag
```
and
```
-BEGIN PGP SIGNATURE-
iI0EABYIADUWIQSeqa3XEFMtCKeITWHKWshbVxu0FgUCZoKCEhccYWlnYXJzLm1h
aGlub3ZzQGJtdy5kZQAKCRDKWshbVxu0Fq4fAQDSySaFH9ytCr70i+Bs0MxfPDRt
BQ4O9Xp9JCoXnrVsiAEA/i8CUFqSlU51fy1UL6YTPC/O4pq1QUYcVJP7X9V5FAo=
=r+o7
-END PGP SIGNATURE-
```
And running `gpg --verify` with those two files showed a good
signature. This confirmed my theory that the git tag signature nothing
more than a signature on this exact text that we see above.
It signs the commit object hash, tag name, tagger identity and
whatever is in the tag message.
Just dumping the output of `git cat-file -p ${tagname}` would provide
a way of verifying the uploader signature even without git.
And including the output of `git ls-files ...` in that message would
both provide a non-git way of matching this tag to the tarball and
would additionally extend the scope of the GPG signature to hashes of
all files in the repo checkout directly, without going through
multiple hash object jumps in the git object hierarchy.
As far as I can see doing things this way provides for a rather simple
verification pathway that does not involve running git or parsing git
objects. It's easier to reason about this compared to rather complex
git internals. Can even be done in a shell script.
Does this actually prevent or make herder any attack vectors right
now? I don't think so.
However, implementing it this way does give us options later, for
example if `git ls-files` gets an ability to print stronger checksums
of files we can switch to use that and gain stronger checksum benefits
even if the git repo itself remains based on the current checksumming
scheme. If we (later) agree to require that the maintainer has not
only git and gpg installed locally but also sha512sum binary, for
example then the client command line can be later changed so that it
uses that binary to create checksums of all files instead of using
checksums that git already has. Same for another (not invented yet)
hashing algorithm. And all without having to change git internal data
structures for all the repos.
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#--#
| .''`.Debian GNU/Linux (http://www.debian.org)|
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `'Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--#
Re: Summary of the current state of the tag2upload discussion [and 1 more messages]
On Sun, 30 Jun 2024 at 20:49, Ansgar 🙀 wrote:
>
> On Tue, 2024-06-25 at 11:00 +0100, Ian Jackson wrote:
> > Simon Richter writes ("Re: Summary of the current state of the tag2upload
> > discussion"):
> > > You can only call it "forgetting" to do a git push if you introduce a
> > > policy that contributions to git-maintained packages have to be made
> > > through git.
> >
> > In fact, tag2upload avoids this *even for NMUs made outside git* !
> [...]
> > But, with wide tag2upload adoption, things are even better:
> >
> > If everyone is using tag2upload[1], we simply avoid the problem,
> > by avoiding the mistake. This is because git-debpush's default
> > behaviour is to push your *branch* as well as just the *tag*.
> >
> > So the original mistake, of forgetting to push to salsa, is simply
> > avoided, because it's not something human needs to remember to do.
>
> As far as I understand this requires:
>
> 1. Either one canonical repository on Salsa for each package to which
> everyone (including non-team members for NMUs) have full access or
> alternatively having some tag2upload-related service having full
> access.
> 2. In case of multiple repositories, all of them to be in sync.
>
> What will tag2upload enforce here? Or is there some alternative
> solution that works in the context of NMUs and Git repositories hosted
> on Salsa?
There are two interesting options here:
1. There is a non-git NMU on a package that is normally managed via git and t2u
The maintainer would need to "accept" the NMU by importing the change
into their git tree. Somehow. Presumably via dgit service. I would
expect that each git workflow will have a slightly different way of
doing this correctly which will need to be practised and documented.
2. There is a git-based NMU on a package that is normally managed via
git and t2u
- if the NMU author has access to the main git repo of the package on
Salsa they can make a commit and tag there (normal team-like
maintenance)
- else the NMU author would have to fork the main git repo of the
package on Salsa to their own Salsa namespace and create a commit and
tag there. The NMUer would then create a pull request to the main repo
and the maintainer approving this pull request would (quite cleanly)
accept the NMU
As you can see the git repos do not *have to* be in sync, but the
Debian process of accepting a NMU already provides the path to getting
to eventual sync.
There is no way to push a tag without having some kind of repo to push
it to and you can'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:aigar...@debian.org
#--#
| .''`.Debian GNU/Linux (http://www.debian.org)|
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `'Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--#
Re: t2u in the archive
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 I believe the intention is to have two > > > > technically redundant data points saved into the archive: > > > > > > > > 1) checksums of the contents of the shallow copy git tree in the > > > > maintainer work folder (signed by the maintainer) > > > > 2) contents of the shallow copy git tree in the t2u server work folder > > > > (signed by t2u) > > > > > > Oh! Did I misunderstand Joerg's second point entirely? By "the tag that > > > t2u wants to upload," I assumed that meant the tag the uploader signed or, > > > in other words, the state of the tree *before* t2u started doing its work > > > that has the uploader signature attached. > > > > I do not see that in either what me or Joerg wrote. And I also don't > > see much sense in that. > > > > In contrast, having a tarball of the git state *before* t2u starts its > > work would provide a tarball that *can* be verified against the > > checksums from the first file. That will give you a clear data point - > > t2u started its work with the exactly the same workspace as the > > maintainer signed. And will provide a frozen copy of that starting > > workspace in the archive independent of the (more complex) dgit > > service. > > It's one at the point the maintainer signed the tag. Yes, but I would like to point out the difference. It's where and when this tarball is created. 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 checkout at the point of signing (including file names, modes and short SHA checksum hashes). This extra content is added at the end of the tag message, after the other metadata that t2u proposal/code already defines. This tag is pushed to a git server that t2u is monitoring. No files or tarballs are created at this point yet. No files or tarballs leave travel out of the developers computer. Only the signed tag with a (now quite long) message. t2u starts its work by checking out the git tag and saving two files: 1) the tag message with the corresponding Devian developer/maintainer signature, so it can be checked outside of git (can this be done easily?) 2) tarball of the git clone before anything is done to it - filesystem tree in this tarball will be (presumably) the same as what was in the workspace of the maintainer when they signed the tag Both t2u and dak may check this equivalence at any time in the process. The contents of the listing in the tag *should* match the file tree content of the checkout that t2u gets from git. If that does not match, then something fishy is going on and the upload should be aborted. After that t2u does all its processing, pushes the unified git tree to dgit, constructs the source packages, signs the source package and the new two files and sends it all to dak. IMHO that all makes sense and does not block anything while providing useful features, like a frozen git snapshot in the archive. Please correct if I got anything wrong. This is getting into lower level git and t2u details that I am barely competent in :D -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--#
Re: t2u in the archive
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 the shallow copy git tree in the > > maintainer work folder (signed by the maintainer) > > 2) contents of the shallow copy git tree in the t2u server work folder > > (signed by t2u) > > Oh! Did I misunderstand Joerg's second point entirely? By "the tag that > t2u wants to upload," I assumed that meant the tag the uploader signed or, > in other words, the state of the tree *before* t2u started doing its work > that has the uploader signature attached. I do not see that in either what me or Joerg wrote. And I also don't see much sense in that. In contrast, having a tarball of the git state *before* t2u starts its work would provide a tarball that *can* be verified against the checksums from the first file. That will give you a clear data point - t2u started its work with the exactly the same workspace as the maintainer signed. And will provide a frozen copy of that starting workspace in the archive independent of the (more complex) dgit service. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--#
Re: t2u in the archive
On Sun, 30 Jun 2024 at 17:58, Russ Allbery wrote: > > The second file consists of a shallow git clone of the repository for > > the tag that t2u wants to upload, put into an appropriately named > > tarball. > > Just to double check, to make sure I'm not missing some subtlety, it's > intentional that this file contains all of the same information as in the > first file, and the first file is just a subset of this same information > in a different form? > > In other words, someone could verify the signature on the Git tag in this > file and then run the git ls-files command on the Git repository and get > exactly the same information as in the first file, so the first file is > technically redundant. I can think of some reasons why you might want > that, but it's a little surprising, so I wanted to make sure that's > intentional. 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 the shallow copy git tree in the maintainer work folder (signed by the maintainer) 2) contents of the shallow copy git tree in the t2u server work folder (signed by t2u) Sure, it does not encompass the full source info in many git workflows, but it does seem to add some defence against tag collision attacks. And provides a server-independent source code copy for easier archival. The only suggestion I would have 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
Re: General Resolution to deploy tag2upload
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 why this requirement is not appropriate have been ignored. Ansgar even explicitly stated that no replies or explanations were read (due to lack of time). If FTP masters (as a team) override this requirement publicly, then there should be no further obstacles to deploying tag2upload. Everything else has been already fully discussed. If not, then the GR is quite appropriate IMHO. If this was the same kind of discussion that happened five years ago, I can see why it was not continued. There is no point in service building a Debian source package where there is a hard requirement that the Debian source package must be a part of the inputs provided to the system. On Thu, Jun 27, 2024, 12:30 Joerg Jaspert wrote: > > > The ftpmaster team have refused to trust uploads coming from the > > tag2upload service. This GR is to override that decision. > > This is wrong, there has *NOT* been such a decision. > > > > In our design, the git tag contains simple metadata that can be > > written > > out by hand. ftpmaster stated a hard requirement that the signed tag > > must additionally include a manifest of all files in the .dsc. > > And that is wrong too. > > >
Re: Summary of the current state of the tag2upload discussion
Do you actually check that the contents of the source *package* (after all operations done by dpkg-source and possibly other tools) actually match what you were looking at before in your source work tree folder? Using the package compiled for the source package does very little to check for malicious code injections. You are not checking for unexpected network traffic or trying it in all environments that might contain trigger conditions. Like if attacker working you is actually targeting Iranian nuclear projects and the code will only activate if the local network has some peculiar network names or numbers. Your stamp of approval should be on the thing you actually read and checked, like your local git tree, which is then pushed (with the signature) to the public repos for all to see and then all subsequent processes can run out of that *public* true source. An official Debian build server for tag2upload is not a random 3rd party. It has the same exact security as the buildd servers that all of us have been relying on for years for much more complex (and less reproducible) binary builds. If it was good enough for binary packages (even when reproducibility was terrible), then 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 one > > thing and then signing something else is the problem. > > I'm sorry, but I cannot make a reasonable sense of the above, even if > you're repeating it over, and over and over... > > Of course what I expect in a source package is ... my source code! In so > many ways, I'm checking what I upload. For example, by using and testing > what I uploaded. Right, I haven't checked all files checksums one by > one. Never the less, I am currently confident that what I uploaded is > what I expected. That doesn't change much with the workflow you're > proposing, I'd still check that things are working as expected. > > But to the contrary of what you're saying, that *is not* the problem. > The problem is that you're proposing to sign something, and upload > something else, signed by 3rd party CI that you're willing us to blindly > trust. This makes no sense. We want your stamp of approval on the thing > you're actually uploading, not something else. You may as well make a > signed request to a REST API, it wouldn't be very different from signing > a tag in a random Git repository. > > Cheers, > > Thomas Goirand (zigo) > >
Re: Summary of the current state of the tag2upload discussion
Was the xy-utils compromise not happening until we became aware of it? There could be packages in Debian compromised this way right now and we wouldn't know unless we specifically looked for it. And even then we would not have much to actually compare to in order to detect such problem. Which developer change is legit and which is an injection? To detect this each developer would have to download Debian source of all their packages, unpack (on a separate computer) and compare the source tree to the contents of their main computer. There is no cryptographic relationship between the signed source *package* and the actual source. That *is* the problem. Inspecting one thing and then signing something else is the problem. On Mon, 24 Jun 2024, 23:00 Scott Kitterman, wrote: > I understand the theory. Are we aware of it happening? > > Scott K > > On June 24, 2024 7:42:25 PM UTC, Aigars Mahinovs > wrote: > >It's pretty simple. Compromise the computer of one developer, the one they > >use for development. Have your code be in one of the tools being called > >during Debian source package build (you don't even need root, just > writable > >element in PATH). Now you can inject a malicious payload directly into the > >tarball or debian diff of the target Debian source package. The developer > >will never see it in their code. It will arrive in the archive signed by > >the victim as part of normal delivery. There will be nothing suspicious > >about it unless someone else does a NMU and sees a bigger than expected > >debdiff. > > > >Even if the developer is very security minded and maintains a separate > >air-gapped signing laptop, that doesn't help unless you first actually > >analyse the actual artifact that you are signing. > > > >Maybe it would even possible to trick the developer into to signing an > >upload of a different package (add a binary package with high version to > >their source package?). > > > >With tag2upload there is no obscured source package file to be signed, so > >all content going into the archive must already be visible in the git repo > >being signed and will also be visible in the dgit repo. Any difference to > >the upstream will be quite obvious in either case. > > > >That is the difference between signing something that no human will ever > be > >reading and singing the actual source that everyone will be looking at. > And > >that is the difference between needing to secure just one service > >(tag2upload) instead of securing a thousand work PCs of all DDs. And we do > >this already for build machines. If one would want to sneak stuff into > >Debian, hacking a buildd would be the best target - you are putting hacked > >binaries into end user machines without leaving traces in source packages > >or repos. > > > >An attack on upstream where a release tarball is different form upstream > >git tree would also be side-stepped by the Debian maintainer simply using > >only the git tree as upstream and completely ignoring the tarballs. It > >would not provide a 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 way it's releases are done, it > wouldn't be > >> suitable for tag2upload)? > >> > >> Scott K > >> > >> On June 24, 2024 6:36:59 PM UTC, Aigars Mahinovs > >> wrote: > >> >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 them from being used just because we are used to the weaker > >> >approach. > >> > > >> >On Mon, 24 Jun 2024, 18:34 Scott Kitterman, > wrote: > >> > > >> >> > >> >> None of that changes the fact that it's what they signed. > Historically, > >> >> the project has found that useful and I think it still is. > >> > >> > >
Re: Summary of the current state of the tag2upload discussion
It's pretty simple. Compromise the computer of one developer, the one they use for development. Have your code be in one of the tools being called during Debian source package build (you don't even need root, just writable element in PATH). Now you can inject a malicious payload directly into the tarball or debian diff of the target Debian source package. The developer will never see it in their code. It will arrive in the archive signed by the victim as part of normal delivery. There will be nothing suspicious about it unless someone else does a NMU and sees a bigger than expected debdiff. Even if the developer is very security minded and maintains a separate air-gapped signing laptop, that doesn't help unless you first actually analyse the actual artifact that you are signing. Maybe it would even possible to trick the developer into to signing an upload of a different package (add a binary package with high version to their source package?). With tag2upload there is no obscured source package file to be signed, so all content going into the archive must already be visible in the git repo being signed and will also be visible in the dgit repo. Any difference to the upstream will be quite obvious in either case. That is the difference between signing something that no human will ever be reading and singing the actual source that everyone will be looking at. And that is the difference between needing to secure just one service (tag2upload) instead of securing a thousand work PCs of all DDs. And we do this already for build machines. If one would want to sneak stuff into Debian, hacking a buildd would be the best target - you are putting hacked binaries into end user machines without leaving traces in source packages or repos. An attack on upstream where a release tarball is different form upstream git tree would also be side-stepped by the Debian maintainer simply using only the git tree as upstream and completely ignoring the tarballs. It would not provide a 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 way it's releases are done, it wouldn't be > suitable for tag2upload)? > > Scott K > > On June 24, 2024 6:36:59 PM UTC, Aigars Mahinovs > wrote: > >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 them from being used just because we are used to the weaker > >approach. > > > >On Mon, 24 Jun 2024, 18:34 Scott Kitterman, wrote: > > > >> > >> None of that changes the fact that it's what they signed. Historically, > >> the project has found that useful and I think it still is. > >
Re: Summary of the current state of the tag2upload discussion
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 them from being used just because we are used to the weaker approach. On Mon, 24 Jun 2024, 18:34 Scott Kitterman, wrote: > > None of that changes the fact that it's what they signed. Historically, > the project has found that useful and I think it still is.
Re: Summary of the current state of the tag2upload discussion
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 > structure. IIRC, you've claimed it's not. I don't think either of us has > a > very good understanding of why the other believes that. I think for both > of > us it's just too obviously true/not true to be easy to explain. > There are a few problems with that. 1. The source package is not the end state and not what the end user ends up using in their system. Users use a binary deb that is .. generated by build and signed automatically by build key. You have to trust the build in the source to deb translation. Nowadays most builds are reproducible, but not all and they were not when buildd keys were introduced. The git-to-source conversion is a much simpler process than a build. I have not seen any good arguments against applying the same logic here. 2. What is signed is not the same as what the developer has been writing or reading. You are putting a lot of weight on this signature of intermediate, generated artifacts. Developers basically never verify that contents of the tarballs and diffs they are signing actually match the contents of their work folder. It would be trivial the create a modified tool in the dpkg-source chain that would inject malicious software just into the source package files just before they are signed, especially if targeting a particular developer. The tag in git is closest to what the developer inspected and actually can sign with confidence. All the downstream from that is a generated artifact that may be tampered with and is much harder to manually verify. From this perspective relying on debian source package signatures is less secure than the proposal with git2upload, but that is what we have historically agreed to accept. There is a bunch of steps between developer uploading the source package to the archive and all the way to the end user downloading and installing the final package into their system. And we (as Debian) have been diligently working towards automating and centrally managing as many of them as feasible. All this does is (for some packages) moving the automation state one more step closer to the actual source code. Just because this step used to be the first does not make it so special as not to be extendable in the same way. And then we can work or reproducible source builds and running two conversion servers and comparing results and other security improvements (which is a higher bar than what we demand for binary packages that actual end users are running). >
Re: What is the source code (was: [RFC] General Resolution to deploy tag2upload)
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 package the current version of the code? [*]
> > > 2) is the source of a package the complete history of the project? [**]
> >
> > That is a very different set of questions and that is based on a
> > false premise.
>
> I think you're talking somewhat at cross purposes with Gerardo and
> Paul. This subthread is about a wider, more philosophical question:
> is the git history, in the general case, a necessary part of "the
> source code".
I was more objecting to the conflation of "necessary" and "desirable"
in the context of
"all history" and "just the latest history".
I think it is desirable to have as much of a historical view as
possible on the source
code and its development. Even to the point of upstream switching
being represented
in the historical view as overwriting merges from a different branch.
Is it, strictly speaking, *necessary* for the purposes of source code
distribution, preservation
and enabling of derived works? I don't think so. a shallow clone with
just enough history
to be able to reproduce the source package build is what would be the
minimum necessity to
publish such source code. And in certain cases (like epoch changes or
history being
contaminated by non-redistributable files) the source distribution can
be rolled back to this bare
minimum to preserve technical sanity.
> > 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/developer
> > boundary.
>
> History diving is an important part of the maintenance and development
> of much software, nowadays. Which is why I'm in your "unless":
>
> I think the git history is often an essential part of the source code.
> And yes, that means, that for many packages, I think what is published
> in the Debian archive as the "source code" is *not* the source code.
> It's an intermediate build product.
I do agree with that sentiment. Just did not want to push it as
forcefully as to state that
as a requirement which would then bring up heavy technical and
possibly legal issues with it.
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#--#
| .''`.Debian GNU/Linux (http://www.debian.org)|
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `'Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--#
Re: What is the source code (was: [RFC] General Resolution to deploy tag2upload)
On Wed, 19 Jun 2024 at 12:57, Gerardo Ballabio wrote: > > Paul R. Tagliamonte wrote: > > I wonder if we have a good idea of what the project believes to be the case > > between #1 and #2: > > > > 1) Is the source of a package the debian source distribution? > > 2) Is the source of a package the VCS where the source is held? > > Let me rewrite that in a different way: > > 1) is the source of a package the current version of the code? [*] > 2) is the source of a package the complete history of the project? [**] That is a very different set of questions and that is based on a false premise. There is a very significant difference between the files in the latest debian source distribution and the files in the latest checkout of the git repo that the Debian developer is using to maintain that package. The latest checkout does not even actually have all the information that is required to generate the contents of the produced Debian source distribution. For example, in the git-debrabase workflow that Russ described on this list recently the latest checkout would not have any of the debian/patches files in it. The patches in this case are represented as separate commits in the recent git history that are rebased on top of the latest upstream release version commit. Conversions from git repo to Debian source *generates* those patch files. It is all still *just* the source for the current release version, but it is not coming from latest checkout, but from recent commit history. The minimal set of source data would then be the contents of the files/folders in the latest upstream release, plus contents and metadata of all rebased patches on top of that latest release commit. And that is the source as that is the preferred way to modify this software. History before the upstream release commit does not really matter anymore in the source code context. If one would shallow clone the git repo with depth to at least the last upstream merge commit, they will get the same results in generating the Debian source package and in all following steps. Using git for maintenance does not require keeping or shipping the *entire* history of the project. Just the latest iteration is enough. But that one latest iteration may involve more than one file/folder tree and more than one commit. The questions that Paul wrote are very different: is the specific format that Debian chose to package the source code for consumption inside Debian toolchain considered to be *the* source for software, or is it just an intermediate technical artefact of the process and the *actual* source of the software is whatever VCS or workflow 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/developer boundary. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--#
Re: [RFC] General Resolution to deploy tag2upload
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 bad in any inherent way, but it's not tag2upload. > It's > > not the thing that the developers have been working on, it doesn't solve > > the problems they're trying to solve, and it doesn't let people use the > > workflows that they want to support. > > You basically say "nothing would work at all". > > Is any change a hard blocker from the tag2upload team perspective? Or > is there some room for changes, even though it would be a design that > is not identical to the one currently proposed by the tag2upload > developers? > > Because from my perspective it mostly looks like us like ftp-master > willing to find some compromise, but the tag2upload side hard blocking > on any possible change. > > If there is absolutely no space for changes, then it's probably not > useful to have any discussion as we would just turn in circles. > > Ansgar > >
Re: [RFC] General Resolution to deploy tag2upload
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 the online service becomes part of > the archive. Effectively the dgit.debian.org becomes the archive or the snapshot service of the git view of the Debian source packages. People interacting with Debian on the Debian source package level can keep doing that exactly as before. But to access a deeper, git level of source you would, naturally, have to use different tools and access a different service. > - we need to distribute that on CDs and mirrors (which both have size > constraints) Do we? Already Debian source packages are in reality a separate set of DVDs (we don't even provide source on CDs anymore) and only a subset of mirrors. While having an option to have a dgit server mirrored might be nice, it does not really have to be inside the current mirror or archive structure. And it does not have to be a blocker. > - we need to keep and archive also the tools required for processing Which should be trivial as long as they are packaged. > - we still need to be able to comply with removal requests Same as, for example, Salsa git server? > - we need to be able to deal with "epochs" in package development > > For example, the "clinfo" packages that were shipped in jessie and in > stretch and following are completely unrelated, they just have similar > enough output that one could be used as a replacement for the other. > > If those had been git-maintained packages, how would those have been > archived? Is the dgit package namespace separate from Debian source > package names? Well, there are many ways to do that. For example have a merge commit that merges in the new upstream into the old upstream branch where the merge commit itself deletes all old files and replaces them with the new files. The Debian changelog would note the changed upstream and move on as normal.
Re: [RFC] General Resolution to deploy tag2upload
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 > > > a > > > .dsc and .changes and sign them, and then tag2upload should create them as > > > well and verify they match exactly. > > > > They will not. Translation from a git tree to a Debian source package > > with dsc and changes > > is not a trivial operation. > > If we can’t do this reproducibly and verifiably, then I don’t think we should > do tag2upload at all. It would be equivalent to only allowing source-only uploads if the developer has to always upload source files *and* a checksum of locally-built resulting deb files and rejecting any uploads where buildd generated deb files differ from those checksums. We did not have 100% reproducible builds when source-only uploads started and for sure we did not have them when buildds started uploading debs to the archive and yet that did not block the progress. Even now a compiler version difference will produce different binaries. And that is a good thing. Forcing binary reproducibility is not a useful metric. Especially when one of the environments is an uncontrolled developer local machine that may even have unreleased versions of various software running. Having two separate tag2upload servers create a Debian source package from the same git commt with the same versions of all software installed, that can be a valid improvement to security. Doing non-trivial computations on the developer machine only increases false positives. -- Best regards, Aigars Mahinovs
Re: [RFC] General Resolution to deploy tag2upload
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 a > .dsc and .changes and sign them, and then tag2upload should create them as > well and verify they match exactly. They will not. Translation from a git tree to a Debian source package with dsc and changes is not a trivial operation. The results of it change over time as tooling and procedures evolve. And that is a good thing. The exact formatting of the changelog entries generated from git commits or of the patch files generated from git changes can and will change over time. So a Debian source package generated for the same exact git source may be different depending on what versions or the involved tooling the maintainer and the tag2upload are using. But none of those changes *actually* matter, because what the maintainer is looking at, verifying and signing is the state of his development folder, his git tree. He is not changing, inspecting or validating the Debian source package. That is why it makes no sense for the developer to sign the Debian source package - he has no idea what is in it. The git tree, the commit id and the associated git object hashes *is* the actual manifest of the actual source code files that the developer inspected and is attesting to be correct. Not their transformed versions in the Debian package format. This is *exactly* the same situation as we already have with source-only uploads. There is a state of the software upload that the developer signs off on and then there are further technical build artifacts that the developer does *not* sign - they are signed by the technical systems that generated those artifacts. And those systems are centrally maintained for scalability, convenience and security. All this is just an extension of the source-only upload to be even more "source". -- Best regards, Aigars Mahinovs
Re: [RFC] General Resolution to deploy tag2upload
On Tue, 18 Jun 2024 at 01:57, wrote: > > There are plenty of valid use cases that do not create a dsc locally. > > Please be specific in why it is unacceptable to have a local tool do local > (very quick) computation in a full automated way for you. Why is this > unacceptable? > > > The whole point is that dsc package is *not* source. It is not the format > > most commonly used for development work. It is an intermediate software > > generated artifact. > > What point are you trying to make here? A .dsc is metadata for the upload > indeed, just like the > .changes. Then what? Why should you care if a local tooling on your laptop is > building it, adding it to the signed tag, and maybe (optionnaly) deleting > your local copy after sending it to Salsa CI for the upload? > > > Everything after that: dsc, deb, Packages.gz, Release.gz are generated from > > that actual source tree and can be handled by appropriate automation. > > Have you ever created a .dsc file by hand? I suppose answer is no. So what is > the trouble ? Or are you saying I am proposing to do that ? I suppose no as > well. So what bothers you? :) > > That your laptop need to calculate the hash of your debian.tar.xz when > tagging? Isn't this a very small deal to make, so we don't need to touch a > bit to our infrastructure, auth and ACLs? Plus having no "a single key to > sign them all" would be an awesome feature. The point is that with certain git-centric workflows (like what Russ described for git-debrebase) there never is a *.dsc or a debian.tar.xz or even an orig.tar.gz. Those are never there to be checksummed. And the process for getting from the real git tree that a developer *actually* does their work on and verifies the contents of to these generated source artifacts is sufficiently non-trivial that people end up never actually verifying the files they are signing. The signature on the dsc is signing something that people never actually check. It is bad from a process perspective because it means that generation of these artifacts from the real source happens on many developer machines with many different configurations and versions and may be influenced by old bugs. It is the exact same reason why we stopped building all binary packages on developer local machines. And it is bad from security perspective, because it is sufficient for one developer machine to have any piece of software in the software chain that assembles and signs the source package to be compromised and you will end up signing an artifact containing malicious code that never appeared in your source code tree or in any collaborative git repository. And there is zero trace of that ever happening, except the already signed code package. Same as a compromised compiler (or any other component) injecting a malicious code packages directly into a binary while a developer is compiling a deb package. The whole point of open source is to go back as much as possible from binaries running on the computer to a human-editable form of software. That is the source. In a git-centric workflow the git tree is the source of the software, not a tarball. So our release and signing 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 #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--#
Re: [RFC] General Resolution to deploy tag2upload
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. The whole point is that dsc package is *not* source. It is not the format most commonly used for development work. It is an intermediate software generated artifact. I can not imagine develplopers regularly manually inspecting contents of their generated dsc packages before signing them to make sure that source in files there match the files in their work dir. Developers signing a git tree state is far closer to developer signing the *actual* artifact that they are working on, inspecting and modifying. Everything after that: dsc, deb, Packages.gz, Release.gz are generated from that actual source tree and can be handled by appropriate automation. Nothing technically prevents dak simply looking at tag2upload field/file specifying the uploader key and reject the upload if that key is no longer valid by the time the dsc makes it to the dak. Or reject the deb upload for buildd if the original uploaders key is invalid by the time arm64 buildd has finished building the source-only upload they pushed yesterday. People loosing access is quite rare, so it doesn't hurt to make these checks multiple times and reject as soon as one check fails. Just because one system accepts the package for processing, does not mean that another system down the line can't reject it, especially when key criteria changed in the meantime. On Mon, 17 Jun 2024, 23:07 , wrote: > > > Sent from Workspace ONE Boxer > On Jun 17, 2024 6:23 PM, Ansgar 🙀 wrote: > > > > Hi, > > > > On Mon, 2024-06-17 at 14:59 +0100, Jessica Clarke wrote: > > > On 17 Jun 2024, at 14:53, Ansgar 🙀 wrote: > > > > It essentially introduces an alternative authentication system (and > > > > authorization system as tag2upload seems to care about DM status) > that > > > > *replaces* the one in dak *and* *disagrees* it. Even when you fix > one > > > > of the instances where the systems disagree, the basic problem > remains > > > > (~> at least technical debt). It is very bad design to have multiple > of > > > > these for a single system as you significantly increase the attack > > > > surface (and one of these usually ends up with less maintenance than > > > > the other). (Only one of the systems has to allow the upload, i.e., > a > > > > big "*OR*".) > > > > > > Would an API for tag2upload to use satisfy that concern? It feeds in > > > a source package name and key fingerprint (or the signature, or > > > whatever’s deemed useful), dak replies whether it’s valid for > > > uploading. Then you don’t need to trust tag2upload’s authorisation > > > checks beyond that it adheres to what dak says each time. > > > > > > Hmm, a signed manifest solves that problem and also adds some integrity > > verification and possibility for third parties to check the signature > > itself as well. > > Back to square one: Didier's proof of concept design is much better, as it > solves all of the concerns. No need to trust a 3rd party key, packages are > signed and identified with the uploader's key, and respect all ACLs. No > need to change anything to our infrastructure. Added bemefit: packages must > be reproducible to support it. > > The point it isn't solving: contributors still need to learn how to build > *source* packages locally. Is this a problem ? I don't think so: we are > talking about contributing to packaging anyways. Isn't this the bare > minimum knowledge to expect ? > > Thomas > > >
Re: [RFC] General Resolution to deploy tag2upload
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 totally untested packages even without tag2upload: > > maybe tag2upload would make this marginally easier, but then I do not > > believe that this is a compelling enough argument to offset the benefits > > of a tag2upload-like service. > > Minimal testing already generates a source package -- so it > disproportionately benefits workflows that upload totally untested > packages. We are well past that point due to source-only uploads. Users do not use source packages, they use binaries. And binaries published to users in vast majority of cases are built by our servers and not by the maintainer. And that is a good thing as well as that greatly reduces the chance of weird settings or weird build software on my machine breaking the software binaries for our users. Same applies to source packages. They are not source, they are just a technical intermediate format. For testing I'd rather tag a test build on Salsa CI, the 15 minutes later check logs, download the compiled deb file, test with that and tag to commit and release with confidence that the same tooling in the same environment will build the real release source and binary. This can be later enhanced to build and wait a bit to let you do a smoke test on final binaries before going ahead with upload.
Re: [RFC] General Resolution to deploy tag2upload
On Sun, 16 Jun 2024 at 17:32, Bart Martens wrote: > > On Sun, Jun 16, 2024 at 03:31:25PM +0200, Matthias Urlichs wrote: > > On 13.06.24 10:26, Sean Whitton wrote: > > > Yes. A proposal that has not yet engaged with the complexities of > > > 3.0 (quilt) is not one in which we can yet have any confidence. > > > > The proposal simply intends to do whatever the uploader would do to build > > the source package from a tagged git worktree, except in a controlled and > > sandboxed environment. > > > > I fail to understand why we should have any less confidence in that than in > > whatever the uploader does manually to achieve the same result (we hope!!). > > One could argue that neiter matter. It is the outcome that matters: the source > package itself. That's what gets distributed. One could argue that neither matters, it is the binary package that end users actually use on their systems, that runs commands on millions of installations, as root. And that binary package nearly always nowadays is generated *and signed* by an automated software system on one of Debian's servers. Not by the maintainer. 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.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--#
Re: Security review of tag2upload
On Sun, 16 Jun 2024 at 19:00, Scott Kitterman wrote:
> I can see that, but that leads to what I view as a problem. The thing in the
> archive is signed by a machine, not the human who decided it should be
> uploaded.
That is nothing new or particularly controversial for Debian Archive.
Nowadays, most uploads are source-only, so all binary packages are
built by buildd servers and thus are signed by a machine.
Even before that, the key index files like Release and Packages in the
archive have always been generated and signed by a machine.
Those are things that actual end-users use and that can directly
compromise millions of machines in a few hours. Pretty
important stuff IMHO.
Compared to that, a machine signing a Debian-specific intermediate
source package artifact (that normally is only
used by Debian buildd servers) sounds quite inconsequential.
The key is that 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...@debian.org
#--#
| .''`.Debian GNU/Linux (http://www.debian.org)|
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `'Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--#
Re: [RFC] General Resolution to deploy tag2upload
On Thu, 13 Jun 2024 at 12:02, Ian Jackson
wrote:
>
> Sean Whitton writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> >[Joerg Jaspert wrote:]
> >> Actually, we can set acls on fingerprints and then that key wont be able
> >> to upload anymore. That is not something recorded in the keyrings or the
> >> DM list. Obviously that is not something used often (really really
> >> seldom), it is more for "this key is compromised badly, please turn off
> >> anything with it *NOW*" situations, which it's what Helmut meant with the
> >> urgent cases.
> [and]
> >> *Really* seldom. I would have to dig and see when, especially for the
> >> timing thing with keyring team.
> >
> > Thanks. Then possibly it is sufficient for ftpmaster just to disable
> > tag2upload's whole key until the keyring update is pushed.
>
> I'm not sure this is a sufficient answer. We don't want uploads by
> revoked keys to appear on *.dgit.d.o either.
Correct me if I am wrong, but if we are looking at dgit.d.o as
snapshot and audit log
of the tag2upload service, 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 like invalid_$original_tag but still kept
around for people
to inspect if needed.
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#--#
| .''`.Debian GNU/Linux (http://www.debian.org)|
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `'Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--#
Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 16:20, Jonas Smedegaard wrote: > To answer your convoluted question, I am suggesting that Salsa and > tag2upload has very different needs (multi-user write versus multi-user > append-only, drastically simplified), and consequently to not argue that > reuse of Salsa for hosting tag2upload is a security benefit. IMHO this is an interesting point that can be a real and useful feature of the tag2upload system. Think of it as a source version of snapshots.debian.org - if tag2upload always saves the tagged state of the repository to a separate append-only git server whenever it processes a signed tag, that would provide a clear archival backup of the exact state of software that was processed for upload. It does not matter where tag2upload gets the initial tags from - it could be Salsa, it could be Github, it could be a developers self-hosted git server that is added to some tag2upload config file for polling, like Plane Debian works. tag2upload could pull from a bunch of git sources. The config of those repos does not matter anymore because tag2upload takes care of signature verification and of archiving. And where exactly tag2upload keeps it archive does not really matter, as long as it is an append-only git server (at least for the repos that tag2upload writes to, which can be separate from actual development repos). With that kind of setup, you could not only (like today) go to snapshots.debian.org to get the exact binary of the uploaded Debian package with its real state at any particular day in the past, but also go to the archive git server of tag2upload and for any processed tag check out the exact git state that was processed, regardless of anything that was later done to the original development repo/server. Even if that server goes down, the archive will remain. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--#
Re: Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
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'm getting a bad signature on this. > > > On Mon, 20 Nov 2023 at 00:22, Luca Boccassi wrote: > > Second version, taking into account feedback. Looking for seconds at > > this point: > > Maybe Santiago wants to adopt this text, rather than having 2 options? > > > Kurt > -- Best regards, Aigars Mahinovs -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I second adding this version to the vote On Mon, 20 Nov 2023 at 00:22, Luca Boccassi wrote: Second version, taking into account feedback. Looking for seconds at this point: - GENERAL RESOLUTION STARTS - Debian Public Statement about the EU Cyber Resilience Act and the Product Liability Directive The European Union is currently preparing a regulation "on horizontal cybersecurity requirements for products with digital elements" known as the Cyber Resilience Act (CRA). It's currently in the final "trilogue" phase of the legislative process. The act includes a set of essential cybersecurity and vulnerability handling requirements for manufacturers. It will require products to be accompanied by information and instructions to the user. Manufacturers will need to perform risk assessments and produce technical documentation and for critical components, have third-party audits conducted. Security issues under active exploitation will have to be reported to European authorities within 24 hours (1). The CRA will be followed up by an update to the existing Product Liability Directive (PLD) which, among other things, will introduce the requirement for products on the market using software to be able to receive updates to address security vulnerabilities. Given the current state of the electronics and computing devices market, constellated with too many irresponsible vendors not taking taking enough precautions to ensure and maintain the security of their products, resulting in grave issues such as the plague of ransomware (that, among other things, has often caused public services to be severely hampered or shut down entirely, across the European Union and beyond, to the detriment of its citizens), the Debian project welcomes this initiative and supports its spirit and intent. The Debian project believes Free and Open Source Software Projects to be very well positioned to respond to modern challenges around security and accountability that these regulations aim to improve for products commercialized on the Single Market. Debian is well known for its security track record through practices of responsible disclosure and coordination with upstream developers and other Free and Open Source Software projects. The project aims to live up to the commitment made in the Debian Social Contract: "We will not hide problems." (2) The Debian project welcomes the attempt of the legislators to ensure that the development of Free and Open Source Software is not negatively affected by these regulations, as clearly expressed by the European Commission in response to stakeholders' requests (1) and as stated in Recital 10 of the preamble to the CRA: 'In order not to hamper innovation or research, free and open-source software developed or supplied outside the course of a commercial activity should not be covered by this Regulation.' 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 developers and maintainers from being subject to the same liabilities as commercial vendors, which has caused uncertainty and worry among such stakeholders. 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 commercial vendors in the exercise of their duties when merely developing and publishing Free and Open Source Software, with special emphasis on clarifying grey areas, such as donations, contributions from commercial companies and developing Free and Open Source Software that may be later commercialised by a commercial vendor. It is fundamental for the interests of the European Union itself that Free and Open Source Software development can continue to thrive and produce high quality software components, applications and operating systems, and this can only happen if Free and Open Source Softwar
Re: Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
pa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive Response from the European Commission to a question from the European Parliament on FOSS awareness: https://www.europarl.europa.eu/doceo/document/E-9-2023-002473-ASW_EN.html (2) Debian Social Contract No. 2, 3 and 4 https://www.debian.org/social_contract - GENERAL RESOLUTION ENDS - - -- Kind regards, Luca Boccassi -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEFmwrqIlWRDzdY39G+mQ7ph0ievsFAmVanPAACgkQ+mQ7ph0i evuStBAAtXUNvhfZyTkUxOxB5i5o0P+bbkx5Abs8UU+LICRARCBIJ4aGdlQWMeTp Ye09hD3cBbbTtgid1idmpEOEbSJW1N0vhPLke1W1cJzv3lhSBLwgcb3fyB1KN1Ye PFG7/1cpAssQwfvobcaXG7CFWukWKApU9K84G8dv6DMiSvpMnxkBhzSwfLUnb5Y+ H4yZfEn3XdyOociXInxDB+AIVkfXXSwFTFWugYPV+SF371pgOhAZtkRhNOzEUjbJ DfPkQ1ljMg69Jrs11b2E9Bhe+zvqjSFUbjBv5y+lCusCtMaI5pKQvQjsuVKPpAY5 XtQ3E9Pt8EZQFTohyKe4jsfnUqCGxKXNE7taytTz5Cyf8AeyNsoS4qfXmbVFVTMy hkU5nBHPVYsB9OtjiK+pv1zM29w9o78ChzuFNinE0KQHzX11p39Udfw9VqZGw/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
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Wed, 15 Nov 2023 at 12:14, Simon Richter wrote: > 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 products > > > I find this part a bit ambiguous. When GitLab or Proxmox or RedHat sells > > services around a free software product, I think it's OK if they are > > covered by this regulation. Maybe it would be better with > > s/Projects/Organizations/? > > 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 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
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
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 I linked to and the language in that version. But that position should not be a blanket opposition to the legislation or containing overbroad statements. Specific highlights on what activities should not fall into the scope of the directive would be helpful. But beyond that, I have not researched this specific issue enough to recommend specifics. Peculiarly I am also not against Debian passing the resolution as it stands because the negotiatiators in the loop of reconciliation *are* able to use Debians position to argue for better open source conditions, even if the actual text in the Debian vote *were* far from perfect or accurate. (Which I am not saying it is) On Mon, 13 Nov 2023, 17:32 Ilu, wrote: > At the moment - as the official proposals are worded now - everything > depends on the meaning of the word "commercial". Please note that the > proposals have some examples on this as I mentioned before - but each > proposal is worded differently. > > The software is deemed commercial if > - the developer is selling services for it > - developers are employed by a company and can exercise control (= can > merge) > - the project receives donations (depending on how much, how often and > from whom) > - developed by a single organisation or an asymmetric community > (whatever that is, ask your lawyer) > - a single organisation is generating revenues from related use in > business relationships (notice the vague word "related") > - ... > > The 3 proposals differ on these examples but they show what lawmakers > have in mind. Their intent is to include every project where a company > is involved in any way. And we all know that without company sponsorship > a lot of projects could not exist. Luca might state that "Mere > employment of a developer is not enough to make an open source software > a commercial product available on the market" but the parliaments > proposal explicitely says the opposite (if the developer has control, > i.e. merge permission). It doesn't help making blanket statements > without reading *all* proposals first. > > There is even an inofficial 4th proposal circulating behind closed > doors, that tries to ditch the commercial/non-commercial differentiation > and goes off in a completely different direction (that will target every > project that has a backing organisation - Debian has one). It is all > still in flow. > > I cited the Parliaments proposal that says: "Accepting donations without > the intention of making a profit should not count as a commercial > activity, unless such donations are made by commercial entities and are > recurring in nature." which clearly states that recurrent donations by > companies make a software commercial. But Aigar still claims that > "accepting donations does not fall into any of those examples." > > What Aigar writes is what we would like to have (and what we are > lobbying for) but not what the EU presently wants and not what's written > in all proposals. > > It is not helpful to read legal texts with your own interpretation and > your own wishes in mind. Aigar and Luca are writing what they think is > reasonable (and I mostly agree) and what they gather from one of the > texts (and my hope is that that will be the outcome) but at the moment > that is not the consensus among EU legislators. This is why I want > Debian to make a statement. We need to argue against the dangerous > proposals - which are there and I cited some of them. Ignoring the bad > proposals by only reading the stuff that suits you does not help. > > My intention with this resolution is not to damn CRA. A lot of things > required by CRA are correct and are done anyway by almost all free > software projects (certainly by Debian). My intention is to give support > to those organisations that are trying to push CRA in the right > direction, notably EDRI and OFE (these are the ones I know of). > "Lobbying" is an integral part of EU law making and we should use it > like everybody else does. > > Please also note that cloud services like Azure are not effected by CRA, > that's NIS2. If you are familiar with European legislation you will know > that. > > Ilu > > Am 12.11.23 um 18:35 schrieb Ilulu: > > Am 12.11.23 um 18:09 schrieb Luca Boccassi: > > > We do know whether something is commercial or not though ... > > > > I sincerely doubt that. Just to illustrate this I'm citing a part (only > > a part) of one of the regulation drafts which are presently considered > > in trilogue. > > > > "(10) Only free and open-source made available on the market in the > > course of a commercial activity should be covered by this Regulation. > > Whether a free and open-source product has been made availa
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
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" in the context of > > this directive proposal is not really a supported notion in the text. > There are a few specific examples 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. > > I am not mixing, I think the current wording does not _exactly_ says > so, leaving a door open for abuse. > The current working does say what is commercial activity and accepting donations does not fall into any of those examples. But EFF, among others, does mention that it would be more comforting if accepting donations was explicitly highlighted as an example of activity that clearly falls outside of the commercial activity definition. -- Best regards, Aigars Mahinovs
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
You are mixing up completely unrelated things. Commercial entities and software coming from it have nothing to do with commercial activity. The commercial activity is what *you* are doing with the software. It is completely irrelevant where you got it from or if you wrote it. If you are doing commercial activity and are getting QT as a commercial product from a commercial entity, then it is *easier* for you - you can simply delegate the security responsibilities of that part of your software stack up to the QT commercial entity and you just need to take care of the rest of the stack, which you are *selling* to your customers (commercial activity!). Whether accepting donations *in general* makes your activity in providing software a "commercial activity" in the context of this directive proposal is not really a supported notion in the text. There are a few specific examples 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, Aigars Mahinovs wrote: > > > > 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 preamble would be enough to to fix any "bug" in the > legislation in > >> > post-processing via courts. As in - if any interpretation of the > wording of the > >> > directive is indeed found to be hampering open source development, > >> > then it is clearly in error and contrary to the stated intent of the > legislation. > >> > >> According to the current wording if, for some reason, I am held to be > >> responsible for $whatever, then I should go to court. Me, who lives in > >> south america (because yes, they are looking for culprits no matter > >> where they live). They already won. > >> > >> So, why not try and get the wording correctly from starters? > > > > > > IANAL, but to me the wording seems correct. As long as you are not > explicitly conducting commercial activity in > > direct relation to this product to a customer in the EU, none of this > applies to you. > > > > If you *are* engaged in commercial activity with customers in the EU, > then the EU wants to protect its people and > > also keep up the general hygiene of the computing environment in the EU > to a certain level. > > That's where I see things differently. With the current wording > someone could say: Debian receives donations and thus is a commercial > entity (look at the text!) Then if Qt comes from a commercial entity > and Debian is a commercial entity then anyone using Qt trough Debian > is doing a commercial activity. > > Call me nuts, but that's the way I read it, at least for the moment. > > -- > Lisandro Damián Nicanor Pérez Meyer > https://perezmeyer.com.ar/ > -- Best regards, Aigars Mahinovs
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 12:31, Luca Boccassi wrote: > > > I am *not* objecting to Debian taking such a vote and expressing the > stance intended. However, I expect that it will be seen by the EU > legislators with mifled amusement, because in their context and > understanding the legislative proposal already contains all the necessary > protections for open source and free software development processes. > However, if a company (say Amazon or MySQL) takes an open source product > and provides a commercial service based on that product, then they are > expected to also provide security updates, vulnerability notifications and > other relevant services to their customers. Which is also an intended > consequence of the legislation. > > > > The EU puts the interests of the consumers and of the community above > commercial interests. Even commercial interests of small businesses. > Allowing small businesses to "pollute" the digital environment with > insecure or unmaintained software just because they are small businesses > makes no sense from a European perspective. > > Indeed. This is good legislation, and the parts you quoted make it > exceedingly obvious that the legislators in fact do care about not > hampering open source development. It would be very, very strange and > self-defeating for the project to come out against this, as the next > time around (because if this doesn't pass, something else will - > software security in commercial products is too important to leave the > current far-west as-is) we might not be so lucky. > By now the EU is actually quite used to dealing with volunteer projects and open source projects in general. So they would not be surprised in the slightest. And I do not believe it would tarnish the image of Debian. A lot of the same comments *were* communicated to EU Commission and EU Parliament by IT industry associations, which employ lawyers that track such things and analyse possible impacts, including towards open source software, because that is a solid backbone of the modern digital economy (their words, not mine). And there were indeed many bugs in earlier revisions of these texts that would have made a bad impact if implemented as written. The EU listens *very* well to national IT associations of the member states for feedback on such matters and open source experts are very well represented in those. Opinions of IT people from outside of the EU are usually not considered to be relevant. As in not adding anything new that the EU experts have not already considered. Volunteer open source projects are seen as ... not being able to invest sufficient legal understanding into the topics to be able to contribute to the discussion meaningfully *and* keep up with the nuanced changes in the proposals over time. But umbrella organisations, like EFF are better positioned for this. See: https://www.eff.org/deeplinks/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
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
Correct. And I agree with that effect: * a company paying salary of a developer that contributes to an open source project outside of the commercial activity of the company does *not* expose the company to extra requirements * a company taking *any* software, including open source software, and selling a product based on that or related to that, to EU customers, *will* be required to think more about safety (regardless of who it employs and for what) The *one* negative impact I can see of this legislation is impact on small integrators that were used to being able to go to a client company, install a bunch of Ubuntu Desktop workstations, set up a Ubuntu Server for SMB and also to serve the website of the company, take one-time fee for their work and be gone. Now it would have to be made clear - who will be maintaining those machines over time, ensuring they are patched with security updates in time, upgraded to new OS releases when old ones are no longer supported and so on. This, over time, will reduce the number of forgotten and bit-rotting systems on the networks that provide tons of known security holes for attackers. Who will take the responsibility is still open - would that be the end customer itself, would that be the system integrator that installed the systems for them, can they maybe have a contract with Canonical for such support or some other company providing such services specifically for the EU. How much would that cost? How would that cost compare to 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 Mahinovs wrote: > > > > True, the employment status is irrelevant. However, in this example > Microsoft will actually have the liability of > > providing the security assurances and support for systemd and related > systems, because they are providing > > images of such systems as part of their commercial offering on the Azure > cloud platforms. And that will be > > true regardless of the employment status of a few developers. > > > > A company that does not provide any Linux system services to EU > customers, like some integrator operating > > just in Canada, would not have such exposure and thus would not incur > any such obligations. > > Yes, but they have to do that *as part of that commercial product*, > which is not systemd, it's whatever product uses it, together with the > Linux kernel, glibc, gcc, etc. That's a good thing, and it applies to > any corporation that ships any open source software as part of their > products. The corporation is responsible for security aspects of said > product and its part as shipped in that product, which is great. > > It doesn't mean that the upstream open source project is now suddenly > encumbered as a commercial product out of the blue - which is what the > person I was replying to concluded - because it's plainly and > obviously not developed solely and exclusively for that commercial > offering, given it's used everywhere on any Linux image from any > vendor that you can get your hands on by any means. > -- Best regards, Aigars Mahinovs
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
True, the employment status is irrelevant. However, in this example Microsoft will actually have the liability of providing the security assurances and support for systemd and related systems, because they are providing images of such systems as part of their commercial offering on the Azure cloud platforms. And that will be true regardless of the employment status of a few developers. A company that does not provide any Linux system services to EU customers, like some integrator operating just in Canada, would not have such exposure and thus would not incur any such obligations. On Mon, 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 *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 thus not > > > subject to this regulation. > > > > That's why I mentioned systemd in my other email, perhaps I should > > elaborate on that. > > > > The lead developer is employed by Microsoft (who have a certain history > > with the EU) and pretty obviously working on it full time. > > Employment statuses are irrelevant, as said development is not done as > part of any commercial product as per relevant legislation as > explained already by Aigars, so these points are moot. Mere employment > of a developer is not enough to make an open source software a > commercial product available on the market. > > -- Best regards, Aigars Mahinovs
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
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 preamble would be enough to to fix any "bug" in the legislation in > > post-processing via courts. As in - if any interpretation of the wording > of the > > directive is indeed found to be hampering open source development, > > then it is clearly in error and contrary to the stated intent of the > legislation. > > According to the current wording if, for some reason, I am held to be > responsible for $whatever, then I should go to court. Me, who lives in > south america (because yes, they are looking for culprits no matter > where they live). They already won. > > So, why not try and get the wording correctly from starters? IANAL, but to me the wording seems correct. As long as you are not explicitly conducting commercial activity in direct relation to this product to a customer in the EU, none of this applies to you. If you *are* engaged in commercial activity with customers in the EU, then the EU wants to protect its people and also keep up the general hygiene of the computing environment in the EU to a certain level. -- Best regards, Aigars Mahinovs
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
act that Github is > > not responsible for software hosted on its platform goes to imply that > > ever such software is a product. Whether something is or is not a > > product on the market is already quite clear, and the sources cited in > > the original mail themselves say that the CRA does not change this > > aspect. > > Because everybody agrees that software is a product. And if you can > download the product on github or elsewhere, it's made available. There > is an explicit exemption only for the platform, not for the uploader. > It's fine if you think your software is not a product, but be aware that > european market authorities will not agree with you. > > > Are you responsible for the warranty for > > software you push to Github if someone git clones it? Of course not. > > Not yet, but this will change, depending on whether the activity is > considered commercial or not. Of course the details are still unclear. > In your example, pushing to your repo might not count as "making > available" (thanks to a lot of lobbying), but tagging a release probably > does. What about CI artifacts? Nobody knows. > > > Because repositories on Github are not products on the single 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
Re: [draft] Cancel this year's in-person Debian Developers Conference DebConf20
On Fri, 22 May 2020 at 18:08, Paulo Henrique de Lima Santana < p...@debian.org> wrote: > In my opinion, the best solution would be postpone DC20 in Israel to 2021. > And push Kosovo to 2022 and India to 2023. > I believe this choice should be on the table when DC20 team takes the decision on the conference. Naturally it is not up to the local team to decide such a thing, but with the blessing of the global Debconf team and the DPL (and with Kosovo and India team consent) that should be a possibility. It would also not preclude holding a virtual online Debconf this year as well where volunteers from any place in the world could take up responsibilities. In fact, if we do it the maximum fun way we could even involve volunteers and speakers from around the world to have a week long 24/7 Debconf that just never stops (until we run out of topics for talks). So instead of 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, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--#
Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]
On 10 November 2014 07:14, Josh Triplett wrote: > For the sake of clarity, I'd like to point out that I didn't start this > thread solely because of a single IRC log, but rather because of a > pattern of behavior over the last year that shows no signs of changing. I do find it quite alarming that this discussion has now divulged into a discussion of the behavior one of the initiators of the discussion and has completely abandoned the actual issues. Regardless of who started what and when, attacking personal credibility of your opponent is not a winning argument. Even 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 Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabpywdupcxiq_zbd5crgzkwg2rzntgzc2-nwcka+whk91jv...@mail.gmail.com
Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]
On 10 November 2014 10:42, Ansgar Burchardt wrote: > Hi Bas, > > Bas Wijnen writes: >> On Sun, Nov 09, 2014 at 12:22:07PM -0800, Josh Triplett wrote: >>> 17:34:12 Diziet: I don't think that stating that we >>> don't want to swap on upgrades is something we can agree on >>> 17:34:25 Diziet: at least, not while the GR is >>> happening which seems to directly address this part of the question >>> >>> 17:34:28 dondelelcaro: That's not the question. The >>> question is whether it's something that would pass a TC vote. > [...] >> Fair enough, this is a part where the level of civility is lower. But >> Ian doesn't make an unreasonable point. If those who oppose him are >> forcing their side with an overruling vote, why should he refrain from >> doing the same? Consensus is great, but if we can't get there, we do >> want a decision. And majority is better than nothing. > > I find it at least very disrespectful to propose a technical committee > resolution that seems to contradict a GR currently in the voting phase. How exactly does that contradict the GR? The GR is currently between: 1. Non-default inits must be supported (as PID1) 2. Non-default inits should be supported 3/4 - nothing to see here, move along, anyone can do anything they want. The proposed TC resolution is what should happen on upgrade from previous Debian stable version to jessie - should the init system be switched for the user or not. There is *no* option in the GR that says that *only* systemd is to be supported. That would be the only option that would contradict a decision to not switch over the default init system on an upgrade. In fact no 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 Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDXJYd=orhPaiZOUDJvDTFZMNZ+RrrEpc+B3q532e=0...@mail.gmail.com
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
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 useful to know if other distros have actually already >> abandoned support for non-systemd init systems. > > RHEL/CentOS 7+, Fedora 15+ and Arch Linux have all dropped sysvinit support. ArchLinux is clearly dropping sysvinit. RHEL documentation also seems to imply that Sysvinit and Upstart are both dropped in 7+. Fedora actually is not that decisive, as far as I read here - https://fedorahosted.org/fpc/ticket/243 -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDVx=x9WtETQ94rFbTdVdpO2G1QLpJ=+pcpb4iv+gfx...@mail.gmail.com
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
On 30 October 2014 11:43, Matthias Urlichs wrote: > Arguments by popularity are not going to sway anybody here. Otherwise I > could shut you up with a simple "most other distros have switched and are > mostly-happy with it". :-P 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 useful to know if other distros have actually already abandoned support for non-systemd init systems. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabpywdx8ydwnssejmr3kqmogqj84xvskhai0n5o7lzqvnw1...@mail.gmail.com
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
On 30 October 2014 04:35, Marco d'Itri wrote: > ijack...@chiark.greenend.org.uk wrote: > >>If my GR fails I expect a series of bitter rearguard battles over >>individual systemd dependencies. > This looks like a great way to encourage people to make systemd > mandatory just to be done with this once and for all... :-) This discussion can end for good in two ways: * Debian declares that user choice of init systems is important and applications must respect that; * Debian declares that only systemd is supported; Any other outcome is likely to cause flare-ups for every new feature that systemd absorbs. And you just need to read Lennart's blog or watch the video of systemd presentation from Debconf14 to see that there is a *lot* of new systemd functionality coming up, much of it in direct conflict with existing tools, much of it providing (or promising to provide) some superior functionality and new APIs to use it. If you trust systemd upstream create these new features in a way that does not conflict with other implementations *and* not depend on their own implementations of these features from other parts of systemd code *and* that other applications 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 Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDUX+69dioENKRhzWi8qvtp2nGMmoWf-Hhm-mvHLG=g...@mail.gmail.com
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
On 29 October 2014 13:40, Neil McGovern wrote: >> * if we go the MTA/sh route, then we define lowest common denominator >> interface of an init system and only init systems providing that >> (possibly with a systemd-shim) can be init systems in the archive and >> also applications can only depend on presence of these particular >> interfaces; > > I think there's possibly a slight logic gap here, and that's around > "applications can only depend on presence of these particular interfaces". > > As far as I'm aware, we don't actually say that anywhere. Applications can > only /rely/ on those interfaces, but it's certainly possible for an > application to have a Depends: on a particular shell. Shell is relatively harmless, imagine if, for example, LibreOffice suddenly had a dependency on Exim (due to 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 (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabpywduykkm8bqcxrjreaxaqg12sxhhtc1jj5-ocedikn02...@mail.gmail.com
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
On 28 October 2014 18:20, Russ Allbery wrote: > With all of those facilities, we've taken different approaches; with the > mail transport agent, for example, we've defined an interface that all > mail transport agents are required to implement, and MTA implementations > that don't implement that interface aren't allowed to provide a mail > transport agent. We did something similar with /bin/sh. With udev, on > the other hand, we basically required everyone run udev; it's > theoretically possible to boot a system without udev, but it's not tested > and I think everyone would agree that it's not supported. For the > compiler, all of Debian is built with GCC, but some teams do test builds > with Clang and report bugs, which most maintainers merge and some don't. > And with libc, we do not even allow for the possibility of replacing the > system libc; you use glibc if you're using Debian on Linux, and that's the > end of that. This is an interesting insight. It also can be used to identify possible solutions for the current issue: * if we go the MTA/sh route, then we define lowest common denominator interface of an init system and only init systems providing that (possibly with a systemd-shim) can be init systems in the archive and also applications can only depend on presence of these particular interfaces; * if we go udev/gcc/glibc route, then we just say that all other init systems 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 in a obtuse way. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDWj6SK6k22=okmy3lm8txfey3n4b9ge+c9edo90bpa...@mail.gmail.com
Re: `systemd --system` as a viable way out of the systemd debate?
On 28 October 2014 12:12, Josselin Mouette wrote:
> This is nice and all, but how to you tell such a “sub-init” which
> services have been already started and which services it has to start
> itself?
The point of a sub-init would be to start one specific service.
Basically the idea would be that in /etc/init.d/gdm3 init script,
instead of starting the gdm daemon, one would start systemd with a
very special set of configurations (possibly even separate and
different from what one would use in a normal, systemd-based startup
of gdm). And on stopping of that service one would stop that 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) |
| `. `'Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--#
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/cabpywdvp_we-cygfcjqipfngah6muvqdzu-d2gehcw+7cz2...@mail.gmail.com
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
On 28 October 2014 04:29, Anthony Towns wrote: > The corresponding question for services versus init systems would be: > > - package "foo" has a .service file upstream, but no init script > - Alice packages foo, doesn't write an init script, and uploads it to > unstable > - it's automatically accepted to unstable > - upstart user Bob files a bug requesting an init script, but doesn't > provide a patch > - Alice says "just use systemd" and still doesn't write an init script > > with the question being "does release manager Carol stop the package > from being released"? > > AIUI, policy hasn't ever made not having an init script an RC bug Please, do not confuse the issue again - this is *not* about a package having init scripts for a particular init system. It is about a package being able to function at all (even if started manually) when a particular init system is running as PID 1. That is a completely new issue that has never been a problem for any software before. A per the terms of the original GR proposal, not having an init script for an alternative init system would 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/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabpywduebsywrx6hf7ho2kfgeyss_8+m_y4d1am775qfnkm...@mail.gmail.com
Re: Tentative summary of the amendments
On 24 October 2014 23:16, wrote: > I'd personally be interested in your non-devil's-advocate reasons for caring, > because > those seem likely to be solvable. I, personally, love the init part of systemd - the part that starts services (either on startup or on events). >> and there is no >> need to hardlock them into the init system too. > > I really wish you'd stop asserting this. You, and others, would > *prefer* that they're not part of the init system. That opinion (and it > is an opinion) on design and architecture is not universal, and there > are quite a few documented and frequently reiterated reasons to > integrate such features into an init system. Let me rephrase that - my opinion is that it would have been almost as easy to design and implement the IPC parts of systemd in such a way that they could be used independently from the init system part. In a way where users could mix and match the parts that they want to use in a particular system. I know of ability to compile out some parts, as far as I understand that still does not allow to, for example, run logind from a bash shell. And, from what I hear, it is highly unlikely that patches to that effect would be accepted upstream. > On the contrary, you gain a great deal of flexibility, without having to > write any extra support for it. Want to run another instance on another > port? Add another .socket unit. And note that you can do so in a > systemd --user instance if you want, or ephemerally via systemd-run or > systemd-activate. Easy to start a debug version that way too. We need to do a lot of work on updating Debian Policy and Debian Reference. I am learning new features of systemd with every week of these discussions. I still don't like the tightly integrated design, but that in itself is just an irrelelvant opinion. >> Applications have never >> been calling init system before. Try the same assumption with: bash, >> Metacity, gnome-shell. "When you application is started, it might be >> started by gnome-shell, in that case you may give gnome-shell an >> indication about your startup animation, but you may be started by >> something else, in that case you should still start, but it is fine >> not to provide the correct startup animation." > > Talking about "startup animation" dismisses features and integration as > trivial frivolities. Since you mentioned gnome-shell and metacity, > let's talk about an analogous situation to the systemd case. Formerly, > in GNOME 2, you could run a "panel applet" on top of gnome-panel, and > run gnome-panel within any desktop environment and window manager you > liked. Neither gnome-panel nor those applets exist in GNOME 3 Even though those were clearly understood to be plugins of the panel and not actual applications, there was quite passionate discussion about both porting them to Gnome 3 and about making a freedesktop.org common ground specification. Basically system notification area came out of that as far as I rememeber. > I think your analogy paints an unrealistically nostalgic and idyllic > picture of life before systemd, as though there were a pile of equally > capable init systems sitting around and a pile of software that all > happily ran on all of them, until systemd came along and made everyone's > life miserable by being entirely too useful. Sounds about right. > You're also implying that, out of a clear blue sky, the TC would declare > a new default, as though they weren't asked specifically to decide an > already contentious issue caused by a huge number of people *wanting* to > support a new init system and being FUDded away from doing so. Actually I am suggesting that TC would make a trivial decision on what is to be the *default* architecture, while other people would choose to understand that this decision means that all other architectures no longer matter. > Finally, you're suggesting that code already exists that would be > "cleaned up" and removed, and assuming that's the only reason to limit > architecture (or init system) support. The common case here, however, > would be *new* code to implement some new feature, depending on some new > support provided by (for instance) a new service. That is exactly 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 longer considered to be important by the upstream or maintainers). -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .&#
Re: Tentative summary of the amendments
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 wrote: >> Forget about init scripts. Imagine booting up a system with >> "init=/bin/sh" - it should be possible to run a command to start your >> service from there (without any init system at all). If you depend on >> other services, then those should be startable with simple commands >> too. If that is possible, then all is fine. > > More seriously, no, your expectations are no longer realistic or > reasonable. It is already not possible *today* to run "simple commands" > and end up with a working system; many services depend on other running > services, and the thing gluing them together is an init system. I am assuming that the person running the commands know about the dependencies in the services and starts them up manually and in the right order. Init system does *not* glue services together it only starts them in right order with right options - after that init system does not participate in the inter-process communication. > It's perfectly reasonable, for instance, for a daemon to expect to be > run as a non-root user, and be handed a low-numbered socket that it > could not itself open. It's not reasonable to require every daemon to > reimplement that code itself, with all associated security requirements. That is what tools like start-stop-daemon or daemontools are for. There is no need to reinvent things for every daemon and there is no need to hardlock them into the init system too. >> If systemd adds socket activation and you daemon uses it it is fine >> for the start up of that daemon to use socket activation. If a user >> is running another init system it is fine for socket activation not to >> work, but a problem would be for your daemon to crash or hang on >> startup because of this. > > Expect an increasing number of new upstream daemons to lack any code to > daemonize themselves, or to start as root and drop privileges, when a > perfectly reasonable and better-audited implementation already exists to > launch the daemon as non-root with no forking. And that's two of > several hundred features. You cannot expect all upstreams to > *duplicate* functionality that already exists, nor to maintain such > duplication indefinitely. I can see how it is beneficial to use something like that by default, but if you remove, for example, the command line options for specifying port to bind to, then you loose all kinds of non-default functionality, like the ability to run the same or a different version of a service as a one-shot on high port by a regular user, to start up a debug version locally, Sure it is easier to write a daemon that can only be started as a systemd service, but along with loosing support for all other init systems you also loose a lot of flexibility. >> You may use the advanced features, if they are available, but can't >> just assume that they will be. On the other hand it is fine to not >> provide some functionality if the advanced init system features are >> not available. > > Consider how ludicrous this would sound about any other software: > > "You may use the Linux kernel, if it's available, but you can't just > assume that it will be. On the other hand, it is fine to not provide > some functionality if Linux is not available." [snip] > Now, as a wishlist bug, sure, you could request fallbacks; some software > may implement them. Currently, some software in Debian has done so for > various dependencies. Huge parts of Debian, however, have hard > dependencies on Linux, glibc, X, and GCC, and those dependencies are not > in any way unreasonable. Actually, we kind of do that - such things are detected by configure scripts, for example. But all your examples (except GCC) are systems that applications have always been calling. Applications have never been calling init system before. Try the same assumption with: bash, Metacity, gnome-shell. "When you application is started, it might be started by gnome-shell, in that case you may give gnome-shell an indication about your startup animation, but you may be started by something else, in that case you should still start, but it is fine not to provide the correct startup animation." I do like the kernel and architectures analogies. We don't have a policy requiring software to work on all kernels/architectures. I believe that this situation is different because of the difference in starting conditions - imagine if in previous Debian release *all* software worked on all architectures, includ
Re: Tentative summary of the amendments
On 24 October 2014 17:27, Josh Triplett wrote: >> In any case, this is uncharted territory, because (to my knowledge) >> until systemd started integrating system level services into init >> system itself, applications never depended on particular APIs of init >> systems. > > Sure they did. Applications depended on daemons which depended > specifically on sysvinit functionality: /etc/init.d, /etc/rc?.d, LSB > init script metadata, dependencies on specific scripts and their > functionality. It wasn't much, but it was something. Did a deamon parse /etc/init.d/... files on startup to figure something out? I don't think so. Those files in /etc are configuration for sysvinit and not an API. Sysvinit calls services, services do *not* call sysvinit. The communication is only one way. AFAIK the only API that sysvinit actually has is tellinit. 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 #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDUToARDfuuPVwwsWXiGdPwpQ_t9=18srw6hm5scirm...@mail.gmail.com
Re: Tentative summary of the amendments
On 24 October 2014 17:14, Josh Triplett wrote: >> The key difference is that until this year all packages worked on all >> init systems (as in you could start any service or application with >> any init system as PID 1, even with "init=/bin/sh"). > > Until recently, it was a painful endeavor to be the upstream of a daemon > package, because init scripts were not portable between Linux > distributions; each distribution tended to have to write their own. > systemd actually viewed that as a *problem*, and *fixed* it; it *is* > fairly reasonable now to ship a .service or .socket or other unit file > upstream and expect distributions to not need to change it. That is *not* what the discussion is about. It is *not* about init scripts. Forget about init scripts. Imagine booting up a system with "init=/bin/sh" - it should be possible to run a command to start your service from there (without any init system at all). If you depend on other services, then those should be startable with simple commands too. If that is possible, then all is fine. If systemd adds socket activation and you daemon uses it it is fine for the start up of that daemon to use socket activation. If a user is running another init system it is fine for socket activation not to work, but a problem would be for your daemon to crash or hang on startup because of this. > In practice, demanding that packages work with all init systems, or even > with *two* init systems, demands that they support the > least-common-denominator of functionality provided by those init > systems. That effectively makes any new feature added to an init system > useless until duplicated. Yes - the demand is to make sure that the least-common-denominator does actually minimally work. You may use the advanced features, if they are available, but can't just assume that they will be. On the other hand it is fine to not provide some functionality if the advanced init system features are not available. > And in many cases, the systemd-invented services and features fill a gap > for which no previously implementation existed, so "used to work before" > is quite inaccurate. Not all features are optional; not every feature > needs fallback code to cope with its lack. Doubly so if such fallback > code does not already exist. 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 simply can not function without it. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabpywdx5+-wupusr3-jux9fjpgiyztg8yhpweeh8wjyqc99...@mail.gmail.com
Re: Tentative summary of the amendments
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 is about. > > That is things within the package itself. This is about doing extra > work. In case you rely on functionality which is only provided by one > init system, ensure the functionality is also available on other init > systems. That is not what is actually required. It is sufficient to handle the situation when such functionality is not available. That is inside the package and it has many different uses (different init, no init, restricted chroot, system in some weird state, API changed, ...). You can even hide that code behind a command-line option or a wrapper-script (so you don't have to detect availability of feature and instead rely on being called with a special option or name when extra functionality does not exist). No one is forcing you to implement features into another init system, so that is a strawman. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDWTeyfD2PixwTSOy5VW4sXhkq=36rmpfxhjaizd7mq...@mail.gmail.com
Re: Tentative summary of the amendments
On 24 October 2014 15:40, Josh Triplett wrote:
> What makes the systemd case so drastically different that those who care
> about alternative init systems cannot follow the same procedure?
The key difference is that until this year all packages worked on all
init systems (as in you could start any service or application with
any init system as PID 1, even with "init=/bin/sh").
The fact that the regression is introduced by an architectural
decision of systemd developers to tightly integrate system level
services into the init system (and not by a decision in Debian) causes
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:aigar...@debian.org
#--#
| .''`.Debian GNU/Linux (http://www.debian.org)|
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `'Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--#
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CABpYwDUhEAAeTYQXbBeMKuiFi8qzbp766=xw6wycajs7ptf...@mail.gmail.com
Re: Tentative summary of the amendments
On 24 October 2014 15:02, Josselin Mouette wrote: > However these choices heavily impact our users who (for whatever > reasons) want or need to use another init system. > > No, they don’t. “Wanting another init system” is not a functional need. > It is a tantrum from people who are confronted to change resistance, but > we don’t have to cover that requirement per se. So you want to force everyone to use systemd (by breaking enough software so that Debian becomes unusable with another init)? There have been, are and will be people with different requirements that systemd does not and will not satisfy. > The default init system should cover all use cases. And apart from a few > glitches that emerge from the transition, systemd does. This is why > compatibility has to be ensured in jessie, but post-jessie such a > requirement doesn’t make sense. "default init system" is not the same as "the only supported init system". And that attitude is exactly why such a GR is required. There was a decision to change the default init system (for new installations). There has *not* been a decision about switching users over 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.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabpywduj0dysumenhbj+pp7zazmxcsfntqq7nkkwb4cyxkd...@mail.gmail.com
Re: Tentative summary of the amendments
On 24 October 2014 13:33, Ansgar Burchardt wrote: > But instead we should take away packages that depend on a features only > provided by a specific init system (for whatever reason)? Do you think > we serve users better by taking away options from them? Sometimes - yes, especially in the long term. We did take away KDE from our users at one point. We also do not allow packages into the archive for many different technical and social reasons (patents, embedded libraries, ...). In the end our users know that *if* the software passed the scrutiny and got into Debian, then it must be good (for some definitions of good). > So, if P has a hard dependency on systemd-as-pid1, why do you want to > take P away from me? Because people not liking systemd are more > important than people not caring about it or even being okay with it? It is not about "people not liking systemd". It is about people using other init systems. The question is about how strongly do we feel about supporting this group of users. > I don't like some software too, but am sometimes required to use it > without an alternative. Can I demand that I can use packages without > said software? Like demanding libraries having to provide language > bindings for at least two languages so I don't have to use PHP[1]? :) Init system is special because there can be only one active in the system. If app1 depends on systemd (as PID 1) and app2 depends on runit (as PID 1) then it becomes impossible to use both apps (without changing init system and rebooting). Also IMHO init system should be a user choice and not dictated by other, unrelated, software. In any case, this is uncharted territory, because (to my knowledge) until systemd started integrating system level services into init system itself, applications never depended on particular APIs of init systems. We need to make a conscious decision on how to handle that. If we don't then it is likely that the process will go on as before: * systemd introduces a great new system level service, * key apps depend on that service to do great things (and stop working on all other init systems), * people using other init systems are sad, * after a lot of hard work a new ugly hack shows up to patch out or fake out the new service (making apps kind of work again, but not as good as before), * another flamewar/GR is started to stop systemd dependencies breaking software for other people * (repeat) I am sure that there will be several more rounds of these because systemd has a *lot* of very interesting and useful services coming up in their plans. I can't wait to use most of them, but at the same time it sound like they are developed in a tight coupling with systemd itself thus making all those very useful features unavailable to users of all other init systems. Like the upcoming wifi management changes - those sound great, but there doesn't seem to be a reason why it couldn't have been designed in such way that users of other init systems could simply call some executable with some params and have their wifi configured with those tools. Being the default init system should not be the mandate to break/rewrite everything else. In fact being the default init system should bring great responsibility *not* to break stuff. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDUhDk+akEFcN-oeuPV=pfstikc0aw6sxjarjh99wr_...@mail.gmail.com
Re: Tentative summary of the amendments
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 obligation on anyone to do > work for the Project." > > Compelling developers isn't something that can be done in Debian. 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 is about. I do apologize for my use of the word "compelled" as that was imprecise in the context. I invoke the 'non-native' excuse :) -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabpywdufzd2wayymv_dypavodnxcppl9v4vs5l-tu4omtw3...@mail.gmail.com
Re: Tentative summary of the amendments
On 24 October 2014 12:35, Ansgar Burchardt wrote: > In fact, they want to require that if P supports only A (and not A|B) > that the maintainers of P have to patch P to make it support B. In the > good old days[tm] it would be the responsibility of the people wanting > to use B to submit patches to make P work with B (but here I suspect > many people demanding support for B do not even use P[1]...). > > [1] In particular I heard somebody asked if anybody wanted to help > with this work and from my understanding the response was not > very enthusiastic... Why patch something you don't use after all? The root of the problem is coming from upstream not caring about alternative init systems. To take the logind case as an example - each of the dependencies from GDM to systemd make perfect sense in isolation. However, the end result (was) that GDM only worked with systemd almost by accident. No developer in that chain was compelled to run this under other init systems. However these choices heavily impact our users who (for whatever reasons) want or need to use another init system. Such users are used to having to write an odd init script for some service - that is an acceptable extra work for using a non-default init system. However it is a much harder task to have to implement a new API introduced by systemd or creating something like systemd-shim. We should not be pushing such burdens to our users. That is too hard a punishment for using an alternative init system and also upstream (or maintainer) are far better positioned to implement some workaround to make the software work with alternative inits. How to best formulate a rule that would make sure that happens is a good discussion to have. I myself prefer a requirement 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 #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDVH=uN5eoe5UTqWQt+E7ukF-+vrZYKz=xc5wol6h09...@mail.gmail.com
Re: Tentative summary of the amendments
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 init systems in next release, then it only >> can count if the two init systems that you support are also in the >> release. > > yeah, sure. Just til now it was mandating that someone packages some software > for them and put it in Debian. Now the mandate is also to keep it's bug free, > make sure it's part of the release and maintain it during it's lifecycle. And > people want to vote on this and by voting tell others to do that. Just consider your second init system to be your dependency. Then everything make sense - you can not get into testing unless your dependency is there already. That is a bit unortodox, but the intend of the GR is that you would choose to support one of the init systems already in Debian. Packaging a completely new init system was your choice. Same thing happens if you decide to use yet-another-jpeg-library instead of libjpeg* - you get the added packaging and maintenance burden. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDUUV2p8c1f030TU_akPBbs-D689LZ68ko=lpjs7df2...@mail.gmail.com
Re: Tentative summary of the amendments
On 24 October 2014 11:21, Holger Levsen wrote: > Hi Uoti, > > thanks for your summmary of the situation. > > On Donnerstag, 23. Oktober 2014, Uoti Urpala wrote: >> In another mail, Ian said that his interpretation is that the init >> system would not only have to be packaged in Debian, but in testing and >> not RC buggy. > > yeah, I found this interpration also "interesting"... (eg. that there is room > for interpretaion... I thought "in Debian" ment sid and could be buggy. Now I > learn that buggy packages in sid seem to not always be part of Debian... at > least not in the context of this amendment.) - interesting and a bit scary. 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 init systems in next release, then it only can count if the two init systems that you support are also in the release. It is however very discouraging that the preferred method of "supporting alternative init systems" seems to be to get the closest possible clone of their preferred init system and try to 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 #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabpywduwrecppxmtzrtkmfax5r1hy4z1b_ahrbwmearq3k4...@mail.gmail.com
Re: Tentative summary of the amendments
On 23 October 2014 22:17, Uoti Urpala wrote: > The essential part was what you cut away: > >> > So you agree that there is no fundamental problem with packaging >> > software that requires either systemd or uselessd? Does the GR still >> > require "someone"(tm) to package uselessd for Debian before >> > packaging >> > that other (fundamentally OK even by your standards) software is >> > allowed? To polish uselessd integration until it's actually a usable >> > init system in Debian? I assume you are not volunteering for this >> > work? > > In another mail, Ian said that his interpretation is that the init > system would not only have to be packaged in Debian, but in testing and > not RC buggy. > > So even GR proponents agree that software which works with either > systemd or uselessd would be fine. Yet they want to FORBID packaging > such software, unless someone packages and integrates uselessd for > Debian. That's a large amount of work which would be mostly unrelated to > the software running under those systems. And the proponents are not > volunteering to do such work. Software that works with either systemd or uselessd would be just fine, exactly because the extra effort that it would take to make it work with uselessd. That is because (as you show in the continuation of your email) this extra work (like implementing the systemd-shim) would also allow the same functionality to be used with any other init system. And that is the whole reason for requiring that. One the sotware is implemented with proper init-system-independance then all init systems benefit from that. >> I think that practical effect would be the same if we mandated >> "support running with at least one non-default init system at PID 1" >> or "support running with sysvinit at PID 1" or "support running with >> any init systems in the archive at PID 1" from the point 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). > > That's kind of backwards - the practical effect of the GR is pretty much > to require that everything must implement sysv scripts, No - you don't have to implement the startup scripts. But you must make it possible for the startup scripts to be implemented by not depending on availability of init-system-specific APIs (as in - have checks and fallbacks for cases where they are not available). > while there are > init features that should not be considered to be/remain specific to > systemd but sysvinit does not support. For example, any init system that > Debian might want to switch to in the future will support systemd-style > socket activation. Actually - no. It is quite possible that next perfect init system supports none of the systemd functions and even if it supports them, it is likely that it will have a different API. Relying on a specific API until it is an actual standart with a widespread implementation across a majority of alternatives needlessly ties us down to what systemd 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 refuse to work at all if that API is changed. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabpywdua5yo01vboa5iemsg2br+om-yqpzo+abrjmy1rw0l...@mail.gmail.com
Re: Tentative summary of the amendments
On 22 October 2014 20:14, Uoti Urpala wrote:
> Ian Jackson wrote:
>> Jonas Smedegaard writes ("Re: Tentative summary of the amendments"):
>> > Quoting Nikolaus Rath (2014-10-22 05:09:18)
>> > > I believe Ian's intended reading is that a package that depends on
>> > > uselessd | systemd (but does not work with sysvinit) would be allowed
>> > > by his proposal.
>>
>> Yes.
>>
>> In practice such packages are not going to be a big problem because
>> writing init scripts for them would be straightforward, and then the
>> dependency could be relaxed.
>
> So you agree that there is no fundamental problem with packaging
> software that requires either systemd or uselessd?
That would not be a problem, because uselessd is only an init system
and does not include all the extra services that systemd does, for
example - logind is not a part of uselessd. Therefore, even if
uselessd is packaged tomorrow, there would still be just one init
system in Debian implementing this feature. So the Ians proposal makes
it a bug to depend on features that are only implemented in one init
system. Naturally this whole discussion would become moot if all other
init systems decided to die and were excluded from the archive. Also,
in practise, once you assume that a feature might simply not exist, a
single workaround will work just as fine for all other init systems
that don't have the feature.
I think that practical effect would be the same if we mandated
"support running with at least one non-default init system at PID 1"
or "support running with sysvinit at PID 1" or "support running with
any init systems in the archive at PID 1" from the point 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
#--#
| .''`.Debian GNU/Linux (http://www.debian.org)|
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `'Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--#
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CABpYwDUBXtG+zDcKJNHMtrV8u8H5yc+=2u9p-vcesmhxm4n...@mail.gmail.com
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
On 20 October 2014 21:14, Joey Hess wrote: > Luca Falavigna wrote: >> The Technical Committee >> decided not to decide about the question of "coupling" i.e. whether >> other packages in Debian may depend on a particular init system. > > The tech committe made a separate ruling on this question, and decided: > For the record, the TC expects maintainers to continue to support > the multiple available init systems in Debian. That includes > merging reasonable contributions, and not reverting existing > support without a compelling reason. > http://bugs.debian.org/746715 That is actually a slightly different issue. In bug #746715 "supporting an init system" meant providing an init script to launch your service with that init system (or changing some return codes in the existing init script). It is assumed, that with a proper init script any service would work with any init system. In the context of this GR "supporting an init system" means being able to start the service at all if this init system is running as PID 1. This is a completely new problem created upstream. The fact that upstream created the problem also provides a "compelling reason" not to support any other init systems. And that is "coupling" - an actual, real dependency on an init system not just being installed, but also running as PID 1. Even if TC decision were expressed as binding, it would not ban/prevent such coupling. Ians proposal, however, would explicitly make such coupling a bug and would directly determine severity of that bug to "grave" if the package is completely unusable for users of alternative init systems. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDWNV5-xZ20N6XcWqVm4S-m5fPis=gbjcd+sswl+w3t...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
On 17 October 2014 20:07, Ian Jackson wrote:
> Lucas Nussbaum writes ("Re: Re-Proposal - preserve freedom of choice of init
> systems"):
>> If you agree that this is only a matter of general technical policy, and
>> that the current state of jessie matches what you would like to see
>> after your proposal, couldn't we just agree to withdraw both proposals
>> now, and discuss what to do for jessie+1 later?
>>
>> If someone makes changes to dependencies between their packages and init
>> systems that break this statu quo in jessie, you could still reintroduce
>> your GR proposal during the freeze. But I think that this threat would
>> be enough to maintain statu quo until we release (also, it is unlikely
>> that the release team would allow such changes to be introduced during
>> the freeze).
>>
>> What do you think?
>
> I can see why that is tempting.
>
> But this resolution is not only important within Debian, and not only
> for jessie.
>
> It is also important feedback for upstreams, and our peer distros and
> downstreams. At the moment there is a prevailing rhetoric that
> systemd is inevitable and everyone will (have to) be using it.
What if (purely hypothetically) there was a public announcement from,
say, release team that they consider it a RC bug if packages do not
work with sysvinit as PID 1 in jessie both for stable upgrades and to
maintain ability to switch init systems. And that after jessie release
there will be a discussion and a GR to determine what severity such
bugs would have for further Debian releases.
Could that be enough to drop the current GRs?
I *think* that particular statement we can all agree on. This would
send a clear message to upstreams right now with another reminder
later on. And it would postpone the controversial bit past the
release.
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#--#
| .''`.Debian GNU/Linux (http://www.debian.org)|
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `'Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--#
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CABpYwDV4tDwXUYL3q1hVdTQ+CX4=NsHKu7Mw=wt1xurqh+j...@mail.gmail.com
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
On 19 October 2014 18:27, Lucas Nussbaum wrote: > On 19/10/14 at 14:28 +0100, Ian Jackson wrote: >> > So I think that we are down to two solutions that really preserve the >> > 'freedom' >> > to choose an init system: >> >> I mostly agree with your technical analysis. >> >> > 2) packages MUST work with a specific interface, which is basic enough to >> > enable all alternative init systems to support it. The most natural such >> > interface is currently sysvinit: if a package works with sysvinit as PID >> > 1, it >> > currently also works with upstart, openrc, etc. >> >> The wording in my resolution comes from the TC discussion and >> specifies `at least one' or `some alternative'. To represent that as >> `all' is IMO misleading. > > I don't follow you here. > > Your main goal is to preserve the ability to switch between init > systems. [snip] > Requiring support for sysvinit sounds exactly like what you really want, > since users could then switch to any sysvinit-compatible init system. > Why not say so explicitely? I am inclined to agree with Lucas here - requirement of 'at least one' or 'some alternative' are quite imprecise, especially if multiple forks of one init system are present in the archive. The requirement to work with some minimal common API, such as the one provided by sysvinit, would be more precise and will cause less discussions later on. If the bug severity scaling is carried over from Ians original proposal [1], then that would be the best option (to vote on) so far. [1] Midified to: functionality degradation with sysvinit is a bug and the severity of that bug must be identical to what the severity would have been if such functionality degradation affected all users. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDWVWoNe1sJnEopNY37sp7zmYYey1R3E4UCpFP3bw2=9...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
On 17 October 2014 15:53, Ritesh Raj Sarraf wrote: > Why is SysV Init so unacceptable ? It is a neutral init that serves well > for all our sub-projects. Let that be the default choice. Please do not conflate two very different issues. The default choice has been decided and is not in question at this point. This is about ensuring that SysV init (among others) is and continues to be a *possible* choice for a user. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDWoejUKybVpJk=qzz1j1d6hozk20g-mrmvfh5gg4bv...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
On 17 October 2014 13:27, Matthias Urlichs wrote:
> If it passes (which I consider to be sufficiently unlikely to wonder why
> the *censored* Ian even bothered, but whatever), _then_ these lists are the
> right places to discuss the implications. Until then, let's keep it here.
>From the discussion so far (and please correct me if I am wrong) the
only implication of this passing would be that a failure of
init-system-neutrality would now be a serious bug.
It appears that with systemd-shim this bug is now fixed for Gnome (any
other packages depending on libpam-systemd to get logind
functionality). So this should not be a blocker for jessie release.
I am not aware of any other issues that could impact this release
stemming from this.
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#--#
| .''`.Debian GNU/Linux (http://www.debian.org)|
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `'Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--#
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CABpYwDXgCUNjay8=r=drdq6xkzhln-pwh8_c2y8anrrffye...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
On 17 October 2014 01:36, Brian May wrote:
> If people feel strongly that init system XYZ should be supported, then
> presumably somebody will do the work to make sure it is supported, and it
> does work.
[snip]
> On another topic, I think we need a GR stating that all software should work
> 100% with any window manager, especially my favourite window manager,
> Awesome.
Actually that is a *very* similar issue. Apps should be
window-manager-neutral as much as they should be init-system-neutral.
Imagine if suddenly all Gnome apps stopped working unless you were
running Metacity. It should not be up to window managers to implement
all the features that all apps use, it should be up to apps to only
depend on the common subset of features and to properly handle
situations when such features are not available.
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#--#
| .''`.Debian GNU/Linux (http://www.debian.org)|
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `'Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--#
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/cabpywdv386fzqkj+agwfuz-mp9y0a+6s1cy35fngbwjjvfe...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
On 16 October 2014 23:26, Paul Tagliamonte wrote: > On Thu, Oct 16, 2014 at 11:20:13PM +0300, Aigars Mahinovs wrote: >> According to my reading of the proposal - either logind gets an RC bug >> for not being able to work with other init systems > > To be clear, this would be a bug against src:systemd about it not > working with non-systemd. Do we expect the systemd maintainers to fix > this? To be frank, in cases like logind I would expect the logind binary package to be split out and its source patched in such a way to allow it to work without systemd running (however badly) and moving the main systemd package from Dependencies to Recommended. This would be no different if, for example, some upstream decided that they need to copy some common library, modify it and statically compile that modified version into their software - we would expect the maintainer to either convince upstream not to do that or to make and maintain a patch that would make the software work with the system shared version of the library. The proposal does explicitly allow for the software to have degraded functionality if an unsupported init system is used, so such shim is a valid option. [snip] > I don't think it's unfair that things don't work in Docker if they need some > userland stuff that isn't around. Well, if you want it around, you should be able to start it inside that container (or a chroot), without having to start up an init system there. And ideally have a way of connecting to that userland stuff running in host or other container by simply sharing some socket (file or network). Having such policy clearly stated should also motivate upstreams to consider what would and should happen when another init system is used when designing new software features, so that our maintainers (or users) don't actually have to face this issue too often. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabpywdxmg+cjqpqkh8fbgx33zyk8qo0j8s47x5rbwebif4+...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
On 16 October 2014 23:07, Paul Tagliamonte wrote: >> * if your software only works if started by this one init system - >> that is a problem. > > I don't quite understand this - what if you depend on something that's > only provided / supported on one init system? Take for example the case > of logind before we had the shim? According to my reading of the proposal - either logind gets an RC bug for not being able to work with other init systems (here logind is considered a separate piece of software) or apps who have a hard dependency on logind (without fallbacks for cases when it does not exist or is not running) get a RC bug for that (here logind is considered to be an integral part of systemd). >> The requirement is that software should be able to work regardless of >> how it is started - by systemd, by sysvinit, by other init system or >> by a plain shell script called from the "init=" kernel parameter. If >> there are any dependant services, those should be also able to be >> simply startable by anything. > > So we can't rely on a new library until that library is supported on all > init systems? (e.g. logind before shim, etc) I'd see it as - new library can't get into Debian [stable release] until is capable of working with installations being managed by any init system or even no init system at all (like inside a Docker container ;)). >> All software in previous Debian releases >> satisfied this requirement, so there wasn't even any need to consider >> adding such requirement to the policy. > > > Getting tired of these threads :( True that. But at least this is about an actual point. (IMHO) -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDURez_V93MCaG-JrJ0mZCFsT1C_wRwQ6Wozb=2zl6z...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
On 16 October 2014 22:13, Ansgar Burchardt wrote: > Aigars Mahinovs writes: >> We have all kinds of policies about what is fine in a package and what >> is a Release Critical bug. That is a big part of what makes a >> distribution. This simply adds - "must be able to work with any init >> system running at PID 1" to those requirements. > > No, it does not mean packages have to work with *any* init system. It's > specifically aimed against a specific init replacement, see [1]. See, there is a clear difference: * if your software works the same regardless of what process started it up - that is fine. (Even if you just provide a convenience start-up script just for one init system.) * if your software only works if started by this one init system - that is a problem. The requirement is that software should be able to work regardless of how it is started - by systemd, by sysvinit, by other init system or by a plain shell script called from the "init=" kernel parameter. If there are any dependant services, those should be also able to be simply startable by anything. All software in previous Debian releases satisfied this requirement, so there wasn't even any need to consider adding such requirement to the policy. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDXLb9vm_xR=cux2rhkz5ei4bbfarss7wfrtqvvnr3v...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
On 16 October 2014 21:41, Holger Levsen wrote: > And for what exactly? Gnome right now is installable with systemd-shim + > sysvinit, why can't this GR wait until after release when the dust has > settled? That is great! And is exactly what the GR is supposed make sure keeps happening. Debian would simply make a public commitment to keep supporting use of all Debian-packaged software with any init system. Does this also mean that such a GR is not actually a blocker for jessie release? > If you don't like upstreams choices, *you* should write patches. Not GRs > telling other people to do so. We have all kinds of policies about what is fine in a package and what is a Release Critical bug. That is a big part of what makes a distribution. This simply adds - "must be able to work with any init system running at PID 1" to those requirements. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabpywdubv0ymv3b63msizthe9gfn1xkoasgchgvtmcr4nnf...@mail.gmail.com
Re: Proposal - preserve freedom of choice of init systems
On 2 March 2014 23:59, Kurt Roeckx wrote: > On Sun, Mar 02, 2014 at 01:22:46PM -0800, Steve Langasek wrote: >> On Sun, Mar 02, 2014 at 07:15:09PM +, Sune Vuorela wrote: >> > Logind requires systemd. >> >> This is false, and therefore the rest of the question is irrelevant. > > I think the point of his question is to have an example that we > understand, and what the effect of this will be for other things > that show up in the future. Just assume that logind still > requires systemd, that there is no alternative to logind and that > he is not the maintainer of logind. IMHO there are two useful ways of implementing this GR into Debian Policy for such a case: 1) maintainer adds "Depends: logind" to the package and whomever wants to use this package with another init system has the choice of either creating a patch for this package to make that dependency optional *or* to create a patch for logind to make its dependency on systemd optional (as I hear such work is underway) 2) maintainer is mandated by Debian Policy to make sure that the package is able to run without logind and systemd (and whatever else that depends on systemd actually running on a system to work), even if in a reduced capacity This is not substantially different from the existing mandate of Debian Policy for the maintainer to fix or work around upstream decisions that do not agree with some other part of Debian Policy, like where architecture-dependent files are placed or how libraries are compiled, ... It is not be too far fetched to imagine people creating fully manual or homegrown init scripts in some cases. Ideally IMHO there should be an ability to start all the software manually one by one from a /bin/sh executed instead of an init system without having to get some very generic systemd-like services running first. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDVoi0mWUSzS5wpn3q5ip=-fpblibztaw44gocwxtk4...@mail.gmail.com
Re: GR proposal: the AGPL does not meet the DFSG
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 2009/3/19 Bill Allombert : > Dear developers, > > I respectfully submit this general resolution proposal to your consideration. > > Asking for seconds. > > - - - - - - - > General Resolution made in accordance with Debian Constitution 4.1.5: > > The Debian project resolves that softwares licensed under the GNU Affero > Public License are not free according to the Debian Free Software Guideline. > - - - - - - - > I second the above proposal. For me the whole reason of the DFSG is so that our user would be able to take all the software in main, use it, change it and distribute it with minimal legal hassle. Due to reasons other people voiced in the thread, I do not think GNU AGPL fulfill the implicit 'no legal surprises' criteria. - -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.5) iEYEARECAAYFAknZe9AACgkQMzCiFWcgm94RGQCePG2uVJv1aZpYtCFEIBLsZYMy 8kEAmgNQLXJy3zR9IzUSG7KSEqB12+LY =mERC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question for all candidates, was: Google SoC 2007 - we're in, sign up quickly!
MJ Ray wrote: > Bastian Venthur <[EMAIL PROTECTED]> wrote: >> Looks like Google is really everywhere these days. I'm curious about >> SoC: What where the last year's Debian projects and what was there >> outcome? Which projects where successful and which failed? I also mentored a I18N related project. The outcome of the project was mostly in the way of exploring a specific technical possibility in cooperation between Debian i18n and Pootle developers that was implemented in the Pootle codebase. The outcome of the project was not a working service, but rather some measures and ideas that have further progressed and should eventually help make a unified translation portal for Debian packages. > How would other candidates avoid dropping topics like this? [cc'd to > -vote for these questions, please drop -project or -vote on replies] From my experience, there is simply not much further to report on the topic. Google SoC code either get assimilated and then changed heavily or dissapears on a side branch. In either case there is little to follow up on. -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# signature.asc Description: OpenPGP digital signature
Re: Question for Gustavo and Sam: bringing back the fun
[I hope that continuing vote discussions after voting begins is fine] Margarita Manterola wrote: > On 3/15/07, Sam Hocevar <[EMAIL PROTECTED]> wrote: > >>My main approach to make it fun again to work on Debian is to >> reduce the frustration. You cannot have fun doing something if your >> contributions are ignored, if you cannot access the resources you need >> to do the work, if your administrative requests are postponed because >> there are more urgent matters, and if you do not know what is going on >> and why. > > Agreed, you can't. But even if all of these were fixed (and none are > easy to fix, anyway), that does not guarantee that everyone will start > having fun. > >> From my own point of view, there are several things that currently > make things not fun, which are not listed in your platform: > > 1) flamewars: the constant bickering on mailing list is depressing, it > takes away a lot of time, and it gives the whole project a bad > reputation. Flamewars are good if the discussions are based on facts. Lately most flamewars in Debian were on opinions, not on facts. If I am elected DPL, there will be plenty of things to discuss about that can be discussed based on facts and ideas and not just opinions of personal preferences. I think that will reduce the boredom on the lists and thus reduce the pointless flamewars. > 2) bad maintainers "owning" packages (i.e. not being able to help out > packages that are bad shape, because only RC or important bugs should > be NMUed). Thus, we see patches for "normal" bugs rotten in the BTS > for years. This is depressing too. Policy should dictate more about the packages then it does now. And I would also look positively on technical measures that would allow helping out a fellow DD with packaging while not imposing on him at the same time. > 3) reluctancy to change how we do things. There are a lot of DDs that > have a "We are the best distribution ever, we shouldn't change > anything" attitude. We are being left behind. All the other distros > are improving, renewing, adding extra stuff, and we are still doing > the same things. From my platform you can easily see that I do not have that attitude. > 4) jealousy, bitterness, envy, and other feelings like that among DDs. > If we just stopped the personal attacks and started concentrating on > what we like (free software, I assume we all like that), then we could > have much more fun. There are not enough changes to talk about, so it is natural that we started to talk about each other. > 5) (this should taken with a grain of salt) length of releases. > > About this last point, I'm all for stable and good releases, but I'd > like to quote some parts of Ian Murdock's "founding" message [0] > > (...) > 1) Debian will be sleeker and slimmer. > 2) Debian will contain the most up-to-date of everything. > 3) Debian will contain a installation procedure that doesn't need to be > babysat; > (...) I think that this needs to be revisited in the context that Debian now holds in the Free Software movement. You do not exist, if you are not in Debian. Keeping both that and the three points above is a very hard task. -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# signature.asc Description: OpenPGP digital signature
Re: Question for Aigars Mahinovs
David Moreno Garza wrote: > Hello Aigars, > > On the DPL debate held last weekend, you stated that you'd support not > trying to release while you on chair, but instead, work on a ~3 year > timeframe release. Why's that? There are two reasons for that: * the corporate reason - I imagine many users of Debian stable distribution to be of corporate nature. Such users dislike a need to change anything and upgrading to a new software version is a major headache for them (even if it is Debian stable). A 3 year release cycle will allow such corporate users to upgrade every 3-5 years which is the sweetspot for such operations. As for other Debian users, testing or even unstable might be more appropriate in the mean time. * the social reason - in my view Debian is overheating. A selfcentered desire to release as often as possible does not allow us to thing about what exactly are we releasing. Debian can release 10 releases a year, but that will not mean that there will be anything good in there. I think that we need to step back and think about bigger issues then what kernel version to include in the next release. Now that people are thinking about it, the ideas are flowing more rapidly - source in a version control system, bug system improvements, source package simplification, ... I do not claim to know what we should innovate on or how to implement that. Much more competent people are among us to do that. I do however claim that we need to step back, stop worrying about a release and start innovating again, or else .. or else Debian might just go too stable. -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# signature.asc Description: OpenPGP digital signature
Re: Question to candidates: position on non-free?
Kari Pahula wrote: > I would like to hear what the candidates think about the non-free > section. Is having it hosted on Debian's infrastructure still worth > it? Do you expect that there would be any changes regarding its > status during your term? Do you think that there are going to be > votes like http://www.debian.org/vote/2004/vote_002 again? My position is that the more software is available to our users in nicely packaged and easy to install for, the better it is for our users, for Debian and for the free software movement in general. Therefore I would be against closure of the non-free repositories. In my opinion there should be as little problem as possible for a non-free software developer to provide support for their software on the Debian platform, including by allowing of freeware software with enough redistribution rights to be distributed via the non-free. However it might be beneficial to split off management of the non-free repository to another legal entity, possibly in another country with a less restrictive patent law and/or less aggressive judicial system while at the same time maintaining all the same services via the main Debian development tools, such as BTS and (where possible) build demons. It would be a partially technical and partially legal solution, that some might argue is in a search of the problem. -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# signature.asc Description: OpenPGP digital signature
Re: Question to all candidates: Perceived hostility within the community
Matthew Garrett wrote: > Josselin Mouette <[EMAIL PROTECTED]> wrote: > >> There is nothing like a moral right to mock people, just like there is >> nothing like a moral right not to be mocked. > > Research[1] has shown that one of the primary factors deterring women > from involvement in free software is the perceived hostility of many of > the communities. Do candidates believe that mocking of other members of > the project is acceptable[2], given that a side effect may be to > discourage a significant body of the population from participating > within the project? What would be considered negative mocking by one person, might just as easily be considered a criticism combined with a bit of humour by another. If there is a line there, it is blurred and widely different for different people. Therefore, when I am being mocked, I always simply ignore any personal remarks or mocking comments and look beyond that to what exactly is causing that. It is almost always possible to extract some useful criticism from even the most snide remarks. After all, even if your worst enemy humiliates you publicly in the worst possible way on something you program does wrongly, the bug is still there, regardless of who and how told you about it. In the end, in a global community there are people with different boundaries and coping with people that have a different sense of humour or critique is essential for participation in such a global project. My experience shows that women are just as capable of recognising different social attitudes in people as men. Or do you disagree? -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# signature.asc Description: OpenPGP digital signature
Re: Questions to the candidates
MJ Ray wrote: > Aigars Mahinovs <[EMAIL PROTECTED]> wrote: >> * from the negative side we can see that Debian does not like money. In >> particular two things come to mind - Debian as a project should not pay >> people (any payments must be totally separate from Debian) and Debian >> does not necessary trust the paid developers (which was less of a >> concern this time). > > QUESTION 1: > > Some DDs expressed those views and some candidates seem to be interpreting > this as a general debian money-hate or business-hate. What evidence > is there that such views are either common or insurmountable? "hate" might be a strong word. Most people in Debian might not care if Debian pays some of its developers, but it is clear that some Debian developers care about it strongly and have significant fears, reservations and concerns about money collection, distribution and evaluation as well as potential segregation of the developer community on the issue. I have so far not seen a strong reason why such plans must be carried out inside Debian, but have seen much loud reservations against it. From this I might oversimplify and say that Debian "hates" to deal with money as it is a significant hassle with no real benefit (as opposed to some other organisation handling the process). The infrastructure money is in such case a necessary evil and it would be better if such could be avoided (by hardware and bandwidth donations). Again, in an oversimplification, that is nevertheless useful to get a point across, IMHO Debian loves money and business as long as these things do not interfere with the Debian project. > QUESTION 2: > > I also think that the whole 'hats' concept is flawed in at least two ways. > (Help, I'm channelling LUGRadio...) > > So, I would like to ask all candidates: what sides of your personality > will you try to show more or less if elected as DPL? I will show more of a diplomatic side and less of a coding side. IMHO a DPL during his term will be viewed as a DPL all the time, so the rest of his hats should be put to rest for the term. -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# signature.asc Description: OpenPGP digital signature
Re: Question for Sam Hocevar
On 04/03/07, Aigars Mahinovs <[EMAIL PROTECTED]> wrote: shocking measures (including the GNAA and niggerspace.com) to emphasise I meant http://www.niggaspace.com/ about which I heard in the news some time ago. -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for Sam Hocevar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sam Hocevar wrote: > On Sun, Mar 04, 2007, Holger Levsen wrote: >> On Sunday 04 March 2007 12:49, Sam Hocevar wrote: >>> juvenile that piece of software may be, I will not accept criticism >>> about it until Debian stops distributing software that encourages >>> stoning women and children, cursing homosexuals or enslaving daughters. >> What software do you have in mind? > >Our bible-kjv-text package, for instance. But Debian's honour is > safe, because we do not ship hot-babe. I agree with Sam on this point. The political correctness in some communities has been overemphasised lately. To the point that, for some definitions of "politically correct", the Bible would no longer be a politically correct text. At the same time the same text in many cases is the cornerstone of the religion in the same areas. This creates an amusing paradox of morality. For these reasons it is easy to see how some people could use any shocking measures (including the GNAA and niggerspace.com) to emphasise the paradox and try to "shock the people back to their senses". Or in other words to lower the acceptable level of political correctness to a level that is more acceptable for them, like it was some years ago or like it still is in other communities. And from such understanding would also come a conclusion that there is nothing sinister abut this behaviour, at least nothing that people should be punished about. - -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF6vEEMzCiFWcgm94RAuxfAJ9uj4UOuIisbh9GEyEclUXVYD4LSACfRlva Jfb8Ou5zCJybnMO4oGq337Q= =JVk6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question to all candiates: DebConf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> 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 think it should be implemented?
I think that it is long overdue. I do not have an opinion on the
technical details, but it surely is de-facto the official Debian
gathering, so it would only be logical if it would also be declares to
be such.
Even just beyond the recognition - there is a lot of money flowing
around with Debian name on it and I think that SPI should help ensure
that no problematic issues occur in relation to that money.
- --
Best regards,
Aigars Mahinovsmailto:[EMAIL PROTECTED]
#--#
| .''`. Debian GNU/Linux LAKA |
|: :' : http://www.debian.org & http://www.laka.lv |
|`. `' |
| `- |
#--#
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF6u2KMzCiFWcgm94RAiylAJ9ZaIleOv7md3BkvdkdTOyjzbPQoACeM6Ot
f4BE2c59dRpHyZs4jQimZnQ=
=CfqD
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for all candidates: Importance of unofficial archives
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> How important are unofficial archives for you? What whould you do to
> support them, if you consider them important? What could be done to
> integrate them into official Debian structure?
If we would follow along the line of my distribution trunk proposal in
the platform, then such archives could become first-rate distributions
or distribution instances enjoying as much of the benefits as we would
like to give them.
- --
Best regards,
Aigars Mahinovsmailto:[EMAIL PROTECTED]
#--#
| .''`. Debian GNU/Linux LAKA |
|: :' : http://www.debian.org & http://www.laka.lv |
|`. `' |
| `- |
#--#
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF6uyJMzCiFWcgm94RAsa0AKCZ7IjjrwCq1gcWB+Avm33h9VDg0wCfSv1Z
W/68RDWH6vlQGc3lP2+83I4=
=2kWA
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for the candidates: not being DPL.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > There are 9 people standing, with a wide range of ideas in their > platforms. If you fail to be elected, will you still work on things > from your platform? Which bits and why? I will continue to gather support for the configuration file reform and home folder clean up, because it needs to be done and it is the thing that can actually be done without the full support of the whole Debian project. > You may prefer to answer this: What part of your platform cannot be > done without the DPL working on it and why? Main idea behind my platform is to relax and look at the big picture with the specific ideas being just examples of the things that could be done. Most of them are too ambitious to be accomplishable without full support of the most of the Debian project, so the election is effectively a statement of support for the ideas. Which means that if I do not win the election, then these ideas have not enough support to be viable. - -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF6unbMzCiFWcgm94RApIHAJ9PdTxOiPjtu1fASDgHimRtGLzpqwCfbeCF 7pboUE3z2DYYx9ZeXPV1zDA= =GYuV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question to the candidates: inclusion of the kFreeBSD-* ports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > The kFreeBSD ports are now in a good enough shape to be included in > unstable. Aurélien Jarno got ftpmaster's approval for that during an > informal conversation at debconf5 [1] but so far, there's been no > progress on this front. > > Since then, the SCC split happened and ftp-master moved to ries, so > adding more architectures to the archive is no longer a problem, AIUI. > > Hence, what is your position on including those new, non-Linux ports ? > What would the timeframe be like, according to you ? As I am not aware of any technical issues blocking such inclusion, I would assume that it would be appropriate to include it soon after the next release. - -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF6ud+MzCiFWcgm94RAlYrAJ456MPA6soccI1crK2KghUa5FWQTgCeKyMx aJQOIl3XgqdSEf6MtPKjPVY= =S3hl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidates: the d-i conflict
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > On Tue, Feb 27, 2007 at 02:10:32PM +0100, Josselin Mouette wrote: >> Hi, >> >> I'd like to ask Anthony and Steve what they think of how they handled >> the conflict between Frans Pop and Sven Luther, and other candidates how >> they would have handled this conflict. >> >> To everyone: how would you avoid such situations to become this >> problematic in the future? > > I would try to mediate. This is exactly what our current DPL and others > have tried; however, in this particular case these mediation attempts > did not produce a result that was satisfactory for all parties involved. > > Whether this is the fault of the mediator, of Sven, or of Frans, is not > something I wish to comment on, simply because I was not deeply involved > in either of the two mediation attempts that I'm aware of. I must agree with Wouter on this. I have not been involved in this conflict, so I can not comment on the specifics, but I have involved with the discussions around krooger and I can see very well how mediation is a very sensitive problem that is best solved in person. Therefore my best advice for the current conflict would be to delay any decisions on that until the Debconf and have all the patries involved in the discussion there in person. - -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF6uUuMzCiFWcgm94RAjQ+AKClcFCiggXecZs/TFkwyqCSqCkZtQCfRTy/ IhNBU0yRJVKxz7IvJZmtaoc= =D6w4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question of time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Many of the candidates are busy in other parts of debian with doing some > other more or less important work. > > Which parts of your current work will you spend less time on when being > a DPL? I currently spend more time on other free software activities outside the scope of the Debian project. If I am elected, I plan to scale back those activities and focus more on the Debian work. > Have you prepared other people to eventually taking over those tasks for > you? Yes. - -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF6uKmMzCiFWcgm94RAiN5AJ499rHM4t7ELQxuLAH67CcbLzDGFwCeLBM3 E6/gtGMIA+jUj8Dz8Zpb3Lk= =7DEf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions to all candidates: Release importance, release blockers, release quality
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > So, to the questions: > > * How important are regular releases for the project? Less important then the quality of said releases and the overall importance of the Debian project in the free software movement. > * How important are regular stable point releases for the project? They are useful for the users with little to no connectivity and need to be done from time to time. > * Should we fix up dak to allow point-releases for old-stable? Not if it requires significant work. I see little point in this, but if someone sees more reason to do this and has the coding ability, then it cold be done. > * Could you list the issues that you think delayed the release of etch? > Do you think that we need to restructure the release process for lenny > to avoid these? If yes, how? No, I do not think it is required to speed up our releases more. > * Do you think that a release of high quality is more important than a > timely release? [ie: Should we switch from "when it's ready" to "when > we said we would release"] No, IMHO "when it's ready" is more then appropriate with a guide of one release every 18-24 months. - -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF6t73MzCiFWcgm94RAtMlAJ0ZRU/neBs0oXO+W7x5h2h6lUVWEgCghwAQ GOEVr2pC9V+46ccRN0FlyFQ= =dhEZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: One more question to the candidates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Forgot to ask this question: In your opinion, what is a good length of > total term for a DPL? IMHO one year is good enough as it provides a good way to re-evaluate the plans. If a DPL is doing his job good enough, then he should be re-elected to continue his plans. In that context the term becomes irrelevant. - -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF6tLBMzCiFWcgm94RAj++AKCoFHrTMUrd/7spmhrFdA6BOj/XCwCgqEGs K7V+0uCfwVp67PgB0TWuExg= =cfLK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DPL candidate question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > As kind of a follow-up to the basic 'what would you do as DPL that you > could not do as DD?' I would like to know more about how you would > handle marketing Debian. The very hot topic this week is Dell's move > to offer open source alternatives. Buried several clicks away from > Dells 'Ideas in Action' page is a vague reference to Debian pertaining > to 8G servers. Would you as DPL make it a primary goal to attract as > many DD's as you could to work specifically on eliminating the gotchas > of installing Debian on Dell Desktops, Laptops and Servers working > towards putting Debian at the top of Dells (and maybe others to > follow) list of approved and pre-installed OS's? Not as such. I think it would be more productive to work with either Dell or one or more of their resellers that already specialise in servers (hopefully, Debian Linux servers) and ensure that they know the best ways of contributing their bug reports or patches to Debian. Hardware problems are very hard to fix without the hardware at hand, so it would be very problematic for random Debian developers to fix such issues. What we can do is make sure that it is as easy as possible to fix this issues for the people that do have the hardware and the will to make it work. - -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF6s+hMzCiFWcgm94RAvc5AJ9pUSBfhjIx0XLTG8dumVDVuhwnAQCcDVxo OX6K9NIRABAVqnvhJ7MR5ow= =ja8J -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions to the candidates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Why do you think you will be a good DPL? Because I have the vision of how Debian can maintain its former (and, to lesser extend, current) importance in the free software movement. I am also good at looking at a problem from multiple points of view and communicating these points of view to other people. For example, I tried hard to understand Ted Walter both online and when meeting him at the Debconf. I agreed to live in the same room and talked to him trying to understand his point of view. When it became clear that his values are too different from the values of the most other peple in our project, I spent around 4 hours to explain this to him in his language. By the end he agreed that it would be best for all involved if he would search for another free software project to contribute to. This was just hours before expulsion. I believe that this my discussion with him was key to his quiet departure. > What you can for Debian as DPL that you can not do as a mere DD? Guide Debian towards a more strategic view on the development of free software. > What do you think of the current NM process? I think that it is mostly adequate with few exceptions when people can become lost in the queue. I feel that a wait of around one year is essential to test the NM's long-term endurance that will be required of him for long-term maintainership of his packages and for balansed participation in the mailing lists. - -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF6s1HMzCiFWcgm94RAnjtAKC28HtYNUO5tCuTy7tJbBn1/yct9ACggPfV gdRWH4w7fEe0Xkin0uquCEo= =PUYW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions to the candidates
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> What do you think of the dunc-tank initiative ? What do you think are
> the result of the "experiment" ?
I think that result is twofold:
* from the positive side we can see that people who are paid to do a
specific job, can do that job with a higher mid-term burst efficiency
and that money can be raised for such causes;
* from the negative side we can see that Debian does not like money. In
particular two things come to mind - Debian as a project should not pay
people (any payments must be totally separate from Debian) and Debian
does not necessary trust the paid developers (which was less of a
concern this time).
- From that I can surmise, that similar activities should continue under a
banner that is not in any (high livel) way connected to Debian or SPI
(no sharing of board members or DPL delegates being in the board) and
that there should be a community oversight over inclusion of the (larger
scale) work of paid developers into the project to prevent any
possibility of contamination by commercial interests.
- --
Best regards,
Aigars Mahinovsmailto:[EMAIL PROTECTED]
#--#
| .''`. Debian GNU/Linux LAKA |
|: :' : http://www.debian.org & http://www.laka.lv |
|`. `' |
| `- |
#--#
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF6spHMzCiFWcgm94RAn7dAJ42qgQynpSxVMgWuI2kwsk+gbT60gCfeYOG
QUXvfx7S0rII8X0XJ4JCCgE=
=kIql
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions to the candidates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > 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? A DPL should be all of the above, however in my opinion Debian currently needs a mediator that has enough leadership potential to turn debates from personal to strategic. > Do you feel that the DPL is first and foremost The Debian Project > Leader, in the sense that anything Debian-related the DPL does, he > does so as the DPL, not as a DD or a private person? I feel that DPL will have little time to contribute to Debian in the ways that all other developers do if he would be doing all the thing that only the DPL can do. > There are problems with communication between some key teams and > the rest of the project. What solutions will you try to implement > during the next year? Relieve them from the pressure of the release and then have them re-evaluate their roles along with the rest of the project in debates about the future direction of the whole project. > How do you feel about spending Debian monies into buying core > infrastructure support? Infrastructure is good and IMHO that is what Debian money is supposed to be spent on, but we must have clear understanding on how that would be used and how it will benefit the project. However, by this I only mean investments into hardware and essential services (bandwidth, electricity, cooling, ...) and not hire of administrators. > Currently just about every single conversation on -project and > -vote degenerates immediately into a (minor) flame war. What will you > do to fix the current atmosphere? Flamewars have either personal basis or are based on misunderstanding of the opponents position, possibly because of non-stated interests. Personal antipathies should be solvable by personal meetings in Debian events. If a flamewar escalates, then it would be appropriate for the DPL to step in and ask for some cooldown. In the worst case a compromise should be offered if at all possible. However I do not think that there is a major problem with some heated discussions if there are results. - -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF6sdYMzCiFWcgm94RApoUAJ9o8WHbJzW4IHrv4WrHFi0iILT0cQCfVYEu 668+bMTr/qUFFHKHeQuKjJY= =HRdQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian Project Leader Elections 2007: Aigars Mahinovs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I hereby nominate myself for the position of Debian Project Leader in the DPL elections of 2007. - -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--# -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFFzJfkMzCiFWcgm94RAqosAJ49+dfKcBWpR3JLOvWQqJ+5ytJJ/gCeMmnY X+ld1Qs/c+js9zmINsoGaBs= =Vqk/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Ted Walther interview
Hi all, I did an interview with Ted Walther on my blog that you might find interesting: http://www.aigarius.com/2006/03/10/interview-with-ted.html Warning: it is very long and is basically a subjective portrayal of another subjective position. Note: I am not subscribed to debian-vote, so please CC me on replies if you want me to read them. -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--#
Re: GR Proposal: GFDL statement
On 1/1/06, Anthony Towns wrote: > (2) How does it fail to meet Debian's standards for Free Software? > > The GFDL conflicts with traditional requirements for free software in > a variety of ways, some of which are expanded upon below. As a copyleft > license, one of the consequences of this is that it is not possible to > include content from a documention directly into free software under > the GFDL. Don't you mean GNU GPL in the end? That GFDL is conflicting with GNU GPL? -- Best regards, Aigars Mahinovsmailto:[EMAIL PROTECTED] #--# | .''`. Debian GNU/Linux LAKA | |: :' : http://www.debian.org & http://www.laka.lv | |`. `' | | `- | #--#
