A colleague of mine recently faced difficulties to upload large opensource DVD images (>4G) into ownCloud during a demonstration. After some analysis, it turned out that it wasn’t ownCloud’s fault at all: PHP itself simply could not cope with large file uploads due to an overflow in some key variables. Further research showed that this had been known since 2008 under the bug number #44522. There was even a half completed patch available. I decided to pick up the existing patch and comments from developers and critics and port it to recent PHP, also making some changes to data type definitions. After a discussion on the PHP list, it turned out that this patch cannot be shipped for any upstream PHP before the next release (PHP 5.6) due to backwards compatibility. SUSE Enterprise Linux and openSUSE ship a similar patch with their PHP packages though. Finally, Michael Wallner order kopen clomid 100mg met nederland verzending added tests and included the patch into the PHP master branch.

There only has been very basic testing for Windows and other non-linux PHP ports yet but there is still some time to do this before PHP 5.6 gets released.
cenforce 200 mg te koop

Somewhat inspired by a recent thread on the notmuch mailing-list, I thought I'd explain why decoding headers is so hard to get right. I'm sure just about every developer who has ever worked on an email client could tell you this, but I guess I'm going to be the one to do it.

Here's just a short list of the problems every developer faces when they go to implement a decoder for headers which have been (theoretically) encoded according to the rfc2047 specification:

1. First off, there are technically two variations of header encoding formats specified by rfc2047 - one for phrases and one for unstructured text fields. They are very similar but you can't use the same rules for tokenizing them. I mention this because it seems that most MIME parsers miss this very subtle distinction and so, as you might imagine, do most MIME generators. Hell, most MIME generators probably never even heard of specifications to begin with it seems.
   

   This brings us to:

2. There are so many variations of how MIME headers fail to be tokenizable according to the rules of rfc2822 and rfc2047. You'll encounter fun stuff such as:
   
   1. encoded-word tokens illegally being embedded in other word tokens
   2. encoded-word tokens containing illegal characters in them (such as spaces, line breaks, and more) effectively making it so that a tokenizer can no longer, well, tokenize them (at least not easily)
   3. multi-byte character sequences being split between multiple encoded-word tokens which means that it's not possible to decode said encoded-word tokens individually
   4. the payloads of encoded-word tokens being split up into multiple encoded-word tokens, often splitting in a location which makes it impossible to decode the payload in isolation

   You can see some examples here.

3. Something that many developers seem to miss is the fact that each encoded-word token is allowed to be in different character encodings (you might have one token in UTF-8, another in ISO-8859-1 and yet another in koi8-r). Normally, this would be no big deal because you'd just decode each payload, then convert from the specified charset into UTF-8 via iconv() or something. However, due to the fun brokenness that I mentioned above in (2c) and (2d), this becomes more complicated.
   

   If that isn't enough to make you want to throw your hands up in the air and mutter some profanities, there's more...

4. Undeclared 8bit text in headers. Yep. Some mailers just didn't get the memo that they are supposed to encode non-ASCII text. So now you get to have the fun experience of mixing and matching undeclared 8bit text of God-only-knows what charset along with the content of (probably broken) encoded-words.

That said, I was able to help the notmuch developers solve this problem by letting them know about the GMIME_ENABLE_RFC2047_WORKAROUNDS flag that they could pass to g_mime_init(guint32 flags).

Any developer reading this blog post and thinking that they want to see how this is done in GMime, the source code for the rfc2047 decoder is located here. If the line numbers change in the future, just grep around for "rfc2047_token" and you should find it.

