[00:03] ScottK2: what would happen if upstream doesn't have a ChangeLog/NEWS file? Would a diff of the upstream source be ok? [00:04] I'd rather you read the diff and sumarize what you think the changes are than you make me do it. [00:05] ScottK2: hmm, right. It's just in case I need to do it, as stani doesn't have one ;) [00:21] geser: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460362 seems to have fixed it. At least it builds on current hardy. [00:21] Debian bug 460362 in binutils-avr "binutils-avr: FTBFS: Applying patch debian/patches/dollars.patch failed!" [Serious,Fixed] [00:23] geser: shall I request the sync? [00:28] ScottK2: I just added ubuntustudio to that page, thanks for the pointer to it. [00:31] heya * [00:36] Hello emgent [00:36] :) [00:41] TheMuso: Did motu-release give a standing FFe to ubuntu-studio this time around? [00:42] ScottK: I don't know, but ubuntustudio was given one last cycle [00:42] TheMuso: I think it's fine that they have one myself, but we have new people on the team, so I think it should be asked each cycle. [00:43] Fair enough [00:43] I know Hobbsee was fine with it. [00:43] I'll ping norsetto and sistpoty when they're around alter. [00:44] TheMuso: Perhaps a bug with also affects for the relevant packages would be the best way? That way there's no confusion. [00:44] Right. [01:04] slomo_, ping === emgent is now known as enJoy === enJoy is now known as emgent === slangase` is now known as slangasek [02:02] nxvl: hi. I've just realised it's our talk tomorrow (in my TZ at least). I've got to sleep now, but I'll send you some notes in a few hours. [02:03] james_w: ok, for me it's past tommorrow :D [02:04] ah, you've got longer to prepare then :) [02:09] james_w: kind of [02:09] i'm at gmt-5 [02:18] Hello all [02:19] just looking for a little advice on how you all handle python programming, on an individual level... [02:19] for those of you that read dive into python that is [02:22] is this the right place? [02:24] well it's not a motu question, but I just wanted to get some advice on how you all work as individuals... it's not a python question per se but more a personal style question [02:24] I'm dragging it out too long [02:25] do any of you find "dive into python" a good reference book to go back to after you've read it through once? [02:25] oh and happy new year to anyone that recognizes me... I've not been in here in ages [02:26] rmjb: I've read bits of it, and I think it's a good python book but not a good reference [02:28] yeah me too, it doesn't seem to be... I want to support the author, but I guess I wont buy the book [02:28] I like the Python Cookbook as a purchased python book [02:28] it's just a huge library of examples, worth looking at time and time again [02:28] Using package (>= version~) as a dependency or build-dependency is a workaround to also allow backported versions to meet the dependency. [02:29] yes.... yes it is. but *looks at scrollback* [02:29] jdong, cool, I'll look at that one when I'm finished with this one. Thanks [03:18] Fujitsu: have you looked at octave3.0 lately? [03:19] ahh, LaserJock just who I wanted to bug :) [03:19] nixternal: regarding PG? [03:19] haha ya [03:19] stupid ass LP [03:20] what is MOTU? [03:20] Masters of the Universe [03:20] maintainers of Universe and Multiverse repositories of Ubuntu [03:20] masters of the universe...universe being the repositories we maintain [03:20] ya, I forget about multiverse repos, only cuz I don't work on anything in them... [03:20] pfft [03:20] err, except the openttd upload I did I guess [03:21] * persia stresses "Masters", as there are many non-MOTU maintainers of universe software [03:21] what skills do I need? [03:21] a couple [03:22] like, being able to compile software [03:22] like what? [03:22] koolkat: patience mostly [03:22] hunt out application dependencies [03:22] :-) [03:22] patience like LaserJock said, and a lot of it :) [03:22] LaserJock: that seems easy [03:22] :-) [03:22] obviously you have the english language down :) [03:22] * koolkat thinks about joining [03:22] debian packaging [03:23] how to efficiently drink beer and dance while building a package...simultaneously I might add :) [03:23] uhhh....about the packaging part.....is it hard? [03:23] if I can do it, anyone can [03:23] then again, who is to say I can even do it [03:23] where do I learn? [03:23] I just play like it [03:24] http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd [03:24] err [03:24] that isn't going to help [03:24] https://wiki.ubuntu.com/PackagingGuide [03:24] that will though :) [03:24] obviously I was working on some docs...much earlier though..odd that was still in my klipper [03:25] nixternal: ok, so about the PG bugs [03:25] seems there are only 3 of them [03:25] some of the could be closed already [03:26] nixternal: do are you a member? [03:26] so* [03:26] ya, I was thinking the same, with a reference that it has been moved to the wiki and is no longer a package [03:26] I count 8 bugs [03:26] koolkat: yes I am [03:26] err, where did I miss 5 of them [03:26] nixternal: you have to look at both the ubuntu-docs package and project [03:27] TheMuso, with these changes to the seeds, how do you *not* include stuff from hardy.platform? [03:27] there is lots of stuff in there that we dont want [03:27] ahh ya, the project [03:27] is there going to be a rewrite or something of the PG on the wiki? [03:27] nixternal: what do you mean? [03:28] LaserJock: I think what I will do, is close the bugs, take out the contents, and add them to the Maintenance page of the PG on the wiki [03:28] LaserJock: nevermind, I was thinking of something else [03:28] nixternal: yeah, we might do that [03:28] it'd be nice if we had a way to deal with the bugs [03:28] I can do that really quick [03:28] well it is on the wiki now, so maybe adding a section to the Maintenance page for people to file an issue [03:29] nixternal: what are the tasks that you do? [03:29] in MOTU? [03:29] nixternal: yeah, that makes sense [03:29] koolkat: I mostly help maintain Kubuntu/KDE packages, but I also help others with packaging when they need it, and help anyway I can [03:29] really don't have a "single" task perse [03:30] LaserJock: OK, I will finish that up right now then [03:30] what do you mean by "maintain" [03:30] nixternal: thanks [03:31] nixternal: what do you mean by "maintain" [03:32] generally things like making sure we're updated, incorporating bug fixes [03:32] koolkat: There are three main thrusts of activity: fixing bugs in the software, making sure that all the software works together, and making sure the software is mostly up to date. The third part is done for hardy, but the first two would benefit from your assistance. [03:32] I guess I could join...i think [03:33] i hope [03:33] * koolkat worries [03:33] koolkat: Best way to start is to find a couple bugs that need fixing, prepare patches, and submit debdiffs of new candidate revisions. See https://wiki.ubuntu.com/MOTU/Contributing. [03:34] persia: Is there a specific place to join MOTU? === danielm__ is now known as danielm [03:35] koolkat: Joining MOTU is not really the first step. Only about 1/3 of the people who have uploaded packages to hardy are MOTU. You'll want first to be a Contributor, and if you are dilligent and active, you will be encouraged to apply for MOTU. [03:35] Oh [03:36] bug 116757 [03:36] Launchpad bug 116757 in ubuntu-docs "Packaging Guide not clear on "rules" having to be executable" [Low,Invalid] https://launchpad.net/bugs/116757 [03:36] ahh, that's teh link :) [03:36] koolkat: On the MOTU/Contributing page there are links to some of the teams that you might want to join to start the process. [03:37] are there anyother projects that need more people? [03:37] nixternal: Is that really a bug? debuild/dpkg-buildpackage set executable anyway, even if it wasn't that way when they were called. [03:37] persia: I will check it out further after I finish moving them [03:37] not necessarily a bug maybe, but unclear to someone obviously [03:38] Makes sense. [03:38] koolkat: the actual MOTU can upload any package in Universe and Multiverse and requires a lot or trust and experience. There are only 80 MOTU [03:38] koolkat: There surely are other projects that also need more people, but we'll all encourage you to participate in universe work, as that's what we do :) [03:38] koolkat: contributing to Ubuntu though is fairly easy and defiantly encouraged [03:39] In motu what should I start out doing? [03:40] nixternal, persia: some people actual were getting errors I believe because of the rules thing [03:40] I dont know that much(or if any) programming.....i think thats bad [03:40] koolkat: well, do you have an interest in a particular area of software? [03:40] koolkat: many don't when they start [03:40] LaserJock: It prints a message complaining about it, but it fixes it when it complains. Maybe better to change the language of the warning then to make everyone try to remember chmod +x debian/rules [03:40] what do you mean? [03:41] LaserJock: What do you mean? [03:41] koolkat: I didn't know how to program when I started contributing [03:41] I still don't know much ;-) [03:41] koolkat: Assuming you run Ubuntu, which are your favorite pieces of software, and which are your most annoying bugs? Those are typically good places to start. [03:41] I like firefox [03:41] persia: how long has that been? seems like people complained about it erroring out [03:42] maybe it was just a complaint [03:42] I like gimp also... [03:42] * koolkat confused [03:42] hehe, pick the easy ones :-) [03:42] It reports an error, but it doesn't stop the process. Looking for the change now (as I don7t ever remember it being a new feature). [03:43] koolkat: for Firefox Ubuntu has a whole Mozilla Team [03:43] Thats what i figured [03:43] they always like help :-) [03:44] Where do i go for that? [03:44] koolkat: For working with Firefox and related packages, you might want to check for things need doing on #ubuntu-mozillateam. For gimp, https://launchpad.net/ubuntu/+source/gimp/+bugs is a list of things to do. [03:45] Ill try to work with gimp [03:45] firefox probably has alot of people [03:45] koolkat: actually, basically *any* area of Ubuntu needs help [03:45] there's always things needing doing [03:45] even if it's testing and bug triage [03:46] koolkat: There's also a lot of firefox work: lots of packages need adjustment to work well with the newest firefox, and there are lots of other xulrunner applications they handle. On the other hand, gimp always appreciates love. [03:46] So I if contribute anywhere and I am deemed useful I will hopefully eventually become a MOTU? [03:46] koolkat: also note that Firefox and Gimp are in Main, not Universe [03:47] LaserJock: I believe the "must be executable" warning comes from pkg 0.93.9 (from 1994). [03:47] Oh.... [03:47] koolkat: that's fine of course [03:48] it's just not MOTUs specific responsibility [03:48] koolkat: Exactly. It was about two years for me, but some people become MOTU in as little as six months. It depends on how much time you have, and how much work you do. [03:48] persia: even if i contribute to firefox? [03:49] I have ALOT of time [03:49] heh [03:49] koolkat: Likely. If you have an interest in FireFox, you'll probably expand to helping work on all the different applications that work with firefox, and a number of them are in universe. [03:49] Is chatzilla in the universe? [03:50] koolkat: We call it "seamonkey-chatzilla", but yes. You can always get the answer to that question with `rmadison -u ubuntu $(package)` [03:51] I have to boot to my ubuntu partition.....so ill be back === asac__ is now known as asac [03:55] IM BACK....!! [03:56] So .......what do I do again....to get into the bugs stuff? [03:58] anyone? [03:59] whew, that was a lot of copying/pasting...there were a total of 10 [03:59] and LaserJock left [04:00] * koolkat lauges [04:00] koolkat: https://wiki.ubuntu.com/MOTU <- you will probably find a good deal of the answers you are looking for from that page and its subpages..there is a bugs page somewhere in there :) [04:01] bbiaf, gotta catch the news [04:02] an launch pad I joined the "Contributors of packages for ubuntu universe" thingy [04:05] koolkat: Welcome. I'd recommend also joining the bugsquad (see #ubuntu-bugs), and subscribing to the ubuntu-devel@, ubuntu-devel-announce@, and ubuntu-motu@ mailing lists. === cprov is now known as cprov-ZzZ [04:07] I joined.... :-) [04:08] So eventually.....if i contribute alot.....ubuntu will invite me to be a MOTU? [04:09] Excellent. Now you just need some bugs to hunt. https://bugs.launchpad.net/ubuntu/+bugs lists a for you to examine. [04:10] Yes. After a while of working on the packages, people will start telling you to apply. Once you have enough sponsors prepared, you can submit an application. For now, better to concentrate on the actual bugs. [04:11] talking about gimp.. [04:11] can someone from main take a look at bug #189758 [04:11] Launchpad bug 189758 in gimp "[hardy] Menu entry should be named "GIMP Image Editor" Instead of only the "GNU Image Manipulation Program"" [Wishlist,Confirmed] https://launchpad.net/bugs/189758 [04:13] persia: how do I know how to fix a bug? [04:17] koolkat: That's the fun part. Based on the bug, examine the application and the source code, and read various documentation to fix it. Once you've hunted a couple, you'll have some solutions you know, and can apply that to other packages. The first one can be a little tricky, but ember's example is good: demonstrating a fix for a bug. [04:17] ember: All the right people are subscribed & assigned. You just have to wait for a -desktop sponsor. [04:18] persia: what do I read? [04:19] koolkat: Depends on the bug. [04:19] Ok...for example on this link https://bugs.launchpad.net/ubuntu/+source/gimp/+bug/186345 what would i read to try to fix it? [04:19] Launchpad bug 186345 in gimp "histogram disappears in gimp's curves tool" [Low,New] [04:20] ember: Actually, looking at that bug, the updated .desktop file isn't valid. Please patch it harder so that desktop-file-validate doesn't complain. [04:20] koolkat: Do you understand the problem, and why the graph doesn't appear? [04:21] uh....let me think......no [04:22] my bad persia i forgot to follow fd.o [04:23] ember: Also, the application's name is not GIMP, but The GIMP. [04:23] koolkat: in that case, I'd start by reading about GNOME theme definitions, and looking at the gimp code (especially the file mentioned) to understand how the graph could disappear. After you have an understanding, you will likely have developed some pointers to other documentation suggesting possible fixes. Once you have a couple candidates, you can check with upstream to see which would be the least intrusive, and submit that. [04:25] Fujitsu looking at the old patches the change is from The Gimp to GIMP image editor. [04:26] koolkat: you can get the gimp source with "apt-get source gimp". Then you could try to find the place where the theme colors get used. Then add a check there if they are the same and use others instead. [04:26] ember: Well, that's probably wrong. [04:27] I'd say `The GIMP Image Editor' [04:27] I think that i shouldnt of joined.....i know some c++ for Win 32 API but this stuff is confusung [04:28] The GNU Image Manipulation Program Image Editor seems just odd :) [04:28] Fujitsu well that's "THE" is odd on desktop files and stuff [04:28] persia: It does, true. [04:28] you don't see "The Text Editor" [04:28] and etc [04:28] ember: Most applications don't have `The' at the start of their names. [04:29] The GIMP does. [04:29] koolkat: then just look at another bug, something easier. [04:29] Ugh :-| [04:29] koolkat: There are lots of easier bugs. Take a look at https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize or https://bugs.launchpad.net/ubuntu/+bugs?field.tag=packaging or https://bugs.launchpad.net/ubuntu/+bugs?field.tag=desktop-file [04:30] ill try [04:30] Fujitsu where? [04:31] Hmm, I know it used to be the policy that it must be prefixed with `The', but their website seems to indicate otherwise now. [04:31] * persia thinks they gave up correcting people [04:49] where patches are submited? launchpad? === jdong is now known as PmDematagoda === PmDematagoda is now known as jdong [05:28] danielm: Yes [05:59] persia: regarding bug #191662 what fix is committed ? [05:59] Launchpad bug 191662 in ubuntume-gdm-themes "New package for ubuntume-gdm-themes" [Wishlist,Fix committed] https://launchpad.net/bugs/191662 [06:00] AnAnt: It means it got uploaded. The next step is "Fix Released", which means it is closed. === asac_ is now known as asac [06:00] persia: uploaded where ? to the queue ? [06:01] persia: btw, do you know why new upstream versions of gpm aren't packaged (not even in Debian) ? [06:01] AnAnt: To Soyuz. Once uploaded, it gets put in one of the queues by the upload processor (usually takes a few minutes), and then, depending on the queue, it may be a manual or automatic process to get into the repositories. [06:02] And, no, I don't know anything about gpm packaging [06:59] Good morning [07:30] How do I exclude a single library from being added to dependencies by dh_shlibdeps? [07:30] (specifically, this is to be able to explicitly depend on libxine1-x | libxine1) [07:38] LucidFox: For that special case, duplicated dependency on libxine1 is acceptable. [07:39] Hmm, but libxine1 pulls all the unneeded stuff, including libxine1-x [07:40] Or will it be changed after the migration is complete? [07:42] It oughtn't. [07:42] Ah. Right. I requires libxine1-x, but not xineui. Hmmm.. [07:44] Aha. libxine1-x depends on libxine1-bin. libxine1 is the thing that shouldn't be required anymore. [07:47] Indeed. I looked at what you did for codeine, but it depends on both libxine1-x and libxine1. [07:48] as does klear [07:53] Maybe once the transition is complete, the libxine-dev shlibs file can be changed. [09:57] libxine1-x dependency will be dropped after lenny is released [09:58] I'd like to keep it at least for hardy for dapper->hardy upgrades. [09:59] siretart: So hardy release will be mid-way through the transition? If we upload a few things, can we push it all the way for Ubuntu, and catch up later? [10:05] persia: which transition are you talking about? [10:06] libxine1 -> libxine1-bin [10:06] * siretart confused [10:07] but I just woke up, so... [10:10] siretart: LucidFox was looking at the leftovers of bug #159338, and noticed that it generated a double-dependency. Maybe that is right, but if there is anything we can do to make hardy clean, I'd like to do that, just so we don't have too many leftovers for the next LTS. You certainly know the code best thought. [10:10] Launchpad bug 159338 in oxine "Re: Heads-up: small xine-lib transition in hardy" [Undecided,In progress] https://launchpad.net/bugs/159338 [10:10] s/thought/though/ [10:12] persia: LucidFox: the duble dependency is absolutely correct, no problem here [10:12] james_w: yes, you can file a sync request [10:12] however, the packages need to manually depend on either libxine1-console or libxine1-x, whatever they actually need [10:13] perhaps -ffmpeg, if they need to play mp3 files [10:13] siretart> but if a package depends on both libxine1 and libxine1-x, then libxine1 pulls libxine1-x AND libxine1-console and a ton of other stuff [10:13] which is, from what I can discern, is precisely what everyone was trying to avoid [10:13] siretart: The thing being that libxine1 depends on libxine1-x and libxine1-console, so these parallel dependencies aren't actually used. [10:19] geser: thanks for the ack. [10:24] hello [11:21] someone here to that one ? http://revu.tauware.de/details.py?package=kdesudo-kde4 [11:22] very important on the kubuntu/kde4 side ! [11:23] Tonio_: Have you filed a freeze exception? [11:28] persia: nope, I'm waiting for the packaging to be accepted before filing this ;) [11:39] I'm rebuilding grisbi for libofx3 -> libofx4 transition. Current version is 0.5.9-0ubuntu1, but Maintainer has not been set to MOTU. Should I set it now? [11:41] * stdin sees "Maintainer: Ubuntu MOTU Developers " in grisbi 0.5.9-0ubuntu1 [11:41] stdin: Where did you see that? [11:42] warp10: from 'apt-cache show grisbi' [11:43] stdin: mmm... weird. I downloaded the source, and debian/control has a field Maintainer: Benjamin Drieu [11:44] heya norsetto :) [11:45] hiya all [11:45] * norsetto bows to the master of security [11:45] warp10: hmm, you're right [11:45] ciao norsetto! good to see you around [11:45] stdin: warp10 is always right [11:46] warp10: wouldn't do any harm to set it correctly now anyway [11:46] norsetto: heh :) [11:46] stdin: indeed. Anyway, I'm wondering how this can happen [11:47] stdin: warp10: The binary package carries the restrictions, as it gets set by the pkgbinarymangler script on the buildds. The source package needs to be updated. [11:47] I think one of the many scripts the buildd runs can check if the maintainer has an ubuntu.com address [11:47] ah, so I was mostly right in my assumption there :) [11:48] stdin: Completely right, just missing the package name :) [11:48] persia, stdin: Ok, I'll update the debian/control therefore [11:49] warp10: There are about 100 other packages that need that sort of attention as well. Patches appreciated. [11:49] Tonio_: Examining the package now, but you'd do best to get your FFe approved as soon as possible. Once approved, the upload can always happen a bit later. [11:50] persia: sure, but I plan to release a tarball in between as we are also maintaing the code [11:51] persia: reviewing is another way to get something clean on kde-apps :) [11:51] Tonio_: Then my current review is fairly pointless :) [11:52] persia: are you speaking about packages needing a transition or about the maintainer issue? [11:52] warp10: Maintainers [11:52] persia: any tool to find them all? [11:54] warp10: wget -O - http://archive.ubuntu.com/ubuntu/dists/hardy/universe/source/Sources.gz| gunzip | grep-dctrl -sPackage,Maintainer -FVersion ubuntu | grep-dctrl -sPackage -FMaintainer -v -n ubuntu | sort -u [11:54] 183 pending today [11:56] persia: Good. I'll try to shorten the list. [11:57] warp10: Thank you. For every package in that state, we're not complying with our agreement with Debian about variation. [11:58] Note that most of them haven't been touched in a while, and would probably benefit from other things, like menu file transition, .desktop cleanup, etc. [12:01] * norsetto -> lunch [12:01] Tonio_: Your package doesn't build in hardy. [12:01] persia: Indeed! I'll try to find out what every package need and fix accordingly [12:02] persia: hu ?????? [12:02] persia: lemme check..... I was asked to update the cdbs content, maybe that causes the issue [12:02] That would be it. Fails to find /usr/share/cdbs/1/rules/patchsys-quilt.mk, which points at a missing build-dependency. [12:03] ah...... [12:03] so stupid....... I don't use patches so removed quilt from builddeps [12:03] that's a cdbs files issue [12:03] Tonio_: Testing is key :) [12:04] Tonio_: blame debian-qt-kde [12:04] jpatrick: I do, I HATE quilt ! [12:04] * jpatrick hugs Tonio_ [12:05] Shouldn't whatever is including that depend on quilt so that the packages don't need to do so individually? [12:05] jpatrick: what's better ? changing cdbs files or adding a stupid builddep to override ? [12:05] jpatrick: I think the builddep is better, as I won't have to consider changing cdbs files everytime [12:05] Tonio_: I just suffer and add quilt to build dep [12:05] persia: it'll be fixed on revu in a few minutes [12:06] persia: some of the debian-qt-kde guys have a thing for quilt [12:06] jpatrick: No issue with that, but isn't there some package that provides the CDBS snippets? That package ought depend on quilt. [12:08] persia: personally I have no idea why quilt is needed [12:09] Because the recommended CDBS bits include the quilt.mk which means it FTBFS without quilt even when quilt isn't being used. [12:10] persia: you can review again, should be okay this time [12:10] jpatrick: because quilt is horribly powerfull and complex [12:11] jpatrick: exactly what debian likes :) [12:11] Tonio_: I'm going to bed, and I don't see the point of a review when there will be a new upstream before it gets accepted and there's no FFe. [12:11] Tonio_: well, I've always perfered simple-patchsys [12:11] jpatrick: of course now quilt is there, there is absolutly no way to use simple-patchsys, it won't be able to do the job.... [12:11] persia: I'm upstream maintainer [12:12] persia: so there won't be another upstream release ;) [12:18] What advantages does quilt have over dpatch, apart from not using non-standard headers? [12:19] It's a little easier to avoid patch conflicts with quilt, because it's a little smarter about these things. [12:24] I have a package (gcal) that built fine a week ago, but now fails, see http://pastebin.ubuntu.com/4681/. CFLAGS from debian/rules are now passed to configure and make it fail, which didn't happen with the old dpkg. [12:24] Downgrading dpkg to the old version solves the problem. With the new dpkg I have to remove the single quotes from CFLAGS='-O2 -Wall $$(INC) -pg' [12:24] Is that a bug in dpkg or is it a bug in gcal that now became visible? [12:25] Hey [12:28] albert23: It's a bug in gcal unless you can find more than 20 packages that now FTBFS, in which case it becomes a bug in dpkg for now, and a bug in gcal for hardy+1. [12:30] persia: ok, then I will make an update for gcal [12:47] Hi. Could someone clarify a couple of points about imports from Debian for me please? [12:47] firstly are new packages in Debian auto-synced? Or do they require a sync request the first time? [12:48] james_w: they are auto-synced before DebianImportFreeze starts [12:49] RainCT: thanks. You've answered my second question as well. [12:49] james_w: and after DebianImportFreeze they require a manual request (and right now for Hardy they would also require a Freeze Exception as there is Feature Freeze) [12:49] heh [12:51] Would it be correct to say that a synced package has no changes made to it in Ubuntu. [12:51] yes [12:51] I guess things like pkg-striptranslations kind of break this don't they? [12:51] and is Maintainer automatically changed for syncs? [12:52] not sure I'm involved heavily enough to answer any more. [12:54] the answer to the second part is yes according to https://wiki.ubuntu.com/DebianMaintainerField [12:54] pkg-striptranslations were only for main last time I checked, which was ages ago. [12:57] I've gone with "the source package is just rebuilt in the latest development version of Ubuntu. Any changes that are made are purely automated." [12:57] There have been slips in the past. Check your buildlog to be sure. [12:58] I'm only talking in general, so I'll ignore any mistakes. [13:06] james_w: during the sync the source package is taken as is from Debian (and stays unmodified) [13:07] the maintainer change, pkgstripstranslation and pkg-create-dbgsym only happen during build of the binary debs (and also only affect them). [13:08] geser: thanks. [13:13] * norsetto <- lunch [13:18] warp10, thanks for opting to take care of the libofx transition! [13:22] asac: ping [13:40] * RainCT is looking for something to do [13:43] * maikeru is looking for lunch [13:44] RainCT: fix bug #1 [13:44] Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,Confirmed] https://launchpad.net/bugs/1 [13:44] :D [13:54] LucidFox: my pleasure! grisbi builds fine, now I'm checking the others === Tonio__ is now known as Tonio_ [14:14] LucidFox: kmymoney2 has been rebuilt two days ago, so it got libofx4 already. (http://people.ubuntu.com/~ubuntu-archive/NBS/libofx3) [14:25] hi all, I want to file a feature-freeze exception, I have a question about a command. [14:26] This is the command given in the wiki of feature freeze exception process [14:26] diff -ruN -{old-version,new-version} | diffstat > diffstat.txt [14:26] warp10: if u can help me it would be nice. [14:26] shirish: what question do you have? [14:27] now I have 2 upstream tarballs which are both .tar.gz , now do I need to gunzip both of them to different directories or how? [14:28] shirish: I'm sorry, I'm going away for a while. I'm sure someone else can help you [14:28] shirish: usually they should unpack to different dir names but you can check before doing it [14:28] geser: right, so the first thing is to unpack them to different directories right? [14:29] geser: the tarballs are swfdec-0.5.5.tar.gz & swfdec-0.4.5.tar.gz [14:29] shirish: yes, and usually the tar.gz already create a subdir [14:40] Does PPA not support multi-package packages? (ie: one source package produces several different binary packages). [14:41] slicer: yes it does [14:42] jpatrick: Odd. I can see both packages being built in the buildlog, but only the first is put in my archive. [14:42] slicer: prehaps it's lagging [14:43] jpatrick: Indeed it is. It just appeared now :) [14:50] geser: are u there m8? [14:50] yes [14:50] geser: I have untarred both the upstream versions, now how I do run the command [14:51] geser: both are in different directories [14:51] diff -ruN -{old-version,new-version} | diffstat > diffstat.txt [14:51] shirish: diff -Nru swfdec-0.4.5 swfdec-0.5.5 | diffstat [14:51] I assume the dirs are named swfdec-0.4.5 and swfdec-0.5.5 [14:51] geser: yes, right. [14:52] what is Nru for? [14:52] geser: or it should be ruN [14:52] man diff: -N: also diff new files, -r: recursive, -u: unified diff [14:52] the order of the options doesn't matter [14:53] run is easier to remember :-) [14:53] alias diff='diff -ruN' is even easier :) [14:54] shirish: and -{old-version,new-version} expands to -old-version -new-version [14:55] right [15:10] hi [15:10] hi === RainCT is now known as UbuCat_ === UbuCat_ is now known as RainCT === RainCT is now known as UbuCat_ === UbuCat_ is now known as UbuCa1 [15:23] Could a MOTU have a look at http://revu.tauware.de/details.py?package=torrentinfo ? === UbuCa1 is now known as UbuCat === UbuCat is now known as RainCT === RainCT is now known as UbuCat === UbuCat is now known as UbuCat1 === UbuCat1 is now known as UbuCat_ [15:25] !nickspam > UbuCat_ [15:26] oops :P === UbuCat_ is now known as RainCT [15:32] * RainCT > comments(bobbo) [15:34] bobbo: are you upstream? [15:34] RainCT: no [15:34] ah I see [15:35] It was recommended to me that I add a get-orig-source target to a package. Can anyone in here point me to an example or documenation for that target? [15:35] RainCT: its my first proper packaging attempt so ive probably done some bits wrong [15:36] bobbo: was it intended to be a native package? [15:36] s/was/is [15:36]