Re: poppler transition

[Steve Langasek]

On Wed, Dec 19, 2007 at 01:09:35PM +0100, Norbert Preining wrote:

> Can we somehow organize that the poppler transition can be done in a
> reasonable time frame?

Only with the cooperation of the maintainers, of course.

> Currently the problematic packages are (from bjorn.haxx.se):
> . gimp
>   uploaded yesterday, needs again 10 days ...

Not problematic TTBOMK, it's built cleanly everywhere and I've bumped the
urgency of the package.  (Having to bump urgency on a new upstream version
of gimp is in a sense its own problem, but this needn't be a blocker for
poppler in any case.)

> . luatex
>   needs 2 more days

No, the real problem with luatex is:

$ grep-excuses luatex
luatex (0.11.2-1 to 0.20.1-1)
Maintainer: Debian TeX Maintainers 
Too young, only 9 of 10 days old
out of date on arm: luatex (from 0.15-1)
^^

The package fails to build with a screwy, arch-specific build failure on
arm.  (As in, the failing code is arm specific.)  Needs investigation.

> . abiword-plugins
>   not yet built on mipsel
>   should be ignored, but forced by vorlon

It is built, the build is not uploaded.  abiword seems to have some
excessively large log files that get stuck in mail systems, so I've pinged
the buildd maintainer about this one (in addition to forcing the package in
britney).

> So let's hope that NO new uploads are happening for the following 8
> days. At least I will refrain from uploading anything.

There should be at least one, since luatex has an as-yet-unfiled RC bug in
unstable.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

wxwidgets 2.8, anyone?

[Daniel Baumann]

Hi,

there are more and more packages which require wxwidgets >=2.8. Last 
time[0], I hoped somebody would finally take care of it, but nothing 
happened yet.


With the new version of poedit, it's not possible to build anymore with 
an older wxwidgets, hence the package is required for me. Does anyone 
have a plan to upload wxwidgets 2.8 within the next four weeks? If not, 
I fear I have to do it.


Regards,
Daniel

--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#456782: ITP: tcpwatch -- tcpwatch is a recorder for HTTP requests in Python

[sean finney]

On Thursday 20 December 2007 01:06:58 am Toni Mueller wrote:
> Hi,
>
> On Thu, 20.12.2007 at 00:06:55 +0100, sean finney <[EMAIL PROTECTED]> 
wrote:
> > the FHS (and debian by extension) doesn't provide support for
> > /usr/libexec. in every case i know of, contents of what would otherwise
> > have gone in /usr/libexec go in /usr/lib/package/ instead.
>
> but this is a misconception because the program *can* be used
> individually, and it was also developed much earlier than whatever

many other programs that *can* be used individually but are typically not done 
so are put in /usr/lib/package.  for example, nagios-plugins-basic and 
friends.  i don't know if that should apply in this case or not, but like i 
said every case i know of is /usr/libexec -> /usr/lib/package.

> individually, and it was also developed much earlier than whatever
> /usr/lib/package you might think is appropriate. And last but not

i have no idea what you're trying to say there.  

> least, you find eg. sendmail in /usr/libexec on BSDs, but not in
> /usr/lib/sendmail/sendmail on Linux, don't you?

actually it's in /usr/lib/sm.bin/sendmail.


and i just have to add that i think it's really silly to add a package/program 
called tcpwatch that doesn't actually... watch tcp connections.  but 
whatever, it's not like i'm installing it.


sean


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

Re: Shouldn't apt-listchanges be Priority: standard?

[Steve Langasek]

Thanks for starting this discussion, Christian; I had planned to do so
myself within a few days.

On Wed, Dec 19, 2007 at 11:49:41AM +0530, Christian Perrier wrote:
> From Bug#456977: 

> Steve Langasek commented while closing this bug report:

> > It is recommended that you use apt-listchanges on your system, to be
> > notified of package behavior changes such as this.

> Could we consider increasign the priority of apt-listchanges so that
> it is installed by default?

> More and more developers use NEWS.Debian to communicate about
> disruptive package changes but that doesn't really help if the tools
> that warn users are not insalled by default.

Further to this, we have the position of the debconf maintainers that
debconf notes should *not* be used for unconditionally sending notices to
users on upgrade.  It's fairly important then that there is a reliable
method to deliver such messages to users by default, and it's my
understanding that apt-listchanges is that chosen method.  Supporting this
by default means raising the package priority so that it's installed by
default.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: wxwidgets 2.8, anyone?

[Daniel Baumann]

Daniel Baumann wrote:
there are more and more packages which require wxwidgets >=2.8. Last 
time[0], I hoped somebody would finally take care of it, but nothing 
happened yet.


[0] http://lists.debian.org/debian-devel/2007/05/msg00028.html and ff

and also, i'm ware of #403237.

