Bug#459699: ITP: sdlroads -- SDL-based recreation of classic plane-jump game

[Christopher Schmidt]

Package: wnpp
Severity: wishlist
Owner: Christopher Schmidt <[EMAIL PROTECTED]>


* Package name: sdlroads
  Version : 0.10 
  Upstream Author : Peter Newman
* URL : http://sourceforge.net/projects/sdlroads/
* License : GPL 
  Programming Lang: C
  Description : SDL-based recreation of classic plane-jump game

 This game is a recreation of the Bluemoon classic, Skyroads. The game
 allows you to control a small spaceship, which you must jump from plane
 to plane to reach the end of the level without falling off the edges or
 into any gaps.

 I'm working with the upstream author to clean up the source code, and
 the project Homepage may change as a result of this. The code has been
 largely untouched for several years, but it has been used occasionally
 in that time period with no known bugs.

-- 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.18-5-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)



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

Re: Correct spelling/capitalisation of project names

[Ralf Treinen]

On Tue, Jan 08, 2008 at 08:07:14AM +0100, Yves-Alexis Perez wrote:
> On lun, 2008-01-07 at 20:06 -0600, Raphael Geissert wrote:
> > Some weeks ago I noticed that some package descriptions incorrectly
> > spell
> > some project names, mainly because of capitalisation.
> > For example GNOME is being spelt in some packages as Gnome, or simply
> > gnome,
> > when its right spelling: GNOME. Other project names such as Debian,
> > KDE and
> > Linux aren't being correctly capitalised.
> > 
> Could you add Xfce to the list? This is the correct spelling, not XFce
> nor XFCE.

And also OCaml, please? -Ralf.


signature.asc
Description: Digital signature

Re: Correct spelling/capitalisation of project names

[Stefano Zacchiroli]

On Mon, Jan 07, 2008 at 11:54:32PM -0800, Russ Allbery wrote:
> BTW, the way that the Lintian spell-checking works is that it looks for
> errors rather than looking for each word in a dictionary.  It has a table
> of pairs of error and correct word.  So if you notice any common
> misspelled words that Lintian doesn't catch, please let debian-lint-maint
> know and we'll add them to the table.

Regarding the Objective Caml language, whose acronym correct
capitalization is "OCaml", please add the following:
ocaml -> OCaml
OCAML -> OCaml

Many thanks!

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Francesco P. Lovergine]

On Tue, Jan 08, 2008 at 06:20:20AM +0100, Cyril Brulebois wrote:
> On 08/01/2008, Michal Čihař wrote:
> > Adding --disable-rpath to configure might be easier solution for this
> > problem.
> 
> Another workaround is chrpath.
> 

which is my preferred dirty trick when I'm not enable to manage the
upstream messy building system...

-- 
Francesco P. Lovergine


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

Re: reporting BTS spam easily from Mutt

[Salvatore Bonaccorso]

Hi 

On Mon, Jan 07, 2008 at 03:29:21PM +0100, Amaya wrote:
> Hamish Moffatt wrote:
> > In case it's useful to anyone, here's a quick hack I put together for
> > easy BTS spam reporting from mutt.
> 
> That is incredibly useful, is tehre any similar tool to report spam
> delivered through the Debian Mailing Lists?
> 
> Sorry if this has been answered before, I am just starting to keep up
> with mail backlog.

In "Bits of the listmasters" in October 2007, there was some idea how
to help against spam on lists.

http://lists.debian.org/debian-devel-announce/2007/10/msg4.html

There Martin Zobel-Helas wrote the following:
---[snip]---
[...]
   * Report spam that gets to you through our filters to
 [EMAIL PROTECTED] Please leave all the headers
 untouched. The best method is to bounce (as in mutt) them. There is a
 plugin for thunder^Wicesomething to do that at
 http://mailredirect.mozdev.org/ . DO NOT do this automagically. If
 you want to help us, you must make personally sure that the things
 you report are REALLY spam.
[...]
---[snap]---

Is this, what you are looking for?

Best regards,
Salvatore


signature.asc
Description: Digital signature

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Paul Wise]

On Jan 8, 2008 1:32 PM, Raphael Geissert <[EMAIL PROTECTED]> wrote:

> Some time ago I noticed some packages were defining a RPATH on non i386
> architectures, notably amd64.

Is either of these planned?

* Make lintian.d.o process debs from architectures other than i386/all
* A way to put all these different QA tests (amd64 rpath, should be
arch all, anything else that may come up) on the PTS/DDPO?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: List of packages which should probably be Architecture: all

[Rafael Laboissiere]

* Raphael Geissert <[EMAIL PROTECTED]> [2008-01-02 13:17]:

> Rafael Laboissiere <[EMAIL PROTECTED]>
>tess (U)

Fixed: http://lists.debian.org/debian-devel-changes/2008/01/msg00693.html

Thanks for spotting this problem.

-- 
Rafael


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

Bug#459729: ITP: pyglet -- a cross-platform windowing and multimedia library for Python

[Michael Hanke]

Package: wnpp
Severity: wishlist
Owner: Michael Hanke <[EMAIL PROTECTED]>


* Package name: pyglet
  Version : 1.0~beta3
  Upstream Author : Alex Holkner <[EMAIL PROTECTED]>
* URL : http://www.pyglet.org
* License : BSD
  Programming Lang: Python
  Description : a cross-platform windowing and multimedia library for Python

Description stolen from webpage (not a proper long descr. yet):

pyglet provides an object-oriented programming interface for developing games
and other visually-rich applications for Windows, Mac OS X and Linux. Some of
the features of pyglet are: 
- No external dependencies or installation requirements. For most application
  and game requirements, pyglet needs nothing else besides Python, simplifying
  distribution and installation.
- Take advantage of multiple windows and multi-monitor desktops. pyglet allows
  you to use as many windows as you need, and is fully aware of multi-monitor
  setups for use with fullscreen games.
- Load images, sound, music and video in almost any format. pyglet can
  optionally use AVbin to play back audio formats


At the moment pyglet is included in the python-sympy package. As it can
be viewed as a pygame replacement sympy maintainers agree that it should
be packaged separately.

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

The final package will be maintained by the pkg-exppsy project on
alioth.



