Usedcarlease.com April Specials / E350s / CLK500s / CLK350s / Corvettes / CL500s / BMW 3 Series

[andrew]

Newsletter







Make 
  us an offer on Ebay. 

  



  
   

  
 
  
  
   
  
 
  
  

  
   
 


 
 
 


 
 
 


 
 
 


 
 
 
  

  
  
To 
  unsubscribe, please click here.
Company Name, Address and Contact Details
  
  

  



  
  



  


You are receiving this message because you have opted in to the 
UsedCarLease.com Specials list. To unsubscribe, please follow this link: 

Re: Should -dev packages providing .pc files depend on pkg-config?

[Bas Wijnen]

On Sun, Apr 06, 2008 at 03:18:58PM +0200, Martijn van Oosterhout wrote:
> On Sun, Apr 6, 2008 at 6:48 AM, Simon Richter <[EMAIL PROTECTED]> wrote:
> >  The use case here are people downloading a tarball and building that.
> >  These people are going to use a prebuilt configure script and expect the
> >  library to be found by it if the -dev package is installed.
> 
> Then the configure script should do:
> 
> Checking for pkg-config no
> ERROR: Please install pkg-config
> 
> It's not the dev package's responsibility to ensure gcc/g++/binutils
> are installed, I beleive the same applies to pkg-config.

It sounds like you're suggesting to add pkg-config to build-essential?
Because that's the reason that the -dev package doesn't depend on them.
It does depend on other library's -dev packages that it needs to compile
programs, for example.  Installing a -dev package and its depends
(including the implicit build-essential dependency because it's about
building things) should be enough to build a program with the library.

The question is, can a -dev package be used for its main function
(building programs with the library) without pkg-config?  IMO that
depends on the maintainer[1].  If the maintainer defines that pkg-config is
the only supported[2] way to use the library, then it should be a Depends.
If the .pc file is shipped as a service to the user, but building
without it is supported as well, then it should not be a Depends, but
possibly a Suggests or Recommends, depending on the exact situation.

Thanks,
Bas

[1] Here, "the maintainer" is a combination of upstream and the Debian
maintainer.  In most cases, upstream's policy will be used unchanged
by the Debian maintainer, but if the Debian maintainer chooses to
diverge from it, then the new policy is what counts.  That is, if
the Debian maintainer chooses to only support pkg-config, then
that's how it is, even if upstream supports building without it as
well.  And if upstream doesn't support anything else, but the Debian
maintainer does (and thus becomes upstream for that part of the
package), then that's how it is.  In other words, the Debian
maintainer defines the rules for the Debian package and in most
cases he/she will copy upstream's policy.

[2] And for clarity, if building without pkg-config is "supported" is a
non-technical thing.  It consists of a statement from the maintainer
about the issue.  The idea is that when it's supported, it will
continue to work in newer versions (at least for some time).  It has
nothing to do with whether or not it will work with the current
version.

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: too many conflicts/replaces

[Martin Schröder]

2008/4/4, Nikita V. Youshchenko <[EMAIL PROTECTED]>:
> Martin Schr?der wrote:
>  > I'm trying to create a package that will when installed automatically
>  > replace all TeX packages on the system with our version of TeX.
>
> Don't all debian tex packages depend, directly or indirectly, on tetex-base
>  or texlive-base? You probably could create your own -base package that
>  conflicts with those, and then pre-depend on it?

And then I'd get a conflict when installing that package. :-( I don't want
any additional user interaction.

Best
   Martin


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

Re: too many conflicts/replaces

[Nikita V. Youshchenko]

> 2008/4/4, Nikita V. Youshchenko <[EMAIL PROTECTED]>:
> > Martin Schr?der wrote:
> >  > I'm trying to create a package that will when installed
> >  > automatically replace all TeX packages on the system with our
> >  > version of TeX.
> >
> > Don't all debian tex packages depend, directly or indirectly, on
> > tetex-base or texlive-base? You probably could create your own -base
> > package that conflicts with those, and then pre-depend on it?
>
> And then I'd get a conflict when installing that package.

Why?

Won't apt-get/aptitude handle proper removal/installation actions for you?


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

Re: Restart automatic build

[Aurelien Jarno]

Ludovico Cavedon a écrit :
> Hi,
> automatic build of wengophone [1] on arm failed because of a GCC
> internal compiler error.

Package given-back.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: too many conflicts/replaces

[Nikita V. Youshchenko]

> 2008/4/7, Nikita V. Youshchenko <[EMAIL PROTECTED]>:
> > > 2008/4/4, Nikita V. Youshchenko <[EMAIL PROTECTED]>:
> >  > > Martin Schr?der wrote:
> >  > >  > I'm trying to create a package that will when installed
> >  > >  > automatically replace all TeX packages on the system with our
> >  > >  > version of TeX.
> >  > >
> >  > > Don't all debian tex packages depend, directly or indirectly, on
> >  > > tetex-base or texlive-base? You probably could create your own
> >  > > -base package that conflicts with those, and then pre-depend on
> >  > > it?
> >  >
> >  > And then I'd get a conflict when installing that package.
> >
> > Why?
> >
> >  Won't apt-get/aptitude handle proper removal/installation actions for
> > you?
>
> If I do this:
> 
> Conflicts: texlive-common
> 
> I get this:
> 
> [EMAIL PROTECTED]:~$ LANG=C sudo dpkg --dry-run -i
> /tmp/qstex-1.0.0-4-i386.deb dpkg: regarding /tmp/qstex-1.0.0-4-i386.deb
> containing qstex:
>  qstex conflicts with texlive-common
>   texlive-common (version 2007-10) is present and installed.
> dpkg: error processing /tmp/qstex-1.0.0-4-i386.deb (--install):
>  conflicting packages - not installing qstex

Sure.
Try istead this:

- mkdir /var/lib/packages

- copy all your debs to /var/lib/packages

- (cd /var/lib/packages && dpkg-scanpackages . /dev/null >Packages)
  ignore any messages about missing packages in override file

- add 'deb file:/var/lib/packages/' to /etc/apt/sources.list

- apt-get update

- try installing your packages with apt-get install


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

uscan download URL mangling

[Michal Čihař]

Hi

I'm trying to construct watch file for python-mpd. It can be downloaded
here: http://pypi.python.org/simple/python-mpd/, but the download URL
contains #md5=... part, which I would like to be removed when uscan
downloads the tarball. Is there some way to do this?

I currently have following, but it does not seem to work and the #md5=
is not removed.

opts="downloadurlmangle=s/#.*//" \
http://pypi.python.org/simple/python-mpd/ \

http://pypi.python.org/packages/source/p/python-mpd/python-mpd-(.*)\.tar\.gz#.*

Any ideas how to make this?

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


signature.asc
Description: PGP signature

Bug#474699: ITP: python-mpd -- Python MPD client library

[Michal Čihař]

Package: wnpp
Severity: wishlist
Owner: "Michal Čihař" <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: python-mpd
  Version : 0.2
  Upstream Author : J. Alexander Treuman <[EMAIL PROTECTED]>
* URL : http://www.musicpd.org/~jat/python-mpd/
* License : GPL
  Programming Lang: Python
  Description : Python MPD client library

An MPD (Music Player Daemon) client library written in pure Python.

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

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

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

iD8DBQFH+e+T3DVS6DbnVgQRAqJ+AKC8fGud9G4O6i1jWR1JqUMAamsfKwCg80h2
AAbV9HyT3sJ9tTsaL8B4UlE=
=19z0
-END PGP SIGNATURE-

princevb.com

[princevb . com]

äÍáå ÊÈäÔÑ ËÏì ÃäËì

http://www.princevb.com/vb/showthread.php?p=2180034#post2180034

ãÚáãÇÊ íÖÑÈä ØÇáÈÉ æíãÒÞä ãáÇÈÓåÇ ÃãÇã ÒãíáÇÊåÇ

http://www.princevb.com/vb/showthread.php?t=89397

ÃÕÛÑ ÚÑæÓíä Ýí ÇáÚÇáã ãÇ íÒÇáÇä Ýí ÇáãÑÍáÉ ÇáÇÈÊÏÇÆíÉ


http://www.princevb.com/vb/showthread.php?t=88995


ÇáÔÑØÉ ÇáÓÚæÏíÉ ÊæÞÝ 30 ÔÇÈÇ ÃÍíæÇ ÍÝáÉ ãÑíÈÉ Ýí ãßÉ

http://www.princevb.com/vb/showthread.php?t=89545


ÑæÓíÉ ÊÓÞØ ãä ÇáØÇÈÞ ÇáÊÇÓÚ.. Ëã ÊÕÚÏ áÊßãá ÇáÍÝá

