Re: Salsa CI news

[Paul Wise]

On Mon, Feb 10, 2020 at 6:18 AM Dmitry Smirnov wrote:
> On Saturday, 8 February 2020 1:49:20 PM AEDT Paul Wise wrote:
> > There is one attribute of how Debian does things that clashes with
> > being able to do this; service maintainers need to be able to update
> > code on a different schedule to Debian stable and even backports
> > time-frames.
>
> When service maintainers build their services from upstream repositories

There is more to services than just upstream code, for example for the
Debian wiki, we install the python-moin package, checkout the git repo
to /srv/wiki.debian.org/ and we also have the private code and configs
for the anti-spam system. My comment here mostly refers to the
additional git repos that service maintainers store configuration,
additional scripts and other service-specific code rather than to the
upstream packages the services might be based on. I do acknowledge
that some services do need to use fast-moving upstream projects
though.

https://salsa.debian.org/debian/wiki.debian.org/

> I think ideally service maintainers should be package co-maintainers. But
> when there is a large burden to maintain either (the service and the
> package), I understand how people might focus just on one thing.
> But again, if everything we do here is about providing packaged software,
> when it is ever the right thing not to use our own packages?
> Certainly we don't trust upstream more than our fellow developers, right?

Using packaged software could be the ideal situation, but I think that
reality is more complicated and that we aren't able to use packaged
software for a number of debian.org services.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Salsa CI news

[Bernd Zeimetz]

On 2/10/20 7:17 AM, Dmitry Smirnov wrote:

> It appears to me that Salsa admins don't use packaged Gitlab-Runner simply 
> because they don't want to, and I don't understand why.

Seriously, stop that.

Instead of complaining, you could send tested patches:

https://salsa.debian.org/salsa/salsa-ansible/tree/master/roles/gitlab-runner

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Salsa CI news

[Dmitry Smirnov]

On Saturday, 8 February 2020 1:49:20 PM AEDT Paul Wise wrote:
> There is one attribute of how Debian does things that clashes with
> being able to do this; service maintainers need to be able to update
> code on a different schedule to Debian stable and even backports
> time-frames.

When service maintainers build their services from upstream repositories 
there is no concern for "stable" release schedule. They could use packages 
from "testing" or "unstable", especially those like Golang ones that almost 
always safe to install even to stable systems due to their statically linked 
nature and few run-time dependencies.

The problem is rather curious one. What would the Debian be without packages? 
Would there be anything left? When the whole project is largely about good 
packaging as a form of delivery of free software with added value in regards 
to integration, build-ability, consistency, respect to FHS and DFSG, 
continuous testing, etc., as a project we are projecting the idea that 
deploying and maintaining services installed from the package repository is 
good. Certainly sometimes it is much easier to deploy and upgrade software 
when it is installed from the official packages. But when service maintainers 
refuse to use packaged software for no good reason the message is not clear. 
Is package maintainer does not do a good enough job or is the whole concept 
is wrong? It is like we are saying, here, use the packages we have prepared 
for you but mind that they are not good enough for us (ourselves) to use...

In case of Gitlab I recognise that Salsa could not be maintained from the 
official packages. They are too fragile, often uninstallable even in 
"unstable" and depend on unofficial "fasttrack" repository. There are too 
many dependencies and things get broken far to often in too many places.
In theory Gitlab could be in a better shape with larger team, but in the 
current situation I see why Salsa operates from vendor container image and it 
is reasonable.

But case of Gitlab-Runner is different. The packaged version is mature 
enough. It is trivial to incorporate it into container image. I've been 
running it in production for 3.5 years ever since I've packaged it.
It appears to me that Salsa admins don't use packaged Gitlab-Runner simply 
because they don't want to, and I don't understand why.

I think ideally service maintainers should be package co-maintainers. But 
when there is a large burden to maintain either (the service and the 
package), I understand how people might focus just on one thing.
But again, if everything we do here is about providing packaged software, 
when it is ever the right thing not to use our own packages?
Certainly we don't trust upstream more than our fellow developers, right?

-- 
All the best,
 Dmitry Smirnov.

---

If liberty means anything at all, it means the right to tell people what
they do not want to hear.
-- George Orwell


signature.asc
Description: This is a digitally signed message part.

Re: Salsa CI news

[Paul Wise]

On Thu, Feb 6, 2020 at 12:34 AM Steffen Möller wrote:

> I think your dispute goes down to the question if Debian's community
> infrastructure should preferably using software packaged for Debian
> (which salsa is doing) with the binaries Debian offers (which salsa is
> not doing).