-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (600, 'testing'), (200, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-k7 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050


signature.asc
Description: Digital signature

Re: reporting BTS spam easily from Mutt

[Kumar Appaiah]

On Mon, Jan 07, 2008 at 03:29:21PM +0100, Amaya wrote:
> That is incredibly useful, is tehre any similar tool to report spam
> delivered through the Debian Mailing Lists?
> 
> Sorry if this has been answered before, I am just starting to keep up
> with mail backlog.

Well, the steps are simply:

1. Scroll to the message which is spam.
2. Type `b', write the address as [EMAIL PROTECTED]
3. Say yes.

I think a single keystroke can be scripted for this. I'll try later
tonight, though someone else is welcome to do this ahead of me. :-)

HTH.

Kumar
-- 
Kumar Appaiah,
458, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600 036


signature.asc
Description: Digital signature

Re: reporting BTS spam easily from Mutt

[Kumar Appaiah]

On Tue, Jan 08, 2008 at 04:26:30PM +0530, Kumar Appaiah wrote:
> macro index , "[EMAIL PROTECTED]"
> macro index , "[EMAIL PROTECTED]"

OK, the second index should be `pager'. And I just tested it on a real
spam with report-listspam@, and it works! :-)

Kumar
-- 
Kumar Appaiah,
458, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600 036


signature.asc
Description: Digital signature

Re: reporting BTS spam easily from Mutt

[Kumar Appaiah]

On Tue, Jan 08, 2008 at 12:41:23PM +0200, Alexander Schmehl wrote:
> Would be cool, if your script would then automatically detect, if the
> mail was received via bts or via a list and bounce it to the correct
> report address.

Er, that's too cool, but here's a simple one to start. Just add this
to your .muttrc:

macro index , "[EMAIL PROTECTED]"
macro index , "[EMAIL PROTECTED]"

Of course, change `,' to whatever key you want, and [EMAIL PROTECTED] to
[EMAIL PROTECTED] If I press `,', it asks me if I'm sure I
wish to bounce it, which is good to stop myself if I pressed `,' by
mistake.

This could be combined with some hook magic to detect the origin of
spam, but I'll think about that later. For now, this seems enough for me.

/me spanks myself for not having done this earlier.

HTH.

Kumar
-- 
Kumar Appaiah,
458, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600 036


signature.asc
Description: Digital signature

Re: reporting BTS spam easily from Mutt

[Alexander Schmehl]

Hi!

Am 8.1.2008 schrieb "Kumar Appaiah" <[EMAIL PROTECTED]>:

[  reporting spam to listmasters and bts admins ]

>I think a single keystroke can be scripted for this. I'll try later
>tonight, though someone else is welcome to do this ahead of me. :-)

Would be cool, if your script would then automatically detect, if the
mail was received via bts or via a list and bounce it to the correct
report address.

BTW:  Where should spam be reported, which was received via lists.d.o
from the bts, e.g. via the bugs-rc or wnpp list?


Yours sincerely,
  Alexander

Is Davide Puricelli MIA?

[Ivan Shmakov]

Does someone know if Davide Puricelli (evo at debian.org) is
MIA?

Apparently, the last upload by him was on 2007-06-10 [1].  I've
tried to communicate him last year, but didn't succeed.

I've mostly interested in the `chicken' package.  The last
version packaged for Debian is 2.5, and it seems that there're
enough Chicken extensions [2] that aren't compatible with that
version of Chicken anymore.

[1] http://packages.qa.debian.org/x/xchat/news/20070610T154706Z.html
[2] http://galinha.ucpel.tche.br:8080/Eggs%20Unlimited


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

netconf control socket protocol: rfc822, xml-rpc, or dbus

[martin f krafft]

Hi there,

As you may know, netconf[0] sports a control socket with which you
can control a running instance of the daemon. The idea is that tools
like /sbin/ifup then are nothing more than clients of this socket,
issuing the right commands to the daemon process.

0. http://netconf.alioth.debian.org/

Currently, the netconf control socket is implemented using,
a pseudo-rfc822-based protocol (see [1] for some information).

1. http://git.debian.org/?p=netconf/netconf.git;a=blob;f=doc/control_socket.txt

Many people have suggested using dbus for this, but I always refused
because I did not want the dependency. I always wanted to make dbus
optional, i.e. provide netconf-dbus which, when installed, links
netconf in with the dbus infrastructure. However, that would be
independendent of the control socket, for which I still need
a protocol.

While working on Ikiwiki, it dawned on me that I really ought to be
using XML RPC for this [2]. Why? Because it's already
there to do exactly the kind of thing I am doing, and standardised.
Furthermore, dbus *is* XML RPC.

2. 
http://lists.alioth.debian.org/pipermail/netconf-devel/2007-October/000197.html

Python (netconf is currently prototyped in Python) makes XML RPC
trivial and does not introduce any new dependencies, except for
python-dbus, if I want to use dbus instead of simple XML RPC.

However, I do want (someone) to port netconf to C or C++ once I am
comfortable with the design. In order to parse XML with C/C++,
netconf would need to depend on e.g. libxmlrpc++0 or even
libdbus-1-3 - static linking is out of the question for I'd prefer
not to die a long and painful death caused by the security team.

I want netconf to eventually replace ifupdown and thus become part
of Debian's base system. Thus, I need to strive for minimal
dependencies, and thus the XML RPC library needed by a C/C++
incarnation of netconf is a thorn in my flesh.

Do you think that a libdbus-1-3 or libxmlrpc++0 dependency would be
a showstopper (given how dbus is becoming a standard)?

Or do you hold the opinion that there should be no question and dbus
is the way forward?

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
micro$oft windoze is like an air-conditioner:
it breaks down if you open a window.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: testing migration/autobuilding postgresql-filedump-8.2

[Michael Meskes]

On Mon, Jan 07, 2008 at 03:45:29PM +0100, Cyril Brulebois wrote:
> On 07/01/2008, Michael Meskes wrote:
> > Now the question ariss, what went wrong? And also of course could
> > someone please reschedule this package or do whatever is needed to get
> > this version into the archive.
> 
> Being built is insufficient, it has to be uploaded as well. If you want
> to contact the buildd admins, [EMAIL PROTECTED]

Yes, I know. But I though uploading was done automatically after
building. 

Michael

-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: netconf control socket protocol: rfc822, xml-rpc, or dbus

[Neil Williams]

On Tue, 2008-01-08 at 12:32 +0100, martin f krafft wrote:
> Hi there,
> 
> As you may know, netconf[0] sports a control socket with which you
> can control a running instance of the daemon. The idea is that tools
> like /sbin/ifup then are nothing more than clients of this socket,
> issuing the right commands to the daemon process.

Would it be possible to retain /sbin/ifup without the xmlrpc dependency
for embedded use?

dbus itself is becoming common in embedded situations but it would be
nice to have the option of not having to install it for very simple
networking devices.

