Re: Call for Jessie Release Goals

[Mathieu Malaterre]

On Wed, Sep 11, 2013 at 9:17 PM, Jonathan Wiltshire  wrote:
> Release goals are areas of functionality which developers would like to see
> as an aim for the next release. They will not hold up the release, but
> allow the bugs opened for that goal to be of severity 'important'.

I am not sure if this qualify as "Release goals". So I'd like to ask
first what people think of using C++11 in the next release.

I know of a couple of C++ libraries which could be compiled with the
new gcc compilation option. And I have at least one application (no
shared lib) which requires C++11 to compile properly. Since C++11
introduce an ABI incompatibility [*], this may not be a Release Goal
but simply a tech-ctte decision.

Comments ?

-M

[*] http://gcc.gnu.org/wiki/Cxx11AbiCompatibility


-- 
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/CA+7wUswH4jbsGyU87g1e7d7QC=29-tq-q8pdawtuga2dgi1...@mail.gmail.com

Bug#723633: ITP: python-falcon -- supersonic micro-framework for building cloud APIs

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-falcon
  Version : 0.1.7
  Upstream Author : Kurt Griffiths 
* URL : http://falconframework.org
* License : Apache-2.0
  Programming Lang: Python
  Description : supersonic micro-framework for building cloud APIs

 Falcon is a high-performance Python framework for building cloud APIs. It
 encourages the REST architectural style, and tries to do as little as possible
 while remaining highly effective.
 .
 Unlike other Python web frameworks, Falcon won't bottleneck your API's
 performance under highly concurrent workloads. Many frameworks max out at
 serving simple "hello world" requests at a few thousand req/sec, while Falcon
 can easily serve many more on the same hardware.
 .
 Falcon isn't very opinionated. In other words, the framework leaves a lot of
 decisions and implementation details to you.
 .
 Features:
  * Intuitive routing via URI templates and resource classes
  * Easy access to headers and bodies through request and response classes
  * Idiomatic HTTP error responses via a handy exception base class
  * DRY request processing using global, resource, and method hooks
  * Snappy unit testing through WSGI helpers and mocks
  * 20% speed boost when Cython is available
  * Python 2.6, Python 2.7, PyPy and Python 3.3 support


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

Re: Bug#723640: ITP: vlc-plugin-vlsub -- VLC extension to download subtitles from opensubtitles.org

[Andrei POPESCU]

Control: reassign -1 wnpp

On Mi, 18 sep 13, 13:50:29, Simon Gareste wrote:
> Package: vlc-plugin-vlsub
> Severity: wishlist
> Owner: Simon Gareste 
> 
> * Package name: vlc-plugin-vlsub
>   Version : 0.9.10
>   Upstream Author : Guillaume Le Maout 
> * URL : 
> http://addons.videolan.org/content/show.php/?content=148752
> https://github.com/simongareste/vlsub-deb
> * License : GPL-3+
>   Programming Lang: lua
>   Description : VLC extension to download subtitles from opensubtitles.org
> Search and download subtitles from opensubtitles.org using the hash of
> the video currently playing or its title.
> 
> 
> -- 
> Simon Gareste

-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ian Jackson]

Russ Allbery writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
Debian branches)"):
> Ian Jackson  writes:
> > Or do you mean that you have files in your git branch which are removed
> > by debian/rules clean ?  (I'm no longer ruling anything out merely on
> > the grounds that it would be utterly insane...)
> 
> This is common.  Usually it's because upstream ships generated files in
> the upstream tarball as well as source files.  As part of building the
> Debian package from source, one wants to remove all generated files and
> recreate them.  Deleting those files in debian/rules clean is an obvious
> way to go about this.

I see.  So are those files in the source package or not ?

If they are then, a dgit user who uses git reset, git clean, dgit -wg
and sbuild won't see any problem from this, because they don't run
debian/rules clean in the build tree as part of preparing the source
package.

If they aren't then the dgit tree is not the same as "your" git tree,
which is fine for the NMUer.  It complicates your life as the
maintainer, though.

> Saving all the build products and restoring them on debian/rules clean is
> more trouble than I have any interest in doing, although patches are
> welcome, I suppose.

I think the right answer to these kind of problems is a vpath build,
or the moral equivalent.

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/21049.42764.430744.384...@chiark.greenend.org.uk

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ian Jackson]

Julien Cristau writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
Debian branches)"):
> No, I mean the upstream tarball contains autotools-generated files that
> debian/rules deletes (and that aren't in my, or upstream's, git tree).
> dpkg-source ignores removals when generating the debian diff, so they're
> extracted by dpkg-source -x, but since the first step after that is
> pretty much always debian/rules clean, they're irrelevant.

If your source package contains the files, and your git tree does too,
then you will find that debian/rules clean generates a dirty git tree.
How do you deal with this problem at the moment ?

I think that whatever solution you adopt will work for dgit too,
although you will want to pass "-wg" to dgit sbuild so that your
build doesn't run rules/clean but instead uses git-clean.

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/21049.42928.227688.836...@chiark.greenend.org.uk

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ben Hutchings]

