[00:22] <jelmer> lifeless: hi
[00:55] <poolie> hi igc, spiv, https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=udd
[00:55] <poolie> hi all
[00:59] <igc> hi
[01:01] <jml> poolie, hi
[01:01] <poolie> hi there jml!
[01:01] <jml> poolie, you should unify some accounts: https://www.ohloh.net/search?q=martin+pool
[01:02] <poolie> oh ok
[01:02] <poolie> i did a bunch of them the other week
[01:02] <poolie> jml, when was that stakeholder meeting going to be?
[01:03] <jml> poolie, 21 June, 1800UTC
[01:03] <poolie> ok
[01:37] <poolie> igc, spiv, https://edge.launchpad.net/bzr/+milestone/2.2.0
[01:51] <poolie> https://bugs.edge.launchpad.net/bzr/+bugs?field.searchtext=&orderby=-number_of_duplicates&search=Search&field.status:list=NEW&field.status:list=INCOMPLETE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&field.importance:list=HIGH&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
[01:51] <poolie> blah
[01:52] <poolie> which is high priority bugs by number of dupes
[01:53] <spm> new bug. LP needs shortly (cryptic) get request fields for sharing searches. Won't Somebody Think Of The IRC Channels!!!!
[01:53] <spm> shorter. even.
[01:58] <AfC1> Why does the Ubuntu package "bzr" depend on "bzrtools". Shouldn't that be "recommends" or something?
[02:00] <jelmer> AfC: it doesn't depend on bzrtools
[02:01] <jelmer> AfC: it's in the Recommends in the original debian package and as far as I can tell that hasn't been changed in ubuntu
[02:01] <AfC> Oh. Have I done something wrong, then? I just did "apt-get install bzr" on a (very) fresh system and it dragged in bzrtools. I was a bit surprised by that
[02:02] <poolie> i think apt is configured to install recommends by default
[02:02] <jelmer> AfC: apt-get installs Recommends by default these days
[02:02] <poolie> there's a way to change this-
[02:02] <AfC> ew
[02:02] <poolie> jelmer do you think https://bugs.edge.launchpad.net/bzr/+bug/481748 is now ready to implement based on the list discussion about revision specs in urls?
[02:04] <poolie> hm
[02:04] <jelmer> poolie: yeah, I think so. Though that'll also need some generic work on supporting extra arguments in URLs
[02:04] <poolie> it's a bit hard to find
[02:04] <jelmer> AfC: aptitude -R will ignore recommends
[02:04] <jelmer> I'm not sure if -R will work for apt-get
[02:09] <AfC> jelmer: thanks, will try that
[02:09] <AfC> brb
[02:15] <lifeless> jelmer: hi?
[02:16] <lifeless> jelmer: I'm back off out in a minute, perhaps more content than ping, and I'll reply when I get back :)
[02:17] <poolie> afc, you can set something in /etc if you want this permanently
[02:17] <poolie> cheerio lifeless
[06:00] <lifeless> hi poolie
[06:00] <lifeless> poolie: I think I have the same hardware issue you had
[06:01] <poolie> hi there!
[06:01] <lifeless> loose cpu heatsink
[06:01] <poolie> ah, really?
[06:01] <lifeless> my games machine is powering off frequently
[06:01] <poolie> after yours was posted across the tasman?
[06:01] <lifeless> yes
[06:01] <lifeless> :(
[06:01] <poolie> erk
[06:01] <lifeless> it was -very- occasionally doing it first
[06:01] <lifeless> and I've inspected the CPU heatsink, and one corner screw is loosish
[06:01] <poolie> i'm still waiting for the 2GB DDR3 to come in so i can get it rebuilt
[06:01] <poolie> mm mine were too
[06:01] <lifeless> its a twist-lock thing
[06:02] <poolie> and i just kind of shrugged
[06:02] <poolie> right
[06:02] <lifeless> but that one won't lock firmly
[06:02] <poolie> exactly
[06:02] <lifeless> yeah
[06:02] <lifeless> I'm going to take a little time tomorrow
[06:02] <lifeless> and drop this in to get addressed
[06:02] <lifeless> also
[06:02] <poolie> heh i just found in my office the other day one of the special torx keys to tighten an ia64 heat sink
[06:02] <lifeless> we've put an offer in on a house
[06:02] <poolie> _that_ won't come loose :)
[06:02] <poolie> congrats
[06:03] <spiv> Ooh :)
[06:03] <lifeless> so I need to do a little run around dance for that with lawyers, inspectors etc
[06:03] <StevenK> lifeless: Nice!
[06:03] <poolie> mm
[06:03] <poolie> so we had a look here into https://bugs.edge.launchpad.net/bzr/+bug/582157
[06:03] <poolie> without really reproducing it
[06:03] <lifeless> poolie: long story short - I'll be around on basically .au hours tomorow
[06:03] <poolie> istm there are two classes of problems here
[06:04] <poolie> ah you're not working so i won't bother you with it
[06:04] <lifeless> poolie: cool, thank you for pulling on the string
[06:04] <poolie> ok, np
[06:04] <lifeless> no, no bother
[06:04] <lifeless> its not like Canonical has traditional boundaries
[06:04] <poolie> ok so the two classes are: things where we know we're going slower than we should; and secondly things where we are unexpectedly slow
[06:04] <poolie> this bug would be in the second class
[06:05] <poolie> we have some ideas for shots in the dark that are probably useful anyhow, and for improving debuggability/supportability
[06:05] <lifeless> I can't wait for steams Linux port.
[06:05] <lifeless> one thing I thought of doing
[06:05] <lifeless> as a fairly immediately useful thing
[06:05] <poolie> after that, i'm going to put this back to incomplete
[06:05] <lifeless> was to make a per-invocation server side log
[06:06] <poolie> mm
[06:06] <poolie> so the ideas were
[06:06] <poolie> 1- use a socketpair to the ssh client, not a pipe
[06:06] <lifeless> that is, $ISO16whatever-$PID.log in ~/.local/bzr/ or some such
[06:06] <poolie> - not proven to fix this but a generally good idea; may alleviate poor blocking behaviour
[06:06] <poolie> ok
[06:06] <poolie> that's good too
[06:07] <lifeless> and then get that cherrypicked into LP production, add -Dhpss on the server side and get the logs synced every 5 minutes or so
[06:07] <poolie> 2- when TERM=spiv, server sends its hpss log over stderr so you can see on the client where it thinks it's spending time
[06:07] <lifeless> so we could see chunking, groupcompress stats etc
[06:07] <poolie> 3- log into that how much cpu time we spend per request
[06:07] <poolie> right
[06:07] <poolie> this would be quicker than getting it off lp via losas etc
[06:07] <lifeless> I like the idea of getting more data
[06:07] <lifeless> I think we should aim for getting more data all the time
[06:08] <poolie> 4- print a few more stats at the end: number of rpcs, number of ~mtu and <<mtu read() responses
[06:08] <lifeless> so that when someone says 'man it was slow this morning', we can see why
[06:08] <lifeless> that doesn't conflict with getting more in an immediate mode like you are describing
[06:08] <poolie> right
[06:10] <poolie> and i think that's it
[06:10] <lifeless> I agree that that bug should be used for 'lp is slower than bzr+ssh in general'
[06:11] <lifeless> I'm not sure where 'bzr+ssh around the world is slower than bzr+ssh locally' should go, if anywhere.
[06:11] <lifeless> [one theory about bzr+ssh performance is window choking on the tcp links - I was doing tcptrace analysis with spm a couple weeks back on this]
[06:11] <poolie> ah
[06:11] <poolie> that's possible
[06:12] <lifeless> on spm's recommendation I filed an RT ticket to increase the buffer limits on chokecherry or whatever the server is
[06:12] <poolie> crowberry?
[06:12] <lifeless> its in the lp queue if you want to dig it up
[06:12] <poolie> i wish the machine list page was up to date
[06:12] <lifeless> $suitablemachinename
[06:12] <poolie> and did you actually find anything from tcptrace?
[06:12] <poolie> i was just wondering if there was a machine like that
[06:12] <lifeless> was something a little suspicious, then PPing
[06:12] <lifeless> then looming
[06:13] <lifeless> that said, changing on crowberry live isn't the best place to test theories
[06:13] <poolie> using a socketpair may help there
[06:13] <poolie> right
[06:13] <lifeless> so we'll want to repurpose tungsten probably
[06:13] <lifeless> to be a testbed
[06:13] <poolie> something tcp related would be compatible with different people observing very different results
[06:13] <lifeless> I'm not sure why a socketpair would help
[06:14] <poolie> i think that they allow partial reads while a pipe does not
[06:14] <lifeless> interesting
[06:14] <poolie> imbw
[06:15] <poolie> oh the other possibility is that it's load-related on the server
[06:15] <lifeless> holy cow steam installs fast on SSD
[06:15] <lifeless> yes, load is a big concern
[06:15] <poolie> under windows?
[06:15] <lifeless> cedega
[06:16] <lifeless> more detailed logs would let us ascertain the concurrent bzr processes, and their activity, after the fact
[06:33] <StevenK> lifeless: What were your thoughts as bzr's TestCase as a fixture?
[06:33] <lifeless> *blink*
[06:36] <lifeless> StevenK: what do you mean
[06:38] <StevenK> lifeless: Context is your comment on this MP: https://code.edge.launchpad.net/~stevenk/launchpad/poppy-sftp-test-isolation/+merge/26717
[07:58] <vila> hi all
[08:03] <spm> hey vila!
[08:04] <vila> spm: _o/
[08:42] <thumper> what is the simplest way to get a time zone aware datetime object for the revision time?
[08:42] <thumper> a revision has a timestamp and timezone
[08:42] <thumper> is there a simple way?
[08:45] <vila> thumper: My memory may be a bit dusty, but I think I recall that the timezone and datetime should be supplied both or none of them
[08:45] <vila> thumper: so, short answer: no
[08:47] <thumper> is the timestamp of the revision in UTC or local time?
[08:49] <vila> gee, let me check, I'd say UTC, but I'm sure there are tests for that
[08:58] <vila> thumper: I was wrong, it's in local time (AFAICS)
[08:58] <thumper> vila: I think I'm going to agree with your first answer
[08:58] <thumper> vila: it is UTC
[08:59] <thumper> if I go: datetime.utcfromtimestamp(r.timestamp) it is right
[08:59] <thumper> where r is a revision object
[08:59] <vila> thumper: you checked that with a timezone != 0 ?
[08:59] <thumper> I'm not sure why a timezone is also recorded
[08:59] <thumper> r.timezone is 43200
[09:00] <thumper> hang on
[09:01] <vila> it's a shame it's not better documented anyway :-/
[09:02]  * thumper is a little frustrated
[09:02] <thumper> it seems to be UTC
[09:02] <thumper> even though a timezone is recorded
[09:06] <vila> hmm, so I looked at the wrong place and we may have bugs there..
[09:07] <vila> but looking at how log process that, yes, it seems to be UTC
[09:56] <sivang> hi
[09:56] <sivang> so, I have 2 branches who have diverged for some unclear reason.
[09:56] <sivang> nor merge or dif --old shows anythinig useful,
[09:57] <sivang> besides that my current branch is all extra to the push location - which was not like this before my laptop commit.
[09:57] <sivang> How to solve this?
[10:03] <jelmer> sivang: have you tried "bzr missing" ?
[10:03] <jelmer> that should tell you the revisions that are present in one branch but missing in the other
[10:07] <mwhudson> vila: when are you arriving in cambridge?
[10:08] <vila> mwhudson: tomorrow, around ~14h30 if all goes well
[10:08] <mwhudson> vila: ok
[10:28] <sivang> jelmer: I have, it suddenly shows me that all of the commits on the local branch I am working on are extras
[10:30] <parthm> mgz: thanks for the bzr-grep patches. i am going through no-match-fast path right now.
[10:41] <jelmer> sivang: that certainly explains why it's giving you that error
[10:49] <sivang> jelmer: right, but how is that that suddenly all those revision are extra?
[10:50] <sivang> jelmer: this wasn't so a day before.
[10:55] <sivang> jelmer: so it seems the only way to solve this is to rebranch
[10:57] <jelmer> sivang: Have you perhaps rebase your branch or something like that?
[11:01] <sivang> jelmer: not that I know of.
[11:01] <sivang> jelmer: This should be explicit enough for me to remember, from a bzr user POV
[11:01] <sivang> :)
[11:04] <sivang> jelmer: I'm rebranching, this takes too long to resolve with no apparent stuff to merg
[11:04] <sivang> jelmer: e.g. merge says there's nothing to do
[12:55] <C-S> ls
[13:15] <C-S> parthm: are you there?
[13:28] <parthm> C-S: hi
[14:16] <feckser> in .bzr/repository/indices I have many duplicate files.  Can I unlink or hard link them all?
[14:16] <feckser> and not break anything?
[15:16] <maxb> feckser: This should not be the case
[15:17] <maxb> feckser: I suggest pastebinning the output of 'ls -lR .bzr/repository/' so people here can understand the situation better
[15:21] <feckser> maxb: what should not be the case?  There should not be binary duplicate indices?
[15:21] <maxb> It's pretty unexpected, yes
[15:31] <feckser> http://www.pastey.net/137418-3kta
[15:54] <maxb> feckser: What? All your concern is about 4 60-byte files?
[15:54] <maxb> stop worrying
[15:54] <feckser> maxb: they obscure the duplicate list.
[15:55] <feckser> They make it harder to process removal of duplicates.
[15:55] <maxb> huh?!
[15:55] <feckser> When I perform a search for duplicates they are always returned.
[15:55] <maxb> So? Why does this bother you?
[15:56] <feckser> It makes the process of finding and removing unwanted duplicates harder
[15:57] <feckser> and that was only an example.  There are more in other bzr repositories.
[16:01] <maxb> Unless you can find duplicates of substantial size, I feel this is a non-issue
[16:23] <feckser> maxb: it is not just about finding duplicates in bzr repositories, it is about finding them all my files.
[16:24] <feckser> some of the directories under ~ are bzr repositories.
[16:24] <maxb> Make your dupefinder ignore .bzr then
[16:24] <feckser> inore list
[16:24] <feckser> it has no ignore list
[16:26] <maxb> Personally, I see no problem with Bazaar happening to produce identical byte content in a few small files as an implementation detail
[16:26] <feckser> I did not say it was a Bazaar problem.  I asked whether I can delete them without harm.
[16:26] <maxb> Answer: no
[16:27] <feckser> Can I hard link them without harm?
[16:28] <feckser> The duplicate finder (fdupes) smartly considers multiple links to same file as not duplicates.
[18:01] <vila> feckser: don't ever hardlink these files, they contain the signatures (and appear to be empty in your case). If you start signing your commits... they won't be empty anymore
[18:02] <feckser> vila: so as long as I don't sign, they can be hard linked or removed?
[18:03] <vila> feckser: no, their presence is mandatory
[18:03] <feckser> vila: hard linked?
[18:03] <vila> feckser: if you hardlink them, you will be doomed the day someone in the project sign a commit
[18:03] <exarkun> it really sounds like you want fdupes to have an exclusions list :)
[18:04] <vila> feckser: besides, new ones will be created when the repo is repacked
[18:55] <meoblast001> hi
[18:55] <meoblast001> i'm having more issues with obtaining the directory of a branch
[18:56] <meoblast001> this result.branch.base isn't cutting it anymore
[18:56] <meoblast001> because "filtered-154314860:///bzr/~mysticgalaxies/citrine-blender/" is not a file path
[18:56] <meoblast001> at least not to me it isn't
[18:57] <meoblast001> hm, a lot of stuff is undocumented
[18:57] <meoblast001> i can't even find Branch.base in the docs
[21:09] <lifeless> meoblast001: branch.base is in the api docs
[21:09] <lifeless> pydoc bzrlib.branch
[21:09] <lifeless> ...
[21:09] <lifeless> :ivar base: ...
[21:09] <lifeless> meoblast001: that filtered: prefix is the soft chroot I was telling you about
[21:10] <lifeless> meoblast001: and why taking a suffix is needed, or unwrapping the filtering
[21:10] <lifeless> meoblast001: or, taking a config option from the branch (which I think is preferrable anyway)
[21:10] <lifeless> meoblast001: but you'll know what works best for your needs
[21:17] <meoblast001> lifeless: oh, why wasn't it in these docs http://people.canonical.com/~mwh/bzrlibapi/bzrlib.branch.BzrBranch7.html
[21:17] <meoblast001> hm, those seem to be personal docs
[21:17] <meoblast001> nvm
[21:18] <lifeless> http://people.canonical.com/~mwh/bzrlibapi/bzrlib.branch.Branch.html
[21:18] <meoblast001> ah
[21:19] <lifeless> looks like a bug in pydoctor
[21:19] <meoblast001> config option?
[21:19] <lifeless> its showing inherited methods
[21:19] <lifeless> but not inherited variables
[21:19] <lifeless> attributes I mean
[21:19] <lifeless> meoblast001: config option - setting a key in branch.conf that you can look for
[21:21] <meoblast001> lifeless: does Bazaar call plugins with .bzr as the working directory or is there something i need to use to set and get keys in branch.conf?
[21:21] <lifeless> branch.get_config()
[21:21] <meoblast001> hm, undocumented
[21:21] <lifeless> its a decorator
[21:22] <meoblast001> decorator?
[21:22] <lifeless> I think
[21:22] <lifeless> ah no, it is genuinely undoced, I'll fix
[21:23] <meoblast001> lifeless: does that return a bzrlbi.config.Config?
[21:23] <meoblast001> bzrlib*
[21:25] <lifeless> bzrlib.config.BranchConfig
[21:25] <lifeless> which has get_config, set_config etc apis
[21:27] <meoblast001> lifeless: i seem to have a limited array of options
[21:27] <meoblast001> i see no get_config or set_config
[21:27] <meoblast001> i see get_user_option
[21:27] <meoblast001> but not even a set_user_option
[21:28] <lifeless> http://people.canonical.com/~mwh/bzrlibapi/bzrlib.config.BranchConfig.html
[21:28] <lifeless> there is a set_user_option
[21:28] <lifeless> and get_user_option
[21:29] <meoblast001> ah, at top
[21:29] <lifeless> as well as typed methods for email, signature checking, aliases and so on
[21:29] <meoblast001> lifeless: so i want to use those, correct?
[21:29] <lifeless> in your plugin you want to use get_user_option
[21:29] <lifeless> you can just set the value in branch.conf with a text editor
[21:29] <meoblast001> result.branch.get_config().get_user_option ('blahblahblah')
[21:30] <lifeless> yep
[21:30] <meoblast001> since the return value of that get_config() is still sort of ambiguous
[21:30] <meoblast001> ok, thanks
[21:31] <lifeless> generally speaking that will return None if the option isn't set
[21:41] <mgz> ah, a lifeless.
[21:41] <mgz> did you suggest I look at testrepository for my traceback matcher thing?
[21:42] <lifeless> yes
[21:42] <lifeless> testrepository.tests.matchers.MatchesException
[21:42] <lifeless> needs a little more suger
[21:42] <lifeless> sugar
[21:43] <mgz> will grab and look at.
[21:44] <mgz> hm, yeah, that's looking at exc_info
[21:44] <lifeless> possibly it should be built via composed subclass/equality style matches for each element of the tuple
[21:44] <mgz> which isn't a bad thing in general, but in this case we care about how the strings actually get passed through to the final stream
[21:46] <mgz> having something that takes an input of extract_tb style tuples might be okay though
[21:48] <meoblast001> lifeless: ok, thanks... and i should have the config option set manually?
[21:48] <lifeless> yes
[21:50] <TresEquis> lifeless: how goes the househunt?
[21:50] <lifeless> great
[21:51] <TresEquis> cool
[22:57] <maxb> So, if you have a branch, stacked on another branch, and the base branch has been upgraded to 2a but the stacked one is still 1.x .... can you recover?
[22:58] <lifeless> yes
[22:58] <lifeless> upgrade the stacked one
[23:10] <james_w> lifeless: testr is pretty cool, thanks
[23:10] <lifeless> james_w: thanks!
[23:10] <lifeless> I'm glad you like it
[23:11] <james_w> lifeless: I'd prefer different output, like a big green light when all the tests pass
[23:12] <lifeless> james_w: I'd be delighted to incorporate patches
[23:12] <lifeless> if you wanted to include an arduino control module to drive a traffic light, we could even include that
[23:12] <james_w> heh
[23:12] <lifeless> did you see that?
[23:13] <james_w> I saw one that did lava lamps
[23:13] <james_w> I ported soupmatchers to use the discovery stuff today, makes for a pretty nice setup.
[23:13] <lifeless> awesome
[23:13] <lifeless> could you comment on the testtools bug about how that hangs together ?
[23:14] <james_w> I find the output on failure a little unpleasant, but can live with it
[23:14] <lifeless> or in some fashion write it up? That would be _most_ useful
[23:14] <james_w> sure
[23:15] <james_w> lifeless: if you could review the merge proposal that would be great
[23:17] <lifeless> which one ?
[23:17] <lifeless> bah
[23:17] <lifeless> which one ?
[23:19] <james_w> lifeless: https://code.edge.launchpad.net/~james-w/subunit/discovery/+merge/26893
[23:19] <lifeless> thanks!
[23:19] <lifeless> I shall peruse
[23:20] <lifeless> james_w: ah, I see
[23:21] <james_w> lifeless: feel free to suggest alternative implementation strategies, it was more of an exploratory hack, but it works :-)
[23:21] <lifeless> so TestProgram can take the name of a callable
[23:21] <lifeless> or callables
[23:22] <lifeless> one way to do discover would be:
[23:22] <lifeless> make a series of callables, assign them to global names
[23:23] <lifeless> globals()[thunkN] = lambda:loader.discover(arg, pattern=options.discover_pattern)
[23:23] <lifeless> or something like that
[23:23] <lifeless> I don't think what you've done is all that ugly
[23:23] <lifeless> have a play, see what you think
[23:23] <lifeless> if you decide that the current stuff is better
[23:23] <lifeless> then lets ditch TestProgram entirely
[23:24] <lifeless> so that we don't have two different paths.
[23:24] <lifeless> ideally though, lets get a fixed TestProgram class in that file, which we can use appropriately, and submit a patch to python to make the stdlib one sufficient.
[23:25] <james_w> ah, you're saying that TestProgram should be able to take a list of callables, rather than it being a current feature?
[23:31] <lifeless> no
[23:31] <lifeless> it currently takes a list of names
[23:31] <lifeless> and does introspection
[23:32] <lifeless> see the testr.conf for testrepository, for instance
[23:32] <lifeless> (testrepository.tests.test_suite)
[23:32] <lifeless> oh bleh
[23:32] <lifeless> yes
[23:32] <lifeless> I'm saying that if we need to change TestProgram to accept callables as well as names
[23:32] <lifeless> or some such
[23:32] <lifeless> then we should
[23:32] <lifeless> or if we need to separate the concerns more
[23:32] <lifeless> then we should do that
[23:34] <lifeless> james_w: to put it most broadly:
[23:34] <lifeless>  - subunit.run should be a trivial change to testtools.run
[23:35] <lifeless>  - testtools.run should be a trivial wrapper for python's TestProgram
[23:35] <lifeless> so lets make things better up the stack, and where we have to wait for patches to be accepted / propogate to old versions etc, we should have a subclass that implements what our patch does, with a 'XXX: delete when python2.7 is the oldest version we support', or similar.
[23:37] <james_w> right
[23:37] <james_w> I don't see TestProgram taking a list of callables right now
[23:37] <lifeless> agreed
[23:37] <lifeless> it does take a list *of the names of callables*
[23:37] <james_w> right
[23:38] <james_w> but serialising the discovered tests back to that seems wrong
[23:38] <lifeless> so here's the review - please change subunit to use testtools more, it hasn't needed to for run as it was sufficient in the stdlib
[23:38] <lifeless> and do the discovery work in testtools
[23:38] <lifeless> and in testtools; either:
[23:38] <lifeless>  - subclass TestProgram and make it more suitable
[23:39] <lifeless>  - use a thunk to pass to TestProgram
[23:39] <lifeless> james_w: it wouldn't be serialising
[23:39] <lifeless> james_w: it would just call indirect the call to discover; I don't have a preference though
[23:39] <james_w> should we push --discover in to TestProgram?
[23:40] <lifeless> ultimately, yes. In fact 2.7 may do that already
[23:40] <lifeless> so it may be a 'copy from python' case
[23:40] <lifeless> as far as licencing goes
[23:40] <lifeless> testtools is license compatible with python, deliberately.
[23:40] <lifeless> so is subunit.
[23:40] <lifeless> just need to update the list of external copyright holders in the docs.
[23:40] <james_w> it doesn't yet, I was just checking that
[23:41] <james_w> oh, hang on
[23:41] <lifeless> I'm sure 2.7 supports discovery in some fashion
[23:41] <james_w> it does
[23:41] <lifeless> COPYING has the external copyright refs
[23:41] <james_w> but not --discover
[23:41] <james_w> it would be "python -m testtools.run discover"
[23:45] <lifeless> thats ... interesting
[23:50] <lifeless> uhm
[23:51] <lifeless> I don't have a strong opinion here, if it works +1. If its maintainable +1. If its the same as python has ended up upstream thats nice; if you think its nicer to be different, thats ok too.
[23:51] <lifeless> Just, where we are different, put patches forwardds.
[23:51] <lifeless> if you think we should try it differently, and decide later what is nicest, thats fine too - we can put a patch in once we are convinced one way or the other.
[23:52] <lifeless> back shortly, popping down to the bank.