> Many people have suggested using dbus for this, but I always refused
> because I did not want the dependency. I always wanted to make dbus
> optional, i.e. provide netconf-dbus which, when installed, links
> netconf in with the dbus infrastructure. However, that would be
> independendent of the control socket, for which I still need
> a protocol.

> Python (netconf is currently prototyped in Python)

(netconf itself isn't suitable for Emdebian for this reason - no python,
no perl {no Essential either}.)

> However, I do want (someone) to port netconf to C or C++ once I am
> comfortable with the design. In order to parse XML with C/C++,
> netconf would need to depend on e.g. libxmlrpc++0 or even
> libdbus-1-3 - static linking is out of the question for I'd prefer
> not to die a long and painful death caused by the security team.
> 
> I want netconf to eventually replace ifupdown and thus become part
> of Debian's base system.

Maybe if 'ifupdown' becomes an optional package instead of netconf
rather than losing ifupdown completely?

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: reporting BTS spam easily from Mutt

[Javier Fernandez-Sanguino]

> Am 8.1.2008 schrieb "Kumar Appaiah" <[EMAIL PROTECTED]>:
> Would be cool, if your script would then automatically detect, if the
> mail was received via bts or via a list and bounce it to the correct
> report address.

I do not suggest you report automatically, as you will not review
false positives. I actually put spam (as scored by SA) coming from the
BTS or mailing list in different folders (through procmail) and then
bounce those, after manually reviewing them, using a muttrc hook.

Regards

Javier


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

Re: reporting BTS spam easily from Mutt

[Alexander Schmehl]

Am 8.1.2008 schrieb "Javier Fernandez-Sanguino" <[EMAIL PROTECTED]>:

>I do not suggest you report automatically, as you will not review
>false positives.

That wasn't my plan; acutally listmasters strongly discourage from doing
so. Problem was, that I sorted spam to one directory, and was to lazy,
to dig out where I got it from, so I didn't reported it, but ...

> I actually put spam (as scored by SA) coming from the
>BTS or mailing list in different folders (through procmail) and then
>bounce those, after manually reviewing them, using a muttrc hook.

... sorting it into different directories would solve my problem, too. 
Thanks :)


Yours sincerely,
  Alexander, still being holiday lazy

Re: testing migration/autobuilding postgresql-filedump-8.2

[Marc 'HE' Brockschmidt]

Michael Meskes <[EMAIL PROTECTED]> writes:
> On Mon, Jan 07, 2008 at 03:45:29PM +0100, Cyril Brulebois wrote:
>> On 07/01/2008, Michael Meskes wrote:
>>> Now the question ariss, what went wrong? And also of course could
>>> someone please reschedule this package or do whatever is needed to get
>>> this version into the archive. 
>> Being built is insufficient, it has to be uploaded as well. If you want
>> to contact the buildd admins, [EMAIL PROTECTED]
> Yes, I know. But I though uploading was done automatically after
> building. 

Nope. After building, the build log gets sent to the buildd admin (and
the address feeding buildd.d.o). The admin needs to sign the .changes
included in the build log and send it back before the buildd
uploads.

Marc
-- 
BOFH #287:
Telecommunications is downshifting.


pgpO2kj3DavEU.pgp
Description: PGP signature

Re: netconf control socket protocol: rfc822, xml-rpc, or dbus

[Simon Richter]

Hi,

martin f krafft wrote:


However, that would be
independendent of the control socket, for which I still need
a protocol.


CORBA?

There is excellent support for it from C++, and since the interface 
definitions are compiled into stub code rather than including a full 
parser covering all eventualities, it doesn't generate too much overhead 
either.


   Simon


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

Re: netconf control socket protocol: rfc822, xml-rpc, or dbus

[Josselin Mouette]

Le mardi 08 janvier 2008 à 12:32 +0100, martin f krafft a écrit :
> Many people have suggested using dbus for this, but I always refused
> because I did not want the dependency. 

OK, now just have a look at what has been proposed, and please
reconsider this decision. The dbus library is 300 KB of installed size,
with no additional dependency. And more importantly, it was specifically
designed for this kind of applications, and currently there is no other
solution that will do it so well.

