Communication issue? (was: Consciously blocking packages and development)

[David Prévot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Norbert,

Le 03/09/2013 02:10, Norbert Preining a écrit :

> Are you planning to block TeX Live transition for unforeseeable future?

Absolutely not, a fixed d-e-d package will be uploaded in due time. In
the mean time, if you’re in a hurry to see your package reach testing,
feel free to provide back the binary packages you removed (via
convenient dummy transitional packages) instead of breaking any third
party due to their uncoordinated disappearance.

Thanks in advance for considering.

> It is ridiculous that you not even care for *answering*

Apologies about that, it has never been anyone’s intention to ignore
this issue. On the contrary, we even staged a fix a few hours after
Ansgar filled this bug (thank you by the way for the bug and the hint):

http://anonscm.debian.org/gitweb/?p=debian-edu/debian-edu-doc.git;a=commitdiff;h=7bc2cb76d3369b457bd8c691bab2dbb9885b0708

Regards

David

P.-S.: transitional packages could be a way to document such disruptive
change, but a note in changelog would have been appreciated.


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

iQEcBAEBCAAGBQJSJYo/AAoJEAWMHPlE9r08JvwH/1hZLihgzo+Pzyqmd8oeRtgc
ur+TG1Ypkkv+u9RV5SrY5omXp7CAwE3owzlIcbDhRTFUfzqStQfEbUjV/kZeMKWl
YmhpD+VflFhPRES/Gs4gzZKp8Q17KCKPTh4EMCWMm/ftB5Cmdf7RsPsfCWx6cdK3
JbLIQsi3smm9cCodYvvla+Sr2jvInMA40UL8xB5oFmE7znWIIfL+KEaow+yCj/4P
ofMIQFQrPJLMI37BWakGZbX25muWYPvd1/hmezbG0AoIENF9FoQytoa4hEDVN27v
FjSR+ipjgxjjap25aQm2lMzqxUEIa1QUdThr1CGokiPCGy5F1z0QgVY8D+PReaQ=
=sMfd
-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/52258a41.3070...@debian.org

Re: Communication issue? (was: Consciously blocking packages and development)

[Norbert Preining]

Hi David,

On Di, 03 Sep 2013, David Prévot wrote:
> Absolutely not, a fixed d-e-d package will be uploaded in due time. In
> the mean time, if you’re in a hurry to see your package reach testing,
> feel free to provide back the binary packages you removed (via
> convenient dummy transitional packages) instead of breaking any third
> party due to their uncoordinated disappearance.

Umpf, uncoordinated disappearance. Might I remind you that
we are talking about build-deps, and that there is *no* rdepends
on texlive-lang-danish. Do you expect to add transitional packages
for *one* (I did not check, maybe 5?) package that needs t-l-d 
as build-depends?

I did not break any package, I just created FTBFS for *one* package,
a very common *very* common case here in Debian. (Uh, just recently
several of my packages started to FTBFS due to perl 5.18).

Yes, devs can take there time to consider it, but letting rot away
the bug without answer ...

Anyway, let us hope that your "in due time" will be at some
reasonable time.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094



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

Re: Nitpicking in the NEW queue.

[Charles Plessy]

(Long answer, but I promise to limit my messages in this thread).

Le Mon, Sep 02, 2013 at 01:08:12PM -0400, Paul Tagliamonte a écrit :
> 
> Yes. For the record, this day when Charles sent this mail, I was working
> in NEW from early in the morning to about 9:00 at night. I don't want
> thanks or even for people to care about such things, but to come home
> from the bar to such an email is annoying and makes me want to review
> NEW less.

Hi Paul,

first of all, please let me clarify that the reason why I answered on our core
mailing list is not to fingerpoint if or not you are wrong, but becase this is
the only way I have to see if others agree to my opinion that comments that are
not critical to the suitability of a package for our archive should be left
out.  I also thank Andreas for his balanced proposition.

Your involvement is very appreciated, but isn't what you wrote above an
indication that something is going wrong ?  Backlogs and long days lead to
burnout, and experience shows that positive enthousiasm can also fuel burnouts.
If there is so much work to do to keep our archive compliant with the law and
our priciples on Free software, please let me suggest to defer other checks to
other teams and automated systems.  It does not mean that that your help or
vision is not wanted or useful, it means that when a task reaches a given size,
it needs to be undertaken with a more systematic approach.

In particular, what I am complaining about (and I understand that complaining
correctly is a difficult art in which I am not the most skilled) is clearly the
result of the recurrent backlogs in the NEW queue and the shortage of time that
can be spend on a package.  You asked me if the scripts I packaged could not be
part of another package, but the very first message of the ITP bug clearly
showes that I already explored that possibility.  Given that we need to wait
for weeks to ensure that people had enough time to anwer, it took me months !
Also, the machine-readable Debian copyright file had a bug, which I again
apologise for, but on the other hand, it contained each and every copyright
statement that needed to be reproduced.

What I am asking for is a predictable system.  If ITP bugs will not be read,
just document that fact proeminently somewhere, and if possible provide a
workaround (like adding a temporary message in README.source ?).  If a question
is recurrent, having an entry in a checklist would be much appreciated.  In
that case it could be: "For a native package containing less than X files, you
must explain your reasons in the file debian/README.foo)".  Same for the
files that, like OpenOffice documents, are in binary format, but in a format
that is not as well recognised.

Given that the NEW queue is often processed by batches, discussion about
rejections tend to stop by loss of momentum, without solving the issues raised.
For that reason, and to ensure predictability, I think that it is very
important to have at least a clear separation between the blocking issues and
the personal comments.  In the case of pv-grub-menu, I am left with the
questions "What else shall I do that I have not tried yet ?  How many weeks or
monthes shall I try before giving up", which will waste time on your side and
mine.

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/20130903084352.gd19...@falafel.plessy.net

Looking for ideas for merging a micro package... (was: Nitpicking in the NEW queue.)

[Vincent Danjean]

Le 02/09/2013 06:12, Paul R. Tagliamonte a écrit :
> Respectfully - when we add micro (under Size 100 packages) the amount of 
> metadata added to every mirror and every users machine is almost as much as 
> the package contents.
> 
> This is a very common request (make sure this really needs to be split out ) 
> and not even the reason for this reject.

My new pagemap package have recently been rejected being a small package.
Indeed, it is a small script, wrote in ruby, that use /proc//pagemap
binary files (and a few other from /sys) and display in text the
mapping between physical and virtual memory.
  When working on NUMA system, it can sometimes be a useful tool
to analyze the performances of HPC programs.

  Never mind. My current problem is that I have no idea which current
package to contact to ask for a inclusion. It is not important enough
to be included in packages such as util-linux and few (no?) system/devel
packages already have a dependency on ruby (ie adding the pagemap script
would add a dependency on ruby).
  Any idea?

  Regards,
Vincent

sources:
dget 
http://people.debian.org/~vdanjean/debian/pool/main/p/pagemap/pagemap_1.1-3.dsc
binary:
http://people.debian.org/~vdanjean/debian/pool/main/p/pagemap/pagemap_1.1-3_all.deb

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/5225a308.2080...@free.fr