--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: poppler transition

[Norbert Preining]

Hi Steve,

On Mi, 19 Dez 2007, Steve Langasek wrote:
> $ grep-excuses luatex
> luatex (0.11.2-1 to 0.20.1-1)
> Maintainer: Debian TeX Maintainers 
> Too young, only 9 of 10 days old
> out of date on arm: luatex (from 0.15-1)
> ^^

Hmm, right (why wasn't that shown on bjorn.haxx the other day).

> The package fails to build with a screwy, arch-specific build failure on
> arm.  (As in, the failing code is arm specific.)  Needs investigation.

That here
  gcc -g -O2 -Wall  -DLUA_USE_POSIX-c -o lcoco.o lcoco.c
  lcoco.c: In function 'lua_newcthread':
  lcoco.c:460: error: '__JMP_BUF_SP' undeclared (first use in this function)
  lcoco.c:460: error: (Each undeclared identifier is reported only once
  lcoco.c:460: error: for each function it appears in.)

I asked Taco and the luatex-dev mailing list for that.

> > . abiword-plugins
> > not yet built on mipsel
> > should be ignored, but forced by vorlon
> 
> It is built, the build is not uploaded.  abiword seems to have some

Ok, thanks.

> There should be at least one, since luatex has an as-yet-unfiled RC bug in
> unstable.

Will do immediately as soon as I can fix it. Is there an ARM debian
machine where I can do test builds in a sid/chroot?

Thanks a lot and all the best

Norbert

---
Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
`Ford, you're turning into a penguin. Stop it.'
 --- Arthur experiences the improbability drive at work.
 --- Douglas Adams, The Hitchhikers Guide to the Galaxy


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Steve Langasek]

On Mon, Dec 10, 2007 at 05:45:27PM +0100, Josselin Mouette wrote:
> Le dimanche 09 décembre 2007 à 15:44 -0800, Steve Langasek a écrit :
> > > For example, pkg-config --libs gtk+-x11-2.0 will return, among others,
> > > -lglib-2.0 and -lm. And this is perfectly intentional.

> > Just because it's intentional doesn't mean it isn't absurd and wrong.

> It may be absurd, but I don’t think it is wrong.

> > No, what can be done is to fix upstream's broken declaration that 'you can
> > assume glib functions are available when doing "#include "'.  It
> > doesn't follow that just because this works in practice, it should be a
> > supported usage.

> When many of the types used by GTK+ are those provided by GLib, it
> sounds wrong to ask developers to include the GLib headers to have these
> types available.

Well, that part is fairly reasonable, I admit.  What isn't reasonable is to
go from "including gtk.h lets you use glib types" to "calling pkg-config
--libs gtk+-2.0 lets you invoke glib functions".  Yes, including gtk.h is
always going to be sufficient, in practice, to get the glib types; but a)
includes != pkg-config, b) since it isn't implied there really is no
obligation to support such an expectation wrt pkg-config use, aside from
upstream's apparent commitment to compatibility with foolishly-assembled
build systems.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Steve Langasek]

On Mon, Dec 10, 2007 at 09:47:36PM +0100, Simon Richter wrote:

>>> No, what can be done is to fix upstream's broken declaration that 'you can
>>> assume glib functions are available when doing "#include "'.  It
>>> doesn't follow that just because this works in practice, it should be a
>>> supported usage.

>> When many of the types used by GTK+ are those provided by GLib, it
>> sounds wrong to ask developers to include the GLib headers to have these
>> types available.

> If it is really expected that type declarations are to be shared between a 
> program and a library, then the program becomes dependent on the library's 
> ABI without this dependency being formally expressed in any usable form, 
> which is broken in and by itself.

> GTK needs to provide its own definitions of types and not expose interfaces 
> it does not control.

Fine in theory, in practice this can be a significant burden to the library
maintainer.  FWIW, I don't see any reason why a library can't use
externally-defined types directly, /as long as/ they have some mechanism for
ensuring ABI consistency between the two libraries (i.e., an ABI change in
the underlying library is always accompanied by an soname change in the
dependent library).

(BTW, pkg-config upstream wrongly claims that exporting dependent libs in
the pkg-config --libs output provides this protection. :/)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: wxwidgets 2.8, anyone?

[Raphael Hertzog]

Hello Daniel,

On Thu, 20 Dec 2007, Daniel Baumann wrote:
> there are more and more packages which require wxwidgets >=2.8. Last 
> time[0], I hoped somebody would finally take care of it, but nothing 
> happened yet.
>
> With the new version of poedit, it's not possible to build anymore with an 
> older wxwidgets, hence the package is required for me. Does anyone have a 
> plan to upload wxwidgets 2.8 within the next four weeks? If not, I fear I 
> have to do it.

I have been (indirectly) contacted by upstream developers of wxWindows who
are also unsatisfied by the lack of action of Ron. It's clear that Ron and
upstream are not in good terms (Ron being a former upstream developer).

In those conditions I wonder if Ron is really a good maintainer for this
package. And from what I saw in the BTS, he deliberatly blocks any work on
wx 2.8 until an hypothetic transition plan. Though I've not seen any
serious work on a "transition plan" from himself. 

I'm also unable to judge of the quality of the 2.6 release compared to 2.8
but I've not seen any serious criticism of 2.8 anywhere else. Ron wonders
if Debian shouldn't skip 2.8 to go straight to 3.0, but according to
upstream it's far more realistic to have 2.8 as main version in Lenny.
If all 2.6/2.4 packages are converted to 2.8, then we might have the
possibility to have 3.0 once it's out. In the mean time, it looks like the
best issue is to start working on 2.8 in Lenny and stabilize it if needed.

Apparently, Vadim Zeitlin <[EMAIL PROTECTED]> is ready to take care of
the Debian packaging but he would need a sponsor and I'm sure some help
would be useful as well.

Thus Daniel I'd suggest you to go ahead for wxWindows 2.8 with the help of
Vadim. Ron should simply let this package go because from what I see he
creates unnecessary tensions between upstream and Debian, and even between
other DD who need wxWindows 2.8 for their packages.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#456782: ITP: tcpwatch -- tcpwatch is a recorder for HTTP requests in Python

[Toni Mueller]

Hi Sean,

On Thu, 20.12.2007 at 09:09:37 +0100, sean finney <[EMAIL PROTECTED]> wrote:
> and i just have to add that i think it's really silly to add a
> package/program called tcpwatch that doesn't actually... watch tcp
> connections.  but whatever, it's not like i'm installing it.

well, that would be just following established tradition (and meet
user's expectations) in keeping the name, but I'm currently considering
to rename the program and "fix" the problem of users not easily finding
it via README.Debian, while keeping the word 'tcpwatch' somewhere in
the package name. The resultant program will then be placed in
/usr/bin, under an appropriate name.


Best,
--Toni++


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: poppler transition

[Michael Biebl]

Norbert Preining schrieb:
> Dear all!
> 
> The other packages which are ready for transition and only waiting are:
> evince, gambas, kdegraphics, pdfcube, tracker, texlive-bin
> 
> So let's hope that NO new uploads are happening for the following 8
> days. At least I will refrain from uploading anything.

As tracker maintainer, I can hold back any new uploads for the time being

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: wxwidgets 2.8, anyone?

[Daniel Baumann]

Raphael Hertzog wrote:

Hello Daniel,


Hi,

and thanks for your answer.


Apparently, Vadim Zeitlin <[EMAIL PROTECTED]> is ready to take care of
the Debian packaging but he would need a sponsor and I'm sure some help
would be useful as well.


I'd be more than happy if Vadim would maintain the package, and I'll 
gladly sponsor it.


Vadim, do you have already something I can look at?

--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: wxwidgets 2.8, anyone?

[Francesco P. Lovergine]

On Thu, Dec 20, 2007 at 09:54:46AM +0100, Raphael Hertzog wrote:
> Hello Daniel,
> 
> I have been (indirectly) contacted by upstream developers of wxWindows who
> are also unsatisfied by the lack of action of Ron. It's clear that Ron and
> upstream are not in good terms (Ron being a former upstream developer).
> 
> In those conditions I wonder if Ron is really a good maintainer for this
> package. And from what I saw in the BTS, he deliberatly blocks any work on
> wx 2.8 until an hypothetic transition plan. Though I've not seen any
> serious work on a "transition plan" from himself. 
>
> [...]

See also

http://lists.debian.org/debian-devel/2007/11/msg00290.html

And I'm quoting below my personal answer to Ron's off-list question 
about 'my transition plan':

"My plan is preparing an experimental 2.8 package and asking all

interested developers trying building and doing some extensive  
   
tests against it. A 2.6 -> 2.8 migration is out of mind due 
   
to consistent changes in APIs and behaviors. Some programs  
   
could consistently use 2.8 without glitches, some others not.   
   
As in case of libdb for instance, we will have to live  
   
with multiple source packages, at least until all interested
   
upstreams will not move completely to new interfaces. Than some 
   
version will become droppable (i.e. the old 2.4).   
   
I did not expect the situation will become better with 3.0. 
   
And the current status require starting a team work, because
   
no maintainers can reasonably maintain the monster alone,   
   
as already true for Qt and GTK+. People who monitor svn 
   
development and create suitable ad-hoc patches to manage
   
main issues are also required.  
   

  
Now, what are YOUR plans?"

No answer. It is quite clear that Ron will not support anything
which is not 3.0 whenever ready (after Lenny freezing I suppose).
I received (if my memory does not fail) no contact by other
supposed interested people in the meantime. 

I find quite superfluous waiting another month in the long way
to a wxwidgets 2.8 package stabilization. It needs action and now. 

PS:
I'm not personally interested in supporting
wxwidgets because already heavily involved in other tasks, sorry. 



-- 
Francesco P. Lovergine


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Shouldn't apt-listchanges be Priority: standard?

[Pierre Habouzit]

On Thu, Dec 20, 2007 at 06:13:02AM +, Christian Perrier wrote:
> Quoting Philippe Cloutier ([EMAIL PROTECTED]):
> >>
> >> Could we consider increasign the priority of apt-listchanges so that
> >> it is installed by default?
> > I'm against making it standard, because currently tasksel doesn't ask if a 
> > recommendation should be installed, so when we make tasksel install 
> > recommendations by default, apt-listchanges would bring in GTK+ and company 
> > (due to its recommendation of python-glade2). This is useless for X-less 
> > installs.
> 
> "Throwing away the baby with the bath's water", no? :-)
> 
> I'm pretty sure that Pierre would downgrade the recommendation to a
> suggestion in case apt-listchanges is "Priority: standard", n'est-ce
> pas Pierre?

  I don't know, the point is that if people use the "gtk" front-end then
I _think_ there will be all kind of exceptions and errors everywhere on
the console. I have to test it doesn't happen and fallback to the pager
front-end if glade isn't there.

  Then I'll be able to move that to a suggest because it won't break
apt-listchanges badly. But it's a 10-liner away probably.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpy3WJeMbYi3.pgp
Description: PGP signature

Ψηφιοποίηση και φύλαξη αρχείων

[Bousgou Vassiliki]

 

Θα ήθελα να μας προσκομίσετε μερικές πληροφορίες για την εταιρεία σας όπως:

 

*   Company Profile 
*   References από τράπεζες που έχετε συνεργαστεί για παρόμοιο έργο 
*   Πιστοποιήσεις κατά ISO 
*   Οικονομικά στοιχεία της εταιρείας σας. 

 

Καθώς και  βέλτιστες πλήρεις λύσεις που έχετε να προτείνετε  σε σχέση με το 
έργο ψηφιοποίησης και φύλαξης του αρχείου τής τράπεζας προκειμένου να έρθουμε 
σε  μελλοντική συνεργασία αν και εφόσον υπάρχει αυτή η δυνατότητα από την 
εταιρεία σας.

 

Ευχαριστώ εκ των προτέρων.

 

 

 

Re: wxwidgets 2.8, anyone?

[Francesco P. Lovergine]

On Thu, Dec 20, 2007 at 10:21:08AM +0100, Francesco P. Lovergine wrote:
> Now, what are YOUR plans?"
> 
> No answer. 

Sorry Ron, No _email_ answer. We talked in IRC about that indeed, I
forgot that.

-- 
Francesco P. Lovergine


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Josselin Mouette]

Le jeudi 20 décembre 2007 à 00:41 -0800, Steve Langasek a écrit :
> > When many of the types used by GTK+ are those provided by GLib, it
> > sounds wrong to ask developers to include the GLib headers to have these
> > types available.
> 
> Well, that part is fairly reasonable, I admit.  What isn't reasonable is to
> go from "including gtk.h lets you use glib types" to "calling pkg-config
> --libs gtk+-2.0 lets you invoke glib functions".

Most GTK+ data types are inherited from Glib, and you need at least to
free them with g_free, g_object_unref, g_slist_free, and so on.

I’ve tried to sum up in bug #456335 the garbage that remains in
GTK’s .pc files, so that in we end we can keep only the legitimate ones,
but I don’t think we can manage to drop things like glib and gobject.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Bug#457198: ITP: lua-leg -- Leg library for lua5.1

[Enrico Tassi]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

   Package name: lua-leg
Version: 0.1.2
Upstream Author: Humberto Saraiva Nazareno dos Anjos
URL: http://leg.luaforge.net
License: MIT/X
Description:
 This package contains leg, a Lua library exporting a complete Lua 5.1 grammar
 and a small API for user manipulation. It can be used to implement a macro
 preprocessor or any other task that needs to parse a .lua file.

This library is required for shake, a unit testing library for lua

The package is already in shape:
 svn://svn.debian.org/pkg-lua/packages/lua-leg
 
-- 
Enrico Tassi



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re[2]: wxwidgets 2.8, anyone?

[Vadim Zeitlin]

On Thu, 20 Dec 2007 09:54:46 +0100 Raphael Hertzog <[EMAIL PROTECTED]> wrote:

RH> Apparently, Vadim Zeitlin <[EMAIL PROTECTED]> is ready to take care of
RH> the Debian packaging but he would need a sponsor and I'm sure some help
RH> would be useful as well.

 Hello,

 I can indeed take care of this (as I said in previous, private, mail, I'm
interested in having up to date and well maintained wx packages for Debian
as both wx developer and Debian user, and I'd be glad to contribute
something back to Debian too) but currently the maintenance of the packages
is done by Robin Dunn, another wx developer and the author of wxPython. So
maybe Robin would prefer to take this role himself -- I'm cc'ing him so
that he could take this decision.

 But in any case and whoever does it, I'll certainly do my best to help and
I'd also like to propose helping any maintainers of wx-dependent packages
and their upstream developers with making sure the packages work correctly
with wx 2.8. Please post to [EMAIL PROTECTED] (preferred) or
contact me directly if you have any problems with porting existing code to
wx 2.8 (and, in the relatively near future, to 3.0 too).


RH> Thus Daniel I'd suggest you to go ahead for wxWindows 2.8 with the help
RH> of Vadim.

 To answer Daniel's question, we do have something you can look at:

- The control &c files used for building the packages can be seen at
  http://svn.wxwidgets.org/viewvc/wx/wxWidgets/branches/WX_2_8_BRANCH/debian/
  (you can also see the latest version by replacing "branches/WX_2_8_BRANCH"
  with "trunk")

  They were written by Ron Lee and we've tried to avoid modifying them
  much so far as we don't understand everything they do. Any comments/
  suggestions on improving them would be very welcome -- thanks in advance!

- The packages themselves are available at http://apt.wxwidgets.org/

  Again, if you see anything wrong with them, please let us know.


 Thanks in advance,
VZ


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: wxwidgets 2.8, anyone?

[Daniel Baumann]

Ron wrote:

We already ostensibly have a group of DD's that
have committed themselves to some degree or another to help with
this, and I've been handing out access to the resources available
for that like candy to all who asked.


and yet there has nothing happened (which is just a statement and not an 
accusation to you or anyone else).



There are even sketches for a transition plan.  If you'd like to
review that, and think there is some way you can help, then please
Just Ask Me.  M'kay?


sure.

why not just upload wxwidget2.8 now to unstable (without naming clashes 
to 2.4 and 2.6), so that those packages which *need* wxwidget2.8 can use it?



I'll leave it as an exercise for the reader to divine VZ's 'interest'
in Debian -- but this offer is wide open to anyone who really wants
to help.  But just shoving some half-assed package into the distro
and saying "to hell with transitions, let god sort it out", isn't
really what I'd call Best Practice for building a distro release.


I agree that it is a mess to have multiple versions of the same package 
in the archive. However, I think it is not ok to block those packages 
which require new wxwidget in favour for those old packages which do not 
(yet or will never ever) work with the new wxiwdget, if it is for the 
only purpose of having only two instead of three wxwidgets in the archive.


or in other words: It's less worse to have three wxwidget versions in 
the archive than only two and having other packages delaying/blocking by 
that.



If we can move from the hyperbolae to some rational discussion about
what _actually_ needs to be done, and who _actually will_ do it, this
might actually be productive.  In the absence of that, quite clearly,
not much is getting done.  I for one don't find that a particularly
surprising resultant outcome.


My plan would be:

  * review and upload the package from Vadim in the next days.

  * try to really get rid of wxwidget2.4.

  * try to get rid of wxwidget2.6 if possible.

What is your alternative plan, or is your position of 
lenny-without-wx2.8 still current?


Regards,
Daniel

--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#456782: ITP: tcpwatch -- tcpwatch is a recorder for HTTP requests in Python

[Toni Mueller]

Hi,

On Thu, 20.12.2007 at 13:57:39 +1100, Hamish Moffatt <[EMAIL PROTECTED]> wrote:
> Sorry you don't like our feedback, but this is the reason why ITPs are
> posted to debian-devel. 

let me say that I think I did change my mind in the course of the
discussion, maybe not entirely in the direction you, or someone else
(there were contradicting suggestions made) like, so the process has
born some fruit.

Apart from that, we'll all have to see what the result will be before
we can continue bickering, right?

;)

What I can also say is that I _was_ surprised how such a minor package
could spark this much discussion, requiring almost as much effort as
the packaging itself (but which I now want to overhaul).


Best,
--Toni++


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

testing build errors on arm/sid

[Norbert Preining]

Hi all,

I need to check out some build failures on ARM arch in a sid chroot. I
found a chroot on leisner.debian.org. 

But since I have never done this, how can I as normal user there check
that? Is there something like a cow/pbuilder using this chroot? 

Thanks a lot for any comments

Norbert

---
Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
`The best way to get a drink out of a Vogon is to stick
your finger down his throat...'
 --- The Book, on one of the Vogon's social inadequacies.
 --- Douglas Adams, The Hitchhikers Guide to the Galaxy


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Robert Collins]

