Original Message
Subject: [ubuntu/maverick] linux-linaro 2.6.35-1000.3 (Accepted)
Date: Fri, 06 Aug 2010 20:01:32 -
From: Ubuntu Installer
Reply-To: Ubuntu Installer
To: Tim Gardner
linux-linaro (2.6.35-1000.3) maverick; urgency=low
[ John Rigby ]
* LINARO: cleanu
On Thu, Aug 05, 2010, Christian Robottom Reis wrote:
> I was surprised to see that a
> fourth of the image is actually apt package caches and lists.
Yup, Martin Pitt worked on some APT patches to allow keeping these
compressed in the local disk.
--
Loïc
On Fri, Aug 06, 2010 at 05:38:56PM +0100, Dave Martin wrote:
> > Would the overhead be significant even if the tarball wasn't compressed?
> > I don't understand enough about tar's concatenate and delete performance
> > to risk a guess.
>
> tar's default internal blocksize is 512 bytes, so there wo
On Fri, Aug 6, 2010 at 3:15 PM, Michael Vogt wrote:
> You have the following options to make the on-disk file size smaller:
>
> * keep them compressed on disk (needs apt in maverick), you need to set
> """
> Acquire::GzipIndexes "true";
> """
> in /etc/apt/apt.conf.d/10keepcompressed
>
>
On Fri, Aug 6, 2010 at 2:30 PM, Christian Robottom Reis wrote:
> By touch I think you mean install, upgrade or remove, and of these I
> guess upgrade is the more common case; do you think it is?
I think you're right. This hits the end user more than first-time
installation - install and remove
On Fri, Aug 06, 2010 at 12:05:25PM +0200, Alexander Sack wrote:
> On Fri, Aug 6, 2010 at 11:57 AM, Dave Martin wrote:
> > On Fri, Aug 6, 2010 at 9:53 AM, Alexander Sack wrote:
> > > On Fri, Aug 6, 2010 at 3:28 AM, Christian Robottom Reis > >> Hi there!
> > >>
> > >>I unpacked our minimal rel
On Fri, Aug 06, 2010 at 02:16:00PM +0200, Martin Pitt wrote:
> Hello all,
>
> Alexander Sack [2010-08-06 12:15 +0200]:
> > > If we have to keep /usr/share/doc/ (for copyright notices and so on),
> > > maybe it would be feasible to replace each /usr/share/doc//
> > > with a tarball? This would eli
On Fri, Aug 06, 2010 at 10:57:21AM +0100, Dave Martin wrote:
> We could remove these files, but I agree it may be a false
> optimisation: the size of the release filesystem is no longer
> representative of the steady-state size of the filesystem when it's in
> use in this case.
Well, I think that
Hello all,
Alexander Sack [2010-08-06 12:15 +0200]:
> > If we have to keep /usr/share/doc/ (for copyright notices and so on),
> > maybe it would be feasible to replace each /usr/share/doc//
> > with a tarball? This would eliminate most of the overhead as well as
> > making the actual data smaller
Hello,
Dave Martin [2010-08-06 13:35 +0100]:
> Just to clarify my meaning--- I expected to have a tarball per
> package, not one massive tarball for the whole system... the cost of
> maintaining the latter would certainly get very unpleasant for people.
Hm, but then you wouldn't save a lot -- you
On Fri, Aug 6, 2010 at 11:16 AM, Zygmunt Bazyli Krynicki
wrote:
> On Fri, 2010-08-06 at 12:05 +0200, Alexander Sack wrote:
>> Out of interest, does anyone know why dpkg/apt never migrated
>> from the
>> "massive sequential text file" approach to something more
>> da
On Fri, Aug 6, 2010 at 1:16 PM, Martin Pitt wrote:
> Hello all,
>
> Alexander Sack [2010-08-06 12:15 +0200]:
>> > If we have to keep /usr/share/doc/ (for copyright notices and so on),
>> > maybe it would be feasible to replace each /usr/share/doc//
>> > with a tarball? This would eliminate most o
On Fri, 2010-08-06 at 12:05 +0200, Alexander Sack wrote:
> Out of interest, does anyone know why dpkg/apt never migrated
> from the
> "massive sequential text file" approach to something more
> database-oriented? I've often thought that the current
> system'
On Fri, Aug 6, 2010 at 11:57 AM, Dave Martin wrote:
> On Fri, Aug 6, 2010 at 9:53 AM, Alexander Sack wrote:>>
> * stripping /usr/share/doc out (but everybody knew that)
>
>
> > ack. we plan to do that using pitti's dpkg improvements; last time they
> > didn't land
> > in the archive yet, but I
On Fri, Aug 6, 2010 at 11:57 AM, Dave Martin wrote:
> On Fri, Aug 6, 2010 at 9:53 AM, Alexander Sack wrote:
> > Hi,
> >
> > On Fri, Aug 6, 2010 at 3:28 AM, Christian Robottom Reis >
> > wrote:
> >>
> >> Hi there!
> >>
> >>I unpacked our minimal release image and ran an xdiskusage on it,
> >
On Fri, Aug 6, 2010 at 9:53 AM, Alexander Sack wrote:
> Hi,
>
> On Fri, Aug 6, 2010 at 3:28 AM, Christian Robottom Reis
> wrote:
>>
>> Hi there!
>>
>> I unpacked our minimal release image and ran an xdiskusage on it,
>> mostly to see what we're shipping -- and I was surprised to see that a
>>
Hi,
On Fri, Aug 6, 2010 at 3:28 AM, Christian Robottom Reis wrote:
> Hi there!
>
>I unpacked our minimal release image and ran an xdiskusage on it,
> mostly to see what we're shipping -- and I was surprised to see that a
> fourth of the image is actually apt package caches and lists. Can we
Setting TERM to linux does not help.
I am wondering if it has anything to do with my kernel command line
"console=ttymxc0,115200".
Yong
On Fri, Aug 6, 2010 at 4:16 PM, Amit Kucheria wrote:
> cc'ing linaro-dev
>
> On Fri, Aug 6, 2010 at 10:59 AM, Amit Arora wrote:
> > On Fri, Aug 6, 2010 at 1:14
cc'ing linaro-dev
On Fri, Aug 6, 2010 at 10:59 AM, Amit Arora wrote:
> On Fri, Aug 6, 2010 at 1:14 PM, Yong Shen wrote:
>> Hi Amit,
>>
>> Clearly, we did not implement these nodes. See below.
>> r...@freescale ~$ cat
>> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
>> cat: c
19 matches
Mail list logo
