yesterday I installed KDE-LiveCD-MS7 on my Laptop(FSC Amilo Pro 2030)
and took notes
what I liked (will usually not be seen on bugzilla):
new Live-CD->USB http://en.opensuse.org/Live_USB_stick#openSUSE_11.2
partition manager UI allows "which partitions to use for install" -
first time I did not have to use expert mode when there was already
something on the HDD.
function keys for brightness/volume working out-of-the-box even in
Live-system
default sound scheme
suspend-to-* working in installed system
===
problems (did not check bugzilla for those yet):
minor: syslinux suggested 800x600 resolution but internal TFT has 1024x768
KDE-live-system: S2RAM fails to resume (black screen, does not shutdown
on power-button) ; works after installation
minor: CD-tray was ejected after install from USB
keyboard was back at us after install (I set german in syslinux) ; yast2
language helped
prepare_preload on ext4 printed messages to console
"/var/tmp/kdecache/...data has tail _and_ normal blocks"
wontfix: b43 (WLAN) firmware missing -> install_bcm43xx_firmware helps
NetworkManager failed to assign ipv4 addr/nameserver for eth0 after
cable hotplug (only ipv6 from radvd)
NetworkManager-0.7.1_git20090811-1.2.i586: system standstill after
ethernet cable disconnect
Segmentation fault in yast2 online-update-configuration (Register.ycp)
=> advanced/register => configure now => +Hardware Profile => Details|Next
no automatic updates? has useless link to novell.com? ; re-tested after
update to factory. still there.
yast2 online repositories links to 11.1
factory seamonkey-2.0b2-1.3 /usr/lib/seamonkey/seamonkey-bin: symbol
lookup error: /usr/lib/seamonkey/seamonkey-bin: undefined symbol:
gdk_x11_window_get_drawable_impl -> zypper install gtk2 helped, so it
was a missing dependency.
seamonkey -mail can not save this mail to IMAP sent folder for some reason
also already had two more system crashes, one of which needed a manual
fsck.ext4 run afterwards. No backtrace available since I was in X11 and
syslog had not caught it.
===
on my Phenom X4 + GeForce 9400 GT:
Live-CD: LCD screen loosing signal randomly (approx 2/minute)
overall there are still plenty of issues to be solved. I will probably
retest with a later pre-release and/or test MS7 on my other laptop.
You are welcome to confirm and file the above issues in bugzilla.
Ciao
Bernhard M.
--
To unsubscribe, e-mail: opensuse-testing+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-testing+help(a)opensuse.org
oS Testing Core Team,
Since it looks like an IRC meeting may be a little while away, perhaps
we can deal with more things on the mailing list before we lose too
much momentum. I think the one of most important things we can do is
decide what we want to test against and when we want to move on from a
given release. This then gives all the team members a rough schedule
to follow, and it also lets the dev team know what to expect from us -
at least as far as testing the distro on real hardware goes.
A quick and dirty general roadmap of a release looks like this:
1. Check-in new updated packages
2. Decide what new features will be targeted at the release
3. Develop new features
4. Progressively freeze elements [Milestone 5 & 6]
5. Final Round of Testing [Release Candidates]
6. Post-release critical bug-fixing [Gold Master]
The points we can test are:
1. Factory, as components offered on top of a stable release (ex:KDE:Factory)
2. Factory, as a complete rolling distribution testing updates as they come
3. Factory, taking regular builds of our own choosing (ex: Every
Thursday's build)
4. Official Snapshots, such as Milestones/RCs/GM
IMHO, I think the oS TCT should also test the final release. Since
the team was formed pretty late in the roadmap, we should run the
final release for at least 2-4 weeks to help knock out bugs that
squeaked through. This should be done for 11.2 at least.
Looking ahead to 11.3, things are pretty wide open. Judging from some
of the changes in Factory and comments online, I believe that openSUSE
developers would really appreciate if more people ran Factory.
However, there may be a reduction in our effectiveness if we end up
fighting against obvious but big bugs (bad kernel builds,
uninstallable images, etc.). Ideally we would thoroughly test both
Factory as a distribution and Milestones, but that's probably not
feasible team-wide.
My first instinct is to test crap out of all the snapshots as that
will also provide the simplest scheduling mechanism - We just test a
given snapshot until the next one comes out...thus we test a final
release until the devs deliver Milestone 0 of the next version. We
can also leverage that time between GM and Milestone 0 to review the
last run and adjust our procedures accordingly.
However, we should decide as a team what to focus on - even if it
means splitting the team down the into a Snapshot Team and a Rolling
Release Team.
Refilwe
--
To unsubscribe, e-mail: opensuse-testing+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-testing+help(a)opensuse.org
>
> In my experience, the only real variances in speed are for the
> startup, as distributions use different methods and start different
> processes. With regard to things such as launching basic applications,
> I've never seen a serious statement about this backed up.
Have you ever seen the opposite? Has anyone tested the distributions
and found they are all about the same speed? This too would be useful
data.
>
> There will be variances if you are using different desktop
> environments, and those kind of results are interesting to see --
> particular with regards to memory. Lubos Lunak (an openSUSE/KDE
> developer) did some testing into this a _long_ time ago[1].
I'm confused. I followed the link and read an excellent article about
excess fonts and application slowdown. And in fact, if different
distributions have different amount of fonts, that would be relevant
and impact performance. Is this what you mean?
Also, I assume without knowing that there are other ways distributions
can effect the speed of their applications (even if just by installing
different versions with different startup options). But if everything
is the same speed, I'll just report that.
>
> However, if you are launching the same application in the same desktop
> environment on a different distribution (making sure it is the same
> app -- which wouldn't work for i.e. searching), I very much doubt
> there will be a significant or material difference. But there are some
> possibilities, and it might be interesting to just verify or disprove
> that, but only if you would investigate why ;-).
>
> Anyhow, with regard to distribution boot times, I ran a test some time
> ago on the differences between the boot times from some of the popular
> distributions[2]. An update on something like that probably would not
> take too long and it would be interesting.
Yep. And one thing I'd very much like to do is get the data to Suse developers.
>
> [0] http://www.kdedevelopers.org/node/1654
> [1] http://ktown.kde.org/~seli/memory/desktop_benchmark.html
> [2] http://francis.giannaros.org/blog/2007/08/23/comparing-distribution-boot-ti…
> --
> Francis Giannaros http://francis.giannaros.org
I love these suggestions. Anyone have any more?
--
To unsubscribe, e-mail: opensuse-testing+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-testing+help(a)opensuse.org
Randy Appleton wrote:
> Hello.
>
> I'm a computer science professor at Northern Michigan University. I
> found your email address at
> http://en.opensuse.org/OpenSUSE_Testing_Core_Team. I'm considering
> offering a student research project and thought you might be able to
> provide some input. Or, could you suggest someone better to contact?
>
> Has anyone timed various operations in Suse vs Ubuntu vs Fedora? I'm
> curious if it's quicker to log in, find a file, open a document, etc. in
> Suse, Ubuntu or Fedora?
>
> Does anyone already have data on these questions? Or, if we do the
> benchmarking myself, is anyone interested in the results? Finally, is
> there some particular operation you'd like to see benchmarked?
I'm copying this reply to the opensuse-testing mailing list.
I have heard anecdotal reports that distro XX is faster than YY while
doing ZZ, but I am not aware of any properly designed studies. I am
confident that the other members of the Testing Team will post such
studies if they exist.
Certainly, the distro packagers would be interested in the results. My
suspicion is that the most important factor will be the kernel itself,
and that there will be only small differences when all are using the
same kernel version; however, that is certainly a testable hypothesis.
Larry
--
To unsubscribe, e-mail: opensuse-testing+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-testing+help(a)opensuse.org
Hello,
few days ago Holger asked for some discussion of future work of openSUSE Core
Testing Team, but I have not received any message regarding this topic. Well,
I'm not professional software tester, so I would appreciate some introduction
or short how to from someone more skilled.
According to Holger's first mail, where he welcomed us in the team he
mentioned "What I personally do expect from the new openSUSE Testing Core is
not mainly executing test cases. From my point of view the team is responsible
to decide what to test and how to test. This can be done by creating test
plans containing test cases either developed by the developers itself or
members with good knowledge in that specific area. Good contact to the
development teams would for sure support that."
It sounds good, but it does not say to me, where and how to start. I'm afraid
because of great time shift between Europe and America we are not able to meet
in #opensuse-testing IRC channel. I'm not absolutely sure what is difference
between https://bugzilla.novell.com/tr_show_run.cgi?run_id=19162 and
https://bugzilla.novell.com/tr_show_run.cgi?run_id=19163 - it is for different
versions, yes, but I mean in basic idea. After short experimentation I hope
I'm familiar with this technology, but short how to would be nice. :-)
Finally, here is my basic idea ("the null hypothesis") how to start work of
openSUSE Core Testing Team. I try to start the discussion, not to make exact
plane of the work.
Everyone of us is interested in different areas (I suppose), so let's divide
the field of all applications. For example I use KDE, I like its graphical
software (digiKam, ...), I use, I'd say, "scientific" applications (R, Kile,
...) and I run a LAMP server. So I would test basically this class of
applications. And like this we can divide whole distribution. Some groups,
like games :-), might be wished by more people, but I hope we will be able to
cover whole field. I hope everyone of us has some deeper knowledge about his
favorite applications, so he can say what should be tested, what might be
problematic, what is important and so on. I have sens our role should be
partially coordinating the testing, shouldn't it? Is it usable basic idea?
In Testopia we can then create plans similar to those for YaST (already
presented). It can be the coordinating place, right? But who will follow the
plans we make in Testopia? Only our group plus developers?
Finally, I hope our team will help openSUSE to be the best Linux distribution.
:-)
Have a nice day,
Vojtěch Zeisek
Hello,
have You ever tried to install openSUSE to computer with already installed
Windows and use YaST automatic division of hard disc (accepting defaults)?
Although I do not have Windows, I have seen it on several computers and I was
not satisfied. Proposed solutions are very strange and complicated. For
example I had an older computer with 2 windows hard discs (one big FAT
partition on each), YaST tried to shrink both discs and create 4 partitions
(swap, /, /home, /usr), on my friend's laptop it tried to delete both Windows
partitions (disc was divided to Windows system a data), but aim was to install
whole openSUSE instead of only one Windows partition (dualboot).
Is it only my sense or do You have similar experience with automatic disc
division during installation? More over I still have sense that installation
from Live CD is even more strange in this way...
I use expert mode and it is OK, but for "an average user" it is very
confusing. I know people understanding basics of disc partitioning, but not
understanding YaST's proposals...
Have a nice day,
Vojtěch Zeisek
While we already have a list of the most annoying bugs causing hazards
or blocking users I wanna encourage something new:
A list of vital-issues which are of elevated importance to desktop
users. I would regard the following as candidate issues:
* Firefox: bookmarks can not be added any more (bug 540629)
* Thunderbird: can not select default browser (bug 540631)
* pairing of bluetooth devices does not work in user mode (bug 513123)
--
To unsubscribe, e-mail: opensuse-testing+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-testing+help(a)opensuse.org
Have created a vital issues sample list at
http://en.opensuse.org/Bugs:Vital_Issues_11.2_dev;
You are welcome to add your own features!
--
To unsubscribe, e-mail: opensuse-testing+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-testing+help(a)opensuse.org
