[04:14] <RAOF> Urgh. Have I broken CI again?
[04:14] <RAOF> The test-build worked, damnit!
[04:14] <RAOF> ON CI!
[05:25] <RAOF> OOOOooooooooh!
[05:37] <RAOF> I have become the destroyer of CI!
[05:45]  * RAOF should not work in branches where the default push is to the default CI runner.
[06:14] <RAOF> Alright!
[06:14] <RAOF> CI should really, really work now you guys.
[06:14] <RAOF> FOR REALZ!
[06:14]  * RAOF goes to pick up his car.
[07:27] <RAOF> Ok. Now CI's just messing with me.
[09:24] <anpok> yay renaming functions with the c-preprocessor is great
[09:27] <alan_g> It is a powerful technique - and should be used responsibly (i.e. rarely)
[09:28] <anpok> here it was used to link to archives together that use a lot of copied code
[09:28] <anpok> *two
[09:28] <anpok> hence one is built with a header full of #definef func old_func ..
[11:22] <alf_> alan_g: Hi! Could you please elaborate on "Indeed wouldn't placing a cache implementation directly in the configuration object be sufficient?". Do you mean that the configuration object should have something like: std::shared_ptr<SharedLibrary> the_platform_library() ?
[11:24] <alan_g> alf_: I was thinking of a data member SharedLibraryCache with a load_library member.
[11:26] <alan_g> But I guess we only ever load the one, so a std::shared_ptr<SharedLibrary> platform_library member would do.
[11:28] <alf_> alan_g: The SharedLibraryCache needs to be shared/survive across configurations and MirConnections, so I am not sure how a SharedLibraryCache as data member would work.
[11:28] <alan_g> alf_: OK, that answers my "needs info".
[12:19] <eanyx> hi
[12:22] <eanyx> Does someone has metrics for 2D/3D throuput of mir?
[12:23] <eanyx> throughput
[12:24] <kdub> there's a glmark built for mir
[12:24] <eanyx> Does the performance are good compared to legacy X?
[12:26] <kdub> sure
[12:26] <eanyx> In what proportion?
[12:34] <kdub> too vague questions
[12:36] <eanyx> I'm wanting to write a 2D game, and wanting to know what is the blitter speed ?
[12:38] <kdub> with the in-game stuff, thats up to you... for mir at least
[12:38] <kdub> we bypass fullscreen on mesa
[12:38] <kdub> and use the overlay path on android
[12:41] <kdub> could everyone take a look at  https://code.launchpad.net/~kdub/mir/frontend-tracking/+merge/232123
[12:41] <kdub> and indicate which of the two exchange_buffer messages are preferable?
[13:08] <eanyx> is there some vsync for smooth animation?
[13:09] <alan_g> kdub: I've looked and don't have a preference
[13:10] <kdub> thanks alan_g
[13:42] <eanyx> have to leave you, have a nive day/evening.
[14:01] <alf_> kdub: fine with both, although I wonder if allowing the client to indicate surf_id could be used maliciously. Of course we already trust the client library to give us correct info in general, so perhaps this is a non-issue.
[14:02] <kdub> alf_, yeah, agree
[14:03] <kdub> at any rate, i'll be on later than normal tonight, so I'll just chat it over with RAOF then
[15:09] <dandrader> a gmock question: is using MOCK_METHODX(....) any good when I want to check a complex parameter of a method?
[15:09] <dandrader> I have a parameter like this "const QList<struct QWindowSystemInterface::TouchPoint> &points"
[15:09] <dandrader> so I wanna iterate the list and check the values of the TouchPoint structure, etc
[15:11] <dandrader> I wonder if using the gmock magic stuff (like declaring the method with MOCK_METHOD() and using things like EXPECT_CALL()... in the test) will be of any use in this case
[15:11] <dandrader> or if I'm better of doing the mock implementation manually
[15:11]  * dandrader was told mir developers were the local gmock experts
[15:11] <tvoss> dandrader, you might want to look into MATCHER_P
[15:12] <tvoss> dandrader, so yes, gmock is quite useful in your scenario, and you can just describe your matching logic in MATCHER_P
[15:13]  * dandrader googles for MATCHER_P
[15:13] <kdub> there are also some container matchers
[15:13] <kdub> https://code.google.com/p/googlemock/wiki/CheatSheet#Container_Matchers
[15:13] <kdub> that might be helpful
[15:14] <dandrader> tvoss, kdub, ok, thanks for the tips. will look into those
[16:40] <josharenson> greyback__ when I build qtmir, it keeps failing on a mir header file, even though the file exists...
[16:40] <greyback__> josharenson: can I see the build output please? How are you building?
[16:41] <greyback__> josharenson: if you're building manually on the phone, you need this: qmake "QMAKE_CXX=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK_SHLIB=arm-linux-gnueabihf-g++-4.9"
[16:41] <josharenson> as per the readme.. mk-build-deps, qmake, make (getting a pastebin of the output)
[16:41] <greyback__> ah, I better update the readme - the 4.9 thing is annoying
[16:41] <josharenson> i was going to update it when I got it working :-p
[16:42] <josharenson> http://pastebin.ubuntu.com/8151394/
[16:44] <greyback__> josharenson: so libmirserver-dev is installed? In that case, I'd clean all & try again (qmake not good at seeing dependencies changing): bzr clean-tree && bzr clean-tree --ignore
[16:44] <greyback__> then try the qmake command again
[16:55] <josharenson> greyback__ I had libmirserver-dev installed, but cleaning the tree seems to have fixed whatever was wrong...
[16:56] <greyback__> josharenson: glad to hear it. Usually that happens to me if I run qmake before having all the dependencies installed. Running qmake again after often does not pick up the new header/lib directories
[16:56] <josharenson> greyback__ good to know, thanks
[16:56] <greyback__> full clean and retry is my usual fix
[16:56] <greyback__> np
[22:54] <rsalveti> AlbertA2: hey, while I agree that it's good to hold a lock during a voicecall, this same issue will happen next time we have an app using the proximity sensor
[22:54] <rsalveti> checking https://code.launchpad.net/~albaguirre/powerd/avoid-suspend-during-call/+merge/232290
[23:01] <Saviq> camako, is there an actual reason why we need the bump of qtmir dep to > 0.7.0? if not, we should just go for a no-change rebuild?
[23:02] <Saviq> camako, although the -gles dep should definitely be bumped to actually be in sync with the non-gles one, but in general unless there's API breaks we don't bump the -dev dependency, it will still build with the latest available
[23:02] <camako> Saviq we broke the ABI.. So I just updated the dependency
[23:03] <Saviq> camako, right, so we only need a no-change rebuild against the new -dev, debian/control deps should generally reflect the truth (as in what's the minimal mir version with which qtmir will build)
[23:03] <camako> Saviq, do you mean, for instance, if there is no client API break then leave the client dependency alone?
[23:03] <Saviq> camako, basically if there's no code changes required
[23:03] <Saviq> camako, there's no need to touch the deps
[23:04] <camako> Saviq, but we definitely broke the ABI on the server side... client side perhaps I should leave it alone
[23:05] <Saviq> camako, sure, but that will sort itself out through a no-change rebuild
[23:05] <Saviq> camako, the build system will select the highest -dev version during the build anyway, and then encode the real versioned dependency in the runtime dependencies
[23:06] <Saviq> camako, basically, qtmir can build with 0.6.0 still, can it not?
[23:07] <camako> Saviq, Oh I see what you mean... I dunno if it can actually..
[23:07] <Saviq> camako, if you only bumped the debian/control version and it still builds, sounds like it can :)
[23:08] <camako> Saviq, you're right... If mir hasn't changed actual code qtmir (or others) depend on then no need to do what I did
[23:08] <Saviq> camako, dependencies (especially versioned ones) in debian/control should be "the least required"
[23:09]  * Saviq comments on the MP then
[23:09] <camako> Saviq, I see... so how do we do a no change rebuild in the silo?
[23:09] <Saviq> camako, you just need an empty (--unchanged) commit in the MP
[23:10] <Saviq> camako, for the -gles counterpart you still need to sync the version number (and silo)
[23:11] <camako> Saviq, yes Iit's just prelim at this moment
[23:11] <Saviq> camako, yup
[23:12] <camako> Saviq, thanks man... every time I talked to you I'm illuminated :-)
[23:12] <Saviq> camako, always
[23:14] <Saviq> camako, for fast development like we do now it isn't as important, but once Mir becomes part of the default distro, LTS and such, it pays off to not bump deps unnecessarily so that you're not forced to unnecessarily build a chain of dependencies
[23:14] <Saviq> when someone wants to build on an older distro, that is
[23:14] <camako> Saviq, makes total sense...
[23:20] <Saviq> camako, one thing to note (when not bumping -dev deps), when you build things in silo, you need to make sure of the order things build in the right order
[23:20] <Saviq> camako, because if you just build mir and qtmir in parallel, qtmir will actually build against the distro version
[23:20] <camako> Saviq, ok.. and putting mir MP in the front doesn't help with that right?
[23:20] <Saviq> camako, no, they all get pushed to the PPA at the same time
[23:21] <Saviq> camako, you just need to run the build job with just "mir" first
[23:21] <Saviq> or whatever comes first for real
[23:21] <camako> Saviq, ok got it
[23:22] <Saviq> camako, I think there's a circular dependency between papi and mir still, which means you might actually need to build papi, mir, then papi again or something similar
[23:22] <RAOF> kdub_: Yo!
[23:22] <camako> Saviq, yeah I've encountered that before and I look out for it
[23:23] <Saviq> camako, ideally this should be resolved if at all possible
[23:27] <Saviq> camako, that would require splitting papi, though
[23:27] <camako> Saviq, yeah it's a nuisance
[23:27] <Saviq> camako, the circular dep might lead into a difficult situation if in a single landing you'll have papi depending on new mir api and mir on new papi, neither will build without the other
[23:28] <Saviq> oh and there's even one with mesa too bug #1239037
[23:29] <Saviq> I thought I filed one for papi, mir, will do so now
[23:29] <camako> Saviq, yeah I guess we change only one first, build the other then we change the other and build the first.. if that makes sense)
[23:30] <Saviq> camako, sure, that makes sense, but might mean you have to do the changes in stages unnecessarily
[23:30] <camako> Saviq, right can't do in one silo... would have to split the landing
[23:31] <camako> which would be an even bigger PITA than it already is
[23:35] <camako> Saviq, so it'll look like this right? https://code.launchpad.net/~mir-team/qtmir/devel-mir-next/+merge/232329
[23:41] <Saviq> camako, yes, approved
[23:42] <Saviq> camako, btw, looks like the papi/mir loop was resolved in the end, it's only the mesa one that remains
[23:42] <Saviq> camako, i.e. mir does not build-depend on anything produced out of platform-api AFAICT
[23:42] <camako> Saviq, I see
[23:44] <Saviq> camako, btw, in theory it should be possible to pull lp:qtmir into lp:qtmir/devel-mir-next instead of merging (is what we do with the gles-sync branch)
[23:45] <Saviq> well, not any more, because there were merges and such, but maybe we could make it happen again by overwriting devel-mir-next with trunk at the next landing
[23:45] <Saviq> this way trunk and devel-mir-next actually maintain the same history
[23:45] <camako> Saviq, I see what you mean
[23:45] <camako> Saviq, good idea
[23:45]  * Saviq tries to verify
[23:46] <camako> Saviq, this actually occured to me but I was a chicken to try
[23:47] <Saviq> camako, so yeah, as long as there's no commit *more* on devel than on trunk, you can pull
[23:48]  * camako will do it next time
[23:50] <camako> Saviq another nice thing with the empty commit option is now the MPs will be approved by Jenkins (before they always failed because Jenkins didn't know anything abt the new release before it happened)
[23:51] <Saviq> camako, sure, assuming they will actually build ;)
[23:51] <Saviq> camako, and well. sure, jenkins approved, but with old mir, so not really something you wanted
[23:51] <camako> Saviq, yea I'm hungry so who knows what I did
[23:52] <Saviq> camako, so yeah, even now, if you uncommit your last commit to devel-mir-next, you can just pull from trunk, so yeah, just after the next qtmir landing, pull into devel-mir-next and you'll have history nice & clean
[23:52] <camako> Saviq, yeah but at least we won't see a failure
[23:52] <camako> Saviq, yeah.. same thing with USC and papi
[23:52] <Saviq> camako, yup
[23:53] <Saviq> camako, so yeah, until devel-mir-next has actual source changes, jenkins should be happy - if it stops being happy is when you should actually bump the build dependencies appropriately
[23:54] <camako> Saviq, yea.. it's sort of one extra checkpoint
[23:54] <Saviq> camako, yup
[23:56] <Saviq> o/
[23:57]  * Saviq sleepy time
[23:57] <camako> Hey Saviq, really thanks man.. good night
[23:57] <Saviq> camako, right back at you


