[GNOME] Public Service Announcement for Fedora users upgrading using fedup

Consider updating fedup to 0.8.0 from updates-testing



# yum update --enablerepo=updates-testing fedup



Or else you may end up with a broken System Upgrade.



https://bugzilla.redhat.com/show_bug.cgi?id=1044346

https://bugzilla.redhat.com/show_bug.cgi?id=1044086

[Technology] Another disappointing upgrade experience

So, sometimes, I'm actually pleased with Fedora upgrades.  Not recently though.  With Fedora 20, I again run into a crippling, opaque problem, which ultimately isn't a huge barrier for me, but I can imagine my friends being lost.



This time, at the time of its release, an appropriate version of fedup (the official upgrade tool) is not available in the Fedora 19 repositories.  You want 0.8, but instead you'll use 0.7, and after downloading a ton of packages, you'll go to restart and then it will fail to upgrade, complaining about things like

-- Unit boot-efi.mount has begun starting up.
            Dec 18 03:14:13 symonia.localdomain mount[768]: mount: unknown filesystem type 'vfat'
            Dec 18 03:14:13 symonia.localdomain systemd[1]: boot-efi.mount mount process exited, code=exited status=32
            Dec 18 03:14:13 symonia.localdomain systemd[1]: Failed to mount /boot/efi.
            -- Subject: Unit boot-efi.mount has failed
            -- Defined-By: systemd
            -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
            -- 
            -- Unit boot-efi.mount has failed.
            -- 
            -- The result is failed.
            Dec 18 03:14:13 symonia.localdomain systemd[1]: Dependency failed for Local File Systems.
            -- Subject: Unit local-fs.target has failed
            -- Defined-By: systemd
            -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
            -- 
            -- Unit local-fs.target has failed.
            -- 
            -- The result is dependency.

I mean, if you can even find that in the voluminous journal output once you're on the command-line.



The solution is to update to the version of fedup in the updates-testing repo



# yum update --enablerepo=updates-testing fedup



Then re-run fedup.  However, if you tried with 0.7 first, 0.8 wants to download the packages in a new directory configuration, so you'll end up with 1.5GB of duplicate packages on your system O_O.  So, I hardlinked the ones in the 0.7 directory (/var/lib/fedora_upgrade) into the various repo-specific directories from 0.8 (/var/tmp/system_upgrade/SOMEREPO/packages).  Those directories might not be quite right, as having eventually succeeded in upgrading, the latter one is gone (the former is still around, wasting space, of course).



Why would the current version of fedup at the time of release be non-functioning, when it's the recommended tool for upgrades?  Yeesh.



The relevant bug is here:

https://bugzilla.redhat.com/show_bug.cgi?id=1044346

[Technology] Fedora 20's System Upgrade with FedUp fails to boot :(

I bet it's because my file system is encrypted.  Sigh.  That used to work.  Silly Linux.

[Technology] Netflix on Fedora, working thanks to Pipelight

I had previously tried to get Netflix to work on Fedora through recompiling wine with associated patches.  It never quite worked (segfaults).  However, thanks to Pipelight, I can now install it relatively easily on Fedora.  Pay attention to all the steps, but it works!

[Technology] Android phone; remote locate, ring, lock and wipe

I remember reading that Android could now locate, ring, lock, and/or wipe lost phones using the Android Device Manager but I never tried it (or enabled the remote lock or remote wipe) until today. Triangulating my position via my cell service isn't very useful or accurate (in part due to WIND's relatively few towers, I presume) but when wifi or GPS is one, it works well. I wish I could remotely activate those, too, to get a finer lock. Sadly, nothing so exciting as losing my phone tends to happen. :'(

[Microblog] Hour of Code

US President Barack Obama wants young Americans to learn how to code. Non-Americans could probably benefit too.

[Technology] 12 Days of WaitingforFedora20

Fedora 20 is coming!  With GNOME 3.10!   On the 17th!



A friend recently had issues trying to reinstall Ubuntu a few times and has agreed to give Fedora a try.  I haven't used Ubuntu regularly in a while, but I don't have much inclination too given my affection for GNOME Shell.  I'm curious why a friend recently told me they switched from Fedora to Ubuntu and that perhaps I should be able to guess why, but I'm not sure what they were suggesting in the end?  Ah well.  To the future, where everything is GNOME!

[Technology] Permanent flux and brokenness

So Google Hangouts for Android now supports SMS and IM.  That's great.  Except for when my friend Kevin is messaging me and then half of his messages appear in one app (texts) and the other half another (IMs) indiscriminately and inconsistently.  Trying to chat with him from G+ Hangouts results in me missing random messages, since G+ Hangouts doesn't catch texts.



So, obviously, the next feature we need is letting GMail/G+ manage your texts too.  That would actually be nice, if I could send a text to any friend from my web browser.  My SwiftKey virtual keyboard on my phone is pretty great, but it's still painful have long conversations through compared to a full keyboard.



It's amusing how quickly I stop considering the privacy impact of letting all my communications be hosted remotely together in the same location.



Anyway, it's sad how people have been solving the problem of digital messaging for over thirty years and it's no better now than it was before, or it's worse.

[General] Helping others and learning stuffs

Today I made a website for a group on campus, Guelph Queer Equality.  It's not published yet, but here's a screenshot:

As you can see, it's fabulous.  I volunteered to do this because I support their work on campus and it benefits good friends of mine.  They didn't have a website before, but wanted one, so I thought my skills could be useful to them.



I'm not brilliant at visual design, but they didn't have any website before, and what I can provide for free is (hopefully) preferable to nothing.



I enjoyed doing this because it did not take too long and was a break from my regular work (thesis, TAing, GRAing, etc).  Here are some fun things I got to play with

• HTML Canvas.  I've poked at it a couple times before, but never really  made it far.  It felt like one of those weird things I might never quite understand.  Basically it gives you a space on your page to draw on.  You have a context that you can use to draw shapes, letters, images, etc.  In this screen shot, the name "Guelph Queer Quality" is drawn on the canvas, and the rainbow and the whitespace are drawn too.




• I followed this tutorial to do the rainbow:
  http://krazydad.com/tutorials/rainbow/showexample.php?ex=rainbow_arch_grad
  The resulting code was refactored quite a bit, though.




• Web fonts.  The header and the URLs are done in Snippet:
  http://www.google.com/fonts/specimen/Snippet


• PHP.  The elements of the site that are consistent across pages are in template PHP files that get included into the primarily-content-based named pages (Updates, Events, FAQ, etc).  Also, the blog posts are actually just a feed from a Blogger blog, whose atom feed is getting parsed.


• JavaScript and CSS.  This was used to position content in the right place, and required many calculations.

I also briefly was using neat stuff like CSS transforms but that was too much for the group. :D

[GNOME] GXml: This Halloween, redundant code dies

XPath, Attr, and a tale most foul

 

