Re: Anyone

[volk]

Hello, debian-devel.

Yes, this library needed for generating pdf docs from PHP.
Could you package it into next version?

-- 
regards,
 volk rich web-design mailto:[EMAIL PROTECTED]


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

Re: Attempted summary and thoughts

[Nathanael Nerode]

>Russ Allbery wrote:
>So, here's a possibly weird proposal.
>
>What if we had some mechanism whereby people could indicate interest in
>maintaining a package should anything happen to the current maintainer?
>Have it be as non-confrontational as possible by having it not indicate
>any feeling about whether the package is currently maintained well, 
>just a willingness to help should the current maintainer be unable to 
>continue for some reason.

I like it.  I doubt it will work for one of the reasons below, but I 
like it.

>Then, should the package run into any trouble, we'd know whether anyone
>else is actually already in a position to potentially take it over, or
>whether there really isn't anyone who feels like they could do so.
>
>Problems that I see with this right away are:
>
> * The data could easily get stale.  I may be willing to help with a
>   package right now, but a year from now when it has problems, I may no
>   longer be in that position.  I'm not sure if some sort of periodic ping
>   of "you said you'd be willing to take on all of these; reply if that's
>   not still true" would cut it.

Yep, this is the problem I anticipated too.

> * My guess is that if we put this system in place, we'll immediately
>   discover that most of our core packages have no backup ready and
>   available.  But that may be useful information anyway.

I'd be willing to take over ifupdown (though I'd hope for 
comaintainers), or doc-debian or lilo (which I could handle by 
myself).  But not all at the same time.  :-)  I'd also maintain lynx or 
gcc in a pinch though I'd want comaintainers and might not be able to 
keep it up for very long solo.

>For example, I (and probably various other people) would register my
>willingness to take over autoconf should Ben ever no longer be in a
>position to maintain it.  That doesn't mean that he's doing a bad job
>(he's doing a *great* job so far as I can tell); it's just a note that
>should anything catastrophic happen to him, people don't have to 
>scramble to look for a replacement maintainer for that package.

You know, this is a really clever proposal, even if you think it's 
"weird".  :-)


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

Re: Anyone

[Andrew Donnellan]

On 3/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Hello, debian-devel.

Yes, this library needed for generating pdf docs from PHP.
Could you package it into next version?


Which library?

--
Andrew Donnellan
ajdlinuxATgmailDOTcom (primary)ajdlinuxATexemailDOTcomDOTau (secure)
http://andrewdonnellan.com http://ajdlinux.wordpress.com
[EMAIL PROTECTED] hkp://subkeys.pgp.net 0x5D4C0C58
   http://linux.org.auhttp://debian.org
   Get free rewards - http://ezyrewards.com/?id=23484
   Spammers only === [EMAIL PROTECTED] ===


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

Re: Ethernet interface numbering in etch

[Nathanael Nerode]

I think everyone missed the important part of my message.
so I'm soliciting comments on it again.

>But perhaps the best "solution" is to document prominently that if you 
>replace your network hardware, you should delete the line associated 
>with the removed hardware from 
>/etc/udev/rules.d/z25_persistent-net.rules before inserting the new 
>hardware.  This would almost always give exactly the desired result, 
>that the new hardware would assume the name of the old hardware.

>Actually, the same caveat should be documented with regard to 
>z25_persistent-cd.rules.  I've had to swap out CD drives disturbingly 
>often (dust, I think), and thankfully I haven't yet had to do it 
>with a machine running udev, because this would have bitten me as I 
>wondered why the CD numbers kept going up and up and up.

This is the "documentation solution", and I think it would be 
essentially acceptable to most people.  Now, this is currently NOT 
prominently documented.  To be prominently documented, it should be in 
the installation manual and the release notes for each release, in a 
prominent place in /usr/share/doc/udev (perhaps its own file 
"REPLACING-HARDWARE.txt")?, and possibly other places.

Anyone have any thoughts on where and how this should be documented?
Which documents do we need to make patches for and how detailed should
the description in each document be?


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

Re: Attempted summary and thoughts

[paddy]

