Bug#680610: ITP: predictprotein -- A service for sequence analysis and the prediction of protein structure and function

[s . domke]

Package: wnpp
Severity: wishlist
Owner: s.do...@wzw.tum.de


* Package name: predictprotein
  Version : 1.0.0
  Upstream Author : Laszlo Kajan 
* URL : http://www.predictprotein.org//
* License : GPL
  Programming Lang: Perl
  Description : A service for sequence analysis and the prediction of 
protein structure and function

PredictProtein is a sequence analysis suite providing prediction of protein
structure and function. It takes protein sequences or alignments as input
and provides the following per-residue or whole protein annotations: multiple
sequence alignments, PROSITE sequence motifs, low-complexity regions, nuclear
localisation signals, regions lacking regular structure (NORS), secondary
structure, solvent accessibility, globular regions, transmembrane helices,
coiled-coil regions, structural switch regions, disulfide-bonds, sub-cellular
localization, disordered regions, B-value flexibility, protein-protein
interaction sites and protein-DNA interaction sites. Upon request fold
recognition by prediction-based threading, CHOP domain assignments,
predictions of transmembrane strands and inter-residue contacts are also
available.



-- 
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/20120707093936.28026.42135.report...@i12r-tbl.informatik.tu-muenchen.de

Re: CD sizes again (and BoF reminder!)

[Ansgar Burchardt]

Steve McIntyre  writes:
> On Fri, Jul 06, 2012 at 09:00:32PM -0600, Ansgar Burchardt wrote:
>>I tried recompressing all packages in wheezy with xz.  The total size
>>for all amd64+all packages was reduced from 42GB to 33 GB (about 20%).
>>A per-package listing is available from [1]
>>
>>  [1] 
>>
>>Would this be enough to make GNOME and/or KDE installable from a single
>>CD image?
>
> Using rough calculation:
>
>  * For GNOME, it takes about 185MB out of the space used to get up to
>task-gnome-desktop. Instead of being ~90MB into CD#2, that's ~100MB
>inside CD#1.
>
>  * For KDE, it takes about 170MB out of the space used to get up to
>task-kde-desktop. Instead of being ~70MB into CD#2, that's ~100MB
>inside CD#1.
>
> So, yes - looks like xz will make a difference here for the wheezy
> release, for amd64 at least. It's enough that we'd probably even have
> space for the installation manual and release notes to fit \o/.
>
> i386 is still worse off (2 kernels instead of 1), but I don't have the
> exact figures to hand.

We need a safety margin as the base system must continue to use gzip
compression.  But my feelings say that 100 MB should be enough for that.

Another question is if the release team would consider unblocking
updated packages (with just the switch to xz for binaries).  I think it
would be nice to be able to get a useful desktop system using just the
first CD, but I'm not sure if they would make an exception for this.

Ansgar


-- 
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/87r4snohc6@marvin.43-1.org

Re: CD sizes again (and BoF reminder!)

[Bastian Blank]

On Fri, Jul 06, 2012 at 10:10:04PM +0100, Steve McIntyre wrote:
>   http://cdimage.debian.org/cdimage/tmp/new-tasks/gnome-cd.list.gz

Why does this contain debug packages?

Bastian

-- 
I've already got a female to worry about.  Her name is the Enterprise.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0


-- 
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/20120707131015.ga25...@wavehammer.waldi.eu.org

Re: CD sizes again (and BoF reminder!)

[Steve McIntyre]

On Sat, Jul 07, 2012 at 03:10:15PM +0200, Bastian Blank wrote:
>On Fri, Jul 06, 2012 at 10:10:04PM +0100, Steve McIntyre wrote:
>>   http://cdimage.debian.org/cdimage/tmp/new-tasks/gnome-cd.list.gz
>
>Why does this contain debug packages?

The list posted there is the full sorted list of *all* packages, as
applied to the full set of CDs. The last one on CD#1 is
gnome-packagekit-data, as I said, and I don't see any debug packages
above that in the list.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess


-- 
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/20120707133444.gv4...@einval.com

Re: CD sizes again (and BoF reminder!)

[Bastian Blank]

