Re: debian github organization ?

[Brian May]

On Sat, 18 Apr 2015 at 18:01 Neil Williams  wrote:

> The github pull request is just a nice UI over a patch. What on earth
> is wrong with that?
>

Unfortunately, github pull requests have limitations compared with patches,
archived for example on a mailing list. For blog post on this see:


https://julien.danjou.info/blog/2013/rant-about-github-pull-request-workflow-implementation

IIRC, my understanding is that creating a patch request means you can't
ever delete the branch associated with the pull request or you can't see
the patch any more from the pull request. Yes, the patch request remains
important even after the patch has been merged, because it can include
discussions on how a particular set of decisions was made concerning the
change in question.

Also worth noting that, while git is a distributed service, some of the
services github provides are not distributed, most notably the issue
tracker and pull requests (not sure it is possible to disable pull
requests). You can only get these discussions from the central github
server and emails from the server. If github went down you would lose all
this information (yes, you can back it up - does anyone do so?)

(side note: github's wiki is based on git and open source software - gollum
 - so can - at least in theory - be distributed. Although last I checked
open source software had features not implemented in github because github
was using an old version of gollum  - not sure if that is still the case or
not; at the time it meant my pages didn't work both in guthub and gollum at
the same time)

I am not saying that we should not use github - I use it all the time (with
and without gerrit), however we should be aware of its limitations.

Re: Bits from the dpkg project: 1.17.x series, general news

[Cyril Brulebois]

Guillem Jover  (2015-04-18):
> General News
> 
> 
> * Raphaël Hertzog has stepped down as maintainer.

It seems a little sad there's not even a thanks or two, so here it is:
Thanks so much for all the hard (and not only technical) work, Raphaël!

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: debian github organization ?

[Vincent Bernat]

 ❦ 19 avril 2015 07:34 GMT, Brian May  :

> Unfortunately, github pull requests have limitations compared with
> patches, archived for example on a mailing list. For blog post on this
> see:
>
> https://julien.danjou.info/blog/2013/rant-about-github-pull-request-workflow-implementation
>
> IIRC, my understanding is that creating a patch request means you
> can't ever delete the branch associated with the pull request or you
> can't see the patch any more from the pull request. Yes, the patch
> request remains important even after the patch has been merged,
> because it can include discussions on how a particular set of
> decisions was made concerning the change in question.

This is not the case anymore. Deleting a branch leaves the pull request
as is. Also, editing commits leave the history of the pull request in
the timeline. Comments on edited commits are also still accessible.
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: debian github organization ?

[Brian May]

On Sun, 19 Apr 2015 at 18:25 Vincent Bernat  wrote:

> This is not the case anymore. Deleting a branch leaves the pull request
> as is. Also, editing commits leave the history of the pull request in
> the timeline. Comments on edited commits are also still accessible.
>

Oh, if that is the case that is really good. I will have to try it out
sometime.

I suspect not many people know about this however (did I miss an
announcement from github on this?), and I suspect it may not be possible to
make changes to the pull request without write access to the branch.

Unlike with gerrit, where I believe is possible to other people to post
improved versions of the patch.

Re: debian github organization ?

[Robert Collins]

On 17 April 2015 at 18:13, Russ Allbery  wrote:
> Marc Haber  writes:
>
>> Thankfully, git is by far the best VCS on the market and the vast
>> majority of people seem to agree. But imagine the outcry if ten years
>> ago Sourceforge had said "our VCS is svn and we don't support anything
>> else".
>
> Er, they did, didn't they?  I could have sworn that they only supported
> CVS initially, and then only added Subversion, and getting Git support
> took forever.
>
> Launchpad, similarly, is probably suffering a lot from the decision to
> only support bzr.  (It suffers from some other things as well, such as
> asset licensing and how difficult it is to stand up your own, but I think
> the VCS is a major problem right now.)

https://dev.launchpad.net/Code/Git - git support is there in nascent
form now and under active development. I think a couple of months will
see it looking pretty solid.

> So you're of course right -- there's a tradeoff.
>
> However, I still stand by the decision to only support a single VCS, at
> least when you start, because you can move a lot faster and implement a
> lot more functionality that people care a great deal about.  If you can
> find the right VCS to use that 90% of people are content with (and I think
> Sourceforge started there), I think your resources are much better put
> into adding other features than adding more VCS support.
>
> I have no interest in ever using bzr again, but I strongly suspect
> Launchpad got a lot farther and does a lot more because the choice was
> made to only support bzr.  Now, of course, they need to switch to Git, or
> at least support it, and that's going to be a ton of work, but I suspect
> the order in which they did that made for a better system in the long run
> than if they'd tried to support both bzar and Git (and Mercurial and the
> other ones that were looking viable) at the start.

When Launchpad started before bzr or git or hg existed - back in 2004
- we started with arch. When we started bzr as a project, (again,
before git or hg :)) we were doing it with lessons-learnt from arch,
and a clear picture about what we'd need from the web site. Our
intention then was to use repository conversions to get content into
Launchpad, rather than being polyglot - because polyglot implies a
raft of tradeoffs.

In hindsight, what that strategy actually did was make high fidelity
incremental imports a key success factor, and that has itself a raft
of tradeoffs - so we spent a huge chunk of effort on that (and its
there and working) - but I think now that taking a federated approach
for the non-hosting needs (read from X systems directly for building
etc) would have been a lot faster to deliver, and would have allowed
more of the VCS work to focus on hosting needs rather than conversion
needs - conversions could be scaled out amongst users wanting to use
the platform, rather than the platforms developers.

OTOH a chunk of the planned features around VCS driven builds were
tightly coupled on understanding branches within the VCS and triggers
on changes etc - but all of those could have been only supplied for
hosted branches, with a low code complexity cost.

Actively supporting hosting of multiple VCSs would have been a huge
distraction in 2005 when the explosion happened. Supporting a VCS for
hosting isn't as simple as just parsing the output of $tool log. Users
need support. They need documentation and assistance. Creating
repositories needs to ask what VCS type to use in addition to any
other questions needed, all such questions tend to decrease the % of
users that get through the become-a-user funnel. You need backup glue
that works with [whatever] mechanism the VCS has to deliver atomic
commits. You need a scale-out strategy that is suitable for the VCS in
question. You need a user model that works for that VCS (and some are
radically different to others) - darcs was very visible at the time we
started, for one of the most different-to-mainline-VCS models.

Lastly at that stage LP was not yet open source, so it simply wasn't
possible for possible users to scratch their own itch and submit
patches - and thus when assessing strategy we assumed we'd have to
write everything, so supporting two systems really need to get twice
as much utility for Ubuntu developers (the primary audience then) -
but Ubuntu had already decided to standardise on a single VCS, as part
of the basic design of the tooling, there was no expectation of
increased utility.

-Rob


> --
> Russ Allbery (r...@debian.org)   
>
>
> --
> 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/871tjj5lle@hope.eyrie.org
>



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.

