Re: Call for teams interested in collaborating on a 'standard' Git workflow

[martin f krafft]

also sprach Thomas Koch  [2011.07.29.1613 +0200]:
> I've attached a draft of a description of the workflow.

It would be good to put this onto the vcs-pkg-discuss mailing list.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"i believe that the moment is near when by a procedure
 of active paranoiac thought, it will be possible
 to systematise confusion and contribute to
 the total discrediting of the world of reality."
  -- salvador dali


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#636016: ITP: goodbye -- next part after 'hello', and a packaging example

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: goodbye
  Upstream Author : myself
  Git : git://gitorious.org/pkg-goodbye/goodbye.git
* License : GPL
  Programming Lang: C
  Description : next part after 'hello', and a packaging example

Using slow, bloated tools like debhelper and dpkg-dev will cost you precious
SECONDS when building your package.  Multiplied by tens of thousands of
packages Debian has, this can be a burden on archive rebuilds.  Thus, this
is a proposal and example how to get rid of that inefficiency.

Written in a Real Man(tm)'s scripting language with a JIT compiler, it's
over two orders of magnitude faster than mainstream packaging techniques.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110730101749.5824.12147.report...@orthanc.angband.pl

Bug#636017: ITP: tran[s[lit]] -- transcribe between character scripts (Cyrillic <-> Latin, etc)

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: tran? trans? translit?
  Upstream Author : Adam Borowski 
* URL : https://github.com/kilobyte/tran
* License : GPL
  Programming Lang: Perl
  Description : transcribe between character scripts (Cyrillic <-> Latin, 
etc)

This is a tool for romanization / cyrillization / greekization / etc of text.
It converts character scripts rather than encodings.  For example, it can
turn "Debian" into "Дэбян", "Δεβιαν".

Currently supported scripts:
* latin
* ascii (ie, dropping accents)
* fullwidth (doublewidth ascii for most of us)
* cyrillic
* greek
* devanagari
* katakana
* hiragana
* hangul
and more are coming.  Unicode has for example 13 fancy sets of letters for
mathematical purposes (fraktur, double-strike, etc), this is not supported
yet because a problem in glibc[1], circled/boxed letters, etc.  Not to
mention all the remaining scripts in Unicode and ConScript.

It tries to do transcription rather than mere transliteration, but is still
pretty naive and doesn't go far into realms of phonetic accuracy.

I named this project ~six years ago "tran" which is probably way too
generic.  I guess "translit" might be a bit better.

There is a similar tool in Debian: libtext-unidecode-perl, but it can go
only one way, targets basic ASCII rather than Latin and fails to preserve
non-letter characters like frames.


[1]. towlower(0x1D400) and friends don't work.  This needs either to be
fixed in glibc, or be worked around with hand-crafted case conversions.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110730101803.7812.38494.report...@orthanc.angband.pl

Bug#636036: ITP: parcimonie -- privacy-friendly helper to refresh a GnuPG keyring

[intrigeri]

Package: wnpp
Owner: intrigeri+deb...@boum.org
Severity: wishlist

* Package name: parcimonie
  Version : 0.5.1
  Upstream Author : intrigeri 
* URL or Web page : https://gaffer.ptitcanardnoir.org/intrigeri/code/parcimonie/
* License : Artistic or GPL-1+
  Description : privacy-friendly helper to refresh a GnuPG keyring

 parcimonie is a daemon that slowly refreshes a GnuPG public keyring
 from a keyserver.
 .
 Its refreshes one key at a time; between every key update parcimonie:
   - sleeps a mostly random amount of time
   - asks Tor to change circuits.
 .
 This process is meant to make it hard for an attacker to correlate the
 multiple performed key update operations.
 .
 See the included design document to learn more about the threat and
 risk models parcimonie attempts to help coping with.


Packaging is mostly ready, Git repository:

  gbp-clone \
git://gaffer.ptitcanardnoir.org/App-Parcimonie.git \
--debian-branch=debian --pristine-tar

(upstream lives in master branch, apart of that it's a gbp-style
repository layout.)

Bye,
-- 
  intrigeri 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/85livgot0x@boum.org

Re: Call for teams interested in collaborating on a 'standard' Git workflow

[Lucas Nussbaum]

