[00:04] 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] but i can't actually find anything in the debian policy manual to back me up on that [00:11] Rcart: ok, just uploaded mpd [00:15] 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] Rcart: that would be different behavior than almost every other postinst script i've seen [00:16] the standard postinst snippet for starting an initscript exits with an error if the start fails [00:18] I see. He said that will fix it (on 5 Jul 2008) and seems like he didn't X: [00:18] should I add a bug watcher linking that (debian) bug report? [00:19] to what? [00:19] the LP bug report [00:19] which bug report? [00:19] (that you mentioned) [00:20] #778571} [00:20] ah. no - the one i mentioned is a different bug from the one described [00:20] Ah, ok [00:21] I'll add a bug watcher to the bug you reviewed [00:21] huh? [00:22] xD [00:22] no, i don't think there's any bug in lp right now that matches the debian bug you linked to [00:22] you should only link bugs if it's the same bug being reported in two places [00:23] the bug I was working on you uploaded it, I'll report it to debian and link it to LP [00:23] ah, yes. that would be excellent :) [00:23] sorry for the confusion [00:23] :D [00:24] Think I need to read carefully the scripts post-pre-etc and try to work on bugs like that [00:34] Thanks for your help broder, I'm leaving. o/ [00:35] Rcart: no problem! thanks for stopping by and contributing! [00:36] (: [01:45] Thanks jtaylor for your help [01:46] hi broder [01:46] akrogames: hey, what's up? [01:47] I live in France and I'm tired and you ? [01:47] I learned to fix bugs [01:57] good night, so later [04:23] 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] 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] !sponsorship| mfisch [05:26] 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:45] tumbleweed: thanks, I'll take a look in the morning [08:12] Changed-By: Ubuntu Merge-o-Matic [08:12] ^ we should have a noisy lintian check for that [08:13] heh [08:33] It is possible to sync a Ubuntu package to Debian? [08:34] vibhav: there's no automated proces for it [08:34] it generally works better to maintain the packgae in Debian and sync to Ubuntu [08:35] I prefer to upload it to Ubuntu first, since I am not experienced in the Debian process [08:36] all the tools (and people) assume that Debian is the upstream [08:36] and I think Debian is a better place to maintain packages (the stronger maintainership makes sense for packages you care about) [08:38] I still can upload it to Ubuntu first? [08:38] nothing stops you from doing that [08:40] tumbleweed: Assuming he has upload privileges or gets a package sponsored [08:40] did something change in apport? There's hardly any information in bug 940800 [08:40] 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:45] tumbleweed: bug 944078 [08:46] Launchpad bug 944078 in apport (Ubuntu) "bugs reported by apport missing essential information" [Undecided,Incomplete] https://launchpad.net/bugs/944078 [08:47] hrm, probably it [10:00] what is the process of fixing these http://qa.ubuntuwire.com/bugs/rcbugs/ [10:00] Is there a document about this? [10:02] I mean I can download the debian source, get the relevant patch etc, then where and how do I submit the result? [10:03] pkt: either request a sync if appropriate or submit a patch for sponsorship either through a bug or bzr branch [10:04] how do I request a sync? [10:04] ok I found, sorry for that question [10:04] 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] http://qa.ubuntuwire.com/bugs/rcbugs/ [10:05] ok, thanks :) [11:31] 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] pkt: if it's only in unstable you'll need -d unstable [11:33] pkt: -d unstable [11:34] thanks :) [11:34] (and sorry for the newbie questions) [11:34] np, that's an issue that only comes up with LTS releases where we sync from testing by default [11:38] this is confusing http://developer.ubuntu.com/packaging/html/packaging-new-software.html [11:39] Pikkachu: what are you finding confusing? let's fix it [11:41] it's entirely confusing, but gtg now [11:45] I think I succeeded (https://bugs.launchpad.net/ubuntu/+source/radare/+bug/946269) [11:45] Launchpad bug 946269 in radare (Ubuntu) "FFe: Sync radare 1:1.5.2-4.1 (universe) from Debian unstable (main)" [Undecided,New] [11:46] Is this correct? [11:46] pkt: that doesn't need an FFe, it's only a bug fix [11:46] uff, I understood wrong then [11:47] should I close the bug? [11:47] if the upstream part (before the dash) of the version hasn't changed, it is unlikely to need the FFe [11:47] It shouldn't need [11:47] it is a trivial bug fix [11:47] no, lets leave it as a sync request, it just doesn't need an FFe [11:47] so, what did I do wrong? [11:47] there, done [11:48] it didn't need -e [11:48] ah, ok :) [11:48] Thanks :) [11:53] So the correct command would have been requestsync -s radare -d unstable [11:53] I will learn slowly slowly :) [11:53] yes [11:54] if you have a recent requestsync (using LP API) you don't need -s either, it'll wor that out itself [11:54] I 'm using latest precise so I guess it is recent enough [11:54] yes [11:55] great, continuing to the next package :) === Quintasan_ is now known as Quintasan [16:43] 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] how would I make a bin deb and how to put this on a recipe? [16:45] first of all instead of cp here/patched other/foo/bar you should have a proper patch [16:45] in the form of a unified diff [16:46] if the package you are patching has source format 3.0 (quilt) then it is very easy to add a patch [16:47] https://wiki.ubuntu.com/PackagingGuide/Complete [16:48] "first of all instead of... " -- you don't really understand what's that [16:49] I will explain what it is [16:49] please do :) [16:49] sorry for calling it patch, it's a new plugin for pidgin called ircaway [16:50] From the process you described it looks as if you want to patch pidgin to include it [16:50] 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] Does pidgin provide a way to build plugins out of tree? [16:52] If it doesn't you need to convince them to add it, or add the source file as a patch [16:52] 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] sure [16:53] but this can't work for packaging I think [16:53] either it needs a way to be built standalone [16:53] please this has nothing to do with patches unless they decided to add the plugin to upstream [16:53] from the pidgin docs, the plugin author would provide the way the plugin needs to be built [16:54] fair enough [16:54] but I'm reading the docs themselves for that [16:54] but pidgin should provide a way to build plugins against it [16:54] which don't explain how to build them alone [16:54] i.e., libraries etc [16:55] are there any pidgin plugins distributed as standalone packages? [16:55] I suppose because it's a plugin it somehow would require most or much of the original infrastructure to build pidgin itself [16:55] https://wiki.ubuntu.com/PackagingGuide/Complete -- is totally confusing [16:56] sorry I mean the new guide [16:56] I just know of purple plugin pack, a set of plugins, distributed as a separate package [16:59] apt-cache search pidgin shows a few extra packages [16:59] you can check if any of them are small enough to be used as examples [17:00] Pikkachu: does libpurple-dev or pidgin [17:00] -dev have wha tyou need? [17:01] I would propose pidgin-extprefs [17:01] it is also a single .c file from what it seems [17:01] so maybe you can reuse its build infrastructure [17:01] tumbleweed: does what? [17:02] He asks if it provides the needed libraries etc [17:02] but I think the problem is to figure out the build system [17:02] pkt: sorry I'm not in Ubuntu right now, but does extprefs stand itself as a pidgin plugin? [17:02] yes it seems so [17:03] pkt: yeah it's a problem -dev x build-dep [17:03] first of all I don't get why can't one put the build deps as deps of the -dev packages [17:04] anyway, libpurple-dev and pidgin-dev contain just headers iirc [17:04] and build-dep for pidgin is really big [17:04] Pikkachu: again, I think you can try extprefs plugin as a template to build from [17:04] pkt: ok will try to take a look at extprefs [17:05] if you are not on ubuntu you can get the source package from the web [17:05] It has some extra stuff for installing on win32 and such, you can just ditch those [17:06] and just copy the linux-related infrastructure [17:09] ok [17:10] great :) [17:10] Pikkachu: if it's a single c file, it can't be that hard to build, right? [17:10] not true [17:11] a kernel module is also a single file [17:11] s/is/can be/ [17:11] and they are fairly straight forward to build [17:11] not without the kernel's build infrastructure [17:11] yeah [17:11] you can't just call gcc on it by hand and expect a working module [17:12] Pikkachu's issue is that he is trying to figure out the corresponding build system for pidgin plugins [17:12] I just don't get why build-dep is not reversible like normal deps with autoremove [17:12] I'm saying that that may be more effort than it's worth [17:13] Pikkachu: use mk-build-deps, then they are easy to remove [17:13] I think you don't really understand the problem, tumbleweed [17:13] I have no idea how would I "use mk-build-deps" [17:14] Pikkachu: of course I don't, I haven't seen the source[6~ [17:14] it has a manpage [17:14] but basically, mk-build-deps -ir inside an extracted source package [17:14] are you trying to sound cool? it's not working [17:15] Pikkachu: I'm trying to be helpful [17:15] Pikkachu: yes [17:15] and you don't appear to want help, so I'm not entirely sure why I'm bothering [17:15] I think there is a misunderstanding [17:15] tumbleweed's advice is useful [17:15] of course, those standard responses, please I disregard your help, right now, ignore me PLEASE [17:16] Pikkachu: mk-build-deps solves the problem of being able to unistall the stuff apt-get build-dep brought in [17:16] 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] tumbleweed: sorry I stopped at 'sorry'. I'm not really interested in your help, sorry [17:17] np [17:18] pkt: well but it will just output the package names, which is mostly the same as saving build-dep's output :( [17:18] Pikkachu: not just that [17:18] it will also make a binary package that depends on them [17:19] so you can install this package to install the build-deps [17:19] and then remove it and they will become removable through autoremove [17:19] of course I don't know how useful this is now (if you have already installed them by build-dep) [17:20] but for future reference [17:21] 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] It is the same number of commands [17:22] I.e., instead of "apt-get build-dep " you do "mk-build-deps -ir" [17:22] and this way the build deps are instantly autoremovable [17:22] I didn't know about this script myself to be honest, I had hacked my own solution for this problem :P === Pikkachu is now known as Pikkachu^Away === yofel_ is now known as yofel [17:53] hi all [17:56] 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] debdiffs are fine. Nobody requires you to use bzr [17:57] however, why does i tnot have any branches in LP? [17:58] tumbleweed: because, I think, until now it was just, uh, pure debian, no ubuntu changes [17:58] mfisch: no, it should still have branches [17:58] what package is it? [17:58] let me confirm that assumption [17:58] okay nevermind :( [17:58] :) [17:58] I just wasn't looking in the right place [18:00] still the information that bazaar is not really needed is useful [18:01] I still find it easier to not use bzr, but bzr is certainly becoming more appealing [18:01] I prefer bzr myself [18:02] As someone who has only done a small amount of packaging I found modifying a package with bzr very straightforward. [18:04] when I do the merge proposal don't i need to add ubuntu-sponsors as a reviewed? [18:04] reviewer i mean [18:04] orrect [18:04] err, you don't need to [18:04] mind if i add that to the wiki? [18:04] hmm ok [18:05] tumbleweed: how will it end up in sponsor queue? [18:06] the sponsorship queue includes all merge proposals against ubuntu pcakages [18:06] alright, I'll see if this shows in the queue in a bit [18:07] 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] 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] tumbleweed: thanks for the ifno, I attached a debdiff and did a merge-prop [18:09] 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] mfisch: so it'll show up twice :) [18:09] tumbleweed: you the man. [18:10] ESphynx: can you pastebin the error? [18:10] 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] tumbleweed: the errors won't really help you, it's my compiler doing really silly stuff that it normally doesn't [18:11] ESphynx: do you have a hardware problem or something? [18:11] The only thing I can't think up is a messed up GCC [18:11] ESphynx: you sure your hard drive isn't going? check dmesg... [18:11] or zero free disk space? [18:11] tumbleweed: eh, should I nuke my merge proposal then? [18:11] pkt: no hardware problem, this is on Launchpad PPA building machines as well [18:11] tumbleweed: not sure if I can remove the attachment from the bug [18:11] pkt: no, dynamic vdi drives with plenty of space [18:11] mfisch: I can unsubscribe sponsors from the bug [18:11] tumbleweed: bug #831392 [18:11] 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:12] 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] my bug-day contrib, 48 hours late ;) [18:12] mfisch: thanks [18:12] tumbleweed: It is virtual machines, and PPA building machines! no HW issue. [18:12] I was suspecting a bug in the Ubuntu GCC 4.6.2 patches. [18:12] mfisch: is it 48-hours late? hehe I thought the Jam was during the weekend as well [18:13] pkt: oh well I'm good then! [18:13] I still haven't finished my contribution :S [18:13] pkt: you're running out of time there in Greece! [18:13] ESphynx: the ppa build failed for a very clear reason [18:14] tumbleweed: Which reason is that? [18:14] mfisch: true, just a few hours more :P [18:14] error: unresolved identifier publicAccess; expected ecere::com::Module [18:14] but can't I say that my personal clock is in pacific timezone :P [18:14] tumbleweed: that is not supposed to happen. [18:15] tumbleweed: also consider "warning: incompatible expression "ecere::sys::FileAttribs FileExists(char * fileName)" (byte *); expected pe" [18:15] there's no such thing as "pe" anywhere in our software... [18:15] the compiler (the bootstrap eC compiler) is all messed up [18:16] none of this happen on any other Ubuntu versions... [18:16] tumbleweed: how often is the sponsor queue updated? hourly or so? [18:17] My Precise VM is dead :| will have to reinstall everything... So much for trying to build my own GCC 4.6.2 :| [18:17] 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] ESphynx: sorry, I thought you were saying tha tthe build had killed your VM [18:17] tumbleweed: building GCC killed my VM. [18:18] ESphynx: how much RAM did you give to your VM? [18:18] ah the hw errors, is what you were talkign about :) hehe, on a Windows host though [18:18] pkt: 2gb [18:18] sorry I thought you guys were blaming the failed build on hw hehe [18:18] And still it died [18:18] hehe [18:18] yes :( [18:18] Interesting [18:19] you guys have other flavors of Gcc installed on Precise? [18:19] we could give that a try? [18:19] I have a VM here with precise (kvm) [18:19] if you want I can install a version of gcc [18:19] pkt: I would greatly appreciate taht. [18:20] But know that I can't build gcc on this VM [18:20] it has just 256MB ram [18:20] pkt: I gave up on building GCC :P [18:20] pkt: but I couldn't figure out out to try 4.6.1, for example, without building it [18:20] if you do know how ;) [18:20] I can try to find out [18:20] just a sec [18:20] ESphynx: w still have a gcc-3.5 package in precise [18:20] err 4.5 [18:21] i decided to try building 4.6.2 , since it built our software fine on Windows [18:21] tumbleweed: ah yes... I guess we could try that. but that's quite far from 4.6.2 :| [18:21] but it would help narrow down the problem [18:21] I see 4.6.3 as default here [18:21] yeah [18:21] 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] And I would like to build on Precise, at least when it comes out :) [18:22] 4.4, 4.5, 4.6 are all available [18:22] pkt: 4.6.3 now ? is it a newer VM? [18:22] which one do you want? [18:22] It has latest precise on it [18:22] pkt: maybe i'm out of date hehe... [18:22] pkt: care to try 4.6.3 first ? [18:22] sure why not [18:23] guess i'll link you to the source package? [18:23] but if lp failed probably it was with 4.6.3 [18:23] sure [18:23] do you have it on a ppa? [18:23] yes [18:23] https://code.launchpad.net/~jerstlouis/+recipe/ecere-daily-multiarch [18:24] gcc-4.6 i386 4.6.3-1ubuntu2 [7576 kB] [18:24] right, lp failed on 4.6.3 as well :( [18:25] so the easy thing would be to try 4.4 ? to establish whether GCC is to blame or not? [18:25] since 4.5 is dev right, so latest dev might have the bug as well? [18:25] I think 4.5 should be release as well, not dev [18:26] ah right osrry [18:26] it's the middle number [18:26] hmm. [18:26] my only worry... when installing side by side... our build system just invokes 'gcc' [18:27] I think gcc is selected using alternatives [18:27] so you can try 4.5 [18:27] please =) [18:28] sure but you will need to wait a few mins [18:28] np [18:30] I gues another thing to try would be to disable -O2 ... [18:30] that you can also try yourself [18:30] guess I could try that on a new Precise machine [18:30] yes. i'll brb, logging out to kill stalled VBox === Pikkachu^Away is now known as Pikkachu [18:33] 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] Pikkachu: fwiw I didn't understand what you meant [18:40] Pikkachu: There are lots of pidgin plugins in ubuntu, have you had a look at how they accomplish the build? [18:40] what was the problem with pidgin-extprefs? [18:46] Ampelbein: and this is what you call "a lot"? http://i.imgur.com/Q5hAT.png [18:46] Hi all! [18:46] Pikkachu: try from the command-line [18:46] there are several [18:46] apt-cache search pidgin [18:46] That .vdi was so locked down, even "Restart" wouldn't work... i had to press the Reset button :| [18:47] Pikkachu: but still what was the problem with extprefs, I chose it for you because it is also a single .c file [18:48] pkt: I have no idea whether its Build-Depepndencies field matches? [18:48] pkt: can we start from the beginning? [18:48] sure [18:49] for starters, where is ircaway.c ? [18:49] Pikkachu: I count 24 plugins, that is a lot. [18:49] 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] nice :) [18:50] so now I can try taking out -O2 :P [18:50] Ampelbein: ignore me from now on, and I'm serious [18:50] hi ESphynx, how's eC going :) [18:50] pkt: well, I will stand it in a simple way then [18:51] sure, simple always helps [18:52] 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] can you give the link to that branch? [18:54] 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] Pikkachu: sure, but this won't help you produce a package [18:55] pkt: https://code.launchpad.net/~renatosilva/pidgin/ircaway [18:55] Pikkachu: great [18:56] 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] it is not just overkill [18:56] it is also not going to be accepted [18:57] so, you need to figure out how to build it standalone [18:57] this doesn't just mean the debian/ part [18:57] it also means the makefile etc [18:58] In fact, the first thing you need to figure out is what to put to the makefile [18:58] 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] do I really need a makefile? because I think that even that is overkill, no? [18:59] no [18:59] why not, just to understand [18:59] Because you need to ensure you are building against the proper headers / libraries [19:00] you could also write a bash script but a Makefile is the standard way to do it (TM) [19:00] so at the very minimum you need the .c file and a Makefile [19:01] and most likely a README [19:01] once you have those, you can also make the debian/ folder with the right contents [19:03] +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] 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] tumbleweed: I'm looking right now, will take a look at their makefile [19:11] Pikkachu: typically you use pkg-config [19:11] Pikkachu: here is my suggestion [19:11] go to the extprefs plugin [19:11] do the mk-build-deps -ir thing [19:12] and now do a debuild -uc -us 2>&1 | tee -a ../build.log [19:12] this will show you which commands the makefile of this plugin called [19:12] it is much easier than trying to analyse its source [19:12] because the source is obfuscated a lot by the automake infrastructure that you don't need [19:13] I'm trying to process what you said [19:13] btw, I hope this advice is ok and not considered as spamming the channel [19:14] sure, nothing else going on right now. (weekends are quiet) [19:14] Pikkachu: no tee reqd, debuild writes a log to ../$pkg.build [19:14] even better [19:15] err pkt [19:15] I'm really annoyed by all this word salad I've been through in the docs, I'm really lost [19:16] :O why have I been using tee all the time?! [19:16] I'm looking in pidgin-facebookchat now [19:16] This is why trying to help on IRC is helpful [19:16] most time you learn new stuff yourself [19:17] Pikkachu: sure, pick the simplest you can find [19:18] 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] facebookchat looks much more complicated [19:19] 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] devscripts is certainly something you want. Any sane packaging documentation should have told you that pretty early on [19:19] I'd also recommend ubuntu-dev-tools [19:22] 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] Pikkachu: the thing is that you need to know the basics of open source development before you start caring about packaging [19:23] 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] pkt: I don't like these standard unclear responses, please [19:24] pkt: any sane developer would hate the whole toolset, to begin with [19:24] I 'm trying to make it specific (searching for a link to a howto) [19:25] Pikkachu: please don't insult our build systems, that doesn't motivate people to help you [19:25] I've read the docs pkt, they're confusing [19:25]