http://www.princevb.com/vb/showthread.php?t=89221


åÇßÑÒ íÎÊÑÞæä ãæÞÚ ÇáÊáÝÒíæä ÇáÓÚæÏí æíØÇáÈæä ÈæÙÇÆÝ

http://www.princevb.com/vb/showthread.php?t=89465

ÇäÊÍÇÑ ÓíÏÉ ÑãÊ ÈäÝÓåÇ ãä ÇáÏæÑ ÇáÑÇÈÚ ÈãÓÊÔÝì Ýí ÇáØÇÆÝ

http://www.princevb.com/vb/showthread.php?t=89376


ÕÜñÜÜæÊ áãäÜÚ ÞÑÇÑ ÍÙÑ ÇáÞÑÇä Ýí åæáäÜÜÜÏÇ

http://www.princevb.com/vb/forumdisplay.php?f=106


ÈÜÜÇÈ ÇáÜÍÜÇÑåÜ ÇáÌÒÁ ÇáËÇáËÜ(3)ÜÜÜ

 http://www.princevb.com/vb/showthread.php?t=89481


{ 30 ÃÛäíÜÜå ÊÑÈßÜ ÌÏíÏ ÑÇÈÍ ÕÞÜÜÑ9ÅÈÑíá }

http://www.princevb.com/vb/showthread.php?t=89495


áÂíÝæÊßã ÑÞÕ ÇáÓÚæÏííä Ýí ÇáíÂÈÂÅä,,ÎÞÂÅÂÞ

 http://www.princevb.com/vb/showthread.php?t=89384


# ÅäÊí ÍíæÇäå #

http://www.princevb.com/vb/showthread.php?t=85572

ÒíäÈ ÇáÚÓßÑí ÊÞáÏ ßáÇã ÇáÓÚæÏííä

http://www.princevb.com/vb/showthread.php?t=88765

ÔÜÜÇÈ íÓÌÜÜÜÏ áÈÜÜäÊ ËÜÜÜã íäÊÍÜÜÜÑ

http://www.princevb.com/vb/showthread.php?t=82281


ÇáÚÇã

=> ( ÌÜÑÍ ÛÇÆÑ æ íäÒÝ ÈÔÜÜÏåÜ ) <=
http://www.princevb.com/vb/showthread.php?t=88969

ÎõÜÜáÜÜæóå ãõËöíÑóå ãóÚ ÔóÇÈ .,!
http://www.princevb.com/vb/showthread.php?t=88766

=
ÇáÝíÏíæ

[ ÅÓã Ì ÜÏíÏ ÙåÑ Ýí ÇáÜ Ú ÜÂáã ÇáÅÓáÂãí ]
http://www.princevb.com/vb/showthread.php?t=89239

ÕÜÜæÊ åÜÜÜäÜÏí íÞáÏ ÇáÝÑÇÚäÉ ...!!
http://www.princevb.com/vb/showthread.php?t=89160

ÅÛÊÕÇÈ ÓÜÜÚÜÜæÏíÉ
http://www.princevb.com/vb/showthread.php?t=81845

+++

ÊÜãÜ ÇáÃÝÊÊÂÍ <~ ãåã ÌÏÇð
ÇáÇÓáÇãí

http://www.princevb.com/vb/showthread.php?t=89147

+++
ÇáÇÎÈÇÑ

ãäÚ ÇáÓÝÑ ááãæÇØäíä ÇáããÊäÚíä Úä ÓÏÇÏ ÝæÇÊíÑ ÇáÎÏãÇÊ ÇáÚÇãå
http://www.princevb.com/vb/showthread.php?t=89128

ÃÕÛÑ ÚÑæÓíä Ýí ÇáÚÇáã ãÇ íÒÇáÇä Ýí ÇáãÑÍáÉ ÇáÇÈÊÏÇÆíÉ
http://www.princevb.com/vb/showthread.php?t=88995

ÝÊÇÉ ÈÍÇÆá ÊäÞÐ ØÝáÇ ãä ÇáÛÑÞ ÈÚÏ ÝÔá ÇáÑÌÇá
http://www.princevb.com/vb/showthread.php?t=89289

+++

ÇáäÞÇÔ

æáÏ Úãí ÚäÏí ÈÇáÇíãíá
http://www.princevb.com/vb/showthread.php?t=89320

+
ÇáÏÑÇãÇ
ÑÇÛÈ ÚáÇãå íÊÒæÌ Ú ÒæÌÊå ¿¿ ÕæÑ
http://www.princevb.com/vb/showthread.php?t=89304

+++

ÇáÕæÑ

ÝÇíÑæÓ ãæÌæÏ Èßá ÈíÊ
http://www.princevb.com/vb/showthread.php?t=89338

+

ÇáÌæÇá

Çä ÇáåÇÊÝ ÇáãØáæÈ áÇíãßä ÇáÇÊÕÇá Èå ÇáÇä .. ãíä¿
http://www.princevb.com/vb/showthread.php?t=89293

<

ÇáÊÕãíã

::|[ ÅáÇÑÓæá Çááå ]|::
http://www.princevb.com/vb/showthread.php?t=89083


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

ITP: etoys -- A media-rich model, simulation construction kit and authoring tool

[L. Redrejo]

Package: wnpp
Severity: wishlist
Owner: José L. Redrejo Rodríguez <[EMAIL PROTECTED]>

* Package name: etoys
  Version : 3.9-12
  Upstream Author : Viewpoints Research Institute
* URL : http://etoys.laptop.org/src/
* License : Apache
  Description : A media-rich model, simulation construction kit and
authoring tool

Squeak Etoys was inspired by LOGO, PARC-Smalltalk, Hypercard,
and starLOGO. It is a media-rich authoring environment with a
simple powerful scripted object model for many kinds of objects
created by end-users that runs on many platforms, and is free
and open source. It includes 2D and 3D graphics, images, text,
particles, pres-entations, web-pages, videos, sound and MIDI, etc.
It includes the ability to share desktops with other Etoy users
in real-time, so many forms of immersive mentoring and play can
be done over the Internet
.
This is the Squeak image developed for the OLPC project.


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Re: uscan download URL mangling

[Adam D. Barratt]

Michal Čihař wrote, Monday, April 07, 2008 11:16 AM


I currently have following, but it does not seem to work and
the #md5= is not removed.

opts="downloadurlmangle=s/#.*//" \
   http://pypi.python.org/simple/python-mpd/ \

http://pypi.python.org/packages/source/p/python-mpd/python-mpd-(.*)\.tar\.gz#.*


downloadurlmangle affects the URL that uscan downloads, not the filename 
that the result is saved under; for the latter you want filenamemangle:


opts="filenamemangle=s/^.*(python-mpd-.*?\.tar\.gz)#.*$/$1/" \
   http://pypi.python.org/simple/python-mpd/ \
   
http://pypi.python.org/packages/source/p/python-mpd/python-mpd-(.*?)\.tar\.gz#.*


There may be a better solution, but the above does work.

Regards,

Adam 



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

RFH: piuparts testing of the archive

[Lucas Nussbaum]

Hi,

[ for those who don't know piuparts: piuparts tests that .deb packages
(as used by Debian) handle installation, upgrading, and removal
correctly. It does this by creating a minimal Debian installation in a
chroot, and installing, upgrading, and removing packages in that
environment, and comparing the state of the directory tree before and
after. ]

Before the etch release, I did a few piuparts runs on all packages, and
filed the resulting bugs. I'd like someone to take over that task for
lenny.

What needs to be done is:
- run installation/removal/purge tests for all packages
- run upgrade tests for all packages in etch
- make changes to piuparts to fix false positives or reduce the number
  of failures by ignoring the less critical ones
- file all the bugs (many of those are RC)

The main problem is that there's currently ~4400 failures for the
installation/removal/purge tests. This includes issues about files being
added/removed/modified during the test, which are not as critical as the
tests where installation simply fails. But still.

Skills needed:
- python, since piuparts is written in python
- understanding of issues piuparts reports (mostly maintainer scripts
  stuff)
- ability to deal with large data sets and semi-automate the process by
  writing scripts

I can of course help by running piuparts on all packages with the
needed options, but that's only a small part of the task.

If you are interested, the logs for all packages are available on
http://people.debian.org/~lucas/logs/2008/04/07/ , and a dd-list of the
failing packages is available at
http://people.debian.org/~lucas/logs/2008/04/07-piuparts-ddlist.txt .
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: Bug#474699: ITP: python-mpd -- Python MPD client library

[Cyril Brulebois]

