[00:15] albert23: FYI, I have just requested the sync for enthought-traits. Please, go ahead with enthought-traits-ui at your will. [00:16] warp10: ok, good to know. I will look at e-t-u tomorrow. [00:16] albert23: great, thank you. :) [02:03] freeflying: Welcome back. [02:21] ScottK: thanks :) === rockstar_ is now known as rockstar [03:35] i'm having some problems packaging a python package that has a compiled module...is this the right place to ask for help? [03:38] Yes [03:39] But not from me, I'm heading out for a while. [03:39] ok, thanks [03:41] the compiled module is built with a simple makefile, which seems to build, but dpkg-buildpackage errors out: "unrepresentable changes to source" [03:42] grantgm: Can you pastebin your debian/rules and your buildlog? [03:44] debian/rules: http://pastebin.ca/1045660 [03:45] output: http://pastebin.ca/1045662 [03:46] debian/control: http://pastebin.ca/1045664 [03:47] persia: would anything else be helpful? [03:47] No. That's sufficient. [03:48] ok. thanks a lot having a look [03:48] *for having [03:48] To me, it appears the issue is that you have build it once in the tree, and your clean isn't deleting the generated files. [03:55] you're right: it appears that the makefile isn't cleaning the files built in the test directory [04:38] Say, I need to test certain packages from -proposed, but don't want to upgrade everything. I know I could enable it, upgrade the one package, then disable the repo again, but could someone tell me how to properly say "only upgrade packages foo, bar from -proposed, all else use these other repos" ? [04:38] apt pinning [04:39] 'man apt_preferences' says it better than I can sum up [04:40] http://wiki.debian.org/AptPinning is also a good reference [04:55] Sigh. Why do applications like Banshee feel they need to reimplement GTK? [04:56] are you referring to the custom widgets & the human theme? [04:56] Yes. [04:56] wgrant: Remember. Newer is better. [04:56] They seem to reimplement GTK's ListView for the sole purpose of combining selection bubbles. [04:57] And it's about the slowest UI I've ever seen. [04:57] it's a microvell conspiracy [04:58] Ah, and there's some strange effect on the play queue when you add something to it. [04:58] I'm sure GTK could be altered to do that without rewriting the whole thing in ridiculously slow Cairo. [05:10] wgrant: You obviously need a better video driver :) [05:10] * RAOF also agrees with gtk reimplemenation bitching. [05:11] RAOF: It's an i915. It runs Compiz fine. [05:12] But it can't render a *media player*'s interface quickly. [05:12] That's because intel doesn't have a nice XRender backend (yet). [05:13] No one accelerates EXA well. Except nouveau. [05:13] RAOF: Does nouveau display a normal desktop well yet? [05:13] persia: Yes. It has done for _ages_. [05:13] Yes. [05:13] I use it at work. [05:14] It's rather nice, as long as you don't want Compiz. [05:14] Then why isn't it in the repos yet? [05:14] The multimonitor is infinitely better than the blob. [05:14] Because I'd need to break libdrm to do it. [05:14] wgrant: Oh, _hell yes_. [05:14] * persia can't use compiz anyway, because compiz + cairo + nVidia binary blob + old graphics card = extra heat [05:14] RAOF: How's 3D coming along? [05:15] RAOF: What's the bad part about breaking libdrm? [05:15] persia: It's at the bottom of the X stack. [05:15] RAOF: NVIDIA does it, no? [05:15] the nvidia blob doesn't use libdrm [05:15] wgrant: Break libdrm? No. They just ignore it. [05:15] Right. [05:15] Like they ignore _every other_ piece of X infrastructure. [05:15] :( [05:16] Elisa no longer segfaults. It now doesn't display any video, but it does'nt segfault. [05:17] * ajmitch wonders when we'll see kernel modesetting in mainline [05:17] Fedora's testing it, right? [05:18] From what I can find, Fedora seems to so some rough equivalent of dpkg-divert for the alternate libdrm [05:18] s/so/do/ [05:18] nouveau is sitting in Debian experimental NEW, too. [05:19] If libdrm gets a release that supports it before FF, I'll totally be syncing stuff accross. [05:20] RAOF: Is my understanding correct that nouveau_libdrm can support most things, as long as the user is using nouveau, and only breaks things for other people? [05:20] persia: Actually, it shouldn't break anything. But it's a git snapshot of a lib at the base of the X stack, so I'm not interested in pushing it to Intrepid. [05:21] RAOF: So it's just new, not Nouveau-specific? [05:21] RAOF: Hrm. OK. [05:21] wgrant: Correct. [05:21] Do the PPA packages work cleanly? [05:21] does it assume different kernel interfaces as well? [05:21] persia: Yup. [05:22] ajmitch: No. It provides the kernel interfaces. [05:22] I can't recall if you can mix & match old drm modules & a new libdrm [05:22] * persia encourages RAOF's intrepidation, especially the bit about fearless audacity. Finding out if the latest git snapshot works is what Alpha releases were designed to do :) [05:22] I don't think you can. Or, rather, you can't build nouveau against an old libdrm. [05:23] RAOF: right, that was more my point with it, seeing what else would have to be updated to bleeding edge snapshots :) [05:24] ajmitch: Just libdrm. [05:26] how's the work with gallium progressing? [05:26] If people _really_ want, I'll ask for a sync/merge of experimental's libdrm, ask to add the kernel module to linux-ubuntu-modules, and sync xserver-xorg-video-nouvea. [05:26] * ajmitch may hold off from upgrading for awhile [05:27] I like having a working system [05:27] Gallium exists. It doesn't work nearly well enough for anyone who cares about 3d. [05:27] * wgrant might upgrade to Intrepid after the calculus exam tomorrow. [05:28] Although there's now a XvMC state tracker in git. That'll be cool. [05:28] What does that do? [05:28] RAOF: How likely is an upstream release in the next couple months? If we're likely to switch for intrepid anyway, maybe better to start wider testing sooner (although this ought be discussed in #ubuntu-devel, as libdrm is fairly core) [05:30] persia: I really have no idea. Upstream may wait until the great gpu-memory-manager wars are resolved before releaseing, in which case that's an indeterminate period. [05:30] RAOF: Ah. Hrm. [05:31] Who are the contenders in that battle? [05:33] TTM and GEM. [05:34] Never heard of the latter. [05:34] Keith P did GEM for the intel driver. [05:35] Why must one conquer the other? [05:35] Because people don't want to support two gpu memory manager interfaces in the kernel indefinately. [05:36] Ah. [05:36] * ajmitch thought that TTM originated with intel [05:37] It did. A different group, I think. [05:37] Ah, that makes it fun :) [05:38] * persia despairs over the inconvenience of attempting to handshake with one left hand and one right hand [05:38] For bonus points, neither has really been used for !intel hardware yet. [05:38] persia: Why would one attempt that? [05:39] wgrant: When the left hand and the right hand have been properly introduced, it is easier for them to thereafter collaborate... [05:39] RAOF: right, and I understand that memory management can be done quite differentlly on other cards [05:39] ajmitch: Very much so. I think that new ATI and nVidia have fully virtualised gpu-memory, for example. [06:59] good morning [07:00] hey anyone in here can help me? [07:01] TiMiDo: Depends on the task with which you need help [07:02] persia: im making a packaged but im getting this error [07:02] Source archive you specified ( ../mdk-1.2.4 ) was not found! [07:02] i'm in the dir.. and i'm doing it.. but i'm getting that error [07:02] TiMiDo: You'll need to supply a little more context. Would you pastebin the relevant log? [07:02] okey [07:03] http://pastebin.ca/1045760 [07:03] there it is persia [07:03] doko: ping [07:04] TiMiDo: And does ../mdk-1.2.4 exist? [07:04] yes it does [07:04] i'm in that dir [07:05] but im getting that error any ideas persia ? [07:05] Right. I dislike dh_make enough to have never used it. Anyone else familiar? [07:07] TiMiDo: use dh_make -e farias.aaron@gmail.com with no ../mdk-1.2.4 [07:07] if you are in the dir of sources ../mdk-1.2.4 is not needed [07:07] Could not find mdk_1.2.4.orig.tar.gz [07:07] Either specify an alternate file to use with -f, [07:07] or add --createorig to create one. [07:08] TiMiDo: il .. of sources paste the orig of the sources, it is needed to use dh_make [07:08] ? [07:08] s/il/in/ [07:09] sorry i'm confused [07:09] TiMiDo: compress orginal sources to tar.gz and rename it to mdk_1.2.4.orig.tar.gz [07:10] move this file in the .. of the sources, your ~/debian/ [07:10] and then use dh_make [07:10] okey dne [07:11] persia: why you dislike dh_make? [07:11] Skipping creating ../mdk_1.2.4.orig.tar.gz because it already exists [07:11] Done. Please edit the files in the debian/ subdirectory now. mdk [07:11] uses a configure script, so you probably don't have to edit the Makefil [07:12] TiMiDo: now edit the debian dir as you want to make a working package [07:12] devfil: can you help me a little I'm totally a newbie on this =) [07:13] devfil: Because I don't like some of the defaults, and I find it annoying to delete all the examples. Generally, I find I want to create debian/rules and debian/copyright from scratch. debian/changelog is dch --create. debian/control is the only benefit I see to dh_make, and it's not really that hard to type. [07:14] TiMiDo: you should start reading this http://www.debian.org/doc/maint-guide/ [07:14] devfil: i've read it =) [07:14] i just need some help [07:15] TiMiDo: what exactly? [07:15] on what dirs do i ut? [07:15] *put [07:16] TiMiDo: in dir you should put dirs that will be created in the package [07:17] okey but what locations do i put it? [07:17] there's two .... dirs names on it [07:17] You almost certainly don't need anything in debian/dirs [07:18] okey so after that what do i do? [07:20] TiMiDo: Come back in here. [07:21] okey [07:21] What is it that you actually want to do? [07:21] RAOF: create a packaged =) for my first time [07:21] You're trying to package mdk 1.2.4, I guess? [07:21] yes RAOF [07:22] And you've read https://wiki.ubuntu.com/PackagingGuide ? [07:23] The files in debain/ are basically divided into metadata and the debian/rules file which is a makefile that actually does the building. [07:23] yeah i did [07:24] RAOF: i'm lost in the debian/rules part =) [07:24] Right. So, debian/rules is a makefile with a couple of mandatory targets and a couple of optional targets. [07:24] How familiar are you with makefiles? [07:25] Well.. i'm new on that also =) [07:25] never had make a Makefile myself =) [07:26] siretart: congratulations [07:27] <\sh> Without knowing how to write makefiles, you life is miserable and you can't enjoy your evening times... [07:27] <\sh> Makefiles make the world go round...do a makefile a day ;) [07:27] Right. You might want to read a make manual, but it's not totally necessary to do the basics. The unindented lines with colons, like "build: " are targets. That's what gets called when you do "debian/rules build" [07:27] The things after the target name are dependencies, so "build: configure" will run the configure: target before running build: [07:28] The tab-indented lines are then what gets actually _run_. Each line gets passed to a (different) shell, and executed. [07:29] damn I'm so freaking lost =*( [07:30] Right. [07:30] So, probably playing around with some makefiles is a good idea. [07:31] persia: do you know what an universe contributor do? [07:31] RAOF: is there any tutorials on makefiles? [07:31] devfil: How do you mean? [07:32] TiMiDo: Google gives me http://www.gnu.org/software/make/manual/make.html , which is a not unreasonable introduction. [07:32] In general, the universe contributors (including MOTU) do the majority of the work in maintaining the packages in universe. [07:32] hmm okey? [07:33] TiMiDo: It's also somewhat tailored towards building C programs, but that's GNU for you :) [07:33] oh ic [07:33] persia: not MOTU, only universe contributors. What are the differences between a normal user that help (as me) and an universe contributor? [07:33] TiMiDo: Just section 2 should give a reasonable overview. [07:33] RAOF: actually, thats posix [07:33] RAOF: but YMMV [07:34] devfil: Mostly just a history of contributions. Being an official Universe Contributor includes Ubuntu Membership, so one can use an @ubuntu.com email address and be on planet, etc. [07:34] lifeless: I was thinking about autotools particularly in this case. Which is great if you're using something sufficiently C like. [07:35] persia: so a user choices to be universe contributor or ubuntu member [07:36] RAOF: ah fair enough. [07:38] devfil: It's not a choice, really. Being a universe contributor is one of the ways that one can become an Ubuntu Member. [07:39] persia: ok, so become universe contributor is not needed to become in future MOTU [07:40] devfil: They are different things. [07:41] Universe Contributors are recognised for their contributions within the Ubuntu development community, and gain membership through this recognition. MOTU are responsible for overseeing all contributors (recognised or not) to the Ubuntu universe component, and have geen granted the right to upload without review. [07:41] Every MOTU is a Universe Contributor, but not every Universe Contributor is MOTU. [07:42] devfil: universe contributor is just 'those who contribute' [07:42] ok, thanks for the reply :) [07:42] devfil: 'motu' is those responsible for reviewing contributions and ensuring quality etc [07:43] lifeless: Well, a little more than that; there's an application process for Ubuntu Contributing Developers to get recognised and gain the benefits of membership now. [07:43] persia: still [07:43] persia: if you strip away the beaucracy ... [07:43] lifeless: Well, yes :) [07:43] lifeless: yes, I know. I did understand reading the wiki that become universe contributor is a step needed to become MOTU, but I was wrong :) [07:44] d [07:45] devfil: It's very definitely not a step required on the way to MOTU. Many people qualify for Universe Contributor before they qualify for MOTU, but lots of people became MOTU directly. [07:46] I would say, its impossible to _qualify_ for MOTU without also _qualifying_ for UC [07:47] lifeless: That's certainly true. [07:48] devfil: so when you are ready to be a MOTU, apply for that [07:48] devfil: and if you aren't yet, you might be ready to be a UC [07:49] lifeless: I'm ubuntu member, so I think is not necessary for me to become UC [07:49] devfil: no, not at all [07:58] morning [07:58] hi emgent :) [07:58] devfil: :) === tb1 is now known as tbf [08:09] devfil: after i created it the rules what do i do now/ [08:10] TiMiDo: You've got some idea of what a makefile looks like now? Good. [08:10] TiMiDo: did you put build depends on debian/control? [08:10] devfil: nope [08:11] TiMiDo: in debian/control, in the build-depends field you must put the dependencies needed to build the source [08:11] Ti [08:12] devfil: yeah done [08:12] now what? [08:12] TiMiDo: in depends of the package you must put dependencies needed to run the package [08:12] depends field [08:12] devfil: Except, in most cases, these should be automatically generated. [08:13] RAOF: in most cases [08:14] TiMiDo: now you should try to build the package, to see if it works [08:14] TiMiDo: So, here's one of those places where you need to know something about the thing you're packaging :) [08:17] devfil: how do i build the package? [08:17] Running "debian/rules binary" should work, but most people will use dpkg-buildpackage or debuild. [08:18] dpkg-buildpackage: set CFLAGS to default value: -g -O2 [08:18] dpkg-buildpackage: set CPPFLAGS to default value: [08:18] dpkg-buildpackage: set LDFLAGS to default value: [08:18] dpkg-buildpackage: set FFLAGS to default value: -g -O2 [08:18] dpkg-buildpackage: set CXXFLAGS to default value: -g -O2 [08:18] tail: cannot open `debian/changelog' for reading: No such file or directory [08:18] dpkg-buildpackage: failure: tail of debian/changelog gave error exit status 1 [08:18] * persia strongly recommends running `debuild -S` before building any binaries, to avoid confusion. [08:18] oh ic =) [08:19] TiMiDo: you can use pbuilder, but I think is better if you use debuild binary, debuild binary shows you during build in the sources dir all the file generated ecc... [08:19] you can see if you did a good rules or not [08:20] i got an error [08:20] let http://pastebin.ca/1045802 [08:21] that's the error [08:21] TiMiDo: you should install build depends on your pc before use debuild binary [08:21] s/should/must/ [08:21] devfil: look read the error that what i've got [08:22] did i do something wrong [08:22] ? [08:22] TiMiDo: That error's OK; it's only about signing your packages. You can ignore it for now. [08:22] okey RAOF now the package is ready? [08:23] Now you have a source package. [08:23] Readiness is a different metric :) [08:23] oh okey cool =) [08:23] now what? do i do with it? [08:24] Well, build it, generally. Does it build? [08:24] debuild -us -uc will try to build it, without signing. [08:24] as root? [08:25] No. [08:26] http://pastebin.ca/1045805 [08:26] now i got thatt error =) [08:27] So, you need to install cdbs [08:27] "Unmet build dependencies: cdbs" is the important line. [08:28] how do i installed cdbs? [08:28] TiMiDo: try again to build [08:28] Same way you'd install any other package? [08:28] Generally, I'd 'sudo aptitude install cdbs', but synaptic, apt-get, packagekit... all these and more are your options ;) [08:29] TiMiDo: sudo apt-get install cdbs [08:29] okey [08:29] is building [08:31] nice done =) [08:31] and now how do i put it up? [08:32] Put it up where? [08:32] on launchpadn [08:32] You mean, in a PPA? [08:33] yeah [08:33] so people can download my package [08:33] Well, for that I'd suggest looking at the PPA-quickstart guide, linked to from your PPA page. [08:34] oh ic [08:35] RAOF: if i want to put it on ubuntu [08:35] ? [08:36] Then you want to upload the source package to revu. You'll want to make sure that running 'lintian -iI' on the .changes file doesn't list any problems. [08:37] You'll also want to check out https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#NewPackage [08:40] https://wiki.ubuntu.com/MOTU/Packages/REVU is the link to revu howto. === fabo_ is now known as fabo [09:41] persia: thanks. let's see how good things will work out with me === nijaba` is now known as nijaba [09:48] <\sh> go siretart go :) [09:48] I'm having problems building a package with pbuilder, is this the right place to ask for help? [09:49] mbudde: I thinnk so.. [09:49] fire away [09:49] siretart: congrats ! [09:50] ok, I'm trying to build enblend from hardy repos but pbuilder fails: http://paste2.org/p/38383 I have successfully build the hello package so i guess it has something to do with the dependencies? [10:05] !search * [10:05] Found: logs-#ubuntuforums, tvout, abs, hdbug, picard, gary, ubunto, officialdocs, winkey, overshare [10:09] hi folks [10:09] howdy ho === DktrKranz is now known as DktrKranz2 === broonie_ is now known as broonie [10:41] I solved my problem, "sudo pbuilder update --other-mirror ... --override-config" did the job === Czessi__ is now known as Czessi [12:40] <\sh> http://www.sourcecode.de/content/launchpad-desktop-integration [12:40] <\sh> get hot new stuff now :) [12:42] woow [12:42] nice :) [12:43] \sh: alpha is avaiable ? [12:43] <\sh> emgent: not now...I'll push the stuff on LP the next few days...when some functionality is there :) [12:44] cool :) [12:44] \sh: very nice [12:44] \sh: gnome version too (GTK and not QT) will be avaiable? :) [12:45] <\sh> emgent: the plan is to provide several frontends :) [12:46] <\sh> emgent: lp-desk -kde / lp-desk -gnome or something like this [12:46] cool, very good idea :) [12:46] <\sh> like ubiquity...one backend, several frontends [12:49] <\sh> emgent: right now, it was just a practive with new pyqt4/pykde4 love...:) [12:49] hehehe ok :) [12:49] <\sh> practice even :) [13:08] Does it seem priority inversion to anyone else that "He was also recommended by Launchpad developers" is a significant qualification for our LP liaison? [13:09] Usually customers are by definition credible with their service providers. [13:09] siretart: Congratulations. [13:46] <\sh> ScottK: *g* [13:57] Hey, simple bug fix for you guys, 238427 [13:57] Hey, simple bug fix for you guys, #238427 [13:57] Where is the Universe SRU verification process documented? [13:58] Bug #238427 [13:58] Launchpad bug 238427 in siproxd "cannot install siproxd on 8.04 due to missing dependancy libosip2-3" [Undecided,Confirmed] https://launchpad.net/bugs/238427 [13:58] <_< [14:01] ScottK: https://wiki.ubuntu.com/StableReleaseUpdates?action=show&redirect=SRU#head-4f8a5c972c2b7f429e32535b806e78d34275d84d or https://wiki.ubuntu.com/QATeam/PerformingSRUVerification [14:02] DktrKranz2: Those don't actually say HOW to do verification for Universe. [14:03] How many people need to test? [14:03] What's the aging requirement? [14:03] Etc. [14:03] Unless I miss it.... [14:03] ScottK: there's no difference, AFAIK. And aging requirement is just an archive admin task [14:03] aging period is described here: https://wiki.ubuntu.com/ArchiveAdministration#head-1f27dc12ab1558ec21b31ac44e4c86a87a4cd053 [14:04] It used to be that it took any 2 positive reports for Universe SRUs, but Main SRUs had to be verified from the SRU verification team. [14:06] DktrKranz2: Is there any point in community feedback with the current process? [14:06] DktrKranz2, ScottK: how about bug 220910... should I tag this as verification-done, as it was tested by the original reporter? [14:06] Launchpad bug 220910 in tk-brief "tk-brief has broken dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/220910 [14:06] sistpoty|work: Apparently we aren't on the right team for that. We can say it's OK to upload, but aren't allowed to have an opinion on if it works. [14:07] ScottK: it used to, but some times ago we merged two policy, leaving to sru verification to check for open sru candidates (bdmurray clarified everyone can join in, not only canonical employees) [14:07] I asked to join to look at uni/multiverse SRUs [14:07] DktrKranz2: Currently, as written, there is no requirement or even request for user testing of proposed packages. [14:08] Current process says, "he SRU verification team may also discover that your fix is good." [14:08] Dear DktrKranz2, please discover that the fix for Bug #226845 is good. [14:08] Launchpad bug 226845 in amavisd-new-milter "amavisd-new-milter: unmet dependencies" [Medium,Fix committed] https://launchpad.net/bugs/226845 [14:09] do you want to bring back "2 works for me" rule? [14:11] or do we want more sru-verification guys? [14:12] I think at the very least we ought to actually ask, in the process, for input from users of the packages. [14:13] I think 2 works for me is good for Universe as it's not reasonable to expect SRU verification team members to be intimately familiar with all the packages in Universe [14:13] I'd suggest 2 worksforme and motu-sru to do verification of Universe/Multiverse SRUs. [14:14] Well, sometimes archive-admins copy packages to -updates even if bugs lack sru-verification input if there are people who declare fix is good, so this could be a good point [14:14] So we aren't even following the process as written now. [14:14] exactly [14:14] I wouldn't make it too strict for small fixes, to be more aligned with main (e.g. for my main sru, I was the only person who tested the .deb from proposed, and pitti still marked it as verification-done :)) [14:15] * ScottK nods. [14:15] DktrKranz2: Following the current process, would you please mark Bug #226845 verified. I just tested it and it works. [14:15] Launchpad bug 226845 in amavisd-new-milter "amavisd-new-milter: unmet dependencies" [Medium,Fix committed] https://launchpad.net/bugs/226845 [14:16] I also marked in the bug. [14:16] ScottK: I can't find it in the mirrors, I'll wget it from LP, just a sec... [14:17] Odd. It was on mine. [14:17] Ah well. [14:19] mh, italy is lazy sometimes :) [14:20] ive fixed this bitebug https://bugs.launchpad.net/ubuntu/+source/kphone/+bug/238192 [14:20] Launchpad bug 238192 in kphone "no man page for 'kphone'" [Undecided,Confirmed] [14:20] have something to do now? [14:21] ScottK: during motu-sru meeting, we should talk about SRU process as well, maybe we can have some exceptions for Universe (e.g. bugfix releases) [14:22] DktrKranz2: OK. [14:22] We could make the formal process change as simple as "For Universe/Multiverse packages, motu-sru is the SRU verification team." [14:23] or restore community feedbacks as verification [14:27] ScottK: I'll need to redo my VM, It will take me a bit, I'll check in a hour. [14:27] DktrKranz2: No rush. [14:28] DktrKranz2: I think using community feedback would be a detail of how motu-sru would do it. I don't think we'd need to disturb the formal process definition for that. [14:29] so, if motu-sru is fine, we tag bug as verification-done [14:31] Yes. [14:31] Sounds good [14:32] ScottK: have you time to review a merge for main? [14:35] DktrKranz2: Not just now. Give me the bug and I'll get to it later today if I can. [14:37] ScottK: bug 226783. [14:37] DktrKranz2: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/226783/+text) === Mez is now known as Mez|DPC [14:37] d'oh! [14:37] DktrKranz2: Not scons. I don't think I want ot touch that. [14:38] ot/to [14:38] ok, thanks anyway [14:49] ScottK: FTY, amavisd-new-milter verification done :) [14:50] DktrKranz2: Thanks. [14:50] *FYI [14:50] someone can tellme what i need to do with this? https://bugs.launchpad.net/ubuntu/+source/kphone/+bug/238192 [14:50] Launchpad bug 238192 in kphone "no man page for 'kphone'" [Undecided,Fix released] [14:52] leleobhz: subscribe ubuntu-universe-sponsors, and please set the state back to confirmed (or triaged), as fix released means that a fixed package is available in the archive. [14:52] \sh: huats_: ScottK: thanks. Still thinking about my opening email. [14:53] sistpoty|work: oh, ok. [14:53] sistpoty|work: and send the bug link into maillist? [14:53] leleobhz: no, subscribing ubuntu-universe-sponsors is enough so that it appears in the teams worklist [14:54] sistpoty|work: so, only revert to confirmed and wait? [14:55] leleobhz: yes [14:56] leleobhz: and subscribe ubuntu-universe-sponsors of course (left hand side, "subscribe someone else" link on the bug page) [14:57] sistpoty|work: done ;] [14:58] sistpoty|work: thanks! [14:58] np ;) [14:59] sistpoty|work: ive corrected some problems in uniconvertor, its now wait-and-see? [15:00] leleobhz: yes === x-spec-t is now known as Spec [15:11] persia: btw.: where did you find the sistpoty@stud.uni-erlangen.de address? did I miss to update s.th. (don't have that address any longer, as I'm no student any longer *g*) [15:28] When two packages conflict with each other, should the "Conflicts:" line be added to just one of the packages ? Or both ? [15:29] It depends. [15:31] ScottK: in which cases would you need to have Conflicts: in both control files ? [15:32] ScottK: or is it just good practice ? [15:32] It depends. [15:32] One common use of conflicts is to force removal of an obsolete package when a new package replaces it. [15:32] In that case adding it to the old package is not needed. [15:33] ScottK: in this case it's two library-dev packages providing the same .a file [15:33] Koon: What exact problem are you trying to solve? [15:33] Ah [15:33] Does the file provide the same functionality? [15:34] ScottK: I would say, not exactly. [15:35] cgilib and libcgi-dev both provide /usr/lib/libcgi.a [15:35] this was fixed in Debian by adding a Conflicts: line to cgilib [15:35] and fixed in Ubuntu by adding a Conflicts: line to libcgi [15:35] sistpoty|work: ^^^ What do you think? [15:36] I take it they are separate source packages? [15:36] siretart, you there? [15:36] Yes. When I merged libcgi, I carried on the delta since it wasn't fixed in the deb one. But now I am not sure it's really needed [15:36] ScottK, Koon: if there is a duplicate file in both, add a conflicts to both source packages [15:36] erm... binary packages that conflict [15:37] theseinfeld: no, I'm gone. please leave a message after the beep. *BEEP* [15:37]