On Fri, Mar 30, 2007 at 05:09:12AM -0400, Nathanael Nerode wrote:
> >Russ Allbery wrote:
> >So, here's a possibly weird proposal.
> >
> >What if we had some mechanism whereby people could indicate interest in
> >maintaining a package should anything happen to the current maintainer?
> >Have it be as non-confrontational as possible by having it not indicate
> >any feeling about whether the package is currently maintained well, 
> >just a willingness to help should the current maintainer be unable to 
> >continue for some reason.

an "understudy" or "standby" ?

Regards,
Paddy


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

Re: Bug#416397: ITP: haproxy -- fast and reliable load balancing reverse proxy

[Russell Coker]

On Friday 30 March 2007 00:50, Steve Greenland <[EMAIL PROTECTED]> wrote:
> Logging and blocking can all be done at the proxy, though. No need to
> transfer the remote IP to the internal server.

Logging can be done at the proxy.  Blocking - maybe not.  IP address based 
restrictions on service forms part of a security strategy.

-- 
[EMAIL PROTECTED]
http://etbe.blogspot.com/  My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development


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

Re: Poll: Anybody using debpool?

[Francesco P. Lovergine]

On Wed, Mar 28, 2007 at 01:42:05AM +0200, Daniel Leidert wrote:
> Am Dienstag, den 27.03.2007, 23:41 +0100 schrieb Magnus Holmgren:
> 
> > DebPool is a Debian package archiver written in Perl by Joel Aelwyn 
> > <[EMAIL PROTECTED]>. Like mini-dinstall it's a lightweight replacement 
> > for "the real deal" that manages Debian's package archive, but unlike 
> > mini-dinstall it uses a full pool layout. The current version is 0.2.3 and 
> > it's in the experimental distribution.
> 
> There was a large discussion about debpool and debarchiver, involving
> Joel, Ola and several users/code writers. If you are interested, I can
> send you the discussion.
> 

Pointers? Debpool is a nice tiny tool, but lacks some major useful
features and has a few annoying bugs. It could be improved. It's a pity
it stales.


-- 
Francesco P. Lovergine


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

Re: Attempted summary and thoughts

[Roberto C . Sánchez]

On Fri, Mar 30, 2007 at 10:13:47AM +, [EMAIL PROTECTED] wrote:
> On Fri, Mar 30, 2007 at 05:09:12AM -0400, Nathanael Nerode wrote:
> > >Russ Allbery wrote:
> > >So, here's a possibly weird proposal.
> > >
> > >What if we had some mechanism whereby people could indicate interest in
> > >maintaining a package should anything happen to the current maintainer?
> > >Have it be as non-confrontational as possible by having it not indicate
> > >any feeling about whether the package is currently maintained well, 
> > >just a willingness to help should the current maintainer be unable to 
> > >continue for some reason.
> 
> an "understudy" or "standby" ?
> 
Could we call it "co-maintainer" or something like that?

Regards,

-Roberto

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


signature.asc
Description: Digital signature

Re: Attempted summary and thoughts

[Kevin Mark]

On Fri, Mar 30, 2007 at 06:51:52AM -0400, Roberto C. Sánchez wrote:
> On Fri, Mar 30, 2007 at 10:13:47AM +, [EMAIL PROTECTED] wrote:
> > On Fri, Mar 30, 2007 at 05:09:12AM -0400, Nathanael Nerode wrote:
> > > >Russ Allbery wrote:
> > > >So, here's a possibly weird proposal.
> > > >
> > > >What if we had some mechanism whereby people could indicate interest in
> > > >maintaining a package should anything happen to the current maintainer?
> > > >Have it be as non-confrontational as possible by having it not indicate
> > > >any feeling about whether the package is currently maintained well, 
> > > >just a willingness to help should the current maintainer be unable to 
> > > >continue for some reason.
> > 
> > an "understudy" or "standby" ?
> > 
> Could we call it "co-maintainer" or something like that?
what about having the list include different options for folks who may
want to:
work on a specific feature
work on a specific bug
want to co-maintaint
want to help with triage
etc.
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal |mysite.verizon.net/kevin.mark/|
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
|  my keyserver: subkeys.pgp.net | my NPO: cfsg.org |
|join the new debian-community.org to help Debian!  |