Re: GitHub “pull request” is useful and can be easily integrated'’

[Ben Finney]

Neil Williams  writes:

> On Sat, 18 Apr 2015 17:55:17 +1000
> Ben Finney  wrote:
>
> > GitHub's pull request feature is proprietary to GitHub, it can only
> > work between repositories hosted inside the GitHub silo, and any
> > project using that feature is thereby locking its workflow to the
> > single-vendor GitHub service.
>
> Not true. Simply and completely untrue.
>
> The pull request exists on github, fine.

How can a collaborator Alice, with no GitHub account, get the pull
request?

> I can either choose to manually pick that out of the github interface

I don't know what this means. How does that interact with the repository
a collaborator Alice, with no GitHub account, is using with standard
Git?

> or I can choose to use my github account to merge that pull request
> into a local branch.

So this option supports my point that the GitHub pull request is siloed,
and one must have an account with the single vendor in order to access
it.

> > Git repositories outside GitHub cannot interact with the GitHub pull
> > request workflow using Git's own features.
>
> Untrue. I use github and git.linaro.org side by side and have applied
> github pull requests as reviews on review.linaro.org

How does a person Bob, using their GitHub repository, send a pull
request to Carol using only their ‘review.linaro.org’ repository?

Does Carol need a GitHub account and repository hosted at GitHub? If so,
that's the point I'm making: GitHub's pull request can only be received
and handled by another GitHub repository.

> > They have chosen (or have never been aware they made the choice) to
> > make it much harder to interact with them using the existing,
> > standard, federated Git ‘request-pull’ feature, instead opting to
> > exclude anyone who doesn't want an account on a specific vendor's
> > service.
>
> Sorry, that makes no sense. Working with github as a second remote is
> trivial. 

How does a collaborator Alice, with no GitHub account, access Bob's
repository on GitHub and use the standard ‘git-request-pull’ to make a
pull request to Bob? How does this interact with the GitHub pull request
feature?

How does Bob make a pull request to Alice, using GitHub's pull request
feature, such that Alice can handle it using standard Git?

Your descriptions so far seem to support the position that Git
‘request-pull’ is equal for all peers, is incompatible with a
workflow based on GitHub pull requests, and that GitHub pull requests
cannot be received and handled using standard Git commands.

My point is to refute the notion that GitHub pull requests are open and
equal for all peer repositories. Please show specifically where I'm
wrong on that.

