Re: Package search engine unusable

[Wolfgang Pfeiffer]

On Tue, 9 Jan 2018 19:37:03 +
Brian Potkin  wrote:

> On Tue 09 Jan 2018 at 13:15:34 +0100, Wolfgang Pfeiffer wrote:
> 
> > On Tue, 9 Jan 2018 08:27:35 +0100
> > Tomas Pospisek  wrote:
> >   
> > > Am 04.01.2018 um 20:21 schrieb Wolfgang Pfeiffer:
> > >   
> > > > I tried to use
> > > > https://www.debian.org/distrib/packages
> > > > 
> > > > to search for the latest linux-image packages. With no luck. At best
> > > > I find dbg versions
> > > > https://packages.debian.org/search?searchon=contents&keywords=linux-image&mode=filename&suite=stable&arch=any
> > > > 
> > > > With google no problem. Search patterns:
> > > > debian linux-image amd64 unstable
> > > 
> > > Can you please file a bug against the "debian-www" pseudo-package?
> > > *t  
> > 
> > Please see:
> > "Debian Archived Bug report logs: Bugs in package debian-www
> > 
> > There is no maintainer for debian-www. This means that this package no
> > longer exists (or never existed). Please do not report new bugs against
> > this package."
> > https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;package=debian-www#_4_6_5
> > 
> > Now what? ... :)  
> 
> www.debian.org as the package.

Thanks!

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886792

Regards,
Wolfgang Pfeiffer

> 
> > PS: 
> > I'm not subscribed to debian-www@lists.debian.org. Please CC me
> > when responding. Thanks.  

Re: Package search engine unusable

[Brian Potkin]

On Tue 09 Jan 2018 at 13:15:34 +0100, Wolfgang Pfeiffer wrote:

> On Tue, 9 Jan 2018 08:27:35 +0100
> Tomas Pospisek  wrote:
> 
> > Am 04.01.2018 um 20:21 schrieb Wolfgang Pfeiffer:
> > 
> > > I tried to use
> > > https://www.debian.org/distrib/packages
> > > 
> > > to search for the latest linux-image packages. With no luck. At best
> > > I find dbg versions
> > > https://packages.debian.org/search?searchon=contents&keywords=linux-image&mode=filename&suite=stable&arch=any
> > > 
> > > With google no problem. Search patterns:
> > > debian linux-image amd64 unstable  
> > 
> > Can you please file a bug against the "debian-www" pseudo-package?
> > *t
> 
> Please see:
> "Debian Archived Bug report logs: Bugs in package debian-www
> 
> There is no maintainer for debian-www. This means that this package no
> longer exists (or never existed). Please do not report new bugs against
> this package."
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;package=debian-www#_4_6_5
> 
> Now what? ... :)

www.debian.org as the package.

> PS: 
> I'm not subscribed to debian-www@lists.debian.org. Please CC me
> when responding. Thanks.

Done.

-- 
Brian.

Re: Package search engine unusable

[Wolfgang Pfeiffer]

On Tue, 9 Jan 2018 08:27:35 +0100
Tomas Pospisek  wrote:

> Am 04.01.2018 um 20:21 schrieb Wolfgang Pfeiffer:
> 
> > I tried to use
> > https://www.debian.org/distrib/packages
> > 
> > to search for the latest linux-image packages. With no luck. At best
> > I find dbg versions
> > https://packages.debian.org/search?searchon=contents&keywords=linux-image&mode=filename&suite=stable&arch=any
> > 
> > With google no problem. Search patterns:
> > debian linux-image amd64 unstable  
> 
> Can you please file a bug against the "debian-www" pseudo-package?
> *t

Please see:
"Debian Archived Bug report logs: Bugs in package debian-www

There is no maintainer for debian-www. This means that this package no
longer exists (or never existed). Please do not report new bugs against
this package."
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;package=debian-www#_4_6_5

Now what? ... :)

HTH

PS: 
I'm not subscribed to debian-www@lists.debian.org. Please CC me
when responding. Thanks.
-- 
Wolfgang Pfeiffer

Re: Package search engine unusable

[Tomas Pospisek]

Am 04.01.2018 um 20:21 schrieb Wolfgang Pfeiffer:

> I tried to use
> https://www.debian.org/distrib/packages
> 
> to search for the latest linux-image packages. With no luck. At best
> I find dbg versions
> https://packages.debian.org/search?searchon=contents&keywords=linux-image&mode=filename&suite=stable&arch=any
> 
> With google no problem. Search patterns:
> debian linux-image amd64 unstable

Can you please file a bug against the "debian-www" pseudo-package?
*t

suggestion for package search page wording (was: Re: Package search function bug)

[Philip Hands]

Hi,

In message <20150708110650.ga30...@mraw.org> to debian-project
Cyril Brulebois  replied thus::

