[00:16] <slangasek> cjwatson: hmm, most likely a winbind bug
[00:16] <slangasek> cjwatson: (re: 576717)
[00:16] <slangasek> ccheney: the crash is immediate upon trying to switch to slideshow mode
[00:26] <duongthaiha> hi I am doing some coding with java any one please could give me some advise about java profiler in ubuntu please? Thanks a lot
[00:29] <hyperair> hohoho java. good luck.
[00:29]  * hyperair 's sanity level: 30%
[00:29] <hyperair> i blame it all on java
[00:29] <duongthaiha> hyperair: is there any wrong with java?? :P
[00:29] <hyperair> duongthaiha: everything you can think of is wrong with java.
[00:30] <hyperair> *everything*
[00:30]  * hyperair highlights, bolds, and underlines everything
[00:30]  * hyperair circles it even
[00:30] <duongthaiha> hyperair: java is quite good may be it not the fastest but it work
[00:31] <hyperair> meh, programming in java is robbing me of my precious sanity
[00:33] <hyperair> in the last 24 hours:  15 files changed, 620 insertions(+), 243 deletions(-)
[00:34] <hyperair> all that is java
[00:35] <rafiyr> I'm not sure which is worse to see, C programmers trying to use java, or java programmers trying to use C.
[00:36] <rafiyr> I guess I've seen one example of a (supposed) java programmer writing C that probably trumps.
[00:36] <hyperair> rafiyr: how about C++ programmers forced to use java.
[00:36] <hyperair> a java programmer writing C is going to nullify all pointers everywhere and expect them to free themselves
[00:37] <rafiyr> hyperair: hm, that's a toughy
[00:37] <hyperair> and then complain that there's no System.gc()
[00:38] <hyperair> well, to summarize: C programmers trying to use java = nothing but static functions. Java programmers trying to use C = memory leaks every damn where, which... hey, isn't too far from using Java straight off.
[00:38] <hyperair> considering how much memory Java takes
[00:38] <hyperair> for the love of god, i don't even have a single large data structure worth talking about, and my swing/AWT UI is already taking up nearly 100M of memory.
[00:39] <rafiyr> A couple weeks ago, I helped a labmate debug a C++ header problem.  The class definition had ifdefs that were indirectly effected by the compile command line.  Missing one flag, the application that was trying to use the classes was seeing different offsets in the class.  Not particularly happy with c++ atm.
[00:39] <duongthaiha> hyperair:  there is a trade off of thing that java and C can do. I presume that you love C++ and hate java so much to say
[00:40] <rafiyr> hyperair: fish out of water, or drowning mammal, neither really work.
[00:40] <hyperair> rafiyr: yes, agreed.
[00:40] <hyperair> duongthaiha: good guess.
[00:40] <hyperair> duongthaiha: but my course requires java. so i do it grudgingly.
[00:40] <hyperair> duongthaiha: but for every moment i spend writing java, my sanity level decreases a little.
[00:41] <rafiyr> hyperair: its not the language, its the programmer :p
[00:41] <hyperair> rafiyr: i'll admit, i didn't account for the program architecture swelling up to this level of complexity.
[00:41] <duongthaiha> hyperair: lol i think u just get used to C++ I can see the different that cause you so much trouble.
[00:41] <rafiyr> my first experiences with java were for a class, and it was a particularly painful combination of circumstances
[00:42] <hyperair> duongthaiha: yeah, stuff like *real* multi-inheritance.
[00:42] <rafiyr> hyperair: clearly you should be using smalltalk
[00:42] <duongthaiha> hyperair: and that is the sanity level that you mentioned here?? I am a new bee so plz forgive me if that is not rite
[00:42] <hyperair> duongthaiha: interfaces are *weird*
[00:42] <rafiyr> hyperair: interfaces has some really nice uses though.
[00:43] <hyperair> duongthaiha: sanity level, in percentage = 100 - (percentage of how crazy i am at the moment)
[00:43] <hyperair> rafiyr: somewhat, but they can be completely done using abstract classes.
[00:43] <rafiyr> hyperair: Are you doing any ui or event based stuff?
[00:43] <duongthaiha> rafiyr: true it really work for the OO design
[00:43] <hyperair> rafiyr: everything i'm doing at the moment is event-based.
[00:44] <rafiyr> hyperair: Then be glad you're not starting with java 1.0, like I did
[00:44] <hyperair> rafiyr: i just finished stitching together two somewhat-separate UIs using some kind of glue (they're supposed to talk over the serial cable, but i needed to debug them first before unleashing the horrors of rs232 on them)
[00:44] <rafiyr> hyperair: It was such a mess, and the ground kept shifting as I coded.
[00:44] <hyperair> rafiyr: i... i... i don't know what to say.
[00:45] <duongthaiha> rafiyr: omg it must be ice age :D
[00:47] <rafiyr> Um, yeah, it sucked.  Didn't help that I'd never (well functionally never) written ui or event code before that, also very little graphics code.  First week on getting to college, "write a mouse driven newtonian fractal browser as a java applet".
[00:48] <rafiyr> hyperair: Try to take some solace in knowing that learning java is probably not going to hurt you in the long run.  And in the short term, take a deep breadth and mediate on not worrying array bounds checking.
[00:49] <hyperair> rafiyr: i take solace in knowing that java has no future anyway.
[00:49] <rafiyr> Are you looking forward to your next class forcing you to code in C#?
[00:49] <hyperair> from what i have heard, oracle's letting java rot. and so be it.
[00:49] <hyperair> C# >>> java.
[00:49] <hyperair> now, i haven't actually done C# code before, but i have patched banshee.
[00:49] <hyperair> in numerous occasions.
[00:49] <duongthaiha> hyperair: i not quite sure about that Java do have it strong point. and C# is a no no to me
[00:50] <hyperair> rafiyr: plus, i'm banshee's package maintainer ;-)
[00:50] <rafiyr> most of what matters has already been opened, is it gpl?  If there's a will, the  community could easily take on java dev.
[00:50] <hyperair> duongthaiha: why, because... the MICROSHAFT?!
[00:50] <rafiyr> hyperair: ah
[00:51] <rafiyr> hyperair: keep meaning to try out c#, but so little motivation, and so many more interesting languages I want to play with.
[00:51] <hyperair> rafiyr: true that. but it will take a long while to get the ball rolling.
[00:51] <hyperair> rafiyr: heh i've been interested in looking at vala.
[00:51] <hyperair> rafiyr: it's the closest to gobject level that doesn't involve actually touching gobject things.
[00:51] <duongthaiha> i used that for my uni dissertation a long time (it might change now) and it really dontt suite me. I dont like the idea of changing the value of variable using the same method.
[00:51] <rafiyr> hyperair: So why do you hate java, yet willingly maintain C# ports
[00:52] <duongthaiha> rafiyr: good quetion
[00:52] <hyperair> rafiyr: perhaps because i haven't been forced to code extensively in it.
[00:52] <hyperair> rafiyr: another reason is the efficiency of the runtimes.
[00:52] <hyperair> rafiyr: get me an efficient java runtime and i'll rethink my hate.
[00:53] <rafiyr> I've been pretty disappointed with gcj.
[00:53] <hyperair> java is slow and bloated, mono is pretty damn fast, has Gtk+ support (i mean native support, not the cheap emulation swing does), can interface with C libraries easily, and has a pretty small footprint.
[00:53] <hyperair> make that Gtk# of course
[00:54] <rafiyr> hyperair: are you complaining about the ui performance or the raw compute performance?
[00:54] <hyperair> rafiyr: three aspects.
[00:54] <hyperair> rafiyr: memory, computing, UI
[00:55] <hyperair> rafiyr: memory, as well as startup time is where java excels at failing.
[00:55] <rafiyr> hyperair: I guess I should benchmark java vs C performance for some of my work.  But in general, its not been that bad.
[00:55] <hyperair> rafiyr: try startup time.
[00:55] <hyperair> rafiyr: even with everything cached, it takes some time for it to load.
[00:56] <rafiyr> hyperair: for most of my work, where a batch process runs for minutes or more, a couple of extra seconds is irrelevant
[00:56] <hyperair> rafiyr: how about a java plugin hanging your firefox for minutes, and rendering your main browser useless.
[00:57] <hyperair> until it finishes loading
[00:57] <hyperair> by the way, it took ~5 minutes for it to show the "Do you want to run this unsecured applet" dialog
[00:57] <hyperair> *5*!!
[00:57] <rafiyr> As for memory, yes java errs on the side of bloat, but the overhead over the raw data doesn't need to be all that bad.  And well, 6G/$100 (roughly)
[00:57] <hyperair> er what? 6G?
[00:57] <rafiyr> hyperair: memory is pretty cheap
[00:58] <hyperair> rafiyr: try owning a computer that uses DDR1 RAM only.
[00:58] <rafiyr> Not saying java is good for everything, just that for many environments the costs aren't that bad compared to the benefits
[00:58] <hyperair> my sanity is a pretty high cost.
[00:58] <ion> Now go and learn Lisp, Erlang and Haskell. :-P
[00:59] <hyperair> but my grades are also a pretty important benefit.
[00:59] <rafiyr> hyperair: Yeah, well my first java experiences were on a p90 and a bunch of sgi indy's.  ddr???
[00:59] <hyperair> rafiyr: well you were talking about cheapness of memory.
[00:59] <rafiyr> :)
[00:59] <hyperair> rafiyr: i'm just saying RAM isn't as cheap as you think.
[01:00] <hyperair> especially in third world coutnries.. there's so much more you can buy with that money saved from not buying RAM
[01:00] <rafiyr> hyperair: as I said, java has its place, but that's not necessarily everywhere.  Like embedded systems, wtf, who'd want to run java on a phone.
[01:00] <hyperair> j2me \o/
[01:00] <hyperair> lol
[01:01] <hyperair> and android
[01:01] <rafiyr> hyperair: I looked into j2me a couple times, but really wtf.
[01:01] <hyperair> yeah, those are the people who want java on a phone
[01:01] <hyperair> i dunno, i like the j2me app i maintain (remuco)
[01:01] <rafiyr> hyperair: sure, as you said there's a degree of insanity here
[01:01] <hyperair> i just don't program it =p
[01:01] <hyperair> heh
[01:01] <rafiyr> what's the min effort to get "hello world"
[01:02] <hyperair> echo hello world
[01:02] <rafiyr> you don't need a specialized profile, or a compiler specific to your device?
[01:02] <hyperair> get bash ported \o/
[01:02] <rafiyr> :p
[01:03] <rafiyr> see, there's another one, why use bash when you could use zsh.
[01:03] <rafiyr> and my phone does run both
[01:06] <rafiyr> hyperair: Anyway, just remember its not that C++ doesn't have issues, you've just accumulated a tolerance.  Also, knowing C++ should make java pretty simple, once you stop crying morning the loss of overloading and macros.
[01:09] <hyperair> rafiyr: it's not that it's hard to program in java. it's just that i feel... annoyed.
[01:09] <hyperair> rafiyr: irritated.
[01:10] <hyperair> one of the reasons was that java was introduced to me in a module that uses written exam papers.
[01:11] <hyperair> and you know how longwinded java's goddamned class names are.
[01:11] <hyperair> and interface names. and exception names.
[01:11] <hyperair> it's one thing to have code completion do that for you, but it's another thing entirely to write everything out in full.
[01:11] <hyperair> *handwrite*
[01:11] <hyperair> speakin of which i should probably go get JDEE working on emacs so i don't have to keep typing out everythign in full.
[03:07] <nigelbabu> imbrandon: you want to take a course for the UUD?
[03:08] <imbrandon> nigelbabu: yes i just signed up to lead one ( Command Line Basics 1 & 2 )
[03:09] <imbrandon> nigelbabu: why, whats up ?
[03:09] <nigelbabu> imbrandon: oh, w00t, cool.  I'll accept you in once the schedule is confirmed :)
[03:09]  * nigelbabu just got mail :)
[03:09] <imbrandon> ahh
[03:15] <cwillu_at_work> heh
[03:15] <cwillu_at_work> mental note:  don't set cups-pdf to use /tmp as the destination, it changes the permissions on /tmp
[03:21] <hyperair> lol i'll kep that in mind =p
[04:02] <crypt-0> does the ubuntu-server kernel have the XTS modue once installed?
[04:53] <amikrop> Hello, I ask here, since here are some developers, so they should know: What is the location of the icons of the "featured/default directories (Documents, Videos, Pictures)?
[05:10] <amikrop> Where can I find Ambiance's folder/places icons?
[06:51] <andersk> Are there going to be ddebs for maverick?
[06:52] <imbrandon> there are now ...
[06:53] <imbrandon> andersk: http://ddebs.ubuntu.com/pool/
[06:55] <andersk> That’s the APT pool for http://ddebs.ubuntu.com/dists/ , which has hardy, jaunty, karmic, and lucid but not maverick.
[06:56] <imbrandon> as the builds continue i'm sure the ddebs will be added, there isnt any reason why they wouldent
[06:56] <andersk> Oh I see, the ddebs are in the pool but there is no APT repository for them.
[07:35] <LucidFox> Bah. Linuxdcpp upstream response to the indicator patch:
[07:35] <LucidFox> "Oh, ok. I assumed it was something included in the new gnome, but if it's just an Ubuntu solo project we don't need this. I just hope that the patched version doesn't cause any problems, since the bugs are likely reported here..."
[07:37] <nigelbabu> LucidFox: how unfriendly :/
[07:39] <ccheney> slangasek: if it is immediate then i don't see it in compiz, will try switching to metacity
[07:40] <ccheney> slangasek: not able to reproduce under metacity either
[08:04] <pitti> bigon: smart-notifier> we regularly do that anyway, so don't worry; I did it yesterday
[08:14] <bigon> pitti: thx :)
[08:17] <pitti> Riddell, james_w, cjwatson, slangasek: are you currently doing syncs? I wanted to do a few, but there are unflushed syncs in the queue
[08:17] <james_w> not me
[08:17] <StevenK> pitti: Not me either
[08:18] <pitti> it looks flushable, but I don't want to step on someone's toes
[08:19] <pitti> they were done half an hour ago
[08:19] <pitti> well, I'll just flush them
[08:34] <cjwatson> pitti: I was
[08:34] <cjwatson> pitti: they were OK to flush, but should have been flushed with NOMAILS=-M
[08:34] <pitti> cjwatson: I did
[08:35] <cjwatson> ok, good
[08:42] <wookey_> is there a specific UDS channel? It doesn't say on https://wiki.ubuntu.com/UDS-M/Handout
[08:43] <james_w> #ubuntu-uds
[08:43] <wookey_> cheers
[09:52] <joaopinto> good morning
[12:55]  * ccheney wonders where the three weeks cut will happen for maverick
[12:56] <ccheney> oh and where did alpha 1 go for maverick, we start with an alpha 2 it seems
[12:56] <ccheney> oh nevermind, i misread a-2 as alpha 2
[13:28] <slangasek> ccheney: hah - so after having downgraded OOo to karmic, and now reupgrading, F5 no longer crashes
[13:29] <statik> hi lifeless, the debian/sid udd import for erlang is quite out of date, do you happen to know who the right person to poke is?
[13:30] <mr_pouit> james_w I guess
[13:31] <cjwatson> statik: all Debian imports are out of date at the moment due (indirectly) to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577759
[13:31] <statik> thanks
[13:31] <slangasek> erlang, however, is last imported in January, with the failure shown (in unfriendly content-type :) at http://package-import.ubuntu.com/failures/erlang
[13:32] <cjwatson> it means that (a) Launchpad's debmirror of Debian unstable fails (b) gina (which populates https://launchpad.net/debian) fails (c) package-import thinks it has nothing to do
[13:32] <slangasek> (not that I can help interpret why that error happens, so --> james_w anyway :)
[13:32] <cjwatson> mm, well that's a timeout error
[13:32] <cjwatson> so another attempt might succeed ...?
[13:33] <slangasek> how to trigger another attempt?
[13:33] <cjwatson> the OOPS id there isn't available on lp-oops
[13:33] <slangasek> AFAIK that interface is also a james_w RPC ;)
[13:33] <txwikinger> Is there a gobby document for the last kubuntu session?
[13:33] <cjwatson> I assume it's expired
[13:33] <txwikinger> wrong channel :)
[13:34] <cjwatson> well, fixing the Debian archive would also wind up triggering another attempt, ultimately
[13:34] <Laney> cjwatson: the cli-mono set doesn't exist on lucid
[13:34] <Laney> maverick even
[13:34] <cjwatson> oh, I suppose that wouldn't have been covered by my migration script
[13:35] <Laney> can you add pinta to it too?
[13:36] <statik> cjwatson, thanks for that, it helps quite a bit. i will chase down james_w sometime today. I want to merge the latest erlang from sid into maverick, i was planning to use bzr merge-package, what would be the right way to carry on while the sid branch is out of date? bzr import-dsc perhaps?
[13:39] <cjwatson> Laney: done and done
[13:40] <cjwatson> statik: not sure, I tend to wait peersonally :)
[13:40] <cjwatson> -e
[13:40] <Laney> cheers
[13:40] <Laney> I wonder why pinta isn't in NEW
[13:40] <cjwatson> because we haven't done a new-sources pass yet
[13:40] <cjwatson> that's separate from the basic autosync
[13:40] <cjwatson> new-source rather
[13:40] <Laney> ah
[13:40] <cjwatson> $ new-source | wc -l
[13:40] <cjwatson> 417
[13:41] <cjwatson> may take a while, we do need to do basic checks on the names to make sure we're not accidentally reintroducing deliberately-removed packages
[13:41] <cjwatson> I'll do pinta now though
[13:54] <Laney> urgh, LP is still rejecting
[13:54] <Laney> guess it needs some time
[14:01] <wgrant> Laney: LP doesn't need any time for that.
[14:01] <wgrant> It should just work.
[14:05] <Laney> wgrant: Signer is not permitted to upload to the component 'main'
[14:05]  * Laney tries once more
[14:06] <Laney> oh, I don't have cli-mono permissions for maverick
[14:07] <Laney> this seems somewhat suboptimal
[14:07] <wgrant> Laney: Yeah, that would be the problem.
[14:07] <wgrant> => not a bug!
[14:07]  * wgrant is safe, for now.
[14:08] <Laney> well, maybe they should copy to new releases by default ;)
[14:08] <wgrant> Pfft.
[14:10] <cjwatson> Laney: oh, ok, I'll fix that - thought I already had
[14:10] <cjwatson> copying over package sets in general is a bit of a pain, I'd like initialize-from-parent to do it automatically really
[14:10] <Laney> yes, that sounds sensible
[14:12] <StevenK> cjwatson: Is there a bug for that i-f-p thing?
[14:15] <cjwatson> StevenK: not yet, sorry
[14:18] <psusi> what is the proper procedure for correcting errors in the release notes?  it says that dpkg runs slower on ext4... this is not the case.. it runs slower period in order to deal with ext4... it behaves the same on ext3
[14:18] <cjwatson> psusi: that does not match my personally-conducted tests
[14:18] <cjwatson> therefore it must be more complicated than that
[14:18] <cjwatson> I tested very carefully on ext3 and the results were within margin of error
[14:18] <psusi> cjwatson: how so?  it doesn't check what fs you are using... it does the sync() either way
[14:18] <cjwatson> psusi: feel free to file a bug on the ubuntu-release-notes project
[14:19] <cjwatson> and it doesn't slow things down on ext3
[14:19] <cjwatson> in my experience
[14:19] <psusi> hrm... that's odd...
[14:19] <cjwatson> perhaps so.  nevertheless
[14:20] <cjwatson> this data is the reason the release note is written that way
[14:20] <psusi> so you didn't see a slow down relative to before the fsync patch?  what about relative to ext4?
[14:20] <cjwatson> I didn't test on ext4, but others did
[14:20] <cjwatson> relative to before the fsync patch> correct
[14:21] <psusi> could be that ext3 basically internally was forcing a sync behavior, so explicitly doing it has no further effect...
[14:21] <psusi> so without the fsync patch, ext4 was faster, but dangerous, with it, they behave the same
[14:21] <cjwatson> sorry, I assumed that when you said "it behaves the same on ext3" you had data to support that
[14:21] <cjwatson> do you not?
[14:22] <james_w> statik: there's also a failure importing erlang, I'll have to dig a little deeper
[14:22] <psusi> no... just a working theory so far... I know that dpkg calls sync the same on both ext3 and ext4, and ext3 did not have the problem that required the sync.. if it had no impact on performance, it seems likely that given the lack of change in performance, and the fact that ext3 already was writing in the correct order, that effectively ext3 already was doing a sync so the explicit sync is a noop
[14:23] <cjwatson> I would suggest that in general it's good to collect data before modifying the release notes, then :)
[14:24] <psusi> but either way, the notes suggest that ext4 is slower than ext3, and I do not believe that to be the case and it doesn't sound like you have data that indicates that :)
[14:24] <statik> james_w, thanks!
[14:24] <joaopinto> psusi, a debootstrap on ext4 takes 10x more time than an ext3, own experience
[14:25] <cjwatson> psusi: I have certainly received data from other people that indicates that.
[14:25] <cjwatson> and no data to the contrary that I remember.
[14:25] <psusi> joaopinto: wha?!
[14:25] <psusi> cjwatson: that it is slower than ext3, or that it is slower than before the patch also on ext4?
[14:25] <cjwatson> that before the patch they were fairly close, and after the patch it's much slower on ext4.
[14:25] <psusi> i.e. just because the patch slowed down ext4 does not mean it is now slower than ext3
[14:26] <cjwatson> by a factor of 5 in some cases.
[14:26] <cjwatson> this is trivially reproducible by timing the installer
[14:26] <cjwatson> Laney: fixed
[14:27] <psusi> hrm... I'll have to check that out then...
[14:28] <Laney> cjwatson: thanks
[14:28] <soren> Do we have a DMB meeting today?
[14:28] <cjwatson> tomorrow, isn't it?
[14:29] <soren> Oh, right.
[14:29] <soren> But it's still on?
[14:29] <soren> I forget what we decided.
[14:29] <cjwatson> I think so, but I do need to rearrange the schedule a bit to make a slot for it
[14:29] <soren> Oh, right, I remembre that.
[14:31] <Laney> subject: [ubuntu/maverick] tomboy 1.2.1-1ubuntu1 (Accepted)
[14:31] <Laney> cjwatson: good stuff, all working
[14:34] <joaopinto> psusi, just try a deboostrap on ext3 vs ext4
[14:35] <joaopinto> I am mounting ext4 with barrier=0 to have decent performance on sbuilds
[14:36] <psusi> damnit... debootstrap wants to download all the packages every time rather than cache them
[14:36] <joaopinto> I am using apt-cacher-ng for that ;)
[14:40] <joaopinto> psusi, someone commented the other day that the performance difference might be related to the "barriers" option, ext3 default is barriers=0, while ext4 uses barriers=1
[14:41] <joaopinto> s/barriers/barrier
[14:41] <psusi> funny... that should speed things up
[14:41] <psusi> since without barriers it has to do a full sync to commit journal transactions
[14:47] <joaopinto> http://lwn.net/Articles/283161/  - "So barriers are disabled by default because they have a serious impact on performance. And, beyond that, the fact is that people get away with running their filesystems without using barriers. Reports of ext3 filesystem corruption are few and far between. "
[14:48] <cjwatson> I explicitly tested this case with ext4 and barriers turned off, and there was no measurable performance difference
[14:48] <cjwatson> versus ext4's default of barriers being on
[14:49] <cjwatson> the test was timing the installer's base-installer and pkgsel steps
[14:49] <joaopinto> my tests were with debootstrap/sbuild
[14:49] <cjwatson> all I have been able to conclude so far is that nobody understands exactly where the slowdown is, or if they do then they aren't telling
[14:51] <james_w> statik: when you uploaded 1:13.b.3-dfsg-2ubuntu1, do you know if you dput before pushing to lp:ubuntu/erlang?
[15:08] <psusi> wow... when I tar up the debootstrap, then time untaring it, it takes about the same on both ext3 and ext4... ~13 seconds... on ext4 with barrier, drops to 9.6 seconds
[15:08]  * psusi wonders what dpkg is doing that makes unpacking so slow on ext4
[15:09] <psusi> and this is on karmic, so no sync changes
[15:10] <joaopinto> my tests were with lucid
[15:11] <joaopinto> I was using ext4 on karmic without this slowdown, I assume it was related to the dpkg fsync changes
[15:12] <psusi> yea, but I would expect that to hit ext3 the same exact way
[15:28] <statik> james_w: re: erlang I think I did bzr merge-package, bzr mark-uploaded, then dput. It is quite possible that I bungled it.
[15:29] <mterry> persia, can you resubscribe me to ~ubuntu-universe-sponsors?
[15:31] <james_w> statik: I'm just wondering if there may have been a couple of minutes or more after the dput before the push, as that would explain what I am seeing
[15:31] <james_w> statik: if you don't remember then I can dig a little deeper to check
[15:35] <statik> james_w: i think it did it all pretty close together, but i was double checking every step so i could have taken 3-4 minutes between steps
[15:37] <james_w> statik: right, I tend to push first to avoid this situation; I always knew there was a theoretical race here, but haven't seen anyone hit it before.
[15:58] <lool> jiboumans: Hey; https://blueprints.edge.launchpad.net/ubuntu/+spec/server-maverick-arm has no assignee, do you know who is leading the session?
[15:59] <lool> pgraner: Heya!  Got pinged about this interesting session https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-arm-single-zimage which differs slightly from device tree, but I think it's unscheduled; it is aimed at the kernel track, did you want to schedule it?
[16:17] <mick_laptop> anyone know how i can remotely coonect in to see the ubuntu developer summit?
[16:18] <crimsun> mick_laptop: as in https://wiki.ubuntu.com/UDS-M/RemoteParticipation ?
[16:19] <mick_laptop> yes :)
[16:19] <mick_laptop> crimsun: thanks
[16:21] <mick_laptop> crimsun: you wouldn't know how to access it via vlc would you?
[19:54] <Gadi> can someone tell me what replaced asoundconf in lucid to perform the alsa-to-pulseaudio redirection?
[20:09] <hyperair> Gadi: /usr/share/alsa/pulse-alsa.conf?
[20:18] <Gadi> hyperair: just what I was looking for, thanks!
[20:19] <hyperair> np
[20:38] <crimsun> Gadi: note that asoundconf was never replaced, just obsoleted.
[21:39] <bryceh> sbeattie, re bug 287215, the tag to add to indicate it really is a problem is 'lucid'.  Running apport-collect I believe should add that tag, or if not I'll have a script search for the needs-testing tag and then look at the Xorg.0.log to get the version, and tag accordingly
[21:40] <sbeattie> bryceh: for that specific bug, do you really want apport-collect output attached? It seems.... overkill to me.
[21:42] <bryceh> sbeattie, for that one, you can probably just tag 'lucid' and set it to Confirmed
[21:46] <bryceh> sbeattie, fwiw RAOF is maintaining X this next cycle
[21:48] <bryceh> sbeattie, probably the next step for this bug is to send it upstream, unless you want to try to provide a patch yourself; keyboard mapping issues tend to be among the lower priorities (compared with X crash and freeze bugs)
[21:56] <ryan22> hey everyone
[22:05] <Viper550> Is there an easy way to override system tray icons through icon themes for third-party programs?
[22:14] <txwikinger> hey ryan22
[22:15] <ryan22> @txikinger: hey
[23:58] <nemo> Hey guys... After screwing around w/ a bunch of pointless attempts to disable IPv6, I finally got things working over here using:
[23:58] <nemo> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/417757/comments/288
[23:58] <nemo> Whiiiich is fine and dandy for me.  But what about all the other poor users out there.  I was curious if something is LTS if ubuntu could offer something like an alternate glibc or something...
[23:58] <nemo> perhaps not appropriate for everyone, but, you know, for those having trouble