On 07/04/2008, Michal Čihař wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Michal Čihař" <[EMAIL PROTECTED]>
> 
> * Package name: python-mpd
>   Version : 0.2
>   Upstream Author : J. Alexander Treuman <[EMAIL PROTECTED]>
> * URL : http://www.musicpd.org/~jat/python-mpd/
> * License : GPL
>   Programming Lang: Python
>   Description : Python MPD client library
> 
> An MPD (Music Player Daemon) client library written in pure Python.

Hi,

how does it compare to python-mpdclient?

Cheers,

-- 
Cyril Brulebois


pgpss3SRhJIKJ.pgp
Description: PGP signature

Re: RFH: piuparts testing of the archive

[Kumar Appaiah]

On Mon, Apr 07, 2008 at 11:46:24AM +0200, Lucas Nussbaum wrote:
> What needs to be done is:
> - run installation/removal/purge tests for all packages
> - run upgrade tests for all packages in etch
> - make changes to piuparts to fix false positives or reduce the number
>   of failures by ignoring the less critical ones
> - file all the bugs (many of those are RC)
> 
> The main problem is that there's currently ~4400 failures for the
> installation/removal/purge tests. This includes issues about files being
> added/removed/modified during the test, which are not as critical as the
> tests where installation simply fails. But still.
> 
> Skills needed:
> - python, since piuparts is written in python
> - understanding of issues piuparts reports (mostly maintainer scripts
>   stuff)
> - ability to deal with large data sets and semi-automate the process by
>   writing scripts
> 
> I can of course help by running piuparts on all packages with the
> needed options, but that's only a small part of the task.
> 
> If you are interested, the logs for all packages are available on
> http://people.debian.org/~lucas/logs/2008/04/07/ , and a dd-list of the
> failing packages is available at
> http://people.debian.org/~lucas/logs/2008/04/07-piuparts-ddlist.txt .

I wish to add that I did an initial round of bug filing for this task
last December, and even supplied a few patches and some NMUs. But that
was when there were holidays. Later, since I tried to help out a bit
more in the gfortran transition and real life difficulties, I did not
pursue this goal with the same force.

My modus operandi for scripting was as follows. First, a general
perusal of the logs reveals that several of the reports are "duds". By
this, I don't mean that all of the problems are wrong, but it is just
that the problem manifests because of no fault of this package.

Please do point out mistakes below; I am not sure if everything I've
written is correct.

For example, if you check out the logs for libitpp6gf, proc is not
mounted, and there seems to be no other major issue.

For most other packages, the problem is because some dependencies
don't clean up properly. For example, for pkpgcounter, the problem
areas are:

  /etc/alternatives/djview   not owned
  /etc/cups  owned by: libcupsys2, cupsys
  /etc/cups/ssl  owned by: cupsys
  /etc/cups/ssl/server.crt   not owned
  /etc/cups/ssl/server.key   not owned
  /etc/sgml  owned by: xml-core, docbook-xml
  /etc/ssl   owned by: openssl
  /etc/ssl/private   owned by: openssl
[snipped for brevity]

Clearly, there's nothing in pkpgcounter's hands for fixing the above;
other packages have the cleaning up to do. So, I tried to parse the
logs to get the list of "not found" files, made a list of them, and
histogrammed them to find the file(s) which appeared the maximum
number of times in these logs. Then, I looked at which package(s) is
responsible for mopping up that file, and confirm that that package
manifests a similar behaviour. For example, in the above case, cupsys
and openssl seems to be among the packages causing pkpgcounter to fail
the piuparts test. Checking their piuparts logs, we do find that at
least cupsys doesn't clean up quite well before leaving. So, the bug
belongs to cupsys, and that should take care of pkpgcounter and the
tens (or, in some cases) hunderds of packages which display this
error.

In short, this is a VERY painful task, since I have to reproduce this
error before actually filing a bug. So, it is time consuming. Also,
some maintainers probed further and found cases where "disowning" a
package's file during upgrade causes dpkg to forget about it. These,
of course, are exceptions, and can be handled separately.

I hope this was useful. I am not in a position to give my scripts as
such, since they were written as dirty one off attempts to get the job
done. But in case someone wishes to rewrite scripts, I would be glad
to share with them some issues related to this. I also wish to
apologise for the fact that I am unable to take this task to
completion myself.

Thank you!

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


signature.asc
Description: Digital signature

Re: Bug#474699: ITP: python-mpd -- Python MPD client library

[Michal Čihař]

Hi

On Mon, 07 Apr 2008 11:32:14 +0200
Cyril Brulebois <[EMAIL PROTECTED]> wrote:

> how does it compare to python-mpdclient?

To be honest I did not compare it. But Sonata switched to this one and
they claim it is faster and better and I don't have reason not to trust
them.

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


signature.asc
Description: PGP signature

Re: uscan download URL mangling

[Michal Čihař]

Hi

On Mon, 7 Apr 2008 12:15:23 +0100
"Adam D. Barratt" <[EMAIL PROTECTED]> wrote:

> downloadurlmangle affects the URL that uscan downloads, not the filename 
> that the result is saved under; for the latter you want filenamemangle:
> 
> opts="filenamemangle=s/^.*(python-mpd-.*?\.tar\.gz)#.*$/$1/" \
> http://pypi.python.org/simple/python-mpd/ \
> 
> http://pypi.python.org/packages/source/p/python-mpd/python-mpd-(.*?)\.tar\.gz#.*

Thanks, I just thought that downloadurlmangle will affect both download
url and resulting filename.

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


signature.asc
Description: PGP signature

Re: Bug#474602: ITP: nikto -- web server security scanner

[Deepak Tripathi]

Hi ,
I had adopted nikto earlier ,but its takes libwhisker-perl which is not well
written and not in available in CPAN.
I don't think that libwhicker-perl has to be in debian .But if you find
sponsor go ahead with that.


Thanks
Deepak Tripathi

On Mon, Apr 7, 2008 at 11:38 AM, Vincent Bernat <[EMAIL PROTECTED]> wrote:

> OoO La  nuit ayant déjà recouvert  d'encre ce jour du  dimanche 06 avril
> 2008,  vers  23:41,  Javier Fernández-Sanguino  Peña  <[EMAIL PROTECTED]>
> disait:
>
> >> * Package name: nikto
>
> > Nikto was already packaged for Debian (etch provided version 1.35). It
> was
> > removed from Debian (see
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434392).
>
> > Please, include the debian information (including changelog history)
> from
> > the old Debian packages and use that as a starting point. I'm not sure
> how
> > many of the patches introduced in the Debian package are current, but it
> > would be best if you evolved from that instead of making new packages
> from
> > scratch.
>
> I first packaged nikto as an ITA but since packages.qa.debian.org seemed
> to think that having an ITA for a removed package was an error and since
> my ITA  was turned  back into a  removal request,  I have opened  an ITP
> instead.
>
> The package  is ready and is an  update of 1.35-2 which  was in unstable
> before removal.  It is  available on mentors.debian.net  if you  want to
> look at it:
>  http://mentors.debian.net/debian/pool/non-free/n/nikto/nikto_2.02-1.dsc
>
> Thanks for your feedback.
> --
> #ifdef STUPIDLY_TRUST_BROKEN_PCMD_ENA_BIT
>2.4.0-test2 /usr/src/linux/drivers/ide/cmd640.c
>



-- 
Deepak Tripathi
E3 71V3 8Y C063 (We Live By Code)
http://deepkatripathi.blogspot.com

Re: Bug#474602: ITP: nikto -- web server security scanner

[Vincent Bernat]

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
X-Sender: [EMAIL PROTECTED]
Received: from 193.252.118.2 [193.252.118.2] with HTTP/1.1 (POST); Mon, 07 Apr
2008 14:09:05 +0200
User-Agent: RoundCube Webmail/0.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit


On Mon, 7 Apr 2008 17:24:07 +0530, "Deepak Tripathi"
<[EMAIL PROTECTED]> wrote:
> Hi ,
> I had adopted nikto earlier ,but its takes libwhisker-perl which is not
> well
> written and not in available in CPAN.
> I don't think that libwhicker-perl has to be in debian .But if you find
> sponsor go ahead with that.

Hi!

I have packaged libwhisker2-perl which is in Debian now:
 http://packages.qa.debian.org/libw/libwhisker2-perl.html



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

Re: Restart automatic build

[Wouter Verhelst]

On Sun, Apr 06, 2008 at 11:59:39PM +0200, Cyril Brulebois wrote:
> On 06/04/2008, Ludovico Cavedon wrote:
> > automatic build of wengophone [1] on arm failed because of a GCC
> > internal compiler error.  Who should I ask to request a retry of the
> > build?
> 
> [EMAIL PROTECTED]

However, if the reason it failed was an internal compiler error, then
unless the bug in the compiler has been fixed, such a rebuild will not
serve any purpose; the package will fail to build on exactly the same
place.

