[00:06] <wgrant> lifeless: Hmm.
[00:07] <wgrant> lifeless: Why 'timeline.timeline' instead of 'timeline'?
[00:08] <wgrant> I have to say that I really question the utility of a 155 line diff to deduplicate a single line of code.
[00:10] <wgrant> The python-oops-wsgi diff could be argued to be sensible. But I don't think python-timeline's is.
[00:11] <lifeless> wgrant: PEP 3333
[00:11] <lifeless> wgrant: environ variables are namespaced
[00:11] <wgrant> But even python-oops-wsgi's diff is probably better handled by passing a dict of stuff to preserve from the environment.
[00:12] <lifeless> so, which package do you think should define the location of the timeline in a wsgi stack ?
[00:13] <lifeless> An implied aspect is that we should export a symbolic variable with the value 'timeline.timeline'
[00:13] <wgrant> Does it need to be fixed?
[00:15] <wgrant> What's going to use it?
[00:21] <lifeless> wgrant: storm and other things that want to log events in a wsgi world
[00:21] <lifeless> wgrant: e.g. https://code.launchpad.net/~lifeless/storm/wsgi/+merge/76009
[00:22] <wgrant> Erm
[00:22] <wgrant> We have DNS breakage.
[00:22] <wgrant> LibrarianServerError: <urlopen error [Errno -2] Name or service not known>