Re: Consciously blocking packages and development

[Holger Levsen]

Dear Norbert,

I stopped reading after reading the subject.
Not sure if you get why, oh, my.
I'll give you a little hint:
always assume the worst,
spread the word,
and for maximum impact, 
put names in subject too.
This really really helps and is super joyful.


cheers,
Holger


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

Re: Nitpicking in the NEW queue.

[Paul Wise]

Reading Charles' mail I had a thought; how about accepting buggy
packages (unless the issues make them non-distributable) and file RC
and other bugs if there are DFSG or other issues?

-- 
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/caktje6h+flbo4vrq4fe4sh4ct3qs-yjtowtwwg9hdy6def8...@mail.gmail.com

Bug#721705: ITP: python-misaka -- binding for Sundown, a markdown parsing library

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-misaka
  Version : 1.0.2
  Upstream Author : Frank Smit
* URL : http://misaka.61924.nl/
* License : MIT
  Programming Lang: Python
  Description : binding for Sundown, a markdown parsing library

A Python 2 and 3 binding for Sundown, a really fast Markdown parser
implemented in C. Misaka is written in Cython and C. And it features a set
of Markdown extensions and customizable renderers. Just like the Sundown
binding for Ruby, Redcarpet.


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

Re: Looking for ideas for merging a micro package... (was: Nitpicking in the NEW queue.)

[Paul Wise]

On Tue, Sep 3, 2013 at 10:51 AM, Vincent Danjean wrote:

>   Never mind. My current problem is that I have no idea which current
> package to contact to ask for a inclusion. It is not important enough
> to be included in packages such as util-linux and few (no?) system/devel
> packages already have a dependency on ruby (ie adding the pagemap script
> would add a dependency on ruby).

I would suggest inclusion in util-linux is the way forward, possibly
with a rewrite in C or whatever languages are accepted in util-linux.

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

Re: Nitpicking in the NEW queue.

[Luca Falavigna]

2013/9/3 Paul Wise :
> Reading Charles' mail I had a thought; how about accepting buggy
> packages (unless the issues make them non-distributable) and file RC
> and other bugs if there are DFSG or other issues?

Although this could be possible, a second upload would be needed
anyway (hopefully in a very short timeframe), so reuploading a fixed
package to NEW would avoid wasting bandwith and disk space on mirrors
and snapshot.d.o.

Usually, rejected packages are fast-tracked when reuploaded to avoid
letting them slip at the bottom of the queue. Simply reply to
rejection mail (or ping us in IRC) informing us a fixed package has
been reuploaded to the NEW queue.


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

Bug#721708: ITP: python-steadymark -- markdown-based test runner

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-steadymark
  Version : 0.4.5
  Upstream Author : Gabriel Falcao 
* URL : https://github.com/gabrielfalcao/steadymark
* License : MIT
  Programming Lang: Python
  Description : markdown-based test runner

 Write your documentation using github-flavored markdown, surround your
 snippets with python code blocks and steadymark will automatically find and
 run them, if there is a header preceeding your python snippet it will be used
 as title for your test.


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

Bug#721710: ITP: python-sure -- utility belt for automated testing for python

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-sure
  Version : 1.2.2
  Upstream Author : Gabriel Falcao 
* URL : https://github.com/gabrielfalcao/sure
* License : GPL-3
  Programming Lang: Python
  Description : utility belt for automated testing for python

 Sure is a python library for python that leverages a DSL for writing
 assertions. In CPython it monkey-patches the object type, adding some methods
 and properties purely for test purposes. Any python code writen after "import
 sure" gains testing superpowers.


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

Re: Bits from the Release

[Stefano Zacchiroli]

On Sun, Aug 25, 2013 at 05:09:22PM +0200, Niels Thykier wrote:
> How you can help (NEW-TEST-HELP)
> 
> 
> Add tests to your packages.  The full specification for these tests
> are available from [AUTOPKG].  If you need inspiration, consider looking
> at some of the existing autopkgtests[FIND-AUTOPKG].
> 
> We need to have the autopkgtest tests run.  Holger Levsen suggested
> that jenkins.debian.net has the necessary hardware to support these
> tests.
> 
> Asheesh Laroia has kindly spent some time during DebConf13 researching
> and experimenting with setting up such jobs.

So, in the context of work to periodically run various sorts of static
analysis tests on Debian packages [1], we (myself, Sylvestre Ledru, Léo
Cavaillé, and Matthieu Caneill) have considered using Jenkins.  Based on
feedback from Matthias Klumpp and his experience in using Jenkins for
Tanglu, we have concluded that it didn't really scale to the point that
we needed (number of Debian packages * number of checkers). We ended up
using Paul Tagliamonte's debile infrastructure [2].

I don't doubt that jenkins.d.n can be leveraged for the time being,
giving the low amount of autopkgtests currently available. But you might
want to check with Matthias or similar experiences before committing to
using Jenkins for this.


Apart from this, hopefully useful feedback: kudos for these saucy bits
from the Release Team :-) Keep up the good work!


Cheers.

[1]: preliminary, not necessarily up to date, results are available at
 http://firewoes.debian.net/ for those who are interested
[2]: http://debile.debian.net/
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Looking for ideas for merging a micro package...

[Vincent Danjean]

Le 03/09/2013 11:52, Paul Wise a écrit :
> On Tue, Sep 3, 2013 at 10:51 AM, Vincent Danjean wrote:
> 
>>   Never mind. My current problem is that I have no idea which current
>> package to contact to ask for a inclusion. It is not important enough
>> to be included in packages such as util-linux and few (no?) system/devel
>> packages already have a dependency on ruby (ie adding the pagemap script
>> would add a dependency on ruby).
> 
> I would suggest inclusion in util-linux is the way forward, possibly
> with a rewrite in C or whatever languages are accepted in util-linux.

The rewrite in C will wait for a volunteer (it is not easy/convenient
to handle strings and it becomes a lot more difficult to improve/
maintain)
  For a rewrite in another script language (perl ? python ?), as the
primary author (Brice Videau) likes ruby a lot, I think it will also
have to wait for a volunteer. Note that it is not really difficult.
But it takes time, the current program "works" and it is not "fun"
for upstream author.

  So, I'm looking for a package that would accept this ruby script
(I will probably ask linux-util anyway if nobody has other suggestions)
and I will keep it in my perso repository until then.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/5225d6a7.3000...@free.fr

Re: Nitpicking in the NEW queue.

[Steve McIntyre]

Paul Wise wrote:
>Reading Charles' mail I had a thought; how about accepting buggy
>packages (unless the issues make them non-distributable) and file RC
>and other bugs if there are DFSG or other issues?

Why should we rush to let more broken stuff into the archive?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/


-- 
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/e1vgq3g-0007aw...@mail.einval.com

Re: Looking for ideas for merging a micro package...

[Paul Tagliamonte]

