[00:39] <RAOF__> HorizonXP: Masters Of The Universe.
[00:40] <HorizonXP> oh lol
[00:41] <HorizonXP> so i'm trying to recompile PHP5, because apparently the PDO built-in doesn't support PDO_Informix
[00:41] <coppro> install the build-deps, file a bug if it won't build, assuming you haven't seriously messed up your compilation environment
[00:42] <HorizonXP> well, compiling works so far, but I can't seem to get rid of PDO. i need the right configure options. I did the following command:
[00:42] <HorizonXP> DEB_BUILD_OPTIONS="--with-mysql --with-apxs2=/usr/bin/apxs2 --with-curl --with-xsl --disable-pdo --without-sqlite" fakeroot debian/rules binary
[00:42] <HorizonXP> does that replace the configure options in debian/rules, or just append to them?
[00:42] <RAOF__> You're misunderstanding what DEB_BUILD_OPTIONS is for.
[00:43] <RAOF__> Neither.  DEB_BUILD_OPTIONS is a list of things like 'noopt', 'nostrip', 'parallel=3', etc.
[00:43] <HorizonXP> oh.
[00:44] <RAOF__> You want to fiddle with debian/rules.  If it's using debhelper the ./configure call will be obivous.  If it's using CDBS, you need to work out the black magics.
[00:44] <pochu> you want DEB_CONFIGURE_EXTRA_FLAGS
[00:44] <RAOF__> Have a goat handy.
[00:44] <pochu> (for CDBS)
[00:46] <HorizonXP> so it's apparently debhelper
[00:46] <HorizonXP> that should be easier
[00:56] <directhex> keep the goat, just in case
[00:56] <HorizonXP> well, i haven't eaten at all today
[00:56] <HorizonXP> so gonna have dinner and get back to it. be back later
[00:58] <directhex> goat curry!
[00:59]  * HorizonXP mouth waters
[01:00] <HorizonXP> not today. it's chicken curry actually (no joke)
[01:06] <radix> curry is a wonderful idea
[01:36] <anakron> hi all
[01:37] <anakron> i wanna know if someone here use firestarter
[01:37] <anakron> or
[01:37] <anakron> gksu
[01:37] <anakron> if someone use firestarter, is it for an administrator or for a user with sudoers habilities
[01:38] <anakron> ?
[01:40] <anakron> can someone answer?
[01:43] <dtchen> anakron: there's really no difference between the former and the latter
[01:44] <anakron> its a little different
[01:44] <anakron> one is root
[01:44] <anakron> the other can be like root if root give him privilieges
[01:45] <dtchen> anakron: in either case, euid == 0
[01:45] <anakron> :)
[01:45] <anakron> ok ok
[01:45] <anakron> im asking because in firestarter.desktop
[01:45] <anakron> its added in Exec
[01:45] <anakron> gksu -X -c firestarter
[01:45] <anakron> but gksu does not have this options
[01:46] <anakron> and i was asking if it correct to change it to : gksu -S firestarter
[01:46] <anakron> and then it will run asking users(included in sudoers file) pass
[01:46] <anakron> :) that was
[01:50] <dtchen> i would hope that passing -S is unnecessary
[01:50] <anakron> mm
[01:50] <dtchen> is there documentation of firestarter behaving in a broken manner if one backend is used vice another?
[01:51] <anakron> in that case is better to use gksudo
[01:51] <anakron> mm
[01:51] <anakron> ok
[01:51] <anakron> one question
[01:51] <dtchen> gksu by itself should do the right thing based on the gconf key
[01:51] <anakron> nono
[01:51] <anakron> ok
[01:51] <anakron> thanks
[01:52] <anakron> hey, if im interested in mentoring
[01:52] <anakron> asking for
[01:52] <anakron> i must sent an email to
[01:53] <anakron> i must sent an email to
[01:53] <anakron> motu-mentoring-reception@reponses.net
[01:53] <dtchen> correct
[01:53] <anakron> :-) ok thanks
[01:54] <dtchen> yw
[01:58] <anakron> one more
[01:58] <HorizonXP> ok back, so i'm trying to reconfigure the PHP5 package so that it doesn't compile PDO support into PHP directly, so I can use the PECL modules.
[01:59] <anakron> what i can do if a patch is applied to my source package and i can't apply my change
[01:59] <HorizonXP> in debian/rules, i see a bunch of CFLAGS that seem to set those options. is there not a way to just override those configure options?
[01:59] <dtchen> anakron: meaning conflicting patches? it's normally best to use upstream's patch [for maintenance rationale]
[02:00] <dtchen> anakron: if you don't mean conflicting patches but just fuzz changes, you can normally rediff your change/patch
[02:00] <anakron> mm
[02:00] <anakron> editing the patch?
[02:01] <anakron> making a debdiff of the changes that ill apply to the patch?
[02:02] <dtchen> you certainly could edit the patch directly using a variety of utilities in the patchutils package
[02:02] <anakron> ok
[02:02] <dtchen> if the source package has a patching system (e.g., cdbs, quilt), use that instead
[02:02] <anakron> how i can know it
[02:03] <dtchen> look at debian/control:^Build-Depends
[02:03] <dtchen> you may also need to look at debian/rules
[02:03] <anakron> dpatch
[02:04] <anakron> dpatch in both
[02:04] <anakron> mm so i must use dpatch-edit-patch
[02:05] <anakron> the problem was that th old desktop file use "su-to-root" with -X -c
[02:05] <anakron> but when the patch owner change it , he does not take out -X -c
[02:05] <anakron> and gksu does not have any option like these
[02:08] <dtchen> normally that can be migrated directly to gksu (without any options)
[02:08] <anakron> yes
[02:08] <anakron> how can i do it
[02:09] <dtchen> is there any particular reason why you're dropping su-to-root? are you trying to remove menu as a dependency?
[02:09] <anakron> now it says, after i do "dpatch-edit-patch 21-gksu.patch
[02:09] <anakron> no
[02:09] <anakron> it was done
[02:09] <anakron> im taking out "-X -c"
[02:10] <anakron> ok
[02:10] <anakron> after doing dpatch appears
[02:10] <anakron> Now launching an interactive shell in your work directory. Edit your files...
[02:10] <anakron> can you explain it please?
[02:11] <anakron> i need to know "HOW"
[02:11] <dtchen> just modify the desktop file, then exit 0
[02:11] <dtchen> you might want to take a lok at dpatch-edit-patch(1)
[02:14] <anakron> but editing the desktop file
[02:14] <anakron> it will change the patch?
[02:15] <anakron> ok thanks!
[02:15] <anakron> thanks for your patience
[02:33] <Turl> hi
[02:33] <Turl> what does W: specto source: debhelper-but-no-misc-depends mean?
[02:33] <bddebian> It means the package uses debhelper but doesn't have a depends on ${misc:Depends}
[02:35] <Turl> so I should add ${misc:Depends} then?
[02:35] <bddebian> Yep
[02:35] <Turl> on build depends, am I right?
[02:36] <bddebian> No, in the binary package, Depends:  Should be next to ${shlib:Depends} if it uses it.
[02:37] <Turl> it's a python program, so I guess it doesn't use it
[02:37] <bddebian> Ah, but it uses ${python:Depends}, right?
[02:37] <Turl> yep
[02:37] <bddebian> Just add it after that :)
[02:38] <Turl> Depends: ${misc:Depends}, ${python:Depends}, python-gtk2, python-glade2, ....
[02:38] <Turl> ok?
[02:38] <bddebian> I would normally ${python:Depends}, ${misc:Depends} but it shouldn't matter.
[02:38] <Turl> I wanted to keep all the python things together (there are more python- packages)
[02:41] <Turl> also, there is dpkg-source: aviso: Version number suggests Ubuntu changes, but there is no XSBC-Original-Maintainer field
[02:41] <Turl> the version is -0ubuntu2~ppa1, iirc this indicates there's no debian package for it, so why does it complain?
[02:44] <bddebian> I don't think it can differentiate, but I'm not sure about that one.
[02:44] <Turl> it's harmless then
[02:55] <HorizonXP> hey guys, so i'm trying to recompile PHP5. I'm trying to get PDO_Informix to install, and I figured out that I can just compile it as an extension directly. but how do I get configure to pick it up? my documentation is saying to use buildconf --force
[04:40] <fabrice_sp> ScottK, sorry for the late answer (if you are still there). I spli the pacakge this way to avoid lintian warning with both packages (no man page in DVDStyler of desktop command not found, ...)
[04:42] <ScottK> fabrice_sp: OK.  Reasonable enough.
[04:43] <ScottK> fabrice_sp: Since dvdstyler depends on the data package it would have been OK, but not a big deal.
[04:45] <fabrice_sp> ScottK, you're right. At first, I put recommend instead of depends, but dvdstyler alone was hardly usable (a lot of errors). I just wanted to have a really clean package(from a lintian stand point :-) At the end, the package size has been divided by 2
[04:46] <ScottK> Good enough.
[04:47] <ScottK> The most correct way to do it would have been to move all the arch all data to the -data package and add lintian overrides, but I think it's not a big deal.
[04:50] <fabrice_sp> you mean non-arch to data, right? This was the first thing I did (usr/bin from in dvdstyler and usr/share in dvdstyler-data)
[04:53] <fabrice_sp> ScottK, I'm changing the package to put usr/bin in dvdstyler and usr/share in dvdstyler-data, and I'll upload again in few minutes (and will have to re-ask mok0 for his advocate :-) )
[04:54] <ScottK> OK.
[04:54] <ScottK> Add the lintian overrides too then.
[04:54] <ScottK> fabrice_sp: Please test build before you upload.
[04:55] <fabrice_sp> yes. I didn't thought about the overrides (and I also always do a sbuild before uploading. That's why I will last a bit :-) )
[04:55] <ScottK> OK.  If I'm not still up when you're done I'll advocate it tomorrow.
[04:55] <fabrice_sp> ok. Thanks
[05:07] <fabrice_sp> ScottK, as I move .desktop file and icon to dvdstyler-data, I should call dh_icons in binary-indep, right?
[05:08] <ScottK> Yes.  I think that's right.
[05:08] <fabrice_sp> ok.
[06:30] <dholbach> good morning
[06:31] <fabrice_sp> Good morning dholbach
[06:31] <dholbach> hiya fabrice_sp!
[06:31] <btm> After I upload a package to revu, and add a link to it to the bug (tagged with needs-packaging), do I need to do anything else to notify someone that it's ready (email a list) or do MOTU folks just queue through the needs-packaging bugs?
[06:35] <fabrice_sp> btm, reviewers go through REVU, in the "Needs review" view. As you can see, there is quite a lot of packages there already, so the better your package is, the quicker it will be
[06:38] <btm> fabrice_sp: do I need to do anything in revu to flag a package so it shows up in 'needs review'?
[06:38] <fabrice_sp> btm, no. Just upload it to revu.
[06:40] <btm> When I set the maintainer field to motu and moved my name to XSBC-Original-Maintainer in control, revu started throwing lintian errors about this being an NMU. Is this normal?
[06:41] <fabrice_sp> btm, it's because your version number is not correct
[06:46] <btm> Got it. When I set distribution to jaunty in changelog I get 'bad-ubuntu-distribution-in-changes-file
[06:51] <btm> set distribution to my current distribution (intrepid) and that lintian error went away.
[06:59] <iulian> btm: Change it back to jaunty and ignore that error.
[07:00] <btm> iulian: gotcha
[07:05] <btm> revu gives an automatic comment of (legal), clicking on it shows a few files marked UNKNOWN, one with a copyright line. In the file it's clearly marked GPL though. Do I need to resolve these?
[07:08] <fabrice_sp> btm, if you are sure that all the source files have a copyright header, it's ok
[07:17] <btm> fabrice_sp: not all of the source files have a reference to the license, but they have a copyright header. The readme has matching copyright with license information. Is that acceptable?
[07:45] <didrocks> morning
[07:49] <iulian> Good morning didrocks, DktrKranz.
[07:50] <didrocks> hello iulian
[07:50] <jpds> morning.
[07:51] <schmiedc>  morning
[07:51] <DktrKranz> morning iulian :)
[07:54] <Webspot> Hey. If there are any MOTUs around and available, could they review my packages at REVU? One is osm-gps-map, which is a GTK widget for embedding openstreetmap. And the other is pyofa, which creates audio fingerprints for files. http://revu.ubuntuwire.com/details.py?package=osm-gps-map http://revu.ubuntuwire.com/details.py?package=pyofa - Thanks :-)
[10:12] <Laney> DktrKranz: Hey, here's a list of the syncs we still need to do and what they wait on: http://pastebin.com/fe76d603
[10:13] <Laney> dholbach: I don't see that ftbfs on washngo with an amd64 sbuild chroot :(
[10:13] <dholbach> Laney: let me try again
[10:14] <Laney> However at that file it did hang for a long time, but eventually got going
[10:14] <Laney> maybe it's a pbuilder/sbuild thing
[10:20] <DktrKranz> Hi Laney, I didn't look at rebuilds (girlfriend wanted priority...), I'll have a look this evening. For syncs, they can be processed as usual because DEPWAIT are handled automatically, for hdbc-*, they need to be processed at a later stage when hdbc is published.
[10:27] <dholbach> Laney: now it got past that point - give me the bug number and I'll ACK it once it proceeded fully
[10:30] <Laney> DktrKranz: I didn't check how tight he made the build-deps actually
[10:31] <Laney> but slangasek has already processed them
[10:32] <DktrKranz> I see
[10:32] <Laney> dholbach: bug #321249
[10:32] <DktrKranz> so they could be synced straight
[10:33] <Laney> they can now
[10:33] <dholbach> Laney: build succeeded - perfect :)
[10:33] <dholbach> Laney: no idea what happened before
[10:34] <Laney> I always do a test build ;)
[10:35] <dholbach> Laney: I wasn't saying that you weren't - you're definitely a good guy :-)
[10:35]  * dholbach hugs Laney
[10:37] <Laney> \o/
[10:38] <james_w> DktrKranz: thanks for the uw-imap work
[10:43] <DktrKranz> james_w: just three rebuilds, no problem :)
[11:06] <dolanor> Hello
[11:07] <dolanor> Anyone to check my package attempt to hexdiff ?
[11:07] <dolanor> on revu, of course
[11:10]  * tuxmaniac is looking for one more advocate for his package gresisotr on REVU. If someone can have a look at it it will be nice! Thanks in advance.
[12:17] <Mez> san nin faai lok to all our chinese friends out there
[13:04] <mok0> tuxmaniac: looking at gresistor now
[13:04] <mok0> tuxmaniac: the email address in changelog is invalid
[13:16] <mok0> tuxmaniac, n/m, fixed & uploaded
[13:20] <tuxmaniac> mok0: thanks :-)
[13:21] <mok0> tuxmaniac: should appear in the new queue shortly
[13:21] <mok0> tuxmaniac: nice app
[13:22] <loic-m> What's the method for removing a patch in debian/patches from a package that uses quilt - just delete the patch and the reference to it in debian/patches/series?
[13:22] <james_w> that'll work
[13:22] <loic-m> and no need to modify the rules files?
[13:22] <mok0> loic-m: actually, just remove the series entry
[13:22] <loic-m> james_w, mok0 thanks a lot
[13:23] <loic-m> If it's the only patch, is it better to delete the debian/patches repository?
[13:24] <mok0> loic-m: heh, good question. I find it convenient with a patch system in place in case I want to fix something
[13:24] <loic-m> mok0: actually you answered - delete the series entry and leave the patch thx
[13:25] <loic-m> the rules files has unpatch in the clean target - is it safe to leave, or better removed?
[13:25] <mok0> loic-m: just leave it
[13:25] <mok0> loic-m: it will discover there's nothing to do
[13:25] <loic-m> thanks mok0
[13:52] <loic-m> If I update from upstream a package that's usually synced from Debian, do I keep Standards-Version: 3.7.2 or do they use a newer one now (like 3.7.3)?
[13:53] <slomo> RAOF: you can sync banshee now i guess... and probably also taglib-sharp :)
[13:56] <dolanor> Anyone to check my package attempt to hexdiff on REVU ?
[14:00] <stefanlsd> loic-m: leave it like the debian version
[14:09] <Myrtti> !longdesc
[14:09] <Myrtti> excellent
[14:14] <mok0> !synopsis
[14:15] <jcfp> Anybody in for a review please consider http://revu.ubuntuwire.com/details.py?package=sabnzbdplus (popular binary newsreader, written in python)
[14:21] <mok0> jcfp: You've been working on that for some time ;-)
[14:26] <Laney> jcfp: Does it use that embedded copy of cherrypy?
[14:26] <jcfp> mok0: unfortunately :/  people apparently don't fancy reviewing python packages, and thing like newly created libjs-* packages also create delays...
[14:26] <jcfp> Laney: no.
[14:26] <Laney> excellent
[14:26] <mok0> jcfp: I will take a look shortly
[14:26] <jcfp> mok0: tia
[14:43] <POX> jcfp: I heard that there's a secret place where people are reviewing Python related packages, few guys here know a magic spell that opens a channel with lots of people who can review your package if you follow some strange rules ;-)
[14:44] <POX> ScottK, pochu, RainCT: ^^
[14:44] <jcfp> POX: i'm not harry potter but do eloborate :)
[14:45] <mok0> jcfp: +1
[14:45] <ScottK> jcfp: If you're interested in getting your package into Debian and syncing it into Ubuntu from there, you can join #debian-python on OFTC.
[14:46] <ScottK> jcfp: https://wiki.ubuntu.com/ContributingToDebian/PythonModulesTeam
[14:47] <jcfp> ScottK: would that be faster? or is there alot of extra work in getting debian to accept too
[14:47] <jcfp> mok0: :)
[14:47] <ScottK> It wouldn't necessarily be faster, but there's more Python specific expertise.
[14:48] <ScottK> Also If POX uploads it to Debian, I'm generally going to make some assumptions about package quality.
[14:48] <ScottK> So working in parallel can make it faster.
[14:50] <jcfp> so what would be best - trying via revu and directly to debian at the same time?
[14:52] <mok0> jcfp: you'll be waiting forever finding a Debian sponsor, so why not?
[14:53] <jcfp> mok0: is it that bad :/
[14:53] <Laney> Doing it in a team is usually easier
[14:53] <Laney> than e.g. through mentors
[14:56] <Piratenaapje> If any reviewers or MOTUs are available, could you please take a look at http://revu.ubuntuwire.com/details.py?package=grnotify ?
[14:58] <ScottK> mok0: Not in the Python team.  There it's very easy to get sponsored.  That's part of what POX was hinting at.
[14:58] <mok0> ScottK, that's good to know
[14:59] <mok0> Piratenaapje: are you in contact with upstream?
[14:59] <Piratenaapje> mok0: I am upstream
[15:00] <mok0> Piratenaapje: ah, then I can really have a go at you ;-)
[15:00] <Piratenaapje> mok0: That doesn't sound too good :p
[15:00] <jpds> mok0: Factoids added to ubottu database.
[15:00] <mok0> Piratenaapje: just trivial stuff, not hard
[15:07] <tuxmaniac> Piratenaapje: sorry for not replying to the changes you made. Thanks for that.
[15:07] <Piratenaapje> tuxmaniac: That's ok, thank you for reviewing :).
[15:12] <Webspot> Hi all. I've fixed all the problems people identified in my packages on REVU. Are there any MOTUs available to review my packages? http://revu.ubuntuwire.com/details.py?package=osm-gps-map http://revu.ubuntuwire.com/details.py?package=pyofa - Thanks :)
[15:13] <savvas> Piratenaapje: I think the right way for closing an LP bug is (LP: #308285
[15:13] <savvas> * (LP: #308285)
[15:14] <savvas> I might be wrong though :)
[15:15] <jpds> savvas: No, that's fine.
[15:16] <savvas> my bad then
[15:16] <Piratenaapje> mok0: thanks for reviewing, I'll try to fix everything later today
[15:16] <loic-m> Does Debian accept Standards-Version: 3.8.0 ? I was under the impression it was still 3.7.X, but some packages in Debian have 3.8.0
[15:17] <ScottK> 3.8.0.1 is the current standards version in Debian.
[15:17] <jpds> loic-m: Yes, it does, it's the lastest Debian policy version.
[15:18] <loic-m> jpds, ScottK thanks
[15:18] <savvas> packages qa show that as well: http://packages.qa.debian.org/f/flumotion.html
[15:18] <savvas> "The package should be updated to follow the last version of Debian Policy (Standards-Version 3.8.0 instead of 3.7.2)."
[15:19] <bddebian> Heya gang
[15:19] <loic-m> savvas, thx, when I googled it I didn't find references to the number
[15:19] <ScottK> Heha bddebian.
[15:19] <bddebian> Heya ScottK
[15:20] <savvas> glad to help out :)
[15:20] <ScottK> loic-m: Try rmadison -u debian debian-policy
[15:22]  * POX think it would be weird if Ubuntu would provide its own version of debian-policy (and thus have its own Standards-Version)
[15:22] <savvas> ScottK: I've noticed that, but why don't they use 3.8.0.1 in the Standards-Version?
[15:22] <POX> +s
[15:23] <ScottK> POX: ubuntu-policy | 3.8.0.1ubuntu4 | jaunty/universe | source, all
[15:23] <savvas> POX: There is a package with ubuntu-policy :P
[15:23] <POX> oh, so you have your own Standards-Version? /me didn't know that
[15:23] <ScottK> savvas: The 4th digit doesn't change policy, it's about the package.
[15:23] <ScottK> It's a recent development.
[15:24] <savvas> ah, ok
[15:24] <ScottK> You can diff debian-policy and ubuntu-policy and see where the distro policies are different.
[15:29] <POX> ScottK: is it possible to tell which policy is the package following after looking at Standards-Version?
[15:29] <ScottK> No.  We don't put the Ubuntu revision in debian/control.
[15:30] <ScottK> We just started having a separate policy document recently and so we're trying to figure out what to do with it.
[15:31] <ScottK> In fact we have a policy of not changing the policy version in packages we get from Debian as it needlessly clutters the diff.
[15:32]  * POX suggests to add something to the version that will allow him to detect that this package is not following the Debian policy
[15:32] <loic-m> ScottK thanks, I was on another screen. rmadison works well
[15:32] <POX> u.3.8.0 or 3.8.0-u or 1:3.8.0 or something like this
[15:33] <loic-m> ScottK: could you please check my changelog entry at http://paste.ubuntu.com/109839/ ?
[15:33] <savvas> and XSBC-Original-Standards-Version ? :P hehe
[15:34] <ScottK> loic-m: Don't bump standards version and don't mention the maintainer change in debian/changelog.
[15:34] <ScottK> loic-m: Also 'should be solved' sounds a bit weak.  Either it is or it isn't.
[15:35] <loic-m> ScottK: I don't have Intel hw to check
[15:35] <loic-m> The code isn't there to be patched anymore in the first place
[15:39] <ScottK> OK.  Then say patch dropped, code changed upstream.
[15:39] <ScottK> Don't make a statement about is the bug fixed.
[15:40] <loic-m> ScottK: can you tell me how you saw that so I know?
[15:40] <ScottK> Make it sound a little better than that though.
[15:40] <loic-m> ScottK: or did you also chack the Debian bug report?
[15:40] <ScottK> Saw which?  The patch thing just from reading your changelog
[15:41] <loic-m> No, how did you find "Then say patch dropped, code changed upstream." ?
[15:41] <loic-m> The Debian bug comments sin't that assertive
[15:41] <ScottK> Because you told me the code had changed upstream and it wasn't there to be patched.
[15:42] <loic-m> Ok.
[15:42] <loic-m> http://paste.ubuntu.com/109843/ is that ok now?
[15:44] <ScottK> I think that's find.
[15:44] <ScottK> find/fine
[15:44] <loic-m> ScottK: thanks
[15:44] <ScottK> no problem.
[15:45] <loic-m> Now I'd like to fix the debian/watch but there's something I don't get
[15:45] <loic-m> http://sf.net/desmume/desmume-(.*)\.tar\.gz downloads desmume-0.9-mac.tar.gz
[15:46] <loic-m> How do I make sure it downloads desmume-0.9.tar.gz ?
[15:47] <loic-m> AFAIU, (.*) should only pick the version numbers, shouldn't it?
[15:49] <petski> loic-m, see http://wiki.debian.org/DEHS | grep dversionmangle
[15:51] <petski> arf, i misunderstood your question
[15:51] <petski> try (\d+\.\d+) instead of (.*)
[15:53] <Piratenaapje> My package was just rejected, and I don't really get why. It says: Details follow: * grnotify_1.0.2_source.changes:Changed-By: Kristof Bamps