On Sat, Jul 07, 2012 at 02:34:44PM +0100, Steve McIntyre wrote:
> The list posted there is the full sorted list of *all* packages, as
> applied to the full set of CDs. The last one on CD#1 is
> gnome-packagekit-data, as I said, and I don't see any debug packages
> above that in the list.

Ups, I did the wrong check.

Anyway, some remarks:
- aptitude: can be downgraded from standard
- gcc-4.[56]-base
- python2.6: 2.7 is already there
- loop-aes-utils: loop-aes is not supported
- grub-legacy
- build-essential, linux-kbuild-3.2, kernel-package: development stuff
- module-assistant: deprecated for dkms
- localepurge
- pump

This is all before X.

Bastian

-- 
Insults are effective only where emotion is present.
-- Spock, "Who Mourns for Adonais?"  stardate 3468.1


-- 
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/20120707141409.gb25...@wavehammer.waldi.eu.org

Re: EFI in Debian

[Ansgar Burchardt]

Hi,

Ben Hutchings  writes:
> 2. Upstream kernel support: when booted in Secure Boot mode, Linux would
> only load signed kernel modules and disable the various debug interfaces
> that allow code injection.  I'm aware that David Howells, Matthew
> Garrett and others are working on this.

That makes dkms modules unusable when using secure boot.  I guess we
would have to build binary packages for all supported kernel versions?

> 5. Key management policy.  Similar issues to archive signing keys, but
> these keys also need to be available at build time.  (a) Should they be
> held by package maintainers and/or the auto-builders for the relevant
> architectures?  (b) sbuild and/or pbuilder will need to know how to
> inject them into the build environment for the relevant packages.  (c)
> How do we handle key replacement when exploitable code needs to be
> blacklisted?

Do these need to be available when building the kernel packages or would
it be possible to have the signatures in a separate package?  The latter
would allow moving the signing off the auto-builders and having either
a human maintainer or a dedicated system do so instead (so the
auto-builders would not need access to the keys).  It would also allow
signing modules provided in the maintainer upload.

Ansgar


-- 
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/87k3yfoci0@marvin.43-1.org

Re: Bug#680226: lib{nss,pam}-ldapd: apt wants to remove them on dist-upgrade in favour of lib{nss,pam}-ldap:i386

[Arthur de Jong]

On Fri, 2012-07-06 at 10:00 +0200, David Kalnischkies wrote:
> > I'm not sure what the proper way is to specify that Conflicts and
> > Provides should only apply for a same-architecture version of the
> > package. If I do this (just trying some things):
> 
> There is simple no way.

Thanks for your reply.

I guess I could drop the Provides for now then which seems to be the
least disruptive change to support multiarch (but also see below).

I can't drop the Conflicts because libnss-ldapd and libnss-ldap share
the same file (at least the same library which may be in the same file
depending on whether you are comparing multiarch or non-multiarch
versions). 

> > # dpkg -i libnss-ldapd_0.8.10-2_i386.deb
> > dpkg: error processing libnss-ldapd_0.8.10-2_i386.deb (--install):
> >  parsing file '/var/lib/dpkg/tmp.ci/control' near line 9 package 
> > 'libnss-ldapd':
> >  'Conflicts' field, reference to 'libnss-ldap': invalid architecture name 
> > 'i386': a value different from 'any' is currently not allowed
> 
> Which dpkg version is that?

This was 1.16.4.2 that was lying around in a play chroot. dpkg 1.16.7
installs the deb just fine.

I've been playing a bit with only changing the conflicts to include
:${Arch} which seems to work with dpkg (though lintian still complains),
however apt doesn't seem to understand it and doesn't remove
libnss-ldapd when installing libnss-ldap.

Then again, I can't reproduce the problem that Thorsten reported. I've
got both libnss-ldapd:i386 and libnss-ldapd:amd64 installed (both
0.8.10-1) in a chroot with dpkg:i386 1.16.7. The installation was done
with apt-get (apt:i386 0.9.7.1) and went fine. Also apt-get dist-upgrade
doesn't want to remove either of the packages (for some reason apt does
want to switch back to the i386 coreutils that I managed to switch to
amd64).

