date:20150419

On Sat, 2015-04-18 at 12:07 +0200, Jérémy Lal wrote:

 gitg is quite good for simple tasks.

I'm guessing it isn't good enough to be a replacement for the github web
UI though and that there is no equivalent free software desktop UI. 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

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

2015-04-19 Thread Neil Williams

On Sun, 19 Apr 2015 19:00:33 +1000
Ben Finney ben+deb...@benfinney.id.au wrote:

 Neil Williams codeh...@debian.org writes:
 
  On Sat, 18 Apr 2015 17:55:17 +1000
  Ben Finney ben+deb...@benfinney.id.au 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: debian github organization ?

On 17 April 2015 at 18:13, Russ Allbery r...@debian.org wrote:
 Marc Haber mh+debian-de...@zugschlus.de 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)   http://www.eyrie.org/~eagle/


 --
 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 rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud


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

Re: debian github organization ?

On 18 April 2015 at 08:03, Ben Finney ben+deb...@benfinney.id.au wrote:
Paul Tagliamonte paul...@debian.org 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 rbtcoll...@hp.com
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 proprietary, incompatible with Git ‘request-pull’ (was: debian github organization ?)

2015-04-19 Thread 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: GitHub “pull request” is useful and can be easily integrated'’

Neil Williams codeh...@debian.org writes:

 On Sat, 18 Apr 2015 17:55:17 +1000
 Ben Finney ben+deb...@benfinney.id.au 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: MBF: build Python 3 modules for packages that support it upstream

2015-04-19 Thread 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: debian github organization ?

2015-04-19 Thread Neil Williams

On Sun, 19 Apr 2015 21:12:57 +1200
Robert Collins robe...@robertcollins.net wrote:

 On 18 April 2015 at 08:03, Ben Finney ben+deb...@benfinney.id.au
 wrote:
  Paul Tagliamonte paul...@debian.org 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: [py3porters-devel] MBF: build Python 3 modules for packages that support it upstream

2015-04-19 Thread 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 paul...@debian.org 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 paul...@debian.org  |   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: Work-needing packages report for Mar 27, 2015

2015-04-19 Thread 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
 copypasting 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=2956view=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

Accepted golang-goptlib 0.4-1 (source all) into unstable

2015-04-19 Thread Ximin Luo

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 17 Apr 2015 10:44:34 +0200
Source: golang-goptlib
Binary: golang-goptlib-dev
Architecture: source all
Version: 0.4-1
Distribution: unstable
Urgency: medium
Maintainer: Hilko Bengen ben...@debian.org
Changed-By: Ximin Luo infini...@pwned.gg
Description:
 golang-goptlib-dev - library for Tor pluggable transports written in Go
Changes:
 golang-goptlib (0.4-1) unstable; urgency=medium
 .
   * New upstream release.
   * Update to latest Standards-Version.
Checksums-Sha1:
 cb0a7216349d6410bfa9f5d6a67ba21ac932a014 1871 golang-goptlib_0.4-1.dsc
 2701b7b7037e18f62e9278b88267a6881228acd6 20807 golang-goptlib_0.4.orig.tar.gz
 0d47cc90a8e4be97dc762d99ee7219d30006dde4 4368 
golang-goptlib_0.4-1.debian.tar.xz
 1b75e31f570b7504a210143478d3d39b772b9102 20606 golang-goptlib-dev_0.4-1_all.deb
Checksums-Sha256:
 a5f43d0d979444825fcc228bc718051070625e2273b2a129b5c4def48200e4a8 1871 
golang-goptlib_0.4-1.dsc
 14fc0ee4eb3acdca463fc28659994d1a4c285b0ac7d05ef169866c0454be4c4c 20807 
golang-goptlib_0.4.orig.tar.gz
 f6982f14212b033218ca18adebb1afe7f45d23d4d880c451732a6eaaee65ce63 4368 
golang-goptlib_0.4-1.debian.tar.xz
 0edb39c671a41c71bc00fed1d2846cdeb576324bc1b8d557e27a1f8cd50329a0 20606 
golang-goptlib-dev_0.4-1_all.deb
Files:
 9b32d203be6a649e2362f13b630b2958 1871 devel optional golang-goptlib_0.4-1.dsc
 5bfc948e5d610406d3f575dacb8cd558 20807 devel optional 
golang-goptlib_0.4.orig.tar.gz
 dfd1f11b82e03a2863ba10c7f86174d8 4368 devel optional 
golang-goptlib_0.4-1.debian.tar.xz
 5976a3e3d477a352eccb47e601cde731 20606 devel optional 
golang-goptlib-dev_0.4-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVM5EQAAoJEHW3EGNcITp+B88QAI688rIzakFo5pym12xXvPYI
0PpzHwV3fU3p8T6dZkHdvfZSIj1cE7KrBMYocHoOxAZPj1qN/vXzEpDCUvEhZDVJ
98OaEiXIwNVgMHckdWy0kRTF9VRd3dNtFvkm+6FAESDZ5ezfvirzRs88PASZTehC
WkjGhDLRKAjNVpXn5mIQ7vAHSf0yJRb3c0CvnRYb4RZE0UWhZMjTVbm3OmIEOIuF
Hvec6zFFYBzkOc1r1qAbBq0HyOb3cBjYG2ruE8Pu6l0r6C6hxZrtqesfQLwC1wfV
zvPp3NdGG24Rfn6E/IWYm0QT6vQE+ok+mkdzOlDIZ3KSnXS++uhZ19s04Liq8Vm+
fyq+1BodL60kJ3jyBqo3S1SrCo/2Z3pSxjQXP7RInej4iOlB+pmbGh2dFdoFBus6
S18wVPndZHe/7aI3Y4YKCGIPKzJ9D+7kq4FQIYfny9hjRCkxlsznsuCYHfJqVHb8
H6PdU68iOFWQqg61TNXS/k3HTWSZe/7qmOAn2AJOU6yoyo3uurqF2OelXw4fwyad
/JklM9cXTHEBMAPt/g0Mohdwd6i+kTdPjzK8vcFfSe6t7LVyAN0q3tL16jfBwczG
6CbXyZPj/Zmh1r/LEvBmomtl2q06/gFwcKQGkbeM1QGQ3e+tzJ9SkqQHwHsAqovK
xAtiCIY+mD+0DqESZ63m
=p8pY
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1yjntp-0001eh...@franck.debian.org

Re: debian github organization ?

 ❦ 19 avril 2015 08:55 GMT, Brian May br...@microcomaustralia.com.au :

 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'’

 ❦ 19 avril 2015 19:00 +1000, Ben Finney ben+deb...@benfinney.id.au :

 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: Bits from the dpkg project: 1.17.x series, general news

2015-04-19 Thread Cyril Brulebois

