[00:37] <infinity> pitti: *poke*
[00:37] <pitti> infinity: hey
[00:38] <infinity> pitti: trusty-adt-libproxy-ppc64 <-- Why is that not using the dpkg arch (ppc64el)?
[00:38] <infinity> pitti: ppc64 is very much not the same thing. :)
[00:39] <infinity> pitti: (And don't go away, I have more important things to discuss)
[00:39] <pitti> infinity: ah, thanks for pointing out; the view name etc. is right, just not the suffix; I asked jibel to rename them
[00:41] <infinity> pitti: Alright, cool.  Simple annoyance, that one.
[00:42] <infinity> pitti: So, the more important thing... We need to completely flush all the ppc64el ddebs/indices from germanium and re-import fresh from the buildds.
[00:42] <infinity> pitti: My cron job that cleans old ddebs is intentionally off for now, so there should be a full set avaiable to scrape.
[00:42] <pitti> infinity: ah, good; setting that off now
[00:43] <infinity> pitti: Just make sure it's actually flushed sanely first, since I know ddebs operated on a naive first-come-first-published basis, and we've, of course, rebuilt the whole world with identical versions/filenames.
[00:44] <pitti> infinity: I can make sure that the latest build wins, that ok?
[00:44] <infinity> pitti: Still not quite ideal, as you may have ddebs that matchs things that don't exist anymore, as we had new FTBFSes.
[00:44] <infinity> pitti: Is flushing really hard?
[00:44] <pitti> *meh* need more interweb tubes here
[00:45] <pitti> infinity: no, it's not; I meant the order of re-pulling them from the buildds
[00:45] <infinity> pitti: If so, then yeah, latest-build-wins would probably work for now, and we can not care about those few.
[00:52] <infinity> pitti: '*_ppc64el*deb' please.  Your will catch a few packages with ppc64el in the name on other arches.   Might want to limit it to just the 10 ppc64el buildds, so you're not reimporting EVERYTHING.
[00:54] <pitti> infinity: hm, lp.builders objects have no .arch property or something like that? meh
[00:54] <pitti> so, 'ppc64el' in .title
[00:56] <infinity> pitti: Title should do.  Or just limiting to fisher*, denneed* and postal*
[00:56] <cyphermox> doko: I can, but it's been that way forever, this isn't something I added recently
[00:56] <cyphermox> that said, it's not a reason to keep this old thing around
[00:58] <pitti> infinity: purged, slurping ddebs from the ppc64el builders (the title hack works)
[01:00] <infinity> pitti: Huzzah.  Let me know when the slurping appears to have been successful, so I can un-hack my cronjobs and let them purge again.
[01:01] <pitti> infinity: ah, it's now at feb 18; I guess that's the day of the Mass Rebuild Of Death, given how much time it spends on that one :)
[01:01] <pitti> I started with Feb 14
[01:04] <infinity> pitti: Started on Feb17, but definitely more packages in Feb18, yeah.
[01:26] <pitti> infinity: all slurped; rebuilding indexes now
[01:30] <infinity> pitti: \o/
[01:30] <infinity> pitti: Thanks.
[02:25] <ScottK> slangasek: Kubuntu wants Qt5 5.2 in.
[02:52] <slangasek> ScottK: ok.  Is any further testing coordination needed wrt Kubuntu, or should we just get it in ASAP?
[02:52] <ScottK> slangasek: Get it in ASAP.
[02:53] <ScottK> We mostly want it in 14.04 so we can backport KDE Frameworks 5 after it's released.
[02:54] <slangasek> ok
[04:51] <ESphynx> hey guys :) still hope to have packages brought in? ;)
[06:31] <dholbach> good morning
[06:32] <ion> that
[06:33] <ESphynx> hey nisstyre :)
[06:33] <ESphynx> good morning dholbach
[06:33] <dholbach> hi ESphynx
[06:34] <ESphynx> dholbach: archive is still open eh?
[06:36] <dholbach> ESphynx, I guess - I haven't heard otherwise
[06:37] <ESphynx> I'm praying my release makes it in somehow :P
[08:25] <fishor> hello devs. http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/ usually provide lates vanilla build. but last build there is 3.13.0
[08:25] <fishor> should it be this way?
[09:38] <jhenke> hi guys
[09:41] <jhenke> cjwatson do you have some time to look at bug #1272664 that had been assinged to you?
[11:09] <tkamppeter> OdyX, hi
[11:16] <infinity> slangasek: Argh.  The new libcap-dev includes <linux/xattr.h> which conflicts with <sys/xattr.h>, which is the cause of your qemu FTBFS across the board.
[11:17] <infinity> slangasek: I was about to blame my new glibc until I looked closer.
[11:37] <infinity> slangasek: Though, it might be that I need to work around this in glibc headers with some undefs, like I did for P_* :/
[11:38] <infinity> I really need to find the time to do some broader comparison of kernel/glibc type mismatches here.
[11:52] <infinity> slangasek: Something like this might minimize the damage for now: http://paste.ubuntu.com/6970443/
[14:01] <ScottK> pitti: Are you dealing with things like https://jenkins.qa.ubuntu.com/job/trusty-adt-postfix-armhf/ or should lamont and I care?  It looks like something test environment related rather than a package issue.
[14:06] <rbasak> ScottK: did you see the announcement?
[14:21] <cjwatson> jhenke: probably not for a while, sorry, am buried in libclick
[14:21] <kenvandine> @pilot in
[14:56] <jhenke> cjwatson okay, do you know anybody else who can help with that issue? If not, I can wait, just want to avoid that the bug get's completely forgotten
[15:00] <ScottK> rbasak: I did (after I wrote that).
[15:50] <stokachu> anyone willing to sponsor/upload bug 1282837 for me?
[16:02] <kenvandine> @pilot out
[16:09] <didrocks> stgraber: hey, once you have a second, I used a new fakeupdate parameter to test animation changes and so on, is it fine with you? https://code-review.phablet.ubuntu.com/#/c/183/
[16:11] <mterry> pitti, what is the state of the art for faking a text message?  Is is still manually sending javascript to the phonesim daemon?
[16:11] <pitti> Good morning
[16:11] <mterry> (on the phone)
[16:11] <mterry> pitti, good morning  :)
[16:12] <pitti> mterry: by and large yes, but have a look at the messaging-app AP tests; they have a helper function which is by and large just receive(sender, text)
[16:12] <mterry> pitti, OK will steal  :)  thanks!
[16:14] <stgraber> didrocks: I already gave my +1 to sergiusens
[16:15] <pitti> ScottK: the "AttributeError: 'NoneType' object has no attribute 'quit'
[16:15] <pitti> ScottK: how is that an infrastructure problem?
[16:15] <pitti> ScottK: it could be yet another fallout from switching default python3 to 3.4
[16:15] <pitti> I haven't yet waded through all the failures
[16:15] <didrocks> stgraber: ah, thanks :)
[16:16] <smb> pitti, Just since you mention that, I saw those relatively often in update output
[16:17] <pitti> another fallout is that a lot of packages' postinst now have some AttributeError in __del__()
[16:17] <smb> Oh so that one actually
[16:19] <rsalveti> xnox_: hey, would need gcc-i686-linux-androideabi or similar to be able to build the x86 emulator :-)
[16:25] <ScottK> pitti: No idea.  I just know it worked last week on i386/amd64 and there's nothing armhf specific in the failure.
[16:27] <pitti> ScottK: yeah, last week we still had py 3.3
[16:27] <brendand> barry, i have a python itch to scratch and google isn't helping me - maybe you know the answer. it seems python memoizes recursive functions, but i was wondering how/when it does this - surely it's not as simple as when the function is called with the same inputs?
[16:27] <ScottK> Right, so by "infrastructure", I meant not the package.
[16:28] <pitti> ScottK: at least it worked on x86 yesterday
[16:29] <pitti> ScottK: it might also be possible that it's due to qemu vs. LXC; the LXC runner is quite a bit stricter (it has less dependencies pre-installed, so a lot of failures are due to insufficient binary and/or test dependencies)
[16:29] <pitti> s/less deps/less packages/
[16:29] <pitti> and s/less/fewer/, but meh @ grammar :)
[16:30] <pitti> ScottK: anyway, as I wrote on the annoucement this is pretty much a "throw everything against the wall and see what sticks" run, we don't gate on it for now
[16:33] <barry> brendand: "memoizes recursive functions"?   not really sure what that means.  it does keep a recursion count and  will throw a RuntimeError if the recursion depth is exceeded.  sys.getrecursionlimit() and sys.setrecursionlimit() control that
[16:34] <brendand> barry, memoization is where you store the result of a call in a table and don't bother to call the function if the result for the same inputs is already there
[16:34] <brendand> barry, but i just realized the function i was working on wouldn't trigger this anyway
[16:35] <xnox_> rsalveti: ok. I'll try to cook that.
[16:35] <rsalveti> xnox_: thanks
[16:35] <barry> (there are actually multiple meanings of "memoize"; in the python context i's mostly closely associated with pickling)
[16:36] <barry> brendand: python doesn't memoize in the sense that you're describing, however it's pretty trivial to write a descriptor that does that for you.  that's used some times for expensive operations, but you have to be careful about the semantic differences it can imply
[16:52] <xnox_> barry: doko: what's up with subprocess NoneType stuff? it seems to be triggered by py3compile.
[16:53] <barry> xnox_: i've seen that too.  haven't had time yet to investigate
[16:53] <xnox_> barry: it appears that __del__ of subprocess does "if not getaatr(self, '_child_created', False)
[16:54] <doko> xnox_, didn't look at it yet
[16:54] <xnox_> but.... self is NoneType?!
[16:55] <dholbach> hey... can somebody check if ubuntu-html5-platform-3.4-dev (from the cordova-ubuntu-3.4 source package) is downloadable/installable in trusty proper?
[16:55] <barry> xnox_: i wonder if this is happening at interpreter shutdown time.  maybe during cycle breaking by the gc?  when python shuts down it first sets all module attributes to None, but doesn't clear out its namespace.
[16:55] <dholbach> according to https://launchpad.net/ubuntu/+source/cordova-ubuntu-3.4/3.4~pre3.r19 it should be there for amd64/i386/armhf - and not in binNEW
[16:56] <dholbach> ^ maybe an archive admin can shed some light on this?
[16:56] <dholbach> seb128, are you still around and know what might be the problem?
[16:59] <dholbach> seb128, alex-abreu: false alarm
[16:59] <dholbach> Get:1 http://archive.ubuntu.com/ubuntu/ trusty-proposed/universe ubuntu-html5-platform-3.4-dev amd64 3.4~pre3.r19 [2157 kB]
[16:59] <dholbach> Fetched 2157 kB in 2s (965 kB/s)
[16:59] <dholbach> alex-abreu, ^ we're fine
[16:59] <Laney> it's not migrating to release though
[16:59] <dholbach> ah, you're right
[16:59] <Laney> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#cordova-ubuntu-3.4 is telling you that there's a leftover cordova-ubuntu-3.4-dev package in trusty-proposed
[16:59] <alex-abreu> dholbach, ah its in proposed!
[16:59] <dholbach> pbuilders have proposed enabled
[17:00] <dholbach> Laney, what can we do?
[17:00] <Laney> an archive admin will need to remove it
[17:00] <dholbach> alex-abreu, can you maybe try talking to anyone of these folks about it? https://launchpad.net/~ubuntu-archive/+members#active
[17:01] <alex-abreu> jdstrand, might be around
[17:03] <dholbach> alex-abreu, got to go - drop me a mail if you need anything from me later on!
[17:03] <alex-abreu> dholbach, sure
[17:03] <alex-abreu> dholbach, I'll ry to unblock it
[17:03] <dholbach> thanks a bunch!
[17:03]  * dholbach hugs alex-abreu and Laney
[17:03] <dholbach> have a great weekend evryone
[17:04] <Laney> you too
[17:04] <Laney> bye!
[17:22] <xnox_> infinity: why do you hate venezuela? =)
[17:22] <xnox_> # localedef -c -f UTF-8 -i es_VE es_VE.UTF-8
[17:22] <xnox_> LC_MONETARY: value of field `int_curr_symbol' does not correspond to a valid name in ISO 4217
[17:30] <xnox_> infinity: filed bug 1283152
[17:33] <jtaylor> is there some summary page of the difference between to adt runs in jenkins?
[17:35] <jtaylor> artifacting dpkg -l or so would be useful
[17:35] <jtaylor> then one could diff it
[17:37] <cjwatson> looks like jdstrand has cleaned up the cordova-ubuntu-3.4-dev binary
[17:50] <slangasek> infinity: ah, it's libcap-dev's doing?  ok - I think we should make hallyn fix it then, since he's the one who said we needed libcap updated :)
[17:51] <hallyn> sup?
[17:52] <dbarth> hiya, i'm looking for an archive admin to help unblock a package that is stuck in proposed
[17:52] <alex-abreu> dbarth, done already :)
[17:52] <dbarth> oops, scratch that,
[17:52] <dbarth> sorry
[17:54] <hallyn> slangasek: I'm not seeing anything obvious;  are you saying ppc64el is broken by the new libcap?
[17:54] <slangasek> hallyn: qemu FTBFS because of the new libcap
[17:54] <slangasek> so I thought you might like to have a look ;)
[17:54] <hallyn> "I don't see how that relates to me"
[17:54] <hallyn> i'll take a look, thanks
[18:04] <jdstrand> cjwatson: I did
[18:04] <jdstrand> and now cordova-ubuntu-3.4 has migrated
[18:04] <Laney> happy daze
[18:20] <hallyn> slangasek: well holy cheeseballs, /usr/include/linux/capability.h has mis-matched parens in the last define
[18:20] <hallyn> oh no
[18:20] <hallyn> i need new glasses
[18:20] <jtaylor> hm libc 2.19 broke scipy :(
[18:24] <jtaylor> any other known fallout by the upload?
[18:25] <jtaylor> infinity: ^
[18:27] <jtaylor> hm it might actually be that it fixed its math functions but scipy tests used wrong ulps
[18:30] <infinity> hallyn: Check backscroll for my explanation to Steve.
[18:30] <infinity> hallyn: Long story short, something like this would work around the mismatched macros between linux headers and userspace headers: http://paste.ubuntu.com/6970443/
[18:31] <infinity> jtaylor: Nothing that I know of yet.
[18:31] <hallyn> infinity: so you can't define something in enum that is #defined?
[18:31] <hallyn> i wonder if there is a reason for those to be an enum
[18:32] <infinity> hallyn: The reason for them being an enum is actually to guard against the inverse.
[18:33] <infinity> hallyn: Which, I suppose, means one could also just include sys/foo.h before linux/foo.h to sort the issue.
[18:33] <hallyn> oh i see now.  i simply could not reproduce the issue in a standalone c program, finally did
[18:34] <hallyn> so yeah i think #include sys/foo.h is the way to go...
[18:37] <infinity> jtaylor: And yes, jsm has been working hard upstream on making libm be less math challenged, so it's possible that some things that rely on its bugs may be a bit out of whack.
[18:37] <jtaylor> well scipy tests against a infinite precision library
[18:37] <jtaylor> so I chances are its worse now
[18:38] <infinity> jtaylor: (I'd content that anything that relies on exact values from libm was always buggy to start with, since libm makes approximation commitments, not precision... If you need precision, you need something slow and correct, like GPM)
[18:38] <jtaylor> but I'm still trying to extract the inputs :/
[18:38] <infinity> s/content/contend/
[18:38] <jtaylor> well C99 appendix gives bounds on what libc should provide
[18:38] <jtaylor> most don't follow it though
[18:38] <jtaylor> glibc is actually one of the better ones
[18:38] <infinity> Yeah, we're working on being more compliant than we were. :)
[18:39] <jtaylor> I still ahve a huge stack of complex trigonometry bugs to fowrard to glibc :/
[18:39] <hallyn> infinity: (I don't have upload rights) do you  mind pushing the new libcap with that change?  I've emailed amorgan (the upstream maintainer) to let him know, in the meantime
[18:40] <infinity> hallyn: Sure.  Might be worth a quick qemu test build against such a mangled header to make sure it doesn't blow up in new and exciting ways.
[18:41] <infinity> hallyn: But that should do the trick.
[18:41] <hallyn> yeah, and my first attempt failed,
[18:41] <hallyn> but i may have left some garbage,
[18:42] <infinity> hallyn: And by "that change", I assume you mean http://paste.ubuntu.com/6972335/ ?
[18:42] <hallyn> i did.  if it turns out that didn't jsut break my qemu build even more
[18:43] <hallyn> well hey, btrfs really *has* sped up on fsync in trusty
[18:43] <infinity> It shouldn't, but I'll spin up a test here for paranoia's sake.
[18:49] <doko> Trying easy from adconrad: ruby-defaults/1:<IP_ADDRESS> ruby2.0/<IP_ADDRESS>4-1ubuntu1 ruby1.9.1/<IP_ADDRESS>4-2ubuntu1
[18:49] <doko> leading: ruby-defaults,ruby2.0,ruby1.9.1
[18:49] <doko> failed: ruby-defaults
[18:49] <doko> but doesn't show anything anymore ...
[18:49] <hallyn> all right.  it's noticably faster, but still eatmydata-worthy
[18:57] <pitti> thomi: https://blueprints.launchpad.net/ubuntu/+spec/core-1311-python3-roadmap
[19:02] <hallyn> infinity: looks like i'd left something in a bad state :) in a new environment it builds fine with that change
[19:04] <infinity> hallyn: Yeah, getting to that conclusion here too.   Slowly.
[19:09] <hakermania> Hello there! I am looking for a sponsor for my package, Wallch. If you want to sponsor it or you know someone interested, please let me know! https://bugs.launchpad.net/ubuntu/+source/wallch/+bug/1282830
[19:11] <rcj> hallyn, if you get a qemu-util package for ppc64el built while you're working on this, could you put it up for me to grab?  I'm blocked at the moment waiting for qemu-img
[19:12] <infinity> rcj: That will fall out from my libcap upload.
[19:12] <infinity> (As in, the change you want is uploaded but FTBFS)
[19:13] <rcj> infinity; thanks.  just trying to determine the fastest route to get back up and running with qemu-img.
[19:18] <infinity> hallyn: Uploaded, I'll retry qemu when it's published.
[19:18] <jtaylor> mh ok glibc 2.19 produces worse results
[19:18] <infinity> jtaylor: :(
[19:18] <infinity> jtaylor: In which function(s)?
[19:19] <jtaylor> still checking where exactly, but mpmath is correct and the error is significant
[19:20] <infinity> jtaylor: Could it, perhaps, be a need for -ffp-contract=off somewhere?
[19:20] <jtaylor> I don't have fma
[19:20] <jtaylor> also thats off by default in gcc4.9
[19:20] <jtaylor> oh we are still 4.8
[19:20] <infinity> 4.8 defaults to fast.
[19:20] <jtaylor> 4.9 not, at least in c99 mode
[19:21] <jtaylor> but its not out yet, got confused as I'm running with that since a while :/
[19:21] <infinity> hallyn: http://launchpadlibrarian.net/167203424/libcap2_1%3A2.24-0ubuntu1_1%3A2.24-0ubuntu2.diff.gz has a slightly more upstream friendly explanation than just "Argh" in the patch header.
[19:23] <jtaylor> oh no it goes into fortran code :(
[19:37] <hallyn> rcj: I'm afraid I don't have any, sorry.  But should be building in archive soon iiuc
[19:40] <hallyn> infinity: but to prevent more failures later, should the libc6 version put the enum inside a #ifndef XATTR_CREATE?
[19:41] <infinity> hallyn: Possibly, yes.  I did this for another set of defines earlier for similar fallout.
[19:42] <infinity> hallyn: But I think I need to bring this up upstream to see if we need to be doing a full userspace/kernel macro clash audit.
[19:42] <hallyn> upstream glibc?
[19:45] <infinity> hallyn: Yeah.
[19:46] <infinity> hallyn: I still blame the kernel for its defines not being enum-guarded, but even if we get that fixed, glibc needs to work with some subset of old kernels, so we might need to sprinkle some idef guards around too.  Fun, fnu.
[19:46] <apw> infinity, enum guarded
[19:46] <apw> ?
[19:49] <infinity> apw: Remember the P_ALL, etc issue we discussed a while back?
[19:50] <apw> yeah i remember that issue, painfully
[19:51] <infinity> apw: Right.  Basically ran into a redux of the same thing when one includes linux/xattr.h and sys/xattr.h out of order (ie: kernel before userspace).
[19:51] <infinity> Not sure if this is spelled out somewhere as a big no-no (I mean, other than including kernel headers at all being a no-no), but there are clearly some larger issues at play here that I think warrant discussion.
[19:52] <apw> its all a twisty maze with glass on the floor
[19:56] <hallyn> arges: were you going to verify bug 1277157 ?
[19:56] <hallyn> the test case can't quite work for precise - bc libvirt isn't built against netcf there.  but even after rebuilding libvirt i coudln't reproduce it.  sadly.
[19:57] <arges> hallyn: hi
[19:58] <slangasek> infinity: qemu given back
[20:00] <arges> hallyn: so the libvirt in the bug comes from the cloud-archive
[20:00] <infinity> slangasek: Ta.
[20:01] <arges> hallyn: i'm having the reporter verify this on his machine, is this blocking something for you?
[20:01] <hallyn> arges: hm, as i said though a manually rebuilt libvirt with netcf support didn't reproduce it.  i can try cloud-archive in a bit...
[20:01] <hallyn> thx
[20:01] <hallyn> no, i just don't like to let things slip through the cracks
[20:01] <hallyn> and then months down the road we have an unverified sru
[20:01] <hallyn> thanks - i'll wait for results from teh reporter!  that's perfect
[20:01] <arges> hallyn: i don't like unverified srus either : )
[20:02] <arges> yea i'm also setting up my big machine to see if I can do some local testing too, let me know if you get anywhere with this one
[20:02] <slangasek> hallyn: any reason not to push the qemu arm64 patches to Debian?
[20:02] <hallyn> slangasek: now that they're upstream, probably not.
[20:02] <hallyn> slangasek: mjt may want to just wait for 1.8
[20:03] <slangasek> hmm; I suppose it is rather a large patchset, would be rude to foist that on Debian if the maintainers weren't prepared to absorb them :)
[20:03] <hallyn> let's ask
[20:04] <slangasek> I was just planning to push back the debian/control changes, and found a much bigger delta than I expected
[20:05] <hallyn> stgraber: ok lemme address the missing --dir
[20:06] <hallyn> slangasek: yeah the number of patches is impressive
[20:06] <slangasek> hallyn: have you by chance been rebasing these branches, rather than merging them?  because 6c93231780ecc89ac9e64686dd3247437d4b0696 doesn't look like a merge :)
[20:07] <slangasek> (guess I won't be cherry-picking ;p)
[20:07] <hallyn> slangasek: they have to be rebased bc we also have the omap3 patchset
[20:07] <slangasek> maaaan
[20:07] <hallyn> oh that
[20:08] <hallyn> slangasek: yes i *intended* with the latest merge to make it a complete sync.  However mjt calmed down from that...
[20:08] <hallyn> wisely
[20:08] <slangasek> ah, well
[20:08] <hallyn> i worked toward it partially which is how i bricked some machines
[20:08] <slangasek> it's still not a merge topologically :)
[20:09] <hallyn> with the *next* merge i may make it completely syncable
[20:09] <hallyn> what do you mean?
[20:09] <slangasek> hallyn: do you know why /usr/share/qemu/OVMF.fd is in qemu-system-common, when all the other firmware bits are in qemu-system-x86?
[20:09] <slangasek> hallyn: I mean that 'git log debian/qemu-system-common.links' shows that the history of this file starts and ends with the latest merge
[20:10] <hallyn> not sure, i don't recall making a change there
[20:12] <slangasek> seems to have happened with the binary package reorg, post-quantal
[20:12] <hallyn> is OVMF useful on any other arches?
[20:12] <slangasek> hallyn: *this* build of OVMF certainly isn't :)
[20:12] <slangasek> there are open bug reports in both Ubuntu and Debian asking to build it for other archs beside x86_64, but then each of those would need its own symlink
[20:12] <slangasek> so I think I'll just arrange to move that into qemu-system-x86
[20:13] <hallyn> sounds good
[20:20] <hallyn> slangasek: so how would the OVMF.fd filenames look if different arches were supported?  /usr/share/ovmf/ovmf-$arch.fd ?
[20:20] <slangasek> hallyn: undecided :-)
[20:20] <hallyn> ok
[20:20] <hallyn> guess i need to be looking at that pkg.  i've been negligent there
[20:21] <slangasek> I suppose I would leave /usr/share/ovmf/ovmf.fd in place for backwards-compatibility, and then use ovmf-$efiarchname.fd
[20:21] <jtaylor> infinity: that doesn't look right: http://paste.ubuntu.com/6972824/
[20:21] <hallyn> yeah
[20:21] <jtaylor> though maybe its the debugger
[20:23] <infinity> jtaylor: I'm pretty wildly unfamiliar with libm.  If you do find issues, an upstream bug report would probably work out better than trying to educate me. :)
[20:24] <infinity> jtaylor: I know the testsuite passes within whatever acceptable ULPs upstream has defined, but that's about as far as my libm usage goes.
[20:41] <jtaylor> k filed a bug
[20:41] <jtaylor> http://sourceware.org/bugzilla/show_bug.cgi?id=16623
[20:48] <jtaylor> fwiw I think its a bug, that number should just still be in the range where glibc can give a right result
[20:48] <jtaylor> at least +- 0.1
[20:53] <ogra_> stgraber, wow, you got a special edition of the german ix magazine (professional it magazine) about LXC ! congrats !!
[20:54] <ogra_> (and you are mentioned in the announcement, i bet they just translated your blog ;) )
[20:54] <stgraber> ogra_: hehe, yeah, I saw a lot of hits coming from heise.de and referring to that magazine
[20:54] <ogra_> yeah
[21:31] <pitti> slangasek: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest%20ppc64el/ :)
[21:33] <slangasek> pitti: whoo! thanks :)
[21:33] <slangasek> pitti: the ppc64 junk jobs still need removing, I guess?
[21:34] <pitti> slangasek: correct, that RT is still pending
[21:34] <slangasek> ok
[21:34] <pitti> slangasek: wolfe-05 ran out of disk space, I'll clean up (bah jenkins leaking all its files) and retry jobs
[21:35] <pitti> *phew*, we've worked on hardly anything else than ppc/armhf tests this week, but finally getting there :)
[21:37] <slangasek> pitti: infinity and I are looking at https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest%20ppc64el/job/trusty-adt-coreutils-ppc64el/ ... coreutils passes its test suite at build time, so we're wondering if this is a problem with the test env
[21:37] <hallyn> how weird - i install linux-image-3.2 in precise, and it grabs...   all of the old 3.2 kernels (-24, -25, -26, -26, ... -41, ...)
[21:37] <slangasek> pitti: how can we reproduce the adt environment?
[21:38] <slangasek> hallyn: linux-image-3.2 isn't a real package, so you're getting the benefit of a little-known misfeature that apt supports regexps for installation
[21:38] <pitti> slangasek: debcheckout autopkgtest; sudo tools adt-build-lxc ubuntu trusty
[21:38] <hallyn> slangasek: neat! :)
[21:39] <pitti> slangasek: that's mostly equivalent to sudo lxc-create with the ubuntu template (debootstreap)
[21:39] <pitti> slangasek: then for the actual test: ./run-from-checkout coreutils --- lxc -es adt-trusty
[21:39] <slangasek> pitti: ok.  what does that give us as the backing filesystem? ext4, tmpfs, or some aufs madness? :)
[21:39] <pitti> slangasek: I think --ephemeral defaults to tpmfs and overlayfs
[21:40] <slangasek> pitti: and you're using --ephemeral?
[21:40] <pitti> slangasek: let me run the test on amd64 in LXC
[21:40] <pitti> slangasek: right
[21:40] <slangasek> ok
[21:40] <pitti> ah, need to create a trusty container; argh slow network
[21:40] <slangasek> pitti: do you have more than one test running /in parallel/ using overlayfs against the same base chroot?
[21:41] <pitti> slangasek: on the ppc nodes we have two parallel runs, on armhf just one
[21:41] <pitti> slangasek: if I were to bet, I'd bet it was due to lxc/overlayfs, not ppc
[21:41]  * pitti lets the container build and firefights the wolfes in the meantime
[21:42] <slangasek> pitti: right, please do *not* use multiple overlayfs instances against a single directory on ppc64el; we've seen instabilities with this before
[21:42] <slangasek> (instabilities == filesystem corruption)
[21:42] <pitti> slangasek: ok, good to know; that'll halve our running slots, but I guess they shuld still be able to keep up
[21:42] <slangasek> pitti: couldn't you run two chroots side-by-side?
[21:43] <pitti> slangasek: with some extra hackery and lock files or so, yes
[21:43] <slangasek> pitti: anyway, you do what you need to :) but yeah, parallel overlayfs is unreliable, so if you can fix that and retry the coreutil adt, that'd be keen
[21:44] <slangasek> infinity: ^^
[21:45] <pitti> slangasek: reconfiguring jenkins on our side is a bit tricky, as d-jenkins is broken; jibel will try
[21:46] <infinity> pitti: Oh, if the lxc adt stuff is using overlayfs, we're going to see failures even without the parallel madness.
[21:46] <infinity> pitti: Could I talk you into switching to aufs?
[21:47] <pitti> infinity: it's just using lxc --ephemeral, so whatever it supports
[21:47] <pitti> ah, --union-type
[21:47] <xnox_> pitti: btrfs-snapshots are quite good with that.
[21:48] <infinity> pitti: So, if you really want more parallelism, your better option is to spin up twice as many VMs and overcommit CPU.
[21:48] <infinity> (This is what I've done for the buildds)
[21:49] <pitti> infinity: sounds good; if smoser can give me four more VMs and we'll use only one run slot in each that'd simplify things indeed
[21:55] <pitti> $ sudo lxc-start-ephemeral --union-type=aufs -o adt-trusty
[21:55] <pitti> lxc_container: command get_cgroup failed to receive response
[21:55] <pitti> hmmm; stgraber ^ ?
[21:56] <pitti> infinity, slangasek: I get the same errors on trusty amd64 with a single container (but with overlayfs); trying with clone now
[21:58] <pitti> still 2 test failures, although the output looks cleaner
[21:58] <pitti> FAIL:
[21:58] <pitti> File name too long at -e line 2.
[22:02] <slangasek> "file name too long" - err?
[22:03] <pitti> slangasek: coreutils' adt test is a subset of the upstream tests; if these two don't work in LXC, we can just drop them as well, in the worst case
[22:03] <pitti> slangasek: we already run them during package build, the autopkgtest sohuld mostly be a smoke test
[22:04] <pitti> slangasek, infinity: wolfes reconfigured to only use one running slot
[22:09] <stgraber> pitti: that error is what you get for "generic startup failure" when not attached to the container's console (which is the case with start-ephemeral) so that's not terribly useful. Maybe you're lucky and you get the actual error in /var/log/lxc/ ?
[22:11] <pitti> stgraber: hm, it doesn't create a log file in the first place
[22:12] <pitti> stgraber: /var/log/lxc/ has gazillions of logs, just not for the --union-type=aufs one
[22:12] <pitti> (are these ever cleaned up?)
[22:12] <pitti> uh, apparenlty not, I've got logs from half a year ago
[22:12] <stgraber> hmm, we probably should ship a logrotate config then :)
[22:13] <stgraber> pitti: so one trick you could do is set those two options in your orig container (adt-trusty):
[22:13] <stgraber> lxc.logfile = /dev/stderr
[22:13] <stgraber> lxc.loglevel = debug
[22:13] <stgraber> start-ephemeral will copy that to the aufs clone and you'll get the log output at startup on stderr
[22:14] <pitti> done, but no output at all (except for the cgroup response and the failure notice)
[22:14] <stgraber> that's slightly annoying... how about if you set it to some fs path?
[22:15] <pitti> stgraber: if I run with --union-type=overlayfs the container starts, but still no debugging output
[22:15] <pitti> but I did get /var/log/lxc/adt-virt-lxc-ewfdkd.log
[22:15] <pitti> (zero bytes)
[22:16]  * pitti logs to /tmp/log
[22:16] <pitti> stgraber: got created, but empty
[22:16] <pitti> stgraber: also empty with (working) overlayfs
[22:17] <stgraber> pitti: what version of lxc is that?
[22:17] <pitti> 1.0.0~rc4-0ubuntu1
[22:17] <pitti> stgraber: I didn't dist-upgrade today, might that help?
[22:17] <pitti> (last upgrade yesterday)
[22:17] <stgraber> probably not
[22:17] <stgraber> unless you're using btfs or xfs as your /var/lib/lxc
[22:17] <stgraber> *btrfs
[22:18] <pitti> no, good ol' ext4
[22:19] <stgraber> pitti: ok, well, easiest way to figure this out will be to patch lxc-start-ephemeral, commenting the "if dest.defined: dest.destroy()" after the "The container '%s' failed to start"
[22:20] <stgraber> pitti: that way the container will fail but will still exist on the system, you can then use good old lxc-start on it
[22:20] <stgraber> which should be a bit more useful at telling you what's wrong
[22:22] <pitti> hm, I did that, it still doesn't exist
[22:23]  * pitti adds good old subprocess.call(['bash', '-i']) right after the error message
[22:23] <stgraber> pitti: hmm, maybe that container is actually getting past that point, pass -k then
[22:23] <pitti> still doesn't exist
[22:23] <pitti> perhaps it fails on creation already?
[22:24] <stgraber> pitti: well, let's try something simpler then :)
[22:24] <stgraber> pitti: lxc-clone -o adt-test -n test -B aufs -s
[22:24] <pitti> --keep-data also doesn't work
[22:24] <pitti> lxc_container: No such device - aufs: error mounting /srv/lxc/adt-trusty/rootfs onto /usr/lib/powerpc64le-linux-gnu/lxc options br=/srv/lxc/test/delta0=rw:/srv/lxc/adt-trusty/rootfs=ro
[22:24] <pitti> stgraber: ah, now we are talking
[22:24] <stgraber> progress!
[22:25] <stgraber> pitti: so let's look for the obvious problems: grep aufs /proc/modules
[22:25] <pitti> no hit
[22:25] <stgraber> pitti: modprobe aufs
[22:25] <pitti> $ modinfo aufs
[22:25] <pitti> modinfo: ERROR: Module aufs not found.
[22:25] <stgraber> that'd explain it ;)
[22:25] <pitti> that'd do it
[22:26] <pitti> $ grep AUFS /boot/config-3.13.0-8-generic
[22:26] <pitti> CONFIG_AUFS_FS=m
[22:26] <pitti> LIES!
[22:26] <stgraber> well, that or you didn't reboot the box in a while
[22:27] <stgraber> it could be that the kernel you're running has been uninstalled
[22:27] <stgraber> so the .ko no longer exist on disk
[22:27] <pitti> no, still installed
[22:27] <pitti> -11 is current, -8 is running, -7 to -11 are installed
[22:28] <pitti> meh, and if I reboot I still get -8
[22:28] <stgraber> do you have linux-image-extra-... installed too?
[22:28] <stgraber> because apparently aufs is in that one, not in the main linux-image
[22:28] <pitti> no, I don't; good point
[22:28] <pitti> infinity: vmlinux -> boot/vmlinux-3.13.0-11-generic
[22:29] <pitti> infinity: any idea why after rebooting I still get 3.13.0-8?
[22:29] <stgraber> well, at least that's the case on x86 but since -extra also exists on ppc64el, that may be the case there too
[22:29] <pitti> infinity: oh, nevermind; smoser` needs to reboot the VMs with an explicit -kernel qemu option
[22:30] <pitti> hm, no metapackage for -extra
[22:30] <bdmurray> bdrung: How would you feel about adding enabled architectures information to distro-info?
[22:30] <infinity> pitti: Because smoser's VM setup doesn't have a bootloader.
[22:30] <pitti> ah, linux-image-generic isn't installed
[22:30] <pitti> infinity: right, so I'll need to ask him to reboot with -11
[22:31] <infinity> pitti: Which host is it?  I *might* be able to figure out his setup.  Maybe.
[22:31] <pitti> infinity: wolfe-03 to 06
[22:32] <infinity> No promises that I can decipher his VM setup, it's more complex and abstracted than mine.  But let me have a poke.
[22:36] <stgraber> pitti: so just wondering, are you using overlayfs because you want the overlay on tmpfs feature or just to save you the lengthy initial clone?
[22:41] <pitti> stgraber: both really; whatever makes things faster
[22:41] <pitti> stgraber: well, we haven't actually yet run into a test which is only broken by overlayfs, so it's not that urgent for now
[22:43] <infinity> pitti: Okay, I think I might have it figured out.  Want to poweroff all your guests for me?
[22:43] <infinity> pitti: As for "tests only broken by overlayfs", you'll find that glibc's testsuite fails. :/
[22:43] <infinity> (And it's fine on aufs)
[22:44] <stgraber> I'd also expect upstart's testsuite to fail on overlayfs, not sure about aufs
[22:44] <pitti> infinity: ah, good; well, let's find out after the reboot with overlayfs
[22:44] <pitti> err, with -11
[22:45] <pitti> infinity: shutdown; that'll kill some tests, I'll retry them later
[22:46] <sarnold> pitti: there's some trusty bugs that are failing the retracing, two at-hand examples: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1283000 https://bugs.launchpad.net/ubuntu/+source/doodle/+bug/1283259
[22:49] <infinity> pitti: Just grabbing a kernel and scping it around.  Be with you shortly.
[22:56] <pitti> sarnold: they can't find glib, gdk-pixbuf and friends, that's a bit odd
[22:56] <pitti> sarnold: I can't spend much time on that now I'm afraid; could you send me a mail about this for next week?
[22:56] <sarnold> pitti: sure
[22:56]  * infinity wonders what's gone wrong with the pty setup on this machine...
[22:57] <pitti> sarnold: oh, WTH -- are you using some PPA?
[22:57] <infinity> [shared@wolfe ~]$ screen -S wolfe-03
[22:57] <infinity> Cannot open your terminal '/dev/pts/8' - please check.
[22:57]  * infinity grumps.
[22:57] <pitti> WARNING: /lib/i386-linux-gnu/libglib-2.0.so.0.3990.0 is needed, but cannot be mapped to a package
[22:57] <sarnold> pitti: dunno, I'm just trying to move bugs out of the security queue so they stand a chance of being fixed :)
[22:57] <pitti> sarnold: nevermind, mis-looked
[22:58] <infinity> smoser`: Don't suppose you're around to tell me what's up with your screen setup?
[22:58] <pitti> sarnold: yeah, that's fine; we have no shortage of failed-to-retrace bugs, if someone wants to investigate all them we have enough work for 20 years :)
[22:59] <infinity> Oh, might be a non-login shell issue.
[22:59] <sarnold> pitti: ha! :) it just feels like lately there's more 14.04 bugs coming throuh than I would have expected, and I'd hate if some of them just didn't get the attention they deserved because they stayed locked up
[23:00] <infinity> Rightm, problem solved.
[23:01] <infinity> pitti: Can you check wolfe-03 appears to be the kernel you want?
[23:01] <pitti> infinity: LGTM
[23:01] <pitti> and look, aufs
[23:02] <pitti> and it works with -ephemeral
[23:03] <infinity> pitti: 4, 5, and 6 should be up now too.  Those were all the ones you had, right?
[23:03] <pitti> infinity: right, these four; danke!
[23:10] <pitti> infinity, slangasek: wolfes changed to run tests with aufs now; I retried a few packages, but as we now only have 4 executors it has some queue
[23:20] <pitti> infinity, slangasek: do you think with aufs we can move back to two executors?
[23:21] <bdmurray> pitti: could you look at an aptdaemon mp from me?
[23:22] <infinity> pitti: Not sure.  Can 4 VMs really not keep up right now, or is there just a scary backlog?
[23:22] <pitti> infinity: I think they can keep up, I'm just impatient :)
[23:22] <pitti> infinity: just stop uploading more eglibcs and retriggering $WORLD :-P
[23:22] <pitti> bdmurray: yes
[23:23] <bdmurray> https://code.launchpad.net/~brian-murray/aptdaemon/bug-1266844/+merge/207276
[23:24] <infinity> pitti: What's that?  I can't hear you over the sound of my uploads being AWESOME.  Maybe I'll do another.
[23:26] <pitti> infinity: I have the entire setup of an adt slave scripted now; I could run it on you and make YOU do all the tests in your brain!
[23:27] <infinity> pitti: My integer performance is pretty lousy, I don't think we want that.
[23:27] <infinity> pitti: And don't even get me started on floating point...
[23:27] <slangasek> not to mention *those* filesystem corruption issues
[23:29] <pitti> there, unar fixed
[23:30] <pitti> I'm tempted to upload postgresql-9.3 to fix its tests on lxc, but that'll trigger yet another 20 tests
[23:41] <pitti> bdmurray: do you know under which conditions get_model() returns None?
[23:41] <pitti> bdmurray: I'm afraid I don't quite understand the fix with some more context
[23:49] <bdmurray> pitti: no, however bug 1024590 was fixed similarly in r963
[23:54] <pitti> mdeslaur, sarnold: did you see my postgresql security update? anything you still need from me for that?
[23:55] <sarnold> pitti: mdeslaur is on it, thanks for the fixes :)
[23:55] <pitti> sarnold: great, thanks


[00:02] <owh> This might turn into a question that's too big for IRC, but I'm unsure where to start. I need to provide SSO for a small business. They're going to be using Google Apps as their email/calendar and the workstations are running Windows. Currently it's all peer to peer, but I need to centrally manage their installations. There's a Ubuntu 8.04 File/Print server...
[00:03] <owh> I want the implementation to be Ubuntu based. I'd like them to have roaming profiles and I'd like it all to be centrally manageable. I like Google's UI for managing users and it seems to make sense to re-use that.
[00:03] <owh> Am I reaching for the moon?
[00:44] <icarus_squared> what kernel does 9.04 SE come with?
[01:32] <fbc-mx> Is there an easy way of running a command recursively on every directory under the one I'm in?
[01:33] <fbc-mx> Ops I meant "IN every directory"
[01:36] <owh> fbc-mx: Use the find command. What are you trying to do?
[02:59] <qman__> owh, It's certainly doable, but it'll take a lot of work. There's also not a lot in the way of documentation for creating complete solutions like that. You're going to need Samba in the very least, and probably openldap or kerberos
[03:03] <qman__> I'm all for open source, but there's something to be said for the simplicity of setting up Active Directory. Getting a working Linux domain controller is pretty difficult.
[03:04] <twb> It kinda helps AD that Microsoft wrote the standards that you're talking about.
[03:04] <qman__> That too, though it does help us that they used Kerberos
[03:04] <twb> They use Microsoft Kerberos.
[03:05] <twb> It's extended in some way that I forget the details of, though they did publish an RFC documenting it
[03:05] <sommer> twb: yep, and I believe that mit kerberos 1.7 will have much of their custom stuff
[03:06] <qman__> Samba 4 should make things a lot easier when it finally comes out
[03:13] <owh> I *really* don't want to install a Windows server in this network, just so I have an AD. I might as well format the HDD on the Linux server and give them an all Windows solution.
[03:14] <owh> Next, I'll remove Thunderbird, Firefox and OO.org and throw them right back into the stone-age :)
[03:15] <owh> Imagine for a moment that I didn't say SSO with Google, does that change the picture any? How do real networks without Windows to central authentication?
[03:15] <owh> Uh, that should read: "How do real networks without Windows do central authentication?"
[03:17] <sommer> owh: I use openldap
[03:18] <sommer> owh: but to take advantage of Google's SSO facilities, I imagine you'll need to write some type of pam plugin to talk to google over the net
[03:18] <sommer> owh: are you talking about using a web based application for machine authentication?
[03:18] <owh> No.
[03:19] <owh> I want them to talk to the samba server which is currently a peer, but will become a domain controller.
[03:19] <owh> s/talk/authenticate/
[03:19] <owh> I'd like the samba server to get credentials from somewhere else.
[03:20] <sommer> owh: ah, that's not that hard then... you'll need to configure samba as a domain controller, and the easiest thing is configure samba to get users from ldap
[03:20] <sommer> owh: there's information in the serverguide for setting samba up with ldap, and as a DC
[03:20] <sommer> owh: I am also migrating to goole apps, and the SSO stuff is on the todo list
[03:20] <owh> Yeah, I'm aware of the docs for that. What I haven't figured out is how their local person can manage accounts using that.
[03:21] <sommer> at this time there isn't a great single solution for that... but there are gui tools to manage an LDAP directory, phpldapadmin, lat, etc
[03:22] <sommer> also from the command line smbldaptools will tweak user settings
[03:22] <owh> I've lookes at most if not all of those, but they all expose the innards of LDAP, which is highly obnoxious to a simple user.
[03:22] <owh> s/lookes/looked/
[03:23] <sommer> agreed, but AFAIK there isn't a simple gui tool to do everything you'd like
[03:23] <sommer> err without exposing LDAP anyway :0
[03:23] <owh> I'm happy to assist in an integrated Google SSO solution. From what I've read thus far, it's really there to provide local authentication to a remote Google Application. Not quite what I need.
[03:24] <owh> I really don't want to have to provide all manner of sync tools and password change things - yuk.
[03:24] <sommer> there was a lot of discussion at the last UDS for a central directory solution, and the plan is to use the adduser scripts for LDAP management
[03:25] <owh> That's probably going to help making it possible to manage the users through the existing Ubuntu User GUI Admin Tool
[03:25] <sommer> it should :-)
[03:25] <owh> So, I'm a decade too early then :)
[03:26] <owh> Ok, so, how does a large - say SUN - installation do this?
[03:26] <owh> I mean, I cannot believe we're the first to tread this ground.
[03:26] <sommer> I imagine there own admin tools
[03:27] <owh> So is everyone else just cobbling together all little bits and pieces with their own little scripts?
[03:27] <ajmitch> all the pieces are there - the bits to tie them together & manage them aren't
[03:27] <sommer> that's the consensus I've come up with... from being around multiple admins
[03:27] <ajmitch> and it's those management tools & ways of setting things up that take a significant amount of time
[03:28] <owh> Yup
[03:28] <sommer> right you pretty much expose no LDAP innards, or all of them
[03:28] <sommer> and if you don't expose them you're locked into a certain tree configuration... which may or may not be a bad thing
[03:29] <owh> So how does AD deal with that? I cannot imagine the MCSE's I know doing any thinking of their own.
[03:29] <owh> Point - click - hunt - click - hunt - whoops - click - fixed.
[03:30] <owh> Or is that unfair?
[03:30] <ajmitch> because a lot of things on the client & server are preconfigured in the case of AD
[03:30] <sommer> AD locks you into their directory layout
[03:30] <ajmitch> s/a lot/nearly everything/
[03:30] <sommer> it's really hard to add attributes in AD for example
[03:31] <sommer> well once you do the pretty GUI admin tools won't know about your changes
[03:32] <owh> I read/skimmed the LP blueprint on some of this. I didn't really understand the concerns raised about example.com vs example, etc.
[03:32]  * owh is hunting for the URL
[03:32] <ajmitch> flexibility is both the best & worst thing about what we have
[03:33] <owh> Never a truer word has been spoken.
[03:33] <owh> The URL: https://blueprints.launchpad.net/ubuntu/+spec/ldap-defaultdit-usergrp-mgmt
[03:33] <owh> There is nothing wrong with making a choice. Ubuntu is a good example of that, u-s, ditto.
[03:33]  * ajmitch spent a little bit of time looking at this in the past
[03:34] <ajmitch> but not enough to suggest an easy way out :)
[03:35] <owh> Well, one comment in that page was to use the ubuntu-server survey to determine a starting point. SOHO was indicated by I'm guessing nijaba.
[03:36] <ajmitch> yep, that's the sort of target market I'd like to look at
[03:36] <ajmitch> since NZ is full of small businesses
[03:36] <owh> It's a good starting point. You can argue that a big organisation is a collection of SOHO's anyway.
[03:37]  * owh didn't know you were in NZ.
[03:37] <ajmitch> yep, in Dunedin enjoying the snow today
[03:37] <ajmitch> you'll be coming to LCA next year I hope?
[03:37] <owh> Details?
[03:38] <ajmitch> late january in wellington
[03:38] <owh> Sounds like an interesting idea.
[03:38] <ajmitch> http://www.lca2010.org.nz/
[03:38] <owh> Hmm, a very interesting idea indeed!
[03:39] <ajmitch> I'm just talking to one of the organisers now in our LoCo channel who wants people to talk about the sort of things you're asking
[03:39] <owh> Channel?
[03:39] <ajmitch> irc channel, the usual #ubuntu-nz
[03:40] <ajmitch> but we'll need someone able to talk on such things
[03:40] <owh> Well some of the time, if not most of the time, the problem is not writing the code. The problem is defining the problem.
[03:40] <owh> Design, Design, Design.
[03:41] <owh> And some coding on the side :)
[03:41] <ajmitch> of course
[03:44]  * ScottK works on some complex projects where the cost is 50% design, 20 % code, 30% testing and they don't test nearly enough.
[03:45] <owh> One of my colleagues is the testing manager for a bank - he agrees :)
[03:47] <owh> In a previous life I was a multi-media developer, design was 85%.
[03:50] <twb> owh: it probably doesn't help that he's writing in COBOL on an AIX
[03:51] <owh> You have no idea how funny that is twb. Lemmie tell you a little anonymised story.
[03:52]  * twb cowers
[03:52] <twb> "I work for an investment bank.  I have dealt with code written by stock exchanges.  I have seen how the computer systems that store your money are run.  If I ever make a fortune, I will store it in gold bullion under my bed."  -- Matthew Crosby
[03:53] <owh> An organisation bills $1million per day. It's a telco. Their billing software runs on a VAX cluster. VAXen are no longer made. They do not have infrastructure or resources to run an old system and a new system side-by-side to trial a new system. Their solution was to virtualise their hurd of VAXen.
[03:53] <twb> owh: ever seens the emulation layers necessary to run a Lisp Machine on AMD64 hardware?
[03:54]  * owh shudders.
[03:54] <owh> That's like emulating a PDP-11 on a 6502 running virtually.
[03:54] <ajmitch> on such things empires are built
[03:54] <twb> lispm -> genera -> alpha -> powerpc (ivory) -> os x
[03:55] <owh> twb: Where's the AMD64 in that?
[03:55] <twb> os x runs on AMD64 CPUs now
[03:55] <owh> Didn't know that.
[03:55] <twb> Apple dropped PowerPC years ago
[03:55] <owh> I thought it was all Intel.
[03:55] <twb> (Note that 64-bit Intel CPUs are AMD64 architecture.)
[03:56] <owh> Ah
[03:56]  * owh is waiting for a shiny 17" MacBook to arrive.
[03:57] <owh> This is so I can finally virtualise things again - bleh.
[03:58]  * ScottK has been bitten by "Don't worry, we're emulating the old environment so the software won't even know the difference."
[03:58] <owh> Details?
[03:58] <owh> They don't have to be sordid :)
[04:00] <owh> So, if integrated SSO is not ready for prime-time like discussion seems to indicate. What would be a smart way to start down the road so past investments don't end up being thrown out with the bathwater?
[04:03] <ScottK> It didn't go well.
[04:03] <owh> What kind of issues were there?
[04:03] <ScottK> Except of timing and I/O the emulation worked fine.
[04:04] <owh> You mean internal clocks etc?
[04:04] <ScottK> Yes
[04:04] <ScottK> It was essentially hand built assembly language, so it mattered.
[04:04] <owh> When virtual time and real time don't match - fun.
[04:05] <ScottK> That and timing mattered for some of the pieces it was integrated with.
[04:05] <ScottK> The getting bitten part was that none of this was noticed until the project was in the integration testing phase.
[04:06] <ScottK> At which point it was too late to go back ....
[04:06] <owh> I can just imagine trying to implement say a serial driver in an emulated environment.
[04:06] <ScottK> You're imagining in the right direction.
[04:06] <owh> So you couldn't sync clocks in any other way?
[04:07] <ScottK> The old system was extremely deterministic.  The new one, not so much.
[04:07] <ScottK> Imagine something engineered for a hard RT kernel and you swap in a regular one and expect it to be happy.
[04:08] <owh> phone
[04:12] <owh> That was the weirdest phone call I've had in years. Anyway moving right along.
[04:13] <owh> Yeah, I can see your fun.
[04:13] <owh> How did you end up fixing it?
[04:14] <ScottK> Fortunately I didn't have to.  I was involved in one of the projects that had to integrate with it.  We got promised it would be transparent.  We weren't at all suprised it wasn't.
[04:15] <ScottK> So we screamed and beat the other project with a metaphorical stick until they bug fixed a design into existence.
[04:16] <owh> Riiight. That's code for: "Ah, we uhm stopped virtualising it?"
[04:16] <ScottK> No, they actually made it sort of work.
[04:17] <ScottK> Well enough to pretend it was sort of OK until the real rehosted version was done.
[04:17] <ScottK> Then, of course, funding got cut so not all these bastardized ones got replaced .....
[04:17] <ScottK> So the long term solution was lowered expectations.
[04:18] <ScottK> Very motivational story, yes?
[04:18] <owh> I'll say.
[04:19] <owh> That seems to be the modus operandi these days.
[04:19] <ScottK> Of course that was the last time they got away with 'Trust us ....'.
[05:26] <owh> Authentication is a funny thing. Seems not all people can get their hands around the difference between me authenticating them and them authenticating me.
[09:04] <th0m> hi
[09:07] <th0m> i just install ubuntu server (8.10, and 9.04) as guest os under vmware esx4. "dd" is very slow (20MB/s). I have 200MB/s result under debian (same config, iscsi san storage). A,y idea what could be wrong with ubuntu server default install/kernel please ? (mtpbase maybe something?)
[09:08] <_ruben> "interesting" .. never done any real performance testing with linux guests on esx (ESXi 3.5 in my case) .. dd is far from useful as a benchmark, iometer is way better, then again, its linux client is kinda crappy as well
[09:11] <Ethos> if I change etc/sudoers what service do I need to restart for the changes to take effect?
[09:13] <th0m> _ruben, i can understand that dd is not the tool for benchmark , but i should have at least the same perf as a debian default install. I cant get what's wrong ...
[09:27] <soren> Ethos: No need to restart anything.
[09:32] <Ethos> thanks
[09:55] <owh> th0m: Are you running vmware tools/open-vm-tools in both - on the same hardware?
[13:38] <ewook> hail ivoks
[13:39] <ivoks> hi
[13:40] <ewook> yo :)
[13:49] <ivoks> ttx: you remember the hadoop session?
[13:51] <ivoks> The HDFS filesystem is a Java-based filesystem
[13:51] <ttx> ivoks: yes
[13:51] <ivoks> hm... sometimes, developers play interesting games :)
[13:51] <ttx> ivoks: yes :)
[13:52] <ivoks> ttx: so, were there any significant stuff regarding java dependecies?
[13:53] <ttx> ivoks: there are a few issues, but nothing that cannot be worked-around
[13:53] <ivoks> aparently, there is source package
[13:53] <ivoks> so we could try to get it in ubuntu
[13:53] <ttx> ivoks: I wanted to have a look at the debian packaging from Cloudera
[13:53] <ivoks> i might work on that, but i'll need your help with java stuff
[13:54] <ivoks> ttx: that's the one i was thinking about
[13:54] <ttx> ivoks: I can send you the email about deps I already sent to soren a few weeks ago
[13:54] <ivoks> that would be good
[13:54] <ttx> ivoks: my guess about the cloudera packages is that they packaged a binary directly... I would be very surprised if they did it following the rules
[13:55] <ivoks> ttx: that's what they said, i didn't check it yest
[13:55] <ivoks> yet
[13:56] <ttx> ivoks: mail sent
[13:57] <ttx> ivoks: I'm available for help :)
[13:57] <ivoks> i've read it
[13:58] <ivoks> i hate non-FHS apps
[13:58] <ttx> ivoks: Java applications are notoriously FHS-adverse. With a few notable exceptions
[14:00] <ttx> ivoks: and Java upstream usually don't like when you try to install their software in a FHS-compliant way. They blame all issues on your symlink hacks.
[14:01] <ivoks> this is a good argument for pro-mono advocates
[14:01] <ivoks> :)
[14:01] <ttx> (which makes sense, from their OS-neutral point of view)
[14:01] <ttx> heh, don't start me on that one ;)
[14:28] <RobertF> Hello
[14:28] <RobertF> 9.10 (alpha2) => frederic is not in the sudoers file.
[14:35] <dnperfors> RobertF: So? is he a member of the admin group?
[14:38] <RobertF> dnperfors: is it a bug?
[14:38] <RobertF> dnperfors: I create the user during the install
[14:48] <Sam-I-Am> i've heard about an issue where the user created during install doesnt always get sudo access like they should
[14:48] <Sam-I-Am> not sure if its an official bug yet
[14:51] <ivoks> there was one couple of releases ago
[14:52] <ivoks> iirc, selecting mail server task with a 'no configuration' option for postfix, resulted in not adding user to admin group
[15:11] <lamont> ivoks: how very strange
[15:12] <ivoks> yeah
[15:12] <ivoks> we had hard time to figure out how come that happend to that user
[15:13] <ivoks> until she put all the steps in install
[15:13] <soren> lamont: It turned out to be because the postinst of postfix exited with an error code causing the rest d-i's finish-install stuff to be skipped.
[15:13] <ivoks> there was even a blog about it
[15:13] <ivoks> right
[15:14] <soren> lamont: Yes, postfix. So it was all your fault :)
[15:18] <Sam-I-Am> always blame lamont :P
[15:20] <lamont> I totally win
[16:28] <zul> so has anyone created a mirror from a cd-rom?
[16:28] <mathiaz> zul: what do you mean exactly?
[16:29] <mathiaz> zul: the packages on the cdrom have the same structure as a mirror
[16:29] <mathiaz> zul: there are dists/ and pool/ directories at the root of the iso
[16:29] <zul> mathiaz: gotcha
[16:46] <th0m> is there a way to freeze a test server ?
[16:46] <th0m> (to smiluate a troubleshooting)
[16:46] <th0m> cat /dev/random > /dev/something_crucial ?
[16:59] <ivoks> ttx: you should've been quiet :)
[16:59] <ttx> ivoks: I won't say anything more :P
[16:59] <ivoks> kirkland: so, what's your opinion on dkms?
[17:00] <ivoks> kirkland: did you use it for kvm backports?
[17:10] <ivoks> well, i have to go now... take care
[17:31] <leonel> will postgresql 8.4  included in Karmic ???  PostgreSQL 8.4 RC1 was released today ..
[17:56] <mathiaz> leonel: I'm not sure we include RCs in Debian/Ubuntu
[18:03] <leonel> mathiaz: of course not, I mean  now that  the  RC 1 is out, the Final version will be  on  Jun 29 so .. I guess it can make to Debian / Ubuntu right ??
[18:04] <mathiaz> leonel: probably - if pitti has time to upload 8.4 to debian before FeatureFreeze (end of august)
[18:50] <newtoubuntu> i am trying to uninstall gnome flash
[18:50] <newtoubuntu> can any one help?
[18:52] <giovani|work> what's gnome flash?
[19:13] <jeiworth> hi all, we are currently looking for a decent groupware for our tiny grafic design office, so far i have been checking zimbra, opengroupware and openxchange and it looks like we'll go for zimbra (although i have a bit of a stomach ache due to yahoo perhaps being sold to the evil overlord ;o)) anyone here with experience with opensource groupware?
[19:19] <sarthor> Hi, How to install / Run http://www.shorewall.net/MultiISP.html#lsm
[19:19] <kirkland> ivoks around?
[20:09] <mathiaz> kees: does this compiler error ring a bell? http://paste.ubuntu.com/197240/
[20:11] <Hecate> hezali, i don't know what gnome föash is supposed to be, either. maybe you're talking about gnash aka. gnu flash. if you do: this is totally off topic in the server chan.
[20:27] <kees> mathiaz: checking
[20:27] <kees> mathiaz: never seen that before.
[20:28] <kees> mathiaz: http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html might be helpful?
[20:28] <mathiaz> kees: ok - I haven't done any investigation on this one
[20:29] <mathiaz> kees: is the failure related to the FORTIFY defaults?
[21:24] <kees> mathiaz: I don't think so -- likely just gcc tightening semantics of the language
[21:29] <maw> on a fresh install, what does ubuntu-server use as a MTA
[21:29] <maw> can mail be relayed off the server or do I need to install postfix?
[21:37] <oruwork> maw-> I am very new to linux and I set up postfix / dovecot about 6 monhts ago for a 10 people company that i work for and we haven't had a single problem
[21:37] <oruwork> maw-> to be more specific, its not just for internal email, its for external
[21:38] <maw> my question was asking if anyone knows if an MTA is shipped in the default install
[21:38] <maw> so apps can send email etc...
[21:38] <oruwork> yes it does
[21:38] <Nafallo> maw: not unless you ticket the task for it
[21:38] <maw> I am not trying to setup a mailserver for users
[21:38] <Nafallo> ticked even
[21:38] <oruwork> maw-> yeah, you have to check the mail task at install
[21:38] <maw> that would have been postfix if I clicked that box?
[21:38] <Nafallo> oh. shipped.
[21:39] <Nafallo> I reckon so.
[21:39] <maw> ah ok
[21:39] <Nafallo> postfix and exim (IIRC) are both on the install disk.
[21:39] <Nafallo> but none is installed by default of course :-)
[21:40] <maw> right... just clarifing. FreeBSD ships with sendmail already installed but configured as a local mailer
[21:40] <Nafallo> maw: it's a decision made to not install any listening daemons by default.
[21:41] <Nafallo> cups would be the exception, but set to bind to localhost in default installs.
[21:41] <maw> right
[21:42] <maw> I essentially verified that with  netstat -an
[21:42] <maw> ok thx for clarifying
[21:42] <Nafallo> netstat -ltun is what I would have used :-)
[21:43] <maw> whoops forgot the l :P
[21:44] <Nafallo> a and l are a bit mutually exclusive aren't they?
[21:44]  * Nafallo checks the manual
[21:44] <Nafallo> yeah. looks like it.
[21:44] <hvn> I'll add sudo and -p: sudo netstat -ltunp
[21:45] <hvn> shows the listening process too
[21:45] <maw> indeed, -a and -l would have similar info. That is not necessary as one might want to know just listening compared to all
[21:54] <billybigrigger> can any suggest a good apache log analyzer? besides awstats and webalizer?