[00:00] <darkxst> bug 1049028
[00:01] <everaldo> cjwatson, do you see any problem to include updates and rebuild an 12.10.1 iso for UGR?
[00:02] <cjwatson> Not in general but I haven't looked at how UGR is laid out
[00:02] <cjwatson> (Nor am I going to at 1am :-) )
[00:02] <everaldo> cjwatson, just one last question them
[00:03] <everaldo> how did you guys build the ubuntu iso? is it a custom script or live-build?
[00:03] <cjwatson> live-build for the squashfs, a collection of stuff mostly involving debian-cd for the iso9660 container
[00:05] <everaldo> humm, good to know, I will move our squashfs build to live-build for 13.04
[00:07] <cjwatson> are you doing it by hand now or something?
[00:07] <darkxst> cjwatson so its just a small script, that runs a bunch of apt commands in a ch-root
[00:08] <everaldo> cjwatson, yes, debootstrap and apt-get install's on chroot
[00:08] <everaldo> cjwatson, https://code.launchpad.net/~ubuntu-gnome-dev/+junk/iso-build-script
[00:10] <cjwatson> I haven't looked, but live-build should be able to obsolete most handwritten scripts of that kind, yes
[00:11] <everaldo> cjwatson, any tutorial or sample about how you guys use live-build?
[00:38] <cjwatson> everaldo: google for my post to ubuntu-devel about it a year or so back
[00:40] <everaldo> got it https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html
[00:41] <everaldo> cjwatson, so simple... thanks :)
[00:51] <jbicha> everaldo: I think that's deceptively simple, at least I wasn't able to figure it out but maybe I'm too impatient
[00:51] <cjwatson> You'd have to hack on livecd-rootfs/live-build/auto/config a little
[00:51] <cjwatson> Shouldn't be desperately much
[01:33] <wookey> what's the package name of the thing that truncates changelogs on builds?
[01:33] <lifeless> binary-pkg-mangler ?
[01:33] <wookey> that's it
[01:34] <wookey> but I searched for that and failed to find.
[01:34] <micahg> pkgbinarymangler
[01:34] <lifeless> that thing :)
[01:34] <wookey> aha
[01:34] <wookey> it's vital for multiarch otherwise your changelogs don;t match up
[01:35] <micahg> do binNMUs have changelogs?
[01:36] <wookey> yes. There was some discussion of this on debian devel
[01:37] <wookey> you really want to take the binNMU change out of the changelog (and record it elsewhere) to avoid multiarch breakage
[01:37] <wookey> it's been bodged for the time being in dpkg, I think
[01:44] <cjwatson> wookey: But not so much of a problem for Ubuntu because we don't have single-arch binNMUs yet.
[01:44] <cjwatson> (And not planned for the near future.)
[01:58] <lifeless> cjwatson: I did a test for you to see whether you had regressed bug 803658 during Q cycle (and you had).
[01:58] <lifeless> cjwatson: I don't recall reverifying for you; did you end up reproducing the setup and validating that you didn't regress it ?
[01:58] <lifeless> cjwatson: or should I be ultra paranoid about upgrading that machine to Q ?
[02:03] <cjwatson> lifeless: as I mentioned at the time, I managed to reproduce it in simulation with manual dmsetup commands, and I believe I fixed it, although it's true you never positively confirmed that
[02:04] <cjwatson> It's not explicitly in the changelog because I fixed it before releasing 2.00-3ubuntu1
[02:05] <cjwatson> (which was the first of the 2.00 merges to hit Ubuntu proper)
[02:10] <RAOF> Hm. The 12.10 desktop installer doesn't seem to see the existing Windows 8 partition on this system; it thinks both discs have no partition table. That's not wonderful.
[02:12] <RAOF> I guess it's time to redo that liveusb with a persistent partition so I can grab the logs.
[02:12] <lifeless> cjwatson: kk, thanks
[02:14] <TheMuso> RAOF: If I need to grab logs, and I used usb-creator to create the live USB drive, I go to a console, remount /cdrom read-write, copy logs, remount read-only to be safe, and shut down.
[02:14] <TheMuso> Thats worked for me in the past.
[02:15] <RAOF> TheMuso: Sounds good.
[02:15] <RAOF> cjwatson: Actually, you're awesome at everything - does apport work in the liveusb environment?
[02:46] <slangasek> darkxst, everaldo: so bugs 1069475 and 1069908 that jbicha was calling my attention to earlier are bugs with the CD and not with the grub2 package, correct?
[02:48] <darkxst> slangasek, yes
[02:48] <darkxst> slangasek, we got stung by the late changes to secure boot ;(
[02:50] <slangasek> darkxst: so I gather - sorry about that
[02:50] <slangasek> darkxst: is there somewhere else those two bugs should be reassigned?
[02:51] <darkxst> slangasek, we don't actually have a package for our build script currently,
[02:51] <darkxst> slangasek, maybe just assign them to jbicha?
[02:51] <slangasek> is there a launchpad project?  (since bugs can be reassigned from packages to projects, now)
[02:52] <darkxst> it lives in jbicha's + junk folder, but if that is the case we should make a project
[02:52] <slangasek> would probably be a good idea to :)
[02:57] <grueblur> I can has nexus?
[02:57] <grueblur> Surely a howto for 13.04?
[02:58] <grueblur> When? So I can set my OMG.
[02:58] <grueblur> I'll be in the saltmines.  Waiting, I suppose.
[02:58] <grueblur> ;_;
[02:59] <grueblur> Seven more days?
[03:04] <grueblur> Bestturingssysteem.
[03:07] <RAOF> As the proud father of a recently-newborn, than quit message is entirely wrong; there's nothing intuitive about the nipple :)
[03:08] <sarnold> hehe
[03:08] <darkxst> slangasek, how do I reassign bug to a launchpad project ?
[03:08] <darkxst> (https://launchpad.net/ugr-iso-build)
[03:09] <slangasek> darkxst: on the bug page, click the arrow next to 'grub2' under Affects; choose 'Project' and fill in the name
[03:14] <darkxst> slangasek, ok, got it. thanks
[03:30] <pitti> Good morning
[03:31] <sarnold> pitti: isn't it insanely early for you?
[03:31]  * slangasek waves to pitti
[03:31] <pitti> bdmurray: I reassigned 1053749 to davmail, as several people seem to have reproduced it with installing this package
[03:31] <pitti> hey slangasek
[03:32] <pitti> sarnold: it's a bit earlier than usual, yes; but my head started working, can't sleep any more
[03:33] <sarnold> pitti: heh, if the brain is already spinning, you might as well use it...
[03:45] <slangasek> pitti: there's no davmail package in the archive; furthermore, the bug is in failing to handle an existing dpkg database
[03:46] <pitti> indeed, just saw the LP error; I reassigned it to dpkg now and gave it a clearer title
[03:47] <slangasek> it's not a dpkg bug either
[03:47] <slangasek> this is existing data
[03:47] <slangasek> dpkg can't possibly undo it; the consumer needs to cope with the encoding issue
[03:51] <pitti> slangasek: so, back to "invalid" again then?
[03:51] <slangasek> how is it invalid?
[03:52] <slangasek> there's a crash on non-unicode input; this is a legitimate real-world situation; the client needs to cope with this
[03:54] <pitti> ooh, I see, sorry
[03:54] <slangasek> ok :)
[03:55] <pitti> so, I guess I'll just intercept/ignore it in u-d-common
[04:05] <skunk> where could I find the acer alps touchpad source code
[04:08] <RAOF> skunk: Shared between the kernel and xserver-xorg-input-synaptics
[05:20] <darkxst> is there anyway we can extpedite the evolution-data-server fix for gmail into -updates? Bug 1049028
[05:20] <darkxst> we are about to rebuild images to fix efi boot issues and would be nice to have that fix also
[05:21] <darkxst> (images for ubuntu GNOME remix)
[05:22] <RAOF> darkxst: How sure are we that the patch is safe?
[05:23] <darkxst> RAOF: very sure, its just installing missing files
[05:23] <darkxst> that said I guess there could be backs in the modules that it installs, since it has been broken since July
[05:23] <darkxst> s/backs/bugs/
[05:24] <RAOF> darkxst: Then I'll push it out now; it's had 3 days, and bugs in modules that weren't installed before are unlikely to be regressions.
[05:25] <darkxst> RAOF, well they were moved in July , but no one even noticed since then
[05:25] <darkxst> RAOF, and thanks
[05:26] <RAOF> Yeah; we got UOA, which actually works :P
[05:27] <micahg> darkxst:  RAOF: 3.6.0-0ubuntu3  is in the release pocket
[05:28] <RAOF> micahg: Not according to my rmadison output?
[05:29] <micahg> oh, eds, neverming
[05:29] <micahg> *nevermind
[05:29] <RAOF> micahg: Launchpad also seems to think that 3.6.0-0ubuntu3 is in quantal-proposed
[05:29]  * micahg was looking at evolution
[05:29]  * micahg really should go to sleep
[05:29] <RAOF> Ah, yeah.
[05:29] <RAOF> darkxst: Copied to quantal-updates (and raring).
[05:30] <darkxst> RAOF, thanks
[05:52] <darkxst> lol, how is this possible "UpgradeStatus: Upgraded to quantal on 2011-04-01 (529 days ago)"
[05:54] <RAOF> System clock out of sync?
[05:59] <darkxst> RAOF, yes that is a good explanation, but you might expect someone would notice that ;)
[06:02] <darkxst> I have another patch that needs sponsoring bug 1064354, patch has been committed upstream also
[06:21] <darkxst> RAOF, micahg, perhaps you could upload ^^ for me?
[07:01] <mvo> doko_: python-apt is building again, but there is a test failure that looks like something in subprocess
[07:03] <dholbach> good morning
[08:16] <tkamppeter> pitti, hi
[08:23] <hyperair> anyone here got a sandy/ivy bridge chip and is running unity?
[08:24] <Laney> yes
[08:25] <hyperair> Laney: could you try running powertop and seeing the rc6 stats?
[08:26] <hyperair> it's under the idle stats tab
[08:26] <hyperair> on my laptop it's stuck at 90+% active
[08:26] <hyperair> i'm wondering if that's supposed to be the case or if unity's sucking.
[08:27] <Laney> cc6?
[08:27] <hyperair> O_o
[08:27] <hyperair> no, it's RC6
[08:27] <hyperair> under GPU
[08:27] <Laney> don't see that
[08:27] <hyperair> Active, RC6, RC6p, RC6pp
[08:27] <hyperair> hmm
[08:27] <hyperair> werid
[08:28] <Laney> C{1,3,6}-IVB
[08:28] <hyperair> weird
[08:28] <Laney> anyway C6 is high
[08:28] <hyperair> maybe you don't have rc6 enabled.
[08:28] <Laney> dunno what it means though
[08:29] <hyperair> it's supposed to go down to C7
[08:29] <hyperair> mine spends most of the time in C7 for CPU
[08:29] <hyperair> but the GPU is spending most of its time active
[08:29] <hyperair> and since upgrading i've been getting these sporadic hangs
[08:30] <hyperair> [16938.783806] [drm:__gen6_gt_force_wake_get] *ERROR* Force wake wait timed out
[08:30] <hyperair> ugh
[08:57] <doko> mvo: both for 3.2 and 3.3?
[08:58] <RAOF> hyperair: Note that running powertop means that you'll have a blinking cursor on the screen, which means you'll be continually waking up the GPU for vsyncs.
[09:00] <hyperair> RAOF: hmmm. meaning that it never goes into rc6 unless the screen is completely still?
[09:01] <RAOF> hyperair: I don't know; I would assume that you'd still be able to get into rc6 even with a 60Hz timer. I'm just saying that powertop distorts the power metrics by running :)
[09:01] <hyperair> RAOF: well i was working on emacs, and leaving powertop running in the background, so i don't think it really counts
[09:01] <hyperair> but yes, blinking cursor
[09:02] <RAOF> Yes, it does, because the blinking cursor still means wakeups even when it's not visible - because of composite, all windows are always “visible”
[09:06] <hyperair> ah right.
[09:07] <hyperair> i actually just closed my terminal while leaving powertop running in screen and went away for the past 5 minutes, but when i came back it was 100%
[09:07] <hyperair> heh
[09:34] <doko> TheMuso, why is python3-louis an Arch: any package?
[09:57] <mvo> doko: http://paste.ubuntu.com/1299692/ <- this fails in py3.3, but works fine in 3.2 and 2.7 - should it?
[10:02] <doko> mvo, looking at the docs, it's found in 3.3.0 too
[10:07] <doko> mvo: hmm, don't see anything documented. the only thing I read is: "When stdout or stderr are pipes and universal_newlines is True then the output data is assumed to be encoded as UTF-8 and will automatically be decoded to text. All line endings will be converted to '\n' as described for the universal newlines 'U' mode argument to open()."
[10:07] <doko> but this is not 3.3 specific
[10:08] <mvo> doko: right, I can clarify with barry later if you want and add a workaround for now, but it seems like this is a unintended break in the new _save_input() in the subprocess modules
[10:08] <mvo> module
[10:08] <doko> mvo: u"u" does work in 3.2??
[10:08] <mvo> doko: no, just remove it there if you want to run the test
[10:09] <mvo> doko: its only needed for 2.7 and 3.3, its illegal on 3.0-3.2
[10:09] <mvo> (and in 3.3 its just doing nothing but makes porting easier)
[10:10] <doko> looks like _save_input was added for the new timeout parameter. looks like a bug
[10:11] <doko> mvo, can you add an issue to the tracker?
[10:11] <mvo> doko: sure, let me do that
[10:16] <cjwatson> mvo: I understood this as intentional - it certainly came up in python3-debian testing
[10:17] <cjwatson> It's documented in "Frequently Used Arguments" in subprocess
[10:17] <cjwatson> mvo,doko: http://paste.ubuntu.com/1299724/
[10:18] <mvo> cjwatson: so it was a mistake that this was accepted before?
[10:18] <cjwatson> That's my understanding
[10:18] <mvo> ok, thanks
[10:19] <cjwatson> I think you need to either not support 3.2, drop universal_newlines and do manual encoding/decoding, or do something clever I haven't thought of
[10:19] <mvo> if sys.version_info[0] < 3 and sys.version_info[1]  < 3: ... <- not very clever
[10:20] <cjwatson> can't remember if sending unicode to stdin with universal_newlines works with 3.2
[10:20] <mvo> I will check
[10:33] <doko> mvo: not more clever, but shorter: if sys.version_info[:2] < (3, 3)
[10:35] <mvo> doko: good point!
[10:36] <doko> mvo: at least for raring, it should be fine. we won't have 3.2 at the end of the cycle anymore, but 2.7 is another thing
[10:36] <cjwatson> sys.version < "3.3"
[10:36] <cjwatson> works too
[10:36]  * mvo nods
[10:36] <doko> yeah, assuming every alpha has the same behaviour
[10:37] <doko> for both cases ...
[10:37] <mvo> doko: ok, I prepare a upload
[10:39] <doko> so now all public python3 modules in main should be available for 3.2 and 3.3 (pending apt, qt4, qscintilla2)
[10:40] <doko> ScottK, ^^^
[10:42] <mvo> doko: do you know if someone update the Ubuntu.info.in template already?
[10:43] <doko> mvo: which package is this?
[10:43] <mvo> doko: python-apt
[10:46] <doko> mvo: no
[10:46] <mvo> doko: ok, I do it now
[10:47] <ScottK> doko: I have python-qt4 mostly ready.
[10:47] <ScottK> Should be ready later today.
[10:48] <doko> will you work on qscintilla too?
[10:48] <ScottK> I didn't look at it yet, but I will.  No promises about today.
[10:49] <mvo> doko: its ready now, should I upload?
[10:51] <infinity> doko: Well done on the first FTBFS of the series. :P
[10:51] <infinity> doko: (Is python3-dev meant to be python3.3 now, cause it sure looks like it's 3.2)
[10:52] <doko> infinity, yeah, you're just too late with the eglibc update ;-P
[11:00] <mvo> doko: uploaded, I will be back, lunchtime
[11:03] <xnox> doko: python3-apparmor is a compiled extenstion in main and built against (default py3) 3.2 only as far as I can see.
[11:04] <xnox> note the "python3 (<< 3.3)" deps.
[11:04] <doko> xnox, yes, according to pitti, it's only built for the default version (although I think it should be built for every one)
[11:06] <xnox> doko: Jamie and I were the last ones to look at it =) (providing py3 packages) and yes it cheats and builds against default only...
[11:06]  * xnox ponders if that automatically means I should be fixing it....
[11:08] <doko> xnox, heh, why not?
[11:08] <xnox> =_
[11:08] <xnox> =)
[11:08]  * xnox creates a symlink in /usr/share/debootstrap/scripts
[11:26] <mitya57> doko: will have a new fix in a minute.
[11:38] <mitya57> fire alarm in my house, will do that later
[11:38] <mitya57> :)
[12:07] <SpamapS> ch /win 6
[12:30] <xnox> doko: did you have to fix ac_python_devel.m4 anywhere yet to pick up multiarched/two python3.3-dev include locations?
[12:30] <doko> xnox, pythonx.y-config --includes should be used, if present, else the hardcoded stuff should be used as a allback
[12:31] <doko> but I don't know which ac_python_devel.m4 you refer to
[12:32] <xnox> doko: ack. didn't know about pythonx.y-config. Well ac_python_devel.m4 is a copy-pasted m4 macro from the autoconf-archive which tries to use pythonx.y -c "import distutils.sysconfig; print distutils..."
[12:33] <doko> xnox, and print exactly what?
[12:33] <xnox>        if test -z "$PYTHON_CPPFLAGS"; then
[12:33] <xnox>                 python_path=`$PYTHON -c "import distutils.sysconfig; \
[12:33] <xnox>                         print distutils.sysconfig.get_python_inc();"`
[12:33] <xnox>                 if test -n "${python_path}"; then
[12:33] <xnox>                         python_path="-I$python_path"
[12:33] <xnox>                 fi
[12:33] <xnox>                 PYTHON_CPPFLAGS=$python_path
[12:33] <xnox>         fi
[12:35] <doko> xnox, well, this already fails with print not a statement anymore ...
[12:35] <xnox> haha true =)
[12:36] <xnox> it should work if that thing returns a single item though ;-)
[12:36] <xnox> or something like (single item tuple?!)
[12:36] <xnox> but fails with python3.3 due to two items returned.
[12:36]  * xnox will use -config in a sec.
[12:37] <doko> xnox, so call the function a second time with plat_specific=1, and if the two values differ, append it
[12:37] <cjwatson> xnox: No, in Python 3 the requirement for parentheses in print() is a syntactic restriction, not dependent on the type of the argument
[12:38] <cjwatson> Try it yourself: foo = (1,); print foo -> SyntaxError
[12:39] <xnox> cjwatson: thanks.
[12:39] <xnox> doko: ack.
[12:41] <infinity> Bleh.  Someone really should fix https://bugs.launchpad.net/ubuntu/+source/libnih/+bug/997359
[12:41]  * infinity decides to have some lunch instead of arguing with computers.
[12:43] <doko> infinity, in the past, I did the upload of a new version as ~pre something to work around this
[12:46] <infinity> doko: Yeah, I've tracked down the workaround, it's still awful.
[12:46]  * infinity really lunches.
[12:51]  * xnox should do quilt push before copy pasting snippets of code. I did re-write print statements with sys.stdout.write when porting to python3....
[12:52] <cjwatson> Usually better to use from __future__ import print_function and then print().
[12:52] <cjwatson> sys.stdout.write is pretty clunky most of the time.
[12:52] <xnox> cjwatson: apparmor maintains 2.3+ compat.
[12:52] <cjwatson> Yeah, if you insist on prehistoric compat then you may need clunky :-)
[12:53] <cjwatson> Gotta wonder what the point is though.
[12:53] <cjwatson> I mean, Ubuntu 5.04 had 2.4 ...
[12:54] <xnox> to make it "secure" ? I dunno.
[12:54] <cjwatson> I doubt it :-)
[12:54] <cjwatson> Probably nobody's thought about it properly.
[12:54] <xnox> well apparmor is not ubuntu specific? or are we upstream?
[12:55] <cjwatson> Err, the point is that if we were shipping 2.4 7.5 years ago then you'd think most systems actually capable of running current apparmor would have something a bit newer than 2.3.
[12:55] <cjwatson> (OK, you want 2.6 for decent py3 compat, but even that we were shipping 3.5 years ago.
[12:55] <cjwatson> )
[12:56] <cjwatson> Though as it happens we are upstream for apparmor.
[12:59] <cjwatson> I think part of my point is that it's kind of daft to require Linux >= 2.6.36 and also go through contortions to support an ancient Python.
[13:03] <xnox> =))))
[13:04] <xnox> maybe nobody touched the python bits in a while...
[13:05] <ev> so `date --utc --reference=/var/log/installer +%s` will tell me the installation date. Is there anything that will (stably) give me the time of upgrade? The ctime off /etc/lsb-release?
[13:06] <xnox> ev: hm... something does add "upgraded on..." in apport hooks. I saw that on launchpad bugs.
[13:11] <ev> ahhh, so it does
[13:11] <ev> the mtime off /var/log/dist-upgrade/main.log
[13:11] <ev> cheers xnox
[13:12] <xnox> =)
[13:14] <xnox> ev: for me the modification time is 4th of january, but I am running quantal. I did $ apt-get dist-upgrade, instead of upgrade-manager -d
[13:15] <xnox> so results from me are bogus :-P
[13:15] <ev> yeah
[13:16] <cjwatson> yeah, I don't know of a 100% reliable and stable way
[13:17] <cjwatson> several semi-reliable and semi-stable ways which might produce something reasonable in aggregate :-)
[13:20] <ev> hm, maybe we chould take the ctime off /etc/lsb-release if it's newer than /var/log/dist-upgrade/main.log?
[13:22] <cjwatson> /etc/lsb-release will get you any base-files upgrade, perhaps one more recent than the dist-upgrade.
[13:23] <cjwatson> Depends which way you want to err.
[13:23] <cjwatson> You could parse /var/log/dpkg.log* for base-files upgrade timestamps *shudder*
[13:40] <wookey> what is responsible for bringing in pkgbinarymangler? It's not part of build-essential, which kind of makes it seem like it shouldn be part of crossbuild-essential, but if I cross-build anything MA-same without it then it's uninstallable
[13:40] <wookey> so it is fairly essential
[13:41] <wookey> IS there any reason why it shouldn't be added to the crossbuild-essential dep-list?
[13:43] <arges> ev, hi. should we schedule https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-fix-ddebs  for usr-r? There are a lot of postponed items and this is still a huge concern for our team. thanks
[13:43] <ev> arges: yes
[13:44] <cjwatson> arges: does it need re-discussion or just implementation time?
[13:44] <arges> cjwatson, both. I think there should be a bit of discussion
[13:44] <cjwatson> Why?
[13:45] <cjwatson> Generally we try to avoid rescheduling UDS sessions when we already know what needs to be done but just didn't get to it.
[13:45] <arges> cjwatson, well we got the extra space I believe on the ddeb server, so do we need to re instrument apport, or can we use the existing code?
[13:45] <cjwatson> We still ultimately need to replace this bodgy pile of hacks
[13:46] <ev> yeah, I thought Adam or someone was going to teach the publisher to include ddebs?
[13:46] <arges> cjwatson, yes. so perhaps there is still some value in discussion.
[13:46] <cjwatson> arges: I don't see any
[13:47] <cjwatson> It's been discussed to death
[13:47] <wookey> :-)
[13:47] <cjwatson> And another UDS session won't make it happen any faster :)
[13:47] <arges> cjwatson, ok so basically its just time to get those work items done. so those get tracked in that same blueprint
[13:47] <cjwatson> So that's just "re-target to raring", I think
[13:48] <wookey> ooh it has a name
[13:48] <cjwatson> which I have now done
[13:48] <wookey> only 4 years till we run out of letters
[13:49] <cjwatson> (possibly not in an optimal way, I just renamed the spec and left the done items there)
[13:49] <arges> cjwatson, ok that will be fine. the big thing that (i believe) has happened is that those older ddebs aren't being deleted
[13:49] <cjwatson> Until we run out of disk again
[13:51] <cjwatson> I mean, they weren't being deleted for fun, they were being deleted because there was nowhere left to go :-)
[13:51] <arges> cjwatson, sure. so being proactive about it would be good. if we are close then add more disks
[13:53] <cjwatson> sorry, but pitti *was* proactive, he notified IS as soon as it started to be close to be a problem
[13:53] <cjwatson> about two months before he had to start deleting stuff
[13:56] <arges> cjwatson, ok didn't know that
[13:57] <xnox> Why would anyone do "X-Python3-Version: << 3.3" ? it doesn't make sense.... as there is no version encoded paths with pure-python3 modules.
[14:00] <dobey> xnox: maybe python3.3 broke something in that module?
[14:00]  * cjwatson is in the odd position of hoping that a build finishes slower
[14:00] <cjwatson> (because it'll give me a better migration test case that way ...)
[14:01] <_jmp_> cjwatson: good to know, I saw pitti was stellar on it. I will talk w/ IS during UDS as its very important to us as well
[14:02] <xnox> dobey: how would the maintainer know that back in 2012-04-04? =)
[14:02] <cjwatson> The publisher changes are still the right longer-term fix, but they're a lot of work and they involve UE doing fairly significant Launchpad work, which we have some capacity for but only limited at this point
[14:02] <cjwatson> So if you can get by with just avoiding running out of disk for a cycle or two more, that would be very helpful
[14:02] <dobey> xnox: maybe they tried it against a local cpython build out of vcs?
[14:03] <pitti> arges, _jmp_: FYI, I got an ack from IS to give it loads more space RSN, and it already got plenty of extra space, so we don't need to kill ddebs anytime soon
[14:03] <_jmp_> cjwatson: yeah, they actually told us they will add enough disks to be space-problem-free for a while :) lets see :)
[14:03] <arges> pitti, : )
[14:03] <pitti> speaking of which, /me sets up ddebs for raring
[14:03] <_jmp_> pitti: awesome!
[14:03] <dobey> xnox: i'm only stating the only viable reason i can think of; not claiming to know why the person actually did it :)
[14:03] <_jmp_> pitti :))
[14:03] <cjwatson> pitti: Excellent, so hopefully infinity can spend time on the other zillion infrastructure things on his plate :)
[14:04] <xnox> dobey: I understand =) I'm trying to prove the maintainer wrong now. The unit-test passes fine
[14:04] <xnox> =)
[14:04]  * xnox calls it lies that 3.3 is not supported
[14:05] <cjwatson> xnox: no VCS logs or anything?
[14:06] <xnox> cjwatson: the python3 support was added with "<< 3.3" without any reasons stated.
[14:06] <xnox> python3-py package that is.
[14:37] <xnox> doko: $ python2.7-config --includes = -I/usr/include/python2.7 -I/usr/include/python2.7
[14:37] <xnox> which is funny
[14:39] <doko> yes, know
[14:39] <doko> n
[14:39] <xnox> ack =) doesn't hurt anything.
[14:58] <doko> python3.3 support for public extensions is mostly done for raring
[14:58] <doko> barry, xnox, ScottK, mvo: thanks for the help
[15:58] <doko> mitya57, any update on sphinx?
[16:00] <mitya57> doko: the test suite fails with python3.3, I'm slooowly debugging it
[16:00] <doko> ok
[16:01] <mitya57> doko: if it's urgent, we can just disable the failing tests (but I don't really like that idea)
[16:02] <doko> as long as sphinx works in raring, that's fine
[16:02] <doko> I mean, keeping the ftbfs, and using the existing binaries
[16:03] <seb128> slangasek, bdmurray, RAOF, SRU team: is there any plan to work on the queue backlog before UDS?
[16:03] <sconklin> @pilot in
[16:05] <seb128> SpamapS, bug #1067356, come on ....
[16:06] <seb128> SpamapS, needed to file a full other paper work bug for a one liner included with the upload?
[16:07] <seb128> hum
[16:07] <seb128> who rejected my seahorse SRU and why?
[16:07] <Laney> I asked for it
[16:07] <Laney> because I uploaded the new upstream
[16:08] <Laney> http://launchpadlibrarian.net/120749544/seahorse_3.6.2-0ubuntu1_source.changes
[16:09] <SpamapS> seb128: As the last time we chatted over IRC about this turned rather emotional, I'll decline to respond here. Please take it up with someone else or we can chat about it face to face if you'll be here in CPH next week.
[16:11] <seb128> SpamapS, can you put those back in the queue for other SRU team members to pick if you are not wanting to.
[16:11] <seb128> ?
[16:11] <seb128> Laney, ok, comment on the bug would have been good
[16:12] <SpamapS> seb128: I don't know how, but I have been told there is a way to unreject.
[16:12] <Laney> you can accept from rejected
[16:13] <Laney> but not put stuff back into unapproved (AFAIK anyway)
[16:13] <seb128> grrr
[16:13] <Laney> so reupload if that's what you want to do :-)
[16:13] <seb128> yeah, doing that
[16:14] <seb128> hopping to get a SRU team reviewer more tolerant for the next review
[16:14] <Laney> that reminds me to reupload glib too
[16:14] <seb128> Laney, what was the issue with this one?
[16:14] <Laney> i rebased the changelog instead of merging it
[16:15] <seb128> SpamapS, I've reuploaded, please don't reject this one, just let somebody who wants to review it do it
[16:15] <SpamapS> seb128: I more meant that you might want to take up a difference in policy with the others. But again, perhaps we should talk in person.
[16:16] <seb128> SpamapS, there is no writen rule saying that a SRU has to be have a record bug for every changeset in the upload
[16:17] <seb128> SpamapS, or if there is one please point me to it
[16:19] <dobey> seb128: the wiki page implies they do; unless there's a microrelease exception
[16:20] <seb128> dobey, "imply", where?
[16:20] <dobey> https://wiki.ubuntu.com/StableReleaseUpdates#Fixing_several_bugs_in_one_upload
[16:21] <seb128> dobey, that upload is not a kitchen sink one, it has 2 fixes, one being a one liner for a segfault I've no testcase about
[16:22] <seb128> e.g those bugs that never get verified
[16:23] <SpamapS> seb128: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure  .. The first requirement is that one records these fields in a bug report.
[16:23] <dobey> seb128: i'm not trying to argue that you're right or wrong. i'm just saying that my reading of that section (in combination with the main Procedure section above it, and the microrelease section below it) suggests that a bug needs to exist for each fix, and each fix needs to close those bugs in the changelog.
[16:24] <seb128> SpamapS, well, I've those fields, I just included a one liner upstream fix because I though it would improve things and wouldn't be a big deal
[16:24] <seb128> *shrug*
[16:24] <SpamapS> seb128: that is the last I'll respond about it. as I said, I'd prefer that we discuss in person, or that you approach somebody else on the SRU team about this.
[16:25] <seb128> SpamapS, fair enough
[16:25] <seb128> SpamapS, thanks
[16:25] <seb128> well in any case I've reuploaded, I don't intend to register a new bug and try to find a testcase for that a non reproducible segfault
[16:26] <seb128> so if somebody wants to accept those fixes great, otherwise it will stay broken for users and I will have lost my time on the SRU
[16:28] <dobey> seb128: well, you don't necessarily need to find a test case for extremely hard to reproduce bugs. if the code does the right thing to fix cases like that, it should be fairly obvious what the code is doing, and a simple "This is nigh impossible to force to happen, but the code is correct and obviously fixes this crash." for the [TestCase] in a bug.
[16:28] <dobey> seb128: from the IRC conversation, it seems to me like the issue is more the lack of the bug, than the testcase itself, no? :)
[16:30] <seb128> dobey, I batched 2 fixes in one paperwork trail, most SRU reviewers are not that picky and let those in
[16:31] <seb128> when fixes are easy ones that can be tested,reviewed easily
[16:31] <seb128> but whatever
[16:31] <seb128> that is more discussion time that the topic is worth, I bring it at UDS with the SRU guys
[16:33] <dobey> well, i don't know if my opinion matters, but i generally agree with having a separate bug for separate fixes. it helps with tracking the changes, in case some regression happens later with the fix; and it provides better information to the users about what is actually getting fixed, when they upgrade and look at the changelog entries.
[16:33] <dobey> oh well :-/
[16:52]  * xnox is confused why sbuild pyside gives me sbuild-build-depends-pyside-dummy : Depends: libphonon-dev but it is not going to be installed
[17:04] <slangasek> xnox: sounds like uninstallable or un-co-installable build deps
[17:04] <xnox> slangasek: I wish it would either tell me, or filter out and use the other alternative build-dep =)
[17:06] <slangasek> xnox: well, "it" is apt and apt doesn't give very good diagnostics in this case unless you crank the debugging up :)
[17:07] <xnox> something tells me that building 4.7really4.6 versions strings with libqt4-dev (>= 4:4.7.0) is not going to go down that well.
[17:07] <xnox> meh... off to play volleyball =)
[17:13] <xnox> slangasek: well at least pbuilder-dist is smarter - phonon-backend-null : Conflicts: phonon-backend which is a virtual package. The following actions will resolve these dependencies: and goes off to install phonon instead of phonon-backend-null
[17:14] <slangasek> sbuild used to be smarter too, until it switched to using apt as its build-dep resolver :/
[17:14] <mitya57> barry, doko: was there any change in python3.3 that could cause it to think that file name is "<string>"?
[17:14] <micahg> xnox: you might need --resolve-alternatives
[17:14] <mitya57> (maybe for some objects that are not really files but python3.2 thought them were)
[17:15] <mitya57> I can't find anything related in the release notes
[17:16] <xnox> micahg: thanks, I'll try that..... while sbuild is nice I find pbuilder more out-of-the-box friendly. E.g. my customisation file for sbuild is longer than the one I have for pbuilder-dist.
[17:16] <xnox> arguably pbuilder-dist is a config wrapper.....
[17:32] <mitya57> doko: I've spent three hours on that issue, and I give up, at least for today :(
[17:33] <mitya57> maybe the best idea will be to ping upstream and make them fix the issue themselves
[17:34] <mitya57> barry: you said you know upstream — maybe you can do that? — bug is https://bitbucket.org/birkenfeld/sphinx/issue/1008/test-failures-with-python-33.
[17:47] <ceolin> hey guys, someone c
[17:48] <ceolin> can tell me if appmenu requires a patched version of gtk and qt ?
[17:55] <hyperair> Laney: are you by any chance seeing GPU hangcheck messages and getting these short spurious hangs with unity in quantal?
[19:21] <maco> what's that debian.org site where you can look up a package, and it tells you what versions are in each debian release and ubuntu release?
[19:23] <slangasek> maco: packages.debian.org?
[19:23] <broder> snapshot.debian.org
[19:24] <broder> oh wait, what slangasek said i think
[19:24] <slangasek> though I had never heard that packages.d.o tracked Ubuntu versions
[19:24] <maco> no, the pink site
[19:24] <slangasek> the what
[19:24] <jibel> maco, http://qa.debian.org/madison.php ?
[19:24] <maco> nope
[19:25] <maco> shows the last few bugs reported on that package too
[19:26] <slangasek> well, if it's not linked from dex.http://dex.alioth.debian.org/ubuntu/ then I really don't know
[19:26] <jibel> maco, http://packages.qa.debian.org maybe ?
[19:27] <maco> jibel: yeah! thanks!
[19:30] <maco> woah, 7 digit bugs in lp! O_O
[19:30] <maco> i thought i'd pasted the bug number wrong. wow
[19:32]  * maco scrapes the rust off the old packaging knowledge
[20:34] <Laney> hyperair: not noticed that, no
[21:09] <TheMuso> doko: A mistake on my part.
[21:10] <dupondje> Got a really strange issue with LightDM, sometimes when I boot, I see the console cursor on tty7 (trough the lightdm window). If I then switch to tty1 for example, I still see lightdm visible (only partly). Is that a known bug?
[21:24] <netdur> a dialog out of nowhere started asking me (every few minutes) for my gmail password http://imgur.com/q5T1S,frM7j
[21:25] <netdur> it is modal and doesn't say which program is requesting access
[21:25] <slangasek> netdur: do you remember clicking 'Install' on an in-browser dialog asking you if you want to enable the gmail webapp?
[21:26] <slangasek> I believe that's what's causing the dialog.  I agree that it's not a very clear dialog though.
[21:26] <xnox> ScottK: did you happen to have CMake fixes to query python3.3-config for --includes and --ldflags already?
[21:26] <micahg> xprop | grep CLASS will tell you what program it is
[21:26] <slangasek> netdur: so a bug report against the unity-webapps-gmail package may be in order
[21:26] <netdur> slangasek: no I did not, I was using gnome-shell, I decided to give unity a try and this started spamming me
[21:27] <xnox> ScottK: or will you be looking at pyside?
[21:27] <slangasek> netdur: well, unity-webapps-gmail is not installed by default, so I'm not sure how that would happen without an explicit user request
[21:28] <slangasek> netdur: if it's not the gmail webapp itself, it might relate to Ubuntu Online Accounts.  Not sure what package that would be though; if in doubt, probably report a bug against unity
[21:29] <netdur> slangasek: all right, I will report bug against unity but for now, how do I disable it?
[21:29] <slangasek> netdur: I couldn't tell you, sorry
[21:30] <darkxst> netdur, remove any extra accounts from GOA!
[21:30] <darkxst> netdur, and/or evolution
[21:32] <netdur> darkxst slangasek is this dialog trusted, can I just type password to make go away?
[21:33] <darkxst> netdur, yes but you will have duplicate accounts setup (adding gmail accounts was broken previously and any attempts would have just been queued up
[21:54] <ScottK> xnox: No and no.
[21:56] <ScottK> You might ask OdyX about getting pyside to work with 3.3.  He sometimes cares about both it and Ubuntu enough to do something.
[21:56] <xnox> ScottK: ok =) my CMake is a bit rusty, but it's like waf but in ALL_CAPS I should be ok =)
[21:57] <ScottK> It's not at all like waf in any way that matters ...
[21:58] <ScottK> debfx might be able to help with CMake.
[21:59] <xnox> ScottK: it was meant to be a joke =) none of them are alike in any useful way. I did port a couple of packages from autoconf to CMake with cross-building to win & mac. I should figure it out =)
[22:00] <xnox> there are 16 packages left, before I can start py3.3 by default rebuild
[22:01] <ScottK> Well.    It won't make it today.
[22:03] <ScottK> infinity: ouch.
[22:04]  * ScottK makes a note for when he's feeling like a bit of D&D in Copenhagen.
[22:05] <xnox> So I checked my Guide and indeed waf was inspired by scons, but neither have direct ancestry to CMake.
[22:06] <maco> i cant figure out if these are real words you're all saying
[22:07] <ScottK> yada was real, but it's, mercifully, dead now.
[22:08] <maco> http://wiki.debian.org/UsingQuilt <-- useful page
[22:08] <infinity> maco: They're not only real words, they're all expletives.
[22:08] <maco> i just used quilt without getting T'd off for about the third time ever
[22:08] <infinity> Although, as much as it caused me no end of grief, I can't deny that 'scons' always made me a bit hungry.
[22:08] <mwhudson> family channel!
[22:08] <maco> (and thats without having used it in like two years)
[22:08] <ScottK> Waf upstream is sufficiently distro hostile that it's impossible, by design, to package it usefully.
[22:09] <jelmer> ScottK: I don't think it's impossible to have it packaged, but working with him to come to a good solution will take time/patience.
[22:09] <xnox> waf upstream is highly responsive to issues on obscure platforms e.g. hpux and patches are written and offered for testing really fast.
[22:10] <ScottK> jelmer: DktrKranz tried.
[22:10] <xnox> ScottK: jelmer: I don't by the whole argument that waf compressed bz2 is evil, yet distributing windows binaries in original tarballs is ok with ftp-masters
[22:11] <xnox> s/by/buy/
[22:11] <jelmer> ScottK: I've tried as well, and have worked quite well with him.
[22:11] <xnox> see lintian lab emited tags for hundrets of instances.
[22:11] <jelmer> ScottK: (Resolving other issues that is)
[22:12] <ScottK> I'm going on the results of DktrKranz trying.
[22:12] <jelmer> ScottK: DktrKranz's way of working with him was quite confrontational too, and that just made things worse.
[22:13] <ScottK> Hmmmm.  That's not usually his style.
[22:14] <ScottK> xnox: the difference, IIRC, is you don't need the Windows binaries to build the package.
[22:14] <jelmer> ScottK: actually, I retract that. The tone from several Debian developers towards waf upstream was very confrontational, rather than constructive.
[22:15] <ScottK> ok.
[22:15] <xnox> ScottK: little did people know about some of the debian packages =)
[22:15]  * xnox walks away grinning


