[11:47] <zul> can someone review python-jsonschema please its sitting in binary new, and its blocking glance
[12:00] <cjwatson> zul: Sorry for the delay.  For main inclusion, I expect that the MIR team will want (a) a watch file and (b) for the package to run its test suite at build time (e.g. 'python -m unittest discover').  Neither of these block acceptance into the archive, though, so accepted.  Thanks
[12:00] <zul> cjwatson: cool...ill get to that today, thanks
[12:02] <cjwatson> zul: Hmm, why does python-jsonschema seem to install into /usr/lib/python2.7/dist-packages/ directly rather than as a symlink into /usr/share/pyshared/?  Am I hallucinating?
[12:02] <zul> cjwatson: im not sure but ill take another look at it
[12:08] <cjwatson> Not a big deal since there'll be no python2.8, but it's a bit weird
[12:14] <pitti> cjwatson, zul: I think that's completely expected
[12:14] <pitti> dh_python2 just does that now, it seems the /pyshared/ approach has been dropped
[12:15] <pitti> i. e. it affects all python packages now
[12:15] <pitti> not just -jsonschema
[12:15] <cjwatson> Oh, huh
[12:15] <cjwatson> Surprising
[12:16] <pitti> NB I'm not saying that it really should be like that, just that it's not package specific, but a changed behaviour from dh_python2 apparently
[12:16] <cjwatson> Yeah, I see that now
[14:19] <ScottK> pitti and cjwatson: The change doko made in dh_python2 in Ubuntu is uncoordinated with Debian and gratuitously breaks packages.  It should be reverted.
[14:21] <ScottK> The relevant bug is Bug 1001912
[14:21] <ubot2> Launchpad bug 1001912 in python-defaults "dh_python2: revert pyshared removal in 2.7.3-0ubuntu3" [High,Confirmed] https://launchpad.net/bugs/1001912
[15:18] <slangasek> ScottK: doko is currently away so you shouldn't expect a quick response from him; I think you should go ahead and revert it for now as the safer option
[15:18] <ScottK> slangasek: Thanks.
[15:19] <ScottK> slangasek: Would you mind saying so on ubuntu-devel ML too (so I can point to it when he gets back)?
[15:19] <Laney> well, he has been replying on the bug
[15:19] <slangasek> I mind saying on ubuntu-devel that he's away, yes :)
[15:20] <ScottK> slangasek: Right, I mean that I should go ahead.
[15:20] <ScottK> I don't mind leaving the reason out.
[15:20] <highvoltage> I guess inside canonical you have some kind of free/busy calendar.
[15:20] <highvoltage> it would actually be nice if there were somewhere where anyone could mark themselves as temporarily away.
[15:20] <slangasek> ScottK: sure
[15:20] <highvoltage> (sorry I'm just thinking out aloud)
[15:48] <Daviey> cjwatson: Hey, what changes do i need to make on nusakan to start using a livefs?
[15:50]  * ogra_ wonders if you actually need any code changes
[15:51] <ogra_> theoretically you might be able to just use the right cmdline
[15:52] <cjwatson> Daviey: mail me the details of what you're doing and I can advise and/or sort it out
[15:52] <Daviey> cjwatson: Does it really need a mail?  'make ubuntu server use live-installer'
[15:53]  * ogra_ thinks theoretically teh following might just work ... : buildlive ubuntu-server daily-live && for-project ubuntu-server cron.daily-live
[15:54] <ogra_> but you will likely need ubiquity adjustments or do you plan to run under X ?
[15:55] <Daviey> ogra_: We've tested with d-i net installs, using live-installer udeb, not ubiquty.
[15:56] <cjwatson> Daviey: please mail me :)
[15:56] <cjwatson> I don't have a lot of spare brain
[15:56] <cjwatson> and I need to know what if anything you've done to livecd-rootfs so far
[15:57] <cjwatson> also you guys owe me two live-installer bug reports from UDS
[15:57] <skaet> cjwatson, can you add me to the response.   Would like to understand this.
[15:57] <cjwatson> Daviey: ^-
[15:58] <Daviey> cjwatson: were they not reported.. *sigh*.. Sorry... Well, we can't switch until they are fixed.. So, i'll shelve this, pending those bugs.
[15:59] <cjwatson> Daviey: have you done anything to livecd-rootfs?
[16:08] <Daviey> cjwatson: nein
[16:18] <cjwatson> Daviey: here, I have one of the bugs fixed locally already (missing kernel).  do you remember off the top of your head what the other one was?
[16:20] <Daviey> cjwatson: One was kernel not being installed if outside the squashfs.. and the other was a debconf value for remote retrieval of squashfs
[16:20] <cjwatson> oh, that one
[16:20] <cjwatson> hm, not sure how to do those two simultaneously, mind :)
[16:20] <cjwatson> maybe it would be easier to disable the kernel hack in server squashfs generation for now
[16:21]  * cjwatson also notes that live-installer doesn't seem to update the initramfs, at least from code inspection
[16:21] <Daviey> well.. if you are netinstalling, you don't have the kernel on the filesystem, do you?
[16:21] <Daviey> which means they need additional retrieval, unless bundled into the quashfs (yucky)
[16:22] <cjwatson> bundling it into the squashfs isn't particularly yucky
[16:22] <cjwatson> it's a removal of an Ubuntu-specific optimisation *shrug*
[16:22] <ogra_> all other squashfses carry it
[16:22] <Daviey> well, it means for cd image, the kernel is shipped twice?
[16:22] <cjwatson> Yes
[16:22] <cjwatson> Not the end of the worl
[16:22] <cjwatson> d
[16:22] <Daviey> no.
[16:22] <cjwatson> It makes some difference for space, but we got by without it for quite a while
[16:23] <cjwatson> update-initramfs> Ah, never mind, it'll remove casper and then update-initramfs, now that I look at it
[16:24] <Daviey> cjwatson: okay, bundling seems reasonable, and satisfies cd and netinst.
[16:24] <cjwatson> I've fixed live-installer to cope with unbundling (I think) anyway
[16:28] <skaet> https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
[16:28] <Daviey> oo, thanks
[16:28] <skaet> has been updated, based on the interlock.
[16:29] <skaet> if anyone spots any glitches,  please flag.  :)
[16:29] <skaet> https://wiki.ubuntu.com/QuantalQuetzal/ReleaseInterlock
[16:29] <skaet> has all the key events in it now as well.
[16:30] <skaet> (getting a few more details added from Linaro though...)
[16:36] <cjwatson> Daviey: and you have network image support as well, assuming I didn't screw it up.  can't easily test it until we have images.
[16:45] <ScottK> Is the chroot problem on nihal known?  See https://launchpad.net/ubuntu/+source/python-defaults/2.7.3-0ubuntu4/+build/3509558
[16:47] <cjwatson> I got ops to fix that, but didn't go through and retry stuff.  Oh, but that's more recent.  Not again.
[16:48] <cjwatson> reported
[16:55] <ScottK> Thanks.
[16:56] <cjwatson> Hope those boxes get upgraded to precise/armhf soon ...
[16:58]  * ogra_ hopes for highbank instead :)
[17:05] <stgraber> ogra_: you should have put that calxeda server in your bag while there weren't looking ;)
[17:05] <ogra_> damned, now you tell me !
[17:06] <ogra_> though i would have been to sick to carry it i guess
[17:25] <ogra_> geez
[17:25] <ogra_> ubuntu-server-dove/quantal/armel+dove failed to build
[17:26] <ogra_> i wouldnt have thought i'd ever seee such a message again :)
[17:26] <highvoltage> ogra_: awesome!!!
[17:26] <ogra_> heh
[17:26] <ogra_> i doubt building dove was intentional :)
[17:26] <highvoltage> ogra_: that's going straight to google+!
[17:40] <cjwatson> ogra_: wasn't intentional, I was experimenting but not with that; I'll fix it up in a bit
[22:07] <Laney> best. process improvement. ever.
[22:08] <slangasek> ?
[22:08] <Laney> oh, you've ignored queuebot :P
[22:08] <slangasek> ;)
[22:08] <Laney> backports DIY + queuebot = fast acceptance
[22:08] <slangasek> so was that sarcasm? :)
[22:08] <slangasek> ah
[22:09] <slangasek> the queuebot should just send to twitter
[22:10] <stgraber> that's certainly easy to implement ;)
[22:10] <tumbleweed> that was a very fast backport!
[22:12] <Laney> still binary NEW to go!
[22:12]  * Laney whips ubuntu-archive
[22:13] <ScottK> Laney: That's not the proper backports versioning.
[22:14] <ScottK> Should be 1.9.9-1~precise1
[22:14] <Laney> it is what broder and cjwatson came up with at UDS
[22:14] <ScottK> Sigh.
[22:14] <ScottK> Any particular reason to change or are we just changing for changes sake?
[22:14] <tumbleweed> to work around the zaney zebra wrap-around
[22:14] <Daviey> I thought there was a concerted effort to try to reduce the use of codenames post release?
[22:14] <cjwatson> We're about to wrap round the alphabet.
[22:14] <cjwatson> FSVO "about".
[22:15] <cjwatson> We need to stop assuming that codenames sort.
[22:15] <ScottK> OK.
[22:15] <ScottK> Backports is approximately the last place we need to assume that though.
[22:15] <ScottK> err .. stop assuming that.
[22:15] <cjwatson> Indeed.  But why wait? :-)
[22:16] <cjwatson> It's also one of the few places that was assuming it in the first place.
[22:16] <ScottK> It's certainly a change there should be some communication about.
[22:16] <ScottK> OK.
[22:16] <Daviey> well, i would hope that there would be a newer upstream version of software come wrap-around time for the backports usecase..
[22:16] <Daviey> but yes, it's a race regardless.
[22:16] <ScottK> I mind the surprise more than I mind the change.
[22:16] <cjwatson> I was hoping broder would send mail about it ;-)
[22:17] <Laney> hm, the process page doesn't mention versioning at all any more
[22:17]  * cjwatson eyes openlp and wonders if he can get the local primary school to stop using Powerpoint for projecting hymns ...
[22:18] <Laney> the modern age... back in my day we made good with OHP
[22:19] <Daviey> hand written lyrics no less.
[22:19] <Laney> of course
[22:20] <Daviey> kids today, don't know they are born, eh Laney ?
[22:21]  * Laney shares a Werthers with Daviey