> Hi,
>
> Vlatko Šurlan  (2015-07-08):
>> Dear all,
>> the package search function 
>> at https://www.debian.org/distrib/packages#search_contents
>> gives nothing for when 'convert' alone but when searcinh '/usr/bin/convert' 
>> there are results.
>> Sounds like some sort of a bug to me.
>
> did you notice this at the top?
>
> You have searched for paths that end with convert in suite jessie, all
> sections, and all architectures. Found 102 results. 
> 
> [icon] Note: Your search was too wide so we will only display only the
> first about 100 matches. Please consider using a longer keyword or
> more keywords.

I note that that last sentence is a bit mangled, with "only display
only" etc.

Perhaps it should read:

  Note: Your search gave too many results, so only the first 100 (or so)
  are displayed here. Please consider using a longer keyword or more
  keywords.

Cheers, Phil.

(I'm not subscribed to -www, so please CC me if you want me to read any reply)
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Package search broken: "packages that contain files named like this" in unstable

[Simon Paillard]

Hi,

On Sun, May 19, 2013 at 02:05:03PM +0200, Roland Stigge wrote:
> the search form at http://www.debian.org/distrib/packages, when using
> the "packages that contain files named like this" option, works for
> stable and testing, but not for unstable.

Thanks for the notice.

The generation of the file containing, for all archs, the reverse map file ->
package, is very long for a reason I don't understand for the moment.

In detail, sort -T seems to block while there are both enough ram and disk to
handle that.

As this never ends, the db file generated from the sort -T output is never
considered finished, and never put in place for packages.d.o operation. 

I'll copy the files from picconi and try to reproduce that at home..

-- 
Simon Paillard


-- 
To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130519174123.gv4...@glenfiddich.mraw.org

Re: Package search on packages.debian.org giving a 500 error

[Paul Wise]

On Wed, Apr 24, 2013 at 1:53 AM, Guruprasad wrote:

> I tried to do a package search on packages.debian.org

The packages site is having trouble, people are working on it:

http://lists.debian.org/debian-infrastructure-announce/2013/04/msg0.html

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6f3v16bdioiqf36wkfdefozwqggrkjc+hw4ozym0gq...@mail.gmail.com

Re: Package search function is failing

[Christian Andersson]

Sorry my bad xbmc comes from the marillat sources. PLease disregard my
previous email.

On Tue, Mar 22, 2011 at 6:55 AM, Christian Andersson <
christian.andersson...@gmail.com> wrote:

> Hi,
>
> When searching for "xbmc" in the package search (and selecting unstable) I
> get no results.When i do apt-cache search on my debian unstalbe system i get
> a package with the name "xbmc". Please investigate.
>
> /Chris
>

Re: Package search broken due to a "Content Encoding Error"

[Toni Mueller]

Hi Simon,

On Mon, 02.11.2009 at 12:02:18 +0100, Simon Paillard 
 wrote:
> I cannot reproduce your problem by searching for vim with german locale and
> Iceweasel from Lenny.

I usually have the English locale selected, also this time, and I just
checked again, and it worked.

> Do you still reproduce your issue ?

No.

> Which is the exact search that you perform ?

I was searching for 'sec', distribution 'any'.


-- 
Kind regards,
--Toni++


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

Re: Package search broken due to a "Content Encoding Error"

[Simon Paillard]

Hi Toni,

On Mon, Nov 02, 2009 at 10:46:31AM +0100, Toni Mueller wrote:
> http://www.debian.org/distrib/packages
> Then I entered a package name and pressed "Search". I got this error
> message:
> 
> Content Encoding Error
> The page you are trying to view cannot be shown because it uses an invalid or 
> unsupported form of compression.
> * Please contact the website owners to inform them of this problem.
> 
> I'm using this browser:
> Mozilla/5.0 (X11; U; Linux x86_64; de-DE; rv:1.9.0.15) Gecko/2009102814 
> Iceweasel/3.0.6 (Debian-3.0.6-3)
> on my Lenny desktop...

I cannot reproduce your problem by searching for vim with german locale and
Iceweasel from Lenny.

Do you still reproduce your issue ? Which is the exact search that you
perform ?

-- 
Simon Paillard


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

Re: package search problem

[Frank Lichtenheld]

On Mon, Sep 10, 2007 at 07:19:12PM -0500, Andrew Golding wrote:
> I got this problem while searching for MySQL packages.  This is  
> certainly a new problem.
> 
> start--
> >> Debian  >> Packages  >> Package Search Results
> 
> You can try a different search on the Packages search page.
> 
> You have searched for packages that names contain mysql in all  
> suites, all sections, and all architectures .
> 
> Your search was too wide so we will only display exact matches. At  
> least 100 results have been omitted and will not be displayed. Please  
> consider using a longer keyword or more keywords.
> 
> Sorry, your search gave no results
> --end
> 
> Wow, not quite sure what to say about this...

So what? I guess we can increase that number a bit now that we see, that
the new code is indeed a huge performance increase, but there still will
be a limit. If you want to make arbitrary queries about Debian packages,
use your own machine's resources.

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Re: package search won't do arch=all

[Dave Love]

Gerfried Fuchs <[EMAIL PROTECTED]> writes:

> Hi!
>
>  It's a bit delayed, but I don't see that you have been answered yet,
> so

I'm not sure I understand what was going on, especially as I thought
it was an Ubuntu-specific server, but it looks OK now anyway.

Cheers.


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

Re: package search won't do arch=all

[Gerfried Fuchs]

Hi!

 It's a bit delayed, but I don't see that you have been answered yet,
so

* Dave Love <[EMAIL PROTECTED]> [2006-07-10 16:46]:
> Searching on packages.debian.org doesn't seem to include the `all'
> architecture, e.g. this link from the package's page returns nothing:

* Thomas Zander <[EMAIL PROTECTED]> [2006-07-11 22:01]:
> This is true for many packages; but try this one:

 The problem were due to that it was needed to restrict some hosts for
more close inspections due to a breakin on one of the main servers.
These issues are resolved and the search on all packages work again.

 Thomas, please notice that even when specify arch=all you still search
on an arch, because there is no arch all, there are only packages that
are the same for all architectures (in contrary to arch="any" binary
packages). I can understand that this might be a bit misleading that the
interface displayes architecture i386, but it's alright and needed.

 So long,
Alfie
-- 
wenn sich aber manche howto und man und was weiß ich nicht
für installanleitungen und hilfen sich anschaut, fragt man sich
wirklichen ob das nicht ausserirdische gepinselt haben, oder nicht
  -- _[puffy]_ in #debian.de


signature.asc
Description: Digital signature

RE: Package search fails since days

[Alexander Schories]

Hello Adam, Hello Kaare, Hello admins,

> 
> It's often painfully slow.

Puhh..and i thought it may be just my imagination (or my network..), because
sometimes it works fine.. :)