I personally would love to see this happen, but I have to acknowledge
that it is unlikely we will because .deb from the archive isn't the
most popular deployment method for debian.org services. For example:
DSA use puppet for deployment of configuration and scripts. Service
maintainers deploy their own code directly from git. Service
maintainers use local copies of software instead of packages. Service
maintainers fork software they use. Service maintainers vendor
dependencies in their git repositories. On debian.net there is
probably some use of containers built in various ways.

> B) Using our own packages ensures that there is no diversion between
> what Debian ships and what Debian uses, so it can be bootstrapped on an
> island (which is the link to the DFSG) as a whole, not only the software
> it distributes.

There is one attribute of how Debian does things that clashes with
being able to do this; service maintainers need to be able to update
code on a different schedule to Debian stable and even backports
time-frames. Once we have bikesheds this will probably become less of
an issue.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Salsa CI news

[Matthew Garrett]

On Wed, Feb 5, 2020 at 4:33 PM Dmitry Smirnov  wrote:
> Second, it that binary build, the way it is compiled upstream, would never be
> accepted by ftp-masters due to lack of some sources in Debian "main".
> That's what I called problem with DFSG compliance.

It's worth remembering that Debian infrastructure relied on qmail for
a long time, despite it not being under a DFSG compliant license at
all. We can argue that everything running in Debian infrastructure
/should/ reflect what we ship to users, but the reality is that there
are multiple reasons why it may not and the project as a whole hasn't
concluded that it should be a requirement to do so.

Re: Salsa CI news

[Ondřej Surý]

I think I need to add that personally I am very thankful for the work the Salsa 
and Salsa CI teams are doing. And the only reason I participated in this 
discussion is that I believe that we need to stand up for each other as fellow 
peers and colleagues.

Ondrej
--
Ondřej Surý 

> On 6 Feb 2020, at 00:42, Inaki Malerba  wrote:
> 
> El 5/2/20 a las 21:25, Dmitry Smirnov escribió:
>>> On Tuesday, 26 February 2019 1:19:35 AM AEDT Inaki Malerba wrote:
>>> [0] https://salsa.debian.org/salsa-ci-team/pipeline/blob/master/README.md
>> 
>> Thank you for providing this useful service.
>> 
>> My big concern though is that primary gitlab-runner 12.7.0 (HEAD)
>> on salsa-runner.debian.net f0fdd533 is not DFSG compliant.
>> 
>> Frankly I don't understand why such issue is tolerated on official 
>> infrastructure.
>> 
>> Please use properly packaged gitlab-(ci-multi-)runner package.
>> 
> 
> Hi Dmitry,
> 
> Thanks for sharing your concern. We, the Salsa CI Team, have no control
> over Salsa or the shared runners.
> 
> I'm sure there might be reasons why the setup is done in this way, but
> we're not able to explain those.
> 
> I'd cc'ed the Salsa Admins which might miss the email otherwise.
> 
> Abrazos.
> 
> -- 
> - ina
> 

Re: Salsa CI news

[Ondřej Surý]

From where I stand it seems to me that you actually don’t care about free 
software or DFSG or Debian and you only care about enforcing your worldview 
upon others. You need to stop, go read DFSG and come back only if you and come 
back with valid arguments how the DFSG is being violated. Or just stop and 
apologize.

Ondrej
--
Ondřej Surý 

