Home Home > Distribution > Factory
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Archive for the ‘Factory’ Category

« Older Entries
Newer Entries »

Guest Blog: Weekly Minutes from the Testing Team (Larry Finger)

May 1st, 2010 by

Guest Blog from Larry Finger

For general news about the openSUSE Testing Core Team, please see http://tinyurl.com/24n8ufe and the links within it.

This has been a quiet week for the team, at least as a group. Individually, we have been testing 11.3 M6 since its release on April 29. In addition, we are preparing for our next team meeting to be held May 3 at 17:00 UTC. If you interested in our group, please join us on the #opensuse-testing channel on the Freenode IRC Network -irc://irc.freenode.net/opensuse-testing.

In the testing front, 11.3 M6 now installs on x86_64 systems, which is an improvement over M5. There are two bugs on the “Most Annoying Bugs” list at http://en.opensuse.or /Bugs:Most_Annoying_Bugs_11.3_dev, both have been repaired. That web page also lists workarounds.

A member of the Testing Team, Bernhard M. Wiedemann,  has been preparing videos showing the steps for installation from various media. Links to these demonstrations are available at http://lists.opensuse.org/opensuse-factory/2010-04/msg00447.html

Posted in Distribution, Factory | Comments Off on Guest Blog: Weekly Minutes from the Testing Team (Larry Finger)

making of the openSUSE install video

April 29th, 2010 by

Videos of software can have many good uses. You can have tutorials or a quick-start how-to illustrated by a video that shows the steps you need to go.

However, creating such videos takes some effort. Especially hard to make is a video of an operating-system installation, which includes a bootloader and other low-level software where you can not run capture-software on the OS.

Being a member of the Testing Core Team, I wanted to automate the typical openSUSE installation workflow up to the point where the installed system first started, because if installation media would not get to that point, it could prevent testers to try the remaining software.

To do this automation, I employed KVM (the much fancied Kernel Virtual Machine). As it is a variant of QEMU, it also has all those many useful options to adjust its behaviour to ones liking. One of those options allows KVM to be remote-controlled via the management-console. You can (among others) send key-presses, move/click the mouse and capture screenshots.

Putting all this together, I got a series of many images. So the next logical step was to run ffmpeg2theora on those images to create with free tools and free codecs a .ogv video file that has an even smaller size and better quality than mpeg[124]. Plus it can be easily viewed in firefox&co at high speed.

The results can be seen on http://www3.zq1.de/bernhard/mirror/opensuse/video/

This is still work in progress. KVM might have issues. e.g today I found, that I could speed up the network from 290kB/s to over 30MB/s by changing the emulated network device model from e1000 to virtio. With this, a network install from a fresh proxy cache took only 34 minutes instead of 95.

There is some more info in  http://lists.opensuse.org/opensuse-factory/2010-04/msg00439.html

(note that my initial test-runs were flawed because they used old MS5 packages and thus hit well known bugs in those)

What do you think: What can I improve? Can this technique be put to other good uses?

Posted in Factory, Quality Assurance | Comments Off on making of the openSUSE install video

Guest Blog: Testing Team Minutes (Week 16)

April 23rd, 2010 by

Guest Blog from Larry Finger:

The openSUSE Testing Core Team (TCT) has been asked to contribute to the Weekly News on a regular basis. We are grateful for the opportunity.

The TCT is a group of 25 volunteers that are charged with helping the openSUSE developers test each new release. Our objectives and membership are given on our wiki site:

http://en.opensuse.org/OpenSUSE_Testing_Core_Team

The TCT was organized in the middle of the 11.2 development cycle, thus we are still learning our role; however, it is clear that we need the involvement of the openSUSE community at large to conduct proper
testing. That is why we appreciate the invitation to participate here.

In particular, the community can help in the following ways:

