[00:03] ScottK - do you know why meta-gnome2 has a comment "no need to sync" on https://merges.ubuntu.com/universe.html ? [00:04] i noticed you just sponsored an upload to fix a broken dependency. some of the existing dependencies it still has are very old and things that it really shouldn't depend on [00:45] ScottK: Thanks for the ack on python-mhash. I used python-support so that Debian would like it. :) [00:45] ScottK: It's in the queue, ready for review. Thanks! [00:46] ScottK: And yes, it will turn out to be server related, so you have are acting within your authority :) [00:47] * soren goes to bed [00:55] ScottK: good grief, this latest rebuild test is concerning. So many FTBFS [01:22] how do I know what's wrong with a quilt .rej file? === micahg1 is now known as micahg [01:31] micahg: it's a patch reject file. it just dumps out rejected hunks. [01:31] micahg: just manually merge in the changes [01:31] the changes specified in the *.rej file i mean [01:32] what do you mean by manually merge? [01:32] copy in vi? [01:33] patches basically represent changes. [01:33] and applying a patch is basically making said changes automatically. [01:33] but sometimes, a patch cannot be applied due to changes in the source hunk. [01:34] in this case, you have to look at the block that was supposed to be changed, and make the changes manually. [01:34] in the source file? [01:34] yes [01:34] ah, then I can refresh? [01:34] yes [01:34] hyperair: thank you...that's what I was missing [01:34] =) [01:36] hyperair: that did it... === qiyong is now known as qiy [03:21] Does anyone know of a python programme that uses policy kit? === zooko is now known as zookox [04:14] jbernard_: OK. Then maybe it's OK. Thanks for looking. [04:17] hey ScottK [04:18] Who, me? [04:19] lol [04:38] Does UI freeze also apply to universe? [04:39] mdeslaur: Only if there is stuff the doc team touches (there may be for mobile stuff, Ubuntu Studio, Mythbuntu, or Xubuntu). Otherwise, no. [04:41] thanks ScottK [04:57] so, if I change a string in a universe package...do I need to update the po files? [05:01] oh, I guess not [05:51] ScottK, if you have the time, would you mind looking at bug #426677 :) [05:51] Launchpad bug 426677 in pysvn "pysvn FTBFS" [High,New] https://launchpad.net/bugs/426677 [05:54] porthose: Just going to bed, but from reading your comment, you don't want to symlink it from pyshared. Move it to dist-packages. [05:54] * ScottK goes to bed. [05:56] * porthose goes to bed also [06:04] LucidFox, here? [06:09] * virtuald ponders getting out of bed [06:09] LucidFox, you're upstream of qink, right? it's about qink FTBFS with libinklevel 0.8. In case you didn't noticed it, libinklevel 0.8.0 version string is "libinklevel 0.8.0" and not "libinklevel v0.8.0", so qink does not recognise it... [06:10] (configure script, I mean) [06:18] Anyway, I've reported it in the upstream bug tracker [06:28] good morning [06:35] hey dholbach! [06:36] hey fabrice_sp! :) [06:36] how are you doing this morning? === cjwatson_ is now known as cjwatson === dholbach_ is now known as dholbach === qiyong_ is now known as qiy [11:26] please comment on my small rhythmbox plugin: http://revu.ubuntuwire.com/p/rhythmbox-radio-browser [11:27] segler: how is this different from the already available internet radio functionality in rhythmbox? [11:28] it makes the lists of dir.xiph.org and shoutcast.com searchable directly from rhythmbox, screenshot on http://programmierecke.net/programmed/rhythmbox-radio-browser.html [11:29] iradio in rhythmbox is a minimal plugin, that radio stations can be played [11:29] at all [11:30] segler: looks good. but at this point we are past feature freeze, so new packages won't go in (unless there is very strong reason for it). And hence you will find MOTUs busy with fixing existing bugs. [11:30] thanks, but maybe for the next version then [11:32] segler: Of if you work on getting it into Debian now, more users will benifit and it will automatically come into Ubuntu for the next release. [11:33] segler: As I said, it is hard to find people not already busy with other things at this stage of development cycle. New packages get best reviewed at the early stage of development cycle. [11:33] is there also good documentation on archiving this for debian [11:35] ? [11:35] mentors.debian.net i think [11:35] but i'd talk to pkg-multimedia [11:35] or maybe pkg-gnome [11:35] thanks [11:35] I guess pkg-gnome is right group. [11:36] rhythmbox is official gnome module. [11:36] there's some overlap anyway [11:36] isn't that right, slomo === elky` is now known as elky === cprov-afk is now known as cprov [14:07] * RainCT thanks bdrung for fixing audacity! :) [14:07] RainCT: np === thekorn_ is now known as thekorn [14:37] *tries to remember the bzr shorthand for pushing to the pull URL* [14:39] unfair; totally undocumented AFAICT! [14:39] jdong: bzr push :parent [14:39] ScottK: ah! thanks [14:39] morning [14:40] I suspect you're right. I found out about it asking on #bzr. [14:40] dholbach, Heya. I'll have the interview ready by the end of this weekend [14:40] RoAkSoAx: ŝuper! [14:40] ScottK: yeah I overheard something like that before, so I knew it existed just not where. [14:41] what does MIR stand for? [14:41] Main Inclusion Report (Request?) [14:41] Report [14:42] ah, cool. [14:42] !mir [14:42] mir is Main Inclusion Report - see https://wiki.ubuntu.com/MainInclusionProcess for more information. [14:47] asac, lool: once you guys get gnome-web-photo using the glue correctly, please let me know, I've been wanting to package it for Debian but that was what was holding me back. and of course I'm curious what I was doing wrong when I tried doing it myself :) [14:48] Ryan52: Eh ok [14:48] Ryan52: libxul.m4 is bogus [14:48] i am not sure where all those m4 files come from [14:49] the glue code is at least in place [14:49] its just a matter of build system from what i can see [14:49] is gnome-web-photo in gnome git? [14:50] found it [14:53] FYI, http://qa.ubuntuwire.com/bugs/rcbugs/ is updated and working. Plenty of opportunity there for fixing stuff. [14:53] woop woop [14:53] Heya gang [14:56] Heya bddebian. [14:57] bddebian: I thought you all removed all the gtk1.2 stuff already? [14:58] Heya ScottK [14:58] I've noticed a couple like dillo that are still there. [14:58] ScottK: I've tried, see: http://wiki.debian.org/Gtk1.2ImlibGnome1Removals [14:59] any rsync experts here? [15:07] hi, ubuntu does not provide a xserver-xorg-video-ast (ASPEED). how can be created? [15:12] kimus, poke the ubuntu x11 guys [15:12] directhex: ok... I'll try to do that thanx [15:32] hi folks [15:32] any release manager here? [15:32] sistpoty|work: ping [15:32] quadrispro: what's up? [15:35] Ryan52: http://people.canonical.com/~asac/tmp/0001-use-libxul-embedding-unstable.pc-.-plain-and-simple..patch [15:35] Ryan52: thats the right approach [15:35] now it fails to build because gnome-web-photo uses internal symbols directly [15:35] namely: in Writer.cpp ... it uses gfxSurface etc. [15:35] that should be done by using canvas.writeDocument [15:36] rather than directly stabbing in the inner guts of gecko ;) [15:36] i will do a second patch for that most likely removing almost everyhting that is in Writer.cpp [15:36] anyway. off for the weekend [15:51] ScottK: im working on updating ksplice, is there something i should do to mark that as in-progress? [15:52] jbernard_: Is this an updated merge? [15:53] ScottK: you're asking if there's a newer debian version? [15:53] jbernard_: Yes. Are you updating from Debian? [15:53] ScottK: yes [15:53] jbernard_: You can leave a comment on merges.ubuntu.com that you are working on it. [15:53] ScottK: awesome, im on it [15:55] ScottK: im not able to find it in the list, am i missing something? [15:57] jbernard_: I agree it's not there. Not sure why. [15:57] Maybe Adri2000 knows. [15:57] ScottK: the new debian version (0.9.9-1) hit sid about two weeks ago [15:58] ScottK: ill prepare a debdiff in any case [15:58] why should it appear on MoM when the ubuntu version doesn't has an Ubuntu delta? [15:58] Oh. Right [15:59] geser: Thanks. [15:59] jbernard_: hopefully there is no debdiff, just a sync request. [15:59] * ScottK wonders off in search of more coffee [15:59] ahh, ok, no i follow [15:59] /s/no/now [15:59] * jbernard_ reaches for more coffee as well [16:08] hey guys is there any wikipage that shows the process to apply debdiff and upload the packages (for MOTUs)? [16:09] hey RoAkSoAx [16:09] congratulations [16:09] james_w, thanks :) [16:09] apt-get source package [16:09] cd package-* [16:10] wget -O- | patch -p1 [16:10] I think that's right [16:10] new upstream versions are different [16:10] or [16:10] bzr branch lp:ubuntu/package [16:11] bzr patch --strip 1 [16:11] hi [16:11] merges require different arguments to debuild as well [16:11] i uploaded an updated version of a package to revu but it is not showing up [16:11] james_w, awesome, thanks. But isn't there a wikipage that explains everything? [16:12] RoAkSoAx: I've not seen one. Write one! [16:13] james_w, yeah!! will do that. I'll just gather the information needed and will setup a wikipage :) [16:13] nice [16:20] if i update a package to fix some problems that revu reports should I bump the version number i.e. ubuntu1 to ubuntu2, and then upload again. Or leave it as it is? [16:21] for REVU you can keep (and should) it at -0ubuntu1 [16:22] thanks [16:30] ode: did you use -f option for dput? [16:31] RoAkSoAx: There is one. I don't remember where it is. (wiki page) [16:31] ScottK, I've been trying to search for it with no luck :S :( [16:32] RoAkSoAx: OK. As james_w said, it's just like applying a patch. Then debuild -S -k(yourkeyid/email...). The dput like you would to a PPA, but to ubuntu. [16:33] slytherin: yeah I did but I think I made an error with the version number [16:33] i'll fix and try again [16:34] ScottK, that's the same process for any kind of debdiff (which can be a merge debdiff or a bugfix debdiff)? [16:34] RoAkSoAx: Yes, unless there is a new upstream release involved. [16:34] ScottK, and how are new upstream releases dealt? [16:34] Then if you have the tarball, you need to add -sa to debuild. [16:35] I see, I always build my packages both ways so it's ok [16:35] You should fetch the tarball from upstream yourself and then take the sponsoree's diff.gz and apply it (decompress and apply as a patch) [16:36] One of the key security principles is that we 'trust' upstream code, so you need to take the upstream code from upstream and not assume a non-developer has given it to you untampered. [16:36] RoAkSoAx: ^^ [16:38] ScottK, awesome! Thanks :)! [16:39] RoAkSoAx: I also recall having approximately the same questions when I made MOTU two years ago. [16:40] ScottK, haha. Yeah, these are exciting moments :) [16:53] RoAkSoAx: You might find https://wiki.ubuntu.com/MOTU/New useful. [16:53] thanks iulian :) [16:54] iulian: That's the page I was thinking of. Thanks. [16:57] No problem. [16:58] So, new MOTUs, eh? Congratulations to them. [16:58] Someone who cares about latex might want to look into syncing vim-latexsuite. [17:01] Hm, it seems that http://vim-latex.sourceforge.net/ is not responding. [17:02] Ah. It worked. [17:06] iulian: What's in Debian represents a considerable update. [17:24] Hi. If a lib appears in the NBS page, and it's normal (changed from lib1 to lib2), should we fill a remove request for the binary package (lib1 in my example)? [17:24] fabrice_sp: No. Once it has no rdends left it'll get cleared up [17:25] ok [17:25] thanks [17:30] ScottK: Yea. I couldn't find a ChangeLog or a NEWS file. It will need a FFe. [17:31] ScottK: There is a debian/RELEASE-1.5.txt file. I found out that 1.5 was released in 2003. [17:33] I'm definitely looking in the wrong direction. [17:33] iulian: Yes. I think it's enough of an update we ought to take it if someone can verify it works. [17:33] ScottK: That's what I was planning. [17:36] RoAkSoAx: If you want something to work on, http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.4;users=debian-gcc@lists.debian.org probably has some patches we could do with. [17:37] If you find packages that FTBFS on http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html that have patches there, it's a good chance we need the patch [17:38] ScottK: Is it just a coincidence that all packages on that list start with the letters a - f ? [17:39] diwic: The rebuild gets done in alphabetical order. That's as far as it is. [17:39] ScottK, awesome! I'll work on it. Thanks :) [17:39] Also that page only updates every two hours. [17:39] RoAkSoAx: Feel free to invite new contributors to help you and sponsor them. [17:40] scottk: somebody needs a faster build machine ;-) [17:40] diwic: It's done on the PPA builders whenever one is not otherwise in use. [17:40] ScottK, will do :) [17:43] RoAkSoAx: don't forget to check if there isn't a fixed package in the archive already. I'm going through this list and trying to fix all those "invalid conversions" errors. [17:47] geser, ok :) [17:50] geser: At the release team meeting today slangasek and sistpoty discussed trying to get a training session together to teach MOTU/hopefuls how to work on solving these FTBFS. [17:53] ScottK: the "invalid conversion" ones are pretty easy to fix (mostly add a "const", but some C/C++ knowledge is still useful), so they would be a good candidates for new contributors [17:54] geser: eh, *don't* add const for the invalid conversion ones [17:54] that's a bug in the toolchain, not in the packages that are FTBFS [17:54] and when the toolchain is fixed, they'll FTBFS again if changed [17:55] slangasek: oh [17:56] perhaps I should fix that in eglibc and ask for another rebuild test [17:56] slangasek: the declaration for strchr() on a const char* seemed pretty logic to return a const char * [17:56] geser: but that's not how the function is defined [17:57] (cf. the manpage) [17:58] in that case it would be perhaps good to stop the rebuild till it's fixed as there are many of these in the FTBFS list for the rebuild [17:59] so it's hard to find the real ones [18:05] hi everybody === micahg1 is now known as micahg [19:20] I have packaged a new upstream version, do I have to upload to LP anything besides .diff.gz? (I assume that .tar.gz should be taken from upstream anyway, and .dsc generated from it) [19:22] hi folks [19:22] randomaction: only the .diff.gz is necessary [19:23] great, thanks === jrib1 is now known as jrib [19:25] if the package doesn't have a watch file which makes it easy to fetch the new .orig.tar.gz, perhaps a link to the new upstream tarball would be helpful to save your sponsor the time to go hunting for it [19:30] Yep, I have added both. [19:46] is anyone interested in an instant fix ftbfs session? [19:46] (as we've got lot's of ftbfs, see http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html) [19:48] sistpoty: there was a discussion two hours ago whether to fix them or not [19:48] sistpoty: seems like an error in the toolchain was causing at least some of them [19:48] diwic: It was decided that was not the case. [19:49] ok [19:49] diwic: they should be fixed again (see the log for #ubuntu-devel) [20:11] so anyone interested in a fix ftbfs session here? I'd help with c/c++ issues [20:12] sistpoty: I'd attend for sure :) [20:12] :) [20:13] sistpoty: what do you mean with "instant", right now? [20:13] sebner: yes [20:13] sistpoty: I have to fix something first :P [20:13] hehe [20:14] * porthose has notpad and pen ready [20:14] porthose: good you didn't write "notepad" :P [20:14] excellent! [20:14] god I can't type today :) [20:15] slangasek: got some time to jump in as well, if tough questions arise? [20:15] * slangasek waves wildly [20:15] wohoo, cool, so let's get started. [20:16] so first off, the list we'll deal with is http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html, which is the current rebuild test (still going on, so the list will increase as buildds come to it) [20:16] let's grab a nice one [20:17] how about adanaxisgpl [20:17] the (F) link goes straight to the build log, so let's take a look at it [20:17] and also let's grab the source while looking at the build log [20:18] (crack, why did I pick a large package :/) [20:18] while the source downloads, it's a good idea to also look at debian's BTS, maybe there's a bug there open already, or a new version which we can pick up [20:19] with the "PTS" link, you can see the package tracking system, and see if there's a newer version in unstable [20:19] the "BTS" link is straight to debian's bug tracking system [20:20] I would help out in the session as I'm currently fixing FTBFS anyway :) [20:20] geser: excellent, so feel free to chime in :) [20:21] so we can see, that a) there's no new version in unstable, b) there is no build failure bug open in unstable... which means that we need to tackle it ourselves [20:22] there is one in mentors.debian.net though [20:22] diwic: oh, nice, excellent! [20:22] wait [20:22] that one's an older version? [20:23] diwic: got a link? (can't see it on mentors right now) [20:24] sistpoty: http://packages.qa.debian.org/a/adanaxisgpl.html lists it, but when I click on the link I just get an error. That version was older anyway [20:24] diwic: it's not on mentors --> http://mentors.debian.net/debian/pool/main/a/ [20:25] diwic: yep, that's an older version, which got purged from mentors after the upload [20:25] sistpoty: you should have picked avifile, it's a nice case that upstream got lucky that it worked till now [20:25] sistpoty: You should just make bddebian fix this one himself. [20:26] ScottK: haha [20:26] geser: I'll leave avifile for you to explain how to fix it ;) [20:27] ok, so on PTS however there's also a link to svn, let's see if there's something that helps fixing it: http://svn.debian.org/wsvn/pkg-games/packages/trunk/adanaxisgpl/?op=log [20:28] which somehow doesn't look like it's working... maybe it was moved to git, *shrug* [20:28] so at this point, it's get interesting, we'll have to fix it ourselves (so I guess I picked a good package *g+) [20:28] let's look at the first error in the build log [20:29] to make it clearer, I've pastebin'd it: http://paste.ubuntu.com/269361/ [20:30] and forgot the interesting line, d'oh [20:30] sistpoty: websvn is working for me but nothing helpful there [20:30] sebner: ah, k, then I clicked on something wrong *g* [20:30] heh [20:30] so here's the interesting bit included: http://paste.ubuntu.com/269362/ [20:31] it says invalid conversion from const char * to char * [20:32] w.o. looking at the code, this looks like a constant string was passed to a function requesting a char * [20:32] We have approximately a bazillion packages that FTBFS on they type of error. [20:32] they/this [20:32] so let's look at the C side... [20:32] in C, if you write "hello world", that will be of the type "const char *" [20:33] the content of the pointer is stored somewhere in the data section [20:33] sistpoty: in most FTBFS listed on the page this error is caused by assigning a const char* to a const * (e.g. from strchr()) [20:33] the return value from strchr() [20:34] ah, I see [20:34] so the content in the data section should really change (i.e. "hello world" shouldn't get overwritten w. something else) [20:35] earlier on, gcc was lenient and didn't care too much [20:35] so to denote that the content doesn't change, there's the const keyword [20:35] so here comes the tricky part: [20:35] if a library function returns a pointer which points inside the string, the return value must also be declared const [20:36] (because you still mustn't be able to change the contents with the returned pointer) [20:36] let's take a look at the code at ./Platform/X11/PlatformMiscUtils.cpp:1245, and see if this is the case here [20:37] which is the case now with g++ 4.4 and the reason why this appears now (see man strchr() for the C syntax) [20:38] strchr() has in C++ two declarations (one for char* and one for const char*) and g++-4.4 checks it now [20:38] so this line is: end = strrchr (path, '/'); [20:38] the same applies for similar functions [20:38] and end is declared as char * [20:40] in this function, end is not modified, so we can simply change it to be a const char * [20:40] let's try a rebuild [20:40] ironically, the next line is: if (end == (const char *) NULL) [20:40] heh, yes [20:42] so while my box is rebuilding, a small side note: [20:42] if you have to fix more compile errors, or need several tries, it makes sense to simply install the build dependencies and rebuild with make -f debian/rules binary [20:43] that way, usually only the changed files will get rebuilt (given the upstream build system is getting it right) [20:43] porthose: pysvn uploaded. Thank you for your contribution to Ubuntu. [20:43] woot thx ScottK :) [20:43] sistpoty: If seen many missing include stuff, what's the magic there? [20:44] sebner: Google has lots of good answers on that one. [20:44] * ScottK needs to run. [20:44] Laney: did you get your system booting again? :) [20:45] ScottK: isn't that a Q&A session :P [20:45] "magic"? [20:45] there's no magic, just include cstdio where it should be included? :) [20:45] sebner: earlier on, many c++ headers included other headers [20:45] Yep [20:45] slangasek: in other words: why does upstream don't do it [20:45] sebner: so that was in fact included by a different header [20:45] sistpoty: mine rebuild is done (successful) [20:45] sebner: so it did built back then [20:45] geser: wohoo [20:45] sebner: because g++ was less strict before and the headers were included by accident, so upstream didn't notice [20:46] grrrr -.- [20:46] sistpoty: do you also have such an example, /me forgot the FTBFS message for this ones [20:46] sistpoty: have you an idea how to fix the FTBFS for avifile? http://launchpadlibrarian.net/31591921/buildlog_ubuntu-karmic-i386.avifile_1%3A0.7.47.20070718-1.2ubuntu1_FAILEDTOBUILD.txt.gz [20:46] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/avifile/karmic/annotate/head%3A/lib/aviplay/aviplay.cpp [20:46] ^^ that's the source file [20:47] sebner: I'd have to look for this... iirc there also was a mail from Martin Michlmayr explaining a few c++ errors wrt the new gcc, but I don't recall right now where that mail is (anyone got a pointer)? [20:47] geser: lol, isn't that the other way round? [20:48] sistpoty: kk, np [20:48] sistpoty: I decided to try another package just to follow, but apt-get build-depends failed, one of the packages got a 404 not found error. :-( [20:48] diwic: run apt-get update [20:50] geser: hm... should be the same thing actually, though I can't say for sure how strrchr is defined in c++ (or why it would be needed in the first place) [20:50] p is not used after if(p). so *p=0 can be removed I think [20:50] sistpoty, geser: yay, the coredump works with gnome-voice-control. Now I need to know wth I can do with this file, though :P [20:51] c_korn: no, the "." is removed in the string, should there be any (in a quite hacky way) [20:51] c_korn: no, the idea it that the filename (fn) should be terminated at the place with "." (if there is any) [20:52] geser: according to http://www.cppreference.com/wiki/string/start, c_str() returns something non-modifiable [20:52] the problem here is that fn.c_str() returns a const char *, strrchr(const char*, int) returns also a const char * [20:52] so *p should be a const char * [20:52] in which case *p = 0 is illegal [20:53] yes [20:54] this code needs to be modified to work on "string" (C++) [20:54] I'm curious why this didn't cause any problems (any crashes) [20:55] why would it? [20:55] geser: how about size_t p = fn.rdin('.', 0) [20:55] if (p != std::string::n_pos) { fn.erase(p, 1); } [20:56] rfind even [20:56] slangasek: I assume it didn't crash because c_str() used modifiable space (even when it returned it as const char *), correct? [20:57] bleh, of course not 1, but fn.erase(p, fn.size() - index - 1) [20:57] (might still be off by one, /me recalculates) [20:57] geser: yes, that's almost always the case [20:58] fn.erase(p, fn.size() - index)... that should be it [20:58] all pointers to read-only memory must be const by definition, but most const pointers don't point at read-only mem [20:59] slangasek: and iirc even string constants don't reside in read only pages, correct? [21:01] geser: anyways, since you were first to have the rebuild finished, maybe you'd like to explain the final steps (like getting the adanaxisgpl patch as a patch, forwarding it to debian and upload it?) [21:02] sure [21:02] thanks, then I'll go out for a smoke, be back in 5 mins :) [21:02] so we know now how to fix it [21:03] the first step would be to check if the package uses a patch system [21:03] what-patch (from ubuntu-dev-tools) helps with this [21:03] sistpoty: string constants will usually be in read-only pages [21:04] what-patch returns for this package that it uses quilt [21:04] (an other way would be to look for debian/patches) [21:05] so lets get the change into a quilt patch [21:06] as I regularly forget the magic for quilt, I use https://wiki.ubuntu.com/PackagingGuide/Howtos/Quilt as a reminder [21:07] Hey, if i [21:07] Hey, if i'm cherry picking a patch from Debian.. should the changelog state "Cherry picked from Debian"? [21:08] Daviey: yes, it makes it easier during the next merge to know that the patch is already in Debian [21:08] geser: they way it's heading it's going to be constantly diverged from Debian :( [21:09] can you explain? [21:10] slangasek: ah, thanks [21:10] back to our quilt patching: "export QUILT_PATCHES=debian/patches" to let quilt know where the existing patches are [21:10] geser: Debian don't want to adropt dkms at the moment for this package. [21:12] Daviey: but it's still good to know that the patch came from Debian and that we don't need to forward it (independent of any Ubuntu delta we need to keep for a longer time) [21:12] sure, thanks. [21:13] the next step is then to apply all existing patches (quilt push -a), create a new one (quilt new 40_fix-invalid-conversion.diff (or similar)) [21:14] add the file we need to modify to it (quilt add src/Platform/X11/PlatformMiscUtils.cpp) [21:14] edit the file with an editor of your choice [21:15] geser: without looking at the patch list, why did you pick 40? [21:15] jdstrand: thanks for the gmameui upload [21:15] geser: are you actually rewriting the code a second time now? [21:16] sorry, missed a step: look at the existing patches to see how they are numbered and named [21:16] jdstrand: however I can't find a config.log file in the source package [21:16] loic-m: did you check the diff.gz? [21:16] diwic: perhaps I should mention that I check which patch system is used before I start changing anything [21:18] * sistpoty usually modifies directly but adds a new changelog entry and then debdiffs to get a patch [21:18] after the look at debian/patches I picked 40 as that looked like the next step in numbering (we don't need to push our patch somewhere in between the existing patches) [21:18] Ijdstrand: yes, I always check for files not in debian/ . Is it possible the diff.gz sent to you wasn't exactly the one I uploaded to REVU [21:19] sistpoty: thought about scripting that process? === Tonio__ is now known as Tonio_ [21:20] Daviey: not really... the main point is looking at the debdiff (to catch other maybe build system related changes, that shouldn't be there), and I wouldn't know how to automate this [21:20] sistpoty: If you modify directly, won't you get lintian warnings for having modifications outside debian subdir? [21:21] when we are done with any changes, "quilt refresh" to update the quilt patch, and "quilt pop -a" to de-apply all patches [21:21] in the case of quilt we don't need to add our patch to debian/series (quilt did it already for us) (for dpatch one has to add it manually to patches/00list) [21:22] diwic: well, if there's a patch system, yes... but I change directly and pick the patch then from the debdiff and integrate it into the patch system if everything works for the final upload (of course after rebuilding it again and running lintian *then*) [21:22] (in karmic quilt now has an option "shell" which makes it behave like cdbs-patch) [21:22] the next step would be to add a changelog entry (dch -i) [21:23] if our change is the first Ubuntu change to this package don't forget to run "update-maintainer" [21:24] if I didn't forget anything we should be able to build the new source package now (debuild -S) [21:24] geser: what would you do if patches are like this: 2_foo, 4_bar, foobar, barfoo, 30_foobarfoo, 40_barfoobar? [21:24] running "debdiff" inside the package dir will gives us the debdiff for our changes [21:25] sebner: curse about the maintainer [21:25] geser: heh [21:25] geser: that too [21:25]