Search Results: "pm"

17 April 2013

Soeren Sonnenburg: CfP: Shogun Machine Learning Workshop, July 12-14, Berlin, Germany

CALL FOR PARTICIPATION: Shogun Machine Learning Workshop, Berlin, Germany, July 12-14, 2013 Data Science, Big-Data are omnipresent terms documenting the need for automated tools to analyze the ever growing wealth of data. To this end we invite practitioners, researchers and students to participate in the first Shogun machine learning workshop. While the workshop is centered around the development and use of the shogun machine learning toolbox, it will also feature general machine learning subjects. General Information The workshop will include: Do not miss the chance to familiarize yourself with the shogun machine learning toolbox for solving various data analysis tasks and to talk to their authors and contributors. The program of the workshop will cover from basic to advanced topics in machine learning and how to approach them using Shogun, which makes it suitable for anyone, no matter if you are a senior researcher or practitioner with many year's of experience, or a junior student willing to discover much more. Interested? A tentative schedule is available at http://shogun-toolbox.org/page/Events/workshop2013_program. Call for contributions The organizing committee is seeking workshop contributions. The committee will select several submitted contributions for 15-minute talks and poster presentations. The accepted contributions will also be published on the workshop web site. Amongst other topics, we encourage submission that Submission Guidelines Send an abstract of your talk/contribution to shogun-workshop2013@shogun-toolbox.org before June 1. Notifications will be given on June 7. Registration Workshop registration is free of charge. However, only a limited number of seats is available. First-come, first-served! Register by filling out the registration form. Location and Timeline The main workshop will take place at c-base Berlin (http://c-base.org/, https://en.wikipedia.org/wiki/C-base) on July 12. It is followed by additional 2-day hands-on sessions held at TU Berlin on July 13-14. About the Shogun machine learning toolbox Shogun is designed for unified large-scale learning for a broad range of feature types and learning settings, like classification, regression, or explorative data analysis. Further information is available at http://www.shogun-toolbox.org.

16 April 2013

Michal Čihař: Weblate 1.5

Weblate 1.5 has been released today. It comes with lot of improvements, especially in performance, reporting and support for machine translations. Full list of changes for 1.5: You can find more information about Weblate on it's website, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Ready to run appliances will be soon available in SUSE Studio Gallery. Weblate is also being used https://l10n.cihar.com/ as official translating service for phpMyAdmin, Gammu, Weblate itself and others. If you are free software project which would like to use Weblate, I'm happy to help you with set up or even host Weblate for you.

Filed under: English Phpmyadmin Suse Weblate 0 comments Flattr this!

Michal Čihař: phpMyAdmin translations status

phpMyAdmin 4.0-rc2 is out and if your want to have your language in final release, it's last moment to start working on translation. So let's look at which translations are at 100% right now (new ones are bold): Almost complete: As you can see, there is still lot of languages missing, this might be your opportunity to contribute to phpMyAdmin. Also you are welcome to translate phpMyAdmin 4.0 using translation server. If your language is already fully translated and you want to help as well, you can translate our documentation as well.

Filed under: English Phpmyadmin 0 comments Flattr this!

Johannes Schauer: botch - the debian bootstrap software has a name

After nearly one year of development, the "Port bootstrap build-ordering tool" now finally has a name: botch. It stands for Bootstrap/Build Order Tool CHain. Now we dont have to call it "Port bootstrap build-ordering tool" anymore (nobody did that anyways) and also dont have to talk about it by referring to it as "the tools" in email, IRC or in my master thesis which is due in a few weeks. With this, the issue also doesnt block the creation of a Debian package anymore. Since only a handful of people have a clone of it anyway, I also renamed the gitorious git repository url (and updated all links in this blog and left a text file informing about the name change in the old location). The new url is: https://gitorious.org/debian-bootstrap/botch Further improvements since my last post in January include: In the mean time a paper about the theoretical aspects of this topic which Pietro Abate and I submitted to the CBSE 2013 conference got accepted (hurray!) and I will travel to the conference in Canada in June. Botch (yeey, I can call it by a name!) is also an integral part of one of the proposals for a Debian Google Summer of Code project this year, mentored by Wookey and co-mentored by myself. Lets hope it gets accepted and produces good results in the end of the summer!

12 April 2013

Michal Čihař: Hackweek 9 is over

