Re: Content of CDs / DVDs

[Bartosz Fenski aka fEnIo]

On Thu, Oct 21, 2004 at 04:43:51PM +1300, Matthew Currington wrote:
> >If not (and I'm assuming that's the right answer) then what about adding
> >some txt files alongside isos?
> >Simple list of packages shouldn't (and won't) take much space and will be
> >very helpful for newbies which still ask what are all of those CDs for.
> 
> Do you think a simple packages.html file would be better? Especially for 
> newbies.

Yes I do. Having simple packages.html is still better than having nothing.

regards
fEnIo

-- 
  _  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | 
IRC:fEnIo
_|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska
(0 0)  phone:+48602383548 | Slackware - the weakest link
ooO--(_)--Ooo  http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001


signature.asc
Description: Digital signature

discover and hotplug must be able to co-exists (was Re: discover or alsa?)

[A Mennucc]

hi
for as much as I loved the religion war of people-liking-discover 
against p-l-hotplug, (and then of p-l-udev vs p-l-devf vs p-l-/dev ), I 
think nobody stated the most important point: discover and hotplug must 
be able to co-exists.
The reason is in the dependencies: indeed
xserver-xfree86 Suggests: discover
(and indeed they were mantained by B.Robinson) whereas
  gnome-volume-manager Depends: udev , udev Depends: hotplug
so, on a typical install of Debian, it is quite possible that discover 
and hotplug are installed at the same time.

AFAIK, discover is needed by xserver-xfree86 only to detect and 
configure the server - but this is a very important functionality for 
the average user, and I would not neglect its usefulness.

Unless someone may go and rewrite xserver-xfree86 to suggest 'hotplug | 
discover', and use any of the two. (hotplug has a much wider list of 
rdependencies than discover, so it may be installed nonetheless).
(Ops I am becoming religious myself!)

a.

Re: discover and hotplug must be able to co-exists (was Re: discover or alsa?)

[Petter Reinholdtsen]

I agree that hotplug and discover must be able to co-exist on a
system.  And I believe they mostly do, as I have both installed. :)

[A Mennucc]
> Unless someone may go and rewrite xserver-xfree86 to suggest
> 'hotplug | discover', and use any of the two. (hotplug has a much
> wider list of rdependencies than discover, so it may be installed
> nonetheless).  (Ops I am becoming religious myself!)

How do I use hotplug to get the correct XFree86 driver for a given
video card?  I thought hotplug only did kernel modules.

update-menus , Re: dpkg and selinux

[A Mennucc]

Luke Kenneth Casson Leighton wrote
as an example, 80% of all debian postinst (post install) packages
on my computer result in the running of update-menus.
 

you don't need to change the whole of the packages to implement the above
just add a few diverts, create some specific locks , and check on exit 
of APT

example:
$ dpkg-divert --rename /usr/bin/update-menus
- file /usr/bin/update-menus
#!/bin/sh
touch /var/lock/post-update-menus
 file /etc/apt/apt.conf.d/post-update-menus
DPkg {
   Post-Invoke {"test -f /var/lock/post-update-menus && 
update-menus.distrib ; rm -f /var/lock/post-update-menus ";};
}
--

that's all folks
the case of scrollkeeper is obviously the same.
But I would not do this for ldconfig:
what if a package needs a library it depends on to configure itself?
a.

Re: discover and hotplug must be able to co-exists (was Re: discover or alsa?)

[Mike Hommey]

On Thu, Oct 21, 2004 at 09:52:10AM +0200, A Mennucc wrote:
> so, on a typical install of Debian, it is quite possible that discover 
> and hotplug are installed at the same time.

It's more than quite possible, it's what you get after installing sarge,
except if it changed since the snapshot I tried.

Mike 

Re: discover and hotplug must be able to co-exists (was Re: discover or alsa?)

[A Mennucc]

Petter Reinholdtsen wrote:
I agree that hotplug and discover must be able to co-exist on a
system.  And I believe they mostly do, as I have both installed. :)
[A Mennucc]
 

Unless someone may go and rewrite xserver-xfree86 to suggest
'hotplug | discover', and use any of the two. (hotplug has a much
wider list of rdependencies than discover, so it may be installed
nonetheless).  (Ops I am becoming religious myself!)
   

How do I use hotplug to get the correct XFree86 driver for a given
video card?  I thought hotplug only did kernel modules.
 

ops. Since hotplug deals with PCI cards, I assumed that it would know of 
video cards as well; if this is not the case, then  maybe the best way 
out would be that: mantainers of discover split discover in two, 
discover-X11 and discover (all the rest), whereas discover-X11 will be 
used by xserver-xfree86, but it will not touch anything else; and 
everybody will be happy ever after.

a.

Re: update-menus , Re: dpkg and selinux

[A Mennucc]

I tested it and it seems ok; so
I sent the following proposal as a wishlist bug for 'menu'
A Mennucc wrote:
Luke Kenneth Casson Leighton wrote
as an example, 80% of all debian postinst (post install) packages
on my computer result in the running of update-menus.
 

you don't need to change the whole of the packages to implement the above
just add a few diverts, create some specific locks , and check on exit 
of APT

example:
$ dpkg-divert --rename /usr/bin/update-menus
- file /usr/bin/update-menus
#!/bin/sh
touch /var/lock/post-update-menus
 file /etc/apt/apt.conf.d/post-update-menus
DPkg {
   Post-Invoke {"test -f /var/lock/post-update-menus && 
update-menus.distrib ; rm -f /var/lock/post-update-menus ";};
}
--

that's all folks
the case of scrollkeeper is obviously the same.
But I would not do this for ldconfig:
what if a package needs a library it depends on to configure itself?
a.

Re: Bug#276306: dpkg -P backuppc fails (debconf problem ?)

[Frank Küster]

Ludovic Drolez <[EMAIL PROTECTED]> wrote:

> Frank Küster wrote:
>> Please try to debug by putting a "set -x" into
>> /var/lib/dpkg/info/backuppc.postrm (or prerm, whatever it is). If it
>> really hangs at db_purge, it may be a bug in debconf. You should know
>> that. 
>
> Yes, I've alread tried the 'set -x'. That's how I found it was stuck in 
> db_purge...
>
> I've tried debconf 1.4.30.5, 1.4.30.8 and 1.4.39. They're all stuck in 
> db_purge,
> waiting for something from stdin !

Calm down. Start reading. Start with debconf-devel(7). Go to the
DEBUGGING section. 

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Xsession doesn't use umask setting from /etc/login.defs

[Branden Robinson]

On Mon, Oct 18, 2004 at 10:57:24AM +0200, Tollef Fog Heen wrote:
> * Branden Robinson 
> 
> | On Fri, Oct 15, 2004 at 12:06:36PM -0700, Steve Langasek wrote:
> | > environment variables, at least, are trivial to accomplish using the
> | > pam_env module.  Properly setting a umask would call for something else
> | > yet.
> | 
> | Would pam_umask.so be a worthwhile exercise for some enterprising person?
> | 
> | I somehow suspect that umasks predate environment variables in the misty
> | early history of Unix, else the umask would've been made one.
> 
> Give me a decent description for it (as in, what goes into the long
> description in debian/control) and it's on its way to incoming.

Wow, thanks!

Hmmm.

 This PAM module sets the umask for successfully authenticated sessions.
 The umask affects the permissions assigned to newly created files by
 default.
 .
 This package is useful to ensure that users' umasks are set consistently
 whether their session is initiated by login, SSH, a display manager for
 the X Window System, or some other means.

I'm not thrilled with it, but maybe you can make something useful out of
that.

Thanks again for the lightning-fast coding.  :)