[00:02] <stgraber> cjwatson: diagnostic so far is that the .md5sum file isn't even read by ucf, not sure why yet
[00:03]  * SpamapS wipes the sweat off his brow, checks for any bleeding wounds, then returns to hacking
[00:12] <micahg> stgraber: FYI, cjwatson said he was gone a few hours ago in case you're waiting for a quick answer
[00:12] <stgraber> cjwatson: ok, found the issue, it's caused by the fact that we have a lastsum on the system, so the whole .md5sum file is ignored
[00:12] <stgraber> micahg: nope, not really hoping for a quick answer :) I'll likely post that in the bug report anyway
[00:13] <micahg> stgraber: k :)
[00:41] <ohsix> am i seeing things or is python-ubuntuone-client and ubuntuone-client broke right now w/ unsatisfiable deps
[00:43] <ohsix> ahhnm i know what to check, ftb for my arch
[01:42] <kees> skaet: what's the best way to answer the question "is pkg Foo seeded?"
[01:43] <cjwatson> kees: http://people.canonical.com/~ubuntu-archive/germinate-output/
[01:43] <cjwatson> grep through that (perhaps over ssh rather than http)
[01:43] <skaet> kees,  its an area I'm still learning about,  germinate is what folks use.
[01:45] <kees> cjwatson: ah, yes, germinate again. how quickly I forget. :)
[01:46] <cjwatson> (also: make the distinction between "explicitly seeded" and "pulled in by dependency-expansion of seeds")
[01:47] <kees> well, mostly I'm trying to sort out the mess that is cyrus-sasl2-heimdal. we branched from debian at the wrong time...
[01:48] <kees> currently cyrus-sasl2-heimdal is uninstallable and ftbfs. it's in universe, but people do use it.
[01:49] <cjwatson> the rdepends/ directories in germinate-output can tell you why something is wanted in main
[01:49] <kees> nothing seems to seed it, so that's nice. but to fix it, we need debian's -6 of cyrus-sasl2, and that gets seeded by lots. I suspect this'll need a -proposed update after release.
[01:49] <cjwatson> they're the answer to many questions in that area
[01:50] <cjwatson> I'd prefer to keep the term "seeded" for "there's an explicit entry in the seed files kept in bzr for it"
[01:50] <kees> gotcha
[01:51] <cjwatson> since that corresponds to the useful concept of "we explicitly decided we wanted this in main regardless of dependencies" (mostly)
[01:51] <cjwatson> and besides the verb/noun correspondence makes more sense that way :)
[02:25] <cavedon> hi, jcc binary  on natty needs to be rebuilt. what is the procedure for requesting a rebuild at this stage?
[02:26] <cavedon> I guess open a bug and subscribe whom?
[02:42] <sladen> cavedon: open a bug, subscribe ubuntu-release
[02:42] <cavedon> sladen, thanks
[02:46] <sladen> cavedon: got the bug number/package name?
[03:00] <cavedon> sladen, https://bugs.launchpad.net/ubuntu/+source/jcc/+bug/768733
[03:06] <sladen> cavedon: python -m jcc.__main__   "/usr/bin/python: No module named _jcc"   that's a different error to what the bug report suggests?>
[03:07] <sladen> cavedon: how can I test the rebuild fixes it?
[06:08] <happyaron> Is there any plan about Firefox 4 for Lucid?
[06:12] <micahg> happyaron: no, but maybe 5 or 6
[06:12] <micahg> happyaron: you can get it now in the PPA, ppa:mozillateam/firefox-stable
[06:18] <happyaron> micahg: thanks. I'm using Nighly from ftp.mozilla.org now, which get auto-update everyday.
[06:18] <micahg> happyaron: we have nightlies too, ppa:ubuntu-mozilla-daily/ppa, package is firefox-trunk
[06:19] <happyaron> thanks.
[07:56] <didrocks> good morning
[08:04] <smoser> anyone have any ideas? i've got a self signed https server . i have 2 systems running natty, that comlain about it, but will let me get the file.
[08:04] <smoser> i have 2 systems running lucid (headless systems, the other 2 are desktops) that simply refuse
[08:04] <smoser> wget says: Unable to establish SSL connection.
[08:05] <smoser> python urllib2 gives: urllib2.URLError: <urlopen error [Errno 104] Connection reset by peer>
[08:15] <lool> slangasek: apparently the u1 package issue went away by itself
[08:15] <lool> or someone fixed it
[08:15] <slangasek> yeah, there was IS fixing involved :)
[09:12] <tseliot> Riddell: can you approve fglrx in the archive, please? It contains updates to the EULA and to the documentation
[09:12] <tseliot> it won't affect the image build since the driver is not installed by default
[11:29] <Quintasan> good morning
[13:18] <mdeslaur> good morning
[13:18] <mdeslaur> @pilot in
[14:12] <ScottK> sladen: I took care of jcc.
[14:14] <ScottK> tseliot: It's on the Kubuntu DVD so it does affect image building.
[14:14] <tseliot> ScottK: ah, I didn't know that
[14:16] <sladen> ScottK: ta
[14:31] <J_Rey> Anyone know if the system requirements are going to noticably increase if using Unity?
[14:35] <tomreyn> is there a universal command which can be used to check for presence of installed non-free kernel modules?
[14:36] <tomreyn> i think apport and reportbug do this but i'm not sure how
[14:43] <mterry> tomreyn, jockey?
[14:43] <directhex> tomreyn, /proc/sys/kernel/tainted
[14:44] <directhex> tomreyn, 0 means no non-free modules
[14:46] <tomreyn> directhex: that's what i was looking for, thanks. How would I go about identifying which modules are tainting the kernel?
[14:47] <directhex> tomreyn, that's rather more involved ;)
[14:48] <tomreyn> okay, i'll leave it there for now, that's good enough for my needs.
[14:56] <directhex> tomreyn, try something like for i in `lsmod | tail -n +2 | cut -f1 -d' '`; do if [ -n "$(modinfo $i | grep ^license | grep -v GPL)" ]; then echo $i; fi; done
[14:56] <ScottK> i
[14:56] <directhex> tomreyn, this is unsophisticated & will spit out a module which isn't really tainted (e.g. MIT only), and will miss modules which lie to fool the kernel (e.g. "not GPL; Proprietary")
[15:01] <smoser> does anyone have a https server with a self signed cert running on natty ?
[15:02] <smoser> i have a little python based web server, with self signed cert and I can't connect to it from lucid using python or wget (Unable to establish SSL connection.)
[15:02] <smoser> i want to make sure its not a bug in the natty openssl stack
[15:04] <mdeslaur> smoser: what about wget with --no-check-certificate?
[15:04] <smoser> it fails.
[15:04] <smoser> same command succeeds from natty to natty
[15:05] <smoser> both complain about the certificate
[15:05] <smoser> but it gives "Unable to establish ssl connection" when run from lucid -> natty.
[15:06] <mdeslaur> smoser: hmm...interesting
[15:06] <smoser> wait. i might not have been cclear
[15:07] <smoser> server is natty python based self signed cert.
[15:07] <smoser> when client is lucid, wget and python fail
[15:07] <smoser> when client is natty, wget and python both succeed
[15:09] <mdeslaur> smoser: give me a few minutes, I'll set up a natty apache with https and try it
[15:12] <fta> robbiew, hi, do we know how debdelta compares with google's courgette?
[15:12] <fta> robbiew, https://sites.google.com/a/chromium.org/dev/developers/design-documents/software-updates-courgette
[15:12] <RoAkSoAx> mdeslaur: howdy!! Since you are piloting, could you please sponsor bug #768598 please?
[15:13] <robbiew> fta: I don't, and tbh  would prefer to use something shared by debian
[15:14] <fta> robbiew, ok, fair enough. i just has the impression that courgette would be several orders of magnitude smaller
[15:14] <fta> but i didn't test deltadeb
[15:14] <mdeslaur> RoAkSoAx: sure...I'll have to ask the release team for approval first though
[15:16] <mdeslaur> RoAkSoAx: actually...looks like it's too late for release, so it needs to be an SRU once natty is out
[15:17] <RoAkSoAx> mdeslaur: Oh, I didn't know that we were already frozen. Thanks though!
[15:20] <tumbleweed> smoser: works for me (twisted ssl server)
[15:23] <smoser> tumbleweed, you have a self signed https server running on natty? and you can connect to it using wget or python from lucid ?
[15:23] <tumbleweed> smoser: with --no-check-certificate yes
[15:24] <smoser> ok. thank you.
[15:32] <ScottK> RoAkSoAx and mdeslaur: You can upload to natty-proposed now, although (unless I screw up) it won't get accepted until release.
[15:33] <ScottK> No need to wait.
[15:34] <mdeslaur> ScottK: ah! cool, thanks
[15:42] <mdeslaur> RoAkSoAx: I'll upload powernap as a day 0 SRU
[15:42] <kirkland> mdeslaur: RoAkSoAx: thanks
[15:43] <RoAkSoAx> ScottK: cool!! good to know! Thanks
[15:43] <RoAkSoAx> mdeslaur: awesome! Thank you
[15:43] <RoAkSoAx> kirkland: wouldn't have even noticed if you wouldn't have pointed it out :)
[15:43] <kirkland> RoAkSoAx: i was working with negronjl, showing it off, and it broke for both of us
[15:44] <RoAkSoAx> kirkland: yeah I don't really know what happened cause I did patch that. I guess I just forgot to commit those 3 lines when changing laptopsg
[15:44] <RoAkSoAx> kirkland: btw.. how did the tests go? How much energy savings were shown?
[15:46] <RoAkSoAx> kirkland: btw the issue was only seen when executing powernap-now, cause it wouldn't have come back up with activity or powerwake-now. But other than that everything was working as expected
[16:36] <tomreyn> directhex: thanks for the non-free kernel module one-liner :)
[16:59] <mdeslaur> @pilot out
[17:47] <hallyn> Daviey: about bug 769025, what do we do with it, target it at 'natty-updates'?
[17:53] <ohsix> hallyn: do you know offhand if cgroup-bin still makes suspend fail?
[17:56] <hallyn> ohsix: nope
[17:57] <hallyn> thatis, i don't know
[17:57] <ohsix> i had a fun time figuring it out :] installed it to check it out a few times and thought the failures were from thekernel or something related
[17:57] <ohsix> the way it bins threads, kernel and otherwise messes with the ordering of something, at least with the default configuration in cgroup-bin
[17:58] <ohsix> i didn't know enough about it (that's why i wnated to mess with it) to offer a fix, and i still don't; shrug
[18:02] <hallyn> ohsix: there is an open bug about it right?
[18:02] <hallyn> (pretty sure i saw one before)
[18:02] <hallyn> if i get through some other bugs, i may try to reproduce here
[18:02] <ohsix> yea i think i filed one after i found out & closed the bug i reported for the suspend
[18:03] <ohsix> one moment
[18:04] <ohsix> https://bugs.launchpad.net/ubuntu/+source/libcgroup/+bug/713187
[18:18] <hallyn> ohsix: thanks
[18:37] <ScottK> barry: I think Bug #768363 is python2.7 related.  I was wondering if you could have a look.
[19:45] <dobey> can someone approve the lucid/maverick nominations on bug #663001 please?
[20:11] <Cas07> I updated this bug https://bugs.launchpad.net/ubuntu/+source/pygtk/+bug/664920 with ubuntu sponsors so that it can be backported but i am wondering if there is anything else i should do?
[20:38] <hallyn> ohsix: actually, i think libcgroup may no longer stop suspend from working.  It's not placing tasks in any child cgroups for me by default
[20:39] <hallyn> ohsix: that's not to say you can't write a config to make it do so.  (nor that i'm just wrong about my conclusion)
[20:39] <ohsix> did the config remove the default groupings?
[20:39] <ohsix> right, the config it came with in mav was what was moving things
[20:40] <hallyn> ok - we still might want to teach libcgroup explicitly not to move kthreadd, but by default maybe it won't mess people up
[20:40] <Daviey> hallyn, That package is universe, and unseeded by flavours as far as i can see.  Therefore, natty pocket makes sense still.
[20:41] <ohsix> it might be more than kthreadd, at least with respect to suspend, but since it's bad to do it's probably prudent
[20:41] <hallyn> ohsix: right
[20:41] <hallyn> Daviey: are you saying go ahead and dput?
[20:41] <Daviey> hallyn, Final freeze for universe/multiverse is 26th.
[20:42] <Daviey> hallyn, Yes, i would.
[20:42] <hallyn> Daviey: cool, then i just have to find someone who's not on vacation who can sponsor :)
[20:42] <hallyn> SpamapS: around?
[20:42] <Daviey> hallyn, linky, i can
[20:42] <hallyn> finding
[20:42] <Daviey> hallyn, Vacation is for wuffos.
[20:44] <hallyn> Daviey: the source (minus .orig.tar.gz) is at http://people.canonical.com/~serge/libcgroup_0.37.1-1ubuntu2-package.tgz.  bzr tree is linked to the bug which is https://bugs.launchpad.net/ubuntu/+source/libcgroup/+bug/769025
[20:44] <hallyn> Daviey: i could do with a week vacation with no laptop available
[20:44] <Daviey> hallyn, so bzr branch is suitable for review?
[20:44] <hallyn> yup
[20:44] <hallyn> want me to do merge request?
[20:44] <Daviey> hallyn, I get shaky hands if i haen't checked my email for an hour.
[20:44] <Daviey> hallyn, sure, go for it.
[20:45] <hallyn> merge proposal sent
[20:46] <hallyn> yeah i used to be that way.  i might still be.  wouldn't know, bc it hasn't happened :)
[20:46] <Daviey> hallyn, what about https://code.launchpad.net/~serge-hallyn/ubuntu/natty/libcgroup/upstart ?
[20:47] <hallyn> Daviey: that's merged
[20:47] <hallyn> well upstart2 was
[20:48] <hallyn> it was a long road :)
[20:48] <Daviey> hallyn, does that mean bug 681724 is fix released?
[20:49] <hallyn> Daviey: i forgot all about that one!  Yes, it is.  we're now mounting under /sys/fs/cgroup/
[20:50] <hallyn> looks like we licked 5 or 6 bugs with the last-minute release.  and so far only created one new one :)
[20:50]  * hallyn ^5s jbernard
[20:50] <Daviey> hallyn, Okay, looking at the merge proposal now.. Could you copy the debian/changelog entry that fixed that bug into a comment, and change the status to Fix Released please?
[20:51] <hallyn> a comment on that bug you mean, right?
[20:52] <hallyn> done
[20:52] <Daviey> ta
[21:21] <micahg> mdke: ubuntu-docs firefox-index still references Ubuntu 10.10, I filed a bug against ubuntu-docs a couple weeks ago
[21:22] <mdke> micahg: does firefox still use that these days? I thought it was all handled internally by now
[21:23] <micahg> mdke: firefox doesn't, but midori does and I think maybe others
[21:23] <mdke> micahg: I can fix it now but don't know if the upload will be accepted
[21:23] <ScottK> SRU material now unless you can get a fix uploaded in the next 15 minutes.
[21:23] <micahg> mdke: would you rather me fix the midori home page?
[21:24] <ScottK> We have a Ubiquity fix that's about to go in, so I can take a trivial fix if it's quick.
[21:24] <micahg> mdke: ugh, it's seeded, I'll see if I can fix midori and the other browsers instead
[21:25] <mdke> it's fairly easy SRU material though
[21:26] <mdke> ScottK: I will try a gnome-user-docs upload in the next 15, as I have some help for mobile broadband that I'd like to get onto the images if at all possible
[21:26] <ScottK> Hurry.  Just accepted Ubiquity.
[21:26] <micahg> mdke: ok, if you want to SRU the ubuntu-docs change, that'll probably be easier, then we can fix the other browsers for oneiric
[21:28] <mdke> ScottK: will depend how long it takes to build. Testing is straightforward
[21:28] <ScottK> Let's see how he does with my deadline for getting it in -release first ....
[21:28] <ScottK> OK
[21:30] <ScottK> mdke: It looks like you've got a little longer, there's some buildd backlog and I doubt Ubiquity will make the next publisher run.
[21:30] <mdke> ScottK: splendid, my laptop is a bit slow at building :)
[21:30] <ScottK> So don't dawdle, but better to take a little extra time to get it right than to push it by a given moment.
[21:31] <mdke> noted
[21:31] <mdke> how much longer are we talking?
[21:59] <mdke> ScottK: uploaded
[22:06] <ScottK> Looking
[22:07] <ScottK> mdke: Accepted.
[22:08] <mdke> ScottK: a million thanks
[22:08] <mdke> or hugs
[22:08] <ScottK> You're welcome.
[22:08]  * ScottK prefers thanks in whisky.
[22:09] <maco> ScottK: taken Riddell's linguistic preferences to heart?
[22:09] <ScottK> I figure he's in a position to be authoritative on the matter.
[22:11] <mdke> ScottK: noted
[22:11] <ScottK> mdke: You coming to UDS again?
[22:12] <mdke> ScottK: I'm afraid not. In fact, I've never been to one
[22:12] <mdke> :(
[22:12] <ScottK> Ah.  Too bad then.
[22:12] <mdke> difficult to get away from work
[22:35] <lamont> how on earth do I get &*^_&N  to quit thinking that because the window bumps in to the top of the screen when I move it that I for some inexplicable reason want a full screen version of it?
[22:52] <broder> go in ccsm and disable the grid plugin
[22:54] <cjwatson> or Grid -> Edges -> Resize Actions -> Top Edge = None
[22:54] <cjwatson> (also in ccsm)


[00:16] <robru> cyphermox, oh hey. slangasek rebooted autopilot-intel and things are mostly looking like they're working now. just restarted some stacks that had to be cancelled before.
[00:16] <robru> rsalveti, still around? i should be able to publish qtvideo soon
[00:17] <rsalveti> robru: actually, please put that on hold
[00:17] <robru> rsalveti, sure thing
[00:17] <rsalveti> awesome, thanks
[00:17] <rsalveti> we'll resume on monday
[00:20] <cyphermox> ack
[00:20] <cyphermox> robru: you could have pinged me too, you and I have access to mess with autopilot-intel and the like
[00:21] <robru> cyphermox, yeah, somebody mentioned that all it takes is VPN access, but I dunno what to actually *do*.
[00:21] <robru> cyphermox, weren't you CC'd on the email I sent?
[00:21] <cyphermox> I didn't look at email tonight yet :)
[00:21] <cyphermox> but we can discuss that monday perhaps?
[00:21] <robru> cyphermox, discuss what? teaching me to reboot autopilot-intel?
[00:33] <cyphermox> yeah
[00:34] <robru> cyphermox, ok, sure. it seems fine now so we can just leave it. there's an email in your inbox you can reply to at your leisure ;-)
[00:34] <cyphermox> alright
[06:51] <lool> cyphermox: so how does one do that?
[06:51] <lool> I'd like to know too   :-)
[06:52] <lool> AFAICT, the autopilot-intel machine is up right now
[11:04] <cjwatson> robru: for future reference: copying things into the distro only requires somebody with upload permissions for the package in question, not an archive admin
[20:02] <lool> I'd like to push the qtvideo-node out of media stack and ubuntu-download-manager out of click-package, but each time I connect to check, the cu2d jenkins is always busy running tons of stacks including these
[22:31] <lool> hmm someone mistakingly marked the mediaplayer-app change as being in unapproved when it's not merged in trunk
[23:26] <lool> so managed to test ubuntu-download-manager and qtvideo-node and publish just these two
[23:26] <lool> I'll try to roll an image later
[23:35] <lool> building an image now


[02:39] <charlie-tca> ooops
[02:39] <charlie-tca> blueman bug is duplicate of bug 437883 with 82 dups now
[02:46] <Unit193> If you'll notice the ML, you may see this: http://jaysonrowe.blogspot.com/2011/09/xubuntu-1110-beta-2-review.html
[02:46] <Unit193> jayson_r: Welcome!
[02:47] <charlie-tca> Unit193: ML == Mailing list?
[02:48] <Unit193> charlie-tca: Yes sir!
[02:48] <charlie-tca> Okay. I usually send a thank you type thing to -devel ml when I spot a review, just to let everyone know about it.
[02:49] <charlie-tca> This one I shared on g+
[02:49]  * Unit193 isn't stalking you on G+
[02:49] <charlie-tca> heh
[02:49] <charlie-tca> I just try to push things that are about Xubuntu, generally. I am not very good at "social networking" at all
[02:50] <charlie-tca> got like 52 people in my circle
[02:50] <Unit193> I've got less, and I post less. I'm also not one for social networking
[02:50] <charlie-tca> after a year or so, I got three people on twitter!
[02:51] <Unit193> Anyway, that person posted to the devel list and is here now. I just found that on my quick look over his blog
[02:52] <charlie-tca> Welcome, jayson_r
[02:52] <charlie-tca> Thanks for the review of Xubuntu!
[02:54] <charlie-tca> well, I think I have to get some sleep tonight
[02:54] <charlie-tca> Unit193: Do you have time tomorrow to run tests?
[02:55] <Unit193> charlie-tca: Eh... I'm going to be gone tomorrow, but I could try to make it up in the morning :/
[02:56] <charlie-tca> Most of the changes should have hit today, so if we can test tomorrow, we can give mr_pouit and micahg a chance to see what might be fixable
[02:56] <Unit193> I'll have to do something mostly basic if I can make it
[02:56] <charlie-tca> That works. It just needs to be an image dated 09-30 or later
[02:56] <Unit193> I will try! Have a great night!
[02:57] <charlie-tca> Just to know they still install is good
[02:57] <charlie-tca> Thank you
[02:59] <jayson_r> Unit193: charlie-tca: thanks!
[03:00] <Unit193> Heh, yep. As I thought. You've been here for a little while now :P
[03:00] <madnick> Are all those bugs related to the version that I tested?
[03:01] <charlie-tca> no, madnick
[03:01] <charlie-tca> They were reported two years ago, and don't seem to have been fixed
[03:02] <madnick> Oh okay
[03:02] <charlie-tca> the crash happened on the alternate 64 install, but the desktop cd installs never crashed. It might be something about how it is being installed
[03:04] <charlie-tca> The problem is, it crashes every login when it decides to crash
[03:06] <madnick> charlie-tca: they fixed my bug :)
[03:06] <madnick> do you think we get it in?
[03:06] <charlie-tca> Which one is it?
[03:07] <madnick> bug 862427
[03:07] <charlie-tca> Oh yeah, that is going to make it in, yes
[03:07] <madnick> nice
[03:07] <charlie-tca> apparently wasn't just us, but anyone using gtk-greeter
[03:08] <madnick> yup, i was going to submit a patch, but i dont think they trust me enough, it was litterly about 2 lines of code to change
[03:08] <charlie-tca> I have to keep an eye on it, and make sure it gets fix-released now.
[03:08] <charlie-tca> but you also have the manager in Ubuntu Development watching it
[14:11] <charlie-tca> Good morning
[14:12] <charlie-tca> mr_pouit: anything blocking us now for final release (if there are no changes that screw us)?
[14:13] <madnick> morning
[14:22] <madnick> does anyone have admin rights to gridcubes testing interface?
[14:22] <madnick> and could add todays files
[14:23] <charlie-tca> hit refresh, it should pick them up
[14:23] <madnick> nope :(
[14:23] <madnick> gonna clear my cache and try 1 sec
[14:23] <charlie-tca> did it here
[14:24] <charlie-tca> I just hit F5 in firefox
[14:24] <charlie-tca> oh, but my cache and everything is set for 1 day maximum
[14:24] <madnick> I get:
[14:24] <madnick> Warning: include(./sch/September30.htm)
[14:24] <madnick> even with cleared cache :\
[14:26] <charlie-tca> close it and the open it again?
[14:26] <charlie-tca> http://gridcube.netii.net/test/XTCv2.html
[14:26] <madnick> oh
[14:26] <madnick> i was here:
[14:26] <madnick> http://gridcube.netii.net/test/XubuntuTestingsCenter.html
[14:27] <charlie-tca> ouch, that is full of errors
[14:28] <madnick> The alt images are oversized
[14:28] <madnick> I will see if it works anyways
[14:28] <madnick> err 64bit*
[14:28] <charlie-tca> They fit on a cd for me yesterday, but it grew again today
[14:29] <charlie-tca> probably have to remove one of the language packs again
[14:30] <charlie-tca> mr_pouit: I show the alternate amd64 image at 702.3MB today
[14:32] <madnick> Should I join Xubuntu Testers? So that I can display my testing hardware?
[14:32] <charlie-tca> yes
[14:32] <madnick> okay
[14:33] <charlie-tca> It's for future reference, when someone asks what hardware was used to test Oneric
[14:33] <madnick> Yeah, seems like a good idea
[14:35] <madnick> oh it says i need a wikipage, im not sure how to make those
[14:36] <charlie-tca> Some people use their irc nicks, I used my real name:
[14:36] <charlie-tca> wiki.ubuntu.com/CharlieKravetz
[14:37] <madnick> Oh, on Ubuntu's wiki? Do I just edit "Home"? Or is there a special page for users to add themselves?
[14:37] <charlie-tca> you create a new page, using https://wiki.ubuntu.com/YOURNAME
[14:37] <charlie-tca> You can copy mine and change it to fit if you want
[14:38] <madnick> awesome thanks :)
[14:38] <charlie-tca> It helps if you keep adding what you do to it, too.
[14:39] <charlie-tca> Then when you need all that good information, it is there
[14:39] <madnick> okay :)
[14:40]  * charlie-tca thinks he should have looked to see what is out of date now, too
[14:40] <madnick> I will use the setup of your page, but since i cannot use the wiki source, i wont add the menu, if thats okay
[14:41] <charlie-tca> If you look at "More Actions", raw, you can copy anything off the page
[14:42] <madnick> :D
[14:42] <madnick> Sweet
[14:42] <charlie-tca> The line starting "||<tablestyle="float:right" is the table of contents
[14:59] <madnick> Writing a wikipage is hard :)
[15:01] <charlie-tca> Only the first time. After that it gets easy :)
[15:07] <madnick> If I was 13, is that junior high school?
[15:07] <madnick> :P
[15:07]  * madnick is not familiar with English educational system
[15:08] <charlie-tca> Yes
[15:08] <madnick> thanks :)
[15:08] <charlie-tca> I think so
[18:28] <Unit193> And we have to update BOTH trackers?
[18:31] <charlie-tca> We appreciate having both updated, since we are testing the new one this week. If you only update one, make it google docs
[18:31]  * Unit193 Alt Entire
[18:32] <charlie-tca> Thank you
[19:21] <Unit193> I just love that I'm not stuck with PINK(!) anymore...
[19:31] <Unit193> Installed, updates, jockey, opened a few programs and.... I can see plymouth??
[19:33] <Unit193> Theme changed too... Can a hardware person try a reboot from LightDM? Seemed a litttle weird
[19:33] <charlie-tca> Have already
[19:33] <charlie-tca> It works nice
[19:33] <charlie-tca> Oh, reboot?
[19:33] <charlie-tca> I will try that in a few minutes for you
[19:34] <Unit193> If you aren't going to run another test, don't bother, I'm sure it's just me
[19:35] <Unit193> blueman-applet crashed on second boot
[19:37] <Unit193> And -manager when I tried to open
[19:43] <charlie-tca> No, I have one installed already that I can reboot
[19:43] <charlie-tca> blueman crash is bug 437883
[19:44] <Unit193> Manager didn't already have one with same name
[19:45] <charlie-tca> reboot is weird; but works
[19:46] <charlie-tca> Once the applet starts crashing, it crashes every login
[19:46] <charlie-tca> but, even if reboot is weird, it's *fast*
[19:48] <Unit193> Bug 863599
[19:48] <Unit193> It's a dupe of something, just don't know what
[19:49] <charlie-tca> Hm, I didn't see that crash, but that could be because I have no bluetooth, so once the applet crashes, I don't mess with bluetooth
[19:50] <Unit193> Well, it doesn't have it either
[19:52] <Unit193> Feel free to change my comments, I'm in a rush
[19:52] <Unit193> Only had an option to logout, not reboot or shutdown
[19:55] <charlie-tca> I'll check and see if I can get reproduce the manager crash
[19:59] <Unit193> And it never logged out, had to force
[20:01] <charlie-tca> Yeah, I had that, but I think it is related to the bluetooth crash
[20:02] <charlie-tca> They pushed so many changes yesterday, I was surprised the images even worked
[20:02] <charlie-tca> and Unity plans another change by Tuesday
[20:03] <Unit193> The bug I filed could be a dupe of the one you pointed at. I should be good for thes
[20:03] <Unit193> tues
[20:04] <charlie-tca> Okay, we will try again tues then
[20:04] <charlie-tca> In the meantime, I will run a few installs and see what I can find
[20:05] <Unit193> Heh, wish I could check better :/
[20:05] <charlie-tca> That's okay, I do pretty good when I have something to start with
[20:06] <charlie-tca> I have to try and reproduce bug 849414 too, so I will be doing a few installs this weekend
[21:06] <charlie-tca> GridCube:
[21:07] <GridCube> charlie-tca,
[21:07] <charlie-tca> GridCube: can we have a "enter another test" button instead of having to hit back twice?
[21:07] <charlie-tca> I hit refresh in hopes of getting back to the beginning, but it dups the test
[21:07] <GridCube> yes
[21:09] <GridCube> yes, i've seen that, I was wondering on a way to avoid that, not allowing users to send twice the same exact test, at least one of the field should be different, and the button to go back to the main page :) the last one is very easy, the first one will take some time
[21:12] <GridCube> :) besides that, what do you think so far?
[21:12] <GridCube> should i add a way to delete entries from the admin area?
[21:20] <charlie-tca> oh, and what about displaying comments?
[21:21] <charlie-tca> Also, If I ran the test, entered the data, and then found I forgot something, I have to dup the entry to change it?
[21:21] <charlie-tca> Which is okay, if we add a delete from admin area
[21:21] <charlie-tca> Then the tester can tell us they changed it, and we just delete the first entry made
[21:24] <GridCube> yes i can add the comments to the front page, i didnt because i though it would be too much information
[21:25] <GridCube> and i don't really want to give to anyone the ability to delete entries, any troll would come and delete everything
[21:25] <charlie-tca> I agree with that. We can do deletes through admin only
[21:25] <charlie-tca> limit it to one or two people
[21:26] <GridCube> as you wish i can change the password on the file directly and give it to you if you want and you do what you please whit it :)
[21:26] <charlie-tca> Is the database working?
[21:26] <GridCube> define "working"
[21:26] <charlie-tca> not losing data
[21:27] <GridCube> oh yes :D
[21:27] <GridCube> that is
[21:27] <charlie-tca> We have added quite a bit this week to it
[21:27] <GridCube> yes, i deleted the old tests entries
[21:27] <GridCube> thats why some numbers are wrong, and it starts at 8
[21:27] <GridCube> all the data is from real tests now
[21:28] <charlie-tca> heh
[21:28] <charlie-tca> we have ways of doing strange things sometimes
[21:29] <charlie-tca> We are going to move to this for the next release.
[21:44] <GridCube> :D
[21:44] <GridCube> awesome
[21:45] <GridCube> i'm making it so it can be edited by an admin to fit any cicle :P
[21:45] <GridCube> and i was thinking on packaging it to share it whit other people if they want it
[21:45] <GridCube> :P
[21:46] <charlie-tca> Great! Are we setting it up to use madnick's server or keep it where it is?
[21:47] <charlie-tca> Oh, yeah, you don't those install messages because your computer is too fast.  messages on installations
[21:49] <charlie-tca> Easier to say it here than jump back and forth to talk to the same person
[22:00] <GridCube> charlie-tca, do you want to be able to see the whole database while deleting an entry or you want to have a simple box where to add the ID number while reading the standard "every test" page?
[22:00] <GridCube> i mean, you read the database in one tab and have the delete box on the admin area
[22:04] <GridCube> charlie-tca, check the testings center, i've enabled it to show comments, as you can see, its not very pretty
[22:06] <charlie-tca> I see
[22:06] <charlie-tca> but what good are comments that are invisible?
[22:06] <charlie-tca> Whatever method to delete is easier to create, I guess.
[22:12] <GridCube> they aren invisibles on the "every test" page
[22:12] <GridCube> but ill see what i can do
[22:19] <charlie-tca> Okay
[22:19] <charlie-tca> I kind of like to see if anyone hit the same issues I did, and I think others do also.
[22:34] <GridCube> there, now you can delete entrys from the admin area, do you remember the password?
[22:35] <charlie-tca> yeah, but not the url
[22:36] <charlie-tca> memory like an elephant, just can't remember those details
[22:42] <GridCube> http://gridcube.netii.net/test/sch/AdminArea.html
[22:54] <charlie-tca> Thank you
[22:55] <GridCube> :)
[22:55] <GridCube> I've tried to make it the most comprensible(?) that i could
[22:56] <charlie-tca> It's good. I will just ask questions when I can't do what I need it to.
[22:57] <GridCube> D:
[22:57] <GridCube> :D
[23:31] <charlie-tca> Well, You have a great weekend! I am taking off for tonight now.