> 
> saens.debian.org, aka packages.d.o and ftp.d.o is apparently currently
> running with a load average in the region of 130-140; aiui 
> the sysadmins
> (DSA) are being informed.

Ahh! Thank you ALL very much for your hard work!!

> 
> Regards,
> 
> Adam

Kind Regards

Alexander Schories
Tuebingen, Germany


If privacy or security of communication is on your mind, feel free to
establish a secure transmission using the PGP public key obtainable from
http://www.schories.com/alexander/pubkey/alexander_schories.asc


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

Re: Package search fails since days

[Adam D. Barratt]

On Wed, 2006-01-04 at 14:37 +0100, Kaare Olsen wrote:
> On Wed, 4 Jan 2006 10:07:20 +0100
> "Alexander Schories" <[EMAIL PROTECTED]> wrote:
> 
> > e.g. this doesn`t work anymore:
> > 
> > http://packages.debian.org/cgi-bin/search_packages.pl?keywords=php5&searchon
> > =names&subword=1&version=all&release=all
> 
> That search works nicely for me:  "Found 29 matching packages, displaying 
> packages 1 to 29." - followed by the expected list.

It's often painfully slow.

saens.debian.org, aka packages.d.o and ftp.d.o is apparently currently
running with a load average in the region of 130-140; aiui the sysadmins
(DSA) are being informed.

Regards,

Adam


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

Re: Package search fails since days

[Kaare Olsen]

On Wed, 4 Jan 2006 10:07:20 +0100
"Alexander Schories" <[EMAIL PROTECTED]> wrote:

> e.g. this doesn`t work anymore:
> 
> http://packages.debian.org/cgi-bin/search_packages.pl?keywords=php5&searchon
> =names&subword=1&version=all&release=all

That search works nicely for me:  "Found 29 matching packages, displaying 
packages 1 to 29." - followed by the expected list.

-- 
Regards, Kaare - 


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

Re: package search

[Gerfried Fuchs]

* Christopher Mauger <[EMAIL PROTECTED]> [2003-11-27 19:23]:
>   For the last couple of days, I have been unable to 
> search directories or contents of packages.  I go to the 
> page:http://www.debian.org/distrib/packages, put in a keyword 
> and press search.  After that my browser is in ``waiting for reply'' 
> mode.  

 Yes, the service is still down and in the restore phase due to the
server compromise Debian was faces:


 Would be a good time to subscribe to the debian-announce list to not
miss such improntant informations again :-)

 So long,
Alfie
-- 
"Where do you want to go today?
 Somewhere, somewhere you could never take me"
  -- Chumbawamba, "Pass It Along"


pgpQ0VN8E1kQ7.pgp
Description: PGP signature

Re: Package search improvements

[Frank Lichtenheld]

On Wed, Apr 23, 2003 at 06:36:44PM +0200, Josip Rodin wrote:
> On Wed, Apr 23, 2003 at 08:43:53AM -0700, Matt Kraai wrote:
> > > > [some usefull thoughts skipped]
> > > 
> > > Hmm. IMHO it would be good to have a test system, where one can
> > > commiting to the CVS without breacking the running system.
> > 
> > Just test your changes before committing.
> 
> They require access to a bunch of Packages files... but then, Alioth isn't
> set up for this either, quantz.d.o doesn't hold a copy of the archive.
> 
> Both quantz (Alioth) and vlaai (ftp.nl) are on SURFnet, so I guess I could
> check with ftp.nl guys if we could NFS-mount it.