There are three things you can do now, in order of preference:
- Fix the bug in the compiler, or provide enough information for someone
  to be able to do so (preferable, but not necessarily feasible),
- Try to find a workaround for the bug (e.g., sometimes changing the
  optimization level may help, or you could build-depend a specific
  compiler version on this architecture). Please coordinate this with
  the architecture's porters, on [EMAIL PROTECTED]
- If all else fails, ask the release managers to remove the arm package
  from testing, so that the new version of your package can migrate.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Re: [OT] Need old Packages.gz and Release Files

[Wouter Verhelst]

On Fri, Apr 04, 2008 at 12:44:38PM -0400, Lennart Sorensen wrote:
> Neat project.  I am not sure why being able to install 3.0r3 rather than
> 3.0r6 is necesarily very useful, but it is neat to have the choice.

To have reproducibility of installations, where such is necessary (e.g.,
software escrow situations).

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Re: Restart automatic build

[Cyril Brulebois]

On 07/04/2008, Wouter Verhelst wrote:
> However, if the reason it failed was an internal compiler error, then
> unless the bug in the compiler has been fixed, such a rebuild will not
> serve any purpose; the package will fail to build on exactly the same
> place.

Build failures can be due to lack of RAM, which especially happens on
arm buildds. The only way to get the package built is then to ask for a
rebuild, which hopefully will hit another box. I've already asked
Aurélien for several give-backs, following his own instructions.

No need to Cc me, thank you.

-- 
Cyril Brulebois


pgpv0EjFl9AWl.pgp
Description: PGP signature

mentors.debian.ORG?

[Christoph Haas]

Fellow earthicans...

as part of Google's Summer of Code we are working the "debexpo" project
which is supposed to create a software basis to run "social
network"-enhanced Debian package repositories. Think mentors.debian.net
with more social interaction like commenting on other people's packages
and perhaps moving part of the "RFS" communication on the debian-mentors
mailing list to the website. mentors.debian.net will start using that
software, too, then.

As soon as that part is done I would like to consider moving the service
to an official Debian machine. I've been sponsoring hardware for
mentors.debian.net for the last years. In my opinion the mentors server
has become an established resource and is used a lot. So I wondered what
has to be done to get it into debian.org hardware. I'd still be willing
to maintain it of course.

What would be needed:

- Python (>= 2.4)
- PostgreSQL
- 10 GB disk space (currently the source repository is just 2 GB)
- Crontab
- Apache, nging, lighttpd...

If everything turns out to work as we plan during our "debexpo" project
we will run as much as possible inside the Python web framework (Pylons)
so there is less to do on the shell and e.g. no proftpd involved
(uploads are supposed to happen through 'dput' and its ability to use
HTTP PUT). The application will work on mod_wsgi or mod_python on Apache
or standalone with its built-in web server that can be proxied by
mod_proxy to a local port.

This does not need to happen before fall 2008. But then it would be nice
if we could move it then. Who is in charge of the debian.org servers for
this matter?

Cheers
 Christoph
-- 
[EMAIL PROTECTED]  www.workaround.org   JID: [EMAIL PROTECTED]
gpg key: 79CC6586 fingerprint: 9B26F48E6F2B0A3F7E33E6B7095E77C579CC6586


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

Re: RFH: piuparts testing of the archive

[Amaya]

Lucas Nussbaum wrote:
> Before the etch release, I did a few piuparts runs on all packages,
> and filed the resulting bugs. I'd like someone to take over that task
> for lenny.

Whoever takes up this task, please keep #322762 updated about findings
related to the /usr/doc symlink transition.

I can't wait to see it go away :)

-- 
  ·''`.   Fuck your fascist beauty standards
 : :' :
 `. `' 
   `-Proudly running (unstable) Debian GNU/Linux


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

Bug#474748: ITP: ruby-pg -- PostgreSQL interface for Ruby

[Dmitry Borodaenko]

Package: wnpp
Severity: wishlist
Owner: Dmitry Borodaenko <[EMAIL PROTECTED]>


* Package name: ruby-pg
  Version : 0.7.9.2008.03.18
  Upstream Author : Jeff Davis <[EMAIL PROTECTED]> and others
* URL : http://rubyforge.org/projects/ruby-pg
* License : Ruby (GPL or BSD-like users choice), portions BSD
  Programming Lang: C, Ruby
  Description : PostgreSQL interface for Ruby