[05:54] <wxl> possibly the wrong place to ask this, but the iso testcases in lp:ubuntu-manual-tests is just in a huge lump. would i be breaking things if i moved lubuntu-specific testcases in a separate folder?
[06:58] <flocculant> wxl: possibly is - but why don't you list them in a bug report there to start with, as it is I've no issue with that
[07:09] <wxl> flocculant: i guess the other possibility is coming up with a more reasonable naming scheme like num-flavour-case where flavour can be all
[07:10] <flocculant> I'd argue against that option :p
[07:10] <flocculant> whichever way - bug report for the paper trail ;)
[07:10] <wxl> because it would be a pain to fix the tracker? :)
[07:11] <flocculant> well that and also just a load of work for little gain
[07:11] <wxl> i'll make a bug report about it though and we can discuss it more. thanks for the thoughts :)
[07:11] <flocculant> moving some things about in lp:ubuntu-manual-tests only affects that - doesn't affect the tracker
[07:12] <flocculant> also - not sure there are manu lubuntu only testcases as it stands
[07:12] <flocculant> s/many
[07:14] <flocculant> I'll see the report when you do it - subscribed to testcases
[11:09] -queuebot:#ubuntu-release- New binary: fswatch [s390x] (bionic-proposed/universe) [1.11.2+repack-1] (no packageset)
[11:10] -queuebot:#ubuntu-release- New binary: fswatch [arm64] (bionic-proposed/universe) [1.11.2+repack-1] (no packageset)
[11:11] -queuebot:#ubuntu-release- New binary: fswatch [armhf] (bionic-proposed/universe) [1.11.2+repack-1] (no packageset)
[11:17] -queuebot:#ubuntu-release- New binary: fswatch [amd64] (bionic-proposed/universe) [1.11.2+repack-1] (no packageset)
[11:19] -queuebot:#ubuntu-release- New binary: fswatch [i386] (bionic-proposed/universe) [1.11.2+repack-1] (no packageset)
[20:33] <jbicha> slangasek: could you have https://launchpad.net/ubuntu/bionic derive from Buster instead of Stretch?
[20:38] <tsimonq2> Why doesn't it just derive from Sid?
[20:55] <mwhudson> lts autosync from testing not unstable
[20:55] <mwhudson> i don't know if that's related
[20:57] <tsimonq2> mwhudson: No it doesn't.
[20:57] <tsimonq2> I think it *used* to be that way.
[20:57] <mwhudson> it certainly used to be true
[20:57] <mwhudson> maybe we're not doing that for bionic
[20:58] <tsimonq2> Well iirc, policy changed after good Proposed Migration procedures were implemented.
[20:58] <tsimonq2> Now I think all devel releases pull from Sid.
[20:58] <mwhudson> hmm ok
[22:40] -queuebot:#ubuntu-release- Unapproved: golang-petname (artful-proposed/main) [2.8-0ubuntu1 => 2.9-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
[23:10] -queuebot:#ubuntu-release- New binary: erlang-jose [ppc64el] (bionic-proposed/none) [1.8.4-1] (no packageset)
[23:10] -queuebot:#ubuntu-release- New binary: ffcall [i386] (bionic-proposed/universe) [2.0-2] (no packageset)
[23:10] -queuebot:#ubuntu-release- New binary: ffcall [s390x] (bionic-proposed/universe) [2.0-2] (no packageset)
[23:10] -queuebot:#ubuntu-release- New binary: pg-similarity [ppc64el] (bionic-proposed/none) [1.0~20160916-1] (no packageset)
[23:10] -queuebot:#ubuntu-release- New binary: ffcall [amd64] (bionic-proposed/universe) [2.0-2] (no packageset)
[23:10] -queuebot:#ubuntu-release- New binary: fswatch [amd64] (bionic-proposed/universe) [1.11.2+repack-2] (no packageset)
[23:10] -queuebot:#ubuntu-release- New binary: ffcall [ppc64el] (bionic-proposed/universe) [2.0-2] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: erlang-jose [arm64] (bionic-proposed/none) [1.8.4-1] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: fswatch [i386] (bionic-proposed/universe) [1.11.2+repack-2] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: ffcall [armhf] (bionic-proposed/universe) [2.0-2] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: fswatch [s390x] (bionic-proposed/universe) [1.11.2+repack-2] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: erlang-jose [armhf] (bionic-proposed/none) [1.8.4-1] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: fswatch [armhf] (bionic-proposed/universe) [1.11.2+repack-2] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: pg-similarity [armhf] (bionic-proposed/none) [1.0~20160916-1] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: ffcall [arm64] (bionic-proposed/universe) [2.0-2] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: pg-similarity [arm64] (bionic-proposed/none) [1.0~20160916-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: erlang-jose [amd64] (bionic-proposed/none) [1.8.4-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: erlang-jose [s390x] (bionic-proposed/none) [1.8.4-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: pg-similarity [amd64] (bionic-proposed/none) [1.0~20160916-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: pg-similarity [s390x] (bionic-proposed/none) [1.0~20160916-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: erlang-jose [i386] (bionic-proposed/none) [1.8.4-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: pg-similarity [i386] (bionic-proposed/none) [1.0~20160916-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: fswatch [arm64] (bionic-proposed/universe) [1.11.2+repack-2] (no packageset)
[23:21] <LocutusOfBorg> gooodbye haskell
[23:50] -queuebot:#ubuntu-release- New: accepted fswatch [amd64] (bionic-proposed) [1.10.0+repack-1]
[23:50] -queuebot:#ubuntu-release- New: accepted fswatch [amd64] (bionic-proposed) [1.11.2+repack-1]
[23:50] -queuebot:#ubuntu-release- New: accepted fswatch [armhf] (bionic-proposed) [1.11.2+repack-1]
[23:50] -queuebot:#ubuntu-release- New: accepted fswatch [s390x] (bionic-proposed) [1.11.2+repack-1]
[23:50] -queuebot:#ubuntu-release- New: accepted fswatch [arm64] (bionic-proposed) [1.11.2+repack-2]
[23:50] -queuebot:#ubuntu-release- New: accepted fswatch [s390x] (bionic-proposed) [1.11.2+repack-2]
[23:50] -queuebot:#ubuntu-release- New: accepted fswatch [armhf] (bionic-proposed) [1.10.0+repack-1]
[23:50] -queuebot:#ubuntu-release- New: accepted fswatch [i386] (bionic-proposed) [1.11.2+repack-1]
[23:50] -queuebot:#ubuntu-release- New: accepted fswatch [i386] (bionic-proposed) [1.11.2+repack-2]
[23:50] -queuebot:#ubuntu-release- New: accepted fswatch [arm64] (bionic-proposed) [1.11.2+repack-1]
[23:50] -queuebot:#ubuntu-release- New: accepted fswatch [amd64] (bionic-proposed) [1.11.2+repack-2]
[23:50] -queuebot:#ubuntu-release- New: accepted fswatch [i386] (bionic-proposed) [1.10.0+repack-1]
[23:50] -queuebot:#ubuntu-release- New: accepted fswatch [armhf] (bionic-proposed) [1.11.2+repack-2]
[23:51] -queuebot:#ubuntu-release- New: accepted kirigami2 [amd64] (bionic-proposed) [5.40.0-0ubuntu1]
[23:51] -queuebot:#ubuntu-release- New: accepted kirigami2 [armhf] (bionic-proposed) [5.40.0-0ubuntu1]
[23:51] -queuebot:#ubuntu-release- New: accepted kirigami2 [ppc64el] (bionic-proposed) [5.40.0-0ubuntu1]
[23:51] -queuebot:#ubuntu-release- New: accepted kirigami2 [arm64] (bionic-proposed) [5.40.0-0ubuntu1]
[23:51] -queuebot:#ubuntu-release- New: accepted kirigami2 [s390x] (bionic-proposed) [5.40.0-0ubuntu1]
[23:51] -queuebot:#ubuntu-release- New: accepted kirigami2 [i386] (bionic-proposed) [5.40.0-0ubuntu1]
[23:51] -queuebot:#ubuntu-release- New: accepted ffcall [amd64] (bionic-proposed) [2.0-2]
[23:51] -queuebot:#ubuntu-release- New: accepted ffcall [armhf] (bionic-proposed) [2.0-2]
[23:51] -queuebot:#ubuntu-release- New: accepted ffcall [ppc64el] (bionic-proposed) [2.0-2]
[23:51] -queuebot:#ubuntu-release- New: accepted ffcall [arm64] (bionic-proposed) [2.0-2]
[23:51] -queuebot:#ubuntu-release- New: accepted ffcall [s390x] (bionic-proposed) [2.0-2]
[23:51] -queuebot:#ubuntu-release- New: accepted ffcall [i386] (bionic-proposed) [2.0-2]
[23:52] -queuebot:#ubuntu-release- New: accepted haskell-bitarray [sync] (bionic-proposed) [<IP_ADDRESS>-3]
[23:52] -queuebot:#ubuntu-release- New: accepted pytrainer [sync] (bionic-proposed) [1.11.0-1]
[23:52] -queuebot:#ubuntu-release- New: accepted erlang-jose [amd64] (bionic-proposed) [1.8.4-1]
[23:52] -queuebot:#ubuntu-release- New: accepted erlang-jose [armhf] (bionic-proposed) [1.8.4-1]
[23:52] -queuebot:#ubuntu-release- New: accepted erlang-jose [ppc64el] (bionic-proposed) [1.8.4-1]
[23:52] -queuebot:#ubuntu-release- New: accepted erlang-jose [arm64] (bionic-proposed) [1.8.4-1]
[23:52] -queuebot:#ubuntu-release- New: accepted erlang-jose [s390x] (bionic-proposed) [1.8.4-1]
[23:52] -queuebot:#ubuntu-release- New: accepted erlang-jose [i386] (bionic-proposed) [1.8.4-1]
[23:53] -queuebot:#ubuntu-release- New: accepted pg-similarity [amd64] (bionic-proposed) [1.0~20160916-1]
[23:53] -queuebot:#ubuntu-release- New: accepted pg-similarity [armhf] (bionic-proposed) [1.0~20160916-1]
[23:53] -queuebot:#ubuntu-release- New: accepted pg-similarity [ppc64el] (bionic-proposed) [1.0~20160916-1]
[23:53] -queuebot:#ubuntu-release- New: accepted pg-similarity [arm64] (bionic-proposed) [1.0~20160916-1]
[23:53] -queuebot:#ubuntu-release- New: accepted pg-similarity [s390x] (bionic-proposed) [1.0~20160916-1]
[23:53] -queuebot:#ubuntu-release- New: accepted pg-similarity [i386] (bionic-proposed) [1.0~20160916-1]
[23:54] -queuebot:#ubuntu-release- New binary: haskell-bitarray [i386] (bionic-proposed/none) [<IP_ADDRESS>-3] (no packageset)
[23:54] -queuebot:#ubuntu-release- New binary: haskell-bitarray [s390x] (bionic-proposed/none) [<IP_ADDRESS>-3] (no packageset)
[23:54] -queuebot:#ubuntu-release- New binary: haskell-bitarray [ppc64el] (bionic-proposed/none) [<IP_ADDRESS>-3] (no packageset)
[23:54] -queuebot:#ubuntu-release- New binary: pytrainer [amd64] (bionic-proposed/none) [1.11.0-1] (no packageset)
[23:55] -queuebot:#ubuntu-release- New binary: haskell-bitarray [amd64] (bionic-proposed/none) [<IP_ADDRESS>-3] (no packageset)
[23:55] -queuebot:#ubuntu-release- New binary: haskell-bitarray [arm64] (bionic-proposed/none) [<IP_ADDRESS>-3] (no packageset)
[23:56] -queuebot:#ubuntu-release- New binary: haskell-bitarray [armhf] (bionic-proposed/none) [<IP_ADDRESS>-3] (no packageset)


