[13:35] <BluesKaj> Hiyas all
[14:50] <janskyview> hi everyone, my machine doesn't  have a serial port and i'm trying to write a java application that reads and writes to a serial port, do you know any emulators please?


[11:41] <Zic> hi, I need informations about forking channel of a LocoTeam : recently, an user of #ubuntu-fr was banned for no respect of the CoC, he forks #ubuntu-fr to #*buntu-fr. He spams #ubuntu-fr, can we contact Freenode Staff to close this channel to not respect the Ubuntu LoCo policy ?
[11:41] <Zic> (I'm a moderator of #ubuntu-fr channel)
[11:41] <jpds> 'jour Zic
[11:41] <Zic> bonjour jpds :)
[11:43] <jpds> I'm sure the IRC Council could ask to have the channels closed down and forwarded to #ubuntu-fr
[11:44] <jpds> elky: could you look above? :)
[11:44] <elky> jpds, just noticed
[11:44] <Zic> I adverts them, channel owner and user of #*buntu-fr
[11:44] <jpds> (noticed you were busy in -ops)
[11:44] <Zic> I'm ban from #*buntu-fr
[11:45] <Zic> (because I'm the moderator who set the ban against this user)
[11:45] <Zic> I'm using mibbit gateway to advert them
[11:48] <jpds> Zic: bad boy!
[11:48] <Zic> On the topic : « salon des kicks, banis ou fuyant de l'officiel » => possible translation « channel where you can escape from kick/ban of the official channel »
[11:48] <Zic> :)
[11:48] <jpds> Zic: what does "< ~danico> personne pour un ptit coup de main?????" mean?
[11:48] <Zic> jpds: a guy from #ubuntu-fr who receive a notice spam to join #*buntu-fr
[11:49] <Zic> "Nobody are available to help me" is a translation of his message.
[11:49] <jpds> hmm
[11:50] <jpds> elky: #ubuntu-bg looks like troll haven too.
[11:50] <elky> jpds, im being pm'd by GetReady, yeah
[11:51] <jpds> elky: 12:44:50 [!] greenland is now known as GetReady
[11:51] <elky> sigh.
[11:54] <elky> im going to need at least an hour with ichc after this :-/
[12:00]  * elky wonders what 'doith' is
[12:02] <elky> ah, doith is probably dutch?
[12:13] <Zic> can someone do something to close this channel and forward it to #ubuntu-fr please ?
[12:14] <Zic> an other channel was opened ##*buntu-fr
[12:15] <elky> we cant do anything about that one unfortunately
[12:15] <Zic> #*buntu-fr and ##*buntu-fr must to be forward to #ubuntu-fr
[12:15] <Zic> elky: hmm, and the freenode staff ?
[12:16] <elky> im waiting on a response about the first, and i'll try organise a freenode staff to take the fun out of the second by lurking
[12:16] <Zic> elky: thanks for your help
[12:18] <Zic> elky: can you have an approximative "time" to set the forward ? because, we can't control help given in this channel, sane, or insane, and spams to newbies users to join #*buntu-fr forked channel continues…
[12:18] <Zic> newbies user in #ubuntu-fr channel.
[12:19] <elky> Zic, i cant control how long it will be until i get staff attention, so no, sorry
[12:22] <Zic> elky: ok, thanks, do you think freenode will have no problem to do it so ? To organize prevention msg on #ubuntu-fr about these forked chan during the waiting
[12:23] <elky> Zic, i cannot predict freenode anymore
[12:23] <Zic> elky: no problem, thanks for your help
[12:26] <Zic> I'm staying here, elky, if you or freenode staff have question, forward them here or to my /query, thanks!
[12:33] <elky> Zic, staffers have been notified, have they acted yet?
[12:33] <Zic> I'm just unban from #*buntu-fr, but don't think so
[12:37] <tomaw> Zic: When has he been spamming #ubuntu-fr?
[12:38] <Zic> tomaw: I discovered it a few hour ago
[12:38] <Zic> by an user, danico, who search help
[12:39] <Zic> apparently, this night, spams were noticed to newbies user
[12:39] <tomaw> the only mention of it I can see in the channel is this:
[12:39] <tomaw> Sat 11:28:53 < ~danico> j/ #*buntu-fr
[12:39] <Zic> tomaw: it's how I discovered it
[12:39] <Zic> but after, I querry danico
[12:40] <Zic> he told me about notices which has been sended
[12:40] <tomaw> Ah
[12:40] <Zic> nothing more, he don't want to told who
[12:42] <elky> tomaw, it's a stretch but #*buntu-fr could be pointed at #ubuntu-fr and ##*buntu-fr could be... monitored... by someone who can understand and write french
[12:42] <Zic> I agree
[12:42] <elky> nothing like an overbearing staffer to ruin any troll's fun
[12:43] <Zic> :)
[12:43] <tomaw> I'll stick around and see what I can find out
[12:46] <Zic> tomaw: I don't care about alternate channel, just about newbies user who are forwareded to this forked channel, #*buntu-fr, we can't controll help that is given, sane or insane…
[13:00] <Zic> a void kick…
[13:58] <tomaw> Zic: hrm, what happened there? :)
[13:58] <tomaw> I walked away from the keyboard and now I am the only person in #*buntu-fr
[14:36] <McPeter> tomaw, it's ok ..
[14:36] <McPeter> i speak with different person
[14:37] <McPeter> i hope this "joke" is end
[14:57] <Zic> tomaw: sorry, I was afk
[14:57] <Zic> tomaw: this seems to be resolved
[14:57] <tomaw> Good :)
[14:57] <Zic> but I thank you for your help :)
[14:58] <McPeter> :)
[19:12] <johanbr> Did anyone else have their channel spammed in Latin about an hour ago?
[19:15] <mohi> hi :)
[19:16] <mohi>  we had an impolite boy in #ubuntu-ir, I'll give you the detais to stop him/her if you saw in your channels
[19:17] <Myrtti> sure
[19:17] <mohi>  [Whois] cumulus007 is<EMAIL_ADDRESS>(Sander Pientka)
[19:17] <mohi> [22:40] [Whois] cumulus007 is a user on channels: #ubuntu #ubuntu-au #ubuntu-ch #ubuntu-jp #ubuntu-ma #ubuntu-nl #ubuntu-nl-offtopic
[19:17] <mohi> Myrtti: :)
[19:24] <johanbr> That's the same person who spammed #ubuntu-se in Latin.
[19:25] <mohi> johanbr: e/she seems to be a troll, shold be talked to
[19:26] <mohi> he/she*
[19:55] <alefteris> cumulus007 together with wess spammed the ubuntu-gr channel as well
[19:55] <alefteris> they where kind enough to leave a link pointing to google translation service so that we may understand what was all that about
[19:55] <alefteris> lol
[19:57] <mohi> you dont wanna do something?
[19:58] <mohi> ant staff here to stop them? :s
[20:40] <ompaul> !staff | please see above
[20:41] <ompaul> cumilus007
[20:41] <ompaul> cheers
[20:43] <PriceChild> neither seem to be online
[20:43] <ompaul> thanks
[20:44] <ompaul> PriceChild,  he did appear on * [cumulus007] (n=sander@<IP_ADDRESS>): Sander Pientka
[20:44] <ompaul> anyway there ya go
[20:44] <PriceChild> whoops copied your spelling with an i :)
[20:44] <ompaul> hehehehe
[20:45] <ompaul> PriceChild, you have also a wess in that
[20:45] <ompaul> http://pastebin.ubuntu.com/21917/   just a hint of racism
[20:45] <PriceChild> I messaged that one but seems offline
[20:45] <mohi> his nick is cumulus007
[20:45] <mohi> he is online!
[20:47] <mohi> in #ubuntu-jp
[20:51] <PriceChild> now he's offline
[20:53] <mohi> yes ;)


[14:55] <bdmurray> pedro_: I just marked bug 868146 as a duplicate because it matched a bug pattern and I'm not certain that was the correct thing to do if you could take a peek
[14:55] <ubot4> Launchpad bug 868146 in gvfs (Ubuntu) "gvfs-fuse-daemon crashed with SIGSEGV in g_type_create_instance() (dup-of: 832533)" [Medium,New] https://launchpad.net/bugs/868146
[14:55] <ubot4> Launchpad bug 832533 in unity-greeter (Ubuntu Oneiric) (and 3 other projects) "gvfs-fuse-daemon crashed with SIGSEGV in g_type_create_instance() (affects: 239) (dups: 47) (heat: 819)" [High,Fix released] https://launchpad.net/bugs/832533
[14:56] <pedro_> bdmurray, ok looking at it now
[16:01] <bil21al> what are the requirements to apply for the ubuntu bug control?
[16:02] <charlie-tca> !bugcontrol
[16:02] <ubot4> Factoid 'bugcontrol' not found
[16:02] <Abhijit> bil21al, https://wiki.ubuntu.com/BugSquad
[16:02] <Abhijit> bil21al, see the bottom of the page Requiremnet section
[16:03] <bil21al> ok thankx
[16:06] <bil21al> abhijit is bug control a bigger branch or ubuntu bug squard? and  first we join bug squard than bug control?
[16:34] <hggdh> bil21al: bug control is a subset of bug squad -- those that have shown strong knowledge of Ubuntu triaging
[16:35] <hggdh> bil21al: see https://wiki.ubuntu.com/UbuntuBugControl for requirements and application


[01:52] <vanlong441> what am I doing here?
[03:18] <bjsnider> micahg, i think i've got a fix for the bad -dbg packages, but i can't test it here because it causes the build to be so large my system runs out of ram
[18:44] <joelesko> micahg: SEAMONKEY_2_6_RELEASE was tagged. I brought over the changes from my beta branch to the dev branch.
[18:45] <joelesko> micahg: I would like to propose the dev branch. Would you be able to create test packages? I'm building in my ppa now.
[18:46] <joelesko> micahg: The 2.6b4 packages I build looked good so I don't expect a problem with the 2.6 release.
[18:50] <joelesko> micahg: Others tested the 2.6b3 and there were no problems. 2.6b4 just came out so I built it the other day, but didn't have time to test. I will be testing 2.6
[20:23] <damian_> Good day is anyone present in the room?
[21:55] <Guest7159> hey guys. would anyone know where to look for attempts or discussion about getting ayanata scrollbars in XUL/XULRunner?


[18:24] <kreme191> does this chat room help ppl with ubuntu issues
[18:28] <hyperair> no.
[18:28] <hyperair> the correct place is #ubuntu.
[18:28] <kreme191> thanx