On Thu, 2007-12-20 at 00:51 -0800, Steve Langasek wrote:
> On Mon, Dec 10, 2007 at 09:47:36PM +0100, Simon Richter wrote:
> 
> >>> No, what can be done is to fix upstream's broken declaration that 'you can
> >>> assume glib functions are available when doing "#include "'.  
> >>> It
> >>> doesn't follow that just because this works in practice, it should be a
> >>> supported usage.
> 
> >> When many of the types used by GTK+ are those provided by GLib, it
> >> sounds wrong to ask developers to include the GLib headers to have these
> >> types available.
> 
> > If it is really expected that type declarations are to be shared between a 
> > program and a library, then the program becomes dependent on the library's 
> > ABI without this dependency being formally expressed in any usable form, 
> > which is broken in and by itself.
> 
> > GTK needs to provide its own definitions of types and not expose interfaces 
> > it does not control.
> 
> Fine in theory, in practice this can be a significant burden to the library
> maintainer.  FWIW, I don't see any reason why a library can't use
> externally-defined types directly, /as long as/ they have some mechanism for
> ensuring ABI consistency between the two libraries (i.e., an ABI change in
> the underlying library is always accompanied by an soname change in the
> dependent library).

I'd make a stronger statement and say that reusing types is a positive
thing. If you are reusing a glib list in your pet library, creating your
own type makes your library incompatible with other libraries also using
glib lists and providing code to manipulate them... and if it doesn't
make it incompatible then its not going to achieve the ABI
considerations that are under discussion here.

