[19:06] <vorathiel21> Hi people, i wanna   put   /home/user/.cache  and   /tmp  directories  in  /run/shm   to increase performance and   clean temp files on every reboot.  Can i do this with symlinks  ??
[19:29] <cmaloney> vorathiel21: I'd recommend using tmpfs for /tmp
[19:30] <cmaloney> https://askubuntu.com/a/173294/1614
[19:31] <cmaloney> as far as cache is concerned unless there's a reason not to write .cache I'd leave it alone
[19:31] <cmaloney> reason being:
[19:31] <cmaloney> There's a lot of things in there that will take longer to re-create
[19:31] <cmaloney> eg: thumbnails and the like
[19:32] <cmaloney> so you'll slow your machine down if you constantly re-create cache
[19:37] <vorathiel21> thanx for your answer.  i've already try  tmpfs  .  it worked fine . The thing is today  i discover  this /run/shm  directory
[19:37] <cmaloney> It's the same thing
[19:37] <cmaloney> If you cd to /run and type `df .` you'll see that it's using tmpfs
[19:39] <cmaloney> https://askubuntu.com/questions/169495/what-are-run-lock-and-run-shm-used-for
[19:42] <vorathiel21> don't you think if i put  those  directories under  /run/shm  , them will share the space ??   i think it's a waste of ram to declare  separated  tmpfs in fstab for  /tmp  and  .cache  ... if there is already a ramdrive available on  /run/shm
[19:43] <vorathiel21> am i wrong ??
[19:43] <cmaloney> I think you're misunderstanding how Linux allocates RAM
[19:43] <vorathiel21> it can be possible
[19:44] <cmaloney> tmpfs is not cordoned off the way you might think it would be for a physical disk
[19:44] <cmaloney> eg: /run/shm doesn't have half of your memory allocated
[19:45] <cmaloney> It's showing the maximum that it will allocate
[19:45] <cmaloney> What is allocated is what you see when you run df
[19:46] <cmaloney> Linux tries to keep as much in an internal cache as possible for performance
[19:46] <cmaloney> and will free up those pages as memory pressures become larger
[19:46] <cmaloney> That's why if you run `free` you'll notice that there's precious little memory left
[19:47] <cmaloney> that's Linux trying to ensure that it goes to disk as few times as it can
[19:47] <cmaloney> most of the time it'll read things from cache
[19:48] <vorathiel21> hmmm
[19:49] <cmaloney> here's an easy test
[19:49] <cmaloney> as root:
[19:49] <cmaloney> sync; echo 1 > /proc/sys/vm/drop_caches
[19:49] <cmaloney> that will clear out the cache
[19:49] <cmaloney> then run (as a normal user) `watch free`
[19:49] <cmaloney> and use your machine
[19:49] <cmaloney> You'll notice it start to fill up the cache again
[19:50] <vorathiel21> i understand.  So... linux already is doing what am trying to do
[19:51] <cmaloney> Exactly
[19:51] <cmaloney> changing /tmp to tmpfs is still a decent idea
[19:51] <cmaloney> I do it on all of my machines
[19:52] <cmaloney> but going much beyond that isn't going to give you what you think it will
[19:55] <vorathiel21> thank you for enlightening me on this
[19:56] <cmaloney> no problem. glad I could help
[19:56] <vorathiel21> c ya
[19:56] <cmaloney> ttyl