signature.asc
Description: Digital signature

Re: Attempted summary and thoughts

[paddy]

On Fri, Mar 30, 2007 at 06:51:52AM -0400, Roberto C. S?nchez wrote:
> On Fri, Mar 30, 2007 at 10:13:47AM +, [EMAIL PROTECTED] wrote:
> > On Fri, Mar 30, 2007 at 05:09:12AM -0400, Nathanael Nerode wrote:
> > > >Russ Allbery wrote:
> > > >So, here's a possibly weird proposal.
> > > >
> > > >What if we had some mechanism whereby people could indicate interest in
> > > >maintaining a package should anything happen to the current maintainer?
> > > >Have it be as non-confrontational as possible by having it not indicate
> > > >any feeling about whether the package is currently maintained well, 
> > > >just a willingness to help should the current maintainer be unable to 
> > > >continue for some reason.
> > 
> > an "understudy" or "standby" ?
> > 
> Could we call it "co-maintainer" or something like that?

I understood that term to be already in use with a different meaning ?
or do you mean that an additional role is not required :-)

Regards,
Paddy


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

Slow package database

[Christoph Haas]

Dear list...

what has always annoyed me is now ready to be asked on this list. :)
It appears like apt-get/aptitude/dpkg dealing with the list/database of 
installed packages is terribly slow at times. I have roughly 1800 packages 
installed and it sometimes takes 20-30 seconds to install a single 
package. On a freshly installed system that's just a matter of seconds. 
Since this is one of my two development workstations I uninstall and 
install a lot of packages and dist-upgrade to unstable/experimental daily. 
So the package database is in permanent flux. What might be the cause? Is 
there some fragmentation effect? This is a common effect on a few Debian 
systems here so I assume I'm not alone with it. Has anyone else observed 
that? Is there a way to optimize it?

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: Slow package database

[Roberto C . Sánchez]

On Fri, Mar 30, 2007 at 03:39:29PM +0200, Christoph Haas wrote:
> Dear list...
> 
> what has always annoyed me is now ready to be asked on this list. :)
> It appears like apt-get/aptitude/dpkg dealing with the list/database of 
> installed packages is terribly slow at times. I have roughly 1800 packages 
> installed and it sometimes takes 20-30 seconds to install a single 
> package. On a freshly installed system that's just a matter of seconds. 
> Since this is one of my two development workstations I uninstall and 
> install a lot of packages and dist-upgrade to unstable/experimental daily. 
> So the package database is in permanent flux. What might be the cause? Is 
> there some fragmentation effect? This is a common effect on a few Debian 
> systems here so I assume I'm not alone with it. Has anyone else observed 
> that? Is there a way to optimize it?
> 
Interesting.  I have ~1600 packages installed on my development machine
and I do not experience the slowness you talk about.  It was installed
about 3.5 years ago.

How much RAM/CPU does the machine have?  How fast are the disks?

Regards,

-Roberto

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


signature.asc
Description: Digital signature

Re: Slow package database

[Christoph Haas]

On Friday 30 March 2007 15:43, Roberto C. Sánchez wrote:
> On Fri, Mar 30, 2007 at 03:39:29PM +0200, Christoph Haas wrote:
> > It appears like apt-get/aptitude/dpkg dealing with the list/database
> > of installed packages is terribly slow at times.
>
> Interesting.  I have ~1600 packages installed on my development machine
> and I do not experience the slowness you talk about.  It was installed
> about 3.5 years ago.
>
> How much RAM/CPU does the machine have?  How fast are the disks?

RAM: 1 GB
CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz
Kernel: 2.6.18-3-686
Disk: ~ 20 MB/sec (if I read the bonnie++ numbers correctly)

 Christoph

Re: Slow package database

[Roberto C . Sánchez]

