[00:16] Hi all [00:27] Laney: is #227505 reproducible for you in a current daily live of 10.04? === jtechidna is now known as JontheEchidna [00:43] I found a script to tell me the depends and build-depends from the source... but I lost it, anyone know where to find it? I've googled for ages! [01:07] Greetings, people of #ubuntu-motu! [01:16] What does this mean? http://thread.gmane.org/gmane.linux.ubuntu.motu/6441 [01:16] (Seen on lwn.net's Distribution page this week.) [01:16] Oh I guess I should read the referenced articles about ongoing discussion... [01:19] Huh. Interesting [03:00] hi all, while doing a merge, I find this one file present in Ubuntu but not in the Debian package, the changelog for debian doesn't mention about this file, so what's the best course of action here, keep that file or remove it [03:21] dhillon-v10: The best course of action is always to understand what things do, and make your best determination as to whether it should keep being done. What is the file in this case? [03:28] persia: thanks for the reply, the file is called: libecryptfs0.shlibs and it contains: libecryptfs 0 libecryptfs0 (>= 77) [03:28] persia: that's it [03:28] persia: bzr gives me this: Contents conflict in debian/libecryptfs0.shlibs [03:29] persia: but there's no marker in that file to cause a conflict [03:29] Right. Read the dh_makeshlibs manpage [03:29] persia: okay, just a minute [03:31] persia: so basically look for: dh_makeshlibs in the rules and if its there then i keep that file, because it basically contains the shlibs, and if its not there (which is the case) I can remove that file right? [03:31] No. [03:32] So, if dh_makeshlibs isn't there, then that's its own problem, because you're dealiing with a library. Note that dh_makeshlibs is implied by dh(1) or cdbs. [03:33] If it is there, then you might want to check the common ancestor to see if it was there before, or whether it's really an Ubuntu addition (you may also be able to check this from patches.ubuntu.com, depending). [03:33] persia: alright, I'll check patches.ubuntu.com [03:33] Also, you might try building the package, and see if the binary shlibs files differ with and without that file, and also inspect the binary packages produced by recent uploads. [03:34] (because dh_makeshlibs can generate one from scratch under some conditions). [03:35] Your target goal should be to make sure that the binary packages (especially the -dev package) are constructed in such a way that other packages build-depending on the library on which you are working get the correct run-time dependencies from ${shlibs:Depends} [03:35] You may or may not need to preserve (or modify) that file in order to reach this goal. [03:35] persia: yeah you are right, the file is indeed an ubuntu specific change, so I'll have to keep it :) [03:36] persia: the patch says that [03:37] dhillon-v10: Note that you may have to modify it, if the ABI has changed. [03:38] persia: so is that the cause of the contents-conflict bzr is giving, an outdated file [03:38] I've no idea about that. I can only tell you about the contents of the packages. [03:48] i was trying to build libtspi and i get this error... http://pastie.org/799908 [03:48] persia: another question: the po stuff that shows up in the diff should be removed right, the patch right now looks really long, because a major change was the formatting of changelog and control files [03:48] what does this even mean? [03:48] dhillon-v10: Best to ask questions generally. Someone else may have a faster or better answer. [03:49] another question: the po stuff that shows up in the diff should be removed right, the patch right now looks really long, because a major change was the formatting of changelog and control files [03:49] That said, Debian translations are preferred except in special cases (which would be noted in the changelog). In cases where there are translations changes, it is important to migrate only the translations that are intentionally changed, and otherwise keep the Debian translations. [03:50] wrapster: Check your build-depends. If that doesn't work, try regenerating the autoconf stuff (but I think that's happening at build-time, from your log). [03:57] hi, i am searchin' for advocates for my rhythmbox plugin, please help me. http://revu.ubuntuwire.com/p/rhythmbox-radio-browser [03:59] persia: there were no buid-depends issues. [04:00] yet i still get the same error [04:00] wrapster: You're sure the desired version of all the libtool related stuff is being installed during the build? [04:00] If so, you may have to relibtoolise (which is something I've not yet mastered), or it may be something else. [04:03] persia: i just saw and one of the chid pkgs, has a dependency on libssl-dev. [04:03] and thats not installed [04:04] I doubt that's the cause of issues with LIBTOOL definition. [04:04] That might be another issue though :) [04:04] yeah.. its not.. it was my mistake.. thats already installed. :) [04:09] persia: well this is what i want... Im trying to build the 64bit version of libtspi.so [04:14] persia: reading across google seems to tell me i might need to have automake >=1.9 and i do have it. [04:15] yet i dont really understand about this issue.. could you please help me/ [04:17] wrapster: I don't know anything beyond that included in your paste. It appears AC_PROG_LIBTOOL isn't defined. All I can suggest is investigating other build logs (especially ./configure output from a successful build of libtspi), and either following the advice from the error messages or something else. [04:17] It may be that aclocal and autoconf aren't being run for some reason (if AC_PROG_RANLIB and AC_PROG_LIBTOOL are defined), or it may be something entirely different. [04:18] I know lots about packaging and debugging crashes, but I only have a passing knowledge of autotools, and that mostly by running stuff and seeing the effects, rather than from any comprehensive source. [04:19] (and asking please doesn't make me any more able to help you :) ) [04:41] persia: yeah i know.. but thats just courtesy. [04:41] ;) [04:43] makefiles are ugly.. [04:43] Why? [04:44] persia: I can't get my head around this thing at all [04:44] This is because of an aesthetic concern, or something else? :) [04:44] partly that possibly - I'm trying to fix up an itty bitty make file; it doesn't like me [04:45] How are you trying to fix it? [04:45] lemme pull up the vm [04:46] I decided to do any development in a vm only [04:46] http://paste.ubuntu.com/364991/ [04:47] I know there should be an uninstall: - I don't think it needs a clean: but should probably have one [04:47] OK. Which bit hates you? [04:47] beyond that - I'm clueless [04:47] I'm beed reading this - http://www.gnu.org/software/make/manual/make.html - and just getting confused [04:47] make is an immensely powerful tool, and so confusing :) [04:48] The install: isn't right - I know that [04:49] It's mostly right. Use `install -m 644 -D` instead of cp for the manpage, and `install -m 755 -D` instead of cp for the binary. [04:49] If anything the man should be gzipped and sent to /usr/share/man/man1/lal.1.gz [04:49] Also, you probably want to install to ${DESTDIR}/bin or ${INSTALLDIR}/bin or something, rather than /usr/bin [04:49] Same for the manpage. [04:50] Or, if you just want the makefile to play nice with a standard debian/rules, install to ${DESTDIR}/usr/bin and ${DESTDIR}/usr/share/man/man1 [04:52] If you want to be fancy, you could use ${DESTDIR}/${PREFIX}/bin and ${DESTDIR}/${PREFIX}/share/man/man1 and add a PREFIX ?= usr/local somewhere earlier (which you'd then override in debian/rules with PREFIX := usr) [04:53] any reason I'd do that over the other option? [04:53] Your all: rule definitely isn't right. all: should generally not have any specific activities, but rather just depend on other rules. You might add a lal: rule, and have all: depend on lal: [04:54] The fancy way I described installs into /usr/local/* (unless overridden) for a local make; make install, and installs to ${DESTDIR}/usr/* if PREFIX is overridden in debian/rules, thereby building the package you want. [04:55] how do I override that? [04:55] Other tricks that might be useful would be things like CFLAGS ?= $(shell pkg-config x11 xft --libs --cflags), and then using ${CFLAGS} in your calls. [04:55] If you want to be fancy, you could use ${DESTDIR}/${PREFIX}/bin and ${DESTDIR}/${PREFIX}/share/man/man1 and add a PREFIX ?= usr/local somewhere earlier (which you'd then override in debian/rules with PREFIX := usr) [04:55] sorry [04:56] No problem: it's just easier for me to quote myself than retype :) [04:57] actually, for CFLAGS, you'd probably want += rather then ?=. That way you can take advantage of any extra cflags that get defined somewhere else. [04:57] so in rules: %: PREFIX ?= usr/local dh $@ [04:57] No. [04:57] Put your variable defintion above your rules. [04:58] oh - you said put that part in the makefile - override in rules [05:00] hmmm no RAOF tonight [05:00] so in deb/rules I have PREFIX = usr/bin ? [05:00] persia: (or anyone else), mind taking a quick peak at this: http://mythbuntu.pastebin.com/d306a3b3d [05:00] rhpot1991: It's best to just ask a question. Whoever happens to be around will probably answer. [05:01] oh wait, I think I see my issue [05:01] persia: ignore me till I fix a path issue [05:01] rhpot1991: I don't see the point of a manual postinst: read the dh_makeshlibs manpage [05:01] Also, install the file to libfoo.so.n and the link to libfoo.so [05:02] MTecknology: I'd probably use "export PREFIX := usr", but it might work without all the syntactic sugar. [05:03] You don't want usr/bin, because you're using ${DESTDIR}/${PREFIX}/bin/ so you already have the "bin". [05:04] so export pre.... goes after %: in deb/rules ? [05:04] Before. [05:04] Actually, if you use "export PREFIX := usr", it doesn't matter, but the convention is to define the variables before the rules. [05:05] ok [05:05] so how do I require something else? [05:05] in the makefile [05:06] How do you mean "require"? [05:06] inside all: require lal: [05:07] "all: lal" [05:07] That means the all: rule depends on either the lal: rule or the lal file. [05:08] (typically rules are named after the files they generate. For other types of rules, there'S the special .PHONY: rule which one uses to indicate make shouldn't check files. For more information, read about .PHONY in the make manual) [05:08] and lal: is where I build thing? [05:08] The lal: rule should create the lal: binary. [05:09] and and for lal.1? the man page [05:09] since it will need to be gzipped [05:10] You could create a lal.1.gz: rule for that. [05:10] If you did, you probably want your install: rule to depend on lal and lal.1.gz [05:11] persia: let me run this by you then, upstream wasn't including any soname data at all, I'll be submitting a patch for this. In their build process they reference libhdhomerun.so directly. Can I handle the symlinking myself in the packaging, or does this need to be done at the build phase? [05:12] rhpot1991: You can handle it in the packaging if you like. If upstream isn't including SONAME data, I strongly encourage you to create a symbols file to track ABI shifts. [05:12] dh_link is probably interesting. dh_install can't rename files, so you'd have to do that in debian/rules directly. [05:13] what does Provides: mean in the control file? [05:13] persia: so if you run 'make' will that do what's in all: ? [05:13] Yes. [05:14] and in the install command, how do I specify the source I'm moving? [05:14] persia: happen to have a link or anything a symbols file? [05:15] install -m 755 -D ${DESTDIR}/${PREFIX}/bin/ lal [05:15] !symbols [05:15] Hrm. [05:15] https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols [05:15] MTecknology: man install :) I'll give you make syntax, because programming language manuals are tricky, but simple commands are easy :) [05:16] I wasn't aware of an install command :P [05:17] Looks like I want this - install -m 755 -D ${DESTDIR}/${PREFIX}/bin/ lal lal [05:18] I know one way to know for sure :) [05:19] heh :) [05:21] yup - that was wrong [05:21] Maybe drop one of the spaces? [05:22] persia: whats the proper way to handle this whole issue, currently their makefile just inserts empty soname data, I have modified this to insert some real data but now my link are backwards, should the makefile handle the linking or should everything build off the full soname file version? [05:23] persia: I thought I was supposed to have a space after the -D /dir/ because it said that sets up everything except the last piece in man install [05:24] rhpot1991: In an ideal world, the upstream makefile will build shared library into a versioned binary. My personal preference when this doesn't happen is to wangle this in debian/rules and add a symbols file, but patching the upstream makefile is arguably more correct because it produces a patch one can send upstream. [05:25] MTecknology: install [OPTION]... [-T] SOURCE DEST [05:26] persia: install -m 755 lal ${DESTDIR}/${PREFIX}/bin/lal worked [05:26] I'm lost with the -D [05:27] google isn't nice in finding examples :P [05:27] something about a command being called install [05:27] -D creates any directories that didn't exist. Like mkdir -o [05:27] Err, mkdir -p [05:27] It's a *good* name. The command installs stuff. [05:27] oh [05:28] .... that makes much more sense when I read it now [05:28] I didn't say it's a bad command - but it's a hard one to search for [05:29] so install -m 755 -D ${DESTDIR}/${PREFIX}/bin/ ./lal ${DESTDIR}/${PREFIX}/bin/lal [05:29] or w/o the ./ probably [05:32] I try that and I get install: target `/usr/bin/lal' is not a directory [05:33] MTecknology: Are you root? [05:33] ya [05:33] And you had the -D? [05:33] Oh, I see the issue. [05:34] read the very first line of the summary in the manpage again. [05:34] DOH! [05:34] OK! [05:34] -D takes no arguments [05:34] * MTecknology facepalm at man page [05:35] sorry for missing that [05:37] alrighty - I'm guessing I should be able to start a new terminal session - make; sudo make install [05:37] nope [05:38] I thought lal and lal.1.gz after all had their own lines - I guess not [05:38] paste your Makefile again? [05:39] http://paste.ubuntu.com/365006/ [05:39] little different now [05:39] Right. all: typically wouldn't depend on lal.1.gz [05:39] install: needs to depend on the stuff it's copying. [05:40] Drop the export line from install, you want just "PREFIX ?= usr/local" at the top (above all:) [05:40] oh.. does the user still needto do make before make install? [05:40] Right now, yes, but if you follow my advice above, no. [05:41] ok; I always that that was the norm :P [05:41] It is, but that's for entirely different reasons. [05:41] ok, should I just have all: lal [05:42] then install: lal lal.1.gz ? [05:42] You can leave all: alone or not, as you like, but if you don't specify the dependencies in install, you are prone to errors. [05:42] ok [05:43] Also, you're installing by default to /usr/local/usr/bin : is that what you want? [05:43] I dropped /usr from that [05:44] I can only critique what I see :) [05:44] http://paste.ubuntu.com/365009/ [05:44] I meant because you said it - just letting yoy know I listened [05:46] heh - 'make' doesn't want to do anything now [05:46] and I see why :P [05:46] That's why you want a clean: rule :) [05:47] just an rm command? [05:48] and depend on clean? [05:49] No. [05:49] A clean: rule. clean: rules typically contain lots of "-rm " lines. [05:50] -rm ? [05:50] I know "rm" but "-rm".. [05:50] I just tossed this together now - http://paste.ubuntu.com/365013/ [05:50] apparently wrong :P [05:52] persia: sorry for trying to jump into this with apparently very little knowledge - I thought I knew enough to be able to do better than this [05:52] nice big learning curve that I'm hoping to overcome someday [05:52] RAOF: hi - somebody was looking for you [05:52] 23:00 < rhpot1991> hmmm no RAOF tonight [05:53] Two recommendations. 1) prefix any line you don't care about succeeding with '-'. This is useful in case you want to, for example, run `make clean; make clean`. 2) don7t bother with all the ./ entries. make knows where it is. [05:53] I hit up persia all good :) [05:53] ok [05:53] rhpot1991: Hah. [05:53] But I'll leave the rest of it to either the make manual or someone else :) [05:54] persia: thanks - I'll try out this sexxy beast now [05:54] Oh, one last bit: install depending on clean: means that the stuff will always be deleted before being installed. [05:54] I'll not do that if that's bad [05:55] Well, generally you need to not delete the things that you're about to try to install :) [05:55] err - I was thinking depend on uninstall [05:55] which I guess isn't needed [05:56] I thought -D created a directory if not exists [05:57] It doesn't want to isntall lal.1.gz [05:58] Is that something that shouldn't have ${PREFIX} in it? [05:58] just ${DESTDIR}/usr/share/man/man1/lal.1.gz [06:00] -D create all leading components of DEST except the last, then copy [06:00] It should make that part - not complain [06:02] persia: thats for putting up with me again - I have the ITP filed too - so it's probably figure out a few tiny things on my own - then take the peoples suggestions - then actually submit to debian and file RFS :D [06:02] persia: I appreciate all the help and holding my hand [06:02] RAOF: thanks for your help too :) [07:46] How can I allow 2 individuals full read/access to my bzr branch? (https://code.launchpad.net/sch-scripts) [08:02] good morning [08:22] G'morning Daniel. [08:28] hiya iulian [08:30] this feels stupid :) [08:30] https://bugs.launchpad.net/ubuntu/+source/gnome-do/+bug/513802 [08:30] Ubuntu bug 513802 in gnome-do "Please sync gnome-do 0.8.3.1+dfsg-1 from debian sid" [Undecided,Incomplete] [08:30] and 1 hour after it, the FTBFS got fixed :) [08:47] crimsun: (re #227505) No, I don't see that any more, but (on a dist-upgraded system, not a live cd) I'm having to toggle mute to get any sound output [10:10] I am having a problem with finding the copyrights of a tarrball I downloaded [10:11] om26er: isn't there any COPYING or LICENSE file? [10:11] om26er, that's usually not a great sign. have you tried contacting the upstream developer? [10:12] slytherin, yes copying file is there [10:12] om26er: then what is the issue? [10:13] slytherin, what should I look for in there? copyrights change with time [10:13] om26er: Wait a minute, are you looking for license or copyright owners? [10:14] I mean copyright holders for the code. [10:14] slytherin, copyright ownsers [10:14] ya [10:14] is there AUTHORS file? [10:15] slytherin, yess [10:15] am looking [10:15] om26er: doesn't it list copyright holders? [10:16] slytherin, no it dont [10:17] om26er: Another option. a bit manual and lengthy. Check headers of source files. grep for word Copyright in the source files. [10:38] I got this error http://pastebin.org/83882 while building [11:18] please help I am getting the error when building dpkg-buildpackage: error: debian/rules build gave error exit status 2 [11:32] om26er: That is merely the consequence of an earlier error [11:33] maxb, did I do something wrong? [11:40] You'd need to pastebin more of your build log for people to help [11:46] maxb, terminal log? [11:46] yes === Knightlust is now known as Igorots [11:57] If a source comes in several different packages, i.e. 1..the source for a program, 2..the data, 3.....the sounds ... can these be packaged separately and depend on each other without any problems? [11:57] here is the terminal log http://pastebin.org/83897 [11:58] Hi om26er :) Congrats on your Bug Control application [11:58] xteejx, thanx :) [12:09] xteejx: Sure why not. In fact the new source format 3.0 allows different upstream tar balls to be combined together. [12:09] Oh wow ok :) [12:10] xteejx: If you want to package it old way you will have to create 3 different source packages. Otherwise use 3.0 format - http://wiki.debian.org/Projects/DebSrc3.0 [12:10] Cool, thanks slytherin [12:43] * directhex wonders if he owes bddebian cake === Igorots is now known as Knightlust [15:04] FTBFS: https://launchpad.net/ubuntu/+source/ogre-contrib/1.6.4-1/+build/1350584 - builds fine locally on i386 [15:10] The error seems to be the autobuilder did not install nvidia-cg-toolkit, whereas locally it was fine. [15:10] dholbach: ^ [15:10] I have no idea [15:10] xteejx: but maybe somebody else can - I need to sort out a few other things [15:10] No probs Daniel [15:11] Anyway, I checked the control file and everything seems fine there, may have just been a quirk [15:12] hi! is there a standard way to rename a file in a debian/patches patch? If I use cdbs-edit-patch, then rename the file directly, the resulting patch I get shows a complete removal and add of a new file, which is way more noisy than I want [15:39] final day of https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 22 minutes in #ubuntu-classroom on irc.freenode.net (first up: "Writing Beautiful Code") === yofel_ is now known as yofel [16:20] james_w, Heya. Hey one quick question. While doing 'bzr builddeb' i get an error 'bzr: ERROR: [Errno 2] No such file or directory:' on a patch I deleted. How to override or what i can be doing wrong? [16:23] RoAkSoAx: did you tell bzr that the patch got removed? (bzr remove) [16:24] geser, nope, but indeed that was the problem :) thanks :) === nxvl_ is now known as nxvl [16:35] hi, I'm reviewing zope.annotation (http://revu.ubuntuwire.com/p/zope.annotation) it says priority: extra [16:35] it should be 'optional', right? [16:44] highvoltage: unless in conflicts with something or depends on "extra" package [17:01] * jdong unamusingly glares at VMWare [17:01] which just told me that a snapshot's size ranges anywhere from 768MB (RAM size) to 10.5GB (disk+RAM size) === asac_ is now known as asac [17:39] hi, i am trying to build a deb of gcc-4.4.3 for karmic. the folder created by apt-get source does't contain the source directly, but a tarball ... when trying to build the package, dpkg-source complains, that the binary file content changed ... any idea, what i am doing wrong? [17:42] hey all [17:43] so this probbaly isn't the correct channel [17:43] but I'm coding a daemon [17:43] tim, how are you trying to build it? [17:43] but I have no idea how to package/run/instlal/debainise it [17:44] fabrice_sp, with git buildpackage [17:44] (eg, where to install, init.d scripts, how to make a pkg for it, etc) [17:44] !packaging | daurnimator [17:44] daurnimator: The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports [17:44] tim, if you have the source locally, you should use debuild -b [17:45] fabrice_sp, i will give it a try [17:58] hi, i am searchin' for advocates for my rhythmbox plugin, please help me. http://revu.ubuntuwire.com/p/rhythmbox-radio-browser [18:01] segler, version should be -0ubuntu1 [18:02] also, why do you need a dir file? [18:03] otherwise, looks good. I'll have a deeper look later [18:12] Laney: which mixer element(s) do you need to unmute? [19:09] how can I close a few bugs in debian/changelog? [19:09] (LP: #bug, #bug2) ? [19:10] ari-tczew: If one change closes multipe bugs shouldn't they be marked as duplicates? [19:11] ari-tczew: if the bugs are related but not the same and are closed by the same fix I belive you can do as you said - (LP: #bug1, #bug2) [19:11] like so, but I want to know [19:12] ari-tczew: if the bugs in question have exacly same problems I would mark one of them as duplicate and close only one [19:12] sebner, how close to done is longomatch? all its build-deps are transitioned, so sponsorship is running at full speed again [19:13] quintasan, statistic mate ;) [19:13] directhex: hmm, I wanted to wait for new upstream version but if you give me some minutes it's ready for now too [19:14] sebner, well, it's RC you see... and stuff is being pulled into lucid by an eager seb128 too. we're almost done \o/ [19:15] directhex: heh, ok. then give me some minutes. I'll make it ready then [19:15] Quintasan, btw. would you like to take sponsor now? [19:15] sebner, it seems to work fine against db4o 7.4, thankfully [19:16] ari-tczew: uh sure, where I can get the diff? [19:16] directhex: haven't tested that yet. Yesterday db4o was still untransitioned so I didn't bother doing testing [19:17] Quintasan, bug 255360 [19:17] sebner, a sexy ftpmaster (i guess bddebian) has been clearing things though NEW, which was running reasonably quickly anyway [19:17] Launchpad bug 255360 in liblo "[lucid] Please update liblo to 0.26 version" [Wishlist,New] https://launchpad.net/bugs/255360 [19:17] directhex: heh, yeah he's great :) [19:22] ari-tczew: well, builds fine, let me check debian/ then :P [19:22] sure [19:24] directhex: I'll give it a testbuild now, I'll tell you when ready for sponsoring [19:26] ari-tczew: I like it, builds fine and I didn't find any problems :) [19:27] Quintasan, cool, would you like take sponsor on other bugs? [19:27] with debdiff now [19:28] well I have time so no problem [19:28] it would be good if someone else could review it too [19:31] Quintasan, go ahead bug 514453 [19:31] Launchpad bug 514453 in pyalsaaudio "Merge pyalsaaudio 0.5+svn36-1 (universe) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/514453 [19:33] ari-tczew: this one is fine with me too [19:33] if anyone's around for reviewing some zope packages so that we can get schooltool back in ubuntu, there's just two left that needs reviewing: [19:33] http://revu.ubuntuwire.com/p/zope.server [19:33] http://revu.ubuntuwire.com/p/zope.size [19:47] ScottK: hi Scott -- reminder: we've been sitting on libtifiles/libticalcs for a couple weeks now. :-) [19:47] kamalmostafa: It's pretty near the top of my Ubuntu TODO at this point. [19:49] ScottK: sounds good. [19:57] <_stink_> anyone know of a way to have dpkg (or some other debian packaging magic thing) (1) check whether a .deb's dependencies are already installed, and (2) return an error to the shell if not? [19:57] <_stink_> --no-act doesn't seem to care about whether depends are installed. [20:04] Hi everyone! Anyone up to advocate/review qt-shutdown-p? - I corrected the desktop file, the copyright file and the docs file as jcfp asked. http://revu.ubuntuwire.com/p/qt-shutdown-p [20:05] hakaishi: I know you've been asking a long time. You might consider asking the Debian qt-kde team if they are interested and if they are, get it into Ubuntu via Debian. See #debian-qt-kde on OFTC. [20:06] _stink_: you could use "gdebi --quiet --aptline $package.deb" and check if it lists something or not [20:08] <_stink_> geser: omg. that is awesome. [20:08] <_stink_> i owe you a beverage should we cross paths. [20:09] hakaishi: it's good, I think if you go to Debian they should be fine with it [20:09] <_stink_> crap, i didn't even know about gdebi. [20:10] ScottK: I thought, I get advocations only if there are no issues with the package. And since there no longer are, I thought I'll ask for it now^^ [20:10] hakaishi: I haven't been following the details of your package, I've just been noticing you've been asking for a while. [20:12] ScottK: Everything should be okay with the new upload. The others weren't okay because of copyright and the rules file or such [20:12] hakaishi: AFAIK it would be better to get it to debian, if you want to change it just get a newer version to Debian and request a sync, both projects will gain something :) [20:14] On which server does #debian-qt-kde run? - I mean the exact address [20:14] hakaishi: irc.oftc.net I belive [20:15] okay, thanks [20:17] Is there a website for debian-qt-kde like revu.ubuntuwire.com? [20:18] hakaishi: hmm I think you can upload to mentors.debian.org [20:24] Thank you, maybe I will try to get it into debian, maybe not. I'll see tomorrow. Bye bye [20:34] hi [20:35] Hi [20:35] on my kubuntu lucid installation the package soprano-daemon is installed [20:36] it is made dependent on virtuoso-server today / yesterday to fix https://bugs.launchpad.net/bugs/505653 [20:36] Ubuntu bug 505653 in soprano "make soprano depending on virtuoso-opensource" [Undecided,Fix released] [20:37] kpackagekit shows that soprano-daemon is dependent on it, but still virtuoso-server is not installed automatically [20:37] is that a bug? [20:38] Depends or Recommends like the changelog says? [20:39] Recommends: virtuoso-server (>= 5.0.12-0ubuntu3), ... [20:39] geser: oh, then that's the problem [20:39] geser: but that's wrong [20:40] wind-rider: Probably better to ask in #kubuntu-devel. [20:40] ScottK: ok, I'll do that [20:40] virtuoso should be installed by default and not as an option [20:40] usually Recommends are auto-installed like Depends [20:41] but I don't know how kpackagekit behaves at it [20:42] fabrice_sp: ping [20:51] directhex: ready for sponsoring :) [21:03] geser: thx, i discussed it at #kubuntu-devel [21:04] and added a comment to the bug report [21:12] Hi , How Gnome-do can shutdown without requesting passwird [21:12] *password [21:14] sebner, ta, i'll take a peek & upload once dinner is eaten [21:15] directhex: great, thx. Just ask if you have any questions [21:20] fabrice_sp: could you check if zshdb builds for you? It FTBFS on buildd but builds fine in pbuilder. (bug 514359) [21:20] Launchpad bug 514359 in zshdb "zshdb-0.03+git20090920 FTBFS" [Undecided,New] https://launchpad.net/bugs/514359 [21:20] randomaction, sure [21:21] maybe it only manifests in sbuild [21:22] would someone mind looking at zynjacku package in REVU ( http://revu.ubuntuwire.com/p/zynjacku ) ? [21:23] randomaction, I also installed some 'checking' packages (don't remember the name), that are responsable of some FTBFS in hte buildd [21:23] so let see what happens [21:24] ScottK, you should update the Maintainer field [21:24] wrong nickname [21:26] ScottL, also some comments in copyright (# Please also look if there are files or directories which have a [21:26] # different copyright/license attached and list them here. [21:26] ) [21:26] argh. got idsconnected [21:27] sebner, seems to build fine [21:27] directhex: sure, I (at least) fiXX0red the build :P [21:27] randomaction, FTBFS [21:28] sebner, well, gotta check these things! [21:28] FAIL: test-tbreak [21:28] who can accept packages that are in queue ? :) [21:28] dupondje, do you mean NEW? [21:28] source format 3.0? sod it, i'll upload anyway [21:28] https://launchpad.net/ubuntu/lucid/+queue here ... [21:28] fabrice_sp_: you said that ScottK should update the Maintainer field...did you mean ScottL (me) ? [21:29] yes. Sorry [21:29] your nicks are very close :-) [21:29] dupondje, archive admins [21:29] yeah, it's been problematic sometimes [21:30] :-D [21:30] fabrice_sp_: ok, so reproducible in sbuild [21:30] fabrice_sp_: thank you [21:31] ScottL, you should also reviewyour copyright: you have sources with LGPL and different people [21:31] randomaction, yw ;-) Do you want me to do more tests? [21:34] directhex: Yeah, I asked you 3 weeks ago (if you remember) and you didn't say to have a problem with it, else I just have to find someone else [21:36] Quintasan, did you check rdepends for liblo? [21:38]