On 28/07/11 at 15:36 +0200, Lucas Nussbaum wrote:
> Hi,
> 
> It seems that many different teams have recently switched to Git, or are
> considering switching. But each of them seems to re-implement the wheel
> by designing their own Git workflow.
> 
> I think that it would be fantastic if we could collaborate on defining
> a common Git workflow. 
> 
> [...]
> 
> If you are interested in participating (which doesn't mean that you
> commit on behalf of your team to switch to that workflow, just that you
> want to participate in the discussions), add yourself (and your team) to
> http://wiki.debian.org/GitPackagingWorkflow.  If more than 3 teams are
> interested in a BOF at DC11, I'll try to organize one on saturday (all
> the video-broadcasted slots are taken, but we will make sure to take
> notes). If the BOF doesn't happen, I'll contact interested people to see
> how to continue.

Hi,

So a BOF happened at Debconf 11, and I've put the raw notes online at
http://wiki.debian.org/GitPackagingWorkflow/DebConf11BOF

My understanding of the situation is that we are ready to document a
workflow including:
- using git-buildpackage for basic stuff
- managing several repositories with mr
- managing and tracking the status of the repositories (e.g with PET)
- managing patches with quilt (the "nothing fancy" approach)
  + additionally, using a patch-queue system (but which one?) to
manage patches locally
- managing debian/changelog with git-dch

Some people expressed interest in starting a proper documentation on
that on the Debian wiki. I suggest to use the
http://wiki.debian.org/GitPackagingWorkflow (or maybe to extend the
http://wiki.debian.org/PackagingWithGit page).

We probably need more discussion:
- on patch queue managers
- on the "one-branch-per-patch" approaches

Also, Raphael Hertzog mentioned that the next version of dpkg will
unapply patches and remove .pc after the build, which should help with
managing patches in git.

- Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110730123502.ga28...@xanadu.blop.info

Re: Bug#636016: ITP: goodbye -- next part after 'hello', and a packaging example

[Adam Borowski]

On Sat, Jul 30, 2011 at 12:17:49PM +0200, Adam Borowski wrote:
> * Package name: goodbye
>   Git : git://gitorious.org/pkg-goodbye/goodbye.git
> 
> Using slow, bloated tools like debhelper and dpkg-dev will cost you precious
> SECONDS when building your package.  Multiplied by tens of thousands of
> packages Debian has, this can be a burden on archive rebuilds.  Thus, this
> is a proposal and example how to get rid of that inefficiency.
> 
> Written in a Real Man(tm)'s scripting language with a JIT compiler, it's
> over two orders of magnitude faster than mainstream packaging techniques.

Sorry for not linking to the .orig tarball (although there's nothing
interesting there).  Version 0.2 hushes a lintian --pedantic warning about
no upstream changelog.  We can't have such a stellar example clean with
merely the normal options :p

dget http://angband.pl/debian/pool/main/g/goodbye/goodbye_0.2-1.dsc

About suggestions for clojure and brainf*ck: really, I intended to use an
ELF object embedded in debian/rules.  The policy says it has to be an
executable makefile, but there is no requirement of it being a text file :p
Zero bytes and newlines would have to be escaped, but that's nothing new,
the tcc version already has to escape the latter.

It would satisfy the policy as long as the source would be present and used
during build -- but no one says we'd need to stay away from Ken Thompson
tricks.  There's a bunch of compilers in the archive already which do
require themselves to build.

-- 
1KB // Yo momma uses IPv4!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110730123646.ga32...@angband.pl

Re: Bug#636016: ITP: goodbye -- next part after 'hello', and a packaging example

[Stefano Zacchiroli]

On Sat, Jul 30, 2011 at 12:17:49PM +0200, Adam Borowski wrote:
> Using slow, bloated tools like debhelper and dpkg-dev will cost you precious
> SECONDS when building your package.  Multiplied by tens of thousands of
> packages Debian has, this can be a burden on archive rebuilds.  Thus, this
> is a proposal and example how to get rid of that inefficiency.
> 
> Written in a Real Man(tm)'s scripting language with a JIT compiler, it's
> over two orders of magnitude faster than mainstream packaging techniques.

OK, I bite (although I regret it already…).

In case you really want to upload this to the archive, can you make it
clear in the package description that the packaging practices embodied
by goodbye are just a show off of what can be done, but at the same time
that they are discouraged practices?

No matter how little the risk is, I don't think we want to risk that
people will imitate them in new packages.
-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Providing official virtualisation images of Debian