ruby-pg module allows Ruby programs to interface with the PostgreSQL
database engine. It supports the functions defined in libpq library.


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (70, 'testing'), (50, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=be_BY.UTF-8, LC_CTYPE=be_BY.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: Bug#474602: ITP: nikto -- web server security scanner

[Deepak Tripathi]

On Mon, Apr 7, 2008 at 5:39 PM, Vincent Bernat <[EMAIL PROTECTED]> wrote:

> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]> <
> [EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
> X-Sender: [EMAIL PROTECTED]
> Received: from 193.252.118.2 [193.252.118.2] with HTTP/1.1 (POST); Mon, 07
> Apr
>2008 14:09:05 +0200
> User-Agent: RoundCube Webmail/0.1
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: 8bit
>
>
> On Mon, 7 Apr 2008 17:24:07 +0530, "Deepak Tripathi"
> <[EMAIL PROTECTED]> wrote:
> > Hi ,
> > I had adopted nikto earlier ,but its takes libwhisker-perl which is not
> > well
> > written and not in available in CPAN.
> > I don't think that libwhicker-perl has to be in debian .But if you find
> > sponsor go ahead with that.
>
> Hi!
>
> I have packaged libwhisker2-perl which is in Debian now:
>  http://packages.qa.debian.org/libw/libwhisker2-perl.html
>
>
> ok then  you can go ahead and package the nikto

all the best .


-- 
Deepak Tripathi
E3 71V3 8Y C063 (We Live By Code)
http://deepkatripathi.blogspot.com

Bug#474749: ITP: sqlite-ruby -- SQLite interface for Ruby

[Dmitry Borodaenko]

Package: wnpp
Severity: wishlist
Owner: Dmitry Borodaenko <[EMAIL PROTECTED]>


* Package name: sqlite-ruby
  Version : 2.2.3
  Upstream Author : Jamis Buck ([EMAIL PROTECTED])
* URL : http://rubyforge.org/projects/sqlite-ruby
* License : BSD
  Programming Lang: C, Ruby
  Description : SQLite interface for Ruby

SQLite/Ruby module allows Ruby programs to interface with the SQLite
database engine.

Note that this module is NOT compatible with SQLite3.


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (70, 'testing'), (50, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=be_BY.UTF-8, LC_CTYPE=be_BY.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: Should -dev packages providing .pc files depend on pkg-config?

[Bernhard R. Link]

* Bas Wijnen <[EMAIL PROTECTED]> [080407 10:16]:
> > It's not the dev package's responsibility to ensure gcc/g++/binutils
> > are installed, I beleive the same applies to pkg-config.
> 
> It sounds like you're suggesting to add pkg-config to build-essential?
> Because that's the reason that the -dev package doesn't depend on them.

Here I have to contradict. No -dev package should ever depend on a
compiler or linker, even if that tool was not already in
build-essentials.

> The question is, can a -dev package be used for its main function
> (building programs with the library) without pkg-config?  IMO that
> depends on the maintainer[1].  If the maintainer defines that pkg-config is
> the only supported[2] way to use the library, then it should be a Depends.

If the maintainer decides this, it should be a Recommends, because it
would be found in all but unusual installations. If the Maintainer does
not think there is no sensible way in his eyes without some tool, it should
be at most a Suggests, if it is there at all.

> If the .pc file is shipped as a service to the user, but building
> without it is supported as well, then it should not be a Depends, but
> possibly a Suggests or Recommends, depending on the exact situation.

I think a Recommends would be far too strong here. A Recommends means
(has ment before apt and means with newer apt), that an user who does
not want it has to work actively against it getting installed.
A Recommends is by no way a lightweight "hey, you might like this, too".

Hochachtungsvoll,
Bernhard R. Link


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

Re: uscan download URL mangling

[Sandro Tosi]

Hi,

>  > opts="filenamemangle=s/^.*(python-mpd-.*?\.tar\.gz)#.*$/$1/" \
>  > http://pypi.python.org/simple/python-mpd/ \
>  > 
> http://pypi.python.org/packages/source/p/python-mpd/python-mpd-(.*?)\.tar\.gz#.*
>
>  Thanks, I just thought that downloadurlmangle will affect both download
>  url and resulting filename.

There is a much simpler way:

http://pypi.python.org/packages/source/p/python-mpd/python-mpd-(.*)\.tar\.gz

I've committed that url in the repository.

Cheers,
Sandro

-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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

debian-multimedia-keyring/debian-backports-keyring in official debian repository?

[Peter Jordan]

Hi,

why are the keyrings of debian-multimedia.org and debian backports not
in the official repository of debian?

At the moment you have to install untrusted keyrings before you can use
 these repositories.

PJ


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

Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?

[Luk Claes]

Peter Jordan wrote:
> Hi,

Hi

> why are the keyrings of debian-multimedia.org and debian backports not
> in the official repository of debian?
> 
> At the moment you have to install untrusted keyrings before you can use
>  these repositories.

Because they are no official Debian services (yet?).

Cheers

Luk


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

Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?

[Peter Jordan]

Luk Claes, 04/07/08 20:05:

> Peter Jordan wrote:
>> Hi,
> 
> Hi
> 
>> why are the keyrings of debian-multimedia.org and debian backports not
>> in the official repository of debian?
>>
>> At the moment you have to install untrusted keyrings before you can use
>>  these repositories.
> 
> Because they are no official Debian services (yet?).
> 

but the repositories does not need to be official debian services, only
the keyrings should be available over the official debian repository.

PJ


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

Re: Should -dev packages providing .pc files depend on pkg-config?

[Manoj Srivastava]

On Mon, 7 Apr 2008 18:20:56 +0200, Bernhard R Link <[EMAIL PROTECTED]> said: 

> * Bas Wijnen <[EMAIL PROTECTED]> [080407 10:16]:
>> > It's not the dev package's responsibility to ensure
>> > gcc/g++/binutils are installed, I beleive the same applies to
>> > pkg-config.
>> 
>> It sounds like you're suggesting to add pkg-config to
>> build-essential?  Because that's the reason that the -dev package
>> doesn't depend on them.

> Here I have to contradict. No -dev package should ever depend on a
> compiler or linker, even if that tool was not already in
> build-essentials.

Can you provide some rationale for this assertion? I can see why
 one might not tie the development tool very strongly with a particular
 compiler or compiler version, to allow a developer to use it with an
 alternative development tool, but I can see why one  may want to depend
 on a generic foo-lang-compiler-or-interpreter virtual package.

There is obviously a trade off here -- the need to the
 development package to be useful on installation, by ensuring that the
 tools required to use the package are also installed, versus the need
 to allow people to use the package with alternate developer tools. Ar
 there other considerations and use cases you have in mind?

I see recommends as a middle ground between a depends and a
 suggestions; can you articulate why this middle ground is unaceptable,
 as you assert above?

manoj
-- 
Ah, sweet Springtime, when a young man lightly turns his fancy over!
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?

[Luk Claes]

Peter Jordan wrote:
> Luk Claes, 04/07/08 20:05:
> 
>> Peter Jordan wrote:
>>> Hi,
>> Hi
>>
>>> why are the keyrings of debian-multimedia.org and debian backports not
>>> in the official repository of debian?
>>>
>>> At the moment you have to install untrusted keyrings before you can use
>>>  these repositories.
>> Because they are no official Debian services (yet?).
>>
> 
> but the repositories does not need to be official debian services, only
> the keyrings should be available over the official debian repository.

No, as that would imply that they are or at least will be official
Debian services and open the door for every archive provider to ask for
adding their key...

Cheers

Luk


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

Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?

[Leo "costela" Antunes]

Peter Jordan wrote:
> 
> but the repositories does not need to be official debian services, only
> the keyrings should be available over the official debian repository.

That may make some sense, but you do understand that by making them
available they wouldn't be any more official and any more trusted,
right? If we provide them as packages, it may be misunderstood for our
users as a recommendation, at best, which IMHO isn't worth the hassle.
Better to keep the key-adding just as manual as the sources.list editing.

This, of course, from the perspective that there is no official trust
relationship. If there is one that I'm unaware of, then by all means,
file an RFP!

Cheers

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



signature.asc
Description: OpenPGP digital signature

add my colugue

[Anjali Verma]

Hi
Everyone

Add new webmaster in our family. [EMAIL PROTECTED] *
**
she is my colugue add her. She is also link builder and seo.



kind regards
rakesh sony

Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?

[James Vega]

On Mon, Apr 07, 2008 at 08:14:19PM +0200, Peter Jordan wrote:
> but the repositories does not need to be official debian services, only
> the keyrings should be available over the official debian repository.

You can get the keys for those sites yourself and add them to the apt
keyring.  Backports.org even gives you explicit instructions on how to
do that.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

add my colleague

[anamika kumari]

Hi
Everyone

Add new webmaster in our family. [EMAIL PROTECTED]

she is my colleague add her. She is also link builder and seo.



kind regards
rakesh sony

Re: uscan download URL mangling

[Michal Čihař]

Dne Mon, 7 Apr 2008 18:32:36 +0200
"Sandro Tosi" <[EMAIL PROTECTED]> napsal(a):

> There is a much simpler way:
> 
> http://pypi.python.org/packages/source/p/python-mpd/python-mpd-(.*)\.tar\.gz
> 
> I've committed that url in the repository.

Thanks, I thought this won't work, so I even did no try it ;-). 

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


signature.asc
Description: PGP signature

Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?

[William Pitcock]

Hi,

On Mon, 2008-04-07 at 19:57 +0200, Peter Jordan wrote:
> Hi,
> 
> why are the keyrings of debian-multimedia.org and debian backports not
> in the official repository of debian?
> 
> At the moment you have to install untrusted keyrings before you can use
>  these repositories.

Because they are third party repositories and not affiliated in any
official way with the Debian project.

William


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

Re: Restart automatic build

[Ludovico Cavedon]

On Mon, Apr 7, 2008 at 12:57 PM, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 06, 2008 at 11:59:39PM +0200, Cyril Brulebois wrote:
>  > On 06/04/2008, Ludovico Cavedon wrote:
>  > > automatic build of wengophone [1] on arm failed because of a GCC
>  > > internal compiler error.  Who should I ask to request a retry of the
>  > > build?
>  >
>  > [EMAIL PROTECTED]

Thank you all for the answers!

>  However, if the reason it failed was an internal compiler error, then
>  unless the bug in the compiler has been fixed, such a rebuild will not
>  serve any purpose; the package will fail to build on exactly the same
>  place.

Yes, you are right. Anyway it might have been caused by some hadrware
fault or race condition.

>  There are three things you can do now, in order of preference:
>  - Fix the bug in the compiler, or provide enough information for someone
>   to be able to do so (preferable, but not necessarily feasible),

It the build is failing again (i.e. if the gcc bug is easily
reproducilbile) I will contact [EMAIL PROTECTED] for help in
getting information for reporting the bug.

Regards,
Ludovico


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

Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/07/08 13:20, Luk Claes wrote:
> Peter Jordan wrote:
>> Luk Claes, 04/07/08 20:05:
>>
>>> Peter Jordan wrote:
 Hi,
>>> Hi
>>>
 why are the keyrings of debian-multimedia.org and debian backports not
 in the official repository of debian?

 At the moment you have to install untrusted keyrings before you can use
  these repositories.
>>> Because they are no official Debian services (yet?).
>>>
>> but the repositories does not need to be official debian services, only
>> the keyrings should be available over the official debian repository.
> 
> No, as that would imply that they are or at least will be official
> Debian services and open the door for every archive provider to ask for
> adding their key...

Governments need silly all-encompassing rule sets to appear fair.
Debian doesn't.  IOW, adding debian-multimedia-keyring and
debian-backports-keyring doesn't mean that you've got to add every
other unofficial archive keyring, even though that archive's owner
screams "that's not fair!".

- --
Ron Johnson, Jr.
Jefferson LA  USA

We want... a Shrubbery!!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH+m6SS9HxQb37XmcRAlAyAJsEpZ7lo5n93H/zv+0ed8AB372SCQCg4J+b
3ViyXLNWSesIRcBSA0AtZ0E=
=xs1z
-END PGP SIGNATURE-


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

Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/07/08 13:53, William Pitcock wrote:
> Hi,
> 
> On Mon, 2008-04-07 at 19:57 +0200, Peter Jordan wrote:
>> Hi,
>>
>> why are the keyrings of debian-multimedia.org and debian backports not
>> in the official repository of debian?
>>
>> At the moment you have to install untrusted keyrings before you can use
>>  these repositories.
> 
> Because they are third party repositories and not affiliated in any
> official way with the Debian project.

But these two repositories are very popular with users.  A firm,
unambiguous disclaimer in the package's long description should be
adequate.

- --
Ron Johnson, Jr.
Jefferson LA  USA

We want... a Shrubbery!!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH+m70S9HxQb37XmcRAgQrAKCITFv/IibuTTtjBBw3BvimIqpHLwCggn7u
AH/wpg/+1MvgXYkrzcGjhUU=
=y+xL
-END PGP SIGNATURE-


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

Bug#474782: ITP: python-sphinx -- Tool for producing documentation for Python projects

[Mikhail Gusarov]

Package: wnpp
Severity: wishlist
Owner: Mikhail Gusarov <[EMAIL PROTECTED]>

* Package name: python-sphinx
  Version : x.y.z0.1.61950
  Upstream Author : Georg Brandl <[EMAIL PROTECTED]>
* URL : http://sphinx.pocoo.org/
* License : BSD
  Programming Lang: Python + C modules
  Description : Tool for producing documentation for Python projects

sphinx is a tool for producing documentation for Python projects, using
reStructuredText as markup language.

sphinx features:
 * HTML, CHM, LaTeX output,
 * Cross-referencing source code,
 * Automatic indices,
 * Code highlighting, using Pygments,
 * Extensibility. Existing extensions:
   - automatic testing of code snippets,
   - including doctrings from Pyhton modules.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (750, 'testing'), (700, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-ovz005 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=ru_RU.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: mentors.debian.ORG?

[Joerg Jaspert]

On 11348 March 1977, Christoph Haas wrote:

> This does not need to happen before fall 2008. But then it would be nice
> if we could move it then. Who is in charge of the debian.org servers for
> this matter?

Who would have guessed - its DSA, the admins of our machines.

-- 
bye, Joerg
 kde und tastatur? passt doch nicht mit dem nutzerprofil
"windepp" zusammen :)


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

Re: mentors.debian.ORG?

[Christoph Haas]

On Mon, Apr 07, 2008 at 09:28:19PM +0200, Joerg Jaspert wrote:
> On 11348 March 1977, Christoph Haas wrote:
> 
> > This does not need to happen before fall 2008. But then it would be nice
> > if we could move it then. Who is in charge of the debian.org servers for
> > this matter?
> 
> Who would have guessed - its DSA, the admins of our machines.

Sounds logical. But do I just bug any DSA asking for resources and
that's it? No bribery? No formal process? Very good. I'll try that as
soon as we are ready then. I just have no experience with Debian
machines except logging into them user-wise.

Cheers
 Christoph
-- 
[EMAIL PROTECTED]  www.workaround.org   JID: [EMAIL PROTECTED]
gpg key: 79CC6586 fingerprint: 9B26F48E6F2B0A3F7E33E6B7095E77C579CC6586


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

Re: Bug#474699: ITP: python-mpd -- Python MPD client library

[J. Alexander Treuman]

On Mon, Apr 07, 2008 at 11:32:14AM +0200, Cyril Brulebois wrote:
> how does it compare to python-mpdclient?

python-mpdclient (better known outside Debian as py-libmpdclient2, or
just mpdclient2) is old, unmaintained, relatively slow, a bit ugly,
contains known bugs, and lacks support for some major features of the
MPD protocol.

I wrote python-mpd with the intention of maintaining it as a replacement
which fixes many of these issues.  It's faster (by as much as 2x in some
benchmarks), cleaner, more strict (and thus less prone to strange bugs),
and implements every command supported by the latest MPD protocol.

Although it's not 100% API compatible, porting existing clients should
be relatively easy.  In fact, Sonata was successfully ported the very
same day I publicly released python-mpd.  And as noted, Sonata 1.5 now
depends on it instead of bundling it's own hacked version of mpdclient2.

However, it's still not a drop in replacement.  mpdclient2 will need to
stick around for old clients.  But I intend to update the MPD website
and wiki to recommend python-mpd over mpdclient2 for new clients.  And
with mpdclient2 quickly becoming deprecated, python-mpd is likely to see
much more use in the future.

--
J. Alexander Treuman


pgp5KaXNFYRlQ.pgp
Description: PGP signature

Re: mentors.debian.ORG?

[Joerg Jaspert]

On 11348 March 1977, Christoph Haas wrote:

> As soon as that part is done I would like to consider moving the service
> to an official Debian machine. I've been sponsoring hardware for
> mentors.debian.net for the last years. In my opinion the mentors server
> has become an established resource and is used a lot. So I wondered what
> has to be done to get it into debian.org hardware. I'd still be willing
> to maintain it of course.

One problem with hosting it on a debian.org machine is that this might
include software not checked by an ftpmaster/assistant, which might very
well be undistributable by Debian. Which is a *BAD* thing to do on a
debian host. IMO not very likely to get on such a host.


Are you hardcoded to your solution? I wouldn't have a problem if we go
and merge this into dak.ganneff.de - something which I meant to move to
a new host anyway. Which would be a big enough Xen domU on one of my
hosts. *Of* course that would work with dak as the background software
then... Depending on the extras mentors might need it should be doable
by additions to the dak code.

-- 
bye, Joerg
 Snow-Man: Please don't talk to me. You have demonstrated yourself
  sufficiently. There is a serious matter being talked.
 exa: It's hardly serious, it's about you.


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

Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?

[Luk Claes]

Ron Johnson wrote:
> On 04/07/08 13:20, Luk Claes wrote:
>> Peter Jordan wrote:
>>> Luk Claes, 04/07/08 20:05:
>>>
 Peter Jordan wrote:
> Hi,
 Hi

> why are the keyrings of debian-multimedia.org and debian backports not
> in the official repository of debian?
>
> At the moment you have to install untrusted keyrings before you can use
>  these repositories.
 Because they are no official Debian services (yet?).

>>> but the repositories does not need to be official debian services, only
>>> the keyrings should be available over the official debian repository.
>> No, as that would imply that they are or at least will be official
>> Debian services and open the door for every archive provider to ask for
>> adding their key...
> 
> Governments need silly all-encompassing rule sets to appear fair.
> Debian doesn't.  IOW, adding debian-multimedia-keyring and
> debian-backports-keyring doesn't mean that you've got to add every
> other unofficial archive keyring, even though that archive's owner
> screams "that's not fair!".

Indeed, so we don't need to add these neither even though you scream
it's unfair :-)

There has to be a line somewhere and the current line makes sense to
everyone, so I don't need we will change it...

Cheers

Luk


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

Re: mentors.debian.ORG?

[Christoph Haas]

On Mon, Apr 07, 2008 at 10:58:36PM +0200, Joerg Jaspert wrote:
> On 11348 March 1977, Christoph Haas wrote:
> 
> > As soon as that part is done I would like to consider moving the service
> > to an official Debian machine. I've been sponsoring hardware for
> > mentors.debian.net for the last years. In my opinion the mentors server
> > has become an established resource and is used a lot. So I wondered what
> > has to be done to get it into debian.org hardware. I'd still be willing
> > to maintain it of course.
> 
> One problem with hosting it on a debian.org machine is that this might
> include software not checked by an ftpmaster/assistant, which might very
> well be undistributable by Debian. Which is a *BAD* thing to do on a
> debian host. IMO not very likely to get on such a host.

The focus of mentors.debian.net is to host source packages that are
supposed to be sponsored. So it's not some weird multiverse non-free
binary warez repository or something. That doesn't ensure that some
packages being uploaded can't be redistributed of course. But the same
might happen with packages uploaded to ftp-master to be checked by the
FTP team.

> Are you hardcoded to your solution? I wouldn't have a problem if we go
> and merge this into dak.ganneff.de

Honestly dak scares me a lot. I tried to get it running with the few
bits of information I could find quite some time ago. I deeply believe
that it's a great repository management software and way more
sophisticated than what mentors.debian.net delivers. And as much as I
hate to avoid double-work I think in this case there are different
goals. dak is rather the industry-grade hardware package backend for
Debian. While the "new generation" mentors.debian.net is more focusing
on the web and social interaction. Besides it's doing QA tasks that I
didn't see in dak. I just don't think this is where dak is heading. If I
think of REVU and PPAs... that's not dak-like at all. And have I
mentioned that dak scares me? :)