> On 6 Feb 2020, at 01:33, Dmitry Smirnov  wrote:
> 
> On Thursday, 6 February 2020 10:22:24 AM AEDT Russ Allbery wrote:
>> I can't speak for Bernd, but I haven't seen any evidence in this thread
>> that the built binary is not DFSG-compliant.
> 
> So now you are going to nitpick on my language with all your eloquence? :(
> 
> The first problem is that packaged gitlab-runner (where all the issues are 
> addressed) is not used. I consider it to be a problem on its own.
> 
> Second, it that binary build, the way it is compiled upstream, would never be 
> accepted by ftp-masters due to lack of some sources in Debian "main".
> That's what I called problem with DFSG compliance.
> 
> On top of that there are minor things like sloppy upstream vendoring of many 
> packaged components. That is over 90 libraries that may or may not contain 
> some binary blobs, pre-generated files, or files licensed under non-DFSG 
> compliant terms. Do you really want me to dig there to find you "proof" or 
> did I say enough to demonstrate the problem?
> 
> User of upstream build (even self-compiled) can not be sure about DFSG 
> compliance due to extensive vendoring - a something that took months to 
> address in the package that was actually accepted into Debian.
> 
> -- 
> Cheers,
> Dmitry Smirnov.
> 
> ---
> 
> In theory, there is no difference between theory and practice. But, in
> practice, there is.
>-- Jan L. A. van de Snepscheut

Re: Salsa CI news

[Ondřej Surý]

And yet you *demand* in a very aggressive way that others dedicate their 
capacity on your misinterpretation of DFSG. Just stop.

Thanks,
--
Ondřej Surý 

> On 6 Feb 2020, at 00:27, Dmitry Smirnov  wrote:
> 
> I would have done so if I had enough capacity.

Re: Salsa CI news

[Ondřej Surý]

I think you should stop here and now. You are misinterpreting DFSG to make a 
point. And instead of asking how you can help you just throw accusations. In 
both you recent threads. We are all in this together and your style is not 
helpful just hurtful.

Ondrej
--
Ondřej Surý 

> On 6 Feb 2020, at 00:13, Dmitry Smirnov  wrote:
> 
> On Thursday, 6 February 2020 9:53:09 AM AEDT Dmitry Smirnov wrote:
>>> On Thursday, 6 February 2020 9:25:29 AM AEDT intrigeri wrote:
>>> I'd love if you would use wording less morally/emotionally loaded than
>>> "excuse" here: for me at least, "excuse" is bound to the thought
>>> framework of guilt, accusation, and absolute right vs. absolute wrong.
>>> Framing the discussion this way can easily lead folks to react in
>>> a defensive, non-constructive way.
>>> 
>>> Maybe, instead, you meant something like "what reason is there to do
>>> X?", or "why do you think this trade-off is the current best
>>> solution?" :)
>> 
>> Valid, thanks. Though you could have lectured us both on the tone we have
>> used as I was merely responding to rather aggressive reply.
> 
> On second thought, yes I would use "excuse" anyway precisely for its moral 
> implications and accusation of wrongdoing. In another community it would not 
> be obvious that DFSG compliance is a good thing. But here in Debian where we 
> all agree that DFSG is good, and compliance concerns should be default, 
> ideally. It should not be necessary to call for DFSG compliance. It should be 
> on abuser to explain that it was not possible to build a service in a fully 
> DFSG compliant manner only from components provided by Debian. I'm not saying 
> that DFSG compliance is optional (or that it doesn't matter) yet you are 
> bothered with _my_ tone. I'm much more troubled by attitude of not caring for 
> DFSG...
> 
> -- 
> Best wishes,
> Dmitry Smirnov.
> 
> ---
> 
> Human beings, who are almost unique in having the ability to learn from the
> experience of others, are also remarkable for their apparent disinclination
> to do so.
>-- Mahatma Gandhi

Re: Salsa CI news

[Russ Allbery]

Dmitry Smirnov  writes:
> On Thursday, 6 February 2020 10:22:24 AM AEDT Russ Allbery wrote:

>> I can't speak for Bernd, but I haven't seen any evidence in this thread
>> that the built binary is not DFSG-compliant.

> So now you are going to nitpick on my language with all your eloquence? :(

Accusing fellow project members of intentionally violating the DFSG is
serious.  If that isn't what you meant to do, and instead you only
intended to complain that the deployment wasn't to the quality
expectations of the archive, wasn't using packaged software, and that it
was inobvious how to find appropriate source, I think you chose your words
poorly in a way that goes substantially beyond nitpicking.

You also doubled down on accusing your fellow project members of
intentional wrong-doing:

On second thought, yes I would use "excuse" anyway precisely for its
moral implications and accusation of wrongdoing. In another community
it would not be obvious that DFSG compliance is a good thing. But here
in Debian where we all agree that DFSG is good, and compliance
concerns should be default, ideally. It should not be necessary to
call for DFSG compliance. It should be on abuser to explain that it
was not possible to build a service in a fully DFSG compliant manner
only from components provided by Debian.

This is a serious accusation of violation of the project principles to
which we've all agreed.  If that wasn't what you intended to do, I think
you should consider toning your language way down.

> Second, it that binary build, the way it is compiled upstream, would
> never be accepted by ftp-masters due to lack of some sources in Debian
> "main".  That's what I called problem with DFSG compliance.

Missing sources in main when those sources are reasonably believed to
covered under a DFSG-compatible license, just not uploaded to main, is not
what DFSG compliance normally means.  It is indeed a release-critical flaw
in packages uploaded to Debian main, but it's not the same thing as
running Debian services on non-free software, which is how I believe a
reasonable person would have interpreted your original message.

That said, thank you for clarifying, and I *do* appreciate you pointing
out lack of obviously available source for Debian project infrastructure,
since I think that's something we should be aware of and ideally fix.  I'm
just objecting to the moral accusation that you coupled with that bug
report.

-- 
Russ Allbery (r...@debian.org)  

Re: Salsa CI news

[Steffen Möller]

Hello,

I think your dispute goes down to the question if Debian's community
infrastructure should preferably using software packaged for Debian
(which salsa is doing) with the binaries Debian offers (which salsa is
not doing). I find this interesting. The two positions are

A) No idea why this should be of concern.

B) Using our own packages ensures that there is no diversion between
what Debian ships and what Debian uses, so it can be bootstrapped on an
island (which is the link to the DFSG) as a whole, not only the software
it distributes.

There is certainly more, like if B) was the case then the salsa
maintainers would find problems with the packages/updates of the same
and the Debian packages would be more likely be use by others when a big
installation like salsa uses them. And that would strengthen Debian as a
whole. However, this extra work /uncertainties may be something that
overloaded maintainers want to avoid.