Hackweek 9 is over and it's time to share what I've done on Weblate during that. I think everything went quite well and Weblate is now ready for 1.5 release. I'm slowly deploying it on my installations (unfortunately this release migration will need some noticeable downtime for bigger installations) and everything seems to work fine so far. I believe this is possible thanks to massive test coverage - all important code is covered by testcases. So what you can expect in 1.5 release? The most visible change is probably new machine translation support, providing support for way more backends and allow you to plug in own services as well. The other changes include word counting (what might give you more idea how much work is remaining) or fancy progress bars in all places (they used to be available for translations only). From the other side, Weblate can now run custom scripts to pre-process translations before commit, what can be used for various things from generating byte compiled files to sorting or cleaning up the translation files. Also Weblate should be now much faster - there were dozen of optimizations done, leading to much lower press on database server. If you want to see more detailed work progress, check Hackweek project page or Weblate changelog. PS: In case no problems appear, Weblate 1.5 should be released on Sunday.

Filed under: English Phpmyadmin Suse Weblate 0 comments Flattr this!

11 April 2013

Daniel Pocock: reSIProcate and reTURN come to Fedora

This week, I've released the first official reSIProcate packages for Fedora. EPEL packages for RHEL5 and RHEL6 are on the way too. This is exceptionally good news for Debian, Ubuntu, OpenWRT routers and every other platform that is already carrying these packages. reSIProcate is not just SIP: it also contains the powerful STUN/TURN server, reTurn Server. The TURN protocol is the IETF standard that solves many of the difficulties faced using VoIP/RTC from behind NAT. It is equally useful for SIP or XMPP (Jabber) and is supported in various ways by Empathy, Jitsi and Lumicall and it is a mandatory element of WebRTC which is expected to rapidly rise in prominence during 2013. Metcalfe's law tells us that the success of a communications platform grows quadratically in proportion to the number of users. In simple terms, doubling the number of potential SIP users gives four times the benefit to existing users. The tide lifts all ships equally The significance of these developments should not be underestimated. The success of Free software and open standards is intricately linked with the success of Free and open communications technology. In the world of RTC, projects don't exist in an ideological bubble, they have to be implemented in the real world and connected together for personal use, small business and large enterprise. People committed to free and open technology need to win all those domains. Conversely, the peer pressure of proprietary softphone technology is one of the strongest barriers faced in the deployment of all forms of Free software on the desktop. Offering an alternative is a high priority campaign of the FSF

10 April 2013

Peter Makholm: Reviewing my own regular expressions

Regular expressions are a wonderful tool, but as many other powerful tools they tend to be misused. If I had a penny for everytime I recommended against using regular expressions for parsing HTML fragments . yeah you know what I mean. This time made me think a bit about my own use of regular expressions. Do I ever fall in the trap of misusing regular expressions myself? Looking at my current code base I couldn t find any glaring misuses, if I could only get a list of all the regular expressions in my current project. Regular expressions to the rescue? No, that would probably be quite an horrible adventure. Luckily I have tools to parse Perl: PPI to the rescue: <script src="https://gist.github.com/pmakholm/5354001.js"></script> A few hundred regular expressions. Most of them just matching simple substrings (in some cases case insensitive) or just short hand for testing a handful of equalities in one go. The only zero-width assertions we are using are the word boundary and quantifiers are mostly used on simple character classes like \d, \s, [0-9a-f] and a few anything but this one or two characters ([^>]). Lessons learned: 1) PPI is cool. 2) I really do use regular expressions as I preach.

Andrew Pollock: [life/repatexpat] Day #10 of repatriation -- got wheels

Finally, finally, I've got a car. I had this grand plan of using a friend of a friend who was a car buyer to source me a car and have it ready for me at the airport when I arrived. That didn't work out so well, so I resorted to carsales.com.au and found something very quickly. I could have bought it last Friday, if I'd wanted to forego the RACQ inspection, but I hate used cars at the best of times, and so I want to do what I can do avoid buying a lemon, so I had to wait until Monday for the inspection. I got the report in the early afternoon on Monday, and the only thing it highlighted was a bit of oil on the front differential housing. I contacted the dealer and he said he'd get it looked at. I got an SMS from him on Tuesday morning saying the car would be ready after 3pm, but by the time I could arrange with Kristy for a ride, we just missed the bank, so I couldn't get the bank cheque to pay for it, so we rescheduled for this morning. The shipping container was delivered to Sarah's place on Monday, and there's been a steady stream of boxes arriving at my place. It was good to be able to transport some of those myself today, and there'll be more to move tomorrow. I need to sort out storage options, because one thing I don't want is for there to be too much clutter in my home. I think there'll be another trip to IKEA in my near future. At least I can do that all on my own now. It's so great to have independent mobility again.

9 April 2013

Michal &#268;iha&#345;: phpMyAdmin at GSoC 2013

phpMyAdmin has been accepted for Google Summer of Code 2013. So if you are a student and thinking about how to spend this summer, you might want to join us. This year we will have fresh mentor blood and we have prepared dozen of ideas, so in case you are interested, it's really the time to start to work on your application. We require you to contribute before GSoC, so that we can see you can handle the code and our tools. All details you might need are available in our applicant guide. Our requirements might sound strict, but without them, we would drown in hundredths of applications with no clue how to decide, so do your homework and prepare perfect application. If you have any questions, get in touch with us on mailing list and get ready for April 22th, when you can submit the application.

