[00:11] <soren> Keybuk: Does your closing bug #372864 as fFix released mean that you added a getty for hvc0?
[00:13] <Keybuk> no, it means the upstart task is closed
[00:13] <soren> But..
[00:13] <soren> upstart also provides /etc/init/tty
[00:13] <soren> *.init?
[00:14] <Keybuk> I don't think upstart should provide a job for everything anyone can think of
[00:14] <Keybuk> if you want an hvc0 tty job, it should go in something else
[00:14] <soren> Um... I don't really see why, really.
[00:15] <cjwatson> d-i creates an hvc0 job if you're installing on that type of console (FWIW)
[00:15] <soren> I thought it was quite elegant that it could be shipped alongside the regular tty? things so that when run in an environment that has hvc0, it woudl dld Just Work.
[00:15] <Keybuk> because otherwise we end up shipping a job file for every single user's random wishlist
[00:15] <soren> cjwatson: Oh, really?
[00:15] <slangasek> Keybuk: hey, since you're around - how can I get an interactive shell out of an upstart job at boot time for debugging?  I'm sure I saw you telling people how to do this before in connection with mountall, but I can't figure it out now
[00:15] <cjwatson> soren: finish-install/finish-install.d/90console
[00:16] <Keybuk> slangasek: http://upstart.ubuntu.com/wiki/OMGBroken
[00:16] <slangasek> Keybuk: thanks!
[00:16] <cjwatson> soren: BTW I'm *so close* to getting vmbuilder working with grub2 ...
[00:16] <soren> cjwatson: Oh, your grub2 branch doesn't work?
[00:17] <cjwatson> that was a chroot-grub branch
[00:17] <cjwatson> it copes with grub2 in the host, but still installs grub in the guest. That much is fine
[00:17] <cjwatson> now I'm working on grub2 in the guest too
[00:17] <soren> cjwatson: Ah, ok. I didn't look at it yet, I just saw it trickle in.
[00:18] <cjwatson> chroot-grub is still worth merging, I think (indeed, I'm basing this grub2 branch on it)
[00:21] <soren> Keybuk: I really think shipping the hvc0 job by default is sensible, and I think your argument about "every user's random wishlist" is needlessly antagonistic. I'm waaaay too tired to argue about it now, though. Tomorrow, perhaps?
[00:21] <soren> cjwatson: Sure, sure, I'll look at it shortly. Tomorrow, hopefully.
[00:21]  * cjwatson nods
[00:24] <Keybuk> soren: it sounds like this is already solved
[00:24] <Keybuk> the installer creates that file
[00:25] <soren> Keybuk: If one uses the installer, yes.
[00:25] <cjwatson> I suspect soren is using vmbuilder or similar, which doesn't use installer code and would require reimplementation of the same ...
[00:26] <soren> Well, there's that, but also upgrades.
[00:26] <soren> Or virtual machines converted from physical ones.
[00:27] <soren> I really don't think it belongs in the installer now that we can actually trigger on the availability of the device in the upstart job itself.
[00:27] <slangasek> pitti, kenvandine: do you know whether gnome-power-manager does the equivalent of 'pm-powersave' at startup?
[00:27] <Keybuk> soren: I'm not saying you can't do this in an upstart job
[00:28] <Keybuk> I'm just saying the upstart package is the wrong place for it
[00:28] <Keybuk> just like we don't ship /etc/init/dbus.conf in the upstart package
[00:28] <soren> Keybuk: I realise.
[00:28] <soren> Keybuk: And I disagree.
[00:28] <ion> How about a xen-guest-stuff package that is strongly recommended to be installed on guests?
[00:29] <ion> update-manager could even install that when it notices it’s being run within a guest.
[00:29] <soren> I think that is silly.
[00:29] <soren> None of my VM's run update-manager (they're server VM's).
[00:30] <soren> ..and so far, we've managed just fine without such a package.
[00:30] <ion> % dpkg -S =do-release-upgrade
[00:30] <ion> update-manager-core: /usr/bin/do-release-upgrade
[00:30] <ion> That’s on a server.
[00:30] <soren> You hardly run do-release-upgrade regularly.
[00:30] <ion> Well, as regularly as you upgrade to a new release. :-P
[00:31] <soren> It's for doing full distro upgrades.
[00:31] <soren> That hardly counts as "when it notices it’s being run within a guest"
[00:31] <ion> When do-release-upgrade notices it’s being run within a guest
[00:31]  * soren sighs
[00:33] <Keybuk> soren: worth pointing out, I guess, that I plan to remove the tty* jobs from upstart too
[00:33] <Keybuk> they were only there because they came from sysvinit via inittab
[00:34] <soren> Keybuk: See, that's a good argument.
[00:34] <soren> Keybuk: Where would they go?
[00:34] <Keybuk> soren: into the package that ships getty
[00:34] <Keybuk> and it'll be just getty.conf
[00:34] <soren> Keybuk: Ok.
[00:35] <Keybuk> there's no reason for having the separate files at the moment
[00:35] <soren> I'm not insisting on putting hvc0 in the upstart package. I just think it belongs where the tty? jobs are, and that's been upstart for the last couple of years.
[00:36] <Keybuk> I don't think I agree with that
[00:36] <Keybuk> because I still don't think every single person wants getty trying to run on that device
[00:36] <soren> ?!?
[00:36] <soren> Why on earth not?
[00:36] <soren> That's what it's for?
[00:36] <soren> Well, that or a root prompt or something.
[00:37] <soren> ...but I didn't think that was really what was being discussed.
[00:37] <Keybuk> that's my point - I've seen a lot of argument that the console of a virtual machine should not be getty but sulogin directly
[00:37] <soren> That may be perfectly reasonable.
[00:37] <Keybuk> and I wouldn't want to ship upstart upstream with a fixed configuration that's not what everyone wants
[00:40] <Keybuk> RH have that neat /etc/consoles solution
[00:40] <Keybuk> start on tty-device-added
[00:40] <Keybuk> stop on tty-device-removed KERNEL=$KERNEL
[00:40] <Keybuk> instance $TTY
[00:40] <Keybuk> pre-start exec grep -w $TTY /etc/consoles
[00:40] <Keybuk> exec /sbin/getty $TTY 38400
[00:40] <Keybuk> ;-)
[00:42] <soren> Sorry, I'm having trouble following this discussion. I'm not sure whether we're discussing shipping an hvc0 job at all, shipping it in a binary package built by the upstart source package in Ubuntu, shipping it in the upstart upstream tarball, whether it will run a getty or sulogin, or perhaps something entirely different. I think I'm going to give up for today and pick it up again tomorrow :)
[00:43]  * soren calls it a day
[01:21] <mbiebl> slangasek: dk-power calls pm-powersave
[01:22] <mbiebl> and it's tied to the battery state
[01:45] <slangasek> mbiebl: ok; part of my problem figuring this out is that devkit-power is mispackaged, leading to gnome-power-manager being statically linked against libdevkit-power-gobject
[01:46] <slangasek> mbiebl: so will dk-power get called on gpm startup, or only on battery state chage?
[01:46] <slangasek> change
[01:48] <mbiebl> dk-power will be dbus autostarted  I guess by gdm's gpm instance
[01:48] <mbiebl> and whenever the battery state changes, dk-power will call pm-powersave true|false
[01:48] <arand> What is it that keeps changelogs lagging so much in publication? Why would they be anything but simultaneous to package publication?
[01:49] <mbiebl> afaik it's not g-p-m that triggers the pm-powersave call
[01:49] <mbiebl> slangasek: btw, what's the mispackaging in dk-power?
[01:50] <mbiebl> I don't see g-p-m being statically linked against libdevkit-power-gobject (at least on sid)
[01:50] <slangasek> mbiebl: -dev package has no dep on the shared lib package
[01:51] <mbiebl> slangasek: should have been fixed in 010-2
[01:52] <slangasek> mbiebl: so there's no guarantee that devkit-power will call pm-powersave on startup, to set an initial configuration?
[01:52] <slangasek> (I'm asking because I want to remove some more redundancy out of acpi-support)
[01:52] <mbiebl> to answer that definitely, I'd have to check the dk-power code
[01:53] <slangasek> mbiebl: 010-2> well, Ubuntu has 010+git20090913-0ubuntu1; I guess it jumped versions before 010-2 was out, so Ubuntu doesn't have the merge
[01:53] <mbiebl> pitti told me that he had merged that
[01:53] <slangasek> well, he hasn't :-)
[01:54] <mbiebl> next upload will be fixed then
[01:54] <slangasek> I'm fixing it in Ubuntu right now
[01:56] <mbiebl> slangasek: just checked
[01:56] <slangasek> mbiebl: it's called from dkp_daemon_startup, so I guess we're good :)
[01:56] <mbiebl> dk-power set's an initial state
[01:56] <slangasek> woohoo
[01:56] <mbiebl> yep
[01:59] <LLStarks> https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/443404
[02:00] <mbiebl> slangasek: I remember. 011 was supposed to be released today and we wanted to sync at this version again
[02:02] <slangasek> mbiebl: ok
[03:34] <dtchen> directhex: (RE: disabling pulse and using alsa-lib pcm.default) potentially racy. you'd want to actually disable autospawn and killall pulseaudio before trying that.
[03:35] <dtchen> superm1: (RE: libmyth/audiopulseutil.cpp) do you still need my input?
[03:35] <superm1> dtchen, well I think i came up with a solution actually.
[03:35] <ScottK> dtchen: Did you see my ping on wvstreams?
[03:35] <dtchen> ScottK: yes, i'm processing backscroll FIFO
[03:35] <ScottK> dtchen: OK.  Just wanted to make sure you saw it.
[03:36] <superm1> it seems that PULSE_INTERNAL needs to be set in the environment when pulseaudio is getting suspend otherwise ALSA:default still goes through pulseaudio
[03:37] <dtchen> superm1: yes, but that's still racy
[03:38] <superm1> dtchen, well there are AV sync issues if things are allowed to go through pulseaudio still
[03:38] <superm1> they're not immediately noticable, but with an hour recording w/ comm skip turned off, they turn up
[03:38] <ajmitch> dtchen: need me to test any more HP patches?
[03:38] <superm1> so this is the easier solution
[03:38] <superm1> (for now given time period)
[03:38] <dtchen> superm1: right. suboptimal, but nothing really resolving by late october.
[03:39] <dtchen> resolvable*
[03:39] <dtchen> ajmitch: soonish, hard to give an ETA right this moment
[03:39] <superm1> dtchen, it would be best if during lucid if upstream could try to help look over mythtv code to help recommend changes to fix these types of things for the next release though
[03:40] <ajmitch> dtchen: alright, ping me on irc if you need testing someday
[03:40] <dtchen> superm1: indeed
[03:40] <dtchen> ajmitch: sure thing
[04:45] <jono> Has anyone got a broken Network Manager?
[04:45] <jono> ahhh
[04:45] <jono> I see a new package
[04:46]  * jono dist-upgrades
[07:10] <dholbach> good morning
[07:17] <stooj> Morning Daniel
[07:40] <pitti> Good morning
[07:41] <pitti> free: sure
[07:41] <free> pitti: heya
[07:41] <pitti> slangasek: g-p-m> pm-powersave support was hacked into dk-power some months ago, so it's supposed to; it doesn't work any more?
[07:42] <slangasek> pitti: mbiebl_ has confirmed that it's there - I was asking the question because I wanted to be sure some broken code in acpi-support was truly redundant before hacking it out
[07:42] <pitti> ah, good; I read the rest of the scrollback
[07:43] <free> pitti: so should I include a SRU-compiant description in each bug involved in the SRU? (with rational, impact, etc.)
[07:43] <pitti> slangasek: so, shall I merge and fix the broken lib dep?
[07:43] <pitti> slangasek: dk-p 011 was supposed to be released yesterday, so I'd just update to the final version (just three changes compared to our git snapshot), and sync to sid
[07:44] <pitti> free: right, but please be very picky; this is intrepid, thus neither the current stable nor current LTS; it should get as few changes as possible
[07:44] <slangasek> pitti: well, I've uploaded devkit-power to fix it - if you have another reason to merge, go ahead, as long as you don't drop that fix :)
[07:44] <pitti> slangasek: no, I fixed that in Debian's git already
[07:45] <pitti> thanks
[07:45] <free> pitti: okay, I'm also going attach a stripped diff containing only the actual changes
[07:45] <free> pitti: because many of them were test code, which doesn't even end up in the packages
[07:45] <pitti> free: test code is fine
[07:46] <free> pitti: okay, I'll update the bugs you pointed out. Shall I update the description or attached a comment? or it's the same?
[07:46] <free> s/attached/attach/
[07:46] <pitti> free: description is preferred, but it doesn't matter so much
[07:47] <pitti> free: but please add proper Ubuntu tasks; so far the bugs just have upstream tasks which aren't even "fix released"
[07:47] <pitti> and it's not clear which fixes are in jaunty/karmic already, etc.
[07:47] <pitti> free: and as I said, the intrepid upload should backport three or so of the most important fixes, not a complete backport of a new version
[07:48] <free> pitti: so that means open new bugs affecting the relevant releases?
[07:48] <pitti> free: not new bugs; new tasks
[07:48] <free> pitti: okay
[07:48] <pitti> free: and please close the upstream tasks as appropriate
[07:48] <pitti> free: ideally for an SRU, the upstream and karmic ubuntu task need to be "fix released"
[07:49] <pitti> we don't put stuff into stables which hasn't even been tested in the latest karmic release yet
[07:49] <pitti> (landscape-client is the obvious exception, which has a standing "new version allowed" permission in the SRU policy)
[07:49] <free> pitti: so the thing that we specifically QA-ed this version we're proposing as SRU, the QA process was rather strict
[07:50] <free> pitti: so we'd rather prefer to see this smart package accepted, as the changes are bug-fix only, no new features
[07:50] <pitti> free: but with this many changes it's utterly hard to guarantee that there are no regressions for users of the current version
[07:50] <pitti> free: you also changed things like the .desktop file, which suddenly make a new menu entry appear for people who have it installed
[07:51] <free> pitti: I and Gustavo Niemeyer are possibly available to help reviewing each single change
[07:51] <free> pitti: okay, we can strip these user-visible things
[07:51] <pitti> free: why not just have a few targetted patches, like the jaunty upload?
[07:51] <pitti> that's so much safer
[07:52] <pitti> free: https://wiki.ubuntu.com/StableReleaseUpdates#It%27s%20just%20a%20one-line%20change!
[07:52] <pitti> and the "When" section below
[07:52] <free> pitti: because we QA-ed those changes already, and we would need to re-do it
[07:53] <free> pitti: also note that the landscape-client accepted in -proposed depend on that version of smart or above
[07:53] <free> pitti: so that would need to change as well
[07:54] <pitti> free: no, it doesn't
[07:54] <pitti> I reviewed the debian/control changes, and it doesn't bump any smart dependency?
[07:54] <pitti> oh, sorry, it does
[07:54] <pitti> yes, that needs to be fixed
[07:55] <free> pitti: yeah
[07:55] <hoonteke> I'm in the process of learning how to create and package .debs.  I'm using pbuilder right now, but running into some problems.  The tutorial I'm following appears to be borked in relationship to my setup.  I'm new enough to the process that I'm not sure what questions to ask or how to start diagnosing.  Is there a better tutorial than https://wiki.ubuntu.com/PbuilderHowto ?
[07:55] <pitti> free: oh, I see; the dependency even moved from one package to the other
[07:55] <hoonteke> (I'm getting stuck on the pdebuild step, which errors out with Make ..[127])
[07:56] <pitti> the new landscape-client is very intrusive, with conffile changes and everything; but it has a standing exception, so I didn't complain there
[07:56] <free> pitti: smart is a critical component of landscape-client
[07:56] <pitti> free: right, but it's not _only_ a component of landscape-client, other users might use it as well
[07:57] <pitti> sure, we don't support it officially, but that's not a reason for us to break it in stables
[07:58] <free> pitti: why break? we're pretty confident that the changes are sane, and they've been out and QA-ed since months
[07:58] <free> pitti: they are in jaunty and karmic already, except those two patches in the jaunty SRU
[07:59] <pitti> free: well, we have this strict "minimal changes" policy for a reason; we've been burned more than once already
[07:59] <free> pitti: http://lists.labix.org/pipermail/smart-labix.org/2009-March/003875.html
[07:59] <free> pitti: yes, I understand that
[08:00] <pitti> and half-a-megabyte diffs are far far away from "minimal changes to fix critical bugs only"
[08:00] <free> pitti: it's actually ~800 lines, if you consider only installed code
[08:01] <pitti> right, and most of the chagnes there are neither appropriate nor necessary for an SRU
[08:02] <free> pitti: okay, I'll try to limit it to the strict necessary, thanks for your feedback
[08:03] <pitti> free: I'm sorry that this caused redundant work; for future updates to stables, please just subscribe the SRU team to the relevant bugs right away, then we can discuss it beforehand and avoid that
[08:03] <free> pitti: good point
[08:50] <maxb> It's my subjective impression based on watching boot messages, that karmic seems to intermittently but often fail to properly unmount the root FS - the kernel always seems to be doing journal recovery on mount. Any thoughts on where I should file / look for a bug on this?
[09:05] <seb128> could somebody look at bug #444216 and see if they know what's going on?
[09:05] <seb128> there is thousand of "Use of uninitialized value $reply" debconf lines in the log
[09:05] <seb128> it seems that something is looping there
[09:15] <slangasek> seb128: hum, yes, killing the debconf frontend is a good way to make a debconf-based program loop :)
[09:16] <seb128> slangasek, do you know what package is responsive for displaying the dialog which confused the user there?
[09:16] <slangasek> pam
[09:16] <seb128> ok, let me reassign the bug there
[09:17] <seb128> the issue seems that the dialog was not clear to the user
[09:17] <seb128> slangasek, thanks
[09:17] <ogra> is gdm really supposed to be in this awful black and white theme now ? or is that just my system
[09:17] <seb128> design decision
[09:17] <slangasek> (the package that libpam-gnome-keyring calls in its postinst, of course :)
[09:17] <ogra> looks horrid :/
[09:18] <slangasek> seb128: well, I think that's more likely than there being a bug in pam-auth-update here, but I can't see how to make the dialog clearer
[09:18] <liw> ogra, I was assuming that was a bug, but didn't get around to reporting it yet... *sigh*
[09:20] <seb128> slangasek, I've not seen the dialog but the user said that one option need to be selected? In which case the dialog should have a widgets allowing to pick one option only rather than what is has now?
[09:20] <slangasek> seb128: no, *at least* one option must be selected
[09:20] <slangasek> it's a multiselect
[09:20] <slangasek> anyway, the user's already done something wrong to see this dialog at all
[09:21] <seb128> slangasek, the bug is confusing, "I selected them all, only to be informed that I need to select at least one."
[09:21] <slangasek> (setting debconf priority to medium or below)
[09:21] <seb128> that seems to be a bug at least
[09:21] <slangasek> I don't believe that's what actually happened, though :)
[09:21] <slangasek> I've tested this code rigorously
[09:21] <seb128> ok, so feel free to ask for details or close the bug as "don't close the debconf frontend in a brutal way" ;-)
[09:21] <slangasek> I think the submitter just wasn't paying close attention
[09:22] <slangasek> yep, will do
[09:22] <seb128> thanks
[09:57] <wgrant> pitti: If Soyuz was to reject binary uploads containing a ddeb without corresponding deb, would the world end? I guess no normal source should get into that situation, but I imagine that some stranger packages might...
[09:58] <pitti> wgrant: it really shouldn't happen (TM), though
[09:58] <pitti> even the handcrafted linux ddebs follow that naming schema
[09:59] <wgrant> It makes things much much simpler for everybody if we can reject those, but the consequences if the assumption proves untrue are... bad.
[10:08] <pitti> wgrant: I'd say, do it like this, at least for now
[10:08] <pitti> wgrant: in all the years when we have used ddebs this case didn't come up
[10:10] <wgrant> pitti: Wouldn't any extra ddebs enter the archive without question with the current setup?
[10:17] <mok0> Netsplit!
[10:17] <mikejones>        _
[10:17] <mikejones>  _ __ (_) __ _  __ _  ___ _ __ ___
[10:17] <mikejones> | '_ \| |/ _` |/ _` |/ _ \ '__/ __|
[10:17] <mikejones> | | | | | (_| | (_| |  __/ |  \__ \
[10:17] <mikejones> |_| |_|_|\__, |\__, |\___|_|  |___/
[10:17] <mikejones>          |___/ |___/
[10:18] <mok0> mikejones: keep the tone please
[10:19] <dholbach> thanks cjwatson - I tried but did not have enough power
[10:23]  * ogra hands dholbach a mars bar ... 
[10:23] <ogra> ... so you are prepared next time :)
[10:25] <pitti> wgrant: they would, yes
[10:27]  * mvo thinks ogra watches to much advertisement
[10:39] <free> pitti: how do I add intrepid/jaunty tasks to a bug, I can't figure it out from the LP UI
[10:39] <pitti> free: "Target to release", right below the yellow task table
[10:39] <cjwatson> you probably don't have the privilege to do so yourself
[10:39] <cjwatson> you can "nominate for release"
[10:39] <pitti> free: ^ I'll approve your nominations
[10:39] <free> okay thanks
[10:56] <pitti> does anyone have a firewire device here?
[11:00] <davmor2> pitti: meh sorry one thing I don't have
[11:20] <lifeless> ArneGoetje: around?
[11:21] <lifeless> if so, do you knowwhy https://translations.edge.launchpad.net/ubuntu/karmic/+source/xulrunner-1.9.1/+pots/xulrunner-1.9.1/la/1885/+translate and
[11:21] <lifeless> much of the rest of that pot, have english values listed as the translations?
[11:24] <lifeless> ArneGoetje: I'm asksing asking you because you are credited by LP
[11:58] <ArneGoetje> lifeless: The only reason I'm credited is because I uploaded the upstream translations and copied the other incomplete translations from xulrunner-1.9 over. I have no stakes in actually translating this language.
[11:59] <lifeless> ArneGoetje: so I think a mistake was made somewhere
[11:59] <lifeless> la is not english
[11:59] <lifeless> but there are very many strings marked as translated with the translated version being english
[12:00] <ArneGoetje> lifeless: I guess it's one of the incomplete translations and XPI format for strings that have no translations fall back to English
[12:01] <lifeless> ArneGoetje: _ugh_ - so we get it marked as translated?
[12:01] <ArneGoetje> lifeless: that's a requirement of XPI files. There needs to be a string there.
[12:02] <ArneGoetje> lifeless: bbl, need to go for lunch now.
[12:04] <lifeless> ArneGoetje: and we import from the xpi, with no change of importing fom upstreams translatio data?
[12:46] <mdz> ttx: if the post-start fails, that will log an error in syslog
[12:46] <mdz> ttx: are you seeing that error?
[12:46] <mdz> we could increase or remove the timeout if it is too short
[12:47] <ttx> mdz: yes
[12:47] <ttx> and it doesn't prevent registration from running.
[12:47] <ttx> it seems like the test we are using always fails, so increasing timeouts won't help :)
[12:47] <ttx> mdz: like I said, it's so strange I want another pass at testing
[12:48] <mdz> ttx: really? that test was succeeding for me
[12:48] <mdz> it's been modified since then, though
[12:49] <ttx> mdz: ithe CC test works. the SC/Walrus ones seem to fail. I want to confirm that on a pristine install though, I may have been hacking around that one for too long
[13:13] <ttx> mdz: filed bug 444504 about that
[13:23] <james_w> has anyone uploaded any maintainer script changes in the last 24 hours?
[13:24] <cjwatson> directhex: does the gettext build failure ring any bells with you? http://launchpadlibrarian.net/31807601/buildlog_ubuntu-karmic-i386.gettext_0.17-6ubuntu2_FAILEDTOBUILD.txt.gz
[13:25] <cjwatson> directhex: that was built a little while back, but I reproduced it on my laptop
[13:26] <directhex> cjwatson, i seem to recall removing support for it a while back - gettext's c# bindings barely function, and are for use with dotgnu (mono has much more robust bindings already)
[13:27] <directhex> it's far more work to make the bindings bundled with gettext actually properly buildable than to ignore them & write them off. and there are no rdeps
[13:31] <directhex> aha, thought so
[13:31] <directhex> i recognise this as i worked on it with sanvila@debian
[13:32] <directhex> 0.17-7 removed all mono stuff
[13:32] <seb128> hum, something seems to clear tmp on upgrades since today, anybody has a clue what change could do that?
[13:32] <directhex> and you're on 0.17-6ubuntu2, so...
[13:32] <cjwatson> directhex: ha, so the right answer is a merge. ok.
[13:33] <directhex> cjwatson, it might've been an easy fix. check the 0.17-7 diff
[13:34] <cjwatson> will do, thanks
[13:34] <cjwatson> just been trying to clear up a few build failures this morning
[13:41] <seb128> slangasek, those weird pam bugs could be also due to this tmp cleaning on upgrade issue
[13:41] <seb128> bug #444252 is gconf-schemas breaks due to that
[14:47] <kirkland> ttx: how's today's iso?
[14:47] <ttx> kirkland: not too bad :)
[14:48] <kirkland> ttx: :-)  i was hoping for some good news
[14:48]  * kirkland is tired of waking up to bad news every day
[14:48] <seb128> slangasek, bug #444252 for the record is probably something to track
[14:48] <seb128> it's collecting duplicates quickly
[14:48] <ttx> kirkland: actually it's surprisingly not too bad.
[14:49] <kirkland> ttx: :-)
[14:49] <kirkland> ttx: i'm very happy to hear that
[14:49] <ttx> kirkland: using a collection of unrelated bugs, autoregistration actually works
[14:49] <ttx> kirkland: see bug 444504
[14:49] <kirkland> ttx: now you're just getting picky!  :-)
[14:49] <kirkland> :-P
[14:51] <ttx> kirkland: i'm not really kidding. if we fix any of these bugs without fixing the others, autoregistration might fail :)
[14:51] <kirkland> ttx: funny enough, i believe you
[14:52] <ttx> kirkland: I committed a few fixes on the branch
[14:53] <ttx> kirkland: an update to rev913 should help us, though it's a confusing mutifix rev
[14:53] <ttx> kirkland: would you agree that is the upstart jobs post-start scripts fail to detect a working setup, then we should not try registration ?
[14:53] <kirkland> ttx: i agree
[14:54] <kirkland> ttx: as for "rev913"
[14:54] <kirkland> ttx: i don't think we should merge any more upstream
[14:54] <kirkland> ttx: i think we need to cherry pick whatever commit r913 is
[14:54] <ttx> kirkland: however if I fix that without fixing bug 443325, that would break autoregistration
[14:54] <kirkland> ttx: apply it in our branch, and release 0ubuntu2
[14:54] <kirkland> ttx: merging is a pain in the ass at this point
[14:55] <kirkland> ttx: see the mistake i made after i had merged 911, and then you asked me to merge 912, and I missed a step
[14:55] <ttx> r913 is several fixes unfortunately. With the usual blank space noops
[14:55] <ttx> so its quite confusing
[14:55] <kirkland> ttx: that's fine, it can still be cherry picked
[14:59] <ttx> The last one I encountered is bug 444352, some db deadlock on reboot
[15:00] <ttx> we'll need nurmi on that one as well.
[15:21] <Darxus> How do I do a kernel abi bump?
[15:22] <Darxus> For bug #424927.
[15:48] <mdz> cjwatson: thoughts on what the apport field name should be for bug 364649?
[15:48] <mdz> I was thinking UbuntuInstallationOrigin or UbuntuInstallationMedia or some such
[15:49] <Darxus> I believe I answered my abi question (in the bug).
[15:52] <cjwatson> mdz: prefer media over origina
[15:52] <cjwatson> -a
[15:52] <cjwatson> mdz: how about MediaInfo to match the file name?
[15:53] <cjwatson> or InstallationMediaInfo
[15:53] <cjwatson> I'd prefer not to have Ubuntu there, it's implicit in the fact that the bug is being reported from Ubuntu and it saves the usual questions about Kubuntu etc.
[15:54] <mdz> cjwatson: "info" seems redundant. how about InstallationMedia?
[15:54] <mdz> I think it's not obvious that that means "this is the installation medium which was used to install the system", hence the "origin" attempt
[15:57] <beuno> mdz, would "source" be too confusing?
[15:57] <Riddell> mvo: is hardy upgrade enabled in  the dist upgrade  tool?
[15:57] <cjwatson> InstallationMedia or InstallationMedium sounds fine. "source" already has an overloaded meaning here, namely an apt source
[15:58] <mdz> cjwatson: done, with InstallationMedia
[15:58] <mdz> beuno: yes, I agree with cjwatson that it would be
[15:59] <mdz> pitti: I've committed the trivial apport change to add InstallationMedia to Ubuntu bug reports; it is of course not critical for 9.10 but should be quite safe if you need to do another upload (and is tested)
[15:59] <cjwatson> (apport field names are developer-facing more than user-facing and so developer jargon such as "apt source" is relevant)
[15:59] <mvo> Riddell: should be, but not in the meta-release file
[15:59] <dotblankalt> hey guys when is /dev/shm mounted?
[16:00] <dotblankalt> cause its not in fstab
[16:00] <cjwatson> in karmic, mountall does t
[16:00] <dotblankalt> in 9.04 the asus touchpad acpi button broke and SHMClient is broken because of it
[16:00] <mdz> cjwatson: it does? its man page doesn't document that fact
[16:01] <dotblankalt> i fixed the touchpad button by using xinput instead but the latest update overwrote my changes to /etc/acpi/asus-touchpad.sh
[16:01] <Riddell> mvo: no meta-release doesn't need changed, we patch adept to look for karmic
[16:01] <cjwatson> dotblankalt: in 9.04, I believe it was the responsibility of /etc/init.d/mountdevsubfs.sh
[16:02] <lool> slangasek, Riddell, Hobbsee, pitti, mdz, Keybuk, cjwatson, kees, jdstrand, lool, pgraner, davidm, cody-somerville, jdong: Hi; we have a serious upgrade issue post-beta; LP #444252 it seems a package upgrade clears /tmp, potentially erasing open user data; there are a bunch of dups; is this escalation worthy?  seb128 and james_w know more about the bug
[16:02] <cjwatson> mdz: mountall? its manual page doesn't document very much as yet ;-)
[16:02] <cjwatson> ./src/mountall.c:218:   { "/dev/shm",                 NULL,        FALSE, "tmpfs",       "nosuid,nodev",                    NULL         },
[16:02] <cjwatson> ./src/mountall.c:231:   "/dev/shm",                     /* Built-in */
[16:03] <mvo> Riddell: ok, give it a go, but it should work. I added a auto-upgrade test profile for kubuntu and that looks ok too (also I did not do extensive testing, just looked if everything upgrades clearnly
[16:03] <kees> lool: yeah, seems serious to me.  mountall erases /tmp if it mounts it.
[16:03] <lool> I'm bumping the bug to critical
[16:04] <seb128> kees, oh, you know what is creating the issue?
[16:05] <cjwatson> mountall doesn't run on upgrade though does it?
[16:05] <kees> seb128: no, but I saw mountall mentioned just now
[16:05] <dotblankalt> ok
[16:06] <dotblankalt> well I just tested the asus-touchpad on an aspire one
[16:06] <dotblankalt> the button doesnt send any acpi events in acpi_listen
[16:06] <dotblankalt> but the touchpad is disabled
[16:06] <cjwatson> kees: the mountall discussion was independent, I thought
[16:07] <dotblankalt> In the g51vx and others when the touchpad event fires synclient fails
[16:07] <cjwatson> mountall clears /tmp at boot (with a grace period), but that's as intended. Clearing files from a running system on upgrade is quite a different matter ...
[16:07] <kees> cjwatson: ah, well, it also jumps to mind as something that clears /tmp, but... I don't think it has changed recently.
[16:07] <Pau_Gasol> juego de boxeo online http://www.kobox.org/kobox-fande-Nourine.html
[16:08] <dotblankalt> I think the aspire one got around by doing this at the bios level
[16:09] <dotblankalt> but alot of asus's touchpad buttons dont work in 9.04
[16:09] <kees> seb128: are they all evolution failures?  (working my way through the dups...)
[16:10] <kees> ah, no, ok
[16:11] <mdz> cjwatson: that bug where the cloud install used -generic instead of -server is fixed now, right?
[16:11] <cody-somerville> kees, the update-gconf-defaults might have been spawned by the evolution upgrade
[16:11] <cjwatson> mdz: yes
[16:11] <cody-somerville> oh wait
[16:12] <cody-somerville> theres a g-p-m bug in there too
[16:12] <cjwatson> mdz: I fixed it more or less on the spot during the last discussion
[16:12] <kees> cody-somerville: yeah, though it's not clear if the gpm is related?
[16:14] <rgreening> greg-g: ping
[16:15] <mvo> lool: re #444252 - if its a maintainer script, the list is pretty small of of possible candidate, see https://bugs.edge.launchpad.net/ubuntu/+bug/444252/comments/6
[16:15] <Keybuk> mvo: the one that calls shutil.rmtree() isn't a prime suspect? :)
[16:16] <jdong> LOL
[16:16] <kees> Keybuk: that's what I was looking at currently...
[16:17] <cjwatson> that only nukes a temporary directory created with tempfile.mkdtemp though
[16:17] <Keybuk> cjwatson: the traceback suggests it's failing partway through
[16:17] <Keybuk> ie. the directory existed when it started
[16:18] <Keybuk> no?
[16:18] <mvo> Keybuk: heh - seb128 said gconf-schemas has not changed in months
[16:18] <Keybuk> did shutil change?
[16:19] <Keybuk> just a thought
[16:19] <cjwatson> Keybuk: almost as if something's racing with it
[16:20] <Keybuk> cjwatson: possibly
[16:20] <Keybuk> or that it's screwed things up
[16:20] <mvo> its also odd because in one of the logs brasero is installed and that calls gconf-schemas too
[16:20] <Keybuk> is all of /tmp being wiped - or just that gconf directory?
[16:20] <seb128> I'm wondering if bug #444452 and bug #444216 are not similar issues
[16:20] <cjwatson> Keybuk: the traceback is basically right at the start of rmtree
[16:21] <james_w> Keybuk: if I'm seeing the same issue then it is all of /tmp
[16:21] <james_w> and perhaps /tmp itself, it's not clear
[16:21] <cjwatson> all it does before that is os.path.islink, really
[16:22] <Keybuk> fair enough
[16:24] <kees> Keybuk: (unrelated to /tmp issue) where is deadline vs cfq handled during boot?
[16:24] <kees> my system seems to be all deadline, but I was expecting cfq
[16:24] <Keybuk> kernel default
[16:24] <Keybuk> I believe they've changed it back to cfq again in -12
[16:25] <kees> do you know how long has it been deadline?
[16:25] <kees> Keybuk: ah, just -11
[16:25] <lool> mvo: Good point; I checked devicekit-power's, evolution's and dmraid's scripts and didn't see anything thouhg
[16:26] <cjwatson> devicekit-power seems like the kind of thing that might prod something asynchronouslsy
[16:26] <cjwatson> but it's really not clear ...
[16:27] <lool> Did someone confirm that the whole of /tmp gets cleared?
[16:27] <seb128> no
 james_w, you got tmp totally wiped, ie no directory there?
[16:28] <james_w> I don't know
  when I looked I had /tmp/orbit-jw2328
[16:28] <seb128> that's what we have from #ubuntu-desktop before
[16:28] <james_w> I went to open the bug report when seb was talking about it, and gnome-open told me that it couldn't talk to orbit
[16:28] <james_w> so I did "ls /tmp" and saw just that one path
[16:28] <lool> Ok so it might not be rm -rf /tmp after all
[16:29] <james_w> well something is removing at least most of /tmp, if not all of it
[16:29] <lool> james_w: No pulse-* keyring-* then
[16:29] <lool> james_w: Ok
[16:29] <james_w> my working assumption was that it created that path as it found that it didn't exist
[16:29] <lool> There was a python update at that time
[16:29] <lool>  -- Matthias Klose <doko@ubuntu.com>  Sun, 04 Oct 2009 21:28:36 +0200
[16:29] <lool> It could be that these are the first updates we're seeing with this new python
[16:29] <seb128> lool, we did start getting bugs only today though
[16:30] <lool> seb128: Yeah exactly
[16:30] <seb128> lool, I doubt it, we got lot of uploads yesterday
[16:30] <seb128> and probably lot of people who upgraded after weekend and got those
[16:30] <seb128> oh, you mean one upgrade to get the new python and one later to run into troubles?
[16:30] <seb128> hum...
[16:30] <lool> Yes
[16:30] <pitti> mdz: apport change> thanks; I'm certain I'll do another bug fix upload for karmic
[16:31] <james_w> the python diff doesn't look very suspicious to me
[16:34] <james_w> oh, there were two uploads
[16:34] <lool> I tried sudo apt-get install --reinstall brasero libdevkit-power-gobject1 devicekit-power  usplash evolution-common evolution
[16:34] <lool> Couldn't reproduce
[16:34] <lool> (usplash instead of dmraid to trigger an update-initramfs)
[16:35] <lool> Oh .tmp empty!
[16:35] <seb128> lool, what did you do?
[16:35] <bdrung_> Keybuk: what's the progress of the unit policy?
[16:36] <lool> Either that sudo did it, or installing dmraid did it
[16:36] <lool> sudo didn;t
[16:36] <mvo> lool: dmraid is something that is common in the reports
[16:36] <mvo>  the diff looks harmless
[16:36] <seb128> lool, you seem to be getting closer
[16:36] <lool> mvo: yes, I almost mentionned it
[16:36] <mvo> update-initramfs maybe?
[16:36] <Keybuk> bdrung_: deferred
[16:36] <lool> Just installing dmraid is enough to reproduce
[16:37] <bdrung_> Keybuk: i read that. when will you work on it?
[16:37] <Amaranth> Confirmed, installing dmraid wiped my /tmp
[16:37] <Amaranth> but the directory still exists
[16:37] <Keybuk> bdrung_: when I am not busy
[16:38] <bdrung_> Keybuk: newer? ;)
[16:38] <bdrung_> s/newer/never/
[16:39] <mvo> yeah, same here, but it seems to be happening when update-initramfs takes place
[16:39] <Amaranth> yeah
[16:39] <Keybuk> bdrung_: after the releas
[16:39] <bdrung_> Keybuk: k, thanks. let me know, when you work on it.
[16:39] <mvo> I see a trace of /tmp/mkinitfamfs-3432 and mkinitramfs_3234
[16:39] <mvo> and now its gone
[16:40] <Amaranth> but that was last changed on the 3rd
[16:40] <cjwatson> update-initramfs shouldn't be doing anything in parallel ...
[16:40] <ogra> tedg, hmm, am i supposed to see pidgin in my indicator applet even though i dont have it installed ?
[16:41] <mvo> I was doing things in parallel (installing and watching /tmp) :)
[16:41] <Amaranth> it's nice how things recover from /tmp going away :)
[16:41] <lool> It seems to be before update-initramfs
[16:41] <lool> At the time where this is run:
[16:41] <lool> + echo update-initramfs: Generating /boot/initrd.img-2.6.31-11-generic
[16:41] <lool> I already lost my /tmp
[16:42] <lool> perhaps at the very beginning of mkinitramfs
[16:42] <Amaranth> But it would have to be something else changing
[16:43] <Amaranth> Because the update of initramfs-tools would have called update-initramfs and wiped everything on the 3rd
[16:43] <tedg> ogra, no, but the chances are you installed while there was a bug that it didn't uninstall.  The bug if fixed, but that doesn't help :)
[16:43] <tedg> ogra, you can just rm -rf /etc/indicators/
[16:43] <kees> hrm.  in a chroot, installing dmraid did not wipe my /tmp
[16:44] <kees> Amaranth, lool: did anything else install with dmraid when you installed it?
[16:44] <Amaranth> just the library
[16:44]  * kees boots a VM
[16:44] <Amaranth> libdmraid1.0.0.rc15
[16:44] <lool> kees: libdmraid
[16:44] <ogra> tedg, ok, i'll watch it
[16:45]  * Amaranth is wondering the sanity of testing this on his actual system now
[16:45] <mvo> for me its gone around the time when udevadm trigger --subsystem-match=block --action=change is called
[16:45] <mvo> (so right after update-initramfs -u)
[16:46] <mvo> ok, so udevadm trigger and tmp is empty
[16:46] <james_w> hmm
[16:47] <lool> mvo: You confirmed that command kills it?
[16:47] <james_w> on a "sudo strace -f aptitude reinstall dmraid"
[16:47] <Amaranth> Confirmed
[16:47] <mvo> udevadm trigger --subsystem-match=block --action=change
[16:47] <james_w> I see /tmp go and then mkinitramfs stuff
[16:47] <kees> Keybuk: how/when does mountall run?
[16:47] <Amaranth> `sudo udevadm trigger --subsystem-match=block --action=change` and my /tmp is empty again
[16:47] <james_w> that's before that
[16:48] <Amaranth> james_w: it's asynchronous, I think
[16:48] <cjwatson> I was under the impression that any use of udevadm trigger on a live system had been quite clearly announced as a bug
[16:48] <lool> Amaranth: here too
[16:48] <james_w> Amaranth: update-initramfs is?
[16:48] <Amaranth> james_w: no, the other call
[16:48] <Keybuk> kees: on boot
[16:49] <Keybuk> cjwatson: indeed
[16:49] <james_w> Amaranth: yes, but update-initramfs runs first
[16:49] <cjwatson> as in, this is exactly the sort of thing you should expect to happen when you run udevadm trigger
[16:49] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2009-January/027260.html
[16:49] <james_w> and presumably that is the bit that puts the mkinitramfs dirs in /tmp
[16:49] <kees> Keybuk: ok, just verifying.
[16:49] <cjwatson> mind you
[16:49] <cjwatson> that says "change is completely safe"
[16:49] <cjwatson> while Amaranth says that udevadm trigger --subsystem-match=block --action=change breaks his world
[16:50] <Keybuk> cjwatson: ...except for block devices ;)
[16:50] <Keybuk> well, except for *RAID* block devices and stuff
[16:50] <cjwatson> Keybuk: ... on a Tuesday
[16:50] <mvo> mine too
[16:50] <lool> cjwatson: hahaha
[16:50] <Keybuk> precisely
[16:50] <lool> openoffice!
[16:50] <Keybuk> in general anything other than udev calling udevadm trigger is bad
[16:50] <lool> mvo: packagekit!
[16:50] <cjwatson> ok, so what's calling it?
[16:50] <lool> cjwatson: dmraid postinst
[16:51] <lool>     # Activate existing arrays now.
[16:51] <lool>     udevadm trigger --subsystem-match=block --action=change
[16:51] <Keybuk> (though there's definitely a mountall bug that it wipes /tmp more than once <g>)
[16:51] <lool> Keybuk: what can we use instead?
[16:51] <cjwatson> so dmraid is in the category of "I've installed udev rules and want udev to do something about it"
[16:51] <Keybuk> it's probably "right"
[16:51] <kees> yeah, isn't this the correct invocation, according to the ubuntu-devel email?
[16:51] <Keybuk> but something's always going to blow up
[16:52] <Amaranth> But dmraid also hasn't been updated for some time
[16:52] <Keybuk> there isn't a correct solution to this
[16:52] <Keybuk> unfortunately the real answer is probably "reboot" right nwo
[16:52] <lool> So we should drop the call and add a reboot required touch?
[16:52] <lool> actually update-initramfs probably does that anyway
[16:52] <cjwatson> mm, surely if you're upgrading dmraid you either have your arrays working about as well as you might expect, or will be content to reboot
[16:52] <cjwatson> I don't know that a reboot is always required, only if your arrays aren't there
[16:53] <cjwatson> but that's a recovery-type operation anyway
[16:53] <ogra> update-initramfs definately doesnt ... that would be horrid :)
[16:53] <Keybuk> why not just run whatever it is the udev rules run?
[16:53]  * kees cringes at "reboot" being a solution to anything on a linux system
[16:53] <Keybuk> if dmraid is trying to activate raid devices, isn't there just a dmraid --scan type thing?
[16:54] <ogra> kees, you are so old school :)
[16:54] <kees> :)
[16:54] <cjwatson> dmraid-activate %k, apparently
[16:54] <cjwatson> SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_TYPE}=="disk", ENV{ID_FS_USAGE}=="raid", KERNEL=="hd[a-z]|sd[a-z]", \
[16:54] <cjwatson>         RUN+="/sbin/dmraid-activate %k"
[16:54] <kees> this seems a bit off-topic.  what is _wiping_ /tmp as a result of --action=change ?
[16:54] <Keybuk> kees: mountall probably ;)
[16:55] <kees> Keybuk: so it's not just at boot, then?
[16:55] <cjwatson> or there's dmraid -ay
[16:55] <Keybuk> since that WHEEE EVERYTHING CHANGED! also happened to tell mountall that you changed the root filesystem ;)
[16:55] <kees> so mountall should not wipe /tmp if it's already mounted...
[16:55] <Keybuk> kees: not sure why it didn't go away
[16:55] <Keybuk> but sometimes it hangs around if there's something in fstab it wants to mount but can't yet
[16:55] <Keybuk> probably your dmraid devices, ironically
[16:55] <Amaranth> None of these packages have been updated recently though
[16:56] <Amaranth> mountall, udev, dmraid, etc
[16:56] <kees> it could just be people doing the beta install.
[16:56] <Keybuk> kees: yeah I said that above
[16:56] <Amaranth> So why did it start blowing up now?
[16:56] <lool> cjwatson: I could run that I guess
[16:56] <james_w> Amaranth: dmraid was uploaded yesterday
[16:56] <james_w> Amaranth: about 2 hours before the bugs started showing up
[16:56] <Amaranth> hrm, mine says september
[16:56] <cjwatson> dmraid -ay sort of concerns me, though. isw arrays have special handling in dmraid-actvate
[16:57] <james_w> this morning I mean
[16:57] <cjwatson> honestly, I think it would be safer just not to do anything in the postinst
[16:57] <kees> Keybuk: ah, ok.  so, bug in mountall, then?  doesn't sound like we need to change dmraid?
[16:57] <lool> cjwatson: is -a for all or for activate?
[16:57] <Amaranth> oh, the changelog is out of date (aptitude changelog)
[16:57] <cjwatson> lool: activate
[16:57] <lool> Ok no -activate man page
[16:57] <lool> no --help
[16:57] <cjwatson> lool: but as stated I'm not convinced that it's the right answer
[16:57] <ogra>   * debian/dmraid-activate: Remove the special-casing of the root
[16:57] <ogra>     device which breaks in many situations and leaves the raw devices
[16:57] <ogra>     exposed.
[16:57] <ogra> very suspicious
[16:57] <lool> cjwatson: Ok to upload a dmraid commenting out the udevadm call?
[16:57] <lool> I have that ready here as a stopgap
[16:58] <cjwatson> lool: it's fine by me, I think it would be by and large safe
[16:58] <cjwatson> needs a comment though!
[16:58] <kees> uhm, is the ubuntu-devel email incorrect then?  we're removing functionality from dmraid due to a mountall bug?
[16:58] <Darxus> dch -i doesn't work in the linux-image packages because debian/changelog is overwritten by debian.master/changelog.  Is there a reason I shouldn't file a bug about that?
[16:59] <Amaranth> Darxus: Because it's expected?
[16:59] <lool> cjwatson: Of course
[16:59] <kees> Darxus: should not file a bug because that source package is not designed to work with dch
[16:59] <lool> http://paste.ubuntu.com/287086/ what I uploaded
[16:59] <sistpoty|work> Darxus: use -c debian.master/changelog as dch argument
[16:59] <cjwatson> kees: is this functionality that is ever needed? enabling arrays on package upgrade?
[16:59] <cjwatson> seems kind of bizarre to me
[17:00] <kees> cjwatson: on _upgrade_ no, but install, yes?
[17:00] <Darxus> Where is that behavior in the linux image packages documented?
[17:00] <cjwatson> even that seems kind of odd to me
[17:00] <lool> cjwatson: Do you think this bug is worth an incident writeup?  we closed the bug in roughly one hour, so I'm not sure whether it needs it
[17:00] <kees> cjwatson: why? you've installed the software to handle a device; I would expect the devices to appear.
[17:00] <cjwatson> although fixing dmraid to do this only on fresh install seems to me as if it would fix this bug
[17:01] <cjwatson> oh, no, not quite
[17:01] <kees> the bug is mountall's... it should not clear a mounted /tmp.
[17:01] <cjwatson> lool: I don't think it needs it, personally
[17:01] <lool> kees: That's my feeling as well
[17:01] <Amaranth> So add an also affects for mountall to keep track of it
[17:01] <cjwatson> kees: right, but udevadm trigger is historically a painful thing to call and we *should* be avoiding it wherever possible
[17:01] <lool> slangasek, Riddell, Hobbsee, pitti, mdz, Keybuk, cjwatson, kees, jdstrand, lool, pgraner, davidm, cody-somerville, jdong: incident closed, bug fix uploaded
[17:02] <seb128> lool, thanks
[17:02] <pitti> lool: merci
[17:02] <Keybuk> lool: "incident"  we're pre-release?
[17:02] <kees> cjwatson: should a follow-up to the ubuntu-devel email be sent then?  it seems like dmraid qualifies as a caller of trigger.
[17:02] <Keybuk> ie. _still_in_development_
[17:03] <kees> Amaranth: yeah, I would say the dmraid "fix" should be reverted once mountall is fixed.
[17:03] <Darxus> Can I file a bug for dchi needing a -c argument being undocumented?
[17:03] <pitti> lots of more innocent people testing beta now, though
[17:03] <Keybuk> so?
[17:03] <cjwatson> kees: up to Keybuk, I'm not all that familiar with the innards
[17:03] <Keybuk> kees: I'd say that any use of udevadm trigger is a bug
[17:03] <Keybuk> and should be removed wherever possible
[17:04] <kees> Keybuk: I'm not in a position to debate that; but having mountall wipe /tmp after it's in use is a bug regardless.  :)
[17:04] <Keybuk> it's always going to have unwanted side-effects
[17:04] <Keybuk> because you're in effect saying "go do whatever you want, have fun!"
[17:04] <Keybuk> extreme case
[17:04] <Keybuk> udevadm trigger could result in a reboot ;)
[17:04] <kees> Keybuk: if the trigger thing is always a bug, then a follow-up to the email describing when/how to use it should be made.
[17:05] <Keybuk> udevadm trigger -> block device now available that's listed in fstab -> fsck runs -> fsck indicates filesystem was repaired and reboot required -> reboot
[17:05] <kees> email says, e.g. ""change" is completely safe."
[17:05] <Keybuk> kees: the e-mail is out of date
[17:05] <Keybuk> we do more as a result of udev events now
[17:05] <kees> :P
[17:05] <Keybuk> feel free to follow up
[17:06] <kees> I would except I don't know what's "current".  :)
[17:06] <Keybuk> there's zero point in e-mailing anyway
[17:06] <Keybuk> nobody reads them
[17:06] <kees> Well, I do.  :P
[17:06] <Darxus> Is debian/README.source the right place to document the need for a -c argument to dch ?
[17:06] <Keybuk> or they argue the toss when they're caught ignoring them
[17:06] <kees> Darxus: that's probably the best, yes.
[17:06] <smoser> can someone with commit access please revert slangasek's commit at http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.karmic/revision/1581 ? the changes required in kernel are available now.
[17:06] <Darxus> kees: Thanks.
[17:07] <kees> Keybuk: how do I find out what mountall is waiting on?
[17:08] <Keybuk> kees: gdb
[17:08] <kees> Keybuk: would you normally expect mountall to exit soon after boot on a "normal" system?
[17:09] <Keybuk> yes
[17:09] <cjwatson> smoser: done
[17:09] <Keybuk> though, admittedly, it doesn't for me here <g>
[17:09] <Keybuk> probably a bug
[17:09] <kees> yeah, me either
[17:09] <smoser> thank you cjwatson
[17:10] <cjwatson> mountall's still running here too, I don't have anything much complex
[17:10] <cjwatson> ... oh, apart from those NFS mounts
[17:10] <ogra> mountall --daemon --tmptime=0
[17:10] <ogra> here as well
[17:10] <kees> I have a VM with /, /proc, and swap in fstab and it's running.  ;)
[17:10] <ogra> what does --daemon mean
[17:10] <ogra> i dont have anything apart from / and /home here
[17:11] <cjwatson> ogra: I think you should probably read the source
[17:11] <Keybuk> ogra: a daemon is a special type of UNIX process
[17:11] <Keybuk> they run it what we call the "background"
[17:11] <Keybuk> you see, UNIX is a multi-tasking operating system
[17:11] <Keybuk> so many different things can all run at once
[17:11] <Keybuk> isn't that clever :P
[17:11] <ogra> Keybuk, oooh and i thought soemthing mystically :P
[17:11] <ogra> like religious or so :P
[17:12]  * ogra was meaning if it is supposed to run in daemon mode even without any networked FSes 
[17:13] <ogra> ok, apparently it is
[17:15] <seb128> tedg, hey
[17:18] <cjwatson> Keybuk: I'm actually a bit baffled by bug 435707, having gone through the logs again in light of that most recent comment
[17:18] <cjwatson> Keybuk: I still think the fix you merged from me is correct, but I no longer think it has anything to do with that bug :-) The log shows mountall getting past that point in run_fsck
[17:19] <Keybuk> does it run fsck? :)
[17:19] <cjwatson> it says it does
[17:19] <Keybuk> does it run it with -f ?
[17:20] <cjwatson> spawn: fsck / [820] - but the log message is obscured and doesn't print the arguments
[17:20] <cjwatson> actually, why aren't we getting a debug message from the spawned child?
[17:21] <cjwatson> there should be one immediately before the execvp
[17:22] <Keybuk> probably usual stdio fuckage
[17:22] <Keybuk> I fixed that in trunk
[17:23] <cjwatson> r47?
[17:23] <cjwatson> I think you might also need a flush after the nih_debug
[17:26] <Keybuk> don't you get a flush on exec anyway?
[17:27] <cjwatson> Keybuk: no
[17:28] <Keybuk> surely you must do?
[17:28] <cjwatson> why so?
[17:28] <cjwatson> certainly nothing specifies it, and glibc's execve stub is pretty simple and doesn't do it
[17:29] <Keybuk> otherwise what takes care of that?
[17:29] <Keybuk> your stdio buffers don't magically get passed via shared memory to the exec()d process that obviously knows what to do with them <g>
[17:29] <cjwatson> (it would have to be in the libc)
[17:29] <cjwatson> you're supposed to flush before exec
[17:29] <Keybuk> where does it say that?
[17:29] <cjwatson> it's implicit in the fact that exec doesn't flush :)
[17:29] <Keybuk> cjwatson: it doesn't say that it doesn't
[17:29] <cjwatson> reality does, though ...
[17:31] <Keybuk> I'll take your word for it ;)
[17:31] <pitti> lifeless: so what are you looking for, desktop translation wise?
[17:33] <lifeless> pitti: the mechanism; ted has a bug where the indicator menu entries are not being translated
[17:33] <lifeless> they are from the desktop files, and if he sets a domain for the menu process, they don't translate
[17:34] <tedg> pitti: seb128 is saying that removing the textdomain setting makes it work for him.
[17:34] <kees> pitti: should apport use launchpad.net instead of edge?
[17:34] <pitti> tedg: what's the .desktop file?
[17:34] <pitti> kees: for what?
[17:34] <lifeless> pitti: several
[17:34] <tedg> pitti: evolution-mail, pidgin, etc.
[17:34] <lifeless> one example is evolution-2.28
[17:34] <seb128> tedg, it works on a simple testcase though
[17:34] <seb128> I wrote one this morning which does the same init
[17:34] <seb128> ie setlocale, bindtextdomain and textdomain
[17:34] <seb128> and things are correctly translated
[17:34] <pitti> lifeless: hang on, I thought we're talking about the indicator applet .desktop file?
[17:35] <kees> pitti: bug 440576
[17:35] <seb128> I need to try again your code
[17:35] <lifeless> pitti: nope, about the things it shows which are refleccted via g_app_info
[17:35] <seb128> gdesktopapp basically use gkey which use gettext
[17:35] <pitti> kees: apport doesn't do anything in particular for edge; the reporter is probably in lp-beta-testers?
[17:36] <pitti> oh
[17:36] <lifeless> that should be either calling dgettext or binding and restoring the domain
[17:36] <lifeless> pitti: so we just wanted to know where the strings to go help in debugging/building hypothesis
[17:36] <pitti> now I know what you are talking about
[17:37] <pitti> so that code reads the .desktop files?
[17:37] <seb128> I already explained to tedg how those are working...
[17:37] <lifeless> seb128: yup, we get that
[17:37] <seb128> pitti, no, it uses gdesktopapp which use gkey
[17:37] <seb128> which is the glib change you wrote
[17:37] <lifeless> seb128: sorry if we are treading somewhat the same path
[17:37] <seb128> that works fine on a small testcase there
[17:37] <bdmurray> Keybuk: the "usb-id" messages in bug 443282 are the normal part or is it something else?
[17:37] <pitti> if you do that parsing manually, you have to use dgettext yourself, yes
[17:37] <tedg> seb128: Yeah, I tried to explain it to lifeless, that's why he's confused now ;)
[17:37] <kees> pitti: ./apport/crashdb_impl/launchpad.py:            launchpad_instance = EDGE_SERVICE_ROOT
[17:37] <lifeless> pitti: no, we don't, we're using the standard api
[17:37] <seb128> who would like to parse those manually anyway?
[17:38] <Keybuk> bdmurray: kernel bug of some kind
[17:38] <pitti> kees: oh, that; but that's not related to where the browser sends you to, it's been there forever
[17:38] <pitti> kees: mainly because there is no production launchpadlib API (or at least hadn't been until recently)
[17:38] <kees> hrm, good point
[17:39] <bdmurray> Keybuk: so that bug should have a linux bug task opened then?
[17:41] <Keybuk> if you like
[17:42] <bdmurray> Maybe I'm confused but there was a call bug bugs to be reported regarding boot messages.  Where do these belong?  Do we not want all of them?
[17:43] <Keybuk> bdmurray: whoever did the call didn't think that far ahead
[17:48] <smoser> anyone know how much space a full ubuntu mirror takes ?
[17:49] <Amaranth> smoser: doesn't debmirror tell you before it starts?
[17:50] <smoser> Amaranth, i dont know. but i just now saw http://www.ubuntu.com/getubuntu/mirror/1  ("A "full archives" mirror is around 210")
[17:50] <lool> smoser: What part?
[17:51] <smoser> i think the link above has what i was asking, lool.
[17:51] <lool> ok
[17:52] <pitti> rickspencer3, kenvandine: FYI, bug 436591 is the one I meant (empathy crasher); it's already on the targetted list
[17:52] <lool> Keybuk: so from reading the discussions here, you dont want a mountall task on that bug?
[17:53] <kenvandine> pitti, i will am looking at that
[17:53] <Keybuk> lool: I've said repeatedly that I accept that there's a mountall bug here *as well*
[17:53] <pitti> Keybuk: right, just because of the "make sure it's targetted" that came up during the meeting
[17:54] <Keybuk> though at this point I've lost all track of bug numbers
[17:54] <Keybuk> and am just going to go around at release time and close any I think I've fixed
[17:56] <lool> Keybuk: Ok so I'm adding a task, do what you think is best with it
[18:11] <Darxus> I'm really surprised launchpad didn't email me when my build completed.
[18:11] <pitti> Darxus: since that's the common case, it just mails you if it failed
[18:12] <Darxus> pitti: That's good.  And I can set an alarm based on when it predicts the build will start... but since it takes so long some times, and I'm generally anxious to have it done, it would be nice to get an email.
[18:16] <dupondje> are there known problems with apparmor & dhclient3 ?
[18:17] <dupondje> http://paste.ubuntu.com/287038/ <- can't get these fixed :s
[18:31] <LaserJock> anybody know what the CLI name of "Universal Access Preferences" is?
[18:38] <slangase`> seb128: pam-auth-update shouldn't be touching /tmp at all
[18:39] <seb128> slangase`, there is nothing in debconf using tmp which could get confusing on tmp wiping?
[18:43] <Amaranth> LaserJock: gnome-at-properties?
[18:43] <LaserJock> Amaranth: hmm, doesn't seem to be it
[18:43] <slangase`> seb128: no, it has its own /var/cache dir, no reason to write anything at all to /tmp
[18:44] <seb128> slangase`, ok, so ignore me, I just though that the timing was suspicious
[18:44] <Amaranth> LaserJock: grep "Universal Access" /usr/share/applications/*
[18:44] <Amaranth> LaserJock: then open that file and check the Exec
[18:45] <slangase`> "udevadm trigger" -hahaha
[18:45] <slangase`> lool: nice bug
[18:45] <slangase`> lool: you still have a task open on mountall; is that an issue or not?
[18:46] <seb128> slangasek, we got 2 of those pam bugs today btw, reassigned your way
[18:47] <LaserJock> Amaranth: no help
[18:47] <Amaranth> LaserJock: I've never heard of it
[18:47] <Amaranth> slangasek: Technically the bug is that mountall wipes /tmp on an already running system, the dmraid change is a workaround
[18:49] <LaserJock> Amaranth: I mean, the grep returns nothing
[18:49] <Amaranth> LaserJock: Right, I figured that
[18:50] <Amaranth> LaserJock: Was saying I've never heard of anything called "Universal Access Preferences"
[18:50] <Amaranth> I have "Assistive Technologies"
[18:50] <Amaranth> but that's gnome-at-properties
[18:50] <cjwatson> there's a "Universal Access" *menu* ...
[18:50] <slangasek> seb128: hmm, more of that pam bug?  Ok, maybe it does have something to do with /tmp, in a way I don't understand
[18:50] <Amaranth> cjwatson: not here
[18:50] <slangasek> maybe the debconf GNOME frontend breaks when /tmp goes away
[18:51] <cjwatson> Amaranth: provision for one anyway
[18:51] <Amaranth> Right, but empty
[18:51] <seb128> slangasek, yes
[18:51] <cjwatson> slangasek: debconf in general uses /tmp
[18:51] <slangasek> oh
[18:51] <slangasek> drat, then :)
[18:51] <slangasek> ok, I'll mark them as dupes
[18:52] <seb128> slangasek, thanks
[18:52] <cjwatson> not that I can remember exactly where
[18:52]  * Amaranth should probably log out to fix his /tmp getting wiped eventually
[18:52] <cjwatson> I'm sure it's somewhere other than in the dialog and editor frontends
[18:52] <Amaranth> but lunch sounds more important right now
[18:52] <LaserJock> Amaranth: it's in my systray and I can't figure out where it came from or how to get rid of it
[18:52] <Amaranth> LaserJock: oh, that's gnome-at-properties
[18:53] <cjwatson> speaking of menus, why do I have a duplicate Calculator item at the top level of Applications?
[18:53] <Amaranth> LaserJock: uncheck the first box there
[18:53] <Amaranth> LaserJock: the app itself is gnome-at-visual
[18:53] <LaserJock> Amaranth: it is unchecked :(
[18:54] <LaserJock> Amaranth: and gnome-at-visual is not running
[18:54] <slangasek> cody-somerville: seen that xubuntu livefs builds are failing?  Looks like a seed ordering problem, maybe
[18:54] <Amaranth> LaserJock: Well I'm stumpted
[18:55] <Amaranth> err, stumped :P
[18:55] <LaserJock> Amaranth: hmm
[18:55] <slangasek> cody-somerville: oh, no - I guess this is an already-fixed bug in xubuntu-gdm-theme, and the ports just need to catchu p
[18:59] <slangasek> cjwatson: hmm, seen bug #444587?  Seems to be a regression caused by your latest grub upload
[19:00] <Amaranth> Every install of grub comes with a free desktop ISO ;)
[19:01] <cjwatson> slangasek: blink. Will look, thanks
[19:01] <cjwatson> I certainly didn't change anything directly related to that
[19:02] <slangasek> oh; I didn't look too deeply, I thought 'objcopy' was kind of a red flag word :)
[19:02] <cjwatson> that was only in the configure script
[19:02] <slangasek> ok
[19:04] <Darxus> Hah, damn, telepathy-idle FTBFS... the irc piece of empathy, the default chat client in karmic.
[19:04] <cjwatson> reproduced in a local build, but dinner is ready so it'll have to wait
[19:05]  * slangasek nods
[19:07] <cjwatson> might be able to backport another piece from grub2 for that
[19:08] <LaserJock> is there a place that gnome lists what apps to restore from a session?
[19:10] <cjwatson> slangasek: at least the .deb compresses well ;-)
[19:10] <slangasek> indeed!
[19:10] <cjwatson>  size 1892884 bytes: control archive= 6106 bytes.
[19:11] <cjwatson>  Installed-Size: 526916
[19:11] <cjwatson> 285x compression
[19:19] <cjwatson> slangasek: actually, sod it - fixing now
[19:20] <cjwatson> might not hurt to crank grub 0.97-29ubuntu58's build priority up some
[19:20]  * cjwatson goes to eat
[19:22] <lifeless> seb128: this translation thing; is it release critical?
[19:22] <lifeless> seb128: we're assuming it is for now, but if its not, we have some rc stuff we would switch to
[19:32] <seb128> lifeless, no it's not, I've a one liner workaround
[19:33] <lifeless> seb128: ok, thanks. Thats disabling the indicators own translations?
[19:34] <tkamppeter> pitti, there still seems to be a problem with USB printing, see bug 420015, comment #105, user tells that he has to set /dev/bus/usb/*/* permissions manually so that printer gets discovered and new udev rules did not make it into current udev.
[19:35] <seb128> lifeless, I will need to test, it's commenting the textdomain call
[19:35] <seb128> lifeless, don't bother with that bug for now
[19:35] <lifeless> seb128: we suspect that will disable the translation for 'm' etc beside the time data
[19:37] <seb128> lifeless, thanks for letting me know I will check that but I want to try debugging it first, I've a working testcase and I know how it's supposed to work so I will give it a try
[19:37] <seb128> ie a standalone gtk code with the same locale init code works correctly
[19:37] <pitti> tkamppeter: hm, current cups runs the usb backend as root again; that still doesn't work?
[19:37] <lifeless> seb128: right, I
[19:37] <seb128> I will keep you guys updated tomorrow
[19:37] <lifeless> 've been looking at the glib patch
[19:37] <pitti> tkamppeter: also, I thought we'd use usblp again?
[19:38] <lifeless> seb128: and i'm happy to follow through and debug it directly too
[19:38] <lifeless> seb128: I think its g_dgettext perhaps.
[19:39] <lifeless> I think I may know what it is
[19:39] <seb128> lifeless, oh ok, what is it?
[19:39] <seb128> it's weird that my testcase is working then
[19:39] <lifeless> look at g_dgettext in devhelp
[19:39] <slangasek> ArneGoetje, pitti: language-pack-gnome-bo uninstallable, breaking livefs builds?  Known issue?  (related to our space problem?)
[19:40] <lifeless> it disables all translations if the application doesn't have a translation
[19:40] <lifeless> so if the indicator-messages-service isn't translated *itself*, it won't show trnslations for anything else either
[19:40] <seb128> lifeless, define "the application doesn't have a translation"
[19:40] <seb128> lifeless, ie if there is no mo file to use?
[19:41] <seb128> lifeless, ok, easy to try, add a dummy string to translate and see if that fixes the issue
[19:41] <lifeless> seb128: I'm reading devhelp, so I can't define "the application doesn't have a translation" very well
[19:41] <lifeless> but yes, I think a mo file - even an empty mo file - for the indicator-messages-service domain will make it work
[19:41] <pitti> slangasek: presumably; it just stopped in the middle of generation
[19:41] <lifeless> seb128: if your test case has a mo file for your test local, that would be why it works
[19:42] <lifeless> seb128: here's how I'd test - change the DOMAIN that indicator-messages-service binds to to be something that is translated
[19:42] <lifeless> e.g. gnome-panel or something
[19:43] <seb128> lifeless, the testcase was using a dummy domain for the textdomain calls
[19:44] <seb128> lifeless, thanks for the hints, I will play with that after dinner
[19:44] <lifeless> or install glib dbgsym and breakpoint translated = g_dgettext (key_file->gettext_domain,
[19:45] <seb128> right
[19:45] <lifeless> then see if it returns the orig value even though the domain etc has been set right
[19:45] <seb128> did you guys try that?
[19:45] <lifeless> no, I was prepping to do that when we realised that the behaviour of g_dgettext was relevant
[19:45] <lifeless> and read up on it.. with shocking results;)
[19:45] <seb128> anyway as said I've a good idea how to look at the returned string etc so I will play with that later
[19:45] <lifeless> cool
[19:45] <seb128> I need to go for dinner now
[19:45] <lifeless> good luck
[19:45] <seb128> bll
[19:45] <seb128> bbl
[19:45] <seb128> thanks
[19:46] <seb128> you too for the next issue you will tackle ;-)
[19:48] <tormod> TheMuso, I reopened bug 440846 with a debdiff, can you please take a look?
[19:50] <pitti> Keybuk: is /sys/class a list of subsystems, or are "class" and "subsystem" different concepts?
[19:56] <ElNerdoDeGeek> Hey, who should I contact concerning a possible (fairly major) Wubi feature?
[19:57] <lool> slangasek: Task on mountall is just to track the fact that it's also a mountall bug that it shouldn't blow /tmp like that when already mounted
[19:57] <lool> slangasek: But fixing one or the other seems enough the drop the bug from its critical status
[19:58] <slangasek> lool: ok - can the mountall task be triaged to something more appropriate than new/undecided, then?
[19:58] <lool> slangasek: There was a longer discussion here between Keybuk and others and I didn't follow the specifics of the mountall issue
[19:58] <lool> slangasek: Sure; I'll confirm + assign keybuk
[19:58] <lool> Sorry I kind of disappeared for other calls after doing the dmraid upload :)
[19:59] <lool> done
[20:02] <tkamppeter> pitti, I am only telling what was reported in bug 420015, but perhaps this user has fallen into an infinite loop of trying to get his USB printer recognized.
[20:06] <slangasek> pitti: would be interested in a quick FFe review of bug #238555 if you can spare the time
[20:28] <pitti> slangasek: replied in the bug
[20:28] <slangasek> pitti: thanks
[20:29] <slacker_nl> hello, I just noticed /etc/apt/preferences.d i take it the logic behind that dir is the same as /etc/apt/sources.list.d
[20:29] <slacker_nl> does anyone have any documentation regarding this change?
[20:33] <slacker_nl> never mind, found it http://osdir.com/ml/debian-bugs-closed/2009-07/msg03476.html
[20:34] <geser> slacker_nl: sources.list.d is for additional repository snippets, while preferences.d is for pinning snippets
[20:39] <slacker_nl> geser: that's what I'm saying, same logic as sources.list.d, but then for pinning
[20:39] <slacker_nl> i know enough
[20:50] <slangasek> pitti: hdparm_is_on_battery> yes, you divined my intent accurately, sorry if this was opaque :)
[20:57] <slangasek> pitti: I note you didn't mark the FFe as 'confirmed' - I've followed up again responding to some of your comments, is that enough for an FFe now?
[21:01] <mathiaz> slangasek: hey - could update the links to test cases on the iso tracker?
[21:01] <slangasek> mathiaz: yes, what links?
[21:01] <mathiaz> slangasek: http://testcases.qa.ubuntu.com/Install/UECInstall
[21:02] <mathiaz> slangasek: ^^ should be replaced with two urls
[21:02] <mathiaz> slangasek: http://testcases.qa.ubuntu.com/Install/ServerECluster for "Install (UEC Cluster Controller)"
[21:02] <mathiaz> slangasek: http://testcases.qa.ubuntu.com/Install/ServerENode for "Install (UEC Node)"
[21:03] <mathiaz> slangasek: is that enough info?
[21:03] <slangasek> mathiaz: yes, thanks
[21:05] <sandberg_> Anyone with experience of Policykit and DBus?
[21:07] <sandberg> I'm having some issues with policykit (bug #439552), seems like this involves UID checking of DBus connections. The strange thing is that I have two installations of Karmic and only the one upgraded from Jaunty is affected by the bug.
[21:18] <Darxus> Screen just crashed on me :/
[21:33] <slangasek> Keybuk: bug #427356 still has a 'cups' task open; is that still on the agenda for 9.10?
[22:17] <slangasek> mathiaz: tracker test case links updated
[22:18] <tormod> sleep/hibernate: if I press my sleep key, gpm does the job its way, if I use the menu, it's done another way by indicator-session. shouldn't this be unified?
[22:19] <slangasek> tormod: both are supposed to be done via devicekit-power -> pm-utils; is this not the case?
[22:20] <tormod> slangasek, I noticed the way they turn on the screensaver is different
[22:20] <slangasek> ah, that's possible :/
[22:21] <slangasek> since that's GNOMEy and therefore not part of what devicekit-power will handle
[22:21] <slangasek> I think that should be a bug report, definitely
[22:21] <tormod> there was recently added stuff to indicator-session but not the same stuff as in gpm
[22:22] <tormod> ok, I can file a bug. on indicator-session maybe? can i-s call gpm to get the same path run?
[22:24] <kirkland> mdz: today's Eucalyptus testing is looking good
[22:25] <kirkland> mdz: i have a cluster + 2 nodes going now
[22:25] <kirkland> mdz: installed from today's ISO
[22:25] <kirkland> mdz: auto registration worked flawlessly
[22:25] <kirkland> mdz: having issues with the UEC image, it won't run
[22:25] <kirkland> mdz: the eucalyptus images are working fine though
[22:25] <slangasek> tormod: I don't know whether there's a path it can invoke, but that shouldn't be a barrier to getting the bug filed on indicator-session and getting people's eyeballs on it :)
[22:40] <tormod> slangasek, I filed bug 444931
[22:56] <mathiaz> slangasek: thank ya
[23:22] <sroecker> just filed a new bug 444962 that will confuse many beta testers
[23:35] <tormod> slangasek, should I make a new debdiff for bug 384875?
[23:39] <slangasek> tormod: I'm just now merging/reviewing your branch; I figured I'd fix up the conffile handling myself afterwards
[23:41] <slangasek> tormod: is there anything in the upstream sleep.d script that we should worry about merging?
[23:41] <slangasek> I guess both scripts are trivial :)
[23:44] <tormod> slangasek, the only difference is that upstream calls laptop_mode auto force and not only auto
[23:44] <tormod> can't remember right now, but we have some Ubuntu changes wrt auto and force
[23:45] <slangasek> tormod: well, no; the main difference is that it respects disabling laptop-mode via /etc/default...
[23:46] <tormod> slangasek, yeah I meant other than the obvious :)
[23:46] <slangasek> ok :)
[23:48] <tormod> we also ship a power.d/laptop-mode, I am to tired to think about why and if :)
[23:49] <slangasek> heh, ok
[23:51] <jbernard_> ive been taking a look at some of the FTBFS problems, cmake builds fine now with the latest version of libxmlrpc-core-c3-dev, we could remove that from the list
[23:54] <tormod> slangasek, if you have time, maybe you can look at my debdiff for bug 430121
[23:55] <cjwatson> jbernard_: not easy to just remove something from the list, it's generated from an automatic build pass
[23:55] <cjwatson> jbernard_: if it builds fine now, great
[23:56] <cjwatson> unfortunately http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909-karmic.html doesn't have any annotation facility at the moment, which is probably impeding serious work on it
[23:56] <cjwatson> wgrant: ^- would it be incredibly painful to add something?
[23:56] <slangasek> tormod: I wonder if bug #384875 is the reason some people have been reporting that their disks are still spinning down when they shouldn't :/  (laptop-mode calls hdparm -S 10)
[23:56] <cjwatson> I mean, today I glanced down the list and fixed various things in main
[23:57] <cjwatson> but if I were to do more than that, I'd almost certainly hit diminishing returns as I start to run into things that other people have fixed
[23:57] <tormod> slangasek, possible
[23:57] <slangasek> cjwatson: "already fixed" - I thought packages that are superseded by newer versions in the archive are supposed to be removed from that page already?
[23:58] <cjwatson> oh?
[23:58] <jbernard_> i believe this is true
[23:58] <cjwatson> hmm, so they are, in that case I take it back
[23:58] <jbernard_> but in cmake's case, it failed because of another package
[23:58] <jbernard_> so it wasn't picked up