> *Of* course that would work with dak as the background software
> then... Depending on the extras mentors might need it should be doable
> by additions to the dak code.

I may need a glass of Chiraz and the "use the source, Luke" method. But
I'm not really convinced that dak is what I want for this purpose.

Cheers
 Christoph

P.S.: I do not endorse the abuse of drugs while coding!
-- 
[EMAIL PROTECTED]  www.workaround.org   JID: [EMAIL PROTECTED]
gpg key: 79CC6586 fingerprint: 9B26F48E6F2B0A3F7E33E6B7095E77C579CC6586


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

Re: mentors.debian.ORG?

[Joerg Jaspert]

On 11348 March 1977, Christoph Haas wrote:

>> One problem with hosting it on a debian.org machine is that this might
>> include software not checked by an ftpmaster/assistant, which might very
>> well be undistributable by Debian. Which is a *BAD* thing to do on a
>> debian host. IMO not very likely to get on such a host.
> The focus of mentors.debian.net is to host source packages that are
> supposed to be sponsored. So it's not some weird multiverse non-free
> binary warez repository or something. That doesn't ensure that some
> packages being uploaded can't be redistributed of course. But the same
> might happen with packages uploaded to ftp-master to be checked by the
> FTP team.

Thats the reason why NEW packages aren't visible to anyone except
ftpteam members.