On Wed, 2013-09-18 at 14:16 +0100, Ian Jackson wrote:
> Julien Cristau writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
> Debian branches)"):
> > No, I mean the upstream tarball contains autotools-generated files that
> > debian/rules deletes (and that aren't in my, or upstream's, git tree).
> > dpkg-source ignores removals when generating the debian diff, so they're
> > extracted by dpkg-source -x, but since the first step after that is
> > pretty much always debian/rules clean, they're irrelevant.
> 
> If your source package contains the files, and your git tree does too,
> then you will find that debian/rules clean generates a dirty git tree.
> How do you deal with this problem at the moment ?
[...]

Example from sgt-puzzles:

override_dh_auto_clean:
! [ -f Makefile ] || $(MAKE) clean
$(MAKE) -f Makefile.doc clean
if [ -d .git ]; then\
git checkout HEAD $(AUTOGEN_FILES); \
else\
rm -f $(AUTOGEN_FILES); \
fi
rm -f po
dh_clean debian/substvars gamedesc.txt version2.def

(I'm not claiming this is a good example).

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.


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

Re: Call for Jessie Release Goals

[Dmitrijs Ledkovs]

On 18 September 2013 03:42, Mathieu Malaterre  wrote:
> On Wed, Sep 11, 2013 at 9:17 PM, Jonathan Wiltshire  wrote:
>> Release goals are areas of functionality which developers would like to see
>> as an aim for the next release. They will not hold up the release, but
>> allow the bugs opened for that goal to be of severity 'important'.
>
> I am not sure if this qualify as "Release goals". So I'd like to ask
> first what people think of using C++11 in the next release.
>
> I know of a couple of C++ libraries which could be compiled with the
> new gcc compilation option. And I have at least one application (no
> shared lib) which requires C++11 to compile properly. Since C++11
> introduce an ABI incompatibility [*], this may not be a Release Goal
> but simply a tech-ctte decision.
>
> Comments ?
>

I think I have replied about similar requests before (not sure if it
was on these mailing lists).
In essence, at the moment we do not have any compiler & stdlib with
complete and stable ABI for C++11.
It is expected that gcc4.8 will break C++11 ABI to further implement
the standard.
Other non-default compilers also are fully featured at the moment
(w.r.t. C++11 compiler features).
Thus at the moment we cannot consider switching. One can compile with
C++11 enable where one must, but also one then gets to keep the ABI
incompatibilities down the road (boost / template libraries
especially).

While one would want to start using C++11, it's not default at the
moment and not feasible to make the default standard level C++11.

Regards,

Dmitrijs.


-- 
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/CANBHLUgYHMH6OymwjNc-b2O_ryuv6i_wKqDd=cnvmgzdb07...@mail.gmail.com

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Cyril Brulebois]

Ian Jackson  (2013-09-18):
> Julien Cristau writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
> Debian branches)"):
> > No, I mean the upstream tarball contains autotools-generated files that
> > debian/rules deletes (and that aren't in my, or upstream's, git tree).
> > dpkg-source ignores removals when generating the debian diff, so they're
> > extracted by dpkg-source -x, but since the first step after that is
> > pretty much always debian/rules clean, they're irrelevant.
> 
> If your source package contains the files, and your git tree does too,
> then you will find that debian/rules clean generates a dirty git tree.
> How do you deal with this problem at the moment ?

That would be silly, but that isn't what Julien is concerned about.
See the first two lines.

Mraw,
KiBi.


-- 
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/20130918134555.gb15...@mraw.org

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ian Jackson]

Steve Langasek writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
Debian branches)"):
> On Tue, Sep 17, 2013 at 07:19:22PM +0100, Ian Jackson wrote:
> > TBPH I think it's a bug if build followed by clean doesn't restore the
> > package to the state you got out of dpkg-source.  I don't want to
> > argue that as a policy change right now, but I don't have much
> > interest in adding code to dgit to better support the maintainers of
> > packages which are broken in this way.
> 
> My understanding is that the current policy implies that the 'dpkg-source -x'
> -> './debian/rules clean' -> 'dpkg-source -b' round-trip should be
> idempotent for all practical purposes,

Yes.

> just as the './debian/rules build' ->
> './debian/rules clean' round-trip should be.  So if ./debian/rules clean
> does something to a checkout of your branch, then that branch seems not to
> be a complete representation of the source package.

However, it appears from the rest of the thread that dpkg-source has a
hack in it which stops it recording the deletion of files, so that the
"dpkg-source -b" step edits the source on the way into the package.
There will be packages that rely on this.

> There are various reasons this might be the case - for instance,
> autogenerated autotools output that you want shipped in the source package
> but don't store in the repository - but these all still amount to imperfect
> representations of the source package, and dgit shouldn't cater to them.
> Either debian/rules clean should be fixed to not leave droppings, or if the
> output is not 'droppings', it should be part of the VCS history.

Well, I agree.


But ultimately I think what we're missing in this conversation is a
key underlying goal of dgit's design:

dgit is designed so that there is a single same coherent workflow for
NMUers and downstreams; and with that workflow supporting use of git's
source code management facilities (notably git reset and git clean).