On Fri, 2012-07-06 at 11:02 +, Thorsten Glaser wrote: 
> Could this work: libnss-ldap and libnss-ldapd both provide the same
> virtual package and conflict with it? Same for the pam ones but a
> different virtual package.

My guess is that it wouldn't because the conflict would still match it
on the other architecture.

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


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

Sysklogd vs. rsyslog

[Touko Korpela]

(please cc me)

Rsyslog is now the default syslog daemon on Debian (at least on wheezy,
maybe earlier also).
It has more features than sysklogd. Maybe package description of sysklogd
should tell that better logging daemons are available and it's no
longer the default?
Some upgraders from previous releases may miss that change
and stay at sysklogd if they don't install new alternative themself.

Recent issue is that new kernels (3.5-rc?) have a problem with sysklogd.
http://marc.info/?l=linux-kernel&m=134161256014626&w=2
Maybe someone can reply there if having knowledge.
In same thread Linus made another harsh reply that I don't quote here:
http://marc.info/?l=linux-kernel&m=134160685712793&w=2


-- 
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/20120707164025.GA25743@lisko

Re: Sysklogd vs. rsyslog

[Andrei POPESCU]

On Sb, 07 iul 12, 19:40:25, Touko Korpela wrote:
> (please cc me)

Done.

> Some upgraders from previous releases may miss that change
> and stay at sysklogd if they don't install new alternative themself.

Upgraders should also read the Release Notes ;)
http://www.debian.org/releases/lenny/i386/release-notes/ch-whats-new.en.html#system-changes

Kind regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: Sysklogd vs. rsyslog

[Guillem Jover]

On Sat, 2012-07-07 at 19:40:25 +0300, Touko Korpela wrote:
> Recent issue is that new kernels (3.5-rc?) have a problem with sysklogd.
> http://marc.info/?l=linux-kernel&m=134161256014626&w=2
> Maybe someone can reply there if having knowledge.
> In same thread Linus made another harsh reply that I don't quote here:
> http://marc.info/?l=linux-kernel&m=134160685712793&w=2

This would be due to:

  

for which I did a review that got ignored:

  

regards,
guillem


-- 
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/20120707170702.ga3...@gaara.hadrons.org

Re: Sysklogd vs. rsyslog

[Michael Biebl]

On 07.07.2012 19:07, Guillem Jover wrote:
> On Sat, 2012-07-07 at 19:40:25 +0300, Touko Korpela wrote:
>> Recent issue is that new kernels (3.5-rc?) have a problem with sysklogd.
>> http://marc.info/?l=linux-kernel&m=134161256014626&w=2
>> Maybe someone can reply there if having knowledge.
>> In same thread Linus made another harsh reply that I don't quote here:
>> http://marc.info/?l=linux-kernel&m=134160685712793&w=2
> 
> This would be due to:
> 
>   
> 
> for which I did a review that got ignored:
> 
>   
> 

Is sysklogd still actively maintained upstream/in Debian?
Doesn't look like it from a cursory glance.

Maybe the package should be O/RFAed or completely retired if no one is
found to take care of it.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#680654: ITP: fglrx-driver-legacy -- non-free legacy ATI/AMD RadeonHD display driver

[Andreas Beckmann]

Package: wnpp
Severity: wishlist
Owner: Andreas Beckmann 

* Package name: fglrx-driver-legacy
  Version : 12.6~beta
  Upstream Author : AMD/ATI
* URL : 
http://support.amd.com/us/kbarticles/Pages/catalyst126legacyproducts.aspx
* License : proprietary
  Programming Lang: precompiled binaries
  Description : non-free legacy ATI/AMD RadeonHD display driver

Re-adds support for the AMD Radeon HD 4000, AMD Radeon HD 3000,
and AMD Radeon HD 2000 Series which was dropped in fglrx-driver 12-6.

According to 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675940#77
this supports Xorg Xserver 1.12
Unfortunately the download server is currently unreachable
(missing DNS records).

Package will be handled by the Fglrx packaging team.

Andreas



-- 
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/20120707182608.1756.65534.report...@cake.ae.cs.uni-frankfurt.de

