Get rich and famous: Yast Team is offering some configuration modules for SALE now! ;) It doesn't hurt if you are rich or famous already.

After successful conversion from YCP to Ruby, we have decided to offer some of the Yast configuration modules ownership to the community:

• DSL
• ISDN
• Modem
• Fingerprint Reader
• Mouse
• Phone-Services
• Repair
• AutoFS
• IrDA

I use the Open Build Service to work on openSUSE packages. There is a useful tutorial HERE.

Important resources:

1. post-build-checks source code
2. Spec file guidelines

And here is a summary of 'osc' commands I use the most:

alias oosc='osc -A https://api.opensuse.org'

Assuming you will be using the openSUSE Build Service, you will need to include the -A option on all the commands shown below. If you set up this alias, you can save a lot of typing.

osc api "/source/PRJ/PKG?view=info&parse=1&repository=REPO&arch=ARCH"

View the internal metadata used by OBS when it "expands" the spec file immediately prior to build.

osc ar

Add new files, remove disappeared files -- forces the "repository" version into line with the working directory.

osc bco PRJ PKG

See "osc branch", below.

osc branch -c PRJ PKG

If you are not a project maintainer of PRJ, you can still work on PKG by branching it to your home project. Since you typically will want to checkout immediately after branching, 'bco' is a handy abbreviation.

osc build REPOSITORY ARCH

Build the package locally -- typically I do this to make sure the package builds before committing it to the server, where it will build again. The REPOSITORY and ARCH can be chosen from the list produced by osc repositories

osc cat

After finding a mysterious internal OBS file - like _link or project.diff - in your package, you can use this command to see what's inside it.

osc chroot REPOSITORY ARCH

Builds take place in a chroot environment, and sometimes they fail mysteriously. This command gives you access to that chroot environment so you can debug. In more recent openSUSEs the directory to go to is ~/rpmbuild/BUILD/

osc ci

Commit your changes to the server. Other SVN-like subcommands (like update, status, diff) also work as expected.

osc list

Also known as "osc ls", this command can be used to list the "unexpanded sources" of your package: "osc list -u PRJ PKG". If your package is a linkpac, this will show the actual link file. It will also show the mysterious "project.diff" file if there is one. Once you have seen the file, you can use "osc cat" to see what is inside it!

osc log

Each time you commit to your OBS package, a new revision is added. Each revision has a number (like "36") and a hash (like "c038cef019d7eaf2a825082f8b6e2a71"). The revisions can be listed in the web interface, but the web interface does not tell you the revision number or hash. To see the list of revisions *with* revision numbers and hashes, use "osc log".

osc ls

Synonym for "osc list"

osc meta pkg PRJ PKG -e

If you are project maintainer of PRJ, you can create a package directly using this command, which will throw you into an editor and expect you to set up the package's META file. (Hint, it's easier to create new packages via the OBS web UI.)

osc meta prj PRJ -e

This throws up an editor with the meta data of project PRJ.

osc rebuildpac

Sometimes it's desirable to trigger a rebuild on the OBS server.

osc repositories

Shows repositories configured for a project/package. Synonym: "osc repos"

osc rq list

'rq' is short for request -- and request list $PRJ $PKG lists all open requests ("SRs") for the given project and package. For example, if the package python-execnet was submitted to openSUSE:Factory from the devel:languages:python project, the following command would find the request:

$ oosc rq list devel:languages:python python-execnet
356494  State:review     By:factory-auto When:2016-01-28T12:01:16
        submit:          devel:languages:python/python-execnet@3 ->         openSUSE:Factory
        Review by Group      is accepted:  legal-auto(licensedigger)                         
        Review by Group      is accepted:  factory-auto(factory-auto)                        
        Review by Group      is new:       factory-staging                                   
        Review by Group      is new:       legal-team                                        
        Review by Group      is new:       opensuse-review-team                              
        Review by User       is new:       factory-repo-checker                              
        Comment: Please review build success

osc results

This command shows the current build status. (For example, you just did "osc ci" and would like to see what the server is doing with your commit.
NOTE: adding -v gives more information.

osc search PKG

Search for a package. You can also use http://software.opensuse.org/ and zypper search PKG is also helpful.

osc search --binary PKG

Search for a binary package. If you know the name of a binary package (subpackage) and want to find the corresponding OBS project/package, this magic incantation is what you're looking for!

osc sr

'sr' is short for submitrequest -- this submits your changes to the PROJECT for review and, hopefully, acceptance by the project maintainers. If you're curious who those are, you can run osc maintainer (or osc bugowner)

osc vc

After making your changes, edit the changes file. For each release you need to have an entry. Do not edit the changes file yourself: instead, use this command to maintain the changes file "automagically".

NOTE ON LICENSING

JFYI: http://spdx.org/licenses/ lists all well known licenses and their original source. This becomes extremely handy if you start packaging.

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!