The resulting design principles are:

 * You should be able to work on a package without needing to
   understand the maintainer's workflow.

 * Every change to the source code (as represented by the Debian
   package) should be done via git.

 * Changes to the working tree should be managed with git as far as
   possible.

 * dgit should provide its user with convenient workarounds for
   bugs and craziness in package build systems and dpkg-source.

 * dgit's output, as seen by non-dgit users, should be compliant with
   Debian's policies and processes, and tolerable to maintainers, but
   not necessarily any better than that.

So to mention two of those convenient workarounds:

 * The dgit user can trivially cope with packages which edit their own
   source code, or delete bits of it, during build or clean.  git
   reset or checkout will sort that out for you.

 * The dgit user can trivially cope with packages whose rules/clean
   target is buggy.  During work, you specify -wg to use git clean
   rather than rules clean.  For the release you use "dgit -wg
   sbuild", which arranges that the tree you are using will be
   subjected to git clean rather than rules/clean.  The use of sbuild
   means you don't care about damage done to the source by the binary
   package build, and if you're not using sbuild you can use git reset
   and git clean after dgit -wg sbuild to undo whatever the build may
   have done.


Convenience for maintainers' use of dgit is a secondary goal.

In particular, it is a secondary goal that the dgit git history should
be the same as upstream's or the maintainer's git history.  If the
maintainer's git trees are different to the source packages, and
therefore not useful for dgit, then the maintainer is inconvenienced
by not being able to use dgit; but all dgit's users can remain in
blissful ignorance.

Of course I am of the view that the correct contents of the git repo
and of the source package are the same.  A maintainer who agrees with
this view will find that dgit helps support their workflow.

If this limitation leads to rejection of dgit amongst maintainers
whose workflows and source code management practices are less than
ideal, then that's acceptable, because dgit's usefulness doesn't
depend on adoption by maintainers.


That's not to say that there aren't things that dgit needs to do
better.  In particular, there isn't currently good enough support for
maintaining a patch series for your package _in git_.

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/21049.44807.575382.648...@chiark.greenend.org.uk

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ian Jackson]

Ben Hutchings writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
Debian branches)"):
> Example from sgt-puzzles:
> 
> override_dh_auto_clean:
>   ! [ -f Makefile ] || $(MAKE) clean
>   $(MAKE) -f Makefile.doc clean
>   if [ -d .git ]; then\
>   git checkout HEAD $(AUTOGEN_FILES); \
>   else\
>   rm -f $(AUTOGEN_FILES); \
>   fi
>   rm -f po
>   dh_clean debian/substvars gamedesc.txt version2.def

OMG WTF BBQ

Although I can see that it will work, and work with dgit too.  Hmmm.
Maybe my initial reaction is overblown and I should be thinking "neat
hack".

IWBNI Policy had something to say about what assumptions a package's
build system is allowed to make about the contents of any .git it may
find.

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/21049.44923.481572.470...@chiark.greenend.org.uk

Re: Call for Jessie Release Goals

[Matthias Klose]

Am 18.09.2013 15:38, schrieb Dmitrijs Ledkovs:
> On 18 September 2013 03:42, Mathieu Malaterre  wrote:
>> On Wed, Sep 11, 2013 at 9:17 PM, Jonathan Wiltshire  wrote:
>>> Release goals are areas of functionality which developers would like to see
>>> as an aim for the next release. They will not hold up the release, but
>>> allow the bugs opened for that goal to be of severity 'important'.
>>
>> I am not sure if this qualify as "Release goals". So I'd like to ask
>> first what people think of using C++11 in the next release.
>>
>> I know of a couple of C++ libraries which could be compiled with the
>> new gcc compilation option. And I have at least one application (no
>> shared lib) which requires C++11 to compile properly. Since C++11
>> introduce an ABI incompatibility [*], this may not be a Release Goal
>> but simply a tech-ctte decision.
>>
>> Comments ?
>>
> 
> I think I have replied about similar requests before (not sure if it
> was on these mailing lists).
> In essence, at the moment we do not have any compiler & stdlib with
> complete and stable ABI for C++11.
> It is expected that gcc4.8 will break C++11 ABI to further implement
> the standard.

Well, GCC 4.8 should not "break" anything more.  Upcoming GCC versions may be
another matter.

Did somebody try to rebuild the archive in c++11 mode?

  Matthias


-- 
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/5239b2c2.8070...@debian.org

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ben Hutchings]

On Wed, 2013-09-18 at 14:49 +0100, Ian Jackson wrote:
> Ben Hutchings writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
> Debian branches)"):
> > Example from sgt-puzzles:
> > 
> > override_dh_auto_clean:
> > ! [ -f Makefile ] || $(MAKE) clean
> > $(MAKE) -f Makefile.doc clean
> > if [ -d .git ]; then\
> > git checkout HEAD $(AUTOGEN_FILES); \
> > else\
> > rm -f $(AUTOGEN_FILES); \
> > fi
> > rm -f po
> > dh_clean debian/substvars gamedesc.txt version2.def
> 
> OMG WTF BBQ
> 
> Although I can see that it will work, and work with dgit too.  Hmmm.
> Maybe my initial reaction is overblown and I should be thinking "neat
> hack".

What I should really do here is to stop bothering with upstream tarballs
and use the upstream branch (converted with git-svn) which doesn't
include those generated files.  But NMUers will find it difficult to
update the git-svn branch and dgit doesn't fix that.  And in the general
case even that may not be an option (there might be no public VCS, or
upstream might have committed the generated files).

