| persia | cody-somerville: Tell the CC, not me :) | 00:18 |
|---|---|---|
| === kamalmostafa is now known as kamalmostafa-out | ||
| RoAkSoAx | hey guys how to make autotool update patches during build with debhelper? | 00:58 |
| RoAkSoAx | i meant, how to make autotool files get update during build with dh7? | 00:58 |
| persia | How much of an update do you want? | 00:59 |
| RoAkSoAx | 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:01 |
| persia | Do you understand what DEB_AUTO_UPDATE_* did? | 01:04 |
| RoAkSoAx | persia, just ensure automake's version to use? | 01:05 |
| persia | heh. No. | 01:05 |
| persia | So, which of DEB_AUTO_UPDATE_* were actually used? | 01:06 |
| RoAkSoAx | persia, http://paste.ubuntu.com/390707/ | 01:06 |
| persia | Generally the definitions of those can be derived from /usr/share/cdbs/1/class/autotools-files.mk | 01:06 |
| persia | (although autotools.mk and autotools-vars.mk have some) | 01:08 |
| persia | Once you know what you actually wanted to do, you'd probably want to add an override_dh_auto_configure: rule. | 01:09 |
| RoAkSoAx | ok | 01:09 |
| persia | Looks to me like it's intending to go all the way from libtoolize onwards. | 01:11 |
| persia | 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:11 |
| RoAkSoAx | awesome. Thanks a lot | 01:13 |
| === kamalmostafa-out is now known as kamalmostafa | ||
| RoAkSoAx | persia, where can I find good documentation to learn everything about this? | 01:20 |
| rdz | 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:21 |
| persia | 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 |
| persia | For autotools, get the goat book | 01:25 |
| RAOF | persia, RoAkSoAx: Also, running dh --no-act $TARGET in a packaging directory will list the sequence, including any overrides you've specified. | 01:26 |
| persia | 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:26 |
| persia | RAOF: Nifty. Thanks for the hint. | 01:27 |
| RoAkSoAx | persia, awesome thanks :) | 01:27 |
| RoAkSoAx | RAOF, and good tip :) | 01:27 |
| persia | s/One of/At least one of the following/ | 01:28 |
| rdz | persia, thanks for the hints...... but how can i find out, which one applies? | 01:33 |
| rdz | do the version and major varibals in the #shared library versions-section do have influence on this? | 01:34 |
| persia | rdz: They can, but it's potentially more complicated than that. | 01:36 |
| rdz | persia, here it the respective section from pbuilder output: http://pastebin.ca/1827974 | 01:36 |
| rdz | i don't understand what is happening here, but it looks to me as in certain cases, files are removed | 01:36 |
| rdz | persia, netsplit: could you read my last message (i don't understand... ) | 01:38 |
| persia | rdz: Are you trying to make multiple binary packages from a single source package? | 01:39 |
| rdz | persia, no.. i am trying to make a lib package | 01:39 |
| rdz | persia, i admit it's my first trial of creaeting a ppa package.. so i might made some mistakes | 01:40 |
| rdz | persia, actrually the only important file doesn't get included.. | 01:40 |
| rdz | which is: /usr/lib/libsomelibraries.so | 01:41 |
| persia | That's not supposed to be an important file. That should be a symlink. | 01:41 |
| rdz | which is: /usr/lib/libsomelibraries.so.1.0.0 | 01:41 |
| rdz | would be the file, ,you're right | 01:41 |
| persia | 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:41 |
| rdz | what makes library managment specially hard? | 01:42 |
| rdz | 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:43 |
| persia | 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 |
| rdz | persia, which i am willing to solve | 01:44 |
| persia | rdz: Also, have you read the prior IRC sessions about packaging libraries? | 01:44 |
| rdz | persia, this library comes with only one binary.. | 01:44 |
| rdz | persia, no, but i will | 01:44 |
| rdz | persia, thanks for mentioning those | 01:45 |
| persia | rdz: A library should *never* come with just one binary. At a minimum you want libfoo1.0.0 and libfoo-dev | 01:45 |
| rdz | persia, both packages are built.. i mean that libfoo package only contains 1 single binary | 01:46 |
| persia | Oh, right. That's normal. paste your libfoo.install file? | 01:47 |
| rdz | persia, hm.. now you're asking me that, i realize what might be wrong | 01:48 |
| rdz | the package is called 'libgavl1', however the files in debian are called simply gavl | 01:48 |
| rdz | gavl.* | 01:48 |
| rdz | like gavl1.install.. should they be called libgavl1.install etc? | 01:49 |
| persia | Something like that. Should be a binary package name. | 01:49 |
| persia | (double-check against debian/control) | 01:49 |
| rdz | persia, thanks.. | 01:49 |
| rdz | the package is called libgavl1, libgavl1-dev and libgavl1-doc | 01:50 |
| rdz | however, the 'source' is gavl | 01:53 |
| rdz | i mean the source field in debian/control | 01:53 |
| persia | rdz: That sounds right. | 01:54 |
| rdz | persia, but that means, that all files in debian need to be called libgavl1.install and the like? | 01:55 |
| persia | rdz: Well, ${binary-package-name}.${function}, but yeah. | 01:56 |
| rdz | persia, thanks.. for being so precise | 01:56 |
| rdz | persia, something is still worng.. how can i find out the ${binary-package-name}? | 01:57 |
| persia | It's listed in debian/control | 01:57 |
| rdz | persia, hm.. then there is something wrong with my debian/control file | 01:59 |
| rdz | i cannot find a variable like that | 01:59 |
| persia | rdz: It's not a variable. It's the Package: name | 01:59 |
| rdz | ah.. ok.. then the files are named correctly | 02:00 |
| RoAkSoAx | 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:13 |
| persia | RoAkSoAx: I need more context to have an opinion. | 02:14 |
| RoAkSoAx | persia, here's the changes made to enable the build of -dev package: http://paste.ubuntu.com/390741/ | 02:16 |
| persia | RoAkSoAx: You'll also need lighttpd-dev.install | 02:17 |
| persia | RoAkSoAx: But are you saying there's no longer a patch system used in Debian, but there once was? | 02:18 |
| rdz | how is the libfoo.symbols files generated? | 02:18 |
| RoAkSoAx | 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 |
| persia | 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:19 |
| RoAkSoAx | 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 |
| rdz | persia, many trhanks | 02:20 |
| persia | RoAkSoAx: Race condition: Check the build log. If you want separated patches, but need them early, consider source format 3.0(quilt). | 02:20 |
| RoAkSoAx | persia, will look into it then. thanks :) | 02:22 |
| jayvee | 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 |
| ubottu | Launchpad bug 529350 in tahoe-lafs "please upgrade Tahoe-LAFS in Lucid to v1.6.1 of Tahoe-LAFS" [Undecided,In progress] | 02:27 |
| persia | 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:28 |
| jayvee | persia: who are the sponsors? is that the package maintainer? | 02:30 |
| persia | !sponsor | 02:30 |
| persia | https://wiki.ubuntu.com/SponsorshipProcess | 02:30 |
| jayvee | oh right | 02:31 |
| jayvee | I'd seen that before, but it didn't twig. | 02:31 |
| persia | jayvee: No worries. Takes a while to get familiar with the processes, etc. | 02:31 |
| jayvee | I was trying to think of the team to subscribe, but I couldn't for the life of me remember it. | 02:31 |
| persia | Thanks a lot for helping out. | 02:31 |
| jayvee | 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 |
| jayvee | Is that normal after it gets looked at? | 02:34 |
| persia | Yes, but it's typically followed by an upload shortly. What was that bug number again? | 02:35 |
| rdz | persia, i checked the four points you mentioned and the .so file is still not included. | 02:35 |
| jayvee | https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/528934 | 02:35 |
| ubottu | Launchpad bug 528934 in libvirt "IPv6 shouldn’t be disabled by default in libvirt" [Wishlist,Triaged] | 02:35 |
| persia | 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:36 |
| rdz | persia, that is the content of libgavl1.install: usr/lib/libgavl.so.1* | 02:37 |
| rdz | persia, can it be, that might something goes wrong even before that? | 02:37 |
| persia | 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 |
| jayvee | Oh, I get it. | 02:38 |
| jayvee | Just re-added it. | 02:38 |
| persia | 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 |
| rdz | persia, is it possible to log to a file instead a of to stdout? | 02:39 |
| persia | rdz: How are you building your package? | 02:40 |
| persia | Any of debuild, pbuilder, sbuild, cowbuilder, etc. will put the log in a file. | 02:41 |
| rdz | persia, debuild -S, then 'pbuilder build libgavl-xxxxxxxx.dsc' | 02:41 |
| persia | rdz: So pbuilder creates a log file somewhere (I don't know where), and you can inspect that. | 02:41 |
| persia | 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:42 |
| jayvee | Good to know, thanks. | 02:43 |
| persia | 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 |
| jayvee | yeah, I was there the other day — had a good chat | 02:44 |
| persia | (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:44 |
| jayvee | and I really appreciate the answers. :) | 02:45 |
| rdz | persia, the log doesn't reveal any specific.. am i supposed to put 'export DH_VEBOSE=1' into debian/rules ? | 03:05 |
| persia | rdz: Yes. | 03:05 |
| rdz | persia, probably i need to omit the 'export' part | 03:06 |
| persia | No. You want the export part. | 03:06 |
| rdz | vim syntax highlighting seems to indicate that at least | 03:06 |
| persia | The vim needs to read the make manual :) | 03:06 |
| rdz | persia, there is no error nor something else suspicious | 03:06 |
| rdz | persia, hehe | 03:06 |
| persia | 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 |
| rdz | it compiles find, but then i am not able to trace what happens to the binary | 03:07 |
| rdz | persia, it's hidden in some obscure libtool commands | 03:08 |
| rdz | i am running out of ideas... | 03:09 |
| rdz | :-/ | 03:09 |
| persia | rdz: That's part of why I said this was complicated to do all at once :) | 03:09 |
| persia | rdz: Try a local build (not using pbuilder) and inspect the leftovers after it's done. | 03:10 |
| rdz | persia, you mean: make && make install ? | 03:10 |
| persia | 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:10 |
| RoAkSoAx | persia, if i put in build-stamp dh_quilt_patch, should I have to put also a dh_quilt_unpatch ? | 03:11 |
| persia | rdz: No, you want to exercise the build scripts in packaging. | 03:11 |
| rdz | persia, aha | 03:11 |
| persia | RoAkSoAx: No idea. I never do it that way. | 03:11 |
| persia | RoAkSoAx: What are you trying to accomplish? | 03:11 |
| rdz | persia, where do i get some variables from ? $(CFLAGS)? | 03:14 |
| RoAkSoAx | 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 |
| persia | rdz: Just run debuild -b in the package directory. Anything that doesn't work wouldn't work in pbuilder anyway. | 03:14 |
| persia | RoAkSoAx: Just use --with quilt (man dh) for that. | 03:15 |
| persia | RoAkSoAx: Also, you may as well drop your binary and binary-arch rules: they don't do anything interesting. | 03:15 |
| persia | 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 |
| rdz | dpkg-checkbuilddeps: Unmet build dependencies: doxygen | 03:16 |
| rdz | however, it is mentioned in debian/control:build-depends | 03:16 |
| persia | RoAkSoAx: You probably want to do your chmods in an override_dh_fixperms rule (see man dh) | 03:16 |
| persia | 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 |
| persia | rdz: debuild doesn't automatically install your build-dependencies. Just install them. | 03:17 |
| RoAkSoAx | 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 |
| rdz | persia, thanks | 03:18 |
| RoAkSoAx | persia, binary,binary-arch, build/build-stamp, install-stamp all come from debian, should I just fix that and submit a patch? | 03:18 |
| persia | 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:19 |
| persia | The reason --with quilt wasn't working for you is because you didn't add it to all the relevant dh calls. | 03:20 |
| persia | Well, and also, perhaps, because of timing issues, but that's separate. | 03:20 |
| RoAkSoAx | persia, where/what are those relevant dh calls, binary-arch:install ? | 03:21 |
| persia | RoAkSoAx: There are dh calls in build-stamp and install-stamp and binary-arch that don't have --with quilt | 03:22 |
| persia | There's also an unexpected dh_quilt_patch | 03:22 |
| RoAkSoAx | persia, oh so *all* have to be --with quilt | 03:22 |
| rdz | persia, the file is there in <package-src>gavl/.libs/libgavl.so.1.0.0 | 03:22 |
| RoAkSoAx | i thought they only had to be in | 03:22 |
| RoAkSoAx | %: | 03:22 |
| RoAkSoAx | dh --with quilt $@ | 03:22 |
| persia | 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 |
| persia | It only has to be there if that's the only dh call :) | 03:23 |
| persia | It's still a makefile, and %: only gets hit if nothing else matches. | 03:23 |
| RoAkSoAx | oh it now make sense then, so that might actually be the problem why It wasn't patching | 03:24 |
| RoAkSoAx | thanks for the enlightenment :) | 03:25 |
| persia | RoAkSoAx: The key is to understand the tools you use. Once you have that, everything becomes easy :) | 03:25 |
| RoAkSoAx | persia, indeed though I haven't played with the new source format much yet :) So It is just matter of practice and reading | 03:26 |
| persia | 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:27 |
| rdz | 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:28 |
| persia | rdz: The first line is incorrect. It doesn't matter if "/usr/lib" exists, because that's not the target. | 03:29 |
| persia | So the directory is probably not being created. | 03:29 |
| persia | Also, you have a warning: perhaps libtool hasn't actually done stuff. | 03:30 |
| rdz | persia, ah | 03:31 |
| persia | Did the file get placed in the right location in a test build? | 03:31 |
| RoAkSoAx | persia, any link in specific where i can look for them? | 03:31 |
| rdz | persia, no | 03:31 |
| rdz | it's empty as well | 03:31 |
| rdz | persia, by testbuild you mean the resulting deb file? | 03:31 |
| persia | 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 |
| persia | rdz: No, I mean by running debuild -b locally. | 03:32 |
| rdz | persia, that is what i did | 03:32 |
| persia | rdz: That lets you check what happened and what didn't, and may help you understand what is going wrong. | 03:32 |
| rdz | and it created deb files | 03:32 |
| persia | Right, but did it create /home/roman/sources/gavl-1.2.0pre1/debian/tmp/usr/lib/libgavl.so.1.0.0 | 03:33 |
| rdz | ah | 03:33 |
| * persia suspects it didn't | 03:33 | |
| persia | The point of the local build is to be able to inspect the leftovers, not to look at the logs. | 03:33 |
| rdz | indeed, the file is there | 03:33 |
| rdz | persia, gotcha.. thanks for your patience | 03:33 |
| rdz | persia, everything seems to be there in debian/tmp | 03:34 |
| persia | rdz: Now, did it get copied to debian/libgavl1 (or whatever) A? | 03:34 |
| RoAkSoAx | persia, awesome! Well I'll call it for the night. Thanks a lot for the help. Have a good one :) | 03:34 |
| persia | rdz: Just follow along the expected path until you find the missing bit. Then fix that. | 03:34 |
| persia | RoAkSoAx: Have a good night. | 03:34 |
| rdz | persia, no,it is not there | 03:35 |
| persia | rdz: Then you have an issue with your dh_install call. | 03:36 |
| rdz | hm.. i don't have a clue what | 03:36 |
| rdz | yo... persia thanks so far.. you're a great help | 03:38 |
| rdz | dh_install: libgavl-dev missing files (usr/lib/lib*.a), aborting | 03:38 |
| persia | There you go. That's the issue. | 03:38 |
| persia | Don't install those anyway. | 03:38 |
| rdz | persia, great.. dh_instal doesn't produce any errors...... | 03:42 |
| rdz | persia, many many thanks | 03:42 |
| rdz | persia, i wonder, why i don't see the very same error in the log? | 03:42 |
| persia | So, anyone wanting support for packaging in general, not related to MOTU work, please go to #ubuntu-packaging | 03:51 |
| persia | Anyone willing to offer such support may want o idle there. | 03:51 |
| ScottK | persia: So we don't have enough channels already? | 03:55 |
| rdz | persia, am i right in assuming that the rules are executed as fakeroot? | 03:55 |
| persia | 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 |
| persia | Interested people can use it. | 03:55 |
| persia | But there's no *requirement* to use it. | 03:55 |
| ScottK | OK. so "not related to MOTU" is about PPAs (at least in part)? | 03:56 |
| persia | ScottK: Right. PPAs, new packages, other random stuff. | 03:58 |
| ScottK | Until Universe actually gets disestablished in some manner, I think that new packages are related to MOTU. | 03:58 |
| persia | Whereas helping track down something that needs fixing in one of our packages, is more on-topic here. | 03:58 |
| ScottK | Certainly. | 03:58 |
| persia | 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 |
| jdong | what's the latest on how long / in what capacity is the MOTU entity supposed to stay around? | 03:59 |
| ScottK | persia: Agreed. | 03:59 |
| ScottK | jdong: Indefinitely. Mostly like now. | 03:59 |
| jdong | ok | 04:00 |
| persia | jdong: Go read the "Future of MOTU" thread on the mailing list. | 04:00 |
| ScottK | There are quite a number of fine points around that 'mostly', but I think it's generally correct. | 04:00 |
| jdong | I was loosely following it | 04:00 |
| persia | My initial post covered the history, status, and expected plans fairly well (but real implementation depends on support from all MOTU) | 04:00 |
| ScottK | Thanks for taking care of that persia. | 04:01 |
| jdong | indeed, thank you persia | 04:01 |
| jdong | reading your initial post again more carefully | 04:01 |
| persia | 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:01 |
| psusi | o/ jdong | 04:03 |
| jdong | hey psusi | 04:03 |
| jdong | long time no see! | 04:03 |
| psusi | yea, been a while ;) | 04:03 |
| psusi | 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:04 |
| psusi | related to dmraid rather | 04:05 |
| rdz | where can i read about the debian/rules file? | 04:09 |
| crimsun | rdz: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules | 04:10 |
| rdz | crimsun, thanks | 04:11 |
| rdz | persia, just for your information.. my issue is finally solved. many many thanks for all your help and your patience | 04:21 |
| rdz | persia, i could really learn a lot today, with your help | 04:22 |
| persia | rdz: Glad to hear it :) | 04:36 |
| rdz | 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:38 |
| RAOF | It's primary purpose is to make the shlibs files, but it also adds the ldconfig calls, yes. | 04:41 |
| rdz | RAOF, when i simply do 'fakeroot dh_makeshlibs' i don't get any postrm / postinst scripts | 04:41 |
| RAOF | Hm. I'm not sure off the top of my head if you'd expect that. | 04:46 |
| RAOF | You're running dh_makeshlibs in the root of your packaging directory, and you actually have some shared libraries there? | 04:47 |
| rdz | RAOF, yup | 04:47 |
| rdz | i see the file debian/libgavl1.postinst.debhelper file growing, but actually cannot find the actual script | 04:48 |
| RAOF | What about after running dh_installdeb? | 04:49 |
| rdz | RAOF, many thanks | 04:51 |
| dholbach | good morning | 06:28 |
| micahg | YokoZar: did you ever file that bug for pidgin-mbpurple? | 06:40 |
| wrapster | 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:02 |
| persia | 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:11 |
| wrapster | persia: they dont seem to be responding.. and hardly anyone on that channel | 08:13 |
| persia | wrapster: Just wait a bit. I'm certain someone will help ;) | 08:17 |
| lifeless | wrapster: generally you don't want a conflicts | 08:39 |
| lifeless | wrapster: breaks is usually better | 08:39 |
| wrapster | lifeless: ok. | 08:39 |
| lifeless | wrapster: see policy for their specific meanings. | 08:39 |
| wrapster | ok | 08:39 |
| persia | 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:55 | |
| lifeless | persia: yes | 08:57 |
| persia | lifeless: Thanks. | 08:57 |
| lifeless | or rather, 'near enough' | 08:58 |
| lifeless | as python has evaluations for true/false that shell doesn't. | 08:58 |
| persia | 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. | 08:59 |
| lifeless | it also returns the last thing looked up | 09:01 |
| lifeless | false or 0 -> 0 | 09:01 |
| superm1 | 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:01 |
| persia | superm1: Um... I was saving them for the lisp hackers fund? | 09:02 |
| * persia adds parentheses | 09:02 | |
| hyperair | 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? | 09:04 |
| === noodles785 is now known as noodles775 | ||
| slytherin | does anyone know if FFe are still being approved for packages in universe/multiverse? | 09:58 |
| persia | 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:01 |
| slytherin | persia: Fine. The package I am working does not seem to break UI freeze. So I suppose it will get approved. | 10:02 |
| persia | Depends on the features, etc. | 10:02 |
| slytherin | 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:06 |
| persia | slytherin: If you're not sure, ask for ubuntu-release review. | 10:09 |
| slytherin | yes I am filing a FFe bug. | 10:09 |
| === Guest78773 is now known as NCommander | ||
| === NCommander is now known as Guest33867 | ||
| === mcasadevall_ is now known as NCommander | ||
| mok0 | NCommander: I wanted to send you an email today, but your address is not on your LP page | 10:40 |
| NCommander | mok0: there's a "Send this user email" link if need be | 10:40 |
| * NCommander probably should de-private his email addresses again | 10:40 | |
| mok0 | NCommander: it doesn't hurt :-) | 10:41 |
| NCommander | 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 | |
| mok0 | NCommander: it concerns getting backporters team up to speed | 10:41 |
| mok0 | NCommander: ... and I see you are a member of that team :-) | 10:42 |
| NCommander | eek | 10:42 |
| mok0 | hehe | 10:42 |
| * NCommander runs out the nearest airlock | 10:42 | |
| NCommander | 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:42 |
| mok0 | NCommander: That's not my problem | 10:43 |
| mok0 | NCommander: let me send you the mail | 10:44 |
| NCommander | mok0: sure, but I won't be reading it for awhile. Still have to re-seutp mail clients | 10:44 |
| mok0 | NCommander: I'll just use the web interface | 10:44 |
| mok0 | NCommander: OK, I'll pastebinit | 10:44 |
| === ogra_ is now known as ogra | ||
| iulian | hyperair: Yay, that was a looong time ago. I have no idea, sorry. | 11:04 |
| rdz | 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:57 |
| hyperair | iulian: lol then you'll be okay with me dropping almost all the changes you made? =p | 11:58 |
| persia | rdz: We've a new channel to answer questions like that: #ubuntu-packaging. Come visit. | 11:58 |
| rdz | would it be sufficient to just change the content of debian/compat to 6? | 11:58 |
| rdz | persia, hi btw | 11:58 |
| rdz | persia, thanks. i will | 11:58 |
| === mcasadevall is now known as Guest20793 | ||
| === Guest20793 is now known as NCommander | ||
| DktrKranz | oh! multiprocessing strikes again! | 12:54 |
| AnAnt | 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 |
| ubottu | 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 |
| ubottu | Launchpad bug 491784 in openjdk-6 "Sound does not work with openjdk" [Undecided,New] https://launchpad.net/bugs/491784 | 12:56 |
| === keffie_jayx_ is now known as effie_jayx | ||
| === hannesw_ is now known as hannesw | ||
| persia | 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 |
| AnAnt | ok | 13:00 |
| persia | And just because nobody gets back to you soon there doesn't make this a better place :) | 13:00 |
| persia | They bugs will be reviewed. Someone will respond. This may take a bit of time. | 13:00 |
| AnAnt | persia: I just found out that Steve Langasek subscribed ubuntu-release already 4 days ago | 13:00 |
| persia | Well then, it's under consideration :) | 13:00 |
| AnAnt | ok | 13:00 |
| AnAnt | sorry then | 13:01 |
| persia | No worries. The procedures are complicated and changing. | 13:01 |
| AnAnt | yeah, the requestsync tool subscribed motu-release instead of ubuntu-release | 13:01 |
| AnAnt | seems that Steve realized that & fixed it | 13:02 |
| slytherin | 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 |
| AnAnt | yup | 13:02 |
| slytherin | geser: Any chance requestsync could be fixed in karmic? | 13:02 |
| DktrKranz | james_w: mind removing (again) python-multiprocessing from lucid (bug #418280) ? Thanks! | 13:03 |
| ubottu | Launchpad bug 418280 in python-multiprocessing "Please remove python-multiprocessing from Lucid" [Wishlist,New] https://launchpad.net/bugs/418280 | 13:03 |
| persia | slytherin: You could fix it too :) | 13:03 |
| slytherin | persia: I could upload it in karmic-proposed. But I usually avoid that when I am not a regular maintainer. | 13:04 |
| POX_ | DktrKranz: seriously? LOL | 13:04 |
| persia | slytherin: we don't have maintainers in Ubuntu. Just do it :) | 13:04 |
| persia | slytherin: If you're not sure, ask someone else to review your change before you upload. | 13:04 |
| DktrKranz | POX_: yeah, I asked for blacklist, so it wouldn't have reappeared, but I had no luck. | 13:05 |
| slytherin | persia: geser already fixed it in lucid so I thought he might be interested in doing SRU. :-) | 13:05 |
| AnAnt | slytherin: I see you're interested in gnusim8085 btw | 13:05 |
| slytherin | AnAnt: interested in what way? | 13:05 |
| AnAnt | slytherin: aren't you the one who've been making the last couple of packages for it in Debian ? | 13:06 |
| slytherin | AnAnt: yes I am. Considering that I am primary maintainer upstream it seemed more natural. :-) | 13:06 |
| slytherin | AnAnt: We (upstream) could use help in completing Arabic translation. :-D | 13:07 |
| AnAnt | oh, I never noticed that | 13:08 |
| AnAnt | that's nice | 13:08 |
| slytherin | 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 |
| AnAnt | 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:09 |
| slytherin | AnAnt: Never mind. I thought you were working on translations. | 13:11 |
| AnAnt | Adnene knows arabic ? | 13:12 |
| AnAnt | hmm, never mind | 13:13 |
| iulian | hyperair: If that is the right thing to do, then yes, sure. | 13:25 |
| hyperair | 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 |
| hyperair | i'd just like to reconfirm that this dropping these changes is correct before i go ahead and do it | 13:31 |
| mok0 | hyperair: sounds sensible to me | 13:32 |
| hyperair | well then. i'll get to work =) | 13:32 |
| mok0 | hyperair: requestsync? | 13:32 |
| micahg | YokoZar: did you ever file that bug for pidgin-mbpurple? | 14:34 |
| === mcasadevall is now known as NCommander | ||
| persia | 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 :) | 14:44 |
| === AndrewGe1 is now known as AndrewGee | ||
| cemc | anybody any comments on bug #534261 ? | 14:51 |
| ubottu | Launchpad bug 534261 in pdns-recursor "Wishlist: new upstream version 3.2" [Undecided,New] https://launchpad.net/bugs/534261 | 14:51 |
| Rhonda | cemc: That one is not yet packaged in Debian and the release date is pretty short of a notice. :/ | 14:53 |
| cemc | Rhonda: too bad ;) does it need to be packaged in debian though? | 14:54 |
| Rhonda | 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 |
| Rhonda | So that no duplicate efforts happen in that respect. | 14:54 |
| cemc | got it | 14:56 |
| cemc | thx | 14:56 |
| Rhonda | cemc: I'm currently chatting with him. :) | 14:57 |
| cemc | sent a mail too | 14:58 |
| cemc | Rhonda: what's he saying? :) | 15:01 |
| cemc | how's the weather? :) | 15:01 |
| Rhonda | 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:07 |
| Rhonda | european time, I guess | 15:08 |
| cemc | Rhonda: cool, thanks! can you ping me if (news()) ? | 15:09 |
| Rhonda | cemc: And I'm not too sure if your PPA version is proper, does this take into account any possible Debian update? | 15:11 |
| Rhonda | cemc: About news, PTS subscribe to source uploads, http://packages.qa.debian.org/pdns-recursor :) | 15:11 |
| cemc | 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 |
| Rhonda | I have no clue, I guess it would work properly though. :) | 15:13 |
| cemc | Rhonda: I think if debian will have 3.2-1 that should be > 3.2-0whatever, right? | 15:16 |
| Rhonda | Yes, that's my thoughts too. :) | 15:16 |
| Rhonda | cemc: I think some non-maintainer update to the new upstream version might though use 3.2-0.1 | 15:17 |
| Rhonda | 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:18 |
| YokoZar | micahg: not just yet | 15:25 |
| micahg | YokoZar: there was a bug filed about the conflict | 15:25 |
| YokoZar | probably a result of my mailing list thread | 15:26 |
| micahg | no, an install bug | 15:26 |
| micahg | bug 530660 | 15:26 |
| ubottu | 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 |
| YokoZar | ahh, well there you are | 15:26 |
| micahg | YokoZar: do you want to take it and prepare teh debdiff? | 15:27 |
| duanedesign | reviewing some patches. looking for some help adding some man pages to a package | 15:45 |
| randomaction | duanedesign: what's the problem? | 15:47 |
| duanedesign | randomaction: do i just place them in a directory called for instance: debian/db4.2-doc.manpages | 15:48 |
| duanedesign | then make a patch? | 15:49 |
| randomaction | You can call dh_installman from debian/rules. It will install manpages listed in debian/PACKAGENAME.manpages, see "man dh_installman". | 15:51 |
| duanedesign | the pages were already written and attached to a bug report about the missing manpages. | 15:51 |
| duanedesign | randomaction: ahh. ok | 15:51 |
| duanedesign | randomaction: i messed around with dh_installman and wasnt getting it right :) | 15:51 |
| randomaction | *.manpages is a text file, not a directory | 15:52 |
| BlackZ | 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? | 16:07 |
| geser | BlackZ: does the new dependency enable a new feature? | 17:13 |
| imbrandon | morning all | 17:30 |
| geser | Hi imbrandon | 17:33 |
| === dpm is now known as dpm-afk | ||
| imbrandon | 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 |
| imbrandon | the reason i know its asleep is i can go in the other room and pound on the keyboard and it "wakes" | 17:42 |
| hyperair | imbrandon: are you sure it's really asleep, not just the screen? | 17:45 |
| imbrandon | there is no screen, nfs mounts lock and ssh access is dropped | 17:46 |
| hyperair | hmm | 17:46 |
| hyperair | i se | 17:46 |
| imbrandon | so i assume is asleep or hybernated, but i have no monitor on it | 17:46 |
| hyperair | weird. | 17:46 |
| hyperair | ssh in, check dmesg? | 17:46 |
| imbrandon | yea lookin at dmsg now, and syslog, nothing looks crazy though | 17:47 |
| hyperair | does dmesg say anything about PM | 17:47 |
| imbrandon | nah, some rpc stuff and other misc stuff | 17:47 |
| hyperair | and do you have X/some DE running? | 17:47 |
| imbrandon | no | 17:48 |
| imbrandon | gnome is installed, but gdm is off on boot | 17:48 |
| hyperair | if dmesg doesn't say anything about PM, then it definitely isn't suspending/hibernating at work | 17:48 |
| imbrandon | this box has been running for years, just upgraded it to 9.10 though and thats when this stuff happened | 17:48 |
| hyperair | some hardware-level crappiness perhaps? | 17:48 |
| hyperair | heh weird | 17:48 |
| hyperair | lemme see your dmesg anyway? | 17:48 |
| imbrandon | kk, lemme pastebin it | 17:49 |
| hyperair | imbrandon: hurry up before i pass out. i'm dead tired and need sleep. | 17:51 |
| imbrandon | heh pastin now, its a 200 line paste | 17:51 |
| imbrandon | http://imbrandon.pastebin.com/xa9PeTJM | 17:52 |
| hyperair | you should go get pastebinit | 17:52 |
| hyperair | it's as simple as dmesg | pastebinit | 17:52 |
| imbrandon | yea i have it on my desktops, but i try to keep this box minimal | 17:52 |
| imbrandon | lol | 17:52 |
| hyperair | er | 17:52 |
| hyperair | that's a very short dmesg | 17:52 |
| hyperair | has this box gone through suspend already? | 17:53 |
| imbrandon | yea, look about the time it says "link down" | 17:53 |
| imbrandon | thats when it was off | 17:53 |
| hyperair | what do you mean when it was off? | 17:53 |
| imbrandon | unreachable | 17:53 |
| imbrandon | ssh nfs etc | 17:54 |
| imbrandon | pound keyboard and it "wakes" | 17:54 |
| hyperair | imbrandon: i want dmesg *after* it wakes up. | 17:54 |
| hyperair | and mind, i can't find anything about eth1 link down apart from when eth1 is first discovered | 17:55 |
| imbrandon | yes thats a dmesg from both before and after | 17:55 |
| hyperair | which is 20 seconds into the kernel starting. | 17:55 |
| imbrandon | its awake now at the end of that | 17:55 |
| hyperair | what before and after?! | 17:55 |
| hyperair | you didn't do any strange stitching right? | 17:55 |
| imbrandon | hyperair, exactly, it dosent show anything in dmsg, thus my confusion | 17:55 |
| hyperair | if it dioesn't show anything your hardware is weird and doing things it shouldn't be | 17:56 |
| hyperair | because the kernel isn't suspending | 17:56 |
| hyperair | go downgrade and see if it happens | 17:56 |
| imbrandon | k | 17:56 |
| hyperair | like stick a live medium in | 17:56 |
| hyperair | liveusb/livecd | 17:56 |
| hyperair | an older one | 17:56 |
| imbrandon | yea a liveusb wont sleep, did try that | 17:57 |
| hyperair | huh | 17:57 |
| hyperair | weird stuff, that is | 17:57 |
| hyperair | just to check, do you have a /var/log/pm-suspend.log? | 17:57 |
| imbrandon | definatly, in my 4 years of ubuntu never had this issue | 17:57 |
| imbrandon | lookin | 17:57 |
| imbrandon | nope | 17:57 |
| hyperair | see, linux isn't doing the suspend. | 17:58 |
| hyperair | what machine is this? | 17:58 |
| imbrandon | x86 | 17:58 |
| imbrandon | 32bit | 17:58 |
| hyperair | did you tweak something in the bios? perhaps a hardware-level suspend-to-whatever that doesn't tell the kernel it's doing it | 17:58 |
| hyperair | i mean vendor/model | 17:58 |
| hyperair | not architecture. | 17:59 |
| imbrandon | ahh via c7 | 17:59 |
| hyperair | via? meh notorious rand. | 17:59 |
| hyperair | brand | 17:59 |
| imbrandon | no bios pm | 17:59 |
| * hyperair shrugs | 17:59 | |
| hyperair | go poke some people in #ubuntu-kernel | 18:00 |
| hyperair | maybe they'll know something | 18:00 |
| imbrandon | no worries, i'll dig a little more, thanks for tryin | 18:00 |
| hyperair | i honestly haven't seen a machine that can suspend-to-ram and come back without the kernel noticing. | 18:00 |
| hyperair | save for virtual machines | 18:00 |
| hyperair | those can do weird things. | 18:00 |
| imbrandon | yea its def strange, i'm wondering if the nic is just going to sleep and walkin on kbrd | 18:00 |
| imbrandon | but that would be strange too | 18:01 |
| hyperair | check the cpu fan | 18:01 |
| hyperair | hard disk | 18:01 |
| hyperair | umm | 18:01 |
| hyperair | leds? | 18:01 |
| imbrandon | what about leds ? | 18:01 |
| hyperair | don't they blink in some way when suspended? | 18:01 |
| imbrandon | and its fanless :) | 18:01 |
| hyperair | i know my desktop's power led blinked when suspended | 18:01 |
| hyperair | as does my notebook's | 18:01 |
| hyperair | bah. fanless. | 18:02 |
| imbrandon | ahh no power is solid the whole time | 18:02 |
| imbrandon | hrm | 18:02 |
| hyperair | i don't think it's actually going through any PM | 18:02 |
| hyperair | stick a monitor to it | 18:02 |
| hyperair | headless debugging is a pita. | 18:02 |
| imbrandon | heh easier said then done, sa i said its been runnin years, its in the attic ceiling | 18:02 |
| imbrandon | lol | 18:02 |
| * hyperair groans. | 18:03 | |
| imbrandon | :) | 18:03 |
| hyperair | can't you bring it down? | 18:03 |
| hyperair | it shouldn't be that huge a box, right? | 18:03 |
| imbrandon | yea i think that will be a weekend task | 18:03 |
| imbrandon | no very small | 18:03 |
| hyperair | yeah, see | 18:03 |
| imbrandon | like 10cm by 14cm | 18:03 |
| hyperair | just bring it down, stick it to a monitor | 18:03 |
| hyperair | i figured as much, when you said via c7 and fanless | 18:03 |
| imbrandon | but its very tucked away | 18:03 |
| hyperair | ouch | 18:04 |
| imbrandon | btw even fanless it runs like at 20c 99% of the time | 18:04 |
| imbrandon | love it so far, till now | 18:05 |
| imbrandon | lol | 18:05 |
| hyperair | imbrandon: a simple test: run a bash loop in a screen session calling date at 1-second intervals. if there is a lapse where it has "suspended" then you know it has really suspended. | 18:05 |
| imbrandon | hahahahahah yea did that | 18:05 |
| imbrandon | #!/bin/bash | 18:05 |
| imbrandon | for (( c=1; c<=1000000; c++ )) | 18:05 |
| imbrandon | do | 18:05 |
| imbrandon | echo "Garbage Busy Work $c times..." | 18:05 |
| imbrandon | sleep 1 | 18:05 |
| imbrandon | done | 18:05 |
| hyperair | while date; do sleep 1; done | 18:05 |
| imbrandon | LOL | 18:05 |
| hyperair | heh | 18:05 |
| hyperair | well that works too =\ | 18:05 |
| imbrandon | yea thought of that one | 18:05 |
| hyperair | imo mine's simpler | 18:06 |
| hyperair | and you get to see the actual lapse in seconds | 18:06 |
| imbrandon | its runs and counts, then "stops" about 1800 untill i pound the kbrd | 18:06 |
| imbrandon | then it resumes | 18:06 |
| imbrandon | like it never stoped | 18:06 |
| hyperair | use mine instead. | 18:06 |
| hyperair | check if there is a lapse. | 18:06 |
| hyperair | if there is a lapse of time, your timestamps will have a gap of more than one second | 18:06 |
| imbrandon | k | 18:07 |
| ScottL_ | can someone make sure I'm not doing anything brain dead for packaging a Plymouth theme (I've done some packaging before)? | 18:13 |
| imbrandon | hyperair, hah i found the issue, not to fix the problem | 18:13 |
| hyperair | ? | 18:13 |
| imbrandon | seems the nic goes to sleep ( realtek ) with the new drivers | 18:13 |
| hyperair | lol | 18:14 |
| imbrandon | s/not/now | 18:14 |
| hyperair | imbrandon: well, check if someone has bisected your issue. otherwise try compiling kernels and bisecting it =p | 18:14 |
| imbrandon | yup | 18:15 |
| === hannesw_ is now known as hannesw | ||
| fagan | directhex: you around? | 19:08 |
| fagan | Are you going to make an application indicator for banshee? | 19:09 |
| * fagan doesnt mind making a plugin for it | 19:10 | |
| jcastro | fagan: qense has one and has submitted it upstream | 19:11 |
| fagan | jcastro: nice I was wondering because its not in banshee for lucid | 19:12 |
| siretart | any kubuntu user around? in what package is the gtk style for qt application? | 19:12 |
| jcastro | yeah it's releasing this week sometime | 19:12 |
| * fagan loves low hanging fruit | 19:12 | |
| jcastro | https://bugs.edge.launchpad.net/ubuntu/+source/banshee/+bug/518171 | 19:12 |
| ubottu | Launchpad bug 518171 in banshee "Support Application Indicators" [Wishlist,In progress] | 19:12 |
| jcastro | if you want to test it and +1 it that would help | 19:12 |
| fagan | jcastro: any more that need porting | 19:12 |
| * fagan has some free time for some dev | 19:13 | |
| jcastro | lots in universe I am sure | 19:13 |
| jcastro | fagan: Deluge would be nice! | 19:13 |
| fagan | Deluge sure ill go have a look and report back :) | 19:14 |
| fagan | Oh and do I remove the current notification area stuff when I port it? | 19:15 |
| fagan | Or just comment it out | 19:15 |
| * fagan just realises he could do that in a plugin anyway dumb question | 19:16 | |
| jcastro | fagan: check the docks, it has a fallback mechanism for when indiscator session isn't running | 19:25 |
| jcastro | er, /docs/, not where boats live | 19:25 |
| fagan | Ah ok | 19:25 |
| jcastro | fagan: and remember it doesn't count until it's submitted upstream! | 19:26 |
| fagan | jcastro: could you help with that pretty please :) | 19:26 |
| fagan | Ill have a patch tomorrow | 19:26 |
| jcastro | fagan: https://bugzilla.gnome.org/show_bug.cgi?id=607800 | 19:27 |
| jcastro | easy example. :D | 19:27 |
| ubottu | Gnome bug 607800 in User Interface "Support for application-indicators/StatusNotifierIcon" [Enhancement,Unconfirmed] | 19:27 |
| fagan | Oh so I should just go to their bug tracker and say here, makes sense | 19:28 |
| * fagan doesnt push much bugs to projects that he doesnt know | 19:28 | |
| fagan | Patches not bugs | 19:28 |
| fagan | crap the deluge guys dont allow the public to submit bugs it seems | 19:30 |
| fagan | Ill just ask on their list | 19:31 |
| jcastro | fagan: make sure you link to the page on the wiki | 19:36 |
| jcastro | it has all the info they'll need | 19:36 |
| fagan | Yep will do | 19:36 |
| jcastro | persia: they made it! (mongodb) | 19:42 |
| === yofel_ is now known as yofel | ||
| lfaraone | if a new upstream version is only a bugfix release, do we still need a FFE? | 20:17 |
| sebner | lfaraone:Nope | 20:20 |
| directhex | what dictates the ordering with which cdbs does its "debian/rules binary" stuff? | 20:47 |
| james_w | directhex: the phase of the moon? | 20:48 |
| directhex | james_w, sigh, yeah, that's my best lead so far :( | 20:48 |
| james_w | directhex: but it's make that will decide that | 20:49 |
| james_w | so, it will take in to account any dependencies between binary/* rules and things that they refer to | 20:50 |
| james_w | and then parallelise things as well as it can within those constraints | 20:50 |
| james_w | and then serialise the rest | 20:50 |
| james_w | and I'm not sure if there are any rules to the serialisation | 20:51 |
| directhex | nice theory | 20:51 |
| directhex | binary-install/libubuntuone1.0-cil:: binary-install/libubuntuone-1.0-1 | 20:51 |
| directhex | why does the -cil package get done before the lib? | 20:51 |
| james_w | directhex: the binary part, or the binary-install part? | 20:53 |
| james_w | so | 20:53 |
| james_w | it may be that it is doing all the arch-dep stuff, then coming back for arch-indep? | 20:53 |
| directhex | james_w, i'd be happy if it was that way round | 20:55 |
| directhex | james_w, dh_clideps MUST be called after "dh_install -plibubuntuone-1.0-1". because cdbs calls dh_install individually for every binary, rather than just once. | 20:55 |
| soren | directhex: It'd be easier to help with a bit more context. Do you have the whole thing in bzr somewhere, for instance? | 20:56 |
| directhex | soren, i'll push what i have so far | 20:56 |
| soren | directhex: Cool. | 20:57 |
| directhex | lp:~directhex/libubuntuone/mono_packaging | 20:59 |
| directhex | your challenge, should you choose to accept it, is to make dh_clideps happen after debian/libubuntuone-1.0-1 has been filled with stuff, which is needed for libubuntuone1.0-cil_blah.deb to correctly have a dependency on libubuntuone-1.0-1_blah.deb | 21:00 |
| soren | directhex: You realise it doesn't say "binary-install/libubuntuone1.0-cil:: binary-install/libubuntuone-1.0-1" in there anywhere? | 21:02 |
| soren | I'm just saying.. | 21:02 |
| directhex | soren, yeah, i removed it since it didn't affect it | 21:02 |
| directhex | was leaving it unmolested rather than leaving non-functional attempts in place | 21:03 |
| * soren installs a million build-deps | 21:04 | |
| soren | give or take | 21:04 |
| soren | directhex: How can I tell that it failed? | 21:06 |
| directhex | soren, check the deps on the libubuntuone1.0-cil_blah.deb package, it should have libubuntuone-1.0-1 in there | 21:06 |
| soren | directhex: Ok. | 21:07 |
| directhex | soren, or check the build output for "dh_clideps: Warning: Missing shlibs entry: libubuntuone-1.0.so.1 or ubuntuone-sharp.dll for: ubuntuone-sharp.dll!" | 21:07 |
| soren | directhex: Alrighty. | 21:08 |
| c_korn | hello. can someone please check if this sync request is correct ? https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/533746 requestsync crashed but it created the bug report. | 21:13 |
| ubottu | Launchpad bug 533746 in scilab "Sync scilab 5.2.1-4 (universe) from Debian unstable (main)" [Undecided,New] | 21:13 |
| soren | directhex: I'm curious why you put dh_clideps in binary-install, though. | 21:24 |
| soren | directhex: It's very much like dh_shlibdeps, is it not? Just for mono? | 21:25 |
| directhex | soren, where should it go? i don't really understand what cdbs does when and why | 21:25 |
| soren | directhex: Is it equivalent to dh_shlibdeps? | 21:25 |
| directhex | yes | 21:25 |
| soren | directhex: dh_shlibdeps is in binary-predep/blah. | 21:25 |
| soren | bah | 21:26 |
| soren | binary-predeb, I mean. | 21:26 |
| * soren <3 cdbs | 21:27 | |
| directhex | soren, does that fix it? | 21:28 |
| soren | Haven't tried. | 21:28 |
| * mok0_ <3 cdbs too | 21:28 | |
| directhex | weirdos ¬_¬ | 21:29 |
| soren | directhex: A good trick if you're doing something like this is to look in the existing cdbs rules files for stuff that's similar to what you're doing. | 21:29 |
| soren | directhex: ...and put your stuff in a the same target. | 21:30 |
| directhex | soren, there's a lack of existing examples of cdbs-based mono bindings. a small number of libs, but not bindings | 21:30 |
| directhex | certainly not built at the same time as the dependent lib | 21:30 |
| soren | Well, in this case, the trick was to realise that dh_clideps does the same as dh_shlibdeps, and just mimic the behaviour around that. | 21:31 |
| directhex | soren, does that fix it? | 21:32 |
| soren | 22:28:41 < soren> Haven't tried. | 21:33 |
| soren | :) | 21:33 |
| soren | directhex: What does dh_cligacpolicy do? | 21:33 |
| soren | I doubt moving all of your existing binary-install/libubuntuone1.0-cil stuff to binary-predeb is going to be a good idea. | 21:34 |
| soren | the clistrip thing sounds like something you'd stick in binary-strip/blah | 21:34 |
| directhex | soren, nothing in this case, it's a noop unless there's a .cligacpolicy file | 21:34 |
| jdong | cd Documents | 21:38 |
| jdong | *grumble grumble* new theme active vs passive window contrast | 21:39 |
| soren | directhex: I've got other stuff to do. I hope I've helped you a bit. | 21:45 |
| directhex | i hope so too ;( | 21:46 |
| directhex | ta | 21:46 |
| directhex | doesn't help, as expected | 21:49 |
| soren | What did you change? | 21:49 |
| directhex | binary-predeb/libubuntuone1.0-cil:: | 21:50 |
| directhex | dh_clideps | 21:50 |
| RAOF | directhex: I recently touched launchpad-integration; that does libs+bindings together. Have you looked at it? | 21:51 |
| directhex | RAOF, no. that one had bad cli bindings too iirc? | 21:51 |
| RAOF | Yeah. I fixinated them, though. | 21:52 |
| directhex | ooh! | 21:52 |
| directhex | src package name? | 21:52 |
| RAOF | launchpad-integration, IIRC. | 21:53 |
| directhex | argh, wasn't finding it as i was on p.d.o :) | 21:54 |
| soren | directhex: um... | 21:54 |
| soren | $ grep -E 'dh_(install -plibubuntuone-1.0-1|clidep)' build.log | 21:54 |
| soren | dh_install -plibubuntuone-1.0-1 | 21:54 |
| soren | dh_clideps | 21:54 |
| soren | dh_clideps: Warning: Missing shlibs entry: libubuntuone-1.0.so.1 or ubuntuone-sharp.dll for: ubuntuone-sharp.dll! | 21:54 |
| soren | That's the order you wanted, right? | 21:54 |
| soren | dh_install takes care to move stuff from debian/tmp to debian/libubuntuone-1.0-1. | 21:55 |
| directhex | looks like it was dh_makeshlibs that i wanted first | 21:55 |
| directhex | RAOF, i notice you're using arch:any not arch:all | 21:58 |
| RAOF | directhex: That's an oversight on my part | 21:59 |
| directhex | RAOF, no joy :( | 22:02 |
| directhex | RAOF, can you take a look? | 22:02 |
| RoAkSoAx | when requesting a FFe sync request from debian, do I need to follow this exactly? https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze for new upstream versions or that's only when the package its been updated in Ubuntu (not syncing/merging) | 22:07 |
| lifeless | RoAkSoAx: new up stream is new upstream | 22:20 |
| RoAkSoAx | lifeless, so that means its only for packages that are new upstream versions that someone packages and does not sync from debian | 22:22 |
| lifeless | no, it means that it includes a sync of a new upstream from debian | 22:22 |
| lifeless | its a new upstream either way | 22:22 |
| RoAkSoAx | oh ok :) | 22:23 |
| directhex | argh | 22:36 |
| RAOF | directhex: I'll add that to my todo. | 22:47 |
| directhex | RAOF, if you're not immediately available, i'll keep hacking at it. it's holding up an upstream upload | 22:49 |
| RAOF | I'm going back to hacking f-spot. If you get frustrated further I'll give it a look. | 22:50 |
| directhex | i'm reading cdbs source | 22:52 |
| RAOF | Uuurgh. | 22:52 |
| directhex | i got it ._. | 22:58 |
| directhex | by jove, he's got it! | 22:59 |
| directhex | jono, break out the champagne! | 22:59 |
| jono | directhex, eh? | 23:01 |
| Beaver | www.search2.net (new search engine) | 23:02 |
| directhex | jono, i've been fighting with cdbs for days to make the mono u1ms bindings package work | 23:02 |
| jono | ahhh right | 23:03 |
| jono | :) | 23:03 |
| directhex | i can get a working banshee u1ms into testers' hands within 24 hours of this hitting the archive | 23:03 |
| RAOF | directhex: Thank you for being awesome! | 23:13 |
| directhex | i need a nap | 23:13 |
| directhex | and/or more rum | 23:13 |
| RAOF | directhex: You're not going to be at UDS, are you? Otherwise, I could buy you a beer :) | 23:57 |
| directhex | RAOF, can't. scheduling conflict | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!