Filed under: English Phpmyadmin 0 comments Flattr this!

8 April 2013

Daniel Pocock: Google Summer of Code, tips for students

I've had quite a few queries about the project ideas for Google Summer of Code on the Lumicall and Debian project pages and I'm publishing some notes here to help people get the best chance of participating, while also helping people's expectations. Firstly, Google is responsible for administering the program and payments, they have the last word on which projects and students participate and free software developers like myself have no direct control over this. In other words, while I would encourage students to make contributions to free software projects to familiarize themselves with the way we work, I can not promise that this will automatically lead to selection. If you are a student, do go ahead and feel free to comment on or make contributions to projects, this helps mentors to see your capabilities very quickly, but don't do any more than you would have done if the GSoC program didn't exist. In any case, building up a portfolio of work that is visible on sites like github does help your employment prospects in the long run. If a development manager is looking at 100 CVs for a job vacancy, and one of them has a strong portfolio on github or Debian, there is a good chance that one person will get an interview - although it doesn't guarantee they get the job. Where to start? If you are a student and you are already heavily involved in some free software project then you probably don't need to read the rest of this. The reality is that GSoC is meant to help bring more people into the free software community and this means we need to help people get their foot in the door. That is what I am addressing here, with examples from my own possible projects. When I went through university in the 90s, there was a very strong UNIX culture in our computer science department and the wider engineering faculty. There were also winds of change, for example, a new dean who wanted to change everything to Windows and a central IT management agenda to abolish campus computers and force students to carry and maintain their own laptops. Around the world, every campus has a different approach. I was fortunate to have UNIX topics like the vi text editor, shell programming and even LaTeX taught as a formal part of the course, students coming after me may have missed those opportunities. I understand that some students have not encountered these concepts at all today. That said, most mentors have a fairly wide tolerance for these things: it is not expected that students know these things, rather, it is an opportunity for you to start learning them whether it is part of your course or not. The key concept here is to be a self-starter: it is not what you know, but your enthusiasm to go and try the things you don't know. That is the very thing you can start doing now, even before the program commences. Doing this will definitely help you identity the areas of free software and Debian that you are most likely to get excited about, and that will lead to a successful project. Some general ideas to get started
  • If your campus hasn't taught UNIX in a formal sense, please familiarise yourself with the basics. While some companies do have more jobs working with other platforms, and some campuses have sadly tried to adapt their courses to prepare students for that limited subset of companies, all the best jobs I've had involve UNIX or Linux. I've never worked for a hedge fund that didn't use Linux. Hollywood uses Linux, NASA does too, but learning Linux is not rocket science. Basic things to understand include the vi text editor, shell scripts and using a command line tool for version control, preferably git. As you will be the system administrator of your own desktop or laptop, it's essential to understand some basic concepts like volume management too.
  • If you need to run some Windows software (some courses do require that), use VirtualBox or a similar solution to run both Windows and Linux on your computer or laptop. The VirtualBox documentation is very good and will help you start quickly. My own laptop runs Debian 7 (wheezy) as the main operating system, and I have Windows and Solaris in VirtualBox for some business applications.
  • My own course included a project that involved downloading the open source GNU make program, writing a patch and testing it. If you've never done something like that, please try. Instead of downloading a project tarball, these days you will typically clone the project's git repository. Even if you only make some trivial change that you will never share, it is good to prove that you can compile and successfully execute something like this.
Some specific ideas for my own projects
  • For Lumicall or Android development, just work your way through the build instructions that are published for all contributors. Trying the f-droid build instructions is also a good way to start.
  • For any of the Debian projects, please make sure you have installed Debian 7 (wheezy) on a desktop, laptop or virtual machine. Just follow the installation guide
  • Once you have installed Debian, try installing whichever one of my packages interests you. Try to configure and use it. Prove that the package works in a normal installation. Look at the log files. Run the test cases.
  • Next, try obtaining the source code and building the package. Debian makes it very easy. Here is an example for reSIProcate, the same works for any other package. As root: 
    # apt-get update
# apt-get build-dep resiprocate
    will obtain all the necessary build tools. Then, as a normal user: 
    $ mkdir ~/src/resiprocate
$ cd ~/src/resiprocate
$ apt-get source resiprocate
$ cd resiprocate
$ dpkg-buildpackage -rfakeroot -j12
    In a few minutes, you should find the packages (*.deb files) are created.
  • Now, you could try making some small change to the package and compiling it again. Verify that your change works.