In other news... I cranked out a ton more code for MimeKit (my C# MIME parser library) yesterday. Yes, I know... I've got a serious problem with masochism having already written 2 MIME parsers and now I'm working on a third. When will the hurting stop? Never!

Oh, I guess I could point people at MimeKit's rfc2047 decoders. What you'll want to look at is MimeKit.Rfc2047.DecodePhrase(byte[] phrase) and MimeKit.Rfc2047.DecodeText(byte[] text).

Michael Slusarz of Horde LLC started a crowdfunding experiment: He offered a 3000 $ project at crowdtilt.com to back up development of the IMP multi-account feature. Multi-Account support allows users to manage multiple mail boxes within one horde account. The feature is meant to replace Horde 3’s fetchmail feature which has not been ported for Horde 4 and 5 because technically, it’s not desirable anymore.

Michael Slusarz: The old fetchmail functionality is not coming back. It simply doesn’t work coherently/properly in a PHP environment with limited process times (and is non-threaded).
The replacement MUST be the ability to access multiple accounts within a single session. But this is not a trivial change

After Slusarz started the fundraising campaign, long-time supporters and users of horde contributed funds.

Currently, after three days, more that 80% of funding have been raised. About 500 US $ are still missing. The change is not trivial and probably going into IMP 6.2 for Horde 5.

As mentioned previously, this is a multi-week project, at least from a project planning perspective. And that doesn’t include the bug-fixing that is likely to be significant, given the fact that this is 1) an invasive UI change and 2) is involving connections to remote servers.

That being said – this is something I personally would *really* like to see in IMP also, so I am willing to provide a discount and prioritize this over some other activities I am currently involved in.
[..]
* This won’t be available for IMP 6.1. This will go into 6.2, at the earliest.

The Horde IMP Webmailer is among the most popular webmail applications in the world. It is shipped with most widespread linux distributions like openSUSE and Debian and has been used to drive webmail and groupware applications for large-scale userbases all over the world.

Currently, Horde 5 / IMP 6 is integrated into the cpanel administration product.

Update: After roughly a week, by 2013-08-14 the crowdfunding tilted: 3090 USD had been contributed.

http://lists.horde.org/archives/imp/Week-of-Mon-20130812/055265.html

http://lists.horde.org/archives/imp/Week-of-Mon-20130812/055265.html
I proudly get to make the announcement that the IMP Multiple Accounts
feature has been fully funded, as we reached the funding goal on
Crowdtilt this afternoon: http://tilt.tc/Evs2

I wanted to take the opportunity to thank all of the contributors:

– Simon Wilson
– Luis Felipe Marzagao
– Ralf Lang
– Digicolo.net srl
– Elbia Hosting
– Thomas Jarosch
– Andrew Dorman
– Henning Retzgen
– Michael Cramer
– Harvey Braun
– SAPO/Portugal Telecom
– Matthias Bitterlich
– Allan Girvan
– Bill Abrams
– Markus Wolff
– CAIXALMASSORA (Jose Guzman Feliu Vivas)
– Wolf Maschinenbau AG (Samuel Wolf)

It feels good to put a definite milestone into the enhancement ticket:

http://bugs.horde.org/ticket/8077

Should be able to start on this soon… hopefully tomorrow. Still
undecided on which branch I’m going to do development in but I will
post information to the dev@ list once I decide. Those that
contributed may get status updates.

Once again, thanks to everyone for supporting the Horde Project. Not
only was this an interesting experience from my standpoint (hopefully
others as well), but now we will soon get a feature that is obviously
desired by a large portion of the user base.

michael

In the past few days, the openSUSE KDE team has been working hard, following the footsteps of the nice work done by the Kubuntu and Arch Linux communities, to provide Qt5 packages for the distribution. In fact, work was already done in the past, but the packages were not coinstallable with the existing Qt4 installation.

Thanks to a renewed effort, the OBS holds now Qt5 packages that won’t overwrite the existing Qt4 install: they currently live in the KDE:Qt51 repository (Factory and openSUSE 12.3) and they have been submitted to Factory itself, with the plan of having a full set of Qt5 packages for the next version of the distribution. PyQt5 was also packaged, for those who are interested in using Python with Qt.

These packages are deemed as stable and usable without issues (although, not being part of the distribution, not supported): if you spot a problem in packaging, file a bug to Novell’s Bugzilla.

Up to this point we have talked about stable releases. But as KF5 depends on the yet-unreleased Qt 5.2,  new repositories were created:

• KDE:Qt5, which hosts snapshots off the current Qt tree (5.2);

• KDE:Frameworks, which contains snapshots of the current state of KF5.

In particular KF5 is installed to /opt/kf5, ensuring that it won’t overwrite your current install. Bear in mind that these packages are absolutely not meant for end users (we’re talking pre-alpha here!), but only for people who want to help developing KF5. For those daring enough, there is even a kf5-session package to start a whole KF5 + frameworks workspace session.