[Charles Plessy]

Le Sat, Jul 30, 2011 at 08:52:41AM +0200, olivier sallou a écrit :
> 
> For Amazon AMI, constraint is on Kernel/Ramfs. On amazon, those are not in
> the image(disk) but separated, and cannot be provided. Those must be
> pre-uploaded on amazon, and only some providers can do so (Ubuntu is one of
> them).

Hi Olivier,

actually, it is now possible to run user-provided kernels on the Amazon EC2, by
booting them via PVGRUB as explained in the following URL.

  http://aws.amazon.com/articles/3967

PVGRUB reads /boot/grub/menu.lst, and I just saw that grub2 contains
/usr/lib/grub-legacy/update-grub, which opens a way to keep this file up to
date when kernels are updated, via a kernel hook.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
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: http://lists.debian.org/20110730132337.gg32...@merveille.plessy.net

Bug#636041: ITP: libgsecuredelete -- wrapper library for the secure-delete tools

[intrigeri+debian]

Package: wnpp
Owner: intrigeri+deb...@boum.org
Severity: wishlist

* Package name: libgsecuredelete
  Version : 0.1
  Upstream Author : Colomban Wendling 
* URL or Web page : http://wipetools.tuxfamily.org/libgsecuredelete.html
* License : GPL-3+
  Description : wrapper library for the secure-delete tools

 GSecureDelete is a GObject wrapper library for the secure-delete tools
 (srm, sfill, sswap and smem), aiming to ease use of these tool from programs
 by providing a simple but complete API to invoke them.

Packaging repository:
  gbp-clone git://webmasters.boum.org/libgsecuredelete

Bye,
-- 
  intrigeri 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/857h6zq4w6@boum.org

Re: Providing official virtualisation images of Debian

[Ian Campbell]

On Fri, 2011-07-29 at 19:29 +0200, Iustin Pop wrote:
> On Fri, Jul 29, 2011 at 08:23:57PM +0400, Michael Tokarev wrote:
> > 29.07.2011 18:02, Aaron Toponce wrote:
> > > On Tue, Jul 26, 2011 at 12:27:09AM +0200, Moritz Mühlenhoff wrote:
> > >> What virtualisation solutions should be supported?
> > > 
> > > Open Virtualization Format (OVF) is the only format that should need to be
> > > supported. VirtualBox, VMWare, RHEV, AbiCloud, Citrix XenConvert, and
> > > OpenNode all support the format.
> > 
> > The problem with OVF is that it does not define actual disk image
> > format, it merely describes the VM for a management layer (like
> > libvirt), but makes no big effort to standardize disk format.
> > 
> > So it's basically useless in this context - it's kinda trivial to
> > provide the management stuff, the more important bit is the disk
> > content.
> 
> I wouldn't put it that strong :)
> 
> While it's true that OVF is 'weak' in respect to disk formats, one can
> choose and support a few widely-used formats to cover enough space.
> 
> This is exactly what we're doing now in the Ganeti project - after some
> consideration, supporting just raw, vmdk and the qcow variants seems to
> have wide-enough use to cover most interoperability issues. Free tools
> to convert to/from vhd is what I think is still missing.

FWIW the Xen project has a library (looks like a BSDish license) for
reading/writing vhd files, although I don't think there is actually a
conversion tool built using them at the moment (it exists as part of the
blktap PV disk backend). I expect it would not be too hard to build one
though.

On the other hand AIUI Virtual Box's vbox-img (GPL) can do VHD
conversion already, but I've not tried it myself.

> I think that for Debian's purposes, offering one of the above formats
> (most likely vmdk) should be good enough, at least for start.

Agreed.

Ian.
-- 
Ian Campbell


Man has made his bedlam; let him lie in it.
-- Fred Allen


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

Bug#636043: ITP: nautilus-wipe -- Secure deletion extension for Nautilus

[intrigeri+debian]

Package: wnpp
Owner: intrigeri+deb...@boum.org
Severity: wishlist

* Package name: nautilus-wipe
  Version : 0.1
  Upstream Author : Colomban Wendling 
* URL or Web page : http://wipetools.tuxfamily.org/nautilus-wipe.html
* License : GPL-3+
  Description : Secure deletion extension for Nautilus

 Nautilus Wipe is a Nautilus extension that adds "Securely erase" and
 "Securely fill empty space" items to the right-click menu.
 .
 The progress and results of the operations are shown in a progress
 dialog.

