[08:54] Hello. [08:54] If a new release of a program is made, that only includes bugfixes, does it have any chance of making it in for oneiric? === bulldog98_ is now known as bulldog98 === warp11 is now known as warp10 [09:55] I have a package which installs a program that runs on user logon. So when a user installs the package, he needs to logoff/logon for my invisible (no gui) user-session-based "service" to run from /etc/xdg/autostart. [09:55] Does the packaging policy allow me to run it from postinst as the SUDO_USER, if I detect that that env var exists, and X is running? === almaisan-away is now known as al-maisan [10:22] alkisg: I don't think that would be desireable === al-maisan is now known as almaisan-away [10:45] Thank you tumbleweed, I'll put a note for the users to the docs that they need manually start it or logoff+logon === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [13:01] tumbleweed: housten, we've had a problem: https://launchpadlibrarian.net/82843129/buildlog.txt.gz [13:02] *Houston ;) [13:06] bdrung: yeah, noticed that [13:13] tumbleweed: the typo or the build failure? ;) [13:20] bdrung: the build failure, hadn't got as far as the typo [13:23] tumbleweed: any idea how to solve this build failure? [13:26] not immediately obvious, and I can't look right now [14:12] bdrung: ah, that was easy. The new binary packages are in NEW [14:14] :) === Elbrus_busy is now known as Elbrus [14:30] wgrant: could you upgrade this page http://qa.ubuntuwire.org/multidistrotools/all.html to precise? [14:32] http://packages.ubuntu.com/search?suite=default§ion=all&arch=any&searchon=names&keywords=sphinx2-bin [14:32] sphinx2-bin isn't in Oneiric. what' the process for getting it in? (I am assuming I can port the natty version forward) [14:54] CarlFK: https://launchpad.net/ubuntu/+source/sphinx2/+publishinghistory [14:57] tumbleweed: thanks. how do I find out why Status=deleted ? [14:57] click on the arrow and you can see :) [14:58] low popcon ? [14:59] any idea where I can see Debian bug #624817 (no the lp bug that it links to) [14:59] Debian bug 624817 in ftp.debian.org "RM: sphinx2 -- RoQA; orphaned, low popcon, outdated" [Normal,Open] http://bugs.debian.org/624817 [14:59] thank you happy robot [14:59] thanks ubottu [15:01] grumble. but thanks. [15:01] CarlFK: you can take over maintainance of it in debian [15:04] joy === Elbrus_busy is now known as Elbrus [18:45] hello, the compilation of pragha fails because of "libtool: link: cannot find the library `/usr/lib/libcurl.la' or unhandled argument `/usr/lib/libcurl.la'" as I see it is in the /usr/lib/x86_64-linux-gnu/ directory on oneiric. how can I fix this? [18:49] c_korn: could you file it in the bug tracker so that it doesn't get lost? [18:50] uhm, of course. against which package? [18:50] so the problem is on the Ubuntu side? [18:50] c_korn: but most likely you're probably missing sudo apt-get install libcurl-dev [18:50] c_korn: there isn't enough information to tell you what/where/how/who the issue is [18:51] c_korn: I don't even eg. know what software you're trying to compile [18:51] I have libcurl4-openssl-dev installed [18:51] err, no it sounds like it's bearking because curl was multiarched [18:51] the music player "pragha" http://code.google.com/p/dissonance/ [18:52] (pragha is not in the Ubuntu repositories) [18:52] c_korn: it may be being directed to libcurl.la by another .la file, see if you can see where that came from [18:53] uff, should I look for some symbolic link now? [18:53] no, other la files probably [18:55] find /usr/lib -name *.la ? [18:55] * tumbleweed tries to build it [18:55] it should not need to know the path at all [18:56] those are my build depends http://pastebin.com/MP5WAdLS [18:57] I built the libclastfm0-dev library before. but it should be optional. [18:58] autsch [18:58] it uses LDFLAGS for libraries [18:58] that will bite you with as-needed [19:01] erm c_korn, it built for me (make all) [19:03] (i was building 0.99) [19:03] hum, maybe it is related to my libclastfm library then [19:03] also, I was on amd64 [19:04] yeah it might only need curl for lastfm [19:05] hm, yeah. it also compiles here without my libclastfm library [19:13] ok, I have rebuilt clastfm and now also pragha compiles with lastfm support. thanks. [19:33] well, I think this lintian error explains my problems. http://pastebin.com/DJAMXs7H [19:36] :) [19:45] hm, shouldn't gensymbols automatically been run with compat 8 ? [19:48] before that, even [19:53] hum, but I had to generate the symbols for myself [19:53] well, the initial symbols list has to be created by hand. After that it'll be verified at build time [19:54] ah, ok [19:54] so I delete one line and see what happens ;) [19:54] remember, it'll differ between architectures [19:54] (err, s/will/may/, e.g. if C++) [19:55] ok, works ;) dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below [19:55] yeah, I already got into that situation once [19:55] luckily there is the lib.symbols.arch naming rule of the file. === yofel_ is now known as yofel [20:04] what happened to xulrunner in oneiric? [20:05] firefox-dev replaces at least parts of it I think [20:05] we got rid of it [20:06] firefox-dev exists purely to provide npapi headers. please don't build anything else against it [20:10] hum, but there is no xulrunner executable any longer? [20:14] there is the application http://getbuzzbird.com/bb/ which I started with "xulrunner ./application.ini". how should I do that now? [20:20] c_korn, you can't. we don't support that anymore [20:20] you could always grab the upstream xulrunner binary though [20:21] hum, ok [21:37] what's the easy/correct way to backport from precise to oneiric-proposed? [21:38] easiest is to just upload to oneiric-proposed, and copy-up to precise [21:38] ok, what if I already uploaded to precise? since the SRU page said bugs should be fixed in the current development release first [21:38] yeah that's not strictly necessary in the first week or so [21:39] I'd just do exactly the same upload, with an SRUish version, to oneiric-propesed [21:39] jbicha: There is a good wiki page on SRU:ing, you've read? [21:41] arand: yes, but I don't always read every word... [21:41] I'll need to do a -0ubuntu1.1 then? [21:42] jbicha: what package? [21:43] totem 3.0.1-0ubuntu8 [21:44] jbicha: totem already has an upload in -proposed waiting for verification [21:45] tumbleweed: right, this upload improves the -proposed fix and fixes a second bug while I'm at it [21:45] basically, how do I fix this? and how do I do this correctly next time? [21:46] ok, I'd have said use 3.0.1-0ubuntu5.1 if 3.0.1-0ubuntu7 wasn't already there. Because of 3.0.1-0ubuntu7 you'll have to use 3.0.1-0ubuntu7.1 (which is a little misleading, in that it looks like the first SRU) === bulldog98_ is now known as bulldog98 [21:47] you just note on the bug that you're about to replace the proposed versoin with another one, so don't verify it yet [21:47] so 7.1 or 8.1 then? [21:48] jbicha: it needs to be lower than the version in later releases, so 7.1 [21:48] I was thinking I'd just sync from precise but it looks like that doesn't really work the same way syncing from Debian does [21:48] ok, and how does copying up work? [21:50] jbicha: if oneiric and precise currently have the same versions, you can upload to -proposed, and ask for the upload to be copied to precise when it's accepted. (as if you'd uploaded it before precise opened) But this should only be done in the first week or so === Quintasan_ is now known as Quintasan === luciano_ is now known as virusuy === virusuy is now known as luciano_