[00:01] <superm1> cjwatson, cody-somerville right. well at least in the context that cody-somerville was referring to, it's more relevant that it is a bootable live disk
[00:04] <billybigrig> pochu: .31-2.16 doesn't seem to have an gspca fixes either
[00:05] <james_w> slangasek: hey. Is there any way for cron to use common-session in PAM, but not the pam_ck_connector that is declared within?
[00:05] <james_w> or is that question too crazy to even contemplate?
[00:06] <slangasek> james_w: yeah, that's too crazy; the mechanism for selecting different modules based on service is to configure /etc/pam.d/$service :)
[00:06] <james_w> yeah :-)
[00:06] <james_w> but, but... https://bugs.edge.launchpad.net/ubuntu/+source/consolekit/+bug/287715/comments/5
[00:07] <slangasek> "This PAM module should be used with caution; only local login managers such as login should use this."
[00:07] <james_w> (the new GDM has further increased the priority of this somewhat)
[00:07] <slangasek> hrm?  how would that be an issue for GDM?
[00:08] <james_w> it's a bit baroque
[00:08] <slangasek> this is basically a manifestation of the "we need to distinguish between interactive and noninteractive sessions in PAM" bug
[00:08] <james_w> GDM now tries to be clever with the user selector by showing users in frequency order
[00:08] <james_w> to do this it calls ck-history --frequent
[00:08] <slangasek> ah, so it sees cronjobs, haha
[00:08] <james_w> that in turn parses /var/log/ConsoleKit/history
[00:09] <james_w> we've fixed it so that it only shows non-system users
[00:09] <james_w> but if you have a */10 cronjob say, you appear to log in a lot
[00:09] <slangasek> right; so the right thing is that we need to *split* /etc/pam.d/common-session, for this reason and others
[00:09] <james_w> the more sever issue is that with cron running so often /var/log/ConsoleKit/history is huge, and --frequent requires parsing the whole thing
[00:10] <james_w> so it takes a few seconds after getting to GDM to actually get any users listed
[00:10] <pochu> billybigrig: I have no clue about that, sorry
[00:11] <james_w> I'm adding logrotate to consolekit to keep the size limited, and considering a new mode for ck-history that is a frequency/recency measure, but fixing this would still be good
[00:11] <james_w> is the split something that is planned, or just needed?
[00:12] <slangasek> james_w: Debian bug #169930, fwiw; I don't have anything more than the roughest notion of what the split needs to look like, at this point
[00:12] <james_w> ok, thanks
[00:12] <james_w> I guess it's unlikely to be done this cycle?
[00:13] <james_w> in that case, is just waiting for the correct fix the right thing to do, and just work on the other fixes to the symptoms?
[00:15] <directhex> cjwatson, looks like the TB can see into the future
[00:15] <slangasek> james_w: if this log scales poorly, presumably terminal servers are going to have the same problem, right?  So the symptom should still be addressed, one way or another
[00:16] <james_w> yeah, that should still be fixed
[00:16] <james_w> I don't see another fix for that original bug though
[00:16] <slangasek> huh, where did ubottu get that wrong description and bug state?
[00:17] <james_w> I'm thinking of using logrotate's behaviour to involve recency in the frequency calculation
[00:17] <slangasek> yeah, I can't offer much for that bug right now; any workarounds would be fussy and make the path to a correct fix longer
[00:18] <james_w> parse the first file, emit the frequency-based user list from that, then parse the first rotated file, and emit any further users from that in frequency order, etc.
[00:18] <james_w> so that the GDM list can fill asynchronously in still a useful order
[00:18] <james_w> ok, thanks, I await a true fix
[01:01] <TheMuso> So 2.6.31-rc2 fixes one thing for me, but breaks another. :)
[01:01] <RAOF> Hurray!
[01:02] <TheMuso> yeah, but I've just found that what seems to be broken as a user, seems to work as root./
[01:02] <TheMuso> Seems some ioctls for talking to DVD/CD drives only work as root.
[01:02] <TheMuso> i.e the eject command as a user doesn't work, but as root works fine.
[01:03] <ion> Seems to work for me.
[01:04] <TheMuso> ion: You on 2.6.31-2-generic?
[01:04] <TheMuso> And what arch?
[01:04] <ion> Linux hapatus 2.6.31-2-generic-pae #15-Ubuntu SMP Mon Jul 6 02:33:43 UTC 2009 i686 GNU/Linux
[01:05] <TheMuso> ok I am on amd64.
[01:06] <ion> If the multiarch thing were already in place, i could simply switch this system to amd64 and give results soonish. :-P
[01:06] <TheMuso> heh
[01:13] <slangasek> doko: do you know why build-essential no longer has a direct dependency on gcc?  The most recent changelog entry still talks about it
[01:21] <slangasek> doko: looks like a bug in the patch for build-essential 11.4, which doesn't match the changelog entry
[01:47] <Kage_Jittai> persia: They still have not backported our project :\
[01:48] <Kage_Jittai> persia: https://bugs.launchpad.net/ubuntu/+source/tmw/+bug/393724
[01:49] <Kage_Jittai> see this is they type of unresponsiveness we have to deal with
[01:51] <slangasek> Kage_Jittai: that's not the correct procedure for requesting backports.  https://help.ubuntu.com/community/UbuntuBackports#How%20to%20request%20new%20packages
[01:53] <Kage_Jittai> slangasek: I was told it would work
[01:53] <slangasek> you were told incorrectly, then; the page I've linked you to documents how to request backports
[01:53] <Kage_Jittai> slangasek: I don't have time to read that page
[01:54] <slangasek> filing a bug on the package isn't going to be noticed by the backports team
[01:58] <Kage_Jittai> https://bugs.launchpad.net/dapper-backports/+bug/396317
[01:58] <Kage_Jittai> will that work?
[01:59] <slangasek> should have been filed against the hardy-backports project rather than dapper-backports, but that should show up on the backport team's radar anyway, yes
[02:00] <Kage_Jittai> slangasek: *sigh* Dapper needs to be backport too prolly
[02:00] <Kage_Jittai> but Hardy is the most used out of date
[02:00] <slangasek> doubtful, given that dapper desktop support expires in a few short days
[02:00] <Kage_Jittai> ok
[02:01] <Kage_Jittai> I remember when dapper was new :P
[02:01] <Kage_Jittai> slangasek: ok, well, I hope this doesn't vanish with it
[02:01] <Kage_Jittai> slangasek: well see if the backport team picks up on it this time
[02:02] <Kage_Jittai> *sigh*
[02:02] <ajmitch> some people have no patience
[02:02] <wgrant> Indeed.
[02:02] <ajmitch> 220 open hardy-backports bugs, I doubt they'll find time to backport some game client in the next couple of hours
[02:04] <ajmitch> good to see backport requests open for stuff that hasn't even landed in karmic yet
[02:06] <slangasek> I see tmw 0.0.29.1-1 in karmic
[02:07] <ajmitch> slangasek: sorry, I was referring to a bug for php 5.3
[02:08] <ajmitch> it seems that a few people want that version
[02:11] <slangasek> ah
[02:11]  * slangasek uploads php 5.3 as a dummy package depending on python
[02:12] <TheMuso> heh
[02:12]  * wgrant likes that idea.
[02:12] <ajmitch> you'd probably make a lot of sysadmins very happy
[02:14] <TheMuso> ...or mad.
[02:14] <wgrant> No, you'd make developers mad.
[02:15] <persia> Well, and those few sysadmins that already got bullied into isntalling some unofficial php5.3 package.
[02:16] <ajmitch> because their developers needed goto?
[02:16] <persia> well, because their developers are mad and interrupting their sleep
[03:12] <TheMuso> pitti: Ok, I have found which event device is for my touchpad using lsinput and input-events, so its fine at the kernel level. Seems hal is not picking it up properly, here is the lshal block for the touchpad. http://paste.ubuntu.com/211657/
[03:21] <Sarvatt> does it work when you rmmod psmouse && modprobe psmouse?
[03:22] <Sarvatt> i've been having to boot with i8042.reset=1 since around 2.6.30-git13 for mine to get detected as a touchpad instead of a generic mouse every other boot
[03:23] <Sarvatt> they added a quirk to always do that for my machine in dtor's input tree but it hasnt hit linus' yet
[03:24]  * ScottK opines we could use some new developer with the energy for reviewing backports requests ...
[03:24] <Sarvatt> http://git.kernel.org/?p=linux/kernel/git/dtor/input.git;a=commit;h=9230ccb1071d2d7e4ecb6314e67203b9f7f08140
[03:25] <TheMuso> Sarvatt: Its USB.
[03:25] <TheMuso> psmouse is PS/2 only.
[03:26] <TheMuso> Sarvatt: And, I wouldn't even get feedback from my finger on the touchpad using input-events if the driver weren't loaded or loaded properly.
[03:29] <cody-somerville> Wow.
[03:30] <cody-somerville> Whoever sponsored network-manager-openvpn did not test it at all.
[03:30] <ajmitch> cody-somerville: does it take out NM?
[03:31] <cody-somerville> ajmitch, The binary is almost empty
[03:31] <cody-somerville> ajmitch, Just has the /usr/share/doc/ stuff
[03:31] <ajmitch> that's a bit odd
[03:31] <ajmitch> though the problem with sponsoring is usually how much you can test things are sane
[03:32] <cody-somerville> They should have atleast done dpkg-deb -c on the deb
[03:32] <StevenK> Although, when I sponsor I will at least check things built correctly
[03:36] <TheMuso> pitti: Seems I can't use suspend/hibernate from the logout menu, or run the gpm preferences as well. Not sure what I am looking for in lshal's output unfortunately, so more guidence will be needed. :)
[03:39]  * cody-somerville fixes network-manager-openvpn.
[03:41] <ajmitch> cody-somerville: looks like it may be something as simple as debhelper compat level
[03:42] <cody-somerville> ajmitch, That was my first thought
[03:42] <cody-somerville> Its actually DEB_DESTDIR in rules
[03:42] <ajmitch> at least the build log shows files going into debian/tmp, so it's just not picking them out of there
[03:42] <ajmitch> ok
[03:42] <cody-somerville> ajmitch, There is no $package.install file
[03:42] <ajmitch> a minor omission
[03:42] <cody-somerville> so DEB_DESTDIR needs to be $(CURDIR)/debian/network-manager-openvpn/ and not DEB_DESTDIR = $(CURDIR)/debian/tmp/
[03:52] <StevenK> debian/tmp is debhelper compat level 1 and 2!
[03:53] <persia> Hrm?  I get stuff in debian/tmp with debhelper 7, if I do it right.
[03:53] <ajmitch> StevenK: it's come back to haunt you
[03:54] <ajmitch> StevenK: the debhelper manpage lists it as a new fallback in 7
[03:56] <StevenK> Argh!
[03:56] <StevenK> Noooooo!
[03:56] <ajmitch> StevenK: embrace the evil
[03:56] <StevenK> Noooooo!
[03:57] <cody-somerville> If I don't have commit access to a universe package that is managed in bzr, does that mean I'm not allowed to upload?
[03:57] <cody-somerville> I've created a branch merge proposal
[03:57] <ajmitch> you're technically allowed to, I suppose, but it'd be polite to at least do a merge proposal
[03:57] <ajmitch> which you've done
[03:57] <persia> cody-somerville, Rather it means you should complain to whoever controls the bzr resource.  I'd suggest uploading, and submitting a merge request
[03:58]  * cody-somerville nods.
[03:59] <wgrant> No point trying to fix access rights now, as everything will change with package branches.
[03:59] <persia> What?  Why?
[04:00] <wgrant> Package branches are meant to get a flag to grant write access to uploaders.
[06:05] <pitti> Good morning
[06:07] <TheMuso> Morning pitti.
[06:07] <pitti> lool: thanks, no prob
[06:08] <pitti> ion: see /topic and u-d-a@; gdm upgrade is known to fail, unfortunately there's nothing to fix :(
[06:09] <gnomefreak> does that include losing the app bubbles on lower gnome pane by chance pitti
[06:09] <pitti> gnomefreak: it breaks gdm pretty much completely
[06:10] <gnomefreak> s/pane/panel
[06:10] <pitti> you _need_ to install it in screen, or a VT
[06:10] <gnomefreak> oh
[06:10] <gnomefreak> pitti: thanks
[06:11] <ajmitch> but it's only breakage for those of us silly enough to run karmic on our desktops already :)
[06:11] <pitti> TheMuso: can you please ubuntu-bug hal and add lsinput output? I'll take a look then and fix it upstream (please assign the bug to me)
[06:12] <pitti> TheMuso: no suspend/hibernate is a separate problem; sounds like gnome-power-manager isn't running; I uploaded a new one last night, does that work?
[06:12] <TheMuso> pitti: Probably haven't got it yet, due to keeping local mirror whic updates daily. I'll refresh it and try again.
[06:13] <pitti> TheMuso: is gnome-power-manager running? (pidof)
[06:13] <TheMuso> pitti: ok will file a bug ASAP.
[06:13] <TheMuso> pitti: Machine is currently not runing, just a sec.
[06:13] <TheMuso> *running
[06:13] <pitti> ah
[06:13] <TheMuso> its my notebok
[06:14] <TheMuso> gah bad typing this afternoon.
[06:15] <TheMuso> pitti: no its not running.
[06:15]  * TheMuso refreshes his local mirror.
[06:15] <pitti> TheMuso: if you start it from a shell with --verbose, what does it say?
[06:15] <ion> pitti: I was commenting about the link in the topic. It says “Press Ctrl+Alt+F7 to get back to the graphical login manager” where it should say “Run sudo /etc/init.d/gdm start to get back to the graphical login manager”. :-)
[06:15] <pitti> TheMuso: do you have devicekit-power 009?
[06:15] <persia> ion, Ctrl+Alt+F7 also works...
[06:15] <pitti> ion: oh, ok; thanks
[06:16] <pitti> but it should start automatically (did for me)
[06:16] <ion> persia: Not very well if gdm isn’t running.
[06:16] <TheMuso> pitti: yes I have that version of devicekit-power
[06:16] <TheMuso> just a sec I'll pastebin the gnome-power-manager output.
[06:16] <pitti> TheMuso: and gnome-power-manager 2.27.1-0ubuntu4?
[06:16] <persia> Ah.  I have an issue with gdm running too much, rather than not enough,  Perhaps slightly different.
[06:16] <TheMuso> pitti: gpm is ubuntu3, I'll refresh and try again.
[06:16] <TheMuso> s/refresh/update/
[06:17] <ion> pitti: 2.26.1-0ubuntu2 prerm ran gdm stop, 2.26.1-0ubuntu3 postinst ran gdm reload. gdm reload doesn’t seem to start gdm if it’s not running in the first place.
[06:17] <pitti> persia: after an upgrade from 2.20? should also be fixed now
[06:17] <pitti> TheMuso: right, known; 0ubuntu4 should fix it
[06:17] <persia> pitti, Hrm.  Wasn't fixed about 5 hours ago, but I'll admit not to having logged in again since then.
[06:18] <TheMuso> pitti: ok thanks.
[06:18] <pitti> persia: I only fixed 2.20 (jaunty) -> 2.26 upgrade
[06:18] <pitti> persia: if you have a different problem about "running too much", we need a new bug report, I think
[06:18] <persia> Right.  I'll upgrade, and try a new login test in an hour or so.
[06:21] <TheMuso> Gdm for me dies a random time after I log in, based on the amount of activity. Once I log in for a second time, things don't die till I reboot.
[06:22] <persia> That's close to my bug, but my death was always within a second or two.
[06:22] <persia> (or at least a fresh invocation occurred within that time)
[06:23] <TheMuso> persia: Right.
[06:28] <StevenK> pitti: So, this UNR MIR bug is getting confusing. I'd like to set the packages to a status when I've commented with a MIR, but it hasn't been checked yet -- what Status do you suggest? (And could you check one or two of the simple ones, like go-home-applet) ?
[06:40] <pitti> StevenK: I'd use "incomplete" for the ones which still need an MIR
[06:41] <pitti> StevenK: yes, we discussed how to handle the backlog and assign it to MIR folks, I'll do that today
[06:41] <StevenK> pitti: So, Incomplete if they need one written, and New if they're good?
[06:42] <StevenK> pitti: Do I need an MIR for unr-meta itself? :-)
[06:42] <pitti> StevenK: unr-meta> nope, just add a task
[06:42] <pitti> StevenK: right (states)
[06:43]  * pitti -> i915 debugging, brb
[06:43] <TheMuso> Hrm. I think update-grub needs to be made a dpkg trigger.
[06:45] <StevenK> pitti: What about ubuntu-netbook-remix-default-settings? It's trivial, effectively a bunch of gconf defaults
[06:46]  * TheMuso files a bug
[06:46] <persia> TheMuso, There's some trickiness in handling update-grub and/or update-initramfs singly and in combination: it may be a bit before anyone can fix it (it's not as simple as one might think)
[06:47] <TheMuso> persia: Right, but I'll file the bug anyway.
[06:47] <TheMuso> So its on the radar.
[06:49] <TheMuso> pitti: Yep, latest gpm works fine.
[06:51] <StevenK> TheMuso: gpm, or gdm?
[06:51] <StevenK> They are two different things :-)
[06:52] <TheMuso> StevenK: gnome-power-manager to be precise.
[06:54] <StevenK> TheMuso: Ahhh. I was thinking the console mouse thingy
[06:55] <pitti> StevenK: for stuff like this, just add a task and set it to "new"
[06:57] <TheMuso> StevenK: ah ok.
[06:59] <StevenK> pitti: Already done.
[07:51] <dholbach> good morning
[07:52] <pitti> StevenK: do you guys still need bug 219087  (moblin-applets)?
[07:52] <pitti> hey dholbach
[07:52] <dholbach> hiya pitti
[08:09] <StevenK> pitti: Nope.
[08:09] <StevenK> pitti: Kill it.
[08:09] <pitti> StevenK: done (timed out)
[08:10] <StevenK> pitti: Hehe, answer quickly or your MIR gets it?
[08:10] <pitti> StevenK: where "quickly" is "within half a year", yes :)
[08:10] <pitti> and you can always reopen if you still want/need it
[08:21] <pwnguin> is there a reason turnkey linux and ubuntu/canonical websites look nearly identical in theme / layout?
[08:31] <StevenK> pitti: Fix Commited for unr-meta makes it nervous, it means component-overrides will explode.
[08:31] <StevenK> s/it/me/
[08:32] <pitti> StevenK: c-mismatches doesn't look at MIR bug states
[08:32] <pitti> StevenK: it means "approved, but not promoted yet"
[08:32] <StevenK> pitti: Oh, right. I'm happy to go through and promote things in one huge lump after it's all done
[08:32] <pitti> StevenK: I think we should move them over in one batch, with unr-meta
[08:33] <StevenK> pitti: Works for me.
[08:33] <persia> pitti, My apologies.  While I could reproduce the gdm-appears-twice issue, I've just had a disk failure on the affected machine, and can't file the bug with ubuntu-bug.  GIven the other issues, it may be that the problem is not software-specific.
[08:34] <pitti> persia: good to hear from a gdm perspective, but I'm sorry for your broken hw; good luck with getting it fixed!
[09:22] <doko> slangasek: depends on g++, and g++ depends on gcc
[09:27] <SiDi> directhex: can you tell me where in http://www.microsoft.com/interop/cp/default.mspx is ECMA 334 listed please ? Cant find it
[09:30] <geser> pitti: re the jinja2 mir: sorry that I missed the pybabel reverse-recommends. should it be dropped from jinja2 as jinja2 is mostly used as a build-dependency and recommends don't get installed during build or should I add a mir for pybabel?
[09:31] <geser> I did a quick try to use jinja2 in pygments but failed at first, perhaps I should try a little bit harder
[09:31] <ojwb> mvo: I have a question about the DH_PYCENTRAL=include-links change in the xapian-bindings package
[09:32] <ojwb> mvo: I was going to slot it into the Debian packaging, to avoid having an Ubuntu diff, but I'm unsure exactly what it does, and so what it should be conditional on, if anything...
[09:39] <pitti> geser: pybabel> not sure what it is used for, does python-ninja2 import it?
[09:47] <geser> pitti: skimming through the source jinja2 has an i18n extension which can use gettext or pybabel for translating a webpage
[09:47] <pitti> geser: ah, the pygment Debian maintainer replied, he'll do the transition
[09:48] <pitti> geser: sounds like it could become a suggests then
[09:52] <geser> pitti: should I do an upload with this change? recommends -> suggests
[09:53] <pitti> geser: please do
[09:53] <pitti> geser: closed python-babel task
[09:57] <StevenK> % tail -n 1 data/desktop-switcher.desktop.in
[09:57] <StevenK> X-Ubuntu-Gettext-Domain=desktop-switcher
[09:57] <StevenK> pitti: ^
[09:58] <pitti> \o/
[09:58] <pitti> StevenK: that's hardcoded upstream? (eww)
[09:58] <StevenK> pitti: Therefore, I have nothing to do.
[09:58] <pitti> StevenK: ok, please set back to new then
[09:58] <StevenK> pitti: Upstream is effectively njpatel. :-)
[09:58] <pitti> it should at least be X-GNOME-*
[09:58] <pitti> anyway, good enough
[09:59] <StevenK> pitti: I can get s/Ubuntu/GNOME/ to happen upstream, easy enough
[09:59] <StevenK> pitti: desktop-switcher task thrown back to New
[09:59] <pitti> thanks
[10:10] <asac> StevenK: webfav. who will take care that this will work with ffox 3.5?
[10:12] <StevenK> asac: I'll talk to Bill Filler about that.
[10:12] <asac> StevenK: ok so he is the primary contact?
[10:12] <mvo> ojwb: hi! the include-links means that python-central does less magic in its maintainer scripts by doing all the symlinking at build time instead of install time
[10:13] <StevenK> asac: Yes, he's who I would talk to about it.
[10:13] <asac> StevenK: ill open a bug and assign it to him
[10:13] <mvo> ojwb: so it adds robustness and it also means that the package is immediately useful when installed/upgraded (as opposed to the default behavior where the .py files are only available after --configure and not in --unpack)
[10:14] <ojwb> mvo: OK, but should that only happen for Ubuntu?  and if so, should it only be for Ubuntu karmic and newer or what?
[10:14] <mvo> ojwb: I think it would be a good addition in debian too, personally I think include-links should the default
[10:14]  * ojwb saw something about it requiring rebuilds for newer python versions
[10:14] <mvo> for all of python-central
[10:14] <ojwb> though that's clearly not a frequent issue
[10:14] <mvo> yeah, that is the drawback
[10:15] <mvo> but for me (robustness + available on unpack) > a rebuild every  ~18 months :)
[10:15] <ojwb> seems reasonable to me
[10:17] <mvo> ojwb: thanks! (and thanks for the backport of the set_data() change from 1.1 to 1.0  for enrico)
[10:17] <pitti> cjwatson: FYI, the other day you asked me about disabling automount of internal disks; I located the problem now (bug 396448), working on it now
[10:19] <ojwb> mvo: no problem - let me know if it throws up any issues
[10:19] <StevenK> asac: Oh, subscibe me to the bug?
[10:19] <ojwb> if not, it should be in 1.0.14
[10:20] <ojwb> mvo: hmm, presumably that wants to go in karmic...
[10:20] <geser> pitti: could you please sponsor http://www.bienia.de/tmp/jinja2.debdiff ? I wasn't fast enough to upload it before it got promoted.
[10:21] <pitti> oh, sorry
[10:21] <ojwb> ah, feature freeze is aug 27th, so that's ok
[10:21] <mvo> ojwb: when is 1.0.14 scheduled?
[10:21] <ojwb> this month
[10:21] <mvo> for what date  I mean
[10:21] <mvo> great
[10:21] <mvo> that should work then :)
[10:21] <ojwb> yeah
[10:21] <ojwb> it could slip to august, but not by all of august
[10:22] <pitti> geser: done, thanks
[10:22] <mvo> ojwb: is the patch isolated enough to put it into the ubuntu 1.0.13 so that we can give it some early testing ? would that help you guys?
[10:23] <ojwb> it's isolated enough, and probably would
[10:23] <ojwb> esp if you're happy to nursemaid 1.0.14 in, since it would then have an ubuntu diff to resolve
[10:25] <pitti> Keybuk, Hobbsee: what did you do to get gdm started on vt1?
[10:26] <mvo> ojwb: ok, that should be fine, I have a look at the upstream svn log
[10:26] <Hobbsee> pitti: i turned on the machine, selected the kenel in gdm, and waited for it to boot.  ie, nothing different.
[10:26] <Keybuk> pitti: when I did the demo hack?  a cross hack?
[10:26] <Keybuk> but that was old gdm code
[10:27] <pitti> Keybuk: in the context of bug 396226
[10:27] <pitti> seems everyone there has gdm start on vt1 initially, and on vt7 the second time
[10:27] <mvo> ojwb: its r12994?
[10:28]  * ojwb looks
[10:29] <ojwb> no, that's the trunk version, which won't apply to 1.0.x
[10:29] <ojwb> http://oligarchy.co.uk/xapian/patches/xapian-flint-lazy-update-backport-for-1.0.patch
[10:29] <ojwb> I haven't commited that to the 1.0 branch yet
[10:30] <ojwb> that's the patch Enrico tested
[10:30] <mvo> ojwb: ok, thanks!
[10:30] <Keybuk> pitti: oh, it just does that by default
[10:30] <pitti> hmm
[10:31] <Keybuk> we want it on tty1 by default though, don't we? :)
[10:31] <pitti> well, sure, but we didn't do that switch yet, anywhere I could see?
[10:31] <Keybuk> I suspect new gdm simply behaves that way out of the box
[10:31] <Keybuk> anyway, I bet I can guess what causes the crash now
[10:31] <pitti> FirstVT=7
[10:31] <asac> StevenK: filed, assigned upstream to bfifller and packaging task to you. 396453
[10:31] <pitti> ^ in /etc/gdm/gdm.conf for me
[10:32] <pitti> Keybuk: do you have "1" there?
[10:32] <pitti> Hobbsee: ^
[10:32] <Keybuk> pitti: no, 7 - but that's the old gdm configuration file, no?
[10:32] <enrico> mvo: comments on my reply?
[10:32] <mvo> enrico: I'm just in the middle of writing it :)
[10:32] <pitti> Keybuk: current gdm still ships it, and settings like autologin still work
[10:33] <enrico> mvo: \o/
[10:33] <Keybuk> pitti: it doesn't mean it supports vt allocation, etc.
[10:34] <Keybuk> I expect what's causing that bug is
[10:34] <Keybuk> gdm is on tty1
[10:34] <pitti> so it could be the missing ConsoleKit patch in bug 375877
[10:34] <Keybuk> getty is on tty1
[10:34] <Hobbsee> pitti: 7 here too
[10:34] <pitti> Keybuk: so getty and gdm collide?
[10:34] <Keybuk> so getty will get random raw input as you type
[10:34] <Keybuk> which getty will interpret as a klingon trying to login
[10:34] <pitti> right, that'd explain the weird characters people saw
[10:34] <Keybuk> after a few minutes, it'll timeout that login and exit()
[10:34] <Keybuk> upstart will respawn getty on tty1
[10:34] <wgrant> Ahaha. That explains everything.
[10:35] <Hobbsee> that would do it
[10:35] <Keybuk> at which point getty will call TIOCSCTTY to claim ownership of the tty
[10:35] <Keybuk> and X will lose control of the tty
[10:35] <pitti> Keybuk: so we just need to drop the getty on vt1?
[10:35] <Keybuk> and shamelessly exit
[10:35] <Keybuk> pitti: my hunch is that if you reboot, and quickly "sudo stop tty1" - you won't get auto-logged out
[10:35] <mvo> enrico: be patient with me :) I want to try some of the code (like the different scan-the-database code) in order to figure out what performance charackteristis to expect
[10:36] <pitti> so I still wonder why gdm starts on vt7 for me right away
[10:36] <pitti> I'm using xorg-edgers, but this hardly sounds like something that X itself would do?
[10:36] <Keybuk> pitti: interestingly, AutoLogin is broken for me
[10:36] <Keybuk> I had auto-login enabled
[10:36] <Keybuk> but after upgrading to new gdm, it doesn't work anymore
[10:36] <mvo> enrico: but I really hope we can get something like "--quick-update" method that takes around the order of ~4s (on my system) so that ideally we could just run it after every apt-get update
[10:36] <mvo> (or at least daily)
[10:36] <pitti> Keybuk: try moving /etc/gdm/gdm.conf-custom to /etc/gdm/custom.conf ?
[10:37] <seb128_> pitti, how do you see where gdm is starting with autologin?
[10:37] <pitti> Keybuk: current package does that automatically, but if you had ubuntu[23] installed that migration was broken
[10:37] <Keybuk> pitti: how will that help?
[10:37] <Keybuk> the AutomaticLogin=scott is in /etc/gdm.conf for me
[10:37] <pitti> Keybuk: gdm reads custom.conf now, not gdm.conf-custom
[10:37] <seb128_> Keybuk, the autologin option is set there
[10:37] <pitti> seb128_: well, I do ctrl+alt+f1 -> VT with getty, ctrl+alt+f7 -> gdm
[10:38] <geser> Keybuk: auto-login still works for me with the new gdm
[10:38] <Keybuk> geser: how/where is it configured?
[10:38] <Keybuk> my /etc/gdm.conf has AutomaticLoginEnable=true \n AutomaticLogin=scott
[10:38] <Keybuk> and it doesn't
[10:39] <pitti> oh, it could be a race condition
[10:39] <seb128_> pitti, I've gdm on no vt with autologin it doesn't seem to keep a greeter after login
[10:39] <pitti> both gdm and getty are started on boot, and whichever gets there first gets it, I suppose
[10:39] <pitti> Keybuk: ^ would that work?
[10:39] <Keybuk> weirdly, I have TimedLoginEnable=true as well
[10:39] <geser> Keybuk: http://pastebin.ubuntu.com/211805/ that's my /etc/gdm/custom.conf
[10:39] <seb128_> my session is on vt7
[10:39] <Keybuk> geser: why is it in custom.conf not gdm.conf?
[10:39] <pitti> seb128_: right, but if nobody is logged in
[10:40] <pitti> Keybuk: because the new gdm sucks wrt. backwards compatibility :(
[10:40] <geser> Keybuk: I put it there (had it in gdm.conf-custom till now)
[10:40] <Keybuk> pitti: right, but I'm confused
[10:41] <Keybuk> there are THREE configuration files
[10:41] <geser> as I didn't want to change the gdm.conf
[10:41] <Keybuk> you're tell me to move it from config file A to B
[10:41] <Keybuk> and I'm saying my config is in config file C
[10:41] <Keybuk> not A or B :)
[10:41] <seb128_> Keybuk, we used to use gdm.conf-custom and pitti renamed to custom.conf now
[10:41] <Keybuk> which are both identically empty
[10:41] <seb128_> which is the upstream naming
[10:41] <pitti> Keybuk: gdm should really also read gdm.conf indeed
[10:41] <enrico> mvo: ok, I like that. Forcing it to be fast, and if anything would hint at too much work to do, just do nothing
[10:41] <Keybuk> seb128_: again, you're not listening
[10:41] <seb128_> Keybuk, gdm.conf is upstream default, custom.conf your user changes
[10:41] <Keybuk> my AutomaticLoginEnable=true is not in gdm.conf-custom *OR* custom.conf
[10:41] <Keybuk> it's in gdm.conf
[10:41] <Keybuk> I'm wondering why it's there
[10:42] <seb128_> because you did edit it at some point§?
[10:42] <pitti> Keybuk: you selected that in the installer?
[10:42] <Keybuk> pitti: yes
[10:42] <pitti> ubiquity used to set it in gdm.conf directly
[10:42] <seb128_> iz ubiquity bog
[10:42] <Keybuk> this was installed with "Automatic Login" checked in the installer
[10:42] <Keybuk> ah
[10:42] <Keybuk> now
[10:42] <Keybuk> could *this* be causing the problem?
[10:42] <Keybuk> has the config migration ended up with a mangled config file that gdm isn't reading anymore?
[10:42] <pitti> Keybuk: I suppose that's it; gdm is not reading these settings from gdm.conf
[10:42] <seb128_> it could
[10:42] <pitti> right, what I said above
[10:42] <Keybuk> and thus gdm isn't reading VTallocation=true
[10:43] <Keybuk> so this would explain both why autologin doesn't work
[10:43] <Keybuk> and why gdm is on tty1 ?
[10:43] <pitti> gdm.conf:FirstVT=7
[10:43] <pitti> gdm.conf:VTAllocation=true
[10:43] <pitti> but I have exactly the same here
[10:43] <Keybuk> pitti: yes, I have that
[10:43] <Keybuk> what I'm suggesting is that the gdm.conf changes have been mangled in such a way that gdm is refusing to read *the entire file*
[10:44] <pitti> d6e74831651b44a9fee800f3af7e2093  gdm.conf
[10:44] <Keybuk> yeah, my md5sum is different, obviously
[10:45] <pitti> argh
[10:45] <Keybuk> pitti: interestingly, gdm's package doesn't contain gdm.conf
[10:45] <pitti> dpkg -L is naughty
[10:45] <Keybuk> and lists it as obsolete
[10:45] <pitti> gdm does not *actually* ship gdm.conf any more
[10:45] <pitti> Keybuk: heh, snap
[10:45] <pitti> so it seems it only sees custom.conf
[10:45] <Keybuk> so that would be another problem ;)
[10:45] <pitti> and that the package update should auto-migrate the settings from gdm.conf to custom.conf
[10:46] <seb128__> gdm.conf should not have settings set
[10:46] <pitti> Keybuk: would you mind attaching your gdm.conf to a bug and assign it to me?
[10:46] <seb128__> gdmsetup always edited gdm.custom-conf
[10:46] <pitti> seb128__: right, but ubiquity set it there
[10:46] <Keybuk> seb128__: but the installer *didn't*
[10:46] <seb128__> hum, right
[10:46] <Keybuk> seb128__: and it seems that the important VTAllocation=true is being set in gdm.conf, and not used :p
[10:46] <pitti> I'll invent some crappy postinst seddery
[10:47] <pitti> (for autologin migration)
[10:47] <pitti> Keybuk: what does VTAllocation do?
[10:47] <Keybuk> pitti: makes gdm use VTs rather than /dev/console <g>
[10:47] <pitti> Keybuk: so we should set that by default in gdm itself?
[10:47] <pitti> Keybuk: but either way, we do want it on vt1
[10:48] <pitti> so should we just stop getty on vt1 by default?
[10:48] <Keybuk> we do, but not while a getty is there ;)
[10:48] <Keybuk> right
[10:48] <Keybuk> though that'll annoy server people
[10:48] <pitti> Keybuk: could init.d/gdm do "upstart fiddle stop vt1"?
[10:48] <pitti> (even if getty@vt1 is started later?)
[10:48] <pitti> phone, brb
[10:50] <Keybuk> pitti: no, it only works if tty1 is started first :-;
[10:50] <Keybuk> ok
[10:50] <Keybuk> so I removed my gdm.conf entirely
[10:50] <Keybuk> and I added the AutomaticLogin bits to custom.conf
[10:50] <Keybuk> and I get auto-login
[10:50] <Keybuk> and I'm still on tty1
[10:51] <Keybuk> now, I've stopped the getty on tty1
[10:51] <Keybuk> will see if I get a logout
[10:53] <tseliot> mpt__: ping
[10:53] <Keybuk> pitti: bug #396459
[10:56] <pitti> Keybuk: hm, gdm diverting /etc/event.d/tty1? (*shudder*)
[10:57] <cjwatson> seb128_: waz, not iz
[10:57] <cjwatson> oh, well, ubiquity hasn't had an upload since that change
[10:57] <cjwatson> so yay for bug paperwork I guess
[10:58] <a|wen> hey pitti. I have an SRU that looks like it got stuck/forgotten after verification, is that something you can take a look on? bug 362537
[10:58] <Keybuk> cjwatson: plus we can't exactly fix this in u6y's postinst ;)
[10:59] <Keybuk> pitti: move gdm to an upstart job, "stop on starting gdm" .. "start on stopping gdm" :)
[10:59] <cjwatson> Keybuk: indeed
[11:00] <pitti> Keybuk: ubiquity postinst> hm? the upgrade should be done by gdm.postinst, no?
[11:00] <Keybuk> pitti: exactly
[11:00] <Keybuk> pitti: thus my use of the word "can't" :p
[11:01] <pitti> Keybuk: and "starting gdm" can only be provided if gdm itself is an upstart job?
[11:02] <seb128> pitti, btw there is a new gpm tarball (not sure if you track GNOME ftp uploads)
[11:02] <pitti> seb128: chrisccoulson is on it
[11:02] <Keybuk> pitti: maybe
[11:04] <seb128> pitti, ok good
[11:04] <pitti> Keybuk: but if gdm starts first and does "stop tty1", and then rc2 finishes and triggers "start tty1"?
[11:05] <pitti> (i. e. exactly what seems to happen on your and Hobbsee's box?)
[11:06] <Keybuk> pitti: that's just a race
[11:07] <Keybuk> but yes, I think that trying to solve this is the wrong approach
[11:07] <Keybuk> instead gdm should stay on tty7
[11:07] <Keybuk> since it clearly respawns there
[11:07] <Keybuk> and we should only move it to tty1 when we can fix this problem properly
[11:09] <pitti> okay
[11:11] <SiDi> directhex: ping ?
[11:11] <directhex> pong
[11:50] <mr_pouit> is there a plan to split gnome-session as in unstable? (http://packages.debian.org/sid/gnome-session-bin)
[11:51] <mr_pouit> Otherwise Xubuntu (for example) will end up with GNOME in the sessions' list in gdm (but since gnome isn't installed, it'll probably confuse users at best...)
[11:52] <pitti> mr_pouit: no plan from our side, but if you guys need it, feel free
[11:52] <pitti> ah, seems that just needs a merge then
[11:56] <mr_pouit> pitti: ok, thanks, I'll try to propose a debdiff soon
[12:06] <pitti> a|wen: ah, because the changelog has an invalid refrence to LP
[12:10] <cody-somerville> Those Debian folks are clever cookies.
[12:20] <lool> pitti: "MIR" ? "[MIR]": what about using a tag "ubuntu-mir" or "mir"?
[12:20] <pitti> lool: I don't particularly mind, I just like titles to have a standard format
[12:20] <pitti> easier to search and spot in your bug list, etc.
[12:21] <pitti> lool: they are already at ~ubuntu-mir/+subscribedbugs
[12:22] <dpm> StevenK: can I assign bug 396492 to you?
[12:23] <lool> pitti: I prefer tags because it doesn't clutter the title and they seemed like the best tool to well tag the bugs but I'm good enough without [MIR] or tags in all cases  :)
[12:24] <pitti> lool: fine for me; please add tags if they help you
[12:58] <c_korn> after a kernel update in karmic there is this message that I should restart the computer now. however when I click restart then I am just logged out.
[13:04] <ogra> c_korn, one of the plenty bugs with new gdm ... just reboot at the gdm screen
[13:05] <c_korn> ok
[13:16] <chrisccoulson> heh. the restart issue is because the new gdm doesn't ship a /usr/bin/gdm-signal anymore, which update-notifier still tries to use, I think
[13:17] <chrisccoulson> not sure if anything replaces that
[13:18] <ogra> i dont think /usr/bin/gdm-signal was shipped in jaunty (it was in powermanagement-interface which was dropped pre jaunty)
[13:18] <ogra> i might be wrong though
[13:20] <asac> cody-somerville: thanks for the vpn fixed - merged.
[13:21] <cody-somerville> asac, I also fixed pptp and vpnc
[13:21] <asac> cody-somerville: i mistyped: s/fixed/fixes/
[13:21] <asac> :)
[13:21] <cody-somerville> :)
[13:21] <asac> _all_ merged
[13:29] <chrisccoulson> ogra - no, you're right
[13:29] <chrisccoulson> the issue is that update-notifier is still using the old GDM protocol
[13:29] <ogra> i thought it was ported to dbus in jaunty
[13:29] <chrisccoulson> update-notifier?
[13:30] <ogra> well, the reboot notifier
[13:30] <chrisccoulson> it doesn't seem like it uses dbus
[13:38] <cody-somerville> mvo, does update-manager no longer have a partial dist-upgrade process? It just lists new packages to be installed as updates?
[13:38] <mvo> cody-somerville: it still has this
[13:38] <cody-somerville> mvo, For me it just lists new packages to be installed as updates
[13:39] <cody-somerville> mvo, making it seem like they're already installed
[13:39] <mvo> cody-somerville: if there are no removals, then that is its default behaviour
[13:39] <cody-somerville> mvo, Is this new behaviour?
[13:39] <mvo> cody-somerville: oh, you want them to be clearly labeled as new?
[13:39] <mvo> cody-somerville: its the default for some time now, its required on a stable system for e.g. the kerel abi upgrades
[13:39] <cody-somerville> ah
[13:40] <cody-somerville> mvo, Well, it would be nice for it be clearly labelled as I was confused when it said I had updates for gnome-panel, metacity, gnome-session, etc.
[13:40] <cody-somerville> mvo, when in reality the new update to gdm wants those things installed
[13:41] <mvo> cody-somerville: right, makes sense
[13:52] <cjwatson> mvo: FWIW if you look back a few revisions in ubiquity you'll find the port to d-bus I did there
[14:00] <mvo> cjwatson: cool, thanks. I port update-notifier to it now
[14:00] <mvo> s/now/next/
[14:05] <c_korn> eh, firefox 3.5 is already in jaunty and karmic? why doesn't the firefox meta package depend on it, yet?
[14:06] <mvo> cody-somerville: hm, I wonder what the best way to present this to the user is - just appending " (New install)" after the package name, or a alternative background, or a new heading
[14:07] <cody-somerville> mvo, Since disabling one of the new packages or disabling the package that is pulling them in will disable the others, maybe the new packages should be indented under the package responsible for pulling in the new packages?
[14:09] <cody-somerville> mvo, and then you could use a slight background tint and note that this package is new and being pulled in by X in the Changes tab.
[14:09] <mvo> a interessting idea
[14:11] <StevenK> dpm: I guess so.
[14:12]  * mvo plays with it
[14:13] <StevenK> dpm: I took the webfav task
[14:13] <dpm> StevenK: thanks
[14:17] <mvo> cody-somerville: btw, what is the plan for xubuntu with gdm? wil it move too the new gdm too?
[14:18] <StevenK> asac: You'll review maximus today?
[14:19] <cody-somerville> mvo, We don't have much of a choice
[14:19] <cody-somerville> mvo, I'm hoping gnome-session will get split like it is in debian
[14:20] <mvo> cody-somerville: right, so I can rely on the presence of the dbus interface for the reboot action in update-notifier?
[14:20] <cody-somerville> mvo, Its provided by gnome-session or gdm?
[14:21] <mvo> cody-somerville: I think its gnome-session, but I'm not 100% positive
[14:25] <cody-somerville> mvo, I think its safe to rely on it
[14:30] <cjwatson> mvo: the one I used is provided by gnome-session
[14:33] <mvo> so far I kept the old way (without dbus) around for compatibility with xfce, but if that is using gnome-session too, then I can remove that code now
[14:44] <pitti> mvo: not really a guide, AFAIK, but the libgudev API is quite easy and obvious
[14:44] <pitti> mvo: http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/index.html is the API doc
[14:44] <pitti> mvo: I can also recommend reading some example patches which port hal to gudev
[14:45] <pitti> mvo: https://wiki.ubuntu.com/Halsectomy links to three for gvfs and one for network-manager
[14:45]  * pitti RTFS
[14:46] <pitti> mvo: so update-notifier.c just initializes the hal context, and src/hal.c works with it?
[14:47] <pitti> mvo: you can just drop the stuff in update-notifier.c; you need a different method to pass the UpgradeNotifier object to src/gudev.c, though
[14:49] <mvo> pitti: thanks for the links
[14:49] <pitti> mvo: basically, you need to write an on_uevent() handler which listens for "block" subsystem devices (connect the "uevent" signal of the GUdevClient object to your handler, see http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/GUdevClient.html#GUdevClient-uevent)
[14:49] <pitti> mvo: and in that device handler you check for ID_CDROM property
[14:50] <pitti> mvo: probably most of the code will just disappear, all the reconection/filtering stuff
[14:50] <pitti> hal_mainloop_integration, etc.
[14:50] <mvo> pitti: excellent, thanks
[14:51] <pitti> mvo: let me know if you have any questions, I'm happy to help out
[14:52] <pitti> mvo: http://bugzilla.gnome.org/attachment.cgi?id=137066&action=view has an on_uevent() handler which looks for audio CDs
[14:52]  * pitti hugs mvo for hal-slaughtering
[14:53]  * mvo hugs pitti for his help
[14:54] <pitti> mvo: I didn't check, but it might be easier to use gvfs instead of gudev? merely looking for data CDs is easy, but if you need file/fs operations like monut/umount, you might be better off with gvfs
[14:55] <mvo> pitti: I just need it to get hints on what kind of media got inserted to show the upgrade/addon CD available dialog
[14:55] <mvo> so all the mounting was done already at this point
[14:59] <pitti> mvo: right, what I meant is that gudev will tell you about new and changed devices, not when they get mounted/unmonuted
[14:59] <pitti> so u-m could pick up the device change event before gvfs can mount it
[15:00] <mvo> isee
[15:00] <pitti> that's why I meant that gvfs (or e. g. /usr/include/gnome-disk-utility/gdu/gdu-device.h) might be easier
[15:01] <pitti> mvo: I haven't used the gdu API myself
[15:02] <pitti> mvo: but e. g. /usr/include/gnome-disk-utility/gdu/gdu-pool.h defines a GduPool    *gdu_pool_new(), which has a device_added signal
[15:02] <pitti> and hal-like volume/drives
[15:02] <pitti> mvo: and then you can do all the volume operations in /usr/include/gnome-disk-utility/gdu/gdu-device.h
[15:03] <mvo> ok, thanks
[15:04]  * mvo pokes around in gdu-dev
[15:04] <geser> TheMuso: are you working on liblouis? I'd like to upload a fix to make liblouis-dev installable again (and while I'm at it also some fixes from your MIR)
[15:04] <cjwatson> mvo: oh, thinking of this, how do you think a dynamic equivalent of apt's current reliance on /cdrom might work? I'd love to not have to add that fstab entry in the installer any more
[15:05] <cjwatson> mvo: e.g. how evil would it be for apt's cdrom method to link against dbus? would you want that to be a separate helper instead?
[15:05] <cjwatson> I think for Debian at least it would need to be able to try a few different methods rather than just relying on DK-disks
[15:06] <mvo> cjwatson: I would prefer to have a seperate helper for now
[15:06] <cjwatson> mvo: if it's in the same package, of course, it wouldn't make a lot of difference :)
[15:06] <cjwatson> maybe it could dlopen dbus
[15:07] <pitti> well, it would merely link against libdbus
[15:07] <pitti> it doesn't need to depend on d-bus itself
[15:10] <mvo> having it optional would be really nice, I have a look
[15:11]  * mvo is almost finished with dropping libgnome from update-notifiers dependencies
[15:11] <higuita> Hi... i just check that the key in the pt.archive.ubuntu.com seens to be reporting as invalid, can anyone confirm if that is the correct key?
[15:13] <ogra> we still dont have a bzr branch for initramfs-tools, right ?
[15:14] <cjwatson> no
[15:14] <cjwatson> pitti: that's what I meant
[15:14] <ogra> thanks
[15:16] <NCommander> http://launchpadlibrarian.net/28640480/buildlog_ubuntu-karmic-armel.kdebase-workspace_4%3A4.2.95-0ubuntu2_FAILEDTOBUILD.txt.gz - anyone what could cause pkgstriptranslations to hang (or at least take so long that the build times out?)
[15:24] <brettalton> I'm editing a release timeline for Ubuntu on Wikipedia (http://en.wikipedia.org/wiki/Template:Timeline_Ubuntu_Linux)
[15:24] <brettalton> and I'm having trouble finding when the start development date of any release is.
[15:24] <brettalton> e.g. Development of Hardy Heron 8.04 started on YYYY/MM/DD
[15:24] <brettalton> The best resource I can find is: https://wiki.ubuntu.com/HardyReleaseSchedule but it doesn't give me an exact date
[15:24] <brettalton> Does anyone have a better resource I can use?
[15:25] <mido> Hi. I'm looking for the kernel config file of the Jaunty Install-CD kernel. Any idea where I could find it? It doesn't seem to be in the casper directory with all the other stuff.
[15:26] <asac> StevenK: what wm did UNR use before?
[15:26] <Ampelbein> brettalton: i think it's safe to assume that work on a specific release began on the day the toolchain was uploaded.
[15:26] <NCommander> mido, the live CD uses the same config as the normal kernel
[15:26] <brettalton> Ampelbein: exactly, do you know how I can find out those dates?
[15:26] <mido> NCommander: Ah! Thanks. I wasn't aware of that. This makes things easy for me...
[15:27] <NCommander> mido, (its the same kernel, just a different initramfs)
[15:27] <cjwatson> brettalton: well, depends what you mean by "work"
[15:27] <mido> Perfect.
[15:27] <Ampelbein> brettalton: it's on the page you mentioned for Hardy. Look at the "notes" field
[15:27] <cjwatson> brettalton: (I'm not being entirely facetious here, bear with me)
[15:28] <cjwatson> brettalton: for quite a few releases now, we've been working on the next release along since the very day the previous release happened
[15:28] <cjwatson> brettalton: in fact, toolchain preparation work usually starts earlier
[15:28] <ogra> pitti, is it ok with you if i just add the four lines to check for a chroot from start to restart in hal's initscript, or do you prefer a check_chroot() function ?
[15:28] <cjwatson> brettalton: we usually send a mail to ubuntu-devel-announce once the archive is open for developers in general to upload, so if that's what you mean, you should be able to mine the list archives for that information
[15:29] <cjwatson> but I'm not sure it's accurate to describe that as the starting development date - for that as worded, I'd just give the previous release date myself
[15:32] <pitti> ogra: OK for me, I don't particularly care
[15:32] <ogra> good, i'm lazy ... just copy paste it is then :)
[15:33] <brettalton> cjwatson: thank you. Sorry, the HardyReleaseSchedule was a mistake to give you, I meant to give you ones like Warty, Breezy, etc. I'm just trying to think of the best way to represent the beginning of development in a chart without making the dates up in my head. But I agree the release of one version constitutes the beginning of the next.
[15:35] <pitti> Keybuk: I just updated bug 396226; what would you recommend, should I add a hack to gdm to always forcibly start X on vt7? or should we change /etc/event.d/tty1 to not start if gdm or kdm are running? or fix getty to not allocate the VT if it is already taken by X?
[15:36] <pitti> Keybuk: (right now, gdm doesn't have any code for VT handling; it entirely relies on X to grab the next free one)
[15:36] <Keybuk> pitti: how would we detect whether gdm are running, etc.
[15:36] <Keybuk> it all worked when X started on tty7
[15:36] <pitti> pidof gdm-binary
[15:36] <Keybuk> so we should just fix that bit first as a short-term solution
[15:36] <Keybuk> and then look into better solutions
[15:37] <pitti> right, it's just quite intrusive, so I wanted to check if you see another option
[15:37] <Keybuk> pitti: that wouldn't cause the getty to *go away* if X was started on tty1
[15:37] <pitti> Keybuk: we don't need that
[15:37] <ogra> pitti, pushed
[15:37] <pitti> we need getty to fail if X is on vt1 already (ideally)
[15:37] <Keybuk> pitti: yes you do, it's when getty times out the login that it kills X
[15:37] <pitti> since getty starts later than X
[15:37] <Keybuk> no, it doesn't ;)
[15:37] <pitti> it does
[15:37] <Keybuk> if getty started later than X, then getty starting would kill X
[15:38] <Keybuk> so because X isn't getting killed before it even gets started, it must be actually starting after X
[15:38] <pitti> well, getty is started at the end of rc2.d/*, isn't it?
[15:38] <Keybuk> bear in mind that when X starts is not when gdm starts
[15:38] <enrico> mvo: I don't feel much about "full reindex of more than X changed"
[15:38] <cjwatson> brettalton: well, I was thinking of in practice as well as in a sort of constitutional sense :-) I'm usually one of those working on the next release more or less from the moment the last one's done ...
[15:39] <mvo> enrico: ok, I can just add a ~20% value in then or something
[15:39] <mvo> (or leave it out entirely, I don't really mind :)
[15:39] <cjwatson> brettalton: in earlier cycles we weren't quite so quick to get restarted, and usually had a few days of break, although even then I believe folks were working on initialising the new archive (I just wasn't involved in that stage back then)
[15:39] <Keybuk> pitti: I would much rather fix this properly later than implement some dirty gross hack now
[15:39] <enrico> mvo: I have't read your patch yet, but from reading the mail, I was thinking: what if with --quick we only update data that is tied to versions
[15:39] <Keybuk> that will only make my life harder when I actually try and fix it properly
[15:39] <enrico> mvo: and all the other data, we update it weekly
[15:39] <mvo> enrico: that sounds like a nice and simple way of doing it
[15:39] <enrico> mvo: therefore, with --quick we don't need to do that thresholding
[15:40] <enrico> mvo: also, for those packages whose version changed, we can still update the non-version-specific data
[15:40] <brettalton> cjwatson: well if you're curious to see what I was working on, here it is:
[15:40] <brettalton> cjwatson: previous chart: http://en.wikipedia.org/w/index.php?title=Template:Timeline_Ubuntu_Linux&oldid=298580025
[15:40] <brettalton> cjwatson: updated chart: http://en.wikipedia.org/w/index.php?title=Template:Timeline_Ubuntu_Linux&oldid=300800384
[15:40] <enrico> mvo: which, as a side effect, turns a --quick into a full update if the index is empty
[15:40] <pitti> Keybuk: right, that's what I'm discussing
[15:40] <pitti> Keybuk: I don't know how to tell X "don't use vt1"
[15:40] <Keybuk> pitti: so just revert whatever bit caused X to suddenly think tty1 was a good place to be
[15:40] <ogra> gah, cjwatson was faster than me with initramfs-tools ... /me redownloads the latest source and starts over
[15:40] <Keybuk> pitti: it's not X is it, it's gdm
[15:40] <pitti> Keybuk: that would mean to revert to gdm 2.20 :)
[15:40] <mvo> enrico: excellent, I think my patch pretty much implements this behaviour :) the switch just needs to be renamed from --update to --quick
[15:41] <pitti> Keybuk: the old gdm had lots and lots of code, including VT handling, and passing the vt to X
[15:41] <enrico> mvo: I'm happy to keep it to --update
[15:41] <pitti> Keybuk: the new one dropped all that and just relies on X autodetection
[15:41] <mvo> enrico: \o/
[15:41] <Keybuk> pitti: but X doesn't do any VT detection either
[15:41] <Keybuk> X just starts on whatever console it's given
[15:41] <pitti> Keybuk: I tried adding a chvt 7 to gdm's init script, and then it started on vt8
[15:42] <pitti> Keybuk: ok, I'll try to find a hack within gdm; just wanted to check whether you see an easier method; thanks!
[15:42] <cjwatson> brettalton: can we get it not called "Ubuntu Linux", since that isn't what the distribution is called? :)
[15:42] <Keybuk> pitti: all the easy methods involve disabling tty1 if gdm is installed ;)
[15:43] <cjwatson> brettalton: yours is certainly a lot closer to reality though
[15:43] <cjwatson> ogra: I uploaded that hours ago ...
[15:43] <pitti> Keybuk: are you sure about X not doing autodetection? If I start "X" on vt1 in a bash, it starts on vt9
[15:43] <Keybuk> pitti: I bet it it's something simple in X
[15:44] <Keybuk> like if you start X when the current tty has a framebuffer, it uses it
[15:44] <ogra> cjwatson, yes, i pulled the source this morning ... thats what you get if you get distracted by a ton of other stuff :)
[15:44] <Keybuk> otherwise it starts a new vt and then switches to that
[15:44] <pitti> Keybuk: so starting getty implies losing the fb?
[15:44] <ogra> ... and dont monitor -changes close enough
[15:44] <pitti> s/starting/having/
[15:44] <Keybuk> pitti: ?
[15:44] <pitti> Keybuk: well, all VTs have a KMSified fbcon
[15:45] <pitti> so I wonder what makes a VT different whether or not getty is running
[15:45] <brettalton> cjwatson: No problem, I just took it out now. The timeline was previous done by another user (who is Spanish I believe) and has had some problems translating. But I thank him very much for his work as he has created extensive timelines for almost all major distributions
[15:45] <pitti> since if it isn't running, apaprently X grabs vt1, otherwise vt7
[15:45] <Keybuk> pitti: entry in utmp?
[15:45] <pitti> and I think I need to understand this in order to figure out how to fix it
[15:46] <Keybuk> hmm
[15:47] <Keybuk> better question for you
[15:47] <Keybuk> why does X end up on vt7 after gdm respawns it ? :)
[15:47] <pitti> Keybuk: ah, ./hw/xfree86/os-support/linux/lnx_init.c, xf86OpenConsole() detects it
[15:47] <tgpraveen> can someone tell me whether delta debs are being worked on for karmic?
[15:47] <pitti> Keybuk: because then getty is running and "takes" the vt, AFAIUI
[15:47] <tgpraveen> it would be really useful to have and the sooner the more helpful to testers.
[15:47] <pitti> Keybuk: but after boot with usplash, getty isn't running yet when gdm/X start
[15:47] <Keybuk> pitti: getty doesn't really "take" anything
[15:47] <Keybuk> it does claim ownership of the console device
[15:47] <Keybuk> and that's what kills X
[15:48] <Keybuk> which is why I'm puzzled that it doesn't happen on boot
[15:48] <Keybuk> if it's because getty isn't running, then when getty starts, X will get killed
[15:48] <Keybuk> which is precisely what we see on timeout
[15:48] <cjwatson> brettalton: looks like he was (a) not counting beta->final as development (which has its merits as a viewpoint but was confusingly presented) (b) unclear on how much development we'd done before going public with warty ;-)
[15:49] <pitti> ok, if that's the case, then I have no explanation what maes the first getty different from the following one
[15:49] <cjwatson> tgpraveen: not deltas as such, but https://blueprints.launchpad.net/ubuntu/+spec/rsync-based-deb-downloads
[15:49] <pitti> Keybuk: I tries to open(ttyN, O_WRONLY) until it succeeds
[15:50] <pitti> Keybuk: meh, s/I/X/
[15:50] <pitti> so apparently "taking" a vt means that opening for writing fails
[15:50] <Keybuk> err
[15:50] <Keybuk> why would opening /dev/tty1 for writing fail?
[15:50] <pitti> crw------- 1 martin tty     4,  1 2009-07-07 16:43 /dev/tty1
[15:50] <pitti> crw--w---- 1 root tty 4, 9 2009-07-07 16:27 /dev/tty9
[15:51] <pitti> could have somethign to do with the missing tty write privs, not sure?
[15:51] <pitti> I'm just reading the code in X
[15:52] <brettalton> cjwatson: lol, very true. I'm a heavy editor of the Ubuntu Wikipedia page (at least the releases part) so I have many of these dates documented and even memorized (!)
[15:52] <pitti> Keybuk: but I rather suspect that you can just open it for writing once, and getty already did?
[15:52] <pitti> (since neither X nor gdm have a particular affiliation to the tty group)
[15:52] <Keybuk> I just set my tty to 666
[15:52] <Keybuk> X still went to 7
[15:52] <pitti> would be interesting to see the errno for that open()
[15:53] <brettalton> cjwatson: Here is the colour scheme that I copied: http://www.markshuttleworth.com/wp-content/uploads/2008/05/ubuntu-release-cycle.png... thank you sabdfl
[15:53] <enrico> mvo: mind if I remove the obsolete packages before doing the rest of the indexing? That should give Xapian a chance to reuse the disk space freed
[15:53] <brettalton> cjwatson: I was also the nerdy one who put 4.10 to 8.04 in a virtual machine to take consistent screenshots of the dektop + nautilus as seen here: http://en.wikipedia.org/wiki/List_of_Ubuntu_releases
[15:54] <Keybuk> pitti: oh
[15:54] <Keybuk> I see the code you're confusing
[15:54] <Keybuk> it's not opening all of the ttys
[15:54] <pitti> open("/dev/tty0", O_WRONLY)             = 7
[15:54] <Keybuk> it's opening all of the different names for the _current_ tty
[15:54] <pitti> open("/dev/vc/9", O_RDWR|O_NONBLOCK)    = -1 ENOENT (No such file or directory)
[15:54] <Keybuk> (/dev/tty0)
[15:54] <pitti> open("/dev/tty9", O_RDWR|O_NONBLOCK)    = 7
[15:54] <pitti> open("/proc/mtrr", O_WRONLY)            = 8
[15:54] <pitti> aah
[15:54] <Keybuk> and then it's doing a VT_OPENQRY on it
[15:55] <enrico> mvo: I like your patch a lot!
[15:55] <_lemsx1_> will the next release of Ubuntu support ksplice?
[15:55] <mvo> enrico: sure, please shuffle it around as you like (and what is best for xapian)
[15:55] <pitti> Keybuk: ok, so there are two methods AFAICS: either allocate the vt earlier (with getty) or supply a "vt" argument to X for the first time
[15:55] <mvo> enrico: thanks :)
[15:55] <Keybuk> pitti: do we run usplash on tty1 now?
[15:56] <pitti> Keybuk: should be on 8
[15:56] <pitti> not sure, though
[15:56] <pitti> Keybuk: nothign in usplash itself changed since jaunty, though (except KMS detection)
[15:57] <Keybuk> right, but why would VT_OPENQRY suddenly return 1 instead of 7
[15:57] <brettalton> cjwatson: Anyway, keep up the good work! I hope to join you once I'm done my CS degree :)
[15:57] <tgpraveen> cjwatson: thx for the link. what is the difference between delta debs and what this blueprint says?from the blueprint it seems they are both same
[15:57] <cjwatson> brettalton: cool :)
[15:57] <pitti> Keybuk: what does "start on stopped rc2" mean?
[15:58] <pitti> Keybuk: when all rc2.d/S* are done?
[15:58] <Keybuk> yes
[15:58] <cjwatson> tgpraveen: as I've heard them described, delta debs would require precomputing the difference to the current package in the archive from any of various different versions which the user might have installed
[15:58] <Keybuk> pitti: I think there's something else going on here still
[15:58] <pitti> Keybuk: sure, then getty just starts after gdm
[15:58] <Keybuk> my test program just returned 7 at the point gdm is started
[15:58] <Keybuk> not 1
[15:58] <cjwatson> tgpraveen: zsync is more flexible - it can, in principle, cope with any currently installed version, although of course the greater the difference the more it has to download
[15:58] <Keybuk> *something* is telling gdm or X to start on tty1
[15:58] <Keybuk> not 7
[15:59] <tgpraveen> cjwatson: ok.thx for clearing that up.
[15:59] <cjwatson> liw: ^- (just in case you want to chip in since you're the spec assignee)
[16:00] <liw> cjwatson, you're correct
[16:01] <Keybuk> pitti: either that or the definition of ownership of a console has changed
[16:01] <Keybuk> oh, wait
[16:01] <Keybuk> I was thinking "otherwise why didn't X get started on tty1 before?"
[16:01] <Keybuk> but it didn't get started there because gdm had lots of insane code to do the VT allocation for X
[16:01] <Keybuk> new gdm doesn't have that code
[16:01] <pitti> right, all of that went away
[16:01] <Keybuk> so it's new gdm making X start on vt1 by virtue of losing all the smarts
[16:01] <pitti> that's what I meant with "go back to 2.20"
[16:02] <pitti> we could pass a "vt7" argument to Xorg in gdm for the first time as a hack
[16:02] <Keybuk> and until getty creates it, there is no tty1
[16:03] <Keybuk> adding "start on runlevel 2" to /etc/event.d/tty1 makes X go to vt 7 :p
[16:03] <Keybuk> interestingly
[16:04] <pitti> finally believe me? :-)
[16:04] <pitti> anyway
[16:04] <Keybuk> it's not that I don't believe you
[16:04] <pitti> I wonder whether there's a way for getty to "see" X on vt1
[16:04] <pitti> and just exit
[16:04] <Keybuk> pitti: I was just thinking that
[16:04] <pitti> Keybuk: (just kidding, sorry)
[16:05] <Keybuk> and pulling up the getty source to see
[16:05] <Keybuk> I'm actually interested to why getty only sometimes kills X
[16:05] <Keybuk> if I start a getty on tty7 it doesn't
[16:05] <pitti> as a last resort I'll add a "vt7" to gdm's XOrg invocation the first time, but that's not a robust solution
[16:05] <pitti> Keybuk: getty just exiting, wouldn't that cause an eternal loop in the upstart event.d?
[16:06] <pitti> ("respawn")
[16:06] <Keybuk> pitti: it'd hit the respawn limiter
[16:06] <pitti> ah, nice
[16:06] <Keybuk> but we could just add a magic exit code to make that not respawn
[16:06] <Keybuk> exit (60) if the VT is in use
[16:07] <pitti> can you say "respawn until exit with 99" or so?
[16:07] <Keybuk> and put "normal exit 60" in the tty1 file
[16:07] <Keybuk> yes
[16:07] <pitti> cool
[16:07] <pitti> \o/
[16:07] <pitti> ♥ upstart :)
[16:07] <enrico> mvo: ok. The first --update run done in a system with an existing database will rebuild everything because there is no version information in the database
[16:07] <enrico> mvo: and it'll take all the time of a full rebuild
[16:07] <enrico> mvo: the subsequent updates, should be very fast indeed
[16:08] <Keybuk> I wonder what it is about getty that kills X
[16:09] <enrico> mvo: if you want to avoid this, I can change the code in "if there is no version info in the xapian db, consider it unchanged"
[16:09] <enrico> mvo: that way, the first --update will do nothing, until the weekly rebuild will rebuild with version info
[16:09] <enrico> mvo: from that moment on, --update will DTRT
[16:09] <enrico> mvo: which one do you prefer? Rebuild everything at first --update, or enable --update only after the first weekly rebuild?
[16:10] <mvo> enrico: I like rebuild everything on first update (slightly) better
[16:10] <enrico> mvo: ok
[16:12] <enrico> mvo: I found a way to speed up database read *considerably*. It's "only print progress every 5000 packages instead of every 200" :)
[16:12] <mvo> heh :)
[16:12] <mvo> really? excellent!
[16:13] <enrico> mvo: at least when using --verbose, and I didn't do timing, just my feeling
[16:13] <enrico> mvo: I'll tweak it for another bit, then I'll push it
[16:13] <mvo> enrico: great, thanks
[16:14] <enrico> mvo: any idea of speed improvements in using a set for 'unchanged' instead of a dict, and a list (or set) of docids for obsolete instead of a dict?
[16:15] <enrico> well, I should just test it
[16:17] <mvo> enrico: I guess its just very small, but measuring it makes sense - you can try the ExecutionTime object, so having "with ExecutionTime("building dict"): block-of-code
[16:18] <mvo> enrico: that will print how long this particular block ran (within the limits of the precision of time.time() of course :)
[16:19] <enrico> mvo: it's... SLOWER
[16:20] <mvo> enrico: that is ... suprising :)
[16:21] <enrico> mvo: it's very tiny differences, maybe it's just all under the tolerance of the measurement tools
[16:21] <enrico> mvo: I'm just testing with time ./testrun, because I only want to bother with measureable performance gains
[16:21]  * mvo nods
[16:22] <enrico> mvo: I prefer to have a function that returns 3 dicts than a function that returns a set a dict and a list, if there is no relevant difference in terms of performance
[16:22] <mvo> enrico: absolutely, the other would be confusing
[16:24] <mvo> pitti: gdu is a thing of beauty! src/hal.c             |  245 ++++++++------------------------------------------
[16:24] <pitti> mvo: :-)
[16:24] <enrico> mvo: gdu?
[16:24] <mvo> enrico: gnome-disk-utils
[16:24] <mvo> enrico: a new lib that replaces (parts of) hal
[16:24] <enrico> mvo: --update properly falls back to showing the progress of an existing full update run
[16:25] <enrico> mvo: I give up. I can't find anything else to improve on your patch, I'll just have to release it :)
[16:25] <pitti> mvo: hm, but with gdu instead of devkit-disks you probably need to write a KDE counterpart? or don't they use update-notifier any more?
[16:25] <mvo> enrico: haha - wonderful
[16:26] <mvo> pitti: they have something on their own in python now
[16:26] <pitti> ah
[16:27] <enrico> mvo: how do you plan to invoke it with --update? Be careful of #516728
[16:29] <mvo> enrico: initially it will replace the code in synaptic that tries to figure out when is a good time to run it. I will have to think a bit more how to integrate it into apt, but it should certainly be part of the daily apt cron job IMO (that is optional to the user to enable that or not)
[16:30] <enrico> mvo: right. It can be left out of apt and delegated to those package managers that use apt-xapian-index
[16:31] <enrico> mvo: also, since running --update does nothing if nothing has changed, package managers can just call that at startup or after every apt-get update
[16:31] <enrico> mvo: did you do anything like post-update apt hooks in the end?
[16:32] <enrico> mvo: I recall an idea of an experimental patch, but I don't recall if it went anythere
[16:33] <enrico> mvo: (btw, I pushed your patch and my small changes to collab-maint)
[16:48] <mvo> enrico: (sorry I was on the phone) - yeah, there is a post-update hook now in libapt (that is run after apt-get update)
[16:54] <enrico> mvo: is there documentation about it? I'd like to run a debtags thing on it
[16:54] <enrico> mvo: that extracts tags from packages
[16:55] <enrico> mvo: I don't know if it'd be worth running update-apt-xapian-index --update in it as well, with a hook that detects if it's in a chroot (but maybe it's still too slow at this stage)
[16:56] <enrico> mvo: I was also thinking: when downloading PDiffs, how hard would it be for apt to generate a list of package names/versions affected by the changes? It could be fed to debtags and apt-xapian-index to speed up incremental updates even more
[16:59] <dholbach> can I interested somebody in giving a Packaging Training session at 09th July, 12:00 UTC?
[17:02] <mvo> enrico: I have to look into that for the pdiffs (but dinner is calling)
[17:02] <enrico> mvo: if from pdiffs apt can generate a list of (pkg, version) for added and upgraded packages and (pkg, "") for deleted packages, update-apt-xapian-index can have an even quicker update that avoids doing a full scan of both the apt and the xapian databases
[17:02] <enrico> mvo: ok, guten apetit!
[17:02] <ion> I thought we weren’t going to use pdiffs because apt-sync would be so much better.
[17:26] <a|wen> pitti: yeah, managed to mess up that changelog entry a bit :/ ... but thx for taking care of it
[17:35] <gigabytes> hello
[17:35] <gigabytes> are there plans to port synaptic to policykit?
[17:35] <ion> There are plans to replace Synaptic AFAIU.
[17:35] <gigabytes> uh really?
[17:36] <ion> https://wiki.ubuntu.com/AppCenter
[17:36] <gigabytes> thanks
[17:36] <gigabytes> will it use polkit?
[17:37] <ion> That page answers your question. :-)
[17:40] <gigabytes> yes it is XD
[17:50] <kirkland> pitti: ping
[17:50] <kirkland> pitti: regarding https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/359447
[17:50] <kirkland> pitti: there's a package that's been in -proposed for a very long time
[17:50] <kirkland> pitti: there's one more patch that i need to add to the package, related to this problem
[17:51] <kirkland> pitti: actually, critical to solving this problem
[17:51] <kirkland> pitti: i'd like to upload that to -proposed, with the new patch
[17:52] <kirkland> pitti: can I go ahead and do that?  or should i wait for the previous upload to be migrated?  or propose a new sru?  or what?
[17:53] <pitti> kirkland: no, the first patch doesn't seem to have really solved it, so no point moving that first
[17:53] <pitti> kirkland: just upload a newer version to -proposed
[17:53] <pitti> kirkland: it's the same bug#, right?
[17:53] <kirkland> pitti: thanks
[17:53] <kirkland> pitti: yes
[17:53] <pitti> kirkland: if not, please build with -v<version in updates for final> to include the previous changelog, too
[17:53] <pitti> ok, should be fine then
[17:53] <kirkland> pitti: i have verification from users testing the package in the ppa
[17:53] <kirkland> pitti: so i'll push to proposed
[17:56] <Sarvatt> any way g-p-m can be made less chatty so as to not fill .xsession-errors with 10MB of spam every day? :D
[18:01] <pitti> Sarvatt: what does it say?
[18:01] <pitti> $ grep power .xsession-errors
[18:01] <pitti> Checking for non power of two support: present.
[18:02] <pitti> and that's from compiz startup, I think
[18:03] <Sarvatt> its filled with the output that you get running gnome-power-manager from the command line, i'll pastebin a portion of it
[18:03] <pitti> Sarvatt: I guess it's the same message over and over?
[18:03] <Sarvatt> http://pastebin.com/d86b87c3
[18:03] <Sarvatt> yeah
[18:04] <Sarvatt> 10MB worth for 22 hours uptime
[18:07] <pitti> WTH?
[18:08] <ogra> looks like lshal output over and over
[18:08] <Sarvatt> g-p-m eventually crashes with this same error ever since the switch to devicekit-power too
[18:08] <Sarvatt> (gnome-power-manager:3275): GLib-GObject-CRITICAL **: g_value_get_uint: assertion `G_VALUE_HOLDS_UINT (value)' failed
[18:08] <Sarvatt> (gnome-power-manager:3275): GLib-GObject-CRITICAL **: g_object_get: assertion `G_IS_OBJECT (object)' failed
[18:09] <ogra> that one i got too
[18:09] <ogra> but nt the noise you have
[18:09] <ogra> *not
[18:09] <Sarvatt> well its the same output i get running g-p-m in a terminal, just getting routed to .xsession-errors for some reason
[18:09] <pitti> Sarvatt: are you sure that you have gnome-power-manager 2.27.1-0ubuntu4?
[18:10] <Sarvatt> ahh pitti I'm really sorry, it could be my package messed up, I forgot I wasn't using the ubuntu one because I was testing newer versions to see if it was fixed
[18:10] <Sarvatt> 2.27.2-0ubuntu0sarvatt
[18:12] <pitti> ah
[18:12] <pitti> Sarvatt: you need a no-change rebuild against current devicekit-power
[18:12] <pitti> or use latest upstraem version, that should fix it as well
[18:17] <Sarvatt> indeed, it doesn't flood .xsession-errors with the ubuntu g-p-m, sorry again
[18:18] <tormod> ogra, the initramfs-tools upload was pretty broken, I guess you noticed when testing it?
[18:18] <ogra> tormod, ?
[18:19] <Sarvatt> (gnome-power-manager:3339): devkit-power-gobject-WARNING **: No 'lid-is-present' property errors now though
[18:19] <ogra> tormod, can you elaborate ?
[18:19] <tormod> ogra, the patch introduced a grep which 1) has no input 2) has a broken RE
[18:20] <ogra> meh, i relied on lool having tested it its a very old patch
[18:21] <tormod> ogra, there's a missing : in the last [] and probably a missing filename
[18:22] <cjwatson> that'll break all architectures then
[18:22] <ogra> works fine here
[18:22] <cjwatson> oh, if grub/lilo is installed then it'll return from the function before hitting it
[18:23] <ogra> right
[18:23] <cjwatson> will probably break in chroots without a bootloader, in that case
[18:23] <tormod> I have a bootloader and I get the error message: grep: Unmatched [ or [^
[18:24] <ogra> hmm, that code shouldnt be run for you
[18:24] <ogra> did you modify kernel-img.conf ?
[18:24] <tormod> no
[18:25] <ogra> it surely doesnt get run for me
[18:25] <ogra> i see the error though
[18:27]  * ogra fixes
[18:29] <tormod> ogra, the reason that I reach this code is that I have no grub executable
[18:29] <ogra> ah
[18:29] <ogra> colon and filename added, thanks a lot for the heads up
[18:30] <tormod> you're welcome. should I have a grub exe now that I use grub2?
[18:30] <ogra> well, i use grub2 here and the code isnt run
[18:31] <ogra> but i dont have any grub i can execute
[18:31] <tormod> did you upgrade from grub to grub2?
[18:31] <ogra> yes
[18:31] <ogra> did you freshly install ?
[18:31] <tormod> you have menu.lst left behind?
[18:31] <ogra> i think i wiped that manually at some point
[18:31]  * ogra checks
[18:31] <ogra> ah, no, still there
[18:32] <tormod> that's why you don't reach the code
[18:32] <ogra> yeah
[18:32] <ogra> i guess that needs updates for grub2
[18:33] <ogra> heh, someone really liked awk in the mbr_check() function
[18:33] <chrisccoulson> mr_pouit - just looking at bug 396657
[18:34] <chrisccoulson> i'm currently doing a gnome-session update, so i can do the split too
[18:35] <cjwatson> grub-pc indeed does not ship /sbin/grub
[18:35] <cjwatson> perhaps checking for /usr/sbin/update-grub would be appropriate
[18:37] <mr_pouit> chrisccoulson: ah, that would be better (I don't use GNOME), thanks. I've already some minimal changes in a bzr branch if you want them.
[18:37] <chrisccoulson> thanks, i can take a look at those
[18:38] <chrisccoulson> mr_pouit - so, the issue is that gnome-session currently pulls in things like gnome-settings daemon and gnome-panel is it?
[18:38] <chrisccoulson> (just so i fully understand)
[18:40] <mr_pouit> chrisccoulson: yeah, something like that, some testers reported that they had gnome instead of xfce on the isos
[18:41] <chrisccoulson> mr_pouit - i'll take a look at that then. i'd already taken a look at the debian split, but we've stopped syncing gnome-session with debian for now because they're introducing too many other wierd changes with it at the moment
[18:41] <chrisccoulson> but this split looks ok
[18:41] <mr_pouit> (probably because of a dependencies/recommends chain with gdm 2.26 & gnome-session)
[18:41] <mr_pouit> ok, thanks.
[18:42] <mr_pouit> chrisccoulson: I pushed to lp:~mrpouit/gnome-session/ubuntu-split-bin-scripts
[18:43] <chrisccoulson> thanks
[18:45] <ogra> cjwatson, well, lool had the idea to just rely on kernel-img.conf's postinst_hook entry directly and drop the whole if/then litany, it was pretty elegant but requireds discussion with debian-boot i guess
[18:45] <ogra> *requires
[18:46] <cjwatson> debian-boot doesn't maintain initramfs-tools, but sure
[18:46] <ogra> oh, i thought it did
[18:47] <cjwatson> the list name is historical - debian-kernel maintains initramfs-tools
[18:47] <cjwatson> debian-boot maintains the installer
[18:47] <ogra> ah
[18:47] <ogra> well, it was mentioned in the bug i puled the patch out
[18:48] <ogra> *pulled
[18:49] <Riddell> pitti: how come apport isn't enabled?
[18:50] <ogra> Riddell, not yet :)
[18:50] <Sarvatt> theres pretty huge differences between ubuntu's and debian's initramfs-tools
[18:51] <ogra> Sarvatt, well, we still pull from debian, just not everythin
[18:51] <ogra> g
[18:51] <Sarvatt> 0.92b is over a year old, they've had 17 releases since then
[18:51] <cjwatson> sure, we haven't merged in some time
[18:52] <cjwatson> largely because now it's a big hairball of a merge
[18:52]  * ogra must say he hasnt missed anything either 
[18:52] <cjwatson> I'm not too worried about it - we have some different goals
[18:53] <cjwatson> though obviously it'd be good to get merged up
[18:53] <ogra> indeed, would save lots of work
[18:53] <Sarvatt> http://git.debian.org/?p=kernel/initramfs-tools.git;a=commit;h=254a54d61d3e2c5463798fa29280c3d1d24c49bf
[18:53] <Sarvatt> ?
[18:54] <cjwatson> heh, yeah
[18:54] <ogra> thouh i suspect it will change a lot again with the boot speedup stuff
[18:54] <cjwatson> ogra: if you're fixing your upload, could you cherry-pick the above commit please?
[18:55] <ogra> my fix is already up, but i got it open in front of me ...
[18:55] <pitti> Riddell: so far it was still too early and shaky to do so; new versions get uploaded every day, fixing crashes, etc.
[18:55] <pitti> Riddell: so far the plan was to enable it for alpha-3; you want it earlier?
[18:55] <ogra> oh, i didnt even know about comand -v
[18:56] <Riddell> pitti: I just wondered what our policy was.  currrently we have some experimentalish KDE stuff that has bugs going upstream when they should come to us
[18:57] <Riddell> pitti: but this'll give me something to talk about in my GCDS session tomorrow :)
[18:58] <pitti> Riddell: we don't really have a policy so far, just "gut feelings"
[19:01] <ogra> uploaded
[19:04] <tormod> ogra, I think you meant "previous" and not "next" in the changelog :)
[19:05] <Sarvatt> the i915 fixes in debian's initramfs-tools would be nice to have, i've seen alot of bug reports from people just adding i915 to /etc/initramfs-tools/modules and it doesnt work with our version because it doesnt automatically load intel_agp before it
[19:05] <Sarvatt> but its not that big a deal now with how things are in karmic, was just an issue before
[19:07] <Sarvatt> oh theres an update to that commit i linked earlier
[19:07] <Sarvatt> http://git.debian.org/?p=kernel/initramfs-tools.git;a=blobdiff;f=update-initramfs;h=8c085a57eae76aa4f1f22c00fd9d29d903a907fb;hp=2eed8cb7d37285383d9c3807f8182bc037bd776b;hb=89257a84d0bfcd46d5514c65245b7b3f57f67ddf;hpb=ff34476ecd5de0da1104b13e6b42e6cc9eff8792
[19:07] <ogra> tormod, yes, i'm tired
[19:08] <ogra> tormod, i have quickly hidden it with another upload :)
[19:10] <Sarvatt> update-initramfs: Generating /boot/initrd.img-2.6.31-rc1-sarvatt
[19:10] <Sarvatt> dpkg: warning: obsolete option '--print-installation-architecture', please use '--print-architecture' instead.
[19:10] <Sarvatt> dpkg: warning: obsolete option '--print-installation-architecture', please use '--print-architecture' instead.
[19:13] <ogra> Sarvatt, wow, how do you get these warnings ?
[19:14] <ogra> (i see the code and have '--print-installation-architecture' here as well, but never get such warnings)
[19:15] <Sarvatt> probably related to the fact i'm using kernel-package 12.014 I guess
[19:16] <ogra> sounds rather like a newer dpkg
[19:16] <ogra> karmic has 1.14.24ubuntu2
[19:18] <Sarvatt> it started with initramfs-tools 0.92bubuntu35 that says something about checking kernel-img.conf thats part of kernel-package is why i was guessing that
[19:21] <Sarvatt> dpkg                                                 1.15.3ubuntu1?
[19:21] <tormod> dpkg --print-installation-architecture complains here also, 1.15.3ubuntu1
[19:22] <ogra> hmm, i didnt upgrade today, when did we get dpkg 1.15
[19:23] <Sarvatt> 15.2 and 15.3 both today
[19:23] <ogra> oh, i see, cjwatson was busy today
[19:25] <Sarvatt> wow now that is a _monster_ of a changelog
[19:25] <Sarvatt> on 15.2
[19:33] <superm1> bryce, hmm.  why is a karmic sbuild (on PPA) failing to setup xserver-xorg as a  build depend because of starting hal?  http://launchpadlibrarian.net/28771398/buildlog_ubuntu-karmic-amd64.mythtv_0.21.0%2Bfixes20810-0ubuntu0%2Bmythbuntu4_FAILEDTOBUILD.txt.gz
[19:33] <superm1> is hal really needed in the xserver-xorg postinst in the first place?
[19:34] <ogra> superm1, try with the new hal
[19:34] <ogra> i just uploaded a fix
[19:34] <superm1> ogra, ah well that was a PPA, so i'll just wait for the PPA to update I suppose
[19:35] <ogra> 0.5.12+git20090626-0ubuntu3 is what you want
[19:35] <bryce> aha
[19:40] <slytherin> can any of the archive admins please give preferential treatment to doxia-sitetools in new queue? I am waiting for it to fix some other maven related packages.
[19:46] <c_korn> can compiz related questions be asked here or is there a special channel?
[19:47] <slytherin> c_korn: is it about use of compiz?
[19:47] <c_korn> it is about a bug that can be fixed by changing the compiz settings. I don't know if the problem is with compiz, the apps or drivers.
[19:48] <c_korn> see this bug 384582
[19:48] <chrisccoulson> mr_pouit - how does the file-manager and panel start in xubuntu? the only reason i ask is because even with the gnome-session split, gnome-session will try and run gnome-panel, nautilus and metacity, because they are listed as required components in the default gconf settings. Obviously, they won't run if they aren't installed, but gnome-session will spit out a warning on each session start
[19:49] <Xhema> who can approve my translation queue here? https://translations.launchpad.net/shqipoffice/+imports
[19:51] <mr_pouit> chrisccoulson: they are started by xfce4-session
[19:52] <chrisccoulson> thanks:)
[19:52] <slytherin> c_korn: try asking on #compiz, check if it is a known problem.
[19:52] <chrisccoulson> i might download the xubuntu live CD and have a play around with it
[19:54] <c_korn> slytherin: ok, thanks
[19:55] <cjwatson> Sarvatt: our initramfs-tools should automatically load intel_agp and i915 all by itself
[20:21] <kees> pitti: \o/
[20:31] <ogra> cjwatson, given that i seem to have initramfs-tools day today, want me to change the two occurences of --print-installation-architecture to --print-architecture to quieten down the new dpkg ?
[20:32] <cjwatson> ogra: yes please
[20:32] <slangasek> bryce: I'm puzzled that xserver-xorg-input-all (and therefore xserver-xorg-input-synaptics) is no longer pulled in by default - is this intentional?
[20:33] <cjwatson> Xhema: maybe try #ubuntu-translators?
[20:33] <cjwatson> Xhema: or possibly #launchpad, not sure
[20:34] <cjwatson> Xhema: actually yeah, I'd think more likely #launchpad in the first instance, since it's not in the Ubuntu namespace
[20:34] <Xhema> thanks
[20:34] <Xhema> cjwatson, i am waiting now. i think it will take time
[20:34] <Xhema> but translators is a good idea
[20:35] <cjwatson> Xhema: you could also try https://answers.launchpad.net/rosetta if you don't get a quick answer on IRC
[20:35] <Xhema> i can wait
[20:35] <Xhema> it is ok
[20:35] <Xhema> we can also translate with po edit
[20:35] <Xhema> its ok!
[20:38] <bryce> slangasek, one sec
[20:40]  * ogra feels ignored on Bug #391094
[20:43] <mterry> cjwatson, evand, Heyo, I think the oem-config->ubiquity branch is pretty decent these days.  What's the best way to start reviewing it and testing it (beyond the testing I've done)?
[20:43] <tjaalton> slangasek, bryce: seems like a merge goof to me; xserver-xorg Depends on -evdev first, then -input-all | -input-5
[20:43] <tjaalton> make that -input-4
[20:43] <bryce> slangasek, I don't see a lot entry about it
[20:43] <tjaalton> so evdev satisfies the latter already
[20:44] <bryce> tjaalton, has the input version number changed?
[20:44] <tjaalton> bryce: no, but what I said :)
[20:44] <tjaalton> I'll poke jcristau
[20:44] <bryce> comparing current xorg to jaunty's, I don't spot a change here
[20:44] <bryce> tjaalton, thanks
[20:45] <evand> mterry: I can have a look over it tomorrow.  I imagine cjwatson will want to check it out as well before we merge it into trunk.
[20:45] <mterry> evand: for sure.  lots of changes
[20:45] <mterry> evand: it's lp:~mterry/ubiquity/oem-config-merge
[20:46] <evand> indeed, thanks.  Perhaps propose it for merging into trunk so we can have a recorded conversation of any further needed changes.  We haven't used that part of launchpad much in the past, but this would be a good opportunity to start.
[20:47] <mterry> evand: will do, good point
[20:47] <evand> great, thanks
[20:49] <cjwatson> mterry: I'll check it out and have a look, thanks
[20:54] <tjaalton> slangasek, bryce: a fix uploaded
[20:55] <bryce> sweet
[20:55] <mvo> cjwatson: I poked around a bit about the dynamic cdrom method for apt and it seems like libudev is the natural choice for this, I guess a addional dependency on this should not really hurt
[21:34] <slangasek> tjaalton: ah, cheers :)
[22:20] <kirkland> james_w: around?
[22:20] <james_w> aye
[22:20] <kirkland> james_w: would you mind proofreading this for me?
[22:20] <kirkland> http://pastebin.ubuntu.com/212258/
[22:21] <kirkland> james_w: i'm about to send that to kvm, qemu, and libvirt mailing lists, cc'ing ubuntu-devel
[22:23] <james_w> kirkland: looks good to me
[22:23] <kirkland> james_w: thanks
[22:23] <james_w> though you might want to tell them how to "point a user at it"
[22:23] <james_w> if there is a wiki page or something with instructions then it would be easy for them to pass the user on
[23:12] <billybigrig> hey all, is anyone alive?
[23:12] <billybigrig> i need to ask a question, brand new alpha 2 install today, and now im getting 1:06 boots, because of a hung devkit-disks-pa
[23:13] <billybigrig> i know this isn't the place for support but could someone give me a heads up on where to start troubleshooting? no one in +1 can seem to help out
[23:13] <billybigrig> http://imagebin.ca/view/aJcM-F.html
[23:13] <billybigrig> is my bootchart
[23:13] <billybigrig> i can't find anything pertaining to devkit-disks in my logs
[23:17] <Ampelbein> billybigrig: what version of devicekit-disks do you have installed?
[23:19] <billybigrig> apt-cache policy devkit-disks
[23:19] <billybigrig> can't find it
[23:19] <billybigrig> but devkit-disks --dump will output info, so i know its installed
[23:20] <Ampelbein> billybigrig: the package is named devicekit-disks. not devkit-disks.
[23:21] <billybigrig> devicekit-disks:
[23:21] <billybigrig>   Installed: 005-0ubuntu1
[23:21] <billybigrig>   Candidate: 005-0ubuntu1
[23:21] <billybigrig> thanks
[23:21] <ion> billybigrig: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/384579 perhaps
[23:22] <billybigrig> hmm
[23:22] <billybigrig> \blacklist floppy module i guess
[23:22] <billybigrig> :P
[23:22] <ion> Which computer is it, btw?
[23:22] <ion> A Thinkpad?
[23:23] <billybigrig> no
[23:23] <billybigrig> desktop
[23:25] <ion> If blacklisting the floppy driver helps, please report that (saying it’s not a Thinkpad) to the bug report, so it’s clear Thinkpads aren’t the only computers affected by it.
[23:25] <billybigrig> k
[23:25] <ion> Attaching /var/log/dmesg (when the floppy driver is not blacklisted) to the bug report would be nice as well.
[23:27] <billybigrig> added blacklist floppy to blacklist-floppy.conf and rmmod floppy
[23:27] <billybigrig> rebooted, still getting the slow boot
[23:27] <billybigrig> anyone care to take a look at my bootchart?
[23:29] <ion> Run update-initramfs -u, perhaps the initramfs still loads the floppy driver.
[23:36] <billybigrig> k lsmod doesn't show it
[23:36] <billybigrig> rebooting now
[23:41] <billybigrig> http://imagebin.ca/view/KnkS5il.html
[23:41] <billybigrig> 0:19
[23:41] <billybigrig> :)
[23:41] <billybigrig> :D