-- 
 .''`.
: :' :  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#459753: ITP: btk-core -- Biomolecule Toolkit C++ library

[Morten Kjeldgaard]

Package: wnpp
Severity: wishlist
Owner: Morten Kjeldgaard <[EMAIL PROTECTED]>


* Package name: btk-core
  Version : 0.8.1
  Upstream Author : Tim Robertson ([EMAIL PROTECTED]> 
* URL : http://sourceforge.net/projects/btk/
* License : GPL
  Programming Lang: C++
  Description : biomolecule Toolkit C++ library
   The Biomolecule Toolkit is a library for modeling biological
   macromolecules such as proteins, DNA and RNA. It provides a C++ interface
   for common tasks in structural biology to facilitate the development of
   molecular modeling, design and analysis tools.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: netconf control socket protocol: rfc822, xml-rpc, or dbus

[Chris Hanson]

On 1/8/08, martin f krafft <[EMAIL PROTECTED]> wrote:

> Furthermore, dbus *is* XML RPC.

Umm, no -- dbus is a custom binary protocol.


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

Re: RFH: How to debug FTBFS of erlang on sparc (UltraSPARC III)?

[Sergei Golovan]

On 1/8/08, Michael Shuler <[EMAIL PROTECTED]> wrote:
> On 01/07/2008 04:29 PM, Sergei Golovan wrote:
> > I can't build it on UltraSPARC III because I don't have an access to
> > it.
>
> Have you gotten access to a machine, Sergei?  If not, let me know, I
> would be happy to give you a login.  I successfully (slowly) built
> erlang_11.b.5dfsg-12 last night with pbuilder on my SunFire V120.

Which kernel version do you have installed? But anyway, if the build
is successful then this machine is useless for me :)

For now several builds were tried (on Solaris and Debian sid) and all
were successful. So, I suspect that the problem is in kernel on lebrun
and titan.

-- 
Sergei Golovan


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

Re: RFH: How to debug FTBFS of erlang on sparc (UltraSPARC III)?

[Michael Shuler]

On 01/08/2008 09:51 AM, Sergei Golovan wrote:

Which kernel version do you have installed? But anyway, if the build
is successful then this machine is useless for me :)


It is an Etch scratch box running 2.6.18-5-sparc64.  You could certainly 
upgrade/install anything on the box you would like to try to recreate 
the problem - it's all just 1's and 0's  ;)


--
Kind Regards,
Michael Shuler



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

Re: RFH: How to debug FTBFS of erlang on sparc (UltraSPARC III)?

[Michael Shuler]

On 01/07/2008 04:29 PM, Sergei Golovan wrote:

I can't build it on UltraSPARC III because I don't have an access to
it.


Have you gotten access to a machine, Sergei?  If not, let me know, I 
would be happy to give you a login.  I successfully (slowly) built 
erlang_11.b.5dfsg-12 last night with pbuilder on my SunFire V120.


--
Kind Regards,
Michael Shuler


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

Bug#459776: RFP: manpages-cs -- Czech manual pages

[Colin Watson]

Package: wnpp
Severity: wishlist

* Package name: manpages-cs
  Version : 0.17.20070905
  Upstream Author : hajma 
* URL : http://sweb.cz/tropikhajma/man-pages-cs/index.html
* License : various, but "all freely distributable"; presumably
same licence as original English versions;
clarification and/or research may be needed
  Description : Czech manual pages

Linux manual pages translated into Czech.

https://bugs.launchpad.net/ubuntu/+source/language-pack-cs/+bug/130377
includes a request for a package of Czech manual pages. I don't speak
Czech so I wouldn't be very good at maintaining this. Perhaps a
Czech-speaking developer could do so?

Thanks,

-- 
Colin Watson   [EMAIL PROTECTED]



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

Re: netconf control socket protocol: rfc822, xml-rpc, or dbus

[Pierre Habouzit]

On mar, jan 08, 2008 at 11:32:29 +, martin f krafft wrote:
> While working on Ikiwiki, it dawned on me that I really ought to be
> using XML RPC for this [2]. Why? Because it's already
> there to do exactly the kind of thing I am doing, and standardised.
> Furthermore, dbus *is* XML RPC.

  That's wrong, and XML-RPC *SUCKS*, as does most of the text-only
interfaces, when you want real-time events. DBus isn't such a bad way to
do things, it doesn't requires the daemon up and running to interact
with netconf, when netconf acts as a dbus server. I assume that it's
possible to write tools that directly hit your netconf server withouth
going through the dbus daemon, making it lightweight and a really good
solution even for small systems.

  And then for 0 cost, you see desktops being able to use your
procedures being routed automatically through the dbus daemon acting as a
proxy. At least it's what I grok reading [0]. And that's an invaluable
advantage as almost all desktop applications are slowly (or not _that_
slowly actually) migrating to DBus. It means that you'll provide a
tested robust known interface to people wanting to interface with you.


  [0] http://dbus.freedesktop.org/doc/dbus-tutorial.html#uses
  
http://www.freedesktop.org/wiki/Software/dbus#head-3aa36e8e37a29ac8985a5ae4f29a7a3d7dde231d

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


pgpu6Nt9PRYEn.pgp
Description: PGP signature

Re: Is Davide Puricelli MIA?

[Davide Puricelli]

On Tue, Jan 08, 2008 at 04:33:18PM +0600, Ivan Shmakov wrote:
>   Does someone know if Davide Puricelli (evo at debian.org) is
>   MIA?
> 
>   Apparently, the last upload by him was on 2007-06-10 [1].  I've
>   tried to communicate him last year, but didn't succeed.
> 
>   I've mostly interested in the `chicken' package.  The last
>   version packaged for Debian is 2.5, and it seems that there're
>   enough Chicken extensions [2] that aren't compatible with that
>   version of Chicken anymore.

Hi Ivan,

I'm not MIA (I still read -devel and I follow the project life), but
you're right, I'm not really active in the packages field.

I'm planning to update chicken in upcoming days, luckily it's not a huge
work, while I just asked Bart Martens to help me to comaintain xchat.

About your private email: I didn't reply because I had never received it!

Regards,
-- 
Davide Puricelli, [EMAIL PROTECTED]
Debian Developer: [EMAIL PROTECTED] | http://www.debian.org

Time looked like snow dropping silently into a black room -- Ray Bradbury


signature.asc
Description: Digital signature

Re: Is Davide Puricelli MIA?

[Ivan Shmakov]

> Davide Puricelli <[EMAIL PROTECTED]> writes:

 >> Does someone know if Davide Puricelli (evo at debian.org) is MIA?

 >> Apparently, the last upload by him was on 2007-06-10 [1].  I've
 >> tried to communicate him last year, but didn't succeed.

 >> I've mostly interested in the `chicken' package.  The last version
 >> packaged for Debian is 2.5, and it seems that there're enough
 >> Chicken extensions [2] that aren't compatible with that version of
 >> Chicken anymore.

 > Hi Ivan,

 > I'm not MIA (I still read -devel and I follow the project life),

Glad to hear it!

 > but you're right, I'm not really active in the packages field.

 > I'm planning to update chicken in upcoming days, luckily it's not a
 > huge work,

