[00:12] <Riddell> ikonia: pong
[02:45] <micahg> can we still upload SRUs to maverick-proposed on the assumption they will be copied to natty if maverick_version = natty_version?
[02:46] <hallyn> doesn't an sru require fix committed in natty first?
[02:47] <micahg> hallyn: well, normally yes, but I seem to recall a discussion about a script that auto copies stuff from maverick-updates to natty if maverick_version = natty_version
[02:54] <hallyn> micahg: <shrug>  could well be, just doesn't match my understanding of the process.  my being wrong is by no means unlikely :)
[02:58] <ebroder> micahg: My understanding was that that automated process was only for SRUs uploaded before the natty archive opened.
[03:27] <ebroder> Was there a change made to plymouth between lucid and maverick that affects when the graphical vs. text splash screen is used?
[03:28] <ebroder> On lucid I would ~always see a graphical splash, and if KMS wasn't working it would just be low res and low color. On maverick I seem to get a text splash if KMS doesn't work
[03:33] <RAOF> ebroder: Yeah.  We turned off vga16fb to stop it *breaking everything*
[03:34] <RAOF> Rather, there were a number of cases where vga16fb would load, scribble over the graphics state that the kms drivers were sure wouldn't change, and hang the machine.
[03:34]  * ajmitch prefers the text splash :)
[03:34]  * RAOF too.
[03:34] <psusi> why?
[03:34] <RAOF> It's *delightfully* geeky.
[03:35] <lifeless> it boots my hardware
[03:35] <ebroder> ROAF: Where was that change made? It doesn't look from the changelog like it was done in plymouth itself?
[03:35] <psusi> I'm looking forward to grub immediately going graphic mode and staying that way
[03:35] <lifeless> what I'd be happiest with is something that doesn't trash progress output from non lsb scripts.
[03:35] <psusi> should be real nice if we ever get the grub gfxmenu set up by default
[03:35] <lifeless> that would be like way retro: a readable boot console
[03:35] <StevenK> lifeless: If it boots your hardware, you're one of the 1% or so :-)
[03:36] <lifeless> StevenK: nokms boot my hardware
[03:36] <lifeless> StevenK: everything else is fail
[03:36] <RAOF> ebroder: It was made in the kernel, around the time of the Prague sprint when I went in to the kernel room and asked them to kindly stop breaking graphics ;)
[03:37] <ebroder> RAOF: Ah, got it
[03:37] <ebroder> RAOF: So...probably not something I could turn on in configuration if I was interested in living dangerously
[03:38] <RAOF> You could get vga16fb to load; you just need to do it manually.
[03:39] <RAOF> Although vesafb is probably a better bet; throwing a vga= on the end of your kernel command line should do it.
[03:56] <ebroder> RAOF: Can I do that by hand by passing module arguments or something?
[03:57] <ebroder> I guess I can probably just look in the source for that
[03:57] <RAOF> Add “vga=ask” to your kernel command line in grub, after “quiet splash”
[03:57] <RAOF> Then when you boot the kernel will list the possible vesa modes, and you can select one.
[03:58] <ebroder> RAOF: Right, but I want to setup something where it'll only use vesafb if KMS doesn't work (i.e. proprietary drivers). I'd prefer to not set a mode for all boots
[03:58] <RAOF> Ah, yeah.  That's more difficult.
[03:58] <ebroder> So I'm thinking of trying to pull something evil together like an initramfs script that runs after udev and before plymouth
[03:59] <RAOF> I guess you could manually modprobe vesafb
[04:00] <RAOF> *uvesafb
[04:00] <ebroder> RAOF: Ah, that's what I was missing. I was looking at vesafb instead of uvesafb. Awesome, thanks
[04:05] <ebroder> RAOF: Actually, do you know what happens if I just load uvesafb when a KMS driver already set the mode? Is it a NOOP, or does it break things?
[04:05] <RAOF> If uvesafb touches the graphics state it's likely that the kms driver will explode into a thousand pieces.
[04:06] <RAOF> Alternatively, it's possible that the kms driver will have changed the graphics state enough that *uvesafb* will explode in a thousand pieces :)
[04:07] <ebroder> But either way if it's going to do something horrible, I should be able to test this and see something explode fairly obviously? It looks like passing video=uvesafb: might cause the /init-top/framebuffer script to do what I want
[04:09] <RAOF> Sadly it's not guaranteed to explode immediately.  For example, when vga16fb was loaded, for most people it created /dev/fb1, which didn't get opened by anything.  But as soon as something *tried* to open /dev/fb1, graphics would hang.
[04:10] <RAOF> There was a popular launchpad bug “Running hwinfo -C causes the screen to go green”, caused because hwinfo probed /dev/fb1.
[04:17] <RAOF> ebroder: Now that I think of it, the kms drivers have code to kick off a generic driver like uvesafb.  If you could guarantee that uvesafb loaded first you'd probably only have the problems with seamless-grub that caused it to slip for Maverick :)
[04:20] <ebroder> RAOF: Ok, I can try that
[04:27] <Sarvatt> vesafb loads early->plymouth loads framebuffer renderer plugin instead of drm->drmfb loads and kicks out vesafb->plymouth segfaults and your boot is screwed was the problem in maverick
[04:28] <RAOF> Sarvatt: And wasn't there also one where radeon just plain died?
[04:28] <ebroder> Oh, uh. Hmm...
[04:28] <ebroder> Maybe I shouldn't try that...
[04:29] <RAOF> I seem to recall that if you loaded the kms drivers into the initramfs it worked ok.
[04:29] <Sarvatt> it was ok packed in the initrd but it was racy, 1 out of 10 boots or so would die here
[04:31] <RAOF> Oh, that reminds me.  Time to un-framebuffer my grub so that I can actually see it.
[04:31] <ebroder> Couldn't you work around that just by doing a udevadm settle in the udev initrd script?
[04:31] <ebroder> (Doesn't it do that already...?)
[04:31] <ebroder> Ah, no - just a trigger
[04:32] <RAOF> I don't think it does, as that would kill boot performance?
[04:32] <ebroder> What about something like trigger fb devices, settle, trigger everything else?
[04:34] <RAOF> With a "load uvesafb if no other fb devices" bit?
[04:34] <RAOF> You'll still lose quite a lot of boot time; i915 is pretty slow at initialising (from memory, pitti suggested it was ~2sec worth of initialisation)
[04:35] <ebroder> Ouch. That's pretty bad
[04:38] <ebroder> I...think I'm suitably convinced that I should figure out how to solve my problems using the text splash :)
[04:42] <RAOF> It's still a goal to make seamless-grub work in Natty, I think, so you could piggy-back on that effort.
[04:42] <RAOF> I don't think that's a solved problem yet, though.
[04:43] <ebroder> RAOF: Yeah, I've got the workitem to figure out how to make hardware blacklisting/whitelisting work. I'm hoping to get that sorted out during some of my Thanksgiving time off
[05:19] <jfer> can someone help me with packaging skype-call-recorder? it is my firsty package
[05:19] <jfer> *first
[07:33] <dholbach> good morning!
[07:42] <bilalakhtar> Good morning dholbach
[07:42] <dholbach> hey bilalakhtar
[07:59] <didrocks> good morning
[08:12] <pitti> Good morning
[08:13] <RenatoSilva> anyone involved with purple-plugins-pack?
[08:14] <micahg> RenatoSilva: I use it
[08:15] <RenatoSilva> there's a typo bug which leads to a plugin not being included
[08:15] <micahg> RenatoSilva: ok, can you file a bug and give me the bug #?
[08:21] <RenatoSilva> I think ircmore was renamed to irc-more for some crazy reason, but the package maintainer didn't notice and package config is still outdated
[08:22] <RenatoSilva> what is funny is that the package was succesfully built even when trying to include a non-existing plugin
[08:23] <micahg> debian 604763
[08:24] <micahg> filed an hour ago
[08:24] <RenatoSilva> micahg: should still file one in Launchpad?
[08:25] <micahg> RenatoSilva: well, we don't currently have a diff, but if the change is small enough, we might be able to SRU, so yes
[08:26] <micahg> RenatoSilva: are you able to provide a debdiff for it?
[08:26] <micahg> RenatoSilva: actually, we should really move this to #ubuntu-motu
[08:27] <sladen> what happened to UpstreamVersionFreeze, did that get rolled into FeatureFreeze?
[08:27]  * micahg didn't know there was an upstreamverisionfreeze :-/
[08:28] <micahg> sladen: seems to fit the definition here: https://wiki.ubuntu.com/FeatureFreeze
[08:29] <RenatoSilva> micahg: I'm there
[09:04] <bilalakhtar> I got this email today, even though the source package got accepted: http://paste.ubuntu.com/535806/
[09:05] <bilalakhtar> Could someone archive-admin please look at it
[09:06] <bilalakhtar> binaries of other archs also got into the archive
[09:17] <mr_pouit> bilalakhtar: https://launchpad.net/ubuntu/+source/gcc-defaults/1.82ubuntu2
[09:19] <soren> bilalakhtar: In a nutshell, another source package has built those binary packages with a newer version.
[09:21] <mvo> soren: could you please have a look at https://code.launchpad.net/~mvo/vmbuilder/add-natty/+merge/40977 ? or alternatively give me access to trunk so that I can just merge it myself?
[09:21] <mvo> (or tell me who to nag instead ;)
[09:26] <dholbach> Amaranth, heya - who's maintaining alacarte upstream now? I was just looking at gnome bug 608221
[09:30] <soren> mvo: I'm still the closest VMBuilder has to a maintainer.
[09:37] <seb128> dholbach, nobody
[09:37] <seb128> dholbach, it's not actively maintained for a while
[09:37] <dholbach> seb128, that explains it :)
[09:48] <bilalakhtar> Did someone reply to my thing?
[09:49] <micahg> bilalakhtar: gcc-defaults is building the source package, you should probably talk to doko
[09:49] <micahg> s/source/binary
[09:49] <bilalakhtar> okay, thanks, micahg
[09:50] <micahg> bilalakhtar: mr_pouit responded with that above :)
[09:50] <bilalakhtar> thanks
[09:50] <soren> mvo: Let me take a look.
[09:50] <bilalakhtar> actually, my system went down due to processor overheat
[09:50] <bilalakhtar> and I am fed up of this laptop
[09:54] <vish> dholbach: i had spoken to Amaranth about that bug a while ago, and he mentioned we can patch it in Ubuntu.. since upstream is unmaintained..
[09:55] <vish> the alacarte one..
[10:22] <cjwatson> stgraber: done
[10:47] <gaurava> hey all .. from yesterday .. I am struggling to setup a serial console on my ubuntu 10.10 machine ..
[10:47] <gaurava> ny help would be great
[10:47] <gaurava> I am basically following this article for the setup <https://help.ubuntu.com/community/SerialConsoleHowto> but no luck so far
[10:47] <gaurava> Then I simply connect the serial cable .. and trying to write on it .. by using command: $ > ehco "abcd" > /dev/ttyS0
[10:48] <gaurava> I can see that interrupts assigned to /dev/ttyS0 (IRQ - 4) is increasing ..
[10:48] <gaurava>  but still there is no output on the other machine ..
[10:48] <gaurava> group ..  ny idea what is going on and how can  i troubleshoot the problem further?
[10:48] <cjwatson> use a proper serial console client, such as picocom, rather than writing directly to the device.  also make sure the baud rate and other settings match on both sides.
[10:51] <gaurava> cjwatson, baudrate is same on both of my machines..
[10:51] <gaurava> will try with the picocom on the sender side.. already using the minicom on the receiving end
[10:52] <cjwatson> picocom, minicom, whatever
[11:04] <gaurava> cjwatson,  can we use the picocom/minicom to send the data ?
[11:05] <cjwatson> yes, if I'm understanding you correctly
[11:05] <cjwatson> this really isn't a topic for #ubuntu-devel though ...
[11:05] <gaurava> ok .. in dat case can you point me to the right forum/direction..
[11:05] <Chipzz> #ubuntu or the forums
[11:07] <gaurava> thanks Chipzz, since setting up serial console is the prestep to debug a kernel crash, I thought one can ask this question over here..
[11:07] <Chipzz> you could try on #ubuntu-kernel
[11:07] <Chipzz> but I'm not 100% sure if it's appropriate there
[11:08] <gaurava> ok thanks once again .. will try my luck over there
[11:08] <Chipzz> gl getting it to work!
[11:08] <Chipzz> btw, are you sure you're using the right cable?
[11:08] <Chipzz> and if it's working correctly?
[11:09] <gaurava> I am not sure.. i just bought these cables from the market yesterday itself ..
[11:09] <gaurava> so i guess.. they  would be fine
[11:10] <Chipzz> right, probably should be. but there are serial cables and then there are serial cables
[11:10] <gaurava> :)
[11:10] <gaurava> if there is any quick test that I can run upon or ask someone else to check if the cables are fine or not?
[11:11] <Chipzz> not sure, been a while since I messed with serial cables
[11:11] <Chipzz> but I recall there being more than one way to wire them
[11:11] <Chipzz> anyway, try on #ubuntu-kernel ;)
[11:11] <gaurava> thanks once again .. will ping over there
[11:41] <Amaranth> dholbach: I didn't see much point in fixing the little bugs while the big ones were still there then the big ones required a spec change then I gave up
[11:41] <dholbach> a spec change?
[11:42] <Amaranth> dholbach: Yeah, NoDisplay has too many meanings
[11:43] <dholbach> ah ok, still it might be good to fix the small bugs already :)
[11:43] <dholbach> but I understand - a shame that nobody has the time to look after it :/
[11:44] <Amaranth> dholbach: Once the discussion on changing the spec didn't get anywhere I decided the menu system was even more broken than I thought when I was writing alacarte
[11:44]  * dholbach nods
[11:44] <Amaranth> So I switched to docky and gnome-do and removed my menu
[11:44] <Amaranth> Someone else was trying to maintain it for awhile, even made a release or two
[11:45] <ogra_ac_> cjwatson, urgh, thanks for spotting the shadow issue, i somehow only looked at the conflicts in the report on MoM
[11:45] <dholbach> thanks Amaranth
[11:45]  * ogra_ac_ merges now
[11:45] <Amaranth> dholbach: heh, thanks for depressing you? :)
[11:46] <dholbach> no for the feedback
[11:46] <cjwatson> ogra_ac_: ok, please mark the sync bug Invalid then
[11:46] <ogra_ac_> will do
[11:46] <dholbach> it's that there's a patch in the sponsoring queue right now and it seems nobody uploaded because upstream didn't comment on it
[11:46] <cjwatson> (there's a little archive admin script that prints all the changes since the last Debian upload; I routinely use it as a quick validator for sync requests)
[11:47] <Amaranth> dholbach: The only patches I don't agree with are ones that add UI but someone else was making releases so I don't consider myself the maintainer anymore
[11:47] <ogra_ac> well, i could have looked at the merged changelog first
[12:41] <Daviey> no patch pilot :(
[12:44] <cjwatson> it's mterry's turn today, but he's probably not around yet
[12:45] <cjwatson> for the rest of this week there's only one pilot per day on the schedule
[12:48] <BlackZ> cjwatson: can you please retry the build of the last apr version in natty?
[12:48] <BlackZ> cjwatson: on all archs..
[12:51] <cjwatson> BlackZ: what changed since the initial attempts?
[12:51] <BlackZ> cjwatson: bug #671441 got fixed in launchpad-buildd
[12:52] <cjwatson> BlackZ: ok, thanks, retried
[12:52] <BlackZ> cjwatson: thank you :)
[13:14] <freeflying> pitti, ping
[13:22] <sebner> cjwatson: thanks for the quick syncs :) Should I use syncpackage in future as it's extrawork for you? I'm not really in a hurry so I use still requestsync
[13:23] <cjwatson> no, please don't, requestsync is very little work nowadays
[13:23] <cjwatson> syncs are generally processed at least daily
[13:23] <sebner> cjwatson: aye aye :)
[13:32] <doko> ScottK: no, gcc-defaults has just a symlink
[13:32] <ScottK> doko: OK.  Thanks.
[13:34] <ScottK> doko: Another gcc issue that I think needs some investigation is in this build log.  It looks like it's trying to buid in /usr/lib64 (built fine on Debian): http://launchpadlibrarian.net/58604511/buildlog_ubuntu-natty-amd64.libclamunrar_0.96.4-1_FAILEDTOBUILD.txt.gz
[13:35] <doko> ScottK: that should be fixed in the package
[13:36] <bdrung> sebner: use requestsync - some people don't like syncpackage
[13:36] <sebner> bdrung: I noticed =)
[13:36] <ScottK> doko: Is gcc in Ubuntu intended to be different than in Debian about this?
[13:36] <doko>  /usr/lib64 is fine, but it's a symlink
[13:36] <doko> 4.4 != 4.5
[13:36] <ScottK> OK.
[13:36] <ScottK> So what 4.5 change is this?
[13:37] <doko> I think I fixed it in the repo, but the assumption of the package is just wrong
[13:38] <doko> same with the 4.5.x and 4.5 symlink in gcc_lib_dir
[13:39] <mterry> @pilot in
[13:39]  * mterry waves
[13:39]  * dholbach hugs mterry
[13:39] <dholbach> woohoo!
[13:40] <sebner> cjwatson: ah, I just noticed your comment. Of course we are before DIF! Sorry for that. Just a habit
[13:40]  * sebner hugs dholbach =)
[13:40] <dholbach> hey sebner
[13:41] <cjwatson> sebner: np
[13:51] <czajkowski> ShaneM: get sorted?
[13:51] <ShaneM> czajkowski: Just doing it now.
[13:53] <czajkowski> ok
[13:55] <ari-tczew> mterry: could you sponsor bug 663343?
[13:56] <mterry> ari-tczew, looking at it
[14:06] <ari-tczew> mterry: IMO set as won't fix and unsubscribe sponsors ^^
[14:08] <mterry> ari-tczew, well, the patch from clint looks legit.  I think I'll take advice from Barry and open a new bug for it though
[14:09] <ari-tczew> mterry: Debian has older version.
[14:10] <mterry> ari-tczew, agreed.  We wouldn't downgrade the version, but the Debian maintainer made some packaging changes at the same time as they updated the version.  In Ubuntu, we leapfrogged that version, but didn't make the same packaging chagnes
[14:10] <mterry> They were good changes, so we should 'sync' up with those changes
[14:11] <ari-tczew> mterry: aha, so go ahead
[14:13] <highvoltage> 14:37 < stgraber> cjwatson: Hi, could you move sabayon from the ubuntu-desktop package set to the edubuntu packageset. It's a gnome upstream project but is only shipped by edubuntu and one of the upstream developers is in edubuntu-dev.
[14:13] <highvoltage> cjwatson: did you perhaps have any chance to look at that?
[14:14] <cjwatson> highvoltage: 10:22 <cjwatson> stgraber: done
[14:18] <highvoltage> cjwatson: merci!
[14:32] <mterry> ari-tczew, so I moved the bug and commented on the patch, but I can't actually upload to main.  But it should be all ready to go
[14:33] <ari-tczew> mterry: ah, you're not core-dev member
[14:33] <mterry> nope.  QQ
[14:39] <bdrung> mterry: are you waiting for the next sponsor request?
[14:41] <mterry> bdrung, if you have a suggestion, I'll look at it.  But I'm going through the queue otherwise
[14:41] <bdrung> mterry: my suggestion is to go to http://reports.qa.ubuntu.com/reports/sponsoring/ and start from the top.
[14:42] <mterry> bdrung, :)  OK thanks
[14:42] <bdrung> mterry: the list is sorted by time in queue. picking the one on the top would processing the list like a queue. :)
[14:42] <bdrung> mterry: do you know sponsor-patch?
[14:44] <mterry> bdrung, no, that's nice!  I do that manually.  So painful
[14:44]  * mterry adds these notes to the patch pilot wiki
[14:44] <smoser> pitti, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/671103 put new cloud-init into -proposed, but it brought a new binary package
[14:45] <smoser> which needs to be allowed into the archive
[14:45]  * cjwatson lands >3 months of grub2 changes on Ubuntu at once and hopes that people's systems still boot
[14:45] <smoser> (grub-legacy-ec2).  Can someone allow that backport in ?
[14:45] <bdrung> mterry: i wrote sponsor-patch to make sponsoring simple. it does many checks and tries to build the package.
[14:49] <highvoltage> ooh, risky updates! I'll be sure to test!
[14:49] <AbsintheSyringe> once Ubuntu does move to rolling releases, will it be based on Debian CUT or ... ?
[14:50] <bdrung> AbsintheSyringe: i think someone over-interpreted something
[14:50] <ogra_ac> whats debian CUT ?
[14:50] <AbsintheSyringe> bdrung, how come?
[14:50] <ogra_ac> a new name for experimental ?
[14:51] <AbsintheSyringe> ogra_ac, no no http://kitenet.net/~joey/code/debian/cut/
[14:51] <AbsintheSyringe> there was a lecture on this years debconf10, and I think this is the way to go actually
[14:51] <bdrung> AbsintheSyringe: gimme your sources
[14:51] <ogra_ac> aha
[14:52] <AbsintheSyringe> bdrung, http://linux.slashdot.org/story/10/11/24/1346221/Ubuntu-May-Move-To-Rolling-Releases?from=fb
[14:52] <AbsintheSyringe> I personally think Debian CUT and Ubuntu rolling releases are future towards all linux platforms should be heading to, including android
[14:53] <AbsintheSyringe> and I remember there was talk about ubutnu rolling releases before this, just can't remember where
[14:54] <cjwatson> AbsintheSyringe: at present Ubuntu has no plans I'm aware of to move to a rolling model
[14:55] <AbsintheSyringe> cjwatson, hype?
[14:55] <cjwatson> I think overinterpreted long-term thoughts, perhaps
[14:55] <cjwatson> I hadn't seen that comment from Mark before now
[14:55] <bdrung> AbsintheSyringe: think about the extra repository - this is the first step in the direction of more frequently updates
[14:56] <AbsintheSyringe> yea, I don't see it happening right now either, but on long term ... I think it should be done
[14:56] <AbsintheSyringe> bdrung, true ...
[14:57] <cjwatson> I suspect what we might end up with is a model with a stable base (of about the scale of current Ubuntu) and a collection of software-center-accessible PPAs with newer versions of things so you can pick and choose; but I really don't know, as I say Mark's comment is new to me
[14:57] <cjwatson> it's certainly too early to be making concrete predictions about what it would be based on
[14:57] <ogra_ac> "Today we have a six-month release cycle," Shuttleworth said. "In an internet-oriented world, we need to be able to release something every day."
[14:58] <ogra_ac> intresting that they didnt make it "Ubuntu plans daily releases" on slashdot
[14:58] <pitti> smoser: I already NEWed it yesterday
[14:58] <smoser> pitti, ... so it requires an admin now ?
[14:58] <pitti> smoser: no, I already did that
[14:58] <smoser> i'm sorry for not understanding process. i just tried to verify and its not in archive
[14:59] <cjwatson> let me modify my previous comment: we have nothing at the moment that I know of that resembles a concrete tactical plan, rather than long-term strategy
[14:59] <bdrung> haha, imagine someone says: "ubuntu has daily builds" and a press guy writes "Ubuntu-May-Move-To-Rolling-Releases" :)
[14:59] <AbsintheSyringe> :D
[15:00] <pitti> smoser: "rmadison -s lucid-proposed -S cloud-init" says that it's in
[15:00] <smoser> at least wasnt in ec2 archive ... hmm. i dont see cloud-init either in proposed there. maybe that mirror is just beind.
[15:00] <pitti> smoser: so it might be mirror lag
[15:02] <sladen> cjwatson: isn't Mark's comment actually about the extras repo
[15:04] <jussi> pitti: for bu #617885 - how many people do you need to test it?
[15:06] <cjwatson> sladen: it's too short to be able to tell :)
[15:06] <jussi> thats bug 617885
[15:06] <pitti> jussi: usually one is enough
[15:06] <cjwatson> speculation filtered through news sites, what a way to go
[15:07] <jussi> pitti: so all good to up it to the repo propper now?
[15:07] <pitti> jussi: it needs to stay in -proposed for 7 days so that we have a chance to catch regression reports
[15:08] <jussi> pitti: ahh, ok. great. please ping me if you need more testers for that (or others similar)
[15:22] <seb128> doko, bug #677387
[15:22] <seb128> not sure we can do something about that
[15:22] <Gulfstream> I am using Natty (upgraded to it last night), and the bar above the window has disappeared (the bar for the minimize, maximize, and close buttons), is there a way to get it back?
[15:23] <seb128> I guess you need to build it manually if you need to start a port
[15:23] <seb128> Gulfstream, hi, try #ubuntu for user questions
[15:23] <jussi> Gulfstream: support for natty is in #ubuntu+1
[15:23] <doko> these are no build-deps, that's library incest
[15:23] <Gulfstream> #ubuntu+1
[15:23] <jussi> yes
[15:23] <Gulfstream> ?
[15:23] <Gulfstream> okay
[15:24] <Gulfstream> thanks
[15:24] <seb128> doko, well in any case it's not going to be worked
[15:24] <seb128> doko, libgnome is deprecated, we are getting ride of it at some point but not this cycle
[15:25] <doko> seb128: but honestly, it's time for a window manager in main, which doesn't depend on the whole of gnome
[15:25] <doko> metacity has the same dependencies
[15:25] <seb128> compiz?
[15:26] <seb128> it's the default wm and it depends on nothing from GNOME
[15:26] <ogra_ac> it depends on working GL
[15:26] <epictetus> it took me hours and hours to re-compile a working kernel package including the OSS emulation drivers. Pulseaudio is awful -- it solves a bunch of problems I never cared about and creates a bunch of new problems that I actually do care about.
[15:26] <seb128> ogra_ac, not really, 0.9 should fallback to 2d
[15:27] <ogra_ac> sweet !
[15:27]  * ogra_ac didnt know that
[15:27] <seb128> it might still be buggy in that regard because it's new but that should work
[15:27] <seb128> it should just turn off options that need gl
[15:27] <doko> seb128: "it"? how?
[15:28] <seb128> doko, how what?
 it should just turn off options that need gl
