[06:35] <dholbach> good morning
[06:36] <iulian> Morning dholbach.
[06:36] <iulian> How is it going?
[06:36] <dholbach> hiya iulian
[06:36] <dholbach> very good - how are you?
[06:36] <iulian> I'm having breakfast in a minute. ;)
[06:37] <dholbach> sounds good :-)
[06:38] <iulian> Tastes good.
[06:38] <dholbach> yeah
[07:09] <didrocks> good morning o/
[07:10] <iulian> 'ey
[07:20] <geser> good morning
[07:37] <dlynch> good morning / afternoon, I would like some advice on naming a package, where I am the upstream author
[07:37] <dlynch> my code is called "Rapid Photo Downloader"
[07:37] <dlynch> I see there is already a package called rapidsvn
[07:38] <dlynch> I can see why it might be unhelpful to call the package "rapid", since that conveys little in the way of meaning
[07:39] <dlynch> I have no problem with the script to launch it being called rapid-photo-downloader
[07:39] <dlynch> but that seems rather long for a package name
[07:40] <pmjdebruijn> dlynch: what does it do?
[07:40] <dlynch> is it perfectly fine to have a package name 'rapidphoto' and a script called as rapid-photo-downloader?
[07:40] <pmjdebruijn> doesn't be a problem
[07:40] <pmjdebruijn> shouldn't*
[07:40] <pmjdebruijn> dlynch: the point is, what is the package called in other distro, try to keep things consistent
[07:41] <dlynch> pmjdebruijn: it downloads images from memory cards / portable storage devices, renaming and backing up
[07:41] <dlynch> http://damonlynch.net/rapid/
[07:41] <dlynch> it is not yet in any distro
[07:41] <pmjdebruijn> ah
[07:42] <pmjdebruijn> dlynch: with "downloading" people tend to think of the "Internet" instead of memory cards
[07:42] <dlynch> pmjdebruijn: that might be the case, but among photographers it's a common usage for th term
[07:43] <pmjdebruijn> dlynch: I'm a photographer as well, still that wasn't my first thought :)
[07:44] <dlynch> ok very good then you can be one of my early users ;)
[07:44] <pmjdebruijn> haha
[07:44] <pmjdebruijn> dlynch: may I privmsg you?
[07:44] <dlynch> pmjdebruijn: yes
[07:50] <dholbach> hi geser - did you see my libxi-dev / x11proto-xext comments? do you think they make sense?
[07:52] <dholbach> erm
[07:52] <dholbach> hang on
[07:58] <geser> dholbach: yes, I've seen them
[07:59] <geser> dholbach: there is already a bug about it: bug 273386
[07:59] <dholbach> geser: my mistake - nothing to sync there, but I think the bug should be fixed in x11proto-xext
[07:59] <dholbach> geser: I'll follow up on the Debian bug
[07:59] <geser> I've asked in #ubuntu-x yesterday about that bug and was advised to add libxi-dev to the affected packages
[08:00] <dholbach> geser: did they offer any reason?
[08:00] <dholbach> XTest.h includes XInput.h
[08:00] <geser> dholbach: http://irclogs.ubuntu.com/2009/03/22/%23ubuntu-x.html
[08:00] <dholbach> it's going to fail for each package that includes XTest.h and does not make direct use of xi itself
[08:01] <dholbach> argh
[08:01] <dholbach> that sucks
[08:10] <geser> so what do you propose to do with it?
[08:14] <Toadstool> good morning
[08:24] <dominiks> morning
[08:24] <dholbach> geser: I'll upload the patches as they are
[08:25] <dholbach> geser: somebody should take it up to upstream though - there should be a clever separation somehow :/
[08:29] <james_w> hello all
[08:30] <james_w> seems like not many people read /away messages :-)
[08:30] <dholbach> james_w: lot to catch up? :)
[08:30] <james_w> oh yes :-)
[09:30] <binarymutant> how does patches.ubuntu.com work? it has a reversed patch in it from me
[09:47] <c_korn> how does it come I am on the changelog of that package? https://launchpad.net/ubuntu/jaunty/+source/apt-cacher-ng/0.3.4-1
[09:47] <c_korn> I did not change anything
[09:48] <\sh> c_korn: did you file eventually the sync req?
[09:48] <c_korn> ehm, yes
[09:49] <\sh> c_korn: that's why...Changed-By: is the entry you see there from the .dsc file
[09:49] <\sh> moins btw :;)
[09:49] <c_korn> moin :P cool
[09:58] <\sh> bah...life sucks...colleague died on saturday, heart stroke, and another colleague became daddy of an healthy boy...
[10:00] <cody-somerville> \sh, I assume your colleague becoming a daddy of a healthy boy is a positive thing, yes? :)
[10:02] <\sh> cody-somerville: of course..but all in all it reminds someone, that life's just too short...we just had a coffee with the guy who died on friday..and now he's just gone...
[10:03] <cody-somerville> mmm... I know the feeling.
[10:03] <\sh> cody-somerville: anyways..back to business...do you know how I can solve xfce in jaunty to work again with floss ati drivers and dual screen setup? gnome just works with xrandr setup...
[10:03] <cody-somerville> \sh, Xfce should just work as well.
[10:03] <cody-somerville> What problems are you experiencing?
[10:03] <cody-somerville> (xfce uses xrandr too)
[10:04] <\sh> cody-somerville: during startup I can see the two mice turning around...and then nothing...I have to sysrq to leave xfce at this stage
[10:04] <cody-somerville> Well, thats odd.
[10:04] <\sh> cody-somerville: if it's just a "rm .xfce" or whatever...
[10:04] <cody-somerville> \sh, Can you pastebin your ~/.xsession-error
[10:05] <cody-somerville> oops, forgot the s on that end there
[10:05] <\sh> cody-somerville: looks like that I have to empty my .xsession-errors first and relogin into xfce...to give you what you need :)
[10:07] <\sh> give me a minute...brb
[10:08] <c_korn> the upload of apt-cacher-ng on sparc fails because of this: http://launchpadlibrarian.net/24246535/cb1TWHeZAb1ZYclOUas44ivnbEl.txt
[10:08] <c_korn> what does that mean?
[10:08] <cody-somerville> It means there is a disturbance in the soyuz.
[10:13] <c_korn> hm, same happens for ia64
[10:13] <cody-somerville> Has maybe a newer version been uploaded and built?
[10:14] <\sh> cody-somerville: hmm... I won't get a .xession-error file for xfce...now I just rmed .config/xfce4 and .config/xfce4-session and now it works
[10:14] <cody-somerville> doh
[10:14] <cody-somerville> So much for bug fixing ;p
[10:14] <\sh> right
[10:17] <cody-somerville> c_korn, where did you get that link btw?
[10:20] <c_korn> cody-somerville: there isn't a newer version in debian. I got that link in a mail
[10:20] <cody-somerville> c_korn, Can you forward me the e-mail?
[10:21] <cody-somerville> actually, nvm
[10:22] <c_korn> cody-somerville: forwared
[10:23] <cody-somerville> ok, thanks
[10:39] <binarymutant> how does patches.ubuntu.com work? it has a reversed patch in it from me and I was wondering if I could switch that patch out for the right one
[10:40] <directhex> binarymutant, patches.ubuntu.com just shows patches extracted from the source package in the archive
[10:40] <directhex> binarymutant, i.e. file a bug on launchpad
[10:41] <binarymutant> directhex, I did file a bug in the sponsor queue with a debdiff but the first one I attached was reversed and managed to find it's way to patches.ubuntu.com
[10:42] <directhex> binarymutant, what's the package?
[10:42] <binarymutant> directhex, charm
[10:42] <directhex> charm-1.9.1/debian/patches/01_hyphens.dpatch ?
[10:43] <binarymutant> charm_1.9.1-0ubuntu1.patch	
[10:44] <binarymutant> it came from here https://bugs.launchpad.net/ubuntu/+source/charm/+bug/345200 originally, but i've updated it there
[10:46] <directhex> i don't see what's unexpected here. 1.9.1-0ubuntu2 is not in the archive yet. charm_1.9.1-0ubuntu1.patch is provided as-is from the version in the archive, 1.9.1-0ubuntu1
[10:46] <POX> charm *was* accepted in Debian
[10:46] <POX> and it's fixed there
[10:47] <binarymutant> ^ hey POX
[10:47] <directhex> so it should be requestsynced, assuming matching orig
[10:48] <binarymutant> well I did the debdiff since it was stuck in debian's new queue at the time but I can request sync as of today
[10:51] <binarymutant> should I have kept the name of the debdiff the same as what's in the repo? or should I have changed the version since it's an almost rewrite?
[10:51] <POX> binarymutant: btw, in next version you'll have to switch to python-support
[10:51] <POX> (or find another sponsor ;-P)
[10:52] <Mewcenary> Good morning, everyone !
[10:52] <binarymutant> POX, I've been silently following that thread on the list, and I will
[10:52] <POX> great
[11:07] <dholbach> geser: I'm just in #ubuntu-x talking with jcristau
[11:38] <dholbach> geser: http://paste.ubuntu.com/135963/
[11:38] <dholbach> gthumb and xnee FTBFS unrelatedly
[11:42] <\sh> do we have a list of ftbfs now?
[11:42] <WalterMundt> (crosstalk from #ubuntu+1 since this is on Jaunty; issue may predate Jaunty according)
[11:43] <WalterMundt> I'm starting some dev work on top of libtheora, and it seems the libtheora-dev packages are missing some pieces
[11:43] <WalterMundt> namely (a) theora/codec.h which is referenced by the provided packages are missing some pieces
[11:43] <WalterMundt> namely (a) theora/codec.h which is referenced by the provided theora/theora{enc,dec}.h files
[11:43] <WalterMundt> and -- though this might belong in the binary package (b) /usr/lib/libtheora{enc,dec}.so symlinks
[11:43] <WalterMundt> symlinks with no version are not needed to run compiled applications, but you need them for building with -ltheoradec and -ltheoraenc to work
[11:44] <dholbach> \sh: no, I was just trying to figure out which source packages include XTest.h but don't implicitly or explicitly build-dep on libxi-dev - totally unscientific, and still discussing with jcristau
[11:44] <WalterMundt> all of this stuff is only needed to build apps running the "new" libtheora1 API, which might explain why they haven't been caught yet
[11:44] <\sh> dholbach: do you happen to know when a complete archive rebuild is started? .. I know it's too late in jaunty cycle ;)
[11:45] <dholbach> \sh: no, sorry, no idea
[11:45] <Laney> the release schedule lists one for the 9th
[11:45] <Laney> "Rebuild Test"
[11:46] <\sh> ah .. i didn't see that last time I checked
[11:48] <dholbach> \sh: https://lists.ubuntu.com/archives/ubuntu-autotest/ might be interesting
[11:50] <\sh> dholbach: yepp...slangasek said just about the archive rebuild for main, not knowing about a rebuild of universe
[11:51] <dholbach> yep, saw it
[11:52]  * \sh runs into every problem someone don't want to have ;) yesterday, I tested system-config-kickstart and failed
[11:54] <\sh> and last friday the regression with dmraid and hardware raid controllers...thx to colin and his fix...but I wonder who is testing real server hardware before a release of our distro...hopefully the chats between HP and C. will change some things
[12:12] <siretart`> \sh: hi there.
[12:12] <siretart`> \sh: did MrFai already contact you?
[12:13] <\sh> siretart`: nope
[12:13] <\sh> siretart`: or at least I didn't read his mail ;)
[12:14] <\sh> siretart`: got his email
[12:15] <siretart`> ok
[12:17] <dholbach> geser: I'll make libxtst-dev Depends on libxi-dev
[12:17] <\sh> siretart`: answered :) so yes, we need FAI back at least for the next LTS (that's a good plan)
[12:19] <dholbach> geser: or rather see if they do it in Debian too
[12:20] <siretart`> great!
[12:38] <WalterMundt> I'm attempting to patch the issue I ran into earlier and test via "bzr builddeb", but it doesn't seem to be extracting the orig tarball into the build tree; what can I do to troubleshoot this?
[12:41] <slytherin> WalterMundt: which package are you talking about? is the packaging maintained in some bzr repository?
[12:42] <Laney> rawr
[12:42] <WalterMundt> slytherin: libtheora @ http://bzr.debian.org/bzr/pkg-xiph/libtheora
[12:45] <popey> rawr indeed
[12:46] <slytherin> WalterMundt: I am not sure how bzr builddeb works. In fact I am not used to this 'build-from-packaging-repository' concept.
[12:46] <james_w> WalterMundt: what's the package?
[12:46] <WalterMundt> slytherin: fair enough; if you were using debuild and it had this result how would you proceed?
[12:46] <james_w> oh
[12:47]  * james_w slaps himself
[12:47] <WalterMundt> basically I get in the build dir a libtheora-1.0 subdirectory with just the debian/ directory in it
[12:47] <james_w> WalterMundt: add "--merge" to the command line
[12:47] <james_w> the branch owner hasn't quite set it up fully
[12:47] <WalterMundt> james_w: okay, will they
[12:47] <WalterMundt> er, try
[12:48] <WalterMundt> that seems to have fixed it, thanks :)
[12:49] <WalterMundt> it's compiling now, which is a good sign
[12:50] <WalterMundt> as I understand it, once I get this working, I can toss a branch on lp and attach it to https://bugs.launchpad.net/ubuntu/+source/libtheora/+bug/347235 which I just filed, right?
[12:51] <WalterMundt> ouch
[12:52] <WalterMundt> No rule to make target `draft-ietf-avt-rtp-theora-00.xml', needed by `all-am'. <-- said xml file is mentioned as having been removed due to DFSG.  Hmm...
[12:53] <WalterMundt> oh, no, it was a different one
[12:53] <WalterMundt> that one is not mentioned...
[12:53] <hyperair> if it's been removed via dfsg, patch the Makefile.am/in to not look for it
[12:53] <WalterMundt> yeah, working on it
[12:54] <WalterMundt> odd, this is totally unrelated to the issue I'm working on
[12:54] <hyperair> =\
[12:54] <Laney> such is the fun of touching packages sometimes
[12:54] <hyperair> i noticed something very odd the other day
[12:54] <Laney> discovering unrelated brakage
[12:55] <hyperair> a package i got uploaded to ubuntu failed to build on 3 archs out of 6. i emailed the upstream author, he fixed the issue, but before i could upload the fix, all the FTBFS'd archs fixed themselves.
[12:55] <hyperair> i don't know what happened ._.
[12:55] <hyperair> does soyuz ever trigger a rebuild on its own?
[12:55] <Laney> yes
[12:56] <Laney> every now and again all FTBFS are retried
[12:56] <hyperair> i see
[12:56] <hyperair> but it's very strange, the bug was supposed to be upstream
[12:56] <hyperair> something about g_atomic_set being a macro
[12:56] <slytherin> WalterMundt: I believe an upload of gst-plugins-good0.10 has happened after libtheora upload. Can you check that. Because if that is correct then the absence of files has not affected any build.
[12:56] <hyperair> i don't know how it ended up fixed on its own
[12:57] <WalterMundt> slytherin: that's precisely my contention
[12:57] <hyperair> well either way considering that between 2.0 and 2.0.2, that's the only change, i'll just not submit the diff.gz to ubuntu for the time being and focus on getting it into debian
[12:57] <WalterMundt> slytherin: the missing files ONLY affect build which rely on the "new" Theora API
[12:57] <WalterMundt> slytherin: existing code running on the "legacy" API doesn't reference any of the missing files
[12:57] <slytherin> WalterMundt: yes, I just read the link you pointed to.
[12:58] <WalterMundt> slytherin: does gst-plugins-good us the new API?  I don't know, but any reference to theoradec.h would indicate so
[12:58] <hyperair> i just have one issue: there's an ITP filed by someone august last year, and no activity since then =\
[12:58] <WalterMundt> if that's the case, I'm mistaken about anything being broken
[12:58] <slytherin> WalterMundt: I am not sure. I will have to check release notes. Have you filed bug against debian already?
[12:59] <WalterMundt> no, I haven't
[12:59] <WalterMundt> I just discovered this last night; will propagate the bug to debian in a bit since it looks like this package is imported directly
[13:05] <WalterMundt> in any case, thanks to help from this channel, I think I will shortly have a package on my system that meets my needs while any discussion of the bug and the merits of adding the files are discussed, which I appreciate
[13:10] <slytherin> WalterMundt: my mistake, theora is in -base plugins and the last release of -base happened 2 months ago. There is no indication in release notes that it uses new theora api.
[13:11] <slytherin> WalterMundt: and you will get answer here why the build didn't fail - http://bugzilla.gnome.org/show_bug.cgi?id=563718
[13:18] <slytherin> anyone form motu-release team here?
[13:21] <ScottK> Sure
[13:23] <slytherin> ScottK: I plan to bring gst-plugins-ugly-multiverse0.10 (which creates a binary package with only lame plugin) in sync with gst-plugins-ugly0.10 source wise. Will I need to follow the usual freeze exception process?
[13:23] <mehdid> hi, can a non-ubuntu-developer (nor motu) but debian maintainer assign itself a bug in launchpad?
[13:24] <directhex> yes
[13:24] <slytherin> mehdid: why not, if he plan to fix the bug in debian package along with some other bugs then sure.
[13:24] <Mewcenary> On that note, how do I get privs to be able to change a bug priority to, say, "Wishlist" ?
[13:25] <mehdid> slytherin: ok... thank you for the answer
[13:25] <ScottK> slytherin: Yes.
[13:25] <directhex> Mewcenary, ask nicely in #ubuntu-bugs is a good start, afaik
[13:26] <Laney> you need to join the ubuntu bugcontrol team
[13:26] <slytherin> ScottK: Ok. I thought we had some kind of standing freeze for gstreamer packages.
[13:27] <ScottK> slytherin: Not that I'm aware of.
[13:27] <Mewcenary> Thanks -- I am a memeber of BugSquad but I guess that is not the same thing?
[13:27] <slytherin> ScottK: anyway, I will do the needful today.
[13:27] <ScottK> slytherin: The only one it might fall under is Gnome.
[13:27] <Mewcenary> Ah, I noticed the MOTD in #ubuntu-bugs.
[13:27] <Mewcenary> Thanks you, Laney and directhex.
[13:28] <Laney> np
[13:28] <directhex> high five, Laney!
[13:28] <directhex> o/
[13:28] <Laney> GO TEAM!
[13:28] <Laney> \o
[13:28]  * Mewcenary grins.
[13:29] <Mewcenary> One thing at a time, you guys haven't got me to superhuman levels in package management just yet.
[13:29] <Laney> you don't have to do triaging and packaging
[13:29] <Mewcenary> I want to do packaging, I'm a developer at heart :)
[13:29] <Mewcenary> But involved with bugs so I can get a better feel for the whole process.
[13:30] <Laney> I just triage bugs that I happen upon while doing other things
[13:30] <Laney> don't go out looking for them explicitl
[13:30] <Laney> y
[13:30] <Mewcenary> I've mostly been finding them when looking out for 'easy' requests for packaging.
[13:32] <directhex> the great thing about karmic is the release after it is an LTS release beginning with "l". which should hopefully mean lemurs
[13:32] <directhex> lemurs rule
[13:32] <dominiks> Mewcenary: hey, you can take a look at http://www.debian.org/devel/wnpp/ if you are looking for some packaging work :p
[13:33] <Mewcenary> dominiks: I'm not running a pure debian system though, wouldn't that get in the way?
[13:33] <directhex> Mewcenary, nah, working with debian is better than working against it
[13:33] <directhex> Mewcenary, that's why god gave us KVM/VBox/VMWare
[13:33] <dominiks> Mewcenary: im not sure.. but i thing packaging in Debian directly is prefered way :)
[13:33] <dominiks> think*
[13:34] <Laney> yes
[13:34] <Laney> but creating new packages isn't the best way to get started really
[13:34] <Laney> best to fix some of the bugs we already have
[13:34] <dominiks> yeah fair enough
[13:34] <Mewcenary> I did submit a patch...
[13:35] <Mewcenary> Lemme find...
[13:35] <Laney> good
[13:35] <Mewcenary> I t hought best to submit patches than re-built packages to begin with.
[13:35] <Mewcenary> https://bugs.launchpad.net/ubuntu/+source/gwibber/+bug/347152
[13:36] <Mewcenary> directhex: I'm a big fan of VirtualBox at the moment.
[13:37] <directhex> Mewcenary, you can learn many packaging semantics by doing a full-on update/test/debdiff for changes you make
[13:37] <directhex> Mewcenary, i.e. prep a new package revision, if needed add a patch system, etc
[13:38] <Mewcenary> I'll keep an eye out for 'easy' bugs to fix, seems to be a bit of a learning curve either way.
[13:39] <Laney> search for the "bitesize" tag
[13:40]  * slytherin wishes that wesnoth 1.6 be in jaunty. :-D
[13:41]  * Mewcenary searches for bitesize.
[13:41] <Mewcenary> Thanks for the tip, Laney.
[13:42] <Mewcenary> This one looks simple enough ;)
[13:42] <Mewcenary> https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/332068
[13:43] <Laney> Mewcenary: If you want to fix that one please do so in Debian
[13:43] <Laney> it's too minor to maintain in Ubuntu
[13:44] <Mewcenary> I understand, then eventually it will flow downstream?
[13:44] <Laney> correct, we'll get it next time we update
[13:44] <Mewcenary> Looks like I will be installing Debian in a VM tonight then :)
[14:06]  * ScottK would appreciate it if someone who knows what they are doing does an upgrade Gnash to 0.8.5 (See Bug #338074 for details)
[14:07] <Laney> huh, weird
[14:08] <Laney> I thought the package had to be prepared and tested before exceptions would be granted
[14:08] <directhex> Laney, special exceptions for packages related to rob millan? :p
[14:08] <ScottK> Laney: Generally that's true.  In this case we got ahead of ourselves.
[14:09] <ScottK> Laney: We clearly want the latest Gnash release, so I think it's fine.  It just needs someone to provide it.
[14:10] <\sh> siretart`: could you add me back to ubuntu-fai team, pls? :)
[14:11] <Mewcenary> I notice that bug has a debdiff attached, so is it just a case of applying that to the current package source?  Is it 'trusted' ?
[14:11] <bddebian> Heya gang
[14:13] <iulian> Hello bddebian.
[14:13] <bddebian> Hi iulian
[14:13] <Laney> Mewcenary: Not at all if it hasn't been uploaded
[14:15] <\sh> oh da bddebian ;)
[14:15] <bddebian> Heya \sh
[14:18] <ScottK> Also for a new upstream we want a diff.gz for the package, not a debdiff.
[14:18] <ScottK> That's been asked for but not provided.
[14:28]  * Mewcenary flicks through the Debian list of projects wanting adoption.
[14:32] <soren> Mewcenary: Are you into networky GNOME things?
[14:33] <Mewcenary> soren: Depends... what sort of networky? :)
[14:34] <soren> network-manager-{openvpn,vpnc}
[14:35] <Mewcenary> I use vpnc for my work VPN, so could potentially help.  Unfortunately th ough, I am coming at this with zero package experience other than the walkthroughs and 'playing' I have been doing to date.
[14:35] <Mewcenary> So looking for a suitable project which will help me grow.
[14:35] <soren> Ah.
[14:36] <Mewcenary> So I@m thinking to start small and easy.
[14:37] <binarymutant> Mewcenary, lxsplit is small and easy, and needs to be in Debian/Ubuntu
[14:39] <binarymutant> should I continue with my debdiff plan to get my Debian version of a package into Ubuntu or should I just requestsync it? I've already set up this https://bugs.launchpad.net/ubuntu/+source/charm/+bug/345200 but my package in Debian made it out of the new queue last night
[14:41] <ScottK> binarymutant: Is it in Debian now and does it need any Ubuntu changes?
[14:43] <binarymutant> ScottK, its in Sid now, the one in Ubuntu doesn't conform to Python policy as far as linking goes and has a dependency problem, the debdiff attached to that bug would patches the rules file great though
[14:44] <ScottK> binarymutant: But syncing what's in Sid would also solve it, right?
[14:44] <binarymutant> ScottK, right, I'm not sure which would be easier/faster
[14:44] <ScottK> A sync would be preferred.
[14:45] <ScottK> Either should be quite doable at this point.
[14:46] <binarymutant> ScottK, my first patch from that bug ended up on patches.ubuntu.com too, but it's reversed so I attached another debdiff. What should I do about that if anything at all?
[14:51] <khashayar> ScottK: You remember the pencil upload you rejected a while back? It was due to a mistake in debian/copyright. I was hoping persia would re-upload, but I haven't heard from him in a while. Is it at all possible for you to take care of it?
[14:51] <khashayar> I've uploaded a new package to revu with a proper debian/copyright, as I'm not sure where else to put the package. (http://revu.ubuntuwire.com/details.py?package=pencil)
[14:58] <ScottK> khashayar: If I upload it, I can't check it for New, so better find someone else to upload.  Feel free to ping me after it's uploaded.
[14:59] <khashayar> ScottK: OK. Thanks!
[14:59] <ScottK> binarymutant: Just request a sync and don't worry about the patch is my suggestion.
[14:59] <binarymutant> thanks
[15:04] <Mewcenary> binarymutant: lxsplit, thanks for the heads up.
[15:05] <binarymutant> Mewcenary, np, it's really easy to compile
[15:06] <Mewcenary> binarymutant:  What happened with it then?  I see someone started porting it, and uploaded to REVU, then it all stopped...
[15:06] <Mewcenary> Just want to make sure I don't step on toes.
[15:07] <Mewcenary> I presume recommendation would be to get it working on Debian first, before porting into Ubuntu?
[15:08] <binarymutant> Mewcenary, I started packaging it and then lost interest in getting it uploaded, but if you need a debian or an ubuntu package to clean up I have those packages still left over
[15:08] <binarymutant> Mewcenary, all the bugs are still assigned to me but I can close them or I guess assign them to you
[15:10] <ScottK> Mewcenary: At this point in the Ubuntu cycle essentially no one is looking at New packages.  The preference would be to get it into Debian.  If you do, it'll automatically get sync'ed for the next release.
[15:17] <binarymutant> does this requestsync look sane? https://bugs.launchpad.net/ubuntu/+source/charm/+bug/347346
[15:20] <Laney> binarymutant: there is a program called requestsync which can do this for you
[15:21] <Laney> binarymutant: you should paste the new changelog entries from Debian
[15:22] <Laney> and the debdiff you posted isn't actually a diff between Jaunty and sid
[15:28]  * dholbach hugs nixternal
[15:35] <ScottK> Laney: But sync requests don't need a debdiff?
[15:36] <Laney> ScottK: That's right, but if there is one it's better for it to be correct
[15:36] <Laney> otherwise it's misleading
[15:36] <ScottK> True.  I'd have just suggested removing it.
[15:39] <binarymutant> Laney, what do you mean its not a diff between jaunty and sid? with the exception of the changelog it should be
[15:39] <Laney> you should have done "debdiff <current version in Jaunty>.dsc <version you want to sync>.dsc" and posted that if you want to post a debdiff at all
[15:39] <Laney> but as Scott said it's not necessary
[15:40] <binarymutant> i'll take it off
[15:41] <binarymutant> if I can
[15:43] <Laney> you can
[15:45] <binarymutant> thanks Laney
[15:51] <Mewcenary> binarymutant: Sorry, got called into meeting.  Feel free to assign the bugs for lxsplit and I'll take a look.
[15:58] <_ruben> superm1: do you recall our little talk some time ago about dkms not being able to pull in the appropriate image/header packages through the dependency system? wouldn't it be better to just drop the dependencies alltogether and just replace then with post install instructions? (i dont think there's a "works for all" solution in this case)
[16:07]  * nixternal hugs dholbach 
[16:08] <superm1> _ruben, i still think the closest to the works for all solution is that the kernel packages "Recommend" the headers
[16:08] <superm1> it will ensure that unless someone went out of their way to take out the headers, it will work
[16:12] <_ruben> superm1: hmm .. guess that'd work for a fair amount of sitations indeed .. getting it to work in the sitation that made me drag it again is kinda hard (without dropping the dep) : pbuilder environment
[16:13] <superm1> _ruben, yeah that's a corner case in dkms' current usage model i think too
[16:17] <superm1> kirkland, what ever happened to that discussion about making all kernel packages recommend headers?  I seem to forget where it went
[16:17] <kirkland> superm1: i dropped it, marked won't fix
[16:17] <kirkland> superm1: i solved it with an informational message in the postinst
[16:18] <superm1> kirkland, so the server team wasn't keen on the extra couple of megs in the installation for headers then?
[16:18] <kirkland> superm1: http://pastebin.ubuntu.com/136107/
[16:19] <kirkland> superm1: it was more like 80MB
[16:19] <kirkland> superm1: which was large, on a 530MB footprint
[16:19] <superm1> kirkland, 80MB unpacked?  or 80MB on the disk?
[16:19] <kirkland> superm1: 80MB on disk, after installation
[16:20] <superm1> kirkland, ah i see. that's sensible i suppose when you have such a small footprint in the first place.  well i think this point is going to come up again at UDS this year though.
[16:20] <DktrKranz> asac: could you please comment on bug 338074?
[16:20] <superm1> kirkland, at least with what i've heard that the -server kernel is going away in favor of a -generic pae enabled 32 bit option?
[16:21] <kirkland> superm1: right
[16:21]  * _ruben wouldnt want a desktop kernel on his 32bits servers
[16:21] <_ruben> then again .. times (differences in kernels) might have changed :)
[16:21] <superm1> _ruben, what about the desktop kernel would cause you to not want it on the server?  other than the name?
[16:22] <superm1> kirkland, so with that happening, i'm guessing the -generic pae enabled kernel will get desktop use cases too, and the headers will make a lot of sense as recommends then too
[16:22] <_ruben> superm1: i was under the assumption that the desktop version would be optimized for interactive use, and server for well, server use
[16:22] <_ruben> must admit i never really dug into the details of it
[16:23] <superm1> _ruben, I had thought the main difference was the task scheduler's default setting, which can be changed anyway
[16:23] <_ruben> superm1: good point
[16:27] <DktrKranz> persia: re bug 339917, still interested in sponsoring? At this point, I think it's better to ask a-a if they still want to accept NEW, though.
[16:40] <DktrKranz> asac: and if you have time, bug #340435 :)
[17:31] <LaserJock> any chances of getting a new upstream release/package name change for a Multiverse package right now?
[17:36] <ScottK> LaserJock: How much of a change in the packaging is it?
[17:36] <ScottK> LaserJock: Also did you see the sugar FFe/sync request?
[17:36] <LaserJock> ScottK: I didn't see that, no
[17:37] <ScottK> LaserJock: Bug 333279
[17:46] <LaserJock> ScottK: for the multiverse package: in terms of packaging there the obvious renaming changes, and some modprobe.d tweaking. The overall debdiff between versions is 696K
[17:46] <LaserJock> but there's lots of binary diff since it's a binary/closed source app
[17:46] <ScottK> LaserJock: Right.  I can do the New stuff, so I'd say go ahead and ask for the FFe.
[18:01] <RainCT> porthose: have I actually sponsored anything from you?
[18:02] <LaserJock> ScottK: filed bug #347442
[18:03] <LaserJock> ScottK: I guess it's a kinda weird bug title as the package is being renamed, but I couldn't file it on the new name so whatever
[18:03] <porthose> RainCT: I would have to check, but I don't think so
[18:04] <RainCT> Has Debian's NMU policy already changed? (I've just seen a +numX version)
[18:04] <RainCT> err +nmuX
[18:05] <RainCT> porthose: OK, so I don't just have bad memory :). But yes, I'll leave a comment ;).
[18:07] <porthose> RainCT: Thank you :)
[18:14] <Laney> sbeattie: Yo, is the patch on bug 173199 ready?
[18:14] <Laney> erm bug 173799 even
[18:14] <Laney> (it's "In Progress")
[18:15] <sbeattie> Laney: it's as ready as I can make it without feedback from testers.
[18:16] <Laney> ok, I'm looking to sponsor it is all
[18:18] <sbeattie> yep, I'd appreciate the sponsorship; I'd hoped to get some testers of the package first, but it seem that hasn't happened.
[18:21] <LaserJock> is there an easy way to get the current changelog for a source package?
[18:22] <Nafallo> LaserJock: easier than changelogs.ubuntu.com ?
[18:22] <LaserJock> yeah
[18:22] <LaserJock> like a CLI way
[18:22] <Nafallo> wget -O - http://changelogs.ubu... ;-)
[18:23] <ScottK> apt-get source .... less .....
[18:23] <sbeattie> LaserJock: aptitude changelog [packagename]
[18:24]  * Nafallo thinks sbeattie wine...
[18:24] <Nafallo> s/wine/wins/
[18:24] <LaserJock> yeah, I knew there was something like that
[18:24] <LaserJock> I just don't use aptitude so I didn't remember where I'd seen it
[18:28] <LaserJock> I guess I should use it more
[18:28] <LaserJock> I'm just not super fond of the curses (or whatever it is) GUI
[18:29] <Nafallo> ncurses
[18:44] <Laney> aptitude-gtk looks hot
[18:44] <Laney> I never use the ncurses ui though
[18:44] <Laney> too complicated
[18:52] <leonel> ScottK as you may know clamav 0.95 is out ..  does debian has the deb already  to start the rdepends  fixing ?
[18:54] <ScottK> leonel: I didn't see the release announcement yet, but I'm behind on mail today.
[18:54] <ScottK> leonel: Not yet.  They are working on it.
[19:00] <mehdid> is there a way to ask for multiple sync requests in a single one?
[19:00] <Laney> not really
[19:00] <Laney> file multiple bugs
[19:00] <mehdid> Laney: that's what I thought
[19:01] <mehdid> but it can be very painful... especially when you have to sync after a transition
[19:01] <Laney> why's that?
[19:01] <Laney> do you use requestsync?
[19:02] <mehdid> Laney: oh what's that?
[19:02] <Laney> a script to file sync requests
[19:02] <mehdid> that's what I'm looking for then... :)
[19:10] <leonel> ScottK so should I wait for them or just try to build a  non oficial package to start checking the rdepends ?
[19:11] <ScottK> leonel: I think they've got it mostly done in the pgk-clamav git repo.  If you could make something out of that that builds enough for testing it would be useful.
[19:20] <Laney> sbeattie: Looks like the upstream fix was done in another way. I'm going to bounce the bug back to you - could you investigate?
[19:21] <sbeattie> Laney: sure, thanks.
[19:21] <Laney> cool, please resubscribe sponsors when ready
[19:21] <leonel> ScottK ok latter on I'll try
[19:33] <\sh> upgrading dapper to hardy via ssh and no remote-hands available... press thumbs
[19:35] <leonel> \sh: can you please post the result ?
[19:35] <\sh> leonel: will do
[19:36] <leonel> \sh I have 2 gutsys to be upgraded
[19:37] <Laney> What's the best way of getting root for a desktop file? su-to-root or gksu?
[19:41] <c_korn> has anyone managed to get the icedtea6-plugin to work in firefox? bug 346524
[19:45] <ScottK> Laney: su-to-root is more general.
[19:46] <Laney> ScottK: It is, I'm just wondering if it's not the canonical way as the package is in Universe
[19:46] <ScottK> It's not, but there really isn't one I don't think.
[19:48] <\sh> c_korn: icedtea jaa plugin works with siemens remote insight java applet (atleast under intrepid)
[19:48] <Laney> fair enough
[19:49] <\sh> which is more then I can get with the ilo2 remote console applet
[19:49] <\sh> s/get/come/
[19:49] <c_korn> \sh: the bug report is about jaunty I forgot to mention. also the plugins works in opera but not in firefox
[19:51] <\sh> give me a sec
[19:53] <\sh> c_korn: ok you have apoint...jaunty doesn't work
[19:53] <\sh> 25088 shermann  20   0  884m  42m  10m S   99  2.1   0:56.23 java
[19:54] <\sh> and it won't unload even when ff is closed
[19:54] <\sh> well, ff doesn't close properly
[19:56] <c_korn> \sh: can you also confirm that it works with opera?
[19:56] <c_korn> so we have a clue it is firefox related somehow?
[19:56] <\sh> c_korn: well, I don#t use opera in any way ...
[19:56] <c_korn> ok ;)
[19:57] <\sh> I could test it in konqueror (if that is a solution)
[19:59] <\sh> c_korn: konqui + java plugin works like a charm
[20:01] <\sh> setting to confirmed...I think there are enough test cases to give asac and the ff team a good bug report
[20:03] <\sh> press thumbs that my rooty comes back after dist-upgrade dapper -> hardy
[20:05] <Sjord> I have made a gataxx Ubuntu package. I am wondering if I did it right.
[20:05] <Sjord> First, its contents are listed here http://rafb.net/p/GROEQG78.html
[20:05] <\sh> hmm..something went wrong...it's pinging but no ssh anymore
[20:05] <Sjord> How do I check whether it contains everything?
[20:06] <\sh> or it's in the filesystem check...after more then 2 years...
[20:07] <Sjord> In the debian/control file, it lists the gnome team under "Uploaders". Is that correct?
[20:09] <\sh> leonel: the upgrade itself was a charm...some "use config file from maintainer or leave it as is" questions, but nothing really serious
[20:09] <\sh> leonel: now I need to know where my rooty hangs...and this information I can get tomorrow morning first
[20:11] <ScottK> Sjord: If you are updating a package from Debian that had uploaders listed, just leave it.  Ubuntu doesn't make use of the uploaders field.
[20:11] <Sjord> Thanks
[20:26]  * \sh goes home now..cu tomorrow
[20:29] <quadrispro> morgs: I've uploaded sugar ;)
[20:31]  * quadrispro going to sleep
[20:34] <Laney> asac: What's up with bug 305738? Did you upload it? Does it have an FFe to be sponsored if not?
[20:36] <Laney> not sure I want to sponsor a NEW package anyway
[20:42] <asac> Laney: please chech whether all issues that lead to archive rejection last time have been addressed
[20:42] <asac> check
[20:42] <Laney> would it be better to defer this package to karmic?
[20:42] <Laney> (and REVU it properly)
[20:44] <asac> not sure. if you want you can review it ;)
[20:44] <Laney> not particularly
[20:44] <Laney> is there a compelling reason for it?
[20:52] <Laney> asac: I'm going to defer it, ok?
[20:53] <leonel> ScottK git://git.debian.org/git/pkg-clamav/clamav.git  <-- this is for clamav right ??
[20:55] <asac> Laney: just leave it as it is
[20:55] <Laney> erm
[20:55] <asac> i will get to it when i have time ... i think it should go in if it has everything fixed
[20:55] <Laney> if you like
[20:56] <asac> its basically that i didnt have time to follow up and it fell off the radar. if the contributor has fixed everything i dont want him get even more discouraged
[20:56] <asac> at least i think it was my fault
[20:56] <asac> if he didnt fix the issues, then it has to wait
[20:59] <ScottK> leonel: Yes.
[21:02] <leonel> ScottK It's a big repo ..   starting the  clone  ..
[21:03] <ScottK> Great.
[21:03] <leonel> ScottK this must be first for jaunty rith ?
[21:03] <leonel> right ?
[21:04] <ScottK> leonel: From reading the pkg-clamav ml, I think what's there may build, but needs more work on configs.
[21:04] <ScottK> leonel: We had some 0.94 updates early on, but this is the first in some time.  The Ubuntu part of that repo is not up to date.
[21:05] <leonel> ScottK if we can do a first install  to start checking the rdepends  will do  don't you think ?
[21:05] <ScottK> leonel: Yes.  If it will build we should put it in the PPA and start work on rdepends.
[21:06] <leonel> ScottK ok ..    cloning ..
[21:44] <leonel> ScottK deadline for a FFE for jaunty ??
[21:44] <ScottK> Any second now.
[21:44] <ScottK> Sooner the better.
[21:44] <ScottK> clamav is in Main, so I can't say for sure.
[21:47] <leonel> ScottK  The new cherokee has been accepted to  debian unstable    and is on queue  ..  or  can it be taken  from  the PPA ?
[21:48] <ScottK> leonel: Needs to be synce'd from Debian.  We don't sync from PPAs.
[21:48] <leonel> ScottK ok
[21:59] <DktrKranz> porthose, re your email, did you try to move MochiKit.js  removal before dh_pycentral call?
[22:04] <porthose> DktrKranz: binary-predeb/python-coherence::   13           /bin/rm -f debian/python-coherence/usr/share/pyshared/coherence/web/static/MochiKit.js
[22:06] <DktrKranz> porthose, I'd try to move it before dh_pycentral (but I'm not a CDBS guy, so you have to check documentation) or do some dirty hacks with postinst/prerm to skip byte-compilation of it
[22:10] <porthose> DktrKranz: the package installs fine if debian/links is like this  /usr/share/javascript/mochikit/MochiKit.js /usr/share/pyshared/coherence/web/static/MochiKit.js instead of like this /usr/share/javascript/mochikit/mochikit.js /usr/share/coherence/coherence/web/static/MochiKit.js
[22:14] <DktrKranz> porthose, try to fix it and then do upgrade tests
[22:14] <DktrKranz> such errors usually pop up during upgrade
[22:15] <porthose> I guess what I'm trying to say is that a when libjs-mochikit is installed to /usr/share/javascript/mochikit  it is MochiKit and not mochikit
[22:16] <porthose> DktrKranz: will do thxs for the help
[22:25] <maxb> Is there any channel in particular that might help me with a peculiar schroot issue? (It prints "Sessions still open, not unmounting", but I don't actually have any sessions still open)
[22:32] <maxb> Oh, yikes. it's interacting with ecryptfs
[23:09] <btm> ScottK: IRT Bug 203990 and Bug 334065, getting gems 1.3.1 synced from debian, since the latter has been assigned to the Package Archive Administrators for some time now and is marked 'fix released', is there anything else we need to do to get the FFe applied and the package to show up in the repositories?
[23:09] <btm> I mean Bug 302990
[23:54] <hggdh> question: I am building a webkit with some patches (to test Evolution based on webkit), based on current 1.0-1. How should I name the version?
[23:55] <hggdh> (Evolution-webkit will need to depend on this temporary version; this is being built in my PPA)