-- 
G. Branden Robinson|The basic test of freedom is
Debian GNU/Linux   |perhaps less in what we are free to
[EMAIL PROTECTED] |do than in what we are free not to
http://people.debian.org/~branden/ |do.  -- Eric Hoffer


signature.asc
Description: Digital signature

Re: Xsession doesn't use umask setting from /etc/login.defs

[Branden Robinson]

On Mon, Oct 18, 2004 at 09:43:33AM +0200, Jan Nieuwenhuizen wrote:
> I wonder if filing a bug report against the offending MUA would be
> more efficient?

I think such bugs are best filed by those who actually use the MUA in
question (I use Mutt, which already respects M-C-T and M-F-T).

After all, if I can't persuade the users of those MUAs that honoring
people's wishes is a good idea, I don't suspect I'll make much more headway
with anyone else.

-- 
G. Branden Robinson|
Debian GNU/Linux   |   If ignorance is bliss,
[EMAIL PROTECTED] |   is omniscience hell?
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: Xsession doesn't use umask setting from /etc/login.defs

[Branden Robinson]

On Mon, Oct 18, 2004 at 09:41:45PM +0200, Tomas Fasth wrote:
> I have re-read your mail and I beg you for pardon. I was wrong.

Thanks.  My anger dissipates with a wave of the hand.  :)

> | And, by the way: X-No-CC: I subscribe to this list; do not CC me
> | on replies.
> 
> I'm very sorry but I'm not perfect. My earlier reply did not cc:
> you. Could you please wait for it to happen a second time in the
> same thread before complaining? You seem a bit touchy about it.

It's one of my long-standing pet peeves.

> | Please get an MUA that respects Mail-Copies-To:.
> 
> Thanks for the advice, but I prefer Firefox for the time being. I
> may try to persuade the Mozilla people to accept a patch. Can you
> give me a reference to a RFC-draft or something equivalent?

The best I can do is my usual boilerplate message, which has some
references at the bottom.

[The following is a form letter.]

Hello,

You recently sent a message to a Debian Project mailing list to which I am
subscribed, and also included me in the To or CC header.

Please don't do this.  The Debian Mailing List Code of Conduct says:

  When using the Debian mailing lists, please follow these rules:

[...]
  * When replying to messages on the mailing list, do not send a carbon
copy (CC) to the original poster unless they explicitly request to be
copied.

(You can review the entire Debian Mailing List Code of Conduct at
http://www.debian.org/MailingLists/>.)

Rationally interpreted, this of course includes anything that works
equivalently to a CC, such including the original poster in the To: or Bcc:
headers, forwarding the message to the original poster, or using the
"bounce" feature of some mailers to send the message again, but rewriting the
SMTP envelope to address the original poster instead of the list.

Some people feel that it is best to send email to everyone who might
possibly be interested in a message, indifferent to whom might be
subscribed to various mailing lists, be part of the expansion of various
mailing lists, be behind an SMTP exploder, and so forth -- in other words,
that it is the responsibility of the recipient of duplicate mail messages
to handle them.

The Debian Mailing List Code of Conduct does not endorse that philosophy.
There are proven limitations with using procmail rules to eliminate
duplicate message based on Message-ID, for instance.  More importantly, the
Debian Mailing List Code of Conduct expects the *senders* of mail to
exercise discretion and good judgement; it does not place the burden of
pruning unwanted copies of mail messages upon the recipient.  You can find
discussions of this aspect of the Mailing List Code of Conduct in the
Debian mailing lists themselves, if you are interested: please see
http://lists.debian.org/search.html> to perform a search.

The subject has come up several times over the past years, and time and
again, the existing policy has been affirmed as the wisest course of
action.  Many people, myself included, use the Mail-Followup-To and
Mail-Copies-To message headers, which are honored by mail user agents such
as Mutt to control the distribution of replies to mailing lists.   Using
such headers, a person can easily indicate that he does (or does not) want
to be sent copies of replies to his message.  You may want to use an MUA
that honors these headers, as they are in fairly wide usage on the Debian
mailing lists, and may help you avoid mistakes resulting in inadvertent
violations of Debian's Mailing List Code of Conduct.

You can read more about the Mail-Followup-To and Mail-Copies-To message
headers at:

http://www.ietf.org/proceedings/98dec/I-D/draft-ietf-drums-mail-followup-to-00.txt
http://www.newsreaders.com/misc/mail-copies-to.html

Please note that no assertions of deliberate misconduct on your part are
intended by this message.  It is meant only to advise you as to how to
communicate more harmoniously with people involved with the Debian Project.

Thank you for your patience with this form letter, for your respect for the
Debian Project's mailing list conventions, and for your participation in
Debian.

-- 
G. Branden Robinson|When we call others dogmatic, what
Debian GNU/Linux   |we really object to is their
[EMAIL PROTECTED] |holding dogmas that are different
http://people.debian.org/~branden/ |from our own. -- Charles Issawi


signature.asc
Description: Digital signature

Re: discover and hotplug must be able to co-exists (was Re: discover or alsa?)

[Marco d'Itri]

On Oct 21, A Mennucc <[EMAIL PROTECTED]> wrote:

> Unless someone may go and rewrite xserver-xfree86 to suggest 'hotplug | 
> discover', and use any of the two. (hotplug has a much wider list of 
Hotplug does not know about X drivers and is not supposed to.

I think that the correct solution is to ship discover with autoloading
of USB and PCI devices turned off by default.

-- 
ciao, |
Marco | [8659 etDocPnL97LuY]


signature.asc
Description: Digital signature

Re: discover and hotplug must be able to co-exists (was Re: discover or alsa?)

[Petter Reinholdtsen]

[Marco d'Itri]
> Hotplug does not know about X drivers and is not supposed to.

Right.  That is what I suspected.  So it can not replace discover,
kudzy, or any of the other packages capable of providing X driver
info.

> I think that the correct solution is to ship discover with
> autoloading of USB and PCI devices turned off by default.

At least it sounds like a good idea to have such option.  The work is
done in the init.d-script.  I'm sure patches to make it optional to
load kernel modules at boot time are welcome. :)

I'm not sure if it should be off by default.  But that is a different
discussion. :)

Re: Content of CDs / DVDs

[Richard Atterer]

Hello,

/me puts jigdo author hat on.

On Wed, Oct 20, 2004 at 06:38:07PM -0500, Matthew Dempsky wrote:
> Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> writes:
> > Of course! Now I can't believe I didn't think about jigdo first...
> > probably because I'm not very familiar with it.
> >
> > Assuming that it allows to create custom isos then it's great for this
> > purpose.
> >
> > In fact alongside picking up custom packages we could create some
> > predefined (maybe based on the popularity) templates.
> >
> > Anyone willing to work on it? Maybe some Alioth project? I'm not DD yet
> > so someone else would be forced to create such project. But I would
> > like to contribute in such addition to project.
> 
> How difficult is it to generate jigdo templates on the fly?  It sounds
> like a fun project if that's not too difficult a task.

It's not /that/ easy, because the .template includes a md5 checksum for the
entire image, and also other, per-file checksums. This means that during
the on-the-fly generation, all the file data needs to be read into memory
to calculate the checksum, so creating the .template will take quite a
while.
(Of course, at the expense of outputting images with a wrong (i.e. zero)
image md5sum, you can go faster...)

Look at Steve McIntyre's JTE project
 for something very much like
this. As of 2 weeks ago, JTE is used to produce the weekly CD/DVD images.

All in all, IMHO generating per-user images on the fly is not really
feasible. However, I think it might make sense to offer several variant CD 
"compilations", a bit like the "Home", "Professional" and "Server" variants 
of other Linux distros. 

OTOH, offering such variants will increase the number of available Debian
images yet again. We already offer images for different arches, different
sizes (business-card/netinst/CD/DVD/DLDVD) and different distributions
(sid/sarge/woody), the total number of images is getting truly confusing,
especially for people new to Debian.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: Content of CDs / DVDs

[Cameron Patrick]

Richard Atterer wrote:

> All in all, IMHO generating per-user images on the fly is not really
> feasible.

Would it be more feasible if all of the intelligence was on the client
side?  The client could slurp down a Packages file, work out which
packages to include and split them into CD-sized chunks, download the
debs from a mirror somewhere, then fetch the installer and whatever
else is necessary to make the CD usable.  It'd be like jigdo, but
taken one stage further.

Cameron.



signature.asc
Description: Digital signature

Re: an idea for next generation APT archive caching

[martin f krafft]

also sprach Tobias Hertkorn <[EMAIL PROTECTED]> [2004.10.20.1449 +0200]:
> As a part of speeding up delivery, I programmed an apache module called 
> mirror_mod.
> For documentation look here:
> http://hacktor.fs.uni-bayreuth.de/apt-got/docs/mod_mirror.html

Interesting! Though I am not sure this would solve my problem...



also sprach Brian May <[EMAIL PROTECTED]> [2004.10.21.0504 +0200]:
> I have looked at (and flamed) apt-proxy in particular, but
> I suspect at least some of the issues here might also be relevant
> to other caching packages.
> 
> If you want a reliable caching service, I think some thought needs
> to be put into some of the issues above. Some issues might be easy
> to fix, others might be harder (e.g. minimizing latency so the
> client doesn't time out and to minimize download time but choosing
> the best server at the same time).

I realise, and I don't want to bash apt-proxy for being ambitious!

However, I am a big friend of simple solutions, and what I have in
mind just sounds like it's a whole lot easier than a separate
daemon. Simplicity -> robustness, that is all...



also sprach Jonathan Oxer <[EMAIL PROTECTED]> [2004.10.21.0617 +0200]:
> So it's necessary to keep fetching the Packages files within their
> expiry time or the cache gets nuked.

Why delete them at all?

Also, if there is no Packages file, then the deletion should not
proceed.

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: Content of CDs / DVDs

[Bartosz Fenski aka fEnIo]

On Thu, Oct 21, 2004 at 06:21:24PM +0800, Cameron Patrick wrote:
> > All in all, IMHO generating per-user images on the fly is not really
> > feasible.
> 
> Would it be more feasible if all of the intelligence was on the client
> side?  The client could slurp down a Packages file, work out which
> packages to include and split them into CD-sized chunks, download the
> debs from a mirror somewhere, then fetch the installer and whatever
> else is necessary to make the CD usable.  It'd be like jigdo, but
> taken one stage further.

That's something what I meant. I don't want to overload our mirrors too.
I meant jigdo+possibility to pick-up packages which user wants to be included
in iso(s).

regards
fEnIo
-- 
  _  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | 
IRC:fEnIo
_|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska
(0 0)  phone:+48602383548 | Slackware - the weakest link
ooO--(_)--Ooo  http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001


signature.asc
Description: Digital signature

Re: discover and hotplug must be able to co-exists (was Re: discover or alsa?)

[Marco d'Itri]

On Oct 21, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:

> I'm not sure if it should be off by default.  But that is a different
> discussion. :)
discover cannot load hotplugged devices, so to me it looks like a good
idea to use the same program to do both. Reliably reproducible bugs are
better than inconsistent behaviour. :-)

