| 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:04 |
| broder | Rcart: ok, just uploaded mpd | 00:11 |
| 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:15 |
| 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:16 |
| 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:18 |
| broder | to what? | 00:19 |
| Rcart | the LP bug report | 00:19 |
| broder | which bug report? | 00:19 |
| Rcart | (that you mentioned) | 00:19 |
| 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:20 |
| Rcart | I'll add a bug watcher to the bug you reviewed | 00:21 |
| broder | huh? | 00:21 |
| 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:22 |
| 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:23 |
| Rcart | Think I need to read carefully the scripts post-pre-etc and try to work on bugs like that | 00:24 |
| Rcart | Thanks for your help broder, I'm leaving. o/ | 00:34 |
| broder | Rcart: no problem! thanks for stopping by and contributing! | 00:35 |
| Rcart | (: | 00:36 |
| akrogames | Thanks jtaylor for your help | 01:45 |
| akrogames | hi broder | 01:46 |
| broder | akrogames: hey, what's up? | 01:46 |
| akrogames | I live in France and I'm tired and you ? | 01:47 |
| akrogames | I learned to fix bugs | 01:47 |
| akrogames | good night, so later | 01:57 |
| 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:23 |
| 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 | 04:42 |
| tumbleweed | !sponsorship| mfisch | 05:26 |
| ubottu | mfisch: You can find out about the package sponsorship process here http://wiki.ubuntu.com/SponsorshipProcess - For !UDS sponsorship see http://uds.ubuntu.com/participate/sponsorship/ | 05:26 |
| mfisch | tumbleweed: thanks, I'll take a look in the morning | 05:45 |
| tumbleweed | Changed-By: Ubuntu Merge-o-Matic <mom@ubuntu.com> | 08:12 |
| tumbleweed | ^ we should have a noisy lintian check for that | 08:12 |
| micahg | heh | 08:13 |
| vibhav | It is possible to sync a Ubuntu package to Debian? | 08:33 |
| 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:34 |
| vibhav | I prefer to upload it to Ubuntu first, since I am not experienced in the Debian process | 08:35 |
| 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:36 |
| vibhav | I still can upload it to Ubuntu first? | 08:38 |
| tumbleweed | nothing stops you from doing that | 08:38 |
| 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:40 |
| ubottu | Launchpad bug 940800 in python-wadllib (Ubuntu) "pyclean crashed with Exception in from_package(): cannot get content of python-wadllib" [Undecided,New] https://launchpad.net/bugs/940800 | 08:40 |
| Ampelbein | tumbleweed: bug 944078 | 08:45 |
| ubottu | Launchpad bug 944078 in apport (Ubuntu) "bugs reported by apport missing essential information" [Undecided,Incomplete] https://launchpad.net/bugs/944078 | 08:46 |
| tumbleweed | hrm, probably it | 08:47 |
| pkt | what is the process of fixing these http://qa.ubuntuwire.com/bugs/rcbugs/ | 10:00 |
| pkt | Is there a document about this? | 10:00 |
| pkt | I mean I can download the debian source, get the relevant patch etc, then where and how do I submit the result? | 10:02 |
| micahg | pkt: either request a sync if appropriate or submit a patch for sponsorship either through a bug or bzr branch | 10:03 |
| 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:04 |
| pkt | ok, thanks :) | 10:05 |
| 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:31 |
| micahg | pkt: if it's only in unstable you'll need -d unstable | 11:33 |
| tumbleweed | pkt: -d unstable | 11:33 |
| 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:34 |
| Pikkachu | this is confusing http://developer.ubuntu.com/packaging/html/packaging-new-software.html | 11:38 |
| tumbleweed | Pikkachu: what are you finding confusing? let's fix it | 11:39 |
| Pikkachu | it's entirely confusing, but gtg now | 11:41 |
| pkt | I think I succeeded (https://bugs.launchpad.net/ubuntu/+source/radare/+bug/946269) | 11:45 |
| ubottu | Launchpad bug 946269 in radare (Ubuntu) "FFe: Sync radare 1:1.5.2-4.1 (universe) from Debian unstable (main)" [Undecided,New] | 11:45 |
| 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:46 |
| 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:47 |
| tumbleweed | it didn't need -e | 11:48 |
| pkt | ah, ok :) | 11:48 |
| pkt | Thanks :) | 11:48 |
| 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:53 |
| 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:54 |
| pkt | great, continuing to the next package :) | 11:55 |
| === Quintasan_ is now known as Quintasan | ||
| 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:43 |
| Pikkachu | how would I make a bin deb and how to put this on a recipe? | 16:44 |
| 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:45 |
| pkt | if the package you are patching has source format 3.0 (quilt) then it is very easy to add a patch | 16:46 |
| pkt | https://wiki.ubuntu.com/PackagingGuide/Complete | 16:47 |
| Pikkachu | "first of all instead of... " -- you don't really understand what's that | 16:48 |
| 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:49 |
| 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:50 |
| pkt | Does pidgin provide a way to build plugins out of tree? | 16:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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 | 16:59 |
| tumbleweed | Pikkachu: does libpurple-dev or pidgin | 17:00 |
| tumbleweed | -dev have wha tyou need? | 17:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| pkt | and just copy the linux-related infrastructure | 17:06 |
| Pikkachu | ok | 17:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| Pikkachu | tumbleweed: sorry I stopped at 'sorry'. I'm not really interested in your help, sorry | 17:17 |
| tumbleweed | np | 17:17 |
| 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:18 |
| 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:19 |
| pkt | but for future reference | 17:20 |
| 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:21 |
| 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:22 |
| === Pikkachu is now known as Pikkachu^Away | ||
| === yofel_ is now known as yofel | ||
| akrogames | hi all | 17:53 |
| 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:56 |
| tumbleweed | debdiffs are fine. Nobody requires you to use bzr | 17:57 |
| tumbleweed | however, why does i tnot have any branches in LP? | 17:57 |
| 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 | 17:58 |
| pkt | still the information that bazaar is not really needed is useful | 18:00 |
| 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:01 |
| ral | As someone who has only done a small amount of packaging I found modifying a package with bzr very straightforward. | 18:02 |
| 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:04 |
| mfisch | tumbleweed: how will it end up in sponsor queue? | 18:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| ubottu | Launchpad bug 831392 in live-manual (Ubuntu Oneiric) "live-manual version 1:3.0~a6-1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/831392 | 18:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| ESphynx | gcc-4.6 i386 4.6.3-1ubuntu2 [7576 kB] | 18:24 |
| ESphynx | right, lp failed on 4.6.3 as well :( | 18:24 |
| 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:25 |
| 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:26 |
| pkt | I think gcc is selected using alternatives | 18:27 |
| ESphynx | so you can try 4.5 | 18:27 |
| ESphynx | please =) | 18:27 |
| pkt | sure but you will need to wait a few mins | 18:28 |
| ESphynx | np | 18:28 |
| 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:30 |
| === Pikkachu^Away is now known as Pikkachu | ||
| Pikkachu | hi pkt, not much help http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/pidgin-extprefs/oneiric/view/head:/debian/control | 18:33 |
| * Pikkachu rebooting to ubuntu | 18:34 | |
| 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:40 |
| 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:46 |
| pkt | Pikkachu: but still what was the problem with extprefs, I chose it for you because it is also a single .c file | 18:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| pkt | sure, simple always helps | 18:51 |
| 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:52 |
| pkt | can you give the link to that branch? | 18:53 |
| 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:54 |
| Pikkachu | pkt: https://code.launchpad.net/~renatosilva/pidgin/ircaway | 18:55 |
| pkt | Pikkachu: great | 18:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 18:59 |
| 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:00 |
| 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:01 |
| 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:03 |
| 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:09 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| pkt | Pikkachu: sure, pick the simplest you can find | 19:17 |
| 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:18 |
| 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:19 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| === JackyAlcine_ is now known as jalcine | ||
| Pikkachu | ESphynx: glad to know you got your way on PPas | 19:35 |
| ESphynx | Pikkachu: almost there, hehehe | 19:36 |
| ESphynx | Pikkachu: just Precise failing to build :( | 19:36 |
| === jalcine is now known as JackyAlcine_ | ||
| === JackyAlcine_ is now known as jalcine | ||
| ESphynx | pkt: well, taking out -O2 doesn't seem to help!! | 19:39 |
| === jalcine is now known as JackyAlcine_ | ||
| === JackyAlcine_ is now known as jalcine | ||
| Pikkachu | pkt: the makefile from that plugin is 137 lines long, should I read it and amke mine based on that? | 19:42 |
| ESphynx | Would anyone know how different the Ubuntu patches for GCC are, and how likely they are to cause memory corruption issues? :| | 19:43 |
| pkt | The short answer is that nothing is impossible with gcc ... | 19:44 |
| ESphynx | hehehe | 19:44 |
| 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:45 |
| ESphynx | jtaylor: My compiled bootstrap eC compiler is going nuts. | 19:46 |
| ESphynx | jtaylor: it works fine on oneiric and all previous Ubuntus. | 19:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| ESphynx | ok guys. What is wrong with bash's tab completion??? | 19:58 |
| pkt | works here | 19:58 |
| 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? | 19:59 |
| 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:04 |
| ESphynx | hehe k, thanks! | 20:05 |
| ESphynx | sorry, I had a space where I shouldn't have. works now | 20:06 |
| 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:07 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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 |
| === jalcine is now known as JackyAlcine_ | ||
| ESphynx | and it works fine in Valgrind! | 20:12 |
| pkt | I only mention because this problem also only showed in gcc 4.6 | 20:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| tumbleweed | well, at least yo uare half way there | 20:17 |
| pkt | I hope more than half hehe | 20:18 |
| pkt | But this could probably be characterised a "hydra bug" | 20:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| jtaylor | yes | 20:24 |
| jtaylor | LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libc/memcpy-preload.so /path/to/binary | 20:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| jtaylor | why do you do that copy in the first place? | 20:33 |
| ESphynx | jtaylor: i use it e.g. for left trimming purposes | 20:34 |
| ESphynx | strcpy(string, string + x) , where x sometimes is 0 | 20:34 |
| 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:35 |
| 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:36 |
| ESphynx | thanks guys. since I only have 3 spots should be easy to try it out | 20:38 |
| jtaylor | did the wrapper work? | 20:38 |
| 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:39 |
| ESphynx | hmm x86 here, not 64 bit | 20:40 |
| jtaylor | hm the change is only in amd64 | 20:40 |
| ESphynx | yeah I don't seem to have this memcpy-preload.so | 20:41 |
| ESphynx | nor a /i386-linux-gnu/libc directory :| | 20:43 |
| === almaisan-away is now known as al-maisan | ||
| === JackyAlcine is now known as jalcine | ||
| === al-maisan is now known as almaisan-away | ||
| pkt | Hmm, ok now the package builds, so the problem becomes how to push the fixes | 21:18 |
| pkt | It isn't just a sync request anymore since there is an extra patch | 21:19 |
| pkt | And I think maybe it would be good to push to debian as well | 21:20 |
| micahg | pkt: is this for radare? | 21:24 |
| pkt | yes micahg | 21:24 |
| jtaylor | can I see the diff? | 21:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| pkt | http://pastebin.ubuntu.com/868973/ | 21:30 |
| jtaylor | you didn't fix the as needed issue? | 21:30 |
| pkt | no | 21:30 |
| 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:31 |
| 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:32 |
| pkt | I see | 21:33 |
| pkt | I can look at it | 21:33 |
| pkt | unless the package is to be dropped of course | 21:33 |
| jtaylor | I don't really now the difference between the two | 21:34 |
| ESphynx | Alt-F "Search" shortcut ? how can I disable that? :| | 21:36 |
| ESphynx | ah no, it's just 'alt / released' :| how annoying!! | 21:38 |
| ESphynx | the hud :| disabled that... | 21:51 |
| ESphynx | E: Package 'ia32-libs-multiarch' has no installation candidate --> where should I ask about this? | 21:51 |
| * Pikkachu tired | 21:52 | |
| ESphynx | when tired, sleep :) | 21:52 |
| ESphynx | "This may mean that the package is missing, has been obsoleted, or is only available from another source" | 21:53 |
| 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:56 |
| ESphynx | tumbleweed: you remember this amd64 issue I had? =) | 21:58 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| JanC | what I mean is: don't use the ia32-* stuff anymore ;) | 22:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| ESphynx | Pikkachu: What's your pidgin plugin do? | 22:25 |
| RAOF | ESphynx: Oh! That's very simple - don't build an amd64 package :) | 22:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| * Pikkachu brb | 22:31 | |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| * Pikkachu brb | 22:50 | |
| tumbleweed | ESphynx: my recommendation was to not bother building on amd64, in the multi-arch world | 23:05 |
| 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) | 23:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
