[02:37] <dCrim> Hey.
[02:38] <dCrim> Does anyone know why the insight GDB GUI disappeared?
[03:23] <wgrant> I'm confused.
[03:24] <wgrant> I'm sure I've seen two 2700-build Python 2.7 rebuilds use up days of build farm time.
[03:24] <wgrant> But neither PPA exists any more.
[03:31] <Sarvatt> looks like theres a fourth starting up now.. https://edge.launchpad.net/~pythoneers/+archive/py27stack4
[03:31] <soren> You must be kidding.
[03:32] <soren> Dear god, no.
[03:32] <Sarvatt> guess that explains the 3-4 day queues for the past week
[03:33] <soren> I see the PPA, but the build queue hasn't exploded yet.
[03:33] <soren> 1233 jobs is as good as it's been all week.
[03:44] <wgrant> At least we're heading for an empty queue in the next 48 hours.
[03:44] <wgrant> Possibly 24, depending on how things go, but I'm not holding my breath.
[03:45] <wgrant> Although given the recent track record, there will probably be an archive rebuild and three Python rebuilds starting on Monday....
[03:46] <wgrant> And a day into that, 90% of the builders will disappear for 24 hours.
[03:57] <Sarvatt> i'm guessing it's just calmed down because they need to wait for the early deps to build too before they dump the other 1500 packages in the PPA :)
[04:25] <wgrant> Sarvatt: Ah, fair point.
[04:31] <wgrant> I must convince people at some point that we need a better queue discipline.
[05:06] <Sarvatt> cjwatson: how recently did gfxpayload=keep get re-added to grub? I'm noticing widescale bustage on all KMS configurations today without something like vesafb=sucks getting added to make it not load or dropping it
[06:30] <SandGorgon> hey guys.. if new symbols are being included into the Unicode character map - is it possible to update the character map of an install ? or does it come implicitly with a Pango update ?
[07:10] <cjwatson> Sarvatt: I posted to ubuntu-devel about it
[07:10] <cjwatson> Sarvatt: this time, I want to debug these problems rather than just ignoring them
[07:17] <cjwatson> Sarvatt: what kind of problems are we talking about?
[07:26] <achiang> hm.
[07:26] <achiang> GRUB_TIMEOUT=0 ; GRUB_HIDDEN_TIMEOUT=10
[07:27] <achiang> i hit the shift key during boot, and i see GRUB Loading. but no menu
[07:27] <achiang> is that expected behavior?
[07:28] <achiang> cjwatson: ^^
[07:29] <cjwatson> pretty sure you need a positive GRUB_TIMEOUT to see the menu.
[07:30] <achiang> hm
[07:30] <achiang> i really want the menu to be hidden, unless i press a key so i can do some debugging
[07:30] <achiang> maybe that's not possible
[07:30] <cjwatson> GRUB_TIMEOUT=<positive> doesn't unconditionally show the menu
[07:31] <cjwatson> if no key is pressed during the GRUB_HIDDEN_TIMEOUT phase then it won't show
[07:31] <achiang> alright, i'll try that, thanks
[07:31] <Sarvatt> cjohnston: have you not booted twice using KMS since updating it? I've got 6 machines all broken the same way and have been getting a bunch of reports of it in #ubuntu-x. plymouth dies like this - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/606393 and on intel X wont start at all unless you press escape to switch away from the broken splash before it starts, on my nouveau machines its not loading the modules until after X start
[07:31] <Sarvatt> s since there's already another framebuffer device i'm guessing and having the ddx load the module doesn't actually work
[07:31] <Sarvatt> sorry, cjwatson :)
[07:31] <cjwatson> Sarvatt: yes, I have
[07:31] <cjwatson> Sarvatt: works fine on my system
[07:32] <achiang> cjwatson: should i be seeing a blinking cursor when the menu is hidden though?
[07:32] <cjwatson> Sarvatt: there are some kernel bugs which we definitely need to shake out, but if I just leave gfxpayload=text then we'll never get rid of them
[07:32]  * Sarvatt nods
[07:32] <achiang> cjwatson: i also have GRUB_GFXMODE=640x480
[07:32] <cjwatson> achiang: we don't manage to turn it off quite everywhere yet
[07:33] <cjwatson> achiang: so right now, yes, that's expected behaviour
[07:33] <cjwatson> it's not how I ultimately want it to be
[07:33] <achiang> cjwatson: was that possible with grub1?
[07:33] <cjwatson> achiang: I've purged my memories of grub1
[07:33] <achiang> heh.
[07:34] <Sarvatt> the intel ones that dont work are odd
[07:34] <Sarvatt> [    3.075685] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
[07:34] <Sarvatt> [    3.075722] Console: switching to colour dummy device 80x25
[07:34] <Sarvatt> [    3.528337] Console: switching to colour frame buffer device 128x37
[07:34] <cjwatson> achiang: grub2 does try to turn off the cursor - grep for grub_term_setcursor
[07:35] <achiang> cjwatson: thanks
[07:35] <cjwatson> Sarvatt: my working system shows that too
[07:35] <cjwatson> that just means the KMS driver is replacing vesafb
[07:36] <Sarvatt> the screen stays blank after that, and I can't do anything but use sysrq
[07:37] <Sarvatt> well, it goes grub - vesa fb (i see splash here at 640x480) - screen turns off, turns back on with a blank black screen - stuck unless I press escape fast enough before X starts
[07:37] <cjwatson> that means that the KMS driver is failing to go VESA->native.  Matthew Garrett did warn us that it was likely that that would happen in some cases, although said it was still worth us giving it a try
[07:38] <cjwatson> we need to be figuring out how to upstream those bugs effectively
[07:40] <Sarvatt> i think udev might need some fixing to not assume vesafb means the actual graphics device modules were added too, since when it does kind of work (nouveau) it doesn't even try to load nouveau before X starts and the DDX ends up loading it every time here
[07:43] <cjwatson> Sarvatt: no reason for that to be in udev; any such interpretation of udev events belongs in higher layers IMO
[07:44] <cjwatson> Sarvatt: and then, it's necessary to think about how this ties in with splash screen requirements in https://blueprints.launchpad.net/ubuntu/+spec/foundations-m-grub2-boot-framebuffer
[07:48] <Sarvatt> so you want xf86LoadKernelModule() to actually work? if you build all the agp modules into the kernel it *might* but that's still going to be a nightmare of racyness
[07:57] <Sarvatt> outside of intel that always uses intel_agp theres no way to ensure the platform agp driver gets loaded before drm which is required otherwise since drm can't depend on the platform agp modules, there are all kinds of bugs about that one. we're probably the only distro not building those into the kernel now and its expected for them to be unable to be built as modules soon
[07:57] <cjwatson> Sarvatt: I don't understand how you got there from what I said
[07:58] <Sarvatt> letting x load the video modules pretty much guarantees drm won't work the first start after boot
[07:58] <cjwatson> but that wasn't what I said.
[07:58] <tjaalton> Sarvatt: iirc airlied wanted to make the modules mandatory in the kernel
[07:58] <Sarvatt> ah sorry, what do you mean by higher layers then?
[07:58] <cjwatson> upstart
[07:58] <cjwatson> or upstart jobs, more accurately
[07:59] <cjwatson> if you special-case it in udev then you can't deal with machines that only have vesafb
[08:00] <Sarvatt> gotcha, sorry, I thought you meant you wanted X to load them like is happening now
[08:00] <cjwatson> not at all
[08:00] <cjwatson> or rather, I don't have the necessary expertise to offer an opinion either way there
[08:01] <cjwatson> have our kernel team given a reason for building agp modular, or is it something that hasn't come up?
[08:05] <Sarvatt> never gotten an answer outside of not wanting to build things in that could be modular, i've brought it up on the list and in bugs a bunch of times but couldn't make it to UDS to discuss it there
[08:06] <Sarvatt> just curious, what gpu do you have that works?
[08:06] <Sarvatt> it worked with efifb before too unlike all of mine
[08:19] <cjwatson> intel
[08:19] <cjwatson> mjg59 was very clear that we must not use efifb
[08:19] <cjwatson> (on non-EFI systems, anyway)
[08:20] <cjwatson> sorry, specifically a GM965, specifically 8086:2a02 rev 0c
[08:21] <cjwatson> I've only had a relatively small number of regression reports so far; before you, most of them were on Radeon cards
[08:22] <Sarvatt> thanks, was wondering because you didn't have problems last time with the gfxpayload=keep either. i don't have anything with a GMA x3100/GL960 like yours
[08:23] <Sarvatt> the bugs are getting filed against x since it isn't starting up is probably why, I just saw your post and will try to move things over to grub2 as I see them
[08:23] <cjwatson> no!
[08:23] <cjwatson> they're not grub2 bugs.  the kernel needs to fix them, aiui
[08:24] <cjwatson> if you reassign them to grub2 I'll just have to reassign them away again. :)
[08:24] <Sarvatt> alrighty :) well here's one - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/606244
[08:24] <cjwatson> I suggested that people file new bugs on grub2 so that I can look them over, but if they're already filed somewhere appropriate then reassigning them to grub2 is a waste of effort
[08:24] <cjwatson> maybe tag them grub-gfxpayload or something
[08:25] <Sarvatt> will do
[15:41] <rsavoye> slacker_nl: the sources for brasero in bzr don't match the same sources I get with apt-get
[15:41] <rsavoye> oops, slangasek  the sources for brasero in bzr don't match the same sources I get with apt-get
[15:41] <rsavoye> silly tab completion...
[16:03] <rsavoye> slangasek: also the axis2c in bzr appears to also be out of sync with the source tarball
[16:43] <dupondje> anyone noted that grub2 isn't counting down sometimes ?!
[16:45] <SevenMachines> dupondje: i think i get this the next boot after going to recovery mode
[16:46] <SevenMachines> i didnt check, i just thought about it in passing
[16:47] <dupondje> it could be after a unclean shutdown also it seems indeed
[16:48] <SevenMachines> it could have been that, that might of been why i booted into recovery :)
[16:50] <dupondje> lets hope https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606244 is fixed asap :) most crappy bug atm :)
[16:52] <SevenMachines> luckily/sadly, its all quite boring over here. you wouldnt notice it was in development if it wasnt for the host of updates every day
[16:52] <SevenMachines> though i may have just cursed things by saying that out loud :)
[16:53] <dupondje> well its the first real bug I noted since dev of maverick started :)
[16:54] <SevenMachines> X crashes are fun :)
[17:00] <SevenMachines> well, now i've finally found a working sasl plugin for xchat.... i'm off for the weekend!
[19:17] <maxwellian> Can anyone tell me how to add a .desktop file to a package?  The packaging guide tells me where it should end up, but I don't know how to get it there.
[19:18] <maxwellian> Errr, sorry, I think this is the wrong channel.  Going to -motu.
[19:18] <shadeslayer> maxwellian: uh.. make a patch?
[19:18] <maxwellian> Oh, sweet.
[19:18] <shadeslayer> not sure .. but thats i would do
[19:18] <maxwellian> shadeslayer: Well before you make a patch, you change something that patch can report...right? :)
[19:19] <shadeslayer> there might be some debhelper magic that lets you put files in debian/ and then carry ot over
[19:19] <shadeslayer> maxwellian: not necessarily ;)
[19:19] <shadeslayer> oh.. i think
[19:19] <nigelb> maxwellian: you want to know how to create a new .desktop file?
[19:19] <shadeslayer> maxwellian: what can also be done is to make a file in debian/ and then add a cp command to rules
[19:20] <maxwellian> nigelb: Yes.  I have the file, I just want to add it to the package so it gets installed.
[19:20] <maxwellian> shadeslayer: I've seen that done, but the rules file as it stands is very terse.  I'm new to packaging, but most of the stuff seems to be handled automatically CDBS.
[19:21] <nigelb> sheslayer, who just turned evil, guided you right
[19:21] <nigelb> *shadeslayer
[19:21]  * maxwellian trembles
[19:22] <evilshadeslayer> muwhahaha :D
[19:23] <maxwellian> This is the current rules file: http://paste.ubuntu.com/465111/
[19:23] <maxwellian> It doesn't say anything about the install process, just after installing.  I guess the rest is implied somehow.
[19:24] <maxwellian> Ack, sorry, there were a couple of includes at the top as well.
[19:24] <Amaranth> maxwellian: stick a `mkdir -p debian/plt-scheme/usr/share/applications && cp debian/foo.desktop debian/plt-scheme/usr/share/applications` in the binary-post-install/plt-scheme:: section
[19:25] <Amaranth> maxwellian: or a similar binary-post-install section for whatever package needs the .desktop file
[19:25]  * evilshadeslayer was about to say taht
[19:26] <Amaranth> I wonder why they remove the files then remove the directory instead of just doing rm -rf
[19:27] <maxwellian> Wow, a consensus even. :)  Okay, great, thanks.  I'm a noob and it's hard to figure out how to go from the simple examples in the packaging guide to dealing with real packages.
[19:27] <maxwellian> Amaranth: Dunno.  This would be the third time that a .desktop file has been added to this package, so something screwy is going on somewhere. :P
[19:27] <cjwatson> cdbs' greatest weakness is that it's hard to see how to extend it, and the syntax for extensions isn't particularly regular
[19:28] <Amaranth> cjwatson: dh 7 has the same problem
[19:28] <Amaranth> It sure does make things simple when you know how it works though
[19:28] <cjwatson> Amaranth: it does not have the latter problem.  The syntax for extensions is regular
[19:29] <maxwellian> cjwatson: When you say "extensions" you mean something beyond daily use, right?
[19:29] <Amaranth> Oh, right, I meant how to extend it
[19:29] <cjwatson> maxwellian: I mean things like binary-post-install/* rule
[19:29] <cjwatson> s
[19:29] <Amaranth> It's hard to figure out how to go from a one line makefile that does everything to something useful :)
[19:29] <cjwatson> there's some documentation in /usr/share/doc/cdbs/cdbs-doc.html
[19:29] <maxwellian> Amaranth: Exactly!!
[19:30] <maxwellian> cjwatson: Thanks, I will check that out.
[19:30] <maxwellian> cjwatson: So it's not faux pas to do more install stuff in the "post-install" section? :P
[19:30] <cjwatson> cf. http://kitenet.net/~joey/talks/debhelper/debhelper-slides.pdf
[19:31] <cjwatson> maxwellian: why not just put 'debian/foo.desktop usr/share/applications' in debian/foo.install?  that's more idiomatic
[19:32] <maxwellian> cjwatson: Yes, that kind of idiom to add a file is something I've seen, but then there were several other lines that only had one path in them.
[19:32] <maxwellian> cjwatson: Like /usr/bin
[19:32] <cjwatson> man dh_install
[19:32] <cjwatson> for the syntax of that file
[19:32] <cjwatson> similarly man dh_installdirs for the syntax of debian/*.dirs, etc.
[19:33] <cjwatson> 'man debhelper' has an index
[19:33] <cjwatson> Amaranth: (appendix B of that slide deck is what I'm referring to, in particular)
[19:34] <Amaranth> Wow, I forgot all about the .install file trick
[19:34] <maxwellian> cjwatson: Yeah, I've read the man page for dh_install, but it says that each line contains a file or files to install, and where to install them.
[19:34] <Amaranth> Too much magic :)
[19:34] <maxwellian> cjwatson: But then the example simply list destination paths, without specifying what goes there.
[19:34] <cjwatson> maxwellian: read the section under --autodest
[19:35] <Amaranth> maxwellian: If you stick /usr/bin in there it'll include everything the package wants to install to /usr/bin
[19:35] <nigelb> g33
[19:35] <nigelb> grr
[19:35] <cjwatson> (including the last sentence, which applies even if that option isn't given)
[19:37] <maxwellian> Amaranth: Unless I'm reading the page wrong, it's saying that /usr/bin would be the source file, and that it's destination would be automatically determined.
[19:37] <Amaranth> Wow, someone needs to turn that slide deck in to a wiki page for documentation
[19:38] <Amaranth> maxwellian: Eh, I forget, haven't looked in a while
[19:38] <Amaranth> maxwellian: That's probably right
[19:39] <vish> Amaranth: hi, got a min to review an alacarte patch?
[19:40] <maxwellian> Amaranth: Thanks though.  I shouldn't have taken so much time in here, but when so much is done automatically it's hard to figure out where the magic is happening and how to change something. :P
[19:40] <Amaranth> vish: It's not really maintained anymore, I think someone else was taking over on the GNOME side for a while
[19:40] <Amaranth> vish: If you mean to add to the ubuntu package you'll want to talk to the folks on the desktop team
[19:41] <vish> Amaranth: oh , ok..
[19:41] <Amaranth> vish: Although if I was maintaining it and the patch adds UI I'd reject it :)
[19:41] <cjwatson> Amaranth: it's basically all in the man pages
[19:42] <vish> Amaranth: not UI , the drag n drop: https://bugzilla.gnome.org/show_bug.cgi?id=608221
[19:42] <Amaranth> vish: GNOME 3.0 won't include alacarte so it's not really important anyway
[19:43] <vish> Amaranth: hmm , the patch is on LP too.. not sure what to do with it.. Bug #395692 , seb128 is the best person to decide?
[19:43] <Amaranth> vish: yeah, see if seb128 will add it to the ubuntu package
[19:44] <dupondje> cjwatson: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606244 seems like caused by grub2 video mode setting?
[19:44] <vish> Amaranth: could you make a comment about that.. I'll talk to seb128 , else its tough to catch you again ;)
[19:44] <Amaranth> vish: I don't even remember what that code was doing
[19:44] <maxwellian> cjwatson: Is there a way besides building the whole package to test if the .desktop file gets installed properly?  This build on my machine is taking a couple of hours. :\  (I'm just hoping against hope there's a better way.)
[19:45] <cjwatson> maxwellian: if you've already got to the end of the build, you can rerun individual debhelper commands with DH_VERBOSE=1
[19:45] <cjwatson> so DH_VERBOSE=1 dh_install # or whatever
[19:45] <maxwellian> cjwatson: So that would just try the install part, and I could see if the file ended up where it should?
[19:46] <cjwatson> dupondje: already had a discussion with Sarvatt about that earlier today - grub2 video mode setting is the proximate cause, yes, although it's still a kernel bug
[19:46] <cjwatson> maxwellian: right
[19:46] <maxwellian> cjwatson: Awesome, thanks for your time.
[19:46] <cjwatson> with DH_VERBOSE=1 it'll echo the commands it runs
[19:46] <maxwellian> cjwatson: Right, good for debugging.
[19:46] <vish> Amaranth: cool , alteast a comment that it aint maintained upstream would do.. :)
[19:46] <cjwatson> in fact, when you're working on this kind of thing, it's often useful to just do a full build under DH_VERBOSE=1, and then you can retroactively inspect the whole log
[19:46] <dupondje> cjwatson: héhé ok :) thx for the info
[19:46] <cjwatson> if you're making several changes
[19:47] <maxwellian> cjwatson: Yes, that would have been a good idea.  Help me to get a sense of all the magic being done for me automatically!
[19:47] <cjwatson> I used that when converting grub2 from CDBS to dh recently
[19:47] <cjwatson> that was quite a difficult conversion job
[19:48] <maxwellian> cjwatson: I don't doubt it.  It seems to me that CDBS is using debhelper in this case, but I don't know.
[19:48] <cjwatson> yes
[19:48] <cjwatson> CDBS is a system of Makefile fragments wrapping debhelper
[19:49] <maxwellian> cjwatson: So the conversion to debhelper means...unwrapping it?
[19:49] <cjwatson> what I'm loosely referring to as "dh" is a system with similar expressive power to CDBS built into newer versions of debhelper
[19:49] <cjwatson> man dh
[19:50] <cjwatson> essentially trying to replicate the good bits of CDBS while avoiding at least some of its design flaws
[19:50] <maxwellian> cjwatson: Oh, sorry...I thought that was just an abbreviation for all of the dh_* commands.
[19:50] <cjwatson> anyway, this isn't terribly relevant to you if you're just extending an existing CDBS package
[19:50] <hyperair> cjwatson: i think dh7 is the more commonly used term, to avoid confusion.
[19:51] <maxwellian> cjwatson: It's very relevant to me, since I would like to be competent at working with packages in general at some point.  Again, thanks a lot for your time, it saves me a lot of head scratching.
[19:54] <cjwatson> hyperair: also confusable with debhelper 7 in general, unfortunately
[19:54] <cjwatson> I guess dh(1) is unambiguous
[19:55] <hyperair> maxwellian: most (including me) would recommend using dh7 over cdbs, considering how poor cdbs documentation is that you'll need a high level of make-fu and the ability to read CDBS's makefile fragments while maintaining sanity.
[19:56] <cjwatson> also dh(1) use is growing more or less linearly right now while cdbs use is stagnant
[19:56] <hyperair> cjwatson: but dh(1) is the single most prominent feature of debhelper 7, so it's almost certain that you're referring to that feature when you say dh7. =p
[19:56] <cjwatson> mm
[20:02] <slangasek> rsavoye: neither axis2c nor brasero are in the import failure list; which bzr branch are you grabbing, and which release are you downloading from with apt-get source?