-- 
 \“Don't worry about people stealing your ideas. If your ideas |
  `\ are any good, you'll have to ram them down people's throats.” |
_o__)—Howard Aiken |
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/85wq18pk5q@benfinney.id.au

Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull’ (was: debian github organization ?)

[Stefano Zacchiroli]

On Sun, Apr 19, 2015 at 12:13:32PM +0800, Paul Wise wrote:
> To those of you who are willing to use github for Debian related
> things, it would be great if you could:
> 
> Mirror the repositories to alioth so Debian has a backup.

I'd rather see it the other way around: advertise the alioth Git repo as
the main one (e.g., in Vcs-* fields), and mirror it to GitHub for people
who want to contribute via GitHub's pull requests.

> Also accept contributions via email or git request-pull.

AOL.

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: debian github organization ?

[Robert Collins]

On 18 April 2015 at 08:03, Ben Finney  wrote:
> Paul Tagliamonte  writes:
>
>> So, yes, it's nonfree. Yes, it's controlled by DDs. No, I don't think
>> this should be the Vcs-Git: target. No, I don't think we should
>> endorse GitHub. Yes, we need free tools. Yes, we should contribute to
>> the F/OSS community where upstreams are.
>
> That last part seems to deny the D in DVCS. Why are we under such
> pressure to use one particular centralised service?

It doesn't deny it at all. Writing code is inherently distributed -
folk do it on their local machines. Other artifacts of software
development, like this mailing list and the Debian BTS, are inherently
centralised: they are discussions between actors, not local output.

> Upstream is using a decentralised VCS, it seems a little condescending
> to assume they are incapable of using it.

As has already been said, noone is making that assumption. For all
intents and purposes every upstream has made a decision about code
review and patch acceptance processes[*] and patches that don't follow
those processes incur a higher cost and increased likely hood of being
ignored. Those processes end up something like this:
 - your patch should apply to branch X in repo Y before you send it.
 - put your patches in place Z for us to find them [e.g gerrit at url
U, PR's at url U, mailing list x-...@example.com]...
 - we'll discuss the patch using tool T

Absolutely none of those three things are distributed in nature. They
can be worked with with distributed tooling, but that is beside the
point - to work with upstream U, requires *working with upstream U*,
whatever their tooling is, wherever they are to be found. That is in
fact exactly what upstream means. Of course, some upstreams don't
document the process super-well, and some are more restrictive than
others (e.g. hg won't accept patches in their bug database - patches
have to go to the list). But there is a process, and its tuned for the
bottleneck that that project has.

To pick a specific example, if you want to get a patch into OpenStack
you *must*:
 - sign up for the OpenStack gerrit system
 - sign a CLA
 - put your patch into git and push it into gerrit

Anything else simply won't be accepted.

*: A very very small number say 'any patch anywhere, we'll handle the
rest', or something similar.


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud


-- 
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/CAJ3HoZ0yS=gteouknvpsr9c_tsekk2rufyvvcgmqq74a6e_...@mail.gmail.com

Re: GitHub “pull request” is useful and can be easily integrated'’

[Robert Collins]

On 19 April 2015 at 21:00, Ben Finney  wrote:
> Neil Williams  writes:
>
>> On Sat, 18 Apr 2015 17:55:17 +1000
>> Ben Finney  wrote:
>>
>> > GitHub's pull request feature is proprietary to GitHub, it can only
>> > work between repositories hosted inside the GitHub silo, and any
>> > project using that feature is thereby locking its workflow to the
>> > single-vendor GitHub service.
>>
>> Not true. Simply and completely untrue.
>>
>> The pull request exists on github, fine.
>
> How can a collaborator Alice, with no GitHub account, get the pull
> request?

For the metadata:
 - Via the web UI or HTTP API.
For the repository:
 - via git over https://

[Unless the host organisation has paid for private repos of course...
but thats exactly the same as Debian security embargoed patches: a
collaborator cannot get those patches without an account.]

>> I can either choose to manually pick that out of the github interface
>
> I don't know what this means. How does that interact with the repository
> a collaborator Alice, with no GitHub account, is using with standard
> Git?

The person that create the PR did so by pushing a git branch to a git
repo. So the interaction is 'its a git remote'.

>> or I can choose to use my github account to merge that pull request
>> into a local branch.
>
> So this option supports my point that the GitHub pull request is siloed,
> and one must have an account with the single vendor in order to access
> it.

No it doesn't. The thing you didn't know what it meant, which I've
explained above, contradicts your assertion.

>> > Git repositories outside GitHub cannot interact with the GitHub pull
>> > request workflow using Git's own features.
>>
>> Untrue. I use github and git.linaro.org side by side and have applied
>> github pull requests as reviews on review.linaro.org
>
> How does a person Bob, using their GitHub repository, send a pull
> request to Carol using only their ‘review.linaro.org’ repository?

review.linaro.org is gerrit. So git push to the magic gerrit repo on
review.linaro.org the branch pulled down from github.

> Does Carol need a GitHub account and repository hosted at GitHub? If so,
> that's the point I'm making: GitHub's pull request can only be received
> and handled by another GitHub repository.

No. The metadata will remain where it was of course (on github) - its
not part of the git history. And this is exactly the same as for a
patch up in the Debian BTS.

>> > They have chosen (or have never been aware they made the choice) to
>> > make it much harder to interact with them using the existing,
>> > standard, federated Git ‘request-pull’ feature, instead opting to
>> > exclude anyone who doesn't want an account on a specific vendor's
>> > service.
>>
>> Sorry, that makes no sense. Working with github as a second remote is
>> trivial.
>
> How does a collaborator Alice, with no GitHub account, access Bob's
> repository on GitHub and use the standard ‘git-request-pull’ to make a
> pull request to Bob? How does this interact with the GitHub pull request
> feature?

I don't know of anyone using git-request-pull. I presume Linux uses
it, but does anyone else?

> How does Bob make a pull request to Alice, using GitHub's pull request
> feature, such that Alice can handle it using standard Git?

All PR's can be handled using standard git.

> Your descriptions so far seem to support the position that Git
> ‘request-pull’ is equal for all peers, is incompatible with a
> workflow based on GitHub pull requests, and that GitHub pull requests
> cannot be received and handled using standard Git commands.

git request-pull doesn't send anything to anybody: it is simply a
template email specifying where a repository is and what branch to
merge. Thats not a code review system, its *at most* the start of one.
Its also not a standard (unlike git-format-patch [1] which is - its
output is machine readable and intended to be consumed directly). Some
projects would accept git request-pull as a way of submitting a patch
- but only some [specifically those where code review is on a mailing
list && they aren't using http://jk.ozlabs.org/projects/patchwork/ or
similar - or they have one and only one committer and you're talking
directly to them every time].

git request-pull is thus inapplicable to many projects, since it won't
meet their needs. Similar GitHub PR's don't meet all projects needs,
so many projects don't use them.

> My point is to refute the notion that GitHub pull requests are open and
> equal for all peer repositories. Please show specifically where I'm
> wrong on that.

They are open - documented API, documented schema (we've had this
debate before!), except for private repositories, code stored in bog
standard git repos anyone can access.

So far, you haven't made your case at all AFAICT. Have you used
github? If not you should: the best position to critique a system from
is one of familiarity.

-Rob

1] https://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html

linking perl statically against libperl

[Niko Tyni]

Hi,

I'd like to start linking /usr/bin/perl statically against libperl on
all architectures instead of just on *i386 like now. See #781476
for some more details. I'm looking for input on this.

Pros:
A we can treat all architectures the same way -> simpler packaging
B slightly improved performance (4%-15% depending on the architecture)
C removes the current kludge where libperl.5.20.so is bundled
  with perl-base on !i386 and the shlibs lie
D makes sure perl-base (which is Essential:yes) stays robust

Cons:
E increased memory usage on systems running multiple perl processes
F possibly increased startup time for short perl scripts
  (but that may be a non-issue due to caching anyway?)

I'd very much like to achieve A and C while keeping D. An alternative
would be to take the performance hit on *i386 too and link libperl in
dynamically on all architectures, but move libperl.5.20.so into the
libperl5.20 package and make perl-base Pre-Depend on that. Presumably
this should work too, but it does make perl-base dependencies a bit
more complex.

I note that this would match what python is doing AFAICS, so I
suppose the memory usage concerns aren't that critical?
-- 
Niko Tyni   nt...@debian.org


-- 
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/20150419084309.GA12055@estella.local.invalid

Re: Bits from the dpkg project: 1.17.x series, general news

[Didier 'OdyX' Raboud]

Le dimanche, 19 avril 2015, 10.25:11 Cyril Brulebois a écrit :
> Thanks so much for all the hard (and not only technical) work,
> Raphaël!

Indeed, thank you buxy!

OdyX

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

Re: Bits from the dpkg project: 1.17.x series, general news

[Eduard Bloch]

Hallo,
* Guillem Jover [Sat, Apr 18 2015, 09:27:26PM]:

> * Add support for versioned Provides [!]:
>   - Packages can provide a specific version, “virtual (= 1.0)” which will
> be honored, previously it would just be accepted when parsing.

That's great news! This will make a lot of evil kludges obsolete RSN.

And: thanks, buxy!

Regards,
Eduard.


-- 
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/20150419112450.ga27...@rotes76.wohnheim.uni-kl.de

Re: linking perl statically against libperl

[Axel Beckert]

Hi,

Niko Tyni wrote:
> Cons:
> E increased memory usage on systems running multiple perl processes
> F possibly increased startup time for short perl scripts
>   (but that may be a non-issue due to caching anyway?)

This sounds rather concerning to me. The again, I've never noticed any
issues on i386 and kfreebsd-i386.

Since you wrote in #781476 that both, statically and dynamically
linked perl binaries are built anyways and then one is thrown away
depending on the architecture, what about letting the user
respectively administrator choose?

Either by

* shipping both in the perl package and using /etc/alternatives/perl
  to choose between the two (perl-dynamic and perl-static) for
  /usr/bin/perl, or

* by providing two conflicting packages perl-base and
  perl-base-static.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


-- 
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/20150419122554.gs5...@sym.noone.org

Re: MBF: build Python 3 modules for packages that support it upstream

[Julien Cristau]

On Fri, Apr 17, 2015 at 15:47:16 -0400, Paul Tagliamonte wrote:

> On Thu, Apr 16, 2015 at 06:50:11PM -0400, Paul Tagliamonte wrote:
> > I'll curate the raw run I did today, since I saw a few false positive
> > (python 3 backports to python 3) and file them. I'll run a dd-list at
> > some point before the file.
> > 
> > Severity will be wishlist. Target is the next release / sid after Jessie
> > release.
> 
> Since I've got no one complaining, I'm going to go ahead and file these
> under the usertag patchme-python3, wishlist, and with a note it's for
> after jessie releases. I'll compile a dd-list and run through it before
> the filing.
> 
You might want to give people more than 24 hours to comment.  A week
seems like the bare minimum to me.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: dose3 support for versioned provides (was: Re: Bits from the dpkg project: 1.17.x series, general news)

[Joachim Breitner]

Hi,

Am Samstag, den 18.04.2015, 23:54 +0200 schrieb Johannes Schauer:
> for source packages that require versioned virtual packages, dose3 support for
> this is needed because otherwise the affected source packages will remain
> bd-uninstallable.  But right now dose3 can only parse versioned provides but
> does not treat them correctly yet.  This is this bug:
> 
> https://gforge.inria.fr/tracker/index.php?func=detail&aid=17556&group_id=4395&atid=13808

Thanks.

> Since the build infrastructure runs stable, it might be tricky to be able to
> upload source packages relying on versioned virtual packages before the next
> stable release (assuming this dose3 bug is fixed during the next release
> cycle).

I hope that in such cases, we can have the fixed programs in
jessie-backports and installed from there?

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: debian github organization ?

[Vincent Bernat]

 ❦ 19 avril 2015 08:55 GMT, Brian May  :

> I suspect not many people know about this however (did I miss an
> announcement from github on this?), and I suspect it may not be
> possible to make changes to the pull request without write access to
> the branch.

Yes, that's not possible.

> Unlike with gerrit, where I believe is possible to other people to
> post improved versions of the patch.

People can still clone the branch and do their own PR, referencing the
original one.
-- 
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: GitHub “pull request” is useful and can be easily integrated'’

[Vincent Bernat]

 ❦ 19 avril 2015 19:00 +1000, Ben Finney  :

>> The pull request exists on github, fine.
>
> How can a collaborator Alice, with no GitHub account, get the pull
> request?

Take a random PR:
 https://github.com/twbs/bootstrap/pull/16258

Append ".patch" to get the patch:
 curl https://github.com/twbs/bootstrap/pull/16258.patch | git am

Or you can also directly pull the URL:
 git fetch origin refs/pull/16258/head:pr/16258
 git checkout pr/16258

Or as one operation:
 git pull https://github.com/twbs/bootstrap refs/pull/16258/head:pr/16258

No GitHub account required.
-- 
The very ink with which all history is written is merely fluid prejudice.
-- Mark Twain


signature.asc
Description: PGP signature

Re: GitHub “pull request” is useful and can be easily integrated'’

[Neil Williams]

On Sun, 19 Apr 2015 19:00:33 +1000
Ben Finney  wrote:

> Neil Williams  writes:
> 
> > On Sat, 18 Apr 2015 17:55:17 +1000
> > Ben Finney  wrote:
> >
> > > GitHub's pull request feature is proprietary to GitHub, it can
> > > only work between repositories hosted inside the GitHub silo, and
> > > any project using that feature is thereby locking its workflow to
> > > the single-vendor GitHub service.
> >
> > Not true. Simply and completely untrue.
> >
> > The pull request exists on github, fine.
> 
> How can a collaborator Alice, with no GitHub account, get the pull
> request?

Public github repositories do not need a github account to clone.

Accounts are only needed for writes and if github is just one of many
remotes, then as long as one person in the team has write access to
each remote that the team supports, then every remote is equal and can
be updated when the team decides to push. Just like every other git
repo out there. Anyone enabling anonymous write to a git repo would be
insane and private git repos are outside the scope of this discussion
by definition.

The rest of this has already been answered by Rob and Vincent.

> > Sorry, that makes no sense. Working with github as a second remote
> > is trivial. 
> 
> How does a collaborator Alice, with no GitHub account, access Bob's
> repository on GitHub and use the standard ‘git-request-pull’ to make a
> pull request to Bob? How does this interact with the GitHub pull
> request feature?

TBH I've never used or been asked to even consider using
git-request-pull for any of the free software work I've done on any
project using git.

> Your descriptions so far seem to support the position that Git
> ‘request-pull’ is equal for all peers, is incompatible with a
> workflow based on GitHub pull requests, and that GitHub pull requests
> cannot be received and handled using standard Git commands.

git-request-pull appears to be something which a few people are hung-up
on and which others simply don't need to use, but as long as it uses
standard git commands in the same way as any other git remote setup on
any particular git clone, it would be 100% compatible with all
workflows similarly based on standard git operations - explicitly
including github pull requests and gerrit and a raft of other options.

Github pull requests absolutely can be received and handled using
standard git commands and with a (default) public repo, anyone can
access them, no accounts necessary.

> My point is to refute the notion that GitHub pull requests are open
> and equal for all peer repositories. Please show specifically where
> I'm wrong on that.

You are specifically wrong on everything on that. There is no basis for
your opposition. If git-request-pull has some kind of problem, then I
would suggest that is a bug in git-request-pull because "standard git"
works fine with github and all the other remotes I use, so should
git-request-pull - I've just never needed it.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgp3OBdRKei8e.pgp
Description: OpenPGP digital signature

Re: [py3porters-devel] MBF: build Python 3 modules for packages that support it upstream

[Sandro Tosi]

basemap
uploaded to experimental, waiting for NEW
https://ftp-master.debian.org/new/basemap_1.0.7%2Bdfsg-2.html

Cheers,
Sandro

On Fri, Apr 17, 2015 at 8:07 PM, Paul Tagliamonte  wrote:
> On Thu, Apr 16, 2015 at 06:50:11PM -0400, Paul Tagliamonte wrote:
>> Severity will be wishlist. Target is the next release / sid after Jessie
>> release.
>
>
> Draft text and dd-list attached. Please let me know of any false
> positives if you see them.
>
> I'll start filing tomorow night.
>
> Cheers,
>   Paul
>
> --
>  .''`.  Paul Tagliamonte   |   Proud Debian Developer
> : :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
> `. `'`  http://people.debian.org/~paultag
>  `- http://people.debian.org/~paultag/conduct-statement.txt
>
> ___
> py3porters-devel mailing list
> py3porters-de...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/py3porters-devel
>



-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
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/cab4xwxwpzfng0xdpot5jp9bgpfj1hdre-ptuepjizk_jn+a...@mail.gmail.com

Re: debian github organization ?

[Neil Williams]

On Sun, 19 Apr 2015 21:12:57 +1200
Robert Collins  wrote:

> On 18 April 2015 at 08:03, Ben Finney 
> wrote:
> > Paul Tagliamonte  writes:
> >
> >> So, yes, it's nonfree. Yes, it's controlled by DDs. No, I don't
> >> think this should be the Vcs-Git: target. No, I don't think we
> >> should endorse GitHub. Yes, we need free tools. Yes, we should
> >> contribute to the F/OSS community where upstreams are.

> To pick a specific example, if you want to get a patch into OpenStack
> you *must*:
>  - sign up for the OpenStack gerrit system
>  - sign a CLA
>  - put your patch into git and push it into gerrit
> 
> Anything else simply won't be accepted.

Indeed, this is precisely why - in Linaro - we chose to push LAVA
upstream repos to github as mirrors just so that contributors did not
need to register for a Linaro account but could use an existing github
account. We've already received useful contributions via github and so
support will continue. Those who choose to or who make regular
contributions are, of course, welcome to register for a Linaro
community account and submit directly to review.linaro.org, the gerrit
instance for Linaro. An account isn't a big deal but as there is a
trivial way of allowing contributions without it, we thought it would
be daft not to use github as an upstream mirror - I don't even need to
explicitly push to it. We were asked to do it by github users, we are
happy to oblige as the setup is trivial and it "just works".

(So I'm in Linaro and Debian organisations now on github. Yay!)

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgp92vtlLHcr9.pgp
Description: OpenPGP digital signature

Re: Work-needing packages report for Mar 27, 2015

[Geert Stappers]

On Tue, Mar 31, 2015 at 03:02:40PM +0200, Fabian Greffrath wrote:
> Am Dienstag, den 31.03.2015, 12:34 +0200 schrieb Jeroen Dekkers: 
> 
> > Dropping packages that need help from the help-wanted list doesn't
> > solve any problem, it only hides problems and makes it even less
> > likely that packages that need help get help. And removing from
> > testing isn't an option for packages for which no alternative exists
> > such as grub.
> 
> I see that this won't help, but I have two other suggestions that I hope
> are not too far-fetched but would IMHO help to improve the usefullness
> of this list:
> 
> 1) Provide actual hyperlinks to the bugs in which help is requested --
> in place, in this list, right next to the package name and bug number. 

So in the source code there is allready a variable which
contains the bugreportnumber, BRN.

And the requested / proposed  improvement would be printing
an extraline which contains http://bugs.debian.org/BRN

> Merely providing bug numbers doesn't help very much and means a lot of
> copy&pasting for a potential contributor. At the end of the list the
> link to https://www.debian.org/devel/wnpp/help_requested is given, but
> following that means you have to go through the entire list again to
> find your package of interest.


Okay, as the mantra says: Patches welcome


The quest begins

Header of the original e-mail contains:  X-Mailer: maintainers-needed.pl

A websearch on that file brought me to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562109

Need to dig deeper

Found 
http://anonscm.debian.org/viewvc/qa/trunk/data/wnpp/maintainers-needed.pl?view=markup

wget -O maintainers-needed.download 
'http://anonscm.debian.org/viewvc/qa/trunk/data/wnpp/maintainers-needed.pl?revision=2956&view=co'

cp maintainers-needed.download maintainers-needed.pl

(The actual coding work)

Ta ta the patch:

--- maintainers-needed.download 2015-04-19 14:52:59.132447756 +0200
+++ maintainers-needed.pl   2015-04-19 15:21:59.792408917 +0200
@@ -362,6 +362,8 @@
 if (my $p = $popcon{"p:$pkg"}) {
 print NFM fmt("Installations reported by Popcon: $p", 72, " "x5), "\n";
 }
+print NFM
+fmt("Bug Report URL: http://bugs.debian.org/"; . $pkginfo{$pkg}{id}, 
72, " "x5), "\n";
 }
 }
 

@wnpp people: please review the above patch



> 2) Maybe it could be possible to tag the bugs with some keywords which
> indicate the type of support that is requested.
> 
> >From the mere bug list I cannot see if the package in question needs
> help with bug triaging, porting issues, documentation, l10n/i18n,
> general packaging or whatever. Probably contributors are not going to
> read through several dozen bug reports to get an idea of *what* they
> could actually do to help in the first place.
> 
> Such keywords could get implemented by means of user-tags and the tags
> get added to the WNPP list right next to the bug number.

Patches welcome

wget -O maintainers-needed.download 
'http://anonscm.debian.org/viewvc/qa/trunk/data/wnpp/maintainers-needed.pl?view=co'
cp -p maintainers-needed.download maintainers-needed.pl
chmod a+x maintainers-needed.pl
./maintainers-needed.pl# see that it is working  # indeed no special 
privelegde required
$EDITOR maintainers-needed.pl
# the actual coding work
./maintainers-needed.pl# see that it is working  # indeed no special 
privelegde required
diff -u  maintainers-needed.download maintainers-needed.pl  > wnppusertags.patch
# e-mail the patch to w...@debian.org


> As an example, this way, contributors could see at first glance that
> e.g. package "munin" requests assistance for "bug-traging" and
> "patch-forwarding" in #655889.

Visiting  http://bugs.debian.org/655889  didn't reveal any usertags yet to me.


> Cheers,
> Fabian

Thanks for sharing the idea.


Groeten
Geert Stappers
-- 
Leven en laten leven


-- 
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/20150419134803.gd23...@gpm.stappers.nl

Re: GitHub “pull request” is useful and can be easily integrated'’

[Ben Finney]

Neil Williams  writes:

> On Sun, 19 Apr 2015 19:00:33 +1000
> Ben Finney  wrote:
>
> > How can a collaborator Alice, with no GitHub account, get the pull
> > request?
>
> Public github repositories do not need a github account to clone.

This is quite frustrating. There's some serious equivocating by GitHub
apologists in this discussion:

* Raising the topic of competing repository hosting services, reliably
  leads to insistence that GitHub provides special, GitHub-only features
  that make it much more (implicitly, better) than a mere Git repo
  hosting service.

* Raising the topic of GitHub's features that aren't standard Git
  protocol, reliably leads to dismissal of all those proprietary GitHub
  features as being irrelevant since of course we can all clone a repo
  from the service.

We're told that GitHub has a raft of features that make it superior,
until it's pointed out that those features are GitHub-specific and
incompatible with collaborators from outside; then, conveniently, the
specialness of those features dwindles to insignificance because we can
access the repo's commits.


In this instance, I've been talking about a GitHub proprietary feature,
incompatible with Git: the GitHub pull request. In response, the non
sequitur of “anyone can clone a GitHub repo” is raised as though it were
relevant.

Yes, Alice can clone the repo. So what? That doesn't allow Alice as an
external party to collaborate in the GitHub pull request on Bob's repo.
The pull request remains siloed within GitHub, accesible only via a
GitHub account Alice doesn't have and doesn't want.

Likewise, as an external party Alice can collaborate via ‘git
send-email’ or ‘git request-pull’ on an equal footing with any other
repo (including GitHub repos). But Bob, having chosen GitHub's
proprietary pull requests as an essential part of his workflow, has
thereby chosen to silo his repo such that Alice can't collaborate as a
peer from outside GitHub.


> > How does a collaborator Alice, with no GitHub account, access Bob's
> > repository on GitHub and use the standard ‘git-request-pull’ to make
> > a pull request to Bob? How does this interact with the GitHub pull
> > request feature?
>
> TBH I've never used or been asked to even consider using
> git-request-pull for any of the free software work I've done on any
> project using git.

Thanks. Everything I've read trying to find a way to make that possible
points to the conclusion it can't be done: Alice can't send a Git pull
request from outside GitHub and have it fit the GitHub pull request
workflow. GitHub's pull request workflow only works for GitHub repos.

> Github pull requests absolutely can be received and handled using
> standard git commands and with a (default) public repo, anyone can
> access them, no accounts necessary.

As far as I can tell, the only sense that can be true is if you ignore
everything about GitHub pull request that actually makes it a GitHub
pull request (as opposed to just a bunch of commits in a repo).


I don't object to people using tools they find convenient. I object to
those tools having detrimental effects on collaboration, on the
distributed nature of the protocols we use to collaborate.

I object to being told that a service is open when it isn't. I object to
being told features are simultaneously unique to a service and not
unique to that service.

Robert Collins  writes:

> Have you used github? If not you should: the best position to critique
> a system from is one of familiarity.

If I were to critique only the effects GitHub has for the individual who
uses it, that would be a valid point. As it is, I'm criticising the
effects GitHub has on a community *including people who don't use it*.

I object to implications that criticism of GitHub's effects, on
collaboration with peers who don't use GitHub, can be dismissed
precisely because that person doesn't use GitHub.

If a case were to be formed to argue GitHub is a monoculture pressuring
outsiders to conform, that's a good way to do it.

-- 
 \  “The most common way people give up their power is by thinking |
  `\   they don't have any.” —Alice Walker |
