Re: Bug#560786: gdb: Please make the python dependency optional

[Ron]

Ok, let's see ...

On Mon, Dec 21, 2009 at 06:18:18PM -0500, Daniel Jacobowitz wrote:
> On Sun, Dec 20, 2009 at 03:30:20AM +1030, Ron wrote:
> > I do appreciate, and share, your concern for not bloating the archive
> > needlessly, but my concern is balancing that against the needs of small
> > Debian systems, where the extra deps this drags in are of themselves a
> > quite substantial and needless extra bloat.  They are considerably larger
> > than gdb is itself, and needing to put extra flash on a board, just to
> > install python, which the board itself will never use, hits a much harder
> > limit than an extra 4MB package in the archive would.
> 
> There is not just one GDB package in the archive.  Many platforms have
> two, and the build logic is tricky enough to produce all the variants
> already... I really don't see the justification for another binary.

Well I offered to provide a patch -- so I can put in some work to help
simplify the build logic too, if that's the pound of flesh this will
cost me ;)

> You've already said you don't have the space for GDB+Python.  So file
> a wishlist bug to split gdbserver out to its own package, and I'll do
> that for you happily.

I haven't seen anyone object to that idea yet, so we seem to have a
rough consensus that would be a good plan independently of any other
issues here, yeah.

> Then you don't need to put the detached debug
> info files on your target either.  If you are putting them on your
> target, well, that explains why you can't fit GDB!

"If I didn't have all that data which was actually useful to me, then
 I'd have plenty of space for whole subsystems I will never need ;?"
That's probably not the most productive argument we could entertain :)

But seriously, it's about resource budgeting.  When we design a new
product, we need to build in some slack space to allow for natural
growth and "incidentals".  So if we have to build in slack space for
python, then $omebody has to pay for that.  Because real memory costs
real money.  And chances are, that somebody, will actually be you.
Because we'll have sold our stuff to someone who sells you stuff ...
Now eventually, memory will be so plentiful and cheap that we can just
waste it on any old thing, but in the meantime we're still a few years
from that point yet.

That's my issue.  That's why I need "optional" things to stay optional.
Because when some other major tool decides to drag in ruby (or whatever)
for the same sort of extra fizz gdb gets from this, I need to be able
to tell one of you "thanks, but I don't need that today".  What I don't
need to hear is "oh but it was ok for gdb" from the other guys ...

If I can do that with python here.  ie. it becomes a Recommends or so,
then I'm totally happy.  I think ;


> > Ideally this should really be some sort of runtime dependency, otherwise
> > what happens when people also add perl, lua, ruby, etc. etc. bindings to
> > do the same thing as this python dep does?
> 
> It's not going to happen.  We (the GDB developers) spent a long time
> picking one language under the firm plan that we wanted exactly one.
> We don't want to fragment available GDB scripts by language; that
> defeats the point of making it scriptable.

That seems like a rather risky edict/assumption to make...  people
really do love their favourite languages.  But hypothetical talk
about egdb springing up is way off the issue I'm concerned with
right now, so I'm happy to steer clear of bringing this into it
any further :)


> >  - libgdb-dev appears to be unused, and itself recommends that it never
> >should be.  That's the size of 2 gdb .debs itself, so if you really
> >want to remain "archive neutral", we could trade it for a gdb-minimal
> >package, and wind up using less archive space in the deal.
> 
> It exists for the benefit of the Free Pascal IDE.  Also, it takes
> almost no additional build daemon time.

Ok.  If it's still needed, that's mostly what I was wondering.
Surely we can also do the "takes almost no additional buildd time" trick
with --without-python though, no?  It looked like only a couple of files
would get touched by that at all.  Did I miss something there?

Either way, this isn't like an extra OOo build we're asking for.

> > I've cc'd -devel, as others may have even better or simpler solutions,
> > but I'd appreciate your guidance on the best way to move forward with
> > solving this from here.
> 
> I just don't see why a solution to this is necessary in the archive.
> Nothing you've said has changed that.  Either we install gdbserver, or
> else you can just throw a GDB binary around from system to system.
> I don't think the range of systems which don't need and can't fit
> Python, but can fit a GDB executable (and its substantial RAM
> requirements, and the huge debuginfo files it needs to be useful)
> is very large.
> 
> Remote debugging is easy, and this is exactly what it's for.

The range of systems is however larger than what gdbserver is suit

Optimus Gnu-Linux

[Jonatan Dimotta]

