/srv/irclogs.ubuntu.com/2011/08/12/#ubuntu-motu.txt

ajmitchScottK: what's needed to be done for bug 788524 ?03:22
ubottuLaunchpad bug 788524 in python-defaults (Ubuntu) "backport dh_python2 to lucid (and maverick if appropriate)" [Undecided,In progress] https://launchpad.net/bugs/78852403:22
* ajmitch still runs lucid on the laptop, it gets a bit hard to build source packages on here03:22
ScottKajmitch: Needs a patch.03:22
ScottKThe trick is to backport just the needed parts of python-defaults, not all of it.03:23
micahgshouldn't that bug have tasks for the appropriate releases?03:23
ScottKNo.  It should be against *-backports03:23
micahgok, then 1 or 2 -backports tasks rather than the UBuntu task03:25
ajmitchthe duplicate bug says that it'll likely be done via SRU rather than backport03:25
micahgthat seems risky for an SRU03:26
micahgIMHO03:26
ajmitchany SRU has some risk, if it's just dh_python2 then it just affects packages at build time03:27
ajmitchjust looking at the ftbfs list, https://launchpad.net/ubuntu/+source/php-compat/1.6.0a3-1/+build/2649444 looks a bit odd03:38
ajmitchfailed to upload due to a 1 jan 1970 timestamp in the .deb03:38
* micahg could try in sbuild locally to see if it's reproducible03:40
ajmitchall the files in question are under the tests/ directory, so it could be an oddity of the build process that LP isn't liking03:41
ScottKI saw this happen once in qt4-x11.03:58
ScottKIn that case the files were actually getting regenerated with the old time.03:58
ScottKI don't recall how.03:59
ScottKhttp://launchpadlibrarian.net/59228404/qt4-x11_4%3A4.7.1-0ubuntu1_4%3A4.7.1-0ubuntu2.diff.gz and the next upload too.04:00
ajmitchwell it looks like the timestamps are set incorrectly in the source package in this case04:03
ajmitch-rwxr-xr-x 1 ajmitch ajmitch  526 1970-01-01 21:14 loadconstant.phpt04:03
ajmitchI guess that LP is just a bit stricter about it04:03
Rhondaduh08:11
Rhondabug-watch-updater is … strange08:11
Rhondahttp://mimiandeunice.com/2010/07/27/please/09:22
=== medberry is now known as med_out
iulianRhonda: Heh.10:42
Rhondaiulian: First thought when I saw that was the CoC :)10:45
hakermaniaDo 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
hakermaniawait*14:24
iulianIs this about a new package?14:28
tumbleweediulian: yes it is. hakermania: I repeat my suggestion that you attempt to get it into Debian first14:37
=== micahg_ is now known as micahg
hakermaniatumbleweed, a package specially designed about ubuntu should go through ubuuntu14:47
tumbleweedoh, I thought this wasn't14:48
hakermaniatumbleweed, 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 all14:50
hakermaniaAnd I also don't know if the featurefreeze exception has been accepted..... -_-14:58
tumbleweedhakermania: (with a release team hat on) it'll almost certainly be accepted14:59
nigelbtumbleweed: heh, didn't know you had that hat :)14:59
tumbleweednigelb: it's new :)15:00
nigelbtumbleweed: :)15:00
jtaylorhm when the subscription of sru team gets removed from a bug without a comment, does that mean denied?15:05
tumbleweednigelb: 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
tumbleweedjtaylor: that sounds more like a mistake. Was it clear it was an SRU?15:06
nigelbtumbleweed: ah!15:06
jtaylortumbleweed: bug 81172115:06
ubottuLaunchpad bug 811721 in pycryptopp (Ubuntu) "update pycryptopp to version 0.5.29-1 in natty" [Undecided,Confirmed] https://launchpad.net/bugs/81172115:06
micahgdupondje: new apcalc in Debian :)15:06
tumbleweedjtaylor: I don't see it being removed: https://bugs.launchpad.net/ubuntu/+source/pycryptopp/+bug/811721/+activity15:07
jtayloroh I had my javascript off15:07
tumbleweedjtaylor: surely it should be nominated for natty?15:08
jtaylordid not know the subscriptions re loaded dynamically15:08
jtayloryes15:08
tsmithehi - 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
hakermaniatumbleweed: even if it is, will anyone have the time to take a look?15:10
ubottuLaunchpad 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/77074215:10
tsmithethe error is "invalid conversion from 'const SLine*' to 'SLine*' [-fpermissive]"15:11
tsmitheand the line is "SLine* sl = static_cast<const SLine*>(el);"15:11
tsmithecould someone give me a pointer? (i don't know where to find a handy gcc changelog that will help with this)15:11
tumbleweedhakermania: yeah, I'll look at it again. You could also help us by working on other packages :)15:12
jtaylortsmithe: add a const befor SLine* sl15:12
hakermaniatumbleweed, I am preparing for final school exams, but why not? If you don't have time don't look at it, seriously15:13
tsmithejtaylor: thanks, i'll give that a go. what changed that means the cast is invalid now whilst not before?15:13
micahgugh, why would you static_cast a const pointer to a non-const pointer15:13
tsmithe(as i said, i don't know enough about c++ semantics...)15:13
tsmithemicahg: :s i wish i knew more about this15:13
jtaylortsmithe: the compiler is stricter, here a pointer is cast to const but the const is lost in the assignment15:13
micahgoh, I guess that does make sense to have a copy to play with15:14
tsmithejtaylor: right, and owing to the new strictness, it won't solve it implicitly15:14
tsmithemicahg: could you explain what it means, and why you objected a second ago?15:15
tsmitheand why it's actually ok?15:15
tsmithe(i'd like to learn a little)15:15
tsmithejtaylor: (i suppose that should have a '?' at the end)15:15
jtaylorwhat?15:15
tsmithe"jtaylor: right, and owing to the new strictness, it won't solve it implicitly"?15:15
jtaylorit can solve it implicitly, but the compiler sees this is a bug and complains15:16
jtaylorgcc gets increasingly better at spotting errors made by the programmer15:16
jtaylorinstead of ignoring it, it now complains15:16
jtaylorif you want to drop constness, you have to use const_cast15:17
jtaylorthen the compiler assumes you know what you are doing15:17
hakermaniajtaylor, I can confirm this, in 11.04 I had no warnings and in 11.10 I had 4 warnings! Of course I fixed them too15:17
tsmithejtaylor: 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
jtaylora few more details: what is done here is take the el pointer, and cast it to const Sline* (for whatever reason)15:20
jtaylorit then assigns it to SLine* which is not const, so the ast to const is made obsolete15:20
jtaylorc++ does not allow implicitly dropping constness, so you get an error15:21
tsmitheright, so would that mean that the cast to const is just redundant? what's its purpose?15:21
jtaylorno the cast is probably correct, but the type it is assigned to is incorrect15:22
tsmithei suppose i don't really know what "const" actually guarantees15:22
jtaylorin efect its this: static_cast<SLine*>(static_cast<const SLine*>(el)) which is not allowed15:22
jtaylorit means the object the pointer points to ist constant and cannot be modified15:23
jtaylorso if you try to change it the compiler will detect it and error out15:23
jtaylorit is good practice to make everything const that should not change to help the compiler in spotting bugs15:23
tsmithewell, 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 c15:24
jtaylorand a very ugly c++ quirk: to get a constant pointer to non constant object you would do: type * const = pointer15:24
tsmitheextraordinary15:25
micahgtsmithe: here's a pointer on const pointers: http://www.learncpp.com/cpp-tutorial/610-pointers-and-const/ :)15:25
tsmithethanks!15:25
jtaylorok so the code is not really const correct :/15:25
jtaylorthe lineSegments function should be declared const if it does not change the object15:25
jtaylorthen you can use it from const pointers15:26
jtaylorhas the bug been forwarded upstream?15:26
micahgtumbleweed: good to have you back to do the MOTU release update :)15:26
tsmithejtaylor: 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
tsmithebut, i'll speak to upstream/try to produce a patch, and work with what i've got15:27
jtaylora simple solution to get it to compile would be to replace static_cast<const SLine*>(el) with const_cast<SLine*>(el)15:27
tsmithethey are developing on natty, so i don't suppose the gcc strictness has got them15:27
jtaylorthat will behave as with gcc < 4.615:28
jtaylorbut the code should be fixed correctly15:28
tsmithejtaylor: yes, i guessed something like that from your comment about const_cast earlier15:28
tsmithei'll go with that bodge and forward it upstream15:28
hyperairjtaylor: out of curiosity, what's the type of el?15:28
hyperairand what are you trying to cast it to?15:28
hyperairit sounds like you're trying to cast away the const?15:28
hyperairbut 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
jtaylorhm el is not const15:29
tsmitheno..15:29
jtaylorthen you can use static_cast not const_cast15:29
hyperairthen you shouldn't be using const_cast at all.15:29
hyperairyeah15:29
tsmithebut the <const SLine*>?15:29
hyperairit should work.15:29
jtaylorjust drop the const15:29
hyperairyea15:29
tsmitheright, thought so15:30
tsmithebizarre15:30
hyperairbut casting things from non-const to const is implicit.15:30
hyperairyou don't even need a cast for that.15:30
tsmithewhat differentiates <type> from (type)? (ie, what is "<...>"?)15:31
hyperairtsmithe: what you should be checking is... is Sline a parent of Element?15:31
tsmithehyperair: i'll have a look15:31
jtaylorbetween the <> is the type it should be cast to15:31
hyperairso is ()15:31
jtaylorin the () is the variable beeing casted15:31
hyperairbut () is a c-style cast.15:31
hyperairC++ has three different kinds of casts, all of which have different effects.15:31
jtaylorwell technically no15:31
hyperairwith () there's no telling which kind of cast you'd get.15:32
jtayloronly dynamic_cast has a different effect15:32
hyperairhmm no15:32
jtaylorthe others do the same but have different names for code clearity15:32
hyperairreinterpret_cast is different.15:32
hyperairstatic, dynamic, reinterpret.15:32
jtaylorereinterpret_cast also does a normal cast15:32
hyperairno it doesn't.15:32
hyperairif you reinterpret a float as an int, it'll go haywire15:32
tsmitheah, the confusion isn't just mine, it seems!15:32
jtayloryes but you can do that with static_cast to15:32
tsmithei'll have a look at the link micahg posted15:33
jtaylorreinterpret cast does no runtime type checking15:33
tsmithemmhmm15:33
jtaylordynamic_cast does15:33
jtaylorthe different name just exists to make it clear in the code that the type changes to something different15:34
tsmitheright15:34
micahgtumbleweed: 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
hyperair23:34:27 <hyperair> {float a = -1.0; int b = static_cast<int>(a);cout << b;}15:34
tsmithehyperair: by the looks of things, you're right - SLine is indeed a parent of Element15:34
hyperair23:34:29 <geordi> -115:34
hyperair23:34:33 <hyperair> {float a = -1.0; int b = reinterpret_cast<int>(a);cout << b;}15:34
hyperair23:34:34 <geordi> error: invalid cast from type 'float' to type 'int'15:34
hyperairtsmithe: then you can static_cast it from Element to SLine.15:35
hyperairat least, you should be able to15:35
tsmithek. thanks for the help15:35
tsmitheand thanks for the code example :)15:35
hyperair23:36:03 <hyperair> struct A{}; struct B : A{}; int main() { B *x = new B; const A *y = static_cast<const A*>(x); }15:36
hyperair23:36:05 <geordi> <no output>15:36
hyperairthat works.15:36
jtayloryes for pointers its the same, builtin types not15:36
jtaylorthx did not remember that15:36
tsmithegreat. and it builds!15:37
tsmithecheers all :)15:37
hyperair=)15:37
tsmithehopefully mad things won't happen at runtime either..15:37
hyperairactually iirc you don't even need a static_cast to cast to parent15:38
hyperair23:38:29 <hyperair> struct A{}; struct B : A{}; int main() { B *x = new B; const A *y = x; }15:38
hyperair23:38:31 <geordi> <no output>15:38
hyperairsee15:38
hyperairjtaylor: 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
tumbleweedmicahg: thanks, yeah I saw you mention it in the minutes (although I'll admit I already forgot) :)15:40
hyperairthere was a cast_damnit_cast as well iirc.15:40
hyperair=p15:40
tsmithei'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
tsmitheah, and: "invalid conversion from ‘Element*’ to ‘SLine*’"15:40
tsmithei'll go back to casting15:40
tsmithehyperair: haha15:40
hyperairhmm? weird.15:40
tsmithei'm no expert..15:40
hyperairare you sure Element is a child of SLine?15:41
jtaylorthen you need a reinterpret_cast or dynamic_Cast15:41
jtaylorit should be15:41
jtaylorthe type is checked above15:41
jtaylorif (el->type() == HAIRPIN || el->type() == OTTAVA || el->type() == TEXTLINE) {15:41
tsmithehyperair: oh, crap - i misread the code. SLine is a chile of Element, not vice versa15:41
hyperairtsmithe: then it's dynamic_cast.15:41
tsmithei think15:41
hyperairtsmithe: because you're downcasting.15:41
jtaylorreinterpret_cast would be what is intended15:41
tsmitheyet static_cast didn't give any error?15:41
hyperairi figured as much (because logically a line is an element, but an element is not necessarily a line ;-)15:41
jtaylorelse probably the check would not have been used15:41
hyperairtsmithe: it should have.15:42
tsmithehyperair: yes, sorry, i misread your initial question i think (to follow that logic..)15:42
tsmithestrange..15:42
hyperairtsmithe: oh wait, i guess you can downcast using static_cast15:42
hyperairit just doesn't do any checking.15:43
hyperair23:42:28 <hyperair> struct B{}; struct A : B{}; int main() { B *x = new B; const A *y = static_cast<const A*>(x); }15:43
hyperair23:42:29 <geordi> <no output>15:43
tsmitheyeah15:43
tsmitheso i'll go for dynamic_, i guess, yes?15:44
hyperair23: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
hyperair23:43:55 <geordi> <no output>15:44
hyperairthis is super unsafe.15:44
tsmithemmm15:44
hyperairbecause as you can see, you can now treat y as a C.15:44
hyperairbut it's not a C, but an A.15:44
jtaylorgiven the code context dynamic_cast is probably not wanted15:44
hyperairyeah15:44
tsmitheyes. fortunately, C and A seem pretty identical in that code15:44
hyperairsince there's a ->type == blah15:44
tsmithejtaylor: go on?15:44
hyperairi'm guessing it already knows what type it wants.15:44
hyperairbut what horrible code.15:44
hyperairtsmithe: dynamic_cast is like static_cast, but slower because it checks to make sure you're casting to the correct type.15:45
hyperairtsmithe: during runtime.15:46
hyperairtsmithe: however, since you've already checked stuff like el->type() == blah blah15:46
hyperairi'm guessing that in those conditions, it can *only* be a SLine15:46
hyperairhowever, it's very dangerous code15:46
hyperairthe potential for screwup is high.15:46
tsmithequite. i might leave it as dynamic_ for the safety. what sort of performance tradeoff is there?15:47
jtaylorif you do that you also need to put in result checks and a bailout15:47
jtaylorelse the dynamic cast is pointless as it will crash anyway15:47
hyperairtsmithe: dynamic_cast may throw if you attempt to cast like what i showed you with A and C just now.15:47
hyperairit throws std::bad_cast15:48
hyperairif you don't catch it, it'll crash.15:48
hyperairbut it'll crash early and cleanly.15:48
hyperairrather than continuing on and segfaulting in some obscure manner that doesn't give you a sensible stack trace.15:48
hyperairs/may throw/will throw/15:48
hyperairactually wait, it may throw, or it may give you NULL15:48
hyperairi think.15:49
jtaylorit returns a null pointer when dealing with poiinters15:49
jtaylorit only throws when using references15:49
tsmithesurely NULL is almost as bad as continuing on and segfaulting in some obscure manner?15:49
jtaylorbut I think it can be changed to always throw15:49
hyperairhttp://answers.yahoo.com/question/index?qid=20071106101012AAggZAk15:49
hyperairaha.15:49
hyperairit throws bad_cast when you're casting references15:49
hyperairbut when you're casting pointers, it just gives you a nullptr.15:49
hyperairjtaylor: i don't think it can be.15:50
hyperairtsmithe: well almost as bad, i guess.15:50
jtayloryou could, be dereferencing it ^^15:50
hyperairbut no, not quite as bad.15:50
tsmithein 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
hyperairfixing a nullptr deref segfault is much much easier than fixing memory corruption15:51
hyperairin which case you probably would get memory corruption due to an unchecked bad cast.15:51
tsmithechoices choices15:51
hyperairtsmithe: or you could static_cast, and put a comment with BIG FAT WARNING15:51
tsmithei'll leave it at static_cast, and forward the bug upstream15:51
tsmithewith a slap on the wrist :)15:51
hyperairbut at the end of the day it's upstream's choice.15:51
tsmithequite15:51
hyperairwhat package is this?15:51
tsmithemusescore15:51
* hyperair adds that to his mental blacklist of applications to ever use. =p15:52
tsmitheoh, it's quite a good application, in terms of functionality :p - unrivalled, you could say..15:52
tsmitheunforunately, 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*unfortunately15:53
jtaylorhyperair: what to you critisize about that code?15:53
jtaylorit seems to deal with deserialization, there this method is quite common15:53
hyperairoh it's deserialization.15:53
hyperairwhoops =\15:53
tsmithe?15:53
hyperairwell i guess deserialization is the exception to the rule where you can use this kind of ugly code15:54
jtayloron the other hand its xmlexport = serialization, and there it probably sucks :)15:54
jtaylorthe filename15:54
tsmithemmmm15:54
jtaylorthough it was xmlimport15:54
tsmithenope15:55
jtaylorthe 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
jtaylorfor deserialization on the other hand you can use dynamic_cast direclty making the code often cleaner15:57
tsmitheand that's ok, because you *know* the cast will work15:57
tsmithe?15:57
jtaylors/de//15:57
jtayloryes15:57
jtaylorswap serialization and deserialzation in those two sentences15:57
tsmithei did :)15:57
hyperairum? really?16:01
hyperairsounds 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
jtayloryes, but I seaid serializing when I meant deserializing16:02
hyperairon the other hand, i don't really see a point in casting during serializing.16:02
hyperairah16:02
hyperairright16:02
hyperairs/de// means s/deserializing/serializing/ ;-)16:03
wibblymatI'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
wibblymatOr at least: stuff to work on that doesn't get fixed by someone else while I'm still investigating :)16:26
micahghi wibblymat!16:26
wibblymathi :)16:26
PiciPerhaps the bitesize bugs list? Are those still getting tagged?16:26
micahgwibblymat: I'd suggest making sure a bug is filed if you're working on an issue and set it to in progress assigned to you16:27
wibblymatThe ones that are *really* bitesize go very fast16:27
micahgwibblymat: FTBFS needs a lot of help still16:27
tumbleweedyeah, there are still hundreds of those16:27
tumbleweedalthough a fair number might be quite tricky16:27
wibblymatI 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 off16:28
micahgssl1.0.0/libav transitions as well needs16:28
tumbleweedwibblymat: there are lots of good links in the topic16:28
tumbleweedyeah, this ssl transition tends to need patches, not just rebuilds16:29
wibblymatmicahg: Is there a wiki page for that or somethin16:29
wibblymatoops16:29
wibblymat+g?16:29
tumbleweedwibblymat: http://people.canonical.com/~ubuntu-archive/transitions/openssl.html16:30
micahgtumbleweed: well, it's the patches ones that need help most I would think :)16:30
tumbleweedmicahg: exactly16:30
wibblymatSo the deal with the transition is to update the depends to 1.0.0 and then patch it until it runs again?16:31
micahgwibblymat: build-dep should be in most cases a versioned dep on libssl-dev16:32
tumbleweedand any of them using SSLv2 funcitons will need to have that code removed16:33
wibblymatI'll see what I can work out :)16:35
wibblymatIf 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
wibblymatmicahg: 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
tumbleweedwibblymat: you don't need to tell anyone anything, it'll appear on the sponsor queue21:54
tumbleweedsee http://reports.qa.ubuntu.com/reports/sponsoring/21:54
tumbleweedof course, if you want feedback or to ask questions before a sponsor gets around to reviewing it, you are welcome to ask here21:54
wibblymattumbleweed: Ah, ok, it just goes in the queue by magic :) Thanks!21:56
=== yofel_ is now known as yofel
micahgwibblymat: 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!