Re: Wheezy release: CDs are not big enough any more...

[Neil Williams]

On Thu, 17 May 2012 04:36:40 +0200
Adam Borowski  wrote:

> On Wed, May 16, 2012 at 02:47:54PM +0200, Goswin von Brederlow wrote:
> > Can someone set the default to xz and recompile all of Debian or at
> > least base and create a repository from that for install tests?
> 
> There's no need to recompile anything.  You can recompress existing packages
> using the attached script.

.. and then spend a huge amount of time rebuilding your now broken
pool/ and archive because none of the checksums match ...

Do you have a patch for dak to go alongside your script to update all
checksums for all binaries across all architectures? What about
packages which are the same version in wheezy and in squeeze - now
you're looking at making a new point release with all packages across
all suites changing checksums.

Then once wheezy is out, we'll just have another round with the next
release because packages just keep getting fatter.

Stop investing time in stop gap measures - we need a durable solution
and that is likely to mean dropping GNOME and KDE as an option for CD#1.

-- 


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



pgpALWVSNRSqw.pgp
Description: PGP signature

Re: debuild/dpkg-buildpackage behaves not as expected

[Thibaut Paumard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 17/05/12 00:25, James McCoy a écrit :
> On Wed, May 16, 2012 at 04:23:05PM +0200, Olе Streicher wrote:
>> Unpatching the sources *before* the build process was cleaned up
>> makes no sense to me at all. Could you provide a use case for
>> that?
> 
> As was described in #649531:
> 
> vcs clone  cd repo ... tweak a
> little ... dpkg-buildpackage; # applies patches, builds, and
> unapplies patches

Precisely, the point is that should be:
applies patches, builds, *cleans* and unapplies patches

>> because it does *not* leave the sources in the same state.
> 
> Yes, it does.

Nope.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+0mOMACgkQ+37NkUuUiPHvwQCfZ5JgYpy9gMl05G+Crkqui+cx
BG8AnAj2RKjSNZ8DqFVXFXaWP2nJP+hY
=DgDT
-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/4fb498e3.7060...@users.sourceforge.net

Re: big .debian.tar.xz - EG Wordpress

[Thomas Goirand]

On 05/16/2012 08:45 PM, Jon Dowland wrote:
> Of course, many of these could be separate source/binary packages in their own
> right[1], as they have value outside of wordpress, and be 
> Build-Depends/Depends
> of wordpress. In fact a few already are: jquery (already packaged); swfupload
> (not yet); tinymce (already packaged)
Unfortunately, swfupload *cannot* be packaged in Debian because we have
no ways
of building it (unless the situation changed with adobe tools... in
which case,
I would really like to hear about it!). The only thing you could package
would
be a very old version of it.

Thomas


-- 
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/4fb498c0.4020...@debian.org

Re: switching from exim to postfix

[Thomas Goirand]

On 05/03/2012 07:23 AM, Henrique de Moraes Holschuh wrote:
> Well, FWIW postfix allows you to override all MTA notifications, not just
> bounce messages, but the full set.  We do that at work.
>   
Interesting. Can you post an example here?

Thomas


-- 
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/4fb4954d.8050...@debian.org

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Tollef Fog Heen]

]] Russ Allbery 

> There was never really a satisfactory resolution to that discussion.  We
> can upload very shallow clones, but they end up looking a lot like the
> existing quilt format with single-debian-patch, and it's not horribly
> clear what the advantages of 3.0 (git) are at that point.  Many of the
> really compelling use cases for 3.0 (git), neat stuff like possibly being
> able to just push a signed tag instead of uploading or having the package
> history when you get the source package, aren't very interesting with
> shallow clones.

Pushing a signed tag and having source packages and binaries built from
that doesn't rely on 3.0 (git), though.  «Just» a repository somewhere
with hooks that go «oh, a signed tag, let me build a source package and
upload that».  Might fire it off as a job to a separate process so
pushing to big repos doesn't take a winter and a day, but that's really
an implementation detail.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
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/87likricaf@xoog.err.no

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Russ Allbery]

Charles Plessy  writes:

> Also, it is very sad that, as a project, we can not decide whether we go
> for 3.0 (git) or not, or have a concrete list of resolvable objections
> from the people whose work is direclty impacted by the use of this
> format.

We know what a primary concrete objection is.  We discussed it at length
at DebConf two years ago, and then on debian-devel afterwards.  Uploading
a Git archive requires reviewing the entire contents of the archive, not
just the current code, for licensing issues, which is pretty painful from
the ftp-master perspective.

There was never really a satisfactory resolution to that discussion.  We
can upload very shallow clones, but they end up looking a lot like the
existing quilt format with single-debian-patch, and it's not horribly
clear what the advantages of 3.0 (git) are at that point.  Many of the
really compelling use cases for 3.0 (git), neat stuff like possibly being
able to just push a signed tag instead of uploading or having the package
history when you get the source package, aren't very interesting with
shallow clones.

-- 
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/87pqa3seyj@windlord.stanford.edu

Re: Wheezy release: CDs are not big enough any more...

[Adam Borowski]

On Wed, May 16, 2012 at 02:47:54PM +0200, Goswin von Brederlow wrote:
> Can someone set the default to xz and recompile all of Debian or at
> least base and create a repository from that for install tests?

There's no need to recompile anything.  You can recompress existing packages
using the attached script.

-- 
“This is gonna be as easy as cheating on an ethics exam!”
-Cerise Brightmoon
#!/bin/sh
set -e

if [ $# -eq 0 ]
  then
cat >&2 <&2 "No such file: $F" && exit 1)
DIR=".$F$"
rm -rf "$DIR"
mkdir "$DIR"
cd "$DIR"

ar x "../$F" debian-binary control.tar.gz
dpkg-deb --fsys-tarfile "../$F"|xz >data.tar.xz
rm "../$F"
ar rcD "../$F" debian-binary control.tar.gz data.tar.xz

cd ..
rm -rf "$DIR"
  done
 

signature.asc
Description: Digital signature

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Henrique de Moraes Holschuh]

On Thu, 17 May 2012, Charles Plessy wrote:
> It strikes me that while we have more than 6,500 source packages
> managed with Git, we are pushing for a source package format that does
> not work transparently with them.

It does, but not on all workflows.  A very large number of DDs are using
3.0 (quilt) with git just fine.

I don't exactly like quilt, in fact all my patch-based work is done
using stgit, but:

1) it is much better than dpatch and other homebrew stuff.  At least you
know exactly what to expect, and it is the same in the entire distro.

2) properly used, it enforces neatness and lowers a damn great deal the
barrier of entry (*and* reduces the risk of mistakes) for someone who
needs to do quick maintenance, security updates, NMUs, when taking over
the package, and even for automated extraction of changes to upstream
code.

> Also, it is very sad that, as a project, we can not decide whether we
> go for 3.0 (git) or not, or have a concrete list of resolvable
> objections from the people whose work is direclty impacted by the use
> of this format.

This is a _very_ dead horse.  I'd appreciate if you'd kindly refrain
from any further attempts at necromancy on this thread.

-- 
  "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: http://lists.debian.org/20120517003922.gb8...@khazad-dum.debian.net

Bug#673212: ITP: haskell-ncurses -- Haskell bindings to the GNU ncurses library

[John Millikin]

Package: wnpp
Severity: wishlist
Owner: John Millikin 

* Package name: haskell-ncurses
  Version : 0.2.1
  Upstream Author : John Millikin 
* URL : https://john-millikin.com/software/haskell-ncurses/
* License : GPLv3+
  Programming Lang: Haskell
  Description : Haskell bindings to the GNU ncurses library

This package provides a library for the Haskell programming language. See
http://www.haskell.org/ for more information on Haskell.

GNU ncurses is a library for creating advanced text-based user interfaces.



-- 
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/20120517000220.1732.40905.reportbug@vm-debian6-i386

Making mailing list discussions more viable (Re: Making -devel discussions more viable)

[Filipus Klutiero]

Hi Stefano, Russ and everyone,
thanks for your interest in this topic. I entirely agree that we should 
do better in this area. Since the discussion problem is not specific to 
debian-devel, I'm moving this to debian-project.


Stefano Zacchiroli wrote:

On Mon, Apr 30, 2012 at 10:11:23AM -0700, Russ Allbery wrote:
>  Given recent experiences, I'm also coming around to Ian's position that
>  aggressive and confrontational contributions from people who don't
>  otherwise seem to be contributing to Debian are part of the problem and
>  are not useful, and possibly should be banned.  I think that's been a
>  significant factor in the deterioration of the init system threads.

I agree that's a problem too and I share your feeling that it has been
particularly bad in recent discussions like the init system ones. To
look on the bright side, the problem seems concentrated in a few
specific topics rather than widespread to all discussions. But it is
still probably enough to keep some people from participating
constructively on -devel, which is a pretty serious problem.

>  I want our technical discussions to be welcoming to anyone who has
>  information to share and who can bring additional clarity and insight to
>  the discussion.  But once things start getting heated or people start
>  throwing around accusations or verge towards personal attacks, there's a
>  real psychological difference between people who are contributing to
>  Debian and people who aren't.