[00:22] <lifeless> wgrant: note that this knows nothing about oopses
[00:22] <wgrant> Just got an OOPS for that page.
[00:23] <lifeless> -win-
[00:23] <lifeless> (sarcasm)
[00:23] <wgrant> And I forget to grab the OOPS ID.
[00:23]  * wgrant greps.
[00:24] <lifeless> was that a librarian fail or a find-librarian fail ?
[00:24] <wgrant> I think find-librarian,.
[00:24] <wgrant> Two OOPS so far today with that error, both from soybean.
[00:25] <lifeless> I've asked in is
[00:26] <lifeless> there was a dns reload
[00:27] <wgrant> Ah
[00:28] <lifeless> anyhow
[00:28] <lifeless> back to our regularly scheduled program
[00:28] <lifeless> its about loose coupling
[00:28] <lifeless> connecting storm to timeline in a wsgi environment is one step
[00:29] <lifeless> connecting timeline to oopses in a wsgi environment is another
[00:29] <wgrant> Just got another one.
[00:29] <lifeless> thus a change to storm, to timeline, and to oops-wsgi
[00:29] <wgrant> AQ4
[00:29] <wgrant> Are they still reloading DNS?
[00:43] <lifeless> james_w: I'm trying to use testr_recipe, but it says 'installing test.. cannot find distribution for test' (where test is the part in the buildout.cfg
[00:48] <lifeless> wgrant: ok, now where were we.
[00:56] <wgrant> lifeless: Having storm.wsgi.make_app be time-line specific seems odd.
[00:59] <wgrant> I'm all for factoring out common code sensibly, but I really don't think the python-oops-wsgi and python-timeline changes are examples of that. They save three lines of code, all of which are trivial and two of which could be reduced to one with a more generic python-oops-wsgi solution.
[01:01] <lifeless> wgrant: you'll need to spell out what you mean, because I don't see it
[01:01] <wgrant> lifeless: Which bit?
[01:01] <lifeless> more generic python-oops-wsgi solution.
[01:02] <wgrant> The oops_wsgi change would probably be better as a general facility to specify values from the environ to put in the context.
[01:02] <lifeless> I can do that
[01:02] <wgrant> eg. pass in a {'timeline.timeline': 'timeline'} dict or so.
[01:02] <lifeless> I don't see it eliminating the needed for the other changes
[01:03] <lifeless> I'd also like to have it do that particular one by default, as a sane-default
[01:03] <wgrant> So, to tie the bits together I need to import a module and have a special-case in oops_wsgi, or I can specify a tiny dict and construct a timeline myself.
[01:03] <wgrant> Which takes roughly 1.5 lines.
[01:04] <lifeless> I am rather allergic to copy and paste of undifferentiated code
[01:04] <lifeless> when there is really local policy, its fine. This isn't one of those times
[01:04] <wgrant> This code is actually going to be shorter.
[01:04] <wgrant> The other one just happens to be entirely symbols.
[01:05] <lifeless> per PEP3333
[01:05] <lifeless> the timeline module is what gets to use timeline.*
[01:06] <lifeless> if we call it oops.timeline or oops.context['timeline'] then oops-wsgi could set it
[01:06] <lifeless> if we call it storm.timeline, storm could set it
[01:06] <lifeless> anything else is asking for trouble, and all those other names are (hopefully obviously) undesirable
[01:09] <wgrant> I don't think any of those need to set it.
[01:09] <wgrant> The only glue code that is useful here is the stuff in storm.wsgi.
[01:12] <lifeless> which would be totally the wrong place to create the timeline object
[01:13] <lifeless> as its used for more than just storm lookups
[01:13] <wgrant> Sure, I don't think you should create it there.
[01:13] <wgrant> I think the app should do it.
[01:13] <wgrant> Pass the name into Storm.
[01:13] <wgrant> And ask oops-wsgi to map it into the report.
[01:13] <lifeless> that would force configuration onto everything that wants to talk to a timeline
[01:13] <lifeless> I think thats undesirable
[01:14] <wgrant> That's possibly true.
[01:14] <lifeless> I'm happy to make oops-wsgi more configurable
[01:14] <lifeless> but it would be a mistake to do that and then say 'now everyone has to use that'
[01:14] <wgrant> But we also have a 155 line diff to add one line (41 characters) of very trivial.
[01:15] <wgrant> very trivial code.
[01:15] <lifeless> shrug
[01:15] <wgrant> I think *that* is probably undesirable.
[01:15] <lifeless> the major cost - writing and testing it - is sunk
[01:16] <wgrant> This smells, and I don't have enough WSGI experience to say if it is sane. I'm afraid I can't sensibly approve this myself.
[01:18] <wgrant> This is an interface that other projects are going to use, so I am going to be more cautious than I would be for an internal LP interface.
[01:27] <lifeless> sure
[01:27] <lifeless> this is what jamesh and I agreed on
[01:27] <lifeless> I don't agree that it smells
[01:28] <lifeless> separate but related
[01:28] <lifeless> oops-tools has code to infer request duration
[01:29] <lifeless> by examining the last item in a timeline
[01:29] <lifeless> I think it might be sane for Timeline() to have a 0 duration initial action
[01:29] <lifeless> to seed things
[01:29] <lifeless> but Timeline can't tell when its finished with, so it needs to be told [exact details for doing this could vary]
[01:30] <lifeless> man, really want yield from
[01:31] <wgrant> That didn't make it into 3.2, did it?
[01:31] <lifeless> I don't think so
[01:31] <wgrant> :(
[01:31] <lifeless> it would make some of these wsgi wrappers better and faster
[01:31] <wgrant> Indeed, accepted for 3.3.
[01:32] <lifeless> such as the next change to the timeline one which I'm about to self review
[01:43] <lifeless> wgrant: other than the structural thing which you've abstained on
[01:43] <lifeless> wgrant: were there code quality comments; I have one noted from the discussion - why doesn't oops-wsgi let the map be done arbitrarily
[01:44] <lifeless> wgrant: which I will execute on as I'm in the area
[01:46] <wgrant> lifeless: It all looks fine, apart from the workaround for lack of 'yield from', which I believe is pretty standard anyway.
[01:46] <lifeless> yah
[01:47] <lifeless> thanks
[01:47] <lifeless> do you want to see the generalisation before I land (I plan to supply a default mapping dict which folk can use as a template, and a mapping param which None means 'use the default dict'
[01:48] <wgrant> That sounds fine. I'm about to wander out for a few hours, so won't be around much.
[01:48] <wgrant> Anyone want to review https://code.launchpad.net/~wgrant/launchpad/no-config-names-in-store-names/+merge/76135? Simple code changes, potentially non-simple consequences, but the test suite is fine with it.
[01:50] <lifeless> what about the impact on session query filtering ?
[01:50] <wgrant> The store name there is just 'session'
[01:50] <wgrant> Always has been.
[01:50] <wgrant> I don't think it even uses LaunchpadDatabase.
[01:51] <wgrant> Yeah, see PGSessionBase in canonical.launchpad.webapp.pgsession
[01:51] <lifeless> ok
[01:53] <wgrant> Thanks.
[01:59] <jtv> nigelb: noticed that too… no idea; frankly I don't know why other MPs don't get empty diffs once they're merged.
[02:03] <jtv> wgrant: looks like gina's done with sid.
[02:03] <jtv> Syncing logs to see what happened to squeeze.
[02:04] <jtv> Oh come on oneiric, please don't do this… I need to shut down _somehow_ so I can carry this laptop to the office.
[02:04] <wgrant> sudo pm-suspend ftw
[02:05] <lifeless> jtv: sudo pkill e*
[02:05] <lifeless> ?
[02:05] <jtv> lifeless: why e*?
[02:06] <lifeless> erlang, can't remember the process name
[02:06] <lifeless> has been known to cause 'issues'
[02:06] <wgrant> beam.smp? :)
[02:06] <lifeless> yeah :P
[02:06] <lifeless> there are two though
[02:06] <lifeless> beam and a broken
[02:06] <wgrant> epmd?
[02:06] <lifeless> broker
[02:06] <lifeless> yes
[02:06] <wgrant> Yay, I remember erlang crap properly.
[02:07] <jtv> In my case: can't move mouse pointer, and can't log into text console because it keeps typing /////////////
[02:07] <jtv> (Actually my GUI session has been doing that as well, but _there_ at least it stopped)
[02:08] <jtv> And since suspend/hibernate don't work, I need to shut down.  But since the shutdown option doesn't work, what I normally do is log out and then switch to a text console to shut down.
[02:08] <jtv> I think I'll take a bug-filing day this week.
[02:09] <jtv> Well, the pkill didn't work.  :(
[02:15] <jtv> Why is epmd running as rabbitmq even after I stopped rabbitmq?
[02:16] <jtv> And why was it still there after the pkill?
[02:16] <jtv> I killed it by pid, but no change.  :(
[02:16] <lifeless> anything in dmesg?
[02:17] <jtv> A lot of screensaver segfaults
[02:17] <jtv> Complaints about the CD that's in my drive, I think.
[02:17] <jtv> forcedeth, which sounds like a cover band.
[02:18] <jtv> Complaints about unknown SCO packets on hci0.
[02:19] <jtv> Sorry no, about SCO packages for an unknown connection handle.
[02:19] <jtv> “apm: BIOS not found” is probably not as exciting as it sounds.
[02:20] <StevenK> You're on a MacBook which uses EFI
[02:20] <jtv> Not as exciting as it sounds.
[02:21] <jtv> I'll try the pm-suspend then I guess.
[04:09] <lifeless> win 19978  OOPS-2088HWDB303  None
[04:38] <StevenK> wallyworld_: *prod*
[04:38] <wallyworld_> StevenK: hello
[04:38] <StevenK> wallyworld_: var co = Y.one('.yui3-overlay.yui3-lp-app-confirmationoverlay');
[04:38] <StevenK> That still results in co being null
[04:38] <wallyworld_> no work?
[04:39] <wallyworld_> maybe try removing one of the css class selectors
[04:39] <wallyworld_> just to see what happens
[04:40] <StevenK> Can I see all CSS classes at that point int time?
[04:40] <wallyworld_> yes, node.getClass()
[04:41] <wallyworld_> but i thought you looked using firebug
[04:41] <wallyworld_> to see what the classes were
[04:41] <StevenK> I meant in the test itself
[04:42] <wallyworld_> oh, ok, yes that will give you the classes
[04:43] <wallyworld_> once you have the node
[04:43] <wallyworld_> wgrant: wrt the conversation about only removing subscribers for bugs associated with projects with private_bugs=true - it is acceptable to simply look at the default_bugtask to get the project (if any) whose 'private_bugs' may be true/false?
[04:44] <StevenK> wallyworld_: Yes, but I'm having trouble getting the node!
[04:45] <wallyworld_> StevenK: yes. so you probably are best to loosen the selection constraint on css class
[04:45] <wallyworld_> to try and get a node that matches
[04:45] <wallyworld_> you can also use Y.all() and iterate over the node list
[04:46] <wallyworld_> so if you make the constraint .yui3-overlay you can see what overlays there are
[04:46] <StevenK> Y.all('.yui3-overlay'); ?
[04:46] <wallyworld_> yes, i think so
[04:46] <wallyworld_> so long as yui3-overlay is correct in terms of a css class that they have
[04:48] <mwhudson> I couldn't get Y.one('.class-one.class-two') to work the other day
[04:48] <mwhudson> could it be some kind of bug?
[04:48] <wallyworld_> mwhudson: perhaps. i think we are running a rc version of yui 3.4. maybe time to look at upgrading
[04:48] <StevenK> That was silly
[04:49] <StevenK> alert(i) gives me an alert box for each attribute of the node
[04:49] <mwhudson> doh
[04:49] <wallyworld_> StevenK: no i lie. we are running 3.3
[04:49] <wallyworld_> but 3.4 is now out i think
[04:50] <wallyworld_> StevenK: Y.log is your friend
[04:50] <StevenK> AH
[04:50]  * mwhudson asks in #yui, though i expect everyone is asleep
[04:50] <StevenK> Y.all('.yiu3-overlay') has a _nodes property that is [ ]
[04:51] <wallyworld_> StevenK: that implies there are no matching nodes
[04:51] <wallyworld_> since Y.all returns a NodeList afaik
[04:51] <mwhudson> StevenK: don't look behind the curtain
[04:51] <StevenK> Clearly
[04:51] <mwhudson> StevenK: .size() == 0 is a better check :)
[04:52] <mwhudson> (and as for gratuitous differences between Array and NodeList...)
[04:53] <StevenK> Ah ha
[04:53] <StevenK> That function never gets called with "unsubscribe"
[04:53] <StevenK> wallyworld_: Does Y.log() hit stdout/stderr when running under bin/test?
[04:54] <StevenK> mwhudson: My JS knowledge is ... heavily fragmented and mostly missing.
[04:54] <wallyworld_> StevenK: not sure but doubt it. it goes to the console in the browser when you run the test via loading the html page
[04:54] <wallyworld_> i find that the best way to debug
[04:54] <mwhudson> StevenK: mine is heavily fractured but i'm gradually filling in the gaps :)
[04:54] <wallyworld_> since i can also use break points, watches etc etc
[04:58] <StevenK> wallyworld_: Running it via the browser it keeps complaining that "Y.lp.app.confirmationoverlay" is undefined.
[04:58] <wallyworld_> StevenK: that explains a lot
[04:58] <wallyworld_> StevenK: you need to include the module in the html harness
[04:59] <StevenK> Oh, at the bottom of the test js?
[04:59] <wallyworld_> sort of near where the other imports are done nearish the top i thin
[04:59] <wallyworld_> thinkl
[04:59] <StevenK> Oh, in the HTML itself
[04:59] <wallyworld_> yes
[04:59] <wallyworld_> see the
[05:00] <wallyworld_> comment
[05:00] <wallyworld_> Some, not Come
[05:00] <wallyworld_> can't type
[05:00] <StevenK> Which doesn't appear in that HTML
[05:01] <wallyworld_> StevenK: bin/test tends to hide a lot of errors and just reports failure for whatever reason
[05:01] <wallyworld_> see test_personpicker.html for an example
[05:01] <wallyworld_> bin/test is good for once stuff is debugged and working
[05:02] <wallyworld_> but to see setup errors etc, use the browser and firebug
[05:05] <StevenK> Expected: null (object)
[05:05] <StevenK> Actual: DIV#yui_3_3_0_2_13164951130961890 yui_3_3_0_2_13164951130961894 (object)
[05:05] <StevenK> SUCCESS
[05:05] <wallyworld_> StevenK: excellent!
[05:06] <wallyworld_> StevenK: now you can try the "proper" css class selector
[05:06] <StevenK> That is with the proper CSS class selector
[05:06] <wallyworld_> even better
[05:06] <StevenK> var co = Y.one('.yui3-overlay.yui3-lp-app-confirmationoverlay');
[05:06] <wallyworld_> at least now you know you test fails and you can write the code to fix it
[05:06] <StevenK> Does that strike you as 'proper' ?
[05:07] <wallyworld_> well, so long as it is specific enough to select the confirmation overlay you are trying to get at
[05:07] <wallyworld_> and not find any others
[05:07] <StevenK> wallyworld_: I'm now un-breaking the JS itself to only show the overlay on private bugs
[05:07] <wallyworld_> sounds good
[05:08] <StevenK> And then if the test passes, I can start writing my own
[05:10] <wallyworld_> yep
[05:11]  * wallyworld_ has to go and pick up car from getting new tyres fitted
[05:11] <StevenK> >1 day for 3 lines of JS and 2 lines of HTML
[05:11] <StevenK>  /wrists
[05:11] <wallyworld_> StevenK: at least you know how to do it quicker now :-)
[05:11] <wallyworld_> all the things to look out for
[05:12] <wallyworld_> StevenK: what doesn't kill you makes you stronger :-)
[05:34] <nigelb> Except those that make you want to die.
[05:34] <nigelb> ;)
[05:35] <nigelb> Why does the MP have "Empty diff" ocassionally?
[05:35] <nigelb> I saw it for one of MPs and the other day with one of jtv's MPs.
[06:09] <StevenK> Can I grab hold of a button in JS by using Y.one() ?
[06:10] <huwshimi> StevenK: Does the button have an ID?
[06:10] <StevenK> It does not
[06:11] <StevenK> <button class="lazr-pos lazr-btn ok-btn" type="submit">OK</button>
[06:11] <StevenK> It has a surrounding div (
), which I guess I can grab with var div = Y.one('.yui3-lazr-formoverlay-actions');
[06:31] <wallyworld_> StevenK: you can grab a button using attribute matching also eg "button.ok-btn[type='submit']" or something like that
[08:02] <adeuring> good morning
[08:05] <nigelb> Good Morning adeuring & mrevell
[08:05] <mrevell> yo
[08:16] <wgrant> stub: Hmm, so it turns out that all but two of the storm_cache and storm_cache_size directives in the configs are unused.
[08:18] <stub> wgrant: Just the appserver overriding?
[08:19] <stub> wgrant: We currently have a huge value for the appserver because it hasn't been instrumented and are scared of reducing the size.
[08:20] <stub> wgrant: And are scared of using high values in scripts to stop memory ballooning.
[08:20] <wgrant> stub: Well, that's what I thought, but it's a little bit simpler than that.
[08:21] <stub> Its busted and only works in rare cases?
[08:21] <wgrant> The 'launchpad' section is used for everything, except for the librarian (which uses 'librarian').
[08:21] <stub> \o/
[08:21] <wgrant> launchpad is 10000 on production, 100 on dev.
[08:22] <wgrant> Someone somewhere along the line stopped calling setConfigSection in production code, except for the 'launchpad' default in lib/canonical/config/__init__.py, and one other case in librarian.tac.
[08:22] <wgrant> librarian seems to really only care about overriding the dbuser and isolation_level.
[08:22] <wgrant> Which, conveniently, is what everybody else cares about overriding too.
[08:23] <stub> Do we currently have any script memory hogs?
[08:23] <wgrant> Apart from nasty gina and process-death-row worstcases recently, not really.
[08:24] <wgrant> That I know of.
[08:24] <stub> dbuser and isolation_level should really be hardcoded anyway, isolation because things break if you change the config and dbuser because we never make use of the fact we can change the config.
[08:24] <wgrant> Yeah, apart from in tests.
[08:24] <wgrant> ... and formerly in buildd-manager, but that was fixed a year ago.
[08:25] <wgrant> So, I'm probably removing config section support, merging launchpad's settings into the main database section, changing librarian.tac to override directly. And due to the fix I landed this morning, that means that dbconfig.override() is pretty much a direct replacement for initZopeless, and ZTM can finally BURN.;
[08:26] <wgrant> And this stuff that has been a shim for 4 years can finally die :/
[08:34] <wgrant> Uhoh.
[08:34] <wgrant> canonical.lp won't die.
[08:34] <wgrant> It somehow got revived today.
[08:34]  * wgrant blames jtv.
[08:34] <jtv> whuwhuwhu?
[08:34] <wgrant> message: [r=benji][no-qa] Fix lots of lint in recently-changed files.
[08:34] <wgrant> added: lib/canonical/lp/
[08:34] <wgrant> :(
[08:34]  * wgrant remurders.
[08:34] <jtv> Please do.
[08:42] <wgrant> Bah.
[08:42] <wgrant> Looks like I need to keep respecting config.launchpad.dbuser, as it's what all the appserver configs use.
[08:44] <poolie> jtv, i think you mean "symptom, search internet, selfdiagnosis, treatment, conspiracy theories"
[08:45] <jtv> poolie: I am _not_ taking you to any more coffee shops.
[08:45] <poolie> haha :)
[08:46] <bigjools> lifeless: how's the python-oops-twisted thingamujig?
[09:09] <lifeless> bigjools: good news and bad news
[09:09] <lifeless> bigjools: the good news is I figured out what all the tech debt meant
[09:09] <lifeless> bigjools: the bad news is that the new project isn't done yet, because of the good news
[09:09] <lifeless> bigjools: pretty close though, just tests to write now
[09:12] <bigjools> lifeless: well, thanks, you've saved me a bunch of work so it's all good AFAIAC: )
[09:26] <poolie> jelmer, hey that's a really interesting point about the code ui
[09:28] <jelmer> poolie: thanks; I think it's one of those things that are hard to notice once you've gotten used to the existing UI.
[09:29] <poolie> yeah
[09:29] <poolie> i was actually talking to huw about this the other day
[09:29] <poolie> because we did a little on it at the o'rally and it's been idle since then
[09:29] <poolie> i would love to see it reactivate
[09:29] <jelmer> Once the last code-import<->mirror integration branch lands, I'd really like to kill the "Register a branch" button.
[09:29] <poolie> i think it's one of those topics that can hurt user experience a lot, but that won't clearly come up in bug reports or user requests
[09:30] <poolie> s//hurt or help
[09:30] <jelmer> yeah
[09:50] <lifeless> bigjools: turns out our current twisted integration can silently block the librarian etc
[09:50] <lifeless> bigjools: we're calling blocking apis without deferToThread
[09:50] <bigjools> lifeless: awesome
[09:50] <lifeless> I will be fixing one of the two cases
[09:50] <bigjools> what scenarios?
[09:50] <lifeless> oops creation writes files to disk
[09:51] <lifeless> and can trigger a re-read of the directory
[09:51] <lifeless> but the key bit is we thunk logObserver to python logging
[09:51] <lifeless> and thats documented in the twisted docs as 'can block'
[09:51] <lifeless> we should be doing deferToThread
[09:52] <lifeless> and then doing the may-block stuff in a thread
[09:52] <lifeless> this just became blindingly obvious when I started asking 'how to extract this nicely'
[09:52] <lifeless> for bonus points we have two distinct twisted integrations atm
[09:52] <stub> I normally don't mind the spider, but it should get off my damn screen!
[09:52] <lifeless> roughly equally used.
[09:53] <lifeless> I'm not going to try and fix that, but I'm going to bless one - the one I extract :)
[09:53] <bigjools> lifeless: well at least you spotted it
[09:54] <jml> lifeless: which is the blocking API being called?
[09:54] <stub> We need to append pending log messages to a list, and deferToThread something that logs them in the correct order.
[09:55] <jml> Logging a message doesn't normally need to be treated as a blocking operation.
[09:55] <lifeless> jml: PythonLoggingObserver
[09:56] <lifeless> jml: it does, and this is documented in the twisted docs as well as the logging docs.
[09:56] <jml> lifeless: where?
[09:56] <lifeless> jml: on the web page :) - sorry, past EOD and got stuff to do
[09:56] <jml> that's lame
[09:56] <jml> but I understand.
[09:56] <lifeless> the twisted.log api docs specifically
[09:57] <lifeless> wherever they are
[09:57] <stub> Oddities I foresee are log messages being spit out in the wrong order, timestamps being slightly off, and bound variables and stacks being mutated as the callsite proceeds and before the log message is generated.
[09:57] <jml> lifeless: thanks
[09:58] <lifeless> stub: failures already materialise the backtrace IIRC
[09:58] <jml> they do.
[09:58] <lifeless> stub: the rest are already happening because we're in a reactor environment
[09:58] <stub> cool. timestamps will be within precision.
[09:58] <stub> just thinking of why it is blocking in the first place :-)
[09:59] <lifeless> its blocking because the python 'logging' module has a great big lock in the middle
[09:59] <lifeless> (and because file IO and directory listing can block too)
[10:06] <jtv> bigjools: do we have any way to watch the debian domination on production?
[10:06] <bigjools> jtv: the log file?
[10:06] <jtv> I mean the effects of.
[10:07] <jtv> Seeing whether the resulting status of Debian makes sense.
[10:07] <bigjools> jtv: yeah, find a package that's dead in Debian but not in LP's import
[10:07] <bigjools> also see the count of packages in +missingpackages
[10:07] <jtv> Oh, we derive Ubuntu from Debian in production now?
[10:08] <bigjools> have done for a while!
[10:08] <bigjools> see oneiroc
[10:08] <bigjools> oneiric, even
[10:08] <bigjools> that's how this bug was noticed IIRC
[10:09] <jtv> Ooh nice little beta bar
[10:10] <jtv> Mind you, this is transitional domination so it shouldn't mark dead packages as deleted yet; it'll keep the last release alive for permanent domination to deal with.
[10:11] <jtv> Also, gina's still dealing with squeeze.  :/
[10:11] <bigjools> did it do sid yet?
[10:11] <jtv> No, don't think so.
[10:11] <bigjools> if not, take a note of the number of packages now
[10:11] <bigjools> compare after
[10:11] <jtv> Good one.  We also did that on dogfood.
[10:12] <jtv> Packages and statuses, I think.
[10:12]  * jtv cooks up some SQL
[10:21] <bigjools> jtv: you can just look at the package counts in the UI
[10:21] <jtv> The ones that need linking?
[10:22] <bigjools> [11:07:42] <bigjools> also see the count of packages in +missingpackages
[10:23] <jtv> That includes the DSD machinery as well… since I'm not expecting any package deletions, I'll want to watch the DB as well.
[11:07] <jtv> gmb: clearly, you're not bitter but just a tad disappointed in my review style?
[11:12] <gmb> jtv: No, I've just formed an emotional attachment to the branch because I've been working on it for a week and a half.
[11:12] <gmb> ]
[11:12] <gmb> It's been a royal pain in my backside.
[11:12] <gmb> jtv: One of your in depth reviews is always appreciated, unless the reviewee is feeling particularly lazy.
[11:12] <jtv> Says the self-proclaimed Lazy Reviewer.  :)
[11:13] <jtv> We ought to form a duo à la Laurel & Hardy.
[11:13] <gmb> :)
[11:13] <jtv> Hippie & Nazi, Reviewers™
[11:13] <gmb> Yeah, I can see that going down a storm :)
[11:16] <bigjools> lifeless: I need to do a txlongpoll test fixture - any opinion on whether that should be a separate project?
[11:17] <jtv> gmb: compared to what I got away with last week, it ain't so bad.
[11:18] <lifeless> bigjools: I'm torn
[11:19] <lifeless> bigjools: on the one hand it should clearly be reusable, so not part of LP
[11:19] <bigjools> lifeless: we could not decide either :) It'll add more dependencies of course
[11:20] <lifeless> on the other hand if its part of txlongpoll it ties the client language to the server implementation, and implies that a client that can use the fixture could get at the server innards - thats undesirable
[11:20] <lifeless> on the gripping hand adding a new project has some cognitive overhead
[11:22] <lifeless> I think we should try separate-project: we can always massively consolidate later
[11:23] <bigjools> I was erring that way
[11:25] <jtv> gmb: your change to initialize() puzzles me.  Why assign a variable you're not going to use?  Are you trying to force evaluation of a property?
[11:27] <gmb> jtv: Yes; activity_and_comments is a cachedproperty. If it's not loaded at initalize() time you end up with recursion problems in tests (not in actual usage though). I can drop the variable assignment; it just looked odd to me without it.
[11:30] <gmb> jtv: I'm going to go and grab some lunch; feel free to stick any questions in the MP and I'll reply on my return.
[11:31] <jtv> Aye-aye.
[11:38] <danilos> flacoste, lifeless: we can't triage bugs for launchpad-results (like https://bugs.launchpad.net/launchpad-results/+bug/854635), meaning that it's not really our duty, yet it's part of launchpad-project and we can't drive untriaged bugs count to zero: what shall we do about it?
[11:38] <_mup_> Bug #854635: unit model names have leading/trailing spaces <Launchpad Results:New> < https://launchpad.net/bugs/854635 >
[11:41] <danilos> bigjools, the following bug seems to be simple to fix (missing DB user), yet pretty critical: bug 854449. Do you think we should treat it as an incident and start working on it asap?
[11:41] <_mup_> Bug #854449: generate-contents-files.py failing on Ubuntu archive since September 11/12 <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/854449 >
[11:41] <bigjools> danilos: yes
[11:42] <bigjools> danilos: I suspect fallout from recent db user renamings
[11:42] <bigjools> danilos: also it needs a script monitor
[11:43] <danilos> bigjools, right, thanks, I'd appreciate it if you (as someone with more authority on the subject) adds a note to the bug itself, and I'll ensure we get started on it soon
[11:43] <danilos> soon == today
[11:44] <bigjools> ok :)
[11:45] <wgrant> danilos: It is a pretty trivial puppet task.
[11:45] <wgrant> An RT and a LOSA-poke may be in order.
[11:45] <danilos> wgrant, I can guess it is for someone who knows all about the script
[11:46] <wgrant> Hm? It's not got much to do with the script :)
[11:46] <danilos> wgrant, (eg. what DB user it should use)
[11:46] <wgrant> if __name__ == '__main__':
[11:46] <wgrant>     script = GenerateContentsFiles(
[11:46] <wgrant>         "generate-contents", dbuser='generate_contents_files')
[11:46] <wgrant> Problem solved :)
[11:47] <danilos> wgrant, I'd appreciate if you add that to the bug as well, since I am doing my CHR rotation right now
[11:49] <wgrant> Done.
[11:50] <danilos> thanks
[12:27] <wgrant> bigjools: You might recall that I removed txlongpoll a while back.
[12:27] <wgrant> bigjools: lifeless forbids its inclusion in our setup.py.
[12:27] <bigjools> FFS
[12:27] <wgrant> For it is to be a microservice.
[12:27] <bigjools> we need it for make run
[12:27] <bigjools> that is all
[12:28] <bigjools> I don;t know how else to set it up
[12:28] <stub> Is there an RT for Bug #854449  yet?
[12:28] <_mup_> Bug #854449: generate-contents-files.py failing on Ubuntu archive since September 11/12 <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/854449 >
[12:28] <wgrant> bigjools: Neither do I.
[12:28] <lifeless> danilos: -results is in a bit of limbo; we should either have it meet our governance rules or remove it from being part of 'launchpad-project'.
[12:29] <lifeless> danilos: chat to flacoste when he's up, and/or cr3 about which route
[12:29] <lifeless> danilos: cr3 wants to have it properly integrated as a microservice etc
[12:29] <lifeless> danilos: so, I think the right thing is getting it under our regular rules for bug supervisor etc
[12:29] <danilos> lifeless, right, thanks for updating me on it
[12:30] <lifeless> wgrant: bigjools: you use a buildout recipe
[12:30] <lifeless> wgrant: that gets it executable with a bin/txlongpoll entry point, but not importable
[12:30] <wgrant> This is going to get very ugly.
[12:30] <wgrant> But maybe.
[12:30] <lifeless> wgrant: bigjools: my use-gpgfixtures branch on lp has/had an example of doing that for the new keyserver.
[12:30] <lifeless> which flacoste gave me.
[12:30] <wgrant> We'll need a separate buildout target for each dep.
[12:31] <bigjools> lifeless: there is no bin/txlongpoll entry point
[12:31] <bigjools> it's a TAP
[12:32] <lifeless> so, you need the egg unpacked (buildout can do that), and you need a script (the fixture) that knows how to run the tap
[12:32] <lifeless> no ?
[12:32] <lifeless> just txlongpoll itself doesn't end up on our PYTHONPATH
[12:33] <bigjools> can you explain your aversion to setup.py changes?
[12:33] <wgrant> Ah, that's right. You'll need to use buildout to create a second twistd.
[12:33] <wgrant> That has the egg.
[12:33] <lifeless> I love setup.py changes
[12:33] <bigjools> in this context :)
[12:33] <lifeless> https://dev.launchpad.net/ArchitectureGuide/ServicesRequirements#Background_reasoning
[12:34] <bigjools> I'm not sure that answers the question
[12:34] <lifeless> thats the background reasoning
[12:35] <bigjools> I'm not really au fait with buildout so this is a learning exercise
[12:35] <lifeless> for why I want the microservices to not be importable
[12:35] <bigjools> happy to be guided on this
[12:36] <lifeless> wgrant: yes, buildout a z3c.recipe.script that has the additional egg, probably a defaults=... and tada
[12:36] <gmb> jtv: I hadn't noticed the conflicts with devel; have pushed a fix.
[12:37] <jtv> gmb: thanks.  I'm… collating notes.
[12:37] <gmb> ok
[12:37] <lifeless> bigjools: basically I want an ironclad avoidance of the sort of back-door dealing with API's we've had in LP with in-process stuff
[12:37] <bigjools> ok
[12:37] <lifeless> bigjools: so that folk can *confidently* work to the interface, not the implementation
[12:37] <lifeless> this has several corollaries:
[12:38] <bigjools> I'm still unsure what setup.py has to do with that
[12:38] <lifeless>  - there will be some form of split-outs that we can't do, because we don't know how to write an interface that is fast+ etc etc etc
[12:38] <bigjools> I perfectly understand the rationale, just not the "how" :)
[12:38] <lifeless> oh
[12:38] <lifeless> so when you add something to setup.py, buildout adds the resulting egg to the PYTHONPATH
[12:38] <lifeless> it does this transitively.
[12:38] <bigjools> and a simple buildout recipe does not?
[12:38] <lifeless> if you have setup.py reference package A
[12:39] <lifeless> and A references B
[12:39] <lifeless> B will be in the PYTHONPATH setup by bin/py
[12:39] <lifeless> bigjools: the 'scripts' recipe can specify its own additional things
[12:39] <bigjools> how are we going to make a fixture figure out how it can run the TAP then?
[12:40] <jtv> gmb: done.  Frankly it was the name of the branch that attracted my attention in the first place.
[12:40] <lifeless> bigjools: thinking
[12:40] <lifeless> bigjools: got it
[12:40] <lifeless> bigjools: the fixture needs to know the command line to run the thing
[12:40] <gmb> jtv: Heh, thanks.
[12:41] <bigjools> yes, but it also needs to know where the twistd binary and plugin lives to do that
[12:41] <lifeless> bigjools: this doesn't mean importing, it just needs to know that 'bin/twistd-longpoll' will run a twistd invocation that can import longpoll, and it needs the tap file
[12:41] <lifeless> bigjools: yes, this will mean buildout.cfg stuff (sorry to be handwavy, nearly 1am etc)
[12:42] <bigjools> ok, thoroughly confused here :)
[12:42] <lifeless> wgrant: are you less confused?
[12:42] <bigjools> maybe someone who knows buildout better can do this
[12:42] <gmb> jtv: Once again, your review has me saying "Wait, what?" I never knew about zip() (or knew and have forgotten). I shall go and learn about it forthwith.
[12:42] <jtv> gmb: good sport
[12:43] <lifeless> def sudo_make_me_a_fixture(twistd='bin/twistd-longpoll', tap='bin/longpoll.tap'):
[12:43] <lifeless>     return LongPollFixture(twistd=twistd, tap=tap)
[12:43] <lifeless> ^ thats the thunk code to inject the custom twistd script and tap location
[12:44] <lifeless> the other bit is teaching buildout to create the tap and twistd-longpoll
[12:44] <wgrant> bigjools: See txlongpoll's buildout.cfg.
[12:44] <wgrant> The 'interpreter' section there does sort of what we want.
[12:44] <wgrant> Except we probably want to use a script target directly, without an interpreter, if possible.
[12:45] <bigjools> lifeless: how would it know where bin lives in your example?
[12:45] <lifeless> bigjools: in LP it will always be bin/twistd-longpoll
[12:45] <bigjools> even if we have a script that encapsulates the invocation
[12:46] <bigjools> ah, so you want it in LP's bin
[12:46] <lifeless> thats what buildout is for
[12:46] <lifeless> its responsible for making that file
[12:47] <lifeless> this is what flacoste showed me: http://bazaar.launchpad.net/~lifeless/launchpad/usegpgfixtures/revision/13758
[12:47] <bigjools> twistd is not entirely flexible in how it looks for TAPs is it ...
[12:47] <lifeless> wgrant: ^
[12:47] <wgrant> bigjools: Not at all. So we'll need a second twistd that has basically just txlongpoll in its path.
[12:47] <bigjools> right, we have something in the txlongpoll buildout.cfg that builds itself
[12:48] <wgrant> Ahh, z3c.recipe.scripts, handy.
[12:48] <wgrant> Although that still generates an interpreter.
[12:48] <lifeless> wgrant: it didn't
[12:48] <lifeless> I don't know why the line is needed ;)
[12:50] <bigjools> what does that code put in bin/ ?
[12:50] <bigjools> s/code/config/
[12:51] <lifeless> it creates bin/gpgfixtures
[12:51] <lifeless> which has the buildout glue to set pythonpath etc
[12:51] <bigjools> not in my dev area it doesn't :)
[12:51] <lifeless> and ends up running gpgfixtures.keyserver.main(argv)
[12:51] <lifeless> bigjools: what do you mean ?
[12:52] <bigjools> there is no bin/gpgfixtures when I build latest trunk
[12:52] <lifeless> of course
[12:52] <lifeless> thats in a branch
[12:52] <bigjools> unlanded?
[12:52] <bigjools> ok
[12:52] <lifeless> its demonstrating what you need to achieve, for a different but similar case
[12:53] <bigjools> insomuch as I understand roughly what one of those lines is doing :)
[12:53] <lifeless> right
[12:53] <lifeless> this is why I pointed wgrant at it
[12:53] <lifeless> he has more overlap with you
[12:53] <lifeless> I'm dead :)
[12:53] <bigjools> FSVO overlap :)_
[12:53] <wgrant> Well, we actually both have zero overlap.
[12:53] <wgrant> But yes.
[12:54] <bigjools> yeah, you were up at crazy o'clock
[12:54] <bigjools> thanks for the advice so far lifeless, rest well
[12:54] <wgrant> Night lifeless.
[12:56] <bigjools> wgrant: ok so we might be able to get away with the one in txlongpoll, the only issue is what to do with the TAP directory abomination
[12:56] <wgrant> bigjools: What about it?
[12:56] <wgrant> That's all in the egg.
[12:57] <bigjools> wgrant: yes, but it needs to end up in $CWD
[12:57] <wgrant> Nope.
[12:57] <bigjools> otherwise twistd doesn't find it
[12:57] <wgrant> It's in twisted/plugins/blah
[12:57] <bigjools> is there a way of telling twistd where it is then?
[12:57] <wgrant> Just try that buildout rul.e
[12:57] <wgrant> Should work fine.l
[12:57] <wgrant> I can type, see.
[12:57] <bigjools> you miss my point I think
[12:57] <wgrant> twistd looks in twisted.plugins
[12:58] <wgrant> The plugin is in twisted.plugins in the egg.
[12:58] <bigjools> where "twisted" is in $CWD
[12:58] <wgrant> No.
[12:58] <bigjools> ah
[12:58] <wgrant> In pythonpath.
[12:58] <bigjools> ah
[12:58]  * bigjools experiments
[12:58] <wgrant> The egg is all set up. It works fine.
[12:58] <wgrant> If you add it to setup.py and rerun buildout, you'll see it listed when you run bin/twistd
[12:58] <wgrant> So we just need to make a *second* twistd, that only has txlongpoll.
[12:58] <bigjools> we do?
[12:59] <wgrant> Since our normal twistd uses the deps from setup.py
[12:59] <bigjools> ah right
[12:59] <wgrant> It's for running LP stuff.
[13:00] <bigjools> how do you rename the generated script name?
[13:00] <bigjools> ah never mind
[13:02] <deryck> Morning, everyone.
[13:02] <jtv> hi deryck
[13:02] <bigjools> morning deryck
[13:02] <bigjools> wgrant: know what's up here? "Error: Picked: Twisted = 11.0.0"
[13:03] <wgrant> bigjools: Possibly because you're using include_site_packages.
[13:03] <bigjools> ok let's try false
[13:03] <bigjools> nope
[13:03] <bigjools> I have no idea what that error even means
[13:04] <bigjools> I'd not know it was an error if it were not preceded with "Error" ...
[13:05] <bigjools> ah think I found it
[13:05] <bigjools> and no
[13:14] <deryck> abentley, adeuring -- can we standup at 20 after?  I have another call at the bottom of the hour today.
[13:15] <adeuring> deryck: sure
[13:15] <abentley> deryck: sure
[13:16] <deryck> great, thanks guys.
[13:35] <flacoste> bigjools: i'm hopping on call with deryck
[13:36] <flacoste> bigjools: but I could help you with that buildout after it, you could also grab gary_poster or benji to help out in the mean time
[13:37] <gary_poster> bigjools: you need to set versions.cfg to specify Twisted = 11.0.0
[13:39] <wgrant> jelmer: Did you intend to bump the bzr-git revision when you regenerated sourcedeps.cache?
[13:45] <jelmer> wgrant: argh, sorry. That should have been in the original commit.
[13:46] <wgrant> Ah, sure.
[13:47] <danilos> flacoste, hi, do you have any suggestions on what we should do with launchpad-results (it's part of launchpad-project, but we don't have privileges to triage bugs)? lifeless believes we should make it match lp-project standards for bug supervision
[13:54] <mrevell> Hey deryck or gary_poster, do you think you could spare someone to finish implementing Huw's 503 page? (https://code.launchpad.net/~huwshimi/launchpad/503-error-844631) Huw tells me he has taken it as far as he can.
[13:55]  * gary_poster looking, mrevell
[13:57] <gary_poster> mrevell, sure, I can put it in our (pretty short) backlog.  bonus points if you mark the bug escalated or critical :-P but not necessary
[14:01] <mrevell> Thanks gary_poster! We consider Launchpad to be a stakeholder, so perhaps I could escalate it. It's producing an OOPs, which we want to continue logging, but I suppose that makes it critical. I'll mark it critical and ask lifeless' forgiveness if need be :)
[14:01] <gary_poster> mrevell :-) ok cool
[14:03] <wgrant> mrevell, gary_poster: It's fastdowntime-related and an OOPS, so it can be critical. Doesn't need escalation :)
[14:03] <mrevell> superb
[14:03] <gary_poster> wgrant, cool :-)
[14:15] <bigjools> gary_poster: hello!
[14:15] <bigjools> my buildout saviour
[14:15] <gary_poster> hey bigjools
[14:15] <gary_poster> heh
[14:15] <bigjools> gary_poster: what I am doing is adding a script recipe to generate a "microservice"
[14:16] <bigjools> versions.cfg already has Twisted = 11.0.0
[14:16] <gary_poster> bigjools, script recipe from what
[14:16] <gary_poster> this is in Launchpad
[14:16] <gary_poster> 's setup.py I assume
[14:16] <bigjools> not in setup, I am taking the txlongpoll egg and writing some buildout config to try and make it generate me a script
[14:17] <bigjools> lifeless has banned changing setup.py for external scripts
[14:17] <bigjools> which is fair enough
[14:17] <gary_poster> bigjools, ok.  Oh, interesting.  (I don't think I'm breaking that in my current branch..._
[14:17] <gary_poster> )
[14:18] <gary_poster> bigjools, my memory is a bit fuzzy on all this, but I bet if I look at it I'll have an idea.  Do you have a branch for me?
[14:18] <bigjools> I'll paste you my change, one sec
[14:19] <bigjools> gary_poster: http://pastebin.ubuntu.com/693799/
[14:19] <bigjools> gary_poster: argh
[14:19] <bigjools> sorry hang on
[14:19] <bigjools> gary_poster: http://pastebin.ubuntu.com/693800/
[14:19] <bigjools> the first one is the whole file, that's just the diff
[14:19] <gary_poster> bigjools, An error with "Picked" is definitely complaining about "You didn't tell me which version to use, so I had to guess, and you told me to complain, so I'm complaining".  So the question is, why isn't versions.cfg good enough
[14:19] <gary_poster> ok
[14:20] <bigjools> gary_poster: oh I wonder if it doesn't like the txlongpoll egg then
[14:21] <bigjools> since that's the part that requires twisted
[14:22] <gary_poster> um
[14:22] <gary_poster> maybe.  I wouldn't have guessed so.
[14:22] <gary_poster> lemme try applying this.  1 sec
[14:22] <bigjools> you'll need to update your eggs
[14:22] <bigjools> well, dists
[14:23] <gary_poster> k
[14:26] <gary_poster> bigjools, I see "Error: Picked: txlongpoll = 0.2".  Fixing versions.cfg for that...
[14:26] <bigjools> gary_poster: weird, I don't see that
[14:28] <gary_poster> bigjools, ok now duped Twisted problem.  Looking more...
[14:28] <bigjools> gary_poster: ah right sorry, I had already applied the change to versions.cfg and didn't tell you :)
[14:28] <gary_poster> :-) cool
[14:28] <rvba> gmb: Could you mentor a review of mine? (the branch it self is from allenap)
[14:33] <gary_poster> bigjools: txlongpoll says it depends on twisted not Twisted.  The name is Twisted, and everything else spells it as such.  Apparently this confuses setuptools and/or buildout code.  You can verify by editing eggs/txlongpoll-0.2-py2.6.egg/EGG-INFO/requires.txt to have Twisted, not twisted.  Then build will complete successfully.  I suggest changing setup.py in txlongpoll and rolling a new release.
[14:33] <bigjools> argh
[14:33] <bigjools> I thought it might be something like that
[14:33] <bigjools> thanks gary_poster
[14:33] <gary_poster> welcome bigjools
[14:34] <bigjools> I can't do enough releases
[14:34] <gary_poster> :-)
[14:36] <flacoste> danilos: i agree with lifeless
[14:36] <danilos> flacoste, cool, so what do we do about it? ask cr3 to fix it all for us? :)
[14:37] <cr3> danilos: oh oh, what's this I hear about work?
[14:38] <flacoste> danilos: or ask a losa  if cr3 isn't responsive enough :-)
[14:39] <cr3> flacoste: good assumption! it would indeed make sense to have danilos on /ignore
[14:39] <gmb> rvba: Sorry, was otp. Certainly, I'd be happy to.
[14:39] <rvba> gmb: Thanks, here you go: https://code.launchpad.net/~allenap/launchpad/longpoll-storm-events/+merge/76215
[14:40] <gmb> rvba: Okay, I'll take a look shortly.
[14:40] <cr3> flacoste: seriously though, is this about builders, hardwaredb, results tracker or something else? I'm not seeing an obvious thread by scrolling above
[14:41] <flacoste> cr3: it's about the bug supervisor for launchpad-results
[14:41] <benji> gmb: if you get a minute to look at a simple lazr.restful branch, I'd appreciate it: https://code.launchpad.net/~benji/lazr.restful/bug-854695/+merge/76230
[14:41] <cr3> aha! I see now, bugs in launchpad-results. where can I familiarize myself with lp-project standards for bug supervision, I'm all for following that too
[14:41] <gmb> benji: I'll add it to my list.
[14:42] <benji> thanks
[14:42] <cr3> flacoste: someone did ask me to triage them more quickly before, which I've been doing so far.
[14:42] <flacoste> cr3: we'd like to change the bug supervisor so that the lp team can triage the bugs
[14:42] <cr3> flacoste: I suspect that "critical" might appear as a big red light on your radar though
[14:43] <flacoste> also
[14:43] <cr3> flacoste: if you change the bug supervisor to launchpad itself and I'm not a member of launchpad engineers, won't that case problems for me?
[14:43] <cr3> s/case/cause/
[14:44] <flacoste> cr3: we should create a new team and make ~launchpad part of it
[14:44] <cr3> flacoste: we've got ~launchpad-results, could we use that?
[14:46] <cr3> flacoste: I changed bug supervisor of launchpad-results to ~launchpad-results so, if you add that team to ~launchpad, we should be good to go
[14:46] <sinzui> gmb, do you have time to review https://code.launchpad.net/~sinzui/launchpad/dsp-official-branches-0/+merge/76128
[14:47] <flacoste> cr3: we want to add ~launchpad to ~launchpad-results
[14:47] <gmb> sinzui: I'll add it to my queue. Shouldn't be a problem.
[14:47] <cr3> flacoste: done
[14:53] <flacoste> cr3: thanks
[15:12] <danilos> cr3, thanks from me as well (if I am still not on your /ignore list :)
[15:13] <danilos> cr3, and I hope you won't be bothered with lp-devs mistriaging bugs for launchpad-results from now on, because that's what we do :)
[15:14] <adeuring> gmb: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/bug-739052-9/+merge/76241?
[15:15] <gmb> adeuring: There's a couple of branches in the queue in front of you, but I'll try to get to it.
[15:15] <adeuring> gmb: ok, thanks
[15:15] <cr3> danilos: bugs for launchpad-results are on my super sonic radar, so I'd like to see you try mistriaging bugs :)
[15:53] <bigjools> flacoste: your guess was right about the clashing twisted paths
[15:54] <flacoste> bigjools: do we need to use a plugins? can't we use a regular tac file?
[15:54] <bigjools> flacoste: we can't
[15:54] <bigjools> tacs don't let you pass command line args
[15:55] <bigjools> flacoste: ah I may be talking cobblers
[15:55] <bigjools> it does find it but there's an import error that twisted was masking
[15:55] <bigjools> hence ignoring the plugin
[16:05] <bigjools> gary_poster: I have an extra directory in txlongpoll that also needs to be in the egg. How do I make that happen?
[16:09] <gmb> sinzui: r=me with grammatical nitpicks
[16:10] <sinzui> thank you
[16:11] <nigelb> sinzui: Heh, re: the mailing list thread - Of course, you're the expert in mass bug status changes :P (j/k)
[16:12] <sinzui> nigelb, indeed. This script is actually from my 18 month effort to make sense of Lp's bugs
[16:13] <nigelb> sinzui: Its interesting how LP bugs are all Critical, High, or Low.
[16:13] <nigelb> I liked what stub suggested
[16:13] <nigelb> Critical should be reserved for things that need overnight/weekend fixing.
[16:14] <sinzui> There are only three states. LP engineers like to bend Lp rules while telling other projects not to do it
[16:15] <nigelb> sinzui: Which turns out to be - "Now!", "Some time in the next 6 months", "not any time soon"
[16:15] <sinzui> nigelb, The three states are: do now (move to the top of the schedule), do next (schedule), do whenever (wait for an opportunity when fixing another bug)
[16:17] <nigelb> sinzui: ah! that makes sense, yes.
[16:17] <nigelb> I tend to pick bugs from the last queue since those are the most unloved.
[16:18] <sinzui> nigelb, right. The performance-bugs-critical experiment failed because we could not distinguish between operational-critical bugs. maintenance squads work on critical (yet tagged work), feature squads work on high(yet tagged work)
[16:18] <nigelb> Ah.
[16:19] <bigjools> sinzui: case in point being the fact that poppy is still not fixed
[16:19] <nigelb> I was curious how feature squads picked work
[16:20] <bigjools> it's down to the lead, who is the project manager for that feature
[16:20] <sinzui> We tag bugs to be part of a feature. We mark the required ones as high, and the optional ones as low.
[16:21] <sinzui> nigelb, oh, and we mark those that happen to be oopes/regressions/timeouts as critical to remind our selves they really need to be fixed
[16:21] <nigelb> ah
[16:21] <nigelb> so, that explains the tags that I've seen
[16:22] <nigelb> and somewhere in betweeen the escalated bugs also come into play. I'm guessing those go to maintenance queue.
[16:22] <sinzui> nigelb, I would like to user words that help developers and users know what is going to happen when the bug's importance is set. maybe essential, expected, optional
[16:23] <nigelb> sinzui: Actually, it would be awesome if teams had the ability to Change bug statuses.
[16:23] <nigelb> Like, a project says, we will rename Critical to -> X, High -> Y, Low -> Z. We won't use the others.
[16:24] <nigelb> s/teams/projects
[16:26] <bigjools> flacoste: do you know how to get a non-python file in an egg?
[16:26] <sinzui> nigelb, I put some thought to that. We already map external importance to Lp importance. We could support a project mapping that permits qualification of the importance. There could be three mapping to low, one meaning  a feature request, a bug in the rules, a rare oops that users can recover from
[16:27] <nigelb> sinzui: But those can be done with status + tags. I like having fewer statuses than more.
[16:28] <sinzui> nigelb, me too. I never suggested we support that level of customisation. project owners sometimes ask for it, but that undermines inter-project collaboration
[16:28] <sinzui> User just want meaningful labels.
[16:29] <gary_poster> bigjools, /me lunching, but just saw your question.  The sarcastic solution is to use subversion, since setuptools has automatic support for that and only that.  The real solution is to use MANIFEST.in.  This is an underdocumented Python thingy.  Lemme see if I can find you the docs...
[16:30] <bigjools> gary_poster: ok thanks.  It's an xml file that the project needs to load at runtime :(
[16:32] <gary_poster> bigjools, ack.  So, the docs are http://docs.python.org/distutils/sourcedist.html and in particular http://docs.python.org/distutils/sourcedist.html#manifest-template .  A number of ye olde lazr.* packages have them, for .txt files and so on.  Here's an example: http://bazaar.launchpad.net/~lazr-developers/lazr.restful/trunk/view/head:/MANIFEST.in
[16:32] <bigjools> gary_poster: you rock, thanks
[16:32] <gary_poster> welcome
[16:33] <bigjools> gary_poster: ah so does it override the packages= on the setup() ?
[16:33] <nigelb> sinzui: Agreed (sorry, connection is being flaky today)
[16:34] <gmb> adeuring: I'm not going to be able to get through your branch before my EoD. Might be worth asking the next OCR, which is... StevenK, if I'm not mistaken.
[16:34] <adeuring> gmb: sure, no problem.
[16:35] <gmb> Thanks.
[16:46] <sinzui> jcsackett, do you have time to mumble
[16:48] <gary_poster> bigjools, sorry, had wandered away again.  AFAIK, it is different.  It describes what files locally in this directory tree should be included.  I don't think you can tell python files specified in packages= to take a hike, but then I've never tried.  Maybe it does override.  I've always done both.
[16:49] <bigjools> gary_poster: yeah I have it working nicely now, thanks
[16:49] <gary_poster> awesome
[17:30] <jcsackett> sinzui: i can mumble now--i was grabbing lunch when you pinged me. does now work for you?
[17:30] <sinzui> jcsackett, too late. I have a meeting with flacoste in 0 seconds
[17:30] <sinzui> Can we talk in about an hour?
[17:30] <jcsackett> sinzui: certainly.
[17:31] <flacoste> sinzui: skype time?
[17:31] <sinzui> flacoste, I am ready
[18:00] <cr3> is there a difference between the verb "new" and "create" in the launchpad api? is one preferred over the other in some circumstances?
[18:19] <flacoste> cr3: no. there isn't, fixing this inconsistency would be nice
[18:59] <sinzui> hi jcsackett. Do you have time to mumble?
[18:59] <jcsackett> sinzui: sure, just a moment.
[19:01] <jelmer> abentley: I'm pretty sure bug 854654 is a dupe
[19:01] <_mup_> Bug #854654: Cyrylic nicknames in ADC are not allowed <FlexHub:Confirmed> < https://launchpad.net/bugs/854654 >
[19:02] <jelmer> ehm, bug 854964
[19:02] <abentley> jelmer: I couldn't find another bug like it.
[19:02] <_mup_> Bug #854964: 2a format permits fetching tree-reference entries <2a> <nested-trees> <Bazaar:New> < https://launchpad.net/bugs/854964 >
[19:02] <jelmer> I recall filing one in the past, but can't find it now either..
[19:03] <abentley> jelmer: anyhow, it damages the prospects of converting the subtree branches to 2a, because we don't know what might be in their history.
[19:05] <abentley> jelmer: even though lp:~ebbe/+junk/game is the only one that could not be pulled into a 2a branch.
[19:46] <lifeless> sinzui: your summary of medium bugs includes low bugs
[19:46] <lifeless> sinzui: is it stale?
[19:48] <sinzui> lifeless, I think I need to recheck the rules. I expected duplicates from multiple bug tasks, but not actual errors
[19:49]  * sinzui rechecks the script
[19:49] <lifeless> sinzui: I just invalidated the bug about email processing not being tested enough
[19:49] <lifeless> as a not-useful-bug
[19:49] <lifeless> but
[19:49] <lifeless> it was low
[19:49] <lifeless> and in your list of mediums :)
[19:49] <lifeless> you made it low yourself not long ago
[19:51] <sinzui> ha, I tend to do that when I view a Medium bug. My new report will be done in a few minutes.
[19:52] <lifeless> it was bug 30138
[19:52] <_mup_> Bug #30138: Notifications generated by the email interface should be properly tested <email> <lp-bugs> <story-better-notification-sending> <test-system> <Launchpad itself:Invalid> < https://launchpad.net/bugs/30138 >
[19:53] <sinzui> ah, I am not getting open-only bugs. So much for the default search rules.
[19:53] <lifeless> sinzui: you are
[19:53] <lifeless> sinzui: I *closed* it when I saw it in the list.
[19:53] <sinzui> :)
[19:54] <lifeless> sinzui: my concern is that it was *low* since '2011-08-26'
[19:54] <lifeless> so your list must be a month old or something
[19:54] <lifeless> (a month old | buggy)
[19:54] <lifeless> if its a month old its fine. If its buggy its not :)
[19:55] <sinzui> While the script pre-exists, the list was made this morning. I wonder if I have cached bugs
[19:55] <timrc> anyway to get at ppa creation date from the web service api?
[19:55] <lifeless> then there was something significantly wonky
[19:55] <timrc> does not look like it from my cursory check :/
[19:56] <lifeless> sinzui: I see 967 medium bugs
[19:56] <lifeless> sinzui: ah, thats lp; lp-project: 1068
[19:57] <sinzui> yes, I am searching lp-project
[19:57] <lifeless> sinzui: I think we can just close many of these
[19:57] <lifeless> e.g. https://bugs.launchpad.net/launchpad/+bug/3454
[19:57] <_mup_> Bug #3454: Should have a UI for assigning multiple tasks to a milestone <lp-bugs> <milestone-management> <Launchpad itself:Triaged> < https://launchpad.net/bugs/3454 >
[19:57] <sinzui> Well I think that of many low bugs. as well
[19:58] <lifeless> its obviously a work item in planned work, rather than a defect report describing a users issue / limitation the user encountered.
[19:58] <lifeless> I will do a table scan of these.
[19:58] <sinzui> I remind myself that if a user provided a patch, I would accept it
[19:58]  * lifeless opens 100 tabs
[19:59] <lifeless> okok, 75
[19:59] <nigelb> ...
[19:59] <nigelb> lifeless: Aren't you supposed to be away today?
[19:59] <sinzui> lifeless, the feature aspect of the bug is an interesting point considering that many of the bugs are reported by us as an idea that seamed relevant 3 years ago
[20:00] <lifeless> sinzui: I agree
[20:01] <lifeless> sinzui: but I think for most things we have no shortage of ideas on how to improve; they don't generally have value like a report of how something affected a user.
[20:01] <lifeless> sinzui: I won't be cavalier
[20:01] <lifeless> sinzui: if you want to take the second page of a web search for medium bugs in -project, default sort order; we could triage 10% of the total in about 10 minutes.
[20:02] <lifeless> nigelb: yes, but thats never stopped me.
[20:02] <sinzui> jml said something similar. I wish I could remember the exact phrasing of his witticism.
[20:02] <nigelb> lifeless: Good point. I was planning to pick your brains tomorrow morning.If you will be around later today, I might just do that :)
[20:02] <lifeless> nigelb: Think of it as priorities: today my priority is my family. But I may do somework. On work days my priority is work, but I may look after my family.
[20:02] <nigelb> lifeless: Well said :)
[20:04] <sinzui> lifeless, the difference in my numbers and lp-projects numbers is that I not subscribed to all private bugs :)
[20:06] <lifeless> sinzui: sure, but how did that low bug get in the list ?
[20:07] <sinzui> lifeless, I cannot explain. My revised report only shows mediums: http://pastebin.ubuntu.com/694004/
[20:09] <sinzui> lifeless, sorry. I ran against qastaging!
[20:09]  * sinzui runs against lpnet
[20:10] <lifeless> sinzui: haha :)
[20:14] <lifeless> do we support debtags yet ?
[20:15] <lifeless> no :)
[20:19] <lifeless> bug 4730 - does the publisher have a --dry-run ?
[20:19] <_mup_> Bug #4730: Publisher tool option to only change the database, not the archive <lp-soyuz> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/4730 >
[20:20] <lifeless> hah
[21:05] <sinzui> jcsackett, r=me
[21:05] <jcsackett> sinzui: hurray!
[21:05] <jcsackett> sinzui: any chance this can wait a bit too land? i'd like to take some time to debug my ec2 issues and having a branch to send out would be nice. :-)
[21:06] <jcsackett> s/too land/to land/
[21:06] <sinzui> land as you you wish
[21:07] <lifeless> sinzui: https://bugs.launchpad.net/launchpad/+bug/34343
[21:07] <_mup_> Bug #34343: Shouldn't allow task or blueprint reassignment to an upstream that doesn't use Launchpad <lp-blueprints> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/34343 >
[21:08] <lifeless> sinzui: did we perhaps fix-by-driveby that ?
[21:08] <sinzui> hmm
[21:09] <sinzui> lifeless, I do not think so. I reported that bugs has the same error last month
[21:09] <lifeless> ah, so there is a dupe out there ? :)
[21:10] <sinzui> lifeless, this they are not since we need three vocabs, each to represent valid spectarget, bugtarget, and questiontarget
[21:10] <sinzui> The current fields only require an active target
[21:11] <lifeless> ahhh! - you know that librarian bug
[21:11] <lifeless> waaaay old dup
[21:11] <lifeless> https://bugs.launchpad.net/launchpad/+bug/34758
[21:11] <_mup_> Bug #34758: librarian will set type to text/html though it should be text/plain <infrastructure> <librarian> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/34758 >
[21:12] <lifeless> ah no its not
[21:12] <sinzui> I do not think it is either.
[21:23] <lifeless> do we have a formatter for libraryfilealias ?
[21:28] <lifeless> nearly done
[21:38] <lifeless> \o/
[21:38] <lifeless> 10% done
[21:53] <lifeless> I hope I didn't overwhelm anyone's mail queue :)
[22:40] <sinzui> wallyworld_, wgrant, StevenK. I will be 15 minutes late to the standup
[22:40] <wallyworld_> sinzui: ok
[22:50] <lifeless> james_w: hi


