[00:12] ikonia: pong === bjf is now known as bjf[afk] === cam is now known as Guest49096 [02:45] can we still upload SRUs to maverick-proposed on the assumption they will be copied to natty if maverick_version = natty_version? [02:46] doesn't an sru require fix committed in natty first? [02:47] 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] micahg: could well be, just doesn't match my understanding of the process. my being wrong is by no means unlikely :) [02:58] micahg: My understanding was that that automated process was only for SRUs uploaded before the natty archive opened. [03:27] Was there a change made to plymouth between lucid and maverick that affects when the graphical vs. text splash screen is used? [03:28] 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] ebroder: Yeah. We turned off vga16fb to stop it *breaking everything* [03:34] 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] why? [03:34] It's *delightfully* geeky. [03:35] it boots my hardware [03:35] ROAF: Where was that change made? It doesn't look from the changelog like it was done in plymouth itself? [03:35] I'm looking forward to grub immediately going graphic mode and staying that way [03:35] what I'd be happiest with is something that doesn't trash progress output from non lsb scripts. [03:35] should be real nice if we ever get the grub gfxmenu set up by default [03:35] that would be like way retro: a readable boot console [03:35] lifeless: If it boots your hardware, you're one of the 1% or so :-) [03:36] StevenK: nokms boot my hardware [03:36] StevenK: everything else is fail [03:36] 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] RAOF: Ah, got it [03:37] RAOF: So...probably not something I could turn on in configuration if I was interested in living dangerously [03:38] You could get vga16fb to load; you just need to do it manually. [03:39] Although vesafb is probably a better bet; throwing a vga= on the end of your kernel command line should do it. === tmzt_dg2root is now known as tmzt_g2root [03:56] RAOF: Can I do that by hand by passing module arguments or something? [03:57] I guess I can probably just look in the source for that [03:57] Add “vga=ask” to your kernel command line in grub, after “quiet splash” [03:57] Then when you boot the kernel will list the possible vesa modes, and you can select one. [03:58] 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] Ah, yeah. That's more difficult. [03:58] So I'm thinking of trying to pull something evil together like an initramfs script that runs after udev and before plymouth [03:59] I guess you could manually modprobe vesafb [04:00] *uvesafb [04:00] RAOF: Ah, that's what I was missing. I was looking at vesafb instead of uvesafb. Awesome, thanks [04:05] 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] If uvesafb touches the graphics state it's likely that the kms driver will explode into a thousand pieces. [04:06] 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] 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] 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] There was a popular launchpad bug “Running hwinfo -C causes the screen to go green”, caused because hwinfo probed /dev/fb1. [04:17] 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] RAOF: Ok, I can try that [04:27] 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] Sarvatt: And wasn't there also one where radeon just plain died? [04:28] Oh, uh. Hmm... [04:28] Maybe I shouldn't try that... [04:29] I seem to recall that if you loaded the kms drivers into the initramfs it worked ok. [04:29] it was ok packed in the initrd but it was racy, 1 out of 10 boots or so would die here [04:31] Oh, that reminds me. Time to un-framebuffer my grub so that I can actually see it. [04:31] Couldn't you work around that just by doing a udevadm settle in the udev initrd script? [04:31] (Doesn't it do that already...?) [04:31] Ah, no - just a trigger [04:32] I don't think it does, as that would kill boot performance? [04:32] What about something like trigger fb devices, settle, trigger everything else? [04:34] With a "load uvesafb if no other fb devices" bit? [04:34] 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] Ouch. That's pretty bad [04:38] I...think I'm suitably convinced that I should figure out how to solve my problems using the text splash :) [04:42] It's still a goal to make seamless-grub work in Natty, I think, so you could piggy-back on that effort. [04:42] I don't think that's a solved problem yet, though. [04:43] 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] can someone help me with packaging skype-call-recorder? it is my firsty package [05:19] *first [07:33] good morning! [07:42] Good morning dholbach [07:42] hey bilalakhtar [07:59] good morning === almaisan-away is now known as al-maisan [08:12] Good morning [08:13] anyone involved with purple-plugins-pack? [08:14] RenatoSilva: I use it [08:15] there's a typo bug which leads to a plugin not being included [08:15] RenatoSilva: ok, can you file a bug and give me the bug #? [08:21] 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] what is funny is that the package was succesfully built even when trying to include a non-existing plugin [08:23] debian 604763 [08:23] Debian bug 604763 in pidgin-plugin-pack "Missing IRC-More plugin" [Normal,Open] http://bugs.debian.org/604763 [08:24] filed an hour ago [08:24] micahg: should still file one in Launchpad? [08:25] 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] RenatoSilva: are you able to provide a debdiff for it? [08:26] RenatoSilva: actually, we should really move this to #ubuntu-motu [08:27] what happened to UpstreamVersionFreeze, did that get rolled into FeatureFreeze? [08:27] * micahg didn't know there was an upstreamverisionfreeze :-/ [08:28] sladen: seems to fit the definition here: https://wiki.ubuntu.com/FeatureFreeze [08:29] micahg: I'm there === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === hunger is now known as Guest91960 === Guest91960 is now known as hunger|o === smb` is now known as smb [09:04] I got this email today, even though the source package got accepted: http://paste.ubuntu.com/535806/ [09:05] Could someone archive-admin please look at it [09:06] binaries of other archs also got into the archive [09:17] bilalakhtar: https://launchpad.net/ubuntu/+source/gcc-defaults/1.82ubuntu2 [09:19] bilalakhtar: In a nutshell, another source package has built those binary packages with a newer version. [09:21] 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] (or tell me who to nag instead ;) [09:26] Amaranth, heya - who's maintaining alacarte upstream now? I was just looking at gnome bug 608221 [09:26] Gnome bug 608221 in general "Drag-and-drop of items downwards is off by one" [Minor,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=608221 [09:30] mvo: I'm still the closest VMBuilder has to a maintainer. [09:37] dholbach, nobody [09:37] dholbach, it's not actively maintained for a while [09:37] seb128, that explains it :) [09:48] Did someone reply to my thing? [09:49] bilalakhtar: gcc-defaults is building the source package, you should probably talk to doko [09:49] s/source/binary [09:49] okay, thanks, micahg [09:50] bilalakhtar: mr_pouit responded with that above :) [09:50] thanks [09:50] mvo: Let me take a look. [09:50] actually, my system went down due to processor overheat [09:50] and I am fed up of this laptop [09:54] 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] the alacarte one.. [10:22] stgraber: done [10:47] hey all .. from yesterday .. I am struggling to setup a serial console on my ubuntu 10.10 machine .. [10:47] ny help would be great [10:47] I am basically following this article for the setup but no luck so far [10:47] Then I simply connect the serial cable .. and trying to write on it .. by using command: $ > ehco "abcd" > /dev/ttyS0 [10:48] I can see that interrupts assigned to /dev/ttyS0 (IRQ - 4) is increasing .. [10:48] but still there is no output on the other machine .. [10:48] group .. ny idea what is going on and how can i troubleshoot the problem further? [10:48] 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] cjwatson, baudrate is same on both of my machines.. [10:51] will try with the picocom on the sender side.. already using the minicom on the receiving end [10:52] picocom, minicom, whatever [11:04] cjwatson, can we use the picocom/minicom to send the data ? [11:05] yes, if I'm understanding you correctly [11:05] this really isn't a topic for #ubuntu-devel though ... [11:05] ok .. in dat case can you point me to the right forum/direction.. [11:05] #ubuntu or the forums [11:07] 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] you could try on #ubuntu-kernel [11:07] but I'm not 100% sure if it's appropriate there [11:08] ok thanks once again .. will try my luck over there [11:08] gl getting it to work! [11:08] btw, are you sure you're using the right cable? [11:08] and if it's working correctly? [11:09] I am not sure.. i just bought these cables from the market yesterday itself .. [11:09] so i guess.. they would be fine [11:10] right, probably should be. but there are serial cables and then there are serial cables [11:10] :) [11:10] 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] not sure, been a while since I messed with serial cables [11:11] but I recall there being more than one way to wire them [11:11] anyway, try on #ubuntu-kernel ;) [11:11] thanks once again .. will ping over there === sebner_ is now known as sebner [11:41] 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] a spec change? [11:42] dholbach: Yeah, NoDisplay has too many meanings [11:43] ah ok, still it might be good to fix the small bugs already :) [11:43] but I understand - a shame that nobody has the time to look after it :/ === MacSlow is now known as MacSlow|lunch [11:44] 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] So I switched to docky and gnome-do and removed my menu [11:44] Someone else was trying to maintain it for awhile, even made a release or two [11:45] cjwatson, urgh, thanks for spotting the shadow issue, i somehow only looked at the conflicts in the report on MoM [11:45] thanks Amaranth [11:45] * ogra_ac_ merges now [11:45] dholbach: heh, thanks for depressing you? :) [11:46] no for the feedback [11:46] ogra_ac_: ok, please mark the sync bug Invalid then [11:46] will do [11:46] 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] (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) === ogra_ac_ is now known as ogra_ac [11:47] 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] well, i could have looked at the merged changelog first === al-maisan is now known as almaisan-away [12:41] no patch pilot :( [12:44] it's mterry's turn today, but he's probably not around yet [12:45] for the rest of this week there's only one pilot per day on the schedule === apachelogger is now known as releaselogger [12:48] cjwatson: can you please retry the build of the last apr version in natty? [12:48] cjwatson: on all archs.. [12:51] BlackZ: what changed since the initial attempts? [12:51] cjwatson: bug #671441 got fixed in launchpad-buildd [12:51] Launchpad bug 671441 in joblib (Ubuntu) "Can't mount /dev/shm as tmpfs in the buildd" [Medium,Confirmed] https://launchpad.net/bugs/671441 [12:52] BlackZ: ok, thanks, retried === MacSlow|lunch is now known as MacSlow [12:52] cjwatson: thank you :) === dmart is now known as Guest16033 === Guest16033 is now known as dmart__ [13:14] pitti, ping [13:22] 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] no, please don't, requestsync is very little work nowadays [13:23] syncs are generally processed at least daily [13:23] cjwatson: aye aye :) [13:32] ScottK: no, gcc-defaults has just a symlink [13:32] doko: OK. Thanks. === korn_ is now known as c_korn [13:34] 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] ScottK: that should be fixed in the package [13:36] sebner: use requestsync - some people don't like syncpackage [13:36] bdrung: I noticed =) [13:36] doko: Is gcc in Ubuntu intended to be different than in Debian about this? [13:36] /usr/lib64 is fine, but it's a symlink [13:36] 4.4 != 4.5 [13:36] OK. [13:36] So what 4.5 change is this? [13:37] I think I fixed it in the repo, but the assumption of the package is just wrong [13:38] same with the 4.5.x and 4.5 symlink in gcc_lib_dir [13:39] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: mterry [13:39] * mterry waves [13:39] * dholbach hugs mterry [13:39] woohoo! [13:40] 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] hey sebner [13:41] sebner: np === dmart__ is now known as dmart [13:51] ShaneM: get sorted? [13:51] czajkowski: Just doing it now. [13:53] ok === almaisan-away is now known as al-maisan [13:55] mterry: could you sponsor bug 663343? [13:55] Launchpad bug 663343 in cheetah (Ubuntu) "Please merge cheetah 2.4.2.1-1 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/663343 [13:56] ari-tczew, looking at it [14:06] mterry: IMO set as won't fix and unsubscribe sponsors ^^ [14:08] 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] mterry: Debian has older version. === Claudinux_ is now known as Claudinux [14:10] 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] They were good changes, so we should 'sync' up with those changes [14:11] mterry: aha, so go ahead [14:13] 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] cjwatson: did you perhaps have any chance to look at that? [14:14] highvoltage: 10:22 stgraber: done [14:18] cjwatson: merci! === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [14:32] 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] mterry: ah, you're not core-dev member [14:33] nope. QQ [14:39] mterry: are you waiting for the next sponsor request? [14:41] bdrung, if you have a suggestion, I'll look at it. But I'm going through the queue otherwise [14:41] mterry: my suggestion is to go to http://reports.qa.ubuntu.com/reports/sponsoring/ and start from the top. [14:42] bdrung, :) OK thanks [14:42] mterry: the list is sorted by time in queue. picking the one on the top would processing the list like a queue. :) [14:42] mterry: do you know sponsor-patch? [14:44] bdrung, no, that's nice! I do that manually. So painful [14:44] * mterry adds these notes to the patch pilot wiki [14:44] 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] 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] (grub-legacy-ec2). Can someone allow that backport in ? [14:45] mterry: i wrote sponsor-patch to make sponsoring simple. it does many checks and tries to build the package. [14:49] ooh, risky updates! I'll be sure to test! [14:49] once Ubuntu does move to rolling releases, will it be based on Debian CUT or ... ? [14:50] AbsintheSyringe: i think someone over-interpreted something [14:50] whats debian CUT ? [14:50] bdrung, how come? [14:50] a new name for experimental ? [14:51] ogra_ac, no no http://kitenet.net/~joey/code/debian/cut/ [14:51] there was a lecture on this years debconf10, and I think this is the way to go actually [14:51] AbsintheSyringe: gimme your sources [14:51] aha [14:52] bdrung, http://linux.slashdot.org/story/10/11/24/1346221/Ubuntu-May-Move-To-Rolling-Releases?from=fb [14:52] I personally think Debian CUT and Ubuntu rolling releases are future towards all linux platforms should be heading to, including android [14:53] and I remember there was talk about ubutnu rolling releases before this, just can't remember where [14:54] AbsintheSyringe: at present Ubuntu has no plans I'm aware of to move to a rolling model [14:55] cjwatson, hype? [14:55] I think overinterpreted long-term thoughts, perhaps [14:55] I hadn't seen that comment from Mark before now [14:55] AbsintheSyringe: think about the extra repository - this is the first step in the direction of more frequently updates [14:56] yea, I don't see it happening right now either, but on long term ... I think it should be done === tkamppeter_ is now known as tkamppeter [14:56] bdrung, true ... [14:57] 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] it's certainly too early to be making concrete predictions about what it would be based on [14:57] "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] intresting that they didnt make it "Ubuntu plans daily releases" on slashdot [14:58] smoser: I already NEWed it yesterday [14:58] pitti, ... so it requires an admin now ? [14:58] smoser: no, I already did that [14:58] i'm sorry for not understanding process. i just tried to verify and its not in archive [14:59] 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] haha, imagine someone says: "ubuntu has daily builds" and a press guy writes "Ubuntu-May-Move-To-Rolling-Releases" :) [14:59] :D [15:00] smoser: "rmadison -s lucid-proposed -S cloud-init" says that it's in [15:00] at least wasnt in ec2 archive ... hmm. i dont see cloud-init either in proposed there. maybe that mirror is just beind. [15:00] smoser: so it might be mirror lag [15:02] cjwatson: isn't Mark's comment actually about the extras repo [15:04] pitti: for bu #617885 - how many people do you need to test it? [15:06] sladen: it's too short to be able to tell :) [15:06] thats bug 617885 [15:06] Launchpad bug 617885 in gparted (Ubuntu Maverick) "gparted crash at start: glibmm-ERROR **" [High,Fix committed] https://launchpad.net/bugs/617885 [15:06] jussi: usually one is enough [15:06] speculation filtered through news sites, what a way to go [15:07] pitti: so all good to up it to the repo propper now? [15:07] jussi: it needs to stay in -proposed for 7 days so that we have a chance to catch regression reports [15:08] pitti: ahh, ok. great. please ping me if you need more testers for that (or others similar) === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [15:22] doko, bug #677387 [15:22] Launchpad bug 677387 in libgnome (Ubuntu) "libgnome b-d on libcanberra, which cannot be availabe at this time" [High,Confirmed] https://launchpad.net/bugs/677387 [15:22] not sure we can do something about that [15:22] 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] I guess you need to build it manually if you need to start a port [15:23] Gulfstream, hi, try #ubuntu for user questions [15:23] Gulfstream: support for natty is in #ubuntu+1 [15:23] these are no build-deps, that's library incest [15:23] #ubuntu+1 [15:23] yes [15:23] ? [15:23] okay [15:24] thanks [15:24] doko, well in any case it's not going to be worked [15:24] doko, libgnome is deprecated, we are getting ride of it at some point but not this cycle [15:25] seb128: but honestly, it's time for a window manager in main, which doesn't depend on the whole of gnome [15:25] metacity has the same dependencies [15:25] compiz? [15:26] it's the default wm and it depends on nothing from GNOME [15:26] it depends on working GL [15:26] 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] ogra_ac, not really, 0.9 should fallback to 2d [15:27] sweet ! [15:27] * ogra_ac didnt know that [15:27] it might still be buggy in that regard because it's new but that should work [15:27] it should just turn off options that need gl [15:27] seb128: "it"? how? [15:28] doko, how what? [15:28] it should just turn off options that need gl [15:28] and works on powerpc? [15:28] dunno about powerpc [15:28] on ARM ! [15:29] well that was discussed to use compiz 2d as fallback at UDS [15:29] they say the code is a bit young and might need work [15:29] ok, so better stay away from it. honestly, I'd rather like to use twm, which doesn't change every few weeks ... [15:31] is the "Subscribe someone else" ajax thing on Launchpad bugs broken for anyone else? [15:31] worked this morning for me [15:31] cjwatson, how broken? [15:32] doko, nobody stop you to use twm if you want [15:32] seb128: does nothing [15:32] hm, maybe I should try restarting firefox [15:33] seb128: just needs promotion ... [15:33] cjwatson, works for me [15:33] I just tried on a bug [15:34] doko, you are in the mir team so just ack it ;-) [15:34] doko: if twm is so much easier, I don't see anything wrong with promoting it for these test cases [15:35] seb128: might be firefox 4 specific; I filed bug 681003 [15:35] Launchpad bug 681003 in Launchpad Bugs "+addsubscribers AJAX link does nothing" [Undecided,New] https://launchpad.net/bugs/681003 === al-maisan is now known as almaisan-away [15:37] pitti: I would prefer it, because you know that it doesn't change, and it does work [15:38] so, let's do that then? [15:39] pitti: reopening the MIR. is it possible for past releases too? [15:39] I don't think we can change it in stables [15:39] we could do a no-change upload to -proposed, but frankly for those it seems easier to just use dbus-launch metacity === almaisan-away is now known as al-maisan [15:41] maybe, at least the old versions don't depend on canberra [15:43] is anyone working on an evolution-couchdb upload for evolution 3.32? [15:43] cjwatson, I'm using firefox4 there [15:44] cjwatson, yes, rodrigo [15:44] didrocks, ok, I'll release evo-couchdb, which includes the fixes to compile with 2.31/32, and package it [15:44] that was a bit earlier today [15:45] 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] ok === diwic is now known as diwic_afk [15:52] * ogra_ac sighs about shadow === bjf[afk] is now known as bjf === beuno is now known as beuno-lunch [16:41] * SpamapS curses the baby for letting him sleep until 8:30am and miss the tech talk [16:41] it's only recently started === ikonia_ is now known as ikonia === al-maisan is now known as almaisan-away === beuno-lunch is now known as beuno === njpatel is now known as njpatel|away [18:03] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [18:26] pitti: will you accept a new SRU that has an upstart job that wasnt there before? [18:27] zul: rrwhhhzaaaa? that sounds a bit crazy. ;) [18:27] zul: would need a really good rationale; these can potentially break the system, so nothing with complex dependencies can be added [18:28] pitti: this is the one https://bugs.edge.launchpad.net/ubuntu/+source/tgt/+bug/574554 i was talking about [18:28] the upstart script is really simple and its not a widely used piece of software [18:29] zul: http://launchpadlibrarian.net/53388867/tgt_1.0.4-1ubuntu4.debdiff ? [18:29] zul: it would suddently start the daemon for people who have it installed, so that might be an unexpected behaviour change [18:29] pitti: right [18:29] but it seems that the job is already there, but has a typo? [18:30] post-start is not the right place to launch the main daemon, thuogh [18:30] pitti: i think its for lucid actually [18:30] zul: yep, we would need it in lucid [18:30] ah, right, fixed in maverick already [18:30] my feeling is that we shouldn't do those behavioural changes a year after release; it's too unexpected [18:31] (in both directions) [18:31] hmm...ok [18:31] -backports would be fine for me, if appropriate [18:31] gotcha [18:31] pitti: hmmm... that could work for me, indeed [18:33] zul: so, backport? [18:34] nijaba: yes [18:34] 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] nijaba: https://help.ubuntu.com/community/UbuntuBackports [18:36] good night everyoen [18:36] zul: pinning wilth apt-get install -t will work just great. thanks a lot [18:37] nijaba: no problems [18:44] nijaba: What won't work with the repository pinned down is pulling depends also from backports. [18:44] ScottK: sure, but for that particular, we don't have that req [18:45] OK. [18:45] ScottK: but thanks for letting me know === releaselogger is now known as apachelogger [18:56] 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] 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 === apachelogger is now known as bloglogger === diwic_afk is now known as diwic === zyga_ is now known as zyga [19:36] pitti: so do you think that talk was ultimately interesting or useful? [19:37] I hoped that by covering some of the design history, the reason for its differences for systemd would be apparent [19:37] but I'm not sure how successful I was at pulling that off [19:41] is launchpad.net down? [19:43] mmoya, http://downforeveryoneorjustme.com/launchpad.net ;-) [19:43] mmoya, or simply: "no" :-) [19:44] htorque: je, ok, didn't know that site [19:46] 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] well indeed [19:46] that's never been clear to me [19:46] even if you assume Copyright assignment [19:47] which is what I assumed before, but now it doesn't seem so obvious [19:47] the upstart-socket-bridge process (if Lenny believes that's the killer feature) could have always been a separate tarball [19:47] upstart-udev-bridge is separate, after all [19:47] 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] to be honest, I simply think Lennart wants to personally write his own OS [19:48] it makes some amount of sense to have a single service supervisor [19:48] something that can start things, stop things and keep things running [19:48] so you may as well make it the init daemon [19:49] I like that part, I don't know about the network sockets being passed around bit. [19:49] well, in the design of upstart (and afaik systemd too) those are just separate services started by init [19:49] which themselves tell init to start services [19:49] 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] That makes more sense then. [19:50] I like the idea of having one, small file that defines the reason and method for a service starting and stopping. [19:51] instead of it being an init.d, or in inetd.conf , or xinetd.d .. or or or.. [19:51] yeah, that's kinda a difference between systemd and upstart [19:51] upstart is all about "one file to define everything" [19:51] systemd is "one type of file to define one type of thing => lots of files to define *something*" [19:52] 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] But the discussion of systemd was harmed, I think, by Lenny's emotional rants. [19:55] ultimately Lenny doesn't understand why I think upstart's design is better [19:55] and therefore he'll never see the point [19:55]