Hi.

After the opinions I heard ("do it at home" from Matt, "use a
branch" from Alfie, and the above statement about alioth from Joy),
I currently plan to do the following:
 - I will make a project on alioth for the sake of shell access to a
   server on which I could set up a testing page.
   For the beginning it will definetly suffice to just get some sample
   Packages files via scp or wget.
 - Probably I will not use alioth for cvs because this is just
   confusing. I will use a branch for the existing directory.

I don't want to do this in private, because I will need probably some feedback
and some testing, therefore the placing on alioth.

Suggestions? Objections?

Frank

PS: Need I a DD to set up a project on alioth?

-- 
*** Frank Lichtenheld <[EMAIL PROTECTED]> ***
  *** http://www.djpig.de/ ***
see also: - http://www.usta.de/
  - http://fachschaft.physik.uni-karlsruhe.de/

pgpU6ZrmrwA9c.pgp
Description: PGP signature

Re: Package search improvements

[Josip Rodin]

On Thu, Apr 24, 2003 at 06:37:11PM +0200, Frank Lichtenheld wrote:
> > (On a more subjective note, perhaps we should rip swish++ out and replace it
> > with a Perl script as well. >:|)
> 
> I second this. Real subword search should be available at least for the
> package name (and perhaps the short description).

Yeah. With mod_perl, we possibly wouldn't have anything to gain from a
binary database, but just use Perl for what it's intended to do.

> And as I recall, switching to a newer swish++ version failed (?).

Yes. I upgraded to 5.1 I think, and it kept crashing.

-- 
 2. That which causes joy or happiness.

Re: Package search improvements

[Frank Lichtenheld]

On Wed, Apr 23, 2003 at 10:20:48AM +0200, Josip Rodin wrote:
> Making packages.d.o backend first parse all Packages files from all
> architectures, sort -u the list, and then go through the data ordering it
> per package, would seem to do the trick. Of course it would also track
> Architecture fields and pass them as parameters to download.pl.

Hmm, presenting a table with all architectures and the version of the
current package in a given distribution will not be so tricky. But (as
also stated somewhere (was it website/todo?)) the dependencies can be
a little tricky when then differ beetween the archs. But let's wait
and see.

Also thought of the next step: DDTP integration. But let us do it one
by one :)

Frank

-- 
*** Frank Lichtenheld <[EMAIL PROTECTED]> ***
  *** http://www.djpig.de/ ***
see also: - http://www.usta.de/
  - http://fachschaft.physik.uni-karlsruhe.de/

Re: Package search improvements

[Frank Lichtenheld]

On Wed, Apr 23, 2003 at 06:32:26PM +0200, Josip Rodin wrote:
> (On a more subjective note, perhaps we should rip swish++ out and replace it
> with a Perl script as well. >:|)

I second this. Real subword search should be available at least for the
package name (and perhaps the short description). And as I recall,
switching to a newer swish++ version failed (?).

-- 
*** Frank Lichtenheld <[EMAIL PROTECTED]> ***
  *** http://www.djpig.de/ ***
see also: - http://www.usta.de/
  - http://fachschaft.physik.uni-karlsruhe.de/

Re: Package search improvements

[Marek Łaska]

And sorry for the duplicates
Pozdrawiam
-- 
Marek 'TamCaP' Łaska
Zdrowy rozsądek to zbiór uprzedzeń nabytych do osiemnastego roku życia. - 
Albert Einstein

Re: Package search improvements

[Marek Łaska]

Hullo all...
Pewnego dnia (Wednesday 23 of April 2003 10:20), niejak(i/a) Josip Rodin 
wystukał/a na klawiaturze:
JR>Making packages.d.o backend first parse all Packages files from all
JR>architectures, sort -u the list, and then go through the data ordering it
JR>per package, would seem to do the trick. Of course it would also track
JR>Architecture fields and pass them as parameters to download.pl.
Sure, but have You considered the version conflicts? Package for i386 will 
surely be in other version than for e.g. sparc...
And if we want not to generate those pages on demand AND not have single pages 
for all ports, then we could just move some work to download.pl... --> read 
below
JR>(Heck, even download.pl could be eliminated, it's not like anyone changes
JR>the selected mirrors often (they're selected for the very purpose of being
JR>reliable and not necessary to change).)
I think the idea of download.pl right now just wastes the CPU...
But if we would send download.pl additional $arch parameter and make 
download.pl just show which version is the most actual (and also maybe show 
all that depend/suggest/etc. stuff) it would be working fine. As far as I can 
see it, we could also get rid of multiple pages of the same packages for the 
same port, just stabe/testing/unstable/(exp.) versions - just use old good 
$type.
I see it that way.
Someone searches for a package and gets a list. Then he opens a page, one 
for all ports, generated once in 24h describing the package and if he wants 
to get the stuff, he just makes choice what port and what version and goes to 
download.pl.
Waiting for comments
Pozdrawiam
-- 
Marek 'TamCaP' Łaska
Żyć jest bardzo niezdrowo. Kto żyje ten umiera. - Stanisław Jerzy Lec