I used the google traslator i think it is very good the traslation, but
forgive me if you don't understand something.
Most PC users when trying to learn about GNU / Linux are lost for several
reasons: many distributions, those who can recommend a number and the person
ends up not deciding any, rumors of bad shareability with some pieces of
hardware, the Select some distribution, the computer runs slower, and so
on.

I was working on this project quite some time but my knowledge is rather
limited (if not what I would done), even do private to make money with the
idea but after recalling the spirit of free software. This project is
basically an interactive free online service where the user enters the
website, run a wizard and it automatically detects the computer's hardware,
then the user chooses basic options such as programs, orientation of the
final operating system and optimized low, with the specific software for
your pc and the kernel compiled automatically. So that the final size of the
discharge may be much less than the current distrubuciones, more efficient
and easier. Also users who want to enter the world of GNU / Linux instead of
spending hours figuring out which distribution you choose, down one to your
specifications and ready.

In broader aspects is not only lower the kernel compiled automatically on
your pc, if not adjust and specify various areas to leverage resources to
maximum, point to Programs, Web browsers, desktop, disk partition,
orientation, etc. . This would include a program to install everything
automatically and an integrated program to this Web service, which can be
updated, recompiling the kernel if you purchase new hardware and see new
style similar to iTunes (say an example).

In the following site:
http://www.debian-mx.com/2008/07/linux-kernel-hasta-que-punto-monolitico-hasta-que-punto-microkernel/can
now see how the Linux kernel is growing to a critical point where it
is
becoming big, slow and heavy, even Linus Trovals believes that every day is
worse. (
http://alt1040.com/2009/09/linus-torvalds-considera-que-linux-es-grande-lento-y-pesado).
However, not only is the kernel, if not the services "as a person with a
pentium 3 and with just a decent video card you can install any of the major
current distributions taking up the bluetooth services enabled by default?
With this project by analyzing the PC before downloading the operating
system can eliminate a lot of programs and unnecessary services, such as
having bluetooth service enabled by default on a pentium 3 and / or have the
webcam working without being hours starting head trying to find drivers for
it. It could clarify the list of drivers and would universally sharable for
all distributions.

This new system should start as armed from the website. Where it should have
an intuitive, simple and 2.0. You can upload manuals to the degree of user
knowledge.
Respect to the wizzard, there is a page that detects the hardware:
http://cyri.systemrequirementslab.com/ could be based on this method and add
other steps such as:

Guidance and Services
Would you chose to start the computer type: Server, desktop, portable
storage, designed for any particular use (the study of music, multimedia,
etc.).. Here you can pre-set programs, though the intent of this project is
not for programs for each user if not optimizing resource efficiency Choose
software-as specific as possible eg Gimp desktop in Gnome.

GUI / Desktop
Recommend a type of desktop to the PC hardware but offer all the
alternatives. Even so modify any remaining basic and efficient, not wasting
resources on images to icons or buttons, several bars, panels, etc.. Without
ceasing to be aesthetically attractive and visually clean.

Partition Type
Currently unaware of ext4 and performance, but a few years ago was better
for large files partition reiserfs xfs and boys. It could be agreed and
using a certain partition to boot (grub, lilo, etc.) according to the
hardware features to recommend one.

Compilation
In the last stage of the wizard do not know if they could build a kernel and
armed with all the options and compiled, or if you have to download all
files in a program then compile everything in the installation.

One could add other steps but the best would be few simple steps.
Automatically detect the type of architecture. It goes without saying that
the site would be translated into several languages and software that is
down as much as possible in the language chosen.

I hope I have explained the idea well and that there are people interested
in developing it, know where to publish it because why start a blog and
publish it there (http://jonidimo.blogspot.com) and send to this list, do
not know whether to put forums or other pages and other languages. I await
your response even if my idea is stupid and impossible to do from now thank
you very much. Jonatan

Bug#564562: stdeb - update description

[Frank Lin PIAT]

package: stdeb
version: 0.5.0-1
Severity: wishlist

On Fri, 2009-10-09 at 14:21 +0200, Piotr Ożarowski wrote:
> Package: wnpp
> * Package name: stdeb
>   Description : Python to Debian source package conversion utility
> 
> stdeb produces Debian source packages from Python packages via a new
> distutils command, sdist_dsc. Automatic defaults are provided for the
> Debian package, but many aspects of the resulting package can be
> customized via a configuration file. An additional command, bdist_deb,
> creates a Debian binary package, a .deb file.

The new version 0.5 [1] contains some nice new(?) feature to create .deb
packages. The package description should be updated accordingly, I
suggest the one below.

Also, I think it is important that stdeb package description should
explicitly mention that .deb from Debian archive are preferred and
supported(2). I am not completely happy with the note I provided.

If the downloaded files aren't gpg/ssl signed, the package description
should mention it.

,--( proposed package description )---
| This package provide some tools to produces Debian packages
| from Python packages via a new distutils command, sdist_dsc. Automatic
| defaults are provided for the Debian package, but many aspects of the
| resulting package can be customized via a configuration file.
|
| * pypi-install will query the Python Package Index (PyPI) for a
|   package, download it, create a .deb from it, and then install
|   the .deb.
| * py2dsc will convert a distutils-built source tarball into a Debian
|   source package.
| Note: Only Python modules downloaded from Debian archive are supported
|   by Debian. Auto-converted packages may not install/work and may
|   requires manual fine tuning to reach Debian standards.
`-

Thanks,

Franklin


[1] 
http://mail.python.org/pipermail/python-announce-list/2009-December/008031.html
(2) This is why I CC'ed debien-devel

-- 
Can you master Open-source software? Prove it, write documentation.




--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Optimus Gnu-Linux

[Frank Lin PIAT]

Hello,

[This is my personal opinion...]

On Sun, 2010-01-10 at 06:17 -0300, Jonatan Dimotta wrote:

> This project is basically an interactive free online service where the
> user enters the website, run a wizard and it automatically detects the
> computer's hardware, then the user chooses basic options such as
> programs, orientation of the final operating system and optimized low,
> with the specific software for your pc and the kernel compiled
> automatically. So that the final size of the discharge may be much
> less than the current distrubuciones, more efficient and easier.

The recommended way to install Debian is to download the "Netinst",
which is 180MB. The webpage says:
| _Download_a_minimal_bootable_CD_image_:
| Are you sure you really need the full CDs? You can just get the basic
| installation system - it will download the rest of the distribution
| if and when needed during the installation.

> Also users who want to enter the world of GNU / Linux instead of
> spending hours figuring out which distribution you choose, down one to
> your specifications and ready. 

Quite off topic here. Debian only provide Debian material ;)
Jounalists, bloggers and Wikipedia could/should help choosing. A
dedicated website may help. You could suggest people at distrowatch.com

> In broader aspects is not only lower the kernel compiled automatically
> on your pc, if not adjust and specify various areas to leverage
> resources to maximum, point to Programs, Web browsers, desktop, disk
> partition, orientation, etc. . This would include a program to install
> everything automatically and an integrated program to this Web
> service, which can be updated, recompiling the kernel if you purchase
> new hardware and see new style similar to iTunes (say an example). 

Keep in mind that changing a computer isn't always planned. In real
life, people tend to change computer when the old one fails.

Debian provides flexible kernel, XWindow... that can adapt to lots of
different configuration without a change. Usually, you can simply move
the hard disk from the old machine to the new one, and voilà.

This is a feature I wouldn't give up, not even if I know that my
computer could be 10% faster with specifically crafted software.

(Observation/Myth: If you compare two computers, the faster being 10%
faster than the other, it means that that take 1 second on a slow
computer would take 0.9 second on the faster computer... Personally, I
wouldn't notice the difference. See Moore's law[1])

> In the following site:
> http://www.debian-mx.com/2008/07/linux-kernel-hasta-que-punto-monolitico-hasta-que-punto-microkernel/
>  can now see how the Linux kernel is growing to a critical point where it is 
> becoming big, slow and heavy, even Linus Trovals believes that every day is 
> worse.

Well, ok. Linus and kernel developers are facing a new challenge. I am
pretty sure they will face and fix it.

For the rest of your email, there are many good ideas. You are welcome
to implement it ;-)

Franklin

[1] http://en.wikipedia.org/wiki/Moore%27s_law


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Optimus Gnu-Linux

[Russell Coker]

On Sun, 10 Jan 2010, Jonatan Dimotta  wrote:
> However, not only is the kernel, if not the services "as a person with a
> pentium 3 and with just a decent video card you can install any of the
> major current distributions taking up the bluetooth services enabled by
> default? With this project by analyzing the PC before downloading the
> operating system can eliminate a lot of programs and unnecessary services,
> such as having bluetooth service enabled by default on a pentium 3 and / or
> have the webcam working without being hours starting head trying to find
> drivers for it. It could clarify the list of drivers and would universally
> sharable for all distributions.

I am writing this message on a Pentium-M laptop - which is essentially a 
1.7GHz version of the Pentium-3 core.

My mail server is a Xen DomU on a Celeron 2.4GHz.  The overall capacity of the 
system is less than some of the SMP P3 systems I used to run when a 1.3GHz P3 
was a good server CPU.

The chipset of most Desktop P3 systems will limit you to 512M of RAM.  This is 
the biggest limit on a P3.  I don't think that there are many things that you 
can't do with a typical P3 system that has been upgraded fully.

There are some things that can be improved, desktop environments tend to drag 
in some daemons that really should be optional - particularly if you have the 
installation of "recommends" enabled (the default).

But I don't think we need to change anything significantly unless we want to 
get decent performance on a system with less than 128M of RAM - which is 
considerably less than is typical of a P3.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package

[Xavier Roche]

Hi folks,

How to deal with a desktop-command-not-in-package lintian warning when a 
.desktop file in a "common" package B references a binary in package A ?


Typically the package A used to contain static/arch-independent data 
which was splitted to a B "common" package to comply with debian 
packaging rules (to limit the size of architecture-dependent packages).


Solution 1: consider the warning a false positive and ignore it
Solution 2: pull back the destop command in the arch-dependent package

(I can not reverse the dependencies, because A _do_ depends on data in B.)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package

[Benjamin Drung]

Am Sonntag, den 10.01.2010, 14:30 +0100 schrieb Xavier Roche:
> Hi folks,
> 
> How to deal with a desktop-command-not-in-package lintian warning when a 
> .desktop file in a "common" package B references a binary in package A ?
> 
> Typically the package A used to contain static/arch-independent data 
> which was splitted to a B "common" package to comply with debian 
> packaging rules (to limit the size of architecture-dependent packages).
> 
> Solution 1: consider the warning a false positive and ignore it
> Solution 2: pull back the destop command in the arch-dependent package

Solution 2 is the correct answer.

> (I can not reverse the dependencies, because A _do_ depends on data in B.)

First I thought it would be a strange warning, but then I understood it.
Imagine that you install only the data package B, which contains the
desktop file. Then you have a desktop icon, but you cannot launch the
application.

-- 
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package

[Ralf Treinen]

On Sun, Jan 10, 2010 at 03:15:30PM +0100, Benjamin Drung wrote:
> Am Sonntag, den 10.01.2010, 14:30 +0100 schrieb Xavier Roche:
> > Hi folks,
> > 
> > How to deal with a desktop-command-not-in-package lintian warning when a 
> > .desktop file in a "common" package B references a binary in package A ?
> > 
> > Typically the package A used to contain static/arch-independent data 
> > which was splitted to a B "common" package to comply with debian 
> > packaging rules (to limit the size of architecture-dependent packages).
> > 
> > Solution 1: consider the warning a false positive and ignore it
> > Solution 2: pull back the destop command in the arch-dependent package
> 
> Solution 2 is the correct answer.

For me solution 1 is also justified when putting the .desktop file into
the arch-dependent package. Since the arch-dependent package depends
on the common package lintian shouldn't complain, otherwise a
bug report against lintian might be in order.

> First I thought it would be a strange warning, but then I understood it.
> Imagine that you install only the data package B, which contains the
> desktop file. Then you have a desktop icon, but you cannot launch the
> application.

True, but this is really an exceptional case. I suspect the normal case is
that one installs both packages.

-Ralf.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package

[Xavier Roche]

Hi Ralf ,

Ralf Treinen a écrit :

For me solution 1 is also justified when putting the .desktop file into
the arch-dependent package. Since the arch-dependent package depends
on the common package lintian shouldn't complain


Well, at first glance I wanted to make the two packages cross-dependend 
(A depends on B and B depends on A) for force the installing of both 
packages at the same time. This was not a good idea, of course.



True, but this is really an exceptional case. I suspect the normal case is
that one installs both packages.


Yep, exactly. OTOH, I will just move the small desktop file in the 
arch-dependent one, which is going to spoil some additional bytes, but 
nothing too serious fortunately :)


The only consequence is a typical conflict when installing the new 
package because a file was moved from a package to another one, with 
dependency issues (something I already experienced):


installed:package A
installed:package B contains 
new:package A [new version]  contains 
new:package B [new version]

Typicall update step when updating A:
- A depends on B, will update B later
- remove A
- installing new A, but  already exist
==> FAIL

Playing with 'Conflicts: A (<= old), B (<= old)' and/or 'Replaces: A (<= 
old), B (<= old)' does not seem to do any good. Humm, I'm wondering if 
the "Let's ignore the minor lintian warning" is not the correct solution 
after all.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package

[James Vega]

On Sun, Jan 10, 2010 at 03:47:39PM +0100, Xavier Roche wrote:
> Ralf Treinen a écrit :
> >True, but this is really an exceptional case. I suspect the normal case is
> >that one installs both packages.
> 
> Yep, exactly. OTOH, I will just move the small desktop file in the
> arch-dependent one, which is going to spoil some additional bytes,
> but nothing too serious fortunately :)
> 
> The only consequence is a typical conflict when installing the new
> package because a file was moved from a package to another one, with
> dependency issues (something I already experienced):

One uses Replaces to indicate that there is a file conflict.

> installed:package A
> installed:package B contains 
> new:package A [new version]  contains 
> new:package B [new version]
> 
> Typicall update step when updating A:
> - A depends on B, will update B later
> - remove A
> - installing new A, but  already exist
> ==> FAIL

Package: A
Depends: B
Conflicts: B (<< newversion)
Replaces: B (<< newversion)

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


signature.asc
Description: Digital signature

Re: desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package

[Julien Cristau]

On Sun, Jan 10, 2010 at 15:47:39 +0100, Xavier Roche wrote:

> The only consequence is a typical conflict when installing the new
> package because a file was moved from a package to another one, with
> dependency issues (something I already experienced):
> 
> installed:package A
> installed:package B contains 
> new:package A [new version]  contains 
> new:package B [new version]
> 
> Typicall update step when updating A:
> - A depends on B, will update B later
> - remove A
> - installing new A, but  already exist
> ==> FAIL
> 
> Playing with 'Conflicts: A (<= old), B (<= old)' and/or 'Replaces: A
> (<= old), B (<= old)' does not seem to do any good. Humm, I'm
> wondering if the "Let's ignore the minor lintian warning" is not the
> correct solution after all.
> 
No.  You don't need any conflicts, you need
Replaces: B (<< new)
in the new A and upgrades will work just fine.

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package

[Xavier Roche]

Julien Cristau a écrit :

No.  You don't need any conflicts, you need
Replaces: B (<< new)
in the new A and upgrades will work just fine.


Yes, works fine, thanks! One more lintian warning removed :)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#564605: ITP: python-pysilc -- Python bindings for SILC

[Stefano Rivera]

Package: wnpp
Severity: wishlist
Owner: Stefano Rivera 


* Package name: python-pysilc
  Version : 0.4
  Upstream Author : Alastair Tse 
* URL : http://www.liquidx.net/pysilc/
* License : BSD
  Programming Lang: C
  Description : Python bindings for SILC

PySilc is a near-complete set of Python bindings for creating SILC clients
using the silc-toolkit. It allows developers to write simple bots and clients
for connecting to SILC servers.

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#564609: ITP: python-pyfiglet -- A Python port of the FIGlet specification

[Stefano Rivera]

Package: wnpp
Severity: wishlist
Owner: Stefano Rivera 


* Package name: python-pyfiglet
  Version : 0.4
  Upstream Author : Christopher Jones 
* URL : http://sourceforge.net/projects/pyfiglet/
* License : GPLv2
  Programming Lang: Python
  Description : A Python port of the FIGlet specification

FIGLet is a program that creates large characters out of ordinary screen
characters. It takes ASCII text and renders it in ASCII art fonts.
It can be used on the command line or as an Object Oriented driver
library in your own programs.

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#564608: ITP: python-aalib -- A set of bindings for AAlib, an ASCII art library

[Stefano Rivera]

Package: wnpp
Severity: wishlist
Owner: Stefano Rivera 


* Package name: python-aalib
  Version : 0.1
  Upstream Author : Jakub Wilk 
* URL : http://jwilk.net/software/python-aalib.html
* License : GPLv2
  Programming Lang: Python
  Description : A set of bindings for AAlib, an ASCII art library

AAlib is a portable ascii art graphics library.
Internally, it works like a graphics display, but the output is
rendered into gorgeous platform independent ascii graphics.

These are Python bindings for AAlib.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#564613: ITP: libtest-tcp-perl -- module to test TCP/IP programs

[Jonathan Yu]

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

* Package name: libtest-tcp-perl
  Version : 0.16
  Upstream Author : Tokuhiro Matsuno 
* URL : http://search.cpan.org/dist/Test-TCP/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to test TCP/IP programs

Test::TCP is a Perl test framework for TCP/IP programs, especially those
written in Perl. For example, to test a client or server written in Perl,
one simply specifies code to launch the server on an arbitrary port and
provides corresponding code to execute a client to connect to it.

This module also supports running multiple servers in the same test file.

NOTE: this is needed for Plack



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

开票找159 99 678 116 叶先生 彼

[dalgamigeciyosunuz]

רҵ´ú¿ª¸÷ÀàÕý¹æÆÕͨ.¹úË°·¢Æ± µãÊý´ÓÓÅ

ÁªÏµÈË:Ò¶ÏÈÉú

µç»°:159 99678 116

(ÈçÓдòÈÅ.¾´ÇëÁ½â)ÁÏ

Send instant messages to your online friends http://asia.messenger.yahoo.com 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#564615: ITP: libtest-requires-perl -- utility module for tests to check whether modules are available

[Jonathan Yu]

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

* Package name: libtest-requires-perl
  Version : 0.03
  Upstream Author : Tokuhiro Matsuno 
* URL : http://search.cpan.org/dist/Test-Requires/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : utility module for tests to check whether modules
are available

Test::Requires is a Perl module for tests written using Test::Builder that
simply checks to see if the module can be loaded. If loading the module fails
then this skips all tests in the file, rather than causing a complete failure
in module testing.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package

[Russ Allbery]

Ralf Treinen  writes:

> For me solution 1 is also justified when putting the .desktop file into
> the arch-dependent package. Since the arch-dependent package depends on
> the common package lintian shouldn't complain, otherwise a bug report
> against lintian might be in order.

I think it's mildly better to keep the *.desktop file with the binary.
It's not large, and that avoids problems if the binary package is removed
and the data package isn't for some reason.

That being said, that's not why Lintian is warning.  Lintian is warning
because structural limitations in Lintian don't give it any way of doing
cross-package queries.  In other words, while it's checking the binary
package, it has no idea what's in the data package.  There are multiple
open bugs about this, but it will require a significant rearchitecture to
address it (even in those cases where it can be addressed, which it can't
always).

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

My warning about Lenny

[Andrzej Borucki]

I am beginner in Linux. I install Debian 5.0.3 "Lenny". I have several warnings:
- in install I can't choose Gnome or Kde
- in installed system I can't choose between Gnome or Kde - is any possibility?
- I can't login as root to graphical environment, only is root terminal
- Debian pack 6 DVD but only first can be readed in installation
- no mkinitrd found (is needed to compile kernel)

Re: My warning about Lenny

[Martin Wuertele]

Hi!

Your questions are better asked on debian-u...@lists.debian.org - thus
CCing.

* Andrzej Borucki  [2010-01-10 19:58]:

> I am beginner in Linux. I install Debian 5.0.3 "Lenny". I have several 
> warnings:
> - in install I can't choose Gnome or Kde

"Graphical desktop environment" will install both, however you can go
without "Graphical desktop environment" and then install either gnome or
kde with aptitude, synaptics or whatever your preferred apt frontend is.

> - in installed system I can't choose between Gnome or Kde - is any 
> possibility?

If you installed "Graphical desktop environment" a graphical
login-manager is started and you should be able to switch "session" to
get either gnome or kde.

> - I can't login as root to graphical environment, only is root terminal

This is a feature. For security reasons you should never login as root
in a graphical environment. If you need to perform admin tasks as root
use tools like su, sudo, gksu,...

> - Debian pack 6 DVD but only first can be readed in installation

Did you verify the disks? You can use apt-cdrom to add the other disks
anytime when needed. Usually the first DVD is enough for average
installations.

> - no mkinitrd found (is needed to compile kernel)

This is depricated. If you want to bild your own kernel please use
make-kpkg from the kernel-package which builds your initrd with the
tools provided by initramfs-tools. For average installations it should
be necessary for you to roll your own kernel, if modules are missing you
might want to add them via module-assistant.

Yours
Martin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: My warning about Lenny

[Andrzej Borucki]

Thanks, 

> If you installed "Graphical desktop environment" a graphical
> login-manager is started and you should be able to switch "session" to
> get either gnome or kde.

How to install "Graphical desktop environment" ? I can't install find gde.

Is archive this list?

[Andrzej Borucki]

Exists archive debian-devel@lists.debian.org ?

Conditions to existing packages for transition into squeeze/stable

[Joachim Wiedorn]

Hello,

there are some packages with old Standards-Version, old debhelper
version and so on.

Who know the conditions to existing packages in lenny for the
transition into squeeze when it goes to stable? 

Or does all existing packages be accepted for the new stable 
if it is already in testing (which is the usual case)?

Fondest regards,
 Joachim Wiedorn


signature.asc
Description: PGP signature

Re: Is archive this list?

[Stefano Zacchiroli]

On Sun, Jan 10, 2010 at 09:16:04PM +0100, Andrzej Borucki wrote:
> Exists archive debian-devel@lists.debian.org ?

Yes, they are at http://lists.debian.org/debian-devel/

If you have further questions about how Debian lists work, please have a
read at the content stored at http://lists.debian.org/ , before posting
your question: it might have already been answered on the website :)

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Is archive this list?

[Steve Kemp]

On Sun Jan 10, 2010 at 21:16:04 +0100, Andrzej Borucki wrote:
> Exists archive debian-devel@lists.debian.org ?Steve

http://lists.debian.org/debian-devel/

Steve
--
http://www.steve.org.uk/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Is archive this list?

[Leo 'costela' Antunes]

Andrzej Borucki wrote:
> Exists archive debian-devel@lists.debian.org ?

I assume from your email that you are Polish, right?

This page might be of interest to you:
http://www.debian.org/international/Polish/index.pl.html

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Conditions to existing packages for transition into squeeze/stable

[Simon McVittie]

Joachim Wiedorn wrote:
> Who know the conditions to existing packages in lenny for the
> transition into squeeze when it goes to stable?

I think you're confused about the ways packages migrate between
releases. See (for instance):

http://www.debian.org/doc/FAQ/ch-ftparchives#s-testing

> Or does all existing packages be accepted for the new stable
> if it is already in testing (which is the usual case)?

Whatever packages are in squeeze (as testing) at the time it's released
will remain in squeeze (as stable). So: fix bugs in unstable, get the
fixed packages into testing (which is normally automatic), and they'll
automatically be in the next stable release.

Regards,
S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: My warning about Lenny

[Joey Hess]

Martin Wuertele wrote:
> > I am beginner in Linux. I install Debian 5.0.3 "Lenny". I have several 
> > warnings:
> > - in install I can't choose Gnome or Kde
> 
> "Graphical desktop environment" will install both

This is not the case in Debian 5.0. Nor was it the case with Debian 4.0.
Debian 3.1 (2005) was the last one to do that.

To install KDE, at the installer's boot menu, choose:

Advanced Options > Alternative desktop environments > KDE

Or, download the "KDE CD", which contains KDE and installs it
automatically.
http://cdimage.debian.org/debian-cd/5.0.3/i386/iso-cd/debian-503-i386-kde-CD-1.iso

Or, press Tab and add "tasksel/desktop=kde" to the kernel command line.

-- 
see shy jo


signature.asc
Description: Digital signature

Debian Packaging advancements

[Joachim Breitner]

[CC’ing debian-devel because this is partly a call for contributions :-]

Hi,

today, I continued in my quest to make a proper Debian package out of
Serna. For now, I ignored the issue of the convenience code copies in
the source code and focused on getting a properly buildable package. The
four really required 3rd party tarballs are shipped in debian/3rd.

http://git.nomeata.de/?p=serna.git;a=summary contains the current state.

I started to use git-dpm[1] for packaging. This means that my changes
against the upstream (which is SVN trunk, revision 139) is stored in
debian/patches:
http://git.nomeata.de/?p=serna.git;a=tree;f=debian/patches;hb=refs/heads/master
Some of those can probably applied to the SVN directory directly, such
as 0017-Working-exports.lst-even-if-list-is-empty.patch. The others
should be reviewd and improved – I’m not an experienced C++ hacker.
Especially the 64bit stuff is just a hack and needs to made working
generally.

The debian packages does not have build-dependencies yet. If someone
wants to help assemble the correct set of packages (using pbuilder and
trial’n’error, that would be appreciated).

The serna binary is installed into /usr/bin/, the rest is put
in /usr/lib/serna. The binary is compiled with rpath so that the bundles
libs can be put in /usr/lib/serna/lib. I tried hard to make serna accept
this, but the patch that I try to use does not seem to be sufficient.
Any comments welcome:
http://git.nomeata.de/?p=serna.git;a=blob;f=debian/patches/0020-Hardcode-usr-lib-serna-as-DataDir.patch;hb=HEAD

I also started to work on the debian/copyright file, which is naturally
a large beast. Again, help is appreciated:
http://git.nomeata.de/?p=serna.git;a=blob;f=debian/copyright;hb=HEAD

All in all I thought would have gotten further in one whole day, and
motivation is fading again. Contributions by others are a good way to
increase motivation again :-).

Good night,
Joachim

[2] http://git-dpm.alioth.debian.org/


-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

jcc and MIA maintainer

[Ludovico Cavedon]

Hi,

The jcc package [1] has been out of date for a long time.
Back in July 2009 I offered [2] to help with the package or adopt it,
but got no answer from the maintainer.

A couple of weeks ago I decided to upload it with a 10-days NMU (which
was anyway needed to fix a RC bug [3]), but still no feedback from the
maintainer.

Do anybody have info about him (in CC)?

I am willing to adopt the package (I also need to do a new upload soon
because now it is FTBFS on archs different from i386 and x86_64).
How am I supposed to proceed? Send all the info to the MIA team and keep
making 10-days NMUs until MIA orphans the package or the maintainer
replies? Or is in this case a take over acceptable?

Thanks,
Ludovico

[1] http://packages.qa.debian.org/j/jcc.html
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533486
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562405




signature.asc
Description: OpenPGP digital signature

Re: jcc and MIA maintainer

[Cyril Brulebois]

Ludovico Cavedon  (10/01/2010):
> How am I supposed to proceed? Send all the info to the MIA team and
> keep making 10-days NMUs until MIA orphans the package or the
> maintainer replies? Or is in this case a take over acceptable?

I'd suggest taking it over. If the previous maintainer comes back, you
can discuss collaborative maintenance. In the meanwhile, the package
is being taken care of.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#384428: xsensors needs "unclutter -noevents" otherwise %100 CPU

[Nanley Chery]

Using unclutter on xsensors without "-noevents" causes %100 CPU.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=384428

Looking at other reports online it seems that unclutter has this problem
with many gtk apps [1] and the fix? doesn't seem trivial. Should I
reassign this bug to unclutter, so that the maintainer can merge this
with the related unclutter bug [2] ?

Thanks.

[1] https://bugs.launchpad.net/ubuntu/+source/unclutter/+bug/385034 
http://www.mail-archive.com/fvwm-work...@lists.math.uh.edu/msg14134.html 
http://code.google.com/p/xmonad/issues/detail?id=45 
http://tech.groups.yahoo.com/group/links-browser/message/2145 

[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266118 


On Sun, 2010-01-10 at 17:32 +0100, Marc-Jano Knopp wrote: 
> quit
> 
> On Sun, 2010-01-10, at 16:08:27 (+0100), Nanley Chery wrote:
> > Please try again with version 0.60 as it provides support for these
> > chipsets.
> 
> Tried 0.60, and the problem still persists, although the load is not
> 100 % anymore, but 50 % on each of my 2 cpu cores (AMD64,
> 2 x 2.6 GHz). "-noevents" still prevents this behavior, with the
> potential problems noted my the original bug report (Emacs and maybe
> others).





-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: My warning about Lenny

[Frans Pop]

Martin Wuertele wrote:
> * Andrzej Borucki  [2010-01-10 19:58]:
>> I am beginner in Linux. I install Debian 5.0.3 "Lenny". I have several
>> warnings: - in install I can't choose Gnome or Kde
> 
> "Graphical desktop environment" will install both, however you can go
> without "Graphical desktop environment" and then install either gnome or
> kde with aptitude, synaptics or whatever your preferred apt frontend is.

That's not so, but has already been corrected by Joey.

>> - in installed system I can't choose between Gnome or Kde - is any
>> possibility?
> 
> If you installed "Graphical desktop environment" a graphical
> login-manager is started and you should be able to switch "session" to
> get either gnome or kde.

Or simply install just one or the other using either the correct tasks or 
the correct meta packages.
 
>> - Debian pack 6 DVD but only first can be readed in installation
> 
> Did you verify the disks? You can use apt-cdrom to add the other disks
> anytime when needed. Usually the first DVD is enough for average
> installations.

apt-cdrom is only useful *after* the installation, but Debian Installer 
itself also supports installing from multiple CDs or DVDs. It will ask if 
you want you scan additional CD/DVDs after you have entered the root 
password and the info for the first user account.

Cheers,
FJP


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

New GMP version 5.0.0 available in experimental: please test

[Steve M. Robbins]

Upstream released a new GMP version 5.0.0 with a scary-sounding
caveat:

The 5.0.0 release contain a very large amount of new code, and
countless improvements to existing code, please see below for the
complete list.  No past GMP release has contained more new code
than 5.0.0.  Most of the new code is at the "mpn level", i.e., the
low-level used by other part of the library.

CAUTION: The amount of new code means that there might be more
bugs in this release than in most GMP releases in the past.  We
therefore release the stable GMP 4.3.2 at about the same time as
this release.  If you are concerned about possible bugs in the
present release, consider using GMP 4.3.2 instead. [...]

So I uploaded GMP 4.3.2 to unstable and 5.0.0 to experimental.

It would be helpful to have some folks (GMP power users
especially) try out 5.0.  Feel free to report bugs upstream
(I follow gmp-bugs), or to the BTS.

I've been using 5.0 for a day and haven't seen any ill
effects.  Please let me know your experience, good or bad.

Thanks,
-Steve


signature.asc
Description: Digital signature