[00:20] <Netsnipe> hi everyone. anyone seen utlemming or anyone else responsible for the AWS AMIs around?
[05:01] <pitti> Good morning
[05:02] <pitti> xnox: ack, thanks; we have that in Steve's bug reply as a reminder
[06:54] <dholbach> good morning
[06:59] <didrocks> morning dholbach :)
[06:59] <dholbach> salut didrocks
[07:31] <pitti> RAOF: oh dear, I was blaming the new libgphoto2 all along, but it seems the @DEV stuff broke umockdev recording
[07:31] <pitti> RAOF: and on top of that, @DEV isn't actually written; I'm looking at both
[07:32] <RAOF> pitti: Huh, for what? I rather thought I'd *used* that feature!
[07:32] <pitti> RAOF: just FYI in case you try to actually use that with Mir
[07:32] <RAOF> I, um, *have* used that in Mir.
[07:32] <pitti> RAOF: if you record several commands (or  more generally, open/close cycles of the device), only the last is kept
[07:32] <pitti> instead of all of them
[07:32] <RAOF> Oh. I don't do that.
[07:33] <RAOF> So wouldn't have noticed.
[07:33] <pitti> RAOF: but the way how ioctl records work the @DEV was never written to them
[07:33] <pitti> RAOF: oh, unless  your program never called close() but you just ^Ced it
[07:33] <RAOF> Ding!
[07:33] <pitti> which would be with evtest
[07:47] <pitti> infinity: nice job on bug 1319122!
[07:53] <pitti> RAOF: hm, still a miracle how it worked with ^C though, as it essentially does the same thing as with close()
[08:10] <RAOF> pitti: It's also possible that I hand-edited in the @DEV line because I was umockdev-recording with the system-wide binary which didn't yet have the patches.
[08:11] <pitti> RAOF: ah, that sounds plausible then
[08:11] <pitti> RAOF: anyway, fixed now, releasing 0.8.2
[08:13] <infinity> pitti: Yeah, I don't have high hopes that many computers actually got updated in time, but at least we did our best in Debian/Ubuntu.
[08:14] <pitti> infinity: one thing that's weird is that utopic has the trusty SRU; we can't sync from Debian?
[08:14] <infinity> pitti: Look again.
[08:14] <infinity> pitti: I just copied the trusty SRU over as a stopgap while LP caught up with dinstall.  They're in sync now.
[08:14] <pitti> ah :)
[08:14] <pitti> thanks
[08:16] <infinity> pitti: It was just a complete fluke that an Egyptian user popped into #debian-glibc to tell us about it, mind you.  I might suggest that Paul Eggert set up an emergency broadcast list for these rare times when governments go crazy with 0 notice. :P
[08:17] <pitti> I thought there was some tz-announce@ thingy
[08:17] <infinity> If there is, no one seems to be on it.
[08:17] <infinity> There sure is...
[08:18] <infinity> Oh, but that's just his release announces.
[08:18] <infinity> I should subscribe to that anyway.
[08:18] <infinity> But I meant something even lower traffic and higher visibility for "OMG THIS COUNTRY IS CRAAAAZY, UPDATE NOW!"
[08:19] <pitti> so what was Argentina back then is now Egypt :)
[08:19] <infinity> In this case, though, thanks to said user, I think we got all the updates out within hours of Paul's release.
[08:20] <infinity> There, subscribed to tz-announce, at least.
[08:39] <seb128> hum
[08:39] <seb128> what's going on with e.u.c?
[08:40] <seb128> https://errors.ubuntu.com/?period=day looks bugg
[08:40] <seb128> ev, bdmurray: ^ do you know if there is a known issue?
[08:40] <seb128> +y
[08:43] <ev> seb128, bdmurray: that's troubling. Brian, do we have any recent changes to production that could've caused this? I had a look through RT and the daisy and errors trunks, but I don't see anything that landed in the past day or two.
[08:44] <seb128> ev, I guess Brian is not going to be up before some hours
[08:44] <ev> yeah
[08:44] <ev> on first blush it looked like it was only showing package installation crashes, but there's at least one regular crash in there
[08:45] <seb128> well, default view is the packages you are subscribed to no?
[08:46] <seb128> it gives me an empty list here
[08:46] <seb128> (well, now it's stucked on "Loading...")
[08:47] <seb128> but like if I do trusty reports on 1 day
[08:47] <seb128> I get "no data to display"
[08:47] <seb128> https://errors.ubuntu.com/?release=Ubuntu%2014.04&period=day
[08:57] <ev> https://graphite.engineering.canonical.com/dashboard/#15may-crashes suggests that we are at least capturing the data
[09:08] <seb128> ev, do you want me to file a report about the issue? against what tracker/component?
[09:13] <ev> seb128: please, against lp:errors
[09:14] <ev> I *think* (/hope) at this point that the problem is in the UI layer, not in our data collection
[09:24] <seb128> ev, https://bugs.launchpad.net/errors/+bug/1319730
[09:32] <ubilli8> please how do i build a software on ubuntu
[09:36] <brendand> ubilli8, depends
[09:36] <ev> seb128: thanks! ^ bdmurray would you mind digging at that when you get a chance? It doesn't appear like we're dropping data on the floor in daisy, but please do confirm in case of I've missed something obvious :)
[09:36] <brendand> ubilli8, which software
[09:37] <seb128> ev, bdmurray: thanks for looking at it ;-)
[09:40] <ubilli8> i want to develop LAMP just like WAMP for windows but i want to know how the ubuntu architecture works to do that and what language to use to write the language
[09:43] <ubilli8> @<brendand>
[09:43] <udevbot> Error: "<brendand>" is not a valid command.
[09:44] <brendand> ubilli8, 'LAMP' is not one piece of software
[09:45] <ubilli8> yeah something like wamp that holds all the software during installation and manages it. just like wamp
[09:46] <infinity> ubilli8: Are you referring to http://www.wampserver.com ?
[09:47] <brendand> ubilli8, so some sort of gui for managing the installation?
[09:48] <ubilli8> yes do you think it is possible...???
[09:48] <infinity> ubilli8: Anyhow, I'll throw you a bone.  To replicate that set of packages installed, you want "apt-get install lamp-server^" and "apt-get install phpmyadmin", but this is also a question for #ubuntu, not #ubuntu-devel, this isn't a channel for people who develop using Ubuntu, but for people who develop Ubuntu itself.
[09:50] <ogra_> xnox, why would you not ship the cmake tools sdk-libs-dev ? cmake itself is shipped there too ... sounds kind of logical to me to ship the needed tools for development in there as well
[09:50] <ogra_> (i would have asked you in #ubuntu-touch ... but you seem to not be there)
[09:51] <xnox> ogra_: hm? i explicitly said that they should be shipped in sdk-libs-dev.
[09:51]  * ogra_ re-reads the mail 
[09:51] <xnox> ogra_: but since it's a metapackage -> that means in one of the seeded depedencies.
[09:51] <xnox> ogra_: metapackages should be empty.
[09:52] <xnox> ogra_: especially those generated from seeds/germinate.
[09:52] <ogra_> xnox, heh, lol, ignore me ... you said exactly what i meant
[09:52] <ogra_> i totally misread
[10:34] <zyga> what is the *correct* way to disable all i18n aspects? so far I'm using LANG= LANGUAGE= LC_ALL=C.UTF-8 but I have no real reference that would say this is correct and minimal, setlocale(3) is not really helping much
[10:35] <zyga> from what I see, setting LANG=C is insufficient, I get a mixture of translated/localized text, equally insufficient is LC_ALL
[10:35] <zyga> is there a document that says how l10n is supposed to be initialized and specifically, disabled
[10:36] <cjwatson> LC_ALL=C
[10:37] <cjwatson> or LC_ALL=C.UTF-8 if what you actually mean is "disable locale-specific things but let me have UTF-8 character encoding"
[10:37] <cjwatson> (note, C.UTF-8 is a bit system-specific, but it's always there on Debian and descendants)
[10:37] <cjwatson> actually, sorry, you must also unset LANGUAGE because LC_ALL doesn't imply that
[10:38] <zyga> cjwatson: yeah, pure LC_ALL is irrelevant it seems
[10:38] <cjwatson> but LC_ALL overrides LANG and all of LC_* so you don't need to deal with those separately
[10:38] <cjwatson> LC_ALL is NOT irrelevant
[10:38] <zyga> http://paste.ubuntu.com/7467208/
[10:38] <cjwatson> it's just not quite sufficient
[10:38] <zyga> LC_ALL=C.UTF-8 pactl list
[10:38] <cjwatson> LANGUAGE= LC_ALL=C.UTF-8 will be sufficient though
[10:38] <zyga> right, it doesn't do much effectively though (I get it that it gets respected though I don't understand why it's not overriding LC_MESSAGES
[10:38] <cjwatson> no, it just doesn't do one specific thing
[10:38] <zyga> cjwatson: which thing  is that?
[10:39] <zyga> cjwatson: is LANGUAGE documented anywhere?
[10:39] <cjwatson> info libc
[10:39] <cjwatson> LANGUAGE overrides LC_ALL IIRC just for the purpose of the message translation category
[10:40] <zyga> cjwatson: thanks
[10:40] <cjwatson> but that's just for gettext; for all other locale categories the master variable is LC_ALL
[10:41] <zyga> cjwatson: reading the relevant part of the info page
[10:42] <cjwatson> so for instance collation order for sorting things, case conversions, numeric/monetary/time presentation, etc.
[10:42] <zyga> cjwatson: hmm, I think there's a bug though still
[10:42] <zyga> cjwatson: look at gettext(3)
[10:42] <zyga> cjwatson: LANGUAGE is apparently ignored if locale is "C" but apparently it doesn't know about C.UTF-8 which is for all intents and purpuses just better "C"
[10:43] <cjwatson> I expect that would be worth fixing in gettext(3), yes
[10:43] <cjwatson> I suggest filing a bug, I don't work on this stuff :)
[10:43]  * zyga just verified that C is special cased and C.UTF-8 isn't 
[10:43] <zyga> cjwatson: yeah, I'll file a bug on that
[10:43] <zyga> cjwatson: thanks for showing me info libc :)
[10:44] <cjwatson> yw
[10:45] <zyga> ara: hey, your office space fixed their internet filters :)
[10:46] <ara> zyga, no, I just moved back home :D
[10:47] <infinity> zyga: Can you file a Debian bug against src:eglibc for the lack of special-casing of C.UTF-8 there?
[10:47] <zyga> infinity: my pleasure
[10:47] <infinity> zyga: Ta.
[10:48] <infinity> This is likely a missing piece I need to fix before I start enacting my "C.UTF-8 everywhere" plans.
[10:48] <hallyn> arges: yes, rsync the rootfs and also copy over the files under $lxcpath/$name, i.e. /var/lib/lxc/u1/config and if it exists .../fstab
[10:49] <zyga> infinity: :)
[10:49] <zyga> infinity: I could patch it, should be relatively simple
[10:49] <infinity> zyga: Yeah, I didn't assume it would be hard, but since you've already gone and found the relevant bit, a bug with a pointer would be awesome, so I don't duplicate the effort next week. ;)
[10:50]  * infinity wonders if maybe it's about time to try to push C.UTF-8 upstream for glibc 2.20, and puts that on his "talk to aurelien" list for when it's not 5am.
[10:51] <mlankhorst> ok, uploading lts stack part 1 (all !drivers)
[10:54] <zyga> gah, reportbug just ate my bug description
[10:57] <zyga> infinity: sent, I'll give you the number as soon as I get it back
[11:00] <infinity> Speaking of C.UTF-8, can anyone reproduce https://errors.ubuntu.com/problem/70c1930688440b1818145db3346da61eb39a7ac8 ?
[11:02] <zyga> infinity: on 14.{04,10}? no
[11:03] <infinity> zyga: Either.
[11:04] <infinity> Seems to work fine for me at a python3.4 interactive prompt.  No idea why it's crashing there.
[11:04]  * infinity shrugs.
[11:05] <zyga> infinity: I've seen odd locale crashes but typically mid-upgrade or remotely
[11:05] <zyga> infinity: but software properties
[11:05] <zyga> wait, could that be add-apt-repository?
[11:07] <zyga> infinity: might be worth to see on a cloud image, those are usually locale-challenged
[11:08] <zyga> infinity: debian bug 748215
[11:09] <infinity> zyga: Ta.
[11:10] <cjwatson> locale-challenged> they are, but C.UTF-8 is in libc-bin, it should be everywhere
[11:12] <zyga> cjwatson: true
[11:12] <zyga> cjwatson: does it need to be generated somehow though, or is it always available?
[11:13] <infinity> zyga: It's always available.
[11:13] <infinity> zyga: That's why that crash confuses the heck out of me.
[11:13] <zyga> infinity: yeah, I can understand that
[11:13] <infinity> (And why I can't reproduce it in a minimal test case in a barebones chroot...)
[11:13] <zyga> infinity: I have no idea why it might occurr
[11:13] <cjwatson> It *is* possible to remove it, but you have to ignore the "you're trying to remove an Essential package, you idiot" prompt
[11:13] <cjwatson> Maybe somebody did
[11:13] <zyga> cjwatson: ;-)
[11:13] <infinity> mvo worked around it by just trapping the error, but it shouldn't error in the first place.
[11:14] <infinity> cjwatson: A fair few someones...
[11:14] <zyga> infinity: the random instance I looked at had a freshly installed 14.04 (0 days old)
[11:14] <zyga> infinity: so I doubt they would remove those packages really
[11:14] <cjwatson> Unfortunately libc-bin isn't in Dependencies (since it's Essential)
[11:15] <infinity> Yeah.  Oh well.  Unless someone can reproduce it and tell me how, it'll be one of those things that just annoys me peripherally but I won't do anything about.
[11:15] <infinity> I doubt anyone would remove libc-bin, but I suppose I could see someone deleting the locale itself.
[11:15] <infinity> But still, that's a lot of crash reports for something as silly as that that I can't see many people doing.
[11:15] <cjwatson> "we don't need this bit"
[11:15] <cjwatson> yeah, as you say
[11:16] <mvo> right, I'm also quite puzzled by this fwiw
[11:16] <infinity> We do have a race in locale-gen that I intend to fix, which could actually cause this sort of issue in the middle of a libc6 upgrade, but since fresh installs see it, and I've not SRUed glibc yet, that theory's out the window.
[11:17] <infinity> Oh, and c.utf-8 is pre-generated in the package anyway.
[11:17] <infinity> So... I dunno.
[11:17] <infinity> I shall try to forget it, like so many bad relationships^wbugs passed.
[13:30] <n4uah> is any one here?
[13:57] <pitti> xnox: hm, the new sysvinit seems to have broken at least LXC, and that looks real (i. e. not just like a CI machinery quirk)
[13:57] <xnox> pitti: ouch, i've tested everything extensively.
[13:57] <xnox> pitti: how/what ?
[13:58] <pitti> Setting up lxc (1.0.3-0ubuntu3) ...
[13:58] <pitti> lxc start/running
[13:58] <pitti> invoke-rc.d: unknown initscript, /etc/init.d/lxc-instance not found.
[13:58] <pitti> http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-lxc/22/ARCH=i386,label=adt/console
[13:58] <pitti> or https://jenkins.qa.ubuntu.com/job/utopic-adt-lxc/22/ARCH=i386,label=adt/console for folks without VPN
[14:00] <xnox> pitti:
[14:00] <xnox> $ sudo initctl --system status lxc-instance
[14:00] <xnox> initctl: Unknown parameter: NAME
[14:00] <xnox> Usage: NAME=name of LXC instance
[14:00] <pitti> I have a /etc/init/lxc-instance.conf, but not /etc/init.d/lxc-instance
[14:01] <pitti> +   && initctl status ${SERVICE} 2>/dev/null 1>/dev/null
[14:01] <pitti> oh, likely due to that?
[14:02] <pitti> xnox: right, you're ahead of me
[14:02] <pitti> so apparently status doesn't work for these "template" jobs
[14:02] <xnox> pitti:  it think it's a bug in lxc postinst, it should not have "dh_installinit --name lxc-instance --no-start -p lxc"
[14:03] <xnox> pitti: as there is no way to invoke lxc-instance without an instance....
[14:03] <xnox> pitti: verifying that now.
[14:13] <xnox> pitti: hm, that is kind of sad. But e.g. initctl show-config still lists lxc-instance.
[14:14] <pitti> xnox: you (or Debian, not sure) does this instead of a simple [ -e /etc/init/lxc-instance.conf ] to also catch overrides etc.?
[14:14] <xnox> pitti: yes.
[14:14] <xnox> pitti: and multiple configuration directories, as we will need in the future.
[14:15] <xnox> pitti: it's more strict, but more correct at the same time. And e.g. i'll be able to resurrect php upstart job.
[14:15] <pitti> xnox: so perhaps only check if "LC_ALL=C initctl status $job | grep -q Unknown"?
[14:15] <pitti> unfortunatley the exit status always seems to be 1
[14:16] <pitti> i. e. both for the lxc-instance "template" situation and a real unknown job
[14:16] <xnox> (upstart job added in trusty, with syntax not supported by precise upstart. and at the moment invoke-rc.d tries to use upstart job, instead of the init-script whilst pid1 is still precise-upstart which has no clue about this new job with what it thinks is invalid syntax)
[14:17] <xnox> pitti: i'll check other template jobs, but for lxc it really should be doing --no-start in it's dh_installinit calls.
[14:17] <pitti> ah right, it doesn't
[14:19] <xnox> pitti: at least no pam-systemd should configure in the lxc container just fine, even if one does lxc-attach to it =)
[14:19] <xnox> pitti: will email people about it, once verified.
[14:19] <pitti> xnox: nice!
[14:19] <xnox> s/no/now/
[14:20] <saiarcot895> Hi, is it possible to disable building ddebs in sbuild? From PPA build logs, there is a line that seems to does this. (dh_strip debug symbol extraction: disabling for PPA build)
[14:21] <pitti> it can be enabled/disabled by PPA
[14:21] <pitti> saiarcot895: but that means it's already not happening, i. e. it shoudln't spit out ddebs
[14:21] <xnox> saiarcot895: or in packaging you can export a variable to make sure pkg binary mangler doesn't create ddebs.
[14:21] <saiarcot895> pitti: The PPA isn't spitting out ddebs, but sbuild locally is spitting out ddebs. I'm trying to disable that
[14:22] <pitti> saiarcot895: ah; drop the pkg-create-dbgsym package from it then
[14:22] <bdmurray> pitti: could you have a look at bug 1318034?
[14:22] <xnox> saiarcot895: you probably have binary pkg mangler installed.
[14:22] <xnox> saiarcot895: i have this in my ~?.sbuildrc
[14:22] <xnox> saiarcot895: $build_environment = { 'NO_PKG_MANGLE' => '1', 'DEB_BUILD_OPTIONS' => 'parallel=12', 'HOME' => '/build/' };
[14:22] <pitti> bdmurray: yes, will do
[14:22] <xnox> saiarcot895: you want the NO_PKG_MANGLE => 1 option.
[14:23] <saiarcot895> xnox: I'll try that
[14:23] <pitti> that should work too, yes
[14:45] <xnox> pitti: i uploaded fixed lxc, and i hope in time autopackagetest will migrate both.
[14:46] <pitti> xnox: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sysvinit is looking good so far
[14:46] <pitti> xnox: and I'm glad this stuff is now actually useful, now that britney is fixed :)
[14:50] <xnox> pitti: looks like that's the only package affected so far. Well at least on my system, didn't check the $world.
[14:51] <pitti> xnox: so grep -r ^instance /etc/init/* are all potentially affected ones, right?
[14:51] <xnox> pitti: well & calling invoke-rc.d in their postinst.
[14:51] <xnox> pitti: for all those that i had on my machine, there are none that called invoke-rc.d.
[14:52] <xnox> pitti: well none, apart from the now fixed lxc-instance.
[14:52] <pitti> nice
[14:53] <xnox> stgraber: i did direct to archive upload of lxc, packaging change only. Not sure if it needs to be committed somewhere else as well.
[15:00] <pitti> I figure at least to Debian?
[15:01] <xnox> pitti: packaging appears to be a fork. and in debian --no-start is passed.
[15:02] <pitti> ah :)
[15:14] <cjwatson> mvo: Would you mind retargeting your click merges to lp:click/devel?  I've just created that.
[15:16] <mvo> cjwatson: sure, no problem
[15:22] <barry> xnox: let's talk about py2
[15:22] <xnox> barry: > #ubuntu-ci-eng
[15:23] <xnox> barry: oh, you are not there. I was chatting to ogra_ about it there already.
[15:24] <barry> xnox: i'm there now
[15:31] <pitti> xnox: http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-lxc/23/ARCH=i386,label=adt/console crashed with something weird in apt-get update, retrying
[15:31] <pitti> xnox: but amd64 succeeded
[17:53] <andrewrk> hey I'm trying to copy a package to my PPA and I'm getting "source contains expired files". what's the deal with that?
[17:54] <andrewrk> I went spelunking into the superceded section of old libav builds and found one that I want to put into my PPA for precise
[17:55] <andrewrk> and launchpad won't let me do it
[17:55] <andrewrk> hmm maybe I should go to #ubuntu-app-devel
[19:08] <bdmurray> arges: are looking at the trusty SRU queue?
[19:09] <arges> bdmurray: had a few minutes between a test I was running. sorry if I steps on your toes a bit
[19:09] <bdmurray> arges: not at all, I was just gonna get started
[19:09] <arges> bdmurray: ok cool : )
[19:45] <stgraber> xnox: I'm used to pick it up when changing in the archive, that's fine
[20:21] <bdmurray> arges: bug 1316125 is fixed in trusty presumably?
[20:22] <arges> bdmurray: let me verify
[20:23] <bdmurray> arges: it doesn't look like it to me...
[20:28] <arges> bdmurray: yup il'l have tinoco fix that thanks
[20:29] <tinoco> yep, im on it
[20:29] <bdmurray> arges: okay, I've also added an autofs task since the closure looks at the source package name
[20:29] <arges> oh didn't realize it was targeted against the binary package
[20:29] <arges> bdmurray: thanks
[20:30] <bdmurray> I think there was some weird renaming of autofs / autofs5
[20:31] <bdmurray> and if its not fixed in trusty then it isn't fixed in utopic since they are the same verison
[20:31] <tinoco> bdmurray: the same version was kept from saucy to utopic
[20:32] <tinoco> and this bug fix is based on a commit on 5.0.7 so all of them needs the fix
[20:32] <tinoco> im creating the diffs for them
[20:32] <tinoco> i'll attach to ua and lp, ok ?
[20:50] <Saviq> kirkland, hey, shift+f2 stopped working a day or two ago in my byobu under utopic (shift+f7 stopped working before that), both print ~ at that point, any idea where that might come from?
[21:34] <jtaylor> can one add new source packages to trusty?
[21:36] <Logan_> through a backport
[21:36] <jtaylor> I mean into updates
[21:37] <jtaylor> so other srus can depend on it
[21:37] <Logan_> does an important bug fix depend on a new source package? o_O
[21:37] <jtaylor> yes
[21:37] <Logan_> go on
[21:37] <jtaylor> one could do it in an existing one but thats incredibly ugly
[22:10] <mterry> robert_ancell, when were you thinking of releasing the next lightdm revision?
[22:11] <robert_ancell> mterry, whenever, is there something you were blocking on?
[22:11] <mterry> robert_ancell, split greeter would appreciate that login1-race fix
[22:11] <robert_ancell> mkay
[22:14] <robert_ancell> mterry, perhaps you could also look at https://code.launchpad.net/~christian-w/lightdm/qt-binding-keyboard-layouts/+merge/205356
[22:15] <infinity> jtaylor: Yes, but it's rather ugly and needs some justification.
[22:16] <mterry> robert_ancell, looking
[22:17] <jtaylor> justification is I don't want to touch tcl ._.
[22:18] <xnox> jtaylor: try again =) what's wrong with tcl in trusty? we even have two, if i recall correctly
[22:18] <jtaylor> thats the problem
[22:19] <jtaylor> I want to add a new package using tcl 8.5 instead of 8.6
[22:19] <jtaylor> to make the stuff we didn't transition work again
[22:19] <xnox> jtaylor: you don't have to build against both, you can use just one of them. and both should be in main.
[22:19] <jtaylor> so far I know porting is either non-trivial or impossible
[22:19] <jtaylor> xnox: doesn't work with libraries
[22:20] <jtaylor> one library uses 8.5 the other 8.6
[22:20] <jtaylor> you can imagine that that will not end well
[22:20] <xnox> jtaylor: what's the incompatible set of packages you are talking about?
[22:20] <jtaylor> the blt and itcl3 rdepends
[22:20] <jtaylor> it seems itcl3 was incorporated into tcl 8.6 as itcl4/tclOOP
[22:21] <jtaylor> I have not found if you can even use itcl3 with 8.6
[22:21] <jtaylor> trying it just crashes
[22:21] <xnox> jtaylor: so you are saying that skycat & tkdesk are borked?
[22:21] <jtaylor> yes
[22:21] <xnox> jtaylor: well one or the other way it needs to be fixed in utopic, and is probably worth an sru into trusty.
[22:22] <xnox> jtaylor: have you filed a bug yet?
[22:22] <jtaylor> I would do that by adding a blt8.5
[22:22] <jtaylor> which is really easy
[22:22] <jtaylor> as its library is versioned
[22:22] <jtaylor> the question is can I do that in trusty too
[22:23] <xnox> jtaylor: you don't need to add a new source package though. you can just add a second binary package.
[22:23] <jtaylor> xnox: I know but thats not easy
[22:23] <xnox> jtaylor: or it would be best to resolve it by e.g. rebuilding itcl3 with 8.5 in trusty. but that needs testing.
[22:23] <jtaylor> itcl is 8.5 in trusty
[22:24] <jtaylor> blt would need rebuild against 8.5
[22:24] <xnox> well then blt should be to.
[22:24] <xnox> right, that.
[22:24] <jtaylor> which is problematic as its rdepends use 8.6
[22:24] <jtaylor> its safer to add a new package
[22:24] <xnox> given that blt's rdependes is relatively short, we will probably need to rebuild those as well.
[22:24] <jtaylor> reverting a transition seems more ugly than adding a new source
[22:25] <xnox> jtaylor: a new package doesn't solve the problem that you have binaries linked together with incompatible tcl's and only adds more cases to the depedency chart.
[22:25] <jtaylor> it helps at least for skycat
[22:25] <xnox> well in utopic we really should port itcl3 to 8.6
[22:26] <xnox> and in the best interest of everyone cherrypick that into trusty.....
[22:26] <xnox> jtaylor: please open a bug report against blt, itcl3, skycat & tkdesk.
[22:26] <xnox> jtaylor: we'll need to track this, whichever way this is going to be solved.
[22:29] <jtaylor> I don't know how to port it
[22:29] <jtaylor> I can't even get a reasonable backtrace of the crash ._.
[22:30] <xnox> jtaylor: that's ok, others know how to port things, but please open the bug report describing the issues you are seeing.
[23:00] <TheMuso> mdeslaur: Re bug 1319970, I am happy to take care of this if you like. I have commit access to the git repo for speech-dispatcher in Debian, and I track Ubuntu's changes there too.
[23:00] <saiarcot895> When building Qt 4.8.5 on Trusty, there's a message printed out about using the -no-exceptions flag (http://paste.ubuntu.com/7470347/). Might this be beneficial?
[23:07] <robert_ancell> mterry, 1.11.2 uploaded
[23:08]  * mterry high fives robert_ancell
[23:08] <mterry> thanks
[23:30] <mdeslaur> TheMuso: sure! that would be great, thanks!
[23:41] <TheMuso> mdeslaur: np, I'll assign the bug to myself then.