I personally see the beauty of B. But if I cannot access the repository
because of some downtime -no good. So I am also a fan of A - it works.
The way to go may be to somehow convince the salsa maintainers that they
will save some work when they adopt the Debian packages. And that
whatever update they are doing is of no risk. No exact idea how to get
there. But the notion of interchangeable Docker images sounds very
reasonable ... and we work on exchanging them for singularity
(syslabs.io) images later.

Steffen

Re: Salsa CI news

[Dmitry Smirnov]

On Thursday, 6 February 2020 10:22:24 AM AEDT Russ Allbery wrote:
> I can't speak for Bernd, but I haven't seen any evidence in this thread
> that the built binary is not DFSG-compliant.

So now you are going to nitpick on my language with all your eloquence? :(

The first problem is that packaged gitlab-runner (where all the issues are 
addressed) is not used. I consider it to be a problem on its own.

Second, it that binary build, the way it is compiled upstream, would never be 
accepted by ftp-masters due to lack of some sources in Debian "main".
That's what I called problem with DFSG compliance.

On top of that there are minor things like sloppy upstream vendoring of many 
packaged components. That is over 90 libraries that may or may not contain 
some binary blobs, pre-generated files, or files licensed under non-DFSG 
compliant terms. Do you really want me to dig there to find you "proof" or 
did I say enough to demonstrate the problem?

User of upstream build (even self-compiled) can not be sure about DFSG 
compliance due to extensive vendoring - a something that took months to 
address in the package that was actually accepted into Debian.

-- 
Cheers,
 Dmitry Smirnov.

---

In theory, there is no difference between theory and practice. But, in
practice, there is.
-- Jan L. A. van de Snepscheut


signature.asc
Description: This is a digitally signed message part.

Re: Salsa CI news

[Inaki Malerba]

El 5/2/20 a las 21:25, Dmitry Smirnov escribió:
> On Tuesday, 26 February 2019 1:19:35 AM AEDT Inaki Malerba wrote:
>> [0] https://salsa.debian.org/salsa-ci-team/pipeline/blob/master/README.md
> 
> Thank you for providing this useful service.
> 
> My big concern though is that primary gitlab-runner 12.7.0 (HEAD)
> on salsa-runner.debian.net f0fdd533 is not DFSG compliant.
> 
> Frankly I don't understand why such issue is tolerated on official 
> infrastructure.
> 
> Please use properly packaged gitlab-(ci-multi-)runner package.
> 

Hi Dmitry,

Thanks for sharing your concern. We, the Salsa CI Team, have no control
over Salsa or the shared runners.

I'm sure there might be reasons why the setup is done in this way, but
we're not able to explain those.

I'd cc'ed the Salsa Admins which might miss the email otherwise.

Abrazos.

-- 
- ina



signature.asc
Description: OpenPGP digital signature

Re: Salsa CI news

[Bernd Zeimetz]

On 2/6/20 12:13 AM, Dmitry Smirnov wrote:
> On Thursday, 6 February 2020 9:52:47 AM AEDT Bernd Zeimetz wrote:
> 
>> Really don't care.
> 
> I see that... :(

See, I prefer to spend my time on doing open source software. I use
tools I can use and that are provided by others, even if the build was
done by other people on a different platform. Its still open source
software. The world would be much better if people would not discuss
about what is free or not, but just create free software. If there is
more free software, there is less need to use proprietary software. I'd
rather see that schools everywhere use linux instead fighting for a dfsg
free gitlab runner image.

>> You are free to setup and run your own runner.
> 
> Just because you did not setup yours properly?

Its not my runner, I'm just happy with what salsa provides, and I'm
using my own one gitlab instance and runners for projects like ceph
where salsa is just undersized for.

The salsa admins are overworked and busy, so I'm sure you have the
biggest chance if you provide something ready to run in k8s, replacing
the existing image should not be too hard if there is a working, tested
and maintained one. Just make sure the latest version is available asap
after a release.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Salsa CI news

[Russ Allbery]

Dmitry Smirnov  writes:

> Sources are somewhere, true. But build (binary) is not DFSG-compliant.

> I feel like you are making your point by pretending not to understand...
> Why all this denial?

I can't speak for Bernd, but I haven't seen any evidence in this thread
that the built binary is not DFSG-compliant.  You clearly believe this,
but you're not explaining why except for reasons that seem clearly
incorrect.

For example, Alpine Linux, assuming one does not enable the non-free
repository, and thus Docker containers created using it appear to be
DFSG-compliant.  They only claim OSI compliance, which is not precisely
the same thing, but there would need to be some indication that the Alpine
components used are in the very narrow set of OSI-approved but not
DFSG-compliant licenses.

Could you be (much) more specific about exactly what violations of the
DFSG you believe exist, rather than assuming everyone agrees with you and
then berating people for ignoring the DFSG?  It seems far more likely
that, rather than ignoring the DFSG, people simply don't believe you're
correct in asserting there is a problem.

-- 
Russ Allbery (r...@debian.org)  

Re: Salsa CI news

[Richard Laager]

On 2/5/20 5:05 PM, Dmitry Smirnov wrote:
> It should be on abuser

Saying "abuser" is inflammatory, especially as no abuse has been proven.
Please stop.

> to explain that it was not possible to build a
> service in a fully  DFSG compliant manner

Why is the current solution not DFSG compliant?

> only from components provided by Debian.

While I agree it would be better in Debian to use a Debian image instead
of an Alpine one and to use Debian packages, that is separate from DFSG
compliance and a much lower severity issue.

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Re: Salsa CI news

[Dmitry Smirnov]

On Thursday, 6 February 2020 9:52:47 AM AEDT Bernd Zeimetz wrote:

> Really don't care.

I see that... :(


> You are free to setup and run your own runner.

Just because you did not setup yours properly?

I do maintain my own runner but it is not for everybody due to capacity 
constrains.

But let's not flip the discussion away from the problem with your runner.


> Its even possible to share them for everybody.

I would have done so if I had enough capacity.


> If you do, I'd suggest you add some appropriate tags so people can force
> their builds to run on a runner built from Debian source.

I'll consider that if/when I'll be able to scale-up the runner. Presently my 
VM struggles to build my own packages.

See, now I'm answering to you for doing nothing wrong... :(

I wish you could take the concern seriously.


> (there is not irony here, if you think that would improve Debian, just
> do it)

I'm trying to improve Debian by communicating a problem that you refuse to 
take seriously...

-- 
All the best,
 Dmitry Smirnov.

---

The more false we destroy the more room there will be for the true.
 -- Robert G. Ingersoll, 1902


signature.asc
Description: This is a digitally signed message part.

Re: Salsa CI news

[Dmitry Smirnov]

On Thursday, 6 February 2020 9:53:09 AM AEDT Dmitry Smirnov wrote:
> On Thursday, 6 February 2020 9:25:29 AM AEDT intrigeri wrote:
> > I'd love if you would use wording less morally/emotionally loaded than
> > "excuse" here: for me at least, "excuse" is bound to the thought
> > framework of guilt, accusation, and absolute right vs. absolute wrong.
> > Framing the discussion this way can easily lead folks to react in
> > a defensive, non-constructive way.
> > 
> > Maybe, instead, you meant something like "what reason is there to do
> > X?", or "why do you think this trade-off is the current best
> > solution?" :)
> 
> Valid, thanks. Though you could have lectured us both on the tone we have
> used as I was merely responding to rather aggressive reply.

On second thought, yes I would use "excuse" anyway precisely for its moral 
implications and accusation of wrongdoing. In another community it would not 
be obvious that DFSG compliance is a good thing. But here in Debian where we 
all agree that DFSG is good, and compliance concerns should be default, 
ideally. It should not be necessary to call for DFSG compliance. It should be 
on abuser to explain that it was not possible to build a service in a fully 
DFSG compliant manner only from components provided by Debian. I'm not saying 
that DFSG compliance is optional (or that it doesn't matter) yet you are 
bothered with _my_ tone. I'm much more troubled by attitude of not caring for 
DFSG...

-- 
Best wishes,
 Dmitry Smirnov.

---

Human beings, who are almost unique in having the ability to learn from the
experience of others, are also remarkable for their apparent disinclination
to do so.
-- Mahatma Gandhi


signature.asc
Description: This is a digitally signed message part.

Re: Salsa CI news

[Bernd Zeimetz]

On 2/5/20 11:52 PM, Bernd Zeimetz wrote:

> You are free to setup and run your own runner.
> Its even possible to share them for everybody.
> If you do, I'd suggest you add some appropriate tags so people can force
> their builds to run on a runner built from Debian source.
> (there is not irony here, if you think that would improve Debian, just
> do it)

If you want salsa to use a packaged gitlab runner, the first start would
be to create a docker image on salsa with it and maintain it. Then
people can use it easily.
But please note that you image will still run on proprietary hardware
and closed source software somewhere in gke (I think..).




-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Salsa CI news

[Dmitry Smirnov]

On Thursday, 6 February 2020 9:25:29 AM AEDT intrigeri wrote:
> I'd love if you would use wording less morally/emotionally loaded than
> "excuse" here: for me at least, "excuse" is bound to the thought
> framework of guilt, accusation, and absolute right vs. absolute wrong.
> Framing the discussion this way can easily lead folks to react in
> a defensive, non-constructive way.
> 
> Maybe, instead, you meant something like "what reason is there to do
> X?", or "why do you think this trade-off is the current best
> solution?" :)

Valid, thanks. Though you could have lectured us both on the tone we have 
used as I was merely responding to rather aggressive reply.

-- 
Best wishes,
 Dmitry Smirnov.

---

Truth never damages a cause that is just.
-- Mahatma Gandhi


signature.asc
Description: This is a digitally signed message part.

Re: Salsa CI news

[Bernd Zeimetz]

On 2/5/20 11:42 PM, Dmitry Smirnov wrote:

> Sources are somewhere, true. But build (binary) is not DFSG-compliant.

Why? Because it was not built in Debian?

> Don't you think it would be _better_ to use (only) components from "main"?
> Certainly there will be more integrity if you can do that.

For something like producing build logs? Really don't care.

>> Where is the problem?
> 
> Lack of self-reliance? Using non-trusted vendor binaries (and/or container 
> image)? Using sloppy vendor build over proper one that we have in Debian? 
> Pick any.


You are free to setup and run your own runner.
Its even possible to share them for everybody.
If you do, I'd suggest you add some appropriate tags so people can force
their builds to run on a runner built from Debian source.
(there is not irony here, if you think that would improve Debian, just
do it)

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Salsa CI news

[Dmitry Smirnov]

On Thursday, 6 February 2020 9:11:07 AM AEDT Bernd Zeimetz wrote:
> They are not shipped in Debian, but they are free software,
> binaries with sources being available, as far as I can see all under a
> dfsg free license.

Sources are somewhere, true. But build (binary) is not DFSG-compliant.

I feel like you are making your point by pretending not to understand...
Why all this denial?

Saying "that's how Golang works" is enough to ignore DFSG compliance?

Don't you think it would be _better_ to use (only) components from "main"?
Certainly there will be more integrity if you can do that.


> Where is the problem?

Lack of self-reliance? Using non-trusted vendor binaries (and/or container 
image)? Using sloppy vendor build over proper one that we have in Debian? 
Pick any.

-- 
Cheers,
 Dmitry Smirnov.

---

Orthodoxy is the ability to say two and two make five when faith
requires it.
-- George Orwell, Nineteen Eighty-Four (1949).



signature.asc
Description: This is a digitally signed message part.

Re: Salsa CI news

[intrigeri]

Hi,

Dmitry Smirnov (2020-02-06):
> Now when we have a proper package for a while what excuse do you
> have to continue to use vendor binaries that could not be accepted
> to Debian?

I'd love if you would use wording less morally/emotionally loaded than
"excuse" here: for me at least, "excuse" is bound to the thought
framework of guilt, accusation, and absolute right vs. absolute wrong.
Framing the discussion this way can easily lead folks to react in
a defensive, non-constructive way.

Maybe, instead, you meant something like "what reason is there to do
X?", or "why do you think this trade-off is the current best
solution?" :)

Cheers!

Re: Salsa CI news

[Bernd Zeimetz]

On 2/5/20 10:33 PM, Dmitry Smirnov wrote:
> Upstream binaries are not DFSG compliant.

Why?

> Not only they use shitload of 
> vendored libraries

That is how go works. The exact version is available, the source code also.
The way how the docker image is being built is actually in the sources,
follow

https://gitlab.com/gitlab-org/gitlab-runner/-/blob/master/.gitlab-ci.yml

If you replace the used base image by debian:stable, and fix the way the
needed packages are installed, you could run this on salsa and have
Debian images out of it.

> but also bundle pre-built source-less Alpine-based helper 
> image 

Alpine linux, including the source to build their images is here:
https://github.com/alpinelinux
Afaik there is nothing in alpine linux that is non-free.

> fetched on build-time and incorporated into executable.

That is how go works.


> Instead of of telling me to go some place else consider that gitlab-runner 
> was rather difficult to introduce as an official package. Now when we have a 
> proper package for a while what excuse do you have to continue to use vendor 
> binaries that could not be accepted to Debian?

Still can't find a reason why the official and supported images are not
dfsg-free. They are not shipped in Debian, but they are free software,
binaries with sources being available, as far as I can see all under a
dfsg free license. Where is the problem?



Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Salsa CI news

[Dmitry Smirnov]

On Thursday, 6 February 2020 8:10:17 AM AEDT Bernd Zeimetz wrote:
> You are free not to use salsa or not to use the gitlab runners.
> You are also free to rewrite the gitlab runner in a free version, if I
> remember right the api is published, so this should not be hard.

What warrants such a hostile reply?? Would you please care to read and 
understand the issue? There is no need to rewrite gitlab-runner, just to 
avoid vendor binaries.

Upstream binaries are not DFSG compliant. Not only they use shitload of 
vendored libraries but also bundle pre-built source-less Alpine-based helper 
image fetched on build-time and incorporated into executable.


> On the first look all used and vendored git modules are also under a
> free license, so you might want to provide some more details if you want
> people to take this serious.

Instead of of telling me to go some place else consider that gitlab-runner 
was rather difficult to introduce as an official package. Now when we have a 
proper package for a while what excuse do you have to continue to use vendor 
binaries that could not be accepted to Debian?

-- 
Best wishes,
 Dmitry Smirnov.

---

Truth — Something somehow discreditable to someone.
-- H. L. Mencken, 1949


signature.asc
Description: This is a digitally signed message part.

Re: Salsa CI news

[Bernd Zeimetz]

On 2/5/20 9:25 PM, Dmitry Smirnov wrote:
> On Tuesday, 26 February 2019 1:19:35 AM AEDT Inaki Malerba wrote:
>> [0] https://salsa.debian.org/salsa-ci-team/pipeline/blob/master/README.md
> 
> Thank you for providing this useful service.
> 
> My big concern though is that primary gitlab-runner 12.7.0 (HEAD)
> on salsa-runner.debian.net f0fdd533 is not DFSG compliant.
> 
> Frankly I don't understand why such issue is tolerated on official 
> infrastructure.
> 
> Please use properly packaged gitlab-(ci-multi-)runner package.

You are free not to use salsa or not to use the gitlab runners.
You are also free to rewrite the gitlab runner in a free version, if I
remember right the api is published, so this should not be hard.

Also the gitlab runner is licensed under the MIT license, so if you did
find something that is not free enough for your needs, take the source
and replace what you do not like. Please send it as patch to gitlab then.
https://gitlab.com/gitlab-org/gitlab-runner/

On the first look all used and vendored git modules are also under a
free license, so you might want to provide some more details if you want
people to take this serious.



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Salsa CI news

[Dmitry Smirnov]

On Tuesday, 26 February 2019 1:19:35 AM AEDT Inaki Malerba wrote:
> [0] https://salsa.debian.org/salsa-ci-team/pipeline/blob/master/README.md

Thank you for providing this useful service.

My big concern though is that primary gitlab-runner 12.7.0 (HEAD)
on salsa-runner.debian.net f0fdd533 is not DFSG compliant.

Frankly I don't understand why such issue is tolerated on official 
infrastructure.

Please use properly packaged gitlab-(ci-multi-)runner package.

-- 
Cheers,
 Dmitry Smirnov.

---

One of the best ways to achieve justice is to expose injustice.
-- Julian Assange


signature.asc
Description: This is a digitally signed message part.

Re: Salsa CI news

[Inaki Malerba]

On 26/2/19 14:42, Domenico Andreoli wrote:
> If I got it right, according to Gitlab docs [0], it's possible to set an 
> arbitrary name for the App you want to configure.

My bad ! Now it should be ok :)

Thanks!

-- 
- ina




signature.asc
Description: OpenPGP digital signature

Re: Salsa CI news

[Domenico Andreoli]

On February 26, 2019 5:32:57 PM UTC, Inaki Malerba  wrote:
>Hi Domenico!
>
>On 26/2/19 14:17, Domenico Andreoli wrote:
>>> We also introduced a way to monitor the pipeline's usage.
>>> prittiau.debian.net is a simple influxdb + grafana which shows some
>>> stats about the projects using the Salsa CI pipeline. You're welcome
>to
>>> log in with your salsa account.
>> I'm loggiagn in right now, Salsa asks for the following
>authorization:
>>
>>   An application called Gitlab is requesting access to your GitLab
>>   account. This application was created by Iñaki Malerba. Please note
>>   that this application is not provided by GitLab and you should
>verify
>>   its authenticity before allowing access.
>>
>> I find slightly confusing that "An application called Gitlab is
>> requesting access to your GitLab account". Maybe you could choose a
>> different name?
>
>That's because Grafana uses Gitlab Oauth2 authentication[0]. I only
>created a Oauth application at Salsa and everything else is on Grafana.

If I got it right, according to Gitlab docs [0], it's possible to set an 
arbitrary name for the App you want to configure.

>> Thanks for all the good work! :)
>
>My pleasure!

thanks,
Domenico

[0] https://docs.gitlab.com/ce/integration/oauth_provider.html

Re: Salsa CI news

[Inaki Malerba]

Hi Domenico!

On 26/2/19 14:17, Domenico Andreoli wrote:
>> We also introduced a way to monitor the pipeline's usage.
>> prittiau.debian.net is a simple influxdb + grafana which shows some
>> stats about the projects using the Salsa CI pipeline. You're welcome to
>> log in with your salsa account.
> I'm loggiagn in right now, Salsa asks for the following authorization:
>
>   An application called Gitlab is requesting access to your GitLab
>   account. This application was created by Iñaki Malerba. Please note
>   that this application is not provided by GitLab and you should verify
>   its authenticity before allowing access.
>
> I find slightly confusing that "An application called Gitlab is
> requesting access to your GitLab account". Maybe you could choose a
> different name?

That's because Grafana uses Gitlab Oauth2 authentication[0]. I only
created a Oauth application at Salsa and everything else is on Grafana.

>> If you have any question, you can find us on #salsaci at OFTC.
> Thanks for all the good work! :)

My pleasure!


0_ http://docs.grafana.org/auth/gitlab/

-- 
- ina




signature.asc
Description: OpenPGP digital signature

Re: Salsa CI news

[Domenico Andreoli]

On Mon, Feb 25, 2019 at 11:19:35AM -0300, Inaki Malerba wrote:
> Hi everyone !

Hi Inaki,

[...]

> We also introduced a way to monitor the pipeline's usage.
> prittiau.debian.net is a simple influxdb + grafana which shows some
> stats about the projects using the Salsa CI pipeline. You're welcome to
> log in with your salsa account.

I'm loggiagn in right now, Salsa asks for the following authorization:

  An application called Gitlab is requesting access to your GitLab
  account. This application was created by Iñaki Malerba. Please note
  that this application is not provided by GitLab and you should verify
  its authenticity before allowing access.

I find slightly confusing that "An application called Gitlab is
requesting access to your GitLab account". Maybe you could choose a
different name?

> If you have any question, you can find us on #salsaci at OFTC.

Thanks for all the good work! :)

