[00:22] <Incubuss> Say I was a lowly CS student who knew Python, (lol)Java and a little bit of C, what would be my best approach for getting involved?
[00:23] <cjwatson> start with http://wiki.ubuntu.com/ContributeToUbuntu and http://wiki.ubuntu.com/UbuntuDevelopment
[00:23] <cjwatson> find things that interest you personally
[00:24] <Incubuss> I'm assuming Java will be next to useless for just about everything? :P
[00:24] <cjwatson> I generally recommend against making assumptions before investigating :)
[00:25] <cjwatson> it's probably not the first language I'd recommend that Ubuntu developers learn, but it is used in some areas. Honestly, the ability to pick up new things is much more important than happening to know some languages up-front.
[00:26] <cjwatson> decent CS courses ought to teach the ability to learn, as well as just languages
[00:26] <cjwatson> and after you've learnt three languages, the fourth is easier, etc.
[00:26] <jdong> those still sound like CE courses to me, but that's a minor nitpick :)
[00:26] <Incubuss> Yeah, thats half the reason I chose Glasgow for CS was their emphasis on being able to pick op different languages fast
[00:26] <cjwatson> naming varies :)
[00:26] <RAOF> And their haskell compiler, presumably :)
[00:26] <Incubuss> Just happen to be stuck in the year where we do all Java at the moment :P
[00:27] <cjwatson> Java's used in (e.g.) the cloud computing bits we're using for the Ubuntu Enterprise Cloud
[00:27] <cjwatson> I expect that on average Python and C will be more useful though
[00:27] <Incubuss> We use Haskell for some of next year, I'm looking forward to it
[00:27] <jdong> and general knowledge of UNIX shell scripting and the likes
[00:28] <RAOF> Makefile syntax!
[00:28] <jdong> but yeah, most important is picking up new things quickly
[00:28] <Incubuss> Yeah, I'm quite happy working in Python, not so much Java
[00:28] <Incubuss> C sorry
[00:29] <cjwatson> if you find something that interests you, that's probably the single most effective way to learn new languages if necessary anyway
[00:30] <jdong> O_O ok maybe my globber is a bit too inductive...
[00:30] <Incubuss> I did a C under Linux course this semester although it was run in the Physics department so they shoved plenty at us but none if it very in depth
[00:30] <jdong>  /** krwlmix is not what I had in mind for dmesg's auto profile...
[00:30] <cjwatson> I pretty much taught myself Unix and Perl during college because it was useful for some things I wanted to build for myself
[00:33] <directhex> we had a first-year module on "unix systems administration"
[00:33] <maco> first year?? my school it's "must be senior or grad student or already know unix & c"
[00:34] <maco> turns out that last "or" means the grad students don't know what they're doing at all and hold up the undergrads who do
[00:34] <jdong> heh we didn't have any IT-related courses at all
[00:34] <cjwatson> we had enough-Unix-to-get-you-by in first year, which I think probably covered more than usual for a course with that kind of remit
[00:35] <directhex> our comsci labs were 50-50 windows and unix, and most of us learnt in first year which were the better systems
[00:35] <directhex> which kinda forced some learning
[00:35] <maco> our acm chapter has started teaching enough-unix-to-get-you-by workshops each semester for first years
[00:36] <maco> because they're not going to learn it anywhere else in the curriculum and will be rather confused in OS class when they have to unpack tarballs and copy files and all sorts of terribly hard things like that ;)
[00:36] <cjwatson> I think I was still before anyone but a fairly small percentage of geeks had their own Linux systems. Nowadays I'm sure it's different
[00:36] <maco> i'm trying to push one of the first years at my school in the motu direction
[00:37] <cjwatson> the purpose of enough-Unix-to-get-you-by used to be "how to use the faculty-provided Unix teaching systems"
[00:37]  * directhex considers FOSDEM
[00:37] <Incubuss> We do Python in 1st Year under Windows, 2nd Year Java (Windows) then 3rd & 4th year we do a host of languages on Linux machines
[00:38] <maco> the workshop i teach for acm is a bit off the unix thing. i do LaTeX.  someone else handles bash and another does vim. there's demand for eclipse now
[00:39] <maco> ah our whole time, all code is required to work on Solaris. i think they finally upgraded the machine from sol 8 to sol 10
[00:39] <cjwatson> the first Debian package I ever built came out of being fed up with the way Java classes were run; I never actually did get around to distributing that although a project that grew out of it is now used by various bits of Debian
[00:40] <cjwatson> but I've been fortunate enough never to really have had to use Java in anger since university, so other priorities took over
[00:41] <directhex> uni taught me to hate java ^_^
[00:41] <maco> java is why i cant do python
[00:43] <Incubuss> Java doesn't seem as bad as I was expecting with all the hate it gets, I'm not a fan of it but I think for teaching OO its quite a good language
[00:44] <Incubuss> I although the more I work worth it the more I get fed up of it
[05:10] <DrManhattan> what's the deal with the intel video driver? The performance is horrible compared to fedora 12
[07:21] <pitti> Good morning
[07:22] <pitti> micahg: just ask :)
[07:22] <micahg> hi pitti, about the case sensitive package names in apport
[07:22] <pitti> slangasek: pm-utils-powersave-policy is in source NEW right now (it's trivial, but I didn't ping anyone about it yet)
[07:22] <micahg> I figure that might be an easy thing and help new users
[07:23] <micahg> I know in ubuntu/debian all package names are lowercase, but regular users might not get this
[07:23] <AnAnt> Hello, sorry to ask here , but, who should we go to if someone is flooding #ubuntu ?
[07:24] <AnAnt> nevermind, someone solved it
[07:24] <pitti> slangasek: right now it only enables sata link power on >= 1 GB RAM, and only sets "min_power", perhaps it should set medium_power on low-mem systems
[07:24] <pitti> fta: doko_ fixed it in lucid now, still on the radar
[07:24] <StevenK> Morning pitti
[07:25] <StevenK> pitti: I've uploaded a NEW netbook-meta, which is effectively a copy of unr-meta, shall I just wave it through and into main?
[07:25] <pitti> StevenK: ah, for the renaming? sure
[07:26] <StevenK> pitti: It's a rename, and a few bits of fluff, since platform.lucid changed
[07:37] <dholbach> good morning
[07:37] <micahg> pitti: ?
[07:39] <pitti> micahg: hm, so you think there are users who don't know about our packaging structure, then manage to find the package name of the problem that affects them, but then somehow manage to miscapitalize it?
[07:40] <micahg> pitti: if someone uses software center to install a package, they might not notice the capitalization as it'll display with the proper name, not the pacakge name
[07:40] <micahg> like the example of gtk-recordMyDesktop
[07:41] <micahg> another one might be Abiword
[07:41] <micahg> "we" know the package name is the lower case version, but a windows user coming over to Ubuntu might not get this
[07:44] <micahg> I figured running the python equivalent of strtolower on the package name would be easy enough and possible help new users
[07:45] <micahg> pitti: ^^^
[07:45]  * nixternal hugs dholbach 
[07:46]  * dholbach hugs nixternal back
[07:48] <poolie> hi, could someone give feedback on my requested sru in https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/437626
[07:48] <poolie> is any more information needed to let it be reviewed?
[07:55] <micahg> poolie: ubuntu-motu would probably be a better place for SRU review
[07:56] <wgrant> micahg: Not for bzr, which is in main.
[07:56] <poolie> ok, thanks (sorry if appropriate)
[07:56] <micahg> oh
[07:56] <micahg> my apologies poolie
[07:56] <micahg> this is the right place
[07:56] <micahg> wgrant: I though -motu was the place for package discussion in general
[07:56] <poolie> at this point i'd just appreciate a quick scan to say whether i should be providing any more information to allow an sru review to proceed
[07:57] <wgrant> micahg: Packag*ing* discussion, perhaps.
[07:57] <persia> micahg: -motu is the place for discussion about universe packages, which often includes packages not yet in universe, hence packaging.
[07:58] <micahg> persia: wgrant: from the channel info: #ubuntu-devel is: Lucid Alpha 1 released | Archive: open | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) |
[07:58] <persia> poolie: I usually see the bug description modified to include specific test cases to aid review that the bug is fixed by the update.
[07:59] <persia> micahg: Indeed.  And when upstream comes in with an update to a package in Ubuntu main, that's part of development of Ubuntu.
[08:02] <micahg> persia: maybe someone should modify it to say main package dev in the description then...
[08:03] <persia> micahg: The topic has worked for us through now.  I suppose someone could change it.
[08:03] <micahg> persia: ok...well, now I know at least :)
[08:04] <poolie> persia: so summarizing the reproduction recipe there would help?
[08:04]  * persia digs up the current set of docs for reference
[08:06] <persia> poolie: Yeah.  According to https://wiki.ubuntu.com/StableReleaseUpdates the description is supposed to be modified to include the impact, a description of the fix, pointer to the patch, a test case, and discussion of regression potential.  But I suspect you're currently blocked on getting it sponsored rather than being blocked on the SRU team accepting it into proposed.
[08:06] <pitti> poolie: just went through the SRU bugmail, looking
[08:08] <pitti> poolie: are there other LP bugs which get fixed by this update? If so, they should be included  into the changelog
[08:08] <pitti> (the upstream changelog mentions a few)
[08:09] <pitti> poolie: it doesn't hurt to add a short description of the changes in debian/changelog
[08:09] <poolie> we should mention all of them?
[08:09] <poolie> ok
[08:09] <pitti> poolie: right, so then we can ask their reporters for testing the update
[08:12] <poolie> ok
[08:12] <poolie> anything else?
[08:20] <pitti> poolie: the descriptions of all affected bugs should be clear and preferably be reproducible (haven't checked that)
[08:20] <poolie> ok
[08:36] <poolie> pitti, thanks, new diff uploaded
[08:36] <poolie> i'll mention this in our process too
[08:36] <pitti> thanks
[08:43] <poolie> https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/16117 in case you have any comments
[08:48] <chrisccoulson> superm1 - i just saw bug 496423. does GDM have an interface for shutting down / rebooting? gnome-session just uses consolekit...
[08:49] <superm1> chrisccoulson, i thought I saw all this stuff about grabbing GDM cookies and what not in gnome-session code as I was walking around it trying to debug a different bug?
[08:49] <chrisccoulson> superm1 - it might do some GDM stuff as a fallback, but the primary method is the consolekit interface
[08:50] <superm1> chrisccoulson, I don't see any methods for halt or reboot on org.freedesktop.ConsoleKit?
[08:50] <superm1> unless that's the Restart() and Stop()?
[08:51] <chrisccoulson> superm1 - yeah, that's right
[08:53] <superm1> ah neat
[08:53] <superm1> so really, xfce4-session needs CK support
[08:55] <superm1> thanks chrisccoulson
[08:55] <chrisccoulson> superm1 - you're welcome
[08:59] <micahg> pitti: any final comments on what I proposed about ubuntu-bug?
[09:00] <pitti> micahg: well, I still think we shouldn't make it too easy to file bad bug reports :)
[09:01] <pitti> apport can digest an executable path if you don't want to bother figuring out the package name
[09:01] <pitti> but since the name already is overloaded about four times (package, executable, symptom, crash file), I don't want to make it even more fuzzy
[09:02] <micahg> pitti: ok, would it be possible to add to the error message if there is an upper case character that package names are lower case?
[09:02] <superm1> pitti, i forgot to ask you last week.  do you have some spiffy apport method to find the package that owns a file other than dpkg -S?
[09:03] <pitti> superm1: please use apport.packaging.get_file_package(filename)
[09:03] <superm1> cool! that beats what i was doing: http://linux.dell.com/git/?p=dkms.git;a=blob;f=dkms_apport.py;h=69b639192eebc53183ec4920bb8150b41e3a6a6d;hb=1f4b4607b1456c18a9d10cde1823ecef71abcbd1
[09:03] <pitti> it's not much better than dpkg -S, though, but no need to hardcode dpkg -S in hooks
[09:04] <pitti> superm1: right, please; get_file_package() is distro independent (there's an RPM implementation, too)
[09:05] <superm1> very good to know.  is apport showing up on any rpm distros by default yet that i'd be able to test this on then too?
[09:05] <pitti> superm1: not sure, but OpenSUSE has a package
[09:09] <superm1> pitti, while you're there, is there anything else useful you think I should be capturing for these DKMS build failures that occur?  the idea is that hook gets called when dkms build fails, and tries to file a bug on the package it was building for
[09:10] <pitti> superm1: you could call attach_hardware(), that might be interesting since these are usually drivers?
[09:10] <superm1> pitti, i thought about that, but pertaining to a build problem, probably wouldn't be much more than cruft
[09:11] <pitti> oh, right
[09:11] <superm1> i'm thinking the cases like where jockey installs a driver, and for some reason it doesnt build
[09:11] <pitti> superm1: another potentially useful thing might be attach_related_packages() to get version info for pacakges you don't depend on
[09:11] <mr_pouit> superm1: upstream will still rely on hal for xfce 4.8 afaik, so if we want to switch to {console,policy,device,whatever}kit, we're probably on our own at the moment
[09:11] <pitti> like gcc, binutils, etc.; those are distro specific, of course
[09:11] <pitti> and in particular, gcc-4.x tends to change with every release
[09:12] <superm1> yes that would be very good to attach then
[09:12] <superm1> mr_pouit, oh that's a shame
[09:12] <pitti> superm1: but I think the build log ought to have anything that's really generally interesting
[09:13] <pitti> I doubt that many errors are due to a binutils bug
[09:16] <geser> could a core-dev please give-back: indicator-applet indicator-messages indicator-session nautilus-sendto libpam-mount. Thanks
[09:18] <pitti> geser: doing
[09:19] <Tm_T> should I care if Intrepid mysql packages might have issue(s)? and if yes, who should I poke to make sure it's packages and not me?
[09:20] <micahg> ok, so am I supposed to ask for main SRU sponsorships in here?
[09:23] <micahg> persia: ^^
[09:30] <superm1> mr_pouit, well coming up with a patch for adding CK support shouldn't be too rough I suppose.  i can probably work something out this week
[09:31] <superm1> it's really just copying a bunch of those HAL methods, and changing a few things here and there it looks like
[09:33] <micahg> seb128: would you mind sponsoring a GTK SRU?
[09:33] <seb128> micahg, depends of the sru
[09:33] <micahg> bug 372103
[09:33] <persia> micahg: You're not supposed to ask for main SRU sponsorships anywhere, really.  But if you're stuck on the process, you can ask how that works.
[09:34] <micahg> persia: yeah, I thought about that after, that's why I asked seb as he maintains the package...I'm learning slowly...
[09:35] <seb128> I was about to read my bug email, usually no need to ping
[09:35] <seb128> it's just that I don't work much during weekends and it's monday morning there
[09:35] <micahg> seb128: ah, ok, sorry
[09:35] <seb128> anyway the change looks fine, could you give give an url to for the cgit commit?
[09:36] <seb128> I will sponsor that later
[09:36] <micahg> yeah, thanks
[09:36] <seb128> thank you for the work on it
[09:36] <soren> Keybuk: Is this a known problem? [   17.400075] plymouthd[414]: segfault at 10 ip 00007fe05f6db704 sp 00007fff904becb0 error 4 in libplybootsplash.so.2 (deleted)[7fe05f6cd000+14000]
[09:36] <micahg> seb128: in the description or a comment?
[09:36] <soren> Keybuk: I don't get any boot splash or anything like that at all.
[09:36] <seb128> micahg, comment
[09:37] <micahg> seb128: done and thanks, now time for me to sleep
[09:37] <soren> Keybuk: That's with 0.8.0~-5, by the way.
[09:38] <seb128> micahg, thanks
[09:38] <seb128> soren, use apport to report the crash?
[09:38] <maco> ~- ??
[09:38] <seb128> soren, hard to tell if a crash is known without seeing a stacktrace...
[09:40] <soren> seb128: There are no bugs (except for the MIR "bug") filed against Plymouth. I just don't know if it's because it's not expected to work at all yet. If it isn't, there's little point in filing bugs about it.
[09:41] <seb128> soren, well, it's not complicated to let apport send the crash bug either
[09:42] <soren> Fine.
[09:42] <soren> Where do I enable apport? AIUI, it's not enabled in Lucid by default yet.
[09:42] <soren> Ah, found it.
[09:43]  * soren sighs deeply and reboots for the 16th time today
[09:43] <soren> Hang on, isn't plymouth started from initramfs?
[09:44] <soren> meh
[09:47] <cjwatson> Keybuk: the point of starting-dm wasn't (mainly) to abstract away 'start' events - it was to arrange for the splash screen not to get an event if you boot with 'text' etc. which causes gdm.conf to 'exit 0' rather than actually starting gdm. I'm not sure that this has been adequately addressed?
[09:48] <cjwatson> Keybuk: and indeed the default-display-manager stuff as well
[09:53] <soren> seb128: Alright, mr. "it's not complicated to let apport send the crash bug". apport doesn't start until runlevel 2, so there's no crash file.
[09:53] <seb128> soren, wait for Keybuk then, I was just suggesting that stacktraces are useful to know what happens on crashes, I don't care enough to argue
[09:54] <soren> seb128: Well... You started it :D
[09:54] <seb128> right, now I stop it too ;-)
[09:54]  * soren hugs seb128 
[09:54]  * seb128 hugs soren
[09:58] <directhex> i didn't see a reply, and my scrollback is long gone. is the plan to put firefox 3.6 in lucid?
[09:59] <pitti> directhex: if it's released in time, sure
[10:06] <Keybuk> cjwatson: right, if you notice, plymouth doesn't have a "stop on startting gdm"
[10:06] <Keybuk> instead gdm itself talks to plymouth to tell it to deactivate the splash but hold the framebuffer
[10:06] <Keybuk> (so it can do the smooth X transition)
[10:06] <Keybuk> and once it's started X, tells plymouth to quit - or if it fails to start X, tells plymouth to reset the console, etc.
[10:06] <Keybuk> otherwise if X failed to start, the console would stick with the last plymouth frame
[10:07] <cjwatson> Keybuk: I agree that that's better, but I see no way to make it work with ubiquity
[10:07] <Keybuk> and you wouldn't be able to recover from that :)
[10:07] <Keybuk> cjwatson: what's ubiquity got to do with it?
[10:07] <cjwatson> you knew this on Friday
[10:07] <cjwatson> 11:05 <Keybuk> if ubiquity was depending on it, then that was definitely a bug ;)
[10:07] <cjwatson> except I disagree :)
[10:07] <Keybuk> ubiquity can just use "starting gdm" no?
[10:07] <cjwatson> oh, yeah, I thought ubiquity used starting-dm but apparently not
[10:08] <Keybuk> it didn't when I glanced at it
[10:08] <cjwatson> ubiquity does *emit* starting-dm though
[10:08] <cjwatson> and I notice that plymouth doesn't cope with ubiquity starting
[10:08] <Keybuk> right, ubiquity may need the same logic as gdm to make plymouth go away
[10:09] <Keybuk> depending on whether you want a flicker-free transition into ubiquity or not <g>
[10:09] <cjwatson> ok, so the reason I came into this is because the gdm/usplash pair is uninstallable :)
[10:09] <cjwatson> can we switch usplash out from the seeds now?
[10:09] <Keybuk> usplash isn't seeded
[10:09] <Keybuk> I took it out last week
[10:09] <cjwatson> the livefs builds disagree :)
[10:09] <Keybuk> the 20091212 and 20091213 cd images built fine without it
[10:10] <cjwatson> yeah, I'm getting lots of mailspam about it though
[10:10] <Keybuk> "mailspam" ?
[10:10] <cjwatson> I guess because several flavours other than Ubuntu still use it
[10:10] <cjwatson> I get mail when livefs builds fail
[10:10] <Keybuk> xubuntu was certainly updated a couple of days ago
[10:10] <maco> kubuntu still does maybe?
[10:11] <cjwatson> Package: usplash
[10:11] <cjwatson> Task: kubuntu-desktop, kubuntu-netbook, edubuntu-desktop-kde, xubuntu-desktop, mobile-mid, mythbuntu-backend-master, mythbuntu-backend-slave, mythbuntu-desktop, mythbuntu-frontend, ubuntu-netbook-remix
[10:11] <cjwatson> so I guess we need to fix all of those up
[10:11] <Keybuk> I guess the seed owners haven't caught up
[10:12] <cjwatson> where do the themes come from?
[10:12] <Keybuk> what themes?
[10:12] <cjwatson> does plymouth not display anything?
[10:12] <Keybuk> yes, there's a basic built-in theme that tseliot did
[10:12] <Keybuk> that's included in the plymouth package
[10:12] <cjwatson> oh, nobody's worked on external theme packages?
[10:13] <Keybuk> external theme packages "just work"
[10:13] <Keybuk> there just aren't any
[10:13] <Keybuk> it would be better to say that nobody's made any themes yet :p
[10:13] <tseliot> Keybuk: have you included my theme already?
[10:13] <Keybuk> tseliot: yes
[10:13] <cjwatson> do you divert /lib/plymouth/ubuntu-logo.png or something?
[10:13] <Keybuk> cjwatson: new themes install their own artwork, and just call plymouth-set-default-theme in their postinst on install
[10:14] <cjwatson> ah
[10:14] <tseliot> cjwatson: the logo can be set with a configuration flag in the debian/rules but you can ignore it in the theme
[10:15] <Keybuk> tseliot: that's not really relevant - we wouldn't want to rebuild plymouth for every new theme <g>
[10:15] <tseliot> as the theme is what tells plymouth to draw things
[10:15] <tseliot> Keybuk: as I said, you can ignore that logo and use whatever png you have in the theme directory as a logo
[10:16] <Keybuk> tseliot: how come you ignore the background colours but not the logo btw? :p
[10:16] <cjwatson> so rather than editing flavours' seeds for them, I think I'd prefer to wait for them to convert their usplash theme packages
[10:17] <tseliot> Keybuk: because that's on my TODO list? :-P
[10:17] <Keybuk> cjwatson: I tend to just leave flavours alone
[10:17] <persia> At least in the case of mobile-mid, it's not worth changing the seed since it is fast losing relevance (and with luck, will not exist in lucid)
[10:18] <mr_pouit> cjwatson: I've xubuntu-artwork 0.39 stuck in new, that's why usplash is still pulled in xubuntu
[10:18] <seb128> bah, bug #495868, apport should really prevent user to file a bug on each every package on a failing upgradfe
[10:18] <seb128> the guy opened a zillion bugs
[10:19] <tseliot> Keybuk: does plymouth work reliably now?
[10:19] <tseliot> on vt7, I mean
[10:19] <Keybuk> tseliot: it works for me
[10:19] <seb128> mvo, ^ isn't apt supposed to avoid those?
[10:19] <tseliot> Keybuk: how did you fix it?
[10:19] <Keybuk> tseliot: which bug are you thinking of ?
[10:20] <mvo> seb128: it does basic dup detection, let me check
[10:20] <tseliot> Keybuk: the one in which error messages overwrite whatever plymouth draws
[10:20] <cjwatson> Keybuk: that's fine, but I don't :-)
[10:21] <cjwatson> mr_pouit: ok
[10:21] <mvo> seb128: 8.10, I suspect it was not fully done back then
[10:21] <Keybuk> tseliot: I worked around it by scanning out the framebuffer back to the fbcon ;)
[10:21] <Keybuk> haven't worked out why it doesn't work without doing that yet
[10:21] <seb128> mvo, oh right, thanks
[10:22]  * seb128 delete some 70 bug email
[10:22] <tseliot> Keybuk: oh, as long as it works it should be fine for Lucid ;)
[10:22] <seb128> some users a really motivated to open that number of bugs
[10:22] <tseliot> mat_t: news from the design team?
[10:24] <ogra> Keybuk, i'm on vacation but will try to provide you a backtrace of the amrel gdm issue if i find a spare minute, i suspect that it could be caused by the fact that nobody included the new populatie_rootfs speedup patches in the armel kernels yet though
[10:24] <Keybuk> ogra: they're not included in the i386 kernel yet either
[10:25] <Keybuk> and either way, would be entirely orthogonal to gdm not starting
[10:25] <ogra> i though i saw a commit with the last upload
[10:25] <Keybuk> since gdm isn't *in* the initramfs
[10:25] <Keybuk> neither is gdm run from a kernel init function
[10:25] <ogra> oh, indeed
[10:25]  * ogra slaps forehead
[10:26] <Keybuk> tseliot: it'll look crap on multi-head
[10:26] <Keybuk> since plymouth maintains a separate framebuffer per head
[10:26] <Keybuk> each with the right resolution
[10:26] <Keybuk> but fbcon maintains a single framebuffer with the lowest common resolution cloned out to each head
[10:27] <tseliot> Keybuk: oh, that's not ideal. My theme isn't exactly ready for multihead either (but this should be easier to fix)
[10:27] <Keybuk> tseliot: your theme works fine on multihead
[10:28] <Keybuk> themes generally don't notice the difference
[10:28] <Keybuk> soren: no, not a known problem - file a bug with a stack trace
[10:29] <tseliot> Keybuk: I think Ray fixed that in plymouth therefore my theme works now. I haven't had the chance to try it yet but if you say it works well with screens which use different resolutions..
[10:30] <metellius> i'm trying to help the intel-xrog-driver people with debugging a bug of mine, and I'm therefore going to try a patch which includes linux-2.6/drivers/gpu/drm/drm_edid.c
[10:30] <soren> Keybuk: How do I get a stack trace? apport isn't running yet when it crashes.
[10:30] <metellius> do I have to recompile the whole kernel for this?
[10:30] <mat_t> tseliot: hey
[10:31] <mat_t> tseliot: I suggest pinging Iain
[10:31] <tseliot> metellius: yes. You can discuss this in #ubuntu-x
[10:31] <cjwatson> mr_pouit: NEWed, though I'm not sure I see any plymouth integration there
[10:31] <mat_t> tseliot: I'll poke him for you
[10:31] <tseliot> mat_t: thanks
[10:32] <soren> Keybuk: FWIW, I have an nvidia card in this laptop. No KSM, as far as I can see (console is plain 80x25).
[10:32] <mr_pouit> cjwatson: thanks. and not yet, this one only demotes usplash-theme-xubuntu to suggests.
[10:33] <Keybuk> soren: tried "start plymouth" when X is not running?
[10:36] <soren> Keybuk: Nope. I'll try that in a minute.
[10:55] <soren> Keybuk: No crash :-/
[10:55] <Keybuk> soren: check with pitti on that one
[10:55] <soren> Keybuk: ..nor any splash screen or anything.
[10:56] <soren> Keybuk: I mean.. It didn't crash.
[10:56] <soren> Keybuk: Not "no crash file". Literally no crash.
[10:56] <Keybuk> no idea then
[10:56] <soren> Keybuk: Is plymouth known to work on any nvidia hardware?
[10:56] <Keybuk> no
[10:57] <Keybuk> though you should at least get a text mode variant
[10:57] <soren> Keybuk: What would that look like?
[10:57] <Keybuk> black screen with something that looks like a progress bar along the bottom
[10:58] <soren> Keybuk: Hm.. Nope, I don't see anything like that.
[11:06] <cjwatson> james_w,jdstrand,Riddell,kirkland,pitti,Keybuk,seb128,StevenK,slangasek: could you check ~lp_queue/sync-queue/{failed,rejected}/ on cocoplum and remove anything you don't need from there, please? I think practically everything in there is probably junk, but it isn't auto-purged at the moment and it's quite big
[11:07] <Riddell> cjwatson: so that's where they go.  all find to scrap with me
[11:08] <cjwatson> Riddell: done, thanks
[11:08] <Keybuk> cjwatson: wiped
[11:09] <tseliot> soren, Keybuk: plymouth should work with nvidia (try the latest Mandriva and see). Maybe fbcon or whatever we use was not loaded?
[11:10] <Keybuk> tseliot: it so doesn't ;)
[11:10] <Keybuk> plymouth might work with the nouveau drm driver
[11:10] <Keybuk> but that's not in our kernel
[11:11] <seb128> cjwatson, cleaned
[11:11] <tjaalton> linus pulled it in .33 btw
[11:11] <tjaalton> nouveau, that is
[11:11] <tseliot> Keybuk: I was referring to the proprietary driver. Maybe the module isn't loaded?
[11:11] <Keybuk> tjaalton: I thought it was just in -staging
[11:12] <tjaalton> Keybuk: correct
[11:12] <Keybuk> tseliot: the proprietary driver doesn't have a framebuffer
[11:12] <Keybuk> tjaalton: that's a vast difference from being pulled into .33
[11:12] <Keybuk> -staging != linux-2.6
[11:12] <Keybuk> -staging is "we like you, but aren't willing to go steady until you sort our your personal hygiene issues"
[11:13] <tjaalton> but it's still in the tarball, no?
[11:13] <Keybuk> tjaalton: no
[11:13] <StevenK> cjwatson: If you have a few seconds, can you review https://code.edge.launchpad.net/~stevenk/launchpad/netbook-cron/+merge/16115 and http://paste.ubuntu.com/341081/
[11:13] <Keybuk> completely different git tree
[11:13] <tseliot> Keybuk: I think it should work as usplash does with nvidia in Karmic
[11:13] <tjaalton> but it _was_ pulled in linux-2.6.git
[11:13] <cjwatson> StevenK: I already did, for the former; merging the latter now
[11:13] <Keybuk> tseliot: why? plymouth doesn't have an svgalib renderer
[11:13] <StevenK> cjwatson: I can merge the latter, I just want sign-off
[11:14] <Keybuk> tjaalton: that being said, you're quite right, it *is* in linux-2.6 - not staging
[11:14] <cjwatson> StevenK: signed off, but before you commit, run 'rm -rf ubuntu-tasks && make ubuntu-tasks && bzr add' and check the result
[11:15] <tjaalton> Keybuk: "Kconfig under staging for now", that confused me
[11:15] <Keybuk> tjaalton: I see where the confusion comes - it was set up to go into staging, but Linus pulled it himself
[11:15] <Keybuk> yeah
[11:15] <StevenK> cjwatson: In a Lucid chroot, or it doesn't matter?
[11:15] <Keybuk> that's just confusing everyone clearly ;)
[11:15] <cjwatson> StevenK: it doesn't matter
[11:15] <tjaalton> yep :)
[11:15] <tseliot> Keybuk: I'll check Mandriva again
[11:15] <Keybuk> tseliot: Mandriva probably has nouveau
[11:15] <tseliot> Keybuk: fcrozat in #plymouth should know how it works.
[11:16] <tjaalton> anyway, it should be much easier to have something sensible for lucid, and not just some random branch from somewhere
[11:16] <Keybuk> tseliot: quick google sez that Mandriva ship nouveau in their kernels
[11:16] <tseliot> Keybuk: and no, I installed the proprietary driver in Mandriva and got the plymouth splash
[11:16] <Keybuk> tseliot: no idea why that would work
[11:16] <tseliot> I'll have to find out
[11:17] <tjaalton> it starts with nouveau KMS and the nvidia blob will then steal everything?
[11:17] <Keybuk> tjaalton: if you load nouveau, you can't load the nvidia blob
[11:17] <Keybuk> in fact, I think you literally can't load
[11:17] <Keybuk> ie. nouveau will claim the device through the usual agpgart stuff
[11:17] <ghostcube> noveau ready for take off now ?
[11:17] <Keybuk> which means the nvidia binary blob stolen agpgart code can't use it ever
[11:17] <tjaalton> Keybuk: ok. I've never tried it myself so..
[11:18] <Keybuk> it's why you have to reboot to switch drivers now
[11:31] <tseliot> Keybuk: "it still works on VESA framebuffer. For chipsets not yet supporting KMS, we can still have graphical boot"
[11:31] <tseliot> source: http://wiki.mandriva.com/en/2010.0_RC_1
[11:31] <tseliot> "it" being "plymouth
[11:31] <tseliot> "
[11:34] <cjwatson> Riddell: re bug 494997, do you know if kdesudo still causes unexplained partitioning problems? ubiquity-wrapper says:
[11:34] <cjwatson>             #temporarily force sudo until we work out why kdesudo stops it passing partitioning stage
[11:34] <cjwatson>             toexec = ['sudo', '-E']
[11:36] <Riddell> cjwatson: doesn't seem to no since we all used kdesudo while testing alpha 1
[11:36] <Riddell> so should be safe to go back to that
[11:37] <cjwatson> Riddell: ok, I'll remove that hack then, thanks
[11:37] <cjwatson> it's from intrepid
[11:50] <tseliot> soren: does Plymouth work if you load uvesafb?
[11:59] <StevenK> cjwatson: tasksel looks good, shall I commit, tag and upload, or would you prefer to eyeball it first?
[12:06] <cjwatson> StevenK: go ahead
[12:11] <soren> tseliot: I'll make a note to check next time I have to reboot.
[12:11] <soren> tseliot: Might be a few hours.
[12:11] <tseliot> soren: ok, thanks
[12:12] <soren> james_w: Would you mind syncing libcloud from unstable for me, please?
[12:18] <soren> Or any other archive admin, I suppose ^^. (james_w is just listed as the "on duty" one today)
[12:20] <geser> I was looking at the FTBFS of db4.7 (see also Debian bug #560641). It's because dh_nativejava (from libgcj-common) needs debhelper. Should libgcj-common depends on debhelper (doesn't look like the best idea based on the rdepends) or should db4.7 depend on debhelper (even if it doesn't use it directly)?
[12:22] <cjwatson> geser: I believe I ran across the same thing in the past and said the former
[12:22] <cjwatson> or maybe something even higher up the stack, given the rdepends
[12:22] <cjwatson> I definitely dealt with this at some point ...
[12:22] <cjwatson> ah, no, I went for the latter
[12:22] <cjwatson>      - Build-depend on debhelper, needed by dh_nativejava. It doesn't seem
[12:22] <cjwatson>        reasonable for libgcj-common to depend on debhelper since that's also
[12:22] <cjwatson>        used by run-time libraries.
[12:23] <cjwatson> that's from the db changelog in Ubuntu
[12:23] <geser> thanks, will do that too then
[12:24] <cjwatson> geser: in fact I'd recommend generally checking the db diff over for things that need to be applied to db4.7
[12:31] <fagan> mvo: could you look at this patch Bug #494845
[12:33] <pitti> cjwatson: sync-queue> cleaned my stuff
[12:37] <StevenK> cjwatson: I've cleaned up my sync-queue stuff too
[12:43] <geser> is someone working on merging perl? there are several perl packages in DEPWAIT waiting on perl >= 5.10.1
[13:09] <Kano> hi, is there a tool that evaluates the fdi files?
[13:13] <Kano> hal is not there, so what does it now
[13:17] <pitti> Kano: nothing
[13:17] <Kano> so how should the xorg autoconfig work now
[13:17] <Kano> like synaptics or other devices
[13:17] <pitti> Kano: well, we'll probably bring back hal into the default install (mainly for brightness handling), but we want to run without hal for a while to detect regressions
[13:17] <pitti> Kano: xorg uses udev now
[13:18] <Kano> well then check for old fdi files, there are quite a lot left
[13:18] <pitti> Kano: we transitioned the synaptics one to udev rules already
[13:18] <pitti> as well as the basic keyboard ones
[13:19] <pitti> there's still a couple which we have to rewrite, most notably the wacom ones
[13:19] <Kano> also vbox?
[13:19] <pitti> but we need a newer wacom driver first
[13:19] <Kano> how to force udev to load new rules?
[13:19] <pitti> Kano: oh, vbox ships them as well? Can yuo please create a bug report for that and assign to me?
[13:19] <pitti> I'll have a look
[13:20] <Kano> well i wrote a script that could install vbox addons automatically - even in live mode
[13:20] <Kano> using hal it needed a hal restart
[13:22] <tseliot> pitti: what is it that does brightness handling and uses hal?
[13:22] <pitti> tseliot: gnome-power-manager
[13:23] <pitti> tseliot: it should work without hal for cards/drivers supporting xbacklight
[13:23] <pitti> but that's only very few yet
[13:23] <tseliot> pitti: that would be with open source drivers, right?
[13:23] <pitti> well, I'm on i945 here, and it doesn't even work here
[13:23] <tseliot> that's an RandR property
[13:24] <pitti> and I doubt that it works with proprietary nvidia/fglrx
[13:24] <tseliot> pitti: but does g-p-m use RandR to set the backlight? If not, you can do it from the command line with xrandr
[13:25] <pitti> it does, yes
[13:25] <pitti> and falls back to hal if it doesn't support  xbacklight
[13:27] <tseliot> pitti: it would be interesting to see why it doesn't work with your card without hal. Does it work with xrandr? (I can give you the exact command if you want)?
[13:29] <pecisk> btw, Xorg hakers, is there any way to get LiveCD iso with nouveau mentioned in https://edge.launchpad.net/~xorg-edgers/+archive/nouveau?
[13:31] <pitti> tseliot: hm, I need to reboot first (it's docked and on external screen right now); will try in 5 mins
[13:33] <tjaalton> pecisk: too much work imo. the kernel will hopefully have the needed bits before too long
[13:37] <tseliot> pitti: now I see why it doesn't work: KMS. See bug #397617
[13:40] <cjwatson> james_w: I'd like to replace lp:ubuntu/grub2 with a branch off Debian's bzr maintenance branch, but I can't easily import the full history there so I'd like to keep the old import branch around for historical reference. What's the best way to do this?
[13:47] <james_w> cjwatson: we can just change what lp:ubuntu/grub2 points to, the old branch will be available under its full name
[13:48] <cjwatson> james_w: so I just push to lp:~ubuntu-core-dev/ubuntu/lucid/grub2/lucid and let you know?
[13:49] <james_w> cjwatson: indeed
[13:49] <cjwatson> ok, thanks
[13:54] <tseliot> Keybuk: they use (u)vesafb to get plymouth to work with nvidia
[13:55] <tseliot> Keybuk: would it be possible to use it only for fglrx and nvidia?
[13:56] <Keybuk> tseliot: vesafb means no suspend/resume
[13:57] <cjwatson> I wonder whether that's true for uvesafb too
[13:58] <tseliot> and I wonder whether suspend/resume works reliably with fglrx and nvidia with or without uvesafb
[13:58] <Keybuk> we don't want uvesafb
[13:58] <Keybuk> at all
[13:58] <cjwatson> tseliot: anyway, the plan of record was to use vga16fb for this, even though its output is less pretty
[13:58] <Keybuk> v86d is not made of kittens
[13:58] <tseliot> cjwatson: ah, right
[13:59] <tseliot> so Keybuk why don't we use that and solve the problem with nvidia?
[13:59] <tseliot> or am I missing something?
[13:59] <Keybuk> tseliot: use what?
[13:59] <tseliot> Keybuk: vga16fb
[14:00] <Keybuk> tseliot: as cjwatson just said, the plan *is* to use it
[14:01] <tseliot> Keybuk: so is soren's problem just temporary? I mean, until we use vga16fb?
[14:01] <Keybuk> I don't know what soren's problem is
[14:02] <soren> I get that a lot.
[14:02] <james_w> soren: done
[14:02]  * soren hugs james_w 
[14:02] <soren> james_w: Thanks!
[14:03] <tseliot> Keybuk: ok, never mind then ;)
[14:06] <pitti> tseliot: re
[14:07] <pitti> tseliot: computer is undocked now, using internal lvds; xbacklight says "No outputs have backlight property"
[14:07] <tjaalton> it works on my intel
[14:08] <tseliot> pitti: right. It looks like we have no backlight interface for intel in /sys/class/backlight in karmic (with KMS)
[14:08] <pitti> /sys/class/backlight/dell_backlight/ exists here
[14:08] <tseliot> tjaalton: with KMS and with Karmic's driver?
[14:08] <tseliot> oh
[14:08] <pitti> and it does work with hal
[14:08] <pitti> $ cat /sys/class/backlight/dell_backlight/actual_brightness
[14:08] <pitti> 4
[14:08] <tseliot> I have none on my pineview card
[14:08] <pitti> and when I crank it up with Fn, I get "6"
[14:09] <tjaalton> tseliot: lucid
[14:09] <tjaalton> but I guess it worked with karmic too
[14:09] <tjaalton> but this is a lenovo..
[14:10] <pitti> tseliot: I'm on COTD lucid, and it doesn't work either, so it's not 397617
[14:10]  * tseliot nods
[14:10] <tseliot> it must be a different issue
[14:11] <tseliot> pitti: does grep backlight /var/log/Xorg.0.log show anything useful?
[14:11] <pitti> no hits
[14:12] <pitti> tseliot: xrandr --properties|grep back is empty, too
[14:12] <tseliot> pitti: and what does xrandr --props do?
[14:12] <pitti> isn't that the same?
[14:13] <pitti> anyway, http://paste.ubuntu.com/341190/
[14:13] <tseliot> yes, it's not there
[15:10] <geser> anyone willing to sponsor a perl merge? bug #496556
[15:12] <rahul_> geser i am a total noob but why do you need someone to sponsor a merge ?
[15:12] <azeem_> rahul_: because not everybody has permissions to change the archive
[15:13] <rahul_> so once you have made the changes in the local branch you get it reviewed by whom ?
[15:14] <rahul_> is this the process called sponsoring ? or merging it into the main branch ?
[15:16] <rahul_> so once you have made the changes in the local branch you get it reviewed by whom ?
[15:16] <rahul_> sorry i am not trying to be annoying , just looking for answers.!!
[15:17] <maco> submit a merge proposal
[15:17] <maco> ~ubuntu-dev is default reviewer on them, i think
[15:18] <rahul_> thanks maco ...!!
[15:18] <rahul_> one more question what are the different bug stages like , basically i am trying to get familiar with the lingo
[15:19] <rahul_> like triaging
[15:19] <maco> https://wiki.ubuntu.com/Bugs/Status
[15:20] <rahul_> awesome ..!!!!!!! thanks a ton
[15:25] <jelmer> mvo: Hi
[15:29] <mvo> hey jelmer
[15:30] <jelmer> mvo: Do you happen to know what the encoding of the apt Release file is ?
[15:31] <mvo> jelmer: the Release file should just be ascii most of the time, but utf-8 should work too
[15:32] <jelmer> mvo: Thanks
[15:49] <cjwatson> Keybuk: BTW, lp:~cjwatson/ubiquity/plymouth is my first cut at dealing with plymouth integration in ubiquity; I won't merge it until plymouth's actually on live CDs though
[15:50] <barry> cjwatson: did you see my updated merge proposal?
[15:50] <cjwatson> yes, I did, thanks - on my queue for today
[15:50] <barry> cjwatson: thanks!
[17:15] <cjwatson> Keybuk: is the code for your daily-bootchart stuff available anywhere? I'd like to adapt it to show manual partitioner benchmarks (mostly interested in the stuff to draw vertical budget lines)
[17:19] <seb128> cj
[17:19] <seb128> cjwatson,
[17:19] <seb128> pybootchartgui (0+r139) lucid; urgency=low
[17:19] <seb128> ...
[17:20] <seb128> "  * Add --annotate option, permitted multiple times; takes a comma-separated
[17:20] <seb128>     list of processes and draws a dashed red line vertically across the chart
[17:20] <seb128>     at the point the first of the named processes is started."
[17:20] <seb128>  
[17:20] <seb128> cjwatson, oh, you probably mean the side which determine when xorg is loaded, etc?
[17:23] <cjwatson> --annotate is useful, thanks, but ideally I did mean the autodetection as well
[17:30] <seb128> cjwatson, http://people.canonical.com/~seb128/guess-time.py
[17:30] <seb128> cjwatson, he gave me that some time ago, that give the linux, xorg, desktop times
[17:31] <cjwatson> great, thanks
[17:31] <seb128> np
[17:32] <joaopinto> I am unable to import libxml2 from python2.5, python2.5 will still be available on Lucid ?
[17:42] <ScottK> joaopinto: It is already gone.
[17:43] <joaopinto> hum, so I have it from the relase upgrade
[17:43] <ScottK> Yep
[17:44] <cjwatson> damnit, I want to be able to run google over Ubuntu source code
[17:44] <joaopinto>         500 http://pt.archive.ubuntu.com lucid/main Packages
[17:44] <cjwatson> seb128: where does the "as superuser" thing in window titles in lucid come from?
[17:44] <joaopinto> python2.5 was upgrade from lucid repos :)
[17:45] <seb128> cjwatson, it's a compiz thing
[17:45] <seb128> or I think it's a compiz thing
[17:45] <seb128> check with Amaranth
[17:45] <cjwatson> ok, I just want to be able to suppress it for the installer really
[17:45] <cjwatson> "Install (as superuser)" -> "eh?"
[17:46] <gigabytes> ahah :)
[17:46] <cjwatson> not compiz
[17:47] <joaopinto> ScottK, it is still available from the repositories, you meant is not used by default any longer ? That was already in karmic :)
[17:47] <lutin> in the case rmadison gives several results for the same source package for the same suite, is there a way for requestsync to pick the correct version, and not the first result ?
[17:47] <cjwatson> lutin: can't it use rmadison -a source?
[17:48] <ScottK> joaopinto: It's not a 'supported python' version so modules aren't built for it anymore (as 2.4 was in Karmic).
[17:48] <joaopinto> ScottK, ah ok, tks
[17:49] <lutin> cjwatson: well it probably does, the thing is that it gives me three different versions for unstable alone
[17:58] <cjwatson> lutin: example?
[17:59] <lutin> cjwatson: rmadison eina -u debian
[18:02] <cjwatson> lutin: blink. that seems like a bug in Debian's database
[18:02] <cjwatson> but if not then I guess requestsync will have to sort by newest or something
[18:08] <Keybuk> cjwatson: absolutely, it's in ../daily-scripts ;)
[18:08] <Keybuk> seb128 was right that the code that does the red dashed lines is just using --annotate though
[18:09] <cjwatson> aha, thanks
[18:11] <Keybuk> incoming.sh does that
[18:19] <Keybuk> cjwatson: your u6y patch looks right to me
[18:25] <damjanzg> I have just one question. What is bare minimum that would give me a chance to start develop for ubuntu?
[18:26] <ion> /bin/sh and /bin/cat
[18:27] <ScottK> damjanzg: Showing up and wanting to help.
[18:28] <damjanzg> OK, I think that wanting to help is not questionable.
[18:29] <damjanzg> I know that there is no ultimate guideline for learning, but some would be helpful.
[18:30] <ScottK> damjanzg: A lot of it depends on where your interests are.  What do you want to make better about Ubuntu?
[18:32] <damjanzg> To be honest, my primary goal is to beather learn programming, and I want to no the lowest painful way, if there is one.:)
[18:33] <ScottK> OK, well it's hard to make suggestions about where to start with just that.
[18:33] <ScottK> What programming do you know already?
[18:34] <damjanzg> I know, C. But nothing major that I have wrote, except some mathematical algorithms.
[18:34] <damjanzg> And I am in process of learning python.
[18:41] <ScottK> We use both those, so it's back to the question of interest.
[18:43] <ion> keybuk: /usr/share/initramfs-tools/init should probably do mount -t devtmpfs,tmpfs ... /dev
[18:44] <Keybuk> ion: yes, now that the kernel is uploaded
[18:44] <Keybuk> though not until mountall does the same
[18:45] <Keybuk> (I'm going to do that tomorrow, I want to see a bootchart with just the -7 -> -8 change on the dailies
[18:45] <Keybuk> adding the new mountall+plymouth would muddy that quite a lot)
[18:45] <ion> Ack
[18:45] <Keybuk> your fsck priority changes are *nice* btw ;)
[18:45] <ion> :-)
[18:46] <Keybuk> that's a trick worth remembering
[18:46] <hyperair> plymouth? =0
[18:46] <hyperair> i thought we were sticking with usplash
[18:46] <Keybuk> rather than serialise things that content on CPU or I/O - run them in parallel, use priorities, and CFQ actually does the right thing
[18:46] <Keybuk> kernel scheduler in working shocker
[18:53] <ion> keybuk: busybox mount doesn’t seem to support -t foo,fallback,bar
[18:55] <Keybuk> you would need to be more clever anyway
[18:56] <Keybuk> you need to mknod if you mount tmpfs not devtmpfs
[18:57] <ion> The scripts seem to do [ -e /dev/foo ] || mknod /dev/foo ...
[18:59] <Keybuk> yeah
[18:59] <Keybuk> doing it properly eliminates those stat() calls :p
[19:00] <ion> Alright
[19:00] <ion> Btw, as for a lot of package changes muddying the bootchart numbers; what i proposed some time ago would have fixed that. ;-)
[19:01] <Keybuk> ion: what's that?
[19:01] <Keybuk> the incremental upgrade stuff?
[19:01] <ion> Yeah
[19:01] <Keybuk> would have done things in the wrong order in this case too
[19:01] <ion> Ok
[19:01] <Keybuk> the kernel and initrd don't come from the squashfs, but the iso image, remember
[19:14] <Keybuk> the thing I like about these Dell Minis is how damned predictable they are
[19:14] <Keybuk> http://people.canonical.com/~scott/daily-bootcharts/20091214-sam.png
[19:14] <Keybuk> vs.
[19:14] <Keybuk> http://people.canonical.com/~scott/daily-bootcharts/20091214-clank.png
[19:15] <ion> :-)
[19:17] <smoser> anyone done a kvm install of lucid server ? i just went through one using alpha1 iso and grub is hanging
[19:18] <smoser> kvm disk was using '-hda' (ide)
[19:24] <cragdor> Anyone got a setup to install a development VM for Kubuntu(Latest) and connect to the SVN?
[19:33] <cjwatson> barry: merged and uploaded (congratulations, your first upload ...)
[19:36] <barry> cjwatson: saw that, thanks!
[19:37] <barry> cjwatson: if you've got another one, i'd like to try it again with some of the things i've learned
[19:41] <ScottK> slangasek: u-d-a moderation queue should have something for you to review.
[19:46] <smoser> shoot... seems like user error above.
[20:17] <wgrant> Is everyone fine with 3.0 support being turned on in LP for Lucid as soon as it's all ready?
[20:17] <lucas> wgrant: just curious. what's the alternative?
[20:17] <superm1> is there any reason people wouldn't want it turned on ? :)
[20:18] <wgrant> superm1: I don't know, but I'd like to be really sure before changing behaviour like that.
[20:19] <cjwatson> wgrant: please do it :)
[20:19] <wgrant> cjwatson: Great, thanks.
[20:20] <wgrant> It's all landed, so should roll out on Wednesday at 2200UTC. But it cannot be enabled before dpkg is upgraded on the production Soyuz machines, which I believe hasn't happened yet.
[20:21] <cjwatson> being tested at the moment, I believe
[20:21] <wgrant> Great.
[21:20] <ion> dkms (2.1.1.0-0ubuntu1): * Convert DKMS to an upstart script that starts up before GDM or KDM can start.  This ensures that drivers are built before X tries to start. (LP: #453365)
[21:20] <ion> /etc/init/dkms_autoinstaller.conf doesn’t seem to have *anything* to delay gdm.
[21:25] <slangasek> ion: I concur; reopen the bug?
[21:26] <superm1> ion, it stops gdm
[21:27] <superm1> look at the gdm task for that bug
[21:27] <superm1> after gdm is stopped, dkms will issue a signal to start it back up when it's ready
[21:30] <cjwatson> seb128: that "(as superuser)" thing is actually from metacity; I happen to know upstream so I've asked him
[21:31] <seb128> oh ok
[21:31] <seb128> there was some discussion about doing that with the compiz decorator some weeks ago too
[21:34] <ion> superm1: How about just dkms_autoinstaller.conf: ‘start on filesystem or starting-dm’ and let Upstart block gdm when it emits starting-dm in case dkms_autoinstaller is still running?
[21:34] <superm1> ion, you dont want it blocking for all modules
[21:34] <superm1> ion, only for fglrx and nvidia
[21:36] <ion> superm1: Also, don’t the ‘build-failed’ and ‘build-successful’ events have a bit too generic names? How about dkms-build-*?
[21:37] <superm1> what else uses build-failed or build-successful?
[21:38] <ion> Nothing should – somethingelse should use somethingelse-build-*. :-P
[21:39] <baddog> Red Hot Chili Peppers - Cant Stop
[21:39] <baddog> er.
[21:39] <baddog> sorry 'bout that >.>
[21:42] <superm1> ion, and gdm doesn't emit starting-dm anymore, so there is no way could have blocked on that
[21:53] <chrisccoulson> hi cjwatson - i can't seem to upload liboobs and gnome-system-tools. is that behaviour expected?
[21:59] <cjwatson> chrisccoulson: afraid so, they're currently marked as 'desktop-core' rather than 'ubuntu-desktop'. See https://lists.ubuntu.com/archives/ubuntu-devel/2009-November/029623.html for some commentary on this kind of subject
[22:01] <chrisccoulson> cjwatson - thanks, that makes sense now
[22:11] <lamont> cjwatson: I'm looking at the implicit-pointer-functions hook... would inline be something reasonable? (we run sbuild --nolog, so I don't have a handy file lying around to feed the script, but I could teach it to do it as part of the command pipe of sbuild
[22:11] <slangasek> cjwatson: ~lp_queue/sync-queue/{failed,rejected}/> swept
[22:11] <cjwatson> lamont: inline?
[22:11] <lamont> done inline, the errors would come where the conversion abuse happens, instead of in a lump at the end.
[22:12] <cjwatson> as long as it doesn't stop the build immediately
[22:12] <lamont> not until it finishes
[22:12] <lamont> it reads to EOF
[22:12] <cjwatson> I don't see a problem with that, then, unless I'm failing to see why it might be problematic
[22:13] <lamont> our current use (debian), it all happens at the end-ish part of the log, right after 'Built successfully', declaring it to be a lie.
[22:13] <slangasek> ScottK: u-d-a> kind of a short message? :)  what are the implications for people doing merges &c.?
[22:13] <lamont> done inline, you'd have a build log that claims "successful", and a failed build
[22:14] <ScottK> slangasek: It's more don't file bugs when import foo doesn't work with python2.5 anymore.
[22:16] <cjwatson> lamont: oh, right - yes, inline makes much more sense
[22:18] <lamont> cjwatson: ok.  of course, getting the compiler to do this for us would be even better in that case...
[22:18] <lamont> but ok
[22:26] <bryce> slangasek, pitti:  we're going to be renaming 'wacom-tools' to 'xserver-xorg-input-wacom' (or maybe xf86-input-wacom) to follow Debian and upstream  - do we need a new MIR for renames?
[22:26] <slangasek> bryce: nope, just a reminder when it's in the NEW queue so we know what to link it to
[22:27] <slangasek> bryce: is this rename source&binary, or source-only?
[22:27] <bryce> slangasek, wacom-tools already provides an xserver-xorg-input-wacom binary afaik so I think it's mostly a source rename
[22:27] <slangasek> ok, cool
[22:28] <bryce> slangasek, this is the last bitty piece needed to get X off HAL :-)
[22:28]  * slangasek dances on hal's grave
[22:28] <StevenK> It's not quite buried yet?
[22:28] <slangasek> I have hal removed from my system though, and keyboard&mouse are still slow to appear on resume :(
[22:29] <slangasek> StevenK: dancing on its grave packs down the earth and prevents it from receiving a decent burial, you see
[22:29] <StevenK> Haha
[22:53] <lamont> hrm... slangasek got a handy implicit-ptr-function package lying around unfixed in lucid?
[22:53] <slangasek> lamont: no, sorry - perhaps one of the ones you filed bugs on last cycle?
[22:53] <lamont> yeah - already searching for one of those
[22:56] <slangasek> anyone else seeing indicator-applet shouting 'No indicators' in lucid?
[22:56] <slangasek> would be nice to be able to log out without hard-killing X
[23:04] <chrisccoulson> slangasek - i think it's still waiting on some builds. in the meantime, you can just do "gnome-session-save --shutdown-dialog"
[23:05] <chrisccoulson> or "gnome-session-save --logout-dialog"
[23:05] <slangasek> chrisccoulson: "waiting on some builds" - so the fix for this has already been uploaded?
[23:05] <slangasek> thanks for the workaround
[23:10] <kirkland> slangasek: hi there, I'm finally getting around to fixing Bug #437012
[23:10] <kirkland> slangasek: i'm curious about "When making the above change, additional cleanup handling should be done to identify any dpkg-statoverrides added by this package and remove them."
[23:10] <kirkland> slangasek: how do I go about doing that?
[23:17] <seb128> slangasek, you are one of the buildd admin? ;-)
[23:18] <seb128> slangasek, https://edge.launchpad.net/ubuntu/+source/indicator-applet/0.3.0-0ubuntu1 is what needs to be done
[23:18] <seb128> tedg and kenvandine forgot to use a Breaks somewhere
[23:18] <chrisccoulson> slangasek - that will fix your indicator issue ;)
[23:18] <seb128> things got out of sync without anything blocking updates
[23:19] <seb128> could somebody bump the build score for indicator-applet?
[23:20] <maxb> Hi, could I enlist a core-dev to push lp:~maxb/ubuntu/lucid/subversion/merge into lp:ubuntu/subversion? Scott Kitterman has already sponsored the upload itself, but didn't do the UDD bit of it
[23:20] <maxb> I've adjusted my branch to correspond to the package that was actually uploaded
[23:30] <slangasek> seb128, chrisccoulson: not a buildd admin, no
[23:30] <seb128> ok, so you will have to wait for those to build
[23:31] <slangasek> kirkland: for override in $(dpkg-statoverride --list $pattern); do <check that it matches what we added previously>; dpkg-statoverride remove $file; done
[23:32] <kirkland> slangasek: okay, thanks, i have a diff you can spot check
[23:33] <slangasek> kirkland: a bit tied up right now trying to make cryptsetup work with plymouth, so that my machine will boot cleanly
[23:33] <kirkland> slangasek: okay, no worries
[23:33] <kirkland> slangasek: i think i have it right
[23:55] <dtchen> maxb: Pushed up to revision 36.