[00:13] <andreserl> howdy!! Library packages are not supposed to have Depends on ${python:Depends}, or are they?
[00:50] <ScottK> andreserl: Please don't ask the same questions in multiple channels just a few minutes apart.
[01:43] <mnajem> anybody experienced problem using gnash on maverick?
[01:43] <mnajem> mnajem got it using CPU usage almost 100%
[01:44]  * RAOF wonders how that's different to the regular flash player…
[01:45] <mwhudson> can someone remind me/point me to the documentation of what's special about the "metapackages" section?
[01:45] <RAOF> mnajem: Likely you'll want to file a bug, particularly if you can find a reproducible way of making it misbehave.
[01:45] <andreserl> ScottK, just noticed that question was more appropriate for -motu that's why I repeat the question there
[01:45] <ebroder> mwhudson: I don't know about docs, but I think it's implemented by a file in /etc/apt/apt/conf.d
[01:46] <mnajem> RAOF, thanks
[01:46] <ScottK> andreserl: In that case, it'd be nice to mention it in the first channel so multiple people don't consider answering the same question.
[01:47] <andreserl> ScottK, ok :) I'm answering in -motu now
[01:47] <ScottK> OK
[01:48] <mwhudson> ebroder: thanks, so it seems my next question is "what does Never-MarkAuto-Sections mean" :-)
[02:03]  * sanchaz off to bed
[03:02] <andreserl> kirkland, ping?
[03:02] <kirkland> andreserl: hi
[03:03] <andreserl> kirkland, howdy!! quick question :). Ok so I've got another action for powernap.
[03:03] <kirkland> andreserl: k
[03:03] <andreserl> kirkland, In lower power state, I change the CPU governor from ondemand to powersave, which sets the CPU freq to 800MHz. Do you know if it is possible to even set it lower by hardcoding the frequency?
[03:04] <kirkland> andreserl: it's not possible
[03:04] <kirkland> andreserl: i'm pretty sure that that should already be covered by pm-powersave
[03:04] <kirkland> andreserl: ie, i don't think you need to do that one
[03:05] <andreserl> kirkland, there doesn't seem to be any script that actually does that
[03:05] <andreserl> so that's why I did it
[03:05] <andreserl> I'll ask pitti tomorrow :)
[03:06] <kirkland> andersk: ah, okay, then yeah, that's a good one
[03:06] <kirkland> andreserl: ^
[03:07] <andreserl> kirkland, but for example, when it is ondeman it will allow the CPU to automatically change the frequencies. If I set it to powersave, it will stay in 800Mhz always
[03:07] <kirkland> andreserl: cool
[03:07] <andreserl> kirkland, ok then :). Anyways, other than that, now that this scripts will be in pm-powersave, Should I still keep the feature to be able to enable/disable scripts, and list which ones are enabled/disabled?
[03:08] <kirkland> andreserl: nah
[03:08] <kirkland> andreserl: i don't think it's necessary
[03:08] <kirkland> andreserl: if it is, it probably belongs in pm-utils
[03:12] <andreserl> kirkland, ok then :) thanks for the input. Btw.. I presented it yesterday in class and professor was very satisfied with it
[03:17] <kirkland> andreserl: great!
[03:19] <andreserl> kirkland, They were asking me so many questions about it, that I ended up explaining the whole project instead of just the part that was supposed to be done for the course project.
[03:19] <kirkland> andreserl: heh
[03:19] <kirkland> cool
[04:05] <hdon> hi guys. i have a rather technical question: i am sshing into a Solaris system at work using gnome-terminal. keys like control+arrowkey don't work. how do i start to troubleshoot this problem? it's been causing me a lot of grief
[06:28] <dholbach> GOOD MORNING!
[09:06] <geser> can someone please accept the nomination for maverick in bug 617885 so it doesn't vanish from the sponsoring queue
[11:39] <cjwatson> geser: done
[14:07] <barry> ScottK: morning.  i was off on another desktop for a bit.  py3.2 is not building?
[14:10] <cjwatson> jelmer: did bzr-svn 1.0.3 affect compatibility with previous mappings?
[14:11] <cjwatson> jelmer: I have a (fairly important and complicated) branch which I believe I last pulled using 1.0.2; 1.0.3 now says "These branches have diverged"
[14:11] <jelmer> cjwatson: no, the mappings haven't changed since 0.4.x IIRC
[14:12] <cjwatson> jelmer: if you have a moment, it would be great if you could have a look at lp:~cjwatson/debian-installer/main vs. svn://svn.debian.org/svn/d-i/trunk/installer - I'm not sure how to investigate further
[14:12] <jelmer> cjwatson: what does "bzr missing" say about the differences?
[14:12] <jelmer> cjwatson: I'll have a look
[14:13] <cjwatson> jelmer: it says there are no common revisions
[14:14] <cjwatson> missing back to r1 both sides
[14:14] <cjwatson> it also had to completely refetch the svn branch when I did 'bzr pull' earlier
[14:18] <directhex> builds are broken right now, yes?
[14:20] <cjwatson> directhex: hmm?
[14:21] <directhex> oh, perhaps not. was misreading the log
[14:23] <cjwatson> well, happy to look if you spot something
[14:30] <Laney> a mere bashism
[15:08] <pitti> kirkland: overheard @ plumbers: PROC_EVENTS
[15:09] <pitti> kirkland: that can be used to get notifications about new procsses, forks, etc., for the server powernap thingy we discussed
[15:09] <pitti> kirkland: so, we wouldn't need to poll any more
[15:09] <pitti> http://lwn.net/Articles/157150/
[15:09] <pitti> kirkland: I haven't researched details yet
[15:09] <cjwatson> is that the same as the netlink proc connector?
[15:09] <seb128> cjwatson, do you mind if I assign bug #662276 to you? it seems you usually do the vim merges in Ubuntu
[15:09] <cjwatson> yes, apparently so
[15:09] <pitti> cjwatson: presumably yes
[15:09] <seb128> cjwatson, geser did the work, it just needs review and sponsoring
[15:10] <pitti> cjwatson: I just wasn't aware of this before
[15:10] <cjwatson> seb128: it's already queued in my browser, at geser's request; go ahead
[15:10] <pitti> it's not race free, thus not suitable for upstart & friends
[15:10] <seb128> cjwatson, ok thanks, I'm just tried to clean the sponsoring queue a bit
[15:10] <cjwatson> I'm trying to get natty builds working as a priority, that's all
[15:10] <cjwatson> cyphermox: any luck with dhcp?
[15:11] <pitti> kirkland: /usr/src/linux-headers-2.6.36-1/include/linux/cn_proc.h is the API
[15:11] <cyphermox> cjwatson, I haven't had time to get back to it, but I will in a few minutes... afaik it's good now as soon as I upload NM with the added Breaks and give it a quick test
[15:12] <cjwatson> music to my ears
[15:13] <cyphermox> cjwatson, I already have a scratch system upgraded to natty so I can try the ppa
[15:21] <ebroder> pitti: how is proc connector race-y? Because I think Keybuk was talking about using it to deal with some double-forking issues in upstart
[15:22] <Keybuk> it sounds like pitti has been listening to lenny
[15:22] <pitti> ebroder: I don't know the details; Lennart just said that it's not the right thing to use for pid 1; perhaps they don't get queued properly, so that you miss events when you don't get scheduled in for a while
[15:23] <pitti> but as I said, IANAKD, and only parrotting here
[15:23] <pitti> but either way, it seems more than appropriate for powernap
[15:24] <Keybuk> Lenny is wrong, fwiw
[15:25] <ebroder> the last time I used the proc connector, my monitoring process was getting woken up frequently enough that it caused a performance hit - I had to add some code to only process events after they'd spent some amount of time queueing
[15:26] <Keybuk> that's because it's a bit of a firehose
[15:26] <Keybuk> and includes all clone() calls, not just fork() ect.
[15:26] <Keybuk> so you get notifications as threads come and go as well
[15:26] <ebroder> right, right. and to be clear, when i talk about a performance hit, i'm talking about a hit on running ./configure on something :)
[15:27] <Keybuk> so you use the socket filter api over top of it, so you just get the events you're actually interested in
[15:36] <cjwatson> ebroder: clearly, you should run ./configure on Cygwin instead, since it has none of these advanced APIs!
[15:43] <ScottK> barry: https://launchpad.net/ubuntu/+source/python3.2/3.2~a3-2
[15:47] <pitti> ebroder: the current powernap uses polling (like 20 times a second), which hardly sounds more efficient
[15:48] <ebroder>  sure. I had no idea there was a socket filtering api. it looks awesome
[15:59] <RoAkSoAx> pitti: Do you have some free time to review a library split for cluster-glue?
[15:59] <pitti> RoAkSoAx: not this week, sorry (i'm on a conference)
[15:59] <RoAkSoAx> pitti: ok no prob :)
[16:11] <jelmer> cjwatson: Still there?
[16:11] <jelmer> cjwatson: I've pulled down those two repositories and am looking at them at the moment.
[16:12] <cjwatson> jelmer: here
[16:12] <Lonewulf> Hi I am having trouble with 10.04 and a CQ50-110US laptop any help.
[16:12] <jelmer> cjwatson: it appears as though the first branch was still using the old (pre-bzr-svn 0.4) style mappings.
[16:12] <cjwatson> ah, that's possible, I created it a long time ago
[16:12] <jelmer> cjwatson: did you perhaps change machines, or did you move the branch?
[16:13] <cjwatson> the initial import was in November 2007
[16:13] <jelmer> cjwatson: newer versions of bzr-svn would still have used the older style mappings if they were configured to do so
[16:14] <cjwatson> I've switched disks since then, but I did a full-system restore
[16:15] <cjwatson> http://paste.ubuntu.com/525745/ - contents of ~/.bazaar/subversion.conf
[16:15] <cjwatson> still seems to be configured there
[16:15] <cjwatson> I don't think I moved it in the filesystem.  What's the UUID of?
[16:16] <jelmer> cjwatson: it's the UUID of the remote subversion repository
[16:17] <cjwatson> I would be surprised if that had changed, but I suppose it's possible - how would I check?
[16:17] <jelmer> cjwatson: 'svn info svn://svn.debian.org/svn/d-i' should tell you
[16:17] <jelmer> it doesn't seem to have changed though
[16:18] <jelmer> so maybe this is a regression in bzr-svn's backward compatibility support
[16:18] <cjwatson> I'm happy to try the version in natty if you think that would help, or try other debugging
[16:27] <jelmer> cjwatson: I'm currently checking if I can reproduce it here (trunk) with your configuration
[16:30] <cjwatson> ta
[16:34] <Wubbbi> Hi guys ;D
[16:41] <Lonewulf> My Nvidia 8200M G does not do compositing....For what ever reason.
[16:43] <nemo>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
[16:43] <nemo>  1280 root      20   0 1293m 843m 274m S    4 22.0 495:25.71 Xorg
[16:43]  * nemo sighs
[16:52] <kirkland> pitti: sweet!
[16:53] <kirkland> RoAkSoAx: see PROC_EVENTS from pitti, http://lwn.net/Articles/157150/
[16:53] <kirkland> pitti: that's pretty awesome
[16:55] <nemo> 00b4e000-25362000 rw-p 00000000 00:00 0                                  [heap]
[16:55] <nemo> hm
[16:56] <nemo> I guess I could try a gdb dump of that...
[17:01] <nemo> damn. tried attaching to the process and Xorg went wild.  now uses 100 megs more of memory and 100% of CPU
[17:02] <nemo> appears to be ignoring gdb's request to suspend
[17:08]  * nemo sighs and kills it
[17:08] <nemo> so today's attempt to figure out my massive Xorg leak in maverick, once more driven back
[17:08] <RoAkSoAx> kirkland: ok will take a look at it :)
[17:08] <nemo> heh. gdm stop failing
[17:09] <nemo> hard kill time
[17:09] <nemo> -2 ignored, -4, on to -9
[17:11] <RoAkSoAx> kirkland: so we could change the process monitor to use that instead of examining the process table. and not do it through upstart?
[18:01] <barry> TheMuso: hi!  say, if you have some time, ScottK recommended that i chat with you about maverick on my powermac g5 dual 2.7.  i'm trying to get a ppc box up - it actually installed fine, but seems to be very unstable when running under maverick
[18:02] <ScottK> barry: I should have mentioned that there is #ubuntu-powerpc too.
[18:02] <barry> ScottK: ah, that's probably a better place to ask.  /me joins and re-posts
[18:36] <cjwatson> first d-i installation images for natty are up, but don't bother testing them, there's a fatal udpkg bug.  fixed upstream and will trickle down tomorrow or so
[18:36] <cjwatson> (no CD images yet)
[18:37]  * SpamapS relaxes the trigger finger poised over his wget window...
[18:37]  * highvoltage is itching for cd images
[18:37] <SpamapS> highvoltage: maybe try baby powder for that?
[18:37] <highvoltage> SpamapS: well, I upgraded to Natty on my laptop and that helped a bit
[18:38] <SpamapS> So.. has anyone seen chromium's method of source distribution and dependency specification.. they're pretty much throwing tarball out the window in favor of svn repository@revision
[18:39] <cjwatson> a lot of that's just an artifact of how the internal repository management stuff works at google
[18:40] <SpamapS> http://src.chromium.org/viewvc/chrome/releases/9.0.572.0/DEPS?revision=65042&view=markup
[18:42] <SpamapS> It does not jive well with making packages. :-P
[18:43] <cjwatson> no reason you couldn't generate tarballs as an archive format from svn repository@revision
[18:43] <persia> SpamapS, You might want to look at some of fta's scripts to handle that sort of thing.
[18:47] <SpamapS> Indeed, it seems the only traditional "release" that is provided is these DEPS files ..
[18:48] <SpamapS> So.. hmm.. create a tarball with the svn revno pointed to...
[18:48] <SpamapS> persia: http://people.ubuntu.com/~fta/chromium/
[18:48] <SpamapS> persia: that stuff?
[18:48] <persia> SpamapS, Well, the stuff that generates that stuff (and the daily builds and the license-analysis tools, etc.)
[18:49] <persia> Catch fta and he can likely tell you lots more about them.
[18:50] <SpamapS> fta: when you have a moment, I'd love to discuss your tools for extracting/handling chromium sources for building packages (I will send an email too)
[18:50]  * SpamapS understands fta is probably past EOW for the day.
[18:51] <fta> SpamapS, hi. no, i'm still here. what do you want to know?
[18:52] <SpamapS> fta: so I'm wanting to build mod_pagespeed .. which depends on the depot_tools from chromium...
[18:52] <SpamapS> fta: seems like there are a whole bunch of hoops to jump through to get all of this packaged in a traditional manner.
[18:53] <SpamapS> fta: persia suggested that you may have gone through some of this pain already.
[18:53] <fta> SpamapS, not really, assuming you have the correct DEPS file in your project
[18:54] <fta> it's kind of easy once you have depot_tools, you need to call gclient
[18:54] <SpamapS> fta: right, so shouldn't depot tools be a package?
[18:55] <fta> SpamapS, well, so far, it was just used by chromium
[18:55] <SpamapS> I don't want to build it just to play with it.. I really want to package it the right way. But its hard to know what the version of depot_tools is.
[18:56] <SpamapS> I'm happy just working backward, and making the version the revno that is pointed to by my DEPS file ...
[18:56] <SpamapS> fta: is depot_tools included in a binary package already?
[18:56] <fta> SpamapS, it's small enough to be carried. there's no release for this i'm afraid
[18:57] <persia> Could we create a "release" sequence to prevent code duplication?
[18:57] <fta> sure
[18:58] <fta> i already did it for gyp
[18:58] <fta> as i needed it for at least 2 packages
[18:58] <SpamapS> Version: 0.1~svn840-0ubuntu1
[18:58] <fta> yep
[18:58] <SpamapS> so just make a chromium-depot-tools 0.1~svnXXXX
[18:58] <fta> but it doesn't include depot_tools
[18:59] <fta> upstream will hate me if i do that
[18:59] <fta> :)
[19:02] <SpamapS> wait.. so.. chromium's build process seems to do svn co's ..
[19:02] <SpamapS> how does that work on a buildd?
[19:02] <SpamapS> oh wait thats just in gos
[19:03] <SpamapS> aha, so the magic is in get-original-source .. ok its making sense to me now
[19:03] <persia> SpamapS, We can always create a tarball from a known revision (and there are good scripts to automate this)
[19:05] <SpamapS> since src/depot_tools is already in the chromium source.. we can just create a chromium-depot-tools package and install it..
[19:05] <persia> Wait: what's the bit about upstream hating this?
[19:06] <SpamapS> I'm not sure they would hate this part
[19:06] <micahg> SpamapS: you should be careful with that as chromium has a micro-release exception, so the tools will change in a stable release
[19:07] <SpamapS> micahg: I think thats ok. Things that build-depend on the tools currently all suggest as a first step 'svn co tool_url/trunk'
[19:07] <persia> micahg, That's fungible, to a certain degree.
[19:07] <fta> SpamapS, i do something like this: http://paste.ubuntu.com/525875/
[19:07] <SpamapS> fta: why do all of the packages in chromium pre-depend on lzma btw?
[19:08] <fta> SpamapS, because my debs are compressed with lzma, and if you don't have it, bad things will happen
[19:08] <micahg> persia: right, but people might be shocked if they can non longer regenerate a source for a package in a stable release due to the depot_tools changing
[19:08] <SpamapS> fta: ahhh good to know
[19:09] <hdon> hi guys. i have a rather technical question: i am sshing into a Solaris system at work using gnome-terminal. keys like control+arrowkey don't work. how do i start to troubleshoot this problem? it's been causing me a lot of grief
[19:09] <hdon> i say "technical" but i guess what i mean is old-school. the new school users with their GUIs for everything would probably have no idea where to begin
[19:10] <SpamapS> hdon: #ubuntu-server may be a better place to ask. :)
[19:11] <fta> persia, upstream hated me when i split gyp from chromium, it was not meant to be used outside of chromium, yet it's perfectly usable outside
[19:11] <hdon> SpamapS, thanks !
[19:11] <SpamapS> fta: even though its being used all over the place now.. page-speed.. mod_pagespeed.. all using gyp and gclient
[19:12] <fta> SpamapS, didn't know it. i'm glad to hear it. are those all google stuff?
[19:13] <SpamapS> fta: yes
[19:13] <fta> ok, makes sense
[19:13] <SpamapS> I'd really like to get mod_pagespeed into natty and backport it to lucid so that people don't have to get a binary only .deb from google
[19:15] <persia> Best place to start is probably a discussion with upstream to make sure there is shared agreement on how the pieces work together.
[19:17] <SpamapS> Their build instructions are pretty uniform.. svn co whatever the latest depot_tools are .. add them to your PATH .. type gclient..
[19:18] <persia> Sure, but if multiple projects are sharing the same dependencies, and they want to have feature changes or API shifts in the dependencies, they must have a way to track them, which system, if we used, would probably make our offerings less offensive.
[19:19] <SpamapS> the gclient script even runs svn up on the dir if it can.
[19:20] <SpamapS> persia: from what I'm seeing.. they're pretty much in the "the latest crack is the only crack" mode for these tools..
[19:20] <fta> yes, it's doing a lot of magic.. too much for my taste. that's why i added the --nohooks
[19:21] <SpamapS> They do lock it down with the other bits though.. just not this particular one.
[19:22] <fta> otherwise, it runs gyp which needs all the -dev packages installed.. which i don't have/want in the box i use to create my tarballs
[19:24] <SpamapS> The wrapper for gclient seems to just be concerned with getting the latest crack..
[19:26] <SpamapS> or .. maybe we should just get out of upstream's way and put this in multiverse. :-P
[19:26] <persia> SpamapS, multiverse doesn't help with the security aspects, and it's only for non-free software anyway.
[19:26] <cjwatson> indeed.  multiverse is not a dumping ground for stuff that's just bad.
[19:28] <SpamapS> Right, the question is.. when upstream wants their stuff updated every time it runs... can we accomodate that?
[19:29] <micahg> SpamapS: -backports?
[19:29] <micahg> SpamapS: every time it runs?
[19:30] <persia> We don't do runtime updates: fails the case where there is no internet access (consider a small LAN on the moon: latency to upstream is too painful)
[19:30] <SpamapS> http://src.chromium.org/viewvc/chrome/trunk/tools/depot_tools/gclient?revision=63234&view=markup
[19:31] <SpamapS> update_depot_tools updates everything from svn
[19:31] <fta> and?
[19:31] <SpamapS> persia: agreed. Your point about talking with upstream is I think even more important.
[19:32] <fta> SpamapS, i just use it in my get-orig-source rule, which happens on my side, before i send the source package to the builder
[19:32] <SpamapS> fta: right, but thats going to violate debian policy (maybe its ok in ubuntu?) if I do that for mod_pagespeed.
[19:33] <SpamapS> No embedding of convenience copies of source code IIRC.
[19:33] <SpamapS> http://www.debian.org/doc/debian-policy/ch-source.html section 4.13
[19:33] <fta> having a separate package for that is not needed. would even make my life even harder as it's one more dep to track and to update along with chromium for lucid up to natty for each release
[19:34] <SpamapS> hmmm actually.. the wording is different than I remembered it..
[19:34] <SpamapS> "packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way"
[19:35] <fta> was already though enough to get the SRU expection for chromium, its codecs and gyp. I don't want to return there ask for another tiny bit ;)
[19:35] <fta> tough
[19:36] <SpamapS> right, I'm thinking more than the chromium package can just spit out its version of depot_tools as a binary package.. and then we just rally around that.
[19:36] <SpamapS> s/than/that/
[19:37] <fta> btw, chromium also provides a real tarball, something like 2GB compared to my already huge 180MB stripped tarball
[19:37] <fta> some distros requested it, so they don't have to fight with svn
[19:38] <fta> but it's regularly broken
[19:38] <SpamapS> I like the get orig source method.
[19:38] <SpamapS> it makes perfect sense.
[19:38] <fta> i like it too, but most people hate me for this
[19:38] <persia> SpamapS, The no-convenience-copies bit is mostly a maintainability thing: when things aren't used elsewhere, nobody cares that much.  See libgyp as an example: once there were two users, it needed to get split.
[19:39] <ivoks> i might be wrong, but i think our LSB is broken
[19:39] <ivoks> killproc doesn't work
[19:39] <persia> ivoks, What gives you that impression?
[19:40] <ivoks> persia: :
[19:40] <ivoks> killproc KILL /usr/sbin/corosync
[19:40] <ivoks> /sbin/start-stop-daemon: signal value must be numeric or name of signal (KILL, INT, ...)
[19:40] <ivoks> without a signal, it returns 0, but the process is still running
[19:40] <cjwatson> it's documented as killproc pathname [signal]
[19:40] <cjwatson> /usr/share/doc/lsb-base/README.Debian.gz
[19:41] <SpamapS> fta: so if I sent you a patch to have chromium output gclient as a binary package, would you be alright with that?
[19:41] <ivoks> cjwatson: same results
[19:41]  * fta should make some tests to see if xz is faster than lzma.. lzma takes ages to compress my tarballs :(
[19:41] <ivoks> it doesn't kill it
[19:42] <cjwatson> I know no more.  (It seems to be the other way round in this SuSE man page I found under a rock, though ...)
[19:42] <cjwatson> you could just use pkill
[19:42] <ivoks> in suse/redhat it works in a way that it sends TERM, waits
[19:42] <ivoks> then if it doesn't exit, sends KILL
[19:43] <ivoks> if signal is specified, it sends signal and exits (without waiting for the results)
[19:43] <elmo> ivoks: is this hardy by any chance?
[19:43] <ivoks> it's lucid
[19:43] <elmo> ah, ok
[19:44] <ivoks> and we get this for free :)
[19:44] <ivoks> /sbin/start-stop-daemon: warning: this system is not able to track process names
[19:44] <ivoks> longer than 15 characters, please use --exec instead of --name.
[19:45] <micahg> fta: you might also want to check lzip
[19:45] <ivoks> (by using killproc)
[19:46] <fta> SpamapS, ..i don't particular the idea of a system gclient. it's already proven weak several times, creating incomplete and unusable tarballs, like when google changes the format of the DEPS files, that's why there's no upstream release, forced me to do XX+0 fake versions :(
[19:48] <fta> micahg, tought about xz because it superseded lzma, and broke my backports in the process
[19:48] <SpamapS> fta: well crap!
[19:48] <SpamapS> fta: actually
[19:49] <SpamapS> fta: then that suggests its more like a generated configure/aclocal.sh script than stable system tool.. and probably doesn't need to be packaged.. yet.
[19:49] <fta> micahg, (because tar -c --lzma -f creates a xz file on maverick which can't be opened on hardy with the same command which really expects lzma)
[19:50] <fta> SpamapS, not exactly, configure/auto* is more equiv to gyp. gclient is a source fetcher, capable of running hooks, incl gyp
[19:51] <fta> and it's a moving target
[19:51] <persia> !ohmy > SpamapS
[19:51]  * SpamapS just mispelled the common fish.. he swears!
[19:52] <ion> “crap” warrants !ohmy? :-)
[19:52] <ion> Everybody craps.
[19:52] <micahg> fta: ok, I guess you have to wait another 6 months to upgrade to lzip
[19:52] <persia> ion, Only once in a while.
[19:52] <micahg> ion: no, craps is a gambling game in Vegas
[19:53] <fta> eheh
[19:53] <SpamapS> fta: given that chromium would spit it out, only to support a few of the other bits building.. I think the other bits can adapt to chromium's massiveness...
[19:54]  * fta attempting one more time to land the launchpad translations into chromium...
[19:54] <fta> drum rolls..
[19:55] <fta> SpamapS, another reason i'm reluctant is that i do tons of builds: http://people.ubuntu.com/~fta/ppa-dashboard/chromium-daily.html
[19:55] <fta> (and i have to fix the new beta too, damn)
[19:56] <fta> (and the prepare the new stable too)
[20:01] <fta> grrr, failed. a translator turned a "<!-- -->" into "<!- ->" making a xml.sax parse error :(
[20:03] <ebroder> There are comments in translatable strings?
[20:05] <persia> ebroder, Consider rather that there may be translatable comments being exposed to users.
[20:05] <ebroder> persia: That sounds like they're no longer comments
[20:06] <persia> ebroder, use/mention.  It's a comment *as part of the UI*, rather than a comment in the code.
[20:09] <fta> i should reject those and alert the translator, not sure how to do that with launchpad though...
[20:17] <deyaert> hi
[20:19] <deyaert> hm
[20:19] <deyaert> quitet in here
[20:19] <deyaert> quiet :p
[20:19] <cjwatson> people don't usually respond unless there's an actual question ...
[20:20] <deyaert> ok
[20:20] <deyaert> sorry
[20:21] <deyaert> i'm quite new in the linux world
[20:21] <deyaert> but i'm a developer
[20:21] <deyaert> and i'm interested in ubuntu development
[20:22] <deyaert> what are the main languages that are used to create the ubuntu os?
[20:22] <cjwatson> C, Python, POSIX shell, C++, Perl, various others.  my experience is that it helps greatly to be flexible
[20:23] <cjwatson> bear in mind that the bulk of the actual code is written in other projects, and integrated in Debian and/or Ubuntu
[20:25] <deyaert> okay
[20:26] <deyaert> i've read the ubuntu documentation on how to set up the dev environment
[20:26] <deyaert> but are there many articles on the actual development
[20:26] <deyaert> debugging
[20:26] <deyaert> packaging
[20:26] <deyaert> submitting code
[20:26] <deyaert> ...
[20:27] <cjwatson> http://wiki.ubuntu.com/UbuntuDevelopment and http://wiki.ubuntu.com/ContributeToUbuntu are full of links that should help
[20:31] <nemo> deyaert: http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html
[20:32] <deyaert> which languages you'd recommend
[20:32] <ebroder> deyaert: it's less about what language and more about what you want to do
[20:32] <nemo> depends what you want to do
[20:32] <nemo> jinx
[20:33] <nemo> personally I work on Hedgewars, but that's not ubuntu specific. I'm just hanging out here hoping to glean suggestions on a memory leak in Xorg
[20:33] <deyaert> bugfixing is quite a general subject
[20:33] <ScottK> Depends on your interests.  You can be productive with even a bit of shell.
[20:33] <ebroder> deyaert: it's true, but you're better off starting more focused than "fixing bugs in ubuntu". something like "fixing bugs in empathy" or whatever
[20:33] <cjwatson> I never recommend any particular language - it's definitely more important to find something that interests you and work from there
[20:33] <deyaert> it's all new for me
[20:33] <deyaert> i mainly developed in java and c#
[20:33] <deyaert> and i come from the windows world :-)
[20:33] <ebroder> deyaert: well are you using ubuntu now? what bugs you about it?
[20:33] <cjwatson> start with things that are comfortable for you then
[20:34] <cjwatson> Ubuntu has code in practically every language under the sun, somewhere
[20:34] <deyaert> but you hear about a lot of languages
[20:34] <ebroder> if you know c#, you could look at some of the mono apps like banshee and tomboy
[20:34] <deyaert> perl python ...
[20:34] <deyaert> mono I've worked with
[20:34] <cjwatson> if you want to pick up more languages, go for it, but there's no reason you should feel constrained by what the bulk of the base system is written in when you're starting out
[20:34] <deyaert> but that's more for application development not?
[20:34] <cjwatson> Ubuntu contains applications written in Mono
[20:35] <deyaert> yea?
[20:35] <deyaert> out of the box?
[20:35] <deyaert> which ones?
[20:35] <cjwatson> ebroder just gave examples
[20:35] <nemo> deyaert: http://ubuntuforums.org/showthread.php?t=51003 (more on packaging)
[20:35] <cjwatson> tomboy is out of the box, banshee is currently an add-on but is due to be out-of-the-box in natty
[20:35] <ebroder> and i think gbrainy is the other mono app included by default
[20:36] <deyaert> okay
[20:37] <deyaert> if you want to develop for example
[20:37] <deyaert> a cross platform installation
[20:37] <cjwatson> Ubuntu is full of stuff that is not distributed out of the box, though
[20:37] <deyaert> is there a way that the ubuntu team whould pick up the application
[20:37] <deyaert> and supply it by default?
[20:37] <cjwatson> maybe, although that's not really a good place to start
[20:38] <cjwatson> the space available for things to be installed by default is *very very restricted*
[20:38] <cjwatson> I would not advise starting with that as a goal, because chances are you would be disappointed
[20:38] <cjwatson> lots of things are distributed in our repositories for later addition, though
[20:39] <cjwatson> if you want to develop applications for use on Ubuntu, there's a way to get them into extras.ubuntu.com and make them available in software-center; that's one route
[20:39] <deyaert> ok
[20:39] <deyaert> but i'm also interested to fix bugs
[20:39] <deyaert> as a hobby
[20:40] <cjwatson> that's great, we have several tens of thousands of them
[20:40] <deyaert> :-)
[20:40] <deyaert> i've taken a look at some bugs on the site
[20:40] <deyaert> but on most of them it's not mentioned the language
[20:40] <deyaert> it's not always that detailed?
[20:41] <cjwatson> almost never, that's not the way things are laid out
[20:41] <cjwatson> as folks said above - it's much better to find something that bothers you personally and that seems to be in an environment you're familiar with, fix that, and repeat
[20:42] <deyaert> that's true
[20:42] <deyaert> I think I should read some more about it then
[20:42] <cjwatson> that's certainly how I started, and I suspect that's how a lot of successful developers get started
[20:44] <cjwatson> find annoying thing that seems vaguely accessible, grab relevant source code, read until you understand where the problem is, hack until you've fixed it, clean up patch for submission, send off, polish as requested
[20:45] <deyaert> you've fixed a lot of bugs?
[20:45] <cjwatson> yes
[20:45] <ebroder> haha. cjwatson has probably fixed more bugs than everyone else in the channel put together :-P
[20:45] <deyaert> hehe
[20:46] <deyaert> yeah i'm just curious
[20:46] <deyaert> for me it's all new :-D
[20:46] <cjwatson> (I wouldn't say that ...)
[20:46] <deyaert> and what kind of bugs?
[20:46] <cjwatson> I mostly work on the installer and the boot loader
[20:46] <persia> deyaert, Best to start with something that bothers you, grab the source, and dig in.  If nothing makes sense, find something else that bothers you.  If it only makes a little sense, ask for help.
[20:46] <cjwatson> various other things on the side
[20:46] <cjwatson> what persia said
[20:47] <deyaert> ok
[20:47] <deyaert> i'll start looking for something that bothers me :-)
[20:47]  * persia learned to read and patch C++ solely from help given attempting to fix bugs in Ubuntu
[20:48] <deyaert> cjwatson, and what kind of languages are used over there
[20:51] <cjwatson> deyaert: boot loader: almost entirely C with a bit of assembly (and some scary stuff in the build system).  installer core: C and shell.  graphical installer frontend: Python.
[20:53] <deyaert> damn
[20:54] <deyaert> :-)
[21:10] <real_ate> Hi everyone! I was wondering if someone could help me with something. I've been following a bug in KDE that prevents you from switching users when you have GDM enabled
[21:10] <real_ate> the bug has been fixed in trunk and i've done a patch that "backports" the bugfix into the version that is in 10.04 LTS
[21:11] <real_ate> ... my question is... what do I do now? what is the "correct" process for getting a patch into ubuntu LTS when you don't need to file a new bug (cos its fixed already)
[21:12] <ebroder> !sru | real_ate
[21:16] <real_ate> ebroder: thank you for the information
[21:18] <real_ate> Looking at it... it seems like the bug that I'm trying to fix doesn't fit into any of the catagories of a sru
[21:18] <real_ate> it seems like it is more of a backport or something
[21:18] <real_ate> I'm not sure
[21:19] <ebroder> real_ate: so it's probably not a severe regression, but is the patch "obviously safe"?
[21:19] <real_ate> can someone give me their opinon on the matter? the bug, I don't think that it has an ubuntu launchpad bug, can be seen here: https://bugs.kde.org/show_bug.cgi?id=186198
[21:19] <persia> real_ate, For backports, we generally like to use the latest upstream (which may include a fix), but we don't much like it for bugfixes, unless there are also new features.
[21:19] <persia> !backports
[21:20] <persia> that ought say useful things about the guidelines for when something is backportable.
[21:20] <ebroder> oh boy...that's a non-trivial change
[21:20] <real_ate> ebroder: i would tend to agree
[21:20] <ebroder> 1 file changed, 184 insertions(+), 13 deletions(-)
[21:21] <persia> Might be one of those things that's only fixed in the future.  There's a fair number of those (else nobody would ever upgrade)
[21:21] <real_ate> :P
[21:21] <persia> ebroder, diffstat and impact are only very loosely related :)
[21:21] <real_ate> but i supose one could say that this is a major regression
[21:22] <ebroder> persia: yeah, i know that. i looked at the actual patch, too. it doesn't pass my triviality filter
[21:22] <real_ate> but it is a very old regression, from when Gnome/GDM updated to use the dbus ConsoleKit for session management
[21:22] <real_ate> KDE can't: shutdown, restart, hybernate, switch users, suspend
[21:22] <real_ate> when GDM is active, but it used to be able to
[21:23] <ebroder> but only if you're using KDE + GDM, right? KDE + KDM works?
[21:23] <real_ate> yes but Gnome + KDM doesn't
[21:23] <real_ate> so you will never be able to switch users where those users use different Desktop environments
[21:23] <ScottK> real_ate: What version of KDM was it fixed in upstream?
[21:23] <real_ate> ... but you used to be able to
[21:23] <real_ate> ScottK: it is in trunk so effectivly 4.6
[21:24] <real_ate> ScottK: but I have made a patch that applies to 4.5... not very many changes to the commited bug fix
[21:24] <real_ate> and i've tested it
[21:24] <ScottK> I see.
[21:24] <ScottK> Why don't you join #kubuntu-devel and discuss it with us there.
[21:25] <real_ate> i think that problem with the bug fix diff is that the whitespace changed a lot and it wouldn't apply correctly
[21:25] <real_ate> ScottK: will do
[21:39] <ebroder> cjwatson: it's deliberate that grub doesn't ship any files in /boot, right? so should i stash the gfxpayload {white,black}lists somewhere else and copy them somewhere in grub-mkconfig?
[21:48] <kees> uhm, so what is going on here?
[21:48] <kees> pkgstripfiles: processing control file: debian/apparmor-profiles/DEBIAN/control, package apparmor-profiles, directory debian/apparmor-profiles
[21:48] <kees> .. removing usr/share/doc/apparmor-profiles/changelog.Debian.gz
[21:48] <kees> and then I get lintian errors that changelog.Debian.gz is missing
[21:48] <ebroder> kees: that's part of https://blueprints.edge.launchpad.net/ubuntu/+spec/performance-desktop-n-install-footprint
[21:49] <ebroder> there should probably be a WI to patch out that lintian check
[21:49] <kees> I guess it's possible that already happened; I'm running a maverick lintian, but yeah, figured that was what was happening. :)
[21:50]  * micahg wonders if this is only for seeded packages or for all of them
[21:50] <ebroder> i believe it's for all packages
[21:50] <RAOF> It would seem to be unusefully difficult to restrict it to just seeded packages.
[21:51] <kees> as long as I'm here...
[21:51] <kees> drop perl dependency from apparmor-utils:
[21:51] <micahg> RAOF: well, if there is a point to having changelogs in a package, it would make sense to have them in the 15k+ packages not on the CDs
[21:51] <ebroder> kees: perl, not perl-base
[21:51] <kees> it's using ${perl:Depends}
[21:51] <kees> right, but I'm not explicitly depending on perl
[21:52] <ebroder> kees: i don't know, but i'm guessing it's because you're using a module that's not on perl-base?
[21:53] <ebroder> the fallback solution we discussed was splitting some more core modules into separate packages instead of "perl" being monolithic
[21:53] <kees> ebroder: yeah, so I guess they need adjustment, not apparmor-utils
[21:53] <kees> libterm-readkey-perl, librpc-xml-perl
[21:53] <RAOF> micahg: I'm not suggesting that changelogs are unuseful, just that they're not useful enough to add extra effort to a large class of packaging.  I also understand that part of the spec is to make the changelogs easily gettable, although you're probably more up on that.
[21:54]  * micahg remembers something about that as well 
[21:54] <ebroder> RAOF, micahg: yeah - pitti is adding an apt-changelog script that pulls from changelogs.ubuntu.com
[21:55]  * ajmitch wonders if there'll be an easy way to grab & store changelogs at install time
[21:55] <micahg> ebroder: the only risk with that is getting a changelog for a newer version of the package than you have
[21:55]  * RAOF wonders again why aptitude can't be polished up to be default.
[21:55] <micahg> RAOF: IIRC, that's not why it's gone, but rather apt-get has reached the maturity where it can be the default
[21:55] <RAOF> micahg: Have you checked out aptitude's behaviour there?  It grabs the changelog for the version you've got installed.
[21:56] <ebroder> i haven't looked at pitti's script, but that seems like easy logic to add
[21:56]  * micahg should try that by forcing a package in -updates back to the release version and see what happens
[21:59] <hallyn> recent libc update in natty changed some defines from int to uint64_t.  Is there guidance for what to do about usersapce which breaks on those?
[21:59] <hallyn> do i make it #include stdint.h?
[22:01] <hallyn> (obviously I could just hack something up, but...)
[22:07] <persia> micahg, ajmitch: I was told that the job to put all the changelogs for all the packages ever uploaded into librarian started running a couple days ago.  It will take a bit to run, but once it completes, we ought be able to pull changelogs via the LP API.  Adding this to the various package management front-ends shouldn't be too hard (and someone should make sure that's part of the work to be done for changelogs).
[22:07] <persia> (all the changelogs for all the packages uploaded during the maverick cycle already got stuck in librarian, as well as all the packages being uploaded now, and some of the packages from lucid)
[22:08] <micahg> persia: so it won't be whatever is current on c.u.c, but rather the actual version, that's good
[22:08] <ebroder> micahg: you know c.u.c has ~all the versions ever, right?
[22:08] <ebroder> it's not just one version
[22:08] <ajmitch> persia: that's good to know
[22:08] <persia> Ideally.  There's still work to be done.  All the LP coding I've seen done on it was unfunded development.
[22:08] <micahg> ebroder: orly?
[22:08] <persia> ebroder, It doesn't (but it has most of them).
[22:08] <ebroder> it certainly has all the recent ones, no?
[22:09] <persia> ebroder, Specifically, it has all the versions that were in the a.u.c pool during any of the times the spider script ran.
[22:09] <ebroder> oh, it's not triggered by the publishing process? that's unfortunate
[22:09] <persia> No.  Upload a package.  Upload a new revision for the next publisher run.  Time this to be between spider runs.  Notice the package never get caught by the spider.
[22:09] <persia> It's external to LP.
[22:09] <micahg> indeed...
[22:09] <persia> I think the spider runs every 4 hours, but it might be 6.
[22:10] <ebroder> i'd be skeptical of using the LP API because of speed, though. even if it's just getting a referral to the librarian
[22:10] <persia> Talk to lifeless.  he's been making LP fast.
[22:11] <ajmitch> and if you only need to make one API call to get a set of changelogs for packages, it shouldn't be too bad
[22:11] <persia> I think someone still needs to do the export-to-API bit for that, so if you have an idea for a good interface, you might want to do the first implementation, before a bad interface happens :)
[22:12]  * persia trusts most API exporters to have sane interfaces, but suspects everyone thinks a little differently
[22:14] <persia> Heh.  Really, LP coding isn't that scary :)
[22:15] <ajmitch> sure it isn't :P
[22:18] <ebroder> well...i'm glad i only mucked with my grub config in a vm
[22:21] <ari-tczew> Archive Admins: could you remove package dssi from blacklist? (new upstream release synced, blacklist due to different md5sums no longer necessary)
[22:23] <micahg> ari-tczew: you might want to file a bug and subscribe ubuntu-archvie
[22:23] <micahg> *archive
[22:25] <BUGabundo> evening
[23:15]  * SpamapS only just now noticed that the chromium-browser packages in ubuntu and debian seem to have diverged or were never from the same place
[23:39] <real_ate> where do you nominate a bug fix for a release in launchpad?
[23:39] <real_ate> I can't see it
[23:39]  * real_ate is kinda tired
[23:40] <persia> There ought be a "Nominate for Release" button.
[23:40] <persia> (also, most of the bug manipulation masters hang out in #ubuntu-bugs)
[23:40] <real_ate> persia: do you have an example bug that has that button?
[23:40] <real_ate> :D
[23:41] <persia> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/671178 has it (and happens to be the last bug I opened)
[23:42] <real_ate> persia: i don't see the button!
[23:42]  * real_ate might be blind!!
[23:45] <yofel> iirc that button is bug-control restricted since recently
[23:46] <real_ate> yofel: so that means only some people are able to set it?
[23:47]  * persia continues in -bugs