Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

[Julian Gilbey]

On Sun, Mar 31, 2013 at 11:45:15AM -0500, Dirk Eddelbuettel wrote:
> 
> A new major release R 3.0.0 will come out on Wednesday April 3rd, as usual
> according the the release plan and announcements [1]. 
> 
> It contains major internal changes [2] and requires rebuilds of all R
> packages.  As I usually do, I started packaging pre-releases and rc
> candidates [3] based on March 24, 27 and 30 snapshots.
> 
> Michael Rutter, who tirelessly backports (most of) my Debian R packages to
> Ubuntu, has also made builds of these R packages [4].  
> 
> As for unstable, we have an issue as essentially all reverse-dependencies
> that are R packages will need to be rebuilt [5]. On testing, I get for
> 158 packages from `apt-cache rdepends r-base-core | grep -c r-cran-`. 

I am a little unclear what is required; is a binary rebuild
sufficient, or is some change in the source code necessary?  If the
former, would it not be better just to ask the buildd administrators
for a binary rebuild as opposed to having a new source version just
for this?

   Julian


-- 
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/20130405075352.gc6...@d-and-j.net

Re: Git packaging workflow discussion on planet.d.o

[Tollef Fog Heen]

]] Andreas Tille 

> Hmmm, you just show some more code as in your blog but this is not
> addressing the three flaws of the workflow I was mentioning in my
> initial mail.  I'm honestly wondering whether I'm missing something
> and these are non-issues.

They seem to just be deficiencies in the tools, something that can be
fixed easily enough with a few patches.

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

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

[Charles Plessy]

Le Fri, Apr 05, 2013 at 08:53:52AM +0100, Julian Gilbey a écrit :
> On Sun, Mar 31, 2013 at 11:45:15AM -0500, Dirk Eddelbuettel wrote:
> 
> I am a little unclear what is required; is a binary rebuild
> sufficient, or is some change in the source code necessary?  If the
> former, would it not be better just to ask the buildd administrators
> for a binary rebuild as opposed to having a new source version just
> for this?

Hi Julian,

for architecture-dependant packages, a binary rebuild is sufficient.  For
arch-independant packages, this facility is not available.  In addition, with
the Freeze, many of us had refrained from updating their packages, so this need
for rebuilds is a good opportunity for update now that the relase is getting
near.

Cheers,

-- 
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/20130405081019.ga32...@falafel.plessy.net