Re: Bug#679078: ITP: acpi-support-minimal -- minimal acpi scripts

[Michael Meskes]

On Sat, Jul 07, 2012 at 01:29:39AM +0200, Vincent Bernat wrote:
> The bug is already closed but I'd like to share another solution: I am
> using "acpi_fakekey $KEY_COFFEE" which sends XF86ScreenSaver key to the
> currently displayed X server. This is not foolproof (only one X server,
> only if it is currently displayed) but it is far simpler than other
> solutions.

Sorry, but what is "acpi_fakekey $KEY_COFFEE" supposed to accomplish? Sending
XF86ScreenSaver key? I don't really how this relates to this big report. Could
you please explain?

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL


-- 
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/20120707183828.ga13...@feivel.credativ.lan

Re: EFI in Debian

[Ben Hutchings]

On Sat, 2012-07-07 at 08:46 -0600, Ansgar Burchardt wrote:
> Hi,
> 
> Ben Hutchings  writes:
> > 2. Upstream kernel support: when booted in Secure Boot mode, Linux would
> > only load signed kernel modules and disable the various debug interfaces
> > that allow code injection.  I'm aware that David Howells, Matthew
> > Garrett and others are working on this.
> 
> That makes dkms modules unusable when using secure boot.  I guess we
> would have to build binary packages for all supported kernel versions?

The Linux kernel hardly has a perfect security record, but signing code
that is too bad even for staging will be a quick route to blacklisting.
I would absolutely oppose signing out-of-tree modules with Debian keys.

> > 5. Key management policy.  Similar issues to archive signing keys, but
> > these keys also need to be available at build time.  (a) Should they be
> > held by package maintainers and/or the auto-builders for the relevant
> > architectures?  (b) sbuild and/or pbuilder will need to know how to
> > inject them into the build environment for the relevant packages.  (c)
> > How do we handle key replacement when exploitable code needs to be
> > blacklisted?
> 
> Do these need to be available when building the kernel packages or would
> it be possible to have the signatures in a separate package?

That is possible... but the installation process would be tricky.

> The latter
> would allow moving the signing off the auto-builders and having either
> a human maintainer or a dedicated system do so instead (so the
> auto-builders would not need access to the keys).  It would also allow
> signing modules provided in the maintainer upload.

It would also help sites to sign with their own PK, if they want to take
full advantage of Secure Boot.

Ben.

-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson


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

Re: CD sizes again (and BoF reminder!)

[Ben Hutchings]

On Sat, 2012-07-07 at 16:14 +0200, Bastian Blank wrote:
> On Sat, Jul 07, 2012 at 02:34:44PM +0100, Steve McIntyre wrote:
> > The list posted there is the full sorted list of *all* packages, as
> > applied to the full set of CDs. The last one on CD#1 is
> > gnome-packagekit-data, as I said, and I don't see any debug packages
> > above that in the list.
> 
> Ups, I did the wrong check.
> 
> Anyway, some remarks:
> - aptitude: can be downgraded from standard
> - gcc-4.[56]-base
> - python2.6: 2.7 is already there
> - loop-aes-utils: loop-aes is not supported
> - grub-legacy
> - build-essential, linux-kbuild-3.2, kernel-package: development stuff
> - module-assistant: deprecated for dkms
> - localepurge
> - pump
>
> This is all before X.

I agree with all the above.

More stuff unlikely to be needed on a desktop:

- ftp, telnet: mostly redundant with wget and nc, unless you really like
cleartext authentication
- tcpd: server
- procmail: server
- module-init-tools: transitional package
- pcmciautils: PCMCIA is dead
- jfsutils, reiserfsprogs, ufsutils: obscure
- openssh-server: server, not desktop
- sharutils: obscure; we've had MIME for 20 years
- fakeroot, autopoint: more development
- deborphan, debfoster: obscure
- mtools: obscure; FAT volumes are auto-mounted
- twm: no-one should have to suffer this
- discover, mdetect: I think these are pretty much obsolete, but could
be wrong
- linux-sound-base, alsa-base, alsa-utils: rarely needed AFAIK

Ben.

-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson


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

Re: EFI in Debian

[Steve Langasek]

