[00:02] <mdz> persia, I read the transcript of your Open Week talk on stack traces; interesting topic
[00:03] <mdz> persia, I find it more convenient to browse the source from within gdb rather than opening up a separate editor, when walking through the stack frames
[00:03] <mdz> cjwatson, I enjoyed your merging session as well
[00:03] <mdz> dholbach, developer week seems to have gone very well, nicely done
[00:07] <dholbach> thanks mdz
[00:14] <seb128> directhex, they are published now btw
[00:14] <directhex> oh, neato
[00:15] <directhex> i'll look tomorrow after it hits my mirror
[00:20] <cjwatson> mdz: oh good
[00:30] <persia> mdz: When one runs gdb directly, I'd agree it's more convenient.  That said, I often find that using the apport stacktraces with the source is good enough, without needing to fully replicate.
[00:31] <persia> Is there a good way to use the info the retracer leaves in a bug (after the coredump is stripped) to initialise gdb?
[00:32] <persia> In many cases, I find the crashes are data- or environment-dependent, and replication can be tricky.
[00:38] <cjwatson> persia: as it turned out it wasn't directly germane to your talk since one can't use it with apport stacktraces, but do you know about gdb 7's record-and-replay support?
[00:39] <persia> cjwatson: I don't.
[00:41] <cjwatson> persia: it rocks.
[00:42]  * persia reads http://sourceware.org/gdb/current/onlinedocs/gdb/Process-Record-and-Replay.html#Process-Record-and-Replay
[00:43]  * cjwatson does an entire test install to test installing GRUB's boot sector + core image to an LVM, only to realise that this makes no sense
[00:44] <cjwatson> persia: reverse execution is the sexy bit, of course
[00:45] <persia> Indeed.  I didn't get any farther than that on the page before redirecting to chapter 6 :)
[01:02] <ogra> Keybuk, http://people.canonical.com/~ogra/osiris-lucid-20100202-2.png :)
[01:02] <ogra> (with FRAMEBUFFER=y btw
[01:02] <ogra> )
[01:02]  * StevenK through and NBSes 3 kernels with happy abandon
[01:03] <Keybuk> what did you change?
[01:03] <StevenK> Sigh. Missing word fail
[01:03] <Keybuk> ogra: I want to see that without ubuntuone-syncd ;)
[01:03] <ogra> Keybuk, nothing ... i switched FARMEBUFFER to n and then back to y, regenerated the initrd both times
[01:04] <ogra> i guess if you move on like that we need some new solution for bootchart to keep the charts readable :)
[01:05] <Keybuk> move on?
[01:05] <ogra> well, to 2sec boots or so :)
[01:05] <ogra> ok, ubuntuone removed ...
[01:05] <Keybuk> we'd have to use perf or something
[01:06]  * ogra reboots 
[01:06] <ogra> :)
[01:12] <ogra> Keybuk, hmm, so the modprobe of death comes back randomly it seems
[01:12] <ogra> Keybuk, but if its not there i get something like http://people.canonical.com/~ogra/osiris-lucid-20100202-6.png :D
[01:13] <ogra> i guess thats something to show off with :)
[01:14] <Keybuk> niiiiice
[01:24] <pitti> 8s? sweeeet
[01:29] <ogra> pitti, without ubuntuone and without plymouth though
[01:30] <LaserJock> does anybody know if there's a good overview of what's happening for UNR/UNE for Lucid?
[01:32] <persia> LaserJock: bzr log of the seeds probably says the most up to now.  Can't give you a pointer for the future.
[01:35] <LaserJock> is it continuing to be actively developed or is it sort of in maintanence mode?
[01:36] <LaserJock> my only machine is now a netbook and so I've noticed a few things that could maybe be improved
[01:36] <LaserJock> but it didn't seem like much was going on with core code (netbook-launcher, etc.)
[01:37] <persia> Have you checked upstream activity?  I haven't followed in a bit, but I remember hearing a bit of talk at UDS.
[01:38] <LaserJock> well, that's sort of what I'm trying to find
[01:38] <LaserJock> I don't know where upstream is
[01:38] <StevenK> In Launchpad
[01:39] <LaserJock> the last commit to netbook-launcher was 14 weeks ago
[01:40] <LaserJock> I'm wondering what that means, "we think we're at a stable point" or "we're not really interested and are moving on"
[01:40] <persia> Is there nifty bits that are not yet released upstream that we'd want?
[01:40] <persia> s/Is/Are/?
[01:41] <LaserJock> honestly I don't know what's upstream and what's not
[01:42] <persia> Well, it's like anything else :)  But if you're looking at the specific packages, that's probably an upstream thing.  If it's not, then it's probably seeds or other random bits :)
[01:43] <LaserJock> well, I'm wondering about code, not seeds
[01:43] <persia> That's probably upstream then.
[01:43] <LaserJock> so upstream I guess, which is sort of the same as downstream, but yeah
[01:43] <persia> How is it the same?  We're downstream.
[01:45] <LaserJock> well, netbook-launcher is done by UNR and UNR is part of Ubuntu
[01:45] <LaserJock> hence, kinda the same
[01:46] <persia> Yeah.  The names are annoying.  I was involved in a discussion about nomenclature back in the very beginning of karmic, with the following conclusions:
[01:46] <persia> 1) There exists some set of code (the core applications) that is a separate project, which is on LP.
[01:46] <persia> 2) There exists an implementation that has been adopted by Ubuntu, which was UNR, and is now becoming UNE.
[01:47] <persia> 3) There exist some other implementations further downstream which are UNR.
[01:47] <persia> Dunno how much that's still true, but theoretically there's supposed to be distinction.
[01:47] <LaserJock> geeze, that's kinda confusing
[01:48] <LaserJock> but the "separate project" is run by "UNR Developers" which makes it sound not-so-separate
[01:48] <persia> Yeah well :)  There was a session on naming at UDS Jaunty, but that was the conclusion :)
[01:48] <persia> I know, but "UNR Developers" != Ubuntu Developers.
[01:48] <LaserJock> I'm seeing that
[01:48] <ajmitch> so much confusion there
[01:49] <LaserJock> it's mostly DX and OEM Solutions
[01:49] <LaserJock> so a bit more like CNR
[01:50] <LaserJock> in fact every single member of "UNR Developers" is Canonical
[01:50] <LaserJock> hmm, weird
[01:52] <persia> Well, still, contacting upstream is the best way to get guidance :)
[01:52] <persia> Otherwise it's just the stuff in the specs.
[01:54] <LaserJock> persia: right, I guess I can file a bug, I just hate doing that if it's likely to come of nothing
[01:56] <persia> LaserJock: I guess.  My point is mostly that I'm not convinced that this channel is the best place to answer that question.  I don't happen to know the best way to contact upstream, but I do expect they're in a better position to answer questions of general direction.
[01:57] <LaserJock> persia: right, I just didn't really know where
[01:57] <LaserJock> probably a bug will get to the right people though if Canonical's still running it
[01:57] <persia> Probably, if it's against the right project :)
[01:58] <LaserJock> heh
[02:15] <fullTummy> ubuntu is good
[02:15] <fullTummy> for testing formatting
[02:20] <fullTummy> kapetan sam od careva grada,
[02:20] <fullTummy> u njem vladam od trista godinah;
[02:20] <fullTummy> đed mi ga je na sablju dobio
[02:20] <fullTummy> đe su carstvo sablje dijelile,
[02:20] <fullTummy> te mu tragu osta za gospodstvo."
[02:20] <fullTummy> Raspali se Mićunović Vuče,
[02:20] <fullTummy> pa se Hamzi poprimače blizu:
[02:20] <fullTummy> "Kakvo Vlaše, krmska poturice!
[02:20] <fullTummy> Đe izdajnik bolji od viteza?
[02:20] <fullTummy> Kakvu sablju kažeš i Kosovo?
[02:20] <fullTummy> Da l' na njemu zajedno ne bjesmo,
[02:20] <fullTummy> pa ja rva i tada i sada?
[02:20] <fullTummy> Ti izdao prijed i poslijed,
[02:20] <fullTummy> obrljao obraz pred svijetom,
[02:20] <fullTummy> pohulio vjeru prađedovsku,
[02:20] <fullTummy> zarobio sebe u tuđina!
[02:20] <fullTummy> Što se hvališ gradom i gospodstvom -
[02:20] <fullTummy> svi gradovi što su do nas turski,
[02:20] <fullTummy> jesam li ih opsuo mramorjem,
[02:20] <fullTummy> te nijesu za ljude gradovi
[02:20] <fullTummy> no tavnice za nevoljne sužnje?
[02:20] <fullTummy> Bič sam božji ja spleten za tebe,
[02:20] <fullTummy> da se stavljaš što si uradio!"
[02:21] <ogra> !ops
[02:56] <David-T> no floodbot here?
[05:23] <breinera> on what channel should I ask about packaging a personal project
[05:30] <ScottK> If you plan to try to get it into Ubuntu, #ubuntu-motu.  If you're going to put it in a PPA, #launchpad.
[05:41] <ccheney> hmm an upload i did today shows binaries still not published
[05:41] <ccheney> is there some kind of block on OOo, or myself? ;-)
[05:42] <ccheney> ah nm it apparently is new for some reason
[05:42] <ccheney> didn't mention that until i clicked through to the actual build
[06:21] <Damascene> Hello, http://www.ubuntu.com/testing/lucid/alpha2 says that UNR is KDE base now. is that right?
[06:23] <Riddell> Damascene: no it doesn't
[06:24] <Damascene> why it is on kubuntu page?
[06:24] <Riddell> why is what?
[06:24] <Damascene> http://cdimage.ubuntu.com/kubuntu/releases/lucid/alpha-2/ (Kubuntu Desktop and Netbook Remix)
[06:25] <Damascene> that is what the page says
[06:25] <Riddell> "Kubuntu Desktop and Netbook Remix" means Kubuntu Desktop images and Kubuntu Netbook Remix images
[06:25] <Riddell> Ubuntu Netbook is not the same as Kubuntu Netbook.  UNE is hidden at the bottom of http://cdimage.ubuntu.com/releases/lucid/alpha-2/
[06:26] <StevenK> And UNE is the new name for UNR
[06:28] <Damascene> Ok :) , I understand now. the site should be clearer
[06:28] <Damascene> thank you
[10:33] <mdz> persia: ah, of course, you were talking about analyzing stack traces in bugs. it would be way cool if Launchpad would cross-reference to the source package branches so you could just click through to the source
[11:25] <nigel_nb> Hobbsee, I now have the source from packages.ubuntu.com and I'm wondering what to do next
[11:26] <nigel_nb> (I should do this more often :( )
[11:30] <Hobbsee> nigel_nb: you're looking for the ubuntu packaging guides and similar, i presume
[11:30] <nigel_nb> Hobbsee, yep... i have the one from motu... works?
[11:30] <Hobbsee> nigel_nb: yep.  What you want should be listed in some section of https://wiki.ubuntu.com/MOTU/Contributing
[11:31] <nigel_nb> Hobbsee, reading through :)
[11:38] <nigel_nb> Hobbsee, what is the patch system in gnome? git?
[11:39] <Hobbsee> nigel_nb: i don't actually know, tbh.  i'm going to tentatively guess dpatch - is there a 00list in debian/patches?
[11:39] <Hobbsee> you can always try building the package / looking at the build depends to see, though
[11:39] <nigel_nb> oh yes
[11:40] <nigel_nb> so its dpatch
[11:43] <nigel_nb> Hobbsee, uh, wait.. cdbs is listed as build depends
[11:43] <Hobbsee> nigel_nb: then that's what it'll be.
[11:43] <nigel_nb> Hobbsee, ah
[11:44] <Hobbsee> 00list is used in multiple patch systems, but does help in tracking it down
[11:44] <nigel_nb> okay.. so I have to add another number to the 00 list?
[11:45] <Hobbsee> https://wiki.ubuntu.com/PackagingGuide/PatchSystems#CDBS with Simple Patchsys
[11:45] <Hobbsee> nigel_nb: gives a fairly good overview of how to use it
[11:46] <nigel_nb> Hobbsee, hehe, I'm already there
[11:46] <Hobbsee> cdbs-edit-patch will automatically add it for you
[11:48] <geser> what-patch (from ubuntu-dev-tools) can also give a hint what patch system is used
[11:48] <nigel_nb> yep, just installed what-patch now
[11:48] <nigel_nb> I'll explain where I'm lost
[11:49] <nigel_nb> I have this diff from upstream (the actual patch).  Am I supposed to do a cdbs-edit-patch and run that patch?
[11:49] <nigel_nb> or pass that patch in to edbs-edit-patch
[11:53] <geser> what patch system is exactly used? what does "what-patch" tell?
[11:55] <nigel_nb> geser, cdbs
[11:58] <geser> then create with "cdbs-edit-patch my_new_patch" a new patch and apply the upstream patch inside the working copy, when you are done all your changes are get saved in my_new_patch
[11:59] <geser> check the new patch name wisely as the patches are applied in lexicographic order
[11:59] <nigel_nb> geser, so I'm supposed to simply create a blank file called my_new_patch?
[12:00] <geser> cdbs-edit-patch will do it for you (and my_new_patch is a placeholder for a better name)
[12:01] <geser> a good name should describe what the patch solves without needing to look inside
[12:01] <nigel_nb> something like "cdbs-edit-patch 07_fix_GvcChannelMap_leak" ?
[12:02] <geser> yes
[12:02] <nigel_nb> I get an error like "dh_testdir: cannot read debian/control: No such file or directory"
[12:02] <nigel_nb> what am I missing?
[12:03] <geser> are you inside the (unpacked) package directory?
[12:03] <Hobbsee> you need to do it in the source package root
[12:03] <Hobbsee> ie, the one that has a debian folder
[12:03] <nigel_nb> I was inside the patches directory.. ah
[12:05] <nigel_nb> oh, I have to satisfy all depends when working on a package?
[12:07] <geser> not necessarily, just the ones needed to run the "clean" target
[12:07] <geser> in this case probably "cdbs" and some other packages
[12:08] <nigel_nb> I'm not running gnome.. which means ......lots of them
[12:08] <nigel_nb> now its a good idea to switch back
[12:17] <nigel_nb> okay, now I'm in the subshell of cdbs-edit patch :)
[12:19] <nigel_nb> geser, so I just paste the diff inside the subshell?
[12:20] <geser> yes, apply it with patch
[12:21] <nigel_nb> um, with patch?
[12:21] <geser> every change you do inside this subshell will be put into the patch later
[12:22] <nigel_nb> so inside the subshell, I'm supposed to go to the particular file and make the modification?
[12:22] <geser> yes, apply the changes you need, e.g. by editing a file with an editor or applying a ready patch
[12:22] <geser> yes
[12:22] <nigel_nb> I have this file withe me http://bugzilla-attachments.gnome.org/attachment.cgi?id=152824
[12:24] <geser> save it somewhere (e.g. /tmp) and then "patch -p2 --dry-run < /tmp/the_saved_patch". if this works without an error, remove the "--dry-run"
[12:26] <geser> (alternatively you could also open that file (src/gvc-mixer-stream.c) in an editor and do the changes there, but that's only feasible for small patches)
[12:30] <nigel_nb> since its a very small patch I opened the file and did it :)
[12:31] <nigel_nb> and the patch command gave me an error and I didn't have enough patching $foo to fix that one
[12:32] <nigel_nb> now the patch is in the folder but its not applied
[12:38] <nigel_nb> shouldn't the patch be applied and not just listed there?
[12:43] <geser> patches are applied before building and un-applied during clean
[12:44] <nigel_nb> ah, so I can just go on to building this now?
[12:44] <geser> when you build the binary package you can check the build output to see if your patch got applied or not
[12:44] <geser> yes
[12:56] <nigel_nb> geser, the patch needs to be tagged rite?
[13:05] <geser> I don't know the current policy but it's a good idea to do it
[13:09] <nigel_nb> I've used this http://dep.debian.net/deps/dep3/
[13:10] <nigel_nb> to the extend that I know how its done
[14:06] <juliank> Shouldn't libslab be included in main and gnome-control-center build-depend on it, like it is done in Debian?
[14:06] <juliank> libslab is currently in universe.
[14:08] <ScottK> Since most/all of the Canonical developers are at a sprint this week, the odds of an authoritative answer via IRC are particularly low at the moment.
[14:10] <dupondje> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 => somebody has time to check this patch ? :) didn't make it in Karmic, would be nice to have it into Lucid :)
[14:13] <juliank> ScottK: I will then report a bug against control-center, once triaged =>MIR for libslab => Change gnome-control-center => Fix released. Should be a good way to do this.
[14:14] <ScottK> juliank: I don't have an opinion on the best way to proceed.  I don't even use Gnome.  I was just suggesting IRC isn't it.
[14:29] <dupondje> nobody to review my patch :) its in sponsor queue for some time now
[14:35] <Ng> I guess whoever would process NEW packages this week is in Portland doing far more interesting things :)
[14:37] <dupondje> Alot of packages in the queue it seems :)
[14:56] <bigon> could someone have a look at my merge request plz https://bugs.edge.launchpad.net/ubuntu/+source/virtinst/+bug/509800 ?
[15:09] <LucidFox> "Lucid changes to Firefox default provider"
[15:10] <LucidFox> I saw Lucid and Firefox in one sentence and did a double take.
[15:10] <Ng> LucidFox: we're sending all search requests to you. I hope you've got plenty of coffee
[15:10] <LucidFox> Er, I don't drink coffee.
[15:12] <ScottK> You will
[15:12] <LucidFox> Eek
[15:38] <Laibsch> ArneGoetje: I have a question if I may.  It seems to me that among scim and now ibus, uim was never seriously considered.  Can you briefly explain the reason?
[15:42] <persia> Laibsch: We used uim back in Breezy, and switched to scim.  I'm not sure switching back was ever considered, but uim was once the preferred choice :)
[15:43] <Laibsch> I see
[15:43] <Laibsch> I'm not very familiar with the options, really
[15:44] <Laibsch> But I learned today that at least in Japan uim is the default
[15:44] <Laibsch> and the numbers in popcon support that
[15:47] <Laibsch> actually, maybe not
[15:47] <Laibsch> I was looking at the wrong package
[15:47] <Laibsch> scim-anthy and uim-anthy seem to be equal at around 1.500 installations
[15:48] <Laibsch> ibus-anthy is still way behind at only ~30 (one of which is mine ;-))
[15:51] <persia> anthy is preferred.  How we get to anthy is less important :)
[15:51] <tkamppeter> pitti, hi
[15:51] <pitti> tkamppeter: hello
[15:52] <persia> The old docs all referenced uim, but scim has started to work well enough that it's the default in the Japanese Remixes.
[15:52] <tkamppeter> I have prepared an SRU for foomatic-filters, bug 463059
[15:52] <sebner> pitti: ~o~, everything fine in Portland? :)
[15:52] <pitti> sebner: yes, it is; had Karaoke last night :)
[15:53] <pitti> tkamppeter: I saw your mail, will followup later on
[15:53] <tkamppeter> pitti, can you accept the foomatioc-filter to get into -proposed, so that the reporter can start testing and does not need to wait for the Sprint to finish?
[15:53] <tkamppeter> Sprint is in Portland?
[15:53] <sebner> pitti: hahaha! I hope you won! you have to defend the german honor :P
[15:54] <pitti> sebner: it wasn't actually a competition :)
[15:54] <pitti> tkamppeter: I'll do it later today, don't worry :)
[15:54] <tkamppeter> OK, it is early in the morning for you, I was used to Sprints being in Europe.
[15:54] <sebner> pitti: then your are doing something wrong, Who is the most funniest, the most drunk, the most embaressing one ... all essential questions :P
[15:55] <pitti> sebner: slangasek wanted to hear 99 Luftballons, but they only had the English version :/
[15:55] <pitti> (which I refused to sing..)
[15:55] <sebner> hahaha
[15:55] <pitti> tkamppeter: right, I just got up early for the DMB meeting
[16:07] <lamont> asac: mono given back
[16:21] <tkamppeter> pitti, thanks for passing through the SRU, it perhaps fixes also bug 513690 and bug 422949.
[16:31] <sbalneav> I'm having trouble trying to get something working for evolution for teachers as part of #edubuntu.  I'm trying to get the evoldap backend working for gconf, and it works for setting mail accounts, but I can't seem to set addressbook and calendar defaults.  Anyone know off the top of their head where evolution picks up it's defaults for addressbook and cal?  It sure seems to find the ubuntuOne stuff.
[16:53] <ArneGoetje> Laibsch: ever tried to install and configure uim? Ever compared the user interface between uim and scim/ibus? IMHO scim/ibus are more advanced and user friendly than uim.
[16:54] <Laibsch> OK
[16:54] <Laibsch> Just curious
[16:54] <asac> lamont: rock
[17:05] <slangasek> ion: fyi, I've uploaded the plymouth upstart job changes now following discussion with Keybuk; he helped identify one reason that would account for the splash screen starting so late, but we haven't pinned your race condition yet - the upstart jobs themselves seem to be exactly what he was expecting, and we probably have to debug the race condition as a plymouth bug
[17:05] <ion> slangasek: Alright
[17:07] <slangasek> ion: you were running on intel, right? you mentioned kms
[17:19] <ion> slangasek: Radeon
[17:25] <slangasek> ion: ok; will try to sniff out some radeon hardware here at the company sprint to reproduce the problem :)
[17:35] <Jumanji> What is the cause of this ? -> WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported!  This is an application bug!
[17:36] <Jumanji> Thats compiz
[17:42] <Jumanji> X.Org X Server 1.7.4.901 (1.7.5 RC 1)
[17:42] <Jumanji> Release Date: 2010-01-23
[17:42] <Jumanji> X Protocol Version 11, Revision 0
[17:42] <Jumanji> Build Operating System: Linux 2.6.32.3 i686
[17:43] <Jumanji> xf86-video-intel-2.10.0
[17:43] <Jumanji> (nice driver btw)
[17:49] <sheldon> hi, i'm trying to upload a source package on my ppa but i recevie this error pkg-kde-tools_0.6.0~ppa1.dsc: format '3.0 (native)' is not permitted in karmic. How can i solve?
[17:57] <Riddell> sheldon: convert it to format 1.0 by removing debian/source/ directory
[17:57] <sheldon> thanks Riddell
[19:21] <ccheney> slangasek: ping
[19:24] <sbalneav> seb128: Got a half a sec?
[19:26] <seb128> sbalneav, yes
[19:27] <sbalneav> As part of Edubuntu, I'm trying to get the gconf backend evoldap going.  Evolution picks up the account settingdgs from ldap, but seems to be ignoring the addressbook and calendar settings...
[19:28] <sbalneav> do you know off the top of your head where evolution's grabbing the default gconf keys for /apps/evolution/calendar/sources and .../addrssbook/sources?
[19:28] <sbalneav> it seems to be ignoring the ones evoldap gives it.
[19:28] <seb128> no I don't
[19:29] <sbalneav> ok, fair enough.  I'll keep digging.
[19:29] <pitti> Keybuk, sabdfl: FYI: http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100202-1-nobg.png  and http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100202-1-tiledbg.png
[19:29] <pitti> Keybuk, sabdfl: in short, tiled bg is cheap
[19:30] <Keybuk> oh, cool
[19:30]  * Keybuk was wrong
[19:32] <micahg> anyone know the debian policy for reopening won't fix bugs if time passes and there's new info?
[19:32] <highvoltage> the universe has a strange sense of humour. just a few weeks ago I laughed at a Windows 7 bug that caused login to take 30s longer if you don't have a wallpaper and just a plain background
[19:32] <seb128> micahg, don't?
[19:32] <highvoltage> and now this :)
[19:32] <micahg> seb128: does that mean file a new bug?
[19:32] <pitti> Keybuk: it does use some CPU, but much less apparently than all the huge .jpg decoding and scaling
[19:32] <seb128> micahg, no that mean if the maintainer says the change will not be made it will probably not
[19:33] <pitti> Keybuk: (it's jpg these days, it just pretends to be a .png for backwards compat issues)
[19:33] <pitti> Keybuk: doing a chart now with new plymouth
[19:33] <micahg> seb128: k, thanks
[19:33] <seb128> micahg, you can argue on the bug but don't play close, reopen game, it will just annoy the maintainer and not lead anywhere usually
[19:34] <micahg> seb128: ok, so it's ok to comment on a won't fix then if there's new information??
[19:34] <seb128> yes
[19:34] <seb128> but those bugs usually don't wait on new comments
[19:34] <micahg> seb128: thanks
[19:34] <seb128> bugs which lack informations are incomplete
[19:34] <seb128> or invalid
[19:34]  * micahg has to actually see if there's an update on the issue
[19:35] <micahg> but wanted to know general policy
[19:36] <ccheney> doko: OOo failed on arm due to what appears to be broken krb5
[19:36] <pitti> right, that caused FTBFSes all over the place (not just on arm)
[19:36] <StevenK> pitti: Which are now fixed?
[19:37] <pitti> I dunno
[19:37] <doko> ccheney, pitti: fixed and requeued
[19:37] <pitti> sweet, thanks
[19:38] <ccheney> doko: thanks
[19:43] <pitti> slangasek, Keybuk: did old vs. new plymouth, nice job!
[19:43] <pitti> http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100202-1.png
[19:43] <pitti> http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100202-2.png
[19:44] <pitti> (it works around the usb_id bug again by parallelization, and is also quite fast)
[19:45] <Keybuk> cool
[19:46] <Keybuk> looking in good shape there
[19:46] <Keybuk> I suspect the usb_id thing is actually holding stuff up still
[19:48] <ion> keybuk: The ureadahead-with-HDD → udev → framebuffer → plymouth sequence causes quite a long period of confusing-black-screen-for-user here. I wonder if there’s a compromise that can be done so that plymouth doesn’t need to wait for the entire readahead thing?
[19:49] <Keybuk> ion: possibly
[19:49] <ogra> pitti, woah, slooow boot there
[19:49] <ogra> :P
[19:49] <pitti> ogra: sheeeesh
[19:49] <pitti> ogra: well, it's an Abacus^WAtom
[19:49] <ogra> heh
[19:51] <TheMuso> lol
[19:52] <Keybuk> ion: got any ideas?
[19:56] <ion> keybuk: Perhaps using similar IO priority queueing as mountall’s doing with fscks and launching ureadahead and udev in parallel with ureadahead having the priority. Then making ureadahead read the files needed for framebuffer first and the rest later. But then, udev probably blocks on IO unrelated to framebuffer, which causes this entire hack to fail.
[19:57] <Keybuk> ion: exactly
[19:57] <Keybuk> and if you do multiple readahead passes, you fail
[19:57] <Keybuk> (on HDD more than SSD)
[19:57] <ion> Yeah
[19:57] <sabdfl> pitti: that latter one is very nicely compacted
[19:58] <pitti> sabdfl: indeed; it'll look even better with the kernel bug fixed
[19:59] <ion> keybuk: Would building the framebuffer stuff into the kernel work? Perhaps make plymouth not wait for a udev event if it can just show the splash?
[20:00] <Keybuk> ion: can't do that
[20:00] <Keybuk> would mean we couldn't update graphics drivers through backports
[20:00] <ion> Right
[20:06] <slangasek> ccheney: pong
[20:09] <ccheney> slangasek: nm i found out it was riddell's day to process new :)
[20:09] <slangasek> ccheney: ah :)  sorry for not getting to it right away, the server team AET MAI BRAIN
[20:10] <ion> keybuk: When udev finds a framebuffer, log the corresponding kernel module and on the next startup try modprobing that stuff and starting plymouth in parallel with ureadahead? If the hardware has changed and the modprobe fails, udev will bring up the correct framebuffer later in the startup and log the new framebuffer module for the next boots. One would need to measure whether those things happening in parallel with ureadahead have too great an impact on HDDs.
[20:10] <ccheney> slangasek: heh ok :)
[20:10] <ion> keybuk: Perhaps do the modprobe attempt just before ureadahead if the framebuffer module has been logged previously.
[20:10] <Keybuk> ion: no.
[20:20] <ion> keybuk: Hack udev to queue all non-whitelisted kernel events for later and only act on framebuffer-related events? Process the entire queue and continue as normal as soon as a signal is received. Start udev early along with ureadahead and signal udev when ureadahead is ready.
[20:21] <Keybuk> ion: again, brittle
[20:21] <Keybuk> udev can't start before mountall
[20:21] <Keybuk> because udev needs /proc, /sys, etc.
[20:21] <Keybuk> but ureadahead has to start before mountall
[20:21] <Keybuk> this is pretty much the fundamental issue
[20:54] <mpt> tremolux, I've added some specifics of how software items without a source should be presented. https://wiki.ubuntu.com/SoftwareCenter?action=diff&rev2=316&rev1=314
[20:56] <tremolux> mpt: ah great, thanks!
[20:58] <mpt> tremolux, actually, I made a confusing mistake there. Fixed in https://wiki.ubuntu.com/SoftwareCenter?action=diff&rev2=317&rev1=314
[20:59] <tremolux> mpt: ok, thx
[21:15] <directhex> seb128, can you sync gtk-sharp2 from sid? 2.12.9-4 is needed to fix the tasque compile error
[21:15] <seb128> directhex, ok
[21:15] <directhex> thanks
[21:26] <pitti> seb128, slangasek, Riddell, james_w, jdstrand: oops, I wanted to sync a package, which started to sync the entire load of packages currently being in syncs/; I ^Ced it
[21:27] <kklimonda> are we going to upload django 1.2 to lucid? it's supposed to be released at 9th march
[21:35] <sebner> pitti: why don't let it run through? =)
[21:54] <Riddell> pitti: hmm, those syncs aren't from me
[21:54] <Riddell> someone is doing my archive day for me!
[21:58] <slangasek> sebner: the sync will run with the wrong options in that case
[21:59] <sebner> slangasek: ah, I wasn't aware of that
[21:59] <slangasek> sebner: we pass a flag when doing mass syncs to tell it not to spam $dist-changes
[22:00] <sebner> slangasek: and I suppose he forgot this special flag?
[22:00] <slangasek> I would expect so :)
[22:01] <ccheney> how often does the conference mirror get the new crack?
[22:03] <pitti> yes, this caused -changes spam, sorry
[22:03] <TheMuso> ccheney: Once a day afaik.
[22:05] <slangasek> ccheney: quadridiurnally
[22:10] <slangasek> oops, no, my bad
[22:10] <slangasek> ccheney: octodiurnally
[22:15] <ccheney> slangasek: 8 times a day or is that every 8 hours?
[22:15] <sebner> pitti: I think you have to pay a round of beer at the next karaoke party :P
[22:15] <slangasek> ccheney: 8 times a day
[22:15] <ccheney> slangasek: ok
[22:23] <pitti> slangasek: ok, we identified why the full OO.o gets pulled in; the oo.o-hyphenation-en-us package gets built by the hyphen source now (instead of oo.o-dictionaries), and thus is missing the | l-support-en dep
[22:23] <pitti> slangasek: ccheney is on it
[22:23] <slangasek> okie
[22:41] <bdrung_> james_w: look at bug #514491
[22:42] <james_w> I'll do it in a moment
[22:48] <bdrung_> something weird is going on. audacity 1.3.11-1 was now synced three times (first time it works; the last two time failed, because the version is already in the archive)
[22:49] <james_w> yep, we had a bit of a collision, as long as it was accepted once we're ok now
[22:49] <james_w> sorry about the noise
[22:51] <bdrung_> james_w: no problem. i just wanted to make sure, that you are aware of it and that a script do not run amok.
[22:53] <ccheney> pitti, slangasek: fixed
[22:54] <pitti> ccheney: sweet, thanks
[23:00] <Lex79> james_w: about kernel-package sync, the sources.changes is rejected
[23:00] <Lex79> Rejected:None: unable to parse .changes file: ",
[23:02] <james_w> Lex79: paste the mail in the bug please
[23:02] <Lex79> ok
[23:04] <Lex79> james_w: bug 512000
[23:05] <directhex> hm
[23:06] <directhex> fta, is there no xulrunner 1.9.2 package?
[23:06] <fta> didrocks, yes there is one. just not in the archive yet
[23:06] <james_w> Lex79: please file a bug on soyuz
[23:06] <Lex79> ok
[23:06] <fta> oops, directhex ^^
[23:07] <directhex> fta, will it be parallel-installable with 1.9.1?
[23:07] <fta> directhex, if it stays like it is today, yes
[23:08] <fta> directhex, but you should ask asac. even if i packaged it and maintained it myself, i kind of dropped the ball
[23:10] <geser> james_w, Lex79: interesting bug, it breaks because of an embedded ^M in the changelog
[23:11] <james_w> it breaks because it's munging the encoding as far as I can see
[23:12] <micahg> directhex: I hope to finish the package tonight
[23:12] <geser> I've opened the .orig.tar.gz and look inside the changelog: „Bug fix: "make-kpkg should use update-initramfs when
[23:12] <geser> ", thanks to“
[23:12] <micahg> directhex: we'll be porting everything to 1.9,2
[23:12] <geser> argh, there is a ^M before the closing "
[23:13] <directhex> micahg, 1.9.1 will be removed from the archive?
[23:13] <micahg> directhex: yes, (hopefully)
[23:13] <directhex> i see
[23:14] <micahg> directhex: and xulrunner is dropping to universe
[23:14] <directhex> micahg, what should i build-depend on for a plugin?
[23:15] <micahg> directhex: xulrunner-dev should be fine
[23:16] <micahg> I"ll be adding that to xulrunner-1.9.2
[23:18] <ion> geser: English text using German quotation marks to quote English text that uses ASCII quotation marks is a pretty sight. :-D
[23:30] <james_w> geser: it's not the ^M in the changelog from what I see
[23:32] <james_w> geser: oh, it is, sorry
[23:36] <wgrant> james_w, geser: Is this really a bug, then?
[23:36] <james_w> yes
[23:36] <james_w> IMO
[23:37] <james_w> ^M isn't a newline in a .changes file, soyuz shouldn't open it in a way that causes it to be interpreted as such
[23:38] <geser> the ^M (carriage return) should be in the changelog in the first place
[23:38] <wgrant> The policy manual doesn't seem to actually state what a newline is.
[23:38] <geser> s/should/shouldn't/
[23:38] <cjwatson> Policy doesn't specify, although I do tend to agree with James
[23:40] <geser> isn't the bug in the part that generates the .changes file for the sync?
[23:40] <james_w> soyuz?
[23:40] <james_w> :-)
[23:41] <Keybuk> pitti: bIlujDI' yIchegh()Qo'; yIHegh()!
[23:41] <james_w> yes, it could strip, but we could always do both
[23:41] <pitti> Keybuk: sorry, my Klingon is not that good, I'm afraid
[23:41] <BlackZ> hi geser ;)
[23:42] <geser> does python differentiate between "\n" and "\r" for newlines?
[23:42] <ogra> pitti, it is better to die() than to return() in failure
[23:43] <pitti> lol
[23:43] <pitti> the Perl mantra?
[23:43] <Lex79> james_w: reject again
[23:43] <Keybuk> exactly
[23:44] <Keybuk> idly thinking we should resurrect the idea of a Klingon translation again
[23:44] <james_w> geser: yes, but you can decide whether it does or not on Windows
[23:44] <Keybuk> because translating Ubuntu into a language that *cannot* express the meaning of the word Ubuntu appeals to me
[23:44] <Lex79> james_w: ah no, sorry :)
[23:44] <ion> keybuk: Hah
[23:44] <StevenK> Keybuk: \o/
[23:44] <james_w> Lex79: I haven't flushed yet :-)
[23:44] <Lex79> ok :)
[23:52] <Keybuk> njpatel_: are we there yet?
[23:53] <ogra> hrm, who broke indicator-session ? i cant lock my screen anymore with it
[23:56] <sebner> mighty Keybuk, what do you think about http://img534.imageshack.us/img534/418/ubuntulucid201002021.png ?
[23:57] <Keybuk> I think it's a fantastic example of early-cubist work
[23:57] <Keybuk> with a distinctly impressionist approach to colours
[23:58] <Keybuk> the linearity has some reflection in the work of modernist painters
[23:58] <Keybuk> but without the bold use of colour
[23:59] <directhex> micahg, is /usr/lib/xulrunner-addons no longer searched by firefox in lucid?
[23:59] <micahg> directhex: is this for a firefox-addon?