[Lubuntu-qa] Final Freeze for Ubuntu 13.10 (Saucy) at 2100UTC today - Live USB test

Sat Oct 12 14:30:55 UTC 2013

Hi,

Not on a machine with normal USB 2.0. Live USB is then much faster than running from a
Live CD connected to an IDE port (while running from Live connected to SATA
should be faster than a Live CD running from a reader connected to IDE...).

I said it was sluggish *compared to* the one version I work with which has swappiness
controlled.

I have rebooted with a persistent mode and the sysctl file added to the system, and now
it behaves "normally".

It would be nice if other persons try the setup I talked about, after trying the normal
setup.

For now after having added the file to /etc/sysctl.d  and rebooted, I am partitioning the
hard drive, having Firefox launched and Abiword as well, and all react in a good span of
time, almost instantly.  

Once the partitions prepared I'll do a reboot to have a fresh session and will start
installing and I'll take some screenshots with htop running along the install process and
upload them to a web space.

Regards,
Mélodie

On Sat, 12 Oct 2013 15:18:19 +0100
Phill Whiteside <PhillW at Ubuntu.com> wrote:

> Running from live usb will be slower than running off the hard drive as an
> installed system.
> 
> Regards.
> 
> Phill.
> 
> 
> On 12 October 2013 14:39, JM <meets at gmx.fr> wrote:
> 
> > Hi,
> >
> > As I am reading this message I feel confused somehow : have some clear
> > step-to-step
> > instructions been given? If not is it possible to get some (and not too
> > long to read if
> > possible)?
> >
> > I am presently testing the Lubuntu Saucy updated with zsync as of
> > yesterday evening Paris
> > time, which I have installed with USB GTK Creator from withing a Ubuntu
> > 12.04, and trying
> > to see if I can get a boot with persistency.
> >
> > The Live USB is running on a nice P4 with 4 GB RAM CPU 2.8 Ghz dual
> > core/hyperthreading,
> > integrated Graphic Intel, and it seems more sluggish than it should be on
> > a machine with
> > that much resource.
> >
> > So, in few words, what about the testing should be prior tested, exactly
> > how, and within
> > how much time? (I'll report on another thread later, of course).
> >
> > Regards,
> > Mélodie
> >
> >
> >
> > On Fri, 11 Oct 2013 23:48:25 +0100
> > Phill Whiteside <PhillW at Ubuntu.com> wrote:
> >
> > > Hi,
> > >
> > > I know full well that I'm no longer allowed on this area, but the thought
> > > of Ubiquity being launched with such a, IMHO, serious bug does lead me to
> > > ask that the bug be allocated to some one and the testers are asked as to
> > > how we can provide data.
> > >
> > > I'm going to step out of line and explain a little behind the bug....
> > > Asking bug reporters generic questions is not the correct way to deal
> > with
> > > installer issues. We are testers and *you* good people have to let us
> > know
> > > what further we can do to provide information. Commenting on a bug "we
> > need
> > > more information" is of no use to either the people reporting the bug,
> > nor
> > > those who need the additional information to track it down.
> > >
> > > Having Nick let me know a wiki link for such things should have been done
> > > long ago. You asked for installer bugs and that they would be top
> > > priority?... Well, here it is with no one allocated to it. Having a name
> > to
> > > a bug does encourage the testers as they see a 'person' and not a blind
> > > bug. This allows the person looking after the bug and the testers to be
> > > able to talk to humans.
> > >
> > > Regards,
> > >
> > > Phill.
> > > 1. https://bugs.launchpad.net/ubuntu/+source/linux-ppc/+bug/1220165
> > >
> > >
> > > On 10 October 2013 18:09, Adam Conrad <adconrad at ubuntu.com> wrote:
> > >
> > > > [ This is a shameless copy-and-paste from last year ]
> > > >
> > > > For the timezone challenged, as of 2100UTC today, the archive is
> > > > officially fozen in preparation of release candidates and the
> > > > final release of Saucy Salamander in a week.  This is three
> > > > hours from the time I hit send on this email.
> > > >
> > > > Uploads from here on in should fall into the following 4 bins:
> > > >
> > > > 1) Installer/release-critical bugs that absolutely MUST get fixed
> > > >    lest we risk shipping a broken image that turns computers pink
> > > >    or sets them on fire:  Please contact the release team about
> > > >    these bugs and upload (well-tested) solutions ASAP.
> > > >
> > > >    Last minute hardware enablement fixes, and pretty much anything
> > > >    installer related that is auditable and testable also falls in
> > > >    to this category, as our best installer testing comes in the
> > > >    next few days, historically.
> > > >
> > > >    Some people may have noticed that we're also in the process of
> > > >    spinning up a new port right now (our timing is impeccable, is
> > > >    it not?), so uploads with clear and targetted FTBFS fixes for
> > > >    arm64 will continue to be accepted for seeded packages until
> > > >    Sunday night, and for unseeded pretty much right up to release.
> > > >
> > > > 2) Non-release-critical-but-nice-to-have bugfixes:  These are
> > > >    fixes that you would absolutely feel comfortably about doing
> > > >    as an SRU but not necessarily destabilising the release process
> > > >    for.  Again, contact the release team, and we may slip some of
> > > >    these in, while asking you to defer the rest to SRUs.
> > > >
> > > > 3) Feature additions, massive code refactoring, user interface
> > > >    changes, non-typo string changes:  Just don't upload these, or
> > > >    ask about them.  The time for them came and went long ago.
> > > >
> > > > 4) Updates to non-seeded packages:  Technically, unseeded packages
> > > >    don't freeze until pretty much right before release.  While this
> > > >    is true, we may still try to talk you out of pushing some huge
> > > >    new upstream version of something, or start a library transition
> > > >    at the zero hour.  We're only a week away from opening the next
> > > >    release, a bit of patience (or prepping in a PPA, etc) might be
> > > >    a decent plan.
> > > >
> > > > Here's hoping everyone gets on board with testing images, helping
> > > > to fix absolutely critical bugs, donating spare creative cycles to
> > > > the release notes, and any other way we can all contribute to yet
> > > > another great Ubuntu release.
> > > >
> > > > ... Adam
> > > >
> > > > --
> > > > ubuntu-devel-announce mailing list
> > > > ubuntu-devel-announce at lists.ubuntu.com
> > > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
> > > >
> > > > --
> > > > https://wiki.ubuntu.com/phillw
> > > > <https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce>
> > > >
> >
> >
> > --
> > JM <meets at gmx.fr>
> >
> 
> 
> 
> -- 
> https://wiki.ubuntu.com/phillw

-- 
JM <meets at gmx.fr>