Generators for debian/* files?

[Thomas Koch]

Hi,

debian-java has the tool "mh_make" that generates debian packages from maven 
projects. There's some java code in there that produces debian/* files: rules, 
copyright, watch, control, orig-tar.sh, doc-base.api, doc.install and of 
course source/format and compat.

This java code should be replaces with something in perl/python/non-JVM. Is 
there already some logic/templates in Debian that I could build on?

Regards,

Thomas Koch, http://www.koch.ro


-- 
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/201304051107.32284.tho...@koch.ro

Re: Generators for debian/* files?

[Jonathan Dowland]

On Fri, Apr 05, 2013 at 11:07:31AM +0200, Thomas Koch wrote:
> This java code should be replaces with something in perl/python/non-JVM.

Why?

> Is there already some logic/templates in Debian that I could build on?

dh-make-perl perhaps?


-- 
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/20130405090954.GA16309@debian

SI units (was Re: failure to communicate)

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/04/13 22:43, Christian PERRIER wrote:
> Quoting ian_br...@fastmail.net (ian_br...@fastmail.net):
>
>> If Debian bug report #684128 proves anything, it is that you will never
>> convince anyone with technical argument, facts advanced in support of
>
>
> I perfectly understand you can be frustrated but, honestly, as of now,
> we're focused on the wheezy release, again. Fixing debootstrap has
> much more importance than Giga/Gibibytes. Once wheezy is released, I
> see no reason for your proposed patch to be "rejected".

Sadly, it appears that failure to communicate was from both sides

Ian was told several times that changes may not be accepted for wheezy

However, that communication was overshadowed by several comments
suggesting nobody cares about the issue at all, rather than comments
like that above explaining the relative importance of fixing other issues.

This issue of units comes up again and again, there is a huge thread on
debian-devel in 2007[1] - that hardly seems like something that nobody
cares about.

So while it may not make it into wheezy (I won't give my own opinion on
this one, it is for the release team to decide), I don't think the
reporter of this bug should be deterred by comments about it being a
trivial wishlist or nonsense item.

It may actually be useful for the technical committee to review what is
on the wiki and make some general statement about Debian's position (if
they haven't done so in the past), and that can guide the way similar
bugs are classified for jessie and beyond.

1. http://lists.debian.org/debian-devel/2007/06/thrd2.html#00700

2. http://wiki.debian.org/ConsistentUnitPrefixes


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

iQIcBAEBAgAGBQJRXpjBAAoJEOm1uwJp1aqDmTsQAL7tmMmZqoZevDa4ZhfuxGrh
R8340K+Fn0aZsYI66bxDHg/HDCJtCGfUpfTOYDnYfsSq+D+4X4ZFTJq6ezKvmbrO
mBDCILtq0km753MyfYgnq37/sCbbTrZ/dLKtSWLNioAcqfnqItSC3PqLUYH2l4Tn
MeXNCzMHKiG2J3hvWLM3knc3UMq/QGE2DUHzD32mk8zTCU4lAYOEsJOh8CQFKVri
oYfGnFlC0Yy6+xf/E1An9Gx80qfRf07vW1odtEIMFmtrotocsj+z3xW1Q8LgwvTA
EQ+yXHK7XWSFaruKSbkLyaM826syiRrDBzzTWN9Fi3gptYgJgEY0yGEQViQ6r5SL
eosQlxALWLCCG9HOzXLf0HXlKDg4keRI+Ay1BJJkcNurcvF4v70ee4YxmlmD6lXK
2LiK/wb+FBjId0vpDP/kLRjhljt+kdNXe/4hqbc2d3aIY7Gnqjgz1o/I+x6+atrm
YIKJM6pGTYrFL2vfsIn1mlrbXnqJEyyD04v7U2afb3n1Dxn9zh/6j7L2R0tv5eLl
dCrnBkXjdLMyMaawyzb/uQyP2FvoFjk92XsehKDATLobQBnZvJ7B2ON6qtLWbn1Q
jG5BvdMH++jU7m+yDlctcVo0dakgAd8UnQFvckjH1JhPwRIsmBYUbJu0Y8fqY2Gz
mbpjVc641/AjIS4ytp10
=L0ZB
-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/515e98c5.6010...@pocock.com.au

Re: SI units (was Re: failure to communicate)

[Jonathan Dowland]

On Fri, Apr 05, 2013 at 11:26:29AM +0200, Daniel Pocock wrote:
> It may actually be useful for the technical committee to review what is
> on the wiki and make some general statement about Debian's position (if
> they haven't done so in the past), and that can guide the way similar
> bugs are classified for jessie and beyond.

I really don't think invoking the technical committee is a good idea.
I don't see anyone arguing that this is not a bug, after all.


-- 
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/20130405093620.GB16309@debian

Status of Debian package utility tester

[Thomas Koch]

Hi,

as I've posted some minutes ago I'm searching to generate the files in debian/ 
and remembered the DPU project[1]. It took me some time to find the blogpost 
again and thus the name of the project. It seems the project is stalled since 
august and it has not yet been uploaded to the archive?

[1] http://blog.pault.ag/post/30552124986/a-bit-more-on-dpu

I'll have a look whether its useful for my needs.

Regards,

Thomas Koch, http://www.koch.ro


-- 
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/201304051156.04358.tho...@koch.ro

Bug#704541: marked as done (general: cannot switch open application by taskbar)

[Debian Bug Tracking System]

Your message dated Fri, 5 Apr 2013 11:54:23 +0200
with message-id <201304051154.26778.hol...@layer-acht.org>
and subject line Re: Bug#704541: general: cannot switch open application by 
taskbar
has caused the Debian Bug report #704541,
regarding general: cannot switch open application by taskbar
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
704541: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704541
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: normal

on the bottom of my gnome session i can't click on the open application
all other functions work fine like:
change workspace
scrol over the taskbar to switch applications
the application switcher on top of the screen (near by the clock)



-- System Information:
Debian Release: 6.0.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Hi,

On Dienstag, 2. April 2013, Mark de Bruin wrote:
> on the bottom of my gnome session i can't click on the open application
> all other functions work fine like:
> change workspace
> scrol over the taskbar to switch applications
> the application switcher on top of the screen (near by the clock)
> -- System Information:
> Debian Release: 6.0.7
>   APT policy: (500, 'stable-updates'), (500, 'stable')

I'm sorry to hear this but for user support please try 
debian-u...@lists.debian.org - millions of people have used squeezes gnome 
session without (these) problems.


cheers,
Holger


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

Re: Generators for debian/* files?

[olivier sallou]

dh-make-perl indeed for Perl CPAN packages.

dh-make for base packages...

Olivier


2013/4/5 Thomas Koch 

> Hi,
>
> debian-java has the tool "mh_make" that generates debian packages from
> maven
> projects. There's some java code in there that produces debian/* files:
> rules,
> copyright, watch, control, orig-tar.sh, doc-base.api, doc.install and of
> course source/format and compat.
>
> This java code should be replaces with something in perl/python/non-JVM. Is
> there already some logic/templates in Debian that I could build on?
>
> Regards,
>
> Thomas Koch, http://www.koch.ro
>
>
> --
> 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/201304051107.32284.tho...@koch.ro
>
>


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: Generators for debian/* files?

[Wookey]

+++ Jonathan Dowland [2013-04-05 10:09 +0100]:
> On Fri, Apr 05, 2013 at 11:07:31AM +0200, Thomas Koch wrote:
> > This java code should be replaces with something in perl/python/non-JVM.
> 
> Why?

Because it's an entirely unnecessary circular build-dependency. java
is not part of build-essential and this doesn't seem like a good
reason for making it so.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.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/20130405101742.gz2...@stoneboat.aleph1.co.uk

Re: Git packaging workflow discussion on planet.d.o

[Guillem Jover]

On Thu, 2013-04-04 at 23:07:04 +0800, Thomas Goirand wrote:
> gen-author-list:
> git log --format='%aN <%aE>' | awk '{arr[$$0]++} END{for (i in
> arr){print arr[i], i;}}' | sort -rn | cut -d' ' -f2-

A better way to write the above could be:

gen-author-list:
git shortlog -nes | tr -s ' '| cut -f2-

which in addition will fix up the authors using any .mailmap rules.

Thanks,
Guillem


-- 
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/20130405105720.ga19...@gaara.hadrons.org

Re: Git packaging workflow discussion on planet.d.o

[Guido Günther]

On Thu, Apr 04, 2013 at 09:38:36AM -0700, Russ Allbery wrote:
> Jean-Christophe Dubacq  writes:
> 
> > Yesterday, however, I just had the case of a project with no tarballs
> > (as the library I wanted to package is part of a larger project, it's
> > not released independently). I stumbled (too long) on having a good
> > workflow for this (I ended up tagging myself the upstream tree).
> 
> Using git archive to generate a tarball from upstream is something that I
> do in some cases as well.  It all depends on upstream's release process.
> I default to using released tarballs if they exist and are useful, but I
> fall back to git archive when they're not.
> 
> For example, for OpenAFS, upstream releases the software as two separate
> tarballs, one with the code and one with the documentation.  I don't find
> this a useful organizational structure for the Debian packaging, nor are
> they split in the upstream repository, so I use git archive to generate a
> tarball instead.  This means that the tarball Debian uses doesn't match
> upstream, which is a drawback, but in this case I know upstream practices
> well enough to know that it shouldn't matter.
> 
> The only thing to be aware of with git archive is that you still want to
> use pristine-tar, since otherwise you either have to redownload the
> *.orig.tar.gz from Debian or you have to keep it around somewhere.
> Running git archive twice on the same tag won't produce the same file
> reliably.

git-buildpackage can handle the tarball generation + pristine tar
interaction with the '--git-pristine-tar-commit' option. It will then
generate the tarball and commit the delta back to the pristine-tar
branch.
Cheers,
 -- Guido


-- 
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/20130405110458.ga21...@bogon.sigxcpu.org

Re: SI units (was Re: failure to communicate)

[Paul Tagliamonte]

Can we *PLEASE* stop making new threads. It's getting *REALLY* hard to
keep playing whack-a-mole with my bozo bin.

Keep it all on the same thread. We don't need to 5 threads about this
nonsense. It's starting to get annoying.

On Fri, Apr 05, 2013 at 11:26:29AM +0200, Daniel Pocock wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 04/04/13 22:43, Christian PERRIER wrote:
> > Quoting ian_br...@fastmail.net (ian_br...@fastmail.net):
> >
> >> If Debian bug report #684128 proves anything, it is that you will never
> >> convince anyone with technical argument, facts advanced in support of
> >
> >
> > I perfectly understand you can be frustrated but, honestly, as of now,
> > we're focused on the wheezy release, again. Fixing debootstrap has
> > much more importance than Giga/Gibibytes. Once wheezy is released, I
> > see no reason for your proposed patch to be "rejected".
> 
> Sadly, it appears that failure to communicate was from both sides
> 
> Ian was told several times that changes may not be accepted for wheezy
> 
> However, that communication was overshadowed by several comments
> suggesting nobody cares about the issue at all, rather than comments
> like that above explaining the relative importance of fixing other issues.
> 
> This issue of units comes up again and again, there is a huge thread on
> debian-devel in 2007[1] - that hardly seems like something that nobody
> cares about.
> 
> So while it may not make it into wheezy (I won't give my own opinion on
> this one, it is for the release team to decide), I don't think the
> reporter of this bug should be deterred by comments about it being a
> trivial wishlist or nonsense item.
> 
> It may actually be useful for the technical committee to review what is
> on the wiki and make some general statement about Debian's position (if
> they haven't done so in the past), and that can guide the way similar
> bugs are classified for jessie and beyond.
> 
> 1. http://lists.debian.org/debian-devel/2007/06/thrd2.html#00700
> 
> 2. http://wiki.debian.org/ConsistentUnitPrefixes
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQIcBAEBAgAGBQJRXpjBAAoJEOm1uwJp1aqDmTsQAL7tmMmZqoZevDa4ZhfuxGrh
> R8340K+Fn0aZsYI66bxDHg/HDCJtCGfUpfTOYDnYfsSq+D+4X4ZFTJq6ezKvmbrO
> mBDCILtq0km753MyfYgnq37/sCbbTrZ/dLKtSWLNioAcqfnqItSC3PqLUYH2l4Tn
> MeXNCzMHKiG2J3hvWLM3knc3UMq/QGE2DUHzD32mk8zTCU4lAYOEsJOh8CQFKVri
> oYfGnFlC0Yy6+xf/E1An9Gx80qfRf07vW1odtEIMFmtrotocsj+z3xW1Q8LgwvTA
> EQ+yXHK7XWSFaruKSbkLyaM826syiRrDBzzTWN9Fi3gptYgJgEY0yGEQViQ6r5SL
> eosQlxALWLCCG9HOzXLf0HXlKDg4keRI+Ay1BJJkcNurcvF4v70ee4YxmlmD6lXK
> 2LiK/wb+FBjId0vpDP/kLRjhljt+kdNXe/4hqbc2d3aIY7Gnqjgz1o/I+x6+atrm
> YIKJM6pGTYrFL2vfsIn1mlrbXnqJEyyD04v7U2afb3n1Dxn9zh/6j7L2R0tv5eLl
> dCrnBkXjdLMyMaawyzb/uQyP2FvoFjk92XsehKDATLobQBnZvJ7B2ON6qtLWbn1Q
> jG5BvdMH++jU7m+yDlctcVo0dakgAd8UnQFvckjH1JhPwRIsmBYUbJu0Y8fqY2Gz
> mbpjVc641/AjIS4ytp10
> =L0ZB
> -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/515e98c5.6010...@pocock.com.au
> 

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: Status of Debian package utility tester

[Paul Tagliamonte]

On Fri, Apr 05, 2013 at 11:56:04AM +0200, Thomas Koch wrote:
> Hi,
> 
> as I've posted some minutes ago I'm searching to generate the files in 
> debian/ 
> and remembered the DPU project[1]. It took me some time to find the blogpost 
> again and thus the name of the project. It seems the project is stalled since 
> august and it has not yet been uploaded to the archive?

Yeah. It got to the point where there was enough there to start writing
tests to help replace Lintian's, but never got around to actually
porting them over.

It's actually not a bad tool, if you want to hack on it, I'll move it
off my github and onto a git.d.o repo -- I'd be happy to help (and
perhaps nthykier as well)

> 
> [1] http://blog.pault.ag/post/30552124986/a-bit-more-on-dpu
> 
> I'll have a look whether its useful for my needs.

Yep! I'd be happy to help with it, if it's got some problems (which I
bet it does, we never actually put it to real use)

> 
> Regards,
> 
> Thomas Koch, http://www.koch.ro
> 
> 
> -- 
> 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/201304051156.04358.tho...@koch.ro
> 

Cheers,
  T

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

alternative debian/rules

[Игорь Пашев]

I've just realized that debian/rules might not be a makefile, but can
be a script in any language.

Is there any package using debian/rules whihc is not a makefile?
Are there any packages that can get advantages by using debian/rules
written in bash/perl/python/etc?


-- 
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/call-q8zdme0i22qwgjxjrbstqxehk03zgcr+xb+6d5z59n9...@mail.gmail.com

Re: failure to communicate

[Thomas Goirand]

On 04/05/2013 04:43 AM, Christian PERRIER wrote:
> Nothing proves that the patches you proposed will be ignored *after*
> the release of wheezy.
Christian,

Not fixing this bug would be a very bad move, because it can lead
to having partitions not aligned to a 4K boundary, meaning that
your system would be slow.

Please do consider 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/515eb76f.3060...@debian.org

Re: alternative debian/rules

[Timo Weingärtner]

Hallo Игорь Пашев,

2013-04-05 um 13:32:24 schriebst Du:
> I've just realized that debian/rules might not be a makefile, but can
> be a script in any language.
> 
> Is there any package using debian/rules whihc is not a makefile?
> Are there any packages that can get advantages by using debian/rules
> written in bash/perl/python/etc?

See http://bugs.debian.org/636016 ;-)


Grüße
Timo


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

Re: alternative debian/rules

[Simon McVittie]

On 05/04/13 12:32, Игорь Пашев wrote:
> I've just realized that debian/rules might not be a makefile, but can
> be a script in any language.

This is technically possible (dpkg allows it), but not acceptable for
Debian packages (Debian Policy requires that debian/rules is an
executable makefile).

> Is there any package using debian/rules whihc is not a makefile?

There have been a few in the past.

S


-- 
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/515eb848.7050...@debian.org

Re: alternative debian/rules

[Adam Borowski]

On Fri, Apr 05, 2013 at 03:32:24PM +0400, Игорь Пашев wrote:
> I've just realized that debian/rules might not be a makefile, but can
> be a script in any language.

The policy says:

# 4.9. Main building script: `debian/rules'
# -
#
# This file must be an executable makefile, and contains the
# package-specific recipes for compiling the package and building binary
# package(s) from the source.

> Is there any package using debian/rules which is not a makefile?
> Are there any packages that can get advantages by using debian/rules
> written in bash/perl/python/etc?

Because of the following requirement, it's not that easy.

It can be done, here's an example how to use a JIT C compiler (tcc)
this way:
  dget http://angband.pl/debian/pool/main/g/goodbye/goodbye_0.2-1.dsc
although you might have trouble smuggling this through the FTPmasters :p

On the other hand, one of fresh DDs already thanked me for this example,
so be afraid.  Be very afraid.

Hope this helps :)

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130405114149.ga7...@angband.pl

Re: alternative debian/rules

[Rene Engelhard]

Hi,

On Fri, Apr 05, 2013 at 03:32:24PM +0400, Игорь Пашев wrote:
> I've just realized that debian/rules might not be a makefile, but can
> be a script in any language.

Not really.

http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules

"This file must be an executable makefile, [...]"

That it might work with something else might be, but that's not
allowed anyway.

Regards,

Rene


--
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/20130405114016.gf...@rene-engelhard.de

Re: Generators for debian/* files?

[Johannes Schauer]

Hi,

Quoting Wookey (2013-04-05 12:17:42)
> Because it's an entirely unnecessary circular build-dependency. java
> is not part of build-essential and this doesn't seem like a good
> reason for making it so.

mh_make is part of the package maven-debian-helper (Thomas: I cant find the
package debian-java you were talking about) but according to the bootstrap
tools, maven-debian-helper is not part of any dependency cycle.

I would be glad if you can prove me wrong because then you found yet another
bug in my code. :)

A java helper which is part of many dependency cycles, is the package
javahelper which is part of the main SCC. It seems that 233 source packages
relevant for the bootstrap process build depend on javahelper (out of a total
of 290 source packages build depending on it).

cheers, josch


--
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/20130405114542.14032.2997@hoothoot

Re: alternative debian/rules

[Thomas Preud'homme]

Le vendredi 5 avril 2013 13:41:50, Adam Borowski a écrit :
> 
> It can be done, here's an example how to use a JIT C compiler (tcc)
> this way:
>   dget http://angband.pl/debian/pool/main/g/goodbye/goodbye_0.2-1.dsc
> although you might have trouble smuggling this through the FTPmasters :p
> 
> On the other hand, one of fresh DDs already thanked me for this example,
> so be afraid.  Be very afraid.

I'd be scared if it was uploaded to Debian but as the maintainer of tcc I'm 
quite amused and happy to see people use it to do crazy stuff.

> 
> Hope this helps :)

Best regards,

Thomas


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

Re: Generators for debian/* files?

[Adam D. Barratt]

On 05.04.2013 12:45, Johannes Schauer wrote:

(Thomas: I cant find the package debian-java you were talking about)


That's because it's a group of people, not a package...

Regards,

Adam


--
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/515f5f71569c2c8c547d9c33419dd...@mail.adsl.funky-badger.org

Bug#704746: ITP: r-cran-armadillo -- R bindings to Armadillo C++ linear algebra library

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-armadillo
  Version : 0.3.800.1-1
  Upstream Author : Dirk Eddelbuettel et al (for RcppArmadillo), 
Conrad Sanderson (for Armadillo)
* URL or Web page : http://dirk.eddelbuettel.com/code/rcpp.armadillo.html
* License : GPL (>= 2) [for RcppArmadillo], MPL 2 [for Armadillo]
  Description : R bindings to Armadillo C++ linear algebra library

RcppArmadillo is becoming more popular within the R world, there are now
about 30 CRAN packages which use it -- and that now includes Amelia (which
is packaged as r-cran-amelia) so we need it in Debian anyway.

I am upstream and should be able to provide concurrent releases within Debian
as I have done for years with Rcpp (that this packages depends upon).

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com


-- 
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/87r4ipmbhg@max.nulle.part

SI units (was Re: failure to communicate)

[Ian Jackson]

Daniel Pocock writes ("SI units (was Re: failure to communicate)"):
> It may actually be useful for the technical committee to review what is
> on the wiki and make some general statement about Debian's position (if
> they haven't done so in the past), and that can guide the way similar
> bugs are classified for jessie and beyond.
> 
> 1. http://lists.debian.org/debian-devel/2007/06/thrd2.html#00700
> 
> 2. http://wiki.debian.org/ConsistentUnitPrefixes

You should try to address this through the policy process.  If and
when we have competing policy proposals the TC might want to
arbitrate.

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

Epoch usage conventions (was Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)

[Ian Jackson]

Guillem Jover writes ("Epoch usage conventions (was Re: R 3.0.0 and required 
rebuilds of all reverse Depends: of R)"):
> Well, I strongly disagree that in general using epochs for packaging
> mistakes is a good practice (and I've thought so even before Ubuntu
> existed). The main purpose of epochs is to be able to handle mistakes
> or changes in the version numbering itself. Say upstream resets their
> versioning from v450 to 0.0.0, or from date based 20130404 to 0.0.0
> (although the packager could have avoided that by prefixing with "0."),
> or if they used something like 1.210 and they meant 1.2.10 (svgalib),
> or a package takes over another's name (git).

I agree entirely with what Guillem says.

> Also, introducing an epoch where there was none in an NMU should be
> frowned upon, unfortunately I've seen multiple instances of these in
> the recent past, something I'd be very upset if it happened to any of
> the packages I maintain.

I wonder if this should be explicitly stated in the dev ref.

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

Re: failure to communicate

[Dmitrijs Ledkovs]

On 4 April 2013 20:47,   wrote:
> On Thu, 4 Apr 2013 19:09:04 +0200
> Christian PERRIER  wrote:
>
>> This mail is a very good argument to confirm that overcomplicated
>> methods to make your point will just fail.
>>
>> If you have a point to make it, make ti. Once. With facts.
>
> I supplied plenty of facts.

I was not following this bug report but reading it, it reminds me of
the Unit Policy [1] that got approved and is gradually implemented in
ubuntu/debian packages.

Looking at d-i the usage is mostly correct sans 'k' should only be
used lower-cased with current base-10 units.

The major problem with changing these is that same prefixes are
accepted for pre-seeding and it would be ill-advised to change those,
thus backwards compatability must be preserved in the values that can
be preseeded as well as entered by the user.

The default to base-10 units, is good as majority of the installer
deals with HDD drives (not SSD) and not RAM. If I have 1TB drive and
want half of it for one thing and 1/4 for this and 1/4 for that, no
space should be left on the drive. Hence matching and using same units
as disk-manufacturers is good.

The case where we mix & match => e.g. making swap big enough (base-10)
for RAM size (base-2) is tricky. And it's something to consider in the
UI.

I understand your frustration, but as it happens installer
work/improvements becomes a hot topic post-freeze as this is when
people start to use the installer, notice things and try to write
features. And all of these features will only land for the next cycle
with a release in ~= 2 years time. Tell me about bad timing, eh?! =)

W.r.t. boundry alignments, I believe it its already aligning at 2048
by default and there is ongoing work to align with 4K boundries
properly. But note that boundry alignment has little to do with user
displaying/specifying amount of gigaheaps one wants to be allocated
where.

Everyone seems to agree to bring support to input/output Ki/Mi etc
prefixes. That's a feature and can only go into jessie branches and or
wait for wheezy release. Once that lands we can bike shed to death
where to display what units and what to default to where going
forward.

[1] https://wiki.ubuntu.com/UnitsPolicy

Regards,

Dmitrijs.

ps. there are disk manufactures that mix base-2 and base-10 units.
E.g. using one to calculate "1MB" and then using the other multiply
and gain GB/TB factors /o\


-- 
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/canbhluhxq96h7ejrsfm7emomvmkdmuc7buyez1jgenrxpuq...@mail.gmail.com

SI units (was: failure to communicate)

[Benjamin Drung]

Am Freitag, den 05.04.2013, 12:59 +0100 schrieb Dmitrijs Ledkovs:
> The default to base-10 units, is good as majority of the installer
> deals with HDD drives (not SSD) and not RAM.

SSD manufactures use base-10 units, too. Even 128 GB SSDs have 128 *
10^9 bytes for the users, but 128 * 2^30 bytes internally. The
difference between 128 GiB and 128 GB (9.44 GB) is used for
over-provisioning.

> ps. there are disk manufactures that mix base-2 and base-10 units.
> E.g. using one to calculate "1MB" and then using the other multiply
> and gain GB/TB factors /o\

I know one example: The "1.44 MB" labeled floppy, which contains twice
as much space as a "720 KB" floppy. The "720 KB" floppy has 720 KiB and
the "1.44 MB" has 2 * 720 KiB = 1.44 * 1000 * 1024 bytes = 1.41 MiB =
1.47 MB!

-- 
Benjamin Drung
Debian & Ubuntu Developer


-- 
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/1365165546.3086.10.camel@deep-thought

Re: alternative debian/rules

[Игорь Пашев]

2013/4/5 Adam Borowski :
> The policy says


Indeed.

So, in any case one can use its own tool just like dh:

%:
debian/megatool $@


-- 
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/CALL-Q8z603EAhb86khzjAfOY1XvO42A+Li_V5mrjUx=w+uq...@mail.gmail.com

threads, Subjects: and mailers (was Re: SI units (was Re: failure to communicate))

[Jonathan Dowland]

On Fri, Apr 05, 2013 at 07:28:32AM -0400, Paul Tagliamonte wrote:
> Can we *PLEASE* stop making new threads. It's getting *REALLY* hard to
> keep playing whack-a-mole with my bozo bin.

Fix your mailer… I see precisely one thread, correctly linked together
via message-id and references headers, with the subject changing on occasion,
which is generally encouraged to make sure it stays relevant as the
conversation changes.


-- 
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/20130405130244.GA25062@debian

Re: failure to communicate

[Andrey Rahmatullin]

On Fri, Apr 05, 2013 at 07:37:19PM +0800, Thomas Goirand wrote:
> > Nothing proves that the patches you proposed will be ignored *after*
> > the release of wheezy.
> Christian,
> 
> Not fixing this bug would be a very bad move, because it can lead
> to having partitions not aligned to a 4K boundary, meaning that
> your system would be slow.
If any tools don't round partition starts to 4K by default they should be
fixed.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Bug#704760: ITP: python-pecan -- WSGI object-dispatching web framework

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-pecan
  Version : 0.2.1
  Upstream Author : Jonathan LaCour 
* URL : https://github.com/dreamhost/pecan
* License : BSD
  Programming Lang: Python
  Description : WSGI object-dispatching web framework

 The Pecan Python module is a WSGI object-dispatching web framework designed to
 be lean and fast with few dependencies. Pecan comes bundled with a lightweight
 WSGI development server based on Python's wsgiref.simpleserver. Pecan
 applications also come with an interactive Python shell which can be used to
 execute expressions in an environment very similar to the one your application
 runs in (using the "pecan shell" command).


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

Re: Generators for debian/* files?

[Thomas Koch]

Jonathan Dowland:
> On Fri, Apr 05, 2013 at 11:07:31AM +0200, Thomas Koch wrote:
> > This java code should be replaces with something in perl/python/non-JVM.
> 
> Why?

Wookeys response (circular build-dependency) is not the reason here. We have 
two packages, maven-repo-helper with minimal dependency set which is a build 
dependency for many java packages and maven-debian-helper with a longer 
dependency list which is only used to create the files in debian/*.

mh_make does not have automatic testing yet and is much work to test manually. 
This is mostly caused by the unnecessary dependency on maven to do something 
as trivial as filling templates for the debian/* files with appropriate 
values.

Regards,

Thomas Koch, http://www.koch.ro


-- 
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/201304051730.41743.tho...@koch.ro

Re: failure to communicate

[The Wanderer]

On 04/05/2013 10:40 AM, Andrey Rahmatullin wrote:


On Fri, Apr 05, 2013 at 07:37:19PM +0800, Thomas Goirand wrote:



Not fixing this bug would be a very bad move, because it can lead to having
partitions not aligned to a 4K boundary, meaning that your system would be
slow.


If any tools don't round partition starts to 4K by default they should be
fixed.


I can't speak to the wheezy installer, but at least the squeeze installer's
partitioner doesn't appear to do so; I got bit by that a couple of weeks back,
and had quite a bit of aggravation getting the partitions laid out and
filesystems created by hand.

--
   The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
  - LiveJournal user antonia_tiger


--
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/515ef0a8.9070...@fastmail.fm

Re: failure to communicate

[Thomas Goirand]

On 04/05/2013 07:59 PM, Dmitrijs Ledkovs wrote:
> The default to base-10 units, is good as majority of the installer
> deals with HDD drives (not SSD) and not RAM.
Come on... it's not! Let's be serious 5 minutes here.
There isn't even a warning about which units are in use.
This fools our users (me included, for many years...).

The freeze of Wheezy might be an argument, but what you
wrote above, really isn't one.

On 04/05/2013 07:59 PM, Dmitrijs Ledkovs wrote:
> And all of these features will only land for the next cycle
> with a release in ~= 2 years time.
I really hope that it wont be the case. That it doesn't go into
Debian 7.0.0, I would understand, but at least, we need it
for a point release. And at least, we need things written in
the release notes about it, if not a message in the installer
itself (Christian, don't kill me... ;).

Could we stop the winning and have this bug fixed please,
or the patch rejected (with a valid motivation)?

Thomas

P.S: Not only with SSD you have problems with boundaries.


-- 
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/515ef333.9000...@debian.org

Re: sprezzos apt-show-rewrite complete (report + numbers)

[Julian Andres Klode]

On Wed, Mar 20, 2013 at 06:31:11AM -0400, nick black wrote:
> This is a followup to my post to debian-devel, debian-derivatives, deity,
> and sprezzos-dev last Monday entitled "apt-show-versions rewrite". This
> post is strictly informative, and does not advocate any policy.
> 
> Documentation has been substantially embeefened, including design notes:
> 
>  https://www.sprezzatech.com/wiki/index.php/Raptorial 
>  https://github.com/dankamongmen/raptorial
> 
> rapt-show-versions(1), part of the RAPTORIAL suite, has become
> feature-equivalent to the native apt-show-versions(1) tool, as predicted.
> Despite fleshing out the features, I've managed to retain its speed.

[...]

> Pretty constant performance from both. Let's call it 1.17s vs .13s on the
> quadcore and 1.12s vs .16s on the dualcore (this perhaps surprising result
> can be explained by the fact that there are fewer packages installed on the
> dualcore).
> 
>  Quadcore winner: RAPTORIAL at 11% running time
>  Dualcore winner: RAPTORIAL at 11% running time
>  Champion: RAPTORIAL with a ~90% reduction in time
> 
> Oh btw, if you don't take it to /dev/null, RAPTORIAL beats apt-show-versions
> by several seconds. It is absolutely faster across the board.
> 
> Gentlemen, you claimed that you could "whip up a C++ apt-show-versions" and
> get similar performance. Consider the gauntlet thrown, and the mic dropped.
> I look forward to your results.
> 

$ env time ./usr/bin/apt-show-versions > /dev/null
0.02user 0.01system 0:00.04elapsed 76%CPU (0avgtext+0avgdata 20856maxresident)k
0inputs+0outputs (0major+7165minor)pagefaults 0swaps

I currently have 0.04 - 0.05 seconds for my prototype using apt-pkg, including
policy and configuration handling, which you do not have. The tool completely
works from the APT cache like the other tools, and can thus skip parsing
altogether. apt-show-versions takes 1.2 seconds.

The code is attached; it takes some further work to add some missing
functionality (not that much though, just different output format,
and configuration parsing). Output is also not sorted currently.

I'll try to get this finished and merged into APT for jessie.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
/* apt-show-versions.cc - apt-show-versions for APT
 *
 * Copyright (C) 2011-2013 Julian Andres Klode 
 *
 * Permission is hereby granted, free of charge, to any person
 * obtaining a copy of this software and associated documentation files
 * (the "Software"), to deal in the Software without restriction,
 * including without limitation the rights to use, copy, modify, merge,
 * publish, distribute, sublicense, and/or sell copies of the Software,
 * and to permit persons to whom the Software is furnished to do so,
 * subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be
 * included in all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
 * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
 * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 * SOFTWARE.
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 

std::string my_name(pkgCache::PkgIterator p, pkgCache::VerIterator c)
{
auto name = p.FullName(true);

for (auto vf = c.FileList(); c.IsGood(); c++) {
if (vf.File().Codename())
return name + "/" + vf.File().Codename();
if (vf.File().Archive())
return name + "/" + vf.File().Archive();
}
return name;
}

bool has_older(pkgCache::PkgIterator p)
{
pkgCache::VerIterator current = p.CurrentVer();


for (auto other = p.VersionList(); other.IsGood(); other++)
if (other->ID != current->ID && _system->VS->CmpVersion(current.VerStr(), other.VerStr()) > 0)
return true;

return false;
}

pkgCache::VerIterator find_newest(pkgCache::PkgIterator p)
{
pkgCache::VerIterator newest = p.CurrentVer();

for (auto other = p.VersionList(); other.IsGood(); other++)
if (_system->VS->CmpVersion(newest.VerStr(), other.VerStr()) < 0)
newest = other;

return newest;
}

int main(void)
{
pkgInitConfig(*_config);
pkgInitSystem(*_config, _system);
pkgCacheFile cachefile;
pkgCache *cache = cachefile.GetPkgCache();
pkgPolicy *depcache = cachefile.GetPolicy();


if (cache == NULL) {
_error->DumpErrors();
return 1;
}

for (auto p = cache->PkgBegin(); p != cache->PkgEnd(); p++) {
if (p->CurrentVer == 0)
continue;

auto current = p.CurrentVer();
aut

Re: failure to communicate

[Didier 'OdyX' Raboud]

Hi Thomas,

Le vendredi, 5 avril 2013 17.52:19, Thomas Goirand a écrit :
> On 04/05/2013 07:59 PM, Dmitrijs Ledkovs wrote:
> > And all of these features will only land for the next cycle
> > with a release in ~= 2 years time.
> 
> I really hope that it wont be the case. That it doesn't go into
> Debian 7.0.0, I would understand, but at least, we need it
> for a point release.

Are you seriously arguing in favour of pushing a behavioural change into a 
stable point release? I doubt the stable release team would accept that, but 
I'm not under their hats.

> And at least, we need things written in the release notes about it, if not a
> message in the installer itself (Christian, don't kill me... ;).

I disagree. It has worked that way for a long time (and many releases in that 
timeframe), so it is probably not "that" broken.

I'm not saying the bug isn't valid of course, just that it's severity is IMHO 
correct.

> Could we stop the winning and have this bug fixed please,
> or the patch rejected (with a valid motivation)?

Could we stop the useless bikeshedding and have Wheezy released please?

The patch doesn't need rejection: it is a valid patch for a valid bug. It just 
affects d-i, which is quite an important piece of software for sane Debian 
releases. As you know, d-i is critically low on manpower.

You want that bug fixed? Great: test the patch, document your tests, upload to 
experimental with the patch, gather feedback, get involved, etc. For a fix to 
land in Wheezy, this should have happened 8 months ago. Now is the time to 
release Wheezy, not the time to add cosmetic and disruptive fixes to it. (And 
again, I think the changes are probably worthwhile, it's only the timing which 
is wrong.)

OdyX


--
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/201304051816.11079.o...@debian.org

Re: Bug#684128: down the memory hole

[Axel Beckert]

Hi Ian.

ian_br...@fastmail.net wrote:
> It seems that Historical Revisionism, of the bad kind, is now in
> operation at Debian, in that critical commentary about unapplied patches
> is made to disappear down the memory hole, without leaving so much as a
> trace on the relevant bug report.
> 
> If it were thought that the criticism was unfair, or inaccurate, then it
> could be allowed to remain in place, so that other people might judge
> its lack of merit for themselves.
> 
> In the case of bug #684128, post #108, however, the fact that the
> offending message was promptly vaporized* (as will be this one also), of
> course suggests that the opposite is true.

I'm (again) not really sure what you mean with these paragraphs, but
the message

> Subject: Bug#684128: Info received ("When I use a word," Humpty Dumpty 
> said...)
> Message-ID: 
> References: <20130402083114.6bba69b4.ian_br...@fastmail.net>

(for reference, that mail is available online at
http://lists.debian.org/20130402083114.6bba69b4.ian_br...@fastmail.net)

looked a lot like non-sense spam to me and I reported it as such in
the BTS. And obviously the one reading that report was of the same
opinion. I wouldn't be surprised if others hit the "Send a report that
this bug log contains spam" link after that mail of yours, too.

If you want to make comments about bugs that people should actually
read, please make sure that your mail is concise and does not tell
fairy tales to hide your intent. The BTS is no literature contest.

TIA.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


-- 
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/20130405161826.gb28...@sym.noone.org

Bug#704766: ITP: rapicorn -- The Rapicorn Toolkit

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: rapicorn
  Version : 13.03.0
  Upstream Author : Tim Janik 
* URL : http://rapicorn.org
* License : LGPL
  Programming Lang: C++
  Description : The Rapicorn Toolkit

 Rapicorn is a toolkit for rapid development of graphical user
 interfaces using C++ and Python. Rapicorn is developed with
 the aim to significantly improve developer efficiency and user
 experience.
 .
 Rapicorn brings UI-design, UI-notation and UI-programming as
 close together as possible. To accomplish this, it provides
 conscise ways for UI notation, usable also throughout design
 phases. Simple but powerful programming mechanisms are
 provided to automate binding of programming and GUI logic and
 to minimize manual work.


-- 
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/20130405163731.9649.27517.reportbug@Aspire-1410

Re: Re: failure to communicate

[ian_bruce]

 a écrit :

> You want that bug fixed? Great: test the patch, document your tests

I did all that.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#103

> gather feedback, get involved

quoting from the above:

I would be interested to hear suggestions as to what sort of tests
of binary mode operation would be considered sufficient for the
patch to be accepted.

> For a fix to land in Wheezy, this should have happened 8 months ago.

Check the date on the above post.

> disruptive fixes

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#66

quote:

I take the point that it is not currently feasible to get
translations of new or changed text for the installer. What I
propose is to apply this small patch, and make no changes at all to
any text. When operating in decimal mode, the new code is
functionally identical to the old, apart from the improvements
listed above. When operating in binary mode, identical input text
will simply be interpreted as s*(2^(10*n)) rather than s*(10^(3*n)).

The choice of whether the partitioner operates in binary or decimal
mode can be controlled by a boot parameter, so as not to introduce
any new user-visible text into the installer.

Now we can all fight about whether the default partitioning mode
should be binary or decimal. I'm curious to hear why, if just about
nobody cares about the difference between 2^(10*n) and 10^(3*n), it
would be unacceptable to default to 2^(10*n), which is what just
about everybody who does care would expect.


--
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/20130405094852.686d4c5c.ian_br...@fastmail.net

Re: alternative debian/rules

[Russ Allbery]

Игорь Пашев  writes:

> Indeed.

> So, in any case one can use its own tool just like dh:

> %:
> debian/megatool $@

Yes, from a Policy perspective.  Although please consider using dh and its
framework instead to make life easier for everyone else in the project who
may have to help out with maintaining the package, such as the security
team.  It has a nice plugin module system that lets you add custom
infrastructure for particular types of projects without changing the basic
framework.

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

Re: failure to communicate

[Thomas Goirand]

On 04/05/2013 10:40 PM, Andrey Rahmatullin wrote:
> On Fri, Apr 05, 2013 at 07:37:19PM +0800, Thomas Goirand wrote:
>>> Nothing proves that the patches you proposed will be ignored *after*
>>> the release of wheezy.
>> Christian,
>>
>> Not fixing this bug would be a very bad move, because it can lead
>> to having partitions not aligned to a 4K boundary, meaning that
>> your system would be slow.
> If any tools don't round partition starts to 4K by default they should be
> fixed.
Right! Let's fix d-i then!!!

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/515f1ceb.70...@debian.org

Re: failure to communicate

[Andrey Rahmatullin]

On Sat, Apr 06, 2013 at 02:50:19AM +0800, Thomas Goirand wrote:
> >>> Nothing proves that the patches you proposed will be ignored *after*
> >>> the release of wheezy.
> >> Christian,
> >>
> >> Not fixing this bug would be a very bad move, because it can lead
> >> to having partitions not aligned to a 4K boundary, meaning that
> >> your system would be slow.
> > If any tools don't round partition starts to 4K by default they should be
> > fixed.
> Right! Let's fix d-i then!!!
Please start with reproducing the problem and filing a bug if the problem
indeed exists.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: failure to communicate

[Thomas Goirand]

On 04/06/2013 12:16 AM, Didier 'OdyX' Raboud wrote:
> Hi Thomas,
>
> Le vendredi, 5 avril 2013 17.52:19, Thomas Goirand a écrit :
>> On 04/05/2013 07:59 PM, Dmitrijs Ledkovs wrote:
>>> And all of these features will only land for the next cycle
>>> with a release in ~= 2 years time.
>> I really hope that it wont be the case. That it doesn't go into
>> Debian 7.0.0, I would understand, but at least, we need it
>> for a point release.
> Are you seriously arguing in favour of pushing a behavioural change into a 
> stable point release? I doubt the stable release team would accept that, but 
> I'm not under their hats.

I've wrote that we should at least address the issue, in a way
or another, through the next point release if that is safer.

But, are you seriously proposing that we leave the issue as-is ???

>> And at least, we need things written in the release notes about it, if not a
>> message in the installer itself (Christian, don't kill me... ;).
> I disagree. It has worked that way for a long time (and many releases in that 
> timeframe), so it is probably not "that" broken.

Well, at least *I* didn't know it was broken (yes, you read
well: BROKEN !!!), and I was quite shocked to read it, Knowing
that absolutely nothing gives you clues about it is equally
shocking. In fact, I saw that strange behaviors, and couldn't
explain it. We are talking about someone who has been using
Debian for 10 years. Now, think about someone who is a new comer...

> I'm not saying the bug isn't valid of course, just that it's severity is IMHO 
> correct.
>
>> Could we stop the winning and have this bug fixed please,
>> or the patch rejected (with a valid motivation)?
> Could we stop the useless bikeshedding and have Wheezy released please?

Sure. And let's add the fix for the next point release if
everyone think it's not a good idea to fix it right now
(though it's quite a shame we can't).
That's all I'm saying.

> As you know, d-i is critically low on manpower.

Yes, I know. And the patch author is also right to tell that
refusing contribution isn't a good idea to address this lack
of manpower.

As much as I don't agree with his tone, I do agree with
the arguments.

> You want that bug fixed? Great: test the patch, document your tests, upload 
> to 
> experimental with the patch, gather feedback, get involved, etc. For a fix to 
> land in Wheezy, this should have happened 8 months ago.

Do you believe the legend that d-i was frozen 8 months
ago? I don't... :D

(only half joking here...)

> Now is the time to 
> release Wheezy, not the time to add cosmetic and disruptive fixes to it.

I don't agree it is cosmetic. I'm not sure it's disruptive.

> (And 
> again, I think the changes are probably worthwhile, it's only the timing 
> which 
> is wrong.)
Then make your case for the next point release, not
for Jessie, please !

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/515f208a.7040...@debian.org

Re: failure to communicate

[Cyril Brulebois]

[ Not answering all occurrences, things got repeated a few times… ]

Thomas Goirand  (06/04/2013):
> I've wrote that we should at least address the issue, in a way or
> another, through the next point release if that is safer.

It is not.

> But, are you seriously proposing that we leave the issue as-is ???

For wheezy, certainly.

> Sure. And let's add the fix for the next point release if everyone
> think it's not a good idea to fix it right now (though it's quite a
> shame we can't).  That's all I'm saying.

Now is not the time, point releases are not the time. Next release
cycle is perfect for considering such requests.

> > Now is the time to release Wheezy, not the time to add cosmetic
> > and disruptive fixes to it.
> 
> I don't agree it is cosmetic. I'm not sure it's disruptive.

It is disruptive, and that's what matters right now for wheezy; that
means r0 but also later point releases.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: [PATCH] netplug - Allow to specify custom script file via param '-s'

[Pali Rohár]

On Wednesday 27 March 2013 12:41:03 Andrew Shadura wrote:
> Hello,
> 
> On Wed, 27 Mar 2013 12:08:20 +0100
> 
> Pali Rohár  wrote:
> > So is my patch totally ignored? I sent it to upstream
> > maintainer, next to debian mailinglist, attached to debian
> > bug tracking system, sent to ubuntu mailinglist and also to
> > launchpad ubuntu bug tracker. And nobody reviewed it until
> > now... So where should be patches sent for review and for
> > inclusion to system?
> 
> I contacted upstream few days ago on IRC; it seems he's rather
> busy now. I think you need to wait for a while :)

Hello again,
what happened after week? Will be my patch included? Or is 
netplug totally dead?

-- 
Pali Rohár
pali.ro...@gmail.com


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

Re: Bug#684128: failure to communicate

[Christian PERRIER]

Quoting Thomas Goirand (z...@debian.org):

> But, are you seriously proposing that we leave the issue as-is ???


Of course. The issue is there since partman exists (about 2005, from
memory) and has probably never prevented anyone to install Debian
since then. So, yes, this issue will still be in wheezy.

Hopefully, the issue will be fixed in jessie, though.




signature.asc
Description: Digital signature

Re: Git packaging workflow discussion on planet.d.o

[Thomas Goirand]

On 04/05/2013 06:57 PM, Guillem Jover wrote:
> On Thu, 2013-04-04 at 23:07:04 +0800, Thomas Goirand wrote:
>> gen-author-list:
>> git log --format='%aN <%aE>' | awk '{arr[$$0]++} END{for (i in
>> arr){print arr[i], i;}}' | sort -rn | cut -d' ' -f2-
> A better way to write the above could be:
>
> gen-author-list:
>   git shortlog -nes | tr -s ' '| cut -f2-
>
> which in addition will fix up the authors using any .mailmap rules.
>
> Thanks,
> Guillem
Though your version doesn't sort authors by the numbers of commits.

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/515f36a0.7000...@debian.org

Re: Git packaging workflow discussion on planet.d.o

[Andreas Tille]

Hi,

On Fri, Apr 05, 2013 at 10:21:58AM +0200, Tollef Fog Heen wrote:
> ]] Andreas Tille 
> 
> > Hmmm, you just show some more code as in your blog but this is not
> > addressing the three flaws of the workflow I was mentioning in my
> > initial mail.  I'm honestly wondering whether I'm missing something
> > and these are non-issues.
> 
> They seem to just be deficiencies in the tools, something that can be
> fixed easily enough with a few patches.

Even if this is the case I'd call the given recipes as "bad timing" as
long as those few patches are not yet written. 

Kind regards

Andreas.

-- 
http://fam-tille.de


-- 
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/20130405214520.gc13...@an3as.eu

Re: Git packaging workflow discussion on planet.d.o

[Guillem Jover]

On Sat, 2013-04-06 at 04:40:00 +0800, Thomas Goirand wrote:
> On 04/05/2013 06:57 PM, Guillem Jover wrote:
> > A better way to write the above could be:
> >
> > gen-author-list:
> > git shortlog -nes | tr -s ' '| cut -f2-
> >
> > which in addition will fix up the authors using any .mailmap rules.

> Though your version doesn't sort authors by the numbers of commits.

,---
usage: git shortlog [-n] [-s] [-e] [-w] [rev-opts] [--] [... ]

  [rev-opts] are documented in git-rev-list(1)

  -n, --numbered sort output according to the number of commits per author
  -s, --summary  Suppress commit descriptions, only provides commit count
  -e, --emailShow the email address of each author
  -w[]  Linewrap output
`---

Thanks,
Guillem


-- 
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/20130405233445.ga2...@gaara.hadrons.org

libc-bin

[carlos]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thanks for your time and job!
I've trying to use Chromiun latest trunk but its requires libc-bin >
2.15, even I use Debian Testing I do not have this package.
Is thought to have libc 2.17 on Debian testing soon?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlFfYgsACgkQogdBASUF5tUgzAD8DrCYPhP6rXAjGoQD8hUEDqJF
DCP+EXERaLCQzW1emM4A/jyWeRGRpJGD/EnSmqc+nsaOuo0MUD15sw1eBD9cIfrZ
=YJxT
-END PGP SIGNATURE-

Re: so long, and thanks for all the fish

[Aneurin Price]

On 4 April 2013 18:28,  wrote:

> There is apparently no mode of argument, or "style of
> communications", which is capable of penetrating the Debian
> bureaucracy. It is impervious, even to patches which have been
> previously solicited. Silly me, for taking that seriously.
>

You need to remember that the Debian project is essentially masturbation.
Nobody likes to be told they're doing it wrong.

Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)

[Dirk Eddelbuettel]

First off, let me apologize. I clearly did this the wrong way and should have
contacted -release and -devel beforehand. My bad -- I'm sorry for extra work
this created for the release managers and maintainer, particularly at this
time.

R 3.0.0 was released on April 3 as scheduled. As usual, I built a package the
morning of, and all build daemons are current. (There was also an unrelated
bug which is why were at 3.0.0-2.)  The release team kindly put a block on
it, so it will make it into testing.  Good.

Preceding the release and following it, we have rebuilt the vast number of
"r-cran-*" packages used my R, and which do need a rebuild, plus a few
building against R such as python-rpy.  Currently, in my unstable pbuilder
chroot (and thanks to Chris for the showpkg trick)

  root@max:/# apt-cache showpkg r-base-core | grep "r-base-core 3" | wc -l  
  127

So 127 packages are already taken care of.  On the other hand, we still have
~50 packages needing work:

  root@max:/# apt-cache showpkg r-base-core | grep "r-base-core 2" | wc -l  
   
52

A few of these are false positives though. Looking more closely via

   root@max:/# for p in `apt-cache showpkg r-base-core | grep "r-base-core 2" | 
sort | awk -F, '{print $1}'`; \
do echo -n "$p,"; apt-cache show $p | grep Maintainer | sed -e 
's/.*$//'; done

gets us a nice little csv data set we can print in R:

R> print(todo[ order(todo[,2]), ], row.names=FALSE)
   pkg  maint
r-bioc-biobase   debian-med-packag...@lists.alioth.debian.org
   r-bioc-biocgenerics   debian-med-packag...@lists.alioth.debian.org
 r-bioc-cummerbund   debian-med-packag...@lists.alioth.debian.org
  r-bioc-edger   debian-med-packag...@lists.alioth.debian.org
 r-bioc-hilbertvis   debian-med-packag...@lists.alioth.debian.org
  r-bioc-limma   debian-med-packag...@lists.alioth.debian.org
 r-bioc-qvalue   debian-med-packag...@lists.alioth.debian.org
   r-cran-combinat   debian-med-packag...@lists.alioth.debian.org
   r-cran-deal   debian-med-packag...@lists.alioth.debian.org
   r-cran-diagnosismed   debian-med-packag...@lists.alioth.debian.org
r-cran-epi   debian-med-packag...@lists.alioth.debian.org
   r-cran-epibasix   debian-med-packag...@lists.alioth.debian.org
r-cran-epicalc   debian-med-packag...@lists.alioth.debian.org
   r-cran-epir   debian-med-packag...@lists.alioth.debian.org
   r-cran-epitools   debian-med-packag...@lists.alioth.debian.org
r-cran-evd   debian-med-packag...@lists.alioth.debian.org
r-cran-genabel   debian-med-packag...@lists.alioth.debian.org
   r-cran-genetics   debian-med-packag...@lists.alioth.debian.org
r-cran-ggplot2   debian-med-packag...@lists.alioth.debian.org
r-cran-haplo.stats   debian-med-packag...@lists.alioth.debian.org
r-cran-psy   debian-med-packag...@lists.alioth.debian.org
r-cran-pvclust   debian-med-packag...@lists.alioth.debian.org
   r-cran-randomforest   debian-med-packag...@lists.alioth.debian.org
r-cran-reshape   debian-med-packag...@lists.alioth.debian.org
   r-cran-reshape2   debian-med-packag...@lists.alioth.debian.org
   r-cran-rocr   debian-med-packag...@lists.alioth.debian.org
r-cran-rsqlite   debian-med-packag...@lists.alioth.debian.org
r-cran-stringr   debian-med-packag...@lists.alioth.debian.org
  r-cran-vegan   debian-med-packag...@lists.alioth.debian.org
 r-other-bio3d   debian-med-packag...@lists.alioth.debian.org
r-other-mott-happy   debian-med-packag...@lists.alioth.debian.org
  r-cran-amore debian-science-maintain...@lists.alioth.debian.org
r-cran-msm debian-science-maintain...@lists.alioth.debian.org
r-cran-plotrix debian-science-maintain...@lists.alioth.debian.org
 r-cran-sp debian-science-maintain...@lists.alioth.debian.org
r-cran-spc debian-science-maintain...@lists.alioth.debian.org
  r-cran-teachingdemos debian-science-maintain...@lists.alioth.debian.org
r-cran-vcd debian-science-maintain...@lists.alioth.debian.org
 r-cran-xtable debian-science-maintain...@lists.alioth.debian.org
 r-cran-maldiquant debichem-de...@lists.alioth.debian.org
 r-cran-readbrukerflexdata debichem-de...@lists.alioth.debian.org
   littler e...@debian.org
  python-nwsserver e...@debian.org
   r-cran-gregmisc  

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

[Charles Plessy]

Le Sun, Mar 31, 2013 at 07:02:15PM -0400, Scott Kitterman a écrit :
> 
> Depends: r-base-core (>= 3.0.0~20130327) , r-base-core (<< 4) 
> 
> or you could have an API virtual package:
> 
> r-base-api-3.0 

Hi Dirk and everybody,

since we already have a substitution variable in most of the R packages
(R:Depends), I think that we can use it to address the problem.

First, let's define the problem: R broke backwards compatibility a couple of
times since it has been packaged.  Rebuilding packages is usually done swiftly,
but there remains the problem of transitions to Testing and updates on the
users computers.  There is usually a gap of some years between breakages,
so we do not want an over-engeneered solution.

I like the idea of an api virtual package, as it requires little work from the
parties involved and solves most of the problem.  (The exception being that
partial upgrades from Wheezy to Jessie will not be supported, but this is also
the case in the current situation).

 - /usr/share/R/debian/r-cran.mk, which is used in most R packages and produces
   the R:Depends substitution variable, would make packages depend on the r-api
   virtual package instead of requiring a version equal or superior to the 
version
   of r-base-core used at build time.

 - Next time R breaks backwards compatibility, Dirk would need to modify the
   Provides: line in debian/control and voilà, the new R core package can not
   be installed on a system without removing or upgrading the R library packages
   that were built with the old API.

Let's discuss the details on #704805

Have a nice week-end,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130406040849.gd22...@falafel.plessy.net

Bug#704810: ITP: spice-html5 -- Spice Web client which runs entirely within a modern browser

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: spice-html5
  Version : 0~
  Upstream Author : Aric Stewart 
* URL : http://www.spice-space.org/page/Html5
* License : GPL, LGPL
  Programming Lang: Javascript
  Description : Spice Web client which runs entirely within a modern browser

Spice Web client which runs entirely within a modern browser. It is limited
in function, a bit slow, and lacks support for many features of Spice
(audio, video, agents just to name a few).

The Simple Protocol for Independent Computing Environments (SPICE) is
a remote display system built for virtual environments which allows
you to view a computing 'desktop' environment not only on the machine
where it is running, but from anywhere on the Internet and from a wide
variety of machine architectures.


Note that this is a dependency for nova-spicehtml5proxy for the latest
Openstack 2013.1 release (code name Grizzly).


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