[03:01] <pleia2> ok, got https://bugs.launchpad.net/ubuntu-women.org/ under control for now, 2 more bugs with fixes committed and a ticket submitted for another \o/
[03:02] <IdleOne> Good job pleia2 and Bug fixers!
[03:04]  * pleia2 still needs to follow up with Tubu on a couple fixes she put in, but at least has a list now
[03:13] <pleia2> actually, the css she gave me the other day has what I needed \o/
[03:13]  * pleia2 fix commits another bug
[03:15] <pleia2> #798813 is tricky, I think we need to talk about it at our meeting
[03:17] <pleia2> bug 783303 too
[03:17] <ubot4> Launchpad bug 783303 in ubuntu-women.org "mointheme: Header is too busy (affects: 1) (heat: 3)" [Undecided,New] https://launchpad.net/bugs/783303
[03:17] <pleia2> they are related
[03:17] <pleia2> all style issues that I'm useless about
[03:17] <pleia2> s/style/design
[03:19] <pleia2> anyway, http://uw.princessleia.com/MyWiki (no login required) is updated with the latest things checked into the theme, please kick the tires :)
[05:59] <elky> pleia2, in all honesty, taking the background dots out of the header would do lots for 783303
[06:12] <Tm_T> and side
[06:12] <Tm_T> hmmm, the front page is wall of text
[06:12] <elky> oh, it's about the links. that'll be in the python template file iirc
[06:13] <elky> Tm_T, the dots down the side aren't underneath text
[06:13] <Tm_T> elky: yup, but still makes it appear rather busy
[06:13] <Tm_T> a line or two of dots would work
[06:14] <elky> not really and would throw our colour ratio off from the branding
[06:14] <elky> it's already not grey enough ;)
[06:29] <Tm_T> hmm


