[00:58] <psusi> ugh, I hate hal... it is such an undocumented flaming mess
[00:58] <Keybuk> fortunately it's mostly dead
[01:02] <psusi> I still have a hald-addon-cpufreq running and can't figure out WTF it's doing... it doesn't recognize --help, has no man page, and I'm coming up short on google
[02:33] <geoff-ysu> hello
[03:06] <ScottK> cody-somerville: I suspect https://bugs.launchpad.net/ubuntu/+source/kdebase-workspace/+bug/538524/comments/5 applies to xdm if someone didn't make the equivalent change already.
[05:27] <slangasek> Keybuk: why is bug #538524 a kdm bug when plymouth is still marked as 'stop on starting kdm'?
[06:35] <pitti> Good morning
[07:55] <\sh> mvo: julian fixed the python-apt-doc bug in debian...I wonder if we can backport this or do you want to push new python-apt into ubuntu?
[07:55] <\sh> mvo: and good morning ;)
[08:01] <mvo> \sh: good morning! there is a freeze exception for this pending, I have not checked this morning. I would like to get the new p-apt
[08:06] <\sh> mvo: sounds good :)
[08:07] <mvo> :)
[08:07] <mvo> otherwise I guess a backport is it
[08:08]  * \sh needs more coffee
[08:11] <dholbach> good morning
[08:11] <\sh> moins dholbach
[08:11] <dholbach> hi \sh
[08:14] <mvo> hey dholbach
[08:14] <dholbach> hey mvo
[09:22] <lool> doko__: I don't think it's worth disabling the valgrind build on armel; it's probably easier to keep the binaries around to help debugging
[09:27] <cjwatson> I wish people would attach log files as log files rather than tarring them up
[09:28] <lool> cjwatson: perhaps we should point them more strongly at apport and make sure the hook does the right thing?
[09:29] <cjwatson> not always feasible, and I'm not always talking about Ubuntu bugs anyway :-)
[09:29]  * lool didn't mention Ubuntu either   :->
[10:06] <doko__> lool: ok, fine with me
[10:08] <lool> doko: thanks
[11:03] <doko> kees: http://launchpadlibrarian.net/40944002/buildlog_ubuntu-lucid-ia64.qt4-x11_4%3A4.6.2-0ubuntu2_FAILEDTOBUILD.txt.gz  the build did succeed without your stack-protector patch; no clue if it's really related to this ...
[11:19] <cjwatson> Keybuk: do you think it would be worth changing loadkeys to read the keymap with zlib directly rather than forking gzip?
[11:19] <Keybuk> will it make much difference?
[11:19] <cjwatson> the bootcharts have enough variance that I'm not sure I can measure accurately
[11:20] <cjwatson> centiseconds maybe, I guess you want everything you can get though? :)
[11:21] <Keybuk> the console-setup stuff creates about a 1s regression in time for me consistently
[11:21] <cjwatson> there is a noticeable amount of CPU spent in loadkeys, although I'm not sure how much of that is the zillion ioctls
[11:21] <cjwatson> really?  I couldn't see any regression on the bootcharts that I could pin on console-setup
[11:21] <cjwatson> there were differences in time, but they seemed to be accountable to other things
[11:22] <cjwatson> (I looked as carefully as I could last night)
[11:22] <Keybuk> you're doing it on "starting" mountall, right?
[11:22] <Keybuk> or something similar?
[11:22] <cjwatson> the only regression I could see from console-setup was a 0.08s increase in plumbing time on SSD
[11:23] <cjwatson> start on (virtual-filesystems or starting rcS or starting mountall-shell)
[11:23] <Keybuk> on the SSD charts, they've got 0.3s slower since adding console-setup
[11:23] <cjwatson> they seemed to have practically that much variance anyway
[11:24] <Keybuk> yes, but they've gone up consistently since then
[11:24] <cjwatson> right, but I looked at the bootcharts and I couldn't see how that accounted to console-setup
[11:24] <cjwatson> not with any accuracy
[11:25] <Keybuk> I guess because it runs alongside plymouth, ureadahead, mountall, udev, etc.
[11:25] <Keybuk> so it slows all those things down
[11:25] <Keybuk> it's probably "doing too many things at once"
[11:25] <cjwatson> ok, well we're certainly doing something we weren't doing at all before, due to a bug
[11:25] <cjwatson> but I can see if I can trim out any more fat
[11:25] <Keybuk> thanks
[11:26] <Keybuk> I'm kinda tired of the boot stuff; every time we speed it up, someone manages to slow it down again
[11:26] <Keybuk> and mostly it's DX not you ;-)
[11:26] <Keybuk> so please read my slight grumpiness as not directed towards you
[11:26] <Keybuk> the console-setup stuff is obviously a needed thing we have to fit in there somehow :p
[11:26] <cjwatson> in some cases I was seeing X actually starting faster after console-setup; I'm not sure I know how to read these as well as you do
[11:27] <cjwatson> and the variance on the HDD charts is hopeless of course
[11:27] <Keybuk> dunno, X seems a bit slower in general at the moment again
[11:27] <Keybuk> yeah, HDD is crap to read
[11:27] <cjwatson> oh I meant the start of X
[11:27] <Keybuk> right, that's what I mean, X init phase
[11:27] <Keybuk> that could be the fact plymouth isn't dicking around with it either of course
[11:27] <cjwatson> no, I meant the point on the chart at which X starts :-)
[11:27] <cjwatson> not the time it takes to start
[11:27] <Keybuk> oh, that varies a bit
[11:27] <Keybuk> but yeah, it's all a bit jumbly
[11:28] <Keybuk> hoping that after β1, people will stop randomly changing stuff, and we'll be able to tweak it a little bit more
[11:28] <cjwatson> so there's the double call to setfont I mentioned, and zlib might make a difference - we're punting 120K of data around over read/write when we don't need to.  won't be a whole lot but it might be enough to let other things be scheduled more efficiently
[11:28] <Keybuk> on the bright side, the VT switch bug proves what I've been saying about compiz all along <g>
[11:29] <Keybuk> yeah, sometimes minor tweaks like that can have the most effect
[11:29] <cjwatson> we're also loading the font file in userspace six times, so it might be worth seeing if we can modify setfont so that we can call it just once after all the ttys are ready, although I'm a bit worried about that introducing new races
[11:30] <Keybuk> it might remove some
[11:30] <cjwatson> maybe, it's all annoyingly delicate
[11:34] <Keybuk> talking of which, still need to debug these two remaining plymouth issues
[11:42] <cjwatson> Keybuk: you know, we might gain by simply not bothering to gzip the font; none of the console font files are bigger than 34523 bytes uncompressed
[11:42] <cjwatson> for the keymap it's more questionable, but we only load that once vs. six times
[11:42] <Keybuk> makes sense
[11:42] <Keybuk> when do you set the font btw?
[11:43] <Keybuk> after fbcon is loaded, I assume?
[11:43] <cjwatson> yes - well, both before and after unfortunately, as we don't really know whether fbcon is going to be loaded
[11:44] <cjwatson> I'm not implacably opposed to removing the "before" if that turns out to make a big difference
[11:44] <Keybuk> fbcon is always loaded?
[11:44] <cjwatson> (and if it all still works ...)
[11:44] <cjwatson> I think I was concerned about failures before fbcon manages to load
[11:44] <cjwatson> but, like I say, can perhaps remove that
[11:49] <bdrung> pitti: regarding units policy: should g_format_size_for_display() use IEC prefixes then?
[11:50] <pitti> bdrung: like "KiB"?
[11:50] <pitti> might be better, yes
[11:50] <bdrung> pitti: yes
[11:50] <pitti> but I think we should just fix the individual apps
[11:50] <pitti> I added a nautilus task
[11:51] <seb128> let's drop this glib change for lucid
[11:51] <seb128> we don't know how many apps that impacts on
[11:51] <seb128> it's not a change you start a beta time
[11:51] <bdrung> pitti: we should write new functions for glib and the glib-maintainer should accept them. then all apps can be ported to use the new ones (otherwise every package needs the conversion function)
[11:52] <pitti> bdrung: *nod*
[11:52] <pitti> seb128: already uploaded, bugs updated, followed up upstream
[11:52] <seb128> we should working on fixing bugs now, not on shuffling around everything
[11:52] <seb128> pitti, you rock, thanks
[11:52]  * seb128 hugs pitti
[11:53] <pitti> seb128: I added a nautilus task instead
[11:53] <pitti> which is really the most pressing one
[11:53] <pitti> gvfs/system-monitor etc. don't use that broken function
[11:53] <seb128> the function is not broken...
[11:54] <bdrung> pitti: btw, your approach make this PPA https://launchpad.net/~bdrung/+archive/base-2 totally unmaintable
[11:54] <seb128> I wish we would just stay away to touch that and keep what upstream is doing
[11:54] <pitti> seb128: sure it is
[11:54] <pitti> seb128: but unless upstream wants to accept this kind-of ABI breakage, there's no way to fix it
[11:54] <seb128> pitti, it's not broken, or rather it's broken by design I think
[11:55] <seb128> right
[11:55] <pitti> broken by whatever, yes
[11:56] <seb128> well, what we have now is consitent with other systems and what users are used to so it's the less confusing user experience imho
[11:56] <seb128> it's also the reason why GNOME has not been changing it
[11:56] <bdrung> even people that are aware of IEC prefixes make mistakes: bug 538732
[11:56] <pitti> haha
[11:56] <pitti> seb128: no, it's so much not consistent
[11:56] <seb128> anyway let's not redo this discussion now, I just think we should wait for after the LTS to do such changes
[11:56] <pitti> seb128: but at least right now we have known inconsistency
[11:57] <seb128> pitti, right, that's what I mean by consistent with other systems
[11:57] <pitti> seb128: the reason why GNOME hasn't changed it was that it can be considered an ABI break, not because (most of them) think that it's actually correct
[11:57] <seb128> other distros and OSes are inconsistant the same way
[11:57] <bdrung> seb128: is this consistent: http://launchpadlibrarian.net/40938824/karmic-disk-properties.png
[11:57] <pitti> we'll fix that in nautilus itself
[11:57] <seb128> bdrung, yes
[11:58] <seb128> bdrung, the volume is make wrong on purpose to match what vendor write on units
[11:58] <pitti> seb128: oh come on
[11:58] <seb128> anyway lunch time
[11:58] <seb128> bbl
[11:58] <pitti> seb128: enjoy!
[11:58] <pitti> lunch sounds fine
[11:58] <seb128> pitti, thanks
[11:58] <seb128> pitti, no "come on", but that's a topic people will never agree on
[11:59] <seb128> and that's why I think we should not step in that controverse for the lts
[11:59] <seb128> rather delay to next cycle
[11:59] <seb128> anyway lunch
[11:59] <pitti> seb128: I didn't see anyone so far who argues that "4.0 GB" == "3.7 GB" in that dialog is correct
[11:59] <seb128> bbl
[11:59] <bdrung> that's why i am glad about the policy
[12:00] <cjwatson> bug 538165 is pretty doom-laden
[12:01] <cjwatson> and right now I'm not seeing any change there that would actually measurably improve matters
[12:01] <bdrung> cjohnston: i added "Wrong labeled devices" to https://wiki.ubuntu.com/UnitsPolicy
[12:01] <cjwatson> fix your tab completeion
[12:01] <cjwatson> -e
[12:02] <pitti> cjwatson: we could make the html pages also print MB, not MiB?
[12:02] <cjwatson> anyway, "wrong labeled" is a misnomer
[12:02] <cjwatson> just as it is a reality that hard disks are labelled in decimal units, it is a reality that CDs are labelled in binary units.  complaining that this is wrong is equivalent to stamping your feet and shouting that the universe is broken
[12:03] <directhex> the universe IS broken.
[12:03] <cjwatson> the thing that is wrong here is that the policy does not account for these situations; reality is what it is
[12:03] <cjwatson> pitti: controlled by apache, can't change it in cdimage
[12:03] <pitti> ah, right
[12:03] <cjwatson> not without completely taking over directory listing functionality, anyway, which would be a right pain
[12:04] <persia> Just as a minor note, hard drives aren't actually labeled in sane decimal units: they are labeled in decimal multiples of binary units.
[12:04] <bdrung> cjwatson: should i change it to "Misnomers of devices"?
[12:04] <cjwatson> persia: yes, indeed
[12:04] <cjwatson> bdrung: dict misnomer
[12:04] <cjwatson> I'm saying that "wrong labeled" is a misnomer, not that the devices are misnomers (whatever that might mean)
[12:04] <cjwatson> as in, that section heading is wrong
[12:05] <cjwatson> "Device types that this policy fails to account for", perhaps
[12:05] <bdrung> cjohnston: so what your proposed heading?
[12:05] <cjwatson> *please fix your tab completion"
[12:05] <bdrung> damn
[12:05] <cjwatson> 12:05 <cjwatson> "Device types that this policy fails to account for", perhaps
[12:06] <bdrung> cjwatson: and something shorter?
[12:07] <cjwatson> "Bugs in this policy"
[12:08] <bdrung> cjwatson: bugs sounds too hard. you can't create a units policy without "bugs". either DVDs don't match or CDs.
[12:08] <cjwatson> it is a bug.  whether you can fix it is a different matteer.
[12:08] <cjwatson> matter
[12:08] <cjwatson> if you think it's hard, then I think that's you being defensive, TBH
[12:09] <bdrung> cjwatson: how can we educate manufacturers to label the devices correct?
[12:09] <cjwatson> we can't.  HTH
[12:10] <cjwatson> it's much better to live with the fact that this is the way it is than to waste our time in fantasy
[12:14] <bdrung> cjwatson: this section is about the devices, which are not labelled correct by the manufacturers. this section should help readers to understand the problems dealing with these devices.
[12:14] <bdrung> cjwatson: feel free to improve the wording
[12:15] <cjwatson> who are we to say that they are incorrect?
[12:15] <persia> Just out of curiosity, how do CD and DVD labelling differ?
[12:15] <cjwatson> let's live in the real world here, a little bit!
[12:16] <cjwatson> we are an OSV with a small percentage of the market - if we had >50% we might be able to dictate this sort of thing, but we don't
[12:16] <bdrung> cjwatson: we can say that they are abusing the SI standard
[12:16] <cjwatson> and even if it changed, CDs labelled the "old" way would be around for a long time - changing the labelling would probably be worse
[12:16] <cjwatson> bdrung: I'm pretty certain they don't care
[12:16] <persia> Consistency in marketing labeling is to be preserved.
[12:17] <persia> There is sufficient investment in the ways the numbers are counted that it is very expensive to change, regardless of the motivation.
[12:17] <bdrung> cjwatson: do you really think that changing the CD label from 700 MB to 700 MiB would be worse?
[12:17] <cjwatson> I think it's never going to happen, so why should we waste time talking about it?
[12:18] <cjwatson> in reality, it is for us to deal with what's out there, not the other way round
[12:19] <cjwatson> Note that I am not saying this is possible; not all bugs are fixable, and we should acknowledge even those bugs that we can't fix
[12:19] <bdrung> cjwatson: agreed
[12:19] <pitti> I'd strive for consistency within the system, e. g. in GNOME (to avoid having two different units in the same dialog, etc.)
[12:19] <cjwatson> and in this case we're trading off sets of bugs against each other, and a clear accounting of the bugs flowing from each choice makes it possible to choose between them with a clear head
[12:19] <pitti> we can't ever fix the entire world
[12:19] <bdrung> cjwatson: you are free to change the wording of this questioned section
[12:21] <bdrung> pitti: for fixing the world, we have to fix #1 first.
[12:21] <bdrung> ;)
[12:21] <cjwatson> bdrung: done
[12:22] <cjwatson> so what about the fact that hard disks are actually measured in decimal multiples of 1024 bytes?
[12:22] <cjwatson> we rather spectacularly failed to address that in the policy, so we're still going to be off in our measurements, just less so
[12:25] <bdrung> cjwatson: thanks
[12:26] <cjwatson> or at least so I understand; wikipedia doesn't back me up here, although persia and I appear to have the same understanding
[12:27] <bdrung> cjwatson: hard disks measured in decimal multiples of 1024 bytes? when displaying the size in kB or greater, will there be a difference or is it rounded away?
[12:27] <persia> Unfortunately, all the disks I've bought in the past couple years have been unboxed, so I can't be entirely sure, but I remember reading "One gigabyte is defined as 1,000,000 kilobytes"
[12:27] <bdrung> pitti: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/369525/comments/17
[12:27] <persia> bdrung: There will be a 2.4% error, which may matter for >1TB drives.
[12:28] <cjwatson> what he said.
[12:28] <bdrung> [    1.145856] sd 2:0:0:0: [sdb]<PHONE_NUMBER> 512-byte logical blocks: (1.50 TB/1.36 TiB)
[12:29] <bdrung> that is<PHONE_NUMBER>016 bytes = 1.500 TB
[12:29] <bdrung> no 2.4% error
[12:30] <cjwatson> of course that doesn't necessarily prove it since -2.4% from that would be 1.465 TB which would round to 1.5, but OK
[12:30] <cjwatson> I don't remember where I picked this up from; it was a while back
[12:31] <bdrung> even the SSD is correct: [    1.145751] sd 1:0:0:0: [sda] 125045424 512-byte logical blocks: (64.0 GB/59.6 GiB)
[12:31] <bdrung><PHONE_NUMBER>8 bytes = 64 GB
[12:32] <cjwatson> I have to say, though, after reading the bugs, I agree with various folks who said we should not be doing this for Lucid
[12:33] <cjwatson> IIRC, we only voted for this in the TB on the understanding that we had time to pull it out if it seemed to be causing trouble
[12:33] <pecisk> Is it right that Lucid will have OpenOffice.org 3.2.0, not 3.2.1?
[12:36] <seb128> pecisk, when is 3.2.1 due?
[12:37] <seb128> pecisk, when will 3.2.1 be availble rather?
[12:37] <seb128> brb, session restart
[12:41] <pecisk> seb128: sorry, seems like 3.2.1 is still long overdue. Upstream translations deadline is 29th April, but it says nothing that release will follow soon. Sorry to bother :)
[12:42] <pecisk> seb128: they plan RC1 on 19th April, for a fact
[12:43] <seb128> pecisk, that means 3.2.1 will be after lucid
[12:43] <pecisk> yep
[12:43] <seb128> so lucid can't really have it I guess
[12:43] <pecisk> I see :)
[13:25] <primes2h> pitti: Hello. apport-collect doesn't allow me to add info to an existing bug report because I'm not the original reporter (in Lucid). Is that a bug or this is the way it works? is there any workaround?
[13:26] <pitti> primes2h: yes, it's supposed to be that way; you should subscribe to the bug if you participate in the discussion
[13:27] <primes2h> pitti: it could be a problem if you need to report some info against the linux package.
[13:27] <pitti> why?
[13:28] <pitti> if you submit information, but aren't available to followup questions, this isn't very useful
[13:29] <primes2h> pitti: Some people could have the same problem (same hardware) and the original reporter could not have time (in a particular period) to provide them. Others can save time providing info automatically.
[13:30] <primes2h> pitti: They can open a new bug report
[13:30] <primes2h> by the way
[13:30] <primes2h> but then they need to mark it as a duplicate
[13:30] <primes2h> I mean, to provide info
[13:31] <primes2h> s/provide them/provide info
[13:31] <pitti> primes2h: right, but why shouldn't they subscribe to the bug they are providing info for?
[13:32] <pitti> apport will warn if you aren't the reporter, and will refuse if you are neither the reporter nor subscribed
[13:32] <primes2h> pitti: you mean that if they subscribe to the bug they can provide info via apport-collect?
[13:32] <pitti> correct
[13:32] <csurbhi> I want to send a patch to the samba mailing list.. should i also include it on some ubuntu list ?
[13:32] <pitti> (that's what the error message says, too)
[13:32] <primes2h> pitti: ah, ok! I understand. Sorry for misunderstanding ;-)
[13:33] <primes2h> pitti: Thank you. :-)
[13:33] <pitti> np :)
[13:33] <pitti> primes2h: we originally didn't have that limitation, but that resulted in a lot of bug spam
[13:33] <pitti> primes2h: such as random people dumping info to unrelated bugs, which were evne invalid/duplicates/etc.
[13:33] <pitti> so we had to make it a little more strict
[13:34] <primes2h> pitti: yes, I agree with this.
[13:36] <primes2h> pitti: I mean, with you about this
[13:44] <Riddell> cjwatson: you fixed the user permissions issue in kde_ui?
[13:44] <Riddell> cjwatson: I was just going to add a conditional to go back to the old code unless it's for UBIQUITY_ONLY
[13:49] <Riddell> cjwatson: I got the progressDialog fixed anyway, and another wee bug
[13:50] <Riddell> Hmm, still the "An attempt to configure apt to install additional packages from the CD failed." issue
[14:03] <cjwatson> Riddell: yes, working on a bit more - kdesudo isn't meeting our needs here and I think a tiny bit of manual xauth passing will be quite sufficient
[14:03] <cjwatson> Riddell: apt> installing from USB stick?
[14:03] <Riddell> cjwatson: no CD
[14:03] <cjwatson> Riddell: I think we can leave the permission handling around KApplication alone now; it will be clearer that way
[14:05] <Riddell> cjwatson: your fix looks much nicer than my suggested workaround, thanks
[14:08] <cjwatson> I'm going to replace it actually :)
[14:08] <cjwatson> http://paste.ubuntu.com/395630/ should fix bug 526456 at the same time
[14:09] <cjwatson> Riddell: can we fix the way the hostname box gets prefilled with "-desktop-desktop-desktop-desktop-desktop"?
[14:10] <cjwatson> actually, I think I see where that bug is ...
[14:10] <cjwatson> http://paste.ubuntu.com/395631/ look plausible?
[14:11] <Riddell> cjwatson: yes it does
[14:16] <cjwatson> Riddell: is the big progress bar during installation indeterminate for you as well, or did I just break something?
[14:16] <Riddell> cjwatson: I just committed the fix for that
[14:18] <cjwatson> ah good
[14:24] <smoser> Keybuk, you have a minute ? bug 531494.  If you could give me some wild guesses as to where to look, I'd really appreciate it.
[14:24] <Keybuk> look for what?
[14:25] <smoser> At this point i really expect that the backlevel of upstart just masked the issue... all other evidence appears to point to timing.
[14:25] <Keybuk> there are very strange things in your logs that I cannot explain
[14:25] <smoser> "where to look" == where to try to find the source of the problem.
[14:25] <Keybuk> like the fact /proc/self/mountinfo has information about /proc that can only come from fstab
[14:25] <smoser> Keybuk, oh ? like what?
[14:25] <Keybuk> and thus something must run "mount /proc"
[14:25] <Keybuk> (like that)
[14:26] <smoser> ok... let me paste you the /etc/fstab just to make sure its sane
[14:26] <Keybuk> no, you misunderstand me
[14:26] <Keybuk> this implies that I do not understand your boot
[14:27] <Keybuk> Ubuntu does not mount /proc that way
[14:28] <Keybuk> I think you need to do elementary level debugging
[14:28] <smoser> http://paste.ubuntu.com/395643/
[14:28] <Keybuk> adding echo statements everywhere to a log, with timings
[14:28] <Keybuk> including printfs in C code, etc.
[14:28] <smoser> well, thats /etc/fstab
[14:29] <smoser> Keybuk, i really can't think of anything strange about the image at this level (ie, prior to cloud-init running).  other than that, it is just "ubuntu", so I don't know how it could mount /proc in a different way
[14:29] <Keybuk> it's not just ubuntu - you don't have an initramfs
[14:29] <Keybuk> but the logs you've pasted suggest to me that you *do* have an initramfs
[14:29] <Keybuk> which is what confuses me
[14:30] <smoser> which log ?
[14:30] <Keybuk> the mountall debug log
[14:30] <Keybuk> filesystems are already mounted in unusual ways
[14:30] <smoser> it is possible that i've posted an initramfs log
[14:30] <smoser> nah http://launchpadlibrarian.net/40094568/console-fail-debug.txt surely doesn't have a ramdisk.
[14:30] <Keybuk> though kees is going to kill you for that fstab entry, y'know :p
[14:31] <Keybuk> like proper axe-through-brain killing
[14:31] <smoser> you'd see messages from the ramdisk if there was a ramdisk
[14:31] <Keybuk> smoser: ok...
[14:31] <Keybuk> answer me this
[14:31] <Keybuk> why is there several seconds of log before mountall is started
[14:31] <Keybuk> during which scsi devices are loaded
[14:31] <Keybuk> md devices are scanned
[14:31] <Keybuk> etc.
[14:32] <Keybuk> if that was just builtins, I'd vaguely expect them to be further up than that ;)
[14:32] <Keybuk> might be wrong, obv
[14:33] <cjwatson> hmm, the installer writes out such a fstab line
[14:33] <smoser> ok... well, that is possible. However, the only way that I can think of that I  would have posted a log that had a ramdisk log is if it was a ramdisk from a different kernel
[14:33] <cjwatson> why did we never notice this before?
[14:33] <smoser> in which case you'd see ramdisk messages like "can't find /lib/modules-OTHER_UNAME"
[14:33] <Keybuk> cjwatson: why didn't we notice our installer wrote kernels world-writable? :p
[14:34] <smoser> cjwatson, that fstab is written by vmbuilder
[14:34] <tseliot1> pitti: what happens if I call "dpkg-trigger gmenucache" in gnome?
[14:34] <cjwatson> smoser: ok, but partman-target does the same thing
[14:34] <smoser> cjwatson, what is wrong with it so i can fix it?
[14:34] <tseliot1> pitti: err, I meant in kde
[14:34] <Keybuk> cjwatson: OOI, why does the installer put that in fstab?
[14:34] <Keybuk> ignoring the fact it's wrong for the moment
[14:35] <cjwatson> Keybuk: mostly hysterical raisins I expect; although presumably it means that 'mount /proc' works
[14:35] <cjwatson> (in a chroot, say)
[14:35] <Keybuk> cjwatson: but "mount /sys" wouldn't work
[14:35] <Keybuk> and "mount /dev" wouldn't work
[14:35] <cjwatson> granted on /sys; in a chroot, you'd typically want to bind-mount /dev
[14:35] <Keybuk> (I actually have a vague plan to have mount read /lib/init/fstab too fwiw)
[14:35] <Keybuk> I tend to think you want to bind-mount /proc too ;-)
[14:35] <cjwatson> can that become an un-vague plan, and then I can get rid of this with a clear conscience? :-)
[14:36] <Keybuk> sure
[14:36] <Keybuk> but either way, that fstab entry is wrong
[14:36] <Keybuk> security hole style wrong
[14:36] <cjwatson> as in nodev,noexec,nosuid presumably
[14:36] <Keybuk> right
[14:36] <cjwatson> indeed - I'm just changing that now
[14:36] <smoser> Keybuk, where do you see "several seconds of log before mountall is started" ?  are you referring to the "QEMU HARDDISK" kernel message line ?
[14:37] <cjwatson> smoser: ^- you'll want to do the same in vmbuilder - "defaults" -> "nodev,noexec,nosuid" for the /proc line
[14:37] <Keybuk> smoser: that stuff, yeah
[14:38] <Keybuk> smoser: I'm sorry I'm not of help here
[14:38] <smoser> Keybuk, those drivers are absolutely built in... there was another bug that we fixed to get them
[14:38] <Keybuk> but I really don't know what's wrong with your system, any more than you do
[14:38] <Keybuk> and since I don't have access to these systems, and nobody has ever reported this problem with Ubuntu on genuine hardware, I can't replicate it
[14:38] <Keybuk> I think the most interesting comment is Steve's comment #9
[14:38] <smoser> Keybuk, i can remedy the first
[14:38] <Keybuk> in your failed logs, there is no event about sda1 from udev
[14:39] <Keybuk> that's why I asked for the udev log from a failed boot
[14:39] <Keybuk> but you haven't been able to provide that
[14:39] <smoser> if you're truely interested. and "genuine hardware" is kvm guest, so.
[14:39] <Keybuk> smoser: I don't have any machine capable of running kvm
[14:39] <smoser> Keybuk, well the file isn't there... I presumed not written yet in the failed case.
[14:39] <Keybuk> somehow, I have only managed to obtain laptops and desktops without hardware virtualisatio
[14:39] <Keybuk> whoah
[14:39] <Keybuk> back up a sec
[14:39] <Keybuk> sda1 isn't there?
[14:40] <smoser> no
[14:40] <smoser> /var/log/udev.log
[14:40] <Keybuk> confirm for me again
[14:40] <Keybuk> oh, right
[14:40] <Keybuk> so that implies udev didn't start either
[14:40] <qense> pitti: Have you seen <https://launchpad.net/gudev-sharp>? I think that's what required for the Halsectomy of Banshee and the other C# apps. Something to watch for lucid+1?
[14:40] <sladen> vish: http://launchpadlibrarian.net/40957362/light-themes-panel-misalignment.png
[14:41] <smoser> cjwatson, i'll get that remedied in our builds and get bug opened for vmbuilder to soren
[14:41] <smoser> thank you
[14:41] <Keybuk> init: udevmonitor main process (81)
[14:41] <Keybuk> smoser: ^ udev monitor is running
[14:41] <Keybuk> so the log must be there
[14:41] <smoser> so maybe it wasn't flushed...
[14:41] <Keybuk> try /dev/.udev.log
[14:41] <Keybuk> or whatever that damned filename is ;)
[14:41] <smoser> i had to kill the instance then mounted loop back the disk image
[14:41] <pitti> tseliot1: it shouldn't do anything at all
[14:42] <pitti> qense: ah, I didn't; nice
[14:42] <Keybuk> no, don't kill the instance
[14:42] <Keybuk> you need to login to it while failed
[14:42] <smoser> Keybuk, there is no way to do that.
[14:42] <smoser> at least not that i can think of
[14:42] <Keybuk> killing one of your VM instances is like saying you have a bug with the laptop
[14:42] <Keybuk> but you binned the laptop
[14:42] <pitti> qense: perhaps by that time we'll get gobject-introspection working
[14:42] <tseliot1> pitti: so, about bug #522969 , do you think it's a gnome only issue?
[14:42] <Keybuk> you have network I assume?
[14:42] <Keybuk> or a console to them?
[14:42] <pitti> tseliot1: yes, it is
[14:43] <smoser> Keybuk, except i can start it again in seconds.. (regarding the "like a laptop")
[14:43] <smoser> Keybuk, we have serial console read-only
[14:43] <Keybuk> smoser: no, you can start a totally different environment
[14:43] <smoser> network istn' up
[14:43] <Keybuk> ok, so use the serial console then
[14:43] <Keybuk> put a root shell on it
[14:43] <tseliot1> pitti: ok, thanks, I'll just add a "dpkg-trigger gmenucache || true" in the postinst then
[14:43] <pitti> tseliot1: thanks
[14:43] <smoser> Keybuk, well, yeah... its not *so* simple... but i can probably do that.
[14:44] <smoser> not so simple because something else (Eucalyptus) starts the instance, and starts it with kvm console going to a file
[14:44] <qense> pitti: And gudev-sharp is back to zero. Anyway, it would be a huge improvement considering the reluctance of the GTK# maintainer(s) to publish new features for GAPI, it's all kept in trunk.
[14:44] <vish> sladen: ty
[14:44] <Keybuk> at the point you have a root shell, on an instance, that is not running the job - then grab me
[14:44] <Keybuk> and we'll debug it
[14:44] <smoser> Keybuk, thank you.
[14:45] <smoser> then, there is the race condition... hopefully this wont throw it off.
[14:45] <jcastro> Keybuk: that box that had the enter bug has been solid over multiple boots all weekend
[14:46] <Keybuk> jcastro: solidly replicating the bug? :p
[14:46] <jcastro> Keybuk: no, solidly working. :)
[14:46] <Keybuk> heh
[14:46] <Keybuk> I need to amend that bug title
[14:47] <Keybuk> since it actually looks like it happens on the DRM renderer too
[14:48] <smoser> cjwatson, just to be crystal clear: http://paste.ubuntu.com/395650/ is what is "right" for /proc, right ?
[14:51] <psusi> Keybuk: I was thinking... couldn't ureadahead be improved by having it not block everything else until after it finishes reading everything?  i.e. allow the jobs to run in paralell with readahead reading the blocks that the jobs don't need just yet, but will soon?
[14:51] <cjwatson> smoser: yes
[14:51] <smoser> cjwatson, second related question... how far back (dapper?) would those options be valid
[14:51] <Keybuk> psusi: that's how it behaves on SSD
[14:51] <cjwatson> smoser: forever, AFAIK
[14:51] <smoser> ok. thanks.
[14:51] <Keybuk> psusi: on HDD, that is the worst, possible, thing you can do
[14:53] <psusi> Keybuk: only in so far as IF the other tasks try to access the page before readahead has fetched them yet... if you could somehow ( maybe by using IO priorities ) make sure that the other task blocks when this happens until ureadahead gets around to fetching the page in the order IT chose... it would be a speed up
[14:54] <Keybuk> psusi: no
[14:54] <Keybuk> psusi: if *any* task tries to access *any* page on the disk, that will incur a seek
[14:54] <Keybuk> which will turn ureadahead's single one-sweep pass across the disk, into a seek-laden nightmare
[14:55] <Keybuk> and seeks is precisely what ureadahead is trying to avoid
[14:55] <psusi> Keybuk: right... so if you could make sure that the kernel does not service any other requests until after ureadahead finishes.... that would prevent the out of order access causing seeks, but still allow the other tasks to execute as much as they can as they can in paralell with ureadahead
[14:56] <Keybuk> psusi: that's what ureadahead does
[14:56] <Keybuk> but at that point in the boot, all the tasks want the disk
[14:56] <Keybuk> so you have to wait for readahead
[14:56] <psusi> huh?  no?  no other jobs are started until ureadahead finishes
[14:58] <psusi> they want a mix of cpu, wait time, and IO.... they can do the cpu and wait time in paralell with ureadahead, it's just the IO becomes a problem if it is allowed to be intermixed with ureadahead doing it
[14:58] <Keybuk> oh, right, I changed that in Upstart because otherwise you can end up with things running in a different order
[14:58] <Keybuk> but seriously
[14:58] <Keybuk> ureadahead is written how *I* know things work
[14:58] <Keybuk> it wasn't written based on ideas
[14:58] <Keybuk> it was very very heavily tested and tweaked to give the best performance
[14:59] <Keybuk> with extensive use of things like blktrace
[14:59] <Keybuk> but since I wrote it, it's based on what I know
[14:59] <psusi> yes?
[14:59] <Keybuk> so if you have different ideas, by all means, try them out!
[14:59] <psusi> that's why I'm bouncing it off you... ;)
[14:59] <Keybuk> why?
[14:59] <Keybuk> I'm not a human blktrace
[15:00] <Keybuk> I can't listen to your idea and tell you whether it's better or not
[15:00] <Keybuk> I can only tell you why ureadahead is the way it is
[15:00] <Keybuk> if you think I'm wrong, since you're arguing here, you clearly do
[15:00] <Keybuk> then go ahead and actually prove it
[15:00] <Keybuk> bring a blktrace of the boot with ureadahead how I wrote it
[15:00] <Keybuk> and a blktrace of the boot with ureadahead how you'd write it
[15:00] <psusi> to confirm my understanding of how it works right now... the key points being that 1) upstart waits for ureadahead to finish reading before starting other jobs, and 2) it does this because if it didn't, the other jobs would cause out of order IO, right?
[15:00] <Keybuk> psusi: no
[15:01] <Keybuk> psusi: it does this because if it didn't, fsck might happen first, and that can rearrange the disk about a bit on some filesystems
[15:01] <Keybuk> iirc
[15:01] <Keybuk> the upstart ordering is unrelated to "blocking on ureadahead" is that makes sense
[15:01] <Keybuk> ureadahead on HDD already has CPU and I/O priorties set
[15:02] <psusi> ohh... so ureadahead runs before fsck, while the filesystem is still mounted ro?
[15:02] <Keybuk> yeeeees ;)
[15:02] <psusi> so fsck has to wait for ureadahead to finish, and everything else waits on fsck...
[15:03] <Keybuk> yeeeeees ;)
[15:03] <psusi> what if you did readahead in two passes?  first pass gets everything needed up to the fsck, then once fsck finishes, start another ureadahead pass to fetch everything else, while the rest of the jobs start up in paralell?
[15:04] <Keybuk> tried it
[15:04] <Keybuk> slower
[15:04] <Keybuk> seriously
[15:04] <psusi> because the other jobs running in parallel get their IO intermixed with udreadahead, causing out of order reads?
[15:04] <Keybuk> no
[15:04] <Keybuk> because then you're doing two slow passes across the slow disk
[15:04] <psusi> then why?
[15:05] <Keybuk> instead of one slow pass across the slow disk
[15:05] <Keybuk> if pass-across-the-disk costs (say) 7s
[15:05] <Keybuk> doing two doesn't mean you get two of 3.5s
[15:05] <Keybuk> it means you have two of 7s
[15:05] <pitti> geser: I'll commit your recent cdbs upload to bzr
[15:05] <Keybuk> well, in reality, they get a bit faster because you have more read than seek
[15:05] <psusi> eh?  should be more like first pass is 1 second, and second pass is 6
[15:05] <Keybuk> psusi: why?
[15:06] <Keybuk> psusi: have you ever tried any of this stuff?
[15:06] <Keybuk> seriously
[15:06] <psusi> because first pass needs to only read the blocks needed by fsck and things before it, which should be a relatively small amount, and the second pass only needs to read blocks needed by what comes after
[15:06] <psusi> no ;)
[15:06] <Keybuk> the first pass still needs to seek over the disk
[15:06] <Keybuk> still needs to seek between the blocks
[15:06] <Keybuk> still needs to read the blocks
[15:06] <psusi> ohh!
[15:06] <Keybuk> still needs to open files
[15:06] <Keybuk> etc.
[15:06] <Keybuk> passing over a rotational hard drive is not free
[15:07] <psusi> of course... since the files aren't stored on the disk in optimal order, it ends up having to go all over the disk looking for the first pass blocks, skipping over blocks the second pass needs anyhow in the process
[15:07] <Keybuk> exactly
[15:07] <psusi> if we were to pack the files in order though ;)
[15:07] <Keybuk> sure
[15:08] <Keybuk> in fact, if you wanted to do the most useful thing you could, it would be to write an online defrag for ext3 & ext4 that could accept ureadahead pack files as input, and refrig the pack file after the defrag
[15:09] <tseliot1> pitti: two more things: 1) I need to call that dpkg-trigger in the postrm too; 2) I should do the same in nvidia-common in the alternatives library so that the trigger is called when we switch between drivers too
[15:09] <psusi> online would be nice... but offline is workable, especially if you were to build it into an alternate initrd, you could have a grub menu choice to optimize the system
[15:09] <pitti> tseliot1: ok, understood
[15:10] <tseliot1> pitti: I'll work on it
[15:11] <ion> Even nicer would be something that keeps track of *all* usage patterns (without hogging too much resources just for the statistics) and keeps reordering blocks in the background using spare IO time. :-)
[15:12] <psusi> Keybuk: so ureadahead already uses io priority to make sure that IF another job does try to use a page that hasn't been read yet, it will block until ureadahead gets around to it in the correct order?
[15:13] <Keybuk> yes
[15:13] <Keybuk> it's like IO_PRIO_IVANOVA or something
[15:14] <psusi> cool... then I need to try packing the files and splitting the ureadahead into two stages
[15:15] <ion> IO_PRIO_GARYBRANDY
[15:16] <cjwatson> asac: are you going to upload your patch in bug 527720, or are you waiting for review?
[15:17] <cjwatson> (I think the libplymouth2/mountall difficulty is sufficiently far in the past now)
[15:17] <Keybuk> until the next time
[15:19] <Keybuk> so, right
[15:19] <Keybuk> M{aemo,oblin,eego}
[15:19] <tseliot1> :-)
[15:19] <Keybuk> does that mean that they're using Upstart now?
[15:19] <Keybuk> and does that mean that Arjan van der Van has died, so they could do that over his dead body?
[15:20] <tseliot1> heh
[15:20] <cjwatson> what's he got against upstart?
[15:20] <directhex> palm pre uses upstart. it's upstarty!
[15:20] <Keybuk> cjwatson: I'm not sure if it's anything other than "we wrote it"
[15:20] <Keybuk> he doesn't like ureadahead either
[15:21] <Keybuk> as far as we know, Arjan was one of the main instigators of that whole Copyright Assignment flamewar - basically over Upstart
[15:31] <james_w> mvo: do you know if anyone is looking in to the aptitude crash?
[15:31] <mvo> james_w: I can do this today, I know what is causing it
[15:31] <dpm> hey bryceh, I'm trying to set the right project for a bug someone mistakenly filed against the 'ubuntu-translations' project. Is there an upstream project associated with the 'x11-utils' in LP?
[15:33] <james_w> mvo: would you like me to fix it? (If it's quicker for you to point me towards the issue than fix it yourself)
[15:33] <james_w> it will be easier to fix it than to workaround it so that I can do local testbuilds in a clean chroot
[15:34] <mvo> james_w: my "fix" is to revert the 13_screensize patch that is causing it and instead just increase the static buffer
[15:34] <Keybuk> http://www.theregister.co.uk/2010/03/14/canonical_ceo_silber/
[15:34] <mvo> james_w: if you want to look into it, that is welcome of course, I'm pretty sure its a bug in the screensize patch
[15:35] <Keybuk> heh, that's the first article I've read on Jane taking over that references the fact she used to sell nuclear weapons
[15:35] <james_w> mvo: that's what I assumed, but the reports didn't pour in until after a couple of weeks with the new patch
[15:35] <mvo> james_w: hmmm
[15:36] <james_w> no, sorry, the bug report *predates* the latest upload
[15:36] <mvo> oh
[15:37] <mvo> james_w: can you reproduce it?
[15:37] <james_w> yeah
[15:37] <mvo> ok, cool. then you can have it :)
[15:38] <james_w> if LP wasn't timing out on the older uploads I would see if they could have affected it too
[15:38] <james_w> damn :-(
[15:38] <james_w> should be trivial to reproduce
[15:38] <james_w> "aptitude changelog aptitude" should do it
[15:40] <james_w> and now it works...
[15:41] <mvo> works for me too
[15:41] <mvo> (both i386 and amd64)
[15:42] <_UsUrPeR_> Hey all. I'm using apt-mirror to create a local repository on an internal server at my office network. It's become a consensus that we no longer need to have a local mirror of the 8.04 LTS in the office, but I can't figure out how to remove all the old hardy packages. Does anybody know of a good way to purge all hardy packages from my server?
[15:43] <_UsUrPeR_> We've also got a local repo of both 9.10 and 10.04 Alpha, so just deleting the repository directory would require a re-download of ~80 gigs
[15:43] <mvo> james_w: a double dl_complete (cmdline_progress.cc) maybe? delete acqprogress; run twice
[15:44] <mvo> james_w: I wonder if its something with sigc++ that causes the completed signal to be run twice
[15:51] <james_w> mvo: yeah, I can't reproduce anymore. I'll come back to it if I can
[15:53]  * Keybuk hugs cjwatson for converting ssh to Upstart
[15:58] <Keybuk> huh
[16:01] <Keybuk> bwahaha
[16:01] <Keybuk> pitti: I think I just figured out the VT switch bug
[16:04] <Keybuk> one cause of it, anyway :p
[16:05] <Keybuk> if rc 2 finishes before gdm ...
[16:05] <Keybuk> not sure why that would stop X from flipping it back though
[16:11] <preseed> hello i d like to make a full automated install using preseed file but i get a " Syntax error : unable to determine template name "  in /var/lib/preseed/log   i do not find the documentation about it
[16:23] <Keybuk> Mar 15 16:18:53 ratchet init: rc state changed from post-stop to waiting
[16:23] <Keybuk> Mar 15 16:18:53 ratchet init: Handling stopped event
[16:23] <Keybuk> Mar 15 16:18:53 ratchet init: plymouth goal changed from start to stop
[16:23] <Keybuk> err.
[16:23] <Keybuk> whut?
[16:23] <Keybuk> you didn't boot *that* fast
[16:36] <Keybuk> pitti: yup, I am a prize numpty
[16:36] <pitti> Keybuk: you figured it out? rocking!
[16:36]  * Keybuk decides to blame the server team
[16:36] <Keybuk> yeah
[16:36] <Keybuk> gdm deactivates plymouth when it's about to start X
[16:36] <Keybuk> leaving it in an inactive state
[16:36] <Keybuk> then when X is running, gdm tells plymouth to quit
[16:37] <Keybuk> either saying everything was ok (leave the fb alone - X is on it) - or X failed (switch back to vt1, reset console, etc.)
[16:37] <Keybuk> ...
[16:37] <Keybuk> for the server people, when rc2 finishes, we run plymouth quit
[16:37] <Keybuk> which happens to be the exact command that gdm runs to tell plymouth that X failed to start
[16:37] <pitti> ah, haha
[16:38] <geser> pitti: Thanks. Is there a real difference between lp:~ubuntu-core-dev/cdbs/ubuntu and lp:ubuntu/cdbs?
[16:38] <pitti> geser: the second is an auto-import without real history
[16:38] <Keybuk> the on_quit code is clearly wrong anyway
[16:38] <pitti> we don't use the auto-imports for branches where we have history already (i. e. existing Vcs-Bzr:)
[16:39] <Keybuk> since it checks the wrong variable
[16:39] <Keybuk> but this is a niiice race
[16:41] <pitti> Keybuk: so, what we roughly want is the end of rc2 not calling that if we either have gdm started, or will start it eventually (with the latter being pretty fuzzy in upstart terms, I figure)
[16:42] <Keybuk> right, or something
[16:42] <Keybuk> either rc2 should do plymouth quit --unless-deactivated
[16:42] <Keybuk> or gdm should be doing plymouth quit --i-am-x
[16:43] <pitti> ^ but if gdm is very slow, this would still go back to vt1?
[16:43] <pitti> (i. e. if it didn't get to deactivate before rc2 finishes)
[16:43] <Keybuk> sure
[16:43] <Keybuk> but that's ok at least
[16:43] <Keybuk> you'd get a black screen before X of course
[16:43] <Keybuk> but X would flip VT back again
[16:43] <pitti> a "login:" screen, anyway, but yes, it would at least be "more" correct
[16:44]  * Keybuk shakes his fist at ubuntu-server
[16:44] <Keybuk> at least we can tell people how to fix that -> "echo sleep 60 >> /etc/rc.local" :p
[16:44] <pitti> easy, just put gdm into rc2.d *cough* *duck*
[16:45] <Keybuk> that doesn't help in this case
[16:45] <Keybuk> gdm is in the background once the gdm multiplexer is running
[16:45] <Keybuk> the X server inits in the background
[16:45] <Keybuk> always did
[16:45] <Keybuk> the race is against X finishing init, not gdm starting
[16:45] <pitti> Keybuk: I thought gdm would do a plymouth --deactivate thing first?
[16:46] <Keybuk> it does
[16:46] <Keybuk> that changes the meaning of any following "plymouth quit"
[16:46] <Keybuk> the trouble is the "plymouth quit" didn't come from gdm ;)
[16:46] <Keybuk> it came from rc2 ending
[16:46] <Keybuk> so need to disambiguate that
[16:47] <Keybuk> the only thing left then would be rc2 ending before gdm even started
[16:47] <Keybuk> which would be "safe" just fugly
[16:54] <dmart> Wow, you're talking about the precise issue I was just trying to debug
[16:55] <Keybuk> dmart: the "login:" thing?
[16:55] <dmart> Well, Xorg running on vt1 (at the same time as getty)
[16:55] <Keybuk> Xorg shouldn't ever be running on vt1
[16:55] <Keybuk> are you still seeing that?
[16:56] <dmart> It looks like there is a race problem with the way Xorg magically chooses a vt--- but writing a wrapper script, it looks like getty has not launched yet when Xorg starts up
[16:56] <Keybuk> the first X server does not chose a VT
[16:56] <dmart> How not?
[16:56] <Keybuk> it is hardcoded to use VT7
[16:56] <dmart> Well, it uses tty1
[16:56] <Keybuk> see debian/patches/05_initial_server_on_vt7.patch
[16:56] <dmart> Hmmm, when did this patch go in?
[16:56] <Keybuk> dmart: mid-karmic development
[16:57] <Keybuk> dmart: you're still seeing an issue with today's lucid daily?
[16:57] <dmart> I'm using a filesystem from a ~ 2 week old daily-live.  I'll try updating xorg and see if the problem persists
[16:57] <Keybuk> you need to update plymouth, mountall and gdm
[16:58] <dmart> OK, I'll try that
[16:58] <Keybuk> pitti: thinking about it harder, I definitely think that it's gdm's commands that have to change
[16:58] <Keybuk> since once deactivated, nothing else must quit plymouth
[16:59] <Keybuk> X has taken over that VT
[16:59] <Keybuk> so gdm should call something else (or with different flags)
[16:59] <Keybuk> and the ordinary quit command should *fail* with a distinct error code
[16:59] <Keybuk> the upstart pre-stop script should catch that error code, and abort stopping plymouth
[17:00]  * Keybuk can think of a race there too
[17:00] <Keybuk> argh
[17:00] <Keybuk> argh
[17:00] <Keybuk> argh
[17:00] <Keybuk> if plymouth is stopped by rc2 ending
[17:00] <Keybuk> then gdm tells it to quit
[17:01] <Keybuk> the pre-stop runs quit, gets told not to
[17:01] <Keybuk> so runs "start" to change the state
[17:01] <Keybuk> but the "plymouth exiting due to SIGTERM" is still there
[17:01] <Keybuk> I don't know what will happen in that case
[17:03] <bryceh> dpm, xorg-server works as upstream for most x11-* stuff
[17:03] <Keybuk> this could even trigger an Upstart bug
[17:03] <dpm> ok, thanks bryceh
[17:07]  * Keybuk cries
[17:09] <Keybuk> ...and files bug #539175
[17:11] <bryceh> pitti, is there a way to expand apport blobs after the fact?  E.g. bug 539069
[17:18] <kees> Keybuk: I worry when people invoke my name to strike fear into the hearts of unbelievers.  :)  what's the fstab issue?  It didn't jump out at me in the scrollback
[17:18] <Keybuk> kees: default fstab written by the installer has "defaults" for mount options
[17:18] <Keybuk> rather than noexec,nosuid,nodev
[17:20] <kees> Keybuk: I imagine some filesystems need suid and exec though?
[17:20] <Keybuk> kees: sorry for /proc mount options
[17:21] <kees> oh, hrm.  shouldn't we fix that for debug, security, and /var/run too?
[17:22] <kees> (better yet, make "defaults" be noexec,nosuid,nodev heh, which would break _nobody_ I'm sure...)
[17:22] <Keybuk> /var/run is nosuid already
[17:22] <Keybuk> I think it has to have exec and dev for the various nefarious purposes it's used for
[17:22] <kees> yeah.
[17:23] <Keybuk> likewise I vaguely remember it being true for debug too
[17:23] <Keybuk> security - no idea
[17:23] <kees> debug requires _exec_?  that's odd.
[17:23] <Keybuk> kees: something to do with mmap
[17:23] <kees> and does it carry device nodes?
[17:24] <kees> Keybuk: mmap should only require exec if something is very wrong.  (i.e. READ_IMPLIES_EXEC personality)
[17:24] <Keybuk> dunno
[17:24] <Keybuk> these are as you specified them ;)
[17:25] <kees> what?
[17:26] <mneptok> kees: wait, you *don't* like your name invoked to strike fear? does that mean you don't want me carrying my "KEES COOK KNOWS YOUR IP ADDRESS" placard outside Apple Stores?
[17:26] <kees> heheh
[17:26] <Keybuk> kees: we went though the mounted filesystem list ages ago at a millbank sprint
[17:26] <kees> mneptok: well, it's a form of putting words in my mouth.
[17:26] <Keybuk> and you indicated what mount options should be
[17:27] <kees> Keybuk: ah, fair enough.  generally "as strict as possible" is my answer.  :)
[17:27] <Keybuk> none            /sys/fs/fuse/connections  fusectl         optional                          0 0
[17:27] <Keybuk> none            /sys/kernel/debug         debugfs         optional                          0 0
[17:27] <Keybuk> none            /sys/kernel/security      securityfs      optional                          0 0
[17:27] <Keybuk> those may be simply that you didn't know
[17:27] <Keybuk> or maybe they post-date that conversation
[17:27] <Keybuk> I don't think we should mount /sys/kernel/security at all
[17:27] <Keybuk> it's clearly wrong
[17:27] <kees> but noexec on /proc makes sense to avoid re-exec of /proc/$pid/exe
[17:27] <Keybuk> :D
[17:27] <kees> they post-date that conversation
[17:28] <Keybuk> kees: right, I remember that and */fd being the obvious holes
[17:28] <kees> makes AA and SELinux harder to use.  ;)
[17:28] <Keybuk> kees: FEATURE
[17:28] <kees> hehe
[17:28] <pitti> bryceh: hm, expand to the bug doesn't currently work; but you can use apport-unpack on the .crash file to get the files locally
[17:29] <kees> cjwatson: so it's partman that needs adjusting for this?  perhaps have a blanet test for anything with a leading /sys/ in the path to get the same defaults as /sys/ itself?
[17:29] <Keybuk> kees: add them to the list to fix post-lucid
[17:29] <kees> s/blanet/blanket/
[17:29] <Keybuk> kees: partman only writes something for /proc
[17:29] <bryceh> pitti, is there a bug against apport wishlisting this feature?  I run into needing it from time to time
[17:29] <cjwatson> kees: what Keybuk said, and I've already uploaded a fix
[17:30]  * kees goes to figure out how security is mounted these days...
[17:30] <bryceh> pitti, e.g. people behind firewalls
[17:30] <kees> probably my bug
[17:30] <Keybuk> kees: mountall
[17:30] <dmart> Keybuk: I upgraded upstart, mountall, plymouth, libplymouth2, xserver-xorg-core, but I still get my X-on-tty1 problem.  Did I miss something?
[17:30] <Keybuk> kees: so as above
[17:30] <Keybuk> dmart: I have no idea then
[17:30] <pitti> bryceh: you can also file it as a _new_ bug with apport-bug /path/to/file.carsh
[17:30] <kees> Keybuk: ah, you meant that for mountall.  I failed to see context, sorry.
[17:30] <bryceh> pitti, related question, is it possible to file a bug with apport when X is not working at all?  (e.g. entirely from command line)
[17:30] <Keybuk> kees: those are from /lib/init/fstab
[17:30] <kees> Keybuk: not something to fix for lucid, post-beta?
[17:30] <dmart> Keybuk: I'll do a dist-upgrade, maybe some other packages are out of date and causing a problem.  I'll get back to you if that still doesn't fix it.
[17:30] <cjwatson> dmart: it would be generally sane to upgrade everything just to make sure - we're pretty close to beta-1 and the current state is probably more stable than the random thing you had
[17:30] <Keybuk> kees: futzing around with kernel filesystem mount options this late in an LTS cycle strikes me as dangerous
[17:31] <bryceh> pitti, ok
[17:31] <pitti> bryceh: uploading a .crash file to an existing bug already has a bug, let me find it
[17:31] <kees> Keybuk: well, it would break very obviously, if we got it wrong, yes?
[17:31] <Keybuk> kees: not necessarily
[17:31] <dmart> cjwatson: doubtless :)  The archive was temporarily broken when I built this system, so I fell back on an older daily-live
[17:31] <Keybuk> we could break vmware or something
[17:31] <kees> okay, fair enough.
[17:31] <Sarvatt> dmart: did you remove splash from the kernel command line and forget to put it back?
[17:31] <pitti> bryceh: bug 506885
[17:32] <kees> I cannot think of anything immediately under user-control in security
[17:32] <bryceh> pitti, great thanks
[17:32] <ScottK> kees: Could you have a look at qt4-x11 on ia64.  It failed again and I wonder if it's related to your stack protector change.
[17:32] <pitti> bryceh: yes, with apport-bug --save /tmp/foo.apport, move that to a different machine, and apport-bug downloads/foo.apport
[17:32] <kees> same for fuse
[17:34] <kees> ScottK: shouldn't be -- stack protector isn't enabled on ia64, I don't think.
[17:35] <ScottK> kees: OK.
[17:35] <ScottK> doko: ^^^ any other ideas?
[17:36] <doko> ScottK: enoclue ... maybe retry on another buildd?
[17:36] <doko> lamont: ^^^
[17:37] <kees> cc1plus: error: .pch/release-shared/QtCore: No such file or directory
[17:38] <kees> especially since this didn't fail:  g++ -g -Os -I/usr/include/freetype2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2 -Os -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DELF_INTERPRETER=\"/lib/ld-linux-ia64.so.2\" -DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG -D_LARGEFILE64_S
[17:38] <doko> my local build using the uploaded package is still building. let's see if it fails
[17:39] <kees> (who is running qt on ia64?)
[17:39] <\sh> kees: are you working on a (semi) automatic way to include the canonical partner repository during upgrade when using sun java6 packages from formerly multiverse? or at least a way to inform the user?
[17:42] <dmart> Sarvatt: splash is not on my command line at all: I'm bringing up on a new platform.  I'd be concerned if having no splash screen is not supported... ?
[17:43] <kees> \sh: I haven't been, no.  I imagine update-manager will prompt to remove it, which is the upgrade path I'm happiest with.  ;)
[17:43] <cjwatson> slangasek: bug 539182 - seems like your casper fix didn't entirely take?
[17:44] <\sh> kees: well, people won't be amused about that ;)
[17:46] <\sh> kees: especially server people won't be amused, when sun-java6 is gone during dist-upgrade and having tomcat6 ;) (hint on security manager)
[17:48] <cjwatson> \sh: what server people upgrade without reviewing the list of packages to be removed?
[17:48] <cjwatson> and can I make sure none of them ever manage any servers I care about?
[17:49] <cjwatson> this seems fairly basic diligence :)
[17:50] <\sh> cjwatson: no...but as it seems there is no way to "remind" admins, that "this package moved from multiverse to whereever"
[17:50] <mneptok> "Oracle"
[17:50] <cjwatson> I guess that's what release notes are for
[17:50] <ScottK> \sh: It's been removed from Ubuntu.  If they want it, they can figure out what repo to enable.
[17:56] <\sh> cjwatson: +1 BUT when I upgraded to lucid, apt-get didn't tell me: "Dude, listen, this package will be removed, you sure you want it?"
[17:58] <\sh> ScottK: I could agree, when there is an alternative, but regarding the special "tomcat6 + openjdk == no security manager, because it's not opensourced by sun, now known as oracle"...ok, I can agree multiverse is not the section where we push security updates regulary,
[17:59] <ScottK> IIRC open security issues and no patches were a big part of why it got removed.
[17:59] <\sh> but right now, regarding our LTS it would be really cool to "shout out loud that this package moved from multiverse to the partner repository".
[17:59] <cjwatson> that would be a pretty major new feature in apt-get
[17:59] <cjwatson> which has historically been something left to higher-level frontends
[17:59] <cjwatson> better just put it in the release notes, I think
[18:01] <kees> \sh: can you write something up for the release notes?
[18:01] <\sh> cjwatson: regarding our idea to push "puppet" as default server configuration management, I don't think it will execute "do-release-upgrade" but apt-get or aptitude only...but that's really not the point
[18:01] <cjwatson> I'm sorry but server admins can surely read release notes
[18:01] <cjwatson> I have more sympathy for desktop cases
[18:02] <\sh> kees: sure...pointer to the release note sandbox on w.u.c.?
[18:02] <ScottK> \sh: File a bug against ubuntu-release-notes and attach the text.
[18:02] <ScottK> (or just put it in the bug, it doesn't need to be an attachment)
[18:15] <\sh> kees: ScottK: bug #539199 eventually someone who writes native english can fix errors in the text or make it more "bling bling"
[18:17] <zyga> mvo: hello
[18:18] <zyga> mvo: I noticed you have cherry picked bzip2 fix from trunk, I wonder what is the point of having freeze exception for .41 then
[18:19] <mvo> zyga: I leave that to you, I needed to do the upload for the scan.data update
[18:19] <mvo> zyga: if you think we should postpone 2.41 that is fine with me
[18:19] <mvo> zyga: I'm also fine with sponsoring the freeze exception, it contains some nice fixes/additions. either is ok with
[18:19] <mvo> me
[18:19] <zyga> well actually I'd like one thing from you: could you have a look at my bug for the exception and tell me what's missing?
[18:20] <zyga> I read the whole procedure
[18:20] <zyga> but it's a little hazy to me, I think the testing/packaging changes are missing but I'm not sure how to describe that
[18:21] <mvo> zyga: I'm about to leave for the evening, I can mail you tomorrow morning about it, ok?
[18:22] <zyga> sure, thanks mvo!
[18:22] <Aquina> Hey guys! Does someone know how to change a launchpad account password? Is that damn function implemented?
[18:23] <ScottK> Aquina: Ask in #launchpad
[18:23] <Aquina> thx
[18:26] <mvo> thanks zyga
[18:50] <RoAkSoAx> cjohnston, i have a few doubts with dh-apport. If the source packages is called net-snmp and I have the apport hook in debian/net-snmp.apport, it should install the hook in the first binary packages listed in debian/control, correct?
[18:50] <RoAkSoAx> ups
[18:51] <RoAkSoAx> cjwatson, i have a few doubts with dh-apport. If the source packages is called net-snmp and I have the apport hook in debian/net-snmp.apport, it should install the hook in the first binary packages listed in debian/control, correct?
[18:51] <RoAkSoAx> cjohnston, sry wrong person :)
[19:01] <kirkland> pitti: howdy, around?
[19:01] <kirkland> pitti: i noticed some strange desktop behavior in testdrive ...
[19:02] <kirkland> pitti: using the same today's desktop amd64 ISO, in KVM there is no bottom panel in the desktop; while in VirtualBox there is ...
[19:02] <kirkland> pitti: do you have any immediate explanation for the strange difference?  or should I start looking into a bug in qemu-kvm ?
[19:03] <kirkland> pitti: oh, actually, looks like it has to do with resolution ...
[19:04] <kirkland> pitti: if i use the default resolution (1024x768) in KVM, no bottom panel;  if I lower (to 800x600), it shows back up
[19:04] <kirkland> bryceh: do you know anything about that ^ maybe?
[19:04] <bryceh> kirkland, nope
[19:05] <kirkland> bryceh: let me check one more thing ...
[19:05] <kirkland> bryceh: pitti: false alarm, i'm a dope ... it's fine, just off my viewable area
[19:06] <kirkland> alt-mouse FTW
[19:25] <FlyingSpaghettiS> How now brown cow. I'm here to submit my job application! As(potentially) the new leader of your GUI design team, I'm sure I could come to an awesome and inspired revelation of proper element configuration for the new ubuntu. With absolutely no experience in any IT fields(or any other fields), my newly minted internship(with you of course) will pave the way to my worthless associates degree.
[19:26] <jjardon> Hello, I wonder if firefox-gnome-support package could be compiled with Gio support instead GnomeVFS
[19:27] <jjardon> Seems that all GNOME support libraries are optional: https://hg.mozilla.org/mozilla-central/file/69cb1df1cb0f/toolkit/system/gnome/nsGnomeModule.cpp
[19:38] <zyga> I'm trying to boot current amd64 live cd on a system with gtx295 graphics card
[19:38] <zyga> during normal boot the process seems to hang
[19:38] <zyga> and the display shows some mess (black/white blocks + random pixels)
[19:39] <zyga> is there a way to trigger no-fancy-graphics during boot to see what's going on?
[19:39] <zyga> there was a 'safe graphics' mode in karmic, I wonder if something similar is available for lucid too
[19:43] <zyga> hmm, I booted with noslash vga=771 and despite the fact that there was some corruption lucid booted correctly
[19:44] <zyga> now I have x11 with native panel resolution, good!
[20:02] <cr3> hm, .disk/info for 20100315 is "Alpha" for alternate and "Beta" for desktop. not something I expected
[20:04] <cr3> I was expeting the date (20100315) and the official ("Alpha" or "Beta" in this case) where attributes of the build rather than attributes of the particular disk image
[20:04] <cr3> s/where/to be/
[20:09] <cjwatson> cr3: alternate and desktop are two separate builds that often happen to share a build number
[20:10] <cjwatson> so I imagine what happened is that the code was switched over to say Beta between those two daily builds
[20:12] <micahg> cjwatson: would I be able to get a release team ack on a TB3 update for Beta 1?
[20:13] <cr3> cjwatson: I thought the images where just different germinate configurations
[20:14] <cjwatson> cr3: it's a bit more complicated than that
[20:14] <cjwatson> micahg: I'm on the phone right now, but what
[20:14] <cjwatson> 's the bug number?
[20:15] <micahg> bug 530405
[20:17] <cjwatson> cr3: the relevant bit is that they're run at different times of day, though :)
[20:34] <_UsUrPeR_> cjwatson: About preseed: I would like to make an install without a network interface, but I can't seem to find and netcfg
[20:34] <_UsUrPeR_> err whoops
[20:35] <_UsUrPeR_> to finish: but I can't seem to find any netcfg/disable function to stop the scary red screen from appearing
[20:35] <_UsUrPeR_> the screen says "no network interface detected"
[20:35] <_UsUrPeR_> any ideas?
[20:42] <cjwatson> _UsUrPeR_: errors are not in general preseedable; what you need to do is arrange for the installer not to take the path where it encounters an error.  Unfortunately I'm not sure that that's sanely possible in this case (a bug).  I think you might need to rebuild the initrd and stub out netcfg to make it work, I'm afraid
[20:44] <_UsUrPeR_> cjwatson: ok, thanks. I appreciate you checking in to this for me. It's unfortunate that there's no fix for this, but at least I can save myself some time by quitting while I'm ahead.
[20:45] <cjwatson> micahg: I'm OK with the update for lucid; thunderbird is a substantial package that takes a while to build, though, and I think we might be better off arranging for this to be available right after beta-1, rather than taking up a big chunk of buildd time with it in the lead-up to beta-1?
[20:45] <cjwatson> (I realise that it's a security update, but it *is* lucid and there's precedent for holding those off during freezes)
[20:45] <micahg> cjwatson: well, my only concern is it being seeded on xubuntu CD with the old version
[20:46] <cjwatson> beta-1 isn't something that people can sanely install and just leave there anyway; they'll have to continue upgrading
[20:46] <cjwatson> I don't know, I'm just concerned about the 4.5 hour build time on armel
[20:46] <micahg> amel is empty now :)
[20:47] <cjwatson> slangasek, what do you think?
[20:48] <micahg> cjwatson: I'd also like to get a new version of Firefox and Ubufox in if possible
[20:48] <slangasek> cjwatson: looks like we have some idle armel builders right now; I think we can take it in
[20:48] <slangasek> eh, firefox+thunderbird+ubufox?  now I think we're pushing it
[20:49] <micahg> slangasek: next version of Firefox was tagged today which should be the version for release
[20:49] <micahg> slangasek: and ubufox because report a bug in firefox is broke
[20:50] <slangasek> ubufox is cheap to build, that's reasonable to take
[20:50] <micahg> k, Firefox can wait as it's not technically released yet
[20:51] <slangasek> firefox is not so cheap, and hits all images, including the armel ones; I don't want to delay image mastering for that
[20:51] <micahg> slangasek: k, I'll have it ready for upload Friday then :)
[20:51] <micahg> slangasek: but thunderbird's ok?
[20:52] <slangasek> micahg: if you upload it in the next few hours, yes
[20:52] <micahg> slangasek: k, I'll get chrisccoulson_ to do it as soon as he gets back :)
[20:54] <micahg> slangasek: do I need a bug for you to release ack for ubufox?
[20:54] <slangasek> micahg: if Feature Freeze is involved, yes
[20:54] <slangasek> if it doesn't need an FFe, just upload
[20:55] <micahg> slangasek: k, it's just bug fixes
[21:01] <Sarvatt> dmart: if you dont have splash on the command line it starts X on VT1
[21:02] <micahg> does adding ellipses to comply with HIG need an FFe?
[21:02] <lifeless> when is string freeze?
[21:02] <micahg> lifeless: Doc string freeze is next thursday
[21:03] <RainCT> lifeless: .. and application string freeze was two weeks ago (part of UserInterfaceFreeze)
[21:04] <micahg> RainCT: it's my Q if adding ellipses for HIG compliance requires an FFe
[21:13] <micahg> slangasek: can I ask you about the ellipses HIG compliance issue whether it needs an FFe?
[21:15] <RainCT> micahg: I can't answer that question, but maybe you could update the existing translations to add the ellipses there (so that the translators don't need to do that themselves).
[21:16] <micahg> RainCT: they already are in the bzr branch :)
[21:16] <slangasek> micahg: sorry, I don't know what that is - context?
[21:17] <micahg> slangasek: Report a Problem in Firefox doesn't comply with HIG since it doesn't have elipses and it requires further action
[21:17] <ScottK> micahg: Generally ANY U/I changes at this point need to be coordinated through the doc team (U/I freeze exception).
[21:17] <micahg> so there's a fix committed to ubufox trunk
[21:17] <ScottK> The point being to make sure that the docs match what we release.
[21:17] <micahg> k, so it's easier if I don't pull that in at the moment
[21:17] <ScottK> So I don't think HIG or not makes a difference.
[21:18] <micahg> ScottK: k, thanks...maybe I'll skip it for now
[21:19] <slangasek> right, HIG wouldn't get a free pass on FF
[21:21] <ScottK> Units policy doesn't either (just saying)
[21:39] <RoAkSoAx> cjwatson, I have a few doubts with dh-apport. If the source package is called 'net-snmp' and I have the apport hook in debian/net-snmp.apport, it should install the hook in the first binary package listed in debian/control, correct?
[21:42] <kees> lool, persia: so, after I do mk-sbuild --arch armel .... what's the right way to start an instance of armel qemu?
[21:42] <kees> ogra too :)  or anyone else that does this...
[21:46] <slangasek> zul: I've reverted several changes you made to the server-ship seed, you can only seed binary package names and there were several source-only package names that had been seeded (paste, pastescript, pastebin)
[21:50] <slangasek> zul: incidentally, why are these seeded in server-ship, instead of just in one of the 'supported' seeds?  Is there a task that will install them off of the CD?  If not, there's not much advantage to shipping them /on/ the CD
[21:54] <kees> popey: did you ever make parts 2 and 3 of the screencasting screencast?
[22:04] <cjwatson> RoAkSoAx: debian/net-snmp.apport specifically applies to the net-snmp binary package.  If you want to use the first binary package, just call it debian/apport
[22:04] <cjwatson> RoAkSoAx: this is just standard behaviour for debhelper configuration files - it's not specific to dh_apport
[22:25] <kees> asac (and micahg): you mentioned you had to do something funny to remember the firefox "middlemouse.contentLoadUrl" config setting.  is that still in -3.6?  it seems to get repeatedly triggered now that I'm using the "rm compatibility.ini" workaround for loading Greasemonkey.
[22:26] <micahg> kees: idr, but I think I have a fix for the greasemonkey issue
[22:26] <micahg> kees: are you running the daily from teh PPA?
[22:27] <kees> micahg: I'm not, no, since it doesn't have the missing font patch.
[22:27] <micahg> kees: k, well, as soon as I have approval for the patch, I'll drop it in the dailies and probably upload friday
[22:28] <micahg> for the addons
[22:28] <kees> excellent.
[22:28] <kees> micahg: can you put the font patch in too?  :)
[22:28] <micahg> kees: which one, the hinting or LCD?
[22:29] <kees> micahg: which ever makes my eyes bleed with out it.  LCD, I think.
[22:29] <kees> the one I reported and mdeslaur fixed
[22:29] <micahg> kees: that one I have to see why cairo won't take it
[22:29] <kees> micahg: right, but in the meantime, let's get it into firefox.  :)
[22:29] <micahg> kees: can't...
[22:30]  * kees goes back to avoiding discussion of this regression.  :)
[22:34] <RoAkSoAx> cjwatson, oh ok, because in the dh_apport manpage says this: debian/source.apport Installed into /usr/share/apport/package-hooks/source_src.py (where src is the current source package name) in the package build directory of the first package dh_apport is told to act on.
[22:34] <cjwatson> that's literally "source.apport"
[22:35] <cjwatson> "source" isn't a substitution - if it were, it would be underlined like "package" is in "debian/package.apport" :-)
[22:35] <RoAkSoAx> yeah that's why I thought using 'net-snmp.apport' would install as source_net-snmp.py
[22:35] <cjwatson> no, use source.apport for that
[22:35] <cjwatson> if you do that, the apport hook applies to all binary packages from that source
[22:36] <RoAkSoAx> cjwatson, oh ok awesome :) thanks
[22:37] <mdz> I'm having a problem with the netbook daily where the initramfs fails to find the live filesystem
[22:37] <mdz> is this a known issue?
[22:38] <cjwatson> not one I've seen
[22:38] <mdz> cjwatson, oh hi
[22:38] <cjwatson> hey
[22:38] <mdz> the usb stick looks sane enough to me, and I can mount it from the initramfs with no problem
[22:38] <mdz> AFAICT all it does is look for /casper/*.squashfs and that is definitely there
[22:39] <cjwatson> I haven't been testing with USB sticks or with the netbook daily (though I don't think the latter should matter much)
[22:39] <cjwatson> does anything in https://wiki.ubuntu.com/DebuggingCasper help?
[22:39] <cjwatson> it at least has a couple of runes for cranking up debugging
[22:39] <mdz> cjwatson, didn't know about that, i'll have a look
[22:42] <mdz> cjwatson, it's failing the UUID Check
[22:43] <mdz> + cat /conf/uuid.conf
[22:43] <mdz> + uuid=ab72326c-1f54-4d17-b5c0-fd1698c95d27
[22:43] <mdz> + [ -e /cdrom/.disk/casper-uuid-generic ]
[22:43] <mdz> + cat /cdrom/.disk/casper-uuid-generic
[22:43] <mdz> + try_uuid=
[22:43] <mdz> + [ ab72326c-1f54-4d17-b5c0-fd1698c95d27 =  ]
[22:43] <mdz> + return 1
[22:43] <cjwatson> I wonder if usb-creator is failing to copy that?
[22:44] <cjwatson> odd that we wouldn't have noticed before now
[22:44] <cjwatson> was that file present in the source iso?
[22:44] <mdz> cjwatson, looking into it
[22:44] <mdz> the files are there, but 0 bytes
[22:44] <mdz> cjwatson, argh, md5sum -c shows checksum failures
[22:45] <mdz> looks like the stick is to blame
[22:45] <mdz> I thought these things would be more reliable than CD-Rs...
[22:45] <cjwatson> if you ever find a reliable medium, let me know
[22:45] <cjwatson> I guess the ASR motto applies
[22:48] <cjwatson> I do believe my grub2 change worked first time
[22:48]  * cjwatson can die happy now
[22:49] <lifeless> cjwatson: btrfs support
[22:49] <lifeless> ?
[22:50] <cjwatson> I'm not that clever
[22:50] <mdz> cjwatson, I've been noticing the device mounted while usb-creator is working with it; I wonder if that's related
[22:53] <lool> kees: I think you don't have to do anything, it will just work
[22:53] <lool> kees: So just start it as usual
[22:54] <lool> kees: Oh are you trying to start a vm?
[22:54] <cjwatson> ev: ^- didn't you say something about problems along those lines just recently?
[22:54] <lool> kees: I've started this page documenting various tools/approaches https://wiki.ubuntu.com/UbuntuDevelopment/Ports perhaps you'll find the answer you're looking for; it's still rough though
[22:55] <mdz> just tried a microSD card, which has led to squashfs errors from the kernel. yawn.
[22:56] <lifeless> I had a fun thing the other day, a usb drive which has to be formatted raw, no partition table - but usb-creator didn't want to do that
[22:56] <lifeless> would an option for usb-creator be a reasonable feature request?
[22:56] <mdz> lifeless, it can do that, it's just not very obvious
[22:57] <mdz> find the parent device and click the 'format' button
[22:57] <lifeless> mdz: IIRC, when I did that, it gave it a MBR, dos disklabel and a partition within that.
[22:57] <lifeless> I shall try again.
[22:58] <mdz> lifeless, oh, maybe I misunderstood what you meant
[22:58] <mdz> you're saying you don't want a partition table on it?
[22:58] <lifeless> right, it can't be booted of by the netbook I was installing otherwise
[22:58] <lifeless> it needed to be treated like a floppy disk - filesystem on /dev/sdb with first block a boot record
[23:00] <mdz> I just noticed that after clicking "quit" on the usb-creator dialog which says "everything is cool, go forth and boot that sucker" there is actually still a progress dialog in the background and a umount process still running
[23:04] <mdz> I am totally blaming usb-creator
[23:10] <psusi> say... the cpufreq gnome panel applet requires root privs for full functionality... I gather it should get them somehow with policy kit but I have no idea how that works... can anyone point me in the right direction?
[23:19] <zyga> psusi: I remember that some part of that applet had to be setuid to work correctly, that was long time ago though
[23:20] <psusi> zyga, yes, setting the binary to suid will make it work, but shouldn't it use polkit to elevate privs?
[23:20] <psusi> so that normal users can still run it without root privs?
[23:21] <zyga> psusi: it's not using polkit to do it as far as I know, and besides that - polkit is not the answer - you'd still need something running as root
[23:21] <zyga> (something that would change cpu policy)
[23:21] <RAOF> psusi: What you need, IIUC, is to have a dbus-activated setuid process which acutally does the action, then polkit arbitrates access to the setuid process.
[23:21] <zyga> polkit would just authorize you to use that
[23:21] <zyga> right
[23:22] <RAOF> Alternatively, you could patch out the ability to set CPU frequency policy.
[23:22] <psusi> exactly... polkit should be running the applet as root if the user has admin permissions
[23:22] <zyga> psusi: running the applet as root is a bad idea
[23:23] <zyga> psusi: the applet runs as your user
[23:23] <psusi> it has to run as root to modify the settings
[23:23] <zyga> psusi: the applet should request via polkit to access another process that just switches the policy and exits
[23:23] <zyga> psusi: the applet should not modify the settings directly
[23:23] <psusi> hrm... that sounds like a rewrite of the applet
[23:23] <zyga> not really, just split
[23:24] <RAOF> Just the CPU policy setting bit.
[23:24] <zyga> just replace whatever_you_do_to_write_to_cpu_policy_governor_file
[23:24] <psusi> hrm... guess I'll file a bug on that then and echo it upstream
[23:24] <zyga> IMHO writing the "daemon" to do that is trivial, coupling that to dbus and polkit is more challenging
[23:25] <zyga> AFAIR all you have to do is echo to some file in /sys or /proc to alter the CPU governor
[23:25] <RAOF> Is it actually useful, though?
[23:25] <zyga> well, yes, it is
[23:25] <zyga> I remember how angry I was to find out that ubuntu shipped this package without setuid
[23:26] <zyga> for security reasons, this is true but still
[23:26] <RAOF> But what did you actually use it for?
[23:26] <psusi> to manipulate the cpu frequency
[23:27] <RAOF> Yes, that's obvious.    You'd also like a thermal manager.
[23:32] <psusi> crap, just to get it working I set suid on the binary and it crashes trying to load... xsession-errors shows: System exception: IDL:omg.org/CORBA/COMM_FAILURE:1.0
[23:33] <psusi> that used to work, just bad system policy
[23:33] <zyga> psusi: don't do that
[23:33] <zyga> apt-get source that-stuff
[23:33] <zyga> AFAIR there are two parts
[23:33] <zyga> the corba applet
[23:33] <zyga> s/corba//
[23:33] <zyga> the applet - it's loaded via corba but that is not relevant
[23:33] <zyga> and a helper tool that needs to be setuid
[23:33] <zyga> I'm not 100% sure but that's what I remember
[23:34] <psusi> there is a command line tool that you can use to manipulate the settings, but setting it suid didn't let the applet change them
[23:34] <zyga> psusi: reload the applet
[23:34] <psusi> did
[23:36] <zyga> actually, if you google a little, you might find the bug I opened for that issue, I'm not sure where it was exactly, I think that lp.net did not exist just yet
[23:37] <zyga> probably gnome bugzilla IIRC
[23:37] <psusi> I remember a few years back I found in the gnome help file that it could modify the settings and I think I looked into it and found that they install it suid root, but we don't... so I set it suid and it worked... but now making it suid craps out


[12:31] <infinity> doko: Any luck with lpia toolchain madness
[12:31] <infinity> ?
[12:32] <doko> infinity: small steps, but something usable ... not yet :-(
[12:32] <doko> already using all x86 computers I have
[12:32] <infinity> doko: Mmkay... Keep me posted.
[12:32] <infinity> doko: We can find you DC hardware, if you're low on resources.
[12:32] <infinity> doko: If it's just time you need, can't help you there. :/
[12:33] <doko> well, doing more in parallel results in more mistakes ...
[12:33] <infinity> Story of my life.


[12:19] <lanoxx> e can i find the code for the indicator "applet" used in unity?
[12:19] <lanoxx> where can i find the code for the indicator "applet" used in unity?


[07:47] <yigal> what is the approximate size after compiling a stock x86 Maverick kernel (with a few patches)?
[07:47] <yigal> of the source directory
[07:47] <yigal> that is
[07:47] <yigal> ?
[07:49] <yigal> I'm using a 7gb flash drive and I've started to uninstall packages due to the size of the source folder ~3.4gb right now
[07:53] <yigal> I mean my whole Ubuntu install is on the 7gb
[07:54] <yigal> soon the build will be 1/2 of the total disk space, lol
[07:59] <yigal> ok 690mb left
[07:59] <yigal> I already removed evolution, empathy, totem and most other "fluff" to compile this kernel
[07:59] <yigal> this is hardcore, lol
[08:09] <yigal> ok have a great weekend


[20:51] <kaldrenon> I'm getting "failed to fetch" errors on a URL that itsn't in my sources.list or in source.list.d/* - how would I track down where it's coming from?
[23:07] <gelph> So launchpad uses only bazaar version control system?  I saw import from other, but as to normal use, it's only bazaar, right?
[23:09] <TheLordOfTime> last i checked, it was just bzr
[23:09] <TheLordOfTime> but i know import-from-other can import from another VCS system into bzr... but i've never used it
[23:11] <gelph> head seriously warped coming from cvs and moving to svn branching and merging, now I begin again with bzr branching
[23:12] <TheLordOfTime> i came from git :p  equally confusing
[23:12] <TheLordOfTime> i still use git :p
[23:24] <thopiekar> got this recipe: https://code.launchpad.net/~thopiekar/+recipe/kivy-testing
[23:25] <thopiekar> problem here is that in the same branch the debian files are located in another folder so I have to move them into the root
[23:26] <thopiekar> as "run" is not allowed in launchpad.net I tried to nest-part it but it fails.. how can I fix that?


[21:45] <bluesabre> Installed the daily iso today... and noticed that our config isn't properly loaded. I've got Xfce defaults at least for window manager, wallpaper, font anti-aliasing
[21:46] <bluesabre> Anybody else see this? Any ideas what might be the culprit?
[23:34] <bluesabre> I'm guessing /etc/xdg/xdg-xubuntu didn't get read for some reason
[23:48] <JackFrost> Is dbus-x11 installed?


[14:44] <lamont> arges: around?  can I poke you to process bcache-tools/precise-proopsed out of NEW?
[14:44] <lamont> that way, I can test it and confirm it.
[14:48] <arges> lamont: yes
[14:48] <arges> lamont: looking
[14:49] <lamont> ta
[14:49] <lamont> arges: and then there's bug 1515661
[14:51] <arges> lamont: so this works with precise/3.2 or do you need to use the lts-trusty kernel
[14:51] <arges> bcache that is
[14:53] <lamont> bcache needs the kernel module that hasn't been backported to the precise kernel
[14:54] <lamont> which is acceptable, in that we can document taht you have to use hwe-t kernel
[14:55] <lamont> tbf, I haven't actually checked the stock precise kernel.  let me do that for giggles, but I'm 99% certain that it'll tell me to jump in a lake
[14:55] <arges> lamont: so just to be clear, hwe-t works? or you have to use an out of tree module build?
[14:56] <lamont> hwe-t is demonstrated to work
[14:56] <arges> lamont: ok ok
[14:56] <lamont> though it did require me to use 1515661's kernel/initrd
[14:57] <lamont> which actually means that really testing stock precise with any hope of success needs 1515661 to land along with bcache-tools, and a new daily image...
[14:58] <arges> lamont: so ideally for cloud-initramfs-tools we need bug 1236380 to be verified as well and it should cook in -proposed for 7 days
[15:00]  * lamont pokes smoser about that
[15:00] <arges> infinity: ^^^ since you did the acceptance, is this one of those high prio things we should push out sooner than later? cloud-initramfs-tools in precise
[15:00] <lamont> arges: it's a blocker for maas1.9, which will rc2 this week, if I'm understanding things correctly
[15:01] <arges> lamont: ok good to know
[15:02] <arges> i think at a minimum getting bug 1236380 verified should be done
[15:06] <lamont> arges: so... 1236380 is actually "not fixed, but not regressing anything" -- I'll be updating it shortly with what I think is an actual diff
[15:06] <arges> lamont: ok appreciate it
[15:06] <lamont> but I don't know that we need to reject the promotion on that account
[15:07] <lamont> arges: and I've been schooled.
[15:08]  * lamont doesn't actuallyhave anything to test that with, so it's semi problematic
[15:08] <lamont> and I misread the code.
[15:13] <lamont> arges: trying to make a machine that loves it enoug to exercise that code.  as a side note, regression is highly unlikey, in that every trusty cloud boot since early 2014 has been exercising this very code.
[15:14] <arges> lamont: ack. also not sure if some maas people could also verify too. i'd think some arm hardware might run into this issue more frequently?
[15:14] <arges> but then again probably not running precise
[15:14] <lamont> arges: tbf, I am one of the maas people.
[15:15] <lamont> but yeah, seeing what I can see
[15:15] <arges> lamont: ah. : )
[15:43] <infinity> arges: I don't mind it being fasttracked, if they prove they've tested the three bits that changed.
[15:44] <arges> infinity: ack
[15:48]  * lamont finds a laptop that netboots
[17:07] <lamont> arges: and yeah, stupid sd cards shows up as sdb on the both of hte machines I can test with, so no go for my testing.
[17:08] <arges> lamont: ok
[17:08] <lamont> otoh, I'm willing to believe that it's at least no worse than the prior code wrt 1236380
[17:13] <arges> lamont: ok made a note in the bug to please re-open if verification fails. thanks for attempting to verify this one
[17:17] <lamont> ta
[17:19] <arges> lamont: bcache-tools accepted, so once that hits the archive you can verify.
[17:22] <lamont> arges: woot
[17:22]  * lamont looks forward to dropping his ppa and associated hackery from his last test
[17:24] <lamont> arges: will test in several minutes, since I see it released
[18:44]  * stgraber pokes queuebot, there should be two more of those :)
[18:49] <lamont> can I sweet talk someone into letting django-piston3 out of NEW? (xenial)
[18:58] <stgraber> Laney, micahg: updated lxc backport in trusty-backports queue (two cherry-picks from upstream)
[19:37] <micahg> stgraber: looking


[11:20] <telschy> Is it correct: no screen lock after a suspend?
[11:24] <telschy> Hello??
[19:51] <sir_guy_carleton> hello
[19:52] <sir_guy_carleton> i'm trying to install ubuntu mate only on old machine, but on boot i get a bunch of flip flop errors
[19:57] <sixwheeledbeast> how are you installing? have you installed ubuntu before? what sort of errors?
[20:11] <sir_guy_carleton> sixwheeledbeast: i've installed ubuntu mate (last lts) on another machine before
[20:11] <sir_guy_carleton> i'm using a usb stick
[20:11] <sir_guy_carleton> and it's on an old dell inspiron
[20:12] <sixwheeledbeast> so what are these errors? laptop or desktop?
[20:12] <sir_guy_carleton> the laptop
[20:12] <sixwheeledbeast> what model?
[20:12] <sir_guy_carleton> dell insipiron 1525
[20:13] <sir_guy_carleton> note i can get to the install screen and the live envirnoment, it just takes a long time
[20:14] <sixwheeledbeast> I have a 1501 with 16.04lts, the update to 18.04 isn't available get so haven't tried 18.04
[20:15] <sixwheeledbeast> You mention errors but also you can boot?
[20:16] <sir_guy_carleton> yeah
[20:16] <sir_guy_carleton> just slowly
[20:18] <sixwheeledbeast> It maybe running at 100% CPU. can you get top and load avg's up on your live session?
[20:20] <sixwheeledbeast> I can also say now you are likely to run into issues with the Broadcom network drivers. Best to work on Ethernet while setting up.
[20:21] <sir_guy_carleton> hmm, top has load average: 0.00, 0.08, 0.41
[20:21] <sir_guy_carleton> maybe, i've got it connected to ethenet right now anyway
[20:24] <sixwheeledbeast> so it's not running anything at the moment.
[20:25] <sir_guy_carleton> no; i'm think i just running the installer and see what happens from there
[20:26] <sixwheeledbeast> just run through the installer, maybe your USB stick.
[22:14] <mate|72780> oi