So really I think each dependant library of a library that is
dynamically linked to falls into one of two categories:
 - internal detail
 - implementation detail resulting in exposed ABI

So if I link program X against libfoo which uses libbar, if libbar is an
internal detail of libfoo then:
libfoo -> [EMAIL PROTECTED] ABI
X -> [EMAIL PROTECTED]'s ABI only.

And a rebuild of libfoo to link a new libbar ABI won't break X, nor will
it require a rebuild of X. 

The conditions for internal detail only are very stringent: compiler
alignment, structure sizes etc etc for all non opaque (where opaque is
opaque to the /compiler/ not to the user's code!) exported types of
libfoo must not be dependent on libbar at all.

I doubt that many libraries will meet this requirement for all their
dependent libraries (and consider libc as just an extremely common case
of this).


For all other cases, when a used ABI gets exposed, while we may not want
X to depend (at the package level) on libbar; at an ABI level it does.
We need to decide how we represent that. We also have at least two
dimensions here:
runtime linker behaviour
package management behaviour

From the runtime linker we want:
 * an error/warning/something when two instances of the same API with
different ABI's are loaded. This commonly occurs when libbar.1 and
libbar.2 are both loaded, but it can occur more generally when libbar is
renamed to libquux and then libbar.1 and libquux.2 are loaded (by X and
libfoo respectively).
 * To be able to interrogate how something was linked sufficiently well
to generate packaging metadata automatically.

From the package manager we want:
 * To know when we have to rebuild X because libbar has changed.
 * To allow upgrades to libbar on users systems without changing X when
possible.

The case where libbar is an internal detail is trivial (detection isn't:
see abicheck and icheck - libraries really need icheck in the package
build rules IMNSHO); I'm going to ignore it here. 

For the case where libbar is not an internal detail. Starting with
packaging as thats easiest:
 * we should depend on a minimum version of the libbar we need (as we
already bump the package name when the ABI changes incompatibly in a
library this is straight forward) and gives the opportunity to upgrade
libbar within an ABI safely.
 * we can do an rdepends on e.g. libbar2 when libbar's API changes from
2 to 3 to find packages we need to rebuild.

One defect here is when symbols are shared from within a non-library -
e.g. the case with some programs plugin's. Here, a plugin may use a
symbol from within the program X, which is ABI dependent all the way
back, so treating programs as libraries - that is having an ABI - might
make sense. I haven't considered this in detail...


The runtime loader is more tricky:
 * If we link X to libfoo only:
   - libfoo's soname has to be manually changed when libbar's changes or
hilarity results
   - we don't have a robust way that I know of to interrogate X to find
out that we need a package dependency on libbar
   + we don't need to have libbar present when it is only optionally
used (that is by calling some libfoo feature that needs libbar)

 * If we link X to libbar directly:
   - because we can't tell how much

Re: wxwidgets 2.8, anyone?

[Daniel Brumbaugh Keeney]

On Dec 20, 2007 2:08 AM, Daniel Baumann wrote:
> Hi,
>
> there are more and more packages which require wxwidgets >=2.8. Last
> time[0], I hoped somebody would finally take care of it, but nothing
> happened yet.

I just wanted to alert you in case you're not aware, that wxwidgets
maintains their own repository at 

Daniel Brumbaugh Keeney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: wxwidgets 2.8, anyone?

[Robin Dunn]

Vadim Zeitlin wrote:

On Thu, 20 Dec 2007 09:54:46 +0100 Raphael Hertzog <[EMAIL PROTECTED]> wrote:

RH> Apparently, Vadim Zeitlin <[EMAIL PROTECTED]> is ready to take care of
RH> the Debian packaging but he would need a sponsor and I'm sure some help
RH> would be useful as well.

 Hello,

 I can indeed take care of this (as I said in previous, private, mail, I'm
interested in having up to date and well maintained wx packages for Debian
as both wx developer and Debian user, and I'd be glad to contribute
something back to Debian too) but currently the maintenance of the packages
is done by Robin Dunn, another wx developer and the author of wxPython. So
maybe Robin would prefer to take this role himself -- I'm cc'ing him so
that he could take this decision.



I've considered this in the past, and even took a few steps towards 
becoming the official Ubuntu maintainer, but I realized that I just 
don't have the time for it.  If I were to take the time to focus that 
closely on just Debian/Ubuntu then I'm afraid that my work on all the 
other platforms would end up suffering for it.  I can continue helping 
with the technical aspects to maintain the debian/rules and etc. but I 
don't see myself having the time for all the advocacy, hoop jumping, red 
tape cutting and other bureaucratic stuff needed for an official package 
maintainer.


--
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#457220: ITP: shake -- test engine for lua

[Enrico Tassi]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

   Package name: shake
Version: 1.0.0
Upstream Author: Copyright © 2007 Kepler Project.
URL: http://shake.luaforge.net
License: MIT/X
Description: 
 Simple and transparent test engine for Lua that assumes that tests
 only use standard assert and print calls. It gives accurate
 feedback on tests failures.

-- 
Enrico Tassi

Re: wxwidgets 2.8, anyone?

[Joerg Jaspert]

> or in other words: It's less worse to have three wxwidget versions in
> the archive than only two and having other packages delaying/blocking by
> that.

Only if you have a good plan how to get rid of at least one of the older
releases.


-- 
bye Joerg
[Kaffeemaschinen und Babies]
Funktioniert aber so ähnlich: Du füllst oben was rein und unten kommt's braun 
raus...
   -- Martin Würtele


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#457242: general: unable to print,cause /dev/usb/lp0 permisions

[pintitas]

Package: general
Severity: grave
Justification: renders package unusable

in order to use the  printer (after configuring the printer) you must 
set /dev/usb/lp0 permissions to 755, 777 ... (various printers models)

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-k7
Locale: LANG=spanish, LC_CTYPE=spanish (charmap=ISO-8859-15) (ignored: LC_ALL 
set to [EMAIL PROTECTED])



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#457242: marked as done (general: unable to print,cause /dev/usb/lp0 permisions)

[Debian Bug Tracking System]

Your message dated Thu, 20 Dec 2007 15:38:37 -0800
with message-id <[EMAIL PROTECTED]>
and subject line Bug#457242: general: unable to print,cause /dev/usb/lp0 
permisions
has caused the attached Bug report 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 I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: general
Severity: grave
Justification: renders package unusable

in order to use the  printer (after configuring the printer) you must 
set /dev/usb/lp0 permissions to 755, 777 ... (various printers models)

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-k7
Locale: LANG=spanish, LC_CTYPE=spanish (charmap=ISO-8859-15) (ignored: LC_ALL 
set to [EMAIL PROTECTED])


--- End Message ---
--- Begin Message ---
On Fri, Dec 21, 2007 at 12:05:09AM +0100, pintitas wrote:
> Package: general
> Severity: grave
> Justification: renders package unusable

> in order to use the  printer (after configuring the printer) you must 
> set /dev/usb/lp0 permissions to 755, 777 ... (various printers models)

No you don't need to, nor should you be doing this.  You should probably ask
for help with your problem on debian-user-spanish, since this is not a
well-formed bug report.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]