Well, Chicken now contains the debian/ directory, currently used
to facilitate the creation of unofficial `.deb's.  Perhaps you
shold review it.

I've suggested to link Chicken against the host version of PCRE
instead of the one supplied with Chicken itself [1].  Felix has
recently committed a patch [2] which simplifies the change.
Could this change be adopted for the official Debian package?

There's a small thread starting at [3] which points a few
problems with the current Debian packaging.  Could you please
review it?

I hope to make some patches (namely, `srcdir' support and
`CHICKEN_LIBRARY_PATH' support) soon, which may be of a
particular interest to the Debian users.

 > while I just asked Bart Martens to help me to comaintain xchat.

 > About your private email: I didn't reply because I had never
 > received it!

Strange enough.  Hope you'll receive this one.

[1] http://permalink.gmane.org/gmane.lisp.scheme.chicken.devel/516
[2] http://permalink.gmane.org/gmane.lisp.scheme.chicken.devel/526
[3] http://permalink.gmane.org/gmane.lisp.scheme.chicken.devel/474


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

Bug#459778: ITP: tinydyndns -- pop-before-dyndns service using djbdns

[Gerrit Pape]

tinydyndns is a simple but powerful dynamic DNS solution that uses
djbdns.  It cooperates with the djbdns package to publish dynamic IP
addresses authenticated through POP connections.  On successfully
authenticated POP connections, the tinydyndns-update program manipulates
tinydns' constant database "data.cdb" directly without rebuilding it;
this makes the dynamic DNS solution use very few system resources.
Using a POP service for authentication saves the work for installing
special client software, since POP clients are available for every
common network-aware operating system.  To provide the DNS and POP
service, tinydyndns cooperates with djbdns, qmail, and cvm.

The package is available through http://smarden.org/tinydyndns/

I'm the upstream author, copyright is the 3-clause BSD license.

Regards, Gerrit.


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

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Russ Allbery]

"Paul Wise" <[EMAIL PROTECTED]> writes:
> On Jan 8, 2008 1:32 PM, Raphael Geissert <[EMAIL PROTECTED]> wrote:

>> Some time ago I noticed some packages were defining a RPATH on non i386
>> architectures, notably amd64.

> Is either of these planned?

> * Make lintian.d.o process debs from architectures other than i386/all

It already takes over a day for Lintian to process the entire archive, so
I don't have any immediate plans to run it on more architectures unless we
can find some dramatic way to speed it up or find other places to run it
besides gluck.d.o.

One guess as to the speed hit at the moment is the man page checks, since
running man and groff is noticably slow.

> * A way to put all these different QA tests (amd64 rpath, should be
> arch all, anything else that may come up) on the PTS/DDPO?

This may be something that mole could do.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#458819: ITP: nettee -- a network "tee" program

[Joe Smith]

"Joel Franco" wrote in message news:[EMAIL PROTECTED]



HEY SPONSORS.. PLEASE LOOK NETTEE :)

I'm guessing that sponsors are waiting for your acknowledgment and 
correction of the issues mentioned in 
http://lists.debian.org/debian-mentors/2008/01/msg00034.html




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

Re: Correct spelling/capitalisation of project names

[Russ Allbery]

Stefano Zacchiroli <[EMAIL PROTECTED]> writes:
> On Mon, Jan 07, 2008 at 11:54:32PM -0800, Russ Allbery wrote:

>> BTW, the way that the Lintian spell-checking works is that it looks for
>> errors rather than looking for each word in a dictionary.  It has a
>> table of pairs of error and correct word.  So if you notice any common
>> misspelled words that Lintian doesn't catch, please let
>> debian-lint-maint know and we'll add them to the table.

> Regarding the Objective Caml language, whose acronym correct
> capitalization is "OCaml", please add the following:
> ocaml -> OCaml
> OCAML -> OCaml

Sure thing.  Added.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Raphael Geissert]

Cyril Brulebois wrote:
> On 08/01/2008, Michal Čihař wrote:
>> Adding --disable-rpath to configure might be easier solution for this
>> problem.
> 
> Another workaround is chrpath.
> 

According to some people (I remember reading something about it in -mentors)
chrpath doesn't always remove the rpath, although I can't confirm (I've
never used chrpath) it should be investigated.

Cheers,
Raphael Geissert


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

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Raphael Geissert]

Russ Allbery wrote:
> "Paul Wise" <[EMAIL PROTECTED]> writes:
>> On Jan 8, 2008 1:32 PM, Raphael Geissert <[EMAIL PROTECTED]>
>> wrote:
> 
>>> Some time ago I noticed some packages were defining a RPATH on non i386
>>> architectures, notably amd64.
> 
>> Is either of these planned?
> 
>> * Make lintian.d.o process debs from architectures other than i386/all
> 
> It already takes over a day for Lintian to process the entire archive, so
> I don't have any immediate plans to run it on more architectures unless we
> can find some dramatic way to speed it up or find other places to run it
> besides gluck.d.o.

What about running lintian once a day on the new/updated packages of every
day? that way the amount of time spent would be reduced and all the lintian
reports would have a delay of no more than one day.

This is the way I want DEHS to work (it currently takes some hours to
perform the archive wide run). At the moment it updates every day the new
packages and some times a month the big run takes place, but I also want to
add timestamps so a package isn't checked if the last check is less than ~3
days old. Something similar could be done to lintian.

> 
> One guess as to the speed hit at the moment is the man page checks, since
> running man and groff is noticably slow.

groff was the process taking the most part of the CPU when lintian processed
libwine-dev, is there anything that can be done to reduce this?

> 
>> * A way to put all these different QA tests (amd64 rpath, should be
>> arch all, anything else that may come up) on the PTS/DDPO?
> 
> This may be something that mole could do.
> 

I'd be happy to add that, although I don't think I will be running those
archive wide lintian checks on amd64 too often (specially because I have to
download all the .deb because my processor is an i386).


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

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Cyril Brulebois]

On 08/01/2008, Raphael Geissert wrote:
> According to some people (I remember reading something about it in
> -mentors) chrpath doesn't always remove the rpath, although I can't
> confirm (I've never used chrpath) it should be investigated.

Either it is misused, or bugs should be opened. The BTS currently shows
zaroo bugz.

-- 
Cyril Brulebois


pgpcENBqmU4xp.pgp
Description: PGP signature

Re: Bug#458819: ITP: nettee -- a network "tee" program

[Joel Franco]

Hi Joe,

I already have corrected that issues and i've send the answer but
appears that it didn't get there.

I will answer it again.

Thank you very much.


On Tue Jan 08 08 14:38, Joe Smith wrote:
>
> "Joel Franco" wrote in message news:[EMAIL PROTECTED]
>>
>>
>> HEY SPONSORS.. PLEASE LOOK NETTEE :)
>>
> I'm guessing that sponsors are waiting for your acknowledgment and 
> correction of the issues mentioned in 
> http://lists.debian.org/debian-mentors/2008/01/msg00034.html
>
>
>
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>

-- 
|
| Joel Franco Guzmán  .''`.
|  self-powered by   : :' :
|   Debian Linux `. `' 
|  `- 


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

Re: Correct spelling/capitalisation of project names

[Joey Hess]

Raphael Geissert wrote:
> Some weeks ago I noticed that some package descriptions incorrectly spell
> some project names, mainly because of capitalisation.
> For example GNOME is being spelt in some packages as Gnome, or simply gnome,
> when its right spelling: GNOME. Other project names such as Debian, KDE and
> Linux aren't being correctly capitalised.

I can't help but roll my eyes at this. There are so many valid reasons
to write "linux", "debian", or even "gnome" or "xerox"^W"kde". You can find
some good in examples in the descriptions of devscripts and debhelper 
("debian/", "debian package") which do not refer to a proper name and so
don't need to be capitalised.

> Neil Williams has requested me on #456495 to seek a concensus on this
> subject, hence the reason of this message.

Good luck!

-- 
SEE SHY JO


signature.asc
Description: Digital signature

Re: Correct spelling/capitalisation of project names

[Ben Finney]

Joey Hess <[EMAIL PROTECTED]> writes:

> Raphael Geissert wrote:
> > Some weeks ago I noticed that some package descriptions
> > incorrectly spell some project names, mainly because of
> > capitalisation. [...]
> 
> I can't help but roll my eyes at this. There are so many valid reasons
> to write "linux", "debian", or even "gnome" or "xerox"^W"kde".

If they're used to describe the project, they should be capitalised
properly.

If they're used to describe, e.g., a filename, command, or some other
literal text, it's more explicit to put those in quote marks so it's
clearer that it's *not* a proper name.

> You can find some good in examples in the descriptions of devscripts
> and debhelper ("debian/", "debian package") which do not refer to a
> proper name and so don't need to be capitalised.

The references to file names can be quoted to distinguish them from
proper names (and the proposed lintian check has been described to
pass on those instances).

Why do you think "debian package" is proper capitalisation? What does
the word "debian" refer to in that term, if not Debian?

-- 
 \"The right to search for truth implies also a duty; one must |
  `\  not conceal any part of what one has recognized to be true." |