[04:02] <JackFrost> Debian #918199 \o/
[09:34] <ochosi> JackFrost: finally
[11:03] <JackFrost> ochosi: you at least testing the gsettings backend? :3
[22:21] <ochosi> JackFrost: nope, don't have much time for playing with anything these days


[04:44] <Sarvatt> well, one day of trying to break stuff with mesa 7.9~git20100923-0ubuntu1 on 945gme and nouveau down and nothing spotted yet
[06:32] <ScottK> Sarvatt: I notice a number of packages still depending on mesa-utils: http://people.canonical.com/~ubuntu-archive/NBS/mesa-utils - What is the replacement package for mesa-utils?
[13:18] <Riotta> does this is ubuntu-x-swat or x-edgers channel?
[23:06] <RandBrittain> Hm, I thought it would be okay to install this fglrx update, since it claimed to build in amd64 even if it didn't in i386. Clearly this was overly bold of me, for now I can't boot normally.
[23:06] <RandBrittain> Is my best bet going to be going back to the last version of fglrx (and, incidentally, what's the best way of doing that?)


[00:15] <msx> hello guys, i'm starting with Juju (so far loving it) and while I'm at the configuration stage I want to ask you: how do you usually use Juju, straight from the r00t account (seems somewhat dangerous to me), from a special account setup to that end (like use "juju") or just from the account you usually use to manage your Ubuntu servers?
[00:16] <sarnold> msx: so far as I've used juju myself, I've just used my own user account; if I had shared administrative tasks with other users, I'd likely take the 'juju' user route and have people ssh in or sudo in ..
[00:17] <msx> sarnold: that's what i was thinking, thanks a lot sarnold :D
[00:24] <lazyPower> msx: its common practice to use a jump host when sharing it with a team
[00:25] <lazyPower> there are newer features in the pipeline that will make sharing administrative control of your juju infrastructure easier, but until thats 100% fleshed out and documented, my suggestion would be to use a shared host/account for management.
[00:37] <msx> lazyPower: hei! Sorry for the late reply. Yes, we are a very small team (just two) so my idea is to have both of us the same level of access to all Juju's features, thus I will be creating a juju account tailored for this end
[00:37] <msx> lazyPower: thank you very much for your suggestion :)
[00:37]  * lazyPower hat tips
[00:37] <lazyPower> any time
[00:37] <msx> "hat tips" lol
[03:50] <davecheney> marcoceppi: https://bugs.launchpad.net/bugs/1281394
[03:50] <_mup_> Bug #1281394: uniter failed to run non-existant config-changed hook <juju-core:New> <https://launchpad.net/bugs/1281394>
[03:50] <davecheney> ^ config-changed isn't manditory, right ?
[04:16] <lazyPower> davecheney: none of the hooks are mandatory afaik
[04:16] <lazyPower> it basically creates an immutable service, but its not required.
[04:17] <davecheney> lazyPower: thanks for confirming
[04:17] <davecheney> this is a regression then
[04:17] <davecheney> deploying the ubuntu charm *used* to work
[04:17] <davecheney> and that is a charm that doens't get much simpler
[04:18] <lazyPower> indeed. i'm running the amulet test against 0.17.2 that arosales wrote
[04:25] <davecheney> lazyPower: what does , juju deploy cs:ubuntu
[04:25] <davecheney> give you ?
[04:46] <lazyPower> davecheney: loading 1 sec.
[04:46] <lazyPower> also, the amulet test passed
[04:47] <davecheney> well shit
[04:47] <davecheney> one of us did something wrong
[04:48] <lazyPower> which version of juju are you running davecheney?
[04:48] <davecheney> <IP_ADDRESS>
[04:48] <davecheney> (trunk)
[04:48] <davecheney> what does juju status ubuntu/0 say
[04:48] <lazyPower> must be in trunk, <IP_ADDRESS> isn't complaining about the config-changed hook
[04:48] <davecheney> 2.1 ?
[04:48] <davecheney> what is that
[04:48] <davecheney> are you doing upload tools from a release vesion ?
[04:49] <lazyPower> http://paste.ubuntu.com/6952698/
[04:49] <lazyPower> nope
[04:49] <davecheney> lazyPower: something is very strange then
[04:49] <davecheney> release tools do not have a 4th digit
[04:50] <davecheney> oh, you're using the local provider
[04:50] <davecheney> never mind
[04:50] <lazyPower> i can check on a cloud provider, 1 moment
[04:51] <davecheney> please
[04:51] <davecheney> hp if oyu can
[04:51] <lazyPower> sure thing
[04:57] <lazyPower> davecheney: http://paste.ubuntu.com/6952734/
[05:02] <davecheney> weird
[05:02] <davecheney> can you have a look in the unit logs on that machine and see what happened
[05:03] <davecheney> did it try to execute the config-changed hook
[05:03] <davecheney> did it ignore it
[05:03] <davecheney> etc
[05:18] <lazyPower> davecheney: http://paste.ubuntu.com/6952783/
[05:19] <lazyPower> i see nothing relating to skipping the config-changed hook. let me check the unit-0 log
[05:20] <davecheney> lazyPower: yeah, that paste is the machine agent
[05:20] <lazyPower> yeah nothing in the controller node's logs either
[05:20] <davecheney> wont' be
[05:21] <davecheney> will only be in machine-1:/var/log/juju/unit-ubuntu-0.log
[05:22] <lazyPower> that was included in that first paste
[05:22] <lazyPower> it shoul dhave been appended at the bottom
[05:22] <lazyPower> i did a cat *.log | pastebinit
[13:07] <xp1990> Hi! is anyone here available to help me with a problem?.
[13:07] <xp1990> I'm using juju 1.16.6
[13:07] <xp1990> and the I'm getting the old index file contains no data for cloud, error.
[13:07] <xp1990> I have generated imagemetadata.json and index.json
[13:07] <xp1990> and uploaded them, using swift, to my cloud public bucket
[13:07] <xp1990> which is named juju-<hash>/streams/v1/
[13:08] <xp1990> then the two json files are there
[13:08] <xp1990> yet I still get an error when running juju bootstrap
[13:09] <xp1990> that says the index file has no data for cloud  {RegionOne <ip>}
[13:17] <marcoceppi> xp1990: can you pastebin your imagemetadata.json and index.json?
[13:18] <tomixxx3> marcoceppi: hi, do u know already a bug fix for the "internal server error" of openstack dashboard?
[13:21] <marcoceppi> tomixxx3: you have to remove django 1.5 and install 1.3, I don't have the exact steps yet
[13:23] <tomixxx3> marcoceppi: kk
[14:12] <hazmat> marcoceppi, do you have any amulet tests for mysql?
[14:13] <marcoceppi> hazmat: just some very light weight skels, nothing of concequence yet
[14:14] <hazmat> marcoceppi, k, just checking cause of addition of ssl support to interface
[14:14] <marcoceppi> hazmat: ah, yeah that's fine, I'll make sure a test exists to gen ssl certs and validate those
[14:16] <hazmat> marcoceppi, so.. i'm taking a slightly different approach.. might be more trouble than its worth.. but its much easier to configure.. ie just set ssl="on"  or ssl="only"and mysql services becomes a ca and hands its ca fingerprint on the relation, with only going to establish client cert passing and checking.
[14:16] <marcoceppi> hazmat: sounds sexy to me
[14:16] <marcoceppi> I like making it easier for users
[14:17] <hazmat> yeah.. i still have to verify its sane for ha setups.
[14:17] <hazmat> but significantly easier for end users and bundles.
[14:17]  * marcoceppi nods
[14:49] <dimitern> hazmat, it seems the fix for bug 1174610 sadly cannot land yet, due to 1.16 having direct state access, and needs to be postponed until the next release
[14:49] <_mup_> Bug #1174610: unit ids should be unique <regression> <juju-core:Triaged by dimitern> <https://launchpad.net/bugs/1174610>
[15:04] <hazmat> dimitern, yeah.. saw the bug email.. no worries. glad to see it get some attention
[16:06] <tomixxx3> marcoceppi: do u think i can investigate the i-net on my own in order to get openstack-dashboard to run? or is it really hard to change django version?
[16:11] <marcoceppi> tomixxx3: not that hard, just uninstall django
[16:12] <tomixxx3> so, sudo apt-get purge django1.5 and sudo apt-get install django 1.3?
[16:14] <roadmr> tomixxx3: yes
[16:14] <roadmr> tomixxx3: *some* parts of the dashboard will still error out, I got that but haven't looked into it further
[16:15] <roadmr> tomixxx3: still you should be able to get an overview and get the all-important credentials
[16:15] <roadmr> (it's mostly some graphs and reports that still fail)
[16:15] <tomixxx3> ok..
[16:17] <tomixxx3> do i have to uninstall/restall django only on the openstack-dashboard node?
[16:18] <tomixxx3> roadmr: do i have to uninstall/reinstall django only on the openstack-dashboard?
[16:18] <tomixxx3> +node
[16:25] <roadmr> tomixxx3: yes, only on that one
[16:25] <roadmr> tomixxx3: juju ssh openstack-dashboard/0 should get you where you need to be
[16:25] <tomixxx3> roadmr: kk
[16:36] <jamespage> marcoceppi, OK - I'm going to bite the bullet and write some amulet tests for the openstack charms
[16:36] <marcoceppi> jamespage: there's a known bug with subordinates that's being patched
[16:36] <jamespage> I need better automated testing in the charm itself - deployer configs are OK - but its hard to get contributors todo that if they don't know about it
[16:37] <jamespage> marcoceppi, is there a good example/guide I can follow?
[16:37] <jamespage> and can I use deployer configs?
[16:48] <tomixxx3> roadmr: ok i have installed django 1.3 now but i still get the interal server error. do i have to restart apache or sth similar?
[16:48] <roadmr> tomixxx3: hmm maybe, I don't remember if I did
[16:48] <tomixxx3> btw, i had to use other commands than sudo apt-get purge or install
[16:48] <roadmr> try it and let me know if it works :)
[16:48] <roadmr> tomixxx3: oh really?
[16:49] <tomixxx3> yes, pip install Django==1.3 to install django for example
[16:49] <tomixxx3> can i simple reboot the nodes?
[16:50] <roadmr> yes that should work
[16:50] <roadmr> tomixxx3: didn't apt-get install python-django=1.3.1-4ubuntu1.8 work? (assuming a 12.04 node)
[16:51] <tomixxx3> roadmr: dunno i have not tried this, but when i do some i-net investigation, i have read that everyone uses other commands
[16:51] <roadmr> tomixxx3: well you could also pip install django=1.4 which I think is the correct version for grizzly
[16:52] <roadmr> tomixxx3: I specifically didn't want to go too deep (at that point I may as well ditch juju and manage the servers manually) so I stuck with what I could do with apt-get
[16:54] <tomixxx3> roadmr: np, i just investigated google and i have found that other commands so i have tried them :-)
[16:55] <roadmr> tomixxx3: cool!
[16:56] <tomixxx3> roadmr: an mathematician told me: "todoay, the only important thing is to know WHERE to search" ^^
[16:57] <roadmr> tomixxx3: indeed :)
[16:57] <tomixxx3> ohoh keystone failed. "hook failed: "config-changed"'
[16:58] <tomixxx3> but openstack dashboard is online :-)
[17:00] <roadmr> \o/
[17:16] <tomixxx3> i got the following "Unable to communicate with identity service: [Errno 111] Connection refused. (HTTP 400)" when i try to manually invoke "change-config"
[17:17] <xp1990> Hi guys, got a bit of an issue, during bootstrap my client will just hang at attempting to connect to
[17:17] <xp1990> Any idea how I could fix this, or debug it?
[17:19] <xp1990> http://pastebin.com/fpGTPCUd
[17:22] <tomixxx3> oh keystone is working now oO
[17:27] <tomixxx3> i manually executed ./hooks/change-config and i got this http 400 exception but keystone is indicated as "started" when i execute "juju status"
[17:32] <jamespage> marcoceppi, omg - /usr/bin/python3 /usr/bin/easy_install3 cherrypy
[17:32] <marcoceppi> jamespage: ugh, I need to stop cherrypy for something else
[17:32] <marcoceppi> s/stop/drop/
[17:32] <jamespage> marcoceppi, i object more to 'easy_install;
[17:33] <jamespage> marcoceppi, currently means I can't run amulet inside our QA cloud
[17:33] <marcoceppi> jamespage: what, would pip be better? I should actually just have the tarbal in there and use a venv I guess
[17:34] <jamespage> marcoceppi, archive or contains in charm good for me
[17:34] <marcoceppi> I'll use something from the archive
[17:38] <stub> What is the syntax in an amulet test to deploy 'this charm'? It seems to be d.add('mycharm'), but that seems  to be hitting the charm store and failing with a 404 (since the charm isn't in the store yet)
[17:46] <jamespage> stub, I was just about to ask the same thing
[17:46] <jamespage> stub, I need a pre-flight test prior to submission or to review a MP
[17:46] <jamespage> marcoceppi, ^^ is that possible?
[17:47] <marcoceppi> stub jamespage that's a known issue that's being patched in 1.2.9 - it'll deploy using local, but will attempt to do a remote lookup when running relation grafting
[17:48] <marcoceppi> so it does a lookup against the charmworld api, quite annoying I know
[17:48] <stub> that's ok, it means I get to submit my new charm without having to debug these tests ;)
[17:49] <marcoceppi> stub: technically we don't require tests..yet ;)
[17:49] <stub> I require tests ;)
[17:49] <jamespage> marcoceppi, confused
[17:50] <marcoceppi> jamespage: sorry, when you d.add() charm, if charm is the name of the current charm the test is being run from it'll use that in it's deloy schema. However, later on down the road in the whole amulet stuff, it does a lookup against charmworld (where you're getting the 404) to get relation details. It's failing there
[17:51] <jamespage> marcoceppi, ok- so it's using the local charm - I'm writing tests for an existing charm so that's ok I think
[17:52] <marcoceppi> jamespage: yeah, it autodetcts if you're in a charm, when you run d.add('charm') and don't specify a charm to pull from, it'll check if the current charm the test is running from is the charm added and use that path for the deployer file, otherwise it'll expand the url to use the charmstore
[17:52] <jamespage> marcoceppi, its used bzr to clone the charm into the deployer directory right?
[17:52] <marcoceppi> jamespage: pretty much, yes
[17:52] <jamespage> OK - so any changes have to be commited to the branch first
[17:52] <jamespage> I understand
[17:53] <marcoceppi> jamespage: actually, I think it does a copydir, I need to verify
[17:53] <marcoceppi> pretty sure I did that instead to git charms would still work
[17:54] <jamespage> marcoceppi, looks that way
[17:56] <jamespage> marcoceppi, no - I can't tell
[17:56] <marcoceppi> jamespage: actually, it looks like it leaves it up to deployer
[17:57] <stub> Oh, charm proof wants a copyright now... anyone know what I should be using?
[17:57] <marcoceppi> stub: an OSI approved license
[17:58] <jamespage> marcoceppi, what's the assumption on where the things in tests/ get run from? the root?
[17:58] <jamespage> of the charm?
[17:58] <marcoceppi> jamespage: CHARM_DIR
[17:58] <stub> So wack a GPL3 on there since this is on Canonical time
[17:59] <marcoceppi> stub: sure, a lot of people have been doing the debian style copyright file
[18:00] <marcoceppi> stub: somethign like this, https://github.com/charms/wordpress/blob/master/copyright
[18:00] <marcoceppi> but basically, just who owns the copyright, and the license for all the charm files
[18:00]  * stub copy pastas
[18:01] <stub> Did you really write that charm in 2012?
[18:02] <marcoceppi> stub: yes, it's an old ass charm
[18:03] <marcoceppi> and that was a re-write of the original charm, so it existed even before that
[18:07] <jamespage> marcoceppi, I've not got this far yet but does the deployer tidy up after itself?
[18:07] <marcoceppi> jamespage: how so?
[18:07] <jamespage> i.e. will it destroy the services ready for the next run
[18:07] <marcoceppi> jamespage: yeah, so each test file gets a fresh bootstrap, unless you set a certain flag
[18:08] <marcoceppi> jamespage: you can log the output of the test run using the -o flag with juju test, which will copy all the logs from the run to the path in -o
[18:09] <jamespage> marcoceppi, juju test was the bit of magic I was missing
[18:09] <marcoceppi> jamespage: oh, yeah, sorry, amulet and juju-test are decoupled. Ones a framework for writing tests the other is the test executor
[18:11] <jcastro> utlemming, how close to non-beta do you consider the vagrant boxes?
[18:12] <marcoceppi> utlemming: on a related note, the mounts are broken in the latest images, where should we file bugs?
[18:12] <jamespage> marcoceppi, ah - so I probably don't want to be installing amulet in tests/01-setup
[18:12] <marcoceppi> jamespage: you probably /do/ want to be doing that
[18:13] <jamespage> marcoceppi, yeah - but juju tests bootstraps and environment to run that script
[18:13] <marcoceppi> jamespage: I'm working on adding isolation to juju-test, so running it will create an LXC that executes the tests without dirtying your system
[18:14] <marcoceppi> jamespage: oh, yeah, that's another issue. For the time being people have been making the script non-executable, for the sake of time you can just feed the juju-test plugin the tests  you want to run
[18:14] <marcoceppi> ie: juju tests 02-other-test 03-this-thing
[18:14] <marcoceppi> to bypass waiting for a setup/teardown to install deps
[18:14] <jamespage> marcoceppi, ok - nice
[18:27] <arosales> jcastro: do you know if http://askubuntu.com/questions/134977/juju-stuck-in-pending-state-when-using-lxc is still valid for 1.16.x release?
[18:30] <marcoceppi> arosales: tjat
[18:30] <marcoceppi> that's a really old release of juju
[18:32] <marcoceppi> arosales: as in, that's python juju
[18:41] <jcastro> I voted to close it
[18:48] <arosales> jcastro: marcoceppi: ack that is what I was thinking based of the comments and release
[18:48] <arosales> thanks
[19:01] <hazmat> and mostly likely its nothing to do with juju but the lxc version of the time if memory serves
[19:01] <jcastro> yeah, mostly I want it deleted so we can get the google search namespace back
[19:01] <hazmat> hmm..
[19:02] <hazmat> actually that quetsion/answer is still revelant
[19:02] <hazmat> ufw can still interfere with local provider
[19:02] <hazmat> jcastro, ie.. this is still a real possibility https://bugs.launchpad.net/juju/+bug/998238
[19:03] <_mup_> Bug #998238: local provider unit agents get stuck in pending state because of host firewall blocking communication <pyjuju:Triaged> <https://launchpad.net/bugs/998238>
[19:03] <hazmat> its dated but the symptons and solutions are still the same
[19:03] <jcastro> huh
[19:03] <jcastro> I wonder if we can put a check in core and at least spit something out?
[19:03] <hazmat> bugs away
[21:53] <lazyPower> utlemming: is there a specific launchpad project you'd like me to open bugs against the virtualbox images? I went looking for cloud-images and have found no such project or relevant projects  - the closes was cloud-init.
[21:53] <lazyPower> *closest


[13:51] <tdr112> afternoon
[13:52] <zmoylan-len> hi
[13:54] <tdr112> hey zmoylan-len, did you make it to the drinks last night
[13:54] <zmoylan-len> no, got caught up doing some shopping and couldn't make it
[13:55] <zmoylan-len> that and the gaa thing going on in the city would have curtailed my getting about
[13:55] <tdr112> I missed it too
[14:09] <czajkowski> aloha
[14:11] <tdr112> hey czajkowski, still in Dublin ?
[14:11] <czajkowski> yup
[14:11] <czajkowski> in our kick off all day today and tomorrow
[14:12] <czajkowski> thursday back to UK
[14:14] <tdr112> who will eat all of the eggs , you will have way too much
[14:21] <czajkowski> Jon will visit a the weekend to his family so we'll give them lots
[14:31] <tdr112> :)