Re: Package search improvements

[Marek Łaska]

Hullo all...
Pewnego dnia (Wednesday 23 of April 2003 10:20), niejak(i/a) Josip Rodin 
wystukał/a na klawiaturze:
JR>Making packages.d.o backend first parse all Packages files from all
JR>architectures, sort -u the list, and then go through the data ordering it
JR>per package, would seem to do the trick. Of course it would also track
JR>Architecture fields and pass them as parameters to download.pl.
Sure, but have You considered the version conflicts? Package for i386 will 
surely be in other version than for e.g. sparc...
And if we want not to generate those pages on demand AND not have single pages 
for all ports, then we could just move some work to download.pl... --> read 
below
JR>(Heck, even download.pl could be eliminated, it's not like anyone changes
JR>the selected mirrors often (they're selected for the very purpose of being
JR>reliable and not necessary to change).)
I think the idea of download.pl right now just wastes the CPU...
But if we would send download.pl additional $arch parameter and make 
download.pl just show which version is the most actual (and also maybe show 
all that depend/suggest/etc. stuff) it would be working fine. As far as I can 
see it, we could also get rid of multiple pages of the same packages for the 
same port, just stabe/testing/unstable/(exp.) versions - just use old good 
$type.
I see it that way.
Someone searches for a package and gets a list. Then he opens a page, one 
for all ports, generated once in 24h describing the package and if he wants 
to get the stuff, he just makes choice what port and what version and goes to 
download.pl.
Waiting for comments
Pozdrawiam
-- 
Marek 'TamCaP' Łaska
Żyć jest bardzo niezdrowo. Kto żyje ten umiera. - Stanisław Jerzy Lec

Re: Package search improvements

[Josip Rodin]

On Wed, Apr 23, 2003 at 08:43:53AM -0700, Matt Kraai wrote:
> > > [some usefull thoughts skipped]
> > 
> > Hmm. IMHO it would be good to have a test system, where one can
> > commiting to the CVS without breacking the running system.
> 
> Just test your changes before committing.

They require access to a bunch of Packages files... but then, Alioth isn't
set up for this either, quantz.d.o doesn't hold a copy of the archive.

Both quantz (Alioth) and vlaai (ftp.nl) are on SURFnet, so I guess I could
check with ftp.nl guys if we could NFS-mount it.

-- 
 2. That which causes joy or happiness.

Re: Package search improvements

[Josip Rodin]

On Wed, Apr 23, 2003 at 10:51:02AM +0100, Colin Watson wrote:
> > > It's disk space against cpu usage. Clearly the first is much
> > > cheaper.
> > 
> > Perhaps I should also mention the exact cause of those 500 errors that
> > was briefly mentioned on -www recently -- the MaxClients 300 setting
> > on gluck exceeds the maxproc 256 setting. Of course, this is a bug,
> > and it will be fixed, but this still means that apache on the machine
> > often runs two hundred processes as it is, so adding more CGIs/PHPs
> > wouldn't exactly be the happiest solution.
> 
> Sane performance tuning strategies dictate that more stuff should be
> in-process, then. Is mod_perl feasible?

Most time is spent on swish++ searching its indices and grepping contents
files, so I don't think mod_perl would be an immediate solution... although
I if we switch from actually forking grep(1) for the contents files and then
use mod_perl, then it might be considerably beneficial.

(On a more subjective note, perhaps we should rip swish++ out and replace it
with a Perl script as well. >:|)

-- 
 2. That which causes joy or happiness.

Re: Package search improvements

[Matt Kraai]

On Wed, Apr 23, 2003 at 04:18:36PM +0200, Frank Lichtenheld wrote:
> On Wed, Apr 23, 2003 at 09:37:53AM +0800, Andrew Shugg wrote:
> > [some usefull thoughts skipped]
> 
> Hmm. IMHO it would be good to have a test system, where one can
> commiting to the CVS without breacking the running system.

Just test your changes before committing.

Matt
-- 
Matt Kraai <[EMAIL PROTECTED]>
Debian GNU/Linux Peon

Re: Package search improvements

[Frank Lichtenheld]

On Wed, Apr 23, 2003 at 09:37:53AM +0800, Andrew Shugg wrote:
> [some usefull thoughts skipped]

Hmm. IMHO it would be good to have a test system, where one can
commiting to the CVS without breacking the running system.

What do you others think of an alioth project for this?
It could start with a copy of the actual cvs repository and
then all people who are actually interested can contribute and
test without breaking anything in the meantime.

Or better a new directory on cvs.debian.org? or a branch?
Opinions?

Frank

-- 
*** Frank Lichtenheld <[EMAIL PROTECTED]> ***
  *** http://www.djpig.de/ ***
