One word, EASY. it really takes no time to fix little things likes the ones in [the Debdiff Recipe https://wiki.ubuntu.com/MOTU/Recipes/Debdiff]. I have to admit I felt confident because I had attended dholbach's session about creating a debdiff on the IRC. debdiffs is used to establish the differences between the previous package and a much recent one. that last one may be one that you worked on (in our case), or just a much recent version of the package. What are they used for. well I remember that in launchpad when someone sees a bug. many people propose a fix using a debdiff. here is an example. This helps the development process because it pin points where the problem is.

==== a word on the tools ====

I am getting a hang of tools. like dch -i for debian/changelog entries, and building forthe sake of testing if it builds with debuild -S. One tool I just learned and that I find a kick ass trick is changing a string on the fly (right there and then) with sed -i 's/colour/color/g' debian/control, this in english means... go and change where it says colour with color in the control file.

I am having fun

Lesson 5:

Breaking a Brick Wall...

I read the IRC logs. I felt much more confident reading the questions after I had done the work. I read the process of updating a package and creating a debdiff intently. know ... I felt empowered enough to go and try something by myself and I found out I have to go back to basics for further consolidation of my learning, Don't get me wrong ... I have learned LOTS. I have. just for kicks. this line in the IRC log started it all..

16:17 <dholbach> also there are a lot of bugs tagged as 'upgrade', the link is on http://wiki.ubuntu.com/MOTU/Bugs 

So I decided to give it a crack at finding myself a bug marked 'upgrade'. I was confident I could do it... and I did all but it failed to build (you'll find out why)... there are some little differences from the recipe. Here is the bug I found through the ones tagged for upgrade in this link https://wiki.ubuntu.com/MOTU/TODO/Bugs the description read.. please help reviewing them carefully. I spotted this bug. It is basically a package called p3scan that hasn't been upgraded for a while (and I think I know why ;)). I wanted to upgrade it from 2.1 to 2.3.2. I created a new directori in my motu folder and inside that folder I pulled sources using apt (first difference from the recipe) using:

sudo apt-get source p3scan

It downloaded the files I needed and I looked into the directory p3scan-2.1 and checked debian/copyright to find the source of the new package. I followed all steps. In the dch -i, I found myself with changing the maintainer field to meet the debian maintainer spec and I just wrote new upstream version. My dch write gutsy on top of the changelog entry.. and also check that the version is changed to the new one. from p3scan (2:2.1-3) to 2:2.3.2-0ubuntu1 (0ubuntu1 means 0 syncs from debian 1 upload from ubuntu becuase I am taking this straight from upstream because this version isn't in debian yet). WOW listen to me talk :D.

as I proceed with the remaining steps. I try pbuilding the package and surprise surprise. The package does not build. here is the part of the output where all errors start (check the full output here:

In file included from getline_ssl.c:54:
getline_ssl.h:42:25: error: openssl/ssl.h: No such file or directory
getline_ssl.h:43:25: error: openssl/err.h: No such file or directory
In file included from getline_ssl.c:54:

I was keen on getting more learning from this case. So I continued on asking people in #ubuntu-motu. and I was pointed to checking structure differences, that sounded more tecnical but I was willing to see where it lead. I was told to use a tool called interdiff. what it does is that it compares code between the old and the new package. I had to 'sudo apt get install patchutils' to be able to use interdiff... and afterwards I did:

interdiff -p1 -z p3scan_2.1-3ubuntu1.diff.gz p3scan_2.3.2-0ubuntu1.diff.gz 

And i got a nice look long look at the code. and I found the glitch...

+#include "getline.h"  
-#include "getline_ssl.h"

the '+andwhateverfollows' means that line got added to that specific file... and the '-adnwhateverfollows' means that it got remove. that explains the error message.

MEANWHILE IN #ubuntu-motu:

<persia> effie_jayx: Good work.  That's one of the tricky things about new upstreams: upstream changes things, and the packaging has to be adjusted.

Well that means party is over...

I have not the expertise to fix this yet, to be honest I just learned to do an upgrade... and I know how to. but how to adjust a package. that should come in later, I'll get back to the bitesize bugs for hands on for a while (my confort zone) and it is my BugSquad duty.

EXTRA LESSON 1:

Setting up PBUILDER

after reading a bit. I decided to upgrade my pbuilder.

sudo pbuilder update --distribution hardy --override-config

and I also enables more repositories to my pbuilder by editing the /etc/pbuilderrc file. I just uncommented the componets section

from:

#COMPONENTS="main restricted universe multiverse"

to:

COMPONENTS="main restricted universe multiverse"

EXTRA LESSON 2:

Bug Fixing

It has been tough for me to pick a bug and get started, specially after my last attempt at fixing one. It seems to me like every BUG has its complexity. I found it hard to find bugs so I openly asked for suggestions in #ubuntu-motu. I got a response from norsetto who suggested this "SIMPLE" bug... and it is a good bug... cuz it seems to have a duplicate. so fixing one could actually fix TWO.

https://bugs.launchpad.net/ubuntu/+source/ghc6/+bug/120064
https://bugs.launchpad.net/ubuntu/+source/ghc6/+bug/95985

The first bug reports the lack of a manpage for the package ghc6 (the Glasgow Haskell Compiler). and the second one reports that ghc6 has a manpage but it doesn't have an entry for runghc.

It was a bug I could fix IF i only knew a little about manpages. I know nothing. but With a little help from my MOTU friends in #ubuntu-motu I had a good look at the documentation for the process and I started working on it.

I made a new directory and in that directory I downloaded the source

mkdir manpagebug
cd manpagebug
sudo apt-get source ghc6

I inmediately started looking for the manpage. I didn't exactly know where it was, usually and acording to people in #ubuntu-motu they are located in debian/manpage or also and to my surprise there was nothing.

cd ghc6-6.6.1

It all depends on the packaging style. It had no manpage in the source. so What do I do?, you can identify one by looking in debian/ and I also read they have a ".1" example "manpage.1"

I was pointed then to .. debian/rules

nano debian/rules

I had to check if dh_installman was being called in the CLEAN: section. It is there and I checked in the manpage section. and I found this

        # manpages
        ProjectVersion=$(ProjectVersion) $(MAKE) -f debian/scripts.mk all
        for m in ghci6 ghc-$(ProjectVersion) ghci-$(ProjectVersion); do echo ".so man1/ghc6.1" > debian/$$m.1; done
        mv debian/tmp/usr/man/man1/ghc.1 debian/ghc6.1
        cp utils/hp2ps/hp2ps.1 debian/hp2ps-ghc6.1
        echo debian/*.1 > debian/ghc6.manpages

GREAT. a manpage-generating script... I won't get to see the man page gch6 has to see if I can learn. It means I start from scratch... :(. I use the debhelper template for man pages and it gave me the basic structure.

cp /usr/share/debhelper/dh_make/debian/manpage.1.ex /home/valles/MOTU/manpagebug/

After that I used this guide for reference me through the writing of the manpage. It required a lot of editing and viewing to see if it looked ok.

after I had my manpage done. I had to get some sleep. and I picked it up the next day. I had a man page so how do I include it in the package. and this is where it got FUN...

RECAP

So now all I need is to include that manpage and package the source and make a debdiff, post that debdiff to the bugs and asign a sponsor...

SOUNDS SIMPLE, DOESN'T IT? BUT NOOOOOOOO... IT ISN'T... and let's see why...

Remember that #manpages in debian/rules, not only does it generate manpages. but include mine I would have to make it manually. and persia had to step by step guide me through this, even though it was something as easy as editing a file. please refer to the debian/rules, specifically #manpages section.

VOICES FROM #ubuntu-motu

<persia>effie_jayx: That's a really annoying way for it to be done: the packager is updating files in debian/ in debian/rules.  By my reading, it should grab any section 1  manpages in debian/ and stick them in the binary package, making your edit easier.  On the other hand, I think this is broken packaging, and recommend manually creating debian/ghc6.manpages containing the suggested line to make this explicit and clear.

So after a long explanation I learned that all I had to do is put my manpage is debian/ and it would be fine. why?.. the last bit in the script in debian/rules

echo debian/*.1 > debian/ghc6.manpages

all files ending in .1 (manpages??) would be generated into the manpages for the package ghc6. just one little detail. I need to make sure I add my file (rundhc.man):

        # manpages
        ProjectVersion=$(ProjectVersion) $(MAKE) -f debian/scripts.mk all
        for m in ghci6 ghc-$(ProjectVersion) ghci-$(ProjectVersion); do echo ".$
        mv debian/tmp/usr/man/man1/ghc.1 debian/ghc6.1
        mv debian/runghc.man debian/runghc.1  
        cp utils/hp2ps/hp2ps.1 debian/hp2ps-ghc6.1
        echo debian/*.1 > debian/ghc6.manpages

when I do this bit:

        mv debian/runghc.man debian/runghc.1  

my file is renamed to a .1 file and in the last bit. it gets included :D. Now for the clean section, after db_installman generates the generates the manpages. all the .1 files have to be erased. I check the CLEAN setion in debian/rules and I found this among other things.

    rm -f debian/*.1 

ok. so my file is included now. WHAT NEXT?, a changelog entry.

    dch -i

I added the info about the runghc manpage.

then I followed the steps 6 and 7 from the building a package recipe

UPDATE

After you build the package. you have to go get it where pbuilder drops all of its results. I moved it to my working directory.

    sudo cp /var/cache/pbuilder/result/ghc6_6.6.1-2ubuntu3_i386.deb /home/valles/MOTU/manpagebug/

and later all I had to do to test it was run a pbuilder session to test it. Note the mount point I make

   sudo pbuilder login --bindmounts /home/valles/MOTU/manpage/

since the pbuilder is very very stripped ... I first have to install man to test the man page.

   apt-get install man

Since I mounted a share directory (remember --bindmounts /home/valles/MOTU/manpage/) I can know install the package I built and it is located in that same path.

   dpkg -i ghc6_6.6.1-2ubuntu3_i386.deb

It complained about not meeting dependencies. but that didn't stop it from installing. so all I needed was to fetch for them... (thanks for the tip javamaniac)

   apt-get -f install   

and I tested it...

   man ghc6

   man runghc

and DONE... now I needed to generate the debdiff to submit it as a patch. .. I can now exit this session of pbuilder.

   exit

I generated the debdiff. this is the single bit of my work that I will submit through launchpad.

   debdiff ghc6_6.6.1-2ubuntu2.dsc ghc6_6.6.1-2ubuntu3.dsc > ghc6_6.6.1-2ubuntu2.debdiff

Now I have a file with changes, I open the bug report for bug #95985 in my browser and then I just comment what I did. I checked the "attachment is a patch" box, I specified the debdiff path for upload. I changed the status to confirmed. and I subscribed "Ubuntu Sponsors for universe" using the "subscribe someone else" in the menu on the left. I left the bug assigned to nobody. and my work is to wait for someone to check my patch.

I did and I got some feedback on it..., I had to make some slight modifications. this involves going back to building a package, testing it with pbuilder and generating the debdiff. The chances were 1) specify that I had modified debian/rules to include the new manpage. 2) I specified which LP bug I closed. 3) I added a copyright notice at the end of the manpage (license under which I released the manpage). I submitted a second patch.

EXTRA LESSON 3:

Merging

This is one of the things I tryed doing when I first tried to do some MOTU work. Merging is simply applying changes that have been made in ubuntu to debian packages. The idea or merging seeks unison with the debian packages whenever possible. ei: if there is a change in a packages in ubuntu because of a bug that was reported in Launchpad, but you quickly find out it's a bug that also affects debian, then the bug is fixed in ubuntu and a patch is sent to the debian mantainer, or we simply report a bug in the Debian DTS. the fact that the bug gets fixed in ubuntu generates the need for a merge between the debian package and the ubuntu package. you have to keep checking if the change was taken upon by the Debian mantainer, if so. then the merge is not necesary because the debian package already brings the changes that were originated by a bug report in Launchpad for an ubuntu package. COOL isn't it?

Well this sounds complex but it really is no rocket science. all you need is patience and perseverance. all the steps for working on a merge are perfectly laid out in the UbuntuDevelopment documentation.

Some things you should know before you merge

I remember me not knowing enough about this things the first time around.

• Consolidate your debdiff generating skills. Knowing how to read them is also important.
• Know the whereabouts. the paths inside source directory. (debian/changelog, debian/rules, debian/control)
• Always double check for changes. (I always tend to not check enough)

Things I learned during this merge

• I have to read more :P
• I got confident with tools like debdiff.
• Manually editing a changelog entry for a merge. (Remaining entries, adding my own name and adding the current time (date -R))

• Reporting Bugs to the debian BTS (I cheated and I used reportbug-NG)

If you want to check out the merge bug I reported in LP and its state go here

Great Thanks to ScottK and mruiz for their special guidance through my most important MOTU acomplishment to date.

Bug Fixing 2

I received a nice task that seemed challenging enough for me to take:

     <Hobbsee> effie_jayx: please fix [https://bugs.launchpad.net/bugs/110268]

It the bug was on a game called Gweled, I had heard about it before. and It immediately appealed to me. I knew this represented more of a challenge. My bug fixes where all CLI apps, so this definetely represented a challenge. by looking at the bug launchpad. The people triaging seemed to have found the cause of this.

    Emmet Hikory wrote on 2008-02-01:

    I certainly am. The fix is to verify the permissions of the high-score files in the postinst. As previously declated, they should be root.games 664.

Let me ilustrate this for you, after installing gweled you do a ls -l /var/games and you find the issue:

        -rw-r--r-- 1 root root  0 Feb  2 17:04 gweled.easy.scores
        -rw-rw-r-- 1 root games 0 Feb  2 17:16 gweled.timed.scores

• So I basically knew what I had to do. I looked at the permissions of the high-score files. Emmet talked about "postinst". I found the bash scripts in the file, which was in gweled-0.7/debian/gweled.postinst and I found the section that creates the files if they are no already present.

    # gweled scores files get root:games

    SCORE_FILES="
    gweled.easy.scores
    gweled.timed.scores"

    if [ ! -d /var/games ]; then
        mkdir /var/games
    fi

    for FILES in $SCORE_FILES; do

        if [ -e /var/games/$FILES ]; then
            continue
        fi

        touch /var/games/$FILES
        chown root:games /var/games/$FILES
        chmod 664 /var/games/$FILES
    done 

It seemed logically fine. Now I am not a BASH expert. The score files get created with touch /var/games/$FILES if they don't exist already, groups are given access with chown root:games /var/games/$FILES and this is correct acording to what emmet mentions. and last and perhaps the most puzzling thing. BOTH files get the right permission.

I keep looking for answers and as I start looking in debian/rules for anything that may get done to the files there. I ask for some help with understanding some pieces of the debian/rules section and mainly because I need some reading of debhelper, only to find I was looking find that the package was not using debhelper. It was CDBS..., what a NOOB... I need to read more the packaging guide I know. But this was not going to stop me. My dumb question led me to my answer anyways... I learned this:

   <sistpoty>effie_jayx: you could try to set DH_VERBOSE=1 in debian/rules... this will give you lots of output from the debhelper commands (even if called through cdbs)

BINGO... if this is the case then, What should I do? Should I find where it gets made in the first place and erase that section there and let it get created in postinst? or should I just eliminate that file from postinst and leave it to its creation in the other section.

   <albert23> effie_jayx: In my opinion both files should be created in postinst.
   <albert23> effie_jayx: I think if a highscore file is in the package, it will be replaced when you upgrade the package, so you would loose your highscores.

He was nice enough to point me to Makefile, where our score file got created in the first place. I opened Makefile.in and I found the section that created the file

        -$(mkinstalldirs) $(DESTDIR)$(scoredir)
        touch $(DESTDIR)$(scoredir)/gweled.easy.scores
        -chown $(scores_user):$(scores_group) $(DESTDIR)$(scoredir)/gweled.easy$
        -chmod 664 $(DESTDIR)$(scoredir)/gweled.easy.scores
        -if test "x$(setgid)" = "xtrue"; then chgrp $(scores_group) $(DESTDIR)$$

I said.. well I'l just erase this... and then debdiff... and it will get fixed :D, BUT WAIT...

     <albert23> effie_jayx: gweled uses simple-patchsys.mk, so you need to make a patch to keep the sponsors happy

PATCH??? /me nows nothing of patches... (only debdiffs :D). but that was not going to stop me. help was well on its way. behold the autotools crash course:

autotools talk

   <sistpoty> effie_jayx: this is autotools, right? (with configure), if you just change it in the makefile, configure will screw that. if the autotools boogie is done (aclocal, autoconf, automake etc) during build, Makefile.in's will also get recreated.

   <sistpoty> effie_jayx: others then knowing which makefile's are getting recreated, it won't cause problems I guess.

   <effie_jayx> sistpoty,  sorry ... I have not the knowledge to fully understand. but Modifying the makefile won't do is what I understood

   <sistpoty> effie_jayx: gweled uses autotools

   <sistpoty> effie_jayx: in an upstream project that uses autotools, you've just got a number of Makefile.am's lying around.

   <sistpoty>  you run aclocal, autoconf, automake, for each Makefile.am a Makefile.in gets created.

   <sistpoty> that's usually what you are distributing as upstream (sources together with Makefile.in's).

   <sistpoty> if you then run ./configure, Makefiles get created from Makefile.in's

   <sistpoty> and that's what's usually gets done in debian/rules, to run configure first.

   <sistpoty> so if you modify a Makefile, it will get overwritten during build because configure is executed.

   <sistpoty> so you'd want to fix the Makefile.in here.

   <sistpoty> effie_jayx: and another side note: this package uses a patch system, so it would be nice to have it around as a patch ;).

a Patch?

Darn a patch again... I must really learn this, The guys were nice enough to show me how simple it is.

   <sistpoty> effie_jayx: if you directly modify any source file and then build the source package, the difference will land in .diff.gz.
   
   <sistpoty> effie_jayx: some maintainers prefer to seperate different changes they do to upstream sources though.

   <sistpoty> effie_jayx: hence they use a patch system (there are quite some out there).

   <sistpoty> effie_jayx: most ship with a command to create a patch which will then land in debian/patches.

   <sistpoty> effie_jayx: gweled uses cdbs' simple-patchsys, so the command is cdbs-editpatch.

   <sistpoty> effie_jayx: first cdbs-edit-patch agoodnameofwhatyoulldo.

   <sistpoty> effie_jayx: then edit files to your liking.

   <sistpoty> effie_jayx: then exit this shell and you'll have your patch ;).

Well I kept asking because I really new little of this. but I learned that after I edited the files using simple-patchsys. my patch was generated and placed in debian/patches.

   cdbs-edit-patch edit_makefile

Closing the bug

I erased the bit from Makefile.in and then I exited the shell using "exit". my patch was generated. :D. then It was only adding my bit to the changelog, I built the source package and built the package like I have done before. I tested it on a Virtual Machine I have with Ubuntu Hardy (currently alpha 4) and IT WORKED :D. I generated the debdiff. I pasted it on Launchpad and asked for sponsorship.

Launchpad is a very friendly thing to use. To ask for sponsorship I only:

• Assinged NOBODY to the package
• I commented and uploaded my debdiff
• I Susbcribed ubuntu-universe-sponsors using "Subscribe someone else", This is so because gweled belongs to UNIVERSE.
• I pasted the last changelog entry from debian and ubuntu as a comment.

You can see this in https://bugs.launchpad.net/bugs/110268

Submiting a patch to debian

Previously I had done little things, like reporting simple bugs on the debian BTS. this time my participation was more interesting, I had a patch :D. Well, sending this was dead easy. ScottK helped me by maing sure I got this right.

• find the bug in http://bugs.debian.org: I found it just by searching by package (gweled)

• I prepared email to 406884@bugs.debian.org with the following; I expressed what I had done to fix the issue and I attached the file I made, debian/patches/edit_makefile.diff. I also added "Tags: patch". this causes the BTS to act on my patch submission.

you can now see my patch in the debian package description: http://packages.qa.debian.org/g/gweled.html

BIG THANKS TO ALL: Hobbsee, albert23, sistpoty, RainCT and Persia... you guys rock

One more fix and I'll try packaging something.

Pacakge Update 2

I was looking for a package upgrade to futher improve my skills. I had already had an run in with updates and how difficult it can be. I was determined to get my first update going. I chose a package that was somewhat interesting.

https://bugs.launchpad.net/ubuntu/+source/kipina/+bug/95842

Notice the last comment:

LimCore wrote on 2007-12-29

The author responded to my email,
0.1 version of kipina is broken and not supported,
versions 0.2.x are on http://sourceforge.net/projects/kipina/ and they work

Is anyone maintaining Kipina in Ubuntu? Can we use the 0.2 versions?

     '''kipina:''' training program to log physical activities of athletes 
Kipina is a free training log software for athletes to log their physical activities. It is intended to be easy to use but still powerful tool to analyze your training data. 

It needed an upgrade and BOY was I in for a good time. It was simple for me to follow the steps laid out in https://wiki.ubuntu.com/MOTU/Recipes/PackageUpdate. I built the source package fine. When I first tried to build the package, It failed miserably.

        checking for GTK... yes
        checking for GCONF... configure: error: Package requirements
        (gconf-2.0) were not met:
        
        No package 'gconf-2.0' found
        
        Consider adjusting the PKG_CONFIG_PATH environment variable if
        you
        installed software in a non-standard prefix.
        
        Alternatively, you may set the environment variables
        GCONF_CFLAGS
        and GCONF_LIBS to avoid the need to call pkg-config.
        See the pkg-config man page for more details.

So I guess I am missing some build dependencies, they are only used during the building of the package. One suggestion was to add libgconf2-dev but I have read that apps should not depend on dev libraries.

I asked this question in the MOTU-Mentor's mailing list to see and people were quick with the answers:

Emilio Pozuelo Monfort (pochu):

 It's needed for building, so it's fine to add a -dev package to Build-Depends.
 The package itself won't depend on the -dev package, but on the normal package
 (which will be added to Depends by $(shlibs:Depends).

There... I added the extra dependency by editing debian/control and adding libgconf2-dev to the build depends line.I tried building again and I was hit with a similar issue, this time it was scroolkeeper so I added it as well.

Later, I found stuff that got removed. as I copied the debian directory from kipina 0.1.1 I found that many files were missing and during the install the package was asking for those files.

         make[3]: Leaving directory `/tmp/buildd/kipina-0.2.2'
         make[2]: Leaving directory `/tmp/buildd/kipina-0.2.2'
         make[1]: Leaving directory `/tmp/buildd/kipina-0.2.2'
         dh_testdir
         dh_testroot
         dh_install --sourcedir=/tmp/buildd/kipina-0.2.2/debian/tmp
         cp: cannot stat
         `/tmp/buildd/kipina-0.2.2/debian/tmp//usr/share/kipina/xsl/i18n.xml': No such file or directory
         dh_install: command returned error code 256
         make: *** [binary-arch] Error 1
         dpkg-buildpackage: failure: fakeroot debian/rules binary gave
         error exit status 

ok so the errors where generated by the fact that a file is missing. and I am thinking that must not be the only one. so I quickly looked at debian/kipina.install which has a list of files to locate. I quickly learned that some of those files where not in the source directory anymore. I removed the old files that were not included in the new version and I moved along from there but I started thinking.. what about the new files upstream added. I asked again in the list and this is what people had to say:

One tool I recommend to find out what was *added* to the new upstream
version and is not being installed to the package is running:
 
   debuild -us -uc && dh_install --list-missing

nice... a command I can learn and try out. I quickly found that I could not do this without installing the build dependencies... so what people suggested was that I install these in a chroot environment, say pbuilder. I logged in to my pbuilder mounting the directory where I was workingm I installed all build depends and executed the command. I was not really sure of what I had to read. or where to expect output. so I could not make use of this tool. I know it exists and how to execute it.

on a trip

I went on a trip to Caracas, the capital city in my country and I met up with a very interesting debian contributor. Jose Parrela is a debian developer and he offered me to stay with him and his family during my stay. I was really confortable and we had a nice talk about the free and open source movement in Venezuela. He having been around for longer had nice stories to tell.

So he started hacking on his things and I decided to go on with my MOTU stuff and I asked a few questions, he gave me some pointers. He first told me to fix the structure of the directories and how there were being created. he noticed that when he did:

    dpkg --contents /var/cache/pbuilder/result/kipina_0.2.2-0ubuntu1_i386.deb 

he showed me how the package had all the files that had to go in /etc where all in /usr/etc. a quick fix was to add a line in debian/rules that would move all of this.

in the install-build section:

   mv $(CURDIR)/debian/kipina/usr/etc $(CURDIR)/debian/kipina/etc

he also suggested that got rid of the .install and check to see if the package worked. this involved removing the kipina.install file and also removing the parameter for the debhelper install (in debian/rules).

this is how dh_install should look like in binary-arch: build install:

   dh_install

I tried the package when I was home. and BINGO. it worked. the package worked great. I tried to reproduce some bugs I found and they seem to be gone. like html exporting and the likes...

I asked for sponsorship with the help of my friend mruiz and you can find my bug submissing a

• https://bugs.launchpad.net/ubuntu/+source/kipina/+bug/190992

I ws quickly reminded to add the changelog for my update and add (LP: 190992) so that the bug can be closed automatically.

Now I shall use kipina to loose some pounds ;).

Kudos: to dholbach, pochu, and the whole mentor's mailing list.

FIXING A BUG IN MY UPGRADE

It seems I broke something in my upgrade, the preset data for kipina is broken. I think it is a matter of simply making sure a file gets moved to the right directory while the package is installed. I am keen on finding out more on the issue. as of now I am only updating my pbuilder.

sudo pbuilder update --distribution jaunty --override-config

I think It would also be cool If I could adopt the package in debian since it is basically sitting ducks and it might get sacked soon. I personally find kipinä Cool and if I knew enough C I would definetelly help fixing bugs with upstream.

THANK YOU'S

BIG THANKS TO THE VOICES @ #ubuntu-motu: persia, geser and ScottK. you guys make motu a friendly place to be. thanks for your undying patience.

Thank you for your support

• Efrain Valles

• email: effie-jayx AT ubuntu DOT com

• IRC: effie_jayx ON freenode

CategoryMOTULog