>> Are you hardcoded to your solution? I wouldn't have a problem if we go
>> and merge this into dak.ganneff.de
> Honestly dak scares me a lot.

Its pretty simple.

> and social interaction. Besides it's doing QA tasks that I didn't see
> in dak. I just don't think this is where dak is heading. If I think of
> REVU and PPAs... that's not dak-like at all. And have I mentioned that
> dak scares me? :)

dak is simple. Really.
Also, you wouldnt have to do the setup.

>> *Of* course that would work with dak as the background software
>> then... Depending on the extras mentors might need it should be doable
>> by additions to the dak code.
> I may need a glass of Chiraz and the "use the source, Luke" method. But
> I'm not really convinced that dak is what I want for this purpose.

Well. I don't think you will get onto a debian.org machine in the near
(or distant) future. I offer you a way out, but it needs dak. :)

Now, what does mentors do that dak doesnt? It might be interesting to
get that into dak too.

-- 
bye, Joerg
Five exclamation marks, the sure sign of an insane mind.
-- Terry Pratchett, Reaper Man


pgpvCirdsQPpt.pgp
Description: PGP signature

help required regarding bug - #436681

[BILAL]

Respected sir,
   
   i am a student of MS (computer science). I need 
your help
 and guidance for my project of course "Advanced Operating 
System".
   
The project is : 
   
  "pick up one bug from the site of debian and solve it "
   
  So i have selected the following  bug:
 
   "Debian Bug report logs - 
#436681
backuppc: Web interface password 
publicly visible "
   link 
http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=436681
  
   I have installed the debian 4.0 (Kernel: Linux 2.6.18-4-686) on my 
PC.
   Now the problem is that how to check and see this bug on my pc?. i 
request you 
 kindly tell me the complete  procedure or instructions for 
checking this bug. And 
 also give me some guideline or extra information about it that 
will be helpful for 
 me to undestand this bug completely.
So that it 
will be easy for me to work on it 
 and eventually find out the proper solution for it in right 
direction. 
 i shall be very very thankful to you.

  bye
   
   

   
-
You rock. That's why Blockbuster's offering you one month of Blockbuster Total 
Access, No Cost.

Re: Should -dev packages providing .pc files depend on pkg-config?

[Andreas Bombe]

On Mon, Apr 07, 2008 at 01:14:50PM -0500, Manoj Srivastava wrote:
> On Mon, 7 Apr 2008 18:20:56 +0200, Bernhard R Link <[EMAIL PROTECTED]> said: 
> > Here I have to contradict. No -dev package should ever depend on a
> > compiler or linker, even if that tool was not already in
> > build-essentials.
> 
> Can you provide some rationale for this assertion? I can see why
>  one might not tie the development tool very strongly with a particular
>  compiler or compiler version, to allow a developer to use it with an
>  alternative development tool, but I can see why one  may want to depend
>  on a generic foo-lang-compiler-or-interpreter virtual package.
> 
> There is obviously a trade off here -- the need to the
>  development package to be useful on installation, by ensuring that the
>  tools required to use the package are also installed, versus the need
>  to allow people to use the package with alternate developer tools. Ar
>  there other considerations and use cases you have in mind?

I can't speak for Bernhard of course, but my opinion is that such
dependencies of any sort are redundant.  The development packages are
not usable by themselves, they are used by programs.  If it's a dev
package for a C library that is used in a C program you want to compile,
then it's your program depending on the C compiler already.  If it's a
module for Python used in a Python program, then the program depends on
the Python interpreter already.

I can't think of a scenario where the dev package would depend on a
compiler or interpreter that wouldn't be depended on by the actual user
(the program) of the package.  They are used in an environment where the
dependency would by necessity already be fulfilled.

-- 
Andreas Bombe <[EMAIL PROTECTED]>GPG key 0x04880A44


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

Re: mentors.debian.ORG?

[Raphael Geissert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Christoph,

This is offtopic to your questions, but I should better say this now than
forgetting about this idea:

For the new users registration process what about making mentors:

 * require the key to be in a keyserver so it can fetch it from there, and
removing the current 'upload your key' way.
   Reasoning: Potential sponsors, in theory, should verify the signature of
package they may sponsor, and in order to do this they need to be able to
get the public key from somewhere. Making this a requirement would also
make people more aware of the keyservers and their pourpose.

 * and once the key has been imported in mentors' local keyring, the user
should fetch mentors' public key in order to send an encrypted message
either via web or via email to mentors in a format such as the following so
the new account is created:
Email: [EMAIL PROTECTED]
Password: foobar
   Reasoning: just like for my previous point, users need to be aware of the
capabilities and uses of GPG/PGP keys. And not to mention that in theory it
is a safer way to transmit passwords over the net instead of dummy https.

A similar process could be used when the user wishes to reset the password
of the web account.

Cheers,
Raphael

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

iD8DBQFH+qpiYy49rUbZzloRAkj+AJ4tmNzRuHrkxRDnIpmTIFinRaA9RACfdbr9
3HLFJ0KptGhomOds4hyqKjE=
=VzVQ
-END PGP SIGNATURE-


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

Re: Should -dev packages providing .pc files depend on pkg-config?

[Manoj Srivastava]

On Mon, 7 Apr 2008 23:21:51 +0200, Andreas Bombe <[EMAIL PROTECTED]> said: 

> On Mon, Apr 07, 2008 at 01:14:50PM -0500, Manoj Srivastava wrote:
>> On Mon, 7 Apr 2008 18:20:56 +0200, Bernhard R Link
>> <[EMAIL PROTECTED]> said:
>> > Here I have to contradict. No -dev package should ever depend on a
>> > compiler or linker, even if that tool was not already in
>> > build-essentials.
>> 
>> Can you provide some rationale for this assertion? I can see why one
>> might not tie the development tool very strongly with a particular
>> compiler or compiler version, to allow a developer to use it with an
>> alternative development tool, but I can see why one may want to
>> depend on a generic foo-lang-compiler-or-interpreter virtual package.
>> 
>> There is obviously a trade off here -- the need to the development
>> package to be useful on installation, by ensuring that the tools
>> required to use the package are also installed, versus the need to
>> allow people to use the package with alternate developer tools. Ar
>> there other considerations and use cases you have in mind?

> I can't speak for Bernhard of course, but my opinion is that such
> dependencies of any sort are redundant.  The development packages are
> not usable by themselves, they are used by programs.  If it's a dev
> package for a C library that is used in a C program you want to
> compile, then it's your program depending on the C compiler already.
> If it's a module for Python used in a Python program, then the program
> depends on the Python interpreter already.

I am not sure I find this argument convincing.  For
 dependencies, we have ruled that if a package depends on library A, and
 that library depends on library B, the package in question should
 still only mention library A only -- and let libA's dependencies pull in
 libB.

In this case, again, if my dev package requires a tool not in
 build depends now, I should declare it, for the same reason -- the next
 upload of the dev package might have different tools, or eliminate
 tools -- and putting that build dependency in all the packages that
 use my dev package is hard -- especially when we consider the cases
 when the scenarios where these dependencies might change over time.

manoj
-- 
The truth about a man lies first and foremost in what he hides. Andre
Malraux
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: help required regarding bug - #436681

[Carsten Hey]

Hi,

bug #436681 is already marked as closed, so you can't fix it :)

If you need a another bug you can work on which will propbaly not be
fixed soon by anybody else I would be very happy if you choose #277994
(http://bugs.debian.org/277944).

The package is hnb, which was developed without variable length
character encoding in mind.  To fix this bug you need to gain some
skills in C, ncurses, read a bit about Unicode and write a patch for hnb
to be able to display UTF-8.  Fixing this is not that easy but it should
be doable for an avarage skilled computer science student.

Reproducing this bug is easy:
1) apt-get install hnb
2) start a terminal
3) start hnb in this terminal
4) type a UTF-8 character and see what happens

hnb needs a simple patch to display a cursor, which will be included in
hnb soon. Drop me a mail if you need that patch.


Thanks,
Carsten


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

Bug#474937: ITP: logstalgia -- a website access log visualisation tool