-- 
ciao, |
Marco | [8669 esXr1it..byJE]


signature.asc
Description: Digital signature

Re: discover and hotplug must be able to co-exists (was Re: discover or alsa?)

[Petter Reinholdtsen]

[Marco d'Itri]
> discover cannot load hotplugged devices, so to me it looks like a good
> idea to use the same program to do both. Reliably reproducible bugs are
> better than inconsistent behaviour. :-)

I'm not really interested in participating in that discussion.

Anyway, if you make a patch, please make the default configurable
using debconf preseeding, with a hidden debconf question (only use
db_get).  This way it is easy to change the default for us making
custom debian distributions.  :)

Re: Content of CDs / DVDs

[Richard Atterer]

On Thu, Oct 21, 2004 at 06:21:24PM +0800, Cameron Patrick wrote:
> Would it be more feasible if all of the intelligence was on the client
> side?  The client could slurp down a Packages file, work out which
> packages to include and split them into CD-sized chunks, download the
> debs from a mirror somewhere, then fetch the installer and whatever else
> is necessary to make the CD usable.  It'd be like jigdo, but taken one
> stage further.

That would be possible, but it wasn't a design goal for jigdo. With jigdo,
I wanted to create bit-exact copies of officially released images. Once you
start executing mkisofs on the user's machine, this becomes difficult to
achieve, so jigdo leaves creating the iso9660 filesystem to other tools.

Have a look at the debian-cd scripts and imagine doing all this on the 
user's machine - not trivial!

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: Content of CDs / DVDs

[Steve McIntyre]

[ Note Reply-To: set to debian-cd; that's the right place for this
  discussion ]

Richard Atterer writes:
>On Wed, Oct 20, 2004 at 06:38:07PM -0500, Matthew Dempsky wrote:
>> 
>> How difficult is it to generate jigdo templates on the fly?  It sounds
>> like a fun project if that's not too difficult a task.
>
>It's not /that/ easy, because the .template includes a md5 checksum for the
>entire image, and also other, per-file checksums. This means that during
>the on-the-fly generation, all the file data needs to be read into memory
>to calculate the checksum, so creating the .template will take quite a
>while.
>(Of course, at the expense of outputting images with a wrong (i.e. zero)
>image md5sum, you can go faster...)

Yes. I was discussing this with some people last night. The MD5 step
is the hard bit. If we are prepared to lose the MD5 of the entire
image (or use another checksum algorithm that can be updated just
using existing checksums of the parts in the image) then we could
probably generate jigdo files on the fly in _seconds_ simply by using
the data already in the Packages files. We'd need to make a few tweaks
to the CD layout, but it's doable if we want it.

