[00:06] <Caelum> Hi, does ubuntu have any support for building 32 bit binaries on 64 bit hosts via -m32 and such, or do you have to use chroot tools? It doesn't seem like it, I just tried e.g. apt install wxgtk3.0-dev:amd64 wxgtk3.0-dev:i386 # and got a bunch of conflicts
[00:26] <sarnold> Caelum: if you want repeatable builds it's usually best to create a schroot for the i386 environment and set up sbuild to use that
[00:26] <sarnold> Caelum: it ought to be possible to compile 32 bit withuot that step but it might not be as straightforward
[00:27] <sarnold> Caelum: I'd expect you to be able to install both -dev packages for i386 and amd64 side-by-side but sometimes mistakes happen. If the version numbers are identical but you can't do it, file a bug; maybe it'll be addressed
[00:52] <cjwatson> Caelum: as well as what sarnold said, basically using -m32 rather than a chroot is supported for a fairly minimal set of libraries but not for everything
[00:52] <cjwatson> it's doable if you just need libc/libstdc++ and maybe a few other small and simple libraries; not so much for wxgtk, say
[01:17] <Caelum> ok thanks, that's what I wanted to know
[01:17] <Caelum> fwiw things are not that much better on other dists
[01:19] <Caelum> on fedora the -devel libs do install side by side, but you have to figure out the 32 bit deps yourself, while on arch you can install the lib32 libs, but some you have to get from AUR
=== jamesh_ is now known as jamesh
[07:56] <smb> nacc, Sounds like the best approach that can be done. The diff looks good to my (not yet caffinated eye). With the bug reference people might look an find tgt mentioned.
[08:51] <wgrant> seb128: We finally have zesty langpacks, after some silly postgres issues. They should be running regularly on Tuesdays now.
[08:52] <wgrant> (and I did a manual run this morning, so a fresh full export exists)
[08:56] <sil2100> seb128: hey! I poked Trevinho already about this and he pointed me to you - I'm looking for someone that's maintaining unity-settings-daemon
[08:56] <sil2100> seb128: there's a merge on the sponsoring queue for a long long time that I'd like someone review/release - https://code.launchpad.net/~chrisccoulson/unity-settings-daemon/lp1542699/+merge/288952
[09:06] <seb128> wgrant, thanks, I was going to ping about that again today since I didn't know if you saw my previous ones ;-)
[09:06] <seb128> sil2100, we don't really have a maintainer for it, Trevinho should feel like he can approve changes ... anyway that one looks fine and I trust chrisc_coulson to know what he's doing
[09:06] <seb128> so feel free to merge it
[09:07] <sil2100> seb128: could you approve the merge? I might try to silo it up later on and drive it through Bileto finally
[09:09] <seb128> sil2100, done
[09:09] <sil2100> seb128: thanks!
[09:10] <seb128> thank you for the ping
[09:17] <freedwhayt> Where are kernel packages on Ubuntu Hybrid CD?
[09:22] <sil2100> jbicha: hey! I wanted to release https://bileto.ubuntu.com/#/ticket/2447 (as I want to follow up with another u-s-d landing) but I see the merge is not approved yet
[09:22] <sil2100> jbicha: I think Robert had some concerns with the MP
[09:22] <sil2100> jbicha: could you take care of that so we could release this silo?
[09:45] <philroche> Hi, would someone on the Ubuntu Sponsors team be able to help with a critical GCE bugfix please? LP:1668327 needs to be marked as critical and target Trusty, Xenial, Yakkety and Zesty. I have uploaded patches for Xenial, Yakkety and Zesty and was hoping I could land them all in -proposed today. Thanks https://bugs.launchpad.net/ubuntu/+source/gce-compute-image-packages/+bug/1668327
[09:45] <ubottu> Launchpad bug 1668327 in gce-compute-image-packages (Ubuntu) "Startup scripts get run when guest packages are updated" [Medium,Confirmed]
=== zyga_ is now known as zyga
=== shadeslayer_ is now known as shadeslayer
=== Son_Goku is now known as Conan_Kudo
=== Conan_Kudo is now known as Son_Goku
=== morphis_ is now known as morphis
=== JanC_ is now known as JanC
=== zyga_ is now known as zyga
=== hikiko is now known as hikiko|ln
=== _salem is now known as salem_
=== hikiko|ln is now known as hikiko
[13:38] <philroche> Apologies I meant to post my request in #ubuntu-release
[13:39] <mardy> morphis: hi! Should I clone libhybris from github of lp?
[13:39] <morphis> mardy: take https://code.launchpad.net/~libhybris-maintainers/libhybris/+git/libhybris/+ref/master
[13:39] <morphis> but would be great if you can submit changes to both
[13:40] <morphis> mardy: doesn't the fix I proposed work?
[13:40] <mardy> morphis: actually, I just started working on it :-)
[13:40] <morphis> ok
[13:41] <mardy> morphis: or was the fix to be meant for the client code?
[13:41] <morphis> it was meant for the client, yes
[13:41] <Nitesh> Hello All, Anyway to figure out why I see the following inside a Ubuntu17.04 VM?  filesystem is turning into readonly due to some input output errors, why is it happening? https://paste.fedoraproject.org/paste/Gxod8BLm7Ewzyj1tP0pQr15M1UNdIGYhyRLivL9gydE=
[14:04] <mardy> morphis: I'm still studying the situation, and yes, I believe that the issue is in oxide
[15:04] <nacc> smb: true. I can even put that in the changelog
[15:53] <nacc> bdmurray, juliank : fyi, c.u.c has been reconfigured
[15:53] <nacc> bdmurray: so i'm going to close the bug and mark my MR as invalid
[16:18] <jbicha> sil2100: I think you mostly just care about https://code.launchpad.net/~jbicha/unity-settings-daemon/fix-ftbfs/+merge/320665
[16:18] <sil2100> jbicha: is this in some silo?
[16:18] <sil2100> Ah, new merge
[16:18] <sil2100> jbicha: can I use that one along with another merge I wanted to release?
[16:18] <jbicha> yes, go ahead! :)
[16:19] <sil2100> Since there was a very very very old u-s-d merge on the sponsoring queue that I'd like to get rid of by finally releasing it
[16:19] <sil2100> Excellent :)
[16:19] <sil2100> Thanks!
[16:19] <jbicha> the other MP isn't that important, so we can let robert_ancell finish reviewing it
[16:19] <jbicha> (let him finish reviewing my drop-updates-plugin MP)
[16:21] <sil2100> Ok
[16:23] <nacc> rbasak: iirc, you had pinged chrisccoulson on the firefox in z-p a few days ago? Is someone working on getting that working? or was that only for the SRU that you had pinged?
[16:25] <nacc> ah intersteing, the failure to build on armhf and s390x also exists on yakkety and xenial
[16:25] <nacc> so ... we have different version per architecture now? :)
[16:29] <jbicha> s390x was broken for yakkety release too
[16:29] <nacc> jbicha: ah ok :)
[16:30] <nacc> jbicha: i guess maybe they are declared as being don't care; just makes the rmadison output rather confusing
[16:30] <nacc> jbicha: and it's not great that 17.04 is behind 16.04 and 16.10...
[16:30] <jbicha> yes, chris is well aware of the zesty issue
[16:31] <nacc> jbicha: ok
[16:37] <bdmurray> nacc: cool, thanks for doing that
[16:38] <nacc> bdmurray: np, thanks for the patience
[16:38] <chrisccoulson> nacc,  firefox/s390x is something that (AFAIK) nobody cares about
[16:39] <nacc> chrisccoulson: ack, makes sense, was just reading through excuses. Seems like it should not be built there at all, maybe?
[16:40] <chrisccoulson> firefox/armhf should be fixed but I don't block security updates for x86/x86-64 due to an armhf failure, given that nobody tests the updates there anyway
[16:40] <rbasak> nacc: no it was just the regression-update bug I think.
[16:40] <nacc> chrisccoulson: ah i see -- ok, i wasn't aware of that nuance, thanks!
[16:40] <nacc> rbasak: ok
[16:41] <chrisccoulson> And I have pretty much no time to debug what is probably going to be a wrong-code bug in the compiler anyway (the armhf build failure is actually a start crash which I reproduced in a local build and makes absolutely no sense)
[16:41] <chrisccoulson> s/start/startup/
[16:41] <nacc> chrisccoulson: right, so should armhf also just not be built if it's not really supported?
[16:41] <nacc> chrisccoulson: i guess i don't fully understand what the long-term plan here is :)
[16:43] <chrisccoulson> nacc, no, somebody needs to fix the armhf build failure
[16:43] <chrisccoulson> Ideally the firefox maintainer that we don't have
[16:43] <nacc> ah i see :)
[16:44] <chrisccoulson> I'm just responsible for doing the security updates for firefox, and anything else is basically ricotz in his spare time
[16:44] <wxl> chrisccoulson: while you're around, who do i speak to about the thunderbird ppas?
[16:44] <wxl> (if anyone)
[16:47] <nacc> chrisccoulson: ah ok, i see -- i didn't realize that (was just going off the upload changelog)
[16:49] <ricotz> wxl, depends on which thunderbird ppa
[16:50] <wxl> ricotz: well, i guess which one's the right one? XD
[16:51] <wxl> ricotz: but i do mean https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa/+packages
[16:51] <ricotz> wxl, either https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+packages for stable or https://launchpad.net/~mozillateam/+archive/ubuntu/thunderbird-next/+packages for beta/next-stable
[16:52] <wxl> ricotz: so no luck on trunk, eh?
[16:53] <ricotz> wxl, imo there is no point to tackle that ;)
[16:53] <wxl> ricotz: well, i mean it hasn't build for trusty i386 since 38 or so.. :/
[16:54] <ricotz> wxl, the last is 45.8.0, but you can look into thunderbird-next ppa
[16:54] <ricotz> which has 52.0
[16:55] <bdmurray> nacc: Did you look for any bugs about the issue? e.g. how it'd manifest in clients / tools
[16:55] <wxl> ah good
[16:56] <wxl> that wouldn't have fixed anything yesterday
[16:56] <wxl> but it looks like we just had a successful build
[16:57] <nacc> bdmurray: i hadn't yet -- i didn't find any obvious ones when i filed my own, but I will go look now
[17:10] <bdmurray> nacc: What was the original issue again?
[17:11] <nacc> bdmurray: `apt-get changelog qemu` would fail because qemu is in universe, but src:qemu is in main
[17:15] <bdmurray> nacc: maybe bug 139791?
[17:15] <ubottu> bug 139791 in aptitude (Ubuntu) "aptitude changelogs 404 when the source is in a different component to the binary package" [Medium,Triaged] https://launchpad.net/bugs/139791
[17:16] <nacc> bdmurray: ah i had also only trawled src:apt so far
[17:17] <nacc> bdmurray: although that bug is probably fixed by the change, the testcase given is also no longer valid (src:kdepim is in universe since at least trusty)
[17:37] <nacc> bdmurray: ok, so on precise, that bug is still present, but i *think* for a different reason
[17:40] <bdmurray> nacc: Ah, okay.
[17:40] <nacc> bdmurray: debugging it still -- i think that one is an issue with kdepim having moved from main to universe (so there's no pool/main/k/kdepim at all)
[17:50] <nacc> bdmurray: actaully, i'm rather confused, i don't see any kdepim 4:4.8.5-0ubuntu0.1 changelogs on c.u.c ? and so the redirects still 404 since there is nothing to redirect to
[17:50] <nacc> bdmurray: maybe we don't care about precise, but i do wonder if extract-changelogs is missing some historical changelogs?
[17:52] <bdmurray> nacc: its possible there was a hardware failure a couple of years ago, I thought everything should have been regenerated though
[17:53] <bdmurray> nacc: its possible.
[17:53] <nacc> bdmurray: if i had to guess, those are the kind of bugs that are now fixed, i agree (component differences between src and binary pacakges)
[19:08] <slangasek> pitti: hey, so it appears systemd upstream test has regressed on the autopkgtest infrastructure sometime after the 10th, we now consistently get timeouts... does this issue look familiar to you?
[19:13] <slangasek> Laney: and do you know of any changes to autopkgtest infrastructure around the 10th that could be contributing? ^^
[20:18] <sinzui> rbasak: who do I talk to about bug 1669507
[20:18] <ubottu> bug 1669507 in juju-core (Ubuntu) "Remove juju-core from zesty" [Undecided,New] https://launchpad.net/bugs/1669507
[20:46] <Laney> slangasek: nope
[20:46] <slangasek> ok
[20:46] <Laney> Did someone try locally?
[20:47] <slangasek> I have not
[20:51] <Laney> the last message before the timeout looks kind of bad :)
[21:03] <rbasak> sinzui: release team to approve an FFe, and someone from ~ubuntu-archive to do the removal.
[21:03] <rbasak> sinzui: I'm not aware of any deb to snap transition mechanism.
[21:04] <rbasak> Perhaps a question for ubuntu-devel@
[21:04] <sinzui> rbasak: me neither, but If we can create a transitional deb for the snap, that would be grant
[21:04] <sinzui> grand
[21:25] <sarnold> nacc: heya, a user reported that the 'ubuntu changelog' links from e.g. http://packages.ubuntu.com/precise/abiword give 404s now -- is this the changelogs cleanup?
[21:28] <infinity> sinzui: There isn't a formal deb->snap upgrade mechanism that I'm aware of, which would make, IMO, dropping the deb somewhat premature and irresponsible.
[21:31] <sinzui> infinity: :/ Is it wrong for a deb's install hook to "snap install juju --classic"? What more would teh deb need to do?
[21:34] <infinity> sinzui: We don't really have a defined right or wrong there, as I don't think we've ever discussed it from an OS architecture perspective.  Calling a package manager from a package manager is certainly unexpected, but it would "work".  Is there user data that would need migration, or would it Just Work?
[21:35] <sinzui> infinity: indeed the JUJU_DATA dir remains a conern for me.
[21:36] <infinity> There also seems to no longer be a manpage.
[21:37] <sinzui> infinity: thats tragic since the most common reason for test build to fail is the man page didn't generate. We treat the man page as a first-class requirement in testing
[21:38] <infinity> Can't tell if sarcasm. :P
[21:38] <infinity> But yeah, not sure if that's your fault or snappy's or snapcraft, I'm not sure how manpages are (or aren't) handled in the snap world.
[21:38] <sinzui> infinity: it is not sarcasm :) I really do scream when the man page breaks in tests
[21:39] <sinzui> infinity: I suppose it will be my fault soon. I am taking over juju packaging again for a while
[21:39] <sarnold> infinity: comment #4 is good https://bugs.launchpad.net/snapd/+bug/1575593
[21:39] <ubottu> Launchpad bug 1575593 in snapd "Snappy installed manpages aren't accessible through man" [Low,Triaged]
[21:39] <infinity> Given there's no snappyish paths on the default manpath, I'd suspect that even if you did ship a manpage (which I don't see in your snap), we wouldn't see it.
[21:40] <infinity> sarnold: I assume that bug says what I just discovered.
[21:40] <sarnold> infinity: sortof. try fixing your PATH to include the new magic snappy things.
[21:42] <infinity> sarnold: There are no magic snappy man paths.  That's why the bug is still open.
[21:43] <infinity> (As in, /snap/man needs to mirror the layout of /snap/bin)
[21:43] <infinity> Anyhow, the juju snap ALSO doesn't ship a manpage, so even if the snapd bug were fixed, there'd be no manpage. :)
[21:43] <sarnold> heh :)
[21:45] <infinity> sinzui: Anyhow, I think from your POV, you want to try to minimize behavioural regressions and have a plan for data migration.  (Mark did some deb->snap migration of something a while back, etcd maybe?  You could look and see if that was crazy overengineered, or perhaps suitable)
[21:45] <sinzui> thank you infinity
[21:45] <infinity> sinzui: And then we need the large discussion of "is it sane for a deb to 'depend' on a snap, should there be a formal hooks process for this to happen, or ad-hoc postinst scripts, blah blah".
[21:46] <infinity> s/large/larger/
[21:48] <sarnold> if there's room for discussion here I think I'd rather see something common that indicates which debs ceased to exist and snap replacement names, to avoid having every postinst from trying to do this. I could imagine a lot of folks wanting to concentrate snaps on perhaps different machines than the ones that used to host things on debs, and not enjoying "hey we installed snapd and this snap" in the postinst of half-dozen packages..
[21:51] <sarnold> juju especially feels like a thing that someone would Care About doing themselves. I'd expect less magic there the better.
[21:56] <infinity> sarnold: I'm not wasting too much brain on it today, but there are several different scenarios and potential solutions to consider.
[21:57] <infinity> sarnold: While the one that's critical to get right (lossless migration when a deb "goes away") is applicable to the above, there's also the question of what to do about the system inevitably becoming more hybrid, and would it be sane to allow deb->snap dependencies, and what would that look like.
[21:59] <infinity> sarnold: Until now, I'd assumed (and hoped) we'd keep the deb world 100% self-contained, and snaps would be an opt-in, but it's pretty clear that some people would like to drop their deb offering entirely, and if one of those people happens to be a dep of someone else...
[21:59] <infinity> Web browsers are a perfect example here.  Dozens of things will suggest or recommend a browser for good reasons, and users shouldn't be forced to have two installed when one would suffice.
[22:00] <pitti> slangasek: hm, no, doesn't look familiar; upstream CI runs on xenial (doesn't happen there); a few weeks ago we had a qemu crash in that test because qemu didn't get along with something in the new kernel; but I don't see a qemu crash in the log this time
[22:01] <sarnold> hey pitti :)
[22:01] <sarnold> infinity: hrm. all good points. :/
[22:03] <infinity> sarnold: And then that just digs deeper into another rabbit hole where, if one were to upstream the concept of extra-system deps to dpkg and rpm, would we have a syntax of system:package for each extra-system system (snap, flatpak, etc, gross), or some generic app:firefox or role:webbrowser type syntax that could be satisfied with a backend priority-based switch that would divine what you probably want based on preferring snaps over flatpaks and ...
[22:03] <infinity> ... mozilla products over google and red over blue?
[22:03] <infinity> sarnold: So, yeah.  It quickly becomes a bit "whee".  But the migration thing is obviously the more urgent to examine.
[22:05] <infinity> Maybe we can borrow some Netflix code here for the preference guessing.  "We suspect you want a small indy web browser, published by a German distributor, featuring a strong female mascot, only allowing plugins on Tuesdays."
[22:05] <sarnold> genau das! bitte bitte :D
=== acheronUK is now known as acheronuk
[22:06] <jbicha> yes but will it let me print on Tuesdays?
[22:07] <sarnold> lol
[22:11] <infinity> jbicha: Arguably our best bug ever.
[22:11] <infinity> jbicha: Crashing X with 11 fingers on the touchpad was also solid.
[22:11] <infinity> Oh, and the Microsoft keyboard being detected as a Joystick with 37 axes and 57 buttons.
[22:12] <sarnold> hehehe
=== grumble is now known as grumble2
=== grumble2 is now known as grumble
=== salem_ is now known as _salem
=== _salem is now known as salem_
[23:00] <nacc> sarnold: sorry, i don't *think* so
[23:00] <sarnold> there's of course the chance that the link from there' salways been busted :) it's not like packages.ubuntu.com is a core service.. but it's awesome when you're reading things on you rphone..
[23:01] <nacc> sarnold: yeah -- i will need to talk to IS to figure out
[23:01] <sarnold> nacc: thanks
[23:02] <nacc> http://changelogs.ubuntu.com/changelogs/pool/universe/a/abiword/
[23:02] <nacc> sarnold: i don't see any 2.9.2
[23:02] <nacc> bdmurray: --^ this makes me think precise changelogs are just broken somehow
[23:02] <nacc> sarnold: it's the second precise package i have failed to find chagnelogs for
[23:03] <sarnold> iiiinteresting
[23:03] <bdmurray> I commented on the bug about how the trusty release pocket version of abiword is missing too
[23:03] <bdmurray> so I don't think its exclusive to precise
[23:03] <nacc> bdmurray: thanks -- i hadn't seen that yet
[23:04] <nacc> bdmurray: interesting, so something else is going on (it feels like). I can ask IS to disable the changes and see if they come back, but we aren't changing anything on the fs itself, so it seems unlikely
[23:04] <bdmurray> If I had to guess I'd say it was populated with a date argument that didn't go far enough back in time
[23:04] <nacc> bdmurray: yeah, i could see that
[23:04] <bdmurray> I'll look for the server fail RT
[23:05] <nacc> powersj: i think i see what is happening
[23:05] <nacc> powersj: if i had to guess, 2.16.12* was in yakkety-proposed
[23:05] <nacc> powersj: but never made it into release and so got copied forward to zesty-proposed
[23:05] <nacc> powersj: but we only know what actually happens
[23:05] <nacc> *what actually publishes
[23:05] <nacc> and the order in which they publish
[23:06] <nacc> https://launchpad.net/ubuntu/+source/mongodb/+publishinghistory
[23:06] <nacc> powersj: --^ yep
[23:06] <nacc> ah *this* is why deleted matters over superseded :)
[23:06] <nacc> rbasak: --^
[23:06] <nacc> powersj: in any case, it's not technically wrong, that did occur in yakkety development before yakkety closed
[23:07] <nacc> powersj: just never migrated -- so you would manually need to find the release pocket branch
[23:07] <nacc> powersj: well 'manually' lpusip/ubuntu/yakkety should do
=== salem_ is now known as _salem
[23:12] <bdmurray> nacc: Its RT 89921 but its not clear to me how the back population was done.
=== _salem is now known as salem_
[23:18] <bdmurray> nacc: the first log entries are from 2016-04-26 which seems like after the backfill would have been done.
[23:20] <nacc> bdmurray: thanks, looking it up
[23:24] <nacc> "  - Tried pushing that start date back in time but that just caused
[23:24] <nacc> timeouts/OOPS from LP"
[23:26] <nacc> bdmurray: yeah, for instance, the missing precise changelog was from a package published on 2012-05-01 :)
[23:26] <nacc> so I'm guessing we're missing a lot of precise changelogs
[23:27] <nacc> we could relatively easily ensure a changelog exists for every publish in the active series
[23:27] <nacc> or some subset of them
[23:27] <nacc> e.g., trusty, xenial, yakkety, zesty
[23:27] <nacc> iterating over every source package, checking if it exists and extracting it if not?
[23:29] <nacc> powersj: approving your tasks
[23:31] <rbasak> nacc: I guess we need to pick up deletions to move the devel pointers back in that case?
[23:31] <rbasak> (I'd use an additional merge -s ours commit)
[23:31] <nacc> rbasak: yeah, but i'm not sure how we'd know
[23:32] <nacc> rbasak: that would require going back in time on each new series creation?
[23:32] <nacc> rbasak: which is fine, just an algorithmic change of some significance
[23:32] <nacc> rbasak: right now, we assume we only ever need to visit a publish once
[23:32] <rbasak> Order publishes and deletes together in time
[23:33] <rbasak> Then when you see a delete, recalculate what was visible at that time, and if it's different from the tip, add a commit.
[23:33] <rbasak> Though "recalclate what was visible" might need looking back perhaps?
[23:33] <rbasak> Though I imagined one could determine that by looking at the "pocket" branch pointers.
[23:34]  * rbasak will think about it
[23:34] <nacc> well, i think we could do this (maybe) -- deletes only are relevant here when they were deleted for copy-forwards
[23:35] <rbasak> I'm not sure that's true, but it's late here so I'll leave thinking about it for another time :)
[23:35] <nacc> rbasak: for this particular issue, i mean (where -devel is past where it should be)
[23:35] <nacc> rbasak: there migth be other cases where deletes are relevant, but we've not really hit them yet :)
[23:35] <nacc> rbasak: ack, didn't think you'd respond in any case :)
[23:40] <nacc> bdmurray: if you want me to code something up, let me know (or i can put something in that other ticket)
[23:42] <bdmurray> nacc: If you're interested feel free. I think a new RT would be appropriate though.
[23:42] <nacc> bdmurray: ok, i may see if i can spin something up -- and will file a RT tmrw
[23:51] <piem> howdy. i'm trying to find out why aubio is not being updated to the latest version from debian. it's been there in 'proposed' for a few weeks now
[23:53] <slangasek> pitti: right, in this case there's no qemu crash logged and we see the console output up to a getty
[23:55] <sarnold> piem: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#aubio reports "Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)"  -- i'm a bit surprised, 114 days feels surprising here..
[23:56] <piem> sarnold: i guess i should head to that channel then. thanks
[23:57] <slangasek> that says why it's /currently/ not migrating
[23:57] <slangasek> previously, it could have been not migrating because its reverse-deps are not in a consistent and migratable state
[23:58] <sarnold> ahh