Bug#352912: marked as done (general: Reduce network load using zip packaging and VFS)

[Debian Bug Tracking System]

Your message dated Wed, 15 Feb 2006 02:31:57 -0600
with message-id <[EMAIL PROTECTED]>
and subject line Bug#352912: general: Reduce network load using zip packaging 
and VFS
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: general
Severity: wishlist

Here is my plan how to reduce Debian servers load and users Debian packages
download bandwidth:

1. Package in .zip (or a similar format) instead of .tar.{gz,bz2}

2. Implement ZIP filesystem as Linux kernel module.

3. Users could be then able to mount a .zip file from the Debian FTP server
and compile a package directly from the server. This would reduce download
I deem some about 50% compared with current downloading a source package
for compilation, because in this scheme only used files from the source
would be download (no downloading of documentation which is not needed for
compilation of a package, etc.)

Here there is however a complicated issue of what to do with Debian
patches.

Ideally we would also add Linux module for "patched file system" (on the
top of any filesystem, e.g. the above mentioned ZIP filesystem), which
would display files from an other FS with a given patch applied.

A simpler implementation would be to have TWO .zip files for each package
on Debian FTP site: unpatched .zip file (equivalent to .tar.{gz,bz2} as
currently used) and also patched .zip file, which could be usable for above
mentioned compilation directly from the FTP server without downloading.

--- End Message ---
--- Begin Message ---

[Victor Porton]
> Here is my plan how to reduce Debian servers load and users Debian
> packages download bandwidth:

It sounds as though you are concerned with source packages, not binary
packages.  Do you have reason to believe that a significant fraction of
Debian archive bandwidth is the source packages?  I suspect it's a very
small fraction.

> 3. Users could be then able to mount a .zip file from the Debian FTP
> server and compile a package directly from the server. This would
> reduce download I deem some about 50% compared with current
> downloading a source package for compilation, because in this scheme
> only used files from the source would be download (no downloading of
> documentation which is not needed for compilation of a package, etc.)

Building a package with dpkg-buildpackage or debuild scans the entire
source tree, as well as the .orig.tar.gz, in order to generate the
.diff.gz file.  So your hypothetical benefit only accrues to people who
explicitly tell dpkg-buildpackage or debuild *not* to rebuild the
source package.

Speaking for nobody in particular, I highly doubt your approach will
ever be implemented.  Acting on nobody else's behalf, I'm closing your
bug.  Anyone's free to reopen it if you feel I'm wrong.


signature.asc
Description: Digital signature
--- End Message ---

Bug#352912: general: Reduce network load using zip packaging and VFS

[Lars Wirzenius]

ke, 2006-02-15 kello 04:00 +0500, Victor Porton kirjoitti:
> Here is my plan how to reduce Debian servers load and users Debian packages
> download bandwidth:
> 
> 1. Package in .zip (or a similar format) instead of .tar.{gz,bz2}

Picking a random package:

-rw-rw-r--   1 liw liw 18113820 Mar 18  2005 emacs21_21.4a.orig.tar.gz
-rw-rw-r--   1 liw liw 19544036 Feb 15 10:26 emacs21_21.4a.orig.zip

The .zip is almost 8% larger than the .tar.gz. This is, in fact, pretty
typical, because a .zip compresses each file separately and a .tar.gz
compresses all the files as one, so that similarities between files
reduce the total size.

(Once we use .tar.bz2, the sizes will be even smaller.)

> 2. Implement ZIP filesystem as Linux kernel module.

There is no need to do that in the kernel, of course.

> 3. Users could be then able to mount a .zip file from the Debian FTP server
> and compile a package directly from the server. This would reduce download
> I deem some about 50% compared with current downloading a source package
> for compilation, because in this scheme only used files from the source
> would be download (no downloading of documentation which is not needed for
> compilation of a package, etc.)

The documentation files are needed to build the .deb package, so it is
no good to not download them.

If there is a particular reason you have for wanting to build only
partial packages, or in fact to build them at all unless you're a
developer, please explain it. Since I can't think of any such reason
myself, I'm closing the bug, but that does not mean it can't be reopened
if you have a good reason.

-- 
You need fewer comments, if you choose your names carefully.



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

Re: Changing menu item name

[Michael Biebl]

Chandan M. C. wrote:
> Hai ,
> 
>  Is it possible to change the menu name ... I need to change the "debian
> menu" what is appearing in "Applications" start menu of gnome ... Instead
> of debian menu I need some other name ... How and whr I can change If
> I want to change in source in which pkg I can change ..

If you run a recent Gnome installation edit the file
/etc/xdg/menus/gnome-applications.menu.
Go to the section  and change the content
between ...
The gnome panel should pick up the changes immediately.

Cheers,
Michael



signature.asc
Description: OpenPGP digital signature

Re: Library interface version question

[Henning Makholm]

Scripsit Shachar Shemesh <[EMAIL PROTECTED]>
> Henning Makholm wrote:

