wiki.debian.org mailer b0rken

[Ondrej Sury]

(added openldap2.2 + gnutls to SummerOfCode2006 page)

Status of sending notification mails:
[fr] PhilBat: (421, 'Too many concurrent SMTP connections; please try
again later.')
[en] PhilippKern, RaphaelHertzog, AlphaPapa, AlexanderSchmehl,
SteveMcIntyre, DavidMorenoGarza, aba, ChristianKuelker, BaruchEven,
JoseParrella, baszoetekouw: (421, 'Too many concurrent SMTP connections;
please try again later.')

-- 
Ondrej Sury <[EMAIL PROTECTED]>


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

Re: no libldap-dev from openldap2.2 package?

[Ondrej Sury]

On Tue, 2006-05-02 at 19:33 -0700, Russ Allbery wrote:
> > [...]
> You can't right now because GnuTLS support is only available for 2.1.  2.2
> and later will need substantial reworking of that support, and without it,
> the OpenSSL licensing issues cause too many licensing conflicts in Debian
> for it to be safe to provide a -dev package that people can use widely.
> 
> I'm pretty sure that we can get funding to do the GnuTLS support for
> OpenLDAP properly.  It's just taking a really long time to work through
> that process.

Seems like as good idea for a project of Google Summer of Code...

Ondrej.
-- 
Ondrej Sury <[EMAIL PROTECTED]>


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

Re: no libldap-dev from openldap2.2 package?

[Tyler MacDonald]

Russ Allbery <[EMAIL PROTECTED]> wrote:
> You can't right now because GnuTLS support is only available for 2.1.  2.2
> and later will need substantial reworking of that support, and without it,
> the OpenSSL licensing issues cause too many licensing conflicts in Debian
> for it to be safe to provide a -dev package that people can use widely.
> 
> I'm pretty sure that we can get funding to do the GnuTLS support for
> OpenLDAP properly.  It's just taking a really long time to work through
> that process.

Speaking of GnuTLS, postgresql developers are on the verge of being
able to support it as an alternative to OpenSSL, primarily to allow GPLed
code to link against libpq in Debian.

Here's some history:

postgresql-general: 
http://marc.theaimsgroup.com/?t=11443445523&r=2&w=2

openssl-users: http://marc.theaimsgroup.com/?t=11446062722&r=2&w=2

freeradius-users: 
http://marc.theaimsgroup.com/?t=1187812&r=1&w=2

Martijn van Oosterhout says he has begin working on this:

http://marc.theaimsgroup.com/?l=postgresql-general&m=114570109002832&w=2

But it hasn't been without caveats:

http://marc.theaimsgroup.com/?l=postgresql-general&m=114571510900274&w=2
http://marc.theaimsgroup.com/?l=postgresql-general&m=114572079501988&w=2

It would take me awhile to get my head inside either codebase, but
I'm sure the help of a seasoned pg and/or gnutls debian developer would be
extremely helpful to get a lot of postgres-backed GPL apps into debian.

Cheers,
Tyler


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

Re: no libldap-dev from openldap2.2 package?

[Russ Allbery]

John v/d Kamp <[EMAIL PROTECTED]> writes:

> When I install the development files for libldap, I always get the
> libldap2-dev package, version 2.1.30. It also seems from the
> debian/control file in openldap2.2 that there is no libldap2.2-dev (or
> something) package that gives the new headers and /usr/lib/libldap.so
> that points to the new libldap version.

> Is there a specific reason that this package is left out?
> How should I compile my program so that it always links with
> /usr/lib/libldap-2.2.so.7?

You can't right now because GnuTLS support is only available for 2.1.  2.2
and later will need substantial reworking of that support, and without it,
the OpenSSL licensing issues cause too many licensing conflicts in Debian
for it to be safe to provide a -dev package that people can use widely.

I'm pretty sure that we can get funding to do the GnuTLS support for
OpenLDAP properly.  It's just taking a really long time to work through
that process.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: System users and valid shells...

[Richard A Nelson]

On Wed, 3 May 2006, Colin Watson wrote:


On Wed, May 03, 2006 at 02:45:56AM +0200, Uwe Hermann wrote:

this may be a dumb question, but I really wonder if there's a policy
(which I obviously haven't found) about which system users should get
a valid shell and which shouldn't.


Yeah, I had the same thoughts when I first installed tiger


This is bug #330882, and is basically because I'm exceptionally
conservative when it comes to base-passwd and it's rather hard to tell
whether anything in Debian might be relying on any of those users having
a valid shell.


I worried about that as well


I'm willing to change these, but I'd like to do it on a case-by-case
basis after scanning the archive for potential problems. At the moment
I'm not even sure how to begin that scan ...


As as a small datapoint, I took 4 machines I could play with and just
fixed all the IDs tiger bitched about - and waited for the fallout.

The results so far (several months later):
* fetchmail needs a shell (likely because of my pam.d & auth)
* news needs a shell to do any maintenance
* uucp needs a shell

The rest of the system accounts are happily running with /bin/false

I'm sure a few more folk could do likewise, and with some tracking,
this should be fairly easy to nail down...  With more testers, the
faster we'd find the few exceptions.
--
Rick Nelson
"By golly, I'm beginning to think Linux really *is* the best thing since
sliced bread."
(By Vance Petree, Virginia Power)


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

Re: XOrg transition, status of libxaw8

[David Nusinow]

On Tue, May 02, 2006 at 03:04:50PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > libxaw8 is abandoned upstream and there are no plans to fix it for the Xorg7
> > transition.  This is a >= serious bug for any package still build-depending
> > on libxaw8-dev, as they FTBFS and this isn't going to be fixed on the xaw8
> > side.
> 
> Or, a Debian developer could be solicited who would maintain the
> package.  We do not have to be tied to upstream's apron strings so
> rigidly.  Just because they drop something doesn't mean we must.
> 
> It may even be that MIT Athena will take this over, though I rather
> doubt it.

This library isn't truly abandoned by upstream, but essentially it's not
getting any new development. Cairo is considered the way forward and xprint
is widely (though not universally) considered a broken implementation. Xaw8
is Xaw7 by the way, only with some additional Xprint support that nothing
is really using as of yet. This is why I pinged every single package
maintainer who had a package that depended on xaw8 explicitly, asking them
if they needed it. No one replied in the affirmative, and several people
said explicitly that they didn't. As such, I killed what I see as a useless
library rather than let packages fester around it. If it's truly needed I
can resurrect it, especially now that Drew Parsons has packaged libxp, but
I'd rather not keep additional detrius around the archive if I don't have
to.

If you want to keep it around despite all this, that's your problem.

 - David Nusinow


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

Re: XOrg transition, status of libxaw8

[David Nusinow]

On Tue, May 02, 2006 at 07:18:17PM +0200, Frank K?ster wrote:
> Hi,
> 
> I recall that it was announced that libxaw8 should be dropped, but I
> can only find discussions on the X list and
> http://lists.debian.org/debian-x/2006/01/msg00409.html. 
> 
> Packages are starting to FTBFS because libxaw8 has not yet been adapted
> to the new Xorg directories (http://bugs.debian.org/365597), and there
> are two possible ways to fix this:  Either fix libxaw8-dev, or
> alternatively prevent libxaw8-dev from being used.
> 
> My question is now whether to switch away from libxaw8 is a wishlist
> issue or in fact a fixed plan?  What's the appropriate severity for
> "drop libxaw8" bugs, and what should maintainers do?

I wrote every maintainer of every package that build-depended on xaw8
asking if they needed it. I gave them quite a bit of time to respond, and
no one spoke up, so I dropped it. Everyone has been informed. I'd be
surprised if xaw3d couldn't just change back to xaw7, unless it truly needs
the xprint support.

 - David Nusinow


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

Re: System users and valid shells...

[Colin Watson]

On Wed, May 03, 2006 at 02:45:56AM +0200, Uwe Hermann wrote:
> this may be a dumb question, but I really wonder if there's a policy
> (which I obviously haven't found) about which system users should get
> a valid shell and which shouldn't.

This is bug #330882, and is basically because I'm exceptionally
conservative when it comes to base-passwd and it's rather hard to tell
whether anything in Debian might be relying on any of those users having
a valid shell.

I'm willing to change these, but I'd like to do it on a case-by-case
basis after scanning the archive for potential problems. At the moment
I'm not even sure how to begin that scan ...

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

System users and valid shells...

[Uwe Hermann]

Hi,

this may be a dumb question, but I really wonder if there's a policy
(which I obviously haven't found) about which system users should get
a valid shell and which shouldn't.

I get tons of warnings like this when I run tiger(8):

NEW: --WARN-- [pass014w] Login (bin) is disabled, but has a valid shell.
NEW: --WARN-- [pass014w] Login (daemon) is disabled, but has a valid shell.
NEW: --WARN-- [pass014w] Login (games) is disabled, but has a valid shell.
NEW: --WARN-- [pass014w] Login (gnats) is disabled, but has a valid shell.
NEW: --WARN-- [pass014w] Login (irc) is disabled, but has a valid shell.
NEW: --WARN-- [pass014w] Login (lp) is disabled, but has a valid shell.
NEW: --WARN-- [pass014w] Login (mail) is disabled, but has a valid shell.
NEW: --WARN-- [pass014w] Login (man) is disabled, but has a valid shell.
NEW: --WARN-- [pass014w] Login (news) is disabled, but has a valid shell.
NEW: --WARN-- [pass014w] Login (operator) is disabled, but has a valid shell.
NEW: --WARN-- [pass014w] Login (postgres) is disabled, but has a valid shell.
NEW: --WARN-- [pass014w] Login (proxy) is disabled, but has a valid shell.
NEW: --WARN-- [pass014w] Login (sys) is disabled, but has a valid shell.
NEW: --WARN-- [pass014w] Login (uucp) is disabled, but has a valid shell.
NEW: --WARN-- [pass014w] Login (www-data) is disabled, but has a valid shell.
[...]

Security-wise it's probably a good idea to give as few users as possible
a valid shell, all others should get /bin/false, right?

Should I CC debian-security?

Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org


signature.asc
Description: Digital signature

Re: XOrg transition, status of libxaw8

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> libxaw8 is abandoned upstream and there are no plans to fix it for the Xorg7
> transition.  This is a >= serious bug for any package still build-depending
> on libxaw8-dev, as they FTBFS and this isn't going to be fixed on the xaw8
> side.

Or, a Debian developer could be solicited who would maintain the
package.  We do not have to be tied to upstream's apron strings so
rigidly.  Just because they drop something doesn't mean we must.

It may even be that MIT Athena will take this over, though I rather
doubt it.



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

kudos to ftp-masters

[Jason D. Clinton]

Yes, seriously. We always complain about the NEW queue. I would just like to 
give some kudos to ftp-masters dealing so well with the bumpy xorg transition 
and for taking us down from 180 packages last week to 90 this week. Keep up 
the good work, guys.


pgpr8qByuBRfe.pgp
Description: PGP signature

Interim maintainer needed for thinkpad and tpctl

[Thomas Hood]

I plan to cease maintaining the thinkpad and tpctl Debian packages very soon.
Martin Krafft kindly agreed to take them over, but he will only be able to
start work at the end of May.  A new version of the thinkpad package needs
to be uploaded soon in order to close a bug that is rated severity: critical.
Therefore I am seeking an interim maintainer of thinkpad and tpctl, preferably
someone who would like to carry on as co-maintainer with Martin.
-- 
Thomas Hood


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

Re: XOrg transition, status of libxaw8

[Frank Küster]

clone 365714 -1
reassign -1 xaw3dg-dev
retitle -1 Depends on libxaw8-dev and breaks building packages
thanks

Steve Langasek <[EMAIL PROTECTED]> wrote:

>> My question is now whether to switch away from libxaw8 is a wishlist
>> issue or in fact a fixed plan?  What's the appropriate severity for
>> "drop libxaw8" bugs, and what should maintainers do?
>
> libxaw8 is abandoned upstream and there are no plans to fix it for the Xorg7
> transition.  This is a >= serious bug for any package still build-depending
> on libxaw8-dev, as they FTBFS and this isn't going to be fixed on the xaw8
> side.

Oh, that's much clearer and more severe than I expected.  Francesco,
will you be able to fix that soon, so that emacs21 can be built again
(and probably others?).

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: XOrg transition, status of libxaw8

[Steve Langasek]

On Tue, May 02, 2006 at 07:18:17PM +0200, Frank Küster wrote:

> I recall that it was announced that libxaw8 should be dropped, but I
> can only find discussions on the X list and
> http://lists.debian.org/debian-x/2006/01/msg00409.html. 

> Packages are starting to FTBFS because libxaw8 has not yet been adapted
> to the new Xorg directories (http://bugs.debian.org/365597), and there
> are two possible ways to fix this:  Either fix libxaw8-dev, or
> alternatively prevent libxaw8-dev from being used.

> My question is now whether to switch away from libxaw8 is a wishlist
> issue or in fact a fixed plan?  What's the appropriate severity for
> "drop libxaw8" bugs, and what should maintainers do?

libxaw8 is abandoned upstream and there are no plans to fix it for the Xorg7
transition.  This is a >= serious bug for any package still build-depending
on libxaw8-dev, as they FTBFS and this isn't going to be fixed on the xaw8
side.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Debian Installer team monthly meeting minutes (20060429 meeting)

[Christian Perrier]

(reply-to: debian-boot)

Debian Installer team meeting number 11 has been held from 16:00UTC to
17:30UTC on Saturday April 29th 2006.

There were about 75 people connected to the channel during the meeting
and 12 of them spoke during the meeting at least once.

The full log of the meeting is available at
http://people.debian.org/~bubulle/d-i/irc-meeting-20060429/log

New busybox
---

Bastian Blank has a pending upload for busybox 1.1.2 to replace
current 1.01 in unstable. He would like to have this version in but
this needs deeper testing with D-I.

The new version was announced in
http://lists.debian.org/debian-boot/2006/04/msg00542.html but no
testing report has been made since then.

It is suggested that more people test this by building their own D-I
netboot images with this new busybox, before it is uploaded to
unstable.

2.4 kernel support for etch
---

In general, we want to support 2.4 until the kernel is no longer in
the archive. However, depending on architectures, we may want to drop
it at different times.

Both the kernel and the release teams want to drop it, so the D-I team
has to be prepared for this to happen.

Joey mentions that many of his automated testing will break if 2.4 is dropped.

Petter also adds that it may help in the installer to be able to
install sarge (see another topic).

  i386: what to do?
  -

No strong conclusion here. The discussion kinda got lost among various
more general consideration.

There seems to be an increasing consensus that supporting 2.4 on i386
is mostly a waste of time, but actually dropping it would break stuff,
mostly Joey Hess automated tests which are very useful to the team.

  sparc: drop 2.4 for next Beta 
  -

General agreement for dropping it. It will break floppt images that
are currently build by G. Stappers (daily sparc images).

There are some issues with 2.6 kernels on sparc32, but 2.4 has issues
as well. Jurij Smakov is working on this.

  Need switch: m68k, mips/mipsel, S/390 (in progress)
  ---

Work is needed for net and dasd to be ready, for S/390. It seems that
2.6.17 could be needed. Basian Blank is working on this when he has
spare time. As soon as that is done, the remaining work can be handled
by Frans. So dropping 2.4 could be a little early for S/390.

No news for m68k: Frans will mail the porters.

For mipsel, DEC-station support for 2.6 is needed. It should work
upstream, but testers are needed. Martin Michlmayr will attempt to
mobilize some testers for that.

  Partial: arm, powerpc apus
  --

arm can drop 2.4 now. only lart/bast sub-architectures are broken and only
these are stuck with 2.4. Until they're fixed, they will be dropped.

powerpc apus needs a kernel patch. From our understanding things need
some work in the kernel team, which may require time.

Installing sarge with the etch installer


There is a demand for this, at least from the Debian-Edu people.
The installed system can either be a full sarge system (which
means that we would reboot in 2.6.8, which won't work in all
situations) or a mixed system with backported 2.6.16 or later kernels
(which the kernel team will probably maintain as backports).

The bricks for using backports are not there yet because some support
should be added for debian-cd to use two sources. A workaround would
be supporting sarge installs only with netboot/businesscard images.

Moreover, if 2.4 support is completely dropped, many cleanups will
occur in D-I (mostly removing hotplug hacks in packages like
hw-detect) which is very likely to break sarge installs as well.

As a summary, effort to allow sarge installs will go on if they're
possible. Deeper discussion with Debian-Edu might be needed about how
to achieve this.

udeb dependency transition (g-i integration)


Correct dependencies on other udebs for D-I udebs is a requirement for
the integration of the graphical installer builds in the normal build
system for D-I.

The status of this work is kept at 
http://wiki.debian.org/DebianInstaller/LibraryUdebs.
The work is mostly finished now, with no critical packages affected.

Now we only need pango from outside libraries and then rebuilds of
gtk+-directfb and cdebconf which we can do ourselves.

The path thus seems cleared for g-i integration in the next
beta. Debconf work of the D-I team will focus on this with "have an
integrated build of g-i at the end of debconf" as goal. The only
blocker is the needed pango upload.

Work on fonts should now be finalized by Davide. If he needs some
help, some other people could bring manpower.

Make floppy builds work
---

Of course, we're here talking about 2.6 floppies as dropping 2.4 is
very likely to happen at some moment.

The main blocker is klibc that needs to provide udebs. The maintenance
te

Re: screenshot with package description

[Daniel Ruoso]

Em Seg, 2006-05-01 às 17:54 +, Gonéri Le Bouder escreveu:
> I did some test. My repository is here: http://gloria.rulezlan.org/debian/
> update_tarballs.pl updates the index_* files and the tarballs.
> For the moment it doesn't create index for testing. It doesn't try to deal 
> with pixmap Depends.

Looks good... Some random thoughts:

1) Isn't some versioning info missing? I mean, you have screenshots, but
how can the user know if the screenshot refers to the current version
(that's quite relevant for games)... Actually, the user must be warned
if the screenshot is from an older version...

2) Shouldn't it have a standard for logos and screenshots? I mean, you
could have 2 types of images (logos or screenshot) with 2 sizes (low-res
or high-res).

3) It would be good to give the user the choice of downloading a subset
(for instance: only low-res, only logos), helping to reduce the
bandwidth usage.

4) A Packages.gz-like file would be helpful for upgrades (considering
the .tar.gz can be quite big, as you get 50k for one package), I would
suggest something like:

Package: netpanzer
Version: a.b-c
Pixmaps-Maintainer: Foo Bar <[EMAIL PROTECTED]>
Path: /pool/n/ne/netpanzer/
Low-Logo: netpanzer-a.b-c_logos_low.tar
High-Logo: netnetpanzer-a.b-c_logos_high.tar
Low-Screenshots: netpanzer-a.b-c_screens_low.tar
High-Screenshots: netpanzer-a.b-c_screens_high.tar
Low-All: netpanzer-a.b-c_all_low.tar
High-All: netpanzer-a.b-c_all_high.tar
All: netpanzer-a.b-c_all_all.tar

(the 'all' series can be optional to save server's disk usage)

5) I would suggest including the entry above together with the .tar
(maybe name it .pdeb), so it would be possible to upload it with tools
similar to dupload or dput, or to the user download an individual
pixmaps package and just install it...

daniel


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

XOrg transition, status of libxaw8

[Frank Küster]

Hi,

I recall that it was announced that libxaw8 should be dropped, but I
can only find discussions on the X list and
http://lists.debian.org/debian-x/2006/01/msg00409.html. 

Packages are starting to FTBFS because libxaw8 has not yet been adapted
to the new Xorg directories (http://bugs.debian.org/365597), and there
are two possible ways to fix this:  Either fix libxaw8-dev, or
alternatively prevent libxaw8-dev from being used.

My question is now whether to switch away from libxaw8 is a wishlist
issue or in fact a fixed plan?  What's the appropriate severity for
"drop libxaw8" bugs, and what should maintainers do?

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: effectiveness of rsync and apt

[Andreas Barth]

* Darren Salt ([EMAIL PROTECTED]) [060502 19:03]:
> I demand that Andreas Barth may or may not have written...
> > * Brian Eaton ([EMAIL PROTECTED]) [060501 19:21]:
> >> On 5/1/06, Andreas Barth <[EMAIL PROTECTED]> wrote:
> >>> Or you could create the diffdebs before upload or on ftp-master, and
> >>> include the diffdebs somehow in the Packages file (so they're signed as
> >>> well by the usual mechanismn).
> 
> >> My initial view is that any delta package system that doesn't reproduce
> >> the exact same .debs as downloading the package from scratch is a
> >> non-starter.
> 
> > Why that? Of course, you need all the maintainer scripts etc in the
> > diffdeb, but not all the regular files.
> 
> I wouldn't like to rely on the admin not having modified any of the package's
> files (/etc aside). Yes, this shouldn't happen, but it does :-)
> 
> Of course, if you're running md5sums on all of the package's files, this can
> be caught...

One need to do that, yes of course. Together with a list of permissions.
I'm not demanding it's trivial. But it's possible if one really minds.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: effectiveness of rsync and apt

[Darren Salt]

I demand that Andreas Barth may or may not have written...

> * Brian Eaton ([EMAIL PROTECTED]) [060501 19:21]:
>> On 5/1/06, Andreas Barth <[EMAIL PROTECTED]> wrote:
>>> Or you could create the diffdebs before upload or on ftp-master, and
>>> include the diffdebs somehow in the Packages file (so they're signed as
>>> well by the usual mechanismn).

>> My initial view is that any delta package system that doesn't reproduce
>> the exact same .debs as downloading the package from scratch is a
>> non-starter.

> Why that? Of course, you need all the maintainer scripts etc in the
> diffdeb, but not all the regular files.

I wouldn't like to rely on the admin not having modified any of the package's
files (/etc aside). Yes, this shouldn't happen, but it does :-)

Of course, if you're running md5sums on all of the package's files, this can
be caught...

[snip]
-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Lobby friends, family, business, government.WE'RE KILLING THE PLANET.

regular guy: n. A person who occurs at fixed or pre-arranged intervals.


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

Re: effectiveness of rsync and apt

[Darren Salt]

I demand that Pierre Habouzit may or may not have written...

[snip; delta packages?]
> The real question is: do people clean their apt cache or not? I do, because
> after a full X.org/kde/openoffice upgrade, it takes quite a lot of disk in
> /var (that is small on my computers). And with that cache cleaned, I fail
> to see how we could improve things much.

. But it's not a matter of if the apt cache is cleaned; it's a matter of
if, when, and whether old packages only or the whole cache is discarded.
Between lists update and packages download is the worst possible time to do
so for delta packages; cleaning out old packages immediately before update or
after an upgrade (or at least after the new versions are cached) seem to be
the best options and should still allow the maximum improvement.

> The mirrors replication could really benefit from that though.

Seems likely...

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Use more efficient products. Use less.  BE MORE ENERGY EFFICIENT.

4 Out of memory, 0:1


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

Re: utnubu-desktop for the masses

[Henning Makholm]

Scripsit Joey Hess <[EMAIL PROTECTED]>
> Henning Makholm wrote:

>> Can tasksel tasks be manipulated programmatically with the same
>> apt/aptitude inferfaces that metapackages can?

> This question does not have a yes or no answer, the situation is rather
> more complex than that.

Concretely: In order to clean up when I have played around with new
packages, I have a script that

  1) runs 'aptitude search ~i' and parses the output
  
  2) compares with a hand-maintained list of packages and
 metapackages that should be installed (with their dependencies)
 on my machine.

  3) emits appropriate 'aptitude markauto foo' and 'aptitude install
 bar' commands to remove packages that should not be there and
 install any packages that have been lost (perhaps because I
 temporarily removed them due to conflicts).

If the metapackages in my hand-maintiained list are changed to tasksel
tasks, can I still use my script without adding a parallel block of
code for handling the tasks? (How can that question not have a yes or
no answer?)

If I can't, then I oppose replacing those metapackages with tasks.

-- 
Henning Makholm "However, the fact that the utterance by
   Epimenides of that false sentence could imply the
   existence of some Cretan who is not a liar is rather unsettling."


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

Re: effectiveness of rsync and apt

[Goswin von Brederlow]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

> Le Lun 1 Mai 2006 15:31, Brian Eaton a écrit :
>> On 4/30/06, Goswin von Brederlow wrote:
>> > Look at zsync and help develope it far enough so it can look into
>> > debs. Without that the gain is practicaly 0 or less.
>>
>> It's entirely possible that the gain will be nothing no matter what
>> algorithm is used.
>>
>> The only time delta packages will be a win is for upgrades where the
>> client has the original package cached.  If the client is installing
>> the package from scratch, delta packages are useless.

Or when the package is already installed. Delta packages should be
deltas to the contents of the package as oposed to a delta of the
compressed deb. Most people don't keep the debs in the cache and a
delta of the compressed data would be quite useless space wise.

> that's a good point, and I suppose that most of the stable traffic is 
> due to first install of the packages. Though, I think it's not true 
> for :
>  - security mirrors (like pointed out in the thread already)
>  - testing and unstable, where users do many upgrades per month or even
>per week (I think I do almost one per day — let's say 5 per week —
>and I know a lot of people who do the same).

I agree. For stable delta package won't be worth it except for a short
while after the release.

> The real question is: do people clean their apt cache or not ? I do, 
> because after a full X.org/kde/openoffice upgrade, it takes quite a lot 
> of disk in /var (that is small on my computers). And with that cache 
> cleaned, I fail to see how we could improve things much.

If the cache would be of use for the next upgrade then I'm sure more
people would not clean their cache.

> The mirrors replication could really benefit from that though.

MfG
Goswin


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

Bug#365734: ITP: svn2bzr -- Converts a Subversion repository to a Bazaar 2.0 repository

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij <[EMAIL PROTECTED]>


* Package name: svn2bzr
  Version : 0.6.0
  Upstream Author : Gustavo Niemeyer <[EMAIL PROTECTED]>
* URL : http://www.bazaar-vcs.org/svn2bzr
* License : GPL
  Programming Lang: Python
  Description : Converts a Subversion repository to a Bazaar 2.0 repository

Converts a Subversion repository to a set of Bazaar 2.0 branches. This
tool does one-way conversions only and can not be used for incremental 
updates. Input will be read from a standard Subversion dump file.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: effectiveness of rsync and apt

[Goswin von Brederlow]

Peter Samuelson <[EMAIL PROTECTED]> writes:

>> * Goswin von Brederlow:
>> > Look at zsync and help develope it far enough so it can look into
>> > debs. Without that the gain is practicaly 0 or less.
>
> The other thing to do would be to lobby for dpkg-deb and dpkg-source to
> use 'gzip --rsyncable' when building stuff.  (That, or sneak
> "--rsyncable" into $GZIP inside buildd and pbuilder environments
> everywhere.)
>
> [Florian Weimer]
>> The downside is that anything that doesn't work on entire .debs is
>> very likely to change them at the byte stream level (you only need to
>> use slightly different zlib versions or parameters).
>
> Yeah, that's the weakness of the zsync idea.  Fortunately for them,
> zlib uses a very mature algorithm so it doesn't change often.

You can also check the checksum of the compressed blocks to detect
when rebuilding the deb fails and then just get it compressed.

MfG
Goswin


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

Re: effectiveness of rsync and apt

[Goswin von Brederlow]

Tyler MacDonald <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>> Bittorrent has a per chunk hash so it can validate each chunk when it
>> recieves it instead of waiting for the full file. It won't see if a
>> chunk is present at some other position in the file, not even if that
>> position is also on chunk boundaries.
>> 
>> Rsync has a per chunk Alder-32 and md4 checksum. Those chunk checksums
>> are compared to a chunk at every byte position in the file. The
>> Adler-32 checksum is fairly weak but it can be updated from one
>> position to the next with minimal work. Only when it matches does
>> rsync compute the expensive md4 checksum for the block.
>> 
>> 
>> The only thing that is simmilar is the "per block" when generating the
>> checksum, which is basicaly nothing.
>
>   Actually it's quite a bit of similarity... but you're right, they
> still are very different. From the article, it sounds like the author is
> suggesting storing these checksum values for quick retrieval, which gets
> closer to what BitTorrent is doing. If an rsync daemon were to spit out IP's
> of clients that were mirroring the exact same thing (which is technically
> feasable, given that an rsync client could easily send it's relevant
> command-line arguments upstream), then rsync clients could talk to
> eachother, which would lower the bandwidth requirements of top-level debian
> mirrors significantly.

The biggest difference is that the checksums aren't retrieved. They
are send. The client sends the checksums of the existing local file
and the server sends back blocks of raw data and matches to existing
chunks. Quite the reverse of BT.

For precalculated (and retrivable) checksums look at zsync.

>> MfG
>   ?

Mit freundlichen Gruessen

>   Cheers,
>   Tyler
Goswin


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

Re: effectiveness of rsync and apt

[A Mennucc]

hi

I did a similar thing some time ago; I used 'xdelta' on two versions of
kernel and of tetex; the results were impressive; I could prepare a
'debdiff' that was < 10% (AFAICR) of the size, and that would recreate
an exact copy of the new version of the package, given the previous
version of the package. Currently my notebook is broken (power
transformer fried with a white flash); when it is alive again, I will
post more details.

a.

Brian Eaton wrote:
> Hello all -
> 
> Regarding the ideas discussed here:
> 
> http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html
> 
> Has anyone ever done some log file analysis to figure out how much
> bandwidth would be saved by transferring package deltas instead of
> entire new packages?
> 
> Assuming someone hasn't done the work already, I'd be interested in
> looking at some logs to figure it out.
> 
> Regards,
> Brian
> 
> 


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

no libldap-dev from openldap2.2 package?

[John v/d Kamp]

Hi,

When I install the development files for libldap, I always get the
libldap2-dev package, version 2.1.30. It also seems from the
debian/control file in openldap2.2 that there is no libldap2.2-dev (or
something) package that gives the new headers and /usr/lib/libldap.so
that points to the new libldap version.

Is there a specific reason that this package is left out?
How should I compile my program so that it always links with
/usr/lib/libldap-2.2.so.7?

Thanks,

John


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

Re: fonts prbl in sid

[A Mennucc]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

James Vega wrote:
> On Mon, Apr 24, 2006 at 11:22:42AM +0200, A Mennucc wrote:
> 
>>hi
>>
>>I use sid and Gnome ; I upgraded my box (after 3 weeks in which I did 
>>not have time to) ; now I have serious problems with fonts.
> 
> 
> Have you reconfigured xserver-xorg?  As part of the modular Xorg update,
> the directories the fonts reside in have moved.  Your xorg.conf may
> still be pointing to the old directories.  Refer to
>  for other side-effects you may
> experience from the upgrade.


thank you,

it was not very easy to tell to have dpkg-reconfigure to properly
recreate /etc/X11/xorg.conf ; then I managed to put the correct MD4 in
the correct directory; then, after reboot , it all worked fine
(for some reason, server restart was not enough...)

a.



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

iD8DBQFEVzdl9B/tjjP8QKQRAmdVAJ9gyCVSM4LsV5pHRl8uoWIn3oGi7QCghWBc
xa5qEN8+/cVvy2Qy9HEHb+s=
=kt69
-END PGP SIGNATURE-


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

Re: fonts prbl in sid

[A Mennucc]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Meskes wrote:
> On Mon, Apr 24, 2006 at 11:38:43AM +0300, Daniel Stone wrote:
> 
>>>almost unusable ; including 'emacs-snapshot-gtk' 'display' 'xmms'
>>>('xmms' is missing fonts for the menus but not for the main display);
> 
> 
> Not sure if this is related but for display see 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363371
> 
> Michael

yes it was the same bug

 it was solved by forcing  dpkg-reconfigure to properly recreate
/etc/X11/xorg.conf ; then , after reboot , it all worked fine (for some
reason, server restart was not enough...)

a.


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

iD8DBQFEVzcx9B/tjjP8QKQRAul7AKCN64Qd7dCkMq0A/LapNK+zndaMXgCdGjaS
5SDTcri3TQ3Jz74ZgstUNqo=
=uaiD
-END PGP SIGNATURE-


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

Re: Using defoma for building package ?

[Josselin Mouette]

Le dimanche 30 avril 2006 à 22:43 +0200, Marcus Better a écrit :
> Is there a way to use fc-match to locate a Type1 font (pfb) and also its
> associated font metrics (the afm file)?

I may be wrong, but as fontconfig was designed for Xft which doesn't
make use of the .afm file but only uses the .pfb directly, I think
fontconfig cannot locate the .afm.

Regards,
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Using defoma for building package ?

[artefact]

Le 30.04.2006 22:43, Marcus Better a écrit :

> Josselin Mouette wrote:
>
> >How about using fontconfig ? Even without using the API you can use it
> >to look for a font:
> >$ fc-match --verbose sans | awk '$1=="file:"'
> >file: "/var/lib/defoma/fontconfig.d/D/DejaVu-Sans.ttf"(s)
>
>
> Is there a way to use fc-match to locate a Type1 font (pfb) and also its
> associated font metrics (the afm file)?
>
> Marcus
>
Thank you, I will have a look at fontconfig, I think this is the right way !

Regards, Jean

-- 
 _
/ Il y a malgré tout un avantage à  \
| tomber en panne sèche. C'est que c'est |
| moins lourd à pousser que si le|
| réservoir est plein. -+- Philippe  |
\ Geluck, Le chat -+- /
 -
\   ^__^
 \  (..)\___
(__)\   )\/\
||w |
|| ||


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

Re: Bug#364652: ITP: squid3 -- Internet Object Cache (WWW proxy cache) version 3

[Gunnar Wolf]

Luigi Gangitano dijo [Tue, Apr 25, 2006 at 02:14:46PM +0200]:
> 
> Il giorno 25/apr/06, alle ore 07:12, Norbert Tretkowski ha scritto:
> >>squid 3.0 is not yet 'stable'. Squid 2.5 is still the stable series.
> >
> >Why not just uploading squid 3.0 to experimental?
> 
> Because it's not a short term package. It will be there for at least  
> 6 months.
> 
> And experimental is not enough used to guarantee proper testing of  
> this new version.

Hmh, six months...

Please keep in mind that we plan on releasing Etch in little more than
six months - This means that, if you upload Squid3 to unstable, Etch
might end up shipping Squid 2.5 and an almost-there-but-not-there-yet
Squid 3. A situation similar to what happened in Sarge with mod_perl
for Apache2, where the official version (including a late API change)
was released two weeks after Sarge had frozen. 

I also suggest you to use experimental for this. If you want a wider
test base, maybe set up an unofficial repository and publicize it.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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