[00:13] i have a question regarding updating a library package [00:14] for protobuf in intrepid the library was libprotobuf0 in intrepid the current version is libprotobuf2 based on upstream version 2.0.2-1. I am trying to update the package so it is based on 2.0.3 [00:15] do i need to rename libprotobuf2 to something else or can it remain as libprotobuf2 [00:26] serialorder: only rename it if the SONAME changed [00:27] e.g. if you have libfoo.so.2 and it changes to libfoo.so.3 with the new version, then it changed the SONAME [00:33] pochu: thanks, is there a place I can look to check if that is the case? [00:33] i found out by compiling but I am sure there is some easier way to tell without having to compile [00:38] serialorder: check out https://wiki.ubuntu.com/PackagingGuide/Recipes/CheckingLibrarySymbols [00:38] serialorder: but the SONAME is usually bumped in configure.ac [00:39] so you can do a `diff libfoo-1.0/configure.ac libfoo-2.0/configure.ac` [00:47] thanks pochu [02:54] I want to make a package of my .bash_profile, .bash_aliases, .vimrc etc... [02:54] Is there a way I can do that? [02:55] I know there are theme packages... [02:56] right now I can reinstall everything from repos except config files. [02:57] et3: The defaults are in /etc/skel, do you want to create modified packages for bash, vim, etc to include your own variant config files? [02:58] jmarsden : it's more like I want all my ~/."${CONFIG_FILES} in one package [02:58] like ./bash_aliases [02:59] I suppose I could customize each individual package... [02:59] Well, if you always use the same username everywhere, you could create a package containing them that puts them all into /home/et3/ [03:00] Are you building a variant distro with this package in it?? Why does it need to be a package? [03:00] couldn't I use the system's "~" ? [03:00] easier to install [03:00] The system doesn't have one... you mean /root/ ? [03:00] no... [03:01] ~ is defined as the home dir for the current user... ;) [03:01] yeah... That'd be the one I'd want to install the package for... but I suppose packages are meant to be a "system-wide" thing. [03:02] ...hmmm [03:02] I just stick a tarball up on the web somewhere and then I can do wget http://www.example.com/mytarball.tar and then tar xf mytarball.tar and I'm done. [03:02] I'd rather go with git [03:02] That way I have my files even on systems that are not Debian/Ubuntu based. [03:02] and if I'm using a cvs thing, why not package it? [03:03] good point [03:03] Not ever machine you ssh into will have git installed... will it? But almost all will have wget or curl. [03:03] another good point. [03:04] What about your other files? Do you have a packaging system for your media? [03:04] maybe I'm just going package crazy since I learned how to make them. [03:04] For music/photos etc? No... I don't need them to travel with me around the Internet ;) [03:05] I plan on setting up a server for my media files. [03:05] There is a package called etckeeper for putting /etc/ in a VCS. [03:05] right now I can use filezilla... but I want to make it a browser-based thing. [03:05] If you have ssh access to it you can grab them via sshfs or (if necessary) with scp or sftp... [03:06] * et3 googles etckeeper [03:06] right. [03:08] mercurial looks cool [03:09] * et3 waves goodbye [03:10] Bye et3, have fun! [03:10] jmarsden : thanks bye ^^ [03:31] Lutin: Hi, were you planning on doing the babel merge? === eric is now known as Guest47181 [03:51] when upgrading a package what needs to be provided in LP? [03:54] diff.gz [03:55] that is a diff between? [03:55] is it a debdiff between the previous version and the upgraded version? [03:58] serialorder: No. Make the upgraded package. A source package has the orig.tar.gz, the diff.gz, and the .dsc. [03:58] The diff.gz is the only part a sponsor needs to reconstruct your package. [03:58] ahh [03:59] They'll fetch the orig.tar.gz themselves. [03:59] Aww, man. How do you get $(addprefix $(FOO)) to work when some of the files in FOO have spaces in their names? [04:02] "$(addprefix $(FOO))"? [04:02] or something akin to that? [04:03] The function is actually $(addprefix bar/,$(FOO)), so that won't work; it'll add bar/ to the start of each space-separated component of FOO. [04:04] oh. That's a tough one; how do you build FOO? [04:04] ScottK I dont see a diff.gz [04:05] i see a .dsc,.build, .changes, .tar.gz [04:05] serialorder: You've got your updated package prepared? [04:05] serialorder: Then you've got a native package. [04:05] serialorder: What package are you upgradingin? [04:05] well I wasnt sure how to name it actually [04:05] protobuf [04:06] previous version was protobuf-2.0.2-1ubuntu1 [04:06] trying to upgrade to 2.0.3 [04:07] Yeah. It shouldn't be a native package. [04:07] What's the name of your tar.gz [04:09] i think i messed that part up [04:10] i have protobuf-2.0.3.orig.tar.gz and protobuf_2.0.3ubuntu1.tar.gz [04:10] I'm guessing. [04:10] i wasnt sure what to call it because the version isn't in debian yet [04:11] The existing orig.tar.gz is protobuf_2.0.2.orig.tar.gz [04:11] So you want protobuf_2.0.3.orig.tar.gz [04:11] The revision doesn't go on the orig.tar.gz. [04:11] In debian/changelog you'll want to say it's 2.0.3-0ubuntu1 [04:14] serialorder, pinmg [04:14] *ping [04:14] oh :-) [04:14] serialorder, I'm test building your patch on sparc right now [04:14] DO you know if the new upstream builds correctly on sparc/ia64? [04:15] the new upstream fixed the sparc FTBFS but it hasnt fixed ia64 yet [04:16] coppro: How do I build FOO? FOO = file1 \ file2 \ Stupid Space Including Dir/file3 \ etc... That will obviously have to change, but I don't know how. [04:16] serialorder, I have access to both SPARC and ia64 [04:16] I can kick builds off on both [04:16] if necessary [04:16] serialorder, do you want me to sponsor the existing patch, or should we wait for the new upstream? [04:17] RAOF: replace each space in the arguments with "\\ " [04:17] (what language is that, btw?) [04:17] NCommander: lets hold off, i just finished upgrading to the latest upstream [04:18] oh cool [04:18] coppro: Make [04:18] ScottK: thanks for the help have the diff.gz now =) [04:18] serialorder: You're welcome. [04:18] RAOF: ah. Hmm... never really gotten into that complex of Make before [04:18] serialorder, if you can kick it onto REVU or into a PPA (someplace where I can get it), I can test build on both SPARC and IA-64 [04:18] coppro: Sorry, thought that would have been obvious from the syntax :) [04:18] as I said, never gotten that complex [04:18] this is my first upgrade =) [04:18] in my experience though, escaping spaces works [04:19] serialorder: Glad to have you here helping out. [04:20] coppro: Yeah, escaping them doesn't work here :( [04:22] RAOF: you can't escape them as they go into FOO? [04:23] I can escape them as they go into FOO, but it doesn't help; the escaping is undone when FOO is processed by $(addprefix [04:25] oh [04:25] double-escaping? [04:33] NCommander: protobuf is now on REVU [04:34] * NCommander wanders over to REVU [04:34] serialorder, link? [04:34] NCommander: http://revu.ubuntuwire.com/details.py?package=protobuf [04:35] serialorder, I already see a mistake [04:35] YOu forgot to change a depends :-) [04:35] doh [04:35] lintian is your friend [04:36] serialorder, did you try test building in pbuilder or a PPA? [04:38] anyone up for a REVU of my package? [04:39] oh, i see the mistake [04:39] sorry [04:39] haven't used lintian before, actually haven't heard of it before, must have missed that wiki page [04:41] serialorder: https://wiki.ubuntu.com/PackagingGuide/Complete [04:56] NCommander: I think I fixed all the problems, also test built with pbuilder and installed http://revu.ubuntuwire.com/details.py?upid=4284 [04:56] execellant! [04:57] serialorder, did you toss the ia64 fix in? [04:57] ah [04:57] yup [04:58] I'll testbuild on bot sparc and amd64 [04:58] i did and now im going to go report that upstream [04:58] sparc build started [04:59] not amd64, ia64 [04:59] no, both [04:59] my ia64 is slow [04:59] So I'm not going to bother test building on it unless its really necessary [05:00] uh [05:00] This script requires setuptools version 0.6c8 to run (even to display [05:00] THat's not going to work [05:01] Buildds do builds as non-root, and don't have internet connectivity [05:01] I'll fix it if I can [05:03] it was like that in 2.0.21ubuntu1 and those built fine except on ia64 and sparc [05:04] It pulled in the pbuilder root for me [05:04] I'm just adding the explicate build-deps [05:05] NCommander: We do patch setuptools to not pull stuff from the internet that's already installed, so that should do it. [05:05] I didn't have setuptools installed :-) [05:05] The build-dep wasn't there at all [05:06] it works fine if setuptools is installed [05:17] NCommander: is there anything else i need to do now? [05:18] I got a test suite failure ... [05:18] It went boom on amd64 [05:18] which caused an FTBFS [05:19] serialorder, http://paste.ubuntu.com/87553/ [05:19] serialorder, I won't upload it since that test suite failure will break the build on amd64 [05:20] serialorder, I left a comment on REVU [05:20] so then should we just patch the current version? [05:30] pbuilder is stupid; it insists on using hardy [05:30] how do I tell it I want intrepid? === hyperair1 is now known as hyperair [05:31] Depends on how you set it up. [05:31] https://wiki.ubuntu.com/PbuilderHowto [05:31] wait, I think I figured it out [05:35] NCommander: I checked and that but has been reported upstream but there is not fix. I am thinking maybe we should just patch version 2.0.2-1 and hold off on the upgrade [05:36] * NCommander falls over [05:38] yeah your telling me, spent all day trying to figure out how to do an upgrade =| [07:07] good morning [07:08] NCommander, ping [07:08] serialorder, semi-pong [07:09] actually found a fix build failure, but i can save it for tomorrow if necessary [07:09] the amd64? [07:09] yeah [07:09] built it on PPA and it built fine [07:10] I'll upload [07:10] link to your PPA [07:10] serialorder, stupid question, are you using a patchsystem? [07:10] no, there was no patch system in place [07:10] so ive just been modifying source [07:10] * NCommander normally perfers if you add one in that case [07:11] Which makes merging it a headache later on [07:11] a very big headache [07:11] :-/ [07:11] i see, i got scolded when i first started for adding a patch system [07:11] Who scolded you? [07:11] Well, except when the maintainer decides to add a different patch system ... [07:11] Oh, the package had a patch system already? [07:11] jwestby [07:11] If the package has a patch system, use that [07:11] if it doesn't have one, add one, or at least that's what I do [07:12] there was none so i added one [07:12] but then i was told not to [07:12] Did this happen on IRC or a bug? [07:12] NCommander, Please don't, unless you know that the maintainer in Debian prefers a given patch system, and you are adding that one. [07:12] persia, and then it becomes a pain when you need to carry your changes forward another revision because the debian developer didn't take your patches [07:12] persia, because then you need to find the changes, and reapply them [07:13] https://launchpad.net/~serialorder/+archive [07:13] there is my PPA [07:13] NCommander, Well, if you are adding lots of unrelated changes, and you don't want to use a VCS, I suppose I could support that, but in the vast majority of cases, it adds unnecessary complication. [07:14] cdbs-simple-patch system is one line in rules, and possibly one additional build-dep [07:15] Hrm? If a package already uses CDBS, it's small enough. Adding cdbs as a build-dep can cause confusion. [07:15] * NCommander sighs [07:16] A difference of opinion. I personally feel that the weight of a patch system is worthwhile since it makes it possible to find patches easily and tweak them if need be [07:16] Oh, I do as well. I'm just opposed to *adding* one if it's not previously in use. [07:17] And that's where we disagree [07:17] * NCommander has issues with people changing inplace patch systems [07:18] persia, right now, I'm looking at the debdiff, and I can't tell at all what was or was not added [07:18] Which debdiff? I suspect there is one that shows the specific set of changes that might be more useful to generate. [07:19] persia, its a new upstream version [07:19] which also needs patches [07:21] serialorder, it looks good so far, I'm just doing a second test build so I can run lintian on the binaries [07:21] Ah, then debdiff isn't the useful diff :) Anyway, I'll walk you through useful diff generation if you like, but I suspect you've already gone far enough with this one as to make it not matter. [07:22] persia, sure, I'd apperiate that [07:22] OK. Which package? [07:22] i wouldn't mind such a lesson either [07:23] persia protobuf [07:23] serialorder, just so we're clear, you do know how to use a patch system, right? [07:23] * NCommander would be willing to teach that for future reference [07:23] And it's a new pull from upstream, a merge from Debian, bugfixes, what? [07:23] i have added a dpatch system once before [07:24] merge with Debian with new upstream [07:24] OK. Let me get some files then. [07:25] serialorder, good [07:25] the only patch system thats very different is quilt [07:26] * persia is confused. sid has 2.0.2-1 and jaunty has 2.0.2-1ubuntu1 [07:27] 2.0.2-1ubuntu1 didnt build on sparc and upstream (as in google) fixed that problem in 2.0.3 [07:27] the version to be uploaded is 2.0.3-0ubuntu1 [07:27] OK. So not a merge from Debian: just a new upstream version. [07:27] I thought we were also merging stuff from Debian [07:29] serialorder, it looks good [07:29] * NCommander grabs his GPG key [07:30] persia, any objections if I upload this now? (I already reviewed his changes by checked the diff.gz :-)) [07:31] NCommander, no objections, if you think it's good. My only point was about patch systems, and reviewing methods. [07:31] * NCommander nods [07:31] serialorder, upload in progress [07:32] Anyway, `debdiff protobuf_2.0.2-1.dsc protobuf_2.0.2-1ubuntu1.dsc` shows that the previous changes were just build-dependencies from Debian. [07:32] right but debdiffing against a new upstream is pointless [07:32] As a result, we would expect the changes in the diff.gz to be broadly similar between 2.0.2 and 2.0.3 [07:34] is this a case where you use interdiff between both diff.gz's? [07:34] `lsdiff -z protobuf_2.0.2-1ubuntu1.diff.gz` and `lsdiff -z protobuf_2.0.3-0ubuntu1.diff.gz` have about the same list of stuff: the interesting patch appears to be inpython/google/protobuf/internal/decoder_test.py [07:34] Yep :) [07:34] oooh [07:34] I didn't know about lsdiff [07:34] Now THAT's handy [07:35] * NCommander waits for the accepted email [07:35] `interdiff -z -p1 protobuf_2.0.2-1ubuntu1.diff.gz protobuf_2.0.3-0ubuntu1.diff.gz` shows the relevant changes [07:35] still not ideal, but I can dig it :-) [07:35] serialorder, [ubuntu/jaunty] protobuf 2.0.3-0ubuntu1 (Accepted) [07:35] serialorder, Thank you for your contribution to Ubuntu [07:36] NCommander, awesome thanks [07:36] The first interesting bit is that it referes to libprotobuf3 rather than libprotobuf2, which makes me wonder about compatibilitity with rdepends [07:37] persia, we have nothing that uses it expect protobuf itself ;-) [07:38] Just pointing things out: like I said, I'm not objecting to the upload, nor have I reviewed it in detail. [07:38] * NCommander nods [07:39] serialorder, anyway, nice job on your first package update [07:39] control seems updated to use the new name, so that's all good. Next interesting thing is that the maintainer scripts seem to have dropped the ldconfig call. [07:39] And then we get to the actual source patches [07:40] Later we see the maintainer scripts were only a side effect of the binary name change (this will need binary NEW) [07:40] serialorder, do you know about the NEW queue? [07:41] And the most exciting bit is that neither the build-depends patch nor the 64-bit patch from Debian appears in the interdiff, which means they are preserved. [07:42] serialorder did a good job on the update [07:42] thanks, it took a long time =) [07:42] i don't know about NEW, remmeber reading about it somewhere [07:42] Ok [07:42] Another interesting thing to do sometimes is to pipe the interdiff output through lsdiff, which shows a list of all the files changed by a given revision. [07:43] might have had to reorganize my firefox bookmarks because of all the MOTU wiki bookmarks i made recently [07:43] Every NEW package gets stuck in a special holding area called the NEW queue [07:43] new source packages don't even get built, and packages with new or changed binaries (such as the updated version) get built, but not published [07:43] They get stuck in a queue until an archive admin creates overrides to allow them to proceed into the archive [07:44] serialorder, https://edge.launchpad.net/ubuntu/jaunty/+queue?queue_state=0&queue_text= you can see the new queue, and your package in it [07:48] ubuntu packaging is way more fun than my dissertation =) === doko_ is now known as doko [07:52] good morning === dholbach_ is now known as dholbach [08:36] nhandler: Wazzup? [08:41] Nothing [08:41] I was going to build a package but found something that works as well [08:42] And BTW: how do you get a very basic Gome install onto Ubuntu Server and tell it to start at system startup? [08:46] Well thanks for your help [08:46] Good night. Bani bash [09:09] stgraber: thanks a lot - posted! :) [09:16] nhandler: CONGRATULATIONS! [09:23] go nhandler! [09:23] * Laney waves pompoms [09:23] nhandler: congratulations! [09:23] *\o/* [09:23] yooohoooo! :) [09:26] who has birthday? [09:26] zerwas: nhandler just joined the MOTU team :) [09:26] ah, well. congratulations :D [09:54] stgraber: congrats :-) [09:54] nhandler: likewise! [09:55] <\sh> stgraber/nhandler: welcome on board... [10:09] congrats nhandler :) [10:57] dholbach, thanks for your reply to my U-U-S application :) [10:59] dholbach: You uploaded bakery! YAY! [10:59] quadrispro: u-u-c? ;) [10:59] Laney, yes :D [11:00] dholbach, s/U-U-S/U-U-C [11:01] the final piece of my glom puzzle is almost complete [11:10] quadrispro, Laney: no worries :) [11:13] anyone on bug #296398? [11:13] Launchpad bug 296398 in liblunar "Please merge liblunar 1.0.1-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/296398 [11:59] nhandler: Congratulations. [12:02] can you build and upload packages for Ubuntu if you're not a MOtu (yet)? [12:03] jack_, Prepare, but not upload. [12:03] persia, ok what do you mean by prepare? [12:03] jack_, Generally, one prepares fixes for a while, and works with the sponsors to get them uploaded. See https://wiki.ubuntu.com/MOTU/Contributing [12:04] jack_, Make any adjustments as if one were uploading, and then show the patch for these changes to the sponsors [12:04] persia, and new packages, which are not yet in ubuntu? [12:05] One generally submits those to REVU. See the bottom of the link. [12:08] is it better to build a package from a debian unstable package or just from tar.gz? [12:10] jack_, If it's in Debian unstable, and it's not in Ubuntu, it will be in a few days. [12:10] persia, ok [12:10] hmph. openjdk-6-source-files is incomplete [12:10] This will continue to be true until 25th December. [12:12] where's a javaish person when you need one? /me prods persia [12:12] jack_: see https://wiki.ubuntu.com/SyncRequestProcess for requesting a sync manually (that might be no neccessary in this case but it is good to know) [12:12] Well, I just got up. Thanks everyone for the congratulations. [12:12] nhandler: congrats! it was about time [12:13] directhex, Do you have a bug number? [12:13] persia, no. it might be intentional! [12:14] [exec] javac: file not found: ../../openjdk-b13/control/build/linux-i586/gensrc/com/sun/accessibility/internal/resources/accessibility.java [12:14] can't find a accessibility.java anywhere [12:15] directhex, What's the result of this error? [12:17] well, i can't build this app, that's what. i'm wondering how feasible it is to actually use system source packages [12:18] erk, compiling it eats all my RAM ^_^ [12:20] Hmm. Unfortunately, I'm not sure enough of the specifics to provide advice. I'd recommend asking slytherin or doko [12:21] i can see why this package's maintainer orphaned it [12:45] nhandler: congratulations also from me =) [12:45] Thanks sebner! [12:54] congrats nhandler! [12:54] :) [12:55] nhandler: now, start uploading crack to the archive :-D [12:56] norsetto: You need 2 MOTUs to ack a new package, you know that ;) [13:15] soren, upstream's solution was to unplug the test suite, there is a warning label that it will not work correctly on non-intel architectures [13:15] er, Debian's [13:16] er [13:16] * soren likes how "solution" can be interpreted so very broadly. [13:16] wrong channel [13:19] thats why he has his own target audience [13:21] nhandler: crack can also be merges :P [13:34] sebner: I'm pretty sure he, of all people, knows that already. [13:36] ScottK: sure, that was more something like a joke because he immediately refered to REVU after norsetto told him to upload stuff [13:36] sebner: Yes, I'm just continuing it (and failing apparently). [13:37] ScottK: you should use a smiley like I did :P [13:37] Too early in the morning for smileys (still on the first cup of coffee). [13:39] * sebner is glad to never get up too early in the morning :) === LucidFox_ is now known as LucidFox [14:16] morning ScottK , hi sebner [14:16] heya norsetto =) [14:16] Hello norsetto [14:21] question regarding packaging for libraries. I've previously packaged up opensg 1.8 which has been accepted since hardy. Now the new version is been worked on (2.0) which has major api/abi changes. The easy option would be to conflict them, however it would be nice to have them installed in parallel. Which can easily be done with the headers etc, however I'm unsure as to what I should do with the libs to enable this to happen. Are there an [14:22] DaveMorris: your line got cut off at "Are there an[...]" [14:22] DaveMorris, Have -dev use the new one, and have differing package names for the libs packages. [14:22] Are there any packages which I can look at as examples for this? [14:23] DaveMorris: did the filename of the library change? [14:23] azeem: no [14:23] from /usr/lib/libfoo.so.0.0.0 to /usr/lib/libfoo.so.1.0.0, e.g. [14:23] DaveMorris: what is the filename? [14:24] they don't produce the version part of the so, I did it within the packagin script [14:24] so I guess I need to change that so it's diff [14:24] why did you choose 1.0.0? [14:25] I'm unsure, it may have been suggest to me [14:25] I guess it needs chaning to 1.8 then [14:25] eh [14:25] no [14:25] are there any reverse-Depends for libopensg-core1? [14:26] not in Ubuntu (apart from the others flibs built from that source package) [14:26] DaveMorris, Are you expecting new users to want them installed in parallel, or just current users? [14:27] just current users [14:27] what users are there? [14:27] who don't want to port their applications, but want to fix the bugs etc [14:27] users as-in, applications using this libaray [14:27] OK, if it's just current users, then you can use the same source package name (which makes it easier). [14:27] mainly research projects in different users [14:27] s/users/unis [14:28] azeem, Rather, users being installed systems. [14:28] persia: hrm? DaveMorris said there are no reverse dependencies of those libraries, so I wondered which applications need them [14:28] DaveMorris, Oh, so you do have users who want to recompile against a selected version, and not be upgraded? [14:28] yes [14:29] I guess I can point them at the right so via pkg-config [14:29] DaveMorris, In that case, you need to have multiple versioned source packages. See e.g. wxwindows2.6 + wxwindows2.8. Also, these tend to get rejected without very compelling reasons, so you might want to first package something that can't easily be migrated. [14:30] azeem, Remember that the archives don't yet include all available software. While we only support that in the archives, when working with libraries, it is also useful to consider the uses to which it may be put external to the archives. [14:30] anyone knows which application this is? http://launchpadlibrarian.net/20543025/WindowManager_screenshot.png [14:30] sorry, I don't understand what you mean by " you might want to first package something that can't easily be migrated." [14:30] persia: right, that was my question [14:31] DaveMorris, Essentially, when we have multiple source packages providing the same library, it's harder for the security folks, and we have to keep track of which ones are still active, and which can be dropped. This is a bunch of extra work. [14:32] so you'd rather I just dropped the old one and did the new one [14:32] So, it's nice to have something to justify the extra work: some someware which requires that extra work to be supported. [14:32] Yeah: that makes it easier. You'll want to have a new binary name, and a new soversion if they are incompatible. [14:33] Then, advise users that need the older version to compile against hardy or intrepid, and users that want the newer version to compile against jaunty. [14:33] so libopensg-core1 would move to libopensg-core2 but libopensg-core-dev will stay the same [14:33] yes [14:33] That's the ideal solution, from a distro-maintenance perspective. [14:34] that sounds reasonable to me, since hardy will stay around for a while, if they want it after that they can build the software themselves [14:36] Right. For widely used libraries, with a large number of reverse dependencies, it sometimes becomes worth carrying two versions of the library source in the archive to reduce porting pressure, but without the rdepends, there's just not a lot of incentive. [14:53] RainCT, that link doesn't seem to be working [15:00] norsetto: Here it works. But well, isn't that important. [15:02] RainCT, hmmm, I think I know why, I just downloaded the newer firefox update [15:08] Heya gang [15:13] norsetto: I have it too :) [15:38] norsetto: ah, right, you need to restart [15:39] norsetto: I too was sorta "wtf??" for the first seconds when it refused to load any page :P === RainCT changed the topic of #ubuntu-motu to: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Grab a merge: http://dad.dunnewind.net http://merges.ubuntu.com | http://qa.ubuntuwire.com/uehs | http://revu.ubuntuwire.com - Go review! :) [15:46] RainCT: :-) I ALWAYS forget that .... [15:53] nhandler: Congratulations. === WelshDragon is now known as Guest43616 [17:45] what is the way to specify multiple bugs in one line in debian/changelog? [17:48] slytherin: lp: #1234, #12345, #123... [17:49] pochu: thanks [18:09] calc: ping [18:25] slytherin: hi [18:26] calc: libitext-java has depwait in latest version due to libbcprov-java being in universe. Will you add libbcprov-java to the list of packages to be promoted to main for OOo? [18:34] slytherin: probably should file a bug against libitext-java and subscribe ubuntu-mir to it since it is already in main [18:34] * calc isn't sure what is normally done for packages that are sync's that gain more deps [18:34] calc: you mean file bug against libbcprov-java, right? [18:35] calc: anyway, I thought I would tell you since you are handling MIR for all new OOo dependencies. [18:35] i filed the bug [18:35] hmm maybe i'm not sure [18:35] i'll reassign to libbcprov-java [19:10] RainCT: I am motu now. Can you please give me the powers on revu. :-) [19:59] Hi. I'm trying to backport a package from jaunty to intrepid (and paybe later to hardy) [19:59] The package builds well and works ok, now I'm trying to do it well [20:00] I get the source with lget, then dpkg-source -x and dch -i, update the changelog [20:01]