Agreed also on your reasoning about the psychological effects of non
constructive participation by non contributors.  Unfortunately, there
aren't many viable solutions to this kind of issues and all have
drawbacks.

1) our current solution: "don't feed the troll"

(even though the list participations we're talking about are not,
strictly speaking, trolling", that's basically our strategy)

It just doesn't work at this scale.

Sure, those who do respect the principle do reduce the noise (as
Bernhard pointed out), but you'll always have someone who will reply ---
maybe because they're new and accustomed to the list culture --- and it
is enough to have a few who do the feeding to make a discussion explode
and drive away people from it and, ultimately, decisions.

2) "don't feed the troll" + report abuses to listmasters and act
accordingly

I think we basically agree on the principle of this and IIRC we've even
discussed this about ~1 year ago without finding much opposition. But
either we're not doing this or it is not working.

Some of problems with this have been highlighted by Raphael. The
proposed fix, specifically for the "I don't know if I'm alone doing this
or not" part, sounds interesting.  But even with that fix, you still
have the social awkwardness problem: the feeling is that of "censoring"
someone and it's a hard to ignore feeling, because the act of doing that
is much more concrete than the perception of the long term benefits of
doing so. I've the impression that the bar for silencing someone will
always remain high, higher than what would be needed to avoid the
behavior we're discussing.

Another problem you'll have with this "solution" is that it consumes a
lot of community energy (the people reporting bad behavior, who will do
that only after reaching some high frustration level; and the
listmasters who'll need to put time and emotions in judging the
behavior, implementing and probably explaining the "sanction").

3) public, but contributors-only list

This has been implemented by other FOSS projects. A notable example is
Ubuntu who have a split between ubuntu-devel (project members only +
whitelisting) and ubuntu-devel-discuss (free for all). I've never asked,
but I have always suspected that they've done so in an attempt to
improve over the experience of debian-devel participants.

The obvious drawback of this "solution" is that non-contributors will
need someone to vouch for them to be whitelisted.

--

Each solution have advantages and disadvantages, but all in all I don't
think there aren't many other options. The question is blunt then: what
are we willing to give up of the current model in order to improve over
its defects?


There are many more approaches possible, and they can be combined.


 Improving what we write (educating)

The idea here is to help people avoid posting problematic content and/or 
to help people avoid posting content which tends to trigger problematic 
replies.



   General advice

This consists in writing guidelines which should be read by participants 
(for example "don't feed the troll").



   Specific advice

This is about offering customized advice to specific participants in need.


 Improving what we end up reading (filtering)

Here, we assume that problematic content will come and improve the 
discussion system to deal with it.


Approaches can be coercive or advisory. For example, excluding 
unapproved people from participating is coercive. Featuring messages 
from approved peop

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Charles Plessy]

Le Wed, May 16, 2012 at 12:38:49PM +0200, Adam Borowski a écrit :
> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote:
> > On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
> > > No, I hereby start saying good by to 3.0
> > 
> > I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also
> > found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last
> > few packages.
> 
> I can't see any reason to use 1.0 anymore, ever.
> 
> It is true that 3.0 (quilt) does have a great downside, quilt, but it also
> has a number of upsides.  And working around quilt is simple:
> 
> echo "single-debian-patch" >debian/source/options
> echo "/.pc" >>.gitignore
> echo "/debian/patches" >>.gitignore

It strikes me that while we have more than 6,500 source packages managed with
Git, we are pushing for a source package format that does not work
transparently with them.

Also, it is very sad that, as a project, we can not decide whether we go for
3.0 (git) or not, or have a concrete list of resolvable objections from the
people whose work is direclty impacted by the use of this format.

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: http://lists.debian.org/20120516230943.gd17...@falafel.plessy.net

Re: Bug#673182: ITP: pscan -- finds overrepresented transcription factor binding sites

[Steve McIntyre]

Steffen Moeller wrote:
>Package: wnpp
>Severity: wishlist
>Owner: Steffen Moeller 
>
>* Package name: pscan
>  Version : 1.2.1
>* URL : http://159.149.109.9/pscan/
>* License : unclear
 ^^^
Umm, what?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane


-- 
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/e1sunes-0001om...@mail.einval.com

Re: debuild/dpkg-buildpackage behaves not as expected

[James McCoy]

On Wed, May 16, 2012 at 04:23:05PM +0200, Olе Streicher wrote:
> Unpatching the sources *before* the build process was cleaned up makes
> no sense to me at all. Could you provide a use case for that?

As was described in #649531:

  vcs clone 
  cd repo
  ... tweak a little ...
  dpkg-buildpackage; # applies patches, builds, and unapplies patches
  vcs diff; # looks good?
  vcs commit

> > dpkg-source leaves the source in the same state it finds it before
> > build.

I think Goswin meant dpkg-buildpackage here.

> because it does *not* leave the sources in the same state.

Yes, it does.  If you started with patches applied, then they will still
be applied after calling "dpkg-buildpackage".  If you didn't have
patches applied, then "dpkg-buildpackage" will apply the patches, build
and unapply the patches.

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


signature.asc
Description: Digital signature

Re: big .debian.tar.xz - EG Wordpress

[Peter Samuelson]

[Russell Coker]
> Would it be possible to have somewhere on the Debian servers for
> storing such files so that they can be referenced in a README file or
> something rather than sent to everyone?  I'm sure that most people
> who build a Wordpress package won't use them.

As Paul Wise said, best if we _do_ build things from source rather than
relying on upstream binaries.

But beyond that, if there is to be a separate place to put "all the
WordPress source we want to provide but you probably don't really
need", for GPL reasons, it needs to be on all the mirrors alongside the
source package you _do_ install.  Not on some other website.

So I guess that brings us to a .dsc that can reference multiple
upstream tarballs (already possible, of course) but mark them such that
by default you only download or unpack _some_ of the tarballs.

The other option of course is to split wordpress into two source
packages, and move all the "users probably don't ever need to rebuild
this" stuff into the second source package and its corresponding binary
package, which regular wordpress can depend on.


-- 
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/20120516222407.gh2...@p12n.org

Re: Wheezy release: CDs are not big enough any more...

[Peter Samuelson]

[Steve McIntyre]
> You're not measuring the time taken to sync to the flash drive
> either, so all you're going to be seeing is the speed of writing to
> cache.

Huh, I figured the 'sync' call at the end of each test run covered
that.

> I've done lots of work with USB flash and MMC/SD cards over the last
> few years, and the best results are typically achieved using "dd
> bs=4M oflag=sync". That way, you'll normally get nicely-aligned date
> writes big enough to cover the internal flash page size and remove
> the horrendous effects of read-modify-write cycles.

Not noticeable in my test runs, so maybe I have an abnormal flash disk.
(The fact that it has a USB interface, rather than something closer to
the flash controller, probably makes a difference.)

Anyway, I've never been against people recommending things like
"dd bs=4M oflag=sync" when writing to disk media.  My pet peeve is when
people recommend "dd" but without any options other than if= and of=.
It is clear that many such people don't have a clue _why_ they use dd,
except an irrational, dare I say cargo-cult, aversion to cp with block
devices.


-- 
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/20120516220409.gg2...@p12n.org

Re: Bug#673182: ITP: pscan -- finds overrepresented transcription factor binding sites

[Charles Plessy]

Le Wed, May 16, 2012 at 07:48:46PM +0200, Steffen Moeller a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Steffen Moeller 
> 
> * Package name: pscan
>   Version : 1.2.1
> * URL : http://159.149.109.9/pscan/
> * License : unclear
>   Programming Lang: C++
>   Description : finds overrepresented transcription factor binding sites
> 
> This packages takes a motif database of transcription factor binding sites 
> (TFBS) and expects a list of genes that are found co-regulated. It then 
> points to
> those TFBS that seem statistically most unlikely to be observed by chance.
> 

Hello everybody,

we have a problem... EMBOSS also distributes a program called pscan, as well as
the "pscan" package itself (Format string security checker for C files).

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/20120516215729.gb17...@falafel.plessy.net

Re: Wheezy release: CDs are not big enough any more...

[Joey Hess]