_o__) —Albert Einstein |
Ben Finney


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

Re: Correct spelling/capitalisation of project names

[Joey Hess]

Ben Finney wrote:
> Why do you think "debian package" is proper capitalisation? What does
> the word "debian" refer to in that term, if not Debian?

A package format.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Raphael Geissert]

Russ Allbery wrote:
> 
> That's what we do now.  It takes about a half-hour, usually, or less.
> However, when I upgrade lintian.d.o to a new version of lintian, I have to
> regenerate the entire results for the whole archive to have consistent
> results, and I don't want that to take a week.
> 
> I suppose we could do something fancy where the archive is rebuilt in the
> background, but gluck doesn't have a lot of spare cycles as it is, and I'm
> not sure it's worth the effort at the moment to get coverage of the
> remaining platforms.

What about checking the amd64 packages by default?
a script could be written so those packages only available for i386 are also
included (and probably the same could be done for the other archs).

> 
>> groff was the process taking the most part of the CPU when lintian
>> processed libwine-dev, is there anything that can be done to reduce
>> this?
> 
> The only options I can think of are:
> 
>  1. Figure out some way to make groff faster.
>  2. Parse nroff in Perl and have lintian do the same checks internally.
>  3. Stop checking man pages.
> 
> None of the options are particularly appealing except 1, which is just
> really hard.  :)
> 



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

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Russ Allbery]

Raphael Geissert <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:

>> It already takes over a day for Lintian to process the entire archive,
>> so I don't have any immediate plans to run it on more architectures
>> unless we can find some dramatic way to speed it up or find other
>> places to run it besides gluck.d.o.

> What about running lintian once a day on the new/updated packages of
> every day? that way the amount of time spent would be reduced and all
> the lintian reports would have a delay of no more than one day.

That's what we do now.  It takes about a half-hour, usually, or less.
However, when I upgrade lintian.d.o to a new version of lintian, I have to
regenerate the entire results for the whole archive to have consistent
results, and I don't want that to take a week.

I suppose we could do something fancy where the archive is rebuilt in the
background, but gluck doesn't have a lot of spare cycles as it is, and I'm
not sure it's worth the effort at the moment to get coverage of the
remaining platforms.

> groff was the process taking the most part of the CPU when lintian
> processed libwine-dev, is there anything that can be done to reduce
> this?

The only options I can think of are:

 1. Figure out some way to make groff faster.
 2. Parse nroff in Perl and have lintian do the same checks internally.
 3. Stop checking man pages.

None of the options are particularly appealing except 1, which is just
really hard.  :)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Correct spelling/capitalisation of project names

[Steve Langasek]

On Tue, Jan 08, 2008 at 05:36:50PM -0500, Joey Hess wrote:
> Raphael Geissert wrote:
> > Some weeks ago I noticed that some package descriptions incorrectly spell
> > some project names, mainly because of capitalisation.
> > For example GNOME is being spelt in some packages as Gnome, or simply gnome,
> > when its right spelling: GNOME. Other project names such as Debian, KDE and
> > Linux aren't being correctly capitalised.

> I can't help but roll my eyes at this. There are so many valid reasons
> to write "linux", "debian", or even "gnome" or "xerox"^W"kde". You can find
> some good in examples in the descriptions of devscripts and debhelper 
> ("debian/", "debian package") which do not refer to a proper name and so
> don't need to be capitalised.

The latter *does* refer to a proper name and should be capitalized in
English.

Not that I'm going to spend my cycles chasing this issue, but if we're going
to pick nits, let's pick them with suitable diligence. :)

-- 
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: Correct spelling/capitalisation of project names

[Russ Allbery]

Joey Hess <[EMAIL PROTECTED]> writes:

> I can't help but roll my eyes at this. There are so many valid reasons
> to write "linux", "debian", or even "gnome" or "xerox"^W"kde". You can find
> some good in examples in the descriptions of devscripts and debhelper 
> ("debian/", "debian package") which do not refer to a proper name and so
> don't need to be capitalised.

Lintian won't complain about debian/rules.  I think the Debian in "debian
package" should be capitalized.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Correct spelling/capitalisation of project names

[Ben Finney]

Joey Hess <[EMAIL PROTECTED]> writes:

> Ben Finney wrote:
> > Why do you think "debian package" is proper capitalisation? What does
> > the word "debian" refer to in that term, if not Debian?
> 
> A package format.

That format is called "the Debian package format", surely?