On Fri, Jul 06, 2012 at 10:14:01AM +0200, Josselin Mouette wrote:
> Le vendredi 06 juillet 2012 à 05:32 +0100, Ben Hutchings a écrit : 
> > 1. General consensus in the project that supporting the option of Secure
> > Boot, including purchase of a Microsoft-signed certificate, is
> > worthwhile and not entirely objectionable.  

> Not entirely objectionable indeed, but it really depends on what we
> would have to pay for.  As long as it is only covering for
> administrative costs of Microsoft emitting a new certificate, it is
> fine.

Microsoft has indicated their intent to provide the Secure Boot CA services
free of charge.  AIUI the only associated fee is to a third party, Verisign,
for them to provide the service of establishing digital identity to
Microsoft's standards.

> If OTOH we have to pay a fee just for our software to work on platforms
> that just happen to be using Microsoft’s certificate, this is clearly
> abusive.  I would object to do so, and I believe we would (at least in
> Europe) have a very strong case in court against such practice.

Note that the Windows 8 requirements stipulate that users must in all cases
retain the ability to disable Secure Boot on their x86 systems from the
firmware.  It's really a question of ease of installation, and whether
Secure Boot provides any additional security protection that we think it's
worth providing to Debian users out of the box.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: EFI in Debian

[Andreas Barth]

* Steve Langasek (vor...@debian.org) [120707 22:54]:
> On Fri, Jul 06, 2012 at 10:14:01AM +0200, Josselin Mouette wrote:
> > If OTOH we have to pay a fee just for our software to work on platforms
> > that just happen to be using Microsoft’s certificate, this is clearly
> > abusive.  I would object to do so, and I believe we would (at least in
> > Europe) have a very strong case in court against such practice.
> 
> Note that the Windows 8 requirements stipulate that users must in all cases
> retain the ability to disable Secure Boot on their x86 systems from the
> firmware.  It's really a question of ease of installation, and whether
> Secure Boot provides any additional security protection that we think it's
> worth providing to Debian users out of the box.

IIRC it's not the same on embedded hardware.


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/20120707210957.gg2...@mails.so.argh.org

Re: EFI in Debian

[Stefano Zacchiroli]

On Sat, Jul 07, 2012 at 02:48:59PM -0600, Steve Langasek wrote:
> On Fri, Jul 06, 2012 at 10:14:01AM +0200, Josselin Mouette wrote:
> > If OTOH we have to pay a fee just for our software to work on platforms
> > that just happen to be using Microsoft’s certificate, this is clearly
> > abusive.  I would object to do so, and I believe we would (at least in
> > Europe) have a very strong case in court against such practice.
> 
> Note that the Windows 8 requirements stipulate that users must in all cases
> retain the ability to disable Secure Boot on their x86 systems from the
> firmware.  It's really a question of ease of installation, and whether
> Secure Boot provides any additional security protection that we think it's
> worth providing to Debian users out of the box.

This argument seems to depend on how thoroughly Microsoft will enforce
their Windows 8 requirements. AFAIU, the fact that Windows 8
requirements might, at least theoretically, be disattended is something
that played a role also in Canonical/Ubuntu decision to stay away from
Grub. All in all, it doesn't seem wise to rely on the fact that Windows
8 requirements will be enforced, especially when disattending them gives
an advantage to Microsoft, by making it even harder to install other
OSs.

Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: EFI in Debian

[Steve Langasek]

On Sat, Jul 07, 2012 at 11:09:57PM +0200, Andreas Barth wrote:
> * Steve Langasek (vor...@debian.org) [120707 22:54]:
> > On Fri, Jul 06, 2012 at 10:14:01AM +0200, Josselin Mouette wrote:
> > > If OTOH we have to pay a fee just for our software to work on platforms
> > > that just happen to be using Microsoft’s certificate, this is clearly
> > > abusive.  I would object to do so, and I believe we would (at least in
> > > Europe) have a very strong case in court against such practice.

> > Note that the Windows 8 requirements stipulate that users must in all cases
> > retain the ability to disable Secure Boot on their x86 systems from the
> > firmware.  It's really a question of ease of installation, and whether
> > Secure Boot provides any additional security protection that we think it's
> > worth providing to Debian users out of the box.