[02:15] <KGB-0> amtk upstream/latest 867f0b2 Sébastien Wilmet amtk/meson.build meson.build * build: don't specify any 'soversion' or 'version' for the library * https://deb.li/3BR6M
[02:15] <KGB-0> amtk upstream/latest af960f7 Sébastien Wilmet amtk/meson.build * build: set 'soversion' to 0 in the library() call * https://deb.li/ZLZ1
[02:15] <KGB-0> amtk upstream/latest f0029cf Sébastien Wilmet NEWS meson.build * Release 5.6.1 * https://deb.li/3LooN
[02:15] <KGB-2> amtk pristine-tar 576f4a1 Jeremy Bicha amtk_5.6.1.orig.tar.xz.delta amtk_5.6.1.orig.tar.xz.id * pristine-tar data for amtk_5.6.1.orig.tar.xz * https://deb.li/ip4xg
[02:15] <KGB-0> amtk upstream/latest 91359fd Jeremy Bicha NEWS amtk/meson.build meson.build * New upstream version 5.6.1 * https://deb.li/0mqV
[02:16] <KGB-0> tepl signed tags b0efddb Jeremy Bicha upstream/6.2.0 * Upstream version 6.2.0 * https://deb.li/3Z4hs
[02:16] <KGB-2> tepl pristine-tar eac6a94 Jeremy Bicha tepl_6.2.0.orig.tar.xz.delta tepl_6.2.0.orig.tar.xz.id * pristine-tar data for tepl_6.2.0.orig.tar.xz * https://deb.li/xKg4
[02:16] <KGB-0> tepl upstream/latest 2a70a41 Jeremy Bicha * pushed 26 commits (first 5 follow) * https://deb.li/BNiv
[02:16] <KGB-0> tepl upstream/latest 828539c Sébastien Wilmet tests/other-tests/test-utils-gsettings.c * utils: test tepl_utils_can_use_gsettings_key() * https://deb.li/30lcn
[02:16] <KGB-0> tepl upstream/latest 6f6dbaf Sébastien Wilmet docs/reference/api-breaks.xml * docs: ABI breaks, just need to re-compile the program * https://deb.li/dl0e
[02:16] <KGB-0> tepl upstream/latest 5d04dd8 Sébastien Wilmet docs/ more-information.md reference/intro.xml * docs: about the library soname * https://deb.li/31mC0
[02:16] <KGB-0> tepl upstream/latest 763708c Sébastien Wilmet meson.build * build: rework libtool/soname version handling * https://deb.li/3pL2A
[02:16] <KGB-0> tepl upstream/latest afe64d3 Sébastien Wilmet tests/interactive-tests/test-tab.c * test-tab: remove TeplIoErrorInfoBar tests * https://deb.li/iQo9i
[07:12] <oSoMoN> good morning
[07:45] <didrocks> good morning
[08:04] <lissyx> oSoMoN, good news bad news, llvm 15 has no x86-64 linux binary release over github
[08:05] <lissyx> oSoMoN, the only solution seems to use their apt repo, but I dont know how well that can work with snap build?
[08:11] <lissyx> https://snapcraft.io/docs/package-repositories#heading--examples ?
[08:50] <oSoMoN> salut didrocks
[08:50] <oSoMoN> salut lissyx
[08:50] <oSoMoN> lissyx, yes, I hadn't bumped the llvm dependency precisely because there was no linux binary available on github
[08:50] <oSoMoN> it's probably worth asking whether they intend to produce one
[08:52] <oSoMoN> falling back to the apt repo would be interesting, but they don't build armhf binaries
[08:53] <lissyx> oSoMoN, so it's up to contributors to uploading one
[08:53] <lissyx> I'm trying to do that apt alternative, but I get weird behavior
[08:53] <lissyx>  0:01.43 checking for the target C compiler... /snap/gnome-3-38-2004-sdk/current/usr/bin/gcc
[08:53] <lissyx> does it makes sense we try to use gcc from gnome-sdk ?
[08:53] <oSoMoN> lissyx, is that the official answer you got from the LLVM project (re release assets)?
[08:54] <lissyx> I dont know if it qualifies as official answer from llvm project
[08:54] <lissyx> but several people asked about that on discourse and this was the reply
[08:54] <lissyx> also this is what sylvestre and glandium told me on matrix :)
[08:58] <oSoMoN> I just found https://github.com/llvm/llvm-project/issues/58004
[08:58] -ubottu:#ubuntu-desktop- Issue 58004 in llvm/llvm-project "clang+llvm-15.0.1-amd64-unknown-linux-gnu builds" [Open]
[08:58] <oSoMoN> looks like whoever usually produces the linux x86-64 builds is MIA
[09:01] <lissyx> I have some build starting with clang-15 from LLVM's apt repo
[09:08] <lissyx> oSoMoN, would switching to mozilla's bundled toolchain be a valid alternative?
[09:10] <oSoMoN> lissyx, if it's available for all the architectures we need to support (amd64, arm64, armhf), absolutely
[09:10] <lissyx> oSoMoN, I'm getting a weird build failure now
[09:11] <lissyx> > 6:25.53 /bin/sh: 1: --stop-server: not found
[09:11] <lissyx> which is likely from client.mk's call to sccache stop
[09:11] <lissyx> but it should not be done...?
[09:11] <oSoMoN> looks like the name of the executable is missing from the call
[09:11] <lissyx> oh no
[09:12] <lissyx> it's a fallout from a previous failure
[09:12] <lissyx> 4:11.51 clang: error: unable to execute command: Executable "wasm-ld-15" doesn't exist!
[09:17] <lissyx> oSoMoN, I think we support all those three, but arm* are cross-compiled for sure
[09:24] <lissyx> oSoMoN, yeah so no native toolchain on arm*
[10:20] <lissyx> oSoMoN, that being said, I'm still  wondering if it's expected we build with gcc from gnome-sdk?
[10:23] <oSoMoN> lissyx, no, the C compiler should be clang
[10:42] <lissyx> oSoMoN, have a look at the build log then :)
[10:46] <oSoMoN> https://launchpadlibrarian.net/633853973/buildlog_snap_ubuntu_focal_amd64_firefox-snap-beta_BUILDING.txt.gz reports that clang is being used to build firefox
[12:08] <Wimpy> Hello desktopers o/
[12:09] <oSoMoN> hey Wimpy
[12:09] <Wimpy> Hello you :-)
[12:12] <Wimpy> Who here has good understand on creating "custom" GNOME sessions?
[12:15] <Wimpy> I've made a custom session which is just Mutter and appropriate settings components, defined in `/usr/share/gnome-session/sessions/butterfly.session`
[12:16] <Wimpy> I've also created `/usr/share/xsessions/butterfly-xorg.desktop` and `/usr/share/wayland-sessions/butterfly-wayland.desktop`
[12:18] <Wimpy> Both the script in `/usr/libexec/butterfly` which starts `gnome-session --builtin --session=butterfly`
[12:19] <Wimpy> LightDM and GDM both see the sessions I've added, and both can start the Butterfly Xorg session. But Butterfly Wayland fails to start and drops back to the display manager.
[12:19] <Wimpy> I can't see any obvious errors in the logs.
[12:20] <Wimpy> Testing in a QEMU VM and the Ubuntu session works just fine, so I don't believe this is an issue with drivers/GL support.
[12:21] <oSoMoN> Trevin_ho might be able to help
[12:23] <Wimpy> Is he on vacation?
[12:59] <oSoMoN> not as far as I can tell, but he's always working in an unpredictable time zone :)
[13:00] <Wimpy> Heh :-)
[13:01] <jbicha> good morning
[13:02] <Wimpy> o/
[13:04] <lissyx> oSoMoN, interesting, locally I see the GCC from GNOME SDK being used
[13:04] <lissyx> oSoMoN, also, moving to rust 1.64 I'm hitting a new failure:  5:33.94 /snap/gnome-3-38-2004-sdk/current/usr/bin/ld.gold: fatal error: out of file descriptors and couldn't close any
[13:06] <oSoMoN> that doesn't look good
[13:07] <lissyx> no
[13:07] <lissyx> and you can see, ld.gold from gnome-sdk
[13:09] <lissyx> oSoMoN, I've disabled PGO as well as the xvfb-run call, maybe this explains why it picks the incorrect compiler?
[13:09] <lissyx> either way we should make sure it's not possible
[13:11] <oSoMoN> I'm running a local build with clang-15 from apt.llvm.org, I'll let you know how that goes (my machine is not as beefy as yours so it takes a while)
[13:12] <lissyx> I tried to do that earlier this morning
[13:12] <lissyx> and it was failing due to obscure stuff around wasi-sdk
[13:14] <oSoMoN> yeah, I'm worried that it might not work because the latest release of wasi-sdk (16) is built against llvm 14
[13:16] <lissyx> either way, if gnome-sdk has some compiler we should likely force CC/CXX in mozconfig.in to use the clang one we want
[13:41] <lissyx> oSoMoN, hm even with correct CC/CXX I get wrong linker
[14:05] <lissyx> oSoMoN, so: https://paste.mozilla.org/p2PQpWWy
[14:05] <lissyx> oSoMoN, I'm getting stuff forward with that
[14:15] <lissyx> trying to re-instate PGO
[14:30] <lissyx> oSoMoN, ok, so I've put back PGO and it's broken again :)
[14:46] <lissyx> oSoMoN, https://firefox-source-docs.mozilla.org/build/buildsystem/pgo.html any reason you force --enable-linker=gold and --enable-lto=cross ?
[15:57] <oSoMoN> lissyx, gold is required to enable LTO, see https://llvm.org/docs/GoldPlugin.html
[15:59] <oSoMoN> and --enable-lto=cross is for performing LTO between C++ code and Rust code (see https://bugzilla.mozilla.org/show_bug.cgi?id=1546438)
[15:59] -ubottu:#ubuntu-desktop- Mozilla bug 1546438 in Firefox Build System "add `--enable-lto=cross` option" [Normal, Resolved: Fixed]
[15:59] <oSoMoN> so those two options are LTO-specific, not PGO
[15:59] <oSoMoN> IIRC this is how upstream builds are produced too
[16:02] <lissyx> oSoMoN, ok, well, even if we install binutils in build-packages section of firefox part, it still uses ld.gold from gnome-sdk ...
[16:02] <lissyx> and it fails on that, somehow.
[17:23] <lissyx> oSoMoN, rust 1.64, no lto/gold, kept only pgo and still segfault.
[17:25] <oSoMoN> lissyx, do you also see the segfault when running xpcshell to generate a file that describes the local Normandy client, or is it failing somewhere else?
[17:25] <lissyx> I'm not yet that far
[17:26] <lissyx> I was hoping to was llvm14 + rust 1.65 ...
[17:26] <lissyx> but now I'm certain it's not the case
[17:26] <lissyx> so i'll try and poke around there yes
[17:26] <lissyx> I know it's a long shot, but the double '/' might
[17:27] <oSoMoN> I don't think so, I ran the command locally (without modifications) in the snapcraft shell and it generated the file correctly
[17:28] <oSoMoN> which suggests there is something in the build environment that triggers this crash, rather than the xpcshell binary itself being faulty
[17:29] <lissyx> yes
[17:30] <lissyx> and the env contains: 242:47.79 env LD_LIBRARY_PATH="/snap/gnome-3-38-2004-sdk/current/usr/lib/x86_64-linux-gnu:/snap/gnome-3-38-2004-sdk/current/usr/lib:../../dist//bin" :)
[17:30] <lissyx> 'dist//bin'
[17:30] <lissyx> oSoMoN, how exactly did you manually ran?
[17:36] <oSoMoN> lissyx, I ran `snapcraft --use-lxd --debug` to ensure I'm dropped into a shell when the failure happens, then I cd'ed to /root/parts/firefox/build/obj-x86_64-pc-linux-gnu/instrumented/dist/bin and ran the command that's reported to cause the segfault
[17:37] <lissyx> ok
[17:53] <lissyx> oSoMoN, same here.
[17:53] <lissyx> I'm wondering if xvfb-run could be acting?
[17:54] <oSoMoN> lissyx, that should be easy enough to test, if you're there
[17:54] <oSoMoN> (I have a clean build running now)
[17:54] <lissyx> well I tested and it did not repro
[17:54] <lissyx> but I'm not sure it's completely valid test
[17:55] <lissyx> there are so many env var we miss running manually?
[17:55] <lissyx> and I need to go now
[17:55] <oSoMoN> yes indeed, and they are not easy to set up
[17:55] <oSoMoN> let's continue debugging this tomorrow then
[21:13] <KGB-0> gedit signed tags 1a315a2 Jeremy Bicha upstream/43.1 * Upstream version 43.1 * https://deb.li/3q9Bh
[21:13] <KGB-2> gedit pristine-tar 5aeb3a9 Jeremy Bicha gedit_43.1.orig.tar.xz.delta gedit_43.1.orig.tar.xz.id * pristine-tar data for gedit_43.1.orig.tar.xz * https://deb.li/E0RI
[21:13] <KGB-0> gedit upstream/latest 2257a5f Jeremy Bicha * pushed 170 commits (first 5 follow) * https://deb.li/3iff2
[21:13] <KGB-0> gedit upstream/latest 9789717 Sergej A po/ru.po * Update Russian translation * https://deb.li/i203C
[21:13] <KGB-0> gedit upstream/latest 3e29105 Sébastien Wilmet gedit/gedit-io-error-info-bar.c * io-error-info-bar: minor code simplification * https://deb.li/wHDR
[21:13] <KGB-0> gedit upstream/latest 6f8c2ff Sébastien Wilmet gedit/gedit-io-error-info-bar.c * io-error-info-bar: better use gtk_info_bar_set_show_close_button() * https://deb.li/3t9sv
[21:13] <KGB-0> gedit upstream/latest eff97e8 Sébastien Wilmet gedit/gedit-io-error-info-bar.c * io-error-info-bar: conversion error info bar: small improvements * https://deb.li/Gfzz
[21:14] <KGB-0> gedit upstream/latest ff6ac78 Sébastien Wilmet gedit/gedit-tab.c * tab: don't use gtk_info_bar_set_default_response() * https://deb.li/3y0Us