Packaging repository:

  gbp-clone git://webmasters.boum.org/nautiluswipe

Note that nautilus-wipe depends on libgsecuredelete, which just had
its own ITP filed.

Bye,
-- 
  intrigeri 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/851ux7q4rd@boum.org

Re: Providing official virtualisation images of Debian

[Charles Plessy]

Le Tue, Jul 26, 2011 at 08:41:06PM -0400, Kyle Moffett a écrit :
> 
> My current work is here:
>   http://opensource.exmeritus.com/debian-ami/
> 
> Please report any success or problems!

Dear Kyle,

I am studying debian-installer and your procedure.  I see that in you patch for
network-console, the public keys provided by the user to the instance running
debian-installer are used not only for d-i's network console, but also copied
to the AMI in preparation.  I think that this would prevent to share the AMI
publicly, as explained in http://alestic.com/2011/06/ec2-ami-security
(authorized_keys).  Others often use a rc.local or an init.d script to install
user-provided public keys each time the instance is ran, like for instance:
https://github.com/camptocamp/ec2debian-build-ami/blob/master/init.d/ec2-get-credentials

This is actually one of the reasons why I was wondering if a package containing
such files would help to progress towrards a procedure to create AMIs using
only material distributed in Debian.

Have a nice week-end,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
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: http://lists.debian.org/20110730141459.gh32...@merveille.plessy.net

Re: Removal of systemtap from testing

[Timo Juhani Lindfors]

Mehdi Dogguy  writes:
> Systemtap seems in pretty bad shape. Its removal from testing has been
> requested (See #635543) and will be effective by Saturday if still not
> fixed.
>
> It you still care about systemtap, please step up and offer your help to
> fix it.

Thanks for the warning. I care about systemtap. I use systemtap to debug
systems for which I always have root access anyway so I don't see
security problems as such a big deal. However, I can work on the build
failures and if patches for security bugs are available I can apply them
too.

I'm currently at debconf so I'll probably miss the Saturday deadline but
that's ok, it can be uploaded again. Please ping me on irc if you want
to meet at debconf.

-Timo


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/84vcunv96g@sauna.l.org

Re: Call for teams interested in collaborating on a 'standard' Git workflow

[David Goodenough]

On Saturday 30 Jul 2011, Lucas Nussbaum wrote:
> On 28/07/11 at 15:36 +0200, Lucas Nussbaum wrote:
> > Hi,
> > 
> > It seems that many different teams have recently switched to Git, or are
> > considering switching. But each of them seems to re-implement the wheel
> > by designing their own Git workflow.
> > 
> > I think that it would be fantastic if we could collaborate on defining
> > a common Git workflow.
> > 
> > [...]
> > 
> > If you are interested in participating (which doesn't mean that you
> > commit on behalf of your team to switch to that workflow, just that you
> > want to participate in the discussions), add yourself (and your team) to
> > http://wiki.debian.org/GitPackagingWorkflow.  If more than 3 teams are
> > interested in a BOF at DC11, I'll try to organize one on saturday (all
> > the video-broadcasted slots are taken, but we will make sure to take
> > notes). If the BOF doesn't happen, I'll contact interested people to see
> > how to continue.
> 
> Hi,
> 
> So a BOF happened at Debconf 11, and I've put the raw notes online at
> http://wiki.debian.org/GitPackagingWorkflow/DebConf11BOF
> 
> My understanding of the situation is that we are ready to document a
> workflow including:
> - using git-buildpackage for basic stuff
> - managing several repositories with mr
> - managing and tracking the status of the repositories (e.g with PET)
> - managing patches with quilt (the "nothing fancy" approach)
>   + additionally, using a patch-queue system (but which one?) to
> manage patches locally
> - managing debian/changelog with git-dch
> 
> Some people expressed interest in starting a proper documentation on
> that on the Debian wiki. I suggest to use the
> http://wiki.debian.org/GitPackagingWorkflow (or maybe to extend the
> http://wiki.debian.org/PackagingWithGit page).
> 
> We probably need more discussion:
> - on patch queue managers
> - on the "one-branch-per-patch" approaches
Eclipse recently moved to one-branch-per-patch, or at least one branch
per issue being fixed.  This seems to be the fashion.