>Look at Steve McIntyre's JTE project
> for something very much like
>this. As of 2 weeks ago, JTE is used to produce the weekly CD/DVD images.
>
>All in all, IMHO generating per-user images on the fly is not really
>feasible. However, I think it might make sense to offer several variant CD 
>"compilations", a bit like the "Home", "Professional" and "Server" variants 
>of other Linux distros. 
>
>OTOH, offering such variants will increase the number of available Debian
>images yet again. We already offer images for different arches, different
>sizes (business-card/netinst/CD/DVD/DLDVD) and different distributions
>(sid/sarge/woody), the total number of images is getting truly confusing,
>especially for people new to Debian.

Agreed.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
Welcome my son, welcome to the machine.

Re: Webmaster

[Christoph Berg]

Re: Sumeru Nandi in <[EMAIL PROTECTED]>
> Hi I am interested in the webmasters job for your website 
> 
> My skills sets include : 
> 
> HTML, XML, PHP, ASP, Javascript, Dreamweaver, Adobe Photoshop.
> 
> Please let me know if this is paid or voluntary work

Hi,

Debian is based on voluntary contributions by various individuals.

Oh, and www.debian.org uses wml, based on perl, which is *not* PHP.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Bug#277658: ITP: smarty -- Template Engine for PHP

[Jose Luis Tallon]

Package: wnpp
Severity: wishlist


* Package name: smarty
  Version : 2.6.5
  Upstream Author : Monte Ohrt <[EMAIL PROTECTED]> & Andrei Zmievski <[EMAIL 
PROTECTED]>
* URL : http://smarty.php.net/
* License : LGPL
  Description : Template Engine for PHP

Although Smarty is known as a "Template Engine", it would be more accurately
described as a "Template/Presentation Framework." That is, it provides the
programmer and template designer with a wealth of tools to automate tasks
commonly dealt with at the presentation layer of an application. 

Here some of the more notable features of Smarty: 
- Caching
- Configuration Files
- Security
- Variable Modifiers
- Template Functions
- Filters
- Resources
- Plugins
- Debugging
- Compiling

The codebase of Smarty is larger than typical template engines available for
PHP, but at the same time it covers a much larger breadth of functionality.
Many of the tools that Smarty supplies would probably need to be programmed
into your application anyways. 

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Re: Bug#277550: ITP: patcher -- perl script useful for managing patches

[Alejandro Rios P.]

Hi Dan

El mié, 20-10-2004 a las 20:23, Dan Weber escribió:
> How is this different from quilt?
> 

I'll take my answer for that question from the upstream developer's
README file:

"
SEE ALSO
Andrew Morton's patch scripts at
http://www.zip.com.au/~akpm/linux/patches/

I stole the idea from him and even most of this documentation.

At http://savannah.nongnu.org/projects/quilt/ you'll find Quilt. That's
the successor of Andrew's original scripts. They do the same as patcher
(and slightly more), but with tenthousand shell scripts.
AUTHOR
Holger Schurig 
"

Alejandro Rios Peña.




signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada	digitalmente

Re: an idea for next generation APT archive caching

[Eduard Bloch]

#include 
* Jonathan Oxer [Thu, Oct 21 2004, 02:17:49PM]:

> > is unstable). IMHO, the only correct way is to scan the most recently
> > downloaded Packages and Source index files and delete files that
> > aren't mentioned anymore.
> 
> That's how apt-cacher does it. Early versions of apt-cacher did no cache
> cleaning and it was the #1 requested feature for a while, but once I sat
> down to actually start implementing it I discovered something that's not
> obvious until you actually try to do it yourself: Writing Cache Expiry
> Algorithms Is Bloody Hard(TM).
> 
> In the end I settled on a combination: Packages and Release files are
> expired based on age, and .debs are purged based on reference within a

And though I like apt-cacher in general (it worked immediately while I
did not manage to make apt-proxy work within 15 minutes and dropped the
crap), this is the only method I do not like at all.
It could be done better. I suggest you switch from wget to curl and use
If-Modified-Since calls to update the Package/Source/Release file only
when needed. And only when the local copy of them has changed (and the
update was clean), then the deb files should be purged (when the next
cleanup cycle comes). You could even check for index file updates based
on time periods instead of triggering it by the user. Actually, it could
be a cron-job that downloads them to /dev/null.

Further, I wish there could be pre-caching. Means: if a file was
downloaded and that file was mentioned in packages-file A and after the
next update, A has a newer version of this package than the package
could be downloaded. This would be an optional feature, of course, but
it could be implemented without millions LOC.

Regards,
Eduard.
-- 
Wer die Form zerstört, beschädigt auch den Inhalt.
-- Herbert von Karajan

Re: forwarding bugs to other packages

[Joel Baker]

On Thu, Oct 21, 2004 at 01:28:41PM +1000, Brian May wrote:
> > "Joel" == Joel Baker <[EMAIL PROTECTED]> writes:
> 
> Joel> It would also presumably allow you to add a filter such as
> Joel> "don't display any bug with a dependancy on any other
> Joel> still-open bug"; thus allowing maintainers to have things
> Joel> "automagically" show up again once the bug they're waiting
> Joel> on has been resolved.
> 
> If you do this, different types of dependancies (or relationships)
> might be desirable. eg:

Possibly; depends on how hard it is to do, really, for the benefit.

> bug x is bug y -- declaration that both bugs are the same, once y is
>   fixed x needs to be rechecked but is most likely
>   fixed.
>
> bug x depends bug y -- y must be fixed before work on x can
> continue. Closing y doesn't mean x is fixed.
> 
> bug x suggests bug y -- y might be a possible solution to this
> bug. Other solutions/workarounds may also be
> possible. Closing y means x is probably fixed
> but needs testing.
> 
> If more thought was put into this, I am sure we could come up with
> something better.

Well, that seems like a start, anyway. Really, I'd like some input from
someone more familiar with the BTS code before going off into the wild blue
yonder. It's possible this has been proposed and discarded before, for good
reason, after all... or not.
-- 
Joel Baker <[EMAIL PROTECTED]>,''`.
 : :' :
 `. `'
   `-

NMU for libpaper

[Giuseppe Sacco]

It seems that libpaper package is unmaintaned, but i would like to do an
NMU using a large patch. The relevant bug report (with patch) is #188899
and this would also close hylafax bug report #269184.

Does anyone see any problem in applying this patch?

Bye,
Giuseppe

Re: Bug#277658: ITP: smarty -- Template Engine for PHP

[David Moreno Garza]

On Thu, 2004-10-21 at 16:30 +0200, Jose Luis Tallon wrote:
> Package: wnpp
> Severity: wishlist
> 
> 
> * Package name: smarty

Are you pretty sure about this?

Please take a look at:
http://packages.qa.debian.org/s/smarty.html


-- 
David Moreno Garza <[EMAIL PROTECTED]> | http://www.damog.net/
 GPG 356E16CD - 84F0 E180 8AF6 E8D0 842F  B520 63F3 08DB 356E 16CD

Re: an idea for next generation APT archive caching

[Chris Halls]