Goswin von Brederlow wrote:
> Joey Hess  writes:
> 
> > Adam Borowski wrote:
> >> Could you please mention which ones do not?  And if so, how are they
> >> relevant/are they fixable?
> >
> > As one of the maintainers of debootstrap, I am perhaps more aware than
> > some how broadly it's used. Ok..
> >
> > They use it on Android (41,600 hits including 
> > http://evilzone.org/android/debian-on-android/)
> > They use it on Nokia (96,600 hits)
> > They use it on Nook (14,000 hits)
> > They use it on headless old Red Hat systems in a datacenter somewhere
> > They use it on Debian oldstable systems, where xz-utils is not even 
> > packaged.
> > They use it on absolutely modern peices of unusual kit that ship with some
> > crufty busybox binary (no source naturally) from far up the supplier
> > chain, that was built well before xz support entered busybox in 2010.
> 
> How are they relevant? Where do they download and unpack udebs? Where is
> busybox used to unpack debs?

In the above message "it" is debootstrap.

-- 
see shy jo


signature.asc
Description: Digital signature

Use cases for CD installs (Re: Wheezy release: CDs are not big enough any more...)

[Filipus Klutiero]

Steve Langasek wrote:

On Sun, May 13, 2012 at 10:26:13PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
>  On Dom 13 May 2012 21:40:10 Marco d'Itri escribió:
>  [snip]
>  >  Does anybody actually know that people routinely try to install desktop
>  >  systems with only a CD and no networking, and why?
>  >  What is the use case for this? Cheap DVD readers have been around for
>  >  over 10 years now.

>  Actually, I was going to ask exactly that. To the best of my knowledge,
>  CDROM players have been out of stock for a while (more than two years?)
>  Normally people will buy a DVDROM player.  Well, at least here in
>  Argentina :-/

>  Could it be reasonable to drop graphical desktops environments for one-CD
>  installs? If you want a GDE, get the DVD. Or two or more CDs.

As a data point, the 12.10 Ubuntu release, which is in about the same time
frame as wheezy, will not include a CD-sized desktop image.  After holding
this line for a long time, it's been decided that we've passed the point of
diminishing returns and that *slowly* allowing an increase in image size
(e.g., 800MB for this cycle instead of 736MB) allows us to define the
default install in terms of what's useful instead of just in terms of what
we can fit on a CD.

So to use the image you need either a DVD or a USB stick, and if you're
using a write-once DVD you're perhaps wasting the unused space; but the
download time and install footprint are still kept low and in the range of
what a CD would give.

Maybe worth considering something similar for Debian.


Interesting. I was going to suggest doing the same.

I do not know people regularly trying to install on desktop systems with 
only a CD drive and no (software) networking. I do use CD isos, however. 
I regularly download the KDE CD 1. The reason why I'm not using the 
netinst instead is that I save install time, and sometimes some download 
when I test the CD on several PCs. But, if I write the iso to a CD, 
that's only because I would need to stand up to reach the rewritable 
DVDs (due to an historical artifact of my desk's setup) and because I'm 
going to install to a machine where USB sticks are more painful to boot 
(but the last machine I had for which this was the case died recently).


So for me, the interest of CD 1 is that it approximates fairly well the 
package set I'm going to end up installing - more than either netinsts 
or DVD  1. If I had another media scoring equally well on that front, I 
would only consider fitting on a CD as an extremely marginally useful 
feature.



--
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/4fb3efe4.2060...@gmail.com

Re: future of python-pipeline package

[Dmitry Nezhevenko]

On Wed, May 16, 2012 at 06:04:27PM +0200, Bastian Blank wrote:
> On Wed, May 16, 2012 at 11:57:07AM +0300, Dmitry Nezhevenko wrote:
> > I'm trying to package a ReviewBoard package that depends on
> > django-pipeline module. Unfortunately there is already another package
> > named python-pipeline in debian that uses same python module name
> > (pipeline). This another package is orphaned for a year:
> 
> And why does django-pipeline have problems with python-pipeline?
> 
> >From your description they don't overlap. python-pipeline installs a
> python module calles pipeline (from the name); django-pipeline does not.

both of them installs "pipeline" module (in terms of python "import
pipeline")

 
-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Bug#673182: ITP: pscan -- finds overrepresented transcription factor binding sites

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: pscan
  Version : 1.2.1
* URL : http://159.149.109.9/pscan/
* License : unclear
  Programming Lang: C++
  Description : finds overrepresented transcription factor binding sites

This packages takes a motif database of transcription factor binding sites 
(TFBS) and expects a list of genes that are found co-regulated. It then points 
to
those TFBS that seem statistically most unlikely to be observed by chance.


The package already lives at
Vcs-Browser: http://svn.debian.org/viewvc/debian-med/trunk/packages/pscan

Cheers,

Steffen



-- 
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/20120516174846.21084.14291.report...@master.dermacloud.uni-luebeck.de

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Russ Allbery]

Adam Borowski  writes:

> It is true that 3.0 (quilt) does have a great downside, quilt, but it also
> has a number of upsides.  And working around quilt is simple:

> echo "single-debian-patch" >debian/source/options
> echo "/.pc" >>.gitignore
> echo "/debian/patches" >>.gitignore

I recommend using local-options instead of options.  That way all of your
changes go into a single patch, but any NMUs automatically are put into
separate patches by version number.  It makes analyzing packages that have
been NMU'd much nicer.

-- 
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/87wr4cvy2a@windlord.stanford.edu

Re: Bug#671503: general: APT repository format is not documented

[Filipus Klutiero]

Could you clarify how this differs from #481129?


--
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/4fb3d965.5030...@gmail.com

Re: Wheezy release: CDs are not big enough any more...

[Hans-Christoph Steiner]

On May 16, 2012, at 10:49 AM, Jonas Smedegaard wrote:

> [CC'ing Hans-Christoph in case he isn't following this list]
> 
> On 12-05-16 at 02:47pm, Goswin von Brederlow wrote:
>> Joey Hess  writes:
>> 
>>> Adam Borowski wrote:
 Could you please mention which ones do not?  And if so, how are 
 they relevant/are they fixable?
>>> 
>>> As one of the maintainers of debootstrap, I am perhaps more aware 
>>> than some how broadly it's used. Ok..
>>> 
>>> They use it on Android (41,600 hits including 
>>> http://evilzone.org/android/debian-on-android/)
>>> They use it on Nokia (96,600 hits)
>>> They use it on Nook (14,000 hits)
>>> They use it on headless old Red Hat systems in a datacenter 
>>> somewhere
>>> They use it on Debian oldstable systems, where xz-utils is not even 
>>> packaged.
>>> They use it on absolutely modern peices of unusual kit that ship 
>>> with some crufty busybox binary (no source naturally) from far up 
>>> the supplier chain, that was built well before xz support entered 
>>> busybox in 2010.
>> 
>> How are they relevant? Where do they download and unpack udebs? Where 
>> is busybox used to unpack debs?
> 
> Perhaps this example is relevant: 
> http://guardianproject.info/code/lildebi/
> 
> @Hans-Christoph: Does that project use a debootstrap without xz support, 
> and would its tricks break if Debian was to switch to compress its 
> binary packages with xz instead of gzip?

It was originally using some ancient busybox binary without xz support. Since 
we are now building busybox from source, we should be able to easily include 
busybox's xz.  So if busybox's xz works for .debs, then it should work ok.

For the record, LilDebi does not use busybox's 'dpkg-deb' because it doesn't 
work with debootstrap.  I haven't really looked into why because using 'ar' 
works.

.hc

--
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/350b5dd5-4310-4fc4-9ee2-bebed712c...@eds.org

Re: future of python-pipeline package

[Bastian Blank]

On Wed, May 16, 2012 at 11:57:07AM +0300, Dmitry Nezhevenko wrote:
> I'm trying to package a ReviewBoard package that depends on
> django-pipeline module. Unfortunately there is already another package
> named python-pipeline in debian that uses same python module name
> (pipeline). This another package is orphaned for a year:

And why does django-pipeline have problems with python-pipeline?

>From your description they don't overlap. python-pipeline installs a
python module calles pipeline (from the name); django-pipeline does not.

Bastian

-- 
If some day we are defeated, well, war has its fortunes, good and bad.
-- Commander Kor, "Errand of Mercy", stardate 3201.7


-- 
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/20120516160427.ga23...@wavehammer.waldi.eu.org

Re: Wheezy release: CDs are not big enough any more...

[Thomas Schmitt]

Hi,

Bjørn Mork  wrote:
> On a default Debian system you need to be a member of
> the "floppy" group.

Ferenc Wagner  wrote:
> What about recommending /dev/disk/by-id/usb-X instead?

I understand that the instructions about creating a Debian installation
medium shall be usable on as many systems as possible, not only on
already installed Debian systems.

USB stick on a pre-udev SuSE:
  brw-r- 1 root disk   8, 32 2012-05-15 20:18 /dev/sdb

USB stick on FreeBSD 8:
  crw-rw-r--  1 root  floppy  0, 124 May 15 20:13 /dev/da0

On Solaris it seems to be:
  lrwxrwxrwx 1 root root 60 Jun  8  2010 /dev/dsk/c5t0d0p0 -> 
../../devices/pci@0,0/pci1458,5004@13,2/storage@4/disk@0,0:q
  br 1 root root 83, 272 Jun  8  2010 
/devices/pci@0,0/pci1458,5004@13,2/storage@4/disk@0,0:q
I fail to find a device file with any w-permission in the c5t0d0 family of
/dev/dsk or /dev/rdsk. (When i was younger, Solaris looked more like Unix.)
There is a script
   http://src.opensolaris.org/source/raw/livemedia/livemedia/usbcopy
which finds the USB stick and writes some data onto the stick while issueing
several error messages.
But the stick afterwards does not bear the data which i gave as input
"image" to the script.


Have a nice day :)

Thomas


-- 
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/1273991356404283...@scdbackup.webframe.org

Re: Wheezy release: CDs are not big enough any more...

[Steve McIntyre]

On Tue, May 15, 2012 at 09:00:29PM -0500, Peter Samuelson wrote:
>[Steve McIntyre]
>> The major win with dd onto a raw device is that you can specify the
>> block size. For most USB sticks, using a block size of 4MB or so is
>> going to be *much* faster than using the default for dd (512 bytes)
>> or cp (10 KB IIRC).
>
>That seemed a little fishy to me, since none of the above commands do
>any fsync by default, so I just benched it locally.
>
>Writing a 50 MB businesscard image to a USB flash drive on my system
>(numbers are MB/s):
>
>dd bs=512   1.771.781.77
>dd bs=1024  1.791.761.77
>dd bs=2048  1.771.781.78
>dd bs=4096  2.542.532.51
>dd bs=8192  2.482.502.55
>dd bs=4194304   2.502.502.54
>cp  2.492.472.48
>
>So it appears that if you aren't going to specify a bs= parameter here,
>there's no point in using dd, unless you just happen to think its
>command line syntax is particularly charming.  And even if you do
>specify bs=, you'll only barely beat cp.

You're not measuring the time taken to sync to the flash drive either,
so all you're going to be seeing is the speed of writing to
cache. I've done lots of work with USB flash and MMC/SD cards over the
last few years, and the best results are typically achieved using "dd
bs=4M oflag=sync". That way, you'll normally get nicely-aligned date
writes big enough to cover the internal flash page size and remove the
horrendous effects of read-modify-write cycles.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...


-- 
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/20120516155205.gc3...@einval.com

Re: Wheezy release: CDs are not big enough any more...

[Timo Juhani Lindfors]

Jonathan Nieder  writes:
> speaking lets each user access media that they have inserted.  Last
> time I checked[1] (a while ago), the same rules did not apply to USB
> sticks.

Yes, this is the point I was trying to make in the first place :)


-- 
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/84boloxh7s@sauna.l.org

Re: Wheezy release: CDs are not big enough any more...

[Jonathan Nieder]

Bjørn Mork wrote:
> Timo Juhani Lindfors  writes:

>> You also need to have root access to some machine to create the USB
>> media.
>
> No, you don't.  On a default Debian system you need to be a member of
> the "floppy" group. From  /lib/udev/rules.d/91-permissions.rules :
>
>  # default permissions for block devices
>  SUBSYSTEM=="block", GROUP="disk"
>  SUBSYSTEM=="block", ATTRS{removable}=="1",  GROUP="floppy"

Yep.

>> This means you can't create the installation media at most
>> university or library machines unlike with CDs.
>
> You mean that they allow you to burn a CD but not write to a USB stick?
> Sounds like they have a support problem which I don't think Debian can
> solve for them.

On large installations (think "computing cluster"), adding untrusted
users to the floppy group is not a great idea, since then they would
have remote access to removable media other users insert.  For CDs
and DVDs, consolekit addresses the problem out of the box and roughly
speaking lets each user access media that they have inserted.  Last
time I checked[1] (a while ago), the same rules did not apply to USB
sticks.

Hope that helps,
Jonathan

[1] http://bugs.debian.org/585463


--
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/20120516153715.GA17460@burratino

Re: debuild/dpkg-buildpackage behaves not as expected

[Osamu Aoki]

Hi,

On Wed, May 16, 2012 at 09:05:21AM +0200, Olе Streicher wrote:
> Hi, 
> 
> I just discovered that debuild does not behave as I would expect from
> the maintainer's guide [1]:

You should say :-)