[10:44] <cpaelzer> ginggs: I'll have a look at https://bugs.launchpad.net/ubuntu/+source/segyio/+bug/1951658 that vorlon left behind on last weeks +1
[10:48] <ginggs> cpaelzer: there is a NMU coming in from debian
[10:48] <ginggs> debian bug 1000360
[10:49] <cpaelzer> already seen it, but it fixes a different problem
[10:49] <cpaelzer> theirs is python 3.10 compat, ours is some cpp magic - and both actually should upgrade to the new version
[10:49] <cpaelzer> the old one is 2.5 years old
[10:50] <ginggs> cpaelzer: the cpp part can be fixed like: https://launchpad.net/~ginggs/+archive/ubuntu/testing/+sourcepub/12858492/+listing-archive-extra
[10:51] <cpaelzer> ah ok, sou you already have that
[10:51] <cpaelzer> then yours on top of the NMU once it arrives
[10:51] <cpaelzer> I'll pick something else then, but will update the LP bug
[10:51] <ginggs> thanks
[10:54] <cpaelzer> ginggs: your fix is straight forward but also kind of brutal :-) Have you filed an issue upstream already?
[10:54] <cpaelzer> If not I could do so to ensure we can drop the delta some day
[10:55] <cpaelzer> 1.9.8 still has the same (bad) line
[11:09] <ginggs> cpaelzer: well the upstream is catch2, and it is fixed there.  we could encourage debian to use the system catch2, which I have filed bug for some packages
[11:09] <cpaelzer> Hmm, I filed it for segyio, but you are right it is an embedded source there
[11:11] <cpaelzer> ginggs: But even upstreams catch2 has the same line it seems
[11:12] <ginggs> i mean it's fixed in catch2's upstream, and in the debian catch2 package
[11:12] <cpaelzer> ack
[11:12] <cpaelzer> https://github.com/catchorg/Catch2/issues/2178
[11:28] <cpaelzer> ginggs: FYI looking at the FTBFS of nbd
[11:29] <ginggs> sack
[11:31] <ginggs> ack, even
[11:31] <cpaelzer> hehe
[11:32] <cpaelzer> ginggs: and parlytype FTBFS @ s390x which seems either flaky or really interesting
[12:02]  * ginggs looks at python-pyspike, then jumps to the bottom of the list; pyemd, aflplusplus
[12:05] <ginggs> fast-histogram
[12:06] <cpaelzer> ok
[12:14] <ginggs> lefse
[12:14] <ginggs> gsl
[14:17]  * ginggs retries all the regressed autopkgtests now that numpy has migrated
[14:22] <dbungert> ginggs: do you want to sync numpy from debian?  I sent debian some py3.10 fixes.  The remaining changes in ubuntu are now incorporated in the debian version of the package.
[14:24] <ginggs> dbungert: morning!  yes, i intend to.  i have been following LP: #1950537
[14:24] <dbungert> awesome, thanks!
[14:34] <Ark74> Hello guys, I'm seeing an issue when building ubiquity https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1951519
[14:34] <Ark74> seems this is not an issue at http://qa.ubuntuwire.com/ftbfs/
[14:35] <Ark74> could this be an issue because of tzdata?
[14:35] <Ark74> or ubiquity source itself?
[14:52] <Velkorq> hey i am banned in #ubuntu for some reason. can someone unban me?
[15:01] <cpaelzer> ginggs: looking at ldc now
[15:17] <oerheks> Velkorq, join #ubuntu-ops for that
[15:43] <cpaelzer> ginggs: I see you have ~10 days ago submitted a bunch of no-change-rebuilds for netcdf but this still has various problems
[15:43] <cpaelzer> ginggs: like FTBFS of libpdl-netcdf-perl ferret-vis vtk6 - since you did the NCR did you look into those builds fails already?
[15:44] <cpaelzer> secondary this also seems to have some autopkgtest fails
[15:54] <ginggs> cpaelzer: sure, i can look at those
[16:27] <xypron> I am looking for a sponsor: opensbi - 0.9+187.52af6e4b52-0ubuntu1 has been packaged in ppa:xypron/opensbi to resolve LP: #1937055
[16:35] <seb128> xnox, could you 'git push origin --delete 1%0.157ubuntu3.1' on ubiquity? I tagged and pushed on the wrong tab, that was meant for apt-setup
[17:23] <xnox> seb128:  done
[17:25] <seb128> xnox, thx
[19:54] <toabctl> bdmurray, hey. could you have a look at https://code.launchpad.net/~gjolly/livecd-rootfs/+git/livecd-rootfs/+merge/412228 please? This is currently blocking the CPC team from building new Jammy images (which also blocks MaaS and others afaik
[19:55] <toabctl> asking you because you sponsored some of the recent livecd-rootfs changes (thanks for that!)
[21:52] <mwhudson> where does the "pending kernel upgrade" message come from?
[21:53] <mwhudson> ah needrestart
[22:03] <jawn-smith> In general, when fixing a bug, is it safe to assume the users have the version of python provided by python3-defaults?
[22:04] <tumbleweed> those are the only supported versions of python
[22:04] <tumbleweed> however, the deadsnakes PPA exists, and users can have those installed
[22:05] <jawn-smith> tumbleweed: thanks! Does that mean it's okay to propose a patch for a focal package that requires python >= 3.5 ?
[22:05] <jawn-smith> (defaults in focal is currently 3.8)
[22:08] <tumbleweed> yes, absolutely
[22:17] <dbungert> Retest click please?  https://autopkgtest.ubuntu.com/request.cgi?release=jammy&arch=amd64&package=numpy&trigger=python3-defaults/3.9.7-4
[22:25] <mwhudson> dbungert: clicked
[22:25] <dbungert> mwhudson: thanks