Guillem Jover guil...@debian.org (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 ?

 ❦ 19 avril 2015 07:34 GMT, Brian May br...@microcomaustralia.com.au :

 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: GitHub “pull request” is useful and can be easily integrated'’

On 19 April 2015 at 21:00, Ben Finney ben+deb...@benfinney.id.au wrote:
 Neil Williams codeh...@debian.org writes:

 On Sat, 18 Apr 2015 17:55:17 +1000
 Ben Finney ben+deb...@benfinney.id.au 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

-- 
Robert Collins

linking perl statically against libperl

2015-04-19 Thread 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: linking perl statically against libperl

2015-04-19 Thread 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 a...@debian.org, 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: debian github organization ?

2015-04-19 Thread Brian May

On Sat, 18 Apr 2015 at 18:01 Neil Williams codeh...@debian.org 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.

Accepted libzen 0.4.31-1 (source amd64 all) into experimental

2015-04-19 Thread Chow Loong Jin

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 16 Apr 2015 12:15:44 +0800
Source: libzen
Binary: libzen-dev libzen0 libzen-doc
Architecture: source amd64 all
Version: 0.4.31-1
Distribution: experimental
Urgency: medium
Maintainer: Chow Loong Jin hyper...@debian.org
Changed-By: Chow Loong Jin hyper...@debian.org
Description:
 libzen-dev - ZenLib C++ utility library -- development files
 libzen-doc - ZenLib C++ utility library -- documentation
 libzen0- ZenLib C++ utility library -- runtime
Changes:
 libzen (0.4.31-1) experimental; urgency=medium
 .
   * [374490a] Imported Upstream version 0.4.31
   * [045cf87] Drop zenlib-missed-cmake-files.patch.
 Applied upstream
   * [2ae0146] Specify -B when using dh_auto_*
 Debhelper's cmake subsystem prefers to use out-of-tree building, at
 obj-${DEB_HOST_GNU_TYPE}, but this is an implementation detail we shouldn't
 rely on. So, explicitly set the builddir instead so that we know where to
 find the .pc file.
   * [1b2b7e9] Patch CMakeLists to use GNUInstallDirs.
 This gives us automatic multiarch support.
   * [3e9fa36] Update libzen-dev.install to look for .pc in debian/tmp
Checksums-Sha1:
 825bb5dc53167078ec2133c15146dc442b02ae3a 1956 libzen_0.4.31-1.dsc
 f8a0ce2c5fb1d4a61186ac6707d07c3ae09f6e8a 126831 libzen_0.4.31.orig.tar.gz
 a90c1c546a7e43364696932233c924798636f6f0 8788 libzen_0.4.31-1.debian.tar.xz
 ddb3f19ef7a7681d16722a9476d86c6ebb0ce65b 36184 libzen-dev_0.4.31-1_amd64.deb
 b2df84d7ec42df480b9e8936eaf63220f356378b 105890 libzen0_0.4.31-1_amd64.deb
 d723079158c4ddafa9e9f68d79cec69b9856db8f 259990 libzen-doc_0.4.31-1_all.deb
Checksums-Sha256:
 ee09de4eeaa99ace089ccac81928a4fd1a55724492bd50132f5dce395019829e 1956 
libzen_0.4.31-1.dsc
 98ddd5c8e02d672055b0087067bc9bcdff27d5f9a8b8943fc209c53d2cf4caa7 126831 
libzen_0.4.31.orig.tar.gz
 f1d030ee20a50312fa928802a04e77202bdda5fec55bed8bb927bd381cbb251a 8788 
libzen_0.4.31-1.debian.tar.xz
 0b08c81f074c15a489a4d4511733575fe7d9eea296be9e796a19ed6198147678 36184 
libzen-dev_0.4.31-1_amd64.deb
 31ad6c208246a79205d248e52329ca68eed261aa71173c906c875488a1f230ff 105890 
libzen0_0.4.31-1_amd64.deb
 103bf252d7ef131868b79ca8e7868c7baebb3681332430e4f961b91fff79de73 259990 
libzen-doc_0.4.31-1_all.deb
Files:
 2240a6ac31c9a19cafa252eb1153a368 1956 libs optional libzen_0.4.31-1.dsc
 c05f2ff828ba462b8a0dccb5f213bf84 126831 libs optional libzen_0.4.31.orig.tar.gz
 08d329f3f65ae3f7e1aed0fb272b5215 8788 libs optional 
libzen_0.4.31-1.debian.tar.xz
 5509333cf3b2a7493d83dac9809be281 36184 libdevel optional 
libzen-dev_0.4.31-1_amd64.deb
 8cae2b457bb4c228390b0a64dbafda31 105890 libs optional 
libzen0_0.4.31-1_amd64.deb
 d21f1a7ae97759a0badf1299979ea270 259990 doc optional 
libzen-doc_0.4.31-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVMmibAAoJEPvVIltYh1KhiwUQAI2rYvFzI8HjK+yS8BaFb3IU
+AkhnWLmIks+CijS0gyggHscBYftLL7/3DuRyRCMXx3SoJodBLGuLS/c4VqYNpmQ
lRVTyARlgyUlpBdLGokGK8MSp/uygXIjADCXFegJaCHin1QtaWJaa/eiulK5GouC
HhTnfk+HQGZxioyqU0jQL7ZbXzkR1FQ/tse4eep8EjKlX522UNlsFZiQVesUcTyR
KVMucK61CuOqso7Jd159df3GdXRKaV0J1zx28OSOow44+4B8HrehrAtmAM/KfmqG
qdHBNQnkl3D5O0GkZDNIdMZPjzg/yZrPHXIfnVDGI2NgNDhJYDIOQz/oCfwAdiVe
a1yh8XQOSOqgUPjvwLA+jLUMy2eiBT5LsD/cOyKUyzF4/BKbcoRL4avs5JHPLbMS
bcd/Cfdh3BFo5WKv0gj87AzRh9/9X4UhuG5NBsjCIzxBow+2nwkiAl3GFEWMIM5j
iCMZCN/wvYRLelHl3hNBrNkxJcgJi1AkE/Cha6cxxH3kkDm745oA6wXxHy1YZO3y
3EhHXrhK1L6kmBL7gtbgk3sz133wU/OC2k+Ff1gjBBybqSQVIKMIEvKuixfDc3vP
Gu4oTIZkLkvydbaG1ubbwk7Ey3QRt/zriRtF/Wawasm0j18r7eK1HgYCKsPx/S0j
Q3tGDX327eIFv0ehxbhU
=c2pM
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1yjjjw-0004wy...@franck.debian.org

Accepted sudoku 1.0.5-1 (source amd64) into experimental

2015-04-19 Thread Peter Spiess-Knafl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 19 Apr 2015 02:12:40 +0200
Source: sudoku
Binary: sudoku
Architecture: source amd64
Version: 1.0.5-1
Distribution: experimental
Urgency: medium
Maintainer: Peter Spiess-Knafl d...@spiessknafl.at
Changed-By: Peter Spiess-Knafl d...@spiessknafl.at
Description:
 sudoku - console based sudoku
Changes:
 sudoku (1.0.5-1) experimental; urgency=medium
 .
   * Imported Upstream version 1.0.5
   * remove upstream applied patches.
   * removed debian/dirs (handled by upstream makefile).
   * adapted debian/rules to new upstream makefile (PREFIX).
   * debian/control: changed dependency to libncurses5-dev.
   * debian/sudoku.desktop: fix missing ';'.
   * updated upstream signing-key.asc
   * removed debian/docs.
   * added debian/clean to avoid override_dh_auto_clean.
   * changed maintainer e-mail in debian/control.
Checksums-Sha1:
 4e7125a4e68c5d859be8680327f39f61213f5cd9 1848 sudoku_1.0.5-1.dsc
 18f51bbb6dcb6ba56564cd07a436460e03d72188 51864 sudoku_1.0.5.orig.tar.gz
 aae8c63b4122a199fe270854defddc4ff1eda3fd 9748 sudoku_1.0.5-1.debian.tar.xz
Checksums-Sha256:
 b229d4196ecd953606da9824396f59c77cc92c9a54df729232dd1070658dd839 1848 
sudoku_1.0.5-1.dsc
 3ce6d9b237546d4ac7cdb7a6bb0e47d5c99e696a710b8935bce40dc706d32ff2 51864 
sudoku_1.0.5.orig.tar.gz
 7f800f3decabf93e069552fc6d3c9b4c02a7c2037a2d58b5f05b9e8b306c9ee1 9748 
sudoku_1.0.5-1.debian.tar.xz
Files:
 c3e98ebd1c4a6c9b583f75baf8137664 1848 games optional sudoku_1.0.5-1.dsc
 171b806e0173f1260e641bb6ab3891e0 51864 games optional sudoku_1.0.5.orig.tar.gz
 b7d190e05a35692d92d93627a04d69f2 9748 games optional 
sudoku_1.0.5-1.debian.tar.xz


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVM1b0AAoJEJFk+h0XvV0239MP/1B5lqdMHi4GhK/hjCa+fxDX
1yCj56Kgh3F8IztAnNHTSazhKmelhzilrwsGDI411NcZeq9CJakQ/wXUZ6YZSLDw
nlVRIRzcGz7bnMl7gJdnYPiXIy9Su6JJNz9Ljc45enipykrQDpKBwBENJDPgtnrR
c1643k5ssiP1BlZ7ataJ2uHkvfT6cc6pJXdB1egUKDln2a9xJMkMNFSLN380REr0
U4ueL8ns10J3acfq6Z3KazQF+ddmjAy6w597HCNLp7OqhQcw7ednUC+uRRMMv1S2
p9uyAS728Hqt7nUDb20bpmPByggQQ+kZuVxi5WQwPhcSVDGI6R5v5+swOm//Rh65
ADtKVTQK4KXbAIuWVfXQ7Aku2LUek/GfNuLtm/IQerhJ0WFyN/qlbqzTQR4mdQxk
GeZm+b3Oa5Cv3SROL7Y94xrGX4jXjYQVFuDN8P7dNPyNzaqzXUXW0FXcQRtjUQ7H
3SEVw050wBqzankCdFm3+q8pxfXQXoK8rv+QOO5jLacxDhaLv2FPidyEPun9PVuc
3UWLaxAyrp50Nc6/lUqAhFItAAdb2Z9wa9d+qCvmz2YbAMzK/88ui3eIa4Kj1t9o
QnoNgZy6/S+Q01/ysz7JCXVmQylJ8h2VzxskSbQiuG+jHxgKL9sYVIWpJ3a5NfQP
CCrwdaojDuCGKYzaI2HJ
=65S4
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1yjjjd-0004xq...@franck.debian.org

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

2015-04-19 Thread 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

2015-04-19 Thread 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: GitHub “pull request” is useful and can be easily integrated'’

On 20 April 2015 at 02:18, Ben Finney ben+deb...@benfinney.id.au wrote:
Robert Collins robe...@robertcollins.net 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 rbtcoll...@hp.com
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

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

Cyril Brulebois k...@debian.org writes:

 Guillem Jover guil...@debian.org (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'’

2015-04-19 Thread 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 james...@debian.org


signature.asc
Description: Digital signature

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

2015-04-19 Thread Andreas Tille

Package: wnpp
Severity: wishlist
Owner: Andreas Tille ti...@debian.org

* Package name: libmuscle
  Version : 3.7
  Upstream Author : Aaron Darling darl...@cs.wisc.edu
* 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

Accepted ruby-ref 1.0.5+dfsg-2~exp1 (source all) into experimental

2015-04-19 Thread Sebastien Badia

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 20 Apr 2015 00:11:50 +0200
Source: ruby-ref
Binary: ruby-ref
Architecture: source all
Version: 1.0.5+dfsg-2~exp1
Distribution: experimental
Urgency: medium
Maintainer: Debian Ruby Extras Maintainers 
pkg-ruby-extras-maintain...@lists.alioth.debian.org
Changed-By: Sebastien Badia s...@sebian.fr
Description:
 ruby-ref   - library implements weak, soft, and strong references in Ruby
Changes:
 ruby-ref (1.0.5+dfsg-2~exp1) experimental; urgency=medium
 .
   * Team upload.
   * Target experimental and build with ruby 2.2.
   * Add ruby-test-unit to Build-Depends for ruby2.2.
   * Update Vcs-Browser to cgit URL and HTTPS.
   * Bump Standards-Version to 3.9.6 (no further changes).
Checksums-Sha1:
 10e87edbc6d7ab4a1d7968118f60da7cc6ee6279 2029 ruby-ref_1.0.5+dfsg-2~exp1.dsc
 29909c3d34abcacf3bf921ac5b04532a567799ad 3140 
ruby-ref_1.0.5+dfsg-2~exp1.debian.tar.xz
 cbcfa3e31c4a6479ac9619d272c2c00f9c367600 11306 
ruby-ref_1.0.5+dfsg-2~exp1_all.deb
Checksums-Sha256:
 9625c1f5b2225b3f1f1521b6b3c2752f615183b4f59347c23c94bf2d3894701a 2029 
ruby-ref_1.0.5+dfsg-2~exp1.dsc
 89ff061f5e62f60d21179961025c9002f55616a976244e21bd746d59bfee86bb 3140 
ruby-ref_1.0.5+dfsg-2~exp1.debian.tar.xz
 2a5766de88bd5a45cb15de587dc0d373e0f07d536c9aee279167d8879aef3e5f 11306 
ruby-ref_1.0.5+dfsg-2~exp1_all.deb
Files:
 3d6ae580c3f1e0ec426c6ae050f22e1e 2029 ruby optional 
ruby-ref_1.0.5+dfsg-2~exp1.dsc
 f1591727c99768b0115d7356897cc7f2 3140 ruby optional 
ruby-ref_1.0.5+dfsg-2~exp1.debian.tar.xz
 ea78c9a613ce44c07d74d274a68766f7 11306 ruby optional 
ruby-ref_1.0.5+dfsg-2~exp1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVNC5gAAoJEFwT1tuTBS4D1D0P/0ojXh8tellAlK3WhJfE3b/M
/glYX0hfJLreleweN4jkH3bWvDJXSA47tW4W3Q80Axu+aJot7akm4IOVbSP34PYW
Nk98hHHb6tT9QBQkKjqgkl9iNgfJT7s93WkCzAZTo8BW1S8DaYjq0HEz+VfNN2JR
3UQZkX5nRbaRHaPYi2rdihtJlAM3LwoihHDfmHbtoYBZ4MSPI1LzBr/cRyHTVV8u
8APD0r9q/62B+g/+qnzXv3iK9HUw9YMwLukUZ81o8agaj/KTtrIxjSZ3XIDADX52
jhM3CJjbQdYWj7ax3FPs5EdOFkIv+mVv0xplKFqmG2UyjmxHqzEZoZlKTbegkHsn
ID+7OmJ9uwDnRqndkIaU36YHFZ7vVMKOTrgURA7bP3p42JBuT2UiFyTMfbOx/T6i
jboZG89XjCk1kB7IzANOnYkVdcL3a3P8pW8HTcR/lhxSCHng29Uq2RUhTeZyn2uc
QgTHsbpWy8O8TqoTw6fb9i6YhNTasACDiThU4Bv2D+vpTZFEmH8dfUK56TgxAVXv
x+rkCv/5HiWMooDQvUEwCLcJ6Y36ZHJRlB2lTS0F1NgOrShH/K/GXPV6Fazx/7AA
Tlw9SRqScJ7q60jyxLWj/DHS6MzTYqbg5aqxJf8L2nV2AcWNUsykSBFnrIySXiqc
mPapcfj9IOdCfo4eWT0o
=p19I
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1yjy1b-0004dg...@franck.debian.org

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

Russ Allbery r...@debian.org 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 URL: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 robe...@robertcollins.net 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

Accepted gnash 0.8.11~git20150419-1 (source i386 all) into unstable

2015-04-19 Thread Gabriele Giacone

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 19 Apr 2015 15:14:31 +0200
Source: gnash
Binary: gnash-common gnash klash gnash-tools gnash-cygnal browser-plugin-gnash 
konqueror-plugin-gnash python-gtk-gnash gnash-ext-fileio gnash-ext-mysql 
gnash-ext-lirc gnash-dev gnash-dbg gnash-doc gnash-common-opengl gnash-opengl 
klash-opengl swfdec-mozilla swfdec-gnome mozilla-plugin-gnash
Architecture: source i386 all
Version: 0.8.11~git20150419-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Flash Team pkg-flash-de...@lists.alioth.debian.org
Changed-By: Gabriele Giacone 1o5g4...@gmail.com
Description:
 browser-plugin-gnash - GNU Shockwave Flash (SWF) player - Plugin for Mozilla 
and derivat
 gnash  - GNU Shockwave Flash (SWF) player
 gnash-common - GNU Shockwave Flash (SWF) player - Common files/libraries
 gnash-common-opengl - dummy package for gnash-common-opengl removal
 gnash-cygnal - GNU Shockwave Flash (SWF) player - Media server
 gnash-dbg  - GNU Shockwave Flash (SWF) player - Debug symbols
 gnash-dev  - GNU Shockwave Flash (SWF) player - Development files
 gnash-doc  - GNU Shockwave Flash (SWF) player - API documentation
 gnash-ext-fileio - GNU Shockwave Flash (SWF) player - Fileio extension
 gnash-ext-lirc - GNU Shockwave Flash (SWF) player - LIRC extension
 gnash-ext-mysql - GNU Shockwave Flash (SWF) player - MySQL extension
 gnash-opengl - dummy package for gnash-opengl removal
 gnash-tools - GNU Shockwave Flash (SWF) player - Command-line Tools
 klash  - GNU Shockwave Flash (SWF) player - Standalone player for KDE
 klash-opengl - dummy package for klash-opengl removal
 konqueror-plugin-gnash - GNU Shockwave Flash (SWF) player - Plugin for 
Konqueror
 mozilla-plugin-gnash - dummy package for renaming to browser-plugin-gnash
 python-gtk-gnash - GNU Shockwave Flash (SWF) player - Python bindings
 swfdec-gnome - dummy package for transition to Gnash
 swfdec-mozilla - dummy package for transition to browser-plugin-gnash
Changes:
 gnash (0.8.11~git20150419-1) unstable; urgency=medium
 .
   * New upstream snapshot.
   * Bump Standards-Version to 3.9.6 (no changes).
   * Fix alternative system on ubuntu (LP: #1266088).
Checksums-Sha1:
 29eedf6069246c7432ab56a58d44db3f8359e065 4156 gnash_0.8.11~git20150419-1.dsc
 7fd0745f2727e9e4766a5e8250c4d2f67722ed5a 4027656 
gnash_0.8.11~git20150419.orig.tar.xz
 a55eb4093e2f699e598f45eadda24cdd7dd38c59 32364 
gnash_0.8.11~git20150419-1.debian.tar.xz
 186489e6680f0b8115fb9ea2a6f4cc15ad95e9aa 1981070 
gnash-common_0.8.11~git20150419-1_i386.deb
 bdf0bdfdf0205e53ebdc40bf355c6b757a887dd2 186308 
gnash_0.8.11~git20150419-1_i386.deb
 6b004ae147406a602f91860bdd9f38605de1b6e7 179956 
klash_0.8.11~git20150419-1_i386.deb
 44042ec7e00847d8e9ea459683cc4a83961137aa 124632 
gnash-tools_0.8.11~git20150419-1_i386.deb
 d226a8fe0a9e1b390be293bba041244896e62b48 412928 
gnash-cygnal_0.8.11~git20150419-1_i386.deb
 2e42de68514107fa31383418ff3e72676416e4cc 120328 
browser-plugin-gnash_0.8.11~git20150419-1_i386.deb
 377f997a6eca1053801af6d28308f4c2b7484830 50934 
konqueror-plugin-gnash_0.8.11~git20150419-1_i386.deb
 796431d1af09b8c94d9273ef9404ef93adce70a6 80528 
python-gtk-gnash_0.8.11~git20150419-1_i386.deb
 0ee3c0bfea90c32111925278c5e3559d60ea81da 63352 
gnash-ext-fileio_0.8.11~git20150419-1_i386.deb
 2cf42f2aec26cae4503e4025205ab08140e85b9d 63172 
gnash-ext-mysql_0.8.11~git20150419-1_i386.deb
 937bd5de397b04e594aef4bdf29676a62662ff9a 56926 
gnash-ext-lirc_0.8.11~git20150419-1_i386.deb
 156be09b163735d7c82bb15c395a0b00185f6448 255518 
gnash-dev_0.8.11~git20150419-1_i386.deb
 895f890ba90cc558ff92561687516c0f889bafbc 55412620 
gnash-dbg_0.8.11~git20150419-1_i386.deb
 33d7b428458ac7d4d3c15770e9122e17e5152faf 3994384 
gnash-doc_0.8.11~git20150419-1_all.deb
 b478c2bbb7e5399fd594365d99333dd839483326 28094 
gnash-common-opengl_0.8.11~git20150419-1_all.deb
 fa5152cacb55a1af5211600c8698faab31446cb1 28090 
gnash-opengl_0.8.11~git20150419-1_all.deb
 061b39e26747916357e3ce25f5e990852ff4d1bc 28082 
klash-opengl_0.8.11~git20150419-1_all.deb
 bebefa66016779c550f34290bb5fc866b58b8feb 28112 
swfdec-mozilla_0.8.11~git20150419-1_all.deb
 2184037a9647966190f9b980c5cb25d55a0905fb 28092 
mozilla-plugin-gnash_0.8.11~git20150419-1_all.deb
 ccf258e25b74cf934a353c63531cbbb1d18faf0d 28092 
swfdec-gnome_0.8.11~git20150419-1_all.deb
Checksums-Sha256:
 9ece3956602e2ed27dc75255c45f83553bf1a0beaa890a0536fe926f1a3c9eaa 4156 
gnash_0.8.11~git20150419-1.dsc
 7ad4b090ef4058f6cc3a47911b529e7decffaa343d43668c817fc2dce36084ba 4027656 
gnash_0.8.11~git20150419.orig.tar.xz
 738d295f5e178a7514789ff8fd4df2c491a894a096f980546df3edbff34c5187 32364 
gnash_0.8.11~git20150419-1.debian.tar.xz
 7aba2c4c75af6fdc3b3c3ba0a4066d160eca21dfcbe7593cc635d4ddf897d5ab 1981070 
gnash-common_0.8.11~git20150419-1_i386.deb
 65ba96f0036e0567a009db0f6ef4e20f47e7bb0ba1cd838a432715aa0c319907 186308 
gnash_0.8.11~git20150419-1_i386.deb
 ea80a95e2c8878d72bb6773d2412da6ae2fcc2297f6bc71ff8d73fa5e687185c 179956

Debian Archive architecture removals

2015-04-19 Thread 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: GitHub “pull request” is useful and can be easily integrated'’

2015-04-19 Thread Brian May

On Mon, 20 Apr 2015 at 00:19 Ben Finney ben+deb...@benfinney.id.au 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 proprietary, incompatible with Git ‘request-pull’

2015-04-19 Thread Russ Allbery

Stefano Zacchiroli z...@debian.org 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)   http://www.eyrie.org/~eagle/


-- 
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

Accepted libmediainfo 0.7.73-1 (source amd64 all) into experimental

2015-04-19 Thread Chow Loong Jin

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sun, 19 Apr 2015 20:27:33 +0800
Source: libmediainfo
Binary: libmediainfo-dev libmediainfo0 python-mediainfodll python3-mediainfodll 
libmediainfo-doc
Architecture: source amd64 all
Version: 0.7.73-1
Distribution: experimental
Urgency: medium
Maintainer: Chow Loong Jin hyper...@debian.org
Changed-By: Chow Loong Jin hyper...@debian.org
Description:
 libmediainfo-dev - library reading metadata from media files -- headers
 libmediainfo-doc - library for reading metadata from media files -- 
documentation
 libmediainfo0 - library for reading metadata from media files -- shared library
 python-mediainfodll - library for reading metadata from media files -- shared 
library
 python3-mediainfodll - library for reading metadata from media files -- shared 
library
Changes:
 libmediainfo (0.7.73-1) experimental; urgency=medium
 .
   * [1e716cb] Imported Upstream version 0.7.73
Checksums-Sha1:
 29b77733b19d267ddb099b76fabf85c1dd654c3c 2359 libmediainfo_0.7.73-1.dsc
 b3695363cb41fa86390c366cc119d897a03576a1 1985807 
libmediainfo_0.7.73.orig.tar.gz
 f4551438d087e180fd67cd153ffe89ec7bc9fa41 8836 
libmediainfo_0.7.73-1.debian.tar.xz
 3e973aadd4fd9f2953c24ec6ba3ad3f5bdb0dc4b 22328 
libmediainfo-dev_0.7.73-1_amd64.deb
 e8f3dcfc2d7970371ea3e6276b57731cfd4dca48 1776864 
libmediainfo0_0.7.73-1_amd64.deb
 3d0ea8510dd760cb42a964bb8252faf46dd10791 13444 
python-mediainfodll_0.7.73-1_all.deb
 8e7660b28436496a4aefd82e460a23c0eb83e405 13318 
python3-mediainfodll_0.7.73-1_all.deb
 c44384c26495b27d21db23aed804984c77e70f34 98288 
libmediainfo-doc_0.7.73-1_all.deb
Checksums-Sha256:
 38a51971f384ce2210e49c766d45ccd5d46e2687f3ec3fd7d25b393f7d6ce0eb 2359 
libmediainfo_0.7.73-1.dsc
 40fe04c2f959537aef6769c89d1b7a1dca242810937f59352e84bc8d1ac3b7a9 1985807 
libmediainfo_0.7.73.orig.tar.gz
 81283f712be1d3afe7863f819f9a9213d1b9a89b9c5c933f446bea0243e84a2d 8836 
libmediainfo_0.7.73-1.debian.tar.xz
 326023c8b7abcea8cb84b5ff079e339eee6ff46b4864ddc4f3d7657fb631647c 22328 
libmediainfo-dev_0.7.73-1_amd64.deb
 50479b9c9bd19a9aed37dfa81cd7a77b75528a1c7249e42d73cf4a2ead0f9edf 1776864 
libmediainfo0_0.7.73-1_amd64.deb
 104246f010bf7600dcea94de5a5c22a11c9d45a16d17b5799e1cbdf9fe59d0e1 13444 
python-mediainfodll_0.7.73-1_all.deb
 2ae059342f86cd6faada1de1f08675c078037cdf628857fb0908393556dd8359 13318 
python3-mediainfodll_0.7.73-1_all.deb
 f0360a31014063d880204e4a274c6e8993f051e7f5612410dfa3d8008716808a 98288 
libmediainfo-doc_0.7.73-1_all.deb
Files:
 8e3bc4d5e918b1bfa4502f5db0d832ad 2359 libs optional libmediainfo_0.7.73-1.dsc
 90d069eb70eeb3cb44e4147c06a6b671 1985807 libs optional 
libmediainfo_0.7.73.orig.tar.gz
 408c158372a7efda333f35e143e2b726 8836 libs optional 
libmediainfo_0.7.73-1.debian.tar.xz
 df2d29db31fdfd2a07a4dd4f8c25ca46 22328 libdevel optional 
libmediainfo-dev_0.7.73-1_amd64.deb
 dd4e76182d3ac8ba1bdd7bfad1cc22ee 1776864 libs optional 
libmediainfo0_0.7.73-1_amd64.deb
 6fe720f39fecfc85dc336a6fefeaee49 13444 python optional 
python-mediainfodll_0.7.73-1_all.deb
 47491d1710161f0a59585f44ca08039f 13318 python optional 
python3-mediainfodll_0.7.73-1_all.deb
 f6bb7b8ba0b03979570f9edd5c069e44 98288 doc optional 
libmediainfo-doc_0.7.73-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVM9ZpAAoJEPvVIltYh1Khh+kP/3LuO4oEwHA8noIrOQfm7lrF
z5JegE1H6D/9P+uPl4ou0QARC+Nu+ns+L7Ip5vfMQAvx1JtNNN8o64bN5hLC5QAj
5H0XV81AOrFn4LAAwyADZCFAYHfsj5D23Yw5nNH4hy09EcW2X09GDo7Z/bcDBa8i
Y52EQi4gDPxDJJXC1239hHqqPG84oMGe3MeehZZFJdYj6Gi3QraOfDu17V2xl7P/
h9Q3Tum54E213bgJ+FwP1IVTAcsRG2A2Ra4/yItLLWTPx0xaxEukT2Uk0d2FuhB0
PjUYxnU4NIBEMIuKCNji1WqlRYi0j6zp2YsrnnscfXq7D+qQWPZ0TMPGsmEyH+d/
oCod5vIejhEd+9iNwBf8OXJ8jjK+GisRe2opne/Ppa8VScfe5t3ILiKUXA06FUHE
QLnrneVFhgidfe3CT8aFevTlg4fElFjJ+DThZmeoaGKNRL7KKg3uffn4yj5kUcMN
uoJtN35B0P6C/muGuIk/yTRafbic3UBL63gVgPbf445jQKyLVOOZlSeAUl56YTZV
lh56rObKB7DY+KqbVE+PzXqR3ypqL6pHwd9qnzGWr7Ko892gdp5u6kby1B4CQpSD
utVgZPo4dBauYB7wDupI+2jw2CDAxUFMK2jSOqm1ZzvBDVD3ig8aQ4e0dk4uVGEX
/o1AAPgxGvF0B8lC0JxE
=fikm
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1yjtzm-0004kh...@franck.debian.org

Accepted hurd 1:0.6-1 (source hurd-i386 all) into unstable

2015-04-19 Thread Samuel Thibault

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 01 Mar 2015 00:41:25 +0100
Source: hurd
Binary: hurd-libs0.3 hurd hurd-dev hurd-dbg hurd-doc hurd-libs0.3-udeb hurd-udeb
Architecture: source hurd-i386 all
Version: 1:0.6-1
Distribution: unstable
Urgency: medium
Maintainer: GNU Hurd Maintainers debian-h...@lists.debian.org
Changed-By: Samuel Thibault sthiba...@debian.org
Description:
 hurd   - GNU Hurd
 hurd-dbg   - GNU Hurd (debugging files)
 hurd-dev   - GNU Hurd (development files)
 hurd-doc   - GNU Hurd manual
 hurd-libs0.3 - GNU Hurd (libraries)
 hurd-libs0.3-udeb - GNU Hurd (libraries) - udeb (udeb)
 hurd-udeb  - GNU Hurd - udeb (udeb)
Changes:
 hurd (1:0.6-1) unstable; urgency=medium
 .
   * New upstream snapshot
   * local/setup-translators: Link /dev/shm to /tmp instead of /run/shm, to
 avoid a tmpfs bug which makes at least Xorg, mupdf, etc. crash.
Checksums-Sha1:
 a1a7154724bacd5bda6b7ab40b9adcd4a8122c91 4680 hurd_0.6-1.dsc
 bcfe92e9060f991ecd0fde686af660b3a097538f 5014 hurd_0.6.orig-devnode.tar.bz2
 26a3bc47df29a67534fa064388433e0cc45ee2fd 18080 hurd_0.6.orig-eth-filter.tar.bz2
 b0a6ffc66b2f980a6cd7432d4d1b72de09b39d85 15980 
hurd_0.6.orig-eth-multiplexer.tar.bz2
 40ca6e640a9c2d0195dcad54b0ff45a230a6c3cc 10448 hurd_0.6.orig-libbpf.tar.bz2
 e96a0e357a4cf77d03e50aac56651a5f975d74a6 3331722 
hurd_0.6.orig-libdde-linux26.tar.bz2
 16270de2e43d5dac0f3f2fc8cf6ea27ff4c393f8 20132 hurd_0.6.orig-libddekit.tar.bz2
 9d91279074f1148dce818cb8ad00ec972136d203 6803 
hurd_0.6.orig-libhurd-slab.tar.bz2
 c5b92eac6c866bc2364546b2d51512798468a24a 22252 hurd_0.6.orig-libmachdev.tar.bz2
 55a5337ff5c752a9781dc9b153b0bcaf8009910b 2015911 hurd_0.6.orig.tar.bz2
 dd503c3a3a731d72ee0a526cfa5f6b909aacb1dc 96896 hurd_0.6-1.debian.tar.bz2
 6f57967219b4b8bd0dbba389bbd85f3d9da7790e 295744 
hurd-libs0.3_0.6-1_hurd-i386.deb
 cf9b96d57db60fd52c9e1bc3c9eff0d5e5b1326b 1430386 hurd_0.6-1_hurd-i386.deb
 91e6fe523a958c61e9868e78d2e7239d8a36cc99 3137074 hurd-dev_0.6-1_hurd-i386.deb
 6ea3a3adbd3e90e898e4d6c601fd34b18cc48cee 3350956 hurd-dbg_0.6-1_hurd-i386.deb
 c199b93a74960ac4b3731c226de2baf2e08e3e96 165196 hurd-doc_0.6-1_all.deb
 f1fd112a378caba094d22b03b3c44a8e6d73340e 272860 
hurd-libs0.3-udeb_0.6-1_hurd-i386.udeb
 6520aa9420868ea1544b9741cf1b61391d64fa68 1451976 hurd-udeb_0.6-1_hurd-i386.udeb
Checksums-Sha256:
 f37498d2b3d73249ec3c11ecb967cfc54ba2cc643cf14797a56c91a683b33a89 4680 
hurd_0.6-1.dsc
 20422cd91aedbe089d384fe97d766fda185a07a8d69568b02b9cb0ea5263649c 5014 
hurd_0.6.orig-devnode.tar.bz2
 8a1be0c68c2a70acb79586da0549a797f6f3149ed1feff47f3f0bb5da011dd98 18080 
hurd_0.6.orig-eth-filter.tar.bz2
 c18d8241cd5aaf785205fe536991b8fcc02ea9dccbe88efbd2e8c2cd0ec95e56 15980 
hurd_0.6.orig-eth-multiplexer.tar.bz2
 44c8b64f722ef6efc55b416b313b445c5f7b50b482d9813a9cd878341345bc27 10448 
hurd_0.6.orig-libbpf.tar.bz2
 4db2dc26a42632a67fa465095d4d12b49fa8c194960b9423a048af8cda24d8f4 3331722 
hurd_0.6.orig-libdde-linux26.tar.bz2
 bafff38074a6c4a465172ca15aac348dbfebef3ce9b067c153daec76118052f1 20132 
hurd_0.6.orig-libddekit.tar.bz2
 e73de11d0244328ea53482caab002d82da6bed967110d6664133acb39c7f3ab7 6803 
hurd_0.6.orig-libhurd-slab.tar.bz2
 a2025bfd7339eb05bc5d65a40fc6fb74487b47d7f13306cfb3db3c864d2dd176 22252 
hurd_0.6.orig-libmachdev.tar.bz2
 d6772631c8c346d70e0958c556af7fce7ded29342a08c44af0532c16c2807a1f 2015911 
hurd_0.6.orig.tar.bz2
 dad37e86cabbaf4ad7960a280b22a5cf606cf787cdbc46455e4aaea6d35a5516 96896 
hurd_0.6-1.debian.tar.bz2
 0f9588fa68627610ab59bfc1ac84a0eee6d41a03ad2cfd3988169ca7dff69324 295744 
hurd-libs0.3_0.6-1_hurd-i386.deb
 44bea704d804bacf86b3d6a7ddc7da9ebbde239dfe44d3d9111ef84ea2841639 1430386 
hurd_0.6-1_hurd-i386.deb
 9bfcce3f39931ac09818e2f12b3d96bb969eaa7931549df14796ecbbd58f54d5 3137074 
hurd-dev_0.6-1_hurd-i386.deb
 d39764f6b33e7d042f748d0ce116ac20dc1b4d896ca4316f0287ab1925b8eee1 3350956 
hurd-dbg_0.6-1_hurd-i386.deb
 f1f79dfecdf3fedbb9688ea9eaa2a00625f9821b6bf1d4e90087ff41deb9cc39 165196 
hurd-doc_0.6-1_all.deb
 610bc8a8e55cf753b6c6c7afd9e0ec3c4b48a0dea1de067f41b945d867235405 272860 
hurd-libs0.3-udeb_0.6-1_hurd-i386.udeb
 cce9dfa131741937354ffc3ba995c147d7eaa548c830e5014c6660df26ff87a0 1451976 
hurd-udeb_0.6-1_hurd-i386.udeb
Files:
 7e2e57c2e751525d1c5fd4c9e69b0bc3 4680 admin required hurd_0.6-1.dsc
 31dd18601fa5b3fc52ce7b74639864f6 5014 admin required 
hurd_0.6.orig-devnode.tar.bz2
 5dbca66b11fb57092f9696c876a8aff6 18080 admin required 
hurd_0.6.orig-eth-filter.tar.bz2
 a667b7ddc9295db8fadb47ef90887aa9 15980 admin required 
hurd_0.6.orig-eth-multiplexer.tar.bz2
 372c791e5b61b8d6486f6d8c43b4492f 10448 admin required 
hurd_0.6.orig-libbpf.tar.bz2
 ffa604815eb2a4d546f1b3df3fb7f936 3331722 admin required 
hurd_0.6.orig-libdde-linux26.tar.bz2
 89ee54b6d1ac43c29b293e4805184b60 20132 admin required 
hurd_0.6.orig-libddekit.tar.bz2
 eae8a08e68509847062096ee3cd31c99 6803 admin required 
hurd_0.6.orig-libhurd-slab.tar.bz2
 d8da5dbbcab0158d1bb6645508b4f8ea 22252 admin required

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

2015-04-19 Thread 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 paul...@debian.org  |   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

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

2015-04-19 Thread Jörg Frings-Fürst

Package: wnpp
Severity: wishlist
Owner: Jörg Frings-Fürst mo...@debian.org

* Package name: pysimplesoap
  Version : 1.16
  Upstream Author : Mariano Reingart reing...@gmail.com
* 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'’

2015-04-19 Thread Russ Allbery

Ben Finney ben+deb...@benfinney.id.au 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)   http://www.eyrie.org/~eagle/


-- 
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

Accepted cwm 5.6-2 (source) into experimental

2015-04-19 Thread James McDonald

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 18 Apr 2015 12:17:39 +0200
Source: cwm
Binary: cwm
Architecture: source
Version: 5.6-2
Distribution: experimental
Urgency: low
Maintainer: James McDonald ja...@jamesmcdonald.com
Changed-By: James McDonald ja...@jamesmcdonald.com
Description:
 cwm- lightweight and efficient window manager for X11
Closes: 782418
Changes:
 cwm (5.6-2) experimental; urgency=low
 .
   * Added patch to avoid using HOST_NAME_MAX which allows building on
 kFreeBSD (Closes: #782418)
Checksums-Sha1:
 56f1bb03a39f1eaef3ff8237bab3b80f7312d319 1715 cwm_5.6-2.dsc
 4dd85aa961d736dbe59618f071553c8c7efd9fdf 10016 cwm_5.6-2.debian.tar.xz
Checksums-Sha256:
 50cfa670a1e6552a4bb42510ca16cf01b59b406b1dc8a57ea68d2baedff8a788 1715 
cwm_5.6-2.dsc
 a068771f971c332bbc3d3f7a31bedb24ee1525f92eda3b9d6006e43e9d620778 10016 
cwm_5.6-2.debian.tar.xz
Files:
 f1e4efc0b3a286967584f2453668d6a0 1715 x11 optional cwm_5.6-2.dsc
 d8d5b59ff7c7e932e7ad1480c10b0a61 10016 x11 optional cwm_5.6-2.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVM9vqAAoJEC1Os6YBVHX1FN0P/3bHDa9hcg13/lSCa4LZebd/
JHyKumIizhPnYtgwQk4CI2zHD9uPhulUQn+Yqc/3r80xYbgVEcBrYjFoCfFc97dO
bKrZGeLzwNGt2YMuyLfYxRjdJd4Vdpi96nxAlQxG9ks/q5ZJvm8q3RP7dCPhJEcg
/5tygHtFTPOwfGM+n5Rm4OgR6CHBwtgX3ecMfPCbBBjNF70M0ZJAhv+WuBKgwsB3
FQxIla2wBU8Vm9iIn9YTmkPHByL0jqrI3/tF2Z2kOMIgVAWR26xUOAvVOMKkXpe8
KtxLc/l+CbnaBknv5iEx06BZKSy8MgGbXnhk49OeEi9VQABSMXsZDwJuC7SBK6ou
4/OgX8jEoYwOziyBWl9GwYn9WtWoWNwZjwfSNg3OUXfAITABmObRC7TRdMgoHLcO
eqX+qGOSblWPgY1jqCSbMCDgPNiUJIqzs5nuWThXz6++JLluXjSJJZB3YUygS+Vr
uSTchkU+nZ7yAQbY14cp4S0y6ka3kNkQ3Y+fU9hhtZ8EX+ZUGEssN7gGJ5gCTchu
aEjY/hxc6JQ/idGB4OecBEEvcm7OguVPZVZqs/ufZ1O7u0NxG6ouwr+3gFjiG2hH
whFjbRL+XxT19gc6+e2Glt9800IGS7EnCKEi9x9R35YgHndLXKb+Kf5uA+43vWhw
iZA6M/Bfiuuly40lCEiM
=8Ivu
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1yjt67-ig...@franck.debian.org

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

2015-04-19 Thread Andreas Tille

Package: wnpp
Severity: wishlist
Owner: Andreas Tille ti...@debian.org

* Package name: libmems
  Version : 1.6
  Upstream Author : Aaron Darling darl...@cs.wisc.edu
* 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

Re: Debian Installer Jessie RC 3 release

2015-04-19 Thread 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 zo...@debian.orgDebian 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

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

2015-04-19 Thread 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 proprietary, incompatible with Git ‘request-pull’

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

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

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

Accepted rhc 1.35.3-1 (source all) into experimental

2015-04-19 Thread Chow Loong Jin

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 20 Apr 2015 02:05:15 +0800
Source: rhc
Binary: rhc
Architecture: source all
Version: 1.35.3-1
Distribution: experimental
Urgency: medium
Maintainer: Debian Ruby Extras Maintainers 
pkg-ruby-extras-maintain...@lists.alioth.debian.org
Changed-By: Chow Loong Jin hyper...@debian.org
Description:
 rhc- OpenShift command-line client tools
Changes:
 rhc (1.35.3-1) experimental; urgency=medium
 .
   * [c5f1fa6] Imported Upstream version 1.35.3
Checksums-Sha1:
 0b03fdc25a29e4eee5c105b32aa48e4037bcdca0 1936 rhc_1.35.3-1.dsc
 4df332d9f8f416e7a5771ba5314479313f7a134a 244796 rhc_1.35.3.orig.tar.gz
 09805441d35f5e1d5fda51b8c18aaadaf73d2a34 5224 rhc_1.35.3-1.debian.tar.xz
 8096fb803a0619c198398fe0a8fe4d870f75eebd 115524 rhc_1.35.3-1_all.deb
Checksums-Sha256:
 fb27de63b2220dd16394872f091d6ec9af28be04ef1cb417f07720671934b33d 1936 
rhc_1.35.3-1.dsc
 ccbc84285d34b2b7532013ff1177a00043a71c4e546ff566c027be3e14971eae 244796 
rhc_1.35.3.orig.tar.gz
 41d4ebd6817f48588160d8bed4a4b89fe902c69125165d6ed8582c01221f262f 5224 
rhc_1.35.3-1.debian.tar.xz
 71bd44ac4ee7b1a52556681bc208aa62df8a299f815a100b4347bc19ffb09ff5 115524 
rhc_1.35.3-1_all.deb
Files:
 2eef39583936d097de06a325ee4985bd 1936 ruby optional rhc_1.35.3-1.dsc
 ad3b54f2d0932a09dd115e816331491c 244796 ruby optional rhc_1.35.3.orig.tar.gz
 14d1f65c8e6a28b0f791314113ab6dd0 5224 ruby optional rhc_1.35.3-1.debian.tar.xz
 8cd614af8bf51c079f84adfdaeeaf3c0 115524 ruby optional rhc_1.35.3-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVM+8QAAoJEPvVIltYh1KhcecQAKxl2zkMTh88a77XwI/lVe3O
k5IRqw4Wh2UL7IYceUPEJm4XgZxwhdQDMNUZ83JzzRbML+gOkv/6zAEUEiKvCKMw
Er2q/pnf0OkVpNncX4V+kNbMIDuTyzlHbarZA+TW/3XxW0H8g4ala0C/6mtLLs5R
8GEkHOyTyuED9vCH7TtCxsA3T7Zs07r4eNIJhPKUgbIFBSUL8yaOiPsVWStqbFK2
c80QL3NK3EGPc8YenZX0aL4cJCKiTZMXmGaK1gwcRYGdMyGRCJzEljvX/7DV4tmN
xgjtvRx+1rIRVeV3GcirGuj2cmkpti0YpJ8kDixlDGBxKov2/YoXDFjzKUKMxGAz
q4gYO5P6rXd43n4bMNxXSNrr/yNw2OrOIIbsT0E8tEXR+FrIxhvtnm7ZAKCN4mHs
OKytLS6iQ6PsNnVW+8pjPx+RJPoCnSBBFJX/kVe3XCMkDUGVqX0XDBl8O8s5LYJl
AjK2JxcnNmo8L+Zl+owORBQauk29uCGZKqQ8V4vMeMDVah95OKp5RXhzRfQcYBmw
H/mPy8n9PEEnxvUg56rdK4/8NoihNM7kFNoGzhlraxsF2Jffx+4lITn9SFV77SaX
emSDP4VQKUy86WM7aVpsZF6yQNPSlb02hF8DJ4evceC0a9l/hOuMjrhMmoFyOXfH
eb1eiNGvsiVKxsOcXHlW
=x95K
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1yk2is-0003hw...@franck.debian.org

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

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

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

2015-04-19 Thread 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'’

Neil Williams codeh...@debian.org writes:

 On Sun, 19 Apr 2015 19:00:33 +1000
 Ben Finney ben+deb...@benfinney.id.au 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 robe...@robertcollins.net 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

2015-04-19 Thread 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: GitHub “pull request” is useful and can be easily integrated'’