Re: Standardizing the layout of git packaging repositories

[Simon McVittie]

On 26/08/14 07:01, Brian May wrote:
> In gbp-pq [...] There is no history kept of
> the patch-queue branch. Possibly the patch-queue branch shouldn't be
> pushed to remote repositories, because rebasing is expected.

You are correct in thinking that it is conventional to avoid pushing the
patch-queue branch.

S


-- 
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/53fc3514.4010...@debian.org

Re: internationalized domain name (IDN) in Debian

[Michal Politowski]

On Tue, 26 Aug 2014 08:50:31 +0200, Dariusz Dwornikowski wrote:
> On 25.08.14 19:53:53, Milan P. Stanic wrote:
> > On Mon, 2014-08-25 at 15:54, Dariusz Dwornikowski wrote:
> > > > Am Sonntag, den 24.08.2014, 20:32 +0200 schrieb Ralf Jung:
> > > > > > https://wiki.debian.org/IDN 
> > > > > > Summary: webbrowser support it in general but email clients still 
> > > > > > lack
> > > > > > the support of it.
> > > > > 
> > > > > Why do you list Icedove as non-supporting? I just sent a mail to your
> > > > > echo service, and got a reply. Is there anything else I should check?
> > > > No, this was a mistake. Just sending/recieving is my first test. This
> > > > could be much more extended (from address with IDN, setup wizard with
> > > > your email account with IDN domain, IDN certificates,...) but first it
> > > > helps to know the software can send IDN emails.
> > > I have chromium on testing, IDN works but show the domain name as 
> > > http://www.xn--kthe-5qa.de/ instead of www.köthe.de . I think this is a 
> > > known chromium issue. 
> > 
> > In my chromium it show it as http://www.köthe.de
> > chromium  35.0.1916.153-1~deb7u1 amd64
> > 
> > -- 
> 
> This is funny. In my chromium http://www.köthe.de get rewritten to
> http://www.xn--kthe-5qa.de/, whereas polish IDN domains stay the way
> they should http://żaba.pl/ or http://żółć.pl . 
> 
> chromium 35.0.1916.153-2 amd64

It seems it is based on your language settings:
http://www.chromium.org/developers/design-documents/idn-in-google-chrome

Adding more languages to the list does indeed cause more IDN domains to
display.

-- 
Michał Politowski


--
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/20140826072240.ga29...@meep.pl

Re: First steps towards source-only uploads

[Ondřej Surý]

On Wed, Aug 13, 2014, at 14:02, Guillem Jover wrote:
> Hi!
> 
> On Mon, 2014-08-04 at 02:35:46 -0400, Joey Hess wrote:
> > #756975 dpkg-dev: dpkg-genchanges option to only include arch:all debs
> 
> This is now available in dpkg 1.17.11, and as mentioned on the bug
> report, you can use it in at least these ways:
> 
>   # Source and arch-indep only build, will fail if the package does
>   # not produce any arch-indep binary, in which case you'd use -S.
>   $ dpkg-buildpackage -g
> 
> or
> 
>   # Full build, but filter the generated .changes file to only inlcude
>   # source and possibly arch-indep binaries, will not fail if the
>   # latter are missing.
>   $ dpkg-buildpackage --changes-option=-g

Any success of passing this to git-pbuilder?

I had to modify pdebuild to not pass $DEBBUILDOPTS to
dpkg-buildpackage invocation and only pass those options
to the build inside of pbuilder.

Ondrej
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
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/1409041723.583972.156795125.3f34c...@webmail.messagingengine.com

Re: Standardizing the layout of git packaging repositories

[Guido Günther]

