Bug#792101: ITP: gogs -- Gogs is a self hosted service aiming to provide a similar set of features to gitlab and github.
Package: wnpp Severity: wishlist Owner: John Hackett * Package name: gogs Version : 0.6.1 Upstream Author : lu...@gitea.io * URL : https://github.com/go-gitea/gitea * License : MIT Programming Lang: Golang Description : Gogs is a self hosted service aiming to provide a similar set of features to gitlab and github. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150711095500.6478.76296.report...@afghan.shockingly.eu
Bug#792112: ITP: ruby-faker -- easily generate fake data
Package: wnpp Severity: wishlist Owner: Balasankar C * Package name: ruby-faker Version : 1.4.3 Upstream Author : Benjamin Curtis * URL : https://github.com/stympy/faker * License : Expat Programming Lang: Ruby Description : easily generate fake data -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2015071841.843.71485.reportbug@sasalam
Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull ’
❦ 10 juillet 2015 22:00 GMT, Jeremy Stanley : > Simulating Gerrit's behaviors in this regard would probably not > satisfy the desire for a "replacement for pull requests" however > since Gerrit assumes a LKML-esque "rebase your patch until you get > it right" approach rather than the "keep stacking more fixes onto > your broken patch" method that Github users have come to expect. Github just puts a lower barrier level entry but many upstreams require the stack of patches to be properly squashed before merging. And force-pushing is allowed. -- Don't compare floating point numbers just for equality. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: GitLab B.V. to host free-software GitLab for Debian project (was: debian github organization ?)
On Wed, Apr 22, 2015 at 3:08 PM, Neil McGovern wrote: >> > It will be an instance of gitlab CE, under MIT license and managed by >> > Debian. Gitlab folks will just sponsor the hosting. >> >> Much appreciated, thank you to GitLab B.V. for this generous offer. Just out of curiosity, has anybody made any progress on this? Is GitLab's kind offer still on the table? Cheers! -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAMHuwox+0mwkJhZBPahNEoc-2ax74MZE8oyGJ0BAjuq3t3=d...@mail.gmail.com
Re: GitLab B.V. to host free-software GitLab for Debian project (was: debian github organization ?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I will be working on it. First task is to complete gitlab packaging. See balasankarc.in/gitlab for current status. Gitlab folks sponsored 60 days of work with 3000 usd. I post updates at poddery.com/tags/debian-gitlab-months On 2015, ജൂലൈ 11 6:51:22 PM IST, Alessio Treglia wrote: >On Wed, Apr 22, 2015 at 3:08 PM, Neil McGovern >wrote: >>> > It will be an instance of gitlab CE, under MIT license and managed >by >>> > Debian. Gitlab folks will just sponsor the hosting. >>> >>> Much appreciated, thank you to GitLab B.V. for this generous offer. > >Just out of curiosity, has anybody made any progress on this? >Is GitLab's kind offer still on the table? > >Cheers! > >-- >Alessio Treglia | www.alessiotreglia.com >Debian Developer | ales...@debian.org >Ubuntu Core Developer| quadris...@ubuntu.com >0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A > > >-- >To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org >with a subject of "unsubscribe". Trouble? Contact >listmas...@lists.debian.org >Archive: >https://lists.debian.org/CAMHuwox+0mwkJhZBPahNEoc-2ax74MZE8oyGJ0BAjuq3t3=d...@mail.gmail.com - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- iQJWBAEBCABAORxQcmF2ZWVuIEFyaW1icmF0aG9kaXlpbCAocGlyYXRlcGluKSA8 cHJhdmVlbkBkZWJpYW4ub3JnPgUCVaEaJQAKCRDOH5xnRRLCKtd5EACKaaWBsqdd VLMy969C+3+jFZz2acmDivHrGx+06JUIErTANeoooYczOa/nL7c+1VE97tlaF7N3 aV7jDfjmkDjr5D+GV58GKwYVTJXq1nqurndzW+ZMB0RkfLMbioM8qSvi9b+iIsP7 cDcilU7twfJhC8aEznZIrzUaIyWzwjF+1crDsmL64AqNZBJhkyGfmZfv5UwXcn0A 0q0LgfnDbnMGbv5Qip269ME4Vhi6vlaRqZiDUIaVADH5iUv7NgdcNkaoYWlfkXDe CsZWSe5fq5LZdlAUqmY5c1eK8MYOfR+oq5CzdPaR1CB00JkwjpMUrMJrZ9gBwNbX b8K4YZ/onYUlxSO5nTIMnYCqEoiGS2C0+TfVtHlNA7qt/gzfeBCPPU6DS5jgMJTd PKKareVTIJAjyk2W8ZcIucwKHz2eWC5nQmObTnzTJxULypCP3bbLfns6sYBlzq/z GPrItaX68KpB3ffvIVw+BoZTBHu4i8Cib4egKJxawjxdKvaJMYhmblExW0fOg/PR oNvuBYY79TpvcwHhURttB6fZTcBbeogvyY5M3bqJZb6VU8NDiKExDAbiXf4JeOvI N8CgYTF/+JTmig5sMJ3RkVVty6dlXu+mDGlp4Fjdbq3f/HRpITabIOXMfPfNa6ke ZsLUyamNk/C7MRJO9N9NH+HkmQzR2fYlrg== =fyk4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/116622b1-1bac-4b98-9c1b-72e6c8bcd...@onenetbeyond.org
Re: GitLab B.V. to host free-software GitLab for Debian project (was: debian github organization ?)
On Sat, Jul 11, 2015 at 2:29 PM, Pirate Praveen wrote: > I will be working on it. First task is to complete gitlab packaging. > See balasankarc.in/gitlab for current status. That is quite a progress. Awesome, thanks! Cheers. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/camhuwow5f1c6+fwybdumppgib2zdhr-+6ttgb9-wcwzt8kz...@mail.gmail.com
Bug#791536: marked as done (general: Debian 7.8 running EXTREMELY slow. Like chronic stop script error.)
Your message dated Sat, 11 Jul 2015 18:34:47 +0200 with message-id <55a145a7.6060...@sourcepole.ch> and subject line Re: Bug#791536: general: Debian 7.8 running EXTREMELY slow. Like chronic stop script error. has caused the Debian Bug report #791536, regarding general: Debian 7.8 running EXTREMELY slow. Like chronic stop script error. to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 791536: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791536 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: important Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? Seems unrelated to any change * What exactly did you do (or not do) that was effective (or ineffective)? I thought that it was a stop script error with facebook but it is constant, even when facebook is off. Restarting doesn't help. Within a short time, it's back to turtle slow, long hesitations between typing letters, extremely long time for web pages to load. etc. Wondering if it's a virus. * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- System Information: Debian Release: 7.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- End Message --- --- Begin Message --- Hello, Am 06.07.2015 um 00:37 schrieb lauren-blaine: > Package: general > Severity: important > > Dear Maintainer, > *** Please consider answering these questions, where appropriate *** > >* What led up to the situation? Seems unrelated to any change >* What exactly did you do (or not do) that was effective (or > ineffective)? I thought that it was a stop script error with facebook but > it is constant, even when facebook is off. Restarting doesn't help. Within a > short time, it's back to turtle slow, long hesitations between typing letters, > extremely long time for web pages to load. etc. Wondering if it's a virus. >* What was the outcome of this action? >* What outcome did you expect instead? > > *** End of the template - remove these lines *** > > > > -- System Information: > Debian Release: 7.8 > APT prefers oldstable-updates > APT policy: (500, 'oldstable-updates'), (500, 'oldstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.2.0-4-amd64 (SMP w/6 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash I'm closing your bug report. The problem with your bug report is that it does not contain any actionable information. From the little information you have provided it is not possible to deduce what's wrong. Also, the machine is running a very old unsupported version of debian (oldstable). It would be best if you'd contact a Debian support channel where people can potentially guide you along. I suggest: https://www.debian.org/support https://lists.debian.org/debian-user/ http://forums.debian.net/ irc://irc.oftc.net/debian Thanks, *t--- End Message ---
Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull ’
Ben Finney writes ("Re: GitHub “pull request” is proprietary, incompatible with
Git ‘request-pull ’"):
> My reading of https://developer.github.com/v3/#authentication>
> leads me to infer there's no way for to submit a GitHub “pull request”
> without having a GitHub account.
>
> Decentralisation would require that anyone with a Git repository can
> submit a GitHub “pull request” without any need for a GitHub account.
> I'd love to learn if that's possible now.
This subthread is in danger of going off into the weeds.
For the avoidance of any doubt: I was volunteering to do some work if
we can figure out what the work is that needse to be done (and it
seems plausible to me, obviously).
I am (obviously) not volunteering to fix Github itself. That is not
possible for me, only for Github.
The way I am offering to help is this: there seems to (or some people
are saying there is) a lack of straightforward server-side software
which (i) project maintainers can run on a suitable friendly server
and (ii) contributors who are used to a github workflow can interact
with reasonably easily.
If someone (preferably several people) who want such a thing would
like to (get together and) write a simple specification for what they
want (and how it differs from or plugs into gerrit, gitorious etc.), I
am still offering to write it.
I don't have a need for such a thing myself right now, but I have the
server side implementation experience. Provided the requirements
don't include too many awkward bells and whistles, I think it ought to
be not too big a job.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21921.20090.614169.946...@chiark.greenend.org.uk
git repositories for packages and signed pushes
We've had some discussion of some of these issues already, but let me summarise: Most current workflows for Debian packaging with git involve a git repository somewhere, and in practice it is very impractical not to trust the contents of (at least some branches in) that repository. Currently AFAIAA most people are using ad-hoc repositories on private servers, or something on alioth. And most people are not using any kind of signature scheme. This is far from ideal. I think we should switch to using GPG-signed pushes. (This is better than GPG-signed tags because tags don't really specify what branches to update, unless you impose special syntax on them - thus reinventing signed pushes. It is better than GPG-signed commits because it works better with history rewriting, makes clearer what is actually being intentionally done by the signer, and exposes and uses your key at only the right point in the process.) For this we need a git server which supports GPG-signed pushes, and (at least) all authorised pushers to be using a suitable verson of git. I guess the rule would be that a DD is allowed to create, delete and rename and update branches on any package's repo, and that a DM may only access repos for `their' packages (and perhaps may only update ff - TBD). The new dgit git repos VM is IMO an appropriate place to host this. The dgit magic git server already knows how to decide whether a particular key is authorised for a particular package and has many of the necessary moving parts. The only significant problem is that the relevant versions of git are currently only in experimental. Can we expect these (a) to be in sid soon and (b) usefully stable backports to be available for (at least) jessie ? (CCing git@p.d.o.) I'll also have to talk to DSA about what they think about running a backport of git. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21921.20783.583098.549...@chiark.greenend.org.uk
Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull ’
Ian Jackson writes:
> Ben Finney writes ("Re: GitHub “pull request” is proprietary, incompatible
> with Git ‘request-pull ’"):
> > My reading of https://developer.github.com/v3/#authentication>
> > leads me to infer there's no way for to submit a GitHub “pull
> > request” without having a GitHub account.
> >
> > Decentralisation would require that anyone with a Git repository can
> > submit a GitHub “pull request” without any need for a GitHub
> > account. I'd love to learn if that's possible now.
>
> This subthread is in danger of going off into the weeds.
>
> For the avoidance of any doubt: I was volunteering to do some work if
> we can figure out what the work is that needse to be done (and it
> seems plausible to me, obviously).
Thanks. In that context, then, let me answer in a different way:
A putative decentralised [0] Git pull request feature would IMO require
that anyone with a Git repository can submit a pull request to any
other, without any registration on a privileged central server.
My understanding is that Git ‘request-pull’ satisfies this requirement
for decentralisation, by using two decentralised protocols: Git, and
a formatted plain text file.
> The way I am offering to help is this: there seems to (or some people
> are saying there is) a lack of straightforward server-side software
> which (i) project maintainers can run on a suitable friendly server
> and (ii) contributors who are used to a github workflow can interact
> with reasonably easily.
Once a hosted service decides to use Git ‘request-pull’ on which to
build its pull request feature, it already knows the inputs to the ‘git
request-pull’ command: the start and end commit hash, the repository URL.
So what seems to be lacking is:
* A reliably-available transport for getting the ‘request-pull’ output
from one repository to an arbitrary one hosted elsewhere.
One obvious candidate is email (a decentralised service), but Git
repositories don't automatically know how to send and receive email.
* Good UX design for the workflow around generating and applying an
individual pull request.
[0] As an aside, the terms “decentralised”, “federated”, “distributed”
http://networkcultures.org/unlikeus/resources/articles/what-is-a-federated-network/>
can get confusing; I think the article at that URL may help.
--
\ “Never express yourself more clearly than you are able to |
`\ think.” —Niels Bohr |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85r3oewjvd@benfinney.id.au
Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull ’
Ben Finney writes ("Re: GitHub “pull request” is proprietary, incompatible with
Git ‘request-pull ’"):
> A putative decentralised [0] Git pull request feature would IMO require
> that anyone with a Git repository can submit a pull request to any
> other, without any registration on a privileged central server.
Yes.
> My understanding is that Git ‘request-pull’ satisfies this requirement
> for decentralisation, by using two decentralised protocols: Git, and
> a formatted plain text file.
However, it has two important downsides:
* The person sending the pull request must have a git server. This
is not inherently a property of the problem, nor of the underlying
git machinery. I think it is undesirable.
* The vital statistics of the pull request are transmitted by email.
> Once a hosted service decides to use Git ‘request-pull’ on which to
> build its pull request feature, [...]
Perhaps this is the reason we seem to be talking past each other.
I don't think this is a good idea. git request-pull is not a
protocol, it's a tool for helping generate a moderately standard form
of email. Trying to turn it into a protocol is not going to end well.
Furthermore, you seem to be under the impression that it is necessary
for the world to agree on a single protocol. That's not true. It is
not even necessary for the UI to be particularly similar.
What's necessary is for the submitter to be able to do whatever the
maintainer asks, but that could easily be a web page written by the
maintainer saying "to make a pull request, run the following git push
rune".
> So what seems to be lacking is:
I think we have very different ideas of what the problem is and how it
might be solved. If you wish to go ahead and try to make some kind of
protocol layered on top of git request-pull, I wish you luck, but I'm
afraid I don't have effort to provide concrete help for such a
project.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21921.33234.592262.395...@chiark.greenend.org.uk
Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull ’
On Sat, Jul 11, 2015 at 06:12:26PM +0100, Ian Jackson wrote:
> Ben Finney writes ("Re: GitHub “pull request” is proprietary, incompatible
> with Git ‘request-pull ’"):
> > My reading of https://developer.github.com/v3/#authentication>
> > leads me to infer there's no way for to submit a GitHub “pull request”
> > without having a GitHub account.
> >
> > Decentralisation would require that anyone with a Git repository can
> > submit a GitHub “pull request” without any need for a GitHub account.
> > I'd love to learn if that's possible now.
>
> This subthread is in danger of going off into the weeds.
>
> For the avoidance of any doubt: I was volunteering to do some work if
> we can figure out what the work is that needse to be done (and it
> seems plausible to me, obviously).
>
> I am (obviously) not volunteering to fix Github itself. That is not
> possible for me, only for Github.
>
> The way I am offering to help is this: there seems to (or some people
> are saying there is) a lack of straightforward server-side software
> which (i) project maintainers can run on a suitable friendly server
> and (ii) contributors who are used to a github workflow can interact
> with reasonably easily.
>
> If someone (preferably several people) who want such a thing would
> like to (get together and) write a simple specification for what they
> want (and how it differs from or plugs into gerrit, gitorious etc.), I
> am still offering to write it.
>
> I don't have a need for such a thing myself right now, but I have the
> server side implementation experience. Provided the requirements
> don't include too many awkward bells and whistles, I think it ought to
> be not too big a job.
I have a few ideas about this. I have used gerrit before, and it
provides a really nice experience except for 2 little facts:
- you have to use a web UI thingy to review patches (although that said
web UI does have a really nice keyboard-based navigation support)
- the server side is quite heavyweight, so both running your own and
packaging it for Debian seems to be difficult.
I would be very happy if something that works more or less like gerrit
but without the above issue existed. I would imagine something along
these lines:
on the submitter side
---
1) obtain repository (git clone)
2) branch off master (or any other branch) to a branch named, say,
`bugfix`.
3) hack and produce one or more commits in the `bugfix` branch.
4) be able to submit that branch as a pull request to the master
branch on the original repository. I would imagine a UI like this:
$ git pull-request submit $ORIGBRANCH $PATCHSET
(in this example $ORIGBRANCH would be `master`, and $PATCHSET would be
`bugfix`)
This would create a specially named ref on the maintainer's
repository, and the maintainer should be notified somehow that such a
pull request exists. Notifications methods could be plugged, so that
you can choose to enable notification by email, IRC, or what have you.
Of course notifications by email is the obvious choice, given commits
come with email addresses.
I would imagine that this process would make sure that the top of HEAD
is a fast forward on top of the target remote branch, an maybe rebase
the submitted branch before submitting.
on the maitainer side
---
1) git fetch/pull
merge requests are available locally at a given namespace, say,
refs/merge-requests/$id, where $id could be e.g. a autoincremented
number, what shouldn't be hard since pushes already lock the target
repository anyway.
2) git pull-request test $id
switches to a local branch which has the latest commit on pull request
3.1) git pull-request accept $id
I imagine this could be as easy as a simple wrapper around `git
merge`. when the maintainer pushes the branch, it would be really
awesome if the server noticed which pull requests have been merged,
and notify the submitters of that.
3.2) git pull-request reject $id
The maintainer would type a message saying why that pull request is
being rejected, and the pull request would somehow be marked as such.
When the maintainer pushes, the submitter should be notified that the
pull request has been rejected, with the reason why.
3.3) git pull-request review $id
This would probably be the hardest part, since we would need to devise
a reasonable UI for the maintainer to comment on the contents of the
patches. I would imagine that being able to record some review message
against each hunk of the diffs would be a good beginning. Being able
to add line-by-line comments, as gerrit allows, would be awesome.
when the maintainer pushes, the submitter should be notified of the
review.
It would be nice to somehow support re-submitting a reviewed pull
request, and to be able to recognize a second pull request as a new
version of
Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull ’
On 2015-07-11 22:32:31 -0300 (-0300), Antonio Terceiro wrote: > I have a few ideas about this. I have used gerrit before, and it > provides a really nice experience except for 2 little facts: > > - you have to use a web UI thingy to review patches (although that said > web UI does have a really nice keyboard-based navigation support) You may want to check out... https://packages.debian.org/gertty Now that I use gertty, I can't recall how I ever managed to limp my way through the Gerrit WebUI. > - the server side is quite heavyweight, so both running your own and > packaging it for Debian seems to be difficult. [...] As someone who helps maintain a very high-traffic Gerrit server, I can confirm it's at least as un-fun as any very complex Java-based server application. And apparently packaging it is even less fun... https://bugs.debian.org/589436 -- Jeremy Stanley -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150712021716.ge2...@yuggoth.org
