Re: Why is procps procps.sh in init.d?
[Craig Small] > Isn't the whole point of the /etc/init.d/.sh files to setup > environment variables for subsequent init scripts. Nope. The point of .sh init.d scripts is to speed up the boot. The sourcing is not guaranteed when scripts are executed in parallel, so all scripts should work when executed in a separate process as well. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reclaiming automake
* Eric Dorland wrote: > Norbert Tretkowski <[EMAIL PROTECTED]> >lcd4linux Upstream just switched to a newer version of automake in cvs last weekend, a new upload is pending. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *-doc package should not gzip PDF file
On Sun, 2006-06-25 at 16:51 -0400, James R. Van Zandt wrote: > > I have no idea how debhelper works. Are there anybody out there that > > can help with getting it to stop gzipping files in -doc? > > dh_compress already has a list of file extensions where (re-)compressing > doesn't make sense. I've submitted Bug#375406 with a patch (below) to > add .pdf to the list. If I read the discussion correctly up to this point, some PDFs are fairly compressible and some are not. Perhaps dh_compress could evaluate this for each .pdf and only compress those files where the saving is significant (say 40%)? -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Reclaiming automake
* Artur R. Czechowski ([EMAIL PROTECTED]) wrote: > Hi Eric, > > On Sun, Jun 25, 2006 at 07:11:14PM -0400, Eric Dorland wrote: > > automake1.4: This is the old school package, that's been completely > > unsupported for a number of years (since 2002). It certainly not used > > with any new software and any software still using it should be > > migrated away from it. It is also the only package that provides > > "automake", cause there are still 73 packages by my reckoning that > > build depend on automake and expect that be automake 1.4. > Have you considered packages depending on automake1.4? > > apt-cache rdepends automake1.4 | grep "^ " | dd-list --stdin says: For the purpose of this transition these are fine. But yes, it would better if these packages could depend on something newer. > Hakan Ardo <[EMAIL PROTECTED]> >toolchain-source For some reason this depends on both automake1.4 and automake1.7. Weird. > Debian PHP Maintainers <[EMAIL PROTECTED]> >php4 >php5 php4 is fairly old, but I'm surprised php5 still uses automake 1.4. Is this really the case? > Gustavo Noronha Silva <[EMAIL PROTECTED]> >glade Glade apparently still generates 1.4 Makefile.am files. Probably easy to fix, if anyone is working on glade anymore. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Bug#375441: ITP: python-stemmer -- Python bindings for Snowball stemming algorithms
Package: wnpp Severity: wishlist Owner: Franz Pletz <[EMAIL PROTECTED]> * Package name: python-stemmer Version : 1.0.1 Upstream Author : Richard Boulton <[EMAIL PROTECTED]> * URL : http://snowball.tartarus.org/ * License : BSD, MIT Programming Lang: C, Python Description : Python bindings for Snowball stemming algorithms PyStemmer provides access to efficient algorithms for calculating a "stemmed" form of a word. This is a form with most of the common morphological endings removed; hopefully representing a common linguistic base form. This is most useful in building search engines and information retrieval software; for example, a search with stemming enabled should be able to find a document containing "cycling" given the query "cycles". PyStemmer provides algorithms for several (mainly european) languages, by wrapping the libstemmer library from the Snowball project in a Python module. It also provides access to the classic Porter stemming algorithm for english: although this has been superceded by an improved algorithm, the original algorithm may be of interest to information retrieval researchers wishing to reproduce results of earlier experiments. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reclaiming automake
Hi Eric, On Sun, Jun 25, 2006 at 07:11:14PM -0400, Eric Dorland wrote: > automake1.4: This is the old school package, that's been completely > unsupported for a number of years (since 2002). It certainly not used > with any new software and any software still using it should be > migrated away from it. It is also the only package that provides > "automake", cause there are still 73 packages by my reckoning that > build depend on automake and expect that be automake 1.4. Have you considered packages depending on automake1.4? apt-cache rdepends automake1.4 | grep "^ " | dd-list --stdin says: Hakan Ardo <[EMAIL PROTECTED]> toolchain-source Debian PHP Maintainers <[EMAIL PROTECTED]> php4 php5 Gustavo Noronha Silva <[EMAIL PROTECTED]> glade Best regards Artur -- (ac) ,< _ó_ We all live in the yellow submarine... <___> signature.asc Description: Digital signature
Re: make -j in Debian packages
On Sun, Jun 25, 2006 at 09:07:40PM +0200, Wouter Verhelst wrote: > It's not a question of legislating; it's more a question of picking a > good option and writing the specification in policy. I fully agree with Wouter on this. Although the specification doesn't necessarily have to be in policy (it could be in dev-ref or the package tools documentation). But I don't think policy is neecssarily a bad place for it either. Beyond telling us what we can and cannot do, policy helps our users understand what they can and cannot expect. I think having a standardized option here to allow "-j X" to be used if the packaging supports it is an excellent idea. If someone wanted to write up an actual proposal and post it to the policy list, well, we could at least judge the proposal on its merits, and, if it were a good proposal, I would definitely support it. But I don't actually care enough to write a proposal myself. Unless you guys want to wait until I _happen_ to find enough free time :) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Reclaiming automake
Hello everyone, Scott James Remnant dropped me an email recently, interested in improving the automake situation in Ubuntu and Debian[0]. Right now the automake packages looks like this: automake1.4: This is the old school package, that's been completely unsupported for a number of years (since 2002). It certainly not used with any new software and any software still using it should be migrated away from it. It is also the only package that provides "automake", cause there are still 73 packages[1] by my reckoning that build depend on automake and expect that be automake 1.4. automake1.7, automake1.8, automake1.9: This is the new generation of automake. While mostly compatible with each other, each new revision brings in some backwards incompatible changes. This is mostly due to automake's free form nature, and no strict API for generating makefiles. Right now, the "automake" command is set up as an alternative, and all these automake* packages provide those alternatives, with automake1.9 having the highest priority. This situation isn't ideal because users can't just install automake and get the expected latest version. So I propose the following steps to take back the automake package name: 1. Remove the automake and automaken provides from automake1.4 and take it out of the alternatives infrastructure (alternatively leave the alternatives but still removing the provides, with automake1.4 providing the lowest alternative value). Make clear in the package description and whatnot that automake 1.4 is deprecated and should only be used in highly special circumstances. 2. Start shipping an automake package again that would track the latest upstream version of automake (or be a dummy package that depended on the latest version) and give it the highest alternative priority. This will give most users the latest version (and hence have a better automake experience), while still allowing packages to depend on other versions. 3. Leave the alternatives system in place for >= 1.7 versions of automake, to give people the ability to say "No, I want my system to be version 1.X of automake, until I say otherwise" Now before I can implement this master plan, I need to fix all the packages that still build depend on "automake"[1]. To proceed with this I'd like to file wishlist bugs (with patches) against these packages one week from today. One week after that, with the Release Team's blessing, I'd like to start NMUing as much of these packages as I can. Once that is complete, I'd like to make the transition and raise the severity of any of bugs that remain. If you find your package listed in [1], the first step is to check if you actually need to be build depending against automake at all. In most cases you shouldn't. If you really do need it (ie you've modified a Makefile.am), consider running the appropriate automake in your source tree and shipping them in your .diff.gz. While bloating the .diff.gz slightly, it will lead to more predictable builds and less nagging from me when these transitions have to happen. [0] Their plan, which mirrors mine, is documented here: https://wiki.ubuntu.com/AutomakeTransition [1] Output of: grep-dctrl -ne -s Package -F Build-Depends,Build-Depends-Indep 'automake[^1n]' /var/lib/apt/lists/http.us.debian.org_debian_dists_unstable_main_source_Sources | grep -v -E 'gcc-3.3|easypg|ext2resize|freesci|gnuift|isoqlog|jack-tools|kmymoney2|oprofile' | dd-list --stdin (those packages filtered out are ones that do have automake in there build depend line, but not in a way that could lead to problems with this transition, eg automake1.9 | automake). Laszlo Boszormenyi (GCS) <[EMAIL PROTECTED]> xmms-blursk Peter De Schrijver (p2) <[EMAIL PROTECTED]> coriander Thomas Bushnell, BSG <[EMAIL PROTECTED]> oaf Michael Banck <[EMAIL PROTECTED]> irssi-plugin-icq Karl Bartel <[EMAIL PROTECTED]> black-box penguin-command Eduard Bloch <[EMAIL PROTECTED]> lufs Ed Boraas <[EMAIL PROTECTED]> aime Jeremy T. Bouse <[EMAIL PROTECTED]> fwbuilder libfwbuilder libgcgi Rob Bradford <[EMAIL PROTECTED]> anjuta Adrian Bridgett <[EMAIL PROTECTED]> gato Rune B. Broberg <[EMAIL PROTECTED]> tuxtype Eric Van Buggenhaut <[EMAIL PROTECTED]> fluidsynth Giacomo Catenazzi <[EMAIL PROTECTED]> knapster2 Debian Hamradio Maintainers ax25-apps ax25-tools libax25 Murat Demirten <[EMAIL PROTECTED]> ettercap Yann Dirson <[EMAIL PROTECTED]> dossizola Jochen Friedrich <[EMAIL PROTECTED]> net-snmp Stephen Frost <[EMAIL PROTECTED]> libpam-ldap Debian QA Group <[EMAIL PROTECTED]> kdoc Marek Habersack <[EMAIL PROTECTED]> pexts Simon Horman <[EMAIL PROTECTED]> heartbeat perdition vanessa-adt vanessa-logger vanessa-socket Mario Joussen <[EMAIL PROTECTED]> affix Takuo KITAME <[EMAIL PROTECTED]> gconf Zdenek Kabelac <[EMAIL PROTECTED]> avifile Ivan Kohler <[EMAIL PROTECTED]> libpam-unix2 Joshua Kwan <[EMAIL PROTEC
Why is procps procps.sh in init.d?
Hello, I've been looking at bug #343620 where /etc/init.d/procps.sh should not exit out. I can see why this could cause problems. However, while I can see that bug #52228 asks for procps to be sourced, I can see no good reason for doing so. Isn't the whole point of the /etc/init.d/.sh files to setup environment variables for subsequent init scripts. The procps init script sets kernel variables, when you remove all the stuff what it basically does is /sbin/sysctl -p Which sets the kernel variables found at /etc/sysctl.conf Is there any good reason keeping it like that, it appears to be it would be best to make it /etc/init.d/procps - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer csmall at : enc.com.au ieee.org debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#375410: ITP: epdfview -- Lightweight pdf viewer based on poppler libs
On Sun, 2006-06-25 at 17:05 -0400, James R. Van Zandt wrote: > So I'd expect a smaller memory footprint and faster startup. What > would I be losing? The ability to drag a PDF file and drop it on the > application's icon on the desktop? Printer integration? Gnome style > documentation? I don't use gnome so I can't tell you, and epdfview can't print for the moment. -- Yves-Alexis Perez -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#375410: ITP: epdfview -- Lightweight pdf viewer based on poppler libs
Yves-Alexis Perez <[EMAIL PROTECTED]> wrote: > epdfview is a pdf viewer based on poppler libs, like evince but without > all gnome libs dependencies, it only uses gtk libs. So I'd expect a smaller memory footprint and faster startup. What would I be losing? The ability to drag a PDF file and drop it on the application's icon on the desktop? Printer integration? Gnome style documentation? I like evince, but maybe I'd be just as well off with epdfview. I use Enlightenment, and am not sure what I'm missing when I use a Gnome program without the Gnome desktop. - Jim Van Zandt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375412: ITP: vdr-plugin-dxr3 -- Plugin to vdr to use a DXR3/Hollywood+ MPEG decoder as primary interface
Package: wnpp Severity: wishlist Owner: Nicolas Boullis <[EMAIL PROTECTED]> * Package name: vdr-plugin-dxr3 Version : 0.2.6 Upstream Author : Kai Moeller <[EMAIL PROTECTED]>, Stefan Schluenss <[EMAIL PROTECTED]>, Christian Gmeiner , ...and numerous others, see CONTRIBUTORS. * URL : http://sourceforge.net/projects/dxr3plugin/ * License : GPL Programming Lang: C++ Description : Plugin to vdr to use a DXR3/Hollywood+ MPEG decoder as primary interface This plugin for vdr allows using a DXR3/Hollywood+ MPEG decoder card as primary interface. This package will be maintained within the "Debian VDR Team <[EMAIL PROTECTED]>". -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental'), (500, 'stable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.1-irma 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: *-doc package should not gzip PDF file
Preben Randhol <[EMAIL PROTECTED]> wrote: > Osamu Aoki <[EMAIL PROTECTED]> wrote: > > If anyone wants this to be fixed following should happen. > > > > * Write a patch to the debhelper gzip text/pdf/ps file logic > >- do not compress if the package is *-doc and file extension is > > pdf. > I have no idea how debhelper works. Are there anybody out there that > can help with getting it to stop gzipping files in -doc? dh_compress already has a list of file extensions where (re-)compressing doesn't make sense. I've submitted Bug#375406 with a patch (below) to add .pdf to the list. - Jim Van Zandt --- dh_compress-orig2006-06-25 15:37:11.0 -0400 +++ dh_compress 2006-06-25 15:39:08.0 -0400 @@ -102,6 +102,7 @@ ! -iname "*.tgz" ! -iname "*.z" ! -iname "*.bz2" \\ ! -iname "*-gz" ! -iname "*-z" ! -iname "*_z" \\ ! -iname "*.jar" ! -iname "*.zip" ! -iname "*.css" \\ + ! -iname "*.pdf" \\ ! -name "copyright" 2>/dev/null || true; find usr/X11R6/lib/X11/fonts usr/share/fonts/X11 -type f -name "*.pcf" 2>/dev/null || true; -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375410: ITP: epdfview -- Lightweight pdf viewer based on poppler libs
Package: wnpp Severity: wishlist Owner: "Yves-Alexis Perez" <[EMAIL PROTECTED]> * Package name: epdfview Version : 0.1.5 Upstream Author : Jordi Fita <[EMAIL PROTECTED]> * URL : http://www.emma-soft.com/projects/epdfview/ * License : GPLv2 Programming Lang: C++ Description : Lightweight pdf viewer based on poppler libs epdfview is a pdf viewer based on poppler libs, like evince but without all gnome libs dependencies, it only uses gtk libs. -- As a side note, the package currently built requires libpoppler 0.5 which is only in experimental, so it'll take some time before the package appears in unstable. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.1 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: Bug#374997: ITP: utf8-migration-tool -- tool to migrate a Debian system to UTF-8
(I forgot to Cc: d-d in my first reply) On Fri, Jun 23, 2006 at 01:12:23AM +0300, Martin-Éric Racine wrote: [...] > > > I would gladly welcome co-maintainance with Debian's i10n/i18n team. > > > > What are his benefits over convmv? > > convmv is good at doing recursive batch conversions from command line. > > utf8-migration-tool is good at inspecting and reporting the encoding, > and it operates as a user-friendly GUI druid written in PyGTK. > > The telling takes longer than the showing, so I invite interested > parties to simply try it. The package is arch:all and available in my > personal repository (source+binary). I would love to, but as you can see from this snapshot, this program is not usable with a white on black theme. Can you please fix it? Denis umt.png Description: PNG image
Re: make -j in Debian packages
On Sun, Jun 25, 2006 at 06:11:24PM +0300, Lars Wirzenius wrote: > su, 2006-06-25 kello 16:36 +0200, Wouter Verhelst kirjoitti: > > It has come to my attention that the gem package is currently built > > using 'make -j 4', to have four compiler processes running at the same > > time. This is a bit troublesome for the poor m68k buildd, which is now > > suffering under High Load And Constant Swapping (HLACS). [...] > I doubt we need a policy change for this. At some point, we need to stop > legislating and start assuming the package maintainers have common > sense. It's not a question of legislating; it's more a question of picking a good option and writing the specification in policy. I would actually like to be able to specify 'make -jX' instead of just 'make' in a build. Currently, that's not possible. The absence of common sense in this particular example is what sparked this suggestion, it is not what I'm trying to avoid in the future (though that is, of course, an interesting byproduct -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
On Sun, Jun 25, 2006, Lars Wirzenius wrote: > Sure, even on a single CPU -jX (X > 1) can be faster, but it depends on > various factors, such as available memory, and other load on the > machine. Using -j is not something that should be on by default, but it > would be *really* nice if it were easy to turn on, for any package. Same > with other compilation options, as it happens. Maybe through USE flags? (*ducks*) -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possibility to get a OLPC developer's board [Reply-to: debian-custom-list]
El dom, 25-06-2006 a las 19:10 +0200, Knut Yrvin escribió: > First of all I'm sorry to cross-post this request. But I need urgent > reply to know if somebody wants to team up in a project making Debian > ready for the One Laptop per Child hardware. If there is somebody > interested applying for OLPC developer board to make things work, > please reply to [EMAIL PROTECTED] > > My project proposal: > > After a tip from Walter Bender at MIT, I was subscribing to the > devel-boards list for the One Laptop per Child project. Walter is > president, software and content, of the One Laptop per Child > foundation. > > My subscription was forwarded to the list moderator for approval. Then > i got a nice e-mail from Jim Gettys. He wrote that if my interest in > the list is to get a developer's board, then please follow the > following instructions (look at the bootom): > > http://wiki.laptop.org/index.php/Developers_Program > > This will result in a developer's board if the request is at all > reasonable, and you will be added to the mailing list (which is meant > to be low volume announcements for people with boards). > > I wrote some suggestions for a plan to get the OLPC-machine up running > April 5th 2006: > > http://lists.debian.org/debian-edu/2006/04/msg00016.html > > So people, I could apply for boards to realize this plan. (The plan is > not at all finale, but a suggestion): > > 1. To make the Debian installer work with OLPC-machines > 2. To make bare bone Debian run with network connectivety in a mesh >network (IPv6) > 3. Make the power management work > 4. To make X and a window manager with simplified debloated desktop > > But with no developers interested doing the development, I see no > reason for applying for boards. So it depends on what the Debian Edu > and Debian contributers are interested in. > > It's a considerable job tailoring the different subsystem in Debian to > OLPC hardware. The installer has to be tailored, the network mesh net > support has to work, simplified debloated desktop has to be configured, > and the power management has to work. > > We have done interesting things with Custom Debian Distributions and > Debian Installer in the Skolelinux / Debian Edu environment before. It > seems to me that more people have joined the Skolelinux / Debian Edu > project. I believe the One Laptop per Child is important for Debian, > and we should do this development. > > - What do you think about this suggestions? > > - Who are interested to develop tailored Debian Edu for > OLPC-machines? > Hi, Knut At LinEx we have interest in this project, next Friday I'll have a meeting with Jim Getty and will get more information to know if it makes sense for us to work on it. I think we could collaborate in points 1 & 4, as we have experience in working with installers, and we have begun the project Futura[1][2] thinking in the obsolescence of the computers we have at our schools. Even if our hardware requirements are still far from the OLPC machines, I think the same developments could apply pretty easily. Regards, José L. Redrejo [1] http://guadec.org/node/420 [2] http://forjamari.linex.org/docman/view.php/54/37/futura.pdf signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: make -j in Debian packages
su, 2006-06-25 kello 10:41 -0700, Tyler MacDonald kirjoitti: > kernel-package uses the CONCURRENCY_LEVEL envrionment variable for > this. And if I do a "CONCURRENCY_LEVEL=4" on my single-CPU system, it does > actually go quite a bit faster. :) Sure, even on a single CPU -jX (X > 1) can be faster, but it depends on various factors, such as available memory, and other load on the machine. Using -j is not something that should be on by default, but it would be *really* nice if it were easy to turn on, for any package. Same with other compilation options, as it happens. -- Yet another quit message no-one will ever comment on. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
On Sun, Jun 25, 2006 at 06:51:31PM +0200, Petter Reinholdtsen wrote: > [Lars Wirzenius] > > As far as I can see, using make's -j option is only useful if you > > have multiple processors. Packages should not make such assumptions > > of the build environment. > Actually, I've seem speedup with -j2 on a single CPU machine. I > suspect one process is compiling while the other fetches the source > from disk. :) Yes, I've seen similar behaviour as well, not only with make/compiler. Overloading can speed up things for rendering processes as well, depending on the arch. But that's not the point here. Although gem was using 4 parallel makes, the buildd performed quite well, but this was just luck. If the source file would've been bigger in size, it would have been bad for the buildd. However, not all buildds have 128M or more memory. For example the armeb buildds only have 32M and Joey said something that the (or some) arm buildds are just having 64M w/o swap. So, finding a solution for this "problem" would be nice. When you have more core/CPUs you may want to make use of these, but it should be configurable by the buildd admin, if it's ok for a package to use multiple instances of the compiler. So, some sort of an environmental variable needs to be set, I think. The package could then check for this variable and when it is known to build without any problems using -jX, it can go right away doing so. Otherwise it should use -j1 (or no -j option at all). When a policy change is needed, I think it would be worthwhile to think of allowing crosscompiler builds as well. When there would be a way to use distcc on slower archs to crosscompile large packages, it would make many people happy, I think. ;) But of course the very first question is: is it wanted that there's something like that in the future or not? If yes, then let a group of porters, policy people and such decide how this can be achieved in the best way and let them make a proposal after some time. Porters are needed because they will have to deal with those issues when a build fails because of this. Policy people, because they need to write it down. DAK people, because they need to implement the needed changes, etc... -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
Lars Wirzenius <[EMAIL PROTECTED]> wrote: > > It has come to my attention that the gem package is currently built > > using 'make -j 4', to have four compiler processes running at the same > > time. This is a bit troublesome for the poor m68k buildd, which is now > > suffering under High Load And Constant Swapping (HLACS). > As far as I can see, using make's -j option is only useful if you have > multiple processors. Packages should not make such assumptions of the > build environment. > > If package maintainer wants to build it faster on their own machine, I > would imagine that checking for an environment variable (DEB_MAKE_OPTS > or something, perhaps?) and using that would be the way to go. By > default, build with a single processor. kernel-package uses the CONCURRENCY_LEVEL envrionment variable for this. And if I do a "CONCURRENCY_LEVEL=4" on my single-CPU system, it does actually go quite a bit faster. :) - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
On Sun, 2006-06-25 at 16:56 +0200, Bastian Blank wrote: > DoS against the buildd? > There is none. But you may consider it as an attack against the > infrastructure. You on the other hand, might consider that developers might not have the malicious intent you infer, but perhaps just made an honest mistake. Thijs signature.asc Description: This is a digitally signed message part
Re: make -j in Debian packages
Am Sonntag, den 25.06.2006, 18:11 +0300 schrieb Lars Wirzenius: > I doubt we need a policy change for this. At some point, we need to stop > legislating and start assuming the package maintainers have common > sense. Agreed. However, it might be a good idea to have *one* canonical variable name for that; perhaps dev-ref is a better place for this than policy. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Possibility to get a OLPC developer's board [Reply-to: debian-custom-list]
First of all I'm sorry to cross-post this request. But I need urgent reply to know if somebody wants to team up in a project making Debian ready for the One Laptop per Child hardware. If there is somebody interested applying for OLPC developer board to make things work, please reply to [EMAIL PROTECTED] My project proposal: After a tip from Walter Bender at MIT, I was subscribing to the devel-boards list for the One Laptop per Child project. Walter is president, software and content, of the One Laptop per Child foundation. My subscription was forwarded to the list moderator for approval. Then i got a nice e-mail from Jim Gettys. He wrote that if my interest in the list is to get a developer's board, then please follow the following instructions (look at the bootom): http://wiki.laptop.org/index.php/Developers_Program This will result in a developer's board if the request is at all reasonable, and you will be added to the mailing list (which is meant to be low volume announcements for people with boards). I wrote some suggestions for a plan to get the OLPC-machine up running April 5th 2006: http://lists.debian.org/debian-edu/2006/04/msg00016.html So people, I could apply for boards to realize this plan. (The plan is not at all finale, but a suggestion): 1. To make the Debian installer work with OLPC-machines 2. To make bare bone Debian run with network connectivety in a mesh network (IPv6) 3. Make the power management work 4. To make X and a window manager with simplified debloated desktop But with no developers interested doing the development, I see no reason for applying for boards. So it depends on what the Debian Edu and Debian contributers are interested in. It's a considerable job tailoring the different subsystem in Debian to OLPC hardware. The installer has to be tailored, the network mesh net support has to work, simplified debloated desktop has to be configured, and the power management has to work. We have done interesting things with Custom Debian Distributions and Debian Installer in the Skolelinux / Debian Edu environment before. It seems to me that more people have joined the Skolelinux / Debian Edu project. I believe the One Laptop per Child is important for Debian, and we should do this development. - What do you think about this suggestions? - Who are interested to develop tailored Debian Edu for OLPC-machines? Regards Knut Yrvin Project manager Skolelinux Norway -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
[Lars Wirzenius] > As far as I can see, using make's -j option is only useful if you > have multiple processors. Packages should not make such assumptions > of the build environment. Actually, I've seem speedup with -j2 on a single CPU machine. I suspect one process is compiling while the other fetches the source from disk. :) Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debtags and Flamenco
Hello, As Erich Schubert pointed out: http://lists.alioth.debian.org/pipermail/debtags-devel/2006-June/001255.html Flamenco: http://flamenco.berkeley.edu is now free software: http://flamenco.berkeley.edu/download.html Flamenco is a "faceted metadata interface from SIMS, UC Berkeley. [...] Its a cool system, the interface is somewhat busy, but it supports more complex information finding tasks very well". This is a demo: http://orange.sims.berkeley.edu/cgi-bin/flamenco.cgi/famuseum/Flamenco Now, debtags happens to be faceted metadata, and it would be cool if someone were to setup flamenco to give a view of Debian packages using debtags. Would someone want to pickup the task? I can help with providing the debtags data digested in all sort of formats. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: additions to dpkg-architecture
On Sun, Jun 25, 2006 at 10:27:37PM +1000, Brendan O'Dea wrote: > On Fri, Jun 23, 2006 at 06:54:49PM +0200, Volker Grabsch wrote: > >I propose to add more CPU types to dpkg-architecture. In particular, > >I'd like to see the different i386 architectures there, i.e. > >i586, i686, k6, ... > [...] > >For instance, some programs with lots of calculations (e.g. mplayer) > >are compiled with different processor optimizations (e.g. mplayer-i586). > >Such packages are created by very redundant entries in debian/rules. > >Exactly such redundancy is removed by dpkg-cross. > > While there are certainly some packages which may benefit from > compilation with sub-architecture optimisations, those packages are the > exception rather than the norm. This is a good reason for Debian not to supply more optimized packages, but this has nothing to do with my proposal. > It may make sense to provide multiple versions of the kernel for > example, and perhaps glibc... but coreutils? grep? I don't understand what you try to explain here. I didn't propose the Debian should provide multiple optimized versions of more packages. Please don't mix the DPKG tools with the Debian distribution. For the same reason APT facilitates inofficial repositories, dpkg should facilitate their creation. > Do you propose re-building all packages for each sub-arch? No, that's not my task, and it also shouldn't be the task of the Debian project. I just want the "dpkg" tools to open the way for those who want to do that, instead of stepping in their way. If "dpkg" had some more architectures in the past, I'm sure we'd have more optimized (inofficial) APT repositories in the net. > If so, [...] > If only a sub-set, [...] I don't want Debian to re-build any of their packages for those new sub-archs. I just want Debian, more precisely: DPKG, to supply a naming scheme where everyone finds a place: The officially supported Debian architectures as well as those which are only interesting for a minority. Because adding architectures to dpkg will be done by those who need it, and because it's very easy, I don't think there's any problem with the cost vs. benefit. The cost are minimal, and there's a reasonably big minority who will greatly benefit. IMHO, it is just a question of courtesy: Not to step others in their way. I'm sure the Debian-embedded and other cross compiling folks are glad to maintain such a scheme, as they are the ones who usually work with many architectures and thus have the motivation and the necessary background knowledge. This is at least my impression of them. > how are you intending to change dpkg, apt and/or the > archive software to handle opportunistic installation of sub-arch > packages with fallback (i.e. try foo.i686, fallback to foo.i386)? I don't intend to change dpkg in this way, I just thought this would be a very dersirable feature for the future. As I stated in my proposal with various examples, the addition of more architectures would have big benefits anyway. However, if one day the kludge with optimized packages etc. should be solved cleanly, I would like to have it in that way: The APT configuration contains an architecture priority list, such as: i686,i585,i486,i386 The first entry is the best suited, the last one the least suited. When doing APT-update, APT knows what packages are avaiable in what architectures. It then simply takes the one which is the best suited one according to the list. To make it more user friendly, there should be prepared lists for each architecture, e.g.: i386 -> i386 i486 -> i486,i386 i586 -> i586,i486,i386 i686 -> i686,i586,i486,i386 Thus, the user just has to choose his own architecture and the rest is taken from the tables. While this approach is AFAICS the most flexible one, probably a simpler structure solves the needs, too. Instead of having a list for each platform, maybe it's suitable to just store the predecessor, e.g.: i386 -> i486 -> i386 i586 -> i486 i686 -> i586 In all cases, this structure should be only used to determine a default, so the user has the last word about his list of architectures. Maybe he want's to cut the list to e.g. "i686,i586" to guarantee a minimum optimization level for all packages. Or maybe his hardware is not fully backwards compatible, e.g. his i686 processor has problems with i486 optimized code, so he would use "i686,i585,i386". Okay, my examples are not that good. I just wanted to state that the user should still have the last word for the architecture priority list. Does this answer your question? I'm not sure I got you right, because all I wrote here seems obvious to me. Greets, Volker -- Volker Grabsch ---<<(())>>--- Administrator NotJustHosting GbR -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
On Sun, Jun 25, 2006 at 05:07:16PM +0200, Turbo Fredriksson wrote: > When the talk about the hijacking of Bacula was up, the consensus was > 'who cares about the m68k? If they can't keep up, get more machines'. You can also get the same from the other arches if you prefer. Bastian -- There are certain things men must do to remain men. -- Kirk, "The Ultimate Computer", stardate 4929.4 signature.asc Description: Digital signature
Re: make -j in Debian packages
Quoting Wouter Verhelst <[EMAIL PROTECTED]>: > Since most packages currently > do not do this, some of our infrastructure (in casu, buildd machines) > assume this is not being done. Doing it anyway then might upset those > machines -- not just on m68k; when there was talk of a 6-way SPARC > buildd machine being set up, I understand that the plan there was to run > multiple instances of the buildd software on that machine, rather than > having parallel builds run[1]. Having five or six build processes all do > 'make -j 4' might grind even the most powerful of machines to a halt. [overly nagging] When the talk about the hijacking of Bacula was up, the consensus was 'who cares about the m68k? If they can't keep up, get more machines'. I didn't like it then, and I don't like it any more now... And i don't even HAVE a m68k machine any more! -- spy Delta Force Kennedy cryptographic Marxist Serbian critical arrangements 747 quiche supercomputer SDI PLO Ortega AK-47 [See http://www.aclu.org/echelonwatch/index.html for more about this] [Or http://www.europarl.eu.int/tempcom/echelon/pdf/rapport_echelon_en.pdf] If neither of these works, try http://www.aclu.org and search for echelon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
su, 2006-06-25 kello 16:36 +0200, Wouter Verhelst kirjoitti: > It has come to my attention that the gem package is currently built > using 'make -j 4', to have four compiler processes running at the same > time. This is a bit troublesome for the poor m68k buildd, which is now > suffering under High Load And Constant Swapping (HLACS). As far as I can see, using make's -j option is only useful if you have multiple processors. Packages should not make such assumptions of the build environment. If package maintainer wants to build it faster on their own machine, I would imagine that checking for an environment variable (DEB_MAKE_OPTS or something, perhaps?) and using that would be the way to go. By default, build with a single processor. I doubt we need a policy change for this. At some point, we need to stop legislating and start assuming the package maintainers have common sense. -- Happiness is going NIH on your own stuff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375362: ITP: xdg-utils -- Desktop integration utilities from freedesktop.org
Package: wnpp Severity: wishlist Owner: Per Olofsson <[EMAIL PROTECTED]> * Package name: xdg-utils Version : 1.0beta1 Upstream Author : Portland Project <[EMAIL PROTECTED]> * URL : http://portland.freedesktop.org/ * License : MIT Programming Lang: Shell Description : Desktop integration utilities from freedesktop.org xdg-utils contains utilities for integrating applications with the desktop environment, regardless of which desktop environment is used. . The following utilities are included: . * xdg-menu - Place a menu into the users menu structure * xdg-mime - Gather mime information about a file * xdg-open - Open a URL in the user's preferred application that handles the respective URL or file type * xdg-email - Open the users preferred email client, potentially with subject and other info filled in * xdg-copy - Copy one URI to another * xdg-su - Run a command as a different (usually root) user * xdg-screensaver - Enable, disable, or suspend the screensaver -- 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-2-686 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- Pelle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
On Sun, Jun 25, 2006 at 04:36:08PM +0200, Wouter Verhelst wrote: > It has come to my attention that the gem package is currently built > using 'make -j 4', to have four compiler processes running at the same > time. This is a bit troublesome for the poor m68k buildd, which is now > suffering under High Load And Constant Swapping (HLACS). DoS against the buildd? > I was going to file a flaming bug of severity 'serious', quoting the > relevant paragraph from Policy which forbids such behaviour, except it's > not there. Well, at least I can't find it... There is none. But you may consider it as an attack against the infrastructure. Bastian -- There is an order of things in this universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1 signature.asc Description: Digital signature
make -j in Debian packages
Hi, It has come to my attention that the gem package is currently built using 'make -j 4', to have four compiler processes running at the same time. This is a bit troublesome for the poor m68k buildd, which is now suffering under High Load And Constant Swapping (HLACS). I was going to file a flaming bug of severity 'serious', quoting the relevant paragraph from Policy which forbids such behaviour, except it's not there. Well, at least I can't find it... So, my question is whether people think this sort of behaviour for a package's debian/rules file is acceptable. Since most packages currently do not do this, some of our infrastructure (in casu, buildd machines) assume this is not being done. Doing it anyway then might upset those machines -- not just on m68k; when there was talk of a 6-way SPARC buildd machine being set up, I understand that the plan there was to run multiple instances of the buildd software on that machine, rather than having parallel builds run[1]. Having five or six build processes all do 'make -j 4' might grind even the most powerful of machines to a halt. OTOH, I understand that maintainers with machines containing two dual-core processors would prefer compiling their 300M worth of C++ files with the use of more than one of their processors. So there's a bit of a dilemma here. Personally, I understand the issue. In fact, in my upcoming version of belpic, I have some code in debian/rules which checks whether the hostname of the machine happens to be 'rock.grep.be' and if so, compiles the build with '-j3', since rock is in fact an SMP system. However, this type of approach is a bit brute-force, and not at all elegant. In light of that, I'm thinking that it might be interesting if a rules file were to check for the presence of a variable called DEB_PARALLEL_MAX or so and, if set, use that as the value to the '-j' option to make, but that it not specify any -j option (or similar) if the variable is not set. Thoughts? [1] I don't know whether it was eventually set up, and if so, indeed in this fashion, but this is besides the point. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 signature.asc Description: Digital signature
Re: Why does doc packages need to contain gzipped files?
#include * Martin Wuertele [Sun, Jun 25 2006, 12:30:31PM]: > * Eduard Bloch <[EMAIL PROTECTED]> [2006-06-25 12:06]: > > > #include > > * Martin Wuertele [Sun, Jun 25 2006, 11:05:54AM]: > > > > > > then it is incorrect?" "If Debian does not use RedHat Kickstart then it > > > > is broken?" > > > > > > Do you have some arguements beside the rant? firefox definitely should > > > handle .txt.gz and other gzipped plaintext documentation. I'm not > > > > Should: maybe, depends on users and webmasters preferences. > > Must: not. > > And what has this to do with local use (TOPIC)? > > The complain was that e.g. firefox does not handle gzipped documents As said... stay on topic or change the subject. This discussion is not just about using a lone program (Firefox) which is usualy used in client/server scenarios but about any program. > would solve the PDF problem. My second point is that firefox and co > should at least handle gzip compressed plaintext and one-file-html > documents and in my experience (at least firefox from backports) does so > without flaws. Having a feature is one thing, deciding where to apply it is another one. It should orient on user wish or webmasters wish and not just follow the stupid "if that is type foo with .gz extension then I want to gunzip it and reconsider the type then" scheme. Of course this behaviour is most often the desired one but it should only happen when explicitely requested by the webmaster. And there are AFAIK means to declare such flags in HTTP answers. And the user should have the choice of interpretation kind when opening a such .gz compressed file, which is usualy not offered by Firefox on offline documents. The whole thing about compressed files is just too inconsistent to make any statements covering all use of compression or all programs. Instead, the applications should offer a preprocessing option along with the file type view options where the user can decide what to do with the data... interpret it as gzipped stream of uncompress and pass to the final viewer. But all that is out of scope here. The question is: should we compress files in the doc package or not? I don't like it unless the majority of available viewers does support transparent decompression (by transparent I mean something not bothering the user with the problems mentioned above in the daily use cases) especially when the documentaiton is being read often enough to become PITA because of decompression requirement. > > > On my portable I have ~4.6K gzipped files in /usr/share/doc and only 39 > > > of them are pdfs, 4 are html files. > > > > TOPIC? That is not about all the obligatory docs (which shall be > > compressed since rarely used) but contents of -doc packages. > > Still I personally prefere -doc packages that consist of plaintext > documentation to remain compressed. Why? Manpages - ok, info files - ok, .ps files... maybe ok, gv does manage that. But PDF? TXT? (and don't say lessopen, $user has to figure out how to install it first), XML? ... And again, before you answer with the wrong stuff in mind: I talk about DOCUMENTATION packages. Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does doc packages need to contain gzipped files?
On Sun, Jun 25, 2006 at 12:20:28PM +0200, Martin Wuertele wrote: > * Osamu Aoki <[EMAIL PROTECTED]> [2006-06-25 12:09]: > pdftk handels both uncompress and compress (see > http://lists.debian.org/debian-devel/2006/05/msg01440.html). I overlooked this discussion started by. http://lists.debian.org/debian-devel/2006/05/msg01434.html This had all the facts. Interesting. I must have missed nthis one. > > I understand your point here. We should not rush this nor unzipping > > should be default even in the future for changelog etc. > > > > Step should be: > > > > 1. No more *.pdf.gz file. (That is now) > > agreed Now that I know files which was compressible by gzip had good cmpression already inside PDF, I am leaning toward publishing PDF without gzipping even now. Thanks. Just to rehash facts, 228023 fhs-2.3.pdf.gz 510762 fhs-2.3.pdf 2883196 fhs-2.3.uncompr.pdf 529987 fhs-2.3.recompr.pdf 798976 reference.en.pdf.gz 1239893 reference.en.pdf 2759682 reference.uncompress.en.pdf 1261303 reference.recompress.en.pdf pdftk can not be used to further compress existing pdf files in the archive internally. They are well compressed. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: additions to dpkg-architecture
On Fri, Jun 23, 2006 at 06:54:49PM +0200, Volker Grabsch wrote: >I propose to add more CPU types to dpkg-architecture. In particular, >I'd like to see the different i386 architectures there, i.e. >i586, i686, k6, ... [...] >For instance, some programs with lots of calculations (e.g. mplayer) >are compiled with different processor optimizations (e.g. mplayer-i586). >Such packages are created by very redundant entries in debian/rules. >Exactly such redundancy is removed by dpkg-cross. While there are certainly some packages which may benefit from compilation with sub-architecture optimisations, those packages are the exception rather than the norm. It may make sense to provide multiple versions of the kernel for example, and perhaps glibc... but coreutils? grep? Do you propose re-building all packages for each sub-arch? If so, please consider the resulting increace in archive size and impact on mirrors. If only a sub-set, how are you intending to change dpkg, apt and/or the archive software to handle opportunistic installation of sub-arch packages with fallback (i.e. try foo.i686, fallback to foo.i386)? --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Tests on fhs-2.3.pdf.gz
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Osamu Aoki wrote: > Hi, > > On Sat, Jun 24, 2006 at 05:30:59PM +0200, Mario 'BitKoenig' Holbe wrote: >> Preben Randhol <[EMAIL PROTECTED]> wrote: >>> My point is that if I choose to install a doc packages I intend to use >>> it frequently and would therefore like that it is user friendly rather >>> than that one has squeezed some few kilobytes out by gzipping files. If >> Agreed. Particularly since the saving isn't sooo big at all. >> On my - of course, not representative - workstation an uncompressed >> doc/ tree takes only about a third more space (and this includes all >> the ChangeLogs, READMEs etc. shipped with each package). >> >> [EMAIL PROTECTED]:~# du -sh /usr/share/doc >> 839M/usr/share/doc >> [EMAIL PROTECTED]:~# cp -ia /usr/share/doc /var/tmp >> [EMAIL PROTECTED]:~# cd /var/tmp/doc >> [EMAIL PROTECTED]:/var/tmp/doc# find . -type f -name \*.gz -print0 | xargs >> -0 gzip -d >> gzip: ./kernel-package/Rationale already exists;not overwritten >> gzip: ./kernel-package/HOWTO-Linux-2.6-Woody already exists;not >> overwritten >> gzip: ./gcc-4.1-base/.changelog.Debian.gz has 1 other link -- unchanged >> gzip: ./gcc-4.1-base/changelog.Debian.gz has 1 other link -- unchanged >> [EMAIL PROTECTED]:/var/tmp/doc# du -sh . >> 1,3G. >> [EMAIL PROTECTED]:/var/tmp/doc# > > Interesting stat. Let me follow-up. On my system "du -sh ." returned: > total/usr2.4G > compressed /usr/share/doc 239M > uncompressed /usr/share/doc 435M > > Although it looks like 40% saving in space, its overall impact is less > than 10% shrink in size. > [snip] > > Since dh_compress does compression (except the copyright file, .html and > .css files, and files that appear to be already compressed based on > their extensions) per its manpage, why not treat PDF as "compressed" > which I thought is the case. In this sense, we do not need policy > change. Just minor change in code to realize what dh_compress claim to > do. > > It is very slow to open over 1MB size PDF file even on a system with > proper auto-ungzipping. So aside from pedantic policy argument, we > should uncompress PDF. > > Osamu > > PS: I did not feel like using -X option now because debhelper default > should be desired behaviour. But I may change my mind soon. > > Reference: > [EMAIL PROTECTED]:/var/tmp2# find . -type f -name \*.pdf.gz -print0 | xargs > -0 gzip -l > compresseduncompressed ratio uncompressed_name > 228023 510762 55.4% ./debian-policy/fhs/fhs-2.3.pdf > 486418 682351 28.7% ./debian-policy/policy.pdf > 318890 456439 30.1% ./debian/FAQ/debian-faq.en.pdf > 124536 155443 19.9% > ./shared-mime-info/shared-mime-info-spec.pdf > 798976 1239893 35.6% > ./Debian/reference/reference.en.pdf > 692308 1063782 34.9% > ./Debian/reference/reference.de.pdf > 808949 1245798 35.1% > ./Debian/reference/reference.es.pdf [snip] > 168530 181283 7.1% ./fcitx/fcitx3.pdf > 2346394 3590496 34.7% ./ddd-doc/ddd.pdf > 145928 250564 41.8% ./ddd-doc/ddd-themes.pdf > 790846 1166650 32.2% > ./harden-doc/securing-debian-howto.de.pdf > 730825 1093197 33.2% > ./harden-doc/securing-debian-howto.en.pdf > 758996 1109269 31.6% > ./harden-doc/securing-debian-howto.fr.pdf >5013658667439000 25.7% (totals) Thanks to Martin Wuertle for pointing out the pdftk package! I took the highly compressible fhs-2.3.pdf and ran a few tests. No commentary, just numbers here: $ dir fhs-2.3.pdf.gz - -rw-r--r-- 1 me me 228023 2006-06-25 06:14 fhs-2.3.pdf.gz $ gunzip -v fhs-2.3.pdf.gz fhs-2.3.pdf.gz: 55.4% -- replaced with fhs-2.3.pdf $ dir fhs-2.3.pdf* - -rw-r--r-- 1 me me 510762 2006-06-25 06:14 fhs-2.3.pdf $ pdftk fhs-2.3.pdf output fhs-2.3.uncompr.pdf uncompress $ dir fhs-2.3*.pdf* - -rw-r--r-- 1 me me 510762 2006-06-25 06:14 fhs-2.3.pdf - -rw-r--r-- 1 me me 2883196 2006-06-25 06:16 fhs-2.3.uncompr.pdf $ gzip -v fhs-2.3.uncompr.pdf fhs-2.3.uncompr.pdf: 88.7% -- replaced with fhs-2.3.uncompr.pdf.gz [EMAIL PROTECTED]:~$ dir fhs-2.3*.pdf* - -rw-r--r-- 1 me me 510762 2006-06-25 06:14 fhs-2.3.pdf - -rw-r--r-- 1 me me 324732 2006-06-25 06:16 fhs-2.3.uncompr.pdf.gz - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEnnLgS9HxQb37XmcRAtEBAJwNmpSRDR5K6sJkcg17V5D7
Re: Why does doc packages need to contain gzipped files?
* Eduard Bloch <[EMAIL PROTECTED]> [2006-06-25 12:06]: > #include > * Martin Wuertele [Sun, Jun 25 2006, 11:05:54AM]: > > > > then it is incorrect?" "If Debian does not use RedHat Kickstart then it > > > is broken?" > > > > Do you have some arguements beside the rant? firefox definitely should > > handle .txt.gz and other gzipped plaintext documentation. I'm not > > Should: maybe, depends on users and webmasters preferences. > Must: not. > And what has this to do with local use (TOPIC)? The complain was that e.g. firefox does not handle gzipped documents well and therefore -doc packages should not contain them. I agree that it doesn't make sense to compress PDFs with gzip when there is already built-in compression that could be used and pdftk is in place to tell you if the file is already compressed (no need to do anything) or not (use pdftk to compress it) - something like that added to debhelper would solve the PDF problem. My second point is that firefox and co should at least handle gzip compressed plaintext and one-file-html documents and in my experience (at least firefox from backports) does so without flaws. > > On my portable I have ~4.6K gzipped files in /usr/share/doc and only 39 > > of them are pdfs, 4 are html files. > > TOPIC? That is not about all the obligatory docs (which shall be > compressed since rarely used) but contents of -doc packages. Still I personally prefere -doc packages that consist of plaintext documentation to remain compressed. > And besides of that, compression does not make sense on most PDFs as > pointed out by yuo/me/many others and the remaining PDFs have good > chances to recompressed internally. And again: I'm here with you, pdf.gz does not make sense. Propably using the built-in compression might. yours Martin -- <[EMAIL PROTECTED]> Debian GNU/Linux - The Universal Operating System ach, und etc/hosts will ich auch noch sehen und die etc/nsswitch und die resolv.conf wenn wir schon dabei sind (und wenn du nicht weitertust, dann wird es immer mehr, bis ein image vom ganzen rechner auf paste.debian.net liegt) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does doc packages need to contain gzipped files?
* Osamu Aoki <[EMAIL PROTECTED]> [2006-06-25 12:09]: > Is there any external tool to convert PDF with better internal > compression? I want to see ome PDF make file to use it to improve their > PDF. Some PDF can still be compressed 50%, as I posted, which is bad. pdftk handels both uncompress and compress (see http://lists.debian.org/debian-devel/2006/05/msg01440.html). > I understand your point here. We should not rush this nor unzipping > should be default even in the future for changelog etc. > > Step should be: > > 1. No more *.pdf.gz file. (That is now) agreed > 2. Wait for smart dpkg which can do smart thing upon unpacking. (Such > as dropping /usr/share/doc, /usr/share/info/,...) > > 3. Ask for unzip option by user preference for text/man/info pages in > usr/share/*/ by dpkg later as wishlist. (Disk will be much cheaper then.) > This will give you faster man/info/... if it is CPU bound. We will have faster CPUs then as well... but as long as can keep man, info... compressed that's fine with me. yours Martin -- <[EMAIL PROTECTED]> Debian GNU/Linux - The Universal Operating System I'm not smoking, I'm only carrying cigarrettes. -- Amaya on the trip to Gramado/Caracol -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *-doc package should not gzip PDF file
On Sun, Jun 25, 2006 at 08:30:34AM +0200, Preben Randhol wrote: > On Sat, 24 Jun 2006 20:35:53 +0900 > Osamu Aoki <[EMAIL PROTECTED]> wrote: ... > > * propose policy update proposal. (debian-policy) > > Ok, I'll bring it up here. > > > Unless someone do the first work, nothing will change. It is > > non-issue for me now (so I will not do it) but I have no reason to > > object such an rational move. > > I have no idea how debhelper works. Are there anybody out there that > can help with getting it to stop gzipping files in -doc? I think I gave wrong impression to you. "ANYBODY" does not work just because you said "right thing". Please do not bring up in debian-policy without cordinated fix to the issue. Policy is not tool to force people. We do not need arguments. We need facts, action and technical solution. Most of PDF.GZ are under me and tetex-doc people. Once we find good technical solution, we may do it without policy change. See internal compression discusion too. Regards, Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does doc packages need to contain gzipped files?
On Sun, Jun 25, 2006 at 12:08:17PM +0200, Rolf Kutz <[EMAIL PROTECTED]> wrote: > * Quoting Graham Wilson ([EMAIL PROTECTED]): > > > On Sat, Jun 24, 2006 at 01:52:58PM +0200, Domenico Andreoli wrote: > > > > I think the more important thing to realize is that the reason we have > > -doc packages is because the documentation for a given program takes up > > a fair amount of space. If a user installs a -doc package, they know > > they are getting extra stuff that takes up more space, so they should > > really get the docs in the most convenient form, not in the most > > compressed form. > > Do you think users with small machines shouldn't > be able to install docs, too? It's just a one line > script to gunzip all pdfs in /usr/share/doc. But in such case, the uncompressed files are out of dpkg's scope and won't get removed on package removal... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does doc packages need to contain gzipped files?
Hi, On Sun, Jun 25, 2006 at 11:05:54AM +0200, Martin Wuertele wrote: > * Eduard Bloch <[EMAIL PROTECTED]> [2006-06-25 10:18]: > > > * Martin Wuertele [Sun, Jun 25 2006, 08:09:57AM]: > > > > > file-roller does view pdf.gz and if e.g. firefox handels them incorrect > > > it should be fixed in there. We don't change policy when programs are > > > broken, we fix them. > > > > What shitty kind of reasoing is that? "If it does not use my extra stuff > > then it is incorrect?" "If Debian does not use RedHat Kickstart then it > > is broken?" > > Do you have some arguements beside the rant? See my other post. > firefox definitely should > handle .txt.gz and other gzipped plaintext documentation. I'm not > talking about pdfs, as in the thread back then I still prefere to use > the built-in compression available for pdfs. Agree here on "the built-in compression available for pdfs". Is there any external tool to convert PDF with better internal compression? I want to see ome PDF make file to use it to improve their PDF. Some PDF can still be compressed 50%, as I posted, which is bad. > > > > then I do not understand why it is done. > > > > > > See other mails in this thread, ther are good reasons to keep doc > > > packages compressed, e.g. half a gig of space saving. > > > > This extrapolation does hardly describe the real situation. Who install > > all -doc packages available in Debian and does not use them? > > That number was from a typical installation. I don't think pdfs should > be gzipped but the built-in compression should be used. However not > compressing anything is a real unnecessary waste of space. > > On my portable I have ~4.6K gzipped files in /usr/share/doc and only 39 > of them are pdfs, 4 are html files. > > I just copied the whole /user/share/doc (169M) to another lvm and > uncompressed everything in there - a typical installation - and > uncompressed all the gzipped files. That results in a total of 323M > nearly doubling the required space. But it is a tiny difference considering your /usr may be as big as 2GB. > I favour keepin plaintext documentation gzipped therefore. I understand your point here. We should not rush this nor unzipping should be default even in the future for changelog etc. Step should be: 1. No more *.pdf.gz file. (That is now) 2. Wait for smart dpkg which can do smart thing upon unpacking. (Such as dropping /usr/share/doc, /usr/share/info/,...) 3. Ask for unzip option by user preference for text/man/info pages in usr/share/*/ by dpkg later as wishlist. (Disk will be much cheaper then.) This will give you faster man/info/... if it is CPU bound. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does doc packages need to contain gzipped files?
#include * Martin Wuertele [Sun, Jun 25 2006, 11:05:54AM]: > > then it is incorrect?" "If Debian does not use RedHat Kickstart then it > > is broken?" > > Do you have some arguements beside the rant? firefox definitely should > handle .txt.gz and other gzipped plaintext documentation. I'm not Should: maybe, depends on users and webmasters preferences. Must: not. And what has this to do with local use (TOPIC)? > On my portable I have ~4.6K gzipped files in /usr/share/doc and only 39 > of them are pdfs, 4 are html files. TOPIC? That is not about all the obligatory docs (which shall be compressed since rarely used) but contents of -doc packages. And besides of that, compression does not make sense on most PDFs as pointed out by yuo/me/many others and the remaining PDFs have good chances to recompressed internally. Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does doc packages need to contain gzipped files?
* Quoting Graham Wilson ([EMAIL PROTECTED]): > On Sat, Jun 24, 2006 at 01:52:58PM +0200, Domenico Andreoli wrote: > > I think the more important thing to realize is that the reason we have > -doc packages is because the documentation for a given program takes up > a fair amount of space. If a user installs a -doc package, they know > they are getting extra stuff that takes up more space, so they should > really get the docs in the most convenient form, not in the most > compressed form. Do you think users with small machines shouldn't be able to install docs, too? It's just a one line script to gunzip all pdfs in /usr/share/doc. - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does doc packages need to contain gzipped files?
Hi, On Sat, Jun 24, 2006 at 05:30:59PM +0200, Mario 'BitKoenig' Holbe wrote: > Preben Randhol <[EMAIL PROTECTED]> wrote: > > My point is that if I choose to install a doc packages I intend to use > > it frequently and would therefore like that it is user friendly rather > > than that one has squeezed some few kilobytes out by gzipping files. If > > Agreed. Particularly since the saving isn't sooo big at all. > On my - of course, not representative - workstation an uncompressed > doc/ tree takes only about a third more space (and this includes all > the ChangeLogs, READMEs etc. shipped with each package). > > [EMAIL PROTECTED]:~# du -sh /usr/share/doc > 839M/usr/share/doc > [EMAIL PROTECTED]:~# cp -ia /usr/share/doc /var/tmp > [EMAIL PROTECTED]:~# cd /var/tmp/doc > [EMAIL PROTECTED]:/var/tmp/doc# find . -type f -name \*.gz -print0 | xargs -0 > gzip -d > gzip: ./kernel-package/Rationale already exists;not overwritten > gzip: ./kernel-package/HOWTO-Linux-2.6-Woody already exists;not > overwritten > gzip: ./gcc-4.1-base/.changelog.Debian.gz has 1 other link -- unchanged > gzip: ./gcc-4.1-base/changelog.Debian.gz has 1 other link -- unchanged > [EMAIL PROTECTED]:/var/tmp/doc# du -sh . > 1,3G. > [EMAIL PROTECTED]:/var/tmp/doc# Interesting stat. Let me follow-up. On my system "du -sh ." returned: total/usr2.4G compressed /usr/share/doc 239M uncompressed /usr/share/doc 435M Although it looks like 40% saving in space, its overall impact is less than 10% shrink in size. Let me add popular big doc (tetex, gcc, harden) packages to my system and see what happens a bit more carefully. total/usr2.5G compressed /usr/share/doc 305M uncompressed pdf /usr/share/doc 322M ( 25.7% total as told by gzip -l) ( 50136586 Compressed <--- 67439000 Before) uncompressed all /usr/share/doc 515M Yes, space saving of compressing file size of PDF 25.7% only yield disk space saving of 17MB. Out of more than 2.5GB installation, this is zero gain. So PDF compress just yield no real impact to space but slow read time of doc packages. Wait, there is less than 70MB of PDF. Yes, this is true. Due to difficulties of making nice PDF out of XML/SGML without hitting FTBFS, many packages does not bother PDF creation. Most of the doc containing PDF are: Debian doc project CVS related doc packages build with debiandoc-sgml TeTex related documents (mostly in tetex-doc) Exceptions, I found, were under: shared-mime-info xen-doc dblatex hlatex fcitx tex-common texmf The thing is we do not put HTML doc files in tar.gz'ed archive to save size. That is the real space eater. Putting unreasonable restriction on PDF yield no real gain. As I see the fact above, at least PDF should not be required to be compressed externally with gzip. Since dh_compress does compression (except the copyright file, .html and .css files, and files that appear to be already compressed based on their extensions) per its manpage, why not treat PDF as "compressed" which I thought is the case. In this sense, we do not need policy change. Just minor change in code to realize what dh_compress claim to do. It is very slow to open over 1MB size PDF file even on a system with proper auto-ungzipping. So aside from pedantic policy argument, we should uncompress PDF. Osamu PS: I did not feel like using -X option now because debhelper default should be desired behaviour. But I may change my mind soon. Reference: [EMAIL PROTECTED]:/var/tmp2# find . -type f -name \*.pdf.gz -print0 | xargs -0 gzip -l compresseduncompressed ratio uncompressed_name 228023 510762 55.4% ./debian-policy/fhs/fhs-2.3.pdf 486418 682351 28.7% ./debian-policy/policy.pdf 318890 456439 30.1% ./debian/FAQ/debian-faq.en.pdf 124536 155443 19.9% ./shared-mime-info/shared-mime-info-spec.pdf 798976 1239893 35.6% ./Debian/reference/reference.en.pdf 692308 1063782 34.9% ./Debian/reference/reference.de.pdf 808949 1245798 35.1% ./Debian/reference/reference.es.pdf 781341 1202792 35.0% ./Debian/reference/reference.fr.pdf 828482 1274316 35.0% ./Debian/reference/reference.it.pdf 1784610 2567959 30.5% ./Debian/reference/reference.ja.pdf 901423 1340825 32.8% ./Debian/reference/reference.pl.pdf 833802 1273284 34.5% ./Debian/reference/reference.pt-br.pdf 2039169 2888341 29.4% ./Debian/reference/reference.zh-cn.pdf 2125677 3018941 29.6% ./Debian/reference/reference.zh-tw.pdf 224459 265209 15.4% ./texmf/tetex/TETEXDOC.pdf 150469 174936 14.0% ./tex-common/
Re: Why does doc packages need to contain gzipped files?
* Eduard Bloch <[EMAIL PROTECTED]> [2006-06-25 10:18]: > * Martin Wuertele [Sun, Jun 25 2006, 08:09:57AM]: > > > file-roller does view pdf.gz and if e.g. firefox handels them incorrect > > it should be fixed in there. We don't change policy when programs are > > broken, we fix them. > > What shitty kind of reasoing is that? "If it does not use my extra stuff > then it is incorrect?" "If Debian does not use RedHat Kickstart then it > is broken?" Do you have some arguements beside the rant? firefox definitely should handle .txt.gz and other gzipped plaintext documentation. I'm not talking about pdfs, as in the thread back then I still prefere to use the built-in compression available for pdfs. > > > then I do not understand why it is done. > > > > See other mails in this thread, ther are good reasons to keep doc > > packages compressed, e.g. half a gig of space saving. > > This extrapolation does hardly describe the real situation. Who install > all -doc packages available in Debian and does not use them? That number was from a typical installation. I don't think pdfs should be gzipped but the built-in compression should be used. However not compressing anything is a real unnecessary waste of space. On my portable I have ~4.6K gzipped files in /usr/share/doc and only 39 of them are pdfs, 4 are html files. I just copied the whole /user/share/doc (169M) to another lvm and uncompressed everything in there - a typical installation - and uncompressed all the gzipped files. That results in a total of 323M nearly doubling the required space. I favour keepin plaintext documentation gzipped therefore. yours Martin -- <[EMAIL PROTECTED]> Debian GNU/Linux - The Universal Operating System Assembler is easy, just a lot of work. -- Peter De Schrijver, Linuxtag 2004 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does doc packages need to contain gzipped files?
#include * Martin Wuertele [Sun, Jun 25 2006, 08:09:57AM]: > > Yes, but the problem is that many systems (firefox, rox-filer etc...) > > file-roller does view pdf.gz and if e.g. firefox handels them incorrect > it should be fixed in there. We don't change policy when programs are > broken, we fix them. What shitty kind of reasoing is that? "If it does not use my extra stuff then it is incorrect?" "If Debian does not use RedHat Kickstart then it is broken?" > > then I do not understand why it is done. > > See other mails in this thread, ther are good reasons to keep doc > packages compressed, e.g. half a gig of space saving. This extrapolation does hardly describe the real situation. Who install all -doc packages available in Debian and does not use them? Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *-doc package should not gzip PDF file
#include * Osamu Aoki [Sat, Jun 24 2006, 08:35:53PM]: > > If one really really need to gzip, then make all applications in the > > default Debian system able to handle gzipped files so there is no need > > to unzip them to your local area and in fact use more space than > > needed. > > The point is, if this mechanism is active, there is no point to gzip > pdf/ps/txt file in /usr/share/doc/* in regular package either. Of course there is. In regular packages huge docs are just balast. You hardly need those files, maybe once to get the package running. OTOH doc packages are installed explicitely when the user wants to use the docs. I would drop this "docs must be compressed" rule from the policy and make it a recommendation instead. Something like "Documentation files in /usr/share/doc shall be compressed with gzip unless they are intended for regular use, eg. for accompanying documentation (...-doc) packages." Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
