Are we monitoring disk space per package over time anywhere?

[Steffen Möller]

Hello,

with more people using Debian on phones and SSDs, the size
of packages keeps being an issue. And some claim that there
would not be much difference of current distros to all the
overhead that Redmond brings.

Are we monitoring any sudden in- or decrease in disk
space per package or "per tasksel" anywhere already?

Many thanks and regards

Steffen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e61f7ec.2060...@gmx.de

Status of circulars dependencies in unstable

[Bill Allombert]

Dear developers,

Today circular dependencies in unstable reached an all-time low, with
only 40 circular dependencies.

Here the current list:

* acheck acheck-rules
* aide aide-common
* autodocktools mgltools-pmv
* bochs bochs-wx
* bootcd bootcd-i386 bootcd-ia64 (1 pre-depends)
* ca-certificates-java openjdk-6-jre-headless openjdk-6-jre-lib
* cli-uno-bridge libuno-cli-cppuhelper1.0-cil
* console-common console-setup console-setup-linux kbd
* cowbuilder cowdancer
* dmsetup libdevmapper1.02.1
* g++-4.4 libstdc++6-4.4-dev
* g++-4.5 libstdc++6-4.5-dev
* g++-4.6 libstdc++6-4.6-dev
* gamin libgamin0
* gcj-4.4-jdk libgcj10-dev
* gcj-4.6-jdk libgcj12-dev
* gdc-4.4 libphobos-4.4-dev
* ggz-gtk-games ggz-gtk-games-data
* ggz-sdl-games ggz-sdl-games-data
* ghostscript gs-cjk-resource libgs9
* gnuift gnuift-perl
* heroes-common heroes-ggi heroes-sdl
* klogd sysklogd 
* libc6 libgcc1 multiarch-support (1 pre-depends)
* libdcerpc0 libgensec0 libndr-standard0 libndr0 libregistry0 
libsamba-hostconfig0 libsamba-util0
* liblwp-protocol-https-perl libwww-perl
* libmono-corlib2.0-cil libmono-posix2.0-cil libmono-security2.0-cil 
libmono-system2.0-cil mono-2.0-gac mono-gac mono-runtime
* libmono-system-data-linq2.0-cil libmono-system-web2.0-cil libmono-wcf3.0-cil 
libmono2.0-cil
* monodoc-browser monodoc-http monodoc-manual
* odbcinst odbcinst1debian2
* pcb-common pcb-gtk pcb-lesstif
* perl perl-modules
* python-imaging python-imaging-tk
* python-netcdf python-scientific
* rubygems rubygems1.8
* strongswan-ikev1 strongswan-ikev2 strongswan-nm strongswan-starter
* sun-java6-bin sun-java6-jre
* tasksel tasksel-data
* uqm uqm-content
* xemacs21 xemacs21-bin xemacs21-mule xemacs21-mule-canna-wnn xemacs21-nomule 
xemacs21-support

For more detail, please see additional data at 


courtesy of Robert Lemmen.

I would like to thanks all the developpers that have worked toward removing
circular dependencies, and especially the X Strike Force and the Debian Java
maintainers.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Re: Are we monitoring disk space per package over time anywhere?

[Samuel Thibault]

Steffen Möller, le Sat 03 Sep 2011 11:48:28 +0200, a écrit :
> with more people using Debian on phones and SSDs, the size
> of packages keeps being an issue. And some claim that there
> would not be much difference of current distros to all the
> overhead that Redmond brings.
> 
> Are we monitoring any sudden in- or decrease in disk
> space per package or "per tasksel" anywhere already?

See the Installation Manual, in "random bits". You can compare the
manual among releases. I have warned about not being able to install
Debian with no more than 512 on

http://lists.debian.org/debian-devel/2010/10/msg00310.html

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110903102233.GE7347@type

Re: kernel.org compromised

[Joerg Jaspert]

> Yeah, yeah.  We've beaten that horse to death, and our side lost.  I also
> advocate that all debs should be signed, but that was not the will of the
> ftp-masters the last time the issue was up for discussion.

Thats wrong.
Since 03 Aug 2008 at least.

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340306#33

(If dpkg-sig is THE way to go is a different topic, but it's a way that
 was there. The maintainers of dpkg-sig don't seem to be interested
 anymore, but thats not a fault of (current) ftpmasters)


-- 
bye, Joerg
(23:02)  I should take a photograph of my stapler, the maker of which is 
"RAPESCO"


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vq5oqfh@gkar.ganneff.de

Re: kernel.org compromised

[Andreas Barth]

* Joerg Jaspert (jo...@debian.org) [110903 12:44]:
> 
> > Yeah, yeah.  We've beaten that horse to death, and our side lost.  I also
> > advocate that all debs should be signed, but that was not the will of the
> > ftp-masters the last time the issue was up for discussion.
> 
> Thats wrong.
> Since 03 Aug 2008 at least.
> 
> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340306#33

This means that dpkg-sig needs to be completly re-written, even though
it was working quite well (before it was blocked by ftp-masters). Not
exactly what I would consider helpful, but well.

Anyways, I don't think discussing this topic more will gain us
anything. (And also the question of signing .deb-packages is completly
orthogonal from authentication of the downloaded packages files which
works, and which is necessary for protection from taken over hosts
like kernel.org this time).


Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110903112210.gl15...@mails.so.argh.org

