Motivation
Sometimes, there is a need to check some patch in the installation system. Of course, we have an article that describe how to Create a Modified Installation System but this one takes a lot of time to prepare, you need a remote server and several things can break.

You can also use Driver Update, but that expects you are able to build RPM with the changes you want to test.

Here you can see the simplest way...

Starting-Up
Start installation from media by adding startshell=1 to the Linuxrc commandline. This will make installation open a shell window before starting YaST/Installer.

You can also boot directly to the installation without adding startshell=1 to the command line but it that case you can't change files that are loaded when the installer starts. Your choice :)

Preparing Installation System
By default, the installation system is read-only but we can cheat it ;)! Let's assume we want to change some YaST script in /usr/share/YaST/clients/ directory in this example.

# The only writable directory is /tmp (and /var...)
cd /tmp
# Copy all clients to /tmp
mkdir clients
cp -ar /usr/share/YaST/clients/* /tmp/clients/
# Bind the writable directory to the original location
mount --bind /tmp/clients /usr/share/YaST/clients

Now you can edit, extend, remove, compile ... etc. the writable clients directory. Hint: If you want to start network (and your network supports DHCP) to copy the patched sources using network, just simply enter dhcpcd eth0 (or similarly according to your current setup).

And ... that's all folks!

Continuing with the Installation
If you have used startshell=1, just simply enter exit command or press Ctrl+d.

"The researcher, Jim Salinger, concluded:

It will mean either there will be pubs without beer, or the cost of beer will go up.

If that sentence doesn't sharpen the focus on the climate change debate, frankly, I don't know what will."


http://www.guardian.co.uk/environment/blog/2009/sep/16/climate-change-beer-quality

(Yes, dear planet reader, this is opensuse-related ;-) )

Amazon's Product Advertising API (PAA) lets you search pretty much everything they offer. But on August 15 they started requiring that all requests to the API be signed with the developer's Private Key. Any client-side software using the PAA directly, including website scripts, Firefox extensions, and desktop applications, would have to distribute their Private Key to all their users to sign the requests. But as you would expect, the license agreement for the API states

a private key...is for your personal use only and you must maintain its secrecy and security.

Others have written about how the PAA license agreement bars its usage on mobile devices. But in fact, it bars it from any client-side software on any device. Or at least from software you want to distribute. You can work around this by hosting a server to sign requests for your users, keeping your Private Key private. But anybody could use your service, pretending to be your client software if necessary. And you could wind up signing requests for half the Internet. The signing requirement benefits nobody. It impedes developers, turning them off from creating applications to serve users and send customers Amazon's way. Amazon should acknowledge its mistake with this policy and reverse it. Thanks to James Vasile for reading drafts of this.

It has been about half a year since the last release, but finally, over a hundred git commits later, we have version 1.3.0 of the radeonhd driver.

You may think that a release "cycle" of 6 months is... not that much. However, as most open source projects radeonhd is pretty much understaffed. Together with lots of additional work on Novell's side (which of course reduces the amount of time Egbert and I can spend on radeonhd) it took us a while to finally find some time for polishing. Because 2D acceleration is active by default now on (almost) all chipsets, we were seeing more regressions than usual.

Never mind, you're probably more interested about the new release. These are the main changes:

• Added support for RV740, M92, M93, M97.


• Added more support for HDMI audio, XVideo color spaces, backlight control.


• Added support for power management.


• 2D acceleration (EXA) is enabled by default now, except on RV740.


• Tons of bug fixes (AtomBIOS, Cursor, DDC, EXA, LUT, MC, Quirks, RandR).

For more read the Phoronix article, the announcement mail or the README of the driver.

Since today is the big day when KDE trunk starts to depend on Qt 4.6, Raymond Wooninck (tittiatcoke), community packaging hero, has worked to provide packages of the unreleased Qt 4.6 in the openSUSE Build Service.

If you want to develop KDE trunk without the hassle of compiling Qt, you can use these packages (openSUSE 11.1). We'll be updating them every week to stay current as Qt 4.6 nears release. Please keep in mind that we're not responsible if you install them and your system KDE packages and anything else that depends on Qt stops working (although we will help you put things right, and the trolls will probably want to know about binary-incompatibility problmems) and when 4.6 is released, it will move into the KDE:Qt repo.

I did an Unconference at openSUSE Conference 2009 titled: Roads Less Travelled – Making Technology Previews succeed“.  More number of people than I had expected participated in the unconference session. I wanted to make the discussion notes (rough) available to a wider audience so that we could act on some of those:

Often Technology Previews are not solving their purpose. The objective of this session was to discuss, find out how we could get better feedback on Technology Previews and make them better.

The discussion is focused primarily on these areas:

• Advertise the feature through proper channels, places
• Make it easy enough for users to try out and provide feedback
• Make it less risk-prone
• What stops users from trying out?
• Provide better documentation?

Key discussion points, suggestions:

• Announcement in opensuse.org main page/wiki could grab the attention of community members who could help test Technology Previews.
• Reduce hassles in providing feedback. For e.g Perhaps facility without authentication/Single-signon?
• Easy ways/methods to provide feedback/input
• Bug/Issue reporting made easy, command line tools?
• Text area to provide feedback (as opposed a authentication based system).
• Create a dedicated page for preview for e.g. previews.opensuse.org
• irc channel for previews? (Discussion on all TPs, User testing one TP might get interested in another)
• Announcement in openSUSE Weekly news could help
• More Blogs, Articles, Whitepapers etc.. (blog entries should have provision for giving comments)
• Perhaps, try to get some help from documentation team?
• Provide instructions, mechanisms to safely try out without breaking things.
• Additional information about new technology while the community tries to use the old technology For e.g. while a user tries to do nfsv3 mount providing an informational message that NFSv4 is available and can be used
• Suggest using a VM
• Caution about what might break and what might not (Make community feel less riskier to try out).

Please feel free to comment on what might work and if you have any more suggestion.

The short presentation I used to introduce the topic can be found here: http://files.opensuse.org/opensuse/en/d/de/Roads_Less_Travelled.pdf

In one hour (12:30 US Pacific time, 19:30 UTC), we'll be holding our cycle-ly planning meeting to make some plans for the next Tomboy release.

If you want to comment, listen, volunteer, or heckle, please join us in #tomboy on GIMPNet.

Oh, by the way, if you've been wanting to follow Tomboy updates on Twitter but you find me way to garrulous, you can now follow @tomboy for some peace of mind. We have @tomboy on identi.ca, too.

Just a quick note to everyone using factory and wonder what patterns-openSUSE-kde4_basis is all about: our patterns install packages now.

To explain this change, I need to get a bit back in history: In openSUSE 11.0 we did a change that is still significant: we do no longer install patterns. In older releases, when you installed a “KDE Desktop” or a “GNOME Desktop”, yast would save that information as “pattern”. Patterns are basically groups of packages, but they can also depend on other patterns. They have a clear semantic when you install: “KDE Desktop” -> kdebase4-workspace, kdelibs4, amarok, …. Some describe them as “Macros for packages”. But there is still no clear semantic on removing a pattern as this relation between “KDE Desktop” and amarok is only in one direction. If you remove “KDE Desktop”, it’s not clear if you want to remove amarok too or if if should stay on your LXDE. So we decided to go away from installing patterns to make this clear: There is no way to remove a pattern as it’s never installed. It’s only “satisfied”, meaning a pattern can express that it’s not satisfied without amarok installed. So if you decide to remove amarok, the pattern will be left unsatisfied (appears as not installed).

As I said: openSUSE 11.0 and 11.1 do this and there are little problems associated with it. But now that we support “zypper dup”, it came clear that you will not get the same “KDE Desktop” on 11.2 if you do an update or an installation. This is kind of okay, but not how it should be: most users see a distribution upgrade as an installation without the need to start from scratch. The reason for this difference is that there is no information left that you have a “KDE Desktop” after you changed repositories (patterns only appear in the repository, not in the system). Now assume the 11.2 “KDE Desktop” needs dolphin too, otherwise you get only an ugly gray square (not true, but we assume it). The solver will see amarok and update it to the newest version, but as it doesn’t see a “KDE Desktop”, it won’t install dolphin.

So for openSUSE 11.2 I changed the patterns to generate packages with cryptic names to install along with the pattern. So if you install “KDE Desktop” on 11.2, it will install amarok, dolphin and patterns-openSUSE-kde4_basis. If you do zypper dup on openSUSE 11.3 (or factory in january) the solver will see patterns-openSUSE-kde4_basis and know the new requires of the new version and install e.g. choqok.

That doesn’t solve the 11.1->11.2 update case, but after updating to 11.2, you can reselect the patterns you want and you can be sure they will stay from now on. And perhaps we do an online update for 11.0 and 11.1 that will add patterns packages to the most prominent use case: the desktops.

Alright. Just out of curiosity, I felt like finding out what the numbers show for South America compared to other regions in the Ambassadors Program of openSUSE.

As a reminder, the goals of the Ambassador Program are:

• Act as an evangelist for openSUSE to the public.
• Mentor new users and contributors.
• Support openSUSE at local events.
• Promote use of openSUSE and contributions to the openSUSE Project.
• Have a lot of fun!.

So, checking out the Ambassadors List, I got for South America:

• Brazil = 6.
• Chile = 3.
• Peru = 3.
• Argentina = 2.
• Colombia = 2.

Brazil is doing great here, doubling any other country’s Ambassadors number in the region. No doubt it’s not just users who are pushing Open Source out there but also their government and enterprises (example:Fisl), and I am glad openSUSE is a real choice for them. Compared to Europe, I believe statistical numbers are still OK for us since the truth is that openSUSE is just ranked in the top five of the most popular Linux flavours in Chile, maybe it’s the same in other South America countries. So, Ambassadors for Europe (some countries only):

• Germany = 8.
• Spain = 6.
• Austria = 4.
• Italy = 3.
• France = 2.

As for North America, we have got:

• USA = 15.
• Canada = 3.
• Mexico = 3.

I even did a “quick and dirt” chart with OpenOffice’s Calc so you can have a graphical idea of our numbers around the world:

For more information, please, visit the openSUSE Ambassadors section.

Have a lot of fun!.

It's been just over five years since Alex Graveley made the first commit to Tomboy CVS, unleashing a brilliantly simple note-taking application for people who just wanted to Get Stuff Done.




Three years ago (right after I joined the project), Tomboy became a part of GNOME 2.16. It was about this time that Boyd Timothy joined the fun and became a co-maintainer with Alex. Much of the polish in Tomboy and many of the features you take for granted such as notebooks, synchronization, and bulleted lists appeared during his stewardship. After helping with sync, I was "promoted" to co-maintainer, too.

After Boyd and Calvin Gaisford (of Giver and Tasque fame) left to start their own company last year, I was left as the sole maintainer. I'm trying to do my part to build on the legacy left by Alex and Boyd. Fortunately for me, Tomboy seems to attract cool people like Chris Scobell, Stefan Schweizer, Benjamin Podszun, and dozens of others who have contributed major features and fixes.

One of the funny little things that tends to come up at Tomboy planning meetings is the version number. Tomboy's been around for five years now, and really it's been a pretty solid app for the majority of that history, especially once it became part of the GNOME desktop. So why is it versioned like some alpha product?



Tomboy runs on every major operating system, is used by 50 kabillion people every day [citation needed], and even if we have more grand plans, Tomboy today really does help people Get Stuff Done.

So we're calling our new stable release 1.0, the first release of the 1.0.x stable series. The next big stable release will be 1.2, etc etc. I hope this arbitrary change will instill a sense of confidence in users, and maybe even get people thinking about what "Tomboy 2.0" might mean.

Here's what's new in Tomboy 1.0 since the 0.14.x stable releases:

• WebSync add-in lets you synchronize your notes with the upcoming Tomboy Online web service, your own server running Snowy, or any other server implementing the new Tomboy Web REST API, which will soon include Ubuntu One and Midgard. Big thanks to Rodrigo Moya and Stuart Langridge from Canonical for their help on this.
  
• NoteDirectoryWatcher add-in from Michael Fletcher (disabled by default) finally lets you edit your note files outside of Tomboy safely, even while it's running, opening the door for all sorts of ad-hoc sync solutions if you don't want to use a server.
  
• Underline add-in from Mark Wakim (disabled by default).
  
• Faster start-up.
  
• UI improvements in note searching.
  
• More keyboard shortcuts.
  
• Loads of bug fixes.
  
• Updated documentation (a complete revamp is on the way for the GNOME 2.30 cycle).
  
• Notes and other files migrated to new standard directories.

I'm really excited about this release, because to me it represents a foundation. A lot of cruft has been cleaned up. Tomboy is leaner and meaner. Note and configuration files have moved to standard locations, making backups and upgrades better. Accessing those note files is now a less scary proposition. This is a good foundation on which we can build Tomboy's future.

With that in mind, here are some features I would love to tackle for Tomboy 1.2 if we can:

• Automatic synchronization.
  
• More work on Snowy, Tomboy Online, and social features integrated right into Tomboy.
  
• Note sharing via Telepathy, and maybe even collaborative editing.
  
• A new innovative workflow for managing simple task lists (with integration points for EDS or Tasque wherever it makes sense).
  
• Customizable, themeable, simplified note UI.
  
• Rethinking notebooks and search.
  
• Better gnome-shell integration.
  
• Better Tomboy experience on Mac OS X.
  
• Additional memory and performance enhancements.
  
• Your ideas and patches!

Personally, I'm really inspired by GNOME 2.28's "Made to Share" slogan, so I expect that will be a running theme in Tomboy 1.2.

I'll make sure to announce when we pick a date and time for our roadmap planning meeting, which is when we will choose what features we really want to focus on this cycle.

You may have read that we now have an official PPA for Ubuntu users. This is all thanks to Alan Pope and Jorge Castro. Since the announcement of the PPA a few other people have joined the tomboy-packagers team so I'm looking forward to being able to provide instant gratification to Ubuntu users on any distro since Jaunty, whether they want the latest stable or the latest development release.

In openSUSE land, the GNOME team is working on a specific organization for repositories like this, but I have the packages ready in my home project, so if you want Tomboy 1.0.0 for openSUSE 11.1 or later (including SLED 11), you can get them here for now:



This post brought to you by the Tomboy Blogposter add-in.