Ben.

> IWBNI Policy had something to say about what assumptions a package's
> build system is allowed to make about the contents of any .git it may
> find.


-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.


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

Re: Anybody using quilt?

[Jonathan Dowland]

On Mon, Aug 26, 2013 at 05:59:41PM +0400, Игорь Пашев wrote:
> https://wiki.debian.org/Projects/DebSrc3.0
> 
> Anything other looks bad :-)

I think guilt attempts to address something that 3.0 leaves unresolved.


-- 
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/20130918134718.GB32614@debian

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Julien Cristau]

On Wed, Sep 18, 2013 at 14:16:32 +0100, Ian Jackson wrote:

> Julien Cristau writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
> Debian branches)"):
> > No, I mean the upstream tarball contains autotools-generated files that
> > debian/rules deletes (and that aren't in my, or upstream's, git tree).
> > dpkg-source ignores removals when generating the debian diff, so they're
> > extracted by dpkg-source -x, but since the first step after that is
> > pretty much always debian/rules clean, they're irrelevant.
> 
> If your source package contains the files, and your git tree does too,
> then you will find that debian/rules clean generates a dirty git tree.
> How do you deal with this problem at the moment ?
> 
You might want to read again.  My git tree does *not* contain these
files.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ian Jackson]

Julien Cristau writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
Debian branches)"):
> On Wed, Sep 18, 2013 at 14:16:32 +0100, Ian Jackson wrote:
> > Julien Cristau writes ("Re: Status of dgit (good for NMUs and 
> > fast-forwarding Debian branches)"):
> > > No, I mean the upstream tarball contains autotools-generated files that
> > > debian/rules deletes (and that aren't in my, or upstream's, git tree).
> > > dpkg-source ignores removals when generating the debian diff, so they're
> > > extracted by dpkg-source -x, but since the first step after that is
> > > pretty much always debian/rules clean, they're irrelevant.
> > 
> > If your source package contains the files, and your git tree does too,
> > then you will find that debian/rules clean generates a dirty git tree.
> > How do you deal with this problem at the moment ?
> 
> You might want to read again.  My git tree does *not* contain these
> files.

Sorry, yes I evidently didn't read clearly enough.  I think other
responses in the thread discuss this situation.

Thanks,
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/21049.51842.915507.13...@chiark.greenend.org.uk

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ian Jackson]

Cyril Brulebois writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
Debian branches)"):
> Charles Plessy  (2013-09-18):
> > for a small native package that I prepared, I would like to indicate dgit's
> > repository as VCS in its source control file (Vcs-Browser and Vcs-Git 
> > fields).
> > 
> > However, it does not clone nor browse well:
> >  - 
> > ‘http://anonscm.debian.org/gitweb/?p=dgit-repos/repos/pv-grub-menu.git;a=tree’
> >gives ‘404 - Reading tree failed’.

That it doesn't browse well is indeed annoying.  On the server the
dgit suite branch ref names aren't in refs/heads/, which is needed to
stop git pushing to them by default.  But that makes gitweb not show
them either.  I'm open to suggestions for how to improve this.

If you make a master branch and put something useful on it, then this
will work.

NB that you can't really use the dgit suite branch (refs/dgit/)
in dgit-repos as a working branch, because it is only updated by dgit
push - so you can't use it for sharing work.

> >  - ‘git clone git://anonscm.debian.org/dgit-repos/repos/pv-grub-menu.git’ 
> > gives
> >‘warning: remote HEAD refers to nonexistent ref, unable to checkout.’
> 
> HEAD probably points to master, and there's no branch at all, just two tags.

Yes.  (They're not tags, they're refs which are actually treated more
like branches than tags.)

Creating a master branch will fix this problem too.

Alternatively, of course, you can use dgit clone.

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/21049.53466.25.778...@chiark.greenend.org.uk

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Russ Allbery]

Ian Jackson  writes:
> Russ Allbery writes:

>> This is common.  Usually it's because upstream ships generated files in
>> the upstream tarball as well as source files.  As part of building the
>> Debian package from source, one wants to remove all generated files and
>> recreate them.  Deleting those files in debian/rules clean is an
>> obvious way to go about this.

> I see.  So are those files in the source package or not ?

They are.

> If they are then, a dgit user who uses git reset, git clean, dgit -wg
> and sbuild won't see any problem from this, because they don't run
> debian/rules clean in the build tree as part of preparing the source
> package.

Ah, good, then it sounds like it handles that all correctly.

>> Saving all the build products and restoring them on debian/rules clean
>> is more trouble than I have any interest in doing, although patches are
>> welcome, I suppose.

> I think the right answer to these kind of problems is a vpath build,
> or the moral equivalent.

The problem, of course, being that these files are usually the support
files that have to be in place before the build system understands VPATH.
Although it would be interesting, as a development project, to teach
Autoconf and friends how to use input files from a different directory and
bootstrap a build directory from scratch.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txhijdwa@windlord.stanford.edu

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ian Jackson]