On Wed, 2004-10-20 at 11:11, martin f krafft wrote:
> 1. apt-proxy:
>   While I love the concept of apt-proxy, it works very unreliably.
>   Frequently, the proxy fails to download the package or imposes
>   very long delays (#272217, and others).

This seems to be the result of a patch that fixed one problem and caused
another.  You can work around it for now by using this in the config
file:

disable_pipelining=1

>   If it does work, it's a performance hog. On my Opteron 3600+, my
>   mouse starts to go jaggy when more than one machine accesses the
>   cache at the same time.

Yes, this needs looking into.  If you actually have some time on your
hands to do this sort of thing, I'd encourage you to look at apt-proxy
seriously.  It hasn't had the loving attention it needs since ranty
died, although Otavio has been fixing some of the problems recently.

There have been quite a lot of attempts to make a better apt-proxy, but
almost always the authors discovered the problem is rather difficult to 
get right, especially when you start worrying about streaming while
downloading, multiple clients downloading simultaneously and cache
cleaning algorithms.  Based on previous attempts, I'd advise you not to
underestimate the task.  Is apt-proxy really so broken that the only way
to make something better is to rewrite the whole thing from scratch?

Chris

Re: RFC: common database policy/infrastracture

[sean finney]

hi javier,

On Wed, Oct 20, 2004 at 05:05:18PM +0200, Javier Fernández-Sanguino Peña wrote:
> - leave data after purge? -> only ask during purge.
> - back up database before upgrade? -> only ask during upgrades. user should 
> be notified where to find backups and possibly how to restore.
> and other ' only ask during install'
> 
> All these questions should be made on configuration, but, obviously, only 
> once (when the package is first installed or on upgrade if the debconf 
> question was not previously there). Obviously, the _actions_, will be taken 
> on purge|postinst|preinst, but the question itself is made in advance the 
> first time the package is configured. You might want to clarify the table 
> and change 'only ask' to 'only done' (or acted upon).

actually, this was intentional.  it seemed to me that the general
consensus was that the purge question should be asked just before
they'd be acted upon.  in the case of the purge question, the
you're not guaranteed that the answer to the question will
still be there at purge time depending on when it was configured
and what's happened to the debconf cache since.  with the upgrade
question, it'd be just fine to ask in the pre-configuration, and
if you look in the pseudo code overview, that's exactly what i
proposed.

> Similarly, you want to change the pseucode in 'overview of 
> installation/removal process' since all the INPUT should be done in 
> configuration. For an example take a look at how the PostgreSQL does this 
> (purge on removal and backup on upgrade) for _all_ databases managed by it.

i'll take a look at this, thanks.


sean

-- 


signature.asc
Description: Digital signature

Re: NMU for libpaper

[Frank Küster]

Giuseppe Sacco <[EMAIL PROTECTED]> wrote:

> It seems that libpaper package is unmaintaned, but i would like to do an
> NMU using a large patch. The relevant bug report (with patch) is #188899
> and this would also close hylafax bug report #269184.
>
> Does anyone see any problem in applying this patch?

I have no opinion on that. But if you do it, I hope you will also fix
the three l10n bugs. And I suggest that you also consider my patch for
the annoying debconf bug #269603, and have a look at #270103. Should be
fairly easy.

Regards, Frank

-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Bug#277658: ITP: smarty -- Template Engine for PHP

[Raphaël 'SurcouF' Bordet]

Jose Luis Tallon wrote:
Package: wnpp
Severity: wishlist
* Package name: smarty
  Version : 2.6.5
  Upstream Author : Monte Ohrt <[EMAIL PROTECTED]> & Andrei Zmievski <[EMAIL 
PROTECTED]>
* URL : http://smarty.php.net/
* License : LGPL
  Description : Template Engine for PHP
There're already exist a smarty package in debian: 
http://packages.debian.org/unstable/web/smarty

Why this ITP ?
Regards,
--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net

Re: an idea for next generation APT archive caching

[Manoj Srivastava]

Hi,

I can mostly live with the current apt-proxy, except for the
 fact that it does not seem to want to play nice with debbootstrap:
 debbootstrap just hangs.

manoj
-- 
Philogyny recapitulates erogeny; erogeny recapitulates philogyny.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Bug#277582: ITP: kwin-baghira -- A MacOSX-like theme for Apple junkies ;)

[Dirk Eddelbuettel]

Jose Luis Tallon  adv-solutions.net> writes:
> 
> Package: wnpp
> Severity: wishlist
> 
> 
> * Package name: kwin-baghira
>   Version : 0.5h
>   Upstream Author : Thomas LÃbking  users.sourceforge.net>
> * URL : http://baghira.sourceforge.net/
> * License : GPL
>   Description : A MacOSX-like theme for Apple junkies ;)
> 
> Baghira is a native style and kwin decoration for KDE >=3.2

Nice -- I wouldn't mind trying that, it looked pretty on the screenshots on
one of the KDE advocacy sites.  Two quick questions:
-- Will this transparently remove existing files via something like the
   dpkg alternatives mechanism ?  That would allow for easy installation and
 
   removal.
-- The package name looks a bit odd. kwin-$FOO for a theme?  Isn't there a 
   better kde convention you could use?

Thanks, Dirk

Document

[MSN Hotmail]

This is an auto-generated response designed to let you know that our system 
received your support inquiry and a Support Representative will review your 
question and respond to you soon. Please note that you will not receive a reply 
if you respond directly to this message. 

Thank you for contacting MSN Hotmail Support.

Remember that MSN Hotmail also has comprehensive online help available--just 
click "Help" in the upper right corner.

Document

[MSN Hotmail]

This is an auto-generated response designed to answer your question as quickly 
as possible. Please note that you will not receive a reply if you respond 
directly to this message. 

Unfortunately, we cannot take action on the mail you sent us because it does 
not reference a Hotmail account. Please send us another message that contains 
the full Hotmail e-mail address and the full e-mail message to:
[EMAIL PROTECTED]

>>> To forward mail with full headers

Using Hotmail:
1.  Click "Options" to the right of the "Contacts" tab. The "Options" page 
appears.
2.  Under "Additional Options", click "Mail Display Settings". The "Mail 
Display Settings" page appears.
3.  Under "Message Headers", select "Full" and click "OK".
4.  Forward the resulting mail to:
   [EMAIL PROTECTED]

Using MSN Explorer:
1.  Open the message, and then click "More" in the upper right corner.
2.  Click "Message Source". The message opens in a new window with all the 
header information visible.
3.  Copy all the text and paste it into a new message. Send this message to:
   [EMAIL PROTECTED]

Using Outlook Express or Outlook:
1.  On the unopened mail, place your cursor over the mail, right-click, and 
click "Options".
2.  Under "Internet headers", copy the contents of the full header.
3.  Open the e-mail in question and forward a complete copy of the message, 
including the full message header you copied at the beginning of your message, 
to:
  [EMAIL PROTECTED]

If you're not a Hotmail member, consult the Help associated with your e-mail 
program to determine how to view complete header information. Then forward the 
message to:
[EMAIL PROTECTED]

If the unsolicited junk e-mail or "spam" comes from a non-Hotmail account, you 
can send a complaint to the service provider that sent the mail. Make sure that 
you include full headers when you send your complaint. 

In the full header, look at the last "Received" notation to locate what .com 
domain it came from. It looks something like:
[service provider domain name].com

Forward a complete copy of the message, including the full message header, to:
  [EMAIL PROTECTED] provider domain name].com

If the domain does not have an abuse service, forward your complaint to:
  [EMAIL PROTECTED] provider domain name].com

