[00:00] Is someone from the Ubuntu Development Team available that can triage a bug? [00:01] https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/574106 [00:01] Launchpad bug 574106 in gparted "Request backport of gparted 0.5.2-9 (Important UPDATE - LVM fix)" [Undecided,New] [00:01] lvm fix? gparted does not support lvm [00:02] There's a regression in gparted, if there's an active LVM on a device, you can't edit or delete any partitions on that device [00:03] There was a new release on May 3, 2010 to fix this [00:06] have you tested this? we should not be affected by this since we don't care WHAT is using the other partitions... there was a regression in libparted that prevented manipulating other partitions on a disk with one in use, but that was fixed [00:08] yea... looks like their bug report cites the two relevant patches to libparted I wrote... we're ahead of gparted ;) [00:08] I installed gparted from ubuntu lucid repos, I am unable to edit a boot partition that is not part of the lvm [00:08] can you be more specific? [00:09] i'm not sure how, I right lick on the boot partition and I'm unable to resize [00:10] do you get an error? [00:10] what version of libparted0 do you have installed? [00:10] the option resize/move is greyed out [00:11] 2.2-5ubuntu5 [00:14] hrm... works for me... [00:14] are you sure the partition you are trying to resize is not in use? [00:16] lifeless: hi, around for a few minutes [00:17] [00:17] james_w: hi [00:17] james_w: what would you say is the most useful thing to do next in the bzr/distro workflow space [00:17] not a promise to do :- want your thoughts as input to deciding :) [00:18] hmm [00:18] perhaps a bit late for strategic thinking :-) [00:18] tactical will do :) [00:18] I've suggested to spiv he might like to do a loom converter for bzr-builddeb imported branches [00:19] yeah, looms would be pretty high [00:19] as something useful, and giving him more exposure to the content that the distro is working with [00:19] merging unrelated branches would be highest on my list right now I think [00:19] do you mean file id related stuff? [00:20] or rather, getting upstreams mergeable to distro branches, at least as one-offs [00:20] actually, what do you mean :P [00:20] so something in that area, either requiring a rewrite of the distro branch, or more smarts in bzr to make that unnecessary [00:20] ok [00:20] so the use case is [00:21] 'I have a bzr-builddeb import-dsc branch, or similar. I now have an upstream branch. Help.' [00:21] yes [00:22] and right now I'm just interested in answering that specific question, rather than "we have 10000 import-dsc branches, and 2000 upstream branches. Help!!!" [00:22] sure [00:22] I think its a rewrite case [00:22] 'path tokens', as I called them, will carry baggage around for some time [00:22] partly because it's would be a precursor, but also to stop punishing the projects who use bzr upstream and in the distro [00:23] james_w: they can just drop the distro history, though its not a brilliant answer [00:23] right [00:24] so it's just something along the lines of putting some of the code in bzr-rewrite together with some heuristics and producing a command that can be run of a bunch of branches. [00:24] yeah, a non-rewrite solution could be to merge -r 0..-1 the upstream branch next time a merge-upstream is done, and take all the file-ids from the upstream branch [00:24] so you get a discontinuity, but that becomes less important over time [00:25] how does this sound [00:25] as a 'break the dam' approach [00:25] we write a little script [00:25] that checks for changes to stuff outside debian/ [00:26] stashes that somewhere; does a join of the branches, grabs the upstream content and restores that diff [00:26] and does this all as one commit [00:26] no conflicts [00:27] sounds reasonable, but I'm not sure how much more work the rewrite case would be [00:27] Much more, I think. [00:28] bzr-rewrite is awkward to work with. [00:28] I don't want to get into making that awesome *and then* get folk the ability to connect branches [00:28] I'd rather get the ability to connect these branches, *and then* make it better. [00:30] the specifically harder thing about rewrite is we don't know where to do repeated merges [00:31] and in general the content won't match for autoconf output etc, repeatedly throughout time [00:31] james_w: while you're here. I'd like to stop the builddeb importer stripping .bzrignore [00:31] james_w: I filed a bug, but I don't think you've given your opinion on that [00:32] I thought it had been done, but I might be misremembering [00:32] it's a trivial patch [00:32] yes, but are you happy with it being done :) [00:34] dunnio [00:34] you can force me to think about it :-) [00:34] * lifeless forces [00:34] james_w: why the change to say 'bzr merge . -r tag:upstream-1.2.3' in your merge of my patch ? [00:34] in my experience it causes trouble, and I can't think of any good reasons to do it [00:35] explicit is better than implicit [00:36] I did the .bzrignore stripping because I was stripping .bzr, and so just went all out. I since scaled back to only stripping some bzr related stuff, and I think we can leave it with just stripping .bzr, even with the known problems with doing that [00:36] what are the problems? [00:36] I mean, I can describe the problems the stripping gives me concisely: it breaks merging from upstream [00:37] psusi: bzr branch of the grapher: http://bradmisik.com/trunk/fragraph [00:38] lifeless: yeah, I meant the problems with stripping .bzr, we can't import .bzr, but if we strip it then there are other issues [00:38] such as not being able to recreate the source package that we imported properly [00:38] james_w: we could import .bzr, but it would be mind bending :) [00:38] well, you can't import .bzr right now [00:38] temugen, thanks... checking it out now [00:39] try telling TreeTransform to create a .bzr/branch-format some time, it's quite spectacular [00:39] james_w: I'll describe how you can over a beer. Needs a custom format object. [00:39] and possibly some monkey aptches [00:39] right, that's what I mean by "right now2 [00:39] anyhow, distractions aside [00:39] if there's nothing else then I'll be heading to bed [00:40] .bzrignore should be ok ? [00:40] yep [00:40] I'll push a patch for it. [00:40] gnight. [00:41] thanks [00:41] night [01:03] Just a reminder, it's Patch Day. Anyone with some time to review patches and help get them in the right places is encouraged to stop by #ubuntu-reviews and help out. [01:54] pitti: btw, as a note kde4.mk has been dropped from cdbs in Ubuntu, and can be dropped from the merge differences list for all future merges [02:01] Hmm. If I submit a deb for review to include in universe...if I have to do export DISTDIR=$(CURDIR)/debian/iscsitarget;$(MAKE) install in debian/rules under install: , would that have any effect on it being accepted? Everything else "just works" [02:02] I just dont want to go through the effort of filling in all the copyright info and making sure everything looks clean and then be denied cuz of that [02:02] I dont see anything in the guides that say you CANT do it [02:02] I wrote the devels of iscsitarget, they wont be changing it [02:02] their makefile doesnt support DESTDIR, only DISTDIR [02:03] df00z1: #ubuntu-motu is a better channel for that question. [02:03] Ok I'll check them out, thanks [02:04] I'd probably define that further up in debian/rules rather than as an environment variable when calling Make, but there's no reason you can't do that. Packaging exists to work around variances in upstream build procedures. [02:07] jdong: Any chance you can look at the pending clamav SRU and give it SRU team blessing? [02:08] ScottK: sure, bug #? [02:09] well that's interesting.... while defragging I noticed a bug in resize2fs... it doesn't respect flex_bg... all of the block groups I added last week when I extended the volume are laid out in their non flex_bg positions [02:10] jdong: Bug #574906 and Bug #571543 [02:10] Launchpad bug 574906 in clamav "Clamav 0.96.0 clamd fails to start on powerpc" [High,In progress] https://launchpad.net/bugs/574906 [02:10] Launchpad bug 571543 in clamav "Milter and Freshclam configurations buggy in Lucid" [High,In progress] https://launchpad.net/bugs/571543 [02:12] ScottK: ACKed [02:12] jdong: Thanks. [02:13] * ScottK switches hats. [02:13] ScottK: just a FYI, it's the last two weeks of class here (last week before things are due), so life is really hellish for me here. If there's outstanding SRU tasks, feel free to ping me in here and I'll look. but I'm probably not gonna read my bugmail for now [02:13] jdong: Will do. Thanks again. [02:14] jdong: You might want to look at http://launchpadlibrarian.net/47809319/xubuntu-default-settings_10.04.8_source.changes [02:16] ScottK: thanks [02:16] ScottK: looks like Martin ACKed it already [02:16] OK. I'll process it then. [02:24] Done. === dendrobates is now known as dendro-afk [02:34] Does KDE get windicators too? [02:36] txwikinger: You tell me: http://blog.martin-graesslin.com/blog/2010/05/why-you-should-not-use-client-side-window-decorations/ [02:37] There doesn't seem to be anything stoping KDE from getting windicators; it sounds like it'll be a similar sort of interface to the app-indicators. [02:37] RAOF: I thought client side decoration was required? [02:39] ScottK: I don't have any deep insight into the implementation or even how much implementation there *is*. There doesn't seem to be any particular reason that it couldn't be implemented in a way that kwin could do the actual indicators. [02:39] If KDE didn't want to do client-side-decoration. [02:39] It would be. Naking it work sanely would require an extension to the WM interface, which isn't what was described. [02:40] That's kind of what I'd have thought, but it'd be very different than what has been proposed. [02:40] why can't the decorator accept plugins? [02:40] txwikinger: It could, but nobody ever defined that an an extension of the WM interface, to my knowledge. [02:41] well.. I see no obstacle to start with it [02:41] So, unless it's CSD, that would require changing all the window managers, or requiring application implementaitons to have a fallback. If the target is a few specific applications, it's much easier to implement with CSD. [02:42] Well. you only need a fallback if it is additional functionality [02:42] There's no obstacle: mostly needs thinking about *how* to pass *what* to enable that sort of thing in a generic fashion. [02:42] if it is just a convenience thing the fallback could be like it is now [02:42] persia: I was under the impression it'd be pretty much like the dbusmenu work that already drives appindicators [02:43] well. I would think all of the window managers in question are composite managers [02:43] I mayhave read the blog post wrong, but I had the impression it would be a replacement for the status bar. [02:43] you're both right [02:43] raof is talking implementation [02:43] RAOF: Yes, but there's nothing in the WM spec to receive that yet :) [02:43] persia is talking user experience, AFAICT [02:43] persia: it wouldn't be WM per se - it would be client side [02:43] user experience and spec compliance, but yeah. [02:43] composite means the decorator would just assign the space and the windicator would plug itself in there [02:44] lifeless: Only if it's CSD. [02:44] right, AIUI that was prereq [02:44] It's not. [02:44] I don't see why it would be predicated on CSD. KWin would just need to grow an appropriate dbus interface. [02:44] There's no reason the WM spec can't get extended to support that sort of functionality. it's just a heap more work to do it that way. [02:45] what is CSD? [02:45] RAOF: You're thinking about specifics. We have > 10 WMs in Ubuntu. [02:45] And users of crazy window decorators get to see the magical fallback paths :) [02:45] txwikinger: Client Side Decorations. [02:45] persia: And I think we should *care* about 3 WMs, give or take. [02:45] At least as far as this work goes. [02:45] 4 [02:46] There will always be crazy WMs that do funky things; we'll need fallbacks regardless. [02:46] RAOF: I'd say 4, but yeah, if done as a WM extension in kwin/metacity/openbox/(whatever the GTK compositing one is) it ought be sufficient. [02:47] txwikinger: Does your 4 match my 4? [02:47] CSD windows could get it for free, which makes it easier. [02:47] Right, which is why it's overwhelmingly likely that a CSD implementation will be sought. [02:48] persia.. I think so.. I thought KDE/Gnome/Xfce and L... [02:48] * txwikinger still likes a plugin solution [02:48] But that CSD implementation shouldn't prejudice the ability of other decorators implementing it. [02:49] txwikinger: Then the same. KDE is kwin, GNOME is compiz, Xfce is metacity, and LXDE is openbox. [02:49] well. kde can run compiz too isn't it [02:49] RAOF: It's pretty clear that CSD means KDE won't support it. [02:49] txwikinger: It can, but it's not supported by Kubuntu or upstream. [02:50] what is the WM for Kubuntu with compiz enabled? [02:50] ScottK: I don't understand; it wouldn't require CSD, but GTK apps would get it for free with CSD. And if Qt implemented CSD, then Qt apps could get it for free, too. [02:51] There's no work planned for a non-CSD implementation. [02:51] (at least as far as I've seen) [02:51] txwikinger: I believe the lack of a good answer to that question is *why* it's not a supported configuration :) [02:52] persia: Why would it be? [02:52] well. whatever the desktop effects are [02:52] txwikinger: In KDE, that's kwin. [02:52] ScottK: was that always kwin? [02:52] That would require KWin patches; it's quite possible that the initial implementation wound be only done for GTK+CSD, because that has the highest reward. [02:53] txwikinger: For KDE4, yes. [02:53] The WM for Kubuntu with compiz enabled is compiz. That's easy :) [02:53] * txwikinger must have remebered KDE3 then [02:53] RAOF: No. It's worse than that. At least one senior kwin dev has essentially said CSD over my dead body, so I don't think it's ever likely to be in KDE. [02:54] So even if patches were done for kwin, they'd have no place to land. [02:54] ScottK: But the patches wouldn't be for CSD in KWin, they'd be for kwin to provide the appropriate interfaces (dbus or otherwise) [02:54] why do people always say something like that? [02:55] KWin would still be drawing the decorations, but it'd be additionally drawing a bunch of indicators. [02:55] txwikinger: Did you read the blog post. [02:55] In that decoration. [02:55] ScottK: yes [02:55] RAOF: So then what happens when you run a KDE app in a Gnome session or the reverse? [02:56] RAOF: You really want to extend the WM interface to allow that, rather than just implement some random D-Bus interface. If it's not in XDG, folks are likely to drag their feet for all sorts of reasons. [02:56] Well, a CSD GNOME app in a KDE session will have gnome-themed titlebars, since it won't be decorated by KWin. This means it'll get the GTK indicator stuff. [02:57] No, because KWin will override the decorations, based on the blog post. [02:57] Yep [02:57] Because KWin doesn't respect the “don't decorate me” hint? [02:57] That seems rather unfriendly. [02:58] It seems to some how since my chromium windows don't look like kwin. [02:58] Right. The CSD GTK apps *should* behave exactly like that. [02:59] I understand that KWin wants to have the ability for the user to force decorations on, but not respecting the undecorated hint entirely would break chromium and other things like it. [02:59] Which does mean they won't fit in at all with the desktop environment. [02:59] GTK apps in Kubuntu look reasonably native currently. [02:59] RAOF: I think it currently respects the hint, but that upstream is unhappy about that. [03:00] * txwikinger does not understand the either/or [03:00] Making them remain reasonably native would be a matter of appropriate engine coding. [03:01] why can't the windicators just be plugins that still allow Kwin to do what it does today [03:01] txwikinger: Plugins to what? [03:01] txwikinger: They could. It's just lots more work that way. [03:02] maybe I don't understand WMs good enough [03:02] txwikinger: The advantage of doing it in GTK with CSD is that you only need to implement it once in GTK and it works with all moderately sane WMs automatically. [03:03] but I would think in the sense of plasmoids [03:03] txwikinger: The main thing to consider is that there exists a current definition of the WM interface, implemented by N WMs (of which we care about 4). If that is to be extended, it needs to be extended in *all* of them. [03:03] and it needs to be extended in a way that is acceptable to the WM development community generally. [03:03] Or at least have agreement on how to implement it even if the implementations appear somewhat asynchronously. [03:03] Using CSD sidesteps the entire conversation, and the cost of inconsistent interface. [03:03] persia: I think that extension would be reasonable [03:04] txwikinger: I agree, but it needs doing, and it's a bundle of work. [03:05] Which no one appears to be proposing be done. [03:06] (at least not in the community of candidates to do the work) [03:07] I'm not sure it's fair to say that yet: let's wait until post-UDS when we've all had a chance to argue about it in detail. [03:08] Is there anyone coming to have this discussion and not just the how we're going to do CSD one? [03:08] I doubt this is on the agenda. [03:09] Ah, good point. There may be insufficient representation from the WM development community to have the discussion. [03:11] I've seen the list if KDEish people coming. No kwin developers on the list. [03:13] I don't remember metacity folks ever being present, nor openbox. I've seen compiz folks regularly, but that's only one of the 4 that we care about (nevermind all the others) [03:22] OTOH, last cycle we didn't have any upstream plasma developers there and Ayatana worked out the dbusmenu concept with them and we had a session with them remote and Kubuntu/Ayatana people local. [03:27] So really it's just a matter of coordination with the appropriate folks. Could be possible to arrange. [03:35] * psusi beats resize2fs for not respecting flex_bg when extending a volume [03:36] lifeless: Dunno if you7re still interested, but http://blino.org/blog/mandriva/poulsbo-xserver1.7.html caught my eye. [03:37] lifeless: You're another unfortunate with a gma500 system? [03:37] RAOF: You have one? [03:38] persia: No, but there are some in #ubuntu-x and Sarvatt's working on it. [03:38] RAOF: lynnes eeepc is [03:39] * persia sends blessings Sarvatt's way [03:39] RAOF: thats why I updated the kernel modules for the IEGD 10.3.1 release or whatever; before finding that the X driver is a different API to lucid and X refuses to use it [03:39] s/API/ABI/ [03:40] lifeless: Well, last I saw there was mutterings and cursings and I think X might have been coming up with acceleration. [03:40] pitti, the broken real time clock fsck issues... could they not be fixed by setting the clock to the fs creation time when mounting the root fs? that way the current time is never < fs creation time? [03:41] RAOF: cool; xorg-edgers ? :) [03:41] lifeless: A different PPA, I think. Let me browse the logs… [03:42] RAOF: don't bother [03:42] I can't fiddle for 2 weeks anyway [03:42] psusi: So, what happens when your filesystem creation time is corrupt? We've a hack in some places that sets it to last mount action time (mount/unmount), but that's not really safe. [03:42] lifeless: Too late: https://edge.launchpad.net/~sarvatt/+archive/psb/+packages [03:42] :) [03:43] persia, none of it is safe, it's a question of the lesser of evils ;) [03:43] Not those 3 letters! [03:43] Nooooooooooooooooo [03:43] but if you KNOW your real time clock is not functioning, setting the current time to the fs creation time is better than the epoc [03:43] StevenK: p [03:43] StevenK: s [03:43] StevenK: b [03:44] Lalalalalala, I can't hear you [03:44] StevenK: don't worry, in 5 days you will [03:44] lifeless: I no longer have to care [03:44] StevenK: I know. But you'll still hear ;) [03:46] psusi: Right before lucid release, ogra committed some patch by dmart that did just that, but unfortunately I forget the bug number. My understanding is that the issue has been communicated to filesystem devs upsteam, and should be fixed in a future upstream release (in that there will be a safe way to deal with nonfunctional RTC/missing RTC) [04:04] RAOF: So, bug #497149 is in the patch review queue (it's Patch Day! everyone should review patches in #ubuntu-reviews) for nouveau-kernel-source : do you need someone to go through a review process for that, or is it something you can just do relatively quickly? [04:04] Launchpad bug 497149 in nvidia-graphics-drivers-96 "Packages using DKMS should make use of /usr/lib/dkms/common.postinst" [Low,Fix released] https://launchpad.net/bugs/497149 [04:06] RAOF: there's another group of people working on it that actually have the machines and care so I disabled that PPA and will just help them out :) [04:09] * Sarvatt can't believe he's actually trying to find a psb machine to buy.. [04:09] Sarvatt: Might you come to UDS? I've one that just gathers dust. [04:09] (it's actually a "cell phone", but it's larger than one of my "laptop"s, so I never use it) [04:11] yep I'll be there, that would help a lot if I could mess with it there since I keep needing info I can only get from a running machine [04:12] Sure. I'll bring it along. [04:13] Might still have a not-quite-jaunty on it, with arbitrary hacks, but presumably it could be upgraded, etc. [04:20] ogra: Do you want to do anything with https://bugs.launchpad.net/ubuntu/+source/xf86-input-evtouch/+bug/317094 ? It's aging, but has a bundle of stuff there. [04:20] Launchpad bug 317094 in xf86-input-evtouch "meta bug to collect lshal touchscreen info" [Undecided,Incomplete] [04:21] ogra: More specifically, do *you* want to do something, or should all the patches be pushed upstream somehow? [04:21] though the bug doesn't have actual patches, but just dumps from a tool [04:22] Ah, right. I guess it needs someone to dig thorugh the dumps, and generate a patch. [04:22] Sorry for the noise. [04:28] the lovely part is that there's a psb replacement destined to end up in netbooks here soon that also uses powervr and is incompatible with all of the current psb stuff === rgreening_ is now known as rgreening [04:30] Sarvatt: Really? :(. I got the impression that psb was almost universally disliked, even within Intel. [04:31] yeah moorestown, there's a ton of support patches for it in meego [04:31] I think the idea of using embedded graphics cores is not universally disliked. [04:37] I love embedded graphics cores... that are open [04:39] Which ones are those again? [04:49] persia: The arrandale(?) cores in the i{3,5,7}, I think. [04:54] * persia gets confused by ark: arrandale seems ot be a product cycle name, and the details of the GPU aren't obvious. I hope this to be true. [04:55] http://en.wikipedia.org/wiki/Intel_Core_i7 gives some hint [04:58] anandtech even had a feature article. It just didn't list which was the old IP (or else I'm missing the hints). [04:58] Anyway, I don't want to care enough about it :) I'll just hope they have open specifications. === almaisan-away is now known as al-maisan [06:54] Good morning [06:54] JontheEchidna: ah, that was actually just a copy&paste error from the changelog; it's not actually installed any more; thanks! [07:27] zul: can you please reupload landscape-client with the correct -v option to show both changelogs, or merge the changelogs? [08:02] morning [08:08] good morning [08:10] hey zyga [08:10] hey seb128, dholbach [08:11] mvo: hello, how are you :-) [08:11] hey mvo [08:11] zyga: good, thanks, how are you? [08:11] mvo: fine, I'm trying to find the right google domain for my project, so many of them around ;-) [08:12] hey mvo, salut seb128 [08:12] hey dholbach [08:12] comment ça va? [08:13] dholbach, un peu fatigué mais sinon bien, et toi ? [08:14] seb128: un peu fatigué aussi [08:15] hallo dholbach! [08:16] seb128: doko va arriver ici dans quelque minutes, son internet est encore "cassé" :) [08:16] dholbach, c'est un prétexte pour pas travailler ! [08:17] "ah ah" :) [08:17] becaucoup de travaille ici, pas travailler n'est pas une option :) [08:22] dholbach, ;-) === Amto_AFK is now known as Amto_res [08:36] hmm test building wine in sbuild with ccache seems to lead to nothing but ccache missees [08:36] what gives? [08:37] hyperair: maybe it inserts build date/time into all objects? [08:37] zyga: ah yes that might be the cause [08:37] hyperair: or it gets around to avoid ccache in some magic way [08:37] hyperair: but it would be queer to put timestamp into _all_ objects [08:37] no wait, ccache is defunct [08:38] zyga: ccache is defunct, that's definite. [08:38] sbuild will be building in a clean chroot, right? That's unlikely to pick up your ccache cache :) [08:38] hyperair: how so? I've used it with great success in the past [08:38] zyga: same here. [08:38] RAOF: sbuild bind-mounts my home [08:38] RAOF: oh, good point [08:39] RAOF: and builds under my UID [08:39] watch ccache -s shows the misses going up [08:39] zyga: i just tried with a helloworld.cc test [08:39] hyperair: did you try checking that hello-world.c is cached correctly/ [08:39] :D [08:40] zyga: heh? [08:41] lemme just run a ccache cleanup [08:42] hyperair: one more possibility is to check the ccache log [08:42] hyperair: I know that ccache just bails out if it sees some option it does not understand [08:42] zyga: eh interesting. i never knew it had a log [08:43] hyperair: you have to set some environment options to enable logging [08:43] hyperair: check the man page [08:43] oh bah [08:43] i didn't have those set. [08:43] hyperair: try with hello-world to see what kind of data is being logged, then check if that same behaviour occurs when you build wine [09:09] Hi, I maintain a game, which I'd like to get into Ubuntu. It's been packaged for debian, and is included in debian unstable (sid). [09:10] what's the next step? do I need to get it to debian testing? or can it go straight from debian unstable to ubuntu? [09:10] game site: http://jasonwoof.org/vor debian package page: http://packages.debian.org/unstable/games/vor [09:11] zyga: aha, it doesn't seem to like the case when i just compile directly without -c [09:12] hyperair: hmm, without -c you just link, right? [09:12] JasonWoof: It will get sync'd directly into maverick when it opsn [09:12] *opens [09:12] iirc -c makes it not link just yet [09:12] hyperair: that would account for a small fraction of the overall build process [09:12] hyperair: like, most of wine gets built with -c, hopefully ;-) [09:12] StevenK: sweet! [09:13] zyga: lemme try that LOGFILE env trick [09:23] good morning [09:23] zyga: i get a whole bunch of "Places ___________.o into cache" [09:23] zyga: maybe it really is getting a whole bunch of different hashes each time. [09:24] hyperair: good, then it's working [09:24] hyperair: can you stop the build after first couple of objecrts [09:24] hyperair: examine them (check that your cache is really in your $HOME) [09:24] hyperair: and try to build again [09:25] hyperair: you can also ask ccache to do double hoop build [09:25] hyperair: first it will pre-process [09:25] hyperair: and the cache will be based on the pre-processed text, not the source text AFAIR [09:27] hyperair: hmm, sorry I take that back [09:27] hyperair: I was thinking about CCACHE_UNIFY [09:27] CCACHE_UNIFY sounds like it'll be nasty [09:28] hyperair: it's designed to assist in edits that don't alter the actual code [09:28] hyperair: you don't need it unless you hack on wine today [09:28] zyga: i know, i'm just rebuilding the same .dsc over and over. [09:36] zyga: on another build (codelite) argument -MM is unsupported [09:36] hyperair: huh? what is codelite? [09:36] -MM generates build deps [09:36] you should not need that for a package build [09:36] zyga: another package [09:37] zyga: for some reason, everything's getting a -MM flag [09:37] weird [09:37] well codelite is known for its weird build system [09:37] no it's normal [09:37] actually it's cheap and good to do so [09:37] O_o [09:37] you get deps _AND_ the .o file at once [09:37] why so? [09:38] ah [09:38] but surely you need the deps *first* [09:38] hyperair: perhaps you can patch the build system to support no-deps option, if it's make you can do that rather easily with injecting one CFLAGS:=$(filter-out -MM,$(CFLAGS)) line in a good spot [09:38] hyperair: no [09:39] hyperair: you only need the deps when you edit and build the code [09:39] hyperair: deps get you .h deps [09:39] zyga: it depends on whether the -MM is part of CFLAGS. [09:39] zyga: CFLAGS is usually only the user-customized flags [09:40] hyperair: internally you have to provide -MM as some kind of flag, I guess they are using CFLAGS to do that [09:41] zyga: no, it's bad practice to provide important flags in CFLAGS, because they can end up getting overridden. [09:41] zyga: one make CFLAGS="blah" will void every CFLAGS assignment [09:42] hyperair: not really [09:42] why not? [09:42] hyperair: you can control that from within make, usually you just CFLAGS+= stuff [09:42] zyga: no, you can't. [09:42] hyperair: and in the extreme case you can also override the environment value [09:42] zyga: += and exports don't work once overridden by the user. [09:43] if you've been doing that, then it's time to change =p [09:43] it's the reason automake uses its own ${SOMETHING_CFLAGS} arguments [09:43] there is the override directive [09:44] well in any way, there has to be a place where -MM gets used/added/whatever [09:44] of course [09:44] (automake is really ugly inside, I will not argue about which part is nice or correct) [09:45] lol [09:45] automake is nice to use [09:45] it's just that patching up errors isn't easy. [09:45] touching the Makefile.in can try your sanity [09:47] zyga: oh hey ccache works for codelite. [09:47] there is this project I like, I cannot remember the name, they are doing automake sans the ugly generated crap [09:47] oh :-) [09:47] even with -MM? [09:47] zyga: you mean autoconf? [09:47] hyperair: actually, no - automake [09:47] hyperair: the project integrates with autoconf [09:47] and existing autotools [09:47] zyga: yes, even with -MM. it still complains, but it reads the cached result anyway [09:47]