[00:04] <broder> Rcart: hmm, i think i actually disagree with that bug report. if i was maintaining that package, i would tell the user to configure the package to not start automatically (using policy-rc.d - see http://manpages.ubuntu.com/manpages/precise/en/man8/invoke-rc.d.8.html#contenttoc6), which would keep the postinst from trying to start the daemon
[00:04] <broder> but i can't actually find anything in the debian policy manual to back me up on that
[00:11] <broder> Rcart: ok, just uploaded mpd
[00:15] <Rcart> broder: I think that the second comment is right, it would be easier for the user to just receive a warning and not a critical error that stops the update/install procedure
[00:16] <broder> Rcart: that would be different behavior than almost every other postinst script i've seen
[00:16] <broder> the standard postinst snippet for starting an initscript exits with an error if the start fails
[00:18] <Rcart> I see. He said that will fix it (on 5 Jul 2008) and seems like he didn't X:
[00:18] <Rcart> should I add a bug watcher linking that (debian) bug report?
[00:19] <broder> to what?
[00:19] <Rcart> the LP bug report
[00:19] <broder> which bug report?
[00:19] <Rcart> (that you mentioned)
[00:20] <Rcart> #778571}
[00:20] <broder> ah. no - the one i mentioned is a different bug from the one described
[00:20] <Rcart> Ah, ok
[00:21] <Rcart> I'll add a bug watcher to the bug you reviewed
[00:21] <broder> huh?
[00:22] <Rcart> xD
[00:22] <broder> no, i don't think there's any bug in lp right now that matches the debian bug you linked to
[00:22] <broder> you should only link bugs if it's the same bug being reported in two places
[00:23] <Rcart> the bug I was working on you uploaded it, I'll report it to debian and link it to LP
[00:23] <broder> ah, yes. that would be excellent :)
[00:23] <broder> sorry for the confusion
[00:23] <Rcart> :D
[00:24] <Rcart> Think I need to read carefully the scripts post-pre-etc and try to work on bugs like that
[00:34] <Rcart> Thanks for your help broder, I'm leaving. o/
[00:35] <broder> Rcart: no problem! thanks for stopping by and contributing!
[00:36] <Rcart> (:
[01:45] <akrogames> Thanks jtaylor for your help
[01:46] <akrogames> hi broder
[01:46] <broder> akrogames: hey, what's up?
[01:47] <akrogames> I live in France and I'm tired and you ?
[01:47] <akrogames> I learned to fix bugs
[01:57] <akrogames> good night, so later
[04:23] <mfisch> jtaylor: I found out the fix for live-manual, it's not pulling a new version.  I'm still trying to figure out the right way to actually make the change.  Ping me when you're around and I'll explain
[04:42] <mfisch> jtaylor: strike that, I have the debdiff ready to go, just need to know where to put it so that a MOTU can take it from there
[05:26] <tumbleweed> !sponsorship| mfisch
[05:45] <mfisch> tumbleweed: thanks, I'll take a look in the morning
[08:12] <tumbleweed> Changed-By: Ubuntu Merge-o-Matic <mom@ubuntu.com>
[08:12] <tumbleweed> ^ we should have a noisy lintian check for that
[08:13] <micahg> heh
[08:33] <vibhav> It is possible to sync a Ubuntu package to Debian?
[08:34] <tumbleweed> vibhav: there's no automated proces for it
[08:34] <tumbleweed> it generally works better to maintain the packgae in Debian and sync to Ubuntu
[08:35] <vibhav> I prefer to upload it to Ubuntu first, since I am not experienced in the Debian process
[08:36] <tumbleweed> all the tools (and people) assume that Debian is the upstream
[08:36] <tumbleweed> and I think Debian is a better place to maintain packages (the stronger maintainership makes sense for packages you care about)
[08:38] <vibhav> I still can upload it to Ubuntu first?
[08:38] <tumbleweed> nothing stops you from doing that
[08:40] <bkerensa> tumbleweed: Assuming he has upload privileges or gets a package sponsored
[08:40] <tumbleweed> did something change in apport? There's hardly any information in bug 940800
[08:45] <Ampelbein> tumbleweed: bug 944078
[08:47] <tumbleweed> hrm, probably it
[10:00] <pkt> what is the process of fixing these http://qa.ubuntuwire.com/bugs/rcbugs/
[10:00] <pkt> Is there a document about this?
[10:02] <pkt> I mean I can download the debian source, get the relevant patch etc, then where and how do I submit the result?
[10:03] <micahg> pkt: either request a sync if appropriate or submit a patch for sponsorship either through a bug or bzr branch
[10:04] <pkt> how do I request a sync?
[10:04] <pkt> ok I found, sorry for that question
[10:04] <micahg> pkt: use requestsync from ubuntu-dev-tools (use the -e flag if the new version has new features since we're past feature freeze)
[10:04] <pkt> http://qa.ubuntuwire.com/bugs/rcbugs/
[10:05] <pkt> ok, thanks :)
[11:31] <pkt> I tried requestsync -e radare but it doesn't work since it says the versions are the same (in reality they aren't)
[11:33] <micahg> pkt: if it's only in unstable you'll need -d unstable
[11:33] <tumbleweed> pkt: -d unstable
[11:34] <pkt> thanks :)
[11:34] <pkt> (and sorry for the newbie questions)
[11:34] <tumbleweed> np, that's an issue that only comes up with LTS releases where we sync from testing by default
[11:38] <Pikkachu> this is confusing http://developer.ubuntu.com/packaging/html/packaging-new-software.html
[11:39] <tumbleweed> Pikkachu: what are you finding confusing? let's fix it
[11:41] <Pikkachu> it's entirely confusing, but gtg now
[11:45] <pkt> I think I succeeded (https://bugs.launchpad.net/ubuntu/+source/radare/+bug/946269)
[11:46] <pkt> Is this correct?
[11:46] <tumbleweed> pkt: that doesn't need an FFe, it's only a bug fix
[11:46] <pkt> uff, I understood wrong then
[11:47] <pkt> should I close the bug?
[11:47] <tumbleweed> if the upstream part (before the dash) of the version hasn't changed, it is unlikely to need the FFe
[11:47] <pkt> It shouldn't need
[11:47] <pkt> it is a trivial bug fix
[11:47] <tumbleweed> no, lets leave it as a sync request, it just doesn't need an FFe
[11:47] <pkt> so, what did I do wrong?
[11:47] <tumbleweed> there, done
[11:48] <tumbleweed> it didn't need -e
[11:48] <pkt> ah, ok :)
[11:48] <pkt> Thanks :)
[11:53] <pkt> So the correct command would have been requestsync -s radare -d unstable
[11:53] <pkt> I will learn slowly slowly :)
[11:53] <tumbleweed> yes
[11:54] <tumbleweed> if you have a recent requestsync (using LP API) you don't need -s either, it'll wor that out itself
[11:54] <pkt> I 'm using latest precise so I guess it is recent enough
[11:54] <tumbleweed> yes
[11:55] <pkt> great, continuing to the next package :)
[16:43] <Pikkachu> I have source code for which compilation is like $apt-get install build-dep other; $apt-get source other; cp here/patched other/foo/bar; cd other; ./configure; cd foo/bar; make patched.so
[16:44] <Pikkachu> how would I make a bin deb and how to put this on a recipe?
[16:45] <pkt> first of all instead of cp here/patched other/foo/bar you should have a proper patch
[16:45] <pkt> in the form of a unified diff
[16:46] <pkt> if the package you are patching has source format 3.0 (quilt) then it is very easy to add a patch
[16:47] <pkt> https://wiki.ubuntu.com/PackagingGuide/Complete
[16:48] <Pikkachu> "first of all instead of... " -- you don't really understand what's that
[16:49] <Pikkachu> I will explain what it is
[16:49] <pkt> please do :)
[16:49] <Pikkachu> sorry for calling it patch, it's a new plugin for pidgin called ircaway
[16:50] <pkt> From the process you described it looks as if you want to patch pidgin to include it
[16:50] <Pikkachu> it's a single ircaway.c for which I need to create the .so, instructions in pidgin website suggested me to put the source under pidgin-source/pidgin/plugins and run $make ircaway.so
[16:51] <pkt> Does pidgin provide a way to build plugins out of tree?
[16:52] <pkt> If it doesn't you need to convince them to add it, or add the source file as a patch
[16:52] <Pikkachu> so I use pidgin's build infrastructure which is able to build arbitrary plugins if they're under that folder, I did this because it just works and I don't want to waste time trying to figure out how to build it alone
[16:52] <pkt> sure
[16:53] <pkt> but this can't work for packaging I think
[16:53] <pkt> either it needs a way to be built standalone
[16:53] <Pikkachu> please this has nothing to do with patches unless they decided to add the plugin to upstream
[16:53] <Pikkachu> from the pidgin docs, the plugin author would provide the way the plugin needs to be built
[16:54] <pkt> fair enough
[16:54] <Pikkachu> but I'm reading the docs themselves for that
[16:54] <pkt> but pidgin should provide a way to build plugins against it
[16:54] <Pikkachu> which don't explain how to build them alone
[16:54] <pkt> i.e., libraries etc
[16:55] <pkt> are there any pidgin plugins distributed as standalone packages?
[16:55] <Pikkachu> I suppose because it's a plugin it somehow would require most or much of the original infrastructure to build pidgin itself
[16:55] <Pikkachu>  https://wiki.ubuntu.com/PackagingGuide/Complete -- is totally confusing
[16:56] <Pikkachu> sorry I mean the new guide
[16:56] <Pikkachu> I just know of purple plugin pack, a set of plugins, distributed as a separate package
[16:59] <pkt> apt-cache search pidgin shows a few extra packages
[16:59] <pkt> you can check if any of them are small enough to be used as examples
[17:00] <tumbleweed> Pikkachu: does libpurple-dev or pidgin
[17:00] <tumbleweed> -dev have wha tyou need?
[17:01] <pkt> I would propose pidgin-extprefs
[17:01] <pkt> it is also a single .c file from what it seems
[17:01] <pkt> so maybe you can reuse its build infrastructure
[17:01] <Pikkachu> tumbleweed: does what?
[17:02] <pkt> He asks if it provides the needed libraries etc
[17:02] <pkt> but I think the problem is to figure out the build system
[17:02] <Pikkachu> pkt: sorry I'm not in Ubuntu right now, but does extprefs stand itself as a pidgin plugin?
[17:02] <pkt> yes it seems so
[17:03] <Pikkachu> pkt: yeah it's a problem -dev x build-dep
[17:03] <Pikkachu> first of all I don't get why can't one put the build deps as deps of the -dev packages
[17:04] <Pikkachu> anyway, libpurple-dev and pidgin-dev contain just headers iirc
[17:04] <Pikkachu> and build-dep for pidgin is really big
[17:04] <pkt> Pikkachu: again, I think you can try extprefs plugin as a template to build from
[17:04] <Pikkachu> pkt: ok will try to take a look at extprefs
[17:05] <pkt> if you are not on ubuntu you can get the source package from the web
[17:05] <pkt> It has some extra stuff for installing on win32 and such, you can just ditch those
[17:06] <pkt> and just copy the linux-related infrastructure
[17:09] <Pikkachu> ok
[17:10] <pkt> great :)
[17:10] <tumbleweed> Pikkachu: if it's a single c file, it can't be that hard to build, right?
[17:10] <pkt> not true
[17:11] <pkt> a kernel module is also a single file
[17:11] <pkt> s/is/can be/
[17:11] <tumbleweed> and they are fairly straight forward to build
[17:11] <pkt> not without the kernel's build infrastructure
[17:11] <Pikkachu> yeah
[17:11] <pkt> you can't just call gcc on it by hand and expect a working module
[17:12] <pkt> Pikkachu's issue is that he is trying to figure out the corresponding build system for pidgin plugins
[17:12] <Pikkachu> I just don't get why build-dep is not reversible like normal deps with autoremove
[17:12] <tumbleweed> I'm saying that that may be more effort than it's worth
[17:13] <tumbleweed> Pikkachu: use mk-build-deps, then they are easy to remove
[17:13] <Pikkachu> I think you don't really understand the problem, tumbleweed
[17:13] <Pikkachu> I have no idea how would I "use mk-build-deps"
[17:14] <tumbleweed> Pikkachu: of course I don't, I haven't seen the source[6~
[17:14] <tumbleweed> it has a manpage
[17:14] <tumbleweed> but basically, mk-build-deps -ir inside an extracted source package
[17:14] <Pikkachu> are you trying to sound cool? it's not working
[17:15] <tumbleweed> Pikkachu: I'm trying to be helpful
[17:15] <pkt> Pikkachu: yes
[17:15] <tumbleweed> and you don't appear to want help, so I'm not entirely sure why I'm bothering
[17:15] <pkt> I think there is a misunderstanding
[17:15] <pkt> tumbleweed's advice is useful
[17:15] <Pikkachu> of course, those standard responses, please I disregard your help, right now, ignore me PLEASE
[17:16] <pkt> Pikkachu: mk-build-deps solves the problem of being able to unistall the stuff apt-get build-dep brought in
[17:16] <tumbleweed> Pikkachu: sorry, I tend to not give complete hand-holding instructions, but rather point you in useful directions, and expect you to do some research yourself
[17:17] <Pikkachu> tumbleweed: sorry I stopped at 'sorry'. I'm not really interested in your help, sorry
[17:17] <tumbleweed> np
[17:18] <Pikkachu> pkt: well but it will just output the package names, which is mostly the same as saving build-dep's output :(
[17:18] <pkt> Pikkachu: not just that
[17:18] <pkt> it will also make a binary package that depends on them
[17:19] <pkt> so you can install this package to install the build-deps
[17:19] <pkt> and then remove it and they will become removable through autoremove
[17:19] <pkt> of course I don't know how useful this is now (if you have already installed them by build-dep)
[17:20] <pkt> but for future reference
[17:21] <Pikkachu> I'd have to do it for every package I want the build deps, I'm just saying there should be something like 'autoremove --build-deps'
[17:21] <pkt> It is the same number of commands
[17:22] <pkt> I.e., instead of "apt-get build-dep <foo>" you do "mk-build-deps -ir"
[17:22] <pkt> and this way the build deps are instantly autoremovable
[17:22] <pkt> I didn't know about this script myself to be honest, I had hacked my own solution for this problem :P
[17:53] <akrogames> hi all
[17:56] <mfisch> I'm making a change on a package that has no branches in launchpad, can I just attach a debdiff to the bug and leave it at that?  Or, should I make an initial branch and then commit on top of that to show the diffs?
[17:57] <tumbleweed> debdiffs are fine. Nobody requires you to use bzr
[17:57] <tumbleweed> however, why does i tnot have any branches in LP?
[17:58] <mfisch> tumbleweed: because, I think, until now it was just, uh, pure debian, no ubuntu changes
[17:58] <tumbleweed> mfisch: no, it should still have branches
[17:58] <tumbleweed> what package is it?
[17:58] <mfisch> let me confirm that assumption
[17:58] <mfisch> okay nevermind :(
[17:58] <tumbleweed> :)
[17:58] <mfisch> I just wasn't looking in the right place
[18:00] <pkt> still the information that bazaar is not really needed is useful
[18:01] <tumbleweed> I still find it easier to not use bzr, but bzr is certainly becoming more appealing
[18:01] <mfisch> I prefer bzr myself
[18:02] <ral> As someone who has only done a small amount of packaging I found modifying a package with bzr very straightforward.
[18:04] <mfisch> when I do the merge proposal don't i need to add ubuntu-sponsors as a reviewed?
[18:04] <mfisch> reviewer i mean
[18:04] <tumbleweed> orrect
[18:04] <tumbleweed> err, you don't need to
[18:04] <mfisch> mind if i add that to the wiki?
[18:04] <mfisch> hmm ok
[18:05] <mfisch> tumbleweed: how will it end up in sponsor queue?
[18:06] <tumbleweed> the sponsorship queue includes all merge proposals against ubuntu pcakages
[18:06] <mfisch> alright, I'll see if this shows in the queue in a bit
[18:07] <ESphynx> hey guys... Would anyone be able to assist me? I'm having really bad troubles with Precise. It fails to build our software in the most silly way...
[18:08] <tumbleweed> ESphynx: this isn't really a support channel, but those kind of thinsg we can probably help with. Also, don't ask to ask, just ask :)
[18:08] <mfisch> tumbleweed: thanks for the ifno, I attached a debdiff and did a merge-prop
[18:09] <ESphynx> It builds fine on Oneiric, which is GCC 4.6.1 .  I was trying to install the 'standard' GCC 4.6.2 on Precise to see if it would build fine (Seeing that GCC/MinGW 4.6.2 on Windows works fine), but then my Precise VM died on me =(
[18:09] <tumbleweed> mfisch: so it'll show up twice :)
[18:09] <ESphynx> tumbleweed: you the man.
[18:10] <tumbleweed> ESphynx: can you pastebin the error?
[18:10] <ESphynx> I don't know what happened to my VM.. last night I went to sleep after the GCC build was going on... this morning the Vbox interface is just jammed, even cloning the machine jams taking 0% CPU
[18:10] <ESphynx> tumbleweed: the errors won't really help you, it's my compiler doing really silly stuff that it normally doesn't
[18:11] <pkt> ESphynx: do you have a hardware problem or something?
[18:11] <ESphynx> The only thing I can't think up is a messed up GCC
[18:11] <tumbleweed> ESphynx: you sure your hard drive isn't going? check dmesg...
[18:11] <pkt> or zero free disk space?
[18:11] <mfisch> tumbleweed: eh, should I nuke my merge proposal then?
[18:11] <ESphynx> pkt: no hardware problem, this is on Launchpad PPA building machines as well
[18:11] <mfisch> tumbleweed: not sure if I can remove the attachment from the bug
[18:11] <ESphynx> pkt: no, dynamic vdi drives with plenty of space
[18:11] <tumbleweed> mfisch: I can unsubscribe sponsors from the bug
[18:11] <mfisch> tumbleweed: bug #831392
[18:12] <ESphynx> tumbleweed: https://launchpadlibrarian.net/95143170/buildlog_ubuntu-precise-i386.ecere_201203031148-0~446~precise1_FAILEDTOBUILD.txt.gz  -- the build log, but like I said it won't help much
[18:12] <mfisch> my bug-day contrib, 48 hours late ;)
[18:12] <tumbleweed> mfisch: thanks
[18:12] <ESphynx> tumbleweed: It is virtual machines, and PPA building machines! no HW issue.
[18:12] <ESphynx> I was suspecting a bug in the Ubuntu GCC 4.6.2 patches.
[18:12] <pkt> mfisch: is it 48-hours late? hehe I thought the Jam was during the weekend as well
[18:13] <mfisch> pkt: oh well I'm good then!
[18:13] <pkt> I still haven't finished my contribution :S
[18:13] <mfisch> pkt: you're running out of time there in Greece!
[18:13] <tumbleweed> ESphynx: the ppa build failed for a very clear reason
[18:14] <ESphynx> tumbleweed: Which reason is that?
[18:14] <pkt> mfisch: true, just a few hours more :P
[18:14] <tumbleweed> error: unresolved identifier publicAccess; expected ecere::com::Module
[18:14] <pkt> but can't I say that my personal clock is in pacific timezone :P
[18:14] <ESphynx> tumbleweed: that is not supposed to happen.
[18:15] <ESphynx> tumbleweed: also consider "warning: incompatible expression "ecere::sys::FileAttribs FileExists(char * fileName)" (byte *); expected pe"
[18:15] <ESphynx> there's no such thing as "pe" anywhere in our software...
[18:15] <ESphynx> the compiler (the bootstrap eC compiler) is all messed up
[18:16] <ESphynx> none of this happen on any other Ubuntu versions...
[18:16] <mfisch> tumbleweed: how often is the sponsor queue updated?  hourly or so?
[18:17] <ESphynx> My Precise VM is dead :| will have to reinstall everything... So much for trying to build my own GCC 4.6.2 :|
[18:17] <tumbleweed> mfisch: I think every 10 mins or so. Maybe 30. depends how big it is (the script that produces it takes forever to run)
[18:17] <tumbleweed> ESphynx: sorry, I thought you were saying tha tthe build had killed your VM
[18:17] <ESphynx> tumbleweed: building GCC killed my VM.
[18:18] <pkt> ESphynx: how much RAM did you give to your VM?
[18:18] <ESphynx> ah the hw errors, is what you were talkign about :) hehe, on a Windows host though
[18:18] <ESphynx> pkt: 2gb
[18:18] <ESphynx> sorry I thought you guys were blaming the failed build on hw hehe
[18:18] <pkt> And still it died
[18:18] <pkt> hehe
[18:18] <ESphynx> yes :(
[18:18] <pkt> Interesting
[18:19] <ESphynx> you guys have other flavors of Gcc installed on Precise?
[18:19] <ESphynx> we could give that a try?
[18:19] <pkt> I have a VM here with precise (kvm)
[18:19] <pkt> if you want I can install a version of gcc
[18:19] <ESphynx> pkt: I would greatly appreciate taht.
[18:20] <pkt> But know that I can't build gcc on this VM
[18:20] <pkt> it has just 256MB ram
[18:20] <ESphynx> pkt: I gave up on building GCC :P
[18:20] <ESphynx> pkt: but I couldn't figure out out to try 4.6.1, for example, without building it
[18:20] <ESphynx> if you do know how ;)
[18:20] <pkt> I can try to find out
[18:20] <pkt> just a sec
[18:20] <tumbleweed> ESphynx: w still have a gcc-3.5 package in precise
[18:20] <tumbleweed> err 4.5
[18:21] <ESphynx> i decided to try building 4.6.2 , since it built our software fine on Windows
[18:21] <ESphynx> tumbleweed: ah yes... I guess we could try that. but that's quite far from 4.6.2 :|
[18:21] <ESphynx> but it would help narrow down the problem
[18:21] <pkt> I see 4.6.3 as default here
[18:21] <tumbleweed> yeah
[18:21] <ESphynx> See, our first open source release on Ecere was 0.44 draft 1, on Dec 25, 2008.... and this coming Wednesday is finally the official 0.44 ;)
[18:22] <ESphynx> And I would like to build on Precise, at least when it comes out :)
[18:22] <pkt> 4.4, 4.5, 4.6 are all available
[18:22] <ESphynx> pkt: 4.6.3 now ? is it a newer VM?
[18:22] <pkt> which one do you want?
[18:22] <pkt> It has latest precise on it
[18:22] <ESphynx> pkt: maybe i'm out of date hehe...
[18:22] <ESphynx> pkt: care to try 4.6.3 first ?
[18:22] <pkt> sure why not
[18:23] <ESphynx> guess i'll link you to the source package?
[18:23] <pkt> but if lp failed probably it was with  4.6.3
[18:23] <pkt> sure
[18:23] <pkt> do you have it on a ppa?
[18:23] <ESphynx> yes
[18:23] <ESphynx> https://code.launchpad.net/~jerstlouis/+recipe/ecere-daily-multiarch
[18:24] <ESphynx> gcc-4.6 i386 4.6.3-1ubuntu2 [7576 kB]
[18:24] <ESphynx> right, lp failed on 4.6.3 as well :(
[18:25] <ESphynx> so the easy thing would be to try 4.4 ? to establish whether GCC is to blame or not?
[18:25] <ESphynx> since 4.5 is dev right, so latest dev might have the bug as well?
[18:25] <pkt> I think 4.5 should be release as well, not dev
[18:26] <ESphynx> ah right osrry
[18:26] <ESphynx> it's the middle number
[18:26] <ESphynx> hmm.
[18:26] <ESphynx> my only worry... when installing side by side... our build system just invokes 'gcc'
[18:27] <pkt> I think gcc is selected using alternatives
[18:27] <ESphynx> so you can try 4.5
[18:27] <ESphynx> please =)
[18:28] <pkt> sure but you will need to wait a few mins
[18:28] <ESphynx> np
[18:30] <ESphynx> I gues another thing to try would be to disable -O2 ...
[18:30] <pkt> that you can also try yourself
[18:30] <ESphynx> guess I could try that on a new Precise machine
[18:30] <ESphynx> yes. i'll brb, logging out to kill stalled VBox
[18:33] <Pikkachu> hi pkt, not much help http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/pidgin-extprefs/oneiric/view/head:/debian/control
[18:34]  * Pikkachu rebooting to ubuntu
[18:40] <pkt> Pikkachu: fwiw I didn't understand what you meant
[18:40] <Ampelbein> Pikkachu: There are lots of pidgin plugins in ubuntu, have you had a look at how they accomplish the build?
[18:40] <pkt> what was the problem with pidgin-extprefs?
[18:46] <Pikkachu> Ampelbein: and this is what you call "a lot"? http://i.imgur.com/Q5hAT.png
[18:46] <PaoloRotolo> Hi all!
[18:46] <pkt> Pikkachu: try from the command-line
[18:46] <pkt> there are several
[18:46] <pkt> apt-cache search pidgin
[18:46] <ESphynx> That .vdi was so locked down, even "Restart" wouldn't work... i had to press the Reset button :|
[18:47] <pkt> Pikkachu: but still what was the problem with extprefs, I chose it for you because it is also a single .c file
[18:48] <Pikkachu> pkt: I have no idea whether its Build-Depepndencies field matches?
[18:48] <Pikkachu> pkt: can we start from the beginning?
[18:48] <pkt> sure
[18:49] <pkt> for starters, where is ircaway.c ?
[18:49] <Ampelbein> Pikkachu: I count 24 plugins, that is a lot.
[18:49] <ESphynx> well the good news is I miraculously kept that .vdi (because it was locked! i had done "delete all files"), and it works
[18:50] <pkt> nice :)
[18:50] <ESphynx> so now I can try taking out -O2 :P
[18:50] <Pikkachu> Ampelbein: ignore me from now on, and I'm serious
[18:50] <Pikkachu> hi ESphynx, how's eC going :)
[18:50] <Pikkachu> pkt: well, I will stand it in a simple way then
[18:51] <pkt> sure, simple always helps
[18:52] <Pikkachu> I have a Bazaar branch for a new plugin for pidgin, I want Launchpad building the deb and putting it available, that simple. I tried and read docs about recipes, ppa, packaging, and they're just confusing, so I wanted to start from this simple point with human help
[18:53] <pkt> can you give the link to that branch?
[18:54] <Pikkachu> fwiw I can generate the .so by ./configuring the pidgin host and $making plugin.so from within pidgin-source/pidgin/plugins (that is, this build thing I used is from pidgin)
[18:54] <pkt> Pikkachu: sure, but this won't help you produce a package
[18:55] <Pikkachu> pkt: https://code.launchpad.net/~renatosilva/pidgin/ircaway
[18:55] <pkt> Pikkachu: great
[18:56] <Pikkachu> pkt: yeah I just mentioned that because I'm not sure how to build the plugin at all except by reusing pidgin infrastructure, which is sort of overkill for a small plugin I think
[18:56] <pkt> it is not just overkill
[18:56] <pkt> it is also not going to be accepted
[18:57] <pkt> so, you need to figure out how to build it standalone
[18:57] <pkt> this doesn't just mean the debian/ part
[18:57] <pkt> it also means the makefile etc
[18:58] <pkt> In fact, the first thing you need to figure out is what to put to the makefile
[18:58] <pkt> you can start simple, assuming that you don't ever want to build for other platforms, so you don't need the autoconf stuff
[18:59] <Pikkachu> do I really need a makefile? because I think that even that is overkill, no?
[18:59] <pkt> no
[18:59] <Pikkachu> why not, just to understand
[18:59] <pkt> Because you need to ensure you are building against the proper headers / libraries
[19:00] <pkt> you could also write a bash script but a Makefile is the standard way to do it (TM)
[19:00] <pkt> so at the very minimum you need the .c file and a Makefile
[19:01] <pkt> and most likely a README
[19:01] <pkt> once you have those, you can also make the debian/ folder with the right contents
[19:03] <tumbleweed> +1 to Ampelbein's suggestino of looking at other plugins, and yes, writing a simple Makefile is probably the easiest way to get a working package
[19:09] <Pikkachu> pkt: ok so let's leave the deb thing for a separate stage. I'm new to make, I've just used it, how would I figure out the dependency tree for the source file compiling?
[19:09] <Pikkachu> tumbleweed: I'm looking right now, will take a look at their makefile
[19:11] <pkt> Pikkachu: typically you use pkg-config
[19:11] <pkt> Pikkachu: here is my suggestion
[19:11] <pkt> go to the extprefs plugin
[19:11] <pkt> do the mk-build-deps -ir thing
[19:12] <pkt> and now do a debuild -uc -us 2>&1 | tee -a ../build.log
[19:12] <pkt> this will show you which commands the makefile of this plugin called
[19:12] <pkt> it is much easier than trying to analyse its source
[19:12] <pkt> because the source is obfuscated a lot by the automake infrastructure that you don't need
[19:13] <Pikkachu> I'm trying to process what you said
[19:13] <pkt> btw, I hope this advice is ok and not considered as spamming the channel
[19:14] <tumbleweed> sure, nothing else going on right now. (weekends are quiet)
[19:14] <tumbleweed> Pikkachu: no tee reqd, debuild writes a log to ../$pkg.build
[19:14] <pkt> even better
[19:15] <tumbleweed> err pkt
[19:15] <Pikkachu> I'm really annoyed by all this word salad I've been through in the docs, I'm really lost
[19:16] <jtaylor> :O why have I been using tee all the time?!
[19:16] <Pikkachu> I'm looking in pidgin-facebookchat now
[19:16] <pkt> This is why trying to help on IRC is helpful
[19:16] <pkt> most time you learn new stuff yourself
[19:17] <pkt> Pikkachu: sure, pick the simplest you can find
[19:18] <tumbleweed> Pikkachu: the solution to that is to improve the docs, so it helps if you can tell us where you are getting stuck / confused
[19:19] <pkt> facebookchat looks much more complicated
[19:19] <Pikkachu> pkt: I'm having to install devscripts for mk-build-deps, I hope I don't need any more word-salad packages since it has already a salad of dependencies itself :(
[19:19] <tumbleweed> devscripts is certainly something you want. Any sane packaging documentation should have told you that pretty early on
[19:19] <tumbleweed> I'd also recommend ubuntu-dev-tools
[19:22] <Pikkachu> tumbleweed: the docs are confusing to the point you don't know where it's confusing, but I'd say write something to someone like "I have source code to give people, I want Launchpad to build and publish the .debs for me". Something straighforward to follow for that kind of developer like me
[19:23] <pkt> Pikkachu: the thing is that you need to know the basics of open source development before you start caring about packaging
[19:23] <tumbleweed> Pikkachu: I'm afraid there's a bit of stuff you need to learn along the way, debian packaging has quite a lot going on in it
[19:23] <Pikkachu> pkt: I don't like these standard unclear responses, please
[19:24] <Pikkachu> pkt: any sane developer would hate the whole toolset, to begin with
[19:24] <pkt> I 'm trying to make it specific (searching for a link to a howto)
[19:25] <tumbleweed> Pikkachu: please don't insult our build systems, that doesn't motivate people to help you
[19:25] <Pikkachu> I've read the docs pkt, they're confusing
[19:25] <Pikkachu> tumbleweed: please ignore me, right now, and I'm serious
[19:26] <Pikkachu> pkt: I think the core problem is
[19:26] <tumbleweed> Pikkachu: if you can't have a civil conversation in this channel, could you please move it elsewhere
[19:26] <Pikkachu> pkt: how to know what packages are needed to build the source code
[19:27] <pkt> Pikkachu: what tumbleweed says is true (it is not nice to insult people that try to help you)
[19:27] <pkt> about the build dependencies
[19:27] <pkt> just pick a random plugin (facebookchat)
[19:27] <pkt> and do mk-build-deps -ir in its directory
[19:27] <Pikkachu> tumbleweed: I said kindly to ignore me, and I was serious, I'm not offending you so if you're willing to do something without any reason, I don't really care at all except you're in my way to publish software to people
[19:28] <Pikkachu> pkt: yeah I will concentrate in that point now
[19:28] <pkt> or apt-get build-dep pidgin-facebookchat
[19:28]  * tumbleweed wanders off
[19:28] <Pikkachu> pkt: if I get anything relevant and I'm still here I'll let you know
[19:28] <pkt> ok
[19:29] <Pikkachu> pkt: oh that's even better I can see the packages before confirming, a second...
[19:29] <ESphynx> sorry guys, I was cooking my breakfast ;)
[19:29] <ESphynx> Pikkachu: quite good! if we can only get it working on Precise :) we're releasing the official 0.44 this wednesday
[19:29] <pkt> Hehe, you are lucky it is already night here ...
[19:30] <Pikkachu> pkt: debhelper gir1.2-json-1.0 html2text libdbus-1-dev libdbus-glib-1-dev libglib2.0-dev libjson-glib-dev libpurple-dev po-debconf zlib1g-dev
[19:30] <Pikkachu> pkt: so your idea is eliminating from above what seems unnecessary?
[19:30] <pkt> I would also install pidgin-dev just to be on the safe side
[19:31] <pkt> my idea is to manage to build your plugin out of tree first
[19:31] <pkt> then you can care about removing stuff
[19:31] <pkt> your first objective should be to build the .so successfully from outside pidgin's directory
[19:32] <pkt> by installing the build-deps from another plugin at least you know that the headers/libs you need are available to begin with
[19:32] <pkt> now you need to write your Makefile correctly
[19:35] <Pikkachu> ESphynx: glad to know you got your way on PPas
[19:36] <ESphynx> Pikkachu: almost there, hehehe
[19:36] <ESphynx> Pikkachu: just Precise failing to build :(
[19:39] <ESphynx> pkt: well, taking out -O2 doesn't seem to help!!
[19:42] <Pikkachu> pkt: the makefile from that plugin is 137 lines long, should I read it and amke mine based on that?
[19:43] <ESphynx> Would anyone know how different the Ubuntu patches for GCC are, and how likely they are to cause memory corruption issues? :|
[19:44] <pkt> The short answer is that nothing is impossible with gcc ...
[19:44] <ESphynx> hehehe
[19:45] <jtaylor> what is the problem?
[19:45] <ESphynx> now that i've ruled out the -O2... i'm pretty sure it's a bug in either 4.6.2 on linux, or the ubuntu patches...
[19:46] <ESphynx> jtaylor: My compiled bootstrap eC compiler is going nuts.
[19:46] <ESphynx> jtaylor: it works fine on oneiric and all previous Ubuntus.
[19:47] <pkt> ESphynx: https://code.launchpad.net/~ecere-team/+archive/ppa/+files/ecere_201203031148-0~446~precise1.dsc
[19:47] <pkt> should I try this with gcc-4.5?
[19:47] <jtaylor> does valgrind help?
[19:47] <ESphynx> pkt: yes, please :)
[19:48] <pkt> Ah, btw, I just remembered one of the nuances of gcc 4.6
[19:48] <ESphynx> jtaylor: it could. I usually use my own memory protection tool called 'memoryguard', but since the thing doesn't build yet :P
[19:48] <pkt> (the ubuntu version)
[19:48] <ESphynx> pkt: Ah? (Note it works fine in Oneiric, 4.6.1 ...)
[19:49] <pkt> the $CFLAGS should be in the end of gcc command
[19:49] <pkt> e.g., gcc $FLAGS -c foo.c -o bar.o won't link
[19:49] <pkt> gcc -c foo.c -o bar.o $CFLAGS will work
[19:49] <ESphynx> it won't ? :S
[19:50] <pkt> the reason is a bit esoteric
[19:50] <pkt> and it will work in previous versions AFAIK
[19:50] <ESphynx> love how this word keeps popping up lately.
[19:50] <Ampelbein> pkt: Nothing to do with CFLAGS.
[19:50] <jtaylor> -c does not linking
[19:50] <pkt> yes sorry
[19:50] <pkt> it is actually the linker flags
[19:50] <ESphynx> ok, i'm all confused here... but here it's not something that won't link
[19:51] <ESphynx> every gcc command compiles and links
[19:51] <ESphynx> it just produes horrible results.
[19:51] <Ampelbein> The problem in many packages was that libraries were added in LDFLAGS, which is the wrong place to put them. They belong in either LDADD or LIBADD.
[19:51] <pkt> exactly
[19:51] <pkt> and because ubuntu has a patch to make the linker stricter
[19:52] <Ampelbein> pkt: Ubuntu uses --as-needed by default.
[19:52] <pkt> yep
[19:52] <pkt> gcc-as-needed.diff
[19:52] <ESphynx> I put them in $(LIBS): $(TARGET): $(SOURCES) $(RESOURCES) $(SYMBOLS) $(OBJECTS) | objdir
[19:52] <ESphynx> 	$(CC) $(OFLAGS) $(OBJECTS) $(LIBS) -o $(TARGET) $(INSTALLNAME)
[19:52] <pkt> A friend of mine got burned by this but his source was technically broken anyway
[19:53] <pkt> http://lists.debian.org/debian-devel-announce/2011/02/msg00011.html
[19:53] <ESphynx> Ampelbein: Could this particular difference have any impact on memory corruption?
[19:54] <Ampelbein> ESphynx: Unlikely.
[19:54] <ESphynx> downloading Valgrind.
[19:54] <ESphynx> it's just a matter of linking with -lvalgrind , is it?
[19:54] <jtaylor> no
[19:55] <jtaylor> running your application under valgrind
[19:55] <ESphynx> No linking necessary?
[19:55] <jtaylor> no
[19:55] <ESphynx> Guess I can try that.
[19:55] <ESphynx> it used to be just linking with it right? :)
[19:56] <pkt> no
[19:56] <ESphynx> In the early days?
[19:56] <pkt> it was always running it under valgrind
[19:56] <pkt> there were other projects that required linking
[19:56] <pkt> e.g. electricfence etc
[19:56] <ESphynx> ah. electric fence is the one I was thinking of.
[19:56] <pkt> valgrind works in a different way
[19:57] <ESphynx> k.
[19:57] <jalcine> viva la valgrind.
[19:57] <pkt> your program sees valgrind "as the cpu" sort of
[19:57] <ESphynx> eC's memoryguard works by using another version of libecere.so :)
[19:57] <ESphynx> k
[19:57] <ESphynx> it's surely nowhere as good as valgrind, but usually works great :P Can you run Valgrind on MinGW/Windows?
[19:58] <ESphynx> ok guys. What is wrong with bash's tab completion???
[19:58] <pkt> works here
[19:59] <ESphynx> It's trying to be too intelligent, and won't let me complete files!
[19:59] <ESphynx> e.g. doing make obj/ doesn't autocompelte... it will only give me 'rules', but what if I want to specify an object target?
[20:04] <pkt> you can use shopt -u progcomp I think
[20:04] <pkt> this will disable programmable completion
[20:04] <ESphynx> prog-and-args -- how does that work? I did  'valgrind obj/ecc myargs here' but my app doesn't seem to be getting any args?
[20:04] <pkt> then you can enable it again
[20:05] <ESphynx> hehe k, thanks!
[20:06] <ESphynx> sorry, I had a space where I shouldn't have. works now
[20:07] <ESphynx> ok, under Valgrind, it seems to compile fine!
[20:07] <ESphynx> I get a bunch of 'Source and destination overlap in strcpy(0xbea45aeb, 0xbea45aeb)'
[20:09] <pkt> Hehe great, how I always manage to get more than I sign up for :P
[20:09] <pkt> I started with the simplest RC bug, it seemed to be "just a resync request"
[20:09] <pkt> now it seems that the package actually needs surgery
[20:10] <ESphynx> pkt: Which package is that? :P
[20:10] <pkt> radare
[20:10] <pkt> I picked it from the list of rc bugs
[20:10] <ESphynx> hehe
[20:10] <pkt> since it was among the few that I knew about :P
[20:11] <ESphynx> So these strcpy things... I'm not really worried about :|
[20:11] <pkt> ESphynx: the friend that had the problem with linking because of as-needed
[20:12] <pkt> he also had a memory corruption
[20:12] <pkt> because he had a double free bug in his code
[20:12] <pkt> i.e., he free'd a var without making it NULL and then he free'd again
[20:12] <ESphynx> but his double free bug was unrelated to the as-needed, right?
[20:12] <pkt> yes
[20:12] <ESphynx> yeah, no such thing as double free in my code ;P
[20:12] <ESphynx> and it works fine in Valgrind!
[20:12] <pkt> I only mention because this problem also only showed in gcc 4.6
[20:13] <ESphynx> maybe I should replace calls to ecc in the package by 'valgrind ecc' for Precise :P
[20:13] <pkt> *with
[20:13] <pkt> It seems you are dealing with a "heisenbug"
[20:13] <ESphynx> hehhe
[20:13] <ESphynx> is than an uncertainty principle?
[20:14] <pkt> It is a term used for a bug that doesn't want to reproduce under debugging infrastructure
[20:14] <pkt> like gdb or valgrind
[20:14] <ESphynx> hehe. let me try simple gdb.
[20:15] <pkt> So, about radare. I got the package from debian, but it wouldn't build
[20:15] <pkt> then I discovered that the version in precise shouldn't build either
[20:15] <pkt> (it has the same bug)
[20:15] <ESphynx> great, under gdb, it goes nuts.
[20:16] <pkt> and now that this is fixed as well, lintian decides to reject it
[20:16] <pkt> because of the decision in debian to reject waf binaries :P
[20:17] <tumbleweed> well, at least yo uare half way there
[20:18] <pkt> I hope more than half hehe
[20:18] <pkt> But this could probably be characterised a "hydra bug"
[20:19] <pkt> every subbug I fix 2 others are revealed :P
[20:19] <ScottK> The new minc in Unstable looks like we might want it, if someone has time to investigate...
[20:20] <ESphynx> jtaylor: Any idea why something would work on Valgrind (without seeing any error), but behaves nuts on GDB?
[20:20] <jtaylor> valgrind runs under a very different environment
[20:20] <jtaylor> which is often more resistant to issues
[20:20] <jtaylor> did it output any errors?
[20:20] <ESphynx> jtaylor: only those strcpy overlap errors (strcpy(string, string))
[20:21] <jtaylor> thats your issue
[20:21] <jtaylor> libc has changed
[20:21] <jtaylor> this will now crash
[20:21] <ESphynx> jtaylor: you sure?
[20:21] <jtaylor> yes
[20:21] <jtaylor> memcpy's are now done backwards
[20:21] <jtaylor> that breaks overlaps
[20:21] <ESphynx> i.e. you're positive something changed between oneiric and precise ?
[20:21] <jtaylor> but is faster
[20:21] <ESphynx> ugg. on x86?
[20:21] <jtaylor> its something that changed recently
[20:22] <ESphynx> I can understand on some exotic platform
[20:22] <ESphynx> but on x86?
[20:22] <jtaylor> use memmove for overlaps
[20:22] <jtaylor> on x86
[20:22] <ESphynx> it's not even 'overlap' is the same string :|
[20:22] <akrogames> hi jtaylor
[20:22] <ESphynx> well. if you say so!! I'll go and hunt those down.
[20:22] <ESphynx> thanks for clarifying this
[20:22] <jtaylor> not sure how that will work
[20:22] <jtaylor> but its 100% an issue that must be fixed
[20:22] <ESphynx> jtaylor: you mean the same string?
[20:23] <jtaylor> there should be a flag for libc hhat disables the feature
[20:23] <jtaylor> read the README
[20:23] <ESphynx> jtaylor: i'd love to try out that flag...
[20:23] <ESphynx> to be sure before I invest the time to fix this
[20:23] <jtaylor> let me check
[20:23] <ESphynx> thanks
[20:23] <ESphynx> (So it would be libc rather than gcc?)
[20:24] <jtaylor> yes
[20:25] <jtaylor> LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libc/memcpy-preload.so /path/to/binary
[20:26] <jtaylor> though that change should already be in oneiric
[20:26] <broder> ESphynx: regardless of whether it fixes *the* problem you're trying to track down, strcpy(string, string) is definitely *a* problem and you should not be doing it
[20:27] <ESphynx> I understand and respected that for memcpy...
[20:27] <ESphynx> But to me strcpy(string, string) should just work :P
[20:27] <jtaylor> no it should not
[20:27] <jtaylor> and never should have
[20:27] <ESphynx> Why not :)
[20:27] <jtaylor> the manpage clearly says the memory regions *must* not overlap
[20:28] <jtaylor> ok it only says may not :O
[20:28] <ESphynx> too bad Dennis isn't among us anymore to discuss it :P
[20:28] <jtaylor> that should be fixed
[20:33] <jtaylor> why do you do that copy in the first place?
[20:34] <ESphynx> jtaylor: i use it e.g. for left trimming purposes
[20:34] <ESphynx> strcpy(string, string + x) , where x sometimes is 0
[20:35] <ESphynx> From Valgrind's output, it seems to happen in 3 spots: LoadTranslatedStrings, ChangeExtension, and TrimLSpaces
[20:35] <broder> ESphynx: it would be better to strcpy(string + x) and then free(string)
[20:35] <broder> assuming you're using a heap buffer
[20:36] <broder> err, sorry, strdup
[20:36] <ESphynx> right.
[20:36] <ESphynx> I have my own memory manager though... so I have CopyString()
[20:36] <ESphynx> but I generally try to avoid heap allocs...
[20:38] <ESphynx> thanks guys. since I only have 3 spots should be easy to try it out
[20:38] <jtaylor> did the wrapper work?
[20:39] <ESphynx> jtaylor:  LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libc/memcpy-preload.so /path/to/binary  --> this is to revert to the previous way?
[20:39] <jtaylor> yes
[20:39] <ESphynx> let me try that
[20:39] <jtaylor> there is also a version that dumps to syslog
[20:39] <jtaylor> LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libc/memcpy-syslog-preload.so /path/to/binary
[20:40] <ESphynx> hmm x86 here, not 64 bit
[20:40] <jtaylor> hm the change is only in amd64
[20:41] <ESphynx> yeah I don't seem to have this memcpy-preload.so
[20:43] <ESphynx> nor a /i386-linux-gnu/libc directory :|
[21:18] <pkt> Hmm, ok now the package builds, so the problem becomes how to push the fixes
[21:19] <pkt> It isn't just a sync request anymore since there is an extra patch
[21:20] <pkt> And I think maybe it would be good to push to debian as well
[21:24] <micahg> pkt: is this for radare?
[21:24] <pkt> yes micahg
[21:24] <jtaylor> can I see the diff?
[21:25] <jtaylor> the package looks in bad shape
[21:25] <jtaylor> lots of uncaught errors in the logs
[21:25] <jtaylor> as needed issues
[21:25] <jtaylor> requires py2.5
[21:25] <micahg> and we have radare2 already
[21:26] <jtaylor> can we just remove radare then?
[21:26] <micahg> no reverse dependencies, we could remove it
[21:26] <pkt> I 'm fine with removing it as well
[21:26] <pkt> my fix is just for the FTBFS
[21:27] <jtaylor> I looked at it too, fixing one issue just uncvered another issue later ...
[21:27] <jtaylor> etc etc
[21:27] <pkt> hehe exactly
[21:27] <jtaylor> I'm for nuking it
[21:27] <micahg> well, the explicit python2.5 dep isn't expressed in the packaging
[21:27] <pkt> this is what I fixed
[21:28] <pkt> and for lua as well
[21:28] <pkt> the build deps are implicit in the Makefile
[21:28] <jtaylor> ruby is needed too
[21:28] <pkt> it seems to build without it here
[21:29] <jtaylor> can you pastebin your diff
[21:29] <pkt> sure
[21:29] <ESphynx> jtaylor: I'll be damned.
[21:29] <ESphynx> jtaylor: The build is working now. Thank you!!!
[21:30] <pkt> http://pastebin.ubuntu.com/868973/
[21:30] <jtaylor> you didn't fix the as needed issue?
[21:30] <pkt> no
[21:31] <pkt> I didn't see that one
[21:31] <jtaylor> my not working "fix": http://paste.ubuntu.com/868975/
[21:31] <jtaylor> src/rsc/gtk/Makefile needs fixing
[21:31] <jtaylor> that worked pre oneiric
[21:32] <pkt> when you say not working what do you mean?
[21:32] <pkt> FTBFS?
[21:32] <pkt> or not working result?
[21:32] <ESphynx> Now I have a question guys regarding the multiarch stuff... Adding ia32-libs-multiarch fixed the build on oneiric, but on Precise it doesn't.
[21:32] <ESphynx> I realize that people can just install the i386 build on their Precise amd64 install... But what about people wanting to build from source on amd64?
[21:32] <jtaylor> it does not link, but the error is noon fatal
[21:32] <jtaylor> but its an regression
[21:33] <pkt> I see
[21:33] <pkt> I can look at it
[21:33] <pkt> unless the package is to be dropped of course
[21:34] <jtaylor> I don't really now the difference between the two
[21:36] <ESphynx> Alt-F "Search" shortcut ? how can I disable that? :|
[21:38] <ESphynx> ah no, it's just 'alt / released' :| how annoying!!
[21:51] <ESphynx> the hud :| disabled that...
[21:51] <ESphynx> E: Package 'ia32-libs-multiarch' has no installation candidate --> where should I ask about this?
[21:52]  * Pikkachu tired
[21:52] <ESphynx> when tired, sleep :)
[21:53] <ESphynx> "This may mean that the package is missing, has been obsoleted, or is only available from another source"
[21:56] <pkt> micahg fwiw I think I fixed the as-needed issue as well
[21:56] <pkt> Sorry for taking so long but compiles take long time here
[21:58] <ESphynx> tumbleweed: you remember this amd64 issue I had? =)
[22:08] <pkt> http://pastebin.ubuntu.com/869020/
[22:08] <pkt> these are my changes
[22:08] <ESphynx> pkt: Any idea about multiarch? :| where should I ask about this? :\
[22:09] <pkt> sorry, not much experience with this
[22:09] <ESphynx> I basically want to know how one is meant to build a 32 bit app on a 64 bit machine :|
[22:09] <pkt> ah ia32-libs-multiarch
[22:09] <pkt> it reminds me of something
[22:09] <JanC> multiarch allows you to install i386 packages on an amd64 system
[22:10] <pkt> wine was broken a little time ago because of this I think
[22:10] <ESphynx> adding this fixed the build on Oneiric (i.e. just ia32-libs, which works on Natty, wasn't enough)
[22:10] <pkt> there was a change for precise IIRC
[22:10] <JanC> so no more need for ia32-lib*
[22:10] <ESphynx> JanC: I understand that. but what about 'building' on a 64 bit machine
[22:10] <JanC> (in theory)
[22:10] <ESphynx> a 32 bit app?
[22:11] <JanC> well, I guess you would need the right 32-bit compiler & -dev packages
[22:11] <ESphynx> JanC: which are all specified in my package dependencies... So I would wish my package builds on a 64 bit machine as well
[22:12] <ESphynx> But I get this error: Package ia32-libs-multiarch is not available, but is referred to by another package.  This may mean that the package is missing, has been obsoleted, or is only available from another source. E: Package 'ia32-libs-multiarch' has no installation candidate
[22:12] <JanC> ESphynx: one option is to use a chroot or similar
[22:12] <JanC> pbuilder can do that...
[22:12] <ESphynx> JanC: On Oneiric, which also uses multiarch, it 'just works'
[22:13] <ESphynx> (My makefiles all have -m32 to build in 32 bit)
[22:13] <JanC> BTW: you probablmy don't need/want any ia32-lib* packages anymore
[22:14] <JanC> as a dependency
[22:14] <ESphynx> JanC: but I do need the 32 bit dev packages to be installed! how can I let the package manager know about that?
[22:14] <ESphynx> for the build to work...
[22:14] <pkt> btw I think the package is now ia32-libs-multiarch:386
[22:15] <ESphynx> pkt: that might work :)
[22:15] <JanC> maybe specify dependencies as libfoo-dev:i386 ?
[22:15] <ESphynx> JanC: I got all those coverd (well not with :i386... I just learned about that :P)
[22:15] <ESphynx> i'm downloading Precise 64 so I will give that a try
[22:16] <JanC> what I mean is: don't use the ia32-* stuff anymore  ;)
[22:17] <ESphynx> JanC: right. use :i386 instead ?
[22:17] <JanC> I think so
[22:17] <ESphynx> that's basically my question :P hehe, what should I do :P
[22:18] <JanC> I think you should build them on a 32-bit system/chroot and then install using :i386 on the amd64 system  ;)
[22:18] <ESphynx> JanC: that's not easy for people downloading my software as source :P
[22:18] <JanC> at least, I think that's how it's done officially
[22:18] <ESphynx> I want them to just do 'make' and it works
[22:18] <JanC> PPA?
[22:18] <pkt> JanC's way seems the right way to go
[22:19] <ESphynx> ESphynx: i mean, right from a git clone... I want them to just do 'make' even if they are on amd64
[22:19] <ESphynx> pkt: :i386 ?
[22:19] <pkt> I mean to build in 386 chroot
[22:19] <ESphynx> pkt: that's a pain for users.
[22:19] <JanC> ESphynx: why would you need to build 32-bit only anyway?
[22:19] <pkt> :i386 seems to be for depending on i386 libraries
[22:20] <ESphynx> JanC: 'cuz my software doesn't support 64 bit yet :P (i hope it will later this year...)
[22:20] <pkt> not for dev tools, at least if I understand correctly
[22:21] <ESphynx> pkt: those ia32-libs / ia32-libs-multiarch did get things building on oneiric though :P
[22:21] <JanC> ESphynx: make a daily build PPA on Launchpad for those who want the latest version, but really, you should fix your software first instead of trying to set up weird build systems  :P
[22:22] <Pikkachu> amazing, I installed libglib2.0 and it succeeded to install, but now thinks removing it is too dangerous???
[22:22] <ESphynx> JanC: yes, but I still think it should be possible to build in 32 bit on a 64 bit system.
[22:22] <pkt> Unfortunately I have to leave now
[22:22] <ESphynx> I mean, it was easy before
[22:22] <ESphynx> thanks for all your help pkt. good night and take care :)
[22:23] <pkt> I will put radare in my ppa and look into how to merge it tomorrow
[22:23] <RAOF> It *is* possible to build 32bit binaries on a 64bit system, but it's non-trivial.
[22:23] <pkt> thanks ESphynx: I hope you will solve the build problems
[22:23] <ESphynx> JanC: and it's not weird :P
[22:23] <JanC> ESphynx: it is possible, but the recommended way is to use a chroot or a VM  ;)
[22:23] <ESphynx> RAOF: Any advice?
[22:23] <ESphynx> pkt: I solved the i386 one!
[22:23] <pkt> cheers, goodnight everyone :)
[22:23] <ESphynx> pkt: it was the stricter libc regarding strcpy overlap...
[22:23] <pkt> ah, that makes sense yes :)
[22:24] <RAOF> ESphynx: Multiarch gets you *most* of the way there, but -dev packages aren't multiarched yet.
[22:24] <ESphynx> as jtaylor pointed out ;P
[22:24] <JanC> building binaries is one thing, building packages complicates it somewhat more
[22:24] <Pikkachu> if I didn't recover the additional files the system would be compromised: libglib2.0-0-dbg libglib2.0-0-refdbg libglib2.0-cil-dev libglib2.0-doc
[22:24] <ESphynx> RAOF: it was working on oneiric ... with ia32-libs and ia32-libs-multiarch
[22:24] <ESphynx> RAOF: but on precise now I get this weird E: Package 'ia32-libs-multiarch' has no installation candidate
[22:24] <ESphynx> RAOF: https://launchpadlibrarian.net/95113396/buildlog_ubuntu-precise-amd64.ecere_201203031148-0~446~precise1_MANUALDEPWAIT.txt.gz
[22:24] <Pikkachu> anyone using pidgin help me testing a thing?
[22:25] <ESphynx> Pikkachu: What's your pidgin plugin do?
[22:25] <RAOF> ESphynx: Oh!  That's very simple - don't build an amd64 package :)
[22:26] <RAOF> ESphynx: Your i386 package will show up on amd64 packages, and the multiarch support will pull in the relevant dependencies.
[22:26] <ESphynx> RAOF: I understand that. but I'm worrying about people ON a 64 bit machine, wanting to build my source.
[22:27] <ESphynx> I want 'make' to work for them.
[22:27] <Pikkachu> ESphynx: changes nick when you are away (can't be tested within this channel :(, but you could use some other network )
[22:28] <ESphynx> Pikkachu: hehe sorry I don't use pidgin, I use Ecere Communicator and mIRC :P was just curious
[22:28] <RAOF> ESphynx: Ah.  That's no longer possible without some manual work on their side (creating dev symlinks).  It only accidentally worked with ia32-libs, too :)
[22:31]  * Pikkachu brb
[22:32] <ESphynx> RAOF: I wish it would accidentally work again.
[22:32] <EvilResistance> is CDBS still supported/used?
[22:32] <EvilResistance> for packaging
[22:32] <EvilResistance> oh nevermind
[22:32] <ESphynx> RAOF: it worked till Oneiric ...
[22:32] <EvilResistance> but perhaps a MOTU could discuss with me how this could be improved: https://wiki.ubuntu.com/PackagingGuide/Basic#rules
[22:32] <EvilResistance> erm
[22:33] <RAOF> ESphynx: Well, it can *kinda* work now; you'd need to instruct the user to install libfoo-dev:i386.  That'll work, as long as they don't have libfoo-dev:amd64 installed.
[22:33] <EvilResistance> ermhttps://wiki.ubuntu.com/PackagingGuide/Basic
[22:33] <EvilResistance> BLEH
[22:33] <EvilResistance> https://wiki.ubuntu.com/PackagingGuide/Basic <-- this even
[22:33] <ESphynx> RAOF: ugg!!!
[22:33] <jtaylor> RAOF: aren't many -dev packages coinstallable?
[22:33] <ESphynx> RAOF: but it does 'skipping incompatible' , doesn't it?
[22:33] <ESphynx> RAOF: the linker ignores wrong architecture...
[22:33] <EvilResistance> MOTUs: https://wiki.ubuntu.com/PackagingGuide/Basic <-- doesnt this ignore the 'install' file, which defines "Where to put built files"?
[22:34] <ESphynx> RAOF: really it's only an apt-get being stubborn here that's the problem
[22:34] <jtaylor> ESphynx: you have to pass -m32 of course
[22:34] <RAOF> ESphynx: Right.  But the *correct* architecture is available.  As long as you pass -m32.
[22:34] <ESphynx> i.e. it works in oneiric, with both pacakges installed
[22:34] <ESphynx> jtaylor: I do (always)
[22:35] <ESphynx> RAOF, jtaylor: So should I just try chanigng the ia32-libs dependencies for libbla-dev:i386 ? might that work ?
[22:35] <jtaylor> I don't think that works yet
[22:35] <RAOF> ESphynx: Yes, that will probably work.
[22:35] <micahg> no, that won't work on the buildds
[22:35] <RAOF> Oh, that's right.
[22:35] <jtaylor> or it will ^^
[22:35] <ESphynx> love it ;)
[22:35] <RAOF> You can't have a package dependency on :i386.
[22:36] <RAOF> You can *tell* people to install :i386, but there's no syntax for doing that in debian/control.
[22:36] <ESphynx> But will it work for the user
[22:36] <ESphynx> to do apt-get install with :i386 ?
[22:37] <ESphynx> and I'll just disable the PPA build for amd64 on Precise.
[22:37] <EvilResistance> micahg:  jtaylor:  can i get your input on the packaging guide?
[22:37] <EvilResistance> it appears to be missing things
[22:37] <EvilResistance> (the basic guide)
[22:37] <RAOF> Yes.  It should work for the user (assuming they don't have :amd64 installed)
[22:37] <ESphynx> RAOF: Even if they do, I think? (hope)
[22:37] <Pikkachu> hi, I'm willing to have launchpad compiling and building a plugin I wrote to pidgin onto a PPA, I have created the Makefile based on another plugin, does it look good? http://pastie.org/3521901. I wanted to remove the unnecessary flags tough.
[22:37] <jtaylor> RAOF: most -dev packages should be coinstallable?
[22:38] <jtaylor> I tried it once with one of mine
[22:38] <jtaylor> worked flawlessly
[22:38] <ESphynx> jtaylor yes I would think so.
[22:38] <RAOF> jtaylor: I'm pretty sure it's a policy violation to have -dev coinstallable.
[22:38] <micahg> EvilResistance: install file not needed for basic packaging (i.e. one binary)
[22:38] <jtaylor> really?
[22:38] <jtaylor> I have seen a couple of -dev pacakge declaring MA: same
[22:38]  * ESphynx beats the policy
[22:38] <jtaylor> why would it violate policy?
[22:39] <micahg> well, coinstallable dev packages isn't required by multiarch policy yet
[22:39] <ESphynx> yes, why? :O
[22:39] <ESphynx> I vote it should be _o/
[22:39] <jtaylor> when the checksums match it works fine
[22:39] <ESphynx> thanks for all the help guys. appreciate it.
[22:39] <jtaylor> but I recall the huge discussion on that on d-d
[22:40] <ESphynx> got to run for now ;) cheers.
[22:40] <jtaylor> is there a result of that yet? I haven'T read everything
[22:40] <RAOF> jtaylor: http://wiki.debian.org/Multiarch/Implementation#What_does_the_end_result_look_like.3F
[22:40] <RAOF> Hm, actually, on closer inspection... no.
[22:40] <jtaylor> RAOF: multich same -dev package conform to that
[22:41] <RAOF> That doesn't prohibit multiarch -dev packages.
[22:41] <ESphynx> successful i386 PPA build on Precise =) https://code.launchpad.net/~jerstlouis/+recipe/ecere-daily-multiarch
[22:50]  * Pikkachu brb
[23:05] <tumbleweed> ESphynx: my recommendation was to not bother building on amd64, in the multi-arch world
[23:18] <ESphynx> tumbleweed: right, I think i'll go that way, I was just worried about people 'building' on an amd64 system...
[23:18] <ESphynx> but as RAOF and jtaylor pointed out, they can probably install the :i386 packages
[23:18] <ESphynx> (which unfortunately we cannot do from the package system)