On Tue, Sep 03, 2013 at 02:31:35PM +0200, Vincent Danjean wrote:
> Le 03/09/2013 11:52, Paul Wise a écrit :
> > On Tue, Sep 3, 2013 at 10:51 AM, Vincent Danjean wrote:
> > 
> >>   Never mind. My current problem is that I have no idea which current
> >> package to contact to ask for a inclusion. It is not important enough
> >> to be included in packages such as util-linux and few (no?) system/devel
> >> packages already have a dependency on ruby (ie adding the pagemap script
> >> would add a dependency on ruby).
> > 
> > I would suggest inclusion in util-linux is the way forward, possibly
> > with a rewrite in C or whatever languages are accepted in util-linux.
> 
> The rewrite in C will wait for a volunteer (it is not easy/convenient
> to handle strings and it becomes a lot more difficult to improve/
> maintain)
>   For a rewrite in another script language (perl ? python ?), as the
> primary author (Brice Videau) likes ruby a lot, I think it will also
> have to wait for a volunteer. Note that it is not really difficult.
> But it takes time, the current program "works" and it is not "fun"
> for upstream author.
> 
>   So, I'm looking for a package that would accept this ruby script
> (I will probably ask linux-util anyway if nobody has other suggestions)
> and I will keep it in my perso repository until then.

Don't kill yourself over this, if there's really nothing else that makes
sense, you can just say that and re-dput :)

We just want to ensure that the tradeoff is worth it, and needed :)

> 
>   Regards,
> Vincent


Cheers,
  Paul

> 
> -- 
> Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
> GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
> Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
> APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main
> 
> > -- > 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/5225d6a7.3000...@free.fr
> 

-- 
 .''`.  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

Bug#721715: ITP: python-couleur -- tool to play around with ANSI features in a unix terminal

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-couleur
  Version : 0.5.0
  Upstream Author : Gabriel Falcão 
* URL : https://github.com/gabrielfalcao/couleur
* License : Apache-2.0
  Programming Lang: Python
  Description : tool to play around with ANSI features in a unix terminal

 Couleur is an ANSI terminal tool for python, colored shell and other handy
 fancy features. With couleur you can mix modifiers and colors. Couleur is made
 of a single python file and comes with syntax sugar.


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

Re: Nitpicking in the NEW queue.

[Paul Tagliamonte]

Hey Charles,

On Tue, Sep 03, 2013 at 05:43:52PM +0900, Charles Plessy wrote:
> Hi Paul,
> 
> first of all, please let me clarify that the reason why I answered on our core
> mailing list is not to fingerpoint if or not you are wrong, but becase this is
> the only way I have to see if others agree to my opinion that comments that 
> are
> not critical to the suitability of a package for our archive should be left
> out.  I also thank Andreas for his balanced proposition.
> 
> Your involvement is very appreciated, but isn't what you wrote above an

Thank you.

> indication that something is going wrong ?  Backlogs and long days lead to
> burnout, and experience shows that positive enthousiasm can also fuel 
> burnouts.

This is true. I've burned out (and seen my friends) of Ubuntu work quite a
few times, I'm sadly aware of the problem.

> If there is so much work to do to keep our archive compliant with the law and
> our priciples on Free software, please let me suggest to defer other checks to
> other teams and automated systems.  It does not mean that that your help or

See, this is an interesting proposal. The issue is we *do* have a system
for doing this -- Lintian autorejects. If something is really this easy
to detect with automated systems, it should be added to Lintian, and set
as an autoreject tag.

The problem is, figuring out what the prefered form of modification is
is a hard problem, and needs a human judgement call. A lot of this stuff
is a grey area, so a human making the decision means that there's at
least a sound Debian-ish argument behind the decision (that perhaps is
in line with the *spirit* of the Project)

In addition the DFSG are a set of Guidelines (see the G), so appling
judgement to what is or isn't DFSG free is also something we need a
human to decide.

So, yes. It would be nice to get robot overloads to do this work.
However, I'm not sure *I* (personally) would like such cold
black-and-white logic behind something that's a bit of a grey area.

> vision is not wanted or useful, it means that when a task reaches a given 
> size,
> it needs to be undertaken with a more systematic approach.
> 
> In particular, what I am complaining about (and I understand that complaining
> correctly is a difficult art in which I am not the most skilled) is clearly 
> the
> result of the recurrent backlogs in the NEW queue and the shortage of time 
> that
> can be spend on a package.  You asked me if the scripts I packaged could not 
> be
> part of another package, but the very first message of the ITP bug clearly
> showes that I already explored that possibility.  Given that we need to wait

So, we have two fun issues here -- I both nitpick and don't research
enough :)

The issue is that I'm not going to go and make sure you're closing all
the right bugs and your diff is as clean as it should be -- that's not
my job. I'm not going to pull up every ITP, because I assume the
research for which ITP to be closed was done.

> for weeks to ensure that people had enough time to anwer, it took me months !
> Also, the machine-readable Debian copyright file had a bug, which I again
> apologise for, but on the other hand, it contained each and every copyright
> statement that needed to be reproduced.
> 
> What I am asking for is a predictable system.  If ITP bugs will not be read,
> just document that fact proeminently somewhere, and if possible provide a
> workaround (like adding a temporary message in README.source ?).  If a 
> question

README.Source would surely get my attention (as would README.Debian).

> is recurrent, having an entry in a checklist would be much appreciated.  In
> that case it could be: "For a native package containing less than X files, you
> must explain your reasons in the file debian/README.foo)".  Same for the
> files that, like OpenOffice documents, are in binary format, but in a format
> that is not as well recognised.

I don't REJECT micro packages for fun, I just want to make sure that the
maintainer has done their homework, and understands the tradeoffs
in adding such a package for our users and mirrors.

If you'll notice, I asked a question, not a statement. If there's a
reason why (as you say wrote in the ITP (I've still not opened it yet)),
you could have replied with that.

No one here is trying to "Keep the masses down" :)

> Given that the NEW queue is often processed by batches, discussion about
> rejections tend to stop by loss of momentum, without solving the issues 
> raised.
> For that reason, and to ensure predictability, I think that it is very
> important to have at least a clear separation between the blocking issues and
> the personal comments.  In the case of pv-grub-menu, I am left with the
> questions "What else shall I do that I have not tried yet ?  How many weeks or
> monthes shall I try before giving up", which will waste time on your side and
> mine.

You know, you can reply to ftpmaster@ about the REJECT to *ask*
about such things.

We're usually frie

Re: Nitpicking in the NEW queue.

[Raphael Hertzog]

On Tue, 03 Sep 2013, Luca Falavigna wrote:
> 2013/9/3 Paul Wise :
> > Reading Charles' mail I had a thought; how about accepting buggy
> > packages (unless the issues make them non-distributable) and file RC
> > and other bugs if there are DFSG or other issues?
> 
> Although this could be possible, a second upload would be needed
> anyway (hopefully in a very short timeframe), so reuploading a fixed
> package to NEW would avoid wasting bandwith and disk space on mirrors
> and snapshot.d.o.
> 
> Usually, rejected packages are fast-tracked when reuploaded to avoid
> letting them slip at the bottom of the queue. Simply reply to
> rejection mail (or ping us in IRC) informing us a fixed package has
> been reuploaded to the NEW queue.

This is not a good trade off. You're loosing out valuable ftpmasters time
for minor bandwith and disk issues (that kind of supplementary upload will
not change much in the global amount of bandwith and disk consumed).

I find pabs's idea rather good. And if you really care about a second check,
you can do that once you get the bug closure notification.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
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/20130903134756.gd30...@x230-buxy.home.ouaza.com

Re: Consciously blocking packages and development

[Norbert Preining]

On Di, 03 Sep 2013, Holger Levsen wrote:
> I stopped reading after reading the subject.

Thanks for the helpful comment instead of fixing things.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094



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

Bug#721730: ITP: libpg-hstore-perl -- Perl module for working with PostgreSQLs HSTORE data type

[Sebastiaan Couwenberg]

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

* Package name: libpg-hstore-perl
  Version : 1.03
  Upstream Author : Galimov Albert 
* URL : http://search.cpan.org/dist/Pg-hstore/
* License : Beerware
  Programming Lang: Perl
  Description : Perl module for working with PostgreSQLs HSTORE data
type

Decodes and encodes PostgreSQLs HSTORE data type into/from Perl hash refs.

This module was previously known as DBD::Pg::hstore, but has been
renamed to Pg::hstore because it's not DBD specific.

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)


-- 
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/5225fa94.3040...@xs4all.nl

Re: Nitpicking in the NEW queue.

[Gergely Nagy]

Raphael Hertzog  writes:

> On Tue, 03 Sep 2013, Luca Falavigna wrote:
>> 2013/9/3 Paul Wise :
>> > Reading Charles' mail I had a thought; how about accepting buggy
>> > packages (unless the issues make them non-distributable) and file RC
>> > and other bugs if there are DFSG or other issues?
>> 
>> Although this could be possible, a second upload would be needed
>> anyway (hopefully in a very short timeframe), so reuploading a fixed
>> package to NEW would avoid wasting bandwith and disk space on mirrors
>> and snapshot.d.o.
>> 
>> Usually, rejected packages are fast-tracked when reuploaded to avoid
>> letting them slip at the bottom of the queue. Simply reply to
>> rejection mail (or ping us in IRC) informing us a fixed package has
>> been reuploaded to the NEW queue.
>
> This is not a good trade off. You're loosing out valuable ftpmasters time
> for minor bandwith and disk issues (that kind of supplementary upload will
> not change much in the global amount of bandwith and disk consumed).
>
> I find pabs's idea rather good. And if you really care about a second check,
> you can do that once you get the bug closure notification.

I disagree. A second review by the same ftpmaster is usually fast and
painless and requires less time and effort overall than doing the bug
handling dance. I've done both, and my experience so far was that
REJECT+reupload worked much better in most cases.

That it also keeps the archive a tinsy bit cleaner is just an added
bonus.

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

lib/libgsl.so: undefined reference to `cblas_ztrsv' (on Ubuntus)