I just discovered that debuild does not behave as it is described in the
maintainer's guide.  So the maintainer's guide can be called buggy but ...
 
> | Cleaning the source and rebuilding the package from your user account
> | is as simple as: 
> | $ debuild
> [...]
> | You can clean the source tree as simply as:
> | $ debuild clean
> 
> This gives an error if the "dh_clean" does not work on the unpatched
> source, since "debuild" reverts all patches, but "debuild clean" does
> not apply then. I filed a bug report for this [2], including a simple
> example package, but the maintainer doesn't see a problem here.

Interesting.

> For me, the behaviour doesn't look good since the state after "debuild"
> does not make sense to me: all files created during the build process
> (from the patches sources) are still there (including temporary ones),
> but the sources themself do not are not patched anymore. So, build
> results and sources do not fit together after this step. Even more, if
> during the build process one file that has a Debian patch is changed,
> unapplying the patch may fail even if the build change would be reverted
> during the clean process.
> 
> What is the rationale behind the automatic reversal of the applied
> patches before a cleanup?

I do not know.  I tends to keep my VCS as patch removed.  So I liked
debuild to be this way.  I happened not to hit case when debuild clean
is problematic.

(I use debian/source/local-options  containing unapply-patches.)

It needs to be resolved at dpkg-buildpackage
http://bugs.debian.org/649531 with everything considered.  This is
certainly not debuild problem.

Osamu


-- 
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/20120516150354.GA9618@localhost

Re: Wheezy release: CDs are not big enough any more...

[Jonas Smedegaard]

[CC'ing Hans-Christoph in case he isn't following this list]