If you've successfully got to this point, then there is every chance you will be able to successfully complete a GSoC project. If you struggled along the way, that is OK too, the important thing to do is to engage with the community and learn how to ask for help. The Debian GSoC wiki provides some excellent ideas about engaging with the project using IRC chat and mailing lists. It is also very worthwhile trying to find a local group or a free software event that Debian is attending near you and spending a few hours with people who can look at any problems you have and give you quick solutions.

Matthias Klumpp: Tanglu status report

Hello everyone! I am very excited to report about the awesome progress we made with Tanglu, the new Debian-based Linux-Distribution. :) First of all, some off-topic info: I don t feel comfortable with posting too much Tanglu stuff to Planet-KDE, as this is often not KDE-related. So, in future Planet-KDE won t get Tanglu information, unless it is KDE-related ;-) You might want to take a look at Planet-Tanglu for (much) more information. So, what happened during the last weeks? Because I haven t had lectures, I nearly worked full-time on Tanglu, setting up most of the infrastructure we need. (this will change with the next week, where I have lectures again, and I also have work to do on other projects, not just Tanglu ^^) Also, we already have an awesome community of translators, designers and developers. Thanks to them, the Tanglu-Website is now translated to 6 languages, more are in the pipeline and will be merged later. Also, a new website based on the Django framework is in progress. The Logo-Contest We ve run a logo-contest, to find a new and official Tanglu logo, as the previous logo draft was too close to the Debian logo (I asked the trademark people at Debian). More than 30 valid votes (you had to be subscribed to a Tanglu Mailinglist) were received for 7 logo proposals, and we now have a final logo: Tanglu Logo (Text) I like it very much :) Fun with dak I decided to use dak, the Debian Archive Kit, to handle the Tanglu archive. Choosing dak over smaller and easy-to-use solutions had multiple reasons, the main reason is that dak is way more flexible than the smaller solution (like reprepro or min-dak) and able to handle the large archive of Tanglu. Also, dak is lightning fast. And I would have been involved with dak sooner or later anyway, because I will implement the DEP-11 extension to the Debian Archive later (making the archive application-friendly). duckWorking with dak is not exactly fun. The documentation is not that awesome, and dak contains many hardcoded stuff for Debian, e.g. it often expects the unstable suite to be present. Also, running dak on Debian Wheezy turned out to be a problem, as the Python module apt_pkg changed the API and dak naturally had problems with that. But with the great help of some Debian ftpmasters (many thanks to that!), dak is now working for Tanglu, managing the whole archive. There are still some quirks which need to be fixed, but the archive is in an usable state, accepting and integrating packages. The work on dak is also great for Debian: I resolved many issues with non-Debian dak installations, and made many parts of dak Wheezy-proof. Also, I added a few functions which might also be useful for Debian itself. All patches have of course been submitted to upstream-dak. ;-) Wanna-build and buildds GearThis is also nearly finished :) Wanna-build, the software which manages all buildds for an archive, is a bit complicated to use. I still have some issues with it, but it does it s job so far. (need to talk to the Debian wanna-build admins for help, e.g. wanna-build seems to be unable to handle arch:all-only packages, also, build logs are only submitted in parts) The status of Tanglu builds can be viewed at the provisoric Buildd-Status pages. Setting up a working buildd is also a tricky thing, it involves patching sbuild to escape bug #696841 and applying various workarounds to make the buildd work and upload packages correctly. I will write instructions how to set-up and maintain a buildd soon. At time, we have only one i386 buildd up and running, but more servers (in numbers: 3) are prepared and need to be turned into buildds. After working on Wanna-build and dak, I fully understand why Canonical developed Launchpad and it s Soyuz module for Ubuntu. But I think we might be able to achieve something similar, using just the tools Debian already uses (maybe a little less confortable than LP, but setting up an own LP instance would have been much more trouble). Debian archive import The import of packages from the Debian archive has finished. Importing the archive resulted in many issues and some odd findings (I didn t know that there are packages in the archive which didn t receive an upload since 2004!), but it has finally finished, and the archive is in a consistent state at time. To have a continuous package import from Debian while a distribution is in development, we need some changes to wanna-build, which will hopefully be possible. Online package search The Online-Package-Search is (after resolving many issues, who expected that? :P ) up and running. You can search for any package there. Some issues are remaining, e.g. the file-contents-listing doesn t work, and changelog support is broken, but the basic functionality is there. Tanglu Bugtracker We now also have a bugtracker which is based on the Trac software. The Tanglu-Bugtracker is automatically synced with the Tanglu archive, meaning that you find all packages in Trac to report bugs against them. The dak will automatically update new packages every day. Trac still needs a few confort-adjustments, e.g. submitting replies via email or tracking package versions. Tanglu base system tanglu-platform-smallThe Tanglu metapackages have been published in a first alpha version. We will support GNOME-3 and KDE4, as long as this is possible (= enough people working on the packaging). The Tanglu packages will also depend on systemd, which we will need in GNOME anyway, and which also allows some great new features in KDE. Side-effect of using systemd is at least for the start that Tanglu boots a bit slow, because we haven t done any systemd adjustments, and because systemd is very old. We will have to wait for the systemd and udev maintainers to merge the packages and release a new version first, before this will improve. (I don t want to do this downstream in Tanglu, because I don t know the plans for that at Debian (I only know the information Tollef Fog Heen & Co. provided at FOSDEM)) The community The community really surprised me! We got an incredible amount of great feedback on Tanglu, and most of the people liked the idea of Tanglu. I think we are one of the less-flamed new distributions ever started ;-) . Also, without the very active community, kickstarting Tanglu would not have been possible. My guess was that we might be able to have something running next year. Now, with the community help, I see a chance for a release in October :) The only thing people complained about was the name of the distribution. And to be really honest, I am not too happy with the name. But finding a name was an incredibe difficult process (finding something all parties liked), and Tanglu was a good compromise. Tanglu has absolutely no meaning, it was taken because it sounded interesting. The name was created by combining the Brazilian Tangerine (Clementine) and the German Iglu (igloo). I also dont think the name matters that much, and I am more interested in the system itself than the name of it. Also, companies produce a lot of incredibly weird names, Tanglu is relatively harmless compared to that ;-) . In general, thanks to everyone participating in Tanglu! You are driving the project forward! The first (planned) release I hereby announce the name of the first Tanglu release, 1.1 Aequorea Victoria . It is Daniel s fault that Tanglu releases will be named after jellyfishes, you can ask him why if you want ;-) I picked Aequorea, because this kind of jellyfish was particularly important for research in molecular biology. The GFP protein, a green fluorescent protein (=GFP), caused a small revolution in science and resulted in a Nobel Prize in 2008 for the researchers involved in GFP research (for the interested people: You can tag proteins with GFP and determine their position using light microscopy. GFP also made many other fancy new lab methods possible). Because Tanglu itself is more or less experimental at time, I found the connection to research just right for the very first release. We don t have a time yet when this version will be officially released, but I expect it to be in October, if the development speed increases a little and more developers get interested and work on it. Project Policy We will need to formalize the Tanglu project policy soon, both the technical and the social policies. In general, regarding free software and technical aspects, we strictly adhere to the Dbian Free Software Guidelines, the Debian Social Contract and the Debian Policy. Some extra stuff will be written later, please be patient! Tanglu OIN membership I was approached by the Open Invention Network, to join it as member. In general, I don t have objections to do that, because it will benefit Tanglu. However, the OIN has a very tolerant public stance on software patents, which I don t like that much. Debian did not join the OIN for this reason. For Tanglu, I think we could still join the OIN without someone thinking that we support the stance on software patents. Joining would simply be pragmatic: We support the OIN as a way to protect the Linux ecosystem from software patents, even if we don t like the stance on software patents and see it differently. Because this affects the whole Tanglu project, I don t want to decide this alone, but get some feedback from the Tanglu community before making a decision. Can I install Tanglu now? Yes and no. We don t provide installation images yet, so trying Tanglu is a difficult task (you need to install Debian and then upgrade it to Tanglu) if you want to experiment with it, I recomment trying Tanglu in a VM. I want to help! Great, then please catch one of us on IRC or subscribe to the mailinglists. The best thing is not to ask for work, but suggest something you want to do, others will then tell you if that is possible and maybe help with the task. Packages can for now only be uploaded by Debian Developers, Ubuntu Developers or Debian Maintainers who contacted me directly and whose keys have been verified. This will be changed later, but at the current state of the Tanglu archive (= less safety checks for packages), I only want people to upload stuff who definitely have the knowledge to create sane packages (you can also proove that otherwise, of course). We will later establish a new-member process. If you want to provide a Tanglu archive mirror, we would be very happy, so that the main server doesn t have to carry all the load. If you have experience in creating Linux Live-CDs or have worked with the Ubiquity installer, helping with these parts would be awesome! Unfortunately, we cannot reuse parts of Linux Mint Debian, because many of their packages don t build from source and are repackaged binaries, which is a no-go for the Tanglu main archive. Sneak peek And here is a screenshot of the very first Tanglu installation (currently more Debian than Tanglu):

