[00:07] <LaserJock> well, bryce's package nicely fixes the problem by dumping me into vesa :-)
[00:07] <LaserJock> I'm guessing that's not the intended fix
[00:08] <jdong> LaserJock: is performance better? :D
[00:08] <LaserJock> well, if I could get a better screen resolution I'd just stick with it
[00:09] <LaserJock> but it sorta looks not-so-great
[00:09] <jdong> ah yeah, how many people put nonstandard resolutions in their VESA modes anyway.
[00:10] <jdong> I remember having this problem with my ATI card back when there were no drivers (more or less)
[00:11] <tclineks> is there anyone working on a 9.04 jeos image?
[00:15] <jdong> hmm it doesn't seem like vmmouse probing works in Jaunty anymore for vmware mouse acceleration... :(
[00:16] <cody-somerville> mouse acceleration?
[00:16] <jdong> yeah, the VMWare absolute position mouse driver
[00:16] <jdong> for seamless host/guest mousing.
[00:16] <jdong> there's some sort of HAL callout used to load the vmmouse input driver
[00:17] <jdong> but in Jaunty only evdev/HID emulation is being used
[00:17] <jdong> (Intrepid and below did it correctly)
[00:17] <TheMuso> slangasek: what are we doing in relation to release freeze and GNOME 2.26.1 updates? There are a few a11y related GNOME 2.26.1 package updates available.
[00:20] <tclineks> http://cdimage.ubuntu.com/jeos/releases/jaunty/ =(
[00:20] <cjwatson> tclineks: the separate jeos image was retired in favour of just being an option in the Ubuntu server installer
[00:20] <tclineks> oh really
[00:20] <tclineks> available in alternate installer?
[00:21] <tclineks> too bad as small iso footprint can be kind of nice, but ah well
[00:21] <cjwatson> no, just server
[00:21] <cjwatson> I'm sure you could do it with the netboot mini.iso ...
[00:21] <tclineks> crap
[00:21] <tclineks> 60% done with alternate iso
[00:21] <tclineks> ok
[00:21] <tclineks> thanks
[00:22] <calc> tclineks: you can rsync that afterwards to server
[00:22] <cjwatson> or jigdo
[00:22] <calc> tclineks: probably would download less than a whole cd
[00:22] <calc> tclineks: or what cjwatson just said :)
[00:22] <tclineks> calc: alternate?
[00:22] <tclineks> haven't dealt with jigdo
[00:22] <calc> tclineks: yea you can rsync between different cd's or use jigdo to rebuild them
[00:23] <calc> tclineks: you just need to rename it to the new name or however you want to do it
[00:23] <tclineks> hm
[00:23] <cjwatson> you should be able to boot the netboot mini.iso with the following arguments to achieve pretty much the same effect as jigdo:
[00:23] <cjwatson> err, as jeos:
[00:23] <cjwatson> tasksel/skip-tasks=standard pkgsel/language-pack-patterns= pkgsel/install-language-support=false clock-setup/utc-auto=true
[00:24] <tclineks> nice
[00:24] <cjwatson> actually, you might want to install the virtual kernel as well
[00:24] <cjwatson> so add: base-installer/kernel/override-image=linux-virtual
[00:25] <tclineks> i'll give that a go
[00:26] <slangasek> TheMuso: I've given seb128 the green light for 2.26.1 updates, pre-RC; what updates do you have, maybe they're already on seb128's list?
[00:30] <TheMuso> slangasek: gnome-orca and gnome-mag, which I am responsible for updating. Accerciser, which is universe.
[00:30] <superm1> jdong, this is something i'm always getting on BIOS developer's cases about, if the mode is in the EDID, it should be in the VBIOS
[00:30] <slangasek> TheMuso: will you be able to upload those today?
[00:30] <slangasek> superm1: so, how's mythbuntu+mesa looking?
[00:30] <TheMuso> slangasek: indeed.
[00:31] <jdong> superm1: haha fat chance they'll listen
[00:31] <jdong> superm1: not unlike fricking Apple with their ATA PIIX mode controllers in BIOS emulation mode
[00:32] <tclineks> don't quite have the knowledge to do the mini.iso deal, just grabbing the full server iso
[00:32] <tclineks> thanks for you rinput
[00:32] <tclineks> your*
[00:32] <cjwatson> np
[00:33] <oobe> I installed juanty beta and was wondering when the release becomes final in a few days will i have to do a full dist upgrade or will i be prompted with updates as per usual as in a normal apt-get upgrade should suffice?
[00:35] <cjwatson> oobe: You should read the documentation for what dist-upgrade vs. upgrade mean, and you should generally use dist-upgrade through development releases. However, System -> Applications -> Update Manager (or the automatic notification) is not equivalent to 'apt-get upgrade', and should work fine.
[00:36] <cjwatson> (I mean System -> Administration -> Update Manager, obviously ...)
[00:37] <oobe> i use kubuntu so im not used to those paths
[00:37] <oobe> plus i usually do everything with apt
[00:38] <cjwatson> if you're using apt-get directly, then use apt-get dist-upgrade
[00:38] <oobe> ok
[00:38] <oobe> thanks
[00:38] <jdong> see the manpage on apt-get for the difference between the two
[00:38] <jdong> (more or less the only time it matters is when apt-get reports held back packages)
[00:39] <slangasek> calc: hunspell-vi, hunspell-hu still Conflict: myspell-da?
[00:41] <directhex> oobe, incredibly short version: dist-upgrade will add/remove packages to reflect changed deps, upgrade will hold packages that would require adding.removing things
[00:43] <calc> slangasek: yea, hmm let me see if i can see why
[00:43] <oobe> directhex, thanks as cjwatson mentioned i really should read more docs on apt and dpkg but what you just said makes it very clear
[00:43] <slangasek> calc: not a regression, I think it's a pre-existing packaging bug; accepted already
[00:44] <calc> slangasek: ok thanks
[00:45] <calc> slangasek: also working on a ooo update atm but still beating on it to make sure its working right
[00:46] <slangasek> calc: why is that needed
[00:46] <slangasek> ?
[00:46] <calc> i managed to cause it to drop the jre dependency from ooo-java-common when i dropped the saxon package
[00:46] <slangasek> ugh
[00:46] <slangasek> can you upload now, and beat on it in parallel?
[00:46] <calc> i fixed it up and built it and noticed the variable wasn't being substituted so fixed it up again and i think it will work correctly now
[00:46] <calc> yea i can upload it now as i think it should work now
[00:47] <slangasek> OOo needs to be in the build queue *ASAP* to avoid delaying CD builds
[00:47] <calc> yes, it takes 36hr to build on armel :\
[00:47] <calc> i just got a bug report today that made it clear what the issue still existed
[00:48] <calc> so been working on it for a while when i saw it wasn't quite fixed yet, should be fine now though so i will upload it should be done uploading in ~ 1hr
[00:49] <superm1> slangasek, 7.4 breaks vesa for us, i'm testing it with -nv later tonight
[00:50] <superm1> slangasek, i've tried to bisect the tree, and i at least found when it started breaking, but it's not a matter of just revert this one commit and you're fixed
[00:50] <slangasek> erk, breaks vesa?  that's not even the same bug I was thinking of, is it?
[00:50] <superm1> no, the one you are thinking of is breaking -ati, and that exists on 7.3 too
[00:50] <slangasek> bryce: followed up to your -intel call for testing; dunno if it needs moderation to reach ubuntu-x
[00:51] <superm1> so it's two ugly bugs
[00:51] <slangasek> superm1: :/
[00:53] <calc> slangasek: started upload, should take somewhere between 30-45m i think
[00:55] <slangasek> ack, thanks
[01:32]  * jdong out of desperation foreports pulseaudio intrepid->jaunty.
[01:32] <jdong> optimistically trying to bisect the flash/skype regressions.
[01:34] <wgrant> jdong: What Flash regressions?
[01:34] <jdong> wgrant: A-V loses sync on things like hulu or youtube, randomly.
[01:35] <jdong> audio continues at normal speeds but video seems to just completely stop.
[01:35] <wgrant> I've not seen that.
[01:35] <jdong> might be an X/xv related problem though.
[01:35] <jdong> just trying to whittle down the list of suspects
[01:37] <dtchen> you need a crackton of fixes in the audio stack
[01:37] <superm1> slangasek, if we wanted to block notification-daemon from getting installed in mythbuntu but just notify-osd, how would we (effectively) do that?  pitti did an upload the other day that stopped notify-osd from getting spawned on !gnome for kubuntu users, but we'd still like to use it on mythbuntu.  removing notification-daemon appears to be the most effective way of (easily) doing that
[01:38] <dtchen> jdong: you need newer linux, alsa-lib, alsa-plugins, pulseaudio
[01:38] <tclineks> oh maybe i will do the mini.iso after all, found some docs
[01:38] <tclineks> it'd be nice to have some common recipies
[01:39] <slangasek> superm1: I think I've gotten lost in the negatives in that question.  What is it you want installed?
[01:39] <calc> slangasek: done uploading
[01:39] <superm1> slangasek, haha.  we have notification-daemon and notify-osd installed side by side right now.  we notify-osd to be used, but to have it be used notification-daemon has to not be present it appears
[01:39] <slangasek> calc: ta
[01:39] <jdong> dtchen: ah, how new?
[01:40] <superm1> i think it gets pulled in from earlier dependency resolution by things alphabetically before mythbuntu-desktop, like gnome-power-manager
[01:40] <slangasek> superm1: so you want to keep notification-daemon from *ever* being installed on mythbuntu?
[01:40] <jdong> dtchen: I noticed also annoyingly that skype ain't API-compatible with newer alsa-lib either. Groan stupid proprietary stuff.
[01:40] <slangasek> superm1: or you just want to make sure only notify-osd is pulled in automatically?
[01:40] <superm1> slangasek, no, just not by default
[01:40] <slangasek> ok
[01:40] <superm1> notify-osd is currently there (recommends on mythbuntu-desktop i believe)
[01:40] <dtchen> jdong: at least what we have in current jaunty. you'll likely need to pull my linux tree and pulseaudio bzr branch, too.
[01:41] <dtchen> jdong: that should be sufficient for Intel HDA but may be insufficient for Intel8x0 AC'97
[01:42] <slangasek> superm1: I wonder if seeding notify-osd at the top of the seed would make a difference?
[01:42] <jdong> dtchen: would you have any hints as to why skype's audio playback would cause 80% of one core to be in system time? strace wasn't very helpful; seems to mostly be select() time
[01:43] <jdong> (it didn't happen in Intrepid)
[01:43] <superm1> slangasek, well is it the seed resolution or normal dependency resolution that does it I wonder?
[01:43] <slangasek> superm1: if not, then the only other thought I have is to change gnome-power-manager to depend on notify-osd | notification-daemon, and try to sort the knock-on effects
[01:43] <dtchen> jdong: welcome to mainloop hell.
[01:44] <dtchen> jdong: (known issue, the ARM guys are hateful about it, too)
[01:44] <superm1> slangasek, i think there are some other apps that do it too though, so that would be a handful of apps just for this change
[01:44] <jdong> dtchen: interesting; any literature you have on it off the top of your head?
[01:44] <superm1> slangasek, i'll try moving it to the top of the seed and see how tomorrow's daily works out with that change
[01:44] <slangasek> superm1: well, it shows up in the seed; http://people.ubuntu.com/~ubuntu-archive/germinate-output/mythbuntu.jaunty/all
[01:44] <slangasek> we ought to see improvement in the seed after the next publisher run, if it's going to take
[01:44] <dtchen> jdong: i don't know aside from pulseaudio chat.
[01:45] <slangasek> currently, it's libnotify1 that pulls it in
[01:45] <slangasek> (according to the seed)
[01:45] <superm1> ooh very cool output.
[01:46] <jdong> dtchen: would you suspect adobe flash AV desync to be video stack related or pulse related?
[01:46] <dtchen> jdong: both
[01:47] <jdong> dtchen: and I suppose it's also known that glitchfree seems to universally glitch more, huh?
[01:48] <dtchen> jdong: on which kernel and using which pulseaudio?
[01:48] <jdong> dtchen: jaunty stock on both counts
[01:49] <dtchen> jdong: then you don't have the necessary base fixes to linux.
[01:49] <dtchen> jdong: (they'll be SRUd from my conversation with rtg)
[01:49] <superm1> slangasek, okay well i've committed that change.  when is the next publisher run for me to take a look at the output then?
[01:49] <jdong> dtchen: ah. Would that have any impact on the mainloop behavior in your opinion?
[01:50] <dtchen> jdong: the glitch-free portion isn't mainloop-related; that's pcm_lib and mid-layer (both linux)
[01:50] <slangasek> superm1: once an hour at 3 after the hour, so you should see the difference in about 1:10 or so
[01:50] <dtchen> jdong: i.e., http://kernel.ubuntu.com/~dtchen/README.asc
[01:50] <superm1> slangasek, okay cool thanks, i'll check back after dinner then
[01:51] <jdong> dtchen: mmmph. Perhaps I should just wait on Intrepid a bit longer for the dust to settle. Thanks for your infinite knowledgebase as always :)
[01:59] <mrooney> bryce: happen to know if bug 312319 is a dupe of anything?
[02:21] <bddebian> lamont: You around by chance? (about xdelta)
[02:25] <superm1> slangasek, here's an overview of the last high/critical bugs I know about after testing on -ati, -vesa, and -nvidia for mythbuntu: http://tinyurl.com/mythbuntu-bugs . there are some smaller ones left too, but i'm not getting to them until i make more progress on mesa stuff
[02:32] <slangasek> superm1: thanks, I'll have a look through those later
[02:32] <slangasek> TheMuso: the gnome-orca diff includes this change; does this wind up in the binary package?:
[02:33] <slangasek> -localedir = os.path.join ("/usr", "share", "locale")
[02:33] <slangasek> +localedir = os.path.join ("/export/home/wwalker/work/orca/branches/gnome-2-26/bld", "share", "locale")
[02:33]  * TheMuso checks
[02:36] <TheMuso> slangasek: appears it doesn't
[02:36] <calc> slangasek: did OOo get processed yet? i haven't seen an email yet
[03:04] <bryce> mrooney: check launchpad
[03:13] <LaserJock> bryce: yo, you get my comments on bug #359600?
[03:14] <bryce> LaserJock: yeah been looking at this
[03:30] <ScottK> bryce: For me greedy was the difference between I can't possibly live with this, what will I install instead and hmm, not too bad.
[03:33] <bryce> ScottK, no one reports bugs against X that go, "I can live with this, but..."
[03:33] <bryce> ;-)
[03:34] <ScottK> bryce: Between Intel video and some unrelated stuff I'm not thrilled about, I have a Debian ISO on my hard drive that I've decided to hold off on installing for a bit now.
[03:35] <bryce> making threats is not very constructive
[03:36] <ScottK> bryce: I'm not intending a threat.  Just trying to express how bad I thought it was before and how much better it is now.
[03:37] <bryce> ScottK, sounds like you're making an ultimatum - "Make the change I want or I quit"
[03:37] <ScottK> bryce: I doubt greedy is suitable for a default, be needs to be one of the options we give people (I don't envy anyone having to write the release note for this).
[03:38] <ScottK> bryce: Not at all.  I changed it myself and my situation is OKish now.
[03:42] <slangasek> calc: notchet
[03:42] <slangasek> TheMuso: ack, thanks
[03:43] <calc> ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) <- should that actually work?
[03:43] <calc> it seems not to even though its in debian policy documented that way
[03:46] <calc> erg i see what is wrong
[03:47] <calc> its supposed to be whitespace delimited not comma delimited
[03:47] <mathiaz> slangasek: what's your opinion on bug https://bugs.launchpad.net/landscape/+bug/360510?
[03:47] <mathiaz> slangasek: should this go in the release or in jaunty-updates?
[03:48] <slangasek> mathiaz: what's the impact of the bug?
[03:48]  * slangasek doesn't know what landscape-broker is
[03:49] <slangasek> calc: how did your local testing turn out? should I go ahead and accept the OOo upload now?
[03:49] <mathiaz> slangasek: it's one component of  landscape
[03:49] <slangasek> that doesn't tell me anything I couldn't infer from the name :)
[03:50] <mathiaz> slangasek: yeah - let me look into this a bit more.
[03:53] <mathiaz> slangasek: the impact is outline in https://bugs.launchpad.net/landscape/+bug/360510/comments/5
[03:53] <mathiaz> slangasek: if the broker crashes, landscape-client doesn't work.
[03:53] <mathiaz> slangasek: the system won'
[03:54] <mathiaz> slangasek: the system won't be manageable by landscape anymore.
[03:55] <mathiaz> slangasek: so a system couldn't get its updates since landscape cannot send the package update request.
[03:55] <radix> hi, I'm around to discuss it
[03:55] <radix> but yes, what mathiaz is saying is true
[03:56] <mathiaz> radix: ^^ is that a possibility (ie an upgrade to jaunty would block the system from upgrading anymore)?
[03:56] <mathiaz> radix: *updating*
[03:56] <radix> yes, at least updating through landscape
[03:57] <mathiaz> radix: isn't that the case for most of systems managed by landscape?
[03:58] <mathiaz> radix: ie are you supposed to use apt-get to manage packages on a landscape managed system?
[03:58] <radix> right, the biggest point of using landscape is its centralized package management
[03:58] <radix> I mean, rather, that that's its biggest feature
[03:59] <radix> so it's pretty serious, as far as users of landscape and landscape itself goes
[04:02] <slangasek> mathiaz, radix: if you can get the fix uploaded in the next few hours so it lands before RC, I'll take it
[04:03] <radix> it's completely ready, as far as the packaging branch goes...
[04:03] <mathiaz> slangasek: ok - I'll upload a new package today.
[04:03] <slangasek> thanks
[04:03] <radix> slangasek, mathiaz: thank you both again
[04:03] <slangasek> calc: OOo accepted now; if there was anything broken in it per your testing, please bump the version when you upload
[04:03] <radix> I am going to have to bake about fifteen cakes for you guys to regain my karma, I think
[04:04] <slangasek> whooo cake
[04:04] <radix> :-)
[04:04] <mathiaz> radix: well I prefer thai food than cakes FWIW
[04:05] <radix> mathiaz: noted ;-)
[04:05] <slangasek> ooh thai cake
[04:05] <radix> hah
[04:05] <slangasek> wait
[04:16] <lamont> bddebian: actually just running off for the evening
[04:16] <lamont> will be back in about 7 hours or so
[04:21] <bddebian> lamont: NP, thx
[04:25] <mathiaz> slangasek: I've got a landscape-client package ready to be uploaded. Should I go ahead?
[04:31] <slangasek> mathiaz: yes
[04:33] <calc> slangasek: sorry it seemed to be fine
[06:04] <geofft> if I'm running intrepid and have jaunty in my sources.list, but apt preferences pinning all but one package at intrepid, does do-release-upgrade figure out what to do?
[06:04] <pwnguin> thats a lot of pinned packages
[06:05] <geofft> That's how the preferences phrase it, no? Package: * Pin-Priority: -1
[06:05] <pwnguin> maybe i should learn how to pin packages sometime ;)
[06:27] <dholbach> good morning
[06:35]  * bryce waves to dholbach
[06:35] <dholbach> hiya bryce
[07:27] <pitti> Good morning
[07:28] <Hobbsee> heya pitti!
[07:32] <Superdweeb> hey, most of you guys are asleep right?
[07:43]  * pitti hugs Hobbsee
[07:43]  * Hobbsee hugs pitti back :)
[07:43] <Hobbsee> how goes it/
[07:45] <pitti> Hobbsee: I enjoyed San Francisco last week (LF collab summit), and the Easter holiday
[07:45] <pitti> time to get back to work :)
[07:46] <Hobbsee> ahhh, nice
[07:46] <Hobbsee> heh.  Get fixing!  :)
[09:09] <elmo> doko: why isn't python-examples seeded as supported?
[09:11] <doko> elmo: because nobody did note? really, should we support these? upstream currently considers removal of many of these
[09:12] <elmo> doko: *shrug* just seems odd - the source is in main, seems like a no-brainer.  but I'm not bothered either way
[09:12] <elmo> (by source, I mean python2.6, not python-defaults, obviously)
[09:12] <doko> sure, we can add it
[09:13] <cjwatson> it's already in the development seed
[09:13] <elmo> cjwatson: oh?  nijaba's ubuntu-maintenance-check script was flagging it as unsupported to me
[09:14] <elmo> maybe it or I am on crack
[09:18] <cjwatson> elmo: it was in desktop in dapper (probably mistakenly), but is in development as of hardy; it may be that nijaba's script is confused about the status of development, since there's quite a bit of desktopy stuff in there
[09:19] <slangasek> pitti: strange, why is /tmp only a ramdisk if / is low on space?  (On an upgraded system, I have it as a tmpfs in /etc/fstab)
[09:20] <slangasek> having /tmp as tmpfs also makes it more straightforward to use read-only root...
[09:20] <pitti> slangasek: in fstab? I'm fairly sure that this wasn't configured so by d-i
[09:20] <cjwatson> d-i doesn't do that (yet), no
[09:20] <nijaba> cjwatson: That is definitely a problem with Dapper.  Are the python-examples in development or supported-development in Jaunty?  IIRC only the ones in supported-development are marked as maintained.  but maybe that is a mistake
[09:20] <slangasek> hmm, wonder where my tmpfs setting came from
[09:20] <cjwatson> /etc/init.d/mountoverflowtmp mounts /tmp as tmpfs in emergencies
[09:21] <cjwatson> nijaba: development
[09:21] <slangasek> ohwell, I'll keep it there in any case
[09:21] <cjwatson> nijaba: was looking at hardy, I don't imagine the distinction matters for jaunty
[09:21] <nijaba> cjwatson: nope
[09:21] <elmo> FWIW, I'm looking at jaunty
[09:25] <pitti> bryce: I'm not sure about your own reply to the call for testing; are you still looking for feedback on 2.6.3-0ubuntu10~bug359600greedy1 ?
[09:26] <nijaba> cjwatson: maybe there is a logical issue here.  So far, the script marks as maintained only those packages that are in some selected seeds directly or by inheritance.  When a package is not found there, it is not marked as maintained at all.  Shouldn't we change this so that any package in main should at least be considered as maintained for 18mo, then for a LTS mark it as maintained for 3y if in a DT seed and 5 for a server seed?
[09:27] <bryce> pitti: no longer
[09:27] <cjwatson> nijaba: for the 18-month releases, anything that's seeded at all should be supported, surely; the discrepancies would be a good way to find bugs in your scripts :-)
[09:27] <pitti> bryce: okay
[09:27] <bryce> pitti: my fears were confirmed, so we're back to square one
[09:27] <cjwatson> nijaba: I don't think you should use main for this, but just the full set of seeds
[09:28] <elmo> nijaba: so, one other thing I've noticed is that my (hardy) kernel always seems to be considered unsupported
[09:28] <elmo> which is a little distressing if true ;-)
[09:28] <nijaba> cjwatson: ok.  expect a new version shortly
[09:28] <nijaba> elmo: that's a known issue, as kernels, apart from the orinal one, are generally not seeded.  if you know a way to solve this, I'll take it
[09:29] <cjwatson> kernels so are seeded
[09:29] <pitti> bryce: BTW, I watched Keith's talk about GEM, UXA, and KMS last week; pretty interesting, but the amount of changes that we'll see in karmic are also scary :)
[09:29] <nijaba> cjwatson: really?  where?
[09:29] <cjwatson> oh, well, I guess ABI changes will leave unseeded kernels. Is that what you mean?
[09:29] <nijaba> cjwatson: yep
[09:30] <bryce> pitti: oh dear
[09:30] <cjwatson> yeah, only thing you can do there is special-case them
[09:30] <bryce> pitti: I thought we were through the worst of that.....
[09:30] <pitti> bryce: well, we don't really use UXA yet, so I don't count jaunty yet
[09:30] <slangasek> pitti: do we need to rate-limit Keith?  Distract him with board games?
[09:30] <pitti> well, the changes make a lot of sense, of couse
[09:31] <pitti> I'm slightly worried about what will happen for nvidia systems
[09:31] <bryce> pitti: it's already been affecting us even though we don't use UXA, but I was hoping it'd all be stable so we could switch to it in karmic
[09:31] <bryce> pitti: yes I am definitely growing tired of users grousing at us and threatening to switch to some other distro
[09:32] <nijaba> cjwatson: so any linux-[generic|server|image-*-[generic|server]] should me marked as maintained?
[09:32] <pitti> bryce: would that actually help? I can't see how it can work significantly better in current FC11, for example?
[09:32] <pitti> they are using nouveau by default there
[09:32] <ogra> pitti, do you still maintain that table with languages used worldwide ?
[09:32] <davmor2> slangasek: is that kieth have you heard about this d&d game.......
[09:32] <pitti> ogra: well, there's not much to maintain :)
[09:32]  * ogra fails to find the url
[09:33] <pitti> ogra: http://bazaar.launchpad.net/%7Eubuntu-langpack/langpack-o-matic/main/annotate/head%3A/langpacksize
[09:33] <bryce> pitti: of course not, that's the sadly ironic thing
[09:33] <pitti> bryce: unless, with "other distro" they mean "lenny" or "hardy" :)
[09:33] <slangasek> davmor2: more like "hey have you heard of this San Juan variant called Lima"
[09:33] <cjwatson> switching distributions to avoid Intel driver bugs is a bit like switching cities to avoid divine retribution
[09:34] <bryce> pitti: well I also hope we can rely more on -nouveau in karmic.  Dunno if it'll be viable for defaulting to, but that's definitely my hope
[09:34] <cjwatson> it'll catch up with you in the end ...
[09:34] <bryce> cjwatson: exactly
[09:34] <davmor2> slangasek: give him a copy of the sims and tell him he can't code till he completes it :D
[09:34] <ogra> pitti, hmm, i thought i remembered a table with an overview how many people speak what langs in relation to the total world population
[09:34] <cjwatson> nijaba: right, something along those lines although I suspect there are a few more flavours to add there
[09:34] <pitti> bryce: *nod*; I doubt that we'll get a GEM/KMS enabled nvidia driver very quickly anyway
[09:34] <Hobbsee> davmor2: oh dear ;)
[09:34] <pitti> ogra: that might be in some ancient email
[09:34] <ogra> pitti, size doesnt matter so much on USB images ;)
[09:34] <ogra> ah, thanks
[09:34] <cjwatson> nijaba: an alternative would be to whitelist by source package for the kernels
[09:35]  * ogra checks if evo still has it
[09:39] <dholbach> Keybuk: does the patch in bug 343215 look good to you?
[09:41] <Keybuk> I've never really looked at the pybootchartgui code
[09:42] <tjaalton> I've got a race condition on boot when using a remote server to collect syslogs. the boot hangs when trying to start klogd unless the network is up
[09:43] <tjaalton> failsafe works, because while the menu is open the network manages to get up and running
[09:43] <tjaalton> this is jaunty
[09:44] <tjaalton> should I file a bug or blame the local configuration?
[09:44] <Keybuk> tjaalton: it's not something we support I think
[09:44] <tjaalton> Keybuk: hrm, ok
[09:44] <slangasek> tjaalton: do you have the remote server configured by IP or by hostname?
[09:45] <Keybuk> pitti: is there any way to get the actual core file for a crasher bug?
[09:45] <tjaalton> slangasek: hostname
[09:45] <pitti> Keybuk: if it was successfully retraced, it gets deleted
[09:45] <Keybuk> pitti: :-(  but that means I can't actually examine the crash
[09:45] <pitti> Keybuk: so, if you are looking at a bug like that, then "no", I'm afraid
[09:46] <slangasek> tjaalton: I would advise not doing that, unless you want to also add the hostname to /etc/hosts.  syslog itself is udp and should behave itself if the host is unreachable, but if it can't resolve the hostname I think that's invariably going to be painful
[09:46] <Keybuk> pitti: the bug has a trace which puts the line of code of the crash at the *entry* to a function
[09:46] <Keybuk> which makes little-to-no sense
[09:46] <slangasek> tjaalton: if you get the same hangs when pointing at an IP, I think that merits a bug
[09:46] <tjaalton> slangasek: ok, I'll try that next
[09:46] <Keybuk> so I need to examine the stack, but can't do that without the core file
[09:46] <Keybuk> pitti: does apport delete the core files from the user's /var/crash directory when reported?
[09:46] <ogra> Keybuk, why does apt-get install bootchart default to install pybootchartgui for me ?
[09:47] <ogra> if we dont support it
[09:47] <pitti> Keybuk: no, it remains for a week
[09:47] <pitti> Keybuk: the cron job deletes old files
[09:47] <Keybuk> ogra: I didn't way we didn't support it?
[09:48] <ogra> oh, you were referring to the syslog qestion above, sorry
[09:48] <ogra> still though, its in universe
[09:48] <Keybuk> ogra: personally I dislike pybootchartgui strongly
[09:49] <ogra> tjaalton, from my experience with remote syslogging in ltsp, syslog has hardcoded dns lookups builtin ...
[09:49] <ogra> Keybuk, so why do we pull it in by default ?
[09:50] <slangasek> because I haven't gotten to that one in component-mismatches yet
[09:50] <ogra> we should offer it optionally but default to whats in main
[09:50] <slangasek> I was going to drop the pybootchartgui recommends for jaunty
[09:50] <ogra> oh, so its supposed to go to main ?
[09:50] <Keybuk> ogra: there is no chart generation tool in main
[09:50] <ogra> ah, good
[09:50] <Keybuk> slangasek: but then people installing bootchart would have no charts
[09:51] <Keybuk> and I'll reassign all the zillion bugs about that to you personally <g>
[09:51] <ogra> Keybuk, the java one we used to use ?
[09:51] <Keybuk> ogra: that's in bootchart-java
[09:51] <ogra> right, that should be the default then
[09:51] <slangasek> Keybuk: ...
[09:51] <Keybuk> slangasek: the bootchart package contains only the collector, it generates .tgz files containing the data collected
[09:52] <Keybuk> slangasek: you need either pybootchartgui or bootchart-java to turn that into a chart
[09:52] <Keybuk> which bootchart will do if either one is installed
[09:52] <Stskeeps> bootchart finally got seperated?
[09:52] <slangasek> Keybuk: are you arguing pybootchartgui should be installed by default?
[09:52]  * ogra wonders why it doesnt collect anythng for him on armel 
[09:52] <Keybuk> slangasek: I'm saying that one of the charting tools should be installed *with* bootchart by default, yes
[09:52] <slangasek> Keybuk: ok. would you like to write an MIR? :)
[09:52] <Keybuk> ie. if you install bootchart, you should get one of the charting tools along with it
[09:53] <Keybuk> personally I prefer the java one
[09:53] <Keybuk> but that made people throw things at me for being written in java
[09:53] <Keybuk> the python one is supposed to be "better", but I think it's output sucks
[09:53] <directhex> nothing wrong with java
[09:53] <Keybuk> and it generally doesn't work more
[09:53] <directhex> if you have the disk space and RAM for it ;)
[09:54] <Keybuk> slangasek: I could argue that the java one should be in main already, since it was only separated out of a source package that was in main before
[09:54] <ogra> you have it installed by default anyway
[09:54] <slangasek> Keybuk: great - let's recommend that one by preference and get it back into main, then. :)
[09:55] <Keybuk> slangasek: can you file a bug to remind me?
[09:55] <slangasek> Keybuk: if we're in agreement, how about if I just upload?
[09:55] <Keybuk> sure
[09:56] <ogra> hmm ... "cp cannot stat "/lib/libc.so.*"
[09:57] <ogra> Keybuk, meh, i think the init-top script needs special casing for armel
[09:57] <ogra> lool, ^^^
[09:58]  * slangasek eyes the bootchart version numbers
[09:58] <ogra> lool, do we use /lib-vfp in initramfs ?
[09:58] <lool> If we do it's probably by accident
[09:59] <lool> I think that's actually a bug if we do
[09:59] <lool> Because we should create vfp initrd if the buildd is vfp
[09:59] <lool> err should NOT
[09:59]  * ogra looks for the runes to display initramfs contents
[09:59] <lool> But the copy_exec stuff and other logic might be doing that   :-/
[09:59] <ogra> yes
[09:59] <ogra> so we would need to special case that or make a link or something like that
[09:59] <slangasek> Keybuk: bootchart missing an .orig.tar.gz?
[10:00] <Keybuk> slangasek: ?
[10:01] <cjwatson> ogra,lool: should be a one-liner in copy_exec
[10:01] <slangasek> Keybuk: 0.90.1-2 is a native package
[10:01] <cjwatson>                 # Try to use non-optimised libraries where possible.
[10:01] <cjwatson>                 # We assume that all HWCAP libraries will be in tls.
[10:01] <cjwatson>                 nonoptlib=$(echo "${x}" | sed -e 's#/lib/\(tls\|i686\).*/\(lib.*\)#/lib/\2#')
[10:01] <Keybuk> slangasek: bootchart is a package we wrote
[10:02] <slangasek> Keybuk: <shrug> if there's no upstream tarball, why use non-native-format version strings
[10:02] <slangasek> (debuild whines at this)
[10:03] <Keybuk> because I prefer them
[10:03] <Keybuk> point me at the line in debian-policy that says you can't use a revision format version string if you don't have an orig.tar.gz ;)
[10:04] <slangasek> it doesn't say you can't
[10:04] <slangasek> it's just annoying when you do :)
[10:04] <ogra> wow
[10:04] <ogra> pybootchartgui explodes massively on armel
[10:04] <Keybuk> slangasek: I think information is lost if you don't use them
[10:04] <cjwatson> policy does allow that, but I think the intention is for that to be for cases where an upstream has released something with a dash in its version
[10:04] <Keybuk> I like to still use <code version>-<packaging version>
[10:05] <Keybuk> cjwatson: I don't see that intent in -policy at all
[10:05] <slangasek> cjwatson: evidently, that's what "upstream" is doing :-)
[10:05] <cjwatson> TBH if I wanted to separate code and packaging I would create an .orig.tar.gz
[10:05] <cjwatson> just because that would make the separation more explicit
[10:06] <Keybuk> but that involves causing myself pain deliberately
[10:07] <cjwatson> policy doesn't really specify the existence of an orig.tar.gz at all; it's left up to common sense
[10:07] <cjwatson> perhaps we should change that ;-)
[10:08] <lool> cjwatson: thanks; will patch the sed foo
[10:08] <cjwatson> (except in C.3, which is less than obviously normative)
[10:13]  * ogra wonders if bootchart-java behaves differently on armel
[10:13] <lool> cjwatson: It's unfortunate that I can't force the hwcaps for ldd; I can force them only for ldconfig
[10:19] <lool> slangasek: Pushing initramfs-tools; tested the change on my babbage and confirmed that it dropped /lib/vfp from the initramfs
[10:20] <slangasek> I guess that's critical for RC on armel?
[10:20] <ogra> well, it breaks things like bootchart :)
[10:21] <slangasek> but not things like boot? :)
[10:21]  * ogra didnt notice any breakage in the default setup yet ... though we're likely using the wrong libc then i assume
[10:22] <ogra> hmm, bootchart-java doesnt seem to finish parsing
[10:24] <ogra> pybootchartgui definately has the wrong code for CPU detection, i wonder if bootchart-java suffers the same thing :/
[10:25] <ogra> ah, no ! i get a png now, its just very slow
[10:25] <ogra> !!
[10:25] <ogra> hmm, a 0 byte png yet ...
[10:27] <slangasek> why does pybootchartgui need code for CPU detection?
[10:28] <ogra> no idea, but the parser tries to compare system.cpu with something
[10:28] <ogra> and fails at that step on my imx51 system
[10:28] <ogra> the java parser is running since 7:30min already
[10:29] <ogra> ah, and it finished
[10:31] <ogra> nice !
[10:31] <ogra> my babbage board takes 0:41 to boot
[10:31] <ogra> thats not bad for booting from two Sd cards i think
[10:33] <ogra> http://people.ubuntu.com/~ogra/babbage-jaunty-20090414-2.png in case anyone is intrested to see the boot of a babbage board
[10:34] <amitk> ogra: two SD cards?
[10:34] <ogra> amitk, one is my bootfloppy and the other sits in an USB SD reader and carries the rootfs
[10:35] <ogra> initramfs comes from the first one
[10:36] <amitk> aah
[10:36]  * ogra wonders what that udevadm sleep is doing there between 6 and 11.5 sec 
[10:38] <ogra> asac, is there any ETA for the NM fix on armel ? would be nice to have ir in the RD image
[10:38] <ogra> *it
[10:38] <ogra> *RC
[10:38]  * ogra sighs about his typing
[10:40] <asac> ogra: is there still time to get anythin on the RC CDs at all?
[10:41] <ogra> slangasek, ^^^ ?
[10:41] <slangasek> that depends entirely on what it is
[10:41] <ogra> bug 356517
[10:41] <slangasek> the NM fix - yes, I would like to get that in; is it ready for upload?
[10:42] <slangasek> and even if it weren't in time for RC, better to have it in the queue if possible so we can take it opportunistically
[10:43] <asac> ok. i will fast track right after what i am doing now
[10:43] <pitti> slangasek: just for planning, is it okay for you if I upload apport after RC? (to disable itself by default)
[10:43]  * ogra would prefer to not have to release note ifconfig calls :)
[10:44] <slangasek> pitti: any chance that fix can get in /before/ RC?  That's where it's supposed to be according to the schedule
[10:44] <pitti> slangasek: ok; I just thought we might want it on for the RC itself
[10:45] <slangasek> asac: thanks.  btw, does ubufox still need updated to know to look at 9.04?  my cursory inspection of the source suggests it does
[10:45] <asac> slangasek: the sources.list is "just" a backend thing for setting up the DB, but looking into this i found that the urls still have 8.04 as distributionID ... most likely was a typo
[10:46] <nijaba> cjwatson: should the rt kernel flavor considered as maintained?
[10:46] <slangasek> asac: does that mean there aren't changes that need to be made to ubufox to update it for a new release?  If so, I should take that out of te checklist
[10:47] <asac> slangasek: anyway. what i am doing right now is finalizing fix for bug 353924 and bug 270303 (both committed)
[10:47] <cjwatson> nijaba: no, you can tell because it's in universe/multiverse
[10:47] <asac> slangasek: no we need to fix the distributionID url (also committed)
[10:47] <slangasek> asac: okie
[10:47] <nijaba> cjwatson: ah, right, I did not click on the link to check, sorry
[10:48] <pitti> slangasek: okay; one-line change to disable apport by default is uploaded
[11:09] <ogra> doko, i see that on armel doing an upgrade: http://paste.ubuntu.com/150705/ bug or not ?
[11:09] <ogra> (it auto-opens the update-manager details window)
[11:17] <slangasek> lool, ogra: I'm planning to defer initramfs-tools until post-RC, to not hold up all the respins much longer
[11:19] <pitti> seb128: I can't say which of the two libproxy uploads is yours and which is mine; I just rejected one of them
[11:20] <seb128> pitti: yeah, that's ok, those should be identic anyway ;-)
[11:21] <slangasek> heh :)
[11:25] <slangasek> pitti: stray 9_autotools.patch2 in this tracker upload; do you want to redo?
[11:25] <pitti> slangasek: whoops; yes, I'll reupload
[11:31] <pitti> slangasek: done; I also updated Vcs-Bzr:; thanks for pointing out
[11:32] <asac> ogra: __ARMEL__ ?
[11:34] <asac> ogra: can you please spin nm with this debdiff and give me an ack? http://paste.ubuntu.com/150727/
[11:36] <ogra> asac, will do
[11:37] <asac> ogra: cool. that would help us to not do another round ;)
[11:38] <RicardoPerez> tkamppeter: Hi! I'd just posted a minor patch to fix a i18n issue in the system-config-printer applet. Could you take a look and apply the patch (if you think it looks ok)? I'm talking about bug #360621
[11:41] <tkamppeter> pitti, can we make a release freeze exception for the patch in bug 360621? It is a one-liner.
[11:46] <ogra> asac, hrm, that will take a while ... 115M build-deps ...
[11:46] <pitti> tkamppeter: the patch makes sense; don't know about slangasek's plan for building CDs
[11:46] <pitti> tkamppeter: please upload it anyway, so that it's in the queue; then it's quick to accept if we want it
[11:47] <slangasek> probably post-RC
[11:47] <pitti> slangasek: btw, did we ever consider renaming RC to "beta 2"? :-)
[11:47] <slangasek> yuck
[11:48] <slangasek> "probably post-RC" could also mean "probably SRU", if you prefer :)
[11:49] <slangasek> pitti, didrocks: does the gtk2-engines change have any effect on our default theme?
[11:49] <pitti> slangasek: no, we are using murrine by default; I switched to clearlooks for testing
[11:49] <RicardoPerez> Thanks very much to everybody :)
[11:50] <pitti> RicardoPerez: good job in chasing down i18n bugs
[11:50] <didrocks> slangasek: it just contains others GNOME default themes (clearlooks, and so on.)
[11:50] <RicardoPerez> pitti: I know I'm irritating about the i18n issues :) Sorry! :P
[11:51] <pitti> RicardoPerez: no, you aren't; unfortunately it's just a bit late to get in changes
[11:51] <didrocks> pitti: I switched to clearlooks too and didn't notice regression
[11:51] <kwwii> pitti: I just noticed that the latest ubuntu-wallpaper package never made it into jaunty (it fixes a bug in the simple-ubuntu wallpaper in which the left pixels are transparent)...any chance of that making it into jaunty or at least an update right after?
[11:51] <RicardoPerez> pitti: many thanks anyway :)
[11:51] <slangasek> didrocks: well, pretty much by definition, "fixes" to the appearance of themes break the UI freeze ;)  So I want to be sure this doesn't cause changes to our default appearance
[11:52] <pitti> kwwii: I saw the sponsoring bug today, but it's a bit late I'm afraid
[11:52] <pitti> kwwii: I can upload it, but it might very well get rejected
[11:52] <didrocks> pitti: I don't know if you notice but tracker has been rejected
[11:52] <nijaba> cjwatson: does http://bazaar.launchpad.net/~nijaba/ubuntu-maintenance-check/trunk/revision/14 looks ok to you?
[11:53] <pitti> didrocks: I know, I reuploaded it for the stray .patch2 and also added Vcs-Bzr
[11:53] <tkamppeter> pitti, RicardoPerez, OK, will upload the fixed s-c-p
[11:53] <didrocks> pitti: ok, thanks :)
[11:53] <RicardoPerez> tkamppeter: thank you very much!
[11:53] <cjwatson> nijaba: that grep syntax is bogus
[11:54] <cjwatson> nijaba: I think you meant something like this: egrep -q "^linux-(headers|image|restricted)-"
[11:54] <cjwatson> nijaba: (grep -> egrep, [] -> (), delete trailing * which is unnecessary here and anyway you meant .*)
[11:54] <didrocks> slangasek: I didn't have noticeable regression, even with French strings. The new features seems to not add too much changes in UI itself
[11:55] <cjwatson> nijaba: likewise, grep -q "\-[virtual|server]$"  ->  egrep -q "\-(virtual|server)$"
[11:55] <nijaba> cjwatson: :/ right.  Passed my test, I do not know how
[11:55] <asac> ogra: thought you have a big pipe ;)?
[11:55] <cjwatson> nijaba: I think I would also use grep -q -- "-blah" rather than grep -q "\-blah"
[11:55] <cjwatson> nijaba: other than that, looks ok
[11:56] <cjwatson> nijaba: well, do you care about non-x86 architectures here?
[11:56] <ogra> asac, nah, just an expensive one :P
[11:56] <nijaba> cjwatson: hmm... do we have non x86 that are maintained?
[11:56] <kwwii> pitti: right, it seems it wsa forgotten along the way
[11:56] <cjwatson> nijaba: lpia, armel
[11:57] <cjwatson> (maybe not in hardy, I forget the exact timeframes)
[11:57] <kwwii> pitti: as the bug is only in the secondary wallpaper it should be fine if it gets included in an update after install
[11:57] <cjwatson> nijaba: oh, also, why the two separate greps at the start, when the second is just a more specific case of the first?
[11:57] <nijaba> cjwatson: well, would could be giving me details on this?  pgraner ?
[11:58] <nijaba> cjwatson: no good reason, a left over
[11:58] <cjwatson> nijaba: you could just say that lpia (flavour: "lpia") and armel (flavours: "imx51", "ixp4xx") kernels are supported and that won't fire if the kernels aren't present
[11:59] <cjwatson> nijaba: but yes, pgraner
[12:02] <asac> ogra: those build deps are good to have ;)
[12:02] <ogra> yeah, its just that i have a freshly installed system here atm
[12:02] <ogra> but i'm already in the middle of the build now
[12:04] <cjwatson> ArneGoetje: could you merge lp:~cjwatson/langpack-o-matic/gnome-user-guide-recommends, please? It'll get rid of some entries on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt once the next batch of language packs are uploaded with it
[12:11] <tkamppeter> pitti, s-c-p uploaded.
[12:11] <asac> slangasek: i uploaded nm-applet togetgher with human-icon-theme for 358526
[12:12] <asac> slangasek: waiting for ogra's confirm on the armel patch ... should happen soon too
[12:12] <asac> (e.g. nm daemon upload)
[12:12] <ogra> still building :/
[12:14] <ogra> nijaba, armel is definately jaunty only yet, no hardy support back then
[12:15] <nijaba> ogra: could you give me the output of 'dpkg -l | grep "$linux"' on an armel and lpia system if you have a sec?
[12:16] <ogra> i dont have a lpia system around atm, but for armel i can
[12:16]  * StevenK boots an lpia install
[12:16] <nijaba> ogra: that would be great.
[12:16]  * nijaba thanks StevenK
[12:17] <ogra> nijaba, i assume you want the packages starting with linux-* ?
[12:17] <nijaba> ogra: right
[12:18] <ogra> (your grep logic above is a bit flawed :) )
[12:18] <nijaba> ogra: I have not clue what the kernel packages look like on those system
[12:18] <ogra> same as everywhere
[12:18] <StevenK> Heh, yeah, '^linux'
[12:18] <StevenK> ^ == start of line, $ == end of line
[12:18] <ogra> http://paste.ubuntu.com/150756/
[12:18] <nijaba> ogra: uh, right ^linux, not $ :(
[12:19] <ogra> StevenK, wont work either :)
[12:19] <ogra> the lines start with ii
[12:19] <StevenK> Shhhh
[12:19] <nijaba> ogra: dug
[12:19] <nijaba> duh, even
[12:19] <ogra> dpkg -l | cut -d' ' -f3 |grep "^linux"
[12:20] <lool> slangasek: initramfs-tools is arch: all though
[12:21] <slangasek> lool: it still has to get built, which would delay things another ~1h
[12:21] <lool> Ok
[12:22] <nijaba> ogra: thanks a lot.  so there is a bit of a mess, as -generic -> x86, -server -> x86, but -imx51 -> armel.  What will happen when we want an server flavor armel build?
[12:22] <ogra> nijaba, in the above paste s/imx51/ixp4xx/ or s/imx51/versatile/ for the other two armel subarches
[12:23] <ogra> i guess you would end up with something like: linux-image-2.6.28-11-server-$subarch
[12:23] <ogra> not sure about the order, $subarch could come first
[12:23] <lool> pitti: Hey
[12:24] <lool> pitti: notify-osd 360989
[12:24] <nijaba> ogra: ok, I'll worry about it later then...
[12:24] <lool> pitti: I can't reproduce here, but perhaps you have an idea of what changed that makes $GDMSESSION be default.desktop for some installs and default for others
[12:24] <slangasek> lool: is bug #349459 still a target for final?
[12:24] <StevenK> nijaba: http://paste.ubuntu.com/150762/
[12:25] <lool> slangasek: I could upload it this week, otherwise either as a SRU or not at all, depending on importance of other issues
[12:25] <nijaba> StevenK: great, thanks a lot.
[12:26] <infinity> nijaba: The odds of having "-server" kernels on armel are pretty slim.  We don't have them on any !x86 arch because, in general, there's no real difference between, say, a sparc64 workstation and a sparc64 server, from the POV of what the kernel should support.
[12:26] <pitti> lool: "default.desktop", really?
[12:26] <infinity> nijaba: In the armel world, the very few armel "servers" out there (like the Marvell boards we're using as buildds) would be their own subarch anyway.
[12:27] <ogra> well, you might want special generic server features enabled in the config
[12:27] <ogra> stuff thats not actually arch related
[12:27] <nijaba> infinity: what about NAS? I thought a lot of them were using arm?
[12:27] <cjwatson> nijaba: I'm not aware of plans for such an image
[12:27] <lool> pitti: That's for mdz
[12:27] <cjwatson> oh, now that I press page down once more I see that others have already answered that
[12:27] <lool> pitti: Mine uses default.desktop and has it in the gdm.conf as well
[12:27] <cjwatson> nijaba: don't borrow trouble
[12:27] <nijaba> cjwatson: I am not either, was just trying to deduce a global logic
[12:27] <lool> pitti: Sorry mine says default
[12:27] <lool> and has default.desktop in gdm.conf
[12:27] <pitti> lool: right, that should be /usr/share/gdm/BuiltInSessions/default.desktop
[12:28] <ogra> nijaba, i guess best is to grab the logic the kernel team uses for generating the names
[12:28] <cjwatson> nijaba: don't try to invent a global logic in advance of the kernel team either - deciding on names for images is their prerogative
[12:28] <cjwatson> ogra: there isn't anything set in stone
[12:28] <ogra> sadly
[12:28]  * cjwatson shrugs
[12:28] <infinity> ogra: Most of the "server-related features" are enabled in x86 -generic kernels too. :)
[12:29] <ogra> infinity, yeah, indeed
[12:29] <infinity> ogra: The differences between -generic and -server aren't what most people expect, and are usually related to hardware support tradeoffs (like supporting massive amounts of RAM on -server, but fewer processor architectures, etc)
[12:29] <nijaba> cjwatson: ok, for now any -(imx51|ixp4xx|versatile|generic)$ will be considered to be on the same maintenance cycle as Ubuntu.  will adapt if and when needed then
[12:29] <infinity> ogra: Since in the armel world, subarches already cover those sorts of things, I doubt we'd ever need or want -server images.
[12:29] <ogra> asac, works !
[12:29] <nijaba> * -(imx51|ixp4xx|versatile|lpia|generic)$
[12:29] <mdz> pitti: my only guess is desktop-switcher
[12:30] <kwwii> wow, my jaunty system just fell apart...error 13 from grub, fsck problems, etc...how does one report a bug in this case?
[12:30] <lool> mdz: Ah you used desktop-switcher?
[12:30] <ogra> yeah i think so too, but i wasnt sure there might be things enabled you dont want on desktop but on server
[12:30] <lool> mdz: it's know to cause breakage sadly
[12:30] <ArneGoetje> cjwatson: will do
[12:30] <slangasek> pitti: bug #352656 doesn't look critical enough to me to warrant a freeze exception; what do you think of pushing this to SRU?
[12:30] <slangasek> pitti: (is it regression-potential?  it's not marked as such)
[12:31] <infinity> nijaba: To be honest, your better bet is probably just to find linux-image\* in Component: main on all arches, and there's your list.
[12:31] <pitti> will always have the
[12:31] <pitti>         <filename>$GDMSESSION</filename> set to the basename of the
[12:31] <pitti>         session that the user chose to run without the
[12:31] <pitti>         <filename>.desktop</filename> extension.
[12:31] <pitti> slangasek: I don't know whether that worked in intrepid, I'm afraid
[12:31] <nijaba> infinity: if I do so, we would be saying that we maintain -rt, -xen, etc for 3y, so it does not work
[12:31] <pitti> lool: it seems it's meant to not have .desktop
[12:32] <slangasek> pitti: ok; without a clearer justification, I'm inclined to reject
[12:32] <cjwatson> nijaba: -rt and -xen are not in main
[12:32] <infinity> nijaba: linux-image-xen is in universe.
[12:32] <cjwatson> (though you should check Component: restricted too)
[12:32] <infinity> (Not that I'd mind us supporting it...)
[12:32] <pitti> slangasek: ok; I'll reopen the bug then
[12:32] <nijaba> cjwatson: and security, and updates
[12:33] <cjwatson> nijaba: those are not components, so no
[12:33] <infinity> nijaba: security and updates are pockets, not components.
[12:33] <lool> pitti: Ok, we should have written this in gdm.conf in the first place
[12:34] <nijaba> cjwatson: but my problem is that if I search for a specific kenel version, that has been updated after initial release, I will not find it in main
[12:34] <lool> pitti: If you look at daemon/slave.c:4644, gdm strip .desktop only for user session
[12:34] <lool> pitti: Not for configured or fallback sessions
[12:34] <nijaba> cjwatson: hence my current logic to go around this
[12:34] <mdz> njpatel: do you have any ideas on bug 360989?
[12:35] <slangasek> nijaba: well, those kernels by definition are also not "supported" for security, you have to instal the renamed one to get security support ;)
[12:36] <lool> pitti: This is patched in debian/patches/35_gdm.conf.patch, but even the upstream default config file uses .desktop there
[12:36] <ogra> lool, shouldnt it actually use the Exec= line from the .desktop file instead of the name ?
[12:37] <lool> mdz: Could you attach your .dmrc?
[12:37] <pitti> lool: I'm fine with updating the d-bus service test accordingly if you want
[12:37] <mdz> lool: done
[12:37] <lool> pitti: Yes, I think we should fix: gdm to strip .desktop, gdm to default to default and not default.desktop and notify-osd to asked default.desktop
[12:37] <lool> mdz: dthanks
[12:37] <mdz> (it's empty)
[12:38] <pitti> lool: perhaps not all three, with the freeze being really close now?
[12:38] <lool> mdz: Mine has [Desktop]\nSession=default
[12:38] <lool> mdz: Which is why GDMSESSION is correct here
[12:38] <ogra> it is only written if you manually selected a session
[12:38] <ogra> similar to gconf behavior
[12:38] <lool> pitti: Agreed, probably only notify-osd change for RC
[12:39] <mdz> lool,pitti: just to confirm, I don't think this is an RC issue
[12:39] <lool> pitti: I can do it if you like
[12:39] <mdz> it's the sort of thing I expected from integrating notify-osd late
[12:39] <lool> mdz: Could you explain what you ran though?  Did you run desktop-switcher?
[12:40] <pitti> with slangasek just shutting the doors, we probably can't get it into RC, but we might get it post-RC or SRU
[12:40] <lool> mdz: I wonder what changed your .dmrc or created mine differently
[12:40] <mdz> lool: I don't remember, I haven't touched the machine in over a week
[12:40] <ogra> usually its only a DM that writes .dmrc
[12:40] <pitti> lool: sure, please go ahead, and coordinate with slangasek about rc/final/sru
[12:40] <mdz> lool: my .dmrc is dated today
[12:40] <mdz> around the time I rebooted the system after installing updates
[12:41] <njpatel> mdz: desktop-switcher doesn't touch session files (just /gnome/session/required_components gconf list)
[12:41] <lool> mdz: I think it's written my gdm when you chose a session on the login screen
[12:41] <ogra> right, and only then
[12:42] <mdz> lool: I've never even *seen* the login screen on this system
[12:42] <mdz> it's always been autologin
[12:42] <mdz> njpatel: thanks, I've copied that into the bug
[12:42] <lool> mdz: It's probably written every time, I mentionned login screen to explain the use case
[13:03]  * ogra wonders if asac noticed his success message
[13:03] <koperton> hi i have made a simple bash script ; to work it shoul be in the /usr/bin . so now i have only to create my debian package . i have read this  http://ubuntuforums.org/showthread.php?t=852023
[13:04] <koperton> and i have create
[13:04] <koperton> d
[13:04] <koperton> but ... it install nothing
[13:04] <directhex> koperton, #ubuntu-motu
[13:04] <koperton> ok
[13:04] <koperton> sorry for that
[13:04] <slangasek> asac: you saw ogra say that your NM patch fixed the problem?
[13:05] <asac> slangasek: yes. uploaded
[13:05] <slangasek> great
[13:05] <asac> so now i am ready for RC
[13:05] <asac> ogra: ^^
[13:05] <ogra> yippie !
[13:05] <asac> just verified that it really doesnt includew the code on non ARMEL ;)
[13:06] <asac> s/doesnt includew/does run/
[13:06] <ogra> heh
[13:06] <seb128> slangasek: we will probably need an another apport update
[13:06] <ogra> just wanted to say ...
[13:06] <seb128> slangasek:
[13:07] <seb128> $ ubuntu-bug --package gedit --pid $(pidof gedit)
[13:07] <seb128> Usage: /usr/bin/ubuntu-bug <pid>|<packagename>|<program path>|<.crash file>
[13:07] <seb128> slangasek: that breaks the launchpad integration menu entries in all desktop applications there
[13:07] <slangasek> seb128: er, and when did that regress?
[13:07] <asac> good. finally no new bugs ;)
[13:07] <seb128> dunno, that was mentionned in this glchess email yesterday on the list
[13:07] <seb128> and somebody else pointed on #ubuntu-desktop right now that it's broken in any applications
[13:08] <seb128> and I can confirm that here
[13:10] <seb128> "  * debian/local/ubuntu-bug: Drop generic passthrough of apport-{cli,gtk,kde}
[13:10] <seb128>     options since this leads to too much confusion. Instead just support a
[13:10] <seb128>     single argument and check whether it is a pid, a package name, a .crash
[13:10] <seb128>     file, or a program path. This does the right thing when calling it with a
[13:10] <seb128>     .crash file (LP: #347392) and fixes the help output (LP: #344923) Update
[13:10] <seb128>     manpage accordingly."
[13:10] <seb128> I guess
[13:10] <seb128> 0.148
[13:10] <seb128> which was 2 weeks ago
[13:12] <slangasek> pitti: ^^
[13:13] <slangasek> superm1: mythbuntu seed doesn't look any better wrt notif*
[13:17] <asac> cdimage.u.c seems to be down from here :/
[13:18] <slangasek> asac: 358526> human-icon-theme touches a lot more ISOs than I realized, due to ltsp; so I'm going to defer that one for the moment, possibly until post-RC
[13:19] <OsamaK> Hello. I found some typos in the Arabic docs, is it possible to fix that? (the 'freeze' is in action).
[13:20] <asac> slangasek: ok, i think its fine (with me) ... please consider it as a ride along if more ISOs need to be respun though.
[13:21] <asac> i will let the dxteam know, so they dont bug me "RC images still have this bug" ;)
[13:21]  * slangasek nods
[13:25] <Ampelbein> seb128: i don't think this is a problem directly in apport but from how liblaunchpad-integration calls ubuntu-bug as the options were changed there. http://paste.ubuntu.com/150786/ should fix that in the liblaunchpad-integration.
[13:35] <seb128> Ampelbein: not really
[13:35] <seb128> $ ubuntu-bug gedit $(pidof gedit)
[13:35] <seb128> Usage: /usr/bin/ubuntu-bug <pid>|<packagename>|<program path>|<.crash file>
[13:36] <seb128> Ampelbein: we need both option because gnome-sudoku needs a --package gnome-games for example
[13:36] <directhex> whoopsie. bug 361049 is the result of insufficient packager testing
[13:38] <Ampelbein> seb128: ah, ok.
[13:43] <cjwatson> OsamaK: it might be possible to do it post-RC
[13:43] <cjwatson> OsamaK: are the fixes committed somewhere?
[13:48] <pitti> seb128, slangasek: re (sorry, was at lunch)
[13:48] <seb128> pitti: wb
[13:48] <pitti> seb128, slangasek: could we change lp-i to call s/ubuntu-bug/apport-gtk/ ?
[13:49] <seb128> pitti: is lpi using out of GNOME? ie is -gtk always right?
[13:49] <pitti> seb128: alternatively, we could just call ubuntu-bug <pid>
[13:49] <slangasek> pitti: well, changing either package requires full respins; so whichever is most correct
[13:49] <pitti> or I need to change ubuntu-bug to accept all options again, which is more intrusive, though
[13:50] <slangasek> and I think this should be post-RC, at this point
[13:50] <pitti> slangasek: post-RC> ack
[13:50] <pitti> seb128: apt-cache rdepends liblaunchpad-integration1 is only gnomeish
[13:50] <pitti> but still, using ubuntu-bug would be nicer
[13:50] <pitti> phone, brb
[13:51] <seb128> pitti: would <pid> work on the case where you need to specify a package? ie gnome-sudoku will match gnome-games?
[13:51] <seb128> pitti: I think the reason why we have --package <package> --pid <pid> right not is those cases
[13:52] <pitti> seb128: the major reason for supplying --package is that it's more efficient
[13:52] <pitti> seb128: if you supply pid, it looks up the executable, and then the package with (the equivalent of) dpkg -S
[13:52] <pitti> seb128: wouldn't that work for sudoku?
[13:52]  * pitti tries
[13:53] <seb128> pitti: that should, I'm just trying to figure why we have this extra api and call --package if not required
[13:53] <pitti> seb128: as I said, it speeds it up a bit
[13:54] <pitti> confirmed that ubuntu-bug <pid> DTRT for sudoku
[13:54] <seb128> right, I tried here too
[13:55] <seb128> so you recommend just not using --package or calling apport-gtk rather?
[13:55] <seb128> is lpi called out of GNOME and would apport-gtk be still right in those cases?
[13:55] <pitti> seb128: right now, lpi is only called for gnomeish things, but also for e. g. pidgin
[13:56] <pitti> I prefer calling ubuntu-bug over apport-gtk, since that has built in DE detection
[13:56] <seb128> which is a gtk application so apport-gtk is ok
[13:56] <seb128> ok
[13:56] <seb128> want to do the lpi change?
[13:56] <pitti> right, it would just not work if you'd install pidgin under KDE and don't have apport-qt installed
[13:56] <pitti> seb128: I think I'll go with changing the ubuntu-bug calling semantics
[13:56] <pitti> s/semantics/arguments/
[13:57] <pitti> this is a safe one-liner and keeps the semantics
[13:57] <seb128> ok thanks
[13:57]  * seb128 hugs pitti
[13:57] <pitti> slangasek: I'll upload this, and we can accept it after RC, or before if we need to rebuild anyway; okay?
[13:57] <slangasek> pitti: yes
[13:57] <pitti> sorry for having screwed that up, I didn't think about checking lpi
[13:58] <pitti> seb128: do you know if there's a bug for this?
[13:58] <seb128> pitti: bug #360470 is that I think
[13:59] <Ampelbein> pitti: bug 353503 also
[13:59] <seb128> pitti: the title is misleading, what it really means is that apport doesn't run where it should
[13:59] <seb128> bug #353503
[13:59] <pitti> Ampelbein: thanks
[13:59] <pitti> I'll make the first a dup of the second
[13:59] <Ampelbein> there are some more i have spotted.
[14:00] <Ampelbein> which should become the master?
[14:00] <Ampelbein> 353503?
[14:01] <pitti> Ampelbein: yes, just made it the master
[14:01] <pitti> Ampelbein: if you find more, marking them as dupes is appreciated
[14:01] <Ampelbein> will do
[14:06] <pitti> seb128: this WFM: http://paste.ubuntu.com/150805/
[14:07]  * pitti restores tabs (which shouldn't be there in the first place, argh)
[14:08] <seb128> pitti: the change looks good to me
[14:08] <seb128> hum wait
[14:09] <pitti> eww, the bzr branch is out of date
[14:09] <seb128> pitti: will "launchpad-integration --package gedit" display the assertion in this case?
[14:09] <pitti> launchpad-integration --package gedit -b
[14:10] <pitti> works fine
[14:10] <pitti> seb128: the assert is only for cleanliness
[14:10] <pitti> $ launchpad-integration  -b
[14:10] <pitti> AttributeError: 'NoneType' object has no attribute 'binarypackage'
[14:10] <pitti> it fails way before that
[14:10] <seb128> ok
[14:10] <seb128> good
[14:10]  * seb128 hugs pitti
[14:10]  * pitti commits dokos' uploads to bzr first
[14:11] <seb128> yeah, known issue, doko doesn't bother update bzrs when doing changes ;-)
[14:29] <pitti> meh, it doesn't even build
[14:31] <elmo> could someone seed openssl-blacklist in hardy, please?
[14:33] <elmo> cjwatson: ^-- ?  (not sure, if there's a better way/place to report such low priority things; I realise this is not the best time to be asking)
[14:37] <Ampelbein> pitti: talking about launchpad-integration? i'm not a developer, but wouldn't http://paste.ubuntu.com/150830/ do the trick?
[14:37] <pitti> Ampelbein: not that part, the -dbg package gets files into /usr/local
[14:38] <seb128> Ampelbein: <pitti> seb128: this WFM: http://paste.ubuntu.com/150805/
[14:38] <pitti> and I need to fix that
[14:43] <superm1> pitti, your change wrg to notify-osd only showing up in gnome stopped it showing up in xfce on mythbuntu too.  i was wondering if you had any ideas how to get it there now?  it seems if we remove notification-daemon it shows up, but it's going to be hard to remove notification-daemon since it gets pulled in via libnotify1 when building CDs
[14:43] <pitti> superm1: depends on owhether you want it in xfce, I figure?
[14:44] <pitti> superm1: you should be able to remove the package, though
[14:44] <superm1> pitti, well in mythbuntu we do - i dont know if cody-somerville wants it in xubuntu too
[14:44] <pitti> notify-osd satisfies Recommends: notification-daemon
[14:44] <superm1> pitti, slangasek recommended moving notify-osd to the top of our seeds and seeing if the the publisher just doesn't pick notification-daemon, but it still got picked up i'm guessing by dependency resolution order
[14:54] <pitti> superm1: if xfce wants to use notify-osd as well, we could also change the dbus service file accordingly
[14:54] <slangasek> pitti: xubuntu doesn't
[14:54] <superm1> oh :(
[14:58] <cjwatson> elmo: done
[14:58] <elmo> cjwatson: ta
[15:00] <superm1> slangasek, well looking at livecd-rootfs, mythbuntu odesn't use the tasks for building the live disk, but uses the meta packages.  i think this was because w/ tasks, all of gnome got pulled in by dependency resolution.  so what if a conflicts is put on mythbuntu-live?  would that do the trick you think?
[15:01] <slangasek> superm1: depends how accomodating apt wants to be at the time, I guess
[15:01] <superm1> slangasek, okay i'll try to do some experiments emulating what livecd-rootfs does in a chroot then and see what apt thinks about it
[15:09] <ogra> calc, around ?
[15:16] <superm1> pitti, i just talked to cody-somerville and mr_pouit in #xubuntu-devel and they appear to be fine with bringing notify-osd into xfce now
[15:16]  * pitti arghs and wonders why lpi suddenly installs files into /usr/local/lib/python
[15:17] <pitti> superm1: ok; that needs a notify-osd upload, though
[15:17] <pitti> or, we just use seeding everywhere for now
[15:17] <superm1> pitti, it's already seeded at least for mythbuntu
[15:17] <superm1> pitti, i think that .service file is what needed adjustments then?
[15:18] <pitti> right
[15:19] <seb128> pitti: python bug, didrocks had the same issue with gnome-applets apparently
[15:19] <seb128> pitti: that might be fixed with the update from this morning, doko or slangasek knows about the details I guess
[15:19] <pitti> probably, but I presume we can't get a fixed python in time, so I'll do a debian/rules workaround
[15:19] <pitti> I'll try
[15:20] <seb128> pitti: are you update with the version from today?
[15:20] <pitti> probably not
[15:20] <slangasek> python is already "fixed", AIUI
[15:22] <Tonio_> jcastro: about the UDS, I confirmed to claire, as suggested, you weren't in copy
[15:22] <Tonio_> jcastro: should I forward to you then ?
[15:24] <jcastro> Tonio_: nope, that's fine, thanks for the heads up though
[15:25] <Tonio_> jcastro: no pb... I was a bit late, but I needed confirmation from my company, since I just announced I was leaving ;)
[15:25] <Tonio_> form the company I mean... ;)
[15:25] <ogra> Tonio_, so i'll see you in barcelona ?
[15:26] <Tonio_> ogra: yup, sponsored again ;)
[15:26] <ogra> i wonder from where you take all that bribing money every time :P
[15:26] <pitti> slangasek, seb128: thanks for the hint; now I get files in site-packages/, but at least not usr/local any more
[15:27] <slangasek> site-packages, not dist-packages? :(
[15:27] <Tonio_> ogra: hehe :)
[15:27] <pitti> slangasek: right
[15:27] <ogra> Tonio_, btw, i think i saw you on german TV recently
[15:27] <ogra> in a report about FOSDEM
[15:27] <pitti> there was a previous upload to correct this, but apparently it doesn't work any more
[15:27] <Tonio_> ogra: hu ?? ah !
[15:28] <Tonio_> with my broken foot ?
[15:28] <ogra> what did you do with your leg ?:)
[15:28] <ogra> ouch
[15:28] <Tonio_> ogra: during FOSDEM, my left  foot was brone
[15:28] <Tonio_> broken
[15:28] <slangasek> pitti: does gnome-applets use the python.m4 from automake to detect python paths?
[15:28] <ogra> yeah, i noticed something was wrong with it
[15:29] <pitti> slangasek: I don't know, I'm working on launchpad-integration
[15:29] <slangasek> oh
[15:29] <slangasek> pitti: does lpi "" "" "" ? :)
[15:29] <Tonio_> ogra: everything's fine now, hopefully
[15:29] <pitti> there's no python.m4 in the code anyway
[15:29] <ogra> great :)
[15:29] <slangasek> pitti: are there python path checks in a configure script?
[15:30] <pitti> and no hits with grep for python.m4
[15:30] <slangasek> pitti: what I'm getting at is that aclocal had a buggy macro before which has only now been fixed, so re-autotools might fix this
[15:30] <slangasek> and smell better than hard-coding a hack in debian/rules
[15:30] <pitti> slangasek: ah, I'm still installing today's upgrades (I just started with python)
[15:30] <pitti> there's a new automake etc. coming in
[15:31] <pitti> slangasek: I'm doing full autoreconf anyway, bzr only has the .am/configure.in bits
[15:31] <slangasek> ok
[15:38] <calc> ogra: pong
[15:38] <pitti> seems that was it; yet another example why I advocate debian/patches/99autotools.patch instead of doing it at build time
[15:39] <ogra> calc, is see http://paste.ubuntu.com/150705/ on my systems ... while that doesnt make dpkg fail, it enforces update-manager to open the details window ...
[15:39] <doko> pitti: the aclocal.m4 needs to be regenerated
[15:39] <pitti> right, it's working now after dist-upgrade
[15:42] <pitti> slangasek: launchpad-integration uploaded for bug 353503
[15:42] <slangasek> pitti: ack; post-RC
[15:42] <pitti> *nod*
[15:43] <calc> ogra: hmm thats very strange i didn't change anything regarding that between 9ubuntu2 and 9ubuntu3
[15:44] <ogra> well, its a freshly installed system from before easter, geeting its first upgrade run today
[15:44] <slangasek> calc: the espa-nol you had me sync had an unsatisfiable build-dep :(
[15:45] <Keybuk> pitti: is the core file not in the .crash file?
[15:46] <pitti> Keybuk: it is
[15:46] <pitti> Keybuk: if you have a .crash file, you can use apport-unpack to get it
[15:46] <Keybuk> oh there it is, encoded in an rfc822 header :p
[15:46] <slangasek> content-type: ELF/multipart
[15:47] <Keybuk> pitti: great, thanks
[15:48] <tseliot> pitti: would this change in nvidia-common break jockey? http://launchpadlibrarian.net/25455321/nvidia-common_0.2.10.debdiff  (bug #303825)
[15:49] <Keybuk> pitti: we should probably teach apport about upstart's strange core dump behaviour
[15:49] <Keybuk> pitti: or does it know about it already?
[15:50] <pitti> tseliot: from a first look, it shouldn't
[15:50] <pitti> Keybuk: it doesn't special-case upstart in any way right now; what should it do?
[15:50] <Keybuk> pitti: Upstart will always crash in a syscall to sigprocmask() in the crash_handler() function
[15:50] <Keybuk> it basically catches the SEGV, and lets a child process crash on its behalf
[15:50] <Keybuk> so the real cause of the crash is whatever was happening when the SEGV signal handler ran
[15:51] <pitti> Keybuk: so you want it to unwind the stack trace until that point for dup detection?
[15:51] <Keybuk> yeah
[15:51] <pitti> Keybuk: apport already does stack unwinding for some situations
[15:51] <tseliot> pitti: ok, thanks, I'll make an SRU then
[15:51] <Keybuk> if you look at bug #358915 it looks like it picked on the top-level function called from the main loop
[15:51] <Keybuk> rather than the real function
[15:52] <calc> slangasek: ah crap :( will look at it after i get my report written (~ 10m)
[15:52] <slangasek> calc: I've already uploaded what should be a fix
[15:52] <slangasek> just waiting for another release teamer to review it
[15:52] <Keybuk> admittedly, I can find no reason *WHY* this crashed from this core file
[15:52] <Keybuk> but it's always worth making back traces nicer :p
[15:52] <slangasek> (actually, probably waiting until after RC)
[15:53] <calc> slangasek: ok sorry for the problem :(
[15:54] <ogra> ogra@osiris:~/Devel$ free
[15:54] <ogra>              total       used       free     shared    buffers     cached
[15:54] <ogra> Mem:       3087916    2993664      94252          0      34624    1902964
[15:54] <ogra> -/+ buffers/cache:    1056076    2031840
[15:54] <ogra> Swap:      4803392    4803384          8
[15:55]  * ogra screatches head what the hell uses all that swap on his system
[15:55] <pitti> Keybuk: so where in http://launchpadlibrarian.net/25186204/Stacktrace.txt should it unwind to, for StacktraceTop?
[15:55] <ogra> i dont run anything special ... evo, ff, four terminals and xchat
[15:56]  * slangasek giggles
[15:56] <Keybuk> #3  job_change_goal (job=0x7f70bacdb1e0, goal=JOB_STOP,
[15:56] <Keybuk>     emission=0x7f70bacd8ff0) at job.c:703
[15:56] <Keybuk> 	__FUNCTION__ = "job_change_goal"
[15:56] <Keybuk> pitti: that's the "crashing" function
[15:56] <slangasek> ogra: I think it's probably evo, ff, and xchat
[15:56] <Keybuk> the one immediately below the "<signal handler called>" thing
[15:56] <pitti> I think in the past I considered unwinding to <signal handler called>
[15:57] <ogra> slangasek, well, top reports X and ff with around 400M VIRT usage each ... the rest of the processes looks relatively calm
[15:57] <pitti> but I didn't do it, since with that we'd miss crashes in signal handlers
[15:57] <pitti> (although that's much less likely)
[15:57] <ogra> nothing in the three digit area
[15:57] <Keybuk> pitti: makes sense; this is somewhat upstart-magic since it *catches* SIGSEGV <g>
[15:57] <Keybuk> very few programs do that
[15:58] <slangasek> ogra: tmpfs?  sysv shm?
[15:59] <pitti> Keybuk: what I'd like to see is package hooks being able to specify further unwinding; that keeps the facility general
[15:59] <pitti> Keybuk: perhaps you can open a bug against apport with this example, and how the StacktraceTop should look like?
[15:59] <Keybuk> pitti: sure
[16:00] <ogra> ogra@osiris:~/Devel$ df -h|grep tmp
[16:00] <ogra> tmpfs                 1,5G     0  1,5G   0% /lib/init/rw
[16:00] <ogra> tmpfs                 1,5G  8,2M  1,5G   1% /dev/shm
[16:00] <ogra> looks calm as well
[16:00] <ogra> killing evo got me 34M back from my swap
[16:01] <ogra> killing FF only got me 1M more free space
[16:01] <ogra> hrm
[16:02] <Keybuk> how much video memory do you have?
[16:02] <ogra> its my lappie with intel card ... so none actually ... in BIOS 128M (maximum) shared videoram are set
[16:05] <ogra> ok, closing everything but one gnome-terminal and xchat still only gets me 42M free
[16:05] <ogra> i start to suspect the intel driver leaks somewhere
[16:06] <ogra> that would also explain why i see system lockups after several days without any trace in any logs
[16:06] <ogra> simply because i hit OOM
[16:11] <Keybuk> so 128M of X's memory will be that
[16:12] <ogra> yes, but what is eating 4G of swap
[16:12] <ogra> on a system only having xchat and a terminal open
[16:13] <ogra> opening and closing evo doesnt really show a change in that footprint ... same goes for FF
[16:14] <ogra> Mem:   3087916k total,  2969868k used,   118048k free,    70652k buffers
[16:14] <ogra> Swap:  4803392k total,  4774848k used,    28544k free,  2373076k cached
[16:15] <ogra> oh !
[16:15]  * ogra just notices he is running metacity while he ran compiz earlier today
[16:15] <ogra> looks like it switched
[16:18] <ogra> Mem:   3087916k total,  1409668k used,  1678248k free,    75592k buffers
[16:18] <ogra> Swap:  4803392k total,     9972k used,  4793420k free,  1073884k cached
[16:18] <ogra> hmm
[16:18] <ogra> switching compiz back on crashed X immediately ... now my swap is freed up
[16:21] <slangasek> superm1: are you adding a conflicts to mythbuntu?  I think that's the only thing blocking a reroll of mythbuntu images at the moment (assuming the X bugs aren't getting more love before RC...)
[16:25]  * cjwatson successfully installs to a virtio device. Nice ...
[16:27] <superm1> slangasek, if i add it, it will be right after RC.  i need to make sure it actually works in a chroot yet, but that won't be until later today
[16:27] <ogra> mumble
[16:27] <slangasek> superm1: ok, so I should go ahead with mythbuntu RC rolling?
[16:27] <superm1> slangasek, but otherwise wubi bug has been fixed, so rerolls are fine
[16:27] <superm1> yeah
[16:43] <cody-somerville> How is Ubuntu handling X's poor auto-detection of DPI?
[16:44] <seb128> it forces 96 dpi
[16:45] <cody-somerville> Okay, thanks.
[16:45] <cjwatson> ah, yes, if Xubuntu isn't doing that then that would explain the installer difference
[16:45]  * cody-somerville nods.
[16:45] <cody-somerville> superm1, ^^ You might be interested in doing the same.
[16:48] <superm1> cody-somerville, yeah we are forcing 100dpi actually (since the most common case for us is TVs)
[16:48] <cody-somerville> Okay.
[16:48] <superm1> we're doing it via our gdm-cdd.conf.
[16:48] <superm1> we did however get a complaint about doing it this way, that on displays that are supposed to have rectangular pixels, they are square
[16:49] <superm1> bug 151310 i believe
[17:04] <slangasek> Keybuk: hmm, but bootchart-java has other deps that aren't (and never have been) in main; is pybootchartgui really that bad?
[17:06] <Keybuk> slangasek: I prefer the -java output
[17:06] <Keybuk> slangasek: though if those deps were not in main, how was bootchart in main previously?
[17:06] <slangasek> I don't know
[17:06] <Keybuk> or has somebody promoted bootchart to main without an MIR?
[17:07] <slangasek> the intrepid version didn't dep on them
[17:07] <Keybuk> what are the deps?
[17:07] <Keybuk> java build system changes perhaps?
[17:07] <slangasek> libcommons-cli-java, libcommons-compress-java
[17:07] <slangasek> maybe
[17:12] <calc> StevenK: stick it in a large bag of rice ;-)
[17:13]  * calc would probably completely disassemble it and manually dry and then stick it in rice like the other poster mentioned :)
[17:14] <Keybuk> slangasek: it's honestly a surprise to me that bootchart is in main ;)
[17:14] <slangasek> Keybuk: been there since dapper or earlier; but if you think that's /wrong/, demoting it is a real easy fix for the component-mismatches pain. :)
[17:14] <Keybuk> looks like Tollef did an initial MIR for it way back in the day
[17:15] <Keybuk> I think that it's ok to be in universe, it's not something we install by default
[17:16]  * Keybuk is not a subscriber to main-or-bust
[17:17] <ogra> but please make -java the default dep
[17:30] <rgreening> bug 361185 requires ack
[17:41] <cody-somerville> What can cause SIGUSR2?
[17:42] <geser> kill -s USR2
[17:42] <cody-somerville> Thats odd because I'm seeing a crash in the Live CD when clicking the logout button with SIGUSR2 in Xubuntu
[17:44] <geser> I don't know if any other reason exist that such a signal might get send
[17:56] <cjwatson> Seeker`: what does it take to get the logs at http://www.novarata.net/mootbot/ updated? Is it just a manual rsync or something? If so, could you please do one (if you're still the right contact for mootbot maintenance)?
[17:57] <cjwatson> Seeker`: I've been waiting for logs from a meeting on 4 April to appear there so that I can write up minutes with reference to them
[18:03] <Seeker`> cjwatson: will give the relvant person a prod
[18:08] <superm1> slangasek, if a solution isn't identified for the intel freezes and mythtv segfaults, will reverting to mesa 7.3 be out of the question before jaunty at this point?
[18:08] <slangasek> superm1: a full revert would not be my first choice, but if necessary we could look at it
[18:09] <superm1> slangasek, okay.  i'm going to attempt a second bisection then at least to identify a second round of commits that are bad (i've got one set so far)
[18:24] <cjwatson> Seeker`: thanks. For future reference, whom should I talk to?
[18:28] <jpds> cjwatson: nalioth runs the server.
[18:28] <cjwatson> aha, thanks
[18:34] <cjwatson> TheMuso: do you understand bug 360530? dm-raid45 does seem to be added to the initramfs
[18:49] <_2eXtreme> hey guys, with regards to risk management, can anyone give me a few examples of risks that would arise in a development project that you are working on by yourself? im writing a report for a personal project, and i need to get some examples of what risks are so that i can get an idea of what a risk is, and then identify the ones i have encountered. please help, i dont know anything about risk management, but i ne
[18:52] <directhex> _2eXtreme, risk: getting sued by microsoft for patent violation
[18:54] <_2eXtreme> directhex, am i right in thinking that risk management is one of things where you just write a load of b***s**t, like one of the boring business sides of software dev that no one really cares about?
[18:54] <directhex> _2eXtreme, bingo!
[18:54] <directhex> _2eXtreme, and bill the client for £180 an hour, that's an important step
[18:55] <_2eXtreme> directhex, can i say taht a change in requirements could be one?
[18:57] <directhex> _2eXtreme, yes, especially late in development
[18:57] <_2eXtreme> directhex, cool, so, are there any websites that sort of...tell you about example risks?
[19:01] <ebroder> How do the Ubuntu buildds get at the .ddeb before the build chroot is thrown away, if it doesn't get added to the .changes file?
[19:11] <cjwatson> ebroder: I believe it's just copied out by hand at the end of the build; it would need to be added to the .changes file if .ddebs were processed by Soyuz, but they aren't
[19:11]  * ebroder nods
[19:12] <infinity> ebroder: It's a violent and hideous hack best not described.
[19:12] <infinity> ebroder: But, yes, the ultimate goal is to make soyuz accept them as part of the upload, and then they'll be added to .changes.
[20:26] <martinw> christel: you said quite a few times in public that you are quite happy that you know young, male lawyers who are falling for you. you said your mom told you it would be smart to be a little bit flirty with them
[20:26] <martinw> christel: and i think its quite obviousy why that is quite smart, when you and your staffy friends dont stick to your own policy.
[20:26] <martinw> christel: you make Freenode be your own little dating site
[20:26] <martinw> its a shame
[20:30] <hyperair> martinw: /me doesn't see anything said by christel.
[20:30] <martinw> sabdfl: i hope you are proud to invest money in form of donations to a hobby like Freenode. Rob Levin wanted this network to be different than other IRC networks and dedicated to Free Software
[20:31] <martinw> but what current staffers made of this is a shame, really
[20:31] <hyperair> martinw: exactly what are you talking about?
[20:31] <martinw> sabdfl: maybe we get a live interview some day that show what unethical behaviour you supported
[20:32] <martinw> and what you have in mind to justify it
[20:32] <hyperair> !ops
[20:32] <martinw> i am very curious
[20:33] <bizkut> where2
[20:36] <ebroder> Anyone from the security team who could look at bug #356861? These vulnerabilities have been in the wild for over a week now
[20:38] <kees> ebroder: yup, know about.  if anyone is prepared to do the patching and testing, we'd be happy to publish updates.
[20:38] <ebroder> kees: We have patches for Hardy, Intrepid, and Jaunty
[20:38] <ebroder> Although Anders and I would both prefer to see 1.4.10 synced in for Jaunty, if that's possible
[20:39] <ebroder> Hmm...did Anders post an actual patch for Intrepid? I can generate one if he didn't
[20:40] <ebroder> I guess not. I'll do that now
[20:40] <kees> ebroder: it's very late in the release cycle, you'll need to get a freeze exception.  https://wiki.ubuntu.com/FinalFreeze
[20:40] <kees> ebroder: as for the others, please see https://wiki.ubuntu.com/SecurityUpdateProcedures (once patches exist, marking it as "In Progress")
[20:41] <ebroder> kees: Ok, thanks
[20:46] <ebroder> kees: If we just take 1.4.9 in Jaunty instead of 1.4.10, do you still need the debdiff or can that be done as a sync from Debian?
[20:48] <ebroder> Oh, hmm...1.4.9 seems to have been booted out by 1.4.10. Never mind
[20:48] <kees> ebroder: if you want to fix it in jaunty with a patch (like done for intrepid, hardy, dapper), that's fine.  if you want 1.4.10, you'll need to go through feature freeze and final freeze exceptions with approval from the motu-release team.
[20:58] <andersk> How likely is such an exception to be approved?  I assumed not very likely, which is why I posted a minimal 1.4.9 package.
[21:17] <RicardoPerez> slangasek: Hi! Too late for a very simple patch to fix an i18n issue?
[21:17] <slangasek> RicardoPerez: too late for RC; for final, it will depend on how simple
[21:17] <RicardoPerez> slangasek: it's a oneliner. the bug is #361312
[21:18] <RicardoPerez> (sorry, bug #361312)
[21:18] <RicardoPerez> very very simple, as you can see
[21:19] <slangasek> yes, that looks appropriate, either for post-RC or for an SRU
[21:19] <RicardoPerez> slangasek: great news :)
[21:20] <RicardoPerez> I don't know if I need to assign a developer & status
[21:21] <NCommander> slangasek, we're doing a minor seed change in Xubuntu to close #278763 and I'd like to run the seed diff by you just to make sure its alright so we don't need to worry about breaking Xubuntu so close to release: http://paste.ubuntu.com/151041/
[21:22] <slangasek> RicardoPerez: if you need an uploader for it, then you need to subscribe ubuntu-main-sponsors
[21:22] <RicardoPerez> slangasek: Ok, I'll do that just now
[21:23] <RicardoPerez> slangasek: thanks a lot, cheers
[21:29] <slangasek> NCommander: given that these transitional packages all exist and are usable, I don't see that this change is really warranted this late
[21:30] <NCommander> slangasek, fair enough, I'll slate the change for karmic
[21:30] <slangasek> NCommander: it would be good if when karmic opens, we can get a solution to the fact that core-dev don't have commit access to the xubuntu seeds, so that we can get changes merged over in a timely fashion
[21:31] <NCommander> slangasek, xubuntu seeds are managed by the xubuntu-devel team
[21:31] <slangasek> yes, they are
[21:31] <NCommander> They were changed mid-intrepid to lp:~xubuntu-dev/ubuntu-seeds/xubuntu.jaunty
[21:31] <slangasek> and they're not tracking the changes in the ubuntu seed, where this change was made months ago
[21:32] <slangasek> those are changes I would push out with my RM hat on, if I could commit to the seed
[21:34]  * NCommander just realized I read what you originally said backward
[21:34] <NCommander> *sigh*
[21:52] <ebroder> Anyone from motu-release around? How likely are we to get a freeze exception to sync in 1.4.10 of openafs from Debian? (for bug #356861)
[21:55] <jpds> ebroder: You might want to subscribe motu-release to the bug.
[21:55] <kees> ebroder: and check with #ubuntu-motu
[21:57] <ebroder> Sure - I'm just trying to get a sense of which way I should push the bug. I'll ask #ubuntu-motu
[21:57] <philsf> I have some spare time now, if any devel wants to test something for Jaunty
[22:36] <siretart> bryce: have you considered downgrading the intel driver to the 2.4 branch for jaunty?
[22:37] <siretart> bryce: I've compiled it locally for me, and I feel it behaves much better than 2.6 branch in jaunty. and even in fact better than the 2.7 one.
[22:38] <bryce> siretart: have you read the IntelPerformance page I wrote?
[22:38] <siretart> bryce: no, where can I read about it?
[22:38] <bryce> siretart: also did you know we're in FinalFreeze, so even if we wanted to do that, it couldn't be done?
[22:38] <bryce> see the Ubuntu-X wiki, it's linked from the Troubleshooting section
[22:38] <siretart> bryce: I'm imagining a new package 'xserver-intel-xorg-intel-2.4' that conflicts/replaces the intel driver in some PPA
[22:39] <bryce> siretart: feel free to set something up
[22:39] <siretart> https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance
[22:39] <siretart> bryce: I think I have such a package ready..
[22:40] <bryce> please add a link to your ppa from that wiki page, in a new section on reverting to 2.4
[22:41] <siretart> hm. I haven't tried this in intrepid, so I cannot say if it's a regression, but...
[22:41] <siretart> ... when enabling compositing in metacity, moving a gnome-terminal window (and only gnome-terminal) is unbelievably slow
[22:41] <siretart> is that known/expected?
[22:42] <bryce> you could check launchpad but it's not an issue I've heard before
[22:42] <bryce> although I think not so many people use metacity+compositing yet
[22:42] <walters> siretart: do you have the transparent background enabled?
[22:43] <bryce> in general composite on intel seems to have a performance regression, so perhaps that's it
[22:43] <siretart> walters: no
[22:43] <siretart> I know it was fine with compiz
[22:44] <siretart> but for some reason, compiz doesn't love me anymore in jaunty :( - still investigating that
[22:45] <bryce> siretart: most tricks and tips and workarounds we know of are listed on that wiki page fwiw
[22:48] <siretart> reading that page now...
[23:17] <siretart> bryce: okay, I've just uploaded my xserver-xorg-video-intel-2.4_2.4.1-1ubuntu11~ppa1_source.changes package to my ppa - pending publishing
[23:17] <siretart> I'll head of to bed right now, I'll do some more testing tomorrow
[23:18] <bryce> ok cool
[23:18] <bryce> siretart: don't forget to update the wiki page with info on your package, so others can make use of it
[23:19] <bryce> I pretty much point everyone that complains about intel performance issues to that page, so that way they'll find your packages easily
[23:19] <bryce> siretart: thanks for putting that backport together
[23:19] <siretart> that's rather a forward port than a backport, no? ;-)
[23:20] <siretart> bryce: btw, I had to add 2 patches to get that beast built against libdrm 2.4.5...
[23:21] <bryce> true, forward port ;-)
[23:21] <bryce> siretart: not surprising
[23:21] <siretart> wow
[23:21] <siretart> I managed to get compiz started
[23:22] <siretart> and moving gnome-terminal is as expected. only metacity's compositing manager breaks it
[23:22] <siretart> s/breaks/makes it unusable/
[23:22] <siretart> HA! same performance as in intrepid again. yay
[23:24] <siretart> even planetpenguin is playable, though it's better without compiz
[23:24] <siretart> anyway, I can sleep now tightly. cu tomorrow!
[23:29] <TheMuso> cjwatson: that doesn't appear to be a dmraid bug to me, it looks like its something to do with mdadm.
[23:31] <cjwatson> TheMuso: I initially made it mdadm, but the nvidia_blah stuff in the error message looks like dmraid, and mdadm doesn't seem to do anything with raid45 (only raid456)
[23:32] <TheMuso> cjwatson: hrm ok, will take another look. I find it kinda hard to work with screenshots.
[23:34] <TheMuso> cjwatson: in the modules screenshot I don't see raid45, and if it were for dmraid it would be dm-raid4-5
[23:37] <neruda> any plans for a vmware image?  I tried to virtualize 8.0.4 (64bit) with vmware server and found out the hard way that vmware cripples all of its free products?
[23:37] <neruda> ?=!
[23:39] <cjwatson> TheMuso: it's not in the modules screenshot, but the "CRW_1325.jpg" attachment shows a screenful of these two errors repeated:
[23:39] <cjwatson> TheMuso: device-mapper: table: 252:0: raid45: unknown target type
[23:39] <cjwatson> TheMuso: device-mapper: ioctl: error adding target to table
[23:40] <cjwatson> TheMuso: and then at the end: device-mapper: ioctl: unable to remove open device nvidia_ddbfdieb
[23:40] <cjwatson> TheMuso: so that seems to be the most immediate problem
[23:40] <cjwatson> TheMuso: "raid45" does show up in dmraid's source ...
[23:46] <TheMuso> hrm ok, I need to find out whether he chose to use a dmraid array at install time and some info about the array.
[23:46] <TheMuso> cjwatson: thanks for that