[09:46] <apw> jibel, looks like autopkgtst broke for linux during setup ?
[09:47] <apw> jibel, specifically working for amd64
[09:49] <jibel> apw, again :( I'll increase the copy timeout a bit more, but more than half an hour to copy the build tree becomes ridiculous.
[09:49] <jibel> maybe we can drop this copy_timeout completely from autopkgtest
[09:50] <apw> jibel, it is 5GB or so, perhaps we can improve the test some, as it makes no sense to run when uploading the kernel
[09:51] <apw> jibel, /me asks pitti about it on #ubuntu-devel
[09:55] <Laney> here comes the alpha freeze
[09:59] <Riddell> brr
[09:59] <Riddell> superm1: ping, no reply on https://wiki.ubuntu.com/TrustyTahr/Alpha2
[09:59] <Riddell> utlemming: likewise ↑
[10:00] <Laney> I've only been taking action for those flavours marked as 'yes'
[10:01] <Riddell> zequence: ↑
[10:01] <Riddell> yes safe to assume they're not in if it's not marked but worth a poke :)
[10:03] <zequence> Riddell: That's correct :)
[10:06] <Riddell> zequence: shall I take Howard Chan off as a contact for Studio?
[10:07]  * Riddell does so
[10:08] <zequence> Riddell: Thanks. Can't login there atm
[10:08] <Laney> kicked iso rebuilds
[10:09] <Laney> self service after these ones appear
[10:11] <Riddell> thanks
[10:14] <darkxst> Laney, why are there no alpha 2 targets on the qa tracker?
[10:14] <Laney> I just made it
[10:14] <Laney> the new images will go in there
[10:14] <Laney> assuming I got it right
[11:28] <didrocks> at-spi2-core is blocked by the alpha2 freeze. it's a revert to yesterday's version as it created crashes with qmlscene in qt5 for touch, can we get it unblocked please?
[11:29] <didrocks> Riddell: ^
[11:51] <apw> the kernel we uploaded last night (to fix the random oddness with tmpfs as reported by cjwatson) is ready in -proposed
[11:56] <Riddell> didrocks: will it need a respin?
[11:56] <Riddell> apw: oh cool
[11:56] <cjwatson> We should respin for the kernel in any case; the percpu counter problems make it unreleaseable IMO
[11:56] <didrocks> Riddell: we are going to respin ubuntu-touch, I don't think it's impacting other flavors as they don't use qt5
[11:57] <didrocks> (but ubuntu touch isn't in the alpha2 set, so we handle ourself the respin)
[11:57] <Riddell> didrocks: is ubuntu touch part of the alpha? (does it even get releases?)
[11:57] <Riddell> ok groovy
[11:57] <didrocks> ;)
[11:57] <didrocks> pre-emptive answer ;)
[11:57] <Laney> feel free to do the unblocks & handle the respin once the kernel is in
[11:59] <Riddell> how does the kernel get in? dose it just need an unblock on linux?
[12:05] <xnox> Riddell: as per http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux yes, linux linux-meta linux-signed debian-installer need unblocking.
[12:10] <didrocks> Riddell: are you handling the unblokcing of at-spi2-core as well? (was still blocked on latest update_excuses.output generation)
[12:10] <didrocks> unblocking*
[12:11] <Riddell> didrocks: yeah can do
[12:11] <didrocks> thanks!
[12:19]  * apw would recommend updating the kernel in any images you are releasing, the -4 seems to be a bit of a lemon
[12:19] <Laney> we'll respin
[12:23] <Laney> the branch says it is unblocked
[12:23] <Laney> oops
[12:54] <Riddell> didrocks: at-spi2 in
[12:54] <didrocks> Riddell: excellent, thanks!
[12:55] <Riddell> Laney: new linux in too, will you do the respins?
[12:55] <Laney> Riddell: you can
[12:55] <Riddell> lucky me :)
[12:55] <Laney> tick them on the alpha 2 page on the tracker, click request rebuild at the bottom
[12:55] <Laney> assuming you checked that rmadison shows everything
[12:56] <Riddell> Laney: rmadison?
[12:57] <Laney> rmadison -S -s trusty linux
[12:59] <cjwatson> more accurate than LP for the purpose of image builds, indeed
[12:59] <cjwatson> rmadison => "actually visible in published archive"
[13:00] <Riddell> mm, still on the old image using my cache from archive.ubuntu.com, so I guess I should wait a bit
[13:05] <cjwatson> Riddell: rmadison is also quicker than waiting for archive.ubuntu.com to update
[13:05] <cjwatson> (because the rmadison backend works off ftpmaster.internal, which is also what image builds work off, but archive.ubuntu.com is a mirror)
[13:06] <Riddell> but if i run it on my local computer does that use ftpmaster.internal?
[13:07] <cjwatson> yes, rmadison talks to a CGI script on snakefruit.c.c
[13:07] <Laney> it hits a remote web service
[13:33] <cjwatson> mlankhorst: is glamor-egl-lts-saucy OK to promote to precise-updates?  (no bug)
[13:34] <mlankhorst> should be
[13:34] <mlankhorst> tjaalton: ?
[13:34] <cjwatson> that's what I thought but just wanted to double-check
[13:35] <tjaalton> I've no objections
[13:35] <mlankhorst> let me test on precise real quick
[13:41] <mlankhorst> cjwatson: oh right that was just the shlibdeps override, if you can make the cd's now that's fine
[13:44] <mlankhorst> yeah did some testing, glamor works
[13:44]  * cjwatson tries to remember how to check
[13:45] <mlankhorst> Depends: libc6 (>= 2.14), libgl1-mesa-glx-lts-saucy | libgl1
[13:45] <mlankhorst> and Xorg starts with my radeon 5570hd glamor, so it's fine
[13:46] <cjwatson> http://ci.ubuntu.com/smokeng/precise/alternate/ started passing at around the time we pushed glamor-egl to -proposed
[13:46] <cjwatson> so LGTM
[13:47] <mlankhorst> ship it
[13:47] <ogra_> hmm
[13:47]  * ogra_ scratches head ...
[13:48] <ogra_> why does env - behave the same as env -i in a chroot call ? i thought - keeps the environment (and adds to it) while -i wipes it
[13:48] <ogra_> oops, that was supposed to land in -devel
[13:48] <mlankhorst>        A mere - implies -i.  If no COMMAND, print the resulting environment.
[13:49] <ogra_> well, mere means nothing after it, no ?
[13:49] <cjwatson> I think it means as opposed to -optionname
[13:50] <ogra_> with something like: chroot "/usr/bin/env - FOO=bar /usr/bin/env"
[13:50] <cjwatson> the info docs simply list "-" as a synonym for "-i"
[13:50] <ogra_> i would expect the FOO var to be added
[13:50] <ogra_> (and printed)
[13:50] <ogra_> hmm, k
[13:50] <cjwatson> it is, outside a chroot
[13:50] <cjwatson> $ env - FOO=bar env | grep FOO
[13:50] <cjwatson> FOO=bar
[13:51] <ogra_> yeah
[13:51] <cjwatson> but the above is an invalid use of chroot
[13:51] <cjwatson> $ sudo chroot /var/lib/schroot/chroots/sid-i386 "/usr/bin/env - FOO=bar /usr/bin/env" | grep FOO
[13:51] <cjwatson> chroot: failed to run command ‘/usr/bin/env - FOO=bar /usr/bin/env’: No such file or directory
[13:51] <cjwatson> bad quoting
[13:51] <cjwatson> if you remove the quotes it works fine
[13:52] <ogra_> err, yes
[13:52] <cjwatson> and you can also lose the unnecessary hardcoded paths
[13:52] <cjwatson> $ sudo chroot /var/lib/schroot/chroots/sid-i386 env - FOO=bar env | grep FOO
[13:52] <cjwatson> FOO=bar
[13:52] <cjwatson> anyway, it'll still behave the same way as -i in terms of not inheriting the environment
[13:53] <ogra_> right
[14:00] <ogra_> aha
[14:00] <ogra_> sudo chroot  env - "$(env)" FOO=bar
[14:00] <ogra_> that one works
[14:01] <cjwatson> um
[14:01] <cjwatson> that looks pretty perilous if any environment variables might contain spaces
[14:02] <cjwatson> why are you doing this strange thing?
[14:02] <ogra_> i want to keep a valid PATH etc when setting a bunch of env vars in a script
[14:02] <cjwatson> I mean, why not just say   env FOO=bar command?
[14:02] <ogra_> and dont want to have to set it every time the scrit chroots
[14:02] <ogra_> *script
[14:03] <cjwatson> but chroot passes through the environment
[14:03] <ogra_> why does env not show it to me then ?
[14:03] <cjwatson> $ diff -u <(sudo env | grep -v ^SUDO_COMMAND=) <(sudo chroot /var/lib/schroot/chroots
[14:03] <cjwatson> $
[14:03] <cjwatson> er, sorry
[14:03] <cjwatson> $ diff -u <(sudo env | grep -v ^SUDO_COMMAND=) <(sudo chroot /var/lib/schroot/chroots/sid-i386 env | grep -v ^SUDO_COMMAND=)
[14:03] <cjwatson> $
[14:04] <cjwatson> it shows it to me.  you must be doing something wrong ...
[14:04] <ogra_> using your "sudo chroot /var/lib/schroot/chroots/sid-i386 env - FOO=bar env " from above only returns FOO=bar
[14:04] <cjwatson> that's because - wipes the environment, as I told you
[14:04] <cjwatson> this is why I'm hoping you can tell me what you're actually doing, rather than a constructed example
[14:05] <ogra_> i'm trying to write a wrapper around an armhf live-build on an x86 machine ...
[14:05] <cjwatson> right, so live-build's Chroot (as opposed to chroot) function explicitly clears the environment
[14:05] <ogra_> exporting PROJECT, ARCH etc before calling the lb commands
[14:06] <ogra_> but the testing i do isnt in live build
[14:06] <cjwatson> but that may not matter here, since if you're just talking about PROJECT/ARCH/etc., those don't need to be passed through Chroot
[14:06] <cjwatson> why don't you just export the environment and call lb?  you shouldn't need to do anything special for what you just described
[14:06] <ogra_> i call lb inside an armhf chroot
[14:06] <cjwatson> doesn't matter
[14:06] <ogra_> and the env doesnt have the vars if i exported them outside
[14:07] <cjwatson> show me real code that doesn't work
[14:07] <cjwatson> without any of this env madnes
[14:07] <cjwatson> s
[14:08] <cjwatson> because in general this *does* work
[14:10] <ogra_> http://paste.ubuntu.com/6791775/
[14:10] <cjwatson> have you tried sudo -E?
[14:10] <ogra_> uh, heh, no, not yet
[14:11] <cjwatson> or maybe it's worth simply running this whole script as root
[14:11] <cjwatson> it doesn't really seem worth having something that runs as a user but runs sudo around basically everything it does
[14:11] <cjwatson> I'd just ditch the sudos and have a uid check at the top
[14:12] <ogra_> hmm, well, let me try the -E ... didnt strike me that it could be sudo
[14:12] <cjwatson> or else have a single uid check that does   exec sudo "$0" "$@"   or similar
[14:12] <ogra_> if that doesnt work i'll ditch sudo
[14:12] <cjwatson> sudo -E is configuration-dependent, so it's probably a worse option
[14:12] <cjwatson> it's possible to have sudo set up such that that won't work
[14:13] <cjwatson> best just to arrange things so that you don't need to pass the environment through sudo
[14:13] <ogra_> well, then the self exec via sudo wouldnt work either
[14:13] <ogra_> (if sudo was set up like that)
[14:16] <cjwatson> ogra_: I believe it always preserves PATH
[14:17] <ogra_> k
[14:17]  * ogra_ waits for the result ...
[14:18] <cjwatson> ogra_: and in any case I would expect it to resolve the command using the caller's PATH; nothing to say that that has to be the same PATH as is set in the callee's environment
[14:19] <ogra_> right, i dont care so much about keeping the actual env, but i want a properly working one *and* my vars that i exported
[14:19] <cjwatson> right, so just doing the whole thing inside a single <pick your root escalation method> is best
[14:20] <ogra_> yeah, -E definitely works
[14:20] <ogra_> thanks !
[14:20] <cjwatson> ok, I still think -E isn't the right answer though
[14:21]  * ogra_ will think about the re-exec
[14:21] <cjwatson> just a way to confirm that you're on the right track
[14:21] <ogra_> yep
[14:22]  * ogra_ drops the exit ... lets see if i end up with a tarball :)
[14:32] <ogra_> hmm, i should probably have set LB_MIRROR in the environment ...
[14:42] <ogra_> bah
[14:42] <ogra_> lb doesnt like its env
[14:42] <ogra_> W: Failure trying to run: chroot //chroot mount -t proc proc /proc
[14:42] <ogra_> ...
[14:42] <ogra_> /usr/sbin/chroot: failed to run command '/usr/bin/env': No such file or directory
[14:50] <ogra_> to sad, lb clean and lb config did work fine
[14:50] <ogra_> /tmp/chroot/chroot/debootstrap/debootstrap.log has "/usr/sbin/chroot: failed to run command 'mount': No such file or directory"
[14:51] <ogra_> which is weird
[14:51] <cjwatson> I expect the key is figuring out where the "//chroot" comes from
[14:52] <cjwatson> that's probably /$SOMETHING_UNSET/chroot
[14:52] <cjwatson> stick set -x everywhere
[14:52] <ogra_> well, thats inside live-build itself ...
[14:55] <cjwatson> sure
[14:55] <ogra_> given that the deboootstrap pahse already worked i can only imagine that live-build misses some config in our default setup
[14:56] <cjwatson> I think you should pick a different candidate theory than "live-build is broken"
[14:56] <cjwatson> since it works fine for e.g. building all our imaegs
[14:56] <cjwatson> *images
[14:56] <ogra_> i dont say live-build is broken, i say our livecd-rootfs setup is broken when run standalone :)
[14:57] <cjwatson> I've used it standalone not that long ago
[14:57] <ogra_> hmm
[14:57] <cjwatson> and the BuildLiveCD script is not that complex a wrapper
[14:57] <cjwatson> you could compare it with what you're doing
[14:57] <ogra_> right
[15:10] <xnox> cjwatson: is there some uninstallability in Saucy atm? #sdk folks are spotting that click chroot create is failing against saucy http://paste.ubuntu.com/6792074/
[15:14] <cjwatson> you know as much as I do :)
[15:14] <xnox> ok =)
[15:15] <cjwatson> looks fine in chdist ...
[15:15] <xnox> running finish.sh with set -x to see which command fails.
[15:15] <Laney> Riddell: AFAICS you can do the respins
[15:15] <Laney> now
[15:15] <xnox> (of the click chroot portions) as yeah, normal things look fine.
[15:16]  * Riddell rebuilds alpha 2 flavours
[15:17] <Laney> ah we have explicit answers for everything other than cloud
[15:38] <xnox> cjwatson: adding " gcc g++ cpp cpp-4.8 g++-4.8 gcc-4.8" to the list of packages to install, succeeds. Yet intermediate steps, look like have mismatched version numbers.
[15:38] <xnox> http://paste.ubuntu.com/6792203/
[15:38] <xnox> doko: should version numbers match across all of them in http://paste.ubuntu.com/6792203/ ?
[15:39] <doko> xnox, no, built from different sources
[15:40] <doko> why the "unmet dependencies"?
[15:41] <xnox> doko: it's quite strange. In a  saucy-amd64 chroot, with armhf added as foreign arch, apt-get -y --force-yes install build-essential g++-arm-linux-gnueabihf pkg-config-arm-linux-gnueabihf dpkg-cross libc-dev:armhf fails with unmet dependencies.
[15:41] <xnox> yet succeeds when "gcc g++ cpp cpp-4.8 g++-4.8 gcc-4.8" is added
[15:42] <xnox> i wonder if gcc-defaults-armhf-cross simply needs a rebuild in saucy.
[16:25] <xnox> do cloud images also need a respin for new kernel?
[16:26] <apw> if they have a kernel in then i would
[16:26] <xnox> smoser: ^ ? i see strange errors when trying to prepare testbeds for adt.
[16:26]  * xnox ENOCLUE how  / where cloud images are respun
[16:27] <utlemming> xnox: I can respin
[16:27] <xnox> utlemming: yes, please! =)
[16:27] <smoser> k. yeah, please re-spin
[16:27]  * utlemming respins
[16:27] <utlemming> xnox: eta is roughly three or four hours
[16:28] <xnox> utlemming: thank's, i'll look for something else to do in the mean time then.
[16:29] <utlemming> xnox: which kernel should this image have?
[16:29] <xnox> 3.13.0-5
[16:29] <utlemming> xnox: thanks
[16:46] <jibel> xnox, with 3.13.0-4 in adt VMs, df reports rootfs is full while it is only 15% full and everything fails with ENOSPC
[16:47] <xnox> jibel: ack. So once cloud images respun, all should be well.
[16:47] <jibel> finger crossed
[16:55] <cjwatson> jibel: right, same failure mode as d-i.
[17:01] <utlemming> xnox, jibel: correct kernel is in the respin. I uploaded the amd64 on Canonistack as utlemming/testing/ubuntu-trusty-amd64-20131213-1390322199 if you want to take a look
[17:01] <bdmurray> slangasek or somebody else - could you please review whoopsie in saucy -proposed fixing bug 1245524
[17:01] <ubot2`> Launchpad bug 1245524 in whoopsie (Ubuntu Saucy) "whoopsie fails to notice/process .upload files on trusty" [High,In progress] https://launchpad.net/bugs/1245524
[17:11] <xnox> utlemming: well, i mostly after generic cloud-image.ubuntu.com which ADT uses.
[17:11] <xnox> http://cloud-images.ubuntu.com/$RELEASE/$BUILDID ...
[17:43] <slangasek> bdmurray: why does this include changes to the debugging CFLAGS in ./Makefile? (CFLAGS=-g3)
[17:44] <slangasek> jodh: why are we waiting for the alpha freeze to be over before pushing out upstart 1.11-0ubuntu2?  It's a critical bug fix, I think we should just land it
[17:44] <bdmurray> slangasek: hmm, it shouldn't - go ahead and reject it
[17:44] <slangasek> ok
[17:45] <jodh> slangasek: yes, shame it was only reviewed today. I only put that comment on the bug as I do not have the power to progress it personally.
[17:45] <slangasek> jodh: you have the power to ask the release team to let it through :)
[17:45] <doko> if you respin packages, please unblock libffi, or unblock it anyway. armhf only fix
[17:46] <slangasek> Laney: ^^ I think upstart 1.11-0ubuntu2 should be let through immediately; what do you think?
[17:46] <jodh> slangasek: ok, please can someone release it after maybe doing a boot test?
[17:46] <slangasek> jodh: I'm assuming you've done a boot test already?
[17:47] <jodh> slangasek: I have done one, yes (not tested on all arches as the fix is so generic).
[17:47]  * slangasek nods
[17:47] <Laney> Is it that random reboot fix?
[17:47] <slangasek> so I don't intend to retread ground you've already covered
[17:47] <Laney> well, not random, YKWIM
[17:47] <doko> afk now, please consider libffi, see lp #1270816
[17:47] <ubot2`> Launchpad bug 1270816 in python-cffi (Ubuntu Trusty) "python-cffi tests fail on arm-linux-gnueabihf with glibc-2.18" [High,Confirmed] https://launchpad.net/bugs/1270816
[17:47] <slangasek> Laney: it's the kernel-panic-on-telinit-u fix
[17:47] <jodh> Laney: yes, if you want to try it :)
[17:48] <Laney> can't right now
[17:48] <jodh> Laney: if you are still seeing the problem, either you have an old alsa-utils still, or you have another invalid job. You could try "for i in /etc/init/*; do init-checkconf $i;done" to see which job(s) are invalid.
[17:48] <Laney> but it's fine to unblock it IMO
[17:49] <Laney> maybe someone else could verify and then do thatr
[17:49] <slangasek> Laney: ok.  If we're unblocking upstart, should we also unblock the libffi doko asked for, at the same time?
[17:49] <bdmurray> slangasek: reuploaded
[17:51] <Laney> slangasek: fine from an alpha pov - armhf only which we aren't releasing any of
[17:51]  * slangasek nods
[17:52] <Laney> jodh: I just get "ERROR: Another instance of this program is already running" a lot
[17:58] <jodh> Laney: yes, there's a fix for that upstream that will end up in the release I hope to do this/next week.
[17:59] <jodh> Laney: I think the problem you're seeing is a timing one so if you put a small pause (sleep - shudder) between each call, it should work.
[18:01] <Laney> jodh: Nah, it always does it
[18:01] <cjwatson> mlankhorst: another precise-updates question for you: is xserver-xorg-video-nouveau-lts-saucy OK?
[18:05] <mlankhorst> ~$ grep -i blank /var/log/Xorg.0.log
[18:05] <mlankhorst> [    21.213] (==) NOUVEAU(0): GLX sync to VBlank enabled.
[18:06] <mlankhorst> seems to be :)
[18:06] <cjwatson> OK, releasing
[18:06] <jodh> Laney: just checked the code - the problem with init-checkconf is that you need the new upstream version that runs a session init to test the files. The version you are running is using upstart running against the session bus (an old test facility). However, that no longer works because the current Session Init also connects to the session bus. Although it drops the connection when re-exec'ed due to a bug (that I've also fixed
[18:06] <jodh> upstream). So, you *could* make init-checkconf work for you by running 'telinit u' to make the Session Init disconnect from the session bus. Oh the irony...
[18:07] <Laney> Maybe I'll wait until I reboot tomorrow :P
[18:07] <jodh> Laney: good plan
[18:09] <jodh> Laney: but if you're keen, you could just pull the latest version of init-checkconf from here: http://bazaar.launchpad.net/~jamesodhunt/upstart/use-session-init-for-init-checkconf/view/head:/scripts/init-checkconf.sh
[18:15] <Laney> jodh: aha, that works
[18:15] <Laney> there's a few that it cries about
[18:16] <Laney> oh no, it's just racy - that's what you said before I guess
[18:24] <infinity> rtg: Did we want to consider the previous linux-firmware SRU verified and push it out before I review this one, or did you want this one to supersede the current proposed version?
[18:24] <infinity> rtg: The current one seems as verified as it's going to get, but maybe you intentionally wanted to replace some bits with this upload?
[18:28] <jodh> Laney: ace :)
[18:28] <jodh> Laney: so, any invalid jobs?
[18:29] <jodh> Laney: hmm, no the new version shouldn't be racy :(
[18:29] <Laney> running on old upstart?
[18:30] <jodh> Laney: the new version of that script using the existing upstart _should_ be fine, yeah. If not, feel free to raise a bug on init-checkconf.
[18:31] <Laney> okay, but that'll be a tomorrow job
[18:54] <rtg> infinity, I don't think there is any file overlap between the 2 versions, is there ?
[18:58] <rtg> infinity, at any rate, I think the previous version has been sufficiently verified.
[20:47] <stgraber> if anyone was wondering, I'll take care of Newing cgmanager (I already did a pre-upload NEW review, just checking that everything is still in order in the current one)


