[12:20] <bradley> IN: thanks for all the help on getting this bug rolling.  I guess I also curious for a more in depth explanation of your reasoning purely for education
[12:20] <IntuitiveNipple> From what I've read of the upstream kernel.org bug report, they initially (back in 2006) thought it was ACPI but then narrowed it down to the X server, then got confused as lots of other similar reports were attached to the bug, and finally marked it as "insufficient data"
[12:21] <IntuitiveNipple> It'd be good to run a debug kernel on that PC, see what else it reveals
[12:23] <bradley> maybe this isn't important, but when you said you read a post on Fedora forums..I was playing with fedora7 when it came out and didn't have this problem
[12:23] <bradley> Suse, when I played with it for a week or so didn't show this issue either.
[12:24] <bdmurray> bradley: How do you normally shutdown the system?
[12:25] <bradley> normally i shut it down graphically....click the icon that brings up log out, restart, shutdown, suspend, hibernate, etc, and then click shut down
[12:26] <bdmurray> bradley: without logging out though?  It might also be interesting to see what happens if you log out and then shutdown.
[12:26] <IntuitiveNipple> bradley: Can you add the PC's ACPI DSDT to the bug, just in case, with "sudo acpidump -t DSDT > DSDT.aml; tar -cjvf DSDT.aml.tar.bz2"
[12:27] <IntuitiveNipple> bradley: If you need to install acpidump: "sudo apt-get install acpidump"
[12:29] <bradley> lol its "cowardly refusing to create en empty archive
[12:29] <IntuitiveNipple> bradley: when I can find time I'll build a debug-version of snd-hda-intel you can test. What kernel-version are you using day-to-day ?
[12:30] <IntuitiveNipple> bradley: you may need to separate the commands I gave you into separate lines :)
[12:30] <bradley> i tried that as well
[12:30] <Nafallo> sudo -i and then the commands.
[12:30] <bradley> same error
[12:30] <Nafallo> sudo can't > things
[12:30] <IntuitiveNipple> acpidump, is it creating a DSDT.aml ?
[12:30] <bradley> fanafallo: i know that much :)
[12:30] <IntuitiveNipple> Nafallo: it can, and did, I tested it here first
[12:31] <bradley> yeah, it created the aml
[12:31] <Nafallo> when did it learn that? :-)
[12:31] <zul> evening
[12:31] <IntuitiveNipple> bradley: ok, use "tar -czvf DSDT.aml.tar.gz DSDT.aml"
[12:32] <bradley> ok, that worked, ill attach it
[12:32] <IntuitiveNipple> (it does help to specify *what* is being put in the tar) lol *slaps self*
[12:33] <IntuitiveNipple> I was doing some suspend/resume hacking of snd_hda_intel a few weeks ago so that module source-code is still fresh in my mind
[12:34] <IntuitiveNipple> bradley: when I can find time I'll build a debug-version of snd-hda-intel you can test. What kernel-version are you using day-to-day ?
[12:35] <bradley> im using the latest gutsy kernel
[12:35] <bradley> against all warnings i know, but it's stable for me
[12:36] <bradley> bdmurray: before i applied the workaround no shut down worked for me, from desktop, loginscreen or otherwise, after i applied the work around, everything works
[12:36] <IntuitiveNipple> bradley: ok, that makes it easier for me then, I'll just build a debug-version from the git
[12:38] <IntuitiveNipple> bradley: Do you think you could clear  /var/log/kern.log then do a single startup/shutdown procedure (without the workaround script, so it fails to shutdown), and then attach that kern.log to the bug report?
[12:41] <bradley> yeah, can i disable the script through sysctlrc...that's not the right name, but its something like that
[12:43] <bradley> the program that allows me to see and edit what's running on which runlevels
[12:44] <bradley> otherwise ill just delete the scripts and remake them
[12:47] <IntuitiveNipple> bradley: You mean update-rc.d ?
[12:47] <bradley> yeah, i think thats what i meant, but im retarded sometimes.  ill just comment out the line that removes snd_hda_intel
[12:48] <bradley> that should make things not work again, and its much easier to put back to working
[12:48] <IntuitiveNipple> yeah :)
[12:48] <bradley> alright, i'll give it a go
[12:49] <lamont`> (compaq nw840)
[12:49] <lamont`> (compaq nw8440, even)
[12:54] <bradley> IN: ok, added the kern.log
[12:54] <IntuitiveNipple> bradley: I've just skimmed the DSDT for anything obvious, but nothing that stands out.
[12:54] <bradley> what does that imply?
[12:56] <IntuitiveNipple> There's nothing in the way of obvious ACPI DSDT faults apparent
[12:57] <IntuitiveNipple> This kern.log, it only has a boot-up sequence in it. I think the file we need is kern.log.0 - can you check?
[01:01] <bradley> sure, brb
[01:13] <bradley> ok, the kern.log.0 isn't cooperating with me.  i cleared it out and did a reboot etc, but now it's not filling wiht messages
[01:15] <IntuitiveNipple> bradley: ahh... maybe some confusion... kern.log is the logfile the system writes to, but when it 'backs-up' it moves it to kern.log.0
[01:16] <IntuitiveNipple> The kern.log you uploaded appears to have been generated during the start *after* the failed shutdown, so I guessed the log we wanted would be kern.log.0
[01:17] <bradley> that makes sense...hmmmm, ok, let me look around some more
[01:17] <IntuitiveNipple> Maybe do another start/shutdown sequence with a freshly cleared kern.log, and then check what you've got in both files when you restart
[01:18] <bradley> ok
[01:18] <IntuitiveNipple> bradley: hang on a minute....
[01:20] <IntuitiveNipple> I think I might be telling you the wrong log, I'm just looking at a notebook I use for ACPI testing and it looks like kern.log only gets updated during a suspend/resume, not a shutdown!
[01:20] <IntuitiveNipple> oops!
[01:25] <IntuitiveNipple> ha, you ran off before I could finish what I was saying!
[01:26] <bradley> ok a did a clean, shutdown, start, shutdown, start sequence.  kern.log.0 is still empty. kern.log _seems_ to have start, shutdown and start in it
[01:27] <bradley> unless im mistaken
[01:27] <IntuitiveNipple> I had just typed...
[01:27] <IntuitiveNipple> I think I might be telling you the wrong log, I'm just looking at a notebook I use for ACPI testing and it looks like kern.log only gets updated during a suspend/resume, not a shutdown!
[01:27] <bradley> sorry, this bug hunting has me all fired up
[01:28] <IntuitiveNipple> but you went! I'm used to loads of output for suspend/resume - I just assumed shutdown was as prolific! The only shutdown logging I can find is in syslog and its brief to the point of useless
[01:29] <bradley> yeah, now that you say it, kern.log IS all startup
[01:30] <IntuitiveNipple> there's all but nothing in any of the logs, except for 'tty exiting' messages
[01:33] <bradley> well thats disappointing
[01:34] <bradley> though i have to think signifcant progress now be made on this bug
[01:34] <IntuitiveNipple> I'm just digging to see if we can make it more talkative
[01:42] <bradley> by all means, i really appreciate you taking time out to help me with this.
[01:44] <IntuitiveNipple> According to the (convoluted) documentation, we use "sudo sysctl -w variable=value" to control the log-level of klogd, but when I do "sysctl -a" to report all the possible names I can't find a variable that sets the log-level!
[01:45] <mjg59> There isn't one
[01:45] <mjg59> All kernel output will be logged
[01:46] <mjg59> All you can change is whether stuff hits the console or not
[01:46] <IntuitiveNipple> Really? another case of the docs not matching reality! I saw "-c" but that is no good
[01:47] <IntuitiveNipple> Is there a way, without kernel recompiling, to increase the logging during shutdown?
[01:47] <mjg59> Any output from the kernel will be logged until klogd is stopped or the filesystem unmounted
[01:47] <mjg59> If you want more output, then you need to add more output to the kernel
[01:48] <IntuitiveNipple> I thought there was logging of driver-unloading etc., but there's almost nothing
[01:48] <mjg59> We don't unload drivers
[01:48] <IntuitiveNipple> Well, stop them then
[01:48] <mjg59> That's after the root filesystem has been unmounted
[01:48] <IntuitiveNipple> ahhh
[01:49] <IntuitiveNipple> small round spherical objects
[01:49] <mjg59> You can edit /etc/default/halt
[01:49] <mjg59> And set it to "halt" rather than "poweroff"
[01:50] <mjg59> Then if you boot without the quiet option, you'll get any logging onscreen until the machine stops
[01:51] <IntuitiveNipple> The issue was to look for any messages during shutdown for bradley's Toshiba, which needs snd_hda_intel unloaded in order to shutdown cleanly, and it seems to be an X issue, since shutdown is fine if gdm is stopped first.
[01:52] <IntuitiveNipple> anyway, aren't you supposed to be on vacation?!
[01:52] <mjg59> Yes
[01:52] <IntuitiveNipple> can't keep away?
[09:53] <infinity> BenC: Kernel fix didn't happen, I guess?
[10:35] <kraut> moin
[11:00] <amitk_> kraut: did you find a solution to your problem?
[11:01] <kraut> amitk_: not really, i know that it is fixed in 2.6.22. that's why i'll now tryout the gutsy-kernel.
[11:01] <kraut> amitk_: i didn't found the exactly problem, because there were many changes in nfs-client between 2.6.20 and 2.6.22 :/
[11:01] <amitk_> true
[11:11] <kraut> amitk_: do you maintain the ubuntu-kernel?
[11:12] <amitk_> kraut: Not really, I am just a member of the kernel team.
[11:13] <kraut> amitk_: the question is, how long does it take. when i fill in a bug-report, until it is fixed in the feisty-kernel.
[11:13] <kraut> i've also mailed an emploeyee of netapp concerning this, but still waiting on an answer.
[11:13] <kraut> perhaps he could tell me the problem and wich fix is missing in the feisty-kernel.
[11:15] <amitk_> kraut: possibly. So I take it that it's not possible for you to migrate to the Gutsy kernel (in a few weeks after it stabiliizes)
[12:08] <bullgard4> In kern.log I obtain a line "Back to C!" between 'LATE suspend' and 'EARLY resume'. What stands 'C' for?
[12:14] <mjg59> It's a programming language
[12:15] <mjg59> It means that the resume code has transitioned back to the C language section, rather than the bit written in x86 assembler
[12:16] <infinity> It really needs a "Phew, we made it!" in there.
[12:17] <infinity> Every time a PC manages to boot past real mode, I think it's a minor miracle.
[12:24] <bullgard4> Ok. Thank you.
[12:25] <kraut> amitk_: not really, i need the new one for an urgent project :/
[01:41] <kraut> anyone tried out the gutsy-kernel on a x86_64 system?
[01:41] <kraut> it won't boot without any usefull message before it will scan the scsi-bus.
[01:53] <kraut> there is a problem concerning a lsi-logic controller :/
[02:18] <kraut> is it possible to change the magic key to something else then "print screen"?
[02:31] <kraut> lsi-logic is broken in 2.6.22 :/
[02:52] <BenC> infinity, doko: 9.22 being uploaded with fix for lpia build
[02:52] <infinity> Good timing, we were just talking about you behind your back.
[02:53] <infinity> BenC: Is your link fast enough to get it up before cron.daily?
[02:53] <doko> just talking =)
[02:53] <BenC> infinity: it's already done
[02:53] <infinity> Awesome.
[02:54] <BenC> we have a .orig.tar.gz now, so it's just a ~3Meg upload
[02:54] <infinity> Ahh, cool.
[02:54] <infinity> Shows how long it's been since I did a kernel upload. :)
[03:24] <zul> oh goody my wife is up
[03:41] <zul> BenC: ping there is a request to sync rt2400 source from debian should we even bother?
[03:48] <BenC> zul: nope
[03:48] <BenC> reject it as Invalid
[03:49] <zul> BenC: thanks
[04:58] <infinity> Bah, where did Ben go?
[05:14] <lamont> hrm... and -9.22 is in the archive.  sigh
[05:14] <infinity> lamont: Don't worry, there's another upload required ASAP. :P
[05:15] <infinity> lamont: (broken on lpia, which was the whole point for this upload)
[05:15] <lamont> heh
[05:15] <lamont> I expect my change will fix hppa finally (mailed kernel-team ml, etc)
[05:15] <lamont> mind you, testing that will take several hours...
[05:16] <lamont> where several is between 2 and 4
[05:17] <lamont> closer to 2, it appears.. (abicheck of 2nd-and-final kernel failed at 1:55:23)
[05:17] <lamont> so just including it should be fine.
[05:18] <lamont> (it won't be any _more_ broken than what's in -9.22) :-)
[05:19] <lamont> infinity: at any rate, I'll be afk for a bit, feel free to help my patch get from my git tree into the real one.
[05:20] <infinity> lamont: Not sure how much I can do on that front, short of bribing people with hookers and beer.
[05:20] <infinity> And I'm starting to run out of hookers.
[05:20] <lamont> good bribes
[05:20] <lamont> heh.  it's more of a "since you have to turn this for me, pls include lamont's latest. kthxbye"
[05:23] <lamont> and afk
[05:45] <doko> infinity: it fails again for the udebs after fixing the linux-libc-dev header
[05:47] <infinity> doko: Ugh.
[05:52] <kylem> doko, i can debootstrap a lpia chroot now?
[05:53] <kylem> doko, how does it fail?
[05:53] <doko> kylem: yes, see my email to distro
[05:53] <doko> you just need http://people.ubuntu.com/~doko/tmp/linux-libc-dev_2.6.22-9.22_lpia.deb for now
[05:53] <doko> for dev things
[05:54] <doko> make: *** [binary-udebs]  Error 1
[05:54] <doko> kylem: ^^^
[05:54] <kylem> dude.
[05:54] <kylem> not terribly helpful, that.
[06:07] <infinity> doko: You may have noticed some text on your terminal slightly before that error.. :P
[06:07] <doko> dilist=$(dh_listpackages -s | grep "\-di$") && \
[06:07] <doko>         for i in $dilist; do \
[06:07] <doko>           dh_fixperms -p$i; \
[06:07] <doko>           dh_gencontrol -p$i; \
[06:07] <doko>           dh_builddeb -p$i; \
[06:07] <doko>         done
[06:07] <doko> dpkg-architecture: warning: Unknown gcc system type i686-linux-gnulp, falling back to default (native compilation)
[06:07] <doko> [...]  repeated 100 times
[06:07] <doko> make: *** [binary-udebs]  Error 1
[06:07] <infinity> Still running the old dpkg, I see...
[06:07] <kylem> indeed
[06:07] <doko> kylem: better? looks like no udebs are produced, so just copying the config from i386 would be fine (I assume)
[06:07] <infinity> Though, in this case, it's helpful to point out that dpkg-architecture is being run a crapload of times. :)
[06:07] <doko> grep "\-di$" looks suspicious, missing architecture
[06:07] <infinity> dh_listpackages limits to the current arch, I assume.
[06:07] <infinity> Yeah.
[06:07] <infinity> That's precisely what it does, in fact.
[06:07] <kylem> doko, yes. d-i is completely absent.
[06:07] <doko>         dilist=$$(dh_listpackages -s | grep "\-di$$") && \
[06:07] <doko>         [ -z "$dilist" ]  || \
[06:07] <doko>         for i in $$dilist; do \
[06:08] <doko> ok, that works.
[06:08] <doko> kyle: how do I correctly increment the version number? just for producing a correct debdiff
[06:09] <kylem> debian/rules startnewrelease
[06:14] <doko> kylem: if you can commit this, and maybe prepare a new upload, tested that it works on lpia  http://people.ubuntu.com/~doko/tmp/linux-source-2.6.22.debdiff
[06:15] <kylem> 17:06:22 < kylem> doko, yes. d-i is completely absent.
[06:15] <kylem> the correct fix would be to add d-i...
[06:16] <doko> kylem: that can be done later, we just need linux-libc-dev for now
[06:16] <infinity> kylem: Yeah, the lack of d-i was intentional at this point.  BenC asked if I wanted udebs, I said "maybe later, don't care for now".
[06:16] <kylem> er, ok.
[06:17] <kylem> ... it's like a two line addition though...
[06:17] <infinity> (Who knows if we'll ever even build lpia installation media)
[06:17] <kylem> alright. fine.
[06:17] <infinity> Oh, if it's easy and guaranteed to work, just do it, then.
[06:17] <doko> kylem: as you like it, I can test build it here
[06:17] <infinity> Won't hurt to have 'em, just in case.
[06:19] <doko> infinity: it would be nice to have installer and/or live cd's just to offer something for testing
[06:19] <kylem> i'm hoping there are proper sdvs when these cpus become available...
[07:47] <zul> its in there somewhere :)
[07:49] <zul> oh i hate cvs
[07:50] <zul> hey BenC
[07:53] <lamont> zul: the rebase option is at the bottom under 'if you have access to kernel.u.c', not up at the top for others...
[08:05] <bullgard4> What is meant by 'LATE suspend' of my agpgart-intel loadable module's message in kern.log?
[08:06] <mjg59> It's the portion of the driver suspend called after interrupts are disabled
[08:07] <lamont> mjg59: btw, remember how putting the gutsy kernel on my laptop made suspend work?  well, it doesn't now...
[08:07] <bullgard4> mjg59: Thank you very much for explaining.
[08:07] <lamont> somewhere between -5 and -8, -9 also b0rked
[08:08] <lamont> mjg59: is there a writeup anywhere that would give me clues on how to troubleshoot that?
[08:09] <mjg59> lamont: git bisect is probably the easiest
[08:09] <kylem> lamont, go to www.united.com, book a flight to heathrow, underground to kings cross, national rail to cambridge.
[08:09] <mjg59> Except you probably can't, because the kernels are rebased
[08:09] <mjg59> Which means the git history bears no resemblance to the release history
[08:10] <lamont> mjg59: any chance you have a compaq mumble8440?
[08:10] <mjg59> lamont: Nope
[08:10] <mjg59> I've a 6220, but that's previous generation
[08:10] <lamont> yeah
[08:11] <lamont> and smaller.
[08:11] <mjg59> Per-generation, the hardware is pretty similar
[08:12] <lamont> mjg59: bisect could still work for me, although it may be fun to get from the eventually-found commit to the actual commit... :-)
[08:12] <lamont> or if there were any bits that needed to be blacklisted/whatever to get it to work
[08:12] <mjg59> lamont: If it previously worked, then bisect is probably as good as you're going to get
[08:13] <lamont> ye
[08:13] <lamont> p
[08:13] <mjg59> You're just going to have to be handwavy in finding the last "good" kernel
[08:13] <lamont> yeah
[08:13] <mjg59> If we didn't rebase the tree, this would be a lot easier
[08:13] <lamont> why do we rebase the tree again?
[08:14] <lamont> I could see starting a new branch off upstream each time we release, and then merging all our stuff onto that new branch, that'd give us all kinds of good history...
[08:14] <mjg59> Ben finds it easier
[08:14] <mjg59> Whereas I find having to pull into a branch and then merge that murder inducing
[08:15] <kylem> lamont, the commit you want pulled is not in your tree.
[08:15] <lamont> hrmpf.
[08:15] <lamont> heh
[08:15] <lamont> pushing
[08:18] <lamont> pushed
[08:20] <mjg59> BenC: Could we not rebase the tree repeatedly? It makes it *much* harder to figure out whether regressions are due to our code or to upstream
[08:26] <kylem> it won't be rebased anymore now that 2.6.22 is out.
[08:27] <mjg59> kylem: Not even to <IP_ADDRESS>?
[08:27] <mjg59> (Or other parts of the stable branch)
[08:28] <zul> have we actually pulled in <IP_ADDRESS>?
[08:31] <makx> in debian yes :)
[08:36] <zul> nerver mine I answered my own question
[08:36] <zul> ergh
[08:39] <BenC> mjg59: it was pretty easy for me to test that by testing with stock 2.6.22 and with our 2.6.22
[08:40] <BenC> mjg59: in fact, I would argue that it's easier to see if it's us or upstream, considering we are rebased on top of stable 2.6.22 instead of intermixed with it
[08:40] <BenC> s/stable/stock/
[08:41] <mjg59> BenC: But we don't ship a stock 2.6.22
[08:41] <mjg59> What users know is "-5 worked, -7 doesn't"
[08:41] <mjg59> That's easy to map back to a tree that matches the development history, but very difficult to map to a rebased tree
[08:42] <lamont> mjg59: keithp says that one should never use 'git pull', instead one should use 'git fetch' and an appropriate merge
[08:42] <BenC> true, but even mapping it back to proper history wont help much, considering the amount of upstream kernel changes mixed with our uploads
[08:42] <BenC> actually, you can get decent history just looking at the changelog
[08:43] <kylem> keith is just being difficult, pull is just a fetch+merge.
[08:43] <lamont> BenC: creating a 2.6.22-9.23 _branch_ at the time of upload would preserve history for us
[08:43] <lamont> kylem: yeah, but he finds  that the merge is seldom the one he really wanted
[08:43] <mjg59> BenC: Given that the number of bisect jumps you need to do is log2 of the number of commits, it's not really a problem
[08:43] <BenC> lamont: well, it's pointless now since we wont be rebasing anymore
[08:43] <lamont> BenC: for the future, I meant
[08:43] <mjg59> lamont: That doesn't actually solve the problem in any case :)
[08:43] <BenC> lamont: good point, we can definitely do that
[08:43] <kylem> we have a branch, since we have a tag.
[08:43] <BenC> lamont: tags wont work?
[08:44] <lamont> mjg59: it renders it more-solvable, I expect
[08:44] <BenC> right, you can do "git-branch Ubuntu-2.6.22-9.23 Ubuntu-2.6.22-9.23"
[08:44] <lamont> would a tag add a reference to the un-rebased commits?
[08:44] <mjg59> lamont: The tree refers to a different history to the one in my local repository
[08:44] <mjg59> BenC: Tags won't work across a rebase in any meaningful way
[08:44] <mjg59> lamont: So it's impossible to pull/fetch/whatever
[08:45] <lamont> hrm.
[08:45] <BenC> mjg59: but if you're bisecting, then you are building kernels for the user or yourself and you can easily testing stock 2.6.22 vs ubuntu-2.6.22 :)
[08:45] <kylem> Subject: Accepted linux-source-2.6.22 2.6.22-9.24 (source)
[08:45] <BenC> kylem: I never uploaded -9.23
[08:46] <mjg59> BenC: You continue to have issues. It may be an interaction between a new upstream patch and one of ours.
[08:46] <BenC> just so you know :)
[08:46] <kylem> BenC, hence it's still unreleased
[08:46] <mjg59> If a user has a good and a bad commit already (by virtue of knowing which package versions worked), that's going to make the bisect much easier
[08:46] <kylem> blef.
[08:46] <BenC> mjg59: if v2.6.22 works and HEAD doesn't, you can easily rebase between those two points
[08:46] <kylem> coffee.
[08:47] <mjg59> BenC: ?
[08:47] <BenC> mjg59: true, you miss the super rare case where an upstream commit during devel actually interacts bad with one of our patches
[08:47] <BenC> s/rebase/bisect/
[08:48] <mjg59> Well, yes, you can do that
[08:48] <mjg59> But it's not actually going to be significantly faster
[08:48] <BenC> it's not going to be slower either :)
[08:48] <amitk_> lamont: you might be suffering from bug #129226, perhaps?
[08:49] <mjg59> But, as you said, it misses one entire class of problem
[08:49] <amitk_> bug# 129226 even
[08:49] <amitk_> damn.. i can never quite figure out how to trigger the bot
[08:49] <BenC> mjg59: one extremely rare class, as I've never experienced it before :)
[08:49] <mjg59> BenC: I've hit it a couple of times.
[08:49] <BenC> amitk_: it's missing from this channel
[08:50] <BenC> mjg59: either way you do it, it doesn't give you full info
[08:50] <mjg59> ACPI is hard. Shopping time.
[08:50] <mjg59> BenC: Sure it does. One way actually reflects the history that we've published, and the other doesn't.
[08:50] <BenC> mjg59: without rebase, you wont know which patch of ours is interacting badly, and with rebase, you wont know which patch from upstream is the cause
[08:51] <BenC> mjg59: you still miss the info to know which patch of ours is interacting with a commit from upstream...unless I'm missing some detail
[08:51] <mjg59> I mean, in addition to it being a nightmare to remember to fetch into a branch and then use that as origin
[08:56] <mjg59> error: no such remote ref refs/heads/origin.old
[08:56] <mjg59> Ngh.
[08:57] <doko> \o/ 2.6.22-9.24
[08:57] <doko> infinity: wake up call ;-)
[08:57] <kylem> hopefully it builds on more than one flavour of amd64. ;-)
[09:40] <Nafallo> hmm.
[09:40] <Nafallo> sata_nv busted?
[09:40] <Nafallo> since like... feisty?
[09:46] <BenC> Nafallo: worked on my one system, even in feisty
[09:48] <Nafallo> BenC: are you aware if there are any bugs with sata_nv hangs?
[09:48] <Nafallo> starts with: [  438.240000]  irq 7: nobody cared (try booting with the "irqpoll" option)
[09:48] <mjg59> Nafallo: Does /proc/interrupts claim that sata_nv is bound to irq 7?
[09:48] <kylem> ah crap, i'm a muppet. forgot to -mv the abi files to 9.23
[09:49] <Nafallo>   7:       9820     264076    XT-PIC-XT        libata
[09:49] <mjg59> Ok, that's a good start
[09:50] <mjg59> So for some reason, sata_nv doesn't believe that the interrupt was its
[09:50] <Nafallo> I got libata on 5,7,10,11
[09:51] <Nafallo> http://paste.ubuntu-nl.org/32273/ <-- mjg59
[09:52] <Nafallo> I haven't really cared about the statement up until now that my two raptors arrived :-P
[09:52] <mjg59> Nafallo: The rest of dmesg would help
[09:54] <Nafallo> http://home.nafallo.info/bugs/sata_nv.txt
[09:56] <Nafallo> mjg59: feisty running now. same error on the gutsy tribe-3 server iso
[09:56] <mjg59> What's kind of weird is that you don't seem to have anything on the ports connected to irq 7
[09:57] <mjg59> So it's either an irq routing issue (try booting with pci=noacpi) or a sata_nv bug
[09:58] <mjg59> amitk_: Why not just fudge the USB autosuspend code so it only triggers on mass storage and HID class devices?
[09:58] <Nafallo> I think sdf and sdg are on IRQ7, cause those drives died after the error.
[09:59] <Nafallo> also I'm booting with noapic for a reason :-)
[09:59] <mjg59> No, they're on irq 10
[09:59] <mjg59> Why are you booting with noapic?
[09:59] <mjg59> It's quite possible that the board irq routing has never been tested with xtpic
[10:00] <amitk_> mjg59: to keep in sync with upstream. Oliver Neukum pushed a similar patch to GregKH's tree
[10:00] <mjg59> amitk_: But it's likely that there's more devices that are broken
[10:00] <Nafallo> mjg59: the kernel refuse to start telling me to boot with that option :-)
[10:00] <mjg59> And I'm sceptical that autosuspend of most USB devices is actually useful
[10:00] <mjg59> Nafallo: Well, attempting to debug that would be helpful
[10:01] <mjg59> Right now you're passing an option that has a reasonable chance of breaking things in exactly the way you're seeing
[10:01] <Nafallo> mjg59: I'll boot with the debug command next time I restart then. will need to keep the server up until the weekend now though :-)
[10:02] <Nafallo> mjg59: aha. how... evil.
[10:02] <Nafallo> mjg59: so right now it is boot || sata then? ;-)
[10:02] <mjg59> So I suspect there's no problem with sata_nv
[10:03] <amitk_> mjg59: I agree. It's more than likely there are more devices. But how can we be sure that this affects only scanner-type devices?
[10:03] <Nafallo> hmm. oki :-)
[10:05] <mjg59> amitk_: For reference, the only devices Windows suspends are hid, bluetooth and serial
[10:05] <mjg59> (http://www.microsoft.com/whdc/system/bus/USB/USBFAQ_intro.mspx)
[10:05] <Nafallo> mjg59: do you think there would be a difference if I move the cables from ports 1 and 2 to ports 3 and 4
[10:05] <Nafallo> ?
[10:06] <Nafallo> maybe someone on IRQ7 starts caring then :-P
[10:07] <mjg59> Nafallo: Could work, but it would be preferable to actually debug it
[10:07] <amitk_> interesting... mjg59, thanks for the link. I will work on a patch and talk to Alan
[10:08] <Nafallo> mjg59: agreed :-)
[10:12] <mjg59> amitk_: So I strongly suspect that pretty much everything outside those classes has never been tested with autosuspend, and if it works it's more by accident than by luck :)
[10:13] <amitk_> i would agree. I would also suspect that everything out of these classes are not connected to laptops very often
[10:15] <mjg59> Well, other than mass storage
[10:16] <mjg59> But if that's connected it's probably mounted (and therefore in use)
[10:18] <mjg59> amitk_: If you could cc me on the patch, that would be great
[10:19] <amitk_> mjg59: sure
[10:26] <amitk_> mjg59: Just had a thought: would disabling autosuspend be something that should be relegated to userspace? After all there is a sysfs entry to do so.
[10:26] <mjg59> amitk_: It could be, but in that case why have a blacklist in-kernel at all?
[10:27] <mjg59> I think it would make more sense to have a userspace whitelist rather than a "Break my hardware by default" kernel option
[10:27] <mjg59> Given that all we get out of it is a small amount of power saving
[10:29] <amitk_> mjg59: I haven't followed usb-devel, but I would suspect this blacklist is a knee-jerk reaction to solve immediate problems and keep users happy
[10:29] <mjg59> amitk_: I suspect we'll keep users somewhat happier if they don't have to keep sending patches to upstream (either kernel or hal) to make their hardware work :)