I'm working on merging Adam Ples' patch for XPath support (branch: xpath), and I notice that a test failed because they were expecting the GXmlDocument to be able to translate from an xmlAttrPtr to a GXmlAttr.  (GXmlDocument remembers a mapping between xmlNodePtrs to GXmlNodes already to avoid duplicating its proxy nodes.)  The patch's expectation is reasonable, but for a variety of reasons, most of all that xmlAttr != xmlNode (except that they sort of do), GXmlAttrs are not considered "backed nodes" (unlike the other GXmlNode types (like GXmlElement) that have an xmlNodePtr behind them) so we don't map between them (and attrs are handled more just like strings (which we need to do, because there isn't really a xmlSetPropNode in libxml2, for instance).  Also, because at one point wanted to use a more familiar GLibHashTable to store an element's mapping of attribute names to attribute values, rather than the NamedNodeMap that the W3C DOM specifies.  However, perhaps it's worth changing how things are done to support the xpath's code's reasonable assumption.



So I looked over the GXmlAttr, GXmlElement, and GXmlDocument code and realised that if I do treat xmlAttrs as xmlNodes where it's safe to do so, I could greatly simplify a lot of code.  And, also, if I do implement the NamedNodeMap for accessing an element's attributes, I could also remove a complicated kludge in GXml which currently requires synchronising elements' attributes between the GLibHashTable they've been stored in and the libxml2 structures they need to be in when doing tasks like saving to disk or stringifying a node or document.



Consequently, there's a new branch in GXml called newattr where this is happening.  Attr.vala loses 85 lines of code, Element.vala loses 127, and Document loses 38.  NamedNodeMap.vala adds 130, with a big chunk of that being a copyright notice and comments, though. :)  Overall, there's a net difference of 119 lines removed (so it's not that massive, but!), including the complexity of syncing Elements at all (needing to remember to call a method to sync each time you might want to was error prone and a delayed performance penalty), and the reduction in parallel code between GXmlAttr and other nodes.  YAY!



I'm considering offering some GLibHashTable-style convenience methods to GXmlNamedNodeMap (like lookup and size) so anyone who has to port will have an easier time (they'd just wrap get_named_item and get_length, for example).  Let me know if you have an opinion on that!



GXml going forward



The next stable release is waiting for this to happen (since it will include API breaks from the summer anyway).  Also, Owen Taylor provided useful advice to me at the conclusion of the Summer of Code that has led to much more useful documentation regarding memory handling of GXml objects, which is already in git master.  The devhelp gtkdocs that valadoc generates have some oddities that I still need to investigate, but I don't think I'll let that be a blocker.  So, if you use the latest documentation and something's unclear, let me know (by filing a bug!)

[Technology] Numix in GNOME

If you're a Linux user and not a fan of faux 3D beveling and flashy gradients, then I strongly recommend the Numix Project: http://numixproject.org/



In particular, I'm using their Gtk+ theme, their icons, a Firefox theme, and one of their wallpapers.



I kept Firefox open for the screenshot because I notice a striking similarity between Numix's aesthetic and Google's style new to last year, which both have squarical flat shapes and colours everywhere.  I like it.

Gtk+ Theme

Download it from the Deviant Art page linked above, and unpack it into ~/.local/share/themes/ (you can find that directory by opening the file browser, and typing in the path directly or choosing to see hidden files and folders and navigating there).  You should have a directory ~/.local/share/themes/Numix (and for ~/.local/share/themes/Numix - Gtk3.4)  now.  Then open GNOME Tweak Tool (gnome-tweak-tool, you may need to install it), go to the Themes section (you might need User Themes extension installed but I doubt it), and set GTK+ theme and Current Theme to Numix.

Icon Theme

Go to the github page linked above.  In the bottom right, there should be a "download zip" button.  Download it, and unzip it.  This should give you a folder "numix-icon-theme".  Go in there and copy the Numix folder into ~/.local/share/icons/.   Then go to GNOME Tweak Tool again and set the Icon them. Next, be delighted when opening Activities view of GNOME Shell.

Firefox

Sadly, Firefox does have great support for this yet.  If set the Gtk theme to Numix, many of Firefox's widgets won't theme at all and will look like GNOME 2.0.  However, that's not so bad. You can at least spice up the tab bar by downloading the Numixy theme by visiting the above link.  Google Chrome apparently has an official Numix theme provided by the Numix Project.

Things wanted

I don't usually put too much effort into theming my environment because a lot of themes grate on me after a while, and because they're often incomplete.  They're not actively maintained.  Someone creates two hundred icons, but then stops creating new ones for new applications.  That's why the Tango project was special, good guidelines and motivated people.



It would be nice to have GNOME Shell itself be themed (I think the Numix developers are Ubuntu users though) and to have better support for Firefox.  Anyway, I'll enjoy it while I can. :)

[Technology] Vala features

Here are a few nifty vala features I did not already know.



I can run "vala foo.vala" and it apparently does "valac foo.vala; ./foo".



Also, I can have preprocessing directorives like this



"#ifdef DUCK

stdout.printf ("QUACK");

#else

stdout.printf ("Woof");

#endif"



I can't seem to use #define, but I can do

"valac -D DUCK foo.vala"

which will define the symbol.



Hooray/boo for conditional compilation!

[GNOME] Final Report for GXml in the 2013 Google Summer of Code

The Google Summer of Code has ended, and GXml is spoiled with the fruits of labour:

• the autotools build system has improved


• documentation is more complete and more accurate


• many new examples across most classes, especially for C and JavaScript


• many bugs were flushed out and fixed (e.g. attribute syncing between underlying libxml2 xmlNodes and GXmlElements)


• it has a mailing list (gxml-list@gnome.org)


• new stuff




• document child management, node cloning




• new memory tests


• new error handling model




• new memory handling model (fixing leaks and improving performance!)


• improved API compliance


• bug-fix release (0.3.2) without API breaks


• imminent 0.4.0 with API breaks (pending some updated patches for XPath, Serialization, etc)

I've talked about those before (near the start and while at GUADEC) so for my report I'm going to focus on the outcome in terms of performance.



Look forward to 0.4.0 imminently, and happy hacking.

GXml's performance versus pure libxml2

One question people have had is the difference in performance between libxml2 and GXml, since GXml currently wraps it.  Things should be worse, as there's typically more code for each operation, but how large will the penalty be and will it matter for you?

Tests

I created a simple test suite with the four following tasks:

1. loading a file from disk


2. loading a file from memory


3. stringifying a document


4. saving a document to disk

The test suite is highly modular, and it's easy to add new tests.  For
each test, you define a setup function, a test function (the measured
test), and a cleanup function.  So if you'd like to see anything else in particular tested, let me know.

Environment

I've run it on a Lenovo ThinkPad Twist S230u with the following configuration

• Intel® Core™ i5-3317U CPU @ 1.70GHz × 4 


• 4GB RAM, SODIMM DDR3 Synchronous 1333 MHz (0,8 ns)


• 500GB HD @ 5400 RPM (HGST HTS725050A7)




• /home, including test files




• 24GB SSD (Samsung MZMPA024)




• everything outside of /home, including libraries 




• Fedora 19, x86_64


• libxml2-2.9.1-1.fc19


• GXml from git HEAD

Test Data

The test data was based on my updateinfo.xml files from yum, in particular the one found at: /var/cache/yum/x86_64/19/updates/gen/updateinfo.xml.  It contained 98743 different nodes over 11,136kB.  I created smaller and larger versions of it, resulting in

name	nodes	size (kB)
test3.xml	22 276	2 784
test4.xml	47 707	5 568
test5.xml	98 743	11 136
test6.xml	197 484	22 268
test7.xml	394 966	44 536

This testing could be improved by using diffferent types of files with different types of data.  Flatter ones versus deeper ones, for instance.  The different sizes were done by either duplicating the content within the root element or by deleting the second half of nodes inside the root element.  test5.xml represents the original updateinfo.xml

Measurements

Three values were measured.  One was time taken to complete a task (like load a file), using g_get_monotonic_time, which reports in microseconds.  One was memory used by the task after it completed, using mallinfo, in particular the uordblks field (total allocated space), and one was memory leaks (also using mallinfo, after we freed memory).

Procedure

I ran the tests once averaged over 10 trials for each combination of test and file, and then again over 25 trials.  Ways the procedure could be improved includes better isolation on the system from other processes, or providing more detail than the averaged scores, so we can detect any exceptional anomalies (e.g. some other process causes a file load to be delayed by hogging I/O).

Results

Keep in mind that GXml wraps libxml2 for most functionality, so we
don't expect it to be faster than libxml2, rather we want to see what
penalty a GObject wrapper (written in Vala) causes.

Memory Leaks

GXml was leaking memory like a sieve before the summer.  (0.3.2 includes memory leak fixes without the API breaks!), so I wanted to know what memory was left after these tasks from both libxml2 and GXml.  Luckily, neither had any in the cases tested.  (That does not mean there aren't any!  Kudos to those who find them (and more to do who patch them)).

Results

data	libxml2	gxml	diff
load disk
memory
test3.xml	20814019	23667584	1,1371
test4.xml	42604277	48477152	1,1378
test5.xml	86151738	98065217	1,1383
test6.xml	172261657	196126066	1,1385
test7.xml	344483559	392241280	1,1386
time
test3.xml	37547	56513	1,5051
test4.xml	66747	63797	0,9558
test5.xml	144234	161024	1,1164
test6.xml	284488	287911	1,0120
test7.xml	561406	564904	1,0062
load mem
memory
test3.xml	24988568	28866015	1,1552
test4.xml	51434229	59523841	1,1573
test5.xml	104192043	120665588	1,1581
test6.xml	208356730	241330737	1,1583
test7.xml	343791009	391564027	1,1390
time
test3.xml	44199	53860	1,2186
test4.xml	84215	71695	0,8513
test5.xml	172920	184735	1,0683
test6.xml	347157	359909	1,0367
test7.xml	572627	555519	0,9701
save
time
test3.xml	25610	24513	0,9572
test4.xml	52908	49175	0,9294
test5.xml	96449	98308	1,0193
test6.xml	192197	196295	1,0213
test7.xml	384343	395194	1,0282
stringify
memory
test3.xml	2735339	3136192	1,1465
test4.xml	5696496	6287776	1,1038
test5.xml	11394656	12592800	1,1051
test6.xml	22789264	25185552	1,1051
time
test3.xml	22873	26749	1,1695
test4.xml	46166	54537	1,1813
test5.xml	93205	111312	1,1943
test6.xml	198988	235645	1,1842

Discussion

loading documents from disk

 

When it comes to loading a file from the disk, we compared xmlReadFile versus gxml_document_new_from_path (which uses xmlParseFile). 



Memory usage differences are consistently ~14% higher. 



Time-wise, on smaller files, GXml tasks up to 50% longer than using libxml2.  I'm not sure why test4.xml is miraculously lower from this run.  You can see that the larger the file, smaller the difference, which makes sense, since most of the hardwork is done by libxml2 anyway.



loading documents from memory



With memory, again, we see a consistent increase between ~14-16%.



Time-wise, again GXml oddly performs better on test4.xml.  Elsewise, we see the same trend: there is little difference with larger files.



saving to disk



We don't report memory differences because GXml's save functionality cleans up its use of xmlSaveCtxt before it exits, so we can't (easily) see how much we used.  Neither leak, so there is nothing to see there.



Time-wise, it seems to take about the same length of time, but GXml may be trending to more.  This could be due to tasks like synchronising data that is initially stored just in GXmlNodes and needs to be copied into the xmlDoc of libxml2 to make it to disk.



stringification



Memory-wise, we typically see an increase of ~10-15%.  Note that they failed to handle the stringification of the largest file, test7.xml, which requires further investigation.  Stringification was done with xmlDocDumpFormatMemory.



Time-wise, the increase was ~16-20%. 

Conclusion

Regarding memory usage, if you use GXml for cases such as these, you can expect around a 15% increase in memory usage.  That makes sense, as GObjects are used instead of the light C structures libxml2 typically does.  One benefit in hwrapping libxml2 is that we don't actually create a GXmlNode for every xmlNode in a document, only the ones we use, so a pure GObject implementation might use more memory.



Regarding time usage, the difference for some operations is small, a couple percent, and for others, the difference is larger with smaller files, as big as 50% when loading a smaller file.  Larger files in those cases (such as loading documents) see less and less of a penalty.



I feel as though for many common applications, these don't represent a significant penalty (time taken in loading large documents is still a few dozen milliseconds), and can be worth the benefits in using a GObject API.

Going forward

If you're interested in more about GXml's performance, the test suite will be in gxml/tests/performance/.  Feel free to submit new tests and test files.



Regarding GXml, HEAD will be pushed out in a new feature release including the API changes, fancy new features, and contributions from others, including Daniel Espinosa, Adam Ples, Simon Reimer, and others.



Cheerio!

[Technology] Mozilla removing certificates

Mozilla removes certificate revocation lists from Firefox.  I wonder if this is a good idea.

[Technology] "Error: Unsupported type void, deriving from fundamental void"

I have an issue trying to use GHashTable as a property in an introspected GObject from Javascript (using gjs).  I was trying to create a test case, but I encountered this when trying to construct my object from gjs:



"Error: Unsupported type void, deriving from fundamental void"



The object was dead-simple, and derived from GObject, so I wasn't sure what the problem was.  Ultimately, it turned out that that was gjs's way of telling me it didn't have a definition for my constructor.  Yikes.  Ultimately, I had to specify a 'shared-library' attribute for the 'namespace' element in the .gir and .typelib files that gjs was using for introspection.  I wasted a couple hours trying to figure that out.  Whee.



For now, I filed a bug, 706906, requesting a useful error message when definitions aren't found, rather than ambiguously complaining about void types.

Writing the Object and test file

First I created a quick object using Vala for my test case.

namespace Foo {
            public class Bar : GLib.Object {
            public GLib.HashTable hashtable { get; set; }
            public Bar () {
            this.hashtable = new GLib.HashTable (GLib.str_hash, GLib.str_equal);
            }
            }
            }

Well, that was quick.  Next I wrote a small .js file

#!/usr/bin/gjs
            const Foo = imports.gi.Foo;
            var bar = new Foo.Bar ();

Compiling the Vala object and introspection files

Of ourse, first you'll need to compile your shared library, Foo.

valac --library=foo --gir=Foo-0.1.gir --vapi foo.vapi -H foo.h -g Foo.vala -X -fPIC -X -shared -o libfoo.so

If you try to run test.js now, it won't find the library and will report the error:



"Requiring Foo, version none: Typelib file for namespace 'Foo' (any version) not found"



To access Foo via introspection, we'll of course need to compile the .typelib too!

g-ir-compiler --shared-library=libfoo.so Foo-0.1.gir --output Foo-0.1.typelib

If you don't specify the name of the shared-library, that's when you'll see the earlier error, "Error: Unsupported type void, deriving from fundamental void" when trying to actually use the objects from gjs, as they're defined, they're only declared through their typelib



If you still see the Typelib file not found, it might not be in your GI_TYPELIB_PATH, so you might want to set that.  Lots of typelibs get installed to /usr/lib64/girepository-1.0/.  For my test case, I set GI_TYPELIB_PATH=. since my typelib is in the current directory.

GHashTable properties: the original problem

Now all I need to do is find a solution to my original problem, "Error: Unable to introspect element-type of container in GValue", where I can't access a GHashTable as a property. :\  (Now bug 706907)

[GNOME] Providing feedback on patches and branches

awesome advert:

Did you know that GXml has a mailing list now?  gxml-list at gnome dot org!

  

Finding time to review

 

A week before GUADEC, the spectacular Daniel Espinosa let me know of work he's doing on GXml serialization in a new branch.  Sadly, it's taken me three weeks to provide adequate feedback.



There were three obstacles to this. 

1. having my HP tc4400 laptop (her name was clarity, after Claire Danes) die shortly thereafter.  


2. going to GUADEC (there was a lot of new work to do while there!)


3. my thesis (sadly, I don't have my summer totally free)


4. other GSOC goals

I feel like such a long delay, even if the causes seem reasonable, is terrible for encouraging good contribution's like Daniel.  I'm lucky Daniel is currently  motivated and has goals.



Doing the review



Because the new work is on a branch, and the changes are a bit extensive, it was a bit challenging keeping track of all the changes.  That's opposed to a set of smaller patches or contained changes, which I might be able to analyse in parts.  Because of cross-file changes and some code-reorganisation, I ended up using emacs ediff and some hand-editing to ease my comparison.  Sometimes changes look bigger on the outside, until you realise that fundamentally a lot of the new logic is the same.



I finally ended up spending about 5 hours reviewing it, which feels a little excessive, and I hope I get better at it.  As a graduate teaching assistant at my university, I'm used to reviewing students' code (which is more predictable and less complex).  I think one problem is that I didn't want to miss anything; I feel as though a quicker and sloppier review might actually be preferable for its quicker return time, than having a thorough and careful one that takes forever to find the time to start.



Providing feedback



One of the hardest parts is providing meaningful and friendly resistance to changes.  I want to make sure that changes are safe (smaller and more precise ones are preferable to minimise new bugs) and necessary (changing APIs without a clear benefit is painful for existing developers), but I don't want to overly discourage a submitter.



I tried to ask specific questions about the motivations behind certain changes, and tried to propose smaller changes that could accomplish the same purpose.



Hopefully I will prove more responsive in the future and Daniel's work will improve GXml's serialization support. :D



Advice from you



I'd appreciate any advice you have for reviewing code and encouraging submitters.  I heard that cursing at contributors works well for some well-known maintainers, but I don't think GXml is quite popular enough to afford that level of abuse. :)

[GNOME] GUADEC 2013: Talking Heads

I survived my trip through Toronto, Amsterdam, and Prague to Brno.
I'm becoming pretty good at flowing through foreign countries without
saying a word. I'd like to thank the GNOME Foundation for making this possible:

The four days of talks have ended, and it's been honestly amazing.  Here are my thoughts on the ones I attended and liked.  (Let me know if you find any errors.)

The AGM

The annual general meeting was informative and entertaining, as usual.
It's nice to know we can have fun while getting serious business done.
Some neat things I learnt is that there's a pre-built image for
virtual machines with a complete jhbuild available to download. Also,
there's now HowDoI on the GNOME Wiki. For localisation, 52 languages
have over 80%. Outreach has helped increase participation of women in
the GNOME project. We also got to hear about GNOME Asia and GNOME
India. From the foundation report, the privacy campaign was a good
success. Noted was that this September will be the 30th anniversary
of the GNU Project!

Keynotes

Ethan Lee on gaming in Linux

Ethan works on porting popular indie games to Linux. It's great seeing
more games available on Linux through the Humble Indie Bundle and
Steam for Linux. Game availability is one of the few remaining
barriers, so it was nice to hear from someone working with games on
Linux about challenges there and what we can do to help facilitate it.

Endless Mobile

Endless Mobile wants to get a smartphone and eventually a computer to
most of the world. They're targetting the market segment of people
who can afford to live in their area but can't really afford a
computer, because while many items are priced locally, electronics are
largely priced globally, and a typical device can exceed a potential
customer's annual earnings.


So, simple devices, near Raspberry Pi price levels and capability,
with intelligent, great design built atop free software. The
hardware has a stylised appearance, and a core part of their value is
their app collection, which is embodied not of fun entertainment, but
a lot of practical software, which can help with cooking, farming,
business, education, etc.

ZaReason

ZaReason, proprietor of Linux laptops and desktops, came to discuss
their goals (provide great, open computers that work well), their
challenges (hardware that restricts freedom), and encourage GNOME to
continue to promote a Free ecosystem. They had some of their
hardware, and I was thrilled by its light weight.

Talks

Colin Walters on GNOME OSTree

GNOME OSTree is being actively used for continuous integration, on a
32-core, 48GBRAM machine. It's working great for testing patches and
git commits as they happen, resulting in quick detection of errors,
and helping improve the overall stability of the stack it tests. It
focuses mostly on the OS and not so much on apps, though it does have
a concept of profiles (sets of packages) with some including apps, for
development and testing purposes. Could help provide atomic updates
and easy rollback, and help decouple the OS from apps.

Fabiana Simões on how not to report User Experience bugs

Fabiana helped emphasise that UX (User Experience) bugs are important,
even if they don't prevent software from compiling and running.
Evaluating user experience issues can be challenging, and encouraging
good UX bug reporting is helpful. Highlights include not to use the
following useless phrases:

• "I think X should be Y"
  


• "It sucks/it's not user friendly/intuitive"
  


• "Most users …" without doing actual research
  

There were also some recommendations on information users should
provide regarding a user experience bug, including what they were
doing, why they were doing it, what steps they took, what were they
expecting, and what happened. What the user felt, saw, and did are
important.

Meg Ford on GNOME in Open Source communities

I didn't catch this entire talk, but was interested in Meg's points
regarding inclusiveness and exclusive attitudes. It's sad to hear
about issues regarding overt discrimination and sexism. I enjoyed the
activity surrounding small local groups like in Chicago.

Lennart Poettering on Sandboxed Applications for GNOME

This was a delicious talk, touching quite a bit on systemd and the
future of applications in GNOME. Basically, isolation for stability
and security, with support in the kernel and through cgroups to help
control apps. Single files bundling apps from the user's point of
view, actually a compressed multiarch loopback filesystem, optioning
containing their own versions of libraries to avoid library version
dependencies in the OS. App distribution through community stores,
not a single canonical source. Unprivileged installation. kdbus for
controlled IPC of even large data between apps and the system or even
other apps, and Portals, intents-like method of providing interactive
security around this. The need for a stricter hierarchy file system
spec and reduce some distribution differences.


I'm really excited about how this will change my interactions with my
computer.

Juan Pablo Ugarte on building UIs in Glade

Juan gave a pretty presentation showing recent work for CCS support in
Glade, with pretty things like gradients, shadows, animations, etc. A
demo of a Baccarat game helped demonstrate just how completely you can
style your windows and widgets. To my great delight, he then revealed
that the presentation was actually built using Glade itself! And was
being run by the new Glade Previewer. (Disclaimer: Glade is not
intended to efficiently build beautiful presentations, though it can.)

Lightning Talks

Some non-comprehensive highlights were that EasyTag, the audio tagger,
has seen some recent activity again. Boxes has had work on copy-paste
between host and guest and usb redirection. The gettext maintainer,
Daiki Ueno, came, and it's seem some exciting new features like
support for GtkBuilder, Vala, Lua, and Javascript, as well as
multiline strings. Work for systemd in the user session advances the
cause of the faster login. Also, the Cantarell font has seem some
refinement. There was a lot more.

Philip Withnall on testing web services

Philip helped address problems with testing against web services, with
the unpredictable nature of dealing with a remote host. The solution
appears to be recording a trace of normal activity for your operation,
and then testing against that rather than the remote server itself.

ownCloud

The future of open source cloud services is growing rapidly and the
cool keeps flowing. Syncing of files, calendars, and contents.
Integration with GNOME Online Accounts. To come is integration with
Documents, Notes, tentatively RSS, Maps, Music, mail, bookmarks, and
more. Syncing should be comprehensive enough to eventually include
settings, dot files, etc, so you could restore a lost installation
from your ownCloud. Vitally, Mines' high scores. For security, the
client could encrypt data before arriving at the server, but if you do
this, some apps won't work well (since they can't read your data).
Right now, I think it's something I'd like to run within my own VPN
for privacy, practically providing me with a 'Google in a box'.

Emmanuelle Bassi on Clutter

The state of Clutter was discussed, along with a proposal to move more
functionality into Gtk+. There was a bit of technical discussion
during the talk and interested parties generally liked the idea.

Tristan van Berkom on Glade and GtkBuilder's UI developer experience

Tristan showed off some long-desired improvements to Glade and
GtkBuilder. He talked about the use in guiding users (here:
developers) on the right path, with the idea of improving the tie-in
between GtkBuilder and actual class code, especially regarding
callbacks and such. Also, you can finally click-and-drag UI elements
onto the graph (whee!) and intelligent grouping of widget properties
by section.

Matthias Clasen's guide through GtkApplication

Matthias led us through a new tutorial of how to build a modern
GtkApplication, emphasing important parts like application-id,
embedding of resources into the binary, using templates and new
macros. Demonstrated was newer candy like GActionMap, GSettings,
templates, GtkStack, GtkSearchEntry and Bar, GtkRevealer, GtkListBox,
GBindings, and more. Wow!

Conclusion

The conference has been really amazing. I'm surrounded by my greatest
programming heroes and have gotten to be immersed in the shared
excitement over GNOME's future.


I'm looking forward to the talks next year in Strasbourg, and the
Boston Summit in Montréal this October.

Heading to Brno

Just in the airport, about to fly from Toronto, Canada, to Prague and then catch a bus to Brno.



Two things I thought I'd note:

• It's going to be very warm/quite hot in Brno for the next 10 days
  The Weather Network  Temperatures above 30°C and little chance of rain.


• Student Agency, http://www.studentagencybus.com/, has very inexpensive bus fares from Prague to Brno.  $10CAD (2400HUF).  Whee!

GXml: Summer of broken API

Welcome back to the wonderful world of GXml.  Here's an update on progress so far.  (Also, thanks to Daniel Espinosa and Adam Ples for recent contributions to serialisation, XPath support, and bug fixes.)

Code

For those interested in the code so far, it's in its own branch thanks to the abundant API breakage (detailed below): 

https://git.gnome.org/browse/gxml/log/?h=gsoc2013



My plan is to release another in the 0.3.x series without major API breakage, and then release 0.4 soon (during GUADEC) with the major API changes.

GUADEC

Thanks to sponsorship from the GNOME foundation, GXml is going to Brno!  In previous years, I've gotten to know some of you.  This year, I'm going to bug you about your code and, if you use GXml, find out what will get you to use GXml. :D

Memory Magic

Changing models

Before, when you obtained a reference to a node from GXml, you owned it and had to unref it.  However, with GXml, nodes are only really useful while their document exists (which manages things like attribute synchronisation with the underlying libxml2 structures).  Consequently, and to simplify reference handling for users, a GXml document alone now owns references to its nodes, and is entirely responsible for freeing its memory.  All a user of the library must do is unref their GXmlDocument when they're done with it.

Valgrind

Valgrind was used to identify memory leaks, where we failed to free libxml2 data or where we created reference cycles.  I'm hoping to write a useful guide on using valgrind later.  It required a lot of suppression file writing and testing, too, to determine which memory from glib and libxml2 could be released by a user, and which couldn't.

Tests

We have a collection of small valgrind tests now so it should be harder to introduce new memory leaks in the future.

API Chaos

DOM spec compliance: GXmlNode

Formerly, XML nodes were called GXmlDomNode.  That was to avoid namespace conflict in languages where Node could mean GLib.Node or GXml.Node.  However, that meant a lot of extra characters in C.  Since I started using DomNode, it's also grated on me, especially because it's not the name known to the DOM spec.  Consequently, pursuant to earlier blog posts and IRC discussions on the matter, it's now GXmlNode.  Dun dun dun!



Attribute might become Attr and Implementation might become DomImplementation, and DocumentType might become DocType.  Feel free to comment on your thoughts on those compliance questions.  I don't want to change entity names again the future.

Error Reporting Revolution

Regarding an earlier discussion, GXml has been misusing GError just because try-catch exception handling is addictive.  Ultimately, after some discussions and analysis, we've switched from GErrors to issuing g_warnings (and having a last_error variable a user can check after running a function if they're unsure of their code's correctness).



Also, all but one DOMException from the DOM Level 1 Core is now tested for!  (Before, only a few actually were.)  The one that isn't so far is whether a node is readonly, since GXml doesn't have a concept of read-only nodes yet. :)

Educational Euphoria

Documentation

Every property and function should now include a reference to its definition in the DOM Level 1 Core spec.  It should also specify the version of the spec the property or function complies with, so that when we move towards Level 2, etc., you can know what to expect.

Examples

More examples exist under examples/c and examples/js now, and there'll be more to come.

Gritty Reality

Writing test patches for projects like yelp, glade, dconf, and libgdata has helped identify a few bugs or failings in the API which have been fixed.  If you're working on those projects and wonder why you haven't seen a patch yet, it's because they're in flux and need to be re-written once I stop changing the API above. :D

A bold new future

Going forward, there's still a lot to do.  Finalise the API, integrate patches accumulating in bugzilla and in branches (XPath support courtesy Adam Ples?!), serialization update (courtesy of Daniel Espinoza) and measure performance.

[Technology] Firefox, libraries, and architectures

So, my laptop is unusable at present, so I'm trying to use school computers.  Trying to check my e-mail (GMail, which gets my University e-mails), I am told that the installed browser (Ice Weasel) is 'too old'.  OK, so I'll just locally install a newer Firefox.

$ firefox
XPCOMGlueLoad error for file ~/.local/opt/firefox/libxul.so:
libdbus-glib-1.so.2: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

I double check, and indeed, libdbus-glib-1.so.2 is in /usr/lib/.



Running

$ LD_DEBUG=libs firefox

prints out, among other things, the search path it uses, and confirms that Firefox's website provided me with a 32-bit binary, expecting 32-bit libraries, on a system that does not have many 32-bit libraries. :D  Not even 'LD_LIBRARY_PATH=/usr/lib firefox' can save me now.



Annoyingly, Firefox's website doesn't seem to offer an easy way to choose which architecture (beyond the OS and language) you want, so I just went here:



http://releases.mozilla.org/pub/mozilla.org/firefox/releases/latest/linux-x86_64/en-US/



And voila!

[Technology] gtk-doc failing to load chunk.xsl

While working on GXml, trying to generate its documentation, I ran into this:

I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl
            warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl"
            compilation error: file /usr/share/gtk-doc/data/gtk-doc.xsl line 10 element import
            xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl
            

This was not happening last week, so it must be my upgrade to Fedora 19.  I tried a few different things, and ultimately discovered RedHat bug 428531 which helpfully suggested reinstalling docbook-style-xsl. 



So, on Fedora,

yum reinstall docbook-style-xsl

After that, it finally continued and finished building. :)