On Fri, Mar 30, 2007 at 04:11:46PM +0200, Christoph Haas wrote:
> On Friday 30 March 2007 15:43, Roberto C. Sánchez wrote:
> > On Fri, Mar 30, 2007 at 03:39:29PM +0200, Christoph Haas wrote:
> > > It appears like apt-get/aptitude/dpkg dealing with the list/database
> > > of installed packages is terribly slow at times.
> >
> > Interesting.  I have ~1600 packages installed on my development machine
> > and I do not experience the slowness you talk about.  It was installed
> > about 3.5 years ago.
> >
> > How much RAM/CPU does the machine have?  How fast are the disks?
> 
> RAM: 1 GB
> CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz
> Kernel: 2.6.18-3-686
> Disk: ~ 20 MB/sec (if I read the bonnie++ numbers correctly)
> 
>  Christoph

Hmm.  I have 1.5 GB RAM, 1.8 GHz Athlon XP and a 2.6.16 or 2.6.17
kernel.  My disks are a little faster, but not much.  I wonder if
something else is slowing you down.

Regards,

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


signature.asc
Description: Digital signature

Re: Slow package database

[Margarita Manterola]

On 3/30/07, Christoph Haas <[EMAIL PROTECTED]> wrote:

what has always annoyed me is now ready to be asked on this list. :)
It appears like apt-get/aptitude/dpkg dealing with the list/database of
installed packages is terribly slow at times. I have roughly 1800 packages
installed and it sometimes takes 20-30 seconds to install a single
package


I've experienced this myself, so much that I'm about to change my
perfectly working IDE disk for a SATA disk with the intent of fixing
this.

On my attempts to fix this, I changed some of the HD parameters, and
it improved a bit, but not completely.

My only guess about why this happens is that at some point the
hard-drive was a bit too-full, so that it started to become
fragmented, and the package db never de-fragmented, even if I later
emptied the disk.  This is just a wild guess.  It might be something
completely different.

--
Besos,
Marga


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

Incorrectly rejected ballots

[Manoj Srivastava]

Hi,

On investigation, I found a mishandled corner case in devotee
 which had caused 4 ballots to be incorrectly rejected (the other 137
 rejections, each one of which I have nw manually inspected, are still
 valid rejections). These four ballots, from 3 individuals, have now
 been accepted, and the voters informed separately.

manoj
-- 
Everything in this book may be wrong. Messiah's Handbook : Reminders
for the Advanced Soul
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


pgpSffnowa3CT.pgp
Description: PGP signature

Re: Slow package database

[nextime]

debian sid installed about 9 years ago, actually on amd64 (but with
32bit kernel and 32bit userland ) sempron 3300+ with 1 gigs of ram.

The system is on a dm-crypted in aes256 device over software raid1 composed 
by two slow ide disks, (so, I/O is *VERY* slow), i have something like 2500 
packages installed.

To install from local disk a simple fake package that just put an empy
file on /tmp/:

real0m5.499s
user0m0.512s
sys 0m0.200s


-- 

Franco (nextime) Lanza
Busto Arsizio - Italy
SIP://[EMAIL PROTECTED]

NO TCPA: http://www.no1984.org
you can download my public key at:
http://danex.nexlab.it/nextime.asc || Key Servers
Key ID = D6132D50
Key fingerprint = 66ED 5211 9D59 DA53 1DF7  4189 DFED F580 D613 2D50
---
echo 
16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq
 | dc
---



signature.asc
Description: PGP signature

Re: Slow package database

[Loïc Minier]