[09:09] <hajour> i have a idea for a memory problem with mail
[09:10] <hajour> but like to exchange idea with someone who knows more from the programs attached to mail
[09:14] <hajour> anyone knows wo i have to talk to about that?
[09:20] <leoquant> some providers (email via a provider) limit the  amount of mb 's for email  attachements, goes this mail via your provider?
[09:21] <leoquant> in your case ziggo.nl
[09:23] <hajour> no for someone else
[09:23] <hajour> he got a memory problem worse then me
[09:24] <leoquant> ah, but it is an attachement problem?
[09:24] <hajour> i wonder thats why i want to know more from it
[09:25] <leoquant> i dont know how it goes via gmail
[09:25] <leoquant> (par example)
[09:25] <hajour> he get mail.answer it.but forget he hat answer.then he do it again .and again enz.
[09:26] <hajour> i try to find him.i have heard in chat he have that problem
[09:26] <leoquant> ok
[09:27] <hajour> but i dont now when he is in ubuntu-beginners-offtopic chat
[09:27] <hajour> i thought maybe we can solve it.but i first have to know more information
[09:28] <leoquant> indeed
[09:28] <hajour> thats where i am busy with now
[09:29] <leoquant> so your problem now is to find him? i can take a look to?
[09:29] <leoquant> *where
[09:29] <hajour> his name is paultag
[09:29] <leoquant>  #ubuntu-beginners
[09:30] <leoquant>  #ubuntu-loco
[09:30] <hajour> i have seen his name in ubuntu-beginners-team
[09:30] <hajour> now i have to find out when he is there.
[09:31] <leoquant> that is #ubuntu-locoteams because is the council
[09:32] <hajour> but thanks leoquant
[09:32] <leoquant> oki
[09:32] <hajour> a ok :)thit not know that
[09:32] <hajour> just noticed the problem
[09:33] <hajour> and when i see that my brains go on and on.til i solved it
[09:35] <leoquant> take care hajour, take your time...
[09:35] <leoquant> i am off for (koorzang)
[09:35] <leoquant> christmas carols...
[09:35] <leoquant> larer hajour
[09:35] <hajour> ok have fun leoquant
[09:35] <leoquant> thx!
[09:36] <hajour> later leoquant
[09:36] <hajour> :)
[10:37] <hajour> going off.kids come back out school in about 10 minutes. til later