[Technology] Valadoc not working in Fedora 19

While working on GXml, I ran into a problem, but then I fixed it, and life is good.



Valadoc failed to run earlier.  It was complaining about missing something like libgraph.so.25.  I'm not sure what the specific version number was now, but checking my system, I didn't have a libgraph.so anywhere.



When I tried to recompile valadoc, it returned errors like
"charts/chart.c:527:2: error: too few arguments to function 'aginit'"


Checking chart.c, I realised that this all has to do with libgvc, the GraphViz C library.  Version 2.30 breaks API with 2.28.  Fedora 18 shipped 2.28.  Fedora 19 ships 2.30 now, and I just upgraded to Fedora 19.



After chasing errors and reading documentations and sometimes source code, bug 703688 was born, and includes rough patches that fix it on my system.  Yay.

[Technology] Fedora 19

Here's my laptop

• Intel Core 2 Duo at 2.00GHz. 


• Intel 945GM


• 2GB RAM

Summary



First, I'd like to say I'm grateful for all the amazing work the designers and developers have put in to Fedora 19 and into GNOME 3.8.  That said, a lot of the things I noticed were things going wrong. 

• FedUp's follow-up grub2-install (as instructed by Fedora's documentation) encountered a catastrophic grub error, and weirdness with its assistants, and some yum/rpm weirdness. 


