[08:11] <poolie> stub, lifeless, is there any facility in launchpad at the moment for configuration that can be changed by sysadmins?
[08:11] <poolie> in particular if i want a list of trusted dkim domains
[08:11] <poolie> or a switch to turn dkim on/off
[08:11] <lifeless> yes
[08:11] <lifeless> the config files
[08:11] <poolie> ok
[08:11] <lifeless> they have settings for dev, staging, edge, production
[08:39] <lifeless> hm
[08:39] <lifeless> oops
[08:53] <james_w> anyone around who knows the job system and can provide some advice?
[08:54] <james_w> I would like to know the preferred way to implement a new job
[08:54] <james_w> Whether a fairly generic job with json, implying serialising some things to strings to lookup as keys when the job is run, or a more-specific job type that can have References to the other models, saving that serialisation step, would be preferred.
[08:55] <poolie> hi james_w
[08:55] <poolie> unfortunately i don't know about that
[08:56] <james_w> hi poolie
[09:21] <mrevell> Morning
[09:25] <james_w> BjornT: hi, do you have an opinion on whether a new job type should use as many References as possible, or serialise to JSON and look up the objects again based on keys in the JSON?
[09:28] <lifeless> james_w: hi
[09:28] <lifeless> james_w: I'm not sure there is a general answer to that question
[09:28] <james_w> hi lifeless
[09:28] <lifeless> james_w: I'd consider things like:
[09:29] <lifeless>  - are there security implications on any referenced tables
[09:29] <james_w> I'm happy to give specifics
[09:29] <lifeless>  - are there performance implications ...
[09:29] <lifeless>  - what would be simplest for your code
[09:29] <lifeless>  - are there race conditions - do you need to freeze parameters so they don't change under you
[09:30] <lifeless> james_w: sure, though I'm signing off - 4am rise tomorrow - shortly
[09:30] <lifeless> james_w: oh and obviously the inverse of the previous one, do you have parameters that *have* to be fresh
[09:32] <james_w> g'night
[10:01] <thumper> james_w: hi
[10:01] <thumper> james_w: what are you looking to do?
[10:01] <james_w> hi thumper
[10:02] <james_w> I want to create a job type for the creation of copy archives
[10:02] <james_w> these have a source archive, target archive, source distroseries, source packagesets, source component, etc.
[10:02] <thumper> james_w: what we did for BranchJob was to just have the branch that it was linked to, and everything else in a json blob
[10:03] <thumper> the general idea is:
[10:03] <james_w> an ArchiveJob to parallel BugJub and BranchJob would be useful elsewhere, but there is far more linked data here than in any of the other jobs
[10:03] <thumper> if you need to query against the value, it needs to be a column
[10:03] <thumper> otherwise a blob is fine
[10:03] <thumper> james_w: the question relates to what you end up querying against
[10:03] <thumper> and what the job really links to
[10:04] <thumper> and how it needs to be selected...
[10:04] <thumper> what invalidates the job...
[10:04] <thumper> how it will be deleted...
[10:04] <james_w> just target archive needs to be queried against I think
[10:05] <thumper> what other jobs will there be for archives?
[10:05] <james_w> don't know yet
[10:06] <james_w> there are a bunch of things that could be possible to have there, bulk copying packages, even publication
[10:06] <thumper> but it is likely that there will be more?
[10:06] <thumper> I'd suggest make a mirror of the branch job table for now
[10:06] <thumper> although I hate myself for saying it...
[10:07] <thumper> the duplication rubs me the wrong way
[10:07] <thumper> but is the best we have for now
[10:07] <thumper> but instead of a branch reference, have the archive
[10:07] <james_w> there's a hell of a lot of boilerplate to create a new job type
[10:07] <thumper> I wouldn't say there is that much...
[10:07] <thumper> a lot has been moved into base classes
[10:07] <thumper> but yes,
[10:07] <thumper> there will be duplication and boilerplate
[10:08] <james_w> https://dev.launchpad.net/Foundations/JobSystem
[10:08]  * thumper isn't working :) just helping
[10:08] <thumper> I'm in Perth having a holiday
[10:08] <james_w> well, thanks :-)
[10:09] <thumper> but as you can see, I have my laptop :)
[10:10] <thumper> can't go on holiday without it, well, not for more than a few days
[10:10] <thumper> I need my fix
[11:01] <deryck> Morning, all.
[11:21] <maxb> In relation to the just-gone discussion in #launchpad, maybe we should have uses_soyuz and uses_lp_distromirrors attributes on distributions?
[11:39] <wgrant> maxb: We already have IDistribution.full_functionality
[11:39] <wgrant> Currently a celebrity-based hack, but it works.
[11:41] <jml> maxb, or even IDistribution.build_system :)
[11:42] <bigjools> ICanHazBuilds
[11:42] <wgrant> But even just hiding series that don't have any PPA-capable DASes would be a good start.
[11:44] <bigjools> wgrant: BTW did you notice that we got the first successful recipe build done in prod yesterday?
[11:45] <wgrant> bigjools: I saw some bugs fly past that suggested it.
[11:45] <wgrant> Is this after chmoding the source dir on cesium?
[11:45] <bigjools> no, fixing the init script for the b-m
[11:45] <wgrant> Ah.
[11:45] <bigjools> which had an interesting "cd" in it
[11:45] <bigjools> so, part of this success is down to you, thanks a lot man :)
[11:46] <wgrant> I'm glad it's finally running.
[11:46] <wgrant> A few months later than I expected, but.....
[11:57] <wgrant> mrevell: The PPA terms of use state that anything OK for Ubuntu is OK.
[11:58] <wgrant> And just about anything redistributable is OK for Ubuntu.
[12:00] <mrevell> wgrant, Thanks for that. I'm not saying you're wrong but that's not how we've enforced it before. For example, we nearly closed a PPA a year or two back that had the flash installer in it but the owner reworked it.
[12:00] <wgrant> Right, it seems like it's wrong, but it seems to be what the terms of use say.
[12:01] <wgrant> Hmm.
[12:02] <wgrant> bigjools: The bzr-builder PPA doesn't also have a modern bzr in it?
[12:02] <bigjools> is that a question or a statement?
[12:02] <wgrant> I just tried a Hardy build, and it seems to be using real Hardy bzr.
[12:02] <wgrant> I didn't even know bzr-builder would work with something so old.
[12:03] <bigjools> the production system doesn't use a PPA for the bzr-builder dep
[12:03] <wgrant> Oh, bzr-builder is in -updates?
[12:03] <bigjools> no, there's an internal archive
[12:03] <wgrant> Ah, right.
[12:03] <mrevell> wgrant, Thanks for raising that. As ever, you're the guy who keeps me on the right track :) I'll review the terms and how we enforce them.
[12:03] <wgrant> s/bzr-builder PPA/internal archive/
[12:04] <bigjools> heh - no idea
[12:04] <bigjools> I'll let abentley chase that one up
[12:05] <james_w> wgrant: bzr-builder doesn't do anything particularly interesting with bzrlib, just equivalents of branch and merge, which have been around for ever.
[12:06] <wgrant> Ah.
[12:16] <wgrant> james_w: http://launchpadlibrarian.net/50794525/buildlog.txt.gz <- do I need to backport python-debian too?
[12:16] <james_w> wgrant: quite possibly
[12:17] <james_w> we could perhaps fix it in bzr-builder
[12:31] <wgrant> Is the PPA publisher working? I copied a package about 12 minutes ago -- it's still Pending.
[12:32] <wgrant> Ah, there.
[12:32] <wgrant> Looks like it missed two runs.
[14:04] <james_w> how do I get the key for a enum item?
[14:04] <james_w> I want to store something that I can use to get that enum value back
[14:05] <james_w> .value?
[15:52] <jml> james_w, have you figured it out yet?
[15:52] <james_w> no
[15:52] <james_w> yes
[15:53] <jml> james_w, cool. :)
[15:53] <jml> sorry for not trying to answer earlier.
[15:53] <james_w> PackagePublishingPocket.items[PackagePublishingPocket.RELEASE.value] I think
[15:54] <james_w> just waiting for my tests to confirm
[15:54] <james_w> yes
[16:23] <james_w> which layer should I use for a test class that will just be using the db (and possibly librarian), but doesn't care about the web ui and stuff?
[16:23] <james_w> is LaunchpadZopelessLayer just for script tests?
[17:07] <james_w> bigjools: do you have a problem with PackageCloner creating build records for the packages it copies too? Currently it just copies sources and the builds are created elsewhere. I would like to consolidate for ease of testing.
[17:08] <bigjools> james_w: remind me where they're created at the moment?
[17:08] <james_w> scripts/populate_archive.py
[17:08] <bigjools> urgh
[17:08] <bigjools> yeah change it
[18:22] <jml> I'm getting an error trying to build gettextpo
[18:22] <jml> it's the first time I've tried to build lp in a few months, so I might have missed some obvious / crucial step
[18:22] <jml> http://paste.ubuntu.com/454033/
[18:26] <jml> help?
[18:30] <dobey> anyone know why the merge proposal diffs aren't updating in launchpad, and it's not sending the mails for proposal status changes?
[18:32] <jml> dobey, no, I don't, but I saw abentley say something vaguely operational about it on another channel
[18:33] <abentley> dobey, no, at this point it's just under investigation.
[18:33] <james_w> jml: that's odd, if pydoc was failing it would normally say "Error" before "Leaving directory" I think
[18:34] <dobey> abentley: ok, thanks
[18:34] <james_w> that's probably the last step either way, so that doesn't tell you whether it failed
[18:35] <james_w> if you are using parallel make then the actual error can be further back
[18:35] <jml> james_w, how would I know if I'm using parallel make?
[18:36] <james_w> I don't know, apart from it doing more than one thing at once
[18:36] <james_w> if there's no error before it starts printing pygettextpo stuff then you probably aren't
[18:36] <james_w> I don't think it's default for LP, so unless you ran "make -j"...
[18:37] <jml> hm.
[18:37] <jml> oh, I missed a tb
[18:37] <jml> http://paste.ubuntu.com/454037/
[18:44] <jml> oh huh
[18:44] <jml> I think I have a local copy of Python
[18:51] <jml> If I want to add some tests for bugtask, should I add them to test_bugtask.py, test_bugtask_0.py or test_bugtask_1.py?+
[18:54] <james_w> heh
[18:55] <james_w> probably make test_bugtask_jml.py?
[18:55] <jml> james_w, maybe I should use the database id for my row in Launchpad to avoid confusion
[18:56] <jml> deryck, If I want to add some tests for bugtask, should I add them to test_bugtask.py, test_bugtask_0.py or test_bugtask_1.py?
[19:01] <deryck> jml, I don't know.  Let me look more after the call.
[19:01] <jml> deryck, thanks.
[19:11] <james_w> gah, IPackagesetSet has a get method that works different to all the other get methods I have come across
[19:11] <jml> yeah. we need some consistency.
[19:18] <james_w> are there any scripts in LP that would be run by an admin and just create a job for later processing? Would we want such a script to create the job but synchronously process it? Or just do the work and leave the job for webservice requests?
[19:24] <jml> james_w, I'm not sure what you mean.
[19:24] <james_w> populate_archive.py currently creates a copy archive and sits there while everything is copied
[19:25] <james_w> I'm working on making copy archive creation a job such that we can do it over the API and the like if we wish
[19:25] <james_w> I'm wondering if I should:
[19:25] <james_w> a) have the populate_archive.py script create the job and exit, leaving it up to a cronscript to do the work and the person running the script to poll the web ui to find when it is done
[19:26] <james_w> b) have the populate_archive.py create the job, but pre-claimed, and then kick off the running of the job synchronously such that it can report the results to the admin running the script
[19:27] <james_w> c) have populate_archive.py ignore the job system and just run the code in pretty much the way it is now, and just have the job system as an alternative entry point
[19:27] <james_w> d) other
[19:27] <james_w> e) none of the above
[19:27] <james_w> 3) Uzbekistan in the 1920s
[19:33] <jml> james_w, sorry for the delay, I'm on a call that got interesting :)
[19:34] <james_w> np
[19:34] <james_w> it's an idle question as I hack the code to actually make any of this possible
[19:35] <jml> james_w, I don't know enough about what populate_archive.py does, I think. a) seems the most consistent
[19:35] <jml> and we should have a widget on the ui for tracking in-progress jobs
[19:36] <james_w> so populate_archive.py creates something like launchpad.net/~jml/+copy-archive/some-new-archive
[19:36] <james_w> then it spends a few minutes copying all the sources from Ubuntu in to it and creating build records so that you can testbuild a snapshot of Ubuntu
[19:37] <james_w> this is currently something that is usually done by an admin for doko
[19:37] <james_w> so I guess it's a question for the losas? they are the only ones that will use the populate_archive.py interface.
[19:38] <jml> james_w, yeah, maybe.
[19:38] <jml> james_w, now that you explain it though, I'm more inclined toward a)
[19:38] <james_w> Perhaps it will be changed to do an API call instead, in which case we can't really do synchronous, as we don't even have a way to poll for completion of this job
[19:39] <jml> james_w, although it's something of a regression in the UI of the script, we should just fix the webservice api so that the script can behave the way it did.
[19:39] <jml> james_w, after all, this isn't the only case where someone wants to run scripts that kick off long-running jobs.
[19:39] <james_w> yeah
[19:40] <jml> deryck, thanks for looking at the test_bugtask thing btw
[19:40] <james_w> jml: do you have any notes from your earlier call with Julian?
[19:41] <deryck> jml, yes, just back from coffee.  Looking now....
[19:43] <abentley> dobey, the script got stuck and we've restarted it.  Please let us know if you're still experiencing problems.
[19:43] <dobey> abentley: ok thanks
[19:43]  * dobey waits for a flood of e-mail
[19:51] <abentley> james_w, we do already have scripts that create jobs and let a cronjob handle running them.  e.g. the branch scanner.  Daily builds is similar, though it hands off to the build farm, not a cron script.
[19:52] <deryck> jml, so I think just use test_bugtask.
[19:52] <deryck> jml, the others seem like someone was thinking something that is not now clear :-)
[19:52] <jml> deryck, that had occurred to me :)
[19:52] <jml> deryck, thanks.
[19:52] <james_w> abentley: they are scripts run by admins?
[19:53] <abentley> james_w, they are normally run from cron scripts themselves.
[19:53] <abentley> Or as cron jobs, I should say.
[19:53] <james_w> abentley: right, this will only ever be run by hand on request
[19:53]  * deryck will make a note to confer and refactor test_bugtask* as appropriate
[20:06] <jml> 5 seconds to start the functional layer
[21:12] <jml> gary_poster, do you know by what mechanism the API documentation lists the possible choices for "hardware_bus" on https://edge.launchpad.net/+apidoc/devel.html#bug_target for searchTasks?
[21:14] <gary_poster> jml: no, but my guess would be by introspecting a vocabulary specified in an interface.  I could probably find out quickly.  Should I?
[21:14] <jml> gary_poster, yes please. I'm trying to figure out how it knows to introspect as well.
[21:15] <gary_poster> k
[21:25] <gary_poster> jml: it almost certainly introspects the Choice field on line 95 of lp/bugs/interfaces/bugtarget.py .  This in turn points to a vocabulary, which is apparently, per the comment, set to HWBus in ./canonical/launchpad/interfaces/_schema_circular_imports.py:165
[21:27] <james_w> lazr.restful.marshallers.SimpleVocabularyLookupFieldMarshaller knows how to iterate items on an enum to get the valid choices
[21:28] <jml> does that get used to generate the wadl
[21:28] <gary_poster> yes
[21:31] <jml> ok. thank you gary_poster & james_w
[21:31] <gary_poster> np
[21:42] <jml> actually, it looks like it's used to make the json, not the wadl
[21:49] <james_w> jml: http://paste.ubuntu.com/454134/
[21:49] <jml> james_w, thanks.
[21:58] <james_w> jml: in return any hints you could give me of how I would get a SourcePackagePublishingHistory given it's id would be greatly appreciated
[21:58] <james_w> there's no ISourcePackagePublishingHistorySet I can see
[21:58] <james_w> hmm, there's an IPublishingSet
[21:59] <jml> james_w, you can cheat & use storm. getUtility(ISomethingOrOther).find(SourcePackagePublishingHistory, SPPH.id=your_id).
[22:00] <james_w> jml: thanks, I'll resort to that if this doesn't work
[22:06] <james_w> getUtility(IPublishingSet).getByIdAndArchive() apparently. Though for some reason that returns you a ResultSet and you have to call .one() on it yourself.
[22:06] <jml> :(
[22:08] <jml> james_w, there's only one callsite for that, and no unit tests.
[22:08] <jml> (or doctests)
[22:09] <james_w> jml: are you suggesting I fix it up?
[22:09] <jml> james_w, I am. But I can completely understand if you'd rather not.
[22:10] <james_w> I'm already in the middle of a monster branch
[22:10] <james_w> so adding one more thing to it isn't going to hurt that much
[22:11] <james_w> hmm, my ec2 instances seem to be dying without mailing me
[22:11] <jml> james_w, good news and bad, even while I momentarily gaze away
[22:12] <jml> gary_poster, james_w, fwiw, I was working on https://bugs.edge.launchpad.net/lazr.restful/+bug/590561. Now I've stopped.
[22:12] <_mup_> Bug #590561: searchTasks API documentation doesn't document acceptable status arguments <lazr.restful:New> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/590561>
[22:12] <gary_poster> on call
[22:12] <jml> np. it's not urgent.
[22:12] <james_w> more fun: http://paste.ubuntu.com/454140/
[22:12] <james_w> oh, that one's my mistake
[22:13] <jml> james_w, nyah-ah-ah
[22:13] <jml> james_w, if they are dying without mailing, I'd recommend running them attached.
[22:14] <jml> james_w, there's no other way of guaranteeing you'll get output.
[22:15] <james_w> jml: just kicking that off now
[22:16] <jml> james_w, cool.
[22:17] <jml> james_w, I'm off now to find something to eat.
[22:18] <james_w> jml: enjoy
[22:18] <jml> james_w, and thence to not work.
[22:18] <jml> james_w, enjoy your evening


[00:02] <beuno> it's a bit late now, aint it?   :p
[00:04] <kiko> he was testing!!
[00:05] <beuno> sure, sure
[00:50] <Rinchen> I'm just always after a meeting
[00:53] <mwhudson> beuno: i dunno, it would be a fine time for a meeting for me :-)
[00:55] <beuno> mwhudson, Rinchen, well, ok, then let's have a meeting  :)
[00:56] <Rinchen> :-)
[00:56] <Rinchen> Apparently they didn't know mootbot wasn't listening
[00:56] <mwhudson> that's not _quite_ what i mean :)
[00:56] <Rinchen> so I was testing it for the scribes gent
[00:56] <Rinchen> he's going to fix it in the morning
[00:57] <Rinchen> I think we should pester Odd_Bloke to see how his PQM foo is doing these days :-)
[00:57] <beuno> Rinchen, what time is it over where you are anyway?
[00:57] <Rinchen> 18:00
[00:59] <Odd_Bloke> ZOMG ping.
[00:59] <beuno> Rinchen, hm, you seem to have a better time zone than me  :/
[00:59] <Odd_Bloke> My PQM foo is not yet started, it still being exam season. :)
[00:59] <Rinchen> lol
[01:00] <Odd_Bloke> My exams don't finish until the 19th of June, but I won't realistically get any hacking done until after the 30th.
[01:00] <Rinchen> ah well, I'm sure anything you can do to it will help
[01:00] <Rinchen> although, a few of us might pay to see it tortured.
[01:02] <Rinchen> slowly
[01:02] <mwhudson> i don't think we can blame the problems we have landing branches on pqm itself, sadly
[01:03] <Rinchen> test suite? we don't need no stinkin' test suite!
[01:07] <mwhudson> oh boy, that approach would make our current level of pain look like a bed of lavender :)
[01:08] <Rinchen> yeah, we'll just replace everything with test.py and call it good
[01:09] <Rinchen> oh wait, we use zope... darn
[01:09] <Rinchen> :-)


