[00:13] <statik> hi slangasek, i'm searching for a sponsor for this couchdb patch, any chance it's something you could help with? https://bugs.edge.launchpad.net/ubuntu/+source/couchdb/+bug/439499
[00:33] <slangasek> statik: happy to
[00:44] <slangasek> statik: I wonder why there's a VERSION= token in couchdb-bin.postrm at all, it's completely unused...
[00:47] <statik> slangasek, huh that might be a leftover
[00:47] <statik> thanks for your help
[01:15] <natewiebe13> im getting "[Firmware Bug]: ACPI : Invalid BIOS _PSS frequency : 0x0 MHz" from beta.. anyone know why? both on live and alternate
[01:23] <cyberix_> I read about Debian's plans for going multi-arch
[01:23] <cyberix_> I suppose this means Ubuntu will go too, as changing all the packages would be insane
[01:24] <cyberix_> So, what I'm worrying about is, how the transition will go
[01:24] <ion> https://wiki.ubuntu.com/MultiarchSpec
[01:25] <cyberix_> thank you
[01:38] <slangasek> huh, there's somewhere that one can read about Debian's plans for multiarch? :)
[01:38] <slangasek> (that doesn't point back at the Ubuntu wiki page? :)
[01:40] <LaserJock> I wonder how much need there is for multiarch these days
[01:41] <slangasek> plenty
[01:42] <slangasek> people still use 32-bit flash, and that depends on ia32-libs, and ia32-libs is a festering boil
[01:42] <LaserJock> I thought the demand was mostly for things like Flash and java
[01:42] <slangasek> that's the primary desktop case, yes
[01:42] <LaserJock> but isn't there 64bit flash coming down the pike?
[01:42] <slangasek> maybe someday
[01:43] <slangasek> oh, and wine is all 32-bit, too
[01:43] <LaserJock> I don't know, I just remember it being such a pain to have amd64 and now I hardly notice the difference
[01:43] <LaserJock> although that could be because of ia32-libs
[01:44] <TheMuso> Skype is also 32-bit, and likely will only be so for a while.
[01:44] <slangasek> popcon says ia32-libs is the 2179th most popular Ubuntu package
[01:44] <Amaranth> LaserJock: 10.1 should have official support for 64-bit on linux, windows, and OS X
[01:44] <slangasek> and the single largest :-P
[01:45] <Amaranth> LaserJock: but they aren't even to a beta of that yet
[01:45] <slangasek> cyberix_: so where were you reading about multiarch?
[01:45] <LaserJock> slangasek: really, that big?
[01:45] <slangasek> LaserJock: you really don't know what goes into ia32-libs, do you :)
[01:45] <LaserJock> I do, but I didn't think it was *that* much
[01:46] <slangasek> 553M	/home/lp_archive/ubuntu/pool/universe/i/ia32-libs/ia32-libs_2.7ubuntu15.tar.gz
[01:46] <Amaranth> LaserJock: ia32-libs is basically a copy of GTK+ and everything in the stack below that
[01:46] <slangasek> Amaranth: and pulseaudio, and...
[01:46] <Amaranth> oh, and pulseaudio
[01:46] <Amaranth> yeah
[01:46] <Amaranth> pain
[01:46] <Amaranth> 64-bit users without 5mbit broadband need not apply
[01:47] <slangasek> the .deb is only 29MB
[01:47] <Amaranth> really?
[01:47] <slangasek> but the source tarball has to include all the sources
[01:47] <slangasek> it's just impossible to *maintain*, because it's the equivalent of having to upload an ISO
[01:48] <Amaranth> yeah, that'd be an all day event for me
[01:48] <LaserJock> yeah
[01:48] <TheMuso> I hope I never have to touch that hunk of junk again. :)
[01:49] <TheMuso> Its about a 3-4 hour upload for me at least, if not longer.
[01:50] <JanC> adobe's 64-bit alpha flash plugin is more "stable" than their stable 32-bit plugin  :P
[01:51] <slangasek> shtylman: in bug #424132 you said you would poke the dev if this wasn't fixed by alpha6... any updates there?
[01:51] <Amaranth> JanC: Except for all the people who get segfaults when it loads
[01:51] <JanC> Amaranth: eh?
[01:51] <JanC> never seen that  ツ
[01:52] <JanC> actually, never heard about that
[01:53] <JanC> Amaranth: is it related to certain hardware or such?
[01:53] <Amaranth> no idea
[01:55] <shtylman> slangasek: unfortunately no... points 1 and 2 I fixed, but still unable to track down why nothing has no next. The last three points I believe to be related.
[01:56] <shtylman> slangasek: I have asked several developers and we still have no fix
[01:56] <shtylman> slangasek: the interesting thing is that text *does* appear when using something other than the oxygen style
[01:56] <shtylman> slangasek: but that doesn't fix the new folder bug and other issues not listen on that report
[01:56] <slangasek> shtylman: ok.  are you still taking responsibility for this (as you're assigned), and can you perhaps follow up to the bug with information about the current status?
[01:57] <shtylman> slangasek: will do... I will read through the bug report and see what I can comment on and what has been addressed
[01:57] <slangasek> shtylman: cheers
[02:35] <kirkland> slangasek: StevenK: hi guys... could one of you please spin a new server daily iso immediately?
[02:37] <slangasek> kirkland: spinning
[02:38] <slangasek> kirkland: why "immediately", btw?  if you were waiting for package publishing, note that we can track that on our side
[02:38] <mathiaz> slangasek: right
[02:39] <mathiaz> slangasek: a new eucalyptus package has been uploaded - we'd like to have it included on the next isso
[02:39] <mathiaz> slangasek: so I think we need to wait for the new package to be published
[02:39] <slangasek> ok, so the build I've just started is useless? :)
[02:39] <mathiaz> slangasek: 1.6~bzr916-0ubuntu1
[02:40] <mathiaz> slangasek: I have the regret to announce that this is probably the case
[02:40] <kirkland> slangasek: whoops, sorry
[02:40] <kirkland> slangasek: i got triggerhappy
[02:40] <slangasek> right; queueing up another build against 916 instead
[02:42] <kirkland> slangasek: sorry for the inconvenience
[02:43] <slangasek> I'll relay your apologies to the build server
[03:31] <LaserJock> where is the CD boot menu items determined?
[03:36] <TheMuso> LaserJock: I think gfxboot-theme-ubuntu is probably what takes care of that.
[04:01] <cyberix_> LaserJock: I think Debian's original multiarch proposal states that the spec isn't only about hardware architectures, but about software architectures as well
[04:02] <cyberix_> LaserJock: I recall them mentioning support for Windows executables or something
[04:02] <cyberix_> wild dreams, might be
[04:02] <cyberix_> but maybe part of it makes sense
[04:03] <cyberix_> they are also talking about emulating hardware
[04:04] <cyberix_> so eventually you could have a package that supports running PowerPC or Gameboy applications :-D
[04:05] <cyberix_> The page in Ubuntu Wiki says: "Ubuntu 9.10 introduces support for installing packages from multiple architectures on a single system. This makes a wider array of 32-bit applications available to users of 64-bit Ubuntu."
[04:05] <cyberix_> How accurate is this?
[04:06] <cyberix_> I mean, I see no marks of the specification being applied to current beta release of 9.10
[04:06] <cyberix_> s/marks/signs/
[04:07] <TheMuso> cyberix_: Its not going into 9.10
[04:08] <cyberix_> TheMuso: That is the impression I got, but I'm not sure if that sentence refers to something else
[04:10] <ScottK> It was planned at one point.
[04:12] <cyberix_> so should we change that to 10.04 then
[04:14] <ScottK> I'd leave it for the guy that has to deal with it.
[04:14] <cyberix_> ok
[04:14] <cyberix_> I'll get some sleep for a change
[04:14] <cyberix_> good night
[04:24] <slangasek> kirkland, mathiaz: ISO built
[04:38] <smoser> can someone please approve my mail to ubuntu-devel (Subject: size of uec images)
[05:12] <kirkland> slangasek: got it, thanks
[05:25] <mathiaz> slangasek: could you have a look at bug 445714?
[07:02]  * spaetz sighs. It seems that brightness special keys will be broken in karmic for quite a few models
[07:13] <tgpraveen> is KMS there for ATI cards or not?
[07:26] <mohanohi> hi..
[07:26] <mohanohi> whats the package name for The Color transformation Language in ubuntu?
[07:33] <pitti> Good morning
[07:33] <mohanohi> whats the package name for The Color transformation Language in ubuntu?
[07:37] <pwnguin> colorfilter?
[07:38] <pwnguin> or are you referring to the language it uses? cuz that's pure shader langage
[07:39] <mohanohi> pwnguin: yeah..
[07:39] <mohanohi> pwnguin: ramenhdr uses it..
[07:40] <mohanohi> pwnguin: i have downloaded the source package
[07:40] <mohanohi> pwnguin: but donno where to extract it in my ubuntu OS..
[07:40] <pwnguin> oh i like this already
[07:41] <mohanohi> pwnguin: what?!!?
[07:41] <mohanohi> pwnguin: is the package in ubuntu?
[07:41] <pwnguin> no, just reading the homepage
[07:42] <dholbach> good morning
[07:42] <mohanohi> pwnguin: ok.. can you tell me where to extract the header files and library files
[07:43] <pwnguin> for ramenhdr?
[07:43] <pwnguin> holy crap. i like it, but those build deps are wild
[07:44] <mohanohi> pwnguin: yeah...
[07:44] <pwnguin> intel tbb is probably a blocker
[07:45] <pwnguin> or
[07:45] <pwnguin> its packaged and older than i think
[07:46] <pwnguin> mohanohi: since this isn't directly related to ubuntu core development, perhaps we should move the conversation to #ubuntu-motu?
[07:46] <mneptok> !info libtbb-dev
[07:46] <mneptok> !info libtbb2
[07:46] <mneptok> ^^^^^^^
[07:46] <pwnguin> good to know
[07:47] <pwnguin> should be fine then. development / library headers generally end with -dev
[07:51] <mohanohi> pwnguin: i am in ubuntu-motu
[08:26] <siretart`> morning
[08:26] <siretart`> lool: are you working on the armel/neon patches for ffmpeg? or are you aware of someone working on them?
[08:29] <siretart`> bug 383240 for reference
[08:36] <ogra> siretart, lool is travelling today (and might have coppy internet over the weekend until monday)
[08:37] <mvo> uff, gettext has a recommends on cvs now
[08:38]  * mvo reads bug #506022
[09:00] <liw> mvo, uh, say what? oh, and it's a debian bug
[09:11] <pitti> Keybuk: good morning
[09:12] <pitti> Keybuk: you said that your bug mailbox is overflowing, so please excuse the IRC ping: just posted a question for you in bug 439138 comment 67
[09:23] <geser> pitti: Hi. Does the DMB already also MOTU applications or will this be merged in the future and the MC is still responsible (for now)?
[09:23] <pitti> geser: I think the latter, but I'm not really sure
[09:23] <pitti> dholbach: ^ do you know?
[09:24] <cjwatson> pitti,geser: the latter
[09:57] <mdz> pitti, what can I do to help diagnose bug 445846
[09:58] <pitti> mdz: I think I know what's going on, but I'd like you to confirm; I just replied to the bug
[09:58] <pitti> mdz: so if you could check the gconftool line I gave you, that will do it (and also the command to unset it, and then try again if it works then)
[11:05] <Riddell> kees: the  upstream fix for koffice is to remove pdf import so I've done that in karmic
[11:11] <Keybuk> pitti: no, you can't, but you shouldn't need to
[11:11] <Keybuk> that bug is full of people misinterpreting the problem
[11:15] <Keybuk> and it has nothing to do with console-setup
[11:23] <Keybuk> so far the bug can be summarised by "adding dependency on $RANDOM_THING_THAT_TAKES_SOME_TIME solves the problem for me!"
[11:23] <Keybuk> you may as well solve it by sticking "sleep 60" in there somewhere
[11:24] <Keybuk> at some point, maybe even today, I'm going to sit down - read the X source, and figure out what it actually *really* needs
[11:24] <Keybuk> I'd hoped someone else would do that so I didn't have to, but meh
[11:28] <ogra> Keybuk, i had a very weird bug yesterday, due to having to test a jaunty kernel on a default karmic install, the ext4 FS didnt work 100%, mountall got in a constant reboot loop and i had no chance to get into the system anymore
[11:28] <ogra> (mountall called fsck, fsck died, system rebooted ... same game over and over)
[11:29] <Keybuk> it doesn't reboot it fsck dies
[11:29] <pitti> Keybuk: well, it's not that random; it loops on ioctl VT_ACTIVATE while the underlying console went away or was changed; I just don't understand what else would even touch vt7, we have a hackish patch in gdm to not use vt 1 to 6
[11:29] <Keybuk> it only reboots if fsck completes successfully after repairing the root fs
[11:29] <ogra> yes, and says its usual ************** REBOOT LINUX ***************
[11:29] <Keybuk> pitti: console-setup doesn't touch vt7
[11:29] <Keybuk> pitti: I can tell this without looking, because cjwatson wrote it, and he's smart
[11:29] <Keybuk> but since one should look
[11:30] <Keybuk> warcraft scott% grep ACTIVE /etc/default/console-setup
[11:30] <Keybuk> ACTIVE_CONSOLES="/dev/tty[1-6]"
[11:30] <ogra> Keybuk, right, but wouldnt it make sense to have mountall to respect some kind of kernel cmdline option so you can forcefully disable fsck ?
[11:30] <Keybuk> pitti: it honestly wouldn't surprise me if the real culprit turns out to be cryptsetup
[11:30] <ogra> Keybuk, the system was fine, the filesystem wasnt corrupt, my clock was wrong and the last mount time was in the future
[11:30] <Keybuk> or something else that's using "console owner" :)
[11:30] <Keybuk> (ie. it could be mountall)
[11:31] <Keybuk> ogra: if that was the case, you would have been given a shell, not rebooted
[11:31] <ogra> due to the fact that it couldnt be mounted (caused by fsck dying to early and rebooting) it got into that endless loop
[11:31] <pitti> Keybuk: hm, I have cryptsetup installed, but no encrypted partitions at all
[11:31] <ogra> i didnt get a shell
[11:31] <Keybuk> though maybe it shouldn't just reboot, but let you have a shell ;)
[11:31] <ogra> yes :)
[11:31] <Keybuk> pitti: that doesn't matter - if cryptsetup is run, it "steals" the console
[11:31] <ogra> thats what i mean
[11:31] <Keybuk> stealing the console while X is running can be bad
[11:31] <ogra> any way of mounting the disk to actually fix the stamp
[11:31] <pitti> ok
[11:32] <Keybuk> pitti: stealing the console is the only way I know to actually "hang up" a tty
[11:32] <Keybuk> opening it, writing to it, mucking around with it, etc. are all safe
[11:33] <Keybuk> but starting something that attempts to become the foreground process group for /dev/console, when vt7 is active (which X is the fg pg for) can go wrong
[11:33] <Keybuk> this is why "console" in Upstart is bad
[11:33] <pitti> Keybuk: so, I'll ask in the bug whether the reporters have cryptsetup installed, and I'll also test it here again
[11:33] <Keybuk> yeah
[11:33] <pitti> it's at least another data point
[11:33] <Keybuk> it needs some genuine debugging - please don't rush a fix to this one
[11:34] <Keybuk> lots of things will "appear" to solve it
[11:36] <pitti> Keybuk: the other obvious candidate is usplash, I guess?
[11:36] <pitti> (although that should be on vt8)
[11:42] <ogra> pitti, btw, was there a final decision if usplash gets enabled by default again ?
[11:42] <ogra> (/me needs to prepare an arm specific change if not, we surely want it there)
[11:43] <pitti> ogra: the most recent decision I'm aware of is still the one from UDS: let it run when required (cryptsetup et al) or after a timeout when X doesn't start fast enough
[11:43] <pitti> but right now it just seems to start unconditionally again
[11:44] <pitti> either that, or the timeout is working :) (can't say with my 85 second boot)
[11:44] <ogra> right, on armel we're about 8-10sec in the initramfs, its between 10 and 13secd until X comes up
[11:44] <ogra> and the vendor kernels spit out messages where we dont want to see any ...
[11:45] <ogra> so usplash is a clear yes for me on that arch
[11:45] <slangasek> pitti: it's not unconditional if you have cryptsetup installed...
[11:45] <pitti> ah, so that might be it
[11:45] <slangasek> (i.e.: "cryptsetup is installed" is the condition under which it runs)
[11:45] <pitti> well, I have crytpsetup, but no encrypted partitiosn
[11:46] <pitti> slangasek: I had thought that only the prompt would actually cause it to start up; but that might look bad indeed
[11:46] <slangasek> in theory it's possible to tweak the cryptsetup initramfs hook to not set USPLASH=yes unless needed
[11:46] <pitti> something for lucid perhaps
[11:46] <slangasek> but it looked hairy and I couldn't bring myself to work on it
[11:47] <pitti> it'd just be nice to be able to install cryptsetup by default again
[11:47] <cjwatson> pitti: in yesterday's foundations meeting, we decided to enable it by default for karmic and revisit for lucid; the action is mine
[11:47] <pitti> since it's useful for encrypted USB sticks and the like, even more so since we finally have a GUI tool to set them up
[11:47] <pitti> cjwatson: sounds like a safe approach for karmic, thansk
[11:47]  * ogra hugs cjwatson 
[11:48] <ogra> prevents me from adding ugly hacks :)
[11:48] <pitti> slangasek: we probably don't need to enable usplash on the fly during boot; making the USPLASH= value dependent on an empty/nonempty /etc/crypttab should be sufficient
[11:48] <pitti> but anyway, that's lucid beautification
[11:49] <slangasek> pitti: it wouldn't be enabled on the fly - we have enough information at initramfs generation time to tell us whether it's needed for the root fs
[11:49] <slangasek> except that the way the initramfs scripts are put together, we currently don't get that information until well after we've set USPLASH=yes :)
[11:51] <pitti> tseliot: would you mind re-owning lp:screen-resolution-extra to ubuntu-core-dev?
[11:52] <pitti> tseliot: I'd like to fix the policykit breakage (bug 435709), but I can't push to it
[11:52] <pitti> tseliot: I'd also add a proper Vcs-Bzr: tag
[11:52] <tseliot> pitti: sure
[11:55] <tseliot> pitti: I don't think I can as launchpad allows me to set the owner to either myself or to a team I'm a member of (and I'm not a core-dev)
[11:55] <pitti> tseliot: oh, perhaps just ubuntu-dev
[11:55] <pitti> should be fine for now
[11:57] <tseliot> pitti: I can't choose that either. Maybe if you add me to Jockey hackers I can set the group to that (just an idea) or we can use some other team
[11:57] <pitti> tseliot: oh, you aren't a MOTU?
[11:57] <tseliot> pitti: nope
[11:57] <pitti> whee, you really ought to
[11:57] <tseliot> yes, I know
[11:57] <tseliot> I'll apply for MOTU too then
[11:58] <pitti> tseliot: well, let me just push my branch to ~ubuntu-core-dev, and we merge back and forth, shall we?
[11:58] <tseliot> slangasek: did you have a look at my addition to the release notes (about DontZap)?
[11:58] <pitti> ~ubuntu-desktop would be more appropriate actually
[11:58] <tseliot> pitti: ok
[11:59] <slangasek> tseliot: not yet, I'm afraid; it's still on my todo list, however
[11:59] <slangasek> (release notes work starts in earnest this week)
[11:59] <pitti> tseliot: for testing, just calling ./policy-dontzap.py should give me the status, right? now it just hangs with changing the mouse cursor and doesn't do anything
[11:59] <tseliot> slangasek: ok, good
[12:00] <tseliot> pitti: make a backup of your xorg.conf and then type: python /usr/share/screen-resolution-extra/policyui.py 2048x2048
[12:00] <tseliot> don't use the dontzap code (as we don't use it in Ubuntu)
[12:00] <pitti> tseliot: oh, that works; (it's actually lying since on intel that's not necessary any more)
[12:01] <pitti> tseliot: right, I just looked for something to test the new policykit stuff, and ./policyui.py just hangs the same way
[12:01] <pitti> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.PolicyKit.AuthenticationAgent was not provided by any .service files
[12:01] <tseliot> pitti: gnome-display-properties decides whether it needs to call screen-resolution-extra or not
[12:01] <pitti> hah
[12:01] <pitti> tseliot: ok, that should do, thanks!
[12:01]  * tseliot can't reproduce the problem here... :-(
[12:02] <pitti> tseliot: oh, I know why it hangs; I tried ./policy-dontzap.py, it's executable, but doesn't have a hashbang line
[12:02] <pitti> tseliot: don't worry, I know the problem (you certainly have policykit-gnome installed)
[12:02] <pitti> tseliot: in fact, that exception was _exactly_ what I wanted )
[12:02] <tseliot> pitti: ah, very good then. Thanks for working on this
[12:04] <pitti> tseliot: pushing to lp:~ubuntu-desktop/screen-resolution-extra/ubuntu now; I'll let you know when you should pull into main
[12:05] <tseliot> pitti: ok
[12:07] <tseliot> pitti: maybe we should add a dependency on either policykit-1-gnome or on policykit-gnome to screen-resolution-extra
[12:07] <pitti> tseliot: yes, I'll do that (but I'll port it to pk-1)
[12:08] <tseliot> ok
[12:08] <tseliot> seb128: that should fix bug #446199
[12:08] <tseliot> ^^
[12:09] <tseliot> pitti: do you mind if I assign the bug to you (as you're working on it)?
[12:09] <pitti> done
[12:15] <tseliot> pitti: shall I pull your changes into main now?
[12:15] <pitti> tseliot: no, I just started; I'll ping you when they are done
[12:15] <tseliot> ah, ok, I was wondering what that "done" stood for
[12:23] <seb128> tseliot, pitti: thanks for fixing the display thing
[12:24] <ttx> pitti: about bug 439138, I experience it and I use cryptsetup. Can't disable it for testing though.
[12:26] <pitti> tseliot: hm, fun; your d-bus methods (setDontZap etc.) don't actually call _check_permission(), thus everyone can just call them without auth
[12:27] <tseliot> pitti: you can remove it if you want as it's really useless now
[12:27] <pitti> tseliot: no, that's actually a security bug..
[12:27] <tseliot> pitti: yes, I picked that up
[12:27] <pitti> tseliot: I want to fix it to actually use PK :)
[12:28] <tseliot> pitti: ok, maybe it's better to do that at this point
[12:29] <mvo> tseliot: have you heard of a problem like #439594 ?
[12:29] <pitti> tseliot: it's the only sensible point to check that
[12:29] <mvo> bug #439594
[12:30] <tseliot> let me check
[12:30] <mvo> tseliot: apparently when using fglrx while fglrx got upgraded
[12:31] <tseliot> mvo: oh, that's really something you should ask superm1 about
[12:32] <mvo> tseliot: ok, I may be able to setup a system to test this, but it is some work so I want to know more about it first :)
[12:34] <tseliot> mvo, pitti: also I was thinking that maybe I should remove nvidia-common's debconf interface from the kernel postinst and simply rely on Update Manager to migrate drivers (bug #292606). What do you think?
[12:35] <tseliot> users who dist-upgrade from the command line would be on their own though
[12:35] <pitti> tseliot: hm, not sure; I like people not getting messed up completely if they use aptitude or apt-get dist-upgrade
[12:35] <pitti> tseliot: does  it cause troubles?
[12:36] <tseliot> pitti: it looks like DKMS doesn't flush the stdout and causes nvidia-common to get an invalid reply about the driver it should recommend
[12:37]  * tseliot -> lunch
[12:52] <mvo> superm1: could you please let me know if you heard about bug #439594 or if you have a simple way to test this?
[12:54] <pitti> tseliot:  7 files changed, 57 insertions(+), 236 deletions(-)
[12:55] <pitti> tseliot:  :)
[13:03] <pitti> tseliot: done, please pull from lp:~ubuntu-desktop/screen-resolution-extra/ubuntu
[13:08] <mdz> pitti, since about yesterday, nautilus is opening PDF documents with gedit on my system, which doesn't work so well. evince is not even visible in "Open with...".  known issue?
[13:08] <mdz> in fact, .odp and .mp3 are being opened with gedit as well
[13:09] <james_w> https://edge.launchpad.net/ubuntu/+source/shared-mime-info/0.70-0ubuntu1 possibly?
[13:09] <happyaron> hi team, who can sync ibus and ibus-m17n? (pitti approved it yesterday)
[13:09] <james_w> uploaded 42 hours ago
[13:09] <james_w> happyaron: is it urgent?
[13:10] <mdz> 0.60-2 to 0.70-0ubuntu1  (420.2 KiB) eek
[13:10] <happyaron> james_w not very, but it contains the first pot file for translations in ibus package
[13:10] <james_w> happyaron: have patience then, it will be done today or tomorrow I expect
[13:10] <happyaron> james_w: thanks, :)
[13:11] <james_w> mdz: probably easiest to try and downgrade?
[13:11] <james_w> I'm not sure how much caching, if any, is done, so a session restart may be required?
[13:11] <seb128> mdz, what libglib2.0-0 version do you run?
[13:11] <seb128> mdz, and did you restart nautilus since you upgraded glib?
[13:11] <mdz> seb128, ii  libglib2.0-0                               2.22.2-0ubuntu1                            The GLib library of C routines
[13:11] <mdz> mdz      27013  0.0  0.6 570612 20948 ?        S    Oct06   0:21 nautilus
[13:12] <mdz> restarting nautilus now
[13:12] <seb128> mdz, restart nautilus
[13:12] <mdz> seb128, that fixed it, thanks
[13:12] <seb128> you're welcome
[13:20] <soren> mdz: fwiw, the vast majority of that the shared-mime-info diff is translations and updated autotools stuff.
[13:20] <mdz> soren, looks like it wasn't the cause either, thankfully
[13:20] <mdz> I'm about due for a reboot
[13:21] <cjwatson> mdz: you're not the first to report that, I saw a report of it the other day
[13:22] <cjwatson> mdz: bug 444962
[13:22] <cjwatson> ah, heh, hadn't seen it reassigned
[13:22] <soren> I had a somewhat similar problem yesterday as well. I tried to open a pdf with evince from the command line, and it refused, claiming it didn't know how to handle application/octet-stream documents.
[13:22] <soren> An apt-get upgrade fixed it for mem.
[13:22] <soren> me..
[13:32] <doko_> seb128: do you plan new gtk+2.0 uploads? if not I would like to re-upload for an arm rebuild
[13:32] <seb128> doko_, before karmic yes, today maybe not
[13:32] <doko_> same with glib2.0
[13:32] <seb128> same reply
[13:32] <doko_> ok
[13:33] <seb128> do you need a quick rebuild or that can wait for the next changes?
[13:34] <tseliot> pitti: ok
[13:35] <mat_t> pitti: hey
[13:36] <mat_t> pitti: do you know why we don't ship human icon theme anymore?
[13:39] <seb128> mat_t, it's not used by default and take space on the cd which we use for other things,ie translations
[13:41] <mat_t> seb128: who made this decision?
[13:42] <seb128> mat_t, to use humanity by default? ask djsiegel
[13:42] <mat_t> seb128: to remove human
[13:43] <seb128> mat_t, to not install human by default, it was a requirement to switch to humanity to win cd space, pitti did the change
[13:43] <seb128> mat_t, is there any issue with that?
[13:43] <mat_t> seb128: ok, so was that pitti's decision?
[13:43] <seb128> mat_t, collection distro decision if you want
[13:43] <seb128> collective
[13:44] <seb128> cds are what they are and we have to make the default install use one
[13:44] <seb128> mat_t, do you have an issue with not having it installed by default?
[13:44] <seb128> mat_t, open a bug and talk to pitti or slangasek I guess...
[13:45] <mat_t> seb128: ok, I'm not saying the decision is wrong, but anything that affects the user experience on a large scale should be consulted with the design team
[13:45] <seb128> mat_t, it doesn't affect anything? it just don't list an extra theme which is not used by default...
[13:45] <seb128> mat_t, using humanity was a user design team request
[13:45] <mat_t> seb128: the potential consequences are, if the icon is not present in humanity, it will be replaced by gnome default, which is less consistent
[13:46] <seb128> mat_t, and that has been discussed with djsiegel without doing the change
[13:46] <mat_t> seb128: I'm only talking about removing human
[13:46] <seb128> mat_t, we specifically checked with the design team that human was not required as a fallback for humanity
[13:46] <mat_t> seb128: with whom?
[13:46] <seb128> djsiegel when he did the request
[13:47] <seb128> and some of the icon guys were on the channel too
[13:47] <mat_t> seb128: ok, I see
[13:48] <mat_t> seb128: please don't understand me wrong, I know the importance of disk space, but decisions like that must be confirmed with ivanka
[13:48] <seb128> mat_t, the request came from djsiegel
[13:48] <seb128> mat_t, next time send whoever is deciding to discuss the changes?
[13:49] <seb128> mat_t, I think djsiegel was representing your team there
[13:49] <mat_t> seb128: ok, I see your point. I'll pass that on.
[13:49] <tevox562> hi
[13:49] <seb128> mat_t, we didn't do anything out of making the change your team request one day before beta freeze in a hurry
[13:51] <tevox562> hi can someone help me??? and sry for my bad english ^^
[13:51] <seb128> mat_t, don't get me wrong but we made efforts to accomodate changes request from your team coming very late, ie the day of the beta freeze, not sure we can take blame there
[13:51] <mat_t> seb128: Absolutely. I was only asking where the request came from. I know you guys did a lot to accomodate late changes.
[13:52] <tevox562> bb
[13:52] <seb128> mat_t, ok thanks, and please let us know now if other changes are required
[13:52] <mat_t> seb128: thanks seb!
[13:53]  * ogra notes that "importance of diskspace" is a funny phrasing ... 
[13:53] <seb128> you're welcome, sorry for the confusion there
[13:53] <ogra> there simply is none :)
[13:58] <slangasek> smoser: you understand that the difference in download size between a 2GB tar.gz and a 10GB tar.gz is going to be minimal, right?
[13:58] <tseliot> pitti: ok, I pulled from your branch and pushed to my branch
[13:59] <pitti> tseliot: thanks
[13:59] <smoser> slangasek, yes.
[13:59] <slangasek> smoser: btw, I've already poked the tar -S code into the build script (but haven't committed it yet), that was the easiest way for me to do an empirical test ;)
[13:59] <smoser> but the 2G have other advantages
[13:59] <tseliot> pitti: thanks for working on it. Please upload it when you can
[13:59] <slangasek> smoser: ok, just making sure that was the case :)
[13:59] <pitti> tseliot: already done :)
[13:59] <tseliot> even better
[14:00] <smoser> big advantage is that per default UEC settings, you could only run 10G images on a "large" instance type
[14:00] <pitti> mdz: gedit problem> seems settled now?
[14:00] <smoser> with 2G we can run on any of the sizes.
[14:00] <pitti> hi mat_t
[14:00] <mat_t> hey pitti - all clear now, just talking to seb128 about it atm
[14:00] <mat_t> :)
[14:00] <pitti> mat_t: that was discussed with kwwii, and it seemed quite obvious to replace human with humanity; it actually just fell off the CD by itself, since human-theme moved dependency from human to humanity
[14:01] <seb128> pitti, seems that humanity doesn't have as many icons that human
[14:01] <pitti> mat_t: ah, the fallback issue actually came up in #u-desktop, and we were told that the coverage should be pretty much identical now
[14:01] <mdz> pitti, yes, thanks to seb128
[14:01] <seb128> so dropping human means some fallback go to very different icons
[14:02] <pitti> hm, when we did the switch we were told it had..
[14:03] <mat_t> pitti: ok, understood. In case there's a need to "bring back" human, what are the consequences? Lang packs?
[14:03] <seb128> mat_t, do you have a list of problematic icons?
[14:03] <pitti> mat_t: I'd rather just copy the missing icons from human
[14:03] <pitti> shipping an extra 2.5 MB just because of 5 missing icons makes little sense
[14:04] <slangasek> smoser: also, I'm fiddling with trying to get make-web-indices give sensible output for UEC; rough draft at http://uec-images.ubuntu.com/karmic/current/; but I'd like to clarify the file naming scheme before committing (and committing to) this, see my reply to your other email :)
[14:04] <seb128> ups, xchat-gnome crash
[14:04] <mat_t> pitti: it's also the question of giving users more choices.
[14:04] <seb128> mat_t, what pitti said, if we can get a list of problematic icons those could perhaps be added to humanity?
[14:04] <seb128> mat_t, they can install the package from any package management tool
[14:05] <mat_t> seb128: is there an easy way of finding out which ones are missing?
[14:05] <seb128> mat_t, well, you are the one who noticed issues?
[14:05] <seb128> which ones are those?
[14:05] <mat_t> seb128: well, casual users will never know how to do it
[14:05] <seb128> mat_t, I guess we can make the list of icons in both themes and diff easily
[14:05] <seb128> mat_t, do casual user need to change theme?
[14:06] <cjwatson> we can't give users an arbitrary amount of choice on the CD
[14:06] <cjwatson> and we don't in other cases where we might otherwise like to
[14:07] <mat_t> ok, again, I'm not saying we should bring back human. I just need to know the potential consequences if such request comes in
[14:07] <cjwatson> indeed, in most cases we just pick the best thing and deliver that on the CD; I think that's even in Ubuntu's founding principles somewhere :)
[14:09] <mat_t> If the consequence is, for example, not having another language on the CD, it's not worth even thinking about.
[14:10] <cjwatson> languages are about the only thing we can remove without even more difficult knock-on consequences, and the size of human-icon-theme is (off the top of my head) roughly a language's worth
[14:10] <slangasek> 1.4M - yep
[14:10] <cjwatson> we passed the point where we had any other significant slack in our CD images several releases ago (although I thought we'd bought quite a bit this time round by moving help to language packs?)
[14:10] <slangasek> soren: if by "extracted image" you mean "gunzipped", then you were perfectly clear
[14:11] <soren> slangasek: Then I'm confused :)
[14:11] <doko_> ttx: did see that /usr/lib/java/swt.jar is handled by an alternative, which is bad on it's own. question is, if this jar is used by some eucalyptus package directly, or if the versioned jar is used?
[14:11] <mat_t> cjwatson: thx
[14:11] <slangasek> cjwatson: that just means that we have a respectable number of languages on the CD now, which we hadn't for some time
[14:12] <ttx> doko_: looking
[14:12] <cjwatson> slangasek: fair point
[14:12] <slangasek> soren: gzip is a streaming compression algorithm - it doesn't have any idea of sparse files
[14:12] <soren> slangasek: I know.
[14:12] <slangasek> soren: so TTBOMK, when you gunzip something, it writes out every zero, it doesn't create a sparse file on output
[14:13] <soren> Indeed.
[14:13] <slangasek> so feeding this back into tar -S isn't going to do anything useful either :)
[14:13] <soren> Hence the "gunzip -c $file | cp -sparse=always /dev/stdin $out" trick.
[14:13] <soren> Oh.
[14:13] <slangasek> oh, ok
[14:13] <soren> I see what you mean now :)
[14:13] <slangasek> I haven't looked at the scripts, didn't realize you were doing such tricks
[14:15] <ttx> doko_: DEB_JARS := swt-gtk-3.4.2
[14:15] <smoser> slangasek, just replied.
[14:16] <soren> cjwatson: You mentioned something about grub2 support in VMBuilder. Is this something you're working on?
[14:16] <doko_> ttx: ok, thanks
[14:16] <ttx> doesn't use swt.jar at all.
[14:17] <slangasek> smoser: sorry, by "version" I meant "ubuntu-uec-karmic" - or, preferably, "karmic-uec" if we get the naming schemes lined up
[14:17] <slangasek> smoser: -virtual and -server> - these packages aren't co-installable at the same ABI version
[14:18] <smoser> ture...
[14:18] <smoser> true even
[14:19] <smoser> slangasek, the other thing i'd like to know, when looking at directory output is if the kernel actually changed from yesterday. if it did not, then there is no reason for me to do get a new one.
[14:20] <smoser> so, with kernels named:
[14:20] <slangasek> smoser: will having the version number in the description field give you that?
[14:20] <smoser> $version-$arch-{vmlinuz,initrd}-$flavor
[14:20] <smoser> slangasek, yeah, other than having to dig it out
[14:21] <smoser> and guessing which package in that list with "linux" in it is the one that i care about
[14:21] <cjwatson> soren: I have been working on it, but it's blocked on a backport of a grub2 change I made upstream a day or two ago to make grub-install --grub-probe= actually do something useful
[14:21] <slangasek> smoser: what I'm envisioning here is: karmic-uec-i386-vmlinuz-generic-pae  <datestamp> <size> UEC kernel for 32-bit computers (linux-image-2.6.31-12-generic-pae 2.6.31-12.80)
[14:22] <slangasek> smoser: and the last part can be a link directly to the launchpad page, too
[14:22] <smoser> ok. so you're saying the html listing output did the digging for me.
[14:22] <smoser> thats fine as long as the digging is done "server side"
[14:22] <slangasek> yes, that's the idea
[14:23] <soren> cjwatson: Do you think it's something we could have for Karmic?
[14:23] <slangasek> if you're just grabbing the image, you have a known filename to grab
[14:23] <slangasek> if you want more info, pull up the index and it gives you the details
[14:23] <cjwatson> soren: I think so, yes
[14:24] <smoser> slangasek, yeah, that works.
[14:24] <soren> cjwatson: Cool. Can I assign https://bugs.edge.launchpad.net/vmbuilder/+bug/410886 to you, then?
[14:24] <cjwatson> soren: sure thing
[14:24] <soren> cjwatson: Awesome. Thanks so much!
[14:25] <smoser> the only thing less than ideal for me then is that i'd like for the "flavour" displayed to be '-server' rather than '-generic-pae'
[14:25] <smoser> but maybe thats not worth it
[14:25] <smoser> ie, i'd like '-server' and '-ec2' versions. but you've solved everything else i can think of.
[14:25] <slangasek> smoser: ok, cool; if you want to adjust the build scripts to spit out the new filenames, I can work up the index code
[14:26] <slangasek> smoser: hmm, but -generic-pae is the name of the kernel flavor, so listing it as "-server" seems misleading?
[14:26] <superm1> mvo, i've not seen bug 439594 or heard any reports of it so far other than this one, i think that Andreas speculation sounds very sound though
[14:26] <superm1> could update-manager inhibit the screensaver just to be safe?
[14:26] <smoser> well it does come from the -server metapackage
[14:27] <smoser> linux-server.
[14:27] <smoser> err... in this case it would be -virtual
[14:27] <smoser> and that is consistent for i386 and amd64
[14:30] <slangasek> smoser: ah; for now please just use the kernel ABI name (server, generic-pae) and if there's time I'll see if we can convert that to -virtual before final
[14:31] <smoser> i'm happy enough with that.
[14:32]  * cjwatson tries for a usplash that doesn't leave both console and X horribly busted
[14:32] <mvo> superm1: thanks, I will add code for that, it would also be nice to be able to reproduce it
[14:33] <MacSlow> What's the location/name of the local blacklist for kernel-modules (for wifi-chips)?
[14:34] <slangasek> MacSlow: create your own ".conf" file under /etc/modprobe.d/ ?
[14:34] <MacSlow> slangasek, can it be /etc/modprobe.d/<anyname>.conf ?!
[14:34] <slangasek> yes
[14:36] <MacSlow> slangasek, thanks
[15:04] <alejandro> hello people
[15:04] <smoser> slangasek, can you pastebin me a 'tar -S' diff ?
[15:04] <alejandro> I'm doing a metadistro
[15:04] <smoser> or otherwise send it.
[15:05] <alejandro> with Ubuntu 9.04
[15:05] <alejandro> and i want to up gdm
[15:05] <slangasek> smoser: $ cd ~vmbuilder/ec2-nightly/automated-ec2-builds/ && bzr diff ? :-)
[15:05] <alejandro> what do i have to modify to make it????
[15:06] <alejandro> I guess something like /etc/gdm/gdm.conf\
[15:06] <alejandro> /etc/gdm/gdm.conf
[15:07] <alejandro> change tty=7 to tty=4 or to another tty
[15:07] <slangasek> smoser: "bzr diff -c -1", now (change committed)
[15:07] <smoser> is tar -S incompatible with -z?
[15:08] <alejandro> I don't know
[15:08] <smoser> oh... i see . you want to pass the rsyncable.
[15:09] <slangasek> smoser: right
[15:09] <dholbach> any reason why pan is in main? :)
[15:12] <alejandro> the gdm is the one in chroot
[15:13] <cjwatson> robbiew: you might be glad to hear I found a nice solution to the console logging problem
[15:13] <seb128> dholbach, no, any reason why abiword is in main?
[15:13] <robbiew> cjwatson: \o/
[15:14] <cjwatson> robbiew: turns out that all the legacy init scripts have their output redirected to the console by way of /etc/lsb-base-logging.sh (which I knew once, but had forgotten)
[15:14] <robbiew> ha!
[15:14] <dholbach> seb128: I dunno :)
[15:14] <dholbach> was just surprised
[15:15] <cjwatson> robbiew: so I make that honour a CONSOLE environment variable, and make /lib/init/splash-functions (owned by usplash and conveniently sourced by /etc/init.d/rc) set that if usplash was ever running on the system
[15:15] <seb128> dholbach, same question about gftp too
[15:15] <cjwatson> job done
[15:15] <seb128> dholbach, we have lot of things in main for no good reason I think
[15:15] <robbiew> nice!
[15:15] <dholbach> seb128: we should purge them :)
[15:15] <seb128> dholbach, demote you mean?
[15:16] <dholbach> yeah
[15:16] <seb128> dholbach, I can see user unhappy about dropping those...
[15:16] <cjwatson> I've abandoned the idea of releasing vt8 for the moment, since this has the property that you get all the init script output nicely piled up on vt8 for future perusal, independent of console switches
[15:16] <dholbach> well, we don't remove them :)
[15:16] <seb128> dholbach, yes fell free
[15:16] <robbiew> cjwatson: ok
[15:16] <seb128> ie gftp was in universe it could be synced for example when I looked we only had a langpack change
[15:16] <cjwatson> robbiew: there's still a noticeable period between usplash stopping and X starting, but I can't do much about that; as far as I can tell, that represents the time for which gdm is scratching its nose and working out what to do
[15:17] <robbiew> cjwatson: np
[15:17] <cjwatson> I tried having X start up without shutting usplash down first, but the result of that was a completely hosed console afterwards, since X didn't know what mode to restore
[15:18] <cjwatson> (*why* does X still have to be responsible for mode restoration in these days of KMS?)
[15:18] <smoser> mdz, you have a link to info on increasing inodes ?
[15:18] <cyberix_> LaserJock: multiarch may also turn out to be usefull when Adobe refuses to build a 128bit flash player for Ubuntu
[15:19] <robbiew> cjwatson: heh...okay.
[15:19] <cjwatson> cyberix_: we're not short of use cases for multiarch, I don't think ;-)
[15:19] <danlii> I need some help; I upgraded my router to 9.10, and now hardly any services will start automatically, bind9 won't start at all and the network traffic is super slow, 28 kB/sec on a 10 Mbit line... I see nothing wrong in the syslog or dmesg. What could have gone wrong? Oh, also, it didn't insert kernel 2.6.31 into the grub menu, I had to do that myself too.
[15:19] <LaserJock> cjwatson: I made the mistake of idly wondering if it was still needed last night ;-)
[15:20] <Pici> danlii: #ubuntu+1 is the support channel for Karmic
[15:20] <danlii> Pici: ok, thanks...
[15:21] <mdz> smoser, not as such, but I have a vague notion that this is what the resize_inode filesystem feature is about
[15:22] <cjwatson> resize_inode is for online resize, I don't think it has anything to do with sparse files?
[15:24] <smoser> cjwatson, the question is if i create a filesystem for 2G, and give it the default number of inodes for 2G, is there a way to resize it up to 10G and grow the number of inodes
[15:25] <smoser> under the presumption (possibly unimportant or wrong) that the actual use of this resized 10G filesystem would result in running out of inodes.
[15:25] <smoser> i may just have years old data in my head and this is all just magic now.
[15:26] <smoser> there is 'resize_inodes' in mke2fs, and info about reserving space, but i wasn't able to find anything that clearly said "when you resize the fs, you can also increase inodes by...."
[15:26] <cjwatson> ah
[15:26] <cjwatson> resize_inode actually means that an inode is reserved for the purposes of online resize
[15:29] <cjwatson> smoser: my memory is that online resizing adds block groups, which contain their own block and inode tables, but I'm not absolutely sure; a quick test with tune2fs ought to confirm it
[15:33] <ArneGoetje> asac: langpacks ran through, you can test the mozilla part.  When you are done, ping pitti or me to upload them.
[15:33] <smoser> was just doing that.
[15:33] <smoser> and it "just works"
[15:33] <asac> ArneGoetje: where?
[15:33] <pitti> ArneGoetje: oh, I'm already uploading
[15:33] <pitti> ArneGoetje: they are complete again
[15:33] <ArneGoetje> asac: rookery
[15:34] <smoser> create 1M file, mke2fs it. dumpe2fs shows 'Inode Count: 128'
[15:34] <ArneGoetje> pitti: oh... you are too fast. :D
[15:34] <pitti> well, I want this bug fixed, it keeps killing kittens^W^Wgenerating bug spam
[15:34] <ArneGoetje> pitti: +1
[15:34] <smoser> truncate file to 100M. resize2fs file 100M. dumpe2fs shows 'Inode Count: 1664'
[15:34] <superm1> pitti, i just had another crash report for mythtv that still is missing the symbols in the retrace.  can you take a look again? bug 446337
[15:35] <MacSlow> bryce, greetings
[15:36] <MacSlow> bryce, do you happen to know if the driver for ATI (R300) in xorg-edgers is newer then jan-2009? If not I'll look myself... just wondering if you know by heart
[15:37] <Christoph_vW> does anyone know if minor updates to mono will be included in karmic? currently it is using 2.4.2.3 afaik - which sucks badly - even simply things like ToolTips are broken in this version
[15:37] <pitti> superm1: meh, libmyth-0.22-0 is still not in the Packages.gz index :-(
[15:37] <Christoph_vW> simple*
[15:37] <smoser> anyone know of an easy way to compare a string like '1G' '100M' (or anything that can be read by resize2fs) to an actual integer ?
[15:38] <smoser> i'm wanting to take: http://launchpadlibrarian.net/32792682/resize-uec-image
[15:38] <asac> ArneGoetje: a full path would be helpful ;)
[15:38] <superm1> pitti, is it maybe something about that package that is causing it to not  show up in this Packages.gz over and over?  it's section or something?
[15:38] <smoser> and make it resize up or down.  but in order to do that, i have to know if the string the user is giving me is larger than, or smaller than the size of the file now.
[15:38] <pitti> superm1: clearly apt-ftparchive hates me
[15:38] <smoser> (to know when to truncate)
[15:38] <Christoph_vW> smoser: guess you will have to parse it before and convert it to the same base uint
[15:39] <ArneGoetje> asac: /srv/language-packs.ubuntu.com/karmic/support-base/
[15:39] <asac> doesnt exist
[15:39] <asac> only sources-base
[15:39] <ArneGoetje> asac: /srv/language-packs.ubuntu.com/karmic/sources-base/
[15:39] <ArneGoetje> asac: sorry
[15:40] <asac> ArneGoetje: where is the log?
[15:41] <asac> ArneGoetje: and where the export?
[15:41] <pitti> asac: log is at /srv/lp.u.c./logs/karmic.log
[15:41] <pitti> asac: the tarball is already deleted (the cron job script does that), but you can easily re-download it if you need it
[15:42] <pitti> asac, ArneGoetje: btw, if you ever unpack a release tarball from LP, pretty please rm -r it again when you are done; they are space hogs
[15:42] <LaserJock> cjwatson: do you know what would be causing: Invalid release file: no entry for multiverse/binary-i386/Packages during "Install Base System" of d-i
[15:43] <cjwatson> LaserJock: not at the moment, sorry, deep in something else ...
[15:43] <LaserJock> cjwatson: np
[15:45] <superm1> pitti, whenever you get that sorted out, can you rerun the retracer on that?  it's a very fresh build and should hopefully be useful to upstream. thanks
[15:48] <Christoph_vW> smoser: you could replace M/G/...  with sed or awk
[15:48] <slangasek> smoser: I believe I have make-web-indices tweaked to where it'll DTRT for files using the naming scheme discussed, but I'm EOD here - once you have a chance to tweak the vmbuilder output, drop me a ping on IRC and I can test the make-web-indices part
[15:48] <smoser> yeah, mainly i was wondering if htere was already a 'human2bytes' program that i could just use.
[15:48] <Christoph_vW> maybe with awk '{gsub(/M/,"*1024*1024",$2); print $2}'
[15:48] <smoser> slangasek, ok.
[15:53] <Christoph_vW> does anyone know if  mono will be upgraded to newer 2.4.x minor versions im karmic?
[15:54] <Christoph_vW> or will at stay at 2.4.2.3 with some security fixes only?
[16:08] <kees> Riddell: heh, ok
[16:08] <pitti> asac: btw, you also have a lot of temp files in rookery:/tmp/; it seems that po2xpi always created a temp dir, but doesn't clean it up (I just deleted gazillion po2xpi* and xpitranslations.* dirs)
[16:11] <asac> pitti: owned by langpack-o-matic or me?
[16:11] <pitti> asac: you; I already removed the langpack owned dirs
[16:11] <pitti> asac: but it would be nice to fix the script to clean up, so that it doesn't keep eating space
[16:12] <asac> ArneGoetje: so the 3.5 and 1.9.1 langpacks were empy because i had a busted data link. i will disable firefox and xulrunner for 9.10 too ... so we dont need to remove it from launchpad yet for those that want to still carry their changes over
[16:12] <asac> pitti: yes, thats for sure. could be that i forgot to readd a remove or something while debuggin at some point
[16:12] <asac> i will check that
[16:13] <pitti> asac: danke
[16:14] <asac> ArneGoetje: kick it off again please
[16:16] <asac> ArneGoetje: if you can fast skip the rest and just try mozilla that would help speed things up i guess.
[16:22] <sladen> cjwatson: what is X doing trying to restore a video mode; surely that is (only) being done by KMS now?
[16:23] <cjwatson> sladen: good question and I have no idea (nor do I have time to go and find out)
[16:24] <cjwatson> lots of things are firmly in the "-> lucid" category for me right now. :)
[16:25] <cjwatson> .oO <mdz> that's a hoary problem
[16:38] <hunger> Any chance to get gdb 7.0 in karmic? Probably too late, it only came out today.
[16:41] <Riddell> pitti: could you eye up adept in hardy-proposed when you have a moment, I'd like to get it tested toot sweet, bug 439706
[16:47] <pitti> Riddell: uh, let's hope that this goes well, since we don't truly support that
[16:49] <pitti> Riddell: skipIntrepid now means "skip intrepid and jaunty"?
[16:50] <Riddell> pitti: right
[16:51] <pitti> good, will do an SRU round after I'm done with my current task
[17:03] <jcastro> Riddell: we have an openweek kubuntu netbook session, want any more?
[17:03] <jcastro> cody-somerville: ... and we have no xubuntu sessions if you want to do one
[17:04] <Riddell> jcastro: we do?
[17:05] <jcastro> Riddell: ScottK is doing one.
[17:08] <Riddell> jcastro: how about something along the lines of "getting KDE 4 ready for the LTS" ?
[17:10] <lool> siretart: around?
[17:13] <jcastro> Riddell: sure, add yourself please! https://wiki.ubuntu.com/UbuntuOpenWeek/Prep
[17:17] <bryce> MacSlow, yes
[17:21] <bryce> pitti, slangasek:  FFe on the -intel 2.9.0 upload is bug 446080; the package is assembled and ready for upload if it is approved
[17:21] <pitti> bryce, slangasek: I went through the changelog yesterday, and it looks fairly good; the b43 addition is already in, or at least planned anyway, right?
[17:25] <bryce> pitti, correct
[17:26] <bryce> pitti, it's not in yet but Intel requested it so it's on the todo list
[17:26] <pitti> bryce: people are starting to test mesa now, so let's get it uploaded now
[17:26] <bryce> alright
[17:49] <smoser> slangasek, http://uec-images.ubuntu.com/karmic/20091008.4/ has renamed output, please verify that it is in line with what you were expecting
[17:51] <smoser> and http://uec-images.ubuntu.com/karmic/20091008.5 has a 'tarball packed' output
[17:52] <smoser> oh, and regarding kernel/initrd names. i did name them with '-virtual' for flavour. this is because i took the information from the package that provided it, rather than the file name
[17:53] <smoser> which i think is more valid
[18:04] <Darxus> Screen just died on me again.  I hit ctrl-d at an unfortunate time so I don't have the error message it through when it crashed.  Something about not having something to attach to.
[18:04] <Darxus> 	5695.pts-0.dancer	(10/03/2009 12:59:33 PM)	(Dead ???)
[18:04] <Darxus> There's no useful debugging I can do of a dead session, right?
[18:16] <robbiew> cjwatson: when should I expect to see the console message related changes and usplash enabled for boot?
[18:32] <cjwatson> robbiew: just need to do another reboot to test this latest batch of changes to make shutdown reliable; distracted by another project atm
[18:32] <siretart> any cryptsetup guru around to triage bug 446517? I'm pretty sure that the bug is valid, I'm unsure how severe it actually is. I believe that many other bugs are actually because of this
[18:32] <cjwatson> robbiew: today or tomorrow I think
[18:32] <robbiew> cjwatson: np...and thanks
[18:33] <cjwatson> I'm having to do a brutal kludge to get shutdown working reliably, because of what looks like a race in gdm shutdown
[18:38] <robbiew> cjwatson: well, fwiw, shutdown experience is a lucid thing ;)
[18:38] <robbiew> not karmic :D
[18:40] <cjwatson> robbiew: regressions are a "not right now" thing, though ;-)
[18:40] <robbiew> touche!
[18:40] <cjwatson> (to be clear, this is me trying to get the shutdown back to at least as good a state as the last upload)
[18:41] <kees> robbiew: I heard you had a patch for redirecting startup text to tty6?  which bug is that for?  (I suspect 444362 should be a dup of it)
[18:41] <robbiew> kees: don't need it
[18:41] <robbiew> kees: cjwatson has a fix for this now
[18:41] <cjwatson> kees: bug 440871
[18:42] <cjwatson> and yeah, it'll fix that bug
[18:42] <cjwatson> well, maybe except for ufw
[18:42] <cjwatson> they're not really dups though, how about I just close both bugs with this upload
[18:42] <kees> cjwatson: sure
[18:43]  * kees still prefers having usplash do the hiding...
[18:43] <cjwatson> kees: we will
[18:43] <cjwatson> kees: the fix is two parts. (a) turn usplash on by default again as agreed in the last foundations meeting (b) force all init script output to tty8 if usplash was ever started
[18:43] <robbiew> kees: patience grasshopper
[18:43] <cjwatson> well, ever this boot
[18:44] <cjwatson> the only thing that doesn't account for is upstart jobs that use 'console output'
[18:44] <cjwatson> and the only one of those that's really relevant I think is ufw
[18:44] <jdstrand> ufw should be quiet unless there is an error
[18:44] <robbiew> nice
[18:44] <cjwatson> ufw should be quiet
[18:44] <cjwatson> when we're in splash mode
[18:44] <jdstrand> ie, if it is disabled or enabled, it is quiet
[18:44] <cjwatson> it using console *at all* creates problems
[18:44] <kees> robbiew: heh, I didn't know usplash was being re-enabled.  :)
[18:44] <jdstrand> if there was an error in running the firewall, it speaks up
[18:45] <robbiew> oh...and apparently the kernel team will fix the "quiet" tag to hide kernel console messages...but will still log to dmesg
[18:45] <kees> cjwatson: sweet
[18:45] <mathiaz> free: hi - looking at the landscape-client/smart intrepid SRU
[18:45] <cjwatson> (so Keybuk says)
[18:45] <mathiaz> free: how much QA has been done for the new version of smart?
[18:45] <free> mathiaz: hey
[18:45] <mathiaz> free: IIUC it's not a 1.2 - only backported patches
[18:45] <cjwatson> as in, using the console output command requires upstart to do things that cause problems
also, can I get colors and a progress bar back in usplash?</rant>
[18:46] <free> mathiaz: the patches that were included are basically the ones from 1.2.0 that affect landscape-client
[18:46] <cjwatson> I think it would probably be best to make it use the LSB init script functions (which I think should still be usable in an upstart job) for its output, and then it won't have to do the console output thing
[18:46] <free> mathiaz: and that have been subject to the QA process outlined in the LandscapeUpdate document
[18:46] <mathiaz> free: right - have the new combination of packages been through the landscape extended SRU process?
[18:46] <jdstrand> cjwatson: it is unclear to me whether I should change ufw (again). I tried to comply with a quiet boot, but thought that if loading the firewall caused an error, that is worth mentioning. is this a wrong assumption?
[18:47] <cjwatson> jdstrand: it's worth mentioning, but not where ufw is currently mentioning it
[18:47] <stgraber> anyone familiar with the way upstart works ? I'm trying to make Karmic work in OpenVZ and for now all I get is a single "init" process and nothing else in the container
[18:47] <free> mathiaz: I have tested them personally on an intrepid machine
[18:47] <cjwatson> jdstrand: I will prepare a patch
[18:47] <free> mathiaz: but they didn't go through the whole process again
[18:47] <stgraber> I tried sending the "startup" event manually but get a "Event failed" error ...
[18:47]  * jdstrand is curious where it should mention it, but will wait for the patch
[18:47] <free> mathiaz: the patches are really the same that we already QA-ed though
[18:48] <cjwatson> jdstrand: if usplash is running, it should use one of those usplash OHMYGOD commands to display text on the splash screen
[18:48] <mathiaz> free: right - I think it would be worth going through an full cycle of QA again - from the -proposed repository this time
[18:48] <mathiaz> free: so I'm going to upload the new packages to intrepid-proposed
[18:48] <cjwatson> jdstrand: if usplash is not running, it should put it on tty8 with the rest of the init script output (or at least where the init script output will be once I finish this patch set)
[18:49] <mathiaz> free: and ask that the full Landscape SRU process be done agains the package published in -proposed
[18:49] <jdstrand> cjwatson: ok, thanks for the explanation
[18:49] <cjwatson> jdstrand: this means (a) most users will see it because it will be on the splash screen as an error (b) people won't complain about ugly text-mode text on the screen (c) Keybuk can continue his campaign to get rid of the console command from upstart
[18:49] <free> mathiaz: you mean re-doing the QA for intrepid-proposed or also for jaunty-proposed?
[18:49] <mathiaz> free: only for intrepid-proposed
[18:49] <free> mathiaz: that's fine
[18:50] <free> mathiaz: I'll ask andreas to help me with that
[18:50] <mathiaz> free: IIUC the packages that are now in jaunty-proposed are the same as the one that have already been QA
[18:50] <free> mathiaz: exactly
[18:50] <mathiaz> free: however the packages that are about to land in intrepid-proposed are *not* the same
[18:50] <free> mathiaz: also true, some more QA is due
[18:50] <mathiaz> free: that's why I'd rather have them QAed again - once they're in intrepid-proposed
[18:51] <free> mathiaz: sounds fine to me
[18:51] <jcastro> mathiaz: any more openweek sessions?
[18:51] <mathiaz> jcastro: hm - I'll look at the wiki page again
[18:52] <mathiaz> jcastro: when is the deadline?
[18:52] <jcastro> mathiaz: like 2 weeks ago. :D
[18:52] <jcastro> mathiaz: COB today would be great
[18:52] <mathiaz> jcastro: ok - when is the *real* deadline?
[18:52] <jcastro> today
[18:52] <jcastro> we would like to announce today
[18:53] <free> mathiaz: btw the hard-deadline for karmic uploads is like next week? we would still have a few patches for the current karmic version of landscape-client
[18:53] <mathiaz> jcastro: ok - I'll have a look at the schedule once I'm done with landscape
[18:53] <mathiaz> free: HardFreeze is next Thursday
[18:53] <free> mathiaz: okay
[18:53] <mathiaz> free: note that only *bug* fixes are accepted now-a-days
[18:54] <jcastro> mathiaz: <3, I'll need a short bio from you too, but you can just mail that to me
[18:54] <free> mathiaz: yes, they're karmic-specific bug fixes
[18:54] <mathiaz> jcastro: "this dude is great - come listen to him! - jcastro" <- would that work?
[18:54] <jcastro> yes
[18:55] <mathiaz> free: sure
[18:58] <kees> Riddell: thanks for fixing skim!  That lets me check off "rebuild all ELFs in main since introducing hardening flags" finally.  that was the last package.  :)
[19:03] <LaserJock> anybody happen to know if the current Ubuntu Alternate daily installs?
[19:05] <mathiaz> jcastro: only spot left are on Fri, Nov 6 - I won't be available that day
[19:06] <jcastro> :(
[19:06] <mathiaz> jcastro: so I'll skip this OpenWeek
[19:06] <jcastro> ok
[19:07] <Amaranth> ugh, I'm going to have to stay awake until 3am to go to this meeting
[19:24] <mathiaz> free: could you comment on the status in karmic for bug 268261, bug 236884, bug 388577, bug 389001?
[19:36] <mathiaz> free: all the bugs that are fixed in the intrepid smart sru need to be fixed released in karmic
[19:37] <mathiaz> free: could you make sure that the status are correct?
[19:37] <free> mathiaz: I'm having a look now..
[19:37] <mathiaz> free: great - I've gone through some of them
[19:38] <mathiaz> free: if you mark them as fixed released, please add a statement why this has been the case (eg: included in 1.2-4 which is karmic)
[19:38] <free> mathiaz: alright
[19:39] <free> mathiaz: I guess most of them don't have a karmic task? like https://bugs.launchpad.net/landscape-client/+bug/268261
[19:40] <free> mathiaz: I don't have the permission to add a karmic task I think
[19:46] <mathiaz> free: karmic == development
[19:46] <mathiaz> free: for the bug above, you need to make sure it's not incomplete
[19:46] <free> mathiaz: so just mark the toplevel item as "Fix released"?
[19:46] <mathiaz> free: yes - top-level for smart (Ubuntu)
[19:46] <free> cool
[19:47] <Turl> hello, can anyone confirm this? https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/442378
[19:47] <beuno> Turl, I can see it just fine
[19:47] <apachelogger> asac: I am not sure we should change the string at this point, so I suppose karmic will ship with the free icon... you still need to make the firefox packages conflict&replace the installer :)
[19:49] <free> mathiaz: bug 388577 is fixed in the smart package in the jaunty-proposed queue
[19:49] <Turl> beuno: are you on AC Power or on battery power?
[19:50] <free> mathiaz: Jaunty is now marked as "Fix committed", I'm not sure if I should turn it into "Fix released"?
[19:50] <asac> apachelogger: whats the problem with that string? its not a translatable string
[19:50] <beuno> Turl, I can see it on both
[19:50] <asac> apachelogger: also without that icon you cannot even name it firefox
[19:50] <mathiaz> free: nope - jaunty status are fine
[19:51] <Turl> beuno: and if you boot from battery power, does g-p-m believe it's on AC power? mine does
[19:51] <apachelogger> hm
[19:51] <asac> apachelogger: if its not possible we can probably also use "firefox" ... as he said. but i dont see why we couldnt try to get permission to change that string
[19:51] <free> mathiaz: okay, so all bugs have the correct status now
[19:51] <mathiaz> free: they're fix committed because they've been accepted in -proposed
[19:51] <asac> its a trademark string -> no translations
[19:51] <apachelogger> asac: which string was he meaning anyway :)
[19:51] <free> mathiaz: oh okay
[19:51] <mathiaz> free: they will be moved to fix released once they're in -updates
[19:51] <beuno> Turl, I need to stop doing what I'm doing now to test that, so I can't say right now  :)
[19:51] <Turl> asac: by chance, are you talking abot karmic's firefox saying 'shiretoko' on the title?
[19:52] <asac> apachelogger: you probably use "firefox" ... and he wants it to be "mozilla firefox"
[19:52] <free> mathiaz: makes sense
[19:52] <Turl> beuno: right, thanks anyway :)
[19:52] <asac> Turl: no. are you running dailies?
[19:52] <apachelogger> asac: yeah, well, every occurance of that is translatable
[19:52] <Turl> asac: nope
[19:52] <apachelogger> desktop file stuff is, the heading is and the description as well
[19:52] <free> mathiaz: it's a rather peculiar way of using the "Fix committed" term :)
[19:52] <Turl> asac:   Installed: 3.5.3+build1+nobinonly-0ubuntu3
[19:53] <mathiaz> free: the important part here is that bugs fixed in an SRU have to be fixed in the development release (*first* usually)
[19:53] <apachelogger> asac: so changing the string basically fuzzyfies about all strings
[19:53] <apachelogger> s/string/strings
[19:53] <mathiaz> free: this is why pitti was asking for the status in karmic
[19:53] <free> mathiaz: yes, that was clear to me
[19:54] <free> mathiaz: I didn't introduce anything that wasn't already in karmic, both for jaunty and intrepid
[19:54] <mathiaz> free: having the bug status set correclty helps the sru team
[19:54] <asac> apachelogger: do you have the screens still i can look at?
[19:54] <asac> mine are gone in the backup archive :/
[19:54] <Turl> asac: any idea why it says 'shiretoko' ?
[19:54] <free> mathiaz: thanks for the explanations, I'll remember it for the next time
[19:55] <apachelogger> asac: http://aplg.kollide.net/images/snapshot019.png
[19:55] <asac> Turl: what does it say in help -> about?
[19:56] <asac> apachelogger: yes. so you cannot use the string that way
[19:56] <asac> it suggest that its a Kubuntu Firefox
[19:56] <asac> and you cannot use the free icon in combination with the trademark
[19:56] <Turl> asac: Firefox Version 3.5.3 Mozilla Firefox for Ubuntu canonical - 1.0 ....
[19:56] <asac> Firefox installer would have been fine
[19:56] <asac> or Mozilla Firefox installer
[19:57] <asac> i will cehck with him if its still ok
[19:57] <apachelogger> hum hum
[19:57] <Turl> (btw, why is canonical on lowercase?)
[19:57] <asac> apachelogger: in worst case we can export pos and sed it and import
[19:58] <apachelogger> asac: IMHO that would be best case though, Kubuntu apps get rarely translated as it is
[19:58] <asac> apachelogger: yes. so checking the translation status in launchpad would be a good first step
[19:58] <asac> like: how many translations are there already etc.
[20:00] <apachelogger> asac: https://translations.launchpad.net/ubuntu/karmic/+source/kubuntu-firefox-installer/+pots/kubuntu-firefox-installer
[20:00] <asac> Turl: thats a bug then for you ... can you file one and assign to me (asac) ... and ping me with bug id?
[20:00] <Turl> asac: I've already filled one
[20:00] <Turl> filed*
[20:00] <Turl> asac: https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/444176
[20:01] <asac> Turl: you probably tried witha  fresh profile?
[20:02] <Turl> asac: nope, I didn't - let me try that
[20:02] <asac> thx
[20:03] <Turl> mhm, a newly created profile says 'Mozilla Firefox'
[20:04] <asac> Turl: can you grep for Shiretoko through the .mozilla folder?
[20:04] <Turl> sure asac
[20:05] <Turl> Binary file .mozilla/firefox/8l8jtiya.default/extensions/langpack-es-AR@firefox.mozilla.org/chrome/es-AR.jar matches
[20:05] <Turl> Binary file .mozilla/firefox/8l8jtiya.default/formhistory.sqlite matches
[20:05] <Turl> Binary file .mozilla/firefox/8l8jtiya.default/places.sqlite matches
[20:06] <asac> Turl: can you still reproduce by using the original profile?
[20:06] <asac> back that up so it stays reproducible
[20:06] <Turl> mhm, how can I test that?
[20:06] <Turl> you mean, mv .mozilla and relaunch firefox?
[20:06] <asac> Turl: what did you do to do a new profile?
[20:07] <Turl> asac: closed firefox, firefox -P and create one there
[20:07] <asac> Turl: yes. so run firefox -P again and choose the default profile
[20:08] <Turl> yeah, the default one is my main profile, the one that says Shiretoko
[20:08] <Turl> I'm using it now again
[20:11] <asac> Turl: so backup your  .mozilla directory. i will ask further things on bug later. now dinner
[20:12] <Turl> asac: moving .mozilla to some other place and then opening firefox makes it work fine (title says 'mozilla firefox')
[20:13] <asac> Turl: i just wanted you to back it up ... so when we start trying things we can still keep reproducing when things are suddenly fixed
[20:13] <Turl> ok
[20:15] <Turl> asac: mhm, I rm'ed a langpack extension on the extensions folder in my profile, and it now says Mozilla Firefox
[20:15] <asac> Turl: where did you get that langpack from?
[20:15] <asac> anyway out for a while bb i 30 minutes or so
[20:15] <Turl> asac: I guess from mozilla's ftp, as karmic firefox is in english now :/
[20:17] <Turl> asac: from here iirc: ftp://ftp.mozilla.org/pub/firefox/nightly/latest-firefox-3.5.x-l10n/
[21:36] <soren> Are people generally converting their bzr branches to the 2a format? It seems a bit early since only Karmic ships bzr > 2.0, but the package branches are in that format, and they're kind of hard to work with, if the upstream project is using an older format, for instance.
[21:39] <LaserJock> yeah, it would be nice to have some general guidelines for what we're supposed to do
[21:41] <jdong> soren: I've been doing so; though the 2a format I should point out is supported by earlier releases too
[21:41] <jdong> though possibly not as stable...
[21:41] <soren> jdong: Oh, really? How far back?
[21:43] <jdong> 1.16-ish?
[21:43] <soren> Aha!
[21:43] <soren> ./repository.py:    'Bazaar repository format 2a (needs bzr 1.16 or later)\n',
[21:43]  * soren rmadisons
[21:44] <soren> So as far back as... <drum roll>
[21:44] <jdong> soren: well presumably Ubuntu bzr users would be taking advantage of the Bazaar PPA anyway
[21:44] <jdong> I'd be more concerned about other distro users
[21:44]  * soren taps fingers
[21:44] <soren> I don't use the bzr ppa. Never have.
[21:44] <soren> I don't expect other people to either.
[21:45] <LaserJock> it'd be good to know how it'd effect Debian
[21:45] <soren> Ah. Jaunty is 1.13, so Karmic is the first to support it.
[21:46] <LaserJock> testing has 1.17 at least
[21:46] <soren> Yeah.
[21:46] <jdong> bad assumption about the bzr PPA then :D
[21:46] <jdong> *revises* presumably bzr users are used to the 90 bazillion format changes per second of their favorite DVCS!
[21:46] <jdong> (haha love you, bzr devs; it's still my favorite!)
[21:50] <ScottK> bzr 2.0 is a no change backport for Jaunty.  Just needs some rdpends testing.