[04:21] <mup> Bug #1844544 changed: multiple gateways with ipv6 and routing-policy <ipv6> <MAAS:Expired> <https://launchpad.net/bugs/1844544>
[04:21] <mup> Bug #1862103 changed: Cannot create KVM pod with bonded NICs <MAAS:Expired> <https://launchpad.net/bugs/1862103>
[04:24] <mup> Bug #1844544 opened: multiple gateways with ipv6 and routing-policy <ipv6> <MAAS:Expired> <https://launchpad.net/bugs/1844544>
[04:24] <mup> Bug #1862103 opened: Cannot create KVM pod with bonded NICs <MAAS:Expired> <https://launchpad.net/bugs/1862103>
[04:33] <mup> Bug #1844544 changed: multiple gateways with ipv6 and routing-policy <ipv6> <MAAS:Expired> <https://launchpad.net/bugs/1844544>
[04:33] <mup> Bug #1862103 changed: Cannot create KVM pod with bonded NICs <MAAS:Expired> <https://launchpad.net/bugs/1862103>
[04:36] <mup> Bug #1844544 opened: multiple gateways with ipv6 and routing-policy <ipv6> <MAAS:Expired> <https://launchpad.net/bugs/1844544>
[04:36] <mup> Bug #1862103 opened: Cannot create KVM pod with bonded NICs <MAAS:Expired> <https://launchpad.net/bugs/1862103>
[04:39] <mup> Bug #1844544 changed: multiple gateways with ipv6 and routing-policy <ipv6> <MAAS:Expired> <https://launchpad.net/bugs/1844544>
[04:39] <mup> Bug #1862103 changed: Cannot create KVM pod with bonded NICs <MAAS:Expired> <https://launchpad.net/bugs/1862103>
[07:39] <mup> Bug #1864210 changed: no way to crash-cart the ephemeral - maas should pass ssh keys to ephemeral on boot <MAAS:Won't Fix> <https://launchpad.net/bugs/1864210>
[07:39] <mup> Bug #1867935 changed: fix openwsman ftbfs (or remove openwsman and rdep wsmancli) <ftbfs> <rls-ff-incoming> <MAAS:Won't Fix> <openwsman (Ubuntu):Confirmed for ltrager> <wsmancli (Ubuntu):New> <https://launchpad.net/bugs/1867935>
[10:43] <mup> Bug #1871356 opened: "maas init" doesn't create admin user <MAAS:Triaged> <MAAS 2.7:Triaged> <https://launchpad.net/bugs/1871356>
[15:34] <mup> Bug #1871423 opened: MAAS snap can't parse the "BACKOFF" supervisord status <MAAS:New> <https://launchpad.net/bugs/1871423>