[15:53] <jpds> Piratenaapje: That would be my email.
[15:53] <Laney> cosmicray versions his packages weirdly: http://packages.debian.org/changelogs/pool/main/m/missingh/current/changelog
[15:53] <Piratenaapje> jpds: Could you explain why it was rejected? I didn't think the mail was too clear
[15:54] <jpds> Piratenaapje: Please see the buttom of the email for steps on how to fix it.
[15:55] <Piratenaapje> jpds: Oh, I thought my key actually was on lp, thanks
[15:55] <Piratenaapje> jpds: But how did the package got filed under my name if I didn't correctly set my key?
[15:56] <jpds> Piratenaapje: The name is set in debian/changelog.
[15:57] <jpds> Piratenaapje: The package uploads are checked against the keyring and if it can't find your key, just pops your package into rejected/.
[15:57] <Piratenaapje> jpds: Ok thanks, I'll have to look into what I did wrong :s
[15:57] <loic-m> petski: it works perfect. What man / doc should I look for if I want to learn about the operators like +d without having to learn a programming language?
[15:57] <quadrispro> hi! w-scan needs a review -> http://revu.ubuntuwire.com/details.py?package=w-scan
[15:58] <savvas> quadrispro: There's an error in macchanger-gtk (1.0-1ubuntu1) [universe] package in jaunty - In debian/control it says "XSBC-Orginal-Maintainer", whereas it should be "XSBC-Original-Maintainer"
[15:58] <loic-m> and do I need to mention the change in the watch file in the changelog?
[15:58] <jpds> Piratenaapje: Adding your key to LP and logging into REVU ought to fix everything.
[15:58] <quadrispro> hi savvas, thank you, I work on it now
[15:58] <savvas> np :)
[16:01] <jpds> Piratenaapje: I'm off for now, but feel free to reply to the email when you're done.
[16:01] <Piratenaapje> The key DF191D95B44054ABA32283735B401CF3BC8C303C has already been imported.
[16:02] <mok0> hyperair: I fixed codelite for you
[16:02] <jpds> Piratenaapje: OK; it's in the revu keyring, let me move the upload back to he processing queue.
[16:02] <Piratenaapje> jpds: But I didn't do anything :s
[16:02] <hyperair> mok0: eh? you did? and reuploaded?
[16:03] <hyperair> mok0: got a debdiff?
[16:03] <jpds> Piratenaapje: Hmm, odd, it's in the keyring
[16:03] <mok0> hyperair: I can make one
[16:03] <hyperair> mok0: thanks
[16:03] <mok0> hyperair: there were still some COFF binaries
[16:03] <hyperair> mok0: yeah i noticed. *.exp
[16:03] <jpds> Piratenaapje: Date: Wed, 14 Jan 2009 16:01:00 +0100 - maybe you added the key recently?
[16:03] <mok0> hyperair: I removed the sqlite3 tree and added it to the build-depends instead
[16:03] <hyperair> mok0: did you change debian/rules?
[16:03] <mok0> no
[16:03] <hyperair> ah
[16:03] <hyperair> removed the sqlite3 tree eh
[16:04] <mok0> hyperair: it was under wxsqlite3
[16:04] <mok0> hyperair: I hope it works now lol
[16:04] <hyperair> mok0: have you tested whether it'll build?
[16:04] <quadrispro> savvas: bug 321504 :)
[16:05] <mok0> hyperair: it builds fine
[16:05] <Piratenaapje> bah, total system freeze :/
[16:05] <hyperair> mok0: okay then
[16:05] <mok0> hyperair: I'll have to bump the release to make a debdiff
[16:05] <jpds> Piratenaapje: Hmm, it's even on REVU: http://revu.ubuntuwire.com/details.py?package=grnotify - I wonder why it got rejected.
[16:05] <hyperair> mok0: ah nevermind then
[16:05] <hyperair> mok0: you didn't touch debian/ right?
[16:06] <Piratenaapje> jpds: I don't know either :s
[16:06] <mok0> hyperair: I added libsqlite3-dev to build-deps
[16:06] <mok0> hyperair: I edited changelog
[16:06] <Laney> DktrKranz: bug #321499, bug #321501, bug #321503, bug #321505 for you good sir
[16:06] <mok0> hyperair: I added README.source
[16:06] <savvas> quadrispro: cool, confirmed!
[16:06]  * jpds raises eyebrown at Laney.
[16:06] <mok0> hyperair: I changed get-orig-source rule
[16:06] <mok0> hyperair: that's it I think
[16:07]  * Laney lowers them for jpds 
[16:07] <hyperair> mok0: could you diff just the debian/ folders then?
[16:07] <Piratenaapje> jdps: so everything should be ok now?
[16:07] <hyperair> mok0: i'd like to reflect the changes on my local bzr tree.
[16:07] <jpds> Piratenaapje: Yep, sorry for the confusion.
[16:07] <mok0> hyperair: yes
[16:07] <hyperair> mok0: thanks
[16:07] <Piratenaapje> jpds: Ok thanks :)
[16:07] <mok0> hyperair: of course
[16:07] <mok0> hyperair: 2 minutes
[16:09] <DktrKranz> Laney: mind subscribing me to them?
[16:11] <mok0> hyperair: dcc'ing you the patch
[16:12] <hyperair> mok0: i'm not very sure if dcc works. could you pastebin it?
[16:13] <mok0> sure
[16:13] <mok0> hyperair: what's your irc client?
[16:13] <Laney> DktrKranz: done
[16:13] <Piratenaapje> jdps: will my package stay in the 'needs work' category?
[16:13] <hyperair> mok0: smuxi
[16:13] <mok0> hyperair:  http://pastebin.com/fe941212
[16:14] <hyperair> mok0: but dcc's failed miserably before, because i'm behind a router
[16:14] <mok0> hyperair: never heard of it
[16:14] <hyperair> mok0: it's in the ubuntu repo =)
[16:14] <mok0> hyperair: using pidgin myself
[16:14] <hyperair> mok0: it's a little buggy, but it's lightweight and nice
[16:14] <mok0> hyperair: well I have a quad duo so...
[16:15] <hyperair> mok0: i used to use pidgin, until a few weeks back. if you leave it on too long (in my case) it starts hanging every 15 minutes or so if the irc backlog gets too long
[16:15] <hyperair> mok0: hmph
[16:15] <mok0> hyperair: I've not noticed that
[16:16] <hyperair> mok0: it happens if you're using msn
[16:16] <hyperair> mok0: anyway... you didn't have to remove wxconfig/sqlite3
[16:16] <hyperair> mok0: it's removed automatically when you exclude wxconfig
[16:16] <mok0> hyperair: it wasn't
[16:16] <hyperair> mok0: perhaps you meant sdk/wxsqlite3?
[16:17] <mok0> hyperair: yes sdk/wxsqlite3/sqlite3
[16:17] <mok0> hyperair: look at the pastebin *^
[16:17] <petski> loic-m, google for "regular expressions"
[16:17] <petski> loic-m, or try "perldoc perlre"
[16:18] <petski> have to go now, bye  bye
[16:18] <hyperair> mok0: well it's documented in README.source as sdk/wxconfig/sqlite3
[16:18] <mok0> ehm, that's wrong
[16:18] <mok0> hyperair: sorry
[16:19] <quadrispro> anyone on bug 321504?
[16:19] <hyperair> mok0: #
[16:19] <hyperair> +       GZIP=-9fn tar --exclude=*.dll --exclude=*.exe --exclude=sdk/curl --exclude=sdk/wxconfig/sqlite3 \
[16:19] <hyperair> mok0: that was in debian/rules
[16:19] <mok0> hyperair: that's also wrong
[16:19] <loic-m> petski; thanks
[16:19] <hyperair> mok0: but that's in debian/rules! check your paste
[16:19] <mok0> hyperair: I made a mistake, typing from memory, didn't repackage using that rule
[16:19] <hyperair> ah
[16:20] <mok0> hyperair: I used tar --delete directly on the tarball
[16:20] <hyperair> ah
[16:20] <mok0> hyperair: fix it in the patch before you apply it :-)
[16:20] <hyperair> mok0: alright.
[16:21] <mok0> hyperair: if the package gets uploaded, please remember to fix it there too
[16:22] <loic-m> liw: I've got a question about piuparts after your presentation last week
[16:22] <liw> loic-m, go ahead
[16:23] <loic-m> liw: when testing upgrades, can I also test how a backported package would upgrade?
[16:23] <hyperair> mok0: how do i do it?
[16:23] <mok0> hyperair: do what?
[16:24] <hyperair> mok0: fix it. i don't have uber motu powers
[16:24] <liw> loic-m, with the correct incantation of --mirror options, I'm sure you can
[16:24] <liw> loic-m, however, I haven't tried it
[16:24] <Piratenaapje> jpds: will my package stay in the 'needs work' category?
[16:25] <mok0> hyperair: 1) file a bug in LP. 2) bump to -0ubuntu2 3) fix error 4) make debdiff 5) attach debdiff to bug filed under 1)
[16:25] <loic-m> liw: so if I want to test how a backport that's not yet in the repos upgrades, I could use f.e. a ppa?
[16:25] <liw> loic-m, sure; with --mirror you can add any apt repositories you wish
[16:25] <hyperair> mok0: regarding 1), are there any tags i should put?
[16:26] <hyperair> mok0: also, once i attach the debdiff, could i ask you to sponsor it for me? =p
[16:27] <mok0> hyperair: you just subscribe "ubuntu-universe-sponsors" to the bug
[16:27] <hyperair> mok0: alright
[16:28] <mok0> hyperair: then it appears on this list, and the first available motu will patch & upload https://bugs.edge.launchpad.net/~ubuntu-universe-sponsors
[16:28] <hyperair> alright
[16:29] <loic-m> liw: one last question: can't one use a non-repository package instead (f.e. for Hardy) then test how it would upgrades with those in the repos for Intrepid and Jaunty?
[16:29] <liw> loic-m, I can't think of a way to do that, off the top of my head
[16:30] <liw> loic-m, it's not a use case I imagined in 2005, basically
[16:31] <loic-m> liw: ok, thanks
[16:35] <hyperair> mok0: README.source is in srcdir or srcdir/debian?
[16:35] <mok0> hyperair: debian/
[16:35] <jpds> Piratenaapje: If someone reviews it and acks it, it'll move up to advocated packages.
[16:35] <hyperair> mok0: strange, the patch dumped it into ./
[16:36] <mok0> hyperair: hm
[16:36] <hyperair> mok0: nevermind, i'll just shift it
[16:36] <hyperair> strange
[16:36] <mok0> hyperair: did you apply patch from topdir/.. ?
[16:37] <hyperair> mok0: no, but i used -p2
[16:37] <mok0> hyperair: that's probably why
[16:37] <mok0> hyperair: you stripped off debian/
[16:38] <mok0> hyperair: try using patch -p0 from $topdir/..
[16:39] <Piratenaapje> jpds: Ok, still have alot of things to fix first
[16:39] <hyperair> mok0: no i didn't. the other files patched just fine
[16:39] <mok0> hyperair: I'm puzzled
[16:39] <hyperair> mok0: so am i.
[16:46] <hyperair> mok0: should i upload to revu?
[16:47] <mok0> hyperair: wait & see if it gets accepted
[16:47] <hyperair> mok0: okay
[16:48] <jpds> Nought in ~ftp/incoming.
[16:53] <Turl> hello :)
[16:54] <Turl> is it a good practise to copy a package to other ubuntu releases in a PPA?
[16:54] <Turl> like I did in https://launchpad.net/~specto/+archive
[16:57] <loic-m> When updating a package from upstream, I just open a Launchpad bug, attach the new .diff.gz, subscribe u-u-s, Status>confirmed, Assign>Nobody, but should I look for a sponsor or is it ok like that?
[16:57] <oojah> Turl: If the package doesn't need rebuilding for the different releases (because of incompatible library versions for example), then it's ok afaik.
[16:58] <Turl> loic-m: did you subscribe ubuntu-universe-sponsors?
[16:58] <Turl> oojah: then it's OK I guess
[16:59] <Turl> it's python, not even compiled
[16:59] <loic-m> Turl: going to subscribe u-u-s, didn't finish filing the bug
[16:59] <oojah> Turl: Even better then.
[17:08] <jpds> RainCT: Do you know what this mini_file.tmp and test_file.tmp are doing in spooky's /srv/uploads?
[17:09] <jpds> these*
[17:10] <RainCT> jpds: nope
[17:10] <jpds> Right, rm time.
[17:14] <quadrispro> could someome review this? http://revu.ubuntuwire.com/details.py?package=w-scan
[17:15] <quadrispro> james_w: sugar patch is coming, i'm very busy in the last period :)
[17:16] <james_w> quadrispro: excellent, thanks. There's no rush, in fact it may be better to just drop the change in the next merge, what do you think?
[17:18] <quadrispro> james_w: yes, in fact I'm workin on the merge with 0.82.9-5 (from debian unstable)
[17:18] <james_w> ah, perfect, thanks.
[17:18] <quadrispro> :)
[17:19] <james_w> feel free to subscribe me directly for sponsorship
[17:19] <quadrispro> oh, thanks a lot :)
[17:32] <iefremov> Hi All! MOTUs needed for review ugene - genome analysis suit based on Qt. http://revu.ubuntuwire.com/details.py?package=ugene
[17:54] <mok0> iefremov: building it now...
[18:08] <rugby471> quick question: I am fixing a bug in SCIM's .desktop file
[18:09] <rugby471> in debian/patches there is already a patch that edits the .desktop file
[18:09] <rugby471> do I create a new patch, or create a patch for the patch?
[18:15] <rugby471> anyone? If there is a bug that involves the same part of a file that a patch already exists for, do I create a new patch or edit the old one?
[18:20] <rugby471> hello?
[18:24] <rugby471> i'm trying not to be impatient but is anyone going to help?
[18:26] <Piratenaapje> I would, but I don't know the correct answer, no use giving you incorrect info :p
[18:29] <mok0> rugby471: what patch system?
[18:30] <rugby471> dptach
[18:30] <rugby471> dpatch
[18:31] <rugby471> Piratenaapje: thats fine :-)
[18:31] <mok0> rugby471: the best and most maintainable is to apply the old patch first, then the new patch
[18:31] <rugby471> so create a new patch?
[18:31] <mok0> rugby471: yes, that operates on the file as it looks after the first patch has been applied
[18:31] <rugby471> it's just that the patch in question actually edits the exact line that the new patch will need to
[18:32] <mok0> rugby471: where does the first patch come from?
[18:32] <rugby471> um..
[18:32] <rugby471> looks like debian
[18:33] <mok0> rugby471: Then it's better to make a second patch like I said
[18:33] <rugby471> ok
[18:33] <mok0> rugby471: you can send your change to the Debian maintainer
[18:33] <rugby471> how do I make sure it gets applied last?
[18:33] <mok0> rugby471: list it after the first one in 00list
[18:33] <rugby471> ok
[18:33] <rugby471> thanks
[18:34] <rugby471> :-)
[18:34] <mok0> rugby471: go for touchdown!
[18:34] <rugby471> hehe
[18:34] <mok0> :)
[18:34] <mok0> I have to go, see you guys
[18:34] <rugby471> see ya
[18:38] <doctormo> Where is the best place to go for deb advice? I'm trying to rebuild a debian package, but my experence has been only with python debs, this is c.
[18:40] <doctormo> hmm I copied a rules file from somewhere else, seems to have worked :-/
[18:43] <iefremov> Any alive MOTU here? reviewer is needed for ugene - complex bioinformatics tool. Already reviewed by mok0. http://revu.ubuntuwire.com/details.py?package=ugene
[18:54] <soc> hi
[18:54] <soc> are there any plans to update texlive from release 2007 to release 2008?
[19:10] <fabrice_sp> doctormo, if it is an existing debian package, why do you copy another rules file?
[19:10] <soc> ooops, sorry closed the window ...
[19:10] <soc> my question was:
[19:10] <soc> are there any plans to update texlive from release 2007 to release 2008?
[19:10] <fabrice_sp> soc: is there a bug report?
[19:10] <soc> mom
[19:12] <fabrice_sp> in mom, you only have from 2007.dfsg.8-1ubuntu1 and 2007.dfsg.15-1 in Debian
[19:12] <doctormo> fabrice_sp: the existing rules, don't exist, I have only the binary deb.
[19:12] <fabrice_sp> so no 2008 release there
[19:12] <fabrice_sp> doctormo, where did you download it from?
[19:12] <fabrice_sp> you should be able to ownload also the source pacakge
[19:12] <soc> https://bugs.launchpad.net/ubuntu/+source/texlive-base/+bug/287502
[19:13] <doctormo> fabrice_sp: http://specificcrap.arbitrarycrap.com/ I've contacted the developer, and had a look round for other debs
[19:15] <DktrKranz> Laney, syncs ACKed and rebuilds uploaded :)
[19:15] <fabrice_sp> doctormo, you can package it from scratch if you don't have the source. Just follow the packaging guide (https://wiki.ubuntu.com/PackagingGuide)
[19:17] <fabrice_sp> soc, did you see the packager comment in debian bug? Doesn't seems the package will ahppen soon, except if someone makes the upgrade
[19:18] <fabrice_sp> (soc, are you volunteer?)
[19:20] <doctormo> fabrice_sp: I shall take this opertunity to learn fromt he well troden path.
[19:20] <_stochastic_> I was pointed toward the new debian machine-readable copyright format: http://wiki.debian.org/Proposals/CopyrightFormat by mok0
[19:20] <soc> fabrice_sp: i did already create an official package ...
[19:20] <_stochastic_> Is this something ready for use in Ubuntu?
[19:21] <soc> but texlive seems to be a bit too complucted for me
[19:21] <soc> _stochastic_: you can just use it
[19:21] <soc> it doesn't change that much
[19:21] <fabrice_sp> soc, even upstream is saying it's complicated, so I understand you. Maybe you can have a look at their svn, as it seems the debian subdirectory is there
[19:22] <soc> ah k
[19:24] <_stochastic_> If the addresses for the FSF in some of the source files in a package are wrong, do they need to be manually changed, or just mentioned that it's an incorrect address in the debian/copyright file?
[19:25] <soc> fabrice_sp: where do they have a svn?
[19:25] <doctormo> I'm not too happy about any of the choices given by dh_make, is an xorg input module a library or a kernel module?
[19:27] <fabrice_sp> soc, http://www.tug.org/texlive/svn/
[19:28] <fabrice_sp> doctormo, I would say xorg input module is a module, no?
[19:28] <_stochastic_> DktrKranz, I was supposed to remind you about bug #211798 a few days ago but I wasn't around during evening time in europe
[19:28] <fabrice_sp> but I really don't know :-/
[19:29] <doctormo> fabrice_sp: yes, but is it a kernel module? dh_make seems to assume a great deal about that in the rules. So I think it's best perhaps if I call it a single binary
[19:29] <DktrKranz> _stochastic_, indeed, thanks ;)
[19:30] <fabrice_sp> doctormo, really don't know. Maybe someone else could help you
[19:35] <_16aR_> Hello, can anyone review hexdiff ? package to visually analyse binary differences between 2 files (in hexa off course). Nobody has put any comments right now, so it could be cool to look at it : http://revu.ubuntuwire.com/details.py?package=hexdiff
[19:42] <soc> some chinese user here?
[19:55] <doctormo> This is an odd error "dpkg-source: error: cannot represent change to wizardpen-0.6.0.2/debian/wizardpen/usr/lib/xorg/modules/input/wizardpen_drv.so: binary file contents changed"
[19:55] <doctormo> anyone know what it means?
[19:58] <furicle> Hi All - hubackup has been broken since edgy - 2006 - see bug#64594 - I think it should be dropped from universe - Docs I've found talk about sponsoring new software, but aren't clear about requesting removal if you aren't a dev.  What's the next step??
[19:59] <JontheEchidna> Basically you file a request for removal stating why it should be removed, then once an motu has said that it's ok they will subscribe the archive admins
[19:59] <JontheEchidna> who will then remove the package from the archives
[20:00] <furicle> forgive the potential stupidity here - but file the request where?  Create yet another bug?  It's been requested on that bug a couple of times by various people.  Or?
[20:01] <fabrice_sp> doctormo, you miss something in the clean target
[20:01] <JontheEchidna> furicle: you would want to file a separate bug for that
[20:01] <fabrice_sp> doctormo, at least a call to "make distclean" or similar
[20:01] <doctormo> fabrice_sp: looked like the extra make arguments that dh_make sticks in
[20:01] <_stochastic_> If the addresses for the FSF in some of the source files in a package are wrong, do they need to be manually changed, or just mentioned that it's an incorrect address in the debian/copyright file?
[20:02] <doctormo> fabrice_sp: this code has no make clean or make distclean
[20:02] <fabrice_sp> doctormo, this error comes from a binary file that you left behind not deleted in the clean target)
[20:02] <doctormo> ok
[20:03] <JontheEchidna> furicle: here's an example: https://bugs.edge.launchpad.net/ubuntu/+source/plasmoid-lancelot/+bug/301083
[20:04] <furicle> Thank you for the info - I'll go do that.
[20:04] <JontheEchidna> You're welcome
[20:06] <maxb> Is there anything that should be done to flag such a bug for MOTU ack-ing attention?
[20:07] <maxb> There are quite a number of packages which have been ftfbs for a number of releases.
[20:10] <JontheEchidna> hmm
[20:10] <JontheEchidna> I usually just poke some motu I know in #kubuntu-devel whenever I need an motu-ack :P
[20:10]  * JontheEchidna isn't an motu quite yet
[20:14] <fabrice_sp> ScottK, I've just uploaded dvdstyler (http://revu.ubuntuwire.com/details.py?package=dvdstyler). Can you check it's ok so  that I can ping mok0 to ack it? thanks
[20:18] <loic-m> Does anybody know how I can set it up so I only have to provide my password once when running debuild -S -sa ?
[20:22] <jpds> loic-m: Run gpg-agent.
[20:23] <loic-m> jpds: thanks
[20:24] <doctormo> fabrice_sp: huh, now I'm trying to get the actuall files to go with the package. I tried added usr/lib/xorg/modules/input/ to dirs, but no luck.
[20:34] <fabrice_sp> doctormo, you have to build the files first. After that, all the magic happen in the rules files
[20:34] <Necrosan> Any of you do the sparc work here? The archives are all screwed up.
[20:36] <jpds> Necrosan: How do you mean screwed up?
[20:37] <Necrosan> jpds: tons of unsolved dependencies. linux-sparc64-smp will not install, xserver-xorg-video-sunffb also will not
[20:39] <Necrosan> This is on intrepid
[20:39] <Necrosan> Gonna update to  jaunty and see if the crap is fixed
[20:39] <Necrosan> surprised that all slipped through the cracks..
[20:43] <lfaraone> Hey, shouldn't we blacklist debian-edu since they A) don't provide anything other than metapackages and B) are a subdistrobution of debian made redundant by edubuntu?
[20:49] <Necrosan> makes sense
[21:09] <lfaraone> Necrosan: ok, how can I get uit BL'd?
[21:22] <pwnguin> loic-m: you gonna update desmume?
[21:23] <loic-m> Yes, I already filed the information in Launchpad
[21:24] <loic-m> They build ok with pbuilder (jaunty/intrepid, i386/amd64) and I tested the Intrepid amd64
[21:24] <loic-m> debian should be in freeze, so i figured it would be to late when they upload it
[21:25] <loic-m> it's at bug #321525
[21:28] <pwnguin> loic-m: it still has bad sound in kirby, but that's probably unavoidable in the near term
[21:29] <loic-m> pwnguin: it should be the same if you build it from source. Do you want to test the packages (in case you've got another arch than me)?
[21:37] <ScottK> fabrice_sp: Looking
[21:38] <doctormo> fabrice_sp: I don't understand where the rules files specifies what files need to be added to the binary deb
[21:38] <doctormo> the files are build and exist in the debian dir
[21:44] <laprice> Is there a good document that explains the interaction between dependencies, apt and dpkg?
[21:44] <pwnguin> loic-m: ive got jaunty and intrepid i386 i can test with if you like
[21:45] <tarimari> hi guys
[21:45] <tarimari> there is a ppa for xorg crack pushers. when these new version will be backported at intrepid?
[21:46] <tarimari> and a more general question: i use experimental ppa repos for kde 4.2, openoffice, xorg etc. when these will be officially available at ubuntu backports, then the official repos will automatically have some priority so the update will happen from official repos, or should i disable the experimental repos firstly?
[21:46] <loic-m> pwnguin: sure
[21:47] <pwnguin> tarimari: that sounds like a question for #ubuntu-x
[21:47] <pwnguin> the xorg crack at least
[21:47] <tarimari> what channel is ubuntu-x?
[21:47] <tarimari> ah
[21:47] <tarimari> ok
[21:47] <tarimari> but what about the general question?
[21:48] <tarimari> ubuntu understand so that it replaces the experimental packages, when they are officially available, or should i follow the new, to see when to disable the experimental?
[21:52] <loic-m> tarimari: I wouldn't bet on packages as critical as xorg/kde2/OO to be backported in Intrepid, too much risk of breakage. But you should ask on the relevant mailing list. Best bet is you'll upgrade from intrepid>Jaunty when it's released
[21:53] <tarimari> too much time to wait :)
[21:53] <tarimari> so what it is expected to be backported in intrepid? :)
[21:54] <loic-m> tarimari: independent programs, usually not too big, not involving massive changes in other areas, bringing relevant new functionnality
[21:55] <tarimari> ok i understand this for xorg or kde, but OO.org bring a lot of new functionality?
[21:58] <Laney> DktrKranz: \o/ thanks
[22:01] <loic-m> tarimari: OO is also a pretty big beast, it had AFAIR some regressions even in 3.0 final, and going from 2.4>3.0 might mess things in some use cases
[22:02] <loic-m> tarimari: for OO3 you have a ppa (you'll have to look for it though) or you can use the binary they provide)
[22:08] <ScottK> Actually we're planning on backporting KDE 4.2
[22:09] <ryanakca> Umm... I received an email from REVU saying that ``There has been a new upload for package aoeui.'' today and that I had uploaded it... but I've done no such thing? Any idea why this would happen?
[22:10] <Necrosan> ryanakca: Someone got y'r l/p?
[22:12] <ryanakca> Necrosan: Someone got my launchpad?
[22:12]  * ryanakca scratches his head confusedly
[22:12] <Necrosan> You tell me. ;)
[22:12] <ryanakca> Are you talking about my launchpad account?
[22:13] <ryanakca> If so, then no, I'm the sole own of my launchpad account....
[22:13] <ryanakca> s/own/owner/
[22:14] <Necrosan> If you're sure it's secure, probably just a mistake then.
[22:14] <ryanakca> *nod*
[22:15] <loic-m> ScottK: that's good news for KDE users. I still have kde-desktop installed, that'll be at least one reason to change the session ;)
[22:16] <jpds> ryanakca: Dude, that was my email.
[22:16] <RainCT> ryanakca: you're subscribed to that packages; all subscribers get mails concerning it
[22:16] <RainCT> nvm then :P
[22:16] <ryanakca> jpds: You sent two?
[22:16] <jpds> RainCT: No, I mailed everyone who had a package in rejected/, with BCC:
[22:16] <ryanakca> I know I got one from you, but I also got one from motu-reviewers later on that day
[22:17] <jpds> ryanakca: Oh, right.
[22:17] <jpds> ryanakca: Oh, I also pushed everything in rejected/ to the processing queue to clear out any possible duds, that might of triggered the other email.
[22:18] <ryanakca> jpds: Ah, that's probably it
[22:19] <oojah> jpds: I presume that packages in rejected/ will just disappear without intervention at some point?
[22:19] <jpds> oojah: They'll stay there until someone deletes them, but I mailed everyone who has a package thee today.
[22:20] <RainCT> oojah: they are manually removed from tme to time
[22:21] <jpds> RainCT: Why aren't binary uploads moved to rejected/?
[22:22] <jpds> RainCT: I found some .deb's in uploads, rm'ed them tho.
[22:22] <oojah> Yeah, I got an email about it. There's something in rejected because I hadn't logged into revu before uploading. The package in rejected has had later versions uploaded to revu though, so it's surplus to requirements.
[22:23] <jpds> oojah: Which package?
[22:23] <oojah> ralcalc
[22:24] <jpds> oojah: It's on REVU already? So I can remove the rejected .changes file?
[22:26] <jpds> oojah: OK; it does look like you did that upload before logging in.
[22:26] <oojah> Correct
[22:26] <oojah> Yes, I did.
[22:26] <jpds> Thanks.
[22:29] <oojah> jpds: It might be worth ammending your email in the future to point out what to do if you don't want the rejected package any longer.
[22:30] <jpds> oojah: There's a first time for everything, I'll do better next time.
[22:30] <oojah> :)
[22:30] <oojah> I wasn't intending to have a go at you...
[22:31] <jpds> oojah: I didn't it as such, don't worry.
[22:36] <stooj> Hi all - wondering if I could get some advice: I've just started out with learning to package and have found something that should be a doddle to do. However, it's a policy change rather than a bugfix, and I wanted to know how to find out whether it was an appropriate change with the devs or not. Any suggestions where to ask/look?
[22:36] <directhex> just ask
[22:39] <ScottK> fabrice_sp: Advocated.
[22:39] <stooj> OK. Uhm, it's the background for gnometris
[22:39] <stooj> Two secs
[22:40] <imbrandon> gitfm
[22:40] <imbrandon> err
[22:41] <jpds> Hey imbrandon.
[22:42] <imbrandon> heya jpds , hows it goin
[22:42] <imbrandon> ryanakca: also when a sync happens and you requested it , it will/can show you did it
[22:42] <jpds> imbrandon: Not too bad, yourself?
[22:42] <imbrandon> not saying thats the case but just FYI ( re: aoeiu )
[22:42] <ryanakca> imbrandon: *nod*
[22:43] <imbrandon> jpds: good good, been crazy at work because of the $$ in the US , but its all flatening out now
[22:43] <imbrandon> :)
[22:44] <stooj> https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/138713 - is this OK to try to package?
[22:44] <imbrandon> jpds: contemplating getting a new laptop, or more specificly a "netbook" but not 100% sold on the idea yet
[22:44] <imbrandon> stooj: it uses that logo by choice, not a matter of theming
[22:45] <jpds> imbrandon: I have an Acer Aspire One, which is doing pretty well, apart from the annoying tiny keys.
[22:45] <stooj> So, not appropriate to do. OK, thanks imbrandon
[22:45] <ScottK> fabrice_sp: Uploaded.  Thank you for your contribution to Ubuntu.
[22:45] <imbrandon> yea thats what i was looking at, i had an eeepc 900
[22:45] <imbrandon> and dident like the tiny keys
[22:45] <imbrandon> stooj: yea, upstream uses that logo, its not a matter of theming per se
[22:46] <imbrandon> jpds: just curious , why the new nick ? ( ment to ask the other day , lol )
[22:46] <jpds> imbrandon: I felt like a change.
[22:46] <imbrandon> :)
[22:47] <imbrandon> i think a 12'' notebook would be perfect but .... hrm .... i just wish they made the 12'' powerbooks still, that was like my "perfect" laptop
[22:47] <imbrandon> not tooo small but not bulky , and plenty of power but not a "gamer" etc
[22:48] <directhex> imbrandon, dell latitude e4300!
[22:48] <imbrandon> for now i just lug arround my lenovo t61 :)
[22:49] <imbrandon> how solid are those? seems every dell product i've touched seems to feel "cheap"
[22:49] <imbrandon> aside from the server line
[22:49] <directhex> imbrandon, this is my second latitude. it's... what i wanted
[22:50] <directhex> imbrandon, backlit keyboard, lovely styling, more or less works with intrepid
[22:50] <directhex> meaning the wifi drivers which someone shoved into the intrepid kernel a few weeks before release aren't quite 100% reliable
[22:51] <imbrandon> directhex: cool, i'll give it a look
[22:52] <imbrandon> directhex: no biggie, being an (ex-) core-dev i'm not oposed to tinkering getting hardware to work :)
[22:52] <imbrandon> anyhow dinner time, bbiab
[22:53] <imbrandon> jpds: you running kde 4.2 ?
[22:59] <ScottK> imbrandon: I've got a Latitude D430 I'm very happy with.
[23:00] <ScottK> IME their Inspiron line are toys that break, the Latitudes aren't bad.
[23:00] <pwnguin> holy crap, imbrandon is alive
[23:02] <pwnguin> imbrandon: toshiba makes some interestingly small tabletPCs
[23:02] <Laney> james_w: You're a forest/derby fan? (just seen identi.ca...)
[23:02]  * Laney is going to the replay
[23:03] <pwnguin> a ksu sysadmin showed me a few and they seemed to run okay on a liveCD i had on me
[23:03] <imbrandon> pwnguin: hahah yea, as always, i just shy away from IRC sometime ( months at a time )
[23:03] <imbrandon> irc eats alot of time
[23:04] <imbrandon> but i'm always "arround"
[23:04] <pwnguin> what part of the country are you in these days?
[23:05] <imbrandon> back in KC for  the moment, will be headed to London at the end of Feb
[23:05] <pwnguin> oh my
[23:05] <imbrandon> for 8 months to a year
[23:06] <imbrandon> our company just bought out a UK company , and there is the whole "rebranding" thing
[23:06] <imbrandon> and i get to head it up and kick off a new site for our largest UK customer :)
[23:06] <DktrKranz> _stochastic_, uploaded
[23:16] <james_w> Laney: Forest
[23:16] <Laney> good choice
[23:17] <Laney> I shall be there tomorrow too
[23:19] <james_w> excellent