> IIRC it's not the same on embedded hardware.

The distinction is between x86 and ARM, and the Windows 8 cert requirements
for ARM appear to have as their goal to prevent any other OS to be bootable
on that hardware.  So I don't think you should expect MS to sign any UEFI
ARM bootloader binaries at all.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.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/20120707215813.gb24...@virgil.dodds.net

Re: CD sizes again (and BoF reminder!)

[Cyril Brulebois]

Ansgar Burchardt  (07/07/2012):
> Another question is if the release team would consider unblocking
> updated packages (with just the switch to xz for binaries).  I think
> it would be nice to be able to get a useful desktop system using just
> the first CD, but I'm not sure if they would make an exception for
> this.

You may want to actually ask the release team at some point, if you want
to know. Just saying…

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: CD sizes again (and BoF reminder!)

[Stefano Zacchiroli]

On Sun, Jul 08, 2012 at 12:03:44AM +0200, Cyril Brulebois wrote:
> Ansgar Burchardt  (07/07/2012):
> > Another question is if the release team would consider unblocking
> > updated packages (with just the switch to xz for binaries).  I think
> > it would be nice to be able to get a useful desktop system using just
> > the first CD, but I'm not sure if they would make an exception for
> > this.
> 
> You may want to actually ask the release team at some point, if you want
> to know. Just saying…

Thanks for the brilliant idea! :-)

Oh all mighty release team,
  Ansgar has been experimenting with .deb sizes to make the packages
needed for a minimal desktop installation fit in the first CD. It looks
like that's doable by switching to xz compression for the involved
binaries. Would you grant freeze exceptions for packages that only
changes that?

See attached email and the corresponding thread on -devel for more info.

Thanks!
Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »
--- Begin Message ---
Steve McIntyre  writes:
> On Fri, Jul 06, 2012 at 09:00:32PM -0600, Ansgar Burchardt wrote:
>>I tried recompressing all packages in wheezy with xz.  The total size
>>for all amd64+all packages was reduced from 42GB to 33 GB (about 20%).
>>A per-package listing is available from [1]
>>
>>  [1] 
>>
>>Would this be enough to make GNOME and/or KDE installable from a single
>>CD image?
>
> Using rough calculation:
>
>  * For GNOME, it takes about 185MB out of the space used to get up to
>task-gnome-desktop. Instead of being ~90MB into CD#2, that's ~100MB
>inside CD#1.
>
>  * For KDE, it takes about 170MB out of the space used to get up to
>task-kde-desktop. Instead of being ~70MB into CD#2, that's ~100MB
>inside CD#1.
>
> So, yes - looks like xz will make a difference here for the wheezy
> release, for amd64 at least. It's enough that we'd probably even have
> space for the installation manual and release notes to fit \o/.
>
> i386 is still worse off (2 kernels instead of 1), but I don't have the
> exact figures to hand.

We need a safety margin as the base system must continue to use gzip
compression.  But my feelings say that 100 MB should be enough for that.

Another question is if the release team would consider unblocking
updated packages (with just the switch to xz for binaries).  I think it
would be nice to be able to get a useful desktop system using just the
first CD, but I'm not sure if they would make an exception for this.

Ansgar


-- 
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/87r4snohc6@marvin.43-1.org

--- End Message ---


signature.asc
Description: Digital signature

Re: CD sizes again (and BoF reminder!)

[Joey Hess]

> - ftp, telnet: mostly redundant with wget and nc, unless you really like
> cleartext authentication
> - procmail: server

These are priority standard.

> - pcmciautils: PCMCIA is dead
> - jfsutils, reiserfsprogs, ufsutils: obscure
> - discover
> - openssh-server: server, not desktop
> - grub-legacy

These are all installed by d-i in various situations.

> - loop-aes-utils: loop-aes is not supported

partman-crypto still installs this.

> - sharutils: obscure; we've had MIME for 20 years
> - fakeroot, autopoint: more development
> - mtools: obscure; FAT volumes are auto-mounted
> - tcpd: server
> - module-init-tools: transitional package
> - linux-sound-base,
> - gcc-4.[56]-base
> - python2.6: 2.7 is already there