[04:01] <geofft> hi folks! I'm trying to debug why a "start on ((a and b and c and d and e) or f)" job isn't starting. I made test jobs with "start on a" through "start on e", and they all run.
[04:03] <geofft> what should I be trying? (there isn't a limit on the number of conditions, is there?)
[04:03] <geofft> the job in question doesn't ever get mentioned in verbose output.
[08:13] <xnox> geofft: is the job valid? e.g. status $jobname
[08:14] <xnox> geofft: and to start that job you need to do "initctl emit a; ... b; ... c; ... d; ... e;" or "initctl emit f"
[08:14] <xnox> geofft: if the job is stopped, the full a-e set of events needs to be re-emitted. or f event needs to be emitted.
[08:22] <geofft> xnox: lemme reboot this VM, one sec, but I believe status said stopped/waiting
[08:23] <geofft> and it never started, from boot
[08:25] <xnox> geofft: then all events have not fired.
[08:26] <geofft> then why did my test jobs all run?
[08:26] <xnox> geofft: and/or the events are mistyped or misnamed.
[08:26] <geofft> well, it also seems to work one in several boots...
[08:26] <geofft> is it possible for events to fire too early / in the wrong order?
[08:31] <geofft> I am pretty confident I typed the test jobs the same way they are listed in the actual job
[08:31] <geofft> like, on the dumb questions front, is it known that having five "and"s works? is there some internal limit?
[08:31] <geofft> or can I ask upstart which condition it thinks didn't fire?
[08:38] <geofft> hrrrm, I wonder if it's a misparse given that d is an instanced job, and it all works fine if "and e" isn't around.
[08:39] <xnox> geofft: can you please list actual config?
[08:40] <xnox> geofft: echo start on ((a and b and c and d and e) or f) | sudo tee /etc/init/foo.conf
[08:40] <geofft> sure, I can pastebin or something, one sec
[08:40] <xnox> geofft: for event in a b c d e; do sudo initctl emit --no-wait $event; done
[08:40] <xnox> geofft: sudo status foo
[08:40] <xnox> works.
[08:41] <geofft> xnox: yes, I can get it to work if I manually emit d.
[08:42] <geofft> my local changes are http://paste.debian.net/108646/ , the rest is all from Trusty (which I can pastebin if that's useful)
[08:42] <geofft> the only change the override does is adding "and e" ("and stopped baremetal-earlyauth").
[08:48] <geofft> (and that job is successfully running and then stopping)
[08:49] <xnox> geofft: task & expect stop don't make sense.
[08:50] <xnox> geofft: on boot what's the "status baremetal-earlyauth" ? is that process simply stopped and that's it?
[08:50] <xnox> geofft: also task doesn't make sense and to key on "stopped baremetal-earlyauth"
[08:51] <geofft> hm, sure, but I added task later as part of debugging, and it was broken before that, too.
[08:51] <geofft> I can pull it back out
[08:51] <xnox> geofft: i think you want "task", delete "expect stop" (unless baremetal-earlyauth actually uses SIGSTOP), and in the lightdm.override you want "and started baremetal-earlyauth"
[08:51] <geofft> it does use SIGSTOP for readiness (there's something else that waits for "started baremetal-earlyauth")
[08:51] <xnox> since for tasks, started is emited after all process quit.
[08:52] <xnox> there is no distinction between started & stopped for tasks. Task only emit "started" after all processes quit. That's how "tasks" are different from normal/regular jobs.
[08:53] <xnox> if there is something else, it may be blocking for stopped to be emitted.
[08:53] <xnox> ...
[08:53] <geofft> hm, that doesn't match my reading of  http://upstart.ubuntu.com/cookbook/#task ? am I misreading it?
[08:54] <geofft> baremetal-earlyauth is a short-running program that (possibly) prompts you for a password at plymouth
[08:54] <geofft> and I care both about readiness, since other things communicate with it, and exit, since I don't want to start lightdm until it's done.
[08:55] <geofft> (looking again, I take that back, there isn't something that waits for "started baremetal-earlyauth", but probably I don't want task, anyway.)
[08:59] <geofft> taking out "task", same behavior, and `status baremetal-earlyauth` is stop/waiting.
[10:00] <geofft> xnox: am I misreading the upstart cookbook docs about when tasks emit started and stopped?
[21:08] <paintedbicycle> Having trouble with upstart on ubuntu with nodejs. I start the app with user called 'deploy', but app doesn't have permission to write to disk even though all files are owned by deploy. When I log into ubuntu as deploy and start app, app can write fine. Tried using setuid, asked on serverfault, still no luck.
[21:21] <paintedbicycle> To follow up, at first when running "sudo -u 'usernane' ..." the sudo process wouldn't go away, so I got an answer here (http://serverfault.com/questions/608240/upstart-why-two-processes-when-running-as-a-different-user/609194) to allow the sudo process to go away and just leave me with my app running as the 'deploy' user I want. Verified that with 'ps aux'. However, when I use the app, the permissions are definitely not
[21:21] <paintedbicycle>  'deploy' as it can't do anything. None of the tutorial that use setuid, etc seem to be any different from one another and are mostly out of date


[00:44] <magicaltrout> what the hell
[00:45] <magicaltrout> why is juju deploy trying to open a browser
[00:45] <magicaltrout> on a server which runs headless
[00:49] <magicaltrout> balls
[00:49] <magicaltrout> now i  juju logout
[00:49] <magicaltrout> and can't juju login
[00:53] <magicaltrout> okay logged back in
[00:53] <magicaltrout> still getting a browser prompt
[01:24] <lazypower> magicaltrout: that should give you the url you need to copy/paste if its in headless mode
[07:08] <magicaltrout> lazypower: yes it did after a delay
[07:08] <magicaltrout> but then when i run that url on a server that isn't my remote one, what difference does it make?
[07:08] <magicaltrout> or do I curl it?
[07:09] <magicaltrout> in the end i logged in with lynx
[09:42] <lazypower> magicaltrout: should be token based. its polling/waiting on a socket to get that auth code back. Pasting that into your workstation browser should have gotten you through.
[09:42] <lazypower> if its not, we need to tag and bag that bug
[10:15] <rock> Hi. Can't we install juju2.0 on ubuntu 14.04.1(trusty)?
[10:17] <rock> If we can, could anyone please provide me a reference link for that.
[10:32] <rock> Actually, I want to do [MAAS+OpenStack base bundle] setup on physical servers. I have taken 5 servers. On one server I configured MAAS 1.9.4 on trusty(14.04). From MAAS UI , I commissioned all remaining four nodes successfully.
[10:33] <rock> Now I want to deploy OpenStack base bundle. What exactly I need to do.
[10:35] <rock> I integrated our cinder-storage driver charm with Openstack bundle. And I pushed this bundle to jujustore as our own bundle. So now I want to deploy our bundle on MAAS nodes. What I need to do exactly here. Please provide me the clear information.
[12:18] <junaidali> Hi everyone, I'm having an issue with juju 2.0 on xenial. The lxds are getting IPs from lxdbr0 bridge rather than the Openstack management network. Any idea what might be the cause?
[12:18] <junaidali> I'm using maas 2.1.0alpha3 and juju 2.0-beta18
[12:18] <beisner> hi junaidali, is this when deploying on top of openstack using juju?
[12:18] <junaidali> yes
[12:20] <junaidali> in /var/log/lxd/<lxd-name>/lxc.conf, lxc.network.link = lxdbr0
[12:20] <junaidali> can this might be the issue?
[12:21] <beisner> junaidali, it is a known issue.  https://bugs.launchpad.net/juju/+bug/1615917  we do a lot of juju deploys on top of openstack, and have great success in just placing all units in their own nova instance.
[12:21] <mup> Bug #1615917: juju openstack provider --to lxd results in unit behind NAT (unreachable) <openstack-provider> <uosci> <juju:Triaged> <https://launchpad.net/bugs/1615917>
[12:28] <junaidali> beisner, when you say deploying on top of openstack, do you mean deploying openstack over openstack?
[12:30] <beisner> junaidali, are you deploying to maas with juju and getting that network issue?  or do you have an openstack deployed, where you are deploying some other thing on top of that with juju?
[12:30] <junaidali> i'm deploying to maas with juju
[12:30] <junaidali> Actually this is happening in a fresh  deployment
[12:30] <junaidali> sorry for the confusion
[12:30] <beisner> ok, so i'm confused
[12:31] <beisner> the openstack networking won't be in play at that point
[12:31] <rick_h_> junaidali: if MAAS is setup to provide dhcp the lxd containers should come up with IP addresses on the network and be reachable across the hosts.
[12:31] <junaidali> machines are getting correct IP, its just the lxds that've the issue
[12:33] <junaidali> yes, but in my case, it is not getting IP from maas.
[12:34] <junaidali> I was previously using an RC release of maas. The error came up when I upgraded to maas 2.1.0 alpha3
[12:35] <junaidali> I deleted the maas and recreated the whole environment but it didn't help
[12:36] <junaidali> lxc.conf for an lxd (/var/log/lxd/<lxd-name>/lxc.conf) http://paste.ubuntu.com/23202676/
[12:37] <rick_h_> junaidali: maybe check out https://bugs.launchpad.net/juju/+bug/1566791 where not all interfaces get bridged ootb
[12:37] <mup> Bug #1566791: VLANs on an unconfigured parent device error with "cannot set link-layer device addresses of machine "0": invalid address <2.0> <4010> <cpec> <network> <juju:In Progress by dimitern> <https://launchpad.net/bugs/1566791>
[12:37] <rick_h_> junaidali: a fix for that is on the way, but not 100% sure it's what you're hitting
[12:38] <coreycb> junaidali, I'm hitting similar issues but not sure it's the same as yours.  here's something you can fix possibly: https://lists.ubuntu.com/archives/juju/2016-September/007801.html
[12:39] <coreycb> junaidali, also when creating your model try this: juju add-model --config enable-os-upgrade=false --config enable-os-refresh-update=false <model-name>
[12:40] <junaidali> thanks coreycb, let me try your suggestion
[12:41] <coreycb> junaidali, hopefully it helps. I've not gotten around my issue yet so I'll keep you posted on any results.
[12:42] <marcoceppi> coreycb junaidali you can also make that the default in beta18 `juju model-defaults`
[12:43] <coreycb> junaidali, fyi I think rc1 comes out tomorrow for juju and from what I understand the above bugs are fixed in it
[12:43] <coreycb> junaidali, actually the model issue may be an images or cloud-init bug, not sure
[15:05] <junaidali> I tried the suggestions, still hitting the same issue.  I hope this is fixed in rc1 now
[15:52] <kjackal> cory_fu kwmonroe: I will be doing the kafka ingestion bundle again with bigtop charms this time. Where should this bunlde live? I think it should be outside the bigtop source tree since it will have apache-flume in it. What do you thing?
[15:52] <kjackal> *think
[15:54] <kwmonroe> kjackal: i think it should live in bigtop-deploy, because i expect it to be updated to use bigtop-flume once we get that charmed
[15:54] <kwmonroe> i don't think there will be too much concern if we have a non bigtop charm in a bigtop bundle, as long as the expectation is that all charms will eventually be bigtopped
[15:55] <kjackal> kwmonroe: I see your point, so we put it inside bigtop and as soon as we get flume ready we create a PR
[15:55] <kjackal> sounds good
[15:57] <cory_fu> kjackal: In particular, I would include a comment in the bundle yaml next to the apache-flume charm URLs saying that they will be swapped out for the Bigtop versions ASAP
[17:02] <lazypower> http://imgur.com/a/xrOmO -- not sure if juju is telling prophecies or coincidence
[17:08] <cory_fu> @kwmonroe @kjackal How do you feel about changing our repo naming convention to follow the charm-, layer-, interface- prefix convention (where we currently use layer- for both charm layers and base layers)?
[17:09] <kjackal> cory_fu: isn't there a case were we might build a new charm over what we consider chamr layer now?
[17:10] <kjackal> cory_fu: for example could someone at any point use the client layer to put something ontop?
[17:11] <cory_fu> kjackal: Yes, there is a possibility that a charm (layered or non-layered) could serve as a base layer, but it is less common and I think it's still useful to indicate that the "base" is a charm in its own right
[17:11] <cory_fu> i.e., layer- would be reserved for things that could never function as a charm on their own
[17:14] <cory_fu> Hrm.  I thought there were more repos in juju-solutions that followed that convention, but I only actually see one.
[17:15] <cory_fu> marcoceppi: Was I correct in recalling that we wanted to encourage that convention?  ^
[17:15] <marcoceppi> cory_fu: we never really have enforced /that/
[17:15] <marcoceppi> cory_fu: I've been doing layer-* reuse and charm-* as either a top layer or built charm
[17:16] <cory_fu> marcoceppi: I was suggesting charm-* as top layer.
[17:16] <marcoceppi> we also have some layers in the index that are actually charm layers and probably shouldn't be
[17:16] <marcoceppi> cory_fu: right, but I also use it for classic charms that have not been layered
[17:16] <cory_fu> Indeed.  IOW, anything that can be deployed (possibly after running through `charm build`)
[17:17] <marcoceppi> cory_fu: this whole "options not defined" bug is killing me
[17:17] <smgoller> Hey all, I'm trying to deploy openstack on maas 2 with juju 2 beta 18 using ubuntu 16.04 everywhere. Everything comes up, but I can't get networking to work. The bundle configuration references eth1 as presumably the physical interface connected to the provider network, which is eno2 in xenial-land. I can't seem to figure out what's going on. any of gnuoy, thedac, or tinwood awake?
[17:17] <marcoceppi> yes
[17:17] <cory_fu> marcoceppi: Really?  I thought we sorted that out?
[17:17] <marcoceppi> cory_fu: we just found where it happens, never patched it
[17:17] <marcoceppi> smgoller: I hit that earlier today, but someone else fixed it and I'm not sure how
[17:18] <thedac> smgoller: I'll get back to you in just a minute when my meeting is done. OK?
[17:18] <lazypower> cory_fu: marcoceppi - +1 to options undefiend bug
[17:18] <smgoller> thedac: awesome! thanks
[17:18] <lazypower> workaround works for now, but its not obvious
[17:18] <lazypower> *undefined
[17:18] <cory_fu> marcoceppi, lazypower: Somebody should fix that.  >_>
[17:18] <smgoller> afk for a sec to run to the toilet
[17:19] <lazypower> cory_fu: you fix it in the repo, i'll fix it in charmbox :D
[17:21] <smgoller> back
[17:24] <kjackal> cory_fu: kwmonroe: am going to push to bigdata-dev a build of the plugin in trusty with openjdk optional. The reason is that we endup with this deployment http://pastebin.ubuntu.com/23203686/ where the plugin must be in trusty to relate to flume and it also needs openjdk
[17:25] <cory_fu> kjackal: I think the plugin might require some additional work, since it currently expects java to be proxied through the principal
[17:25] <kwmonroe> hold up kjackal
[17:26] <kjackal> cory_fu: kwmonroe: didn't we make openjdk optional in the base layer?
[17:26] <kjackal> then I might need to use the apache plugin
[17:26] <cory_fu> We did, but the plugin was previously a special case (because we had a misunderstanding about how relations between two subordinates work)
[17:27] <cory_fu> kjackal, kwmonroe: Apparently, we can't have a bundle and a charm with the same name.  What should we call the insightedge bundle?  insightedge-core?
[17:29] <marcoceppi> cory_fu: I tried, and failed, the logic is too complex for me
[17:29] <thedac> smgoller: Hi, so Xenial has slightly more unpredictable interface names based on the device type. There are a handful of configuration knobs you can set in the charms to work this. Let me get you a list. One sec
[17:29] <kwmonroe> kjackal: can you try this one? http://jujucharms.com/u/bigdata-dev/bigtop-plugin-trusty
[17:30] <kjackal> thanks kwmonroe.
[17:30] <kwmonroe> kjackal: cory_fu: ^^ that's a bigtop plugin, specifically built for trusty.. it pulls in puppet from puppetlabs since the trusty archive won't have a new enough puppet.
[17:30] <smgoller> thedac: yeah, maas tries to keep it a little more consitent, but xenial instances i've brought up on esxi have names like ens160, ens192...
[17:31] <kjackal> cory_fu: how about insightedge-bunlde or sulution? the core sounds like "limited functionality, only for internal use"
[17:32] <cory_fu> kjackal: I wish we could rename the charm and just call the bundle "insightedge" but that's impossible (within the bigdata-dev namespace) now
[17:32] <kwmonroe> kjackal: cory_fu, bigtop-plugin-trusty should *not* need openjdk.  that's the charm i was using during the summit specifically because some of our big data charms weren't xenial... i'm like 92% sure it worked without java.
[17:33] <kjackal> ah that is my doing (I think) we cannot rename a charm :(
[17:33] <cory_fu> kjackal: Also, I was thinking "insightedge-core" like "kubernetes-core" since we will want to build on the bundle to include things other than just Spark
[17:34] <cory_fu> kwmonroe: We can't mix Bigtop and vanilla plugins, can we?
[17:34] <thedac> smgoller: In neutron-gateway set the ext-port:
[17:34] <thedac> https://github.com/openstack/charm-neutron-gateway/blob/master/config.yaml#L85
[17:34] <thedac> If you are running HA set vip_iface and ha-bind interface
[17:34] <thedac> https://github.com/openstack/charm-keystone/blob/master/config.yaml#L186
[17:34] <kwmonroe> cory_fu: i didn't try
[17:34] <thedac> https://github.com/openstack/charm-keystone/blob/master/config.yaml#L198
[17:34] <thedac> And the corosync_bindifcace for hacluster
[17:34] <cory_fu> I'm sure we can't
[17:34] <thedac> https://github.com/openstack/charm-hacluster/blob/master/config.yaml#L30
[17:35] <cory_fu> kwmonroe: I was somehow under the impression that kjackal was dealing with vanilla Hadoop
[17:35] <smgoller> thedac: we're not doing HA, this is just a basic install to get things rolling
[17:35] <cory_fu> I think I read something backwards, though
[17:35] <cory_fu> kwmonroe: Thoughts on the insightedge bundle name?
[17:35] <thedac> smgoller: ok, then it should just be the neutron-gateway ext-port.
[17:36] <smgoller> ok, so i've tried a bunch of different bundles, and the last bundle i tried was your stable one on github.
[17:36] <smgoller> I've done the ext-port change and that one didn't seem to make a difference.
[17:36] <thedac> smgoller: oh, ok, then I need more info on *how* things are breaking
[17:37] <kwmonroe> cory_fu: what's in the bundle?  spark + insightedge?
[17:37] <smgoller> thedac: heh, that's a good question. I'm trying to figure that out myself.
[17:37] <cory_fu> kwmonroe: And Zeppelin
[17:37] <cory_fu> kwmonroe: Basically, it recreates what the InsightEdge release provides.
[17:37] <smgoller> but first, this is the one i've been using most recently. https://github.com/openstack-charmers/openstack-bundles/tree/master/stable/openstack-base
[17:38] <cory_fu> (But in a more modular way)
[17:38] <thedac> smgoller: and you are changing ext-port for the gateway charm? That is needed.
[17:38] <kwmonroe> cory_fu: i think i agree with kjackal.. -core kinda implies just the minimum.  i wouldn't expect zepp in a core bundle.  unless that's the only interface into insightedge
[17:39] <smgoller> http://pastebin.com/peLb4Zme
[17:39] <smgoller> do I need to set ext-port as well?
[17:39] <smgoller> because the docs say that was deprecated in favor of the options in this one
[17:40] <smgoller> which is why I switched to this bundle over the one on jujucharms.com
[17:40] <thedac> ah, let me validate that for you. One sec
[17:44] <smgoller> Yeah, that data-port line is the only thing I changed from github, from eth1 to eno2
[17:52] <thedac> smgoller: sorry, I had to read the docs myself. I am trying to figure out if data-port is *only* used in a flat-network setup. I'd like to run a quick test on my end.
[17:53] <smgoller> ok
[17:53] <thedac> smgoller: in the meantime, can you say one way or the other that only external networking is failing?
[17:53] <smgoller> well, I can't ping the openstack router provider interface.
[17:54] <thedac> ok
[17:54] <thedac> smgoller: `ip netns exec qrouter-$ID ping $INSTANCE_IP`
[17:54] <thedac> try that ^^. That will tell us if the internal ovs is working
[17:55] <smgoller> on the compute node?
[17:55] <thedac> on the gateway node
[17:55] <smgoller> got it
[17:56] <smgoller> nope
[17:56] <smgoller> no pings
[17:57] <thedac> ok
[17:57] <thedac> smgoller: let me run this test then and get back to you in just a bit
[17:57] <smgoller> ok
[17:57] <smgoller> thanks!
[18:29] <kwmonroe> cory_fu: back to your naming convention, we would then have 'layer-bigtop-base' and 'charm-hadoop-namenode'?
[18:29] <cory_fu> kwmonroe: charm-hadoop-namenode because it is deployed (after being built)
[18:30] <cory_fu> kwmonroe: It's unclear whether we would have charm-hadoop-datanode or layer-hadoop-datanode, since we use it as a base layer and don't publish it in the store, but it could conceivably be built and deployed directly
[18:31] <cory_fu> kwmonroe: Actually, to be pedantic, we wouldn't have either charm-hadoop-namenode nor layer-hadoop-namenode because that lives in the Bigtop repo.  ;)
[18:33] <cory_fu> kwmonroe, kjackal: I went ahead and used the charm- prefix for https://github.com/juju-solutions/charm-insightedge-core since I was renaming it anyway
[18:33] <kwmonroe> very well
[18:33] <kwmonroe> i'll let you decide how much confusion you've just injected to the datanode/nodemgr naming.
[18:34] <cory_fu> :)
[18:34] <cory_fu> I don't plan on changing them
[18:34] <cory_fu> And anyway, I was just considering this for future repos
[18:35] <cory_fu> Though all of our charm repos should live upstream anyway, so it shouldn't really make any difference
[18:37] <thedac> smgoller: ok, so our test setup does use data-port however, it sets it to the MAC address rather than the interface name ie: br-ex:fa:16:3e:ec:79:d5 Can you test setting the MAC address of the "external" interface? And we can go from there
[18:40] <smgoller> ok, how would I do that?
[18:40] <smgoller> oh
[18:40] <smgoller> i see
[18:41] <smgoller> the config line explicitly sets a mac address? or do I need it to match to something else
[18:41] <thedac> With MAAS you can tag a host as the gateway. Then use constraints: tags=$GATEWAY_TAG. Then find the MAC address of the interface and in the bundle have data-port: br-ext:$MAC
[18:42] <smgoller> ok, but since i've already got something deployed i should just ssh in and grab the mac and redeploy?
[18:42] <smgoller> or do i need to tear this down and deploy from scratch?
[18:43] <thedac> smgoller: you could test with the current deploy as a first step
[18:43] <smgoller> i guess i can just set config on gateway-api?
[18:43] <thedac> Grab the mac and juju set neutron-gateway data-port="br-ext:$MAC"
[18:44] <smgoller> ok, that's done.
[18:45] <smgoller> do I need to do anything to the charm to get it to reconfigure?
[18:45] <thedac> Let that settle a moment and see if you can ping the neutron router
[18:46] <smgoller> still no go. you mean the mac address of eno2, the physical interface connected to the external physical network, yes?
[18:46] <smgoller> just to be clear.
[18:46] <thedac> yes, correct
[18:47] <smgoller> should i reboot the machine?
[18:47] <thedac> ok, can I see `ovs-vsctl show` from the gateway and one of the compute nodes?
[18:47] <thedac> I don't think that will help
[18:48] <smgoller> /paste.ubuntu.com/23203969/
[18:48] <smgoller> http://paste.ubuntu.com/23203969/
[18:48] <smgoller> that's the gateway
[18:48] <coreycb> junaidali, fyi I just tested with a pre-release of juju rc1 and it fixed the lxd bridge issues I was hitting
[18:48] <thedac> ok, looking
[18:49] <smgoller> http://paste.ubuntu.com/23203974/
[18:49] <smgoller> compute node
[18:53] <thedac> smgoller: simple test. From <IP_ADDRESS> can you ping <IP_ADDRESS>? Just making sure the tunnels should be expected to work.
[18:54] <smgoller> yes
[18:54] <thedac> thanks
[18:59] <thedac> smgoller: so I am not finding a smoking gun the ovs output looks good.
[19:00] <smgoller> ok.
[19:00] <thedac> here is a doc I often follow from ODS for troubleshooting neutron http://www.slideshare.net/SohailArham/troubleshoot-cloud-networking-like-a-pro
[19:00] <thedac> I think the next step would be a re-deploy and if that still does not work follow this doc until we have a smoking gun
[19:01] <smgoller> Sounds good. Thank you so much for your help! I'll report back once it's redeployed.
[19:01] <thedac> smgoller: great. And do set the data-port with the MAC in the bundle
[19:01] <smgoller> thedac: yup, i just set that.
[19:01] <thedac> cool, I'll hear from you soon
[19:04] <kjackal> cory_fu: kwmonroe: After some debugging... Seems we are hitting a permission problem on HDFS "Permission denied: user=root, access=WRITE, inode="/user/flume/...."
[19:05] <kjackal> cory_fu: kwmonroe: I do not see any way of onfiguring the output directory of flume-hdfs https://jujucharms.com/u/bigdata-dev/apache-flume-hdfs/trusty/34
[19:06] <kjackal> Is it acceptable to ask the user to change the permissions of that dir or should we use the apache-hadoop?
[19:06] <cory_fu> kjackal: I remember when kwmonroe originally hit that permissions issue and it was sorted out, I thought in the flume charm.
[19:06] <cory_fu> kjackal: That's not an on-disk path, that's an HDFS path.  The Flume charm should be creating and managing that directory inside HDFS
[19:07] <kwmonroe> kjackal: do an 'hdfs dfs -ls -R /user' and see if the /user/flume dir is there
[19:07] <cory_fu> kjackal: https://github.com/juju-solutions/layer-apache-flume-base/blob/master/lib/charms/layer/apache_flume_base.py#L122
[19:08] <kjackal> cory_fu: true. but bigtop hdfs pre-creates all directories with permissions we do not like for this usecase
[19:08] <kjackal> kwmonroe: yes, /user/flume is there and is owned by flume in the hadoop group
[19:09] <kwmonroe> cool kjackal, now you need to find out why 'root' is trying to write there.. writes from flume-hdfs should be coming from the 'flume' user
[19:10] <kjackal> I see!
[19:10] <kjackal> Back to debugging :)
[19:10] <kwmonroe> fwiw kjackal, the flume source will be setting the output dir based on the 'event_dir'.  so apache-flume-syslog defaults that to 'flume-syslog', which would appear in hdfs as '/user/flume/flume-syslog'
[19:11] <kjackal> kwmonroe: yeap
[19:26] <junaidali> thanks coreycb
[20:37] <smgoller> so i have a maas machine that failed deployment according to maas. Can I recover from this from juju's standpoint or do I need to destroy the model and start over?
[20:37] <smgoller> juju doesn't think the machine is in an error state but maas is pissed
[20:47] <rick_h_> smgoller: so if it's a deployment you can destroy the application and redeploy?
[20:47] <rick_h_> smgoller: need more info on what happened I guess.
[20:47] <rick_h_> smgoller: does juju status --format=yaml show more details on the machine?
[20:47] <smgoller> so I did a deployment of a bundle, which required 4 machines
[20:47] <smgoller> i blew the model away and redeployed.
[20:48] <smgoller> but for the record, one of the machines failed to deploy according to maas
[20:48] <rick_h_> smgoller: k, if it happens again let us know and we can try to help see what's up.
[20:49] <smgoller> and juju status showed that machine as "error" state. but I'm sorry I was too impatient. :) If it happens again i'll leave it :)
[21:17] <kjackal> kwmonroe: cory_fu: need some help with bundles and the store
[21:17] <cory_fu> kjackal: Sure, what's up?
[21:17] <kjackal> there is no charm build step for bundles, right?
[21:17] <kjackal> cory_fu: charm show cs:~bigdata-dev/bundle/kafka-ingestion-0
[21:18] <kjackal> cory_fu: I pushed the bundle but I am not sure where did it go in the store
[21:18] <kjackal> cory_fu: I do not see it here: https://jujucharms.com/q/bigdata-dev?type=bundle
[21:19] <kjackal> I must be mising some thing, eg a metadata.yaml
[21:19] <cory_fu> kjackal: 1) Did you do `charm release cs:~bigdata-dev/bundle/kafka-ingestion-0`?  2) Did you do `charm grant cs:~bigdata-dev/bundle/kafka-ingestion everyone`?
[21:20] <cory_fu> kjackal: (Hint, you forgot to grant)
[21:20] <cory_fu> https://jujucharms.com/u/bigdata-dev/kafka-ingestion/0
[21:20] <kjackal> http://pastebin.ubuntu.com/23204426/
[21:22] <cory_fu> kjackal: Odd.  http://pastebin.ubuntu.com/23204431/
[21:22] <kjackal> So cory_fu, is this a permissions issue?
[21:23] <kjackal> Is the series = bundle correct?
[21:23] <cory_fu> kjackal: Oh, I think what happened is that you granted before you released, and the stable channel didn't exist yet, so the grant ended up being a no-op
[21:23] <cory_fu> kjackal: Try granting again
[21:23] <kjackal> ok
[21:23] <cory_fu> kjackal: Yes, the commands look fine to me
[21:24] <kjackal> https://jujucharms.com/u/bigdata-dev/kafka-ingestion
[21:24] <kjackal> Awesome, thanks!
[21:54] <smgoller> thedac: ok, I've got it redeployed. I've created the external network according to the docs again. I've also got a manually deployed host as well.
[21:55] <smgoller> thedac: at this point, the manual host can ping the router. however, pinging via ip nets exec on the qrouter fails to ping the router.
[21:55] <smgoller> the manual host is mainly just to validate layer1 connectivity
[21:56] <thedac> smgoller: hmm, ok.
[21:56] <thedac> I guess I need you to unpack "manually deployed host".
[21:56] <thedac> Is that a booted instance on the cloud or something else
[21:56] <smgoller> a host manually deployed with maas with ubuntu on it
[21:56] <smgoller> outside openstack
[21:57] <thedac> but outside the softare defined network .. ok
[21:57] <smgoller> basically something else connected to the provider network that's not the router
[21:57] <smgoller> i have not created a internal network
[21:58] <thedac> Being able to ping the router at all is a good sign. I would finish the config and boot an instance and we can debug from there
[21:58] <smgoller> this is what i used to create the external network "./neutron-ext-net -g <IP_ADDRESS> -c <IP_ADDRESS>/24 -f <IP_ADDRESS>:<IP_ADDRESS> ext_net"
[21:59] <thedac> smgoller: remember there are probably secgroups aslo at play. You might consider making the default secgroup wide open for early testing.
[22:00] <smgoller> the default secgroup seems to be wide open by default
[22:02] <smgoller> downloading an ubuntu image so i can launch an instance.
[22:03] <smgoller> thedac: do you want me to go ahead and create an internal network and launch an instance? Or should we continue trying to debug the external part of this?
[22:04] <thedac> I would go ahead and create the internal network and boot an instance.
[22:05] <thedac> Having said that when you say the manual host can ping the router. Do you mean <IP_ADDRESS> or <IP_ADDRESS> (the likey SDN router IP)
[22:05] <stokachu> cory_fu: https://github.com/battlemidget/charm-layer-ghost/pull/5
[22:05] <stokachu> when you get a chance
[22:08] <smgoller> <IP_ADDRESS>
[22:09] <smgoller> thedac: the upstream router, not the router in openstack. my apologies.
[22:09] <thedac> smgoller: which is an external device corect? ... ok, I was confused
[22:09] <cory_fu> stokachu: LGTM, but I didn't test it
[22:09] <smgoller> yes
[22:09] <stokachu> cory_fu: thanks, im testing it now
[22:09] <thedac> smgoller: what does neutron router-list show as the IP of the SDN router?
[22:10] <smgoller> <IP_ADDRESS>
[22:10] <stokachu> cory_fu: im noticing 5 minute waits between the APT layer running ensure_package_status
[22:10] <stokachu> not sure what that's about
[22:10] <thedac> smgoller: ok, and can you ping that?
[22:10] <thedac> either from the manual host or inside the netns?
[22:10] <smgoller> sudo ip netns exec qrouter-c2a5b6f2-8006-4a78-ad07-c82f8c1fd7ef ping <IP_ADDRESS>
[22:10] <smgoller> succeeds.
[22:10] <stokachu> you can see that here: http://paste.ubuntu.com/23204650/
[22:10] <smgoller> thedac: fails from the manual host
[22:11] <thedac> and what is the IP of the manual host?
[22:11] <cory_fu> stokachu: Strange.  Sounds like maybe it's queueing it but not acting on it during that hook, so it gets processed during the next hook (presumably update-status, after 5 min)
[22:11] <smgoller> <IP_ADDRESS>
[22:11] <thedac> smgoller: ok, on the neutron-gateway host are eth0 and eth1 in the same VLAN?
[22:12] <thedac> smgoller: they would have to be for that to work
[22:12] <stokachu> cory_fu: im not sure what package it's queueing as everything was installed on line 973
[22:12] <stokachu> stub: ^ any idea on that?
[22:12] <smgoller> thedac: you mean the physical interfaces on the machine running neutron-gateway?
[22:12] <thedac> yes
[22:13] <cory_fu> stokachu: Where do you see the 5 minute gap?
[22:13] <smgoller> the physical interfaces are both untagged, but they are on separate vlans on the physical switch they're connected to
[22:13] <stokachu> cory_fu: line 1118 and line 1119
[22:14] <thedac> smgoller: Because <IP_ADDRESS> and <IP_ADDRESS> are both in the <IP_ADDRESS>/24 network they need to be in the same broadcast domain. Or you need a different set of network address space for the ext interface
[22:14] <thedac> make sense?
[22:15] <cory_fu> stokachu: It's not actually installing anything there.  That's just update-status running after 5 min of doing nothing.  The apt layer always logs that it's initializing at the start of every hook, even if there's nothing for it to do
[22:15] <smgoller> thedac: I'm misinterpreting something. the manual host's ethernet and the "external" interface (eno2) on the machine running neutron-gateway are in the same vlan
[22:15] <cory_fu> stokachu: Probably worth filing a bug for stub to remove that log message, as it doesn't seem useful
[22:15] <stokachu> cory_fu: hmm, ghost is sitting at installing NPM dependencies
[22:16] <smgoller> thedac: my initial answer was for the two physical interfaces on the machine running neutron-gateway
[22:16] <thedac> smgoller: ooh, ok, so it has a second ethernet interace in the same vlan as the neutron-gateway's external interface?
[22:16] <cory_fu> stokachu: Guessing that there's a handler order dependency in how you update your status
[22:16] <smgoller> it being the manual host? yes.
[22:16] <thedac> yes, ok
[22:16] <cory_fu> stokachu: Give me a few and I'll take a closer look.  It's probably actually ready
[22:16] <stokachu> cory_fu: ok
[22:17] <thedac> smgoller: so we expect that ping to work. But to humor me. Will you set the default secgroup wide open with: http://pastebin.ubuntu.com/23204687/
[22:17] <smgoller> thedac: on it
[22:17] <thedac> in particular the icmp bit
[22:18] <smgoller> thedac: still no go
[22:19] <thedac> ok, ... /me thinks for a bit
[22:20] <cory_fu> marcoceppi: Is this the issue you were hitting with resources not downloading?  http://pastebin.ubuntu.com/23204673/
[22:20] <cory_fu> If so, will it eventually recover?
[22:20] <marcoceppi> cory_fu: I didn't hit it, lazypower and mbruzek did
[22:21] <marcoceppi> cory_fu: and no, there was no recover from what I remember
[22:21] <cory_fu> Ok, then mbruzek, how would handle that?
[22:22] <cory_fu> i.e., do I have to redeploy the app, start a new model, or tear down the entire controller?
[22:22] <mbruzek> cory_fu:  is that with juju 2.0 ?
[22:22] <cory_fu> Yes
[22:23] <mbruzek> Did you juju attach the resource
[22:24] <cory_fu> mbruzek: Yes, it's in the store.  This worked several times before this one choked
[22:24] <cory_fu> Oh, wiat
[22:24] <cory_fu> I deployed from local this time
[22:24] <cory_fu> ha!
[22:24] <cory_fu> Thanks, mbruzek
[22:25] <mbruzek> we have code that checks the size of a resource
[22:25] <mbruzek> and I do resource-get in a try catch
[22:25] <cory_fu> mbruzek: Does it sometimes return an empty file?
[22:25] <mbruzek> try/except
[22:25] <mbruzek> We did this so we can specify zero byte resources
[22:28] <thedac> smgoller: ok, looking at the neutron-ext-net script it defaults to network-type GRE. For your external network you actually want --network-type flat. So, I would remove the router and networks and re-run neutron-ext-net with --network-type flat
[22:28] <smgoller> aha
[22:29] <thedac> smgoller: you can prove this to yourself with neutron net-show ext-net
[22:29] <thedac> look at  provider:network_type
[22:30] <smgoller> the version of the script i have doesn't have support that argument
[22:31] <thedac> just to clear up. Are you using the openstack-charm-testing repo to get that script?
[22:31] <smgoller> no, but I can grab it.
[22:32] <smgoller> is that on launchpad or github?
[22:32] <thedac> interesting, so before I send you there. What does neutron net-show ext-net show for provider:network_type
[22:33] <thedac> lp:~ost-maintainers/openstack-charm-testing/trunk/
[22:33] <thedac> That has our version of the script in bin
[22:33] <smgoller> | provider:network_type     | gre                                  |
[22:34] <thedac> ok, so that is still a problem.
[22:34] <thedac> Let me track down the neutron commands directly so we are not depending on a script. One sec
[22:35] <stokachu> cory_fu: yea something is causing dpkg to go into a unconfigured state
[22:35] <smgoller> thedac: to be clear, that was the old one. I'm checking out that one from launchpad now
[22:35] <thedac> ok
[22:37] <cory_fu> marcoceppi, tvansteenburgh: To get the new version of jujuclient on Xenial, do you recommend `pip install --upgrade` over the one provided by python-jujuclient, or is there a ppa I should use instead?
[22:38] <smgoller> thedac: that was it. I can now ping from the netns to the provider router
[22:38] <thedac> ok, great. I think that should get you unblocked
[22:38] <smgoller> and i can ping the manual host as well
[22:39] <smgoller> thank you so much. So should I be basing my work of the bundle there as well?
[22:39] <stokachu> huh, charm build layer-nginx puts the built dir in ~/charms/trusty, where building my ghost charm places it in ~/charms/build/ghost
[22:39] <thedac> smgoller: no, I the one you are working with is the state of the art
[22:39] <thedac> s/I//
[22:39] <smgoller> thedac: roger that.
[22:39] <marcoceppi> cory_fu: think about what you just said.
[22:40] <smgoller> but the internal network as gre should be fine, yes?
[22:40] <thedac> that is correct
[22:40] <smgoller> awesome.
[22:40] <cory_fu> marcoceppi: pip install, got it.  ;)
[22:40] <cory_fu> marcoceppi: What is the ppa, then?
[22:41] <marcoceppi> https://launchpad.net/~tvansteenburgh/+archive/ubuntu/ppa
[22:41] <smgoller> thedac: you rock sir, thank you so much for your time.
[22:41] <thedac> smgoller: in that repo you can look at profiles/default for the commands run and use that as a crib sheet
[22:41] <thedac> no problem
[22:41] <smgoller> thedac: will do
[22:41] <cory_fu> marcoceppi: Thank you!
[22:42] <cory_fu> marcoceppi: Just for that, I'll go ahead and fix dhx for 2.0
[22:42] <marcoceppi> cory_fu: what about charm build ;)
[22:42] <cory_fu> marcoceppi: meh
[22:43] <cory_fu> marcoceppi: I probably won't get dhx fixed tonight either, actually.
[22:49] <bdx_> hows it going all?
[22:49] <bdx_> can someone point me at an example of how to bootstrap to rackspace pls?
[22:50] <stokachu> cory_fu: im thinking it's something with the apt layer, i can't get my nginx layer to deploy either
[22:52] <cargill> hi, is there an example how to use charmhelpers.core.services.helpers.TemplateCallback or an equivalent?
[22:52] <bdx_> stokachu: one thing that got me hung up with layer apt when included by a bottom layer, is that the configs specified in config.yaml for the bottom layer werent making into the built artifact
[22:53] <stokachu> hmm
[22:54] <bdx_> stokachu: I had to add them to the top layer to get them to persist through to the built charm
[22:55] <stokachu> ugh
[22:55]  * stokachu sad
[22:55] <bdx_> was that it?
[22:55] <stokachu> bdx_: no lol
[22:56] <stokachu> it pulls the package from my layer.yaml but then sits in this loop checking package_ensure_status
[22:56] <stokachu> nothing ever finishes after the apt layer does its thing
[22:58] <bdx_> stokachu: I modeled layer-nginx-passenger after your nginx layer, it uses layer-apt -> https://github.com/jamesbeedy/layer-nginx-passenger
[22:58] <bdx_> stokachu: are you using it differently then I?
[22:58] <stokachu> bdx_: have you done a charm build/juju deploy recently?
[22:58] <bdx_> errr, not in the last day or so
[22:58] <stokachu> nah i just built the nginx layer and tried to deploy it locally
[22:59] <bdx_> ahh changes in layer-apt then
[22:59] <stokachu> going to download yours and try it
[22:59] <bdx_> layer apt hasn't changed
[22:59] <stokachu> bdx_: yea so im not sure whats going on
[23:01] <bdx_> this is how im using it -> https://github.com/jamesbeedy/layer-nginx-passenger/blob/master/reactive/nginx_passenger.py#L22,L24
[23:01] <bdx_> not sure if that is correct or not, but it work
[23:01] <bdx_> s
[23:01] <stokachu> bdx_: deploying your layer now to see what happens
[23:04] <stokachu> bdx_: yours fails too
[23:05] <stokachu> http://paste.ubuntu.com/23204830/
[23:07]  * stokachu super sad
[23:07] <cholcombe> anyone remember the cmd to get the reactive states that are set when debugging?
[23:13] <smgoller> thedac: launched an instance and was able to ssh into it just fine.
[23:13] <thedac> fantastic!
[23:16] <smgoller> thedac: so the host can't really resolve anything, including its own hostname. I'm guessing my options are either define a DNS server to use when I create the internal network, or maybe install designate and designate-bind to get route53-like functionality?
[23:16] <smgoller> s/DNS server/external DNS server/
[23:17] <thedac> smgoller: yes, when you define the internal network set a DNS server. As long as it can route there that will work.
[23:17] <smgoller> would designate/designate-bind fulfill that as well?
[23:17] <thedac> designate is a whole other ballgame. More if you want to serve DNS as a service
[23:17] <smgoller> ok
[23:19] <smgoller> thedac: it seems like if I set designate up and link it to nova-compute, then when instances came up, their names would resolve, plus they'd be able to resolve things on the internet normally? Like, I have an instance called "xenial-test". It believes that is its hostname, but it doesn't resolve to anything. designate seems like it would allow that to work.
[23:19] <smgoller> "out of the box" that is
[23:20] <bdx_> stokachu: mine fails similarly to yours?
[23:20] <thedac> smgoller: I am not going to stop you from using designate. It is a good solution but it is adding complexity to a fairly simple problem
[23:20] <thedac> if you find that interesting, go for it
[23:20] <smgoller> thedac: a very diplomatic answer. Thank you. :) I'll stick with defining DNS.
[23:20] <smgoller> and leave designate for another day
[23:22] <smgoller> thedac: one last question before I let you escape: Is it possible to configure the bundle such that the openstack console for instances works?
[23:23] <smgoller> I see you can pass custom configuration to nova-compute, but it feels like the configuration for console needs knowledge of its own ip address for it to work, which I don't know if you can model in a bundle
[23:23] <thedac> smgoller: it has been a while since I have plaeyed with that.
[23:23] <smgoller> ok, then i won't worry about it.
[23:23] <smgoller> thanks!
[23:24] <thedac> smgoller: if the charm is missing anything, patches are welcome :)
[23:24] <smgoller> oh for sure
[23:24] <smgoller> If I come up with anything I'll contribute back, definitely.
[23:25] <bdx_> stokachu: I figured it out to some extent
[23:26] <bdx_> stokachu: add a series tag to your metadata.yaml
[23:26] <bdx_> stokachu: xenial is what I used that worked