[00:04] <Kano> Sarvatt: it is definitely a very bad idea...
[00:07] <bjf> Kano, we review *all* the flavours that we support at every UDS
[00:08] <Kano> well the server one was obsolete, i never used that
[00:08] <Kano> only generic + generic-pae
[08:41]  * smb considers just going back to bed
[09:34] <smb> gah
[09:53] <brendand> has anyone tried to build the kernel with gcov on recently?
[10:17] <apw> brendand, not recently no
[10:21] <brendand> apw - do you normally need anything extra to do it?
[10:22] <apw> i don't think i have ever done it, though iirc it is an external patch set and lags the kernel mostly
[10:32] <apw> UBUNTU: SAUCE: rtl8192se: Force a build for a 2.6/3.0 kernel
[12:25] <Fudge> cjwatson  are you about cobber
[12:27]  * Fudge pokes apw
[12:40] <cjwatson> Fudge: it helps to give a reason rather than just poking people.
[12:41] <Fudge> sry cjwatson , we spoke a few weeks ago about kernel sound, i wondered if i can show u a bug report Attila submitted, i tink i saw ur name on there
[12:42] <cjwatson> I know nothing about kernel sound
[12:42]  * cjwatson <- not a kernel hacker
[12:43] <Fudge> mm my mistake
[12:43] <Fudge> wonder who it was loL
[13:03]  * apw looks at Fudge
[13:08] <_jmp_> good $localtime
[13:47] <apw> _jmp_, hiya
[13:58]  * tgardner reviews 104 stable patches
[14:05] <smb> tgardner, Most of them just are as from upstream. I would say the ones that can use a bit more thought would be the two drm ones and the adaption I made as noted in the pull request
[15:00] <ogasawara> tgardner: I'm getting ready to push over the top of precise master-next.  just want to make sure you haven't got anything locally that you wanted to push.  am also going to push up sforshee's alps patches at the same time.
[15:01] <tgardner> ogasawara, whack away
[15:01] <tgardner> smb, just pushed lucid master-next with a small compile fix to 'NLM: Don't hang forever on NLM unlock requests'
[15:02] <smb> tgardner, Gosh I managed to break it with copy and paste. :(
[15:02] <tgardner> smb, your forgot a ','
[15:02] <tgardner> you*
[15:03] <smb> tgardner, Bah. Thanks for fixing it.
[15:03] <tgardner> smb, the DRM patches look fine. I'm gonna reboot with that kernel here shortly
[15:04] <smb> tgardner, ok, probably should do the same here. are you building on gomeisa or tangerine
[15:04] <tgardner> smb, I built locally
[15:05] <smb> Someone has too much powerful gear... On the other hand its noisy enough nobody else wants it...
[15:06] <tgardner> smb, indeed. its probably time to ship that one to 1SS
[15:09]  * ogasawara back in 20
[15:12] <smb> tgardner, guess I will hammer gomeisa a bit with that master-next plus that xen fixup. Then I can test that on various places
[15:21] <alexbligh> smb, we talked a week ago about the Ubuntu kernels not booting on Xen PV-on-HVM because xen-platform-pci is missing from  the udeb. I have Iain Watson sitting next to me who is happy to provide a patch. Would you rather it put it in the udeb as a module or built it in to the kernel (the latter definitely works, the former we haven't got working yet).
[15:21] <alexbligh> (i.e. we got it into d-i but have not yet discovered what filters the modules into what appears in the udeb and what doesn't).
[15:23] <smb> alexbligh, Well, from the mailing list I think that it will be built-in at least for newer kernels, so it feels like that approach would be simpler
[15:23] <alexbligh> OK, so if Iain provides a patch for that, and puts it against one of the LP bugs, you would apply it? (in principle)
[15:24] <smb> It sounds reasonable. Btw, are we talking about Oneiric or Peecise target
[15:25] <alexbligh> smb, both ideally, but mostly Oneiric, as we'd actually like a version of Oneiric we can run on Xen :-)
[15:26] <smb> alexbligh, It is not that you cannot *run* it on Xen. You want the paravirt disk for install
[15:26] <alexbligh> It won't run at all on Xen because it unplugs the non-PV disk.
[15:27] <alexbligh> And cloud customers don't have the option of disabling all PV emulation...
[15:27] <alexbligh> therefore it just 'doesn't run on Xen' :-)
[15:27] <alexbligh> (yes, I know they can do xen_emul_unplug=never)
[15:27] <alexbligh> s/never/unnecessary/
[15:28] <smb> alexbligh, or unnecessary, but yeah if you need HVM it gets a bit difficult of that option is not put into your pv-grub commandline
[15:28] <apw> alexbligh, so if he is supplying the patch get him to send it to kernel-team@ directly
[15:29] <alexbligh> apw, hi Andy, OK, I will get Iain to do that. Our problem is that we need one Xen config that works with everything as we don't know what is in the image that we will run
[15:29] <apw> an admirable goal if it can be done for sure,y
[15:29] <alexbligh> Iain is<EMAIL_ADDRESS>and is just looking over my shoulder, so I shall leave it to him.
[15:30] <apw> yeah as long as we have the bug reference in there we'll be good and get the right people looking at it quickest
[15:30] <apw> bugs dissappear in the quagmire
[15:45] <apw> tgardner, ogasawara, i have the armhf bits pending to push, is the tree stable enough for me to push them on the top... they have a config copy in them so i neeed to have a stable config when i push
[15:46] <ogasawara> apw: go for it, I pushed the bits I wanted already.
[15:51] <apw> ogasawara, tgardner, ok pushed
[15:52] <tgardner> apw, ack, will have a look when I get back in a couple of hours.
[15:52] <ogasawara> bjf: I'm looking at kteam-tools/ktl/ubuntu.py .  It notes db["12.04"]["supported"] = False.  Will that remain False for the remainder of the dev cycle and then flip to True once we release 12.04?
[15:52] <apw> tgardner, ogasawara, the config is identicle to armel at this point.  the config does maintain them separatly and this needs to be considered when doing config changes for arm
[15:52] <ogasawara> apw: ack
[15:53] <tgardner> apw, I assume we must have an armhf chroot ? or did you just use the armel chroot
[15:53] <apw> tgardner, we have no way to build it without the right cross compilers and the right chroot
[15:54] <tgardner> ah
[15:54] <apw> tgardner, and you can't make those without the libc from the kernel.  so its a test it as well as you can and pray job
[15:54] <bjf> ogasawara: i think so but i need to dbl check the meaning of "supported" in some of the tools, there was a specific reason for that at the time i did it
[15:54] <apw> bjf, yeah i think that means 'stable teams repsonsibility' in there effectivly
[15:56] <ogasawara> bjf: only reason I ask is because I've got a script using supported_series which I believe included the dev release (it at least oneiric when it was in development)
[15:56] <ogasawara> bjf: so I'm just curious if it's meaning of supported has indeed changed and i need to fix up my script
[15:56] <bjf> ogasawara, that's what i was going to check, then it probably needs to go to "True"
[15:57] <bjf> ogasawara, the Precise block was added before Oneiric was final so i probably made it False so scripts wouldn't use it
[15:57] <ogasawara> bjf: I'll make the change and push.  let me know if it buggers up any of your scripts.
[15:58] <bjf> ogasawara: thanks
[16:15] <smb> alexbligh, Btw, for precise XEN_PCI_PLATFORM does not exist anymore as configurable option
[16:38]  * apw has to pop to the store for a washer, else we won't be using the loo
[16:44]  * smb now probably has more info than he wanted to have...
[16:50] <brendand> Does anyone know why, if I have GCOV_KERNEL enabled I get:
[16:50] <brendand> II: Done
[16:50] <brendand> make: *** [abi-check-generic] Error 1
[16:51] <brendand> when I don't without it enabled?
[16:52] <smb> brendand, because enabling gcov changes some structures and thus the abi
[16:53] <brendand> smb - fair enough
[16:53] <brendand> smb - do i build just the headers with gcov to begin with then?
[16:53] <brendand> smb - i'm very green on kernel building
[16:55] <smb> That won't help you to get a gcov enabled kernel. Depending on whether you do local builds or on a ppa you can disble the abi check...
[16:55]  * smb tries to find that wiki page again
[16:57] <smb> https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#ABI
[17:19] <brendand> smb - thanks
[17:45] <komputes> Hi everyone, I was wondering if someone can explain to me how the Linux kernel decides to assign a specific driver when a particular device when detected. From what I understand each module has a table of IDs it supports. Can I view this table? Where in the source should I look for this information?
[17:58] <tgardner> komputes, in any particular driver you can look for the usb_device_id or pci_device_id table.
[18:04] <komputes> tgardner: How would I go about looking for the USB ID in /lib/modules/2.6.32-34-generic/kernel/drivers/media/video/usbvideo/usbvideo.ko
[18:05] <komputes> it is not ASCII text but ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
[18:06] <apw> komputes, also that information is extracted and forms the module.dep stuff that modprobe uses; thats all in ascii
[18:06] <tgardner> komputes, get the source code?
[18:07] <tgardner> apw, thats kind of the hard way isn't it?
[18:08] <apw> tgardner, i'd say it was the easy way if you only have the binary
[18:08] <tgardner> I guess if you already know the ID and able to format your search correctly
[18:08] <apw> komputes, so you can see the matches which will map to a specific driver like this: grep i915 /lib/modules/`uname -r`/modules.alias
[18:08] <tgardner> komputes, look in /lib/modules/`uname -r`/modules.alias
[18:14] <komputes> That works.
[18:26]  * jsalisbury has recovered from changing Unity settings 8-O
[18:35] <tgardner> ogasawara, I'm test building the rebased seccomp_filter patches from kees
[18:36] <ogasawara> tgardner: ack
[19:14]  * tgardner -> lunch
[19:33] <kees> tgardner: oh excellent, thanks!
[19:34] <kees> tgardner: please double-check it on ARM. I *think* will fixed it for ARM, but that was the main thing I wanted to double-check when I was going to do the rebase.
[19:35] <kees> tgardner: and, if you want, qrt has seccomp_filter tests in it, but, again, I haven't tested them against the newer patch set. it _should_ pass, but it's possible something subtle changed that I was accidentally depending on in the test.
[19:48] <tgardner> kees, were you going to consider any of Tetsuo's suggestions ?
[19:55] <kees> tgardner: I replied to his email, I'm happy to switch from #if to #ifdef. the code changes I disagree with, but am curious if he sees something I don't.
[19:55] <tgardner> kees, ok, I just hadn't seen anything on the kteam list
[19:56] <tgardner> kees, I'll pull 'em into Precise for now. We've got plenty of time to fix any issues.
[19:56] <jjohansen> kees: often not, he likes to pick on style
[19:57] <kees> jjohansen: I think he wanted to just minimize the patch, but I like having it be as functional as it is.
[19:57] <kees> tgardner: hrm, is that a subscriber-only posting list? maybe it got moderated.
[19:57] <jjohansen> kees: ah could be
[19:57] <tgardner> kees, um, likely
[19:58] <tgardner> kees, ok, moderated
[19:58] <kees> hm, weird. https://lists.ubuntu.com/archives/kernel-team/2011-November/017663.html went through
[19:58] <tgardner> kees, 'cause I'm the moderator
[19:58] <kees> hah, okay :)
[19:58] <kees> I'll get my @chromium subscribed...
[19:58] <tgardner> kees, thanks
[19:59] <kees> though frankly, I'm already in there as @ubuntu and read it that way. I just did stuff from @chromium because of the @google in the original email. :P
[19:59] <kees> wheee
[19:59] <kees> too many email addresses
[20:21] <hallyn> smb: bug 795717 is the one which needs a patch sent to -proposed
[20:21] <ubot2> Launchpad bug 795717 in linux "32bit rhel and centos 5.(5|6) hangs on boot on natty" [Medium,Confirmed] https://launchpad.net/bugs/795717
[20:38]  * ogasawara lunch
[21:33] <tgardner> ogasawara, what is the name of the kernel config spec ?
[21:33] <tgardner> blueprint, I mean
[21:33] <ogasawara> tgardner: https://blueprints.launchpad.net/ubuntu/+spec/hardware-p-kernel-config-review
[21:33] <tgardner> ogasawara, thanks
[21:39] <ogasawara> pgraner: you want me to take over filling in the monthly report blurb each month for ya?
[21:44]  * tgardner is off to bike in the snow.
[22:09] <pgraner> ogasawara, sure
[22:45] <bjf> jsalisbury: did you look into whether bugs are being expired ?


[05:20] <guruprasad> tsimonq2, yes, you should be able to use it to authenticate yourself when performing git operations over HTTPS
[07:42] <cjwatson> tsimonq2: Yeah, I suppose in principle it doesn't _have_ to be tied to the username since tokens are unique, but it seems clearer that way and why not
[15:25] <jonesv> Hello! I am trying to add my SSH public key to my Launchpad profile, but it keeps saying "invalid key". My public key is<EMAIL_ADDRESS>and the private key is on a Yubikey (so it's not easy for me to re-generate it). What could be the issue with my SSH key?
[15:26] <jonesv> The Launchpad says "Only SSH v2 keys are supported", but I am not sure exactly what it means... is the key format I have unsupported?
[15:40] <cjwatson> We don't support sk-* keys yet - they'll require upstream work in Twisted first
[15:43] <cjwatson> I thought I'd mentioned this in https://www.chiark.greenend.org.uk/~cjwatson/blog/lp-new-ssh-features.html but I seem to have forgotten.  But that should give a sense of the amount of work involved
[15:45] <cjwatson> (And maybe a pointer to where somebody who wanted to contribute this sort of thing could look)
[18:36] <RogueScholar> Hey, has anyone else noticed that something seems to be seriously awry with the Nextcloud arm builds on Soyuz? It looks like some of them have been running for a couple days already... <https://launchpad.net/~kyrofa/+snap/nextcloud-daily-26/+build/2180614>
[18:47]  * RogueScholar slowly looks the nicklist up and down and feels a bit chagrined, "Dang, I didn't realize that it's like 80% FOSS heavy hitters around here. Please allow me to clarify that I had no intentions of sharpshooting anyone just now. I had assumed this was more of a user-centric space but now it's clear that probably everyone here is better informed than me and probably a half dozen or more are sitting within view of a screen showing the
[18:48] <RogueScholar> ...live resource monitoring for the whole deal." 😯
[19:09] <guruprasad> RogueScholar, there were some issues with the builder this week that we have resolved today. So I'd recommend cancelling stuck builds and retrying them.
[19:09] <guruprasad> *builders
[19:10] <RogueScholar> guruprasad: Thanks for the insight. None of mine are currently building, I'm afraid, just holding position in the queue.
[19:20] <cjwatson> I'm retrying this one.
[19:20] <cjwatson> And a dozen or so others.
[19:24] <cjwatson> Issues specifically: we tried to upgrade builder VMs to jammy, but it turned out that LXD 5.0 (which is the default in jammy cloud images) has some subtle issues that cause some builds to eventually hang after producing some quantity of output.
[20:24] <RogueScholar> cjwatson: Ugh, as much as I love the sound of the builders finally moving off of Xenial, that sounds like a ugly one to try and troubleshoot. You know this week I've noticed that some of my build recipes (and I can't find a common thread yet as to what they have in common) have started erroring out over the version string, they won't build if there's a package revision. Is it possible that's all part of the same set of issues?
[20:26] <cjwatson> RogueScholar: moving off focal, not xenial
[20:26] <cjwatson> RogueScholar: But maybe?  Link?
[20:28] <cjwatson> (builders moved off xenial in 2020 or so)
[20:31] <cjwatson> At a guess, that sounds more likely to be an independent problem possibly also prompted by switching the base system to jammy; if that's the case it ought to have gone away again now, since we've rolled back to focal.  But I'd like to check.
[20:31] <RogueScholar> Oh right, my bad. Well sassafras, I think I might have rewritten all the versions on the problematic recipes and the logs of the failures got pushed out of the queue, but I'm pretty sure this one was one of them <https://code.launchpad.net/~appimagelauncher-team/+recipe/dh-python-daily-git>
[20:34] <cjwatson> That one has had seven builds ever of which all appear to have been successful, unless I'm missing something
[20:34] <cjwatson> Oh, maybe https://launchpad.net/~appimagelauncher-team/+archive/ubuntu/daily/+build/26457484
[20:35] <cjwatson> Failures without a build log like that are normally either your build killed the builder (unlikely for something like dh-python) or infrastructure issues
[20:35] <cjwatson> So I think that one is probably ignorable given that you've had more recent successful builds
[20:39] <RogueScholar> Yeah, it must have been one of the other ones. Sorry I can't illustrate it better, but it was pretty clear that it was an issue with the version string parsing. I know the builds always get run in native package mode after quilt runs the patch series, but before this week it had always let the package revisions through.
[20:41] <RogueScholar> Spoke too soon, just found one! <https://code.launchpad.net/~appimagelauncher-team/+archive/ubuntu/daily/+recipebuild/3579288>
[20:42] <cjwatson> RogueScholar: Thanks, probably a behaviour change in dpkg-dev in jammy that we need to take account of.  It should have gone away for now as per what I said above, but could you file a bug on https://bugs.launchpad.net/launchpad-buildd/+filebug please as a reminder for us to look into that?
[20:43] <cjwatson> With that link, of courase
[20:43] <cjwatson> *course
[20:43] <RogueScholar> You got it, boss; can do.
[20:44] <cjwatson> That code in dpkg doesn't seem to have changed at all recently, but I only looked superficially
[22:27] <jonesv> cjwatson: hmm I'm afraid it's not clear to me what would need to be done in Twisted Conch in order to support sk-* keys. First, I am not a cryptographer. Does that rule me out for that? I can write Python code though. Then... does it look like a good "first contribution", or does it look like something pretty involved?
[23:58] <Eickmeyer> 99% sure the build farm is stuck.


[00:23]  * redir is going EoD RSN
[00:23] <mup> Bug #1577550 changed: juju fails to provision machine and will not retry <juju-core:New> <https://launchpad.net/bugs/1577550>
[00:23] <mup> Bug #1577569 changed: 1.25.5: failed to retrieve the template to clone -  error executing  "lxc-start" <oil> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1577569>
[00:57] <mup> Bug #1576805 changed: Juju controllers set the rsyslog NetstreamDriver affecting all subsequent rsyslog configuration <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1576805>
[01:48] <mup> Bug #1577606 opened: StatusInfo has a time.Time pointer, shoult not be a pointer. <tech-debt> <juju-core:New for hduran-8> <https://launchpad.net/bugs/1577606>
[02:08] <natefinch> oh weird.... bootstrapping on gce, I get a log message saying "Creating Juju controller "local.google" on google/us-east1" but it's actually created in us-central1
[02:12] <mup> Bug #1577609 opened: juju switch to non-existent controller gives wrong error <juju-core:New> <https://launchpad.net/bugs/1577609>
[02:36] <mup> Bug #1577614 opened: Bootstrapping GCE lies about the availability zone of the controller <juju-core:New> <https://launchpad.net/bugs/1577614>
[02:42] <thumper> axw_: ping
[03:04] <axw_> thumper: pong
[03:04] <axw_> sorry, missed message
[03:04] <thumper> axw: np, was wanting to talk to you about storage entities ...
[03:04] <thumper> however I need to take my daughter to BJJ shortly
[03:04] <thumper> but I could drop and come straight back to chat if you can
[03:05] <axw> thumper: sure, I can chat
[03:05] <thumper> in about 25 minutes?
[03:06]  * thumper wonders if Maia has remembered
[03:06] <axw> thumper: no worries, prod me when you're back
[03:06] <thumper> kk
[03:35] <thumper> axw: back
[03:36] <axw> thumper: ok, gotta make a hangout
[03:36] <axw> thumper: https://plus.google.com/hangouts/_/canonical.com/juju-storage?authuser=1
[04:09] <mup> Bug #1577638 opened: Can't juju ssh to lxd-placed container <juju-core:New> <https://launchpad.net/bugs/1577638>
[07:45] <dimitern> morning
[07:45]  * dimitern thinks it might be time to change my ISP :/
[07:46] <anastasiamac> dimitern: o/
[07:47] <dimitern> anastasiamac: \o
[07:47] <anastasiamac> dimitern: how was easter?
[07:47] <dimitern> anastasiamac: as usual :) I got too much to eat
[07:48] <anastasiamac> dimitern: and isn't it a great feeling? \o/
[07:49] <dimitern> anastasiamac: ahh it is :)
[08:07] <dimitern> frobware: ping
[08:25] <babbageclunk> dimitern: stink about the internet bro - hope you get it sorted out soon!
[08:25] <dimitern> babbageclunk: well, they did fix it, but kept me on hold for 20m
[08:26] <babbageclunk> dimitern: grrr, but yay!
[08:26] <dimitern> their support is a joke, it's good I rarely had to contact them
[08:46] <TheMue> morning
[08:55] <dimitern> axw: hey, are you still around?
[08:55] <axw> dimitern: sure am
[08:56] <dimitern> axw: I've noticed you've landed the changes in provider/ec2 re filtering instances purely based on tags
[08:56] <dimitern> axw: I'm trying to integrate that into my fix for allowing non-default VPC to be used
[08:56] <axw> dimitern: apart from AllInstances, which filters on security groups
[08:57] <dimitern> axw: ah, so I'll merge the changes there
[08:58] <axw> dimitern: yep, should just be in one place now
[08:58] <dimitern> axw: how did you get around the non-idempotent nature of adding tags at start instance time?
[08:59] <axw> dimitern: which non-idempotency issue would that be?
[08:59] <axw> dimitern: the one we talked about last was to do with using ClientToken, but I didn't end up using that
[08:59] <voidspace> do you mean non-atomic?
[08:59] <dimitern> voidspace: that's it :)
[09:00] <axw> dimitern voidspace: it's still non-atomic, which is why I'm using security groups in that one spot
[09:00] <dimitern> axw: ok, makes sense
[09:00] <axw> dimitern: we only *need* it in AllInstances, because that's where we need to list instances to be cleaned up by the provisioner
[09:00] <voidspace> dimitern: babbageclunk: frobware: doorbell - will be standup shortly
[09:00] <axw> dimitern: if we didn't tag it, it's busted anyway, so no point returning it from anything else
[09:01] <dimitern> axw: right
[09:01] <dimitern> axw: ok, thanks I'll take it from here :)
[09:07] <thumper> babbageclunk: are you in the standup?
[10:00] <babbageclunk> thumper: oops, didn't notice that because I was in the standup
[11:54] <babbageclunk> voidspace, dimitern: review please? https://github.com/juju/gomaasapi/pull/54
[11:55] <babbageclunk> voidspace, dimitern: I'm going to go through the MAAS provider and make sure we can deal with machine.BootInterface() or interface.VLAN() being nil.
[11:55] <dimitern> babbageclunk: looking
[11:58]  * babbageclunk is out - meeting someone for lunch
[12:26] <jcastro> http://askubuntu.com/questions/766851/how-do-i-use-a-feature-flag/76685
[12:26] <jcastro> can someone peer review my answer please?
[12:30] <dimitern> jcastro: looks correct
[12:59] <babbageclunk> dimitern: is the maas networking interlock happening?
[13:00] <babbageclunk> dimitern: Thanks for the review, by the way!
[13:00] <dimitern> babbageclunk: oops, I forgot - joining now
[13:03] <voidspace> babbageclunk: cool
[13:20] <mup> Bug #1577776 opened: 2.0b6: asks for domain-name, then doesn't know what it is <landscape> <juju-core:New> <https://launchpad.net/bugs/1577776>
[13:32] <mup> Bug #1577776 changed: 2.0b6: asks for domain-name, then doesn't know what it is <landscape> <juju-core:New> <https://launchpad.net/bugs/1577776>
[13:41] <mup> Bug #1577776 opened: 2.0b6: asks for domain-name, then doesn't know what it is <landscape> <juju-core:New> <https://launchpad.net/bugs/1577776>
[13:50] <mup> Bug #1576704 changed: MigrationExportSuite.TestUnits unequal results <blocker> <ci> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1576704>
[13:50] <mup> Bug #1576913 changed: StatusHistorySuite.TestPruneStatusHistory <blocker> <ci> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1576913>
[13:50] <voidspace> anyone seen this?
[13:50] <voidspace> mongo/open.go:116: undefined: tls.TLS_RSA_WITH_AES_128_GCM_SHA256
[13:50] <voidspace> ah, wrong version of go probably
[14:05] <babbageclunk> voidspace, dimitern: If iface.VLAN() is nil at https://github.com/juju/juju/blob/master/provider/maas/interfaces.go#L249
[14:06] <dimitern> babbageclunk: then VLANTag should be 0
[14:06] <babbageclunk> what should happen? Skip this interface in the loop? Use 0 as the tag? Error out?
[14:06] <babbageclunk> dimitern: ok, awesome, thanks!
[14:07] <voidspace> babbageclunk: how can machine.InterfaceSet() return a nil interface?
[14:07] <voidspace> babbageclunk: I'm pretty sure it can't
[14:07] <babbageclunk> voidspace: It can return an interface for which the VLAN is null (or will be able to in the near future).
[14:07] <voidspace> babbageclunk: ah, VLAN is nil
[14:08] <voidspace> babbageclunk: sure
[14:08] <voidspace> I misread
[14:08] <babbageclunk> voidspace: :)
[14:29] <mup> Bug #1577568 changed: juju 1.25.5 problems with bonded nics <landscape> <juju-core:Invalid> <juju-core 1.25:Invalid> <https://launchpad.net/bugs/1577568>
[14:29] <mup> Bug #1577798 opened: azure 400 bad request creating networks <azure-provider> <blocker> <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1577798>
[14:35] <babbageclunk> voidspace, dimitern: review for the Juju side of the nullable/optional fields work? http://reviews.vapour.ws/r/4759/
[14:36] <dimitern> babbageclunk: LGTM
[14:37] <babbageclunk> dimitern: ta!
[14:41] <voidspace> babbageclunk: \o/
[14:42] <dooferlad> dimitern / voidspace / babbageclunk: Please take a look: http://reviews.vapour.ws/r/4758
[14:43] <dooferlad> it is mostly a forward port. The only change vs 1.25 is https://github.com/juju/juju/pull/5333/commits/4fe1310661e8256164ab5039a0079fc049060d84
[14:43] <dooferlad> so just take a look at that.
[14:46] <babbageclunk> dooferlad: Ha ha, took me moment to click that I was reading Python not Go.
[14:46] <dooferlad> babbageclunk: :-)
[14:49] <dimitern> dooferlad: LGTM - I'm happy the bridge script shows routes once more btw - it was a pain to debug without it
[14:49] <dooferlad> dimitern: thanks
[15:29] <mup> Bug #1577816 opened: Deploy of cs:trusty/ubuntu gives me xenial <landscape> <juju-core:New> <https://launchpad.net/bugs/1577816>
[15:53] <mup> Bug #1577556 opened: mysql charm is failing to get unit-get private-address in the install hook <juju-core:New> <mysql (Juju Charms Collection):Fix Released> <https://launchpad.net/bugs/1577556>
[16:11] <babbageclunk> dimitern: If I want to install juju-mongodb3.2 do I have to have xenial installed?
[16:12] <dimitern> babbageclunk: I suspect so, but I don't know for sure
[16:13] <babbageclunk> dimitern: :/ I guess upgrading might be the thing to do now anyway.
[16:14] <dimitern> babbageclunk: +1
[16:15] <perrito666> babbageclunk: yes, iirc there is no mongo 3.2 package for earlier versions of ubuntu
[16:16] <babbageclunk> ok, thanks perrito666.
[16:19] <ejat> hi .. is there any inside the documentation brieft how to get MS Azure credential
[16:19] <ejat> brief*
[16:23] <natefinch> uh, wow, we just let you set whatever values you want in the model config? There's no check if something is a valid configuration value?
[16:39] <ejat> natefinch: u mean in credentials.yaml ?
[16:41] <xnox> frobware, hi
[17:12] <mup> Bug #1577816 changed: Deploy of cs:trusty/ubuntu gives me xenial <landscape> <juju-core:New> <https://launchpad.net/bugs/1577816>
[17:17] <alexisb> katco, looks like this bug just got a lot easier :) see urulama latest comment: https://bugs.launchpad.net/juju-core/+bug/1576509
[17:17] <mup> Bug #1576509: Race in macaroon-bakery <blocker> <ci> <race-condition> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1576509>
[17:17]  * katco looks
[17:18] <katco> alexisb: nice! :) should be a small update to dependencies.tsv :D
[17:19] <alexisb> whoo hoo for an easy win thanks to rogpeppe1 !
[17:19] <rogpeppe1> alexisb: :)
[17:43] <ejat> marcoceppi: ERROR autorest:WithErrorUnlessStatusCode POST https://login.microsoftonline.com/fb30bf07-xxxx-xxxx-b9a8-02ef08680fb9/oauth2/token?api-version=1.0 failed with 400 Bad Request
[18:10] <natefinch> juju status doesn't show containers?
[18:10] <natefinch> boggle
[18:11] <natefinch> (tabular that is, they're shown in yaml)
[19:03] <mup> Bug #1577900 opened: juju set-model-config's UX is very confusing <juju-core:New> <https://launchpad.net/bugs/1577900>
[19:08] <tych0> frobware: hi
[19:09] <frobware> https://bugs.launchpad.net/juju-core/+bug/1242783
[19:09] <mup> Bug #1242783: containers should use constraints to configure cgroups/kvm values <constraints> <local-provider> <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1242783>
[19:09] <frobware> tych0: https://bugs.launchpad.net/juju-core/+bug/1242783
[19:12] <tych0> frobware: ah
[19:12] <tych0> so this has been around for a while :)
[19:24] <mup> Bug #1577900 changed: juju set-model-config's UX is very confusing <juju-core:New> <https://launchpad.net/bugs/1577900>
[19:58] <natefinch> am I crazy... didn't juju ssh used to work for lxc containers juju creates?
[19:58] <natefinch> ericsnow, katco, cherylj ^
[19:58] <perrito666> dont remember, but it should
[19:59] <katco> natefinch: i think it did
[19:59] <perrito666> you should be able to ssh into an lxc container
[19:59] <natefinch> well, you can't
[19:59] <natefinch> $ juju ssh 1/lxc/0
[19:59] <natefinch> ssh: connect to host <IP_ADDRESS> port 22: No route to host
[19:59] <perrito666> bug?
[19:59] <natefinch> tried on aws and gce
[19:59] <perrito666> natefinch: pastrebin your ifconfig
[19:59] <perrito666> ah that not on your machine?
[20:00] <perrito666> actually I changed my mind, paste ifconfig and lxc list
[20:00]  * perrito666 smells something fishy there
[20:00] <natefinch> perrito666:  yeah, not lxd provider, lxc containers on real cloud machines
[20:00] <perrito666> ohh, I see what is going on there
[20:00] <perrito666> that IS a bug
[20:00] <natefinch> reporting
[20:01] <perrito666> voidspace: any input on that?
[20:01] <cherylj> natefinch: https://bugs.launchpad.net/juju-core/+bug/1577638/comments/3
[20:01] <mup> Bug #1577638: Can't juju ssh to lxd-placed container <juju-core:Incomplete> <https://launchpad.net/bugs/1577638>
[20:01] <perrito666> ah I see
[20:02] <perrito666> well that is poor ux, juju ssh should know how to jump through the hoops
[20:02] <natefinch> yeah, that's half the reason juju ssh exists, is to jump through hoops for you
[20:03] <cherylj> natefinch: this was a security concern - allowing users who don't have access to the admin model
[20:03] <perrito666> cherylj: interesting
[20:03] <natefinch> man we're bad at UX
[20:04] <perrito666> cherylj: actually you could ssh into the container by going through the host
[20:04] <perrito666> or you could actually do proper port binding there and get the 22 exposed
[20:09] <natefinch> cherylj: can we set the status to something other than incomplete? the bug seems well-enough specified.  I'd prefer we raised this up as a fairly major UX problem, and regression from 1.x
[21:02] <alexisb> katco, ericsnow, one of you guys available for technical back up  on an sts q?
[21:02] <ericsnow> alexisb: sure
[21:02] <alexisb> https://plus.google.com/hangouts/_/canonical.com/juju-core-sts
[21:02] <alexisb> ericsnow, ^^
[21:15] <mup> Bug #1577939 opened: Backup-restore failed on xenial because service "juju-db": No such file or directory <backup-restore> <blocker> <ci> <xenial> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1577939>
[21:18] <mup> Bug #1577939 changed: Backup-restore failed on xenial because service "juju-db": No such file or directory <backup-restore> <blocker> <ci> <xenial> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1577939>
[21:21] <mup> Bug #1577939 opened: Backup-restore failed on xenial because service "juju-db": No such file or directory <backup-restore> <blocker> <ci> <xenial> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1577939>
[21:45] <mup> Bug #1577945 opened: Bootstrap failed: DNS/routing misconfigured on maas 1.8 <blocker> <bootstrap> <ci> <maas-provider> <network> <regression> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1577945>
[21:45] <mup> Bug #1577949 opened: windows services cannot upgrade to 1.25.6 <blocker> <ci> <regression> <upgrade-juju> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1577949>
[23:04] <perrito666> wallyworld: is standup happening anyway?
[23:05] <wallyworld> perrito666: sure, why not
[23:06] <anastasiamac> wallyworld: perrito666: why would standup not b happening?
[23:06] <perrito666> well we had another meeting happening at that time and then we changed it
[23:07] <anastasiamac> wallyworld: perrito666: oh i have release/bug updates for standup :D
[23:12] <perrito666> I dont think we can push it back 20 mins or so?
[23:14]  * perrito666 looks at wallyworld anastasiamac and axw
[23:14] <wallyworld> perrito666: you want to delay? fine with me
[23:14]  * axw looks back
[23:14] <axw> I can delay a bit
[23:15] <perrito666> k bbh
[23:17] <wallyworld> perrito666: axw: there's 3 in the call as the others didn't see the backscroll; axw want to jump in and perrito666 can join us when ready
[23:17] <axw> wallyworld: okey dokey
[23:23] <perrito666> I am here
[23:36] <redir> ericsnow: yst?
[23:38] <perrito666> wallyworld: https://bugs.launchpad.net/juju-core/+bug/1576313
[23:38] <mup> Bug #1576313: windows: uniter tests fail because logs get dumped to stderr <blocker> <ci> <regression> <test-failure> <windows> <juju-core:In Progress by hduran-8> <https://launchpad.net/bugs/1576313>
[23:40] <axw> redir: wallyworld: to juju-core actually, maybe reed's not on it
[23:45]  * redir looks
[23:49] <anastasiamac> redir: i forwarded it to u directly \o/
[23:50] <redir> axw: wallyworld I don't appear to be on a juju-core list.
[23:50] <redir> anastasiamac: tx:)
[23:50] <anastasiamac> redir: and i think that u r on the mailing list (i can see u)
[23:50] <anastasiamac> :D
[23:50] <redir> hmmm
[23:51] <anastasiamac> it's going to ur namesurname.com
[23:53] <redir> anastasiamac: I think it is a bug:)
[23:54] <anastasiamac> bug = user error?
[23:54] <redir> I have recieved no emails from that from address...
[23:54] <anastasiamac> redir: taking it to pm


