This tip explains how to visualize HA managed resources and their dependencies with a graph.
Posts and information from the SUSE world.
This tip explains how to visualize HA managed resources and their dependencies with a graph.
git clone http://lilypond.org/vc/dev300-m28.git # r13448
Calling all San Franciscans! The openSUSE Project (or at least selected members thereof) is hosting an openSUSE Day at LinuxWorld Expo next Wednesday, and we want to see you there.
We’re going to be giving out two Chumby’s (er, that’s two total — not two per attendee…) as door prizes at the openSUSE Day and we’ll also be handing out assorted openSUSE swag — such as t-shirts, Geekos, openSUSE DVDs, and other goodies that you won’t want to miss out on.
And, if all the swag wasn’t enough reason to drop by, you’ll also have a chance to hear some great talks about openSUSE and technologies in openSUSE. And be sure to head by the openSUSE booth and see openSUSE on display and ask whatever questions you might have about openSUSE 11.0 and the openSUSE Build Service.
To get the tablet supported you need a new version of the wacom kernel module. I’ve added a new wacom-kmp package to my openSUSE Build Service project with an updated version of the module including a working version for kernel 2.6.26. The package is available for openSUSE 10.2/10.3/11.0 and factory. You should also update x11-input-wacom to the latest version from the same repo.
Currently I’m working on an updated and extended version of SaX2 to easily configure also these TabletPCs. As soon as I’ve a new SaX2 package available I’ll announce it here.
Ever shoot yourself in the foot with the chown command. Well this tip will help bring your system back to life
Join the openSUSE Project for a day of fun and FOSS at the LinuxWorld Expo! On Wednesday, August 6th, the openSUSE Project will be holding its first “openSUSE Day” in North America, in conjuction with the LinuxWorld Expo at the Moscone Center in San Francisco.
We’ll have a full day of presentations about the openSUSE Project, […]
Step by step instructions to get Atheros Wireless & Webcam on Compaq Presario C795TU working with SLED10 SP2.
People
like were thinking of a document-centric desktop
before my GUADEC talk. W00t. It’s nice to see people
tuned in to the same channel.
(There is a lot of material in that blog post. Digest
it slowly, bit by bit. I don’t agree with the parts
about needing to dump the fundamentals of our platform,
but that’s perhaps better seen from an implementator’s
perspective.)
Nemo is a file
manager for GNOME which displays your files based on
time, not on folder hierarchies. It also
handles categories for files, like tags in F-spot. I
had not seen it before GUADEC, and it’s a pretty cool
concept — much more developed than the simplistic
timeline-of-days that I showed in GUADEC. Maybe we can
embed
the Mono VM into Nautilus and reuse Nemo’s
super-sexy widgets for time-based displays.
rpm2git — an easy way to publish distro patches
Various GNU/Linux distros have developed different,
ad-hoc ways of publishing the patches they put on top of
“pristine” released tarballs from upstream projects like
GNOME. openSUSE lets
you download full SRPMS from an FTP site, or in a
slower but more elegant way through the openSUSE Build
Service. Fedora has
a CVS repository where they put specfiles and
patches. Back in the Ximian days, we had a pretty cute
web page, patches.ximian.com,
where you could ask for the patches for a specific
module, for one or more distros.
Since every distro publishes its patches in a different
way, the following happens.
First, upstream developers have a hard time actually
looking for those patches to review them and see if they
are fit for inclusion in the mainline releases. Where
does $distro publish its stuff? How do I know what its
latest version is? How do I know what bugs they were
trying to fix? Upstream developers should not have to
learn the idiosyncrasies of each distro just to get
code from them.
Second, distros themselves end up doing a lot of
duplicated work. I just found out that both Fedora and
openSUSE have patches in their gtk package to do the
same things: one for GtkEntry to change the “*” into a
“?” when the entry is being used for password entry;
another one to let 64-bit builds install the 32-bit and
64-bit libraries in the correct places. If there had
been an easy way to share those patches, maybe they
wouldn’t have duplicated the same work.
I am pleased to give you rpm2git.
This is a little tool that you can use as follows:
First, you get a Git clone of an upstream repository,
for example, something out of git-mirror.gnome.org.
Second, you get a SRPM and unpack it. You look at the
version of that package (say, Nautilus 2.22.2).
Third, you find the Git tag for that version
(svn/NAUTILUS_2_22_2).
Fourth, you call rpm2git with that tag name,
your specfile, and a destination branch name.
Rpm2git will create a branch starting at the tag you
specified, and it will apply the patches from the SRPM
as individual commits. The commit messages come from
the patch comments.
The idea is that you can later just publish this Git
repository, and upstream developers or other distros
will be able fetch your branches into their own base
repositories. Then, they can cherry-pick patches at
their convenience.
You can get rpm2git like this:
git clone git://gitorious.org/rpm2git/mainline.git rpm2git
Over the next few days I hope to start publishing Git
repositories of the GNOME packages we ship in openSUSE,
with branches for the patches we use.
Note that rpm2git is not the same as VCS-PKG, a really
interesting project to go directly from source code
under revision control to compiled distro packages.
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Jun | Aug » | |||||
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | |||