[01:10] <thumper> mwhudson: I'm back now.  When do you want to talk about recipies?
[01:10] <mwhudson> thumper: i haven't really started anything after my lunch break so now ish is good
[01:11] <mwhudson> thumper: gimme a minute to fetch a drink
[01:11] <thumper> mwhudson: ok, let me grab a glass of water and I'll call you
[01:13] <mwhudson> thumper: ready now
[01:18] <dhillon-v10> mwhudson: ping :)
[01:52] <mwhudson> http://people.canonical.com/~michaeln/bfb/build_now_overlay_v2-expanded.png
[03:29]  * thumper off to take advantage of sunshine, back later
[07:32] <noodles775> G'day all
[07:37] <noodles775> lifeless: Hi, will you have a chance to look at bug 509370 solution before I get it reviewed and landed?
[07:37] <mup> Bug #509370: PPA access granted for XXXX mail does not identify the PPA. <email> <ppa> <trivial> <Soyuz:In Progress by michael.nelson> <https://launchpad.net/bugs/509370>
[07:37] <noodles775> s/at/at the
[07:39] <NCommander_> hey noodles775
[07:39] <wgrant> Morning.
[07:41] <lifeless> noodles775: I'm sure you understood the issue, so whatever you've done should be fine
[07:41] <lifeless> noodles775: if you have some reason to think it won't be, I can make time to look at it.
[07:42] <NCommander_> noodles775: do you know if there are any Soyuz specs to implement binary rebuilds?
[07:44] <noodles775> lifeless: ok, I was slightly confused about it, as it is a private PPA that the subscriber doesn't actually have access to, but I've just added the actual PPA name (as opposed to the displayname) and included the description in the email. Thanks.
[07:46] <noodles775> NCommander_: hi, it seems to be currently without priority - mentioned at https://dev.launchpad.net/Soyuz/WantedFeatureList with the relevant bug.
[07:47] <NCommander_> noodles775: I was hoping there were some design docs or spec on the topic
[07:47] <noodles775> Evening wgrant.
[07:49] <lifeless> noodles775: the key thing I'd want to see is the ppa: url
[07:49] <lifeless> noodles775: which is perhaps what you mean by 'actual PPA name'
[07:49] <lifeless> noodles775: the problem being that many many people have a PPA called 'releases' :)
[07:50] <noodles775> lifeless: by 'actual PPA name' I mean the IArchive.name property which is what is used in the URL. Including the URL has a few issues, the main being that the user *doesn't* have access to view the URL.
[07:51] <noodles775> (and won't even when they are subscribed - they can download software, but not see the details of uploads etc.
[07:52] <lifeless> noodles775: I don't understand the issue: the URL is what they add to add-apt-repository etc - its the unique key for the thing.
[07:52] <lifeless> noodles775: I don't know what IArchive.name property /means/
[07:52] <noodles775> lifeless: ah, the apt url - right, I thought you meant the LP url.
[07:52] <lifeless> noodles775: but here is my test: If I can be confused because someone else has a similarly named PPA, then the bug won't be fixed.
[07:53] <wgrant> The URL, or ppa:wgrant/ppa?
[07:56] <noodles775> wgrant: right - As long as owner ? ppa name is there it's sufficient to uniquely identify it. Currently the email includes the name, but not the owner (instead displaying info about the person who subscribed you, which won't always be the same)
[07:56] <lifeless> wgrant: so, ppa:wgrant/ppa, and https://launchpad.net/~wgrant/+archive/ppa - either would be fine for me
[07:57] <noodles775> Neither of those are actually accessible, but yes, the unique info is contained there.
[07:57] <lifeless> and I don't want to pin noodles775 down to doing something that doesn't make sense, which is why I'm trying to keep it high level - that both the owner and url element, not the visible description, need to be visible.
[07:57] <lifeless> noodles775: great, I shall be happy then
[07:58] <noodles775> Yep, that's great. Thanks.
[08:46] <adeuring> good morning
[08:49] <maxb> What is the ettiquette for submitting branches to devel, which you know will cause a conflict in the stable->db-devel automerge?
[08:50] <maxb> (It's just an unfortunately clashing import change)
[08:58] <thumper> maxb: propose for devel, and land
[08:58] <thumper> maxb: once in devel, merge into db-devel
[08:58] <thumper> maxb: when the automatic merge from stable -> db-devel happens, it is a no-op
[08:58] <mrevell> Hi.
[08:58] <thumper> hi mrevell
[09:00] <maxb> Thanks
[09:04] <maxb> gmb: When you have time, could I trouble you for review of the additional unreviewed changeset in https://code.edge.launchpad.net/~maxb/launchpad/use-hashlib/+merge/18894 ? - thanks
[09:10] <lifeless> hi jml
[09:14] <jml> lifeless, hi
[09:20] <jml> jelmer, hi
[09:43] <gmb> maxb: Sure, I'll look now. Sorry, I forgot all about that yesterday
[09:45] <gmb> maxb: Looks good.
[09:45] <gmb> maxb: Want me to ec2  it ?
[09:45] <maxb> Excellent ... yes please
[09:46] <gmb> It's on its way.
[10:41] <jelmer> jml, 'morning
[10:42] <nigelb> any launchpad devs around? I have a feature request and want to know if it is technically feasible before requesting
[10:42] <nigelb> Recently, we've been having quite a large amount of spam, is it possible to revert all the changes made by a user in this case?
[10:43] <nigelb> now, we are manually having to change it.  That comes to modifying around 40 or so bugs
[10:52] <jelmer> nigelb: The required information is present to do something like that, but I have no hard it would be to implement.
[10:52] <jelmer> nigelb: please file a wishlist bug against Launchpad
[10:52] <nigelb> jelmer, so shall I log a bug and hope for the best that it would be tried at some point?
[10:53] <nigelb> oh, great. thanks
[10:53] <wgrant> jelmer: It's not necessarily all present, sadly.
[10:53] <wgrant> The activity log isn't perfect.
[10:53] <wgrant> Although it's much better than it was a few months ago.
[11:43] <nigel_nb> jelmer, bug 520413 opened in LP :)
[11:43] <mup> Bug #520413: All changes by user must be revertable <Launchpad Bugs:New> <https://launchpad.net/bugs/520413>
[11:44] <jelmer> nigel_nb, thanks :-)
[11:45] <nigel_nb> could you please set that to wishlist?
[12:41] <sinzui> nigel_nb: we do not use wishlist (we should remove that status). We use the feature tag and usually mark it as low. Low mean it will be fixed opportunistically, but the feature tag means we need a blueprint for it
[12:42] <nigel_nb> sinzui, and the blueprint would be made at your end ?
[12:42] <nigel_nb> i.e., anything nothing more I can do?
[12:43] <sinzui> nigel_nb: not necessarily us. anyone may, and any feature should have one.
[12:43] <nigel_nb> sinzui, so can I write (or get help from some one to write) one and add a feature tag?
[12:44] <sinzui> nigel_nb: We only commit to working on high priority work. The priority is determined by our goals, oops, and some bugs. contributors can and do work on low priority features to improve launchpad for their community.
[12:45] <sinzui> nigel_nb: I added that tag before you asked to have it set to wishlist :)
[12:46] <nigel_nb> sinzui, well, I'm not a dev at all.  But I can create a feature spec if someone wants to work on it :)
[12:46] <nigel_nb> I'm afraid this *could* potentially be high priority later on
[12:48] <sinzui> nigel_nb: I think we really want to understand what needs to be accomplished and why. A spec implies we know that. We may want to change ACLs and that will make the suggested solution moot.
[12:48] <nigel_nb> sinzui, um, what are ACLs?
[12:49] <sinzui> access control list. If the the untrusted user could not make the change, there would have been no request to rollback the data.
[12:52] <nigel_nb> sinzui, ah, well that makes sense too!   The last week had two.
[12:57] <nigel_nb> True.  But it would be nice to have a fail-safe
[13:33] <sinzui> jpds: ping
[13:36] <jpds> sinzui: Pong.
[13:38] <sinzui> jpds: my test for your api changes never enters the loop: http://pastebin.ubuntu.com/373951/ can you hit me with a clue-by-four so that I can test  the api changes?
[13:40] <wgrant> Is that the broken unauthenticated launchpad.View adapter problem?
[13:40] <thekorn> I think so
[13:41] <sinzui> yes it is
[13:41] <sinzui> thank you everyone.
[13:41] <thekorn> bug 515761
[13:41] <mup> Bug #515761: Anonymous API access to some collections returns nothing <qa-ok> <Launchpad Foundations:Fix Committed by jamalta> <https://launchpad.net/bugs/515761>
[13:41] <sinzui> ...I should not have cargo-culted my anonymous test for this test
[13:41] <wgrant> You should have.
[13:41] <wgrant> It exposed another bug.
[13:46] <intellectronica> thekorn: thanks for the work on the iperson_ihasbugs branch. the branch looks in good shape now. set the commit message and i'll land it for you
[13:47] <thekorn> intellectronica, super, thanks. will set this message in a bit
[13:52] <jpds> sinzui: I just mirror = ubuntu.getMirrorByName(name="releases.ubuntu.com") personally.
[13:54] <sinzui> jpds: yes that works, but as wgrant and thekorn rightly noted, there is another bug. I tested it as anonymous and I could not get the mirrors. I am looking for the bad interface
[13:54] <jpds> Groovy.
[13:54] <wgrant> There is no launchpad.View for mirrors.
[13:54] <wgrant> There needs to be, for other reasons, which will fix this.
[13:57] <thekorn> intellectronica, I added a commit message
[13:58] <intellectronica> thekorn: lovely, thanks.
[15:32] <maxb> What's PQM up to, and is lp:~maxb/launchpad/use-hashlib coming up soon?
[15:49] <bigjools> maxb: should have gone through now, the queue is empty
[15:51] <maxb> Something's eaten my branch :-(
[15:51] <maxb> I have a test results email confirming ec2 success
[15:59] <maxb> Well, if it's not in devel and its not in PQM, could someone resubmit it directly to PQM for me?
[15:59] <maxb> lp:~maxb/launchpad/use-hashlib  -> devel
[15:59] <maxb> "[r=gmb][ui=none] Switch from using sha and md5 to hashlib. Also use hashlib.sha256 instead of the python-apt implementation."
[16:19] <bigjools> it's in testfix mode :/
[16:58] <thekorn> allenap, thanks for your comments ;)
[16:59] <thekorn> allenap, ...and your patch
[17:00] <allenap> thekorn: Cool, no worries. Thank you for doing the branch :)
[17:01] <thekorn> allenap, I promise, future branches will have smaller diffs :)
[17:02] <allenap> thekorn: It grew naturally, so no complaints here.
[17:03] <thekorn> yeah that's exactly the problem here
[17:15] <thekorn> allenap, when I move get_related_bugtasks_search_params() to bugs.model.bugtask should this IllegalRelatedBugTasksParams exception stay in registry.interfaces.person or can this exception be moved somewhere to bugs.*
[17:15] <leonardr> flacoste: do you have time for a quick pre-impl chat?
[17:16] <leonardr> the bug is https://bugs.edge.launchpad.net/lazr.restful/+bug/520542
[17:16] <mup> Bug #520542: confusing latest_version_uri_prefix should be merged into active_versions <lazr.restful:New> <https://launchpad.net/bugs/520542>
[17:16] <leonardr> basically, people who encounter latest_version_uri_prefix are confused
[17:17] <leonardr> my plan is to not spell that our separately, just have it be the last version mentioned in active_versions
[17:17] <leonardr> the underlying implementation would be the same
[17:17] <leonardr> the only downside i can think of is it might be confusing to always have 'devel' or 'trunk' at the end of the list, and to slip versions into the list near the end instead of adding them at the end
[17:18] <leonardr> but i think on balance it's better without latest_version_uri_prefix
[17:18] <leonardr> let mek now if you agree
[17:20] <flacoste> leonardr: agreed
[17:23] <allenap> thekorn: Good question. lp.bugs.interfaces.bugtask seems likely, but I'll check.
[17:24] <allenap> thekorn: Yeah, that's the place.
[17:25] <thekorn> okidoki,moving it there, thanks
[17:25] <kfogel> jml: thanks for the quick re-review
[17:49] <salgado> deryck, around? is bug 520584 known?
[17:49] <mup> Bug #520584: Person (assignee) picker is broken on +filebug <Launchpad Bugs:New> <https://launchpad.net/bugs/520584>
[17:50] <deryck> salgado, yes.  I thought there was a bug for that already.
[17:50] <salgado> I couldn't find one
[17:51]  * deryck looks
[17:55] <deryck> very aggravating.  I know I've seen a bug for this before.
[17:56] <jtv> I'm tired of writing one-liner stub methods in my tests.  Unless something *simple* already exists, I'm introducing a helper class FakeMethod that gives you a stub for any function or method and counts the invocations.
[17:59] <deryck> salgado, found it.  and marked yours accordingly.
[17:59] <deryck> salgado, thanks for the heads up, though.
[17:59] <salgado> thanks deryck
[18:03] <mrevell> night
[18:07] <jml> g'night all.
[18:20] <thekorn> allenap, still around?
[18:25] <kfogel> jml: g'night
[18:26] <kfogel> deryck: any idea what's going on here?  http://paste.ubuntu.com/374133/   (i.e., why are there instances of "\n\t" in the submit message that PQM is quoting back to me, when they're not in the original?)  I don't see why we'd be in testfix mode...
[18:26]  * deryck looks
[18:27] <deryck> kfogel, we must be in testfix.  Checking builders now...
[18:27] <deryck> kfogel, db_lp is in testfix
[18:28] <kfogel> deryck: "db_lp" means db-devel or something else?
[18:28] <deryck> kfogel, yeah, the db-devel builder.
[18:28] <kfogel> deryck: hm, but this submission is to devel
[18:29] <deryck> kfogel, yeah, but if either buildbot is broken we go into testfix mode.
[18:30] <kfogel> deryck: oh, I didn't know that.  Okay, thanks.
[18:30] <maxb> Is anyone working on un-testfixing?
[18:31] <deryck> I seem to recall something about db devel in email this morning.
[19:29] <mwhudson> good morning
[19:35] <maxb> Are we un-testfixed now? If so, please could someone do a PQM submit for me?
[20:11] <mwhudson> barry: ping?
[20:11] <barry> mwhudson: pong
[20:11] <mwhudson> barry: do you know anything about getting the magic gdbinit file to work with python2.5?
[20:12] <mwhudson> maxb: yes, untestfixed it seems
[20:12] <barry> mwhudson: i wasn't aware that it didn't work, but it's been a long time since i tried.
 lp:~maxb/launchpad/use-hashlib  -> devel
 "[r=gmb][ui=none] Switch from using sha and md5 to hashlib. Also use hashlib.sha256 instead of the python-apt implementation."
[20:13] <maxb> That got ec2tested OK but apparently dropped on the floor presumably due to testfix
[20:13] <barry> mwhudson: which gdbinit file are you using?
[20:13] <mwhudson> i think it'll be ok with a non-debug build, but too much seems to get inlined into PyEval_EvalFrameEx in the release build
[20:13] <mwhudson> man gdb's command language sucks
[20:14] <bdmurray> where do the losa's hide out?
[20:14] <mwhudson> bdmurray: here, among other places
[20:15] <mwhudson> barry: i'm using the one from the release2.5-maint branch currently
[20:15] <bdmurray> I'd like a Launchpad account suspended.
[20:16] <mwhudson> aaaah
[20:17] <mwhudson> gdb has an embedded python interpreter now
[20:17] <barry> BOGGLE
[20:18] <mwhudson> OH MAN
[20:18] <mwhudson> ACTUAL PROGRAMMING WOO
[20:22] <maxb> Sorry to nag, but as my message is vanishing up in the scrollback: Would someone be able to do a PQM resubmit for me?
[20:22] <mwhudson> maxb: i guess i'm not very trusting, but i'd like confirmation that it passed ec2 from somewhere
[20:23] <mwhudson> did gmb try to land it?
[20:23] <maxb> quite understandable. Shall I forward the ec2test email to mwh@canonical?
[20:24] <mwhudson> maxb: that'd be good
[20:24]  * mwhudson grrs at gdb's python thing
[20:24] <mwhudson> close but no cigar
[20:27] <maxb> sent
[20:28] <mwhudson> ok, got
[20:39] <mwhudson> maxb: in pqm
[20:39] <maxb> \o/
[21:40] <wgrant> jelmer: I notice that your sync-source.py fix tests for lzma tarballs, which are not supported by dak or LP.
[22:36] <EdwinGrubbs> maxb: ping
[22:37] <maxb> EdwinGrubbs: pong
[22:38] <EdwinGrubbs> maxb: I saw your email. I wasn't sure if that was something you were planning to work on, or if I should plan on doing it.
[22:38] <maxb> This is about PIL 1.1.7, right?
[22:39] <EdwinGrubbs> maxb: right
[22:40] <maxb> The relevant change to debian/control is a mere 10 characters or so. I figured I'd leave it to you, as you can better explain why we need 1.1.7
[22:40] <EdwinGrubbs> ok, cool
[23:41]  * mwhudson lunches
[23:42] <maxb> Hrm
[23:42] <maxb> launchpad-database-dependencies is no longer installable on lucid, because postgresql-8.3-slony1 has been dropped
[23:42] <wgrant> Oops.
[23:42] <wgrant> Rebuild rebuild rebuild?
[23:43] <wgrant> Or convince stub to fix 8.4..
[23:43] <wgrant> maxb: Do you have any ideas on the lucid python-setuptools incompatibility?
[23:43] <maxb> I've not looked at the slony1 source package, but adapting it to build for multiple postgresql versions doesn't sound all that fun
[23:44] <maxb> wgrant: I've not examined it - I've literally just upgraded my desktop to lucid now, so I've been focussing on karmic+2.6 up til now
[23:44] <wgrant> maxb: Ah, right.
[23:44] <wgrant> Well, you'll probably need to download python-setuptools and python-pkg-resources to their karmic versions, because of the migration to distribute.
[23:45] <wgrant> I must file a bug on that.
[23:45] <maxb> Oh, the setuptools guys are starting to think about fixing the bug that stops us using pytz source#
[23:45] <maxb> I need to get back to them about that, actually
[23:45] <wgrant> Ah, good.
[23:50]  * maxb wonders what the lp buildbot is up to
[23:51] <maxb> 6 more revs in devel over stable seems high
[23:52] <wgrant> It should be just a few minutes off merging.
[23:53] <wgrant> (I'd guess < 10)
[23:55] <maxb> I wonder if slony1 is actually needed for launchpad development environments
[23:57]  * maxb ponders the idea of a slony1pg83 renamed source package that only builds the postgresql-8.3-slony1 binary (slony1-bin and slony1-doc unbuilt and coming from the lucid archive)


[16:25] <blackboxsw>  beantaxi happy new year, checking it out now. reopening is always allowed/encouraged
[16:29] <samgranieri> Good morning. I'm having some trouble trying to add a ppa in my user-data file. I've attached a few logs and my user data file here. https://gist.github.com/samgranieri/0ce80186349b846f8c9adbdf63353591
[16:30] <samgranieri> If anyone has any tips on how to get this ppa ready, that would be amazing
[16:31] <blackboxsw> beantaxi: ahh the reason it can't be "re-opened" in its current state is because we renamed "master" banch to "main" to establish more inclusive naming practices. So your merge target of "master" no longer exists. I would suggest opening up a new pull request against upstrem/main.
[16:32] <blackboxsw> beantaxi: maybe something like `git checkout shell-script-handlers-by-freq; git fetch upstream; git rebase -i upstream/main; git push beantaxi shell-script-handlers-by-freq --force`
[16:34] <beantaxi> blackboxsw: Thanks! I just now glanced at the PR and saw you have removed stale. Thanks for the detail on why it can't be reopened.
[16:37] <beantaxi> The other day I did a merge (though not a rebase) from upstream/main onto my feature branch. So are you suggesting pushing my feature branch, now with latest from main, and then opening a new PR against the branch? If I am understanding you correctly, that sounds fine from my end
[16:39] <blackboxsw> samgranieri: your error looks like it's the Traceback which tries to look for the filename key inside your source object.
[16:39] <blackboxsw> samgranieri: so the problem really is in user-data, each apt: sources: object should be a dict, not a list.
[16:40] <blackboxsw> samgranieri: so remove the leading hyphen '-' from https://gist.github.com/samgranieri/0ce80186349b846f8c9adbdf63353591#file-1-user-data-yaml-L32
[16:40] <samgranieri> @blackboxsw i'll try that, thanks
[16:43] <blackboxsw> honestly our JSON schema should have warned about that being an invalid type. I'll make sure that the existing James has up for this catches that case.
[16:44] <blackboxsw> https://github.com/canonical/cloud-init/pull/1155
[16:51] <samgranieri> @blackboxsw that did the trick, thank you!
[16:53] <blackboxsw> great to hear samgranieri. Yeah I see our existing schema definition doesn't define the strict schema for objects below "sources" https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_apt_configure.py#L375
[16:53] <blackboxsw> so we'll have to extend the schema there so you'd get a nice warning telling you about invalid type
[18:10] <jchittum> blackboxsw : i know we were just chatting, but i think PR #1158 should be gtg. i did rebase and push after the reformatting, and made sure it was happy with linting
[18:14] <blackboxsw> jchittum: awesome . oops right. Just merged
[18:16] <jchittum> LOL. ubottu, bad bot. i meant github not launchpad.
[18:40] <holmanb> @blackboxsw - https://github.com/canonical/cloud-init/pull/1130 now addresses your requested change


[01:15] <james_w> could someone with the power please let my mail out of the kernel-team moderation queue?
[05:05] <Sarvatt> http://patchwork.kernel.org/patch/33044/
[05:05]  * Sarvatt cheers
[08:58] <apw> TheMuso, i see the latest upload actually one of the ports kernels built!
[09:01] <smb> I actually only saw powerpc fail
[09:01] <smb> err no, sparc as well
[09:47] <amitk> smb: regarding the ipw3945 patches. I have a question regarding the first one
[09:48] <amitk> smb: if there is a running worker, it will first unregister the device by calling ieee80211_unregister_hw(priv->hw)
[09:49] <amitk> but it doesn't call iwl3945_down()
[09:50] <amitk> is the call to down() not needed any more?
[09:52] <smb> amitk, As I understood the change the down is done when there is no interface registered. I assume it is part of the unregister
[09:53] <amitk> ok
[09:55] <smb> amitk, I did not follow that so closely as that change come around 2.6.29 and still looks the same, so I think it should make sense
[10:38] <TheMuso> apw: Yeah, but I see you missed my pull request with a powerpc config fix.
[11:23] <Laney> Hi ho, how can I get you guys some useful debugging info? If I try to boot with .31 then my system reboots after about 5 seconds...
[11:31] <apw> TheMuso, i'll get it in the next one
[11:40] <Keybuk> apw: the tmpdevfs kernel worls
[15:46] <Lascax> Hi all
[15:46] <Lascax> Question: there is a way to convert a patch for an older kernel to make it compatible with a new one?
[15:48] <amitk> Lascax: you apply the patch to the new kernel and if it fails, fix the 'rejects'
[15:48] <amitk> then create a new patch
[15:49] <Lascax> amitk: well, I am new to ubuntu. There is a guide on how to fix the rejects?
[15:49] <amitk> Lascax: this isn't specific to Ubuntu. It is a feature of the 'patch' program.
[15:50] <Lascax> Yeah, my mistake.
[15:50] <amitk> patch will tell you what parts of the old patch did not apply (because that part of the code might have changed)
[15:50] <amitk> then you fire up a text editor, open the file and hand apply the changes until it does the right thing
[15:51] <Lascax> OK, I hope there aren't a lot of changes between 2.6.22 kernel and 2.6.28 (for example Inoticed that one fo the files changed from .c to .h)
[15:51] <amitk> Lascax: just look at any of the patch examples from Google
[15:51] <amitk> Lascax: depends on the code you are trying to port.
[15:52] <Lascax> amitk: this is the link fo the patch that I want to port. A lot of code is changed, I already noticed in the new files. ( http://drp.id.au/linux-2.6.16-joydev.patch )
[15:53] <amitk> Lascax: is it known to not work on 2.6.28?
[15:54] <Lascax> amitk: already tried to force compiling with it redirecting to the files, but no new command in the makemenuconfig
[15:54] <Lascax> amitk: this patch adds a command in the menuconfig
[15:54] <amitk> Lascax: I meant, does the HW not work on 2.6.28 already?
[15:55] <Lascax> amitk: it works, but there is still the axis problem (this is a patch to make directional buttons of the joypad to be digital input instead analogic)
[15:56] <Lascax> amitk: no recognization of up+down and right+left, for example
[15:57] <amitk> Lascax: I'd suggest first understanding how 'patch' works. A few simple examples might make it clearer how to port this code
[15:57] <amitk> but I've got to go now...
[15:58] <Lascax> amitk: ok, hope to see you later. Nobody helped me with this until now, nor at #ubuntu-it nor at #ubuntu
[15:59] <Lascax> amitk: last question. I found the same patch for 2.6.22 ( http://drp.id.au/linux-2.6.22-joydev.patch ) Can it be easier to convert than the one for 2.6.16?
[15:59] <amitk> Lascax: good luck.
[15:59] <amitk> Lascax: yes, it will be easier to convert from later kernel
[15:59] <Lascax> amitk: OK, thx for helping. I still have an hope :-)
[16:01] <amitk> Lascax: np
[16:41] <bdmurray> smb: Where was bug 330824 Fix Committed?
[16:41] <ubot3> Malone bug 330824 in linux "Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28" [Medium,Fix committed] https://launchpad.net/bugs/330824
[16:42] <broonie> Does anyone have any info on how the process of upstreaming the ARM changes you guys are carriying is progressing?
[16:42] <smb> bdmurray, It was always part of the 2.6.28.y stable impart iirc
[16:42] <bdmurray> smb: okay, there was a follow up question regarding it in the bug
[16:43] <smb> bdmurray, Oh. I would have to look a it close. I just went over all the bugs that had references in the next proposed i am preparing
[17:07] <james_w> hi all, I've sent a mail to kernel-team and it's stuck in the moderation queue, could someone fish it out for me please?
[18:00] <Sarvatt> so is hardy the last release that has the ide-scsi module on powerpc thats needed to install from an alternate disk for ibooks? just burnt off karmic and jaunty but neither can detect the cd drive on my ibook (and fail during the install because of it) and i cant figure out what module to manually load it if it isnt ide-scsi
[21:57] <Sarvatt> heyo, just want to suggest maybe disabling radeon KMS by default but perhaps leaving it enabled in staging so its still possible to use. perhaps in drivers/gpu/drm/radeon/radeon_drv.c changing line 85 int radeon_modeset = -1; to int radeon_modeset = 0;? things work fine in the current userspace with radeon.modeset=0 but the default radeon.modeset=1 doesn't have the userspace to support it yet in karmic.
[22:18] <Sarvatt> disabling it completely from staging would preclude the nescessary headers from getting into linux-libc-dev to build the userspace to support it on xorg-edgers to work out the kinks supporting it is why I was suggesting that instead of disabling it completely. booting with radeon.modeset=0 works fine how it is currently