tanglu_sneak-peek_screenshot Something else I am involved in Debian for a very long time now, first as Debian Maintainer and then as Debian Developer and I never thought much about the work the Debian system administrators do. I didn t know how dak worked or how Wanna-build handles the buildds and what exactly the ftpmasters have to do. By not knowing, I mean I knew the very basic theory and what these people do. But this is something different than experiencing how much work setting up and maintaining the infrastructure is and what an awesome job the people do for Debian, keeping it all up and running and secure! Kudos for that, to all people maintaining Debian infrastructure! You rock! (And I will never ever complain about slow buildds or packages which stay in NEW for too long ;-) )

Bits from Debian: Debian joins Free & Open Source Software Outreach Program for Women

The GNOME Foundation started the Free & Open Source Software Outreach Program for Women, OPW, in 2010. In the January-April 2013 round, many other FOSS organizations joined the program. We are happy to announce that Debian will also join in the next round from June-September and we'll offer one internship. You can find more details about Debian's participation in the program at Debian OPW page. Call for mentors and projects OPW allows applicants to work on any kind of project, including coding, design, marketing, web development... The Debian Google Summer of Code projects will be offered also as possible projects for OPW, but GSoC only allows coding projects. If you have any idea of a non-coding project and you want to mentor it, please contact us in the soc-coordination mailing list adding [OPW] in subject. OPW works in the same way as GSoC except Google doesn't play a part here. The same advice that is provided for GSoC mentors works for OPW mentors. Call for participants The main goal of this program is to increase the number of women in FOSS, so all women who are not yet a Debian Developer or a Debian Maintainer are encouraged to apply. There are no age restrictions and applicants don't need to be a student. If you want to apply, you must follow three steps:
  1. Choose a project from this list. There are two lists, one for GSoC and another with non-coding tasks that can be only offered by the OPW. Those lists may change and add or remove more projects in the next few weeks.
  2. Make a small contribution to Debian. Projects will add a task the applicant must complete as part of the pre-selection process. If no task is provided, you are welcome to ask the mentors of the project. You can also make a different extra task of the one listed to show your skills and interest.
  3. Create a page in the Debian wiki with your application. You can do so under pseudonym, but in that case, please give us information about yourself privately by email to the coordinators listed in the Debian OPW page!