[00:32] <jbicha> darkxst: I merged your build script changes
[00:32] <jbicha> but it's disabling logout in indicator-session; we don't want to do that
[00:39] <darkxst> jbicha, let me check, maybe  I put the wrong 15autologin in there
[00:40] <darkxst> once I unbreak my system, due to your gdm mess up!
[00:41] <jbicha> sorry about that :(
[00:46] <darkxst> hmm seems ok
[00:47] <darkxst> can you check work-amd64/edit/usr/share/initramfs-tools/scripts/casper-bottom/15autologin
[00:48] <darkxst> the sed command should be commented out?
[00:49] <jbicha> here's what I did, but I didn't test it yet http://bazaar.launchpad.net/~ubuntu-gnome-dev/+junk/iso-build-script/revision/18
[00:54] <darkxst> that sed you added will apply to installed system also, is that what you want?
[00:55] <darkxst> if logout is still disabled, then files didn't copy for some reason
[00:56] <darkxst> I have mostly been testing with update-initramfs, however I did do a full rebuild this morning and it worked fine
[00:58] <jbicha> I think that sed line should be in a casper script
[00:59] <jbicha> Unity does it directly in their packaging without a casper script, but for us, it would be one extra diff from Debian which I don't want
[01:01] <darkxst> did you check the above file?
[01:03] <jbicha> I think it was the printf line, not the sed one
[01:03] <darkxst> oh, you meant classic?
[01:04] <jbicha> yes
[01:04] <darkxst> ah, I forgot to do that one ;)
[01:14] <darkxst> jbicha, so you can put that sed command in 25adduser I suppose
[02:01] <jbicha> I wonder why pt language packs are still installed after install
[02:41] <darkxst> jbicha, I assume you removed them from the build script?
[02:47] <jbicha> no, I don't see anything related in our build scripts; ubiquity is supposed to remove all language packs except for the chosen one
[02:47] <jbicha> it worked in the Ubuntu image, just not my Ubuntu GNOME one
[02:47] <darkxst> its in livecd-chroot script
[02:47] <darkxst> es and pt language-packs
[02:48] <darkxst> I suppose ubiquity doesnt remove them since they are installed manually into the chroot?
[02:52] <jbicha> the other language packs are removed, it's just en and pt left
[03:27] <darkxst> Sep 27 02:21:47 ubuntu install.py: keeping language packs for: en_US.UTF-8
[03:27] <darkxst> but then strangely it never trys to remove the pt packs :(
[03:29] <jbicha> so, my change isn't enough to get log out working from GNOME Classic
[03:30] <jbicha> anyway, I'm off to bed
[03:31] <jbicha> and we'll be releasing the beta later today-ish
[03:31] <jbicha> sorry I didn't get the plymouth stuff in
[03:37] <darkxst> ok,that  doesnt matter too much
[12:09] <jbicha> sorry I didn't get the plymouth stuff in
[12:09] <jbicha> sorry I didn't get the plymouth sstop
[12:09] <jbicha> sorry I didn't get the plymouth sstart
[12:09] <jbicha> sorry I didn't get the plymouth sstop
[12:09] <jbicha> sorry I didn't get the plymoulightdm start
[12:09] <jbicha> sorry I didn't get the plymoulightdm stop
[12:11] <jbicha> yikes, there's this crazy black screen of death problem with my Intel graphics card after letting the computer sleep for too long
[12:46] <darkxst> strange....
[12:46] <darkxst> jbicha, btw I can't find anything in casper that disables the logout for classic
[12:48] <darkxst> and user switching is still a mess (only works the first switch)
[13:51] <smartboyhw> jbicha, is beta coming today?
[14:17] <jbicha> smartboyhw: yes, I think we've got the final build
[14:18] <smartboyhw> jbicha, yay
[16:41] <jbicha> I'm having trouble figuring out whether the torrent tracking is working
[16:42] <jbicha> I'm getting a bunch of connection failed errors
[16:42] <jbicha> https://wiki.ubuntu.com/UbuntuGNOME/ReleaseNotes/12.10Beta?action=AttachFile
[16:54] <ricotz> jbicha, will try to get this one if the tracker works
[17:59] <jbicha> everaldo: hi
[18:07] <ricotz> jbicha, is the amd64 torrent working?
[18:08] <ricotz> meaning, it isn't working here (just noticed your mail)
[18:08] <jbicha> ricotz: does the i386 work?
[18:08] <ricotz> one sec
[18:09] <ricotz> doesnt work either
[18:10] <ricotz> i am only seeing one peer which is probably me
[18:15] <jbicha> so I could send you a direct link but I wish we could figure out how to get the torrents working before release
[18:16] <everaldo> jbicha, hey!
[18:17] <everaldo> jbicha, finally fix my internet, last days was really bad :-)
[18:17] <everaldo> jbicha, build iso here
[18:17] <everaldo> s/build/building/
[18:18] <ricotz> jbicha, i see
[18:19] <ricotz> jbicha, do you have the torrent running yourself?
[18:20] <jbicha> yes, but I'm getting connection errors
[18:48] <jbicha> I guess the trackers are working now
[18:49] <jbicha> I don't understand the crazy things :)
[18:49] <ricotz> jbicha, yeah there is one with 100% :)
[18:52] <jbicha> well there ought to be two with 100%
[19:34] <everaldo> also here 0 peers connected :(
[19:35] <everaldo> jbicha, 3 peers on amd64 and 0 on i386


[19:23] <mup> PR snapcraft#2552 closed: release: 3.4.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2552>
[21:29] <fastfresh> How do I pass environment variables to snap package? I need to run vscode snap with some additional PATH paths


[03:56] <Riddell> \sh_away: should be kdevelop ok to build not in breezy.  make sure you depend on the latest kdelibs and libcvs
[09:41] <\sh> hey jre
[09:41] <JRe> heyq
[03:50] <Riddell> hoary using volunteers needed to test koffice 1.4.1
[04:46] <JRe> Riddell: repo ?
[04:46] <Riddell> JRe: top one at http://kubuntu.org/hoary-koffice-141.php
[04:47] <JRe> Riddell: what kind of test? just installing the packages ?
[04:47] <Riddell> JRe: yes please
[04:48] <JRe> Riddell: ok i do it immediatly
[05:05] <JRe> Riddell: ok installed succesfully
[05:06] <JRe> (before i had 1.4)
[05:06] <JRe> Riddell: i've starting to use kword it works great
[05:06] <JRe> Riddell: no dep problems or things like that
[05:07] <JRe> Riddell: in short: well done :)
[05:08] <Riddell> JRe: rocking
[05:08] <Riddell> thanks for testing
[05:08] <JRe> Riddell: you're welcome! thanks for packaging :)
[05:08] <Riddell> now...koffice 1.4.1 or openoffice :)
[05:09] <JRe> Riddell: i think that as long as koffice will not perfectly handle .doc and .xls it's better to have openoffice
[05:09] <JRe> Riddell: but it's just IMHO ;)
[05:10] <Riddell> your opinion is valuable
[05:11] <JRe> (.doc and .xls bad handling often leads the user to return to window)
[05:57] <JRe> Riddell: i am going to work on the Krecipes 0.8.1 release
[05:57] <Riddell> JRe: cool
[05:57] <JRe> Riddell: you prefer that i make a whole package
[05:58] <Riddell> hopefully it will have got rid of some of those random libraries
[05:58] <Riddell> JRe: splitting up sounds best to me
[05:58] <JRe> Riddell: or that i separate binaries and recipes (arch indep) data
[05:58] <JRe> Riddell: if there is unusefull lib i'll clean the makefile
[06:05] <JRe> Riddell: BTW there is KTvSchedule in REVU, when you have time you can take a look at it. There is some improvments, and i think it will soon start to be usable
[06:05] <JRe> Riddell: (v0.1.9)
[06:06] <Riddell> JRe: added to TODO (after KDE 3.4.2 :)
[06:06] <JRe> Riddell: ok :)
[10:42] <allee> Riddell: koffice 1.4.1 installs fine. Played a bit with kspread: fine too
[10:43] <allee> are there plans to move digikam to main?
[10:45] <Riddell> allee: I'm yet to be convinced that digikam is any good
[10:45] <Riddell> but feel free to convince me :)
[10:46] <allee> Riddell: what problem do you have with digikam?
[10:48] <allee> In case you have ppc, most endian problems are fixed now ;)
[10:48] <allee> s/most/all known/
[10:48] <Riddell> well I tend to just sort my photos by directory, dikicam does all sorts of clever stuff that I don't really want to know about
[10:50] <allee> hmm, your way is the default in you don't touch the 'clever stuff', afaiu.
[10:50] <allee> with 0.8-svn digikam even got rid of some config options ;)
[11:12] <allee> sebas: why do you use(?) digikam
[11:21] <sebas> It works :)
[11:21] <allee> that's better than nothing ;)
[11:21] <sebas> And it's a nice app, I mainly use it to download and view my photos.
[11:22] <sebas> Another one, I'm trying to get guidance running in breezy.
[11:22] <sebas> I'm done with fixing compile problems, but now kcontrol can't find my modules.
[11:22] <sebas> They're in /usr/lib/kde3
[11:22] <sebas> kcmshell doesn't list them, though.
[11:23] <sebas> allee: Seriously, it's one of the coolest apps in KDE, I *really* like it.
[11:23] <allee> libs are not enough you need some desktop files too
[11:23] <sebas> Ah, then I'll check if these got installed properly.
[11:24] <allee> sebas: thx.  Can I cite you on #digikam? ;)
[11:25] <sebas> Sure.
[11:25] <sebas> I like the OpenGL slideshow, btw, although it doesn't work on my radeon.
[11:25] <allee> done ;)
[11:25] <sebas> Ok.
[11:26] <allee> doesn't work?  Not at all? only slow? ...?
[11:26] <sebas> Stays black
[11:26] <sebas> On my nvidia it works fine.
[11:27] <sebas> I've replied in a bugreport already, so it *should* be know ...
[11:27] <allee> oh, I've no problem in sarge with radeon cards
[11:28] <sebas> Which radeon?
[11:28] <sebas> And which driver?
[11:29] <sebas> I'm running sid, xorg from cvs with oss driver.
[11:29] <allee> 9000 and 9200, 7000 and 7500 afair
[11:29] <allee> sarge: so xfree 4.3
[11:30] <sebas> Hm, i've got a 7500
[11:30] <sebas> http://bugs.kde.org/show_bug.cgi?id=107410 This one actually.
[11:30] <sebas> Other OpenGL apps work just fine. ($GF is addicted to supertux)
[11:40] <allee> sebas: I've found a 7500 but the offcie it closed now.  I'll try tomorrow ...
[11:41] <sebas> Great :)
[11:41] <sebas> allee: Let me know if you need more feedback/info/flames ;-)
[11:41] <sebas><EMAIL_ADDRESS>[11:42] <allee> okay.  I appoint you to may hoary beta tester.  You have my repo in your sources.list so stay tuned ;)
[11:43] <sebas> allee: Ok. :)
[11:44] <sebas> Riddell: As to guidance, I'm bugging Simon now, who hopefully gets back online this week and will fix pykdeextensions (that's where the problems left are at the moment).
[11:47] <Riddell> sebas: cool
[11:47] <Riddell> and then it'll be ready for packaging?
[11:47] <allee> sebas: @kde.nl?  did you happen to have bbc with toma in rinses garden?
[11:48] <sebas> Riddell: Jep, I hope so. displayconfig might be excluded from packaging until we get the dualhead stuff flying, but I think that issues that might appear with the code can be easily fixed.
[11:49] <sebas> allee: Jep :)
[11:49] <allee> he, with toma and rinse around you, you can't dislike digikam, too dangerous ;)
[11:49] <sebas> The tricky stuff is the kcontrol magic (tricky as in "Let's Simon fix that" ;-))
[11:50] <sebas> allee: I think most of the photos for the dutch digikam docs/ are from me :)
[11:51] <allee> sebas: heh!
[11:59] <sebas> Riddell: Would you like intermediate hints how to fix smallish install problems or should I wait with bugging you until we get it actually running in breezy?
[11:59] <sebas> It might take a couple of days for Simon to reply, and I'm on holiday for a week beginning on friday.
[12:00] <Riddell> sebas: if you have hints that sounds good
[12:00] <Riddell> but currently I'm packaging kde 3.4.2 so not looking at guidance
[12:00] <sebas> Ok, I'll just CC: you in the e-mail to Simon then. It has most of the hints I could figure out.
[12:00] <Riddell> cool
[12:01] <sebas> That's no problem, of course. :)
[12:01] <sebas> Are you going to upload hoary backports of 3.4.2?
[12:02] <sebas> Yeah, a new snapshot build of OOo2 would be kewl, now the KDE stuff is merged.