[15:28] <doko> and works on powerpc?
[15:28] <seb128> dunno about powerpc
[15:28] <ogra_ac> on ARM !
[15:29] <seb128> well that was discussed to use compiz 2d as fallback at UDS
[15:29] <seb128> they say the code is a bit young and might need work
[15:29] <doko> ok, so better stay away from it. honestly, I'd rather like to use twm, which doesn't change every few weeks ...
[15:31] <cjwatson> is the "Subscribe someone else" ajax thing on Launchpad bugs broken for anyone else?
[15:31] <ogra_ac> worked this morning for me
[15:31] <seb128> cjwatson, how broken?
[15:32] <seb128> doko, nobody stop you to use twm if you want
[15:32] <cjwatson> seb128: does nothing
[15:32] <cjwatson> hm, maybe I should try restarting firefox
[15:33] <doko> seb128: just needs promotion ...
[15:33] <seb128> cjwatson, works for me
[15:33] <seb128> I just tried on a bug
[15:34] <seb128> doko, you are in the mir team so just ack it ;-)
[15:34] <pitti> doko: if twm is so much easier, I don't see anything wrong with promoting it for these test cases
[15:35] <cjwatson> seb128: might be firefox 4 specific; I filed bug 681003
[15:37] <doko> pitti: I would prefer it, because you know that it doesn't change, and it does work
[15:38] <pitti> so, let's do that then?
[15:39] <doko> pitti: reopening the MIR. is it possible for past releases too?
[15:39] <pitti> I don't think we can change it in stables
[15:39] <pitti> we could do a no-change upload to -proposed, but frankly for those it seems easier to just use dbus-launch metacity
[15:41] <doko> maybe, at least the old versions don't depend on canberra
[15:43] <cjwatson> is anyone working on an evolution-couchdb upload for evolution 3.32?
[15:43] <seb128> cjwatson, I'm using firefox4 there
[15:44] <seb128> cjwatson, yes, rodrigo
 didrocks, ok, I'll release evo-couchdb, which includes the fixes to compile with 2.31/32, and package it