see also: - http://www.usta.de/
  - http://fachschaft.physik.uni-karlsruhe.de/

Re: Package search improvements

[Jose Carlos Garcia Sogo]

On Wed, Apr 23, 2003 at 10:51:02AM +0100, Colin Watson wrote:
> On Wed, Apr 23, 2003 at 10:20:48AM +0200, Josip Rodin wrote:
> > On Wed, Apr 23, 2003 at 01:50:26AM +0200, Frank Lichtenheld wrote:
> > > It's disk space against cpu usage. Clearly the first is much
> > > cheaper.
> > 
> > Perhaps I should also mention the exact cause of those 500 errors that
> > was briefly mentioned on -www recently -- the MaxClients 300 setting
> > on gluck exceeds the maxproc 256 setting. Of course, this is a bug,
> > and it will be fixed, but this still means that apache on the machine
> > often runs two hundred processes as it is, so adding more CGIs/PHPs
> > wouldn't exactly be the happiest solution.
> 
> Sane performance tuning strategies dictate that more stuff should be
> in-process, then. Is mod_perl feasible?

 Or libapache-mod-speedycgi if there's enough spare RAM available.

 /me hides

-- 
  Jose Carlos Garcia Sogo
 [EMAIL PROTECTED]


pgpHBIUMEx4D4.pgp
Description: PGP signature

Re: Package search improvements

[Colin Watson]

On Wed, Apr 23, 2003 at 10:20:48AM +0200, Josip Rodin wrote:
> On Wed, Apr 23, 2003 at 01:50:26AM +0200, Frank Lichtenheld wrote:
> > It's disk space against cpu usage. Clearly the first is much
> > cheaper.
> 
> Perhaps I should also mention the exact cause of those 500 errors that
> was briefly mentioned on -www recently -- the MaxClients 300 setting
> on gluck exceeds the maxproc 256 setting. Of course, this is a bug,
> and it will be fixed, but this still means that apache on the machine
> often runs two hundred processes as it is, so adding more CGIs/PHPs
> wouldn't exactly be the happiest solution.

Sane performance tuning strategies dictate that more stuff should be
in-process, then. Is mod_perl feasible?

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Package search improvements

[Josip Rodin]

On Wed, Apr 23, 2003 at 01:50:26AM +0200, Frank Lichtenheld wrote:
> It's disk space against cpu usage. Clearly the first is much cheaper.

Perhaps I should also mention the exact cause of those 500 errors that was
briefly mentioned on -www recently -- the MaxClients 300 setting on gluck
exceeds the maxproc 256 setting. Of course, this is a bug, and it will be
fixed, but this still means that apache on the machine often runs two
hundred processes as it is, so adding more CGIs/PHPs wouldn't exactly be the
happiest solution.

Some might mention, why don't we put it on another machine -- we do that
kind of stuff already, but even so, we shouldn't waste stuff on principle,
and fact is that most of the scripts are lightweight (download.pl,
subscribe.pl or redirect.pl), and those that aren't, suck :) (searchlists).

Making packages.d.o backend first parse all Packages files from all
architectures, sort -u the list, and then go through the data ordering it
per package, would seem to do the trick. Of course it would also track
Architecture fields and pass them as parameters to download.pl.

(Heck, even download.pl could be eliminated, it's not like anyone changes
the selected mirrors often (they're selected for the very purpose of being
reliable and not necessary to change).)

> The only question I have: When I want to help on this, in which
> direction should I go so that when I invested some time in it I will 
> not just hear: "Nice what you've done, but completly useless for us"

I'm sure my constant bitch^Wsteering in the right direction will prevent
that ;)

-- 
 2. That which causes joy or happiness.

Re: Package search improvements

[Andrew Shugg]

Frank Lichtenheld said:
> "Anyone got ideas on doing this without replicating the entire page
> structure for each port?" 
> This leads at least to two possible solutions: 2.) (one page per
> package per distrib but for all archs) or 3.) (create the pages
> dynamically). And what one finds more "clean" of them both is obviously
> a question of his definition of "clean" which seems to be differ
> between us both. For me "clean" means: It's good structured, easily
> to extend and maintain.

I think the pages should continue to be statically generated: for the
information that is 'worth' dynamic generation I think it's all on
Raphael's Package Tracking System website.

One page per package, and that page should indicate which
architecture(s) the package is available for.  And when I say "is
available" I guess you have two choices: just go by what the package
information says the package _should_ be built for, or (more complexly)
you could find the latest version of each package for each architecture
to cater for some arches being ahead of others.  (You may be able to
conveniently retrieve this from the PTS.)

Even if you go by the first option, I think this will add a lot more
useful functionality to packages.debian.org; adding a drop-down list to
select an architecture for the download.cgi form would then be trivial
and make a lot of people happy.  It would also resolve the problem of
not being able to search for non-i386 packages (silo is the first that
leaps to mind).

Andrew.

-- 
Andrew Shugg <[EMAIL PROTECTED]>   http://www.neep.com.au/