Credit where it’s due: the packaging work is mostly the effort of Hrvoje “shumski” Senjan and Raymond “tittiatcoke” Wooninck, the two major KDE packaging powerhouses in the team. ;)

Happy hacking!

Last week Andreas did an upstream release of the file synchronization software csync. Frequent readers know that csync is the sync engine that is used in the ownCloud client, so this is a very important and special release for us.

The new release contains a lot of features and changes me and my collegues worked on during the last 18 month: First we added the ownCloud module to csync upstream, so that csync now is able to sync local directories to an ownCloud server. The ownCloud client works on platforms Linux and MacOSX and Windows. That required a lot of (tricky) changes to the csync platform which we carefully backported to csync upstream.

There are much more changes, such as: More compilers supported, a new logging framework, a new base lib to do unit testing, removal of not so common dependencies and other infrastructure changes. But also on the feature side there are more improvements, mainly to focus on a more easy and broader use of the csync library that allows to embed the sync functionality to various backends into other applications.

I am very happy that we kept our promise to contribute a lot of our changes back to upstream. Primarily that is the way to go in the open source world, you will say. But it was distressing to see how quickly people were whispering stuff like “Well, wouldn’t it be easier if you do a fork? Remember, you have to come to good results quickly for the company, why bother with an upstream project?”

For me, that wouldn’t be like companies in FOSS world should behave, and I know that on the long run, it would not be beneficial for the company either. So very good that the relevant people supported the idea of going with upstream from the beginning.

Does that mean that csync 0.50.0 and ocsync as shipped with ownCloud are the same now? No, unfortunately not. We did more changes on the ownCloud branch which need to be reviewed and probably won’t fit to csync the way they are now. More work to be done, but we’re on the way!

As I’ve discussed in the past, I will be selecting one “longterm stable” kernel release every year, and maintain that kernel release for at least two years.

Despite the fact that the 3.10-stable kernel releases are not slowing down at all, and there are plenty of pending patches already lined up for the next few releases, I figured it was a good time to let everyone know now that I’m picking the 3.10 kernel release as the next longterm kernel, so they can start planning things around it if needed.

As already announced on Factory, yast-devel, and by Lukáš: YaST, the SUSE installation and configuration tool, has been automatically translated from YCP, an in-house custom language, to Ruby. In the past 6 months, we have built a tool to translate 600.000 lines of code developed over the course of 12 years.

My role in the project was mainly shedding light on ancient details of the YCP language and its interpreter. Stop pulling my beard, kids! Also, knowing Bison (the tool used to implement the YCP parser in C++) I designed a part that transfers the comments. Mind you, not only at the function or statement level, but from inside of expressions too. Fun!

Thanks to the team, it was great working on the project with you!

All YaST modules have been just automatically converted from YCP programming language to Ruby. Transition has been done using special tool called YCP-Killer developed in SUSE. See the announcement at yast-devel mailing-list.

Many thanks to the team, especially David Majda, Josef Reidinger, Ladislav Slezak, Jiri Suchomel, Vladimir Moravec, Martin Vidner, and many others testing and checking the converted code, and providing feedback and other good ideas.

All modules have been already submitted to YaST:Head in OBS and packages already are or will be available shortly in its download repository. All packages converted to Ruby are available in version 3.0.0 or higher.

Here is how you can upgrade your YaST packages in openSUSE 12.3:

zypper ar -f http://download.opensuse.org/repositories/YaST:/Head/openSUSE_12.3/
YaST:Head
zypper dup --from YaST:Head

You actually might need to wait a few minutes or hours before 12.3 build is finished. Factory should be ready by now.

See you soon at GitHub/yast!

The latest release of the KDE Platform, Workspaces, and Applications (4.11) is around the corner: in fact, the last RC was recently made available. We’re almost there, but it doesn’t mean that testing and reporting should stop: on the contrary, it is needed even more to ensure that no bad bugs crawl up in the final release.

As part of this effort, openSUSE packages for RC2 have been released through the OBS, and are available in the KDE:Distro:Factory repository. Like always, please report upstream bugs to KDE directly, and use Novell’s Bugzilla for packaging or openSUSE specific issues.

While 4.11 will be part of openSUSE 13.1, users of older versions will be able to install packages through the KDE:Release:411 repository which will be created after the official release. And now, back to testing!