[03:22] <ajmitch> ScottK: what's needed to be done for bug 788524 ?
[03:22]  * ajmitch still runs lucid on the laptop, it gets a bit hard to build source packages on here
[03:22] <ScottK> ajmitch: Needs a patch.
[03:23] <ScottK> The trick is to backport just the needed parts of python-defaults, not all of it.
[03:23] <micahg> shouldn't that bug have tasks for the appropriate releases?
[03:23] <ScottK> No.  It should be against *-backports
[03:25] <micahg> ok, then 1 or 2 -backports tasks rather than the UBuntu task
[03:25] <ajmitch> the duplicate bug says that it'll likely be done via SRU rather than backport
[03:26] <micahg> that seems risky for an SRU
[03:26] <micahg> IMHO
[03:27] <ajmitch> any SRU has some risk, if it's just dh_python2 then it just affects packages at build time
[03:38] <ajmitch> just looking at the ftbfs list, https://launchpad.net/ubuntu/+source/php-compat/1.6.0a3-1/+build/2649444 looks a bit odd
[03:38] <ajmitch> failed to upload due to a 1 jan 1970 timestamp in the .deb
[03:40]  * micahg could try in sbuild locally to see if it's reproducible
[03:41] <ajmitch> all the files in question are under the tests/ directory, so it could be an oddity of the build process that LP isn't liking
[03:58] <ScottK> I saw this happen once in qt4-x11.
[03:58] <ScottK> In that case the files were actually getting regenerated with the old time.
[03:59] <ScottK> I don't recall how.
[04:00] <ScottK> http://launchpadlibrarian.net/59228404/qt4-x11_4%3A4.7.1-0ubuntu1_4%3A4.7.1-0ubuntu2.diff.gz and the next upload too.
[04:03] <ajmitch> well it looks like the timestamps are set incorrectly in the source package in this case
[04:03] <ajmitch> -rwxr-xr-x 1 ajmitch ajmitch  526 1970-01-01 21:14 loadconstant.phpt
[04:03] <ajmitch> I guess that LP is just a bit stricter about it
[08:11] <Rhonda> duh
[08:11] <Rhonda> bug-watch-updater is … strange
[09:22] <Rhonda> http://mimiandeunice.com/2010/07/27/please/
[10:42] <iulian> Rhonda: Heh.
[10:45] <Rhonda> iulian: First thought when I saw that was the CoC :)
[14:24] <hakermania> Do you think I should speak to a MOTU so as to have the application reviewed? It's very clean and clear and I think it needs a small review... Or do you think I should way for them? :/
[14:24] <hakermania> wait*
[14:28] <iulian> Is this about a new package?
[14:37] <tumbleweed> iulian: yes it is. hakermania: I repeat my suggestion that you attempt to get it into Debian first
[14:47] <hakermania> tumbleweed, a package specially designed about ubuntu should go through ubuuntu
[14:48] <tumbleweed> oh, I thought this wasn't
[14:50] <hakermania> tumbleweed, I suppose that wallch would work on Debian but has lots of features like unity shortcuts that makes wallch an Ubuntu's package first of all
[14:58] <hakermania> And I also don't know if the featurefreeze exception has been accepted..... -_-
[14:59] <tumbleweed> hakermania: (with a release team hat on) it'll almost certainly be accepted
[14:59] <nigelb> tumbleweed: heh, didn't know you had that hat :)
[15:00] <tumbleweed> nigelb: it's new :)
[15:00] <nigelb> tumbleweed: :)
[15:05] <jtaylor> hm when the subscription of sru team gets removed from a bug without a comment, does that mean denied?
[15:05] <tumbleweed> nigelb: Laney and I are looking after FFes universe (and I'm reporting on universe status in the weekly meetings, which was why I was interested in FTBFS-jamming)
[15:06] <tumbleweed> jtaylor: that sounds more like a mistake. Was it clear it was an SRU?
[15:06] <nigelb> tumbleweed: ah!
[15:06] <jtaylor> tumbleweed: bug 811721
[15:06] <micahg> dupondje: new apcalc in Debian :)
[15:07] <tumbleweed> jtaylor: I don't see it being removed: https://bugs.launchpad.net/ubuntu/+source/pycryptopp/+bug/811721/+activity
[15:07] <jtaylor> oh I had my javascript off
[15:08] <tumbleweed> jtaylor: surely it should be nominated for natty?
[15:08] <jtaylor> did not know the subscriptions re loaded dynamically
[15:08] <jtaylor> yes
[15:10] <tsmithe> hi - i'm trying to fix bug 770742, an ftbfs that seems to have something to do with gcc 4.6, but unfortunately, i don't know enough about c++ to understand the error or find a solution..
[15:10] <hakermania> tumbleweed: even if it is, will anyone have the time to take a look?
[15:11] <tsmithe> the error is "invalid conversion from 'const SLine*' to 'SLine*' [-fpermissive]"
[15:11] <tsmithe> and the line is "SLine* sl = static_cast<const SLine*>(el);"
[15:11] <tsmithe> could someone give me a pointer? (i don't know where to find a handy gcc changelog that will help with this)
[15:12] <tumbleweed> hakermania: yeah, I'll look at it again. You could also help us by working on other packages :)
[15:12] <jtaylor> tsmithe: add a const befor SLine* sl
[15:13] <hakermania> tumbleweed, I am preparing for final school exams, but why not? If you don't have time don't look at it, seriously
[15:13] <tsmithe> jtaylor: thanks, i'll give that a go. what changed that means the cast is invalid now whilst not before?
[15:13] <micahg> ugh, why would you static_cast a const pointer to a non-const pointer
[15:13] <tsmithe> (as i said, i don't know enough about c++ semantics...)
[15:13] <tsmithe> micahg: :s i wish i knew more about this
[15:13] <jtaylor> tsmithe: the compiler is stricter, here a pointer is cast to const but the const is lost in the assignment
[15:14] <micahg> oh, I guess that does make sense to have a copy to play with
[15:14] <tsmithe> jtaylor: right, and owing to the new strictness, it won't solve it implicitly
[15:15] <tsmithe> micahg: could you explain what it means, and why you objected a second ago?
[15:15] <tsmithe> and why it's actually ok?
[15:15] <tsmithe> (i'd like to learn a little)
[15:15] <tsmithe> jtaylor: (i suppose that should have a '?' at the end)
[15:15] <jtaylor> what?
[15:15] <tsmithe> "jtaylor: right, and owing to the new strictness, it won't solve it implicitly"?
[15:16] <jtaylor> it can solve it implicitly, but the compiler sees this is a bug and complains
[15:16] <jtaylor> gcc gets increasingly better at spotting errors made by the programmer
[15:16] <jtaylor> instead of ignoring it, it now complains
[15:17] <jtaylor> if you want to drop constness, you have to use const_cast
[15:17] <jtaylor> then the compiler assumes you know what you are doing
[15:17] <hakermania> jtaylor, I can confirm this, in 11.04 I had no warnings and in 11.10 I had 4 warnings! Of course I fixed them too
[15:19] <tsmithe> jtaylor: right. i'll do what you suggested. i just wish i knew the language better so i could grasp these semantics. what i'd really like is an introduction to C++ from the perspective of academic logic, rather than from the perspective of the newbie programmer (which, i would hazard, would not cover what i'm interested in)
[15:20] <jtaylor> a few more details: what is done here is take the el pointer, and cast it to const Sline* (for whatever reason)
[15:20] <jtaylor> it then assigns it to SLine* which is not const, so the ast to const is made obsolete
[15:21] <jtaylor> c++ does not allow implicitly dropping constness, so you get an error
[15:21] <tsmithe> right, so would that mean that the cast to const is just redundant? what's its purpose?
[15:22] <jtaylor> no the cast is probably correct, but the type it is assigned to is incorrect
[15:22] <tsmithe> i suppose i don't really know what "const" actually guarantees
[15:22] <jtaylor> in efect its this: static_cast<SLine*>(static_cast<const SLine*>(el)) which is not allowed
[15:23] <jtaylor> it means the object the pointer points to ist constant and cannot be modified
[15:23] <jtaylor> so if you try to change it the compiler will detect it and error out
[15:23] <jtaylor> it is good practice to make everything const that should not change to help the compiler in spotting bugs
[15:24] <tsmithe> well, that makes sense to me at least syntactically, and your explanation fits with my intuition - thanks. unfortunately, the cast is more problematic than that, because the next line is "sl->lineSegments().size() > 0", which also generates a bug: "passing ‘const SLine’ as ‘this’ argument of ‘QList<LineSegment*> SLine::lineSegments()’ discards qualifiers [-fpermissive]"... but that's odd, to me (on the basis of your definition), because that c
[15:24] <jtaylor> and a very ugly c++ quirk: to get a constant pointer to non constant object you would do: type * const = pointer
[15:25] <tsmithe> extraordinary
[15:25] <micahg> tsmithe: here's a pointer on const pointers: http://www.learncpp.com/cpp-tutorial/610-pointers-and-const/ :)
[15:25] <tsmithe> thanks!
[15:25] <jtaylor> ok so the code is not really const correct :/
[15:25] <jtaylor> the lineSegments function should be declared const if it does not change the object
[15:26] <jtaylor> then you can use it from const pointers
[15:26] <jtaylor> has the bug been forwarded upstream?
[15:26] <micahg> tumbleweed: good to have you back to do the MOTU release update :)
[15:27] <tsmithe> jtaylor: unfortunately, no, not yet. i've been ill for a while and rather neglected the package (which i maintain in debian). tragically, they just made a new release - and so i'm frantically trying to get bugs fixed and a FFe applied for...
[15:27] <tsmithe> but, i'll speak to upstream/try to produce a patch, and work with what i've got
[15:27] <jtaylor> a simple solution to get it to compile would be to replace static_cast<const SLine*>(el) with const_cast<SLine*>(el)
[15:27] <tsmithe> they are developing on natty, so i don't suppose the gcc strictness has got them
[15:28] <jtaylor> that will behave as with gcc < 4.6
[15:28] <jtaylor> but the code should be fixed correctly
[15:28] <tsmithe> jtaylor: yes, i guessed something like that from your comment about const_cast earlier
[15:28] <tsmithe> i'll go with that bodge and forward it upstream
[15:28] <hyperair> jtaylor: out of curiosity, what's the type of el?
[15:28] <hyperair> and what are you trying to cast it to?
[15:28] <hyperair> it sounds like you're trying to cast away the const?
[15:29] <hyperair> but i don't see how static_cast<const blah*> would cause trouble.
[15:29] <tsmithe> "Element* el" is passed to the function that the bug occurs in..
[15:29] <jtaylor> hm el is not const
[15:29] <tsmithe> no..
[15:29] <jtaylor> then you can use static_cast not const_cast
[15:29] <hyperair> then you shouldn't be using const_cast at all.
[15:29] <hyperair> yeah
[15:29] <tsmithe> but the <const SLine*>?
[15:29] <hyperair> it should work.
[15:29] <jtaylor> just drop the const
[15:29] <hyperair> yea
[15:30] <tsmithe> right, thought so
[15:30] <tsmithe> bizarre
[15:30] <hyperair> but casting things from non-const to const is implicit.
[15:30] <hyperair> you don't even need a cast for that.
[15:31] <tsmithe> what differentiates <type> from (type)? (ie, what is "<...>"?)
[15:31] <hyperair> tsmithe: what you should be checking is... is Sline a parent of Element?
[15:31] <tsmithe> hyperair: i'll have a look
[15:31] <jtaylor> between the <> is the type it should be cast to
[15:31] <hyperair> so is ()
[15:31] <jtaylor> in the () is the variable beeing casted
[15:31] <hyperair> but () is a c-style cast.
[15:31] <hyperair> C++ has three different kinds of casts, all of which have different effects.
[15:31] <jtaylor> well technically no
[15:32] <hyperair> with () there's no telling which kind of cast you'd get.
[15:32] <jtaylor> only dynamic_cast has a different effect
[15:32] <hyperair> hmm no
[15:32] <jtaylor> the others do the same but have different names for code clearity
[15:32] <hyperair> reinterpret_cast is different.
[15:32] <hyperair> static, dynamic, reinterpret.
[15:32] <jtaylor> ereinterpret_cast also does a normal cast
[15:32] <hyperair> no it doesn't.
[15:32] <hyperair> if you reinterpret a float as an int, it'll go haywire
[15:32] <tsmithe> ah, the confusion isn't just mine, it seems!
[15:32] <jtaylor> yes but you can do that with static_cast to
[15:33] <tsmithe> i'll have a look at the link micahg posted
[15:33] <jtaylor> reinterpret cast does no runtime type checking
[15:33] <tsmithe> mmhmm
[15:33] <jtaylor> dynamic_cast does
[15:34] <jtaylor> the different name just exists to make it clear in the code that the type changes to something different
[15:34] <tsmithe> right
[15:34] <micahg> tumbleweed: FYI, we'll most likely need an FFe for eclipse and rdeps if I or someone else can get it working without breaking the world (I mentioned it last week in the release meeting)
[15:34] <hyperair> 23:34:27 <hyperair> {float a = -1.0; int b = static_cast<int>(a);cout << b;}
[15:34] <tsmithe> hyperair: by the looks of things, you're right - SLine is indeed a parent of Element
[15:34] <hyperair> 23:34:29 <geordi> -1
[15:34] <hyperair> 23:34:33 <hyperair> {float a = -1.0; int b = reinterpret_cast<int>(a);cout << b;}
[15:34] <hyperair> 23:34:34 <geordi> error: invalid cast from type 'float' to type 'int'
[15:35] <hyperair> tsmithe: then you can static_cast it from Element to SLine.
[15:35] <hyperair> at least, you should be able to
[15:35] <tsmithe> k. thanks for the help
[15:35] <tsmithe> and thanks for the code example :)
[15:36] <hyperair> 23:36:03 <hyperair> struct A{}; struct B : A{}; int main() { B *x = new B; const A *y = static_cast<const A*>(x); }
[15:36] <hyperair> 23:36:05 <geordi> <no output>
[15:36] <hyperair> that works.
[15:36] <jtaylor> yes for pointers its the same, builtin types not
[15:36] <jtaylor> thx did not remember that
[15:37] <tsmithe> great. and it builds!
[15:37] <tsmithe> cheers all :)
[15:37] <hyperair> =)
[15:37] <tsmithe> hopefully mad things won't happen at runtime either..
[15:38] <hyperair> actually iirc you don't even need a static_cast to cast to parent
[15:38] <hyperair> 23:38:29 <hyperair> struct A{}; struct B : A{}; int main() { B *x = new B; const A *y = x; }
[15:38] <hyperair> 23:38:31 <geordi> <no output>
[15:38] <hyperair> see
[15:39] <hyperair> jtaylor: afaik reinterpret_cast means force-cast it to whatever other type, i don't care how. i was pretty surprised to see an error message when reinterpreting a float as an int.
[15:40] <tumbleweed> micahg: thanks, yeah I saw you mention it in the minutes (although I'll admit I already forgot) :)
[15:40] <hyperair> there was a cast_damnit_cast as well iirc.
[15:40] <hyperair> =p
[15:40] <tsmithe> i'll try that as well, but it looks scary, as taking the line in isolation would make it look like el and sl were of the same type...
[15:40] <tsmithe> ah, and: "invalid conversion from ‘Element*’ to ‘SLine*’"
[15:40] <tsmithe> i'll go back to casting
[15:40] <tsmithe> hyperair: haha
[15:40] <hyperair> hmm? weird.
[15:40] <tsmithe> i'm no expert..
[15:41] <hyperair> are you sure Element is a child of SLine?
[15:41] <jtaylor> then you need a reinterpret_cast or dynamic_Cast
[15:41] <jtaylor> it should be
[15:41] <jtaylor> the type is checked above
[15:41] <jtaylor> if (el->type() == HAIRPIN || el->type() == OTTAVA || el->type() == TEXTLINE) {
[15:41] <tsmithe> hyperair: oh, crap - i misread the code. SLine is a chile of Element, not vice versa
[15:41] <hyperair> tsmithe: then it's dynamic_cast.
[15:41] <tsmithe> i think
[15:41] <hyperair> tsmithe: because you're downcasting.
[15:41] <jtaylor> reinterpret_cast would be what is intended
[15:41] <tsmithe> yet static_cast didn't give any error?
[15:41] <hyperair> i figured as much (because logically a line is an element, but an element is not necessarily a line ;-)
[15:41] <jtaylor> else probably the check would not have been used
[15:42] <hyperair> tsmithe: it should have.
[15:42] <tsmithe> hyperair: yes, sorry, i misread your initial question i think (to follow that logic..)
[15:42] <tsmithe> strange..
[15:42] <hyperair> tsmithe: oh wait, i guess you can downcast using static_cast
[15:43] <hyperair> it just doesn't do any checking.
[15:43] <hyperair> 23:42:28 <hyperair> struct B{}; struct A : B{}; int main() { B *x = new B; const A *y = static_cast<const A*>(x); }
[15:43] <hyperair> 23:42:29 <geordi> <no output>
[15:43] <tsmithe> yeah
[15:44] <tsmithe> so i'll go for dynamic_, i guess, yes?
[15:44] <hyperair> 23:43:53 <hyperair> struct B{}; struct A : B{}; struct C : B{}; int main() { B *x = new A; const C *y = static_cast<const C*>(x); }
[15:44] <hyperair> 23:43:55 <geordi> <no output>
[15:44] <hyperair> this is super unsafe.
[15:44] <tsmithe> mmm
[15:44] <hyperair> because as you can see, you can now treat y as a C.
[15:44] <hyperair> but it's not a C, but an A.
[15:44] <jtaylor> given the code context dynamic_cast is probably not wanted
[15:44] <hyperair> yeah
[15:44] <tsmithe> yes. fortunately, C and A seem pretty identical in that code
[15:44] <hyperair> since there's a ->type == blah
[15:44] <tsmithe> jtaylor: go on?
[15:44] <hyperair> i'm guessing it already knows what type it wants.
[15:44] <hyperair> but what horrible code.
[15:45] <hyperair> tsmithe: dynamic_cast is like static_cast, but slower because it checks to make sure you're casting to the correct type.
[15:46] <hyperair> tsmithe: during runtime.
[15:46] <hyperair> tsmithe: however, since you've already checked stuff like el->type() == blah blah
[15:46] <hyperair> i'm guessing that in those conditions, it can *only* be a SLine
[15:46] <hyperair> however, it's very dangerous code
[15:46] <hyperair> the potential for screwup is high.
[15:47] <tsmithe> quite. i might leave it as dynamic_ for the safety. what sort of performance tradeoff is there?
[15:47] <jtaylor> if you do that you also need to put in result checks and a bailout
[15:47] <jtaylor> else the dynamic cast is pointless as it will crash anyway
[15:47] <hyperair> tsmithe: dynamic_cast may throw if you attempt to cast like what i showed you with A and C just now.
[15:48] <hyperair> it throws std::bad_cast
[15:48] <hyperair> if you don't catch it, it'll crash.
[15:48] <hyperair> but it'll crash early and cleanly.
[15:48] <hyperair> rather than continuing on and segfaulting in some obscure manner that doesn't give you a sensible stack trace.
[15:48] <hyperair> s/may throw/will throw/
[15:48] <hyperair> actually wait, it may throw, or it may give you NULL
[15:49] <hyperair> i think.
[15:49] <jtaylor> it returns a null pointer when dealing with poiinters
[15:49] <jtaylor> it only throws when using references
[15:49] <tsmithe> surely NULL is almost as bad as continuing on and segfaulting in some obscure manner?
[15:49] <jtaylor> but I think it can be changed to always throw
[15:49] <hyperair> http://answers.yahoo.com/question/index?qid=20071106101012AAggZAk
[15:49] <hyperair> aha.
[15:49] <hyperair> it throws bad_cast when you're casting references
[15:49] <hyperair> but when you're casting pointers, it just gives you a nullptr.
[15:50] <hyperair> jtaylor: i don't think it can be.
[15:50] <hyperair> tsmithe: well almost as bad, i guess.
[15:50] <jtaylor> you could, be dereferencing it ^^
[15:50] <hyperair> but no, not quite as bad.
[15:51] <tsmithe> in that case, and because of the need for checks/bailout (which i'm not up to implementing), i'll revert to the hacky static_cast.
[15:51] <hyperair> fixing a nullptr deref segfault is much much easier than fixing memory corruption
[15:51] <hyperair> in which case you probably would get memory corruption due to an unchecked bad cast.
[15:51] <tsmithe> choices choices
[15:51] <hyperair> tsmithe: or you could static_cast, and put a comment with BIG FAT WARNING
[15:51] <tsmithe> i'll leave it at static_cast, and forward the bug upstream
[15:51] <tsmithe> with a slap on the wrist :)
[15:51] <hyperair> but at the end of the day it's upstream's choice.
[15:51] <tsmithe> quite
[15:51] <hyperair> what package is this?
[15:51] <tsmithe> musescore
[15:52]  * hyperair adds that to his mental blacklist of applications to ever use. =p
[15:52] <tsmithe> oh, it's quite a good application, in terms of functionality :p - unrivalled, you could say..
[15:53] <tsmithe> unforunately, i guess this interesting coding style might be fairly prevalent, as i do occasionally get reports of obscure segfaults that i can't reproduce...
[15:53] <tsmithe> *unfortunately
[15:53] <jtaylor> hyperair: what to you critisize about that code?
[15:53] <jtaylor> it seems to deal with deserialization, there this method is quite common
[15:53] <hyperair> oh it's deserialization.
[15:53] <hyperair> whoops =\
[15:53] <tsmithe> ?
[15:54] <hyperair> well i guess deserialization is the exception to the rule where you can use this kind of ugly code
[15:54] <jtaylor> on the other hand its xmlexport = serialization, and there it probably sucks :)
[15:54] <jtaylor> the filename
[15:54] <tsmithe> mmmm
[15:54] <jtaylor> though it was xmlimport
[15:55] <tsmithe> nope
[15:56] <jtaylor> the issue is, when serializing polymorphic objects you need to save which type they where (usually by using uuid's) when reading in you then do these kinds of if (obj->type()) static_cast<Obj*>(type)
[15:57] <jtaylor> for deserialization on the other hand you can use dynamic_cast direclty making the code often cleaner
[15:57] <tsmithe> and that's ok, because you *know* the cast will work
[15:57] <tsmithe> ?
[15:57] <jtaylor> s/de//
[15:57] <jtaylor> yes
[15:57] <jtaylor> swap serialization and deserialzation in those two sentences
[15:57] <tsmithe> i did :)
[16:01] <hyperair> um? really?
[16:02] <hyperair> sounds to me more like you'd use static_cast for performance purposes since when you're deserializing you'd know exactly what each type was.
[16:02] <jtaylor> yes, but I seaid serializing when I meant deserializing
[16:02] <hyperair> on the other hand, i don't really see a point in casting during serializing.
[16:02] <hyperair> ah
[16:02] <hyperair> right
[16:03] <hyperair> s/de// means s/deserializing/serializing/ ;-)
[16:26] <wibblymat> I'm looking for some advice on how best to help out. I joined in with a couple of bug jams last month and that was a pretty good intro to packaging. But day to day I'm struggling to find stuff to work on.
[16:26] <wibblymat> Or at least: stuff to work on that doesn't get fixed by someone else while I'm still investigating :)
[16:26] <micahg> hi wibblymat!
[16:26] <wibblymat> hi :)
[16:26] <Pici> Perhaps the bitesize bugs list? Are those still getting tagged?
[16:27] <micahg> wibblymat: I'd suggest making sure a bug is filed if you're working on an issue and set it to in progress assigned to you
[16:27] <wibblymat> The ones that are *really* bitesize go very fast
[16:27] <micahg> wibblymat: FTBFS needs a lot of help still
[16:27] <tumbleweed> yeah, there are still hundreds of those
[16:27] <tumbleweed> although a fair number might be quite tricky
[16:28] <wibblymat> I did a search: tagged as bitesize, no fix released, no branch attached. There are 257 and they all appear to be old tricky bugs that should have had the "bitesize" taken off
[16:28] <micahg> ssl1.0.0/libav transitions as well needs
[16:28] <tumbleweed> wibblymat: there are lots of good links in the topic
[16:29] <tumbleweed> yeah, this ssl transition tends to need patches, not just rebuilds
[16:29] <wibblymat> micahg: Is there a wiki page for that or somethin
[16:29] <wibblymat> oops
[16:29] <wibblymat> +g?
[16:30] <tumbleweed> wibblymat: http://people.canonical.com/~ubuntu-archive/transitions/openssl.html
[16:30] <micahg> tumbleweed: well, it's the patches ones that need help most I would think :)
[16:30] <tumbleweed> micahg: exactly
[16:31] <wibblymat> So the deal with the transition is to update the depends to 1.0.0 and then patch it until it runs again?
[16:32] <micahg> wibblymat: build-dep should be in most cases a versioned dep on libssl-dev
[16:33] <tumbleweed> and any of them using SSLv2 funcitons will need to have that code removed
[16:35] <wibblymat> I'll see what I can work out :)
[21:49] <wibblymat> If I create a branch to fix an ssl1.0.0 transition, who should I inform? There doesn't seem to be a bug open for any of them.
[21:51] <wibblymat> micahg: tumbleweed: In case either of you are the right people to tell, https://code.launchpad.net/~wibblymat/ubuntu/oneiric/cryptonit/openssl-transition/+merge/71431 is a merge request for libssl-1.0.0 work.
[21:54] <tumbleweed> wibblymat: you don't need to tell anyone anything, it'll appear on the sponsor queue
[21:54] <tumbleweed> see http://reports.qa.ubuntu.com/reports/sponsoring/
[21:54] <tumbleweed> of course, if you want feedback or to ask questions before a sponsor gets around to reviewing it, you are welcome to ask here
[21:56] <wibblymat> tumbleweed: Ah, ok, it just goes in the queue by magic :) Thanks!
[23:10] <micahg> wibblymat: thanks, I noticed that, unfortunately, there are many packages in disrepair, eventually they get dropped, but in general, the ones from Debian we don't fix up unless it's for a transition or we're taking over maintenance, so you did the right amount of work :)