Bug#906640: ITP: r-cran-ps -- GNU R list, query, manipulate system processes
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-ps Version : 1.1.0 Upstream Author : Jay Loden, Dave Daeschler, Giampaolo Rodola, Gábor Csárdi, RStudio * URL : https://cran.r-project.org/package=ps * License : BSD-3-clause Programming Lang: GNU R Description : GNU R list, query, manipulate system processes This GNU R package provides functions to list, query and manipulate all system processes. This is an implementation of the Linux command ps for R. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-ps This package is needed to upgrade r-cran-processx to its latest upstream version.
Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)
* Bastian Blank: " Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)" (Sat, 18 Aug 2018 08:26:11 +0200): Erroneously sent as PM. > On Sat, Aug 18, 2018 at 02:16:33AM +0200, Mathias Behrle wrote: > > > Please explain. Google Cloud storage is just a large disk. The > > > analytics stuff can access the data if it got the authorization to > > > access it. > > I have quite some difficulties to believe that Google respects privacy > > settings: > > https://apnews.com/828aefab64d4411bac257a07c1af0ecb/AP-Exclusive:-Google-tracks-your-movements,-like-it-or-not > > > > I have no idea what you are trying to tell me. This article not even > once talks about the storage. You spoke about authorization to Google and I gave an example where Google obviously doesn't care about authorization. Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)
On 08/18/2018 08:26 AM, Bastian Blank wrote: > On Sat, Aug 18, 2018 at 02:16:33AM +0200, Mathias Behrle wrote: >>> Please explain. Google Cloud storage is just a large disk. The >>> analytics stuff can access the data if it got the authorization to >>> access it. >> I have quite some difficulties to believe that Google respects privacy >> settings: >> https://apnews.com/828aefab64d4411bac257a07c1af0ecb/AP-Exclusive:-Google-tracks-your-movements,-like-it-or-not > > This article not even once talks about the storage. Let's blindly trust then...
Bug#906621: ITP: ccdiff -- Colored Character Diff
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: ccdiff Version : 0.20 Upstream Author : H.Merijn Brand * URL : https://metacpan.org/release/App-ccdiff * License : Artistic or GPL-1+ Programming Lang: perl Description : Colored Character Diff ccdiff is a colored diff that also colors inside changed lines. All command-line tools that show the difference between two files fall short in showing minor changes visuably useful. ccdiff tries to give the look and feel of `diff --color` or `colordiff`, but extending the display of colored output from colored deleted and added lines to colors for deleted and addedd characters within the changed lines. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Tracy Chapman: Smoke And Ashes signature.asc Description: Digital Signature
Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)
On 08/18/2018 01:11 PM, Bastian Blank wrote: >>Also, using a free >> implementation avoids vendor lock-in, > > Could you please be more specific on what vendor lock-in you mean? > > If I build an application using Kubernetes and Helm, I'm using only free > components, but I'm still locked-in, as there is only one > implementation. If I do the same using the OpenStack API, I'm locked-in > as there exist only one implementation of this API. First, there's dozens of OpenStack public cloud out there, so you're not locked-in with a single operator. Then there's not a single contributor to the OpenStack source code, the contributors are quite diverse. To the contrary, if you're using a proprietary cloud like AWS, you have no choice but to continue with them. > In our case all the components can utilize multiple backends, so we can > freely choose which one to use. Including completely free alternatives > like ceph with radosgw or minio. I'd like to understand better what the need and usage is. Could you please expand? Do you need to store blobs, like with Swift? Maybe swift is more adapted to the use case, if we only need to store blobs? Swift is also a way more easy to deploy and maintain than a Ceph cluster, which requires careful monitoring of daemons if you don't want it to fall apart. >> and provides proven (and tested on >> a CI, for the case of OpenStack) interoperability. > > I'm pretty sure all the Cloud vendors do heavy tests on all sorts. To > be exact, I know they do. They just don't show you all of it. So this > is no unique selling point for OpenStack. I was talking specifically about interoperability tests from one OpenStack version to the next. OpenStack clients are designed to work with *any* version of OpenStack, and they are supposed to work even some very old deployments. And that's the thing that is tested in the CI. I may be wrong, but so far, I haven't head that any of the big 4 non-free clouds having such thing for their client API, and even if they did, it would make little sense, as they don't have the interoperability problem to take care of (they just need to be compatible with themselves). Other free IaaS implementation may have the feature also, but free-software public cloud providers are almost always using OpenStack anyway, so interoperability, really, is a unique selling point here for OpenStack. >> And there's what Jeremy replied to you. We shall not endorse non-free. > > No, he just said we should prefer to use free ones. > > Endorse is something different, please read yourself > https://www.merriam-webster.com/dictionary/endorse or > http://www.learnersdictionary.com/definition/endorse Well, it's a question of view. To me, having Salsa to host some of its data on Google is a kind of tacit endorsement. Even worse, it gives the message that, from the viewpoint of the whole Debian community, it's ok to host there. Clearly, I'm not the only one bothered in this way. >> Though what I agree very much about, is that we'd get more freedom if we >> were self-hosting fully. One always do. > > You primarily got more work to do. Sure, of course.
Re: Bug#906613: ITP: python-sphinxcontrib.apidoc -- Sphinx extension for running 'sphinx-apidoc' on each build
On 08/18/2018 11:23 PM, Thomas Goirand wrote: > Package: wnpp > Severity: wishlist > Owner: Thomas Goirand > > * Package name: python-sphinxcontrib.apidoc > Version : 0.2.1 > Upstream Author : Zane Bitter > * URL : https://github.com/sphinx-contrib/apidoc > * License : Apache-2.0 This is in fact BSD-2, not Apache-2.0 license.
Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)
On 08/18/2018 07:42 AM, Alexander Wirt wrote: >> I also don't understand why we're not attempting to build a Ceph cluster >> at UBC. Why not? > go ahead. if it works well we can switch to it. > > Alex Ok, I'm getting in touch with the DSA team to see how it can be done. Let's see first if we have hardware, and then how I can help for the setup and maintenance. Cheers, Thomas Goirand (zigo)
Bug#906613: ITP: python-sphinxcontrib.apidoc -- Sphinx extension for running 'sphinx-apidoc' on each build
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-sphinxcontrib.apidoc Version : 0.2.1 Upstream Author : Zane Bitter * URL : https://github.com/sphinx-contrib/apidoc * License : Apache-2.0 Programming Lang: Python Description : Sphinx extension for running 'sphinx-apidoc' on each build sphinx-apidoc is a tool for automatic generation of Sphinx sources that, using the autodoc sphinx_autodoc extension, documents a whole package in the style of other automatic API documentation tools. sphinx-apidoc does not actually build documentation - rather it simply generates it. As a result, it must be run before sphinx-build. Note: This is a new dependency for OpenStack.
Bug#906590: ITP: pass-otp -- A pass extension for managing one-time-password (OTP) tokens
Package: wnpp Severity: wishlist Owner: gustavo panizzo * Package name: pass-otp Version : 1.1.1 Upstream Author : Tad Fisher * URL : https://github.com/tadfisher/pass-otp/releases * License : GPL-3.0 Programming Lang: Bash Description : A pass extension for managing one-time-password (OTP) tokens lightweight directory-based password manager Stores, retrieves, generates, and synchronizes passwords securely using gpg, pwgen, and git. this extension provides support for otp tokens
Re: Notification of merge requests on Salsa
On Sat, 18 Aug 2018, Rene Engelhard wrote: > Hi, > > On Fri, Aug 17, 2018 at 11:13:11PM -0400, Jacob Adams wrote: > > I’m sure I’m not the only one to have missed a merge request for a while > > thanks to the lack of notifications, but also we don’t want DDs inboxes > > flooded with every merge request in the Debian group. > > > > My concern is that newcomers will have their merge requests ignored when > > maintainers are not emailed. I see no workable solution as yet, so I’ll > > have to look more into this and come back to this thread when I find one. > > One workaround is > > $ reportbug > Severity: whatever > Tags: patch > > (and mention the PR) > > Did that in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904457 > for > https://salsa.debian.org/installer-team/tasksel/merge_requests/2 > (where I thought this happened. no idea whether installer-team has MR > notifications on or not.) As said: a team can't enforce that. Its a user setting. alex
Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)
Hi Thomas On Fri, Aug 17, 2018 at 11:12:01PM +0200, Thomas Goirand wrote: > Wouter, I very much do not agree with your argumentation. Please read > this video: > https://meetings-archive.debian.net/pub/debian-meetings/2018/DebConf18/2018-07-30/server-freedom-why-choosing-the-cloud-op.webm Do you have some abstract for this? I watched it and still don't know what you want to say here. >Also, using a free > implementation avoids vendor lock-in, Could you please be more specific on what vendor lock-in you mean? If I build an application using Kubernetes and Helm, I'm using only free components, but I'm still locked-in, as there is only one implementation. If I do the same using the OpenStack API, I'm locked-in as there exist only one implementation of this API. In our case all the components can utilize multiple backends, so we can freely choose which one to use. Including completely free alternatives like ceph with radosgw or minio. > and provides proven (and tested on > a CI, for the case of OpenStack) interoperability. I'm pretty sure all the Cloud vendors do heavy tests on all sorts. To be exact, I know they do. They just don't show you all of it. So this is no unique selling point for OpenStack. > And there's what Jeremy replied to you. We shall not endorse non-free. No, he just said we should prefer to use free ones. Endorse is something different, please read yourself https://www.merriam-webster.com/dictionary/endorse or http://www.learnersdictionary.com/definition/endorse > Though what I agree very much about, is that we'd get more freedom if we > were self-hosting fully. One always do. You primarily got more work to do. Bastian -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0
Re: Notification of merge requests on Salsa
Hi, On Fri, Aug 17, 2018 at 11:13:11PM -0400, Jacob Adams wrote: > I’m sure I’m not the only one to have missed a merge request for a while > thanks to the lack of notifications, but also we don’t want DDs inboxes > flooded with every merge request in the Debian group. > > My concern is that newcomers will have their merge requests ignored when > maintainers are not emailed. I see no workable solution as yet, so I’ll have > to look more into this and come back to this thread when I find one. One workaround is $ reportbug Severity: whatever Tags: patch (and mention the PR) Did that in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904457 for https://salsa.debian.org/installer-team/tasksel/merge_requests/2 (where I thought this happened. no idea whether installer-team has MR notifications on or not.) Regards, Rene
Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)
On Fri, Aug 17, 2018 at 11:12:01PM +0200, Thomas Goirand wrote: > On 08/17/2018 04:11 PM, Wouter Verhelst wrote: > > But if we're going to > > be using an external cloud provider for such things, then it doesn't > > matter whether that external cloud provider runs a free software cloud > > implementation or a proprietary one, since we wouldn't have any of the > > benefits of the free software implementation anyway. In that background, > > it makes much more sense to use free software which can talk to multiple > > cloud storage implementations; that gives us the ability to move from > > one cloud provider to another by simply copying some data followed by > > the flick of a switch (or "just" that flick, if the free software in > > question copies the data for you). > > > > It is true that the whole "cloud" thing does have some impact on free > > software, and it is indeed also true that this is something that should > > be considered when deciding on a strategy; however, it is *not* correct > > to assume that a cloud provider which uses free software is in any way > > less of a problem in that context than a cloud provider which does not. > > Both are cases of you relying on a third party for part of the service > > which you provide, and so there is no real difference. > > Wouter, I very much do not agree with your argumentation. Please read > this video: You mean watch, I take it? ;-) > https://meetings-archive.debian.net/pub/debian-meetings/2018/DebConf18/2018-07-30/server-freedom-why-choosing-the-cloud-op.webm > > Having the underlying infrastructure to fully run free software is super > important, for many reasons. For example, because you can completely > reproduce it on your own hardware if you feel like it's the correct > thing to do, and then migrate your data to it. Also, using a free > implementation avoids vendor lock-in, and provides proven (and tested on > a CI, for the case of OpenStack) interoperability. That does make sense. However, if the free software on top of whatever cloud infrastructure we choose to use already supports multiple cloud providers (as is the case here), then you already do avoid that same vendor lock-in. It would be totally different if we were talking about something that can only be done by Google Compute Engine; say, if the salsa administrators wrote the necessary code themselves and did not even consider looking at a free implementation. Were that the case, I would agree with you. But that's not what this is about. > And there's what Jeremy replied to you. We shall not endorse non-free. > > I've been fighting for software freedom on the servers for nearly all of > my professional career, and reading what you wrote makes me really sad. > IMO you haven't understood what the problem is. I do; I just don't agree that, *in this specific instance*, it applies. > Though what I agree very much about, is that we'd get more freedom if we > were self-hosting fully. One always do. Exactly. We should encourage that when we can; but we should not fault the salsa administrators for deciding they don't have the time for that, and for choosing a third party cloud infrastructure, *for storage only*. When the cloud provider is used for only a minimal part of the problem space (as is the case here), and when the software in use allows for easy switching to another cloud provider (as is the case here), then the advantages of choosing a cloud provider that uses free software to provide the required service become very slim indeed. What use is free software when you can't exercise the rights anyway, as is the case with a third-party installation of free software cloud infrastructure? One could say that we might want to do so anyway, for political reasons, and I would definitely agree with you. But that ship has sailed when we chose gitlab over the really free software alternatives that also exist. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