Regards,
Domenico

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13


signature.asc
Description: PGP signature

Re: Salsa CI news

[Paul Wise]

On Mon, Feb 25, 2019 at 11:22 PM Roberto C. Sánchez wrote:
>
> On Mon, Feb 25, 2019 at 02:44:22PM +, Jonathan Dowland wrote:
> > On Mon, Feb 25, 2019 at 11:19:35AM -0300, Inaki Malerba wrote:
> > > On behalf of the Salsa CI Team I'm pleased to announce some of the
> > > changes we've been working on this weekend. We don't have an official
> > > mailing list, so please excuse us if this is not the place for this
> > > kind of announcements.
> >
> > Thanks for sharing! Personally I think you could consider using
> > debian-devel-annou...@lists.debian.org (but others may disagree)
> >
> At the very least make sure the publicity team knows so it makes it into
> the next Debian Project News issue.

Misc Dev News seems more appropriate here:

https://wiki.debian.org/DeveloperNews

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Salsa CI news

[Roberto C . Sánchez]

On Mon, Feb 25, 2019 at 02:44:22PM +, Jonathan Dowland wrote:
> On Mon, Feb 25, 2019 at 11:19:35AM -0300, Inaki Malerba wrote:
> > On behalf of the Salsa CI Team I'm pleased to announce some of the
> > changes we've been working on this weekend. We don't have an official
> > mailing list, so please excuse us if this is not the place for this
> > kind of announcements.
> 
> Thanks for sharing! Personally I think you could consider using
> debian-devel-annou...@lists.debian.org (but others may disagree)
> 
At the very least make sure the publicity team knows so it makes it into
the next Debian Project News issue.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Salsa CI news

[Jonathan Dowland]

On Mon, Feb 25, 2019 at 11:19:35AM -0300, Inaki Malerba wrote:

On behalf of the Salsa CI Team I'm pleased to announce some of the
changes we've been working on this weekend. We don't have an official
mailing list, so please excuse us if this is not the place for this
kind of announcements.


Thanks for sharing! Personally I think you could consider using
debian-devel-annou...@lists.debian.org (but others may disagree)