[13:11] <ginggs> hi there, anyone available to nominate two bugs for particular ubuntu releases for me please?
[13:17] <penguin42> which bugs
[13:23] <ginggs> penguin42: I'd like precise and quantal tasks for LP: #1187534 and p,q and r tasks for LP: #1187507 please
[13:23] <ubot2`> Launchpad bug 1187534 in openmotif (Ubuntu) "motif-clients: unowned files after purge (policy 6.8)" [Undecided,New] https://launchpad.net/bugs/1187534
[13:23] <ubot2`> Launchpad bug 1187507 in openmotif (Ubuntu) "(open)motif should properly transition from libmotif3" [Undecided,New] https://launchpad.net/bugs/1187507
[13:24] <penguin42> ginggs: OK, give me a sec
[13:24] <penguin42> heck, openmotif - that's a rareity :-)
[13:27] <penguin42> hang on , I rarely do this
[13:28] <ginggs> I used to think openmotif was a rarity, but was shocked when I saw the number of libmotif3 vs libmotif4 installations in PopCon.
[13:28] <ginggs> Hence this SRU request.
[13:29] <penguin42> yeh there are a lot of old packages that depend on it, and people who use it to work with things they've successfully had it working with for the last 20 years
[13:33] <ginggs> penguin42: I'm not clear on the difference between nomindating for a release and creating a task for  release
[13:35] <penguin42> ginggs: Yeh that's what's also confusing me - I think it's that us BugControl's can do a nominate, but then another level is needed to accept that
[13:36] <ginggs> hmm, let me try and find out who can create tasks then
[13:36] <penguin42> ginggs: Your transitioning from libmotif3 to libmotif4 - do you really want to automatically transform from 3 to 4  is it really totally compatible
[13:38] <ginggs> penguin42: according to the openmotif 2.3.3 release notes, yes, see LP: #818220
[13:38] <ubot2`> Launchpad bug 818220 in openmotif (Ubuntu Precise) "libmotif4 should provide libmotif3 symlinks (libXm.so.3, etc.)" [Wishlist,Fix released] https://launchpad.net/bugs/818220
[13:39] <penguin42> wth did they bump the library version then if it's binary compatible?
[13:40] <ginggs> Who knows :)
[13:47] <ginggs> penguin42: I read a couple of pages, it looks like BugSquad can create tasks for a release, not sure about BugControl
[13:50] <penguin42> which page?
[14:19] <penguin42> ginggs: I'm tempted to say you need a better test case
[14:22] <ginggs> penguin42: i take it you mean better than just making sure libmotif3 upgrades cleanly to libmotif4?
[14:23] <penguin42> yeh, I mean making sure stuff that was using the libmotif3 doesn't break
[14:24] <ginggs> penguin42: well, there's nothing remaining in the archive that depends on libmotif3, that's why it got removed
[14:25] <ginggs> there are the test cases I compiled myself attached to LP: #818220
[14:25] <ubot2`> Launchpad bug 818220 in openmotif (Ubuntu Precise) "libmotif4 should provide libmotif3 symlinks (libXm.so.3, etc.)" [Wishlist,Fix released] https://launchpad.net/bugs/818220
[14:26] <penguin42> yeh it's probably as good as you can do; I still wouldn't be surprised if someone using some obscure/ancient commercial app breaks
[14:26] <ginggs> but we've pretty much accepted that libmotif4 is binary compatible with libmotif3 (and had to trust the vendor's release notes) - so now all we are testing is the transition
[14:26] <penguin42> true
[14:27] <penguin42> sorry, for rather complex reasons I've had too many bad experiences with motif incompatibilties
[14:28] <ginggs> yes, there is a chance of that, as I noted in the regression potential, but supporting obscure/ancient commercial apps is outside of Ubuntu's scope, although the intention of this SRU is to help as many people as possible by transitioning them away from the orphaned libmotif3
[14:29] <penguin42> I guess they can always grab the old packages if they hit that
[14:31] <ginggs> yup
[14:33] <penguin42> ginggs: What's the advantage of backporting bug 1187507 - i.e. what currently breaks on precise/quantal if we don't SRU it
[14:33] <ubot2`> Launchpad bug 1187507 in openmotif (Ubuntu) "(open)motif should properly transition from libmotif3" [Low,Triaged] https://launchpad.net/bugs/1187507
[14:33] <penguin42> ginggs: is it when they do install libmotif4 things break?
[14:35] <ginggs> In p,q and r manually installing libmotif4 is OK, in saucy and sid that is a problem which we decided to fix by introduce the libmotif3 transitional package
[14:36] <penguin42> ok, so what's the advantage of SRU'ing it
[14:36] <ginggs> it was then that I discovered that according to popcon there are 25000+ installations of libmotif3 and only 3600+ of libmotif4
[14:37] <penguin42> heck that's quite a number isn't it
[14:37] <ginggs> so we can let these people wait until saucy or the 14.04 LTS to get transitioned to the new packages, but I figure the sooner the better
[14:38] <penguin42> ok - but that's the bit I'm arguing with; the SRU has a small chance of breaking something - but unless there's an advantage to doing that I don't think we shoudl risk it
[14:39] <penguin42> I mean, does libmotif4 have security fixes that 3 doesn't have - and putting those transitions in would help keep it secure?
[14:42] <ginggs> according to the release notes [ http://motif.ics.com/open-motif-233-release-notes ] 2.3.3 is a bug fix release, i quickly scanned the list of bugs fixed, none of them seem like security fixes
[14:44] <penguin42> actually, that list of bugs on it's own could be enough of an argument for SRU?
[14:44] <ginggs> as you noted, why on earth would they bump the so name for a bug fix release in version 2.3.3, when they were happy to leave it the same between 2.2 and 2.3
[14:45] <ginggs> good point, shall I add a link to the release notes and list the bugs fixed?
[14:46] <penguin42> yeh, IMHO that would be a reasonable justification
[14:47] <ginggs> going to do that now, thanks
[15:01] <ginggs> ok, done
[15:09] <penguin42> ginggs: You said that there was a page saying that BS can create tasks for a release - does it say how?
[15:10] <penguin42> (I've done the nominations)
[15:10] <ginggs> penguin42: sorry closed the page. i have to run now but will be back in about an hour.  thanks for your input - much appreciated!
[15:11] <penguin42> np
[16:32] <ginggs> penguin42: do you perhaps get an extra field to choose the release if you click on 'also affects distribution'?
[16:33] <penguin42> ginggs: No, I just get distribution, Source package name and url
[16:33] <penguin42> and the distribution doesn't have anything more
[16:33] <ginggs> i know someone i can ask, but he doesn't seem to be online now
[16:34] <penguin42> ginggs: bdmurray_ is the person I'd ask if he's awake
[16:35] <ginggs> btw: source package motif only exists in saucy and sid at the moment, the source package is still called openmotif in p, q and r
[16:35] <penguin42> how did that happen - is that some change of licensing/release?
[16:36] <ginggs> just to confuse matters further openmotif is not truly open hence resides in non-free
[16:36] <penguin42> ah, that's why I didn't find it in an apt-cache search
[16:36] <ginggs> motif 2.3.4 is now truly open source
[16:37] <penguin42> did they ever release the motif 1 source? I had to work with it about 5 years ago
[16:37] <ginggs> http://motif.ics.com/article/news
[16:39] <ginggs> no i don't think they released motif 1, there is a git at http://sourceforge.net/p/motif/code/commit_browser but only goes back as far as 2.1
[16:40] <penguin42> I seem to remember the ordering for it asked you what format tape you wanted it on
[16:42] <penguin42> ginggs: Out of vague interest, what do you use motif for?
[16:44] <ginggs> I don't personally, I have users who use Ansys GAMBIT among other applications that require libXm.so.3
[16:45] <penguin42> ah right
[16:45] <ginggs> so when they upgraded from lucid libmotif3 disappeared and it became my problem
[16:45] <penguin42> haha yeh
[16:46] <ginggs> ...and now I am the DM for motif :)
[16:46]  * penguin42 points the blame-resolution-operator at ginggs
[16:48] <ginggs> and yourself? why did you need to work with it?
[16:49] <penguin42> I used to have a job that involved porting from old sunos to Linux
[16:56] <ginggs> sounds like fun ;)
[16:57] <penguin42> never underestimate what bugs an application can depend on