_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/85lhhop5fc@benfinney.id.au

Re: Bits from the dpkg project: 1.17.x series, general news

[Thomas Preud'homme]

Le dimanche 19 avril 2015, 12:25:28 Didier 'OdyX' Raboud a écrit :
> Le dimanche, 19 avril 2015, 10.25:11 Cyril Brulebois a écrit :
> > Thanks so much for all the hard (and not only technical) work,
> > Raphaël!
> 
> Indeed, thank you buxy!
> 
> OdyX

+1. Thanks a lot Raphaël.

Cheers,

Thomas

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

Re: Bits from the dpkg project: 1.17.x series, general news

[Lisandro Damián Nicanor Pérez Meyer]

*Thanks* :)

-- 
“I don’t think security can solve problems.
We need to teach greater respect.”
  Oslo Mayor Stang when asked whether Oslo needs greater security
  after the attacks in Norway, 07/2011.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: GitHub “pull request” is useful and can be easily integrated'’

[Vincent Bernat]

 ❦ 20 avril 2015 00:18 +1000, Ben Finney  :

> Likewise, as an external party Alice can collaborate via ‘git
> send-email’ or ‘git request-pull’ on an equal footing with any other
> repo (including GitHub repos). But Bob, having chosen GitHub's
> proprietary pull requests as an essential part of his workflow, has
> thereby chosen to silo his repo such that Alice can't collaborate as a
> peer from outside GitHub.