[18:15] <ginggs> vorlon: thanks, I'll take a look at apt-xapian-index
[18:35] <vorlon> ginggs: cheers. any thoughts on further systematic testing we should do to check for other runtime problems before we have to stumble across them?  I'm not sure if apt-xapian-index would've been picked up by a rebuild e.g.
[19:19] <vladimirp> jbicha: Hi, just wanted to double-check - are we rolling back Java 21 default by syncing 0.75+exp1?
[19:27] <vpa1977> jbicha: my mistake - same changes as ubuntu1 just a bit more architectures
[23:04] <tsimonq2> noble-changes looks to be asleep, could someone please wake it up?
[23:07] <vorlon> bdmurray: ^^ I don't remember, do you have any administrative access to the list to check on it, or should this be a straight RT?
[23:11] <vorlon> tsimonq2: is it asleep on both mail delivery and web archive or just web archive? (I'm not subscribed so don't know about mail delivery firsthad)
[23:13] <bdmurray> The -changes lists are setup by IS during archive opening and I don't think they give anyone access.


[06:54] <praveen__> is there anyway i can know through some code that some process is suspended or not
[14:08] <azimout> question: is it possible to use bootchart without an initrd? do you just add a script at S01?
[14:09] <azimout> and, on a different issue, isn't the room topic a bit old?
[14:20] <azimout> anyone?
[15:07] <rtg> apw: is there sufficient information in the vanilla kernel signature that kerneloops can spew an appropriate blob?
[15:09] <apw> i think we send him enough, but he never responded to say whether he was happy
[15:09] <rtg> big surprise there :)
[15:28] <ivoks> i'm getting 'Invalid or unsupported executable format' from grub on all jaunty's generic kernels since (including) 2.6.28-7
[15:31] <rtg> ivoks: you must have HW issues. Surely lots of folks would have been howling by now.
[15:31] <ivoks> could be... but -6 works :/
[15:31] <ivoks> even after reinstall of all kernel
[15:31] <ivoks> s
[15:32] <rtg> have fsck'd ?
[15:32] <rtg> s/have/have you/
[15:32] <ivoks> could try that...
[15:32] <ivoks> it's ext4
[15:33] <rtg> ivoks: is it an ext4 upgrade, or was it install time formatted ?
[15:33] <ivoks> upgrade
[15:34] <rtg> hmm, there were a bunch of ext4 changes that went into -7.18
[15:34] <ivoks> right, i've notices that
[15:34] <ivoks> noticed
[15:36] <rtg> ivoks: any change you could build a kernel with all of those patches reverted? I expected them via stable updates by now, but perhaps Ted has been finding issues with them.
[15:36] <ivoks> i could try...
[15:37] <rtg> ivoks: they are all labeled 'SAUCE: (revert before 2.6.28.y update) ext4:'
[15:37] <ivoks> thanks
[15:53] <ivoks> only 21 commits :)
[16:22] <ivoks> is it possible to build i386 kernel on amd64?
[16:24] <rtg> ivoks: you have to chroot the build.
[16:24] <ivoks> oh, right!
[16:51] <_ruben> hrm .. seems i just got bitten by http://kerneltrap.org/mailarchive/linux-kernel/2008/10/16/3678594 .. on 2.6.27-11-server
[16:52] <_ruben> lets see if manually applying the patch helps
[16:53] <_ruben> bah .. it does fix it, yet there's more to it to get scst kmod to build against that kernel
[17:10] <rtg> does anyone know how to analyze a crash dump core? I've gotten past where I can copy a crash from /proc/vmcore, but am kind of stalled at the gdb point.
[17:15] <Ng> smb_tp: we were expecting 2.6.24-23.49 to fix the rtc related kernel oops on sparc64, right?
[17:16] <smb_tp> Ng, Was that rtc? Sorry got too many other patches through my head lately. But I think we expected it to fix the problem you had.
[17:18] <Ng> hmm, I just netbooted the machine and installed the newer kernel package from proposed, but it's still doing it. I think I must have done something wrong, the initial version details printed by the kernel claim it's still .48
[17:19] <smb_tp> It definitely would have to be .49.
[17:20] <Ng> I guess I'll be netbooting it again and poking
[17:26] <ivoks> rtg: so, reverting all ext4 commits since -6 did the trick
[17:27] <rtg> ivoks: can you file a bug with the specifics, and your results that I can pass on to Ted ?
[17:27] <ivoks> yes, but later... i have to rush now :/
[17:28] <ivoks> take care
[17:47] <Ng> smb_tp: yeah that was my mistake, I mounted the wrong partition. It boots now :)
[17:47] <smb_tp> Cool
[17:49] <rtg> Keybuk: uploaded 2.6.28-8.24 with the cpu governor changes
[17:54] <Keybuk> rtg: thanks
[17:55] <rtg> Keybuk: maybe you can teach me how to analyze a vmcore ? I can't seem to get the right info for gdb.
[17:57] <Keybuk> you have the linux-kernel-debug package?
[17:57] <rtg> Keybuk: not yet, just kexec-tools
[17:57] <Keybuk> ah, you need the -debug thingy
[17:58] <Keybuk> and apt-get install crash
[17:58] <Keybuk> which is a bit like gdb
[17:58] <Keybuk> that's what I've used in the past, anyway
[17:58] <rtg> Keybuk: thats not a Jaunty package, is it?
[17:59] <Keybuk> crash? should be
[17:59] <Keybuk> it's even in main
[17:59] <rtg> I meant linux-kernel-debug
[17:59] <Keybuk> oh, no, that's in ddebs.ubuntu.com
[17:59] <Keybuk> http://magazine.redhat.com/2007/08/15/a-quick-overview-of-linux-kernel-crash-dump-analysis/
[17:59] <Keybuk> ^ that's a pretty good guide from a RH pov
[17:59] <rtg> all of this is  a bit byzantine.
[18:00] <Keybuk> it's the _kernel_ ;)
[18:00] <Keybuk> some chickens have to be sacrificed
[18:00] <rtg> ok, I'll grind through that.
[18:05] <Keybuk> cool
[18:05] <Keybuk> hwclock changes get us to the end of rcS in 9s
[21:10] <maco> is kernel team also responsible for packaging the kernel?
[21:15] <pgraner> maco: yes
[21:15] <maco> pgraner: bug 272885 is worth looking then
[21:15] <ubot3> Malone bug 272885 in linux-meta "linux-image package must depend on package grub" [Undecided,New] https://launchpad.net/bugs/272885
[21:15] <maco> the postinst scripts in the kernel try to update grub, but if you're not using grub, it's a problem
[21:16] <maco> it recommends, but recommends don't *have* to be fulfilled
[21:17] <pgraner> rtg: since you the local pkg guru, what do you think?
[21:22] <maxb> maco: remove/comment-out postinst_hook and postrm_hook  in /etc/kernel-img.conf
[21:25] <maxb> sorry, that's overly generic advice
[21:25] <maxb> I guess as far as that bug is concerned, bits of the last-good-boot infrastructure should not be in the "grub" package
[22:34] <dtchen> i'd be a bit uncomfortable making grub a hard dependency, but i suppose there must be a time and place to move beyond lilo