[12:34] <stelis> Hello?
[12:34] <pygi> hi stelis
[12:34] <stelis> Hi
[12:35] <stelis> I read Richard J.'s blog entry, and was interested in helping with docs
[12:36] <stelis> Do you know who the best person to speak to is?
[12:36] <pygi> yes, me or Hedgemage
[12:36] <stelis> OK, cool.
[12:37] <pygi> nixternal: you brought a lot of people here ;)
[12:37] <nixternal> im hoping that is a good thing ;)
[12:37] <nixternal> stelis: are you familiar with Docbook?  SVN?
[12:37] <stelis> Yes to the first.
[12:38] <nixternal> don't worry if you say no, as that is fine
[12:38] <nixternal> oh wow, cool
[12:38] <stelis> FWIE, I've worked on OSS docs before
[12:38] <nixternal> that is a bonus then...great
[12:38] <nixternal> oh wow, even better!
[12:38] <nixternal> https://wiki.ubuntu.com/DocumentationTeam/Repository
[12:38] <stelis> But that was CVS rather than SVN.. I've got a checkout and built it though
[12:39] <nixternal> you can take a look there, as I have posted the docs on the doc svn repo...so it is easy to 'svn co dir/' to download them
[12:39] <nixternal> we are working out of the trunk/edubuntu/handbook/C/ directory
[12:39] <nixternal> if you grab the docs, and look in there, there are around 25 .xml files in there...you can view https://wiki.ubuntu.com/EdubuntuHandbook/Management to get an idea of the layout
[12:39] <stelis> OK, I've got that, and a test Edubuntu Edgy setup
[12:40] <nixternal> p1-xxxx.xml would be Part 1, p2 part 2 and so on
[12:40] <nixternal> you are ready to rock and roll..the LTSP stuff is pretty much taken care of...part 2 that is....part 1, part 3, and part 4 are pretty much empty yet
[12:41] <nixternal> feel free to look around and see what you might be interested in helping out with
[12:41] <nixternal> im preparing a "presentation", 1 of the about 20 i have to give in the next week or so
[12:41] <pygi> nixternal: same here, lol :)
[12:41] <pygi> but you know that already :P
[12:41] <nixternal> ya..i have a cool one i did for a master slide layout
[12:42] <nixternal> im making a Kubuntu one, Ubuntu one, and Edubuntu one...and they look like the desktops
[12:42] <pygi> oh :P I forgot I could have given you OO.Impress templates
[12:42] <stelis> FWIW, I've got screenshots of the installation process
[12:43] <stelis> Vmware makes screendumps very easy
[12:43] <nixternal> thats worth a lot actually stelis, as it prevents us from having to do it
[12:43] <nixternal> i was going to do them with vmware as well, but you beat me to it ;)  thanks
[12:44] <stelis> I've done this before :)
[12:44] <stelis> I'll upload them to a server, and post a link in a sec
[12:51] <stelis> OK, screenshots: http://www.elsn.org/downloads/edubuntu/screenshots/
[12:52] <stelis> The numbers in the filenames indicate the sequence
[12:53] <pygi> stelis: permissions pls :)
[12:53] <pygi> hehe
[12:55] <stelis> Gah, that bites me every time
[12:56] <stelis> Fixed.
[12:57] <stelis> The screen resolutions are as Vmware grabs them...
[12:57] <pygi> all fine :)
[12:57] <stelis> So 640x480 for text-mode and 1024x768 for graphical screens, I think
[12:57] <stelis> Cool.
[12:58] <stelis> Windows has recursive permissions
[12:58] <stelis> I've never adjusted to Linux not doing it
[01:03] <stelis> OK... A really basic question:
[01:03] <stelis> Target audience
[01:04] <stelis> I'm looking at the heading "Networks and Networking" and wondering how much knowledge can be assumed...
[01:04] <pygi> stelis: it's best to assume very trivial knowledge
[01:05] <stelis> Hmm...
[01:05] <pygi> not really "move your move over here...then click here..."
[01:05] <pygi> but for a regular Joe user
[01:06] <stelis> OK, so we may need to start with a link to explain terms like "IP address"?
[01:06] <pygi> lol, no :)
[01:06] <pygi> no, no, don't go with explaining what IP address is :)
[01:07] <pygi> let's assume they know the basic terms, ok? :)
[01:07] <stelis> To explain where I'm coming from...
[01:07] <stelis> I'm not sure whether the target is the professional IT technician
[01:08] <stelis> Or IT teachers
[01:08] <stelis> Whose knowledge is a bit more patchy
[01:09] <pygi> right, but we don't want to explain trivial things like IP address & stuff
[01:10] <stelis> Being *really* new to Edubuntu, I'm not sure who the adopters are
[01:10] <pygi> well, it all depends if a school has an IT professional who will install the complete Informatics system, or is the teacher the one doing it
[01:12] <stelis> Is Edubuntu being used mostly on self-contained networks?
[01:12] <pygi> ehm, you mean no access to internet?
[01:13] <stelis> More WRT to how it interacts with the institutional network and the central management
[01:14] <stelis> We have labs where central IT just provides IP addresses and walks away
[01:14] <stelis> and centrally managed ones
[01:14] <pygi> "central IT" as a person or what?!
[01:16] <stelis> I mean a central department and the management that they provide, like an LDAP directory and so on.
[01:16] <pygi> oh, well Edubuntu is actually a server ^_^
[01:16] <pygi> You run thin clients then --> pulling it from server's chroot
[01:19] <stelis> Where I work we have three workgroups which are independently managed by departmental people, who don't work for the main IT teams that run the rest of the network, and aren't necessarily IT professionals.
[01:19] <stelis> Those workgroups have their own servers
[01:20] <stelis> OS X and Netware
[01:20] <stelis> But they rely on DNS managed centrally
[01:21] <stelis> I'm wondered if Edubuntu is used in that way
[01:22] <stelis> Or in smaller organizations where the Edubuntu system is pretty much the whole network
[01:22] <stelis> So it may have to run the DNS as well (for example)
[01:25] <stelis> I guess the question is: can you say "ask your network provider for <DNS/Proxy> settings", or whether you need to assume that the reader has to sort it out fro themselves.
[01:25] <pygi> you can ask that for a reader I guess
[01:29] <stelis> Sorry if this seemed like a dumb question - I think that what I'll do is try to write a draft on the assumption that the reader has an Internet connection of some kind already, and see where it goes from there.
[01:30] <pygi> stelis: feel free to mail me at mario dot danic at gmail dot com if you want me to help you with anything, or review, or whateva :)
[01:30] <pygi> there is no dumb questions...except the one not asked
[01:30] <stelis> Thanks - you've just preempted my next question :)
[01:31] <pygi> good :P
[01:31] <stelis> Can you give me an idea of the deadlines?
[01:32] <pygi> ASAP :P
[01:33] <stelis> I guess what I'm asking is the freeze date :)
[01:33] <pygi> hm....ASAP? :)
[01:33] <pygi> preety soon actually
[01:35] <stelis> My previous experience was that the docs had to be frozen at a point before the release to allow for translation etc.
[01:35] <pygi> stelis: right, but we are already past that point
[01:35] <pygi> due to some circumstances
[01:35] <stelis> Ah
[01:36] <pygi> ah :)
[01:36] <stelis> OK - I've a suggestion
[01:36] <bddebian> Heya
[01:36] <stelis> Why not create a screencast or slideshow to walk new users through the process
[01:37] <pygi> hey bddebian :)
[01:37] <pygi> stelis: uh, uh, not now :)
[01:37] <bddebian> Hi pygi
[01:38] <stelis> My thought was it might be faster to make than the written documentation, you see
[01:38] <stelis> And then focus on the text after.
[01:39] <pygi> stelis: nop, we want the book :)
[01:39] <pygi> it is doable, trust me
[01:39] <pygi> I wrote one for dapper with hedgemage :)
[01:40] <stelis> I wrote for Fedora :)
[01:41] <stelis> A much smaller work, though :)
[01:44] <stelis> OK: if you like what I'll try to do is finish off part I (or at least a draft) in the next day or two
[01:44] <pygi> oki :)
[01:44] <stelis> I can probably also pick up part IV
[01:45] <stelis> I probably don't have the experience with LTSP to fill out the other sections.
[01:46] <stelis> Although I can probably write at least basic text for the update and security sections, if needs be.
[01:46] <pygi> stelis: no worries, I'm here to instruct and guide if needs be
[01:47] <stelis> Cheers. When I say that I'm new to LTSP...this is about day 4.
[01:49] <pygi> :)
[01:50] <stelis> It was great to realise that Edubuntu works out of the box, and that I'd didn't need to write my own dhcpd.conf just to get it started.
[02:01] <pygi> :)
[02:03] <nixternal> sorry..getting ready to head to dinner...
[02:03] <nixternal> anyways, don't worry about the LTSP section, as it is already being handled
[02:04] <pygi> bon appetit nixternal :)
[02:04] <nixternal> part 3 and 4 need the loving ;)
[02:04] <nixternal> bon McDonalds ;)
[02:04] <pygi> hehe :P
[02:04] <stelis> :)
[02:04] <nixternal> i have no clue what i said, except for McDonalds
[02:04] <pygi> good McDonalds :)
[02:04] <nixternal> I shall return, thanks stelis for your help!
[02:04] <nixternal> well, that is good ;)
[02:04] <pygi> that's what you said :)
[02:04] <nixternal> bbiab
[02:04] <pygi> oki, 2:06 am
[02:04] <stelis> Cheers
[02:04] <pygi> time for me to sleep if nobody needs me...
[02:05] <pygi> going once...
[02:05] <nixternal> pygi:
[02:05] <pygi> going twice...
[02:05] <nixternal> hey pygi
[02:05] <pygi> sold!
[02:05] <nixternal> before you go
[02:05] <nixternal> are you still here?
[02:05] <pygi> yes?
[02:05] <nixternal> oh
[02:05] <nixternal> just wanted to say good night and see if you would stick around ;)
[02:05] <nixternal> hehe
[02:06] <pygi> ergh! :)
[02:06] <nixternal> haha
[02:06] <nixternal> g;nite
[02:06] <pygi> night
[05:31] <thompa> !xgl
[05:31] <ubotu> Compiz (compositing window manager) and XGL (X server architecture layered on top of OpenGL)  -  Howto at http://help.ubuntu.com/community/CompositeManager  -  Help in #ubuntu-xgl  -  See http://tinyurl.com/pw5ez for Kubuntu systems
[05:32] <thompa> anybody going to install edgy in school?
[09:33] <RichEd> hi cbx33
[09:33] <cbx33> hey RichEd
[09:33] <RichEd> jonathan1 / highvoltage : you there ?
[09:47] <cbx33> hey jono
[09:47] <jono> hey cbx33
[09:50] <RichEd> hey jono ...
[09:51] <jono>  hey RichEd
[09:52] <RichEd> jono: We must chat soon about putting together a mini community agenda for UDS and AH ... been discussing with Matt Nazum
[09:52] <RichEd> have you planned any formal Community Slots or BOF sessions ?
[09:53] <jono> RichEd, yeah, I have been working on community slots over the last day or so - thinkabout what is needed
[09:53] <jono> RichEd, I am hoping to register them in LP later this week
[09:54] <RichEd> Great ... We would want at least one meeting with Matt Nazum and Philipp Schroder and yourself to explain our view of Education Community and the new space we are creating. Pop into here and give me a ping when you have 2 mins #ubuntu-education
[01:41] <jsgotangco> hey guys
[02:18] <pawman> Hi there can anyone help with networking
[02:55] <jsgotangco> ogra: http://toosa.oo-linux.com/cms/index.php/home/my_book
[02:58] <ogra> jsgotangco, WOW !
[03:01] <jsgotangco> it was just shown to me
[03:02] <jsgotangco> its from the indonesian team
[03:04] <ogra> thats very cool
[03:05] <luckyed> Cheerio! I'm having probs with the install cd of Edubuntu 6.10 Beta. Md5 checksum seems ok, but when I run a cd check or try to install a server, I get an error message about some files not found on the cd. Tried to download the iso twice and burned it with 8x speed the second time, but the error stays... Anyone else has experienced this or knows where to get a proper iso image???
[03:06] <ogra> if the Cd check fails but md5 is fine, you likely burned the CD to fast
[03:07] <ogra> try 4x
[03:07] <ogra> apart from that see the /topic for the download URL
[03:11] <luckyed> ogra: That's where I got the image, but it didn't work. Has anyone actually succeeded in installing from the install cd? Just wanna know...
[03:11] <ogra> (on all arches)
[03:12] <ogra> so yes, its working for me ...
[03:12] <luckyed> OK, sounds convincing. I'll give it one more try! :)
[03:12] <ogra> and for various other testers as well
[03:12] <ogra> btw, the server install is whats on the ubuntu-server iso ... very likely not what you want
[03:12] <ogra> (there is a translation error in the first Cd screen)
[03:13] <ogra> should be "commandline minimal install" instead
[03:13] <ogra> if you want the edubuntu classroom server, just use the default item (install to HD or so)
[03:15] <luckyed> I'm actually writing from an installed version of edubuntu 6.10, but it's installed from the live cd and thus the ltsp stuff is not set up. And the ltsp packages in synaptic are the wrong ones, aren't they?
[03:16] <ogra> no
[03:16] <ogra> just dont use the ltsp-utils package (which should be gone from edgy anyway)
[03:16] <luckyed> ahem, and you're right, I meant the classroom server install, not the "server install", as I need gnome, too...
[03:16] <ogra> but the installer sets up a bunch of defaultsd you will miss if you install ltsp manually
[03:18] <luckyed> hmm, I thought so. Install cd is just burning with 4x this time..... let's see
[03:19] <luckyed> ah, and btw: Would it be possible to use the upgrade function from 6.10 to 6.10 without messing up the ltsp installation or anything else?
[03:19] <luckyed> 6.06. to 6.10....
[03:20] <luckyed> ...because I've got a running Edubuntu 6.06 server with ~500 active users and I'd like to have the transition to 6.10 as smooth as possible (understandingly:)
[03:20] <ogra> well, i'd suggest to wipe the ltsp chroot then and rebuild it ... its only three commands
[03:21] <ogra> actually you could even try it with the ltsp-server/-standalone packages and build it manually
[03:21] <ogra> afterwards run: sudo dpkg-reconfigure -pcritical edubuntu-artwork
[03:22] <ogra> https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall (afterwards == after you follwed that wikipage to get the initial setup)
[03:22] <luckyed> but then again, aren't a lot of packages still left from the old version that wouldn't be needed by 6.10? In this case I'd prefer a clean install
[03:22] <ogra> well, update-manager should care
[03:23] <ogra> and edgy has a 2remove old cruft" feature in apt now
[03:24] <luckyed> I already tried to install the ltsp-server-standalone package and run ltsp-manager afterwards, but it gives me: (ltsp-manager:7072): libglade-WARNING **: could not find glade file './ltsp-manager.glade'
[03:24] <luckyed> Traceback (most recent call last):
[03:24] <luckyed>   File "/usr/bin/ltsp-manager", line 409, in ?
[03:24] <luckyed>     base = LTSPManager()
[03:24] <luckyed>   File "/usr/bin/ltsp-manager", line 18, in __init__
[03:24] <luckyed>     self.wTree=gtk.glade.XML ("./ltsp-manager.glade")
[03:24] <luckyed> RuntimeError: could not create GladeXML object
[03:25] <cbx33> ogra: is there a package for ltsp-manager?
[03:25] <luckyed> yes
[03:26] <ogra> cbx33, yes, but it still has no backend
[03:26] <cbx33> hmm....ahhh
[03:26] <ogra> so it wont do anything ... its only a gui
[03:26] <cbx33> that's what I thought...
[03:26] <cbx33> sorry coming in on the tail end of this conversation
[03:26] <ogra> and i'm still working on gui parts here
[03:26] <cbx33> right
[03:26] <ogra> (havent pushed the changes for quite somne time)
[03:27] <cbx33> ogra: did you want a hand on it?
[03:27] <ogra> sure, but lets have a spec first
[03:27] <cbx33> well, the only reason I said it was....I have a week off next week, because it's half term I am allowed to take holiday, so I may have some spare time to work on things
[03:28] <cbx33> pessulus/SCP seems fixed now
[03:29] <ogra> i'll be busy as hello next week ... including no sleep for some days to test the final iso etc
[03:29] <cbx33> ok
[03:29] <cbx33> did you want a hand with any of that
[03:29] <ogra> sure
[03:29] <cbx33> I can only test in vm's as I'll be without the hardware I have at work
[03:29] <ogra> help testing :)
[03:30] <ogra> thats why we have the qemu support built in, even vm's will be fine for install tests
[03:31] <cbx33> ok sure
[03:51] <bddebian> Heya
[05:05] <sbalneav> Morning all!
[05:05] <RichEd> hi sbalneav :)
[05:05] <sbalneav> Hello RichEd
[05:24] <highvoltage> RichEd: here now
[05:27] <RichEd> highvoltage: thanks -> msg window
[06:01] <Dheeraj> hi wat package is available on edubuntu?
[06:02] <Dheeraj> does it has all dev package?
[06:02] <Dheeraj> eg c++ ide, eclipse etc?
[06:02] <ogra> it has *all* packages ubuntu has
[06:03] <ogra> (available that is ... there is no compiler installed by default)
[06:03] <Dheeraj> is it same as ubuntu?
[06:04] <stgraber> all the ubuntu (ubuntu/kubuntu/edubuntu ...) use the same packages and the same repositories
[06:04] <ogra> yes, but with a different set of default packages, different artwork and a ltsp setup out of the box for classrooms
[06:04] <stgraber> that's just the package installed by default that are differents
[06:04] <ogra> well and the installer
[06:04] <Dheeraj> i thought i'll get all dev tool with that
[06:05] <ogra> sure you can ... but they wont be there directly after install ...
[06:05] <Dheeraj> that means i'll have to download those packages?
[06:05] <ogra> but there are more than 17000 packages ... including all the dev tools you can install directly afterwards
[06:06] <ogra> you have to strt up your package manager and select what you want ...
[06:06] <ogra> same as in ubuntu
[06:06] <Dheeraj> but most of the package is going to be downloaded from net right?
[06:07] <ogra> well, the compilert itself is on the CD ...
[06:07] <ogra> *compiler
[06:07] <stgraber> It depends of the one that are on the CD/DVD you use
[06:07] <ogra> but if you want to do development, you surely need libraries etc
[06:07] <ogra> these have to come froim the net
[06:08] <ogra> we'd have to ship on several DVDs if we'd ship all the devel packages
[06:08] <Dheeraj> why they don't ship all the package?
[06:08] <Dheeraj> not every body have high speed net connection
[06:08] <ogra> not everybody has a DVD reader either
[06:09] <ogra> so we cant ship DVDs
[06:09] <ogra> since we send out the CDs fro free, we cant afford to press more than one CD
[06:09] <Dheeraj> than all in 4-5cd ?
[06:09] <ogra> and you only get so much packages into 700MB
[06:10] <Dheeraj> i recently odered 40 cd and distributed it among my friends :)
[06:10] <ogra> we'll discuss having a second CD in mountain view at the conference in november ....
[06:10] <ogra> so probably edgy+1 will be a 2 CD distro (for edubuntu at least)
[06:11] <ogra> but its very unlikely that we'll fill up the space with development packages
[06:11] <Dheeraj> and i know many ppl who use to order 10 cd but they don't even use a single 1
[06:11] <Dheeraj> best idea is allowing user whether they want all package or limited 1
[06:12] <stgraber> ogra: Is the possiblity to have the normal installer (not the graphical one) included on the CD also in the things you have to discuss ? (I had 10-15 people that had some problem to install with the Install/Live CD and only 128MB of ram)
[06:12] <ogra> well, not if you have technical limitations
[06:12] <ogra> i.e. 1.4Gb of space on two CDs isnt much
[06:13] <Dheeraj> yeah thats a majour problem
[06:13] <ogra> stgraber, the LiveCD pretty clear states that it needs *at least* 256M
[06:13] <ogra> thats one reason why we still use the non live CD for our default install in edubuntu
[06:14] <Dheeraj> even i faced the problem while installing it on my pc
[06:14] <Dheeraj> p4 with 256mb ram
[06:14] <ogra> so we can support smaller footprints
[06:14] <Dheeraj> than i installed it on safe graphic mode
[06:15] <Dheeraj> there should be option whether user want to run live cd or dorect installation
[06:15] <Dheeraj> without running live cd
[06:15] <Dheeraj> another problem is with connecting gprs on it
[06:15] <Jsgmob> We dont have enough space on cd
[06:16] <Dheeraj> i tried almost all the dialer including wvdial and kpppd
[06:16] <ogra> you cant have a live session and all the install packages on one CD
[06:16] <ogra> the DVD has this option btw
[06:16] <Dheeraj> but both disconnect net with in 2-3minute
[06:16] <Dheeraj> than pls think about shipping dvd
[06:17] <Jsgmob> Eekkkk
[06:17] <Dheeraj> dvd writer and dvd rom price is now very cheap
[06:17] <ogra> Dheeraj, as i said, *most* edubuntu users dont have a DVD reader
[06:17] <Jsgmob> Not in mass production though
[06:17] <ogra> most of our users are happy to have power
[06:18] <ogra> or a single phone line
[06:18] <Dheeraj> there should be some sollution
[06:18] <Jsgmob> Grab the dvd and distribute it ;)
[06:19] <ogra> yes, the next solution down the road is to ship on two CDs
[06:19] <ogra> which puts the double amopunt of costs on us
[06:19] <^Ghost2U> anyone had probls with ltsp chroot build? (I have)
[06:20] <ogra> ^Ghost2U, can you switch to console 4 (alt-F4) and have a look what exactly failed  ?
[06:21] <ogra> or file a biug with /var/log/installer/syslog installed
[06:21] <ogra> *bug
[06:22] <^Ghost2U> ogra, I'm reinstalling from scratch right now... lets see what happens
[06:22] <ogra> which iso did you use ?
[06:23] <Dheeraj> i am currently using fedora 4 only coz i am not able to connect gprs on ubuntu :(
[06:23] <^Ghost2U> ogra: 6.06 edubuntu
[06:24] <^Ghost2U> ogra: install version
[06:24] <^Ghost2U> ogra: i386
[06:24] <Dheeraj> is it a bug in wvdial or ubuntu?
[06:24] <ogra> hmm, thats used b ymany many people
[06:25] <ogra> so the install should just work
[06:25] <Dheeraj> as wvdial is working fine on fedora
[06:25] <ogra> at which speed did you write the CD ?
[06:25] <^Ghost2U> ogra: i think it may be my cdrw might be flaky, i burned at 8x
[06:25] <jsgotangco> Dheeraj: file a bug in the appropriate package unfortunately we dont have  a lot of testers on such methods
[06:25] <ogra> 8x *should* be fine ...
[06:26] <Dheeraj> power failure i'll b back later.
[06:26] <^Ghost2U> ogra: i read something in the older vers about burning at slower speeds, so i started there
[06:26] <ogra> yeah
[06:27] <ogra> that didnt change, the data on the iso is still compressed ... but 8x should really be ok
[06:27] <jsgotangco> Jeez typing with thumbs will most likely accelerate carpal tunnel
[06:34] <^Ghost2U> ogra: i had a similar problem installing under vmware 5.51 a few days ago.. got it to work, but shelved it, and using real h/w this time
[07:12] <Dheeraj_k> here is the detail http://www.desi-tek.com/forum/index.php?showtopic=398
[07:13] <Dheeraj_k> wvdial error on ubuntu
[07:15] <ogra> right, but this is surely the wrong channel to discuss it :)
[07:15] <Dheeraj_k> it is ocurring only on ubuntu and other distro of ubuntu
[07:16] <Dheeraj_k> eg edubuntu, kubuntu
[07:16] <ogra> right
[07:17] <ogra> for support go to #ubuntu for this issue ... if you want it fixed, make sure to file a bug about it (unless there isnt one already)
[07:18] <Dheeraj_k> ubuntu channel is full
[07:19] <ogra> that doesnt make this channel valid for general ubuntu support :)
[07:20] <Dheeraj_k> p81 member there and every 1 is just typing and typing no response
[07:22] <Dheeraj_k> p81 = 981 :)
[08:19] <cbx33> i didn't know there was a limit on #ubuntu
[08:20] <cbx33> ogra, once the installer is confirmed ok...this is just a general question.....why do we need to test all variations of installing ubuntu?