[01:23]  * StevenK kicks FreeNode
[01:26] <StevenK> ajmitch: Paying attention?
[01:26] <StevenK> (To IRC, that is)
[01:30]  * ajmitch kicks StevenK 
[01:30]  * StevenK smothers ajmitch with a PPA
[02:47] <jdong> ScottK: sorry for late response -- regarding quassel SRU...
[02:48] <jdong> I think definitely it's something worth SRU'ing
[02:48] <jdong> it's borderline but not quite "security" but definitely worth fixing :)
[02:49] <jdong> the diff itself looks reasonable, my only concern is that it makes both UI and string changes
[02:49] <jdong> not sure if there's anything special implicated by this (i.e. translation?) if we SRU
[02:49] <jdong> apart from that, I'd ACK it :)
[03:26] <ScottK> jdong: Thanks.  Quassel's translations are internal to the package and not part of language packs.  The only U/I change is untranslated, so it's OK.
[03:34] <jdong> ScottK: thanks for the clarification. Looks good to me then!
[03:35] <ScottK> jdong: Great.  Please ack in the bug if you didn't.
[03:35] <jdong> sure thing
[03:36] <jdong> done
[03:50] <RAOF> For some reason mono apps seem to get much more benefit out of building on tmpfs.  Maybe gmcs is threaded.
[03:52] <RAOF> ...and would normally be waiting on the disc more.
[03:55] <ScottK> Maybe tmpfs is more efficient for patent license validation.   ;-)
[03:57] <RAOF> :)
[03:59] <RAOF> tmpfs appears to be quite a lot faster; a bunch of mono packages take somewhat under half the time on tmpfs than on ext4, and even xorg-server takes 80% the time on tmpfs than on ext4.
[04:02] <jdong> RAOF: could it be disk thrashing related? mcs and managed code might stress the VM subsystem into evicting disk cache more readily?
[04:03] <RAOF> Maybe.  The laptop's hardly under memory pressure, though.
[04:03] <RAOF> I don't think it's hit more that 50% ram use.
[04:04] <jdong> hmmm
[04:04] <jdong> would be interesting to know what mcs is doing differently
[04:04] <jdong> I wonder if it writes intermediate files to disk in the process then
[04:04] <RAOF> I should probably add some insane C++ packages to the benchmarks.  How's boost at chewing ram?
[04:08]  * RAOF restarts to load a new nouveau module.
[04:12] <RAOF> Boo. nouveau's 3D is just plain broken :(
[04:13] <ScottK> RAOF: kdebase-workspace probably does a decent job of chewing up ram.
[04:13] <RAOF> Ok.  Once it's finished building gtk & mono I'll throw kdebase-workspace at it.
[04:15] <ScottK> qt4-x11 for ultimate pain, FWIW.
[04:28] <RAOF> Aah.  gnome-shell probably ftbfs because of the wonders of linking against firefox.
[05:33] <RAOF> Gar.  Why is mozilla so difficult?
[05:35] <micahg> ?
[05:36] <RAOF> Oh, gnome-shell FTBFS because it can't find some mozilla libraries, and it can't find them because they're in /usr/lib/xulrunner-1.9.1.7 which isn't in the library path.
[05:39] <micahg> RAOF: do you need someone to look at it?
[05:41] <RAOF> I'd like to know whose responsibility it is.
[05:42] <micahg> RAOF: do you have a build log?
[05:43] <RAOF> http://launchpadlibrarian.net/37862849/buildlog_ubuntu-lucid-amd64.gnome-shell_2.28.1~git20091125-1_FAILEDTOBUILD.txt.gz is as good as any.
[05:45] <RAOF> Either adding an rpath on /usr/lib/xulrunner-1.9.1.7 or exporting LD_LIBRARY_PATH makes the build work.
[05:45] <micahg> RAOF: well, we have a bug about libmozjs
[05:48] <RAOF> Hah.  Wandering through launchpad again makes me wonder why mozilla is so difficult - xulrunner, xulrunner-1.9, no!  xulrunner-1.9.1 is the source package I'm after! :)
[05:48] <micahg> RAOF: I don't see the build dep
[05:48] <RAOF> It's transitive; libgjs-dev pulls it in.
[05:51] <RAOF> I'm just wondering at what level to fix this; it looks like libgjs or gnome-shell are the candidates.
[05:52] <micahg> probably in gjs
[05:55] <micahg> RAOF: do you need the link to the mozjs bug?
[05:55] <RAOF> If it's relevant; I can't seem to find any mozjs bug under xulrunner-1.9.1
[05:56] <micahg> bug 286906
[05:56] <ubottu> Launchpad bug 286906 in xulrunner "provide and support a top-level library package for libmozjs (Was: Unable to use libmozjs.so in an application, because of library path problem.)" [Unknown,Confirmed] https://launchpad.net/bugs/286906
[06:00] <RAOF> Man, launchpad bugzilla integration rocks.
[06:01] <micahg> RAOF: probably should ask asac for anything more, I'm still learning :)
[06:03] <RAOF> It looks like the answer was “no system library for you, but feel free to pull a Debian and make one up”.
[06:04] <micahg> heh
[06:06] <RAOF> I *think* this might be an annoying interaction that isn't necessarily libgjs' fault.
[06:06] <micahg> indeed
[06:07] <RAOF> In fact, I *think* it's something needlessly linking directly to libmozjs.
[06:07] <RAOF> Yup, there we go.
[06:08] <RAOF> Oh, so it probably *is* libgjs' fault, but in its pkg-config file.
[06:22] <RAOF> Right.  So, now I run into the limits of my knowledge of ELF linking.
[06:24] <RAOF> Oooh, is that it?  libgnome-shell.so has 3 references to libmozjs; one explicitly from the (unnecessary) -lmozjs, one implicitly from libgjs-gi.so linking to libmozjs, and finally one with the right rpath from libgjs.so linking to libmozjs
[06:25] <RAOF> It seems two of these are unnecessary; neither libgnome-shell nor libgjs-gi appear to use any symbols from mozjs, and exist only to make other things break.
[06:26] <micahg> RAOF: maybe ask upstream why it's linked?
[06:27] <RAOF> I think it's that common misunderstanding about the role of Requires in pkg-config files.
[06:28] <micahg> k
[06:28] <micahg> sorry, I must go to sleep now
[06:28] <micahg> glad you found the issue
[06:31] <RAOF> So, I can (temporarily) fix gnome-shell by building it with -Wl,--as-needed
[07:15] <dholbach> good morning
[07:16] <RAOF> Morning dholbach
[07:16] <dholbach> hi RAOF
[07:26] <RAOF> dholbach: How are you on the intricacies of the elf linker as they apply to shared object dependencies?
[07:28] <dholbach> you're asking the wrong person :)
[07:30] <RAOF> I might wait for seb128 then, as it concerns gnome-shell and such.
[11:03] <cemc> dholbach: care to look at this bug #96850 (last comment)
[11:03] <ubottu> Launchpad bug 96850 in rrdtool "[apport] perl crashed with SIGSEGV in rrd_test_error()" [Medium,Fix released] https://launchpad.net/bugs/96850
[11:03] <dholbach> cemc: I'm in a meeting right now
[11:04] <cemc> dholbach: oh, sorry
[11:04] <dholbach> cemc: it might make sense to ask in the channel here generally
[11:04] <cemc> it's in main
[11:04] <dholbach> try asking in #ubuntu-devel then :)
[11:05] <cemc> ok, thanks
=== dholbach_ is now known as dholbach
[12:05] <ivoks> \sh: heartbeat isn't what it used to be before
[12:05] <ivoks> \sh: please don't upload anything to lucid yet
[12:06] <\sh> ivoks, grmpf
[12:06] <\sh> ivoks, just two ldirectord bin deps + Makefile.am patch for the FTBFS...I found it what the bugger was...autotools
[12:07] <ivoks> there's latest upstream + fixes on ubuntu-ha ppa
[12:08] <ivoks> heartbeat3 standalone is useless :)
[12:08] <\sh> ivoks, heartbeat from universe.
[12:08] <ivoks> right
[12:08] <ivoks> version 3.0/2.99 is just part of cluster stack
[12:13] <slytherin> is ia64 buildd broken currently? I am seeing lot of ia64 only FTBFS.
[12:13] <randomaction> it was several hours ago, now seems to be ok
[12:14] <randomaction> (sparc was broken, too)
[12:21] <\sh> ivoks, I just fixed the 3 bugs...2 of them I reported...(well and sadly uploaded already :()
[12:21] <slytherin> randomaction: thanks for info. I am retrying a build.
[12:34] <\sh> ivoks, could you incorporate the changes into your ppa then?
[12:36] <ivoks> \sh: if i haven't already, i will
[12:36] <ivoks> \sh: ldirectord isn't part of heartbeat anymore, iirc
[12:37] <\sh> ivoks, it's in 2.99
[12:37] <ivoks> probably, yes, but in 3.0 it's removed to cluster-glue, iirc
[12:37] <\sh> ivoks, well, for ldirectord we need bin-deps on libdbd-mysql-perl and libsocket6-perl and for heartbeat in $sourceroot/resources/OCF/Makefile.am it tries to install drbd resource script two times, and autotools failes because it doesn't like that
[12:38] <ivoks> hb3 doesn't have drbd issue
[12:38] <ivoks> and ldirectord is part of cluster-agents
[12:38] <ivoks> i'll take a look if those deps are satisfied
[12:39] <ivoks> they aren't :)
[12:39] <soren> seb128: Fantastic, thank you.
[12:39] <soren> Whoops.
[12:39] <soren> Heh :)
[12:39] <\sh> ivoks, libdbd-mysql-perl is needed for ldirectord service=mysql loadbalancing, and libsocket6 is needed too, regarding heartbeat
[12:39] <\sh> argl
[12:40] <ivoks> \sh: libdbd-mysql-perl will be recommended
[12:40] <\sh> ivoks, libdbd-mysql-perl is needed for ldirectord service=mysql loadbalancing, and libsocket6 is needed too, regarding bug #487508
[12:40] <ubottu> Launchpad bug 487508 in heartbeat "ldirectord is missing libsocket6-perl dependency" [Undecided,Fix released] https://launchpad.net/bugs/487508
[12:41] <ivoks> \sh: i understand :D
[12:41] <\sh> ivoks, I can help to test latest packages for lucid if you want...we are planning the dist-upgrades from jaunty to lucid via karmic ;)
[12:41] <ivoks> \sh: it's just that not everybody wants load balance mysql, so it's more natural for libdbd-mysql-perl to be recommended, while it clearly depends libsocket6-perl
[12:41] <ivoks> ^on
[12:42] <ivoks> \sh: with heartbeat cluster?
[12:42] <\sh> ivoks, yes..right now we are running plain heartbeat with v1 config, but we need to upgrade this asap
[12:42] <ivoks> \sh: you do know that heartbeat isn't cluster any more?
[12:43] <ivoks> \sh: you will need new CRM; pacemaker
[12:43] <\sh> ivoks, yepp
[12:43] <ivoks> ok
[12:43] <ivoks> don't do any upgrades yet
[12:43] <ivoks> this is something i would like us to do togheter
[12:43] <ivoks> so that we can cover this scenario
[12:44] <ivoks> once packages are prepared, i'll let you know, ok?
[12:44] <\sh> ivoks, pls :) there are more bugs regarding an upgrade from jaunty to karmic we need to resolve here before we actually can dist-upgrade anyways...and we will do our testing in our lab before :)
[12:45] <ivoks> \sh: karmic doesn't have heartbeat-1 :)
[12:45] <ivoks> \sh: you might be better of with cluster from scratch :D
[12:45] <ivoks> anyway, i have to go now
[12:45] <ivoks> ttl
=== bluefox_ is now known as bluefoxicy
[13:08] <bluefoxicy> so is songbird a tool of the devil?
[13:08] <bluefoxicy> It's not packaged in Ubuntu
[13:09] <slytherin> bluefoxicy: ask mozilla team if they have any plans to package it.
[13:09] <bluefoxicy> slytherin: ah, there's a team for that?
[13:09] <directhex> bluefoxicy, songbird bundles its own forked version of xulrunner (the mozilla engine). bundling even little things like zlib makes the archive admins flustered and stern.
[13:09] <bluefoxicy> aha, so it IS a tool of the devil
[13:10] <directhex> bluefoxicy, if songbird gets approved as-is, then it's the precedent i need for moonlight 2.0
[13:11]  * slytherin wonders when rhythmbox will get video playback capability.
[13:12] <directhex> slytherin, is that useful functionality for you?
[13:12]  * bluefoxicy copies music he pirated ages and ages ago to his ipod.
[13:12] <bluefoxicy> this is retarded.
[13:12] <bluefoxicy> I have a folder with like 30 albums in it that I torrented, in a bundle, most I didn'tknow about
[13:12] <bluefoxicy> I'm slowly replacing them with... the actual, physical CDs, from Amazon
[13:12] <bluefoxicy> 8 years later I have half of them
[13:12] <slytherin> directhex: Not very important. But surely I would love to have a single player for audio/video/media (DVD) etc.
=== yofel_ is now known as yofel
[13:13] <bluefoxicy> slytherin:  last time I asked, they weren't interested in video
[13:13] <slytherin> hmm, may be some day I will gain enough knowledge about the code to be able to produce a patch.
[13:13] <directhex> slytherin, i know banshee has the functionality, but afaik it's buggy
[13:13] <slytherin> Or at least a plugin
[13:15] <bluefoxicy> https://bugs.launchpad.net/ubuntu/+bug/94494
[13:15] <slytherin> directhex: last time I tried banshee it worked fairly well for me.
[13:15] <ubottu> Ubuntu bug 94494 in songbird "[needs-packaging] Songbird" [Unknown,Confirmed]
[13:26] <juli_> Hi everybody. I want to update libswing-layout-java from 1.0.3 to 1.0.4. If I update it in Debian won't it be too late to import the package in Ubuntu?
[13:27] <soren> juli_: We can sync from Debian at will.
[13:27] <slytherin> juli_: Debian import freeze is in February
[13:28] <soren> juli_: It doesn't /have/ to have migrated to testing, for instance. It just has to have migrated to testing before it happens /automatically/.
[13:29] <juli_> Actually I don't know when it happens, I mean migraiting to testing
[13:29] <slytherin> juli_: That reminds me. I forgot to send you email about this. Are you interested in taking care of netbeans package in Debian as well?
[13:30] <juli_> slytherin, as for me, I need them in Ubuntu. But people ask me to put them in Debian, so I'm interested
[13:30] <directhex> juli_, that's the spirit
[13:31] <juli_> directhex, :)
[13:31] <slytherin> juli_: The packages are orphaned in Debian. And you are the best person for job. All you need to do is join debian-java team and port the packaging as per Debian practices.
[13:31] <Laney> somehow my priorities shifted after I started contributing to Debian
[13:32] <slytherin> juli_: Oh and migration to testing happens in 10 days provided there are no serious or grave bugs against the package.
[13:32] <directhex> Laney, now you have a flowing beard and wear sandals?
[13:32] <Laney> one out of two of those is correct
[13:32] <Laney> you may choose which
[13:33] <juli_> slytherin, so I can try to upload my packages in Debian... and if I'am lucky they will be migrated automatically right?
[13:33] <slytherin> yes
[13:34] <juli_> slytherin, ok, thank you!
[13:34] <juli_> Laney, are you in debian-java?
[13:34] <Laney> juli_: nop
[13:35] <juli_> can anybody tell me what I have to do to join debian-java team? It looks like I don't have much time for this:(
[13:38] <directhex> juli_, they probably have a page on alioth with a "join this team" link
[13:38] <directhex> probably
[13:40] <juli_> directhex, thanks, I'm already in google:) but as far as I remember I wrote them a letter a year ago with no answer. Anyway I'll try again
[13:47] <sebner> directhex: are you aware that -cli-dev packages got autosynced?
[13:49] <slytherin> juli_: The mailing list is http://lists.debian.org/debian-java/ for getting access to the pkg-java svn register on alioth.debian.org, upload your ssh public key and join team - https://alioth.debian.org/projects/pkg-java/
[13:52] <Laney> Why does mono not get autosynced? It's not in the blacklist
[13:59] <juli_> slytherin, thank you.
[13:59] <geser> Laney: you might need to get an archive admin try to sync it and watch for any errors/OOPSes
[14:00] <Laney> I wonder if there is a block for packages on the cd
[14:00] <Laney> (not interested in syncing it yet)
[14:02] <geser> I don't know of any special handling for those packages (and other parts of main are on the CD too)
[14:04] <geser> directhex: do you see any reason to keep the current mono version in lucid instead of finding it out why it doesn't autosync?
[14:04] <Laney> it will make FTBFS happen
[14:04] <Laney> ongoing transition
[14:05] <geser> ok
[14:05] <Laney> cjwatson: (last few lines) — do you know of any reason why mono doesn't autosync?
[14:15] <cjwatson> Laney: "autosyncs" are only auto in that there's a script to do it; the script still has to be run manually, and maybe it just hasn't been run recently
[14:15] <cjwatson> Laney: somebody appears to be in the middle of an autosync run right now, including mono
[14:17] <Laney> cjwatson: There had been newer versions in testing since 2009-11-23, which made me think that something else was going on here (I know they are only semi-automatic)
[14:34] <cjwatson> Laney: I won't be able to investigate until whoever's running syncs at the moment flushes them
[14:35] <Laney> cjwatson: No problem. It's not urgent, more of a curiosity (until we come to need this sync)
[14:38] <directhex> Laney, when it's needed we can just open 90 bugs manually :)
[14:40] <Laney> dunno if it affects more than just mono!
[14:40] <Laney> (seems not, from random checking of gtk#)
[14:43] <geser> Laney: I know of an other package that fails to auto-sync (I have the OOPS id for it and just need to find someone who can look at it)
[14:44] <Laney> I bet it's something to do with the mammoth number of binary packages provided by mono
[14:59] <proppy> ScottK: hi
[15:16] <proppy> filled https://bugs.launchpad.net/ubuntu/+source/poker-network/+bug/509677
[15:16] <ubottu> Ubuntu bug 509677 in poker-network "Please sync poker-network 1.7.6-1 from unstable to lucid" [Undecided,New]
[15:19] <bddebian> Heya gang
[15:40] <hyperair> heya bddebian.
[15:41] <bddebian> Hi hyperair
[15:41] <hyperair> bddebian: could i ask you to endorse my MOTU application? =D
[15:44] <bddebian> Not sure my opinion is worth much in the Ubuntu world these days.
[15:45] <hyperair> hmm why not?
[15:46] <bddebian> I haven't done much for Ubuntu directly in a looong time. :(
[15:48] <hyperair> but indirectly you still do stuff don't you? =p
[15:48] <bddebian> Probably depends on who you ask. :)
[15:49] <hyperair> O_o
[16:22] <ScottK> bddebian: You are a God.  Your opinion will always matter.
[16:23] <ScottK> proppy: It needs an explicit statement that it's OK to over-write the Ubuntu changes and why.
[16:24] <proppy> ScottK: ah sorry I missed there were ubuntu changes
[16:24] <proppy> checking
[16:24] <ScottK> proppy: poker-network | 1.7.5-1.1ubuntu2 | lucid/universe | source
[16:24] <proppy> ScottK: yes I see that now, dget'ing https://launchpad.net/ubuntu/+archive/primary/+files/poker-network_1.7.5-1.1ubuntu2.dsc
[16:25] <hyperair> bddebian: and so that's how it is. =p
[16:27] <proppy> I already applied ubuntu ubuntu1 changes upstream
[16:27] <proppy>   * Apply Ubuntu changes:
[16:27] <proppy>     debian/python-poker{-network, 2d, -prizes,-stats}.install: use wildcards
[16:27] <proppy> checking ubuntu2
[16:33] <proppy> ScottK: will ask the maintainter to upload a 1.7.6-2 with ubuntu2 changes
=== ianto is now known as Guest42653
=== Pici` is now known as Pici
[16:45] <directhex> moo
=== Quintasan1 is now known as Quintasan
[17:13]  * iulian moos at directhex.
=== maxb_ is now known as maxb
[17:29] <MTecknology> if there's a newer verswion of something in debian unstable, will it still make it to 10.04?
[17:31] <randomaction> MTecknology: not on its own, a sync should be requested for that
[17:31] <randomaction> packages from testing are autosynced
[17:32] <MTecknology> randomaction: how can I request that?
[17:32] <randomaction> https://wiki.ubuntu.com/SyncRequestProcess
[17:33] <MTecknology> thanks
[17:37] <Laney> just wait for it to transition
[17:37] <Laney> unless there's a good reason why we shouldn't
[17:37] <MTecknology> Laney: I just checked what testing is - it's in sid so I guess it'll be in 10.04 :D
[17:38] <MTecknology> for now - I just installed the debain .deb :)
[17:38] <Laney> subject to caveats, yes
[17:38] <Laney> like — is anything going to stop it migrating to testing, and are there any ubuntu changes that will stop it being auto synced?
[17:39] <kamalmostafa> randomaction: hi -- i just fixed guymager to build for i386 and amd64 only (the libguytools1 does actually contain arch-specific code) -- bug 509732 ready for u-u-s
[17:39] <ubottu> Launchpad bug 509732 in guymager "guymager tries to build on architectures not supported by libguytools1" [Undecided,Confirmed] https://launchpad.net/bugs/509732
[17:42] <randomaction> kamalmostafa: ok, I'll sponsor it later if no one beats me to it
[17:42] <kamalmostafa> randomaction: very good.  thanks for noticing that it was going to be a problem.
[17:43] <Laney> (please forward to Debian)
[17:44] <kamalmostafa> Laney: was that for me?  I did report it to Debian, but I do see that upstream of that they're already aware of the Architecture: problems in libguytools1 and guymager -- they'll be cleaned up in their next release I think.
[17:45] <Laney> cool beans
[17:49] <jariq> What is REVU day ?
[17:55] <kamalmostafa> Retry build request:  https://launchpad.net/ubuntu/+source/octave-ad/1.0.6-3   ... yesterday's new libgl1-mesa-glx might fix all the octave-* breakages.
[17:58] <randomaction> pushed button for i386
[17:58] <kamalmostafa> thank you -- i'll keep an eye on it
[18:02] <randomaction> What do I need to do to provide a symbols file for a library (bug 361651)?
[18:02] <ubottu> Launchpad bug 361651 in libsocket "Package does not provide /var/lib/dpkg/info/libsocket0.symbols (shared library information)" [Undecided,New] https://launchpad.net/bugs/361651
[18:04] <kamalmostafa> randomaction: take a peek at dpkg-gensymbols -- google implies that it will generate what you need there.
[18:04] <randomaction> I wonder whether it's called by dh at some point
[18:05] <kamalmostafa> randomaction: that I do not know
[18:06] <kamalmostafa> randomaction: oh and that octave build just failed with the same problem
[18:06] <kamalmostafa>   libGL.so.1: cannot open shared object file: No such file or directory
[18:06] <kamalmostafa> so nevermind about any other the others there (sigh).
[18:08] <randomaction> ok, dh_makeshlibs call dpkg-gensymbols, which creates a shlibs file which goes into control part of the .deb but doesn't seem to be installed
[18:08] <kamalmostafa> But wait... now I see that the octave-ad build didn't actually use the brand new mesa 7.7-0ubuntu7 (it used ubuntu6).  Why would that be?
[18:10] <randomaction> kamalmostafa: maybe it built only recently and hasn't propagated to buildds yet
[18:11] <hyperair> dpkg-gensymbols creates shlibs?
[18:11] <hyperair> that's new
[18:11] <hyperair> and the manpage doesn't say anything of that sort either
[18:11] <kamalmostafa> randomaction: okay, that sounds reasonable.  I do see that it was published only very recently.  We'll try octave again "later".  :-)
[18:13] <hyperair> randomaction: i think you're looking for a symbols file in the control.tar.gz of the deb
[18:14] <randomaction> hyperair: it is there indeed, but it seems to go nowhere
[18:14] <hyperair> not a shlibs. and dpkg-gensymbols doesn't generate one. it needs one to be already there, and then checks that there are no new symbols. if there are new or deleted symbols, it prints a diff then dies, taking the build with it
[18:15] <hyperair> i mean dpkg-gensymbols doesn't gnerate a .symbols file if it didn't already exist before
[18:15] <randomaction> right, there is .shlibs but no .symbols
=== lifeless1 is now known as lifeless
[18:15] <hyperair> yep
[18:15] <hyperair> so what you need is to create the symbols file
[18:15] <hyperair> to do that, you need to run the build locally, then run dpkg-gensymbols on it
[18:15] <hyperair> get the diff
[18:15] <hyperair> and then get the symbols out from there
[18:16] <hyperair> (very annoying, i know)
[18:16] <randomaction> and it goes into debian/ ?
[18:16] <kamalmostafa> randomaction: fwiw an small-ish package which has an example of this is 'clxclient'.
[18:16] <hyperair> randomaction: yes, it goes into debian.
[18:16] <randomaction> hyperair: thank you, I'll try it
[18:17] <hyperair> randomaction: the naming convention of the symbols file is in the top of the dpkg-gensymbols manpage
[18:18] <hyperair> randomaction: if you're packaging a C++ library, you want to avoid dpkg-gensymbols like plague. but you're not, are you?
[18:18] <randomaction> it's C++
[18:19] <randomaction> I mean, sources are
[18:19] <hyperair> then you want to avoid dpkg-gensymbols
[18:19] <randomaction> I don't really know what it exports
[18:19] <hyperair> C++ symbols are mangled, as i'm sure you know?
[18:19] <randomaction> yep
[18:19] <hyperair> and the mangling is architecture specific.
[18:19] <randomaction> and compiler-specific I believe
[18:19] <hyperair> which means that for each architecture the library builds on, you're going to have to provide a different symbols file.
[18:19] <hyperair> yes
[18:19] <hyperair> architecture and compiler specific
[18:20] <hyperair> it's not worth the effort.
[18:20]  * hyperair packaged sigx and encountered this kind of problem
[18:20] <randomaction> ok, I've got one more library question..
[18:20] <hyperair> hmm?
[18:21] <randomaction> this package installs library into /usr/lib/packagename, adds this path ld.so.conf on install and doesn't clean on remove
[18:21] <hyperair> that's not good.
[18:21] <randomaction> that's terribly wrong, I assume
[18:21] <hyperair> it is terribly wrong
[18:21] <hyperair> if you must add a path into ld.so.conf, use /etc/ld.so.conf.d/
[18:22] <hyperair> stick a file in there
[18:22] <randomaction> so the solution is just to install .so to /usr/lib
[18:22] <hyperair> yes, that would be preferable, i believe.
[18:22] <randomaction> ok, that's what I did
[18:22] <hyperair> is there a reason that upstream wants to install it to /usr/lib/packagename?
[18:23] <randomaction> no idea; I took this package to fix FTBFS, and I try to fix other obvious breakage
[18:23] <hyperair> i see
[18:23] <hyperair> well, this is an issue that probably should be brought upstream
[18:25] <hyperair> if you don't want to bring it upstream yourself, you could contact te original maintainer of the package
[18:25] <hyperair> the last person in the debian/changelog
[18:25] <hyperair> or the debian maintainer
[18:26] <randomaction> yep
[18:26] <hyperair> ..it's even a native package. just what is going on with this package?
[18:26] <hyperair> weird.
[18:26] <randomaction> it's really broken :)
[18:26] <hyperair> heh
[18:26] <hyperair> when was the last changelog entry?
[18:27] <randomaction> 2007
[18:27] <hyperair> that's quite long ago.
[18:27] <hyperair> i wonder if upstream died
[18:27] <hyperair> there are no rdeps
[18:27] <hyperair> it might be better to just get rid of the package.
[18:27] <randomaction> last release is 2006
[18:27]  * hyperair whistles
[18:27] <randomaction> popcon = 368
[18:28] <hyperair> hmm that's a significant number
[18:28] <randomaction> a bug filed in April 2009, apparently someone is still using it
[18:28] <hyperair> hmm
[18:29] <hyperair> maybe
[18:29] <hyperair> it's removed from debian though
[18:29] <hyperair> at least, the source package's not there.
[18:29] <hyperair> that would probably mean that it's going to disappear from ubuntu in due time
[18:30] <randomaction> maybe
[18:51] <randomaction> ok, I uploaded a relatively straightened version of libsocket, I decided not to touch symbols file, but anyway thank you hyperair for telling me how it's done
[18:51] <hyperair> np
[18:59] <fabrice_sp> randomaction: fceux accepted: thanks for your review! :-)
[19:00] <randomaction> you're welcome :)
=== stgraber_ is now known as stgraber
[19:17] <jariq> could someone pls review new package ipwatchd ? - http://revu.ubuntuwire.com/p/ipwatchd
[19:24] <stefanlsd> With a merge and a debuild -S -v, the -v specifies the previous ubuntu version so you get the debian changes and your merge changes in the .changes right?
[19:29] <jariq> I've read in motu mailinglist that for Jaunty there were weekly REVU days every Friday. Is there something similar also for lucid ?
[19:32] <randomaction> stefanlsd: right
[19:33] <stefanlsd> randomaction: thanks!
[19:40] <geser> kamalmostafa: can you please mark your libguytools1 merge proposal as "merged". thanks
[19:41] <kamalmostafa> geser: sure will do.  I'm unclear as to why that doesn't happen automatically.
[19:43] <geser> I guess randomaction uploaded your changes but did push the merged bzr branch back to LP (only then LP knows that your branch got merged and updates the status of the merge proposal)
[19:43] <randomaction> I actually only did the upload
[19:44] <kamalmostafa> geser: ok.  fwiw, I think that I *always* have to manually change my merge proposals to "Merged".  I mentioned it to james_w and he was surprised by that too.
[19:56] <kamalmostafa> geser: Were you looking at the related 'guymager' merge (bug 509732)?  It looks like I had forgotten to press the "Propose" button, but have done so now.
[19:56] <ubottu> Launchpad bug 509732 in guymager "guymager tries to build on architectures not supported by libguytools1" [Undecided,Confirmed] https://launchpad.net/bugs/509732
[20:09] <james_w> kamalmostafa: I think the issue is that your sponsor is not pushing to the lp:ubuntu branche
[20:15] <kamalmostafa> james_w: ok -- i'm not sure what that means really -- is this something the sponsors should be doing differently, or something I should be doing differently?
[20:17] <geser> kamalmostafa: it's a sponsor thing: with bzr merges your sponsor has to do "bzr push" to updated the LP branch (and get your merge proposal marked as "merged" by LP) *and* dput the new source package
[20:17] <randomaction> I wonder what happens if I push and dput different things
[20:18] <randomaction> will delta be represented as another revision?
[20:19] <geser> james_w: ^^ any answers to this?
[20:20] <james_w> it will complain and make the branch look like the upload, but won't throw the push away
[20:21] <geser> what about any tags? (bzr mark-uploaded)
[20:22] <randomaction> ok, so that won't screw things up completely
[20:32] <kamalmostafa> Quick informal moto-review of bug 353219 please.  Do we want this fix in Lucid, or is it not important enough to justify an "ubuntu1" version?
[20:32] <ubottu> Launchpad bug 353219 in ax25-tools "beacon crashes if the length of the destination exceeds 20" [Undecided,Confirmed] https://launchpad.net/bugs/353219
[21:05] <dirakx1> hello i uploaded a package to REVU but its not showing this is the bug.  https://bugs.launchpad.net/ubuntu/+bug/507579
[21:05] <ubottu> Ubuntu bug 507579 in ubuntu "[needs-packaging] turtleart" [Wishlist,New]
[21:06] <dirakx1> dput says Already uploaded to revu on revu.ubuntuwire.com
[21:10] <cyphermox> dirakx1, does dput -f say the same thing?
[21:11] <dirakx1> cyphermox: i havent issue that command :)
[21:11] <dirakx1> Uploading to revu (via ftp to revu.ubuntuwire.com):
[21:11] <dirakx1>   Uploading turtleart_0.0.1.dsc: done.
[21:11] <dirakx1>   Uploading turtleart_0.0.1.orig.tar.gz: done.
[21:11] <dirakx1>   Uploading turtleart_0.0.1.diff.gz: done.
[21:11] <dirakx1>   Uploading turtleart_0.0.1_source.changes: done.
[21:11] <dirakx1> Successfully uploaded packages.
[21:12] <dirakx1> lets hope that it works this time ..
[21:13] <dirakx1> cyphermox: thx for your help.
[21:13] <cyphermox> dirakx1, when you upload, dput creates a .upload file, IIRC, to remember the changes have already been send
[21:14] <dirakx1> source.revu.upload
[21:14] <dirakx1> :)
[21:31] <EzraR> if i wanted to put a package in my ppa for testing before merging would placeing a ~ppa0 be enough to keep it seperate from the official repo?
[21:32] <EzraR> meaning would foo-1ubuntu1 replace foo-1ubuntu1~ppa0
[21:32] <RAOF> Yes.  That means its version will sort before the official one.
[21:33] <RAOF> The ~ character is treated specially: it means “sort me after everything else, even the empty string”, so 0~ < 0 and 1ubuntu1~ppa0 < 1ubuntu1
[21:33] <EzraR> thats what I thought I just wanted to make sure, thanks
[21:35] <siretart> does anyone else experience that gpg-agent does no longer cache the passphrase?
[21:35] <RAOF> The plugin from seahorse-plugins still does, for me.
[21:35] <siretart> doing mass uploads is no fun if you need to retype in the pin for each source package
[21:36] <siretart> twice
[21:36] <micahg> siretart: on cli, yes
[21:36] <siretart> RAOF: that one doesn't work with the gpg smartcard :/
[21:37] <siretart> so I need to resort to gpg-agent
[21:37] <RAOF> Wow, I don't even have that installed.
[21:38] <siretart> I'd prefer working smartcard support in searhorse, too
=== micahg1 is now known as micahg