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