• GNOME Shell has a variety of little bugs (wallpaper, jerkiness, message tray responsiveness, painful design decisions)


• I can no longer run "GNOME" when using dual-monitors :(


• new applications have a blank look and aren't very useful yet (e.g. Timers and Alarms stop if you close the window; Weather couldn't find any cities)


• GNOME Online Accounts still doesn't work with 2-factor authentication for Google (Contacts and Documents are noticeably less useful) (UPDATE: workaround does work, though I had to try it 3 times)


• Tracker is finally usable on my system! :D  I can finally search for files!

I've also put in red the worst problems, and in green the greatest delights.  I'll be linking or submitting bugs when I have time over the next month.  I still look forward to a future where there's a QA process that can leave me confident in recommending Fedora (or any Linux) to friends.

FedUp Upgrade

Mostly straightforward.

• look forward to a UI in the future, so I wouldn't have to tell normal friends to open the command-line. 


• look forward to when the work of yum distro-sync will be handled by FedUp


• look forward to when the work of grub2-install will be handled by FedUp (and won't break)


• I really enjoyed the GNOME Help video and stuff.

Here are things I noticed

• Following the instructions from the Fedora Documentation manual, I ran grub2-install and it gave me errors. 




• /usr/sbin/grub2-bios-setup: warning: the device.map entry `hd0,1' is invalid. Ignoring it. Please correct or delete your device.map.
  /usr/sbin/grub2-bios-setup: warning: File system `ext2' doesn't support embedding.
  /usr/sbin/grub2-bios-setup: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
  /usr/sbin/grub2-bios-setup: error: will not proceed with blocklists


• Rebooting led to the terrifying grub_rescue> prompt, and was not able to boot.


• I booted with a LiveCD, mounted my HD, chroot, and re-ran grub2-install.




• FedUp doesn't do anything for new applications like GNOME Clocks.  I used yum with the grouplist, groupinfo and groupupdate commands to identify new, interesting software and ensure it got installed.


• Some libraries were missing or the wrong version, so consequently emacs wouldn't start ("emacs: error while loading shared libraries: libgnutls.so.26: cannot open shared object file: No such file or directory"), and this was fixed by yum distro-sync.


• Setup assistants didn't start properly.




• After my first reboot, there was no assistant. 


• After my second reboot, after logging in, I had a session-specific assistant which lost my previous keyboard layouts (English, International; English, Dvorak; and Greek (symbols, yay!))




• It asked to connect to my router, but no matter which nearby router I clicked on, it always prompted me for the password for the last one in the list (which was not mine); thankfully, the networking menu in the top bar worked.


• It launches GNOME Help which has sexy videos; however, some of the videos have captions, whose # of lines change, and keep jerking the video up and down.  (See below for more complaints about one UI element altering the spatial position of others.)




• After the third reboot, a system-wide assistant started, and asked me to create a new user; I didn't want to, so I didn't, and the assistant went away. 




• On a secondary machine, I ran into an issue where yum update and stuff would not work, complaining about RPM errors.  I used rpm --rebuilddb and they went away.




• This machine I did not do grub2-install and so it booted fine.


• The setup assistants might have appeared when they were supposed to this time

Shell and Desktop

• I like having a right-click to change the wallpaper (is that new to GNOME 3.8?)


• I like some of the new animations


• I like the larger window thumbnails in the activity overview


• File Search is pretty usable!  Thanks to the fact that Tracker is almost usable on my system now (it has historically consumed ridiculous amounts of IO and CPU; it's still not perfect, if you look at Tracker below)


• The volume change overlay (when I use media keys) nicely animates the increase and decrease in volume now.  Neat.

Problems

• I'm not sure what exactly controls the wallpaper now, but a number of my wallpapers won't load.  I used to use Mirror (that's the one with the water and mountains in the distance) and it's still there and the path is set correctly (in org.gnome.desktop.background picture-uri) but nothing appears.   Also, adwaita-timed doesn't work either.  However, the new schroedinger-cat one works, and so do a number of others.


• The login transition is jerky.  Probably my video card.


• When at the lock screen, the icons in the top right (volume, wifi, power) group tightly together, and clicking any of them only brings up the volume control.  (This happened in GNOME 3.6 as well.)


• Activities' list of applications seems to have lost categories.  This reduces discoverability and makes finding things very onerous.  I can search for things that I anticipate existing, but I can't be reminded of things I don't anticipate.




• Apparently there are application groups but I can't find any UI with which to define them.




• The Message Tray is hard to pull up now.  Before, it popped up too easily.  Basically, I can bring my mouse to the bottom and drag it down forever and nothing pops up, I have to start jerking it around and it's tiring and inconvenient.  Also, I used to think there was a hot corner in the bottom right to pull it up, but I suppose I was wrong (or it's gone).




• The Message Tray is also invisible in Activities mode now (was it before?).  I didn't realise that messages had accumulated because I didn't realise that I wasn't getting it up at first.  Whoops.


• I wonder what a user who doesn't already know that there's supposed to be a Message Tray would do; I can imagine them not discovering it for weeks/ever.


• It still has that UI fault where one element modifies everything around it by pushing up my desktop rather than just climbing overtop it.  It's as bad as web pages and browsers that make a top message appear that pushes down all the web content, causing early mouse clicks to miss and misclick, or like Google Maps in my phone changing where the "Get Directions" button is after I've typed in locations, so I end up pressing the wrong thing.  I wish applications would stop affecting the spatial location of other things.




• GNOME Classic uses OpenGL, apparently, because now I can't use GNOME at all with dual monitors.  OpenGL on the Intel 945GM has a 2000px width limit, and my screen becomes 1024+1920 pixels wide with a second monitor plugged in; so, now I have to log in with one screen, then use metacity to replace mutter.  I used to be able to add GNOME Panel as well, and I used to still have a wallpaper, but gnome-panel doesn't seem to be packaged any more, and I don't know who handles the wallpaper any more.  (Not nautilus, apparently.)

 Applications

•  GNOME Weather exists as an application preview.  It has the same problem as a few other new ones where you open it and you just get a large grey window with nothing in it.  "What is this? What does it do?" Eventually I noticed the "New" button hiding in the corner, but it couldn't find any cities; I guess that's why it's a preview.




• I look forward to when it will determine my local weather based on my IP address.




• GNOME Clocks has the same problem as Weather, where you open it and there's ... nothing.  




• Once you've manually defined some clocks, clicking on one enlarges the time and adds a minimum amount of new data (sunrise and sunset).  Unfortunately, it also loses the pretty picture.  So, right now, expanding a clock is almost pointless.  


• I liked the Timer and Alarm sections.  However, if you close the GNOME Clocks window, those die.  So, unless I want the window open all the time, I cannot actually use the Alarm for anything.  


• The application is might large (spatially) given what it works with.  It makes working with a Timer or an Alarm (or a clock) seem onerous.  It's information I think I'd want in my calendar drop down, instead.




• GNOME Font Viewer isn't new, but I was actually missing it (didn't come through an upgrade at some point, apparently; hooray for manually going through yum group*)




• Most fonts tell a prescribed story, but some show randomised gibberish; I wonder if it's a bug or not.




• GNOME Contacts can't be tested for me until GNOME Online Accounts works with Google (see below) (UPDATE: a work around lets me connect again, yay) 




• It's pretty slow and the window becomes unresponsive during most actions.


• There are little popdowns after I do things like link contacts that don't disappear and instead wait for me to click an x, and instead of replacing one another, overlap. O_O


• A lot of space is wasted with HUGE contact boxes in the list to the left, so you can only see about 6-7 people at a time.  Ugh; I should start calling this the Texan design fallacy.


• Doesn't really indicate from which source each one comes; will fail to edit some and I am not allowed to understand why




• Bijiben, I assume, is another preview application.  It seems a bit like GNote or Tomboy but wastes a bit more space; lots of basic features like hyperlinking and lists didn't seem to work yet despite having UI elements; lots of warnings on the terminal.


• Nautilus 




• has a LOVELY NEW TREE OPTION for list view




• sadly, if you show the Place column for list view, a long path won't be shrunk/ellipsised, but the filename will, so I couldn't read files when I went a little deeper :(




• File Search is almost usable (see Tracker below and GNOME Shell above)!  The main problem is that after you start a search, I/O is pillaged with "nautilus [nautilus-search]".  I think that might be them doing something like find and not them using Tracker, though. 




• DevHelp




• tops of pages are still obscured by the title of the section.




• Rhythmbox is a little prettier.  




• adding new music got weirder (maybe in GNOME 3.6); there's now an Import window and it lists tracks in directories it's checking, but the trick is, it's not actually adding them to your library yet.  It's now a two-stage thing, of tell it to find things, wait interminably for it to find them, and then click Add, and then click close.  I would have thought that Add would start the import process, and I wouldn't have to wait around for it to find results.  Tiresome.




• Metacity didn't have keybindings set for alt-tabing between windows any more.  Perhaps this is related to new keybindings for Mutter/GNOME Shell that allow Super+tab to switch applications.  (I still use Metacity because Mutter's compositor using OpenGL can't handle a dual monitor setup with the Intel 945GM ;_;)

Settings 

• Network Settings 




• crashes when I was setting up a hot spot.


• if I choose to forget a preferred network, the settings gear doesn't disappear immediately; if I click the gear, it crashes.




• GNOME Online Accounts doesn't work with Google, at least when you're using two-factor authentication.  It apparently is blocked on OAuth2 support for CalDav which Google recently added and which e-d-s now needs to support.  There's apparently a workaround involving a one-time application-specific password from Google, which worked for me with GNOME 3.6, but doesn't in 3.8.




• UPDATE: workaround still works




• Tracker almost works!




• tracker-file-miner no longer hammers my system all the time with persistent heavy IO!  It almost works as advertised.


• it was also able to index my selected directories in 30 minutes, instead of indexing forever (I assume it must have been caught in some loop before)


• sadly, there are an abundance of GDBus timeout errors in .xsession-errors from Tracker, concerning extraction of metadata from virtually everything


• the next time I logged in, it took 40 seconds and iotop and top reported tracker-store was to blame

[Technology] "error: symbol 'grub_term_highlight_color' not found."

I just upgraded from Fedora 18 to Fedora 19 and am a bit sad to run into a pretty horrific error when following the published upgrade instructions, again.



I consider this link to be the official upgrade instructions:

http://docs.fedoraproject.org/en-US/Fedora/19/html/Installation_Guide/ch18s02.html

That said, it's pretty hard to find.  Additionally, there are also these pages:

https://fedoraproject.org/wiki/FedUp

This next one is probably also useful, but incredibly more cryptic for a "normal" user:

https://fedoraproject.org/wiki/GRUB_2



So, despite having to use the command-line for FedUp (Anaconda doesn't work any more), FedUp itself ran pretty smoothly for me.  You'll note that the instructions tell you to update/reinstall grub.



After running the provided grub2-install command, I received the following warnings and errors:



/usr/sbin/grub2-bios-setup: warning: File system `ext2' doesn't support embedding.
/usr/sbin/grub2-bios-setup:
warning: Embedding is not possible.  GRUB can only be installed in this
setup by using blocklists.  However, blocklists are UNRELIABLE and
their use is discouraged..
/usr/sbin/grub2-bios-setup: error: will not proceed with blocklists





That sounds pretty alarming, but hey, if it didn't proceed, and then what could go wrong?  Reboot, and ...



error: symbol 'grub_term_highlight_color' not found.

grub_rescue>



Well, that's horrifying.



The best explanation of how to fix this (at least using a live USB key, if you have one handy, preferably from a recent Fedora (e.g. F19 itself :D)) that I found is this Ubuntu article:

https://help.ubuntu.com/community/Grub2/Installing#via_ChRoot

Particularly the section "via ChRoot".



Basically,

• get to a command-line


• mount your system's root partition somewhere (not /tmp)


• mount special directories (see article)


• mount your boot partition to /boot (if it's separate)


• chroot into your system's root partition


• run "grub2-install --recheck /dev/sda" (or wherever)


• etc.

That fixed it for me.



Boot loader errors are terrifying for "regular" users, and it's sad that Fedora 19's instructions can lead to it.  Sigh.

[Technology] GNOME Shell, memory usage, CPU usage, and graphics

I have a "Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller" according to lspci.  It's in an HP Compaq tc4400.  It's nice.  However, it doesn't like GNOME Shell when it comes to multiple monitors.



The reason is bug 699705: "Intel Gen 3 Rendering Limits are Pitiful".  A solution might be coming under the name "per-crtc pixmaps" in a future edition of the XRANDR protocol, requiring support in GNOME Shell as well.  Basically, the way memory is allocated right now, a screen that spans multiple monitors becomes too big, and GNOME Shell can't handle it.  It used to crash; now it just takes 100% CPU to draw VERY SLOWLY.



I own a nice second monitor, and I've suffered under using GNOME Shell on just one screen for too long.  Consequently, I'm now back to just using gnome-panel and metacity, and I've noticed something weird.



When I'm using just a single monitor, using GNOME Shell, if any application (with a window, at least), uses up to 50% of available RAM (e.g. Firefox, Chromium), my system slows to crawl and starts swapping like crazy.  In theory, there's still a lot of memory available, though. 



When I use metacity + gnome-panel, whether I'm using one monitor or two, I have Firefox up to 64% of available memory (nauseating) and there's no swapping yet!



Does using GNOME Shell somehow double memory usage, double what's reported under top?

[Technology] DOMException, its nature and appropriateness for GError reporting

I've had to recently study the nature of the various DOMExceptions specified by the DOM Level 3 Core spec, to better understand whether we want to use the GError reporting system of GLib in GXml, or whether we want to use something else.  I defaulted to using GError, because the spec presents them as exceptions to be raised, and because I was used to handling libgdata errors (which are legitimately run-time errors) with GError.



The GLib Error Reporting documentation is pretty clear about when it's appropriate to use GError: basically, only when it's a run-time issue that a programmer can't reasonably anticipate.

First and foremost: GError should only be used to report recoverable runtime errors, never to report programming errors. If the programmer has screwed up, then you should use g_warning(), g_return_if_fail(), g_assert(), g_error(), or some similar facility. (Incidentally, remember that the g_error() function should only be used for programming errors, it should not be used to print any error reportable via GError.)



Examples of recoverable runtime errors are "file not found" or "failed to parse input." Examples of programming errors are "NULL passed to strcmp()" or "attempted to free the same pointer twice." These two kinds of errors are fundamentally different: runtime errors should be handled or reported to the user, programming errors should be eliminated by fixing the bug in the program. This is why most functions in GLib and GTK+ do not use the GError facility.

Below are my feelings on which DOMExceptions constitute programming errors (and shouldn't use GError) or run-time errors (and should). I look at run-time errors as consequences of the environment in which GXml is used (e.g. is it the fault of a document we're reading in, the content of which we have little control), and programming errors the direct result of a programmed call that's supplying bad data or misusing the document.



I find most of the DOMExceptions to be programming errors.  If you believe that something is more properly a run-time error and deserves GError reporting, please comment and explain why!  I am not an expert.  Like, for invalid characters, GXml might be used by a GUI where a user is entering data, and enters characters that aren't supported.  I think input checking like that should be handled in the application instead of in the GXml library, though; it shouldn't get as far as trying to actually set an attribute with bad data.  Perhaps we could provide convenience validation methods to GXml, though.  Thoughts welcome.

R: Runtime, GError
            P: Programming
            N: N/A
            
            Defined Constants
            
            N    DOMSTRING_SIZE_ERR
            If the specified range of text does not fit into a DOMString.
            we don't have our own DOMString type, we just use gchar* arrays, which don't really have 
            a fixed limit, just as much as you can alloc in a single go.
            
            P    HIERARCHY_REQUEST_ERR
            If any Node is inserted somewhere it doesn't belong.
            this would be a programmer error, like trying to append a node to be a child of itself.
            
            P    INDEX_SIZE_ERR
            If index or size is negative, or greater than the allowed value.
            programmer error, they should check size before accessing non-existent members of lists
            
            P    INUSE_ATTRIBUTE_ERR
            If an attempt is made to add an attribute that is already in use elsewhere.
            programmer error
            
            ?    INVALID_ACCESS_ERR, introduced in DOM Level 2.
            If a parameter or an operation is not supported by the underlying object.
            nclear as to when this might happen; property of a document or implementation or the DOM?
            
            ?P    INVALID_CHARACTER_ERR
            If an invalid or illegal character is specified, such as in an XML name.
            I'd almost think it's a run-time error, because it probably reflects an issue with the 
            document we're working on.  Invalid characters are related to the XML version of a document,
            and which features our implementation supports.  Right now, we basically don't deal with 
            this (!).  libxml2 has version information, of course, but I'm not sure how it handles 
            invalid characters yet.  TODO: figure this out.  
            However, I think of it more as programmer error, because almost all the methods its 
            associated with are where the programmer provides a string that might contain it, rather 
            than just accessing a string already in the Document.  The other ones involve bringing
            foreign nodes into documents, and the programmer has the option of checking version 
            information and characters beforehand to ensure compatibility
            *Document.adoptNode
            Document.createAttribute
            Document.createElement
            Document.createEntityReference
            Document.createProcessingInstruction
            *Document.importNode
            Document.renameNode
            Node.prefix.set
            Element.setAttribute
            DOMImplementation.createDocument
            DOMImplementation.createDocumentType
            
            ?    INVALID_MODIFICATION_ERR, introduced in DOM Level 2.
            If an attempt is made to modify the type of the underlying object.
            Not really specified for any methods
            
            ?    INVALID_STATE_ERR, introduced in DOM Level 2.
            If an attempt is made to use an object that is not, or is no longer, usable.
            Not really specified for any methods
            
            P    NAMESPACE_ERR, introduced in DOM Level 2.
            If an attempt is made to create or change an object in a way which is incorrect 
            with regard to namespaces.
            The result of bad input from a programmer, for qualified names.
            DOMImplementation.createDocument
            DOMImplementation.createDocumentType
            DOMImplementation.createAttributeNS
            DOMImplementation.createElementNS
            DOMImplementation.renameNode
            Node.prefix.set
            
            P    NOT_FOUND_ERR
            If an attempt is made to reference a Node in a context where it does not exist.
            Programmer error, they're specifying the node in reference, so like with insertBefore, 
            removeChild, etc.
            
            ?RP    NOT_SUPPORTED_ERR
            If the implementation does not support the requested type of object or operation.
            We couldn't don't deal with the features of our implementation or XML versions (that's bad, 
            but oh well); not exactly sure where this would fall.  Sometimes it seems like it would be 
            a programming error (trying to adopt a Document node into another Document with adoptNode) 
            but other times, like when creating a document, I could see that being a runtime error.
            
            ?    NO_DATA_ALLOWED_ERR
            If data is specified for a Node which does not support data.
            Currently nothing raised it according to the spec, and there aren't any obvious cases 
            where I want to.  
            
            ?PR    NO_MODIFICATION_ALLOWED_ERR
            If an attempt is made to modify an object where modifications are not allowed.
            We currently don't have a concept of a read only node, and thus no way to check. I'm not
            sure if libxml2 has a concept of readability either.  Its common for most nodes to want to 
            raise this, so perhaps it's a real use case we should support, but even then, it feels like
             something that isn't variable at run time, and that a programmer might be able to reasonably 
            anticipate and check for.  
            
            P    SYNTAX_ERR, introduced in DOM Level 2.
            If an invalid or illegal string is specified.
            Probably a programmer error, if they're the ones specifying strings.
            
            P    TYPE_MISMATCH_ERR, introduced in DOM Level 3.
            If the type of an object is incompatible with the expected type of the parameter 
            associated to the object. 
            Only used by DOMConfiguration.setParameter, which we don't support.  This seems like a 
            programmer thing, anyway
            DOMConfiguration.setParameter
            
            P    VALIDATION_ERR, introduced in DOM Level 3.
            If a call to a method such as insertBefore or removeChild would make the Node invalid 
            with respect to "partial validity", this exception would be raised and the operation 
            would not be done. This code is used in [DOM Level 3 Validation]. Refer to this 
            specification for further information.
            
            P    WRONG_DOCUMENT_ERR
            If a Node is used in a different document than the one that created it (that doesn't 
            support it).
            Definitely a programmer error.