[Andrew Hugh Caudwell]

Package: wnpp
Severity: wishlist
Owner: Andrew Caudwell <[EMAIL PROTECTED]>


* Package name: logstalgia
  Version : 0.9.0
  Upstream Author : Andrew Caudwell <[EMAIL PROTECTED]>
* URL : http://code.google.com/p/logstalgia/
* License : GPL
  Description : a website access log visualisation tool

Logstalgia (aka ApachePong) replays or streams a standard website
access log (eg access.log) as a retro arcade game-like simulation.

-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.16.17-vs2.0.2-rc21-x4100vs
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)



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

Re: help required regarding bug - #436681

[Franklin PIAT]

Note there's a typo in Carsten's mail.

The link is incorrect (#277944 instead of #277994)
 =>  http://bugs.debian.org/277994

Franklin

On Tue, 2008-04-08 at 01:49 +0200, Carsten Hey wrote:
> bug #436681 is already marked as closed, so you can't fix it :)
> 
> If you need a another bug you can work on which will propbaly not be
> fixed soon by anybody else I would be very happy if you choose #277994
> (http://bugs.debian.org/277944).



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

Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/07/08 15:34, Luk Claes wrote:
> Ron Johnson wrote:
>> On 04/07/08 13:20, Luk Claes wrote:
>>> Peter Jordan wrote:
 Luk Claes, 04/07/08 20:05:

> Peter Jordan wrote:
>> Hi,
> Hi
>
>> why are the keyrings of debian-multimedia.org and debian backports not
>> in the official repository of debian?
>>
>> At the moment you have to install untrusted keyrings before you can use
>>  these repositories.
> Because they are no official Debian services (yet?).
>
 but the repositories does not need to be official debian services, only
 the keyrings should be available over the official debian repository.
>>> No, as that would imply that they are or at least will be official
>>> Debian services and open the door for every archive provider to ask for
>>> adding their key...
>> Governments need silly all-encompassing rule sets to appear fair.
>> Debian doesn't.  IOW, adding debian-multimedia-keyring and
>> debian-backports-keyring doesn't mean that you've got to add every
>> other unofficial archive keyring, even though that archive's owner
>> screams "that's not fair!".
> Indeed, so we don't need to add these neither even though you scream
> it's unfair :-)

Actually, OP and I are not screaming that not add the 2 keyring
packages is unfair.

> There has to be a line somewhere and the current line makes sense to
> everyone, so I don't need we will change it...

As is your prerogative...

- --
Ron Johnson, Jr.
Jefferson LA  USA

We want... a Shrubbery!!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH+sFrS9HxQb37XmcRArDCAJ0XboaceDYoLxknkV0ZmHx8JYXujACfQRKs
H1FY+0KuHGQvVGs3ScG6ukY=
=bLSm
-END PGP SIGNATURE-


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

Re: help required regarding bug - #436681

[Carsten Hey]

On Tue, Apr 08, 2008 at 01:49:27AM +0200, Carsten Hey wrote:
> (http://bugs.debian.org/277944).

Sorry, http://bugs.debian.org/277994 is the correct URL.


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

Re: [OT] Need old Packages.gz and Release Files

[Wouter Verhelst]

On Thu, Apr 03, 2008 at 03:35:57PM +0200, Michelle Konzack wrote:
> Hello,
> 
> I have had an accident on my Debian-Archiv-Server and  unfortunatly  the
> files "Packages.gz",  "Packages.bz2",  "Sources.gz",  "Sources.bz2"  and
> "Release" from the directories
> 
> /debian/dists/${RELEASE}/main/binary-${ARCH}/
> /debian/dists/${RELEASE}/main/sources/
> /debian/dists/${RELEASE}/contrib/binary-${ARCH}/
> /debian/dists/${RELEASE}/contrib/sources/
> /debian/dists/${RELEASE}/non-free/binary-${ARCH}/
> /debian/dists/${RELEASE}/non-free/sources/
> 
> deleted.  The special is, that I have ALL Releases where ${RELEASES}  is
> like:
> 
> potato: 2.2r0 bis 2.2r5 =>  6 Releases
> woody:  3.0r0 bis 3.0r6 =>  7 Releases
> sarge:  3.1r0 bis 3.1r7 =>  8 Releases
> etch:   4.0r0 bis 4.0r2 =>  3 Releases
> 
> Does anyone has this files?  (e.g from the original CD's)

Can't you fetch them from snapshot.debian.net?

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Reminder to connect with Mayur Ranpura

[Mayur Ranpura]

Connect with me on Ecademy

I added you as one of my contacts to my business network on Ecademy.

Click here to connect with me:
http://www.ecademy.com/account.php?op=signup&xref=236310

Thank you.

Mayur Ranpura
[EMAIL PROTECTED]

To avoid receiving these emails in the future just reply to [EMAIL PROTECTED]
or go to http://www.ecademy.com/[EMAIL PROTECTED]  
Email:[EMAIL PROTECTED] Company Registration:3651083 VAT:718 0377 36

Re: RFH: piuparts testing of the archive

[Russ Allbery]

Lucas Nussbaum <[EMAIL PROTECTED]> writes:

> Before the etch release, I did a few piuparts runs on all packages, and
> filed the resulting bugs. I'd like someone to take over that task for
> lenny.
>
> What needs to be done is:
> - run installation/removal/purge tests for all packages
> - run upgrade tests for all packages in etch
> - make changes to piuparts to fix false positives or reduce the number
>   of failures by ignoring the less critical ones
> - file all the bugs (many of those are RC)
>
> The main problem is that there's currently ~4400 failures for the
> installation/removal/purge tests. This includes issues about files being
> added/removed/modified during the test, which are not as critical as the
> tests where installation simply fails. But still.

Fixing #454694 might help.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Should -dev packages providing .pc files depend on pkg-config?

[Steve Langasek]

On Mon, Apr 07, 2008 at 06:49:24PM -0500, Manoj Srivastava wrote:
> > I can't speak for Bernhard of course, but my opinion is that such
> > dependencies of any sort are redundant.  The development packages are
> > not usable by themselves, they are used by programs.  If it's a dev
> > package for a C library that is used in a C program you want to
> > compile, then it's your program depending on the C compiler already.
> > If it's a module for Python used in a Python program, then the program
> > depends on the Python interpreter already.

> I am not sure I find this argument convincing.  For
>  dependencies, we have ruled that if a package depends on library A, and
>  that library depends on library B, the package in question should
>  still only mention library A only -- and let libA's dependencies pull in
>  libB.

Any package that wants to use .pc files during its build is going to invoke
pkg-config directly, and changing your -dev package to recommend a different
means of linking to the library won't cause this reference to disappear.
That's a build-dependency.

-- 
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]

Come join me on My Thank You...

[Tord Martin]

Come join me on My Thank You.

Hi 
how are you?

If You want to say thanks to your family, friends, God and someone special, 
Please join 

mythanktou.com and express your feeling.

Click here to join:
http://www.mythankyou.com/?xgi=18pv6VE

Thanks,
Tord Martin



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

Come join me on My Thank You...

[www.manyforyou.com]

Come join me on My Thank You.

Hi, 

   This is the good friends networking site - all over the world , register 
with this site in 1 minutes and be happy ,, 

Thanks
Bala
www.manyforyou.com

Click here to join:
http://www.mythankyou.com/?xgi=nuiK1W

Thanks,
www.manyforyou.com



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

Come join me on My Thank You...

[www.manyforyou.com]

Come join me on My Thank You.

Hi Friend,, 

   I am Bala from India, I joined in this site , and this is the amazing 
friends creating network - all over the world. Register with 2 - 3 details and 
be happy , 

Thanks
Bala
www.manyforyou.com

Click here to join:
http://www.mythankyou.com/?xgi=nuiK1W

Thanks,
www.manyforyou.com



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

Come join me on My Thank You...

[www.manyforyou.com]

Come join me on My Thank You.

Hi Friend,,

  I am Bala from India, I joined in this site , and this is the amazing friends 
creating network - all over the world. Register with 2 - 3 details and be happy 
,

Click here to join:
http://www.mythankyou.com/?xgi=bhIwmMN


Thanks
Bala
www.manyforyou.com

Click here to join:
http://www.mythankyou.com/?xgi=bhIwmMN

Click here to join:
http://www.mythankyou.com/?xgi=nuiK1W

Thanks,
www.manyforyou.com



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

Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?

[Reinhard Tartler]

Ron Johnson <[EMAIL PROTECTED]> writes:

>> Because they are third party repositories and not affiliated in any
>> official way with the Debian project.
>
> But these two repositories are very popular with users.

Which doesn't make them official. Better spend your time helping those
projects with becoming official!

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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