[00:18] cody-somerville: Tell the CC, not me :) === kamalmostafa is now known as kamalmostafa-out [00:58] hey guys how to make autotool update patches during build with debhelper? [00:58] i meant, how to make autotool files get update during build with dh7? [00:59] How much of an update do you want? [01:01] persia, let me explain, lighttpd used to be package with cdbs and in UBuntu the lighttpd-dev package was itnroduced and they were using DEB_AUTO_UPDATE_* variables to ensure autotool files get updated with the ubuntu patches. however, now lgihttpd has been changed to dh7. How would I do the same to ensure that autotool update its file with the patches? [01:04] Do you understand what DEB_AUTO_UPDATE_* did? [01:05] persia, just ensure automake's version to use? [01:05] heh. No. [01:06] So, which of DEB_AUTO_UPDATE_* were actually used? [01:06] persia, http://paste.ubuntu.com/390707/ [01:06] Generally the definitions of those can be derived from /usr/share/cdbs/1/class/autotools-files.mk [01:08] (although autotools.mk and autotools-vars.mk have some) [01:09] Once you know what you actually wanted to do, you'd probably want to add an override_dh_auto_configure: rule. [01:09] ok [01:11] Looks to me like it's intending to go all the way from libtoolize onwards. [01:11] Note that you can call dh_auto_configure in your override_dh_auto_configure: rule to take care of the rest once you're finished with the autotools stuff. [01:13] awesome. Thanks a lot === kamalmostafa-out is now known as kamalmostafa [01:20] persia, where can I find good documentation to learn everything about this? [01:21] hi all. i am trying to create a package for my ppa. everything seems to compile fine. howerver, the resulting deb files does not contain any binaries, although i see that those are compiled [01:25] RoAkSoAx: For CDBS, search for "CDBS Documentation", but mostly read the source. For dh(1), man dh and look at the sequences in the dh source. [01:25] For autotools, get the goat book [01:26] persia, RoAkSoAx: Also, running dh --no-act $TARGET in a packaging directory will list the sequence, including any overrides you've specified. [01:26] rdz: One of four things is true 1) your debian/rules install rule is wonky, 2) You didn't set some variable you need to feed the upstream build system to define the install target, 3) the upstream build system is wonky, or 4) you need to add more hints to dh_install [01:27] RAOF: Nifty. Thanks for the hint. [01:27] persia, awesome thanks :) [01:27] RAOF, and good tip :) [01:28] s/One of/At least one of the following/ [01:33] persia, thanks for the hints...... but how can i find out, which one applies? [01:34] do the version and major varibals in the #shared library versions-section do have influence on this? [01:36] rdz: They can, but it's potentially more complicated than that. [01:36] persia, here it the respective section from pbuilder output: http://pastebin.ca/1827974 [01:36] i don't understand what is happening here, but it looks to me as in certain cases, files are removed [01:38] persia, netsplit: could you read my last message (i don't understand... ) [01:39] rdz: Are you trying to make multiple binary packages from a single source package? [01:39] persia, no.. i am trying to make a lib package [01:40] persia, i admit it's my first trial of creaeting a ppa package.. so i might made some mistakes [01:40] persia, actrually the only important file doesn't get included.. [01:41] which is: /usr/lib/libsomelibraries.so [01:41] That's not supposed to be an important file. That should be a symlink. [01:41] which is: /usr/lib/libsomelibraries.so.1.0.0 [01:41] would be the file, ,you're right [01:41] But I'll strongly recommend you go work with other sorts of packages first. libraries are hard for several reasons, and learning packaging and library packaging, and library management all at the same time is likely an exercise in frustration. [01:42] what makes library managment specially hard? [01:43] persia, the only thing, that seems not working right now, is that the file is not included.. is that a impossible to solve problem? it seems so silly to me [01:44] rdz: It's an easy to solve problem. The issue is entirely in your dh_install hint file contents. I'm just certain that it's a lot to get right, and you'll end up finding a bunch of little issues. [01:44] persia, which i am willing to solve [01:44] rdz: Also, have you read the prior IRC sessions about packaging libraries? [01:44] persia, this library comes with only one binary.. [01:44] persia, no, but i will [01:45] persia, thanks for mentioning those [01:45] rdz: A library should *never* come with just one binary. At a minimum you want libfoo1.0.0 and libfoo-dev [01:46] persia, both packages are built.. i mean that libfoo package only contains 1 single binary [01:47] Oh, right. That's normal. paste your libfoo.install file? [01:48] persia, hm.. now you're asking me that, i realize what might be wrong [01:48] the package is called 'libgavl1', however the files in debian are called simply gavl [01:48] gavl.* [01:49] like gavl1.install.. should they be called libgavl1.install etc? [01:49] Something like that. Should be a binary package name. [01:49] (double-check against debian/control) [01:49] persia, thanks.. [01:50] the package is called libgavl1, libgavl1-dev and libgavl1-doc [01:53] however, the 'source' is gavl [01:53] i mean the source field in debian/control [01:54] rdz: That sounds right. [01:55] persia, but that means, that all files in debian need to be called libgavl1.install and the like? [01:56] rdz: Well, ${binary-package-name}.${function}, but yeah. [01:56] persia, thanks.. for being so precise [01:57] persia, something is still worng.. how can i find out the ${binary-package-name}? [01:57] It's listed in debian/control [01:59] persia, hm.. then there is something wrong with my debian/control file [01:59] i cannot find a variable like that [01:59] rdz: It's not a variable. It's the Package: name [02:00] ah.. ok.. then the files are named correctly [02:13] persia, do you think it would be a good idea to add a lighttpd.pc.in and modify configure and Makefile without using a patching system since debian has dropped the use of it. [02:14] RoAkSoAx: I need more context to have an opinion. [02:16] persia, here's the changes made to enable the build of -dev package: http://paste.ubuntu.com/390741/ [02:17] RoAkSoAx: You'll also need lighttpd-dev.install [02:18] RoAkSoAx: But are you saying there's no longer a patch system used in Debian, but there once was? [02:18] how is the libfoo.symbols files generated? [02:19] persia, yeah there was one, I was thinking on enabling quilt and place what I've pasted in the patch, but I did that, added the --with quilt, but this way it's not building [02:19] rdz: https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols is a good guide to what you seek to do that also happens to answer the question you asked. [02:20] i applied the patch directly to the source and it builds and I can't figure out what might be wrong with it [02:20] persia, many trhanks [02:20] RoAkSoAx: Race condition: Check the build log. If you want separated patches, but need them early, consider source format 3.0(quilt). [02:22] persia, will look into it then. thanks :) [02:27] persia: you got me to update tahoe-lafs to 1.6.1 for zooko. I still haven't heard back from him, but I just put the .diff.gz on the bug at https://bugs.launchpad.net/ubuntu/+source/tahoe-lafs/+bug/529350 [02:27] Launchpad bug 529350 in tahoe-lafs "please upgrade Tahoe-LAFS in Lucid to v1.6.1 of Tahoe-LAFS" [Undecided,In progress] [02:28] jayvee: OK. The next step is to request upload. Just subscribe the sponsors if you feel that this is uploadable. As both zooko and you have noted, it shouldn't need a freeze exception. [02:30] persia: who are the sponsors? is that the package maintainer? [02:30] !sponsor [02:30] https://wiki.ubuntu.com/SponsorshipProcess [02:31] oh right [02:31] I'd seen that before, but it didn't twig. [02:31] jayvee: No worries. Takes a while to get familiar with the processes, etc. [02:31] I was trying to think of the team to subscribe, but I couldn't for the life of me remember it. [02:31] Thanks a lot for helping out. [02:34] On my other libvirt bug, mathiaz removed the ubuntu-main-sponsors subscription. He didn't give any clues as to why he might have done that. Do you have any idea? [02:34] Is that normal after it gets looked at? [02:35] Yes, but it's typically followed by an upload shortly. What was that bug number again? [02:35] persia, i checked the four points you mentioned and the .so file is still not included. [02:35] https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/528934 [02:35] Launchpad bug 528934 in libvirt "IPv6 shouldn’t be disabled by default in libvirt" [Wishlist,Triaged] [02:36] rdz: Considering that you can force-include it with debian/${binary-package}.install, I'm certain there's an issue with that file. You aren't using a leading / in the target, are you? [02:37] persia, that is the content of libgavl1.install: usr/lib/libgavl.so.1* [02:37] persia, can it be, that might something goes wrong even before that? [02:38] jayvee: mathiaz would have removed the subscription when asking for the upstream link, etc. Once you've addressed the concerns in his comment (which you did), just resubscribe the team. This is done to try to reduce the queue to only those things needing active sponsoring. [02:38] Oh, I get it. [02:38] Just re-added it. [02:39] rdz: Maybe that file doesn't exist? Maybe something went wrong earlier. Try setting DH_VERBOSE=1 and reading the build log carefully. [02:39] persia, is it possible to log to a file instead a of to stdout? [02:40] rdz: How are you building your package? [02:41] Any of debuild, pbuilder, sbuild, cowbuilder, etc. will put the log in a file. [02:41] persia, debuild -S, then 'pbuilder build libgavl-xxxxxxxx.dsc' [02:41] rdz: So pbuilder creates a log file somewhere (I don't know where), and you can inspect that. [02:42] jayvee: Also, nominations for the current release don't usually mean anything. If someone rejects it, don't think that means it won't hit lucid. Nominations are more interesting for old releases. [02:43] Good to know, thanks. [02:44] Also, I'll encourage you to hang out in #ubuntu-server : that's a better place to get advice on working with server packages, contact server developers, etc. [02:44] yeah, I was there the other day — had a good chat [02:44] (not that we won't help you here: most of us are too lazy to check if some package falls into our purview, and will just answer questions) [02:45] and I really appreciate the answers. :) [03:05] persia, the log doesn't reveal any specific.. am i supposed to put 'export DH_VEBOSE=1' into debian/rules ? [03:05] rdz: Yes. [03:06] persia, probably i need to omit the 'export' part [03:06] No. You want the export part. [03:06] vim syntax highlighting seems to indicate that at least [03:06] The vim needs to read the make manual :) [03:06] persia, there is no error nor something else suspicious [03:06] persia, hehe [03:07] You aren't looking for an error. You're looking to understand precisely what is happening so that you can see why what you expect isn't happening. [03:07] it compiles find, but then i am not able to trace what happens to the binary [03:08] persia, it's hidden in some obscure libtool commands [03:09] i am running out of ideas... [03:09] :-/ [03:09] rdz: That's part of why I said this was complicated to do all at once :) [03:10] rdz: Try a local build (not using pbuilder) and inspect the leftovers after it's done. [03:10] persia, you mean: make && make install ? [03:10] If you use debuild -b after debuild -S, you can usually safely remove the entire working directory and reunpack the source package with dpkg-source to get back where you were (ideally, the clean rule does this, but just in case your package is buggy) [03:11] persia, if i put in build-stamp dh_quilt_patch, should I have to put also a dh_quilt_unpatch ? [03:11] rdz: No, you want to exercise the build scripts in packaging. [03:11] persia, aha [03:11] RoAkSoAx: No idea. I never do it that way. [03:11] RoAkSoAx: What are you trying to accomplish? [03:14] persia, where do i get some variables from ? $(CFLAGS)? [03:14] persia, well I actually discovered how to make quilt to patch the source by adding dh_quilt_patch in build-stamp: http://pastebin.ubuntu.com/390768/ However, I do not know if I should create a clean target to put dh_quilt_unpatch or override the clean rule, or where [03:14] rdz: Just run debuild -b in the package directory. Anything that doesn't work wouldn't work in pbuilder anyway. [03:15] RoAkSoAx: Just use --with quilt (man dh) for that. [03:15] RoAkSoAx: Also, you may as well drop your binary and binary-arch rules: they don't do anything interesting. [03:16] RoAkSoAx: Also, your life will be a lot easier if you replace the entire build/build-stamp section with an override_dh_auto_configure rule. [03:16] dpkg-checkbuilddeps: Unmet build dependencies: doxygen [03:16] however, it is mentioned in debian/control:build-depends [03:16] RoAkSoAx: You probably want to do your chmods in an override_dh_fixperms rule (see man dh) [03:17] RoAkSoAx: And finally, you ought be doing the install with dh_install rather than sticking it in install-stamp. Allof these will make your rules file easier to read. [03:17] rdz: debuild doesn't automatically install your build-dependencies. Just install them. [03:18] persia, I tried using '--with quilt', however, it wasn't actually patching the source so that's why It wouldn't get the changes for the -dev package, that's why I needed to figure out another way to make it patch the source before the configure and I did it that way and now the package builds [03:18] persia, thanks [03:18] persia, binary,binary-arch, build/build-stamp, install-stamp all come from debian, should I just fix that and submit a patch? [03:19] RoAkSoAx: Only if you wish, and don't change it if they do it that way. To me, it's not an elegant way to use dh(1), but well. [03:20] The reason --with quilt wasn't working for you is because you didn't add it to all the relevant dh calls. [03:20] Well, and also, perhaps, because of timing issues, but that's separate. [03:21] persia, where/what are those relevant dh calls, binary-arch:install ? [03:22] RoAkSoAx: There are dh calls in build-stamp and install-stamp and binary-arch that don't have --with quilt [03:22] There's also an unexpected dh_quilt_patch [03:22] persia, oh so *all* have to be --with quilt [03:22] persia, the file is there in gavl/.libs/libgavl.so.1.0.0 [03:22] i thought they only had to be in [03:22] %: [03:22] dh --with quilt $@ [03:23] RoAkSoAx: Well, either that, or you need to manage quilt separately (e.g. with dh_quilt_patch and dh_quilt_unpatch at appropriate times) [03:23] It only has to be there if that's the only dh call :) [03:23] It's still a makefile, and %: only gets hit if nothing else matches. [03:24] oh it now make sense then, so that might actually be the problem why It wasn't patching [03:25] thanks for the enlightenment :) [03:25] RoAkSoAx: The key is to understand the tools you use. Once you have that, everything becomes easy :) [03:26] persia, indeed though I haven't played with the new source format much yet :) So It is just matter of practice and reading [03:27] RoAkSoAx: There's heaps of patches in the bugtracker, if you just want a target for experimentation. Just grab one, test it, get it integrated in the packaging, and submit. [03:28] persia, i think, that is the relevant part of the log: http://pastebin.ca/1828110, but i cannot see anythin suspicious.. all pathes seem correct [03:29] rdz: The first line is incorrect. It doesn't matter if "/usr/lib" exists, because that's not the target. [03:29] So the directory is probably not being created. [03:30] Also, you have a warning: perhaps libtool hasn't actually done stuff. [03:31] persia, ah [03:31] Did the file get placed in the right location in a test build? [03:31] persia, any link in specific where i can look for them? [03:31] persia, no [03:31] it's empty as well [03:31] persia, by testbuild you mean the resulting deb file? [03:32] RoAkSoAx: https://bugs.launchpad.net/ubuntu/+bugs?orderby=-date_last_updated&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.omit_dupes=on&field.has_patch=on [03:32] rdz: No, I mean by running debuild -b locally. [03:32] persia, that is what i did [03:32] rdz: That lets you check what happened and what didn't, and may help you understand what is going wrong. [03:32] and it created deb files [03:33] Right, but did it create /home/roman/sources/gavl-1.2.0pre1/debian/tmp/usr/lib/libgavl.so.1.0.0 [03:33] ah [03:33] * persia suspects it didn't [03:33] The point of the local build is to be able to inspect the leftovers, not to look at the logs. [03:33] indeed, the file is there [03:33] persia, gotcha.. thanks for your patience [03:34] persia, everything seems to be there in debian/tmp [03:34] rdz: Now, did it get copied to debian/libgavl1 (or whatever) A? [03:34] persia, awesome! Well I'll call it for the night. Thanks a lot for the help. Have a good one :) [03:34] rdz: Just follow along the expected path until you find the missing bit. Then fix that. [03:34] RoAkSoAx: Have a good night. [03:35] persia, no,it is not there [03:36] rdz: Then you have an issue with your dh_install call. [03:36] hm.. i don't have a clue what [03:38] yo... persia thanks so far.. you're a great help [03:38] dh_install: libgavl-dev missing files (usr/lib/lib*.a), aborting [03:38] There you go. That's the issue. [03:38] Don't install those anyway. [03:42] persia, great.. dh_instal doesn't produce any errors...... [03:42] persia, many many thanks [03:42] persia, i wonder, why i don't see the very same error in the log? [03:51] So, anyone wanting support for packaging in general, not related to MOTU work, please go to #ubuntu-packaging [03:51] Anyone willing to offer such support may want o idle there. [03:55] persia: So we don't have enough channels already? [03:55] persia, am i right in assuming that the rules are executed as fakeroot? [03:55] ScottK: I got tired of the ping-pong match between here and #launchpad about where to get PPA support, so I just created a channel. [03:55] Interested people can use it. [03:55] But there's no *requirement* to use it. [03:56] OK. so "not related to MOTU" is about PPAs (at least in part)? [03:58] ScottK: Right. PPAs, new packages, other random stuff. [03:58] Until Universe actually gets disestablished in some manner, I think that new packages are related to MOTU. [03:58] Whereas helping track down something that needs fixing in one of our packages, is more on-topic here. [03:58] Certainly. [03:59] Sure, for new packages trying to actually enter the distribution. Lots of support seems to be about new packages for PPAs, and I doin't think MOTU should be the support channel for that. [03:59] what's the latest on how long / in what capacity is the MOTU entity supposed to stay around? [03:59] persia: Agreed. [03:59] jdong: Indefinitely. Mostly like now. [04:00] ok [04:00] jdong: Go read the "Future of MOTU" thread on the mailing list. [04:00] There are quite a number of fine points around that 'mostly', but I think it's generally correct. [04:00] I was loosely following it [04:00] My initial post covered the history, status, and expected plans fairly well (but real implementation depends on support from all MOTU) [04:01] Thanks for taking care of that persia. [04:01] indeed, thank you persia [04:01] reading your initial post again more carefully [04:01] ScottK: The issue is that I know I can't staff it myself, so whether this actually works depends on their being enough folk willing to make it happen. I just fiddled the IRC server. [04:03] o/ jdong [04:03] hey psusi [04:03] long time no see! [04:03] yea, been a while ;) [04:04] say, you know much about udev? I'm trying to track down what appears to be an infinite udev loop in 10.04 related to udev [04:05] related to dmraid rather [04:09] where can i read about the debian/rules file? [04:10] rdz: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules [04:11] crimsun, thanks [04:21] persia, just for your information.. my issue is finally solved. many many thanks for all your help and your patience [04:22] persia, i could really learn a lot today, with your help [04:36] rdz: Glad to hear it :) [04:38] am i right in thinking, that dh_makeshlibs is used to create automatically the postinst and postrm scripts, so that ldconfig is executed after installation/removal? [04:41] It's primary purpose is to make the shlibs files, but it also adds the ldconfig calls, yes. [04:41] RAOF, when i simply do 'fakeroot dh_makeshlibs' i don't get any postrm / postinst scripts [04:46] Hm. I'm not sure off the top of my head if you'd expect that. [04:47] You're running dh_makeshlibs in the root of your packaging directory, and you actually have some shared libraries there? [04:47] RAOF, yup [04:48] i see the file debian/libgavl1.postinst.debhelper file growing, but actually cannot find the actual script [04:49] What about after running dh_installdeb? [04:51] RAOF, many thanks [06:28] good morning [06:40] YokoZar: did you ever file that bug for pidgin-mbpurple? [08:02] i have a control file like this.. http://pastie.org/859191 and i wanted to add 'Conflicts' to the pkg 'sprosslnk' I added/built the entire pkg.. but when i try to install that pkg i see that I can find this entry missing..When i open up the control file (the one i've pasted) after buildpkg, I can see that the entry im made is missing.. why so.. and how do i add it ? [08:11] wrapster: I'll suggest you ask in #ubuntu-packaging (as we don't have that package, and it's past feature-freeze, so we're not concentrating on new packages) [08:13] persia: they dont seem to be responding.. and hardly anyone on that channel [08:17] wrapster: Just wait a bit. I'm certain someone will help ;) [08:39] wrapster: generally you don't want a conflicts [08:39] wrapster: breaks is usually better [08:39] lifeless: ok. [08:39] wrapster: see policy for their specific meanings. [08:39] ok [08:55] In python, if I have a sequence "A and B or C and D or E and F" will that behave the same as "A && B || C && D || E && F" in shell? [08:55] * persia suspects so based on playing with the python interactive environment, but would like confirmation [08:57] persia: yes [08:57] lifeless: Thanks. [08:58] or rather, 'near enough' [08:58] as python has evaluations for true/false that shell doesn't. [08:59] The important part was just that if the current state is false and the next word is "and" drop it, if the current state is true and the next word is "or" drop it, and otherwise continue. [09:01] it also returns the last thing looked up [09:01] false or 0 -> 0 [09:01] persia, why don't you just add some extra parentheses to clarify your intent though? surely someone who is reading over that code will have difficulty making sense of it and trying to figure out the order of operations otherwise [09:02] superm1: Um... I was saving them for the lisp hackers fund? [09:02] * persia adds parentheses [09:04] iulian: it seems that the last person who touched gdeskcal in ubuntu was you. why was XB-Python-Version switched away from ${python:Versions} to >= 2.4? === noodles785 is now known as noodles775 [09:58] does anyone know if FFe are still being approved for packages in universe/multiverse? [10:01] slytherin: On a case by case basis, FFes may be approved until release day. Note that we are also currently in UI Freeze. More freezes come into effect over time, and there will be more limitations. [10:02] persia: Fine. The package I am working does not seem to break UI freeze. So I suppose it will get approved. [10:02] Depends on the features, etc. [10:06] persia: The package is gst-plugins-ugly-multiverse0.10. It is more of 'make it work with latest x264' release. But reading the changelog I feel like there are few feature additions. [10:09] slytherin: If you're not sure, ask for ubuntu-release review. [10:09] yes I am filing a FFe bug. === Guest78773 is now known as NCommander === NCommander is now known as Guest33867 === mcasadevall_ is now known as NCommander [10:40] NCommander: I wanted to send you an email today, but your address is not on your LP page [10:40] mok0: there's a "Send this user email" link if need be [10:40] * NCommander probably should de-private his email addresses again [10:41] NCommander: it doesn't hurt :-) [10:41] mok0: what can I do for you? [10:41] * NCommander notes he's recovering from a harddrive crash, so I'm a bit disorganized ATM [10:41] NCommander: it concerns getting backporters team up to speed [10:42] NCommander: ... and I see you are a member of that team :-) [10:42] eek [10:42] hehe [10:42] * NCommander runs out the nearest airlock [10:42] mok0: I don't have a lot of free time to look at backports so much recently, but if you have a specific backport you want looked at ... [10:43] NCommander: That's not my problem [10:44] NCommander: let me send you the mail [10:44] mok0: sure, but I won't be reading it for awhile. Still have to re-seutp mail clients [10:44] NCommander: I'll just use the web interface [10:44] NCommander: OK, I'll pastebinit === ogra_ is now known as ogra [11:04] hyperair: Yay, that was a looong time ago. I have no idea, sorry. [11:57] i uploaded a package to my ppa to be built for hardy, but i made the source package on karmic. now i am getting this error: dh_clean: Sorry, but 6 is the highest compatibility level supported by this debhelper.. is there a way for me to make the necessary files compat level 6? [11:58] iulian: lol then you'll be okay with me dropping almost all the changes you made? =p [11:58] rdz: We've a new channel to answer questions like that: #ubuntu-packaging. Come visit. [11:58] would it be sufficient to just change the content of debian/compat to 6? [11:58] persia, hi btw [11:58] persia, thanks. i will === mcasadevall is now known as Guest20793 === Guest20793 is now known as NCommander [12:54] oh! multiprocessing strikes again! [12:56] Hello, could someone grant FFe to LP 530204 ? especially it also fixes LP 491784, I asked on #ubuntu-release, but no one replies there [12:56] Launchpad bug 530204 in libbasicplayer-java "FFe: Sync libbasicplayer-java 3.0-5 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/530204 [12:56] Launchpad bug 491784 in openjdk-6 "Sound does not work with openjdk" [Undecided,New] https://launchpad.net/bugs/491784 === keffie_jayx_ is now known as effie_jayx === hannesw_ is now known as hannesw [13:00] AnAnt: You want to subscribe the ubuntu-release team. If you're in a huge hurry, you can ask on #ubuntu-release. If anyone here is able to address your request, it is purely by coincidence. [13:00] ok [13:00] And just because nobody gets back to you soon there doesn't make this a better place :) [13:00] They bugs will be reviewed. Someone will respond. This may take a bit of time. [13:00] persia: I just found out that Steve Langasek subscribed ubuntu-release already 4 days ago [13:00] Well then, it's under consideration :) [13:00] ok [13:01] sorry then [13:01] No worries. The procedures are complicated and changing. [13:01] yeah, the requestsync tool subscribed motu-release instead of ubuntu-release [13:02] seems that Steve realized that & fixed it [13:02] AnAnt: It is quite possible that Steve did that because requestsync script subscribes motu-release by default in karmic (which is wrong as per updated policy). [13:02] yup [13:02] geser: Any chance requestsync could be fixed in karmic? [13:03] james_w: mind removing (again) python-multiprocessing from lucid (bug #418280) ? Thanks! [13:03] Launchpad bug 418280 in python-multiprocessing "Please remove python-multiprocessing from Lucid" [Wishlist,New] https://launchpad.net/bugs/418280 [13:03] slytherin: You could fix it too :) [13:04] persia: I could upload it in karmic-proposed. But I usually avoid that when I am not a regular maintainer. [13:04] DktrKranz: seriously? LOL [13:04] slytherin: we don't have maintainers in Ubuntu. Just do it :) [13:04] slytherin: If you're not sure, ask someone else to review your change before you upload. [13:05] POX_: yeah, I asked for blacklist, so it wouldn't have reappeared, but I had no luck. [13:05] persia: geser already fixed it in lucid so I thought he might be interested in doing SRU. :-) [13:05] slytherin: I see you're interested in gnusim8085 btw [13:05] AnAnt: interested in what way? [13:06] slytherin: aren't you the one who've been making the last couple of packages for it in Debian ? [13:06] AnAnt: yes I am. Considering that I am primary maintainer upstream it seemed more natural. :-) [13:07] AnAnt: We (upstream) could use help in completing Arabic translation. :-D [13:08] oh, I never noticed that [13:08] that's nice [13:09] AnAnt: It is pretty recent development. I am trying to get FFe for the latest release. Meanwhile you can check - https://translations.edge.launchpad.net/gnusim8085 [13:09] slytherin: hmmm, I'm not into translation (especially that we study/work in the electronics field in English language), but, there is a guy doing arabic translation for gEDA [13:11] AnAnt: Never mind. I thought you were working on translations. [13:12] Adnene knows arabic ? [13:13] hmm, never mind [13:25] hyperair: If that is the right thing to do, then yes, sure. [13:31] iulian: i'm in favour of dropping most of the changes to reduce the debian-ubuntu delta, since i can't see why they were added, other than for maintenance purposes. stuff like the standards-version bump. [13:31] i'd just like to reconfirm that this dropping these changes is correct before i go ahead and do it [13:32] hyperair: sounds sensible to me [13:32] well then. i'll get to work =) [13:32] hyperair: requestsync? [14:34] YokoZar: did you ever file that bug for pidgin-mbpurple? === mcasadevall is now known as NCommander [14:44] If anyone is handy with pbuilder and has time to create a stanza to add to http://people.ubuntu.com/~persia/pull-soyuz-chroot whilst I'm idle, I'd appreciate the help. Corrections would be nice too :) === AndrewGe1 is now known as AndrewGee [14:51] anybody any comments on bug #534261 ? [14:51] Launchpad bug 534261 in pdns-recursor "Wishlist: new upstream version 3.2" [Undecided,New] https://launchpad.net/bugs/534261 [14:53] cemc: That one is not yet packaged in Debian and the release date is pretty short of a notice. :/ [14:54] Rhonda: too bad ;) does it need to be packaged in debian though? [14:54] cemc: I would try to get in contact with Christoph Haas, the DD who maintains the package in Debain, from what I remember he usually is pretty responsive. [14:54] So that no duplicate efforts happen in that respect. [14:56] got it [14:56] thx [14:57] cemc: I'm currently chatting with him. :) [14:58] sent a mail too [15:01] Rhonda: what's he saying? :) [15:01] how's the weather? :) [15:07] cemc: Christoph isn't on the team anymore he said. :P But I got the jabberID of the other person and he promised to look into the update tonight. [15:08] european time, I guess [15:09] Rhonda: cool, thanks! can you ping me if (news()) ? [15:11] cemc: And I'm not too sure if your PPA version is proper, does this take into account any possible Debian update? [15:11] cemc: About news, PTS subscribe to source uploads, http://packages.qa.debian.org/pdns-recursor :) [15:13] Rhonda: thanks. about the ppa versioning, I'm not sure... those packages I really did for myself for testing mainly... is it incorrect? [15:13] I have no clue, I guess it would work properly though. :) [15:16] Rhonda: I think if debian will have 3.2-1 that should be > 3.2-0whatever, right? [15:16] Yes, that's my thoughts too. :) [15:17] cemc: I think some non-maintainer update to the new upstream version might though use 3.2-0.1 [15:18] So I guess -0~whatever might be more suiting. I'm not sure if there are some suggestions hanging around on the wiki, though. [15:25] micahg: not just yet [15:25] YokoZar: there was a bug filed about the conflict [15:26] probably a result of my mailing list thread [15:26] no, an install bug [15:26] bug 530660 [15:26] Launchpad bug 530660 in pidgin-microblog "package pidgin-microblog (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/purple-2/liboldtwitter.so', which is also in package pidgin-mbpurple 0:0.2.4-0ubuntu1" [Medium,Triaged] https://launchpad.net/bugs/530660 [15:26] ahh, well there you are [15:27] YokoZar: do you want to take it and prepare teh debdiff? [15:45] reviewing some patches. looking for some help adding some man pages to a package [15:47] duanedesign: what's the problem? [15:48] randomaction: do i just place them in a directory called for instance: debian/db4.2-doc.manpages [15:49] then make a patch? [15:51] You can call dh_installman from debian/rules. It will install manpages listed in debian/PACKAGENAME.manpages, see "man dh_installman". [15:51] the pages were already written and attached to a bug report about the missing manpages. [15:51] randomaction: ahh. ok [15:51] randomaction: i messed around with dh_installman and wasnt getting it right :) [15:52] *.manpages is a text file, not a directory [16:07] once finished to modify a debian package for ubuntu to add a dependence in debian/control file, what's the next step? and, can be that a good reason for an exceptionfreeze? [17:13] BlackZ: does the new dependency enable a new feature? [17:30] morning all [17:33] Hi imbrandon === dpm is now known as dpm-afk [17:42] not support chan, i know i know, but i got a quick question , ok i got a ubuntu 9.10 install ( headless server , only access via ssh ) that seems to be going to sleep or hybernate every half an hour or so, i thought i disabled all PM and even removed some of the packages, what log can i look in to track this down ? [17:42] the reason i know its asleep is i can go in the other room and pound on the keyboard and it "wakes" [17:45]