[00:44] <Ammond> Just got Xubuntu loaded on a couple hosts. I'm confused about encrypting my home folder. A wizard comes up and tells me to click on the button to get my pass phrase and NOTHING happens. What's the trick??
[00:45] <Ammond> Even the command line seems to be wrong. I presume I really needed to sudo the command. Haven't tried that yet.
[00:51] <charlie-tca> !patience | Ammond
[00:51] <Ammond> Thnx!
[03:21] <vandyk> !File sharing
[03:21] <vandyk> !file share
[03:21] <vandyk> !filesharing
[03:22] <vandyk> !smb
[05:13] <BipolarMike> hello? I am a newb... anyone like to help me install Xubuntu?
[05:13] <BipolarMike> aw...
[05:32] <Misterangry> any suggestions for hanging at "Checking battery state" on live cd start?
[05:35] <moetunes> I would suggest doing the cd check
[05:35] <Misterangry> I did, and it turned out fine
[05:42] <moetunes> Misterangry:  I can't find anything on google about that sort of issue
[05:43] <moetunes> does it happen with another live cd?
[05:53] <ubuXubu> good morning xubuntu technicians.
[05:54] <Misterangry> moetunes: no
[05:55] <moetunes> Misterangry:  how old is the laptop?
[05:56] <Misterangry> that's the thing
[05:56] <Misterangry> it's not a laptop
[05:56] <moetunes> ohh
[05:57] <moetunes> prob why it hangs
[06:03] <Misterangry> so is xubuntu laptop exclusive?
[06:08] <moetunes> not at all - been in google again and found nothing like your issue
[06:12] <moetunes> I don't know why it would be looking for a battery at all Misterangry
[06:14] <moetunes> Misterangry:  what sort of hardware is in the comp?
[06:15] <Misterangry> intel p4, think it's an intel motherboard too
[06:16] <Misterangry> 2gb ram, nVidia card (I think.)
[06:16] <moetunes> should be no hassles at all with that stuff...
[06:17] <TheSheep> Misterangry: there is a number of kernel options you might want to try at startup
[06:17] <Misterangry> such as
[06:17] <ubuXubu> may i hear this problem
[06:17] <TheSheep> Misterangry: they are described in the help there
[06:22] <Misterangry> ubuXubu: Misterangry: any suggestions for hanging at "Checking battery state" on live cd start?
[06:22] <ubuXubu> hmmm
[06:23] <ubuXubu> doubt this is right but maybr change cmos battery if its old
[06:24] <TheSheep> Misterangry: I think that checking battery just happens to be the last thing displayed, it's not the thing that actually hangs
[06:24] <TheSheep> Misterangry: (x)ubuntu skips quite some messages
[06:24] <Misterangry> hmmph
[06:24] <Misterangry> how would I go about booting in to expert mode?
[06:25] <TheSheep> I guess you read the help at the boot screen, sorry I won't reboot now just to check for you
[06:25] <ubuXubu> does it hang but then does it let u run the os?
[06:25] <TheSheep> It's under F1
[06:27] <Misterangry> it just hangs
[06:28] <ubuXubu> so it never gets beyond that
[06:28] <Misterangry> nope
[06:28] <ubuXubu> if so i would suspect video issue
[06:29] <ubuXubu> is it a windows computer
[06:29] <Misterangry> nope
[06:29] <Misterangry> it runs Debian normally
[06:30] <ubuXubu> i wonder then if ubuntu cd would run live
[06:30] <Misterangry> yeah
[06:30] <ubuXubu> ok so if ubuntu runs live and xubuntu hangs at that stage i think there is a video issue in xfce with your hardware
[06:31] <ubuXubu> is it 1004 or above
[06:31] <Misterangry> 10.10
[06:31] <ubuXubu> ill bet 904 works
[06:32] <moetunes> looking for a battery wouldn't be a video issue afaik
[06:32] <ubuXubu> ill bet xubuntu 904 will run, i experienced something like this on a p4/nvidia desktop
[06:33] <ubuXubu> i know ...battery was 1st wild guess
[06:33] <ubuXubu> i think it video/xfce thing
[06:40] <ubuXubu> Misterangry, any chance th cd itself is corrupt, did you try it in another machine
[06:54] <Misterangry> not yet
[06:55] <Misterangry> and I actually don't have any machines without an nvidia card. lol
[06:56] <Misterangry> excluding the ppc laptop next to me, which wouldn't work for obvious reasons
[08:37] <xubuntu149> hey
[08:49] <xubuntu017> эй
[08:53] <Misterangry> it seems I got 10.04 working
[08:53] <moetunes> how did you get the cd booting Misterangry ?
[08:55] <Misterangry> burned a copy of 10.04, verified it and then started it normally
[08:55] <Misterangry> and yes, it is working
[08:57] <Amaterasu> helloo
[08:58] <Amaterasu> i recently tried xubuntu and i have question i'd to ask about it
[08:58] <Amaterasu> anyone there ?
[09:04] <TheSheep> wow, xubuntu is now used by japanese gods
[09:07] <moetunes> I am amazed at the breadth of your knowledge TheSheep :)
[09:07] <TheSheep> moetunes: telling that to someone with access to Internet is weird
[09:08] <moetunes> ohh you googled it ?
[09:08] <TheSheep> no, but I could have
[09:08] <moetunes> I had a feeling you didn't...
[09:35] <knome> !ask | Amaterasu
[09:35] <TheSheep> knome: yeah, we have it all explained already on #x-ot
[09:35] <knome> right
[09:36] <knome> i'll just continue with my usual matters then
[09:36] <TheSheep> :)
[13:26] <aladoinsano> Im trying to start xmodmap -e 'keycode 118 = Return' automatically on login, via rc.local, but it refuses to run. It does work since i can type exactly that in the terminal and then it works
[13:26] <aladoinsano> can anyone be of help?
[13:27] <moetunes> you can add it to the autostarted apps for your user
[13:28] <charlie-tca> cross-posted to #xfce at the same time
[13:31] <aladoinsano> yes i did add it to autostarted apps, but that didnt work either, trying out to put it .xinitrc now, lets see if that does the trick
[16:00] <ubuXubu> happy thanksgiving u buncha turkeys!!
[16:09] <leoquant> have a nice day to ubuXubu
[17:27] <Filimon> How to enable file sharing on Xubuntu?
[17:29] <Filimon> Can anyone help me?
[18:02] <charlie-tca> Xubuntu Community Meeting in 1 hour in #ubuntu-meeting
[18:55] <Roach_Motel3> howdy yall
[19:13] <ubuXubu> happy turkey day!!!
[19:15] <ridin> you too.
[19:21] <Roach_Motel3> howdy yall
[19:22] <Sysi> !hi
[19:22] <Roach_Motel3> got a problem with xubuntu, i have a toshiba 1005-s157
[19:22] <Roach_Motel3> I was able to successfully install but once it was installed
[19:23] <Roach_Motel3> i cannot boot, it brings up the splash screen and then goes black