[04:42] <Chaos7Theory> Rather quiet.
[04:47] <rocsteady> hi guys/gals
[04:49] <rocsteady> I'm rsync'ing a large directory from a remote host to my local host over ssh
[04:49] <rocsteady> Trying to learn linux
[04:50] <rocsteady> It's working!
[04:50] <rocsteady> 20 min to wget at home, whereas at school it's like the speed of light
[13:37] <vibhav> So, what do we discuss here? :)
[13:38] <RamchandraApte> about ubuntu


[01:20] <wallyworld_> thumper: i have to go to the hardware store - bit of a bathroom issue, back soon hopefully
[01:33] <thumper> wallyworld_: ok.. ping me when you're back
[02:40] <wallyworld_> thumper: ping
[02:40] <thumper> wallyworld_: hi
[02:40] <thumper> wallyworld_: hangout?
[02:40] <wallyworld_> yep
[02:41] <wallyworld_> https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6
[03:51] <kyhwana> hey thumper, do yo know cucumbererror?
[03:56] <thumper> kyhwana: sorry, no
[03:58] <kyhwana> ahh ok, he's dunners too, works at some educational instution in IT or helldesk
[04:00] <thumper> kyhwana: oh, I assumed you were talking about errors from the python library cucumber L(
[04:01] <thumper> L( should have been :)
[04:01] <thumper> but still, no
[04:01] <kyhwana> hehe
[04:04] <kyhwana> ah right, at UO. oh well
[04:09] <thumper> kyhwana: what it their real name, I may know them but not their irc nick
[04:09] <kyhwana> Oh, darryl someone
[04:56] <thumper> kyhwana: doesn't ring any bells
[04:58] <kyhwana> ah well, you probably know someone that knows him
[05:07] <thumper> kyhwana: almost certainly
[05:07] <kyhwana> thumper: Do you drink of the beers?
[05:08] <thumper> kyhwana: sometimes
[05:08] <kyhwana> hmm, do you goto Beervana in wellington?
[05:09] <thumper> no
[05:09] <thumper> not that keen
[05:09] <thumper> I know some who do
[05:09] <kyhwana> ahh ok
[05:10] <kyhwana> I think that's my only trips to wellington this year, Nethui, beervana and Kiwicon :P
[05:15] <thumper> kyhwana: I do kiwipycon
[05:15] <thumper> not going to nethui
[05:15] <thumper> although Unfocused is
[05:16] <thumper> wallyworld_: email sent to dev list re: opaque keys and natural business keys
[05:16] <kyhwana> ahh ok
[05:16] <thumper> wallyworld_: I mentioned that you feel stronger than I do in the email, so no additional rant needed
[05:17] <thumper> wallyworld_: but feel free to +1 it with a non-ranty additional info
[07:09] <TheMue> morning
[07:36] <fwereade> TheMue, heyhey
[07:38] <TheMue> fwereade: heya
[07:39] <TheMue> fwereade: where i just see you, could you tell me more about the background of nonce (e.g. used in StartInstance() )?
[07:39] <fwereade> TheMue, it's to deal with provisioner failures after starting an instance but before recording that fact in state
[07:40] <fwereade> TheMue, if that happens, we get a rogue instance starting up, thinking it's running machine (say) 7
[07:40] <fwereade> TheMue, but state being unaware of that
[07:41] <fwereade> TheMue, so when we start up a machine agent, the first thing we do is check that the nonce matches the one recorded in state
[07:41] <fwereade> TheMue, if it doesn't, or there's no nonce in state, the MA does nothing and just sits back and waits for its host instance to be trashed
[07:42] <TheMue> fwereade: ah, ok, thx, that makes it more clear.
[07:43] <TheMue> fwereade: my dict translates nonce as sex offender, esp. paedophile. strange.
[07:43] <fwereade> TheMue, when it's a container being provisioned, this is potentially less of a problem -- we *could* arrange matters so that "instance" ids are predictable based on machine ids -- but I'd prefer to just keep the nonce mechanism so we aren't forced to do that
[07:44] <fwereade> TheMue, and so that we have the same code path in all cases
[07:44] <TheMue> fwereade: +1 on that, yes
[07:44] <fwereade> TheMue, cool
[07:45] <fwereade> TheMue, (yeah, it's one of those interestingly overloaded terms, I knew that meaning before I was aware of the technical one)
[07:46] <TheMue> fwereade: i never heard it before
[07:46] <TheMue> fwereade: but wikipedia knows the correct meaning
[08:48] <dimitern> fwereade: hey
[08:48] <fwereade> dimitern, hey dude
[08:49] <dimitern> fwereade: sorry, yesterday i suddenly felt tired and decided to lie down for a while and was midnight when I woke up :)
[08:49] <dimitern> fwereade: saw your msg too late
[08:49] <fwereade> dimitern, haha, no worris
[08:50] <dimitern> fwereade: I have a proof-of-concept proposal of the bulk-ops: https://codereview.appspot.com/9847044
[08:51] <fwereade> dimitern, awesome
[08:52] <fwereade> dimitern, btw, cath and I were pondering a cuba lunch today, feel like joining us?
[08:52] <dimitern> fwereade: i was thinking I can just get rid of srvUnit altogether
[08:52] <dimitern> fwereade: sgtm, although i'll bring my apples :)
[08:52] <fwereade> dimitern, haha, ok -- what time works for you?
[08:53] <dimitern> fwereade: either before standup at 13:30 or after 14
[08:53] <fwereade> dimitern, maybe 12 or 12:15 then?
[08:53] <dimitern> fwereade: ok
[08:54]  * dimitern brb
[08:54] <TheMue> fwereade, dimitern: shall i join too? ;)
[08:54]  * TheMue orders his jet
[08:59] <dimitern> TheMue: :) if you manage, by all means
[09:00] <TheMue> dimitern: don't think so, my wife just took it for a short trip to new york
[09:00] <dimitern> fwereade: so what do you think of the approach ^^ ?
[09:00] <fwereade> dimitern, looks ideal
[09:01] <dimitern> fwereade: haven't figured out a way to test is server-side yet, i'm afraid
[09:01] <fwereade> dimitern, I was about to say "I think it's time to introduce direct server testing" ;p
[09:02] <dimitern> fwereade: and also, if we need bulk ops exposed at client-side how do you picture it? having st.AllUnits? or something like that
[09:02] <fwereade> dimitern, I was vaguely expecting st.Units([]string)
[09:02] <fwereade> dimitern, I think AllUnits is potentially problematic
[09:02] <dimitern> fwereade: ah, ok can do that
[09:03] <dimitern> fwereade: will this be the only entry point?
[09:03] <fwereade> dimitern, and I would rather not implement either until there's a need -- so, for now, yes, the st.Unit will remain the only entry point in state/api
[09:03] <dimitern> fwereade: maybe if we need it later, we could have st.UnitsStatus(names) perhaps
[09:04] <dimitern> fwereade: s/UnitsStatus/Units.Status(names)/
[09:04] <fwereade> dimitern, I have a small part of my brain wondering whether a type that wraps a list of unit ids will be justifiable/handy at some point
[09:04] <fwereade> dimitern, but yeah, exactly
[09:05] <dimitern> fwereade: although if st.Units takes names, then .Status() is redundant, unless you don't want all the other info over the wire
[09:05] <dimitern> fwereade: in which case, we'll need separate top-level methods - st.UnitsStatus(names)
[09:06] <fwereade> dimitern, Status doesn't get sent over in the unit data does it?
[09:07] <dimitern> fwereade: anyway, I'm glad I got you finally :) i'm afraid i was being stupid last couple of days
[09:07] <dimitern> fwereade: well, no actually - only stuff accessible from the u.doc directly
[09:07] <fwereade> dimitern, fwiw I don't think you have been
[09:08] <fwereade> dimitern, the jujud agent stuff is not much fun to play with
[09:08] <dimitern> fwereade: agreed!
[09:08] <fwereade> dimitern, and the number of layers involved in the api stuff makes it very hard to communicate precise instructions
[09:09] <fwereade> dimitern, the blocker was in clearly explaining the precise scope of the problem
[09:09] <dimitern> fwereade: so to emulate Unit(name).Status() with bulk ops, i'll need to do srvUnits().Status(names) and call that
[09:09] <fwereade> dimitern, yep, sgtm
[09:09] <fwereade> dimitern, just one thing to bear in mind
[09:10] <dimitern> fwereade: ok, so my plan is to get rid of srvUnit and replace it with bulk-only ops, while keeping the client-side the same first, then think how to test it
[09:10] <fwereade> dimitern, returning a map potentially bumps up against the json key-type restriction; consider the tradeoffs in returning an []params.Unit instead
[09:10] <dimitern> fwereade: and add api.Units(names) as well
[09:11] <fwereade> dimitern, I'm not 100% sure it's smarter but my gut leads me that way
[09:11] <dimitern> fwereade: what are these restrictions, elaborate pls?
[09:11] <fwereade> dimitern, no int keys
[09:11] <dimitern> fwereade: well, we'll make them strings throughout :)
[09:11] <fwereade> dimitern, and there is at least one situation in which we need to retrieve relations by int key
[09:12] <dimitern> fwereade: or only return a map for string keys proper, so that lookups are fast client-side
[09:12] <fwereade> dimitern, suggestion: preserve order of input names
[09:13] <dimitern> fwereade: can do; that'll actually save some bytes over the wire
[09:13] <fwereade> dimitern, that way we can loop in a defined order if necessary, and otherwise don't have to mind
[09:13] <fwereade> dimitern, great
[09:21] <dimitern> fwereade: can you please comment on the CL, so it doesn't look like i'm pulling stuff from my ass there :)
[09:21] <fwereade> dimitern, ofc, sorry
[09:22] <dimitern> fwereade: cheers
[09:36] <fwereade> dimitern, sorry sent it a few mins ago
[09:37] <dimitern> fwereade: saw it, thanks
[09:38] <fwereade> dimitern, I've noticed something else in the api, that you had no way of knowing about... we really shouldn't be sending data down from the environ config watcher... we should be consistent with the other watchers and just send notifications
[09:38] <fwereade> TheMue, ^^
[09:38] <fwereade> TheMue, since you'll be working on the provisioner, please ensure you fix that end keep the API up to date
[09:39] <jam> fwereade, dimitern: anyone have insight into the state_test.go TestOpenDoesNotDelayOnHandShakeFailure test? I think it was written by davecheney
[09:39] <jam> It succeeds for me locally, but fails reliably on go-bot
[09:39] <dimitern> jam: not really
[09:39] <jam> It seems to do 3 TLS Handshake failures locally
[09:39] <jam> but on gobot I get maybe 6 ofthem
[09:40] <fwereade> jam, it *looks* like it's intended to test that we fail out immediately on handshake failure
[09:40] <fwereade> jam, I seem to get 4 locally
[09:41] <fwereade> (can you tell I've written no code since I got back? :/)
[09:41] <TheMue> fwereade: yep, will keep in mind
[09:41] <jam> fwereade: well, it is slightly indeterministic if you get the failure before the last log message (if I force the test to fail on an otherwise working system)
[09:41] <jam> I think I see 4 as well
[09:41] <jam> I'm slightly worried that it is a timing based test and the go-bot is just slow
[09:42] <fwereade> jam, from local behaviour it STM to be an actual problem
[09:42] <fwereade> TheMue, dimitern: are you getting that test passing?
[09:42] <jam> fwereade: as in, it should be only trying 1 time?
[09:42] <fwereade> jam, that's how I read the test name
[09:42] <jam> it passes for me locally
[09:43] <jam> (maybe the issue is that locally it is too fast?)
[09:43] <fwereade> jam, interesting
[09:43] <fwereade> jam, could be
[09:43] <dimitern> fwereade: let me check
[09:43] <jam> fwereade: it fails for you?
[09:43] <fwereade> jam, did just now, don't know whether it's consistent
[09:43] <jam> fwereade: so I believe the code it cares about is in open.go around line 93
[09:44] <dimitern> fwereade, jam: it passes for me - tried 3 times
[09:44] <jam> which has a time.Sleep if you have a connection failure
[09:44] <jam> but no time.sleep if you connect but fail to TLS handshake
[09:44] <fwereade> jam, ah, but the TLS bit below *does* retry but does not delay
[09:44] <fwereade> jam, yeah, ok, I suspect I misread intent
[09:44] <fwereade> jam, sounds timingy then :/
[09:45] <jam> fwereade: that is what I get from the "DoesNotDelay"
[09:45] <fwereade> jam, seems to consistently take 1.5s for me
[09:45] <jam> fwereade: that is what it was taking me as well on go-bot
[09:45] <jam> so it *sounds* a *lot* like an actual sleep somewhere
[09:46] <fwereade> jam, hmm, go version related perhaps?
[09:46] <fwereade> jam, go version go1.1 linux/amd64
[09:46] <jam> fwereade: it failed on gobot with 1.0.2, so I upgraded to 1.0.3 and still failed
[09:46] <jam> fwereade: the fact that you and I both get 1.5s on very different hardware
[09:47] <jam> means I'm pretty confident there is a hidden sleep
[09:47] <jam> or timeout
[09:47] <fwereade> jam, (I thought we'd standardized on go1.1?)
[09:47] <fwereade> jam, yeah
[09:47] <jam> fwereade: there will be no 1.1 in precise
[09:47] <jam> that we can use for building
[09:47] <jam> so use 1.1 when we can, but our syntax needs to stay 1.0.3 compatible
[09:47] <fwereade> jam, oh balls -- I suppose we can't use a PPA?
[09:47] <fwereade> jam, forget it, derail, anyway
[09:47] <jam> fwereade: there are issues with dependent builds
[09:48] <jam> at least for backports
[09:48] <jam> you can get go 1.1 into backports
[09:48] <fwereade> jam, heh, fair enough
[09:48] <jam> but a backport of juju-core can't use debs from other backports to build itself
[09:48] <jam> limitations of the builders
[09:48] <fwereade> jam, blarg, ok
[09:48] <fwereade> jam, good to know then
[09:48] <jam> and we can get 1.0.3 into an SRU (which builders *can* use)
[09:48] <jam> but not a 1.1 sort of change
[09:49] <jam> fwereade: especially given dfc just mentioned there is a bug in 1.1 and we should actually wait for 1.1.1
[09:49] <fwereade> jam, sounds worth investigating... sorry I can't help more :(
[09:49] <fwereade> jam, ah, yeah, dimitern found some gc-related panic?
[09:49] <dimitern> fwereade: yeah, let me find the issue link
[09:50] <dimitern> fwereade: https://code.google.com/p/go/issues/detail?id=5554
[09:50] <fwereade> dimitern, (fwiw, wrt 10 mins ago, please ping me before you implements any watchers that send actual data, rather than notifications... they're not all necessarily invalid, but they deserve discussion)
[09:50] <fwereade> dimitern, cheers
[09:51] <dimitern> fwereade: not planning to implement any today :) but might have to change what's already implemented
[09:52] <fwereade> dimitern, if it's just EnvironConfigWatcher I've kicked that over to frank, he's making provisioner changes
[09:52] <dimitern> fwereade: ah, cool
[09:52] <dimitern> TheMue: ping me if you need help around the api/watchers - it's not pleasant :)
[09:52] <TheMue> jam: test failed here with 1.0.3 too
[09:53] <fwereade> dimitern, (and should thus be the best person to coordinate keeping that precise bit in sync)
[09:53] <TheMue> dimitern: will do
[09:54] <dimitern> fwereade: meet you in 10-15m @cuba?
[09:54] <jam> TheMue: so the real question is why is it passing locally for me :)
[09:55] <jam> on go-bot, I actually see it retrying maybe 6 times
[09:56] <jam> found it, I think
[09:56] <jam> fails locally now
[09:56] <jam> the issue is that mgo driver
[09:56] <jam> changed
[09:56] <TheMue> jam: indeed, a good question
[09:56] <jam> it now sleeps
[09:56] <jam> it didn't as of the earlier rev I was using
[09:57] <jam> TheMue: I think: https://groups.google.com/forum/#!msg/mgo-users/DU5pXpIxCg8/cAXAGWaOl0sJ
[09:57] <jam> " A short delay was introduced at
[09:57] <jam>   this point to minimize the impact of these retries"
[09:57] <fwereade> jam, ahhhh
[09:57] <fwereade> dimitern, sgtm, just about to leave
[09:58] <dimitern> fwereade: omw in 5
[09:59] <jam> fwereade, TheMue: 'time.Sleep(500 * time.Millisecond)' was added to the retry code in mgo
[09:59] <jam> hence, 3 retries (4 total tries), always equals 1.5s for everyone
[10:01] <fwereade> jam, hmm, maybe the answer is to drop the delay in state.open regardless, and suck up the wait?
[10:01] <fwereade> not sure
[10:01]  * fwereade -> lunch
[10:06]  * dimitern lunch as well
[10:06] <TheMue> fwereade, dimitern: enjoy
[10:08] <TheMue> jam: I updated mgo yesterday, so that change may be the reason, yes
[10:12] <jam> TheMue: I'm pretty confident about it. 3 retries * 500ms = 1.5s, which is what we are all seeing.
[10:13] <jam> TheMue: https://bugs.launchpad.net/juju-core/+bug/1183320
[10:13] <_mup_> Bug #1183320: TestOpenDoesNotDelayOnHandshakeFailure fails with updated MGO <test> <juju-core:Confirmed> <https://launchpad.net/bugs/1183320>
[10:13] <jam> TheMue: so right now mgo allows you to specify a custom Dial (which is how we inject TLS support)
[10:14] <jam> does it sound like we should be able to inject a retry delay?
[10:14] <jam> or just punt
[10:14] <jam> and remove the test.
[10:14] <jam> I would think that locally for testing we'd *really* like to set the retry delay to something really low, because we aren't dealing with network partitions while running the test suite.
[10:14] <jam> so sleeping 500ms in a test suite is a bit silyy
[10:15] <TheMue> jam: sgtm
[10:15] <jam> I feel like waiting for a patch to land in mgo so that we can use the Tarmac bot for juju-core and goose is a bit of a *long* way around the problem... :(
[10:19] <TheMue> jam: niemeyer should be available soon
[10:20] <jam> dimitern: for the Units api that you're working on.
[10:20] <jam> Does the individual Unit objects you are returning have 'name' in them?
[10:21] <jam> (I'm guessing they do)
[10:21] <jam> For something like an RPC, I would like to avoid depending on the order being identical to the request order.
[10:21] <TheMue> jam: dimitern is at lunch
[10:21] <jam> also, I don't think we want 1 bad name to fail the rest of the requests because of potentially stale data.
[10:42] <jam> TheMue, fwereade: In go, if you close a channel, then a pending <- on the channel returns, right? And it returns the zero value for the type?
[10:43] <jam> Which means that technically the code in state/presence/presence.go which is waiting on "case <- done:" is actually getting false, but since it is just using it as a block
[10:43] <jam> it doesn't actually care that the result is 'false'
[10:46] <TheMue> jam: one moment
[10:46] <jam> TheMue: I *think* I sorted out that the logic is it wants a channel that returns a bool, but all the inner code does is close the channel it has pending
[10:46] <jam> it never sends something on that channel
[10:47] <TheMue> jam: just looking at the code
[10:47] <jam> it is a bit convoluted :)
[10:48] <jam> I was trying to understand TestSync
[10:48] <jam> as to why it thinks one call to Sync blocks
[10:48] <jam> (for at least 200ms)
[10:48] <jam> but it will be done after a later change.
[10:51] <TheMue> jam: so far it seems you're correct, it's just closing the collected syncs
[10:51] <TheMue> jam: wife called me for lunch, biab
[10:51] <jam> TheMue: enjoy
[11:24] <jam> fwereade, wallyworld_: I just sent an email to the list that is intended to roughly summarize what I got out of our chat last night about API. It would be nice if you could read over it and see where you agree/disagree/have more notes, etc.
[11:25]  * dimitern is back
[11:25] <wallyworld_> ok
[11:25] <dimitern> jam: what's up?
[11:31] <jam> dimitern: I ended up just commenting on your merge proposal
[11:36] <danilos> jam: hi, trouble connecting to mumble server (connection times out :/)
[11:38] <danilos> this seems to be the weird problem I've been seeing since quantal where my internet just stops working for any new connections but IRC keeps ticking along
[11:38]  * danilos reboots
[12:12] <fwereade> aw hell
[12:14] <fwereade> dimitern, I think LifecycleWatcher is broken... ISTM that we trash intermediate results if the client doesn't pull from out before a new value arrives from in
[12:15] <fwereade> dimitern, also (and this is nothing to do with you) this style completely invalidates the assumptions rog made when he did the original always-call-Next model
[12:15] <fwereade> dimitern, do I recall you saying he was involved in its implementation?
[12:16] <dimitern> fwereade: standup still, will get back to you
[12:16] <fwereade> dimitern, np
[12:57] <TheMue> *hmpf*
[12:57] <fwereade> TheMue, encountering pain?
[12:57] <TheMue> fwereade: only effort. ;)
[12:58] <TheMue> fwereade: agent.Conf and upstart are so self-aware about their location (used in Write() and Install())
[12:58] <fwereade> TheMue, relative to DataDir, right?
[12:59] <TheMue> fwereade: yes, but they also write references to the DataDir as far as I can see
[12:59] <TheMue> fwereade: so using the container dir full qualified here would later to an illegal dir when used from inside the container
[13:00] <fwereade> TheMue, gaah, code reference?
[13:01] <TheMue> fwereade: I have to check, it has been an assumption as it is a field in each struct. but maybe you're right. that would be great.
[13:02] <fwereade> TheMue, I think you just write a conf to the full path, and start the agent with the container-relative path, and you're done
[13:02] <TheMue> fwereade: oh, in agent conf the read value from the file is overwritten by the passed one which is an arg of the jujud
[13:02] <TheMue> fwereade: nice
[13:02] <fwereade> TheMue, oh, we write it out? damn, that's stupid
[13:02] <dimitern> fwereade: just finished, but have to dash out quickly, sorry
[13:03] <fwereade> dimitern, no worries
[13:03] <fwereade> dimitern, ping me when you're back
[13:03] <TheMue> fwereade: we write it, but then, when reading the file in ReadConf(dir, tag), that dir is used.
[13:04] <TheMue> fwereade: so the right one is used later, only in the conf file the full qualified path is written
[13:05] <fwereade> TheMue, it is more than somewhat insane that we write the file's path into the file though, feel free to fix that (or at least comment it, because it's seriously misleading)
[13:05] <fwereade> TheMue, or hell just leave it
[13:05] <TheMue> fwereade: so it only would confuse somebody debugging and reading that file inside a container wondering where this dir comes from
[13:05] <fwereade> TheMue, agnt.Conf is ludicrous anyway :/
[13:06] <TheMue> fwereade: hehe
[13:06] <fwereade> TheMue, it's absurdly overloaded
[13:08] <TheMue> fwereade: absolutely. hmm, wouldn't omit the writing of that field be enough? if it is set each time after reading the file?
[13:08] <fwereade> TheMue, it'd probably be slightly better
[13:08] <fwereade> TheMue, better still to actually *separate* the ancillary in-memory data from the stuff we serialize rather than smooshing it all together
[13:11] <TheMue> fwereade: yes, but it's always so convenient to use a field instead of passing an argument through all nested methods. ;)
[13:13] <fwereade> TheMue, heh :(
[13:13] <TheMue> fwereade: hehe
[13:16] <TheMue> fwereade: *hmpf* again, there are so many references to that DataDir. thankfully most simply reading the field
[13:39] <dimitern> fwereade: back
[13:53] <fwereade> dimitern, hey, sorry I missed you
[13:53] <fwereade> dimitern, 5 min chat in the hangout before kanban?
[13:58] <dimitern> fwereade: oops, too late i think
[13:59] <dimitern> fwereade: i'm in the kanban g+ now
[14:02] <fwereade> ffs
[16:04] <Makyo> Running into the following problem, would appreciate input: a test is setup with a service (riak), but when running, the assert fails that the service "riak"doesn't exist.  if I deploy riak as the first step of the test, I get "cannot add service \"riak\": service already exists" - any ideas?
[16:09] <Makyo> Here: http://bazaar.launchpad.net/~makyo/juju-core/upgrade-charm2-1171548/view/head:/state/statecmd/upgradecharm_test.go#L80
[16:14] <dimitern> fwereade: mail sent
[17:14] <FunnyLookinHat> let's say I wanted to disable the security ( nova / quantum ) group stuff - where would I look to start commenting stuff out in src / trunk ?
[18:19] <fwereade> FunnyLookinHat, driveby answer: environs/openstack/provider.go:809; and consider stubbing out all the methods with names like OpenPort, ClosePort, etc
[18:19] <FunnyLookinHat> fwereade, perfect - thanks!
[21:02] <wallyworld_> fwereade: hi, if you have a chance, can you take another look at https://codereview.appspot.com/9662048. tim had a question about the --series param and non-ubuntu deployments. i can change the flag's description text to something more generic. perhaps that's all we need for now
[21:05] <thumper> morning
[23:45] <thumper> hi wallyworld_
[23:45] <thumper> wallyworld_: how are you doing today?
[23:45] <wallyworld_> hi, was going to ping you soon. getting through some mechanical changes to clean up some aspects of our errors
[23:46] <wallyworld_> a bit noisy here - guys trashing our bathroom
[23:46] <thumper> hah
[23:46] <wallyworld_> :-(
[23:46] <wallyworld_> $$$$$$$
[23:46] <thumper> expected trashing?
[23:46] <wallyworld_> well, the shower has been rooted for weeks, big leak :-(
[23:46] <thumper> hopefully only one of them and not all at once
[23:47] <thumper> :(
[23:47] <wallyworld_> so they need to pull apart the entire room
[23:47] <thumper> wallyworld_: I've been trying to get loggo working
[23:47] <wallyworld_> cool
[23:47] <thumper> wallyworld_: however there are so many issues with our logging in the tests
[23:47] <thumper> that makes it hard
[23:47] <thumper> time consuming
[23:47] <thumper> and energy sapping
[23:47] <thumper> I need something enervating to do
[23:47] <wallyworld_> yeah, this is my surprised face, not
[23:48] <wallyworld_> we can discuss surrogate ids :-)
[23:48] <bigjools> g'day
[23:48] <thumper> hi bigjools
[23:48] <wallyworld_> bigjools: fuck off
[23:48] <thumper> bigjools: how are you feeling these days?
[23:48]  * thumper slaps wallyworld_
[23:48] <thumper> none of that here
[23:48] <thumper> play nice
[23:48] <wallyworld_> thumper: he knows i'm joking
[23:48] <thumper> wallyworld_: but others reading here don't
[23:48] <wallyworld_> it's the way we say hello in australa
[23:49] <bigjools> it's his standard greeting.  If he doesn't say it I know he hates me :)
[23:49] <thumper> lovely jubbley, say it on the private channels then :)
[23:49] <bigjools> consider yourself bitchslapped wallyworld_
[23:49] <wallyworld_> sigh
[23:49] <bigjools> heh
[23:49] <wallyworld_> everything is so politically correct nowadays
[23:49] <thumper> sarcasm also doesn't come across well on irc
[23:50] <thumper> wallyworld_: be non-pc on private channels, not public logged ones
[23:50] <thumper> sad but true
[23:50] <thumper> aspect of online life
[23:50] <wallyworld_> yeah i know
[23:51]  * thumper sighs
[23:51]  * wallyworld_ sighs again
[23:51]  * thumper looks to bigjools for the next sigh
[23:52] <bigjools> meh
[23:52] <bigjools> tired of sighing lately
[23:52] <bigjools> thumper: anyway to answer your question, I am slightly better than I was thanks.  Had a torrid time last week but seem to be relatively ok at the mo. (fingers crossed)
[23:55] <thumper> cool


[00:00] <fta> there's no soname
[00:01] <fta> apparently, the shared lib magic from scons is still far from libtool
[00:01] <asac> fta: we should really encode the tag in changelog for new upstream revisions
[00:01] <fta> didn't I ?
[00:02] <fta> i thought i did...
[00:02] <asac> fta: nss.head?
[00:02] <asac> dont see it
[00:02] <asac> just the version. but hard to guess without version scheme
[00:02] <asac> but we are bad about that for other branches to i guess
[00:02] <fta> at least in nspr.head
[00:04] <asac> ack. can confirm that  its in nspr.head
[00:04] <asac> ok so just a glitch ;)
[00:06] <fta> the great fear of having nspr/nss diverged in xul trunk was unfounded. they are in sync, i think i can go back to system lib in trunk
[00:06] <fta> we should also revisit the in-source libjpeg
[00:07] <fta> and we must update system sqlite, ours is old now
[00:07] <rzr> asac: task #1 ready : https://code.launchpad.net/~rzr/firefox-extensions/flashblock.ubuntu/+merge/1727
[00:19] <asac> fta: well. i dont mind about system libs or not. i just think that nss will move ahead once they have RTM
[00:20] <asac> rzr: next time please create the new upstream changelog when doing the merge
[00:20] <fta> in practice, they bump nss and nspr in branch and trunk at the same time
[00:20] <asac> e.g. in revision 11 you could have created new UNRELEASED changelog entry with just
[00:20] <asac> * new upstream release (...)
[00:20] <asac> fta: how about ffox 2?
[00:21] <fta> i don't know, i don't monitor it
[00:21] <asac> was that migrated to latest 3.12 ?
[00:21]  * asac looks
[00:21] <asac> fta: http://mxr.mozilla.org/mozilla1.8/source/client.mk#261
[00:21] <asac> so that means that they will move ahead ;)
[00:22] <asac> sooner or later ;)
[00:22] <fta> ix:~/bzr/build-area/chromium-v8-<IP_ADDRESS>~svn20081105r696$ scons library=shared sample PREFIX=/usr DESTDIR=debian/tmp install
[00:22] <fta> scons: Reading SConscript files ...
[00:22] <fta> scons: done reading SConscript files.
[00:22] <fta> scons: Building targets ...
[00:22] <fta> scons: Nothing to be done for `sample'.
[00:22] <fta> Install file: "libv8.so" as "debian/tmp/usr/lib/libv8.so"
[00:22] <fta> scons: done building targets.
[00:22] <fta> double shot of \o/
[00:22] <asac> good ;)
[00:22] <asac> rzr: why the orig rule=?
[00:23] <fta> but they can't do shared and static in on shot..
[00:23] <asac> rzr: we dont want to produce orig.tar.gz, but produce an updated .upstream branch
[00:23] <rzr> this help to generate the upstream tarball for debian
[00:23] <rzr> i try to merge it as best as possible
[00:24] <rzr> is it annoying ?
[00:25] <asac> rzr: why use  a different orig for debian than for ubuntu?
[00:25] <asac> e.g. both can be generated from branches
[00:26] <asac> rzr: problem is that people see that and use that for ubuntu
[00:26] <asac> i am sure ;)
[00:26] <asac> and then things become messy
[00:26] <rzr> it's troll time :)
[00:26] <asac> e.g. we get uploads with bzr
[00:27] <rzr> anyway I can remove this part if needed
[00:27] <asac> rzr: is README.source relevant if you have the get-orig-source code?
[00:28] <rzr> README seems mandatory
[00:29] <rzr> since the user will know where his software come from
[00:29] <asac> rzr: yeah. but the content should be correct. it should read: "to build orig.tar.gz run ./debian/rules get-orig-source "
[00:29] <rzr> It's in policy IICR
[00:30] <asac> current content looks like it duplicates the content in debian/rules ... at best
[00:30] <rzr> I am not sure, policy ask to put address of the upstream tarball
[00:30] <rzr> am i right ?
[00:30] <rzr> and debian/rules is not installed on user system
[00:31] <fta> asac, http://www.scons.org/wiki/SconsVsOtherBuildTools
[00:31] <rzr> I'll remove get-orig-source if you want
[00:31] <rzr> not README.source :)
[00:31] <rzr> or you have to kill me :)
[00:32] <asac> rzr: keep get-orig-source .... and add how to use debian/rules to reproduce current orig.tar.gz in a first paragraph
[00:32] <asac> and keep the full explanation in a 2nd paragraph: "how to get the upstream source manually"
[00:32] <rzr> this will fail tests
[00:33] <rzr> desert island test  etc ...
[00:33] <asac> not sure what you mean
[00:33] <asac> the full instruction will still be in
[00:33] <rzr> not in the deb file
[00:33] <asac> just add a 1st instruction
[00:33] <rzr> in the patch file
[00:33] <rzr> in other words
[00:34] <asac> rzr: read what i wrote
[00:34] <asac> two paragraphs:
[00:34] <rzr> the upstream source will not visible from : /usr/share/doc/flashblock
[00:34] <asac> 1st. how to use get-orig-source
[00:34] <asac> 2nd. how to do it manually
[00:34] <rzr> ok
[00:34] <asac> 2nd == what you currently have
[00:34] <rzr> it's ok for me
[00:35] <asac> but imo the desert island test is about licenses
[00:35] <asac> and not about orig ;)
[00:35] <asac> if you are on a desert island you wont be able to access upstream repos anyway ;)
[00:35] <asac> so the only source you might have is the orig.tar.gz on a source CD/DVD
[00:35] <rzr> no but I can write a book and put a reference to him
[00:36] <rzr> and rely on the fact that policy ask this to be mentionned in copyright file
[00:37] <asac> not sure i understnad ;)
[00:37] <rzr> well it's late :)
[00:37] <asac> but dont mind ... if you add the 1st paragraph ... and also a hint about upstream branch ;)
[00:37] <asac> thats ok
[00:37] <rzr> ok perfect
[00:38] <rzr> upstream branch ? ubuntu one I guess, using bzr-buildpackage i guess ?
[00:38] <rzr> debian guys will hate me :)
[00:39] <asac> rzr: later things will be released to debian from there too
[00:39] <asac> mozilla-devscripts will go up
[00:39] <asac> and then there is no reason not to directly upload there
[00:39] <asac> rzr: no not how to build from branch ... instruuction how to update .upstream tree
[00:40] <rzr> on LP right ? if some ubuntu+debian DD can sponsor FB to debian this will be perfect for me
[00:41] <rzr> else any reference to LP or ubuntu will make me loosing my time to the debian guys...
[00:42] <rzr> oh well,
[00:50] <asac> ok keep it out of that then.
[00:50] <asac> but i think it should be in
[00:50] <asac> but until -devscripts is in debian its not really needed to name it
[00:53] <rzr> http://rzr.online.fr/volatile/tmp/README.source
[00:53] <rzr> is the branch name correct ?
[00:53] <rzr> because I am the owner not a motu ou core developper
[00:55] <asac> rzr: thats ok. use the code.launchpad.net url instead
[00:55] <asac> (so yuo can directly navigate using browser)
[00:55] <rzr> ok this is safer
[00:55] <asac> huh?
[00:55] <asac> rzr: https://code.launchpad.net/~rzr/firefox-extensions/flashblock.upstream
[00:58] <rzr> I thought about only : https://code.launchpad.net/firefox-extensions
[00:58] <rzr> since it can move
[00:58] <rzr> if I'm killed by a debian integrist or ubuntu terrorist
[00:59] <rzr> nevermind
[01:06] <rzr> asac: let me wish you a good night and thanks for your explanations I appreciated
[01:06] <rzr> btw, the branch is ready
[01:13] <asac> rZr: the upstream version is wrong
[01:13] <asac> 1.3.11.a
[01:13] <asac> where did you get that from?
[01:14] <asac> that should be 1.3.11a
[01:14] <rZr> there is a bug
[01:14] <rZr> there are 2 files
[01:14] <rZr> install.rdf and install.js
[01:14] <asac> yes. install.rdf should match
[01:15] <rZr> it doesnt
[01:15] <rZr> i used install.js instead
[01:15] <rZr> should this be reported upstream ?
[01:15] <rZr>         <em:version>1.3.11.a</em:version>
[01:17] <asac> rZr: yes. please ask "ted" on irc.mozilla.org
[01:17] <asac> maybe do that tomorrow
[01:17] <rZr> ok
[01:19] <asac> commented that on the merge
[01:46] <asac> dpkg-shlibdeps: warning: couldn't find library libxpcom.so needed by debian/firefox-3.0/usr/lib/firefox-3.0.4/components/libbrowserdirprovider.so (its RPATH is '').
[01:46] <asac> fta: ^^ ;)
[01:46] <asac> whats that?
[01:46] <asac> did we always have that=
[01:47] <asac> hmm
[01:47] <asac> maybe local xulrunner dir
[01:48] <asac> ok
[01:48] <asac> its ok
[01:48] <fta> yes, for ages, maybe forever
[01:49] <asac> sure
[01:49] <asac> was confused by libxpcom.so for amoment
[01:49] <asac> forgot that its not wrapped into libxul.so
[01:50] <fta> i have no idea of how to teach scons to do the libfoo.so -> libfoo.so.X.Y.Z
[02:00] <fta> or to use a soname
[02:00] <asac> fta: soname is usually just ldflag
[02:01] <fta> yes but i don't call ld myself
[02:01] <fta> hm, maybe i can pass a flag somewhere
[02:01] <asac> nv['NUMPY_PKG_CONFIG'][libname].version
[02:01] <asac> env['NUMPY_PKG_CONFIG'][libname].version
[02:02] <asac> http://www.opensync.org/ticket/467
[02:03] <asac> At the moment we're lacking at SO-NAMING support in our scons environment. Sorry about that .. the implementation of SO-NAMING support in our scons env is planned. I don't recommend to package 0.30 yet .. it's only interesting for developers and advanced testing and maybe for packagers which need some time to get familiar with scons.
[02:04] <asac> env.SharedLibrary ('target', sources, RPATH = "/usr/lib", SHLINKFLAGS = env['SHLINKFLAGS'] + ' -Wl,-soname=$TARGET')
[02:05] <fta> thanks, i'll have a look
[02:08] <asac> i have the feeling that it really lacks support for it
[02:08] <asac> there is just: SHLIBSUFFIX
[02:08] <asac> cannot see that it does magic from soname or seomthing and creates the appropriate links
[02:08] <asac> i think we should add SHLIBVERSION
[02:08] <asac> or something
[02:09] <asac> appaned that to SHLIBSUFFIX
[02:09] <asac> and create the appropriate links
[02:10] <fta> i think the author of scons is in the #chromium channel, i'll ask him next week
[02:10] <fta> how should i name the v8 package ? chromium-v8 / chromium-v8-dev ? libv8 / libv8-dev ?
[02:11] <asac> fta: do we have a chromium-v8 project?
[02:11] <asac> i still think we hsould have one
[02:11] <fta> not yet, i'm not ready to push any of the branches
[02:11] <asac> then ship stuff in chromium-v8 source and produce libv8*
[02:11] <asac> binaries
[02:12] <fta> not libv8-0 ? or something like that?
[02:13] <asac> not sure
[02:13] <asac> but including a version should be ok
[02:22] <fta> next step will be to teach chromium how to use system v8
[02:24] <fta> asac, well, 1st attempt (still without the soname stuff): http://paste.ubuntu.com/72660/
[02:27] <fta> asac, http://paste.ubuntu.com/72662/
[02:29] <asac> fta: ok. do you gen-symbols?
[02:29] <fta> ?
[02:30] <asac> to track symbols
[02:30] <asac> of lib
[02:30] <fta> no, not yet
[02:30] <asac> k
[02:31] <fta> i should try to upstream my patches asap
[02:31] <fta> i feel this one will be tricky
[02:47] <fta> "To work with the V8 code you need to download and build the development branch. Active development of V8 takes place on a branch, branches/bleeding_edge, from which we push "green" versions that have passed all tests to trunk/ every week or so. "
[02:47] <fta> interesting, trunk is not HEAD :)
[02:51] <asac> yeah ... but trunk is most likely what is wanted for HEAD packaging :-P
[02:53] <fta> yes, i have not plan to package "bleeding_edge" but this is mandatory to create patches against it to upstream them
[02:56] <asac> if its once a week the diff shouldnt be that massive usually
[03:20] <fta> gen-symbols is impossible without soname
[11:46] <armin76> asac: http://rafb.net/p/NEqexh24.html
[12:15] <armin76> asac: http://rafb.net/p/twPPKg34.html <- this one better
[14:15] <asac> insane
[14:15] <asac> my IRC system just hang
[14:16] <asac> it hung up over night and didnt work until i plugged in a monitor and rebooted. all fine
[14:17] <asac> lets hope that this isnt the beginning of the end
[14:17] <asac> http://de.youtube.com/watch?v=yX8yrOAjfKM&feature=bz301
[14:17] <asac> The Matrix Runs on Windows -> Ubuntu ;)
[14:20] <asac> so obviously if there was any ping or such ... dont expect an answer :)
[14:21]  * directhex pings asac
[14:23] <asac> heh
[14:49] <asac> armin76: SIGBUS
[14:49] <asac> please reproduce
[15:05] <asac> @time
[15:05] <asac> reconnect
[15:11] <armin76> asac: http://rafb.net/p/NEqexh24.html
[15:11] <armin76> asac: http://rafb.net/p/twPPKg34.html <- this one better
[15:11] <asac> armin76: thats the unpatched crash
[15:11] <asac> ;)
[15:11] <asac> armin76: now we need to get the other ;)(
[15:11] <asac> oh
[15:12] <asac> the first one is new
[15:12] <armin76> the first one is when starting with a fresh profile
[15:12] <asac> armin76: first one is probably useless because of corrupt stack
[15:12] <asac> scary
[15:14] <armin76> the second is with an used profile, because gdb-6.8 doesn't seem to want to run it when creating the profile, dunno why
[16:49] <asac_the_bumber> i'll be king
[16:53] <asac> asac_the_bumber: found the issue?
[16:54] <asac_the_bumber> nope
[16:54] <asac_the_bumber> i just built <IP_ADDRESS> with debian's patch
[16:55] <asac> k
[17:13] <fta> in ff3.1, all my rss/atom prefs changed to preview in Shiretoko :( useless
[17:19] <fta> https://edge.launchpad.net/chromium-project ... feels weird to see chromium maintained by a mozilla team..
[17:32] <fta> a chromium team would look nicer
[17:35] <sebner> fta: a chromium team with ubuntu mozilla team guys? ^^
[17:43] <fta> a restricted team, like mozillateam, ie, with write access to branches
[17:48] <fta> asac, 1st branch: https://code.edge.launchpad.net/~chromium-team/chromium-v8/chromium-v8.head
[17:51] <rZr> asac: upstream is about to fix the typo , I'll update it then and tell you when to merge my branch
[17:57] <fta> http://www.labnol.org/internet/google-chrome-logo-design-inspiration/4414/ :)
[18:00] <armin76> asac: http://rafb.net/p/O7dgMn96.html <- with the patch
[18:24] <asac> armin76: please post the patched nsUrlClassifierDBService.cpp
[18:25] <armin76> asac:  http://rafb.net/p/PrTIvx80.html
[18:27] <asac> armin76: imo that means that the compiler is right when it spits out warnings for nsTArray
[18:27] <asac> which we ignore ;)
[18:31] <armin76> no u
[18:31] <armin76> *g*
[18:36] <asac> armin76: can you please build the classifier cpp file with -Walign-cast ?
[18:36] <asac> e.g. in build tree just remove the .o and so on and manually invoke the g++ line
[18:39] <armin76> let me build it
[18:46] <asac> wow. armel is really slow ;)
[18:46] <asac> https://edge.launchpad.net/+builds/prumnopitys
[18:46] <asac> xul is already building more than 2 hours
[18:46] <asac> and is in layout/
[18:49] <armin76> mozilla-firefox-<IP_ADDRESS>: Fri Aug 11 08:35:17 2006: 13 hours, 39 minutes, 30 seconds
[18:49] <armin76> mozilla-firefox-<IP_ADDRESS>-r2: Wed Jan 17 06:11:48 2007: 14 hours, 36 minutes, 42 seconds
[18:49] <armin76> mozilla-firefox-<IP_ADDRESS>: Wed Jul 25 08:32:50 2007: 18 hours, 12 minutes, 30 seconds
[18:49] <asac> armin76: where is that?
[18:49] <armin76> thats on a netwinder, 233mhz 128mb
[18:49] <asac> on your system?
[18:49] <asac> oh
[18:49] <asac> well. i think this one has 500 or so ;)
[18:49] <asac> not sure
[18:49] <asac> mhz
[18:50] <fta> yosh, enough of gimp for today, https://edge.launchpad.net/chromium-v8
[18:50] <armin76> xulrunner-<IP_ADDRESS>: Thu Sep 25 18:31:18 2008: 3 hours, 15 minutes, 0 seconds <- with distcc
[18:51] <asac> fta: so you took over team ownership ;)
[18:51] <sebner> asac: how are your holidays going? ^^
[18:51] <fta> asac, so far yes, noone else worked on this
[18:51] <asac> fta: thats ok. just thought mt was team owner before
[18:51] <asac> but dont care much
[18:52] <asac> sebner: too much holiday ;)
[18:52] <asac> isnt good
[18:52] <fta> asac, it was weird to have a mozilla team owner of a competitive project
[18:52] <asac> fta: well ;)
[18:53] <asac> fta: but retroactively restricting team ownership isnt the best way either ;)
[18:53] <sebner> asac: I thought so :P btw, you forgot to comment :P bad boy. however, not necessary anymore
[18:53] <asac> sebner: comment?
[18:54] <sebner> asac: on my application ;)
[18:54] <fta> asac, well, what are non active members good for in a team? i see tons of users joining teams just to collect logos
[18:55] <asac> fta: just a point that when you bump people better ask ;)
[18:55] <fta> sure
[18:55] <sebner> asac: MOTU application. but as I said. not necessary anymore
[18:58] <[reed]> fta: chromium-team should take over https://launchpad.net/googlechrome
[18:58] <[reed]> :)
[18:59] <asac> fta: so do we need to go for individual ownership for everything mozillateam owned now?
[18:59] <fta> [reed], well, this page should be removed instead
[18:59] <fta> asac, ? eh?
[19:00] <asac> nm
[19:00] <[reed]> fta: true, dunno how to delete it, though!
[19:01] <[reed]> asac: remember, mozilla-related sessions at the latter half of UDS week, please!
[19:01] <asac> yeah
[19:01] <[reed]> considering I only get to MV on Tuesday afternoon ;)
[19:01] <fta> asac, i just created a new team because chromium is not a mozilla project, no other reason, if you want to join, you're welcome, after all you're canonical so you can join everything
[19:01] <asac> fta: didn't know that canonical entitles to join everything ;)
[19:03] <sebner> asac: bah :P
[19:03] <[reed]> fta: I agree that mozillateam shouldn't own Chromium
[19:03] <asac> [reed]: thats not the question ;)
[19:03] <sebner> mighty asac shouldn't be scared :P
[19:03] <asac> there isnt much a question as of now ;)
[19:07] <fta> [reed], it's done using questions.. Question #51560
[19:08] <fta> Question 51560
[19:08] <fta> answer 51560
[19:08] <fta> bahh
[19:08] <fta> https://answers.edge.launchpad.net/launchpad/+question/51560
[19:08] <[reed]> lol
[19:12] <fta> i think i won't do openkomodo, it's another xul engine with tons of patches
[19:12] <asac> you should really take over debian bug 497701
[19:12] <asac> otherwise there will be duplication of effort
[19:13] <fta> you already know i'm no longer interested by debian
[19:14] <asac> still if debian does a package it doesnt make sense to maintain it independently here
[19:14] <asac> fta: you will end up in a situation where you have rdepends on debian package getting synched here
[19:14] <asac> and then you are not free anymore, but become dominated by what debian folks do to your package in debian
[19:14] <fta> i don't understand why we always have to work with them but don't give a damn about our work, this is not fair
[19:15] <asac> because we still sync a lot of other work from them
[19:15] <fta> -but+but they
[19:15] <asac> fta: right. but it saves a lot of work
[19:16] <asac> fta: you need to first upload. then you can upload without being a DD
[19:16] <asac> and the syncs get back here
[19:16] <asac> fta: also you can circumvent all the REVU stuff ;)
[19:17] <asac> just push it to debian and see how it gets here automatically ;)
[19:20] <armin76> asac: it doesn't give any warning
[19:21] <asac> armin76: with -Wcast-align ?
[19:22] <armin76> asac: err, wait
[19:23] <armin76> asac: http://rafb.net/p/lsgB8a46.html
[19:28] <asac> armin76: why is there a reinterpret cast in 2027 at all=
[19:30] <armin76> thats from debian's patch
[20:10] <asac> https://edge.launchpad.net/ubuntu/+source/xulrunner-1.9/<IP_ADDRESS>+nobinonly-0ubuntu1/+build/788444/+files/buildlog_ubuntu-jaunty-armel.xulrunner-1.9_<IP_ADDRESS>+nobinonly-0ubuntu1_FULLYBUILT.txt.gz
[20:11] <asac> Finished:   2 minutes ago  (took 3 hours 50 minutes)
[20:11] <asac> ^^ armin76
[20:12] <armin76> asac: omgs!
[20:13] <armin76> well, it just took 4 hours
[20:23] <sebner> armel, hihi
[21:23] <fta> armel      7573 builds waiting in queue
[21:24] <asac> yeah. now that xul is there things can lift off
[21:24] <fta> with ~1h per package, that's still one year
[21:31] <asac> nah ;)
[21:31] <asac> 1h is too much
[21:31] <asac> average is 4min ;)
[21:33] <fta> i can no longer build ff3.1 in jaunty/ppa :(
[21:33] <fta> FATAL: kernel too old
[21:33] <fta> http://launchpadlibrarian.net/19629359/buildlog_ubuntu-jaunty-i386.firefox-3.1_3.1~b2~hg20081113r21632%2Bnobinonly-0ubuntu1~fta2_CHROOTWAIT.txt.gz
[22:14] <fta> boom http://paste.ubuntu.com/73091/
[22:33] <fta> damn; https://edge.launchpad.net/v8


[04:19] <bazhang> e10byagrue<EMAIL_ADDRESS>has joined #ubuntu
[04:19] <bazhang> thats an imaginative nick
 helps me remove these ads
[05:03] <bazhang> from PM
[05:03] <gnomefreak> bazhang: are ou IRCC?
[05:04] <gnomefreak> s/ou/you
[05:04] <bazhang> gnomefreak, he means the ads on 12.10 (not really ads, but it's slashdot, so sensational)
[05:04] <bazhang> gnomefreak, for giving back ops in -ot?
[05:06] <gnomefreak> bazhang: im looking for councle to try and get all my access list reset. it seems i lost the mai. that box get ~1500 every week or 2 but as it statys im only ops in #u #u-mozillateam and maybe here i havent testet
[05:06] <gnomefreak> bazhang: i had more than ot alot more
[05:07] <gnomefreak> if the email can be sent to a new address i can return it this time now that i know im looking for it
[05:08] <bazhang> yep. someone posted where you can look on launchpad for this, let me check the scrollback here
[05:08] <gnomefreak> thanks
[05:09] <bazhang>  when gnomefreak comes back, tell him he can go to LP/~id/+expiringmembership/ and renew anything that's coming up.
[05:09] <gnomefreak> thanks bazhang ill check it out
[05:12] <gnomefreak> bazhang: not sure how much help this is please let me know what im doing wrong  https://launchpad.net/+search?field.text=LP%2F~id%2F%2Bexpiring+membership%2F
[05:13] <bazhang> ~gnomefreak/+expiringmembership
[05:14] <bazhang> or whatever your id is
[05:15] <gnomefreak> bazhang: thanks checking now
[05:15] <bazhang> np
[05:17] <gnomefreak> bazhang: i keep getting a error here is the error im seeing https://launchpad.net/~gnomefreak/+expiringmembership
[05:17] <gnomefreak> one of thoswe lost something errors
[05:18] <gnomefreak> brb smoke and think
[05:28] <gnomefreak> it seems we now are getting amazon store intergrated in launcher
[05:29] <bazhang> the ads guy
[05:30] <gnomefreak> beeetles == adds guy? for some reason taht nick rings a bell with me
[05:31] <gnomefreak> and no i cant spell its 1:30ish am
[05:32] <bazhang> he kept flooding the channel with the slashdot article
[05:34] <gnomefreak> ah
[06:31] <bazhang> http://benjaminkerensa.com/2012/09/22/lots-of-hype-over-shopping-lens-in-ubuntu-12-10    good clarification/rebuttal to all the idiocy surrounding this
[06:40] <Flannel> bazhang: The initial post there draws a null conclusion based on incorrect information.  It's a bit of an anti-clarification.
[06:53] <bazhang> ok