[03:22] ScottK: what's needed to be done for bug 788524 ? [03:22] 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] ajmitch: Needs a patch. [03:23] The trick is to backport just the needed parts of python-defaults, not all of it. [03:23] shouldn't that bug have tasks for the appropriate releases? [03:23] No. It should be against *-backports [03:25] ok, then 1 or 2 -backports tasks rather than the UBuntu task [03:25] the duplicate bug says that it'll likely be done via SRU rather than backport [03:26] that seems risky for an SRU [03:26] IMHO [03:27] any SRU has some risk, if it's just dh_python2 then it just affects packages at build time [03:38] 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] 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] 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] I saw this happen once in qt4-x11. [03:58] In that case the files were actually getting regenerated with the old time. [03:59] I don't recall how. [04:00] 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] well it looks like the timestamps are set incorrectly in the source package in this case [04:03] -rwxr-xr-x 1 ajmitch ajmitch 526 1970-01-01 21:14 loadconstant.phpt [04:03] I guess that LP is just a bit stricter about it [08:11] duh [08:11] bug-watch-updater is … strange [09:22] http://mimiandeunice.com/2010/07/27/please/ === medberry is now known as med_out [10:42] Rhonda: Heh. [10:45] iulian: First thought when I saw that was the CoC :) [14:24] 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] wait* [14:28] Is this about a new package? [14:37] iulian: yes it is. hakermania: I repeat my suggestion that you attempt to get it into Debian first === micahg_ is now known as micahg [14:47] tumbleweed, a package specially designed about ubuntu should go through ubuuntu [14:48] oh, I thought this wasn't [14:50] 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] And I also don't know if the featurefreeze exception has been accepted..... -_- [14:59] hakermania: (with a release team hat on) it'll almost certainly be accepted [14:59] tumbleweed: heh, didn't know you had that hat :) [15:00] nigelb: it's new :) [15:00] tumbleweed: :) [15:05] hm when the subscription of sru team gets removed from a bug without a comment, does that mean denied? [15:05] 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] jtaylor: that sounds more like a mistake. Was it clear it was an SRU? [15:06] tumbleweed: ah! [15:06] tumbleweed: bug 811721 [15:06] 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] dupondje: new apcalc in Debian :) [15:07] jtaylor: I don't see it being removed: https://bugs.launchpad.net/ubuntu/+source/pycryptopp/+bug/811721/+activity [15:07] oh I had my javascript off [15:08] jtaylor: surely it should be nominated for natty? [15:08] did not know the subscriptions re loaded dynamically [15:08] yes [15:10] 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] tumbleweed: even if it is, will anyone have the time to take a look? [15:10] 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:11] the error is "invalid conversion from 'const SLine*' to 'SLine*' [-fpermissive]" [15:11] and the line is "SLine* sl = static_cast(el);" [15:11] could someone give me a pointer? (i don't know where to find a handy gcc changelog that will help with this) [15:12] hakermania: yeah, I'll look at it again. You could also help us by working on other packages :) [15:12] tsmithe: add a const befor SLine* sl [15:13] 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] jtaylor: thanks, i'll give that a go. what changed that means the cast is invalid now whilst not before? [15:13] ugh, why would you static_cast a const pointer to a non-const pointer [15:13] (as i said, i don't know enough about c++ semantics...) [15:13] micahg: :s i wish i knew more about this [15:13] tsmithe: the compiler is stricter, here a pointer is cast to const but the const is lost in the assignment [15:14] oh, I guess that does make sense to have a copy to play with [15:14] jtaylor: right, and owing to the new strictness, it won't solve it implicitly [15:15] micahg: could you explain what it means, and why you objected a second ago? [15:15] and why it's actually ok? [15:15] (i'd like to learn a little) [15:15] jtaylor: (i suppose that should have a '?' at the end) [15:15] what? [15:15] "jtaylor: right, and owing to the new strictness, it won't solve it implicitly"? [15:16] it can solve it implicitly, but the compiler sees this is a bug and complains [15:16] gcc gets increasingly better at spotting errors made by the programmer [15:16] instead of ignoring it, it now complains [15:17] if you want to drop constness, you have to use const_cast [15:17] then the compiler assumes you know what you are doing [15:17] 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] 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] a few more details: what is done here is take the el pointer, and cast it to const Sline* (for whatever reason) [15:20] it then assigns it to SLine* which is not const, so the ast to const is made obsolete [15:21] c++ does not allow implicitly dropping constness, so you get an error [15:21] right, so would that mean that the cast to const is just redundant? what's its purpose? [15:22] no the cast is probably correct, but the type it is assigned to is incorrect [15:22] i suppose i don't really know what "const" actually guarantees [15:22] in efect its this: static_cast(static_cast(el)) which is not allowed [15:23] it means the object the pointer points to ist constant and cannot be modified [15:23] so if you try to change it the compiler will detect it and error out [15:23] it is good practice to make everything const that should not change to help the compiler in spotting bugs [15:24] 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 SLine::lineSegments()’ discards qualifiers [-fpermissive]"... but that's odd, to me (on the basis of your definition), because that c [15:24] and a very ugly c++ quirk: to get a constant pointer to non constant object you would do: type * const = pointer [15:25] extraordinary [15:25] tsmithe: here's a pointer on const pointers: http://www.learncpp.com/cpp-tutorial/610-pointers-and-const/ :) [15:25] thanks! [15:25] ok so the code is not really const correct :/ [15:25] the lineSegments function should be declared const if it does not change the object [15:26] then you can use it from const pointers [15:26] has the bug been forwarded upstream? [15:26] tumbleweed: good to have you back to do the MOTU release update :) [15:27] 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] but, i'll speak to upstream/try to produce a patch, and work with what i've got [15:27] a simple solution to get it to compile would be to replace static_cast(el) with const_cast(el) [15:27] they are developing on natty, so i don't suppose the gcc strictness has got them [15:28] that will behave as with gcc < 4.6 [15:28] but the code should be fixed correctly [15:28] jtaylor: yes, i guessed something like that from your comment about const_cast earlier [15:28] i'll go with that bodge and forward it upstream [15:28] jtaylor: out of curiosity, what's the type of el? [15:28] and what are you trying to cast it to? [15:28] it sounds like you're trying to cast away the const? [15:29] but i don't see how static_cast would cause trouble. [15:29] "Element* el" is passed to the function that the bug occurs in.. [15:29] hm el is not const [15:29] no.. [15:29] then you can use static_cast not const_cast [15:29] then you shouldn't be using const_cast at all. [15:29] yeah [15:29] but the ? [15:29] it should work. [15:29] just drop the const [15:29] yea [15:30] right, thought so [15:30] bizarre [15:30] but casting things from non-const to const is implicit. [15:30] you don't even need a cast for that. [15:31] what differentiates from (type)? (ie, what is "<...>"?) [15:31] tsmithe: what you should be checking is... is Sline a parent of Element? [15:31] hyperair: i'll have a look [15:31] between the <> is the type it should be cast to [15:31] so is () [15:31] in the () is the variable beeing casted [15:31] but () is a c-style cast. [15:31] C++ has three different kinds of casts, all of which have different effects. [15:31] well technically no [15:32] with () there's no telling which kind of cast you'd get. [15:32] only dynamic_cast has a different effect [15:32] hmm no [15:32] the others do the same but have different names for code clearity [15:32] reinterpret_cast is different. [15:32] static, dynamic, reinterpret. [15:32] ereinterpret_cast also does a normal cast [15:32] no it doesn't. [15:32] if you reinterpret a float as an int, it'll go haywire [15:32] ah, the confusion isn't just mine, it seems! [15:32] yes but you can do that with static_cast to [15:33] i'll have a look at the link micahg posted [15:33] reinterpret cast does no runtime type checking [15:33] mmhmm [15:33] dynamic_cast does [15:34] the different name just exists to make it clear in the code that the type changes to something different [15:34] right [15:34] 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] 23:34:27 {float a = -1.0; int b = static_cast(a);cout << b;} [15:34] hyperair: by the looks of things, you're right - SLine is indeed a parent of Element [15:34] 23:34:29 -1 [15:34] 23:34:33 {float a = -1.0; int b = reinterpret_cast(a);cout << b;} [15:34] 23:34:34 error: invalid cast from type 'float' to type 'int' [15:35] tsmithe: then you can static_cast it from Element to SLine. [15:35] at least, you should be able to [15:35] k. thanks for the help [15:35] and thanks for the code example :) [15:36] 23:36:03 struct A{}; struct B : A{}; int main() { B *x = new B; const A *y = static_cast(x); } [15:36] 23:36:05 [15:36] that works. [15:36] yes for pointers its the same, builtin types not [15:36] thx did not remember that [15:37] great. and it builds! [15:37] cheers all :) [15:37] =) [15:37] hopefully mad things won't happen at runtime either.. [15:38] actually iirc you don't even need a static_cast to cast to parent [15:38] 23:38:29 struct A{}; struct B : A{}; int main() { B *x = new B; const A *y = x; } [15:38] 23:38:31 [15:38] see [15:39] 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] micahg: thanks, yeah I saw you mention it in the minutes (although I'll admit I already forgot) :) [15:40] there was a cast_damnit_cast as well iirc. [15:40] =p [15:40] 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] ah, and: "invalid conversion from ‘Element*’ to ‘SLine*’" [15:40] i'll go back to casting [15:40] hyperair: haha [15:40] hmm? weird. [15:40] i'm no expert.. [15:41] are you sure Element is a child of SLine? [15:41] then you need a reinterpret_cast or dynamic_Cast [15:41] it should be [15:41] the type is checked above [15:41] if (el->type() == HAIRPIN || el->type() == OTTAVA || el->type() == TEXTLINE) { [15:41] hyperair: oh, crap - i misread the code. SLine is a chile of Element, not vice versa [15:41] tsmithe: then it's dynamic_cast. [15:41] i think [15:41] tsmithe: because you're downcasting. [15:41] reinterpret_cast would be what is intended [15:41] yet static_cast didn't give any error? [15:41] i figured as much (because logically a line is an element, but an element is not necessarily a line ;-) [15:41] else probably the check would not have been used [15:42] tsmithe: it should have. [15:42] hyperair: yes, sorry, i misread your initial question i think (to follow that logic..) [15:42] strange.. [15:42] tsmithe: oh wait, i guess you can downcast using static_cast [15:43] it just doesn't do any checking. [15:43] 23:42:28 struct B{}; struct A : B{}; int main() { B *x = new B; const A *y = static_cast(x); } [15:43] 23:42:29 [15:43] yeah [15:44] so i'll go for dynamic_, i guess, yes? [15:44] 23:43:53 struct B{}; struct A : B{}; struct C : B{}; int main() { B *x = new A; const C *y = static_cast(x); } [15:44] 23:43:55 [15:44] this is super unsafe. [15:44] mmm [15:44] because as you can see, you can now treat y as a C. [15:44] but it's not a C, but an A. [15:44] given the code context dynamic_cast is probably not wanted [15:44] yeah [15:44] yes. fortunately, C and A seem pretty identical in that code [15:44] since there's a ->type == blah [15:44] jtaylor: go on? [15:44] i'm guessing it already knows what type it wants. [15:44] but what horrible code. [15:45] tsmithe: dynamic_cast is like static_cast, but slower because it checks to make sure you're casting to the correct type. [15:46] tsmithe: during runtime. [15:46] tsmithe: however, since you've already checked stuff like el->type() == blah blah [15:46] i'm guessing that in those conditions, it can *only* be a SLine [15:46] however, it's very dangerous code [15:46] the potential for screwup is high. [15:47] quite. i might leave it as dynamic_ for the safety. what sort of performance tradeoff is there? [15:47] if you do that you also need to put in result checks and a bailout [15:47] else the dynamic cast is pointless as it will crash anyway [15:47] tsmithe: dynamic_cast may throw if you attempt to cast like what i showed you with A and C just now. [15:48] it throws std::bad_cast [15:48] if you don't catch it, it'll crash. [15:48] but it'll crash early and cleanly. [15:48] rather than continuing on and segfaulting in some obscure manner that doesn't give you a sensible stack trace. [15:48] s/may throw/will throw/ [15:48] actually wait, it may throw, or it may give you NULL [15:49] i think. [15:49] it returns a null pointer when dealing with poiinters [15:49] it only throws when using references [15:49] surely NULL is almost as bad as continuing on and segfaulting in some obscure manner? [15:49] but I think it can be changed to always throw [15:49] http://answers.yahoo.com/question/index?qid=20071106101012AAggZAk [15:49] aha. [15:49] it throws bad_cast when you're casting references [15:49] but when you're casting pointers, it just gives you a nullptr. [15:50] jtaylor: i don't think it can be. [15:50] tsmithe: well almost as bad, i guess. [15:50] you could, be dereferencing it ^^ [15:50] but no, not quite as bad. [15:51] 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] fixing a nullptr deref segfault is much much easier than fixing memory corruption [15:51] in which case you probably would get memory corruption due to an unchecked bad cast. [15:51] choices choices [15:51] tsmithe: or you could static_cast, and put a comment with BIG FAT WARNING [15:51] i'll leave it at static_cast, and forward the bug upstream [15:51] with a slap on the wrist :) [15:51] but at the end of the day it's upstream's choice. [15:51] quite [15:51] what package is this? [15:51] musescore [15:52] * hyperair adds that to his mental blacklist of applications to ever use. =p [15:52] oh, it's quite a good application, in terms of functionality :p - unrivalled, you could say.. [15:53] 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] *unfortunately [15:53] hyperair: what to you critisize about that code? [15:53] it seems to deal with deserialization, there this method is quite common [15:53] oh it's deserialization. [15:53] whoops =\ [15:53] ? [15:54] well i guess deserialization is the exception to the rule where you can use this kind of ugly code [15:54] on the other hand its xmlexport = serialization, and there it probably sucks :) [15:54] the filename [15:54] mmmm [15:54] though it was xmlimport [15:55] nope [15:56] 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(type) [15:57] for deserialization on the other hand you can use dynamic_cast direclty making the code often cleaner [15:57] and that's ok, because you *know* the cast will work [15:57] ? [15:57] s/de// [15:57] yes [15:57] swap serialization and deserialzation in those two sentences [15:57] i did :) [16:01] um? really? [16:02] 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] yes, but I seaid serializing when I meant deserializing [16:02] on the other hand, i don't really see a point in casting during serializing. [16:02] ah [16:02] right [16:03] s/de// means s/deserializing/serializing/ ;-) [16:26] 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] Or at least: stuff to work on that doesn't get fixed by someone else while I'm still investigating :) [16:26] hi wibblymat! [16:26] hi :) [16:26] Perhaps the bitesize bugs list? Are those still getting tagged? [16:27] 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] The ones that are *really* bitesize go very fast [16:27] wibblymat: FTBFS needs a lot of help still [16:27] yeah, there are still hundreds of those [16:27] although a fair number might be quite tricky [16:28] 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] ssl1.0.0/libav transitions as well needs [16:28] wibblymat: there are lots of good links in the topic [16:29] yeah, this ssl transition tends to need patches, not just rebuilds [16:29] micahg: Is there a wiki page for that or somethin [16:29] oops [16:29] +g? [16:30] wibblymat: http://people.canonical.com/~ubuntu-archive/transitions/openssl.html [16:30] tumbleweed: well, it's the patches ones that need help most I would think :) [16:30] micahg: exactly [16:31] 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] wibblymat: build-dep should be in most cases a versioned dep on libssl-dev [16:33] and any of them using SSLv2 funcitons will need to have that code removed [16:35] I'll see what I can work out :) [21:49] 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] 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] wibblymat: you don't need to tell anyone anything, it'll appear on the sponsor queue [21:54] see http://reports.qa.ubuntu.com/reports/sponsoring/ [21:54] 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] tumbleweed: Ah, ok, it just goes in the queue by magic :) Thanks! === yofel_ is now known as yofel [23:10] 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 :) === emma is now known as em