5 April 2013

Lior Kaplan: The commit police: reference you bugs properly

Besides my RTL work on Libreoffice, every once in a while I just go over the regular commit log to see what have changed. I don t necessary understand each line in the commit, but do get the general idea from the commit message. Being more dependent on the commit messages makes me review them more thoroughly (hence the topic of this post). As many projects, Libreoffice has notifications of commits related to bugs reports when the bug number is properly mentioned in the commit message. This is very useful for other developers and also for QA people. After verification of a bug is fixed, I often use the commits listed on the bug report to cherry pick them to an older branch. Going to search for an unreferenced commit isn t much fun. One of the things I notice is different ways people reference bugs from not referencing them at all to referencing them in various ways like linking to the bugs system, just writing the number (without the fdo# prefix) and other creative ways This is also true for first time contributors, which might not know the standards or the rules . When I see such a case I usually put a manual notification in the bug report, and mail the author of doing so. For new or sporadic contributors this is also an opportunity to welcome and thank them for the commit and even encourage future contributions. I have been asked why aren t that info on the wiki, so I went looking and found out the info is in the right place under the Development/GetInvolved page. The relevant part is:
When you type a commit message:
  • start the first line with a bug reference like fdo#12345, if you have one for your commit (see details below)
  • use the rest of the first line as a concise summary of your changes
  • the 2nd line remains empty
  • and starting on the 3rd line you can explain how and what changes have been made for what reasons.
Thanks in advance and happy coding (:
Filed under: LibreOffice

Michal &#268;iha&#345;: Unknown phpMyAdmin features - server monitoring

phpMyAdmin has in last year received various useful features, which are not that well known. I've decided to give them some promotion before releasing phpMyAdmin 4.0. The server monitoring part is already present since phpMyAdmin 3.5, but some of the parts were further improved in 4.0. Server monitor Server monitor (as you can see on picture above or on demo server) allows you to follow server status in real time. Besides predefined charts, you can choose to follow any of MySQL server status variables or some system parameters. If you see something weird in the charts, you can select interval and inspect slow or general query log (if you have enabled it). This can help you finding most problematic queries for your server. Server configuration advisor Advisor (on picture above or on demo server) is another way to improve server performance - it comes with extensive set of rules, which can help you tuning performance for your workload. Your server has to be running for significant time to give some reasonable recommendations (so don't expect these on the demo server, which is restarted quite often). However it is still recommended to read server documentation before doing any adjustments, as the setting might have some side effects, which will affect your workload as well. Of course these are not magic pill to cure your unresponsive server, but can help you a lot in finding possible bottlenecks.

Filed under: English Phpmyadmin 0 comments Flattr this!

Daniel Pocock: Quickstart: Integrating SIP support into any application with reSIProcate

Today's applications are more dynamic and interactive than ever before, typically offering the user many ways to collaborate or get live data about their community or environment as they need it. Two open standards exist with a broad focus on real-time messaging and session control, SIP and XMPP (Jabber). Both of them have been supercharged by the development of technologies like WebRTC that makes every browser into a communications endpoint. Here, we look at integrating SIP into any C++ application (either client or server). We use the industry standard SIP stack reSIProcate. The quickest way to get started is with a Debian, Ubuntu or Fedora development environment. reSIProcate is conveniently packaged on all those platforms (for Fedora, it is not yet in yum and must be built from the tarball using rpmbuild). Getting the environment set up Once you have Debian or Ubuntu installed, just do: 
# apt-get build-dep resiprocate
# apt-get install libresiprocate-1.8-dev
This will install all the necessary tools, libraries and header files. Headers are under /usr/include/resip Writing some code The object orientated nature of C++ is heavily leveraged by reSIProcate, and this makes it easy to code. The stack is based on a callback paradigm: you create some objects based on well-defined interfaces, give your objects to the stack, and put the stack into a loop. The stack will call your object when some event occurs (e.g. new incoming call, new text message) The easiest way to see this in practice is to browse the test cases. The test cases under the resip/dum(mirrored on github) section of the source tree provide good high-level examples of the type of code an application writes when using reSIProcate in an existing application. Sending a SIP text message Based on the basicMessage test case, I've created a trivial piece of code below to send a text message over SIP. The whole demo project is uploaded into github, see the README for instructions on how to build and run. Here, we have a quick look at the one object in the demo, it is notified on the progress of the SIP text message: 
class ClientMessageHandler : public ClientPagerMessageHandler  
public:
   ClientMessageHandler()
      : finished(false),
        successful(false)
    
    ;
   virtual void onSuccess(ClientPagerMessageHandle, const SipMessage& status)
    
      InfoLog(<<"ClientMessageHandler::onSuccess\n");
      successful = true;
      finished = true;
    
   virtual void onFailure(ClientPagerMessageHandle, const SipMessage& status, std::auto_ptr<contents> contents)
    
      ErrLog(<<"ClientMessageHandler::onFailure\n");
      successful = false;
      finished = true;
    
   bool isFinished()   return finished;  ;
   bool isSuccessful()   return successful;  ;
private:
   bool finished;
   bool successful;
 ;
int main(int argc, char *argv[])
 
   // boilerplate initialisation code...
...
   NameAddr naTo(to.c_str());
   ClientPagerMessageHandle cpmh = clientDum.makePagerMessage(naTo);
   Data messageBody("Hello world!");
   auto_ptr<contents> content(new PlainContents(messageBody));
   cpmh.get()->page(content);
...
 
</contents></contents>
Going further with reSIProcate

4 April 2013

Bernhard R. Link: Git package workflows

Given the recent discussions on planet.debian.org I use the opportunity to describe how you can handle upstream history in a git-dpm workflow. One of the primary points of git-dpm is that you should be able to just check out the Debian branch, get the .orig.tar file(s) (for example using pristine-tar, by git-dpm prepare or by just downloading them) and then calling dpkg-buildpackage. Thus the contents of the Debian branch need to be clean from dpkg-source's point of view, that is do not contain any files the .orig.tar file(s) contains not nor any modified files. The easy way The easiest way to get there is by importing the upstream tarball(s) as a git commit, which one will usually do with git-dpm import-new-upstream as that also does some of the bookkeeping. This new git commit will have (by default) the previous upstream commit and any parent you give with -p as parents. (i.e. with -p it will be a merge commit) and its content will be the contents of the tarball (with multiple orig files, it gets more complicated). The idea is of course that you give the upstream tag/commit belonging to this release tarball with -p so that it becomes part of your history and so git blame can find those commits. Thus you get a commit with the exact orig contents (so pristine-tar can more easily create small deltas) and the history combined.. Sometimes there are files in the upstream tarball that you do not want to have in your Debian branch (as you remove them in debian/rules clean), then when using this method you will have those files in the upstream branch but you delete them in the Debian branch. (This is why git-dpm merge-patched (the operation to merge a new branch with upstream + patches with your previous debian/ directory) will look which files relative to the previous upstream branch are deleted and delete them also in the newly merged branch by default). The complicated way There is only a way without importing the .orig.tar file(s), though that is a bit more complicated: The idea is that if your upstream's git repository contains all the files needed for building your Debian package (for example if you call autoreconf in your Debian package and clean all the generated files in the clean target, or if upstream has a less sophisticated release process and their .tar contains only stuff from the git repository), you can just use the upstream git commit as base for your Debian branch. Thus you can make upstream's commit/tag your upstream branch, by recording it with git-dpm new-upstream together with the .orig.tar it belongs to (Be careful, git-dpm does not check if that branch contains any files different than your .orig.tar and could not decide if it misses any files you need to build even if it tried to tell). Once that is merged with the debian/ directory to create the Debian branch, you run dpkg-buildpackage, which will call dpkg-source which compares your working directory with the contents of the .orig.tar with the patches applied. As it will only see files not there but no files modified or added (if everything was done correctly), one can work directly in the git checkout without needing to import the .orig.tar files at all (altough the pristine-tar deltas might get a bit bigger).

Hideki Yamane: waagent_1.2-1_amd64.changes ACCEPTED into unstable

Thank you, ftpmasters.

waagent (Windows Azure Linux Agent) hits Debian repository now... Yes, "Windows Azure" is cloud computing service provided by Microsoft.

Michal &#268;iha&#345;: phpMyAdmin translations status

phpMyAdmin 4.0-rc1 is out and it's really time to work on translations if you want them to be ready for final release.. So let's look at which translations are at 100% right now (new ones are bold): Almost complete: As you can see, there is still lot of languages missing, this might be your opportunity to contribute to phpMyAdmin. Also you are welcome to translate phpMyAdmin 4.0 using translation server. If your language is already fully translated and you want to help as well, you can translate our documentation as well.

Filed under: English Phpmyadmin 0 comments Flattr this!

Bits from Debian: Improvements in Debian's core infrastructure

Thanks to a generous donation by Bytemark Hosting, Debian started deploying machines for its core infrastructure services in a new data center in York, UK. This hardware and hosting donation will allow the Debian Systems Administration (DSA) team to distribute Debian's core services across a greater number of geographically diverse locations, and improve, in particular, the fault-tolerance and availability of end-user facing services. Additionally, the storage component of this donation will dramatically reduce the storage challenges that Debian currently faces. The hardware provided by Bytemark Hosting consists of a fully-populated HP C7000 BladeSystem chassis containing 16 server blades: and several HP Modular Storage Arrays: with 108 drive bays in total, mostly 500GB SATA drives, some 2TB, some 600GB 15kRPM SAS, providing a total of 57 TB. 57 TB today could host roughly 80 times the current Debian archive or 3 times the Debian Snapshot archive. But remember both archives are constantly growing!

Russ Allbery: Debian packaging of Git upstreams

Since there's a discussion of packaging software for Debian that uses Git upstream on Planet Debian right now, I wanted to weigh in and advocate for my current workflow for this situation, which I'm quite fond of. It's worth noting that I'm also upstream for quite a few of the packages I maintain, all in Git, and I use (almost) exactly the same structure for packaging my own software as for packaging anyone else's. So I have some experience with both sides of this. First off, I completely agree with Joey: if upstream is already using Git, there's no reason not to base the Debian packaging on the upstream repository, and many, many reasons to do so. One of the biggest advantages is that when repositories share a common basis and have been regularly merged, you can easily cherry-pick commits, which is wonderful for security releases and situations where you need a quick bug fix from an unreleased upstream branch. I make very heavy use of this when packaging OpenAFS. I do, however, like to base the Debian packaging on the released tarball, if for no other reason than that's the artifact that other people can more easily confirm. Yes, you can do the same thing with a Git tag, but the tarball is what upstream considers a release, so if one is available, I think it makes the most sense to base the packaging on it. I do this even for my own software. Thankfully, it's not that difficult to do both. Sam Hartman was the one who showed me this technique, and (after I used a manual script for some time for a couple of packages) Guido G nther incorporated the support into git-import-orig. The key idea is to still import the tarball into the upstream branch, but instead of making that import a simple commit, you make it a merge commit referencing the upstream release tag or commit from their Git repository. This means that you still get the exact contents of the release tarball on the upstream branch (and pristine-tar works as normal), but that branch is also based on the full upstream line of development. Therefore, so is your packaging branch (master or what have you) since you merge upstream into it. You can then charry-pick and take advantage of all of the normal Git features when following upstream development. This is dead simple to do with git-import-orig. Just add the upstream repository as a remote for your Git repository, make sure it's up to date with git fetch and you have the upstream tags, and then pass the flag --upstream-vcs-tag <tag> to git-import-orig whenever importing the upstream release tarball. git-import-orig will handle the construction of the merge commit for you and everything will just work, exactly like it normally does with git-buildpackage except with a more complete history. This support was added in git-buildpackage 0.6.0~git20120324, so it's available in unstable and testing. (I was going to update my notes on Debian packaging with Git to include this information before posting this, but I see that it will require some restructuring and quite a few changes to that document and I don't have time tonight. Hopefully soon.)

Next.

Previous.