Well, Bob may be open to receive contributions by email as well. It is
his choice and hardly relevant with the proprietary nature of GitHub. If
Bob chosed its own Gerrit installation, Alice would need to create an
account on this Gerrit system. Maybe Alice would prefer to create
accounts on random small systems or maybe Alice don't like to create
accounts at all.

Many people having a GitHub account, it is easier to contribute to a
project hosted on GitHub. As an open source project, you need to choose
between using only an open infrastructure and missing a few contributors
not willing to create a specific account on this open infrastructure or
choose something like GitHub.
-- 
Let the machine do the dirty work.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

[David Kalnischkies]

On Sat, Apr 04, 2015 at 10:54:09AM +0200, Niels Thykier wrote:
> The resulting debs are installable with dpkg -i ( \o/ ).  I have not
> tried anything fancy like setting up a local APT mirror and tried to
> convince APT do install it.

I did and apt works with ddeb just fine, meaning it can happily
print infos about them, download them and install them with dpkg.

There are two exceptions as far as I can see:
- apt-ftparchive doesn't know about '.ddeb', so by default neither
  Contents nor Packages files created by it contain information about
  them. Users of "apt-ftparchive contents/packages" are (surprisingly)
  out of luck as far as I can see and have to wait for a patch (= 2
  lines), but users of "apt-ftparchive generate" can configure the used
  extension, see apt-ftparchive manpage on how to do that.

  Debian uses dak to create the archive, so that isn't a problem per-se.
  I would presume most derivatives aren't using it either as
  alternatives are plenty.  Those who do are very likely using generate
  as its just strictly better than manually creating Packages files with
  'apt-ftparchive packages'. I guess most repository creators have this
  or similar problems and solutions through and that doesn't seem like
  all to important for the adoption.