On Mon, Aug 25, 2014 at 04:38:05PM +1000, Brian May wrote:
> On 25 August 2014 14:34, Barry Warsaw  wrote:
> 
> > I'm beginning to think that what we want is for gbp and git-dpm to
> > interoperate, such that any individual maintainer can use whichever tool
> > they
> > choose, but would still allow the team to adhere to consensus
> > recommendations,
> > so there's no guesswork involved.  E.g. the ultimate artifacts would end up
> > being the same, regardless of whether you used gbp, git-dpm, or plain
> > vanilla
> > git + quilt.  One example of a superficial differences is the tag names
> > used
> > by default.  They're different between the two helpers, but really needn't
> > be.
> >
> 
> Unless I am mistaken, I think both  gbp pq and git-dpm store different data
> in git, so cannot interoperate on the same tree.
> 
> i.e. by the looks of it, gbp pq only bothers to keep the most recent set of
> patches in git, and stores the history of old patches  old versions of
> debian/patches/.

...but you can keep (and share) old versions by tagging the commit on
the pq branch and pushing the tag. This has the advantage that it
doesn't need additional branches and that it's not fetched by default
since there's no branch you fetch with it.

Or you can fake-merge it into e.g. master. It's just that this isn't
automated in any way within gbp yet.
Cheers
 -- Guido


-- 
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/20140826100555.gc1...@bogon.m.sigxcpu.org

Re: Standardizing the layout of git packaging repositories

[Guido Günther]

On Tue, Aug 26, 2014 at 08:19:48AM +0100, Simon McVittie wrote:
> On 26/08/14 07:01, Brian May wrote:
> > In gbp-pq [...] There is no history kept of
> > the patch-queue branch. Possibly the patch-queue branch shouldn't be
> > pushed to remote repositories, because rebasing is expected.
> 
> You are correct in thinking that it is conventional to avoid pushing the
> patch-queue branch.

...but it is o.k. to push e.g. patch-queue/master as
patch-queue/ tag if debian/ is the tag of the Debian
release permitting to keep a stable SHA1.
Cheers,
 -- Guido


-- 
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/20140826101004.gd1...@bogon.m.sigxcpu.org

Re: Standardizing the layout of git packaging repositories

[Guido Günther]

On Sun, Aug 24, 2014 at 02:11:16PM +, Mike Gabriel wrote:
[..snip..]
> >- shall we standardize the "pristine-tar" branch?
> 
> I'd say "No" here. With packaging of the MATE desktop environment I started
> maintaining only the debian/ folders in the packaging Git repositories (e.g.
> [1]). So, I am not shipping any upstream sources with the packaging Git at
> all. I have started getting fond of this Git packaging way and I recommend
> this to everyone else for various reasons (saving storage on git.debian.org
> for one of them).

Having a 'pristine-tar' branch should only apply if there are any
upstream sources in git. It doesn't make sense for debian/ only
packaging.

That said it'd be nice to know why it's more convenient to not have
the upstream sources in git since I think one misses out on many of
the advantages of git based packaging (like rebasing patches to new
upstream versions).

Cheers,
 -- Guido


-- 
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/20140826101458.ge1...@bogon.m.sigxcpu.org

Re: daemon user naming scheme

[Guido Günther]

On Mon, Aug 25, 2014 at 03:53:22PM +0100, Simon McVittie wrote:
> On 25/08/14 14:01, Jerome BENOIT wrote:
> > is there for Debian a daemon user naming scheme or custom ?
> 
> Several :-(
> 
> The ones I've seen suggested are (assuming a package, daemon or user
> whose simple name is "foo"):
> 
> * _foo
> * foo
> * debian-foo
> * Debian-foo
> * Dfoo
> 
>  has been open
> since 2004 and shows no signs of resolution.
> 
> I think I slightly prefer _foo, which originated in *BSD. However, none
> of the packages I maintain actually do that; they use Debian-foo or

This has the advantage of being short and downstreams not having lots of 
Debian-*
users on their systems possibly confusing users not familiar with
Debian. I'd be nice to standardize on this.
Cheers,
 -- Guido


-- 
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/20140826101939.gf1...@bogon.m.sigxcpu.org

Re: Standardizing the layout of git packaging repositories

[Mike Gabriel]

Hi Guido,

On  Di 26 Aug 2014 12:14:58 CEST, Guido Günther wrote:


