Bug#826799: ITP: libplack-handler-anyevent-fcgi-perl -- Asynchronous FCGI handler for PSGI using AnyEvent::FCGI
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: libplack-handler-anyevent-fcgi-perl Version : 0.01 Upstream Author : Tatsuhiko Miyagawa * URL : https://metacpan.org/release/Plack-Handler-AnyEvent-FCGI * License : Artistic or GPL-1+ Programming Lang: Perl Description : Asynchronous FCGI handler for PSGI using AnyEvent::FCGI Plack::Handler::AnyEvent::FCGI is a PSGI adapter for AnyEvent::FCGI allowing AnyEvent based non-blocking applications running behind a web server using FastCGI as a protocol. This package will be maintained uder umbrella of Debian Perl Group.
Bug#826798: ITP: libanyevent-fcgi-perl -- Perl non-blocking FastCGI server
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: libanyevent-fcgi-perl Version : 0.04 Upstream Author : Vitaly Kramskikh, * URL : https://metacpan.org/release/AnyEvent-FCGI * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl non-blocking FastCGI server AnyEvent offers module authors the ability to do event programming using different event implementation. AnyEvent::FCGI implements non-blocking FastCGI server based on AnyEvent for event based applications. Package wil be maintained uner umbrella of Debian Perl Group.
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, Jun 08, 2016 at 10:41:33PM +0100, Ben Hutchings wrote: > I don't see what's so unreasonable about that. They're asking you to > provide the same licence for your contributions, as the licence for the > existing Gitlab software. Every FOSS project expects that, even if > they don't make such a formal statement of it. If all they want is to have contributions use the same license as the code they provide, why is that license not enough? Why is a separate contributor license agreement needed? -- Schrödinger's backup hypothesis: the condition of any backup is undefined until a restore is attempted. -- andrewsh signature.asc Description: PGP signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On 08/06/16, 10:41pm, Ben Hutchings wrote: > On Wed, 2016-06-08 at 19:40 +0200, Alexander Wirt wrote: > > On Wed, 08 Jun 2016, Jonathan Dowland wrote: > > > > > On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: > > > > I am also not very keen on using a system with a "open core / > > > > enterprise" > > > > model. For such a crucial service I would really prefer a real open > > > > source > > > > system. But maybe I am alone with that oppinion. > > > > > > You are not alone, but please do not call Gitlab CE not "real open > > > source". > > I do for every software which forces me to sign things like: > > https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/legal/individual_contributor_license_agreement.md > [...] > > I don't see what's so unreasonable about that. They're asking you to > provide the same licence for your contributions, as the licence for the > existing Gitlab software. Every FOSS project expects that, even if > they don't make such a formal statement of it. > > Ben. Nodejs requires that as well. Nothing wrong with it. And in that case, calling node.js not real open source, would be quite a mistake. -- ⨳ PGP 0x13EC43EEB9AC8C43 ⨳ https://ghostbar.co
Pagure and Gitolite for project+code hosting (was: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project))
Barry Warsaw writes: > Another possible option is Pagure > https://pagure.io/ Wow, that's an attractive option. Thanks! > Written in Python and developed by Fedora. Apropos the discussions in this thread: Pagora uses Gitolite https://docs.pagure.org/pagure/overview.html> as its component for managing access to repositories. -- \ “[Entrenched media corporations will] maintain the status quo, | `\ or die trying. Either is better than actually WORKING for a | _o__) living.” —ringsnake.livejournal.com, 2007-11-12 | Ben Finney
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
Hi, Am 8. Juni 2016 22:47:24 MESZ, schrieb Julien Cristau : >On Wed, Jun 8, 2016 at 15:56:31 +0200, Joachim Breitner wrote: > >> We’ll have to allow for some diversity, if only to try new paths (and >> then, eventually, cut off old ones). Especially as long as there is >> motivation. >> >I haven't seen much motivation to maintain alioth (especially the >fusionforge bits) for a few years now. Alex is doing a great job of >preventing things from collapsing under their own weight entirely, but >there's a difference. I was referring to the motivation of those who want to intrude new things. Joachim
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Jun 07, 2016, at 11:22 PM, Pirate Praveen wrote: >I have started a wiki page to compare gitolite and gitlab >https://wiki.debian.org/Alioth/GitNext Another possible option is Pagure https://pagure.io/ Written in Python and developed by Fedora. Cheers, -Barry pgpAFfrqLj5m8.pgp Description: OpenPGP digital signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, 2016-06-08 at 19:40 +0200, Alexander Wirt wrote: [...] > Debian needs feature X but it is already in the e.nterprise version. We make > a patch and for commercial reasons it never gets merged (they already sell it > in the enterprise version). Which means we will have to fork the software and > keep those patches forever. Been there done that. For me, that isn't > acceptable. > I don't want another Nagios. This, however, is a concern I share. I would be interested to know whether such a contribution has ever been offered to Gitlab and what the result of that was. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, 2016-06-08 at 19:40 +0200, Alexander Wirt wrote: > On Wed, 08 Jun 2016, Jonathan Dowland wrote: > > > On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: > > > I am also not very keen on using a system with a "open core / enterprise" > > > model. For such a crucial service I would really prefer a real open source > > > system. But maybe I am alone with that oppinion. > > > > You are not alone, but please do not call Gitlab CE not "real open source". > I do for every software which forces me to sign things like: > https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/legal/individual_contributor_license_agreement.md [...] I don't see what's so unreasonable about that. They're asking you to provide the same licence for your contributions, as the licence for the existing Gitlab software. Every FOSS project expects that, even if they don't make such a formal statement of it. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
Bug#826774: ITP: genwqe-user -- A hardware accelerated version of zLib using PCIe with FPGA
Package: wnpp Severity: wishlist Owner: Breno Leitao * Package name: genwqe-user Version : 4.0.17 Upstream Author : Frank Haverkamp * URL : https://github.com/ibm-genwqe/genwqe-user * License : Apache Version 2.0 Programming Lang: C Description : A hardware accelerated version of zLib using PCIe with FPGA GenWQE (Generic Work Queue Engine) is a PCIe acceleration card. This repository contains the source code to test, maintain and update the GenWQE PCIe card. Furthermore a zlib version with hardware acceleration is provided to do zlib style compression/decompression according to RFC1950, RFC1951 and RFC1952. This can be used as alternative to the traditional software zlib. This package dependes on a specific PCIe3 FPGA Accelerator Adapter. You can find them at: http://www.ibm.com/support/knowledgecenter/POWER8/p8hcd/fcej12.htm http://www.ibm.com/support/knowledgecenter/en/POWER8/p8hcd/fcej13.htm I want to maintain this package as I am one of the main ppc64el porters, and I am in the DD process to become one.
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Wed, Jun 8, 2016 at 15:56:31 +0200, Joachim Breitner wrote: > We’ll have to allow for some diversity, if only to try new paths (and > then, eventually, cut off old ones). Especially as long as there is > motivation. > I haven't seen much motivation to maintain alioth (especially the fusionforge bits) for a few years now. Alex is doing a great job of preventing things from collapsing under their own weight entirely, but there's a difference. Cheers, Julien
Re: Genesis of the git.d.o/gitlab.d.o confusion
]] Ian Jackson > But what you are saying is that they must, right away, pick a fight > with the administrators and users of the existing services. They have > to declare their intent to obsolete it and write out a detailed plan > on how everyone will have to change. > > I think that this would be very aggressive and harmful behaviour. You > can see in this thread the kind of (very measured, under the > circumstances) responses from people who have qualms about such a > plan. > > Requiring this requires those who want improvement to (a) enter into a > political battle (b) make explicit and public their criticisms of > the existing setups (c) "win" against the now-"enemies" who support > the existing services. FWIW, you're the first one (AFAIHS) in this thread to use of adverserial words like «pick a fight», «enemies», «battle», and so on. I don't think that choice of words is helpful to finding a good solution that's reasonable to everybody. I'll be talking about official services here. What people do with their private experiments in the debian.net namespace is up to them. The requirement is that if your new project largely duplicate some existing project, you talk to the folks running the existing project, work out delineations and at a minimum, try to work together. If you can't make anything work, come back, make a reasonable case for why we still want it despite the duplication in effort. I don't think this is a particularly unreasonable bar. If you're setting up a new service, that hopefully adds some unique value to the project, it's not just an intersection of three existing projects. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: why, nicely explained (Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Wed, Jun 8, 2016 at 12:39 PM, Milan Kupcevic wrote: > On 06/08/2016 02:55 PM, Michael Lustfield wrote: > > On Wed, 8 Jun 2016 15:47:46 +, Holger Levsen > > mailto:hol...@layer-acht.org>> wrote: > >>Thanks for this nice summary. It helped me understand things better. > > > > I'm... actually gonna save this for later because it helps me understand > > the alioth workflow. > > > > [...] > > Great sarcasm. > > Milan > This was not in any way intended as sarcasm. If it came across as such, please accept this as my apology. Alioth has been, and continues to be, the hardest thing for me to wrap my head around. Whatever option (gitlab, gogs, gitolite) is rolled out and is able to eventually replace at least the git (and projects) functionality of Alioth would very much help me, and others, dive into other projects. Currently, I don't like to even poke at other projects that I'm not already familiar with; I'm scared I'll break something because I don't understand the workflows and processes involved. I /did/ star that message and save it for future use because I /did/ find it valuable. Again, I'm sorry if I came across sarcastic. Hopefully elaborating helps explain what I meant originally. :)
Upstream releases on GitHub (was: Generating upstream version from git history with uscan)
Mo Zhou writes: > (Keep me in CC list please) Done. > I'm working on some packages whose upstream (github) doesn't make > releases. So I need to invent upstream versions, that's OK. Can you appeal to upstream to make releases? The Upstream Guide https://wiki.debian.org/UpstreamGuide#Releases_and_Versions> has a section that may help you to convince them. GitHub has support for users to create releases of their projects https://help.github.com/articles/creating-releases/>, along with release notes and arbitrary files to accompany the release. So maybe you have a co-operative upstream who will help in this way. -- \ “The shortest distance between two points is under | `\ construction.” —Noelie Alito | _o__) | Ben Finney
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
Le 08/06/2016 à 10:53, Christiaan de Die le Clercq a écrit : > > +1 > > Though I am not involved in this discussion and didn't read a lot of > previous emails about this. I am going to assume it would be hosted on > Debian's servers and not with Gitlab's hosted services. We use Gogs at > the office, a (MIT licensed) Gitlab alternative. > https://github.com/gogits/gogs > It might be worth checking out. > Let me add another one: GitBlit (http://gitblit.com/) It may not be as active as others, but it is quite simple, and provide me a huge benefits over Gogs, since it knows how to handle git repositories created by third-party on disk. Using Gogs, all git repositories must have been imported. It's in Java, and I don't know if the "Pull request" thing is really useful. Adrien
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On 06/08/2016 02:08 PM, Milan Kupcevic wrote: > On 06/08/2016 11:19 AM, Felipe Sateler wrote: >> >> So, say I want to contribute to a project I don't normally work in. Steps >> in alioth: >> > > [...] > > Well, I would go this route: > > - git clone > - hack > - git commit -a -v > - git format-patch -1 --to=proj...@lists.alioth.debian.org | mailx -t > The last line is missing --stdout for correct piping: git format-patch -1 --to=proj...@domain.tld --stdout | mailx -t signature.asc Description: OpenPGP digital signature
Re: why, nicely explained (Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On 06/08/2016 02:55 PM, Michael Lustfield wrote: > On Wed, 8 Jun 2016 15:47:46 +, Holger Levsen > mailto:hol...@layer-acht.org>> wrote: >>Thanks for this nice summary. It helped me understand things better. > > I'm... actually gonna save this for later because it helps me understand > the alioth workflow. > [...] Great sarcasm. Milan signature.asc Description: OpenPGP digital signature
Re: why, nicely explained (Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Wed, 8 Jun 2016 15:47:46 +, Holger Levsen wrote: >Thanks for this nice summary. It helped me understand things better. I'm... actually gonna save this for later because it helps me understand the alioth workflow. I'm still relatively fresh to Debian dev and can say, without any doubt, alioth was (continues to be) the hardest part, by far for me to wrap my head around.
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, Jun 8, 2016 at 12:40 PM, Alexander Wirt wrote: > On Wed, 08 Jun 2016, Jonathan Dowland wrote: > >> On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: >> > I am also not very keen on using a system with a "open core / enterprise" >> > model. For such a crucial service I would really prefer a real open source >> > system. But maybe I am alone with that oppinion. >> >> You are not alone, but please do not call Gitlab CE not "real open source". > I do for every software which forces me to sign things like: > https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/legal/individual_contributor_license_agreement.md > > Thats far away from what I call open source. I also don't want to end with > things like: > > Debian needs feature X but it is already in the e.nterprise version. We make > a patch and for commercial reasons it never gets merged (they already sell it > in the enterprise version). Which means we will have to fork the software and > keep those patches forever. Been there done that. For me, that isn't > acceptable. That is the nature of free software, though. Any given upstream might be unwilling to merge some useful patch for whatever reason they choose. If enough of those patches don't get merged, then a fork may be likely. This already happens in the FOSS community without any commercial or proprietary interests. Given that, I still prefer software that doesn't have a proprietary licensed "enterprise" version as well as a free software version. -m
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On 2016-06-08 11:08:02, Lars Wirzenius wrote: > On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: > > I am also not very keen on using a system with a "open core / enterprise" > > model. For such a crucial service I would really prefer a real open source > > system. But maybe I am alone with that oppinion. > > You're not alone. The open core approach of Gitlab worries me greatly. > > (I'm just a random Debian developer. I no particular say in this.) I'm not even a Debian dev (random or not :-) ). I'm using Debian as well as gitlab and I agree that we should use fully open solutions and avoid those with so called open open core. -- |_|0|_| | |_|_|0| "Heghlu'Meh QaQ jajVam" | |0|0|0| kuLa - | gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3 signature.asc Description: PGP signature
Re: why, nicely explained (Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Wed, 8 Jun 2016 15:47:46 +, Holger Levsen wrote: >Thanks for this nice summary. It helped me understand things better. What Holger says +1. I must say that I like the discussion style shown in this thread up to now. Please more of this friendly constructivism. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, 8 Jun 2016 11:21:30 +0100, Jonathan Dowland wrote: >If it takes off and is popular, then migrating to a .org, what happens to >Alioth, >where git.d.o point etc. are all things to worry about in the future, but >they're >moot if it doesn't take off. So focus on getting a separate service running, >and >running well. I must say that those .net => .org migrations have been a nuisance for years. For me, at least. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On 06/08/2016 11:19 AM, Felipe Sateler wrote: [...] > > So, say I want to contribute to a project I don't normally work in. Steps > in alioth: > [...] Well, I would go this route: - git clone - hack - git commit -a -v - git format-patch -1 --to=proj...@lists.alioth.debian.org | mailx -t > > Compare with gitlab: > > - go to https://gitlab.debian.org/project/project > - click fork > - git clone the url gitlab will tell you > - hack > - push > - click "Submit Merge Request" button on the same page > [...] Milan signature.asc Description: OpenPGP digital signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, 08 Jun 2016, Jonathan Dowland wrote: > On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: > > I am also not very keen on using a system with a "open core / enterprise" > > model. For such a crucial service I would really prefer a real open source > > system. But maybe I am alone with that oppinion. > > You are not alone, but please do not call Gitlab CE not "real open source". I do for every software which forces me to sign things like: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/legal/individual_contributor_license_agreement.md Thats far away from what I call open source. I also don't want to end with things like: Debian needs feature X but it is already in the e.nterprise version. We make a patch and for commercial reasons it never gets merged (they already sell it in the enterprise version). Which means we will have to fork the software and keep those patches forever. Been there done that. For me, that isn't acceptable. I don't want another Nagios. Alex
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, 08 Jun 2016, Alexandre Viau wrote: > On 08/06/16 07:57 AM, Alexander Wirt wrote: > > On Wed, 08 Jun 2016, Antonio Terceiro wrote: > > > >> On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: > >> for authentication, I think you should probably use the Debian SSO with > >> client certificates: > >> https://wiki.debian.org/DebianSingleSignOn > > Nope, thats http only and doesn't cover ssh. Client certificates also have > > several problems, see enricos mails for details about it. > > Alioth accounts are first created on the web interface and then users > upload their SSH keys. I don't see why we wouldn't do the same with gitlab? You will just end with a second tool for ssh keys. I dream of some central self service tool (maybe like freeipa) which can be used as a source for authentication. > I can see the following: > - DDs login with Debian SSO and upload their public key on the web inteface > - Debian Contributors are able to create -guest a account and upload > theur public key on the web interface I personally think it sucks to have another identity provider. So if you use svn for one team and git(lab) for another, you will have to maintain your stuff twice. I would like to prevent that. Just my 2 cent Alex signature.asc Description: PGP signature
Bug#826757: ITP: golang-github-pkg-errors -- Simple error handling primitives for Go
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-pkg-errors Version : 0.6.0+git20160608.5.2af433a-1 Upstream Author : Dave Cheney * URL : https://github.com/pkg/errors * License : BSD-2-clause Programming Lang: Go Description : Simple error handling primitives for Go Package errors provides simple error handling primitives for the Go programming language. . The traditional error handling idiom in Go results in error reports without context or debugging information. . The errors package allows programmers to add context to the failure path in their code in a way that does not destroy the original value of the error. Reason for packaging: Needed by new version of the existing golang-github-pkg-sftp-dev package
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Wed, Jun 08, 2016 at 05:16:54PM +0100, Ian Jackson wrote:
> Luca Filipozzi writes ("Re: Genesis of the git.d.o/gitlab.d.o confusion (Was:
> Next steps for gitlab.debian)"):
> > On Wed, Jun 08, 2016 at 03:19:09PM +, Felipe Sateler wrote:
> > > That speaks more to the need of actually dropping the not-shiny-anymore
> > > services rather than block adding a new service.
> >
> > We aren't saying 'no'; we're saying 'please have a transition plan'.
> >
> > Dropping a not-shiny-anymore service without a transition plan to
> > move users of the service off is not great. That said, maybe that's
> > what we do. Announce a date and move on.
>
> We have a situation where someone thinks the existing services are
> poor, and wants to set up what they think is an improved one.
> Presumably they hope that lots of people will use it.
>
> But what you are saying is that they must, right away, pick a fight
> with the administrators and users of the existing services. They have
> to declare their intent to obsolete it and write out a detailed plan
> on how everyone will have to change.
I'm not asking anyone to pick a fight. I'm asking for a transition plan (more
below).
If Alioth is no longer fit for purpose, then let's see if this is the
opportunity to find a replacement.
> I think that this would be very aggressive and harmful behaviour. You
> can see in this thread the kind of (very measured, under the
> circumstances) responses from people who have qualms about such a
> plan.
>
> Requiring this requires those who want improvement to (a) enter into a
> political battle (b) make explicit and public their criticisms of
> the existing setups (c) "win" against the now-"enemies" who support
> the existing services.
>
> It is bad enough that it is sometimes thought acceptable to aggressive
> declare someone else's project obsolete. Encouraging this behaviour,
> which is what you are doing, is (I'm sorry to say) very bad indeed.
A discussion between those proposing a new service and those currently
operating the current service doesn't need to be confrontational.
Asking for a conversation to develop a plan, if possible, should not be seen as
promoting a conflict.
Maybe the sole remaining administrator of Alioth is interested in making a
transition, also.
Maybe those proposing the new service can join the Alioth team to ease the
transition.
Maybe after gitlab is up, we give people six months to move off of Alioth.
Without additional people joining the Alioth team, that service is
under-resourced. If the count of members reaches zero, then we will likely
consider the service abandoned, regardless of active user count. (Maybe we
need to introduce RFH, RFA, O, etc. for services.)
Any new service transitioned to d.o needs to have a dedicated team to operate
it. That's part of service planning.
> Also, from a practical point of view, this is an impractical way of
> carrying on change. We don't know, in general, whether the new thing
> will indeed be better. The best way is to try it and see.
Try it and see means debian.net. That's fine. That's not the same as
debian.org.
> We happily have some people who want to do the work of setting it up.
> They should be encouraged and supported. They should not be set up in
> some kind of manufactured conflict with existing services.
I don't view it as a conflict. There is one remaining Alioth administrator; we
should ask him what he wants to do.
> If the new thing really is great then we can think about what other
> things it might have obsoleted. That would principally be a decision
> for those who are supporting and using the services which might be
> withdrawn.
>
> And, that would be the time to think about firming the thing up - for
> example, by transitioning to a .org name on a DSA-owned machine.
>
> For now I would advise the people who want to try gitlab to _consider
> in advance_[1] that transition, but to feel free to set something up
> outside DSA control for now.
>
> [1] I'm sure DSA and others will be happy to advise on how to make
> choices which make moving to DSA infrastructure easier rather than
> harder.
Always.
--
Luca Filipozzi
http://www.crowdrise.com/SupportDebian
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Wed, 2016-06-08 at 20:29 +0530, Balasankar C wrote: > Tell me an "easy" way to do merging in alioth, I think perhaps it hasn't been made clear to folks on this thread that gitlab is more like a github style thing (with a webui for PRs and whatnot) rather than a more "traditional"/"simple" git hosting service (like gitorious et al) used by people with ML driven development models (who use "git send-email", "git pull-request" and "git am" etc and only need push and pull from their service). At least I assume that's what gitlab is based on what I'm infering from what some folks are skirting around on this thread, perhaps someone who is familiar with gitlab can comment. (Iain was asking why people host only use alioth for simple git hosting hate it, so your response was something of a non sequitur in that context because you began talking about a usecase which is more than simple git hosting) Ian.
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
Luca Filipozzi writes ("Re: Genesis of the git.d.o/gitlab.d.o confusion (Was:
Next steps for gitlab.debian)"):
> On Wed, Jun 08, 2016 at 03:19:09PM +, Felipe Sateler wrote:
> > That speaks more to the need of actually dropping the not-shiny-anymore
> > services rather than block adding a new service.
>
> We aren't saying 'no'; we're saying 'please have a transition plan'.
>
> Dropping a not-shiny-anymore service without a transition plan to
> move users of the service off is not great. That said, maybe that's
> what we do. Announce a date and move on.
We have a situation where someone thinks the existing services are
poor, and wants to set up what they think is an improved one.
Presumably they hope that lots of people will use it.
But what you are saying is that they must, right away, pick a fight
with the administrators and users of the existing services. They have
to declare their intent to obsolete it and write out a detailed plan
on how everyone will have to change.
I think that this would be very aggressive and harmful behaviour. You
can see in this thread the kind of (very measured, under the
circumstances) responses from people who have qualms about such a
plan.
Requiring this requires those who want improvement to (a) enter into a
political battle (b) make explicit and public their criticisms of
the existing setups (c) "win" against the now-"enemies" who support
the existing services.
It is bad enough that it is sometimes thought acceptable to aggressive
declare someone else's project obsolete. Encouraging this behaviour,
which is what you are doing, is (I'm sorry to say) very bad indeed.
Also, from a practical point of view, this is an impractical way of
carrying on change. We don't know, in general, whether the new thing
will indeed be better. The best way is to try it and see.
We happily have some people who want to do the work of setting it up.
They should be encouraged and supported. They should not be set up in
some kind of manufactured conflict with existing services.
If the new thing really is great then we can think about what other
things it might have obsoleted. That would principally be a decision
for those who are supporting and using the services which might be
withdrawn.
And, that would be the time to think about firming the thing up - for
example, by transitioning to a .org name on a DSA-owned machine.
For now I would advise the people who want to try gitlab to _consider
in advance_[1] that transition, but to feel free to set something up
outside DSA control for now.
[1] I'm sure DSA and others will be happy to advise on how to make
choices which make moving to DSA infrastructure easier rather than
harder.
Ian.
why, nicely explained (Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Wed, Jun 08, 2016 at 03:19:09PM +, Felipe Sateler wrote: > Git is not only for code hosting. It is also a tool for collaborating, > even with people not formally affiliated with your project. > > So, say I want to contribute to a project I don't normally work in. Steps > in alioth: > > - debcheckout project > - hack (possibly in own branch) > - ssh into alioth > - alioth$ mkdir -p ~/public_git/project.git > - alioth$ cd ~/public_git/project.git && git init --bare > - git remote add personal\ > git+ssh://git.debian.org/git/users/$user/project.git > - git push -u personal $currentbranch > - Wait some minutes for cron job to pick up your repo > - Realize you did not edit description, nor touch the magic > git-daemon-export-ok file in the remote repo, do so. > - Wait some minutes again > - Send mail to project maintainer instructing them to pull from > https://anonscm.debian.org/git/users/$user/project.git > > Compare with gitlab: > > - go to https://gitlab.debian.org/project/project > - click fork > - git clone the url gitlab will tell you > - hack > - push > - click "Submit Merge Request" button on the same page > > If the change is small enough (ie, doc/typo fixes), you can even edit the > file directly in the web browser. Thanks for this nice summary. It helped me understand things better. -- cheers, Holger signature.asc Description: Digital signature
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Wed, Jun 08, 2016 at 03:19:09PM +, Felipe Sateler wrote: > >> But that doesn't mean we as a project have to run and keep maintaining > >> all the things that were once shiney. > > > > +1 > > That speaks more to the need of actually dropping the not-shiny-anymore > services rather than block adding a new service. We aren't saying 'no'; we're saying 'please have a transition plan'. Dropping a not-shiny-anymore service without a transition plan to move users of the service off is not great. That said, maybe that's what we do. Announce a date and move on. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Wed, 08 Jun 2016 15:14:36 +0100, Iain R. Learmonth wrote: > Hi All, > > On 08/06/16 15:10, Peter Palfrader wrote: >> On Wed, 08 Jun 2016, Marco d'Itri wrote: >>> Since usability is the main reason many people hate using alioth, > > Do people really hate Alioth if they're just using it for git hosting? > You do some ssh and make a repo and then you just pull and push as you > would with anything else. Git is not only for code hosting. It is also a tool for collaborating, even with people not formally affiliated with your project. So, say I want to contribute to a project I don't normally work in. Steps in alioth: - debcheckout project - hack (possibly in own branch) - ssh into alioth - alioth$ mkdir -p ~/public_git/project.git - alioth$ cd ~/public_git/project.git && git init --bare - git remote add personal\ git+ssh://git.debian.org/git/users/$user/project.git - git push -u personal $currentbranch - Wait some minutes for cron job to pick up your repo - Realize you did not edit description, nor touch the magic git-daemon-export-ok file in the remote repo, do so. - Wait some minutes again - Send mail to project maintainer instructing them to pull from https://anonscm.debian.org/git/users/$user/project.git Compare with gitlab: - go to https://gitlab.debian.org/project/project - click fork - git clone the url gitlab will tell you - hack - push - click "Submit Merge Request" button on the same page If the change is small enough (ie, doc/typo fixes), you can even edit the file directly in the web browser. For flyby contributions (eg, because you noticed a small thing you can fix, or because you are working on lots of packages due to an archive- wide task), the alioth workflow doesn't work very well. > >>> "because it's shiny" is a reasonable selling point for gitlab... > > It's also far from a feature-complete replacement for Alioth and has > zero integration into our existing infrastructure. Fortunately, integration can be worked on. > > A shiny web view of repositories is not a reason to run a whole new > service. Just make a shiny theme for cgit. No, gitlab is not a shiny web view of repositories. It is a (web) app that helps people collaborate on projects. One of the things it does is give you a web view of the git repository. But it also gives you tools to manage repositories, track change proposals, triger CI builds, and integrate with other services via hooks. It probably has more features that I have just not used yet. > > >> But that doesn't mean we as a project have to run and keep maintaining >> all the things that were once shiney. > > +1 That speaks more to the need of actually dropping the not-shiny-anymore services rather than block adding a new service. -- Saludos, Felipe Sateler
Bug#826748: ITP: webhook -- Small server for creating HTTP endpoints (hooks)
Package: wnpp Severity: wishlist Owner: Free Ekanayaka * Package name: webhook Version : 2.3.8 Upstream Author : Adnan Hajdarevic * URL : https://github.com/adnanh/webhook * License : MIT Programming Lang: Go Description : Small server for creating HTTP endpoints (hooks) Webhook is a lightweight configurable tool written in Go, that allows you to easily create HTTP endpoints (hooks) on your server, which you can use to execute configured commands. You can also pass data from the HTTP request (such as headers, payload or query variables) to your commands. webhook also allows you to specify rules which have to be satisfied in order for the hook to be triggered. For example, if you're using Github or Bitbucket, you can use webhook to set up a hook that runs a redeploy script for your project on your staging server, whenever you push changes to the master branch of your project.
Odp:
08/06/2016 TO: debian-devel@lists.debian.org Czy potrzebujesz zatwierdzony biznes i prywatnego kredytu / Finansowanie w maksymalnej wysokosci 3% w skali roku. Skontaktuj sie z nami po wiecej szczególów w razie zainteresowania. Dziekuje. BSN Capital Zarzadzanie (C) 2016 -- Angielska wersja -- Do you need an approved business and personal Loan/Funding at a maximum rate of 3% per Annum. Contact us today for more details if interested. Regards, BSN Capital Managment (C) 2016
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On ബുധന് 08 ജൂണ് 2016 07:44 വൈകു, Iain R. Learmonth wrote: > Do people really hate Alioth if they're just using it for git hosting? > You do some ssh and make a repo and then you just pull and push as you > would with anything else. > Tell me an "easy" way to do merging in alioth, and then let's talk about people hating Alioth. Gitlab (or similar tools) is not preferred because they are shiny. They are preferred because they provide better, usable features. :) People don't use git for just "push and pull", you are missing the whole point of VCS and collaborative development. :) -- Balasankar C http://balasankarc.in
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Wed, Jun 08, 2016 at 03:14:36PM +0100, Iain R. Learmonth wrote: > Hi All, > > On 08/06/16 15:10, Peter Palfrader wrote: > > On Wed, 08 Jun 2016, Marco d'Itri wrote: > >> Since usability is the main reason many people hate using alioth, > > Do people really hate Alioth if they're just using it for git hosting? > You do some ssh and make a repo and then you just pull and push as you > would with anything else. > > >> "because it's shiny" is a reasonable selling point for gitlab... > > It's also far from a feature-complete replacement for Alioth and has > zero integration into our existing infrastructure. > > A shiny web view of repositories is not a reason to run a whole new > service. Just make a shiny theme for cgit. gitlab (and, to be fair, gogs which was also mentioned in the thread) are way more than a "shiny web view of repositories". you are completely missing the point. signature.asc Description: PGP signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On 08/06/16 10:17 AM, Ole Streicher wrote: > Alexandre Viau writes: >> - DDs login with Debian SSO and upload their public key on the web inteface > > Just a question: aren't there already SSH keys in ldap, and can't these > be re-used? If that is possible, then yes! It would be great. But this could be complicated due to the fact that -guest accounts don't come from the same source. I haven't looked into it. -- Alexandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Re: make ping executable by normal users?
On Wed, Jun 08, 2016 at 02:44:52PM +0100, Ben Hutchings wrote: > [...] see bug #770492. Truly amazing! For "ping", it would be like this: $ /sbin/getcap /bin/ping /bin/ping = cap_net_raw+ep $ chown root:root /bin/ping chown: changing ownership of '/bin/ping': Operation not permitted $ /sbin/getcap /bin/ping [ empty output ] And you don't even have to be root, so this is a lot easier method to lose the capability than doing tar + untar or using rsync without -X. Thanks.
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
Alexandre Viau writes: > - DDs login with Debian SSO and upload their public key on the web inteface Just a question: aren't there already SSH keys in ldap, and can't these be re-used? Best regards Ole
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
Hi All, On 08/06/16 15:10, Peter Palfrader wrote: > On Wed, 08 Jun 2016, Marco d'Itri wrote: >> Since usability is the main reason many people hate using alioth, Do people really hate Alioth if they're just using it for git hosting? You do some ssh and make a repo and then you just pull and push as you would with anything else. >> "because it's shiny" is a reasonable selling point for gitlab... It's also far from a feature-complete replacement for Alioth and has zero integration into our existing infrastructure. A shiny web view of repositories is not a reason to run a whole new service. Just make a shiny theme for cgit. > > But that doesn't mean we as a project have to run and keep maintaining > all the things that were once shiney. +1 Thanks, Iain.
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Wed, 08 Jun 2016, Marco d'Itri wrote: > On Jun 08, Luca Filipozzi wrote: > > > Let me rephrase, then: can we have a plan that addresses alioth / git / > > gitolite / gitlab / stuff rather than standing up yet another SCM/PM tool > > because it's shiny? > Since usability is the main reason many people hate using alioth, > "because it's shiny" is a reasonable selling point for gitlab... But that doesn't mean we as a project have to run and keep maintaining all the things that were once shiney. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On 08/06/16 07:57 AM, Alexander Wirt wrote: > On Wed, 08 Jun 2016, Antonio Terceiro wrote: > >> On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: >> for authentication, I think you should probably use the Debian SSO with >> client certificates: >> https://wiki.debian.org/DebianSingleSignOn > Nope, thats http only and doesn't cover ssh. Client certificates also have > several problems, see enricos mails for details about it. Alioth accounts are first created on the web interface and then users upload their SSH keys. I don't see why we wouldn't do the same with gitlab? I can see the following: - DDs login with Debian SSO and upload their public key on the web inteface - Debian Contributors are able to create -guest a account and upload theur public key on the web interface -- Alexandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, Jun 08, 2016 at 01:57:10PM +0200, Alexander Wirt wrote: > On Wed, 08 Jun 2016, Antonio Terceiro wrote: > > > On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: > > > On Wed, 08 Jun 2016, Pirate Praveen wrote: > > > > > > > On Wednesday 08 June 2016 01:07 AM, Bastian Blank wrote: > > > > > [SN: trimmed Cc list, as this is about what Debian wants] > > > > > > > > > > Hi Alex > > > > > > > > > > On Tue, Jun 07, 2016 at 08:06:41PM +0200, Alexander Wirt wrote: > > > > >> Its more things like: > > > > >> - integration into alioth - aka, how easy is it to integrate the > > > > >> already > > > > >> existing identity data (which we want to keep) into the system > > > > > > > > > > This can be easy (use OAUTH2 against the identity provider) or hard > > > > > (convert all data). Also it speaks ldap itself. > > > > > > > > Does alioth/fusionforge already support becoming an OAUTH2 identity > > > > provider? How do other debian services (like nm.debian.org) use alioth > > > > login? [1] I found this [2] > > > I wrote a minimal exporter for user information (no group or acl > > > information) that gets synced to the dacs host. That enables dacs enabled > > > services to use these information. > > > > for authentication, I think you should probably use the Debian SSO with > > client certificates: > > https://wiki.debian.org/DebianSingleSignOn > Nope, thats http only and doesn't cover ssh. gitlab would not need that for ssh pushes; they are done with a "git" user (like in most sane git server infrastructures), and each user uploads their SSH keys via the web interface after logging in against a central authentication provider. > Client certificates also have several problems, see enricos mails for > details about it. sure. > > for authorization, at least if the plan is to mirror the current alioth > > git infra you will need some scripting to sync the alioth data to gitlab > > (I would suggest starting with a very limited pilot with only one of > > very few projects). > I don't think we will give any third party access to the user and > passwordhashes. gitlab wouldn't need password hashes. as long as the central login thingy lets users login to the gitlab web UI, users can set a gitlab-specific password for git push over HTTP(S). then you would just need to know which users are members of which groups so you can create the corresponding structure on gitlab. since anyone can sign up on alioth today and get that, I don't think this will be a problem. signature.asc Description: PGP signature
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
Hi, Am Mittwoch, den 08.06.2016, 13:46 + schrieb Luca Filipozzi: > On Wed, Jun 08, 2016 at 03:17:44PM +0200, Joachim Breitner wrote: > > > Let me rephrase, then: can we have a plan that addresses alioth / git / > gitolite / gitlab / stuff rather than standing up yet another SCM/PM tool > because it's shiny? Probably as likely as we can have a plan to agree on one version control system, on one packaging scheme, on one repository layout, on one CI system (we have jenkings.d.o, ci.d.o, and many people have their own scripts). We’ll have to allow for some diversity, if only to try new paths (and then, eventually, cut off old ones). Especially as long as there is motivation. Greetings, Joachim -- Joachim “nomeata” Breitner Debian Developer nome...@debian.org • https://people.debian.org/~nomeata XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part
Re: Generating upstream version from git history with uscan
Hello! On 08/06/16 09:13 AM, Mo Zhou wrote: > I read all the uscan examples, and it seems that uscan > works basing on http and ftp only. That is to say uscan > will not scan Git repos so the above demand won't be > satisfied. `man uscan` will tell you that there is a `git mode`. Unfortunately, this mode is only able to read version numbers from tags and not generate version numbers by reading git commit dates and such. I have opened a bug on uscan for this: #811565 [1]. Please take a look at it and redirect the discussion there. I would love to see someone working on this, as this is a feature that would be much needed in the go packaging team. Cheers, 1. https://bugs.debian.org/811565 -- Alexandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Jun 08, Luca Filipozzi wrote: > Let me rephrase, then: can we have a plan that addresses alioth / git / > gitolite / gitlab / stuff rather than standing up yet another SCM/PM tool > because it's shiny? Since usability is the main reason many people hate using alioth, "because it's shiny" is a reasonable selling point for gitlab... -- ciao, Marco signature.asc Description: PGP signature
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Wed, Jun 08, 2016 at 03:17:44PM +0200, Joachim Breitner wrote: > Am Mittwoch, den 08.06.2016, 10:21 +0100 schrieb Jonathan Dowland: > > On Tue, Jun 07, 2016 at 10:25:07AM +0530, Pirate Praveen wrote: > > > Thanks for the offer. It would be great if I have more hands to help with > > > migrating git.debian.org > > > > Whoah there. Running an official Debian gitlab instance is one thing, > > migrating > > git.debian.org is quite another. Did I miss where there was consensus on > > this? > > it was a misunderstanding that went this way: > > * Someone wanted gitlab.debian.org. > * Someone pointed out that d.o services should be named by task, not > implementation. > * Someone figured that the task provided by gitlab is git hosting, > hence understood the above as a suggestion to use git.debian.org. Let me rephrase, then: can we have a plan that addresses alioth / git / gitolite / gitlab / stuff rather than standing up yet another SCM/PM tool because it's shiny? This has more to do with delivering sustainable services while reducing the overhead / technical debt. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian
Re: make ping executable by normal users?
On Tue, 2016-06-07 at 14:56 -0800, Britton Kerin wrote: > On Thu, Jun 2, 2016 at 2:33 PM, Santiago Vila wrote: > > On Thu, Jun 02, 2016 at 01:56:08PM -0800, Britton Kerin wrote: > > > On my old debian system I could ping as a normal user. The ping > > > binary had the suid bit set. Now I get: > > > > > > $ ping www.google.com > > > ping: icmp open socket: Operation not permitted > > > 2 $ > > > > > > presumably because the bit isn't set. > > > > > > What's the right fix? I could setuid it but then if I understand > > > correctly it might get changed back by an upgrade. Does it use > > > capabilites or something? > > > > Yes, it uses capabilities. The simple fix is to do this: > > > > dpkg-reconfigure iputils-ping > > Well, that works, thanks. But I really don't get the overall behavior. > It says this: > > root@debian:/home/bkerin# dpkg-reconfigure iputils-ping > Setcap worked! Ping(6) is not suid! > root@debian:/home/bkerin# > > And then ping works for non-root users. > > How, just by executing dpkg-reconfigure, did I tell it this is what > I wanted? If that's the default, why wasn't it that way to begin with? It probably was, but see bug #770492. > More generally, is it somehow possible to still run debian without > capabilities? [...] Capabilities are a non-optional feature of Linux. There are Debian ports to other kernels where this may not be the case. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
Generating upstream version from git history with uscan
Hi folks, (Keep me in CC list please) I'm working on some packages whose upstream (github) doesn't make releases. So I need to invent upstream versions, that's OK. However when one is going to maintain a number of packages that watch is not present, upstream update tracking by hand would be a nightmare. In a word, this is what I want: Suppose that the latest upstream update is `aabbccdd`, and the corresponding commit date is `20160607`, i.e. ``` $ git log -1 commit aabbccddXXX Author: XXX Date: Tue Jun 7 09:24:33 2016 + ``` And I hope some uscan hacks can automatically generate such a version string `0~20160607-gaabbccd`. I read all the uscan examples, and it seems that uscan works basing on http and ftp only. That is to say uscan will not scan Git repos so the above demand won't be satisfied. Did I miss some uscan feature? If not, do you folks think this feature proposal should be filed against uscan? BTW, the VCS scan provided in DDPO is something similar to what I want, but I didn't found the scanning script in the qa repo ... Thanks in advance. :-) -- Best, Lumin
Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
Hi, Am Mittwoch, den 08.06.2016, 10:21 +0100 schrieb Jonathan Dowland: > On Tue, Jun 07, 2016 at 10:25:07AM +0530, Pirate Praveen wrote: > > Thanks for the offer. It would be great if I have more hands to help with > > migrating git.debian.org > > Whoah there. Running an official Debian gitlab instance is one thing, > migrating > git.debian.org is quite another. Did I miss where there was consensus on this? it was a misunderstanding that went this way: * Someone wanted gitlab.debian.org. * Someone pointed out that d.o services should be named by task, not implementation. * Someone figured that the task provided by gitlab is git hosting, hence understood the above as a suggestion to use git.debian.org. * Someone concluded that therefore, we need to consider a migration from git.debian.org to gitlab. * And then, because git.debian.org is run by alioth, someone started talking about alioth. The problem was between step 2 and 3. Two suggestsions: * Consider gitlab.debian.org. Gitlab is not “just some implementation” that can be swapped for another, so it is ok to name the service according to that. Just like we have jenkings.debian.org. * If that is not acceptable, consider something like projects.debian.org as gitlab is about (git-centric) hosting of projects. Greetings, Joachim -- Joachim “nomeata” Breitner Debian Developer nome...@debian.org • https://people.debian.org/~nomeata XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part
Bug#826735: ITP: haskell-monadplus -- Haskell98 partial maps and filters over MonadPlus
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: haskell-monadplus Version : 1.4.2 Upstream Author : Hans Hoglund * URL : https://hackage.haskell.org/package/monadplus * License : BSD-3-clause Programming Lang: Haskell Description : Haskell98 partial maps and filters over MonadPlus This is a library providing functions to work with the MonadPlus typeclass (which is part of core Haskell). I'm packaging this on behalf of the Haskell team, as a new dependency for the latest version of agda. -- Sean Whitton signature.asc Description: PGP signature
Bug#826729: ITP: python-cymruwhois -- python library for interfacing with the whois.cymru.com service
Package: wnpp Severity: wishlist Owner: Ana Custura * Package name: python-cymruwhois Version : 1.5 Upstream Author : Justin Azoff * URL : https://github.com/JustinAzoff/python-cymruwhois * License : X11 Programming Lang: Python Description : python library for interfacing with the whois.cymru.com service I would like to package dnsdiag, which in turn depends on this library.
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, 08 Jun 2016, Antonio Terceiro wrote: > On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: > > On Wed, 08 Jun 2016, Pirate Praveen wrote: > > > > > On Wednesday 08 June 2016 01:07 AM, Bastian Blank wrote: > > > > [SN: trimmed Cc list, as this is about what Debian wants] > > > > > > > > Hi Alex > > > > > > > > On Tue, Jun 07, 2016 at 08:06:41PM +0200, Alexander Wirt wrote: > > > >> Its more things like: > > > >> - integration into alioth - aka, how easy is it to integrate the > > > >> already > > > >> existing identity data (which we want to keep) into the system > > > > > > > > This can be easy (use OAUTH2 against the identity provider) or hard > > > > (convert all data). Also it speaks ldap itself. > > > > > > Does alioth/fusionforge already support becoming an OAUTH2 identity > > > provider? How do other debian services (like nm.debian.org) use alioth > > > login? [1] I found this [2] > > I wrote a minimal exporter for user information (no group or acl > > information) that gets synced to the dacs host. That enables dacs enabled > > services to use these information. > > for authentication, I think you should probably use the Debian SSO with > client certificates: > https://wiki.debian.org/DebianSingleSignOn Nope, thats http only and doesn't cover ssh. Client certificates also have several problems, see enricos mails for details about it. > for authorization, at least if the plan is to mirror the current alioth > git infra you will need some scripting to sync the alioth data to gitlab > (I would suggest starting with a very limited pilot with only one of > very few projects). I don't think we will give any third party access to the user and passwordhashes. Alex signature.asc Description: PGP signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: > On Wed, 08 Jun 2016, Pirate Praveen wrote: > > > On Wednesday 08 June 2016 01:07 AM, Bastian Blank wrote: > > > [SN: trimmed Cc list, as this is about what Debian wants] > > > > > > Hi Alex > > > > > > On Tue, Jun 07, 2016 at 08:06:41PM +0200, Alexander Wirt wrote: > > >> Its more things like: > > >> - integration into alioth - aka, how easy is it to integrate the already > > >> existing identity data (which we want to keep) into the system > > > > > > This can be easy (use OAUTH2 against the identity provider) or hard > > > (convert all data). Also it speaks ldap itself. > > > > Does alioth/fusionforge already support becoming an OAUTH2 identity > > provider? How do other debian services (like nm.debian.org) use alioth > > login? [1] I found this [2] > I wrote a minimal exporter for user information (no group or acl > information) that gets synced to the dacs host. That enables dacs enabled > services to use these information. for authentication, I think you should probably use the Debian SSO with client certificates: https://wiki.debian.org/DebianSingleSignOn for authorization, at least if the plan is to mirror the current alioth git infra you will need some scripting to sync the alioth data to gitlab (I would suggest starting with a very limited pilot with only one of very few projects). > Please keep in mind that dacs is not available for non dsa enabled hosts. > > > >> - mapping groups and permissions from alioth to the new system > > > > > > Fusionforge also uses a similar group based permission system. > > > > > > Okay, there is this (hacked in?) "allow every DD to write" permission > > > that some groups use, which is only supported by gitlab EE. > Alioth uses some role based model where specific permissions get mapped to > (pre-)defined roles. We will never be able to get that into a different > system et al. My current plans are limited to group information and admin > flags. Everything else will need to get redefined by the admins to the > specific system. > > We'll have to ask gitlab folks if they are willing to provide that in CE. > I am also not very keen on using a system with a "open core / enterprise" > model. For such a crucial service I would really prefer a real open source > system. But maybe I am alone with that oppinion. You are not. even though I think gitlab is great, the fact that there is a proprietary version with "premium features" has always made me feel weird. -- Antonio Terceiro signature.asc Description: PGP signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, 08 Jun 2016, Milan P. Stanic wrote: > On Wed, 2016-06-08 at 10:53, Christiaan de Die le Clercq wrote: > > > > On 06/08/2016 10:39 AM, Arturo Borrero Gonzalez wrote: > > > On 8 June 2016 at 10:08, Lars Wirzenius wrote: > > >> On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: > > >>> I am also not very keen on using a system with a "open core / > > >>> enterprise" > > >>> model. For such a crucial service I would really prefer a real open > > >>> source > > >>> system. But maybe I am alone with that oppinion. > > >> You're not alone. The open core approach of Gitlab worries me greatly. > > >> > > >> (I'm just a random Debian developer. I no particular say in this.) > > > +1 > > +1 > > Though I am not involved in this discussion and didn't read a lot of > > previous emails about this. I am going to assume it would be hosted on > > Debian's servers and not with Gitlab's hosted services. We use Gogs at > > the office, a (MIT licensed) Gitlab alternative. > > https://github.com/gogits/gogs > > It might be worth checking out. > > +1 > > We also tried Gogs and it works very well and looks promising but we > didn't yet moved our repos from gitolite to gogs so I can't tell for > sure would it be good for Debian. IMHO, it is worth some investigation. I am a heavy gogs user, but its feature set is currently too limited and it is not as adaptable as I would like. I am also not sure how it will scale with more than 20.000 [1] git repos. Just my 2 cent Alex [1] grep -c repo.url cgitrc.repos 23092 >
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, 08 Jun 2016, Jonathan Dowland wrote: > On Tue, Jun 07, 2016 at 10:25:07AM +0530, Pirate Praveen wrote: > > Thanks for the offer. It would be great if I have more hands to help with > > migrating git.debian.org > > Whoah there. Running an official Debian gitlab instance is one thing, > migrating > git.debian.org is quite another. Did I miss where there was consensus on this? calm down, there isn't the plan to replace it soon (except for collab-maint), which will migrate as soon as possible. For everything else: we will see. I really hope to find a possibilty to proxy or redirect most of the git stuff to a new hostname. For http, it is probably easy. For everything else: ideas are welcome. Alex
Re: make ping executable by normal users?
On Tue, Jun 07, 2016 at 02:56:11PM -0800, Britton Kerin wrote: > On Thu, Jun 2, 2016 at 2:33 PM, Santiago Vila wrote: > > On Thu, Jun 02, 2016 at 01:56:08PM -0800, Britton Kerin wrote: > >> On my old debian system I could ping as a normal user. The ping > >> binary had the suid bit set. Now I get: > >> > >> $ ping www.google.com > >> ping: icmp open socket: Operation not permitted > >> 2 $ > >> > >> presumably because the bit isn't set. > > > > Yes, it uses capabilities. The simple fix is to do this: > > > > dpkg-reconfigure iputils-ping > > Well, that works, thanks. But I really don't get the overall behavior. > It says this: > > root@debian:/home/bkerin# dpkg-reconfigure iputils-ping > Setcap worked! Ping(6) is not suid! > root@debian:/home/bkerin# > > And then ping works for non-root users. > > How, just by executing dpkg-reconfigure, did I tell it this is what > I wanted? If that's the default, why wasn't it that way to begin with? It is supposed to work on initial installation as well -- the decision whether to setcap or setuid is made anew whenever iputils-ping is configured. Did you do something out of ordinary, like tarring and restoring or otherwise moving your system around? If so, that's unfortunately an expected thing -- if not, it'd be nice to know what else could have failed. > More generally, is it somehow possible to still run debian without > capabilities? I hate them. Yes, apt-get purge libcap2-bin. This won't undo existing capabilities in the filesystem, you can search for them with getcap -r, then dpkg --reconfigure them to use setuid instead. > The simple root-or-not security model is much simpler and doesn't promise > more than it can really deliver. Giving only limited capabilities greatly reduces possible attacks. If someone manages to subvert ping, in the setuid model he gains full root. In the capability model, all he gets is cap_net_raw. The damage from being able to create raw sockets is rather limited. Another such capability is for example cap_net_bind_service which lets your http/whatever server to listen on port 80 without being root. And so on... On the other hand, setcap does have its downsides, like surprising some sysadmins or tools. > I'm sad to see capabilities now as the default. I'd say the upside outweights the downsides. But, you do get to choose. Meow! -- An imaginary friend squared is a real enemy.
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, Jun 08, 2016 at 03:15:29PM +0530, Pirate Praveen wrote: > On Wednesday 08 June 2016 02:51 PM, Jonathan Dowland wrote: > > On Tue, Jun 07, 2016 at 10:25:07AM +0530, Pirate Praveen wrote: > >> Thanks for the offer. It would be great if I have more hands to help with > >> migrating git.debian.org > > > > Whoah there. Running an official Debian gitlab instance is one thing, > > migrating > > git.debian.org is quite another. Did I miss where there was consensus on > > this? > > > > May be you did not read the whole thread, I suppose you missed the flow. I hadn't read all of it. I have now, and there's definitely not consensus on moving git.debian.org to gitlab :) however, I don't think you need it. Here's how I think you should proceed. Firstly your goal is to offer a new service to Debian, not to replace Alioth or git.debian.org. If your new service turns out to be enormously popular, then its possible that Alioth will be deprecated simply because nobody would use it anymore. This would take years and years at a minimum (and Alioth does more than just git hosting). Don't talk about migrating git.debian.org or replacing Alioth; that will just upset the people who are (too) emotionally invested in running the existing services. Offer something new. Let's have a very short evaluation process to determine whether to proceed with Gitlab, Gitolite or Gogs. Don't wait to get a DSA-managed machine. Run the new thing on a debian.net host. Call it gitlab (assuming it *is* gitlab as per the evaluation) if you can: Tollef's point about trying to name services based on their service rather than implementation makes sense, but Gitlab etc. doesn't offer a git service, they offers a superset of that, and there's not really a good 'service' name for them, certainly I concur with Ian etc. that dev.debian would be too generic. In terms of where to host it, before you take up Gitlab, Inc on their hosting offer, see if you can find somewhere nearer to "official". There are some hosts at https://wiki.debian.org/MemberBenefits which might be useful. But if nothing pans out, take up Gitlab on their offer. Don't size the machine too small to start with. Plan for growth from day 0. If it takes off and is popular, then migrating to a .org, what happens to Alioth, where git.d.o point etc. are all things to worry about in the future, but they're moot if it doesn't take off. So focus on getting a separate service running, and running well. -- Jonathan Dowland Please do not CC me, I am subscribed to the list.
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, 2016-06-08 at 10:53, Christiaan de Die le Clercq wrote: > > On 06/08/2016 10:39 AM, Arturo Borrero Gonzalez wrote: > > On 8 June 2016 at 10:08, Lars Wirzenius wrote: > >> On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: > >>> I am also not very keen on using a system with a "open core / enterprise" > >>> model. For such a crucial service I would really prefer a real open source > >>> system. But maybe I am alone with that oppinion. > >> You're not alone. The open core approach of Gitlab worries me greatly. > >> > >> (I'm just a random Debian developer. I no particular say in this.) > > +1 > +1 > Though I am not involved in this discussion and didn't read a lot of > previous emails about this. I am going to assume it would be hosted on > Debian's servers and not with Gitlab's hosted services. We use Gogs at > the office, a (MIT licensed) Gitlab alternative. > https://github.com/gogits/gogs > It might be worth checking out. +1 We also tried Gogs and it works very well and looks promising but we didn't yet moved our repos from gitolite to gogs so I can't tell for sure would it be good for Debian. IMHO, it is worth some investigation.
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On 2016-06-08 10:45, Pirate Praveen wrote: On Wednesday 08 June 2016 02:51 PM, Jonathan Dowland wrote: On Tue, Jun 07, 2016 at 10:25:07AM +0530, Pirate Praveen wrote: Thanks for the offer. It would be great if I have more hands to help with migrating git.debian.org Whoah there. Running an official Debian gitlab instance is one thing, migrating git.debian.org is quite another. Did I miss where there was consensus on this? May be you did not read the whole thread, I suppose you missed the flow. I've read the whole thread, and have not seen anything approaching consensus on moving the service. In terms of timing, migrating to gitolite was certainly discussed some time ago, at least in the corridor track around https://summit.debconf.org/debconf15/meeting/390/alioth-git-replacement-bof/ Regards, Adam
Re: replacing alioth is more than git (Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, Jun 8, 2016 at 09:41:11 +, Holger Levsen wrote: > Hi, > > setting up this gitlab thing is one thing, but moving away from alioth > has this problem that we'll need to keep (svn|cvs|bzr|hg|...).debian.org > as not only some packages workflows depend on it, but also parts of our > own infrastructure. > > Does anyone has any idea how to do this in practice, without keeping > alioth running? (or is the only idea to keep it running and phase it out > in 5-10 years?) > I think the most realistic way is to phase it out gradually. Starting with git makes a lot of sense. Cheers, Julien
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wednesday 08 June 2016 02:51 PM, Jonathan Dowland wrote: > On Tue, Jun 07, 2016 at 10:25:07AM +0530, Pirate Praveen wrote: >> Thanks for the offer. It would be great if I have more hands to help with >> migrating git.debian.org > > Whoah there. Running an official Debian gitlab instance is one thing, > migrating > git.debian.org is quite another. Did I miss where there was consensus on this? > May be you did not read the whole thread, I suppose you missed the flow. This reply was immediately after DSA suggestion of not duplicating services [1]. Then I proposed gitlab as a possible replacement [2][3] and gitolite was also suggested. I created a wiki page to compare the options [4] and it was decided to run gitlab instance as experimental service. gitolite was not in the scene then. [1] https://lists.debian.org/debian-devel/2016/06/msg00069.html [2] https://lists.debian.org/debian-devel/2016/06/msg00074.html [3] https://lists.debian.org/debian-devel/2016/06/msg00077.html [4] https://wiki.debian.org/Alioth/GitNext signature.asc Description: OpenPGP digital signature
replacing alioth is more than git (Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
Hi, setting up this gitlab thing is one thing, but moving away from alioth has this problem that we'll need to keep (svn|cvs|bzr|hg|...).debian.org as not only some packages workflows depend on it, but also parts of our own infrastructure. Does anyone has any idea how to do this in practice, without keeping alioth running? (or is the only idea to keep it running and phase it out in 5-10 years?) -- cheers, Holger signature.asc Description: Digital signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
Hi, On Tue Jun 07, 2016 at 10:19:48 +0530, Pirate Praveen wrote: > > Another prerequisite for > >d.o > >hosting is that it runs on a DSA-managed machine. > > How do I get such a machine? Since Gitlab Inc, is sponsoring this > hosting, should we get a new machine and set it up as per DSA > standards? DSA-managed machines means, that DSA is physical owning the machine. As a DSA member, i do not want to open a new hosting location for new machines. Thus Gitlab Inc, is sponsoring the hosting is not a real option for me. Cheers, Martin -- Martin Zobel-Helas Debian System Administrator Debian & GNU/Linux Developer Debian Listmaster http://about.me/zobel Debian Webmaster GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B
Re: Dropping upstart jobs (or not)
On Sat, Jun 04, 2016 at 09:35:29PM -0700, Russ Allbery wrote: > Because that's the point of this thread. Notice the subject? That's the > point I'm making. I think I like the new, angry Russ :>
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: > I am also not very keen on using a system with a "open core / enterprise" > model. For such a crucial service I would really prefer a real open source > system. But maybe I am alone with that oppinion. You are not alone, but please do not call Gitlab CE not "real open source".
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Tue, Jun 07, 2016 at 10:25:07AM +0530, Pirate Praveen wrote: > Thanks for the offer. It would be great if I have more hands to help with > migrating git.debian.org Whoah there. Running an official Debian gitlab instance is one thing, migrating git.debian.org is quite another. Did I miss where there was consensus on this?
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On 06/08/2016 10:39 AM, Arturo Borrero Gonzalez wrote: > On 8 June 2016 at 10:08, Lars Wirzenius wrote: >> On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: >>> I am also not very keen on using a system with a "open core / enterprise" >>> model. For such a crucial service I would really prefer a real open source >>> system. But maybe I am alone with that oppinion. >> >> You're not alone. The open core approach of Gitlab worries me greatly. >> >> (I'm just a random Debian developer. I no particular say in this.) >> > > +1 > +1 Though I am not involved in this discussion and didn't read a lot of previous emails about this. I am going to assume it would be hosted on Debian's servers and not with Gitlab's hosted services. We use Gogs at the office, a (MIT licensed) Gitlab alternative. https://github.com/gogits/gogs It might be worth checking out. signature.asc Description: OpenPGP digital signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On 8 June 2016 at 10:08, Lars Wirzenius wrote: > On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: >> I am also not very keen on using a system with a "open core / enterprise" >> model. For such a crucial service I would really prefer a real open source >> system. But maybe I am alone with that oppinion. > > You're not alone. The open core approach of Gitlab worries me greatly. > > (I'm just a random Debian developer. I no particular say in this.) > +1 -- Arturo Borrero González
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: > I am also not very keen on using a system with a "open core / enterprise" > model. For such a crucial service I would really prefer a real open source > system. But maybe I am alone with that oppinion. You're not alone. The open core approach of Gitlab worries me greatly. (I'm just a random Debian developer. I no particular say in this.) -- Schrödinger's backup hypothesis: the condition of any backup is undefined until a restore is attempted. -- andrewsh signature.asc Description: PGP signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, 08 Jun 2016, Pirate Praveen wrote: > On Wednesday 08 June 2016 01:07 AM, Bastian Blank wrote: > > [SN: trimmed Cc list, as this is about what Debian wants] > > > > Hi Alex > > > > On Tue, Jun 07, 2016 at 08:06:41PM +0200, Alexander Wirt wrote: > >> Its more things like: > >> - integration into alioth - aka, how easy is it to integrate the already > >> existing identity data (which we want to keep) into the system > > > > This can be easy (use OAUTH2 against the identity provider) or hard > > (convert all data). Also it speaks ldap itself. > > Does alioth/fusionforge already support becoming an OAUTH2 identity > provider? How do other debian services (like nm.debian.org) use alioth > login? [1] I found this [2] I wrote a minimal exporter for user information (no group or acl information) that gets synced to the dacs host. That enables dacs enabled services to use these information. Please keep in mind that dacs is not available for non dsa enabled hosts. > >> - mapping groups and permissions from alioth to the new system > > > > Fusionforge also uses a similar group based permission system. > > > > Okay, there is this (hacked in?) "allow every DD to write" permission > > that some groups use, which is only supported by gitlab EE. Alioth uses some role based model where specific permissions get mapped to (pre-)defined roles. We will never be able to get that into a different system et al. My current plans are limited to group information and admin flags. Everything else will need to get redefined by the admins to the specific system. > > We'll have to ask gitlab folks if they are willing to provide that in CE. I am also not very keen on using a system with a "open core / enterprise" model. For such a crucial service I would really prefer a real open source system. But maybe I am alone with that oppinion. Alex signature.asc Description: PGP signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wednesday 08 June 2016 01:07 AM, Bastian Blank wrote: > [SN: trimmed Cc list, as this is about what Debian wants] > > Hi Alex > > On Tue, Jun 07, 2016 at 08:06:41PM +0200, Alexander Wirt wrote: >> Its more things like: >> - integration into alioth - aka, how easy is it to integrate the already >> existing identity data (which we want to keep) into the system > > This can be easy (use OAUTH2 against the identity provider) or hard > (convert all data). Also it speaks ldap itself. Does alioth/fusionforge already support becoming an OAUTH2 identity provider? How do other debian services (like nm.debian.org) use alioth login? [1] I found this [2] >> - mapping groups and permissions from alioth to the new system > > Fusionforge also uses a similar group based permission system. > > Okay, there is this (hacked in?) "allow every DD to write" permission > that some groups use, which is only supported by gitlab EE. We'll have to ask gitlab folks if they are willing to provide that in CE. I'm tracking the requirements and possible solutions here [3] [1] https://lists.debian.org/debian-devel-announce/2014/03/msg8.html [2] https://wiki.debian.org/DebianSingleSignOn#Howto_setup_your_web-app_with_DACS [3] https://wiki.debian.org/Shukra signature.asc Description: OpenPGP digital signature
Bug#826707: ITP: golang-github-bowery-prompt -- Cross platform prompting library
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-bowery-prompt Version : 0.0~git20150722.0.3a76720-1 Upstream Author : Bowery, Inc. * URL : https://github.com/Bowery/prompt * License : MIT (Expat) Programming Lang: Go Description : Cross platform prompting library for Go Prompt is a cross platform line-editing prompting library. . Features: * Keyboard shortcuts in prompts * History support * Secure password prompt * Custom prompt support * Fallback prompt for unsupported terminals * ANSI conversion for Windows Reason for packaging: Needed by govendor 1.0.3