--- End Message ---

Re: wxwidgets 2.8, anyone?

[Roberto C . Sánchez]

On Thu, Dec 20, 2007 at 11:36:06AM -0600, Daniel Brumbaugh Keeney wrote:
> On Dec 20, 2007 2:08 AM, Daniel Baumann wrote:
> > Hi,
> >
> > there are more and more packages which require wxwidgets >=2.8. Last
> > time[0], I hoped somebody would finally take care of it, but nothing
> > happened yet.
> 
> I just wanted to alert you in case you're not aware, that wxwidgets
> maintains their own repository at 
> 
Yes, but that does not help packages which are in Debian as you cannot
have a build-time dependency on a third-party repository like that.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: -Wl,--as-needed considered possibly harmful

[Steve Langasek]

On Fri, Dec 21, 2007 at 04:08:28AM +1100, Robert Collins wrote:
> > (BTW, pkg-config upstream wrongly claims that exporting dependent libs
> > in the pkg-config --libs output provides this protection. :/)

> It doesn't? (I must be missing something as I thought it did, just over
> aggressively).

Nope.

Consider two libraries, libfoo and libbar.  libfoo depends on libbar,
references functions from it and uses some of libbar's types in its own
exported API.

We assume the Debian-style libbar-dev, which ensures that the libbar headers
match the version of libbar.so on the system.