* Publish Bug Reports in the Bugzilla (http://bugzilla.novell.com/).

* Inform us of testing that worked. With this, we have an idea of the
test coverage.

* Participate in our regular IRC meetings. See http://en.opensuse.org/OpenSUSE_Testing_Core_Team/Meetings. During the  development phase of a new release, our meetings are held at 17:00 UTC on the Monday following the release of a new Milestone or Release Candidate. Accordingly, our next meeting will be on May 3, assuming that M6 is released during the week of April 26. The transcripts of previous meetings are posted on the site. If there is a topic you would like to see covered in an upcoming meeting, please send a private mail to user lwfinger on the openSUSE site. Our meetings are held on the
#opensuse-testing channel on the Freenode IRC Network -irc://irc.freenode.net/opensuse-testing. All are welcome.

Tags:
Posted in Distribution, Factory | Comments Off on Guest Blog: Testing Team Minutes (Week 16)

Call for testing: unzip feature

April 7th, 2010 by

Hello Planet!

Have you ever faced a bug like this bnc#540598 ?

When you create  zip archive with non-English filenames and try to unpack it on openSUSE, filenames within archive become unreadable. It can irritate, isn’t it?

It seems as if we found a solution for Russian language. We tested it and it works for us.

It would be helpful if some of you could test your local language. And check whether core functionality still works 😉

Here is a list of  languages that are potentially affected by this bug: Ukrainian,Belorussian, Bulgarian, Croatian, Czech, Estonian, French, German,Hungarian, Italian, Lithuanian, Latvian, Polish, Slovak, Spanish,Slovenian, Swedish.

So it is worth to test them in the first place.

The reproducer is pretty simple:

  • create zip archive on windows with file named in you local language
  • transfer archive to openSUSE system
  • unpack it
  • see if filenames are readable

What needs to be tested:

  • if this bug applicable to you language
  • if core functionality of unzip still works

Please share your experience by commenting on bug.

Package to test located in Lazy_Kent home project

Thanks in advance

Posted in Build Service, Desktop, Factory, Localization, Quality Assurance | 4 Comments »

How to Add New Packages to the openSUSE Distribution

March 23rd, 2010 by

I’ve added a new package (grub2) to the openSUSE distribution and like to share with you what needs to be done for it, I’m using the package “grub2” as example. To get a package in the distribution, it needs to be in the openSUSE:Factory project in the openSUSE Build Service.

  1. Get an openSUSE Build Service account.  It’s free, just go to the Build Service and register.
  2. Go to your “Home Project” and follow the link to “add a new package”, I use “grub2” as package and filled in the details.
  3. Now add all the files you need to properly build the package.  For openSUSE Factory, you need the spec file (grub2.spec), an empty changes file (grub2.changes) and all source files.
    1. Some of the next steps are done best by the openSUSE Build Service command line client osc, so you should install the current version on your system. If you’re running openSUSE, just do a “zypper in osc”, if you use another distribution, download it from the “openSUSE:Tools” project for your distribution (best way to find it search via our search interface for osc).
    2. I propose to check out the files with osc, e.g. “osc co home:a_jaeger grub2”.
    3. Use “osc vc” to add entries to the new changes file describing what you have changed in the package.
    4. Go to your “Home Project” in the web user interface and add “openSUSE Factory”  using “Add Repository” as build target.
    5. Build the package locally using “osc build”.  If it succeeds, submit all fixes with “osc ci” to the build service.
    6. Now it’s time to wait until the build succeeds on all platforms and distributions you have enabled – and if not to fix it until it succeeds.
  4. Tell the openSUSE Factory maintainers about the new package in an email to the opensuse-factory list with all details as explained here and discuss which devel package should be used for it.
    Note that all packages in openSUSE:Factory are developed in so called “devel projects”.  So, decide where your package fits best – or add it to “devel:openSUSE:Factory”. I choose the later.
  5. Submit the package to the devel project with “osc sr <your-home-project> <packagename> <devel-project>” and add a nice comment  (in my case “osc sr home:a_jaeger grub2 devel:openSUSE:Factory”).
  6. Once the submitrequest gets accepted, check that you are setup as maintainer for the package with “osc maintainer devel:openSUSE:Factory grub2”, if you are the maintainer, you have write and review access to the package.
  7. Submit the package from the devel project to openSUSE:Factory using osc. I did a “osc sr devel:openSUSE:Factory grub2 openSUSE:Factory”.
    Since the package gets submitted the first time, it will go through a good first review including a license check.  So, give the team a week or two for the review.  Eventually you’ll get noticed about the check in.
  8. Now you can update the package in the devel project at your own consideration and don’t forget to submit it timely again after testing to openSUSE:Factory so that people running Factory can use it.

I advise to read the documentation about Factory to understand the mentioned concepts and not just blindly follow my cook book.

Keep in mind that having packages in openSUSE is an honor and an obligation.  An openSUSE release gets fixes for 18 months and as a maintainer of the package, it’s expected that you take care of the package. With having it in Factory, please remember to update it in time for a release and keep in mind that we’re not doing any major updates in a released distribution.

Posted in Distribution, Factory | 2 Comments »

openSUSE Boosters update: build.opensuse.org improvements

March 16th, 2010 by

In January, the Build Service squad of openSUSE Boosters worked to improve the openSUSE Build Service web client experience.

One focus was to make it easier for project maintainers to review and accept package submissions from contributors.  As explained in detail in the Collaboration article, when a contributor has made a local change to a package in her branch of a project, she then submits a request to merge the changes back to the original project (‘osc submitrequest’).  This request is received by the maintainers of the original project, who review it, and then submit it onwards towards openSUSE:Factory, for example, where it is reviewed again.  This distributes the workload of assembling a distribution by using the ‘many eyes’ typical of Free Software development in a structured way.

Until now, the list of requests waiting to be handled was very basic, only showing that a request was made regarding a particular package.  It was necessary to use the osc command line client to actually review and accept or reject requests.

Accepting a submitrequest from the web client

The Boosters’ sprint resulted in a fully-featured web frontend, where the reviewer can check if a submitted package actually builds, the differences in the request, accept or reject with comment, and also immediately submit the changes onward to openSUSE Factory.

Checking that submitrequests build

Showing the changes in a submitrequest

Showing the changes in a submitrequest

Another focus has been to make the overall process of preparing an openSUSE release easier.  The release manager’s job involves bringing together the output of many Build Service development projects, making sure that they all build, and that they have submitted their latest versions from the development projects to openSUSE:Factory.  This is the Build Service collaboration model.  If packages don’t build for a milestone release, or are not submitted, then the release manager can only take the previous version or choose to exclude a package from the release, which doesn’t help in getting the distribution tested.

Factory Status showing packages from GNOME:Factory

Factory Status showing progress from GNOME:Factory

The new project status page gives a project maintainer, for example the openSUSE release manager, a bird’s eye view of what needs to be done in his project: a list of packages that are currently failing; where there is an outstanding submit request, where there are unsubmitted changes in the development project, and where there is a newer version available upstream.  With quick links to projects and packages of interest, and a powerful set of filters, a project maintainer can quickly see where there are problems then drill down into the details.

Filtering problem packages by development project

Posted in Boosters, Build Service, Factory | 1 Comment »

openSUSE-LXDE development status

March 1st, 2010 by

Ok people… openSUSE 11.3 Milestone2 has been released and quite soon we will have the Milestone3.

So now, after lot’s of promises, what is the status now?

IT’S DONE!

yes… it’s done… openSUSE 11.3 allow now to install LXDE directly from installation DVD or Net install. I’m sure all of you reading this post wants to try it, but for lazy people (and i know there are a lot of them outside), just click here and watch some pictures.

Can that be all? No of course not!

Just today i announced to opensuse-lxde and opensuse-factory mailing lists that we switched finally to pcmanfm2.

Even if that one is not yet stable, and even if it’s still on alpha release stage, it’s already feature rich and stable enoguht for daily usage. Of course bugs exist and you report is welcome, so we can fix them.

But it’s not enough, thanks to sidux lxde community we have a couple of nice tools: lxdm-conf and lxcc.

lxdm-conf as name suggest, it is a simple and powerful tool that helps you to edit lxdm settings without take care to manually edit /etc/lxdm/lxdm.conf file. This tool is already into repos.

lxcc instead is a small control center, written using python-gtk. It’s based on an idea of PCLinuxOS Community that wrote lxdecc using gtkdialog. Instead to port original lxdecc to openSUSE we choose to cooperate with Sidux on lxcc simply because gtkdialog looks to be a dead project. Lxcc is not yet into repos, so here a screenshot:

Schermata

And to finish a very good news. We are working on live cds. Yes, it’s taking looong time, but now we should be able to provide you better ISOs in shorter time since we moved from suse-studio to OBS kiwi system. Preliminary images can be downloaded from here:  X11:lxde (login required).

Most probably, a preliminary image will be published soon for a testing (based on openSUSE 11.2), in the same way, a Factory based live CD should be ready soon. Of course, i can’t forget, all that work on ISOs couldn’t be possible without the Dmitry serpokryl help (The author of SOAD).

I hope you’ll enjoy openSUSE-LXDE experience. So please, test test test and test it again. We have to provide the best LXDE ever!

Posted in Accessibility, Desktop, Distribution, Factory, lizards.openSUSE.org, openSUSE 11.2, Packaging, X.org | 2 Comments »

Hermes Twittering about openSUSE Factory

February 1st, 2010 by

I'm going to FOSDEM, the Free and Open Source Software Developers' European Meeting

Last week we updated Hermes on our production servers, they’re running a version now which will become a first Hermes release. I hope to get it packaged and released this week to present it on FOSDEM where I’ll give a talk about Hermes. Don’t miss it if you’re interested in this useful technology.

There went in a lot of technical improvement and bugfixes which one gets aware of if a system like Hermes runs in production for quite some time, such as missing indexes here and there which slow down the database and stuff like that. But that is another story.

What I actually wanted to talk about is the the fact that Hermes now is twittering now for you. You can follow it under the OBSHermes Twitter account. Hermes currently twitters about version updates of all packages in the openSUSE Factory project, so this is your tweet if you want to be at the bleading edge of Factory.

It is configurable for the administrator what actually is twittered. Is there other useful information around the openSUSE project which you would like to see twittered about? If so, please let me know.

Tags: , ,
Posted in Boosters, Build Service, Factory | Comments Off on Hermes Twittering about openSUSE Factory

LXDE: Mission (almost) Accomplished

January 15th, 2010 by

Sorry if i missed to inform you since September but i passed a very bad period, (including a breakage of my hand and with my ex-girlfriend), but now i’m definetly better, so here i am to inform you about some wonderful progress.

first of all:

LXDM has been released

exactly, LXDE Desktop Manager has been released and looks to be fully working 🙂

2nd) Upgrades, upgrades and more upgrades