On Fri, Mar 30, 2007, Christoph Haas wrote:
> It appears like apt-get/aptitude/dpkg dealing with the list/database of 
> installed packages is terribly slow at times.

 I think dpkg spends a lot of time reading all /var/lib/dpkg/info/*.list
 files.  These are not big and this is typically in cache between dpkg
 runs, and I think this is the reason that cold dpkg runs are very very
 slow.

 I tested by stracing dpkg -i on a small .deb after sync && echo 3 >
 /proc/sys/vm/drop_caches, and from a 24 seconds run, 22 seconds were
 spent reading *.list files.

 (A subsequent run took in the order of 1 second.)

 Perhaps someone with elite dpkg skillz will implement some form of
 cache for these?  :-)

NB: I have 227524 files in 1801 packages.
-- 
Loïc Minier


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

Re: many rejects (Re: Second call for votes for the debian project leader election 2007)

[Manoj Srivastava]

On Fri, 30 Mar 2007 09:23:38 +0200, Michal Čihař <[EMAIL PROTECTED]> said: 

> Hi On Thu, 29 Mar 2007 21:23:28 +0200
> Kurt Roeckx <[EMAIL PROTECTED]> wrote:

>> If you encrypt to yourself, how is the voting system supposed to
>> decrypt it?

> It was encrypted for two keys, both of them can decrypt it.

It turns out that it was indeed encrypted, but the message was
 not signed; which means there is no information about who is sending
 the ballot. This is a legitimate addition to the ballot; I'll point
 it out in the next CFV.

manoj
-- 
Time will end all my troubles, but I don't always approve of Time's
methods.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: many rejects (Re: Second call for votes for the debian project leader election 2007)

[Manoj Srivastava]

On Fri, 30 Mar 2007 11:02:49 -0500, Manoj Srivastava <[EMAIL PROTECTED]> said: 

> On Fri, 30 Mar 2007 09:23:38 +0200, Michal Čihař <[EMAIL PROTECTED]>
> said:
>> Hi On Thu, 29 Mar 2007 21:23:28 +0200
>> Kurt Roeckx <[EMAIL PROTECTED]> wrote:

>>> If you encrypt to yourself, how is the voting system supposed to
>>> decrypt it?

>> It was encrypted for two keys, both of them can decrypt it.

> It turns out that it was indeed encrypted, but the message
> was
>  not signed; which means there is no information about who is
>  sending the ballot. This is a legitimate addition to the ballot;
>  I'll point it out in the next CFV.

Hmm. Turns out, that ballot already mentioned that "you may, if
 you wish, choose to send a signed, encrypted ballot".   The operative
 word is "signed", which the ballot in question was not.

manoj
-- 
No matter how good she looks, some other guy is sick and tired of
putting up with her shit.  Men's Room, Linda's Bar and Grill.  Chapel
Hill, North Carolina.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Poll: Anybody using debpool?

[Magnus Holmgren]

On Friday 30 March 2007 12:22, Francesco P. Lovergine wrote:
> Pointers? Debpool is a nice tiny tool, but lacks some major useful
> features and has a few annoying bugs. It could be improved. It's a pity
> it stales.

I'd like to suggest, then, that a project be started on Alioth, let's 
say "saving-debpool" or "debpool-2g". Or anything that is better. :-) I just 
wanted to make clear that no one is "stealing" debpool or anything. 
Discussion can then continue on an associated mailing list.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgp5vI4aumiHv.pgp
Description: PGP signature

Re: Slow package database

[Joey Hess]

Loïc Minier wrote:
>  I think dpkg spends a lot of time reading all /var/lib/dpkg/info/*.list
>  files.  These are not big and this is typically in cache between dpkg
>  runs, and I think this is the reason that cold dpkg runs are very very
>  slow.

It can also lead to a kind of "fragmentation", since during an initial
install these files tend to be fairly close together on disk while over
time new files will be scattered about and more seeking needed to read
them all.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Slow package database

[Nico Golde]

Hi,
* Loïc Minier <[EMAIL PROTECTED]> [2007-03-30 20:29]:
> On Fri, Mar 30, 2007, Christoph Haas wrote:
> > It appears like apt-get/aptitude/dpkg dealing with the list/database of 
> > installed packages is terribly slow at times.
> 
>  I think dpkg spends a lot of time reading all /var/lib/dpkg/info/*.list
>  files.  These are not big and this is typically in cache between dpkg
>  runs, and I think this is the reason that cold dpkg runs are very very
>  slow.
> 
>  I tested by stracing dpkg -i on a small .deb after sync && echo 3 >
>  /proc/sys/vm/drop_caches, and from a 24 seconds run, 22 seconds were
>  spent reading *.list files.

Yes I experienced the same while doing a bit of stracing on 
dpkg. I wondered that it reads the whole info list even if 
you just remove a single package.
Kind regards
Nico
-- 
Nico Golde - http://www.ngolde.de
JAB: [EMAIL PROTECTED] - GPG: 0x73647CFF
Forget about that mouse with 3/4/5 buttons,
gimme a keyboard with 103/104/105 keys!


pgpxZM21H0bvo.pgp
Description: PGP signature

Re: Slow package database

[Loïc Minier]

On Fri, Mar 30, 2007, Joey Hess wrote:
> It can also lead to a kind of "fragmentation", since during an initial
> install these files tend to be fairly close together on disk while over
> time new files will be scattered about and more seeking needed to read
> them all.

 Indeed it accounts for some part of the problem; after I cloned and
 replaced my /var/lib/dpkg/info tree with the copy, the figure dropped
 from 22 seconds to 15 seconds.

 I suppose a cache would nevertheless address both problems.

-- 
Loïc Minier


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

Bug#416843: ITP: libphp-facebook -- PHP5 client library for Facebook

[Jonny Lamb]

Package: wnpp
Severity: wishlist
Owner: Jonny Lamb <[EMAIL PROTECTED]>


* Package name: libphp-facebook
  Version : 0.0.020070306
  Upstream Author : Facebook, Inc. <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : FreeBSD
  Programming Lang: PHP
  Description : PHP5 client library for Facebook

 A client library for PHP5 that simplifies writing projects
 that use Facebook's services. This involves creating a
 signature (MD5 hash of a combination of the parameters
 to the method), creating and sending an HTTP POST request,
 and parsing the XML result of each request.

 Homepage: http://developers.facebook.com/documentation.php?doc=clients

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18.2
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)


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

Re: Poll: Anybody using debpool?

[Andreas Fester]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Magnus,

Magnus Holmgren wrote:
[...]
> Since I liked it very much I immediately started adding and rewriting code 
> and 

"me too" ;)

> submitting my suggestions for improvement to the BTS, but unfortunately Joel 

Yes, I also sent him an email some time ago, asking if he is interested
in what I did, my but never got a reply.

> seems to be gone; he hasn't uploaded anything or commented on any bugs for 
> over eight months. I don't want debpool to die, especially not with all the 
> hours I spent on it...
> 
> I could of course fork it (except that it wouldn't really be a fork since I'd 
> continue in the same general direction, and also it isn't much of a fork 
> unless the original branch continues to grow), but first I'd like to ask if 
> anyone else has an interest in this package and could think of cooperating 
> with me.

I do. I am currently a littlebit short of time, but I also already
hacked some improvements into debpool, among them

- - Added optional File Alteration Monitor support to make the
  incoming queue more responsive (plan is to also add GAMIN support)

- - Started to implement automatic tests to check if packages are
  properly installed in the pool (see the tests subdirectory)

- - Added support for multi arch archives (the .package files were
  not arch specific and therefore overwritten when an additional
  arch-specific package was uploaded)

- - Some minor bug fixes

The package is at http://littletux.homelinux.org/debian/pool/main/d/debpool/

> I'd like to suggest, then, that a project be started on Alioth, let's 
> say "saving-debpool" or "debpool-2g". Or anything that is better.  :-)  I 
> just 
> wanted to make clear that no one is "stealing" debpool or anything. 
> Discussion can then continue on an associated mailing list.

Great! I would be glad to contribute to this project!

Thanks,

Andreas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGDWYuZ3bQVzeW+rsRAjzrAKDPorTlHsy8WJVsh+2t1qdNCjpnSwCgrOID
Dk990NUje8uEphXsj/vyOE4=
=aElS
-END PGP SIGNATURE-


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

was (long time ago) ITP: zenoss

[Bernd Zeimetz]

Heya,

yesterday I've contacted the original bug submitter of #361253 via
personal mail and he told me that he doesn't have the time to take care
of packaging zenoss at all and that I should just do it, so I'll hijack
this wnpp bug and package zenoss within the next days.
If anybody else is working on this, or if there are any wishes or
additional plugins to package, please let me know. I don't want to waste
any efforts.

Cheers,

Bernd Zeimetz

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: Slow package database

[Adam Borowski]

On Fri, Mar 30, 2007 at 08:57:03PM +0200, Loïc Minier wrote:
>  Indeed it accounts for some part of the problem; after I cloned and
>  replaced my /var/lib/dpkg/info tree with the copy, the figure dropped
>  from 22 seconds to 15 seconds.

It's not that.  It's /var/lib/dpkg/available.

Try this:

for x in /var/lib/apt/lists/*Packages;do dpkg --merge-avail "$x";done
(or "dselect update")
Install+purge of an empty package:
9-ish seconds on one box (my home desktop, years of use)
6-ish seconds on another (a slow server)

dpkg --clear-avail
Install+purge of an empty package:
0.182s on the slow server
3ish seconds on the desktop

The difference between those 0.182s and 3s is due to removed and even purged
packages staying in the available file.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Slow package database

[Florian Weimer]

* Christoph Haas:

> What might be the cause? Is there some fragmentation effect?

It's probably ext3's directory hashing.  It tries to access the files
in /var/lib/dpkg/info in hash order, which leads to essentially random
disk I/O.


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

raptor.d.o down

[Bastian Blank]

Hi folks

raptor.d.o is down until at least tomorrow. During a planned system move
something got wrong and the machine is now in an undefined state and
needs manual intervention by an vm admin.

Bastian

-- 
Women are more easily and more deeply terrified ... generating more
sheer horror than the male of the species.
-- Spock, "Wolf in the Fold", stardate 3615.4


signature.asc
Description: Digital signature

Bug#416862: O: mutt-ng

[Elimar Riesebieter]

Package: mutt-ng
Severity: normal

I hereby want to orphan mutt-ng as ist isn't maintained upstream
anymore [0]. To synchronise the package with mutt and fix the new
and upcoming security issues isn't my intetion as I then have to
carry over the upstream work.

[0] http://mutt-ng.supersized.org/

The best would be to remove it out of the pool as it actually only
resides in experimental. It was a great idea to create a mutt by
user-wishes. but I think mutt 1.6 will be a well featured one and
hopefully the sidebar patch will be adoptet by upstream or at least
by the mutt maintainers?

Thanks Andreas Kremmair <[EMAIL PROTECTED]>,
Rocco Rutte <[EMAIL PROTECTED]> and Nico Golde <[EMAIL PROTECTED]> for
their great work to the package.

Elimar

-- 
  Numeric stability is probably not all that 
  important when you're guessing;-)


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

Re: Slow package database

[Brad Sawatzky]

On Fri, 30 Mar 2007, Adam Borowski wrote:

> It's not that.  It's /var/lib/dpkg/available.
> 
> Try this:
> 
> for x in /var/lib/apt/lists/*Packages;do dpkg --merge-avail "$x";done
> (or "dselect update")
> Install+purge of an empty package:
>   9-ish seconds on one box (my home desktop, years of use)
>   6-ish seconds on another (a slow server)
> 
> dpkg --clear-avail
> Install+purge of an empty package:
>   0.182s on the slow server
>   3ish seconds on the desktop
> 
> The difference between those 0.182s and 3s is due to removed and even purged
> packages staying in the available file.

Hmm.  I've been wondering why upgrades seemed to take so long on my shiny
new desktop...

Here's a couple more data points for a 2GB/AMD64 box running 2.6.19.2 with
and ext3 filesystem.  My test package was the sid/etch ethereal 'dummy'
package.

Original baseline:
  % time (apt-get -y install ethereal && apt-get -y remove ethereal)
[ . . . ]
real  0m10.729s
user  0m6.692s
sys 0m1.224s
  I threw out the first couple iterations after which these timings were
  consistent to +- 0.1s across 5 subsequent samples.

Now, I blow away my (22 MB) /var/lib/dpkg/available file:
  % dpkg --clear-avail

  % time (apt-get -y install ethereal && apt-get -y remove ethereal)
[ . . . ]
real  0m6.492s
user  0m4.124s
sys 0m0.800s
  I threw out the first couple iterations after which these timings were
  consistent to +- 0.1s across 5 subsequent samples.

--> Result: 40% faster with an empty 'available' file.

On a whim I enabled dir_index on my ext3 FS, _and_ rebuilt info/:
  % cd /var/lib/dpkg/
  % cp -a info info.tmp
  % mv info info.orig
  % mv info.tmp info
I gather that should both defrag the info files (FWIW), and rebuild the
director using the hashed b-trees.  (I don't see how the hashed b-trees
could impact this particular test, but what the hell...)

Then I redid the timing test:
%time (apt-get -y install ethereal && apt-get -y remove ethereal)
  [ . . . ]
  real  0m6.847s
  user  0m4.100s
  sys 0m0.776s

--> Result: No difference at all this time...

Then I replaced the 'available' file with an archived version and ran
the test again:
%time (apt-get -y install ethereal && apt-get -y remove ethereal)
  [ . . . ]
  real  0m10.869s
  user  0m6.592s
  sys 0m1.228s

--> Result: right back to the original (slow) baseline times

Looks like '/var/lib/dpkg/available' is the main culprit here.  (I wish I
could test the same setup on a different filesystem like JFS though...)

-- Brad


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

Re: Ethernet interface numbering in etch

[Javier Fernández-Sanguino Peña]

On Thu, Mar 29, 2007 at 11:34:53AM +1100, Russell Coker wrote:
> The current functionality in regard to Xen is seriously broken.  A reasonable 
> person will expect that when a Xen virtual machine is configured with a 
> single Ethernet interface then it can be restarted at any time and get the 
> same name - eth0.  The current functionality for Xen breaks user expectations 
> and does not provide any benefit that I can imagine.

If this is so important, why, after so many many months of freeze, no Xen
users found this and submited a bug report? (Now its #413601, filed 24 days
ago)

> I believe that this fix is worthy of inclusion at this time.

I disagree. Not only because the bug is not RC, but because you could say the
same for users running other virtualization technologies (UML? Vmware?) with
similar behaviours. 

I'm in favor of adding a note in the Release Notes but I think we should not
delay the release (*again*) by modifying such a critical element as udev
right now.

Regards

Javier


signature.asc
Description: Digital signature

Re: Ethernet interface numbering in etch

[Javier Fernández-Sanguino Peña]

On Fri, Mar 30, 2007 at 05:19:25AM -0400, Nathanael Nerode wrote:
> Anyone have any thoughts on where and how this should be documented?
> Which documents do we need to make patches for and how detailed should
> the description in each document be?

I think the appropiate location is the Release Notes' chapter "Issues to be
aware of for etch":
http://www.debian.org/releases/etch/i386/release-notes/index.en.html#contents

More specifically the subsection "Switching to 2.6 may activate udev" under
section "5.2 Upgrading to a 2.6 kernel":
http://www.debian.org/releases/etch/i386/release-notes/ch-information.en.html#s-2.6-udev
(the subsection title needs to be fixed: s/may/will/)

Regards

Javier


signature.asc
Description: Digital signature

Bug#416871: ITP: debreaper -- bring peace to the poor souls of crashed applications

[Josselin Mouette]

Package: wnpp
Severity: wishlist
Owner: Josselin Mouette <[EMAIL PROTECTED]>

* Package name: debreaper
  Version : 0.1
  Upstream Author : myself
* URL : None yet (will be on alioth in pkg-gnome if there 
are no objections)
* License : GPL
  Programming Lang: Python
  Description : bring peace to the poor souls of crashed applications

 The Debian Reaper collects the souls of crashed applications, and 
 gathers information from the process and the system to write a nice bug 
 report. The package can then find peace in the BTS.
 .
 Debreaper is meant to be a drop-in replacement for the GNOME signal 
 handler, but can easily be used by any other software. It attempts to 
 remain as simple as bug-buddy, and makes use of the user's configured 
 mail client to send the report.

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


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

Re: Slow package database

[Ganesan Rajagopal]

> "Roberto" == Roberto C Sánchez <[EMAIL PROTECTED]> writes:

> Interesting.  I have ~1600 packages installed on my development machine
> and I do not experience the slowness you talk about.  It was installed
> about 3.5 years ago.

> How much RAM/CPU does the machine have?  How fast are the disks?

I have a Athlon X2 3800+ with 2Gig of RAM. To install a single package it
takes 10s real time. I have a SATA 250GB disk. I have ~1500 packages
installed. On a 2.8 Ghz P4 with 512MB RAM (~1800 packages) it does take 20-30
seconds. I also note that dselect eats up 40+ MB on this second machine and
really slows down the machine during an install. 

-- 
Ganesan Rajagopal


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