- apt/experimental supports installing local .deb files. That doesn't
  support the '.ddeb' extension yet.

  I leave it up to the reader to figure out how much of a dealbreaker
  that is…


So, super-cow approves (d)debs.
(In fact, apt-dbg never became a thing as automatic ddebs were always
 "very soon now" in existence every time it came up. This time please…)
And it especially approves the debhelper branch name. ;)


I think there will be some work upon us to make ddebs supported well
(I invision something like a "apt-get debugsymbols foo" which installs
the package foo-dbgsym and maybe optionally also the debug packages of
the direct dependencies libfoo1 (libfoo-dbgsym) and libbar0.1
(python3-bar-dbgsym as it is the c-binding of a python library as you
might (not) have guessed).) but lets get them first, shall we? :)


btw: Is it planed to drop them into their own repository/component or
are we gone blow up our regular Packages files with them? (you might
guess from the wording which way I would prefer).


Best regards

David Kalnischkies


signature.asc
Description: Digital signature

Re: GitHub “pull request” is useful and can be easily integrated'’

[Russ Allbery]

Ben Finney  writes:

> We're told that GitHub has a raft of features that make it superior,
> until it's pointed out that those features are GitHub-specific and
> incompatible with collaborators from outside; then, conveniently, the
> specialness of those features dwindles to insignificance because we can
> access the repo's commits.

It's a UI.  The UI is really nice.  That's why people use it.  But lock-in
implies more than a really nice UI that people use because it's superior.
Lock-in implies something you're trapped into using even when it's
*inferior*, and that's what people are taking issue with.

For better or for ill, people use GitHub because it's *a really good
product*, not because of some sort of nefarious lock-in strategy that
holds people's data captive.  The data that's to some extent captive in
GitHub (like issues) are not really a strong point for GitHub.  There are
a lot of better issue trackers out there.  (Like *cough* Atlassian, which
is a much different conversation.)

The repositories and Git management are the very nice features of GitHub,
and there's nothing there data-wise you can't pretty trivially extract.
It's just a very nice UI.

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


-- 
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/87lhhot4ey@hope.eyrie.org

Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull’

[Russ Allbery]

Stefano Zacchiroli  writes:
> On Sun, Apr 19, 2015 at 12:13:32PM +0800, Paul Wise wrote:

>> To those of you who are willing to use github for Debian related
>> things, it would be great if you could:

>> Mirror the repositories to alioth so Debian has a backup.

> I'd rather see it the other way around: advertise the alioth Git repo as
> the main one (e.g., in Vcs-* fields), and mirror it to GitHub for people
> who want to contribute via GitHub's pull requests.

I mirror the repositories on my own publicly-accessible Git server.
Hopefully that's good enough.  :)

>> Also accept contributions via email or git request-pull.

> AOL.

Oh, certainly.  (Well, like Neil, I've never heard of git request-pull
before this thread and have never seen anyone use it, but if someone did,
it would be an interesting learning opportunity.)

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


-- 
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/87h9sct4cb@hope.eyrie.org

Re: GitHub “pull request” is useful and can be easily integrated'’

[James McCoy]