[18:20] <lifeless> cr3: ol
[18:20] <lifeless> ola
[18:21] <nigelb> Morning lifeless :)
[18:21] <nigelb> Damn, its still yesterday for me.
[18:23] <lifeless> it always will be
[18:23] <lifeless> nigelb: hey, hows the jsoopsd going ?
[18:23] <nigelb> lifeless: Haven't started yet. Life.
[18:23] <lifeless> :)
[18:23] <cr3> lifeless: hola senor!
[18:24] <lifeless> cr3: I'm wondering how to get the service integration for the results tracker underway
[18:24] <lifeless> cr3: like e.g. should we identify a couple of useful steps and create bugs for the, ?
[18:24] <lifeless> s/the,/them/
[18:26] <cr3> lifeless: my understanding is that the next step consisting of auditing the code, does that sound about right?
[18:28] <cr3> lifeless: if so, I thought that perhaps having a production instance running might be useful which was completed last week. however, only IS has access to that instance, so I'm not really sure that was really a blocker come to think of it
[18:31] <lifeless> :)
[18:31] <lifeless> so the code review was part of being willing to open backend ports betwee it and LP
[18:31] <lifeless> we kindof need to do that & the first backend service at the same time
[18:32] <cr3> lifeless: what do you mean by "first backend service"?
[18:32] <lifeless> service call
[18:32] <lifeless> thing where it calls into LP via a trusted API
[18:32] <lifeless> e.g. direct person access
[18:33] <cr3> lifeless: ok, does LP already have direct person access?
[18:33] <lifeless> currently the only APIs for person at the launchpadlib ones - which means you'll run into trouble if the account is renamed
[18:33] <cr3> lifeless: btw, opening backend port can be done as one step and then actually using that port a second step
[18:34] <lifeless> sure, I kindof like to have a use case up my sleeve when changing firewall rules - so that someone monitoring can see it gets used.
[18:34] <cr3> lifeless: do you envision the person access needing a microservice of its own? how will that work?
[18:35] <lifeless> long term we might do a dedicated directory service, yes.
[18:35] <lifeless> medium term LP is the directory, so I'd expect targeted APIs on its services
[18:35] <cr3> lifeless: short term, database access? privileges launchpadlib api?
[18:35] <lifeless> 9
[18:35] <lifeless> bah
[18:35] <lifeless> no, no db access, ever ever ever ever evcer
[18:35] <cr3> good, I was going to whine otherwise :)
[18:35] <lifeless> possibly a privileged lplib API, or an xmlrpc api
[18:36] <cr3> lifeless: ideally, I'd like for the results tracker to still be runnable standalone by people on the outside. although that's my problem, just thought I'd share some of my pain :)
[18:37] <lifeless> cr3: thats a good goal, but there are two very distinct paths to it
[18:37] <lifeless> cr3: one path is to say 'run up as much of LP, *or equivalent services*, as the tracker needs'
[18:37] <lifeless> cr3: the other path is to say 'the tracker knows how to run standalone and how to run integrated'
[18:37] <cr3> lifeless: I could start looking into contributing a person access, any preference between lplib api or xmlrpc? I think there's more lplib api precedent for my inspiration, so that would be my inclination
[18:38] <lifeless> cr3: launchpadlib API only knows how to speak active urls; I don't think there is -any- precedent for using things that aren't exposed in the regular traversable fashion over lplib
[18:38] <cr3> lifeless: I was leaning towards the latter: being able to parameterize whether the tracker is running integrated or standalone
[18:39] <lifeless> cr3: that implies that you'll have two copies of every template, for instance (one for standalone, and one in the lp template service for integrated)
[18:40] <cr3> lifeless: I haven't even started thinking about the user interface, I'm hoping to find a way to make template sharing possible somehow
[18:41] <lifeless> cr3: If I were working on it, I wouldn't do a standalone mode; I would make the services it depends on clear, crisp, contracts, so that thin versions can be written and combined to run outside of LP
[18:41] <cr3> lifeless: maybe a tracker aware zope component that points to templates in the tracker codebase, I really don't know
[18:42] <lifeless> cr3: That sounds awfully complex vs saying 'templates are in the LP tree'
[18:42] <cr3> lifeless: to me, "LP tree" means it can't run standalone
[18:43] <cr3> lifeless: anyways, we'll burn that templates bridge when we're on it, lets concentrate on the person access service for now :)
[18:44] <lifeless> so to define it, we need to figure out what data you need, and in what access patterns, so that you can drop your mirrored person table
[18:44] <lifeless> (or reduce it to non-duplicated data [e.g. an enterprise-wide person reference]
[18:44] <cr3> lifeless: I'm not sure I understand "aren't exposed in the regular traversable fashion", I was thinking something like the hwdb in the lplib api which is only accessible to members of a particular group
[18:44] <lifeless> cr3: the hwdb is still referencing things by their current url
[18:45] <lifeless> cr3: the current url might be defined in an immutable fashion, but its still 'current url'
[18:45] <cr3> lifeless: could the enterprise-wide person reference be the database sequential id in lp or are we thinking of something wider than that?
[18:46] <lifeless> cr3: I don't think it can, no. Person ids get merged.
[18:46]  * cr3 will probably have to research how others have solved this problem before
[18:47] <cr3> lifeless: just for my edification, when do person ids get merged?
[18:47] <lifeless> or rather, it may be we can use the row key, but we need a way to handle lookups on persons that have been merged
[18:47] <lifeless> cr3: 'claim my account'
[18:47] <lifeless> cr3: or 'this person is me'
[18:48] <cr3> lifeless: ok, solving this problem will probably be useful for me in other contexts too, like when merging similar systems for ubuntu friendly
[18:49] <cr3> lifeless: do you know if this problem has been tackled before within canonical? any leads you know I should be following to start my exploration down this person access service?
[18:49] <cr3> lifeless: also, should we create a bug as you suggested before, or something else, to keep track that someone is looking into this?
[18:52] <lifeless> so, I think you need to look at how you use the mirrored person metadata
[18:53] <lifeless> and you need to make a bug / LEP that says 'results tracker needs real-time access to <foo> for <bar>' (repeat items in the bug/lep for batch vs single vs search)
[18:53] <lifeless> then we can think about how best to expose that and things that will cause trouble.
[18:56] <cr3> lifeless: sounds like a plan. I'm not entierely clear but it certainly gives me something to do and bounce later for feedback.
[18:56] <lifeless> cool
[18:57] <cr3> I need to jet for now, thanks for the guidance!
[18:57] <lifeless> to help clarity: look at your mirrored metadata; look at where you use it (queries, batches, individual templates) and write up a list so that we can together figure out how to meet those uses without you mirroring [all] of the data.
[18:57] <lifeless> bwah
[20:13] <lifeless> has anyone around atm setup a local oops-tools instance before?
[20:22] <jelmer> no
[20:43] <jelmer> also, g'morning :-)
[20:45] <lifeless> hi :)
[20:47] <nigelb> evening jelmer :)
[20:57] <jelmer> hey Nigel, what are you hacking on?
[20:57] <nigelb> jelmer: Nothing much tonight :)
[20:58] <nigelb> Need to do some stuff over the week.
[21:02] <lifeless> hmm
[21:02] <lifeless> I wants rabbitmqadmin packaged :)
[21:03] <lifeless> ah , it is
[22:30] <lifeless> where is that hack to change the command line ?
[22:30] <lifeless> (to hide passwords etc)
[22:34] <mwhudson> setproctitle?
[22:35] <lifeless> ah thanks
[22:35] <lifeless> I suspect I won't use it here (anyone with access to the same machine has access to the prod configs...)
[22:36] <lifeless> but its nice to remember it exists
[22:36] <lifeless> also
[22:36] <lifeless> amqp for oops-tools. Done.
[22:36] <lifeless> \o/
[22:36] <mwhudson> i don't know if using that for security is valid btw, there might be some way of digging out the original command line
[22:36] <lifeless> mwhudson: + race conditions
[22:36] <lifeless> python takes a while to start up after all
[22:36] <mwhudson> yeah, that too
[22:37] <lifeless> did I mention amqp ?
[22:37] <lifeless> :P
[22:37] <mwhudson> yes, that sounds very nice :)
[22:37] <lifeless> https://code.launchpad.net/~lifeless/python-oops-tools/amqp/+merge/79505
[22:52] <lifeless> (diff is there now)
[23:04] <lifeless> righto and local setup working. \o/
[23:21] <wgrant> lifeless: lucid?
[23:32] <lifeless> wgrant: of course
[23:39] <lifeless> anyone else seeing "Launchpad encountered an internal error during the following operation: generating an incremental diff for a merge proposal.  It was logged with id OOPS-2115MPJ4.  Sorry for the inconvenience"
[23:39] <lifeless> I thought we had incrementals turned off ?
[23:44] <wgrant> They're not displayed.
[23:44] <wgrant> But I think they're still generated.
[23:44] <wgrant> And yes, we've had a couple of reports of that last week.
[23:54] <lifeless> win ec2
[23:55] <lifeless> ec2test@i-da2526ba$ cd /var/launchpad/test; bzr merge lp:~lifeless/launchpad/useoops
[23:55] <lifeless> ssh: connect to host ec2-50-17-126-253.compute-1.amazonaws.com port 22: Connection timed out