several new package version has been released, including lxappereance, lxmusic, lxpanel and so on.

3rd)  We are going to fix a small not-portable issue due to X-KDE-SubstituteUID

check bugzilla #540627 for more informations, what you want to know any way, is that we fixed .desktop files to allow to run applications as root even outside GNOME or KDE

4th) Factory, factory, factory

LXDE is into openSUSE_Factory now! yes, that means lxde will be installable on 11.3 from OSS repo, and probably from DVD.  I actually submitted lxde pattern request and yast2 pattern icons are already into yast svn. So people.. PLEASE TEST AND REPORT!!

5th) OPENSUSE-LXDE MAILING LIST

yes people, we have a new opensuse-lxde mailing list now! Please subscribe to opensuse-lxde@opensuse.org for help, support and development… i’m waiting for you!!

6th) Not official support on openSUSE <= 11.1

That’s not my choice but it’s due to gtk changes, because of that X11:lxde will no more take care of failures on suse <= 11.1. new lxde packages requires gtk2 >= 2.16.0 and backport is impossible (see lxappereance for example).

I think that’s all, if not i’ll write a new blog post, but now i must go to my work or i’ll be fired!!

Regards

Andrea (your favourite openSUSE-LXDE admin!)

Posted in Distribution, Factory, lizards.openSUSE.org, Marketing, Miscellaneous, Packaging, X.org | 2 Comments »