[08:07] <dholbach> good morning
[08:09] <micahg> morning dholbach
[09:53] <HOHOHaney> ello
[12:38] <`-`> #ubuntu ops are nazi fags. please remember to use your brain not that other bit of the anatomy the #ubuntu team appears to think is best.
[13:02] <Rhonda> Oo
[13:52] <Q-FUNK> howdy!
[13:52] <Q-FUNK> any m4 guru here? :)
[13:53] <HOHOHaney> I need something to alert me to forgotten CCs / attachments
[13:54] <Q-FUNK> I'm trying to tweak debian/rules and I seem to be misunderstanding how to use "ifequ" in http://paste.debian.net/147813/  - I need to make the part in install be skipped in VIDEOABI is empty.
[13:57] <tumbleweed> Q-FUNK: you mean ifeq
[13:57] <geser> debian/rules is a simple Makefile, not a m4 macro file
[14:01] <geser> have you tried to add "ifeq ($(VIDEOABI),)" before the "echo" call + "endif" after the "echo"?
[14:01] <Q-FUNK> tumbleweed: erm, yes :)
[14:02] <Q-FUNK> geser: http://paste.debian.net/147814/   like this?
[14:02] <Rhonda> HOHOHaney: mako did some sendmail wrapper that checks for the words "attached" and similar in mails and rejects unless there is either an attachment or a special header in the mail.
[14:03] <HOHOHaney> yeah, something like that
[14:03] <Rhonda> HOHOHaney: http://projects.mako.cc/source/attachcheck/
[14:03] <HOHOHaney> i'll look for it, t
[14:03] <HOHOHaney> oh :-)
[14:03]  * Rhonda . o O ( git )
[14:03] <Rhonda> git clone git://projects.mako.cc/attachcheck
[14:04] <geser> Q-FUNK: yes, is it intended that you moved it also to the xdepends target? (although it probably doesn't make a difference in this case)
[14:09] <ockham_> hi, anyone feel like reviewing http://revu.ubuntuwire.com/p/unity-lens-bliss ?
[14:10] <Q-FUNK> geser: it seems to me that I might as well group all those Depends generations there.
[14:10] <ockham_> btw i'm using Standards-Version 3.9.2 in it, about which REVU's linitian complains. should i really downgrade to 3.9.1?
[14:11] <geser> ockham_: no, keep 3.9.2, it's just that REVU's lintian doesn't know of 3.9.2 yet (didn't get updated)
[14:11] <ockham_> geser: thx, i figured. it's just a bit annoying as it kinda suggests my package isn't lintian clean. hopefully doesn't scare off reviewers...
[14:11] <Q-FUNK> geser: ok.  this was a lot simpler than I thought.  thanks for the help!
[14:14] <geser> ockham_: have you tried if someone from #ubuntu-desktop (or anyone from unity with upload rights) is willing to review it?
[14:14] <ockham_> geser: no, not yet. good idea, though. might try #ayatana, too.
[14:55] <Guest4224> hi
[17:02] <tumbleweed> Laney, stgraber, cjwatson: Useful? lp:~stefanor/ubuntu-dev-tools/who-can-upload-876554 (e.g. http://paste.ubuntu.com/757271/ )
[17:07] <micahg> tumbleweed: there's a lot of redundency in the output
[17:08] <tumbleweed> micahg: there'd be even more if I wasn't filtering duplicate packageset permissions (don't know why those exist)
[17:09] <cjwatson> it's an LP bug when opening new distroseries
[17:09] <tumbleweed> micahg: one could expand teams in an area at the bottom (or say [already expanded, see above])
[17:09] <tumbleweed> but tbh, I don't tihnk people will use -t much
[17:09] <micahg> tumbleweed: right, but under Ubuntu Kernel Uploaders you have core-devs, then the core-dev team as a member with the list again under it
[17:09] <Laney> what's the point of the tool?
[17:10] <Laney> the discussion in the bug was for release team / freeze stuff
[17:10] <Joe_CoT> hey, looking for people on the Security team. are there plans to update ffmpeg in the releases to address the new security fix point releases?
[17:10] <Laney> the security team live in #ubuntu-hardened
[17:10] <Laney> but micahg can help you ;-)
[17:11] <jdstrand> Joe_CoT: mdeslaur is working on it
[17:11] <tumbleweed> Laney: well it doubles as a 'what packageset is this in, without remembering how to use edit_acl tool' :)
[17:11] <tumbleweed> Laney: but yes, that's why I'm asking
[17:12] <Laney> I would like should-i-upload which links into some service that knows about soft freezes / freeze policies
[17:12] <tumbleweed> Laney: btw, 8 / 15 releases imported
[17:12] <Joe_CoT> jdstrand, cool, thanks. Do you know if there's an ETA, or a launchpad bug I can track?
[17:12] <Laney> nice
[17:12] <tumbleweed> soft freezes aren't visible in lp
[17:13] <jdstrand> Joe_CoT: I think soonish, but you'd have to ask mdeslaur.
[17:13] <Laney> yes
[17:13] <jdstrand> mdeslaur: ^
[17:13] <Laney> that is why 'some service' and not launchpad
[17:13] <Laney> (or fixing launchpad)
[17:13] <mdeslaur> Joe_CoT: I'm awaiting on an answer from siretart about some libav fixes
[17:14] <Joe_CoT> ok, thanks. My company's security guy is bugging me about it, so I was asking to see if I can wait for the package update or need to compile it
[17:15] <Joe_CoT> anyway, thanks for being on it :)
[17:16] <mdeslaur> Joe_CoT: can't really give an ETA without the answer, but I could guess we'll have a fix out in the next 2-3 weeks
[17:16] <tumbleweed> Laney: so, you don't think there's any value in listing PPUs and packagesets outside of edit_acl? or you don't think this is relevant for the bug
[17:16] <Laney> I think the bug title and description ask for different things
[17:16] <Laney> and personally I don't find it that useful as people generally know what they can upload and there is one interface for sponsors (modulo security) these days
[17:17] <Laney> but that may be me
[17:17] <tumbleweed> well, we know that LP needs to display packageset membership a little more clearly
[17:18] <tumbleweed> but yes, for freezes, it doesn't tell you anything that apt-cache show | grep Task doesn't
[17:18] <Joe_CoT> mdeslaur, so you have an idea of what you're updating to? like for Lucid, are you going to 5.5, or going up to one of the later releases. I think I'm going to get pushed into compiling it, but I want to go with the same version you guys are going to package
[17:22] <Joe_CoT> mdeslaur, nevermind, we're waiting, since that'll be within the disclosure date, and no one seems to be exploiting the bug yet. thanks!
[17:23] <Laney> tumbleweed: There might be value in can-i-upload foo if it either says "Yes you can" or a some condensed output (with --verbose)
[17:24] <Laney> "No, since you do not have upload access to component main or packagesets foo bar baz (--verbose to see who does)"
[17:24] <tumbleweed> we already have a lpapicache function for that
[17:24] <Laney> excellent
[17:24] <tumbleweed> ah, if you want the reason for not being able to, we don't
[17:24] <Laney> well you just wrote it :P
[17:26] <Laney> it could even indicate yes or no with exit status for use in scripts (but I cannot imagine any usecases for that atm)
[17:27] <tumbleweed> you mean I'm going to have to write a manpage for this now? :)
[17:27] <Laney> bdrung would let you merge it otherwise?!
[17:27] <tumbleweed> I think he's got bored of reviewing every commit I make :P
[17:27] <bdrung> tumbleweed: a new script without a man page?
[17:27] <Laney> haha
[17:27] <bdrung> ts ts ts
[17:27] <broder> right on cue!
[17:28]  * Laney is off to the climbing competition: https://www.facebook.com/photo.php?fbid=10150503191911756&set=a.10150503187896756.428884.38579036755&type=3&theater — enjoy writing documentation :-)
[17:29] <tumbleweed> enjoy. /me hasn't climbed in ages :/
[17:29] <broder> oh yeah, speaking of docs, i'm planning to push out my new backports docs this weekend of anybody has last minute feedback
[17:29] <broder> ScottK, micahg, Laney, tumbleweed: ^
[17:29] <bdrung> Laney: isn't climbing with a ladder easy?
[17:29] <ScottK> broder: I gave it a quick read and it seems good.
[17:29] <micahg> broder: sorry, will try again this weekend to review
[17:30] <bdrung> broder: where can i read it?
[17:30] <broder> we *can* always change these after the fact :)
[17:30] <ScottK> Yeah, I'm fine with pushing it.
[17:30] <broder> bdrung: http://bit.ly/rNEOWc
[17:31] <bdrung> broder: "new version of OS"
[17:31] <bdrung> shouldn't that be written out?
[17:31] <broder> i don't think so; we don't in the current docs
[17:32] <broder> but there is a missing possessive there, which i've added :)
[17:32] <Laney> hrm
[17:33] <Laney> tumbleweed: I just noticed that the branch for LP API sponsoring (yay) overrides .creator but doesn't seem to give any way to get sponsor through PAI
[17:33] <Laney> API
[17:33] <Laney> can you ping bigjools?
[17:33] <Laney> bye o/
[17:34]  * tumbleweed assumes he can
[17:34] <Laney> I would have done it but I don't have any time to get into a discussion
[17:34]  * Laney REALLY GOES. REALLY. BYE.
[17:35] <micahg> broder: typo in the second to last line, says cna should be can
[17:35] <micahg> broder: also, I thought we determined that -backports is enforced with the same archive upload permissions as the rest of the pockets(except -security)
[17:36] <micahg> ooh, google docs shows live editing :)
[17:36] <bdrung> broder: second page: "(lucid-backports)" -> user should be informed that "lucid" is different on each release
[17:36] <broder> micahg: ah yes, so we did. /me makes a note
[17:37] <tumbleweed> broder: doesn't this need to cover the pre-release backports?
[17:37] <broder> :-/ yeah, probably
[17:37] <broder> i was hoping to have these up before that got approved so i could let the docs get stale again for a while before dealing :
[17:37] <broder> :)
[17:37] <tumbleweed> heh
[17:38] <tumbleweed> even more reason to do it now :)
[17:38] <broder> actually, i think i'd rather hold off on updating the docs until we have the infrastructure in place for pre-release backports
[17:38] <broder> because i suspect that we will discover policy questions in the process of making the tools work
[17:39] <tumbleweed> Laney: his merge-proposal says "UI changes will happen in a future branch" I think the API is UI
[17:39] <bdrung> broder: can you highlight "unsupported updates" so that it's obvious that this is the text of the gui?
[17:40] <broder> the formatting will probably look slightly different when i translate everything to wikispeak
[17:47] <bdrung> broder: "If the backport does require source changes, it should go through the normal sponsorship process once it has been approved by the backports team." -> ubuntu devs can upload directly after an ACK?
[17:48] <broder> bdrung: yes, but only if there are source changes required
[17:48] <broder> if it's no-change, it should be done by an AA
[17:48] <broder> (for now - if we can get queue permission granularity from LP, we might be able to change that)
[17:48] <bdrung> broder: that should be more clear (direct upload for non-no-change backports)
[17:50] <broder> bdrung: ok. re-worked the text - better?
[17:51] <bdrung> broder: yes, better
[20:25] <jtaylor> opinions on wether this is SRU'able? bug 877519
[20:25] <jtaylor> ups wrong bug
[20:25] <jtaylor> this one: bug 871176
[20:26] <jtaylor> fix is simple but it also is not really such a grave bug for the regular user
[20:27] <broder> seems mostly reasonable to me, but it's not my call
[20:27] <broder> wouldn't this affect anything using nose, though?
[20:27] <broder> (if so, i think limiting the discussion to its impact on ipython understates the problem)
[20:29] <jtaylor> I assume nothing should get broken by fixing it
[20:29] <jtaylor> matplotlib has nothing to do with defining global test macros
[20:29] <jtaylor> only things relying on accidentally getting matplotlibs version would break and that should not be the case
[20:30] <broder> for simple patches like that, the regression concern is usually not about the fix itself, but about random, unpredictable other things happening in the process of rebuilding the package
[20:33] <broder> i'm kind of excited about discovering that i can do `s=$(schroot -bc natty-amd64); mk-build-deps -i -r -s "schroot -rc $s -u root --" `
[20:34] <jtaylor> hm what is this error about: http://paste.ubuntu.com/757463/
[20:37] <EvilResistance> any of ya able to point me at what i need to do to create a source package from actual source that comes with its own ./configure script?
[20:39] <jtaylor> checkinstall can do that to some extent
[20:39] <broder> EvilResistance: http://developer.ubuntu.com/packaging/html/packaging-new-software.html ?
[20:42] <EvilResistance> broder, ah cool...
[20:42] <EvilResistance> didnt know that existed :P
[20:48]  * arand is guessing "dh $@"
[20:50] <broder> well, yes, but the rules file isn't the hard part of creating a package these days :-P
[20:50] <broder> (personally, i find i spend as much time writing the description as everything else put together)
[20:50] <jtaylor> the copyright is the worst ._.
[20:54] <arand> Indeed, 1200 lines is my record so far for d/copyright
[20:54] <jtaylor> :O
[20:54] <jtaylor> my worst has 9 different licenses
[20:55] <jtaylor> but lgpl gpl and apache are in common making the file short :)
[20:56] <arand> Bah, that's peanuts, I've got about 10 custom written, plus: by, by-sa, mit, zlib, ofl..
[20:56] <broder> gah. string processing in C sucks
[20:57] <arand> (granted, the custom one's are mostly attempts at cc-by or cc-0)
[21:09] <tumbleweed> broder: that's definitly something to have as a function in my bashrc, thanks
[22:30] <broder> ...huh, impressive. update-notifier pops up telling me to upgrade to oneiric when i'm running off a natty live cd
[22:34] <kees> broder: if you've got enough RAM.... :P
[22:34] <broder> i wonder what would happen if i went through with the install after taking the upgrade...
[22:34] <broder> actually, i guess it probably explicitly just unpacks the squashfs


[12:27] <Teduardo> Hi, is it ok to ask a debian-installer question here?
[12:28] <Teduardo> there doesnt appear to be any installer community for debian available on irc


 Everyone went home.
[18:20] <oCean> marmelade in #u is this troll I think, but cannot remember the name/previous bans
[18:22] <oCean> oh wait, isn't it lars? torben?
[18:27] <oCean> I wager it's him
[18:36] <oCean> is there even an active ban on him? Seems that a lot have been removed since
[18:39] <oCean> right: 41282
[18:45] <oCean> but no active one I think
[22:11] <hypatia> i am so confused by #u-o at the moment
[23:40] <Pici> I'm normally confused about #u-o
[23:40] <ldunn> This is entirely normal
[23:41] <charlie-tca> I'm normally confused
[23:50] <hypatia> good point


[16:43] <effendy[m]> leo_cuyar: Who knows, maybe if you had an actual question, someone might even answer!