Mageia 4 on Lenovo G550

I am in the process of upgrading a number of  Lenovo G550 laptops to Mageia 4. I have been a Mandriva user since the 90s, but switched to Mageia around the version 2 release as Mandriva simply could not cut it with regards to stability. I hope that these notes might help others solving some issues on these laptops

Network errors on eth0:

If the ethernet adaptor according to lspci is "Ethernet controller: Broadcom Corporation NetLink BCM5906M Fast Ethernet PCI Express (rev 02)" then set the MTU=1000 (in contrast to default of 1500) as per a previous posting.

BCM4312 wifi driver:

If you are unlucky still to have Broadcom wireless hardware in your G550, then some work lies ahead. This specific hardware identifies itself to lspci as

Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01)

Mandriva gives you the option to use the new dkms-broadcom-wl package, but it simply did not want to install on the default 2.6.39 kernel due to DKMS build failures. I decided to settle for using the firmware-dependent b43 driver instead. For this the b43-fwcutter package had to be installed and the firmware downloaded from openwrt and unpacked.

Edit /etc/modprobe.conf and add the line

options b43 pio=1 qos=0 

(Src: OpenSuse Forums)

As root, run the following commands

b43-fwcutter -w /lib/firmware /path/to/unpacked-broadcom-wl/linux/wl_apsta.o
modprobe -r b43
modprobe b43

Finally setting MTU=1000 as was the case for the ethernet hardware, solved the dropping of packets.

Lacklustre performance:

If you are running KDE, uninstall kmail (there are better email clients), virtuoso & nepomuk.

Faking it with Gradle Repositories

There are days with Gradle when you need to pull files from a location that is not a Maven or Ivy repository. Gradle does provide a flatDir repository, but that is restricted in that files have to be local and they can only be referenced as :artifactId:version. As a regular Gradle user you probably want to use the group:artifactId:version or group:artifactId:version:classifier@ext format.

What if you want to pull from say Sourceforge, Google Projects or a legacy build artifact server ? There used to be a repositories plugin for Gradle, but it no longer seems to work with later Gradle versions. The good news is that it is possible in many cases to achieve this with Ivy + pattern layout.

Ivy usually requires an XML file (Ivy file) to describe its transitive dependencies, but in Gradle if the Ivy file does not exist, then it is simply assumed that there are no transitive dependencies. This is good for working with arbitrary artifact stores as they will not have such files. Managing transitive dependencoes are now up to you, the build script author, but you probably know this anyway as you are already doing something that is not of the ordinary.

In concept.gradle the artifact pattern string contains a number of fields. Those in square brackets are field names, those in parenthesis are optional sections.

To get a better understanding of what these fields mean, I suggest reading the Ivy terminology page. For now let's just see how the standard Mavane items you are familiar with in Gradle will map to these fields.

• group - This maps to organisation.
• artifactId - Effectively maps to both module and artifact. Strictly speaking not the same, but in practice this is usuaaly how it works out.
• version - Maps to revision
• classifier - This seems to be seldom used, is usually optional, but maps to classifier.
• ext - Refers to the extension of the artifact. Is optional and maps to ext.

How would you go about mapping this in practice? Let's assume you have a project that is dependent on libusb on SourceForge. The latter has a flexible folder structure, so once the Files section has been inspected one can write an appropriate pattern as is shown in sourceforge.gradle

Notice that the ext field is not in parenthesis, meaning that in this case I expect the extension to be passed.

Finally to prove that it work we can create a little build script tryIt.gradle and running it with gradle --info -b tryIt.gradle tryIt should provide output similar to output.txt.

Reviewing User Stories - Rise of the Quality Factors

Many people are familiar with Bill Wake's INVEST acronym when it comes to user stories. Even though I've heard a number of criticisms launched at conferences, from my experience it is still very popular in current teaching material.

Althought INVEST can be used to review user stories, when I look at the quality aspects of a process overall I would like to have a different approach. With user stories in each various incantations being very popular in the Agile world, I would therefore want to be able to review from an outsider's point of view, possibly that of a coach or consultant.

My friends Ashish Misra and Aditya Garg have come up with what I consider to be an excellent list [1]. I have deemed to name it the User Story Quality Factors:

Completeness: Any team or organisation will develop a way of capturing user stories. This might be internalised or published in a similar fashion to a Definition of Done. Therefore does te story have all the information it is supposed to have? Does it have traceability from previous documentation or discussions?

Consistency: The way the specification is formatted, the language used and the way the requirements are presented should be consistent throughout.

Ambiguity: Is it free of any ambiguous statements?

Specific:  Is it free of generalised statements?

Realisable: Does the requirement make sense and is it possible? Has all of the information been included in order to deliver the product?

Testable: If the user acceptance criteria is not testable it cannot be built with confidence.

Traceable: Who wants this requirement and why is it needed, what business strategy does it support?

Measurable: How are you going to measure if the requirements have actually been delivered and are operational to specification? Quantification applies to both user acceptance criteria (that which tell you that you can release) and success criteria (that which tells you that your release is a success in the market). If I don't see this I usually teach people the basic of Planguage - Name, Scale, Meter & Goal.

Acceptable: Is the use of calculations, language, logic and formulas correct?

Achievable: Is the user story achievable within an sprint (iteration-based) or a acceptable number of cadences (iteration-less)? If not, then consideration must be given to splitting the user story in to smaller units that still deliver value.

Independent: It is best if stories are independent. Sometimes this is not completly possible, thus one-way directional dependencies are acceptable. Circular and two-way dependencies are not allowed, otherwise prioritisation and planning problems will occur. The latter will also indicate that there are other issues within the context of a project or business value increment.


[1] By their own admission, Ashish & Adi would not declare full originality to the idea, but rather that it has been a fusion of ideas, influenced by the streams of time. Maybe a similar list already exists in another publication. If anyone reads this and can point me to that, then please do so - appropriate credit needs to be given.