[Yaroslav Halchenko]

Hi Everyone,

Though it is actually not a Debian specific question (since on pure
Debian builts/links fine), I hope to find help and wisdom here.  

We (neurodebian) have a package for AFNI which we have been cooking for a
while... with a recent change to force -Wl,--no-undefined I got into a weird
linking issue which happens only on Ubuntu boxes (11.10 and up) while building
fine on Debian.  In the gcc call where linking '-lgsl -lgslcblas' fails
for no obvious for me reason -- order of libraries inclusion is fine, symbols
are there (even found/reported by ld) but still then reported not found. What
could be the reason?

The only obvious difference from Debian builds is addition of
-Wl,-Bsymbolic-functions for linking calls but even if I remove it for this
specific call -- nothing changes (although may be it is an effect of gsl being
built with it?)

See below what I am talking about and please find complete logs at
http://neuro.debian.net/_files/_buildlogs/afni/0.20130830~dfsg.1

so here it is -- gslcblas has the definitions, I do have -lgsl
-lgslcblas, according to strace gslcblas is read at least -- but references are
still undefined:

~/afni-0.20130830~dfsg.1/build-x86_64-linux-gnu/avovk# nm -D 
/usr/lib/libgslcblas.so | grep cblas_dgemv  ea00 T cblas_dgemv

~/afni-0.20130830~dfsg.1/build-x86_64-linux-gnu/avovk# gcc  --param 
ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wno-unused  
-fopenmp -DUSE_OMP  -Wl,-z,now -Wl,-z,relro -Wl,--no-undefined
CMakeFiles/3dkmeans.dir/3dkmeans.c.o 
CMakeFiles/3dkmeans.dir/cluster_floatNOMASK.c.o 
CMakeFiles/3dkmeans.dir/thd_segtools_fNM.c.o  -o 3dkmeans
../libmri.so ../libmrix.so ../coxplot/libcoxplot.so libsegtools.so -lSM -lICE 
-lX11 -lXext -lXm -lXmHTML ../libmri.so -lvolpack -lnetcdf -lXt -lf2c
-lgiftiio -lnifticdf -lniftiio -lz -lnifticdf -lniftiio -lz -lgsl  -lgslcblas 
-lm
-Wl,-rpath,"/tmp/buildd/afni-0.20130830~dfsg.1/build-x86_64-linux-gnu:/tmp/buildd/afni-0.20130830~dfsg.1/build-x86_64-linux-gnu/coxplot:/tmp/buildd/a
fni-0.20130830~dfsg.1/build-x86_64-linux-gnu/avovk:" -DNDEBUG
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libgsl.so: undefined 
reference to `cblas_ztrsv'
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libgsl.so: undefined 
reference to `cblas_scasum'
...

and here you can see that ld finds the definition but then reports that it is
undefined in libgsl.so (which is factually true but I thought it would use the
one from libgslcblas by then).

~/afni-0.20130830~dfsg.1/build-x86_64-linux-gnu/avovk# /usr/bin/ld --verbose -t 
-y cblas_ztrsv --sysroot=/ --build-id --no-add-needed --as-needed 
--eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker 
/lib64/ld-linux-x86-64.so.2 -z relro -o 3dkmeans 
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crt1.o 
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crti.o 
/usr/lib/gcc/x86_64-linux-gnu/4.7/crtbegin.o 
-L/usr/lib/gcc/x86_64-linux-gnu/4.7 
-L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu 
-L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib -L/lib/x86_64-linux-gnu 
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib 
-L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../.. -z now -z relro --no-undefined 
CMakeFiles/3dkmeans.dir/3dkmeans.c.o 
CMakeFiles/3dkmeans.dir/cluster_floatNOMASK.c.o 
CMakeFiles/3dkmeans.dir/thd_segtools_fNM.c.o ../libmri.so ../libmrix.so 
../coxplot/libcoxplot.so libsegtools.so -lSM -lICE -lX11 -lXext -lXm -lXmHTML 
../libmri.so -lvolpack -lnetcdf -lXt -lf2c -lgiftiio -lnifticdf -lniftiio -lz 
-lnifticdf -lniftiio -lz -lgsl -lgslcblas -lm -rpath 
/tmp/buildd/afni-0.20130830~dfsg.1/build-x86_64-linux-gnu:/tmp/buildd/afni-0.20130830~dfsg.1/build-x86_64-linux-gnu/coxplot:/tmp/buildd/afni-0.20130830~dfsg.1/build-x86_64-linux-gnu/avovk:
  -lgomp -lgcc --as-needed -lgcc_s  -lpthread -lc -lgcc  -lgcc_s 
