[01:16] <nacc> jbicha: are you going to followup on php-imagick failure in debian/ubuntu something about SVG i guess
[01:31] <jbicha> nacc: it looks like Restriction: needs-recommends was accidentally dropped which is essential for the tests to pass, I'll contact the Debian maintainer
[01:42] <nacc> jbicha: thanks
[01:57] <jbicha> I'm curious about what changed in imagemagick recently so I looked at the git repository and there's all these commits where the commit message is just "..."
[01:57] <jbicha> http://git.imagemagick.org/repos/ImageMagick/commits/ImageMagick-6
[01:57] <nacc> jbicha: yeah ... upstream IM is terrible :)
[01:57] <nacc> they use git like a stream of consciousness, often with reverts and fully undocumented sequences of changes as individual commits.
[01:58] <sarnold> and unrelated changes checked in together
[01:58] <sarnold> and related changes checked in apart
[01:59] <mdeslaur> jbicha: you can go blind from looking at that, be careful
[02:00] <nacc> heh
[02:00] <jbicha> I started here: http://git.imagemagick.org/repos/ImageMagick/blob/ImageMagick-6/NEWS.txt
[02:00] <nacc> heh
[02:00] <mdeslaur> ARGH MY EYES
[02:00] <sarnold> heh
[02:00] <jbicha> but that was useless
[02:02] <jbicha> nacc: anyway, Debian is up to 8:6.9.7.4+dfsg-1 but I've no idea whether 6.9.7.4 is better than 6.9.7.0
[02:02] <mdeslaur> GIT revision what? http://git.imagemagick.org/repos/ImageMagick/commit/fc0fa2145cc6a4d3f4cf95b80ffcc1498eef4970
[02:03] <sarnold> doko: ARGH MY EYES
[02:03] <sarnold> doko: sorry, tab-misire. :(
[02:03] <Unit193> ...They do git worse than I do.
[02:04] <nacc> lol
[02:04] <nacc> jbicha: ah thanks for pointing that out -- let me see if i can get IM to migrate tmrw and then I'll look if it's worth updating. Probably for security team's sake it will be :)
[02:18] <krytarik> nacc: The newer one of those is supposed to also fix LP bug 1550210, btw.
[02:27] <nacc> krytarik: thanks
[03:18] <rnetocombr> 16.04.2 will be delayed again ? i was scheduling a install party in my school today.
[03:28] <Unit193> infinity: Hmm.  Did you not see the ping the other day?
[03:46] <nacc> krytarik: jbicha: fyi, i think if we can get php-imagick migrated, it will let imagemagick through (that's at least one of the blockers)
[08:48] <rbasak> tjaalton: did you conclude anything wrt. adcli?
[08:51] <tjaalton> rbasak: feel free to drop it
[08:52] <tjaalton> or demote to suggests
[08:53] <tjaalton> that's what I committed to debian git
[09:45] <fossfreedom_> andyrock: just returning your ping from yesterday
[09:48] <seb128> fossfreedom, I think he wanted to discuss the gnome-menus patch
[09:57] <fossfreedom_> seb128: ah - yes - we had a quick conversation last week - andyrock mentioned you were in fosdem - hope you enjoyed that!
[09:57] <seb128> I did thanks
[10:31] <andyrock> hey
[10:31] <andyrock> fossfreedom_: seb128 wanted to know which series you want to target
[10:32] <fossfreedom_> andyrock: patch is for zesty.  For our 16.04 and 16.10 users we are managing this via PPA
[11:30] <jbicha> nacc: php-imagick's autopkgtest fails on armhf :(
[11:38] <xnox> jbicha, kenvandine - could you please explain "* Have libgtk-3-dev depend on libcontent-hub-glib-dev, thanks Ken VanDine!" it makes no sense to me...
[11:39] <jbicha> xnox: the previous gtk3 update introduced a build-dependency on the content-hub, kenvandine reported that without adding that as a dependency of libgtk-3-dev, gtk3 apps were FTBFS
[11:39] <xnox> ah
[11:39] <xnox> ok
[11:40] <jbicha> gtk3 is stuck in zesty-proposed because content-hub isn't available on s390x and I'm not sure how that's going to be handled
[11:40] <infinity> Why isn't it?  Haven't we unwound the upstart mess yet?
[11:41] <xnox> infinity, in progress.
[11:41] <infinity> (And if not, ffs, why not?)
[11:41] <jbicha> content-hub > ubuntu-app-launch > upstart
[11:41] <xnox> tedg_, we need to build src:ubuntu-app-launch sans libupstart. or build gtk+3 sans mir.
[11:42] <xnox> tedg_, but i think having compile time conditionals "without upstart" is overdue for ubuntu-app-launch now.
[11:42] <infinity> xnox: The first half please.
[11:42] <infinity> On all arches.
[11:42] <infinity> I thought you were like two steps from removing upstart at the sprint. :P
[11:42] <infinity> Two very large steps, I guess.
[11:42] <xnox> infinity, we got closer at fosdem.
[11:43] <infinity> Speaking of touch things, who do I yell at for libhybris creeping its way onto every desktop?
[11:44] <infinity> Last I checked, about 0% of our users are on Android.
[11:48] <cult-> xnox: i added you to the bugreport
[11:48] <infinity> Aaaaand, today's update wants to pull in a bunch of -dev packages?
[11:49] <jbicha> infinity: bug 1662608, I think someone just needs to push the qtmir update through bileto
[11:50] <infinity> jbicha: Looks plausible indeed.
[12:34] <seb128> fossfreedom, andyrock, didn't you say that the new codebase that's going to be used in zesty isn't impacted by that bug though?
[12:34] <seb128> fossfreedom, andyrock, in any case I'm voting against a hack that's desktop specific, if there is a ref bug in the code that ought to be fixed, not workaround with a getenv hack
[12:37] <fossfreedom_> seb128: I honestly dont have any other way forward to fix this issue :(
[12:38] <seb128> fossfreedom, it's a bug, just needs somebody to look at it and fix it
[12:40] <fossfreedom_> to answer your previous question - zesty is affected in the same way as yakkety and xenial - gnome-menus code base looks to be virtually the same between the three series
[12:44] <fossfreedom_> seb128: I have no one in my team that can fix this.  I have called out previously to the community for programmers - but no joy
[12:46] <seb128> fossfreedom, the bug comments state "17.04 Ubuntu Budgie is going to be using v10.2.9 of budgie-desktop and hence will be affected by the issues raised."
[12:46] <seb128> so I missread
[12:47] <seb128> fossfreedom, in any case the workaround is wrong so need to keep looking for somebody who wants to fix the issue
[12:47] <fossfreedom_> andyrock: do you any bandwidth to help please?
[12:48] <andyrock> i'm pretty busy
[12:48] <andyrock> and without a bt I can't really see the issue
[12:51] <fossfreedom_> andyrock: this is an earlier backtrace when I was looking at this with upstream: http://paste.ubuntu.com/23346077/
[12:54] <fossfreedom_> the problem seem to wander around - memory corruption issues probably http://paste.ubuntu.com/23345306/ and http://paste.ubuntu.com/23345313/
[13:01] <fossfreedom_> andyrock: I know I am grasping at straws here ... could some-sort of lock be added at the beginning of the function that is only released once the 2 second delay function has finished ... maybe a re-entrant type issue where the function is called repeatedly very quickly?
[13:13] <andyrock> i don't think that's the problem
[13:14] <andyrock> but if you can try
[13:46] <rbasak> cpaelzer: I agree about changing the NEWS section, but I'm not sure how I should fix it since that is now published in Xenial.
[13:48] <rbasak> I suppose it's the same mess that we get from the changelog like the discussion the other day. By nature of being a derivative, the concept of a linear log no longer works :-/
[13:48] <cpaelzer> ack
[13:48] <cpaelzer> I'd keep Xenial as-is and only care for your upload now
[13:49] <cpaelzer> and there you could add a new NEWS section for the new content and leave the Debian NEWS untouched
[13:49] <rbasak> But that'll change the previous NEWS entry. I don't know how tooling like apt-listchanges will deal with that.
[13:49] <cpaelzer> oh, right :-/
[13:49] <rbasak> And do I even have any new news? The migration already happened on the upgrade to Xenial!
[13:49] <cpaelzer> But this was only a review/process finding - it is clearly not worth spending more than 15 minutes on it if it gets complex
[13:50] <rbasak> Yeah. I'm sort of stuck. I don't feel like there's any good answer, so I'll leave it.
[13:50] <cpaelzer> You can only fix the future, not the past
[13:50] <rbasak> I did fix the attribution only because I thought it was grossly wrong not to do so.
[13:50] <cpaelzer> BUT
[13:50] <cpaelzer> that means you change the section anyway
[13:50] <rbasak> Yeah
[13:50] <cpaelzer> then make it an appendix in the section
[13:51] <cpaelzer> with no lines being removed
[13:51] <rbasak> That's reasonable.
[13:51] <rbasak> OK, I'll do that. Thanks!
[13:51] <cpaelzer> yw
[14:39] <tedg_> xnox: It is definitely on the TODO list, biggest issue is that half the test suite works against an Upstart mock, so need to move those tests over to the systemd mock. But no every user should be *using* systemd just need to drop old code.
[14:41] <xnox> can you please rephrase "But no every user should be *using* systemd just need to drop old code." i fail at english =/
[14:41] <infinity> xnox: He failed at typing.
[14:42] <infinity> xnox: s/But no/But now/ might clear it up.
[14:42] <xnox> tedg_, at least building without src:upstart should be possible; and would be nice to start doing on s390x, even without the tests.
[14:42] <xnox> infinity, ah, thanks.
[14:42] <xnox> well, if everyone is using systemd code, the upstart tests are pointless no?! =)
[14:42] <infinity> tedg_: If runtime is upstart free, omg please please please make build-time/tests upstart-free as a priority.  WE'RE SO CLOSE.
[14:43] <infinity> xnox: The point is that the tests for the project are against an upstart mock.  They're not useless tests, just using an outdated framework.
[14:43] <xnox> true.
[14:43] <infinity> xnox: The tests should still exist, but need to be moved to a systemd framework, then we all win.
[14:43] <tedg_> Yeah, they're testing other things, just need that as a backstop.
[14:44] <infinity> (I'd like to win soon please)
[14:44] <tedg_> Obviously the ones that are testing just the Upstart features can go away.
[14:44] <tedg_> So, honestly, it's not the highest priority right now, but I'm 99.9% sure we'll get it for zesty.
[14:45] <infinity> tedg_: I know we're super naggy about it, and it's not always been high on your TODO, but we should realistically have dropped upstart last cycle (or even in 16.04, if we could have found the time), doing it this cycle is really really something we need to do so we can move on with life. :P
[14:45] <tedg_> Yes, I understand. I want to drop it too.
[14:48] <nacc> jbicha: ok, I can try and reproduce that today and look into it
[14:48] <nacc> jbicha: the others pass though?
[14:50] <jbicha> nacc: yes
[14:53] <nacc> jbicha: sigh, ok
[14:56] <jbicha> I can just drop debian/gnome-settings-daemon.user-session.upstart now, right?
[14:59] <gQuigs> jbicha: re:bug 1540461, so I don't need to do a big debdiff of all the changes between 3.22.0 and 3.22.4?
[14:59] <gQuigs> jbicha: figured it made more sense to talk on IRC, rather than back and forth on the bug
[15:00] <jbicha> gQuigs: right, all the new changes are likely outside of the debian/ directory
[15:00]  * gQuigs has only done patches so far, but happy to learn more
[15:01] <gQuigs> jbicha: do I need to make a new orig tarball for 3.22.4 or something?
[15:02] <jbicha> gQuigs: I generally use packaging-only bzr branches to do most of my packaging which makes it easy once you figure out how to do it
[15:03] <gQuigs> jbicha: so then where do the new 3.22.4 bits come from in that?
[15:04] <jbicha> my workflow is because I learned from the desktop team packaging, this wiki might be a bit confusing
[15:04] <jbicha> https://wiki.ubuntu.com/DesktopTeam/Bzr
[15:04] <jbicha> the important part is  mkdir .bzr-builddeb; echo -e '[BUILDDEB]\nmerge = True' > .bzr-builddeb/default.conf
[15:05] <jbicha> add your debian/ directory and then bzr init; bzr add; bzr commit -m "init"
[15:05] <nacc> i'm assuming you'd need a new .orig tarball and then a bumped version in d/changelog to know that it's a new upstream
[15:05] <jbicha> to look at the source code, you can use bzr bd-do
[15:05] <nacc> (the .orig tarball would be necessary to, e.g., build a new source pacakge anyways)
[15:06] <jbicha> and to build you use bzr bd --builder="sbuild -d zesty" or whatever you use to build
[15:08] <jbicha> for gnome-ish packages, bzr should fetch the original tarball once you use bzr bd or bd-do based on whatever version you have set in the top debian/changelog entry
[15:08] <nacc> jbicha: ah that makes sense
[15:09] <jbicha> the setup is confusing but once you figure that out, it is fairly convenient
[15:10] <jbicha> git-buildpackage works for git stuff but it offers more flexibility and room for complexity
[15:10] <gQuigs> jbicha: thanks!
[15:10] <gQuigs> yea, git-buildpackage is what I have a bit more exp. with.. but msotly doing things manually
[15:11] <gQuigs> where does the orig tarball actually go after this process?  or does something in the archive know to download it in the same way?
[15:12] <jbicha> with gbp, you have to get the original tarball (maybe something like uscan -dd ?) then gbp import-orig (assuming you're using full source git and not just packaging only)
[15:13] <nacc> jbicha: yeah, i usually use uscan & uupdate
[15:14] <jbicha> when you upload to Debian/Ubuntu, you need to upload the original tarball unless that tarball already exists in the archive from a previous build
[15:14] <nacc> gQuigs: at least in my process, you end up passing -sa to dpkg-buildpackage when you buid the source package and that means it will include the orig. Note that the only caution here is we want the same orig everywhere for that upstream
[15:14] <jbicha> (in other words, you're doing like a -0ubuntu2 instead of a -0ubuntu1)
[15:15] <gQuigs> k, thanks both!  will see if I can get it built in a PPA
[15:15] <nacc> gQuigs: feel free to ask more questions here, of course
[15:32] <seb128> fossfreedom, having a valgrind log (with ddebs installed) would probably be more useful than a bt for a refcounting issue
[15:54] <nacc> jbicha: hrm, i think something got messed up in these php-imagick uploads
[15:54] <nacc> jbicha: the *reason* our d/t/control looked different was that we patched php-imagick to be single-threaded
[15:56] <nacc> jbicha: i believe that was lost in the sync of 3.4.3~rc2-1-build1, which should have been a merge, afaict
[15:57] <nacc> jbicha: that was needed because of segfaults in the testsuite (iirc)
[15:58] <fossfreedom_> seb128: I've tried running under valgrind - the problem doesnt occur.  Weird ... it must be a timing issue.
[15:58] <nacc> jbicha: i'm not 100% sure it would fix armhf, but it's not mentioned in that upload
[15:59] <jbicha> nacc: yes, I saw there were 2 changes that were dropped, I decided to try just the needs-recommends change first, do you want to do the upload now?
[15:59] <nacc> jbicha: let me see if i can get on a porter box and test it first
[15:59] <nacc> jbicha: but yeah, i'll handle it today
[15:59] <nacc> jbicha: just wanted to sync with you first
[16:00] <phunyguy> hey guys... can anyone in here tell me how Ubuntu's kernel modules are so small?  compiling a kernel manually in $another_distro, even with module compression turned on results in modules 3x the filesize of Ubuntu's....  Just curious really.
[16:01] <nacc> jbicha: my suspicion is that will fix it, though, given that 3.4.3~rc1-4ubuntu4 passed on armhf, but all the 3.4.3~rc2-1* have failed
[16:03] <ChrisTownsend> seb128: Hey!  Would you have any time to look over the binNEW introduced in https://bileto.ubuntu.com/#/ticket/2452 ?
[16:20] <Laney> jbicha and nacc: The autopkgtest lxd runner is good enough for testing this even on amd64, btw
[16:21] <dannf> cyphermox, cjwatson : i was looking to sync the last grub2 debian upload to zesty today, let me know if you have any changes to add in there
[16:22] <cjwatson> dannf: do you mean merge?  there are two changes in the Ubuntu history not yet in Debian
[16:22] <dannf> cjwatson: yes, sorry - merge
[16:22] <cjwatson> fine by me
[16:23] <nacc> jbicha: cross-arch testing?
[16:25] <cyphermox> dannf: go ahead
[16:25] <dannf> cyphermox, cjwatson: cool, thx
[16:30] <rbasak> cpaelzer: how about http://paste.ubuntu.com/23961330/ as the debian/NEWS.debian change in my squid3 merge?
[16:32] <Laney> nacc: you meant to hilight me?
[16:32] <Laney> If so - no, just amd64 on amd64
[16:33] <nacc> Laney: was just in response, was debugging an armhf failure only
[16:33] <Laney> I know
[16:33] <Laney> But you can make the same one happen in that way
[16:33] <Laney> On amd64.
[16:33] <nacc> I can? autopkgtest is passing on amd64?
[16:34] <Laney> Use the lxd runner
[16:34] <nacc> Laney: no, i understand, but it's not failing on amd64
[16:34] <Laney> It is if you use that runner
[16:35] <Laney> Production doesn't use it, so you don't see it there
[16:35] <Laney> Does for armhf though
[16:35] <nacc> Laney: oh i see, then yes, this isthe same bug i know the fix for, probably :)
[16:35] <nacc> Laney: thanks, will verify it locally then on amd64
[16:36] <Laney> nacc: good, just wanted to share a way to test the fix easily, hope it works!
[16:37] <rbasak> cpaelzer: complete diff against what you previously reviewed: http://paste.ubuntu.com/23961353/
[16:37] <nacc> Laney: thanks, sorry for my density
[16:38] <seb128> fossfreedom_, often segfault stop happening under valgrind but it doesn't mean the error isn't in the log
[16:39] <seb128> fossfreedom_, get a log anyway, there is a good chance it has the info you need even if it didn't segfault
[16:40] <seb128> ChrisTownsend, sorry but the changelog doesn't explain enough the diff for me to ack it, like the gobject bindings got removed but without mention nor "why"
[16:41] <ChrisTownsend> seb128: Ok.  It was removed because it is deprecated and nothing used it.
[16:42] <seb128> ChrisTownsend, same about why was python3-apt removed from the depends
[16:42] <seb128> ChrisTownsend, it's good taste to summarize the changes in the changelog for futur uploads
[16:43] <ChrisTownsend> seb128: The python3-apt depends is not removed, just moved to the libertined package.
[16:43] <ChrisTownsend> seb128: Ok, will do that next time when deprecating a package.  I can add it now if you'd like since this is still in lander testing.
[16:43] <Laney> mapreri: seems like the skip_unless_module_exists thing in diffoscope is busted
[16:45] <seb128> ChrisTownsend, not sure it's worth making you go through another silo round and restarting testing, looks fine but please next time explain the packaging changes in the changelog so we know if they are errors or wanted
[16:46] <ChrisTownsend> seb128: Ok, will do and thanks for the feedback.
[16:46] <seb128> ChrisTownsend, yw!
[16:49] <Laney> mapreri: oho, I see #854670
[16:58] <gQuigs> jbicha: lol, I've been mostly playing with the tools.. and missed the basics..
[16:58] <gQuigs> jbicha: Requested 'evolution-data-server-1.2 >= 3.22.4' but version of evolution-data-server is 3.22.3,  it would need a bump of the data-server for me to bring in .4 of ews
[16:59] <gQuigs> could just likely go for ews 3.22.3
[17:00] <jbicha> yes, that's fine
[17:00] <fossfreedom_> seb128: will rerun under valgrind and grab a log.  thanks.
[17:01] <seb128> fossfreedom_, thanks
[17:06] <ChrisTownsend> seb128: Oh, one other thing...a couple of libertine related packages in universe will need to be promoted to main when this landing hits -proposed.  The libertine source package is already in main, so do I just create a bug at that time asking for those binary packages to be promoted?
[17:08] <seb128> ChrisTownsend, no, binaries are semi-automatically handled, they are going to show on the component mismatch report and an archive admin needs to promote them then
[17:09] <ChrisTownsend> seb128: Ok, thanks
[17:10] <mapreri> Laney: yeah, I already reported a bug in Debian
[17:11] <mapreri> .. which you found few minutes after the first msg :)
[17:11] <mapreri> I have a feeling lamby is not running autopkgtest before uploading, or something :(
[17:40] <nacc> Laney: thanks again for the guidance (and patience) -- I forget that nuance about the autotpkgtest runners. Reproduced the failure locally and testing the fix now.
[17:41] <Laney> nacc: Nice
[17:45] <Laney> mapreri: enjoy a patch
[17:47] <mapreri> Laney: thank you!  (I'm in exam season, so I'm not doing much of Debian work these weeks)
[17:47] <mapreri> Laney: btw, "BTW, maybe it would be nice if the 'debian' tests were run in autopkgtest; add a test-dep on python3-debian?" - they are run, on the other test; the failing autopkgtest is the run without any optioanl package installed to test fallbacks, etc.
[17:47] <mapreri> see d/tests/control
[17:48] <Laney> oh ok
[17:48] <Laney> that makes sense, thanks
[17:48] <nacc> jbicha: verified, tests pass again now -- probably should send this to Debian? (both bits of delta)
[18:01] <mapreri> Laney: that's weird btw:
[18:01] <mapreri> In [12]: importlib.util.find_spec('this module is not there') is None
[18:01] <mapreri> Out[12]: True
[18:01] <mapreri> it doesn't rise any exception, as documented
[18:02] <Laney> mapreri: try foo.bar
[18:03] <mapreri> oh, right "If name is for a submodule (contains a dot), the parent module is automatically imported."   ....
[18:03] <mapreri> pity
[18:03] <Laney> you could probably split or something
[18:03] <mapreri> but then your patch makes the function wrong for modules without dot
[18:04] <mapreri> yeah, I got the problem now
[18:05] <Laney> did you see the second version?
[18:06] <Laney> oh, I typed my passphrase wrong :|
[18:06] <mapreri> Hence, I haven't :)
[18:10] <Laney> k, night night
[18:10] <mapreri> Laney: thanks, that looks nicer indeed :)  I'll leave it there for lamby to pick it up; if he won't by tomorrow, I'll upload it tomorrow evening or so.
[18:11] <Laney> might want to re-word the commit msg a bit
[18:12] <Laney> see you!
[21:54] <nacc> anyone know enough about locales to know if the following is expected? http://paste.ubuntu.com/23962998/
[21:54] <nacc> it's the root cause for the phpmyadmin build failure in z-p (which is a build-time test failure)
[21:55] <nacc> it didn't show up in my lxd z-p, because the locale is set to POSIX, so I tried `export LC_ALL=C.UTF-8` and the test failed
[21:59] <nacc> interesting (to me, because it's confusing), running with LC_ALL=C also produces "This is the Euro symbol 'EUR'"
[22:00] <nacc> so it's only C.UTF-8 that has issues, which is unfortunately the sbuild default
[22:00] <nacc> infinity: --^ maybe you'd have a suggestion here (if you're busy, totally fine)
[22:01] <sarnold> heh, pasting that command line into a bash with en_US.UTF-8 works fine; start LANG=POSIX bash and the paste is all screwed up
[22:02] <nacc> yeah, the C&P might be funky as it tends to do something wonky with the multibyte characters
[22:03] <nacc> sarnold: agreed, though en_US.UTF-8 also does work
[22:03] <sarnold> I sort of expected the terminal's environment to control it thuogh, not some random child process of the shell in the terminal, heh
[22:03] <sarnold> I -still- don't know how these things work. sobering though.
[22:03] <sarnold> s/though/thought/
[22:08] <cyphermox> dannf: don't forget grub2-signed :)
[22:08] <dannf> cyphermox: ack, in progress :) thanks for the reminder!
[22:09] <cyphermox> (if you don't have the time, then I'll do it)
[22:09] <nacc> sarnold: at first, i thought maybe it was because ISO-8859-1 technically doesn't have the euro symbol, but ISO-8859-15 does. And in fact, specifying -15 with LC_ALL=C.UTF-8 does work (although it does not translit it, as I guess iconv successfully converted it)
[22:11] <nacc> and it was added (I think) in -9, which again works (and translits) with en_US.UTF-8, but not C.UTF-8
[22:36] <casa> hi everyone I'm using Lubuntu I want to meet a OS programmer (not only Unix and Linux), I want to collaborate with programmer for make original sounds, I compose and produce somethings for opensource programs, but I want to know a programmer for OS...maybe here there aren't OS programmer?!? btw I really love Lubuntu and I'm trying to install to every friend I have xD it is difficult but slowly everyone will use Lubuntu or
[22:36] <casa> Ubuntu OS, I hope I find someone interested in this way..for music and original sound design, I'm always here...my email is jacopotore@gmail.com  , on skype: jacopotore  , hope to find someone...really love Art and Computer <3
[23:07] <nacc> mdeslaur: fyi, sorry for the delay, uploading 7.0.15 for SRU now
[23:23] <mdeslaur> nacc: np, thanks! :)