David
> 
> Also, Raphael Hertzog mentioned that the next version of dpkg will
> unapply patches and remove .pc after the build, which should help with
> managing patches in git.
> 
> - Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/201107301626.30124.david.goodeno...@btconnect.com

Re: Call for teams interested in collaborating on a 'standard' Git workflow

[Benjamin Drung]

Am Samstag, den 30.07.2011, 16:26 +0100 schrieb David Goodenough:
> On Saturday 30 Jul 2011, Lucas Nussbaum wrote:
> > On 28/07/11 at 15:36 +0200, Lucas Nussbaum wrote:
> > > Hi,
> > > 
> > > It seems that many different teams have recently switched to Git, or are
> > > considering switching. But each of them seems to re-implement the wheel
> > > by designing their own Git workflow.
> > > 
> > > I think that it would be fantastic if we could collaborate on defining
> > > a common Git workflow.
> > > 
> > > [...]
> > > 
> > > If you are interested in participating (which doesn't mean that you
> > > commit on behalf of your team to switch to that workflow, just that you
> > > want to participate in the discussions), add yourself (and your team) to
> > > http://wiki.debian.org/GitPackagingWorkflow.  If more than 3 teams are
> > > interested in a BOF at DC11, I'll try to organize one on saturday (all
> > > the video-broadcasted slots are taken, but we will make sure to take
> > > notes). If the BOF doesn't happen, I'll contact interested people to see
> > > how to continue.
> > 
> > Hi,
> > 
> > So a BOF happened at Debconf 11, and I've put the raw notes online at
> > http://wiki.debian.org/GitPackagingWorkflow/DebConf11BOF
> > 
> > My understanding of the situation is that we are ready to document a
> > workflow including:
> > - using git-buildpackage for basic stuff
> > - managing several repositories with mr
> > - managing and tracking the status of the repositories (e.g with PET)
> > - managing patches with quilt (the "nothing fancy" approach)
> >   + additionally, using a patch-queue system (but which one?) to
> > manage patches locally
> > - managing debian/changelog with git-dch
> > 
> > Some people expressed interest in starting a proper documentation on
> > that on the Debian wiki. I suggest to use the
> > http://wiki.debian.org/GitPackagingWorkflow (or maybe to extend the
> > http://wiki.debian.org/PackagingWithGit page).
> > 
> > We probably need more discussion:
> > - on patch queue managers
> > - on the "one-branch-per-patch" approaches
> Eclipse recently moved to one-branch-per-patch, or at least one branch
> per issue being fixed.  This seems to be the fashion.

Did we?

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: Bug#636016: ITP: goodbye -- next part after 'hello', and a packaging example

[Adam Borowski]

On Sat, Jul 30, 2011 at 12:17:49PM +0200, Adam Borowski wrote:
> * Package name: goodbye

Well, I'm quite surprised that some people didn't take this as a joke.  I've
intentionally used over-the-top phrases like "a Real Man(tm)'s scripting
language" and so on to make it more obvious, but it seems some folks' sense
of humour is not aligned with mine.