/usr/lib/gcc/x86_64-linux-gnu/4.7/crtend.o 
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crtn.o 2>&1  | grep 
-e 'gsl' -e 'cblas_ztrsv' | head -20
...
attempt to open /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libgsl.so 
succeeded
-lgsl (/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libgsl.so)
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libgsl.so: reference to 
cblas_ztrsv
...
attempt to open 
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libgslcblas.so succeeded
-lgslcblas (/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libgslcblas.so)
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libgslcblas.so: definition of 
cblas_ztrsv
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libgsl.so: undefined 
reference to `cblas_ztrsv'
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libgsl.so: undefined 
reference to `cblas_scasum'
.

probably needless to say that adding -lcblas works around this issue.

Thanks in advance for the hints!
-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http:

Bug#721731: ITP: camo -- SSL image proxy to prevent mixed-content warnings

[Luke Faraone]

Package: wnpp
Severity: wishlist
Owner: Luke Faraone 

* Package name: camo
  Version : 1.1.1
  Upstream Author : Rick Olson and Cory Donohoe
* URL : https://github.com/atmos/camo
* License : Expat
  Programming Lang: JavaScript (nodejs)
  Description : SSL image proxy to prevent mixed-content warnings

Camo is all about making insecure assets look secure. This is an SSL
image proxy to prevent mixed content warnings on secure pages.

Using a shared key, proxy URLs are encrypted with hmac so we can bust
caches/ban/rate limit if needed.