[04:44] <Kilos> morning superfly and other early birds
[04:45] <Kilos> Maaz, coffee on
[04:45]  * Maaz puts the kettle on
[04:49] <Maaz> Coffee's ready for Kilos!
[04:54] <Kilos> Maaz, ty
[04:54] <Maaz> You're Welcome I'm sure
[04:55] <Kilos> Maaz, rusks please
[04:55] <Maaz> There is a packet of Ouma's  on the top shelf
[05:12] <superfly> morning Kilos
[05:25] <Kilos> sorry to worry you superfly . i wanna copy all the packages on the 20g drive to my external so i can install on the 80g without having to download. is this command correct or must there be more / and a *
[05:25] <Kilos>  cp /var/cache/apt/archives /media/storage/Packs
[05:26] <superfly> that'll copy the archives directory itself to /media/storage/Packs
[05:26] <superfly> you might want to rather do this
[05:26] <superfly> cp /var/cache/apt/archives/*.deb /media/storage/Packs/
[05:27] <Kilos> this is on 9.04 and i dunno if they will work on maverick as well
[05:27] <superfly> no they won't
[05:27] <Kilos> eish
[05:27] <superfly> packages are tied to a version of Ubuntu
[05:27] <Kilos> so i have to go the download route
[05:28] <Kilos> hi corrie206
[05:28] <superfly> yup
[05:28] <Kilos> ty superfly
[05:30] <Kilos> see i would like to remove 9.04 here and install maverick on this 20g for my sis
[05:30] <Kilos> but cant do the whole update download thing again
[05:30] <Kilos> am looking at remastersys as well
[05:32] <Kilos> ok i go back to 80g. bbl
[06:19] <sakhi> moonin
[06:19] <Kilos> hi sakhi
[06:19] <Kilos> hehe
[06:20] <Kilos> i am trying to register at remastersys but the security is weird
[06:20] <Kilos> one of the questions is how many legs does a $!x legged horse have
[06:28] <superfly> Kilos: what are you trying to do? (i.e. why are you registering at remastersys)
[06:29] <Kilos> i want to ask their forums if and how to use it to a flash disk or externalm because a cd only takes 700m and mine 789m superfly
[06:29] <Kilos> and no dvd writer
[06:29] <Kilos> no dvd anything
[06:29] <superfly> Maaz: Google for linux bootable flash disk
[06:30] <Maaz> superfly: "Boot and run Linux from a USB flash memory stick | USB Pen Drive Linux" http://www.pendrivelinux.com/ :: "Comparing Linux USB flash disk distros | Linux.com" http://www.linux.com/distrocentral/distronews/8221-comparing-linux-usb-flash-disk-distros :: "Imran Nazar: Booting Linux from Flash" http://imrannazar.com/Booting-Linux-from-Flash :: "Create a Bootable Ubuntu USB Flash Drive the Easy Way - How-To Geek" http://www.howtogeek.c
[06:30] <superfly> Maaz: Google for linux convert ISO to bootable flash disk
[06:30] <Maaz> superfly: "Boot ISO image from hard disk?" http://www.linuxquestions.org/questions/linux-general-1/boot-iso-image-from-hard-disk-294744/ :: "How to Convert a Linux Boot ISO to USB | eHow.com" http://www.ehow.com/how_5062890_convert-linux-boot-iso-usb.html :: "UNetbootin - Homepage and Downloads" http://unetbootin.sourceforge.net/ :: "Install any Linux distro directly from hard disk without burning ..." http://www.instantfundas.com/2007/08/i
[06:30] <Kilos> remastersys is supposed to make a cd of your exact system superfly  so that means no downloads
[06:31] <superfly> Kilos: yes, but does it make an ISO?
[06:31] <Kilos> yes it makes an iso too
[06:31] <superfly> right, then my last search is most definitely relevant
[06:31] <Kilos> thats what filled my 6g drive so i couldnt go on
[06:32] <Kilos> oh
[06:32] <Kilos> ty will look
[15:41] <drubin> Does ubuntu alert you when it is end of life?
[15:42] <drubin> is there a popup going this distro is NO longer supported please upgrade like now.
[15:50] <superfly> drubin: not as far as I know
[15:54] <drubin> that is silly
[15:54] <drubin> just had a guy ask questions about intepid
[15:54] <drubin> he didn't know it was end of life ;/
[15:55] <drubin> but I guess even if there was a notification they wouldn't upgrade. If they didn't upgrade the security fixes or any thing
[16:17] <highvoltage> drubin: update manager does warn in newer versions, but I don't think it was in intrepid yet
[16:43] <drubin> highvoltage: Thanks :)
[17:04] <drubin> "Scheduled Delivery: 10-January-2011 " for "Ubuntu Banner"
[17:05] <drubin> I was >< that close to marking that email as spam :)
[17:05] <drubin> Maaz: tell maiatoday "Scheduled Delivery: 10-January-2011 " for "Ubuntu Banner"
[17:05] <Maaz> drubin: Okay, I'll tell maiatoday on freenode
[17:23] <Kilos> hi walterl happy new year
[17:50] <walterl> Kilos: thanks. same to you :)
[17:50] <Kilos> ty
[19:29] <inetpro> Maaz: coffee on
[19:29]  * Maaz puts the kettle on
[19:33] <Maaz> Coffee's ready for inetpro!
[19:34] <inetpro> Maaz: dankie ou maat
[19:34] <Maaz> inetpro: Excuse me?
[19:34] <inetpro> hmm...


[06:19] <thatgraemeguy> morning peoples
[06:26] <inetpro> goiedag thatgraemeguy
[06:26] <inetpro> and hi to all else
[06:26] <SilverCode> Obsidians ability to manage the jabber.co.za server makes me question how they manage to maintain regular servers
[06:28] <inetpro> Maaz_: is jabber.co.za up
[06:28] <Maaz_> inetpro: No, http://jabber.co.za/ is down (Server is not responding)
[06:29] <inetpro> oh oh!
[06:30] <inetpro> SilverCode: How long has it been down?
[06:31] <inetpro> I wonder how many people still use that
[06:31] <SilverCode> inetpro: about First noticed it yesterday morning. Not sure if it was down over the weekend as well
[06:32] <SilverCode> I know if at least 3 people that still use it :) I keep trying to get them to move over to Telegram, but trying to get people to move to a different IM platform is almost impossible
[06:33] <MaNI> because 10 other people also want them to move to a different IM platform
[06:33] <MaNI> people are sick of everyone wanting them to move to different IM platforms :P
[06:35] <inetpro> I guess the best way to force a change is to kill the server :-)
[06:35] <SilverCode> I can't help but think that is what Obsidian are trying to do with the Jabber server
[06:35] <SilverCode> heck, you can't even register accounts on jabber.org anymore
[06:36] <SilverCode> "June 25, 2013: We have temporarily disabled account registration" - Jabber.org
[06:37] <inetpro> oh that looks very temporary
[06:37] <SilverCode> Jabber is dead, but these 3 people are clinging on to it for dear life and no matter how hard I try they refuse to move to anything else
[06:39] <inetpro> really sad, jabber was good for us long before most other IM technologies emerged
[06:41] <inetpro> of course we've always had talk, write and other commands long before that
[06:41] <jerit> the hell are you guys doing up so damn early?
[06:41] <inetpro> sorry jerit
[06:42] <jerit> meh my dog woke me up at 5:30 and wouldn't shut up so I was up around 2 hours ago already
[06:42] <jerit> I don't wanna be cranky all day but unless I make up some sleep somewhere I don't see this changing
[06:43] <inetpro> almost thought we woke you up ;-)
[06:56] <andrewlsd> I'm a fan of jabber. :-)
[06:59] <jerit> I remember dad used jabber when he was working for HP
[07:23] <MaNI> jabber was a good concept, -open- protocol that other people can extend, instead of every person reworking their own client
[07:23] <MaNI> if people had embraced that then I could message people regardless of what client they are on - instead of needing 20 different clients
[07:24] <MaNI> too bad they didn't
[08:00] <Kilos> hi inetpro Cryterion chesedo ludo MaNI thatgraemeguy zquish102 and others
[08:02] <inetpro> wb Kilos
[08:02] <Kilos> ty inetpro
[08:02] <Kilos> hoe gaan dit daar boetie
[08:04] <inetpro> good, good and yourself oom Kilos?
[08:04] <Kilos> goed dankie
[08:25] <inetpro> SilverCode: $ nc -z -v jabber.co.za 5222
[08:25] <inetpro> Connection to jabber.co.za 5222 port [tcp/xmpp-client] succeeded!
[08:33] <inetpro> SilverCode: is it working now?
[08:59] <SilverCode> inetpro: yup, looks like it is working again
[09:07] <chesedo> hi Kilos thatgraemeguy SilverCode inetpro Maaz_ MaNI jerit andrewlsd and all others
[09:08] <MaNI> hi
[09:08]  * chesedo thought Maaz_ would pick that up... should have listed him first maybe
[09:09] <inetpro> SilverCode: next time just tweet the guys at @obsidianza and they'll get it up in a jiffy
[09:09] <inetpro> it's a legacy system after all
[09:10] <inetpro> that's if you do the twitter thing
[09:10] <inetpro> hi chesedo
[09:11] <inetpro> chesedo: you have to talk to Maaz_ directly
[09:17] <chesedo> inetpro: ok, ty
[09:17] <chesedo> oh inetpro, did you get my message yesterday?
[09:18] <inetpro> chesedo: oh my, yes
[09:19] <inetpro> let me try again to add him
[09:19] <inetpro> not sure if I can
[09:44] <Maaz_> Note that we have a meeting here this evening at 20:30 SAST
[09:45] <inetpro> ah, something is working
[09:48] <inetpro> that's better as well
[10:03]  * Maaz I feel so much better now
[10:03]  * inetpro stops playing
[10:05] <inetpro> the bot tells me "I don't know who andrewlsd is"
[10:16] <Kilos> Maaz seen andrewlsd
[10:16] <Maaz> Kilos: andrewlsd was last seen 3 hours, 19 minutes and 2 seconds ago in #ubuntu-za on freenode [2016-10-25 08:56:58 SAST], and has been online on freenode since 2016-10-25 01:39:14 SAST
[10:40] <Kilos> i crash now guys, have a good day and a successful meeting. see you tomorrow
[11:01] <andrewlsd> Maaz: create account mciverza
[11:01] <Maaz> andrewlsd: Alrighty
[13:31] <pavlushka> Hey paddatrapper :)
[13:45] <paddatrapper> Hey pavlushka
[13:45] <paddatrapper> How goes it?
[13:50] <jerit> haircut and short pants really refreshes :3
[13:50] <jerit> goddamn its hot
[13:56] <pavlushka> paddatrapper: so far so good :)
[17:17] <inetpro> maaz: permissions for mciverza
[17:17] <Maaz> inetpro: Permissions: +chairmeeting
[17:17] <inetpro> mciverza: it should work now
[17:38] <chesedo> inetpro: ty
[17:38] <inetpro> I will unfortunately no
[17:38] <inetpro> oops...
[17:39] <inetpro> I will unfortunately not be in the meeting
[17:39] <chesedo> mciverza: when you can, will you run a test run at #ubuntu-afr?
[17:39] <chesedo> inetpro: ok
[17:39] <inetpro> have a power failure and quickly running out of battery on the mobile as well
[17:41] <chesedo> ouch... general outage
[17:42] <chesedo> *?
[17:43] <inetpro> looks like our transformer is blown today
[17:45] <tumbleweed> did it make a nice bang?
[17:45] <tumbleweed> those things can pop quite impressively
[17:49] <inetpro> have to go... enjoy the meeting guys
[17:49] <inetpro> good night
[17:49] <chesedo> night inetpro, hope you get it restored soon
[18:12] <mciverza> I am online
[18:16] <mciverza> Maaz: Agenda for tonight's meeting is at https://wiki.ubuntu.com/ZATeam/Meetings/20161025
[18:16] <Maaz> mciverza: Got it
[18:25] <andrewlsd> Five minute heads-up before tonights #ubuntu-za meeting here.
[18:29]  * chesedo is ready
[18:29] <andrewlsd> 1 minute to meeting
[18:30] <andrewlsd> Maaz: start meeting about Ubuntu Monthly Meeting - October 2016
[18:30]  * Maaz gets out his memo-pad and cracks his knuckles
[18:30] <andrewlsd> Maaz: I am Andrew Mac
[18:30] <Maaz> andrewlsd: Yessir
[18:31] <chesedo> Maaz: I am Pieter Engelbrecht
[18:31] <Maaz> chesedo: Alrighty
[18:31] <andrewlsd> Maaz: topic Welcoming and Introduction
[18:31] <Maaz> Current Topic: Welcoming and Introduction
[18:31] <chesedo> superfly Cryterion  jerit paddatrapper SilverCode thatgraemeguy meeting time
[18:32] <paddatrapper> Thanks chesedo
[18:32] <andrewlsd> Thank you all for being here. Feel free to continue your  "I am" introductions.
[18:32] <paddatrapper> Maaz: I am Kyle Robbertze
[18:32] <Maaz> paddatrapper: Righto
[18:33] <andrewlsd> The agenda for today is at https://wiki.ubuntu.com/ZATeam/Meetings/20161025
[18:33] <andrewlsd> Are there any additions that anyone would like to make to it?
[18:34] <chesedo> andrewlsd: i'm good with it
[18:34] <paddatrapper> Lgtm
[18:34] <andrewlsd> aah.
[18:34] <andrewlsd> Maaz: agreed All happy with agenda
[18:34] <Maaz> Agreed: All happy with agenda
[18:35] <andrewlsd> Maaz: topic Review minutes of previous meeting
[18:35] <Maaz> Current Topic: Review minutes of previous meeting
[18:35] <andrewlsd> The minutes of the previous meeting (20160927) are at https://wiki.ubuntu.com/ZATeam/Meetings/20160927#Summary
[18:37] <andrewlsd> Can I have a proposal and a second to accept the previous minutes.
[18:37] <andrewlsd> e.g paddatrapper / chesedo
[18:38] <paddatrapper> Am I missing something, but are there no minutes there...? I only see an agenda
[18:38] <andrewlsd> aah.
[18:38] <chesedo> andrewlsd: i forgot that we did not have a meeting in sept, but also do not have an issue with Aug's...
[18:38] <chesedo> so all good with me
[18:38] <paddatrapper> Also no issue with Aug's, so second chesedo
[18:39] <andrewlsd> In which case, correction, the minutes for the previous meeting are at https://wiki.ubuntu.com/ZATeam/Meetings/20160823
[18:40] <andrewlsd> Maaz: agreed All happy with previous minutes
[18:40] <Maaz> Agreed: All happy with previous minutes
[18:40] <andrewlsd> Maaz: topic Plans for 2016
[18:40] <Maaz> Current Topic: Plans for 2016
[18:41] <andrewlsd> Is there any news on tareq, magespawn and Kapanda's membership applications?
[18:41] <paddatrapper> I haven't heard anything
[18:42] <chesedo> magesawn's wiki page is still empty (waiting for him)...
[18:42] <andrewlsd> Thanks chesedo.
[18:42] <chesedo> Kapanda's just in idea stage I think...
[18:43] <chesedo> and Kilos will(may) know about tareq'a
[18:43] <andrewlsd> We will probably need to wait for oom Kilos and some other regulars to get any further feedback.
[18:43] <andrewlsd> (mis-timed that one)
[18:43] <chesedo> yip, seems so
[18:44] <andrewlsd> Are there any other folks that we know of that need assistance with ubuntu IDs or the Code of Conduct?
[18:44]  * chesedo does not at this time
[18:44]  * andrewlsd does not either.
[18:45] <andrewlsd> Moving right along then ...
[18:45]  * paddatrapper neither
[18:45] <andrewlsd> Maaz: topic Events
[18:45] <Maaz> Current Topic: Events
[18:46] <andrewlsd> Are there any upcoming Ubuntu or open source related events that anyone would like to mention?
[18:46] <paddatrapper> There's a Debian Miniconf in Cambridge happening second week of November, but I think that's a little unrelated
[18:46] <chesedo> I received something on the sulug maillist, but forgot it now
[18:46]  * chesedo goes to look
[18:47] <andrewlsd> *whatis sulug*
[18:48] <chesedo> stellenbosh university linux user group
[18:49]  * andrewlsd is now enlightened
[18:49]  * paddatrapper wishes UCT's LUG was more active
[18:49]  * andrewlsd has been to a couple of CLUG meetings.
[18:49] <paddatrapper> CLUG is active, which is nice
[18:50] <andrewlsd> ... a nice CLUG meeting included an IPA tasting (ale, not the Identity Management foss project)
[18:50] <chesedo> paddatrapper: they had a (stirring) discussion about it last month or so, and became quite active afterwards...
[18:51] <chesedo> Here is that event: DevOps happening 7 & 8 Nov in CPT -> https://devops.capetown/devopsdays/
[18:51] <andrewlsd> Aah, yes.
[18:51] <paddatrapper> andrewlsd: Of course, no beer and the CLUG hasn't met
[18:51] <andrewlsd> Devops Days.
[18:51] <andrewlsd> thanks chesedo for the info and link.
[18:52] <andrewlsd> moving along in the agenda.
[18:52] <andrewlsd> shall we proceed to "Miscellaneous"
[18:52] <andrewlsd> ?
[18:52] <paddatrapper> Yup
[18:52] <chesedo> yip
[18:52] <andrewlsd> Maaz: topic Miscellaneous
[18:52] <Maaz> Current Topic: Miscellaneous
[18:53] <andrewlsd> Any misc bits n pieces to share?
[18:53] <chesedo> nothing new...
[18:54] <paddatrapper> Not sure if we covered it in a previous meeting, but PyConZA happened in CT 3 weeks ago. It went well with about double the attendees than the previous year
[18:54] <andrewlsd> Interesting news this week has been that the DDOS that took out dyn DNS and much of amazon, etc was largely due to exploited IoT devices such as consumer IP cameras/securityPVRs
[18:54] <chesedo> oh our Ubuntu For Hope site has been completed (needs some extra mods), just waiting for kmf to put it on his servers
[18:54] <andrewlsd> excellent paddatrapper.
[18:54] <andrewlsd> chesedo: looking forward to seeing the site go live
[18:54] <paddatrapper> Dirty COW means everyone should patch their kernels
[18:55] <chesedo> paddatrapper: you organised there as well right?
[18:55] <paddatrapper> chesedo: Yeah, I was responsible for organising the video equipment again
[18:55] <andrewlsd> live patching FTW, now available for Ubuntu via Canonical
[18:55] <chesedo> more on dirty cow for those interested -> https://dirtycow.ninja/ http://www.zdnet.com/article/the-dirty-cow-linux-security-bug-moos/
[18:56] <andrewlsd> Ty, useful link.
[18:56] <paddatrapper> .ninja ... First time I've seen that! Lol
[18:57] <andrewlsd> all righty then ....
[18:57] <chesedo> all right
[18:58] <andrewlsd> Maaz: topic Elect chairperson for next meeting
[18:58] <Maaz> Current Topic: Elect chairperson for next meeting
[18:58] <chesedo> andrewlsd: you can do it again if you are up to it?
[18:58] <andrewlsd> chesedo or paddatrapper, either of you keen to chair November's meeting?
[18:59] <chesedo> else i'm available (for backup too)
[18:59] <paddatrapper> What date in November is it, 25th? If so I don't see why not
[18:59] <andrewlsd> I can do so. I was just about to ask which date 22 or 25
[18:59] <chesedo> paddatrapper: 22nd
[18:59] <chesedo> andrewlsd: ^^
[18:59] <andrewlsd> (I meant 22 or 29)
[18:59] <andrewlsd> 22nd.
[18:59] <paddatrapper> Ok then I may or may not be here - in the middle of exams, so probably not a good idea to put my hand up
[19:00] <andrewlsd> Ok, paddatrapper can volunteer for Dec or Jan. Not sure if we have a meeting in Dec.
[19:00] <andrewlsd> ... but Jan should be good.
[19:00] <paddatrapper> Cool
[19:00] <chesedo> lol, paddatrapper jan would be open...
[19:01] <andrewlsd> I'll do the next one if that is OK with you, chesedo?
[19:01] <chesedo> andrewlsd: ok
[19:01] <andrewlsd> Maaz: agreed andrewlsd to chair next meeting
[19:01] <Maaz> Agreed: andrewlsd to chair next meeting
[19:01] <andrewlsd> Maaz: topic Next meeting
[19:01] <Maaz> Current Topic: Next meeting
[19:02] <andrewlsd> Is it agreed that the next meeting will be 22 Nov at 20h30 SAST ?
[19:02] <paddatrapper> Yup
[19:02] <chesedo> yip
[19:03] <andrewlsd> Maaz: agreed Next meeting is 22 November 2016 @ 20:30
[19:03] <Maaz> Agreed: Next meeting is 22 November 2016 @ 20:30
[19:03] <andrewlsd> Maaz: end meeting
[19:03] <Maaz> Meeting Ended
[19:03] <Maaz> Minutes available at json: http://maaz.mene.za.net/logs/meetings/freenode-%23ubuntu-za/2016-10-25-18-30-38.json :: txt: http://maaz.mene.za.net/logs/meetings/freenode-%23ubuntu-za/2016-10-25-18-30-38.txt :: html: http://maaz.mene.za.net/logs/meetings/freenode-%23ubuntu-za/2016-10-25-18-30-38.html
[19:03] <chesedo> andrewlsd: thanks for chairing tonight
[19:03] <andrewlsd> :-) pleasure
[19:03] <paddatrapper> Thanks andrewlsd
[19:03] <andrewlsd> Thanks paddatrapper and chesedo
[19:03] <chesedo> it went well and smoothly
[19:04]  * andrewlsd goes off to edit wiki with the minutes.
[19:05] <chesedo> Maaz: Agenda for tonight's meeting
[19:05] <Maaz> chesedo: Agenda for tonight's meeting is at https://wiki.ubuntu.com/ZATeam/Meetings/20161025
[19:05] <chesedo> Maaz: forget Agenda for tonight's meeting
[19:05] <Maaz> chesedo: Alrighty
[19:05] <chesedo> Maaz: last minutes is <reply> Minutes available at json: http://maaz.mene.za.net/logs/meetings/freenode-%23ubuntu-za/2016-10-25-18-30-38.json :: txt: http://maaz.mene.za.net/logs/meetings/freenode-%23ubuntu-za/2016-10-25-18-30-38.txt :: html: http://maaz.mene.za.net/logs/meetings/freenode-%23ubuntu-za/2016-10-25-18-30-38.html
[19:05] <Maaz> chesedo: Got it
[19:05] <chesedo> Maaz: last minutes
[19:05] <Maaz> Minutes available at json: http://maaz.mene.za.net/logs/meetings/freenode-%23ubuntu-za/2016-10-25-18-30-38.json :: txt: http://maaz.mene.za.net/logs/meetings/freenode-%23ubuntu-za/2016-10-25-18-30-38.txt :: html: http://maaz.mene.za.net/logs/meetings/freenode-%23ubuntu-za/2016-10-25-18-30-38.html
[19:06] <chesedo> thanks for the wiki edit andrewlsd
[19:06] <andrewlsd> Wiki page updated at https://wiki.ubuntu.com/ZATeam/Meetings/20161025
[19:07] <andrewlsd> G'night all
[19:07] <paddatrapper> night andrewlsd
[19:08] <andrewlsd> ciao paddatrapper chesedo
[19:10] <chesedo> night paddatrapper andrewlsd
[19:12] <paddatrapper> night
[21:14] <inetpro> andrewlsd: thanks for taking the hot seat today
[21:14]  * inetpro has power again
[21:17] <inetpro> chesedo: remind me to send an invite to the meeting on Twitter next time


[00:07] <zmoylan-pi> happy new year o/
[00:07] <daftykins> happy new year sir
[00:07] <daftykins> i thought Ireland had a time of its' own :D
[00:09] <zmoylan-pi> well we were off set in dublin by 25 minutes until 1916... https://www.buzz.ie/news/dublin-lost-its-own-time-zone-after-the-1916-rising-39579
[00:09] <zmoylan-pi> if you're heading to belfast just set your watches back 300 years... :-P
[00:09] <daftykins> well well, war going on and they found time to quibble... time
[09:10] <brobostigon> morning boys and girls.
[09:59] <zmoylan-pi> o/
[10:00] <brobostigon> o/


[13:07] -SwissBot:#xubuntu-devel- ::platform:: seed probert (needed by subiquity) @ http://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=fb93501a65eef2e90192d7a16845c6bdee4f99cc (by Paride Legovini)


[19:00] <tormod> hyperair, I saw your new mesa flag in git. which changes are needed in the packaging? I can add it to x-updates
[19:01] <hyperair> tormod: add --with-dri-searchdir=/usr/lib/dri:/usr/lib/dri$(DEB_HOST_GNU_TYPE) to configure
[19:02] <hyperair> er wait
[19:02] <hyperair> tormod: add --with-dri-searchdir=/usr/lib/dri:/usr/lib/dri/$(DEB_HOST_GNU_TYPE) to configure
[19:02] <hyperair> i'll come up with a debdiff for mesa
[19:02] <tormod> hyperair, ok will do
[19:03] <hyperair> tormod: by the way, it seems that one of the patches in mesa hits on symlinks and comes up with issues when quilt popping
[19:03] <tormod> hyperair, yes if you run quilt on your git tree it fails
[19:04] <hyperair> tormod: no, i'm talking about an apt-get source'd directory
[19:04] <tormod> if you unpack an orig.tar.gz the links have been dereferenced
[19:04] <tormod> oh still?
[19:04] <hyperair> yes
[19:04] <hyperair> and sorry i got the config flag wrong
[19:04] <hyperair> it's --with-dri-searchpath
[19:06] <tormod> hyperair, which mesa patch?
[19:07] <hyperair> tormod: 35506dec6734a1ae777dc16981cb19e514f41897
[19:08] <tormod> oh I see I was thinking the other way, a Ubuntu patch on git. but you have git patch on orig.tar.gz...
[19:10] <tormod> that's your git patch, I don't see where it hits any symlink?
[19:11] <hyperair> tormod: oh sorry. you meant the quilt issue?
[19:11] <tormod> yes
[19:11] <hyperair> it's the one that hits on the radeon symlinks
[19:11] <hyperair> r{2,3,6}00/radeon_dma.c
[19:11] <hyperair> they all point to "../radeon/radeon_dma.c"
[19:11] <tormod> (I told you had seen your mesa patch in git :) )
[19:11] <tormod> yes I know
[19:12] <tormod> but that's fine if you're using orig.tar.gz
[19:12] <hyperair> my bad. my text-to-speech converter in my brain isn't working well
[19:12] <hyperair> and yes i'm using orig.tar.gz
[19:12] <hyperair> the problem is when you quilt push -a to work on a patch and then quilt pop -a
[19:12] <hyperair> the next debuild fails because of unrepresentable errors
[19:13] <tormod> which patch was that, I can not find it (although I remember spending hours on it=
[19:13] <tormod> but there are no symlinks in the unpacked orig.tar.gz right?
[19:15] <hyperair> there are.
[19:15] <hyperair> at least, you can't put links inside diffs, and it was already there after i apt-get source'd it
[19:15] <hyperair> couldn't you just quilt remove the said files?
[19:15] <hyperair> it'd be so much simpler =\
[19:28] <tormod> oh yes you are right, there are links
[19:29] <tormod> you talking about 109_revert-dma-reuse.patch ?
[19:29] <tormod> it's gone upstream so I don't use it
[19:32] <tormod> I think quilt is not symlink aware, so if you use quilt to make the patch, it adds hunks for each link + original
[19:32] <tormod> but it works on the builder, so there is something I don't get
[19:33] <tormod> are packages unpacked differently on the builder vs apt-get source?
[19:37] <hyperair> tormod: quilt can push -a once, and pop -a once. subsequent attempts will afil.
[19:37] <hyperair> fail*
[19:38] <hyperair> since it only pushes all the way once for building, it works fine
[19:38] <hyperair> also, quilt tracks each change by file.
[19:38] <hyperair> i.e. only if you've quilt add-ed before you edited your file
[19:39] <hyperair> symlinks shouldn't make a difference unless you quilt add-ed your symlink, (which is what appears to have gone wrong here)
[19:40] <hyperair> tormod: i'd like to get this fix into karmic as a SRU. i'd put karmic-proposed in the changelog, right?
[19:41] <tormod> yes
[22:56] <jcristau> wgrant: re your question earlier on #u-devel, the debian archive already started accepting v3 source packages
[22:58] <wgrant> jcristau: I know. Just wondering when it will actually be allowed.
[23:02] <jcristau> http://lists.debian.org/debian-devel-changes/2009/10/msg02608.html
[23:02] <jcristau> so, now.
[23:53] <wgrant> jcristau: ... fuck.


[00:00] <racarr> mm
[00:00] <kdub> like,  its common  for the software buttons on the nexus4 to be an overlay layer
[00:00] <kdub> i guess we don't have to solve the problem now
[00:00] <racarr> no it's interesting though
[00:00] <racarr> I'minterested in starting to rework the rendering
[00:00] <racarr> to explore the shell rendering effects, etc.
[00:00] <racarr> might be related.
[00:01] <kdub> yeah... its hard to abstract that
[00:01] <kdub> 'this layer is quicker, but... you can't use a shader on it'
[00:02] <racarr> Mm
[00:02] <racarr> there are sort of two approaches to the shell and how it interacts with rendering and effects
[00:02] <racarr> 1. Is the shell replaces the compositor, renderer, etc, does what it wants
[00:03] <racarr> and 2. is the surface stack functions more as a scene graph and the shell is declarative about what it wants
[00:03] <racarr> I think this functions as an argument for 2, where the shell would create an "overlay" layer inside the scenegraph (beefed up surface stack)
[00:03] <racarr> and insert say, the software button surface in it
[00:03] <kdub> well, we could do a mix somehow
[00:04] <racarr> then the graphics backend is free to figure out
[00:04] <racarr> Hey, can overlay this with HWC
[00:04] <racarr> then all of a sudden it has a blur shader
[00:04] <racarr> and the graphics backend can render it however
[00:04] <kdub> right
[00:04] <kdub> i think that dynamism is what we should aim for
[00:04] <kdub> plus if the behavior is abstracted well
[00:04] <kdub> thats a big win too
[00:05] <kdub> like, thats actually how composition on the nexus4 works
[00:05] <kdub> within the hwc
[00:05] <racarr> mm
[00:06] <racarr> We should have layers in the surface stack
[00:06] <racarr> lets introduce them for stacking
[00:06] <racarr> and add fancy rendering later
[00:06] <racarr> (maybe try and make a demo shell that implements the unity blur between two layers)
[00:07] <racarr> Hehe that's tricky to express
[00:09] <kdub> racarr, i mean, the quick way is just override the default gl_renderer.cpp
[00:09] <kdub> but expressing a good model for all the different effects is tricky
[00:10] <racarr> one possible way to express blur is like
[00:10] <racarr> there are two layers, say the app layer and the shell layer and we want to render the shell layer with a blur effect of the app layer
[00:13] <racarr> so the shell, does something like shell_layer->add_texture_sampler((Renderable)appLayer, "textureSamplerName")
[00:13] <racarr> then shell_layer->add_fragment_shader(shader source)
[00:13] <racarr> highly idealized of course ;)
[00:14] <racarr> the renderer
[00:15] <racarr> does a prepass on the graph, to resolve dependencies, i.e. it sees the shell layer references the app layer as a texture so we need to render it to an fbo
[00:15] <racarr> or maybe there are only 4 renderables in total and we have a bunch of texture units so we render it all with one massive multitexture
[00:15] <racarr> *hand wavy*
[00:15] <racarr> thats my idealized extreme of number 2
[00:22] <RAOF> I hate all technology
[00:56] <RAOF> robert_ancell: Any better luck with XMir today?
[01:30] <robert_ancell> RAOF, just about to try
[01:30] <robert_ancell> brb
[01:39] <robert_ancell> RAOF, http://paste.ubuntu.com/5597212/ - is that it getting confused with nouveau?
[01:40] <robert_ancell> And if I remove the nouveau driver Mir wont even start
[01:42] <RAOF> Wha?
[01:43] <robert_ancell> RAOF, drmOpen seems to give "Operation not permitted"
[01:43] <RAOF> Well, it's not meant to be drmOpening at all.
[01:45] <RAOF> robert_ancell: Could you change lightdm so that it passes "-verbose 7" to X, and then give me the lightdm log? That should also catch things that X's backtrace handler doesn't, like missing symbols.
[01:45] <robert_ancell> RAOF, that should have been -vebose 7
[01:49] <RAOF> robert_ancell: Ah, ok.  Bah!
[01:51] <RAOF> I'm heading out to lunch soon. I'll see what I can wrangle when I get back.
[01:51] <robert_ancell> RAOF, nope
[05:01] <racarr> If anyone still around wants to review
[05:02] <racarr> demo-shell again, alans needs fixing was covered by weakify-event-filters (and Alan agreed that was good in the morning)
[05:02] <racarr> and alf is on vacation so it just need one more +1
[05:02] <RAOF> robert_ancell: I think I've fixed your nouveau problem in the daily build that's happening now.
[05:02] <robert_ancell> RAOF, yay!
[05:02] <racarr> anyway if we can land it or iterate in the next 2 hours or so before I go to sleep
[05:02] <racarr> I can propose software cursor :)
[05:03] <racarr> Also happy afternoon :)
[05:03] <robert_ancell> racarr, if you think you've fixed the issues raised by Alan/Alexandros just land it
[05:16] <racarr> robert_ancell: Cheers :) will land and propose software cursor soon
[05:18] <robert_ancell> racarr, regarding https://code.launchpad.net/~vanvugt/mir/clarify-c-types/+merge/160294. Is c_types supposed  to refer to "C language types"?
[05:31] <RAOF> Hah! And now that we've fixed the drivers to not load we run into xserver bugs.
[05:44] <racarr> robert_ancell: It's supposed to refer to C language types
[05:44] <racarr> it is used in the server by the native display but this merge seems to work because mesa/native_display.h is included
[05:44] <racarr> includes it
[05:44] <racarr> even if the src/server/* file removed it
[05:46] <duflu> racarr: Yeah there's still some conflict there with common.h. We need to resolve the differences between the two more clearly, somehow
[05:47] <duflu> I think mentioning "c_" is pointless, because all the toolkit headers are C-compatible
[05:50] <racarr> types.h :)
[05:50] <racarr> it was introduced just right before mir_toolkit so it was weird
[05:52] <racarr> oh god reminder email
[05:52] <racarr> I forgot the difference between tuesday and wednesday
[05:58] <duflu> racarr: Right, but common.h is also just for C-types. But wider-used simple types like enums
[05:58] <tvoss> racarr, robert_ancell duflu do we do the weekly?
[05:58] <duflu> The tricky part is that some types like callbacks are too client-specific to go in common.h (visible to the server)
[05:58] <robert_ancell> tvoss, sure. I'm looking after my daughter so I'll have to see how it goes but I'll attempt it
[05:59] <tvoss> robert_ancell, cool
[05:59] <tvoss> robert_ancell, grabbing headset then
[06:00] <robert_ancell> RAOF, ^
[06:00] <RAOF> robert_ancell: Yeah, just hunting for the link.
[06:02] <robert_ancell> racarr, ping?
[06:04] <robert_ancell> hikiko, connection problems?
[06:05] <racarr> Joining!
[06:07] <hikiko> yes robert_ancell
[06:07] <hikiko> trying to fix it
[06:07] <robert_ancell> hikiko, ok, we're mostly saying we'll just meet in Oakland
[06:09] <duflu> No one wants to talk much this week
[06:10] <hikiko> :)
[06:14] <hikiko> I entered!! but the hangout is done I guess
[06:14] <hikiko> I am the only one there :)
[06:15] <hikiko> fail!!
[06:15] <duflu> hikiko: Sorry. Not having any problems to discuss is good I guess.
[06:16] <hikiko> haha, true :D
[06:58] <duflu> Oh dear. I failed to read the docs correctly on our pixel format semantics. Time to rewrite :P
[07:49] <RAOF> Man, I wonder if this xserver code has ever actually been executed?
[07:49] <RAOF> mlankhorst: xf86DeleteDriver just doesn't really work, does it? :)
[08:00]  * mlankhorst has no idea
[08:00] <RAOF> Spoilers: it doesn't.
[08:00] <RAOF> Well, it does unless you're using it in a situation when you'd want to use it.
[08:01]  * mlankhorst busy rebasing the kernel patches
[08:02] <RAOF> Does one of them allow me to get the size of a dma-buf out of its fd? :)
[08:02] <mlankhorst> oh I forgot
[08:03] <RAOF> I'm happy to get some more kernel experience if you don't want to write that patch.
[08:03] <mlankhorst> hehe I want to write it, it was just that I had to rework some other patches and I was resenting it so much I postponed all my kernel work a bit
[08:04]  * RAOF goes to bathe Zoë
[08:12]  * duflu wonders if RAOF named Zoë before, after, or because of his discovery of key composition ;)
[08:13] <duflu> Aaa Mir, why can't you tell red from blue? :(
[08:25] <RAOF> Wellllll after :P
[08:25] <alan_g> Good morning!
[08:25] <duflu> Good afternoon- almost end of the week
[08:26] <alan_g> ;)
[08:26] <duflu> I'm panicking about lack of prep and need to run off in a while
[08:31] <duflu> Happy Raring Eve too
[08:31] <tvoss> duflu, Happy Raring Eve
[08:32]  * alan_g checks he has the t-shirt
[09:23]  * RAOF wins the battle against Xorg
[09:23] <tvoss> RAOF, \o/
[13:02]  * mlankhorst checks RAOF for scars
[15:07] <kdub> hello! status, bugs, worked on display logging
[15:09] <alan_g> afternoon, got laptop up to date, reviewing and updating MP. Thinking about ownership issues.
[15:12] <kgunn> kdub: hwc1.0...awesome!
[15:16] <tvoss> kdub, \o/
[15:17] <kdub> yay
[16:42] <racarr> /win goto 10
[16:42] <racarr> ...:)
[16:43] <alan_g> Hello there
[16:47] <racarr> Hello :)
[17:05] <alan_g> Goodbye!
[19:35] <racarr> I thought I broke the Qt mapping of the tab character
[19:35] <racarr> but really I forgot I was in demo shell
[19:35] <racarr> and it eats tab events
[19:35] <racarr> ...
[19:48] <racarr> Got lots of little quirks in Qt key input worked out
[20:09] <bschaefer> racarr, cool :)
[20:09] <bschaefer> racarr, soo, i added some more event defines in a branch here:
[20:09] <bschaefer> https://code.launchpad.net/~brandontschaefer/mir/more-event-defines/+merge/160756
[20:10] <bschaefer> I saw your comment about waiting till next week, but I needed the MirMotionButton and MirKeyMeta for some SDL stuff so I went ahead and did that
[20:16] <racarr> bschaefer: Haha! I was just getting ready to add the mir key meta after lunch
[20:16] <racarr> so perfect!
[20:16] <racarr> now lunch though, will review after
[20:17] <bschaefer> haha nice :), im just about to go on lunch
[21:08] <racarr> back
[21:11] <bschaefer> soo, i just started looking into this missing button state for a mouse release...and whats weird is the mir_motion_action_hover_exit
[21:11] <bschaefer> has the correct button state
[21:11] <bschaefer> another thing thats weird is clicking in general generates a hover exit/enter event as well
[21:12] <bschaefer> so the events go like this when you press: HoverExit (correct button state), MousePressed (correct button state), Mouse Released (incorrect button state)
[21:12] <bschaefer> so im thinking that hover exit steals it
[21:18] <bschaefer> also thanks for the review
[21:33] <racarr> hmm
[21:33] <racarr> well click/release does enter/exit hovering
[21:33] <racarr> kind of weird though
[21:37] <bschaefer> indeed, i need to track down where the conversion from an android event -> mir event happens...possibly something in there?
[21:49] <bschaefer> err, that seems to be done in the lexicon, but that would mean android is giving odd states? interesting..
[21:49] <racarr> bschaefer: I guess this is just how the android input works perhaps
[21:49] <racarr> it does make sense somehow, when the button is released the button state is 0 ;)
[21:50] <bschaefer> racarr, hmm perhaps, the problem is theres no look ahead when receiving events
[21:50] <bschaefer> ie, press button 1 down, press button 2 down, release button 1, which button was released?
[21:51] <bschaefer> I also don't know why you would need to know the button state on a hover exit :)
[22:04] <racarr> bschaefer: So...it seems to be as intended
[22:05] <bschaefer> racarr, whooo, umm I just got something weird...um
[22:05] <bschaefer> racarr, is the lexicon function thread safe?
[22:05] <racarr> if you look in InputReader.cpp around l2400
[22:05] <racarr> is whre it begins sort of
[22:05] <racarr> It should be right! It doesn't access any
[22:06] <racarr> data or anything besides its arguments
[22:07] <bschaefer> racarr, so heres a sample of my log:
[22:07] <bschaefer> http://paste.ubuntu.com/5599532/
[22:07] <bschaefer> and the print statement im using in void mia::Lexicon::translate(const droidinput::InputEvent *android_event, MirEvent &mir_event)
[22:08] <bschaefer> it does a static cast but the umm, android event seems to be off, as it should align up
[22:08] <bschaefer> racarr, ignore that...
[22:08]  * bschaefer put the print statement in the wrong place
[22:08] <bschaefer> :)
[22:09] <racarr> story of my life haha :)
[22:09] <bschaefer> haha, I put it before the mir_event was getting assigned so it had the last values it had in it hahaha
[22:09] <bschaefer> :)
[22:10] <racarr> I think this is as intended by android, and the idea is just, you receive an event and see the new button state and do what is appropriate
[22:10] <bschaefer> right, SDL being old doens't do things like this
[22:10] <racarr> but if SDL apps aren't happy with that (i.e. need an event this button was released)
[22:10] <racarr> I think you should just maintain
[22:10] <racarr> a simple mapping
[22:10] <racarr> for now
[22:10] <bschaefer> well, yeah Ill have to do a map
[22:10] <bschaefer> yeah
[22:10] <racarr> Im not sure if the android way is good or not but
[22:10]  * bschaefer was trying to avoid ambiguous events
[22:11] <bschaefer> well to me it makes for an ambiguous event, which means we have to do more book keeping :)
[22:12] <bschaefer> but android is more a of touch environment, so maybe thats a reason
[22:12]  * bschaefer makes a workaroud
[22:13] <racarr> bschaefer: You should propose the test anyway, just with the passing semantics
[22:13] <racarr> so we at least have something that says how it works
[22:13] <bschaefer> alright, I still need to fix a mocking problem, complaining about something
[22:13] <bschaefer> even if I remove the check if state ==0
[22:14] <bschaefer> racarr, Ill try and get that out today
[22:15] <racarr> great
[22:23] <racarr> ok the one thing keeping me from using mir as a terminal multiplexor now
[22:23] <racarr> is input goes through to the VT :p
[22:23] <racarr> so ctrl+c
[22:24] <bschaefer> haha
[22:25] <bschaefer> racarr, also, turns out if you do MouseDown 1, then try MouseDown 2 its blocked by the mouse Down 1
[22:25] <bschaefer> sooo I suppose thats no longer a problem, so I just have to save the last used button state...still annoying :)
[22:35] <racarr>   struct termios terminal_attributes;
[22:35] <racarr>     tcgetattr(vt_fd, &terminal_attributes);
[22:35] <racarr>     cfmakeraw(&terminal_attributes);
[22:35] <racarr>     terminal_attributes.c_oflag |= OPOST | OCRNL;
[22:35] <racarr>     tcsetattr(vt_fd, TCSANOW, &terminal_attributes);
[22:35] <racarr> lol...
[22:35] <racarr> its like all the worst names in 5 lines
[22:35] <bschaefer> haha, are you really stealing the fd from the vt haha?
[22:35] <bschaefer> well that works
[22:36] <racarr> well I mean in the server
[22:37] <racarr> setting up the VT
[22:37] <racarr> the problem is I need the server not to respond to control sequences anymore :)
[22:37] <bschaefer> oo, I was thinking the tty for some reason
[22:38] <bschaefer> right, you don't want the server to die on a crtl+c :)
[22:40] <bschaefer> also for you enable input branch, with my change to trunk you'll need to change these: http://paste.ubuntu.com/5599384/
[22:40] <bschaefer> (very simple...)