[00:00] <persia> kees: Didn't you have a script that discovered all the ELF objects that hadn't been compiled since your last hardening improvement?  Could we repurpose that for our ARM instruction set plans?
[00:00] <slangasek> is that level of inspection needed, or is the "not rebuilt since karmic" sufficient?
[00:01] <persia> Well, we don't actually care about rebuilding stuff that doesn't have ELF.
[00:01] <slangasek> inspecting the ELF objects will be a lot more expensive, certainly, so is harder to iterate; and I don't think looking for karmic binaries will turn up any false-positives
[00:01] <persia> For those, -marm vs. -thumb2 isn't going to make a difference.
[00:01] <slangasek> true, but if you're only grabbing Architecture: any, that's nearly 1:1 with "ELF"
[00:01] <persia> Fair enough.  I just thought it might be easier to use an extant script than develop a new one, even if it takes longer to run.
[00:11] <asac> slangasek: ok thanks
[02:47] <ccheney> doko__: i'm running into some sort of weird build error on lucid, not sure if its a toolchain issue (maybe related to java) or what, i tried 3.2 at first but can't even get 3.1.1 to build on lucid
[02:47] <ccheney> getting weird errors like this: "dmake:  Error: -- `VA8CLASSFIFILES)' not found, and can't be made"
[02:49] <ccheney> doko__: any ideas what could be causing that?
[02:49] <ccheney> doko__: for the 3.1.1 rebuild i just added the minimum needed to get it to build on lucid the distro-config update, apply file update, and rules file update
[02:50] <ccheney> doko__: it got the same type of weird class not found error as the 3.2 build i tried though
[02:50]  * ccheney thinks it must be something related to java build stuff
[02:50] <TheMuso> c/c
[05:06] <ebroder> Hmm...so I just got an e-mail from someone I sponsored pointing out that when james-w sponsored a bzr merge, the sponsoree was still the committer, but when I follow the instructions at <https://wiki.ubuntu.com/DistributedDevelopment/Documentation/UploadingAPackage>, it creates a new commit with me as the committer. What is james-w doing that I'm not?
[05:13] <RAOF> ebroder: They should still be the committer for the revisions that they committed; you'll have committed a new merge revision, though, right?
[05:14] <ebroder> Right. But there's not much point in creating a merge revision if I'm not making any changes to their branch. Would I just `bzr branch` their branch and then `bzr push lp:ubuntu/<package>` with that, I guess?
[05:21] <RAOF> If you wanted to, I guess.
[05:23] <jml> hi
[05:24] <jml> I've just posted about Launchpad's development roadmap to the LP blog. If I wanted to make sure that interested Ubuntu developers knew about it, where else should I post?
[05:25] <persia> jml: Is your post entitled "The Road Ahead"?
[05:25] <jml> persia, yes.
[05:26] <persia> Then you're done :)  http://planet.ubuntu.com/
[05:26] <jml> persia, ok, thanks.
[05:55] <smoser> Keybuk, is there a way i can tell ureadahead to not reprofile next time?
[05:55] <smoser> after its told me "ureadahead will be reprofiled on next reboot"
[06:27] <dholbach> good morning
[06:54] <smoser> Keybuk, ping. or anyone, i could use some upstart help. on ec2, I can reproduce regularly, the following:
[06:54] <smoser> - working first boot
[06:54] <smoser> - install of upstart job that has: start on (mounted MOUNTPOINT=/ and net-device-up IFACE=eth0)
[06:55] <smoser> - install upstart job that turns on debug on 'startup'
[06:55] <smoser> - reboot
[06:55] <smoser> - hang
[06:55] <slangasek> smoser: why are you saying 'mounted MOUNTPOINT=/'?
[06:55] <smoser> per advice of Keybuk i thought.
[06:56] <slangasek> hmm
[06:56] <smoser> i want my job to run as early as possible such that eth0 is up
[06:56] <slangasek> I don't know why you wouldn't just be doing 'start on net-device-up IFACE=eth0'
[06:57] <slangasek> I'm not going to try to guess why Keybuk would have advised you to write it that way
[06:57] <smoser> because i want to block other things i think.
[06:57] <smoser> i want to block as much as I can on my job running
[06:57] <smoser> http://paste.ubuntu.com/353326/ is the debug output
[06:58] <slangasek> what, specifically, are you trying to block?  If that formulation is blocking at all, it'll block any other non-root filesystems from being mounted... which could also block the network from coming up
[06:59] <smoser> well, theres only 1 "normal" filesystem
[07:00] <smoser> in general, the goal is to run as early in the boot process as psossible and be able to affect as much of the boot proccess as possible.
[07:01] <smoser> this actually does work for me in a kvm instance that ih ave which is really almost identical. other than timing.
[07:04] <smoser> i think i know what the problem is.
[07:05] <smoser> in my initramdisk, i was bringing up eth0 and not bringing it down
[07:05] <smoser> that must have stopped a eth0 up event from ever firing
[07:10] <slangasek> could be
[07:44] <pitti> Good morning
[07:46] <nixternal> pitti: come shovel my driveway, then it will be a good morning :p
[07:47] <nixternal> though 01:45 and am waiting for a meeting, so even the shoveling won't make it any better :)
[07:47] <pitti> nixternal: I'd get stuck in all the snow on our front door :)
[07:47] <ebroder> I am so not looking forward to heading back to Boston this weekend...
[07:47] <nixternal> yeah, I just looked and the snow is up on the glass...the drifting has started
[07:47] <nixternal> we got another foot of snow today on top of the 2+ feet we already had...this is getting crazy
[07:59] <pitti> StevenK: thanks for finishing the netbook renaming transition!
[08:08] <Shiran> anyone know how can i add ASCII 0 to a string in c++?
[08:09] <Flannel> Shiran: what are you trying to do with it once it's added?
[08:09] <Shiran> send it  to a socket
[08:09] <Shiran> i added "\0" in my string but apparently this doesn't work
[08:09] <Flannel> Oh wait, we're talking about computers.  Right.
[08:10] <Shiran> :P
[08:10] <Flannel> Shiran: you want to append "0", not '\0'
[08:10] <Flannel> No, no, I was going to mention that strings are static and you'll wind up doing a copy and stuff, but you probably don't care.
[08:11] <Shiran> that doesn't matter
[08:12] <Shiran> i want my string to be "blah blah blah ^@"
[08:12] <ttx> pitti: good morning ! Could you trigger a Server CD respin for me ? The recent one didn't catch the lately-published eucalyptus 1.6.2~bzr1120-0ubuntu6
[08:12] <persia> You want a string that contains a null byte?
[08:12] <Shiran> if i write "blah blah blah 0" wouldn't it just be "blah blah blah 0" ??
[08:12] <Shiran> i want it to contain ^@, i dont think thats null but im not sure
[08:12] <Flannel> Shiran: That's what you asked for "ascii 0" is 0x30
[08:13] <Flannel> You want it to have "^@" in it?
[08:13] <Shiran> yea
[08:13] <Shiran> ^@ being ASCII 0
[08:13] <Shiran> right now i have   string shiran = "blah blah \0"
[08:13] <persia> Shiran: You probably want to ask on a dedicated c++ channel.  That's going to be tricky.
[08:14] <Shiran> what should it be?
[08:14] <Shiran> presia: obvisouly i did in 2 of them
[08:14] <ash211> Do you mean append ASCII 0 to the end of the string, or add to each character by the value of ASCII 0 ?
[08:14] <Shiran> and i didnt get reply yet
[08:14] <Shiran> ash: ASCII 0 to the end of the string
[08:15] <Shiran> this is how the other socket knows i finished sending it a message
[08:15] <Shiran> it should read ASCII 0
[08:17] <Flannel> Shiran: what's the hex value for 'ascii 0'?
[08:18] <Shiran> i dont know
[08:19] <ttx> slangasek, cjwatson: if you're around, please feel free to trigger a server CD respin as well, since my usual victim (pitti) is not available :)
[08:20] <ash211> well if your string is called str, why can't you just do a [[str += "0";]] ?
[08:20] <Shiran> ok someone in C++ channel helped me
[08:20] <Shiran> it's   mystring + '\0'
[08:21] <Shiran> this works good
[08:21] <ash211> oh, that's not ASCII zero, that's a null byte
[08:21] <ash211> but anyway, glad you got it figured out
[08:24] <Flannel> Shiran: you might also be interested in str.c_str() (where str is your string)
[08:24] <Shiran> and why is that?
[08:25] <Shiran> i know i'm getting char* with it
[08:25] <Flannel> Shiran: Because it returns the null terminated string
[08:25] <Shiran> i don't think thats good
[08:25] <ttx> mvo: about bug 494499
[08:25] <Shiran> because i use a certain protocol
[08:26] <Shiran> STOMP protocol
[08:26] <ttx> mvo: this bug has been targeted to alpha2
[08:27] <ttx> mvo: an easy fix is to return 0 in all cases, I was wondering if it had any side-effects ?
[08:28] <mvo> ttx: I'm on the phone right now, I have a look after that
[08:28] <ttx> mvo: no hurry, thx
[08:28] <Shiran> so my string goes like   "CONNECT\n" + "login:Shiran\n" + "passcode:passcode\n\n" + '\0'
[08:28] <ebroder> Whoo! u-u-s queue is empty again :)
[08:29] <Shiran> if i dont send my string exactly this way, then my server doesn't get the right command to connect me
[08:30] <superm1> kirkland, no better than you can google it, sorry no special links from my end
[08:30] <superm1> kirkland, probably support.dell.com and put in that model and it will be right htere
[08:31] <ttx> mvo: hm, in fact it's not targeted to alpha2, just nominated for lucid
[08:41] <pitti> ttx: bonjour
[08:42] <ttx> pitti: hey !
[08:42] <pitti> ttx: running
[08:42] <ttx> pitti: thanks !
[08:42] <pitti> de rien
[08:44] <tseliot> doko_, cjwatson, slangasek: do you know how to make sure that a library is permanently loaded before another which lives in /usr/lib? Putting the path to the other library in /etc/ld.so.conf.d/ doesn't seem to solve the problem (see libGL.so.1): http://pastebin.ubuntu.com/353366/
[08:45] <tseliot> shall I use preload and would it be acceptable if I did so?
[09:05] <doko_> tseliot: LD_LIBRARY_PATH should help, I don't think that LD_PRELOAD is needed
[09:07] <tseliot> doko_: but shouldn't glibc look in /usr/lib after the paths in /etc/ld.so.conf.d ?
[09:12] <tseliot> doko_: is it possible that some patches that we have cause it to somehow resort the cache?
[09:13] <doko_> tseliot: why? it's still one logical config file
[09:15] <tsimpson> did you run ldconfig after editing the conf file(s)?
[09:15] <tsimpson> that's what regenerates the cache
[09:15] <tseliot> yes, of course I did
[09:16] <tsimpson> as far as my knowledge of LD goes, it should be working then
[09:16] <tseliot> the file that I put on pastebin ^^ is the output of ldconfig -p after doing an ldconfig
[09:18] <tseliot> doko_: but I don't see why it should pick up /usr/lib/libGL.so.1 before /usr/lib/nvidia-current/libGL.so.1 if I put /usr/lib/nvidia-current/ in /etc/ld.so.conf
[09:20] <superm1> what if your rename the cache before running it
[09:21] <superm1> although i guess it's supposed to rebuild it anyway during the invokation
[09:21] <tseliot> I can try that
[09:22] <tjaalton> sounds like /usr/lib|/lib is used before anything else
[09:22] <tseliot> superm1: same result
[09:23] <tseliot> tjaalton: right
[09:24] <doko_> tseliot: even before /usr/local/lib ?
[09:25] <tjaalton> forgot /usr/local/lib :)
[09:26] <tseliot> doko_: let me check
[09:27] <tseliot> doko_: it's loaded after the path that I want to use
[09:28] <tseliot> libGL.so.1 (libc6, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so.1
[09:28] <tseliot> libGL.so.1 (libc6) => /usr/lib/nvidia-current/libGL.so.1
[09:28] <tseliot> libGL.so.1 (libc6) => /usr/local/lib/libGL.so.1
[09:28] <tseliot> which is correct
[09:28] <tseliot> since I put my path in GL.conf
[09:29] <tseliot> which comes before libc.conf
[09:29] <tseliot> in alphabetical order
[09:30] <tsimpson> are you sure ldconfig -p prints out in the order which libraries will be loaded?
[09:30] <tseliot> doko_: oh, I think I know what the problem is
[09:31] <tseliot> if I copy the library from /usr/lib to /usr/local/lib the former is picked up first
[09:31] <tseliot> while if I copy the one from /usr/lib/nvidia-current to /usr/local/lib the same doesn't happen
[09:32] <superm1> how does that explain it?
[09:32] <tseliot> this happens because these 2 libraries are considered as different libraries:
[09:32] <tseliot> libGL.so.1 (libc6, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so.1
[09:32] <tseliot> libGL.so.1 (libc6) => /usr/lib/nvidia-current/libGL.so.1
[09:32] <superm1> tsimpson has a good point though, you should double check with ldd and something that is linked to libGL.so.1 in case ldconfig -p just prints the cache in the order it likes to
[09:33] <tseliot> but "ldd /usr/bin/glxinfo" confirms the fact that the wrong library is being used
[09:33] <Sarvatt> open("/usr/lib/libGL.so.1", O_RDONLY)   = 3
[09:36] <tseliot> Sarvatt: do you have a theory?
[09:37] <superm1> tseliot, its possible that mandriva's ldconfig is behaving differently.  they probably use glibc whereas we use eglibc
[09:37] <Sarvatt> nope its just definitely using /usr/bin/libGL.so.1 first like the ldconfig -p shows here with your packages
[09:41] <tseliot> superm1: if it considers libGL.so.1 (libc6, OS ABI: Linux 2.4.20) and libGL.so.1 (libc6) as different libraries then there might be something wrong in what ldconfig does
[09:46] <tseliot> here's what ldconfig --verbose says: http://pastebin.com/d72e5c079
[09:49] <doko_> tseliot: is the library loaded at all, even if you remove the one in /usr/lib?
[09:50] <tseliot> doko_: yes, it is. Currently it's the only way to get things to work
[09:55] <tseliot> doko_: ldconfig still seems to be looking for /usr/bin/libGL.so.1. If I remove /usr/bin/libGL.so.1 (which is a symlink to /usr/bin/libGL.so.1.2) ldconfig recreates the symlink
[10:17] <tseliot> tjaalton, doko_: I guess it depends on the flags that we use in mesa. Mandriva doesn't have (libc6, OS ABI: Linux 2.4.20) but only (libc6)
[10:17] <tseliot> ldconfig sort things differently if flags or whatever are there
[10:19] <tseliot> tsimpson, Sarvatt: ^^
[10:20] <tjaalton> ask for the config flags of the mandriva package
[10:32] <tseliot> tjaalton: they use -O2 -g -pipe -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
[10:37] <tjaalton> tseliot: more than what we seem to have
[10:40]  * tseliot nods
[11:11] <apw> pitti, hey, looking at report_tools.py, at the names of the _completions, it seems some return tasks and others not, and there is no hint in the function name
[11:18] <StevenK> pitti: You're welcome. If it all looks fine to you, I can mark the last work item as DONE?
[11:20] <StevenK> pitti: Ah, you already did it, thanks!
[11:20] <StevenK> seb128: You're awesome, thanks (re: gyp)
[11:21] <seb128> StevenK, thanks ;-)
[12:14] <asac> Keybuk: we get "Its mountall: Could not connect to Plymouth" on arm ... is that expected/known/filed?
[12:16] <asac> Keybuk: unping. found that plymouth isnt seeded still
[12:20] <ogra> asac, with it installed i get: init: plymouth-log main process (3094) terminated with status 111
[12:20] <asac> ogra: does it break the boot?
[12:20] <ogra> and still the: mountall: Could not connect to Plymouth#
[12:20] <ogra> no
[12:20] <ogra> just adds noise
[12:20] <asac> good. just scared as it gets added next week to seed
[12:20] <ogra> Keybuk, ^^^
[12:21] <asac> so if it would break we would have to blacklist on armel for a2
[12:21] <ogra> indeed
[12:43] <sbalneav> mvo: Tested the gksu patch last night.  Works for me!  Ship it!
[12:44] <mvo> sbalneav: thanks! already uploaded :)
[12:44] <sbalneav> supah!
[12:44] <sbalneav> mvo++
[12:46] <mvo> thanks for your great help on this!
[12:48] <apw> pitti, about?  i think i've got a first stab at the wiki-status for the 2.0 interface, wondering if you are generating the DB regularly yet?
[13:04] <pitti> StevenK: :)
[13:05] <pitti> apw: re
[13:05] <pitti> apw: hm, which function is unclear? I thought I documented their return value in the docstring, but I'm happy to add improvements
[13:06] <pitti> apw: db is generated hourly, at http://piware.de/workitems/lucid.db
[13:06] <pitti> apw: http://piware.de/workitems/ also has all the generated reports
[13:06] <apw> pitti, any chance we can get that onto chinstrap
[13:07] <pitti> apw: that's indeed my hope (or, rather, rookery, so that t's publicly http-accessible); pychart isn't on rookery, but the data collection part should be
[13:24] <files22> NEW TORRENT SEARCH SITE http://Torrentpirates.org
[13:41] <doko_> pitti: was there some reason that we did demote autogen (besides that we hadn't a dependency on it anymore)?
[13:46] <pitti> doko_: I can't remember any discussion about it; probably it just fell out of main's dependency set?
[13:47] <doko_> pitti: ok, could you re-promote it? gcc-4.4 build-depends on it again. somehow I did manage to drop this b-d
[13:49] <pitti> doko_: done
[13:49] <doko_> thanks!
[13:50] <zul> pitti: i was wondering if you had a look at the packaging for autofs5 yet?
[13:51] <pitti> not yet, sorry
[13:59] <kirkland> superm1: okay, thanks, i googled some, the signal-to-noise ratio was pretty low, though, thanks.
[14:05] <BlackZ> hello pitti
[14:09] <zul> doko: thanks for the review
[14:09] <pitti> hi BlackZ
[14:13] <hashimi> Hi everyone
[14:13] <hashimi> I have a question regarding, how to change my bootsplash. In my special builded linux
[14:14] <hashimi> i have the usplash folder, and make file. After doing make, where i must apply changes in intrd ?
[14:36] <pitti> apw: http://macaroni.ubuntu.com/~pitti/workitems/ -- banzai!
[14:37] <pitti> apw: unfortunately it doesn't build the .pngs yet, it complains about "Ghostscript not found." (pychart needs that apparently)
[14:37] <pitti> I'll see to installing a local gs as well
[14:37] <pitti> ... or not; this thing needs a million libraries
[14:38] <hashimi> I have a question regarding, how to change my bootsplash. In my special builded linux
[14:38] <hashimi> i have the usplash folder, and make file. After doing make, where i must apply changes in initrd ?
[14:44] <apw> pitti, how often will this data be updated, at what times?  so i can sync my updates
[14:44] <pitti> apw: 03 * * * *
[14:44] <pitti> apw: and takes some 15 mins
[14:44] <apw> so i should aim for 30
[14:45] <pitti> that should be safe
[14:46] <apw> cool ... i'll leave that running and see what happens
[14:48] <kirkland> Keybuk: howdy
[14:49] <kirkland> Keybuk: so i was up really late last night fighting something that appears broken, as best as I can tell
[14:49] <kirkland> Keybuk: but i'm sure i'm just looking at it wrong :-)
[14:49] <kirkland> Keybuk: start on (started foo and started bar)
[14:49] <kirkland> Keybuk: let's call ^ baz
[14:50] <kirkland> Keybuk: so baz has "start on (started foo and started bar)"
[14:50] <kirkland> Keybuk: okay, let's say that all 3 are running (foo, bar, baz)
[14:50] <kirkland> Keybuk: I now stop foo, which does in fact stop baz (as desired)
[14:51] <kirkland> Keybuk: note that bar is still running, was unaffected by stopping foo and baz
[14:51] <kirkland> Keybuk: now, i start "foo"
[14:51] <kirkland> Keybuk: foo runs
[14:51] <kirkland> Keybuk: and baz is still running
[14:51] <kirkland> Keybuk: shite
[14:51] <kirkland> kees: baz is *not* running
[14:51] <kirkland> Keybuk: ^
[14:51] <kirkland> Keybuk: baz is not running, although foo and bar are
[14:52] <kirkland> Keybuk: is this the way it's supposed to work?
[14:52] <apw> kirkland, isn't that the The Upstart Bug again?
[14:53] <apw> that that means 'both start events occur then do this'
[14:53] <kirkland> apw: oh?
[14:53]  * pitti reads "baz" and remembers the old days of arch
[14:53] <kirkland> apw: yup, that's what i'm hitting
[14:53] <kirkland> apw: i think i've hit this before in a slightly different fashion
[14:53] <apw> yeah it sounds like the one you were talking to slangasek about
[14:54] <kirkland> apw: great, then i'm right back to where I started :-)
[14:54] <apw> i think semantics clarification of what start on (started a and started b) means is in order
[14:54] <apw> and i think we have use cases for both obvious semantics
[14:56] <ion> tjaalton, keybuk: Wasn’t udevadm-trigger-in-maintscript evil? xorg-server (2:1.7.3.902-1) * Run udevadm trigger on postinst, and depend on udev [linux-any].
[15:02] <pitti> njpatel, StevenK: do you happen to have an idea about bug 495066?
[15:02] <njpatel> pitti: asac uploaded a proposed fix from me today
[15:03] <pitti> njpatel: oh, sweet!
[15:04] <tjaalton> ion: according to this howto it's safe https://lists.ubuntu.com/archives/ubuntu-devel/2009-January/027260.html
[15:04] <pitti> njpatel: hm, not in netbook-launcher then? latest upload is from December 15th
[15:05] <njpatel> pitti: clutk :)
[15:05] <ion> Alright
[15:06] <tjaalton> though the (driver) rules will be gone if/when we integrate the xorg.conf.d stuff
[15:12] <pitti> njpatel: sweet, thanks
[15:25] <asac> slangasek: you asked for ooo upload before a2?
[15:25] <asac> slangasek: i am quite sure that will kill our arm images
[15:25] <asac> at least there is high risk ;)
[15:33] <doko_> pitti: autogen needs libopts25-dev libopts25 from universe as well :-/
[15:34] <pitti> doko_: erm, it's the same source package?
[15:34] <pitti> all in main now
[15:34] <doko_> pitti: yes
[15:45] <pitti> apw: haha! using svg instead of png avoids ghostscript and even looks much better \o/
[15:46] <apw> pitti, most sneaky
[15:46] <ion> Using svg for what?
[15:47] <pitti> ion: burndown charts
[15:47] <pitti> http://macaroni.ubuntu.com/~pitti/workitems/canonical-desktop-team-lucid-alpha-2.html
[15:47] <pitti> rickspencer3_: ^ FYI
[15:47] <slangasek> asac: not having it before a2 leaves us with oversized images - why will it kill arm?
[15:47] <pitti> rickspencer3_: this also uncovered some WIs we have to do for other teams
[15:48] <jiboumans> piti: wtb bigger picture ;)
[15:48] <rickspencer3_> pitti, nice job
[15:48] <jiboumans> pitti too
[15:48] <pitti> bryyce: the other day you asked for svg for the burndown charts -- there you have :)
[15:48] <jiboumans> pitti++ for doing the hard work
[15:48] <rickspencer3_> pitti, that's a great view
[15:48] <pitti> http://macaroni.ubuntu.com/~pitti/workitems/ now has the full combinatorial explosion of all milestones and teams, all from a single DB, and super-fast to generate
[15:48] <rickspencer3_> jiboumans, just zoom in, the picture is svg
[15:49] <rickspencer3_> pitti, wow
[15:49] <pitti> and magnitudes easier to configure
[15:49] <slangasek> tseliot: peramenently loaded before another> before another library of the same name?
[15:49] <jiboumans> rickspencer3_: you overestimate the cross-browser compatibility of that suggestion =/
[15:49]  * pitti fixes the y labels on http://macaroni.ubuntu.com/~pitti/workitems/all.html
[15:50] <slangasek> tseliot: (or did you get your answer to this overnight?)
[15:51] <tseliot> slangasek: I think I've solved the problem now. The ".note.ABI-tag" in libGL from mesa makes ldconfig believe that it's not the same library as the one from nvidia as the former causes a versioned dependency.
[15:51] <slangasek> heh, ok
[15:52] <tseliot> slangasek: if each library lives in its own directory (as long as it's not /usr/lib) and we use ld.so.conf.d to tell ldconfig what to do, things work well
[15:53] <zul> doko: can you review python-pastedeploy as well it goes hand in hand with python-pastescript
[16:02] <asac> slangasek: if it fails to build on armel we cannot produce images i was told
[16:02] <asac> and we probably have just one try
[16:02] <asac> because of the time it takes to build it
[16:03] <asac> i think it has binary all packages that would mean that its not installable (i havent checked myself, was just pointed to that problem before)
[16:03] <asac> maybe we could unseed ooo ... not sure
[16:03] <asac> i will see if i can get info on that
[16:05] <slangasek> asac: I believe we've unseeded it before due to breakage; right now we've got two copies of libicu on the disk because OOo hasn't been rebuilt, and that's a fat library
[16:05] <asac> yeah. i will try to verify that unseeding would work
[16:06] <slangasek> anyway, OOo took 1d19h to build last time on armel... doesn't that give us two chances?
[16:13]  * ccheney running a local OOo build with updated dmake now to see how it goes
[16:28] <pitti> for a few days now, my launchpadlib scripts often get "ValueError: No JSON object could be decoded" exceptions, which seem to be transient, but numerous; did anyone else see those as well?
[16:32] <jpds> pitti: I'm pretty sure james_w filed a bug about that a few days ago.
[16:32] <jpds> Can't find it right now.
[16:32] <pitti> ah, thanks
[16:32] <geser> pitti: bug #504199
[16:32] <pitti> *phew*, so I'm not going crazy
[16:33] <geser> "Redirecting to a 200 response offline.html is a really bad idea for the API"
[16:35] <pitti> geser: thanks
[16:43] <smoser> Keybuk, do you happen to be around?
[17:11] <ttbabie> hi room 18 female here but iam bi
[17:12] <ttbabie> so whoeva wants pravite me can
[17:12] <jussi01> ttbabie: not here please, this is a channel for ubuntu development.
[17:37] <ccheney> slangasek: ok build worked with my updated dmake, will need to add doko's patch and then upload dmake and OOo
[18:35] <jono> seb128, are you aware of any problems with python-vte?
[18:35] <jono> I am trying to create a Terminal() in my app and the module says it is not there
[18:36] <jono> this is on Lucid
[18:36] <jono> wasn't sure if the module is broken atm
[18:37] <seb128> jono, no
[18:37] <seb128> $ python -c "import vte"
[18:37] <seb128> $
[18:37] <jono> seb128, its ok, fixe it
[18:37] <jono> II had a vte.pyc lying around :)
[18:37] <jono> thanks!
[18:38] <seb128> cool
[18:55] <mvo> jono: when python-vte break I usually get upset very quickly :)
[18:55] <jono> mvo, lol :)
[18:55]  * mvo uses it in various stuff like update-manager and gdebi
[18:55] <jono> mvo, I have quick q you might be able to answer
[18:55] <jono> I have a vte widget and need to feed it a command that it can execute, I am using feed_child to pass it the command, but how do I emulate pressing enter to run it
[18:56] <jono> or is there a better way of doing this?
[18:56] <jono> I just want to run a python script inside the terminal and show the output there
[18:57] <pacejr> does anyone know the status on alpha 2?
[18:57] <ScottK> lamont: It looks like Ross is hung somehow.  kdewebdev should have depwaited right away and even if it managed to start to build somehow, the package only takes 15 minutes (and it's been over 30).
[18:57] <smoser> anyone able to offer some guidance on bug 504883
[18:58] <ScottK> pacejr: What specificly do you want to know about?
[18:58] <smoser> try again ubottu  bug 504883
[18:58] <jono> ooh I see how this works
[18:58] <james_w> jono: try fork_command
[18:58] <jono> its like popen
[18:58] <jono> thanks james_w
[18:59] <pacejr> ScottK: It was scheduled to be released yesterday, I was curious about what was holding it up and when the actual release would be.
[18:59] <mvo> jono: sorry, was distracted, what james_w said
[18:59] <ScottK> pacejr: No.  It's scheduled for next week.
[18:59] <jono> mvo, no worries :)
[19:00] <pacejr> ScottK: You're right; my eyes skipped a line. Thanks
[19:01] <jono> mvo, james_w: I am using: self.terminal.fork_command("python", "/usr/share/python-snippets/pygtk/buttons.py")
[19:01] <jono> but I get /: can't open file 'u': [Errno 2] No such file or directory
[19:02] <jono> oh I can pass it a dir
[19:04] <jono> hmm no luck
[19:04] <bryyce>  pitti, beautiful svg :-)
[19:04] <mvo> jono: here is a example http://paste.ubuntu.com/353583/
[19:04] <mvo> jono: this is how I use it
[19:05] <jono> thanks mvo
[19:05] <jono> I will give that a shot
[19:05] <jono> I was using: self.terminal.fork_command("python", self.current_filename, None, self.snippetsdir)
[19:06] <bryyce> pitti, the chart only shows from jan 8th though ;-)
[19:13] <smoser> slangasek, bug 504883 is what i was asking about earlier this AM
[19:22] <LeonBrussels> Hi! I am using Epiphany 2.28.0 on Karmic. I am experiencing https://bugzilla.gnome.org/show_bug.cgi?id=605536 in gnome-shell with epiphany. I talked to the gnome-shell guys, a fix is already in 2.28.2 of epiphany. They told me to tell you that to fix it you would have to import f0e7cc5af163c6ed16c4450115b61bfa0822b80a from upstream (or push 2.28.2, I don't know what ubuntu policy is in that regard)
[19:24] <ScottK> LeonBrussels: Did you put all that information in the bug?
[19:24] <jdstrand> kees: I am trying to investigate bug #504903 and am stumped. if I build it locally in an schroot, the apparmor is included in the build, if I build it in LP, it is not. the LP buildlog is http://launchpadlibrarian.net/37456614/buildlog_ubuntu-lucid-amd64.tcpdump_4.0.0-6ubuntu1_FULLYBUILT.txt.gz
[19:25] <jdstrand> kees: the debhelper auto magic stuff is different between my local build and LP, even though the debhelper versions are the same
[19:25] <jdstrand> kees: this is tcpdump 4.0.0-6ubuntu1 (lucid)
[19:26] <jdstrand> kees: it moved over the the new 'dh $@' format with this merge, which I haven't used much before
[19:27] <jdstrand> kees: is there anything obvious in debian/rules that I did wrong?
[19:28] <jdstrand> kees: (I added the 'binary: install' part
[19:28] <cjwatson> most dh(1) users don't have a separate install: target IME
[19:29] <cjwatson> (haven't looked at the rest of it, sorry)
[19:29] <jdstrand> cjwatson: this is the whole debian/rules file: http://paste.ubuntu.com/353594/
[19:30] <jdstrand> there is no separate 'install', and I thought this was correct (since 'install' is done behind the scenes, aiui)
[19:30] <cjwatson> no, you should just drop the install bit
[19:30] <cjwatson> but that binary: doesn't look right in general
[19:30] <cjwatson> what I would do is:
[19:31] <cjwatson> override_dh_install:
[19:31] <cjwatson>         dh_install
[19:31] <cjwatson>         cp -a $(CURDIR)/debian/usr.sbin.tcpdump $(CURDIR)/debian/tcpdump/etc/apparmor.d
[19:31] <cjwatson> actually, why don't you just put 'usr.sbin.tcpdump etc/apparmor.d' in debian/install instead?
[19:32] <jdstrand> cjwatson: wouldn't I still need to put it in debian/tcpdump/etc... for that to work?
[19:32] <jdstrand> (the 2nd suggestion)
[19:33] <cjwatson> sorry, not sure what you mean?
[19:33] <cjwatson> I meant 'debian/usr.sbin.tcpdump etc/apparmor.d' BTW
[19:33] <jdstrand> ah, well that clarifies it
[19:33] <jdstrand> let me try that
[19:34] <jdstrand> I still find it curious that what I had worked in a clean schroot and not on the buildd
[19:36] <kees> jdstrand: that is weird.  does using debian/install work?
[19:36] <jdstrand> building now
[19:36] <ccheney> doko_: is the patch you referred to the one you sent on nov 1?
[19:37] <jdstrand> obviously, what I was trying to do was put the profile in place before binary was called
[19:37]  * ccheney hopes it is, its the only one he could find in his inbox
[19:38] <LeonBrussels> ScottK: I didn't report the bug, no. Should I post a reply to the bug in gnome-shell or file a new bug for the ubuntu package on launchpad?
[19:39] <ScottK> LeonBrussels: I missed that that wasn't a launchpad bug.  I'd file an Ubuntu bug on Launchpad.
[19:41] <jdstrand> cjwatson: debian/install works great. thanks!
[19:41] <jdstrand> kees: ^
[19:41] <slangasek> smoser: right, that's going to need Keybuk's input, because I don't see how this could ever work reliably
[19:41] <LeonBrussels> ScottK: Just so I can suggest the improvement: Would the ubuntu way of doing it be to update Karmic to the new version or patch the version in Karmic or wait for Lucid altogether (not a lot of people are affected anyway, gnome-shell is devel-only anyway)?
[19:41] <jdstrand> (at least locally, but I'm sure this will work on the buildd too)
[19:42] <ScottK> LeonBrussels: Either fix lucid only or fix lucid and patch karmic.
[19:42] <kees> jdstrand: cool
[19:42] <ScottK> It depends a bit and I couldn't say for sure.
[19:42] <smoser> slangasek, :-(. well, it works very reliably in my kvm guests.
[19:45] <Keybuk> I don't see why it wouldn't be reliable?
[19:47] <slangasek> Keybuk: smoser says this start rule was your suggestion in order to block other services until this job is done; but if that's true, isn't there a problem if bringing up eth0 depends on something else than just 'mounted MOUNTPOINT=/'?
[19:50] <Keybuk> that rule is very EC2 specific
[19:50] <Keybuk> after the root mount filesystem is mounted, wait for the interface to come up, download the config for that instance, and continue
[19:50] <Keybuk> eth0 is never going to depend on anything complicated
[19:50] <Keybuk> certainly never going to have a split filesystem
[19:50] <smoser> Keybuk, well, its not working on ec2, while it does work for me in kvm
[19:51] <smoser> i'm open to other more general suggestions that still allow blocking of other events and running early
[19:52] <Keybuk> smoser: what doesn't work about it?
[19:52] <slangasek> Keybuk: does mounted MOUNTPOINT=/ happen before or after virtual filesystems are mounted?
[19:52] <Keybuk> slangasek: neither
[19:52] <Keybuk> both
[19:52] <slangasek> (and if it happens before, does mountall block waiting for that event to return?)
[19:53] <kenvandine> cjwatson, ping
[19:53] <cjwatson> kenvandine: hi
[19:53] <Keybuk> mountall does not wait for virtual-filesystems, no
[19:53] <Keybuk> so you can do on virtual-filesystems and mounted and ...
[19:53] <smoser> Keybuk, if i add that job (see bug 504883), it blocks
[19:53] <kenvandine> hey, i have 3 packages that were ~ubuntu-desktop can upload for karmic and not lucid
[19:53] <kenvandine> cjwatson, mind fixing ?
[19:54] <kenvandine> indicator-applet, indicator-messages, and libdbusmenu
[19:54] <kenvandine> cjwatson, ^^
[19:54] <Keybuk> smoser: why does it block?
[19:54] <Keybuk> what blocks?
[19:54] <Keybuk> what's it blocking on?
[19:54] <smoser> boot stops. i was hoping you could give more info.
[19:54] <Keybuk> I don't have any more info to give you
[19:55] <Keybuk> you're the one with the problem, not me ;P
[19:55] <smoser> i have before and after logs there.
[19:55] <smoser> with logging level to info
[19:55] <Keybuk> I can take a look at the sprint for you
[19:56] <smoser> well, given that it doesn't work, do you have any suggestions for me on something else to try?
[19:57] <smoser> pretty please?
[19:58] <Keybuk> without knowing what's broken I can't give any suggestions?
[19:58] <Keybuk> you're going to need to debug it
[20:00] <CodAr2D3> Ubuntu-8.10 should update with this: http://debian.cs.binghamton.edu/debian/pool/main/g/gadmin-proftpd/gadmin-proftpd_0.3.8-1_amd64.deb
[20:03] <cjwatson> kenvandine: will have a look, it may not be easily fixable
[20:03] <kenvandine> cjwatson, ok, thanks i do appreciate it
[20:03] <CodAr2D3> Felix sit Annus Novus!!!
[20:03] <cjwatson> CodAr2D3: we don't update stable releases with new upstream versions, as a rule; we backport specific targeted patches for critical bugs. see http://wiki.ubuntu.com/StableReleaseUpdates
[20:03] <kenvandine> cjwatson, i have uploaded those for lucid before, dec 10
[20:04] <Keybuk> smoser: I don't wish to be difficult, btw
[20:04] <Keybuk> but between now and the sprint, I'm either on leave or at LCA
[20:04] <CodAr2D3> cjwatson: As upstream id say itll be more fun for the users to have things that works as intended. Dont you ?
[20:04] <cjwatson> kenvandine: I realise that, but since then more flavours of Ubuntu have started using it and so the software has started considering it as more core than ubuntu-desktop
[20:04] <smoser> Keybuk, thats ok. thank you for your imte.
[20:04] <Keybuk> and I have my own Alpha 2 deliverables which are, right now, being a complete pain and difficulty
[20:04] <Keybuk> and increasingly limited time to get them done
[20:04] <smoser> Keybuk, ok, the big first thing different between good and bad that i see is good has
[20:05] <smoser> init: mounted-tmp main process (2127) exited normally
[20:05] <kenvandine> cjwatson, sure... just in case that info helps
[20:05] <Keybuk> (ie. one day)
[20:05] <Keybuk> I don't have EC2
[20:05] <Keybuk> I don't know anything about EC2
[20:05] <smoser> and bad has 'mounted-tmp' messages
[20:05] <Keybuk> I don't have KVM
[20:05] <Keybuk> etc.
[20:05] <cjwatson> CodAr2D3: there are multiple ways to achieve this, and I'm afraid that this policy is not normally open to negotiation, but if there's an appropriate bug we can certainly look at backporting the fixes to achieve the same result for ussers
[20:05] <cjwatson> users
[20:05] <Keybuk> for me to be able to get up to speed enough to even replicate your problem is more time than I have
[20:05] <Keybuk> that shouldn't make a difference
[20:05] <Keybuk> does your job use /tmp ?
[20:06] <CodAr2D3> cjwatson: Upstreams gets hundreds of emails because Ubuntu fails to just copy in the new packages.
[20:07] <cjwatson> CodAr2D3: if you make it a matter of "you have to use our new releases or your users are broken", then we may have trouble working with you; but we do successfully work with many upstream releases on the understood basis that we'll backport important patches.
[20:08] <cjwatson> we do not copy in new releases because, sadly, this policy generally breaks a lot
[20:08] <cjwatson> I'm an upstream myself, I know that everyone always wants people to use the newest code, but this doesn't tend to be very compatible with the notion of an integrated stable release I'm afraid, so we backport patches
[20:09] <cjwatson> CodAr2D3: are there bugs filed for these problems?
[20:09] <CodAr2D3> Hmm, i suddenly feel a need to escalate this issue some notches.
[20:09] <cjwatson> CodAr2D3: this doesn't feel very constructive
[20:09] <CodAr2D3> No, go to bed or use your head.
[20:10]  * ScottK wonders who he thinks he would escalate to.
[20:10] <cjwatson> charming
[20:10] <smoser> Keybuk, my *real* job would use tmp, bu tthe example job just does "echo "hello world\n"'
[20:10] <Keybuk> I believe that the Baby Jesus still has a place in our governance structure
[20:10] <smoser> with console output
[20:10] <Keybuk> smoser: your real job cannot use /tmp
[20:11] <geser> ScottK: the last instance could be God (but I don't think he will intervene in this case)
[20:11] <Keybuk> but I'm surprised that the echo one fails
[20:11] <ScottK> One never knows for sure.
[20:11] <cjwatson> I only see four bugs on gadmin-proftpd, possibly bug 242067
[20:12] <smoser> how would i change it such that i could use tmp? and why couldn't i use tmp at that poitn. i woudl have thought that, csince its the same filesystem, it would be usable as normal
[20:12] <Keybuk> smoser: you can't
[20:12] <Keybuk> if you want to block mounting, you must only use the filesystem you're blocking
[20:13] <ScottK> geser: You should see the hatemail I got after wontfixing a bug that asked for gcc3.3 to be put back into the archive because there's proprietary software that needs the support libraries.
[20:13] <Keybuk> since you can't guarantee that any other mountpoint is ready yet
[20:13] <Keybuk> (this includes /proc, /sys, /var/run, /var/lock, etc.)
[20:14] <smoser> ok, that makes sense to me for proc, sys
[20:14] <smoser> but /tmp is on same filesystem as / (and so is /var.... and all things)
[20:14] <Keybuk> yes
[20:14] <Keybuk> and /tmp gets wiped ;)
[20:15] <Keybuk> if you're really unlucky, it might get wiped while you're trying to use it
[20:15] <Keybuk> mountall actually always thinks /tmp is a separate filesystem
[20:16] <Keybuk> (though I think it's more likely that /tmp will be wiped before, or just after, but I wouldn't bet on that)
[20:16] <smoser> ok, then to go another route, how can i say i want to run when those things are available.
[20:17] <Keybuk> if you want to run when those things are available, you can't block
[20:18] <Keybuk> (just reading through the code - you probably can get away with /tmp, provided you know it's never mounted as a tmpfs or similar)
[20:19] <Keybuk> but none of this explains why "echo hello world" does not work
[20:21] <smoser> shoot. well, possibly. let me change it. i wasn't completely truthful
[20:21] <smoser> echo [20:21] <smoser> possible that sh uses a tmp file for $(date) ?
[20:25] <Keybuk> shouldn't do ;)
[20:25] <Keybuk> that should work
[20:26] <ccheney> Keybuk: UK looks nice and cold ;-) http://news.bbc.co.uk/2/hi/in_depth/8447023.stm
[20:26] <Keybuk> ccheney: I love how the cities show up in grey
[20:27] <ccheney> looks like only a few areas not covered in snow/ice near scotland and north wales
[20:29] <cjwatson> ScottK: this is usually the point when Mark gets a ranty e-mail, I think
[20:29] <ScottK> No doubt.
[20:31] <Keybuk> shouldn't Jane get those now? :p
[20:31] <cjwatson> I'm not sure that people are mailing Mark as the CEO of Canonical
[20:34] <Keybuk> I HATE YOUR DISTRO YOUR STAFF SUCKS PS GIVE ME MONEY AND SEND ME INTO SPACE UR SO AWESOME!!!!
[20:37] <tseliot> :-D
[20:46] <lamont> ScottK: no, it's not ross.  but thank you
[20:47] <ScottK> lamont: OK.  I'm starting to gather it's more now.  Good luck.
[20:47] <jcastro> cjwatson: next time you get someone like that please feel free to punt them towards me, I have a whole spiel on explaining that to people, etc.
[20:48]  * ScottK thinks you should just explain the real solution is for them not to release buggy software in the first place.
[20:48] <jcastro> yeah
[20:50] <jcastro> but usually I can explain backports or PPAs to them so they at least know they're available
[20:50] <cjwatson> jcastro: I think in this case he was pretty unreceptive to start with, but sure
[20:50] <Keybuk> ccheney: the amusing thing about the cold weather is that some of the papers are proclaiming the end of global warming
[20:50] <cjwatson> we've all released buggy software from time to time, I imagine
[20:51] <Keybuk> when one of the "possible" causes for the cold weather is arguably related to global warming
[20:51] <Keybuk> (if there is such a thing)
[20:51] <jcastro> cjwatson: I agree, just letting you know you don't have to waste time on that. :)
[20:51] <cjwatson> Keybuk: the Express being well noted for its scientific approach to life
[20:51] <slangasek> cold weather is a myth
[20:51] <ccheney> Keybuk: heh, well cold != warm so it must not be global warming then, see its perfect logic :)
[20:52] <ccheney> its been below freezing all day here in houston area, too cold for me :)
[20:52] <jcastro> as an fyi to those interested, I am working on a little cheat sheet document for upstreams so they can understand how we work: https://wiki.ubuntu.com/Upstream/Guide
[20:53] <Keybuk> cjwatson: there is compelling evidence that the gulf stream has buggered off to the south
[20:53] <Keybuk> (or is it to the north)
[20:53] <Keybuk> might be to the north
[20:53] <jcastro> Keybuk: I saw a pic of your whole island being white the other day
[20:53] <cjwatson> Keybuk: yes, I saw it, scary stuff
[20:54] <jcastro> ah right, the nasa one you just linked
[20:54] <cjwatson> it's currently hitting Greenland IIRC
[20:54] <ccheney> jcastro: yep here is one http://news.bbc.co.uk/2/hi/in_depth/8447023.stm
[20:54] <Keybuk> the interesting thing will be whether that's temporary or permanent
[20:56] <jdstrand> pitti: fyi, it seems that status is reversed in workitems. eg: http://piware.de/workitems/security/lucid/report.html . security-lucid-apparmor-tunables should be 2/0/5 (todo/postponed/done). Also status by assignee is wrong-- eg coffeedude.jerry should be at 100% now (same blueprint)
[20:58] <jdstrand> hmm, actually, it seems out of date... that should be 3/0/5, but report.html has a timestamp of 08-Jan-2010 21:08 (I'm assuming +1)
[20:58] <lamont> ScottK: yeah - build-manager was a bit snitty there for a bit.  it's flowing now
[20:59] <jdstrand> pitti: ^
[21:05] <smoser> Keybuk, well, i guess i need to request some of your time at the sprint to discuss this more and fins some solution.
[21:05] <Keybuk> sure, time at sprint is easy :)
[21:06] <smoser> if you can think of anything i can do in the meantime i'd appreciate it.
[21:06] <Keybuk> debug! :)
[21:06] <smoser> i'm fine to change the start on to something that gets me run early on and has access to tmp and var
[21:06] <Keybuk> lots of echo and stuff
[21:14] <tjaalton> Keybuk: I know there's a bug about bootlog & upstart, but is there a way to get the bootlog somehow? gdm fails to start most of the time, dropping me in failsafe. note that the logfiles are not updated, so it isn't started at all
[21:15] <Keybuk> there is no boot log
[21:15] <tjaalton> but how do I get to see why gdm failed?
[21:19] <Keybuk> gdm's log?
[21:19] <tjaalton> it's untouched
[21:21] <Keybuk> that's not very helpful of it
[21:21] <tjaalton> I'll try to reproduce it after the uploads.. it doesn't happen every time
[21:21] <tjaalton> no it's not :)
[21:22] <tjaalton> and failsafe vesa on intel kms takes the rest :)
[21:22] <slangasek> tjaalton: I have failsafe X disabled here for that reason
[21:23] <Keybuk> I know of a bug where gdm just flat out doesn't get started
[21:23] <Keybuk> though I still can't reproduce it on demand enough to debug it
[21:23] <Keybuk> it usually happens when I'm trying something else and haven't put the instrumentation in I need
[21:23]  * slangasek nods :/
[21:24] <slangasek> I have mountall exiting abnormally for me at the moment, hoping to debug that this afternoon
[21:25] <tjaalton> slangasek: ah, so I'm not the only one. that's a relief
[21:25] <slangasek> tjaalton: to which part?
[21:26] <lamont> ScottK: and now it'll bitch at me the next time.
[21:26] <tjaalton> slangasek: oh, hmm :) well I do remember seeing some mountall failures
[21:26] <Keybuk> slangasek: ion has been doing some debugging along those lines
[21:26] <slangasek> tjaalton: ok - hopefully I'll be fixing a bug for more people than myself :)
[21:29]  * Keybuk sings the bugs song
[21:32] <slangasek> bugs song?
[21:32] <sistpoty> all your bugs belongs to Keybuk, lalalala?
[21:32] <sistpoty> :P
[21:33] <lamont> sistpoty: don't you mean his mom?
[21:33] <sistpoty> haha
[21:34] <Keybuk> too many bugs, not enough Keybuk
[21:35] <lamont> what if we cut him into little itty-bitty pieces?
[21:36] <Keybuk> same amount of keybuk ;)
[21:36] <Keybuk> just in smaller bits
[21:44]  * slangasek douses Keybuk in planarian hormones
[21:45] <Keybuk> heh, if I had clones, I'd just make out with them </xkcd>
[21:46] <sistpoty> Keybuk: oh, btw, do autosyncs still happen? and do they pickup -XbuildY versions as versions to sync?
[21:47] <sistpoty> (looking at guvcview atm)
[21:47] <Keybuk> sistpoty: autosyncs have never been auto, but entirely manual
[21:48] <sistpoty> Keybuk: oh, I see... should I file a sync request then? or will it be handled manually automatically *g*?
[21:48] <Keybuk> sistpoty: we're after freeze, so sync request I think
[21:48] <Keybuk> slangasek is *the* guy to ask about this kind of thing, of course
[21:48] <sistpoty> ah, thanks!
[21:48] <slangasek> we're after which freeze?
[21:49] <ScottK> lamont: Would you please rescore kde4libs on ia64.  If I can get that in ahead of gcc it should save a bunch of build failures later.https://launchpad.net/ubuntu/+source/kde4libs/4:4.3.90-0ubuntu1/+build/1436376
[21:49] <slangasek> Keybuk: import freeze isn't until Feb 11
[21:49] <slangasek> milestone freeze isn't until Tuesday :)
[21:50] <Keybuk> oh, I thought import freeze was christmas or something
[21:51] <sistpoty> <- didn't see import freeze on the wiki recently, but now it's there :)
[21:51] <sebner> Keybuk: we are sycing from testing, doesn't destroy even that so so far away from release :P
[21:51] <slangasek> Keybuk: it's delayed this cycle because of the testing Thing
[21:51] <Keybuk> ah
[21:51] <tweakt> is it possible to use the python-apt library 'apt.*' api with a custom configuration, or do I need to stick to the low level 'apt_pkg' api?
[21:52] <Keybuk> maybe it's jaunty's release schedule I'm thinking of
[21:54] <cjwatson> kenvandine: turns out your wish is granted after all. HAND
[21:55] <kenvandine> cjwatson, excellent!
[21:55] <kenvandine> cjwatson, thx!
[21:57]  * jdstrand is pretty sure we are past Juanty's feature freeze
[21:57] <jdstrand> err... Jaunty's
[21:57] <Keybuk> exactly :D
[21:57] <jdstrand> :)
[21:58] <ebroder> Jaunty's DIF was Christmas day, I think
[21:59] <Keybuk> yeah that's what I was thinking of
[22:00] <mvo> tweakt: that should work, however apt_pkg.Configuration needs to be used, that is not exported but will be picked up by the apt.* stuff
[22:00] <cjwatson> yes, I remember we had to justify it to people going "hang on, you can't schedule something for Christmas Day"
[22:00] <mvo> tweakt: (if not, please let me know with a example what dosn't work)
[22:00] <cjwatson> by pointing out that this was an event where you *stopped* doing work
[22:05] <Keybuk> after a while, all the releases merge into one great big panic
[22:06] <tweakt> mvo: so how should I access apt_pkg.Configuration ? I'm using apt_pkg.Config right now
[22:07] <jdstrand> where are lucid's netboot images? (I *never* can seem to remember where they are, and I know I wrote it down somehwere...)
[22:07] <elmo> jdstrand: dists/lucid/installer-$arch/
[22:08] <ebroder> Hmm... cdimages.ubuntu.com/netboot/lucid doesn't exist
[22:08] <elmo> jdstrand: dists/lucid/main/installer-$arch/current/images/netboot/
[22:08] <elmo> specifically
[22:08] <jdstrand> cool, found it
[22:08] <jdstrand> elmo: thanks!
[22:09] <cjwatson> ebroder: yeah, we should create that, it's all manual
[22:09] <cjwatson> (prefer cdimage.u.c btw)
[22:11] <jdstrand> that was where I looked first-- found the stable releases of course...
[22:11] <tweakt> mvo: apt_pkg.newConfiguration() ?
[22:12] <slangasek> Keybuk: does the disappearance of the Vcs-Bzr field on mountall imply the lp:ubuntu/mountall branch is now authoritative?
[22:12] <slangasek> hmm, I see some 'debcommit -r' log entries, so I guess so :)
[22:12] <elmo> hey, my panels no longer move when I drag them
[22:13] <elmo> anyone know how to unstick them?
[22:13] <slangasek> alt-drag? (WFM)
[22:13] <cjwatson> ebroder: I've pushed up http://cdimage.ubuntu.com/netboot/lucid/; it should get populated shortly
[22:15] <ebroder> cjwatson: Awesome, thanks
[22:17] <slangasek> Keybuk: server team is keen to have bug #503212 fixed for alpha-2, which is the one ion has a merge proposal for; do you have any insights/observations on that branch that aren't expressed in the merge proposal, or if not, do you mind if I review it and upload if I think it checks out?
[22:18] <ion> That branch fixes the initial segfault, but there are still other problems when running without an initramfs. I haven’t had a chance to debug them yet, but i’m planning to.
[22:18] <slangasek> ok
[22:19] <slangasek> ion: do you have any more detail on what the further problems are?  I don't have a ready initramfs-less test system
[22:19] <ebroder> Hmm...that's weird: "bzr: ERROR: Invalid url supplied to transport: "lp:ubuntu/bochs": bochs in ubuntu has no default branch."
[22:19] <ebroder> Import bug?
[22:20] <ion> slangasek: I’d prefer Keybuk to review my first commit in that branch, he might have a different idea of how to fix new_mount()s-after-mount_policy(). The second commit should definitely be Keybuk-safe if you will. :-P
[22:21] <slangasek> ion: well, I would also prefer Keybuk review it, but I'm not sure he'll be available to do so :)
[22:21] <ion> slangasek: I’ve encountered an assertion failure from nih_free (i.e. a double nih_free somewhere) that still didn’t kill mountall, so it seems to happen in a forked subprocess. That’s all i know so far, it needs actual debugging.
[22:22] <slangasek> ok
[22:22] <ion> slangasek: Oh, and the second commit is the only one needed to fix the #503212 segfault. The first commit fixes another bug that’s not related.
[22:22] <ebroder> Oh, do 3.0 (quilt) packages not get imported into bzr yet?
[22:26] <neXyon> hello
[22:29] <mothinator> I have a few questions about how merges/syncs occur: 1.) Does ubuntu sync with debian testing or unstable? 2.) When does syncing occur? Thanks.
[22:30] <sebner> mothinator: normally with unstable but now for the LTS with testing. Hmm, no fixed times, every few days afaik
[22:30] <neXyon> is any real ubuntu developer here? just interested
[22:30] <sebner> neXyon: what do you understand under "real" ?
[22:30] <neXyon> one that updates official packages
[22:30] <geser> and what are "fake" developers? :)
[22:31] <neXyon> ones not allowed to update official packages :D
[22:31] <sebner> neXyon: "official"?
[22:31] <neXyon> those in the official package repos :D
[22:31] <sebner> neXyon: you are currently speaking with 2 ;)
[22:31] <neXyon> okay
[22:31] <neXyon> I request an update of the openal package
[22:31] <sebner> neXyon: in this channel "higher" devs too though
[22:31] <tweakt> Still trying to figure out how to get the high level python-apt api to use a custom configuration (so it runs as non-root, with an isolated config)
[22:31] <neXyon> for ubuntu 08.04 - current
[22:31] <cjwatson> neXyon: please use the bug tracking system for such things
[22:32] <tweakt> any help *greatly* appreciated... tnx
[22:32] <cjwatson> any update to a stable release requires a bug report anyway
[22:32] <neXyon> I'm sure the bug report is there already
[22:32] <crimsun> neXyon: are you referring to #503780 ?
[22:33] <neXyon> my recommended solution as you don't update package versions is to change the default configuration of openal (soft) to use alsa, not pulse as the pulse backend is broken in openal soft (excluding current SVN)
[22:33] <crimsun> (the default backend *is* alsa)
[22:33] <crimsun> it's just being routed through the pulse pcm plugin, which is currently broken
[22:34] <mothinator> sebner: There is a package in unstable that I'd like be merged in for lucid, do I just file a "please merge" bug report on launchpad?
[22:34] <neXyon> then fix that one
[22:34] <crimsun> both upstream alsa and pa know of it; we're quite close to a solution
[22:34] <elmo> slangasek: hmm, sorry, I didn't realise/remember I needed a keyboard modifier, thanks
[22:34] <sebner> mothinator: I think so, what package?
[22:35] <neXyon> I then wonder why setting alsa in the openal config file helped fixing the bug in the application I'm developing
[22:35] <crimsun> neXyon: I appreciate your enthusiasm, but it has never been as simple as "just fix it already?!?!?!"
[22:35] <crimsun> neXyon: we can debug further whether it opens default or *hw: in a separate place
[22:36] <mothinator> sebner: texlive-publishers. Revtex (installed in texlive-publishers) has updated to 4.1 in October, but the old package is still in debian testing.
[22:37] <ScottK> mothinator: Why didn't the new one get in.
[22:37] <sebner> hola ScottK :)
[22:38] <neXyon> crimsun: well, at least, if the bug is fixed in alsa/pulse/whatever will you then update all affected versions of ubuntu?
[22:39] <crimsun> neXyon: erm, I uploaded openal-soft last night to Lucid; anything further regarding other released versions of Ubuntu will need to go through the StableReleaseUpdates procedure
[22:39] <Keybuk> ion: what did you need me to review?
[22:39] <neXyon> crimsun: you mean openal 1.10?
[22:39] <neXyon> (soft)
[22:40] <crimsun> neXyon: openal-soft (1:1.10.622-1ubuntu1) lucid; urgency=low
[22:40] <mothinator> ScottK: Good question. I'm just an end user that would like to see it get updated and I was curious how the process works. Is there a particular place to find out why?
[22:40] <cjwatson> texlive-extra is stuck in a big dependency cycle
[22:41] <ion> keybuk: https://code.edge.launchpad.net/~ion/ubuntu/lucid/mountall/lucid/+merge/16868 Do you agree with what i did in #254?
[22:41] <cjwatson> it's trying to go into testing at the moment
[22:41] <cjwatson> but it failed today, on the grounds of making a few hundred more packages uninstallable
[22:41] <neXyon> crimsun: ahh yeah, have you checked out openal soft svn too? that version is really fixed, as there are still bugs with pulse in 1.10
[22:41] <cjwatson> http://ftp-master.debian.org/testing/update_output.txt but it's not easy to read
[22:41] <cjwatson> (I have interpreted it above for you)
[22:41] <mothinator> thanks
[22:41] <Keybuk> ion: #255 is "obviously right"
[22:42] <crimsun> neXyon: "in 1.10" is quite ambiguous, but no, I have not done an "svn up" in the past day.
[22:42] <cjwatson> see http://lists.debian.org/debian-release/2010/01/msg00005.html and thread but there isn't much more informative there
[22:42] <neXyon> crimsun: which revision did you build?
[22:42] <Keybuk> ion: 254 is a bit heavy
[22:42] <Keybuk> ion: probably better to just have mounted() ignore TAG_UNKNOWN :p
[22:42] <cjwatson> we could sync directly from unstable, but the point of syncing from testing this cycle is to insulate us from this kind of bug that tends to be very time-consuming to sort out, so it would be better to wait
[22:42] <Keybuk> since the tag is largely irrelevant
[22:43] <Keybuk> (mounts found from parse_mountinfo() are already mounted)
[22:43] <neXyon> crimsun: because 1.10 is revision 622
[22:43] <mothinator> cjwatson: so does that mean it is unlikely to make it into lucid?
[22:43] <cjwatson> mothinator: it doesn't hurt to file a bug asking for it, of course, but perhaps wait until after Debian import freeze in case it gets in by itself (http://wiki.ubuntu.com/LucidReleaseSchedule)
[22:43] <ion> keybuk: Ok, i’ll make all cases of tag checking handle UNKNOWN properly instead of that.
[22:43] <cjwatson> mothinator: you're reading more into what I said than I actually said. :)
[22:43] <crimsun> neXyon: I thought my paste was pretty clear regarding which revision
[22:43] <Keybuk> ion: yeah, I think I meant to do that, and just forgot
[22:44] <Keybuk> "unknown" was there to literally mean "it wasn't there when we started"
[22:44] <Keybuk> (otherwise I'd've just used a different default)
[22:44] <crimsun> neXyon: also, I presume you meant to refer me to the git repo on repo.or.cz ?
[22:44] <neXyon> crimsun: ah yeah xD my mistake; well that version is buggy as I said
[22:44] <neXyon> crimsun: yeah you're right
[22:45] <neXyon> man, I should go to bed :)
[22:46] <crimsun> neXyon: there's considerable churn since the release 8 weeks ago
[22:46] <mothinator> cjwatson: fair enough. I just need to write some papers over the next year and this update would make my life easier. Also, I am clueless about development, so thanks for your help in sorting this out.
[22:46] <neXyon> crimsun: anyway, any expectation when this will be an update for the official repos so that affected users will get that fixed
[22:46] <Keybuk> cjwatson: btw, since you're here, I'm sure you know already, but installs aren't working atm
[22:46] <alkisg> crimsun, hi, I've heard of 3 ways to solve the SDL problem in Ubuntu and LTSP etc: 1) Put libsdl1.2debian-pulseaudio as the first dependency of libsdl1.2debian => would break [k|x]ubuntu, at least for now, 2) Put libsdl1.2debian-pulseaudio in the Ubuntu CD seeds => maybe SDL isn't needed on the CD,
[22:46] <crimsun> neXyon: what do you mean by "update for the official repos"?
[22:46] <alkisg> 3) Put libsdl1.2debian-all as the first dependency and either patch libsdl1.2debian to prefer pulse, if it's available, or/and set SDL_AUDIODRIVER=the preferred output method in the environment.
[22:46] <alkisg> Is there any chance that any of the above methods are included to Lucid?
[22:46] <sistpoty> Keybuk: I assume I can't bribe you to merge trousers for me? (my tiny change is picked up, but I have not much clue about your udev changes though)
[22:47] <neXyon> crimsun: I'm not too much into ubuntu... I mean when do normal users that just do normal updates get a fixed system?
[22:47] <cjwatson> Keybuk: I don't, I have been completely buried in contract work for the last week
[22:47] <crimsun> alkisg: setting environment variable isn't terribly intrusive
[22:47] <crimsun> neXyon: that will need to go through the StableReleaseUpdates process, as I mentioned earlier
[22:47] <cjwatson> Keybuk: no rows for it on daily-installer?
[22:48] <crimsun> neXyon: so no, I have no ETA
[22:48] <alkisg> crimsun: I offered to test if [k|x]ubuntu work with out of the box with libsdl1.2debian-all, but the current live CDs don't work with my hardware. I'll report in LP #203158 when alpha 2 is out. Thanks! :)
[22:48] <alkisg> (a change in the libsdl1.2debian dependencies order will be needed)
[22:49] <cjwatson> neXyon: stable updates are *minimum* seven days from the time the upload enters the verification process; this is to protect users from mistakes. So certainly not before that
[22:49] <Keybuk> cjwatson: no, ubiquity never finishes or runs the failure script
[22:49] <Keybuk> I'll nag evan on monday
[22:49] <crimsun> alkisg: changing the alternates order seems nasty; I'd prefer to export a variable conditionally
[22:49] <cjwatson> Keybuk: it's probably best, this week has not been composed of short days
[22:49] <alkisg> crimsun: the variable only works with -all, it won't work if -alsa is installed.
[22:49] <Keybuk> cjwatson: I know the feeling
[22:50] <alkisg> crimsun: So a change in the dependencies would be required for -all to be installed, when someone installs e.g. tuxpaint.  libsdl1.2debian-all is in main, so it shouldn't be much of a problem..
[22:50] <neXyon> cjwatson: I am happy with 2 months :D
[22:51] <crimsun> alkisg: it really makes more sense to explicitly seed the appropriate backend, then
[22:51] <tseliot> cjwatson: can you accept nvidia-graphics-drivers (it's in NEW), please?
[22:52] <cjwatson> tseliot: I have a rule, I don't do archive admin that requires thought when exhausted
[22:52] <alkisg> crimsun: I'm fine with explicit seeding, and sdl is currently on the CD, but maybe when gimp is out people will also want sdl out of the CD?
[22:52] <cjwatson> tseliot: sorry ...
[22:53] <tseliot> cjwatson: it's a good rule. Thanks anyway
[22:53] <tseliot> Keybuk: ^^ or maybe someone from a different time zone could help me
[22:54] <Keybuk> what's a time zone?
[22:54] <Keybuk> I'm going to decline as well; I need to eat and actually go do things that don't involve work :p
[22:54] <tseliot> I don't know, but it sure sounds good when I say it :-P
[22:55] <tseliot> fair enough
[22:55] <crimsun> alkisg: I'd rather focus on fixes instead of hypothetical crackfulness
[22:55] <alkisg> crimsun ++ :)
[22:57] <tseliot> slangasek: ^^^
[22:57]  * sebner is afraid of testing tseliots newest driver :P
[22:58] <tseliot> sebner: just reboot without testing, I know you love it :-P
[22:58] <sebner> hahaha
[22:58] <sebner> tseliot: btw, my *new* harddrive has 1 bad sektor since that day ;)
[22:59] <sebner> *sector in english
[22:59] <slangasek> tseliot: hmm, let me poke first to see whether the xorg upload has fixed my crash-on-lid bug :)
[22:59] <tseliot> slangasek: ok, thanks
[23:00] <sebner> slangasek: you could also try the blob as I said but leave out the 40 reboots I did because tseliot was overexitced and broke stuff all the time :P
[23:00] <tseliot> sebner: that's a scar of war. Treat it with respect ;)
[23:00] <tseliot> soren can confirm that everything works fine now
[23:00] <sebner> heh
[23:01] <soren> Affirmative.
[23:01]  * sebner ^5 soren 
[23:01] <tseliot> but yes, we had a rather interesting session
[23:01] <tseliot> testing session, that is
[23:01] <sebner> heh
[23:01]  * sebner hugs tseliot :)
[23:01]  * tseliot hughs back sebner
[23:02] <tseliot> hugs
[23:02] <sebner> he
[23:02] <sebner> h
[23:09]  * tseliot restarts X
[23:15] <slangasek> sebner: no, *I'm not running nvidia* :)
[23:18] <slangasek> tseliot: great, xorg-server is fixed for me, I'll happily approve anything X-related I find in NEW now <whistles>
[23:18] <tseliot> slangasek: thanks a lot :-)
[23:26] <tjaalton> slangasek: would you be willing to test applying just that gamma-fix patch on top of .901 to be sure it's the one that fixed it, and not some other commit from .902?
[23:27] <slangasek> tjaalton: if you insist... :)
[23:27] <tjaalton> slangasek: it would probably help in getting a quick review for the patch upstream :)
[23:44] <slangasek> cjwatson: do you know why lintian is broken on cocoplum suddenly? (Can't locate Digest/SHA.pm)
[23:45] <cjwatson> I do not, haven't touched it, sorry
[23:45] <elmo> that's most likely me
[23:46] <elmo> slangasek: try now
[23:47] <slangasek> elmo: better, thanks :)
[23:47] <elmo> hmm, I've actually no idea why that broke
[23:47] <elmo> or that package is needed
[23:48] <slangasek> in karmic and above it's part of perl itself, and we're using a lintian "backport"
[23:48] <slangasek> but I don't know what changed that made lintian start wanting it /since the last time I ran lintian/
[23:48] <slangasek> maybe because I haven't done sourceful new in a while
[23:48] <elmo> is the lintian backport locally installed?
[23:48] <slangasek> tseliot: tsk, new package using debhelper 4?
[23:48] <slangasek> elmo: yes, on lp_archive's path
[23:48] <elmo> ah
[23:49] <tseliot> slangasek: I can update that
[23:50] <tseliot> it won't be a problem ;)
[23:50] <tseliot> I need something working in time for alpha 2
[23:51] <slangasek> tseliot: shouldn't the copyright holder be "Canonical Ltd"?
[23:52] <slangasek> (in debian/rules)
[23:52] <tseliot> slangasek: I work for Canonical Services Ltd
[23:52] <jpds> elmo: Alt-dragging penals was a design decision in Jaunty; bug #321032.
[23:53] <jpds> panels*
[23:54] <neXyon> cjwatson, crimsun: thx for the infos, gn8 now :)
[23:55] <cjwatson> tseliot: if you've already been explicitly told otherwise, ignore this, but it's my understanding that all copyright of Canonical group companies is owned by Canonical Ltd. regardless of which particular company you work for
[23:55] <cjwatson> tseliot: I wish https://wiki.canonical.com/LegalServices/Licensing were a bit more explicit - wonder if there's something ele
[23:55] <cjwatson> else
[23:56] <slangasek> been looking, been not finding :)
[23:56] <elmo> jpds: ah, I see, thanks