[12:08] <jdub> morning boys and girls
[12:08] <jdub> and mdz
[12:08] <mjg59> Oh, possibly not fontconfig
[12:09] <Nafallo> morning jdub :-)
[12:09] <dholbach> hey jdub
[12:09] <AlinuxOS> hm...great xterm shows the same console font :)
[12:09] <mjg59> AlinuxOS: No, that's the X one
[12:09] <mjg59> Probably unifont
[12:10] <mjg59> AlinuxOS: Ok. Once the new language-selector package hits daily CDs, the install should leave the correct font configuration
[12:10] <AlinuxOS> mjg59, ok so I purge unifont and restart X.
[12:10] <mjg59> AlinuxOS: It currently won't work for upgrades, but I'll get that fixed before release
[12:10] <mdz> AlinuxOS: where can I download that text file you use for testing?
[12:10] <AlinuxOS> mdz just a sec.
[12:10] <mjg59> mdz: Ah! dpkg-reconfigure -plow fontconfig-config
[12:11] <mjg59> That should make unifont available to fontconfig apps
[12:12] <AlinuxOS> https://launchpad.net/distros/ubuntu/+source/unifont/+bug/62849
[12:12] <Ubugtu> Malone bug 62849 in unifont "Georgian (ka) letters are very crappy!" [Undecided,Unconfirmed]
[12:13] <AlinuxOS> mdz, I've attached that text file.
[12:13] <jdub> dholbach: you guys totally have to figure out how to get to lca
[12:13] <dholbach> jdub: i hope you tell me once you know how we get there :)
[12:13] <mjg59> dput needs an option that checks my distribution line
[12:13] <AlinuxOS> mjg59, so you've fixed my Georgian issue ? :)
[12:14] <mjg59> AlinuxOS: For new installs, once the package is on the images
[12:14] <mdz> AlinuxOS: http://people.ubuntu.com/~mdz/temp/Screenshot-xterm.png http://people.ubuntu.com/~mdz/temp/Screenshot-xterm-1.png
[12:14] <ajmitch> hey jdub
[12:14] <mjg59> mdz: The second is 403
[12:14] <AlinuxOS> so there will be new ttf-bpg-georgian-fonts version 0.3 ?
[12:14] <mdz> fixed
[12:14] <mjg59> AlinuxOS: Yes, but that's not what fixed it
[12:15] <AlinuxOS> http://people.ubuntu.com/~mdz/temp/Screenshot-xterm.png THIS ONE IS SUPER!
[12:15] <jdub> morning ajmitch
[12:15] <AlinuxOS> mdz, it's really great.
[12:16] <zul> hey ajmitch
[12:16] <ajmitch> hi zul :)
[12:17] <AlinuxOS> mjg59, I suppose you will use the same fonts that in 0.3 for Debian right ? http://packages.debian.org/unstable/x11/ttf-bpg-georgian-fonts
[12:17] <AlinuxOS> because 0.2contains old(some malformed fonts).
[12:17] <mjg59> AlinuxOS: Yes
[12:18] <AlinuxOS> great ;)
[12:18] <AlinuxOS> ;)
[12:19] <AlinuxOS> mdz, http://people.ubuntu.com/~mdz/temp/Screenshot-xterm.png fonts on this screenshot are really very smart.
[12:23] <AlinuxOS> mdz, some improvements ? Or important decisions for unifont (or maybe for that misterious font)?
[12:35] <sabdfl> i get asked two questions about keyboard layout on upgrade, is that unavoidable?
[12:35] <sabdfl> am using aptitude to upgrade dapper to edgy, this was on kubuntu but iirc i saw the same on ubuntu
[12:36] <sabdfl> just thought back then that it would not happen at beta
[12:39] <Gman> sabdfl, http://thomas.apestaart.org/log/?p=409 ?
[12:39] <jdub> Gman: debconf questions
[12:39] <Gman> ah
[12:39] <jdub> Gman: not X breakage :)
[12:40] <desrt> isn't the entire purpose of the gnome keyboard settings to allow you to have different settings than the X defaults?
[12:41] <sabdfl> hey hey jdub
[12:48] <Nafallo> are there any reason edgy is still frozen? :-)
[12:53] <jdub> sabdfl: morning
[12:55] <bluefoxicy> Mem:    970640k total,   959848k used,    10792k free,      372k buffers
[12:55] <bluefoxicy> Swap:  2104472k total,   284616k used,  1819856k free,   741836k cached
[12:56] <bluefoxicy> ok, my kernel is EXTREMELY prefering to devote about 75% of my memory to disk cache and push a lot to swap, wtf?
[12:57] <bluefoxicy> holy crap, I swapoff -a; swapon -a and it immediately put 36 megs back in swap, with 500 megs of disk cache O_o
[12:57] <gnomefreak> did the beta get released?
[12:57] <Nafallo> gnomefreak: yes
[12:57] <gnomefreak> .me used daily build
[01:01] <Nafallo> mjg59: hi! reading bug #22336
[01:01] <Ubugtu> Malone bug 22336 in acpi-support "laptop overheats when performing CPU intensive tasks." [High,Confirmed]  http://launchpad.net/bugs/22336
[01:01] <Nafallo> mjg59: seems I don't have anything at all in /proc/acpi/thermal_zone/ :-P
[01:02] <Nafallo> mjg59: is that normal on current edgy, or has something changed somewhere?
[01:05] <AlinuxOS> mjg59, mdz Thank you and goodnight !
[01:21] <mjg59> Nafallo: Do you have any reason to believe you /should/ have something in thermal_zone?
[01:21] <Nafallo> mjg59: the other guys on the bug report has? :-)
[01:22] <Fujitsu> mjg59, Xorg's i810 is replaced by intel now, is it?
[01:22] <tseng> Fujitsu: i dont believe that is the case
[01:22] <Nafallo> mjg59: and since it seems I got that problem (workaround by using cpu_governor powersave) I though I might want to have something in there ;-)
[01:22] <Fujitsu> It says `X.Org X server -- Intel i8xx, i9xx display driver'
[01:22] <tseng> there is still the i810 is what video-all depends on
[01:23] <tseng> for now
[01:23] <mjg59> Fujitsu: No
[01:23] <mjg59> Nafallo: Not all machines expose anything
[01:23] <mjg59> If you did in previous versions and don't now, then maybe
[01:24] <Nafallo> mjg59: ah, oki. haven't checked before actually :-).
[01:24] <redcard> Okay.  I'll ask here.  I went Dapper->Edgy Beta , and it held back all the X stuff.  All of it.  X is symlinked to /bin/true.  What I need to do is remove all held packages.  How?
[01:25] <redcard> Or rather, the held status on all held packages.
[01:25] <Nafallo> woha! someone opened up the archive again :-)
[01:26] <Nafallo> ehm, nm. I think it was just delayed mails finding there way home.
[01:40] <jdong> Nafallo: not all laptops expose their thermal_zones
[01:40] <jdong> Nafallo: some are purely bios/hardware-controlled
[01:40] <jdong> (which frankly I like... less can go wrong in the buggy kernel department)
[01:41] <Nafallo> hm, maybe turning off powernowd and use only ondemand works for me then...
[01:41] <jdong> Nafallo: you still running dapper then?
[01:41] <Nafallo> edgy
[01:41] <jdong> Nafallo: then you should be using ondemand already...
[01:41] <Nafallo> seems just removing powernowd might do it :-P
[01:42] <jdong> Nafallo: if you have a reasonably mobile processor, powernowd passes control over to ondemand automagically
[01:43] <Nafallo> yea, but if it's not needed I might as well remove it :-)
[01:43] <jdong> Nafallo: absolutely. it saves an entire 300KB of valuable disk space :)
[01:44] <Nafallo> :-)
[01:44] <Nafallo> call me a minimalist if you like ;-). I don't like to have unused stuff installed :-P
[01:45] <jdong> I guess the slower seek rate makes the difference, as CFQ is a winner on my desktop
[01:45] <jdong> Kamion: ping
[01:46] <bluefoxicy> jdong:  did you see my mention of LiveCD magics earlier?
[01:46] <jdong> bluefoxicy: no, i didn't
[01:47] <bluefoxicy> jdong:  I'm hoping the layerfs guy will release under LGPL (he's expressed interest in this but didn't know if he had to register somewhere or something) for compressed file systems; but I'm thinking, tmpfs -> layerfs -> compressed ram-backed mount point -> unionfs
[01:47] <orphennui> hi
[01:47] <bluefoxicy> jdong:  that would basically make all the changes written into the tmpfs on the LiveCD compressed, saving RAM space; though I'm not entirely sure how much memory that accounts for normally
[01:47] <jdong> bluefoxicy: that sounds cool
[01:47] <orphennui> i'm getting a report that Gimmie no longer works on ubuntu for some reason.  I haven't seen a bug about this.  Does anyone know what's up?
[01:48] <bluefoxicy> It'd be cool yes; if you use 2M of memory, you're suddenly using 0.8-1.2M (zlib compression)
[01:48] <bluefoxicy> but that's not really that great
[01:48] <Nafallo> jdong: how do I set which one of them to use? (disc-scheduler)
[01:48] <jdong> Nafallo: /sys/block/<device>/queue/scheduler
[01:48] <bluefoxicy> now if we're talking about 10 or 20 megs typically THAT'S interesting... any idea what it takes just to boot and get to desktop?  What it takes to run Ubiquity (does it create temporary files)?
[01:49] <jdong> Nafallo: or system-wide default with kernel parameter elevator={as,cfq,deadline}
[01:49] <Nafallo> jdong: cating that gives me four of them, with []  around cfq. I can just echo with one of the others? :-)
[01:49] <jdong> Nafallo: right, echo one of them to set it
[01:49] <Nafallo> ah, oki. thanks.
[01:50] <Nafallo> nice :-)
[01:51] <jdong> Nafallo: anticipatory will reduce disk seeking, which should increase overall throughput, but could decrease multitasking responsiveness
[01:52] <jdong> Nafallo: so it's appropriate for when you need to keep up streams of disk IO (i.e. cd/dvd burning, file server), but not appropriate for watching your divx'es while performing backups :D
[01:52] <Nafallo> jdong: :-)
[01:53] <jdong> Nafallo: booting a livecd with elevator=as makes it much more responsive while ubiquity grinds away
[01:53] <Nafallo> I should probably use cfq then ;-)
[01:53] <jdong> (which was why I was trying to ping mr. ubiquity)
[01:55] <imbrandon> mdz, ping
[01:55] <imbrandon> mdz, unping
[01:56] <pygi> night all
[01:56] <ajmitch> night pygi
[01:57] <imbrandon> night pygi
[01:57] <imbrandon> ugh late
[01:57] <imbrandon> later Nafallo
[02:50] <jdong|amd64> mjg59: ping
[02:50] <mjg59> jdong|amd64: Hi
[02:51] <jdong|amd64> mjg59: just to say I'm on a system where I can reproduce bug 56587; wondering if you need any additional info
[02:51] <Ubugtu> Malone bug 56587 in usplash "[edgy]  usplash segfaults" [Medium,Confirmed]  http://launchpad.net/bugs/56587
[02:51] <jdong|amd64> mjg59: bzr revno 90 still crashes
[02:52] <mjg59> jdong|amd64: Uh. Last night you said it didn't.
[02:52] <jdong|amd64> mjg59: this is a new bug; the amd64+nvidia one?
[02:53] <jdong|amd64> mjg59: ati is all happy :)
[02:53] <mjg59> Sigh.
[02:53] <mjg59> Right. Could you get me a backtrace?
[02:53] <jdong|amd64> mjg59: I got an apport bundle-of-joy attached, with debugging symbols
[02:53] <jdong|amd64> http://librarian.launchpad.net/4540718/_sbin_usplash.0.crash
[02:55] <mjg59> Hrmph.
[02:56] <mjg59> Jesus x86emu is a piece of shit
[02:56] <mjg59> Ok
[02:56] <jdong|amd64> I'll bbl; let me know if you need any more info
[02:56] <jdong|amd64> my amd64 box is now happily edgy :)
[02:56] <mjg59> I'm going to upload what I have now and then work on this later on
[03:04] <mdz> slomo_: f-spot spins on me at the import dialog if I try to import a large number of photos at once; ever seen that before?
[03:07] <ajmitch> mdz: that's known
[03:14] <mdz> ajmitch: is it an f-spot problem or a mono problem?
[03:14] <ajmitch> f-spot problem
[03:14] <ajmitch> it's not doing the import asynchronously
[03:15] <Fujitsu> Hahah.
[03:15] <ajmitch> Fujitsu: sorry?
[03:15] <Fujitsu> It's importing everything synchronously?
[03:16] <Fujitsu> 'cause that's quite a nasty mistake.
[03:18] <ajmitch> something I had to track down, I'm sure it used to be better behaved
[03:29] <sbalneav> Evening all
[03:29] <ajmitch> hi sbalneav
[04:38] <mjg59> Dear apport:
[04:38] <mjg59> Why does running apt-get source xserver-xorg-core result in apt crashing and you consuming all my CPU?
[04:38] <mjg59> Ah, apt-get update has made things work
[04:39] <infinity> I turned off apport for that reason.
[04:39] <infinity> I was pretty miffed when I was debugging a segv in a 50-line C snippet, and it was taking longer for the thing to segv than it was to compile it.
[04:39] <infinity> (much longer)
[04:40] <infinity> I have a feeling this feature was not really aimed at developers. :)
[04:40] <infinity> Of course, now you get to laugh at me for admitting that I had to look more than once to find the segv in 50 lines of C, but in my defense, it was late and my eyes were crossed.
[04:44] <imbrandon> lol infinity ;P
[04:44] <imbrandon> happens to us all ;)
[04:59] <mjg59> Oh, now, wait a second
[04:59] <mjg59> apport just *killed my gdb*
[04:59] <mjg59> I am, shall we say, unamused
[05:01] <Fujitsu> apport seems to like doing nasty things like that.
[05:12] <nixternal> any ideas on fixing the "creating/updating hplip user" error?
[05:25] <fabbione> morning guys
[05:25] <ajmitch> hi fabbione
[06:46] <netdur> there is one feature I wanna request, but I don't know who to ask... GNOME's bugzilla or launchpad
[06:46] <netdur> I want menu (main menu, menu bar) to add "run as administrator" option
[06:51] <LaserJock> I would guess Gnome would be a good place for it
[06:51] <netdur> LaserJock, thanks
[07:33] <|thunder> wassup all.
[07:33] <|thunder> ive found a bug in gconf
[07:33] <|thunder> seems to be in both 32 and 64 bit ubuntu's
[07:35] <|thunder> there are a few settngs that are set to integer, they should be string, yet I cannot change them as the conbobox to do so is grey'd out.
[07:35] <|thunder> help
[07:42] <LaserJock> |thunder: please search http://launchpad.net/distros/ubuntu/+bugs for a bug report about it
[07:42] <LaserJock> |thunder: and if you can't find one please file one
[07:47] <|thunder> thanks
[08:31] <pitti> Good morning
[08:32] <ajmitch> morning pitti :)
[08:32] <pitti> hey ajmitch
[08:33] <realist> Good evening :-)
[08:35] <Burgundavia> hey pitti, ajmitch
[08:35] <ajmitch> hi Burgundavia, how's it going?
[08:36] <Burgundavia> not bad
[08:42] <imbrandon> moins pitti and Burgundavia
[08:43] <pitti> hey imbrandon
[09:11] <Keybuk> they should so re-label the left control key to be just "Wake Up"
[09:22] <imbrandon> lol Keybuk
[09:26] <Keybuk> ok
[09:26] <Keybuk> I am -> <- this close to upgrading my desktop edgy
[09:26] <Keybuk> the buggy-as-shit e-d-s in dapper is annoying the hell out of me
[09:26] <Keybuk> admittedly, it may not be better in edgy, but still
[09:26] <Fujitsu> e-d-s?
[09:26] <HrdwrBoB> evolution data server
[09:26] <Fujitsu> Ah.
[09:27] <Fujitsu> And what is this key dev doing running Dapper, when all the not-so-almight ones are running Edgy? :P
[09:27] <Fujitsu> *almighty
[09:27] <HrdwrBoB> because you want a stable platform as a desktop
[09:27] <Fujitsu> Probably, yeah.
[09:27] <HrdwrBoB> then you have development environments
[09:29] <imbrandon> Keybuk: well beta is as good as time as any to switch
[09:30] <imbrandon> i kept dapper on this laptop untill the other day, and an edgy dev machine for building etc
[09:30] <Keybuk> Fujitsu: I always run the stable release on my desktop, so I can always get work done
[09:30] <Keybuk> I can do builds and testing in a chroot
[09:31] <Fujitsu> Keybuk, but it's no fun having a working system :P
[09:31] <Keybuk> and I always run the development release on my laptop, and make sure that any files are backed up, so I can wipe it and reinstall it at any time without remorse
[09:31] <imbrandon> Keybuk: backport e-d-s ( atleaste for yourself ) ?!?
[09:31] <realist> Is there an Ubuntu equivalent to debootstrap?
[09:31] <Fujitsu> realist, debootstrap
[09:31] <infinity> realist: Yes, debootstrap
[09:31] <Keybuk> imbrandon: that'd involve backporting evolution, and gnome, etc.
[09:31] <imbrandon> realist: debootstrap
[09:31] <Keybuk> and backports are for children
[09:31] <imbrandon> true
[09:31] <Keybuk> it always seems to be calendar related
[09:32] <Keybuk> I can't switch to the calendar in evo, and clicking on the clock makes it hang
[09:32] <infinity> Keybuk: Those bits seem much-improved in edgy.
[09:32] <infinity> Keybuk: Much more responsive anyway, I never did have them outright hang on me in dapper.
[09:33] <Fujitsu> You're right, it's less laggy in Edgy.
[09:33] <janimo> infinity, Kamion: hi, can either of you push yesterdays xubuntu isos as betas or should I wait for tollef?
[09:34] <infinity> janimo: I'd prefer not to push the publish-release button, since this was Tollef and Colin's show.  One or both of them should be around soon, though.
[09:34] <janimo> infinity: ok thanks
[09:35] <Keybuk> infinity: the only other vaguely useful thing is that sometimes, after killing it, it disables my web calendars
[09:35] <Keybuk> so I've wondered if it's unable to deal with them not being available sometime
[09:42] <HrdwrBoB> ah. gg nautilus. 75% icons are HUGE, bigger than 100%
[09:45] <Keybuk> yay beta
[09:45] <Keybuk> *sigh*
[09:45] <Keybuk> "upstart doesn't load fuse module" ... "upstart doesn't display splash screen in correct colours" ... "upstart spilled my coffee"
[09:46] <Fujitsu> Hehehe.
[09:46] <Fujitsu> This is what we get when we rejig the world.
[09:46] <HrdwrBoB> "upstart stole my baby"
[09:46] <Keybuk> it amuses me that people always file bugs on the one thing they know that changed
[09:47] <imbrandon> hahah sooo true
[09:47] <Keybuk> "I upgraded from dapper to edgy beta, and clearly upstart was the ONLY THING THAT CHANGED"
[09:47] <ajmitch> heh
[09:47] <pitti> Keybuk: well, that and the splash screen
[09:47] <Keybuk> "upstart causes my network card to be not listed in network-manager"
[09:47] <Keybuk> W.T.F.?!
[09:47] <Fujitsu> Keybuk, that's your fault. Obviously.
[09:47] <HiddenWolf> Doh
[09:47] <realist> upstart being the init replacement, right?
[09:48] <Fujitsu> realist, yeah.
[09:48] <imbrandon> realist, yea
[09:48] <realist> Ahh well, they're only trying to help *smirk*
[09:48] <ajmitch> ah yes, bug 62862
[09:48] <Ubugtu> Malone bug 62862 in network-manager "Atheros w-lan card doesn`t work on edgy live!" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62862
[09:48] <Keybuk> [Bug 62872]  Upstart doesn't start Avahi
[09:48] <Ubugtu> Malone bug 62872 in upstart "Upstart doesn't start Avahi" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62872
[09:48] <Keybuk> yes, could that be that Avahi is DISABLED?
[09:48] <Fujitsu> Keybuk, upstart (and thus you) is personally responsible for every single regression.
[09:48] <Fujitsu> hahah
[09:48] <ajmitch> it makes you wish for a mass-reassign button in launchpad
[09:48] <Fujitsu> Keybuk, we love our users.
[09:50] <Fujitsu> Can't LP grow a tool which allows us to electrocute the person on the other end?
[09:50] <ajmitch> think of all the karma you can get by rejecting these
[09:50] <Fujitsu> `Always look on the bright side of completely loony bug reports.'
[09:50] <Keybuk> I don't think you get karma by rejecting bugs?
[09:51] <Fujitsu> Keybuk, I think you do...
[09:51] <realist> How is karma accrued?
[09:51] <imbrandon> i think you do
[09:51] <Fujitsu> realist, by doing stuff :)
[09:51] <Keybuk> At some point during Edge development cycle, booting has become
[09:51] <Keybuk> extremely slow. It takes almost three minutes from grub until X starts.
[09:51] <imbrandon> realist, clicking stuff on LP
[09:51] <Keybuk> This is on AMD64 running the latest everything.
[09:51] <Fujitsu> Keybuk, I'd think you would.
[09:51] <Keybuk> of course, this is an upstart bug
[09:51] <ajmitch> Keybuk: very technical description there
[09:51] <Fujitsu> Keybuk, naturally.
[09:52] <Keybuk> oh look
[09:52] <Keybuk> he has his dmesg attached
[09:52] <Keybuk> and oh look
[09:52] <Keybuk> it's an nvidia motherboard
[09:52] <imbrandon> haha
[09:53] <imbrandon> Keybuk, you had some coffee^Wtea^Wmt dew yet today ?
[09:54] <Fujitsu> Keybuk, have you considered writing a quick script to go through all the upstart bugs, reassign them to some other random package, and wait for people to assign the bugs that are actually upstart's fault back to upstart?
[09:54] <Fujitsu> I think that'd work quite well :P
[09:54] <infinity> Keybuk: The really curious question is, if he thought it was a bug in init, why did he bother including dmesg? :P
[09:54] <Keybuk> imbrandon: can't stand guiness
[09:54] <imbrandon> whoop
[09:55] <ajmitch> Keybuk: interesting, what is this usplash bug?
[09:55] <infinity> Keybuk: Sketchy interaction with svgalib and some nvidia chipsets, apparently.
[09:55] <rideout> So, somehow I borked all of python on my edgy system and have pulled out my hair for an hour trying to fix it
[09:56] <ajmitch> infinity: great, so I should hit it on reboot if I'm lucky
[09:57] <infinity> ajmitch: You have a curious definition of the word "luck".
[09:57] <Keybuk> infinity: so I understand
[09:57] <Fujitsu> infinity, he /is/ an NZer.
[09:57] <Keybuk> ajmitch: if you do, make sure you have bootchart intalled
[09:57] <ajmitch> hence why I don't reboot this box if I can help it
[09:57] <ajmitch> Keybuk: will do
[09:57] <Keybuk> rideout: upstart bug <g>
[09:57] <Keybuk> ajmitch: helps prove the bug
[09:57] <Fujitsu> Keybuk, no, upstart. I can assure you.
[09:58] <rideout> Keybuk: seriously or joking?
[09:58] <Keybuk> rideout: joking
[09:58] <imbrandon> heh
[09:58] <rideout> somehow the modules can't be found when any python program uses "import"
[09:59] <rideout> but there there, and update-python-modules seems to be working
[09:59] <HiddenWolf> Fujitsu: no, you can't shock people for filing bad bugs, that'd be bad karma.
[09:59] <Fujitsu> HiddenWolf, electrocuting people vs. gaining karma... Hm...
[10:00] <HiddenWolf> Fujitsu: you don't want bad karma, you want good karma. ;)
[10:02] <rideout> any thoughts?
[10:07] <lastnode> imbrandon, ping
[10:09] <dholbach> good morning
[10:09] <ajmitch> morning dholbach :)
[10:10] <dholbach> hey ajmitch
[10:11] <ajmitch> Keybuk: your upstart branch appears to miss an nih directory that Makefile.am refers to
[10:12] <Fujitsu> What do these changes do?
[10:12] <ajmitch> selinux policy loading
[10:12] <Keybuk> ajmitch: read HACKING
[10:12] <Keybuk> which tells you where to get that directory from ;)
[10:12] <ajmitch> ah, figures I'd miss something obvious again
[10:13] <Keybuk> interesting ... it seems from reading LKML that Linus actually agrees with my interpretation of the GPL wrt GPL'd shared libraries
[10:14] <Fujitsu> Makes sense.
[10:14] <Fujitsu> You're right about most things, so's he. Of course you should come to the same conclusion.
[10:14] <Keybuk> heh, I'm wrong about a great many things too
[10:17] <Keybuk> Fujitsu: many people are adamant that I'm wrong
[10:17] <Fujitsu> Hey sabdfl.
[10:17] <Fujitsu> Keybuk, is that a surprise?  Well, I did, anyway. But I was wrong! It actually creates a whole new copy of the password file, and then renames it over the top of the old one."
[10:41] <Keybuk> *blink*
[10:41] <Keybuk> well, err, duh
[10:41] <Keybuk> is that not the standard way in which all files are modified? :)
[10:41] <Treenaks> Keybuk: not _all_ files :)
[10:42] <Keybuk> if you don't do it like that, then you don't get an atomic write
[10:42] <pitti> adduser *could* do with appending, too, but deluser?
[10:42] <pitti> hi tkamppeter
[10:42] <Keybuk> pitti: power goes in the middle => corrupt passwd file
[10:42] <pitti> Keybuk: (I know)
[10:42] <Keybuk> at least with fsync();fclose();rename() you know the filesystem will at worst only corrupt the temporary file
[10:42] <realist> Keybuk: hence using "vipw" to edit the /etc/passwd file
[10:42] <Treenaks> Keybuk: so, who wrote this?
[10:43] <Keybuk> Treenaks: gnome dude on their planet
[10:44] <ogra> Keybuk, bug 62861, fuse does the following now (it used to just add fuse to /etc/modules, but that changed in debian)
[10:44] <Ubugtu> Malone bug 62861 in fuse "fuse module not loaded" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62861
[10:44] <ogra>   if invoke-rc.d udev reload 2>/dev/null; then
[10:44] <ogra>   modprobe --first-time fuse 2>/dev/null ||
[10:44] <ogra>         echo -n add > /sys/class/misc/fuse/uevent
[10:44] <ogra>   fi
[10:44] <ogra> do you think that suffices ?
[10:44] <Keybuk> ogra: uh, that won't do anything after a reboot
[10:44] <ogra> ah, k, i'll add the code from ltspfs to it then ...
[10:45] <Keybuk> he does go on to say an interesting observation about autoconf, etc. though
[10:45] <ogra> i just read your last comments ...
[10:46] <ogra> oh, that wasnt targeted to me i guess :)
[10:52] <seb128> could somebody help me to debug gdb?
[10:53] <seb128> it segfaults on gaim, rhythmbox, ekiga ...
[10:53] <fabbione> seb128: did you try rebuilding gdb without stack-protector?
[10:54] <fabbione> seb128: i have seen it going crazy recently with threaded apps...
[10:54] <fabbione> not sure if that might be related
[10:54] <seb128> fabbione: I tried stack, I tried 6.5 from upstream too
[10:54] <seb128> grumpf
[10:54] <seb128> fabbione: I tried *that*, I tried 6.5 from upstream too
[10:54] <pitti> dapper's 6.4 was much better, wasn't it?
[10:54] <fabbione> hmm
[10:54] <pitti> . o O { maybe we shoud rollback to that stable version instead of our 6.5 beta)
[10:55] <seb128> pitti: it worked
[10:55] <fabbione> seb128: can you try to build a very simple test case?
[10:55] <Keybuk> seb128: I can't even get gdb to work at the moment
[10:55] <Keybuk> I was going to beat doko or pitti up about it
[10:55] <fabbione> like hello.c and see if it segfaults there too?
[10:55] <Keybuk> it just claims "unable to read stack frame" or something
[10:55] <Keybuk> like, gee, helpful
[10:55] <seb128> gdb works fine on most of apps
[10:55] <seb128> not on gaim, rhythmbox, ekiga though
[10:55] <pitti> Keybuk: of the topmost function? yeah, I noticed that, too, a pretty recent regression
[10:55] <seb128> an valgrind doesn't work on multithreaded programs neither
[10:56] <seb128> "valgrind: m_debuginfo/storage.c:311 (vgModuleLocal_addDiCfSI): Assertion 'cfsi->len > 0 && cfsi->len < 2000000' failed."
[10:56] <seb128> that starts being pretty annoying to do debug on edgy
[10:56] <pitti> seb128: 'it worked' -> with 6.5 final or no SSP you don't get the crashes?
[10:56] <seb128> no
[10:56] <seb128> it worked with dapper
[10:56] <pitti> ah, right
[10:57] <seb128> no luck on edgy, with or without ssp, with current edgy or 6.5 upstream
[10:57] <seb128> I'll try build to install the dapper package
[10:57] <pitti> an interesting test would be to build 6.4 on edgy
[10:57] <seb128> I think I tried some time ago, was not working neither
[10:57] <pitti> I'm not entirely convinced that it is a gdb problem
[10:57] <pitti> our gdb didn't change in ages, and when I wrote the pkg-create-dbgsym test suite we alread had it
[10:57] <seb128> I'm pretty convinced it's not
[10:58] <seb128> I tried the dapper deb some time ago
[10:58] <pitti> still I only noticed the test suite failure due to gdb regression recently
[10:58] <seb128> and it was not crashing but not working neither
[10:58] <pitti> so 6.4.90 built on dapper is likely to work
[10:59] <seb128> "thread_db_get_info: cannot get thread info: generic error"
[10:59] <seb128> the dapper version does that
[10:59] <seb128> that's already what it was doing when I tried some time ago
[11:00] <seb128> so that's not coming from gdb itself
[11:00] <seb128> that package works fine on dapper
[11:01] <seb128> http://sourceware.org/ml/gdb/2006-09/msg00059.html
[11:01] <pitti> nice - apport runtime reduced from 25 s to 0.7 s for a test bash crash
[11:02] <seb128> waouh
[11:02] <seb128> how did you do that?
[11:02] <pitti> seb128: several optimizations and shifting many expensive bits to apport-gtk
[11:02] <pitti> tfheen: I alread had heuristic optimizations for that before
[11:03] <pitti> tfheen: if the binary name is a substring of the package name, or vice versa, finding the package is quite fast
[11:07] <Keybuk> LOL @ http://maps.google.com/maps?hl=en&t=k&q=Germany&ie=UTF8&z=18&ll=48.857699,10.205451&spn=0.002404,0.006738&om=1
[11:07] <pitti> Keybuk: the bug invasion?
[11:07] <Keybuk> yeah
[11:10] <pitti> seb128: well, and for firefox I still get a respectable 3:30 mins -> 30 seconds
[11:10] <mvo> mjg59: hi! thanks for your language-selector upload. could you send me a debdiff please so that I can put it into my bzr tree? the upload is still in the unapproved queue
[11:10] <pitti> seb128: (ugh, I should have tested that on my slow laptop much earlier...)
[11:12] <pitti> ok, changing from laptop to desktop, brb
[11:13] <mjg59> mvo: http://www.codon.org.uk/~mjg59/tmp/language-selector.debdiff
[11:13] <mvo> mjg59: thanks!
[11:17] <ogra> pitti, according to a support request the bug in the autosink was already introduced in a dapper upgrade ...
[11:18] <ogra> (the one with LTSP)
[11:18] <mjg59> mvo: Did you get my bug about fontconfig-voodoo?
[11:18] <mvo> mjg59: I'm behind on bugs currently, let me have a look
[11:19] <seb128> re
[11:19] <seb128> I hate whatever DoS my desktop when an app crash
[11:19] <seb128> either the linux patch or appport
[11:19] <mvo> mjg59: right, got it and it is indeed a problem
[11:19] <tfheen> seb128: just fix the bugs (or turn off apport?)
[11:19] <seb128> I got my amd64 frozon for 10 minuts after gdb crash
[11:21] <seb128> tfheen: I would be happy to fix bugs, having gdb or valgrind working would help for that :p
[11:21] <mvo> seb128: apt-get install gdb ;)
[11:21] <seb128> mvo: did you read that chan the previous half an hour? :p
[11:22] <seb128> mvo: gdb segfautls on ekiga, rhythmbox, gaim, etc
[11:22] <seb128> mvo: you just stepped to help me to fix it apparently, thank you ;)
[11:22] <mvo> nay, some of the conversation had the words "problem", "error" and "segfault" in it and I blend that out automatically
[11:23] <pitti> seb128: for that I'm afraid I have to sacrifice the 'sort coredump to the end' fix
[11:23] <tfheen> seb128: works for me on amd64.
[11:23] <seb128> pitti: why?
[11:23] <seb128> tfheen: valgrind?
[11:23] <tfheen> seb128: gdb
[11:23] <tfheen> valgrind blows up
[11:23] <pitti> seb128: otherwise apport-gtk had to write the whole report file again; apart from performance issues, this also bears some other difficulties
[11:24] <seb128> tfheen: do you have a jabber account?
[11:24] <seb128> tfheen: you are to my list, could you go online, I'll send you a file
[11:25] <seb128> tfheen: it makes gaim crash, it crashes gdb too for me and dholbach (and pitti IIRC)
[11:25] <seb128> tfheen: if it works fine for you I'm happy to get the bt for it, other way you can confirm that gdb crashes
[11:25] <dholbach> tfheen: did you manage to capture the crash in gdb?
[11:25] <seb128> dholbach: he just said he has no crash
[11:25] <dholbach> ok, that's why gdb is happy
[11:26] <tfheen> "gdb valgrind ekiga" seems happy here.
[11:26] <tfheen> (or rather --args ekiga)
[11:26] <seb128> tfheen: attach gdb to gaim before accepting ;)
[11:27] <tfheen> seb128: it probably doesn't work from here because of my nice network setup.
[11:27] <seb128> ddc, etc don't work usually for me due to masquerading
[11:27] <seb128> but jabber transferts seem to work
[11:27] <tfheen> I'm on wireless too, so unless it does in-band, it won't work.
[11:28] <seb128> hum, k
[11:28] <tfheen> seb128: ok, try again
[11:29] <tfheen> Program received signal SIGPIPE, Broken pipe.
[11:29] <seb128> k
[11:29] <seb128> and gdb did crash with it?
[11:29] <tfheen> I guess I should really install the gaim-dbg package too?
[11:30] <tfheen> no, gdb is happy as can be
[11:30] <seb128> would be better yep
[11:32] <tfheen> seb128: ok, doit.
[11:33] <seb128> tfheen: done
[11:33] <tfheen> seb128: http://rafb.net/paste/results/XOdBHk29.html
[11:33] <tfheen> is the backtrace
[11:33] <tfheen> gdb is happy still
[11:34] <seb128> k, so it's doesn't happen to everybody
[11:34] <seb128> thank you for the bt, will update the bug about it with that ;)
[11:34] <tfheen> np; tell me if there's anything more you need
[11:34] <seb128> fixing valgrind on amd64 would be nice :p
[11:35] <tfheen> I'm still not really well, so I'm not really working today.
[11:35] <seb128> tfheen: don't worry, it's broken for some time and that's not really something useful to average user, no hurry for it
[11:36] <seb128> tfheen: better to take care of yourself today, you deserve it after the beta rush ;)
[11:39] <pitti> seb128: apport writes the core dump, and apport-gtk adds packaging/os/gdb information; apport-gtk can only append to the report or completely rewrite it, not insert new stuff in between
[11:41] <seb128> pitti: maybe we should make "crash file without coredump" the default?
[11:41] <seb128> pitti: because my browser chockes every time I click on a crash file from a bug
[11:41] <seb128> and we don't do anything with the coredump atm anyway
[11:45] <pitti> seb128: well, we need it to get better stack traces
[11:46] <seb128> pitti: can we get better straces with it atm?
[11:46] <pitti> seb128: I'll update apport-retrace soon to download ddebs automatically on request
[11:46] <seb128> right, but that's client side
[11:46] <pitti> seb128: I'd rather solve that problem by changing the extension or something so that ffox defaults to downloading the file instead of displaying it
[11:47] <seb128> I mean do we need to coredump on the bug page?
[11:47] <seb128> usually I want a quick look at the bt
[11:47] <pitti> seb128: well, it might be useful to debug the problem
[11:47] <seb128> I don't want to download 10M for that
[11:47] <pitti> seb128: hm
[11:47] <seb128> I mean the coredump is useful
[11:47] <pitti> seb128: apport-retrace offers to remove the core dump from the report
[11:48] <seb128> but most of the time I quick lock the bt to mark as dup
[11:48] <pitti> seb128: so as soon as we have automatic processing of these reports, that'll be solved
[11:48] <seb128> s/lock/look
[11:48] <Kamion> elmo: cdimage size should be saner now
[11:48] <seb128> right
[11:48] <pitti> seb128: but I'm afraid I don't have a truly quick solutino
[11:48] <pitti> seb128: let's talk about it in 30 mins or so, I need some food
[11:48] <seb128> sure
[11:49] <Kamion> sabdfl: the questions on upgrade are a console-setup bug, which I thought I'd fixed
[11:50] <Kamion> sabdfl: assuming they were asking you for keyboard layout and variant respectively
[11:51] <Kamion> sabdfl: perhaps you could file a bug on console-setup and attach the output of 'echo GET debian-installer/keymap | sudo debconf-communicate', 'sudo debconf-show console-setup', and the contents of /etc/default/console-setup
[11:51] <Kamion> you might still get a question if this is a system that has been upgraded continuously from a fresh Debian woody install all the way to edgy, though
[11:52] <Kamion> (in which case debian-installer/keymap won't be set)
[11:59] <lfittl> hrmm, something weird happened with compiz-plugins 0.5-0ubuntu4, it is listed on my Packages package as built sucessfully, but nowhere else in launchpad (no buildlogs, ..)
[11:59] <tfheen> Kamion: that might be why I saw it, since one of my systems is really a slackware '96 installation slightly mangled over the years.
[12:08] <pitti> seb128: re
[12:08] <seb128> pitti: wb
[12:09] <pitti> seb128: and the current sort order helps you for that, and ffox does not choke?
[12:10] <seb128> pitti: I can click on the "stop" button after a few sec
[12:10] <pitti> ok
[12:10] <seb128> pitti: so it doesn't load the whole crash file
[12:10] <pitti> seb128: alright, let me think about that problem
[12:10] <pitti> seb128: I can load, modify, and rewrite the complete report; it takes *much* longer for the user, but so be it
[12:10] <Kamion> tfheen: ha
[12:11] <seb128> pitti: no no, nothing taking much longer
[12:11] <Kamion> lfittl: I only shunted it through unapproved very recently; I'm surprised it built
[12:11] <doko_> Kamion: the queue remains in manual mode for main?
[12:11] <seb128> pitti: I can cope with downloading the coredump if that reduces crash generation and makes better user experience
[12:11] <Kamion> lfittl: although looking more closely there appear to have been two copies of the same version there
[12:11] <pitti> seb128: (appending one kb of packaging info to a ffox crash report is super-fast, rewriting it isn't)
[12:11] <seb128> pitti: k, keep it the fast way then
[12:12] <Kamion> doko_: yes, mdz wants to leave it that way for a while (a day or so) to let the mirrors concentrate on serving the beta
[12:12] <pitti> seb128: I'll think about it; if I don't find a robust way to rewrite it without unpacking/packing the core dump, I'll just append
[12:13] <seb128> ok, thank you
[12:13] <lfittl> Kamion: yep, the version slomo uploaded and mine, but we agreed mine is better (fixes the problem by using shlibs instead of hardcoding it), should I do anything to get this into the archive?
[12:13] <Kamion> lfittl: check what source package actually landed in the archive; if it's slomo's, you should supersede it with another upload
[12:13] <Kamion> lfittl: in general you should try to avoid two uploads with the same version number - it's confusing for everyone
[12:14] <lfittl> Kamion: it wasn't intended, just coincidence ;)
[12:15] <Kamion> o
[12:15] <Kamion> ok
[12:15] <lfittl> Kamion: hmm, the archive has no source package of this version, only the old one
[12:15] <Kamion> doko_: if there's something that's urgent, I can accept it
[12:15] <Kamion> lfittl: it will still be publishing; wait about 30 minutes
[12:16] <lfittl> Kamion: ok, and if I reupload then, I should use a new version number, right?
[12:17] <Kamion> lfittl: absolutely
[12:17] <lfittl> Kamion: good, thanks for your help
[12:17] <Kamion> version numbers are cheap; you don't need to conserve them
[12:17] <Kamion> at this point, an upload with the same version number would be rejected, anyway
[12:18] <Kamion> it's a soyuz bug that one of your uploads wasn't rejected earlier
[12:21] <doko_> Kamion: java-gcj-compat would be nice as a prerequisite of the next OOo; axis and wsdl4j in NEW are required for tomcat5.5, which is then required by eclipse (not sure if Keybuk did look at these two); you could reject the pending python2.4 upload, it will be superseeded by a followup upload anyway
[12:32] <Keybuk> Kamion: what's the policy on uploads currently, btw?
[12:32] <Keybuk> I see everything is still getting tipped into unapproved
[12:33] <Kamion> doko_: java-gcj-compat accepted, python2.4 rejected
[12:33] <Kamion> Keybuk: 11:12 < Kamion> doko_: yes, mdz wants to leave it that way for a while (a day or so) to let the mirrors concentrate on serving the beta
[12:33] <Keybuk> ok
[12:33] <Kamion> we're back to feature freeze though - it's purely an administrative thing at this point
[12:33] <Keybuk> *nods*
[12:40] <seb128> re
[12:40] <seb128> another 15min of DoS after gdb crash, next time I stop apport before :p
[12:41] <pitti> seb128: yeah, yeah, I'm working on it :-P
[12:41] <seb128> I don't get why the load goes over 10 though
[12:41] <pitti> seb128: (I hope 15 min was just a metaphoric overstatement)
[12:41] <seb128> I've nothing against it working
[12:42] <seb128> but the mouse cursor jumping every few sec and the box not usuable is no fun
[12:42] <Kamion> pitti: I'll work on the openssh DoS in edgy if you like
[12:42] <Kamion> unless you're already on it; I hadn't seen anything
[12:42] <pitti> Kamion: oh, I appreciate that
[12:42] <seb128> pitti: no, I went away from the computer for 10min and it was still not responding, and that's an amd64 with 1Go of RAM and a fast disk
[12:42] <pitti> Kamion: no, I didn't start on it yet
[12:43] <Kamion> I'm upgrading Debian to 4.4p1 nowish
[12:43] <Kamion> I think edgy should just be patched though
[12:43] <pitti> Kamion: yeah, we need the patches anyway for stables
[12:44] <pitti> Kamion: do you have the three CVEs?
[12:44] <Kamion> oh, uh, can't do Debian yet because there isn't an updated GSSAPI patch yet
[12:44] <Kamion> meh, will just have to patch it
[12:45] <Kamion> pitti: CVE-2006-4924 is the only one I have
[12:46] <pitti> Kamion: 'unsafe signal hander': CVE-2006-5051, 'authentication abort': CVE-2006-5052
[12:47] <pitti> Kamion: in the 'security fixes' section of the announcement (http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=115939141729160&w=2)
[12:47] <pitti> Kamion: I have a patch for CVE-2006-5051 in my mailbox, if you need it
[12:49] <Kamion> pitti: I'll grab them from upstream CVS, but if you can forward what you have to me, that would be good
[12:49] <Kamion> then I can compare them
[12:51] <seb128> pitti: the DoS doesn't seem to be due to apport itself, that's just a "not enough swap available" issue
[12:54] <pitti> Kamion: mailed you info about 5051, /msg'ed you cvs links for CVE-2006-4924
[12:55] <elmo> Kamion: thanks
[12:57] <janimo> seb128: hi, what is the plan re python-gnome2?
[12:58] <Kamion> pitti: thanks
[12:58] <Kamion> janimo: published xubuntu beta
[12:59] <janimo> Kamion: saw it, thanks
[01:01] <fabbione> Kamion: i uploaded cpio to dapper-updates, up to you when you want to unleash it for sfllaw
[01:01] <fabbione> hem
[01:01] <fabbione> dapper-proposed i meant
[01:23] <Riddell> tfheen, Kamion: are uploads to main still blocked?
[01:25] <tfheen> Riddell: yes, waiting for mirrors to ride off the initial load and such.
[01:25] <StevenK> tfheen: What's with the non-Mithrandir nick?
[01:26] <tfheen> StevenK: vawad (my usual machine) is behind a really stupid NAT ATM, so I can IRC off it.  Mith will be back once that's fixed.
[01:32] <HiddenWolf> tfheen: well, torrent is under hardly any load at all at the moment, how bad can the mirrors be doing. :)
[01:33] <tfheen> HiddenWolf: *shrug*; mdz wanted it that way, I'm not going to argue
[01:33] <HiddenWolf> :)
[01:33] <HiddenWolf> wise policy
[01:34] <tfheen> it's not like it really matters that much either.
[01:45] <tkamppeter> hi pitti
[01:50] <heno> tfheen: hello!
[01:51] <tfheen> heno: how's the new place coming together?
[01:52] <heno> tfheen: ok, slowly. Since I started work again this week I haven't done much in the house :)
[01:52] <heno> Most of my stuff will get here in about 2 weeks
[01:52] <tfheen> heno: I knew I shouldn't have fixed your DSL, then. ;-)
[01:52] <heno> heh
[01:58] <slomo__> tfheen, Kamion: hm are my dbus/libnotify/notification-daemon uploads lost somewhere or just not approved yet?
[01:58] <tfheen> slomo__: edgy is still frozen, it'll be thawed in a couple of hours
[01:59] <slomo__> tfheen: oh sorry for uploading them then... i thought with the beta release it was officially unfrozen :(
[02:00] <tfheen> slomo__: well, it's just frozen in LP, we're past beta release so anything uploaded while it's frozen will be accepted in a bit.
[02:00] <elmo> Kamion: did you see the  discussion mdz and I had last night about torrents?
[02:09] <janimo> seb128: hi
[02:09] <seb128> janimo: Hi
[02:10] <janimo> seb128: how do you propose we get on with python-gnome, now we are past beta?
[02:11] <seb128> janimo: I'm busy with other things atm, I'll do that later when archive is unfrozen
[02:12] <janimo> seb128: I did not mean that you upload now of course, just pinged as a remainder
[02:12] <janimo> thanks
[02:12] <seb128> janimo: np ;)
[02:31] <bddebian> Howdy folks
[02:32] <pygi> bddebian: and hi again :P
[02:32] <bddebian> Sheesh :-)
[02:35] <heno> doko: when it try to upgrade with the source list entries you sent I end up with a new openoffice.org-java-common and a few other things, but all of openoffice gets held back. Is that as expected or should I force it through?
[02:36] <heno> *when I try
[02:40] <heno> eh, nevermind. It seems to be installing now
[02:44] <sfllaw> fabbione: Just saw my name.
[02:52] <sandy> i can't input chinese in gaim  ?  why
[02:52] <sandy> help
[02:54] <desrt> sandy; seriously wrong channel.  ask in #ubuntu.
[02:55] <sandy> #ubuntu ?
[02:56] <abattoir> sandy: yes, and #ubuntu-cn might be helpful as well
[02:57] <sandy> thanks
[02:57] <sandy> bye
[03:10] <dholbach> doko_, heno: nice that ooo seems fixed wrt a11y
[03:11] <doko_> dholbach: it is?
[03:11] <dholbach> doko_: at least heno wasn't able to reproduce it
[03:11] <doko_> ahh, I see. heno, cool!
[03:12] <doko_> heno: pulled some FC patches
[03:12] <dholbach> doko_: how did you fix it?
[03:12] <dholbach> ahhh nice
[03:13] <dholbach> heno: now we only need to fix the gnometerminal-tab-weirdness and the evolution crasher (with a11y enabled)
[03:15] <doko_> heno: btw, you are able to enable the hicontrast icons in OOo, but just manually
[03:16] <doko_> heno: and with the new packages only, if you have the openoffice.org-style-hicontrast package installed.
[03:20] <dholbach> doko_: how many icons are in that package?
[03:21] <doko_> $ unzip -v /usr/lib/openoffice/share/config/images_hicontrast.zip | wc -l
[03:21] <doko_> 7509
[03:21] <Riddell> Keybuk: please give back ruby1.9 on ppc
[03:21] <dholbach> wow
[03:21] <dholbach> doko_: then I didn't have them all installed
[03:21] <dholbach> doko_: those are not the usr/share/icons/locolor icons?
[03:22] <Keybuk> Riddell: is the bug fixed?
[03:22] <Riddell> Keybuk: yes
[03:22] <Keybuk> ok
[03:22] <doko_> dholbach: no, there are no locolor icons
[03:24] <Kamion> elmo: I've removed knot-3 from torrent.u.c; anything else I need to remove?
[03:25] <elmo> Kamion: mdz was suggesting we remove hoary, dvd's, source and dailies too *shrug*
[03:28] <Kamion> hoary should go, the rest will come right back with the next daily build and I'm not keen on removing them because if I do I'll be deluged with people asking me why they're missing
[03:29] <Kamion> killed hoary
[03:30] <pitti> seb128: ok, I'm rewriting the full report now; I need to load the core dump anyway for doing the backtraces, so it's not that much overhead
[03:31] <pitti> seb128: IOW, CoreDump will be at the very end, as usual
[03:31] <seb128> pitti: cool
[03:40] <ogra> mjg59, there is a ipw2200 version you have to run with ndiswrapper ?
[03:41] <Keybuk> ogra: some people seem to use ndiswrapper for drivers that are better supported under Linux than they are under Windows!
[03:41] <ogra> (someone just told me his card isnt supported by the driver we ship ?)
[03:42] <ogra> Keybuk, but i cant imagine that there is a ipw2200 based card that doesnt work at all with our (intels) drive
[03:42] <ogra> r
[03:42] <Treenaks> ogra: there's another chip, called 'ipn2200'
[03:43] <Treenaks> ogra: that's completely not ipw2200.. the names are just very much alike
[03:43] <ogra> thast not from intel, is it ?
[03:43] <Treenaks> ogra: not intel, indeed
[03:43] <ogra> i think i have such a card around on a broken lappie here, it was never supported ... not even with ndiswrapper
[03:44] <janimo> Kamion,  bug 48047 , it seems to be ok for 6.06 but now 6.06.1 has the issue
[03:44] <Ubugtu> Malone bug 48047 in xubuntu-meta "wrong jigdo files" [Medium,Confirmed]  http://launchpad.net/bugs/48047
[03:44] <janimo> I don't use jigdo but by the look of the files seems there's something wrong there
[03:46] <sabdfl> does mercurial 0.9.1 *really* depend on python 2.5?
[03:47] <_ion> When Malone says someone is the "creator" of a package that has been automatically synced from Debian without changes (e.g. bddebian with preload), exactly what does that mean?
[03:47] <Kamion> _ion: "creator" is the person who appeared in the Changed-By field in the .changes file
[03:48] <Kamion> it's a terrible name, should be "uploader" (I filed a bug ages ago)
[03:48] <Kamion> or "last changed by"
[03:48] <Kamion> _ion: for syncs, it's the person who requested the sync
[03:48] <_ion> Ok, thanks.
[03:48] <Kamion> so we do sync-source -b kamion foo, which creates foo_VERSION_source.changes with Changed-By: Colin Watson<EMAIL_ADDRESS>[03:48] <Kamion> (say)
[03:49] <janimo> sabdfl: unlikely as in debian is deps on python <<2.5
[03:49] <sabdfl> pls can we fix that package then?
[03:49] <Kamion> maybe it picks the highest of pyversions or something
[03:49] <sabdfl> should i file a bug and assign to... was uploaded by motu
[03:50] <Kamion> sabdfl: it was a sync
[03:50] <janimo> Kamion: the depends line has both 2.4 and 2.5
[03:50] <doko_> Kamion, Keybuk: please ack the binary wsdl4j in NEW, and icu4j source
[03:50] <sabdfl> aptitude wants to pull in 2.5
[03:50] <doko_> janimo: package?
[03:50] <Kamion> janimo: it also has python2.5
[03:50] <janimo> doko_ mercurial
[03:50] <Kamion> (but not python2.4)
[03:50] <doko_> janimo: looking
[03:50] <Kamion> janimo: thanks, checking now
[03:50] <janimo> doko_: actually not both... just python2.5
[03:50] <janimo> and also python >=2.4
[03:57] <heno> doko_, dholbach: yep, ooo seems good now. I'll play with the icons next
[03:58] <heno> and keep using ooo with at-spi turned on and see if anything pops up
[04:00] <mhb> hello
[04:00] <Kamion> janimo: fixed, thanks
[04:00] <mhb> I've attached a fix to this bug: https://launchpad.net/distros/ubuntu/+source/mozilla-firefox-locale-all/+bug/61875 but someone has to commit it, I guess
[04:00] <Ubugtu> Malone bug 61875 in mozilla-firefox-locale-all "[edgy]  Keyboard shortcuts for "Add page to bookmarks..." and "Save page as..." are the same" [Undecided,Confirmed]
[04:01] <janimo> Kamion: thanks
[04:02] <mhb> can someone tell me what should I do next, whom should I contact?
[04:06] <lucas> infinity: there was a lot of ruby-related build failures on powerpc which should be fixed now, but they need to be re-queued.
[04:08] <tfheen> lucas: do you have a list of packages?
[04:09] <lucas> tfheen: no. some of them are on https://launchpad.net/people/lucas/+packages, but all packages which aren't arch: all that transitively build-dep on ruby are affected
[04:09] <lucas> (on ppc only)
[04:10] <lucas> I mailed infinity three or four times over the last months about those ruby build problems on ppc, but it was only fixed recently by Riddell
[04:11] <tfheen> given that ruby itself failed to build, that's not very surprising
[04:12] <Kamion> doko_: wsdl4j/icu4j done
[04:12] <Kamion> lucas: it was a kernel bug (or at least it was fixed by upgrading the kernel on davis) - it wasn't something that repeatedly mailing somebody was necessarily likely to solve
[04:12] <elmo> lucas: it wasn't fixed by Riddell, the root cause was diagnosed by BenC (after several others had tried), and it wasn't exactly obvious, there's no point repeatedly complaining about it
[04:13] <tfheen> lucas: anyway, *ruby* which ftbfs-ed given back.  Please do tell me if there are more packages.
[04:14] <lucas> I probably mailed him about once a month, never got any answer from him, I wouldn't call that "repeatedly complaining".
[04:15] <Kamion> lucas: it wasn't something infinity could particularly easily fix; such things often end up sitting in people's queues if they think they *might* be able to figure it out in the futre
[04:15] <elmo> lucas: the complaining I'm talking about is how you keep banging on about how you've mailed Adam
[04:16] <mjg59> ogra: No
[04:17] <lucas> Kamion,elmo: maybe we need another way to track buildd problems then. Is there a way to submit bugs on malone about such problems ?
[04:17] <doko_> janimo: uploaded
[04:18] <elmo> lucas: it wasn't a buildd problem
[04:18] <elmo> it was a kernel problem
[04:18] <BenC> no, it was a ruby problem
[04:18] <elmo> (which btw, makes all "I don't have access to the buildds -> I can't debug it" claims bunk)
[04:18] <elmo> BenC: ok, that works too ;-)
[04:18] <BenC> it's triggered by differences in the kernels
[04:19] <Kamion> lucas: "won't build" is a perfectly normal bug report against the package in question
[04:19] <BenC> benh did a code audit of ruby and called it horrid crud :)
[04:19] <BenC> or something along those lines
[04:19] <pitti> Hi BenC
[04:19] <Kamion> BenC: out of curiosity, what was the bug in ruby?
[04:19] <lucas> elmo: not being able to reproduce it myself is still a problem
[04:19] <BenC> Kamion: you were on the rigth track
[04:19] <Kamion> I got as far as determining that it was something to do with threading and gave up in despair
[04:20] <lucas> Kamion: won't build + assign to who ?
[04:20] <Kamion> lucas: in general you shouldn't be assigning bugs to people unless you're their manager
[04:20] <BenC> racy locking and such
[04:20] <elmo> lucas: anyone with access to a powerpc could have reproduced it
[04:20] <Kamion> or in a similar position of being able to instruct them to fix it
[04:20] <BenC> pitti: hey
[04:20] <lucas> Kamion: s/who/which team/ ?
[04:20] <Kamion> lucas: don't
[04:20] <Kamion> leave it assigned to nobody unless you know that somebody is actually working on it
[04:20] <Kamion> fictitious assignments are a pain
[04:21] <pitti> BenC: I'm a bit puzzled about bug 62972
[04:21] <Ubugtu> Malone bug 62972 in linux-source-2.6.17 "leaves core files behind after calling crashdump-helper" [High,Unconfirmed]  http://launchpad.net/bugs/62972
[04:21] <pitti> BenC: IIRC apport should not remove core dumps, or shall it?
[04:22] <BenC> pitti: is this new?
[04:22] <pitti> BenC: I noticed core files laying around since only recently
[04:22] <pitti> BenC: since -8 or -10 (I never used -9 since it didn't boot)
[04:23] <pitti> BenC: and since my home dir gets an automatic backup, I'll notice unusual size increasing quite fast
[04:23] <BenC> pitti: damnit...ok, need to check on that
[04:23] <BenC> pitti: I'll mark this bug for release, and high
[04:24] <pitti> I already did
[04:24] <BenC> heh, already done :)
[04:24] <pitti> BenC: thanks
[04:24] <mhb> I'll try it again - anyone able to finalize 61875 ?
[04:24] <mhb> bug 61875
[04:24] <Ubugtu> Malone bug 61875 in mozilla-firefox-locale-all "[edgy]  Keyboard shortcuts for "Add page to bookmarks..." and "Save page as..." are the same" [Undecided,Confirmed]  http://launchpad.net/bugs/61875
[04:25] <pitti> mhb: looks easy, I'll take it
[04:25] <pitti> mhb: thank you!
[04:25] <mhb> pitti: I fixed it, all it takes is to submit the patch
[04:25] <pitti> mhb: (btw, I can apply patches to the jar files)
[04:26] <pitti> mhb: marked accordingly, will be fixed by the final release
[04:26] <mhb> pitti: thanks
[04:27] <mhb> pitti: the diff of the only modified file in the jar archive is there as well
[04:27] <pitti> mhb: yeah, I saw it
[04:28] <sfllaw> fabbione: What's an "SRU" and where is this policy found?
[04:30] <jdong> sfllaw: wiki, StableReleaseUpdates
[04:30] <sfllaw> jdong: Thanks.
[04:33] <jdong> imbrandon / Tonio_: poke... so what _does_ happen to duplicate uploads?
[04:34] <Tonio_> jdong Hum, first one will be accepted and second one rejected because of already existing
[04:34] <janimo> pitti, hi could you look at the printer tool and gxine in your next review session? thanks
[04:34] <Tonio_> jdong btw main is still locked actually
[04:34] <jdong> Tonio_: aha, that explains why it wasn't accepted yet
[04:34] <Tonio_> jdong extactly
[04:34] <jdong> thx
[04:36] <pitti> imbrandon, janimo: most probably I have to shift the review session to Monday, sorry
[04:49] <doko_> infinity, cprov: please requeue axis (edgy)
[04:52] <pygi> sivang: ping for a sec?
[05:04] <fabbione> sfllaw: did you find it?
[05:05] <sfllaw> fabbione: Yes, thanks.
[05:05] <sabdfl> how can i play the new sounds without rebooting?
[05:05] <BenC> pitti: working on the crash-helper issue now
[05:05] <sabdfl> where are they?
[05:06] <seb128> sabdfl: aplay /usr/share/sounds/login.wav
[05:06] <fabbione> hey BenC
[05:06] <seb128> sabdfl: and aplay /usr/share/sounds/logout.wav
[05:06] <sabdfl> thanks seb128
[05:06] <seb128> np
[05:07] <BenC> fabbione: hey
[05:08] <Hobbsee> jdong: mind emailing them to me or something?  i want to hear them.
[05:08] <jdong> jdong|amd64: didn't I shut you off last night?
[05:09] <jdong> jdong|amd64: turn off, I command you... and don't bug me again until you have a working usplash!
[05:09] <jdong> hobbsee: hehe
[05:10] <enrico> mvo: hi, around?  I don't seem to be able to link with apt-pkg in debian anymore
[05:10] <jdong> hobbsee: grab ubuntu-sounds
[05:10] <enrico> .oO(I actually better /msg him, sorry for the noise)
[05:10] <mvo> enrico: g++ b0rkage, pleae rebuild apt, that should fix the issue
[05:10] <Hobbsee> jdong: point.
[05:11] <Hobbsee> jdong: my head's hurting really badly again, i've already blacked out this morning - forgive my brain being a little screwed.
[05:11] <sfllaw> Hobbsee: Ouch.
[05:11] <sfllaw> Hobbsee: Good plan.
[05:11] <jdong> hobbsee: ouch... hope you feel better
[05:11] <Hobbsee> hehe
[05:11] <Hobbsee> yeah
[05:11] <Hobbsee> i've never quite blacked out before.  rather interesting.
[05:11] <jdong> now, off to diagnose my hal....
[05:12] <jdong> *cough* bug 60989 *cough* kthxbye :)
[05:12] <Ubugtu> Malone bug 60989 in hal "HAL reports incorrect battery percentages" [Undecided,Unconfirmed]  http://launchpad.net/bugs/60989
[05:15] <Hobbsee> Hobbsee's cant be tickled while their head hurts.
[05:15] <tfheen> Hobbsee: dudette, I know how you feel after having fever and headache for the last three days.
[05:15] <zul> Hobbsee: lop your head off then :)
[05:15] <tfheen> s/having/& had/
[05:15] <Hobbsee> tfheen: yeah, true.
[05:15] <tfheen> Hobbsee: and I _did_ tickle you carefully with no poking or stomping or anything
[05:16] <Hobbsee> hehe
[05:16] <Hobbsee> indeed
[05:17] <Hobbsee> zul: *g*.  i think a few people will complain if i do that.
[05:18] <zul> Hobbsee: heh but it would stop your complaining :)
[05:18] <Hobbsee> there, i've stopped complaining.
[05:19] <zul> :P
[05:19] <tfheen> zul: you haven't switched the xen master branch to 2.6.17 yet?
[05:20] <Hobbsee> nice sounds.
[05:20] <zul> tfheen: no because amd64 is not quite working yet
[05:21] <jdong> yep, same problem on livecd
[05:22] <slomo__> pitti: ^--
[05:23] <pitti> nnnng, I gotta leave soon
[05:23] <Hobbsee> run :P
[05:23] <jdong> pitti: *sniff* *sniff* please....?
[05:23] <jdong> :)
[05:23] <Hobbsee> hehe
[05:23] <Hobbsee> night all
[05:23] <pitti> jdong: oh, that was since the most recent update?
[05:23] <jdong> pitti: correct
[05:24] <jdong> pitti: it fixed my formfactor bug but broke my battery percentages
[05:24] <pitti> jdong: very unlikely
[05:24] <slomo__> jdong: your machine seems to be a bit weird... you always have dbus bugs or bugs in software connected to dbus there ;)
[05:24] <pitti> jdong: it's probably debian/patches/00upstream-02-mWh-conversion.patch:
[05:24] <jdong> pitti: it worked great in knot2
[05:24] <pitti> jdong: introduced in <IP_ADDRESS>-0ubuntu10 (Tue, 12 Sep 2006)
[05:25] <jdong> hmm
[05:25] <pitti> jdong: can you please try building the hal source without that patch and check if it works again?
[05:25] <jdong> pitti: will do
[05:25] <pitti> jdong: the patch looked right, and it fixed stuff for many people
[05:25] <pitti> jdong: before hal assumed that mAh * mV = mWh instead of Wh
[05:25] <tfheen> mvo: do we have any docs online which Opera can link to which explains how to install stuff from the commercial repo?
[05:26] <pitti> jdong: please add your findings to the bug, I'll read it
[05:26] <jdong> pitti: ok, thanks for your time
[05:26] <pitti> you're welcome :)
[05:30] <mvo> tfheen: nothing that I'm aware of. maybe the docteam has created something on the wiki though
[05:31] <tfheen> mvo: hmm, ok.  I couldn't find anything which talked about using add/remove apps, but just adding the commercial repo by hand and similar.
[05:32] <mvo> tfheen: well it really should be a matter of clicking on "enable commercial" and then searching for opera
[05:32] <jdong> pitti: if you're still around, that patch was the culprit... I'm gonna add my findings to the bug ticket
[05:34] <pitti> jdong: ah, ok; so we now have to decide which fraction of hardware we will break *sigh*
[05:35] <jdong> :(
[05:35] <pitti> well, I'll have a closer look; the idea of the patch was right, but perhaps it has a bug
[05:36] <jdong> pitti: could be my laptop has quirky acpi?
[05:36] <jdong> pitti: apart from lshal, would any other info help you?
[05:36] <pitti> I don't know of any off-hand
[05:36] <jdong> pitti: would /proc/acpi/battery info do any good?
[05:37] <pitti> jdong: sounds helpful; just attach anything that might be useful :)
[05:37] <jdong> hehe, ok
[05:50] <elmo> tfheen/kamion: does lithium try to rsync from ports or something?
[05:50] <elmo> ah, nm, of course it does
[06:15] <`anthony> in case anyone cares - I was trying to upgrade the python dapper buildbot to edgy, but it fails with E: Couldn't configure pre-depend python-gtk2 for gnome-app-install, probably a dependency cycle.
[06:15] <`anthony> will try again in a couple of days, I guess...
[06:19] <Kamion> mvo: why's the Pre-Depends: python-gtk2 that `anthony mentioned in gnome-app-install?
[06:20] <Kamion> that's going to complicate upgrades a lot, surely, with the python2.4-* -> python-* transition in there as well
[06:20] <`anthony> if by "complicate" you mean "break", then yes :)
[06:20] <Kamion> mvo: gnome-app-install doesn't have a preinst, so ...
[06:20] <Kamion> `anthony: well, possibly changes elsewhere could make it not break, but it would still be very complicated
[06:21] <`anthony> I want to switch the buildbot to edgy because it acts as both a test for edgy and a test for python.
[06:21] <`anthony> it also runs with the intel C compiler instead of gcc, just to throw additional fun into the mix :)
[06:21] <Kamion> bug 59403
[06:21] <Ubugtu> Malone bug 59403 in gnome-app-install "g-a-i postinst fails if X is not running" [Critical,Fix released]  http://launchpad.net/bugs/59403
[06:22] <`anthony> X is running.
[06:22] <Kamion> not the point
[06:22] <Kamion> see the bug
[06:22] <Kamion> mvo: I cannot understand why changing Depends to Pre-Depends has any effect at all on the postinst
[06:22] <bluefoxicy> bah X usage is regularly maxing out and the system lags
[06:23] <Kamion> mvo: oh, unless there's a dependency loop in there, in which case postinst ordering would be random
[06:23] <`anthony> worth logging a lunchpad bug about it, or do people not care at this point about upgrades?
[06:23] <jdong> I am about to have evolution fetch 6000 messages via POP (400MB).... is this going to work?
[06:24] <Kamion> `anthony: I've reopened the bug abve
[06:25] <Kamion> above
[06:26] <`anthony> ah - just read far enough down in the bug report. yeah, that looks like the problem. wah
[06:27] <`anthony> well, removing gnome-app-install lets the upgrade proceed, at least. I'll add it back afterwards
[06:27] <`anthony> now that 2.5 is done, it's time for buildbot maintenance. yay.
[06:29] <`anthony> don't know if there's any value to having a saved virtual machine of dapper, and an automated test that tries to upgrade it to edgy...
[06:29] <mdz> morning folks
[06:30] <mdz> Kamion: I didn't suggest removing dvd torrents, but the existing dailies and source
[06:30] <Kamion> that will only have any effect for about a day until we turn the dailies back on. Is it really worth it?
[06:30] <Kamion> it would be much better to improve the torrent.u.c UI
[06:31] <Kamion> (people do torrent the dailies)
[06:32] <Kamion> I'll remove the source, I guess - probably not enough people torrent that for it to be worth it
[06:32] <Kamion> oh, except that it's already gone
[06:32] <Kamion> I guess that was for old releases or someting
[06:32] <Kamion> something
[06:33] <Kamion> elmo: you might need to restart the tracker to pick up the fact that I removed a bunch of stuff?
[06:34] <Kamion> mdz: when do you want to thaw edgy? I've been letting the odd thing through unapproved that people need, but not everything
[06:35] <elmo> Kamion: it gets restarted on triggers, I think
[06:35] <`anthony> should I log other upgrade-blocking bugs?
[06:35] <Kamion> elmo: I've definitely triggered since removing some of those files
[06:35] <Kamion> `anthony: yes please
[06:35] <tfheen> mdz: I've poked *Process a bit and will continue to do so over the next week or so.  The basis looks good to me; I'm sure we need to go through it at least once to check that it's good, though.
[06:35] <`anthony> e.g. there was an "opera" symlink in /usr/X11R6/bin that blocked xorg-common.
[06:35] <`anthony> Ok dokey
[06:35] <mdz> Kamion: today
[06:36] <mdz> Kamion: (cf BetaProcess)
[06:36] <`anthony> x11-common, I meant. sigh
[06:36] <Kamion> oh, yes, I've been meaning to read that
[06:36] <Kamion> mdz: so, say, now? :)
[06:37] <mdz> Kamion: sure
[06:37] <elmo> Kamion: hmm, ok, kicking
[06:37] <mdz> tfheen: re: notifying the marketing team, I figured beta wouldn't need much time because of the work done for the milestones
[06:37] <Kamion> mdz: historically I don't think we've reverted the Beta change to debian-cd/CONF.sh
[06:37] <mdz> tfheen: but feel free to move it earlier if you or the marketing team feel it's appropriate
[06:37] <Kamion> I don't necessarily object to doing so, I guess
[06:38] <Kamion> mdz: needs somebody with a rubber duck to change the status in LP
[06:38] <tfheen> mdz: the marketing team is fairly small and we have a significant risk of hitting a time when everybody's busy/traveling/whatever.
[06:38] <mdz> Kamion: yes, at the time I suggested removing the dailies it was to be a temporary fix
[06:38] <Kamion> mdz: oh, I didn't realise that. bit late now then
[06:38] <mdz> tfheen: good point, edit as needed
[06:38] <mdz> Kamion: I'll fix lp
[06:39] <mdz> Kamion: I think it only needs a driver though
[06:39] <mdz> done
[06:39] <Kamion> oh, really? ok
[06:39] <mdz> Kamion: maybe not revert, but it should probably change at least
[06:39] <Kamion> no, I think it needs an admin now, I can't see the widget
[06:40] <mdz> Kamion: or does it still get a build number?
[06:40] <Kamion> there's always a build number
[06:40] <mdz> so long as the beta and the dailies are distinguishable, it's ok I guess
[06:40] <Kamion> I'll flip it back to Alpha, it doesn't seem outrageous
[06:41] <mdz> it sort of does actually
[06:41] <Kamion> Post-Beta?
[06:42] <mdz> the release is still beta-quality, but the CD builds could potentially get flaky since they're automated
[06:42] <mdz> it's a daily build of a beta tree
[06:43] <mdz> not sure what to call that
[06:43] <mdz> probably just a build number
[06:44] <Kamion> Post-Beta seems to express it pretty well
[06:45] <Kamion> unless we want to go for Gamma ;-)
[06:46] <Kamion> I've emptied unapproved
[06:49] <`anthony> maybe you should have a special "daily" quality tag, to denote that it's an automated build?
[06:54] <mdz> Kamion: beta daily?
[06:54] <Kamion> well, firstly, that's normally been "Alpha" up to now; secondly, all releases are merely copies of automated builds
[06:54] <mdz> we should probably call the dailies daily too
[06:55] <Kamion> mdz: doesn't make a lot of sense to me
[06:55] <mdz> Kamion: it doesn't seem right to call something beta which has seen zero testing
[06:55] <Kamion> well, why don't I just make it say "Daily Build"
[06:55] <Kamion> and people can deal
[06:55] <mdz> that's OK with me
[06:56] <mdz> mvo: have you and infinity worked out the correct fix for the langpack/livefs issue?
[06:56] <Kamion> right, third commit to CONF.sh :-)
[06:56] <Kamion> thanks
[06:56] <mvo> mdz: not yet
[06:57] <mdz> tfheen: did you intentionally target bug 57084?
[06:57] <Ubugtu> Malone bug 57084 in xorg-server "Please package Xephyr" [Wishlist,Fix released]  http://launchpad.net/bugs/57084
[06:57] <mdz> mvo: I can think of a few approaches but am not sure what's most correct
[06:57] <mdz> mvo: either we should consider the langpacks manually installed, or ubiquity should explicitly mark them manually installed after removing -live
[06:58] <mdz> it would be pretty silly to remove them and install them again
[06:58] <tfheen> mdz: yes, and I thought I had that fixed already too.
[06:58] <tfheen> mdz: not because it's so important, but more because I wanted it in (and get the previous, broken package out of universe)
[06:59] <mdz> mvo: does the existing API allow ubiquity to fix this?
[06:59] <tfheen> (I apparently have this fixed already, I just can't read)
[06:59] <Kamion> mdz: presumably, if a langpack is installed by language-selector, it will be considered manually installed?
[06:59] <mvo> mdz: yes, there is a apt-mark command that can be used for this
[06:59] <Kamion> if so, I think the livefs should be in sync with that
[06:59] <mdz> tfheen: neither can I
[06:59] <mdz> tfheen: this lack of sorting sucks
[06:59] <mdz> if they can' fix that easily, perhaps just hiding the fixed bugs would do
[07:00] <mdz> s/can'/&t/
[07:00] <mdz> Kamion: I don't follow
[07:00] <Kamion> mdz: doesn't installing support for a language with language-selector count as manually installing those language packs?
[07:00] <mdz> Kamion: I would say so, yes
[07:01] <Kamion> so I sort of feel that the livefs should be constructed as if you had installed that set of languages with language-selector
[07:01] <tfheen> mdz: I whined in the "sorting is broken" bug today; jamesh offered using advanced search as a workaround.
[07:01] <mdz> Kamion: I see, I think I agree
[07:01] <tfheen> (since that doesn't give you colspan=3)
[07:01] <Kamion> it doesn't have to be, and I can fix it in ubiquity if everyone disagrees, but that just feels cleanest to me
[07:01] <mdz> there's no point in apt wanting to autoremove them in the live environment depending on the language you booted
[07:02] <mdz> tfheen: yeah, I saw
[07:02] <Kamion> it's either code in livefs.sh or pretty much the same code in ubiquity, so whatever
[07:02] <mdz> tfheen: that actually lets us limit to main, too, which is nice
[07:03] <tfheen> mdz: true.  It just a workaround, though, and way more work than having it Just Work.
[07:04] <mdz> Kamion: I'm not sure what the livefs.sh bit would look like...special-case langpacks?
[07:04] <bluefoxicy> this experiment is over
[07:04] <bluefoxicy> I switched to evolution for my g-mail account a while back, but I've decided the memory usage is too much, so back to thunderbird.
[07:05] <bluefoxicy> (if I can figure out htf to get mail migrated BACK to thunderbird)
[07:06] <Kamion> mdz: sure
[07:06] <mdz> seb128: bug 3642 is targeted for edgy; can the same fix for suspend be applied to hibernate?
[07:07] <Ubugtu> Malone bug 3642 in Baltix "hibernate doesn't work from gdm itself" [Undecided,Unconfirmed]  http://launchpad.net/bugs/3642
[07:08] <mdz> Kamion: ok, I'll update bug 61684
[07:08] <Ubugtu> Malone bug 61684 in portmap "Removing any u-desktop depdencency marks all other packages for auto-removal (on alternate install)" [Undecided,Rejected]  http://launchpad.net/bugs/61684
[07:20] <cb_> Tried to upgrade to the latest beta...encountered errors in a duplicate python file that could not be deleted. How to handle this problem?
[07:21] <tfheen> file a bug?
[07:22] <mdz> tfheen: I've emailed a forums admin asking about how we should communicate about releases; for your other comments, please just go ahead and edit as necessary
[07:25] <tfheen> mdz: 'k
[07:30] <mvo> Kamion: I look into the postinst issue for g-a-i today
[07:36] <Kamion> mvo: thanks
[07:37] <rraphink> bug #1
[07:37] <Ubugtu> Malone bug 1 in ubuntu-meta "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
[07:42] <lastnode> mdz, if i was creating a py package, would i unpack my functions/classes to /usr/local/app ? ive looked through the debian python policy and it doesn't recommend a location. does ubuntu have a preferred place?
[07:42] <mdz> lastnode: I'm surprised if that's not in the policy
[07:43] <mdz> lastnode: at any rate, serpentine is a good example
[07:43] <lastnode> ok, thanks
[07:43] <mdz> lastnode: and to answer your question, no, packages should not place files in /usr/local at all
[07:43] <lastnode> gotcha
[08:45] <mdz> mvo: g-a-i still doesn't seem to sort by popularity by default
[08:47] <mdz> mvo: I think that for search results it should
[08:52] <mvo> mdz: it does a ranking that involves popularity but is not the only criteria
[08:52] <glatzor> mdz: hi, we use a more "complex" rating for the search. So that if the search term matches the pkg name the application will be on top
[08:52] <mdz> mvo: ah, interesting
[08:55] <mdz> mvo: gstreamer0.10-plugins-ugly has a low popularity rating; I wonder if our popcon statistics are useful
[08:55] <mdz> mvo: would you ensure that in the release notes, there is a section highlighting the knob to turn on popcon so that we get more participation?
[08:55] <mvo> mdz: yes, I can do this
[08:56] <mvo> mdz: we could pimp the raking for certain selected apps :)
[08:57] <mvo> e.g. mp3->gstreamer
[08:57] <seb128> mdz: re gdm hibernate, I've set an edgy milestone because I thought it maybe was the same fix as the upstream sleep one, but it's not. The sleep option is an upstream, hibernate is a distribution patch and it's lacking some part of code to work from the login screen apparently. How much do we care about having hibernate on the gdm screen? I was pondering dropping the patch since the session dialog use gnome-power-manager now anyway
[09:00] <seb128> mjg59: thank you for the nice gnome-session patch, that's better than yet another environment variable ;)
[09:02] <adam0509> hi, got an idea when edgy eft will be realeased ?
[09:03] <LaserJock> adam0509: wiki.ubuntu.com/EdgyReleaseSchedule
[09:04] <nixternal> have they even started developing Edgy Eft
[09:04] <seb128> nixternal: yeah, better :p
[09:04] <mdz> seb128: I don't think that hibernation from the login screen is an essential feature, but having sleep and not hibernate is weird
[09:05] <mdz> seb128: shouldn't it be possible to make them both work in almost exactly the same way?
[09:05] <nixternal> hehe
[09:05] <adam0509> 26 october ? exactly the day I wanted to reinstall my Ubuntu ;)
[09:06] <seb128> mdz: yeah, should not been too much work, maybe 1 hour to do the change, it has just been low on my TODO and I didn't come to do it yet, will do before edgy ;)
[09:08] <shawarma> I just noticed that<EMAIL_ADDRESS>is not working.. Should I file a bug or is this message sufficient? :-)
[09:08] <shawarma> "Recipient address rejected: User unknown in vir
[09:08] <shawarma> tual alias table (in reply to RCPT TO command)"
[09:46] <BenC> pitti: ping
[09:46] <BenC> hmm, no pitti
[09:50] <AlinuxOS> Kamion, ping
[09:55] <AlinuxOS> Kamion, Hello,so this (Gia Shervashidze's Georgian fonts http://img295.imageshack.us/my.php?image=screenshotxtermgiaqu5.png), may/could replace (this crappy: http://img83.imageshack.us/my.php?image=screenshotxterm1crappyma5.png) fonts in unifont, gfxboot and everywhere in Ubuntu where bitmap (console font) needed ?
[09:57] <AlinuxOS> Kamion, it will be great if we dissapear this (http://img83.imageshack.us/my.php?image=screenshotxterm1crappyma5.png) crappy/improportional font from Georgian range of glyps...Thank You!
[09:57] <mdke> AlinuxOS: email will get him, I would think
[09:58] <AlinuxOS> Ok I'll mail him ;)
[10:18] <AlinuxOS> mdke, maybe you need new Firefox's start page in Georgian (ka)?
[10:22] <mdke> AlinuxOS: I have no idea. I've been away for a month and don't know how the start page has been changed
[10:22] <AlinuxOS> mdke, ok don't worry...if there is something new...just let us know ;)
[10:22] <AlinuxOS> please ...
[10:24] <mdke> AlinuxOS: I won't have time. The best thing is if you keep an eye on it and check it is up to date
[10:24] <mdke> damn
[11:06] <sfllaw> mdz: Were we going to have a chat this week?
[11:08] <mdz> sfllaw: absolutely. how's now?
[11:10] <mdke> sfllaw: you pinged me a couple of times while I was on holiday: I'm off to bed now, but if I can still help, send me an email and I'll look tomorrow!
[11:24] <sfllaw> mdke: Sent.
[11:24] <sfllaw> mdz: Yes, I think that's fine.  +1-514-839-4887.
[11:26] <mdke> sfllaw: ah, that's fine. I'll reply in the morning
[11:27] <slomo> infinity: please give-back brasero on ppc, should be buildable now that new gtk is in the archive... thanks :)
[11:34] <tfheen> slomo,infinity: brasero given-back
[11:51] <tfheen> slomo: it still failed to build
[11:52] <slomo> tfheen: hrm... ok, let's wait an hour or something, i would've assumed that the gtk binaries are already in the archives for ppc too as they were there for amd64 already
[11:52] <tfheen> slomo: I'm off to bed, but if you ask me about it tomorrow, I'll give it back unless infinity beats me to it.
[11:54] <slomo> tfheen: ok, not so urgent anyway... good night :)


[11:01] <bilalakhtar> Hi there, people. I have installed the 4 launchpad-*-dependencies packages. I am not using rocketfuel. Do I have all the deps to build and run lp?
[11:15] <bilalakhtar> Hi there, people. I have installed the 4 launchpad-*-dependencies packages. I am not using rocketfuel. Do I have all the deps to build and run lp?
[11:35] <bilalakhtar> Hi there, people. I have installed the 4 launchpad-*-dependencies packages. Do I have all the packages required to build and run launchpad? Can I proceed to run rocketfuel? Will rocketfuel install any more packages? or it will just configure the sys?
[11:38] <bilalakhtar> beuno: Hi there! ^^
[12:13] <bilalakhtar> Hi there, people. I have installed the packages launchpad-*-dependencies in the lp ppa. Do I have all the deps and can proceed to download branch now?
[12:14] <bilalakhtar> Sorry, people, my connection was lost, so had to join and ask the question again
[13:46] <bilalakhtar> Hi there, people. I am having a dependency problem with launchpad. I want to run lp on my computer having a lamp stack already installed. Installing lp will remove PHP, since lp requires apache2-mpm-worker while PHP requires apache2-mpm-prefork. Both of these packages are conflicting. What should I do? Can lp run on prefork? I know PHP cannot run on worker. Please help
[14:00] <bilalakhtar> beuno: Please help ^^
[14:00] <bilalakhtar> wgrant: please ^^
[14:00] <adiroiban> bilalakhtar: try to install LP into a virtual machine
[14:01] <bilalakhtar> adiroiban: just a minute, seeing how to do that
[14:03] <bilalakhtar> adiroiban: You mean a chroot?
[14:03] <adiroiban> bilalakhtar: chroot or a kvm
[14:05] <bilalakhtar> adiroiban: ok, thanks for the info, will do it in a chroot
[14:19] <bilalakhtar> Hi there, people. I am trying to run lp in a chroot. I have apache already running in host along with php and mysql. Do I need to stop apache in host before starting the one in chroot?
[14:39] <adiroiban> bilalakhtar: if they are not running on the same IP:PORT you can have them both
[14:40] <bilalakhtar> adiroiban: Bot of them will run on the same port by default. I will modify the host one to run on post 8080. Thanks for into
[14:40] <bilalakhtar> *info
[18:25] <james_w> lifeless, jml: plane hacking: https://edge.launchpad.net/soupmatchers
[18:26] <jml> james_w, ooh. /me looks
[18:26]  * jml is releasing Twisted today
[18:26] <james_w> yay!
[18:26] <james_w> thanks
[18:26] <james_w> there's a README in the branch that will explain
[18:27]  * james_w -> dinner
[20:38] <krkhan> is there a place with information about lp layers which are run during testing? i can't figure out which layer does what or which layers do i need for my tests
[20:39] <jml> krkhan, not really. your best bet is to copy another test that does something similar, or look at lib/canonical/testing/layers.py
[20:58] <krkhan> jml: thanks
[21:15] <lifeless> james_w: nice, I shall look more when I get back from the real estate agents
[23:38] <wgrant> spm: When you appear, can you please kick the i386 buildds back into life?
[23:38] <wgrant> Most of them died yesterday for no particularly good reason.


[20:26] <ogra_> stgraber, depends if grouper actually powers off on reboot, kmsg/last_kmsg should persist as long as the ram is powered , but probably the grouper kernel misses the ram console option or some such
[20:26] <anders3408> stgraber:  just a sec :)
[20:26] <tedg> mhall119, Is there someone I can get to ack that they're okay with this URL format from calendar app?  bug 1231136
[20:27] <anders3408> stgraber: http://paste.ubuntu.com/6156029/
[20:27] <lool> stgraber: ok thanks
[20:27] <anders3408> there you have from 1st bootup and 2.nd bootup
[20:27] <tedg> lool, So I'm having second thoughts on using the full triplet for the object path.
[20:28] <tedg> lool, The reason being that if you have something like GEdit, and you wanted to make a click package, even thought it is "org.gnome" the app wouldn't do that.
[20:28] <tedg> lool, But it would be wired to use application name already.
[20:28] <stgraber> anders3408: can you try "mount /dev/mmcblk0p19 /mnt" outside the container?
[20:29] <stgraber> anders3408: to check whether the partition is still mountable at all
[20:29] <anders3408> stgraber:  mount: /dev/mmcblk0p19 already mounted or /mnt busy  mount: according to mtab, /dev/mmcblk0p19 is mounted on /system
[20:31] <mhall119> tedg: kunal is usually the one to go to for calendar, but I know he has some help now
[20:31] <mhall119> popey: who's working on calendar these days?
[20:31] <lool> tedg: we could patch it to support both
[20:32] <tedg> lool, ?  How?  Send two messages?
[20:32] <lool> tedg: doesn't fdo encourage all apps to move to namespace + app name anyway?
[20:32] <dobey> jono: for bug #1226183, does "not displayed" mean that "More Suggestions" shows up, but is empty?
[20:32] <lool> tedg: have two objects?
[20:32] <stgraber> anders3408: so what happens if you umount /system and then start the container?
[20:32] <lool> tedg: also, imagine a desktop with gedit.deb installed a gedit.click, what happens when you want to tell gedit to open an url?
[20:33] <lool> s/a/and/
[20:33] <tedg> lool, Kinda, I mean, the namespace/app might not align.  They're encouraging the desktop file name to match that.  But we're using that as the app name.
[20:33] <tedg> lool, So is an app id it could end up as: org.gnome_org.gnome.gedit_123
[20:33] <lool> tedg: 123?
[20:33] <tedg> lool, version
[20:33] <anders3408> stgraber:  just tried and outcommited /system in /etc/fstab , and then the container started, but still some issues like E/linker  ( 1927): linker.c:1095| ERROR: Library '/system/lib/libubuntu_application_api.so' not found so it ends up rebooting after some time
[20:33] <slangasek> barry: are the failing s-i dbus api tests bugs in system-image?  in u-d-m?  We're kind of at the end of our rope here
[20:34] <lool> tedg: I didn't want the version in there, sorry should have been clearer in the mp
[20:34] <lool> tedg: and I thought _ would be split away
[20:34] <tedg> lool, So you're just thinking /pkg/app ?
[20:34] <lool> tedg: /parts/of/the/name/space/AppName
[20:34] <stgraber> anders3408: right, so you're basically in a race between Ubuntu and Android mounting /system with the first boot case changing the timing enough to make it boot
[20:35] <lool> com/ubuntu/stock-ticker-mobile
[20:35] <lool> com/ubuntu/dropping-letters
[20:35] <jono> dobey, yes, I think so
[20:35] <jono> dobey, although I think some times it didn't show the section
[20:35] <anders3408> yes that sounds correct :) stgraber
[20:35] <lool> tedg: there are other conflicts between the two anyway, like lower case vs. mixed case
[20:35] <lool> Gedit vs. gedit
[20:35] <tedg> lool, Perhaps we can just check to see if the pkg is the first part of the app, and ignore in that case.  So if org.gnome is there twice, we don't put it there twice.
[20:35] <stgraber> anders3408: that was one of my concerns with the flipped model which I addressed in the system images by having Ubuntu always mount everything in /android and then have lxc bind-mount those into the container (and disabling android's mount management code)
[20:36] <mfisch> ssweeny: https://bugs.launchpad.net/touch-preview-images/+bug/1231140
[20:36] <lool> tedg: I dont understand the thing coming in twice
[20:36] <tedg> lool, True, and that's what is nice about just matching the desktop file.  It's known by everyone clearly.
[20:36] <tedg> lool, Case and all.
[20:36] <tedg> lool, If we do /pkg/app then app could have a namespace in it.
[20:36] <stgraber> anders3408: so the good news is that your device will likely just work once there's documentation for how to setup a ports system-image server, the bad news is that this probably won't happen for another couple of weeks, so until then your best hope is to add a bunch of sleeps at random places and see if that helps...
[20:36] <anders3408> stgraber:  ugh.... so i cant do anything about it :(
[20:37] <tedg> lool, pkg = "org.gnome" ; app = "org.gnome.gedit"
[20:37] <dobey> jono: ok, thanks.
[20:37] <lool> tedg: I dont get it, if we take sudoku out of com.ubuntu.sudoku_sudoku_0.4.3.desktop it's not distinguishable from sudo from net.launchpad.sudoku_sudoku_0.4.3.desktop
[20:37] <lool> tedg: why would we ever get pkg = "org.gnome" ; app = "org.gnome.gedit"
[20:38] <tedg> lool, That's not an issue, we don't care if they export the same object name.
[20:38] <stgraber> anders3408: maybe ogra_ can comment on what exactly is the done on first boot which isn't on subsequent ones which may help you figure out where to add a delay
[20:38] <anders3408> stgraber:  where should i add some sleeps ? right now it looks like if i can get android to mount /system first then ubuntu mounting /system after that , looks like a win win, just like it does on first bootup :)
[20:38] <lool> concretely with "legacy" / .deb we have non-namespaced names, and they might be namespaced, and with click we have namedspaced
[20:38] <lool> tedg: it's an issue because we're matching the name
[20:38] <tedg> lool, Because FD.o is encouraging apps to change their desktop files to include namespace.  So it'd be "org.gnome.gedit.desktop"
[20:38] <tedg> lool, We're not matching the name.
[20:38] <lool> tedg: so that's fine, and then it will be org/gnome/gedit
[20:38] <tedg> lool, We're just sending a message to that object on the bus.
[20:39] <lool> I fail to see the difference
[20:39] <lool> we're going to send the message to all sudokus on the bus
[20:39] <tedg> If two apps both export /sudoku and /sudoku it doesn't matter.
[20:39] <tedg> No, we're not.
[20:39] <lool> well there's just the pid check
[20:39] <tedg> "just" ?
[20:39] <tedg> We're sending it to only a single unique name.
[20:39] <lool> tedg: I don't find "sudoku" unique enough
[20:40] <tedg> There's no chance that it'll get to more than one connection there.
[20:40] <lool> well you're saying we're stopping at the first one
[20:40] <lool> it might still be the wrong one  :-)
[20:40] <tedg> I don't see anyway it could be the wrong one.
[20:40] <lool> tedg: also, you want to implement a non-namespaced object path when FDO pushes for namespaced object path?
[20:41] <tedg> It pushes for it to match the name of the desktop file.  And for the desktop file to be namespaced.
[20:41] <tedg> The result is a namespaced path, but they're independent.
[20:41] <lool> yes, and so we happen to have namespaces
[20:41] <anders3408> ogra_: do you have some ideas on what stgraber said ? :)
[20:42] <lool> and you don't want to use them  :-)
[20:42] <tedg> Because I want to use the desktop file name.
[20:42] <tedg> Which could or could not be namespaced.
[20:42] <lool> the desktop file name is com.ubuntu.sudoku_sudoku_0.4.3.desktop and is namespaced!  :-)
[20:43] <lool> tedg: I think we should use the app_id/desktop filename but strip the version and transform not only . but also _ in /
[20:44] <lool> it guarantees uniqueness, and it matches the way we identify the application on the system
[20:44] <tedg> I think if we're going to do that we should use the DBus name
[20:44] <lool> but I can pull in an independent expert, my wife, and convince here to vote for my option
[20:45] <lool> *her
[20:45] <tedg> We've got the name that we're getting from nih_dbus_path() elsewhere.
[20:45] <tedg> (hud, etc.)
[20:45] <tedg> And just do /$(DBUS_NAME)
[20:45] <mhall119> anders3408: tracking number should be in your inbox
[20:45] <mhall119> anders3408: once again, fantastic work you did on the port
[20:45] <anders3408> mhall119:  nice :D
[20:46] <anders3408> thanks  mhall119 :)
[20:46] <mhall119> I know many Find 5 owners will be looking forward to continued improvements to it to :)
[20:47] <lool> tedg: ok, I'm happy to check how this looks like, but it will have to be tomorrow
[20:47] <anders3408> stgraber:  what if i add noauto,users, to the fstab file, where it mounts system, then in lxc-android-config.conf after it has run lxc-start, let it mount /system ?
[20:47] <lool> tedg: the other thing we could think about is whether it's something we can easily change or not
[20:47] <lool> if it's only done in qtubuntu, then certainly, but if individual apps do it, it's bad
[20:47] <lool> gtg
[20:47] <lool> super tired
[20:48] <tedg> Non-SDK apps would do it themselves.
[20:48] <tedg> But SDK apps would just be using QtUbuntu.
[20:48] <rsalveti> jdstrand: guess you forgot to attach the example qml/profile files at bug 1226844
[20:48] <tedg> It'd be nice if we could keep GApplication working.
[20:48] <rsalveti> you did attach the click package, but I'd prefer using the qml one to reproduce the issue
[20:48] <jdstrand> rsalveti: I did, but later attached a click package with instructions
[20:49] <rsalveti> right, let me give the click a try then
[20:49] <jdstrand> rsalveti: see comment #2
[20:49] <lool> fginther: not sure you saw https://code.launchpad.net/~stgraber/mtp/upstart-fixes/+merge/187587 failed upstream merging due to bazaar connection issue?
[20:50] <tedg> lool, So I'll use nih_dbus_path() for now and we'll go from there?
[20:50] <rsalveti> jdstrand: as we connect to 3g with nm anyway, I believe we just need to fix the ofono related error
[20:50] <jdstrand> cool
[20:52] <lool> tedg: I'll read on that tomorrow; write me some pointers to it and I'll check it out tomorrow
[20:52] <lool> updating last things I had to do before bed and going off
[20:53] <tedg> 'night lool
[20:54] <tedg> mhall119, popey, so I'm happy to take other options as a URL format there, we just need something that we can start coding to on the other sides.
[20:55] <tedg> mhall119, popey, It seems relatively arbitrary as I couldn't find any other prior art.
[20:55] <mhall119> tedg: what is the url meant to do?
[20:55] <tedg> mhall119, Click on an appointment in datetime and open the calendar to the right view.
[20:57] <anders3408> stgraber:  ^
[21:00] <kgunn> ricmm: just getting ducks in a row to land kdub's flicker fix, need to bump so name again
[21:00] <kgunn> ricmm: https://code.launchpad.net/~kgunn72/platform-api/bump-mir-dep12/+merge/187603
[21:00] <mhall119> tedg: http://iphonedevwiki.net/index.php/NSURL has calshow:// for urls to specific events already in the calendar
[21:00] <mhall119> though it's not public
[21:00] <kgunn> ricmm: didrocks said these build dep bumps should be top approved first before mir...altho, i suppose they need to be done in quick succession
[21:01] <ricmm> kgunn: I'll approve it now, if thats ok
[21:01] <kgunn> ricmm: i won't top approve until we've got mir on trunk ready w/ a bump
[21:01] <kgunn> cool
[21:02] <ricmm> kgunn: let didier do the top approving, as he usually does the succession
[21:02] <kgunn> ricmm: thanks (i'll quote you :)
[21:02] <fginther> lool, no, I did not see the https://code.launchpad.net/~stgraber/mtp/upstart-fixes/+merge/187587 failure, will restart
[21:03] <lool> stgraber: 6
[21:03] <lool> stgraber: ^
[21:06] <tedg> mhall119, Yeah, but that was private and seems it was deprecated in iOS5
[21:07] <mhall119> ok
[21:07] <tedg> mhall119, So, no "useful prior art" :-)
[21:07] <mhall119> tedg: something that points to a specific event would be better, I think, than just pointing to a time
[21:07] <tedg> mhall119, Why?  Is there an event view?
[21:07] <mhall119> tedg: I was close, it was "prior useful art" :)
[21:07] <mhall119> tedg: there is, yes
[21:08] <mhall119> and a better one being worked on currently as well
[21:09] <tedg> charles, Is there an event ID we could use? ^
[21:09] <tedg> Something from EDS that is unique
[21:11] <charles> tedg, yes, see e_cal_component_gen_uid()
[21:11] <charles> that's the unique ID that the calendar uses
[21:12] <tedg> charles, Would it make sense to do a "calendar:///?eventId=$(foo)" ?
[21:12] <tedg> It'd be nice for calendar (on desktop) to be able to click on a day.
[21:13] <tedg> But it seems for events that'd imply the start/end time.
[21:13] <charles> ted, right. in addition to startdate and enddate, calendar takes a handful of other arguments
[21:13] <charles> source-uid, comp-uid, comp-rid
[21:14] <tedg> charles, K, that works for me.
[21:15] <tedg> charles, Add the useful ones to the bug?
[21:15] <charles> tedg, sure
[21:15] <charles> looking through the code right now to make sure one doesn't require the other two
[21:19] <tedg> charles, Think you forgot to bzr add the vapi for the indicator-sound branch.
[21:19] <charles> teg, right you are
[21:20] <charles> ...chasing the comp-uid, comp-rid handler from evolution to libecal, where it's turning into a dbus call, still digging :)
[21:21] <jono> bfiller, hey, any idea who is working  on the gmail web app?
[21:22] <jono> noticed a bug where links are not loaded in the external browser
[21:22] <bfiller> jono: the gmail webapp would be alex-abreu, I'm working on getting a good user-agent string so it renders nicely
[21:23] <jono> thanks bfiller
[21:23] <jono> bfiller, any idea where the gmail web app lives on LP?
[21:23] <jono> so I can file a bug
[21:24] <bfiller> jono: good question, just file it under browser for now and I'll make sure it gets to the right person
[21:24] <jono> thanks bfiller
[21:30] <jono> bfiller, https://bugs.launchpad.net/webbrowser-app/+bug/1231156
[21:31] <bfiller> jono: thanks
[21:31] <stgraber> fginther, lool: failed again: https://code.launchpad.net/~stgraber/mtp/upstart-fixes/+merge/187587
[21:32] <stgraber> meant, https://jenkins.qa.ubuntu.com/job/mtp-saucy-i386-autolanding/5/console
[21:32] <stgraber> in the middle of the auto-landing this time...
[21:37] <fginther> stgraber, argh! These network failures will be the death of me. Will retry for now (an attempt at a fix is in the works)
[21:45] <popey> jono: how many contacts do you have on your phone?
[21:47] <jono> popey, about 88
[21:47] <popey> ok go to them and scroll to the bottom
[21:47] <popey> time it
[21:49] <popey> on iphone it takes ~7 swipes to get from A to Z, on Touch it takes 7 swipes to get from A-G
[21:50]  * popey discovers you can tap the letter to do it quicker
[21:57] <cwayne> mterry: so is the u-touch-session in the landing plan?
[21:58] <mterry> cwayne, oh, I guess I should re-do it.  It is a twice-graduate, I figured it was still on the radar
[21:58] <ogra_> cwayne, lightdm is stuck in proposed until the beta freeze gets lifted
[21:59] <ogra_> earliest is tomorrow evening i guess
[21:59] <rsalveti> jdstrand: did you test your example click app after disabling ofono?
[21:59] <mterry> cwayne, looks like it got updated yeah.  thanks ogra_(?)
[21:59] <rsalveti> even after I disable ofono, it still gives me status unknown
[22:00] <jdstrand> rsalveti: I tested on grouper vs mako
[22:00] <mterry> cwayne, I still could use confirmation that it fixes the daily tests.  If you have free testing time...
[22:00] <jdstrand> rsalveti: you want me to disable ofono on mako now?
[22:00] <ogra_> mterry, yeah, i keep an eye on this one
[22:00] <rsalveti> jdstrand: please, just stop ofono and give it a try
[22:01] <rsalveti> argh, something might be wrong locally, even the qml directly failed now
[22:02] <cwayne> mterry: how can i help?  i've never really touched/seen the daily tests
[22:02] <cwayne> but i've got devices, am happy to help get stuff in :)
[22:05] <rsalveti> hm, stopped ofono, restarted nm, and still showing status unknown even when opening the qml file directly
[22:05] <jdstrand> rsalveti: I stopped ofono and now it gave an error
[22:05] <jdstrand> (both confined and unconfined)
[22:06] <mterry> cwayne, ogra_ tells me you have to use phablet-test-run
[22:06] <jdstrand> I noticed telepathy-ofono was running, so killed it too, no difference
[22:06] <mterry> cwayne, but I don't know the details
[22:06] <mterry> cwayne, this is to reproduce the same tests that the daily image tests do
[22:06] <rsalveti> yeah, we might have another bug around as well
[22:07] <jdstrand> rsalveti: restarted network-manager, same thing
[22:07] <rsalveti> jdstrand: works fine if you start ofono again, unconfined at least
[22:08] <rsalveti> I forced isOfonoAvailable to return false, and also gives me that error
[22:08] <jdstrand> rsalveti: yeah, I can confirm that (unconfined)
[22:08] <rsalveti> thanks for confirming it, will investigate a bit further
[22:10] <jdstrand> rsalveti: thanks. I tried uninstalled libofono-qt1 too, but that didn't help
[22:10] <jdstrand> uninstalling*
[22:24] <loicm> tedg: hey, gonna link to nih-dbus and use nih_dbus_path() too to get the object path