[12:02] <minghua> aptitude is really giving me a headache
[12:03] <lifeless> wow
[12:03] <\sh> ogra: the cube 21h
[12:03] <lifeless> multisync 0.90.18 really is experimental
[12:03] <ajmitch> it wipes all your data?
[12:03] <lifeless> it ignores deletes on the phone
[12:03] <lifeless> can't configure the irmc plugin
[12:04] <ogra> \sh, expect it to go over 1000 then ...
[12:05] <minghua> amazon US is actually selling iBook G4 at $900, not sure about europe though
[12:11] <ogra> in europe you get the cheapest around 1000
[12:12] <\sh> night guys
[12:17] <lifeless> ajmitch: azeem ping
[12:17] <minghua> crimsun: bug #5888 is the first package for scim rebuild.  I'll work on others tonight and tomorrow
[12:17] <Ubugtu> Malone bug #5888: scim-canna: package needs rebuild against libscim8c2a In: Ubuntu, Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/5888
[12:17] <crimsun> minghua: ok
[12:18] <ajmitch> lifeless: pong
[12:18] <lifeless> so
[12:18] <lifeless> opensync 0.18
[12:18] <lifeless> I packaged that version thinking that tracking releases would be a good idea
[12:18] <lifeless> I'm not sure that that is the case :[
[12:18] <ajmitch> but no..
[12:18] <ajmitch> the release is broken?
[12:18] <lifeless> fooked
[12:18] <minghua> crimsun: I believe you prefer my sending all debdiffs to you together instead of bugging you for each package :-)
[12:18] <ajmitch> sigh
[12:19] <ajmitch> do they test it at all before releasing?
[12:19] <lifeless> its not that
[12:19] <lifeless> its that its a noticable step back from multisync - lots of things broken in the rearchitecture FWICT
[12:20] <crimsun> minghua: either way
[12:20] <lifeless> I'm just tracking down a bug in irmc for instance
[12:20] <ajmitch> that's quite unfortunate - I thought they were trying to fix what was lacking
[12:20] <lifeless> 0 length vcal files are reported as 'modified'
[12:21] <ajmitch> yes, I saw in the channel
[12:22] <sistpoty> revu new world order is done :)
[12:22] <ajmitch> sistpoty: revu2 is finished? ;)
[12:22] <minghua> One question: is MoM clever enough to knwo that -XbuildY version doesn't have sourceful changes and sync them automatically?
[12:22] <ajmitch> minghua: yes
[12:22] <sistpoty> ajmitch: no only sorting the list for revu 1
[12:22] <ajmitch> minghua: that's why we use that - it only looks at -XubuntuY
[12:23] <minghua> cool, then I don't need to babysit scim-m17n in dapper
[12:23] <lifeless> ajmitch: the ui to configure irmc is awol
[12:23] <minghua> ajmitch: thanks.  I thought that would be the whole point of differing -XubuntuY and -XbuildY suffices
[12:24] <lifeless> ajmitch: it *looks* to me like their split into parallel hiearchies was not done preserving the old functionalit
[12:24] <lifeless> y
[12:24] <ajmitch> lifeless: it was a ground-up rewrite
[12:24] <ajmitch> and they're filling in the pieces as needed?
[12:24] <lifeless> no
[12:24] <lifeless> definately a lot of old code there, the copyrights tell the tale
[12:25] <lifeless> I think it was a hacknslash job to the new framework
[12:25] <lifeless> and devil take the hindmost
[12:27] <lifeless> that bugs in HEAD anyway, whew
[12:27] <ajmitch> that's a good thing?
[12:27] <lifeless> yes, it means I don't have to backport a fix on an active project
[12:28] <scotth> I'm curious, how do people here upgrade their packages to new upstream versions.  Do you apply the diff or move the debian dir over or start from scratch or is there some automated tool for this?
[12:28] <sistpoty> scotth: uscan/uupdate can automate this process
[12:29] <scotth> sistpoty, thanks
[12:30] <sistpoty> scotth: and if you don't use that, it's usually a good idea to move the debian dir over, as more things will stay the same then will change
[12:30] <minghua> scotth: and maybe consider making all debian/ubuntu specific changes into patches, so all the .diff.gz is limited in debian/ dir
[12:31] <lifeless> for an alternative, I put everyine in bzr
[12:31] <lifeless> then a new upstream is just a new commit in the upstream branch, and a merge.
[12:32] <ajmitch> lifeless: how do you handle moved files in upstream?
[12:32] <ajmitch> you untar new upstream tarball, copy over .bzr?
[12:33] <lifeless> ajmitch: I untar the tarball if the upstream does not use vcs.
[12:33] <lifeless> ajmitch: then check status etc and adjust, the commit
[12:34] <lifeless> ajmitch: but if the upstream uses vcs, its easier still ;)
[12:34] <ajmitch> certainly
[12:34] <ajmitch> but then you don't have an orig.tar.gz that matches upstream, which can be a little annoying
[12:34] <lifeless> I guess thats another reason I largely ignore tarballs for packaging
[12:34] <minghua> hmm, maybe I should do the same thing
[12:34] <lifeless> meh
[12:35] <lifeless> the number of upstreams that release 'orig' tarballs we cant directly use is growing not decreasing
[12:35] <minghua> my upstream used CVS and all my debian packaging stuff is in SVN now
[12:35] <lifeless> -> autoconf dependencies & configure or makefile bugs
[12:35] <ajmitch> lifeless: we've just run into a few issues where debian & ubuntu have packaged a new upstream version separately, with differing tarballs
[12:35] <ajmitch> makes syncing a real pain
[12:35] <lifeless> -> included inappropriate files such as object or GFDL files
[12:35] <ajmitch> that one is annoying
[12:35] <scotth> sistpoty, how do you create a watchfile if none is provided upstream?
[12:35] <lifeless> ajmitch: yeah, I can imagine. Fortunately, as I can't upload to ubuntu yet, that won't happen ;)
[12:36] <sistpoty> scotth: just look at "man uscan"... good source for examples
[12:36] <scotth> lol, of course
[12:43] <minghua> speaking of modifying .orig.tar.gz, what is the conventional way to deal with .tar.bz2 only upstream?
[12:43] <minghua> just bunzip2 and gzip it?
[12:43] <lifeless> yes.
[12:44] <lifeless> unless its insanely big
[12:44] <lifeless> in which case ... evil happens
[12:45] <scotth> is there a good way to find out if a package has a motu maintainer?
[12:45] <ajmitch> most packages in universe don't have a motu that is caring for that specific one
[12:46] <ajmitch> there are some teams that do
[12:46] <lifeless> opensync-debian-team rah rah rah
[12:46] <minghua> I was wondering about that as well
[12:46] <ajmitch> mono team, etc
[12:46] <minghua> it would be nice to have some way to indicate a universe package get more love than others
[12:47] <minghua> which means some MOTU/MOTU-wannabe is building and testing it
[12:47] <crimsun> grep the output from dapper-changes and pipe it through wc -l? ;)
[12:47] <minghua> instead of just simplying syncing/merging from sid
[12:48] <minghua> crimsun: not a bad idea... :-)
[12:48] <scotth> well I'm interested in gajim, ejabberd, and a few other jabber related things.  I notice that gajim is listed in launchpad.net and has a registrant.  Does that mean it has a maintainer kinda?
[12:48] <ajmitch> scotth: for that, there's the MOTU IM team
[12:49] <ajmitch> https://wiki.ubuntu.com/MOTUIM
[12:49] <ogra> scotth, just look who touched it last (changelog) for any package, and talk to this guy if he cares personally, but in general we dont have any personalized packages
[12:49] <scotth> ahh
[12:49] <scotth> makes sense
[12:50] <ogra> most is done in teams here ... no "maintainers" like debian has
[12:50] <scotth> actually it looks like I might want to join MOTUIM
[12:50] <scotth> it looks to be right up my alley
[12:50] <ogra> indeed there are people that care more for certain packages ...
[12:51] <scotth> is it acceptable to add my name to that team in the wiki or should I contact the people listed?
[12:51] <ogra> do both ;)
[12:52] <scotth> cool
[01:09] <lifeless> ajmitch: azeem: anyway, I think we need to upload multisync 0.90 in parallell with 0.8x
[01:09] <lifeless> for a while yet
[01:09] <lifeless> tchau - yum cha time
[01:15] <Riddell> blurg, skim fails to build and I can't work out why or recreate it
[01:15] <Riddell> /usr/bin/fakeroot debian/rules binary-arch
[01:15] <Riddell> make: Nothing to be done for `binary-arch'.
[01:16] <desrt> sistpoty; i talked to the debian upstream guy about ghc.  as it turns out, someone reported the bug that the patch fixes against debian so he plans on integrating the patch (probably not until after the holidays, though)
[01:17] <sistpoty> desrt: thx... I just check timetable when upstreamversion-freeze will be for dapper
[01:18] <desrt> ah.  right.
[01:18] <eruin> is the maintainer of linphone around?
[01:18] <desrt> having a working ghci on powerpc is decidedly in my interests so i'd definitely advocate including the patch for ourselves if debian isn't fast enough :)
[01:19] <minghua> hi Riddell, is the build log somewhere?
[01:19] <Riddell> http://people.ubuntu.com/~lamont/buildLogs/s/skim/1.4.3-0ubuntu3/skim_1.4.3-0ubuntu3_20051217-2251-powerpc-failed.gz
[01:20] <eruin> if liblinphone1 depends on libjack0.100, but liblinphone1-dev depends on libjack0.100 - should I file a bug?
[01:20] <Riddell> eruin: why, that's the same thing?
[01:20] <eruin> well, that makes liblinphone1-dev uninstallable
[01:21] <eruin> oh, my mistake,. liblinphone1-dev depends on libjack0.80 ;)
[01:21] <sistpoty> desrt: we have uvf on jan 19. So i guess it will be better, if I include the patch soon... I still have the possibility to go in sync with debian later on
[01:21] <eruin> poor typing this late
[01:21] <sistpoty> desrt: where can I find your patch? in BTS?
[01:21] <desrt> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343428
[01:22] <sistpoty> desrt: cool, thx. will care for it during next week
[01:23] <desrt> sistpoty; most excellent.  thanks.
[01:23] <sistpoty> np
[01:23] <Riddell> eruin: looks like a beastie!  I'm taking a look
[01:23] <eruin> Riddell, thanks mate :)
[01:26] <Riddell> eruin: uploaded, keep an eye on http://people.ubuntu.com/~lamont/buildLogs/l/linphone/ to make sure it compiles
[01:32] <sistpoty> Riddell: I just take a look at skim (ubuntu2) and its rules
[01:32] <Riddell> sistpoty: see anything revealing?
[01:32] <minghua> sistpoty: do you mean 0ubuntu3?
[01:32] <sistpoty> Riddell: if I get it right, you should have a target binary-arch... binary should depend on binary-arch
[01:33] <ajmitch> sistpoty: see changelog for 0ubuntu3
[01:33] <sistpoty> minghua: no, I guess my sources are outdated
[01:33] <ajmitch>   * Add fake rule in debian/rules on binary-arch
[01:33] <minghua> sistpoty: Riddell added an empty binary-arch target in debian/rules, but it didn't seem to help
[01:33] <minghua> I was thinking maybe binary-arch should depend on binary-common or something
[01:34] <minghua> I'm building skim -0ubuntu3 in pbuilder right now
[01:35] <sistpoty> compared to dh_make templates and policy hints, binary should depend on binary-arch and binary-indep
[01:36] <sistpoty> however binary-arch is optional according to the policy... maybe sbuild is wrong there
[01:37] <sistpoty> args... no binary-arch must exist (according to policy) and always succeed (even if it has nothing to do)
[01:37] <ajmitch> which is why you often see an empty rule
[01:38] <minghua> sistpoty: you were looking at build-arch, weren't you? ;-)
[01:38] <sistpoty> yes
[01:39] <minghua> yikes, scons sends color terminal control code to its log
[01:40] <Kyral> scons...
[01:40] <Kyral> *shudder*
[01:43] <ogra> sistpoty, but thats a silly and very debianish part of the policy, the ubuntu buildds are more tolerant ...
[01:43] <sistpoty> hehe
[01:43] <ogra> i have some "non policy compliant" ubuntu only packages where i tipped it out
[01:43] <ogra> *riped
[01:44] <ogra> grrr
[01:44] <ogra> *rpped
[01:44] <sistpoty> the only thing that looks odd with rules, is that phony targets are not listed in .PHONY
[01:44] <ogra> ARGH
[01:44] <ogra> r i p p e d
[01:44] <ogra> phew
[01:45] <minghua> StevenK is probably going to be bold pretty soon... :-P
[01:46] <StevenK> I'm already bold. :-P
[01:46] <StevenK> ITYM bald. :-)
[01:46] <minghua> yeah, I meant bald
[01:47] <minghua> StevenK: thanks for correcting, I was actually not sure and looking it up
[01:48] <StevenK> minghua: I suspect you can usually speak English better than I can. :-)
[01:48] <StevenK> It may be my first language, but I still suck at it. :-)
[01:48] <minghua> Riddell: I got exactly the same error with "pbuilder build --binary-arch skim_1.4.3-0ubuntu3.dsc"
[01:49] <minghua> Riddell: so probably the buildd is right
[01:49] <Riddell> hmm, right
[01:50] <minghua> hammer? :-P
[01:50] <ajmitch> drill & hacksaw
[01:50] <Kyral> screwdriver?
[01:50] <StevenK> Kyral: No screws, only a lock.
[01:50] <StevenK> ajmitch: Ouch.
[01:50] <ajmitch> drill out the lock
[01:50] <StevenK> Tried that.
[01:50] <Kyral> yah I concur with ajmitch
[01:50] <Kyral> nm
[01:50] <ajmitch> ah :(
[01:50] <Kyral> Blowtorch?
[01:51] <StevenK> Well, I drilled a hole in the lock, is that the same thing?
[01:51] <sistpoty> ok... /me needs to go to bed now
[01:51] <sistpoty> gn8 everyone
[01:51] <ajmitch> that's usually how it's done
[01:51] <ajmitch> drill out the centre of it so that it can open
[01:51] <StevenK> And I think I bent the bit doing it.
[01:51] <ajmitch> night sistpoty
[01:51] <minghua> Riddell: I _think_ having binary-arch depending on binary-common would solve it
[01:52] <minghua> it looks like a -B build will only call binary-arch, not binary
[01:54] <minghua> the debian/rules of skim doesn't look very professional anyway
[01:59] <eruin> I wonder why my computer loves crashing/overheating so much when I compile gaim
[01:59] <eruin> or rather, ./configure it
[02:00] <LaserJock> if a file is installed from a package it can be found by dpkg -S right?
[02:02] <minghua> LaserJock: only if it's in the package's .list file (i.e., not installed by postinst script, etc.)
[02:03] <LaserJock> minghua: ahhh, can I find it if it is isn't in the .list file?
[02:03] <minghua> and sometimes symlinks confuse dpkg -S as well
[02:03] <minghua> LaserJock: the .list file is in /var/lib/dpkg/info/ if you installed it :-)
[02:05] <eruin> Riddell, linphone_1.1.0-2ubuntu2_20051218-0047-i386-given-back.gz
[02:05] <minghua> LaserJock: I don't know how...  probably looking at the postinst script?
[02:06] <eruin> Riddell, doesn't look too healthy, the poor thing
[02:06] <Riddell> eruin: the i386 buildds seem to be in a mood to do that today
[02:06] <eruin> Riddell, all work, no fun ;-)
[02:07] <LaserJock> minghua: there are posinst script in /var/lib/dpkg/info/ so maybe it's there. I just need to track down where a particular file got installed from
[02:09] <minghua> LaserJock: ah.  I was thinking you just want to know _if_ a certain file is from a certain package, now you want to know _whick package_ it is from...  that's harder :-)
[02:09] <LaserJock> minghua: yeah, there is a file that is creating a bug and nobody knows where it comes from
[02:10] <minghua> LaserJock: maybe first try "readlink -f file" to get rid of symlink problem first?
[02:10] <minghua> LaserJock: bug nubmer?
[02:11] <LaserJock> bugzilla 20183
[02:13] <minghua> where is our friend Ubugtu now?
[02:13] <minghua> Ubugtu: ubuntu 20183
[02:13] <Ubugtu> Ubuntu Bugzilla bug #20183: firefox 1.4.99 upgrade still have compreg.dat, creates issue Product: Ubuntu, Component: firefox, Severity: normal, Assigned to: iwj@ubuntu.com, Status: NEW https://bugzilla.ubuntu.com/show_bug.cgi?id=20183
[02:15] <Riddell> minghua: seems to have done the trick thanks
[02:15] <minghua> Riddell: no problem.  thank *you* for working on skim :-)
[02:16] <Riddell> well it was freeflying
[02:17] <minghua> Riddell: yeah, but you are the sponsor :-)
[02:17] <minghua> LaserJock: didn't comment #22 say it was shipped in mozilla-firefox 1.0.7?
[02:18] <Riddell> looks like I need to rebuild all the scim modules
[02:19] <minghua> LaserJock: oh never mind, I see comment #25 now
[02:19] <minghua> Riddell: for what reason?  I am working on the libstdc++ allocator transition rebuild right now
[02:19] <Riddell> minghua: oh, if you're doing it that's all good then
[02:20] <minghua> Riddell: if for skim support, then rebuild won't help
[02:20] <minghua> Riddell: yes, and crimsun is sponsoring me :-)
[02:20] <Riddell> ah good
[02:21] <Riddell> it's really good having CKJ types involved
[02:33] <minghua> Riddell: did freeflying say anything about the .orig.tar.gz inconsistancy to you?
[02:34] <minghua> Riddell: I met him on IRC a few days ago and he said he is waiting for William uploading it to debian now
[02:34] <minghua> Riddell: but he didn't say anything about my comments
[02:40] <Tonio_> good night
[03:35] <minghua> now I am finally getting this scim-setup segfault myself.
[04:13] <LaserJock> any MOTUs willing to do a quick review?
[04:13] <bmonty> LaserJock: what kind of review?
[04:13] <LaserJock> REVU review
[04:14] <bmonty> which package?
[04:14] <LaserJock> plotdrop
[04:15] <LaserJock> minghua: do you use gnuplot?
[04:15] <minghua> LaserJock: yes
[04:16] <LaserJock> you might like this package I've got on revu, plotdrop. You can drag n drop data files into it and plot them with gnuplot
[04:16] <LaserJock> it's pretty cool
[04:17] <LaserJock> the homepage is at http://icculus.org/~jcspray/plotdrop/
[04:18] <minghua> LaserJock: sounds cool. thanks
[04:18] <LaserJock> and the author is an Ubuntu user so that is cool to ;-)
[04:25] <LaserJock>  bmonty: a .desktop file is intalled
[04:26] <bmonty> ahh, I see it now :)
[04:27] <LaserJock> so I don't need to keep the comments at the top?
[04:27] <bmonty> LaserJock: nope...you only need the first line
[04:28] <bmonty> the rest of the comments don't really apply IMO
[04:28] <LaserJock> what about # -*- makefile -*-
[04:28] <LaserJock> does that do anything?
[04:28] <bmonty> no
[04:29] <minghua> LaserJock: that's for emacs IIRC
[04:29] <bmonty> even more reason to remove it :)
[04:29] <LaserJock> lol
[04:29] <LaserJock> ok, uploaded
[04:31] <LaserJock> bmonty: not an emacs fan?
[04:32] <bmonty> LaserJock: its not my favorite editor
[04:33] <LaserJock> bmonty: so do you like vim better or something else?
[04:33] <bmonty> I personally like vim better than emacs
[04:35] <LaserJock> I started out with emacs but I am starting to get used to vim. I have to force myself to use each one for a few days at a time. I am getting better at both that way.
[04:37] <LaserJock> sweet, thanks bmonty
[04:37] <bmonty> np
[04:39] <bmonty> LaserJock: plotdrop builds here, I got a couple errors with piuparts but no files that your package touches
[04:43] <JohnnyMast> any one interested in looking @ ttb (revu)
[04:45] <LaserJock> bmonty: ahh, yeah. I need to get piuparts going. I haven't tried that out yet
[04:45] <bmonty> you have a pbuilder, right?
[04:45] <JohnnyMast> bmonty wasnt it you wo also looked at ttb ?
[04:46] <JohnnyMast> hey lukas
[04:46] <bmonty> JohnnyMast: maybe :)
[04:46] <JohnnyMast> bmonty well i have made my fixes
[04:46] <lukas> hey JohnnyMast
[04:46] <JohnnyMast> :D
[04:46] <LaserJock> bmonty: yeah, I have pbuilder and dchroot, but I haven't bothered to get piuparts going yet
[04:46] <JohnnyMast> welcome back home lukas
[04:47] <bmonty> LaserJock: you can use your pbuilder chroot with piuparts check out the -p or -b options
[04:47] <LaserJock> bmonty: sweet, good to know. I will look into that
[04:48] <minghua> crimsun: what I have done tonight is in malone 5894, 5895 and 5896
[04:48] <Ubugtu> Malone bug #5894: chewing (Ubuntu) - scim-chewing: needs rebuild against libscim8c2a In: scim-chewing (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/5894
[04:49] <minghua> crimsun: but scim-uim (5896) has some other bug, so you may want to delay that upload, please see my comments on malone
[04:49] <minghua> crimsun: thanks
[04:49] <crimsun> minghua: ok
[04:50] <crimsun> I'll look at 589[45]  then
[04:54] <JohnnyMast> punkrockguy318 nice nick :)
[04:54] <punkrockguy318> JohnnyMast, thank you =D
[04:54] <JohnnyMast> ur a punk rocker ?
[04:56] <JohnnyMast> and Johnny cash ... ring of fire
[04:56] <minghua> crimsun: is it okay to close the bug even if scim-canna hasn't been built on i386 yet? ;-)
[04:58] <JohnnyMast> while ur asking crimsun: (and hes gone)  i do advise you to wait
[04:59] <minghua> JohnnyMast: oh sure
[05:01] <JohnnyMast> but then again its just an advise
[05:01] <zakame> lunchtime all :D
[05:01] <JohnnyMast> luchtime ??
[05:01] <JohnnyMast> its 5 at night man
[05:01] <JohnnyMast> :p
[05:02] <zakame> er its 12 noon here :P
[05:02] <JohnnyMast> oh in that case, i would like one sandwitch with cheese please
[05:02] <JohnnyMast> neh ile make it my self and head to bed
[05:03] <JohnnyMast> mmm thanks man :)
[05:03] <zakame> JohnnyMast: rock on :)
[05:03] <JohnnyMast> :D
[05:04] <JohnnyMast> alright im gone, MOTU`s sand hopefulls sleep well
[05:05] <zakame> gn8 JohnnyMast
[05:05] <JohnnyMast> gn
[05:37] <Kyral> Goodnight MOTU
[05:38] <zakame> gn8 Kyral
[06:09] <zakame> bye all
[06:49] <LaserJock> azeem: ping?
[08:50] <zakame> hey all
[08:51] <minghua> hi zakame, welcome back :-)
[11:02] <Gloubiboulga> hello
[11:07] <pef> Gloubiboulga: salut :)
[11:08] <Gloubiboulga> salut pef :)
[11:30] <sivang> morning all
[11:32] <Gloubiboulga> hello sivang
[11:42] <greenpenguin13> would someone mind fixing bug #21126 please? ive tried myself, but... :-p
[11:42] <Ubugtu> Error: Error getting Malone bug #21126: Bug does not exist
[11:52] <Gloubiboulga> greenpenguin13, gnomemeeting just needs a rebuild I think
[12:01] <sivang> #21126
[12:02] <greenpenguin13> i will have a peek...
[12:04] <siretart> morning
[12:07] <greenpenguin13> afternoon
[12:13] <lifeless> azeem: around ?
[01:08] <herve> hello
[01:08] <zakame> hello herve
[01:54] <azeem> lifeless: hey
[02:07] <tseng> anyone on ppc64?
[02:31] <thierry> with debhelper, how can I put the configure thing before cleaning??
[02:34] <azeem> why do you need that?
[02:36] <StevenK> Presumably clean is running make clean with no Makefile.
[02:39] <thierry> StevenK , azeem : well it's because it's a ruby building apps, so when I do "ruby install.rb clean" before "ruby install.rb config" it complains that he needs to run config before
[02:41] <thierry> azzem , StevenK : so any idea how I could do that?
[02:41] <StevenK> Add a - to ruby install.rb clean so it's non-fatal.
[02:41] <StevenK> "-ruby install.rb clean"
[02:47] <thierry> yeah but where?
[02:48] <StevenK> debian/rules
[02:48] <thierry> ho ok sorry
[02:49] <thierry> I get this dh_testdir
[02:49] <thierry> # Add here commands to compile the package.
[02:49] <thierry> ruby install.rb setup
[02:49] <thierry> install.rb config first
[02:49] <thierry> Try 'ruby install.rb --help' for detailed usage.
[02:49] <thierry> make: *** [build-stamp]  Error 1
[02:49] <thierry> debuild: fatal error at line 765:
[02:49] <thierry> dpkg-buildpackage failed!
[02:49] <thierry> ho ok I see why, forget this
[04:05] <JohnnyMast> good afternoon
[04:06] <JohnnyMast> is the maintainer of kdetv here ?
[04:57] <Riddell> JohnnyMast: hi
[04:57] <JohnnyMast> Riddell hi
[04:57] <Riddell> not sure who that is but it's a KDE package so it's probably my fault
[04:58] <JohnnyMast> well i just wanted to ask one question
[04:58] <JohnnyMast> i have the same setup in configureing and makefiles
[04:59] <JohnnyMast> and they where also created with kdevelop but it install in /usr/local/bin
[04:59] <JohnnyMast> and thats bad when developing a ubuntu package so im wondering what kdetv does
[05:04] <Riddell> JohnnyMast: --prefix=/usr  for ./configure
[05:05] <JohnnyMast> well thats not it ... and yes i know that hack
[05:05] <Riddell> it's not a h
[05:05] <Riddell> it's not a hack, it's how all
[05:05] <JohnnyMast> but thats not supposed to be needed
[05:05] <Riddell> automake programs work
[05:06] <Riddell> JohnnyMast: the kdetv package uses cdbs which will specify the --prefix for ./configure
[05:07] <azeem> JohnnyMast: it is needed because programs usually default to /usr/local for prefix
[05:07] <azeem> which is fine for locally compiled and installed softwre
[05:07] <JohnnyMast> azeem yes for native packages
[05:07] <JohnnyMast> but not for OS software
[05:07] <JohnnyMast> installed via .deb packages
[05:08] <azeem> right, that's why we do --prefix=/usr
[05:08] <azeem> it's not a hack, it is how it is supposed to be
[05:09] <JohnnyMast> i was just wondering the if maintainer took (ubuntu maintainer) care of that else he/she had to use --prefix=/usr
[05:14] <Riddell> --prefix=/usr --sysconfdir=/etc --localstatedir=/var
[05:14] <Riddell> or maybe --sysconfdir=/etc/kde3
[05:14] <Riddell>  --with-qt-dir=/usr/share/qt3 --disable-rpath --with-xinerama
[05:15] <JohnnyMast> Riddell its good to know you know your stuff. Makes reviewing a heck of a lot easyer
[05:28] <JohnnyMast> some one fixing gnomemeeting already if not leave it to me
[05:32] <ogra> you fix main packages ?
[05:33] <JohnnyMast> ow its main ?
[05:53] <siretart>  (I'm speaking of packages which don't exist in Debian yet).
[05:53] <siretart> sry. didn't want to paste
[06:06] <buxy> siretart: hehe, I've seen that you've read my mail then :)
[06:06] <siretart> buxy: sorry? which mail?
[06:07] <buxy> siretart: the one that you pasted
[06:07] <siretart> buxy: aah, that mail. of course :)
[06:07] <siretart> ah, so you are raphael, nice to meet you :)
[06:07] <buxy> siretart: nice to meet you too :)
[06:07] <siretart> buxy: that email is very interesting and promising stuff. I'm currently thinging how to get the most of it. for both debian and ubuntu
[06:09] <buxy> siretart: Yeah, I would love to be able to set a "nice precedent" of successfull collaboration between Ubuntu and Debian :)
[06:10] <siretart> buxy: that would be really really great.
[06:10] <siretart> I'm still thinking about a few details
[06:10] <thierry> whats means : old-fsf-address-in-copyright-file ?
[06:11] <ogra> thierry, what it says ...
[06:11] <thierry> what's an old-fsf-adress ?
[06:11] <buxy> siretart: just tell me what you're thinking...
[06:11] <ogra> f-s-f == free software foundation
[06:11] <buxy> thierry: use "lintian-info" to have more verbose information about the message
[06:11] <ogra> thierry, they moved ...
[06:12] <buxy> ogra: that's the right answer, explaining people how to learn themselves :)
[06:12] <siretart> buxy: if I understand you correctly, then you want to have something like REVU, but what is also a frontend to a more or less public svn archive, yes?
[06:12] <siretart> buxy: and I'm currently think if and how this could be implementable
[06:12] <ogra> buxy, true ... but some background knowledge might help as well :)
[06:13] <buxy> siretart: yes, a public svn repo, where the mentors can directly work on their packages
[06:13] <buxy> ogra: of course
[06:13] <siretart> buxy: do you think we can place that on alioth? or shall we use another server for that?
[06:13] <buxy> and where the reviewers can see the history and the evolution of the package in the hands of the "applicant"
[06:14] <ogra> siretart, hmm, doenst the launchpad supermirror offer that anyway
[06:14] <buxy> siretart: I'm an alioth admin, so yes we can use alioth if needed
[06:14] <ogra> so you'd only need a branch script that puts it on alioth
[06:15] <buxy> ogra: any pointer to that "supermirror" thingy ?
[06:15] <ogra> no idea, we were shown it live at ubz, i dont know where the specs for it are
[06:15] <siretart> buxy: the 'supermirror' is a service provided by canonical, which imports public cvs and svn repositories to bzr archives
[06:16] <ogra> in general its a huge centralized bzr archive of the whole world on launchpad
[06:16] <siretart> buxy: you know, I designed REVU so that newbees can see how uploading with dput works.
[06:17] <siretart> but I see what you try to acheive with svn, so thats promising
[06:17] <siretart> buxy: have you thought about hacking up something based on trac?
[06:17] <buxy> siretart: we can still have an associated "binary repositorie" so that people can upload those with dput ... and test their tool
[06:18] <siretart> buxy: revu does only accept sourceful only uploads, just like the ubuntu archive
[06:18] <siretart> binary uploads are ignored
[06:18] <ogra> but with elma we'll also have binarys there ...
[06:18] <ogra> so debian could grab them
[06:18] <siretart> we rather want buildlogs than binaries
[06:19] <buxy> siretart: we can have a two-way working: either work directly in svn, or work at home and upload with dput and then a script injects it into svn
[06:19] <siretart> and debian would want to have them rebuild by a 'trusted' DD anyway
[06:19] <ogra> yes, but its a side effect, we wont need but we could keep them for debian
[06:19] <buxy> ogra: elma ?
[06:19] <ogra> s/need/need them/
[06:19] <siretart> buxy: thats sounds promising. so nobody is actually forced to use svn
[06:19] <ogra> buxy, elmo automated ;)
[06:20] <ogra> buxy, our automatic buildd admin for revu2
[06:20] <siretart> buxy: elma is a bad joke about a script, which we want to use for the next version of revu. It will build uploaded packages and attach the buildlog to the detail page
[06:20] <buxy> ok nice
[06:21] <ogra> siretart, i oppse the bad in the above sentence .... its a tribute ;)
[06:21] <ogra> *oppose
[06:21] <ogra> or a praise :)
[06:22] <siretart> ogra: you're right :)
[06:24] <siretart> buxy: well, my current project and plan is to get this one implemented: https://wiki.ubuntu.com/REVU2Spec
[06:25] <siretart> buxy: and I think having an svn under the hood should be achievable
[06:26] <buxy> Yes I've seen your spec already
[06:26] <buxy> it's quite good
[06:26] <siretart> buxy: the current plan is to use launchpad for authentication, though. I'm pretty sure that many DDs will object in using launchpad
[06:27] <buxy> Right, I wanted to mention that ... if you could factorize that part of the code in a easily replaceable module, that would be cool
[06:27] <siretart> but hacking around the authentication part shouldn't be that hard. revu2 is already quite modular (thanks to sistpoty!)
[06:28] <siretart> buxy: only one class would have to be rewritten, not that much of trouble
[06:29] <buxy> How do you handle all the stuff requiring root rights ?
[06:29] <buxy> I mean recompiling a package is not a trivial task ...
[06:30] <siretart> buxy: sudo
[06:30] <buxy> in particular since the package cannot be really trusted.
[06:30] <siretart> buxy: we won't do anything which needs root rights automatic
[06:31] <siretart> buxy: rebuilds are semi automatic, so a human needs to do a first check first. then he is able to request a build
[06:33] <buxy> siretart: do you plan to generate a history associated to an applicant ?
[06:34] <buxy> I mean so that you can easily review the evolution of someone when you must decide if he deserves to be MOTU/DD ?
[06:34] <siretart> buxy: there will be an overview page listing all sourcepackages he contributed
[06:34] <siretart> based on the information in the database
[06:36] <buxy> in that part it would be nice to be able to come back to "svn commits" they made, or come back to changelog of uploads they made
[06:37] <buxy> as well as comments of reviewers associated to those "uploads"
[06:38] <ogra> but we look into -changes anyway if we review someones application for MOTUship at the TB
[06:39] <siretart> buxy: ah, I see what you mean
[06:39] <ogra> there is no detailed review of someones single packages
[06:39] <ogra> that would cost to much time ...
[06:40] <ogra> usually the persons who worked with him get asked to give an opinion on his collaboration and packaging skills
[06:40] <buxy> ogra: keep in mind that Debian has different opinion on what needs to be reviewed before accepting someone for DD
[06:40] <ogra> i know
[06:40] <buxy> ogra: in Debian also we ask the opinion of the sponsor
[06:41] <ogra> as we do ...
[06:41] <buxy> but if we can handle the complicated case, you can still decide based on what you want :)
[06:41] <ogra> but note that we dont have a single sponsor for a MOTU hopeful
[06:41] <siretart> buxy: well, the expected workflow of an applicant is, that he mainly tries to get 'his' packages into shape. so for completely new packages, I didn't notice any 'group maintenance' in the past
[06:41] <ogra> only group reviews ...
[06:42] <buxy> siretart: I see more and more projects on alioth to start packaging new apps in team mode (from the beginning)
[06:42] <siretart> buxy: so the workflow described in the Revu Spec is based on what we have seen while running revu1
[06:42] <buxy> siretart: I understand that, that's why I started this discussion now,
[06:42] <siretart> buxy: which is a good thing, I think
[06:43] <buxy> so that we can see bit further and create something usefule for more people and which will last longer
[06:43] <siretart> buxy: yes, I think get what you want.
[06:45] <siretart> buxy: summary: this 'group maintenance' workflow what you propose is imo very promising, but it doesn't fit 100% in the workflow process which we desinged for revu
[06:45] <ogra> or into the MOTU process ...
[06:45] <siretart> I think I should think a bit more about how 'group maintenance' could be clarified, and write some lines about that
[06:46] <ogra> even if we have teams, the teams still dont *own* any packages in ubuntu
[06:47] <siretart> I think what buxy actually wants is to 'track' 'contributions'
[06:47] <siretart> which we actually want too
[06:47] <siretart> but a 'contribution' in the model of 'group maintenance' is a bit more fine granular
[06:47] <ogra> that enables us to keep a low entry threshold for MOTU hopefuls, most stuff you learn, you learn by doing, and the non personalized package approach we have allows you to make mistakes, since someone else can quickly pick your broken package and fix it without begging for NMU rights ...
[06:48] <siretart> buxy proposes to identify 'contribtutions' with svn commits
[06:48] <ogra> its fine as long as we dont overcomplicate the entry process for new MOTUS ...
[06:49] <siretart> ogra: I think for us MOTUs we will stick with revu, and work on revu2. what buxy proposes is way more far reaching
[06:49] <ogra> yup
[06:49] <siretart> but I'm definitly interested in helping with implementing it!
[06:50] <buxy> ogra: I have the same goal for Debian, I want external people join and help us even without being DD
[06:50] <buxy> so that they can learn by doing
[06:50] <ogra> what buxy proposes sounds very fine for the debian model, it will improve a lot ...
[06:51] <buxy> but I need transparency on what they do so that we can better judge people, better train them and so that the work of reviewers is simplifed
[06:51] <ogra> buxy, but isnt that what mentors was supposed to do once ?
[06:51] <buxy> ogra: mentors.debian.net ?
[06:51] <siretart> buxy: besides, do you need to be a DD to create an alioth project or can anyone apply for one?
[06:51] <buxy> siretart: anyone can apply
[06:51] <siretart> nice. good to know
[06:52] <ogra> buxy, yup
[06:52] <ogra> at least thats how i understood it ...
[06:52] <buxy> but an alioth project is only approved if it's related to Debian in one way or another
[06:52] <siretart> sure
[06:52] <buxy> ogra: sure, but what they did is not enough yet, and they were in CC of my mail, I want them to help us too ! :)
[06:53] <buxy> siretart: wiki.debian.org/Alioth and AliothFAQ if you want to learn more about alioth
[06:53] <ogra> oh, i didnt look at the recipient list, right :)
[06:58] <buxy> ogra: BTW collaborative maintenance doesn't mean "maintained by a formalized list of people"
[06:59] <buxy> my proposal will help bring decentralized management of packages into Debian
[06:59] <ogra> buxy, but the "group maintenance" attempt put together with debians way of having personalized packages sounds like it
[07:00] <ogra> its hard to imagine (at least for some DDs i can think of) that you will be able to change the world :) but my best wishes are with you indeed
[07:01] <buxy> ogra: whatever you think, I'm changing the way Debian works ...
[07:01] <buxy> :-)
[07:01] <siretart> :)
[07:01] <buxy> it takes time but it's possible
[07:02] <ogra> crossing my fingers for you, it would rock if it worked :)
[07:02] <siretart> buxy: if you want truely distributed management of packages, then I'm not sure if svn fits your model
[07:02] <buxy> if you check what I said in 2002 when I tried to get Debian Leader ... I announced most of the work that I did in the last 3 years and this work
[07:02] <buxy> lead to more packages being now "group maintained" when there was none in 2002
[07:03] <buxy> siretart: I've heard lots of good things about svk
[07:03] <ogra> i think i read your papers back then :)
[07:03] <siretart> buxy: good point.
[07:03] <buxy> siretart: and frankly I'm not interested in a discussion about VCS
[07:04] <buxy> I'm maintaining alioth and we offer SVN/baz/bzr/tla repo for maintenances
[07:04] <siretart> right
[07:04] <buxy> and SVN is *way* more popular (at least in the Debian world)
[07:04] <siretart> I just noticed that you used 'svn commits' in the discussion above
[07:04] <siretart> and svn-buildpackage is imo the best of the *-buildpackages around
[07:06] <buxy> I don't if it's the best, but it exists
[07:06] <buxy> and it works and many people already use it
[07:08] <buxy> if I want to make Debian evolve, I have to follow the natural path of Debian ... if 70% of Debian uses SVN, I have to use SVN to have a good chance that poeple will use the new infrastructure
[07:11] <siretart> right
[07:12] <siretart> and after all, svn isn't that bad at all. in fact, I like it :)
[07:12] <shawarma> Have any of you tried the new Gaim?
[07:13] <shawarma> I'm assuming you've noticed the 2.0.0beta1 release. :-)
[07:16] <greenpenguin13> bug 21126...
[07:16] <Ubugtu> Error: Error getting Malone bug #21126: Bug does not exist
[07:16] <ogra> meh, still no gobby 0.3.X
[07:24] <Hieronymus> Can someone please review http://revu.tauware.de/details.py?upid=1232 (bulldozer package)?
[08:11] <JohnnyMast> does any one know a vlc tweak to broadcast your cam OUTside my lan ?? .... for now the httpd that vlc creates only works inside the lan
[08:37] <ajmitch> morning
[08:37] <LaserJock> morning ajmitch
[08:41] <LaserJock> ajmitch: up for a quick REVU review? I just need one more advocate for plotdrop and I am leaving town for a couple of weeks so I would like to get if done today or tomorrow.
[08:42] <ajmitch> not right now sorry
[08:42] <ajmitch> maybe later today
[08:42] <LaserJock> ok, that's fine
[08:43] <tseng> link please
[08:43] <LaserJock> http://revu.tauware.de/details.py?upid=1235
[08:47] <tseng> LaserJock: done.
[08:48] <LaserJock> tseng: thanks so much
[08:48] <tseng> nps
[08:51] <Hieronymus> Will someone review my bulldozer package, please?
[08:51] <Hieronymus> http://revu.tauware.de/details.py?upid=1232
[08:52] <ajmitch> tseng: plotdrop will ftbfs
[08:53] <ajmitch> and a quick look at the makefile shows that it might screw up the chroot it's built in
[08:53] <tseng> ajmitch: go me, i didnt build it
[08:53] <ajmitch> (ftbfs due to gtk+ breakage)
[08:53] <ajmitch> unless seb fixed that
[08:53] <tseng> what part am i looking at?
[08:53] <ajmitch> I just built it on tiber quickly
[08:53] <tseng> in the source itself?
[08:53] <LaserJock> ajmitch: what?
[08:54] <tseng> i only reviewed the diff, i am lazy
[08:54] <ajmitch> LaserJock: does your makefile respect DESTDIR after it's been patched?
[08:54] <ajmitch> because +$(MAKE) PREFIX="/usr"
[08:55] <ajmitch> that part is ok
[08:55] <ajmitch> but abusing PREFIX later on..
[08:56] <ajmitch> anyway, I'm late for work
[08:56] <LaserJock> ajmitch: where?
[08:57] <LaserJock> oh, in install?
[08:59] <LaserJock> all I know is it builds fine in my pbuilder. I do patch the Makefile (maybe I am not doing it right though).
[09:26] <ajmitch> sigh, I hate having to go to work & use windows
[09:26] <Kyral> lol
[09:26] <Kyral> I know the feels
[09:26] <Kyral> feeling even
[09:27] <Kyral> I had to help my uncle print his boarding pass
[09:27] <Kyral> the only computer I had access to had WinMe + AOL Dialup
[09:27] <ajmitch> & my wrist seems to be getting a little stuffed from using the mouse here
[09:27] <Treenaks> ajmitch: that's _possible_ ?!
[09:28] <ajmitch> Treenaks: not only is it possible
[09:28] <ajmitch> but I'm going to do it in a few days
[09:28] <Treenaks> omg!
[09:29] <ajmitch> yes, very funny
[09:38] <hub> can someone review http://revu.tauware.de/details.py?upid=1238
[09:38] <Mirno> omg!
[09:38] <hub> now that if build from source
[09:39] <Mirno> Kyral: Hi
[09:39] <hub> (it broke because of bad code + gcc being stricter)
[09:39] <Kyral> hello Mirno
[09:40] <Mirno> hello Kyral
[09:41] <Mirno> is icc free of charge ?
[09:42] <Kyral> ICC?
[09:42] <Mirno> Intel C Compiler
[09:42] <Kyral> Intel has their own C Compiler?
[09:42] <siretart> yeah
[09:42] <siretart> it optimizes great
[09:43] <ajmitch> for anything but an amd chip ;)
[09:43] <Mirno> Kyral: yes it's a much bette roptimizer than gcc
[09:43] <ajmitch> hi siretart
[09:43] <Kyral> I dunno I just use GCC
[09:43] <siretart> huhu ajmitch
[09:43] <Mirno> Kyral: me too
[09:43] <Mirno> Kyral: I was considering to try icc
[09:43] <hub> Mirno: if only Intel could provide this to gcc
[09:43] <hub> ....
[09:43] <Mirno> hub: yes if only ... :=)
[09:44] <Mirno> hub: do you know if it's free of charge ?
[09:44] <hub> Mirno: I know it is not free softw3
[09:44] <hub> software
[09:44] <Mirno> hub: yes that i know
[09:44] <hub> so for the rest I'm not caring at all
[09:45] <Mirno> but do they cherge forit ?
[09:45] <Mirno> ok hub
[09:45] <siretart> Mirno: for noncommercial/private use its free. not sure for educational purposes but I think too
[09:46] <Mirno> siretart: ok, thank you very much :)
[09:46] <Mirno> siretart: (hi BTW)
[09:46] <siretart> huhu Mirno
[09:47] <siretart> Mirno: ah, good that I catch you ;)
[09:47] <siretart> Mirno: have you already seen http://debian-unofficial.org?
[09:48] <Mirno> siretart: no
[09:50] <Mirno> One unofficial repository to rule them all.
[09:50] <Mirno> huhu
[09:50] <siretart> Mirno: I'm currently in contact with him. what he does is in my opinion quite similar to plf, I think
[09:51] <Mirno> siretart: yes
[09:51] <Mirno> siretart: but he does it for debian
[09:51] <Mirno> siretart: :)
[09:51] <siretart> Mirno: well, he is a DD
[09:51] <siretart> (well, not yet, he is in NM, but anyway)
[09:52] <siretart> Mirno: he wouldn't object much in having a http://ubuntu-unofficial.org
[09:52] <Mirno> siretart: DD as in Dolby Digital ? :)
[09:52] <siretart> Mirno: DD as in debian developer
[09:52] <Mirno> siretart: so ?
[09:53] <siretart> Mirno: I thought you might be interested in knowing
[09:55] <Mirno> siretart: well I don't understand why we should take this domaine name and why should we ask him for it ?
[09:56] <siretart> Mirno: no, I don't mind about the domain name
[09:56] <siretart> Mirno: I rather mind about the repository's package policy and the packages he actually has
[09:58] <Mirno> siretart: he is willing to port them ?
[10:01] <siretart> Mirno: AFAIK he accepts buildds
[10:01] <Mirno> siretart: what is "AFAIK" ? :)
[10:01] <siretart> as far as I know
[10:01] <siretart> or better, I think
[10:01] <Mirno> siretart: and what is "builds" ?
[10:02] <Mirno> siretart: you mean binary deb ?
[10:02] <siretart> Mirno: a build daemon is a machine autobuilding packages
[10:03] <Mirno> siretart: you propose I provide a ubuntu machine so he can build his packages for ubuntu ?
[10:03] <Mirno> s/propose/suggest/
[10:04] <siretart> I currently dont suggest anything
[10:04] <siretart> I'm considering how we can collaborate with him
[10:04] <Mirno> siretart: I don't understand what you have in minde :)
[10:05] <siretart> Mirno: currently I'm at the stage in thinking how to compare his repository with what we already have in multiverse
[10:05] <siretart> Mirno: and then look whats left. what we can include in multiverse, and what would have to go to some other repository
[10:06] <Mirno> siretart: ok
[10:06] <siretart> Mirno: please don't misunderstand me, but for my taste, the plf acceptance policy is far too lax. thats why I cannot recommend using them with clean concience.
[10:07] <Mirno> siretart: as you wish :)
[10:19] <siretart> Mirno: http://tiber.tauware.de/~siretart/unofficial/not-in-ubuntu thats the list of packages in debian-unofficial but not in multiverse
[10:19] <Mirno> siretart: ok
[10:19] <Mirno> thx
[10:19] <siretart> so I need to go through the list and comment about their status
[10:20] <siretart> Mirno: for libdvdcss, he has no problems with hosting it, because he says it was legal in CH *shrug*
[10:20] <siretart> for java, it is a bit more complicated, because sun makes YOU responsible when you are redistributing it
[10:21] <siretart> for skype, he told me it was no problem. you just have to report that to skype and update it everytime they release a new version
[10:22] <siretart> so we cannot have skype in ubuntu, because we cannot update in past releases
[10:23] <Amaranth> updates and/or backports?
[10:24] <ajmitch> siretart: interesting, what did you use to get that list?
[10:25] <siretart> ajmitch: I downloaded the 'Sources' files, concatenated them, extracted the source package name with grep-dctrl
[10:25] <ajmitch> siretart: just grep packages files?
[10:25] <ajmitch> ah, using source package namesd
[10:25] <siretart> ajmitch: did some sort magic, then diffed it and edited the '-' away with vim
[10:25] <ajmitch> nice
[10:25] <siretart> the manual foo and magic
[10:25] <siretart> ;)
[10:25] <ajmitch> yep
[10:26] <hub> siretart: dvdcss is legal in a lot of countries :-)
[10:26] <ajmitch> much better than nasty hackish scripts like mine
[10:26] <siretart> hub: interesting
[10:26] <Kyral> But because the US Government is run by the RIAA...
[10:26] <ajmitch> hub: but mirrors would end up carrying it & we can't push it to there
[10:26] <siretart> ajmitch: well, I assume your hackish scripts are non-interactive
[10:26] <hub> ajmitch: I get the point :-)
[10:26] <hub> I was just saying
[10:26] <ajmitch> siretart: of course
[10:26] <ajmitch> siretart: and now sistpoty is using them to update the merge lists
[10:26] <siretart> cool!
[10:27] <siretart> perhaps I should put the list on the ubuntu wiki
[10:27] <siretart> for public commenting them
[10:27] <Kyral> what are these?
[10:28] <ajmitch> siretart: we'll do a similar interface for unmet deps later as we do for merges now
[10:28] <hub> can someone advocate this http://revu.tauware.de/details.py?upid=873
[10:28] <ajmitch> siretart: if we had enough RAM I'd like to use britney on tiber
[10:28] <hub> and this http://revu.tauware.de/details.py?upid=1238
[10:28] <ajmitch> but apparantly it really loves the memory
[10:29] <ajmitch> maybe ask kamion about getting the scripts
[10:30] <siretart> ajmitch: how much ram does she need?
[10:30] <ajmitch> well we only need to do an installability test
[10:30] <siretart> I never used britney
[10:30] <ajmitch> but imagine holding the whole dependency tree in memory
[10:31] <ajmitch> and resolving all the virtual depends, conflicts, etc
[10:31] <siretart> but running them on universe would be really interesting
[10:31] <siretart> ajmitch: perhaps you could place a ready to run example on tiber, so I can run her on my machine?
[10:31] <ajmitch> which is why I didn't continue writing my pure python version
[10:31] <ajmitch> siretart: I grabbed the source on tiber
[10:32] <ajmitch> but it requires python-apt, and some other packages
[10:33] <ajmitch> sorry,  libapt-pkg-dev
[10:33] <siretart> ajmitch: thanks
[10:33] <siretart> how to use/configure her?
[10:33] <ajmitch> no idea
[10:33] <ajmitch> well I have an idea
[10:33] <ajmitch> but it's not well documented
[10:34] <siretart> ah, exactly my problem :)
[10:34] <ajmitch> as like any of the 'evolved' debian scripts ;)
[10:34] <ajmitch> which have just grown in place on debian
[10:36] <siretart> and she doesn't like amd64 :/
[10:36] <lfittl> Does anybody know why the i386 buildd gives back some packages lately? (http://people.ubuntu.com/~lamont/buildLogs/m/mdf2iso/0.3.0-0ubuntu1/)
[10:36] <JohnnyMast> siretart do you have some time to review 2 packages ?
[10:37] <siretart> sorry, I'm too tired now :(
[10:37] <seth_k|lappy> anyone want to review a merge for a KDE package, noteedit? Should be quite quick; very small debdiff
[10:37] <JohnnyMast> any one else ? that i could tackle for a revu ?
[10:41] <seth_k|lappy> lfittl, i386 buildd is messed up, it'll be fixed
[10:42] <lfittl> seth_k|lappy: k, thanks for the information :)
[10:49] <greenpenguin13> bug #21126 is fixed but still listed on bugzilla
[10:49] <Ubugtu> Error: Error getting Malone bug #21126: Bug does not exist
[10:53] <siretart> seth_k|lappy: which bugno?
[10:57] <ajmitch> JohnnyMast: I'll review kryptor later, but my first impression is that the diff is too big (generated files), and you've got numerous spelling errors, some of which really do matter (eg in debian/rules)
[10:58] <JohnnyMast> ajmitch alright im looking forward to it
[10:59] <ajmitch> JohnnyMast: and you don't need libx11-dev & libx11-6 in build-depends
[10:59] <JohnnyMast> ajmitch toucht that already
[10:59] <ajmitch> build-depending the library as well as the headers is unnecessary, and kdelibs4-dev pulls it in anyway
[11:15] <LaserJock> ajmitch: do you still have problems with my plotdrop packaging?
[11:17] <Kyral> anyone know what "warning: assignment discards qualifiers from pointer target type" means?
[11:18] <Mithrandir> Kyral: you have something like void foo(const char *bar) {char *baz = bar } in your code.
[11:19] <Mithrandir> (hence discarding "const" in the example)
[11:19] <ajmitch> LaserJock: dunno, I haven't tried building it or testing, etc
[11:19] <lifeless> does motus take care of multiverse too ?
[11:19] <ajmitch> LaserJock: and I see nothing new on REVU
[11:19] <ajmitch> lifeless: yep
[11:19] <Kyral> Mithrandir: its an assignment statement
[11:20] <LaserJock> ajmitch: you said earlier that it was FTBS
[11:21] <Kyral>  s = gtk_entry_get_text (GTK_ENTRY (entry_gs));
[11:22] <ajmitch> LaserJock: yes, mainly because libgtk2.0-dev might be missing some xdmcp dependency
[11:22] <ajmitch> or the pbuilder needs updated
[11:22] <Kyral> I don't see anyting wrong with the assignment
[11:22] <Kyral> then again I don't know what gtk_entry_get_text returns
[11:22] <LaserJock> ajmitch: it worked for me fine
[11:23] <Kyral> Okay...can someone who knows the GTK Libs look over this?
[11:26] <ajmitch> LaserJock: ok it built
[11:26] <Kyral> could someone who knows the GTK Libs look at http://revu.tauware.de/revu1-incoming/easychem-0512141655/easychem-0.6/dialogs.c lines 963 and tell me whats wrong there?
[11:27] <LaserJock> ajmitch: what about my use of PREFIX in the install rule in debian/rules. Is that not ok?
[11:27] <ajmitch> not really
[11:27] <buxy> ajmitch & sirestart: britney has an author however, and he still lives, so you can contact him (even on IRC)
[11:27] <ajmitch> it works
[11:28] <ajmitch> buxy: I know that..
[11:28] <desrt> Kyral; wrt. the comment?
[11:28] <Kyral> desrt: no the assignment near it
[11:28] <Kyral> s = whatever
[11:28] <desrt> looks fine to me.
[11:29] <Kyral> hmm, GCC is spittng out a warning
[11:29] <desrt> oh
[11:29] <desrt> s should be const char *
[11:29] <desrt> not char *
[11:29] <ajmitch> buxy: funnily enough I had even thought of asking someone about it, once I had looked at it a bit
[11:29] <Kyral> desrt: so in the declaration I should chanage it to const * gchar?
[11:29] <desrt> Kyral; yes
[11:30] <desrt> 'assignment discards qualifiers from pointer target type' ?
[11:30] <desrt> or some such?
[11:30] <Kyral> ah
[11:30] <Kyral> but what...if I change it to declare const
[11:30] <Kyral> then the = wouldn't work...
[11:31] <desrt> const char *s; means that the char that s points to is const
[11:31] <desrt> not s itself
[11:31] <desrt> that would be char * const s;
[11:31] <Kyral> so the = would be right?
[11:31] <desrt> yes.  assigning to a pointer of type (const char *) is fine.
[11:31] <ajmitch> Kyral: you're spending a lot of effort on this warning
[11:31] <Kyral> ajmitch: I wanna fix it :D
[11:32] <Kyral> so it will be accepted into Universe LD
[11:32] <Kyral> You called it to my attention so :D
[11:32] <desrt> what package is this?
[11:32] <Kyral> EasyChem
[11:32] <desrt> oh.  you're not talking to me :)
[11:33] <Kyral> builds fine, but ajmitch noted that the warning could be bad on AMD64
[11:33] <ajmitch> Kyral: it won't be
[11:33] <desrt> Kyral; it's a trivial warning in this case
[11:33] <ajmitch> I didn't really look at what the warning was
[11:33] <Kyral> ajmitch: then can you advocate so I can forget this thing for a while
[11:33] <desrt> Kyral; read the gettext() manpage for example
[11:33] <desrt> from gettext:
[11:33] <desrt> BUGS
[11:33] <desrt>        The  return type ought to be const char *, but is char * to avoid warn
[11:33] <desrt>        ings in C code predating ANSI C.
[11:34] <Mithrandir> Kyral: const vs non-const is just as harmful on i386 as on amd64.
[11:34] <desrt> gettext actively does exactly what that warning is warning you about :)
[11:34] <Kyral> someone just get me one more vote lol
[11:34] <desrt> (ie: using a 'char *' to store a const char pointer)
[11:35] <desrt> did keyboardcast get accepted yet?
[11:35] <desrt> crikey.  no.
[11:35] <desrt> advocate #1120, people :p
[11:37] <LaserJock> ajmitch: if you don't mind, could you briefly explain why my use of PREFIX was wrong? Do I need to modify the Makefile more?
[11:37] <Kyral> yah someone just please advocate EasyChem