ajmitch | ScottK: what's needed to be done for bug 788524 ? | 03:22 |
---|---|---|
ubottu | Launchpad bug 788524 in python-defaults (Ubuntu) "backport dh_python2 to lucid (and maverick if appropriate)" [Undecided,In progress] https://launchpad.net/bugs/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:22 |
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:23 |
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:25 |
micahg | that seems risky for an SRU | 03:26 |
micahg | IMHO | 03:26 |
ajmitch | any SRU has some risk, if it's just dh_python2 then it just affects packages at build time | 03:27 |
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:38 |
* micahg could try in sbuild locally to see if it's reproducible | 03:40 | |
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:41 |
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:58 |
ScottK | I don't recall how. | 03:59 |
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:00 |
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 | 04:03 |
Rhonda | duh | 08:11 |
Rhonda | bug-watch-updater is … strange | 08:11 |
Rhonda | http://mimiandeunice.com/2010/07/27/please/ | 09:22 |
=== medberry is now known as med_out | ||
iulian | Rhonda: Heh. | 10:42 |
Rhonda | iulian: First thought when I saw that was the CoC :) | 10:45 |
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:24 |
iulian | Is this about a new package? | 14:28 |
tumbleweed | iulian: yes it is. hakermania: I repeat my suggestion that you attempt to get it into Debian first | 14:37 |
=== micahg_ is now known as micahg | ||
hakermania | tumbleweed, a package specially designed about ubuntu should go through ubuuntu | 14:47 |
tumbleweed | oh, I thought this wasn't | 14:48 |
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:50 |
hakermania | And I also don't know if the featurefreeze exception has been accepted..... -_- | 14:58 |
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 :) | 14:59 |
tumbleweed | nigelb: it's new :) | 15:00 |
nigelb | tumbleweed: :) | 15:00 |
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:05 |
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 |
ubottu | Launchpad bug 811721 in pycryptopp (Ubuntu) "update pycryptopp to version 0.5.29-1 in natty" [Undecided,Confirmed] https://launchpad.net/bugs/811721 | 15:06 |
micahg | dupondje: new apcalc in Debian :) | 15:06 |
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:07 |
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:08 |
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:10 |
ubottu | Launchpad bug 770742 in musescore (Ubuntu Oneiric) "musescore version 1.0+dfsg-2 failed to build on amd64 with GCC-4.6/oneiric" [High,Confirmed] https://launchpad.net/bugs/770742 | 15:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
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:19 |
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:20 |
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:21 |
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:22 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
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:31 |
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:32 |
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:33 |
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:34 |
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:35 |
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:36 |
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:37 |
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:38 |
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:39 |
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:40 |
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:41 |
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:42 |
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:43 |
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:44 |
hyperair | tsmithe: dynamic_cast is like static_cast, but slower because it checks to make sure you're casting to the correct type. | 15:45 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
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:51 |
* 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:52 |
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:53 |
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:54 |
tsmithe | nope | 15:55 |
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:56 |
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 :) | 15:57 |
hyperair | um? really? | 16:01 |
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:02 |
hyperair | s/de// means s/deserializing/serializing/ ;-) | 16:03 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
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:31 |
micahg | wibblymat: build-dep should be in most cases a versioned dep on libssl-dev | 16:32 |
tumbleweed | and any of them using SSLv2 funcitons will need to have that code removed | 16:33 |
wibblymat | I'll see what I can work out :) | 16:35 |
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:49 |
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:51 |
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:54 |
wibblymat | tumbleweed: Ah, ok, it just goes in the queue by magic :) Thanks! | 21:56 |
=== yofel_ is now known as yofel | ||
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 :) | 23:10 |
=== emma is now known as em |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!