Bug#640204: ITP: ztex-bmp -- babel universal macro processor

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: ztex-bmp
  Upstream Author : Stefan Ziegenbalg
* URL : http://www.ztex.de
* License : GPL-3
  Programming Lang: Pascal
  Description : babel universal macro processor

 The package is close to be ready for an upload. Respective
 progress can be inspected at
  http://anonscm.debian.org/viewvc/pkg-escience/ztex-bmp/trunk/



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110903112640.9778.50289.reportbug@Toshiba.siemens

Re: Are we monitoring disk space per package over time anywhere?

[Neil Williams]

On Sat, 03 Sep 2011 11:48:28 +0200
Steffen Möller  wrote:

> Hello,
> 
> with more people using Debian on phones and SSDs, the size
> of packages keeps being an issue. 

It's more than the packages themselves. It also includes the Packages
file and there's a clear need to encourage maintainers to use more
package splits.

Emdebian has smaller packages and keeps the Packages file smaller by
only providing a subset of all packages in Debian.

There is a possible issue where Debian might consider splitting main
by functionality as well as by freedom but Emdebian has tried that with
our Component support and it proved too difficult to manage in the long
term.

Other issues include:

0: single binaries which need upstream support to split up
1: over zealous dependencies / recommends
2: package selection - maintainers / upstreams need encouragement to
package smaller apps with smaller dependency chains *and leave them
small* which leads on to:
3: resisting feature creep. This includes closing some bugs as wontfix
when what is needed is another small tool instead of the existing tool
becoming twice the size.

> And some claim that there
> would not be much difference of current distros to all the
> overhead that Redmond brings.

Depends if you can live without Xorg - not all graphics need libx11.
 
> Are we monitoring any sudden in- or decrease in disk
> space per package or "per tasksel" anywhere already?

The closest we get is the DebianCD team. There are many other factors
which affect whether any particular package is considered "too big". A
small package with a nightmare dependency chain is as much of a problem
as a big package which only depends on libc6. Small python apps
(especially GUI ones), many perl packages, panel applets too - it's
surprising how often a small package generates links into massive
dependency chains. I try to gauge some of these problems by installing
problematic packages in an empty pbuilder chroot - not the -dev
package, the runtime, starting from only what is part of
build-essential.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpXW4OG5KN4X.pgp
Description: PGP signature

Bug#640240: ITP: toprammer -- Command-line and GUI software for the TOP2049 universal programmer

[Uwe Hermann]

Package: wnpp
Severity: wishlist
Owner: Uwe Hermann 

* Package name: toprammer
  Version : 0.9
  Upstream Author : Michael Büsch
* URL : http://bues.ch/cms/hacking/toprammer.html
* License : GPL
  Programming Lang: Python
  Description : Command-line and GUI software for the TOP2049 universal 
programmer

Control software for the TOP2049 universal programmer, written in Python.
There's a commandline and GUI (PyQT) tool available.

As all programming algorithm logic is implemented in software, it does
not support all the devices that the original "Topwin" Windows software
supports. However, support for new chips can be added, if needed.

Support for other "TOP" devices like the TOP2007, TOP3000 or TOP3100 is
planned, but currently not implemented. 


Uwe.
-- 
http://hermann-uwe.de | http://sigrok.org
http://randomprojects.org | http://unmaintained-free-software.org



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110903144730.GA31704@greenwood

Bug#640263: debian-policy: Clarify policy section 9.9 - Environment variables

[Carl Fürstenberg]

Package: debian-policy
Version: 3.9.2.0
Severity: normal

Per resolution of bug #639997 I would like to ask for clarification of
section 9.9 in the polcy regarding environmental variables, and if it
implicitly excludes "global" environmental variables like PATH, or if
all programs must include themself a sensible default PATH as fallback.


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

debian-policy depends on no packages.

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
ii  doc-base  0.10.2 utilities to manage online documen

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110903172416.3842.93725.report...@azaboxen.carl

Re: Dependencies of metapackages

[Yves-Alexis Perez]

On mer., 2011-08-31 at 11:59 +0100, Wolodja Wentland wrote:
> 
> Could you elaborate on your reasons and your intentions for making the
> distinction?

Policy 7.2, mostly, and the fact depends are installed (obviously),
recommends are installed by default (but that can be disabled and one
can remove it safely) and suggests are just displayed.

>  Do you have reasons for not changing Depends into Recommends? I
> will probably file bugs, but do not want to do so if I already know that the
> maintainer is not going to change it. I am sincerely interested and my only
> motivation is to make Debian a better distribution. 

I'm not going to change it if you don't have good reason for specific
packages changes.

Regrds,
-- 
Yves-Alexis


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

Bug#640284: ITP: ab-chocolate -- inline assignments book

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 


* Package name: ab-chocolate
  Version : 49.00
  Upstream Author : Pierre Lemaitre 
* URL : http://www.etab.ac-caen.fr/bsauveur/cahier_de_texte/
* License : GPL-3+, and BSD-like
  Programming Lang: PHP, Perl
  Description : inline assignments book

 ab-chocolate stands for "assignment book -chocolateware-". It features an 
 inline assignment book for teachers and students. This web application has
 been developed initially in educational institutions near Caen (France),
 and has been tested and polished by numerous educational actors: teachers,
 students and their parents. It is easy to use for beginners, still fitted
 for demanding users. 
 .
 The mainstream author of ab-chocolate accepts donations, and chocolate.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110903223345.9077.14240.report...@photos.khaznadar.fr