|
|
|
|
http://blog.mraw.org/2012/05/21/Fun_with_integers_longs_pointers/ While investigating the case of some packages responsible for
uninstallability on the s390x architecture, I stumbled upon one
FTBFS on a single architecture, reported as
#673590 (<insert some nice words
about software shipping with a decent testsuite>).
Given the int versus size_t question was asked, I grabbed this old
(it’s UNIX!) reference:
64-bit and Data Size Neutrality.
Among other things, it describes the “everything is 32-bit” to “64-bit
is becoming the new standard” slow conversion process, where keeping
compatibility with existing applications was a high priority. It has a
nice description of so-called C data models, making it possible to
refer to them quickly: LP32 and ILP32 in the 32-bit world; ILP64,
LLP64, and LP64 in the 64-bit world. I won’t go into detail here, this
page has a nice table and lots of explanations about pros and cons for
those.
(On a personal note, I discovered those on xorg-devel@ when I saw
patches floating around, which were about optimizing data sizes for
this or that data model, by picking the right types.)
While standards may be boring, this page makes it really easy to
understand which data types to use, to ensure the best 32/64-bit
compatibility possible. It’s even full of dos and don’ts. See the
second half (Porting Issues) for details.
|
|
Comments: Add Your Own.
|
|
|
|
http://info.comodo.priv.at/blog/archives/2012/05/#e2012-05-20T21_04_10.txt I was on vacations for a few days last week, therefor my list of RC bugs is
a bit shorter this time. thanks again to everyone who sent patches to the
BTS that I could just use.
#625230 – libfile-path-perl: "libfile-path-perl: uninstallable, obsoleted by perl" removal bug filed (#672905; pkg-perl)
#642745 – src:libnetserver-generic-perl: "libnetserver-generic-perl: FTBFS: E: Caught signal 'Terminated': terminating immediately" removal bug filed (#672903; pkg-perl)
#658577 – libevocosm-dev: "-dev library is broken" add patch from Vincent Legout, upload to DELAYED/2
#661500 – src:libevocosm: "FTBFS: dpkg-source: error: aborting due to unexpected upstream changes" fix config.{guess,sub} handling, upload to DELAYED/2
#667244 – libevocosm: "libevocosm: ftbfs with GCC-4.7" add patch from Matthias Klose, upload to DELAYED/2
#672000 – src:structure-synth: "structure-synth: FTBFS: StructureSynth/JavaScriptSupport/../../SyntopiaCore/GLEngine/Sphere.h:25:4: error: 'GLUquadric' does not name a type" sponsor NMU from Sebastian Ramacher, upload to DELAYED/2
#672005 – src:l2tp-ipsec-vpn: "l2tp-ipsec-vpn: FTBFS: src/main.cpp:210:15: error: '::getuid' has not been declared" add patch from Paul Tagliamonte, upload to DELAYED/3
#672010 – src:cryptkeeper: "cryptkeeper: FTBFS: lsof.cpp:40:2: error: 'pipe' was not declared in this scope" add patch from Paul Tagliamonte, upload to DELAYED/3
#672014 – src:megaglest: "megaglest: FTBFS: util.cpp:360:30: error: 'close' was not declared in this scope" sponsor NMU from Sebastian Ramacher, upload to DELAYED/2
#672071 – src:pxe-kexec: "pxe-kexec: FTBFS: networkhelper.cc:211:21: error: 'close' was not declared in this scope" add patch from Paul Tagliamonte, upload to DELAYED/3, then closed by maintainer upload
|
|
Comments: Add Your Own.
|
|
|
|
http://ekaia.org/blog/2012/05/20/long-due-to-do-item-removal-of-qt3-from-debian/ http://ekaia.org/blog/?p=121 A couple of weeks ago was the first anniversary of orphaning Qt3 in Debian, see bug 625502.
In this year, Qt3 has got a few QA uploads with the most relevant change being support to multiarch. And, more importantly, nobody seemed to care enough to step into maintaining it.
In the last days, I have taken a look into how much needed to be done to remove Qt3 and there were slightly more than 50 packages depending directly or indirectly from Qt3. A removal from Wheezy seemed doable given that removing packages is never a problem during the Debian freeze ;-)
All the packages affected have a bug opened since more than one year and half ago and I have pinged all the bugs with some maintainers responding quick (thanks!). I also filed some removals for packages that were clearly unmaintained and didn’t seem worth keeping, with ftp-masters responding quick too (Thanks!). And finally, a couple of QA upload for orphaned software that were still useful without Qt3.
There is a wiki page tracking the status of the removal if you are curious:
http://wiki.debian.org/qt3-x11-freeRemoval
If in the future, you are reading this and you need Qt3 in Wheezy, you can fetch it from Debian snapshots.
|
|
Comments: Add Your Own.
|
|
|
|
http://feedproxy.google.com/~r/ICringely/~3/_QhG9Bjm1is/ http://www.cringely.com/?p=4154 So Facebook is now a public company but with the shares only one day old the news is already bad: Facebook shares didn’t pull a Google or a Yahoo or a Microsoft or even a TheGlobe.com and soar out of sight on IPO day. They ended right where they started pretty much after the day traders took their easy profits. And while Wall Street sees this performance as a dud, Facebook itself sees it as a masterful piece of financial engineering.
If you are an investment banker — and let me re-emphasize that, if you are an investment banker — you want IPO shares to go up on their first day, rising in price by at least 10 percent though no more than 20 percent. This shows the IPO is hot, the company is booming, yet the offering wasn’t so underpriced that the founders feel cheated. Such IPOs make investors feel happy and happy investors buy and sell more shares and participate in future IPOs.
If you are an IPO company founder and — even more explicitly — you are Facebook CEO Mark Zuckerberg, you want your share price on the first day to go exactly nowhere, which is what Facebook’s did. That means no money was left on the table and the company got the best possible deal. Zuckerberg didn’t and doesn’t care about investors in this scenario, but then neither does he wish them ill. He just doesn’t give a damn.
And there’s the difference because investment bankers do give a damn because they’d like to have another IPO next week or next month and have that go very well, too. Zuckerberg expects Facebook to never issue another share of stock. He’s done raising money thanks, and on his honeymoon.
I’m sure there was a struggle at the end over how to price the offering. The bankers would have preferred $34 or even $32, but Facebook went for $38 and they were correct to do so from their point of view because we now see it was the optimal solution.
Then why don’t we feel better? Because for all it’s $100+ billion valuation the whole thing feels pretty low rent, like a big sale at K-Mart. Where’s the excitement? There isn’t any.
|
|
Comments: Add Your Own.
|
|
|
|
http://www.groklaw.net/article.php?story=20120520001747488 I can't find it on Oracle's website any more, but thanks to Internet Archive, we can find Sun Microsystems writing about software patents in 2006 and explaining its position. This was back when the European Union was for a while considering adopting software patents. You will not believe what Sun's position was. It's definitely relevant to the Oracle v. Google litigation. Sun's position paper was titled, "Software Patents: A European Union (EU) Directive on the Patentability of Computer-Implemented Inventions must not Jeopardize Interoperability." The title says it all, but I'm going to show the entire statement to you in all its glory, so Oracle can't pretend, as it tried unsuccessfully to do with the Jonathan Schwartz corporate blog, that it wasn't an official company statement. Sun strongly urged that Europe, if it adopted the Directive, "allow for the creation of products which can interoperate with the protected products to safeguard competition in the sector and to provide greater choice and lower costs for consumers." Imagine that. Sun said publicly that interoperability was more important than IP rights, even patents, because it led to competition and hence greater choice and lower costs for consumers.
|
|
Comments: Add Your Own.
|
|
|