On 12-05-16 at 02:47pm, Goswin von Brederlow wrote:
> Joey Hess  writes:
> 
> > Adam Borowski wrote:
> >> Could you please mention which ones do not?  And if so, how are 
> >> they relevant/are they fixable?
> >
> > As one of the maintainers of debootstrap, I am perhaps more aware 
> > than some how broadly it's used. Ok..
> >
> > They use it on Android (41,600 hits including 
> > http://evilzone.org/android/debian-on-android/)
> > They use it on Nokia (96,600 hits)
> > They use it on Nook (14,000 hits)
> > They use it on headless old Red Hat systems in a datacenter 
> > somewhere
> > They use it on Debian oldstable systems, where xz-utils is not even 
> > packaged.
> > They use it on absolutely modern peices of unusual kit that ship 
> > with some crufty busybox binary (no source naturally) from far up 
> > the supplier chain, that was built well before xz support entered 
> > busybox in 2010.
> 
> How are they relevant? Where do they download and unpack udebs? Where 
> is busybox used to unpack debs?

Perhaps this example is relevant: 
http://guardianproject.info/code/lildebi/

@Hans-Christoph: Does that project use a debootstrap without xz support, 
and would its tricks break if Debian was to switch to compress its 
binary packages with xz instead of gzip?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Wheezy release: CDs are not big enough any more...

[Mehdi Dogguy]

On 16/05/12 13:41, Wookey wrote:

is there any reason not to just upload this to Debian?


There are ITPs filed for it:
- http://bugs.debian.org/582884
- http://bugs.debian.org/576359

Regards,

--
Mehdi


--
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/4fb3b89b.2030...@debian.org

Re: debuild/dpkg-buildpackage behaves not as expected

[Olе Streicher]

Goswin von Brederlow  writes:
> What automatic reversal? There is no automatic reversal. The default
> state of source is with patches applied.

Hmm. I have overlooked this when reading bug report #649531.

The order how the steps are applied, is clearly:

1. patch the sources
2. build the package

If you want to reverse this, one clearly should to it in reverse order:

1. cleanup from the build process
2. unpatch the sources

Unpatching the sources *before* the build process was cleaned up makes
no sense to me at all. Could you provide a use case for that?

> Wether debuild  should apply patches before running the target
> is arguable. But lets say it does apply patches before the target and
> then restores the source to the state it was before after the
> target. What happens if you now call
>
> debuild patch
>
> to apply the patches in a 3.0 (quilt) package that has patch/unpatch
> targets?
>
> Patches would be applied before that patch target is called, then patch
> is called and does nothing (or fails) and then patches are unapplied
> again to restore the original state.
>
> Not what you want.

A "patch" target would contradict your statement 

> dpkg-source leaves the source in the same state it finds it before
> build.

because it does *not* leave the sources in the same state.

Cheers

Ole


-- 
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/ytz4nrg8at2@news.ole.ath.cx

Re: Wheezy release: CDs are not big enough any more...

[Henrique de Moraes Holschuh]

On Wed, 16 May 2012, Wookey wrote:
> this to Debian? I see a couple of places in the UI where it says
> 'Ubuntu' and it would be good if it got a bit cleverer and put in the

If Ubuntu sponsored the creation of usb-creator, we can package it that
way just fine, as long as the trademark license for "Ubuntu" allows us
to do that.

-- 
  "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: http://lists.debian.org/20120516141221.gb30...@khazad-dum.debian.net

Re: debuild/dpkg-buildpackage behaves not as expected

[Goswin von Brederlow]

debian-de...@liska.ath.cx (Olе Streicher) writes:

> Hi, 
>
> I just discovered that debuild does not behave as I would expect from
> the maintainer's guide [1]:
>
> | Cleaning the source and rebuilding the package from your user account
> | is as simple as: 
> | $ debuild
> [...]
> | You can clean the source tree as simply as:
> | $ debuild clean
>
> This gives an error if the "dh_clean" does not work on the unpatched
> source, since "debuild" reverts all patches, but "debuild clean" does
> not apply then. I filed a bug report for this [2], including a simple
> example package, but the maintainer doesn't see a problem here.
>
> For me, the behaviour doesn't look good since the state after "debuild"
> does not make sense to me: all files created during the build process
> (from the patches sources) are still there (including temporary ones),
> but the sources themself do not are not patched anymore. So, build
> results and sources do not fit together after this step. Even more, if
> during the build process one file that has a Debian patch is changed,
> unapplying the patch may fail even if the build change would be reverted
> during the clean process.
>
> What is the rationale behind the automatic reversal of the applied
> patches before a cleanup?

What automatic reversal? There is no automatic reversal. The default
state of source is with patches applied.

% ddsa_0.1-1.dsc
dpkg-source: warning: extracting unsigned source package
(ddsa_0.1-1.dsc)
dpkg-source: info: extracting ddsa in ddsa-0.1
dpkg-source: info: unpacking ddsa_0.1.orig.tar.gz
dpkg-source: info: unpacking ddsa_0.1-1.debian.tar.gz
dpkg-source: info: applying automake
% cd ddsa-0.1/
% debuild
...
dpkg-genchanges: including full source code in upload
 dpkg-source --after-build ddsa-0.1
dpkg-buildpackage: full upload (original source is included)
% debuild clean
dh clean --with autoreconf
   dh_testdir
   dh_auto_clean
make[1]: Entering directory `/data/home/brederlo/src/ddsa/ddsa-0.1'
test -z "" || rm -f 
test . = "." || test -z "" || rm -f 
rm -f config.status config.cache config.log configure.lineno
config.status.lineno
rm -f Makefile
make[1]: Leaving directory `/data/home/brederlo/src/ddsa/ddsa-0.1'
   dh_autoreconf_clean
   dh_clean


dpkg-source leaves the source in the same state it finds it before
build. So if you start out with patches applied then they stay
applied. If you manually removed the patches then it is your job to
manually apply them again.

Wether debuild  should apply patches before running the target
is arguable. But lets say it does apply patches before the target and
then restores the source to the state it was before after the
target. What happens if you now call

debuild patch

to apply the patches in a 3.0 (quilt) package that has patch/unpatch
targets?

Patches would be applied before that patch target is called, then patch
is called and does nothing (or fails) and then patches are unapplied
again to restore the original state.

Not what you want.


As a solution to your problem I would add patch/unpatch targets to your
source file like this:

QUILT=QUILT_PATCHES=debian/patches quilt --quiltrc /dev/null

PATCH := $(QUILT) push -a || [ "$$($(QUILT) applied)" = "$$(grep -v '^\#' 
debian/patches/series)" ]
UNPATCH := $(QUILT) pop -a || [ "$$($(QUILT) applied 2>&1)" = "No patches 
applied" ]

patch:
$(PATCH)
 
unpatch:
$(UNPATCH)

configure-stamp:
$(PATCH)
...

build: build-stamp
build-stamp: configure-stamp
$(PATCH)
...

clean:
$(PATCH)
...
# if you like sources unpatched use unapply-patches in
# debian/source/local-options or:
# $(UNPATCH)

The reason for calling PATCH/UNPATCH directly instead of as dependencies
is so that (un)patch is called again even if it was called before
(because (un)patch might have been called since then) and so that
targets with stamp files don't run every time.

MfG
Goswin


-- 
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/87r4ukp7ts.fsf@frosties.localnet

Re: on the use of chmod/chown in maintainer scripts

[Roger Leigh]

On Wed, May 16, 2012 at 02:38:14PM +0200, Goswin von Brederlow wrote:
> Roger Leigh  writes:
> 
> > With the above approach, the only hard question is how to set the
> > ownership during the package build.  fakeroot handles this just fine,
> > but it does require the user/group to be present on the build
> > system, which will not always be the case.  Is there an alternative
> > means to set/override the ownership during packing of a tarfile?
> 
> Shouldn't be to hard to make fakeroot also create fake users and groups
> specified in debian/passwd and debian/group (or similar).

fakeroot is the wrong level to do this.  Think about how you are
dependent upon the NSS databases and you need a valid db for
the chown/chmod commands to work.  Coupled with the fact that
fakeroot is not required for building, I don't think this is a
good plan.  A wrapper around or replacement for chown/chmod is a
possibility; this could store the changes in a file, rather than
change the on-disc perms, ready for dpkg-deb to use.

> That just leaves the question of wether dpkg uses uid/gid or symbolic
> names when unpacking debs.

I think this one is clear: it must be symbolic since the uids/gids
aren't static.  Unless you want to provide a package-specific
mapping in the control data, and I can't see that gains much, since
it makes unpacking unnecessarily complex.  If it's symbolic, you
simply just extract it.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20120516130809.gb22...@codelibre.net

Re: problems with quilt and 3.0 (quilt) format again

[Goswin von Brederlow]

"Bernhard R. Link"  writes:

> * Norbert Preining  [120515 01:10]:
>> For these kind of things the expected behaviour is that quilt and
>> dpkg-source behave the same way, and if not, dpkg-source should
>> warn or whatever.
>
> I think the patched debian source format should not depend on what
> quilt does but be sensible within itself. Requiring patched being
> able to applied without any magic (which might hide mistakes and
> result in changes different from the intended ones) is a reasonable
> thing to do.
>
> Bernhard R. Link

The error message could be better though. dpkg-source could try if magic
(fuzz) helps and then complain about the patch being fuzzy etc...

MfG
Goswin


-- 
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/87vcjwp9h7.fsf@frosties.localnet

Bug#673143: ITP: eclib -- Programs for modular symbols and elliptic curves over Q

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 

* Package name: eclib
  Version : any
  Upstream Author : John Cremona 
* URL : http://code.google.com/p/eclib/
* License : GPL
  Programming Lang: C, C++
  Description : Programs for modular symbols and elliptic curves over Q



-- 
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/20120516125002.7519.92127.reportbug@newton.localdomain

Bug#673139: ITP: jgromacs -- library for trajectory analysis in molecular dynamics

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: jgromacs
  Version : 1.0
* URL : http://nanomed.bioch.ox.ac.uk/jgromacs/
* License : GPL3
  Programming Lang: Java
  Description : library for trajectory analysis in molecular dynamics

 JGromacs is a Java library designed to facilitate the development
 of cross-platform analysis applications for Molecular Dynamics (MD)
 simulations. The package contains parsers for file formats applied by
 GROMACS (GROningen MAchine for Chemical Simulations), one of the most
 widely used MD simulation packages.
 .
 JGromacs provides a multilevel object-oriented representation of
 simulation data to integrate and interconvert sequence, structure
 and dynamics information. In addititon, a basic analysis toolkit is
 included in the package. The programmer is also provided with simple
 tools (e.g. XML-based configuration) to create applications with a user
 interface resembling the command-line UI of Gromacs applications.

Packaging instructions live on
http://anonscm.debian.org/viewvc/debichem/unstable/jgromacs

Steffen



-- 
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/20120516124404.1511.38920.report...@gpu1.dermacloud.uni-luebeck.de

Re: Wheezy release: CDs are not big enough any more...

[Goswin von Brederlow]

Joey Hess  writes:

> Adam Borowski wrote:
>> Could you please mention which ones do not?  And if so, how are they
>> relevant/are they fixable?
>
> As one of the maintainers of debootstrap, I am perhaps more aware than
> some how broadly it's used. Ok..
>
> They use it on Android (41,600 hits including 
> http://evilzone.org/android/debian-on-android/)
> They use it on Nokia (96,600 hits)
> They use it on Nook (14,000 hits)
> They use it on headless old Red Hat systems in a datacenter somewhere
> They use it on Debian oldstable systems, where xz-utils is not even packaged.
> They use it on absolutely modern peices of unusual kit that ship with some
> crufty busybox binary (no source naturally) from far up the supplier
> chain, that was built well before xz support entered busybox in 2010.

How are they relevant? Where do they download and unpack udebs? Where is
busybox used to unpack debs?

>> Special-casing base packages would be a lot of complexity, let's avoid that
>> if possible -- but still preferred to letting gzip stay.
>
> Base packages can be identified at build time by their priority.
> if ($priority ne 'important' && $priority ne 'required') {
> }
>
> Although I do think that rebuilding the entire archive at this point in
> the release process is probably going to result in a lot of ..
> complexity. For one, d-i relies on being able to unpack firmware .debs
> The code that does this doesn't support data.tar.xz. There are probably
> plenty more problems where that came from.

Can someone set the default to xz and recompile all of Debian or at
least base and create a repository from that for install tests?

MfG
Goswin


-- 
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/87zk98pa11.fsf@frosties.localnet

Re: big .debian.tar.xz - EG Wordpress

[Jon Dowland]

On Wed, May 16, 2012 at 05:53:11PM +0800, Paul Wise wrote:
> Seems like a bug, the best way to determine that sources are still
> buildable is to always build them.

The stuff is things such as "minified" js. The wordpress source contains the
minified copies, and you can get the originals in separate tarballs from the
wordpress site.

It strikes me that this is *exactly* what the multiple-source-tarballs feature
of 3.0. is for.  Although, the fact these sources aren't used at all is
troubling.  If Debian used them (implemented the minifying as part of the build
process) we might catch a problem upstream miss (not necessarily a bad thing).

Of course, many of these could be separate source/binary packages in their own
right[1], as they have value outside of wordpress, and be Build-Depends/Depends
of wordpress. In fact a few already are: jquery (already packaged); swfupload
(not yet); tinymce (already packaged)…

[1] 
http://anonscm.debian.org/gitweb/?p=collab-maint/wordpress.git;a=blob;f=debian/missing-sources/README;h=3c3b33eadc25e8c43ca6147a185e127a5cc8a856;hb=HEAD


-- 
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/20120516124552.GB6784@debian

Re: Bug#673071: ITP: vodstok -- Voluntary Distributed Storage Kit

[Jonathan Wiltshire]

On 2012-05-16 13:19, Pierre Jaury wrote:

On Wed, 2012-05-16 at 11:02 +0200, Cyril Brulebois wrote:

Jonathan Wiltshire  (16/05/2012):
> Viral? I hope this is just a translation artefact; can you explain
> exactly what you mean by it?

Quite a shock for a project advertised as licensed under the BSD!

(INSTALL.txt says GPLv2 though.)


As explained already, this is a translation artifact. Should be
understood as ``intended to be self-distributable'' as long as the 
web

ui embeds the source package for download.



Thank you for the clarification.



--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51


--
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/7f5fa357591ff090ebee2d93b4332...@hogwarts.powdarrmonkey.net

Re: on the use of chmod/chown in maintainer scripts

[Goswin von Brederlow]

Roger Leigh  writes:

> With the above approach, the only hard question is how to set the
> ownership during the package build.  fakeroot handles this just fine,
> but it does require the user/group to be present on the build
> system, which will not always be the case.  Is there an alternative
> means to set/override the ownership during packing of a tarfile?

Shouldn't be to hard to make fakeroot also create fake users and groups
specified in debian/passwd and debian/group (or similar).

That just leaves the question of wether dpkg uses uid/gid or symbolic
names when unpacking debs.

MfG
Goswin


-- 
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/874nrgqp1l.fsf@frosties.localnet

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Jon Dowland]

On Wed, May 16, 2012 at 12:38:49PM +0200, Adam Borowski wrote:
> It is true that 3.0 (quilt) does have a great downside, quilt, but it also
> has a number of upsides.  And working around quilt is simple:
> 
> echo "single-debian-patch" >debian/source/options
> echo "/.pc" >>.gitignore
> echo "/debian/patches" >>.gitignore

Thanks for the recipes for avoiding the quilt stuff; whilst still more work
than "just use 1.0", but perhaps the advantages are indeed worth it. (Esp.
in light of the talk re: xz compression.)

> Except for nuking upstream debian/ dir which can mean a bit of lost work if
> the upstream is sane (and can save some if they're not), the 3.0 format is
> strictly better than 1.0.

I had to go away and read up on the other things 3.0 brings to the table.
Indeed they are nice-to-haves, which I am not benefiting from precisely because
they are presently only available in Debian via 3.0 (quilt).  This is a bit of
a marketing fail for 3.0., in hindsight.



-- 
Jon Dowland


-- 
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/20120516123707.GA6784@debian

Re: on the use of chmod/chown in maintainer scripts

[Goswin von Brederlow]

Russ Allbery  writes:

> Charles Plessy  writes:
>
>> in some of my packages, I give the ownership on some directories in /var
>> to www-data without checking that the www-data group exists, but I guess
>> it is acceptable because it is globally allocated by base-passwd.
>
> Right.
>
>> Dpkg will not update permissions or ownership, but when creating the
>> directory it will apply the ones in the 'data' tar archive.  So if there
>> was no package released with wrong settings, I assume this is safe.  Or
>> am I simply relying on something undocumented and unwaranteed ?
>
> No, this is fine.  But it only works for globally-allocated IDs in
> base-passwd.  If you instead need to dynamically generate a system user on
> the fly and then set ownership of files to that user, which is a
> reasonably common case, this is more complex.

Actualy not quite. This fails during bootstrap if base-passwd is not yet
configured.

While base-passwd is essential the /etc/passwd is only created during
postinst and thus not covered by base-passwd being essential.  So if you
are essential (or pseudo essential, something essential depends on you)
you have to depend on base-passwd to ensure your postinst is run after
base-passwd is configured.

MfG
Goswin


-- 
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/878vgsqpc6.fsf@frosties.localnet

Re: Bug#673071: ITP: vodstok -- Voluntary Distributed Storage Kit

[Pierre Jaury]

Hi,

On Wed, 2012-05-16 at 11:02 +0200, Cyril Brulebois wrote:
> Jonathan Wiltshire  (16/05/2012):
> > Viral? I hope this is just a translation artefact; can you explain
> > exactly what you mean by it?
> 
> Quite a shock for a project advertised as licensed under the BSD!
> 
> (INSTALL.txt says GPLv2 though.)
> 
> Mraw,
> KiBi.

As explained already, this is a translation artifact. Should be
understood as ``intended to be self-distributable'' as long as the web
ui embeds the source package for download.

About the license, my bad: it is licensed under *GPLv2*, I must have
been distracted when first writing the ITP ticket.

regards,
Pierre


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

Re: Wheezy release: CDs are not big enough any more...

[Wookey]

+++ Timo Juhani Lindfors [2012-05-15 21:01 +0300]:

Yes, turns out I failed to read the instructions right, presumably due
to thinking I knew how this worked (i.e. you can't just put an iso
stright onto a USB stick, and you need 'hd-media' for USB sticks).

I'm glad to see that this has got significantly simpler.

> ubuntu uses the usb-creator package to provide a dbus api that allows
> normal users to create usb installation media. (It carefully checks that
> you can not write to the internal hard disk).

I think this is what most inexpert users would like to see - a
reasonably idiot-proof GUI tool for downloading an installer image and
putting it on the USB stick for them.

usb-creator is in ubuntu but not Debian for no good reason. It has
already had Debian support added. 

One of the uploaders, and the person who added the Debian support is a
DD: Dmitrijs Ledkovs. Dmitri - is there any reason not to just upload
this to Debian? I see a couple of places in the UI where it says
'Ubuntu' and it would be good if it got a bit cleverer and put in the
appropriate string with dpkg-vendor, as it already does for the logo
files. I also fixed up the build so it skips the not-present
dh-translations on Debian, and otherwise modified the deps for Debian.
I'll do some testing tonight when I have USB sticks to hand.

There are probably quite a few useful utilities like this in Ubuntu
universe that should get uploaded. 

Wookey


-- 
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/20120516114114.gj11...@stoneboat.aleph1.co.uk

Re: Wheezy release: CDs are not big enough any more...

[Timo Juhani Lindfors]

Bjørn Mork  writes:
> I fail to see how burning to a local user's CD is any better, but yes,
> if that is a consideration then they need some system to tie the rights
> to console access.  I believe ConsoleKit and the replacement
> systemd-loginctl attempts to solve such problems.

Yes, I believe usb-creator package in ubuntu does exactly this, it lets
local users create USB installation media. Unfortunately even that is by
default only allowed for admins.


--
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/84liksxt1l@sauna.l.org

Re: debuild/dpkg-buildpackage behaves not as expected

[Olе Streicher]

James McCoy  writes:
> On Wed, May 16, 2012 at 09:05:21AM +0200, Olе Streicher wrote:
>> What is the rationale behind the automatic reversal of the applied
>> patches before a cleanup?
>
> Quoting from the bug I meant to refer you to (#649531) when closing the
> debuild bug:
>
>   On one hand, in dpkg's source format v3, the patched source is considered
>   to be standard "unpacked" form.
>   …
>   On the other hand, some people like to work most of the time with the
>   unpatched source, as in pre-v3 days.

That sounds that "some people" were favoured over "standard" here.

> My main point was that you should be trying to drive change through
> dpkg, not through devscripts.

I am not sure who is responsible here -- that's why I've put both
commands into the Subject. 

Cheers

Ole


-- 
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/ytz8vgs8j43@news.ole.ath.cx

Re: Wheezy release: CDs are not big enough any more...

[Ferenc Wagner]

"Thomas Schmitt"  writes:

> I am a bit scared by the catastrophic potential of
>   cat debian.iso > /dev/sdX
> for X = valuable hard disk.

What about recommending /dev/disk/by-id/usb-X instead?
-- 
Feri.


-- 
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/87r4ukwgk6@szonett.ki.iif.hu

Re: Wheezy release: CDs are not big enough any more...

[Neil Williams]

On Wed, 16 May 2012 07:53:55 -0300
Ben Armstrong  wrote:

> On 05/16/2012 06:10 AM, Timo Juhani Lindfors wrote:
> > Bjørn Mork  writes:
> >> No, you don't.  On a default Debian system you need to be a member of
> >> the "floppy" group. From  /lib/udev/rules.d/91-permissions.rules :
> > 
> > Yeah but you are not a member of that group by default surely?
> 
> $ debconf-show user-setup

... that listing isn't available on Squeeze ...

If we're to document this, it would need to be as-per Squeeze.

>   passwd/user-default-groups: audio cdrom dip floppy video plugdev
> netdev powerdev scanner bluetooth

floppy is in my `groups` on Squeeze (scanner is not but the rest on the
list above are).

dialout cdrom floppy sudo audio dip video plugdev netdev bluetooth

dialout and sudo explicitly added, rest are the defaults IIRC.

> At least the initial user created by user-setup at install time will be
> in this group. That would cover everyone with self-administrated
> systems, which I would hazard a guess would be most of our audience. So
> while we can't assume every user has access, we could at least recommend
> in the doc that the command be executed as an ordinary user "where
> possible" to avoid accidental harm.



-- 


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



pgpRZUidabRlY.pgp
Description: PGP signature

Re: Bug#673071: ITP: vodstok -- Voluntary Distributed Storage Kit

[Jonas Smedegaard]

On 12-05-16 at 11:36am, Thomas Preud'homme wrote:
> Le mercredi 16 mai 2012 09:22:46, Jonathan Wiltshire a écrit :
> > Hi,
> > 
> > On 2012-05-15 21:33, Pierre Jaury wrote:
> > > This is an opensource, free and viral  project
> > 
> > Viral? I hope this is just a translation artefact; can you explain
> > exactly what you mean by it?
> 
> From the website linked in the ITP:
> 
> 4. Why is this project "viral" ?
> 
> Once your Vodstok server functional, please drop the last version
> of Vodstok in the root directory of this web application. A webpage
> will be displayed when browsing the index page, and the kit would
> be available from this page. This is the "viral" part.
> 
> Not exactly the definition of viral I have.

It feels obvious to me that it refers to viral marketing: 
http://en.wikipedia.org/wiki/Viral_marketing


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Wheezy release: CDs are not big enough any more...

[Ben Armstrong]

On 05/16/2012 06:10 AM, Timo Juhani Lindfors wrote:
> Bjørn Mork  writes:
>> No, you don't.  On a default Debian system you need to be a member of
>> the "floppy" group. From  /lib/udev/rules.d/91-permissions.rules :
> 
> Yeah but you are not a member of that group by default surely?

$ debconf-show user-setup
...

  passwd/user-default-groups: audio cdrom dip floppy video plugdev
netdev powerdev scanner bluetooth
...

At least the initial user created by user-setup at install time will be
in this group. That would cover everyone with self-administrated
systems, which I would hazard a guess would be most of our audience. So
while we can't assume every user has access, we could at least recommend
in the doc that the command be executed as an ordinary user "where
possible" to avoid accidental harm.

Ben


-- 
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/4fb38743.7040...@sanctuary.nslug.ns.ca

Re: Wheezy release: CDs are not big enough any more...

[Bjørn Mork]

Timo Juhani Lindfors  writes:
> Bjørn Mork  writes:
>> No, you don't.  On a default Debian system you need to be a member of
>> the "floppy" group. From  /lib/udev/rules.d/91-permissions.rules :
>
> Yeah but you are not a member of that group by default surely?

No, that decision should be left to the adminstrator.  The point was
that you don't need to be root, and you probably never should be when
doing something like that (to prevent being only one typo away from
disaster).

>> You mean that they allow you to burn a CD but not write to a USB
>> stick?
>
> Yes, I understood this was the default. If you put users to floppy group
> then remote users can read usb sticks of local users.

I fail to see how burning to a local user's CD is any better, but yes,
if that is a consideration then they need some system to tie the rights
to console access.  I believe ConsoleKit and the replacement
systemd-loginctl attempts to solve such problems.


Bjørn


--
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/87fwb0a0fj@nemi.mork.no

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Adam Borowski]

On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote:
> On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
> > No, I hereby start saying good by to 3.0
> 
> I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also
> found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last
> few packages.

I can't see any reason to use 1.0 anymore, ever.

It is true that 3.0 (quilt) does have a great downside, quilt, but it also
has a number of upsides.  And working around quilt is simple:

echo "single-debian-patch" >debian/source/options
echo "/.pc" >>.gitignore
echo "/debian/patches" >>.gitignore

and perhaps "rm -rf .pc debian/patches" in the clean target if those bother
you -- and you have all the goodies that come with the 3.0 format, with
getting none of quilt brain damage onto you.  Suddenly, nothing conflicts
with the VCS you're using, nothing breaks bisects, nothing causes spurious
recompiles, etc.

Except for nuking upstream debian/ dir which can mean a bit of lost work if
the upstream is sane (and can save some if they're not), the 3.0 format is
strictly better than 1.0.

-- 
“This is gonna be as easy as cheating on an ethics exam!”
-Cerise Brightmoon


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Josselin Mouette  writes:

> Le dimanche 13 mai 2012 à 20:00 +0200, Gergely Nagy a écrit : 
>> > There is a huge difference between gconf, for which you can set one
>> > specific setting in /etc, overriding the default in /usr (and in a way
>> > that will not break the application if the schemas change), and
>> > systemd/udev, which require to copy the *entire* file, leaving behind
>> > any improvements that could made to it in ulterior versions.
>> 
>> Not entirely true. You can override parts of the file too, without
>> copying: include the original. This doesn't let you override everything,
>> but for a lot of things, is good enough.
>
> And then, when the original file changes, you lose the improvements and
> you might even end up with a broken system.
>
> For example if a systemd unit file is updated to match a change of
> behavior in a daemon. Say, from now it requires a pre-exec stanza to do
> stuff it used to do at startup. Your modified file in /etc will not
> include this new stanza and your daemon is broken.

Same problem exists with conf.d/ snippets. It's nothing unique to
systemd, nor to etc-overrides-lib.

If you can override, include or otherwise configure your system in such
a way that you do not get warned when one part changes incompatibly, it
will likely break, indeed.

That is what NEWS.Debian can be used for, for example. But in systemd's
case, there are better options, as discussed in this thread elsewhere
(and from what I've been told, with a little bit of postinst magic, this
can easily become a non-issue, but I haven't tested that yet).

-- 
|8]


--
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/87ipfwphgs.fsf@algernon.balabit

Re: debuild/dpkg-buildpackage behaves not as expected

[James McCoy]

On Wed, May 16, 2012 at 09:05:21AM +0200, Olе Streicher wrote:
> What is the rationale behind the automatic reversal of the applied
> patches before a cleanup?

Quoting from the bug I meant to refer you to (#649531) when closing the
debuild bug:

  On one hand, in dpkg's source format v3, the patched source is considered
  to be standard "unpacked" form.
  …
  On the other hand, some people like to work most of the time with the
  unpatched source, as in pre-v3 days.
  …
  "dpkg-source --after-build" distinguishes between the two cases by
  checking for the ".pc/.dpkg-source-unapply" file, which is added when
  "dpkg-source --before-build" notices that patches were not already
  applied.  You can ensure patches remain applied by applying the
  patches yourself before starting the build.

QUILT_PATCHES=debian/patches quilt push -a
debuild; # or dpkg-buildpackage, or whatever

So, you have a method that you can work with.  My main point was that
you should be trying to drive change through dpkg, not through
devscripts.

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


signature.asc
Description: Digital signature

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Bastien ROUCARIES]

On Tue, May 15, 2012 at 11:10 AM, Jon Dowland  wrote:
> On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
>> No, I hereby start saying good by to 3.0
>
> I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also
> found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last
> few packages.

You could use gitpkg with a quilt export hook. i use it regularly with
imagemagick and it work perfectly (it is gitpkg over git over svn).

Bastien
>
>
> --
> 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/20120515091028.GB24635@debian
>


-- 
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/CAE2SPAaMrJR2y15X0OKteGT47SZ1Ej=QG=v++iywstkvuod...@mail.gmail.com

Re: big .debian.tar.xz - EG Wordpress

[Paul Wise]

On Wed, May 16, 2012 at 5:45 PM, Russell Coker wrote:

> I just downloaded the source to Wordpress from Squeeze, it's got a 14M
> .debian.tar.xz which is mostly sources for things that are included in the
> upstream tarball.  The build process appears to only use the upstream tarball
> code so the 13MB of data in the debian/missing-sources directory isn't used
> for building.

Seems like a bug, the best way to determine that sources are still
buildable is to always build them.

> It is a really good thing to have upstream sources available as dictated by
> the GPL (well done to whoever did that).  But that availability doesn't
> require that they be in the source package.
>
> Would it be possible to have somewhere on the Debian servers for storing such
> files so that they can be referenced in a README file or something rather than
> sent to everyone?  I'm sure that most people who build a Wordpress package
> won't use them.

If I downloaded a source package and didn't get source I would be most
unimpressed.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6EuzQTKMRM2GTwRp6kJRUebsD+B7ObE-aaOo8f_=tr...@mail.gmail.com

big .debian.tar.xz - EG Wordpress

[Russell Coker]

I just downloaded the source to Wordpress from Squeeze, it's got a 14M 
.debian.tar.xz which is mostly sources for things that are included in the 
upstream tarball.  The build process appears to only use the upstream tarball 
code so the 13MB of data in the debian/missing-sources directory isn't used 
for building.

It is a really good thing to have upstream sources available as dictated by 
the GPL (well done to whoever did that).  But that availability doesn't 
require that they be in the source package.

Would it be possible to have somewhere on the Debian servers for storing such 
files so that they can be referenced in a README file or something rather than 
sent to everyone?  I'm sure that most people who build a Wordpress package 
won't use them.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
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/201205161945.56941.russ...@coker.com.au

Re: Bug#673071: ITP: vodstok -- Voluntary Distributed Storage Kit

[Thomas Preud'homme]

Le mercredi 16 mai 2012 09:22:46, Jonathan Wiltshire a écrit :
> Hi,
> 
> On 2012-05-15 21:33, Pierre Jaury wrote:
> > This is an opensource, free and viral  project
> 
> Viral? I hope this is just a translation artefact; can you explain
> exactly what you mean by it?

From the website linked in the ITP:

4. Why is this project "viral" ?

Once your Vodstok server functional, please drop the last version
of Vodstok in the root directory of this web application. A webpage
will be displayed when browsing the index page, and the kit would
be available from this page. This is the "viral" part.

Not exactly the definition of viral I have.

> 
> Thanks,


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

Re: Wheezy release: CDs are not big enough any more...

[Bjørn Mork]

Timo Juhani Lindfors  writes:
> Wookey  writes:
>> And the USB-stick process is not as simple as it might be because you
>> have to find the HD-media files and then _also_ find an iso image to
>> put on. It's no wonder newbs are still downloading CD/DVD images. 
>
> You also need to have root access to some machine to create the USB
> media.

No, you don't.  On a default Debian system you need to be a member of
the "floppy" group. From  /lib/udev/rules.d/91-permissions.rules :

 # default permissions for block devices
 SUBSYSTEM=="block", GROUP="disk"
 SUBSYSTEM=="block", ATTRS{removable}=="1",  GROUP="floppy"

> This means you can't create the installation media at most
> university or library machines unlike with CDs.

You mean that they allow you to burn a CD but not write to a USB stick?
Sounds like they have a support problem which I don't think Debian can
solve for them.


Bjørn


--
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/87zk98a480@nemi.mork.no

Re: Wheezy release: CDs are not big enough any more...

[Timo Juhani Lindfors]

Bjørn Mork  writes:
> No, you don't.  On a default Debian system you need to be a member of
> the "floppy" group. From  /lib/udev/rules.d/91-permissions.rules :

Yeah but you are not a member of that group by default surely?

> You mean that they allow you to burn a CD but not write to a USB
> stick?

Yes, I understood this was the default. If you put users to floppy group
then remote users can read usb sticks of local users.


--
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/84pqa4xzis@sauna.l.org

Re: Bug#673071: ITP: vodstok -- Voluntary Distributed Storage Kit

[Cyril Brulebois]

Jonathan Wiltshire  (16/05/2012):
> Viral? I hope this is just a translation artefact; can you explain
> exactly what you mean by it?

Quite a shock for a project advertised as licensed under the BSD!

(INSTALL.txt says GPLv2 though.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

future of python-pipeline package

[Dmitry Nezhevenko]

Hi,

I'm trying to package a ReviewBoard package that depends on
django-pipeline module. Unfortunately there is already another package
named python-pipeline in debian that uses same python module name
(pipeline). This another package is orphaned for a year:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620067

I've asked it's upstream and author is going to rename it to something
else:

http://code.google.com/p/python-pipeline/issues/detail?id=1

(btw I've also asked upstream of django-pipeline but without any luck for
now)

apt-cache rdepends shows nothing for current python-pipeline. Also popcon
shows only 48 installation without information about usage:

http://qa.debian.org/popcon.php?package=python-pipeline

So I'm asking how to deal with it? django-pipeline looks like more popular
according to project github page and bugtracker. 

Holger suggests to ask here and thinks that it's better to remove orphaned
pipeline package. Any ideas or suggestions?

-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: debuild/dpkg-buildpackage behaves not as expected

[Norbert Preining]

On Mi, 16 Mai 2012, Thibaut Paumard wrote:
> fishy with the default behaviour: anytime you have to patch a file
> which is later modified during build, you have to build with -tc IIRC.

Ouch, I had this case (reautoconf vs patching), it lead me to give 
up on it. It simply is not worth the pain.

Best wishes

Norbert

Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

WOKING (participial vb.)
Standing in the kitchen wondering what you came in here for.
--- Douglas Adams, The Meaning of Liff


-- 
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/20120516085311.gb25...@gamma.logic.tuwien.ac.at

Re: debuild/dpkg-buildpackage behaves not as expected

[Thibaut Paumard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 16/05/12 09:34, Andrey Rahmatullin a ?crit :
> On Wed, May 16, 2012 at 09:05:21AM +0200, Olе Streicher wrote:
>> I just discovered that debuild does not behave as I would expect 
>> from the maintainer's guide [1]:
>> 
>> | Cleaning the source and rebuilding the package from your user 
>> account | is as simple as: | $ debuild [...] | You can clean the 
>> source tree as simply as: | $ debuild clean
>> 
>> This gives an error if the "dh_clean" does not work on the 
>> unpatched source, since "debuild" reverts all patches, but 
>> "debuild clean" does not apply then. I filed a bug report for 
>> this [2], including a simple example package, but the maintainer 
>> doesn't see a problem here.
> (for the reference) ... because "debuild is just a wrapper around 
> dpkg-buildpackage" and the behavior "is documented in 
> dpkg-buildpackage(1)".
> 

Documented, yes. Rationalized, no. I agree that there's something
fishy with the default behaviour: anytime you have to patch a file
which is later modified during build, you have to build with -tc IIRC.
I agree with Ole that unpatching should never be done before cleaning.

Regards, Thibaut.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+zX6UACgkQ+37NkUuUiPEe5QCfZDjHOHmCeu6GIKXWTPlXOxkS
TIoAn1sgi+4ufCCc9yTsnYvR3nVDI5gi
=ALCr
-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/4fb35fa5.5070...@users.sourceforge.net

Re: debuild/dpkg-buildpackage behaves not as expected

[Andrey Rahmatullin]

On Wed, May 16, 2012 at 09:05:21AM +0200, Olе Streicher wrote:
> I just discovered that debuild does not behave as I would expect from
> the maintainer's guide [1]:
> 
> | Cleaning the source and rebuilding the package from your user account
> | is as simple as: 
> | $ debuild
> [...]
> | You can clean the source tree as simply as:
> | $ debuild clean
> 
> This gives an error if the "dh_clean" does not work on the unpatched
> source, since "debuild" reverts all patches, but "debuild clean" does
> not apply then. I filed a bug report for this [2], including a simple
> example package, but the maintainer doesn't see a problem here.
(for the reference) ... because "debuild is just a wrapper around
dpkg-buildpackage" and the behavior "is documented in
dpkg-buildpackage(1)".

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Bug#673071: ITP: vodstok -- Voluntary Distributed Storage Kit

[Jonathan Wiltshire]

Hi,

On 2012-05-15 21:33, Pierre Jaury wrote:

This is an opensource, free and viral  project


Viral? I hope this is just a translation artefact; can you explain 
exactly what you mean by it?


Thanks,

--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51


--
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/a9449e27c74791ff2838a3199b275...@hogwarts.powdarrmonkey.net

debuild/dpkg-buildpackage behaves not as expected

[Olе Streicher]

Hi, 

I just discovered that debuild does not behave as I would expect from
the maintainer's guide [1]:

| Cleaning the source and rebuilding the package from your user account
| is as simple as: 
| $ debuild
[...]
| You can clean the source tree as simply as:
| $ debuild clean

This gives an error if the "dh_clean" does not work on the unpatched
source, since "debuild" reverts all patches, but "debuild clean" does
not apply then. I filed a bug report for this [2], including a simple
example package, but the maintainer doesn't see a problem here.

For me, the behaviour doesn't look good since the state after "debuild"
does not make sense to me: all files created during the build process
(from the patches sources) are still there (including temporary ones),
but the sources themself do not are not patched anymore. So, build
results and sources do not fit together after this step. Even more, if
during the build process one file that has a Debian patch is changed,
unapplying the patch may fail even if the build change would be reverted
during the clean process.

What is the rationale behind the automatic reversal of the applied
patches before a cleanup?

Cheers

Ole

[1] http://www.debian.org/doc/manuals/maint-guide/build.en.html#debuild
[2] http://bugs.debian.org/672378


-- 
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/ytzfwb08v2m@news.ole.ath.cx

Re: RFC: OpenRC as Init System for Debian

[Tollef Fog Heen]

]] Stefan Fritsch 

> For example, the apache2 init script starts htcacheclean if and only 
> if mod_disk_cache is enabled. While this could arguably be considered 
> as an upstrem deficiency, such cases won't simply disappear because 
> systemd becomes more common.

Ideally, they will, but even if they dont…

> And fixing this in the daemon as part of a packager's work is not
> feasible.

ExecStartPre=some_script_that_checks_if_htcacheclean_is_needed_and_starts_it


[...]

> Also, the apache2 init script creates various required directories on 
> volatile file systems like /var/run or /var/lock and supports multiple 
> running instances, but these are more common problems.

tmpfiles.d for the directories, multiple instance support is built-in
already, so that becomes easier if anything.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
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/87wr4c8w1t@qurzaw.varnish-software.com

Bug#673105: ITP: gstreamer0.10-dvswitch -- GStreamer plugin source from DVswitch

[James Bromberger]

Package: wnpp
Severity: wishlist
Owner: James Bromberger 

  Package name: gstreamer0.10-dvswitch
  Version : 0.0.1
  Upstream Author : Tim Ansell 
  URL : https://github.com/timsvideo/gst-dvswitch
  License : GPL
  Description : GStreamer plugin source from DVswitch

 gst-dvswitch is a GStreamer plugin for acquiring a DIF (DV) stream from a
 dvswitch server. The plugin does not require dvswitch to be installed on
 the same machine.  This plugin borrows code quite heavily from udpsrc.



-- 
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/20120516064138.32161.51268.report...@rivendell.james.rcpt.to