[02:09] -queuebot:#edubuntu- Builds: Edubuntu Desktop amd64 [Mantic Daily] has been updated (20230912)
[19:41] <Eickmeyer> cjdg_: We had a flavor sync meeting yesterday with all of the flavor leads, the release team, and the Ubuntu Desktop team. One of the outcomes was that we are a step closer to Raspberry PI images.


[15:04] <lilith93> If anyone is sitting in front of a ubuntustudio installation, can you please check: ls -l /etc/resolv.conf
[15:04] <lilith93> ?
[15:05] <lilith93> I wonder why it links to ../run/resolvconf/resolv.conf although on Ubuntu 20.04 it should be managed by systemd
[15:09] <OvenWerks> lilith93: mine is the same... I am not sure why it should not be no matter who is managing it.
[15:10] <lilith93> OvenWerks: Just asking because I have some issues with DNS resolving in Firefox and chromium sporadically
[15:10] <lilith93> thanks for checking, so at seems to be normal.
[15:10] <lilith93> *it
[15:11] <OvenWerks> Most systems get their ip, gateway, name server from dhcp
[15:11] <OvenWerks> the dhcp client writes ../run/resolvconf/resolv.conf
[15:11] <lilith93> I set firefox to get the domain directly... this seem to work better
[15:13] <OvenWerks> the only problem I have had with firefox and DNS resolving (maybe) is if the switch has been turned off for a bit.
[15:13] <OvenWerks> FF then takes a while to figure out where things are.
[15:15] <lilith93> which switch?
[15:15] <lilith93> it takes sometime 5.01 s to get the name resolved.
[15:15] <lilith93> which looks like a time out
[15:15] <OvenWerks> The switch between my router and the rest of the house
[15:17] <lilith93> ah... I have PC --> LAN --> Repeater 1 --> WLAN --> Repeater 2 --> WLAN Fritzbox
[15:18] <lilith93> it's always on
[15:18] <lilith93> I don't know if that makes sense, but maybe Ubuntustudio 20.04 is based on a earlier upgraded Ubuntu version?
[15:20] <OvenWerks> we have a timmer that shuts the switch off at 0030 and turns it back on at 0630... so people actually go to sleep and so we don't get woke up at 0300 by someone half way around the world.
[15:21] <OvenWerks> lilith93: you could see if xubuntu is the same I guess
[15:21] <lilith93> ahhh... maybe it's different there, right.
[15:22] <lilith93> I also wonder why there were no updates the last days. maybe because of xmas ...
[15:22] <lilith93> my latest kernel is  5.4.0-58-lowlatency
[15:22] <OvenWerks> yeah, someone has to work for updates to happen
[15:23] <OvenWerks> kernels are done by employees I think.
[15:25] <OvenWerks> uploads to main too.
[15:25] <lilith93> oh, this is new... I thought for Linux in general people don't get paid
[15:28] <OvenWerks> the code is free and open, but much of the coding is done by paid employees of various companies.
[15:29] <OvenWerks> there are also companies that do linux system support
[15:29] <OvenWerks> and sell linux preinstalled computers
[15:29] <lilith93> I thought about buying a Mac mini M1, but I wonder if this will have less flaws than Linux
[15:30] <lilith93> In principal I'm happy with Linux (as long it works :) )
[15:30] <OvenWerks> A large portion of the kernel real time code is sponsored by various companies (including Intel)
[15:31] <OvenWerks> as for the Mac mini, my feeling is that it is still new, so bugs are likely... and lockin has gone up a notch
[15:33] <OvenWerks> Also the CPU has changed (again) so all sw has to be rewritten or run with an adaptor middle ware.
[15:33] <lilith93> I never had a mac and never was a fanboy... But it quite silent and almost don't need a fan running
[15:34] <lilith93> Was thinking about a NUC PC with Linux as an alternative, but these seems to be quite loud when the fan is running
[15:35]  * OvenWerks would stay as far away from a NUC as he could
[15:35] <OvenWerks> too much stuff in a little box to cool and therefore less performance.
[15:37] <lilith93> I think these times every motherboard will work with Linux, right? So, I just have to stay away from NVIDIA
[15:38] <OvenWerks> depends on what things you need. if you don't do much graphics, intel works just fine.
[15:40] <OvenWerks> for someone who does a lot of painting, animation or video editing, nvidia might be worth while if you don't mind the blob...
[15:41] <OvenWerks> But for everyday youtube videos and desktop work... it is not needed
[15:42] <OvenWerks> Also, any high power graphics creates heat and therefore noise.
[15:44] <OvenWerks> lilith93: in the long run, I expect that there will be more arm/risc based systems, not just mac.
[15:58] <lilith93> OvenWerks: Yes, I think so too. I have a thinkpad which I could use as an in between solution if my PC crashes
[16:04] <lilith93> ahh .. new kernel update today
[16:05] <lilith93> or at least some updates