"Just remember, Mr Fawlty, there's always someone worse off than yourself."
"Is there?  Well I'd like to meet him.  I could do with a good laugh."

Re: Package search improvements

[Frank Lichtenheld]

On Wed, Apr 23, 2003 at 12:51:00AM +0200, Josip Rodin wrote:
> On Tue, Apr 22, 2003 at 10:19:25PM +0200, Frank Lichtenheld wrote:
> > > FL>   3.) make 1.) but create the pages dynamically. This will
> > > FL>  require nearly a complete rewrite, but would be the
> > > FL> cleanest way, I think.
> > > Aren't the 'packages' pages already dynamically created???
> > 
> > Not really. With "dynamically created" I mean "on request". The
> > package pages are actually static pages created by a script running
> > as cronjob.
> 
> If you define 'cleanest' with 'the most k-rad k-cool method everyone else
> uses, regardless of actual purpose', sure. I wouldn't consider constantly
> wasting CPU cycles on stuff that only changes once every 24 hours
> particularly clean myself...

Hmm, you've a point here. It's disk space against cpu usage. Clearly
the first is much cheaper. That's why I wrote a mail one week (or so) ago
asking for input on this since I would really help here because it is
a long outstanding problem. And I presented the "dynamic"
version because of this sentence in the website/todo:
"Anyone got ideas on doing this without replicating the entire page
structure for each port?" 
This leads at least to two possible solutions: 2.) (one page per
package per distrib but for all archs) or 3.) (create the pages
dynamically). And what one finds more "clean" of them both is obviously
a question of his definition of "clean" which seems to be differ
between us both. For me "clean" means: It's good structured, easily
to extend and maintain.

The only question I have: When I want to help on this, in which
direction should I go so that when I invested some time in it I will 
not just hear: "Nice what you've done, but completly useless for us"

Programming is a hobby for me, not a religion. You can convince
me when you have good arguments (and you normally have).

Grüße,
Frank

-- 
*** Frank Lichtenheld <[EMAIL PROTECTED]> ***
  *** http://www.djpig.de/ ***
see also: - http://www.usta.de/
  - http://fachschaft.physik.uni-karlsruhe.de/

pgpdrnD0jpcbq.pgp
Description: PGP signature

Re: Package search improvements

[Josip Rodin]

On Tue, Apr 22, 2003 at 10:19:25PM +0200, Frank Lichtenheld wrote:
> > FL> 3.) make 1.) but create the pages dynamically. This will
> > FL>  require nearly a complete rewrite, but would be the
> > FL>   cleanest way, I think.
> > Aren't the 'packages' pages already dynamically created???
> 
> Not really. With "dynamically created" I mean "on request". The
> package pages are actually static pages created by a script running
> as cronjob.

If you define 'cleanest' with 'the most k-rad k-cool method everyone else
uses, regardless of actual purpose', sure. I wouldn't consider constantly
wasting CPU cycles on stuff that only changes once every 24 hours
particularly clean myself...

-- 
 2. That which causes joy or happiness.

Re: Package search improvements

[Frank Lichtenheld]

On Tue, Apr 22, 2003 at 08:54:47PM +0200, Marek ?aska wrote:
> Pewnego dnia (Thursday 17 of April 2003 18:31), niejak(i/a) Frank Lichtenheld 
> wystuka?/a na klawiaturze:
> FL>   3.) make 1.) but create the pages dynamically. This will
> FL>  require nearly a complete rewrite, but would be the
> FL> cleanest way, I think.
> Aren't the 'packages' pages already dynamically created???

Not really. With "dynamically created" I mean "on request". The
package pages are actually static pages created by a script running
as cronjob.

Frank

-- 
*** Frank Lichtenheld <[EMAIL PROTECTED]> ***
  *** http://www.djpig.de/ ***
see also: - http://www.usta.de/
  - http://fachschaft.physik.uni-karlsruhe.de/

Re: Package search improvements

[Marek Łaska]

Pewnego dnia (Thursday 17 of April 2003 18:31), niejak(i/a) Frank Lichtenheld 
wystukał/a na klawiaturze:
FL> 3.) make 1.) but create the pages dynamically. This will
FL>  require nearly a complete rewrite, but would be the
FL>   cleanest way, I think.
Aren't the 'packages' pages already dynamically created???
Greetz
-- 
Marek 'TamCaP' Łaska
Zaiste, wariat na swobodzie, największą klęską jest w przyrodzie. - Czesław 
Miłosz

Re: Package search improvements

[Frank Lichtenheld]

On Thu, Apr 17, 2003 at 12:49:21PM +0200, Josip Rodin wrote:
> On Tue, Apr 15, 2003 at 08:18:01PM +0200, Frank Lichtenheld wrote:
> > Surely, this has to be corrected, but obviously no one has
> > volunteered yet to build a new packages.d.o from the scratch.
> 
> Just to make sure nobody gets the wrong impression: it doesn't necessarily
> have to be rewritten from scratch to support multiple architectures.