[14:08] <edakiri> Is there a better way to create a backup of an archive than archiving the .bzr directory?
[14:09] <edakiri> 'export' appears to only capture a specific revision.
[14:51] <beuno> edakiri, not that I know of, the .bzr dir has all the right information in the right way. You could do a checkout without a working tree and compress that, but it's essentially the same thing
[18:49] <LeoNerd> edakiri: bzr push  it somewhere


[03:28] <ppurka> hi all.. i want to know whether it is possible to get the ubuntu-specific kernel patches for 2.6.30
[04:13] <dhendrix> hey everyone... i'm trying to use make-kpkg to package kernels, but I keep getting annoying interactive warning messages when I try to install a fresh kernel package. I've set "do_initrd = yes", "warn_initrd = no", "clobber_modules = yes", and "silent_modules  = yes" but I still get warnings about installing an initrd kernel and writing over an old /lib/modules/$version directory.
[04:13] <dhendrix> has anyone else seen this?
[09:33] <maxb> Hi, the Karmic ABI 10 kernel results in gnome-power-manager not being able to set/get laptop panel brightness - Acer Aspire One, Intel graphics - any thoughts on what I need to put in a useful bug report?
[09:42] <smb> maxb, It would be interesting to see what is in (and under) /sys/class/brightness. I am not really sure what caused that ever to work. The acpi interface seems not to work and the acer-wmi is supposed not to...
[09:49] <maxb> Actually it works pretty horridly without KMS also
[09:49] <maxb> But KMS makes it actually give errors, rather than just behaving bizarrely, so something has changed
[09:51] <smb> I know. From the 1000 (not really but felt) levels the OSD suggested in Jaunty, only the first 7 or 9 were real.
[09:51] <smb> Hm, errors in dmesg?
[09:51] <maxb> And I don't seem to *have* a /sys/class/brightness !
[09:52] <maxb> I'm booted without KMS at the moment, I'll comb dmesg after my next reboot.
[09:52] <smb> That is what I would expect. With all the experience with the aa1 it seems it does most things internally in the hw
[09:52] <maxb> But KMS itself seems to be working fine, and VT switching is so slick now :-)
[09:53] <smb> True :)
[09:54] <smb> I currently booted an 8.9 kernel with kms and can change the brightness with the hotkeys, but without any osd feedback
[10:00] <mvo> hello. I was wondering if anyone if familar with "crash" and knows if there is a way to get a backtrace without the linux-image-debug package?
[10:06] <smb> mvo, I would not say I am familiar with crash, so I cannot say whether it will do anything without files with symbol information. But in general a backtrace of a kernel stack without cannot tell which function name an address belongs to. And that is unlikely useful
[10:17] <mvo> smb: thanks, it was a small hope I had, the debug pakage is just so huge
[10:17] <smb> mvo, If you compile locally, you could take the vmlinux produced there
[12:08] <mdz> l-r-m is no longer, right?
[12:28] <asac> during boot and in syslog i am seeing: [69908.676578] end_request: I/O error, dev fd0, sector 0
[12:28] <asac> is that known? bugid?
[12:28]  * asac does not have a floppy drive
[12:42] <amitk> mdz: correct.
[12:45] <mvo> asac: I see this as well (and I have no floopy) - IIRC it was a devicekit issue and is already reported
[12:46] <asac> mvo: hmm. ok. but that happens really early during boot
[12:46] <asac> something like "testing for hardware ..." ...
[12:47] <asac> and then that takes ages and it spits out those messages
[12:55] <mvo> oh
[12:55] <mvo> asac: maybe its something else then
[13:43] <maxb> If killing devkit-disks-daemon stops it, it's likely the already reported issue
[14:08] <pgraner> ogasawara_: ping
[14:10] <pgraner> ogasawara_: unping /me forgot your in PST
[14:17] <zhoujingrui> hi
[19:57] <rtg> apw: are you familiar with the grub2 --no-floppy borkage?
[20:06] <apw> rtg no not heard anything about that
[20:06] <apw> where is that being discussed
[20:28] <maxb> Since updating to karmic abi 10, on some boots intermittently, my touchpad intermittently gets reported as a 'PS/2 Synaptics TouchPad' instead of a 'SynPS/2 Synaptics TouchPad', causing hal to miscategorise it as a mouse.... any thoughts on what to dig into?
[20:29] <rtg> maxb: IIRC there was a reset patch, or perhaps an unusual device patch for that.
[20:30] <rtg> that was in Jaunty, so it ought to still be in Karmic
[20:37] <maxb> This problem is new in karmic abi 10
[20:40] <rtg> maxb: hmm, almost all of the work from ABI 9 to 10 was config stuff. Is there some config option that has disappeared or changed?
[21:08] <apw> rtg as i recall the configs were mostly unchanged
[21:08] <rtg> apw: that was my observation as well
[21:23] <JFo> ogasawara, thanks for being willing to guide me. I'll pester you after I have read up more on the information you gave me :-)
[21:23] <ogasawara> JFo: great, thanks for wanting to help!
[21:23] <JFo> no problem


[02:41] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: xfce4-pulseaudio-plugin 0.4.5 released<EMAIL_ADDRESS>[10:13] <Unit193> Crap, I didn't nab it and we're pretty late in a freeze...
[12:57] <ochosi> maybe we can at least fetch the one commit that improves the recording indicator?
[14:46] <XubuntuFan> hello all
[14:46] <XubuntuFan> i have a question
[14:47] <XubuntuFan> are the real devs from Xubuntu here ?
[14:47] <XubuntuFan> because i want to say thanks alot to them for Xubuntu
[14:47] <XubuntuFan> i am very happy with my install on my old HP laptop.
[14:47] <XubuntuFan> well if the devs are here , alot thanks guys!
[14:48] <XubuntuFan> keep up the good work!
[15:00] <bluesabre> <3
[23:35] -SwissBot:#xubuntu-devel- ::xubuntu-default-settings:: Import bug comments and linked attachments from Launchpad (#54) @ https://github.com/Xubuntu/xubuntu-default-settings/commit/171b60f271c04dfe1b8a7e6859f608b6c4d4a8b5 (by bluesabre)
[23:35] <bluesabre> That was a fun project. :)