[00:52]  * genii-around sips
[00:54] <genii-around> Meh. Is there something like quassel-sync where I can merge 2 different machines both running monolithic versions?
[00:54] <genii-around> Wrong channel, apologies
[03:53] <Artificial_Intel> I need a cloak, thanks. https://launchpad.net/~artificial-intelligence
[03:57] <nhandler> jussi, elky, topyli, tsimpson: ^
[05:20] <elky> nhandler, yep
[05:26] <nhandler> elky: Done
[09:43] <ubot4> valorie called the ops in #ubuntu-women-project ()
[10:14] <Tm_T> mmmh ^
[16:53] <cyberanger> We (#ubuntu-us-tn) have a channel whose founder has been gone a few months (Aug 19 according to nickserv) and was wondering if that could be adjusted, to our current point of contact perhaps?
[16:54] <cyberanger> was directed here from a #freenode op, different procudre for #ubuntu-* channels I'm told
[17:15] <cyberanger> is this the best channel to ask, or would somewhere else be better?
[17:20] <k1l> this is the right place. just wait until someone vorm the ircc wakes up :)
[17:21] <cyberanger> k1l: no problem, I've let the issue stew for months, don't mind waiting a day or two for the right solution
[17:21] <cyberanger> thanks
[17:23]  * tsimpson looks into it
[17:34] <cyberanger> tsimpson: some extra info, should it help, current founder was w4ett, military deployed, which caused issues, our last election I was elected trustee (our teams title for point of contact) he couldn't even tell us of his deployment for 6 months, after the election he did a proper handoff of most team resources (irc being overlooked, and he didn't have full control on the forum)
[17:35] <cyberanger> and I could pull up the email and irc logs on this, if it'd help
[17:35] <cyberanger> thanks in advance mate
[17:36] <tsimpson> I can see that you're set as the current owner of the ~tennessee.team launchpad team, so no need :)
[17:36] <tsimpson> I'm just getting staff to give you access, but finding active staff is not always easy
[17:37] <cyberanger> ok, that's good (it's hard doing a proper handoff when the military has you far away, and only gives you so much internet access, best used to contact home, he did what he could, given his constraints)
[17:40] <tsimpson> cyberanger: you should be set now
[17:42] <cyberanger> tsimpson: didn't know two people could have the founder flag, cool
[17:42] <cyberanger> and thanks again, it appears set
[17:42] <tsimpson> no problem :)
[18:03] <cyberanger> tsimpson: yep, that definately did it, thanks
[23:14] <vibhav> are you dere bazhang?
[23:14] <bazhang> vibhav, yes?
[23:14] <vibhav> !op
[23:14] <vibhav> Oh sorry
[23:14] <bazhang> ...
[23:14] <vibhav> NEVER MIND!
[23:15] <vibhav> Btw , bazhang I am banned from ubuntu-ops , offtopic
[23:15] <vibhav> ikonia did it
[23:15] <vibhav> CAn you unbann me
[23:15] <bazhang> vibhav, try to /join #ubuntu-ops
[23:15] <vibhav> Cannot join #ubuntu-ops (You are banned).
[23:15] <vibhav> :(
[23:16] <m4v> if you managed to get banned from #ubuntu-ops this channel can't help you
[23:16] <vibhav> why?
[23:16] <vibhav> I HATE IKONIA!
[23:16] <bazhang> vibhav, calm down
[23:16] <bazhang> and have some patience
[23:16] <vibhav> ok
[23:17] <vibhav> I am trying to be patient for the last 25 days
[23:17] <bazhang> trying to get you unbanned from -ops so we can discuss there. no need for the anger, etc
[23:18] <vibhav> ok
[23:19] <bazhang> vibhav, try now
[23:20] <vibhav> ok , unbanned
[23:20] <vibhav> parting now
[23:22] <jpds> ...
[23:29] <jpds> That guy has an interesting track recors.
[23:29] <jpds> record*
[23:30] <Unit193> Calling for ops and then asking to be unbanned...