Features include:
* Proxy Google charts
* Proxy images under 5 MB
* Follow redirects to a configurable depth
* Proxy remote images with a content-type of image/*
* Disallows proxying to private IP ranges


-- 
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/20130903160256.18529.9753.report...@cobalt.mit.edu

Re: lib/libgsl.so: undefined reference to `cblas_ztrsv' (on Ubuntus)

[Andrey Rahmatullin]

On Tue, Sep 03, 2013 at 11:42:32AM -0400, Yaroslav Halchenko wrote:
> ~/afni-0.20130830~dfsg.1/build-x86_64-linux-gnu/avovk# gcc  --param 
> ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security -g -O2 
> -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wno-unused  
> -fopenmp -DUSE_OMP  -Wl,-z,now -Wl,-z,relro -Wl,--no-undefined
> CMakeFiles/3dkmeans.dir/3dkmeans.c.o 
> CMakeFiles/3dkmeans.dir/cluster_floatNOMASK.c.o 
> CMakeFiles/3dkmeans.dir/thd_segtools_fNM.c.o  -o 3dkmeans
> ../libmri.so ../libmrix.so ../coxplot/libcoxplot.so libsegtools.so -lSM -lICE 
> -lX11 -lXext -lXm -lXmHTML ../libmri.so -lvolpack -lnetcdf -lXt -lf2c
> -lgiftiio -lnifticdf -lniftiio -lz -lnifticdf -lniftiio -lz -lgsl  -lgslcblas 
> -lm
> -Wl,-rpath,"/tmp/buildd/afni-0.20130830~dfsg.1/build-x86_64-linux-gnu:/tmp/buildd/afni-0.20130830~dfsg.1/build-x86_64-linux-gnu/coxplot:/tmp/buildd/a
> fni-0.20130830~dfsg.1/build-x86_64-linux-gnu/avovk:" -DNDEBUG
> /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libgsl.so: undefined 
> reference to `cblas_ztrsv'
> /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libgsl.so: undefined 
> reference to `cblas_scasum'
If you ship a public library with undefined symbols it is not just simply
wrong, it's also a violation of a Policy "must" (10.2) and hence an RC
bug. In any case, please don't. It's 2013 already.

> and here you can see that ld finds the definition but then reports that it is
> undefined in libgsl.so (which is factually true but I thought it would use the
> one from libgslcblas by then).
You can't link in shared libs with undefined symbols when using
--as-needed which is default on Ubuntu (well, sometimes you probably can
but not in this case).


-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: lib/libgsl.so: undefined reference to `cblas_ztrsv' (on Ubuntus)

[Yaroslav Halchenko]

On Tue, 03 Sep 2013, Andrey Rahmatullin wrote:
> > ~/afni-0.20130830~dfsg.1/build-x86_64-linux-gnu/avovk# gcc  --param 
> > ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security -g -O2 
> > -fstack-protector
> > --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wno-unused  
> > -fopenmp -DUSE_OMP  -Wl,-z,now -Wl,-z,relro -Wl,--no-undefined
> > CMakeFiles/3dkmeans.dir/3dkmeans.c.o 
> > CMakeFiles/3dkmeans.dir/cluster_floatNOMASK.c.o 
> > CMakeFiles/3dkmeans.dir/thd_segtools_fNM.c.o  -o 3dkmeans
> > ../libmri.so ../libmrix.so ../coxplot/libcoxplot.so libsegtools.so -lSM 
> > -lICE -lX11 -lXext -lXm -lXmHTML ../libmri.so -lvolpack -lnetcdf -lXt -lf2c
> > -lgiftiio -lnifticdf -lniftiio -lz -lnifticdf -lniftiio -lz -lgsl  
> > -lgslcblas -lm
> > -Wl,-rpath,"/tmp/buildd/afni-0.20130830~dfsg.1/build-x86_64-linux-gnu:/tmp/buildd/afni-0.20130830~dfsg.1/build-x86_64-linux-gnu/coxplot:/tmp/buildd/a
> > fni-0.20130830~dfsg.1/build-x86_64-linux-gnu/avovk:" -DNDEBUG
> > /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libgsl.so: undefined 
> > reference to `cblas_ztrsv'
> > /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libgsl.so: undefined 
> > reference to `cblas_scasum'
> If you ship a public library with undefined symbols it is not just simply
> wrong, it's also a violation of a Policy "must" (10.2) and hence an RC
> bug. In any case, please don't. It's 2013 already.

Well -- I am not shipping any public library here... so I guess I am
reading your comment as pertinent to libgsl which should have been
linked against libgslcblas?

btw - even on Debian systems it is not:
$> ldd /usr/lib/libgsl.so 
linux-vdso.so.1 (0x7fff5fddb000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f558ccc9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f558c91d000)
/lib64/ld-linux-x86-64.so.2 (0x7f558d483000)

but I am not sure here if that is not intentional to allow "flexibility" to
decide to link against a specific blas implementation (gsl's or
system-wide)...

> > and here you can see that ld finds the definition but then reports that it 
> > is
> > undefined in libgsl.so (which is factually true but I thought it would use 
> > the
> > one from libgslcblas by then).
> You can't link in shared libs with undefined symbols when using
> --as-needed which is default on Ubuntu (well, sometimes you probably can
> but not in this case).

ha -- I thought I have checked for that but I guess I have not removed all
--as-needed from that call.  If I remove all of them from  ld call -- links
fine! Adding -Wl,--no-as-needed to gcc call seems to resolve this issue --
thanks!

So I guess -Wl,--no-as-needed is needed for any linking against gsl, gslcblas
libraries ATM on Ubuntus.

Cheers,
-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate, Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


-- 
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/20130903162150.gq27...@onerussian.com

Re: lib/libgsl.so: undefined reference to `cblas_ztrsv' (on Ubuntus)

[Andrey Rahmatullin]

On Tue, Sep 03, 2013 at 12:21:50PM -0400, Yaroslav Halchenko wrote:
> > > /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libgsl.so: undefined 
> > > reference to `cblas_ztrsv'
> > > /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libgsl.so: undefined 
> > > reference to `cblas_scasum'
> > If you ship a public library with undefined symbols it is not just simply
> > wrong, it's also a violation of a Policy "must" (10.2) and hence an RC
> > bug. In any case, please don't. It's 2013 already.
> 
> Well -- I am not shipping any public library here... so I guess I am
> reading your comment as pertinent to libgsl which should have been
> linked against libgslcblas?
Correct.

> btw - even on Debian systems it is not:
> $> ldd /usr/lib/libgsl.so 
> linux-vdso.so.1 (0x7fff5fddb000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f558ccc9000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f558c91d000)
> /lib64/ld-linux-x86-64.so.2 (0x7f558d483000)
> 
> but I am not sure here if that is not intentional to allow "flexibility" to
> decide to link against a specific blas implementation (gsl's or
> system-wide)...
If that was intentional then you as an user of the library should be
prepared to any kinds of problems.

> So I guess -Wl,--no-as-needed is needed for any linking against gsl, gslcblas
> libraries ATM on Ubuntus.
Note that --as-needed it's not Ubuntu-specific (even as a default).

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Bug#721731: ITP: camo -- SSL image proxy to prevent mixed-content warnings

[Paul Wise]

On Tue, Sep 3, 2013 at 6:02 PM, Luke Faraone wrote:

> Camo is all about making insecure assets look secure. This is an SSL
> image proxy to prevent mixed content warnings on secure pages.

Is distributing software that pretends it is secure a good idea?

-- 
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/caktje6ez3xlndvphmiy9btqrzv8k-q27+fmo+pbch7pgvq3...@mail.gmail.com

Re: Bug#721731: ITP: camo -- SSL image proxy to prevent mixed-content warnings

[Paul Wise]

On Tue, 2013-09-03 at 13:02 -0400, Luke Faraone wrote:

> This provides integrity protection and last-mile confidentiality to
> images, thus preventing a local network attacker from seeing the images
> you request (allowing for possible disclosure of the content you're
> viewing) or changing their content (to misinform, confuse, or shock).
> 
> It of course does not prevent an attacker from modifying the content or
> noticing its access if the attacker is in the path between your
> datacentre and the image source.
> 
> However, even in this case, it provides some security insofar as it
> may prevent the attacker from knowing who is accessing the image.

Ok, that makes sense I guess, I would suggest using that in the package
description rather than what you wrote in the ITP.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Looking for ideas for merging a micro package...

[Vincent Danjean]

Le 03/09/2013 14:50, Paul Tagliamonte a écrit :
> On Tue, Sep 03, 2013 at 02:31:35PM +0200, Vincent Danjean wrote:
>>   So, I'm looking for a package that would accept this ruby script
>> (I will probably ask linux-util anyway if nobody has other suggestions)
>> and I will keep it in my perso repository until then.
> 
> Don't kill yourself over this, if there's really nothing else that makes
> sense, you can just say that and re-dput :)
> 
> We just want to ensure that the tradeoff is worth it, and needed :)

The fact is that the FTP team comment was correct: it is really
a small package. So, my question was really open (I do not know every
package in Debian), in case someone has a useful suggestion (that does
not involve to rewrite the script).

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/52263ac6.4090...@free.fr

Re: Consciously blocking packages and development

[Ondřej Surý]

It would probably more helpful to approach our release team asking for
advice how to proceed with transition than sending this blunt rant into d-d.

O.


On Tue, Sep 3, 2013 at 8:10 AM, Norbert Preining  wrote:

> Dear maintainers of debian-edu-doc, all of d-d
>
> [short explanation for d-d: debian-edu-doc has a serious bug since it
> build-deps on a not existing package. Instead of transiting to the
> new pakcage naming, it keeps the old anme hindering transition)
>
> On Do, 15 Aug 2013, Norbert Preining wrote:
> > thanks for fixing it in git, but could you please upload a fixed version
> > of the package as soon as possible?
>
> I see that the fix was even reverted in the git repository.
>
> Are you planning to block TeX Live transition for unforeseeable future?
> Might I remind you that the packaging is for Debian/sid to go into
> testing.
>
> Whatever your ideas and backgrounds concerning Debian Edu are,
> your main obligation is *not*to*block*hinder* other packages.
>
> Might I also remind you once more, that the target of development is
> *unstable* and *NOT* (!!!) wheezy which is released. Your statement
> that it has to be buildable on wheezy is *simply* plain wrong.
>
> It is ridiculous that you not even care for *answering* to
> inquiries on a serious bug, although there is a lot of activity
> in the git repository (see below for logs).
>
> Thanks for your understanding
>
> Norbert
>
>
>
> commit 2f2fd908a54bc106eebdd21e8260ec4399436c5e
> Author: David Prévot 
> Date:   Wed Jul 17 13:13:00 2013 -0400
>
> Revert "Build-depend on texlive-lang-danish | texlive-lang-european
> and texlive-lang-norwegian | texlive-lang-european to support building on
> wheezy and sid. (Closes: #709758)"
>
> This reverts commit 34130ece41450e92cea0a007f24a0fcebbc8573b.
>
> commit a2d9ca4796df74cc4dfb1cf4e490fe15a11b4b32
> Author: David Prévot 
> Date:   Wed Jul 17 13:12:46 2013 -0400
>
> Revert "Change order of alternative depends."
>
> This reverts commit 2bcf0673abe4514deece73502d661c4d888a31c2.
>
> commit 2bcf0673abe4514deece73502d661c4d888a31c2
> Author: Holger Levsen 
> Date:   Mon Jul 15 14:01:10 2013 +0200
>
> Change order of alternative depends.
>
> Build-depend on texlive-lang-european | texlive-lang-danish and
> texlive-lang-european | texlive-lang-norwegian to support building on
> wheezy and sid.
>
> commit 34130ece41450e92cea0a007f24a0fcebbc8573b
> Author: Holger Levsen 
> Date:   Mon Jul 15 13:33:40 2013 +0200
>
> Build-depend on texlive-lang-danish | texlive-lang-european and
> texlive-lang-norwegian | texlive-lang-european to support building on
> wheezy and sid. (Closes: #709758)
>
> 
> PREINING, Norbert   http://www.preining.info
> JAIST, Japan TeX Live & Debian Developer
> DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
> 
>
>
> --
> 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/20130903061002.gc29...@gamma.logic.tuwien.ac.at
>
>


-- 
Ondřej Surý 
Have you tried Knot DNS – https://www.knot-dns.cz/
– a high-performance authoritative-only DNS server

Re: lib/libgsl.so: undefined reference to `cblas_ztrsv' (on Ubuntus)

[Vincent Danjean]

Le 03/09/2013 18:26, Andrey Rahmatullin a écrit :
> On Tue, Sep 03, 2013 at 12:21:50PM -0400, Yaroslav Halchenko wrote:
>> btw - even on Debian systems it is not:
>> $> ldd /usr/lib/libgsl.so 
>> linux-vdso.so.1 (0x7fff5fddb000)
>> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f558ccc9000)
>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f558c91d000)
>> /lib64/ld-linux-x86-64.so.2 (0x7f558d483000)
>>
>> but I am not sure here if that is not intentional to allow "flexibility" to
>> decide to link against a specific blas implementation (gsl's or
>> system-wide)...
> If that was intentional then you as an user of the library should be
> prepared to any kinds of problems.

I've been hit by this problem with my libmath-tamuanova-perl package.
This perl extension use the gsl library and must be linked to a blas
implementation. I use alternatives in Depends but I think this should
have been done in the gsl library itself and not in its depends.

The main problem with blas implementation is that they share some
part of there ABI but not the whole one. So, switching from one
implementation to another sometimes work and sometimes not.

If someone has some free time, analyzing the ABI (soname and symbol),
the dependencies, and the location on the filesystem of the various
blas (atlas pre-compiled, atlas locally compiled, goto blas,
openblas, ...) and related library (lapack, ...) would be very useful.
  It is on my TODO list since a long time but it is still here :-(

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/52263eb6.4060...@free.fr

Replacing a binary package by another one(was: Communication issue?)

[David Prévot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi again,

Le 03/09/2013 03:37, Norbert Preining a écrit :
> On Di, 03 Sep 2013, David Prévot wrote:

>> if you’re in a hurry to see your package reach testing,
>> feel free to provide back the binary packages you removed (via
>> convenient dummy transitional packages) instead of breaking any third
>> party due to their uncoordinated disappearance.
> 
> Umpf, uncoordinated disappearance.

I’ve been told that my previous suggestion was not clearly worded, so
let me try to be a little more specific.

I was directly proposing that, instead of silently removing the
texlive-lang-danish — and at least texlive-lang-norwegian — binary
packages, they could be added back as dummy transitional packages
depending on texlive-lang-european (that is, as far as we were able to
guess, providing the texlive-lang-danish — and texlive-lang-norwegian —
features). That way, this transition is not tight to the celerity third
party packages are able to cope with the change in our archive. As an
added value, any third parties (including those not in the Debian
archive) can benefit of a smooth upgrade instead of a disruptive change.

I’ve witnessed many such transitions, they even usually are kept in the
following stable release (so stable-to-stable upgrades are not too
disruptive for those third parties, and our users). I failed to come up
with a best practice URL documenting such transition, is someone able to
provide one, or correct me if I’ve made that up? (Maybe the dev-ref
would be the appropriate place to document such transition, I’m willing
to propose a patch if it’s worth it.)

Regards

David


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

iQEcBAEBCAAGBQJSJkM5AAoJEAWMHPlE9r085uMH/2IK81w446ORP7cB8B4uOR0N
GtBxEWer6rSwvgA87HmH+ONtaVyUPyXQ+X5i1sN08FQNwWgl8+N4u8xbqYJwKu4e
8+Ogel85pY4hZqk8tuVz/EJC1QVVpKPKccbOZB0TmKfV0jHXwbZt8PhHB22V2Xsl
QC01rzATU9qvxxws2BZEZg7fOPdmRPv0coG/rJwMgIA11pYmEFIGw1iVZc2mxSor
frMH9URLXsgxrCy1RD8/tdq7LzB9ETaae+3xOa+Gt9S5UZ1Oce2SqLQtk26roKIM
trE0is5MVujlQnnwF226ozSO66LJ9DzvGdtFaT6H18paohc9V4JJZB0pgr1KlhE=
=QhU4
-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/5226433b.2000...@debian.org

Re: Looking for ideas for merging a micro package...

[Russ Allbery]

Vincent Danjean  writes:

> The fact is that the FTP team comment was correct: it is really a small
> package. So, my question was really open (I do not know every package in
> Debian), in case someone has a useful suggestion (that does not involve
> to rewrite the script).

moreutils is another possible home for such useful scripts, although I'm
not sure if Joey is interested in accepting Ruby scripts.  I think
currently it's C and Perl.

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

Re: Replacing a binary package by another one(was: Communication issue?)

[Norbert Preining]

Hi David,

On Di, 03 Sep 2013, David Prévot wrote:
> I was directly proposing that, instead of silently removing the
> texlive-lang-danish — and at least texlive-lang-norwegian — binary
> packages, they could be added back as dummy transitional packages

I understood your proposal, of course. Still, since there are no rdepends
besides very few (1?) build-depends on these two packages, I consider
it a a waste of resources. 

I repeat my point, these changes happen on major upgrades. If many
packages are concerned, a mass bug filing is the way to go. Since
we are talking about *one* package that in addition is extremly simple
to fix, I don't consider it useful or necessary to provide transitional
packages. dist-upgrade will remove these packages during upgrade from
stable to next-stable, so nothing to worry.

> I’ve witnessed many such transitions, they even usually are kept in the
> following stable release (so stable-to-stable upgrades are not too
> disruptive for those third parties, and our users). I failed to come up

Nothing disruptive here, dist-upgrade removes conflicting packages
that have no dependencies anymore.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094



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

Re: Replacing a binary package by another one(was: Communication issue?)

[Peter Samuelson]

[Norbert Preining]
> I understood your proposal, of course. Still, since there are no rdepends
> besides very few (1?) build-depends on these two packages, I consider
> it a a waste of resources. 

Sounds like you are saying 'texlive-lang-danish' is only useful as a
package dependency - in other words, users would never install it
explicitly because they want its functionality.  Is that correct?  This
is not clear from the package description, which at least to me looks
like something users _would_ install explicitly:

Description-en: TeX Live: Danish
 Support for typesetting Danish.
 .
 This package includes the following CTAN packages:
  hyphen-danish -- Danish hyphenation patterns.


-- 
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/20130903234245.gc6...@p12n.org

Re: Introducing dgit - git integration with the Debian archive

[Barry Warsaw]

On Aug 31, 2013, at 01:37 AM, Jelmer Vernooij wrote:

>In the end, this meant that using UDD had some minor benefits (a richer
>history, and theoretical improved merge support)

I'd argue that they were more than minor benefits!

>but there were a number of extra things you had to watch out for that made it
>frustrating to use: manually checking sure that the branch was in sync with
>the archive before using it (and giving up on UDD or prodding us if it
>wasn't),

It was really great when you guys added the feature to bzr to actually do this
check and tell you if the branch was up-to-date or not.

>making sure you pushed the right changes to the UDD branches (otherwise they
>would be overwritten by the automatic importer).

I learned never to push a UDD branch.  I almost never had problems when I let
the importer update the branch on upload, rather than try to push a branch.
The downside is that there could be a lag between upload and branch import,
but it hasn't really been much of a problem in practice.

>Cloning one of the bzr branches can also be quite slow because of performance
>issues in bzr that took a long time to fix, and because Launchpad is in the
>UK, whereas there are a lot of mirrors of the Ubuntu archive.

I never found the performance issues to be a hindrance, but I have a good
internet connection.  Besides, over time this was ameliorated by using bzr
shared repos.

>I always considered having the .pc/ directory checked in and the patches
>applied by default for the quilt format a mistake, as it lead to tons of
>spurious conflicts during merges.

It's nice that a source branch gives you a fully unpacked and patched tree
which you can start hacking on immediately, but it was tricky to get quilt
interaction right, especially when doing merges.  Another important lesson is
to be sure that when committing a branch (say for a merge proposal), you do it
at the same quilt push "level" as the original branch.

-Barry


signature.asc
Description: PGP signature

Re: Replacing a binary package by another one(was: Communication issue?)

[Norbert Preining]

On Di, 03 Sep 2013, Peter Samuelson wrote:
> Sounds like you are saying 'texlive-lang-danish' is only useful as a
> package dependency - in other words, users would never install it
> explicitly because they want its functionality.  Is that correct?  This

I never said that. The functionality is now in
texlive-lang-european


Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094



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

Re: Replacing a binary package by another one(was: Communication issue?)

[Peter Samuelson]

> > Sounds like you are saying 'texlive-lang-danish' is only useful as a
> > package dependency - in other words, users would never install it
> > explicitly because they want its functionality.  Is that correct?  This

[Norbert Preining]
> I never said that. The functionality is now in
>   texlive-lang-european

I can see that.  But your argument for removing texlive-lang-danish
etc. is basically "there are almost no rdeps".  But that is only half
the story.  The other half is to explain what will happen to users who
installed texlive-lang-danish because they want Danish language
hyphenation support.  When they upgrade, will they get
texlive-lang-european?  It doesn't look like it to me (no Breaks or
Conflicts), but I haven't actually tried it.


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

Re: Replacing a binary package by another one(was: Communication issue?)

[Norbert Preining]

On Di, 03 Sep 2013, Peter Samuelson wrote:
> texlive-lang-european?  It doesn't look like it to me (no Breaks or
> Conflicts), but I haven't actually tried it.

conflicts there are, texlive-base conflicts with all the old packages.

TL2013 made big changes to the naming of packages. If I go down
the road you suggest I have to introduce about 30 transitional
packages ... 

Simple answer: No.

If someone wants to, I am fine to hand over the maintainance of TL
to those who think they can handle it.

I will not carry 30+ transitional packages.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094



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

Re: Replacing a binary package by another one(was: Communication issue?)

[Ben Hutchings]

On Wed, 2013-09-04 at 10:57 +0900, Norbert Preining wrote:
> On Di, 03 Sep 2013, Peter Samuelson wrote:
> > texlive-lang-european?  It doesn't look like it to me (no Breaks or
> > Conflicts), but I haven't actually tried it.
> 
> conflicts there are, texlive-base conflicts with all the old packages.
> 
> TL2013 made big changes to the naming of packages. If I go down
> the road you suggest I have to introduce about 30 transitional
> packages ... 
> 
> Simple answer: No.
> 
> If someone wants to, I am fine to hand over the maintainance of TL
> to those who think they can handle it.
> 
> I will not carry 30+ transitional packages.

How much do those packages weigh, Norbert?  Are TeX transitional
packages particularly heavy?

I really don't know why you think TeX is exempt from the usual
requirements to support clean upgrades between Debian releases.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.


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

Re: Replacing a binary package by another one(was: Communication issue?)

[Norbert Preining]

On Mi, 04 Sep 2013, Ben Hutchings wrote:
> How much do those packages weigh, Norbert?  Are TeX transitional
> packages particularly heavy?

In kg? In bit? In work time?

> I really don't know why you think TeX is exempt from the usual
> requirements to support clean upgrades between Debian releases.

Please try it before complaining. Clean upgrades are working with
dist-upgrade

And now I leave this discussion, I have enough of it. I complained
about a *serious* bug not being fixed although patches and fixes
are known, and at the end it is me hahahahaha. Go and have
fun yourself.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094



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

Re: Looking for ideas for merging a micro package...

[tony mancill]

On 09/03/2013 02:17 PM, Russ Allbery wrote:
> Vincent Danjean  writes:
> 
>> The fact is that the FTP team comment was correct: it is really a small
>> package. So, my question was really open (I do not know every package in
>> Debian), in case someone has a useful suggestion (that does not involve
>> to rewrite the script).
> 
> moreutils is another possible home for such useful scripts, although I'm
> not sure if Joey is interested in accepting Ruby scripts.  I think
> currently it's C and Perl.

Thank you for pointing this out.  I just recently uploaded a script,
splitpatch, that I argued should be accepted as-is (i.e. as a "micro
package") because of the dependency on ruby.

Given that ruby is becoming more popular for scripting, what do folks
think about a catch-all package for ruby scripts?  I don't have a good
feel for what the right trade-off is between:

* reducing load on the archive by consolidating these tiny packages

* making good use of maintainer's time, the implication being that
coordinating multiple (otherwise unrelated?) ruby scripts is going to be
more of a time commitment for the maintainer(s)

and

* making it easy (or even possible) for users to find these scripts when
the package name doesn't match upstream

Discuss... (and thanks in advance for constructive ideas)
tony



signature.asc
Description: OpenPGP digital signature

Re: Looking for ideas for merging a micro package...

[Russ Allbery]

tony mancill  writes:

> Thank you for pointing this out.  I just recently uploaded a script,
> splitpatch, that I argued should be accepted as-is (i.e. as a "micro
> package") because of the dependency on ruby.

> Given that ruby is becoming more popular for scripting, what do folks
> think about a catch-all package for ruby scripts?  I don't have a good
> feel for what the right trade-off is between:

> * reducing load on the archive by consolidating these tiny packages

> * making good use of maintainer's time, the implication being that
> coordinating multiple (otherwise unrelated?) ruby scripts is going to be
> more of a time commitment for the maintainer(s)

> and

> * making it easy (or even possible) for users to find these scripts when
> the package name doesn't match upstream

I think it makes a ton of sense to have several of these catch-all
packages split by implementation language.  The biggest advantage is to
the maintenance of the catch-all package; most of us only consider
ourselves highly experienced in, or comfortable in, one or two languages,
and therefore it's harder to find maintainers who are comfortable with
packages that mix a bunch of languages.  It's also helpful to be tied in
to the maintenance community for that language to weigh things like good
modules to rely on or not rely on, how burdensome dependencies are, etc.
There's also a minor advantage for the user who may not want to introduce
a whole new interpreter to systems that are tight on space or that need to
be kept simple.

A moreutils-ruby (or some similar name) seems like a great idea to me.

I would check with Joey first, though, just in case he disagrees with that
reasoning and would prefer to include the scripts directly in moreutils.

(splitpatch might make more sense in devscripts, but devscripts I think
has the same set of constraints, albeit with different base languages.
Python and Perl at the moment, I think.)

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