=== nhandler_ is now known as nhandler [02:07] pbuilder is giving me some wonky output [02:07] throwing a bunch of 404's for old library debs, which aren't in the archive anymore [02:07] do i need to clear some cache files or something? [02:08] i'm all apt-get updated ... [02:09] How does dpkg handle upgrading a package that has a configuration file with new defaults, when the user hasn't changed the defaults? Does it stay at the old defaults? [02:09] kirkland: Is your pbuilder chroot all apt-get updated? [02:10] SoftwareExplorer: It replaces it if the checksum of the installed conffile matches the stored checksum of the conffile installed by the last version of the package, and asks the user for guidance if the checksum doesn't match. [02:10] persia: i thought it was, let me check again [02:11] persia: Ok, thanks! [02:11] kirkland: I usually only encounter that when there's skew between the apt-cache in my chroot and my other apt-caches (since I have about 20 different apt-caches this happens frequently) [02:11] persia: doh, i fatfinger that step in my script; sorry for the noise [02:11] hello, I just disable dh_auto_test, what should i do? I just have "dh_auto_test:" with nothing to do, but it doesn't work :( [02:11] just want [02:12] kirkland: No worries. Took me about 20 tries to get it right, and now I keep it on p.u.c/~persia so I never have to reimplement :) [02:13] rawang: If you have that, dh_auto_test is disabled. Are you sure something else isn't running the test suite? [02:13] persia, yes, [02:13] I just want to know, how to disable dh_auto_test :) [02:13] is it 'override_dh_auto_test'? :) [02:14] persia, and nothing under that "override" ? :) [02:14] rawang: Oh, right. Sorry, not thinking. Yes, it's override_dh_auto_test: with no actions. [02:14] persia, alright, got it, thanks a lot! :) [02:21] What happens when a user changes a normal (non-configuration) file and the package is updated? [02:21] The file gets overwritten silently. [02:22] RAOF: Thanks. [03:50] I'm trying to fix a package that is Section: multiverse/metapackages, although debian/control tells it to go into the graphics section instead. Is there somewhere else that section is set in packaging? [03:51] whats the package name? [03:51] mythtv-themes [03:52] it is in multiverse, but the graphics is the category in Synaptics I guess [03:52] right, but I need to remove it from multiverse/metapackages, as it causes issues when being removed from ubuntu software center [03:53] basic multiverse would be fine I guess, just out of metapackages [03:53] specifically for bug 529740 [03:53] Launchpad bug 529740 in myththemes "mythtv-themes metapackage needs to be != metapackages section" [Medium,Triaged] https://launchpad.net/bugs/529740 [03:56] tgm4883: pastebin debian/control ? [03:56] ah, the expert's here :) [03:56] persia, ok sec [03:57] persia, also, there is a debian/control.in, do you need that too? [03:57] persia, http://pastebin.com/qEHHs2Zg [03:58] Doesn't matter. I just didn't want to hunt on LP or download the package :) [03:58] persia, heh [03:59] I guess I could have linked you to the bzr source too [03:59] tgm4883: As easily :) Anyway, that's a bug in the archive overrides file, not in the package, based on that debian/control. [03:59] It's clearly "Section: graphics". by preference. [03:59] yep [03:59] I don't know how to fix that: you likely need an archive admin. [03:59] archive overrides file? [03:59] ah ok [04:00] so it's not something in the packaging then? [04:00] The archive management tools have a way to override incorrect section stuff, set components, etc. [04:00] Doesn't look like it to me, but confirm with an archive admin. [04:00] ok, so do I need to open a bug somewhere for that or should I ping someone? [04:00] hi, when building a python packages, all packaged which was in 'site-packages' goes to 'dist-packages', and some of them goes to 'pyshared' directory, what is the standard way? [04:01] tgm4883: Check wiki.u.c/ArchiveAdministration, find the archive admin of the day, and ask them how to proceed in #ubuntu-devel [04:01] tgm4883: This might end up as a bug, or a package change, or just the request on IRC may be enough. [04:01] persia, ok will do, thanks [04:03] persia, hi, :) [04:03] * persia ignores contentless pings [04:03] persia, , when building a python packages, all packaged which was in 'site-packages' goes to 'dist-packages', and some of them goes to 'pyshared' directory, what is the standard way? [04:04] rawang, http://www.debian.org/doc/packaging-manuals/python-policy/ [04:04] * persia is also the wrong person to ask about python packaging [04:04] porthose, great, that's very useful, thanks :) [04:04] rawang: Always ask your questions generally, unless you *know* one person has special knowledge. There's lots of folk here, and most are happy to help. [04:04] persia, alright, thanks all the same :) [04:04] :) [04:05] sure [04:05] is there something I should do if deletion requests dont get ack'd? [04:06] nigelb: Wait. Complain here if we reach BetaFreeze [04:06] * nigelb goes to check dates [04:07] ah, well 9 days more, thats plenty of time [04:12] what's the difference between the math.h in libc6-dev and the one in libstdc++6-4.4-dev [04:12] micahg: diff may tell you more, but I suspect it's different language bindings. [04:19] persia: to use one of the other is based on the rules file? [04:21] micahg: based on the whether it uses gcc or g++ perhaps? [04:21] (I'm guessing) [04:23] micahg: I'm guessing it's based on the include directives in the source. I'd expect both of those packages to be installed from build-essential. [04:36] guys. i don't think making nvidia-current a build-dep for mplayer is a good idea. it breaks libgl on systems with intel graphics. [04:38] The following NEW packages will be installed: [04:38] dkms libavcodec-dev libavdevice-dev libavdevice52 libavformat-dev [04:38] libavutil-dev libcdparanoia-dev libdts-dev libfaac-dev libfribidi-dev [04:38] libgif-dev liblircclient-dev liblivemedia-dev liblzo2-2 liblzo2-dev [04:38] libmp3lame-dev libopenal-dev libopenal1 libpostproc-dev libsmbclient-dev [04:38] libswscale-dev libvorbisidec-dev libvorbisidec1 libx264-dev libxvidcore-dev [04:38] LLStarks: I disagree. I suggest instead that the issue lies in ending up with compiled bits that don't work on arbitrary graphics cards. [04:38] libxvmc-dev libxxf86dga-dev libxxf86vm-dev nvidia-185-libvdpau-dev [04:38] nvidia-current nvidia-current-dev nvidia-settings vstream-client-dev [04:38] !paste [04:38] x11proto-xf86dga-dev x11proto-xf86vidmode-dev [04:38] For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. [04:38] my bad. [04:38] LLStarks: So the way to fix it is to fiddle debian/rules to not break things, rather than exclude the build-dep. [04:38] file a bug? [04:40] Depends on your level of skill and/or motivation, really. Either fix it or file a bug, yes. [04:42] this is what happens: http://img94.imageshack.us/img94/7263/ohgodo.png [04:42] it's imperative that this is fixed. [04:43] https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/530481 [04:43] Launchpad bug 530481 in mplayer "nvidia-current build-dep breaks libgl if hardware isn't nvidia" [Undecided,New] [04:44] LLStarks: It's hard for me to find the specific mplayer error in that screenshot. [04:50] that looks more like a screenshot from the upside down chrome extension to me [04:50] but surely a build-dep won't affect usage of the app [04:51] but also it shouldn't build-dep on nvidia-current-dev, but instead libvdpau-dev probably [05:12] porthose, hello, I just read the debian python policy, but seems like there are two ways to pack python package, python-support and python-central, which way is mostly used for debian package? [05:13] rawang, I would suggest dh7 with python-support [05:14] rawang: They are both commonly used. The last answer I got was "If you're uploading to Ubuntu directly, use python-centtral, and if you're uploading to Debian use python-support". [05:14] rawang: They will both go away soonish, being replaced by the renewed dh_python (for some definition of soonish) [05:14] porthose, what does this mean? I've already use debhelper >=7.0.50 [05:15] persia, ah, i see, i guess that's what porthose wants to say :) [05:16] superm1. persia. doing a "sudo apt-get build-dep mplayer" will cause this once everything is installed and compiz is activated. [05:17] that's why this is a pants-****ting bug. [05:17] LLStarks: OK. You filed the bug? [05:17] https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/530481 [05:17] Launchpad bug 530481 in mplayer "nvidia-current build-dep breaks libgl if hardware isn't nvidia" [Undecided,New] [05:17] LLStarks: Are you planning to work on it? [05:17] i'm not a coder [05:17] why would i? [05:17] nor can i package. [05:18] bjsnider, siretart, ^ it's just a matter of needing libvdpau-dev support instead of nvidia-libvdpau-dev [05:19] LLStarks: OK. If you're not working on it, you'll want to either wait until someone else wants to work on it, or encourage them to do so. Complaining to people generally causes them to want to remove themselves from the situation in which they receive complaints. [05:20] even my most detailed bug reports aren't acted on for at least 2 months unless i bring them up on mailing lists or irc. [05:21] i apologize for my lack of proper protocol though. [05:21] is it just a matter of changing deps? [05:21] Yeah :/ We don't have enough folk fixing stuff. That's part of why I hoped you'd want to work on that one. [05:22] If its just changing dep and repacking, I could probably help :) [05:22] nigelb: Needs some thought as to which are the right deps, and then testing on a variety of hardware, so mostly build-deps, but maybe some changes in debian/rules [05:22] okay, not my cup of tea then [05:24] nigelb: You can try. There is a suggestion in backscroll as to which might be the right build-dep. [05:24] LLStarks: would probably be happy to help with testing. [05:24] I'm sure other testers could be found in #ubuntu-bugs, etc. [05:24] so, I change to libvdpau-dev instead of nvidia-libvdpau-dev, build, and upload to PPA for testing? [05:25] libvdpau-dev is the correct build-dep now. that's the same change that was made for ffmpeg, mythtv, etc [05:25] i guess so. if it's only a matter of purging the proper packages and then doing a build-dep command. [05:25] superm1: shall I change and propose a debdiff then? [05:25] sure [05:26] I dunno what needs to be done in the rules file if anything needs to be done [05:26] debian/control [05:28] The only reason for debian/rules changes would be if the build system needs a hint about the other changes (in terms of --enable --disable, etc.) [05:32] LLStarks: where did you see nvidia-libvdpau-dev as a build depends? [05:32] (I can't find it) [05:33] nevermind, got it [05:33] nvidia-185-libvdpau-dev nvidia-current nvidia-current-dev [05:34] I can only find 'nvidia-185-libvdpau-dev' listed in debian/control [05:34] where are you seeing the others? [05:36] LLStarks: what page/file are you seeing the build deps? [05:36] ? [05:36] i don't understand. [05:37] where are you checking for build dependencies? [05:38] apt-get build-dep [05:38] ah [05:38] so now worries, its just the nvidia package depending on the others I guess [05:46] should i amend the bug report to reflect other packages? [05:47] nope [05:47] its only the ''nvidia-185-libvdpau-dev' package [05:48] Almost fixed, i'm test building now. [06:23] mplayer is a hell of a package to build ;) [06:23] !ohmy [06:23] Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others. [06:23] I guess it will take a good 30 mins [06:23] (and yes, it is :) ) [06:24] woops, sorry :( [06:25] is it because of the graphics libs that it depends on that it takes so much time? [06:26] Well, also because of all the various optimised flavours and assembly. [06:26] ah :) [06:29] okay, something went wrong in the build [06:30] any idea whats going wrong? http://paste.ubuntu.com/386786/ [06:32] nigel_nb: That's not really enough of the log to tell, but I'd guess that nobody defined vs_info_x264.opts [06:33] that was where the problem happened. You want me to paste the whole log (where do I get it anyway) [06:33] how do I fix this issue? [06:33] You want to go look at the source in the place where the failure happened, and see if you can figure out why things aren't initialised. [06:34] Also, compare the libraries you were using to the libraries you are now using. [06:34] You need to identify what is different between the two builds. From there, you'll be in a strong position to fix it. [06:35] between the 2 builds? [06:35] you mean the old dep and the new dep? [06:35] and the build seems to show a huge number of warnings [06:37] Right. Between building with the old build-dep and the new one. [06:37] I didn't try building with the old one. [06:37] lemme try now [06:38] nigel_nb: There's a build log on LP from the old way. [06:38] nigel_nb: It might be a bit different, but may save you a bit of time. [06:38] yes, it definitely wil [06:40] I can't find the 've_info_x264.opts' file in the source [06:40] i.e., a grep returns blank [06:40] even grep -rin . ? [06:40] And it may not be a file. [06:41] I did a grep -R 've_info_vfw.opts' * [06:42] That usually works. [06:43] I tend to use -rin because sometimes things end up strangely capitalised, and I want line numbers in my report. [06:43] well, -R and -rin returned nothing [06:43] Now, it's possible that this comes from a generated file. [06:43] but I tend to think, thats not the trouble [06:43] did you try a grep in a failed-build tree? [06:43] because that warning is there in the old build logs too [06:43] Aha! [06:44] So, go find something else :) [06:46] something related to make. Who's the subject matter expert? [06:47] its the "make[1]: *** [libmpcodecs/ve_x264.o] Error 1" that is giving me trouble [06:49] That usually means that it couldn't make that file. [06:49] So, you need to look up and try to figure out how it tries to make that file. [06:49] how? [06:51] Yes, how. [06:51] So the Makefile provides instructions on how to make files. [06:51] (or targets, but usually targets are files) [06:51] So you look in your partial build tree to find the makefile that tries to make libmpcodecs/ve_x264.o [06:52] and you try running the command to create that file manually. [06:52] That should narrow down the issue. [06:52] I see "SRCS_MENCODER-$(X264) += libmpcodecs/ve_x264.c" in makefile [06:53] OK. That just adds that value to that variable. [06:53] Now go find how that variable is used. [06:54] I can see a few references in the configure.in file [06:54] nothing I can decipher [06:55] OK. Where did you find the first line you found? [06:56] the first few defines the options that can be passed [06:56] later on, each of the option is correctly defined with code, that uses this variable [06:56] RIght. So you're looking for a rule to make the variable. [06:56] Or you're looking for some rule that makes files based on a transformation of this variable (e.g. .c -> .o) [06:58] dont see that [07:31] where in the partial build tree would I find the make file usually? [07:33] I would think configure generates them for you, there should be Makefile.in files before that. [07:34] I'm running into some build troubles [07:34] me and persia were trying to figure how to fix it. but I'm still lost [07:37] ugh! where do I find the build log now? [07:37] Im so lost when pbuilder gives me troubles [07:38] pbuilder puts them into /var/cache/pbuilder/result if you used the --pkgname-logfile switch. [07:38] persia, hello there. [07:39] I only see the final .debs there of the successful packages [07:39] persia, I found look at the dh_python manpage, and it says the dh_python is deprecated, but you said dh_python will be used for new package, which one is correct? :) [07:39] Then you probably haven't used that switch. [07:40] oh [07:40] so, without that switch the logs wont be generated? [07:40] which means i have to compile again - ugh! [07:40] rawang: Well, you should settle for either dh_pysupport or dh_pycentral from what I understand . o O ( haven't packaged any python modules yet, though ) [07:40] rawang: Both. The revivified dh_python is still being assembled, and the electrodes have not yet been attached. The switch will likely be thrown in the next few months. [07:41] nigel_nb: No, you only will see the messages on your screen without any logfile. [07:41] rawang: So if you want to do something now, use python_support or python_central. [07:41] good morning [07:41] persia, is it okay if you use dh_python only? [07:42] this a paste of the trouble I ran into earlier, if its too short, I'll run it by again with the log file switch http://paste.ubuntu.com/386786/ [07:42] and good morning dholbach [07:42] persia, i mean if 'I' only use dh_python :) [07:42] hi nigel_nb [07:42] Rhonda, thanks :) [07:42] rawang: Yes, but you may have to wait many months before you can upload, and there currently exist no documents on how to use it correctly (please read this response as a carefully couched "No") [07:44] ok, and another question, when i use dh_pycentral, what's the target? I found a examle "binary-install/python-pyatspi::" why there are two colons? is that a typo? [07:44] rawang: No worries. :) [07:44] :) [07:48] persia: "So you look in your partial build tree to find the makefile that tries to make libmpcodecs/ve_x264.o" - means inside the pbuilder/build/1234/ folder? [07:51] nigel_nb: I'd probably use something like pbuilder --login (I really use schroot -c) and try a local build there with debuild -b -nc to get the partial build tree. [07:51] nigel_nb: Someone who actually uses pbuilder may be able to suggest other strategies. [07:52] I got a hook to get me in the chroot when something goes wrong [07:52] so now I'm in the chroot [07:53] Excellent. If you're in the chroot, that's the place to be looking. [07:53] all of it will be in /tmp of the chroot I suppose? [07:54] persia, So when i use dh_pycentral, what's the target? I found a examle which has "binary-install/python-pyatspi::" why there are two colons? is that a typo? or it's intented? could you please review my rules file? http://pastebin.org/99827 thank you so much [07:54] okay, the grep has returned 3 matches which might be significant [07:54] rawang: I'm the wrong person to ask. [07:55] persia, sorry, :) [07:55] rawang: I have worked with one (1) python package in any depth, and last touched it in gusty because I couldn't make it work. [07:55] Like I said earlier, please ask questions generally. [07:55] yeah [07:55] hi [07:56] so hello everybody, if the target has two colons like "binary-install/python-pyatspi::" is that a typo? [07:57] Usually it's just CDBS, unless it's special in some way. [07:57] I think I found that ve.o file that we were looking for earlier [07:57] my package iok(indic onscreen keyboard) was accepted for lucid, can i add this in the previous stable releases of ubuntu? [07:57] suji11: no [07:58] nigel_nb: ok [07:59] suji11: You need to request a backport, and it only goes into -backports [07:59] https://help.ubuntu.com/community/UbuntuBackports [07:59] I finally did find the 've_info_x264' variable, but how do I figure out what is going wrong? [08:00] persia: ok, i go through that. [08:02] nigel_nb: You need to figure out which command is used to create the file that isn't being created. [08:03] oh no. [08:04] the 've_x264.o' is called only in 1 file and its not a create command [08:05] nigel_nb: Paste the makefile that contains 've_x264.o' [08:05] its not a make file. I can't find a make file [08:07] I'm looking at '/tmp/buildd/mplayer-1.0~rc3+svn20090426' inside the chroot and this seems to be the result after building [08:07] where in the chroot do i see the make file? [08:07] Is there no Makefile? [08:08] Previously you identified a bit of code you found which was in make syntax. [08:08] that was directly in the code, not in chroot [08:08] I didn't read what you asked me to do [08:08] now, i'm inside the chroot [08:09] nigel_nb: You don't have the code in the chroot? [08:10] I'm looking. [08:10] ah, I see the same code I saw earlier 'SRCS_MENCODER-$(X264) += libmpcodecs/ve_x264.c' [08:13] OK. And that's in a makefile? [08:13] yup [08:14] OK. Do you read make? [08:15] nothing more than that line in the make file [08:15] It's a one-line makefile? [08:16] its a huge makefile [08:16] Excellent! [08:16] 1125 lines [08:16] So, You know that libmpcodecs/ve_x264.c is being added to SRCS_MENCODER-$(X264) [08:16] This might help here. its a grep result [08:16] http://paste.ubuntu.com/386828/ [08:17] Next, find where something happens to SRCS_MENCODER-$(X264) [08:17] now, you have an idea of where to ask me to look. (since i'm thoroughly lost [08:17] SRCS_MENCODER-$(X264) is only referenced in the make file [08:18] nigel_nb: Well, here's an interesting line: [08:18] libmpcodecs/ve_x264.d:1:libmpcodecs/ve_x264.d libmpcodecs/ve_x264.o: libmpcodecs/ve_x264.c config.h mp_msg.h [08:18] thats the line you were looking for? 0_0 [08:18] To me, that looks like a rule definition to create libmpcodecs/ve_x264.o which is the file that filed. [08:19] s/filed/failed [08:19] So, under that line there should be some commands that explain how the file is created. [08:19] And if you're still in the interrupted build, you could run them one-by-one to find out which fails. [08:19] And once you know which is failing, you can probably debug back to the larger change. [08:20] here you go http://paste.ubuntu.com/386829/ [08:20] oh, how do I do it one by one? [08:22] That's just the rule definition (\ indicates not to really break the line) [08:22] What do you have after that, before the next rule? [08:22] thats the entire file [08:23] I thought you said the file has 1125 lines. [08:24] that was the make file [08:24] OK. What was the file from which you generated http://paste.ubuntu.com/386829/ [08:24] oh, you want the next line of make file, ah [08:24] No, I don't. [08:24] libmpcodecs/ve_x264.d [08:24] the one that the grep revealed [08:25] I want you to read the next section of the make file, and identify what is done to create libmpcodecs/ve_x264.o based on that rule. [08:25] I'll help if you get stuck, but remember that the goal is to solve the issue, not to give me information. [08:25] okay, now I get it :) [08:25] (otherwise I'd have downloaded the source and be looking it it myself) [08:25] :) [08:26] I'm learning but I'm hungry, tired, and fatigued. that might contribute to me giving you the info [08:26] Take a break. [08:27] I've ordered lunch, when it comes I will [08:27] I'd like you to spend 86400 seconds a day fixing bugs, but I'm certain that if you spend 21600 seconds well rested and well-fed, you'll get more done. [08:27] this line is a declaration right "SRCS_MENCODER-$(FAAC)" ? [08:28] persia: I will from tomorrow, my work timings change :) [08:28] nigel_nb: That's just a variable. It might be a declaration or a use. [08:28] so, now, I have to figure out the line in the make file, that executes all these ? [08:28] what is the variable name there? [08:29] is it SRCS_MENCODER or is it X264? [08:29] It depends. [08:29] The value varies based on the expansion of the referenced variable. [08:29] because I feel strange reminders of Cpp, like object.variable [08:29] so probably "OBJS_MENCODER += $(addsuffix .o, $(basename $(SRCS_MENCODER)))" has some significance? [08:30] Oh, most likely :) [08:31] nigel_nb: If you haven't before, you might want to read the Make manual. [08:31] It's fairly well written, and will help you understand this. [08:31] thats a good idea, I haven't. reading now [08:31] It will also help with debian/rules files. [08:31] or scar you for life. [08:31] Probably help you. [08:31] That too, but I don't usually advertise that feature :) [08:32] I know one person ended up writing lisp. [08:32] in GNU Make [08:32] That's brilliant! [08:36] persia: I absolutely cannot make any sense of this mess. I give up :( [08:36] see, scarred for life [08:36] lifeless: not the make help [08:36] I'm talking about the makefile [08:37] nigel_nb: I was finishing the sub-thread with persia [08:37] nigel_nb: Read the manual. Have lunch. Come back later. I'll walk you through it. [08:37] lifeless: ah, apologies [08:37] that does sound better than staring at a terminal. [08:40] persia: Just realized. I've been awake for 22 hours now. [08:41] nigel_nb: Then set it aside, have lunch, finish your day, and get your schedule adjusted. [08:41] That is, unless you think better on little sleep. [08:41] nope. I'm more determined to finish this and sleep or I'll not get a peaceful sleep [08:42] OK. Come back after lunch then, but do take a break and at least skim over the manual, especially about variables and built-in functions. [08:43] what are you talking about variables? I dont see it here [08:44] http://www.gnu.org/software/make/manual/make.html#Using-Variables [08:44] * persia meant the full manual, not just the output of `man make` [08:45] I'll go through it after lunch. [09:25] persia: I'm back after lunch and brief run down through the manual :) [09:26] Excellent. [09:26] now, I can make sense of the make file :) [09:26] (at least parts of it) [09:26] Even better :) [09:26] So, can you determine which commands are *supposed* to generate the failed .o file? [09:27] is it MENCODER_DEPS = $(OBJS_MENCODER) $(OBJS_COMMON) $(COMMON_LIBS) [09:32] that seems to be the one line all the += ends in :) [09:32] No. [09:33] So, basically makefiles consist of a set of targets. [09:33] yes [09:33] You can set variables and do conditional things, and define functions, and all sorts of fun and games, but generally it's all about the rules. [09:34] hm [09:34] There exists a rule to build libmpcodecs/ve_x264.o [09:35] huh? [09:35] And that's the file that didn't get generated, right? [09:35] yes [09:35] huh? at what? [09:35] There exists a rule to build libmpcodecs/ve_x264.o [09:35] So a rule is defined as a line starting fully left-justified that contains a colon. [09:36] So the rule to build libmpcodecs/ve_x264.o is at http://paste.ubuntu.com/386829/ [09:36] Or at least that's the rule declaration. [09:36] yes [09:37] They syntax of makefiles, conditionals and variables and the like aside consists of target declarations followed by sequences of shell commands required to generate the target [09:38] (or at least do something related to the target: it doesn't always result in an output file, although it usually does : read about .PHONY and .SECONDARY and similar in the make manual for more info) [09:38] So, since you have found the target declaration, you can find the sequence associated with that target. [09:38] yes [09:39] By executing each command in the sequence in order, you can replicate the behaviour make would take to create the target. [09:39] And if there is an issue, you can debug the issue with the specific command that is causing the issue, rather than dealing with the huge build system. [09:40] which is what you've been urging me to do [09:41] Yes :) [09:41] and I've been stuck figuring out how it is supposed to be done + what is the exact line [09:41] But I realise that there may be a gap between what I request and what is understood, so please ask lots of questions along the way. [09:42] OK. Are you still stuck? [09:42] I think I figured out the line which does the actually making [09:43] this is what I have understood, all the rules go to one variable. [09:43] which is then converted to an object [09:43] and then equated to a buld_dep variable [09:43] I think our semantics are different. [09:43] Because that doesn't make any sense to me [09:44] its probably because you understand the code and I dont, at least not well [09:44]