All Hotmail customers have agreed to MSN Website Terms of Use and Notices(TOU) 
that forbid e-mail abuse. At the bottom of any page in Hotmail, click "Terms of 
Use" to view the Terms of Use document in its entirety.

Thank you for helping us enforce our TOU.

Bug#277706: ITP: libcompress-lzo-perl -- Perl bindings for LZO realtime compression library

[Nikita V. Youshchenko]

Package: wnpp
Severity: wishlist

* Package name: libcompress-lzo-perl
  Version : 1.08
  Upstream Author : Markus Franz Xaver Johannes Oberhumer <[EMAIL PROTECTED]>
* URL : http://www.oberhumer.com/opensource/lzo/
* License : GPL
  Description : Perl bindings for LZO realtime compression library

Compress::LZO is a Perl external module which provides an interface to
LZO compression library.

LZO is a portable lossless data compression library written in ANSI C.
It offers pretty fast compression and *very* fast decompression.
Decompression requires no memory.


Package is at http://zigzag.lvk.cs.msu.su/~nikita/perl/
I created it because we need Compress::LZO for one of local projects,
and there is no debian package available yet.
Package is lintian- and linda-clean. However, since it is my first perl
debian package, I'd like someone to look through it, probably I've done
somethin wrong.

Re: Python executables inside libraries

[Magnus Therning]

On Thu, Oct 21, 2004 at 10:53:32PM +1000, Matthew Palmer wrote:
>On Thu, Oct 21, 2004 at 09:25:41AM +0200, Magnus Therning wrote:
>> I have a silly little problem with getting Python's distutils to play
>> nice with Debian packaging. The library I am packaging (PyGGy) has a few
>> python files that double as executable scripts (in short they have '#!
>> /usr/bin/python' at the top of the file, while still being part of a
>> library, and they are executable, I am sure you know what I mean ;-).
>> Distutils insists on leaving them non-executable after a './setup.py
>> build'. However, since they contain that first line lintian complains
>> that they are scripts, but non-executable:
>
>[...]
>
>> Do I leave it them the way they are, or is there a nice way of resolving
>> this?
>
>Resolve the problem by making up your mind -- are they scripts (and
>hence need +x and quite possibly a home in /usr/bin) or are they
>library files, and hence no #! and a -x.

Well, they can't go into /usr/bin, they are part of the library.
However, for some reason upstream decided to put the python equivalent
of a main() in some of the files that make up the library.