The pkg-config technique guarantee that, when an application links against
libfoo, it is also linked against libbar.  Because of the preceding, this
guarantees that the application is linked against the version of libbar
whose ABI matches that of the headers used when building the application.

But *nothing* here guarantees that the version of libbar the application is
linked against has the same ABI as the one libfoo itself linked against!  If
libfoo linked against libbar1, the pkg-config approach only ensures that
when your application is built against the libbar2 version of libbar-dev,
the resulting binary will depend on both libbar1 and libbar2 (despite not
using any symbols from libbar2).  All this does is increase the chances of
segfaults or bad runtime behavior as a result of symbol clobbering.

So the usage recommended by pkg-config upstream does nothing at all to solve
the problem it's supposed to, and instead causes other linkage problems.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Work-needing packages report for Dec 21, 2007

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 343 (new: 3)
Total number of packages offered up for adoption: 88 (new: 1)
Total number of packages requested help for: 34 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   mp3splt (#457132), orphaned yesterday
 Description: Splits MP3 and Ogg Vorbis files without reencoding
 Installations reported by Popcon: 823

   mp3wrap (#457131), orphaned yesterday
 Description: Utility for MP3 wrapping (rolling multiple MP3s into
   one)
 Installations reported by Popcon: 322

   ofbis (#457022), orphaned 2 days ago
 Description: simple Linux framebuffer graphical library
 Reverse Depends: libofbis-dev
 Installations reported by Popcon: 24

340 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   libgstreamer-perl (#456924), offered 2 days ago
 Description: Perl interface to the gstreamer media processing
   framework
 Installations reported by Popcon: 37

87 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   aboot (#315592), requested 910 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot aboot-cross dfsbuild ltsp-client-core
 Installations reported by Popcon: 128

   apt-build (#365427), requested 600 days ago
 Description: Need new developer(s)
 Installations reported by Popcon: 930

   ara (#450876), requested 39 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 111

   athcool (#278442), requested 1150 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 280

   cdrskin (#450873), requested 39 days ago
 Description: command line CD-R/CD-RW writing tool
 Reverse Depends: k3b
 Installations reported by Popcon: 418

   cvs (#354176), requested 665 days ago
 Description: Concurrent Versions System
 Reverse Depends: bonsai crossvc cvs-autoreleasedeb cvs-buildpackage
   cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta (14
   more omitted)
 Installations reported by Popcon: 22007

   dctrl-tools (#448284), requested 54 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: debian-goodies dlocate feta hg-buildpackage mlmmj
   sbuild simple-cdd
 Installations reported by Popcon: 5843

   dpkg (#282283), requested 1125 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-cross apt-src
   backuppc build-essential bzr-builddeb clamsmtp crosshurd (93 more
   omitted)
 Installations reported by Popcon: 70228

   elvis (#432298), requested 164 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 308

   fglrx-driver (#454993), requested 12 days ago (non-free)
 Description: non-free AMD/ATI r5xx, r6xx display driver
 Reverse Depends: fglrx-amdcccle
 Installations reported by Popcon: 2196

   gentoo (#422498), requested 228 days ago
 Description: a fully GUI-configurable, two-pane X file manager
 Installations reported by Popcon: 278

   grub (#248397), requested 1319 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: dfsbuild replicator startupmanager
 Installations reported by Popcon: 64787

   imagemagick (#452314), requested 29 days ago
 Description: Image manipulation programs
 Reverse Depends: advi-examples afterstep album ale alml ascd
   asymptote autotrace bins cimg-dev (83 more omitted)
 Installations reported by Popcon: 27286

   ispell-et (#391105), requested 442 days ago
 Description: Estonian dictionary for Aspell/Ispell/MySpell
 Installations reported by Popcon: 52

   loop-aes-utils (#385614), requested 476 days ago
 Description: Tools for mounting and manipulating filesystems
 Reverse Depends: loop-aes-modules-2.6.23-1-486
   loop-aes-modules-2.6.23-1-686 loop-aes-modules-2.6.23-1-686-bigmem
   loop-aes-modules-2.6.23-1-alpha-generic
   loop-aes-modules-2.6.23-1-alpha-legacy
   loop-aes-modules-2.6.23-1-alpha-smp loop-aes-modules-2.6