Hi,
We're going to ship glib 2.28 in openSUSE 11.4, since 2.28 should be out
in December.
There's one change that we must prepare for, though: the way URI scheme
handlers are registered changed. Before, applications used to register
themselves in gconf (see /desktop/gnome/url-handlers). The new glib
won't support that anymore and will use the MIME type system.
See Bastien's post for some more background:
http://www.hadess.net/2010/10/new-control-center-and-you.html
What does it mean for us? It means that we have to patch various
packages for this, and the good news is that by doing this, we can help
upstream. It's really easy to do, and I'm looking for volunteers :-)
Below are some instructions. It's a bit long. And it's late here, so
maybe they won't be really clear to everyone ;-) But just ask if you
want to help and face an issue.
Here is the upstream tracker bug:
https://bugzilla.gnome.org/showdependencytree.cgi?id=631433&hide_resolved=0
Let's take an example: Yelp. If you go the tracker bug, you'll find a
bug for yelp:
https://bugzilla.gnome.org/show_bug.cgi?id=631678
We need to register yelp for the x-scheme-handler/ghelp,
x-scheme-handler/info and x-scheme-handler/man MIME types. So here are
the steps we'll do:
a) branch yelp in the build service (osc branch GNOME:Factory yelp)
b) look for the source of the desktop file in the tarball. In this
case, this is yelp.desktop.in.in.
c) add the MIME types to the MimeType key. If there's no such key,
create one. For yelp, there's no such key, so we create one:
MimeType=x-scheme-handler/ghelp;x-scheme-handler/info;x-scheme-handler/man;
d) make sure that the Exec line has %u or %U as argument. This is
required to accept the URI that has to be opened. %u is for only one
URI, and %U is for multiple URI. In the case of yelp, we probably
want %u, and we see that the Exec line doesn't have %u nor %U, so we
add %u.
e) to make sure you were right to do this, manually simulate the
opening of such an URI. Call "yelp ghelp:evince" and see if it works
fine. (We replaced %u with ghelp:evince).
f) it's also important to make sure that simply calling the Exec line
by removing %u or %U works. For example, if yelp needs --open to
open a URI, you would use "yelp --open %u". But you have to check
that "yelp --open" doesn't fail and just launches yelp. If it
doesn't, then it will be a bit more complex and I suggest for now to
just report in the bug that yelp needs to be adapted.
f) create a patch of these changes, and submit it in bugzilla, as well
as in the build service
Additionally, we need someone to also patch totem with the two patches
that were committed in git for this:
http://git.gnome.org/browse/totem/commit/?id=74833ef98e515104a5ef10b0e59af0…http://git.gnome.org/browse/totem/commit/?id=b337849b174efd6b11304ddcdd3cfd…
There will be other apps to patch, that are not tracked in the upstream
bug. Looking at what I have in gconf, we probably want to patch the
desktop file for firefox (to support ftp and http) and transmission (to
support magnet). We could also patch xchat (but it needs to be done
carefully -- I'll let that as an exercice to the reader).
Thanks,
Vincent
--
Les gens heureux ne sont pas pressés.
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
Hi,
This is the list of GNOME-related packages that got added since the last
issue, ie August 26th. The packages that are in Factory as of this issue
will be in Milestone 2! Woohoo! We didn't get any removal this time.
I must admit I lost track of who did what, but many of those packages
are in thanks to Atri, Dominique, and Luis! Keep the contributions
coming!
http://en.opensuse.org/openSUSE:GNOME_new_packages contains the latest
status about this.
New packages
============
New, and already in Factory:
+ arista: video transcoder
+ cherrytree: hierarchical note taking application
+ gnac: audio converter
+ gtk3-branding-openSUSE: openSUSE branding for GTK+ 3
+ libdmapsharing: library needed for DAAP support in rhythmbox
+ libkate: overlay codec, for karaoke and text (needed for gstreamer
plugin)
+ libraw: raw decoding library (needed for shotwell)
+ libtimidity: MIDI to WAV library (needed for gstreamer plugin)
+ rygel: UPnP for GNOME
+ transmageddon: video converter
+ vboxgtk: GTK+ frontend for virtualbox
Were already in a devel project and now also in Factory:
+ evolution-tray: evolution plugin to minimize to tray
+ fillmore and lombard: audio and video editors
+ gcstar: personal collections manager
+ glib-networking: gio module to use libproxy
+ gnonlin: gstreamer plugin for non-linear editors
+ gstreamer-0_10-plugins-gl: OpenGL-based plugins for gstreamer
+ libvpx: VP8 codec (WebM)
+ memphis: library to render openstreetmap tiles (for libchamplain)
+ pitivi: video editor
+ shotwell: a photo manager
+ sparkleshare: file sharing and collaboration tool
Submitted or waiting for submission to Factory:
+ gst-rtsp: gstreamer rtsp server
Soon to enter a devel project:
+ gnome-dvb-daemon: daemon to setup your DVB devices, record and watch
TV shows and browse EPG
+ pidgin-embedded-video: view videos embedded in pidgin chat window
+ wiican: assistant to use wiimotes
+ x-tile: gnome applet to tile windows
Cheers,
Vincent
--
Les gens heureux ne sont pas pressés.
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
Hi all,
Today I was talking with one user that is migrating from KDE to GNOME
on the #opensuse-pt channel and something quite interesting poped
out... having some gmail notifications.
Anyone aware of any application to fulfill this? I know there's some
stuff I could get from Ubuntu to do this, but I also found [1] which
can be used.
I'm also interested in packaging this for personal use, therefore, if
anyone can point the best application to fulfill this role in case we
don't have it packaged already, I would like to take that assignment.
[1] - http://notifier.geekysuavo.org/
nelson.
--
nelson marques
nmo.marques(a)gmail.com
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
Hi,
I think we can be a bit more helpful to other teams by clearly
documenting some of the changes happening in the GNOME packages. I'd
like us to start documenting the big changes on a wiki page, so that we
can quickly summarize them.
Relevant changes would be important changes for end-users, and important
changes for the way the distribution works (like new packaging macros,
or change in a library that might affect other teams).
Does that make sense to people? Can someone create a wiki page for this,
that we'll start populating?
Cheers,
Vincent
--
Les gens heureux ne sont pas pressés.
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
Dear all,
There's too much fuss around Unity and GNOME at the moment. I have some
concerns, and it's somehow easy for me to realize that distributions do
have a great role to perform in supporting GNOME:
* As a distribution channel for GNOME;
* As a source of contributors for GNOME;
* Help GNOME in promoting an experience;
* Promote the Free Desktop alternative;
* etc.
'Unity' comes with some pure sarcasm, and the media is passing on
already a very twisted idea about GNOME. On this article from 'The
Register' a less technical user can pretty much take the conclusion that
GNOME is a solution for obsolete environments.
My suggestions to this list so that we can help GNOME from openSUSE,
and at the same time, defend our users. Unity is going to become 'hype',
Canonical's marketing is on that. Our users will feel tempted to try out
'Unity'. Unity has it's own 3rd party distribution channels. OK, Dell
this or Dell that, but small local hardware manufacturers get the
message and they are also pushing Ubuntu. So in a way, we can't ignore
it, therefore we need to use the ammunition we have available to defend
ourselfs. War was brought upon us, either you like or not. From a
strategical point of view, our success will be based mainly on
'resources' and the management of those, the very own can be applied to
GNOME, and they have their own people to work it out, though we can help
if required.
A small set of actions that can help us:
1. Do not engage Canonical directly. Take a vertical defense strategy.
In an easy way: treat them like you would treat your ex-girlfriend which
cheated on you, give them indiference. That's what will hurt them more,
specially their hordes of fan boys. If you find this is not the way,
consider people's morale and the negative impacts of engaging a full
scale war that will bring no benefit to us.
2. Take a stand - By not facing directly Canonical/Ubuntu/Unity, but
instead to promote GNOME Shell and GNOME3. I would base all the message
in the following points:
* Invitation to a whole new user experience;
* Invitation to be a part of something, GNOME;
* Invitation to be a part of a innovation;
* Promote only people, no screenshots, no tech stuff. Drop that
mentality, if we are a community, we are people, as such we build our
message based on the people, GNOME developers, packagers, and specially
USERS!.
* Refuse to be shy and brag a lot about how GNOME3 can be the ultimate
experience for your desktop (ease of use, reliability, productivity).
Means: The traditional digital means we use! Social Networks, Blog
spheres, even YOUTUBE! Specially youtube. (I know it's H264, but we have
a higher purpose, promote GNOME3).
Canonical took a stand, we take a stand, and hopefully next time we
take a stand even before Canonical did it. I don't like to use this
expression due to it's author, but I would to do so:
"while they build their barricades, we charge in!"
3. Beta Phase - Beta Phase is important, we need to schedule one before
GNOME3 hits the final release. A couple of points in why you really want
to do it:
* Because you will be providing your users a preview of gnome-shell.
Therefore when it becomes standard, they already tried it and already
have an idea of what is coming their way.
* Bug Squash parties - Important stuff for you guys. Most users will
_NOT_ be able to provide decent bug reports. We need to be pedagogical
on this. Anyone willing to write a sort of "Bug Report in 5 steps" that
we can use during the beta phase to enrol our users? I'll bring this up
on marketing so we can get a 'ninja pack' of merchandise to send to the
top bug reporters (based on quality of bug reports and maybe
relevance?), this is actually something you guys can decide for us.
* Soften the adaptation process and eventually reduce the psychic costs
of our users during that process.
* Most important, have the opportunity to collect feedback and provide
GNOME Project all the information required to easen up the deployment
process and promotion of GNOME3 even before it's released, according to
our users expectations and problems.
4. Ammunition - As a community and as a Linux distribution if the
licences aren't a problem to distribute Unity, openSUSE should consider
to place some effort in making Unity available 'AS AN OPTION' to our
users. This will remove the need they have to install Ubuntu and check
out Unity. We should not place any effort in marketing that, on the
contrary, we should market only GNOME and gnome shell. But having it as
an alternative will help us defend our position and our users. We can
even later on turn such option against Canonical. It would be
interesting to have actually a better Unity option than Canonical
itself, specially when Canonical has a long history in refusing patches
for extended configuration. They will appear also for Unity, if they
don't accept it, we can eventually aceppt them ourselves and might even
in some cases shift those contributors to our side, thus educate them
and try to make them real GNOME contributors. The availability (or not)
of Unity by openSUSE is to be faced only as a defensive action to
preserve the integrety of our community and avoid our users to try
Ubuntu. This has to be properly advertised as such.
Those are some thoughts. Sorry for the critical wall of text. I am
willing to work on a wiki page and some contents to promote GNOME and if
this list believes that Unity can be used to preserve our community
(point 4), I can take a number of packages to package, though I will
require help here and there.
This are personal thoughts, which I believe that can help us in
defending our position. I do not favor any strategy that takes a direct
hit on Canonical or their users, as they won't be shy in bashing us
down.
Kindest Regards,
nmarques
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
Hey,
Just cc-ing the list again as you dropped it out of your response accidentally.
> You make it clear that there are commercial interests behind this,
> while I trully believed that this case was based on "from the
> community" and "to the community". I could be a dick right now and
> take this to the forums and eventually try to leverage the public
> opinion to favour it and destroy most arguments presents (or at least
> try). But since it seems there are interests, as you clearly point,
> and I quote:
>
> " Especially when that customer wants to give me money "
>
> Following the original thoughts from RMS about documentation in free
> software, there's actually only one thing I can do: turn my back into
> such villainy.
> I can not be associated with such thing. Thanks for making it clear
> for us, who care more about the community then exactly about the shark
> interests (_on documentation_ ?!) of some.
No, not at all. I'm just making sure everyone realises that commercial
entities are part of the community. When making decisions on behalf of
the community you need to make sure that those decisions would be
agreeable to the majority of people from a wide range of cultures from
both a commercial and non-commercial background.
>
> This clears pretty much a lot to me. Thank you, now I am enlightened.
> And as a personal note, for someone who feels so much offense, you
> really have no problem in using such word as your post clearly
> indicates.
When something is appropriate, I use it. It was the most appropriate
way of wording my concerns as to why 'rtfm' may be considered
insulting or inappropriate. If you felt that my email was
inappropriately worded then it served it's purpose. You now understand
exactly why I believe 'rtfm' is inappropriate for a documentation
site.
Alan.
>
>
>
>
>
>
>>
>> If you felt vaguely offended or insulted while reading that paragraph
>> then you understand why RTFM is not a good choice. I really don't see
>> what it brings to the table other than 'fuck'. I'd also like to direct
>> your attention to the rather apt section 'Use and overuse' here:
>> http://en.wikipedia.org/wiki/RTFM . Take note of how other distros and
>> other websites have banned (yes, *banned*) the usages of that phrase
>> as it's both unhelpful and unwelcoming. That's pretty much all I have
>> to add.
>>
>> Alan
>>
>> On Tue, Oct 26, 2010 at 7:35 PM, Nelson Marques <nmo.marques(a)gmail.com> wrote:
>>> On Tue, 2010-10-26 at 17:59 +0100, Alan wrote:
>>>> If everyone here can say with a clean conscience that they have no
>>>> trouble saying the words "read the fucking manual" to anyone and
>>>> everyone who has a problem which can be solved by the docs then I
>>>> think rtfm is a great idea.
>>>>
>>>> If you think that might cause offence, then maybe you should be
>>>> looking at ditching the name.
>>>
>>> Read This Fine Manual
>>>
>>> Phonetically: redifine manual /* they look so close */
>>>
>>> Plus lots of other stuff... Some people will know it's 'Read the fking
>>> manual' but we can present in another non-harmful way, and people can
>>> still laugh about it.
>>>
>>> Given the ammount of self-learning on this communities, I really think
>>> it's dangerous and involves a risk to use it, but it work out very good!
>>>
>>> But that's just me.
>>>
>>>
>>>>
>>>> Alan.
>>>>
>>>> On Tue, Oct 26, 2010 at 5:32 AM, Rajko M. <rmatov101(a)charter.net> wrote:
>>>> > On Monday 25 October 2010 16:35:33 Nelson Marques wrote:
>>>> >
>>>> >> If someone who is placing work on helping with our goals has
>>>> >> chosen «RTFM», my role would be making «RTFM» look good and promote it
>>>> >> with the right message.
>>>> >
>>>> > From your perspective F-word can be fun for non-native speakers, but try to
>>>> > translate RTFM to Portuguese and tell me what is positive in F part of it. It
>>>> > is a profanity. I'm sure that I will not tell to any person that I have
>>>> > respect for, or I expect to be respected from, to see rtfm domain for opensuse
>>>> > docs.
>>>> >
>>>> > Well entrenched acronyms can be changed, but the price can be higher than
>>>> > openSUSE can pay.
>>>> >
>>>> > IMO, energy can be better used to fix the links and style sheet glitches on
>>>> > the http://doc.opensuse.org .
>>>> >
>>>> > --
>>>> > Regards,
>>>> > Rajko
>>>> > --
>>>> > To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
>>>> > For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
>>>> >
>>>> >
>>>
>>>
>>>
>>
>
>
>
> --
> nelson marques
> nmo.marques(a)gmail.com
>
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
Hi,
I'm not where to share feedback about this, but as this is the only
openSUSE mailing list I'm currently subscribed to, I thought i'd start
here. Before I blog about this (if I do), I wanted to say I'm happy to
see the openSUSE community launch a Documentation sub-domain, especially
as someone who enjoys writing user help for upstream. Getting users to
read documentation and user help can be a challenge and efforts like
this are important to encourage users to start in one spot when they
need help.
But I can't communicate enough how disappointed I am in the sub-domain
that has been chosen: http;//rtfm.opensuse.org - RTFM has such a
negative connotation, especially from Linux's early years, that while
this may be funny to an old-timer that has been using Linux for more
than 10 years, to someone who is new and needs help, this is a bad
message to send. Whether they have tried to get help on IRC or a forum
and have been told to go "RTFM" we shouldn't encourage that kind of
behavior by naming a sub-domain "RTFM".
Call it docs.opensuse.org, help.opensuse.org, userhelp.opensuse.org or
anything else. There's no reason to continue an old stereotype or use
an abbreviation in a sub-domain that contains profanity.
If anyone can pass this on to the community members who set this up or
share their contact information I'm more than happy to pass on this
feedback.
Thanks.
Paul
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
The package dmxviewer exists in home:hennevogel:TODO, a temporary devel
project. It was formerly maintainer by "gnome-maintainers".
A couple of questions for you:
* Is this package still needed for factory ?
* Do you want to maintain it?
* Or should I drop it?
Andreas
--
Andreas Jaeger, Program Manager openSUSE, aj(a){novell.com,opensuse.org}
Twitter: jaegerandi | Identica: jaegerandi
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
Maxfeldstr. 5, 90409 Nürnberg, Germany
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
Hi
I recently did a distupgrade to GNOME:Stable:2.32 on a pretty fresh
OpenSUSE 11.3 installation. Rather than moan on IRC where people might
not see this, especially during conference, I thought I'd write it up
properly.
There were some problems. Not as bad as last time I tried this a while
back, admittedly. I did the dup, didn't check every single package
change, and restarted my session. First problem? No panel. Eep.
In a terminal, gnome-panel told me that it was dying because the
notification area applet was missing a symbol in GTK+. I'm afraid I
can't remember that symbol's exact name. It didn't take much sniffing
to discover that GTK+ 2.22 had not been installed during the upgrade.
That was a surprise. I told zypper to install it manually, it said
there was an update available with vendor change, so I forced it to do
that and the reason was revealed - some kind of dependency/provides
argument with gtk2-branding-opensuse and gtk2-engines or maybe
gtk2-branding-upstream. Unfortunately it's a bit too early in the
morning to remember the details.
In any case, installing that sorted out notification-area. Cracking.
The problem I remain immediately aware of is what looks like a
rendering bug in certain conditions. I'm using compiz on an nvidia
card, and before the upgrade everything looked fine. Now, when I pull
up GNOME Do, the window's shadow (which I believe is rendered by Do
and not by compiz) has no gradient - it's just a nasty chunk of
translucent grey. This lack of gradient is also visible in certain
states of certain GTK widgets, like the internal shadow on a progress
bar, and a depressed button (using the Clearlooks engine for this). I
did wonder if maybe cairo had escaped updating too, but that's at the
latest available version according to zypper (package libcairo2).
So that one's got me stumped, and it's kind of ugly too. Seems to
affect all apps, from GDM to Firefox and beyond. There's a load of stuff
I haven't tested yet as well, but I'll worry about that if it becomes
worrisome.
I know I could've just stuck with 2.30, but I knew there were probably
still problems from my adventures before, and how can problems be
fixed if people don't know about them?
Thanks
Matthew
mathw
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org