The package is not a pure waste of time as it has educational value about
internals of Debian packages (and perhaps make's quoting rules as well), but
it's certainly not meant as something to be followed -- to the contrary, it
may point out things that should be banned by the policy.

So, my apologies for the confusion.

-- 
1KB // Yo momma uses IPv4!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110730165220.ga9...@angband.pl

Re: Call for teams interested in collaborating on a 'standard' Git workflow

[David Goodenough]

On Saturday 30 Jul 2011, Benjamin Drung wrote:
> Am Samstag, den 30.07.2011, 16:26 +0100 schrieb David Goodenough:
> > On Saturday 30 Jul 2011, Lucas Nussbaum wrote:
> > > On 28/07/11 at 15:36 +0200, Lucas Nussbaum wrote:
> > > > Hi,
> > > > 
> > > > It seems that many different teams have recently switched to Git, or
> > > > are considering switching. But each of them seems to re-implement
> > > > the wheel by designing their own Git workflow.
> > > > 
> > > > I think that it would be fantastic if we could collaborate on
> > > > defining a common Git workflow.
> > > > 
> > > > [...]
> > > > 
> > > > If you are interested in participating (which doesn't mean that you
> > > > commit on behalf of your team to switch to that workflow, just that
> > > > you want to participate in the discussions), add yourself (and your
> > > > team) to http://wiki.debian.org/GitPackagingWorkflow.  If more than
> > > > 3 teams are interested in a BOF at DC11, I'll try to organize one on
> > > > saturday (all the video-broadcasted slots are taken, but we will
> > > > make sure to take notes). If the BOF doesn't happen, I'll contact
> > > > interested people to see how to continue.
> > > 
> > > Hi,
> > > 
> > > So a BOF happened at Debconf 11, and I've put the raw notes online at
> > > http://wiki.debian.org/GitPackagingWorkflow/DebConf11BOF
> > > 
> > > My understanding of the situation is that we are ready to document a
> > > workflow including:
> > > - using git-buildpackage for basic stuff
> > > - managing several repositories with mr
> > > - managing and tracking the status of the repositories (e.g with PET)
> > > - managing patches with quilt (the "nothing fancy" approach)
> > > 
> > >   + additionally, using a patch-queue system (but which one?) to
> > >   
> > > manage patches locally
> > > 
> > > - managing debian/changelog with git-dch
> > > 
> > > Some people expressed interest in starting a proper documentation on
> > > that on the Debian wiki. I suggest to use the
> > > http://wiki.debian.org/GitPackagingWorkflow (or maybe to extend the
> > > http://wiki.debian.org/PackagingWithGit page).
> > > 
> > > We probably need more discussion:
> > > - on patch queue managers
> > > - on the "one-branch-per-patch" approaches
> > 
> > Eclipse recently moved to one-branch-per-patch, or at least one branch
> > per issue being fixed.  This seems to be the fashion.
> 
> Did we?
If I remember correctly part of the Indego annoucement was for the Mylyn
Git support was to move to one branch per issue.  When you open an issue to
work on it, it creates a branch, and then merges it back in when you close
the ticket.  

David


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/201107301754.41515.david.goodeno...@btconnect.com

autopkgtest / DEP8

[Ian Jackson]

I have just uploaded what I have called autopkgtest 2.0.0.
I have cured the bitrot and it now works for me on my on laptop.

It's in unstable (well, incoming right now) but you can install and
use the package on squeeze.  I've also pushed it to my git branch
  http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git/autopkgtest.git/

I have been testing it with schroot's LVM snapshots and there's a
README.schroot-setup which gives instructions for setting that up.
It also gives the URL of the patched mawk package.

If you don't want to bother with snapshots and lvm and so forth you
can just use the "null" virtualisation server to run tests on your
laptop/workstation.

Stefano has apparently set up an alioth project, and I expect the
master autopkgtest git branch to move there RSN.

I haven't been able to test the Xen virtualisation machinery, so that
may still be nonfunctional due to bitrot.

I missed my upload deadline by 2 minutes - dput finished 2 mins after
the end of the applause at the end of the debconf closing ceremony,
but I got it in under the wire :-).  I will be around this evening in
Banja Luka and after that will not be available until I get online
late on Monday.

Thanks to everyone for their interest.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20020.16502.85799.174...@chiark.greenend.org.uk

Bug#636072: ITP: stud -- scalable TLS unwrapping daemon

[Vincent Bernat]

Package: wnpp
Severity: wishlist
Owner: Vincent Bernat 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: stud
  Version : 0.1
  Upstream Author : Bump server team 
* URL : https://github.com/bumptech/stud
* License : Simplified BSD License
  Programming Lang: C
  Description : scalable TLS unwrapping daemon

stud is a network proxy that terminates TLS/SSL connections and
forwards the unencrypted traffic to some backend. It is designed to
handle tens of thousands of connections efficiently on multicore
machines.

stud has very few features. It is designed to be paired with an
intelligent backend like haproxy or nginx. It maintains a strict 1:1
connection pattern with this backend handler so that the backend can
dictate throttling behavior, maxmium connection behavior, availability
of service, etc.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk40VncACgkQKFvXofIqeU5+TwCgtGlqt9T6wYHpUGdZw7LqMMMJ
HiMAn1UNg0eVWfaZJgJrtuE7mp+rqGSH
=ZyNI
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110730190742.4302.53884.report...@neo.luffy.cx

Re: Bug#636072: ITP: stud -- scalable TLS unwrapping daemon

[Peter Samuelson]

[Vincent Bernat]
> stud is a network proxy that terminates TLS/SSL connections and
> forwards the unencrypted traffic to some backend. It is designed to
> handle tens of thousands of connections efficiently on multicore
> machines.

You should include some text to differentiate this from stunnel4.  From
the ITP, I cannot figure out why I would want this instead, or indeed,
why Debian should ship both.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110730204225.ga3...@p12n.org

Bug#636081: ITP: prayerwheel -- Tibetan prayer wheel

[Simon Kainz]

Package: wnpp
Severity: wishlist
Owner: Simon Kainz 


* Package name: prayerwheel
  Version : 0.0.1
  Upstream Author : Simon Kainz 
* URL : http://dharma-haven.org/tibetan/prayer-wheel.htm
* License : Public Domain
  Programming Lang: none
  Description : Tibetan prayer wheel

 This is very simple implementation of a tibetan prayer wheel.
 For a detailed explanation of a prayer wheel, please see
 http://dharma-haven.org/tibetan/prayer-wheel.htm
 This package provides a digital prayer wheel as explained in
 http://dharma-haven.org/tibetan/digital-wheels.htm
 Tibetan Buddhists believe that saying the mantra (prayer)
 "Om Mani Padme Hum"
 invites the blessing of Chenrezig, the embodiment of Compassion.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110730205903.4818.60508.reportbug@localhost.localdomain

Re: Providing official virtualisation images of Debian

[graziano obertelli]

I'm working at Eucalyptus Systems: I have been away at a conference, so
my apologies if this has already been mentioned.

On 07/30/2011 07:14 AM, Charles Plessy wrote:
> Le Tue, Jul 26, 2011 at 08:41:06PM -0400, Kyle Moffett a écrit :
>>
>> My current work is here:
>>   http://opensource.exmeritus.com/debian-ami/
>>
>> Please report any success or problems!
> 
> Dear Kyle,
> 
> I am studying debian-installer and your procedure.  I see that in you patch 
> for
> network-console, the public keys provided by the user to the instance running
> debian-installer are used not only for d-i's network console, but also copied
> to the AMI in preparation.  I think that this would prevent to share the AMI
> publicly, as explained in http://alestic.com/2011/06/ec2-ami-security
> (authorized_keys).  Others often use a rc.local or an init.d script to install
> user-provided public keys each time the instance is ran, like for instance:
> https://github.com/camptocamp/ec2debian-build-ami/blob/master/init.d/ec2-get-credentials
>
> This is actually one of the reasons why I was wondering if a package 
> containing
> such files would help to progress towrards a procedure to create AMIs using
> only material distributed in Debian.

