[15:54] <jcastro> 8 minutes until "How to Run a Jam!"
[15:56] <dholbach> jcastro: I would have dented it, but twitter is a bit screwed
[15:56] <jcastro> dholbach: I put it on identi.ca
[15:56] <jcastro> but my gwibber is broken so I had to do it on the website
[15:57] <dholbach> yeah
[15:59] <nizarus> strange my gwibber is broken too...
[15:59] <sebner> twitter seems to be pretty br0ken :P
[15:59] <jcastro> maybe that's what's breaking gwibber
[16:00] <jacob> oddly enough gwibber is working here. it usually drops all of my messages
[16:00] <dholbach> buenos dias!
[16:00] <jureba> Hola!
[16:01] <nizarus> salamou alaykoum :)
[16:01] <jcastro> let's give it a few more minutes for the stragglers
[16:01] <jcastro> in the meantime introduce yourselves!
[16:01]  * dholbach is Daniel Holbach from the Ubuntu Berlin team - and we'll have a Jam on 3rd October! :)
[16:02] <pleia2> I'm Elizabeth Krumbach from the Pennsylvania team :) we're having a mythbuntu jam + doc jam
[16:02] <jureba> Hi, this is Jose from Madrid, Spain
[16:02]  * ianto is Christopher Swift of Ubuntu Cymru (Wales) - And our Jam is in the nation's Capital library on 3 - 4 October
[16:02] <dpm> hi everyone
[16:02] <jacob> ubuntu-us-ohio here, _still_ figuring out details on a jam in Cleveland
[16:02]  * jcastro is jorge castro from ubuntu-michigan
[16:02] <sbc> o/  I'm Søren Caspersen from the Danish team. We hope to have a bug jam, but are not entirely sure yet
[16:02]  * nizarus is Nizar Kerkeni from Tunisian LoCo we are planning to run our first jam 
[16:02]  * andol is Andreas Olssom from the Swedish LoCo. We will have a (bug) jam the 3rd of October.
[16:03] <dholbach> james_w: Jam in Bristol?
[16:03] <james_w> always
[16:03] <james_w> my life is one big sticky mess
[16:04] <jcastro> ok, before we start, if you're participating in the global jam, then your loco should be listed here:
[16:04] <jcastro> https://wiki.ubuntu.com/UbuntuGlobalJam/Events
[16:04] <jcastro> please add yourself if you haven't already
[16:05] <jcastro> ok let's get started!
[16:05] <jcastro> first of all, welcome!
[16:05]  * dholbach hugs y'all :-)
[16:05] <jcastro> This session is for local teams who want to know how to run what we call "Jams"
[16:05] <jcastro> https://wiki.ubuntu.com/Jams is the URL
[16:05] <jcastro> for those of you who want to read ahead
[16:06] <jcastro> So basically, a Jam is when a bunch of ubuntu enthusiasts get together and do something useful for ubuntu.
[16:06] <jcastro> anything from installfests, bug jams, packaging courses, you name it
[16:06] <jcastro> last year we had a "Global Bug Jam", which was a big bug triaging session all around the world
[16:06] <jcastro> that went so well that we decided to do one huge "Global Jam", so LoCos could work on all sorts of things that interest them
[16:07] <jcastro> So you can do Doc Jams, Testing Jams, Translations Jams, as well as Packaging and Bug Jams.
[16:07] <jcastro> whatever interests your LoCo
[16:07] <jcastro> so for example on the sign up page you'll see LoCos signing up for different jams
[16:08] <jcastro> or even doing their own, like NY is focusing on security, and Pennsylvania is doing mythbuntu
[16:08] <jcastro> and california still doesn't know what it wants to do. :D
[16:08] <dholbach> :-)
[16:08] <jcastro> the most important thing to remember about holding a jam is that the key to success is for the Local Team to get together
[16:08] <dholbach> if you're a bit bigger team and there's various interests you can also think about nominating people who take care of the organisation of parts of the jam
[16:09] <jcastro> the purpose is to bring people together in real life and mentor each other
[16:09] <dholbach> (somebody takes care of Translations and is the "go-to" guy for that, somebody else does bug stuff, etc.)
[16:09] <jcastro> so if you hold a jam and you feel like you didn't accomplish too much then don't worry about that
[16:09] <jcastro> because as your LoCo grows you'll get better at that kind of thing
[16:09] <jcastro> you should concentrate on having a good time and learning
[16:10] <jcastro> development of your team should be the priortiy
[16:10] <jcastro> ok, so, since lots of people have been running Jams now we have put together a list of tips and tricks
[16:10] <jcastro> https://wiki.ubuntu.com/Jams
[16:11] <jcastro> Usually the tough part is getting a venue
[16:11] <vubuntor6765> hello
[16:11] <jcastro> if you're participating in the global jam you hopefully have a venue already picked out.
[16:11] <jcastro> This can be difficult, one person wrote in to me that he couldn't find a place because they needed X amount of people, but he couldn't get X amount of people to show up without a venue!
[16:11] <dholbach> and if you have just a few people participating you might want to consider inviting people to your house... Ubuntu people usually behave themselves. :-)
[16:12] <jcastro> Right, another good place is your local library
[16:12] <jcastro> or civic center or something.
[16:12] <ianto> I second the library, it was what the Welsh team is using! :)
[16:12] <afterlastangel> tomorrow is Software Freedom Day
[16:12] <ianto> s/was/is/g
[16:12] <brobostigon> :)
[16:12] <jcastro> so they key parts to the venue would be normal things that geeks need
[16:12] <jcastro> so power and internet
[16:13] <jcastro> a projector is also useful because you can do tutorials and things on the screen while other people see what you are doing
[16:13] <jcastro> for bug jams we keep a projector handy
[16:13] <jacob> and a supply of caffeine? ;)
[16:13] <jcastro> so when a person get's stuck on a bug we put it up on the big screen and discuss it
[16:13] <jcastro> this is useful because the experienced people end up telling their knowledge to the new people.
[16:14] <jcastro> and something like bug triaging is a skill that you forget if you're not doing it all the time
[16:14] <jcastro> so it helps the experienced people stay sharp
[16:14] <jcastro> because humans are good at becoming experts at something if we teach someone else to do it
[16:14] <jcastro> and yes, jacob brings up a good point
[16:14] <jcastro> you should plan for sustinance
[16:15] <jcastro> so if you're having a 12 hour jam you should plan in for a lunch/dinner somewhere
[16:15] <brobostigon> food and drink.
[16:15] <jcastro> right
[16:15] <jcastro> for example like most LoCos, ours does not function without beer.
[16:15] <jcastro> so you need to plan for these things ahead of time
[16:15] <jcastro> If you meet at a local restaurant (which is commong), you'll want to get reservations, etc.
[16:16] <jcastro> we always have to ask for certain tables with power access, etc.
[16:16] <jcastro> ok, so that's all I have for venues
[16:16] <jcastro> anyone have any tips to share?
[16:16] <brobostigon> facilities, is you have disabled members.
[16:17] <jcastro> ah, that's a good point
[16:17] <jcastro> accessability is important for a bunch of things
[16:17] <jcastro> like, if you have your meeting in the smoking session of a pub but you have 3 underage non-smokers
[16:17] <jcastro> that would affect your attendance. :D
[16:17] <dholbach> hahaha
[16:18] <jcastro> A long time ago there was this story of this guy who got invited to speak at LinuxWorld but they wouldn't let him in because he was underage
[16:18] <jcastro> but anyway ...
[16:18] <dholbach> if you can, try to plan in enough time for everything, 2-3 hours might be just enough to get to know each other, get everybody set up and a quick introduction :)
[16:18] <brobostigon> we have a member who requires a wheelchair, so venue wheelchair access.
[16:18] <jcastro> also don't forget other supplies
[16:18] <jcastro> people will always need power strips, ubuntu CDs, etc.
[16:19] <jcastro> you'll never know when that ethernet cable might come in handy!
[16:19] <dholbach> I take with me an extra harddisk with Karmic ISOs for the Test Jam part
[16:19] <jcastro> ok, after you have a place let's talk about promotion a bit
[16:19] <dholbach> somebody is going to bring a local mirror on his laptop
[16:19] <jcastro> this is basically telling people in your area about the event
[16:19] <jcastro> this involves mailing other mailing lists
[16:19] <jcastro> perhaps contacting your local lug
[16:20] <jcastro> putting up flyers at the local PC shops
[16:20] <dholbach> the Berlin team is also mailing local Debian developers
[16:20] <jcastro> or whatever other creative thing you can think of
[16:20] <dholbach> TV Ads, Magazine Ads, everything is OK ;-)
[16:20] <jcastro> heh
[16:20] <jcastro> so hopefully by now people in your local area kno0w about the global jam
[16:20] <jcastro> but it's never too late to keep sending out stuff
[16:21] <dholbach> and try to be precise about what you're going to do there
[16:21] <dholbach> probably the first question you're going to get is: will you help us fix our Ubuntu installation?
[16:21] <dholbach> or: is this tutorials and workshops and stuff?
[16:21] <dholbach> better be clear about hands-on-making-ubuntu-better
[16:21] <dholbach> :)
[16:22] <jcastro> right
[16:22] <jcastro> although invariably someone always shows up needing help
[16:22] <jcastro> which is fine too of course
[16:22] <dholbach> sure
[16:22] <jcastro> also, the time leading up to the jam is a good time to prepare attendees
[16:23] <jcastro> if you're doing bug stuff and stuff you'll want to make sure people have launchpad accounts before hand
[16:23] <dholbach> and gobby installed :)
[16:23] <jcastro> if 30 people show up and they all need lp accounts it could eat up precious together-time
[16:23] <jcastro> so usually reminding people is a good idea
[16:24] <ianto> Some venues may need for example, a library card to enter ^
[16:24] <jcastro> dholbach: oh, we should add gobby to the Jams prereq section
[16:24] <jcastro> ianto: good point
[16:24] <dholbach> jcastro: on it
[16:24] <jcastro> so there's all sorts of ways to promote stuff
[16:24] <jcastro> anyone have any other  tips?
[16:24] <jcastro> the wiki page lists obvious things like twitter/facebook, etc.
[16:25] <jacob> perhaps video streaming parts of the event? ustream.tv/mogulus are nice
[16:25] <jacob> s/mogulus/livestream/
[16:26] <jcastro> right
[16:26] <jcastro> also, lots of pictures
[16:26] <pleia2> we have a lot of local tech groups and non-profits that don't have a linux focus, but have been interested in events, contacting them with event info is great
[16:26] <jcastro> we like to have at least one photo per loco who participates to make a big collage
[16:27] <jcastro> pleia2: yeah, events like this are good for people who go to computer groups who have heard of that ubuntu thing but would  like more information
[16:27] <dholbach> https://wiki.ubuntu.com/UbuntuGlobalJam/Stories
[16:27] <dholbach> ^ we want you on there :)
[16:28] <jcastro> the part after the jam is also important
[16:28] <jcastro> we like to see planet flooded with stories and pictures of people having a good time
[16:29] <jcastro> one thing that we just added is the Testing Part of the Jams:
[16:29] <jcastro> https://wiki.ubuntu.com/Jams/Testing
[16:29] <jcastro> if you have a LiveCD of Karmic (the beta will be out the thursday before the jam)
[16:29] <jcastro> you can boot it up, and right from there do a submission to the hardware database
[16:29] <jcastro> and run the little tests and all that
[16:30] <jcastro> this is very important because the weekend after beta we have tons of people all over the world gathering together
[16:30] <jcastro> and since it's really easy, just booting into a liveCD, perhaps it's something you can use to warm up new people with
[16:31] <dholbach> and we have a lot of test cases, so everybody can grab a few: https://wiki.ubuntu.com/Testing
[16:31] <dholbach> if you have a few spare USB keys, you can easily use usb-creator to create live-usb-sticks and ask people to test with them
[16:31] <jcastro> especially with the fresh beta, that will be real handy!
[16:31] <dholbach> yep
[16:31] <jcastro> since people will be bringing all sorts of hardware
[16:32] <jcastro> and a livecd won't break their existing computer
[16:32] <jcastro> so it's a nice low-barrier/high-win of awesome.
[16:32] <dholbach> AWESOME
[16:32] <jcastro> do we have anymore tips?
[16:32] <jcastro> I think we've covered most of the things you need
[16:32] <jcastro> anyone have questions or comments?
[16:33] <dholbach> are there any concerns you still have or things you're unsure about?
[16:34] <jcastro> any comments from the last jam for those of you who have participated in the past?
[16:35] <dholbach> or maybe what kind of jams did you do the last time and what are you trying out now?
[16:37] <jcastro> beuller?
[16:37] <dholbach> brobostigon, pleia2, ianto, dpm, sbc, jureba, nizarus: you guys are all set?
[16:37] <dholbach> or is there anything that's still unclear or problematic?
[16:37] <ianto> dholbach: Yep
[16:37] <brobostigon> dholbach: yes.
[16:38] <nizarus> o/
[16:39] <dholbach> all good... all jams planned? :)
[16:39] <dpm> all set
[16:39] <dholbach> any great tips or tricks from you?
[16:39] <sbc> dholbach: My biggest problem is getting people to show up. A jam with just me will be kind of boring. Hopefully people will respond to my mails / forum posts going out this weekend.
[16:39] <dholbach> or what are you most excited about?
[16:39] <dholbach> sbc: try the "contact team" feature of LP
[16:39] <dholbach> sbc: and mention that there's beer after the event!
[16:40] <sbc> dholbach: We have a fine working mail list, problem is if people have the time / want to. But I hope so. And beer alwas works as a lure ;)
[16:40] <vojtech_t> i have a question. is it good idea to run jam only virtually -- via audio/videoconference (ekiga), irc or something like this?
[16:40] <andol> sbc: Well, if nothing else, you'r welcome to Linköping :)
[16:40] <brobostigon> dholbach: if i can attend ubuntu-cym's, i will do beer organising, :)
[16:40] <ianto> Club Ubuntu did that last year ^
[16:41] <dholbach> vojtech_t: sure... if there's no way around it, you can do that
[16:41] <vojtech_t> our problem is, that there are about 10 interested in Jam in the Czech rep. bud they are from six cities/towns
[16:41] <dholbach> generally it's just preferrable to meet up and get to know each other
[16:41] <vojtech_t> s/10/10 people/g
[16:41] <dholbach> it's so much easier to have a chat and help each other when you can just have a look at somebody else's screen
[16:41] <dholbach> vojtech_t: are those 10 people spread over the whole country?
[16:41] <vojtech_t> unfortunately yes
[16:42] <dholbach> ah I see - that can be difficult then
[16:42] <dholbach> although... there's always a good reason to meet in Prague, isn't there? :-)
[16:42] <ianto> Oh a question, how late do we leave it until we go out for a drink without feeling guilty? :)
[16:42] <nizarus> what if we havent an experianced user ?
[16:43] <dholbach> ianto: in Berlin we plan to be around from 11 to 19
[16:44] <vojtech_t> dholbach: Prague isn't good idea... I hear them all saying "oh no, everything is in Prague..." (I'm from Prague)
[16:44] <dholbach> nizarus: that's a good question
[16:44] <dholbach> vojtech_t: I see what you mean :)
[16:45] <dholbach> nizarus: if you head to https://wiki.ubuntu.com/Jams you can take a look at the top bar there (Testing, Translations, Bug, etc.)
[16:45] <nizarus> yes dholbach
[16:45] <brobostigon> budweiser budvar, rocks.
[16:45] <dholbach> I think at least Translations and Testing should be self-explanatory and easy to prepare
[16:45] <dholbach> I agree that Packaging without having an expert might be a bit slow and complicated
[16:45] <dholbach> but I guess the rest should be easier
[16:45] <dholbach> if the documentation doesn't make sense
[16:46] <dholbach> come and talk to dpm, jcastro and me :)
[16:46] <dholbach> and mdke and davmor :)
[16:47] <nizarus> in each cases having tutors is recommended
[16:47] <jcastro> nizarus: if you don't have an experienced packager then don't do a packaging jam, I would start with a test jam and live CDs
[16:48] <YoBoY> dholbach: come where? :p
[16:48] <dholbach> YoBoY: hm?
[16:48] <dholbach> ah ok :)
[16:48] <YoBoY> for the doc
[16:48] <dholbach> just talk to us on IRC or mail us
[16:48] <dholbach> and we can improve the docs
[16:49] <YoBoY> we have shared some ideas last time, but i don't know yet what to do exactly
[16:50] <dholbach> YoBoY: what are you thinking about?
[16:51] <YoBoY> upgrading doc for karmic, erasing old docs (related to no more supported releases), making wanted pages, ...
[16:52] <dholbach> ah ok
[16:52] <dholbach> well there's a bunch of tasks at https://wiki.ubuntu.com/Jams/Docs#Tasks
[16:53] <sbc> andol: Thanks, but 5 hours each way is a bit much for transport time :) If you had jams in Malmö or Lund that might be closer.
[16:53] <YoBoY> ho this page is more complete than last time i saw it
[16:54] <dholbach> YoBoY: mdke put a lot of work into it
[16:54] <YoBoY> i see, great work
[16:55] <jcastro> ok well, that's pretty much it
[16:55] <jcastro> we got through a bunch of it quickly
[16:55] <jcastro> as always, feel free to ping myself, dpm, or dholbach if you have questions
[16:55] <dholbach> or ask in #ubuntu-locoteams
[16:56] <ianto> jcastro: off-toopic, but can I ask what happened to yesterday's meeting? there were lots of us waiting in #ubuntu-meeting and nothing happened
[16:56] <dholbach> there's a lot of experienced loco team contacts in there :)
[16:56] <dholbach> rock on everybody!
[16:57] <jcastro> ianto: we rescheduled it for next week because no one showed up in #ubuntu-locoteams
[16:57] <jcastro> ianto: those meetings are in #ubuntu-locoteams afaik
[16:57] <jcastro> hmm, now I am confused
[16:57] <jcastro> ah no, they're in here
[16:57] <ianto> jcastro: You emailed saying there was an overwhelming turnout and jono tweeted -meeting
[16:58] <ianto> about 10 mins before
[16:58] <jcastro> -meeting? I did
[16:58] <jcastro> sigh.
[16:58] <jcastro> that was a mistake on my part.
[16:59] <jcastro> ok, next week for sure
[16:59] <jcastro> in here.
[16:59] <jcastro> ianto: sorry about that. :-/
[16:59] <ianto> OK no problem ^
[17:15] <jureba> *
[19:44] <wubbbi> Hello :)
[19:57]  * funkyHat dances
[19:58]  * ikt dances
[20:03] <sistpoty> hiho
[20:03]  * sistpoty just quickly finishes a mail and will then start, ok?
[20:04] <ikt> ok :)
[20:05] <sistpoty> so who's around for the FTBFS session?
[20:05]  * Rail is
[20:05] <sistpoty> thanks pleia2
[20:05] <pleia2> sure thing :)
[20:05]  * norax_ is
[20:05]  * sebner waves 
[20:05]  * funkyHat is ^·^
[20:05]  * ikt dances
[20:06] <ikt> i mean hi
[20:06] <sistpoty> is geser around as well? :)
[20:06]  * funkyHat dances on ikt 
[20:06] <geser> sistpoty: yes
[20:06] <sistpoty> excellent, then let's get started
[20:06] <geser> I'm already looking for a good example
[20:06] <sistpoty> :)
[20:06] <sistpoty> first off, our recent archive rebuild showed a lot of packages, that fail to build from source (that's what FTBFS stands for)
[20:07] <sistpoty> you can see the results at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html
[20:07] <geser> http://launchpadlibrarian.net/32020496/buildlog_ubuntu-karmic-i386.libofa_0.9.3-3_FAILEDTOBUILD.txt.gz looks like a good candidate
[20:08] <sistpoty> yes, let's take this one
[20:08] <sistpoty> first off, a number of packages have already been fixed on the list
[20:09] <sistpoty> so please first check if the version in the archive is not already newer than the one in this list
[20:10] <sistpoty> however there are more good sources to look at in this list...
[20:10] <sistpoty> the "PTS" link goes straight to the debian package tracking system
[20:10] <dhillon-v10> hi all how are you guys doing?
[20:10] <sistpoty> maybe unstable already has a newer version
[20:11] <sistpoty> the "BTS" link goes to the debian bug tracking system
[20:11] <sistpoty> eventually there's already a bug and/or a patch there
[20:11] <sistpoty> let's check
[20:12] <c_korn> sorry, I am late. which bug are you on currently ?
[20:12] <RoAkSoAx> c_korn, http://launchpadlibrarian.net/32020496/buildlog_ubuntu-karmic-i386.libofa_0.9.3-3_FAILEDTOBUILD.txt.gz
[20:12] <sistpoty> c_korn: libofa from http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html
[20:12] <c_korn> thanks
[20:12] <dhillon-v10> quit
[20:13] <sistpoty> now in this case, we're lucky, because at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504902 there already is a patch :)
[20:13] <stlsaint> lo all
[20:13] <geser> one should also look at the bugs in LP for that package in case an other contributor fixed it already and waits on sponsoring
[20:14] <sistpoty> https://launchpad.net/ubuntu/+source/libofa/+bugs
[20:15] <sistpoty> maybe we'll pick another package, where it's up to us to do the work?
[20:17]  * sistpoty looks for a good one
[20:17] <geser> like http://launchpadlibrarian.net/31983196/buildlog_ubuntu-karmic-i386.libcommoncpp2_1.7.3-1_FAILEDTOBUILD.txt.gz?
[20:18]  * funkyHat doesn't see where libofa has been fixed ?
[20:18] <geser> funkyHat: there is a Debian bug with a patch which "just" need to be packaged and sponsored into Ubuntu
[20:19] <sistpoty> geser: that one is excellent :)
[20:19] <DasEi> or tor..
[20:19] <sistpoty> funkyHat: here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504902
[20:19] <geser> while in itself easy to do (and should be done) it's not an good example how to fix it yourself
[20:20] <funkyHat> Ok. Perhaps I will have a go at fixing that one then, should be good practice
[20:20] <sistpoty> ok, so at first we'll be looking again at BTS and PTS, and at lp bugs of libcommoncpp2
[20:21] <sebner> funkyHat: ping me and I'll sponsor it then
[20:22] <geser> sebner: to main?
[20:22] <sebner> geser: ah, didn't check where it's based :\
[20:22] <sistpoty> so no fixes in BTS, no newer version in unstable and no open bugs in launchpad
[20:22] <sistpoty> for libcommoncpp2
[20:22] <sistpoty> I guess I could offer sponsoring to main for FTBFSes ;)
[20:23] <sistpoty> however there's another thing we could check for libcommoncpp2
[20:23] <sistpoty> if you type apt-cache showsrc libcommoncpp2
[20:23] <sistpoty> you'll see a field called Vcs-Browser: http://svn.debian.org/wsvn/pkg-voip/libcommoncpp2/?op=log
[20:23] <funkyHat> (I'm not sure if there's a format I should use for the bug report, but I won't disturb the class any more)
[20:23] <sistpoty> and Vcs-Svn: svn://svn.debian.org/pkg-voip/libcommoncpp2/trunk/
[20:24] <geser> (or use the links on the PTS page for libcommoncpp2)
[20:24] <sistpoty> funkyHat: along the lines "patch to fix FTBFS", please subscribe me if you've got a patch ;)
[20:25] <sistpoty> at this link (or the VCS link from PTS) is where development of the debianization happens
[20:25] <sistpoty> at a glance, there doesn't seem to be anything related to the FTBFS
[20:25] <sistpoty> finally, let's grab the sourcepackage and get working
[20:26] <sistpoty> while the source package downloads, let's try to see where the first error is that gcc reported
[20:27] <sistpoty> to make it more clear, I've pastebinned it (as taken from the build log)
[20:27] <sistpoty> http://paste.ubuntu.com/273724/
[20:28] <sistpoty> so we'll need to look add ciddr.cpp, lines 205 and 335
[20:28] <sistpoty> (they reside in the "src" subdirectory)
[20:28] <sistpoty> everyone got that file open right now?
[20:29] <funkyHat> yep
[20:30] <sistpoty> I've pastebinned the relevant part again: http://paste.ubuntu.com/273729/
[20:31] <sistpoty> now gcc tells us about an "invalid conversion from 'const char*' to 'char*'"
[20:32] <sistpoty> a const pointer means, that you cannot change the object (memory) it points to
[20:32] <sistpoty> in c++ (and in c as well) you can only get rid of that const by casting
[20:32] <sistpoty> however casting often enough is not safe
[20:33] <sistpoty> e.g. if the memory is read-only memory (e.g. if it's a string constant like const char *s = "hello world";)
[20:33] <sistpoty> if you'd cast away the const for read only memory, the program would simply segfault when trying to write to it
[20:33] <sistpoty> the posix c string functions are a little bit nasty... you pass them a const char *
[20:34] <sistpoty> and you obtain a char * out of these, pointing to the memory that the parameter referred to
[20:34] <sistpoty> erm, I'm referring to strrchr for example (strchr and a few other follow that scheme)
[20:35] <sistpoty> this means, they implicitely get rid of the const (which might be dangerous)
[20:35] <sistpoty> in c there is sadly no alternative to it
[20:35] <sistpoty> however in c++, you can overload functions
[20:35] <sistpoty> and that's one of the gcc-4.4 changes
[20:35] <sistpoty> there exist two overloaded strrchr functions
[20:35] <sistpoty> one which gets a char * as parameter and returns a char *
[20:36] <sistpoty> and one which gets a const char * as parameter and returns a const char *
[20:36] <sistpoty> gcc then selects the correct one based on the parameter passed into it (not by the return type)
[20:37] <sistpoty> so with gcc-4.4 you can no longer accidentally get rid of the const by calling strrchr
[20:37] <sistpoty> in this example (line 205) , cp is declared const, hence the return value (ep) must also be const
[20:38] <sistpoty> however as ep is written to later, we cannot simply declare it const as well
[20:39] <sistpoty> let's try to see what the entire IPV4Cidr::set method does
[20:41] <sistpoty> the only place, where ep is written to, is straight afterwards, so let's take a closer look at this snippet
[20:41] <sistpoty> http://paste.ubuntu.com/273732/
[20:41] <sistpoty> still following me so far?
[20:41] <c_korn> yes
[20:41] <funkyHat> Just about!
[20:41] <jureba> ya
[20:42] <sistpoty> ok, good
[20:42] <sistpoty> this snippet tries to find the last occurance of a '/' in cp
[20:42] <geser> in case you missed this write access, gcc will inform you during your test build (-> FTBFS :)
[20:42] <sistpoty> and then sets it to '\0'
[20:43] <sistpoty> which means it simply truncates cp at (i.e. before) the last '/'.
[20:43] <sistpoty> now comes the fun: this means that it writes to cp, which is passed as *const* into the method. tststs
[20:44] <sistpoty> at this point, we can either choose the unelegant and simple way, or try to get it right (which might mean pain, pain, pain)
[20:44] <geser> it looks like we found a bug
[20:44] <sistpoty> the simple way would be to assume that it worked before, and obviously the const'ness of cp is a red herring
[20:45] <sistpoty> so we can cast it away
[20:45] <sistpoty> with: const_cast<char *>(whatwewanttocast)
[20:46] <sistpoty> or in this case line 205: ep = strchr(const_cast<char *>(cp), '/');
[20:46] <geser> sistpoty: from a look at this function, should line 211 (cp = cbuf) be moved before line 202?
[20:47] <sistpoty> geser: that could be
[20:47] <sistpoty> however the program could also require the side effect that cp is in fact changed
[20:48] <sistpoty> (that's always hard to judge from a glimpse)
[20:48] <geser> that's a problem :(
[20:48] <sistpoty> yes
[20:48] <geser> but anyway: this function doesn't seem to the right thing in case someone passes a string of e.g. "192.168.1/24"
[20:49] <sbeattie> geser: indeed.
[20:49] <sistpoty> yes, then it segfaults
[20:49] <sistpoty> of course if you're unsure, there's always one very good option to choose:
[20:49] <geser> sistpoty: I mean even if it's passed in a memory from e.g. strcpy
[20:49] <sistpoty> ask upstream :)
[20:51] <geser> the function takes our string, copies it (line 200), then strips it off at '/' and fills up the copy (still with the '/' with ".0" till it has 4 octects
[20:52] <geser> when now someone passes "192.168.1/24" it turns cp into "192.168.1" and makes cbuf contain "192.168.1/24.0"
[20:52] <sistpoty> yes, that looks like it
[20:52] <geser> don't know what inet_aton will make out of it
[20:53] <sistpoty> (parse it and convert it to a non-string representation)
[20:53] <geser> (and probably fail at the parsing)
[20:54] <geser> this is probably now a good time to look if upstream released a new version and look if it's fixed there else contact upstream with what we found out and let upstream handle it
[20:56] <c_korn> their homepage announces: GNU Common C++ 2.0 Beta Candidate
[20:56] <c_korn> http://www.gnu.org/software/commoncpp/
[20:59] <sistpoty> hm... has anyone found a download link for the 2.0 beta yet?
[20:59]  * sistpoty only sees 1.7.3
[20:59]  * geser too
[21:00] <sistpoty> and cvs seems to be 404
[21:00] <c_korn> seems so
[21:01] <funkyHat> ftp://www.mirrorservice.org/sites/ftp.gnu.org/gnu/commoncpp/
[21:01]  * BlackFate away
[21:02] <sistpoty> ah, so it's called ucommon nowadays?
[21:04] <sistpoty> indeed it is, and I've also found our nice method again in the ucommon source package
[21:05] <sistpoty> it's in src/socket.cpp, line 788
[21:06] <sistpoty> which a) has majored a bit, and b) seems to confirm geser's first idea how to fix it
 sistpoty: from a look at this function, should line 211 (cp = cbuf) be moved before line 202?
[21:08] <sistpoty> so the string as is should be copied to cbuf, and only cbuf should get adjusted
[21:09] <sistpoty> let's try to do this
[21:10] <sistpoty> so we change line 205 to      ep = strchr(cbuf, '/');
[21:11] <sistpoty> any objection?
[21:12] <sistpoty> anyone still around? :)
[21:12] <c_korn> here
[21:12]  * geser is
[21:12] <c_korn> just let's try if it builds :)
[21:12] <funkyHat> here, but this is over my head, I'll try to follow what I understand :)
[21:13] <sistpoty> well, for sure it won't because we didn't adjust the error in line 305 yet
[21:13] <geser> as one has seen here fixing FTBFS trains ones detective skill :)
[21:13] <sistpoty> funkyHat: just ask if anythings unclear
[21:13] <sistpoty> let's take a look at line 305
[21:13] <sistpoty> any suggestions how to fix this?
[21:14] <geser> why does it need fixing? I seem to overlook something there
[21:15] <c_korn> line 335 ?
[21:15] <sistpoty> c_korn: yes, in the same file
[21:15] <sistpoty> cidr.cpp:335: error: invalid conversion from 'const char*' to 'char*'
[21:15] <sistpoty> (from the original build log)
[21:15] <geser> line 335 makes more sense
[21:16] <sistpoty> erm, sorry :)
[21:16] <c_korn> hm, ep gets written again
[21:16] <sistpoty> looks like a copy&paste bug to me :)
[21:17] <sistpoty> so anyone with a suggestion?
[21:17] <geser> and when you compare the function name and what it does with the one we just fixed, then the fix should be pretty obvious
[21:18] <nicolasvw> copy and paste fix ? ;)
[21:18] <sistpoty> nicolasvw: righto, let's use the buffer again
[21:19] <sistpoty> and finally now it's time to do a test-build
[21:19] <sistpoty> let's add a changelog entry and build it in pbuilder
[21:20] <sistpoty> hint: if you're working on a package, which might need a number of patches
[21:20] <sistpoty> it might be easier to install the build-dependencies on your system
[21:20] <sistpoty> and do a fakeroot make -f debian/rules binary
[21:20] <sistpoty> to test-build
[21:20] <sistpoty> as this can then (ideally) reuse the already built files and will only built your new changes (and dependencies) again
[21:21] <sistpoty> -- i.e. if the upstream build system supports it
[21:21] <sistpoty> of course as last action, you should then always test-build it in a clean (=pbuilder) environment
[21:22] <sistpoty> so anyone with a buildresult yet?
[21:23] <geser> an other option is to start directly in a pbuilder (pbuilder login) but one has to don't forget to copy the changes outside the pbuilder before one exits it
[21:23] <nicolasvw> (or use the --bindmounts option to pbuilder)
[21:23] <nicolasvw> ?
[21:23] <geser> what I currently do is using a pbuilder hook to get a shell if pbuilder fails so I can investigate or test more changes
[21:24] <geser> doesn't pdebuild use it? never used pdebuild
[21:24] <sistpoty> heh, me neither... (as I once wrote my own pdebuild alike variant *g*)
[21:25] <geser> one has to find the way which works for one the best (I prefer not to pollute my host system with -dev packages)
[21:26] <sistpoty> ok, it did build for me
[21:26] <sistpoty> so here's another thing that can be totally different
[21:27] <sistpoty> let's see if the package has a patch system. if so, we should add the fix as a patch, otherwise we can simply leave it as is
[21:27]  * sistpoty usually looks if there's a directory called debian/patches, but what-patch of ubuntu-dev-tools also should give you an answer
[21:27] <sistpoty> (is that the right command *g*)
[21:28] <sistpoty> in this case, it uses dpatch
[21:28] <sistpoty> so here's my tricky way to apply it
[21:28] <sistpoty> as I already added a changelog entry, I now have got 2 .dsc files lying around
[21:28] <sistpoty> and can simple debdiff between these two
[21:29] <sistpoty> this however means that my changelog entry (which I don't want in there) is also in the debdiff
[21:29] <sistpoty> but with filterdiff, it can easily get excluded:
[21:29] <sistpoty> debdiff libcommoncpp2_1.7.3-1.dsc libcommoncpp2_1.7.3-1ubuntu1.dsc | filterdiff -x "libcommoncpp2-1.7.3/debian/*"
[21:30] <sistpoty> this one gives me the patch, which I'm putting into debian/patches
[21:30] <c_korn> hah, cheater. I never thought of that :)
[21:31] <sistpoty> now I've also need to add it to debian/patches/00list, so that it will get applied
[21:31] <sistpoty> and being a good citizen I should add a descriptive header to it
[21:31] <c_korn> but the patch is now already applied to the sources. do you revert it manually ?
[21:33] <sistpoty> either that, or I unpack the old sources (depending on how much unwanted damage I did to the sources)
[21:33] <c_korn> ok
[21:34] <sistpoty> however how you do it is pretty much your choice, you could also use dpatch-edit-patch
[21:36] <sistpoty> however after manually fiddling with patch systems, I usually do another test-build (one never knows *g*)
[21:37]  * c_korn usually sets up a git repository in the sources to get those patches :)
[21:37] <sistpoty> but what you should always do (after your final build) is to debdiff between the old and the new dsc file
[21:38] <sistpoty> that way you can make sure that only changes you really want are in the new version
[21:38] <sistpoty> should I write something about adding a debian/changelog entry, or is this clear for everyone
[21:38] <sistpoty> ?
[21:39] <c_korn> clear to me (dholbach explained it in a session)
[21:40] <sistpoty> so what's left to do...
[21:41] <sistpoty> testing your fix is always a good idea
[21:41] <sistpoty> so you should install the resulting package and test it
[21:41] <sistpoty> in this case its a library, so testing it gets a little bit hard
[21:42] <sistpoty> but you should install it, and check the file contents
[21:42] <sistpoty> eventually a lintian run on the resulting binaries might also be a good idea...
[21:42] <sistpoty> however don't try to fix these bugs, but rather look out for really critical stuff
[21:43] <sistpoty> (happened to me recently, that after a no-change-rebuild the resulting package was empty, of course that a must to get this right then)
[21:44] <sistpoty> looks all good here :)
[21:44] <sistpoty> so now it's time to upload it to the archive, or (if you don't have powers to do so) to request sponsorship
[21:45] <sistpoty> but wait, we're not yet done...
[21:45] <c_korn> what about update-maintainer ?
[21:45] <sistpoty> c_korn: of course, mea culpa
[21:46] <sistpoty> (I silently did that for my package when dpkg-buildpackage bailed out)
[21:46] <sistpoty> however ther's more to do
[21:47] <sistpoty> forwarding the bug and the fix
[21:47] <sistpoty> as the same version is also in debian, I'm forwarding it there.
[21:48] <sistpoty> geser: anything else that should get mentioned?
[21:50] <sistpoty> any questions from anyone?
[21:50] <geser> nothing missed (or I missed it too because of the routine in doing it (like calling update-maintainer))
[21:50] <sistpoty> heh
[21:50] <sistpoty> oh, I missed an important thing
[21:51] <sistpoty> as you've seen, fixing a FTBFS bug is not always trivial
[21:51] <sistpoty> so if you've come to a point, where you have no clue, it's a good idea to paste the build error (with a little bit of context) and the failing function in pastebin
[21:51] <sistpoty> and ask around (for example at #ubuntu-motu)
[21:52] <sistpoty> I'm quite sure, there'll always be someone in knowledge of the fix around, and most of the time will also give you an answer ;)
[21:53] <sistpoty> so concluding, I'd like to invite you all to #ubuntu-motu now, to get practice from the theoretical lesson right now
[21:53] <sistpoty> as a side note, until I'm too tired I'll be happy to sponsor fixes for FTBFS bugs ;)(
[21:54] <sistpoty> geser: oh, did you upload libcommoncpp2 already or did anyone else or should I do it?
[21:54] <funkyHat> sistpoty: good timing :)
[21:54]  * DasEi lacks c- / gcc knowledge for that
[21:54] <funkyHat> I just subscribed you to my libofa bug
[21:55] <geser> sistpoty: no, I didn't upload it
[21:55] <geser> DasEi: there are also other FTBFS, if you are more familiar with e.g. perl look at those
[21:56] <sistpoty> geser: ok, then I'll uload it in 5 minutes (/me needs a short break first *g*)
[21:57] <funkyHat> I didn't really manage to follow the bug-fixing on this one as I don't know any c++, but I learnt stuff anyway :)
[21:58] <sistpoty> well, I'm already writing code in c++ since 7 years or so, but I still don't understand it yet :P
[21:58] <funkyHat> :D
[21:59] <c_korn> thank you sistpoty and geser for the great lesson. I am going for some bug hunting now :)
[21:59] <sistpoty> thanks everyone for coming!
[21:59] <sistpoty> excellent c_korn:
[22:00] <funkyHat> I'm going to wait for my first patch to be looked at before I try anything else, in case I got something wrong. Don't want to keep doing the wrong thing if I did :)
[22:00] <geser> funkyHat: not everyone is that hard like that one, some are only applying a patch from Debian (like libofa) or adding a const for the same error like in the libcommoncpp2 case. you still can try and abort if it gets to hard
[22:02] <funkyHat> geser: right, and I just fixed the libofa one, but I want to check I got it right, rather than fix another one wrong as well :)
[22:04] <geser> funkyHat: not that bad, missed one thing
[22:04] <geser> forget to call update-maintainer
[22:05] <funkyHat> Ah
[22:05] <funkyHat> Now I should debuild -S again, then debdiff again?
[22:09] <c_korn> eh, gambas2 FTBFS but the same version is already in karmic ?
[22:09] <geser> funkyHat: yes
[22:09] <funkyHat> geser: I guessed and did it already :)
[22:10] <geser> c_korn: the toolchain or one of the build-dependecies changed since it got build.
[22:11] <geser> that's the reason behind the archive test rebuild: to know that it still builds (we already know that it build (or not build) in the past)
[22:11] <c_korn> ah, ok
[22:12] <geser> imagine a SRU (or security upload) you want to do later just to find out that you have to first fix a FTBFS too
[22:12] <c_korn> right
[22:13] <c_korn> there is a newer version in debian but the changelog does not mention changes regarding the FTBFS bug: http://packages.debian.org/changelogs/pool/main/g/gambas2/gambas2_2.15.2-1/changelog
[22:15] <geser> c_korn: AFAIR this specific problem only appears since g++ 4.4 with eglibc 2.10 (Debian still has g++ 4.3 as default and eglibc 2.10 is only in experimental, so there was no test build with it in Debian yet)
[22:16] <c_korn> hm, so what should I do now? file a sync request (which would require a FFe first) and patch it then ? or just patch it and it has to be merged later with debian in karmic+1 ?
[22:27] <geser> c_korn: if there is no good reason for the new upstream version, patch it
[22:27] <c_korn> ok
[22:33] <c_korn> hm, another invalid conversion in line 5. and I cannot constify it. http://pastebin.com/d3445f605
[22:42] <c_korn> I better ask in #ubuntu-motu
[22:43] <sistpoty> yep, let's move to -motu