New pm-utils for openSUSE

November 25th, 2009 by

The current SUSE version of pm-utils is pretty old. Rpm -q said somethink like 0.99.4.20071229. And it also contains a hacked support for s2ram, which is nowadays in upstream version. There has been also a bnc#378883 – Need an updated pm-utils I started a work on this week.

A new pm-utils package for openSUSE is available in home:mvyskocil:branches:Base:System. The HIBERNATE_METHOD is no longer supported, because upstream version contains something better – modules. There are three methods how to run software suspend on Linux

  1. kernel – plain echo something > /proc/something
  2. suspend – tool contains a lot of quirks needed on some HW
  3. tuxonice – kernel and userspace support for hibernate, not in upstream kernel, nor in openSUSE

Because there are too many ways in current Linux world, pm-utils simply support all by specific modules stored in /usr/lib/pm-utils/modules.d, which implements appropriate functions for suspend/hibernate and hybrid. The SUSE default is uswsusp module calls s2ram/s2disk/s2both from software suspend project, because it should be considered as a safe default.

If you want to use different module, you can add a config file somewhere to
/etc/pm/conf.d/
and set the value of SLEEP_MODULE.

# The default sleep/wake system to use. Valid values are:
# kernel The built-in kernel suspend/resume support.
# Use this if nothing else is supported on your system.
# uswsusp If your system has support for the userspace
# suspend programs (s2ram/s2disk/s2both), then use this.
# tuxonice If your system has support for tuxonice, use this.
#
# The system defaults to "kernel" if this is commented out.
SLEEP_MODULE="uswsusp"

You can type more methods, which will be called, so SLEEP_MODULE=”kernel uswsusp” will use kernel and if it fail, or not available, it call uswsusp. Please note that config files are read in C sort order, so names matters.

So please install new pm-utils and test it and tell me if you found any regression (please inform me about a regressions only, I cannot fix generic suspend problems).

Posted in Base System, Factory | 2 Comments »

« Older Entries
Newer Entries »