[15:35] <fabrice_sp> porthose, about bug 508668
[15:36] <fabrice_sp> -1 (testing) FTBFS but -1.1 (unstable) don't (was building the pacakge before going to lunch)
[15:44] <randomaction> We can't sync -1 because we already have -1ubuntu1 ;)
[15:49] <fabrice_sp> oh right randomaction :-)
[15:49] <fabrice_sp> I'll update the bug report then ;-)
[15:55]  * randomaction test-builds opensg. Last build errored out after 3h45min
[16:18] <fabrice_sp> try to build im-sdk, and you'll see :-D
[16:29] <kamalmostafa> fabrice_sp: hi Fabrice.  fyi I have corrected the patch for bug 507163 as you rightly suggested -- should be ready to go now.
[16:30] <fabrice_sp> kamalmostafa, I've seen that. I've just working on it ;-)
[16:31] <fabrice_sp> (it should be ok, as it's an easy fix)
[16:32] <kamalmostafa> fabrice_sp: now *that* is quick service!  :-)   thanks!
[16:32] <fabrice_sp> lol
[16:32] <fabrice_sp> Thanks to you to work on it ;-)
[16:35] <fabrice_sp> by the way: remember to update the maintainer field ;-)
[16:35] <kamalmostafa> did I miss that for the qtoctave fix?  oops!
[16:35]  * kamalmostafa rushes off to go double-check the other three merges in the queue
[16:35] <fabrice_sp> lol
[16:36] <fabrice_sp> and also, to close the bug report in the changelog entry ;-)
[16:37] <kamalmostafa> wow, i must have forgotten to have a cup of coffee before doing that one!
[16:38] <fabrice_sp> :-)
[16:38]  * fabrice_sp is test building qtoctave right now)
[16:39] <kamalmostafa> And I see that I forgot update-maintainer on one of of my other merges also...  I'll fix it.
[16:41] <fabrice_sp> ok
[16:43] <fabrice_sp> is anyone using piuparts to check the 'instalability' of an upload before uploading?
[16:44] <fabrice_sp> it fails in most packages because it fails to install the packages in the right order (lib before -dev,, for example)
[16:51] <kamalmostafa> fabrice_sp: Okay my three pending u-u-s merge requests are all 'update-maintainer'ed and 'changelog-LP'ed (after fixing one!).   FYI, the 'inteltool' and 'clxclient' FTBFS fixes are trivial changes.   The other one at the top of the queue (bug 208913) has been pending for 8 days -- any guess why it might be so delayed?
[16:51] <fabrice_sp> kamalmostafa, I've tried aprsd yesterday, but was unable to reproduce the pb
[16:52] <kamalmostafa> I can help you reproduce it if you'd like.  I'm quite familiar with the package and this problem.
[16:52] <fabrice_sp> oh really?
[16:52] <fabrice_sp> yesm, then: I installed the package yesterday, stated it, but didn't find any port to 'use'
[16:52] <kamalmostafa> yes, it is a ham radio package -- I have used it for years (on and off)
[16:53] <fabrice_sp> :-D
[16:53] <kamalmostafa> i'll uninstall my fixed version here, and we can walk through it if you wish.
[16:53] <fabrice_sp> ok
[16:54] <kamalmostafa> just a moment -- i'll push my running installation of aprsd off to the side here...
[16:54]  * fabrice_sp installes again aprsd in his test chroot
[17:00] <kamalmostafa> fabrice_sp: ok, i am ready when you are.  FYI, aprsd listens on several tcp ports for various programs which can connect to it.  One such port is "14500".  Clients which speak its protocol connect to 14500 and log in to aprsd by sending a text line like "user foobar pass whatever".   On 64-bit platforms (only) aprsd crashes while parsing the "user ..." line.   We will start aprsd manually from the cmdline, then connect to it wi
[17:01] <kamalmostafa> fabrice_sp:  Oh, and you *are* using a 64-bit platform here, right?  Bug doesn't manifest on 32-bit.
[17:01] <fabrice_sp> yeah: amd64 here
[17:02] <kamalmostafa> ok, if aprsd is already running, kill it, then start just "aprsd" from the command line (no arguments).
[17:02] <fabrice_sp> kill'd
[17:02] <randomaction> fabrice_sp: re im-sdk, I think that correcting format strings may fix that segfault
[17:03] <fabrice_sp> randomaction, I saw that Debian claimed to have fixed the issue. Didn't had time to actually really check the Debian version
[17:04] <fabrice_sp> kamalmostafa, aprsd running
[17:04] <kamalmostafa> fabrice_sp: assuming aprsd is running (blocked), start another terminal and run "telnet localhost 14500" and type "user foo<ENTER>"
[17:05] <kamalmostafa> (Note there will be no character echo to the telnet session when typing "user foo<ENTER>")
[17:05] <kamalmostafa> aprsd crashes with segfault
[17:05] <fabrice_sp> ok
[17:05] <fabrice_sp> reproduced
[17:05]  * fabrice_sp will now test build your version
[17:06] <fabrice_sp> by the way: just uploaded qtoctave
[17:06] <kamalmostafa> note also that a *remote* user can also crash your aprsd this way -- aprsd binds to all network interfaces -- so this exposes aprsd to being killed by any remote user at any time.
[17:07] <fabrice_sp> this program is 7 years old, right? (from 2003)
[17:07] <kamalmostafa> yes, its getting pretty long in the tooth, but it is used very widely in the ham radio community.
[17:07] <fabrice_sp> ok
[17:10]  * kamalmostafa goes for more coffee (brb)
[17:11] <geser> I once looked at this merge proposal (aprsd) and it wasn't obvious for me why it fixed it (and it didn't happen on ia32). Do you know why it crashes on amd64 but works on i386?
[17:16] <randomaction> it assumes that pointers can be converted to ints
[17:18]  * fabrice_sp is looking for the definition of size_t in amd64
[17:19] <geser> is probably a signed long (64bit)
[17:20] <kamalmostafa> size_t is unsigned.    ssize_t is the signed variant.  And yes, its' 64-bits wide on a 64 bit machine.
[17:20] <kamalmostafa> geser: Hi geser.  Yes, I do understand it --  well... I did when I debugged and fixed it a couple weeks ago anyway ;-)   As I remember it, the problem is all about the value 'npos', which is getting used (poorly) as a sentinel value.
[17:20] <geser> right
[17:23]  * geser googles the definition of string::npos
[17:23] <kamalmostafa> Looking at the diff in the merge request, see src/servers.cpp at line 967:    if (( rc != string::npos)     That broke when 'rc' was declared to be only 32-bits wide, since npos will be 64-bits wide on a 64-bit system.   Bottom line is that all the "string index" variables need to be 64-bits wide to match what's happening in the string::npos class.
[17:24] <kamalmostafa> It all made much more sense in 'gdb'  ;-)
[17:25] <geser> now I understand the problem (and the fix): comparing an unsigned variable of 32bit and 64bit (both set to '-1') doesn't really work
[17:25] <kamalmostafa> geser:  yes, exactly.
[17:26] <kamalmostafa> fundamentally, the problem (in my opinion) is the poor design choice to use -1 as the sentinel value at all here, but that's not aprsd's fault.  :-)
[17:28] <fabrice_sp> in 2003, amd64 was not so frequent
[17:29] <geser> kamalmostafa: a small hint: if your changelog entry was a little more verbose than "fix crash" it would be easier to understand what's exactly the problem and why it fixes it
[17:31] <kamalmostafa> geser:  point well taken... this one certainly did warrant more explanation than I provided!  I'll be more verbose next time.
[17:32]  * fabrice_sp just uploaded the patch
[17:36] <fabrice_sp> kamalmostafa, for bug 508633, I prefer to wait for Debian, as the fix just consists in not having it built for this arch
[17:37] <fabrice_sp> so better autosync the package when it get fixed in Debian (instead of diverging now)
[17:39] <kamalmostafa> fabrice_sp: that's fine with me regarding inteltool.   The amd64 and i386 packages still get uploaded anyway (despite the build failure for all other platforms), correct?
[17:39] <fabrice_sp> yes
[17:39] <fabrice_sp> it FTBFS in arch where the package is of no use
[17:40] <geser> should it be also added to P-a-S?
[17:41] <kamalmostafa> geser: the package hasn't yet been fixed in Debian -- they're just talking about it.   don't we only subscribe p-a-s when its ready to be sync/merged from debian?
[17:41] <fabrice_sp> geser, it would make sense, yes
[17:41] <fabrice_sp> kamalmostafa, p-a-s are not archive admin :-D
[17:42] <geser> kamalmostafa: P-a-s: Packages-arch-specific
[17:43] <geser> see https://edge.launchpad.net/packages-arch-specific (and its branch)
[17:43] <kamalmostafa> geser: okay, thanks.  I thought p-a-s was something else altogether.
[17:44] <kamalmostafa> i will subscribe p-a-s to this.
[17:45] <fabrice_sp> geser, dose it makes sense to update the ubuntu p-a-s branch? Or better wait for Debian?
[17:46] <kamalmostafa> i see that p-a-s is a project, not a team, so I cannot subscribe p-a-s to the bug.  I'll leave it to you folks to handle.
[17:47] <geser> hmm, I'm not sure if limiting the Architecture field is enough or if soyuz will try to build it anyways (until it's listed in P-a-s). Will have to ask soyuz people and/or buildd admins
[17:49] <kamalmostafa> geser: Just limiting Architecture: as I did made it work properly in my PPA test...  On Karmic, I made a "no-change" PPA and it built for (i386,amd64,lpia) -- but after my change, the PPA only built for (i386,amd64).    (I had to use Karmic to do this test, since Lucid PPA's only build for i386 and amd64 anyway).
[17:53] <ScottK> geser: Limiting the architecture field works.
[17:54] <geser> ok
[17:56] <fabrice_sp> do we support upgrade path from dapper?
[17:56] <Laney> to hardy
[17:57] <fabrice_sp> but not to lucid, then. Thanks!
[17:57]  * fabrice_sp will ddrop an ubuntu change for obsolete :-)
[18:04] <kamalmostafa> fabrice_sp and geser:  Thanks for all the help.  Question about the aprsd crash...  Might it qualify for an SRU, given the denial-of-service exposure that any remote use can crash it trivially?
[18:05] <kamalmostafa> s/remote use/remote user/
[18:20] <fabrice_sp> kamalmostafa, not sure: it's only amd64 and it has been known for almost 2 years . I would say it can wait 3 month :-)
[18:30] <kamalmostafa> fabrice_sp: Okay, got it.  Thanks again!
[19:05] <hakaishi> Hi folks! Anyone up to review qt-shutdown-p? It is a small program to shutdown the computer. It uses qdbus to send a shutdown request to the session manager or to HAL or alternatively uses sudo shutdown -P now. http://revu.ubuntuwire.com/p/qt-shutdown-p
[19:20] <doctormo> How can I get my application to appear in the add/remove software center?
[19:24] <randomaction> Can a developer's @ubuntu.com address be listed in Maintainer field? (update-maintainer script is refusing to alter it)
[19:26] <fabrice_sp> randomaction, shouldn't be, as the mailing list if the official maintainer address
[19:26] <fabrice_sp> In this case, you should update it by hand
[19:26] <randomaction> ok
[19:27] <randomaction> thanks
[19:27] <geser> it's allowed
[19:27] <geser> if the dev wants to be the contact then he can put himself in maintainer
[19:27] <hakaishi> How can I add an image for a program in synaptic?
[19:28] <geser> therefore the scripts checks on @ubuntu.com and not the list address
[19:29] <doctormo> Hmm, older guides say to use X-AppInstall-Package in a .desktop file and put it in /usr/share/app-install/desktop/ but that doesn't make sense, how does it get in there.
[19:32] <ajmitch> morning
[19:35] <randomaction> I think I'll leave it as it is then
[19:39] <geser> doctormo: you might need to look how app-install-data gets build (and where it pulls its data from)
[19:39] <doctormo> geser: I think that what I want is not possible.
[20:09] <Quintasan> Hello
[20:19] <geser> Hi
[20:28] <sebner> hola geser :D
[20:28] <geser> Hi sebner
[20:39] <dhillon-v10> Quintasan, hi :) did you close that bug we were working on the other day
[20:39] <dhillon-v10> geser, hi :)
[20:42] <Quintasan> dhillon-v10: hmm you mean that KVM thingy? well the MALLOC something variable helped but it's a veeeery dirty hack I think
[20:42] <dhillon-v10> Quintasan, true :) so how are we going to solve it, or should we wait until nixternal find some time and help us out with it
[20:44] <Quintasan> dhillon-v10: he got the exacly the same error, I expect his backtrace to be a little bit different though :)
[20:45] <dhillon-v10> Quintasan, ahh yes, he reported that bug :) I guess we can wait for sometime and see if upstream kernel does something about glibc
[21:30] <crimsun> geser: were you working on merging fuse from Debian testing?
[21:36] <geser> crimsun: yes, bug #506958 (awaiting sponsoring)
[21:44] <crimsun> geser: thanks, looking now
[21:53] <ianto> Hello,  does anybody know the name of the command line application which searches whether or not a package exists in the Ubuntu and Debian repos and their version number?  Auto searches both sets of repos and it isn't apt cache.
[21:55] <and`> ianto: rmadison packagename
[21:56] <crimsun> note that it doesn't "auto [search] both sets of repos"
[21:56] <chashall> hello maco are you there?
[21:56] <ianto> and`: That's the one,  thanks :)
[21:56] <and`> ianto: np
[21:59] <crimsun> geser: looks good; have you verified that it continues to work on a local lucid system?
[22:01] <geser> have you any hints how to test it (as I don't know if I use fuse or not), I've checked only so far if the package updates (inside a pbuilder, didn't have upgraded my system at that time yet)
[22:03] <crimsun> geser: reading from and writing to an NTFS partition, sshfs, etc.
[22:15] <geser> crimsun: I've restarted to make sure that any device permissions are still correct after a reboot, mounted my windows partition in nautilus and viewed a picture from it and copied a new one to it
[22:17] <crimsun> geser: all right. I'll do some testing over NTFS and ssh this evening, then upload if no one has reservations/beats me to it. Thanks very much for looking at it!
[22:18] <geser> and building zfs-fuse works too (it's in DEPWAIT on a newer libfuse-dev)
[22:24] <ScottL> i've been packaging a new app (nedko's zynjacku and lv2rack) for the ubuntu studio devs and am having trouble getting the menu entry in the audio submenu on the ubuntu studio menu
[22:25] <ScottL> i can get it in the audio/video menu but not into the audio submenu
[22:25] <ScottL> anyone have any suggestions or ideas?