[00:02] <mup> Bug #1571898 opened: [2.0 beta 2] Fabric's are not created sequencially <MAAS:New> <https://launchpad.net/bugs/1571898>
[02:07] <andywojo> Hi
[02:07] <andywojo> Can I still use MAAS id I don't have access to my DHCP? I.E I don't manage the DHCP in my lab, but still want to use MAAS
[10:33] <mup> Bug #1572060 opened: Cannot add chassis with port <qa-missing> <MAAS:New> <https://launchpad.net/bugs/1572060>
[10:52] <dimitern> roaksoax: this ^^ is a serious blocker for juju
[10:53] <dimitern> oops, not that
[10:53] <dimitern> roaksoax: I meant this bug 1572070
[10:55] <dimitern> huh.. mup's not around..
[10:55] <dimitern> https://bugs.launchpad.net/maas/+bug/1572070
[11:13] <mup> Bug #1572070 opened: MAAS 2.0 cannot link physical device interfaces to tagged vlans, breaking juju 2.0 multi-NIC containers <juju> <MAAS:New> <https://launchpad.net/bugs/1572070>
[11:13] <mup> Bug #1572076 opened:  [UI 2.0b1] Impossible to change subnet CIDR or gateway with instant editing <design> <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1572076>
[14:02] <kevinkga> hi there. I've been tasked with investigating a potential openstack implementation and I was thinking of using ubuntu maas for this too. This needs to eventually be setup in production. Could someone recommend me where to find commercial support for implementing this? e.g. consultancy
[14:08] <rbasak> kevinkga: from Canonical? See http://www.ubuntu.com/cloud/openstack maybe?
[14:15] <kevinkga> Thanks rbasak. It looks interesting. However, there does not seem to be any advertised service to setup OpenStack in our existing datacenter. What's more is that the ubuntu website just advertised Mesosphere DCOS... but I'm confused since that seems to overlap a lot with MaaS
[14:16] <rbasak> kevinkga: http://www.ubuntu.com/cloud/openstack/managed-cloud
[14:17] <rbasak> kevinkga: or, from http://www.ubuntu.com/cloud/openstack, "Get a customised cloud"?
[14:17] <kevinkga> aha! sorry I was being daft (no had enough coffee in me today it seems)
[14:27] <kevinkga> on another note, I'm trying to setup maas in a limited setup to test-drive it. However, after running "sudo apt-get install maas -y" the terminal locks and the last message is:
[14:27] <kevinkga>  > maasserver:0102_candidate_name  > maasserver:0103_candidate_names Killed
[14:27] <kevinkga> any ideas anyone?
[14:30] <kevinkga> the same thing happens on 14.04 running on VirtualBox as well as on 15.10 running on my local machine
[14:34] <rbasak> Anything in "dmesg|tail"? That looks like the OOM killer to me. How much RAM in the machine?
[14:37] <kevinkga> that's quite possible. 14.04 was running in Virtualbox with 8192 RAM. However on 15.10 that's running on my local PC with 32GB RAM and 20GB free at the time that I run it. Let me see if I find anything in dmesg
[14:42] <kevinkga> rbasak, you're right -> [  134.534523] Out of memory: Kill process 10830 (maas-region-adm) score 386 or sacrifice child
[14:42] <kevinkga> Is there a recommended memory setting set for running maas?
[14:43] <rbasak> It seems a bit odd. I don't know of any recommendation but for what it does I'd expect 8G to be enough.
[14:44] <kevinkga> I'll just increase it slightly and see. Thanks a lot for your help today rbasak
[14:44] <rbasak> kevinkga: no problem. Please do file a bug if it seems to need excessive memory.
[14:44] <rbasak> kevinkga: there isn't a ulimit or cgroup preventing it from using your available memory, is there?
[14:44] <rbasak> Though it really should work in the default configuration.
[14:52] <kevinkga> I don't think it's a bug. It might have been other stuff that I had running
[16:43] <roryschramm> hey im having some problems with maas - fresh install of ubuntu 1404 and maas 1.9 from stable ppa - after reboot of server the region and cluster become disconnected - bug 1563483
[23:26] <mup> Bug #1572340 opened: PXE boot fails when two interfaces are managed <cdo-qa> <pxe> <MAAS:New> <https://launchpad.net/bugs/1572340>
[23:32] <mup> Bug #1572340 changed: PXE boot fails when two interfaces are managed <cdo-qa> <pxe> <MAAS:New> <https://launchpad.net/bugs/1572340>
[23:35] <mup> Bug #1572340 opened: PXE boot fails when two interfaces are managed <cdo-qa> <pxe> <MAAS:New> <https://launchpad.net/bugs/1572340>


