[01:23] <wgrant> qastaging takes forever to update :(
[01:35] <thumper> poo
[01:53] <wgrant> added: lib/lp/archivepublisher/tests/util.py.THIS
[01:53] <wgrant> thumper: ^^
[01:54] <thumper> eh?
[01:54] <thumper> arse
[01:54] <thumper> did that slip through?
[01:54] <wgrant> Yes.
[01:54] <thumper> poo
[01:54] <wgrant> Just landed a couple of minutes ago.
[01:54] <thumper> another pp
[01:54]  * thumper fixorates
[01:54] <thumper> wgrant: is it breaking things?
[01:54] <thumper> it passed ec2
[01:55] <wgrant> thumper: It shouldn't break anything, no.
[02:01] <thumper> pqm-sumitting the fix
[02:01] <wgrant> Thanks,
[02:21]  * wgrant lunches.
[03:51] <wgrant> Has anyone looked at the db-devel failure?
[03:52] <lifeless> the real question is, has the failure looked at anyone?
[03:52] <wgrant> Ah, it's already running again.
[03:52] <wgrant> Yay buildbot.
[04:49] <wgrant> lifeless: How do we fix a stale librarian PID issue on buildbot? Get a GSA to remove the file manually?
[05:00] <lifeless> yes, checking that:
[05:00] <lifeless>  - the librarian is not still running
[05:00] <lifeless>  - *how* it happened - was the machine rebooted? did the librarian crash? was the test killed (and if so with what signal)
[05:01] <lifeless> basically gather data so we can permanently fix
[05:01] <wgrant> There was a test explosion in the last run.
[05:02] <wgrant> zope.testrunner does not seem to rate very highly in the not sucking department.
[05:02] <lifeless> go on, be more accurate ;)
[05:06] <lifeless> wgrant: please make sure there is a bug on lp, high pri explaining what you figured out
[05:06] <lifeless> wgrant: test explosions should always tear down
[05:06] <lifeless> etc
[05:07] <wgrant> lifeless: But Twisted tests dying with KeyboardInterrupt make me cry.
[05:23] <wgrant> stub: Morning.
[05:23] <stub> yo
[05:23] <wgrant> stub: Can I please have you db-blessing for https://code.launchpad.net/~wgrant/launchpad/die-lucilleconfig-die/+merge/44305?
[05:27] <stub> In the name of the Senate and Peoples of Rome
[05:28] <wgrant> stub: Do I also need a TA-blessing?
[05:32] <stub> Not before landing, no. Request 2 db reviews from me and lifeless. Land after you have the number and one approval.
[05:33] <wgrant> I thought thinks might be different at the moment, given the lack of TA.
[05:33] <wgrant> things.
[05:33] <wgrant> Thanks.
[05:33] <stub> I've put in the second review request
[05:33] <stub> The two reviews thing is so we can both keep on top of things, but not block devs.
[05:33] <stub> Holidays etc.
[05:33] <wgrant> Right.
[06:44] <poolie> hi
[06:44] <poolie> stub, would you be kind enough to sponsor landing of https://code.launchpad.net/~mbp/launchpad/314507-oauth/+merge/44188 for me?
[06:44] <poolie> iow to send it to pqm
[06:45] <stub> poolie: Has it gone through ec2 test yet?
[06:45] <poolie> no
[06:45] <poolie> i guess to send it to pqm via ec2
[06:45] <stub> Ok. Doing that now.
[06:46] <poolie> thanks
[07:01] <stub> Bug #692872
[07:01] <_mup_> Bug #692872: Test suite fails if previous run did not tear down Librarian fully. <Launchpad itself:New> < https://launchpad.net/bugs/692872 >
[07:03] <wgrant> lifeless: Oh?
[07:03] <lifeless> wgrant: did you end up landing my librarianfixture branch ?
[07:03] <wgrant> lifeless: No.
[07:03] <wgrant> I was told that adeuring was working on that.
[07:03] <wgrant> But that was nearly two weeks ago.
[07:04] <lifeless> right
[07:04] <lifeless> well it needs landing
[07:04] <lifeless> the cure is worse than the disease
[07:04] <lifeless> we need to stop doing expendient things and actually make the foundations sane and reliable
[07:05] <wgrant> Sure.
[07:05] <wgrant> I'll take a look at that tomorrow.
[07:05] <wgrant> Once I work out how I am going to get this regression fix deployed.
[07:05] <lifeless> qa the intermediate patches
[07:06] <wgrant> Difficult.
[07:06] <lifeless> qa isn't restricted to the author
[07:06] <wgrant> I need r12112, but r12102 is bad.
[07:06] <wgrant> It is needed on cesium, which r12102 does not affect.
[07:06] <wgrant> So I need manual approval.
[07:06] <wgrant> But the relevant team lead and project lead are on leave.
[07:06] <lifeless> whats in 12102
[07:07] <wgrant> A webapp formatter change.
[07:07] <lifeless> ok
[07:07] <lifeless> +1
[07:07] <lifeless> the losas should remove cesium from nodowntime
[07:07] <wgrant> lifeless: Thanks!
[07:09] <wgrant> danilos: Should the variants rev I tried to QA last night block a rollout?
[07:09] <wgrant> danilos: Or does it just not fix the bug?
[07:09] <wgrant> It looks qa-ok to me, but I'd like to be sure.
[07:30] <stub> lifeless: Does that branch relateto Bug #692872 ?
[07:30] <_mup_> Bug #692872: Test suite fails if previous run did not tear down Librarian fully. <Launchpad itself:Won't Fix> < https://launchpad.net/bugs/692872 >
[07:30] <lifeless> stub: very much so
[07:33] <stub> Your comments don't say if your branch fixes the issue, or if we want the issue to continue.
[07:33] <lifeless> oh
[07:34] <lifeless> gimme a sec to find it
[07:34] <stub> I just don't want buildbot to fail if a previous run left librarian crud on well known sockets or in well known files.
[07:34] <stub> (which is why we are in testfix atm)
[07:35] <wgrant> (Hudson! Hudson!)
[07:35] <stub> wgrant: Won't hudson have the same problems?
[07:36] <wgrant> stub: It doesn't have the same catastrophic failures, plus it uses Canonicloud and recreates the instances every so often.
[07:37] <lifeless> ok
[07:37] <lifeless> https://code.launchpad.net/~lifeless/launchpad/librarian/+merge/39013
[07:37] <stub> Recreating the instances seems nice - pita buildbot requires manual intervention.
[07:37] <lifeless> stub: it won't have this problem at all
[07:37] <lifeless> because of the new instance thing
[07:37] <lifeless> so that MP ^
[07:37] <stub> lifeless: Cool. So the bug isn't won't fix, it is pending :)
[07:38] <lifeless> well
[07:38] <lifeless> let me reread
[07:38] <lifeless> right
[07:38] <lifeless> the proposed fix is inappropriate
[07:43] <stub> Argh... midair collision
[07:43] <wgrant> Hmmm.
[07:43] <wgrant> Something is broken.
[07:44] <spiv> wgrant: Is that something software?  That always breaks.
[07:44] <stub> 5963 things are broken in LP
[07:44] <spiv> It's a wonder anyone ever bothers to use software, really.
[07:44] <wgrant> https://code.qastaging.launchpad.net/~wgrant/launchpad
[07:44] <wgrant>    - Expression: <PathExpr standard:u'menu/mergequeues/render'>
[07:44] <wgrant> KeyError: 'mergequeues'
[07:44] <wgrant> I don't think that's changed lately :/
[07:45] <stub> lifeless: Anything stopping the librarian branch landing (apart from being in testfix mode because the librarian branch hasn't landed yet)?
[07:45] <lifeless> stub: I'd love it if someone would land it
[07:46] <stub> I'll stuff it through ec2 then
[07:46] <wgrant> It has some test failures.
[07:46] <lifeless> I suspect it will have (some) failures / may need a merge with trunk
[07:46] <wgrant> Or did last time I looked.
[07:46] <wgrant> I don't remember exactly which. Which may indicate that it was catastrophic enough that I was unable to get a complete list.
[07:46] <stub> I'll stuff it through ec2 test to get the list.
[07:47] <wgrant> Not if it explodes :)
[07:49] <stub> That bad huh?
[07:49] <lifeless> its altering fairly fundamental stuff
[07:49] <wgrant> IIRC yes.
[07:49] <wgrant> The testrunner did not end up very happy at all.
[07:50] <stub> Maybe it is a post-lunch job then
[07:53] <wgrant> stub: There shouldn't be anything quite as terrible as the databasefixture branch.
[07:53] <wgrant> Since we now know that everything uses the right config.
[07:53] <lifeless> we're pretty close to being able to truely parallelise
[07:53] <wgrant> Yup.
[07:53] <lifeless> we need to track down the cause of leaks
[07:53] <wgrant> Although I ran into some trouble with launchpadlib tests last night.
[07:53] <lifeless> something is either not calling cleanups, or the process is being killed hard
[07:54] <lifeless> launchpadlib needs to be fixed
[07:54] <lifeless> where is that concurrent use bug
[07:54] <wgrant> It seems to enjoy always connecting to :8085
[07:54] <wgrant> I don't know how that can work, since AppServerLayer is meant to be dynamic now.
[07:54] <wgrant> Oh.
[07:54] <wgrant> I guess we don't do custom ports yet, just custom DBs.
[07:54] <wgrant> And on Natty it decides to connect to :443 instead, just for fun.
[07:55] <lifeless> win
[07:55] <wgrant> So I will probably beat it to death with some monkeypatches.
[07:55] <lifeless> wait what
[07:55] <lifeless> we maintain it
[07:55] <wgrant> Hmm, maybe I can get it to use a custom base URI.
[07:56] <wgrant> lifeless: True.
[07:57] <wgrant> But lazr.restful has at least one 3000-line doctest.
[07:57] <wgrant> Which has sort of put me off that stack a bit.
[07:57] <lifeless> boom shaka
[07:57] <wgrant> Maybe I should try again.
[07:58] <wgrant> Also, Python decided it would be amusing to change the default email header wrapping character from \t to ' '.
[07:58] <wgrant> This breaks a lot of tests :D
[07:59] <lifeless> OTOH the only thing that should be testing serialised forms is emaillib
[08:01] <wgrant> lifeless: That is true, but there are a lot of other 'should' and 'should not's in LP.
[08:01] <lifeless> wgrant: I think I mean 'cast the serialised form to an object, use a matcher, or delete the test
[08:02] <wgrant> eg. you should probably not have a single monolithic 570KLOC Python app that can be logically split into lots of pieces :)
[08:03] <lifeless> wgrant: I hold a rather different view on the 'logical split' thing
[08:03] <lifeless> wgrant: I grant that there are /some/ pieces we can(and should) split out
[08:04] <lifeless> wgrant: but I'm not convinced that there are lots; and certainly the UI->persistence->storage story is all one logical thing
[08:04] <wgrant> At least Translations, Buildmaster and most of Soyuz have no business being in with the rest of LP.
[08:05] <lifeless> no, yes, no
[08:05] <wgrant> The interaction points between those three and the rest are minimal.
[08:05] <wgrant> And will remain so.
[08:06] <lifeless> to me there are two key tests
[08:06] <lifeless> a) could it be written to APIs
[08:07] <lifeless> b) would it be free of lockstep changes with the core
[08:07] <lifeless> if the answers are yes and yes, then I think a separate piece makes sense
[08:07] <lifeless> that isn't the case with translations or soyuz
[08:08] <lifeless> and soyuz is (finally) getting reuse and working in better with code
[08:08] <lifeless> translations ditto
[08:09] <wgrant> I'm not sure that those interactions are significant enough to prevent a split.
[08:10] <lifeless> I think they are massive impediments against splitting
[08:10] <wgrant> They make it harder than it would be otherwise.
[08:10] <lifeless> they are fundamental problems
[08:13] <lifeless> that will massively outweigh any benefits from splitting them out, unless the split edge is designed to prevent those problems occuring
[08:19] <lifeless> the latter problem in particular would mean terrible deployment and testing issues
[08:24] <stub> AttributeError: type object 'BaseLayer' has no attribute 'config'
[08:24] <stub> Think that means I should terminate the run :)
[08:25] <lifeless> thats fallout from wgrants fixes to databasefixture
[08:25] <wgrant> Indeed.
[08:25] <stub> I'll look at it after lunch
[08:26] <lifeless> wgrant: what was teh change
[08:28] <wgrant> lifeless: I was going to tell him, but then he escaped.
[08:28] <wgrant> I renamed config to config_fixture.
[08:28] <wgrant> Or config_name.
[08:28] <wgrant> Because the other one sprung into existence.
[08:29] <wgrant> don't remember which was which.
[08:40] <poolie> lifeless, would you care to offer an opinion on https://code.edge.launchpad.net/~mbp/launchpad/690021-rlimit/+merge/43733
[08:40] <poolie> ie about setting an rlimit in cron scripts
[08:40] <poolie> not an emergency, just feeling a bit stuck
[08:40] <poolie> or anyone else for that matter
[08:41] <lifeless> poolie: uhm
[08:41] <poolie> if you're not here, you don't have to, of course
[08:41] <lifeless> ideally we'd give each task an even slice of the machine memory
[08:41] <lifeless> which implies knowing the machine memory
[08:41] <lifeless> I'd look to features to configure that
[08:41] <lifeless> as for where its set
[08:41] <lifeless> I don't care whether its in-proc or in-parent
[08:41] <poolie> you could do a lot more towards this
[08:42] <poolie> we could have a whole lep on the idea of resource caps on jobs
[08:42] <poolie> istm perhaps you want a model of "this job should never need more than x GB unless something's wrong; this machine has Y GB; run y/x of them in parallel"
[08:43] <poolie> or perhaps for other jobs, you just want to cap them
[08:43] <lifeless> that seems liable to fail with too many jobs for the cpus
[08:43] <poolie> oh, that too of course
[08:43] <poolie> anyhow, ideally it would be an operational knob, not in the code
[08:43] <lifeless> there are mulitple dimensions here
[08:44] <poolie> the thing for this particular mp is
[08:44] <lifeless> one is not using more resources than we have
[08:45] <poolie> istm it is a step improvement to at least have a cap on this job as we have on others
[08:45] <lifeless> another is autoconfiguration
[08:45] <lifeless> poolie: sure
[08:45] <lifeless> poolie: why don't you land it?
[08:45] <poolie> and no worse than having losas manually kill them, as has happened at least once (maybe only once)
[08:46] <poolie> i didn't want to land it over the top of aaron and tim's concerns
[08:47] <lifeless> fair enough
[08:47] <lifeless> anyhow, it seems to me that you'll want to use a mock
[08:47] <lifeless> because setting an rlimit in a test and then butting up against it would be unreliable at best
[08:47] <poolie> but i would like to restrict the scope
[08:47] <poolie> i agree
[08:48] <lifeless> if you're testing with a mock, it really doesn't matter where you set it, does it ?
[08:48] <poolie> a mock of what? a monkeypatched setrlimit?
[08:48] <lifeless> yah
[08:48] <poolie> oh, i mean restrict the scope to smaller than "make a new job system thx"
[09:17] <danilos> wgrant, hi, can you please run the rosetta-approve-imports script on dogfood please? I've made all the variant languages visible to see if that case would at least work
[09:18] <wgrant> danilos: Does it need a fresh upload?
[09:18] <danilos> wgrant, no, we've got plenty of unapproved files left
[09:18] <wgrant> danilos: Running.
[09:19] <wgrant> It's doing stuff.
[09:19] <danilos> wgrant, cool, thanks
[09:19] <danilos> wgrant, it puts stuff in arbitrary order so I can't find it in the queue
[09:20] <wgrant> danilos: Should I knock all the old ones to some other status?
[09:20] <danilos> wgrant, can you please kill the run and clean up all the TIQE entries with status != 5 (needsreview)
[09:20] <danilos> wgrant, or that, if it's not a big bother
[09:20] <danilos> wgrant, I believe status 3 is deleted so try with that :)
[09:20] <wgrant> danilos: That's what I'm doing.
[09:21] <wgrant> 1 -> 3
[09:21] <wgrant> That was quick.
[09:21] <danilos> wgrant, cool, thanks
[09:21] <wgrant> Reapproving.
[09:21] <danilos> cool
[09:24] <danilos> wgrant, looks good so far, but please let it finish
[09:24] <wgrant> Looks good, yeah.
[09:26] <wgrant> danilos: It's finished.
[09:27] <danilos> wgrant, oh, is it perhaps because of a time-limit? can you run it again please?
[09:27] <wgrant> Still lots unapproved.
[09:27] <wgrant> Indeed, ran for a few seconds over 5 minutes.
[09:27] <wgrant> And now is doing lots more.
[09:28] <danilos> wgrant, I've made "sr@ijekavian" hidden to see what will happen with those (if it works properly, they would stay unapproved, if not, they might again be approved in "serbian" directly)
[09:29] <wgrant> danilos: The queue is not getting shorter.
[09:29] <wgrant> It's doing dozens of transactions per second, and not running for more than 30 seconds or so.
[09:30] <danilos> wgrant, right, then it's surprisingly working fine with hidden languages this time around as well
[09:31] <wgrant> danilos: Do we want to do another upload of the same file to another series and try it again from the start?
[09:31] <danilos> wgrant, you can perhaps kill that run and I can make "sr@ijekavian" visible again so we just make sure it works fine to clean up the queue (well, mostly: sometimes not all files have matching templates)
[09:31] <wgrant> Sure.
[09:31] <wgrant> It's finished again.
[09:32] <danilos> wgrant, not really, I am experiencing some weirdness locally as well
[09:32] <wgrant> So unhide.
[09:32] <danilos> wgrant, done
[09:32] <wgrant> I need to learn this Translations stuff.
[09:32] <danilos> wgrant, I want to get down to the local weirdness first, and then when I am certain why is it happening we can try it all over again :)
[09:32] <wgrant> danilos: Right.
[09:32] <wgrant> So, is it qa-ok?
[09:32] <danilos> wgrant, it's all very simple, and you have a head start compared to everybody else
[09:32] <wgrant> danilos: It's running much slower this time.
[09:32] <wgrant> Which may be a good sign.
[09:33] <danilos> wgrant, yeah, it doesn't break stuff and works fine for when languages are not hidden
[09:33] <wgrant> Indeed, queue is decreasing in size.
[09:33] <danilos> wgrant, I'll file a new bug if I find more problems with it
[09:33] <wgrant> danilos: Can you qa-ok the bug so I can request a deployment?
[09:33] <danilos> wgrant, I did that already
[09:34] <wgrant> Ah, great.
[09:34] <wgrant> Thanks.
[09:34] <wgrant> mthaddon: Around?
[09:34] <mthaddon> wgrant: yup
[09:41] <wgrant> mthaddon: We need r12112 deployed to cesium (to fix bug #692114).
[09:41] <_mup_> Bug #692114: Recipe builds require indices for non-main PPA components <qa-ok> <recipe> <Launchpad itself:Fix Committed by wgrant> < https://launchpad.net/bugs/692114 >
[09:41] <wgrant> mthaddon: There is one qa-bad rev in front of it, but that only affects the webapp.
[09:42] <wgrant> lifeless has given me his blessing.
[09:42] <mthaddon> erm, maybe, but that's completely non-standard...
[09:43] <wgrant> It was done for Soyuz a couple of weeks ago... r12043, IIRC.
[09:43] <lifeless> wgrant: it will need a incident report, I assumed you already knew that :)
[09:43] <mthaddon> that doesn't mean we're okay to do it every time...
[09:44] <lifeless> mthaddon: will you be at the epic?
[09:44] <mthaddon> lifeless: nope - mbarnett will be there though
[09:45] <lifeless> ok, I want to go through our exception-handling workflows face to face, can you perhaps make sure he's across all your concerns?
[09:45] <danilos> wgrant, fwiw, 12111 is also still "needtesting"
[09:45] <wgrant> mthaddon: Ah, OK.
[09:45] <wgrant> mthaddon: I was under the impression that it wouldn't be that abnormal.
[09:46] <wgrant> I guess I will wait.
[09:46] <mthaddon> how critical is it?
[09:47] <mthaddon> lifeless: I'm not really sure I understand the scope of the conversation you're after, but we can certainly cover anything over the phone that you need to
[09:47] <wgrant> It breaks recipe builds into new PPAs or new series in existing PPAs, which is probably most new recipes.
[09:47] <mthaddon> and how long has it been doing this for?
[09:48] <mthaddon> and how long do we expect before we can get those revisions qa-ed?
[09:48] <lifeless> mthaddon: that would be great
[09:48]  * mthaddon nods
[09:48] <wgrant> Well, buildbot is being more agreeable now, so it's not as long as I thought. Assuming that we don't get another qa-bad which immediately pushes us back another 24 hours :/
[09:48] <wgrant> But these look OK so far.
[09:49] <lifeless> mthaddon: scope wise - we have cherrypicks, but we're also doing some adhoc things while I've been on leave
[09:49] <wgrant> lifeless: Er, don't we not have cherrypicks any more?
[09:49] <lifeless> I'd like to consolidate things a bit, and talk cost-of-execution, latency, and approvals/risk analysis
[09:49] <mthaddon> yeah, we've not done a cherry pick for a good while now
[09:50] <lifeless> wgrant: we certainly do have them in policy
[09:50] <wgrant> I thought we'd lost that capability.
[09:50] <lifeless> wgrant: we haven't had to do many - but this soyuz working-around-unqaed-things is cherrypick-like
[09:50] <lifeless> wgrant: not at all
[09:51] <wgrant> lifeless: We need some way to roll out urgent changes that is not blocked by irrelevant bugs in the webapp, each of which blocks us for a day.
[09:51] <lifeless> wgrant: perhaps.
[09:52] <lifeless> wgrant: I'm not interested in drilling into this now. At the epic I'd be delighted to.
[09:52] <wgrant> Sure.
[09:53] <wgrant> I will say that the process simplification and frequent rollouts are great. It just seems to border on ridiculous to block another one-line critical fix for days.
[09:54] <lifeless> so we're not meant to block for days ever
[09:54] <lifeless> if there is something buggered, roll it back immediately.
[09:54] <wgrant> But every time we have a qa-bad we block for 24 hours.
[09:54] <wgrant> Which then gives us time for another one to slip in.
[09:54] <lifeless> things are *meant* to be qa'd the same day they land.
[09:54] <wgrant> => infinite chain of pain
[09:54] <lifeless> wgrant: how it is taking 24 hours?
[09:55] <wgrant> lifeless: The change is landed during the engineer's working day.
[09:55] <wgrant> 4 hours of EC2 + 1 hour of PQM + 6 hours of buildbot takes us well after the end of their day.
[09:55] <lifeless> and?
[09:55] <wgrant> They QA it the following morning.
[09:55] <wgrant> Notice that it's bad.
[09:55] <wgrant> Send the rollback through EC2.
[09:55] <wgrant> Another 11 hours later, it is in stable and can be QAd.
[09:55] <lifeless> so, flaw one: don't wait for the engineer to qa it.
[09:56] <lifeless> we're strongly encouraged to describe how to qa things in merge proposals.
[09:56] <lifeless> 2) rollbacks go straight to pqm, no ec2.
[09:57] <wgrant> s/rollback/fix/, then.
[09:57] <lifeless> don't fix
[09:57] <lifeless> rollback
[09:57] <wgrant> Since avoiding rollbacks in DVCS\{darcs} is nice.
[09:57] <lifeless> no, its insane.
[09:57] <lifeless> rollbacks are how we undo mistakes rapdily.
[09:58] <lifeless> there is no opprobobium in having something rolled back
[09:59] <lifeless> and it removes all the latency involved in analysing and fixing the issue in the bad commit
[10:03] <lifeless> wgrant: if something was broken, and I was working, I'd land a rollback with no hesitation at all
[10:03] <lifeless> wgrant: if we *don't* do this, the expected result is a trunk that is broken a lot.
[10:04] <wgrant> lifeless: So, it sounds like everyone needs to know three things: 1) QA quickly. 2) QA other people's stuff. 3) Rollback is the first resort, not the last.
[10:05] <lifeless> wgrant: makes sense to me
[10:05] <lifeless> wgrant: this has been communicated before, but it bears repeating.
[10:05] <lifeless> wgrant: I'll be talking about this in my TA report too
[10:05] <wgrant> Nobody treats QA as priority 1.
[10:05] <wgrant> When in reality it probably should be.
[10:06] <lifeless> wgrant: the logic behind this is simple; once a patch is in trunk, its on the critical path to deploy, anywhere.
[10:06] <lifeless> The only thing higher priority than QA is fixing a production issue directly.
[10:07] <lifeless> wgrant: this is why I was making such a big deal on your first? second? day about qaing when you had a blocked thing
[10:18] <danilos> wgrant, fwiw, I figured what the problem is with "sometimes doesn't work": if we have paths stored in pofiles in the DB (due to the previous buggy behavior) it can wrongly take up a wrong pofile early on
[10:18] <wgrant> danilos: Ah, great.
[11:04] <pcjc2> allenap, deryck: Is there anything you need me to chase RE: Contributor agreement?
[11:04] <pcjc2> (https://code.launchpad.net/~pcjc2/launchpad/allow-empty-comments/+merge/43449_
[11:04] <pcjc2> )
[11:04] <henninge> danilos: do you know what the problem might have been with bug 487137?
[11:04] <_mup_> Bug #487137: Allow Rosetta admins to create custom language codes <bugjam2010> <lp-translations> <Launchpad itself:In Progress by henninge> < https://launchpad.net/bugs/487137 >
[11:05] <henninge> danilos: Adi had a branch ready a month before his last comment on the branch (and unassigning himself from it).
[11:06] <danilos> henninge, I was just looking at that and planning to get it landed
[11:06] <henninge> danilos: ;)
[11:06] <danilos> henninge, yeah :)
[11:06] <danilos> henninge, if you want to take it over and go through it to ensure it's all still good, go for it ;)
[11:06] <henninge> danilos: but what is Adi's last comment about? Is the branch flawed?
[11:10] <danilos> henninge, well, last comment is from Michael, but just because of the status we should basically re-review it now
[11:11] <henninge> danilos: sorry, Adi's last comment on the *bug*
[11:11] <henninge> that's a month after Michael looked at the mp
[11:12] <danilos> henninge, oh, I think it's easy: we can just let project owners administer their own custom language codes
[11:13] <henninge> ;-)
[11:13] <danilos> henninge, especially since there won't be any per-app teams anymore, I think that's the way to go
[11:13] <henninge> good point
[11:13] <danilos> henninge, who ever screws it up for themselves, well, they've done it themselves
[11:13] <danilos> henninge, fwiw, we should make them able to do translations approval as well
[11:14] <henninge> hah!
[11:14] <danilos> henninge, it's just that we won't have the people to monitor it anyway, so we should just worry about being able to clean up later
[11:14] <henninge> good thing it's just the two of us here ...
[11:14] <danilos> henninge, heh
[11:15] <danilos> henninge, anyway, is that how Adi's branch is working? (i.e. using TranslationsAdmin privilege directly)
[11:16] <danilos> henninge, (if you looked at it)
[11:16] <danilos> henninge, MP suggests it is
[11:25] <henninge> sorry, was afk
[11:28] <lifeless> danilos: I think in general per-app responsibilities will become interrupt-team responsibilities; its not that there is noone to do it, its that its no longer such a static group of people
[11:29] <danilos> lifeless, and this is one of responsibilities that it'd be better to hand of to project owners than to hand of to that team, that's all I am saying
[11:29] <lifeless> danilos: +1
[11:30] <lifeless> danilos: I thought that perhaps you felt there wouldn't be staff to do it at all, rather than that project owners were a better natural fit
[11:30] <lifeless> danilos: so I was trying to clear that up, was all.
[11:30] <danilos> lifeless, well, the staff that will remain will not really be up to the task either, it's a complex work and you have to be careful (I am talking about import queue management) because it's easy to mess stuff up
[11:32] <lifeless> danilos: is that an ops thing perhaps?
[11:32] <danilos> lifeless, ideally, we wanted to transfer that to project owners only when we made it very hard to make mistakes, but I think it's better to let owners make mistakes now and be able to fix it to at least some extent than to have owners depend on a team that might make mistakes as well and depend on them to fix them afterwards
[11:32] <danilos> lifeless, "ops" as in operation? yes
[11:32] <danilos> operational, that is
[11:32] <lifeless> danilos: I love the idea of being able to fix things rather than obsessing about preventing them
[11:32] <lifeless> scales better
[11:32] <lifeless> feels easier to use
[11:32] <danilos> lifeless, the problem is that we can't really fix them atm
[11:33] <danilos> lifeless, which is why the permissions are very restricted
[11:33] <lifeless> danilos: sure, we have some work to do to get there
[11:33] <lifeless> its too late for me to try to understand the details
[11:33] <danilos> when I say "really", I mean "make sure the DB is in the best possible state"; it's not hard to make it appear relatively decent to outside users
[11:33] <lifeless> would love to do so at the epic perhaps
[11:33] <danilos> lifeless, yeah, sounds good, I guess thunderdome is a good place to do that
[11:41] <allenap> pcjc2: I'll follow up on the contributor agreement now.
[11:46] <allenap> pcjc2: I think my colleague might have been looking in the wrong place; your name is already on the signed list, and has been since the 17th. I'll land your branch now. Thank you, and sorry for the confusion :)
[11:46] <pcjc2> Thanks!
[11:47] <pcjc2> danilos: +2^n (n large), for letting projects manage their own translation imports - PRETTY PLEASE ;)
[11:48] <danilos> pcjc2, if that +2^n translates into someone doing to work for cleaning up the mess that people can make, I'll go all-in on that bid :)
[11:49] <danilos> pcjc2, but will do it even if that work is not done to the full extent
[11:49] <pcjc2> Hard to know - would  some clean-uprequire a LOSA?
[11:50] <pcjc2> or are you talking about extending LP code to allow more web-access to undo screw-ups?
[11:52] <allenap> pcjc2: Is there a bug related to that fix?
[11:52] <pcjc2> no, sorry
[11:52] <allenap> pcjc2: Okay, I'll file one, just so we can track QA.
[11:52] <pcjc2> ok, thanks
[12:06] <deryck> Morning, all.
[12:13] <danilos> pcjc2, it's about extending LP to allow more clean-ups and do some on it's own
[12:13] <danilos> pcjc2, for instance, it's totally impossible to remove templates today, and when they are left around they just cause more problems for people
[12:38] <danilos> anyone around who can help QA bug 670452, bug 619555 and bug 504080? (trying to get something rolled out, so need to go all the way to 12121)
[12:38] <_mup_> Bug #670452: Hard to find related branches when composing recipe <lp-code> <qa-needstesting> <recipe> <Launchpad itself:Fix Committed by wallyworld> < https://launchpad.net/bugs/670452 >
[12:38] <_mup_> Bug #619555: cronscripts/request_daily_builds.py is not verbose enough on default logging <bugjam2010> <canonical-losa-lp> <lp-code> <qa-needstesting> <recipe> <Launchpad itself:Fix Committed by thumper> < https://launchpad.net/bugs/619555 >
[12:38] <_mup_> Bug #504080: Please put the URL to the merge proposal in the body of the email <bugjam2010> <code-review> <email> <lp-code> <qa-needstesting> <trivial> <Launchpad itself:Fix Committed by abentley> < https://launchpad.net/bugs/504080 >
[12:41] <danilos> Ursinha, matsubara-afk: hi, where's the "specification" of all the bug tags that qa-tagger handles (I am wondering how do I tag a bug to indicate that one revision fixes a previous one)
[12:42] <Ursinha> danilos, let me find the link for you
[12:43] <danilos> Ursinha, I did find https://dev.launchpad.net/QAForContinuousRollouts though only through the mail archive, is there anything more complete?
[12:46] <Ursinha> danilos, that's a bit of a mess... here's the page I know: https://dev.launchpad.net/QAProcessContinuousRollouts
[12:47] <danilos> Ursinha, right, that one is much better
[12:48] <danilos> Ursinha, so, I guess the right approach to landing this should have been a rollback and then a full fixed landing
[12:49] <Ursinha> danilos, yes, I think so
[12:51] <danilos> Ursinha, should we perhaps add a 'fixes-REVNO' tag as well? (just wondering, because if rollback=REVNO was included in this landing I am looking at it would have been sufficient even though it doesn't really roll the change back)
[12:51] <Ursinha> danilos, the tag is bad-commit-firstrevno
[12:51] <Ursinha> where firstrevno is the defective one you want to rollback
[12:52] <danilos> Ursinha, well, look at bug 118284
[12:52] <_mup_> Bug #118284: URLs ending with a ) aren't linkified properly <bad-commit-12102> <bugjam2010> <lp-web> <qa-ok> <tales> <Launchpad itself:Fix Committed by jcsackett> <Ubuntu:Invalid> < https://launchpad.net/bugs/118284 >
[12:52] <danilos> Ursinha, 12102 is a bad-commit, tagged like that, and it was later fixed by 12121 (for the same bug)
[12:53] <Ursinha> danilos, fixed or rolledback
[12:53] <Ursinha> ?
[12:53] <danilos> Ursinha, fixed
[12:54] <Ursinha> so the first revision can be rolled out to production?
[12:54] <Ursinha> 12102
[12:54] <danilos> Ursinha, so, 12121 is good to go out, but nothing between 12102 and 12121 isn't because 12102 shouldn't go out without 12121
[12:54] <danilos> Ursinha, no
[12:54] <danilos> Ursinha, basically, regarding qa-tagger, it should behave exactly like rollback=12102 imo
[12:55] <danilos> Ursinha, but I am guessing developers won't use that because it doesn't make much sense
[12:55] <Ursinha> right, but now it doesn't
[12:55] <Ursinha> yeah
[12:55] <Ursinha> I guess the approach is a rollback then a full fixed branch
[12:55] <danilos> Ursinha, the difference between this and rollback is that this requires QA, where rollback doesn't
[12:55] <Ursinha> I get it
[12:55] <danilos> Ursinha, yeah
[12:56] <Ursinha> wondering how to proceed now
[12:56] <Ursinha> well, if you already qaed the fix, removing the tag is safe
[12:56] <Ursinha> right now deployments are blocked due to the bad-commit tag, so when you think that can land, just remove the tag
[12:57] <Ursinha> danilos, would you mind filing a bug against qa-tagger about it?
[13:01] <danilos> Ursinha, not at all
[13:06] <danilos> Ursinha, bug 692978
[13:06] <_mup_> Bug #692978: No way to mark a revision as fixing another bad revision <qa-tagger:New> < https://launchpad.net/bugs/692978 >
[13:07] <Ursinha> danilos, merci
[14:55] <abentley> rockstar, https://code.qastaging.launchpad.net/~abentley/bzrtools is giving a KeyError about "mergequeues".  Do you know anything about this? http://pastebin.ubuntu.com/546278/
[15:15] <rockstar> abentley, no, I don't know what that's about.
[15:16] <abentley> rockstar, okay, thanks.
[15:18] <rockstar> abentley, I don't know if wallyworld is working on merge queues, but I didn't but anything about mergequeues on the branch index page.
[15:29] <Ursinha> any soyuz people around?
[16:24] <allenap> sinzui: Did I accidentally fix bug 56038?
[16:24] <_mup_> Bug #56038: BugField should define some constraints <bugjam2010> <lp-bugs> <trivial> <Launchpad itself:Fix Released by allenap> < https://launchpad.net/bugs/56038 >
[16:24] <sinzui> yes
[16:25] <allenap> sinzui: \o/
[19:28] <thumper> morning
[20:04] <thumper> abentley: s = u'Hello \N{SNOWMAN}'
[20:16] <EdwinGrubbs> StevenK, jelmer_, wgrant: can I assign this question to one of you? https://answers.launchpad.net/launchpad/+question/138604
[20:17] <jelmer__> EdwinGrubbs: sure
[20:25] <EdwinGrubbs> jelmer: is it possible to build a package from a branch yet, or do you still need to use dput?
[20:26] <jelmer> EdwinGrubbs: That's an odd problem (The question)
[20:26] <jelmer> EdwinGrubbs: You can build from a branch without a dput but you'll need a recipe, which is probably more work than a dput at this point.
[20:27] <abentley> jelmer, I dunno about that-- we have a reasonable default recipe.
[20:28] <jelmer> abentley: "bzr bd && dput ../foo.changes" is quicker (and doesn't require a multi-minute recipe build) than clicking create recipe, adjusting the default recipe and requesting a build imho.
[20:30] <thumper> EdwinGrubbs: you can point the user to the help page
[20:30] <jelmer> abentley: Don't get me wrong, I'm a big fan of recipe builds and I think we're as close as we've ever been to building from branch but it's still not quite as easy as clicking a "Build this revision as a package" button in the web UI.
[20:31] <thumper> EdwinGrubbs: https://help.launchpad.net/Packaging/SourceBuilds
[20:32] <EdwinGrubbs> thanks
[21:44] <lifeless> gmb: hi
[21:44] <lifeless> gmb: you might like lp:~lifeless/launchpad/persistence
[21:44] <lifeless> gmb: I couldn't stop thinking about it, so I wrote down more science fiction.
[22:26] <jcsackett> wgrant, you around?
[22:27] <wgrant> jcsackett: Indeed.
[22:28] <jcsackett> wgrant: just wanted to let you know that the fix on the branch/bug we chatted about yesterday has gone through, but the bad-commit-tag can't be removed b/c there are revisions between that need to be qa'ed.
[22:28] <wgrant> jcsackett: Yeah, I saw that... but there's now *another* bad rev before the fix.
[22:28] <wgrant> Just for added fun.
[22:30] <jcsackett> wgrant: yeah, i just saw that qa-bad; it's weird, i qa'ed that this morning trying to get teh queue cleared out before i hit bugs i had no idea how to qa. thought that one looked good, but apparently someone more familiar with it saw issues i did not.
[22:31] <jcsackett> anyway, just wanted to keep you up to date; sorry there is yet further difficulty in getting to your revision. :-
[22:32] <wgrant> Breakage happens.
[22:32] <wgrant> But our process cannot deal with it :(
[23:52] <poolie> hello
[23:52] <poolie> could somebody please send https://code.edge.launchpad.net/~mbp/launchpad/690021-rlimit/+merge/43733 to pqm for me?
[23:52] <wgrant> poolie: Has it been through ec2?
[23:53] <poolie> no
[23:53] <wgrant> Also, thumper just nak'd it.
[23:54] <poolie> ok, fine
[23:55] <poolie> thumper: so shall i just reject it?
[23:55] <poolie> it was just a kind of drive by


[12:38] <thierry_> crimsun : Is there anyway to make some following command to wait that I have finished to edit the files with gedit? or do I need to run something like editor command?
[12:42] <siretart> crimsun: when doing merges, dont forget to use the -v flag in dpkg-buildpackage
[12:42] <siretart> crimsun: so the all missing changelogs gets in the changes file
[12:43] <siretart> slomo_: you, too ;)
[12:47] <Kyral> Hey can you increase the number of loopback devices?
[01:47] <crimsun> Kyral: beyond the default?
[01:48] <crimsun> siretart: nod
[01:48] <crimsun> Kyral: sudo modprobe max_loop=256  should suffice
[01:58] <Kyral> nm he found out fine
[01:59] <crimsun> anything over and beyond requires mucking with source
[02:00] <Kyral> He was mounting ISOs on loopbacks
[02:01] <crimsun> more than 256?
[02:03] <Kyral> no, he just didn't know how to increase the number
[02:05] <Kyral> crimsun, just curious, when is the new XFCE gonna be sync'd in?
[02:05] <crimsun> Kyral: when Debian has packaged it
[02:05] <Kyral> thats what I thought
[02:05] <crimsun> pkg-xfce still has quite a few bugs, particularly on ppc
[02:06] <Kyral> I am really amazed with XFCE's compmgr
[02:06] <Kyral> It seems to turn itself off when it realizes its not needed
[02:08] <Kyral> Like if I was running GNOME + xcompmgr and I tried to run ANYTHING through Cedega, X would crashout
[02:08] <Kyral> but with XFCE it seems to turn off compmgr when I use Cedega
[02:08] <crimsun> fairly early on, oliver decided to write his own
[02:09] <Kyral> oliver?
[02:09] <crimsun> I don't use those extensions
[02:09] <crimsun> lead developer of Xfce
[02:09] <Kyral> Ah
[02:09] <Kyral> I thought orga for a second :D
[02:09] <Kyral> Well, he did a very good job :D
[07:58] <polpak> I'm just curious, but if there are packages in Debian for some libraries and whatnot, why wouldn't there also be Ubuntu packages?
[09:22] <sivang> MOrning all
[09:24] <polpak> hello
[09:25] <sivang> hey polpak
[09:27] <polpak> Do you know much about the packages in universe?
[09:28] <polpak> I'm basically wondering how to get packages built for Debian into Ubuntu universe..
[09:29] <Nafallo> yes, we maintain them.
[09:29] <Nafallo> they get auto-synced from Debian in here.
[09:30] <polpak> ok
[09:31] <polpak> I'm looking to get some ubuntu packages for a 3d rendering engine called ogre
[09:31] <polpak> I know that debian has them, but ubuntu doesn't
[09:31] <polpak> someone was talking about adding them to ubuntu
[09:31] <sivang> polpak: so you probably need to check the build logs, they may have failed building?
[09:31] <sivang> Nafallo: any idea?
[09:33] <Nafallo>       ogre |    1.0.5-1 | http://localhost dapper/universe Sources
[09:34] <Nafallo> probably FTBFS
[09:35] <polpak> FTBFS?
[09:35] <Nafallo> Failed To Build From Source
[09:35] <sivang> polpak: as I thought, there was probably some problem with building the binary from the source pkg
[09:36] <polpak> oh
[09:36] <polpak> I know how to build it
[09:36] <Nafallo> I'm looking at it.
[09:36] <polpak> from source
[09:36] <polpak> mostly it just has a lot of dependancies
[09:36] <Nafallo> missing build-deps
[09:36] <polpak> but the dependancies are also available as debian packages AFAIK
[09:39] <polpak> Need any help getting all the needed deps?
[09:53] <Nafallo> polpak: just let me try this build I have running first.
[09:53] <polpak> ok
[10:14] <Nafallo> polpak: built locally now :-)
[10:14] <polpak> =)
[10:16] <Nafallo> * Added Build-Dep on x11proto-xf86vidmode-dev.
[10:16] <polpak> what is that one?
[10:16] <polpak> I don't recall seeing it
[10:17] <Nafallo> Description: X11 Video Mode extension wire protocol
[10:18] <polpak> Hrm. I'll take your word for it =)
[10:18] <polpak> I know it depends on the nvidia-cg-toolkit
[10:18] <polpak> and that's also not available in Breezy
[10:19] <Nafallo> ouch! lot's of lintian errors
[10:19] <polpak> lintian, as in from lint?
[10:21] <Nafallo> Description: Debian package checker
[10:22] <polpak> ah
[10:26] <zakame> hi all
[10:27] <polpak> hi
[10:28] <Nafallo> polpak: anyway, uploaded.
[10:29] <polpak> Nafallo: uploaded ?
[10:29] <Nafallo> to the archive. will be in as soon as the build-machines are finished.
[10:29] <polpak> Nafallo: sorry if I'm too noob. I'm coming from a fedora environment
[10:30] <polpak> it'll be in breezy universe?
[10:30] <Nafallo> nope, breezy is now 5.10 and frozen.
[10:31] <Nafallo> will be in dapper
[10:31] <polpak> oh
[10:31] <polpak> so I've got to get it from backports?
[10:31] <polpak> if someone adds it?
[10:31] <Nafallo> sure, ask jdong or Mez when you see them.
[10:31] <polpak> or wait 6 months.. ? ;p
[10:31] <tseng> or you could upgrade and help out.
[10:32] <polpak> tseng: I would, but I wouldn't really know where to start
[10:33] <zakame> hi zyga
[10:37] <zyga> zakame: good morning :-)
[10:47] <mr-russ> What is needed if I want to maintain, or help maintain a package?
[10:47] <crimsun> please see the topic
[11:04] <dholbach> hellas
[11:04] <zakame> webaks dholbach :D
[11:05] <dholbach> webaks? hi zakame :)
[11:05] <zakame> dholbach: welcome back :)
[11:05] <dholbach> what language is that? :)
[11:06] <zakame> pinoy internet slang, i presume, just heard about it from -ph :)
[11:06] <Treenaks> :)
[11:20] <dholbach> still no motu report :/
[11:20] <dholbach> anyone want to add stuff from last month + ubz? i'm going to write it now
[11:21] <dholbach> http://wiki.ubuntu.com/MOTUReport
[11:21] <dholbach> er ... http://wiki.ubuntu.com/MOTUReportDraft
[11:23] <sivang> dholbach: if you would send me links for info, I can do it if you want :)
[11:23] <dholbach> sivang: that's part of the work :)
[11:23] <dholbach> finding out...
[11:23] <dholbach> i enjoy doing the writing, but i simply forget stuff that happened
[11:24] <Nafallo> dholbach: We have released Ubuntu 5.10 :-)
[11:24] <Ubugtu> Error: Could not parse XML returned by Ubuntu Bugzilla bugzilla: not well-formed (invalid token): line 88, column 76
[11:25] <zakame> eh?
[11:26] <Nafallo> zakame: what? :-)
[11:26] <crimsun> (Ubugtu is a bot that automatically pulls Malone info if it sees a bug #)
[11:26] <crimsun> bug #4437
[11:26] <Ubugtu> Malone bug #4437: waili: merge new debian version Fix req. for: waili (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/4437
[11:26] <Nafallo> or bugzilla if it sees Ubuntu it seems ;-)
[11:27] <zakame> ah... so that's why Ubugtu just ponged
[11:27] <zakame> as in Ubuntu 5.10
[11:27] <Ubugtu> Error: Could not parse XML returned by Ubuntu Bugzilla bugzilla: not well-formed (invalid token): line 88, column 76
[11:28] <Nafallo> Ubuntu 510
[11:28] <Ubugtu> Ubuntu Bugzilla bug #510: /usr/bin/ld: assertion fails on mips/mipsel Product: Ubuntu, Component: binutils, Severity: major, Assigned to<EMAIL_ADDRESS>Status: RESOLVED, Resolution: DUPLICATE http://bugzilla.ubuntu.com/show_bug.cgi?id=510
[11:28] <Nafallo> yepp :-)
[11:30] <zakame> bbl, be uploading some debdiffs
[11:34] <dholbach> minghua: do you happen to know what is wrong with breezy's scim?
[11:34] <dholbach> minghua: i got a users mail about it, but i'm not quite sure, what he's referring to
[11:36] <dholbach> how about mentioning NEW software we got in in the MOTU report?
[11:44] <dholbach> can somebody of the 'motu' launchpad team drop "danielholbach" and add "dholbach" please?
[11:50] <dholbach> who of you became ubuntu member and wants to be a MOTU soon?
[11:51] <crimsun> dholbach: I deactivated danieldolbach and added dholbach, but I think ogra will need to bump dholbach to Administrator status
[11:51] <dholbach> crimsun: thanks for that
[11:51] <crimsun> np
[11:55] <crimsun> later guys
[11:58] <hunger> launchpad is almost usable when not viewed in IE:-)
[12:01] <hunger> How can I have my launchpad account deleted again?
[12:01] <hunger> Looks like I got two of them.
[12:02] <Treenaks> hunger: how about using lynx? :)
[12:02] <hunger> Treenaks: And that will delete accounts?
[12:02] <Treenaks> no
[12:03] <hunger> Treenaks: lynx is not available on a windows box:-( Windows is my only connection into the net during the week.
[12:04] <hunger> Hi selinium
[12:04] <selinium> Hi hunger :)
[12:24] <dholbach> http://wiki.ubuntu.com/MOTUReportDraft
[12:24] <dholbach> please change and add missing stuff
[12:24] <dholbach> merci beaucoup
[12:47] <lucas> zyga: are you planning to do something for moturuby ?
[12:48] <dholbach> hellas dredg
[12:48] <Tonio_> hi everyone
[12:48] <dholbach> hey Tonio_
[12:48] <Tonio_> dholbach: Upgrading pwmanager because of new upstream release
[12:48] <Tonio_> maybe this one will upload correctly :)
[12:48] <zyga> lucas: yes
[12:48] <zyga> lucas: but now I'm overloaded with RL job
[12:48] <Tonio_> dholbach: I will upload all my waiting packages toonight
[12:49] <dholbach> Tonio_: elmo should know, what went wrong
[12:49] <dholbach> cool
[12:49] <dholbach> thanks for your work on this
[12:49] <Tonio_> I was in vacation and lost much time ;)
[12:49] <codepoet> Alrighty, who's going to help me get started with some suggestions I need to make and/or universe access? haha
[12:49] <dholbach> codepoet: what do you want to do?
[12:49] <codepoet> well
[12:50] <codepoet> there are some suggestions i need to make to the appropriate people and/or be able to change them myself
[12:50] <dholbach> like what?
[12:50] <codepoet> for one, the acx100 driver provided is old and locks up systems, including my own
[12:50] <codepoet> second
[12:50] <dredg> dholbach: morning
[12:51] <dholbach> codepoet: that's something you should talk about in #ubuntu-kernel :)
[12:51] <codepoet> ok
[12:51] <dholbach> codepoet: they are most likely to fix it
[12:51] <codepoet> second
[12:51] <hunger_> codepoet: That's a bugreport, no suggestion IMHO.
[12:51] <codepoet> apt network repository testing during installation freezes if your wireless card isn't configured right
[12:52] <dholbach> freezes in which way?
[12:52] <codepoet> at 50$
[12:52] <codepoet> 50%
[12:52] <dholbach> (sounds like a bugreport to me too)
[12:52] <codepoet> which is 1/2 of it
[12:52] <codepoet> ok
[12:52] <codepoet> also
[12:52] <codepoet> lilo installation doesn't work period
[12:52] <dholbach> lilo? we use grub
[12:52] <codepoet> if you select lilo, it just doesn't work
[12:52] <codepoet> yeah
[12:52] <dholbach> ah ok... hm
[12:53] <doko> anybody knows if \sh_away is still away?
[12:53] <codepoet> but lilo is sill in the installer
[12:53] <codepoet> it's mentioned
[12:53] <dholbach> sounds like http://bugzilla.ubuntu.com is way to go
[12:53] <codepoet> and is supposed to work, i suppose
[12:54] <codepoet> also, if you don't specify a hostname during the install you can't do anything unless you go into recovery mode and modify /etc/hosts
[12:55] <codepoet> very inconvenient
[12:55] <codepoet> a new user would be thrilled haha
[12:56] <dholbach> thanks for inspecting the installer that closely... it would be nice, if you filed bugs for those
[12:56] <codepoet> one last thing though
[12:56] <codepoet> haha
[12:56] <codepoet> and this is the kicker
[12:56] <codepoet> breezy comes with gcc 3.3
[12:56] <codepoet> the kernels are compiled for 3.4
[12:57] <dholbach> it comes with gcc4
[12:57] <codepoet> if you have no network access and need to compile a network card driver -- you're screwed
[12:57] <dholbach> yes, that's a problem
[12:57] <codepoet> right
[12:57] <codepoet> idk why they choose 3.3 if they compiled them with 3.4
[12:57] <codepoet> if they're stable enough for the kernels
[12:57] <dholbach> gcc4
[12:57] <codepoet> right
[12:57] <codepoet> as default
[12:57] <dholbach> there were problems with building the kernel with gcc 4
[12:57] <codepoet> but gcc-3.3-base also comes with it
[12:58] <dholbach> i guess there wasnt enough space to ship 2 sets of compilers with the cd
[12:58] <codepoet> which is i suppose a way to appease people that had to use 3 still
[12:58] <dholbach> which is... yes ... problematic
[12:58] <codepoet> right
[12:58] <codepoet> and there was one more thing i couldn't pinpoint as a problem but it was very annoying
[12:58] <hunger> codepoet: I think gcc-3.3 base is needed for some proprietary apps (acroread). Maybe it was included due to that.
[12:59] <codepoet> failsafe gnome, default session, all of them twice on me failed to bring up gnome after gdm login, they would just freeze
[01:00] <codepoet> and Ctrl+Alt+Backspace would just NOT bring down gdm no matter how many times you did it, when after crashing 3 times it would ask if you wanted to go to the console on many distros
[01:00] <dholbach> anyone from the mono team here? anyone like to package lat (ldap administration tool) - it comes with a basic debian packaging already, but would need some love (http://people.mmgsecurity.com/~lorenb/lat/)
[01:00] <dholbach> codepoet: i think that was fixed in the last gdm (in dapper)
[01:00] <codepoet> ok cool
[01:01] <codepoet> good deal
[01:01] <dholbach> but anyway... bug reports are a better way of writing those down :)
[01:01] <codepoet> ok
[01:01] <codepoet> i'll do that
[01:02] <codepoet> is there any chance one of you could point me in the right direction of getting some kind of developer or tester or some kind of status so i can contribute?
[01:02] <codepoet> other than bugreports, i suppose is what i mena
[01:02] <codepoet> mean*
[01:03] <dholbach> codepoet: we have quite a lot of teams going on... the MOTU team of course, we're about to form a team of bug squashers and quite some others... it depends what you want to do in the ubuntu landscape :)
[01:04] <codepoet> everything
[01:04] <codepoet> haha
[01:04] <codepoet> for one
[01:04] <dholbach> cool :)
[01:04] <codepoet> if there's not an official maintainer of the acx100 driver i'd like to take the part
[01:04] <lucas> rah
[01:04] <lucas> ruby sucks so much in breezy
[01:04] <dholbach> you should talk to the kernel guys... i guess they'll be quite happy to have somebody helping them out
[01:05] <lucas> it doesn't even know that 30 Aug + 1 day = 31 Aug, not 01 Sep
[01:05] <codepoet> another, i'm a C/C++ programmer so i can contribute to a few things
[01:05] <dholbach> codepoet: we're currently merging the debian changes, which is A LOT of work and everybody would be happy if you'd help out there
[01:06] <codepoet> yeah, i was a former debian maintainer
[01:06] <bmonty_laptop> merges are fun!
[01:06] <dholbach> rock'n'roll
[01:06] <dholbach> nice to hear that
[01:06] <codepoet> even though ubuntu just refuses to fscking work for me no matter what i do, i have hope in the project
[01:06] <dholbach> thanks for that :)
[01:07] <codepoet> i hope to at least have dapper as my main OS
[01:07] <codepoet> until then it's Windows + QEMU for me
[01:09] <dholbach> hey slomo
[01:10] <slomo> hi dholbach :)
[01:10] <slomo> is elmo awake again for syncs?
[01:11] <dholbach> ARG
[01:12] <lucas> dholbach: do you have an ETA for a ubuntu-motu mailing list ?
[01:12] <lucas> most of the members of MOTURuby are not subscribed to ubuntu-devel, so there's no real way to contact them
[01:12] <dholbach> lucas: jdub is not here, working on it
[01:14] <lucas> what are my chances to get an upload of a new ruby version in breezy-updates ?
[01:14] <lucas> since ruby is in main
[01:14] <womble> I'm looking for a MOTU who will be coming LCA2006 in Dunedin, to talk to the Debian miniconf about Universe, what it's like deriving from Debian, and what Debian is doing well and poorly from the MOTU perspective.
[01:15] <dholbach> ajmitch_: ^? :)
[01:15] <womble> If you fit this description, chat to me now or e-mail me at<EMAIL_ADDRESS>[01:15] <dholbach> Lathiat: were you planning to be there? ^ :)
[01:15] <Gloubiboulga> hi
[01:17] <sivang> dholbach: the report looks quite good, what else did you want to include in it?
[01:17] <bmonty_laptop> hi Gloubiboulga
[01:17] <sivang> hey bmonty_laptop
[01:17] <dholbach> sivang: whatever happened and i forgot
[01:18] <bmonty_laptop> hi siretart
[01:18] <bmonty_laptop> er...sivang
[01:27] <sivang> bmonty_laptop: hehe, use irssi :)
[01:27] <sivang> dholbach: what about sitestart being approved for main?
[01:27] <sivang> dholbach: (during UBZ)
[01:27] <bmonty_laptop> sivang: nah, I'm to used to X-Chat to switch :)
[01:28] <dholbach> sivang: oh yes... that's a good one, would you mind to add it?
[01:29] <Tonio_> dholbach: new version of pwmanager (1.4.1) uploaded (just for your information)
[01:29] <dholbach> Tonio_: cool, if something strange happens, talk to elmo please
[01:29] <sivang> dholbach: not at all :)
[01:29] <dholbach> sivang: merci
[01:29] <Tonio_> dholbach: yep
[01:29] <Tonio_> dholbach: when I say uploaded, I mean on revu ;)
[01:29] <sivang> dholbach: no prob.
[01:29] <dholbach> ah ok :)
[01:30] <Tonio_> dholbach: it still needs to be approved and uploaded
[01:30] <dholbach> ok, will look at it later
[01:34] <Tonio_> dholbach: thanks ;)
[01:35] <sivang> dholbach: could you let me know if you like it?
[01:36] <codepoet> ok
[01:36] <dholbach> sivang: stuper
[01:36] <dholbach> sivang: super
[01:36] <codepoet> all 6 bugs have been documented
[01:36] <sivang> dholbach: merci :)
[01:36] <dholbach> codepoet: thanks for that
[01:38] <codepoet> oops
[01:39] <codepoet> seems there was already a duplicate of one bug
[01:39] <codepoet> yay
[01:39] <codepoet> it's not just me
[01:50] <raphink> hi :)
[01:50] <raphink> siretart: I've sent a request to add my key to the REVU keyring. Did you get it?
[01:54] <Tonio_> dholbach: what would you do if the homepage URL in the extended description of a package is too long and causes a lintian error ?
[01:54] <Tonio_> would you let it or remove it ?
[01:55] <dholbach> probably remove it
[01:55] <Tonio_> okay
[01:55] <Tonio_> and let a note on revu on the reason it isn't added maybe ?
[01:57] <dholbach> if it's in debian/copyright it's ok
[02:00] <Tonio_> dholbach: it is
[02:00] <Tonio_> dholbach: rebuilding it and uploading it, thanks !
[02:01] <dholbach> de rien
[02:02] <Tonio_> dholbach: when you come to Paris, poke me and we'll have a bear, speaking french, I'd much appreciate it ;)
[02:02] <dholbach> hehe... bien sur :)
[02:02] <Tonio_> ^_^
[02:18] <\sh> i need elmo somehow
[02:20] <zakame> hi ho
[02:25] <Lathiat> dholbach, womble: I'll be at lca2006
[02:25] <Lathiat> womble: i can do that if you like
[02:26] <dholbach> Lathiat: if you want, i can provide you with slides on a community / motu talk
[02:26] <Lathiat> dholbach: cool
[02:26] <dholbach> Lathiat<EMAIL_ADDRESS>?
[02:26] <Lathiat> i'll be there may as well make the most of it :)
[02:26] <Lathiat> dholbach: yeh
[02:26] <Lathiat> or @ubuntu.com
[02:26] <dholbach> Lathiat: rock, will take care of it later
[02:26] <Lathiat> cheers
[02:26] <Lathiat> should organize my passport this week
[02:27] <Lathiat> womble: i'd prefer a day 1 talk so i can goto GCA on day 2
[02:28] <Lathiat> bbs
[02:29] <womble> Lathiat: I'm pretty sure that could be arranged (day 1 vs day 2).  Thanks so much for offering to talk.
[02:39] <dholbach> so who could have a final look at MOTUReportDraft, so i can mail it out?
[02:40] <zakame> I was reading it, 'tis nice :)
[02:50] <Lathiat> womble: nps
[02:50] <Lathiat> wo	so what els eis on the agenda?
[02:51] <womble> Lathiat: It's fairly early stages yet -- Jon Oxer and I really only got together for our first planning meeting this morning.
[02:51] <Lathiat> womble: ah cool
[02:52] <Lathiat> i know jon i like him :)
[02:52] <Lathiat> he'll knwo who i am
[02:52] <womble> Excellent.
[02:52] <bmonty_laptop> dholbach: report looks great to me....probably the best I have seen so far
[02:52] <Lathiat> did a talk at the 03 miniconf on using ipv6
[02:52] <dholbach> bmonty_laptop: wow... thank you
[02:53] <womble> Lathiat: So you're a seasoned pro then... <grin>
[02:53] <bmonty_laptop> UBZ info is very useful
[02:53] <Lathiat> :)
[03:05] <dholbach> sent the mail...
[03:07] <dholbach> sorry for the noise
[03:12] <zakame> dholbach: yay!
[03:12] <zakame> hmmm, when updating merges shall I also update the Standards-Version?
[03:16] <bradb> siretart: ping
[03:17] <bradb> siretart: Just curious: was that "avifile: merge new debian version" dup problem due to some script testing you were doing?
[03:28] <zakame> hi SEJeff
[03:28] <zakame> and Seveas too :D
[03:29] <Seveas> hi
[03:33] <\sh> bradb: I don't think so
[03:36] <zakame> just to be sure, do I debdiff my changes from the original debian version, or from the MoM version?
[03:40] <whiprush_> dholbach: Issue 9 has been Fridged!
[03:41] <dholbach> whiprush_: ROCK'NROLL
[03:41] <dholbach> thank you
[03:42] <zakame> jerome!
[03:43] <jsgotangco> hiya
[03:43] <siretart> yay, one internal server in my department was just upgraded from woody to breezy :)
[03:43] <zakame> siretart: w00t
[03:43] <siretart> it is also installation server for clients which are used by students (also installing breezy) :)
[03:47] <slomo> Nafallo: kernel build failed everywhere :(
[03:49] <Nafallo> udev?
[03:52] <slomo> no, some weird wlan driver
[03:52] <Nafallo> rt2500? ;-)
[03:52] <slomo> now
[03:52] <slomo> no
[03:53] <slomo> something beginning with z :P
[03:53] <slomo> look at the log
[03:53] <Nafallo> oki :-)
[03:53] <raphink> siretart: I sent my key this morning to subscribe to REVU. Did you get it?
[04:22] <siretart> raphink: I think so, but I'm currently at work
[04:28] <Nafallo> woohoo! libmagick9 seems to be NEW'd'
[04:29] <Treenaks> omgwtf!?
[04:37] <raphink> siretart: ok :)
[04:37] <hunger> Hi siretart.
[04:38] <bmonty_laptop> is it ok if I put a merged package onto REVU?
[04:40] <zakame> can any master please check Malone #4085?
[04:40] <Ubugtu> Error: Could not parse XML returned by Malone bugzilla: Connection to Malone bugzilla failed: HTTP Error 404: Not Found
[04:46] <bmonty_laptop> Malone #4443
[04:46] <Ubugtu> Error: Could not parse XML returned by Malone bugzilla: Connection to Malone bugzilla failed: HTTP Error 404: Not Found
[04:46] <hunger> This Ubugtu is annoying.
[04:46] <hunger> #1 annoyance:-)
[04:46] <Nafallo> Malone 4443
[04:46] <Ubugtu> Error: Could not parse XML returned by Malone bugzilla: Connection to Malone bugzilla failed: HTTP Error 404: Not Found
[04:46] <bmonty_laptop> hunger: its helpful when it works
[04:46] <Nafallo> hmm, odd
[04:47] <hunger> bmonty_laptop: Dunno... maybe.
[04:47] <zakame> iirc it was ok earlier
[04:47] <bmonty_laptop> it works on #ubuntu-bugs
[04:47] <hunger> bmonty_laptop: The idea is good, but the thing is too noisy for my taste.
[04:48] <bmonty_laptop> yeah maybe it should only respond if it is asked....not parse conversations
[04:48] <hunger> bmonty_laptop: Now, then it would rock:-)
[04:49] <\sh> argl
[04:49] <hunger> pepito: Just using /dev/input/mice and hoping for the best does not suffice?
[04:49] <\sh> my first day at work...and completly fcked
[04:49] <hunger> Sorry, wrong channel.
[04:50] <zakame> \sh: how come?
[04:52] <zakame> hmm, does lpbugs.py work with gmail?
[04:53] <zakame> I'm getting smtp auth not supported by server :(
[04:53] <bmonty_laptop> zakame: get the lastest version
[04:53] <zakame> bmonty_laptop: via bzr pull, right?
[04:54] <\sh> zakame: gmail is not supporting standard smtp auth
[04:54] <\sh> zakame: it's a non problem with smtplib and gmail
[04:54] <\sh> s/non/known/
[04:54] <\sh> btw
[04:54] <\sh> anyone read Dokos announcement on ubuntu-devel ML
[04:54] <\sh> ?
[04:54] <zakame> \sh: ah... so in other words I can't use this
[04:55] <\sh> about touching again some library packages and renaming them?
[04:55] <\sh> zakame: well..if u need a real smtp server with working functionality...i can help u out
[04:55] <bmonty_laptop> \sh: there are some spelling/grammer issues with text lpbugs puts in launchpad...are you interested in patches if I update them?
[04:55] <\sh> bmonty_laptop: sure :)
[04:55] <bmonty_laptop> \sh: yeah I just read it
[04:55] <Tonio_> little question: does anyone know if there is a kind of cdbs .mk file for scons ?
[04:55] <bmonty_laptop> \sh: ok, I'll fix them up a little and email you the patch
[04:56] <\sh> ok...anyone against this idea, that i#m taking over this task?
[04:56] <\sh> bmonty_laptop: do u have bzr?
[04:56] <bmonty_laptop> \sh: I installed it, but I haven't had any time to learn how to use it
[04:56] <\sh> bmonty_laptop: ok..send me a patch :)
[04:58] <bmonty_laptop> \sh: do I make changes and then 'bzr commit'?
[04:59] <\sh> bmonty_laptop: yes...and then u give me the location where I can merge from
[04:59] <bmonty_laptop> k
[05:00] <zakame> \sh: hmmm, I've just tried again using my own shell account, lpbugs doesn't work either, still same error
[05:01] <\sh> zakame: did u change from smtp to sendmail? try it with a local mta configured
[05:02] <zakame> will try
[05:04] <bmonty_laptop> cya all later
[05:05] <zakame> bye bmonty_laptop
[05:27] <hunger> How do I make sure a set of debs is at the same version?
[05:32] <hunger> siretart: Got a working dom0 with my debs:-) Progress! ;-)
[05:38] <hunger> Can I use the current version in debian/control?
[05:43] <raphink> I'd like to package kim but it's only a collection of bash scripts with an install.sh script
[05:43] <raphink> can it be packaged ?
[05:43] <hunger> raphink: Why not?
[05:43] <raphink> hunger: just wondering
[05:43] <raphink> dh_make won't do anything about it
[05:43] <hunger> raphink: If it can get installed, then it can get packaged;-)
[05:44] <raphink> since there's no makefile
[05:44] <hunger> raphink: Remove that.
[05:44] <raphink> well the question is rather : _how_ can it be packaged ?
[05:44] <sivang> raphink: you would probably only need to create a $pkg.install file to copy files from the pkg to the right location
[05:44] <hunger> raphink: the install targets basically only need to call the install script.
[05:44] <sivang> raphink: you'd need to use dh_install probably
[05:44] <sivang> sombody please correct me if I am talking rubbish :)
[05:44] <hunger> raphink: or do what sivang says:-)
[05:44] <raphink> ok
[05:45] <raphink> well the install script uses a qt dialog
[05:45] <raphink> I think this is not suitable in a package
[05:45] <raphink> it asks for a choice between 3 actions and then puts the bash scripts in teh right places
[05:45] <sivang> raphink: you should then try to convert i into a debconf question..
[05:45] <hunger> raphink: Oh... then you will need to copy the files "manually" in the appropriate install target.
[05:46] <siretart> hunger: w00t!
[05:46] <raphink> sivang: so I would have to basically convert the install.sh into a pre script with debconf and a post script installing the scripts in the system
[05:46] <raphink> right?
[05:47] <hunger> raphink: If there is no place where it belongs in debian then converting the dialog into a debconf question might be a good idea.
[05:47] <hunger> siretart: ?
[05:47] <raphink> hunger: kim is just a series of scripts that add a submenu in Konqueror to manage images
[05:48] <hunger> raphink: Then all you need to do is figure out where the scripts need to go in ubuntu's konqueror install.
[05:48] <hunger> raphink: And declare a dependencies on konqueror.
[05:48] <raphink> hunger: that's what the install.sh script does
[05:48] <raphink> yes I guess so hunger
[05:48] <raphink> there is a dependency on konqueror and imagemagick
[05:49] <raphink> the pb is not the dependencies actually for me but rather the way to package it
[05:49] <hunger> raphink: Doesen't sound to hard to do then;-)
[05:49] <siretart> hunger: yay for your dom0 debs
[05:49] <raphink> just have to know how hunger ;)
[05:49] <hunger> siretart: Oh, thanks.
[05:49] <sivang> raphink: I think so...but better follow hunger's suggestions :)
[05:50] <hunger> sivang: I have no clue what I am talking about;-)
[05:50] <raphink> lol
[05:50] <sivang> hunger: err, then you fooled me :) I'm really insecure still with pkging question, but I try my best helping without causing harm :)
[05:50] <hunger> raphink: You should get a template with that script...
[05:51] <raphink> what do you mean hunger ?
[05:51] <hunger> raphink: Then you should be able to remove all the stuff in the build rules.
[05:51] <sivang> hunger: there must be something like that somewhere
[05:51] <hunger> raphink: Let me check... only ever used that script once:-)
[05:51] <raphink> ok
[05:51] <sivang> hunger: as a ready template , probably for python stuff that doesn't need pyc
[05:52] <hunger> siretart: Can I use the current version number of the debs in debian/control?
[05:52] <raphink> so if I understand well
[05:52] <raphink> the easiest way should be to use a .install
[05:52] <hunger> raphink: dh_make....
[05:52] <raphink> and use dh_install in the rules
[05:52] <hunger> raphink: that's what it was called;-)
[05:52] <raphink> hunger: dh_make says it finds no makefile
[05:53] <hunger> raphink: I'd try "touch Makefile" then;-)
[05:53] <hunger> raphink: But don't listen to me too carefully, I only started on my first deb last week.
[05:53] <raphink> hehe
[05:54] <hunger> raphink: I'm messing around a lot without a clear idea of how things should work.
[05:54] <raphink> hmmm
[05:54] <siretart> hunger: err, what do you mean with 'current version number'?
[05:54] <raphink> I think I should only ask a debconf question in a pre script
[05:54] <raphink> and then use the install script as it is in a post
[05:54] <hunger> siretart: The newest changelog entry.
[05:55] <hunger> siretart: I want to make sure that you only use a set of debs from the same revision.
[05:55] <siretart> hunger: what do you currently have as version number?
[05:55] <hunger> siretart: 3.0pre20051113-0ubuntu1
[05:55] <Gazer> Hi, Universe bugs are reported in Malone, right ?
[05:55] <hunger> I think...
[05:55] <siretart> hunger: you can force this with versioned depends
[05:56] <hunger> siretart: Yeap... my question is: How so?
[05:56] <siretart> that version number sounds sane
[05:56] <Nafallo> Gazer: yes
[05:57] <hunger> siretart: I hoped so;-) It is  < 3.0.0 so there shouldn't be a problem when the stable version is released.
[05:58] <siretart> hunger: oh, that easy: place a 'Depends: hypervisor (= ${Source-Version})'
[05:58] <siretart> in debian/control
[05:58] <siretart> or how your dependency tree actually is
[05:58] <siretart> please try to avoid circular dependencies
[05:58] <hunger> siretart: Thanks! I was looking for that ${Source-Version};-)
[05:59] <hunger> siretart: Do I need to Replace << ${S-V}?
[05:59] <Gazer> Nafallo, thx
[05:59] <siretart> no
[06:05] <raphink> is there a tool to make scripts using debconf easily?
[06:05] <raphink> or should scripts with debconf be written manually?
[06:08] <hunger> raphink: What do you want to use debconf for?
[06:08] <raphink> well I'm wondering what I shall do actually lol
[06:08] <hunger> raphink: Wasen't that QT dialog about figuring out where the files must go?
[06:08] <raphink> the kim install.sh script asks whether you want a default install or an install with plugins
[06:08] <raphink> that's what the qt dialog asks
[06:09] <hunger> raphink: Why not do a "kim" deb and a "kim-plugins" deb?
[06:09] <raphink> hmmm
[06:09] <raphink> that might do it
[06:10] <hunger> raphink: You can suggest the plugins from the kim one and depend on kim in the plugins.
[06:10] <raphink> except that the installation with plugins is just one more file
[06:11] <raphink> I don't think it's a good idea to make a new package for just one more line
[06:11] <hunger> raphink: Then just install that file and be done with it;-)
[06:11] <raphink> yep I'll install the plugins by default
[06:11] <raphink> but then
[06:11] <raphink> sorry for all these stupid questions ;)
[06:11] <hunger> raphink: ... or is that file huge?
[06:11] <raphink> I don't think so hunger
[06:12] <hunger> raphink: No problem. I'm waiting on debuild anyway:-)
[06:12] <raphink> hunger: http://ubuntu-fr.pastebin.com/429199
[06:12] <raphink> this is the install.sh script
[06:13] <hunger> raphink: I wouldn't start another package for that;-)
[06:13] <raphink> how shall I use it to make a package and have each script installed in the right place is what I don't understand
[06:13] <raphink> well it's a useful tool hunger
[06:13] <hunger> raphink: How big is the plugins dir?
[06:14] <raphink> 5.5kB LOL
[06:14] <hunger> raphink: Why do they ask about installing the plugins for 5kB? Does it add lots of entries into the menus?
[06:15] <raphink> no idea, I never tried without
[06:15] <raphink> it adds two functions
[06:16] <raphink> well more actually
[06:16] <raphink> it adds movie options
[06:16] <raphink> anyway that's not the main point
[06:16] <raphink> ;)
[06:18] <Gloubiboulga> How can I send a bug correction on a Universe package ?
[06:18] <Gloubiboulga> and hello everyone :)
[06:18] <raphink> hunger: the main point is : how do I sent the package to instlal the components ?
[06:18] <raphink> *set
[06:19] <dholbach> Gloubiboulga: a patch?
[06:19] <hunger> raphink: Copy the stuff under 2) in that pastebin file into debian/rules (install-indep).
[06:19] <raphink> ok
[06:19] <hunger> raphink: remove everything not appropriate in there... that should have been it.
[06:19] <raphink> hmm
[06:19] <Gloubiboulga> dholbach, I don't know.. a patch is enough ?
[06:19] <hunger> raphink: Make sure that the stuff is installed in debian/tmp!
[06:19] <raphink> I'd have to know what is appropriate and what is not I guess
[06:20] <dholbach> Gloubiboulga: you can "add attachment" or something on the bug - if you put the patch there, that'd be great
[06:20] <hunger> raphink: Well, does it have man pages?
[06:20] <raphink> nope hunger, only an html manual
[06:20] <Gloubiboulga> ok dholbach
[06:21] <hunger> raphink So you don't need dh_installman;-)
[06:21] <hunger> raphink: Read the docs.
[06:21] <Gloubiboulga> btw, I've sent a package on revu (my first "official" package)
[06:28] <Gloubiboulga> dholbach, the bug report should be done on malone, right ?
[06:28] <Gloubiboulga> can't see any "add attachment"
[06:31] <dholbach> Gloubiboulga: "+ Add Attachment" - right hand side
[06:31] <dholbach> Gloubiboulga: if you opened a bug
[06:33] <Gloubiboulga> :( I have to buy new eyes
[06:36] <toma> evening!
[06:37] <toma> my application just entered debian unstable, will it go automatically into dapper in that case?
[06:38] <dholbach> toma: in the next days it should
[06:38] <toma> dholbach: ok, thanks.
[07:09] <dholbach> Lathiat: new gnome-user-share :)
[08:24] <Kyral> New kernel sources!
[08:59] <dholbach> would it make sense to have a beagle-dev package?
[08:59] <dholbach> to split out "libbeagle" and the beagle*.pc files?
[08:59] <dholbach> i have a package which would build-depend on beagle
[08:59] <dholbach> i'd rather like it to be just beagle-dev to build-dep on
[09:00] <dholbach> mono team, anyone?
[09:03] <herve> hello
[09:07] <dholbach> hellas herve
[09:07] <raphink> yop herve
[09:07] <herve> raphik, I knew you were French :-)
[09:08] <raphink> how so herve ?
[09:08] <herve> the "yop"
[09:08] <minghua> dholbach: I'm back
[09:08] <raphink> lol
[09:08] <dholbach> tseng: where do i get libbeagle-0.0.pc?
[09:08] <raphink> bon j'aurais pu dire plop ;)
[09:08] <dholbach> minghua: hey
[09:09] <minghua> dholbach: the first thing you should ask is if they use 3rd-party apps, i.e. Debian #323216
[09:09] <minghua> dholbach: I've heard about other reasons for crash, but I can't pinpoint it yet
[09:10] <dholbach> ah right, will do that
[09:10] <dholbach> they could strace their app or debug it otherwise
[09:11] <dholbach> minghua: thanks, will do that
[09:26] <bmonty_laptop> \sh: I think I have the bzr stuff setup correctly, check out http://www.montynet.org/bzr/motu-tools
[09:28] <\sh> bmonty_laptop: merged and pushing the merges to tiber
[09:28] <\sh> thx :)
[09:28] <bmonty_laptop> \sh: so I managed to use bzr correctly :)
[09:29] <\sh> bmonty_laptop: and it wasn't difficult :)
[09:29] <bmonty_laptop> nope
[09:35] <Kyral> I still need to get around to merging stuff
[09:38] <whiprush_> dholbach: thanks for the deskbar-applet love!
[09:39] <dholbach> :-)
[09:41] <\sh> hmmmm
[09:41] <\sh> any objections to update to dapper?
[09:41] <Kyral> You aren't on it?
[09:41] <\sh> no...why should i?
[09:41] <Kyral> Dunno
[09:42] <Kyral> I dist-upgraded the first day
[09:43] <\sh> so lets go on the nc6000 first
[09:46] <siretart> \sh: I forgot to tell you yesterday, I hacked a bit on options checking, please merge my motu-tools branch
[09:47] <\sh> done
[09:49] <bmonty_laptop> \sh: now all we have to do is add a debian dir and make it a package
[09:49] <bmonty_laptop> how can I sign an already created changes file?
[09:49] <\sh> bmonty_laptop: debsign?
[09:50] <bmonty_laptop> thanks
[09:50] <\sh> bmonty_laptop: no..wait for my UI interface :)
[09:50] <bmonty_laptop> \sh: oh yeah...I'm looking forward to it
[10:04] <markuman> hey masters: http://home.arcor.de/sip85/00009.jpg :-D
[10:06] <herve> markuman, where's the caption? :-)
[10:06] <siretart> nice
[10:06] <dholbach> markuman: who are those guys? can you give names?
[10:07] <dholbach> i just know one of them :)
[10:07] <markuman> dholbach: you know smurf :-)
[10:08] <dholbach> yeah
[10:08] <markuman> it is from the german ubuntu club/association. it was founding last weekend
[10:09] <dholbach> can you give names of the different people?
[10:10] <markuman> dholbach: ehm, yes. but i think no one knows the names. i know there nick names in irc and some realnames
[10:10] <dholbach> fire away
[10:10] <raphink> guys I might be dumb but I browsed the whole debian maintainer's guide and have found no answer to my pb :(
[10:10] <dholbach> raphink: what problem is it?
[10:11] <raphink> dholbach: I'd like to package Kim, which is a collection of bash sccript
[10:11] <raphink> script
[10:11] <raphink> the "source" package contains an install.sh script that tells where each script has to go
[10:11] <raphink> but I don't know how I should turn that into a deb package
[10:11] <raphink> :s
[10:12] <dholbach> raphink: i suggest you take a look at *very simple* python packages, which just install a bunch of files to wherever they should be
[10:12] <raphink> if I should create a Makefile (and I don't know how to do that) or use debian/rules
[10:12] <herve> erm
[10:12] <raphink> dholbach: well I've packaged two programs already
[10:12] <herve> most python packages use setup.py
[10:13] <herve> like mine (to be reviewed *hint* *hint)
[10:13] <raphink> but I think kim is a nice set of scripts and I'd like to have it packaged
[10:13] <dholbach> herve: most python packages' setup.py is unusable :)
[10:13] <herve> raphink, then you know about debian/rules?
[10:13] <raphink> sure herve
[10:13] <raphink> herve: it's not my first package
[10:13] <herve> dholbach, I bet mine isn't ;-)
[10:13] <raphink> but I am very very far from mastering packaging ;)
[10:14] <herve> raphink, then it's just a matter of call ./install.sh with the right prefix, no?
[10:14] <Tonio_> raphink: you're gonna have the same mentor than me ??? ^_^
[10:14] <raphink> herve: well the thing is that the install.sh script calls kdialog with dcop and I don't wna that in a package
[10:14] <herve> Tonio_, you know Dinofly?
[10:14] <raphink> Tonio_: herve is your mentor?
[10:14] <herve> raphink, ho GUI installer?
[10:15] <Tonio_> raphink: dholbach is
[10:15] <Tonio_> herve: dinofly ? yes, very good friend of mine
[10:15] <markuman> dholbach: from right, its mitsuhiko (armin - i think he will listen now *g*) one of the http://www.ubuntuusers.de admin. next to him SS2, daboo, elys, smurf. littlepaul, jrg and juliux, juliux has made the ubuntu banner with mpathy. the banner was build for the linux day in essen (ger) on 3./4.12.05.
[10:15] <herve> Tonio_, I was in school with him :-)
[10:15] <mitsuhiko> :-)
[10:15] <markuman> *g*
[10:15] <raphink> herve: well basically, the install.sh script asks for an install option with kdialog and then installs using basic bash commands
[10:15] <Tonio_> herve: arf
[10:15] <mitsuhiko> hi dholbach :)
[10:15] <Tonio_> herve: how did you gess ?
[10:16] <dholbach> mitsuhiko, markuman: well done guys... you rock
[10:16] <raphink> herve: I could use the bash commands in this script though, but I don't know where to put them
[10:16] <herve> Tonio_, the whois
[10:16] <Tonio_> s/gess/guess
[10:16] <Tonio_> herve: ah okay ;) logic ^^
[10:16] <thesaltydog> hi all
[10:16] <herve> raphink, then you have to write your installer from debian/rules...
[10:16] <raphink> I don't know how herve ...
[10:16] <herve> hi
[10:16] <raphink> I wish I knwe
[10:17] <raphink> herve: the first problem is that there is no Makefile and dpkg-buildpackage will give me an error because of this
[10:17] <herve> what is the installer doing, just copying nO?
[10:17] <raphink> yes herve
[10:17] <herve> I don't see why dpkg-buildpackage would complain
[10:17] <Tonio_> raphink: the easier way is to use cdbs
[10:17] <raphink> well it says it can't build herve
[10:17] <herve> unless you took a rules from another package assuming there is a Makefile to call :-)
[10:17] <raphink> Tonio_: is that _really_ easier?
[10:18] <Tonio_> and simply add cp and chmod commands in an "install\package::" section
[10:18] <thesaltydog> Often I need to test build on a debian/unstable pbuilder environment, and then back to ubuntu. Is there a way to keep 2 separate settings for pbuilder?
[10:18] <Tonio_> raphink: cdbs ? yes, much easier
[10:18] <herve> raphink, it's just about copying in the temp directory, no?
[10:18] <raphink> yes herve I guess
[10:18] <Tonio_> the only problem with cdbs is that you have to learn the solution for each problem
[10:19] <raphink> that's the only thing to be done
[10:19] <Tonio_> "how to perform this"
[10:19] <Tonio_> but once you know it..... really easier
[10:19] <raphink> Tonio_: I think I'dlike to learn it the traditional way first
[10:19] <herve> raphink, you could ask upstream to split up the installer utility from the GUI, so you and other maintainers can reuse the installer
[10:19] <Tonio_> a cdbs rules file is generally between 256 and 512 bytes
[10:19] <Tonio_> not more
[10:20] <raphink> mhm
[10:20] <herve> raphink, check also if this software is packaged in other distributions and how they do it
[10:20] <Tonio_> I personnaly learned cdbs directly.... it hasn't been easy, but I don't regret it
[10:20] <raphink> I don't think it's packaged herve
[10:20] <raphink> I'll hav a look
[10:20] <raphink> hmm
[10:21] <raphink> there are packages for mandriva and sue
[10:21] <raphink> suse
[10:21] <raphink> :)
[10:21] <raphink> would that help ?
[10:21] <Tonio_> raphink: nope.....
[10:21] <raphink> it doesn't work the same way I guess
[10:21] <raphink> hmm
[10:21] <bmonty_laptop> any MOTU: please look at Malone 4443
[10:21] <Ubugtu> Error: Could not parse XML returned by Malone bugzilla: Connection to Malone bugzilla failed: HTTP Error 404: Not Found
[10:21] <raphink> if I run alien on the rpm, do you think it can give me a hint?
[10:22] <raphink> *barbarian way*
[10:22] <Tonio_> raphink: nope
[10:22] <raphink> k
[10:22] <herve> raphink, yes, you could see how their build scripts and what files they copy
[10:22] <raphink> :(
[10:22] <Tonio_> because you will not have any information required by a valid source package
[10:22] <raphink> how do I open an rpm ?
[10:22] <Tonio_> and anyway you will miss the debian folder structure
[10:23] <raphink> yes Tonio_ but i can see how they deal with the scripts
[10:23] <sivang> dholbach: I see https://wiki.ubuntu.com/FormalTestPlans is not updated with what we worked on during UBZ, is it on another page?
[10:23] <herve> raphink, use midnight commander :-)
[10:23] <dholbach> sivang: it's linked from it
[10:23] <raphink> argh
[10:23] <Tonio_> raphink: is your package a collection of python scripts, or bashscripts ?
[10:23] <raphink> bash Tonio_
[10:24] <Tonio_> raphink: there are lots of packages that are scripts colletction
[10:24] <raphink> like what?
[10:24] <Tonio_> debuild is a script
[10:24] <Tonio_> it is installed by a package
[10:24] <raphink> mhm
[10:24] <Tonio_> so you may found the way to proceed looking at one of those sources packages
[10:25] <raphink> I'll look at devscript
[10:25] <herve> yes but the installer is probably less awkward :-)
[10:26] <raphink> lets see
[10:26] <Tonio_> raphink: look at the devscripts source package
[10:26] <Tonio_> that might help
[10:26] <raphink> taht's what I'm doing Tonio_
[10:26] <Tonio_> sorry, didn't read before writing ;)
[10:26] <raphink> hehe
[10:27] <raphink> that's the idea I had origially
[10:27] <raphink> they use postinst and postrm
[10:27] <raphink> ;)
[10:29] <raphink> there is nothing special in debian/rules
[10:29] <raphink> they seem to install all scripts with postinst and postrm
[10:30] <raphink> so they don't use debian/temp either
[10:31] <herve> strange...
[10:31] <raphink> heh
[10:31] <raphink> if they do it, then I should do it too ;)
[10:31] <raphink> so just using what is in the install.sh
[10:31] <ogra> nope
[10:32] <raphink> ogra: what do you think ?
[10:32] <ogra> the packaging system doesnt know anything about files you install via postinst
[10:32] <raphink> yes ogra
[10:32] <ogra> you could give your users a tgz with the same effect
[10:32] <raphink> still that's the option that was chosen for devscripts
[10:33] <raphink> sure ogra, the difference is that a tgz can't be found in the apt-get db, installed and upgraded
[10:33] <ogra> might be, but if you want to have dpkg -S or apt-file working with it, you should install them from the package not from the config scripts
[10:33] <raphink> surely this package won't be much more than a tgz since there's nothing to build anyway
[10:33] <raphink> hmm
[10:33] <raphink> I don't know how to do that ogra
[10:33] <ogra> its not *that* hard :)
[10:34] <raphink> when you know how to do I'm sure it's not hard ;)
[10:34] <ogra> http://people.ubuntu.com/~ogra/bzr-archive/student-control-panel-0.1/ i just uploaded this source, the debian/rules simply copy stuff into place... its all scripts and png's
[10:35] <ogra> but the packaging system will know about every single file in there ...
[10:36] <ogra> in case someone puts a script with the same name like yours in his package and it has the same path your stuff will simply get overwritten...
[10:36] <raphink> yes I understand that
[10:36] <raphink> so what shall I use
[10:36] <raphink> what is the specificity of your debian/rules
[10:36] <ogra> make it a real package
[10:36] <raphink> or what do you use in addition to it
[10:36] <raphink> ?
[10:36] <ogra> there is none ...
[10:37] <ogra> the files and dirs get listed in the student-control-panel.dirs and student-control-panel.install files
[10:37] <raphink> ok
[10:38] <ogra> dh_install in the rules file just move the files into place
[10:38] <raphink> you basically list the files and for each file you tell where they have to go in the system, right?
[10:38] <ogra> exactly ...
[10:38] <raphink> ok
[10:38] <ogra> and i removed all make related stuff from the rules file
[10:38] <raphink> so if the scripts of the kim package are in bin
[10:38] <raphink> I should have things like
[10:38] <raphink> bin/*.sh /usr/share/wherevertheyhavetogo/
[10:39] <raphink> in the kim.install
[10:39] <ogra> yup
[10:39] <raphink> ok
[10:39] <raphink> see this is simple
[10:39] <ogra> yup :)
[10:39] <ogra> and way less evil ;)
[10:39] <raphink> but I found _no_ mention of this in the debian maintainer's guide
[10:40] <ogra> the only thing you need to know is that rules is a makefile ... it can do everything a makefile can ... even simple cp or mv commands ...
[10:40] <ogra> then only make lintian/linda happy and you have basically a good package
[10:41] <raphink> yes
[10:41] <raphink> I'm learning
[10:41] <raphink> ;)
[10:41] <ogra> :)
[10:41] <sivang> ogra: but you better use dh_install for copying/moving files no?
[10:41] <ogra> sivang, yup
[10:41] <McFergus> !ftp
[10:41] <sivang> ogra: rather then doing it "manually" with cp, mv, or whatever..
[10:42] <McFergus> wrong window... sorry
[10:42] <ogra> always ude the debhelper scripts (or cdbs, as you like)
[10:42] <ogra> *use
[10:43] <sivang> ogra: feel free to ping me on that gnome-system-toosl change, I'm mostly busy during the day , but if I see someone pinging me on IRC, I tend to leave everything at work and attend to him :)
[10:43] <ogra> but there is no policy in debian that forbids 500 cp commands in debian/rules ... even if its darn ugly it schouldn't violate any debian policy
[10:43] <sivang> ah , I see.
[10:43] <sivang> good to know
[10:43] <ogra> sivang, i will, im currently more busy on low level ltsp stuff...
[10:44] <sivang> ogra: sure, I just wanted you to feel free :)
[10:44] <ogra> it will still take some days before i get up to speed with other things
[10:44] <ogra> but we have sound in ltap :)
[10:44] <ogra> *ltsp
[10:44] <sivang> cool !
[10:45] <ogra> yup... out of the box, no configuration needed .... :)
[10:45] <sivang> amazing
[10:45] <sivang> through the device on-tcpip-loopback ?
[10:45] <ogra> now i just need to get the spec approved to be allowed to implement it officially *grin*
[10:45] <ogra> nope
[10:45] <sivang> ah...well, I suspect that wouldn't be too hard
[10:45] <ogra> very simple esound forwarding
[10:46] <sivang> ah, right! it's a damn network daemon!
[10:46] <sivang> :)
[10:46] <ogra> the intresting thing is that i get rather delays in the X output than choppy sound with it ...
[10:47] <ogra> it had expected it the other way around
[10:47] <sivang> well, sound is easier to deliver AFAICT
[10:47] <sivang> less traffic
[10:47] <sivang> then visual stuff
[10:47] <bmonty_laptop> \sh: can we add an auto-email elmo feature to the sync request part of lpbugs?
[10:47] <ogra> bmonty_laptop, better ask this to elmo first :)
[10:48] <bmonty_laptop> ogra: I'm trying to be a little sarcastic, but it would be nice ;)
[10:49] <ogra> i think he doesnt care if the requests come from a lp feature, but i doubt he likes to be the guinea peg while it gets developed ;)
[10:49] <ogra> s/peg/pig/
[10:49] <ogra> the idea isnt bad :)
[10:49] <bmonty_laptop> I wonder if he has a special address for sync requests
[10:50] <raphink> ogra: the install.sh script I have uses kim*.desktop $kdeinstdir/share/apps/konqueror/servicemenus/
[10:50] <raphink> shall I keep the $kdeinstdir variable or replace it ?
[10:50] <bmonty_laptop> maybe we could have it build the command line for whatever tool he uses to do syncs and then he could just cut and paste to a shell
[10:51] <ogra> depends, is there such a variable in the system if kde is installed ? (gnome here)
[10:51] <raphink> hmm
[10:51] <raphink> how do I know that ?
[10:51] <raphink> echo $kdeinstdir ?
[10:51] <ogra> yup
[10:51] <ogra> but i doubt it ...
[10:52] <raphink> well there is no such a variable
[10:52] <raphink> but the install script worked on my system though
[10:52] <raphink> ...
[10:52] <raphink> doh!
[10:52] <raphink> the variable is set a few lines before ;)
[10:52] <raphink> hehe sorry ;)
[10:52] <ogra> dont worry
[10:52] <ogra> its usually /usr
[10:52] <raphink> kde-config --prefix
[10:53] <raphink> that's how they get it
[10:53] <raphink> is it worth it that I get it this way somewhere?
[10:53] <raphink> or shall I just use /usr ?
[10:53] <ogra> since the kde paths wont just randomly change in kubuntu i think its safe to assume it stays /usr for some time :)
[10:54] <raphink> ok
[10:54] <raphink> then is there a way I can set the chmod in the .install ?
[10:55] <raphink> since the install.sh script sets the chmod
[10:55] <raphink> is there a way I can do it cleanly within the .install maybe ?
[10:56] <ogra> dh_fixperms shoudl care for that
[10:56] <raphink> ok
[10:57] <raphink> and I guess mkdir should go to the .dirs :)
[10:57] <ogra> yup
[10:57] <raphink> simple :)
[10:57] <ogra> yep :=
[10:57] <ogra> )
[10:57] <raphink> all cp to .install and all mkdir to .dirs :)
[10:58] <ogra> exactly
[10:58] <raphink> ok next issue is with this :
[10:58] <raphink>  cd $kdeinstdir/share/apps/konqueror/servicemenus/
[10:58] <raphink>                 mv imageconverter.desktop imageconverter.desktop~
[10:58] <raphink>                 mv jpegorient.desktop jpegorient.desktop~
[10:58] <raphink> I'm not sure this should be kept
[10:58] <raphink> this turns some services down
[10:58] <raphink> since kim services replace them
[10:59] <raphink> :s
[10:59] <ogra> they are most likely in another package... its evil to move files from other packages :)
[10:59] <raphink> yes
[11:00] <raphink> but then there's gonna be two converters in the menus in konqueror
[11:00] <raphink> which is why kim removes them
[11:00] <raphink> let's see what package they come with :)
[11:01] <raphink> ok they come with konq-plugins
[11:01] <raphink> no surprise
[11:01] <raphink> is there a way I can have the same result cleanly ogra ?
[11:01] <raphink> or should I not touch it at all?
[11:01] <ogra> have a look at dpkg-divert's manpage :)
[11:02] <raphink> hmm ok
[11:04] <ogra> btw, that is something for postinst/postrm :)
[11:04] <raphink> ic
[11:05] <raphink> so in postinst I should ust dpkg-divert
[11:05] <raphink> to rename imageconverter.desktop to imageconverter.desktop
[11:05] <raphink> sorry with ~
[11:05] <ogra> yup
[11:05] <raphink> and in postrm it sould remove the diversion
[11:05] <raphink> logically
[11:05] <ogra> so the packaging system (and thus the konqueror package) know about it
[11:06] <raphink> yes
[11:06] <ogra> yup
[11:18] <allee> raphink: FWIW: in case you don't hardcode the path use: kde-config --expandvars --install data   +  /konqueror/servicemenus (and report upstream ;)
[11:18] <\sh> going to bed...
[11:19] <allee> \sh: nite
[11:19] <raphink> I'll hardcore the path I think
[11:19] <allee> raphink: that's a pretty save choice
[11:20] <raphink> ;)
[11:24] <janimo> hey
[11:24] <raphink> ok should do it now
[11:24] <janimo> if a package upload gor REJECTED, subsequent uploads need special care to enter buildd?
[11:25] <janimo> if I keep the same version
[11:25] <allee> raphink: the french desktop file with accent problems: does it contain an Encoding=<whatever>  and is the french trans in this encoding?
[11:25] <janimo> do buildds run about twice an hour?
[11:25] <bmonty_laptop> janimo: I think you have to bump the version, at least that is what crimsun had to for a package we were working on
[11:26] <janimo> ok thanks
[11:26] <raphink> no idea allee
[11:26] <janimo> but it made it to the changes-list
[11:26] <janimo> hmm I'll ask on devel
[11:26] <allee> raphink: which desktop file?
[11:27] <raphink> what are you talking about allee ?
[11:28] <herve> night all
[11:28] <allee> raphink: oh sorry your comment on kim on kde-apps.org (or is it solved?)
[11:28] <raphink> I'm done packaging kim allee
[11:28] <raphink> haven't tested it yet
[11:28] <raphink> oh I see what you mean
[11:29] <raphink> yes it's me who put a comment on the accent issue
[11:29] <raphink> sorry I wasn't following you ;)
[11:29] <allee> raphink: my fault
[11:29] <raphink> it's ok
[11:29] <raphink> hmm wait a min
[11:29] <raphink> I'll just test the package
[11:30] <raphink> then look at your option to solve this
[11:34] <sivang> night all
[11:35] <bmonty_laptop> bye sivang
[11:37] <raphink> yeah :D
[11:37] <raphink> now tell me about your suggestion allee
[11:37] <raphink> :)
[11:38] <bmonty_laptop> hi LaserJock
[11:39] <allee> raphink: every desktop file can spezify it's encoding with a Encoding=<whatever> with whatever usually being UFT-8
[11:39] <raphink> mhm
[11:39] <LaserJock> bmonty_laptop: looks like you've been busy
[11:40] <raphink> allee: there is no such entry in the .desktop files indeed
[11:40] <bmonty_laptop> I've looked at a couple of packages :)
[11:40] <allee> raphink: grep other service type .desktops for examples
[11:41] <raphink> ok
[11:41] <raphink> I'll have a look
[11:41] <raphink> thanks
[11:42] <raphink> allee: shall I report that to the upstream author?
[11:43] <allee> raphink: yes and maybe s/Gig/Gif/ and in english there no space before
[11:43] <allee> '1' afaik
[11:43] <allee> s/'1'/'!'/
[11:43] <raphink> ok
[11:44] <raphink> hmm
[11:44] <raphink> shall I correct it in my package and tell the upstream author at the same time
[11:44] <raphink> or should he fix it before and then I package the patched version?
[11:44] <raphink> :s
[11:45] <allee> raphink: depends on you.  If it's cosmetics this IMHO okay to just report and wait.  If it a real bug, fix it (or ask upstream) and incorporate it into you pkgs
[11:45] <raphink> well it's just cosmetics I thin
[11:45] <raphink> think
[11:45] <allee> raphink: upstream if always happy of course if you the gets patches ;)
[11:46] <allee> yes
[11:46] <raphink> so just report the bug and wait
[11:46] <raphink> I mean telling him what has to be changed
[11:47] <tseng> dholbach: beagle.
[11:47] <raphink> ;)
[11:47] <allee> raphink: he will be delighted ;)
[11:47] <raphink> hehe
[11:48] <raphink> I'll do that as soon as I'm done updating my repo
[11:48] <dholbach> tseng: hm, doesnt seem to be shipped then
[11:48] <tseng> maybe not
[11:49] <dholbach> tseng: no libbeagle love
[11:49] <tseng> there are regressions from the debian version
[11:49] <dholbach> tseng: i see
[11:49] <tseng> i have the so's
[11:49] <tseng> but no pc
[11:49] <allee> raphink: all scripts use #!/bin/sh.  Maybe check if there's no bashism??
[11:49] <dholbach> maybe it will be shipped in the new version
[11:49] <raphink> there is allee I think
[11:49] <tseng> maybe.
[11:49] <allee> if [ ! -d /tmp/kim ] ; then
[11:49] <allee>     mkdir $TMPDIR;
[11:49] <raphink> it's matter of encoding as you said
[11:50] <allee> raphink: is also no good idea.
[11:50] <raphink> hmm ok
[11:50] <raphink> well hmm I'm not sure I grasp all you would report and why
[11:50] <raphink> would you report it yourself ?
[11:51] <allee> 'k
[11:51] <dholbach> tseng: how are you?
[11:51] <tseng> i am ok, you?
[11:51] <raphink> thanks a lot allee :)
[11:52] <dholbach> tseng: a bit tired, but ok, thank you :)
[11:52] <tseng> good
[11:52] <raphink> btw allee the pb is not exactly about declaring the encoding, but the `plugins' scripts are not typed as utf-8
[11:52] <dholbach> Tonio_: uploaded
[11:52] <raphink> that's why it doesn't work
[11:59] <allee> raphink: oh, oh, lots of hardcoded /tmp filename
[11:59] <raphink> where?
[12:00] <allee> grep /tmp bin/*
[12:00] <raphink> how should it be coded?
[12:01] <raphink> allee: how should it be coded instead?
[12:01] <allee> raphink: e.g. using mktemp(1)
[12:01] <raphink> ok
[12:01] <Tonio_> dholbach: ? uploaded ?
[12:01] <dholbach> Tonio_: pwmanager?
[12:01] <allee> or you user private KDE dir in tmp
[12:01] <Tonio_> dholbach: ah okay ;)
[12:02] <allee> s/you/use/
[12:02] <raphink> I'm not a coder allee so I don't know much about that yet ;)
[12:02] <raphink> ic allee
[12:02] <raphink> allee: the pb is that it might make conflicts with other apps, right?