[00:01] directhex: lucky you, I had to compile a kernel only 2 days ago [00:01] though it was just grabbing the ubuntu kernel, modifying 1 file to add a USB device ID, and push it through pbuilder [00:19] hi! [00:19] is it possible to write a debian/watch file for google code? doesn't provide directory listing [00:19] freinhard: It is. [00:19] See: pidgin-facebookchat [00:26] jpds: great, works! [00:31] would be nice if someone could comment (and maybe advocate) http://revu.ubuntuwire.com/p/ctemplate [00:35] freinhard: From a quick glance, you have some unanswered lintian reports (you don't need Section: in the source stanza) you're forcing debhelper 7, but using CDBS: what feature from debhelper 7 do you require? You don't need .dirs files for directories identified to dh_install, you haven't included a symbols file to check for ABI shifts. [00:35] There's likely more, but that's a batch to dig at for now :) [00:36] persia: just reuploaded witout the unneeded second section line [00:37] OK. How about the rest? [00:37] just removed debhelper and i'll check the .dir files [00:38] removed debhelper? Check the debhelper changelog: you may want something newer than the 5.0.30 that cdbs pulls. Also, be sure to adjust debian/compat if you're supporting older debhelper. [00:39] Also, there's a lintian bug that some people work around by adding an unversioned debhelper build-dependency. If you end up with the complaint that there's no build-depends on debhelper, and you do have build-depends on CDBS, you can ignore it because CDBS depends on debhelper. [00:40] in fact i've no idea which debhelper and compat i need. build on karmic, that's all i know. upstream requires 4.0.0 but no idea if this is still valid [00:40] s/build/builds/ [00:40] upstream shouldn't require any version of debhelper: it's only used in packaging. [00:41] Check the debhelper changelog (in reverse order). The first time you see a feature you think you're using, set that as a minimum version of debhelper. === SuBmUnDo_ is now known as SUBMuNdO__ [00:41] If you get back to the version that CDBS requires (5.0.30 for karmic), stop, and don't bother with a versioned depends. [00:41] i know, they provided some two years old debian/ folder which, except for the controls and .install files, i dumped [00:42] Similarly, it's likely worth checking the CDBS changelog to see if you need a specific version. === SUBMuNdO__ is now known as SuBmUNDo`OuTzZ === SuBmUNDo`OuTzZ is now known as SUBMuNdO__ [00:42] the only thing i can do is to require karmics current cdbs version. i know that it builds on karmic and i can't test anything else. [00:43] Well, don't bother with a versioned build-dep on cdbs then. [00:43] If someone tries to backport it, they may file a bug. [00:44] that's what i wanted to hear :D [00:45] any package where i can have a look how the debian/symbols file works? [00:47] https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols is an excellent write-up (which stefanlsd really ought push into the PackagingGuide at some point) [00:47] Dunno about sample packages. [00:53] if i don't depend on debhelper anymore, can i drop the debian/compat file? [00:56] No. [00:56] You need to tell debhelper which version of the files you're using. [00:57] ok so i just ignore the lintian warning about debhelper and keep the compat file [00:57] But if you're using CDBS, you can drop it to compatibility level 5, unless you're depending on some special feature of debhelper that requires a newer compatibility level (and you oughtn't be if you checked the changelog and aren't adding a versioned dependency) [00:57] Yes, that's the lintian bug I mentioned earlier, that it fails to detect when debhelper will be installed by CDBS. [00:58] As I said before, some people work around this with an unversioned debhelper build-dependency, but I usually just leave it there, because I know lintian is wrong in this case. [00:59] Fixing it is tricky because the real fix would involve lintian building a recursive build-depends tree based on a current apt-cache for the target listed in debian/copyright and checking that, which would be slow (and quite possibly completely wrong in cases where special targets (e.g. UNRELEASED) are being used). [01:00] so this will probably never happen. [01:00] If you're super picky, you can set up a lintian override file that explains why lintian is brain-dead in this case and overrides the warning, but since it's not critical, it doesn't really require an explanantion in an override file. [01:00] no,i'm not picky at all. if it works, i'm fine with it ;) [01:01] Well, it's a tricky problem. Needs someone who cares enough about CDBS and lintian and hiding the warning to spend a lot of time on it. [01:01] Most such people would rather fix other stuff in lintian or make CDBS more flexible instead. [01:02] lintian complains about leading spaces in the description when i run it on one of the resulting .deb files [01:04] is the description indented with one or two spaces? [01:05] i guess one... [01:06] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description describes the syntax for Description fields. [01:06] Sometimes you want one space, sometimes two. It depends on what you're doing. === SUBMuNdO__ is now known as SuBmUNDo`OuTzZ === ScottK changed the topic of #ubuntu-motu to: Ubuntu 9.10 released! | Lucid Alpha 2 Released! | Want to get involved with the MOTU? https://wiki.ubuntu.com/MOTU/Contributing | Sponsor queue: http://is.gd/2y76G | http://qa.ubuntuwire.com/ftbfs | http://people.canonical.com/~ubuntu-archive/NBS/ | http://qa.ubuntuwire.com/debcheck | latest rebuild failures: http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi | Outstanding merges: http://people.ubuntuwire.com/~lucas/merges.html [01:31] I'm tying to make a debdiff for bug 461104. I get the messageNOTICE: 'ubiquity' packaging is maintained in the 'Bzr' version control system at:http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk Please use:bzr get http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk to retrieve the latest (possibly unreleased) updates to the package. What one should I use? [01:31] Launchpad bug 461104 in ubiquity "Timezone combo doesn't always change (doesn't retranslate) if I change language" [Undecided,Confirmed] https://launchpad.net/bugs/461104 [01:32] SoftwareExplorer: For that package you're better off to work from bzr and ask to have your branch reviewed. [01:32] SoftwareExplorer: ubiquity development is a bit special, because the ubiquity branch doesn't quite match the ubiquity package (because the ubiquity package includes chunks of d-i). [01:33] SoftwareExplorer: https://wiki.ubuntu.com/Ubiquity/Contributing might be a good place to start to untangle things [01:34] SoftwareExplorer: https://wiki.ubuntu.com/Installer/Development has more pointers. [01:35] The main reason I was going to try to do this bug is that it seems to already have a patch for the python. Is this not a good bug to try to fix for my first time? [01:36] Probably not. That's an odd source package and runs in a tricky-to-test environment. [01:37] Speaking of my experience, I ran into lots of difficulties when I first tried to change ubiquity, even after several years of experience with packaging and bugfixing in Ubuntu. [01:37] Ok. Well, at least I was able to confirm the bug. [01:37] Alternately, if you have a real interest in how the installer works, more help in that area would likely be appreciated :) [01:38] I'm just trying to start learning to package. I don't really have a specific interest yet, mostly I just want to help. [01:40] SoftwareExplorer: Were glad to have you. [01:41] kamalmostafa: If you're around, now's not bad. [01:41] ScottK: By the way, did you ever get an answer to your question about plymouth and art? [01:42] (or am I misremembering the channel in which you asked?) [01:42] persia: I did not, but davmor2 said he'd file the bug. [01:42] persia: I think it was -devel, but thanks for remembering. [01:42] In another context, I was told that the filename was hardcoded in the ./configure call in the plymouth source package. [01:42] ScottK: just a moment [01:42] OK. [01:42] persia: That's "special" [01:43] I wondered if it might make sense to have that be some well-known-location and use alternatives for the different flavours, but I'm not likely to dig into that. [01:43] Indeed :) It broke several flavours. [01:43] It also FTBFS on ports. Dies in configure [01:43] no artwork? :) [01:43] The error message isn't helpful [01:44] I didn't get a chance to investigate [01:45] It's the --with-logo=/lib/plymouth... that handles the artwork there. [01:46] ScottK: Seems the issue is: configure:11953: error: Package requirements (libdrm libdrm_intel libdrm_radeon libdrm_nouveau) were not met: [01:46] I'm guessing that string needs adjustment for any ports DRM that support it (but I'm not at all familiar with how DRM works for ports) [01:46] Ah. No, they wouldn't be, would they. [01:47] * ScottK neither. [01:47] Maybe tseliot knows. [01:47] Maybe we should have been having this discussion in -devel :) [01:47] (but tseliot isn't there either) [01:48] kamalmostafa: What have you got? [01:50] ScottK: ok, first off, I'm not at all sure that I actually did what you asked for, but here goes... [01:50] kamalmostafa: That's fine. Learning is a big part of the point of this. [01:50] Lets start with libtifiles: https://code.launchpad.net/~kamalmostafa/ubuntu/lucid/libtifiles/libti-backmerge [01:50] ok [01:51] - Merged libtifiles2 --> libtifiles [01:51] - I did not re-autoconf (ran into problems) so kept ubuntu versions' conf (autoconf-1.10.1) [01:51] - Significant changes to debian/copyright files. Is it okay? [01:51] - I may have missed some instances of "2-removal" (po stuff? doc stuff?) [01:52] First question: Is the debian/changelog version number correct? [01:53] I bumped up the "libtifiles2" version number by one "ubuntuN" unit to construct 1.1.2-0ubuntu2 but it looks weird as the next revision above libtifiles (1.1.1-1). .. [01:56] Bumping the version number was right. [01:56] As first glance it looks pretty good. [01:57] I don't think there's a way to do the changelog that wouldn't end up looking a bit odd. [01:57] Yeah, I fought it out with the version numbering for quite awhile -- this was the only way to convince Lucid to use *this* libtifiles instead of the one that appears newer from libtifiles2. [01:57] kamalmostafa: It does look like there are some things you can do to minimize the diff from debian. [01:58] kamalmostafa: Exactly. [01:58] As an example, you have ordered the build-depends differently. [01:58] That's a pointless diff and you should change to follow Debian. [01:58] OTOH, the more precise debhelper version requirement in the Ubuntu package is good to retain [01:59] You should make standards version and home page the same as Debian [01:59] But here's the thing... All those settings are what I lifted from "libtifiles2". [02:00] I mean to say -- that's the debian/control from "libtifiles2", except modified for the new name "libtifiles". [02:01] Yes. [02:01] So I think there's a little more work to do to make our diff from Debian only the meaningful ones [02:01] For example I'd also use the Debian descriptions unless you think the Ubuntu ones are enough better to be worth sending a patch to Debian. [02:02] It looks like debian/rules could be better aligned similarly. [02:02] kamalmostafa: This is a very good start. [02:02] Okay that seems like a reasonable endeavor for e.g. debian/control, but what about the generated files in the root directory -- those are sure going to differ greatly from Debian. Is that going to be a problem? [02:03] I just looked in the debian dir so far. [02:04] For that we'll keep one or the other, I don't know yet which. [02:04] :-) Oh, you don't want to look up at Makefile.in ;-) [02:04] I'm banking on keeping "the one that works". [02:05] Those should disappear on the next upstream release. [02:05] Well, as it stands, I think it actually "works" -- the two packages together do build in PPA and install on my Karmic machine. But yes, I'll make another pass over the debian/* files to reduce the diff. I'm for leaving the generated stuff alone though. [02:06] OK. Let's see. You're off to a good start. [02:07] ScottK: you still looking at tifiles? or ready to move on to a ticalcs? [02:11] kamalmostafa: I suspect if I did, I'd just tell you the same thing. Want to take another pass at them both first? [02:12] Sure that's just fine, one side note: What about libticables2? (libticalcs-dev depends on libticables2-dev). Is it going to need the same "2-removal" treatment? [02:12] Yes. [02:13] We'll want to switch to the Debian package names and if there are any reverse-build-depends they'll have to be changed [02:13] Looks like tilp2 is affected as well. === asac_ is now known as asac [02:14] What a mess. Well, since those ones aren't breaking (yet), how about we just deal with tifiles & ticalcs as "stage 1", and then deal with the rest as "stage 2". Will that work? [02:18] Yes. [02:19] libticables2-dev will be NBS (Not Built from Source) once we upload the new libticables, but won't actually be removed until it had no reverse-build-depends [02:19] (or depends) [02:19] Okay, good plan. Thanks for the review Scott -- I'm off to dinner, then will make another pass at these two. Will let you know when ready for the next review. All good? [02:23] Ye[ [02:23] Yep [03:20] hi all, I am working on this merge and bzr says that there are conflicts in control and changelog, I understand the changelog part but my question is shouldn't there be conflicts in more than that or is that okay [03:21] dhillon-v10: generally that means the merge is clean [03:22] crimsun, this is a merge from main so I was hoping something super complicated that I can't do but it seems plausible :) [03:24] There will only be conflicts where the both Ubuntu and Debian have made changes in the same place; unless we're both fixing the same bug independently, that should be fairly rare. [03:24] RAOF, crimsun thanks :) [03:25] RAOF2, oh btw what does >> mean in version numbers, is it greater than [03:27] Yup, greater than. [03:27] Strictly greater than, in fact. [03:28] RAOF2, thanks again [04:26] does debcommit automatically use --fixes lp:xxxxxx? [04:28] yes [04:28] yay! [04:29] indeed [04:30] example: http://pastebin.com/d66dc32c3 [04:30] O:-) [04:35] crimsun, I did the merge here: https://bugs.launchpad.net/ubuntu/+source/acpid/+bug/507778 does it look right [04:35] Ubuntu bug 507778 in acpid "Please merge acpid (1:2.0.0-1) from Debian testing" [Undecided,New] [04:40] jdong: ping on an SRU [04:41] wondering if I can get approval for bug 350902 [04:41] Launchpad bug 350902 in kdepimlibs "[ubuntu 8.10] kio_imap4 hangs" [Medium,In progress] https://launchpad.net/bugs/350902 [04:42] sure, gimme 5 minutes [04:42] Thanks [04:47] Why do we have a 'unapproved' queue for -proposed uploads. We never upload packages to -proposed without a SRU approval? So what is point of another approval? [04:47] slytherin: according to the wiki process, upload is supposed to occur before approval [04:48] micahg: AFAIK, approval form SRU team is required before upload. [04:49] well... [04:50] both https://wiki.ubuntu.com/StableReleaseUpdates#Procedure and https://wiki.ubuntu.com/ArchiveAdministration#Stable%20release%20updates seem to imply you don't [04:50] in the old days, ubuntu-sru tended to be a subset of ubuntu-archive [04:50] and archive admins found it much more natural to use queuediff to process SRU's as they're clearing the upload queues [04:50] hence upload and reference LP #, wait for approval [04:50] but MOTU-SRU (at first didn't have, later didn't know of) the tools, and preferred using LP team subscriptions [04:51] hence for MOTU, it tended to be ACK before upload [04:51] now, I guess upload-and-wait is the correct procedure? :) [04:51] well, if it's different the docs should be updated... [04:52] well I think for now, the right thing to do is to update the docs and slap the people who don't follow it [04:52] (innocently looks away) [04:52] jdong: approval first? [04:52] upload first [04:53] jdong: that's what it says :) [04:53] jdong: And what happens when when Martin Pitt gives approval, package is uploaded and is waiting in queue? Whom do I need to bug about it. [04:53] slytherin: archive admins, in that case [04:53] slytherin: What package? [04:54] wow, what a big debdiff :) [04:54] ScottK: evolution-mapi. [04:54] slytherin: What bug? [04:54] oh that's not a debdiff [04:54] * jdong obviously needs caffeine [04:54] ScottK: bug 472552 [04:54] jdong: would you prefer a debdiff? [04:54] I can accept it if pitti approved it. [04:54] Launchpad bug 472552 in evolution-mapi "Please upgrade evolution-mapi to 0.28.1" [Medium,In progress] https://launchpad.net/bugs/472552 [04:54] Looking [04:54] JontheEchidna: haha no no, it's fine, I got it now :) [04:55] :) [04:55] silly midnight blind clicking [04:55] I was a bit unclear on the process too. Generally pitti just uploads and accepts at the same time :P [04:56] JontheEchidna: haha yeah, since the unification of the teams I guess there's been a bit of a shakeup :) [04:56] the dust will settle soon [04:56] JontheEchidna: ok you've got an ACK, carry on! [04:57] jdong: thanks [04:57] slytherin: Done. [04:57] ScottK: thanks. Do I need to add that response in bugs 'please test package from -proposed'? [04:58] slytherin: No. Did that as part of the process. [04:58] great [04:59] ScottK: I am wondering if I should request for standing exception for evolution-mapi. [04:59] No opinion. I'm not on the SRU team. [05:00] You'd have to ask the tech board for the exception. [05:00] I meant for micro releases actually [05:00] Ok. I will mail them. [05:00] is there a standing-exception... yeah what ScottK said :) === ripps is now known as ripps|sleep [06:09] ScottK: You forgot to add comments on other bugs fixed in evolution-mapi upload. Should I do that? [06:09] slytherin: Add a comment that test results should go in the bug I marked. [06:10] Ok [06:10] Or I could add comment and set the bugs is verification-needed. [06:10] s/is/as/ [07:01] Could someone please review new package ipwatchd ? http://revu.ubuntuwire.com/p/ipwatchd [07:03] jariq: Regarding point 4 of my previous feedback: why do changes in debian/rules need to wait for an upstream release? [07:04] persia: hm.. i thought you were talking about "rm -f" in Makefile in upstream package [07:04] Well, it's a good idea to fix that too :), but your debian/rules is also a makefile. [07:05] Mind you, without all the other stuff, it becomes minor enough not to warrant another upload, I just wondered. [07:05] My personal preference is to have the logs show if anything unexpected happens, just so that when something does fail, I can figure it out. [07:05] On the other hand, the way you're doing it might save kilobytes of storage space over the package lifetime. [07:06] (and it's exceedingly unlikely that failure to remove some stamp files would interrupt a build) [07:06] Bah, your package is in good enough shape that it needs a real review. [07:07] I'll hit it if I get time while I'm doing reviews tonight, but there's nothing I can tell you in a couple minutes that would improve it. [07:08] persia: ok thanx a lot.. I'll take a look at that 'rm -f ' stuff meanwhile [07:08] Really, it's so minor it's not worth updating the package to make the change. [07:08] It's just a stylistic thing. [07:09] Probably more important if the target was an interesting file that might not be there or might have been created at the wrong time. [07:09] But for stamp files, it doesn't matter at all. [07:10] ok [07:11] anyone has an idea why I'm getting this error: Function `gtk_tree_view_column_get_cell_renderers' implicitly converted to pointer at ignoregui.c:192 [07:11] * persia idly wonders if a dh(1) package using rules.tiny could just ship debian/rules as a symlink to /usr/bin/dh [07:11] fabrice_sp: In what context? [07:11] line is GList *list = gtk_tree_view_column_get_cell_renderers (col); [07:12] and function is declared as GList * gtk_tree_view_column_get_cell_renderers (GtkTreeViewColumn *tree_column); [07:12] (my upload of xchat is FTBFS in amd64) [07:12] OK. What's the type of the col variable at the time of the function call? [07:13] GtkTreeViewColumn *col; [07:13] * persia has no idea given that code [07:13] the same for me :-/ [07:14] it's not a FTBFS as is, because the build is fine, but some sort of check is run on code after the building [07:14] * fabrice_sp never saw that before [07:14] So it's a make tests failure? [07:15] it seems to be an "automated build log filter" [07:15] http://launchpadlibrarian.net/37913661/buildlog_ubuntu-lucid-amd64.xchat_2.8.6-4ubuntu3_FAILEDTOBUILD.txt.gz [07:15] Check the rules file. Some rules files will run a test suite. It may be that someone patched something and forgot to update the test suite. [07:16] hmm, actually, the message gives some links [07:16] * fabrice_sp should have looked at that before :-/ [07:17] point to http://wiki.debian.org/ImplicitPointerConversions [07:17] Also, look at line 1732 of the build log. [07:17] The error is reported there, it's just not enough to kill the make. [07:18] ok [07:18] It looks like some header is missing, because the compilation claims "ignoregui.c:192: warning: implicit declaration of function 'gtk_tree_view_column_get_cell_renderers'" [07:18] So it may never be seeing " GList * gtk_tree_view_column_get_cell_renderers (GtkTreeViewColumn *tree_column);" for some reason. [07:19] Maybe a scoping error also. [07:19] make sense. I'll have a look later. Thanks! [07:19] Good luck. [07:20] thanks ;-) [07:20] Note that this really only affects ia64, but it's worth checking for everything :) [07:20] (because amd64 will *try* to use 32-bit-safe pointers, if it can) [07:20] I know: the problem is that it really blocks amd64 also :-/ [07:21] FTBFS [07:21] Doesn't it block all architectures on the buildds? [07:21] no: only ia64 and amd64 [07:21] If not, it's worth asking a buildd admin why not [07:21] That seems silly to me, but OK. [07:21] have to go. Bye ;-) [07:21] Bye :) [07:30] good morning [07:36] morning === SuBmUNDo`OuTzZ is now known as GotchA === slytherin1 is now known as slytherin [10:10] Hi! Could someone please review qt-shutdown-p (I'm waiting since days)? http://revu.ubuntuwire.com/p/qt-shutdown-p [10:14] dholbach: please unsubscribe u-u-s (and subscribe yourself) when sponsoring a merge [10:14] bdrung_: why? [10:15] bdrung_: once the bug is closed it shouldn't matter any more who's subscribed, or does it? [10:17] dholbach: when searching lp directly or when someone writes a comment [10:19] hum, generally the bug (that's been closed after upload) shouldn't turn up in bug lists any more... only if you search for all bugs ever [10:20] dholbach: yes, but sometimes i search for all [10:21] what is your use-case? [10:21] I never bothered to do it and am not sure who else does :) [10:22] but yeah I could do it if it's really necessary [10:22] anybody else who has an opinion? [10:30] dholbach: The sponsoring procedure documents unsubscribing, and lots of people do it. [10:30] I see [10:30] maybe I'm the only lazy guy then ;-) [10:30] I wrote that bit, to cover two cases 1) often bugs will have other tasks not currently needing sponsorship, which clogs the LP view [10:31] and 2) sometimes bugs need later attention because something went wrong, so it's good for the original sponsor to be paying attention, but nobody else needs to care (unless there's an issue, in which case the submitter might again subscribe the queue) [10:32] dholbach: You're not the only lazy guy, just one of them :) [10:33] Could someone please review qt-shutdown-p? ';.;' *pleeeease* http://revu.ubuntuwire.com/p/qt-shutdown-p [10:34] hakaishi: Some reviewers have an informal policy that any package that gets reviews requested with less than 24 hours passing between requests get ignored. [10:34] Not that your package doesn't deserve review, but just a warning that asking too much may have the opposite effect. [10:35] hmm... the last view days I asked just two times a day... I think this isn't too much to bear [10:36] but, thanks [10:36] You may be right. Depends on the reviewer. I don't believe we have an active REVU coordinator this cycle, so I'm not sure there's any firm policy. [10:38] okay, then I'll just try to ask every 24 hours and 5 minutes ^^' [10:38] That's what I used to advise people when I was REVU Coordinator. [10:39] Well, actually, I used to advise about every 30 hours, to have the best chance of catching different people at different times of day. [10:40] okay, thank you! See you then ^^' (you seem to be online almost all the time) [10:41] I'm almost always online, but sometimes I have significant lag (rarely more than 100Ksec) === shriekout is now known as rororororo === rororororo is now known as shriekout [11:42] 0hi! [11:44] fixed all lintian warnings on http://revu.ubuntuwire.com/p/ctemplate and the last thing remaining is, what is that .symbols file for and where do i get usefull documentation or a package using it? [11:54] freinhard: http://wiki.debian.org/UsingSymbolsFiles [11:58] slytherin: no example there [11:59] freinhard: for example you can check gtk+2.0 package [12:03] slytherin: ok, undestood what that file does and what it is for. [12:03] slytherin: these files aren't manually created, are they? [12:03] freinhard: I haven't used it so don't know the details. [12:04] freinhard: https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols is fairly good documentation. [12:05] I tend to create the file at packaging time (using tools), so that the package FTBFS if the symbols don't match. [12:05] persia: not the shortest docs for a single file i've ever seen ;) [12:05] Well, no, but that's not a bad thing. [12:05] Consider all the documentation that exists on how to deal with debian/rules, when one can just use /usr/share/doc/examples/rules.tiny [12:10] persia: is that path correct? [12:11] slytherin: no it isn't, there's a debhelper missing [12:11] :-) [12:11] Good catch, both of you :) [12:12] ok, from the docs i see that exporting a single environment variable should trigger dpkg-gensymbols and i can gather the output for the symbols file after building the dsc with pbuilder? [12:18] freinhard: I've added some comments to ctemplate [12:19] freinhard: Right. Once done, copy that file back into your source package, so it will compare the generated results against the defined results at build-time. [12:19] When upstream introduces new symbols without breaking ABI, add the right version hints. [12:19] When upstream breaks the ABI, create a new symbols file. [12:23] hmm didn't work with cdbs, looks like this gets called for debug packages only [12:40] persia: if the environment variable is set, dh_makeshlibs should have called dpkg-gensymbols? [12:44] freinhard: I don't remember having set an environment variable, but perhaps. You might also try `touch debian/libctemplates.symbols` to generate a broken one and get the conflict output. [12:45] just tried that, still running === Pici` is now known as Pici [13:01] persia: where did you find a .la file? [13:02] persia: just checked the .deb file with gdebi and couldn't see one. [13:03] freinhard: I saw it listed in your .install file. [13:03] http://revu.ubuntuwire.com/revu1-incoming/ctemplate-1001150403/ctemplate-0.96/debian/libctemplate-dev.install [13:04] So if you're not seeing it in the package, then something else is wrong. If you are seeing it in the package, you should change it so you don't (referenced to the squeeze release goal) === jtechidna is now known as JontheEchidna === azeem_ is now known as azeem [14:29] Heya gang [14:30] bddebian: !!! [14:31] Need help with oython. I am trying to install reviewboard which defines dependency on paramiko. I have already installed package form repository but reviewboard installer is not detecting it. [14:32] Heya persia! [14:34] huhu bddebian :) [14:35] Heya sebner [14:37] Hey. [14:38] * sebner waves at iulian too [14:46] <^arky^> hi, who's the right person to answer a question on upstart event handling [14:47] ^arky^: I'm not sure there's any right person. [14:48] But it also depends on context. If you're looking to put an upstart job in a package, we might be able to help. If you're writing an upstart job from scratch, you might want to talk to the upstart team. [14:48] <^arky^> Then I will ask the question anyway, https://answers.edge.launchpad.net/upstart/+question/97511 [14:48] <^arky^> need to write upstart job for gnome-orca package, upstart team looks like a good bet [14:50] Yeah, for that sort of thing, you probably need upstream support. [14:59] <^arky^> Yeah, I have bug 507953 created for this, how do I bring it to the notice of upstart team [14:59] Launchpad bug 507953 in gnome-orca "Upstart keybinding event to restart orca" [Undecided,New] https://launchpad.net/bugs/507953 [15:00] <^arky^> think I'll subscribe upstart developers team and keep my fingers crossed [15:00] Um, surely there's a better way. [15:01] ^arky^: Try asking in #upstart (based on http://upstart.ubuntu.com/development.html) [15:07] <^arky^> persia: I already did [15:07] <^arky^> no response [15:08] Have you tried the mailing list? [15:26] persia: do i need to pass some magic commandline option to dh_makeshlibs to get the symbols output? [15:26] freinhard: I'm afraid I don't remember offhand [15:27] You can always run it manually if you do a local binary build (debuild -b) in a chroot (schroot -c or pbuilder --login) === ripps|sleep is now known as ripps === MTeck-engaged is now known as MTecknology === yofel_ is now known as yofel [16:52] what's the benefit of having /usr/lib/libfoo.so in the -dev package? [16:52] you can link against -lfoo [16:53] ok, my question should have been: why put libfoo.so in the -dev and not in the main package? [16:54] because you only need it during building other packages (or software in general) [16:55] thank you for clearing that up! [16:56] huhu geser :D [16:56] still trying to figure out how to get that symbols file [16:56] Hi sebner [16:56] tried debian/(dev-packagename|package-name|parent-directory-name).symbols [16:57] none of them cause dh_makeshlibs to call dpkg-gensymbols [16:58] what does "if (-e" in perl check? exists? [16:59] have you also tried debian/libfoo1.symbols (or how exactly your library package is named) [17:00] yes, do they need to contain something? just put a empty file there [17:00] don't know, haven't need to use this yet [17:04] if a package contains a optional .vim syntax file that's usually goes to /usr/share/docs, should i install it to /usr/share/vim/vimcurrent/syntax/ ? [17:06] hmmi guess not, would imply having vim installed... === cyphermo1 is now known as cyphermox [17:12] persia: about the copyright file: copied that from upstream svn, so i guess this should be fine? [17:39] What is the correct procedure for sponsored SRUs? Suppose we have a good debdiff and bug description. What happens next? ubuntu-sru ack or upload to -proposed? [17:51] http://revu.ubuntuwire.com/p/ctemplate could need some more review :) [17:57] randomaction: It's a bit confused, but I think the consensus is upload. [17:59] Also, what does opening a task for a stable release imply? It means you think that the problem is worth a SRU, right? [18:01] yes. [18:02] thank you [18:02] Although sometimes I'll open one against all affected releases and wontfix the ones I think we shouldn't do for clarity === micahg1 is now known as micahg [18:12] anyone willing to sponsor my (almost ;) ) perfect ctemplates package? http://revu.ubuntuwire.com/p/ctemplate [18:31] anyone knowing how to fix xchat in amd64? The log is there http://launchpadlibrarian.net/37913661/buildlog_ubuntu-lucid-amd64.xchat_2.8.6-4ubuntu3_FAILEDTOBUILD.txt.gz [18:33] The line that fails is this one: GList *list = gtk_tree_view_column_get_cell_renderers (col); and I tried to include [18:35] bbl [18:37] ScottK: Hi Scott. I've re-done the libtifiles2 merge -- this time keeping the older Debian autoconf products and most of the debian/ file contents. After folding in the one actual code change that Ubuntu picked up from the maintainer, the merge diff is really only a dozen lines or so: https://code.launchpad.net/~kamalmostafa/ubuntu/lucid/libtifiles/libti-backmerge [18:38] fabrice_sp: I see that in that header file, the prototype you need is wrapped by #ifndef GTK_DISABLE_DEPRECATED -- is that the problem perhaps? [18:41] kamalmostafa: Great. I'm busy with $WORK right now. I'll try and look at it tonight. [18:41] ScottK: That's fine. [18:49] kamalmostafa, will have a look. Thnaks for the idea! :-) [18:50] fabrice_sp: glad to help! === and`_ is now known as and` [19:58] Problem: After updating a .gmo file, my bzr builddeb -S fails: dpkg-source: error: cannot represent change to .../po/fr.gmo: binary file contents changed [19:58] Advice? [20:08] kamalmostafa, update the source (.po file?), and modify the debian/rules to generate it again, if it's not the case [20:13] fabrice_sp: I'm not at all familiar with the po/ methodology. There is a fr.po file (and a fr.gmo) already checked into this bzr tree. I'm trying to replace them with the fr.po and fr.gmo from a later version of the same package. So I don't think the .gmo needs to be generated again -- just needs to be rolled into this change. I can "bzr commit" it no problem -- just can't build a test source package with "bzr builddeb - [20:14] AFAIK, you can't commit a binary change [20:15] bzr commit accepts it with no argument. :-) [20:16] Is it abnormal that a .gmo file would be checked in at all then? [20:17] kamalmostafa: Yes, quite abnormal [20:17] Unless it's by way of it being shipped in an upstream tarball, and thus imported. [20:17] sorry: building classpath is killing my computer :-/ [20:18] In which case, what needs to happen is that the .gmo is unchanged whilst building the debian source package [20:18] * fabrice_sp was going to say the same thing :-) [20:19] maxb: okay, I think that does fit this situation -- both the "original" and my "target" packages were imported from upstream. [20:20] generally, in that cases, I modify the clean target to delete the generated binary files, and build them [20:20] even if the binary file comes from upstream [20:21] So now when exactly will the new .gmo be regenerated? (just part of 'make'?) [20:21] kamalmostafa: OK. Make sure that _you_ don't commit any changes to those binary files - they should be left identical to those coming from the upstream import. [20:21] Well, that's dependent on the specific package's buildsystem, but hopefully yes [20:23] Got it (and I'll test it to make sure that happens). So let me get it straight... Its fine to change the .po, but leave the .gmo alone when building the source package; the .gmo should get regenerated as part of the build anyway. Yes? [20:23] Correct [20:23] maxb and fabrice_sp: Thanks very much! [20:46] hi, is there a page about the Prevu tool ? Who said exactly it does in its automated backporting ? [21:01] hi folks [21:01] huhu sistpoty :D [21:01] hi sebner [21:01] hi [21:01] hi freinhard [21:02] qnix: prevu is mainly just a wrapper around pbuilder. If you want to use it for anything complex, I recommend learning about pbuilder directly. [21:02] looks like people with sparetime! go for it: http://revu.ubuntuwire.com/p/ctemplate :D [21:02] qnix: See also cowbuilder / cowdancer, which will save you so much time if you do lots of things with pbuilder [21:02] ah, I already use cowbuilder. [21:03] Then you don't really care much about prevu [21:03] I thought prevu was something that fixes incompatibilities between different version of debhelper etc.. [21:03]