[00:03] <superm1> cody-somerville, what's up? i'm in between airports, so leave me a message with what ya need
[00:04] <persia> superm1, I suspect it was about a sound issue encountered with a particular device, now solved by an upgrade to karmic (unless my backscroll memory overflowed)
[00:05] <superm1> persia, ah okay
[00:05] <dtchen> superm1: vostro 1520, already fixed in karmic. possible backport to jaunty-proposed (later) by apw.
[00:06] <persia> (of course, he who actually pinged ought to have provided both bits of information :) )
[00:56] <asomething> any one around who can add me to universe-sponsors?
[00:58] <TheMuso> asomething: Sure. Whats your LP username?
[00:58] <asomething> TheMuso: andrewsomething
[00:58] <TheMuso> asomething: Ok will add it, and congrats.
[00:59] <asomething> Thanks!
[00:59] <TheMuso> Done.
[00:59] <ajmitch_> what's the benefit of being a team member? getting the extra pile of bugs to look at?
[01:00] <TheMuso> ajmitch_: being able to unsubscribe uus if need be for one.
[01:01] <ajmitch_> hm, true
[01:01]  * ajmitch_ should probably join up there & u-m-s as well
[01:02] <TheMuso> ajmitch_: I can get you into the former if you'd  like.
[01:02]  * persia goes to give ajmitch a gold star
[01:02] <ajmitch_> alright
[01:02] <ajmitch_> persia: but I want a pony!
[01:02] <persia> ajmitch_, Then create a launchpad group with a pony icon
[01:03] <ajmitch_> heh
[01:03] <fta> if i ship an icon in different sizes in /usr/share/icons/hicolor/*/apps/, do I also need to continue to ship one in /usr/share/pixmaps?
[01:04] <persia> fta, It depends on whether all the environments you wish to support include /usr/share/icons/ in their icon cache search path (most do).
[01:04] <ajmitch_> looks like kees will be the most likely person to poke about u-m-s at this hour
[01:05] <fta> persia, that's chromium, i asked upstream to provide several sizes, now i have 16 32 48 and 256
[01:05] <ajmitch_> 256? that's rather large
[01:05] <persia> fta, Excellent.  The part I can't tell you is if that will work in kubuntu.
[01:05] <fta> 256 is for gnome do
[01:08] <fta> persia, ok, so i'll keep my old 48x48 icon in /usr/share/pixmaps for now and ask the kde guys what they need
[01:10] <persia> fta, My understanding was that the KDE cache was considerably more flexible than the GNOME cache.  It's XFCE that makes me wonder.
[01:11] <persia> (yet somehow I managed to type "kubuntu" instead of "xubuntu", for which I must apologise)
[01:11] <fta> oh, ok. i'll find someone using xubuntu then
[01:17] <JontheEchidna> hicolor works in kde (since it's the xdg fallback icon theme)
[01:18] <persia> JontheEchidna, Didn't hicolor come from KDE?
[01:19] <JontheEchidna> hmm, that's ringing a few bells so there's a good chance it did
[01:19] <JontheEchidna> especially since kde was a major contributor to xdg along with gnome
[01:19] <persia> Certainly.  .desktop files are basically .link files redone.
[01:27] <ajmitch_> what's the best way to go about sponsoring merges? unsubscribe u-u-s when it's uploaded?
[01:33] <ajmitch_> assuming that this package builds properly & is flawless :)
[01:42] <freakabcd> hi all
[01:42] <ausimage> persia: I just pushed out my update package to lp and revu... :D
[01:43] <persia> ajmitch_, https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue
[01:43] <persia> freakabcd, Hi
[01:43] <persia> ausimage, Cool.
[01:43] <ajmitch_> of course, I only searched for 'Sponsoring'
[01:43] <ausimage> I hope to really get some good feedback on how I can make my package better and to see it in Ubuntu
[01:46] <ajmitch_> nellery: sorry about the bug spam, just juggling statuses ;)
[02:04] <nellery> ajmitch_: no problem, thanks for sponsoring that :)
[04:12] <prefrontal> hey guys, do i need to plan to have my package included in universe in conjunction with an ubuntu release or can it happen at any time
[04:13] <ajmitch_> it needs to be ready, reviewed & uploaded before feature freeze
[04:14] <ajmitch_> https://wiki.ubuntu.com/KarmicReleaseSchedule has the relevant dates for this release
[04:14] <prefrontal> August 27th
[04:15] <prefrontal> thanks ajmitch_
[04:16] <lifeless> I strongly suggets you have it uploaded way before that
[04:16] <lifeless> because the first upload will probably generate a bunch of bug reports
[04:17] <prefrontal> i've had my own repo for years
[04:17] <prefrontal> what kinds of bug reports?
[04:17] <ajmitch_> reviewing may take awhile as well, depending on how busy people are
[04:17] <ajmitch_> have you looked at getting it into debian as well?
[04:17] <prefrontal> also, can i have a development snapshot of my project that i update semi frequently?
[04:18] <prefrontal> no i haven't
[04:18] <prefrontal> sometimes i get dependency conflicts but they are almost always because the user has some weird video card for which opengl is not working correctly
[04:19] <prefrontal> what other kinds of bug reports are you thinking of? related to the package itself?
[04:21] <prefrontal> here is my software btw http://grey.colorado.edu/emergent
[04:22] <lifeless> prefrontal: your own debian repository with the software interacting with all 16K other packages?
[04:22] <prefrontal> yes
[04:22] <prefrontal> it has a huge whack of dependencies. our software is complicated
[04:22] <lifeless> then thats where I would expect bug reports
[04:22] <lifeless> its just a trend I see with new packages
[04:23] <prefrontal> but nothing else depends on our software
[04:23] <ajmitch_> that'll make it fun to review
[04:23] <lifeless> prefrontal: so, as I said, just get it uploaded early; if I'm wrong you got in early no harm done
[04:24] <prefrontal> k:)
[04:24] <lifeless> if I'm right, you'll have time to fix things without needing SRU's
[04:25] <prefrontal> i can use SRU's to have the package included in previous versions of ubuntu?
[04:25] <ajmitch_> do you have a source package around that you build the binary package from?
[04:25] <ajmitch_> no, you can't include new packages that way - instead you use backports to get it into earlier versions
[04:26] <prefrontal> no, for my own repo i just use cpack's 'make deb' target. i built a package from hand once, it sucked
[04:26] <ajmitch_> you may need to learn the sucky way of doing it to get a source package ready for review
[04:27] <prefrontal> yeah i know, thats why i'm here :)
[04:27] <prefrontal> about that frequent development snapshot package?
[04:27] <prefrontal> emergent-snapshot
[04:28] <prefrontal> can i do that, and how frequently?
[04:28] <lifeless> sure
[04:28] <lifeless> two ways
[04:28] <lifeless> a PPA
[04:28] <lifeless> with the regular package name in the PPA
[04:28] <lifeless> or a dedicated snapshot package in karmic
[04:28] <lifeless> I recommend a PPA
[04:28] <lifeless> its much cleaner
[04:29] <prefrontal> i've used someone elses PPA before i think
[04:29] <prefrontal> they then have to modify sources.list?
[04:29] <prefrontal> which wouldn't present a benefit to me, since thats just like using my own repo
[04:30] <prefrontal> you're saying there is something unclean about the dedicated snapshot package
[04:30] <prefrontal> e.g., i wouldn't be able to do nightlies?
[04:30] <ajmitch_> it does have the benefit of being built automatically on different architectures
[04:30] <prefrontal> oh that could be nice
[04:31] <ajmitch_> nightly uploads wouldn't really work, and you couldn't do that with a snapshot package in a released version of ubuntu
[04:31] <ajmitch_> but you can with a PPA
[04:33] <prefrontal> how frequent can i update my snapshot? weekly/monthly?
[04:34] <prefrontal> ok, i have a different idea..
[04:34] <ajmitch_> someone would probably need to review & upload the snapshot package each time, and this would just be for the development relerase unless you were then also getting the snapshot updated in backports
[04:35] <ajmitch_> and I don't know how that would go :)
[04:35] <prefrontal> is Ubuntu ok with a snapshot package that svn checkouts the source code to my software and compiles it?
[04:35] <ajmitch_> does your software change that rapidly?
[04:35] <lifeless> prefrontal: its like, but not like using your own repo
[04:35] <ajmitch_> using a PPA is probably the best option, I think
[04:35] <ajmitch_> since you don't have to worry about ubuntu freezes, etc
[04:35] <lifeless> prefrontal: firstly it builds with all the current karmic dependencies, and it builds in the same environment as karmic itself, so you'll find out about build issues
[04:36] <prefrontal> yeah it does change a lot, we are scientists and our nose and hence code follows the funding
[04:36] <lifeless> secondly, it builds on all the karmic architectures, so you'll find out about portability to things like lpia that you were perhaps not doing yourself
[04:37] <prefrontal> yeah.. we haven't really thought about that
[04:37] <prefrontal> we can't target specific archs?
[04:37] <lifeless> and lastly, you'll be building via the standard deb rule, rather than the cmake deb rule
[04:37] <lifeless> you can, but the experience of getting it building in a PPA will make sure you have addressed those things
[04:37] <prefrontal> i see
[04:38] <lifeless> so PPA's are great for upstream software authors to use as a staging area for updates to their software in Ubuntu itself
[04:39] <prefrontal> i think i'm going to create a PPA - thanks a lot guys
[04:39] <ajmitch_> NB: PPAs only accept source package uploads, like ubuntu
[04:42] <prefrontal> NB?
[04:43] <ajmitch_> short for nota bene, or colloquially 'take note of this'
[04:43] <prefrontal> kk
[04:47] <prefrontal> cool, so, after I upload a new source package to a PPA, does it get compiled straightaway, or is there a periodic cron?
[04:47] <prefrontal> reductio: can I submit a new snapshot package for each commit?
[04:48] <prefrontal> (to my PPA)
[04:48] <ajmitch_> each upload would go into a queue to get built
[04:48] <lifeless> prefrontal: yes you an
[04:48] <prefrontal> nice
[04:48] <lifeless> prefrontal: various upstreams do this already
[04:48] <ajmitch_> uploading on every commit may be a bit of overkill for something that large though
[04:48] <ajmitch_> depending on how often you commit
[04:48] <lifeless> prefrontal: I'd suggest establishing a baseline and uploading incrementals though
[04:49] <prefrontal> we don't do that now and wouldn't likely start, but i would like to do more frequent builds
[04:49] <lifeless> step 1) get it working. step 2) tune :)
[04:50] <ajmitch_> step N) automagic building based on pushes to bzr branches in launchpad? :)
[04:50] <lifeless> ajmitch_: :)
[04:50] <ajmitch_> if that comes about soon
[04:53] <prefrontal> what kind of compile farm you guys got?
[04:53] <prefrontal> just curious..:)
[04:54] <prefrontal> we just got a 26 node cluster with dual quad core nehalems and 24 gb ram per node
[04:54] <prefrontal> make -j8 takes less than a minute on a single node
[04:54] <prefrontal> takes like 30 minutes on my laptop
[04:56] <lifeless> I don't remember the details
[04:56] <lifeless> lots though
[04:57] <lifeless> they get shared with other things - at release time I think most of the builders become mirrors for ubuntu; demand goes through the roof for a while there
[04:57] <lifeless> lp has most of the details
[04:59] <lifeless> https://edge.launchpad.net/builders/
[04:59] <lifeless> I coulnt 53 machines
[05:00] <ajmitch_> with a lot of interesting names
[05:01] <lifeless> there may be hidden ones for embargoed builds too; I dunno quite how that hangs together.
[05:09] <StevenK> lifeless: There isn't, they just state 'Building private build'
[05:21] <prefrontal>  those are virtual machines?
[05:21] <prefrontal> some of them look to be
[05:31] <bodhizazen> All Hai oh great ones :)
[05:32] <bodhizazen> I have  a question which should be easy , but no one has answered for me
[05:33] <bodhizazen> Let us say I am building a package from source, applying a patch
[05:33] <bodhizazen> call this package foo
[05:33] <bodhizazen> so I get the ubuntu source (apt-get source foo) -> patch -> build it
[05:34] <bodhizazen> how do I number the package so as not to confuse apt-get (dpkg) ?
[05:34] <bodhizazen> ie I want to maintain satisfaction for dependencies
[05:35] <bodhizazen> So bar depends of foo-ubuntu-1.0
[05:35] <bodhizazen> and I build foo-patched
[05:35] <bodhizazen> how do I number it ?
[05:36] <lifeless> prefrontal: we build on VM's for security. clean machine every time
[05:37] <lifeless> bodhizazen: that will depend on how strict bar's dependencies are
[05:37] <lifeless> bodhizazen: which is probably why noone has answered it, because there isn't a single answer, other than 'you should learn how version numbering in dpkg works'
[05:39] <bodhizazen> would you have a link you would advise ?
[05:40] <lifeless> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
[05:41] <bodhizazen> Thank you  :)
[05:42] <jmarsden> Chapter 7 too: http://www.debian.org/doc/debian-policy/ch-relationships.html
[05:43] <prefrontal> lifeless, thats impressive:)
[05:43] <bodhizazen> The problem is , sometimes bar can be very strict, in which case it seems like a can of worms :)
[05:46] <lifeless> bodhizazen: it may be a bug in bar, or necessary for some reason. So if you think its going to occur you should check bar (or the reverse-depends of foo) and possibly change them too
[05:50] <bodhizazen> Assuming I do not mind the breakage / building in a chroot ...
[05:50] <bodhizazen> may I assume I can change / edit the dependencies as I wish ?
[05:51] <jmarsden> Sure.  What you do in the privacy of your own computer is your own business :) :)
[05:51] <lifeless> within sensible constraints yes
[05:52] <lifeless> if you put it in a PPA you should be aiming for something that is in principle uploadable to ubuntu too
[05:52] <bodhizazen> What I am working on is the php5 meta package
[05:52] <bodhizazen> but I do not run apache
[05:53] <bodhizazen> so I want to remove the apache dependencies
[05:53] <bodhizazen> I am applying the php-fpm patch
[05:53] <bodhizazen> http://php-fpm.anight.org/download.html
[05:53] <lifeless> if you're planning on submitting that for Ubuntu, you should probably discuss it on the list first ;)
[05:53] <bodhizazen> I have no problem building from source (ie php directly)
[05:53] <bodhizazen> and I am trying to go to a ppa
[05:54] <bodhizazen> which list ?
[05:54] <ajmitch_> probably ubuntu-server
[05:56] <bodhizazen> Good advice
[05:57] <bodhizazen> for the moment I am wanting to learn what is involved (or at least a general idea) with going from source to a ppa ;)
[05:58] <bodhizazen> not that I do not want to work with ubuntu-server, I am just at the beginning stage and as you can see need a little advice on actually packaging, lol
[05:58] <ajmitch_> I'd love to help but I have to leave the computer for a bit - most of what you need to know will be covered on the wiki
[05:58] <ajmitch_> !packagingguide
[05:59] <jmarsden> bodhizazen: If you can build it in a pbuilder chroot locally, (and that chroot is "normal"), it will be fine in the PPA also.
[06:00] <jmarsden> So once you've read the Packaging Guide, check out https://wiki.ubuntu.com/PbuilderHowto and try building your packages that way; then try uploading them to a PPA.
[06:12] <Flannel> bodhizazen: You don't have to have apache stuff to install the php5 metapackage.  it's depends are satisfied by php5-cgi
[06:12] <bodhizazen> jmarsden, I have nginx + php-fpm up and running in an OpenVZ container , which is essentially a chroot
[06:13] <bodhizazen> Flannel, the fpm essentially replaces php5-cgi
[06:13] <jmarsden> bodhizazen: Well, it is a choroot but it contains a bunch of modules that are unlikely to be present by default in a PPA or a pbuidler... so it will not check build dependencies nearly as well as a real pbuilder
[06:13] <bodhizazen> so it is php5-common with a patch, but otherwise is run as you would fastcgi
[06:15] <bodhizazen> can pbuilder be run in a VM ?
[06:15] <jmarsden> I'm very imperfect... when I build stuff on a "real" machine or a VM and forget to also test in a pbuilder chroot, that's when I find my PPA builds fail with dependency problems...
[06:15] <bodhizazen> such as KVM or Virtualbox ?
[06:15] <jmarsden> Yes, I run pbuilders inside virtualbox VMs here
[06:15] <jmarsden> Lets me test on Debian when I am running Ubuntu as my primary OS...
[06:16] <bodhizazen> I will look at that over the next few days
[06:17] <bodhizazen> The problem is I am patching php5-common
[06:17] <bodhizazen> but that is part of php5 the meta package , lol
[06:18] <fabrice_sp_> jmarsden, you don't need a vm for that: you can use a simple chroot to have a debian env in your machine
[06:18] <fabrice_sp_> except if you are using windows as primary os
[06:18] <Flannel> bodhizazen: php5 is a metapackage... just don't install it.
[06:19] <jmarsden> fabrice_sp_: True, but then if I want to test the resulting built modules under Debian, and the app concerned needs a GUI... I'm not sure I can do that in a chroot, can I?
[06:24] <AnAnt> hello, when was the last sync from Debian ?
[06:27] <fabrice_sp_> jmarsden, you can use the x-windows server of Ubuntu to see the window
[06:28] <fabrice_sp_> I actually do it with karmic (in a chroot) and even an i386 chroot for Firefox (because of flash on amd64)
[06:29] <jmarsden> fabrice_sp_: OK... thanks.  I should try that (although virtualbox is so easy to use anyway).
[06:30] <bodhizazen> Flannel, apt-get source php5-common pulls all of php5 (the meta package) with all it's dependencies
[06:31] <bodhizazen> dpkg-buildpackage -rfakeroot -uc -b then builds all of php5 and all of it's dependencies,
[06:31] <fabrice_sp_> AnAnt, you mean for Karmic? The last automatic sync will be end of June (https://wiki.ubuntu.com/KarmicReleaseSchedule).
[06:31] <bodhizazen> so I am trying to figure out how to build just php5-common ?
[06:32] <fabrice_sp_> jmarsden, the pb with VM is that you have to dedicate the memory, and some packages are so huge during compilation, that they 'eat' more than 1Gb... I also use virtualbox, but not for building ;-)
[06:34] <AnAnt> so before June I shouldn't ask that a package get sync'ed from debian ?
[06:34] <jmarsden> fabrice_sp_: OK.  I do have pbuilder chroots under the main OS for building too; I tried it both ways.  I put 8GB in this desktop so I can run several virtualboxes of 1GB each with no real worries... could probably try running a couple of 2GB Virtualboxes if I needed to :)
[06:35] <jmarsden> AnAnt: Unless the older package you are replacing in Ubuntu has a -XubuntuY Ubuntu-specific package earlier, autosync will do the job for you until then.  BTW... it is already June :)
[06:35] <fabrice_sp_> AnAnt, no, except if it has some Ubuntu changes that can be discarded
[06:36] <fabrice_sp_> jmarsden, is quicker with his 8Gb of RAM :-)
[06:36] <jmarsden> if I run enough vboxes I will slow down :)
[06:36] <fabrice_sp_> sure! :-) I only have 2, so I don't have much room to run a lot of VM ;-)
[06:37] <dholbach> good morning
[06:37] <fabrice_sp_> 2Gb, I mean
[06:37] <fabrice_sp_> Hey dholbach ! Good morning ;-)
[06:37] <jmarsden> fabrice_sp_: Yes, that would be pretty limiting.
[06:38] <dholbach> hiya fabrice_sp_
[06:39] <fabrice_sp_> jmarsden, my VM's don't have more than 400 Mb, so for building, it¡'s very short (the compiler sometimes eat all the ressources, and I have to kill the VM)
[06:39] <fabrice_sp_> dholbach, how are you doing this morning?
[06:39] <dholbach> very good very good - how 'bout you?
[06:41] <fabrice_sp_> Good too :-) a bit hot lately here (more than 30ºC), so I don't sleep as much as I liked to :-)
[06:44] <AnAnt> ah, ok
[06:44] <AnAnt> dholbach: thanks
[06:44] <ajmitch_> morning dholbach
[06:48] <dholbach> hiya ajmitch_
[06:48] <ajmitch_> dholbach: I was inspired by you & sponsored an upload today ;)
[06:48] <dholbach> wooohoo!
[06:49] <dholbach> more sponsoring!
[06:49] <ajmitch> and rejoined u-u-s so I can mangle the bugs
[06:49]  * ajmitch isn't in u-m-s though
[06:50] <ajmitch> dholbach: mind re-adding me there?
[06:51] <StevenK> ajmitch: You're actually doing some sponsoring?
[06:51] <dholbach> ajmitch: done
[06:51] <StevenK> ajmitch: Who are you, and what have you done with the real ajmitch?
[06:51] <ajmitch> StevenK: shush, before you kill off my desire to do any more
[06:52]  * StevenK smiles sweetly
[06:52] <ajmitch> I even merged stuff!
[06:53] <ajmitch> Now let me revel in the fact that I've done more uploads to karmic already than the last 3 releases together
[06:53] <StevenK> Haha
[06:53] <StevenK> How many is that?
[06:53] <ajmitch> bugger all :)
[06:53] <StevenK> Less than 9?
[06:53] <ajmitch> 6 or 7 so far, I think
[06:53]  * StevenK did 9 in a lump this morning for NBS-age
[06:54] <ajmitch> so I saw
[06:54] <ajmitch> they were mostly rebuilds though, they hardly count
[06:54] <StevenK> But I did test build them!
[06:54] <AnAnt> ok, can you upload these: LP #359436 , LP #359444 , LP #359446 ?
[06:54] <ajmitch> I'd hope so! :)
[06:54] <StevenK> ajmitch: :-)
[06:55] <AnAnt> they are for karmic now
[07:05]  * StevenK uploads something to decrease the evilness present in the archive by a little.
[07:10] <prefrontal> hmm, debootstrap karmic doesn't seem to be making use of both cores
[07:14] <AnAnt> brb
[07:22] <StevenK> ajmitch: Does acidlab count? :-P
[07:27] <ajmitch> decreasing the evilness? I doubt it
[07:28] <ajmitch> it's a php package, that's pure evil right there
[07:31] <StevenK> But it was using yada, and now it isn't!
[07:33] <ajmitch> oh, that's alright then
[07:33] <jmarsden> So before it was impure evil, and now it is pure evil? :)
[07:34] <ajmitch> I'm not sure whether uploading php5 made me evil or not
[07:36] <StevenK> PHP + yada == evil^evil ; PHP == evil
[07:50] <slytherin> Can anyone please tell me the meaning of this condition - ifneq ( ,$(filter-out $(DEB_HOST_ARCH), arm mipsel mips armel))
[07:55] <StevenK> If the arch isn't arm, mips, mipsel or armel do the following
[07:58] <slytherin> StevenK: thanks. I was trying to figure out why armel build of libjogl-java fails. I thought the condition was problem.
[08:04] <slytherin> StevenK: any idea if DEB_HOST_ARCH evaluates to armel on the armel buildd? Or should we rather use DEB_TARGET_ARCH?
[08:05] <StevenK> steven@obliterated:~$ dpkg-architecture -qDEB_HOST_ARCH
[08:05] <StevenK> armel
[08:06] <slytherin> StevenK: then I am not able to understand why the build is failing
[08:07] <StevenK> slytherin: Where's the build log?
[08:07] <slytherin> StevenK: https://edge.launchpad.net/ubuntu/+source/libjogl-java/1.1.1+dak1-5/+build/983218/+files/buildlog_ubuntu-karmic-armel.libjogl-java_1.1.1+dak1-5_FAILEDTOBUILD.txt.gz
[08:08] <slytherin> StevenK: the logic is supposed to be in such a way that if the arch is armel then 'javadoc' target should not be run. But the target is running anyway, it times out and fails.
[08:08] <slytherin> StevenK: looks like the same problem is happening in Debian as well.
[08:09] <StevenK> Build killed with signal 15 after 150 minutes of inactivity
[08:09] <StevenK> Ahh
[08:09] <StevenK> Perhaps javadoc should only run on the i386 builder and dump the docs into a arch all package?
[08:10] <slytherin> StevenK: that is what supposed to happen according to the logic in debian/rules file. But the logic is not working. I will log a bug in Debian.
[08:14] <StevenK> slytherin: With my logic, javadoc should only get run in the binary-indep target, so the !i386 builders would never call it
[08:15] <slytherin> StevenK: how can that be handled in cdbs?
[08:16] <StevenK> As a hack?
[08:17] <slytherin> StevenK: No I am asking how to achieve what you are suggesting in a rules file which is using cdbs.
[08:18] <StevenK> Yes, and my suggestion is a hack ;-)
[08:20] <StevenK> H
[08:20] <StevenK> *Hmm
[08:21] <StevenK> I wonder if this is as simple as ifeq rather than ifneq
[08:27] <gaspa> someone could please giveback ocaml-http
[08:27] <gaspa> ?
[08:27] <gaspa> (in my ppa builds fine)
[08:28] <gaspa> and ocaml-lastfm as well, please.
[08:33] <nenolod_> hi.  is karmic auto-import frozen yet?  audacious2 just hit debian sid a few days ago.
[08:35] <maxb> nenolod: https://wiki.ubuntu.com/KarmicReleaseSchedule - no
[08:45] <StevenK> nenolod: It doesn't appear in the new source report I just ran on the archive master.
[08:45] <nenolod> StevenK: it's there :P
[08:46] <nenolod> StevenK: http://qa.debian.org/developer.php?login=nenolod@dereferenced.org
[08:47] <StevenK> http://ftp.debian.org/debian/pool/main/a/audacious2/ is 404
[08:47] <StevenK> And?
[08:47] <StevenK> Oh, I know. It's stuck in Debian NEW.
[08:47] <nenolod> no.
[08:47] <StevenK> Wait a few weeks, then
[08:47] <nenolod> it's not in NEW
[08:47] <nenolod> it is in SID.
[08:48] <nenolod> StevenK: as the fucking maintainer of audacious, i damn well know where it is.
[08:48] <StevenK> Ah, I was looking for the package name of audacious2
[08:49] <nenolod> yeah.  sorry for the confusion.
[08:49] <nenolod> we were originally going to run them side by side
[08:49] <StevenK> Right. The version of audacious in Karmic has Ubuntu changes, so it needs a merge
[08:49] <nenolod> since 2.0 series was originally meant more as a platform demo, than an actual finished product
[08:49] <nenolod> yeah. i'll do it.
[08:49] <nenolod> i need to up a fixed plugins though
[08:49] <nenolod> i made an oops
[08:49] <nenolod> :P
[08:50] <StevenK> Looks like someone else has done it
[08:51] <nenolod> well, plugins needs to be merged against pending 2.0.1-2
[08:51] <nenolod> otherwise audacious-plugins-dev convenience package becomes broken
[08:51] <nenolod> as i said, i made an oops
[08:52] <StevenK> But audacious-plugins is a seperate source?
[08:52] <nenolod> StevenK: yep
[08:53] <StevenK> That also needs a merge
[08:53] <nenolod> yep
[08:53] <nenolod> i've done it before in ubuntu
[08:53] <StevenK> I don't trust the audacious merge in https://bugs.edge.launchpad.net/ubuntu/+source/audacious/+bug/383271 either
[08:53] <nenolod> i need to go through and see what changes ubuntu has added on and if they are even relevant anymore, anyway.
[08:54] <nenolod> StevenK: yeah.  it's done incorrectly.
[08:54] <nenolod> SSE2 is safe to enable on x86_64, but...
[08:54] <nenolod> that's a new patch introduced
[08:54] <StevenK> I think it drops changes, but I haven't confirmed
[08:55] <nenolod> i'll look into it
[08:55] <nenolod> probably after audacious-plugins/2.0.1-2 goes up later today
[09:00] <nenolod> StevenK: i commented on the merge
[10:13] <loic-m> What's the bast way to ckeck what o put in build depends when packaging a new program?
[10:13] <loic-m> I checked http://www.debian.org/doc/manuals/maint-guide/ch-dreq.en.html#s-control , all methods are a bit confusing
[10:13] <siretart> look in the README or COMPILATION file in the package?
[10:14] <iulian> loic-m: The source should have some docs saying what packages it needs in order to build the program.
[10:14] <loic-m> siretart: there's no information there
[10:15] <iulian> loic-m: What about its homepage?
[10:15] <loic-m> iulian: no information either :(
[10:16] <siretart> loic-m: it is very hard to guess what build dependencies a package needs. if it is not documented, I generally inspect the source to understand how it works
[10:16] <iulian> Well, in this case I usually build it with pbuilder to see what dependencies it needs.
[10:16] <jpds> loic-m: Well, I guess pbuilder it until it works I guess :/
[10:16] <jmarsden> loic-m: Worst case, try building it in a base pbuilder chroot with no Depends: at all and see what fails, and go from there?
[10:16] <siretart> which is a good idea in any case in order to get an idea what the package is doing
[10:18] <loic-m> So each time the pbuilder fails, I add the missing bit to control? That sound doable, easier than read the source for me ;)
[10:18] <siretart> welcome to the dark side...
[10:18] <iulian> loic-m: Yes.
[10:19] <loic-m> ok, thanks
[10:19] <jmarsden> loic-m: Yes.  if you have a compiled binary you can also try running ldd on it so see what libraries it links to, for some extra clues?
[10:19] <siretart> there are indeed some wrapper around the open syscall that observe what header files a subprocess is trying to open and guesses on that bases what development package might be relevant
[10:19] <loic-m> jmarsden: I tried objdump -p /usr/bin/foo | grep NEEDED as the Debian maintainer guide suggest, but it gave me far to much dependencies
[10:20] <siretart> it still requires a bit of thinking
[10:21] <loic-m> ldd list is eevn bigger
[10:22] <loic-m> I'll try the pbuilder fail method first...
[10:24] <rawang> hi, when I use pbuilder to build package, but failed, and i want to dig it, and pbuilder remove the build environment, how can i keep it unremoved
[10:24] <loic-m> When I used objdump -p /usr/bin/foo | grep NEEDED, I tried filtering the libs in build-essential, but i still had far to much libraries. I just want to make sure I don't add useless build-depends
[10:26] <jmarsden> rawang: Would https://wiki.ubuntu.com/PbuilderHowto#Running%20a%20Shell%20When%20Build%20Fails%20(Intro%20to%20Hook%20Scripts) help you out?
[10:30] <loic-m> As a more general question, when reviewing on REVU, how do one check if the build-depends and depends in debian/control are correct (i.e. neither too much or too little)?
[10:31] <jmarsden> too little => package would not build in a pbuilder.  too many is harder to detect, you have to know, or try removing the ones you think are unnecessary and rebuild, as far as I know.
[10:33] <ultrafredde> Hi again, anyone feeling for a review of http://revu.ubuntuwire.com/p/task Would be appreciated. Really.
[10:44] <rawang> jmarsden, hey, big thanks, it helps
[10:46] <rawang> jmarsden, but it appears my problem is caused by fakeroot, since the build need to generate something with root privilege, but fakeroot can't do anything except get a root id
[10:49] <geser> rawang: have you the exact error message?
[10:57] <rawang> geser, sure , http://paste2.org/p/244640
[10:58] <rawang> geser, thanks a lot
[10:58] <rawang> geser, you will noticed at line 27, it said permission deny
[11:01] <loic-m> When a package need intltool to build, what's the difference between using intltool and intltool-debian? Is it just that -debian depends on less stuff?
[11:03] <loic-m> Or is the only difference that intltool-debian supports "Debconf template files" and intltool doesn't?
[11:05] <geser> rawang: my guess would be to set $HOME to something which can be written to (like /tmp) but better ask someone who is more familiar with mono packaging (like directhex)
[11:05] <directhex> moo?
[11:06] <directhex> aha, rawang has encountered a rather... common... issue
[11:06] <geser> directhex: see the paste http://paste2.org/p/244640 from rawang
[11:06] <directhex> export MONO_SHARED_DIR=$(CURDIR)
[11:07] <directhex> add the above to rules
[11:07] <rawang> geser, but this is not the first time I run into "permission deny" problem when I build package with "dpkg-buildpackage -rfakeroot", "sudo dpkg-buildpackage" resovle all
[11:07] <directhex> and add "rm -rf $(MONO_SHARED_DIR)/.wapi" to your clean rule
[11:08] <rawang> ok
[11:08] <rawang> directhex, in the debian/rules file?
[11:08] <directhex> although whatever the package is, should you be cooperating with pkg-cli-apps ?
[11:08] <directhex> oh... right, sorry
[11:08]  * directhex goes back to sleep
[11:08] <rawang> directhex, wow, thanks a lot! :)
[11:09] <geser> rawang: the buildd run the build as a user (and only parts as root with fakeroot) so you need to take care that your package doesn't write outside it's packaging directory
[11:09] <directhex> yes, debian/rules is the makefile. you need to override MONO_SHARED_DIR because mono has a simple evaluation for where to put the .wapi folder for processes
[11:11] <rawang> geser, but you know, I even failed at "debuild -S" at "permission deny" error, I have to use "sudo debuild -S" to update my .dsc file :(
[11:12] <directhex> rawang, right, you have files now owned by root
[11:12] <directhex> time for a big ol' "chmod -R"
[11:12] <rawang> ahhhh...
[11:13] <rawang> directhex, maybe "chown -R"  :)
[11:13] <directhex> bah!
[11:14] <rawang> errr
[11:17] <rawang> directhex, geser wooh, big thanks, after I add MONO_SHARD_DIR, it succeed to build :)
[11:18] <directhex> rawang, are these the same packages sshaw has been bugging me about?
[11:18] <rawang> directhex, heh, yeah, maybe
[11:18] <rawang> directhex, I'm not sure what packages he worked on :)
[11:19] <loic-m> When packaging a frontend, should I put the program it's a frontend of in Depends, Suggests or Recommends?
[11:19] <directhex> rawang, anyway, please make your source package available somehow for peer review
[11:20] <directhex> loic-m, can the frontend be used in any way, shape or form without the app it's a frontend for?
[11:20] <rawang> directhex, yeah, of course, now I successful build those packages, next I will put it on my ppa and REVU, hopefully you could take a glance to review it :)
[11:20] <loic-m> directhex: fact is it can start without the program, and you can configure the options and manage your collection of games without the program - but not play them
[11:21] <directhex> rawang, yes - but i won't advocate uploading mono-related packages directly to ubuntu (we prefer to upload to debian). revu's ui is nice enough for the review process though ;)
[11:21] <loic-m> directhex: it's a frontend for mame, so even without it can be usefull to manage a collection of roms
[11:21] <directhex> loic-m, then it sounds like a Recommends to me, especially since recommends are pulled in by default
[11:21] <directhex> certainly not suggests
[11:22] <rawang> directhex, ok, so what's your opinion?
[11:22] <rawang> directhex, make them available on debian first?
[11:22] <loic-m> directhex: thanks a lot
[11:23] <rawang> directhex, actually, I was planning to put them on ubuntu, and then debian, since ubuntu have a more friendly package promotion process and interface
[11:23] <directhex> rawang, well, yeah. file a request to join on https://alioth.debian.org/search/?type_of_search=soft&group_id=0&words=pkg-cli-libs&Search=Search
[11:24] <directhex> and generally be in #debian-cli on oftc
[11:24] <directhex> we can review your package and have it uploaded to debian, whereupon it gets pulled into ubuntu automatically
[11:24] <directhex> and then you only need to maintain it in one place which benefits the most users, as part of a team of maintainers
[11:24] <rawang> directhex, ok
[11:25] <gaspa> could someone please giveback ocaml-http and ocaml-lastfm ?
[11:25] <rawang> directhex, i have requested to apple pkg-mono before, but no one else response to me :)
[11:26] <directhex> rawang, hence the IRC suggestion, so people can put names to fac... well, nicks
[11:27] <rawang> directhex, sorry, but what it means above? :)
[11:29] <directhex> rawang, if you're in the IRC channel, then when meebey receives a join request, he can go "hm, anyone know who this Ray Wang guy is?" and get an answer
[11:29] <rawang> directhex, ok ,if someone knows me, I am accepted? :)
[11:30] <directhex> rawang, more or less
[11:31] <directhex> rawang, i'd recommend you file an ITP bug (intention to package) to further cement the relationship between you and the package
[11:31] <rawang> directhex, where should I file that bug?
[11:32] <rawang> directhex, say something like," I'm working on this package, hopefully someone won't duplicate this build" ?  :)
[11:33] <directhex> rawang, ITP bugs should be filed against the "wnpp" pseudo-package.
[11:33] <directhex> rawang, if you have a working mail server configured (and even if you don't, i suppose, you can send the result by hand) then run "reportbug -B debian wnpp"
[11:33] <rawang> directhex, I'm terribly sorry, what you said seems like new things to me :(
[11:33] <directhex> the wizard will help you fill in the standard ITP template
[11:34] <rawang> directhex, in debian's terminal?
[11:35] <directhex> rawang, well, in a terminal window. the "-B debian" allows it to run on non-debian distros
[11:35] <directhex> like ubuntu, which has a different bug reporting mechanism
[11:36] <rawang> directhex, so reportbug is a command, it could generate a wnpp template, you fill out the template, the command will help you to send it to somewhere?
[11:36] <directhex> yup!
[11:37] <rawang> directhex, thanks a lot, I never heard of this before :)
[11:37] <directhex> this allows you to start your package's life on a high note - the first changelog entry should be something like " * Initial release (Closes: #123456)" which means you get to close a bug on day one ;)
[11:38] <rawang> lol
[11:38] <directhex> rawang, once you're in pkg-cli-libs i can help with the packaging bits & bobs, as i can then write to the package directly before it gets uploaded
[11:39] <rawang> directhex, that would be awesome! thanks in advanced! :)
[11:41] <rawang> didrocks, i have one source package generate 2 packages, so when I first to *reportbug* , which package name I should use? or both?
[11:42] <slytherin> directhex: I added the information you asked to bug 378613. Let me know if there is anything more you need.
[11:43] <directhex> rawang, the source package name is the important one at this point
[11:43] <directhex> slytherin, thanks
[11:43] <rawang> ok, make sense
[11:44] <rawang> directhex, so i just need to file a ITP bug with my source package name for both binary packages, right?
[11:45] <directhex> rawang, right. just one bug. source is what matters at this point
[11:45] <rawang> ok, thank you
[11:45] <slytherin> directhex: The problem exists in Debian as well. Should I file a bug in Debian too?
[11:45] <directhex> slytherin, if it's a mono bug then yes, if it's a banshee bug then no
[11:47] <slytherin> directhex: how do I know?
[11:47] <directhex> you give me 3 minutes to compare to an amd64-generated empty repo ;)
[11:49] <directhex> hm... interesting
[11:49] <directhex> there's definitely a big difference between the two
[11:50] <directhex> slytherin, were you reproducing the issue on squeeze or sid?
[11:51] <directhex> hm, squeeze
[11:56] <slytherin> directhex: squeeze (testing).
[11:59] <directhex> slytherin, i have a sneaking suspicion that an sqlite bug is exposing a banshee bug
[12:05] <slytherin> he he
[12:07] <directhex> slytherin, okay, it seems the first-run database creation is not completing successfully. my DB has several values yours doesn't
[12:07] <directhex> slytherin, HOWEVER, here's the interesting bit - one of the values is 0 for me and NULL for you
[12:08] <slytherin> directhex: is that anyway arch dependent?
[12:09] <directhex> slytherin, well, it shouldn't be, but it's the only line which isn't simply values missing in your DB
[12:10] <hyperair> Build-Depends-Indep contains build dependencies for arch independent packages, right? if there's only one package, and it's arch indep, should i just dump everything into Build-Dep then?
[12:11] <directhex> hyperair, i would
[12:11] <hyperair> alright
[12:11] <hyperair> i can't remember why i ended up dumping more than half of the deps for bansheelyricsplugin in build-dep-indep
[12:11] <slytherin> hyperair: Build-Dep usually includes cdbs/debhelper and anything that is needed to run the clean target
[12:12] <hyperair> slytherin: i see.
[12:12] <hyperair> slytherin: but it's kind of pointless to separate it if you're only having one binary package, right?
[12:12] <slytherin> hyperair: it is not if you want to keep lintian happy.
[12:13] <hyperair> slytherin: i don't understand. isn't lintian happy if you dump everything in build-dep?
[12:13] <slytherin> hyperair: I don't think so. But check for yourself.
[12:14] <hyperair> hmm
[12:17] <directhex> slytherin, i'm going to forward the bug upstream, and bug them about it when they're awake
[12:18] <slytherin> directhex: thanks
[12:18] <directhex> slytherin, actually, i have an idea. are you in a position to test something for me?
[12:18] <slytherin> directhex: not right now. I am in office.
[12:18] <slytherin> directhex: drop me a mail if possible. I will do that tonight if I can.
[12:21] <directhex> slytherin, i've posted to the bug report instead
[12:22] <slytherin> directhex: checking
[12:25] <hyperair> slytherin: looks like lintian doesn't mind.
[12:38] <slytherin> directhex: I will try using your empty db tonight. And I guess I will wait for mono2.4 to migrate to testing. Do you plan to fix the bugs that are blocking the migration?
[12:40] <directhex> # mono is only 9 days old. It must be 10 days old to go in.
[12:40] <juanje> Hi, someone like to review any of these packages? http://revu.ubuntuwire.com/p/mount-systray  ||  http://revu.ubuntuwire.com/p/gedit-plugin-tloleo  ||  http://revu.ubuntuwire.com/p/backintime
[12:40] <directhex> so i need a time machine to fix that blocker ;)
[12:40] <StevenK> Or patience
[12:41] <StevenK> And since you use mono, you must have lots, since it's slow
[12:41] <slytherin> directhex: right but even after that there are two 'serious' bug which will block the migration
[12:41]  * StevenK hides
[12:41] <directhex> slytherin, the serious bug will be fixed in the next upload (likely to be Monday, since there's a new bugfix release due from upstream). the grave bug i can't work on without help from a porter, since i lack access to sparc hardware
[12:43] <slytherin> directhex: thanks for info
[12:44] <directhex> slytherin, i'm waiting for at least a -3 upload before requestsync to karmic, as -2 and below have an issue cleanly upgrading with aptitude
[12:44] <slytherin> hmm
[12:46] <directhex> slytherin, see, another reason i should be a DD sooner rather than later - access to funny machines to test things on ;)
[12:50] <slytherin> directhex: :-)
[15:16] <bddebian> Heya gang
[15:54] <iulian> Heya bddebian.
[15:58] <neurobuntu> hi!
[15:59] <neurobuntu> when building a package using cdbs and the variable "DEB_MAKE_CHECK_TARGET = test"  how can I generate the FTBFS error if the tests fail...
[15:59] <dholbach> Packaging Training with mvo in #ubuntu-classroom now!
[16:02] <azeem> neurobuntu: shouldn't it fail?
[16:02] <azeem> neurobuntu: if not, maybe the upstream build system does not error out if the checks fails
[16:02] <neurobuntu> azeem, I thought that it would but i've seen the tests fail but the packages still get built in the end
[16:03] <bddebian> Hi iulian
[16:03] <neurobuntu> azeem, I'll talk to upstream about it... but under normal conditions I shouldn't have to catch the errors from the test?
[16:03] <azeem> neurobuntu: well, check yourself
[16:03] <neurobuntu> ok
[16:03] <neurobuntu> azeem, thanks for your help
[16:04] <azeem> run "make test", and see the return value
[16:33] <directhex> dtchen, how big was your music collection?
[16:49] <mterry> vorian: Got a sec to talk about kio-gopher?
[16:53] <vorian> sure thing
[16:53] <vorian> mterry: sorry, yes :)
[16:54] <mterry> vorian: I was just doing some merge work and thought I'd hit it.  But it looks like the two packages (debian and ubuntu) have never really merged.  Debian uses just 1.3 numbering, we use 1.3-kde4.2.0 numbering.  Is there a good reason to keep that or can I just request a sync?
[16:54] <vorian> hmmm
[16:55] <vorian> is that the only difference?  I seem to recall other differences
[16:56] <mterry> vorian: Debian intentionally strips the -kde4.2.0 part in its watch file.  Um, seems to be the only difference after merging anyway
[16:56] <vorian> even in rules?
[16:57] <vorian> we should be using kde4.mk
[16:58] <mterry> vorian: Upstream uses /usr/share/pkg-kde-tools/makefiles/1/cdbs/kde.mk
[16:58] <mterry> vorian: We use /usr/share/cdbs/1/class/kde4.mk
[16:58] <mterry> vorian: Seems like a droppable change?
[16:58] <vorian> hmmm
[16:58] <vorian> i'll have to take a closer look
[16:59] <mterry> vorian: Yeah, I'll leave it to you then.  :)
[16:59] <JontheEchidna> That's a droppable change, kde4.mk was a fork we used in intrepid and jaunty
[17:00] <vorian> fantastic
[17:00] <JontheEchidna> in karmic we merged the one from pkg-kde-tools
[17:00] <vorian> yeah, so it should be syncable
[17:00] <vorian> ok, thanks JontheEchidna
[17:01] <mterry> vorian: OK.  I'll request a sync
[17:02] <mterry> vorian: But we don't care about stripping the version?  Do the -kde4.x.x releases change anything if the main version doesn't change?
[17:02] <JontheEchidna> oh, KDE usually updates the translations shipped with the -kde4.x.x releases
[17:03] <vorian> yeah, we get that versioning from upstream
[17:03] <JontheEchidna> so there is probably some merit in keeping the -kde4.x.x version
[17:03] <vorian> It's not a huge deal to drop in on extragear stuff
[17:03] <vorian> l10n doesn't ship for extragear
[17:04] <JontheEchidna> right, the apps themselves ship their translations
[17:04] <JontheEchidna> and afaik we don't strip them from universe packages
[17:05] <vorian> mterry: your call - but there is merit to staying in sync with debian :)
[17:05] <JontheEchidna> that is true too, losing slightly-updates translations for barely-maintained extragear isn't that big of a deal :)
[17:05] <mterry> vorian: I'd sync it if there's no great loss.  But I wonder why upstream strips.  Maybe I'll file a debian bug about that
[17:06] <vorian> mterry: or join #debian-kde and ask plusing
[17:06] <vorian> pulsing, even
[17:07] <vorian> bleh, see JontheEchidna, i can't type
[17:07] <vorian> pusling
[18:16] <Stupendoussteve> If I run a line like mpi-default-bin [!lpia] openmpi-bin [lpia], would that prevent mpi-default-bin as pulling openmpi-bin as a dependency for other architectures?
[18:16] <Stupendoussteve> in build-depends that is
[18:18] <binarymutant> what provides the cdbs rule uploaders.mk ?
[18:22] <geser> {gnome,ruby}-pkg-tools have one such named file
[18:22] <binarymutant> geser, thank you I think I found it
[18:28] <binarymutant> I'm fixing a ftbfs but the package doesn't seem to conform to python policy, should I fix this as well or let the real maintainer handle it?
[18:30] <geser> try to keep the Ubuntu delta minimal, so change only as far as necessary
[18:31] <geser> unless the package in maintained by QA in Debian, then you can do more and forward the patch to Debian so it can hopefully be synced again soon
[18:33] <binarymutant> your always great help geser thank you
[18:42] <binarymutant> geser, do you have time to sponsor this patch? https://bugs.launchpad.net/ubuntu/+source/deskbar-applet/+bug/383675
[18:43] <binarymutant> actually...
[18:50]  * DBO pokes directhex 
[18:52] <directhex> evening jason. what's on your mind?
[18:52] <DBO> was hoping I might be able to get a recommendation for a icon theme packager
[18:53] <geser> binarymutant: where is the promised debdiff in that bug?
[18:53] <DBO> Elementary Icons really need a PPA =)
[18:54] <binarymutant> geser, a control.in was getting me :(   but it's attached now
[18:56] <directhex> DBO, i don't really have any experience with packaging that kind of thing
[18:57] <DBO> i know, you only package insanely hard things =P thats why I was looking to see if you knew someone we could poke
[18:57] <directhex> pochu, is debian bug #531870 about removing libgda2 entirely from the archive? if so i'll need to beat upstream
[19:01] <pochu> directhex: yes, it is
[19:01] <pochu> I talked to Mirco about it, he told me to report the bug
[19:06] <geser> binarymutant: I just noticed that I can't sponsor it, you need a core-dev for that (ubuntu-main-sponsors). And don't forget to close your bug in your changelog entry
[19:06] <binarymutant> ah okay, thanks for trying geser
[19:09] <binarymutant> any ubuntu-main-sponsors in here?
[19:11] <geser> for this package you might have better chances to find one in #ubuntu-desktop
[19:12] <binarymutant> thanks again geser, always the best help :)
[19:13] <bencrisford> How much work constitutes universe-contributor rank?  I appreciate I probably have far to go, but I am just wonderinhg
[19:15] <binarymutant> bencrisford, ask your sponsors they're always really great help with that sort of information
[19:15] <bencrisford> ok :)
[19:15] <bencrisford> I haven't actually had any sponsors yet binarymutant :(, although I have subscribed them to a couple of bug fixes of mine ;)
[19:16] <geser> bencrisford: as a hint 2-3 months of visible contributions (e.g. sponsored uploads)
[19:16] <bencrisford> geser: Ok. ty ;)
[19:17] <directhex> pochu, filed the bug upstream back in september ;)
[19:18] <pochu> directhex: :)
[19:18] <pochu> link?
[19:19] <geser> bencrisford: and if manage to get an sponsored upload each week (on average) that might be considered enough (but the more the better :)
[19:19] <directhex> pochu, https://bugzilla.novell.com/show_bug.cgi?id=430332
[19:20] <bencrisford> geser: I'm trying to fix a bug at least every two days at the moment.  But i doubt ill be able to keep that up, im quite busy at school atm
[19:23] <geser> bencrisford: no problem. that aren't any hard numbers, if you show that you contribute and do this over some time you should get u-c-d without problems
[19:24] <bencrisford> geser: Ok ;), thanks for your advice/help :)
[20:54] <studio32> I get this error: W: rumor: info-document-missing-dir-section usr/share/info/rumor.info.gz
[20:54] <studio32> http://pastebin.com/m72856a2
[20:55] <ausimage> Any python gurus lurkin? I would like some feedback on my package http://revu.ubuntuwire.com/p/soovee
[20:56]  * ausimage notices that REVU has issues with Python packaging in general :/
[20:56] <ausimage> or Python in general :(
[20:58] <ajmitch> ausimage: that does look problematic
[20:59] <ausimage> yeah...
[20:59]  * ajmitch checks on how you destroyed REVU
[20:59] <ausimage> :O
[20:59] <ajmitch> killed it dead!
[21:00] <ausimage> huh? All I did was dput my package for review.... LP has never had issues with the task
[21:00] <ajmitch> obviously REVU has some bugs in handling that stuff :)
[21:01] <ausimage> I saw that
[21:01] <vorian> anyone seen an error like this one - dh_install: plasma-widgets-workspace missing files (), aborting
[21:02] <ausimage> vorian that sounds like my issue with multi packaging :/
[21:03] <ausimage> perhaps a file in an install manifest is missing?
[21:03] <vorian> no, i know how to fix those
[21:03] <vorian> i've never seen this error
[21:05] <ajmitch> ausimage: sadly I don't have time to dig into the REVU error right now, might look at it in an hour or so
[21:05] <ausimage> ahh
[21:05] <ajmitch> though your changelog looks well-formed & shouldn't be breaking the parsing
[21:06]  * ausimage also was looking for a deep review of his effort... so he can make the necessary changes to improve his python app and skills 
[21:07] <ajmitch> until REVU is fixed people won't be able to see your package
[21:08] <ausimage> :O
[21:09] <ajmitch> first suggestion is to not upload it as a native package, where you have to change the whole version number for every packaging change
[21:10] <ausimage> hmmm... you mean to leave the version off?
[21:11] <ausimage> the new package that is there is because of code changes made after discovering an oversight
[21:13] <ajmitch> no, I mean to add on the debian versioning
[21:13] <ajmitch> such as 1.04-0ubuntu1
[21:13] <ausimage> k
[21:13] <ajmitch> so that you only change the -0ubuntu1 for packaging changes
[21:14] <vorian> ah, found it
[21:14] <vorian> there was an extra new line
[21:14] <ajmitch> vorian: tricksy
[21:14] <vorian> aye,
[21:14] <ausimage> I can do that in the future ajmitch
[21:14] <ajmitch> and it was set to complain about missing files?
[21:14]  * ausimage seems vindicated on that one ;)
[21:14] <vorian> always, can't have any hotness missing
[21:15] <vorian> ajmitch: i knew it was the .install file - I just didn't understand why i was getting that error
[21:15] <vorian> er, ausimage
[21:15] <vorian> :P
[21:15] <ausimage> :D
[21:18] <ausimage> ajmitch: I guess that means two changelogs unless it is kosher to upload -0ubuntu1 to a PPA :/ Besides I thought ppa1 was on that file :?
[21:21] <ajmitch> upload -0ubuntu1~ppa1 to a PPA
[21:21]  * ajmitch must really go to work now, will be back later
[21:45] <stgraber> cody-somerville: ping
[21:45] <cody-somerville> stgraber, pong
[21:46] <stgraber> cody-somerville: I'm helping someone with an universe SRU, the bug is opened in LP with an attached debdiff (taken from the same bugfix in Debian), what should happen next ? Can I upload that directly to proposed or is that something motu-sru should do or approve first ?
[21:51] <savvas> what does "Chroot problem" mean? https://edge.launchpad.net/ubuntu/+source/cgal/3.4-4ubuntu1/+build/1059619
[21:51] <savvas> ah, E: There are problems and -y was used without --force-yes
[22:02] <geser> savvas: usually that it should be retried later
[22:02] <dtchen> you're probably hitting the coreutils bug
[22:03] <dtchen> (haven't looked at the log yet)
[22:03] <savvas> ok thanks :)
[22:50] <loic-m> Do we support the Sparc arch for karmic?
[22:50] <directhex> loic-m, if we do, i could do with access to a sparc box :/
[22:51] <dtchen> directhex: not sure i understand your earlier question regarding "how big was your music collection?"
[22:52] <directhex> dtchen, i'm trying to get a proper handle on media player RAM scalability, i heard you had lots of music
[22:53] <dtchen> directhex: ah. currently my library in banshee is ~4K songs. earlier banshee and rhythmbox libraries have been somewhere between 60-600K songs, but those machines are long gone.
[22:54] <dtchen> (it's always easier to store massive libraries when you don't have to tote a laptop with limited store)
[22:56] <superm1> directhex, can't you just write a simple $(language) script that would to and make a copy of a few files many times and modify the id3 tags to simulate a large library?
[22:57] <superm1> s/to/go/
[22:57] <directhex> superm1, yeah, probably..... effort :'(
[22:57] <directhex> superm1, easier if i found someone with a big collection just lying around on irc ;)
[22:58] <dtchen> directhex: think greg-g has a fairly sizeable library
[22:58] <superm1> directhex, right.  well if you don't find such a person, i'm guessing this would be like a 15 line script or so to walk a directory and do these tasks
[23:14] <porthose> directhex: not sure if this will help but I have 13K songs on my ampache server
[23:14] <directhex> porthose, that's about 10k more than me, so could provide an interesting measure. if you're bored enough
[23:15] <porthose> directhex: what do yea need?
[23:16] <directhex> porthose, just add the whole lot to the library for whichever gnomish media library apps you have access to, and read off the "writable memory" column from gnome-system-monitor whilst playing a sample track
[23:17] <directhex> porthose, i want to know to what degree the numbers i have for my 3k collecton are representative
[23:18] <porthose> directhex: ok may take a while
[23:29] <porthose> directhex: I'm importing everthing into rythembox, I'll give you a ping when it is complete and I have some numbers for yea ;-)
[23:30] <directhex> yays!
[23:30] <directhex> porthose, rhythmbox is especially interesting as it's the only major player written in a "low level" language - but it also uses XML for its library storage and loads the entire library into one liststore
[23:32] <doctormo> Hey all
[23:33] <directhex> hello doctormo
[23:33] <somaunn> doctormo, hello
[23:33] <doctormo> I'm trying to enable debugging in jabberd2 (which should be a package option somehow) but anyway, setting DEB_BUILD_OPTIONS didn't seem to want to work
[23:34] <doctormo> Ofcourse if anyone is good with jabberd already, perhaps they can tell me why it never seems to want to work.