[00:11] Keybuk: Does your closing bug #372864 as fFix released mean that you added a getty for hvc0? [00:12] Launchpad bug 372864 in upstart "conf: Put a getty on hvc0" [Wishlist,Fix released] https://launchpad.net/bugs/372864 [00:13] no, it means the upstart task is closed [00:13] But.. [00:13] upstart also provides /etc/init/tty [00:13] *.init? [00:14] I don't think upstart should provide a job for everything anyone can think of [00:14] if you want an hvc0 tty job, it should go in something else [00:14] Um... I don't really see why, really. [00:15] d-i creates an hvc0 job if you're installing on that type of console (FWIW) [00:15] 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 dld Just Work. === lamont` is now known as lamont [00:15] because otherwise we end up shipping a job file for every single user's random wishlist [00:15] cjwatson: Oh, really? [00:15] 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] soren: finish-install/finish-install.d/90console [00:16] slangasek: http://upstart.ubuntu.com/wiki/OMGBroken [00:16] Keybuk: thanks! [00:16] soren: BTW I'm *so close* to getting vmbuilder working with grub2 ... [00:16] cjwatson: Oh, your grub2 branch doesn't work? [00:17] that was a chroot-grub branch [00:17] it copes with grub2 in the host, but still installs grub in the guest. That much is fine [00:17] now I'm working on grub2 in the guest too [00:17] cjwatson: Ah, ok. I didn't look at it yet, I just saw it trickle in. [00:18] chroot-grub is still worth merging, I think (indeed, I'm basing this grub2 branch on it) === dendrobates is now known as dendro-afk [00:21] 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] cjwatson: Sure, sure, I'll look at it shortly. Tomorrow, hopefully. [00:21] * cjwatson nods === dendro-afk is now known as dendrobates [00:24] soren: it sounds like this is already solved [00:24] the installer creates that file [00:25] Keybuk: If one uses the installer, yes. [00:25] I suspect soren is using vmbuilder or similar, which doesn't use installer code and would require reimplementation of the same ... [00:26] Well, there's that, but also upgrades. [00:26] Or virtual machines converted from physical ones. [00:27] 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] pitti, kenvandine: do you know whether gnome-power-manager does the equivalent of 'pm-powersave' at startup? [00:27] soren: I'm not saying you can't do this in an upstart job [00:28] I'm just saying the upstart package is the wrong place for it [00:28] just like we don't ship /etc/init/dbus.conf in the upstart package [00:28] Keybuk: I realise. [00:28] Keybuk: And I disagree. [00:28] How about a xen-guest-stuff package that is strongly recommended to be installed on guests? [00:29] update-manager could even install that when it notices it’s being run within a guest. [00:29] I think that is silly. [00:29] None of my VM's run update-manager (they're server VM's). [00:30] ..and so far, we've managed just fine without such a package. [00:30] % dpkg -S =do-release-upgrade [00:30] update-manager-core: /usr/bin/do-release-upgrade [00:30] That’s on a server. [00:30] You hardly run do-release-upgrade regularly. [00:30] Well, as regularly as you upgrade to a new release. :-P [00:31] It's for doing full distro upgrades. [00:31] That hardly counts as "when it notices it’s being run within a guest" [00:31] When do-release-upgrade notices it’s being run within a guest [00:31] * soren sighs [00:33] soren: worth pointing out, I guess, that I plan to remove the tty* jobs from upstart too [00:33] they were only there because they came from sysvinit via inittab [00:34] Keybuk: See, that's a good argument. [00:34] Keybuk: Where would they go? [00:34] soren: into the package that ships getty [00:34] and it'll be just getty.conf [00:34] Keybuk: Ok. [00:35] there's no reason for having the separate files at the moment [00:35] 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] I don't think I agree with that [00:36] because I still don't think every single person wants getty trying to run on that device [00:36] ?!? [00:36] Why on earth not? [00:36] That's what it's for? [00:36] Well, that or a root prompt or something. [00:37] ...but I didn't think that was really what was being discussed. [00:37] 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] That may be perfectly reasonable. [00:37] and I wouldn't want to ship upstart upstream with a fixed configuration that's not what everyone wants [00:40] RH have that neat /etc/consoles solution [00:40] start on tty-device-added [00:40] stop on tty-device-removed KERNEL=$KERNEL [00:40] instance $TTY [00:40] pre-start exec grep -w $TTY /etc/consoles [00:40] exec /sbin/getty $TTY 38400 [00:40] ;-) [00:42] 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 :) === a1g_ is now known as a1g [00:43] * soren calls it a day === bjf is now known as bjf-afk [01:21] slangasek: dk-power calls pm-powersave [01:22] and it's tied to the battery state === yofel_ is now known as yofel [01:45] 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] mbiebl: so will dk-power get called on gpm startup, or only on battery state chage? [01:46] change [01:48] dk-power will be dbus autostarted I guess by gdm's gpm instance [01:48] and whenever the battery state changes, dk-power will call pm-powersave true|false [01:48] What is it that keeps changelogs lagging so much in publication? Why would they be anything but simultaneous to package publication? [01:49] afaik it's not g-p-m that triggers the pm-powersave call [01:49] slangasek: btw, what's the mispackaging in dk-power? [01:50] I don't see g-p-m being statically linked against libdevkit-power-gobject (at least on sid) [01:50] mbiebl: -dev package has no dep on the shared lib package [01:51] slangasek: should have been fixed in 010-2 [01:52] mbiebl: so there's no guarantee that devkit-power will call pm-powersave on startup, to set an initial configuration? [01:52] (I'm asking because I want to remove some more redundancy out of acpi-support) [01:52] to answer that definitely, I'd have to check the dk-power code [01:53] 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] pitti told me that he had merged that [01:53] well, he hasn't :-) [01:54] next upload will be fixed then [01:54] I'm fixing it in Ubuntu right now [01:56] slangasek: just checked [01:56] mbiebl: it's called from dkp_daemon_startup, so I guess we're good :) [01:56] dk-power set's an initial state [01:56] woohoo [01:56] yep [01:59] https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/443404 [01:59] Launchpad bug 443404 in software-properties "add-apt-repository insists on downloading GPG key even if keyserver is down. If keyserver is down, add-apt-repository can't proceed." [Undecided,New] [02:00] slangasek: I remember. 011 was supposed to be released today and we wanted to sync at this version again [02:02] mbiebl: ok [03:34] 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] superm1: (RE: libmyth/audiopulseutil.cpp) do you still need my input? [03:35] dtchen, well I think i came up with a solution actually. [03:35] dtchen: Did you see my ping on wvstreams? [03:35] ScottK: yes, i'm processing backscroll FIFO [03:35] dtchen: OK. Just wanted to make sure you saw it. [03:36] 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] superm1: yes, but that's still racy [03:38] dtchen, well there are AV sync issues if things are allowed to go through pulseaudio still [03:38] they're not immediately noticable, but with an hour recording w/ comm skip turned off, they turn up [03:38] dtchen: need me to test any more HP patches? [03:38] so this is the easier solution [03:38] (for now given time period) [03:38] superm1: right. suboptimal, but nothing really resolving by late october. [03:39] resolvable* [03:39] ajmitch: soonish, hard to give an ETA right this moment [03:39] 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] dtchen: alright, ping me on irc if you need testing someday [03:40] superm1: indeed [03:40] ajmitch: sure thing [04:45] Has anyone got a broken Network Manager? [04:45] ahhh [04:45] I see a new package [04:46] * jono dist-upgrades [07:10] good morning === nxvl_ is now known as nxvl [07:17] Morning Daniel [07:40] Good morning [07:41] free: sure [07:41] pitti: heya [07:41] 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] 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] ah, good; I read the rest of the scrollback [07:43] pitti: so should I include a SRU-compiant description in each bug involved in the SRU? (with rational, impact, etc.) [07:43] slangasek: so, shall I merge and fix the broken lib dep? [07:43] 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] 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] 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] slangasek: no, I fixed that in Debian's git already [07:45] thanks [07:45] pitti: okay, I'm also going attach a stripped diff containing only the actual changes [07:45] pitti: because many of them were test code, which doesn't even end up in the packages [07:45] free: test code is fine [07:46] 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] s/attached/attach/ [07:46] free: description is preferred, but it doesn't matter so much [07:47] free: but please add proper Ubuntu tasks; so far the bugs just have upstream tasks which aren't even "fix released" [07:47] and it's not clear which fixes are in jaunty/karmic already, etc. [07:47] 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] pitti: so that means open new bugs affecting the relevant releases? [07:48] free: not new bugs; new tasks [07:48] pitti: okay [07:48] free: and please close the upstream tasks as appropriate [07:48] free: ideally for an SRU, the upstream and karmic ubuntu task need to be "fix released" [07:49] we don't put stuff into stables which hasn't even been tested in the latest karmic release yet [07:49] (landscape-client is the obvious exception, which has a standing "new version allowed" permission in the SRU policy) [07:49] pitti: so the thing that we specifically QA-ed this version we're proposing as SRU, the QA process was rather strict [07:50] pitti: so we'd rather prefer to see this smart package accepted, as the changes are bug-fix only, no new features [07:50] 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] 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] pitti: I and Gustavo Niemeyer are possibly available to help reviewing each single change [07:51] pitti: okay, we can strip these user-visible things [07:51] free: why not just have a few targetted patches, like the jaunty upload? [07:51] that's so much safer [07:52] free: https://wiki.ubuntu.com/StableReleaseUpdates#It%27s%20just%20a%20one-line%20change! [07:52] and the "When" section below [07:52] pitti: because we QA-ed those changes already, and we would need to re-do it [07:53] pitti: also note that the landscape-client accepted in -proposed depend on that version of smart or above [07:53] pitti: so that would need to change as well [07:54] free: no, it doesn't [07:54] I reviewed the debian/control changes, and it doesn't bump any smart dependency? [07:54] oh, sorry, it does [07:54] yes, that needs to be fixed [07:55] pitti: yeah [07:55] 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] free: oh, I see; the dependency even moved from one package to the other [07:55] (I'm getting stuck on the pdebuild step, which errors out with Make ..[127]) [07:56] 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] pitti: smart is a critical component of landscape-client [07:56] free: right, but it's not _only_ a component of landscape-client, other users might use it as well [07:57] sure, we don't support it officially, but that's not a reason for us to break it in stables [07:58] pitti: why break? we're pretty confident that the changes are sane, and they've been out and QA-ed since months === Lutin_ is now known as Lutin [07:58] pitti: they are in jaunty and karmic already, except those two patches in the jaunty SRU [07:59] free: well, we have this strict "minimal changes" policy for a reason; we've been burned more than once already [07:59] pitti: http://lists.labix.org/pipermail/smart-labix.org/2009-March/003875.html [07:59] pitti: yes, I understand that [08:00] and half-a-megabyte diffs are far far away from "minimal changes to fix critical bugs only" [08:00] pitti: it's actually ~800 lines, if you consider only installed code [08:01] right, and most of the chagnes there are neither appropriate nor necessary for an SRU [08:02] pitti: okay, I'll try to limit it to the strict necessary, thanks for your feedback [08:03] 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] pitti: good point === porthose is now known as porthose|afk [08:50] 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? === tkamppeter_ is now known as tkamppeter [09:05] could somebody look at bug #444216 and see if they know what's going on? [09:05] Launchpad bug 444216 in gnome-keyring "package libpam-gnome-keyring 2.28.0-0ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 143" [Undecided,New] https://launchpad.net/bugs/444216 [09:05] there is thousand of "Use of uninitialized value $reply" debconf lines in the log [09:05] it seems that something is looping there === dholbach_ is now known as dholbach [09:15] seb128: hum, yes, killing the debconf frontend is a good way to make a debconf-based program loop :) [09:16] slangasek, do you know what package is responsive for displaying the dialog which confused the user there? [09:16] pam [09:16] ok, let me reassign the bug there [09:17] the issue seems that the dialog was not clear to the user [09:17] slangasek, thanks [09:17] is gdm really supposed to be in this awful black and white theme now ? or is that just my system [09:17] design decision [09:17] (the package that libpam-gnome-keyring calls in its postinst, of course :) [09:17] looks horrid :/ [09:18] 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] ogra, I was assuming that was a bug, but didn't get around to reporting it yet... *sigh* [09:20] 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] seb128: no, *at least* one option must be selected [09:20] it's a multiselect [09:20] anyway, the user's already done something wrong to see this dialog at all [09:21] slangasek, the bug is confusing, "I selected them all, only to be informed that I need to select at least one." [09:21] (setting debconf priority to medium or below) [09:21] that seems to be a bug at least [09:21] I don't believe that's what actually happened, though :) [09:21] I've tested this code rigorously [09:21] 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] I think the submitter just wasn't paying close attention [09:22] yep, will do [09:22] thanks [09:57] 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] wgrant: it really shouldn't happen (TM), though [09:58] even the handcrafted linux ddebs follow that naming schema [09:59] 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] wgrant: I'd say, do it like this, at least for now [10:08] wgrant: in all the years when we have used ddebs this case didn't come up [10:10] pitti: Wouldn't any extra ddebs enter the archive without question with the current setup? [10:17] Netsplit! [10:17] _ [10:17] _ __ (_) __ _ __ _ ___ _ __ ___ [10:17] | '_ \| |/ _` |/ _` |/ _ \ '__/ __| [10:17] | | | | | (_| | (_| | __/ | \__ \ [10:17] |_| |_|_|\__, |\__, |\___|_| |___/ [10:17] |___/ |___/ [10:18] mikejones: keep the tone please [10:19] thanks cjwatson - I tried but did not have enough power [10:23] * ogra hands dholbach a mars bar ... [10:23] ... so you are prepared next time :) [10:25] wgrant: they would, yes [10:27] * mvo thinks ogra watches to much advertisement === mbiebl_ is now known as mbiebl [10:39] pitti: how do I add intrepid/jaunty tasks to a bug, I can't figure it out from the LP UI [10:39] free: "Target to release", right below the yellow task table [10:39] you probably don't have the privilege to do so yourself [10:39] you can "nominate for release" [10:39] free: ^ I'll approve your nominations [10:39] okay thanks === doko__ is now known as doko [10:56] does anyone have a firewire device here? [11:00] pitti: meh sorry one thing I don't have [11:20] ArneGoetje: around? [11:21] 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] much of the rest of that pot, have english values listed as the translations? [11:24] ArneGoetje: I'm asksing asking you because you are credited by LP [11:58] 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] ArneGoetje: so I think a mistake was made somewhere [11:59] la is not english [11:59] but there are very many strings marked as translated with the translated version being english [12:00] 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] ArneGoetje: _ugh_ - so we get it marked as translated? [12:01] lifeless: that's a requirement of XPI files. There needs to be a string there. [12:02] lifeless: bbl, need to go for lunch now. [12:04] ArneGoetje: and we import from the xpi, with no change of importing fom upstreams translatio data? [12:46] ttx: if the post-start fails, that will log an error in syslog [12:46] ttx: are you seeing that error? [12:46] we could increase or remove the timeout if it is too short [12:47] mdz: yes [12:47] and it doesn't prevent registration from running. [12:47] it seems like the test we are using always fails, so increasing timeouts won't help :) [12:47] mdz: like I said, it's so strange I want another pass at testing [12:48] ttx: really? that test was succeeding for me [12:48] it's been modified since then, though [12:49] 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 === porthose|afk is now known as porthose [13:13] mdz: filed bug 444504 about that [13:13] Launchpad bug 444504 in eucalyptus "Autoregistration through upstart, while working, uses strange ways" [Medium,New] https://launchpad.net/bugs/444504 === dendrobates is now known as dendro-afk [13:23] has anyone uploaded any maintainer script changes in the last 24 hours? [13:24] 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] directhex: that was built a little while back, but I reproduced it on my laptop [13:26] 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] 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] aha, thought so [13:31] i recognise this as i worked on it with sanvila@debian [13:32] 0.17-7 removed all mono stuff [13:32] hum, something seems to clear tmp on upgrades since today, anybody has a clue what change could do that? [13:32] and you're on 0.17-6ubuntu2, so... [13:32] directhex: ha, so the right answer is a merge. ok. [13:33] cjwatson, it might've been an easy fix. check the 0.17-7 diff [13:34] will do, thanks [13:34] just been trying to clear up a few build failures this morning [13:41] slangasek, those weird pam bugs could be also due to this tmp cleaning on upgrade issue [13:41] bug #444252 is gconf-schemas breaks due to that [13:41] Launchpad bug 444252 in gconf "gconf-schemas: OSError: [Errno 2] No such file or directory" [Undecided,Confirmed] https://launchpad.net/bugs/444252 === arand_ is now known as arand [14:47] ttx: how's today's iso? [14:47] kirkland: not too bad :) [14:48] ttx: :-) i was hoping for some good news [14:48] * kirkland is tired of waking up to bad news every day [14:48] slangasek, bug #444252 for the record is probably something to track [14:48] Launchpad bug 444252 in ubuntu "tmp cleaned during upgrades and breaking installations?" [High,Confirmed] https://launchpad.net/bugs/444252 [14:48] it's collecting duplicates quickly [14:48] kirkland: actually it's surprisingly not too bad. [14:49] ttx: :-) [14:49] ttx: i'm very happy to hear that [14:49] kirkland: using a collection of unrelated bugs, autoregistration actually works [14:49] kirkland: see bug 444504 [14:49] Launchpad bug 444504 in eucalyptus "Autoregistration through upstart, while working, uses strange ways" [Low,Triaged] https://launchpad.net/bugs/444504 [14:49] ttx: now you're just getting picky! :-) [14:49] :-P [14:51] kirkland: i'm not really kidding. if we fix any of these bugs without fixing the others, autoregistration might fail :) [14:51] ttx: funny enough, i believe you [14:52] kirkland: I committed a few fixes on the branch [14:53] kirkland: an update to rev913 should help us, though it's a confusing mutifix rev [14:53] 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] ttx: i agree [14:54] ttx: as for "rev913" [14:54] ttx: i don't think we should merge any more upstream [14:54] ttx: i think we need to cherry pick whatever commit r913 is [14:54] kirkland: however if I fix that without fixing bug 443325, that would break autoregistration [14:54] ttx: apply it in our branch, and release 0ubuntu2 [14:54] Launchpad bug 443325 in eucalyptus "/services/Heartbeat fails on exception" [Undecided,Fix committed] https://launchpad.net/bugs/443325 [14:54] ttx: merging is a pain in the ass at this point [14:55] 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] r913 is several fixes unfortunately. With the usual blank space noops [14:55] so its quite confusing [14:55] ttx: that's fine, it can still be cherry picked [14:59] The last one I encountered is bug 444352, some db deadlock on reboot [15:00] Launchpad bug 444352 in eucalyptus "DB deadlock on reboot prevents EMI from being started" [Medium,New] https://launchpad.net/bugs/444352 [15:00] we'll need nurmi on that one as well. === robbiew-afk is now known as robbiew === tjaalton_ is now known as tjaalton [15:21] How do I do a kernel abi bump? [15:22] For bug #424927. [15:22] Launchpad bug 424927 in linux "[needs-packaging] include Brain Scheduler" [Wishlist,Confirmed] https://launchpad.net/bugs/424927 === robbiew is now known as robbiew-afk === Whoopie_ is now known as Whoopie [15:48] cjwatson: thoughts on what the apport field name should be for bug 364649? [15:48] Launchpad bug 364649 in installation-report "Please include installation media build number in installation logs" [Wishlist,Fix released] https://launchpad.net/bugs/364649 [15:48] I was thinking UbuntuInstallationOrigin or UbuntuInstallationMedia or some such [15:49] I believe I answered my abi question (in the bug). [15:52] mdz: prefer media over origina [15:52] -a [15:52] mdz: how about MediaInfo to match the file name? [15:53] or InstallationMediaInfo [15:53] 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] cjwatson: "info" seems redundant. how about InstallationMedia? [15:54] 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] mdz, would "source" be too confusing? [15:57] mvo: is hardy upgrade enabled in the dist upgrade tool? [15:57] InstallationMedia or InstallationMedium sounds fine. "source" already has an overloaded meaning here, namely an apt source [15:58] cjwatson: done, with InstallationMedia [15:58] beuno: yes, I agree with cjwatson that it would be [15:59] 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] (apport field names are developer-facing more than user-facing and so developer jargon such as "apt source" is relevant) [15:59] Riddell: should be, but not in the meta-release file [15:59] hey guys when is /dev/shm mounted? [16:00] cause its not in fstab [16:00] in karmic, mountall does t [16:00] in 9.04 the asus touchpad acpi button broke and SHMClient is broken because of it [16:00] cjwatson: it does? its man page doesn't document that fact [16:01] i fixed the touchpad button by using xinput instead but the latest update overwrote my changes to /etc/acpi/asus-touchpad.sh [16:01] mvo: no meta-release doesn't need changed, we patch adept to look for karmic [16:01] dotblankalt: in 9.04, I believe it was the responsibility of /etc/init.d/mountdevsubfs.sh [16:02] 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] Launchpad bug 444252 in ubuntu "tmp cleaned during upgrades and breaking installations?" [High,Confirmed] https://launchpad.net/bugs/444252 [16:02] mdz: mountall? its manual page doesn't document very much as yet ;-) [16:02] ./src/mountall.c:218: { "/dev/shm", NULL, FALSE, "tmpfs", "nosuid,nodev", NULL }, [16:02] ./src/mountall.c:231: "/dev/shm", /* Built-in */ [16:03] 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] lool: yeah, seems serious to me. mountall erases /tmp if it mounts it. [16:03] I'm bumping the bug to critical [16:04] kees, oh, you know what is creating the issue? [16:05] mountall doesn't run on upgrade though does it? [16:05] seb128: no, but I saw mountall mentioned just now [16:05] ok [16:06] well I just tested the asus-touchpad on an aspire one [16:06] the button doesnt send any acpi events in acpi_listen [16:06] but the touchpad is disabled [16:06] kees: the mountall discussion was independent, I thought [16:07] In the g51vx and others when the touchpad event fires synclient fails [16:07] 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] cjwatson: ah, well, it also jumps to mind as something that clears /tmp, but... I don't think it has changed recently. [16:07] juego de boxeo online http://www.kobox.org/kobox-fande-Nourine.html [16:08] I think the aspire one got around by doing this at the bios level [16:09] but alot of asus's touchpad buttons dont work in 9.04 [16:09] seb128: are they all evolution failures? (working my way through the dups...) [16:10] ah, no, ok [16:11] cjwatson: that bug where the cloud install used -generic instead of -server is fixed now, right? [16:11] kees, the update-gconf-defaults might have been spawned by the evolution upgrade [16:11] mdz: yes [16:11] oh wait [16:12] theres a g-p-m bug in there too [16:12] mdz: I fixed it more or less on the spot during the last discussion [16:12] cody-somerville: yeah, though it's not clear if the gpm is related? === hile__ is now known as hile [16:14] greg-g: ping === Pici is now known as Guest99641 [16:15] 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] Launchpad bug 444252 in ubuntu "tmp cleaned during upgrades and breaking installations?" [Critical,Confirmed] [16:15] mvo: the one that calls shutil.rmtree() isn't a prime suspect? :) [16:16] LOL === Guest99641 is now known as Pici [16:16] Keybuk: that's what I was looking at currently... [16:17] that only nukes a temporary directory created with tempfile.mkdtemp though [16:17]