[00:55] <crypt-0> what recent changes in bash make var=var=${var:0:40} invalid?
[00:55] <crypt-0> *var=${var:0:40}
[02:09] <crypt-0>        ${parameter:offset:length} is broken.
[02:15] <Euyulio> how long till beta1?
[02:15] <Keybuk> Euyulio: we need help with testing CD images before we can release beta 1
[02:16] <Euyulio> lol alpha3 #&@! up my system
[02:16] <Euyulio> was wondering if i could go to bed yet
[02:17] <Keybuk> all the more reason you should help us test images before we declare a beta
[02:17] <Keybuk> a 20100318 daily should be up, we'd appreciate any testing
[02:17] <Keybuk> https://wiki.ubuntu.com/Testing/ISO
[02:17] <Keybuk> in particular we're after testing Plymouth, https://wiki.ubuntu.com/Testing/Plymouth
[02:18] <Euyulio> can i install it from this 9.04 cd
[02:19] <Keybuk> that is not the kind of testing we need help with
[02:20] <Euyulio> alright i'll check if i have a cd i'm tired & drunk, check-in will be a while
[03:31] <superm1> slangasek, the images have been "rebuilding" since earlier today at http://iso.qa.ubuntu.com/qatracker/build/mythbuntu/all , is there something wrong?
[03:42] <slangasek> superm1: yes, there was - bug #540256, now fixed
[03:49] <crypt-0> can someone run this code and confirm that bash *should* run it but does not? http://pastebin.com/57UV2Bb9
[03:52] <johanbr> crypt-0, works for me
[03:56] <crypt-0> johanbr, with sh script.name  or ./ script.name  ?
[03:57] <johanbr> ./scriptname or "bash scriptname"
[03:57] <johanbr> I think the string stuff on line 17 is a bashism
[03:58] <crypt-0> ./script.name works for me sh script.name does not [rand-string.sh: 18: Bad substitution]
[03:58] <slangasek> yes, because sh isn't bash
[03:59] <slangasek> "bash should run it" - you're not calling bash when you type "sh" on Ubuntu
[03:59] <crypt-0> ahh ok
[06:54] <pitti> Good morning
[06:55] <pitti> slangasek: bug patterns> ubuntu-dev has commit access to the bug patterns, FYI
[07:55] <dholbach> good morning
[07:56]  * pitti takes the plunge and updates wife's computer to lucid beta-1. OMG
[08:26] <ravibn> Hi! I need help with my webcam
[08:28] <ravibn> Hi! I have a problem with my Frontech ecam JIL 2214. When gstream-properties is used it works perfectly alright.
[08:28] <ravibn> But when I use skype or any other application it does show blank
[08:28] <ravibn> Can I re-direct this video from gstreamer to these applications ?
[08:30] <\sh> jcastro: congrats dude
[11:11] <Ng> pitti: if I'm seeing bug #275972 with a slightly different byte would you want that as a separate bug, or re-opening that one?
[11:12] <pitti> Ng: looks fine to reproduce that one, since it was never really investigated
[11:17] <Ng> pitti: thanks, done
[11:19] <Ng> pitti: I'm not super keen to attach my Xorg crash file to the bug, but I can make it available to you
[11:20] <pitti> Ng: Xorg crash file? for apport?
[11:20] <Ng> pitti: yeah, I was trying to report an Xorg crash when I got that unicode error
[11:21] <pitti> Ng: perhaps put it on chinstrap and leave me the path in the bug report?
[11:21] <Ng> k
[11:28] <slangasek> NCommander, persia: will there be a separate release notes page for armel at https://wiki.ubuntu.com/ARM/LucidReleaseNotes as there was for last cycle, or are all the errata fixed? :)
[11:28] <slangasek> asac: ^^
[11:28] <pitti> jdong: if you have a minute, would you mind SRU-reviewing bug 476654? the other SRU team is quite busy with the beta-1 release ATM..
[11:32] <slangasek> pitti: is bug #462704 still present in Lucid?  (and if so, should we be targeting it for fixing?)
[11:32] <asac> slangasek: most from the karmic page are fixed. do you want such a page for beta?
[11:33] <asac> well ... the boards supported in karmic that had the issues are not supported anymore (e.g. no babage 2)
[11:33] <slangasek> asac: I'm preparing the preliminary release notes, and want to know whether there will be such a page that I should link to - I don't have a preference for whether there will be one or not
[11:34] <asac> slangasek: there surely will be release notes bits specific to arm, so i think it makes sense to keep it
[11:34] <slangasek> asac: ok
[11:34] <asac> unless you say that we should include such itesm in main release notes if the number of itesm is < X
[11:34] <slangasek> asac: I was just about to say that ;)  Let's say < 5
[11:34] <asac> with X being a number you define.
[11:35] <slangasek> asac: yes, X = 5
[11:35] <asac> slangasek: for now i would assume it will be > 5 ...
[11:35] <slangasek> ok
[11:35] <asac> but cant promise
[11:35] <asac> ;)
[11:36] <asac> but i think its safe to say that for now
[11:36] <asac> will check with QA on our current issues today
[11:39] <slangasek> StevenK: do you still have any plans to work on bug #439656, or is that irrelevant now that we're not shipping moblin remix? (haven't looked at what the proposed change was)
[11:39] <cody-somerville> Is gnome-power-manager in lucid broken or something?
[11:39] <cody-somerville> The following packages have unmet dependencies:
[11:39] <cody-somerville>   ubuntu-netbook: Depends: gnome-power-manager but it is not going to be installed
[11:40] <slangasek> cody-somerville: it's not broken, no; do you have something that conflicts with it?
[11:40] <StevenK> slangasek: Irrelevant
[11:40] <slangasek> StevenK: ok - want to mark it such? :)
[11:40] <cody-somerville> slangasek, No. This is attempting to install the UNE task in a fresh chroot.
[11:42] <slangasek> cody-somerville: out-of-date mirror, then?  we're in beta freeze, we certainly didn't leave core main packages uninstallable
[11:43] <cody-somerville> oops. I think I know what the problem is. Will try again.
[12:53] <alkisg> pitti: I think you're missing some important information on bug #460328, could I give you some feedback from Greece?
[12:53] <alkisg> "gdm is meant to pick precisely one keyboard layout (the one you want to
[12:53] <alkisg> use by default), so we should not and will not support lists in gdm. "
[12:53] <alkisg> That's an extremely wrong assumption
[12:53] <alkisg> Many countries need 2 layouts *by default* and the PCs are unusable without 2 layouts
[12:53] <pitti> alkisg: I think we have a different meaning of "default" here
[12:54] <pitti> alkisg: of course you should have more than one layout available and configured in GNOME
[12:54] <pitti> alkisg: but still, one of it must be set by default if you log in
[12:54] <alkisg> E.g. in Greece it's *required* that we have [us,gr] as the preinstalled layouts, otherwise we can't even use a browser
[12:55] <pitti> alkisg: I understand
[12:55] <alkisg> So if gdm goes on to force the gconf key to just [us], it ruins our setup..
[12:55] <pitti> alkisg: I'm using two layouts myself
[12:55] <pitti> alkisg: it doesn't
[12:55] <alkisg> Then I obviously misunderstood something
[12:55] <pitti> alkisg: g-s-d should use $GDM_KEYBOARD_LAYOUT to pick the one it sets by default
[12:56] <pitti> but it wouldn't remove existing layouts
[12:56] <alkisg> The default is not to have any layout in that gconf key
[12:56] <alkisg> gdm sees that none exists, so it adds a [us] there
[12:56] <pitti> well, it should have [us,gr] in gconf
[12:56] <alkisg> What package is responsible to put [us,gr] there?
[12:56] <pitti> alkisg: oh, you mean right after installation? yes, that'd be a problem
[12:56] <pitti> alkisg: gnome-settings-daemon
[12:57] <alkisg> I assume g-s-d can't use /usr/share/gconf/defaults, as it's country-specific
[12:57] <pitti> alkisg: thanks, I'll keep that in mind (first-time install case)
[12:58] <alkisg> pitti: ok, thanks
[12:58] <pitti> but once you have a sensible list of mappings in gconf, the main bug that I see is that the layout that you select in gdm doesn't become the default
[12:58] <alkisg> So if gdm sees an empty value there, it should put all the layouts in the gconf key, not just the first one
[12:58] <pitti> right
[12:58] <alkisg> Yeah, we'd be fine with that, thanks :)
[12:58] <pitti> (it's g-s-d, but nevermind)
[12:58] <alkisg> Ah, ok
[13:00] <alkisg> pitti: About gdm, it would be best if there was an additional entry there: "use the system default layout". This doesn't need any UI change. When a user selected that, the layouts from /etc/default/console-setup would be copied to the gconf key
[13:01] <alkisg> So without actually supporting multiple layouts, you still enable gdm to work fine in countries like greece
[13:01] <alkisg> (I'm talking about the combobox where the layout is selected in gdm)
[13:02] <pitti> alkisg: it actually uses the system default layout to set the default value of the keyboard picker
[13:03] <pitti> alkisg: I'll figure something out between gdm and gsd
[13:03] <pitti> I think I really understand the problem now, and can replicate it
[13:03] <alkisg> pitti: it uses just [us] for greece... ok, thanks again
[13:03] <alkisg> And sorry for the direct ping :)
[13:03] <pitti> alkisg: no problem :) I'm here for that reason
[13:15] <jdub> Keybuk: about?
[13:17] <jdub> still having problems with rsyslogd -- now getting "imklog: Cannot read proc file system, 1." with a supported kernel, 2.6.32-302-ec2
[13:29] <daniel1234> Hi, where should I go to ask about apparmor profiles (of openldap in ubuntu specifically), and packaging guidelines?
[13:48] <daniel1234> I have a service that I want to write a profile for, that service is using slapd. slapd already has a profile, but it doesn't cover the directories I need. Apparmor doesn't support having multiple profiles for one binary and it doesn't support "inheritance".. And you shouldn't touch files from other packages
[13:48] <daniel1234> afaik at least.
[13:55] <ev> kwwii: https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/368060
[14:29] <cnd> if I build a test version of an ubuntu package for a ppa, I should increment the version and add ~<something> to it?
[14:29] <cnd> so if the package is currently version 0.3, I should make it 0.4~test?
[14:35] <daniel1234> i'm not a packager, but i'dd say that you shouldn't increase the version that the package already has, so 0.3~test1 or something like that
[14:36] <slangasek> That depends on what the package you're preparing is.  If it's a test version of a package that will be uploaded to the archive later, you want it to sort earlier than the eventual to-be-uploaded version, but *later* than what's already in the archive
[14:37] <slangasek> so <upstream_version>-<debian_version>ubuntu<next_ubuntu_version>~test is pretty typical
[14:38] <cnd> slangasek: ok, I think I've got my package versions right then
[14:38] <cnd> thanks
[14:40] <tseliot> Riddell: currently ServerAttempts is set to 1 in kdm. Shall I set it to 2 in order to make it retry if it fails the 1st time?
[14:42] <Riddell> tseliot: is that a change from upstream?  does that interract with the bulletproof X stuff?  (I don't even know if bulletproof X still works in KDM)
[14:43] <tseliot> Riddell: that's in our current source code (kdm/config.def). I have no idea abour bulletproof X in KDM either
[14:46] <tseliot> Riddell: kubuntu_33_kdm_bulletproof_x.diff seems to hardcode that variable to 3
[14:49] <Riddell> tseliot: mm, I wonder why that is
[14:49] <Riddell> tseliot: but I guess that answers your question :)
[14:50] <tseliot> Riddell: yes but at least you reminded me about bulletproof X. I'll make sure that my patch and that one don't conflict
[15:01] <micahg> it seems like there's no hope for people me too'ing bugs....
[15:01] <nigelb> micahg: what happened?
[15:02] <micahg> nigelb: that plymouth bug
[15:02] <nigelb> micahg: I wish bug control could turn the option off after sometime
[15:03] <slangasek> micahg: not to worry though, they reapplied an image that had plymouth installed just this morning so they're legit to comment
[15:04] <micahg> slangasek: k...
[15:04] <slangasek> :)
[15:05] <micahg> slangasek: It's just "funny" to watch you and pitt-i change the bug and then still have people comment
[15:05] <slangasek> I remain firmly convinced that non-bugcontrollers should not be allowed to comment on bugs they didn't open
[15:06] <slangasek> well, bugsquad I suppose
[15:06] <micahg> slangasek: well, that's not good in some cases if some users are more technical and can more easily provide debugging information
[15:06] <slangasek> micahg: they can file a new bug, and a triager can mark whichever report is better as master
[15:07] <slangasek> the vast majority of users are not technical enough to correctly identify bugs as duplicates
[15:07] <micahg> slangasek: interesting point...maybe we should bring this up in the next meeting
[15:22] <cnd> pitti: slangasek: I sent out a CFT for pm-utils-powersave-policy to ubuntu-devel, but it's awaiting moderator approval
[15:22] <jdub> jdstrand: will you be pushing a new ufw to lucid?
[15:24] <slangasek> cnd: I'm not a moderator of ubuntu-devel
[15:24] <cnd> slangasek: do you know who I should ping? or should I just wait?
[15:24] <slangasek> cnd: also, I see it in my mailbox, so it seems to have been moderated :)
[15:25] <cnd> slangasek: ahhh, cool
[15:27] <slangasek> cnd: "slated for inclusion in lucid" - errr, no, I told apw in the release meeting two weeks ago that this was beta-1, or Lucid+1
[15:27] <cnd> slangasek: the package is already in lucid, just without many scripts
[15:27] <cnd> and it's still listed as a beta-2 activity on the blueprint
[15:27] <apw> slangasek, yep thats my understanding
[15:27] <cnd> https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-laptop-mode-tools-integration
[15:28] <apw> cnd, that task is specifically for beta-2 yes, but note it says "in a PPA" at the end
[15:28] <apw> and the 'in lucid' form of the task is postponed to MM
[15:28] <cnd> ahhh, ok I was confused
[15:28] <slangasek> cnd: "10 second audio codec power down" - this was explicitly *disabled* this cycle, again, because people were still getting popping; if we were going to release it, it needed to stay enabled through the cycle for testing and fixing if it was going to release
[15:29] <slangasek> apw, cnd: ok, glad that's straightened out then :)
[15:29] <slangasek> (FWIW, I think it was a mistake to redisable the audio codec powerdown when we did, but it's done now and nothing for it)
[15:29] <apw> as i understand the plan we wanted to complete the work so it didn't need to be started all over again for M and not make it in time there either
[15:29] <cnd> slangasek: this enables the power down only when on battery, in the past it was enabled through a module param at boot
[15:30] <apw> slangasek, yeah specially as even with it disabled i get the popping :)
[15:30] <slangasek> apw: heh
[15:30] <apw> either that or disabling it didn't work
[15:30] <slangasek> cnd: well, I see no reason not to enable that setting even on AC if it works, and no reason to tolerate the popping even on battery if it doesn't :)
[15:31] <cnd> true
[15:31] <apw> slangasek, right it either works or not, whether we have a battery is not the reason to change it
[15:31] <apw> any more than turning on or off video downclocking is a battery based feature
[15:32] <cnd> For me, if there's popping I don't want it when I'm plugged in cause it's annoying
[15:32] <cnd> but I want the battery life when not plugged in
[15:32] <mathiaz> pitti: hi - I'm reviewing bug 531978
[15:32] <cnd> so I'm willing to deal with popping in that case
[15:33] <mathiaz> pitti: it adds a apport hook that uses ui.yesno("..
[15:33] <slangasek> cnd: and for me, I'm willing to deal with the popping in both cases in order to save power, but I don't think either of those is a good default policy for the distro :)
[15:33] <mathiaz> pitti: does this mean a UIFreezeException is required?
[15:33] <pitti> mathiaz: I wouldn't go as far as requiring UIF for apport hooks
[15:34] <mathiaz> pitti: so text used in ui.yesno() is not automatically translated?
[15:34] <pitti> mathiaz: no; at this point (for reporting bugs) you need to speak English anyway
[15:35] <pitti> mathiaz: well, of course you could call gettext for it, build .po files, etc., but I don't think it's worth the effort
[15:35] <slangasek> pitti: fighting the urge to amuse myself by presenting counterexamples from LP
[15:35] <slangasek> :)
[15:35]  * mathiaz wonders if apport could enforce the "you need to speak english to report bugs to Ubuntu"
[15:36] <pitti> slangasek: well -- yes :/
[15:37] <seb128> slangasek, those are usually closed though with a request to open a new one in english
[15:37] <slangasek> oh, is that what I was supposed to do
[15:37] <slangasek> oops
[15:37] <seb128> I don't think there is agreement on that
[15:37] <micahg> seb128: idk about that
[15:37] <seb128> but that's we do for desktop and what some active triagers do
[15:38] <seb128> micahg, "idk"?
[15:38] <slangasek> "i don't know"
[15:38] <seb128> ah
[15:38] <micahg> I usually try google translate, but I think the consensus was to subscribe the translations team
[15:38] <seb128> well, there is so many bugs open anyway
[15:38] <slangasek> I tend to reply to them myself for the novelty ;)
[15:38] <micahg> or open a task in the translations project..can't rememberr which one
[15:38] <seb128> there is no point to spend efforts trying to get one translated
[15:39] <seb128> if the issue is one users care about somebody will open an english bug soon enough anyway
[15:39] <seb128> often non english bugs are rather support requests than bugs anyway
[15:39] <micahg> seb128: 1.  Sometimes things are lost in translation, 2. Ubuntu's internation base is growing, 3.  We have locos in a lot of places, maybe they can help
[15:40] <seb128> micahg, I don't see the point of vasting efforts on that
[15:40] <seb128> we already don't read half of the bugs we get, ETOOMANY
[15:40] <seb128> what is the point to waste efforts to add extra ones with lower quality or hard communication with submitter
[15:40] <pitti> it'd just mean to spend tons of manhours for somethign that we don't even want to encourage, IMHO
[15:41] <pitti> we do NOT have the problem of having too few bug reports
[15:42] <pitti> and people have to go through Launchpad either way, so it wouldn't be worth the effort unless it's done all the way through
[15:42] <pitti> cnd: seems someone moderated it, thanks!
[15:45] <tseliot> Riddell: do you know who wrote kubuntu_33_kdm_bulletproof_x.diff?
[15:45] <slangasek> tseliot: IIRC, the debian/changelog attributes it
[15:46] <tseliot> or do you know his nickname?
[15:46] <tseliot> it's Eugene Tretyak
[15:46] <tseliot> slangasek: yes, but nicknames are not there, unfortunately ;)
[15:47] <cjwatson> launchpad.net/people is sometimes helpful for this
[15:47] <Riddell> tseliot: etretyak but he hasn't been around for ages
[15:47] <tseliot> good point
[15:47] <tseliot> oh
[15:49] <tseliot> Riddell: I can either merge my patch for plymouth with that patch or make my patch depend on that patch (which I will have to edit). Which one do you prefer?
[15:49] <Riddell> tseliot: merging is fine, probably easier not to have overlapping patches
[15:50] <tseliot> Riddell: yes, that's easier for me but I had to ask since I'm not the maintainer ;)
[15:50] <Riddell> tseliot: oh we can fix that :)
[15:52] <tseliot> Riddell: no, we can't :-P
[16:07] <researcher1> which is the IRC channel for ubuntu 10.04?
[16:08] <Laney> for support? #ubuntu+1
[16:23] <tseliot> Keybuk, slangasek, Riddell: do you think pseudo-code this is correct? http://pastebin.ubuntu.com/397327/
[16:23] <jdong> pitti: ok, just had a chance to look at bug 476654; it looks good
[16:24] <slangasek> tseliot: why call 'plymouth quit' before restarting X?
[16:24] <slangasek> (though, I don't see why you wouldn't call failsafe-X immediately, if starting failed the first time)
[16:24] <Keybuk> right, with slangasek here
[16:25] <Keybuk> you call plymouth quit because you've given up starting X servers
[16:25] <Keybuk> it resets the terminal to text mode, switches to VT1, etc.
[16:25] <Keybuk> so it'd be before you called failsafe X (in case that too failed to show up)
[16:25] <tseliot> right, we don't want KD_GRAPHICS
[16:26] <slangasek> Keybuk: in this case, it'd be after failsafe X, because kdm doesn't hook into the failsafe X upstart job, it spawns the server directly...
[16:26] <tseliot> slangasek, Keybuk: when shall I call failsafe x then?
[16:27] <Keybuk> slangasek: right, good point
[16:28] <slangasek> tseliot: well, the *right* way to do it is to make kdm parallel what gdm does: exit with a special code on X server failure, trigger the separate failsafe-x upstart job.  But that's not realistic for Lucid
[16:28] <tseliot> slangasek: oh, I misread your sentence
[16:29] <slangasek> tseliot: for now, I think it should immediately fall back to failsafe-x, without trying to restart the normal X server at all
[16:29] <tseliot> slangasek: so, I should try to stop plymouth and start failsafe X after that
[16:30] <tseliot> ok, it's even easier
[16:31] <pitti> jdong: cheers
[16:31] <slangasek> tseliot: I think 'stop plymouth' belongs after 'start failsafe X' as part of the common cleanup path
[16:32] <tseliot> slangasek: but if we're still in KD_GRAPHICS I won't be able to start X (failsafe X in this case)
[16:32] <tseliot> or am I missing something?
[16:33] <slangasek> tseliot: I don't know the terminology, but I know gdm doesn't call 'plymouth quit' until after the X server is started
[16:35] <tseliot> slangasek: right, I can see that in the plymouth_transition patch. I'll trust whatever gdm does then ;)
[16:35] <tseliot> and do the same in kdm
[16:36] <slangasek> tseliot: explanation from #ubuntu-release yesterday: http://pastebin.com/aSuFz7YW
[16:38] <tseliot> slangasek: right, I guess this confused me a bit though:
[16:38] <tseliot>      if the X server starts ok
[16:38] <tseliot>        call plymouth quit --retain-splash
[16:38] <tseliot>      if the X server *fails to start)
[16:38] <tseliot>        call plymouth quit
[16:39] <slangasek> tseliot: yes; that's because if gdm can't start the X server, it gives up and a different job picks it up
[16:39] <slangasek> or, perhaps, doesn't pick it up :)
[16:39] <slangasek> kdm should only call 'plymouth quit' when it gives up
[16:39] <tseliot> slangasek: so that's what I was missing
[16:39] <slangasek> or after it's started the X server successfully
[16:40] <tseliot> ok
[16:41] <psusi> shouldn't device mapper devices default to using the noop scheduler instead of cfq?  don't need a scheduler on top of a scheduler on top of a scheduler do we?  should this be done in libdevicemapper or by udev I wonder?
[16:48] <jaycount> Say if a student-developer wants to get started in open source development, is Ubuntu a good place to cut teeth?
[16:50] <mathiaz> slangasek: IIRC for daemon using upstart, the default file should go away and be merged into the upstart job?
[16:51] <cjwatson> It depends.  Distributions are a good place to get lots of variety, as long as you don't mind occasionally being told that you should go upstream.  People who work on distributions tend to quickly become expert build system engineers, and also get lots of direct contact with end users so it's excellent if you like maintaining and integrating code and trying to turn things into a polished product.
[16:51] <cjwatson> jaycount: ^-
[16:51] <kklimonda> jaycount: that depends - Ubuntu takes most of its software from the upstream so they may be a better place to start if you want to write some code.
[16:51] <slangasek> mathiaz: typically yes, though I am loathe to do that without migrating settings on upgrade
[16:51] <cjwatson> jaycount: If the student has some particular burning interest in a particular application, or whatever, then it's best to go straight to the source, as kklimonda says
[16:52] <cjwatson> jaycount: although there's lots of software that's upstream-maintained by people who started out as distribution developers, either because it was written specifically for that distribution, or because nobody else was doing it so the package maintainer took it over
[16:52] <jaycount> The upstream... you'll have to help me with that particular piece of jargon
[16:53] <tseliot> upstream = the original authors
[16:53] <jaycount> ahhhhh
[16:53] <pitti> jaycount: it's generally the direction where code flows from/to from a particular person's perspective
[16:54] <cjwatson> http://en.wikipedia.org/wiki/Upstream_%28software_development%29
[16:54] <jaycount> I've been sitting around idle looking for an open source project to get started with and I'm comin up blank. I don't wanna get started on a project that's too big and just get caught in a bunch of devs but I don't wanna go into a small project that's just a remake and is going to fail
[16:54] <jaycount> Really I just want to get some real life experience. I'm 2 years from  graduating and have no real world experience
[16:54] <pitti> jaycount: e. g. lxde is a downstream from our side, since they base their distro on ubuntu; debian is upstream because we derive from them; and of course all the projects like gnome/firefox etc. are "upstream" from our POV
[16:55] <jaycount> pitti, makes sense. thanks
[16:56] <tseliot> right, it's a relative concept
[16:57] <jcastro> jaycount: https://wiki.ubuntu.com/UbuntuDevelopment
[16:57] <jaycount> jcastro, thanks for the link
[16:59] <kn100> I just booted into my lucid setup today and my resolution is set at 1024x768 and won't let is any higher
[16:59] <kn100> it's a nvidia card, and I am using the proprietary drivers
[17:00] <tseliot> kn100: try nvidia-settings perhaps?
[17:00] <kn100> tseliot, the higher resolutions aren't available
[17:00] <kn100> tseliot, it worked fine yesterday
[17:01] <kn100> I can't say it definitely is a lucid update, but that's the only change I remember making yesterday
[17:01] <tseliot> kn100: are you sure that the driver was loaded correctly?
[17:01] <tseliot> kn100: can you put /var/log/Xorg.0.log on pastebin, please?
[17:01] <kn100> tseliot, well nvidia-settings is open and compiz is rendering as beautifully as ever along with my card not being span up to full like it does with the oss drivers, so I think so
[17:02] <tseliot> also the output of "dmesg" might help
[17:03] <cjwatson> jaycount: it doesn't work for everybody, but it works well for some people.  Lots of people (like me) got involved with Debian a bit before graduating, and ended up making a career of it
[17:03] <kn100> tseliot, I'll get you both :)
[17:03] <cjwatson> (Ubuntu didn't exist when I graduated)
[17:05] <kn100> tseliot, both can be found here http://pastebin.com/LxKM2a4p
[17:05] <ScottK> Heh.  Debian didn't exist when I graduated (nor Linux for that matter).
[17:05] <kn100> tseliot, thanks for any help, and alphas are fun huh :P
[17:05] <jaycount> good stuff on that ubuntu dev site, I'll prowl around some. thanks guys
[17:05] <ogra> ScottK, that would have been a reason to wait with graduation !
[17:06]  * cjwatson passes ScottK the honorary zimmer
[17:07] <tseliot> kn100: it looks like (somehow) the driver can't read the EDID of your monitor. There are ways around it. Can I see your xorg.conf too, please?
[17:07] <kn100> tseliot, of course :)
[17:07] <kn100> tseliot, it's a dvi > vga adapter for the monitor, I didn't have any spare dvi cables
[17:08] <pitti> cjwatson: "zimmer"? (that's German for "room"..)
[17:08] <Laney> "zimmer frame" — comes from the name of a company
[17:08] <maco> pitti: wait so mdz's last name...?
[17:08] <slangasek> maco: "Chamberlain"
[17:09] <tseliot> :-)
[17:09] <pitti> maco: right, "Zimmerman" == "Carpenter" in German :)
[17:09] <pitti> well, Zimmerman_n_
[17:10] <cjwatson> and Carpenter is a fairly common surname in English
[17:10] <slangasek> oh, carpenter?  huh
[17:10] <maco> slangasek's translation is funnier
[17:10] <alex-weej> since karmic and now on lucid alpha, my system has been scanning my ext4 root partition every single boot... is there any way to debug this, maybe get it to print out out the reason it decides to scan?
[17:10] <slangasek> Laney: we don't have Zimmer frames over here, just walkers :)
[17:11] <kn100> alex-weej, I also have that issue, and ureadahead exits with some status error right
[17:11] <kn100> also tseliot my xorg, http://pastebin.com/S15rcGH4
[17:11] <Laney> It's one of those names that has entered common parlance, like Hoover
[17:11] <pitti> alex-weej: you mean really extensively?
[17:11] <pitti> alex-weej: there has been a quick fsck at every boot forever
[17:11] <alex-weej> pitti, well it's quick i guess because it's ext4, but it still takes 10-20 seconds or so
[17:11] <pitti> alex-weej: ok, that's the "extensive" category already
[17:12] <alex-weej> pitti, you know i may be falsely diagnosing this then...
[17:12] <pitti> it usually should take a fraction of a second to see  that they are clean
[17:12] <alex-weej> i assumed it was taking 10-20 seconds because my system does nothing for a while whilst i can hear some sort of disk activity, and then it prints the usual fsck "clean" message
[17:12] <alex-weej> maybe bootchart will help?
[17:13]  * psusi hates seeing bugs that have gone unfixed in thunderbird since 2004.. maybe it's time to find a new mail client...
[17:13] <pitti> alex-weej: it might also be readahead, and fscking afterwards; hard to tell
[17:13] <pitti> alex-weej: bootchart will definively show it, yes
[17:14] <alex-weej> pitti, i will have a look now thanks
[17:15] <tseliot> kn100: I guess there's no other way to solve your problem so
[17:15] <tseliot> You can use nvidia-settings to get your EDID info. Run nvidia-settings, click on DFP-0 (or whatever your monitor is listed as), then click "Acquire EDID..." and save the file somewhere in your home directory (you may want to move it to another place after this though e.g. /etc/X11/
[17:15] <tseliot> Then add something like this in the "Device" section of your xorg.conf:
[17:15] <tseliot> Option "CustomEDID" "DFP-0:/etc/X11/your_edid_file"
[17:16] <kn100> tseliot, any idea what might be going wrong? think I should try updating to see if any patches have come through
[17:16] <tseliot> (replace DFP-0 with your monitor, which seems to be CRT-0, at least in the log)
[17:17] <tseliot> kn100: (replace DFP-0 with your monitor, which seems to be CRT-0, at least in the log)
[17:18] <tseliot> kn100: and I have no idea about the real cause of the problem. The driver is closed
[17:22] <NCommander> what's the proper way to load a module at boot time? I'm packaging something that requires a specific kernel module to be loaded (it also includes a udev rule, but the rule doesn't load the module, nor am I sure if thats possible)
[17:23] <slangasek> NCommander: by having it set proper aliases so udev loads it automatically
[17:29] <NCommander> slangasek: aliases?
[17:32] <slangasek> NCommander: /lib/modules/$(uname -r)/modules.alias
[17:33] <kn100> tseliot, sorry for the constant join/parting, my internet has been as reliable as a donkey with no legs for the past week or so. Have you said anything?
[17:34] <tseliot> kn100: I said that I have no idea about the real cause of the problem. The driver is closed.
[17:34] <kn100> tseliot, switching back to the free ones doesn't fix it
[17:34] <kn100> tseliot, and i like to use my hardware :)
[17:35] <tseliot> kn100: if you do what I suggested you should get your resolution back
[17:35] <kn100> tseliot, I didn't get anything you said
[17:35] <kn100> tseliot, as in i physically didn't receive it, my modem kept rebooting
[17:36] <tseliot> kn100: ok, let me put the instructions on pastebin (I don't want to spam the room with my instructions)
[17:36] <kn100> tseliot, ok
[17:37] <tseliot> kn100: http://pastebin.ubuntu.com/397366/
[17:38] <kn100> tseliot, OK i'll try that if this update doesn't fix it
[17:38] <tseliot> ok
[17:38] <alex-weej> pitti, turns out it is ureadahead after all... the fsck.ext4 does indeed take a fraction of a second
[17:38] <pitti> alex-weej: ok, *phew*
[17:39] <alex-weej> still, there's nothing on screen for 8s -> 31s while ureadahead and plymouthd are running
[17:58] <Laney> Would it be possible for someone to subscribe ubuntu-cli-mono-dev to all packages it can upload?
[17:58] <Laney> I want a nice +packagebugs page... hopefully this can be done easily with the LP API
[18:00] <Laney> although if that would cause bugmail to go to all team members, obviously not
[18:00]  * Laney hopes that would not be the case
[18:01] <seb128> it would if the team has no mailinglist
[18:01] <Laney> yeah, it doesn't
[18:01] <seb128> so set one ;-)
[18:01] <Laney> is there a /dev/null solution?
[18:01] <seb128> setting a list
[18:02] <Laney> someone in the DMB will need to do that
[18:02] <Laney> I guess an LP list would be fine
[18:02] <seb128> right
[18:03]  * Laney requests any passing DMB reader to do so
[18:12] <smoser> pitti, are you around ?
[18:16] <psusi> I thought that the kernel did not create a dev node for the extended partition.. as in the container itself, not the partitions in it?
[18:16] <cjwatson> Laney: nominate an address
[18:17] <cjwatson> Laney: or do you want me to create an LP list attached to ~ubuntu-cli-mono-dev?
[18:17] <pitti> hi smoser
[18:17] <smoser> I'm looking at http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/eucalyptus/lucid/annotate/head%3A/debian/source_eucalyptus.py . after working through some bugs in it, i'm to the point where I'm spinning in apport-cli (http://bazaar.launchpad.net/%7Eubuntu-core-dev/ubuntu/lucid/apport/ubuntu/annotate/head%3A/bin/apport-cli) ~ line 208.  the files attached in the first link are large
[18:18] <cjwatson> Laney: when I try that, it says "Ubuntu mailing lists should not be created here. Create them at lists.ubuntu.com instead.", although there's still an "Apply for Mailing List" button
[18:19] <cjwatson> lamont: is it OK to create a list for ~ubuntu-cli-mono-dev on LP?  It seems a bit ... special-purpose for lists.u.c somehow?
[18:19] <smoser> i do think its making progress, but it is very slow. is there a better way to attach large files ?
[18:20] <Laney> cjwatson: I'm not fussed where it ends up... the main reason is so that I can get the team subscribed to all of the packages
[18:21] <Laney> although maybe lists.u.c would be better so that it subscriptions can be open (don't know if the LP list would be)?
[18:21] <cjwatson> Laney: well, once the list exists, you can certainly do the mass subscription yourself; distro_source_package has an addBugSubscription method
[18:22] <Laney> cjwatson: I can't as I'm not a team adin
[18:22] <cjwatson> LP list subscriptions wouldn't be open because you'd need to join the team
[18:22] <Laney> admin*
[18:22] <smoser> the files sizes are:  12M axis2c.log   10M cloud-debug.log   4.0K httpd-cc_error_log
[18:22] <smoser>  26M cc.log      8.9M cloud-output.log
[18:22] <smoser>  . I dont think it makes a lot of sense to show the user these through a pager.
[18:22] <Laney> I can just give someone the script to run on my behalf though
[18:22] <pitti> smoser: in that line it just compresses the data
[18:23] <lamont> cjwatson: I don't see why not - is it creating enough volume on ubuntu-mono to warrant its own list?
[18:23] <cjwatson> Laney: oh, indeed, it's restricted to Launchpad/team admin
[18:23] <pitti> smoser: oh, sorry, it uncompresses it; apparently you chose to show the report?
[18:23] <cjwatson> lamont: that team doesn't have a contact address right now; I'd be happy to set it to ubuntu-mono, if that's the right thing to do
[18:23] <cjwatson> Laney: ^-
[18:23] <smoser> hm.. i didn't htink i chose to. its apport-cli. just a minute i'll walk through again.
[18:23] <cjwatson> (I wasn't aware of that list)
[18:23] <pitti> smoser: we probably might not show values which are larger than a certain threshold
[18:24] <cjwatson> ubuntu-mono seems to be getting bugmail already
[18:24] <Laney> I don't know what ubuntu-mono is
[18:24] <Laney> it's probably for that MOTU mono team
[18:24] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-mono/
[18:24] <smoser> pitti, i never answered that i want to see the log
[18:24] <Laney> cjwatson: looks good then
[18:25] <cjwatson> yes, it's getting bug notifications for MOTU Mono Team
[18:25] <cjwatson> but two teams can't have the same contact address AFAIK
[18:25] <pitti> smoser: ah, it's building the paged details before asking the question
[18:25]  * Laney rolls eyes
[18:25] <pitti> smoser: it should only build it if you agreed to showing it
[18:26] <smoser> yeah, and i think the threshold is a good idea too
[18:26] <smoser> there is no sense in sending dozens of megabytes to a pager
[18:26] <smoser> no human is going to look at that.
[18:27] <smoser> for EucalyptusCloudOutputLog, its spinning for minutes at this point
[18:32] <psusi> so what are the odds on getting a patch in for lucid to fix parted to be able to manipulate partitions on a disk that has other partitions in use on it, like it could in karmic?  seems upstream tore out the code that used the new ioctls because it didn't check for errors removing partitions that were in use
[18:32] <psusi> I'm seeing about putting it back in, with the correct error checking
[18:37] <cjwatson> Laney: I don't know what to do here - if you want a list on lists.u.c, perhaps you could mail RT for it?
[18:38] <Laney> cjwatson: I'll see if the subs can be moved over from ~mono
[18:38] <ccheney> what time today is the beta freeze lifted?
[18:38] <Laney> and then the mailing list moved over
[18:39] <Laney> well, removed from ~mono
[18:42] <directhex> ccheney, good question - i'm waiting for an archive admin to be freed from the shackles of freeziness & sync banshee
[18:43] <ccheney> i'm prepping a OOo 3.2.0 upload using new deb format 3 so need to do some testing with it asap :)
[18:43] <cjwatson> ccheney: it'll be tomorrow now, the respins yesterday pushed us back
[18:45] <ccheney> cjwatson: ok no problem
[18:45] <directhex> ccheney, debsrc 3.0? you trailblazer you!
[18:45]  * ccheney will probably throw it in a ppa for early testing tonight
[18:46] <ccheney> directhex: yea debian switched over already so i will follow them, easier than debugging the 1.0 stuff
[18:46] <pitti> ccheney: we have quite a bunch of 3.0 packages in the archive now
[18:46] <directhex> one of them's mine
[18:46] <ccheney> also means we won't have a 100MB diff.gz anymore :)
[18:46] <directhex> would be hellish to do moon with debsrc 1.0
[18:46] <cjwatson> ccheney: (you know we don't support multiple .orig tarballs yet, right?)
[18:47] <ccheney> pitti: yea i saw some of the comments about getting them in a while back, sounds like i shouldn't have any trouble assuming the rules file is ok
[18:47] <ccheney> cjwatson: uh, we don't?
[18:47] <directhex> cjwatson, you don't? it's in the archive & working...
[18:47] <cjwatson> openssh is much more manageable as 3.0 (quilt)
[18:47] <cjwatson> directhex: where?
[18:47] <cjwatson> I was sure that was still unsuppoed
[18:47] <cjwatson> unsupported
[18:47] <ccheney> isn't that the main point of 3.0 support?
[18:47] <cjwatson> no?
[18:47] <directhex> cjwatson, http://packages.ubuntu.com/source/lucid/moon
[18:48] <directhex> cjwatson, don't think bzr plays nice with it though
[18:48] <directhex> for bzr buildpackage foo
[18:48] <cjwatson> directhex: gosh
[18:48] <cjwatson> I stand corrected
[18:48] <ccheney> ok well i'll find out if we support multiple tarballs when i upload tomorrow i guess :)
[18:48] <ccheney> the new OOo has 5 tarballs
[18:48] <cjwatson> ccheney: the main point is to integrate patch systems into dpkg proper, but there are various other fringe benefits
[18:49] <ccheney> cjwatson: ah ok
[18:49] <ccheney> even at 5 it is still a grouping of tarballs of tarballs, heh
[18:49] <directhex> oo build system is nutty
[18:49] <directhex> and fruity
[18:50] <cjwatson> obviously being able to get rid of tarball-in-tarball packaging is good as well, but the number of packages with multiple orig components is quite small (even if the packages themselves tend to be significant) so it can't really be described as the main point I think
[18:52] <zyga> mvo: is there any way you could help me extract install scripts from all packages in the archive?
[18:53] <zyga> mvo: I want to make a list of packages that need c-n-f related meta-data, a simple grep for 'update-alternatives' in the install script will solve that
[18:54] <directhex> cjwatson, the big issue with debsrc 3.0 is backportiness... launchpad will reject debsrc 3.0 uploads for pre-lucid, including PPA uploads. which is vexatious for the whole backporting thing
[18:55] <ccheney> directhex: eh, so i can't upload a debsrc 3.0 lucid ppa package?
[18:56] <ScottK> You can for Lucid only.
[18:56] <directhex> ccheney, lucid yes, but not karmic & earlier
[18:56] <ccheney> ScottK: ah ok, i misparsed the sentenced
[18:56] <ccheney> ed /d$//
[18:57] <ccheney> directhex: lucid is a LTS so no need to backport past that ;-)
[18:57] <cjwatson> directhex: for anything that isn't multiple-orig and doesn't have include-binaries switched on, it should just be a matter of rm -f debian/source/format
[18:58] <cjwatson> directhex: it's fairly easy to glom any 3.0 package back to 1.0; you might not want to maintain the result afterwards (frex, worst case, just make it a giant native tarball, PLEASE DON'T DO THIS FOR OOO), but it would *work*
[18:58] <micahg> cjwatson: I've noticed also packages are having the patch system stripped from build-dep as well
[18:58] <ccheney> cjwatson: oh i don't need to do that for OOo we have the rules hacked to support 1.0 its just not well tested
[18:59] <cjwatson> micahg: as is right and proper for 3.0.  but you don't *need* a patch system for 1.0
[19:00] <micahg> cjwatson: right, but if there are patches, it needs to be added back...just noting that
[19:00] <cjwatson> no, that doesn't hold
[19:00] <cjwatson> in an unpacked 3.0 format package, all the patches are applied by dpkg
[19:00] <cjwatson> therefore, just leave them in the applied state when you pack it back up in 1.0 format
[19:00] <cjwatson> easy
[19:00] <micahg> cjwatson: ah, ok, that's what you meant by not maintainable :)
[19:01] <cjwatson> presumably for a backport you don't care anyway - if you're maintaining a backport as a non-trivial branch, you're probably doing it wrong
[19:02] <micahg> cjwatson: yep, I just missed that originally
[19:03] <ccheney> the OOo tarball for debian is only ~ 250K and only 2.1MB for Ubuntu, much better than the old diff.gz
[19:04] <ccheney> er debian specific OOo tarball i meant to say
[19:22] <smoser> pitti, i linked a branch to bug 486122 , which is what a dupe of the same issue i was talking about above.
[19:31] <zyga> is there an easy way to know dpkg --print-architecture and (python) os.uname() values for amd64, ppc64 and arm?
[19:43] <kees> if policykit-1 is "current", can we drop polickit from lucid?
[19:50] <\sh> what was the magic kernel append param to disable the switch to colour frame buffer ?
[19:50] <\sh> nomodeset or something?
[19:51] <pitti> kees: I'd love to, but there's still a couple of universe packages which need it
[19:51] <zyga> \sh: I think it's listed when you select F3 or F4
[19:51] <zyga> \sh: (in grub menu screen)
[19:51] <pitti> smoser: thanks, will have a look
[19:51] <\sh> zyga: I don't have grub ;) I'm directly booting via pxe + dhcp + tftp a kernel ;)
[19:51] <zyga> \sh: I think your guess was right, nomodeset, I can tell you for sure if you wait
[19:51] <slangasek> \sh: no, "nomodeset" is a switch to disable KMS support in your video driver, and is exclusively a workaround for kernel+X bugs
[19:52] <smoser> pitti, no hard feelings if you don't like hiding long files, but i do think there is no point in building the massive string if not being shown.
[19:52] <pitti> smoser: right; that is obvious, it should be moved inside the if block
[19:52] <pitti> kees: it's in universe now, at least
[19:52] <rafiyr> nothing like a disk less workstation for some peace and quiet in the office
[19:52] <slangasek> there is no switch to disable color framebuffers; there are switches to do other things which might disrupt your framebuffer display as a side effect
[19:52] <\sh> slangasek: ok...how do I tell nowdays ubuntu kernel to not switch into framebuffer at all? looks like a ESX VMWare machine doesn't like it somehow
[19:53] <rafiyr> (in resp to \sh)
[19:53] <slangasek> \sh: if you boot without 'splash', then plymouth won't try to *use* the color framebuffer
[19:54] <slangasek> but fbcon is still loaded and used as your default console
[19:54] <\sh> slangasek: I don't have plymouth or something like that
[19:54] <slangasek> then I have no idea what problem you're experiencing
[19:54] <slangasek> maybe you're screen is blank *because* you don't have plymouth
[19:54] <mvo> zyga: I have a script that can run over a local mirror that could help with that I guess
[19:54] <slangasek> s/you're/your/
[19:55] <kees> pitti: okay, cool
[19:55] <\sh> slangasek: well not blank...but the last line is "Console: switching to..." and then *bing* stop
[19:55] <zyga> mvo: is your script ready for that? (to produce list of packages that use update-alternatives)? If you give me the full list of packages I'll patch each one with meta-data myself
[19:55] <\sh> I'm trying to debug it now...and wonder how can someone prevent the kernel from doing this switch
[19:55] <slangasek> \sh: what does it say it's switching to?
[19:55] <\sh> Console: switching to colour framebuffer device 80x30
[19:56] <slangasek> the only way to prevent it is by preventing fbcon from loading, and there's no setting for that
[19:56] <\sh> slangasek: initramfs magic?
[19:57] <slangasek> \sh: is this lucid?
[19:57] <\sh> slangasek: yes
[19:57] <mvo> zyga: it will need a bit of tweaking, I can give it a go tomorrow
[19:57] <slangasek> \sh: then unless you also have cryptsetup installed, fbcon isn't in your initramfs
[19:57] <zyga> mvo: great, if I can write the script for you just tell me please
[19:57] <slangasek> \sh: you could use 'break=init' to stop the initramfs before switching to the rootfs and fiddle by hand
[19:57] <superm1> pitti could you take a look at http://pastebin.com/SGZyUmPa ? it appears to handle the immediate error i'm seeing with 540375, but i was hoping to get your eyes on it too
[19:58] <\sh> slangasek: ok...let me try and debug this...trying to get fai + ubuntu lucid to work properly
[20:00] <mvo> zyga: all it really takes is a "find" and "dpkg -I libnet1_1.1.4-2_i386.deb postinst|grep update-alternatives" I guess
[20:01] <zyga> hmm, right
[20:01] <mvo> zyga: if you write it and mail it to me I will run it on a local mirror
[20:01] <pitti> superm1: hm, it was actually intended that way
[20:01] <zyga> ok, any hint on how the mirror path/directory layout looks like?
[20:01] <mvo> zyga: plus it needs to filter out the non-lucid packages from the mirror, so its probably not that trivial
[20:01] <zyga> mvo: I can do that in another step, I want to hit as many packages as I can now
[20:01] <pitti> superm1: I duped it to bug 540750
[20:02] <mvo> zyga: its a pool/ direcotry that has all the debs from multiple distro relesaes
[20:02] <zyga> mvo: ok, I'll figure the rest out - thanks
[20:02] <mvo> zyga: the mirror will just look like archive.ubuntu.com/ubuntu/pool etc
[20:02] <mvo> zyga: cool, thanks
[20:11] <zyga> mvo: it's not perfect but: for pkg in /var/cache/apt/archives/*.deb; do ar p $pkg control.tar.gz | tar zxO ./postinst 2>/dev/null | grep --quiet update-alternatives && echo $pkg; done
[20:12] <zyga> obviously the path needs to be switched
[20:12] <zyga> (or you could splice find inside)
[20:17] <mvo> zyga: dpkg-deb -I $pkg postinst does not work?
[20:18] <zyga> -l ?
[20:19] <zyga> no (unless my font is bad and I cannot distinguish -l from -something-vertical)
[20:21] <cjwatson> capital i
[20:22] <sebner> bdrung: you happen to be around? sebner@ubuntu:~$ eclipse
[20:22] <sebner> Trace/breakpoint trap (core dumped)
[20:27] <sebner> bdrung: hmm, I guess I'll wait until you upload 3.5.2 and see if it fixes it :)
[20:28] <pitti> smoser: hm, did that actually work for you? %s % max_show looks like a crash
[20:28] <smoser> really ?
[20:28] <smoser> i did test it.
[20:29] <smoser> you think %i there ?
[20:29] <pitti> yes, it's an int surely?
[20:29] <smoser> i think because an int can be converted to string
[20:29] <pitti> oh, indeed
[20:29] <pitti> Python does that automatically apparently
[20:29] <pitti> smoser: ok, nevermind
[20:29] <pitti> >>> print 'hello %s' % 3
[20:29] <pitti> hello 3
[20:29] <smoser> $ python -c 'f=1024 * 1024 ; print "%s\n" % f'
[20:29] <smoser> 1048576
[20:29] <smoser> right
[20:29] <smoser> same thin g
[20:29] <smoser> :)
[20:34] <zyga> cjwatson: thanks, that was it
[20:36] <zyga> cjwatson: strange, brute-force method is quite faster!
[20:36] <zyga> dpkg-deb is slower than ar + tar
[20:39] <cjwatson> zyga: seems like a bug; OTOH dpkg-deb actually works on all packages ;-)
[20:39] <cjwatson> (actually that's probably unfair, control.tar.gz is always .gz AFAIK)
[20:39] <cjwatson> the point is more relevant for dpkg --fsys-tarfile really
[20:52] <ev> pitti: would you be so kind as to accept ubiquity/apport/source_ubiquity.py into apport upstream?  It would be handy for post-install debugging as ubiquity copies its install logs to the target system.
[20:52] <pitti> ev: not into apport upstream, but certainly into the ubuntu package
[20:52] <ev> pitti: ah, indeed
[20:53] <pitti> ev: although I'd rather see it as an "installer" symptom
[20:53] <pitti> this could then figure out whether it's d-i, ubiquity, or whatnot
[20:53] <pitti> "ubuntu-bug installer"
[20:53] <pitti> ev: but I guess we could have both actually
[20:54] <ev> cool!
[20:56] <pitti> ev: just want to commit it yourself, or shall I grab it for you?
[20:58] <ev> pitti: Sure, I can do it.  Is it lp:~ubuntu-core-dev/ubuntu/lucid/apport/ubuntu ?
[20:58] <pitti> ev: right; just add it to data/package-hooks/
[20:59] <pitti> ev: I guess you'll also need to add a Replaces: ubiquity then?
[20:59] <ev> indeed
[21:08] <ev> done
[21:18] <pitti> ev: looks fine, thanks
[21:20] <ev> cool
[21:26] <elmo> does anyone know if our cups supports discovery of printers via bonjour/avahi?  docs suggests it's possible but not enabled by default or exposed through the gui as an option, curious as to why
[21:26] <elmo> tkamppeter/pitti: ^--
[21:28] <pitti> elmo: it should work, but we do not enable printer discovery by default indeed
[21:28] <pitti> elmo: because we have a policy that all discovered services must be clearly marked so for the user
[21:28] <elmo> pitti: sorry, I should have been clear, the 'enable printer discovery' button in the gui only covers CUPS/IPP broadcasts
[21:28] <pitti> elmo: and our GTK/KDE print dialogs currently don't
[21:28] <elmo> (at least for me, on Karmic)
[21:28] <pitti> it's not clear whether a printer is locally configured or just randomly picked up by auto-discovery
[21:29] <elmo> pitti: right
[21:29] <pitti> elmo: hmm; it should certainly enable avahi as well
[21:29] <elmo> BrowseRemoteProtocols CUPS
[21:29] <elmo> is all I get after clicking the button
[21:31] <elmo> (and BrowseLocalProtocols which is more relevant is empty)
[21:32] <pitti> tkamppeter: ^
[21:39] <nemo> http://packages.ubuntu.com/intrepid/golly - horribly out of date. They are on 2.1 now and many cool demos do not work in it
[21:42] <ScottK> nemo: Intrepid goes out of support next month, it's really quite old and out of date, as you've discovered.
[21:43] <nemo> ScottK: also out of date in karmic
[21:43] <nemo> ScottK: hasn't been updated in ages is what I'm getting at :)
[21:44] <nemo> http://archive.ubuntu.com/ubuntu/pool/universe/g/golly/  - only 1.4
[21:44] <jpds> nemo: It's maintained by Debian, and they uploaded a new package on the 1st of this month, by that time; we had frozen.
[21:44] <nemo> aww
[21:44] <nemo> oh well.
[21:44] <nemo> luckily downloading and running 2.1 doesn't require building anything
[21:44] <ScottK> You can ask for a freeze exception, but it'll take a bit of research.
[21:45] <nemo> well, if at least 1.4 made it, that allows some stuff to run...
[21:46] <nemo> it did
[21:46] <nemo> yay
[21:46] <nemo> but, for example: http://www.sq3.org.uk/wiki.pl?Von_Neumann%27s_Self-Reproducing_Universal_Constructor
[21:46] <nemo> doesn't run in 1.4
[22:08] <superm1> pitti, it was intended to check for bash, or just to generally check for a repo?
[22:08] <superm1> pitti, particularly in my case the repo doesn't necessarily have bash on it, but it has a bunch of other interesting things
[22:13] <ev> pitti: if you have a free moment, do you consider this a bug, or expected behavior: http://paste.ubuntu.com/397490/
[23:51] <xorl> can any of you tell me why apache is so fixated on uid 33?
[23:51] <cjwatson> that would be www-data
[23:51] <xorl> I can't seem to FORCE it to use another user/group w/out it starting a process as the www-data (uid)
[23:52] <xorl> but then magically the rest are my user/group defined
[23:52] <cjwatson> oh, I thought you meant why that particular uid as opposed to that particular user.  no idea then.
[23:52] <xorl> cjwatson: yeah, weird bug/glitch on Hardy Server LTS
[23:54] <xorl> changed the configs to my own custom configs and now it just spawns one process as the magical www-data, and then the rest as what I specified in httpd.conf (User/Group)
[23:54] <xorl> as soon as I renamed the www-data user, it changed it's identity so it must be fixated on that uid which is weird