[00:06] <slangasek> tormod: is the change in 430121 still required?  upstart-job has been fixed so that 'invoke-rc.d $foo start' doesn't fail when the job is already started
[00:06] <tormod> slangasek, I saw this yesterday
[00:07] <slangasek> tormod: ok; well I don't think this patch is the right way to fix the problem, invoke-rc.d should *not* be failing so we should get to the root of what's causing it to fail
[00:07] <wgrant> cjwatson: Adding comments is difficult, but I want to do it eventually. Versions superseded in the primary archive are in a separate table, as that's fairly useful and much much easier.
[00:07] <tormod> slangasek, isn't it failing just because upstart already restarted it?
[00:07] <slangasek> tormod: it shouldn't be, see my above comment
[00:08] <slangasek> 'invoke-rc.d $foo start' on a service that's already started is *not* supposed to fail
[00:08] <tormod> slangasek, ok I see
[00:08] <wgrant> If something is on the list but now builds fine in the primary archive, I guess it's reasonable to retry it to make it disappear.
[00:08] <slangasek> tormod: when you saw this yesterday, was this part of a full dist-upgrade from jaunty?
[00:09] <tormod> slangasek, not from jaunty, just a week or two old karmic
[00:09] <slangasek> tormod: ah, so you could indeed have already had the old upstart-job installed
[00:10] <slangasek> tormod: a full apt term.log would be helpful to confirm this
[00:10] <cjwatson> wgrant: yeah, I hadn't realised the latter - that does help a lot
[00:11] <slangasek> tormod: if upstart was at a version lt 0.6.3-4 when acpid was being configured, that explains why you still saw the problem
[00:11] <tormod> slangasek, I attached the dpkg.log
[00:13] <tormod> slangasek, yes it went from 0.6.3-1 to 0.6.3-7
[00:13] <slangasek> tormod: ok, great - I'll close this bug out as a duplicate, thanks
[00:13] <slangasek> er, no
[00:13] <slangasek> I didn't have a bug open before :-)
[00:14] <chrisccoulson> seb128 - i didn't want to disturb the meeting on #ubuntu-desktop. so, our current default gconf setting for g-p-m screen locking is "/apps/gnome-power-manager/lock/use_screensaver_settings = true", which means that if a user disabled locking in the screensaver preferences, the screen will no longer lock on suspend either
[00:14] <chrisccoulson> and the log attached to bug 428115 shows that is the likely reason for the issues there
[00:14] <seb128> chrisccoulson, could you add a comment on the bug saying that?
[00:15] <chrisccoulson> yeah, can do
[00:15] <seb128> thanks
[00:15] <seb128> that would make sense to explain the issue
[00:15] <chrisccoulson> yeah, it should do:)
[00:15] <seb128> I'm not sure if it makes sense from an user perspective
[00:15] <seb128> ie if you want suspend to not lock screen because you told the screensaver to behave this way
[00:16] <cjwatson> jbernard_: I'll retry cmake, hopefully that will get it off the list
[00:16] <cjwatson> (as wgrant suggested)
[00:16] <chrisccoulson> seb128 - yeah, that's confusing, but we can easily flip that key and have g-p-m use it's own policy
[00:20] <jbernard_> cjwatson: cool, thanks
[00:24] <chrisccoulson> seb128 - i had a response back already, and it is a user config issue
[00:24] <chrisccoulson> but the behaviour is still confusing
[00:25] <seb128> chrisccoulson, ok, good to have that sorted, you rock!
[00:25] <cjwatson> wgrant: does the row shading mean anything? it doesn't seem to just alternate
[00:26] <chrisccoulson> heh, thanks ;)
[00:26] <wgrant> cjwatson: It does alternate. But I forgot to fix it so that it's done after the list is split.
[00:26] <wgrant> cjwatson: Fixing.
[00:27] <cjwatson> ah, ok
[00:27] <cjwatson> thanks
[01:03] <slangasek> pitti: AFAICS, devicekit-power never grew a quirks database in time for karmic; does pm-suspend just magically work on everyone's hardware now without any arguments, or are the complaints going somewhere that I'm not noticing?
[01:03] <james_w> pm-utils still uses hal I thought?
[01:04] <chrisccoulson> i thought it was the other way around?
[01:04] <slangasek> pm-utils never used hal
[01:04] <slangasek> g-p-m used hal to assemble the commandline to pass to pm-utils
[01:04] <slangasek> maybe pm-utils is smart enough to do this on its own now, I dunno
[01:04] <slangasek> oh, it does
[01:04] <slangasek> /usr/lib/pm-utils/sleep.d/00auto-quirk
[01:04] <slangasek> james_w: thanks :)
[01:05] <slangasek> pitti: ^^ ignore me, james_w knows
[01:05] <james_w> Halsectomy knows all
[01:06] <james_w> I just happened to discover this the other day while trying to suspend with the dbus server broken in gdb and then spending ages finding out that pm-utils was hung waiting for a response from HAL
[01:06] <slangasek> that means all our quirks are now properly shared across all suspend methods without having to add any code, awesome
[01:06] <slangasek> james_w: haha
[03:53] <gbear14275> I was wondering if someone could pass a link to me or some information about the upcoming 9.10 server edition?  I tried to download it from this link: http://uec-images.ubuntu.com/releases/9.10/  but its broken.  I found this page: http://uec-images.ubuntu.com/releases/karmic/beta/  but am not sure what version I'm looking for.  Can someone tell me about the upcoming server versions or by chance point me to the "regular" ser
[04:05] <andersk> Is it known that usplash doesn't quit when fsck fails so badly that it asks you to run fsck manually?
[04:19] <slangasek> andersk: bug #432237, linked from the beta overview?
[04:22] <Darxus> Is it really not possible to change a ppa name?  I have to create a new one and copy the contents?
[04:41] <Darxus> Wow, three minutes after upload, my package is building.  You people must be slacking.  Last time was eight hours.
[05:08] <superm1> so what is actually supposed to control whether usplash starts prior to xsplash?
[05:08] <superm1> sometimes i've been seeing it and sometimes not
[05:20] <slangasek> superm1: USPLASH=yes somewhere in /usr/share/initramfs-tools
[05:20] <slangasek> (currently, it's on if cryptsetup is installed, and AFAIK off in all other cases)
[05:21] <superm1> slangasek, hmm interesting.  i've been seeing it right after a fresh install sometimes on misc daily disks, wonder if that's a bug somewhere then.  i'll have to check again off a recent daily
[06:30]  * lamont wonders how to tell gdm to _NOT_ show the pretty users-list crap.. make me type my username...
[06:30] <lamont> or at the very least, don't show me all the users with locked passwords
[06:37] <liw> or let me configure it to not make an awful bleeping noise when it brings up the login window...
[06:42] <al-maisan> Good morning!
[06:47] <jdong> can a KDE dude enlighten me on why the default KDE window decorations are so.... 1990's? :-/
[06:47] <jdong> I've never been the one to nitpick UI prettiness but it seems like everyhing ELSE about KDE is remarkably shiny
[06:49] <liw> hm, my karmic desktop machine has developed an annoying habit of not bringing its statically configured network interface up
[07:18] <dholbach> good morning
[07:35] <superm1> pitti, ping.  would you be able to help look at an apport report for a mythtv bug and help figure out why symbols aren't getting properly applied?  All of the QT debug symbols get applied perfectly, but the mythtv ones are just showing up "No symbol table info available"
[07:35] <superm1> https://bugs.launchpad.net/ubuntu/+source/mythtv/+bug/445173
[07:53] <pitti> Good morning
[07:54] <pitti> slangasek: confirmed, pm-utils still uses the hal quirks DB; that's still on the list of getting ported (also, my favourite option is to put the quirks right into pm-utils, not into dk-power)
[07:55] <pitti> superm1: yes, I can have a look into the retracer logs; I'll comment on the bug
[07:55] <superm1> thanks pitti
[08:11] <pitti> superm1: replied
[08:13] <superm1> pitti, ah okay.  thanks.  won't need the retrace this time since upstream tracked it down already from another report, but we've been having a lot of these bug have broken lately.  how soon is the plan for proper soyuz support of ddebs then?
[08:14]  * pitti eyes wgrant
[08:16] <ttx> pitti: hey -- if you could trigger a server ISO respin, I would win a couple hours in my testing :)
[08:16] <wgrant> superm1: I hope to have the code in LP for 3.1.10, but it will need IS work and buildd changes rolled out as well.
[08:16] <wgrant> superm1: What's the problem here?
[08:17] <pitti> ttx: do you want ports as well? or just amd64/i386?
[08:17] <ttx> pitti: just amd64/i386.
[08:17] <pitti> ttx: running; should be there in some 10 mins
[08:17]  * ttx hugs pitti
[08:17] <pitti> you're welcome
[08:17] <superm1> wgrant, pitti said this: https://bugs.launchpad.net/ubuntu/+source/mythtv/+bug/445173/comments/5
[08:18] <wgrant> superm1: Ah, right.
[08:18] <wgrant> So, it will be several weeks, but not much longer.
[08:19] <superm1> okay.  well if this comes up again with some other reports before that i'll raise it with pitti
[08:26] <pitti> ttx: there:
[08:26] <pitti> http://cdimage.ubuntu.com/ubuntu-server/daily/20091007/
[08:27] <ttx> pitti: \o/ yay, more UEC testing...
[08:44] <seb128> does anybody has an idea about bug #441167?
[08:45] <seb128> there is a pam_mount password prompt during the postinst
[08:45] <seb128> not sure if that's due to gdm calling su gdm to write the gconf key for the theme
[08:46] <pitti> superm1: su does create a PAM session, yes
[08:46] <pitti> sorry, seb128
[08:47] <pitti> seb128: perhaps we should use "sudo -u gdm command" instead?
[08:47] <seb128> pitti, I'm wondering if we should rather try to use a gtkrc or something
[08:47] <seb128> those su calls create tons of issues
[08:48] <pitti> seb128: sure, we can just ship the .gtkrc in the .deb
[08:48] <seb128> gconftool call issues when there is no dbus session bus
[08:48] <seb128> .gvfs permissions issues
[08:48] <pitti> right, we had that (--direct, etc.)
[08:48] <seb128> now password prompts
[08:48] <pitti> seb128: I'm fine with a .gtkrc
[08:49] <seb128> pitti, I need to test that though because gnome-settings-daemon is running and I'm not sure .gtkrc will be used or if g-s-d will overwrite things
[08:49] <seb128> ie what wins between gtkrc and gconf keys applied by gsd
[08:49] <pitti> seb128: wouldn't/shouldn't the file be owned by root?
[08:49] <pitti> gdm shouldn't be able to change it
[08:50] <seb128> what file?
[08:50] <pitti> the .gtkrc one
[08:50] <pitti> if it's shipped in the .deb, it's be root:root
[08:50] <pitti> s/be//
[08:50] <seb128> well you can change the permissions in the package if needed
[08:56] <chrisccoulson> seb128 - g-s-d currently has it's own specific settings for the GDM user (but the keys are shipped by GDM, in a special location). g-s-d uses these settings in the GDM session because g-s-d is started with a --gconf-prefix option. i wonder if we could exploit this for the theme (perhaps with a small patch)
[08:57] <chrisccoulson> that would avoid messing around with user gconf keys in the postinst and gtkrc's and everything
[08:57] <seb128> chrisccoulson, are those settings not only gconf datas in the gdm user dir?
[08:59] <chrisccoulson> seb128 - no, they're global i think. i can't check right now, but if you have a look in your user session, i think you should see /apps/gdm/simple-greeter/settings-manager-plugins, which are the GDM specific settings fro g-s-d
[08:59] <chrisccoulson> if thats the case, then i can't see why we couldn't do something similar for the theme
[08:59] <seb128> chrisccoulson, oh, thanks for the hint
[09:01] <chrisccoulson> yeah, i just checked the package contents, and they're just installed like any other gconf schema
[09:03] <seb128> excellent
[09:07] <pitti> kees: gdm has a Vcs-Bzr: *cough*
[09:08] <pitti> kees: (committed now)
[09:14] <seb128> pitti, working on gdm changes?
[09:14] <pitti> seb128: just committed kees' upload
[09:15] <seb128> pitti, ok, I was not sure if you were cleaning on if you noticed because you started on other changes
[09:16] <pitti> seb128: no, I just habitually check bzr if someone outside of ~ubuntu-desktop uploads a gnome package :) (I follow -changes)
[09:16] <seb128> ok good :-)
[09:16] <chrisccoulson> heh, yes, i've been caught by branches being out of date before ;)
[09:33] <soren> X is chewing up 100% cpu on my laptop. Is there something like xrestop that can give me a hint about which X client might be keeping the X servr so busy?
[09:36] <pitti> soren: I didn't find xrestop helpful for that; I just kept killing programs until I found it
[09:36] <pitti> fortunately the responsible program usually also has some CPU usage
[09:36] <pitti> (and most often it's firefox..)
[09:36] <soren> The ubuntuone syncdaemon was also eating 100% cpu, but that wasn't the culprit. X is still at it.
[09:36] <soren> ...and firefix isn't running.
[09:37] <pitti> soren: so! X is desperately waiting for firefox!
[09:37] <soren> Some kind of top-like application for IPC would probably help somewhat. I expect the offending process will be talking a lot to the X server.
[09:38] <soren> pitti: Heh.. That would be freaky :)
[09:42] <soren> Ah, right.
[09:42]  * soren was just reminded how annoyed X gets if you try to strace it.
[09:43] <jtimberman> i just did an apt-get upgrade on my karmic system, and now networking doesn't start up, complains that /var/run/network/ifstate doesn't exist. is this a known issue?
[09:48] <Koterpillar> Where can I get the Ubuntu source for gnome-keyboard-applet? I did apt-get source gnome-applets, but I can't find it there.
[09:51] <chrisccoulson> Koterpillar - libgnomekbd
[09:51] <chrisccoulson> that's the source package name
[09:55] <seb128> chrisccoulson, the applet is in gnome-applets no?
[09:56] <chrisccoulson> i thought the applet was shipped as part of libgnomekbd
[09:56] <chrisccoulson> yeah, the binary package is gkbd-applet
[10:35] <Whoopie> bryce: Hi, I think your latest changes to wacom-tools were not applied as the patch is not in the series file.
[10:52] <mr_pouit> pitti: Bug #445236 << Apparently this old bug (fixed in gutsy) has come back in karmic. Any idea? (something dropped in hal?)
[11:05] <pitti> mr_pouit: it has never really been a hal bug; but I noticed that as well
[11:05] <pitti> we worked around it in hal by supplying a magic vfat option back then
[11:05] <pitti> "usefree" IIRC
[11:05] <pitti> this was fixed in a later kernel, but apparently it came back
[11:06] <pitti> bug 133567
[11:09] <joaopinto> aren't debian/control files utf-8 encoded ?
[11:10] <pitti> they ought to
[11:11] <liw> http://www.debian.org/doc/debian-policy/ch-controlfields.html -- yes, they must be
[11:13] <joaopinto> UnicodeDecodeError: 'utf8' codec can't decode bytes in position 39-41: invalid data
[11:13] <joaopinto> parsing thunderbird-locale-mk 1:<IP_ADDRESS>+1-0ubuntu2
[11:14] <liw> sounds like a bug, that
[11:14] <joaopinto> you mean a packaging bug ?
[11:16] <liw> yes
[11:18] <liw> joaopinto, indeed, the thunderbird-locale-nb-no package has text in what looks like iso-8859-1 (latin1)
[11:20] <liw> (isutf8 can be a handy tool for finding such, even if I say so myself)
[11:23] <joaopinto> ok I will add some failsafe code to encode with replace on errors, and then file bug reports
[11:57] <citrus212> hi there
[11:57] <citrus212> i need help getting the 'mouse over w/thumbnails' KDE package onto gnome
[11:59] <Riddell> ?
[12:00] <Riddell> citrus212: it's a  feature  not a package, you would need to code the same feature in gnome or use KDE
[12:01] <liw> what does this feature do?
[12:58] <cjwatson> #ifdef HAVE_STRNLEN
[12:58] <cjwatson> # ifndef strnlen
[12:58] <cjwatson> int strnlen(const char *str, size_t size);
[12:58] <cjwatson> # endif /* !strnlen */
[12:58] <cjwatson> what on earth is the point of that, other than to cause build failures?
[12:58] <cjwatson> (librcc)
[12:58] <doko__> seb128: what are the keywords for hidden gnome/kde entries in .desktop files?
[12:58] <doko__> heh
[12:59] <doko__> we should collect these "best of build failures"
[13:00] <chrisccoulson1> doko__ - are you referring to the "OnlyShowIn" key?
[13:01] <doko__> chrisccoulson1: yes, I think that's what I do want
[13:02] <doko__> chrisccoulson1: can these be enabled using the menu editor?
[13:04] <chrisccoulson1> doko__ - i think they're hidden completely, so they won't show in the menu editor either
[13:04] <chrisccoulson1> although i'm not 100% certain there
[13:04] <soren> cjwatson: Perhaps it's meant for the case where HAVE_STRNLEN is a lie?
[13:05] <soren> cjwatson: Where did you see this?
[13:05] <ogra> doko__, if you just dont want to have it shown at all: Hidden=true
[13:06] <cjwatson> soren: 12:58 <cjwatson> (librcc)
[13:06]  * soren cleans his glasses
[13:06] <cjwatson> soren: it's just wrong. configure detected strnlen (in this case). Either it's a function or a macro, so given the #ifndef, it must be a function. Either the system declaration is the same, in which case it's pointless, or it's different, in which case it will fail.
[13:19] <cjwatson> asac: could you fix the test rebuild failure in http://launchpadlibrarian.net/32107043/buildlog_ubuntu-karmic-i386.mobile-broadband-provider-info_20090622-0ubuntu1_FAILEDTOBUILD.txt.gz ? I'd do it myself but it's in a bzr branch I can't commit to. I think you just need to either build-depend on automake1.10 or change debian/rules to use 1.11 (preferably the latter)
[13:24] <asac> cjwatson: yes. i am updating that package today anyway to get latest data. thx!!
[13:30] <hyperair> hmmm i'm missing a libglib2.0-0. amd64 must have ftbfsed eh
[13:46] <cjwatson> hyperair: seems to have succeeded, maybe just a bit behind
[13:47] <hyperair> ah i see
[13:47] <cjwatson> finished three hours ago, though ...
[13:47] <cjwatson> not in NEW
[13:50] <hyperair> imo there should be some synchronization in place to ensure arches don't get left behind. leads to some annoying dependency problems
[14:03] <cjwatson> doko__: what should we do about the pychecker build failure? it's full of stuff that changed in python2.6 - do we need to adjust the test suite for that, or do we need to make it only work with python up to 2.5 since it looks like nobody's really added 2.6 support yet?
[14:04] <cjwatson> doko__: I can probably take care of it, but wouldn't mind some direction if you've handled this kind of thing before
[14:05] <doko__> cjwatson: python2.5 only, I don't see it maintained upstream
[14:06] <cjwatson> ok, so build-dep on python2.5 and make it use python2.5 for the regression test - should be straightforward
[14:07] <liw> mvo, #226967: I assume that can be marked "Fix Released" now?
[14:07] <kagou> can we still request a sync for a package in universe ?
[14:08] <cjwatson> kagou: yes, if it meets feature freeze criteria or you get an exception
[14:09] <kagou> thanks cjwatson, I'v reported #445413 (you have done the precedent sync from 0.9.8 in #384380 ). I'm looking at feature freeze criteria
[14:10] <mvo> bug 226967
[14:10] <mvo> bug #226967
[14:20] <seb128> doko__, what do you want to do? usually we use NoDisplay
[14:20] <doko__> seb128: hmm, ogra mentioned Hidden=true ...
[14:21] <ogra> Hidden might be old
[14:21] <seb128> doko__, so you want those to be listed in the menu editor or not?
[14:21] <ogra> my knowledge in that area is a bit rusty
[14:22] <doko__> seb128: yes, the user should be able to show it again
[14:22] <seb128> Hidden=true will make those not considered for mimetypes associations etc too
[14:22] <seb128> doko__, so NoDisplay is what you want
[14:22] <doko__> seb128: ok thanks
[14:23] <doko__> everything not using the command line is scary, maybe except OOo ,p
[14:23] <ogra> haha
[14:25] <mvo> cjwatson: does https://bugs.edge.launchpad.net/ubuntu/+bug/442262/comments/7 looks like a bug in debconf to you? or something in the integration in aptdaemon?
[14:25]  * liw is scared by OOo
[14:32] <tkamppeter> pitti, hi
[14:32] <cjwatson> mvo: would it be possible to get 'DEBCONF_DEBUG=.' output? it looks as though debconf got an error when trying to read from the other end of the passthrough fd
[14:33] <cjwatson> mvo: it's a bug that it carries on and spews warnings, but fixing that would just tidy up the output, not actually fix it
[14:34] <mvo> cjwatson: thanks, I have not yet managed to reproduce it, I will try that and add the output
[14:34] <cjwatson> lines 65-66 are:
[14:34] <cjwatson>         $reply = <$readfh>;
[14:34] <cjwatson>         chomp($reply);
[14:35] <cjwatson> and undef from <> means error or EOF
[14:40] <pitti> hey tkamppeter
[14:49] <tkamppeter> ṕitti, in bug 441897 it looks like that during the update of the CUPS package (Jaunty -> Karmic or within Karmic) the cupsd.conf file got empty.
[14:50] <tkamppeter> pitti, AFAIR there are also other reports about this problem.
[14:54] <spaetz> pitti: thanks for driving bug 430694 forward. It was giving me a hell of a time :-
[14:54] <spaetz> :-)
[14:57] <pitti> spaetz: wasn't me really
[14:58] <spaetz> no, but you are nagging Tim Gardner :)
[14:58] <pitti> tkamppeter: ugh, that sounds serious; could it be a fallout from the "cleans /tmp/ on upgrade" bug that was fixed yesterday?
[14:58] <spaetz> And I am just happy that the bug is being taken care of
[14:59] <tkamppeter> pitti, I have already heard about wiped cupsd.conf before yesterday.
[15:00] <tkamppeter> pitti, where got a '"cleans /tmp/ on upgrade" bug' get fixed yesterday?
[15:02] <bfox> cjwatson: ping?
[15:03] <cjwatson> bfox: hello?
[15:03] <cjwatson> bfox: if it's about what I think it's about, haven't had a chance to look yet ...
[15:04] <bfox> cjwatson: okay, thanks
[15:04] <pitti> tkamppeter: bug 444545
[15:04] <bfox> cjwatson: I know you're busy  ;)
[15:04] <pitti> tkamppeter: but that could only be relevant if cups tried to do stuff in /tmp/ and died in the middle of rewriting cupsd.conf
[15:06] <pedro_> does anybody know if the ubuntu wiki is on some kind of read only mode? I'm trying to create a page and i'm getting a nice error
[15:09] <tkamppeter> pitti, does any "udevadm trigger ..." call wipe /tmp? And why should this affect /etc/cups/cupsd.conf?
[15:11] <pitti> tkamppeter: any udevadm trigger which triggers block devices
[15:11] <pitti> tkamppeter: there are only two reasonable ways it could get empty: (1) either you have an unmodified conffile and dpkg dies in the middle of unpacking a new version
[15:11] <pitti> or (2) cups rewrites it on a cupsctl change and dies in the middle of it
[15:12] <pitti> (1) is unlikely, given that the reporters actually use it, and cups just can't keep its bloody fingers from that conffile
[15:12] <pitti> and dpkg is pretty robust agianst that, too
[15:12] <liw> doesn't dpkg always write first to a new file, then move that over the original?
[15:12] <pitti> (2) could happen with anything; but if it coiincides with the time when we had that /tmp bug, it might be related
[15:13] <liw> (any program -- except database engines -- updating an important file in-place is probably buggy)
[15:15] <liw> is gutsy still supported?
[15:15] <Pici> No.
[15:15] <Pici> !gutsy
[15:16] <liw> !dapper
[15:39] <liw> any Spanish speakers who could look at bug #444979 (filed against update-manager)? looks like lirc and ntfs-3g failed to upgrade for some reason
[15:40] <beuno> liw, looking
[15:40] <kirkland> ttx: yo
[15:41] <ttx> kirkland: hey
[15:41]  * mvo hugs liw for doing u-m triage
[15:41] <beuno> liw, he says "no idea, the error got triggered in fusa, lirc, and other dependencies"
[15:41] <liw> mvo, I don't like doing it, though... I was down to 775 open bugs and then something brought it back up to 775 :(
[15:42] <pitti> 775 - 775 == 0, hmm
[15:42] <liw> er, 776 for the second instance
[15:42] <mvo> liw: its no fun, I do not enjoy it either
[15:42] <mvo> hard work
[15:42] <liw> mvo, yeah
[15:42] <LaserJock> mdz: do you want me to edit the release manifest wiki page or just reply to the email you sent?
[15:42] <mdz> LaserJock, both please
[15:43] <ttx> kirkland: I've committed a few fixorz that should make autoregistration more consistent
[15:43] <kirkland> ttx: cool
[15:43] <kirkland> ttx: uploaded?
[15:43] <kirkland> ttx: i uploaded your fixes from yesterday?
[15:43] <ttx> kirkland: no, I want to test it more
[15:43] <ttx> kirkland: yes, btw, don't forget to debcommit --release when you do so
[15:43] <ttx> kirkland: your final changelog for ubuntu2 wasn't in the branch
[15:44] <ttx> kirkland: I committed it.
[15:44] <ttx> kirkland: I cherrypicked the Heartbeat fix
[15:44] <kirkland> ttx: okay, what about kees' euca_rootwrap?
[15:44] <ttx> kirkland: looks like it's working, but i want to do the full test run
[15:45] <ttx> kirkland: didn't test it
[15:45] <kirkland> ttx: i think we're going to need to pull that in too
[15:45]  * liw wishes for a feature in LP that would uncompress files (so it would be easier to look at log files, without having to download + uncompress locally)
[15:45] <ttx> kirkland: I'm tseting a little more and will give you the go-ahead to release my changes, together with whatever you want from your day
[15:46] <LaserJock> mdz: the sign off is for the just the announcement or on the whole release (.iso, etc.)?
[15:46] <kirkland> ttx: cool, thanks for doing that
[15:46] <kirkland> ttx: we'll pull the euca_rootwrap fixes too
[15:46] <ttx> kirkland: I didn't work on "wtf after the reboot" style bugs
[15:46] <kirkland> ttx: test that, and upload (hopefully)
[15:46] <mdz> LaserJock, the whole thing
[15:46] <ttx> I think you need to debug those with Dan
[15:46] <mdz> LaserJock, who can say "yes, it's ready"
[15:46] <LaserJock> mdz: ok
[15:48] <kirkland> ttx: please assign to me any bugs you want me to work on with dan
[15:48] <ttx> I think they are already assigned to you..; let me check
[15:49] <ttx> hmm, why does the wiki hate me
[15:51] <ttx> "[Errno 31] Too many links: '/srv/wiki.ubuntu.com/www/data/pages/MeetingLogs(2f)Server(2f)20091006'"
[15:52] <elmo> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
[15:53] <elmo> god damn it moin
[15:53] <ttx> elmo: :)
[15:53] <robbiew> lmao
[15:54] <LaserJock> mdz: done, thanks for bringing that up
[15:55] <LaserJock> mvo: does software-center use the app-install-data data?
[15:55] <mvo> LaserJock: yes
[16:16] <joaopinto> already saw 2 reports about mysql server upgrade failing, anyone knows a bug about it ?
[16:16] <joaopinto> ops, ignore me :P
[16:17] <Riddell> cjwatson: does reorg just affect packages in main?  universe  stays much the same?
[16:17] <cjwatson> no
[16:18] <cjwatson> it's entirely possible (and may be useful) for a package set to contain stuff in universe
[16:18] <cjwatson> probably best to read the spec for details
[16:19] <cjwatson> seb128: are we planning to pull in mm-common from Debian? gtkmm-documentation from git seems to require it
[16:20] <seb128> cjwatson, I don't know about this one but I will have a look, I would say that we should from a quick look right now
[16:20] <seb128> what do you think?
[16:24] <cjwatson> I think it may only be necessary for building from git, not quite certain
[16:24] <cjwatson> maybe we should sync it and stick it in universe, if that's accurate
[16:24] <lamont> if some enterprising soul could go stomp on bug 445530, my life would be much better.
[16:24] <lamont> since (nearly?) EVERY package using python-support is FTBFS in rebuildability testing
[16:24] <cjwatson> (I'm just looking at gtkmm-documentation's build failure, and trying to reproduce with git so that I can file an upstream bug ...)
[16:24] <blackxored> enrico, ping
[16:25] <jjardon> hello, I can't install epiphany-browser (It's not in the archive), is this intentional?
[16:26] <jtimberman> i just did an apt-get upgrade on my karmic system, and now networking doesn't start up, complains that /var/run/network/ifstate doesn't exist. is this a known issue?
[16:26] <ScottK> jjardon: It is, but it's in Universe in karmic.
[16:28] <jjardon> ScottK, ah, ok. The problem is I can't install epiphany-webkit neither
[16:29] <ScottK> Well my advice would be install KDE, so I'm probably not the best one to help you.  Help with Karmic is in #ubuntu+1.
[16:29] <jjardon> ScottK, Maybe I'm wrong but I think that epiphany-browser is not in universe
[16:30] <ScottK> I see there is source, but now binaries, so I'm not sure what's up with that
[16:31] <blackxored> ScottK, it's not on karmic/universe version 2.28.0-4?
[16:31] <ttx> kirkland: proposed 0ubuntu3 so far is working alright for me
[16:31] <blackxored> ScottK, the source only ?
[16:31] <kirkland> ttx: good
[16:31] <ScottK> What I see in rmadison is epiphany-browser |   2.28.0-4 | karmic/universe | source
[16:32] <ScottK> Perhaps the binary package name changed.
[16:32] <blackxored> ScottK, yes that's what I see, odd :(
[16:32] <james_w> ftbfs?
[16:32] <blackxored> probably
[16:32] <ScottK> No idea.
[16:32] <LaserJock> slangasek: what was the issue with libgd2-xpm causing a conflict between ubuntu-desktop and edubuntu-server?
[16:32] <LaserJock> slangasek: is that something that Edubuntu can fix?
[16:33] <james_w> blackxored: https://edge.launchpad.net/ubuntu/+source/epiphany-browser/2.28.0-4ubuntu1
[16:33] <sebner> ScottK: blackxored : In NEW is -4ubuntu1 fixing a FTBFS so this might be the issue
[16:33] <blackxored> sebner, james_w thanks but point to jjardon ;)
[16:33] <ScottK> OK, well we've pretty well exhausted my interest in the Gnome web browser.
[16:34] <lamont> 2 bugs filed, 49 to go
[16:36] <jjardon> thank you all :)
[16:45] <james_w> dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
[16:45] <james_w> really annoying
[16:46] <mvo> if someone uses a rtl language I would appreciate feedback if the latest software-center works with that as expected (it should :)
[16:46] <jtimberman> is this not the place to ask about bugs in karmic?
[16:47] <Pici> jtimberman: Please use #ubuntu+1 for karmic support and discussion
[16:56] <ogra> ok, thats totally not funny ... if your system clock is at 1970 but your disk was mounted with proper clock setting your system goes into constant reboots
[16:56] <ogra> /dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****
[16:56] <ogra> /dev/sda1: ***** REBOOT LINUX *****
[16:56] <ogra> /dev/sda1: 138868/469568 files (0.1% non-contiguous), 590241/1875580 blocks
[16:56] <ogra> mountall: fsck / [575] terminated with status 3
[16:56] <ogra> mountall: System must be rebooted: /
[16:56] <ogra> init: mountall main process (341) terminated with status 4
[16:56] <ogra> rm: cannot remove `/forcefsck': Read-only file system
[16:57] <ogra> init: mountall post-stop process (648) terminated with status 1
[16:57] <ogra> [42949430.100000] Restarting system.
[16:57] <ogra> where is keybuk when i need him :(
[16:58] <ogra> that looks serious
[16:59] <ogra> hmm, great after the 100th reboot it trashed the rootfs completely and cant mount it anymore
[17:00] <ttx> kirkland: just add anything you want (reasonably tested) to it, upload, and /quit plop
[17:00] <ttx> arrh
[17:00] <ttx> make that just /quit plop
[17:01] <james_w> http://launchpadlibrarian.net/31896337/buildlog_ubuntu-karmic-i386.k3b-i18n_1.0.5-1ubuntu1_FAILEDTOBUILD.txt.gz
[17:01] <james_w> is --without-arts the right thing to do now that we have dropped it?
[17:12] <sistpoty|work> james_w: I assume it is (though I'm by far no kde expert, maybe #kubuntu-devel might give better information ;))
[17:13] <Riddell> james_w: hum, that doesn't match the k3b version we're using
[17:14] <Riddell> james_w: mm, that should probably be removed from the archive
[17:15] <james_w> even easier then
[17:17]  * cjwatson removes linux-ports from the archive. die
[17:18] <mathiaz> slangasek: could you have a look at bug 445453?
[17:27] <cjwatson> lamont: oddly, 'from hashlib import md5' works here
[17:28] <cjwatson> lamont: I suspect it needs libssl0.9.8
[17:28]  * cjwatson does a minimal bootstrap to check
[17:29] <lamont> cjwatson: you can even do variant=buildd :-p
[17:30] <lamont> http://paste.ubuntu.com/287931/ <-- cjwatson: wb --list order (ish), and not pysupport or arch-not-in-list, so far
[17:31] <lamont> if you see any in the list after quilt that especially interest you, holler
[17:34] <cjwatson> I think the problem is that /usr/lib/python2.6/lib-dynload/_hashlib.so is in python2.6 rather than python2.6-minimal
[17:34] <cjwatson> doko__: ^- do you agree?
[17:35] <cjwatson> lamont: I know I just fixed a few of those. Interested in gfxboot-theme-ubuntu
[17:36] <doko__> cjwatson: I'll have a look later, does this have time until tonight?
[17:36] <cjwatson> doko__: no rush!
[17:38] <doko__> cjwatson: would a dependency on libopenssl in -minimal be ok?
[17:39] <cjwatson> doko__: it's already priority: important - it would just mean it'd have to move to priority: required
[17:39] <lamont> cjwatson: build-depends: cpio, not declared
[17:39] <cjwatson> lamont: ah, ok
[17:39] <lamont> cjwatson: was old chroot tarball cruft
[17:39] <cjwatson> lamont: can fix that easily
[17:40] <doko__> cjwatson: which report/package is this?
[17:40] <cjwatson> doko__: bug 445530
[17:41] <cjwatson> that's odd though, python-support Depends: python
[17:42] <lamont> cjwatson: if your doing that, the other cpio winner is qt-x11-free
[17:42] <cjwatson> lamont: is python2.6 installed at the point when python-support breaks?
[17:42] <cjwatson> lamont: same question for libssl0.9.8
[17:43] <lamont> libfile-find-rule-perl-perl <-- stutter
[17:43] <lamont> checking
[17:44] <james_w> if I /proc/<pid>/fd/<n> is a socket
[17:44] <james_w> how do I find out what other tasks are attached to the socket?
[17:46] <elmo> lsof or netstat
[17:46] <cjwatson> lamont: fixed gfxboot-theme-ubuntu. In the last few days I've fixed at least gettext, icu, libiodbc2, pychecker, netpbm-free, elilo, grub, kexec-tools, and smartmontools, and removed linux-ports - so you can skip all those
[17:46] <lamont> ta
[17:46] <lamont> python2.6-minimal is build-essential, python2.6 is not
[17:47] <cjwatson> indeed, but python-support depends: python depends: python2.6
[17:47] <cjwatson> so it's weird that it wouldn't be installed
[17:47] <cjwatson> I still think it's probably wrong for python2.6-minimal to ship a .py without the matching .so, but this seems independent
[17:51] <pmatulis> what's the password for user 'ubuntu' in a jaunty live session?
[17:52] <cjwatson> pmatulis: none
[17:52] <pmatulis> the shadow file shows an encrypted one and i want to ssh into the session
[17:52] <cjwatson> as in, blank
[17:52]  * doko__ is away for 3h ...
[17:52] <cjwatson> it's an encrypted blank password. You may have to reconfigure sshd to allow that
[17:52] <pmatulis> ahh
[17:52] <cjwatson> PermitEmptyPasswords yes
[17:54] <pmatulis> cjwatson: thank you
[17:56] <jdstrand> kees: were you involved in the gcc update on hardy?
[17:56] <smoser> cjwatson, i'm looking at bug 444598. mdz suggested consulting you.
[17:57] <jdstrand> kees: I ask cause I'm having problems building icu on amd64, and think it is because I cannot install gcc-multilib
[17:57] <LaserJock> cjwatson: am I correct to assume that Edubuntu's supported seed only needs to list packages that are not already in the Ubuntu supported seed?
[17:57] <jdstrand> kees: gcc-4.2-multilib: Depends: lib32gcc1 (>= 1:4.2.4-1ubuntu3) but 1:4.2.3-2ubuntu7 is to be installed
[17:57] <cjwatson> smoser: reasonable, but I'm about to finish up for the day - do you think you could mail me?
[17:57] <lamont> cjwatson: btw... I filed bugs for everything thru quilt on that list, so... fix-released status for a number of bugs would be appropriate
[17:57] <smoser> sure.
[17:58] <lamont> if you don't kill them first, I'll go back after I get done with this round of bugfiling
[17:58] <cjwatson> LaserJock: there's very little actually in the Ubuntu supported seed directly ...
[17:58] <mdz> smoser, I suggested you ask him about matching source for the binaries; not sure if that's the same bug or not
[17:58] <smoser> you're right, mdz, it is different bug.
[17:59] <kees> jdstrand: I did touch gcc in hardy, yes
[18:00] <kees> jdstrand: checking...
[18:00] <jdstrand> kees: actually, it may be a problem with my mirror
[18:00] <jdstrand> gcc-4.2 | 4.2.4-1ubuntu3 | http://debmirror hardy-security/main Sources
[18:00] <jdstrand> (that is good)
[18:00] <kees> jdstrand: oh, er.
[18:00] <jdstrand>   Version table:
[18:00] <jdstrand>      1:4.2.3-2ubuntu7 0
[18:00] <jdstrand>         500 http://<IP_ADDRESS> hardy/main Packages
[18:01] <jdstrand> kees: let me look into it more before you waste time on it. sorry for the noise
[18:01] <kees> jdstrand: yeah, it _should_ be ok:    gcc-4.2 | 4.2.4-1ubuntu3 | file: hardy-security/main Packages
[18:02] <kees> jdstrand: anyway, let me know if you don't resolve it and I can dig more.
[18:02] <slangasek> LaserJock: moodle->php5-gd->libgd2-xpm; it's not something Edubuntu can fix
[18:03] <mathiaz> cjwatson: hi!
[18:03] <jdstrand> kees: universe/g/gcc-4.2/lib32gcc1_4.2.4-1ubuntu3_amd64.deb
[18:04] <mathiaz> cjwatson: I've just done a ./edit_acl.py -P karmic-ubuntu-server query from the ubuntu-archive-tools bzr branch
[18:04] <jdstrand> kees: for some reason the binary is in universe here. I'll look into it and get it fixed up
[18:04] <kees> jdstrand: oh, did lib32gcc1 fall out of main?
[18:04] <mathiaz> cjwatson: and it seems that there are some missing things related to server in there (like mysql-dfsg-5.1 and openldap)
[18:04] <jdstrand> kees: it looks like it
[18:04] <kees> jdstrand: that's odd.  I didn't have anything to do with that!  :)
[18:04] <jdstrand> kees: no, you wouldn't :)
[18:05] <jdstrand> kees: again, thanks and sorry for the noise
[18:05] <mathiaz> cjwatson: is this on purpose or the package set is not up-to-date yet?
[18:05] <kees> jdstrand: np
[18:07] <cjwatson> mathiaz: a lot of source packages that ship core libraries are necessarily in core, not ubuntu-server
[18:08] <cjwatson> mathiaz: although the package sets are indeed a bit out of date at the moment; I have a terminal session over there -> in the process of fixing it up
[18:11] <kirkland> cjwatson: we're hitting a weird avahi issue with our current eucalyptus testing
[18:11] <kirkland> cjwatson: possibly a regression, possibly just something randomly wrong this time
[18:12] <kirkland> cjwatson: pinging cluster.local, resolving over avahi is resolving to two different addresses, from different machines
[18:12] <kirkland> cjwatson: <IP_ADDRESS> in the "broken" case
[18:12] <kirkland> cjwatson: <IP_ADDRESS> in the "working" case
[18:13] <kirkland> cjwatson: this is making the retrieval of the node-preseed fail
[18:13] <kirkland> cjwatson: as the installer cannot wget from <IP_ADDRESS>
[18:14] <kees> kirkland: 169.254... is a link-local address.
[18:14] <kirkland> cjwatson: actually, from the same host, pinging cluster.local is sometimes resolving to <IP_ADDRESS> and sometimes to <IP_ADDRESS>
[18:14] <kees> kirkland: in theory, the <IP_ADDRESS> machine should have the link-local until it gets the 10.x address?
[18:14] <kees> (both should reach the machine?)
[18:22] <cjwatson> kirkland: I don't know exactly how avahi orders its resolution; in theory you should get all the possible names, but when I tried the obvious fix to euca_find_cluster to try to prefer some over others, I was only seeing one
[18:23] <ScottK> cjwatson: Your gettext merge from yesterday now causes cvs to be installed with lintian due to lintian depends gettext and gettext recommends cvs  (see gettext (0.17-7)).  Would you mind if I moved that back to suggests?
[18:23] <cjwatson> kirkland: it has a debugging environment variable, you can see what it says I guess
[18:23] <cjwatson> ScottK: yes, I would
[18:23] <cjwatson> ScottK: I'd prefer we just left it there and sucked it up
[18:24] <cjwatson> I don't want people getting confused because it's a recommendation in Debian and a suggests in Ubuntu ...
[18:24] <ScottK> cjwatson: OK.  It seems a bit much to me that every Lintian user now gets cvs,....
[18:25] <cjwatson> maybe one of these days gettext will stop shipping an embedded cvs repository
[18:26] <cjwatson> but until then I do feel that it's kind of bad form to ship gettext in a state where it doesn't work for building packages that use it (indeed, there's a bug asking for it to be moved from suggests to depends ...)
[18:26] <cjwatson> this isn't a veto or anything, but you asked :)
[18:27] <ScottK> Well it's not the kind of thing I'm going to ignore your opinion on.
[18:27] <slangasek> oh, is that why cvs is on my system now <purge>
[18:27] <ScottK> Yep
[18:27] <cjwatson> I agree the indirect dep from lintian is annoying
[18:28] <lamont> gettext is annoying
[18:28] <cjwatson> the alternatives are worse
[18:29] <ScottK> Given what you've said, I can see this is the least bad approach available.
[18:30] <cjwatson> I wonder what it'd take to turn that CVS repository into something else upstream
[18:32] <MacSlow> bryce, greetings
[18:32] <MacSlow> bryce, where's the Xorg/Mesa/drivers edgers PPA again?
[18:33] <bryce> MacSlow, xorg-edgers is at https://edge.launchpad.net/~xorg-edgers/+archive/ppa
[18:33] <MacSlow> bryce, thanks!
[18:34] <bryce> MacSlow, however note that it's already beyond mesa-7.6.  I'm working on pulling in the debian package of that release; should be up in a ppa before long
[18:35] <MacSlow> bryce, it's about trying to narrow down a bug in intel's (i965) GLSL compiler in their driver
[18:37] <bryce> MacSlow, ah gotcha; yeah for that you'll probably want to use xorg-edgers.
[18:37] <lamont> seb128: so how do I teach firefox that when I minimize it, or start it and move the mouse out of it while it's thinking about rendering a page, that I DON'T WANT IT TO STEAL FOCUS WHEN IT FINISHES RENDERING (AND IT UNMINIMIZES TOO)
[18:38] <lamont> just curious
[18:38] <seb128> dunno, I don't work firefox nor wms, try asking asac or mvo about those ;-)
[18:38] <lamont> (that's with metacity)
[18:38] <lamont> heh. ok
[18:39] <ogra> you start it with --dont-steal-my-focus-you-damned-bastard
[18:40] <lamont> ogra: if only firefox really had such an option
[18:40] <ion> bryce: Does the edgers repo have KMS support for ATI?
[18:40] <ogra> heh
[18:40] <lamont> seb128: it's on my screen, it must be yours. :-D
[18:40] <bryce> ion, in fact Karmic has KMS support, you just need to boot with the radeon.modeset=1 kernel parameter
[18:41] <ion> bryce: Ooh! Nice.
[18:41] <bryce> it's still a bit buggy though; xorg-edgers may be less buggy
[18:48] <alex-weeej> is apt daemon staying?
[18:50] <seb128> staying where? for karmic? yes
[18:50] <alex-weeej> that's cool
[18:50] <alex-weeej> does it support the same interfaces as packagekit?
[18:50] <alex-weeej> for application integration
[18:51] <alex-weeej> such as "halp i need plugins"
[18:51] <seb128> alex-weeej, you want to talk to mvo or glatzor about that
[18:52] <alex-weeej> ok
[18:52] <alex-weeej> also one more quick one
[18:52] <alex-weeej> my MacBook Pro 5.4 from a few months ago has an NVidia HDA sound card that isn't supported by Karmic's kernel.
[18:53] <alex-weeej> but it is in the upstream alsa driver
[18:53] <alex-weeej> is it too late to support this hardware by backporting the driver?
[18:53] <alex-weeej> actually it's the snd-hda-intel driver, so i guess there could be regressions :/
[18:54] <ion> bryce: Is radeon.modeset=1 supported with 2.6.31-12-generic-pae?
[18:54] <ion> bryce: It says it's unknown boot option.
[19:00] <bryce> ion, supported with the current Karmic kernel.  If you're using some other random kernel YMMV
[19:07] <ion> bryce: My bad; the kernel says that but the driver still seems to respect that value. The real error is later in dmesg; it says "[drm:radeon_driver_load_kms] *ERROR* Failed to initialize radeon, disabling IOCTL", "radeon 0000:01:05.0: PCI INT A disabled", "radeon: probe of 0000:01:05.0 failed with error -22". The GPU's RS780M/RS780MN [Radeon HD 3200 Graphics].
[19:08] <ion> bryce: It's the current karmic kernel; the generic-pae variant.
[19:16] <bryce> ion, I'm really tied up doing a mesa merge at the moment, but if you can reproduce the problem with the stock (non-pae) kernel, do file a bug about it and I'll investigate when I have some time
[19:17] <ion> bryce: Alright, i'll test with -generic.
[19:17] <bryce> ion, we have found other random little bugs with -ati kms in testing, which is why we've not yet switched kms on by default yet.  What you've found might just be yet another one of those bugs.
[19:20] <kirkland> cjwatson: okay, so we're looking for alternative approaches to solving this now...
[19:20] <kirkland> cjwatson: in eucalyptus-cc.eucalyptus-cc-publication.upstart, I see
[19:20] <kirkland> exec avahi-publish -s $(hostname) _eucalyptus._tcp $CC_PORT txtvers=1 protovers=1.5.0 type=cluster
[19:20] <kirkland> cjwatson: the $(hostname) is being used for the "name" parameter of avahi-publish
[19:21] <kirkland> cjwatson: i don't see where that field is actually being used anywhere
[19:21] <kirkland> cjwatson: we're thinking about overloading that field with $CC_IP_ADDR
[19:21] <kirkland> cjwatson: and modifying euca_find_cluster to use that input as the cluster's ip addr
[19:22] <kirkland> cjwatson: do you have any objections to this?
[19:22] <cjwatson> kirkland: none, if it works
[19:23] <kirkland> cjwatson: cool, thanks
[19:33] <cody-somerville> Can an arch all package specify architecture restricted relationship?
[19:33] <cody-somerville> *relationships
[19:34] <slangasek> cody-somerville: no
[19:35] <slangasek> arch-restricted relationships are parsed by dpkg-gencontrol (so don't end up in the binary package control file), not by apt/dpkg
[19:51] <LaserJoc1> cjwatson: why did adding ship-addon to dvd fix bug #439383 ?
[19:51] <LaserJoc1> cjwatson: couldn't we just use ship from ubuntu.karmic?
[19:58] <ion> bryce: Reported http://launchpad.net/bugs/445717
[20:15] <mathiaz> slangasek: could you have a look at the smart upload to jaunty-proposed?
[20:16] <mathiaz> slangasek: it blocks landscape-common that was accepted in jaunty-proposed
[20:16] <slangasek> mathiaz: there seems to be a lot of state related to that SRU that I would have to get up to speed on; would it be reasonable to wait for pitti?
[20:19] <mathiaz> free: what's the bug number that prevents landscape-common to be upgraded?
[20:19] <mathiaz> slangasek: smart not being accepted in jaunty-proposed holds back landscape-common
[20:19] <free> mathiaz: hhm I don't understand this
[20:19] <slangasek> mathiaz: well, sure, but it's -proposed? :)
[20:20] <free> mathiaz: bug 444743 ?
[20:20] <free> mathiaz: or #347983
[20:20] <mathiaz> slangasek: ok - if that's fine by you, we can wait for pitti
[20:21] <slangasek> mathiaz: I'm not bothered by temporarily uninstallable packages in -proposed; but if you tell me you guys need to get this fixed today to be able to test it, that's another matter
[20:21] <mathiaz> free: ^^?
[20:21] <mathiaz> free: I think we can wait until tomorrow
[20:21] <free> yes sure
[20:22] <mathiaz> free: make sure that all relevant bugs related to smart have been documented correclty acccording to the SRU policy
[20:22] <free> mathiaz: it's just that somebody opened the bug, and I wanted to make sure there wasn's some other problem
[20:22] <mathiaz> free: and then ask pitti to process the jaunty-proposed smart update
[20:22] <free> mathiaz: that has been done
[20:22] <mathiaz> free: If I have time today I'll try to upload the intrepid smart SRU as well
[20:23] <free> mathiaz: sweet! thanks
[20:23] <debfx> slangasek: could you have a look at https://code.launchpad.net/~debfx/acpi-support/fix-lp387750/+merge/12466 - it adds kde4's powerdevil to the list of power managers
[20:23] <sbeattie> speaking of, do we have the ability to test the landscape-common SRU when it becomes available?
[20:24] <free> mathiaz: (that will need another landscape-client upload for intrepid-prosed as well, see bug 347983 and lp:~free.ekanayaka/landscape-client/intrepid.fix-347983)
[20:24] <mathiaz> free: ok
[20:26] <free> sbeattie: how you mean?
[20:28] <sbeattie> free: just trying to figure out the who and the how of verifying all the fixes.
[20:30] <free> sbeattie: well, you'll need a Landscape account, and to go through each bug
[20:31] <free> sbeattie: they've been QA-ed already thought, see https://wiki.ubuntu.com/LandscapeUpdates
[20:31] <free> s/thought/though/
[20:36] <kirkland> cjwatson: i'm confused as to when does debian/local/euca_find_cluster.c get built?
[20:36] <kirkland> cjwatson: i didn't see it build with bzr builddeb
[20:37] <kirkland> cjwatson: hmm, okay, it's part of the udeb build
[20:53] <slangasek> debfx: fwiw, that commandline scares me :)
[20:53] <slangasek> debfx: I did look at it before, but the commandline made me postpone it
[20:54] <slangasek> debfx: one improvement I see is that you should be able to avoid the export by stringing the commands together in a slightly different manner
[21:05] <mdz> say, isn't rhythmbox supposed to be able to extract and encode CDs these days?
[21:09] <seb128> mdz, what gstreamer-plugins-base0.10 do you have?
[21:09] <seb128> mdz, libgstreamer-plugins-base0.10-0
[21:09] <mdz> ii  gstreamer0.10-plugins-base                 <IP_ADDRESS>-1ubuntu1                         GStreamer plugins from the "base" set
[21:10] <seb128> mdz, ok, update, it has been fixed in karmic today
[21:10] <mdz> seb128, oh, thanks
[21:10] <mdz> seb128, shouldn't you be in bed soon? ;-)
[21:10] <mdz> I upgraded just a few hours ago, I guess I must have just missed it
[21:11] <debfx> slangasek: I just noticed it doesn't work when there are multiple kded4 running
[21:12] <slangasek> debfx: that was going to be my next question :)
[21:12] <seb128> mdz, give us another slot to hire an extra desktop team GNOME maintainer and I will go to bed earlier ;-)
[21:12] <debfx> slangasek: is there an easy way to get the uid/username of a process?
[21:12] <seb128> mdz, joke aside I'm still looking at a gconf issue but will try to stop not to late ;-)
[21:14] <slangasek> debfx: ps -o user= <pid>
[21:15] <debfx> slangasek: wouldn't it be sufficient to add kde4d to the pidof list, can't imagine anyone wants acpi-support power managment when he's running kde
[21:16] <slangasek> debfx: that would be inconsistent with how we handle the other desktops, though
[21:16] <directhex> oh, are the colours all wrong for fullscreen video via the moz totem plugin for anyone else?
[21:17] <mok0> debfx: of course, if can become superuser, you can go to /proc/<pid> and get ALL kinds of nice info about the process
[21:20] <mdz> seb128, you already got one, and he should be awake soon :-)
[21:21] <seb128> mdz, right, I'm waiting for him, with 3 of us we could do 8 hours shifts ;-)
[21:25] <smoser> slangasek, ping
[21:25] <smoser> when i use the 'checksum-directory', it will overwrite MD5SUMS, right?
[21:25] <slangasek> smoser: yes
[21:26] <smoser> asking because i'd like to have MD5SUM of uncompressed and compressed image
[21:26] <slangasek> smoser: why?
[21:26] <slangasek> we only ship a compressed image
[21:26] <smoser> and only compressed is around when it runs.
[21:26] <slangasek> having a checksum of the uncompressed image provides only minimal security
[21:26] <smoser> no terribly good reason
[21:26] <smoser> other than it takes on the order of 10 minutes to uncompress that image
[21:26] <mdz> kirkland, FYI I did a cloud install with 20091007.1 and auto-registration appears to have worked perfectly
[21:27] <slangasek> (in fact, since you're only shipping unsigned md5sums, I would argue it provides *no* security :)
[21:27] <slangasek> smoser: I think we should only provide one md5sum per file in the index, and drop the md5sum for the uncompressed images
[21:28] <smoser> slangasek, that will be fixed. i guess i dont have a terribly good argument. i'm not so much interested in security here only in convienence of having the uncompressed md5sum around.
[21:28] <smoser> once you've uncompressed it, theres kind of no going back to get the original that you could have verified
[21:28] <smoser> (where "original" = "compressed")
[21:29] <smoser> and i've been in that situation before, trying to identify this 10G binary and decide if I have to pull the 500M again.
[21:29] <smoser> so, thats the best i can do.
[21:29] <smoser> i'll change scripts to use checksum-directory today
[21:30] <slangasek> ah, I see
[21:31] <slangasek> I would've assumed that you keep the compressed image around next to it
[21:31] <smoser> yes. that would make sense :)
[21:31] <smoser> but 'gunzip' and its gone.
[21:31] <slangasek> right, taking with it your target for rsync :)
[21:32] <slangasek> if you feel strongly about it, we can patch checksum-directory to recognize that .gz images should also be uncompressed and checksummed, but I think that's just going to slow down publishing inconveniently
[21:32] <mdz> seb128, hmm, even after upgrading, I'm having some problems with CD extraction
[21:33] <mdz> rhythmbox doesn't seem to even see the CD
[21:33] <mdz> sound-juicer only sees the internal drive, not the external one (only one option in the drop-down)
[21:33] <mdz> if I rename sr1 to sr0 (!), sound-juicer works, but still not rhythmbox
[21:33] <seb128> mdz, is the cdrom listed in gvfs-mount -li or the computer location?
[21:33] <smoser> for now i do not feel strongly enough.
[21:34] <mdz> seb128, gvfs-mount -li shows only /dev/sr0
[21:34] <mdz> (which is now the external drive)
[21:34] <seb128> mdz, is the other drive listed in devkit-disks --dump or not?
[21:36] <mdz> seb128, devkit-disks --dump shows both
[21:36] <seb128> mdz, ok, can you open a gvfs bug with the devkit-disks --dump and gvfs-mount -li logs?
[21:37] <mdz> also ejecting in sound-juicer didn't work, but eject(1) did
[21:37] <mdz> seb128, certainly
[21:37] <seb128> mdz, thanks
[21:38] <mdz> seb128, there don't seem to be any apport hooks for the gvfs packages; would you accept a patch which attached devkit-disks --dump and gvfs-mount -li to gvfs bugs by default?
[21:38] <seb128> mdz, yes, looks a good idea, in fact pitti has an interactive hook for devices detections issue he wrote during distro sprints
[21:39] <seb128> the gvfs could probably be based on that
[21:39] <seb128> maybe check with him before writing one
[21:40] <mdz> pitti, ^^ when you're around next
[21:40] <seb128> mdz, ubuntu-bug storage
[21:40] <seb128> in fact
[21:40] <seb128> apport-symptoms: /usr/share/apport/symptoms/storage.py
[21:43] <mdz> seb128, bug 445787 FTR
[21:43] <seb128> mdz, thanks
[21:44] <seb128> mdz, the interactive hook seems rather made to direct the bug at the right place, getting logs would probably be easy though if you want to send a patch for that ;-)
[21:45] <seb128> mdz, do you have disks in those drives?
[21:45] <mdz> seb128, right, it picks the package, then will run whatever hooks the package provides
[21:45] <debfx> slangasek: http://paste.ubuntu.com/288100/ should work
[21:45] <mdz> seb128, I had ejected it when I ran the commands; should I get the output with media inserted as well?
[21:45] <seb128> mdz, "  has media:                   0" for both sr0 and sr1
[21:45] <seb128> mdz, that would be nice yes, at least in the one you want to use
[21:45] <mdz> seb128,   has media:                   1 (detected at Wed 07 Oct 2009 09:44:15 PM BST)
[21:46] <mdz> seb128, attached to the bug as well
[21:50] <seb128> mdz, and it's still not in gvfs-mount -li or in the computer location?
[21:51] <mdz> seb128, correct
[21:51] <mdz> computer:/// only shows one CD/DVD reader and it is the internal (empty) one
[21:52] <cjwatson> LaserJoc1: ship-addon looked more appropriate to me (normally dvd is a superset of nearly everything else), but I'm sure ship would work too
[21:53] <cjwatson> LaserJoc1: it just needs to (transitively) include d-i-requirements
[21:55] <debfx> slangasek: updated the merge request
[21:56] <LaserJoc1> cjwatson: ok, I just was trying to avoid using addon stuff for the DVD
[21:57] <mdz> cjwatson, I have a ubiquity install which is hung at "Configuring apt"
[21:57] <cjwatson> LaserJoc1: I remember not being sure
[21:57] <cjwatson> mdz: evand fixed that a few hours ago, I'm about to upload
[21:57] <mdz> cjwatson, ok, thanks
[21:57] <cjwatson> mdz: bug 445385
[21:57] <seb128> mdz, do you have a sr1 entry in fstab?
[21:59] <mdz> seb128, perseus:[~/Music] grep sr /etc/fstab
[21:59] <mdz> zsh: exit 1     grep sr /etc/fstab
[22:00] <seb128> mdz, hum ok, I don't know offhand then, I will look at the code tomorrow and ping you back
[22:00] <seb128> or rather comment on the bug
[22:00] <mdz> seb128, sure, thanks
[22:00] <LaserJoc1> cjwatson: the seed soup is a bit hard to untangle this far up :-)
[22:01] <cjwatson> if you have to untangle your soup, you're Doing It Wrong
[22:02] <LaserJoc1> cjwatson: I'm trying to figure out how to get everything on the DVD, but only what we need
[22:02] <LaserJoc1> cjwatson: we jumped from a 300 MB addon to a 3+ GB DVD so I'm trying to keep things as light as I can
[22:03] <LaserJoc1> as well as keep the maintanence low, trying to rely on Ubuntu's seeds as much as possible
[22:14] <mdz> mathiaz, kirkland, ping?
[22:16] <mdz> oh, neat, that worked: LiveMediaBuild: Ubuntu 9.10 "Karmic Koala" - Alpha armel+imx51 (20091007)
[22:17] <mdz> I hadn't actually seen bugs come in with that apport data
[22:37] <smoser> slangasek, just fyi, i just remembered that i had put a script in ~vmbuilder/bin named 'build-nightly' that takes a single arg (the suite) and should build correctly
[22:45] <cjwatson> LaserJoc1: seems reasonable enough to get rid of the addon stuff if you want, certainly
[23:42] <rickspencer3> cjwatson, just saw this question in #ubuntu-x
 how do I disable services at boot in the brave new world of native upstart scripts?
[23:42] <rickspencer3>  the services applet seems to have disappeared
[23:42] <rickspencer3> is there a link or something I could point him to?
[23:43] <chrisccoulson> rickspencer3: bug 433701
[23:43] <chrisccoulson> it was disabled because it doesn't work with upstart jobs
[23:43] <rickspencer3> right
[23:43] <robbiew> hmm
[23:43] <rickspencer3> so what do we do?
[23:43] <rickspencer3> edit init.conf or some such?
[23:43] <chrisccoulson> it needs some effort to port it
[23:44] <rickspencer3> yeah
[23:44] <chrisccoulson> although the upstream developer might already be working on it
[23:44] <chrisccoulson> i didn't realise so many people found this tool useful
[23:44] <rickspencer3> this is jbarnes asking, so I'm sure he can manage editing a conf file or whatever
[23:44] <rickspencer3> i just don't know where to point him
[23:44] <chrisccoulson> i'm not sure either
[23:45] <chrisccoulson> i don't know how you disable services anymore and stop them running on subsequent boots
[23:45] <rickspencer3> put a file in /etc/intit ?
[23:46] <chrisccoulson> yes, if you want to add a service. but does he want to disable one?
[23:46] <rickspencer3> would you not just rename it>
[23:46] <rickspencer3> ?
[23:46] <chrisccoulson> possibly, but i haven't tried
[23:46] <slangasek> mv /etc/init/$foo.conf /etc/init/$foo.conf.disabled
[23:46] <rickspencer3> thanks slangasek
[23:46] <rickspencer3> :)
[23:46] <robbiew> and the voice from above speaks
[23:46] <robbiew> lol
[23:46] <chrisccoulson> heh
[23:47]  * slangasek gets down off the step stool
[23:47] <chrisccoulson> i've never felt compelled to mess around with the services on my machine ;)
[23:49] <slangasek> sometimes you have to debug them :)
[23:49] <slangasek> (well, s/you/we/)