The package I am trying to Debianise is PyGgy (bug #277567). It's a
lexer/parser for Python. Upstream decided that the parser package
(pyggy.pyggy) should double as an executable script (it creates parser
tables for all parser description files it's given on the command line).
This sort of thing isn't uncommon in Python, I believe.

Removing the executable flag would leave the Debianised package
different from the upstream package. I can't find anything in the Debian
Python Policy mentioning this "problem".

How do other maintainers do?

/M

-- 
Magnus Therning(OpenPGP: 0xAB4DFBA4)
[EMAIL PROTECTED]
http://magnus.therning.org/

In my opinion, shareware tends to combine the worst of commercial software
(no sources) with the worst of free software (no finishing touches). I
simply do not believe in the shareware market at all.
 -- Linus Torvalds


signature.asc
Description: Digital signature

Re: an idea for next generation APT archive caching

[Robert Collins]

On Wed, 2004-10-20 at 12:11 +0200, martin f krafft wrote:
> also sprach martin f krafft <[EMAIL PROTECTED]> [2004.10.20.0211 +0200]:
> > Here's an idea I just had about apt-proxy/apt-cacher NG. Maybe this
> > could be interesting, maybe it's just crap. Your call.

> 3. squid:
>   Squid works reliably, but it has no concept of the APT repository
>   and thus it is impossible to control what is cached and for how
>   long. The release-codename symlinks can be worked around with
>   a simple rewriter, but other than that, there are three parameters
>   that seem relevant:
> 
>   maximum_object_size 131072 KB
>   cache_dir aufs /var/spool/squid-apt 1024 16 256
>   store_avg_object_size 100 Kb
> 
>   These values are what I came up with after two days of testing.
>   The problematic one is the last one. It's at 13 Kb per default,
>   and this causes squid not to reliably cache objects larger than
>   35 Mb. Increasing it to 100 Kb causes even openoffice.org to be
>   cached for some time, but the high average also causes smaller
>   files to be removed earlier than they should be.

store_avg_object_size should have no impact on what is and is not
cached. It is used to estimate the has size required to fully populate
the cache. Having too low a value there will simply cause squid to
create a hash table that is larger than optimal : it will not enable or
prevent caching of debs, nor will it cause smaller files to be removed.

If you are using bloom inter-cache digests, the average object size
estimator is also used there to tune the bloom digest for optimal
density. Again, no impact on the local squid's caching or not of any
given object.

I usually bump my max object size up past 720MB, so that I can cache
isos.
maximum_object_size 740 MB

One of the problems with sid debs, is that they are often very recent,
and delivered without cache expiry metadata, so squid's heuristic, which
looks at time since modification, gives them an inappropriately low
maxmium lifetime. So lets specify 1 day minimum for debs without expiry
metadata, and 1/5 of its age as the age based freshness, and upper cap
that at 1 month. This is heavily geared, and if you are happy with
revalidation - i.e. your deb mirror returns the same mod time & etag
when squid checks, and you aren't trying to use this offline, then this
can reduced. As debs names are not reused, this should be safe as is.

refresh_pattern deb$ 14400 20% 2592000

likewise the control files files, but these we expect to change daily.

refresh_pattern (Packages(.gz)?|Release|Sources.gz)$ 14300 20% 14400

(I think that regex is right, haven't tested it).

You probably want heap LFUDA cache replacement policy.

cache_replacement_policy heap LFUDA


Cheers,
Rob

-- 
GPG key available at: .


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

Re: Python executables inside libraries

[Matthew Palmer]

On Thu, Oct 21, 2004 at 11:41:09PM +0200, Magnus Therning wrote:
> On Thu, Oct 21, 2004 at 10:53:32PM +1000, Matthew Palmer wrote:
> >On Thu, Oct 21, 2004 at 09:25:41AM +0200, Magnus Therning wrote:
> >> I have a silly little problem with getting Python's distutils to play
> >> nice with Debian packaging. The library I am packaging (PyGGy) has a few
> >> python files that double as executable scripts (in short they have '#!
> >> /usr/bin/python' at the top of the file, while still being part of a
> >> library, and they are executable, I am sure you know what I mean ;-).
> >> Distutils insists on leaving them non-executable after a './setup.py
> >> build'. However, since they contain that first line lintian complains
> >> that they are scripts, but non-executable:
> >
> >[...]
> >
> >> Do I leave it them the way they are, or is there a nice way of resolving
> >> this?
> >
> >Resolve the problem by making up your mind -- are they scripts (and
> >hence need +x and quite possibly a home in /usr/bin) or are they
> >library files, and hence no #! and a -x.
> 
> Well, they can't go into /usr/bin, they are part of the library.
> However, for some reason upstream decided to put the python equivalent
> of a main() in some of the files that make up the library.
> 
> The package I am trying to Debianise is PyGgy (bug #277567). It's a
> lexer/parser for Python. Upstream decided that the parser package
> (pyggy.pyggy) should double as an executable script (it creates parser
> tables for all parser description files it's given on the command line).
> This sort of thing isn't uncommon in Python, I believe.

Would you reasonably want to execute those scripts in and of themselves from
another program?  If yes, then +x.  If not, s/^#!.*$//.

- Matt

Re: an idea for next generation APT archive caching

[Robert Collins]

On Thu, 2004-10-21 at 17:31 +0100, Chris Halls wrote:

> There have been quite a lot of attempts to make a better apt-proxy, but
> almost always the authors discovered the problem is rather difficult to 
> get right, especially when you start worrying about streaming while
> downloading, multiple clients downloading simultaneously and cache
> cleaning algorithms.  Based on previous attempts, I'd advise you not to
> underestimate the task.  Is apt-proxy really so broken that the only way
> to make something better is to rewrite the whole thing from scratch?

Caching for concurrent clients is non trivial :). Theres not a lot squid
would need done, to make it an excellent archive-specific cache:

If we allowed cache dir selection by request tag, or just by standards
then acl's could trivially tag requests that should go into a dedicated
cache dir, thus preventing normal traffic ejecting packages or archive
metadata from the cache. Beyond that, see my other email for some
settings that should make squid much better than the default, for apt
caching.

Rob

-- 
GPG key available at: .


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

Bug#277721: ITP: libnet-smpp-perl -- Net::SMPP is an implementation of Short Message Peer to Peer protocol over TCP

[Andres Seco Hernandez]

Package: wnpp
Severity: wishlist

* Package name: libnet-smpp-perl
  Version : 1.03
  Upstream Author : Sampo Kellomaki <[EMAIL PROTECTED]>
* URL : http://www.symlabs.com and CPAN
* License : PERL
  Description : Net::SMPP is an implementation of Short Message Peer to 
Peer protocol over TCP

Net::SMPP is an implementation of Short Message Peer to Peer protocol
over TCP. This protocol is frequently used in the telecoms and mobile
operator world to pass short messages between systems that implement
the short message service (SMS). It is applicable to both european GSM
and american CDMA based systems. The SMPP protocol is documented at 
www.smpp.org. This module aims at fully implementing version 3.4 of the
protocol. This module also implements 4.0 and aims to support it fully
as well.

License
---
Net::SMPP is copyright (c) 2001 by Sampo Kellomaki ([EMAIL PROTECTED]),
All rights reserved. Portions copyright (c) 2001 by SymLABS
([EMAIL PROTECTED]), All rights reserved.  You may use
and distribute Net::SMPP under same terms as perl itself.
NET::SMPP COMES WITH ABSOLUTELY NO WARRANTY.


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.7-1-686
Locale: LANG=C, LC_CTYPE=C

Re: an idea for next generation APT archive caching

[Tobias Hertkorn]

One bad thing (amongs others) that happens if you use squid - first of all 
you have to make your clients use the proxy settings AND way more imortant - 
a request for http://yourserver/testing//apachedeb will not create a 
hit if requested as http://yourserver/sid//apache...deb . Furthermore 
requests to similar mirrors will not create cache hits. So everybody has to 
use the same sources list, down to the same requests by symlinks.
You can make squid better than the default, but excellent for clients that 
are not owned by the very same admin? I doubt it.

Greets,
Tobi
- Original Message - 
From: "Robert Collins" <[EMAIL PROTECTED]>
To: "Chris Halls" <[EMAIL PROTECTED]>
Cc: 
Sent: Friday, October 22, 2004 1:56 AM
Subject: Re: an idea for next generation APT archive caching

Caching for concurrent clients is non trivial :). Theres not a lot squid
would need done, to make it an excellent archive-specific cache:

Re: an idea for next generation APT archive caching

[Jonathan Oxer]

On Fri, 2004-10-22 at 03:36 +0200, Tobias Hertkorn wrote:

> a request for http://yourserver/testing//apachedeb will not create a 
> hit if requested as http://yourserver/sid//apache...deb . Furthermore 
> requests to similar mirrors will not create cache hits. So everybody has to 
> use the same sources list, down to the same requests by symlinks.

Yep, that's annoying and it's one of the reasons for the flat cache
design in apt-cacher: if clients fetch the same package from different
mirrors it will cause a cache hit since the package names are the same.

However, something that was raised at Debian Miniconf2 (IIRC) was that
this allows cache poisoning: by creating a compromised package and
sticking it on any random web server, a cracker can then fetch the
package themselves through the cache and any user who subsequently
fetches it (even using a genuine mirror in the sources.list) will get
the poisoned package.

Good argument for package signatures.

Cheers  :-)

Jonathan Oxer
--
The Debian Universe: Installing, managing and using Debian GNU/Linux
http://www.debianuniverse.com/

Re: an idea for next generation APT archive caching

[Jonathan Oxer]

On Thu, 2004-10-21 at 13:13 +0200, martin f krafft wrote:

> also sprach Jonathan Oxer <[EMAIL PROTECTED]> [2004.10.21.0617 +0200]:
> > So it's necessary to keep fetching the Packages files within their
> > expiry time or the cache gets nuked.
> 
> Why delete them at all?

Because then they are never re-fetched, and they'll be out of date.

Cheers  :-)

Jonathan Oxer

Re: an idea for next generation APT archive caching

[Robert Collins]

On Fri, 2004-10-22 at 03:36 +0200, Tobias Hertkorn wrote:
> One bad thing (amongs others) that happens if you use squid - first of all 
> you have to make your clients use the proxy settings

Set it up in reverse proxy mode (way easier in 3.0) and you don't use
proxy settings - you use it as your repository. AIUI apt-proxy, you use
it in much the same way.

>  AND way more imortant - 
> a request for http://yourserver/testing//apachedeb will not create a 
> hit if requested as http://yourserver/sid//apache...deb . Furthermore 
> requests to similar mirrors will not create cache hits. So everybody has to 
> use the same sources list, down to the same requests by symlinks.

A fairly simple redirector will accomodate this, but even if not done,
the pool is common - and the bulk of sid & testing updates is in the
pool.


Rob

-- 
GPG key available at: .


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

Re: Bug#277582: ITP: kwin-baghira -- A MacOSX-like theme for Apple junkies ;)

[Adeodato Simó]

* Dirk Eddelbuettel [Thu, 21 Oct 2004 19:51:49 +]:
> Jose Luis Tallon  adv-solutions.net> writes:

> > * Package name: kwin-baghira
> > Baghira is a native style and kwin decoration for KDE >=3.2

> -- Will this transparently remove existing files via something like the
>dpkg alternatives mechanism ?  That would allow for easy installation and  
>
>removal.

  what existing files?

> -- The package name looks a bit odd. kwin-$FOO for a theme?  Isn't there a 
>better kde convention you could use?

  the only packges in the archive which provide kwin decorations are
  kwin itself and kdeartwork-theme-window. however, the baghira style is
  provides both kwin decoration *and* widget style (like plastik does).

  this could be a good moment to standarize the name of these packages.
  I'm CC'ing debian-qt-kde for that purpose (and Ben Burton, who is the
  maintainer of kdeartwork).

  I would suggest a name like kde-$FOO-style to be used (e.g.,
  kde-baghira-style) for packages that provide a widget style for
  QT/KDE, and include kwin decoration (if they exist) in the same
  package. (*)

  packages providing only kwin decorations could be named
  kde-$FOO-style-kwin, and icon themes could use kde-$FOO-icons.

  if anybody has concenrs with that naming, please speak (only to
  debian-qt-kde, if you consider that appropriate).

(*) I am aware that this will make style packages depend on kwin via
shlibs:Depends. I, however, frown upon the idea of spliting
*each* style in two packages.
  
  thanks,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
If you want the holes in your knowledge showing up try teaching someone.
-- Alan Cox

Re: an idea for next generation APT archive caching

[Adeodato Simó]

* Eduard Bloch [Thu, 21 Oct 2004 18:12:42 +0200]:

> And though I like apt-cacher in general (it worked immediately while I
> did not manage to make apt-proxy work within 15 minutes and dropped the
> crap), this is the only method I do not like at all.
> It could be done better. I suggest you switch from wget to curl and use
> If-Modified-Since calls to update the Package/Source/Release file only
> when needed. And only when the local copy of them has changed (and the
> update was clean), then the deb files should be purged (when the next
> cleanup cycle comes). You could even check for index file updates based
> on time periods instead of triggering it by the user. Actually, it could
> be a cron-job that downloads them to /dev/null.

> Further, I wish there could be pre-caching. Means: if a file was
> downloaded and that file was mentioned in packages-file A and after the
> next update, A has a newer version of this package than the package
> could be downloaded. This would be an optional feature, of course, but
> it could be implemented without millions LOC.

  well, that would change apt-cacher from a from a simple webserver
  script to a daemon-via-cron application.

  what problems does it have a cron.daily script that runs like:

apt-get -qq update && apt-get -qqdy dist-upgrade

  ?

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
When all is summed up, a man never speaks of himself without loss; his
accusations of himself are always believed; his praises never.
-- Michel de Montaigne

orphaning packages

[Chris Ruffin]

I am orphaning four packages.  All of them are oriented in one way or
another to the electrical engineering discipline, but they are of
limited to that of course.

If you would like to adopt any or all of these packages, please refer
to the procedures documented at
http://www.debian.org/devel/wnpp/index.html.

#277731: O: electric -- electrical CAD system 
#277732: O: nasm-mode -- NASM mode for XEmacs 
#277733: O: hp48gcc -- C-like compiler which produces HP48 RPN 
#277734: O: vipec -- network analyzer for electrical networks 

--
Chris Ruffin <[EMAIL PROTECTED]>



signature.asc
Description: Digital signature

Re: update-menus , Re: dpkg and selinux

[Paul Hampson]

On Thu, Oct 21, 2004 at 10:07:53AM +0200, A Mennucc wrote:
> But I would not do this for ldconfig:
> what if a package needs a library it depends on to configure itself?

Isn't that why library packages must include the .so symlinks, so
they work before ldconfig is called?

-- 
---
Paul "TBBle" Hampson, MCSE
7th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: orphaning packages

[Kyle McMartin]

On Thu, Oct 21, 2004 at 10:50:18PM -0400, Chris Ruffin wrote:
> #277731: O: electric -- electrical CAD system 
> #277733: O: hp48gcc -- C-like compiler which produces HP48 RPN 
> #277734: O: vipec -- network analyzer for electrical networks 

I would like to take over these three packages. I will take them over
as per policy shortly. (They are relevant to me).

Thanks,
Kyle McMartin.

Re: an idea for next generation APT archive caching

[Paul Hampson]

On Wed, Oct 20, 2004 at 02:11:44AM +0200, martin f krafft wrote:
> Here's an idea I just had about apt-proxy/apt-cacher NG. Maybe this
> could be interesting, maybe it's just crap. Your call.

> Based on a normal mirror layout, the idea is to use apache's 404
> hook for packages. When an existing package is requested, it is
> served regularly. If the file is not found, a 404 is triggered,
> which can be served by a CGI-like thingie that goes to retrieve the
> package, returns 200 instead of 404 and streams the package as the
> 404 error document contents while writing it to the filesystem
> (tee(1) style).

This all sounds great. I've been thinking about it since this posting,
and one thing I'd like to see would be this hooked up to mod_proxy, so
I only have to change one setting in apt.conf, rather than a couple of
lines in sources.list, when I move from site to site.

I'm not sure yet myself how this would work, but I guess it would
catch anything that was looking for a Packages.gz, and rewrite it
internally as a connection to a local mirror or mirrors. If that
didn't work, trying the client-supplied mirror server as a fallback
would allow it to neatly cache those files which were coming from
Debian-external package pools, while still ensuring only files that
are listed in a Packages.gz somewhere get through.

That last fallback would have to be optional, or anyone could put a
Packages.gz on a webserver, and suddenly any file would be gettable
through the proxy, which would defeat one of the purposes to which
_I_ currently put apt-proxy (which is providing unmetered Debian
archive access for otherwise metered ISP customers. ^_^)

But for my home install, it'd be nice to know that experimental,
the IPv6 archive and the WMI, CenterICQ and irssi daily build
archives are all being cached and cleaned automatically when I'm
there, and otherwise I comment out the proxy option and they work
when I'm off-site for a week.

Is there anything such a system would want to fetch from a Debian
mirror that doesn't show up in Packages.gz or Sources.gz?

> For Release, Package, Sources, and Contents files, we need
> a RewriteRule. When one of these is is accessed, a call to a mirror
> should be made to check for updates. If there is one, download it
> and stream it.

> How do you send the newly retrieved file instead of the static file
> present on the filesystem? Essentially, this is the only need for
> a proxy, which could be implemented with a RewriteRule and a CGI. Or
> maybe apache can do this somehow?

> I think this would be an extremely simple implementation, using the
> proven apache for most of the work (and not the buggy twisted module
> that apt-proxy uses). Thus, the entire thing is reduced to a couple
> of httpd.conf entries and two extremely simple (?) CGIs.

> In addition, a cronjob runs daily to purge all files in the
> filesystem space, which are not referenced from any of the
> Packages/Sources files.

> This is a braindump. Please comment. Am I missing something? Would
> someone like to try this? I really don't have the time right now...

-- 
---
Paul "TBBle" Hampson, MCSE
7th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: an idea for next generation APT archive caching

[Jonathan Oxer]

On Fri, 2004-10-22 at 13:43 +1000, Paul Hampson wrote:

> Is there anything such a system would want to fetch from a Debian
> mirror that doesn't show up in Packages.gz or Sources.gz?

Yes, lots of things as I found out the hard way when I implemented
object type checking in apt-cacher - even plain old .tar.gz if you want
people to be able to fetch sources. Not good from a "don't use this as a
general purpose relay" standpoint! The current checks in apt-cacher look
like this:

if ($filename =~ /(\.deb|\.rpm|\.dsc|\.tar\.gz|\.diff\.gz|\.udeb)$/) {
...
} elsif ($filename =~ /(Packages.gz|Release|Sources.gz)$/) {
...
} else {
etc.

(It's trapping the Packages.gz etc files separately because you can't
just cache them directly: you'd have namespace collisions all over the
shop. They have to be stored separately in the cache based on the
requested host, distro etc and then the names mapped back again when
another request comes in).

Cheers  :-)

Jonathan