Adam Borowski writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
Debian branches)"):
> On Tue, Sep 17, 2013 at 07:02:04PM +0100, Ian Jackson wrote:
> > Or you could simply ignore the format `3.0 (quilt)' thing entirely and
> > allow it to automatically accumulate one diff per upload, and
> > presumably clean it out occasionally.
> 
> There's more to "3.0 (quilt)" than just quilt:
> * multiple tarballs (good)
> * a way to include binaries without uuencode (good)
> * upstream debian/ is nuked (sometimes good, at worst a minor waste of
>   space and a minor inconvenience)

Right.

> Here's one way:
> rm -rf .pc debian/patches
> echo single-debian-patch >>debian/source/options
> 
> The rm needs to be repeated, either in the "clean" target or perhaps by
> dgit.

I don't think removing .pc and debian/patches will DTRT because
dpkg-source -x will produce a directory containing them.  dgit's idea
of "the source tree from the source package" is "whatever dpkg-source
-x produces".

I think even if you put single-debian-patch in debian/source/options,
you'll find that dgit still needs to make the spurious commit on your
git head to represent the results of dpkg-source --commit (that is, to
represent the changes to .pc and debian/patches.

It would be nice if there were a source format that:
 * Could represent every change to a source tree (including the
   deletion of upstream files!)
 * Did not insist in including droppings in the trees it manages.
 * Supported multiple tarballs.

> This turns "3.0 (quilt)" into "3.0 (sane)" and allows using version
> control without having to go out of your way to work around quilt.

Single-patch "3.0 (quilt)" is still IMO insane.  The droppings in .pc
and debian/patches (which require workarounds in dgit) also mean (for
example) that a debdiff of a one-line change contains a giant pile of
poo.

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/21049.55273.443618.587...@chiark.greenend.org.uk

Bug#723666: ITP: libio-prompt-tiny-perl -- module that prompts for user input with a default option

[Marius Gavrilescu]

Package: wnpp
Owner: Marius Gavrilescu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libio-prompt-tiny-perl
  Version : 0.002
  Upstream Author : David Golden 
* URL : https://metacpan.org/release/IO-Prompt-Tiny
* License : Apache-2.0
  Programming Lang: Perl
  Description : module that prompts for user input with a default option

This is an extremely simple prompting module, based on the extremely simple
prompt offered by ExtUtils::MakeMaker.In many cases, that's all you need and
this module gives it to you without all the overhead of ExtUtils::MakeMaker
just to prompt for input.

It doesn't do any validation, coloring, menus, timeouts, or any of the wild,
crazy, cool stuff that other prompting modules do. It just prompts with a
default. That's it!


-- 
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/e1vmkp3-yx...@ieval.ro

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Russ Allbery]

Ian Jackson  writes:

> If your source package contains the files, and your git tree does too,
> then you will find that debian/rules clean generates a dirty git tree.
> How do you deal with this problem at the moment ?

Generally by not running debian/rules clean in my source repository or, if
so, running git reset --hard afterwards.  Yes, it's not particularly
appealing, but it's better than the alternatives: not regenerating
upstream files that are actually build products, not having debian/rules
clean put the source package back into a functionally equivalent state as
before the build, or having to munging the upstream tarball extensively.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9jajcy1@windlord.stanford.edu

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ian Jackson]

Ben Hutchings writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
Debian branches)"):
> Example from sgt-puzzles:
> 
> override_dh_auto_clean:
>   ! [ -f Makefile ] || $(MAKE) clean
>   $(MAKE) -f Makefile.doc clean
>   if [ -d .git ]; then\
>   git checkout HEAD $(AUTOGEN_FILES); \
>   else\
>   rm -f $(AUTOGEN_FILES); \
>   fi
>   rm -f po
>   dh_clean debian/substvars gamedesc.txt version2.def
> 
> (I'm not claiming this is a good example).

You know, the more I think about this the more I like it.

Perhaps dh_autoreconf should do this, rather than simply deleting the
files and relying on a bodge in dpkg-source.

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/21049.55331.115743.671...@chiark.greenend.org.uk

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Russ Allbery]

Ian Jackson  writes:

> Single-patch "3.0 (quilt)" is still IMO insane.  The droppings in .pc
> and debian/patches (which require workarounds in dgit) also mean (for
> example) that a debdiff of a one-line change contains a giant pile of
> poo.

I don't understand what you mean by this.  I do debdiffs between
single-debian-patch 3.0 (quilt) packages (for security fixes, for
example), and I don't recall seeing giant piles of poo, just the relevant
change to the single patch.  I don't recall ever seeing changes to .pc
files in debdiffs.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87six2hxm4@windlord.stanford.edu

Bug#723672: ITP: libdancer-plugin-database-core-perl -- shared core library for Dancer and Dancer2 database plugins

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libdancer-plugin-database-core-perl
  Version : 0.04
  Upstream Author : Alberto Manuel Brand�o Sim�es 
* URL : https://metacpan.org/release/Dancer-Plugin-Database-Core
* License : Artistic-2.0
  Programming Lang: Perl
  Description : shared core library for Dancer and Dancer2 database plugins

Dancer::Plugin::Database::Core should not be used directly. It is a shared
library for Dancer::Plugin::Database and Dancer2::Plugin::Database modules.


-- 
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/20130918172427.ga7...@jadzia.comodo.priv.at

Re: using packages from sid on travis-ci.org

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 15/09/13 23:34, Roger Leigh wrote:
> On Tue, Sep 10, 2013 at 10:42:09PM +0200, Daniel Pocock wrote:
>> 
>> 
>> Some of the upstream projects I work on use travis-ci.org for
>> continuous integration
>> 
>> In some cases I'd like to configure builds that depend on
>> packages from Debian unstable, but I'm not sure of the Ubuntu or
>> travis way of doing that, has anybody dealt with this before?  Or
>> is there a Debian alternative?
> 
> You can configure travis to add additional apt sources and then
> install packages from them, e.g.
> 
> before_install: - sudo add-apt-repository -y "deb
> http://archive.ubuntu.com/ubuntu/ raring main universe" - sudo
> apt-get -qq update - if [[ $BUILD != 'sphinx' ]]; then sudo apt-get
> install -qq python-genshi; fi - if [[ $BUILD == 'cppwrap' ]]; then
> sudo apt-get install -qq build-essential cmake libboost-all-dev;
> fi - if [[ $BUILD == 'sphinx' ]]; then sudo apt-get install -qq
> python-sphinx; fi - if [[ $BUILD == 'sphinx' ]]; then sudo apt-get
> -y install texlive-latex-base texlive-latex-recommended
> texlive-xetex; fi - if [[ $BUILD == 'sphinx' ]]; then sudo apt-get
> -y install texlive-latex-extra texlive-fonts-recommended tex-gyre;
> fi - if [[ $BUILD == 'sphinx' ]]; then sudo fc-cache -rsfv; fi
> 
> In this case, we're updating to a newer version of Ubuntu and
> installing packages from it, but you can probably do exactly the
> same for unstable.
> 

Thanks for this feedback, I managed to get my dependency into saucy
and it is working with that approach

However, I suspect that sooner or later I will need to just get things
directly from sid (or testing) so that I am always using the versions
likely to be released.  I've never tried doing such a dist-upgrade
from Ubuntu but if it can all happen without any user input then I
will give it a go.



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJSOg8BAAoJEOm1uwJp1aqDZ4gP/iHuYUsEqZ7nz4b/Ddc9JP6z
NQghvjLIWX5X7imX+vMCyhB5gW3gif9j7JVb3CDVxDJcVHsNQfny2xGgHneUxHTn
uwaKsds2Wk8vev/IiugssycdoFhm0TP3hdLzXSRb4aP5Y1kMsRdwPlv+cWzVITKd
g/cSayTG737cnUC//0T1LiwkFcRH2vdY09QvL5Q4ctik9RFc6F9bbBUcTK+oUz/V
AOVpX4n6ZIMpsq1jmcKBlz1RkU4wDF436pgvS9DRwklhAPKovzsdO6KST96KgYKO
Exf4dT3uoSYD/LuBFvZZ+16OsQX2Lj+skDDKP1qI3Wgu7xnKHLo/xV0S/tmQv9Qo
0cSiaMlT5+Y4ZyvKwe2M4jbh2T+pS9wY4nHuHblX9thMxMDPM96HCoEzcBjKbHiE
NtoQ8lNgV3lQAqE98zTGesoXmex6b+u5Ok0pc0YbExbG0lANPW6lT5WIMF+ckRJv
xwJRvUn2jqChCsBANEFD8EKkDCsu8S1IuTcCXrCwBOocHGzEji7SfRkhpq0pk+W+
cb4T6DH9otbWDm1Egc7xTvpSyzkYSh6ADxycISM/K5GQjMUZI4TgQAK+8BCAga7V
DpC8Rt4U7kjeE6n3wDLjjXK6Fw/IlPU2fBuMtXqZAIDvVDBfXBu2+JiFReS3uasL
AtSsmwCzZHK3hmwDNt4G
=3QZi
-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/523a0f01.2010...@pocock.com.au

Re: Biological data being used by an unpublished research paper is considered proprietary

[Faheem Mitha]

Hi Peter,

Thank you for your very helpful answer. Seriously, it is rare to get
such a good answer on such a topic. I actually read your response on
academia.sx before you saw your email, and I should have guessed such
a good reason would have come from a Debian person. Also, I see you
registered the same day as your answer. :-)

I'm keeping debian-devel and debian-med cc'd for now, because I do
have some general questions about biological data licensing. If the
lists want me to go away, just say so.

Since you posted your answer publicly, I'm assuming you don't mind if
I quote it. I recommend you post your answer to the Debian lists,
since there is no guarantee that academia.sx will be around forever.

See responses inline. I'm afraid there are a lot of questions, but I
really can't pass up the opportunity to get some answers for
once. Sorry about that.

If you don't want to answer my questions (and let's face it, you
probably don't) perhaps you can suggest some suitable mailing
list(s)/forum(s)?

On Mon, 16 Sep 2013, Peter Rice wrote:


On 16/09/2013 11:31, Faheem Mitha wrote:



Hi,



This is really not Debian-related, except insofar as the software in
question is something that might have been in Debian one day. I talked
about that with people on debian-med recently. So, it is technically
off-topic.



I posted a reply on stackexchange with instructions to get the data
from the EBI SRS server.



However, I have run into this issue before in the context of
biological database entries and Debian so it may be worth discussing
here. There were objections to including SwissProt entries in the
example data for the EMBOSS package because the licensing of
SwissProt does not allow them to be edited.  That was resolved by
agreeing that scientific facts should not be edited so that the
files could be accepted as part of a Debian package even though they
could not be changed. A fine compromise I feel.


So, what license did these files go into Debian as?


regards,

Peter Rice
EMBOSS team



The copyright is probably on the full database release flatfile and
the formatted entries ... you will find similar conditions for
UniProt/SwissProt so it is not so unusual.


Yes, but I'm not trying to download their entire database, just a
small portion of it.


The restrictions on scripts are common to prevent server performance
hits from a large number of requests.


Is such a restriction legally enforceable? I don't see how one can
distinguish between a human user downloading using say curl, and a
script using curl with random pauses between downloads. Or is acceding
to such a request just a matter of common courtesy?


You can simply invite reviewers to download the data from some other
server, for example from the EBI SRS server. The URL for entry
A00673 would be



"http://srs.ebi.ac.uk/srsbin/cgi-bin/wgetz?[IMGTLIGM-ID:a00673]+-view+FastaSeqs+-ascii";


Wow, that works for me! Cool. I've tried before to download data from
other biological data web services, but have always fallen down
confused at the complexity of the sites and the multiplicity of their
options. IMGT is practically the only such site I have found which I
found I was able to navigate without getting brain fever.

http://www.ebi.ac.uk/miriam/main/collections/MIR:0287

So a few possibly dumb questions.

Question 1: Is there no general agreement on the licensing of
biological data such as that the kind we are talking about? This seems
strange. Aren't such data biological "facts", as you put it in your
message? To me, it makes as much sense to try to treat the list of
prime numbers or any other such mathematical facts as proprietary
information.

Specifically, I don't understand how IMGT can claim to own this data,
to the extent of forbidding its redistribution. They didn't produce
this data themselves, did they?

Question 2: It looks like EBI is hosting a copy of the IMGT
database. Is that right?

Also, there are a lot of different kinds of accession numbers. Which
accession numbers is IMGT using here?

Also, do you know of other servers that have the same data?


You can also use a list of accessions, for example A00673 or A01650



"http://srs.ebi.ac.uk/srsbin/cgi-bin/wgetz?[IMGTLIGM-ID:a00673|a01650]+-view+FastaSeqs+-ascii"



If downloading many entries you should pause between requests, but
putting lists into the URLs may reduce it to few enough not to cause
a problem. I doubts EBI would be upset by 200 requests - they would
be concerned about thousands.


This is *really* useful. I see each of these "list" requests produces
one fasta file with multiple sequences in them. I think this is be a
better way to go rather than producing hundreds of fasta files, each
containing a single sequence, as I have been doing. Also, unlike IMGT,
one justs downloads a FASTA file directly, without having to trim off
HTML stuff. I suspect that each request corresponds at the backend to
a SQL query, and if so, I'm sure the system would prefer one larger
SQL quer

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Joey Hess]

Ian Jackson wrote:
> That it doesn't browse well is indeed annoying.  On the server the
> dgit suite branch ref names aren't in refs/heads/, which is needed to
> stop git pushing to them by default.  But that makes gitweb not show
> them either.  I'm open to suggestions for how to improve this.
> 
> If you make a master branch and put something useful on it, then this
> will work.

My suggestion is to have dgit also push the dgit branch to the
remotes/dgit/master branch, as long as remotes/dgit/master is
an ancestor of the dgit branch, or does not yet exist.

Some dgit users may want to have a master branch that is not connected
to the dgit history. They can simply make one forced push of the master
branch to prevent dgit from handling it.

When multiple suites are involved, dgit currently does not connect
the history of the branches for those suites. So if a package is
first pushed to unstable (creating the master branch), and later to
experimental, the master branch would not be updated. This is probably
what we want to happen. OTOH, if a package is first released to
experimental (creating the master branch), later uploads to unstable
would not update the branch. This might be an unusual case that should
be handled with a forced push. Or, dgit could hardcode the name "sid"
along with the rest of its collection of per-distribution values
and only push master along with dgit/sid.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Decision on R datasets

[Dirk Eddelbuettel]

Joerg Jaspert  debian.org> writes:
> it came to our attention[0] that most R packages ship data files (*.Rda,
> *.Rdata), which can contain a lot of different kind of data, from
> command line instructions, to huge data tables, or even extra modules
> loaded by means of install.packages() function.
> 
> It is common practice for R packages to fully document the content of
> the data files in .Rd files shipped in the source tarball[1], so it
> becomes easier to determine which kind of information those data files
> provide.

As this may not be common knowledge among Debian developers, I would also
like to point out that the CRAN network [the package mirrors for R, 
containing more than 4800 source packages, and having ~200 global mirrors] 
does extensive checks on incoming new packages which are very much inline 
with Debian's views.  PDF vignettes need to rebuildable from source, data 
sets much be documented etc pp.

CRAN does very extensive checks on incoming packages (and sometimes gets
some heat from the R Community over the proces; see recent r-devel email 
threads).

I think it is worthwhile to point this out. Debian is not the only 
organization taking this issue very seriously.

> Data files can contain modules loaded at runtime, for which we do not
> usually have corresponding source code shipped in the package (or even

I've been around R and a user/contributor/author for maybe 15 years, and 
I'd say that this is _extremely_ rare. Mostly these are in fact just data 
structures, possibly nested.  Saving your session in RData format for
redistribution is not common practice. RData / rda files almost always
contain data.

And they are generally documented, and often available from source. Eg the 
r-base-core package ['package' in the Debian sense] contains a package 
['package' in the R sense, something loaded by library()] called datasets
with multiple data files. For efficiency these are packaged together, but 
the source tarball has them as code, often as a structure.  [ You can 
always call dput() on an R object and it will print an ascii 
representation.]

On the other hand, some packages contain files in .rda (or .RData) format
in their sources. An example is eg tseries (aka r-cran-tseries) which 
switched to .rda when R started to mandated / recommend / prefer this more
compact representation. All .rda files do have corresponding help pages 
with source information but do not have 

> anywhere, if it was modified and saved without keeping the source file),
> or can contain malicious code as well. This is a very extreme corner
> case, but you cannot know it in advance.

Again, I think that is rare.
 
> This is an example of a R library without source code:
> 
> > install.packages("sig")

Not part of Debian though, ie one the 4600-ish package on CRAN but not in 
Debian (we have maybe 200 or so).

> [snip]
> > library("sig")
> > save(sig, file="mydata")
> >
> 
> When users load the data file, they have a sourceless library in their
> environment:
> 
> > before <- loadedNamespaces()
> > load("mydata")
> > setdiff(loadedNamespaces(), before)
> [1] "sig"
> >
> 
> This is an example of malicious code:
> 
> > old_print <- print
> > print <- function(...)
> + {
> + unlink('the_most_important_file.txt')
> + old_print('Say goodbye to your file!')
> + }
> > save.image("mydata")
> >
> 
> When users load the data file, and try to execute a simple print
> statement, they can have their files removed:
> 
> > load("mydata")
> > list.files()
> [1] "mydata"  "the_most_important_file.txt"
> > print('Hello world!')
> [1] "Say goodbye to your file!"
> > list.files()
> [1] "mydata"
> 
> This just shows that there exist cases where .Rda files are *not* the
> prefered form of modification, such as placing code (or even whole
> libraries) into *.Rda files to be loaded.
> 
> Therefore, we shall consider these data files as preferred form of
> modification if the data was captured in this format from a scientific
> instrument, created manually and painstakingly by hand (this is not the
> common case), or otherwise not generated. If the data was generated, or
> converted by a script or series of scripts, the .Rda file is likely not
> the prefered form, and needs to be rebuilt at build-time from source (as
> we do with any binary in the archive).

I am very grateful that this discussion and decision did not lead to a 
'worst case' of outright rejection.  If you would like more information,
or to some (very Debian aware) folks at R Core (who are in your timezone) 
just shoot me an email off-list and I would be delighted to make an 
introduction.

Regards,  Dirk


-- 
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/loom.20130918t233300-...@post.gmane.org

Bug#723700: ITP: tinyows -- lightweight and fast WFS-T server

[Sebastiaan Couwenberg]

Package: wnpp
Owner: Bas Couwenberg 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-...@lists.debian.org

* Package name: tinyows
  Version : 1.1.0-3
  Upstream Author : Barbara Philippot, Olivier Courtin and the MapServer
team.
* URL : http://www.mapserver.org/tinyows/
* License : MIT/X11
  Programming Lang: C
  Description : lightweight and fast WFS-T server

TinyOWS is a lightweight and fast implementation of the OGC WFS-T
specification. Web Feature Service (WFS) allows querying and retrieval
of features. The transactional profile (WFS-T) allows inserting, updating
or deleting such features.

>From a technical point of view WFS-T is a Web Service API in front
of a spatial database. TinyOWS is deeply tied to PostgreSQL/PostGIS
because of this.

TinyOWS implements strictly OGC standards and pass successfully all
WFS OGC CITE tests (and even beta ones).

TinyOWS is part of MapServer Suite, but provided as a distinct module
(i.e you could use it in conjunction with MapServer and MapCache, or
as a standalone app). But both MapServer and TinyOWS could use the same
configuration file, if you want to (or native TinyOWS XML config file).


-- 
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/523a3fde.1060...@xs4all.nl

Bug#723704: ITP: mplapack -- multiple precision arithmetic BLAS and LAPACK

[Jerome Benoit]

Package: wnpp
Severity: wishlist
Owner: Jerome Benoit 

* Package name: mplapack
  Version : 0.8.0
  Upstream Author : Nakata Maho 
* URL : http://mplapack.sourceforge.net
* License : GPL
  Programming Lang: C/C++
  Description : multiple precision arithmetic BLAS and LAPACK

mplapack is a free library for arbitrary/higher precision linear algebra.
It consists of MBLAS and MLAPACK, multiple precision arithmetic versions
of BLAS and LAPACK, respectively.

mplapack supports various multiple precision arithmetic libraries like
GMP, MPFR, MPC, and QD, as well as IEEE 754 binary128.


-- 
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/20130919015348.12113.94783.report...@nen.dnsalias.org