Ok, thats right.
But from my point of view there exist at least three ways to implement
it:
1.) each architecture gets its own pages. That will be a lot
of files and I read from the statements on website/todo that
this is not the preferred way. Only small changes in code
needed though.

2.) all architectures are merged in one page per package per 
distrib. That would not change the number of pages (only some
non-i386 packages would be added.) but like also stated
on the todo site, it will be tricky to find a correct and
viewable layout. The code would not be the problem and can
be embedded in the existing one.

3.) make 1.) but create the pages dynamically. This will
  require nearly a complete rewrite, but would be the
  cleanest way, I think.

Frank

-- 
*** Frank Lichtenheld <[EMAIL PROTECTED]> ***
  *** http://www.djpig.de/ ***
see also: - http://www.usta.de/
  - http://fachschaft.physik.uni-karlsruhe.de/

Re: Package search improvements

[Josip Rodin]

On Tue, Apr 15, 2003 at 08:18:01PM +0200, Frank Lichtenheld wrote:
> Surely, this has to be corrected, but obviously no one has
> volunteered yet to build a new packages.d.o from the scratch.

Just to make sure nobody gets the wrong impression: it doesn't necessarily
have to be rewritten from scratch to support multiple architectures.

-- 
 2. That which causes joy or happiness.

Re: Package search is dead...

[Josip Rodin]

On Tue, Apr 15, 2003 at 07:14:45PM +0200, Frank Lichtenheld wrote:
> > Thought I'd drop you a line to let you know that the package search on
> > debian.org is dead :( (500 Internal Server), the URL that's causing the
> > problem (my exact search) is;
> > 
> > http://packages.debian.org/cgi-bin/search_packages.pl?keywords=djbdns&searchon=names&subword=1&version=all&release=all
> 
> Seems to have been a temporary problem. Works for me now.

It's a reoccurring problem that I've diagnosed and am waiting for
debian-admin to fix.

-- 
 2. That which causes joy or happiness.

Re: Package search improvements

[Frank Lichtenheld]

On Tue, Apr 15, 2003 at 07:16:45PM +0200, Carlos Izquierdo wrote:
> 
>   I've noticed that the "Search package directories" engine, located at 
> http://www.debian.org/distrib/packages, returns only results for the i386 
> architecture. Would it be possible to include an architecture drop-down list 
> just like the one that "Search the contents of packages" has?

Not at the moment.
This is a known issue (Bug#21620
) and a very
old one. Surely, this has to be corrected, but obviously no one has
volunteered yet to build a new packages.d.o from the scratch.

>   Also, clicking on certain PPC-specific packages using this later tool 
> returns a 404 Error (e.g.: searching for quik, the main executable in package 
> quik - Mac Linux Loader-, returns a link to base/quik at 
> http://packages.debian.org/stable/base/quik.html, which doesn't exist).

This is some sort of follow-up bug to the one above and also 
already filed (Bug#131631).

You can see all open bugs of www.debian.org by visiting 
http://bugs.debian.org/www.debian.org

thanks,
Frank Lichtenheld

-- 
*** Frank Lichtenheld <[EMAIL PROTECTED]> ***
  *** http://www.djpig.de/ ***
see also: - http://www.usta.de/
  - http://fachschaft.physik.uni-karlsruhe.de/

Re: Package search is dead...

[Frank Lichtenheld]

On Tue, Apr 15, 2003 at 03:44:20PM +0100, Matt Wilson wrote:
> Thought I'd drop you a line to let you know that the package search on
> debian.org is dead :( (500 Internal Server), the URL that's causing the
> problem (my exact search) is;
> 
> http://packages.debian.org/cgi-bin/search_packages.pl?keywords=djbdns&searchon=names&subword=1&version=all&release=all

Seems to have been a temporary problem. Works for me now.

Frank

-- 
*** Frank Lichtenheld <[EMAIL PROTECTED]> ***
  *** http://www.djpig.de/ ***
see also: - http://www.usta.de/
  - http://fachschaft.physik.uni-karlsruhe.de/

Re: Package search engine didn't find xxdiff when given "diff"

[Matt Kraai]

On Mon, Jan 13, 2003 at 06:21:49AM +1300, Craig Carey wrote:
> >  * Subword searching only checks for arbitrary suffixes, not prefixes.

It sucks, but at least it is documented.

Matt

Re: Package search problem

[James A. Treacy]

On Thu, May 17, 2001 at 12:05:46PM +0200, Nagy, Gabor wrote:
>  
> http://packages.debian.org/cgi-bin/search_packages.pl?keywords=*pam*&searcho
> n=all&subword=1&version=all&release=all
> 
> Debian package search results 
> - 
> Release   Package (size) 
> unstable  libpam-pgsql 0.5.1   (11.2k)  
>PAM module to authenticate using a PostgreSQL database 
> ...
> 
Note the third comment:
  appending an asterisk, '*', to the end of a keyword will allow...
 ^^^
To make this clearer, I have added a fourth comment:
  Subword searching only checks for arbitrary suffixes, not prefixes.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]