[00:00] <anon^_^> Is someone from the Ubuntu Development Team available that can triage a bug?
[00:01] <anon^_^> https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/574106
[00:01] <psusi> lvm fix?  gparted does not support lvm
[00:02] <anon^_^> 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] <anon^_^> There was a new release on May 3, 2010 to fix this
[00:06] <psusi> 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] <psusi> yea... looks like their bug report cites the two relevant patches to libparted I wrote... we're ahead of gparted ;)
[00:08] <anon^_^> I installed gparted from ubuntu lucid repos, I am unable to edit a boot partition that is not part of the lvm
[00:08] <psusi> can you be more specific?
[00:09] <anon^_^> i'm not sure how, I right lick on the boot partition and I'm unable to resize
[00:10] <psusi> do you get an error?
[00:10] <psusi> what version of libparted0 do you have installed?
[00:10] <anon^_^> the option resize/move is greyed out
[00:11] <anon^_^> 2.2-5ubuntu5
[00:14] <psusi> hrm... works for me...
[00:14] <psusi> are you sure the partition you are trying to resize is not in use?
[00:16] <james_w> lifeless: hi, around for a few minutes
[00:17] <lifeless>  
[00:17] <lifeless> james_w: hi
[00:17] <lifeless> james_w: what would you say is the most useful thing to do next in the bzr/distro workflow space
[00:17] <lifeless> not a promise to do :- want your thoughts as input to deciding :)
[00:18] <james_w> hmm
[00:18] <james_w> perhaps a bit late for strategic thinking :-)
[00:18] <lifeless> tactical will do :)
[00:18] <lifeless> I've suggested to spiv he might like to do a loom converter for bzr-builddeb imported branches
[00:19] <james_w> yeah, looms would be pretty high
[00:19] <lifeless> as something useful, and giving him more exposure to the content that the distro is working with
[00:19] <james_w> merging unrelated branches would be highest on my list right now I think
[00:19] <lifeless> do you mean file id related stuff?
[00:20] <james_w> or rather, getting upstreams mergeable to distro branches, at least as one-offs
[00:20] <lifeless> actually, what do you mean :P
[00:20] <james_w> so something in that area, either requiring a rewrite of the distro branch, or more smarts in bzr to make that unnecessary
[00:20] <lifeless> ok
[00:20] <lifeless> so the use case is
[00:21] <lifeless> 'I have a bzr-builddeb import-dsc branch, or similar. I now have an upstream branch. Help.'
[00:21] <james_w> yes
[00:22] <james_w> 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] <lifeless> sure
[00:22] <lifeless> I think its a rewrite case
[00:22] <lifeless> 'path tokens', as I called them, will carry baggage around for some time
[00:22] <james_w> 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] <lifeless> james_w: they can just drop the distro history, though its not a brilliant answer
[00:23] <james_w> right
[00:24] <james_w> 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] <james_w> 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] <james_w> so you get a discontinuity, but that becomes less important over time
[00:25] <lifeless> how does this sound
[00:25] <lifeless> as a 'break the dam' approach
[00:25] <lifeless> we write a little script
[00:25] <lifeless> that checks for changes to stuff outside debian/
[00:26] <lifeless> stashes that somewhere; does a join of the branches, grabs the upstream content and restores that diff
[00:26] <lifeless> and does this all as one commit
[00:26] <lifeless> no conflicts
[00:27] <james_w> sounds reasonable, but I'm not sure how much more work the rewrite case would be
[00:27] <lifeless> Much more, I think.
[00:28] <lifeless> bzr-rewrite is awkward to work with.
[00:28] <lifeless> I don't want to get into making that awesome *and then* get folk the ability to connect branches
[00:28] <lifeless> I'd rather get the ability to connect these branches, *and then* make it better.
[00:30] <lifeless> the specifically harder thing about rewrite is we don't know where to do repeated merges
[00:31] <lifeless> and in general the content won't match for autoconf output etc, repeatedly throughout time
[00:31] <lifeless> james_w: while you're here. I'd like to stop the builddeb importer stripping .bzrignore
[00:31] <lifeless> james_w: I filed a bug, but I don't think you've given your opinion on that
[00:32] <james_w> I thought it had been done, but I might be misremembering
[00:32] <james_w> it's a trivial patch
[00:32] <lifeless> yes, but are you happy with it  being done :)
[00:34] <james_w> dunnio
[00:34] <james_w> you can force me to think about it :-)
[00:34]  * lifeless forces
[00:34] <lifeless> james_w: why the change to say 'bzr merge . -r tag:upstream-1.2.3' in your merge of my patch ?
[00:34] <james_w> in my experience it causes trouble, and I can't think of any good reasons to do it
[00:35] <james_w> explicit is better than implicit
[00:36] <james_w> 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] <lifeless> what are the problems?
[00:36] <lifeless> I mean, I can describe the problems the stripping gives me concisely: it breaks merging from upstream
[00:37] <temugen> psusi: bzr branch of the grapher: http://bradmisik.com/trunk/fragraph
[00:38] <james_w> 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] <james_w> such as not being able to recreate the source package that we imported properly
[00:38] <lifeless> james_w: we could import .bzr, but it would be mind bending :)
[00:38] <james_w> well, you can't import .bzr right now
[00:38] <psusi> temugen, thanks... checking it out now
[00:39] <james_w> try telling TreeTransform to create a .bzr/branch-format some time, it's quite spectacular
[00:39] <lifeless> james_w: I'll describe how you can over a beer. Needs a custom format object.
[00:39] <lifeless> and possibly some monkey aptches
[00:39] <james_w> right, that's what I mean by "right now2
[00:39] <lifeless> anyhow, distractions aside
[00:39] <james_w> if there's nothing else then I'll be heading to bed
[00:40] <lifeless> .bzrignore should be ok ?
[00:40] <james_w> yep
[00:40] <lifeless> I'll push a patch for it.
[00:40] <lifeless> gnight.
[00:41] <james_w> thanks
[00:41] <james_w> night
[01:03] <persia> 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] <JontheEchidna> 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] <df00z1> 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] <df00z1> 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] <df00z1> I dont see anything in the guides that say you CANT do it
[02:02] <df00z1> I wrote the devels of iscsitarget, they wont be changing it
[02:02] <df00z1> their makefile doesnt support DESTDIR, only DISTDIR
[02:03] <ScottK> df00z1: #ubuntu-motu is a better channel for that question.
[02:03] <df00z1> Ok I'll check them out, thanks
[02:04] <persia> 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] <ScottK> jdong: Any chance you can look at the pending clamav SRU and give it SRU team blessing?
[02:08] <jdong> ScottK: sure, bug #?
[02:09] <psusi> 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] <ScottK> jdong: Bug #574906 and Bug #571543
[02:12] <jdong> ScottK: ACKed
[02:12] <ScottK> jdong: Thanks.
[02:13]  * ScottK switches hats.
[02:13] <jdong> 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] <ScottK> jdong: Will do.  Thanks again.
[02:14] <ScottK> jdong: You might want to look at http://launchpadlibrarian.net/47809319/xubuntu-default-settings_10.04.8_source.changes
[02:16] <jdong> ScottK: thanks
[02:16] <jdong> ScottK: looks like Martin ACKed it already
[02:16] <ScottK> OK.  I'll process it then.
[02:24] <ScottK> Done.
[02:34] <txwikinger> Does KDE get windicators too?
[02:36] <ScottK> txwikinger: You tell me: http://blog.martin-graesslin.com/blog/2010/05/why-you-should-not-use-client-side-window-decorations/
[02:37] <RAOF> 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] <ScottK> RAOF: I thought client side decoration was required?
[02:39] <RAOF> 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] <RAOF> If KDE didn't want to do client-side-decoration.
[02:39] <persia> It would be.  Naking it work sanely would require an extension to the WM interface, which isn't what was described.
[02:40] <ScottK> That's kind of what I'd have thought, but it'd be very different than what has been proposed.
[02:40] <txwikinger> why can't the decorator accept plugins?
[02:40] <persia> txwikinger: It could, but nobody ever defined that an an extension of the WM interface, to my knowledge.
[02:41] <txwikinger> well.. I see no obstacle to start with it
[02:41] <persia> 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] <txwikinger> Well. you only need a fallback if it is additional functionality
[02:42] <persia> There's no obstacle: mostly needs thinking about *how* to pass *what* to enable that sort of thing in a generic fashion.
[02:42] <txwikinger> if it is just a convenience thing the fallback could be like it is now
[02:42] <RAOF> persia: I was under the impression it'd be pretty much like the dbusmenu work that already drives appindicators
[02:43] <txwikinger> well. I would think all of the window managers in question are composite managers
[02:43] <persia> I mayhave read the blog post wrong, but I had the impression it would be a replacement for the status bar.
[02:43] <lifeless> you're both right
[02:43] <lifeless> raof is talking implementation
[02:43] <persia> RAOF: Yes, but there's nothing in the WM spec to receive that yet :)
[02:43] <lifeless> persia is talking user experience, AFAICT
[02:43] <lifeless> persia: it wouldn't be WM per se - it would be client side
[02:43] <persia> user experience and spec compliance, but yeah.
[02:43] <txwikinger> composite means the decorator would just assign the space and the windicator would plug itself in there
[02:44] <persia> lifeless: Only if it's CSD.
[02:44] <lifeless> right, AIUI that was prereq
[02:44] <persia> It's not.
[02:44] <RAOF> I don't see why it would be predicated on CSD.  KWin would just need to grow an appropriate dbus interface.
[02:44] <persia> 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] <txwikinger> what is CSD?
[02:45] <persia> RAOF: You're thinking about specifics.  We have > 10 WMs in Ubuntu.
[02:45] <RAOF> And users of crazy window decorators get to see the magical fallback paths :)
[02:45] <persia> txwikinger: Client Side Decorations.
[02:45] <RAOF> persia: And I think we should *care* about 3 WMs, give or take.
[02:45] <RAOF> At least as far as this work goes.
[02:45] <txwikinger> 4
[02:46] <RAOF> There will always be crazy WMs that do funky things; we'll need fallbacks regardless.
[02:46] <persia> 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] <persia> txwikinger: Does your 4 match my 4?
[02:47] <RAOF> CSD windows could get it for free, which makes it easier.
[02:47] <persia> Right, which is why it's overwhelmingly likely that a CSD implementation will be sought.
[02:48] <txwikinger> persia.. I think so.. I thought KDE/Gnome/Xfce and L...
[02:48]  * txwikinger still likes a plugin solution
[02:48] <RAOF> But that CSD implementation shouldn't prejudice the ability of other decorators implementing it.
[02:49] <persia> txwikinger: Then the same.  KDE is kwin, GNOME is compiz, Xfce is metacity, and LXDE is openbox.
[02:49] <txwikinger> well. kde can run compiz too isn't it
[02:49] <ScottK> RAOF: It's pretty clear that CSD means KDE won't support it.
[02:49] <ScottK> txwikinger: It can, but it's not supported by Kubuntu or upstream.
[02:50] <txwikinger> what is the WM for Kubuntu with compiz enabled?
[02:50] <RAOF> 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] <ScottK> There's no work planned for a non-CSD implementation.
[02:51] <ScottK> (at least as far as I've seen)
[02:51] <persia> txwikinger: I believe the lack of a good answer to that question is *why* it's not a supported configuration :)
[02:52] <ScottK> persia: Why would it be?
[02:52] <txwikinger> well. whatever the desktop effects are
[02:52] <ScottK> txwikinger: In KDE, that's kwin.
[02:52] <txwikinger> ScottK: was that always kwin?
[02:52] <RAOF> 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] <ScottK> txwikinger: For KDE4, yes.
[02:53] <RAOF> The WM for Kubuntu with compiz enabled is compiz.  That's easy :)
[02:53]  * txwikinger must have remebered KDE3 then
[02:53] <ScottK> 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] <ScottK> So even if patches were done for kwin, they'd have no place to land.
[02:54] <RAOF> 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] <txwikinger> why do people always say something like that?
[02:55] <RAOF> KWin would still be drawing the decorations, but it'd be additionally drawing a bunch of indicators.
[02:55] <ScottK> txwikinger: Did you read the blog post.
[02:55] <RAOF> In that decoration.
[02:55] <txwikinger> ScottK: yes
[02:55] <ScottK> RAOF: So then what happens when you run a KDE app in a Gnome session or the reverse?
[02:56] <persia> 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] <RAOF> 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] <persia> No, because KWin will override the decorations, based on the blog post.
[02:57] <ScottK> Yep
[02:57] <RAOF> Because KWin doesn't respect the “don't decorate me” hint?
[02:57] <RAOF> That seems rather unfriendly.
[02:58] <ScottK> It seems to some how since my chromium windows don't look like kwin.
[02:58] <RAOF> Right.  The CSD GTK apps *should* behave exactly like that.
[02:59] <RAOF> 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] <ScottK> Which does mean they won't fit in at all with the desktop environment.
[02:59] <ScottK> GTK apps in Kubuntu look reasonably native currently.
[02:59] <persia> 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] <RAOF> Making them remain reasonably native would be a matter of appropriate engine coding.
[03:01] <txwikinger> why can't the windicators just be plugins that still allow Kwin to do what it does today
[03:01] <RAOF> txwikinger: Plugins to what?
[03:01] <persia> txwikinger: They could.  It's just lots more work that way.
[03:02] <txwikinger> maybe I don't understand WMs good enough
[03:02] <RAOF> 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] <txwikinger> but I would think in the sense of plasmoids
[03:03] <persia> 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] <persia> and it needs to be extended in a way that is acceptable to the WM development community generally.
[03:03] <ScottK> Or at least have agreement on how to implement it even if the implementations appear somewhat asynchronously.
[03:03] <persia> Using CSD sidesteps the entire conversation, and the cost of inconsistent interface.
[03:03] <txwikinger> persia: I think that extension would be reasonable
[03:04] <persia> txwikinger: I agree, but it needs doing, and it's a bundle of work.
[03:05] <ScottK> Which no one appears to be proposing be done.
[03:06] <ScottK> (at least not in the community of candidates to do the work)
[03:07] <persia> 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] <ScottK> Is there anyone coming to have this discussion and not just the how we're going to do CSD one?
[03:08] <ScottK> I doubt this is on the agenda.
[03:09] <persia> Ah, good point.  There may be insufficient representation from the WM development community to have the discussion.
[03:11] <ScottK> I've seen the list if KDEish people coming.  No kwin developers on the list.
[03:13] <persia> 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] <ScottK> 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] <persia> 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] <persia> lifeless: Dunno if you7re still interested, but http://blino.org/blog/mandriva/poulsbo-xserver1.7.html caught my eye.
[03:37] <RAOF> lifeless: You're another unfortunate with a gma500 system?
[03:37] <persia> RAOF: You have one?
[03:38] <RAOF> persia: No, but there are some in #ubuntu-x and Sarvatt's working on it.
[03:38] <lifeless> RAOF: lynnes eeepc is
[03:39]  * persia sends blessings Sarvatt's way
[03:39] <lifeless> 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] <lifeless> s/API/ABI/
[03:40] <RAOF> lifeless: Well, last I saw there was mutterings and cursings and I think X might have been coming up with acceleration.
[03:40] <psusi> 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] <lifeless> RAOF: cool; xorg-edgers ? :)
[03:41] <RAOF> lifeless: A different PPA, I think.  Let me browse the logs…
[03:42] <lifeless> RAOF: don't bother
[03:42] <lifeless> I can't fiddle for 2 weeks anyway
[03:42] <persia> 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] <RAOF> lifeless: Too late: https://edge.launchpad.net/~sarvatt/+archive/psb/+packages
[03:42] <RAOF> :)
[03:43] <psusi> persia, none of it is safe, it's a question of the lesser of evils ;)
[03:43] <StevenK> Not those 3 letters!
[03:43] <StevenK> Nooooooooooooooooo
[03:43] <psusi> 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] <lifeless> StevenK: p
[03:43] <lifeless> StevenK: s
[03:43] <lifeless> StevenK: b
[03:44] <StevenK> Lalalalalala, I can't hear you
[03:44] <lifeless> StevenK: don't worry, in 5 days you will
[03:44] <StevenK> lifeless: I no longer have to care
[03:44] <lifeless> StevenK: I know. But you'll still hear ;)
[03:46] <persia> 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] <persia> 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:06] <Sarvatt> 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] <persia> Sarvatt: Might you come to UDS?  I've one that just gathers dust.
[04:09] <persia> (it's actually a "cell phone", but it's larger than one of my "laptop"s, so I never use it)
[04:11] <Sarvatt> 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] <persia> Sure.  I'll bring it along.
[04:13] <persia> Might still have a not-quite-jaunty on it, with arbitrary hacks, but presumably it could be upgraded, etc.
[04:20] <persia> 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:21] <persia> ogra: More specifically, do *you* want to do something, or should all the patches be pushed upstream somehow?
[04:21] <ajmitch> though the bug doesn't have actual patches, but just dumps from a tool
[04:22] <persia> Ah, right.  I guess it needs someone to dig thorugh the dumps, and generate a patch.
[04:22] <persia> Sorry for the noise.
[04:28] <Sarvatt> 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
[04:30] <RAOF> Sarvatt: Really? :(.  I got the impression that psb was almost universally disliked, even within Intel.
[04:31] <Sarvatt> yeah moorestown, there's a ton of support patches for it in meego
[04:31] <persia> I think the idea of using embedded graphics cores is not universally disliked.
[04:37] <lifeless> I love embedded graphics cores... that are open
[04:39] <persia> Which ones are those again?
[04:49] <RAOF> 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] <lifeless> http://en.wikipedia.org/wiki/Intel_Core_i7 gives some hint
[04:58] <persia> 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] <persia> Anyway, I don't want to care enough about it :)  I'll just hope they have open specifications.
[06:54] <pitti> Good morning
[06:54] <pitti> JontheEchidna: ah, that was actually just a copy&paste error from the changelog; it's not actually installed any more; thanks!
[07:27] <pitti> zul: can you please reupload landscape-client with the correct -v option to show both changelogs, or merge the changelogs?
[08:02] <zyga> morning
[08:08] <dholbach> good morning
[08:10] <mvo> hey zyga
[08:10] <mvo> hey seb128, dholbach
[08:11] <zyga> mvo: hello, how are you :-)
[08:11] <seb128> hey mvo
[08:11] <mvo> zyga: good, thanks, how are you?
[08:11] <zyga> mvo: fine, I'm trying to find the right google domain for my project, so many of them around ;-)
[08:12] <dholbach> hey mvo, salut seb128
[08:12] <seb128> hey dholbach
[08:12] <dholbach> comment ça va?
[08:13] <seb128> dholbach, un peu fatigué mais sinon bien, et toi ?
[08:14] <dholbach> seb128: un peu fatigué aussi
[08:15] <pitti> hallo dholbach!
[08:16] <dholbach> seb128: doko va arriver ici dans quelque minutes, son internet est encore "cassé" :)
[08:16] <seb128> dholbach, c'est un prétexte pour pas travailler !
[08:17] <dholbach> "ah ah" :)
[08:17] <dholbach> becaucoup de travaille ici, pas travailler n'est pas une option :)
[08:22] <seb128> dholbach, ;-)
[08:36] <hyperair> hmm test building wine in sbuild with ccache seems to lead to nothing but ccache missees
[08:36] <hyperair> what gives?
[08:37] <zyga> hyperair: maybe it inserts build date/time into all objects?
[08:37] <hyperair> zyga: ah yes that might be the cause
[08:37] <zyga> hyperair: or it gets around to avoid ccache in some magic way
[08:37] <zyga> hyperair: but it would be queer to put timestamp into _all_ objects
[08:37] <hyperair> no wait, ccache is defunct
[08:38] <hyperair> zyga: ccache is defunct, that's definite.
[08:38] <RAOF> sbuild will be building in a clean chroot, right?  That's unlikely to pick up your ccache cache :)
[08:38] <zyga> hyperair: how so? I've used it with great success in the past
[08:38] <hyperair> zyga: same here.
[08:38] <hyperair> RAOF: sbuild bind-mounts my home
[08:38] <zyga> RAOF: oh, good point
[08:39] <hyperair> RAOF: and builds under my UID
[08:39] <hyperair> watch ccache -s shows the misses going up
[08:39] <hyperair> zyga: i just tried with a helloworld.cc test
[08:39] <zyga> hyperair: did you try checking that hello-world.c is cached correctly/
[08:39] <zyga> :D
[08:40] <hyperair> zyga: heh?
[08:41] <hyperair> lemme just run a ccache cleanup
[08:42] <zyga> hyperair: one more possibility is to check the ccache log
[08:42] <zyga> hyperair: I know that ccache just bails out if it sees some option it does not understand
[08:42] <hyperair> zyga: eh interesting. i never knew it had a log
[08:43] <zyga> hyperair: you have to set some environment options to enable logging
[08:43] <zyga> hyperair: check the man page
[08:43] <hyperair> oh bah
[08:43] <hyperair> i didn't have those set.
[08:43] <zyga> 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] <JasonWoof> 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] <JasonWoof> 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] <JasonWoof> game site: http://jasonwoof.org/vor   debian package page: http://packages.debian.org/unstable/games/vor
[09:11] <hyperair> zyga: aha, it doesn't seem to like the case when i just compile directly without -c
[09:12] <zyga> hyperair: hmm, without -c you just link, right?
[09:12] <StevenK> JasonWoof: It will get sync'd directly into maverick when it opsn
[09:12] <StevenK> *opens
[09:12] <JasonWoof> iirc -c makes it not link just yet
[09:12] <zyga> hyperair: that would account for a small fraction of the overall build process
[09:12] <zyga> hyperair: like, most of wine gets built with -c, hopefully ;-)
[09:12] <JasonWoof> StevenK: sweet!
[09:13] <hyperair> zyga: lemme try that LOGFILE env trick
[09:23] <joaopinto> good morning
[09:23] <hyperair> zyga: i get a whole bunch of "Places ___________.o into cache"
[09:23] <hyperair> zyga: maybe it really is getting a whole bunch of different hashes each time.
[09:24] <zyga> hyperair: good, then it's working
[09:24] <zyga> hyperair: can you stop the build after first couple of objecrts
[09:24] <zyga> hyperair: examine them (check that your cache is really in your $HOME)
[09:24] <zyga> hyperair: and try to build again
[09:25] <zyga> hyperair: you can also ask ccache to do double hoop build
[09:25] <zyga> hyperair: first it will pre-process
[09:25] <zyga> hyperair: and the cache will be based on the pre-processed text, not the source text AFAIR
[09:27] <zyga> hyperair: hmm, sorry I take that back
[09:27] <zyga> hyperair: I was thinking about CCACHE_UNIFY
[09:27] <hyperair> CCACHE_UNIFY sounds like it'll be nasty
[09:28] <zyga> hyperair: it's designed to assist in edits that don't alter the actual code
[09:28] <zyga> hyperair: you don't need it unless you hack on wine today
[09:28] <hyperair> zyga: i know, i'm just rebuilding the same .dsc over and over.
[09:36] <hyperair> zyga: on another build (codelite) argument -MM is unsupported
[09:36] <zyga> hyperair: huh? what is codelite?
[09:36] <zyga> -MM generates build deps
[09:36] <zyga> you should  not need that for a package build
[09:36] <hyperair> zyga: another package
[09:37] <hyperair> zyga: for some reason, everything's getting a -MM flag
[09:37] <hyperair> weird
[09:37] <hyperair> well codelite is known for its weird build system
[09:37] <zyga> no it's normal
[09:37] <zyga> actually it's cheap and good to do so
[09:37] <hyperair> O_o
[09:37] <zyga> you get deps _AND_ the .o file at once
[09:37] <hyperair> why so?
[09:38] <hyperair> ah
[09:38] <hyperair> but surely you need the deps *first*
[09:38] <zyga> 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] <zyga> hyperair: no
[09:39] <zyga> hyperair: you only need the deps when you edit and build the code
[09:39] <zyga> hyperair: deps get you .h deps
[09:39] <hyperair> zyga: it depends on whether the -MM is part of CFLAGS.
[09:39] <hyperair> zyga: CFLAGS is usually only the user-customized flags
[09:40] <zyga> hyperair: internally you have to provide -MM as some kind of flag, I guess they are using CFLAGS to do that
[09:41] <hyperair> zyga: no, it's bad practice to provide important flags in CFLAGS, because they can end up getting overridden.
[09:41] <hyperair> zyga: one make CFLAGS="blah" will void every CFLAGS assignment
[09:42] <zyga> hyperair: not really
[09:42] <hyperair> why not?
[09:42] <zyga> hyperair: you can control that from within make, usually you just CFLAGS+= stuff
[09:42] <hyperair> zyga: no, you can't.
[09:42] <zyga> hyperair: and in the extreme case you can also override the environment value
[09:42] <hyperair> zyga: += and exports don't work once overridden by the user.
[09:43] <hyperair> if you've been doing that, then it's time to change =p
[09:43] <hyperair> it's the reason automake uses its own ${SOMETHING_CFLAGS} arguments
[09:43] <zyga> there is the override directive
[09:44] <zyga> well in any way, there has to be a place where -MM gets used/added/whatever
[09:44] <hyperair> of course
[09:44] <zyga> (automake is really ugly inside, I will not argue about which part is nice or correct)
[09:45] <hyperair> lol
[09:45] <hyperair> automake is nice to use
[09:45] <hyperair> it's just that patching up errors isn't easy.
[09:45] <hyperair> touching the Makefile.in can try your sanity
[09:47] <hyperair> zyga: oh hey ccache works for codelite.
[09:47] <zyga> there is this project I like, I cannot remember the name, they are doing automake sans the ugly generated crap
[09:47] <zyga> oh :-)
[09:47] <zyga> even with -MM?
[09:47] <hyperair> zyga: you mean autoconf?
[09:47] <zyga> hyperair: actually, no - automake
[09:47] <zyga> hyperair: the project integrates with autoconf
[09:47] <zyga> and existing autotools
[09:47] <hyperair> zyga: yes, even with -MM. it still complains, but it reads the cached result anyway
[09:47] <zyga> it just replaces the part that you generate the makefiles
[09:48] <hyperair> zyga: heh? how do you use automake without causing a generated Makefile.in?
[09:48] <hyperair> O_o
[09:48] <zyga> hyperair: yes, you just write the _same_ stuff in a regular makefile
[09:48] <zyga> hyperair: and the code they wrote uses pure gnu make to do the rest
[09:48] <zyga> no generated 50K mess
[09:48]  * hyperair shrugs
[09:48] <hyperair> sounds like a lot more work
[09:49] <zyga> ah
[09:49] <zyga> found it
[09:49] <zyga> quagmire
[09:49] <zyga> http://code.google.com/p/quagmire/
[09:50] <zyga> I checked it about 1 year ago last time as I had no use of that tech where I worked before
[09:50] <zyga> hyperair: http://code.google.com/p/quagmire/source/browse/trunk/example/simple/Quagmire.mk
[09:51] <zyga> example
[09:52] <hyperair> zyga: that looks exactly like a Makefile.am
[09:52] <hyperair> zyga: how is that different from using automake?
[09:53] <zyga> hyperair: the way it works is 10x better
[09:53] <hyperair> zyga: why so?
[09:54] <zyga> hyperair: it's faster and there is no generated makefile for you to debug
[09:54] <zyga> hyperair: automake is _really_ inefficient in what it does
[09:54] <hyperair> zyga: only if you do the recursive automake style
[09:54] <hyperair> i personally use .mk files everywhere, with non-recursive automake
[09:54] <zyga> hyperair: the only advantage it that it supported arcane systems where everything was broken and you had to patch around with horrid portable sh scripts
[09:54] <hyperair> it goes really fast.
[09:54] <zyga> hyperair: right, automake is not bad by design, but the implementation could be better nowdays
[09:55] <zyga> hyperair: it was also designed to work on non-gnu make
[09:55] <zyga> that's really pointless nowdays
[09:55] <zyga> hyperair: non-gnu make build systems are faster
[09:55] <hyperair> it isn't.
[09:55] <zyga> especially if you take account the configure phase
[09:55] <hyperair> well that's just the configure phase
[09:55] <hyperair> it's a one-off thing
[09:56] <zyga> not really
[09:56] <hyperair> what else changes?
[09:56] <zyga> hyperair: if you build 1000s of packages the configure phase is slowing you down
[09:56] <hyperair> heh i suppose.
[09:56] <zyga> hyperair: you cannot do it in parallel
[09:56] <zyga> and it's only broken legacy crap when you cross compile
[09:56] <hyperair> well non-gnu *nixes still suck without autofoo
[09:56] <zyga> hyperair: quagmire also has one advantage
[09:56] <zyga> it uses less shell
[09:57] <zyga> less shell = faster
[09:57] <hyperair> lemme just check out quagmire's code and take a look
[09:57] <zyga> hyperair: I hope they finish the work and that the project is not dead
[09:57] <hyperair> i'm just not convinced.
[09:57] <zyga> but believe me, non-gnu build systems can be way better
[09:58] <zyga> the only problem is that you cannot usually expect them to be used in vast open source world ;-)
[09:58] <zyga> hyperair: think about why large projects are switching away from make
[09:58] <hyperair> zyga: general stupidity and refusal to learn m4.
[09:59] <hyperair> zyga: at least, those are the unbiased reasons for using waf and scons
[09:59] <zyga> hyperair: I say efficiency and windows build requirements
[09:59] <zyga> hyperair: autotools on windows blows
[10:00] <hyperair> what's hard about it? cygwin's almost the same, is it not?
[10:00] <zyga> hyperair: no :D
[10:00] <hyperair> honestly, the only thing i see as a viable alternative to autofoo is cmake.
[10:00] <hyperair> the *only* viable alternative
[10:00] <zyga> hyperair: first off - what if you have to build with visual studio?
[10:00] <zyga> hyperair: then you only need cygwin to run those slow shell scripts
[10:00] <hyperair> throw that crap away
[10:01] <zyga> hyperair: it's not crap, you have to use it alot on windows because gnu on windows is not up to par with Ms stuff, really
[10:01] <hyperair> compilations have i/o bound bits. the shell scripts aren't changing much.
[10:01] <zyga> hyperair: you may not like it but it's true
[10:01] <hyperair> especially if you have a proper sh
[10:01] <zyga> hyperair: on windows cygwin is 10x-50x slower than regular shell on the same box with linux
[10:01] <zyga> so having cygwin feels like using decade old PC
[10:01] <zyga> hyperair: and if you build with cygwin you reguire cygwin.dll
[10:02] <zyga> another bummer
[10:02] <zyga> and what if you want to link to some platform specific bits, well ...
[10:02] <zyga> to say the least: automake is not good there - it might work if you are carefully - but it's not optimal
[10:02] <zyga> s/carefully/careful/
[10:02] <zyga> anyway, it's not related to ubuntu
[10:03] <zyga> if you really want to talk about this let's go somewhere elase
[10:05] <hyperair> heheh
[10:20] <pitti> cjwatson: just got a message from doko that gcc 4.5 isn't supposed to be the default yet (pending SRU discussion); accepted perl and base-files
[11:22] <bigon> pitti: hi, I've installed posgresql and it listen on port 5433 any reason of this?
[11:22] <StevenK> bigon: Because you have an older version running on 5432?
[11:23] <bigon> well in the configuration 5433 is explicitly defined
[11:24] <ogra> cjwatson, are we planning to merge initramfs-tools 0.92f for maverick ?
[11:25] <ogra> (seems new flash-kernel has a versioned dep on it for kirkwood arches in debian)
[11:26] <jcisio> hello
[11:26] <jcisio> I want to search for a translation of "thing" in all Ubuntu package, how to get po of a certain locale in all packages?
[11:28] <sladen> jcisio: does the Launchpad translations suggestions help?
[11:28] <sladen> jcisio: that does fuzzy matching
[11:28] <jcisio> no I want to translate automatically all menu items in the ubuntu-manual
[11:29] <jcisio> so I need a automatical mechanism
[11:29] <sladen> jcisio: so you have a peusdo .svg screenshot and want to replace the strings in that with that the user of (eg. Italian) will see?
[11:30] <jcisio> yes, nearly
[11:30] <dpm> hi jcisio, in principle you can't. You could download all PO files from https://translations.edge.launchpad.net/ubuntu/lucid/+language-packs . However, I would strongly discourage you from translating things automatically, since it tends to lead to very bad translations. Translation teams should be the ones translating and reviewing translations
[11:30] <jcisio> I have "bla bla \menu{thing} bla bla" and whan to replace "thing" by its translation
[11:30] <jcisio> s/whan/want/
[11:31] <sladen> you really need  \menu{release::application::specificmenuid}  and (eg. everything that gettext needs
[11:31] <jcisio> this is a 160+ pages manual, and those are things that are already translated
[11:32] <jcisio> author won't like that lol
[11:32] <sladen> jcisio: and then gettext will do that for you based on the available installed langpacks;  so just install (build-dep) on all of the language packs and have your make script do the replacement based on the native gettext domain
[11:32] <dpm> jcisio, I know the Ubuntu Manual, but I'm just saying that not all languages are the same, and automatic translation tends to lead to poor translations, and a bad impression on quaility to users
[11:32] <jcisio> For example in manual there is "Click on the menu item \menu{File} and then..." then I want to replace "File" with appropriate translation
[11:33] <sladen> gettext
[11:33] <sladen> use. the. same. methods. that. the. applications. themselves. are. using
[11:33] <sladen> no automatic translations needed, and the user will see exactly what the application in real life will contain
[11:33] <jcisio> many translators want to have it done like that, mean the translation of "sure" thing
[11:34] <dpm> jcisio, how do you know, have you asked translators?
[11:34] <jcisio> as when they translate, they don't rememer that is the "real" thing
[11:34] <sladen> okay, fish the default out using gettext and have them check it
[11:34] <jcisio> there are many suggestion like that in the mailing list
[11:35] <jcisio> even in our team (Vietnamese), we need a consistence in translation (manual vs software)
[11:38] <dpm> on which mailing list? I didn't see any on ubuntu-translators. Anyway, my recommendation is to leave translators do their work and review the translations other than the developers doing it for them. If you want to do it for a language you know, it's fine, but the same rules don't apply for all languages. In any case, for consistency you can use Launchpad's global suggestions, where translators just have to do one click to translate if the suggestion is
[11:38] <dpm>  appropriate. I hope this helps. Feel free to join us on #ubuntu-translators if we can give you a hand
[11:41] <joaopinto> dpm, if I understood it currently he is attempting to cross reference real software translations, for software strings, I don't see how could that lead to poor translations :)
[11:41] <joaopinto> ops, s/currently/correctly
[11:43] <dpm> joaopinto, unless he knows the rules for gender, plurals, grammar for all languages, and knows for certain that the translated string he's picking up coincides exactly with the one he's trying to automatically translate, it can be difficult
[11:43] <joaopinto> dpm, he is referring to extract strings which refer exactly to a software string, there is no conversion involved
[11:44] <joaopinto> like "Please use the File -> Menu -> Action"
[11:44] <joaopinto> to "regular translation  File_String -> Menu_String -> Action_String", where _String are extracted from the pofiles
[11:47] <dpm> joaopinto, so what's "regular translation then"? If I understand it correctly, he's talking about searching all PO files for all languages hoping to find a matching translation for the original English string. Even if that works, the translation might be out of context
[11:47] <dpm> oh, I see what you mean with "regular translation" now
[11:48] <dpm> But I still thing automatically searching for File_String, etc. translations is not safe
[11:48] <dpm> Translators can do it themselves using e.g. translation memories
[11:49] <dpm> anyway, as I say, I'd ask translators first :)
[12:00] <sladen> jcisio: joaopinto: dpm: in theory, you can do something like  LANG=en_GB gettext -d gimp20 -s "File Open _Dialog"   but I can't get that to work just now
[12:01] <sladen> and it'll return  "File Open _Dialogue"  (in theory)
[12:06] <james_w> TheMuso: do you know of a bug somewhere for pulseaudio respawning very quickly or similar? I'm getting several reports of problems apparently caused by this, something is repeatedly trying to use rtkit in a very fast loop. Is that just a symptom of several possible problems?
[12:29] <TheMuso> james_w: Pulseaudio is set up to automatically spawn by default if a client requests it. Since the volume indicator is running, if pulseaudio is killed, it will be respawned due to clients still running that need it.
[12:29] <TheMuso> james_w: And I am off this week, so haven't seen any new pulse bug mail since last week, and prior to this week, I haven't seen anything along these lines.
[12:34] <james_w> TheMuso: so it's probably pulse crashing on startup, and then getting respawned?
[12:34] <TheMuso> james_w: possibly, I won't know till next week when I look at bug mail to see if anything similar has come up. Maybe crimsun might know something.
[12:42] <james_w> TheMuso: thanks, I'll get the reporters to try things
[13:17] <jcisio> sladen, joaopinto, dpm: in the ubuntu-manual list, the translator(s) want to reuse what that have been done in software translation https://lists.launchpad.net/ubuntu-manual/msg01672.html
[13:18] <jdstrand> pitti: hi! did you happen to see my question yesterday regarding firefox?
[13:19] <seb128> jdstrand: he's travelling to Brussels
[13:19] <jdstrand> ah
[13:19] <jdstrand> ok
[13:19] <jcisio> I discussed with godbyk (tech coordinator of ubuntu-manual), too, and we agreed that a tool is good
[13:19] <jdstrand> seb128: thanks
[13:19] <seb128> jdstrand: he should be around in a few hours from now though
[13:19] <jdstrand> k
[13:19] <seb128> jdstrand: what was the ping about? I can ping him directly when he arrives there
[13:19] <jdstrand> seb128: it isn't that urgent
[13:19] <seb128> ok
[13:20] <jdstrand> seb128: but thanks for the offer :)
[13:20] <jcisio> problem is we don't know the string is in which package (in order to know that, authors must add more data, that they eventually don't know, in the document)
[13:22] <jcisio> oh thanks dpm, I'm downloading the pack at https://translations.launchpad.net/ubuntu/lucid/+language-packs it seems to be the right one!
[13:24] <dpm> jcisio, no worries, be sure to download the base language pack, which is the one that contains all translations. It's going to be a few hundred Mb download, though :)
[13:24] <jcisio> well, 500+ MB
[13:27] <sladen> jcisio: the package (category/domain) is quite important as how a string has been translated depends on that particular context/application.  however, it's basically going to be the same for each Chapter
[13:30] <jcisio> sladen, because of that, I consider count all translation of a string (two or three word string, maximum), and take the most popular one
[13:30] <jcisio> I don't know if it could be done better, without the context of the package
[13:30] <jcisio> (that is currently not included in manual)
[13:30] <sladen> jcisio: information loss.  not a good idea
[13:31] <sladen> jcisio: if you're trying to do something automatically, you at least need to give it the right input data
[13:31] <jcisio> try to guess ;)
[13:32] <jcisio> I think it's much to ask the author of ubuntu-manual to know in which package their text is in
[13:32] <sladen> you'd kind of hope they knew which application they were writing about...
[13:32] <sladen> you'd kind of hope it's mentioned in the chapter title
[13:33] <sladen> otherwise the poor reader is going to have a heck of a time guessing what the manual is for
[13:33]  * persia can imagine task-based chapters ("Listening to Music") that fail to mention a specific application in the chapter title.
[13:34]  * persia hasn't actually looked at the manual, so has no real idea if that would be the case
[13:35] <sladen> persia: but it might open with a title like  "Rhythmbox is the default music player in Ubuntu, if can be found in  Applications->Sound & Video->Rhythmbox Music Player"
[13:35] <sladen> persia: s/title/lede/
[13:36] <persia> Oh, sure, but it's harder to parse lead sentences than titles automatically :)
[13:36] <jcisio> well, when I click on a menu, I don't know in which package it is
[13:37] <jcisio> a menu/button in an application is ok, but the package name is...
[13:38] <jcisio> well, if the manual is for apt-get thing, it's much easier
[13:39] <jcisio> Actually, what I try to do is this: having this string:
[13:39] <jcisio> Once your computer finds the Live \\acronym{CD} and after a quick loading screen, you will presented with the ``Welcome'' screen. Using your mouse, select your language from the list on the left, then click the button labeled \\button{Try Ubuntu 10.04}. Ubuntu will then start up, running straight from the Live \\acronym{CD}.
[13:39] <jcisio> I detect \\button{Try Ubuntu 10.04}, and try to replace thing in {} with its translation
[13:41] <jcisio> Two translator may have different translation for "Try Ubuntu 10.04", but there should be an consistence between manual and the software itself.
[13:42] <sladen> jcisio: are we still debating about whether using the existing translation keys is a good idea, or how one might do it?
[13:43] <jcisio> "how" - I think ;)
[13:43] <jcisio> I just tried to explain why the package name is not neccessary
[14:01] <cnd_mini> How do acls work in the ubuntu filesystem? for example, there's an acl on /dev/snd/controlC0; how does one query its properties or manipulate it?
[14:01] <directhex> i wonder how that happened. my grub on my laptop was really old. like from january old.
[14:02] <joaopinto> cnd_mini, the help channel is #ubuntu :)
[14:02] <cnd_mini> joaopinto: yes, this is a development question
[14:03] <cnd_mini> there's no docs I can find anywhere
[14:03] <joaopinto> not really, unix privileges and file system management in general is support, unless you are developing, which does not seem to be the scope of your question :)
[14:03] <cnd_mini> the only thing I've found close is in /lib/udev/rules.d
[14:04] <cnd_mini> joaopinto: yes, development is my scope,
[14:05] <cnd_mini> specifically, I need to know if there's any kernel dependencies to make acls work in the root fs
[14:05] <cnd_mini> but as a base, I'd just like to know how to do anything with them
[14:07] <joaopinto> file system based ACLs if implemented depend on the corresponding filesystem type support, and there is no such thing as "ubuntu filesystem" ;)
[14:09] <cnd_mini> ok, but how do you query and manipulate them?
[14:11] <statik> dumb question - does toolchain freeze mean that I should wait a bit longer before doing non-toolchain related uploads? or does it mean don't upload toolchain stuff but other packages are ok?
[14:12] <maxb> https://lists.ubuntu.com/archives/maverick-changes/2010-May/thread.html would seem to imply the former
[14:14] <statik> maxb: cool, thanks
[14:14] <Chipzz> cnd_mini: AFAIK the only "ACLs" being used (and note that the usage of the word ACL is improper in this context) in your case are the traditional UNIX ACLs (user/group/other)
[14:14] <Chipzz> and you can check those with a simple ls -l
[14:15] <cnd_mini> Chipzz: if you do ls -l /dev/snd/controlC0, you should see a '+' at the end of the perms
[14:15] <Chipzz> no further ACLs ae used
[14:15] <cnd_mini> apparently, the acls are there, but the default une (maybe desktop too?) doesn't include the acl package
[14:15] <cnd_mini> once I installed it I was able to use getfacl on it to see the acls
[14:16] <geser> cnd_mini: you can query them with getfacl (from the acl package) (and set them with setfacl)
[14:16] <cnd_mini> geser: yep, thanks
[14:16] <cnd_mini> joaopinto got me straightened out with the acl package
[14:18] <geser> Chipzz: some /dev have additional ACLs so the user can have rw access to it without owning the device node or needing to be in the group owning it
[14:19] <cnd_mini> so it appears that the kernel I'm working on doesn't have POSIX_ACLs turned on
[14:19] <cnd_mini> so that's the reason I'm having issues I think
[14:19] <jdstrand> ogra: am I remembering correctly that arm doesn't work super well with qcow2 in qemu?
[14:19] <jdstrand> ogra: hi btw :)
[14:20] <hyperair> 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.
[14:20] <Chipzz> geser: oh. wouldn't that be filesystem dependent then?
[14:21] <cnd_mini> geser: Chipzz: there's a TMPFS ACL option, and tmpfs is used for /dev
[14:22] <geser> Chipzz: yes, but the Ubuntu kernel has them enabled for most FS types (grep POSIX_ACL /boot/config-*)
[15:30] <jibel> cjwatson, psusi, hello, about the ext4 failure, I reported upstream bug http://bugzilla.kernel.org/show_bug.cgi?id=15910 . See if there's anything to add.
[15:34] <tankdriver> Hi, before I add another unuseful "me too" comment to this bug ( https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/353126):  I can reproduce this bug in Kubuntu lucid. But this bug is definely filed as gnome-related. What should I do?
[15:50] <JFo> cjwatson, or slangasek bug 574184 seems to indicate that the DVD images have bad checksums
[15:50] <JFo> just wanted to bring to one of your attention
[15:52] <JFo> not sure what package to assign that to though
[15:54] <apw> yeah no idea what the iso image creator would be
[15:55] <persia> I'd suggest adding an ubuntu-cdimage task to the bug, if it's verified.  That gets it to the larger set of folks that can help sort it.
[15:56] <persia> (and #ubuntu-bugs is an *excellent* place to ask for help getting bugs in the right state)
[15:56] <JFo> persia, :P
[15:57] <psusi> my goodness there's a lot of bugs filed against gparted... time to whack a few
[16:06] <bitshuffler> Hello. Could someone please tell me which package (postinst) is creating /etc/shadow    and friends?
[16:13] <joaopinto> bitshuffler, grep "shadowconfig" /var/lib/dpkg/info/*postinst
[16:13] <bitshuffler> joaopinto: well, problem is I don't run ubuntu here so I have to ask :)
[16:13] <joaopinto> it's: passwd
[16:14] <bitshuffler> joaopinto: sure it isn't base-passwd (that's what #debian said)? (on 10.04 that is)
[16:15] <joaopinto> bitshuffler:
[16:15] <joaopinto> /var/lib/dpkg/info/passwd.postinst:# Run shadowconfig only on new installs
[16:15] <joaopinto> /var/lib/dpkg/info/passwd.postinst:[ -z "$2" ] && shadowconfig on
[16:15] <bitshuffler> joaopinto: that's on 10.04?
[16:15] <joaopinto> yes
[16:15] <bitshuffler> thanks a lot :)
[16:16] <joaopinto> I guess base-passwd will install passwd
[16:19] <aburch> bitshuffler: base-passwd at least creates /etc/passwd and /etc/group.
[16:21] <bitshuffler> ah ok, so if I run into trouble with "chmod: cannot access `/etc/passwd': No such file or directory" it might be cause passwd got installed before passwd. Does that sound logically?
[16:22] <joaopinto> you mean passwd installed before passwd-base :)?
[16:23] <bitshuffler> yeah, right ;D
[16:23] <ogra> jdstrand, (sorry for the late reply, i got sucked into some ARM stuff) qcow2 works with qemu-system-arm, qemu-nbd i had issues with
[16:24] <joaopinto> bitshuffler, installing a new passwd will run shadowconfig on, I assume that chmod error is from shadowconfig
[16:24] <jdstrand> ogra: ok-- I had a weird hang in the guest when using qemu-system-arm with a qcow2 and backing store... have you tried that? are raw images generally ok too?
[16:25] <joaopinto> bitshuffler,  grep chmod /sbin/shadowconfig, chmod 644 /etc/passwd /etc/group
[16:25] <bitshuffler> joaopinto: I think so: http://pastebin.org/203320 (base-passwd get's installed a bit later)
[16:25] <joaopinto> bitshuffler, in short, yes, that is the problem :P
[16:25] <bitshuffler> joaopinto: thanks a lot :)
[16:25] <ogra> jdstrand, i usually use raw, yes, if you see something like bug 532733 it would be awesome to get some more debug info though
[16:26] <ogra> nobody was able to get to the root cause yet
[16:26] <jdstrand> ogra: ok-- it's possible that it was a networking thing, since avahi was being installed in the guest and I was using 'user' net
[16:27] <ogra> ah
[16:27] <jdstrand> (as opposed to tun/tap)
[16:27] <ogra> hmm
[16:27] <ogra> shouldnt though
[16:27] <ogra> it should just do transparent NAT
[16:27] <jdstrand> I'll play with it and report a bug if I can reproduce
[16:45]  * psusi wonders why the hell a fully downloaded lucid dvd iso has holes in it
[16:45] <Pici> psusi: well, there has to be at least one hole for the spindle
[16:46] <psusi> lol
[16:46] <psusi> seriously though, there are still holes in the file long after transmission finished the download
[16:47] <psusi> it's weird... like there must be gaps of all zeroes in the iso image and I guess transmission doesn't bother writing the zeroes to the file?  so the hole remains...
[16:51] <bitshuffler> Ok, if I got that right shadowconfig generates /etc/shadow by calling pwconv which should generate /etc/shadow. What could be the cause that pwconv does _not_ generate /etc/shadow?
[16:52] <bitshuffler> (output of pwconv is nothing, no "x" is in the passwd file - e.g. "root:*:0:0:root:/root:/bin/bash" - which looks fine to me)
[17:03] <joaopinto> bitshuffler, did you check the exit code ?
[17:04] <bitshuffler> joaopinto: sry, how do I do that when I call it in a shell manually?
[17:04] <joaopinto> I am looking at pwconv.c source and there are some predefined exit codes (not described on the manpage)
[17:04] <joaopinto> bitshuffler, command ; echo $?
[17:04] <bitshuffler> joaopinto: shows "1"
[17:05] <joaopinto> #define E_NOPERM        1       /* permission denied */
[17:05] <joaopinto> :)
[17:05]  * bitshuffler is root
[17:05] <bitshuffler> hmmm
[17:07] <bitshuffler> is it normal in ubuntu that "ls -l" doesn't list "." and ".." at the beginning?
[17:07] <joaopinto> bitshuffler, did you check syslog ? I see some syslogging for some errors
[17:08] <bitshuffler> joaopinto: I have no services running (it's a chroot). Only log in /var/log is dpkg.log which I guess is from installation
[17:12] <garet> hello, I am having troubles since lucid upgrade with kerberized NFS my client can't negociate with the server (server is a NAS). gssd reports "No supported encryption types"
[17:12] <garet> it used to work in karmic (and jaunty)
[17:12] <joaopinto> bitshuffler, do you have /dev and /proc bind mounted in the chroot ?
[17:13] <bitshuffler> joaopinto: I can bind them in from the base system (which is suse) if that helps somehow
[17:14] <joaopinto> bitshuffler, I am just guessing because I don't see any explit exit with that E_NOPERM code
[17:14] <joaopinto> and there is an open syslog call at the beginning
[17:14] <bitshuffler> joaopinto: http://pastebin.org/203388 is the strace if that's somehow helpful to you
[17:16] <joaopinto> #
[17:16] <joaopinto> connect(5, {sa_family=AF_FILE, path="/dev/log"}, 110) = -1 ENOENT (No such file or directory) <- might be required, the /dev bind mount should help here
[17:16] <kees> smoser: say, I have ec2 all set up, but I can't figure out how to generate the SSH key I need to log into my instance with.  what's the right incantation?
[17:19] <bitshuffler> joaopinto: with /dev bound in strace is http://pastebin.org/203398
[17:20] <bitshuffler> ah, now I have in my syslog: "pwconv[19447]: cannot open login definitions /etc/login.defs [No such file or directory]"
[17:21] <bitshuffler> which package contains /etc/login.defs on ubuntu?
[17:22] <ogra> bitshuffler, dpkg -S /etc/login.defs ;)
[17:22] <ogra> bitshuffler, its in the login package
[17:23] <bitshuffler> ogra: cheers :)
[17:26] <kees> smoser: ah, nm, realized that ec2 ssh keys aren't shared across regions.
[17:30] <smoser> kees, thats annoying, but yeah.
[17:31] <smoser> also annoying that there is no ec2-upload-keypair
[17:32] <kees> smoser: yeah, now I have two different keypairs.  ;)
[17:33] <Neo--> anyone going to UBS in brussels and would like to share a room in a hostel?
[17:33] <smoser> i name them keypair.<region> and just always invoke with --key keypair.region ,and have ssh config pick the right onw
[17:33] <smoser> one
[17:35] <ScottK> jdong: Would you please ack the revised clamav upload in lucid-proposed (no new bug, just yesterday's upload was missing one commit on the powerpc patch).
[17:38] <bitshuffler> Thanks a lot for your help guys, the only missing thing was the login package and now it's fine :)
[17:54] <kees> smoser: is there a way to poke holes in the ec2 firewall for a single instance (instead of "default")?
[17:55] <smoser> well 'default' is just a "group"
[17:56] <smoser> you can ec2-add-group, delete-group and such
[17:56] <smoser> i could be wron, but i think wonce you've launched an instance its in the group you launched it in for good.
[17:56] <kees> smoser: okay, cool
[17:57] <joaopinto> bitshuffler, great :)
[17:57] <bitshuffler> joaopinto: yeah, thanks for your help :)
[21:17] <pace_t_zulu> hey guys... is this the right place to get an answer about gcc-4.2 on lucid
[21:17] <pace_t_zulu> like why are 4.1,4.3,and 4.4 available but no 4.2
[21:18] <pace_t_zulu> perhaps #ubuntu-app-devel
[21:19] <ScottK> pace_t_zulu: Generally re remove old GCC versions when no more packcages need it to build.
[21:19] <ScottK> re/we
[21:19] <ScottK> So without looking, I'd guess there's still something that won't build with newer than 4.1, but that wasn't the case for 4.2.
[21:24] <pace_t_zulu> ScottK: ty
[21:32] <pace_t_zulu> ScottK: i maintain the MATLAB page on the wiki... MATLAB prefers gcc-4.2 and presents the user with a warning... i currently do not have a work-around - just tell the users to ignore the warning
[21:33] <ScottK> We're using GCC 4.5 in Maverick.  It would be nice if matlab would catch up a bit.
[21:34] <directhex> matlab is, how to put this politely..... trash with a multi-thousand-dollar license fee
[21:34] <ScottK> Very popular in some circles though
[21:35] <directhex> yes, very
[21:35] <directhex> circles that say "i don't care that it's 200x slower than real c++, it's easy"
[21:35] <pace_t_zulu> ScottK directhex i agree
[21:36] <pace_t_zulu> ScottK directhex some people don't have a choice...
[21:36] <JFo> especially if it is a lab requirement
[21:36] <pace_t_zulu> JFo: +1
[21:36]  * JFo 'fondly' remembers matlab
[21:36]  * pace_t_zulu can't escape MATLAB
[21:37] <JFo> heh, my condolences :)
[21:37] <JFo> I have a friend who is in the same boat pace_t_zulu
[21:37] <pace_t_zulu> anyway... it is ridiculous that such expensive software, released this year, doesn't support > gcc 4.2
[21:38] <pace_t_zulu> i just want to provide ubuntu users a satisfactory solution...
[21:39] <pace_t_zulu> the workaround i documented at https://help.ubuntu.com/community/MATLAB#MEX%20functions worked great for versions of ubuntu < 10.04
[21:39] <pace_t_zulu> ScottK: i noticed about maverick earlier... are the maverick repos live yet? i realize it's just the toolchain right now
[21:40] <ScottK> It exists, but uploads aren't being accepted yet.
[21:41] <pace_t_zulu> ScottK: ty
[21:57] <oskie> what's the package called that does the ubuntu installation? i'm doing a debootstrap install and need to know what i need to run post-debootstrap
[21:58] <oskie> the docs here seems a bit outdated: https://help.ubuntu.com/6.10/ubuntu/installation-guide/i386/linux-upgrade.html
[22:00] <apachelogger> ping ping, anyone around who can bump a build scores for me?
[22:05] <pace_t_zulu> oskie: why are you installing that way?
[22:06] <pace_t_zulu> oskie: which version are you trying to install? that URL you are looking at is from 2006 - ancient
[22:10] <oskie> pace_t_zulu: i'm trying to install ubuntu to a NFS-mounted root
[22:11] <pace_t_zulu> oskie: are you "Installing on a NFS-server and using with diskless clients."
[22:11] <oskie> pace_t_zulu: yeah!
[22:11] <pace_t_zulu> oskie: try this URL https://help.ubuntu.com/community/Installation/OnNFSDrive
[22:11] <pace_t_zulu> oskie: that is definitely more current
[22:12] <oskie> ah ok, i'll take a look!
[22:12] <pace_t_zulu> oskie: good luck
[22:13] <pace_t_zulu> oskie: btw... i got that link from here: https://help.ubuntu.com/community/Installation
[22:14] <oskie> pace_t_zulu: it seems none of those pages actually use the default text user interface installer
[22:15] <oskie> either the recommend duplicating a complete installation, or running debootstrap followed by a lot of manual work (all different suggestions from different pages)
[22:27] <pace_t_zulu> oskie: yea... i'm not familiar with what you are doing... just tried to provide some helpful guidance
[22:28] <pace_t_zulu> oskie: maybe #ubuntu-server is where you should be asking this question...
[22:29] <ScottK> It's certainly off topic for this channel.
[22:31] <pace_t_zulu> ScottK: is there a better place for asking my gcc-4.2 question?
[22:31] <ScottK> No, that one was fine.
[22:32] <ScottK> It's the how to install over NFS that's off topic.
[22:32] <ScottK> Nothing to do with development.
[22:32] <ryan22> i would like to proposal a new development model
[22:32] <pace_t_zulu> ScottK: that's why i suggested #ubuntu-server ;)
[22:32] <ryan22> Ubuntu needs a change in direction. I propose that Ubuntu adopt a development model where only the core operating system, userland, core libraries, and desktop environment are frozen every 6 months. The applications would then be freely updated to the newest versions at all time. Package maintenance and support for the end-user applications would be provided by the developers themselves.
[22:33] <ScottK> pace_t_zulu: Yes, it was a good suggestion.
[22:33] <ryan22> more info here: http://www.linuxquestions.org/questions/linux-distributions-5/ubuntu-needs-a-new-development-model-806162/
[22:33] <pace_t_zulu> ryan22: hmm
[22:33] <ryan22> i call it the semi-rolling release system
[22:34] <ryan22> the stability of debian with the flexiblity of gentoo
[22:34] <ScottK> ryan22: I'd recommend you right about it on the ubuntu-devel-discuss mailing list.  That's a more appropriate way to bring things like that up.
[22:34] <ion> Yeah, it will be awesome when stuff breaks at unpredictable times.
[22:34] <ryan22> thanks
[22:34] <pace_t_zulu> ion: +1
[22:35] <geser> ryan22: and upstream has the manpower (and knowledge) to take care of their packages in Ubuntu?
[22:35] <ryan22> ive implemented it in my distro (infinityOS) and it has worked perfectly for 2 months
[22:36] <ryan22> the new packages would be pushed from the dev PPAs
[22:36] <geser> how many upstream participate?
[22:36] <ryan22> i just use the dev PPAs
[22:36] <ryan22> it takes me about a hour a week to maintain
[22:37] <geser> what about libraries that aren't part of core?
[22:37] <ryan22> it depends on the library
[22:38] <pace_t_zulu> ryan22: nothing stops developers from having their own repos and following your model
[22:38] <ryan22> i actually did that myself
[22:38] <pace_t_zulu> ryan22: ubuntu is simply providing users with packages that have been tested against particular releases
[22:38] <ryan22> https://launchpad.net/~infinityos
[22:39] <ryan22> i believe ubuntu rlease should be refoactored into being just a core os that launchpad builds against
[22:39] <ryan22> a specification
[22:40] <pace_t_zulu> ryan22: you'd rather ubuntu developers do less...
[22:40] <ryan22> so they can do more with the core
[22:40] <pace_t_zulu> ryan22: ubuntu is not lacking the core you describe
[22:40] <ion> How do you guard against e.g. config syntax changes or other maintenance required by new upstream releases during upgrades within the same distro release?
[22:40] <ryan22> i have 3 tires inspired by debian
[22:41] <ryan22> stable, testing, and unstable
[22:41] <ryan22> the packages go into testing or unstable depending on the their stability and depenencies
[22:41] <pace_t_zulu> ryan22: do you think debian should do the same?
[22:41] <ryan22> yes
[22:41] <ryan22> my system works and my users love it
[22:41] <geser> from how many dev PPAs do you pull the packages?
[22:41] <ryan22> 20ish
[22:42] <pace_t_zulu> ryan22: maybe you should start with the debian developers... i hear they are very receptive ;)
[22:42] <ryan22> maybe
[22:42] <ryan22> where would i find them
[22:44] <ryan22> i know alot of times devs hang out in private rooms
[22:44] <geser> ryan22: do you believe this would still work with several thousands? universe has currently around 13k source packages (and universe is pretty non-core)
[22:45] <ryan22> as it takes me only hour a week to maintain it, i feel that it would scale gracefully
[22:46] <geser> but the potential for conflicts is with 20 PPAs much smaller than with 1000 PPA (or even more)
[22:46] <pace_t_zulu> ryan22: maybe you should bring this up once you have 1000+ packages and a stable release
[22:46] <ryan22> i will have a a stable release in a matter of weeks. my gfx designer is in his finals, so im waiting on my branding
[22:46] <geser> so you would need some coordination, especially for non-core libraries that are yet used by several packages
[22:47] <ryan22> definitely
[22:47] <ryan22> but the debian infrastucture would be more than sufficient
[22:48] <pace_t_zulu> ryan22: so your proposal, in theory, is easier to maintain than ubuntu?
[22:49] <ryan22> yes
[22:49] <zyga> ryan22: I think it could work only in one case
[22:49] <zyga> ryan22: that you don't do anything
[22:49] <ryan22> it takes much better advantage of the scale of the ubuntu/debian community
[22:49] <zyga> ryan22: just do the core and ask the upstream to package and release
[22:49] <pace_t_zulu> ryan22: what's stopping you from beating ubuntu devs at their own game... you would, in theory, need less manpower
[22:49] <zyga> ryan22: and provide an app store PPA for them to publish their stuff into
[22:49] <ryan22> well i can of am actually
[22:50] <ryan22> and thats what im planning on doing
[22:50] <zyga> ryan22: but you said that right now _you_ do the packaging and merging/etc
[22:50] <zyga> ryan22: that simply does not scale
[22:50] <pace_t_zulu> ryan22: so are you here to put the ubuntu developers on alert then?
[22:51] <zyga> ryan22: if you want upstream to participate then you have to convince them to package their stuff for one-more-system because it's good-and-all, that's not going to work
[22:51] <ryan22> i am here to suggest you adopt my idea as i now greatly imbeeded in the interests of ubuntu
[22:51] <ryan22> my proposal to convert my univeristy (trent university) to ubuntu has been accepted
[22:51] <pace_t_zulu> ryan22: i think the suggestion has been noted
[22:51] <zyga> ryan22: I'm sure everyone appreciates that you want to improve user experience and that you like ubuntu
[22:52] <pace_t_zulu> ryan22: your ambition is impressive
[22:52] <ryan22> http://tinyurl.com/excalibur-proposal http://tinyurl.com/excalibur-screens
[22:52] <zyga> ryan22: but making changes like that requires serious coordination, it's not something you do overnight, if you want it accepted you need to put some effort and endure the pain it takes to do so for 2-3 years
[22:52] <ryan22> i have universal support from the faculty and now i am supported by the administration and faculty
[22:52] <pace_t_zulu> ryan22: what is ExcaliburOS?
[22:53] <pace_t_zulu> ryan22: i commend your efforts to spread ubuntu
[22:53] <zyga> ryan22: and worse, you have to convince everyone it's better, otherwise you'll get ignored, it's a code-speak game [un]fortunateluy
[22:54] <ryan22> my custom ubuntu based distribution for my univertsity. i am aiming for it to be installed alongside windows in the computers in the computer science and mathematics dept in sept
[22:54] <ryan22> lol ya alot of these reasons are why i am now calling infinityOS the firefox to ubuntu's mozilla
[22:54] <YokoZar> jcastro: is the UDS roommate situation finalized yet?
[22:55] <pace_t_zulu> ryan22: good luck... please keep the enthusiasm up :)
[22:57] <ryan22> perhaps i should keep infinityOS and its release system separate for now from upstream (meaning ubuntu)
[22:58] <ryan22> however i would fully welcome canonical support
[23:00] <jcastro> YokoZar, I don't know about roomates
[23:01] <jcastro> YokoZar, also plenaries are full, can you make yours a 5 minute lightning talk instead?
[23:01] <YokoZar> jcastro: what is this
[23:01] <YokoZar> jcastro: I registered first :(
[23:02] <YokoZar> jcastro: but ok whatever
[23:02] <jcastro> yeah there is some special guest coming on tuesday and is hogging a bunch of slots
[23:02] <jcastro> ... or we can cancel lightning talks
[23:03] <YokoZar> Also the title is gonna be different  I have way more than "not suck" to show ;)
[23:04] <jcastro> I guess you're going to have to cram and talk much faster!
[23:05] <YokoZar> All right then
[23:05] <zyga> YokoZar: sorry to eavesdrop but is there any information about roomates anywhere on the wiki?
[23:06] <jcastro> YokoZar, mail marianna and ask her if she can just post it on the wiki or something
[23:08] <YokoZar> jcastro: done
[23:13] <Airells> looking for good socket lib , any suggestions ?
[23:14] <ion> socket(2)
[23:16] <YokoZar> also jcastro I hope this is very exciting on Tuesday because an hour long plenary is a long time
[23:17] <Airells> ion you mean popular "socket.h" lib?
[23:18] <hdon> hi all. so i ran "apt-get source gnome-applets" to get the source code for multiload-applet. but when i run ./configure it says "Your intltool is too old. You need intltool 0.35.0 or later." is there a package in Jaunty that provides this?!
[23:23] <hdon> looks like it's intltool-debian
[23:23] <hdon> well that didn't work
[23:23] <hyperair> does anyone here use sbuild + ccache?
[23:23] <hyperair> i'm getting a crapton of cache misses
[23:24] <hdon> oh maybe i didn't have *any* intltool installed
[23:24] <hdon> looks like it likes the one that comes from the package "intltool"
[23:24] <hdon> lol
[23:32] <zyga> hyperair: no luck with finding what caused them?
[23:32] <hyperair> zyga: =(
[23:33] <hyperair> zyga: i've exhausted many things already, including HASHDIR, UNIFY, among others
[23:33] <zyga> hyperair: can you post the log file to a pastebin?
[23:33] <ryan22> well good luck everyone
[23:34] <hyperair> zyga: there's nothing interesting in there. just a whole bunch of "Placed ____.o into cache"
[23:34] <zyga> hyperair: mmm
[23:35] <zyga> hyperair: out of curiosity, why are you using ccache with sbuilder?
[23:35] <zyga> hyperair: I'm willing to write a gcc wrapper with extra feature and I'd like to know if it would be useful
[23:36] <hyperair> zyga: because in the event of a failed long build, i can just get right back there almost immediately
[23:36] <hyperair> zyga: it worked wonderfully with pbuilder.
[23:36] <zyga> mmm, okay - makes sense
[23:36] <zyga> why sbuilder then?
[23:36] <hyperair> cache hit                          39377
[23:36] <hyperair> cache miss                         22770
[23:36] <zyga> mabe it's messing something
[23:36] <zyga> oh
[23:36] <zyga> then you _did_ hit something :-)
[23:36] <hyperair> that's pbuilder!
[23:36] <zyga> can you ask ccache to print each cache miss command?
[23:36] <hyperair> the sbuild one... has
[23:36] <hyperair> cache hit                            212
[23:36] <hyperair> cache miss                          1543
[23:37] <zyga> it's quite easy at the source level, I was doing that once recently
[23:37] <hyperair> er how?
[23:37] <zyga> just rebuild ccache with one more printf
[23:37] <ryan22> i was wondering if anyone has thought of removing pulseaudio from ubuntu
[23:37] <ryan22> i have removed completely from infinityos by request of my users
[23:37] <zyga> ryan22: if you have more ideas please post them to the mailing list
[23:37] <ryan22> no prob
[23:38] <ryan22> thanks for pointing me in the right direction
[23:39] <zyga> ryan22: it's not about posting crazy ideas, it's about posting crazy ideas to more than 10~ people currently watching
[23:39] <kyle__> hey there i wonder if anyone could help me out? i am trying to patch a ps3 camera in and am following a guys terminal guide but have hit a dead end. Help??
[23:39] <ryan22> zyga: rember the crazy idea are often the ones that gain you users ;P
[23:40] <zyga> kyle__: try #ubuntu, this channel is not for support
[23:40] <kyle__> k thanks