On Sun, Apr 19, 2015 at 10:27:01AM -0700, Russ Allbery wrote:
> The repositories and Git management are the very nice features of GitHub,
> and there's nothing there data-wise you can't pretty trivially extract.
> It's just a very nice UI.

In fact, joeyh wrote a nice tool[0] that will extract all the data that
can be extracted and put it into your git repository.

[0]: https://joeyh.name/code/github-backup/

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


signature.asc
Description: Digital signature

Re: MBF: build Python 3 modules for packages that support it upstream

[Paul Tagliamonte]

On Sun, Apr 19, 2015 at 02:41:47PM +0200, Julien Cristau wrote:
> You might want to give people more than 24 hours to comment.  A week
> seems like the bare minimum to me.
> 
> Cheers,
> Julien

Euch, sorry, I filed them this morning, but it was only like 40 or so
packages, a chunk of which are DPMT.

Sorry for doing this without waiting enough, I just wanted to get them
tracked, and I figured these were all kinda no-brainers.

Sorry if it's bothering anyone, I'd be happy to talk more about the
ongoing efforts here.

Cheers,
  Paul



-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: Debian Installer Jessie RC 3 release

[Martin Zobel-Helas]

Hi, 

On Sun Apr 19, 2015 at 16:25:30 +0200, Cyril Brulebois wrote:
> Improvements in this release of the installer
> =
> 
>  * apt-setup:
> - Stop enabling backports by default (#764982).

(i have read the BR)

I consider this this 'last minute' change as affront against the
backports eam. I have not seen any discussion for this on the backports
mailing list.

Can you please explain why you are doing thins now instead of earlier
releases? This BR has been open since October! Also i expect mininal
changes in an RC3, not such massive functional changes.

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 


-- 
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/20150419194418.gf17...@ftbfs.de

Bug#782968: ITP: libmuscle -- multiple alignment library for protein sequences

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: libmuscle
  Version : 3.7
  Upstream Author : Aaron Darling 
* URL : http://sourceforge.net/p/mauve/code/HEAD/tree/muscle/
* License : Public domain
  Programming Lang: C++
  Description : multiple alignment library for protein sequences
 MUSCLE is a multiple alignment program for protein sequences. MUSCLE
 stands for multiple sequence comparison by log-expectation. In the
 authors tests, MUSCLE achieved the highest scores of all tested
 programs on several alignment accuracy benchmarks, and is also one of
 the fastest programs out there.
 .
 This library was derived from the original MUSCLE and turned into
 a library.


Remark: This library is packaged as a precondition of the Mauve multiple
genome alignment package by the Debian Med team at

   git://anonscm.debian.org/debian-med/libmuscle.git


-- 
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/20150419194903.21628.53796.report...@mail.an3as.eu

Bug#782969: ITP: libmems -- library to support DNA string matching and comparative genomics

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: libmems
  Version : 1.6
  Upstream Author : Aaron Darling 
* URL : http://sourceforge.net/p/mauve/code/HEAD/tree/libMems/trunk/
* License : GPL
  Programming Lang: C++
  Description : library to support DNA string matching and comparative 
genomics
 libMems is a freely available software development library to support DNA
 string matching and comparative genomics. Among other things, libMems
 implements an algorithm to perform approximate multi-MUM and multi-MEM
 identification. The algorithm uses spaced seed patterns in conjunction
 with a seed-and-extend style hashing method to identify matches. The method
 is efficient, requiring a maximum of only 16 bytes per base of the largest
 input sequence, and this data can be stored externally (i.e. on disk) to
 further reduce memory requirements.


Remark; This library is packaged by the Debian Med team as a
precondition of the Mauve multiple genome alignment package at

git://anonscm.debian.org/debian-med/libmems.git


-- 
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/20150419195225.21795.63780.report...@mail.an3as.eu

Bug#782970: ITP: pysimplesoap -- Python simple and lightweight SOAP Library

[Jörg Frings-Fürst]

Package: wnpp
Severity: wishlist
Owner: "Jörg Frings-Fürst" 

* Package name: pysimplesoap
  Version : 1.16
  Upstream Author : Mariano Reingart 
* URL : http://code.google.com/p/pysimplesoap
* License : LGPL-3.0
  Programming Lang: Python
  Description : Python simple and lightweight SOAP Library

 Python simple and lightweigh SOAP library for client and server webservices
 interfaces, aimed to be as small and easy as possible, supporting most common
 functionality. Initially it was inspired by PHP Soap Extension (mimicking its
 functionality, simplicity and ease of use), with many advanced features added.

It is the only maintained SOAP package with py3k support, which is needed to
port python-debianbts (CCed Bastian) and then port reportbug to py3k.


-- 
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/20150419202209.31241.53364.report...@oracle.matrix.int

Re: GitHub “pull request” is useful and can be easily integrated'’

[Robert Collins]

On 20 April 2015 at 02:18, Ben Finney  wrote:
> Robert Collins  writes:
>
>> Have you used github? If not you should: the best position to critique
>> a system from is one of familiarity.
>
> If I were to critique only the effects GitHub has for the individual who
> uses it, that would be a valid point. As it is, I'm criticising the
> effects GitHub has on a community *including people who don't use it*.

Sure, but...

> I object to implications that criticism of GitHub's effects, on
> collaboration with peers who don't use GitHub, can be dismissed
> precisely because that person doesn't use GitHub.

For clarity, I made no such suggestion. However your critique has a
number of 'how does X work' questions which most users of Github could
answer. That makes your debate about Github seem uninformed, and
detracts from whatever your actual point is. (Simple by reducing the
signal:noise ratio of the debate).

> If a case were to be formed to argue GitHub is a monoculture pressuring
> outsiders to conform, that's a good way to do it.

If anyone had done that [discarded arguments because the person making
them isn't well informed], which they hadn't.

As to your point about community effects, I believe I addressed that
in the other thread when I pointed out that there is TTBOMK -no-
distributed solution that is working well for any community for peer
review - which is the specific feature {PR's} of Github that is under
debate.

If PR's are lock-in, so is the BTS (for Debian), Gerrit (for Gerrit
users), etc etc etc.

The challenge is social, not technical, and assessing it on technical
grounds misses the entire point. Communities have spaces to discuss
things in, and those spaces naturally end up restrictive - at least so
far - in that if you're working outside the space, even with the same
tools, you are not visible and become less relevant.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud


-- 
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/CAJ3HoZ1mp=hqucpqewgdshp-flec+2oy37nrnnqnu1pudpe...@mail.gmail.com

Debian Archive architecture removals

[Joerg Jaspert]

Hi,

As the jessie release approaches, the ftp-team have been reviewing the
status of the architectures in unstable.

Neither sparc nor hurd-i386 are going to release with jessie and we are
therefore looking at their future in unstable.


SPARC
=
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745938

Given the current lack of proper kernel support and the lack of upstream
toolchain support, we intend to remove sparc *at the latest*, three
months after the release of jessie. This could be avoided if there is a
team of Debian Developers putting in a serious effort to revive this
port, thus the 3 months timeframe. If this happens, please keep track in
an easy reviewable way, so we can recheck it before actual removal (for
example list of closed bugs, uploads, upstream patch work, ...).

It is noted that the sparc64 port is likely to be a more suitable basis
for any future SPARC work but that nobody has approached us about
inclusion.

hurd-i386
=
Well before wheezy was released, we talked with the HURD porters, and
they agreed to re-check their archive status just after the wheezy
release[1]. The plan was to move the HURD port off ftp-master if it
wasn't included as a technology preview or full release arch. HURD
wasn't a part of Wheezy, and it's highly unlikely it will be in Jessie.

We'll be removing HURD, as discussed, from the ftp-master archive after
the Jessie release.

[1] https://lists.debian.org/debian-hurd/2013/05/msg00018.html

-- 
bye, Joerg
Throw them away? Are you mad woman? You never know when an old calendar
may come in handy. Sure it’s not 1985 now, but who knows what tomorrow
might bring?


signature.asc
Description: PGP signature

Re: Bits from the dpkg project: 1.17.x series, general news

[Ben Finney]

Cyril Brulebois  writes:

> Guillem Jover  (2015-04-18):
> > General News
> > 
> > 
> > * Raphaël Hertzog has stepped down as maintainer.
>
> It seems a little sad there's not even a thanks or two, so here it is:
> Thanks so much for all the hard (and not only technical) work,
> Raphaël!

We are greatly indebted to Raphaël, and everyone involved in ‘dpkg’
development.

The upcoming improvements look awesome, it's wonderful there is so much
good stuff happening. Thank you buxy for getting us here!

-- 
 \ “How wonderful that we have met with a paradox. Now we have |
  `\some hope of making progress.” —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/85bnijpswi@benfinney.id.au

Re: GitHub “pull request” is useful and can be easily integrated'’

[Brian May]

On Mon, 20 Apr 2015 at 00:19 Ben Finney  wrote:

> This is quite frustrating. There's some serious equivocating by GitHub
> apologists in this discussion:


It GitHub better then the open source GitLab?

If the answer is Yes, is there any obstacles to trying to improve GitLab so
it does what we want?

If the answer is No, then why use GitHub? Shouldn't we have our own GitLab
install? Is it just because GitHub is so very popular and everyone knows it?

I have never actually used GitLab, so I can't actually comment on how good
it is...

Re: GitHub “pull request” is useful and can be easily integrated'’

[Ben Finney]

Russ Allbery  writes:

> It's a UI. The UI is really nice. That's why people use it. But
> lock-in implies more than a really nice UI that people use because
> it's superior.

By lock-in I'm implying vendor lock-in: the customer or user is unable
to switch away from the vendor's service without significant switching
costs https://en.wikipedia.org/wiki/Vendor_lock-in>.

> Lock-in implies something you're trapped into using even when it's
> *inferior*, and that's what people are taking issue with.

I don't see that implication from vendor lock-in, and propose that
people are reading it in where it's not implied.

The service may be utterly wonderful and still impose significant
switching costs; in such a case its customers are still locked in. The
benefits of the service don't negate the fact of vendor lock-in.

By that sense – the dominant sense, if I understand correctly – GitHub's
pull requests, no matter how wonderful and beneficial, subject a project
that uses them to the same vendor lock-in.


Robert Collins  writes:

> For clarity, I made no such suggestion [that criticisms of GitHub are
> invalid from someone who doesn't use it].

Thanks for clarifying.

> However your critique has a number of 'how does X work' questions
> which most users of Github could answer.

A made informed statements about how GitHub features work. Responses
told me “that's not true”. Rather than coming back with “is too”, I ask
questions to understand what the person is saying.

What I learned is that I was right in my statement, and I was glad to
have asked the questions because that led to more informed discussion.
My apologies that my questions seemed like I was uninformed.

> That makes your debate about Github seem uninformed, and detracts from
> whatever your actual point is. (Simple by reducing the signal:noise
> ratio of the debate).

I've made my point, some in the discussion have understood. Going
further in this thread is unlikely to convince enough people to be worth
the noise.

So I'll just have to wait until more data comes along, and raise the
issues again at that time.

-- 
 \   “Self-respect: The secure feeling that no one, as yet, is |
  `\suspicious.” —Henry L. Mencken |
_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/857ft7ps6q@benfinney.id.au

Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

[Paul Wise]

On Mon, Apr 20, 2015 at 1:10 AM, David Kalnischkies wrote:

>   I would presume most derivatives aren't using it either

Most derivatives appear to use reprepro but there is one using apt-ftparchive

https://wiki.debian.org/Derivatives/CensusFull
https://wiki.debian.org/Derivatives/Census/Lihuen

> I think there will be some work upon us to make ddebs supported well
> (I invision something like a "apt-get debugsymbols foo" which installs
> the package foo-dbgsym and maybe optionally also the debug packages of
> the direct dependencies libfoo1 (libfoo-dbgsym) and libbar0.1
> (python3-bar-dbgsym as it is the c-binding of a python library as you
> might (not) have guessed).) but lets get them first, shall we? :)

As a user of debug packages I'd like installing foo-dbg to pull in all
the -dbg packages I would need to dump a backtrace from GDB. So
basically all recursive reverse dependencies.

> btw: Is it planed to drop them into their own repository/component or
> are we gone blow up our regular Packages files with them? (you might
> guess from the wording which way I would prefer).

IIRC it was always planned to put them in a separate place.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
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/CAKTje6GFzSJCyaFwXz06gyUtQc0=5__=1_371_yrdwvm3qg...@mail.gmail.com

Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull’

[Paul Wise]

On Mon, Apr 20, 2015 at 1:28 AM, Russ Allbery wrote:
> Stefano Zacchiroli writes:
>> On Sun, Apr 19, 2015 at 12:13:32PM +0800, Paul Wise wrote:
> I mirror the repositories on my own publicly-accessible Git server.
> Hopefully that's good enough.  :)

If those are Debian related, I'd still suggest mirroring on alioth.
General upstream stuff probably doesn't need to.

>>> Also accept contributions via email or git request-pull.
>
>> AOL.
>
> Oh, certainly.

Just an FYI, there are Debian folks who reject patches to Debian
services that are sent via git send-email rather than github pull
requests. Personally I am disappointed by this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
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/CAKTje6G2kanVwjri9TqBvYb=d+qw+oc-s7ku6lc0wdwpass...@mail.gmail.com

Bug#782749: general: All browsers except Links2 crash constantly and iceweasel is broken

[Paul Wise]

On Sun, 2015-04-19 at 11:20 -0600, D. Charles Pyle wrote:

> My machine is a Sparc64 machine.
...
> if I can help, I can try to do so.

An update: sparc will be removed from the Debian archive unless a team
of people is willing to work on the port and bring it back in shape:

https://lists.debian.org/debian-sparc/2015/04/msg1.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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