That said it'd be nice to know why it's more convenient to not have
the upstream sources in git since I think one misses out on many of
the advantages of git based packaging (like rebasing patches to new
upstream versions).


The convenience judgement is probably quite a personal thing. I use  
both workflows (gbp and debian/-only), but esp. for backporting I came  
to prefering only having the debian/ folders in my Gits.


For rebasing debian/patches/*.patch against new upstream releases, I  
simply copy my tarball into the packaging Git, rebase the patches,  
remove upstream sources again and commit the patches.


Greets,
Mike



--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpcDaadX4qie.pgp
Description: Digitale PGP-Signatur

RE:daemon user naming scheme

[PICCA Frederic-Emmanuel]

> This has the advantage of being short and downstreams not having lots of 
> Debian-*
> users on their systems possibly confusing users not familiar with
> Debian. I'd be nice to standardize on this.

I have the same problem in one of my package. #737956
I would like to rename the system user tango -> _tango
But I do not know how to do this rename properly :((

cheers

Frederic

--
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/20140826101939.gf1...@bogon.m.sigxcpu.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/a2a20ec3b8560d408356cac2fc148e53b1f01...@sun-dag3.synchrotron-soleil.fr

Bug#759340: RFP: cdist -- Usable Configuration Management System

[Nico Schottelius]

Package: wnpp
Severity: wishlist

* Package name: cdist
  Version : 3.1.6
  Upstream Author : Nico Schottelius 
* URL or Web page : http://www.nico.schottelius.org/software/cdist/
* License : GPL-3+
  Description : Usable Configuration Management System

cdist is a usable configuration management system. It adheres to the
KISS principle and is being used in small up to enterprise grade
environments. cdist is an alternative to other configuration
management systems like cfengine, bcfg2, chef and puppet.

There exists a preliminary packaging by Axel Beckert for version 3.0.0
at https://github.com/xtaran/cdist/tree/debian/debian on which the
packaging probably should be based on. Axel would also review and
sponsor cdist packages, but won't maintain it himself.


msg.asc
Description: Binary data

Bug#759354: ITP: python-admesh -- Python bindings for the ADMesh, program for processing triangulated solid meshes

[Anton Gladky]

Package: wnpp
Severity: wishlist
Owner: Anton Gladky 

* Package name: python-admesh
  Version : 0.98
  Upstream Author : Miro Hrončok 
* URL : https://github.com/admesh/python-admesh
* License : GPL-2
  Description : Python bindings for the ADMesh, program for processing 
triangulated solid meshes

This module provides bindings for the ADMesh library. It lets you
manipulate 3D models in binary or ASCII STL format and partially repair
them if necessary.

The package will be maintained in Debian Science Team


-- 
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/20140826163944.27774.87398.reportbug@debian

Re: daemon user naming scheme

[Matthias Urlichs]

Hi,

PICCA Frederic-Emmanuel:
> I would like to rename the system user tango -> _tango
> But I do not know how to do this rename properly :((
> 
Fake it.

UID=$(id -u tango)
GID=$(id -g tango)
deluser tango
adduser tango --uid $UID --gid $GID

-- 
-- Matthias Urlichs


-- 
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/20140826171050.ga21...@smurf.noris.de

Re: daemon user naming scheme

[Matt Zagrabelny]

On Tue, Aug 26, 2014 at 12:10 PM, Matthias Urlichs  wrote:

> adduser tango --uid $UID --gid $GID

typo?

adduser _tango --uid $UID --gid $GID

-mz


-- 
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/caolfk3x04x2iv0rzd9e5zpjwtpepgdtp++nj6mwm9zhnoma...@mail.gmail.com

Re: daemon user naming scheme

[Lars Wirzenius]

On Tue, Aug 26, 2014 at 12:40:04PM -0500, Matt Zagrabelny wrote:
> On Tue, Aug 26, 2014 at 12:10 PM, Matthias Urlichs  
> wrote:
> 
> > adduser tango --uid $UID --gid $GID
> 
> typo?
> 
> adduser _tango --uid $UID --gid $GID

The sysadmin may have written scripts and things that assume the
existing username. Instead of removing the old one, maybe add a new
one with the same uid, gid, groups, etc?

-- 
http://www.cafepress.com/trunktees -- geeky funny T-shirts
http://gtdfh.branchable.com/ -- GTD for hackers


-- 
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/20140826174634.ge4...@exolobe1.liw.fi

RE:daemon user naming scheme

[PICCA Frederic-Emmanuel]

> Fake it.

> UID=$(id -u tango)
> GID=$(id -g tango)
> deluser tango

> adduser tango --uid $UID --gid $GID

I like this fake rename because it cause no troubles to the files already owned 
by the tango user
BÙT
in case of an idempotent pre/post scripts.
what happend if I delete the tango users before creating the new _tango user.

If something goes wrong between this deluser and adduse, I am stuck...

another important point in my case is that I need to do some mysql operation to 
grant right for the new user...

Frederic

Is it possible to use this thread to define the default snipsets to put in the 
debhelper scripts to do this rename.

--
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/a2a20ec3b8560d408356cac2fc148e53b1f01...@sun-dag3.synchrotron-soleil.fr

Help request: intel-microcode and old Intel processors

[Henrique de Moraes Holschuh]

I am the maintainer of the intel-microcode and iucode-tool packages, used to
update the microcode[1] on Intel system processors (CPU chip).

I'd like to know whether the kernel microcode update is working well on some
of the older Intel 32-bit processors or not.  These computers were sold
between years 2000 and 2010.

This information will be used to decide the level of microcode update
support for these processors on the next non-free release (Jessie).

If you happen to run Debian or Ubuntu on a computer with an old Intel
processor (Pentium M, Celeron M, Pentium 4 Mobile, Mobile Celeron, Pentium
4, Pentium II, Pentium III, Pentium D, Celeron D, Core Solo, etc), and you
have the intel-microcode package installed, I ask you to run this simple
test command in a terminal emulator (xterm, konsole, system console, etc):

  grep microcode.*update /var/log/dmesg

The command above searches for a specific log message during boot that tells
me whether the microcode is being updated by Debian/Ubuntu or not.

If the test above returned something, it would be really helpful if you
could send me a reply (feel free to email it directly to me) with the result
of the following commands:

  grep microcode /var/log/dmesg
  cat /proc/cpuinfo

These commands display microcode-related log messages, and also some CPU
information (processor name, family, model and stepping, microcode version,
etc).

Thank you!

[1] A microcode update is a process used to fix defects (errata) on the
system processor, by updating its internal control program (microcode).
https://wiki.debian.org/Microcode

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20140826184906.ga14...@khazad-dum.debian.net

Re: daemon user naming scheme

[Guillem Jover]

Hi!

On Tue, 2014-08-26 at 11:02:54 +, PICCA Frederic-Emmanuel wrote:
> > This has the advantage of being short and downstreams not having lots of 
> > Debian-*
> > users on their systems possibly confusing users not familiar with
> > Debian. I'd be nice to standardize on this.
> 
> I have the same problem in one of my package. #737956
> I would like to rename the system user tango -> _tango
> But I do not know how to do this rename properly :((

# usermod -l newname oldname

(Other things can also be modified at the same time, see the man page.)

Regards,
Guillem


-- 
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/20140826194545.ga16...@gaara.hadrons.org

RE:daemon user naming scheme

[PICCA Frederic-Emmanuel]

> # usermod -l newname oldname

> (Other things can also be modified at the same time, see the man page.)


thanks a lot

Frederic

--
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/a2a20ec3b8560d408356cac2fc148e53b1f01...@sun-dag3.synchrotron-soleil.fr

Bug#759376: ITP: python-pysocks -- socket-like interface for tunneling through SOCKS

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-pysocks
  Version : 1.5.0
  Upstream Author : Anorov Vorona 
* URL : https://pypi.python.org/pypi/PySocks
* License : BSD-3-clauses
  Programming Lang: Python
  Description : socket-like interface for tunneling through SOCKS

 This module provides a standard socket-like interface for Python for tunneling
 connections through SOCKS proxies. This is an updated version of SocksiPy.
 Many old bugs fixed, and overall code cleanup. It features:
  * Fully supports Python 2.6 - 3.4
  * SocksiPyHandler, courtesy e000, was also added as an example of how this
module can be used with urllib2. See example code in sockshandler.py.
  * Bugs in the original SocksiPy were fixed, including two that could lead
to infinite hanging when communicating with bad proxy servers.
  * urllib3, which powers the requests module, is working on integrating SOCKS
proxy support based on this branch.
  * SOCKS5, SOCKS4, and HTTP are now aliases for PROXY_TYPE_SOCKS5,
PROXY_TYPE_SOCKS4, and PROXY_TYPE_HTTP
  * Various style and performance improvements; codebase simplified
  * Actively maintained


This is a dependency for running Google cloud tools.


-- 
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/20140826210827.11541.17755.report...@buzig.gplhost.com

Bug#759379: general: Mouse resp. touchpad cursor is flickering, disapearing and jumping

[Stefan Hans]

Package: general
Severity: normal

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation? New installed debian on a dell inspiron 15 
7000 series with gnome
   * What exactly did you do (or not do) that was effective (or
 ineffective)? It happens everywhere as far as I've experienced
   * What was the outcome of this action? I have to redo the action esp. clicks 
or search for the cursor
   * What outcome did you expect instead? stable normal cursor behaviour

*** End of the template - remove these lines ***


-- System Information:
Debian Release: 7.6
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
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/20140826213028.15629.33593.reportbug@debian

Bug#759385: ITP: python-protorpc-standalone -- Google Protocol RPC

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-protorpc-standalone
  Version : 0.9.1
  Upstream Author : Daniel Hermes 
* URL : https://github.com/jeremydw/protorpc-standalone
* License : Apache-2.0
  Programming Lang: Python
  Description : Google Protocol RPC

 This package provides the Google Protocol RPC (modified to run outside Google
 App Engine). Protorpc is library is a framework for implementing
 HTTP-based remote procedure call (RPC) services.


-- 
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/20140826215004.14247.58222.report...@buzig.gplhost.com

Re: daemon user naming scheme

[Matthias Urlichs]

Hi,

PICCA Frederic-Emmanuel:
> BÙT
> in case of an idempotent pre/post scripts.
> what happend if I delete the tango users before creating the new _tango user.
> 
Actually, nothing prevents you from creating _tango first.

> another important point in my case is that I need to do some mysql operation 
> to grant right for the new user...
> 
mysql usernames and Linux usernames are not related in any way.

-- 
-- Matthias Urlichs


-- 
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/20140826224723.gf21...@smurf.noris.de

Re: bits from the DPL -- mid-April to mid-August 2014

[Santiago Vila]

On Sun, Aug 24, 2014 at 09:28:11AM -0700, Lucas Nussbaum wrote:
> Donations in Bitcoin
> 
> 
> Crytocurrencies have been the subject of a lot of attention recently.
> Debian received its first Bitcoin donation, which was handled in a ad-hoc
> manner as we don't have any infrastructure for them yet. The Debian
> auditors are looking into various options around this, and to understand
> where we should be going with cryptocurrencies donations, we would like to
> hear from people interested in making such donations. Specifically, would
> it matter to you that Debian tries to keep and use those donations as
> bitcoins? Or on the contrary, would you prefer Debian to convert them into
> USD or EUR to limit the risks raised by the higher volatility of Bitcoins?

I don't think Debian should accept donations in Bitcoin, as such thing
could be considered as an endorsement of Bitcoin. The EFF has a very
well written rationale why accepting Bitcoins is not necessarily a
good idea, see point 3 here:

https://www.eff.org/deeplinks/2011/06/eff-and-bitcoin

In fact, I consider Bitcoin to be some kind of collective hallucination,
as it violates so-called "Mises regression principle".

When we used gold as money, we did so because it was already a valuable thing.
But with Bitcoin, people pretend it to be money *before* or *at the same time*
it has a value, which is some kind of "bootstrapping problem".

Sure, their advocates consider it to be "already bootstrapped", I
consider it too much similar to a scam.

As for whether Debian should keep some of its assets in Bitcoins or not, that
would be like asking whether Debian should keep some of its assets in
gold. I think the answer is clearly not.

To summarize:

* I feel unconfortable with the fact that Debian accepts Bitcoins and
I think we should not do that.

* If we have to accept them, we should convert it to whatever usual
money we are already using.

Thanks.


-- 
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/20140827000803.ga2...@cantor.unex.es

Re: bits from the DPL -- mid-April to mid-August 2014

[Charles Plessy]

Le Wed, Aug 27, 2014 at 02:08:03AM +0200, Santiago Vila a écrit :
> 
> I don't think Debian should accept donations in Bitcoin, as such thing
> could be considered as an endorsement of Bitcoin. The EFF has a very
> well written rationale why accepting Bitcoins is not necessarily a
> good idea, see point 3 here:
> 
> https://www.eff.org/deeplinks/2011/06/eff-and-bitcoin

Hi Santiago,

The EFF changed its mind two years later.


https://www.eff.org/deeplinks/2013/05/eff-will-accept-bitcoins-support-digital-liberty

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20140827004015.gh19...@falafel.plessy.net

Re: bits from the DPL -- mid-April to mid-August 2014

[intrigeri]

Hi,

Santiago Vila wrote (27 Aug 2014 00:08:03 GMT) :
> The EFF has a very well written rationale why accepting Bitcoins is
> not necessarily a good idea, see point 3 here:
> https://www.eff.org/deeplinks/2011/06/eff-and-bitcoin

It seems useful to note that, since then, they've decided to accept
Bitcoins, and explained why:
https://www.eff.org/deeplinks/2013/05/eff-will-accept-bitcoins-support-digital-liberty

Cheers,
-- 
intrigeri


-- 
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/85ha0ywyry@boum.org

Re: bits from the DPL -- mid-April to mid-August 2014

[Santiago Vila]

On Wed, Aug 27, 2014 at 09:40:15AM +0900, Charles Plessy wrote:
> The EFF changed its mind two years later.
> 
> 
> https://www.eff.org/deeplinks/2013/05/eff-will-accept-bitcoins-support-digital-liberty

Ok, from the above link:

 You can now give Bitcoins to EFF in the same way that you can give
 stock. EFF has long had a policy that converts gifts of stock and
 items like cars into cash immediately on receipt.

At the very minimum, we should have a policy like that, as Bitcoin is
more an asset than money.

The referenced link has even more interesting stuff, which I'll quote:

  [...] we note here that Bitcoin is very often not anonymous in the
  ways users might believe or expect, because (for instance) the
  network doesn't actively conceal the IP addresses from which
  transactions were initiated; its expenditure of large amounts of
  computational resources may turn out to be unnecessary; and its
  monetary policy is controversial and arguably designed to
  incentivize adoption and holding of the currency, rather than
  maximizing valuable economic transactions.

To me, it's sad to see that we seem to be officially endorsing Bitcoin
without any debate at all. If we accept Bitcoin, we should probably
accept competing so-called-cryptocurrencies as well. Should Debian
favour one cryptocurrency over the others?

Thanks.


-- 
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/20140827020131.GA4093@dell

Bug#759398: ITP: trust-router - Dynamically configure Trust Between RADIUS Realms

[Sam Hartman]

package: wnpp
severity: wishlist
owner: hartm...@debian.org


URL: git://git.project-moonshot.org/trust_router.git
http://www.project-moonshot.org/

license: bsd-3-clause

Description: The trust router establishes a DH key between two RADIUS
servers to protect a RADIUS over TLS session.  GSS-API authentication is
used between  to securely establish this key.  The trust router provides
a trusted-third-party to manage connections between RADIUS realms and to
provide information constraining what connections are permitted.

The trust router is used to connect Moonshot Service providers to
Identity Providers.


-- 
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/014815379066-0646baf9-9869-4bd1-b409-9fbfa4f81de9-000...@email.amazonses.com

Bug#759159: ITP: shibboleth-resolver - Library to access the Shibboleth Attribute Resolver from Third-Party Applications

[Sam Hartman]

package: wnpp
severity: wishlist
owner: hartm...@debian.org

URL: http://www.shibboleth.org/
Source: svn https://svn.shibboleth.net/extensions/cpp-sp-resolver/trunk

Description: Shibboleth library to access Attribute Resolver
 The Shibboleth Service provider consumes information about an
 authenticated user from SAML and GSS-API , providing services such as
 attribute mapping, authorization, and attribute resolution.  This
 extension permits a third-party application to access resolved
 attributes.

License: Apache 2.0

I'm packaging this because it is a dependency of the Moonshot GSS-API
mechanism, an implementation of RFC 7055 (EAP for GSS-API).

Current work can be seen at
git://git.project-moonshot.org/shibboleth/resolver.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/01481537d429-39b5afac-c8f6-478e-a39d-36080f95f2a7-000...@email.amazonses.com

Re: Standardizing the layout of git packaging repositories

[Brian May]

On 26 August 2014 16:12, Manoj Srivastava 
wrote:

> http://people.debian.org/~srivasta/Serializing_Git_Branches.pdf has a
> demonstration of the differences in history given an upstream and two
> feature branches with two commits each, using git-dpm and git-debcherry.
>

Interesting review.

However, I think there might be some errors.

I don't think you should use normally be feature branches with git-dpm.
Rather you edit the commit directly (whether by rebase or --amend).

Also I think there is an error in the way you have done the git-dpm, e.g.
when committing B21, you have added to the existing B12 patch instead of
replacing it. Similarly when adding A31, you haven't replaced A11.
-- 
Brian May 

Re: bits from the DPL -- mid-April to mid-August 2014

[Matthias Urlichs]

Hi,

Santiago Vila:
> To me, it's sad to see that we seem to be officially endorsing Bitcoin
> without any debate at all. If we accept Bitcoin, we should probably
> accept competing so-called-cryptocurrencies as well. Should Debian
> favour one cryptocurrency over the others?
> 
No, but it's the most widely used one, and setting up eWallets for yet
another cryptocurrency is a hassle.

In any case, I'm in favor of accepting Bitcoins (and whatever else
somebody can be bothered to set up a donation address for) – but for
our purposes they should be considered a fancy way to exchange money,
not money or something else "valuable" in and of themselves, and
converted to $/€ as soon as we get them.

-- 
-- Matthias Urlichs


-- 
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/20140827063451.gb21...@smurf.noris.de

Re: Standardizing the layout of git packaging repositories

[Matthias Urlichs]

Hi,

Brian May:
> I don't think you should use normally be feature branches with git-dpm.
> Rather you edit the commit directly (whether by rebase or --amend).
> 
If Upstream uses git and wants you to send a pull request when you add a
feature (or fix a bug), then using a feature branch is what you do – so our
git-aware packaging tools should work well with them.

-- 
-- Matthias Urlichs


-- 
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/20140827064025.gc21...@smurf.noris.de

Re: daemon user naming scheme

[Matthias Urlichs]

Hi,

Matt Zagrabelny:
> On Tue, Aug 26, 2014 at 12:10 PM, Matthias Urlichs  
> wrote:
> 
> > adduser tango --uid $UID --gid $GID
> 
> typo?
> 
> adduser _tango --uid $UID --gid $GID
> 
Right. Of course. Thanks for spotting. :-/
-- 
-- Matthias Urlichs


-- 
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/20140827064112.gd21...@smurf.noris.de