>>You are supposed to write an appropriate shlibs file, as described in
>>policy �8.6. Have you done so?

> My file is currently automatically generated by dh_shlibdeps, and says
> "libargtable2 0 libargtable2-0".

No it isn't. dh_shlibdeps is jus a wrapper around dkpg-shlibdeps,
which does not generate shlibs files. It _reads_ shlibs files and
collects substvars for use in your package's Depends line.

Please do read the documentation.

> I realize that I should place any version restrictions there, if I
> want them. The question is whether I should just state the version
> at which the interface advance there, or whether I should do some
> other version tricks?

You are the maintainer; it is your job to know which versions and
packages it is appropriate for freshly compiled client programs to
depend on.

> In a nutshell - because then the information regarding which backwards
> compatible interface to use is lost.

You seem to be misunderstanding the purpose of /usr/lib symlinks. See
Steve Langasek's answer.

-- 
Henning Makholm  "Wir kommen nun ans Ziel unserer Ausführungen."


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

Re: timezone data packaged separately and in volatile?

[Michelle Konzack]

Am 2006-02-07 14:40:52, schrieb Ian Jackson:

>  2. The package fixes a critical bug which can lead into data loss,
>  data corruption, or an overly broken system, or the package is broken
>  or not usable (anymore).
> 
> That seems to be true in this case.  I think a system which gets the
> clock wrong in this way is `overly broken'.

And if you have scheduler which take critical operations (erasing
of files or or something similar) it would be critical.

> There doesn't seem to be anything in those rules which allows for an
> analysis of the risk, so that it can be compared to the benefit.
> (Perhaps that's implicit, although it's not stated.)  A timezone
> update, carefully built against the right dependencies, could be
> diffed (that is, the .deb could be diffed) against the old version and
> carefully tested, which would provide us with confidence that the new
> package is right to install.

I have an international database where I need correct timezones.
Currently I have a server side script for Australian $USERS.
 
> Ian.

Greetings
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)


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

Bug#352953: ITP: pyqonsole -- X terminal emulator written in python

[Alexandre Fayolle]

Package: wnpp
Severity: wishlist
Owner: Alexandre Fayolle <[EMAIL PROTECTED]>

* Package name: pyqonsole
  Version : 0.2.0
  Upstream Author : Logilab <[EMAIL PROTECTED]>
* URL : http://www.logilab.org/projects/pyqonsole
* License : CeCILL 
  Description : X terminal emulator written in python

Pyqonsole is an X Window terminal written in Python. The code is based
on konsole, and it uses the Qt toolkit. It is mainly meant for use by
Python application developpers who would like to embed a terminal in
their application, but it can be used as a not blazingly fast XTerm
replacement.

Text of the CeCILL license available on
http://www.cecill.info/licences/Licence_CeCILL_V2-en.html

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: [Pbuilder-maint] pbuilder, xvfb and nonexisting /tmp/.X11-unix

[Junichi Uekawa]

Hi,

> 
> I'm seeking advice on the following problem:
> - xvfb-run bails out on nonexistant / not root-owned /tmp/.X11-unix,
> - a/my pbuilder chroot won't have /tmp/.X11-unix,
> - I need some X (xvfb is fine) to build libaqbanking (glade-2 code
>   generation needs X bug).
> 
> A working work-around is build-depending on fakeroot and calling
> fakeroot xvfb-run.
> 
> Any better ideas?

I thought I fixed it already.

pbuilder (0.138) unstable; urgency=low

  * Bug fix: "pbuilder: please add x11-common to policy-rc.d", thanks to
patch from Aurelien Jarno (Closes: #337541).
Fixes interaction with xvfb.
Please recreate base.tgz for this to take effect.

 -- Junichi Uekawa <[EMAIL PROTECTED]>  Fri, 11 Nov 2005 08:46:38 +0900


What's the issue?


regards,
junichi
-- 
[EMAIL PROTECTED],netfort.gr.jp}   Debian Project


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

Re: pbuilder, xvfb and nonexisting /tmp/.X11-unix

[Junichi Uekawa]

Hi,

> Daniel Schepler wrote:
> > Have you tried just recreating base.tgz with an up-to-date pbuilder?
> Ah, no. Cool. I'll have to file a wishlist item against pbuilder to
> update its configuration upon update.
 
One problem is that currently policy-rc.d is just stuffed in without
any version control, it should probably be installed as a package
inside chroot.


regards,
junichi
-- 
[EMAIL PROTECTED],netfort.gr.jp}   Debian Project


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

Re: [Pbuilder-maint] pbuilder, xvfb and nonexisting /tmp/.X11-unix

[Thomas Viehmann]

Junichi Uekawa wrote:
> Please recreate base.tgz for this to take effect.

> What's the issue?
Sorry, I missed the changelog entry (it took a while for me to trigger
that bug and someone else using a newer chroot but probably
pbuilder/stable had the same problem but I didn't think of him not using
unstable).
I like your idea of customizing pbuilder chroots with debs. I'm not fond
of recreating the base.tgz because I have some customizations
(editor...) in my chroot.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

Contact Centre - Partnership enquiry

[info]

Hi,

I am Alex accounts manager of Skymkglobal. We just opened a new office and 
currently looking for reliable partners that would benefit of our services. 
We successfully run an customer service and reactivation project for a 
company like yours. We are located in Europe, Romania  and we have 5 years 
experience in the contact centre industry.  We provide services like: 

-customer service
-live chat
-email handling
-customer renewal 
-appointment setting 
-soft sales


Did you know that :
75% of all e-shopping carts are abandoned before the purchase is actually 
complete. Nine out of 10 shoppers who abandoned their carts did so because 
of a lack of customer service. (Web Merchant, Fall 2003, Cybershopper 
Survey) 

72% of respondents said that customer service is critical in shopping 
satisfaction. Less then one percent of all ecommerce Websites offer live 
customer assistance. (eMarketer, June 2002)?


We can help you turn your prospects into customers, and then your customers 
into advocates. We focus on building a relationship that lasts by using a 
personalized approach that provides the value addition necessary to 
maintain and grow your client base.

If you are interested in knowing more details please reply and I shall send 
this over, are you reachable by telephone to discuss this further?


Awaiting your reply, 
Alex

www.skymkglobal.com
[EMAIL PROTECTED]


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

Bug#352912: general: Reduce network load using zip packaging and VFS

[Портон Виктор Львович]

First, I suggested .zip just for an example. There are other similar archivers 
with bigger compression ratio.

>> 3. Users could be then able to mount a .zip file from the Debian FTP
server
>> and compile a package directly from the server. This would reduce
download
>> I deem some about 50% compared with current downloading a source package
>> for compilation, because in this scheme only used files from the source
>> would be download (no downloading of documentation which is not needed
for
>> compilation of a package, etc.)
>
>The documentation files are needed to build the .deb package, so it is
>no good to not download them.

Not always. For example, apache2 package is split into two packages: apache2 
and apache2-doc (and also apache2-dev and several others). To Build apache2 
binary package most of documentation files are not needed. In the case of 
apache2 downloading only needed files (e.g. using compilation directly from 
network filesystem) would be big traffic save.

>If there is a particular reason you have for wanting to build only
>partial packages, or in fact to build them at all unless you're a
>developer, please explain it. Since I can't think of any such reason

Reducing traffic.

>myself, I'm closing the bug, but that does not mean it can't be reopened
>if you have a good reason.

One more additional thought: We can make Debian server to serve files like 
apache2_2.0.55.zip/README and/or apache2_2.0.55-4.zip/README (patched) 
delivering to clients (compressed) entries from the .zip archive. (Which 
protocol to use? Not HTTP due too big overhead. Or maybe HTTP is OK with 
pipelining? At least HTTP well supports tranferring archived data. File modes 
can be specified by an extension HTTP header.)

Then clients would be able to mount these (source) archives as filesystems.

-- 
Victor Porton ([EMAIL PROTECTED])


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

Re: Bug#352912: general: Reduce network load using zip packaging and VFS

[Russ Allbery]

Портон Виктор Львович <[EMAIL PROTECTED]> writes:

> Not always. For example, apache2 package is split into two packages:
> apache2 and apache2-doc (and also apache2-dev and several others). To
> Build apache2 binary package most of documentation files are not
> needed. In the case of apache2 downloading only needed files (e.g. using
> compilation directly from network filesystem) would be big traffic save.

I still don't understand what problem you're trying to solve by reducing
downloads for source packages, even if successful.  Very, very few people
download source packages.  Debian is a binary distribution.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Size matters. 7zip. Again.

[Eduard Bloch]

#include 
* Lars Wirzenius [Wed, Feb 15 2006, 10:42:02AM]:

> (Once we use .tar.bz2, the sizes will be even smaller.)

I cannot remember a clear consens from the "Size matters" thread, and
IMO we should go for 7zip at least for source packages.

Eduard.
-- 
For any stupid thing chosen at random, you'll find at least 5 people on
the Internet who thinks it's a good idea. -- Steve Langasek in debian-devel


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

Re: Bug#352535: ITP: gitmail -- Very simple graphical mail user agent for sending mail (GTK)

[Adeodato Simó]

* Jari Aalto [Tue, 14 Feb 2006 01:13:36 +0200]:

> The HELO argument may be funny,

  It says something about the author.

> but the package seems to work okay. This list weight GUI version of
> sending mail (in contrast to console based ones; mutt etc.), is very
> small application that is suitable for low end machines (166Mhz).

  This has a point.

> Can you all provide more information on

> "too buggy that we refuse to support it"
>  full of malloc(FIXED_NUM)

> So that I can take this to upstream. Is there improvements
> that you would like to propose?

  See Lars' mail.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Y sobre todo, tienes mucho de gilipollas.
-- B.C.S. addressing P.G.i.Q in b8g


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

New sbuild release 0.38

[Roger Leigh]

Hi folks,

sbuild 0.38 has been released; the changelog follows at the end of
this message.  It's tagged in CVS as sbuild_0_38, and has been
uploaded to experimental.  It is also available at
http://people.debian.org/~rleigh/sbuild-0.38/

If you are a user of sbuild, it would be greatly appreciated if you
could test this release.  It has already had a good bit of testing,
but if there are any corner-case regressions that have been missed, it
would be great to catch them before it is uploaded to unstable.


I'm also posting this to -devel, to bring everyone up-to-date on the
current state of sbuild following on from the thread in November
(starting at
http://lists.debian.org/debian-devel/2005/11/msg01368.html).

Version 0.37, released on the 31 Jan 2006, was an almost-complete
merge with upstream; the list of changes is also attached below.  This
fixed a number of long-standing bugs, as well as removing a number of
incompatibilities with upstream (it should now be possible to use the
packaged sbuild on a buildd, for example).  The next step is merging
all of our bugfixes with upstream.  These patches are available at
https://alioth.debian.org/tracker/index.php?group_id=30471&atid=411184

Version 0.38 fixes a number of bugs, as well as introducing a number
of larger changes, the most important being
- full sudo access is no longer required on the host system; access to
  the chroot and host system is now provided through a simple API to
  make chroot use uniform throughout sbuild.
- schroot session management is integrated.  This means that you can
  build using any chroot type supported by schroot(1), including LVM
  snapshots, files (zip, tar(.gz|.bz2) in a manner similar to
  pbuilder), as well as normal chroots.  This is selected with
  $chroot_mode="schroot" in /etc/sbuild.conf.local.
The only user-visible change should be more verbose log messages; this
will probably need to be made configurable.


Regards,
Roger


sbuild (0.38) experimental; urgency=low

  * Full sudo access is no longer mandatory when using the schroot
chroot_mode (Closes: #287669, #331506).
  * schroot session management is now fully implemented and completely
functional.
  * sbuild:
- Move schroot metadata parsing to a separate function,
  get_schroot_info().  Parse both "Location" (for
  backwards-compatibility) and "Mount Location".
- Move path and APT setup into a separate function, setup_options().
- Remove check_dpkg_version().  This has not been necessary since the
  release of potato (Debian 2.2), which had a dpkg version 1.6.14.
- When $chroot_mode == "schroot", clear %main::dist_order and
  %main::dist_locations using an empty array, rather than undef.
- New functions get_command(), run_command(), get_apt_command() and
  run_apt_command() to run a command inside or outside the build
  chroot under the specified user, or run apt inside or outside the
  chroot (depending on the chroot_mode), respectively.
- New function exec_command().  This is the same as run_command(), but
  runs the command with exec rather than system().
- New functions log_command() to log a command being run,
  get_command_internal() and get_apt_command_internal() to get a
  command string without logging it; these are used by get_command(),
  run_command, exec_command(), get_apt_command() and run_apt_command(),
  which do log the command being run.  Commands are logged in for all
  chroot modes.
- get_apt_command() and run_apt_command() take an additional parameter,
  the command to run (apt-get or apt-cache).
- get_apt_command() and run_apt_command() take an additional parameter,
  the user to run as, because not all commands need (or should) run as
  root.
- Use new commands for running commands inside and outside chroots:
  + Signing options for dpkg-buildpackage are double-quoted rather than
single-quoted (because the main command is single-quoted).
  + All commands run in a pipeline are obtained with get_command() or
get_apt_command().
  + All other commands are run with run_command(), exec_command() or
run_apt_command().
  + check_space() only requires root access in the chroot.
- Add schroot session management.  Sessions are created, run and
  removed automatically.  The current session is stored in
  $main::schroot_session.  setup_options is called once per build, in
  order to set up the session options.
- Add missing newline to log message.
  * sbuild.1:
- Update outdated information.
- Correct macro usage and reindent.
- Correct command-line summary (Closes: #311589).
  * sbuild-setup.7: New manpage.  This describes how to set up a chroot
(Closes: #311363).
  * avg-pkg-build-time.1: Clean up.
  * update-sourcedeps.1: Clean up.
  * sbuild.conf: $schroot_options defaults to "-q" to match the built-in
default.
  * example.sbuildrc: Single quote example em

limitations of reportbug and BTS

[kamaraju kusumanchi]

Hi

  I wanted to report a minor bug on kicker using reportbug package 
tool. But then it forces me to read a huge number of bug titles (around 
647 of them) most of which were not filed against kicker. For example it 
shows bugs against kdeprinter, kate, konsole etc., Why is this so? I 
think it kind of discourages users who want to report to bugs against a 
single package...


   Moreover, bugs.debian.org does not allow me to search for bug 
reports which contain particular words. It kind of forces people to 
search against packages which I think is somewhat restrictive. For 
example, I wanted to search for bugs which have the error message


"X Error: BadWindow (invalid Window parameter) 3"

This kind of thing is not possible currently. Do you think it is a good 
implement such a feature? Currently bugs.kde.org allows this (searching 
for strings in the bug reports without worrying about package names etc.,).


thanks
raju

--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/


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

Re: Size matters. 7zip. Again.

[John Goerzen]

On Wed, Feb 15, 2006 at 06:45:21PM +0100, Eduard Bloch wrote:
> #include 
> * Lars Wirzenius [Wed, Feb 15 2006, 10:42:02AM]:
> 
> > (Once we use .tar.bz2, the sizes will be even smaller.)
> 
> I cannot remember a clear consens from the "Size matters" thread, and
> IMO we should go for 7zip at least for source packages.

There are a lot of problems with 7zip.

They continue to fix various segfault bugs.

It is rather windows-centric in its approach in many ways.

They've recently added support for symlinks and file permission bits,
and still don't support storing of uid/gid.  You can probably pretty
much forget storage of hard links and sparse files.

I wouldn't be surprised to find various security bugs that have been
long-since fixed in tar, such as unpacking files with names such as
../../../etc/passwd or whatnot.

You may say that some of these don't matter for source archives.  That
is true to a certain extent, but security does matter there still.

-- John


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

Re: Bug#352535: ITP: gitmail -- Very simple graphical mail user agent for sending mail (GTK)

[Jari Aalto]

Adeodato Simó <[EMAIL PROTECTED]> writes:
>> Can you all provide more information on
>
>> "too buggy that we refuse to support it"
>>  full of malloc(FIXED_NUM)
>
>> So that I can take this to upstream. Is there improvements
>> that you would like to propose?

I noticed that later. I've forwarded the discussion to upstreams and
he acknowledges the problems. There is a promise to get them fixed,
because this project is hosted at sourceforge.

Thank you for participants to point how to improve this package,

Jari



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

Re: Size matters. 7zip. Again.

[Aurelien Jarno]

John Goerzen a écrit :

On Wed, Feb 15, 2006 at 06:45:21PM +0100, Eduard Bloch wrote:


#include 
* Lars Wirzenius [Wed, Feb 15 2006, 10:42:02AM]:



(Once we use .tar.bz2, the sizes will be even smaller.)


I cannot remember a clear consens from the "Size matters" thread, and
IMO we should go for 7zip at least for source packages.



There are a lot of problems with 7zip.

They continue to fix various segfault bugs.

It is rather windows-centric in its approach in many ways.

They've recently added support for symlinks and file permission bits,
and still don't support storing of uid/gid.  You can probably pretty
much forget storage of hard links and sparse files.

I wouldn't be surprised to find various security bugs that have been
long-since fixed in tar, such as unpacking files with names such as
../../../etc/passwd or whatnot.

You may say that some of these don't matter for source archives.  That
is true to a certain extent, but security does matter there still.



What about using .tar.7z files to fix those problems?


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


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

Re: Bug#352535: ITP: gitmail -- Very simple graphical mail user agent for sending mail (GTK)

[Jari Aalto]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

> On Tue, 14 Feb 2006, Ron Johnson wrote:
>
>> On Tue, 2006-02-14 at 03:35 -0500, Glenn Maynard wrote:
>> > On Tue, Feb 14, 2006 at 10:07:45AM +0200, Jari Aalto wrote:
>> > > Ron Johnson <[EMAIL PROTECTED]> writes:
>> > > 
>> > > > On Tue, 2006-02-14 at 01:16 +0200, Jari Aalto wrote:
>> > > >> 
>> > > >> The speciality is the small size + GUI to send mail. Useful for
>> > > >> low end harware (166Mhz / 64 M mem).
>> > > >
>> > > > But that's just it.  It's for *sending* mail only.  What is the
>> > > > purpose of a GUI for sending mail?
>> > > 
>> > > The small memory footprint. In minimalistic Window manager +
>> > > minimalistic program to send mail. 
>> > 
>> > Err, who uses GTK when "small memory footprint" or "minimalistic"
>> > are objectives?
>> 
>> XFce is lighter than GNOME.
>> 
>> And writing in GTK is (supposed to be) easier that writing Xlib.
>
> Which's the reason you use xaw.  But in this case, it is a simple X-based
> form plugged to broken crap that needs to be replaced, and which could well
> be replaced by a call to sendmail.  Thus, you don't even need C code, just a
> tcl/tk script.

Not so fast. If the light weight system is to be kept as small as
possible, the additional tcl/Tk libraries would not be welcomed.

GTK at least is common to most of the C programs that do not bring
along other libraries.

The programs talks directly to SMTP, so there is no need to require
a MTA in the system.

Upstream is interested in getting the program in better shape based on
the malloc-discussion here.

Jari



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

Re: Bug#352912: general: Reduce network load using zip packaging and VFS

[Kevin Mark]

On Wed, Feb 15, 2006 at 08:25:07PM +0300, =?UTF-8?Q? 
=D0=9F=D0=BE=D1=80=D1=82=D0=BE=D0=BD_?=   
=?UTF-8?Q?=D0=9B=D1=8C=D0=B2=D0=BE=D0=B2=D0=B8=D1=87 ?= wrote:
> First, I suggested .zip just for an example. There are other similar 
> archivers with bigger compression ratio.
> 

> 
> One more additional thought: We can make Debian server to serve files like 
> apache2_2.0.55.zip/README and/or apache2_2.0.55-4.zip/README (patched) 
> delivering to clients (compressed) entries from the .zip archive. (Which 
> protocol to use? Not HTTP due too big overhead. Or maybe HTTP is OK with 
> pipelining? At least HTTP well supports tranferring archived data. File modes 
> can be specified by an extension HTTP header.)
> 
> Then clients would be able to mount these (source) archives as filesystems.
> 
> -- 
> Victor Porton ([EMAIL PROTECTED])
> 
Hi Victor,
Debian seems to like folks to do stuff as well as make suggestions.
Could you implement any of your ideas in a small scale and provide a
report of benefits. And if possible allow other folks access to this
system. I would use the excellent example of Ingo J. who provides the
buildd.net service. Even if all of his ideas have not been integrated
into debian, it still provides a useful service and is an example of
possible improvements that debian could utilize. The benefit Ingo's
service provide are apparent only after having seen it in action and not
merely from reading his proposal.
Cheers,
Kev
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal | debian.home.pipeline.com |
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
| my keysever: pgp.mit.edu   | my NPO: cfsg.org |


signature.asc
Description: Digital signature

Re: Size matters. 7zip. Again.

[Jari Aalto]

Eduard Bloch <[EMAIL PROTECTED]> writes:

> #include 
> * Lars Wirzenius [Wed, Feb 15 2006, 10:42:02AM]:
>
>> (Once we use .tar.bz2, the sizes will be even smaller.)
>
> I cannot remember a clear consens from the "Size matters" thread, and
> IMO we should go for 7zip at least for source packages.

There are more alternatives:  http://rzip.samba.org/

...In the following I show the compression ratios of the
large-corpus for rzip 2.0, gzip 1.3.5 and bzip2 1.0.2 on my Debian
Linux laptop. In all cases the programs were run with their
maximum compresion options.

File Name rzip  gzipbzip2   
large-corpus/archive  6.03  3.644.97
large-corpus/emacs5.08  3.664.62
large-corpus/linux5.54  4.245.23
large-corpus/samba9.55  3.504.78
large-corpus/spamfile 29.95 8.4314.23

Does anyone know how 7zip would compare to this?

Jari


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

Re: limitations of reportbug and BTS

[Marco d'Itri]

On Feb 15, kamaraju kusumanchi <[EMAIL PROTECTED]> wrote:

> This kind of thing is not possible currently. Do you think it is a good 
> implement such a feature? Currently bugs.kde.org allows this (searching 
> for strings in the bug reports without worrying about package names etc.,).
You use google groups to search the linux.debian.bugs.dist newsgroup.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Size matters. 7zip. Again.

[Miriam Ruiz]

 --- Jari Aalto <[EMAIL PROTECTED]> escribió:

> There are more alternatives:  http://rzip.samba.org/

>From the same web page:

"rzip is not for everyone! The two biggest disadvantages are that you can't
pipeline rzip (so it can't read from standard input or write to standard
output), and that it uses lots of memory. A typical compression run on a large
file might use a couple of hundred MB of ram. If you have ram to burn and want
the best possible compression rate then rzip is probably for you, otherwise
stick with bzip2 or gzip."

I'm not sure whether not being able to pipeline it might be a problem, but
needing that huge amount of RAM might, at least in my oppinion. I'm not sure
if they're refering just to compression or both to compression and
decompression anyway.

Greetings,
Miry




__ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com


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

Re: limitations of reportbug and BTS

[Brian M. Carlson]

On Wed, 2006-02-15 at 14:10 -0500, kamaraju kusumanchi wrote:
> Hi
> 
>I wanted to report a minor bug on kicker using reportbug package 
> tool. But then it forces me to read a huge number of bug titles (around 
> 647 of them) most of which were not filed against kicker. For example it 
> shows bugs against kdeprinter, kate, konsole etc., Why is this so? I 
> think it kind of discourages users who want to report to bugs against a 
> single package...

It searches for bugs on the source package, which in this case is
kdebase.  You can change this behavior with --no-query-source.  My guess
for the reason that --query-source is that quite frequently, especially
with libraries, bugs will be filed on the package in which someone has
found a bug, but the bug will also be present in other packages from the
same source.

For example, see #145786, filed on libarts1 over 3 and one-half *years*
ago (and still not fixed).  This bug is still present in libarts1c2a,
but because they are from the same source package, it can be assumed
that the maintainers know about this.


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

Re: when and why did python(-minimal) become essential?

[Jari Aalto]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> Le samedi 28 janvier 2006 à 21:19 -0600, Manoj Srivastava a écrit :
>
>> And if we followed the the line of argument you are pressing
>>  uncritically, we'd bloat essential/base with gazillions of
>>  interpreters from people too lazy or incompetent to learn the
>>  interpreters already in base.
>
> I prefer to be labeled as incompetent by people like you than to write
> scripts that no one will be able to understand later. Every time I face
> a write-once, never change perl script, the only thing to do is to
> rewrite it. And this isn't a Debian-specific issue.

Don't blame the language[1], but the people. You can as well code unbearable
code in C/C++/Mono/C# (whatever) that no-one can understand. The Perl
syntax is elegant, efficient and Python's regexp handling is nowhere
as intuitive as needed for day-to-day tasks where the poer is needed.

This is not to day that Python is bad - It has better OO, which Perl
unfortunately negletted fromt he very starts. Now, talk about Perl OO 
and that's hairy!.

Jari

[1] Example of Perl coding (do not blame the language):

# 
#
#   DESCRIPTION
#
#   Convert tokens 7m, 2h, 3d into minutes. Die if value is not numeric.
#
#   INPUT PARAMETERS
#
#   none
#
#   RETURN VALUES
#
#   none
#
# 

sub TimeValue ($)
{
my $id = "$LIB.TimeValue";

local ($ARG) = (@ARG);

if ( /^(\d+)([mhd]?)$/ )
{
$ARG = $1;
my $spec = $2  if defined $2;

$debug  and  print "$id: val [$ARG] spec [$spec]\n";

my $factor = 1;
$factor = 60if $spec =~ /h/i;
$factor = 60 *24if $spec =~ /d/i;

$ARG *= $factor;

$debug  and  print "$id: val [$ARG] factor [$factor]\n";
}
else
{
die "$id: Not a recognized time value [$ARG]. Try 2m, 2d, 2h";
}

$ARG;
}


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

Re: limitations of reportbug and BTS

[Frans Pop]

On Wednesday 15 February 2006 20:56, Marco d'Itri wrote:
> On Feb 15, kamaraju kusumanchi <[EMAIL PROTECTED]> wrote:
> > This kind of thing is not possible currently. Do you think it is a
> > good implement such a feature? Currently bugs.kde.org allows this
> > (searching for strings in the bug reports without worrying about
> > package names etc.,).
>
> You use google groups to search the linux.debian.bugs.dist newsgroup.

Maybe we should document that on the bugs.debian.org main webpage.

Any objections to the patch below (I can commit it myself)?

@@ -62,6 +62,14 @@
   http://bugs.debian.org/tag:tag
 

+Searching bug reports
+
+Probably the easiest way to search bug reports is use
+http://groups.google.com/group/linux.debian.bugs.dist";>Google 
Groups.
+If you use the
+http://groups.google.com/advanced_search?q=""+group%3Alinux.debian.bugs.dist";>
+advanced search option, you will be able to limit the period to be 
searched.
+
 Supplementary information

 The current list of http://bugs.debian.org/release-critical/";>


pgpIsbHBc4ojp.pgp
Description: PGP signature

Re: limitations of reportbug and BTS

[Frans Pop]

On Wednesday 15 February 2006 21:28, Frans Pop wrote:
> + href="http://groups.google.com/advanced_search?q=""+group%3Alinux.debian.bugs.dist";>

Hmm. Quotes within quotes probably won't work, so this is better:
http://groups.google.com/advanced_search?q=+group%3Alinux.debian.bugs.dist";>


pgpauf7fJtMxQ.pgp
Description: PGP signature

Ebay Item

[hottopfashion]

All Brands of Jeans 29.99 USD
www.charshaf.com
Dolce Gabbana, Armani, Prada etc..















if you want to opt-out from mailing list just reply and use subject "leave me 
alone"
Thanks for checking







































































Current email was sent by an Evaluation License.
Note: This footer will be removed with Licensed Version

Bug#353051: ITP: pootle -- Web-based translation and translation management tool

[Nicolas François]

Package: wnpp
Severity: wishlist
Owner: "Nicolas François" <[EMAIL PROTECTED]>


* Package name: pootle
  Version : 0.6.3.20060126
  Upstream Author : David Fraser, translate.org.za
* URL : http://sourceforge.net/projects/translate
* License : GPL
  Description : Web-based translation and translation management tool

 Pootle provides a rich set of features for managing a translation
 project.  It integrates components of the Translate Toolkit to provide
 error checkers for translation messages and the ability to download files
 in a number of formats: PO, XLIFF, CSV.  Pootle can also provide compiled
 PO files for download. You can use it to assign work to translators in
 your team, and you can define goals to help focus the efforts of your
 translation.  Pootle can run without a Web server or be proxied through
 your existing Apache server.  The Translate Toolkit is a set of software
 and documentation designed to help make the lives of localizers both more
 productive and less frustrating.
 .
 Homepage: http://translate.sourceforge.net/


Note: a pootle package existed and was recently renamed translate-toolkit.
I will (first) package 0.6.3.20060126, because it matches the current
translate-toolkit package (0.8.rc6-1).

-- 
Nekral

Processed: /usr/doc/*

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> block 322762 by 319726
Bug#322762: /usr/doc still exists (transition tracking bug)
Was blocked by: 189856 190020 203278 254800 254913 254924 254930 255590 256250 
302504 320084 320103 321926 322749 322769 322772 322775 322776 322778 322779 
322781 322782 322783 322784 322785 322786 322787 322788 322789 322790 322791 
322792 322793 322794 322795 322797 322798 322799 322800 322801 322803 322804 
322805 322806 322807 322808 322809 322810 322811 322812 322813 322814 322815 
322816 322817 322818 322819 322820 322828 322829 322830 322831 322832 322833 
322834 322835 322837 322838 322839 352893 352894
Blocking bugs added: 319726

> --
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: when and why did python(-minimal) become essential?

[Miles Bader]

Jari Aalto <[EMAIL PROTECTED]> writes:
> The Perl syntax is elegant, efficient and Python's regexp handling is
> nowhere as intuitive as needed for day-to-day tasks where the poer is
> needed.

Efficient, perhaps, but _elegant_?!?  HAhahahahah1hahah3$I17-e87

Perl is an utter mess, with a few nice bits here and there.

-miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'


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

Re: when and why did python(-minimal) become essential?

[Thomas Bushnell BSG]

Jari Aalto <[EMAIL PROTECTED]> writes:

> This is not to day that Python is bad - It has better OO, which Perl
> unfortunately negletted fromt he very starts. Now, talk about Perl OO 
> and that's hairy!.

Actually, Python *also* ignored OO at the beginning.

It has grafted it on, but since real OO is either Smalltalk or the
Metaobject Protocol, I'll have to beg off on whether C++ or Perl or
Python has "better" OO.


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

Re: Bug#352535: ITP: gitmail -- Very simple graphical mail user agent for sending mail (GTK)

[Henrique de Moraes Holschuh]

On Wed, 15 Feb 2006, Jari Aalto wrote:
> Not so fast. If the light weight system is to be kept as small as
> possible, the additional tcl/Tk libraries would not be welcomed.

You won't be able to stay away from tcl/tk for too long if you want GUIs,
but I see your point.

> GTK at least is common to most of the C programs that do not bring
> along other libraries.

No. It is common to a lot of *GUI* C programs nowadays.

> The programs talks directly to SMTP, so there is no need to require
> a MTA in the system.

There are MTAs that do little else than that, but they do it properly. And a
proper unix system needs a working /sbin/sendmail that sends mail.  A system
without a /sbin/sendmail is quite broken, a lot of stuff won't be able to
send mail notifications, etc.

So I don't buy this argument.  Reimplementing the wheel and doing it badly
is not good form, and it is an anti-unix way of life :-)

The goal (a GUI that lets the user send email) can be equally met (using GTK
even) by running sendmail to do the mail sending.

> Upstream is interested in getting the program in better shape based on
> the malloc-discussion here.

I'd *highly* suggest that he read fully all SMTP and ESMTP-related RFCs, and
make sure he understands the BNF grammar completely, and that he correctly
implements all MUST requirements.

But really, if I were writing this, I'd just write the x-based form (using
whatever toolkit I deemed best), and call /sbin/sendmail to do the ESMTP
talking.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Size matters. 7zip. Again.

[Henrique de Moraes Holschuh]

On Wed, 15 Feb 2006, Aurelien Jarno wrote:
> What about using .tar.7z files to fix those problems?

What about writing a gzip-like utility using the improved 7zip compression,
and doing that the way bzip and gzip are done (a very sane library we can
call directly from inside apps, and a command-line tool that uses the
library to implement the gzip-like interface).

Then we could really consider using .tar.7zip (or whatever) packages.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Bug#352535: ITP: gitmail -- Very simple graphical mail user agent for sending mail (GTK)

[Steve Langasek]

On Thu, Feb 16, 2006 at 12:46:30AM -0200, Henrique de Moraes Holschuh wrote:
> On Wed, 15 Feb 2006, Jari Aalto wrote:
> > Not so fast. If the light weight system is to be kept as small as
> > possible, the additional tcl/Tk libraries would not be welcomed.

> You won't be able to stay away from tcl/tk for too long if you want GUIs,

Huh?  My desktop is 100% tk-free...

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

Re: Bug#352535: ITP: gitmail -- Very simple graphical mail user agent for sending mail (GTK)

[Miles Bader]

Steve Langasek <[EMAIL PROTECTED]> writes:
>> You won't be able to stay away from tcl/tk for too long if you want GUIs,
>
> Huh?  My desktop is 100% tk-free...

Yeah, me too; I actually use that as one criterion to decide whether I
really want to install some random borderline useful utility... :-)

-Miles
-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]


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