[00:07] <infinity> ion: Does this mean you'll be sponsoring my uploads and reviewing my patches and such? ;)
[00:10] <ion> infinity: It did from 02:25:49 to 02:26:17 (UTC+3).
[00:14] <infinity> Damnit, I missed my chance.
[00:20] <lynxman> it was such short... but intense piloting
[00:22] <kees> anyone else seeing "debsums: invalid package name" errors?
[00:23] <kees> seems related to doing sums on transitional packages
[00:28] <ion> kees: Yeah. There’s a bug report about it on Launchpad.
[00:28] <ion> Bug #809924
[00:54] <stgraber> kees: debsums might be a bit broken at the moment because of the changes that happened to it to make it multiarch aware. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616066
[00:55] <stgraber> kees: what's in Oneiric is based on a relatively hacky script I wrote back the sprint but I probably missed some corner cases that have been addressed by the newer version of the patch in Debian
[01:00] <kees> stgraber: ah, cool
[01:57] <mynameisdeleted> I'd like to submit artwork to the ubuntu project
[01:57] <mynameisdeleted> whats the process for doign that?
[02:02] <hammma> where can I suggest ideas for the unity project?
[02:15] <sladen> hammma: ayatana-design
[02:17] <sladen> hamma: https://launchpad.net/~ayatana
[02:17] <sladen> hammma: should be a subscribe link at the bottom
[02:19] <hammma> thanks
[05:23] <pitti> Good morning
[05:46] <didrocks> good morning
[06:51] <YokoZar> Is there an environment variable that will set bzr launchpad-login ?
[06:55] <infinity> YokoZar: Setting it with 'bzr launchpad-login' isn't enough?
[06:56] <YokoZar> infinity: meh, I figured I could put it in bashrc along with the long list of other environment variables I have there like BZR_EMAIL
[06:56] <infinity> You could put "bzr launchpad-login whoever" in bashrc...
[06:58] <broder> bzr launchpad-login just sets a variable in ~/.bazaar, right?
[06:58] <YokoZar> for some reason I thought it did something a bit more complex than that, like verify the name somehow
[06:59] <infinity> launchpad_username in bazaar.conf, yeah.
[07:01] <YokoZar> ok then since it's persistent there's no need for environment variable or bashrc messing ;)
[07:01] <infinity> Nope, not if you always have a bazaar.conf.
[07:03] <dholbach> good morning
[07:04] <pitti> hey dholbach
[07:04] <geser> Hi pitti, dholbach
[07:05] <dholbach> hi pitti, hi geser
[07:10] <pitti> hey geser, wie gehts?
[07:22] <geser> pitti: I'm fine. And you?
[07:22] <pitti> pretty well, thanks! a bit in crunch mode due to the late respin for beta
[08:07] <dholbach> Ursinha, happy birthday!
[09:09] <jibel> pitti, where is the code of the apport duplicate finder ? it's doing things that doesn't make sense.
[09:10] <pitti> jibel: it's all in lp:apport, but where exactly depends on the nature of what you are seing
[09:10] <pitti> "seeing"
[09:10] <pitti> jibel: what's an example?
[09:11] <pitti> jibel: we recently added some non-crash dupe things to the ubuntu hook (/usr/share/apport/general-hooks/ubuntu.py); these are fairly new and might cause false positives
[09:12] <jibel> pitti, it marked bug 837503 and bug 837288 as duplicates of bug 837042. In its logic it is probably right but we should probably add rules to say "Don't touch a report that is in this state".
[09:13] <jibel> like don't touch what is triaged
[09:14] <jibel> or also bug 837282 as duplicate of bug 619363, one is a timeout of dbus the other is a dbus service not found
[09:17] <pitti> jibel: right, that DuplicateSignature looks totally inadequate for a manually created bug report
[09:18] <pitti> bdmurray: ^ I think ubuntu.py should only add these for crash bugs perhaps, not for manually filed bugs?
[09:19] <pitti> jibel: so for that I think the code is in /usr/share/apport/package-hooks/source_ubiquity.py
[09:20] <pitti> line 73 ff.
[09:20] <pitti> it sets the DuplicateSignature regardless of the ProblemType
[09:20] <pitti> it shuold only do that for "Crash" and perhaps "Package", but not "Bug"
[09:20] <pitti> bdmurray: ^ do you agree?
[09:22] <pitti> jibel: bug 837288 should keep the DuplicateSignature, though, do you agree?
[09:27] <jibel> pitti, the signature is wrong. It is not the error in the Traceback but from ubiquity syslog, which is not what triggered the crash.
[09:27] <pitti> jibel, bdmurray: first fix: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/oneiric/apport/ubuntu/revision/1834
[09:28] <pitti> bdmurray: can you look into the wrong DuplicateSignature in 837288?
[09:28] <pitti> jibel: right; I meant for these kinds of bugs it makes sense to keep a DuplicateSignature, but not for the other two (ProblemType Bug)
[09:28] <pitti> jibel: I'll remove that faulty master bug from the dup db in a moment
[09:29] <jibel> pitti, agree. for crash reports it makes sense to keep the signature.
[09:30] <lynxman> jhunt_: ping
[09:30] <jhunt_> lynxman: hi
[09:30] <lynxman> jhunt_: hey :)
[09:30] <lynxman> jhunt_: I've been fighting with a bug the last day, very nasty one
[09:31] <lynxman> jhunt_: looks like a race condition in the initrd ramfs when your root or swap are in extended partitions
[09:31] <lynxman> jhunt_: which makes udev not mount properly and you can't boot up
[09:31] <lynxman> jhunt_: in oneiric server
[09:31] <lynxman> jhunt_: bug 818177
[09:32] <jhunt_> lynxman: I'll take a look...
[09:32] <lynxman> jhunt_: adam_g suggested a small patch to /usr/share/initramfs-tools/scripts/init-bottom/udev
[09:32] <lynxman> jhunt_: just want to make sure it makes sense from the foundations side as well
[09:32] <lynxman> jhunt_: thanks :)
[10:17] <infinity> jml: I bet it suspends great, it just fails to resume. ;)
[10:18] <cjwatson> tkamppeter: it's too late to change beta-1 for anything short of an emergency
[10:19] <pitti> tkamppeter: this kind of bug can be fixed perfectly with a  post-installation upgrade
[10:37] <tkamppeter> cjwatson, pitti, OK. Probably beta1 users update regularly anyway, as it is not a final.
[10:37] <cjwatson> yes, I think that can be expected
[11:08] <cr3> is there a debian script or something for a package to modify the configuration file of another package when it doesn't have a convenient *.d directory, ie should be able to add either lines or a section on install and then remove that on uninstall
[11:09] <pitti> cr3: if it's a dpkg-managed configuration file (so-called "conffile"), this is not allowed
[11:09] <pitti> cr3: if it's a non-managed file, there are no scripts for this, as every conffile looks different; the usual approach is to use sed, etc.
[11:10] <cr3> pitti: /etc/sysctl.conf, I'm only writing a convenience optimization package for use in the cloud, not intended for the real archives :)
[11:10] <pitti> cr3: but these things need to be done very very VERY careful; it must never touch a file of an unkonwn/unexpected format, the code needs to be idempotent, etc.
[11:10] <ogra_> cr3, you want /etc/sysctl.d/ instead
[11:10] <pitti> cr3: sysctl.conf is a conffile; what ogra said
[11:11] <ogra_> that can override /etc/sysctl.conf and you only drop a file in place with your package
[11:12] <cr3> awesome, I didn't even notice sysctl.d! I can't remember last time I actually did an ls of /etc, strange :)
[11:13] <cr3> but now I have to modify /etc/postgresql/$version/main/postgresql.conf :(
[11:13] <pitti> cr3: that's not a conffile
[11:14] <pitti> cr3: also, that file isn't guaranteed to exist (there might be more/other/differnet clusters), but as long as it's for a personal package, that's fine
[11:14] <cr3> pitti: yeah, it's personal but I'm still trying to be minimally careful, like not just appending blindly and so forth
[11:50] <bdrung> cjwatson: are you working on a patch for xmms2?
[11:51] <bdrung> oh, now i got the mails. thanks for your work.
[11:55] <cjwatson> bdrung: I'm working on all the remaining libav NBS dependencies (that Fabrice doesn't beat me to)
[11:56] <bdrung> :)
[11:57] <cjwatson> it's just a bit tedious
[12:07] <bdrung> cjwatson: can you give me your patch as real file / attachment? i copied the inline patch and 'patch' complains about it.
[12:12] <cjwatson> bdrung: perhaps easiest to grab it from https://launchpadlibrarian.net/78695385/xmms2_0.7DrNo%2Bdfsg-2build2_0.7DrNo%2Bdfsg-2ubuntu1.diff.gz
[12:12] <cjwatson> minus the debian/control bit of course
[12:28] <Daviey> slangasek: Do you have thoughts on, bug 835625 .. smelling multiarch related.
[12:57] <jibel> pitti, do you still get bug 831884
[12:57] <jibel> ?
[12:57] <pitti> jibel: I didn't notice apport popping up for this
[12:57] <jibel> not  the master, the first report.
[12:58] <jibel> 831884
[12:58] <pitti> jibel: but I didn't do a test case with an existing user account, so there was nothign to migrate
[12:58] <pitti> jibel: ah, no, I don't get 831884 any more
[12:59] <jibel> it is still an issue there with ubiquity 2.7.25
[12:59] <pitti> I tried the beta-1 on the very same machine (Mini 10), plus my workstation (X201), both worked fine
[13:03] <jibel> I tried on an eeepc, same error. another system work fine booted from CD. I'll try from USB.
[13:30] <lynxman> jhunt_: hey sir o/ any feedback on bug #818177?
[13:47] <jhunt_> lynxman: can't recreate the problem myself yet, but the proposed solution sounds reasonable, although maybe we should have some sort of timeout waiting for udev?
[13:48] <lynxman> jhunt_: okay, I'll figure out a patch with a timeout value then :
[13:48] <lynxman> :)
[14:04] <bdmurray> pitti: one issue with using if report['ProblemType'] != bug is bug 712677
[14:22] <Andy80> hi all
[14:23] <Andy80> I've read that Oracle retired their license for distributing their SDK on Linux... does it mean we will be able to distribute only OpenJDK in the Software Center?
[14:24] <pitti> bdmurray: right, we need to fix that
[14:27] <bdrung> cjwatson: uploaded xmms2 to sid. i did more changes: http://anonscm.debian.org/gitweb/?p=pkg-xmms2/xmms2.git
[14:28] <cjwatson> ok, dh_python2 will need an FFe though
[14:30] <slangasek> Andy80: what Oracle has retired is their standing public redistribution license; given that the sun java packages currently available through Software Center are part of the Canonical Partner archive, not part of Ubuntu itself, it's not clear from this whether Oracle will maintain that particular relationship
[14:32] <Andy80> slangasek: ok, so it's a different agreement, not the general one. Thanks
[14:33] <slangasek> Andy80: well, I'm not actually privy to whether Canonical does have a separate license agreement for those packages - but by virtue of the package's presence in partner, I can say there's a direct *relationship*, so they may work something out :)
[14:33] <slangasek> Daviey: thanks, bug #835625 triaged
[14:47] <pitti> stgraber: oh, bfb? I thought that was gone in oneiric now, does 2d still have it?
[14:47] <stgraber> pitti: it's still called bfb (as in the file) but that's now the dash launcher
[14:47] <pitti> jibel: trying a zh_CN install with the oneiric desktop CD now; which one is simplified Chinese, the third-last or second-last in the language list?
[14:49] <pitti> stgraber: ah
[14:49] <jibel> pitti, this one 中文(简体)
[14:49] <slangasek> the simpler one, obviously! :)
[14:49] <pitti> jibel: ah, it does look a tad simpler, doesn't it
[14:49] <pitti> jibel: merci!
[14:49]  * pitti now trying to do a "blind" install
[14:50] <stgraber> pitti: anything in particular you want to test?
[14:50] <pitti> jibel: still curious that I don't see it when I create a chinese user in a running system, or in the live session
[14:50] <stgraber> pitti: I just did a chinese test install for Edubuntu
[14:50] <pitti> stgraber: bug 771510
[14:50] <pitti> stgraber: and the two related ones for two other indicators
[14:50]  * pitti retitles the bug
[14:50] <stgraber> pitti: ok, I have an installed chinese system here, let me have a quick look
[14:50] <pitti> bug 771510
[14:51] <pitti> stgraber: some indicators show "Empty Label" in them
[14:51]  * pitti figures out how to select US keyboard layout
[14:51] <stgraber> "Label Empty" actually
[14:52] <pitti> ah, right; bug updated
[14:52] <stgraber> session/me, sound and date all have the problem
[14:52] <pitti> yeah, seems everyone gets it but me..
[14:52] <pitti> I'm currently doing a clean test install with zh_CN right from the start
[14:53] <pitti> seems it doesn't happen in live session or post-install
[14:53] <stgraber> ouch, and seems like we also have some font problem (might be related
[14:53] <pitti> ah, with the "guess your keyboard layout" button I was able to find US :)
[14:53] <stgraber> pitti: default chinese keyboard is US
[14:55] <stgraber> pitti: http://www.stgraber.org/download/unity-chinese.png
[14:55] <stgraber> that doesn't look too good :)
[14:55] <pitti> whee
[14:55] <pitti> I didn't get that
[14:56] <pitti> after jibel's latest post I'm beginning to think it's a broken locale setting
[14:56] <stgraber> for some reason I didn't get that in the live session either, only on the installed system
[14:56] <pitti> stgraber: do you mind to post the output of "locale" to that bug, plus ~/.profile and /etc/default/profile ?
[14:56] <stgraber> pitti: and you'd be right, locale is wrong
[14:56] <pitti> if it is locale, then it'll also explain why I didn't get it with a test user
[14:56] <stgraber> pitti: I have zh_CN not zh_CN.UTF-8
[14:56] <pitti> as control-center sets it right
[14:56] <pitti> accountsservice, I mean
[14:57] <pitti> stgraber: I bet that's it; it's getting an invalid LC_CTYPE and chinese $LANGUAGE
[14:57] <stgraber> restarting session with the right locale
[14:57] <stgraber> everything looks good now
[14:58] <pitti> ok, so we should just attach the wrong files; my install is almost through, will do it afterwards unless you beat me to it
[14:58] <stgraber> ok, so I guess that bug should be changed to: "/etc/default/locale set to zh_CN instead of zh_CN.UTF-8 when installing in Chinese"
[15:00] <stgraber> pitti: attached the screenshot and /etc/default/locale to the bug
[15:01] <stgraber> I guess this will need re-assigning but not sure to what, localechooser?
[15:03] <stgraber> pitti: it very well might explain bug 838845
[15:03] <pitti> stgraber: very probabl
[15:03] <pitti> e
[15:03] <pitti> stgraber: I updated the bug and will add a few dupes
[15:06] <pitti> stgraber, jibel: ok, reproduced here as well; I updated the bug and duped the others
[15:14] <pitti> Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell
[15:14] <pitti> (freeze lifted, go wild)
[15:14] <pitti> didrocks: ^ you might fancy uploading unity-2d
[15:15] <didrocks> pitti: ah nice, I'm preparing the next release of unity-2d with the unity one right now :)
[15:25] <tkamppeter_> pitti, It looks like that LP has a problem with the two s-c-p uploads approved at once. It seems that it has picked the older one, 1.3.6+20110824-0ubuntu2 instead of 1.3.6+20110831-0ubuntu1.
[15:25] <pitti> tkamppeter_: it should have accepted both
[15:26] <tkamppeter> pitti, See https://launchpad.net/ubuntu/+source/system-config-printer, which shows the old version and https://launchpad.net/ubuntu/+source/system-config-printer/+changelog which includes the new version.
[15:27] <tkamppeter> pitti, I got two accept e-mails, but the one for the old version came after the one for the new version.
[15:27] <pitti> tkamppeter: the latter page shows unpublished sources, too; all is well
[15:30] <tkamppeter> pitti, yes I can access the newer version's page through a link on the changelog page.
[15:30] <cjwatson> don't worry about mail ordering
[15:31] <slangasek> if both are accepted, the higher version will win
[15:31] <cjwatson> just leave it an hour or so and everything will sort itself out
[15:34] <tkamppeter> OK, thanks.
[15:38] <bdmurray> superm1: Did you see my patch in bug 766160?
[16:05] <qmr> Why is empathy the default IM client?
[16:28] <hallyn> how come /dev/mqueue is not mounted  by default on an ubuntu system?  Just obsolete?
[17:00] <kirkland> jml: ping
[17:00] <jml> kirkland: hi
[17:00] <kirkland> jml: i'm not able to reproduce https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/838807
[17:00] <jml> kirkland: ah, ok.   I can't log out right now though, and it seems fine on the first login after booting (which this is)
[17:04] <cjwatson> -rw-r--r-- 1 cjwatson cjwatson 0 2008-08-20 14:14 /home/cjwatson/.ecryptfs/auto-mount
[17:04] <kirkland> hmm, is there any chance that subsequent logins are short circuiting the pam stack in lightdm?
[17:04] <slangasek> twitch?
[17:06] <kirkland> jml: one more thing ...  could you try with ssh?
[17:06] <kirkland> jml: ie, logout of your desktop, and then ssh in/out repeatedly, and see if it's automounting/unmounting
[17:06] <kirkland> jml: i just tried that with an encrypted private, and ssh logins seem to be behaving properly
[17:07]  * kirkland logs out to test this
[17:10] <jml> kirkland: ok. sure. sorry for delay.
[17:10] <jml> umm
[17:10] <jml> I need something to log in with.
[17:12] <kirkland> jml: ssh?
[17:12] <kirkland> jml: if you're running an ssh server there, you can drop to a tty, login as root or another user, and ssh jml@localhost
[17:12] <jml> kirkland: ahh, right.
[17:12] <kirkland> jml: i just logged in/out 10x times with a test user and an encrypted private directory, with no luck reproducing the problem
[17:12] <jml> kirkland: ok. will try that.
[17:13] <kirkland> jml: do a mount | grep ecryptfs in between logins
[17:13] <kirkland> jml: to see if you're getting unmounted properly
[17:13] <jml> ok
[17:14]  * jml tries.
[17:20] <kirkland> jml: hmm, I'm just not reproducing this
[17:20] <tgm4883> jdstrand, ....
[17:21] <jandrusk> Really? Dead link off of "Create" section of developer.ubuntu.com? http://developer.ubuntu.com/create/qt/
[17:21] <superm1> bdmurray, yeah but i don't have access to sponsor it until next week.
[17:21] <jml> kirkland: so I tried logging out, but I need to reconfigure my SSH server :)
[17:21] <superm1> it looks fine to me though
[17:22] <jml> kirkland: give me a bit longer.
[17:22] <jml> kirkland: when I log in on the tty as jml, I get an error.
[17:22] <barry> @pilot in
[17:22] <kirkland> jml: np;  i'll get this solved for you, but we'll need to work together a bit to triage it, since I'm not reproducing it
[17:22] <jandrusk> It's the last link on the left on 'QT creator'.
[17:22] <jml> kirkland: but I think it's the one in the paste in the bug report
[17:23] <kirkland> jml: are you in your desktop now?
[17:23] <jml> kirkland: yes.
[17:23] <kirkland> jml: okay, give me a couple of pastebins ...
[17:23] <kirkland> jml: ll $HOME/.ecryptfs/
[17:24] <kirkland> jml: and
[17:24] <kirkland> jml: ll $HOME/.ecryptfs
[17:24] <jml> kirkland: http://paste.ubuntu.com/679942/
[17:25] <jml> kirkland: going to try the SSH thing again now.
[17:26] <kirkland> jml: hmm, okay, i do see one aberration
[17:26] <kirkland> jml: minor, but let's try this ...
[17:26] <kirkland> jml: echo "$HOME/Private" > $HOME/.ecryptfs/Private.mnt
[17:26] <kirkland> jml: ie, set your private mountpoint
[17:27] <kirkland> jml: i think that should default to $HOME/Private, but it's possible that it's not doing so for you?
[17:27] <jml> kirkland: ok. done that. Will log out and log in again.
[17:27] <kirkland> jml: k
[17:29] <jml> kirkland: no joy.
[17:29] <jml> kirkland: want me to try the SSH thing, now that I have a properly configured server?
[17:29] <kirkland> jml: okay ls -alF /dev/shm/ecryptfs-jml*
[17:30] <jml> kirkland: -rw------- 1 jml root 2 2011-09-01 18:28 /dev/shm/ecryptfs-jml-Private
[17:30] <jml> kirkland: but this is while it is mounted
[17:30] <kirkland> jml: cat /dev/shm/ecryptfs-jml-Private
[17:30] <jml> 1
[17:31] <kirkland> jml: okay, good
[17:31] <kirkland> jml: yeah, try ssh
[17:31] <kirkland> jml: you can even do it in your desktop session
[17:31] <kirkland> jml: just ssh in and out of localhost
[17:32] <jml> kirkland: ssh works while I'm in desktop session (thing shows up as mounted).
[17:32] <jml> kirkland: shall I try outside of desktop session?
[17:32] <kirkland> jml: ecryptfs-umount-private
[17:32] <kirkland> jml: make sure it gets unmounted
[17:32] <kirkland> jml: mount | grep ecryptfs
[17:33] <kirkland> jml: and then try in and out of ssh a couple of times (3?  4?  5?)
[17:34] <jml> kirkland: http://paste.ubuntu.com/679951/ (line 25 is when I umount)
[17:35] <kirkland> jml: ooh, so you can reproduce it with ssh alone?
[17:35] <kirkland> jml: dpkg -l ecryptfs-utils
[17:35] <jml> kirkland: apparently so. although I notice that with SSH I don't get the warning about keyctl_search, which I *do* get when I do a tty login after first desktop logout
[17:36] <jml> ii  ecryptfs-utils      90-0ubuntu1         ecryptfs cryptographic filesystem (utilities)
[17:36] <kirkland> jml: okay, do: keyctl list @u
[17:36] <kirkland> jml: this should show 2 keys in your keyring
[17:36] <kirkland> jml: well, 2 if you're encrypting filenames
[17:36] <jml> no, only one.
[17:36] <kirkland> jml: 1 if you're not
[17:37] <jml> I don't know if I'm encrypting filenames. I chose the option on install some three years ago :)
[17:37] <kirkland> jml: wc -l $HOME/.ecryptfs/Private.sig
[17:37] <kirkland> jml: :-P
[17:37] <kirkland> jml: if that wc is 1, then you're not
[17:37] <kirkland> jml: if it's 2, then you are
[17:37] <jml> 1
[17:37] <kirkland> jml: or, ls $HOME/.Private
[17:37] <kirkland> jml: and if you see normal filenames, then you're not encrypting filenames
[17:38] <jml> kirkland: right. they are all there.
[17:38] <kirkland> jml: if you see: ECRYPTFS_FNEK_ENCRYPTED.FWYkiiM.WVXtxUQ5kMZ3hnYV7a7TNI7Ya0xUZWDbvgdLrupba-Nlw.EU--
[17:38] <kirkland> jml: then you are :-)
[17:38] <kirkland> jml: okay, good
[17:39] <jml> kirkland: so, keyctl list @u has one key. Are there details there that you would like to see?
[17:39] <kirkland> jml: no need
[17:40] <kirkland> jml: okay, can you get it back to the point where you reproduce the problem, and then see if keyctl list @u shows 1 key?
[17:40] <jml> hmm. by "reproduce the problem", do you mean, say, in an ssh session?
[17:41] <kirkland> jml: sure
[17:41] <kirkland> jml: reproduce is "ssh in, enter password, but ~/Private is not mounted"
[17:42] <kirkland> jml: also, pastebin "md5sum /etc/pam.d/*"
[17:43] <jml> kirkland: http://paste.ubuntu.com/679960/
[17:45] <kirkland> jml: oooh, your /etc/pam.d/common-auth and /etc/pam.d/common-password differ from mine
[17:45] <kirkland> jml: could you pastebin those two files?
[17:45] <jml> kirkland: sure.
[17:45] <jml> http://paste.ubuntu.com/679966/
[17:46] <jml> http://paste.ubuntu.com/679968/
[17:47] <jml> kirkland: have 1 key under ssh
[17:47] <jml> oh
[17:47] <jml> but when I remount the thing I have two keys
[17:47] <kirkland> jml: oh ho ho, that's interesting, that gives me an idea
[17:48] <kirkland> jml: -auth   optional                        pam_smbpass.so migrate
[17:48] <kirkland> jml: that's inconsequential here
[17:48] <jml> also, the numbers are slightly different
[17:48] <jml> "1000    0" for one, "1000   1000" for the one that appears after mounting
[17:48] <jml> ok
[17:48] <jml> kirkland: sorry, I don't quite grok the "-auth" line.
[17:49] <kirkland> jml: oh, i just looked at your minor pam differences, and it's just an smbpass thing, which should have nothing to do with this
[17:49] <jml> ah right.
[17:50] <kirkland> jml: okay, so those two numbers are uid and gid, and that shouldn't matter here
[17:50] <kirkland> jml: but you're saying sometimes you have 2 keys in there, and sometimes 1?
[17:50] <jml> kirkland: when ~/Private is mounted, I have two
[17:50] <jml> kirkland: otherwise, 1
[17:50] <jml> kirkland: but maybe that's because I've been using the interactive command to mount it? /me really doesn't know. Not sure what it has on first login
[17:51] <kirkland> jml: okay, when private is mounted, could you give me the output of "mount | grep ecryptfs" ?  you may choose to fuzz the sig hex numbers, as these are hashes of your keys
[17:51] <kirkland> jml: i'm think i'm on the track here
[17:52] <jml> /home/jml/.Private on /home/jml/Private type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=XXXXXXXXXXX)
[17:53] <kirkland> jml: okay, take a mental note of the true value of your ecryptfs_sig=XXXXXXXXXXX
[17:53] <jml> got it.
[17:53] <kirkland> jml: now, do whatever you do to reproduce the problem (ie, get it to not auto mount)
[17:53] <kirkland> jml: and before mounting do your keyctl list @u
[17:53] <kirkland> jml: see if that hex key id is in the list
[17:54] <kirkland> jml: if i understand you correctly, there will be 1 and only 1 key in your list, and it won't be ecryptfs_sig=XXXXXXXXXXX
[17:54] <jml> kirkland: correct.
[17:54] <kirkland> jml: then do ecryptfs-mount-private
[17:54] <kirkland> jml: enter your pw, see that private mounted, and now keyctl list
[17:55] <kirkland> jml: and you get two keys in the list
[17:55] <kirkland> jml: which includes the necessary ecryptfs_sig=XXXXXXXXXXX
[17:55] <jml> kirkland: correct again.
[17:55] <kirkland> jml: okay, i have an idea of what's wrong
[17:56] <kirkland> jml: see line 46 of /usr/bin/ecryptfs-mount-private ... I need to simulate that in pam_ecryptfs.c
[17:56] <kirkland> jml: okay, give me a little while to get this reproduced and tested;  i'll put a package in a ppa for your testing
[17:56] <kirkland> jml: thanks for your patience
[17:56] <jml> kirkland: thank you for helping me debug this
[17:57] <jml> kirkland: or, umm, the other way around.
[17:57] <jml> kirkland: anyway, I'm grateful :)
[17:57] <kirkland> jml: :-)  yes, thank you
[17:57] <kirkland> jml: how much longer until your EoD?
[17:58] <jml> kirkland: I'm an hour past it.
[17:58] <kirkland> jml: okay, it might be on the morrow for you then
[17:58] <jml> kirkland: but I'll be around online most of the evening.
[17:58] <kirkland> jml: cheers, though, you'll have a ppa package waiting for you
[17:58] <jml> kirkland: ok, thanks. :)
[17:58] <kirkland> jml: okey doke
[18:12] <pdtpatr1ck> Question .. what's the preferred method for building a package.. there's dkpg-buildpackage -rfakeroot .. there's fakeroot dpkg-buildpackage -F .. there's debuild -S -sa and then sudo pbuilder build <package_version.dsc>
[18:20] <infinity> pdtpatr1ck: Any of those except for "fakeroot dpkg-buildpackage".
[18:20] <slangasek> pdtpatr1ck: debuild is a better interface than dpkg-buildpackage for developer use cases; fakeroot never needs to be specified manually becuase it's a default; what infinity said; and use of debuild vs. pbuilder has more to do with your workflow than whether one is a "preferred method".
[18:21] <infinity> pdtpatr1ck: "dpkg-buildpackage -rfakeroot" will only use fakeroot during the bits where it needs to (and debuild, pbuilder, and sbuild will all call dpkg-buildpackage in that same manner)
[18:21] <slangasek> if you already have a dsc, you're not going to be running 'debuild -S -sa', so the last two are orthogonal
[18:21] <pdtpatr1ck> Great .. much appreciated guys
[18:22] <infinity> slangasek: Is it sad that even though I know debuild is easier and less typing, muscle memory dictates that I still type "dpkg-buildpackage -rfakeroot -uc -us -S" every time?
[18:22] <infinity> slangasek: Worse still, because -rfakeroot is the default now, and I still type it.
[18:23] <infinity> Silly fingers.
[18:26] <pitti> kirkland: no, I switched to full $HOME encryption a few cycles ago
[18:26] <pitti> kirkland: yeah, I think I saw it sometimes; seems to be some kind of race condition or mis-counting sessions
[18:35] <slangasek> infinity: you're losing valuable seconds of your life that way!  best to just let the autobuilders do it all for you
[18:41] <infinity> slangasek: *glare*