[15:44] <seb128> that was a bit earlier today
[15:45] <cjwatson> kees: you made cpu-checker depend on msr-tools in universe, so it's now uninstallable; can you deal with the MIR side of that?
[15:45] <cjwatson> ok
[15:52]  * ogra_ac sighs about shadow 
[16:41]  * SpamapS curses the baby for letting him sleep until 8:30am and miss the tech talk
[16:41] <cjwatson> it's only recently started
[18:03] <mterry> @pilot out
[18:26] <zul> pitti: will you accept a new SRU that has an upstart job that wasnt there before?
[18:27] <SpamapS> zul: rrwhhhzaaaa? that sounds a bit crazy. ;)
[18:27] <pitti> zul: would need a really good rationale; these can potentially break the system, so nothing with complex dependencies can be added
[18:28] <zul> pitti: this is the one https://bugs.edge.launchpad.net/ubuntu/+source/tgt/+bug/574554 i was talking about
[18:28] <zul> the upstart script is really simple and its not a widely used piece of software
[18:29] <pitti> zul: http://launchpadlibrarian.net/53388867/tgt_1.0.4-1ubuntu4.debdiff ?
[18:29] <pitti> zul: it would suddently start the daemon for people who have it installed, so that might be an unexpected behaviour change
[18:29] <zul> pitti: right
[18:29] <pitti> but it seems that the job is already there, but has a typo?
[18:30] <pitti> post-start is not the right place to launch the main daemon, thuogh
[18:30] <zul> pitti: i think its for lucid actually
[18:30] <nijaba> zul: yep, we would need it in lucid
[18:30] <pitti> ah, right, fixed in maverick already
[18:30] <pitti> my feeling is that we shouldn't do those behavioural changes a year after release; it's too unexpected
[18:31] <pitti> (in both directions)
[18:31] <zul> hmm...ok
[18:31] <pitti> -backports would be fine for me, if appropriate
[18:31] <zul> gotcha
[18:31] <nijaba> pitti: hmmm... that could work for me, indeed
[18:33] <nijaba> zul: so, backport?
[18:34] <zul> nijaba: yes
[18:34] <nijaba> zul: I just need to find the correct way to document activating this particular package from backport in the doc.  should not be too hard
[18:35] <zul> nijaba: https://help.ubuntu.com/community/UbuntuBackports
[18:36] <pitti> good night everyoen
[18:36] <nijaba> zul: pinning wilth apt-get install -t will work just great.  thanks a lot
[18:37] <zul> nijaba: no problems
[18:44] <ScottK> nijaba: What won't work with the repository pinned down is pulling depends also from backports.
[18:44] <nijaba> ScottK: sure, but for that particular, we don't have that req
[18:45] <ScottK> OK.
[18:45] <nijaba> ScottK: but thanks for letting me know
[18:56] <sladen> sense: re: papercuts-ninjas, I think the way that it is normally done is by subscribing the team (think ubuntu-archive and such) rather than assigning the team
[18:57] <sladen> sense: assigning the team means that the team will stop getting emails when somebody /on/ the team evetually subscribes themselves and makes it  In Progress
[19:36] <Keybuk> pitti: so do you think that talk was ultimately interesting or useful?
[19:37] <Keybuk> I hoped that by covering some of the design history, the reason for its differences for systemd would be apparent
[19:37] <Keybuk> but I'm not sure how successful I was at pulling that off
[19:41] <mmoya> is launchpad.net down?
[19:43] <htorque> mmoya, http://downforeveryoneorjustme.com/launchpad.net ;-)
[19:43] <htorque> mmoya, or simply: "no" :-)
[19:44] <mmoya> htorque: je, ok, didn't know that site
[19:46] <SpamapS> Keybuk: after the talk, its clear to me why upstart was written, and why Ubuntu will continue to use it. Its not clear to me why systemd was created instead of just working on the state refactor.
[19:46] <Keybuk> well indeed
[19:46] <Keybuk> that's never been clear to me
[19:46] <Keybuk> even if you assume Copyright assignment
[19:47] <SpamapS> which is what I assumed before, but now it doesn't seem so obvious
[19:47] <Keybuk> the upstart-socket-bridge process (if Lenny believes that's the killer feature) could have always been a separate tarball
[19:47] <Keybuk> upstart-udev-bridge is separate, after all
[19:47] <SpamapS> I also don't understand why service activation in the init daemon is all that key but thats probably because I'm a server kind of guy. ;)
[19:47] <Keybuk> to be honest, I simply think Lennart wants to personally write his own OS
[19:48] <Keybuk> it makes some amount of sense to have a single service supervisor
[19:48] <Keybuk> something that can start things, stop things and keep things running
[19:48] <Keybuk> so you may as well make it the init daemon
[19:49] <SpamapS> I like that part, I don't know about the network sockets being passed around bit.
[19:49] <Keybuk> well, in the design of upstart (and afaik systemd too) those are just separate services started by init
[19:49] <Keybuk> which themselves tell init to start services
[19:49] <Keybuk> so they're not "in the init daemon" - it's more that the init daemon is flexible enough to support people who want to do that
[19:50] <SpamapS> That makes more sense then.
[19:50] <SpamapS> I like the idea of having one, small file that defines the reason and method for a service starting and stopping.
[19:51] <SpamapS> instead of it being an init.d, or in inetd.conf , or xinetd.d .. or or or..
[19:51] <Keybuk> yeah, that's kinda a difference between systemd and upstart
[19:51] <Keybuk> upstart is all about "one file to define everything"
[19:51] <Keybuk> systemd is "one type of file to define one type of thing => lots of files to define *something*"
[19:52] <SpamapS> so, to answer your question, I do think that the history section was helpful to many of us who have only recently arrived or were not involved in the discussions..
[19:53] <SpamapS> But the discussion of systemd was harmed, I think, by Lenny's emotional rants.
[19:55] <Keybuk> ultimately Lenny doesn't understand why I think upstart's design is better
[19:55] <Keybuk> and therefore he'll never see the point
[19:55] <Keybuk> and I have a strong suspicion that if it suddenly clicked with him
[19:55] <Keybuk> and he realised why I like upstart's design
[19:55] <Keybuk> his reaction would be to go and write something like that into systemd
[19:55] <Keybuk> and come back with "there, systemd does that too, now you can use systemd?!"
[19:56] <mneptok> 12:48 < Keybuk> it makes some amount of sense to have a single service supervisor   <---- are you channeling my wife?!
[19:57] <Keybuk> mneptok: not only that, but she was channelling me last time you two were in bed together
[19:57] <SpamapS> =-o
[19:57] <mneptok> Keybuk: explains my greater-than-usual arousal. and her moustache.
[19:59] <highvoltage> If I understood what you were talking about I'd probably say "TMI".
[19:59] <Keybuk> TMK is probably equally valid
[20:18] <ebroder> AbsintheSyringe: Did you see rickspencer3's blog post? (http://theravingrick.blogspot.com/2010/11/ubuntu-is-not-moving-to-rolling-release.html)
[20:22] <AbsintheSyringe> ebroder, I haven't, I'll write my own post, it'll appear on planet debian, why this should be done
[20:23] <AbsintheSyringe> ebroder, well this post explains term "press" :)
[20:27] <AbsintheSyringe> ebroder, tnx for explain btw :)
[20:27] <AbsintheSyringe> clarification that is
[21:37] <bdrung> AbsintheSyringe: i was right. yeah :D
[21:40] <ari-tczew> SpamapS: around?
[21:51] <SpamapS> ari-tczew: yes, whats up?
[21:52] <ari-tczew> SpamapS: did you reconsider SRU for bug 370994?
[21:54] <SpamapS> ari-tczew: AFAICT its never been accepted
[21:54] <SpamapS> ari-tczew: once its accepted for Lucid (I think the other two are pretty unlikely at this point) then we can certainly backport.
[21:55] <SpamapS> ari-tczew: I'll bring it up at the next server team meeting.
[21:55] <ari-tczew> ok thanks for your feedback SpamapS
[21:58] <SpamapS> ari-tczew: btw, since drupal6 is universe, #ubuntu-motu may be a good place to ask.
[21:58] <ari-tczew> SpamapS: sure
[22:01] <bdrung> cjwatson: you broke my natty VM
[22:02] <SpamapS> bdrung: thats like the old TV commercial.. "you sunk my battleship!"
[22:03] <bdrung> SpamapS: 8 hours ago: "cjwatson lands >3 months of grub2 changes on Ubuntu at once and hopes that people's systems still boot"
[22:09] <bdrung> cjwatson: i end up in the grub terminal. what should i do to debug the issue?
[22:10] <sebner> bdrung: thanks you very much! Just wanted to do an update! :D :D :D
[22:10]  * sebner hugs bdrung 
[22:10] <bdrung> :)
[22:11] <bdrung> sebner: make an backup / snapshot and then try to upgrade grub. maybe you don't hit that bug
[22:11] <SpamapS> bdrung: no time like alpha1 for grub changes. ;)
[22:12]  * sebner hides
[22:12]  * sebner pokes cjwatson to fix the system of poor bdrung 
[22:13] <sebner> wahhh
[22:13]  * sebner just installed the grub update per accident xD
[22:15] <bdrung> sebner: then don't reboot. muhaha
[22:16] <sebner> xD
[22:16] <sebner> bdrung: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/657788
[22:21] <bdrung> sebner: maybe the problem was triggered by removing the old kernel
[22:24] <AbsintheSyringe> bdrung, yep you were :)
[22:31] <sebner> bdrung: hmm I think I'm too lazy to downgrade grub. so hibernate for today :D
[22:32] <bdrung> sebner: hibernate? isn't suspend the right mode?
[22:33] <bdrung> cjwatson: i have one menu entry in /boot/grub/grub.cfg: Ubuntu, with Linux 2.6.37-6-generic
[22:33] <sebner> bdrung: hmm, I neither use suspend to ram nor hibernate so I'm always mistaking them xD
[22:34] <bdrung> sebner: i am using suspend a lot on my desktop (because the bios takes too long to boot)
[22:34] <sebner> bdrung: /here rebooting is actually faster than suspend to ram + extra time until wlan works again
[22:35] <bdrung> sebner: my bios takes ~ 30 secs till grub and then http://overbenny.wordpress.com/2010/04/03/ubuntu-10-04-lucid-lynx-boots-fast/
[22:39] <sebner> bdrung: that's really epic fail xD
[22:40] <bdrung> sebner: gimme 400 bucks and i will replace the mainboard with as faster bios ;)
[22:42] <sebner> bdrung: ask canonical instead, /me is a poor student :P
[22:42] <bdrung> sebner: me too :)
[22:46] <cjwatson> bdrung: what happens if you say 'insmod normal' and then 'normal'?
[22:46] <cjwatson> might get better errors that way
[22:47] <cjwatson> sebner: doubt it's the same as bug 657788
[22:47] <cjwatson> don't confuse symptom with cause :)
[22:48] <bdrung> cjwatson: error: unknown command 'lua'.
[22:48] <bdrung> syntax error
[22:49] <bdrung> incorrect command
[22:49] <cjwatson> huh, interesting
[22:49]  * cjwatson blames ebroder :-)
[22:49] <ebroder> Wait we have lua now?
[22:49] <cjwatson> I merged your branch, like I said
[22:49] <ebroder> Oh, awesome
[22:49] <cjwatson> probably only temporary given Robert's comments though
[22:49] <ebroder> ...except for the breaking bit :)
[22:49] <cjwatson> I don't want to carry that divergence permanently, I just want to get moving on the boot graphics stuff
[22:50] <cjwatson> /boot/grub/lua.mod exists in my natty vm
[22:50] <ebroder> cjwatson: Yeah, sure. I was planning to try and create a "hwmatch" C-based command during my Thanksgiving time off that we could carry as a distro patch while we work out the best long-term approach with upstream
[22:51] <cjwatson> bdrung: 'ls $prefix/lua.mod'
[22:51] <ebroder> If there are objections to turning on Lua, then having the ugly C command at least avoids opening those floodgates
[22:51] <cjwatson> indeed
[22:52] <bdrung> cjwatson: there is no lua.mod in (hd0,1)/boot/grub/
[22:52] <cjwatson> bdrung: tell me about your disk layout
[22:53] <bdrung> cjwatson: (hd0,1) is the root partition mounted at /
[22:53] <ebroder> bdrung: Do you have a lua.mod in (hd0,1)/usr/lib/grub/i386-pc/?
[22:53] <cjwatson> it's definitely in the package, both i386 and amd64
[22:54] <bdrung> ebroder: yes, (hd0,1)/usr/lib/grub/i386-pc/lua.mod is there (i am on amd64)
[22:54] <cjwatson> any problems during the upgrade?
[22:55] <cjwatson> oh, I bet you have grub-pc/install_devices set to nothing
[22:55] <bdrung> no errors, but i don't know if there were any warnings
[22:55] <cjwatson> you should have had a debconf warning about that, though it will only warn once
[22:56] <cjwatson> (perhaps some time ago)
[22:56] <cjwatson> that will mean you're running an old grub with a new configuration file
[22:56] <bdrung> cjwatson: where do i find grub-pc/install_devices?
[22:56] <cjwatson> in the debconf database
[22:56] <cjwatson> so, slightly tedious but you can certainly boot this
[22:56] <ebroder> cjwatson: I thought I checked that the config will fallback gracefully in that case...
[22:57] <cjwatson> 'set pager=1', 'cat /boot/grub/grub.cfg', page through until you find the menuentry block you want to boot, make a note of the commands, enter them all in sequence, then type 'boot'
[22:57] <cjwatson> ebroder: well, I had to modify your patch somewhat because it was syntactically invalid in at least two ways ... :-)
[22:57] <cjwatson> ebroder: so might want to try the version in the archive
[22:58] <cjwatson> bdrung: once you've booted, 'sudo debconf-show grub-pc | grep install_devices'
[22:58] <ebroder> cjwatson: Oh, whoops. I'll take a look
[22:59] <cjwatson> ebroder: could be that whatever version of normal.mod bdrung has doesn't deal with missing commands very gracefully
[22:59] <bdrung> cjwatson: what's the alternative to specifying an UUID?
[22:59] <cjwatson> it would be nice to know what version is actually installed
[22:59] <cjwatson> bdrung: 'set root=(hd0,1)'
[22:59] <cjwatson> it's probably there already, and if it is, just leave out the 'search' command
[23:00] <cjwatson> I think  strings /boot/grub/normal.mod | grep '^1\.9'  should tell you what version of GRUB is installed (not very reliable of course but it works here)
[23:06] <cjwatson> maybe I'm going to have to start recording the installed version, and implementing thresholds for popping up the debconf warning again, or something
[23:07] <cjwatson> http://paste.ubuntu.com/536085/ is the warning that should have been produced at some point in the past, if this is what I think it is
[23:07] <ebroder> cjwatson: Your code doesn't look interesting different from mine. I was using "if lua ..." so that we would handle the command not being there gracefully. If that doesn't work, maybe we can do an "if insmod lua; then lua ..."
[23:07] <cjwatson> mm, perhaps
[23:08] <cjwatson> revisions 2068 and 2069 were my changes
[23:12] <ebroder> Oof, that's embarrassing. I *swear* I fixed that missing fi at least twice. Anyway, I can investigate if insmod'ing a non-existant module gives a useful error code later this evening
[23:12] <cjwatson> I think we need to know what normal.mod version bdrung has first
[23:15] <bdrung> cjwatson: mounting (hd0,1) on /root failed: no such file or directory
[23:15] <bdrung> what did i miss?
[23:15] <ebroder> bdrung: You need to set root=(hd0,1) for grub, but pass root=/dev/sda1 or whatever to the kernel
[23:15] <cjwatson> you put root=(hd0,1) in the 'linux' line ... what he said
[23:16] <bdrung> i put root=(hd0,1) in the 'linux' line
[23:16] <ebroder> Right. That needs to be /dev/sda1 (or whatever)
[23:16] <bdrung> next try...
[23:17]  * bdrung hates the us keyboard layout
[23:17] <sebner> cjwatson: so it might be safe to reboot for me?
[23:17] <ebroder> sebner: Definitely check to see if you have a /boot/grub/lua.mod first
[23:18]  * sebner checks
[23:18] <ion> It’s much, *much* better than the fi(nnish) layout.
[23:18] <ion> fwiw
[23:18] <cjwatson> sebner: 'sudo debconf-show grub-pc | grep install_devices'
[23:18] <cjwatson> if you actually have a reasonable setting there (it should have at least one disk device in it), you should be fine
[23:18] <cjwatson> and almost everyone should
[23:19] <bdrung> ion: but not if you have a german keyboard and have to guess where "=", "/", ... etc are
[23:19] <sebner> ebroder: it's there
[23:19] <sebner> cjwatson: yeah my harddrive is listed (1 line)
[23:19] <sebner> cjwatson: http://pastebin.com/3fyPZj6p
[23:20] <sebner> bdrung: happens to me too all the time :D
[23:20] <bdrung> sebner: but i am used to neo2 layout...
[23:20] <ion> bdrung: It doesn’t take long to store them into muscle memory. At that point, you’ll notice programming anything or using the shell or using vim or whatever is a pain in the local layout where you need to do nasty altgr combinations to get special characters.
[23:20] <sebner> bdrung: ok that's even worse then :D
[23:22] <bdrung> ebroder: third try: it's /dev/vda1 not sda1
[23:22] <cjwatson> sebner: should be fine
[23:22] <cjwatson> ah.  I think there is a known bug about virtio devices not being listed in the install_devices select list
[23:24] <sebner> :)
[23:26] <bdrung> cjwatson: http://paste2.org/p/1108205
[23:27] <bdrung> that's the result of 'sudo debconf-show grub-pc | grep install_devices'
[23:27] <cjwatson> right, so you were warned about this in the past according to that :)
[23:28] <bdrung> nice excuse :)
[23:28] <cjwatson> easiest fix for now at least is probably:  echo SET grub-pc/install_devices /dev/vda | sudo debconf-communicate; sudo grub-install /dev/vda
[23:28] <cjwatson> and bug 604335 is the rest
[23:30] <bdrung> cjwatson: should i apply the fix or keep that version of my VM for testing bug fixes?
[23:30] <ebroder> bdrung: Before installing the new grub, can you find out what version of normal.mod you had?
[23:30] <ebroder> (If you haven't already)
[23:30] <cjwatson> yes, what ebroder said
[23:30] <cjwatson> aside from that you can go ahead and apply the fix
[23:30] <cjwatson> as I said above:  strings /boot/grub/normal.mod | grep '^1\.9'
[23:31] <bdrung> ebroder: 1.98-1ubuntu1
[23:32] <ebroder> Looks like pre-release Lucid
[23:32] <cjwatson> yes
[23:32] <cjwatson> I'm surprised it's worked this long
[23:34] <bdrung> ebroder: that's my devel release testing vm
[23:37] <ebroder> cjwatson: Well, when I get a chance, I'll grab that version and test with it. If we can make the new config file compatible, there's no reason not to
[23:38] <cjwatson> yes, although it's really just papering over a problem, upstream definitely doesn't guarantee compatibility there
[23:40] <RAOF> @pilot on
[23:40] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[23:40] <RAOF> @pilot in
[23:41] <bdrung> RAOF: my suggestion is to go to http://reports.qa.ubuntu.com/reports/sponsoring/ and start from the top if you want to process the request like a queue
[23:42] <bdrung> RAOF: do you know sponsor-patch?
[23:42] <RAOF> I do not, no.
[23:42] <RAOF> It's in ubuntu-dev-tools?
[23:42] <bdrung> yes
[23:43]  * RAOF checks it out.
[23:43]  * bdrung should blog about it
[23:43] <bdrung> whom can i blame if compiz/metacity doesn't work in my second vm?
[23:45] <RAOF> I'm surprised compiz works in your *first* VM :)
[23:45] <ebroder> bdrung: the metacity fallback doesn't seem to be working, but you can run metacity by hand
[23:46] <ebroder> (compiz crashes before it realizes that it doesn't work)
[23:46] <bdrung> ebroder: why does the metacity fallback work in the first vm, but not in the second?
[23:46] <ebroder>  that I can't help you with
[23:47] <bdrung> second question: what can i do when the mouse cursor stops moving in the VM?
[23:50] <sebner> RAOF: compiz works on my productive machine without problems (well the upgrade was painful but dpkg --force-all ftw!)
[23:51] <bdrung> sebner: compiz in natty does not work correctly on my real hardware.
[23:52] <sebner> bdrung: what's the problem?
[23:53] <bdrung> sebner: i can't enable extra effects (no wobby windows) and it hang if i want to shutdown the computer
[23:54] <RAOF> bdrung: That's probably fallout of the lack of settings migration; if you (a) kill your existing compiz settings with gconftool-2 --recursive-unset or (b) switch to the ini backend in ~/.config/compiz-1/compizconfig/defaults it should work.
[23:55] <sebner> bdrung: well, I only use some minimal effects so I can't tell but I have the shutdown bug too
[23:55] <bdrung> RAOF: i'll try that next time i boot into it.
[23:55] <sebner> simple-compiz-configurator is b0rken btw, seems not to be compatible with compiz 0.9.x
[23:57] <bdrung> sebner: i'll use the 'visual effects' tab in gnome-appearance-properties
[23:59] <sebner> bdrung: right, stays at "None" (even though I have effects enabled)