-- 
 \   "There's no excuse to be bored. Sad, yes. Angry, yes. |
  `\Depressed, yes. Crazy, yes. But there's no excuse for boredom, |
_o__)   ever."  -- Viggo Mortensen |
Ben Finney


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

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Russ Allbery]

Raphael Geissert <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:

>> I suppose we could do something fancy where the archive is rebuilt in
>> the background, but gluck doesn't have a lot of spare cycles as it is,
>> and I'm not sure it's worth the effort at the moment to get coverage of
>> the remaining platforms.

> What about checking the amd64 packages by default?

I'm not sure that's better than checking i386 by default.  Each check
different things.  Right now, I would defend the chosen architecture for
the lintian checks on the grounds that it's the majority architecture
among our users.  If that changes, I'd be inclined to change lintian to
match.

> a script could be written so those packages only available for i386 are
> also included (and probably the same could be done for the other archs).

A script could be written to do all kinds of things.  :)  It's not a bad
idea, but I don't personally have time to do it; I don't think it's a high
priority compared to the other things already taking up my lintian time.
But if someone else wants to work on it (and probably on rewriting the
reporting harness in the process, and maybe fixing the long-standing
limitation in lintian that prevents it from checking contrib and
non-free), I'd be happy to review it.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Paul Wise]

On Jan 9, 2008 5:15 AM, Russ Allbery <[EMAIL PROTECTED]> wrote:

> > * Make lintian.d.o process debs from architectures other than i386/all
>
> It already takes over a day for Lintian to process the entire archive, so
> I don't have any immediate plans to run it on more architectures unless we
> can find some dramatic way to speed it up or find other places to run it
> besides gluck.d.o.

Perhaps lucas could use his access to Grid'5000 to do these lintian
runs when you upgrade lintian? I imagine that would take very little
time to do on the grid. There would need to be some way of merging the
results back to lintian.d.o and ensuring the same errors/warnings from
multiple architectures don't show up more than once, but that wouldn't
be too hard.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Russ Allbery]

"Paul Wise" <[EMAIL PROTECTED]> writes:

> Perhaps lucas could use his access to Grid'5000 to do these lintian runs
> when you upgrade lintian? I imagine that would take very little time to
> do on the grid. There would need to be some way of merging the results
> back to lintian.d.o and ensuring the same errors/warnings from multiple
> architectures don't show up more than once, but that wouldn't be too
> hard.

That part is relatively easy; the output is just the output of running
lintian, and all I have to do to usefully process the output is cat it all
together.  Although that's actually not true of running it across multiple
architectures; right now, the output format doesn't include architecture
information.

Oh, the other challenge with running lintian across multiple architectures
is that, at least in previous days, some things didn't work right unless
the binutils installed corresponded to the package architecture.  I wonder
if that's still true.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#459778: ITP: tinydyndns -- pop-before-dyndns service using djbdns

[Joel Franco]

On Tue Jan 08 08 16:44, Gerrit Pape wrote:
>tinydyndns is a simple but powerful dynamic DNS solution that uses
>djbdns.  It cooperates with the djbdns package to publish dynamic IP
>addresses authenticated through POP connections.  On successfully
>authenticated POP connections, the tinydyndns-update program manipulates
>tinydns' constant database "data.cdb" directly without rebuilding it;
>this makes the dynamic DNS solution use very few system resources.
>Using a POP service for authentication saves the work for installing
>special client software, since POP clients are available for every
>common network-aware operating system.  To provide the DNS and POP
>service, tinydyndns cooperates with djbdns, qmail, and cvm.
>
>The package is available through http://smarden.org/tinydyndns/
>
>I'm the upstream author, copyright is the 3-clause BSD license.
>
>Regards, Gerrit.
>
>

Hi Gerrit,

Your idea is good and simple.

I think that you could better the security side: you send the login/pass
in clear text and this is one of the worst aspect of the legacy POP3
protocol still very used, at least in Brasil. 

You could use SSL, for example. I don't know SSL in details, but i know
that it creates a encrypted service layer to encrypt the data and can
too do the authenticate part. You could use a assymetric key too.

I know that doing thinks like that, the simple solution could get
complicated, but IMHO, keep security in mind is important.

[]s

-- 
|
| Joel Franco Guzmán  .''`.
|  self-powered by   : :' :
|   Debian Linux `. `' 
|  `- 


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

Re: Bug#459627: ITP: libdmtx-dev -- header files for libdmtx

[Michael Biebl]

Todd A. Jacobs wrote:

Package: wnpp
Severity: wishlist
Owner: "Todd A. Jacobs" <[EMAIL PROTECTED]>


* Package name: libdmtx-dev
  Version : 0.4.0-codegnome.3
  Upstream Author : Mike Laughton <[EMAIL PROTECTED]>
* URL : http://www.libdmtx.org/
* License : LGPL
  Programming Lang: C
  Description : header files for libdmtx

The libdmtx package contains the shared libraries and command-line
utilities for creating/reading Data Matrix 2D barcode symbols. Install
this package if you need the C header files to include in your source
code.

NOTE: The packages are already available from the following repository:

deb http://www2.codegnome.org:59321/codegnome-debs/ sid contrib non-free
deb-src http://www2.codegnome.org:59321/codegnome-debs/ sid contrib non-free

and are just in need of a sponsor.


Surely you don't want to create three different source packages 
libdmtx,libdmtx-dev and libdmtx-utils.


What you want instead is one source package creating 3 binary packages.
As such its only necessary to file one ITP for the source package.
While at it, please name the libdmtx binary package libdmtx0, to match 
the SONAME.


Thanks,
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: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Guillem Jover]

On Tue, 2008-01-08 at 17:01:27 -0800, Russ Allbery wrote:
> Oh, the other challenge with running lintian across multiple architectures
> is that, at least in previous days, some things didn't work right unless
> the binutils installed corresponded to the package architecture.  I wonder
> if that's still true.

Not even with binutils-multiarch?

regards,
guillem


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

Re: Bug#459776: RFP: manpages-cs -- Czech manual pages

[Michal Čihař]

Hi

On Tue, 8 Jan 2008 16:15:57 +
Colin Watson <[EMAIL PROTECTED]> wrote:

> Package: wnpp
> Severity: wishlist
> 
> * Package name: manpages-cs
>   Version : 0.17.20070905
>   Upstream Author : hajma 
> * URL : http://sweb.cz/tropikhajma/man-pages-cs/index.html
> * License : various, but "all freely distributable"; presumably
> same licence as original English versions;
> clarification and/or research may be needed
>   Description : Czech manual pages
> 
> Linux manual pages translated into Czech.
> 
> https://bugs.launchpad.net/ubuntu/+source/language-pack-cs/+bug/130377
> includes a request for a package of Czech manual pages. I don't speak
> Czech so I wouldn't be very good at maintaining this. Perhaps a
> Czech-speaking developer could do so?

I tried to look at this, but I failed to download tarball. I will try
not to forget about this and retry sometimes later.

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: Bug#459627: ITP: libdmtx-dev -- header files for libdmtx

[Todd A. Jacobs]

On Wed, Jan 09, 2008 at 03:51:25AM +0100, Michael Biebl wrote:

> What you want instead is one source package creating 3 binary packages.

Which is what I did...but I grokked that I was supposed to create an ITP
for each .deb, not for each source package. If that was in error, I can
close all three bugs and reopen one for libdmtx0 only.

Is that what I should do, or is there some other way to handle it at
this point?

> While at it, please name the libdmtx binary package libdmtx0, to match 
> the SONAME.

Okay, so you'd like to see three packages named:

libdmtx0
libdmtx0-dev
libdmtx0-utils

Is that right? If so, I'd be glad to do it that way. If I've
misunderstood again, please clarify what's needed.

-- 
"Oh, look: rocks!"
-- Doctor Who, "Destiny of the Daleks"


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

Re: Bug#459776: RFP: manpages-cs -- Czech manual pages

[Michal Čihař]

owner 459776 !
retitle 459776 ITP: manpages-cs -- Czech manual pages
thanks

Hi

On Tue, 8 Jan 2008 16:15:57 +
Colin Watson <[EMAIL PROTECTED]> wrote:

> Package: wnpp
> Severity: wishlist
> 
> * Package name: manpages-cs
>   Version : 0.17.20070905
>   Upstream Author : hajma 
> * URL : http://sweb.cz/tropikhajma/man-pages-cs/index.html
> * License : various, but "all freely distributable"; presumably
> same licence as original English versions;
> clarification and/or research may be needed
>   Description : Czech manual pages
> 
> Linux manual pages translated into Czech.
> 
> https://bugs.launchpad.net/ubuntu/+source/language-pack-cs/+bug/130377
> includes a request for a package of Czech manual pages. I don't speak
> Czech so I wouldn't be very good at maintaining this. Perhaps a
> Czech-speaking developer could do so?

Okay, wget did the job and managed to download sources while I was at
lunch, so I will look at this package. Anyway upload will probably not
happen until utf-8 man pages will be supported.

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Russ Allbery]

Guillem Jover <[EMAIL PROTECTED]> writes:
> On Tue, 2008-01-08 at 17:01:27 -0800, Russ Allbery wrote:

>> Oh, the other challenge with running lintian across multiple
>> architectures is that, at least in previous days, some things didn't
>> work right unless the binutils installed corresponded to the package
>> architecture.  I wonder if that's still true.

> Not even with binutils-multiarch?

I'm not at all sure, actually.  That sure sounds like it would fix it.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#459627: ITP: libdmtx-dev -- header files for libdmtx

[Hamish Moffatt]

On Tue, Jan 08, 2008 at 07:30:30PM -0800, Todd A. Jacobs wrote:
> On Wed, Jan 09, 2008 at 03:51:25AM +0100, Michael Biebl wrote:
> > What you want instead is one source package creating 3 binary packages.
> Which is what I did...but I grokked that I was supposed to create an ITP
> for each .deb, not for each source package. If that was in error, I can
> close all three bugs and reopen one for libdmtx0 only.
> 
> Is that what I should do, or is there some other way to handle it at
> this point?

You can close the -dev and -utils bugs and retitle the libdmtx0 bug to
"ITP: libdmtx". See http://bugs.debian.org/ for instructions on how to
use the control interface to achieve this.

> Okay, so you'd like to see three packages named:
> 
> libdmtx0
> libdmtx0-dev
> libdmtx0-utils
> 
> Is that right? If so, I'd be glad to do it that way. If I've
> misunderstood again, please clarify what's needed.

Typically the -dev package should be just libdmtx-dev, unless you
anticipate that it will be necessary to have both libdmtx0-dev and
libdmtx1-dev in the archive at the same time in the future. This may be
true for -utils also.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: Bug#459627: ITP: libdmtx-dev -- header files for libdmtx

[Cyril Brulebois]

On 09/01/2008, Todd A. Jacobs wrote:
> Which is what I did...but I grokked that I was supposed to create an
> ITP for each .deb, not for each source package.

One per source package. You could eventually specify after the usual
fields and the descriptions that you're going to build binaries foo,
bar, baz, quux.

> If that was in error,

Yes,

> I can close all three bugs and reopen one for libdmtx0 only.

Or merge them, and retitle so that only one ITP for libdmtx (or dmtx,
depending on how upstream names it), and you're done.

> Okay, so you'd like to see three packages named:
> 
> libdmtx0
> libdmtx0-dev
> libdmtx0-utils
> 
> Is that right? If so, I'd be glad to do it that way. If I've
> misunderstood again, please clarify what's needed.

It'd rather be:
 - libdmtx0: versioning is important, see libpkg-guide[1] (which is a
 must-read, but not enough, when it comes to packaging
 libraries, which isn't trivial)
 - libdmtx-dev: unless you're going to maintain several versions of the
library at the same time, which you probably 
won't do,
there's no need to have libdmtxN-dev
 - libdmtx-utils: which usually contains tools that are only depending
  upon libdmtxN, where N varies.

 1. http://www.netfort.gr.jp/~dancer/column/libpkg-guide/

Cheers,

-- 
Cyril Brulebois


pgpDucZwdYKCn.pgp
Description: PGP signature

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Raphael Geissert]

Russ Allbery wrote:
> 
> Oh, the other challenge with running lintian across multiple architectures
> is that, at least in previous days, some things didn't work right unless
> the binutils installed corresponded to the package architecture.  I wonder
> if that's still true.
> 

What kind of problems occur?



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

Re: Is Davide Puricelli MIA?

[Bart Martens]

On Tue, 2008-01-08 at 16:47 +0100, Davide Puricelli wrote:
> On Tue, Jan 08, 2008 at 04:33:18PM +0600, Ivan Shmakov wrote:
> > Does someone know if Davide Puricelli (evo at debian.org) is
> > MIA?
> > 
> > Apparently, the last upload by him was on 2007-06-10 [1].  I've
> > tried to communicate him last year, but didn't succeed.
> > 
> > I've mostly interested in the `chicken' package.  The last
> > version packaged for Debian is 2.5, and it seems that there're
> > enough Chicken extensions [2] that aren't compatible with that
> > version of Chicken anymore.
> 
> Hi Ivan,
> 
> I'm not MIA (I still read -devel and I follow the project life), but
> you're right, I'm not really active in the packages field.
> 
> I'm planning to update chicken in upcoming days, luckily it's not a huge
> work, while I just asked Bart Martens to help me to comaintain xchat.

I can confirm that Davide is not MIA, and that Davide replies to e-mails
within reasonable time.  Davide and I agreed today to comaintain xchat.

Regards,

Bart Martens



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

Re: Bug#459776: RFP: manpages-cs -- Czech manual pages

[Christian Perrier]

Quoting Michal Čihař ([EMAIL PROTECTED]):

> Okay, wget did the job and managed to download sources while I was at
> lunch, so I will look at this package. Anyway upload will probably not
> happen until utf-8 man pages will be supported.


Please note that, in the past, the login and/or passwd packages had to
conflict with such manpages-* packages because both provide manpages
such as passd.1, passwd.5, etc.

shadow *has* Czech manpages:
expiry.1
faillog.5
faillog.8
gpasswd.1
groupadd.8
groupdel.8
groupmems.8
groupmod.8
groups.1
grpck.8
gshadow.5
id.1
lastlog.8
logoutd.8
nologin.8
passwd.5
shadow.5
su.1
vipw.8

Those are in an unknown shape but could be converted to PO format so
that a translator looks at them.

The same goes maybe for other manpages provided by this package and
that could also be provided in the native package(s).



signature.asc
Description: Digital signature