[18:44] <pitti> infinity: "bzr bd" !!!11!
[18:45]  * infinity packs up his toys and goes home.
[18:45]  * pitti is still a bit grumpy about debhelper claiming 'dh', a command that nobody ever types into a shell
[18:46] <infinity> I imagine you'll get over it.
[18:46] <infinity> Besides, I type it in shells.
[18:46] <infinity> dh --no-act can be handy.
[18:47] <pitti> still, it's so un-Huffman-y
[18:48] <pitti> infinity: but anyway, I think you already LARTed me for my collection of aliases :)
[18:48] <infinity> You were a math major turned programmer, weren't you?
[18:48] <pitti> no, just a lazy typer :)
[18:48] <infinity> And I may have.  It sounds like the sort of thing I'd make fun of.
[19:23] <smoser> hey all. i'm looking at trying to find a solution for bug 838968 .
[19:24] <smoser> i'm wondering if there is any way suitable for that a daemon could avoid polling to see if all of a list of network interfaces are up and have IPs assigned to them.
[19:24] <smoser> s/suitable for that/suitable for ubuntu boot where/
[19:25] <hallyn> smoser: wasn't SpamapS working on an event for that?
[19:26] <smoser> hallyn, you're funny.
[19:26] <smoser> its broken :)
[19:26] <smoser> and i want to fix it.
[19:26] <stgraber> too bad upstart can't react to netlink activity yet...
[19:27] <hallyn> don't suppose there is a udev uevent when an address is defined?
[19:28] <smoser> polling is probably *really* light, but it just seems dirty.
[19:30] <hallyn> stgraber: are you thinking NETDEV_CHANGENAME?
[19:30] <slangasek> smoser: I think it's a bug in dhclient and/or ifupdown
[19:31] <smoser> its by design in dhclient
[19:31] <slangasek> yeah, I think the design is wrong :)
[19:31] <stgraber> hallyn: yeah, didn't remember the name though :)
[19:31] <DoctorPepper> hi guys !!!
[19:32] <slangasek> smoser: is there a reason you think it's correct for dhclient to background itself before it's gotten a response from the DHCP server and applied it?
[19:33] <slangasek> I think this is a bad design that only exists to work around historic limitations, but maybe I'm missing something
[19:33] <stgraber> hallyn: there's also NETDEV_CHANGEADDR but that might be for the mac address but maybe NETDEV_CHANGE would work then (haven't played with these in a while, just had to google for them again :))
[19:33] <smoser> slangasek, i dont have a good reason.
[19:34] <slangasek> stgraber: ^^ perhaps you have an opinion there
[19:34] <smoser> but even if i did, it in that bug info, it seems like ifupdown is going on immediately as opposed to waiting 60 seconds.  although in attempts to reproduce that outside of boot, i can't see it.
[19:35] <slangasek> ifupdown is going on immediately because dhclient has backgrounded and ifupdown has no channel by which to detect that the interface isn't actually up
[19:35] <stgraber> smoser: any reason we don't simply put a script in /etc/dhcp/dhclient-exit-hooks.d ?
[19:35] <smoser> slangasek, when run after boot, it doesn't do it immediately, dhclient holds around until it gets an IP address.
[19:36] <slangasek> stgraber: because ifupdown and networkmanager already emit events when interfaces are "up", and we should fix *that* to work as intended instead of adding more layers
[19:36] <smoser> i have the luxury of working on a system where the driver is apparently bad and a dhcp request is taking like 45 seconds, so i know this :)
[19:36] <slangasek> stgraber: since ifupdown and network-manager still have to have them for the static interface case
[19:37] <smoser> slangasek i just assumed that the static interface case was more straight forward. is it not?
[19:37] <slangasek> smoser: I did see another bug report recently about *statically* configured interfaces getting the up event emitted before the driver was ready to tx/rx - maybe you have the same issue?
[19:37] <slangasek> smoser: er, from upstart's perspective static vs. dynamic is (and should be) the same model
[19:37] <smoser> stgraber, so, saying theres a hooks dir there, how would you tie that all together to ?
[19:38] <DoctorPepper> chrisccoulson: i need your  help  , i am trying to build  globalmenu-extension for installing on a non ubuntu distribution (archlinux) , but  when running autoconf  i get the following error : build/autoconf/acwinpaths.m4:44: error: defn: undefined macro: AC_OUTPUT_FILES when the build fails
[19:38] <smoser> slangasek right, i agree it should be the same.
[19:38] <stgraber> smoser: as slangasek said before, it's probably not a good idea to add yet another hook, but otherwise a workaround would have been to change the ifupdown script not to send the event when doing dhcp and add a hook in dhclient to send the event when it gets an ip
[19:38] <chrisccoulson> DoctorPepper, you need autoconf2.13
[19:39] <chrisccoulson> i'm sure you already asked me that a while ago, and i gave the same answer ;)
[19:39] <smoser> stgraber, right... and then i' dhave to have another upstart job that ran on if-really-up, and determine if all interfaces were up in *that* and fire the event.
[19:41]  * stgraber starts liking NM for that ;) at least we have one piece of software starting everything and that knows the state of all NICs
[19:42] <stgraber> smoser: yeah, that'd get even more of a mess than what we currently have...
[19:42] <DoctorPepper> about 6 month ago but back then  i was impossible to build  it since i was using  fedora  the whole appmenu infrastructure  wasnt avalaible
[19:42] <smoser> yes.
[19:42] <smoser> but it would give me a solution
[19:42] <smoser> which i need
[19:42] <smoser> :)
[19:43] <DoctorPepper> chrisccoulson: i got another error : ./allmakefiles.sh: line 104: ./toolkit/toolkit-makefiles.sh: No such file or directory
[19:43] <DoctorPepper> what should ido ?
[19:44] <smoser> slangasek, how much would you hate me if i did something like that? if it was clearly marked as "the only consumer of 'is-really-up' events is 'static-networking-up.conf', DO NOT USE IT YOURSELF"
[19:45] <slangasek> smoser: a lot :P
[19:45] <slangasek> smoser: that's a lousy workaround - fix the real bug
[19:46] <smoser> do you really think "fix the real bug" is even an option for 11.10 ?
[19:46] <slangasek> ifupdown shouldn't say the interface is up until it's up; whatever is causing it to say it's up before it is is a bug
[19:46] <slangasek> yes
[19:46] <smoser> changing dhclient to not bacakground itself would be seemingly invasive at this point.
[19:46] <chrisccoulson> DoctorPepper, looking in the README file would be a good start
[19:46] <slangasek> I disagree.  We're not making dhclient not background itself, we'd only be changing *when* it backgrounds itself.
[19:47] <stgraber> smoser: is dhclient being called with -d?
[19:47] <stgraber> smoser: if so, that's your bug
[19:48] <smoser> stgraber, i dont thin it is. but i think you're reading the man page wrong.
[19:48] <smoser> -d just says "never background"
[19:48] <stgraber> wasn't the manpage but yes I read it wrong ;)
[19:48] <smoser> i did the same thing
[19:49] <DoctorPepper> chrisccoulson:  i worried about one thing   i see  two option  disabling both ogg and web  would this affect the ability  to play ogg and web video on the browse
[19:49] <chrisccoulson> DoctorPepper, no, they have no effect at all
[19:50] <chrisccoulson> the build system is copied straight from firefox, so those build options just stop you depending on them
[19:50] <smoser> SpamapS, ^ slangasek says "make it work right".
[19:50] <SpamapS> smoser: so is dhclient backgrounding itself too early?
[19:50] <chrisccoulson> DoctorPepper, in fact, the build system is basically from https://launchpad.net/mozilla-build-system ;)
[19:51] <DoctorPepper> ok thanks
[19:51] <smoser> SpamapS, so i think there are 2 issues.  1, by design dhclient is not what we'd like.
[19:51] <smoser> 2. i swear i'm seeing ifupdown emit the interface immediately, but i can't see how.
[19:53] <slangasek> where is it said that this is by design in dhclient, btw?
[19:54] <slangasek> in fact, dhclient has a '-nw' option
[19:54] <slangasek> which we should avoid using :)
[19:55] <slangasek> (and we're not, in either ifupdown or NM - so dhclient daemonizing before IP is acquired is certainly a bug)
[19:55] <SpamapS> slangasek: it daemonizes after 60 seconds I believe
[19:55] <smoser> yeah... so maybe i'm having old daemons in my head.
[19:56] <smoser> i know it used to do this "no ip found for XX seconds backgrounding"
[19:56] <slangasek> right; and that's not a sensible thing to do with a modern init system
[19:56] <smoser> and actually, i can verify that right now on a system not connected . if i 'sudo ifup eth1' then it *does* return and dhclient is in daemon mode afterwards
[19:57] <stgraber> are we sure it's dhclient daemonizing when it shouldn't and not ifupdown starting it in the background to start with (I see quite a few fork() in ifupdown's code)?
[19:57] <slangasek> not sure at all
[19:58] <smoser> i'm not usre.
[19:58] <smoser> then *it* would have to be performing the "wait for a little while".  i can test it easily on my unconnected eth1
[19:59] <slangasek> you can run dhclient directly with the same options as ifupdown does, check the behavior?
[19:59] <smoser> yeah. thats what i was going to do.
[20:00] <slangasek> what's the full dhclient commandline it uses, btw?  I only have ifupdown-managed dhcp on Debian machines handy, not Ubunut
[20:00] <stgraber> smoser: can you try: killall dhclient3 ; ifconfig eth0 <IP_ADDRESS> ; dhclient3 eth0; ifconfig eth0?
[20:00] <stgraber> smoser: I just did it a few times here and I always get an IP when dhclient returns
[20:01] <SpamapS> I only see two fork's in ifupdown's code
[20:01] <slangasek> stgraber: yes, but in your case you *are* getting an IP so that's a racy test :)
[20:01] <DoctorPepper> is anyone from the appmenu team here ?
[20:01] <slangasek> more interesting is to see what happens when you aren't
[20:01] <smoser> slangasek, ok. i verified.
[20:02] <smoser> time sudo dhclient3 -e IF_METRIC=100 -pf /var/run/dhclient.eth1.pid -lf /var/lib/dhcp3/dhclient.eth1.leases eth1
[20:02] <smoser> that comes back in 1 minute and 0 seconds and change
[20:02]  * slangasek nods
[20:02] <smoser> and syslog shows
[20:02] <smoser> Sep  1 16:01:35 mabolo dhclient: No DHCPOFFERS received.
[20:02] <smoser> Sep  1 16:01:35 mabolo dhclient: No working leases in persistent database - sleeping.
[20:03] <smoser> and dhclient on eth1 still running per 'ps'
[20:03] <slangasek> so there's a built-in timeout of 60 for dhclient
[20:03] <smoser> right.
[20:03] <slangasek> I wonder if we can set that to -1
[20:04] <slangasek> or if the timeout is fine and we just need to fix the behavior *when* it times out
[20:04] <SpamapS> "To run force dhclient to always run as a foreground process, the  -d flag  should be specified. "
[20:04] <slangasek> we don't want it to always run as a foreground process
[20:04]  * SpamapS notices a bug in the man page. :)
[20:05] <SpamapS> -1 for a timeout would mean what though?
[20:05] <DoctorPepper> can anyone tell me why   installation of ubuntu on lvm encrypted partitions dont boot ?
[20:06] <smoser> SpamapS, no.
[20:06] <slangasek> SpamapS: that it would wait forever for a server instead of the current behavior, which is that it waits for 60 seconds and then *backgrounds anyway* as if it had succeeded
[20:06] <smoser> slangasek is wanting it to background when and only when it gets a connection.
[20:06] <SpamapS>        The -1 flag will cause dhclient to try once to get a lease.  If it fails, dhclient  exits  with  exit  code
[20:06] <SpamapS>        two.  In  DHCPv6  the -1 flag sets the max duration of the initial exchange to timeout (from dhclient.conf,
[20:06] <SpamapS>        default sixty seconds).
[20:07] <SpamapS> Sounds like thats what you want.
[20:07] <slangasek> right - devil's in the details.  What does "try once" mean here?
[20:07] <slangasek> does it mean it will never try to renew?  that it will only send out one request packet?
[20:07] <SpamapS> DoctorPepper: this is for discussion of development of Ubuntu. You may want to try #ubuntu if you're talking about a stable release, or #ubuntu+1 if you're trying this on oneiric.
[20:09] <DoctorPepper> SpamapS: actually  i tried it  on both 10.04 , 11.04 and oneric  always the same results  failure to boot
[20:10] <hrw> apparmor messages should rather not appear in dmesg - right?
[20:10] <stgraber> -1 seems to do what we want. It tries until it reaches the timeout, when it does it exits with exit 1. If it gets an IP before the timeout, it'll go in the background and renew it as usual
[20:10] <kirkland> jml: fixed!
[20:10] <kirkland> jml: package pushed to ppa:ecryptfs/ppa
[20:10] <kirkland> jml: but i've reproduced the problem and tested the solution here locally
[20:10] <slangasek> SpamapS, stgraber: my testing concurs, -1 does seem to DTRT at least for the cases of reliable and non-existent dhcp servers.  I don't know about an intermittent one, though
[20:11] <kirkland> jml: i'm confident enough that I'm just going to push
[20:11] <slangasek> stgraber: did you test to make sure it will retransmit the requests?
[20:11] <smoser> we may want to bump the timeout on it too.
[20:11] <slangasek> hrw: apparmor is a kernel lsm, so it will log in dmesg
[20:12] <SpamapS> it seems to just skip the daemonization step
[20:12] <smoser> 60 seconds is reasonable, but if its not blocking, then it might as well be longer.
[20:12] <stgraber> slangasek: what I tested is the behaviour with link and no DHCP (waited a minute and died), with link and dhcp (got an IP went in the background) and with an existing lease (renewed it)
[20:12] <stgraber> smoser: I wouldn't change that timeout as it's likely going to affect NetworkManager too
[20:12] <hrw> slangasek: thx
[20:12] <smoser> stgraber, so can you test no link, start it, plug in link, what happens.
[20:12]  * hrw -> sleep
[20:12] <slangasek> smoser: well, would anything else in the boot sequence wind up blocking indefinitely if we raised the timeout?
[20:13] <slangasek> and is that a good or bad thing?
[20:13] <smoser> plug in link after ~ 30 seconds or so, to make sure that dhclient is re-transmitting its requests if the first dont go through.
[20:13] <slangasek> SpamapS: "seems"?  it still daemonizes here on successful lease, which is what we want
[20:13] <SpamapS> slangasek: with the failsafe boot, boot happens 30 seconds after 'filesystem' no matter what.
[20:13] <stgraber> can we set the timeout on the command line so we don't have to change it for everyone?
[20:14] <stgraber> smoser: it's an LXC container, the "no link" case is a bit of a problem to implement ;)
[20:14] <slangasek> stgraber: how about the "DHCP server not running yet, gets started in the middle" case?
[20:14] <SpamapS> slangasek: right, on receiving a lease it always daemonizes. "onetry" mode just skips the daemonization after reaching the initial timeout.
[20:14] <slangasek> SpamapS: right - 'swhat we want
[20:14] <stgraber> slangasek: that I can try
[20:15] <slangasek> so, have we analyzed this to death now? :)
[20:15] <stgraber> slangasek: works fine
[20:15] <SpamapS> it only takes 4 people to analyze it
[20:15] <SpamapS> :)
[20:16] <smoser> but this is good.
[20:17] <smoser> SpamapS, and i think i ssee the flaw in our /etc/network/if-up.d/upstart logic.
[20:18] <smoser> we are reading /var/run/network/ifstate for "is interface up".  (ie, just checking that the interface is in there).  I think that ifupdown is pupulating that immediately.
[20:18] <smoser> populating it immediately even.
[20:19] <SpamapS> That would be.. unfortunate, but makes sense.
[20:19] <slangasek> heh, that's true
[20:19] <SpamapS> So instead of trusting that, being in there means its "up" .. we have to additionally check that it has the configuration intended?
[20:19] <SpamapS> god I hate ifupdown's code
[20:19] <smoser> SpamapS, well not really. we can just make our own
[20:20] <smoser> that only is populated on successful bringup
[20:20] <stgraber> SpamapS: bah, it's just a big manpage that happens to have C in it (and some other things) ;)
[20:20] <smoser> hm... but races
[20:20] <SpamapS> stgraber: you forgot the bit that turns "defn" to C
[20:20] <SpamapS> and the bit that turns nowebm to "defn"
[20:21] <smoser> can that perl script compile this conversation into working code ?
[20:21] <stgraber> ;)
[20:22] <SpamapS> so  yeah, looking at the code, I think its adding it to say "I've got this don't try to do it"
[20:23] <SpamapS> not to sya "this is up"
[20:23] <SpamapS> so we can simply replace that with our own state managed by if-up.d/upstart ...
[20:23] <smoser> thats what i said.
[20:23] <SpamapS> smoser: setting bootytraps?
[20:23] <smoser> but we have to avoid racy-ness.
[20:24] <SpamapS> smoser: I'm prepared to simply ignore /var/run/network/ifstate entirely
[20:24] <smoser> i'm prepared to do that too
[20:24] <smoser> but its not as simple
[20:24] <SpamapS> smoser: what I need is "what should be up" (ifquery gives us that) and then a canonical source of what *is* up.. initctl list gives us that.
[20:24] <smoser> as you can't just "echo $IFACE" >> /var/run/my-really-up-state
[20:25] <slangasek> initctl list seems like a good choice
[20:25] <slangasek> alternatively, you could use 'pidof ifup' + /var/run/network/ifstate
[20:25] <SpamapS> the race isn't as important since this is forward only..
[20:25] <SpamapS> if something comes up, then goes down again, we don't really care.. thats not something we can solve.
[20:25] <SpamapS> what we want is the moment at which they were all "up"
[20:25] <smoser> i dont follow that.
[20:25] <slangasek> if ifup is still running for an interface you care about, and it's not the *current* interface, then you're not ready yet... oh, except those can race each other, so ignore this.
[20:26] <slangasek> initctl list is the best
[20:26] <SpamapS> right, because start/running is only achieved after ifup --allow auto $INTERFACE returns
[20:26] <slangasek> well, no
[20:27] <slangasek> it's achieved *within the upstart hook* :)
[20:27] <smoser> network-interface (eth1) start/running
[20:27] <slangasek> oh
[20:27] <slangasek> right
[20:27] <slangasek> thinking of the wrong event, sorry
[20:27] <smoser> that is from my system, where eth1 is unplugged
[20:27] <SpamapS> initctl list | grep '^network-interface .* start/running$'
[20:27] <SpamapS> smoser: thats because ifup didn't error out
[20:27] <SpamapS> it should have
[20:28] <SpamapS> because we're calling dhclient wrong, it didn't
[20:28] <smoser> right.
[20:28] <smoser> ok.
[20:28] <slangasek> you could have an instantiated job that does nothing but catch the net-device-up event
[20:28] <SpamapS> one issue, do we want it trying ifup.. forever?
[20:28] <slangasek> and then enumerate *those* jobs with initctl list
[20:29] <smoser> why another layer of indirection, slangasek ?
[20:29] <SpamapS> slangasek: thats sort of what the if-up.d/upstart script is already.. so it wouldn't be too far fetched to simply move all of this into that job.
[20:30] <slangasek> smoser: because there's no other way currently that lets you count interfaces as "up" that's not racy
[20:30] <smoser> i think its ok.
[20:30] <slangasek> SpamapS: you couldn't move *all* of it into that job... you couldn't move the part that emits the event you're trying to catch ;)
[20:31] <smoser> in the if-up.d of all of them you just say "are all auto interfaces up" (other than self) and emit if that is the case.
[20:31] <slangasek> you have no way to determine that's the case
[20:31] <slangasek> that's the bit that needs solved
[20:32] <slangasek> /var/run/network/interfaces is an imperfect proxy
[20:32] <slangasek> it tells you "ifup has been called", not "the interface is up"
[20:32] <smoser> oh, and initclt list was not sufficient ?
[20:32] <smoser> fyi: network-interface (eth3) start/running
[20:32] <slangasek> yes, it's not sufficient
[20:32] <smoser> eth3 is not in interfaces at all
[20:33] <slangasek> consider two interfaces, eth0 and eth1
[20:33] <slangasek> both are detected in parallel, so ifup is launched for each
[20:34] <slangasek> dhcp runs in parallel on each, finishes within a split second of each other
[20:34] <slangasek> so /etc/network/if-up.d/upstart is called for each interface; emits the 'net-device-up' event, which doesn't directly start any uniquely identifiable jobs that will show up in 'initctl list'
[20:35] <slangasek> at this point, you'll see this output in initctl list:
[20:35] <slangasek> network-interface (eth0) start/starting
[20:35] <slangasek> network-interface (eth1) start/starting
[20:35] <slangasek> you can ignore your *own* interface, but what about the other?
[20:36] <slangasek> if you say "it's starting, that's close enough", you risk emitting the event before the interface is actually up
[20:36] <slangasek> if you say "it's starting, we'll do nothing and let the *other* script handle it when it starts", you risk both scripts doing the same thing and nobody emitting the event
[20:37] <SpamapS> slangasek: indeed, race found.. so we should sync these up...
[20:38] <SpamapS> wait-for-state to the rescue?
[20:38] <Laney> cody-somerville: can you vote on chase and brian please?
[20:38] <SpamapS> hrm no.
[20:38] <slangasek> right, so one way to do that is to instantiate a job for each interface, at a point in this script before it does the initctl check
[20:39] <slangasek> has to be done synchronously, of course, not using -n
[20:39] <slangasek> but the last of the interfaces to do so is guaranteed to see all interfaces as up
[20:40] <slangasek> (...then you just have to deal gracefully with our event being emitted multiple times, which you already have to do)
[20:41] <jml> kirkland: testing now
[20:41] <smoser> slangasek, we were avoiding multiple times with mkdir /var/run/network/static-network-up-emitted . but maybe im' missing something.
[20:41] <kirkland> jml: thanks!
[20:42] <kirkland> jml: man this bug has a bunch of dupes
[20:42] <slangasek> smoser: ahh yes
[20:42] <SpamapS> slangasek: hm.. I'm trying to remember if emitting a sync event returns when the goal is changed to start, or when the jobs have entered start/running
[20:42] <slangasek> smoser: a perfectly cromulent semaphore :)
[20:42] <smoser> exactly
[20:43] <SpamapS> if the former, then we still have the race.
[20:44] <SpamapS> Well except now we don't care about start/running .. just start/
[20:44] <SpamapS> so I think that will work
[20:44] <slangasek> true
[20:44] <SpamapS> since we're really just using upstart as a synchronous place holder
[20:45] <jml> great. I have to get a libreoffice update at the same time :)
[20:45] <SpamapS> which makes me wonder if we shouldn't just use /var/run/network dirs for simplicity sake...
[20:45] <smoser> SpamapS, i couldn't avoid a race there either.
[20:45] <slangasek> SpamapS: right, and does that seem reasonable or should we just do it all in /run :)
[20:45] <SpamapS> jml: if we never updated openoffice, I would never have an excuse to check facebook. ;)
[20:45] <slangasek> rather than making init do it for us
[20:45] <smoser> how would you avoid the race?
[20:46] <slangasek> smoser: by having this script write to /run/network, instead of starting an upstart job
[20:46] <jml> SpamapS: heh.
[20:46] <smoser> when you ccheck "are all other interfaces done" you risk a race of 2 jobs saying "nope, the other isnt done yet"
[20:46] <jml> SpamapS: sadly, I get plenty of chances.
[20:46] <SpamapS> smoser: create the dir, /var/run/network/ifup.$INTERFACE , then ls /var/run/network/ifup.* .. compare with /etc/network/interfaces list..
[20:47] <slangasek> SpamapS: why a dir instead of a file? in this case no collisions
[20:47] <SpamapS> smoser: as long as you only check after you've updated yours, you are ok
[20:47] <SpamapS> Whoa
[20:47] <SpamapS> earthquake
[20:47] <slangasek> also, /run/network please, /var/run is a compat symlink :)
[20:47] <slangasek> how bad?
[20:48] <barry> seriously?  what's with all this seismic activity?
[20:48] <smoser> SpamapS, i think there is a race still.
[20:48] <slangasek> he's in California, he's statistically ignorable :P
[20:48] <slangasek> smoser: there isn't, because you're doing a filesystem-level test and set :)
[20:48] <SpamapS> not much
[20:48] <smoser> eth0 touch /var/run/network/ifup.eth0; eth1 touch /var/run/network/ifup.eth1
[20:49] <SpamapS> Los Angeles area.. sometimes I think I feel them and its just a big truck.. old building..
[20:49] <smoser> wait...
[20:49] <slangasek> smoser: each instance must create its own flag file *before* checking the list.  Therefore, whichever one creates its file *last* is guaranteed to see all of them
[20:49] <barry> slangasek: :)
[20:49] <smoser> eyah..i guess.
[20:49] <smoser> k.
[20:49] <smoser> much easier.
[20:49] <slangasek> as long as we're using a POSIX filesystem, that is ;)
[20:50] <smoser> as long as we dont remove them.
[20:50] <slangasek> which we shouldn't
[20:50] <smoser> i think we're kind of screwed if /run is not POSIX
[20:50] <SpamapS> slangasek: we decided to put off non posix support for /run until after systemd migration... 15.10 maybe? ;)
[20:51] <SpamapS> http://earthquake.usgs.gov/earthquakes/recenteqscanv/FaultMaps/118-34.html
[20:51] <slangasek> just making sure your code isn't portable to Win32 ;)
[20:51] <SpamapS> 4.1 in the valley
[20:51] <smoser> SpamapS, ok
[20:51] <slangasek> s/your code/you know your code/
[20:51] <smoser> so i'm still going to make the /var/run/network/static-network-up-emitted dir.
[20:51]  * slangasek nods
[20:51] <smoser> or touch that. or something. so that when i come up i can say "has that event happened?"
[20:52] <slangasek> the mkdir is best because you only want it to succeed once
[20:54] <kirkland> jml: what's the word?
[20:54] <jml> kirkland: ssh test failed. trying logout of desktop session.
[20:54] <smoser> SpamapS, i have to run. i'll put together a merge proposal later.
[20:55] <Daviey> smoser: don't break it.
[20:59] <SpamapS> smoser: ok THANKS!
[20:59] <kirkland> jml: hmm, i don't get it ... i reproduced your setup and the bug here exactly
[20:59] <kirkland> jml: and this is fixing it for me
[21:02] <kirkland> slangasek: howdy
[21:02] <slangasek> kirkland: hiyo
[21:02] <kirkland> slangasek: okay, a grep shows: http://paste.ubuntu.com/680126/
[21:02] <kirkland> slangasek: so all of these can/should be dropped to a LOG_DEBUG?
[21:03] <slangasek> kirkland: my position is that at least the first 2 should not be logged at all unless the module is being passed some debugging option
[21:04] <slangasek> because "pam_sm_authenticate: Called" is bloody useless output
[21:04] <slangasek> unless you're debugging the module
[21:04] <kirkland> slangasek: agreed, okay
[21:04] <slangasek> kirkland: also, please put the module name *in* the log messages :)
[21:04] <kirkland> slangasek: agreed
[21:05] <jml> kirkland: v91?
[21:05] <kirkland> jml: hmm
[21:05] <slangasek> kirkland: we actually have a pam helper function in current Linux-PAM that you could use, fwiw (pam_syslog())
[21:06] <kirkland> jml: i think i might have push a bad upload to the ppa
[21:06] <kirkland> jml: ie, without the fix
[21:06] <jml> kirkland: ah, ok.
[21:06] <jml> kirkland: I've got to head now -- laptop and mental batteries are fading
[21:06] <jml> kirkland: but I can test on the morrow if you upload to your ppa again.
[21:06] <kirkland> jml: k
[21:21] <Apteryx> Hey, I've got a really trivial patch (one mirror line to add to /usr/share/python-apt/templates/Ubuntu.mirrors
[21:23] <dupondje> Somebody pushed some upgrades :D
[21:23] <Apteryx> I made a patch, showing the added line, see: http://pastebin.com/EFF2mvhv
[21:24] <Apteryx> What's the process to get this line incorpored efficiently in Ubuntu 11.04 and later?
[21:25] <Apteryx> I could report a bug against python-apt, but it seems almost overkill.
[21:28] <kirkland> jml: ecryptfs-utils_92-0ubuntu1~ppa1_source.changes uploaded to ppa:ecryptfs/ppa
[21:30] <stgraber> Apteryx: this is a generated file, so shouldn't be patched
[21:31] <slangasek> Apteryx: as stgraber says - the correct procedure is to get your mirror registered with launchpad
[21:31] <slangasek> see https://launchpad.net/ubuntu/+archivemirrors
[21:31] <slangasek> (and the 'register a new mirror' button)
[21:32] <slangasek> if it's already registered and what's needed is to refresh the mirror list in the package, please do file a bug against python-apt
[21:33] <stgraber> Apteryx, slangasek: http://paste.ubuntu.com/680146/ is the diff from what we currently have in python-apt and what's in Launchpad
[21:35] <stgraber> Apteryx: what version of Ubuntu was that patched written for? I see the uqam mirror at the top of LOC:CA in the current package
[21:35] <stgraber> Apteryx: http://paste.ubuntu.com/680147/ is what we have in Oneiric
[21:35] <sladen> skaet: are we unfrozen now post beta1 ?
[21:35] <slangasek> sladen: we are now in feature freeze again instead of beta freeze, yes
[21:36] <skaet> sladen.  yup
[21:37] <skaet> thanks slangasek. :)
[21:39] <slangasek> sure :)
[21:39] <sladen> ta :-)
[22:15] <slangasek> tedg: hi
[22:16] <tedg> slangasek, Unfortunately I need to run... I was just logging out.
[22:16] <slangasek> tedg: ok
[22:16] <tedg> I'll assume you'll implement the highlander directive and we're all happy :-)
[22:16] <slangasek> :)
[22:16] <slangasek> well, wanted to talk through it with you
[22:17] <slangasek> the reason apt has such a problem with it is because the breaks is so deep in the dependency tree
[22:17] <slangasek> if it were done against the indicators themselves, which seems perfectly appropriate, apt would sort it out
[22:17] <slangasek> but I realize there are a lot more of those, so it's hard to be comprehensive
[22:17] <tedg> slangasek, Hmm, okay.  I have no specific concern there, but we just thought if we did it lower it would be more complete.
[22:17] <tedg> Which I guess is kinda the problem :-)
[22:18] <slangasek> yeah :)
[22:18] <tedg> slangasek, So, in a nutshell, I'm totally open to ideas, but I think we need to have something to protect for that situation in the package.
[22:18] <slangasek> agreed
[22:19] <slangasek> I'll see what I can come up with
[22:19] <tedg> Cool, thanks.  I'll run around in 100 degree heat with 5 year olds ;-)
[22:23] <SpamapS> err.. can somebody explain this one for me...
[22:23] <SpamapS> http://paste.ubuntu.com/680171/
[22:24] <SpamapS> I have python3 3.2-3 installed, but it says the >= 3.2 < 3.3 dependency is not satisfiable..
[22:30] <barry> SpamapS: i've seen that before too, and i don't understand it either
[22:30] <barry> tumbleweed: ping
[22:30] <SpamapS> maybe its to signal that python3-profiler isn't a separate package anymore.. which is cool
[22:31] <barry> SpamapS: i find apt's error messages to be about as cryptic as you can get ;)
[22:41] <jelmer> Sweetshark, hi
[22:42] <jelmer> Sweetshark, just noticed you registered a libreoffice import - unfortunately we don't support git imports over http using the smart server protocol yet, I've fixed the URL
[22:42] <jelmer> Sweetshark, There was already an import at lp:~vcs-imports/libreoffice/trunk; that failed to scan for some reason
[22:43] <barry> @pilot out
[23:00] <TheMuso> @pilot in
[23:46] <pdtpatrick_> Which team would I ask this question to? .. why does the shell built-ins navigate better than for instance /usr/bin/less? ... here's an example.
[23:46] <pdtpatrick_> http://pastebin.com/BLXiiV4M
[23:47] <pdtpatrick_> notice how if u use cd it would add the /
[23:47] <pdtpatrick_> when u tab to autocomplete
[23:47] <pdtpatrick_> when u use less .. if u tab - it just creates a space instead of realizing you're navigating a directory