AFAICS, debian-cd does not explicitly include these, they're being
pulled in by some other packages.

> alsa-base, alsa-utils: rarely needed AFAIK

These are currently included in the desktop task.

alsa-utils stores mixer settings, so users are only puzzled by
everything defaulted to being muted once, not every boot..

> - deborphan, debfoster: obscure
> - pump
> - twm: no-one should have to suffer this
> mdetect
> - localepurge

I've removed these.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: CD sizes again (and BoF reminder!)

[Bastian Blank]

On Sat, Jul 07, 2012 at 04:36:34PM -0600, Joey Hess wrote:
> > - ftp, telnet: mostly redundant with wget and nc, unless you really like
> > cleartext authentication
> > - procmail: server
> These are priority standard.

This is fixeable.

> > - pcmciautils: PCMCIA is dead
> > - jfsutils, reiserfsprogs, ufsutils: obscure
> > - discover
> > - openssh-server: server, not desktop
> > - grub-legacy
> These are all installed by d-i in various situations.

Even grub-legacy?

> > - loop-aes-utils: loop-aes is not supported
> partman-crypto still installs this.

This can be fixed easily.

> > - sharutils: obscure; we've had MIME for 20 years
> > - fakeroot, autopoint: more development
> > - mtools: obscure; FAT volumes are auto-mounted
> > - tcpd: server
> > - module-init-tools: transitional package
> > - linux-sound-base,
> > - gcc-4.[56]-base
> > - python2.6: 2.7 is already there
> AFAICS, debian-cd does not explicitly include these, they're being
> pulled in by some other packages.

Priority? Will write bugs.

Bastian

-- 
History tends to exaggerate.
-- Col. Green, "The Savage Curtain", stardate 5906.4


-- 
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/20120707231732.ga31...@wavehammer.waldi.eu.org

Re: CD sizes again (and BoF reminder!)

[Ben Hutchings]

On Sat, 2012-07-07 at 16:36 -0600, Joey Hess wrote:
> > - ftp, telnet: mostly redundant with wget and nc, unless you really like
> > cleartext authentication
> > - procmail: server
> 
> These are priority standard.

Which is not the same as being important to include in a desktop
installation.

> > - pcmciautils: PCMCIA is dead
> > - jfsutils, reiserfsprogs, ufsutils: obscure
> > - discover
> > - openssh-server: server, not desktop
> > - grub-legacy
> 
> These are all installed by d-i in various situations.

Many things are installed by d-i in various situations, and yet are not
on CD#1.

> > - loop-aes-utils: loop-aes is not supported
> 
> partman-crypto still installs this.

Seems like a bug...?  The package is orphaned and dm-crypt has support
for a compatible encryption mode.

> > - sharutils: obscure; we've had MIME for 20 years
> > - fakeroot, autopoint: more development
> > - mtools: obscure; FAT volumes are auto-mounted
> > - tcpd: server
> > - module-init-tools: transitional package
> > - linux-sound-base,
> > - gcc-4.[56]-base
> > - python2.6: 2.7 is already there
> 
> AFAICS, debian-cd does not explicitly include these, they're being
> pulled in by some other packages.

OK, but then we should work out how that is and fix it.

> > alsa-base, alsa-utils: rarely needed AFAIK
> 
> These are currently included in the desktop task.
> 
> alsa-utils stores mixer settings, so users are only puzzled by
> everything defaulted to being muted once, not every boot..
[...]

I know that.  But CD#1 is for the GNOME desktop, where PulseAudio stores
mixer settings.

Ben.

-- 
Ben Hutchings
Life would be so much easier if we could look at the source code.


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

Re: CD sizes again (and BoF reminder!)

[Christian PERRIER]

Quoting Ben Hutchings (b...@decadent.org.uk):

> > partman-crypto still installs this.
> 
> Seems like a bug...?  The package is orphaned and dm-crypt has support
> for a compatible encryption mode.


Given the level of attention which partman-crypto got during the
squeeze->wheezy release, I'd bet this is indeed a bug, yes.



signature.asc
Description: Digital signature