Amazon's EMI and Ubuntu images are using cloud-init to pull in the keys,
and to do more (like installing packages, running user's scripts etc..).
I seem to remember that Scott Moser (author of cloud-init) was talking
of getting it into Debian, but I'm not sure about the progress.

We do provide some images to our users to test their Eucalyptus
installation, and we are in the process of refreshing them. Here is the
relevant part of rc.local we use (in case you can find it useful). We
pull in the public-keys then we look at the user-data and if it is a
script we execute it.

# simple attempt to get the user ssh key using the meta-data service
mkdir -p /root/.ssh
echo >> /root/.ssh/authorized_keys
curl -m 10 -s
http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key | grep
'ssh-rsa' >> /root/.ssh/authorized_keys
echo "AUTHORIZED_KEYS:"
echo ""
cat /root/.ssh/authorized_keys
echo ""

# check if the user-data is a script, and if so execute it
TMP_FILE="/tmp/user-data-$$"
curl --retry 3 --retry-delay 10 -o $TMP_FILE
http://169.254.169.254/latest/user-data
if [ -s $TMP_FILE ]; then
echo "Downloaded user data in $TMP_FILE"
if [ "`head -c 2 $TMP_FILE`" = "#!" ]; then
chmod 700 $TMP_FILE
echo "User data is a script: executing it"
sh $TMP_FILE
fi
fi

cheers
graziano


> Have a nice week-end,
> 

-- 
Graziano Obertelli
Eucalyptus Systems, Inc.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e347079.7040...@eucalyptus.com

Re: Bug#636081: ITP: prayerwheel -- Tibetan prayer wheel

[Samuel Thibault]

Simon Kainz, le Sat 30 Jul 2011 22:59:03 +0200, a écrit :
> * Package name: prayerwheel
>   Version : 0.0.1
>   Upstream Author : Simon Kainz 
> * URL : http://dharma-haven.org/tibetan/prayer-wheel.htm
> * License : Public Domain
>   Programming Lang: none
>   Description : Tibetan prayer wheel
> 
>  This is very simple implementation of a tibetan prayer wheel.
>  For a detailed explanation of a prayer wheel, please see
>  http://dharma-haven.org/tibetan/prayer-wheel.htm
>  This package provides a digital prayer wheel as explained in
>  http://dharma-haven.org/tibetan/digital-wheels.htm
>  Tibetan Buddhists believe that saying the mantra (prayer)
>  "Om Mani Padme Hum"
>  invites the blessing of Chenrezig, the embodiment of Compassion.

We definitely need to have this on all mirror harddrives, so it spins
for World Peace!

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110730211227.GH5444@const

Re: Bug#636072: ITP: stud -- scalable TLS unwrapping daemon

[Vincent Bernat]

OoO En cette soirée bien amorcée  du samedi 30 juillet 2011, vers 22:42,
Peter Samuelson  disait :

>> stud is a network proxy that terminates TLS/SSL connections and
>> forwards the unencrypted traffic to some backend. It is designed to
>> handle tens of thousands of connections efficiently on multicore
>> machines.

> You should include some text to differentiate this from stunnel4.  From
> the ITP, I cannot figure out why I would want this instead, or indeed,
> why Debian should ship both.

The  main  difference  is  that  stud  "handles  tens  of  thousands  of
connections efficiently on multicore  machines".  stunnel is not able to
get similar  performance due  to its threaded  model. Moreover,  stud is
really small  (ten times  smaller than stunnel)  which may  be important
From a security point of view.

I hope to backup those claims with some figures soon.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Don't compare floating point numbers just for equality.
- The Elements of Programming Style (Kernighan & Plauger)


pgpcGSgqh3Ljk.pgp
Description: PGP signature

Re: Providing official virtualisation images of Debian

[Yaroslav Halchenko]

Thank you Steffen -- very informative (at least to me, who has not went
into the cloud yet) and in general I share your side.

do you know if alestic guys are planing on preparing an AMI with
squeeze?

On Tue, 26 Jul 2011, Steffen Möller wrote:
> > I would love to have an official Debian Image for Amazon and other
> > cloud infrastructures.
> Please allow to bring
> http://alestic.com/
> with a series of fine images to your awareness. Those folks are not
> beaten too
> easily, and should rather be joined in some way.

> The cloudbiolinux.org community is also preparing Debian-based images.
> Everyone
> out there in the cloud not using Azure likes Debian and/or its
> derivatives. Rather than
> having their effort duplicated, I would aim at embracing them and find a
> niche for the
> with or next to us.

> That all said - we should be (and are) experimenting with those technologies
> and come up with bits that those downstreamers might not have yet
> thought of.
> There is for instance Rudy at the very moment exploiting cross-architecture
> virtualisation for the cloud with Eucalyptus as his Google Summer of
> Code project.

> Steffen
-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110731034359.gb5...@onerussian.com

Re: Providing official virtualisation images of Debian

[Charles Plessy]

Le Sat, Jul 30, 2011 at 11:44:00PM -0400, Yaroslav Halchenko a écrit :
> Thank you Steffen -- very informative (at least to me, who has not went
> into the cloud yet) and in general I share your side.
> 
> do you know if alestic guys are planing on preparing an AMI with
> squeeze?

No plans… http://groups.google.com/group/ec2debian/msg/8f12b422f881dbaa

Currently there are some Squeeze AMIs made available, and they are probably
good, but none of them is as strongly established as ‘the’ Debian AMIs as
Alsetic's are for Ubuntu.

I think that one way to get more blessing in Debian AMIs would be to build them
entirely from material distributed in Debian.  Luckily, as you have seen in
some other messages, it looks possible.

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
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: http://lists.debian.org/20110731044003.gb29...@merveille.plessy.net

Re: Bug#636016: ITP: goodbye -- next part after 'hello', and a packaging example

[Steve Langasek]

On Sat, Jul 30, 2011 at 06:52:20PM +0200, Adam Borowski wrote:
> On Sat, Jul 30, 2011 at 12:17:49PM +0200, Adam Borowski wrote:
> > * Package name: goodbye

> Well, I'm quite surprised that some people didn't take this as a joke.

It's hard to be sure something like this is a joke when packages like yada
are still in the archive.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature