Re: bumping telepathy-glib's external dependencies for 2.32
Le mercredi 21 avril 2010 à 09:11 +0200, Guillaume Desmottes a écrit : Le jeudi 01 avril 2010 à 11:01 +0200, Guillaume Desmottes a écrit : Hi, I plan to use in Empathy new API from telepathy-glib so will have to dump the external dependency to 0.11. This will be needed for new features and factor out code from Empathy to tp-glib. I'd like to bump to 0.11.3. This will allow me to fix #579813. Actually I plan to use latest 0.11.x releases during this cycle. We plan to release tp-glib 0.12.0 (stable branch) in time for GNOME 2.32 so distributions will ship this version. telepathy-glib 0.11.6 has been released [1] yesterday. I plan to use it soon in Empathy as it introduces lot of new API making Empathy simpler. I'll update the wiki and jhbuild. G. [1] http://lists.freedesktop.org/archives/telepathy/2010-May/004558.html -- Guillaume Desmottes gdesm...@gnome.org Jabber cass...@jabber.belnet.be GPG 1024D/711E31B1 | 1B5A 1BA8 11AA F0F1 2169 E28A AC55 8671 711E 31B1 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Fwd: Proposing new external dependency for Empathy: libfolks]
Il giorno mar, 25/05/2010 alle 11.07 +0200, Frederic Peters ha scritto: New Dependencies = empathy depends on: libfolks libfolks depends on: telepathy-glib Vala bindings [3] (should be in telepathy-glib 0.11.6) for building telepathy-glib Vala bindings depend on: gobject-introspection vala 0.8.1 (first release to include fix for bgo #618660 [4]) Please correct me if I'm wrong, but this means we'll need something like this telepathye-d-s | | V V telepathy-vala e-d-s-vala | | V V libfolks in order to have a persona object that could share info from both sources? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-system-monitor does not show CPU speed on ppc64
On Tue, 2010-05-25 at 20:55 -0500, Diego Escalante Urrelo wrote:
Hi Luciano,
Quite an interesting read!
I think you want to ping Benoît Dejean ben...@placenet.org (cc'd) who
is listed as the maintainer of the module, and also put your report
(file a new bug) in http://bugzilla.gnome.org and attach any patch you
come up with.
If the maintainer or someone else doesn't comment or review your patch
on a reasonable time feel free to ping here again.
Thanks for working on this!
Hola Diego,
Gracias! Thank you! I will open a bugzilla as I am working on a proposed
patch for this. I also have another patch in this same code for another
problem where it displays an extra CPU entry at the end for ppc64 that
it shouldn't. I will open a separate bugzilla for that one as well.
El lun, 24-05-2010 a las 12:36 -0500, Luciano Chavez escribió:
Hello,
I am looking at problem reported by one of our test teams. Below is
their recreation steps and what they reported:
1. Launch System Monitor Tool (gnome-system-monitor-2.28.0)
2. Look at Hardware item of System tabbed section like following
sentence:
Precessor 0: POWER6 (architected), altivec supported === no processor speed
3. In System Monitor Tool window, open help manual via
Help-Contents-Introduction and you could see Processors and speeds
description in Hardware item of System tabbed section
Here is my analysis:
I took a look at the source for gnome-system-monitor and determined where
the
strings that are displayed came from. Looking at src/sysinfo.cpp there is
this
method:
void load_processors_info()
{
const glibtop_sysinfo *info = glibtop_get_sysinfo();
for (guint i = 0; i != info-ncpu; ++i) {
const char * const keys[] = { model name, cpu };
gchar *model = 0;
for (guint j = 0; !model j != G_N_ELEMENTS(keys); ++j)
model =
static_castchar*(g_hash_table_lookup(info-cpuinfo[i].values,
keys[j]));
if (!model)
model = _(Unknown CPU model);
this-processors.push_back(model);
}
}
It first invokes the glibtop_get_sysinfo() call which comes from the
external
libgtop to retrieve the system info (I will explain where from shortly) and
then uses the keys model name and cpu to retrieve the corresponding
strings
in a hash table that correspond to those keys. What is retrieved is what
ends
up being displayed under the Hardware section.
In the libgtop source we find a file called sysdeps/linux/sysinfo.c which
contains the source for the glibtop_get_sysinfo() which almost wholly
contained
in the function init_sysinfo() which essentially reads the contents of
/proc/cpuinfo into a buffer then parses each line and uses the label before
the
: as the key and the remaining as the value and the labels/keys are loaded
into string array and the string values are added into a hash table with the
label as the key.
So, looking at the /proc/cpuinfo of a x86_64 system I get the following:
model name : Intel(R) Xeon(TM) CPU 3.40GHz
as well as ...
cpu MHz : 3400.000
but on the test system we get
cpu : POWER6 (architected), altivec supported
clock : 4204.00MHz
So, as you can see both do offer separate sysinfo records for the processor
speed (cpu MHz and clock) but since only model name and cpu are
looked
at and only model name contains that extra info, this is why for the ppc64
system, it is not displayed though it is separately available from the
clock
record.
I am considering creating a patch for the case when model name is not
available but cpu is which will simply append the clock text (if
available) to the cpu text. Anyone suggest a better or alternative
solution?
regards,
--
Luciano Chavez lnx1...@linux.vnet.ibm.com
IBM Linux Technology Center
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Fwd: Proposing new external dependency for Empathy: libfolks]
On Wed, 2010-05-26 at 13:11 +0200, Luca Ferretti wrote: Il giorno mar, 25/05/2010 alle 11.07 +0200, Frederic Peters ha scritto: New Dependencies = empathy depends on: libfolks libfolks depends on: telepathy-glib Vala bindings [3] (should be in telepathy-glib 0.11.6) for building telepathy-glib Vala bindings depend on: gobject-introspection vala 0.8.1 (first release to include fix for bgo #618660 [4]) Please correct me if I'm wrong, but this means we'll need something like this telepathye-d-s | | V V telepathy-vala e-d-s-vala | | V V libfolks in order to have a persona object that could share info from both sources? Hi Luca, Just to clarify a little, it would look like this: telepathye-d-s | | V V telepathy-vala libebook-vala | | | | ++---+--+---+ |libfolks| | | | ++ V V | | TpPersona EPersona | | \ / | |V | |Individual | || | ++--+ | V applications E-d-s Vala bindings aren't strictly a requirement here, though they would have to be manually bind pieces of libebook in libfolks if not. On the other hand, Rodrigo mentioned an interest in adding gobject-introspection notation to e-d-s (and a libfolks eds-backend), in which case the Vala bindings should be practically free. In most cases, end-user applications will only care about Individuals, which are made of 1 or more Personas. The Personas will be exposed, in case they're useful (for instance, TpPersona exposes its TpContact from telepathy-glib, so you can initiate chats, audio/video calls, etc.). Getting Individuals, from the the application perspective, is as easy as getting the FolksIndividualAggregator and hooking up a handler for individuals-added. -Travis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Fwd: Proposing new external dependency for Empathy: libfolks]
On Wed, 2010-05-26 at 08:23 -0700, Travis Reitter wrote: Just to clarify a little, it would look like this: telepathye-d-s | | V V telepathy-vala libebook-vala | | | | ++---+--+---+ |libfolks| | | | ++ V V | | TpPersona EPersona | | \ / | |V | |Individual | || | ++--+ | V applications Does that mean that, when I sync from Evolution, I'm loosing a part of the information constituting an Individual ? Xav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Fwd: Proposing new external dependency for Empathy: libfolks]
On Wed, 2010-05-26 at 17:37 +0200, Xavier Bestel wrote: On Wed, 2010-05-26 at 08:23 -0700, Travis Reitter wrote: Just to clarify a little, it would look like this: telepathye-d-s | | V V telepathy-vala libebook-vala | | | | ++---+--+---+ |libfolks| | | | ++ V V | | TpPersona EPersona | | \ / | |V | |Individual | || | ++--+ | V applications Does that mean that, when I sync from Evolution, I'm loosing a part of the information constituting an Individual ? What kind of syncing, specifically? libfolks' Personas are designed to stay synchronized with their original sources (through their per-backend PersonaStore, which I left out of the diagram above for simplicity). If the EContacts in e-d-s change state (eg, you synchronize them from another addressbook, change them in Evolution itself), libebook will signal the changes, EPersonaStore will handle the signals and update its EPersonas (including adding/removing full EPersonas, as necessary), and each EPersona will signal the changes. The Individual will notice the changes and update its exposed attributes (and emit its own signals). Does that answer the question? Regards, -Travis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Fwd: Proposing new external dependency for Empathy: libfolks]
On Wed, 2010-05-26 at 09:19 -0700, Travis Reitter wrote: On Wed, 2010-05-26 at 17:37 +0200, Xavier Bestel wrote: On Wed, 2010-05-26 at 08:23 -0700, Travis Reitter wrote: Just to clarify a little, it would look like this: telepathye-d-s | | V V telepathy-vala libebook-vala | | | | ++---+--+---+ |libfolks| | | | ++ V V | | TpPersona EPersona | | \ / | |V | |Individual | || | ++--+ | V applications Does that mean that, when I sync from Evolution, I'm loosing a part of the information constituting an Individual ? What kind of syncing, specifically? libfolks' Personas are designed to stay synchronized with their original sources (through their per-backend PersonaStore, which I left out of the diagram above for simplicity). If the EContacts in e-d-s change state (eg, you synchronize them from another addressbook, change them in Evolution itself), libebook will signal the changes, EPersonaStore will handle the signals and update its EPersonas (including adding/removing full EPersonas, as necessary), and each EPersona will signal the changes. The Individual will notice the changes and update its exposed attributes (and emit its own signals). Does that answer the question? I'm not sure. Say I have a central server where I store my contacts, and 2 workstations syncing to that server through Evolution. If I add some information (e.g. a Facebook id) to an Individual with Empathy on a workstation, will it appear on the other workstation ? Xav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Fwd: Proposing new external dependency for Empathy: libfolks]
Le 26/05/10 18:45, Xavier Bestel a écrit : On Wed, 2010-05-26 at 09:19 -0700, Travis Reitter wrote: On Wed, 2010-05-26 at 17:37 +0200, Xavier Bestel wrote: On Wed, 2010-05-26 at 08:23 -0700, Travis Reitter wrote: Just to clarify a little, it would look like this: telepathye-d-s | | V V telepathy-vala libebook-vala | | | | ++---+--+---+ |libfolks| | | | ++ V V | | TpPersona EPersona | | \ / | |V | |Individual | || | ++--+ | V applications Does that mean that, when I sync from Evolution, I'm loosing a part of the information constituting an Individual ? What kind of syncing, specifically? libfolks' Personas are designed to stay synchronized with their original sources (through their per-backend PersonaStore, which I left out of the diagram above for simplicity). If the EContacts in e-d-s change state (eg, you synchronize them from another addressbook, change them in Evolution itself), libebook will signal the changes, EPersonaStore will handle the signals and update its EPersonas (including adding/removing full EPersonas, as necessary), and each EPersona will signal the changes. The Individual will notice the changes and update its exposed attributes (and emit its own signals). Does that answer the question? I'm not sure. Say I have a central server where I store my contacts, and 2 workstations syncing to that server through Evolution. If I add some information (e.g. a Facebook id) to an Individual with Empathy on a workstation, will it appear on the other workstation ? Xav First, I don't think Empathy should be a full vCard editor. That said, if empathy (or any app, include Evolution) edit a contact, the new vCard is stored in E-D-S and sync system will just replicate that change in other PCs. I think that process is totally transparent to libfolks. The only thing to take care is to not change the UID of the EContact in the sync process, otherwise the contact will unmerge. Or did you mean if I merge a TpContact (say, a Jabber contact f...@jabber.org) and an EContact together into an Individual, the EContact should be added a vCard attribute x-jabber=...@jabber.org and that info sync in other PCs? That could be done, but I don't think that's necessary. Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
2.31.2 release will be a bit late -- current status
Hi, I won't be able to complete the release of 2.31.2 today (or well, yesterday for me now). I still have various build failures: gvfs telepathy-farsight empathy epiphany gnome-sharp gnome-desktop-sharp gnome-games gnome-system-tools sound-juicer anjuta evolution-webcal yelp Some notes about those: + gvfs: https://bugzilla.gnome.org/show_bug.cgi?id=619537 (conflict between gvfs and recent glib) + telepathy-farsight: stream.c:164:13: error: conflicting types for ‘close’ /usr/include/unistd.h:350:12: note: previous declaration of ‘close’ was here + empathy: needs telepathy-farsight + epiphany: I guess I need a newer webkit + gnome-sharp: fails during install with: Failure adding assembly policy.2.8.gconf-sharp.dll to the cache: Strong name cannot be verified for delay-signed assembly + gnome-desktop-sharp: needs gnome-sharp, I suppose + gnome-games: gsettings issue: make[3]: *** No rule to make target `org.gnome.Games.WindowState.gschema.xml', needed by `all-am'. Stop. + gnome-system-tools: fails with gnome/releases/usr/include/liboobs-1.0/oobs/oobs-object.h:27:23: fatal error: dbus/dbus.h: No such file or directory + sound-juicer: sj-play.c:99:1: error: conflicting types for ‘pause’ /usr/include/unistd.h:465:12: note: previous declaration of ‘pause’ was here + anjuta: needs a newer libgda, I assume: symbol-db-engine-core.c:2987:14: error: ‘GDA_CONNECTION_OPTIONS_THREAD_SAFE’ undeclared (first use in this function) + evolution-webcal: fix in master, need new tarball + yelp: https://bugzilla.gnome.org/show_bug.cgi?id=617376 (fix in master, need new tarball) Any help to quickly fix those issues is welcome! Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.31.2 release will be a bit late -- current status
On Wed, May 26, 2010 at 7:19 PM, Vincent Untz vu...@gnome.org wrote: + gvfs: https://bugzilla.gnome.org/show_bug.cgi?id=619537 (conflict between gvfs and recent glib) I've just done a 1.6.2 that should build. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
