[12:16] <ogra> hmmm, /dev  12G  4,6G  5,9G  44% /.dev why is it this big ?
[12:16] <ogra> ahh, nm, i'm blind
[12:16] <Seveas> ogra, you know how df works, right? :)
[12:17] <ogra> partly, yes (never hecked the source ;) )
[12:17] <ogra> checked even
[12:17] <GheRivero> res
[12:17] <zul> lamont: ping
[12:18] <lamont> ack
[12:19] <zul> check out kernel
[12:19] <zul> er, #-kernel
[12:20] <zul> abi breakage
[12:23] <thom> mdz: ack
[12:37] <thom> mdz: sorry, sleep time.
[12:38] <zul> kernel is building bbiab
[12:45] <mvo> mdz: send you a mail about the package-queueing
[01:00] <mdz> mvo: thanks
[01:03] <mvo> mdz: do you have a moment for two additional questions?
[01:03] <mdz> mvo: yes
[01:04] <mvo> mdz: I think #7419 is a apt bug, how should we proceed? trying to solve it in apt? or trying to work around it?
[01:05] <ogra> thom: bah, sleep is for past release.....
[01:05] <mdz> mvo: we should work around it; I think changing the problem resolver would be crazy
[01:05] <mdz> mvo: maybe for hoary+1 we should think about using aptitude's resolver
[01:06] <mvo> mdz: I looked at aptitudes algorithm and it's not really seperated, but I agree that we should try to fix it. IIRC apt-rpm has some fixes too that may be usefull
[01:06] <mvo> (or may not)
[01:06] <mdz> my standing opinion has been that we need a test suite before we can make that kind of change
[01:06] <mdz> otherwise by fixing one case, we break another
[01:07] <mvo> agreed, at least we need some regression testing code
[01:08] <mvo> mdz: how would you like to see #6761 fixed? as part of apt itself (like the current auto-clean)? or as part of the new apt periodic cron-job
[01:08] <mvo> ?
[01:09] <doko> mvo: pong
[01:09] <ogra> YokoZar, ?
[01:15] <mdz> mvo: I think we should add an option to cron.daily/apt
[01:16] <mdz> mvo: I think the ideal solution would be a combination of the two ideas I presented
[01:16] <mvo> mdz: all right, will look at it. thanks!
[01:16] <mdz> mvo: e.g., APT::Cache::Min-Age and APT::Cache::Size
[01:17] <mdz> (Cache::Archives perhaps)
[01:17] <mdz> mvo: meaning "Remove files older than Min-Age, until the cache is smaller than Size" or some such
[01:18] <mdz> mvo: it will be tricky to choose defaults which will be good for both stable releases and development systems, though
[01:18] <mdz> mvo: perhaps it would be better to keep it simple
[01:18] <mdz> I'm open to suggestions
[01:19] <mvo> mdz: what do you think about making it either: age (e.g. 10 days) _or_ size (<300Mb)?
[01:20] <mvo> mdz: I'll think about it a bit and add something to the bugreport
[01:20] <mdz> mvo: ok, but let's implement something soon, so that it can be tested for a good long while
[01:21] <mvo> mdz: ok, I'll make it priority
[01:32] <YokoZar> ogra: arr?
[01:32] <ogra> YokoZar: to late, i mailed you back
[01:36] <ogra> YokoZar: you didnt answer my question in the mail, are winetools 100% compatible with the wine packages currently in universe (does the config work for them ?)
[01:36] <YokoZar> Yeah
[01:37] <YokoZar> I thought I did, sorry
[01:37] <YokoZar> Winetools works in the user's home directory, mucking about with .wine - it works with the debian wine packages, but those only work if a user installs every component (since they're needlessly split)
[01:38] <ogra> YokoZar: you said they only depend on wine, which was not what i asked ;)
[01:38] <bluefoxicy> http://www.openoffice.org/issues/show_bug.cgi?id=41966 this issue is fixed in the new openoffice 2.0 beta
[01:38] <bluefoxicy> but exists on ubuntu
[01:38] <ogra> YokoZar: thats why i was asking but the above sounds good :)
[01:39] <mvo> Mitario: got some jabber errors :/
[01:39] <crimsun> bluefoxicy: in the openoffice.org2 packages, too?
[01:39] <bluefoxicy> crimsun: 1.9.74 is affected, 1.9.79 is not
[01:40] <bluefoxicy> Ubuntu uses 1.9.74
[01:40] <crimsun> k
[01:40] <bluefoxicy> http://www.openoffice.org/issues/show_bug.cgi?id=44764 has an example file
[01:40] <YokoZar> When I have evolution open and click a mailto link in firefox it opened a new copy of evolution on me (rather than just a new mail message) - can someone else confirm this behavior?
[01:41] <ogra> nope, worksforme
[01:44] <Mitario> mvo, oh :(
[01:44] <mvo> Mitario: yeah, and I'm about to go to bed now
[01:44] <mvo> pretty late :)
[01:44] <Mitario> mvo, indeed :) i'm going too
[01:44] <Mitario> nite everyone
[01:44] <Mitario> just finished my little python library :p
[01:45] <ogra> night
[01:45] <daniels> mdz: yeah, it's DDC
[01:47] <koke> an idea before sleep
[01:48] <koke> it should be nice if the xscreensaver lock dialog showed a warning, like the gdm one, if you have caps lock enabled
[01:48] <koke> what do you think?
[01:49] <mdz> mvo: night
[01:49] <mvo> night mdz
[01:49] <mdz> koke: yes, I agree that would be a good idea
[01:49] <ogra> night mvo
[01:49] <koke> mdz: ok, I've it noted in my tomboy ;) tomorrow I'll file a bug on that
[01:50] <koke> my batteries are low :)
[01:50] <mdz> koke: that isn't what I meant when I said it was a good idea :-)
[01:50] <koke> bye
[01:50] <koke> :P
[01:51] <koke> filing a bug does not meant I'm not going to try fixing it myself :)
[01:51] <mdz> if I thought it would be a good idea to file bugs about every feature that I would like to see in Ubuntu, I would singlehandedly double the number of open bugs easily :-)
[01:52] <koke> well, maybe change the "filing a bug" to "write to ubuntu-devel@"
[01:52] <koke> or maybe if I have one of these bright days, to "send a patch to..."
[01:52] <koke> :D
[01:53] <mdz> I would like to find a way to better manage feature ideas
[01:53] <mdz> neither bugzilla nor mailing lists are very good for this
[01:53] <koke> wiki/IdeaPool ?
[01:53] <koke> maybe too chaotic
[01:53] <ogra> wiki, but idea pool ?
[01:54] <tseng> well, jdub just made a post on this
[01:54] <tseng> to pgnome
[01:54] <tseng> you need to have a well defined spec for feature requests
[01:54] <tseng> http://jimmac.musichall.cz/weblog.php/Design/Speccing
[01:55] <jdub> ^ not jdub ;-)
[01:55] <tseng> yeah uh
[01:55] <tseng> i meant jimmac, maybe i did a tab complete or something
[01:55] <tseng> or a brain-o
[01:55] <jdub> mdz: i'm convinced a slightly different frontend and query would really help
[01:56] <hsprang> mdz: maybe the feature tracking thing is less a problem of tools but of the way you try to tackle it?
[01:56] <mdz> jdub: for the suspend/hibernate stuff?
[01:56] <jdub> mdz: feature requests
[01:56] <mdz> ah
[01:56] <mdz> yes, I agree
[01:56] <jdub> which is pretty much what mark talks about wrt malone
[01:56] <mdz> hsprang: as jdub says, I think tools would help a great deal
[01:56] <jdub> different interface, different workflow
[01:57] <mdz> right, feature requests have an entirely different workflow
[01:57] <tseng> you could build a spec into the interface
[01:57] <ogra> jdub: if it ever gets ready
[01:57] <hsprang> mdz: yes, but the tools can only help if you have a clear idea of the process
[01:57] <mdz> they should be put into a tracking system in order to store the discussion and status, but bug tracking workflow is all wrong
[01:57] <mdz> I have some pretty good ideas about process
[01:57] <jdub> interested people could farm the requests, talk to maintainers about them, and answers to the requests can be saved as documentation of the decision
[01:58] <jdub> hmm, so you'd have a slightly different search interface for features too
[01:58] <hsprang> mdz: so, you have the process clearly defined somewhere?
[01:59] <mdz> hsprang: I wouldn't go as far as to say that it's clearly defined, but I have a clear idea in my head
[01:59] <mdz> based on experience
[02:00] <hsprang> mdz: so, you'll have to get it outta your head, document and communicate it, and others can help you find the tools
[02:01] <mdz> hsprang: that's the usual process, yes
[02:01] <mdz> hsprang: that's what we do at Ubuntu conferences
[02:01] <mdz> the next one is at the end of April in Sydney
[02:02] <jdub> and it's going to ROCK
[02:02] <hsprang> i doubt i will be able to afford such a vacation until then :(
[02:02] <ogra> vacation ?
[02:03] <hsprang> travel
[02:03] <mdz> hehe
[02:03] <jdub> mdz: hey, there was a good interview with you in the local paper
[02:03] <mdz> more like a week of non-stop work
[02:03] <jdub> http://www.smh.com.au/articles/2005/03/10/1110417596585.html
[02:03] <daniels> jdub: hahaha
[02:03] <mdz> jdub: a what now?
[02:03] <daniels> jdub: if that's what I think it is :)
[02:03] <jdub> daniels: ;)
[02:03] <daniels> jdub: yeah.  'twas on the sidebar of theage also
[02:03] <mdz> oh, my alter-ego
[02:04] <jdub> mdz: did you see fabio's crazy messages the other day?
[02:04] <mdz> jdub: I vaguely remember something in all caps trying to wake me up early in the morning :-P
[02:04] <jdub> mdz: he was calling you his LITTLE BOLD FRIEND
[02:04] <jdub> he meant BALD
[02:04] <jdub> but we all agreed he was doubly right ;)
[02:05] <mdz> my hair is like 2cm long at the moment; it needs cutting
[02:05] <jdub> yowza
[02:05] <mdz> it is starting to stick up and curl
[02:05] <jdub> ('twas an interesting interview though)
[02:05] <mdz> "It's one of the reasons why George Bush was re-elected," says Moby. "There are a majority of Americans who are scared provincial white Christians.
[02:06] <daniels> 'provincial'
[02:07] <hsprang> non-stop productive work for a week can be a vacation, too :)
[02:07] <ogra> hsprang: its rather fun, but you need a week of vacation afterwards ;)
[02:08] <mdz>      2. Intermission of a stated employment, procedure, or office;
[02:08] <mdz>         a period of intermission; rest; leisure.
[02:09] <jdub> heh
[02:11] <zenwhen> everything was working fine and I did another big upgrade. Now pages are loading slower than molasses. Am I the only person to run into this recently?
[02:11] <zenwhen> I have no idea what package could be causing it.
[02:11] <jdub> daniels: 'Since then, though, Goodrem has had 18 months of controversy. She's gone from being the most popular of our recent Neighbours exports to someone described as "the most hated woman in Britain", courtesy of her relationship with a former boy-band singer.'
[02:11] <jdub> daniels: ha ha
[02:12] <zul> hmmm...building kernel fun..
[02:12] <jdub> yo zul
[02:12] <jdub> how's inotify in the latest 2.6.11?
[02:12] <zul> hey jdub how is it giong?
[02:12] <zul> its inotify 0.20
[02:12] <jdub> "lazy" saturday morning ;)
[02:13] <zul> heh
[02:13] <zul> so its the same that we had in -26
[02:13] <tseng> zul: you have a .11?
[02:14] <zul> nope im trying to track down an abi breakage
[02:15] <zul> jdub: nice background though for ubuntu desktop though ;)
[02:15] <mdz> tseng: yes, in universe
[02:16] <zul> but thats a pre release
[02:18] <hsprang> bye - need sleep
[02:18] <daniels> jdub: heh
[02:18] <daniels> mdz: so udu is an intermission?
[02:18] <ogra> hsprang: nacht
[02:18] <mdz> daniels: no?
[02:19] <daniels> mdz: damn.
[02:21] <daniels> wtf?  it's more expensive to fly from canberra -> sydney than either of melbourne -> canberra or sydney -> melbourne
[02:32] <schweeb> was there a kernel upgrade earlier today?  were restricted-modules properly regenerated?  my nvidia module won't load... modprobe says "Invalid module format"
[02:33] <zul> schweeb: working on it
[02:34] <schweeb> alrighty, long as someone knows
[02:34] <zul> yeah thanks
[02:39] <tseng> zul: if you get acx in ill test for you
[02:39] <tseng> zul: i can also test new ipw2200
[02:39] <tseng> probably neither for hoary
[02:39] <zul> sure..
[02:40] <zul> kernel team is just concentrating on 2.6.10 for now, but if you want to do some testing with 2.6.11.x go nuts
[02:40] <tseng> i care more about those two drivers
[02:40] <tseng> heh.
[03:01] <zenwhen> everything was working fine and I did another big upgrade. Now pages are loading slower than molasses. Am I the only person to run into this recently?
[03:03] <tseng> zenwhen: sounds like you/your isps problem really.
[03:03] <crimsun> if you rebooted between yesterday and today, possibly.
[03:03] <zenwhen> tseng, it would sound like that until I boot to windows and dont have the issue with the same nameservers
[03:04] <tseng> crimsun seems to have a clue
[03:04] <zenwhen> I was simply trying to see what was causing the issue, not place blame, but it is software.
[03:04] <zenwhen> crimsun, you have an idea?
[03:05] <crimsun> zenwhen: it is generally sluggish performance, or specifically network-related or graphics-related, etc.?
[03:06] <zenwhen> It seems that the DNS resolves, then the page waits about ten seconds to continue loading.
[03:06] <zenwhen> if I try to load the same page again, it is quick.
[03:07] <zenwhen> I am really not looking for tech support.
[03:07] <crimsun> zenwhen: nic spew in dmesg?
[03:07] <zenwhen> I am wondering if something weird is happenning to other dialup users.
[03:08] <zenwhen> nope
[03:08] <zenwhen> nothing since the PPP modules loaded
[03:08] <crimsun> don't know offhand. Not using ppp* here, however.
[03:43] <mdz> mako: around?
[04:20] <jon1012> good night everybody :)
[04:21] <toresbe> nite
[05:20] <zul> kernel is still compiling and im going to bed
[05:21] <crimsun> night zul
[05:21] <zul> night crimsun
[05:45] <Benoni> Anybody successfully using OpenAFS on hoary?
[07:54] <svenl> mdz: why your over-cautious remark on #7144 ? and do you think daniels will check it ? he is not usually available all the time, right ?
[08:00] <mdz> svenl: daniels works australian hours usually, but he is looking for a new place to live right now and so is on an odd schedule
[08:00] <mdz> svenl: I am very cautious about changing the X autodetection logic because it is critical functionality and we put a lot of effort into broad testing
[08:01] <svenl> mdz: well, have you looked at the patches ?
[08:02] <svenl> mdz: anyone literate in C will see that it has no effect unless the autodetection failed already.
[08:02] <mdz> svenl: no, but they are non-trivial, and even trivial patches have introduced bugs for us in the past.  that code is hairy.
[08:02] <svenl> mdz: please define non-trivial ? Please have a look at them.
[08:02] <mdz> svenl: there is no need to be aggressive about it.
[08:02] <mdz> none whatsoever
[08:02] <svenl> mdz: ok.
[08:02] <mdz> it will go in if daniels feels that it is safe, otherwise not
[08:02] <svenl> mdz: sorry, got burned by this whole Ethan/yaboot story.
[08:02] <mdz> we are very close to release and we _will_ be cautious
[08:03] <svenl> mdz: but how can you affirm they are none-trivial if you didn't even look at them ?
[08:03] <mdz> we are in feature freeze since one month, and this is a feature
[08:03] <svenl> mdz: the xresprobe patch for example, does :
[08:03] <svenl> 1) if we failed to find EDID in /proc/device-tree, try the same in /sys.
[08:04] <svenl> since if you fail to find EDID in /proc/device-tree, your auto-detection is broken anyway, it cannot cause problem.
[08:04] <_d4vid> hi all
[08:05] <svenl> mdz: current auto-detection is broken in the multi-head case anyway, for example if the first monitor support more modes than the second.
[08:05] <mdz> svenl: right, we don't even attempt to support multi-head at this point
[08:05] <svenl> mdz: and daniels had had a pegasos for over 4 month now.
[08:06] <svenl> mdz: yep, which is what i noticed, so the patch does exactly the same thing with the radeonfb probed edid as it would have if the /proc/device-tree edid was found.
[08:06] <svenl> mdz: works on my pegasos and my ibook.
[08:07] <svenl> mdz: and i am sure you are putting 10 times more intrusive patches in at this time.
[08:07] <mdz> svenl: it takes some time to adjust to time-based releases, but there is a groove to it
[08:08] <mdz> and a big part of it is saying "no" at the right times
[08:08] <svenl> mdz: ok, well.
[08:08] <mdz> I am not saying that this is necessarily one of those cases
[08:08] <mdz> because I haven't read the code
[08:08] <svenl> mdz: Ok.
[08:08] <mdz> but be aware that we are in that position
[08:08] <svenl> mdz: yes, i am aware of it.
[08:09] <svenl> mdz: but it is a bit strange to me how people can claim a patch is non-trivial without even looking at it.
[08:09] <mdz> svenl: it is a patch to add a feature.  we are in a release phase where we only fix bugs.
[08:09] <svenl> especially if i know it is of the kind : if (failed to work properly) { do other stuff }.
[08:10] <svenl> mdz: that is dogmatic.
[08:10] <svenl> mdz: and exactly the kind of stuff Ethan told me about yaboot, which i find despissable.
[08:10] <mdz> svenl: it is rigid and boring and it is the way that things have to be in order to get the job done
[08:11] <mdz> daniels has a list of about a hundred bugs that he has to deal with
[08:11] <mdz> and they are all higher priority than reviewing your patch
[08:11] <svenl> mdz: yes, but if you *look* at the patch, dismissing something out of hand without even looking is seriously meprising for the contributors.
[08:11] <svenl> mdz: yep, but the difference, is that i did the work, that the patches are trivial, and that it would take it at most one minute to decide on them.
[08:11] <mdz> I don't see why it should make a difference to you whether your patch is merged next week or next month
[08:11] <svenl> mdz: and i arranged for a free pegasos box for him too, but i ended doing the job.
[08:12] <svenl> mdz: ah, no.
[08:12] <mdz> even if it only takes a minute, I would rather that daniels spend that minute fixing bugs for the release
[08:12] <svenl> mdz: because i would like to have pegasos support in ubuntu, no ?
[08:12] <mdz> and apply your patch after the release
[08:12] <svenl> mdz: yep.
[08:12] <mdz> but if he has the time to do it, then I think it would be great to have better pegasos support
[08:12] <mdz> but I understand there is more to pegasos support than this patch
[08:12] <daniels> svenl: err, when I was sent the Pegasos, I explained very clearly that I could not commit to doing anything for it at all
[08:12] <daniels> svenl: which you seemed to be OK with
[08:13] <svenl> mdz: you are aware that i was told pegasos support would come after the release shortly before the warthy release.
[08:13] <mdz> daniels: morning
[08:13] <mdz> svenl: you were not told that by me
[08:13] <svenl> daniels: ok, no problem.
[08:13] <svenl> mdz: nope.
[08:13] <daniels> right now, as Matt said, I'm in the middle of looking for a house (and need one ASAP), so I really don't have much time in between 'X doesn't work at all' bugs and looking for houses
[08:13] <svenl> mdz: but i did the job for the support.
[08:13] <daniels> but yes, I think better Pegasos support is a worthwhile goal
[08:13] <daniels> mdz: g'morning
[08:13] <mdz> svenl: I appreciate that, and your patch will not be dropped on the floor
[08:13] <svenl> daniels: could you at least look at the patches and give your advice ?
[08:13] <daniels> mdz: spent most of the morning/afternoon shopping; practically bought a kitchen
[08:13] <daniels> svenl: yeah, I'm just reading my email now
[08:14] <svenl> daniels: cool.
[08:14] <svenl> daniels, mdz: sorry, i maybe over reacted, but dismissing patches as non-trivial potentially release-breaking if this is not the case, well it is really discouraging to participate at all.
[08:14] <svenl> mdz: especially if you don't even look at the patches.
[08:15] <daniels> i understand it can be discouraging -- it's just right now that all our X autodetection stuff is on a hairline trigger
[08:15] <mdz> it is a big adjustment from Debian
[08:15] <daniels> breathing on it can make it collapse
[08:15] <mdz> but there is a logic to it
[08:15] <svenl> daniels, mdz and we lose more time arguing than it would take to review those patches.
[08:15] <daniels> and I have lots and lots of bugs assigned to me where autodetection completely fails to produce the right result
[08:15] <daniels> svenl: i'll review them once offlineimap finishes
[08:15] <mdz> svenl: yes, but this argument will hopefully have long-term benefit
[08:15] <svenl> daniels: ok, that is all i ask.
[08:16] <svenl> mdz: you mean, in passing the message that it is not worthwhile to contribute to ubuntu because the patches don't even get reviewed ?
[08:16] <mdz> svenl: no, by helping you to understand our development methodology
[08:17] <svenl> mdz: don't get me wrong, i understand your position.
[08:17] <mdz> but you're starting to get hostile about it, so I think we should continue this conversation another time
[08:17] <svenl> mdz: there you pass the message that i am ignorant of it, which is not the case.
[08:17] <svenl> mdz: well, i don't feel hostile, and really don't intent to do so.
[08:18] <daniels> svenl: hm, I'm not sure that this patch works properly for all cases
[08:18] <svenl> mdz: the patches are valid, i did all the job for it, it will take daniels maybe 5 minutes to integrate them, and it adds support for a new architecture.
[08:18] <svenl> daniels: which of them ?
[08:18] <daniels> svenl: depends how the CRTCs are wired up
[08:18] <daniels> svenl: xresprobe
[08:18] <svenl> daniels: ah.
[08:19] <daniels> svenl: i don't know how radeonfb works, but if edid%d is edid data for the head on crtc %d, then it might not generally work
[08:19] <svenl> daniels: well sure, but it is no worse than the current case.
[08:19] <daniels> true
[08:19] <svenl> daniels: so it is a best case, and better handling will wait post-hoary.
[08:20] <daniels> the pcigart thing *looks* alright, but I want to run it past Michel Dnzer
[08:20] <svenl> radeon does default to clone mode, so both edid1 and edid2 should be read, and the intersection of the modes chosen, but this may (or not) be more disruptive.
[08:20] <svenl> daniels: i think he authored it, and it has been in debian since ages, and probably in 4.3.0 upstream too.
[08:20] <daniels> er, if it was in 4.3.0 upstream, then it would be in xorg upstream
[08:20] <svenl> daniels: but ask him, no problem, you are better suited for it.
[08:20] <daniels> given that <IP_ADDRESS> was merged back into the 6.6 tree to make 6.7
[08:21] <svenl> daniels: i don't know where it comes from, but it doesn't seem to be in a debian patch, not sure.
[08:21] <daniels> but yeah, I'll ask Michel about it and see if it's still good, and check out radeonfb to see if edid%d is useful
[08:21] <svenl> daniels: edid%d will look for both edid1 and edid2 ? I would rather not do that.
[08:22] <daniels> svenl: i'm just saying in the general case -- if you have something connected to crtc 2 and nothing to crtc 1, then it will fail
[08:22] <svenl> daniels: it will take the bigger of the two modes, i tested it.
[08:22] <daniels> what I'm most worried about is if we have an external display connected, and try DDC, and end up getting sync ranges and data from an externally connected monitor
[08:22] <daniels> svenl: no, what I'm saying is that edid1 may be empty and edid2 may have the real modes
[08:22] <svenl> daniels: not sure, i am not 100% sure that radeonfb doesn't report edid1 independent of where the monitor is connected. let me test it.
[08:23] <daniels> but if you have a laptop with an external display connected, and you end up writing sync ranges for a huge 21" LCD or something
[08:23] <svenl> daniels: this makes for a more intrusive patch though.
[08:23] <daniels> yeah
[08:23] <svenl> daniels: notice that in this case, the current xresprobe is also broken.
[08:24] <svenl> since we have no info on the head used, and if there are two monitors and thus two EDID's, all the modes will be used.
[08:24] <svenl> let me check with my ibook and an external monitor.
[08:24] <daniels> right
[08:26] <svenl> mmm, can't find the external monitor thingy.
[08:27] <svenl> daniels: anyway, i think the current patch is the less intrusive one, and even if it doesn't work in all cases, it will work in the current case, and don't break existing cases.
[08:28] <svenl> daniels: i think anything more complexe should wait post-hoary.
[08:32] <abelli> daniels: ping
[08:33] <daniels> abelli: sup
[08:33] <abelli> daniels: it's all right thank you :)
[08:33] <daniels> err ... ok
[08:34] <abelli> daniels: what's the main difference between nvidia-glx, and the linux-r-m ?
[08:35] <daniels> um
[08:35] <daniels> l-r-m provides the kernel module, nvidia-glx provides the xorg driver
[08:36] <abelli> so nvidia-glx has no modules in it?
[08:36] <abelli> ok, is it safe now, to upgrade from warty to hoary (i mean under xorg's perspective)?
[08:37] <daniels> seems to work fine
[08:38] <abelli> ok thank you
[08:39] <schweeb> just a sec abelli, you may not want to upgrade just this sec if you want nvidia... for me at least, the nvidia kernel module is broke... zul mentioned something about compiling a kernel before he went to sleep, but it could be a few hours till a functional nvidia module
[08:39] <crimsun> abelli: you'll want to use 'nv' instead of 'nvidia' for the time being
[08:40] <crimsun> (as schweeb mentioned)
[08:40] <schweeb> ^^^
[08:40] <abelli> crimsun: i actually use nv..
[08:40] <abelli> crimsun: that was for a friend.
[08:40] <crimsun> abelli: ok :-)
[08:41] <abelli> because, i don't know why, a dist-upgrade from hoary to warty produced bxl (to be read Big Xorg Lock)
[08:41] <abelli> xfree didnt get uninstalled, and xorg didnt get installed :)
[08:41] <abelli> but 08:39 < daniels> seems to work fine
[08:41] <abelli> ;)
[08:43] <HiddenWolf> abellli: you can't 'upgrade' from hoary to warty, warty is the older version
[08:43] <abelli> in god we trust.
[08:43] <abelli> mmmright... switch them :)
[08:54] <daniels> looks abelli forgot about ubuntu-desktop
[08:58] <HiddenWolf> daniels: bad for him
[09:14] <mdz> doko: morning
[09:18] <mdz> fabbione: morning
[09:18] <fabbione> hi mdz
[09:18] <doko> morning all
[09:18] <fabbione> hi doko
[09:32] <daniels> fabbione: oh, dude
[09:32] <daniels> fabbione: it's nothing to do with different agp modules, is it?
[09:32] <daniels> fabbione: like, if you use agpgart, it fails
[09:32] <fabbione> nope
[09:32] <daniels> has that sort of thing seen any update?
[09:32] <daniels> or drm
[09:32] <fabbione> i didn't upgrade agpart
[09:32] <daniels> drm?
[09:32] <fabbione> the changelog is 99% on the build system
[09:32] <daniels> hmmm
[09:32] <fabbione> only update is idiotify patch
[09:33] <fabbione> and it's an API change. no ABI according to them
[09:33] <mdz> idiotify :-)
[09:33] <daniels> heh
[09:34] <fabbione> i am really tired of this breakages
[09:35] <daniels> yeah, it sucks :\
[09:35] <daniels> don't envy your position
[09:36] <fabbione> i swear god if i ever gonna get back X, i will never complain again!
[09:36] <fabbione> X = EASY
[09:37] <fabbione> daniels: perhaps we can switch for a while after hoary ;)
[09:37] <fabbione> just to gimme a little break :P
[09:37] <fabbione> mdz: btw.. this is all your fault ;)
 fabbione: mind to do the <IP_ADDRESS> -> 2.6.9 transition?
 mdz: i imagine nobody is crazy enough to do that.. so yeah
[09:38] <fabbione> look now!
[09:39] <crimsun> poor fabbione. At least he's married. :-)
[09:39] <daniels> fabbione: you gave me x, suckah, i'm going to damn well keep it
[09:39] <fabbione> no that's on top that... my wife will hunt you down.. all of you!
[09:40] <fabbione> daniels: good boy ;)
[09:41] <fabbione> daniels: but that's because you are my little kitty :P
[09:42] <daniels> haha
[09:42] <daniels> so much so that I took HorizSync and VertRefresh out as the first thing I did :P
[09:42] <daniels> i'm thinking of putting them back in by default now, though
[09:43] <fabbione> let's look at the bright side of all this mess
[09:43] <fabbione> sparc is catching up on main :)
[09:43] <daniels> heh, cool
[09:43] <daniels> fabbione: ah yeah, but not always, you see
[09:44] <daniels> fabbione: don't write them out if we get sync ranges back from ddcprobe, or we're on a laptop chipset that we know isn't shit
[09:44] <daniels> fabbione: so it will still be out of the file in about 95% of cases
[09:44] <fabbione> yeah i saw your code dude
[09:44] <fabbione> i keep an eye on my pets :P
[09:44] <daniels> i remember that we had a bet of sorts about this in kbenhavn
[09:45] <daniels> i guess this means you win, then :)
[09:45] <daniels> to some degree
[09:45] <fabbione> i can't lose :)
[09:45] <daniels> haha
[09:45] <fabbione> hmmm eel2 is doomed
[09:45] <fabbione> where is seb?
[09:45] <fabbione>  bin/sed: can't read /usr/lib/libhowl.la: No such file or directory
[09:46] <fabbione> we must rebuild the archive asap to see if everything is ok
[09:46] <fabbione> i am off.. later fellas
[09:46] <crimsun> cya
[09:47] <daniels> seeya dude
[09:49] <kagou> hi
[10:06] <svenl> daniels: BTW, after thinking about it, for a laptop with an external monitor, in clone mode, the code i submitted will use the first head only, which will be the panel.
[10:06] <daniels> svenl: you're assuming the panel exports edid, which it generally doesn't
[10:06] <daniels> also, the panel isn't always hooked up to the first crtc
[10:06] <svenl> daniels: ah ...
[10:06] <daniels> the laptop i'm sitting on now has the panel off the secondary display path
[10:06] <svenl> daniels: i don't know, my ibook does have a EDID and edid1 in both places.
[10:07] <svenl> daniels: my code is enabled for powerpc only, and of.c is linked in on powerpc only though.
[10:07] <daniels> svenl: yes, but iirc powerbook panels don't export edid
[10:07] <svenl> daniels: ah.
[10:07] <daniels> svenl: (i think the difference was that the ones with nvidia chips export edid, radeons don't)
[10:07] <daniels> the radeon lvds code is very clean
[10:07] <daniels> nvidia's is ... not
[10:07] <svenl> daniels: you have a powerbook ? which graphic card ?
[10:09] <daniels> svenl: i don't have one, no, but there have been a lot of bug reports since ... last june, i think it was
[10:09] <svenl> daniels: mmm, ...
[10:11] <svenl> daniels: in any case, it would be possible for those powerbooks to be fixed by the radeonfb/sys thingy, but we need to find out what they do have ? edid1 or edid2.
[10:11] <svenl> maybe they simply don't have anything though, will need to ask benh about this case.
[10:11] <daniels> errr ... no
[10:11] <daniels> see, the way panels generally work is that you have a table in the bios with the panel's mode information
[10:11] <daniels> the lvds tables
[10:12] <svenl> daniels: in any case, the current patch should have no influence on those.
[10:12] <daniels> the panels will not respond to ddc queries
[10:12] <daniels> this is the entire reason why we only run ddcprobe sometimes, and we run Xorg and grep the log other times
[10:12] <svenl> daniels: but radeonfb is better placed than the EDID code to do its own mode setup and such.
[10:12] <daniels> because we can't get DDC all the time, so we have to let Xorg read the tables out of the BIOS
[10:12] <svenl> daniels: maybe we could get the info out of dmesg even, not sure.
[10:12] <daniels> err, yeah, I'm not disputing that
[10:13] <daniels> all we really need is the panel size, in which case we fork Xorg and grep the log
[10:13] <daniels> see xprobe.sh and lcdsize.sh
[10:13] <svenl> daniels: anyway, the patch i submitted should have no influence on that, and for hoary+1 chances are good that fbdev/fbmon will provide infrastructure for querying this kind of info.
[10:14] <dholbach> good morning
[10:14] <svenl> daniels: i will ask benh (who did the powerpc radeonfb stuff lately), if he knows of a way to get said info from radeonfb in 2.6.10.
[10:14] <daniels> svenl: yeah, but that's irrelevant for i386/amd64 anyway
[10:14] <daniels> configuring framebuffers by default is a nightmare I'd rather avoid
[10:15] <daniels> svenl: right, but I think you'll find that the LVDS info is not exported via EDID
[10:15] <svenl> daniels: euh. yeah, ok, guess i don't really care about non-powerpc and all my patches should not apply on non-x86, since they are #ifdef __powerpc_ed.
[10:16] <svenl> daniels: yes, altough radeonfb could fake an edid1 with the lvds table or something, or provide the data in some other way.
[10:16] <svenl> daniels: i think benh mentioned something such.
[10:16] <daniels> svenl: ideally there'd be a driver-independent interface that xorg, fbdev and dri use that we can hook into
[10:16] <daniels> svenl: but that's like hoary+9
[10:16] <svenl> daniels: not sure.
[10:16] <daniels> svenl: (well, that's the plan upstream, but it's going to take ages)
[10:17] <daniels> we like it, the kernel guys like it
[10:17] <svenl> daniels: it would be easy enough to simply use the fbdev facility, we place usefbdev option anyway.
[10:17] <daniels> on powerpc, yes
[10:17] <svenl> daniels: i like it too.
[10:17] <svenl> daniels: ah ..
[10:18] <svenl> daniels: anyway, are we agreed that the current patch is ok for now, doesn't break existing supported cases, and we can have this discussion with more time post-hoary ?
[10:18] <daniels> svenl: it *looks* ok to me -- i will check further, but on initial inspection it doesn't look too badly
[10:18] <svenl> daniels: if the panel doesn't export EDID, then radeonfb doesn't export edid1 too, i think.
[10:20] <daniels> ok, but we fork Xorg for laptops anyway and grep the log
[10:20] <svenl> daniels: the real worry is if the powerpc laptop doesn't provide edid, that a monitor is connected externally, and that radeonfb provides an edid1 for the external monitor.
[10:20] <daniels> so that doesn't matter
[10:20] <svenl> ah, ok.
[10:20] <daniels> right.  that's why we fork Xorg first
[10:20] <svenl> ok.
[10:20] <svenl> so no need for me to investigate this ?
[10:20] <jdub> YokoZar: replied to your mail on u-d
[10:20] <daniels> no, just needs me to integrate it, thankyou
[10:20] <jdub> YokoZar: hope that helps :)
[10:20] <daniels> jdub: so, like, dbus 0.23.4 for hoary?
[10:20] <svenl> BTW, can you apply the pcigart fallback to some tree you have, and build the radeon module, and make it available in the bug report for testing ?
[10:21] <YokoZar> jdub: thansk
[10:21] <YokoZar> Thanks, even.
[10:21] <jdub> daniels: was that ABI/API change dealt with upstream?
[10:21] <daniels> jdub: not really, no
[10:21] <jdub> daniels: can we get that upstream, and do we have a good list of the fixage between releases?
[10:21] <daniels> jdub: but if it comes down to beagle vs !beagle for hoary, i can patch the affected apps (which are few)
[10:21] <daniels> jdub: i've kicked upstream in the testicles for that one
[10:22] <daniels> 0.23.x fixage is just fixing a hojillion memory leaks (one that made your app use a few hundred mb in half an hour) and a couple of lockups, mainly in interactions with mono
[10:22] <daniels> but yeah, upstream are unrepentant and won't commit to a stable api :\
[10:22] <daniels> brb
[10:22] <jdub> :-)
[10:22] <jdub> daniels: you seen that hal-d-m doesn't run?
[10:22] <svenl> ok, need to go, see you later.
[10:27] <daniels> jdub: it can be patched away
[10:27] <daniels> jdub: my argument was that if you're going to change dbus_pending_call_get_reply to dbus_pending_get_steal_reply and change the semantics, just keep the old function around and mark it deprecated
[10:27] <daniels> then remove it all in one great hit
[10:27] <daniels> and i mentioned soversions
[10:28] <daniels> this had the unfortunate effect of possibly placing us in a gal-esque situation
[10:28] <YokoZar> jdub: reply sent
[10:29] <jdub> daniels: yeah
[10:41] <fabbione> hey jdub
[10:41] <fabbione> jdub: isn't about time you add some README or documentation to flumotion?
[10:42] <fabbione> btw.. it hangs on me
[10:43] <dholbach> elmo: could you please, when you're back sync  mondo  and  mindi  from sid?
[10:51] <fabbione> daniels: did you ever installed your sparc?
[10:52] <daniels> fabbione: not yet, I'm afraid
[10:52] <fabbione> daniels: i still have problems using xvfb-run on sparc
[10:52] <fabbione> it doesn't work as normal user in certain cases
[10:52] <fabbione> nothing extremely important for hoary
[10:52] <daniels> hmmmm, bloody hell
[10:52] <fabbione> it's one package in main that needs manual love
[10:53] <daniels> doesn't that fail pyopengl's build?
[10:53] <fabbione> yes
[10:54] <fabbione> this is frigging annoying.. my new webcam adds a new audio device
[10:54] <fabbione> and it renumbered all the other cards
[10:54] <fabbione> and xine refuses to see the correct one
[10:54] <fabbione> oh btw
[10:55] <fabbione> that xinemara problem seems isolated to mplayer
[10:55] <fabbione> all the other players look ok
[10:55] <fabbione> i will try later to see if it is only a missing build-dep somewhere
[10:56] <daniels> weird
[10:56] <daniels> yeah, it's probably a b-d thing
[10:56] <daniels> anyway, I need to get some more sleep in
[10:56] <daniels> on the couch, since my bed makes my back ache, heh
[10:57] <Seveas> daniels, try a waterbed
[10:57] <daniels> Seveas: i'm getting a new bed soon
[10:58] <Kamion> svenl: OF upgrade seemed to work (although unfortunately I wasn't looking at the screen when the flash program finished, so I'm not 100% certain; looked back and it was back at the OF prompt with variables reset), so I'm re-burning a CD image with modified yaboot
[10:58] <fabbione> hey Kamion
[10:58] <fabbione> Kamion: did you manage to build a new DVD image?
[10:59] <fabbione> (after preview i mean)
[10:59] <fabbione> i got my DVD burner back yesterday and i can test during the weekend
[11:00] <Kamion> fabbione: one should build today
[11:00] <fabbione> rocking
[11:00] <Kamion> didn't seem any particular hurry to preempt it :)
[11:00] <Kamion> you do want today's build, since it has hopefully-fixed archive-copier
[11:01] <fabbione> yes.. i recall that :)
[11:02] <Kamion> fabbione: expect it to be available around 13:15 UTC or a little afterwards
[11:04] <fabbione> Kamion: no rush. i need to unfuck the kernel first anyway
[11:04] <jdub> fabbione: new packages on their way to universe soon are nicely split out and stuff
[11:05] <fabbione> jdub: good.. but please add documentation too
[11:05] <jdub> fabbione: thus far, the flumotion docs have not had a tarball release; i might have to package them anyway
[11:05] <fabbione> usr/share/doc empty is the SUCKS
[11:05] <mdz> Kamion: LANG=foo should be sufficient for #7138, right?
[11:05] <fabbione> jdub: the README file as a starter is perfect
[11:05] <mdz> no need to mess with any other locale settings?
[11:06] <fabbione> jdub: the main issue for me is that it hangs when reading from my webcam
[11:06] <fabbione> xawtv can read from it without any problem
[11:06] <fabbione> flumotion can't
[11:06] <jdub> hmm
[11:06] <fabbione> brb
[11:08] <Kamion> mdz: yes. what I was thinking was that it'd be best if casper got debian-installer/locale just before pivoting, and export LANG="whatever it got" immediately after pivoting; then you'd only have to do it in one place
[11:08] <mdz> that's what I've just done
[11:08] <Kamion> ideal then
[11:12] <mdz> Kamion: any other environment variables which deserve the same treatment, while I'm there?
[11:13] <fabbione> re
[11:14] <daniels> mdz: for 7138, all I need is LANG
[11:14] <Kamion> LANG's the only one I can think of
[11:14] <Kamion> note to self: when burning CDs, it helps if you put the CD into the correct drive
[11:15] <Kamion> what happened to the live CDs? they're taking ages to rsync today
[11:15] <fabbione> lol
[11:15] <fabbione> Kamion: winfoss?
[11:16] <Kamion> not for powerpc
[11:16] <HiddenWolf> ugh, I just realised hoary shuts down so fast that it clips off the shutdown sound before it's done playing. :S
[11:16] <sabdfl> morning guys
[11:16] <Kamion> jdub: "brill"? what decade do you live in? :-)
[11:16] <fabbione> hey sabdfl
[11:16] <dholbach> hi mark
[11:16] <sabdfl> installer tests... lots of problems today?
[11:16] <jdub> Kamion: ha ha
[11:17] <Kamion> sabdfl: hmm?
[11:17] <daniels> Kamion: as opposed to 'rad'
[11:17] <Kamion> I said "brill" when I was five
[11:17] <daniels> Kamion: jdub is still five
[11:17] <Kamion> good point
[11:17] <sabdfl> we're trying to install hoary on a laptop for my new PA.
[11:17] <sabdfl> last night, jane was getting a debootstrap error, "can't find ..."
[11:18] <jdub> i have moments of youthful exhuberance :-)
[11:18] <sabdfl> today i just burned a new install daily
[11:18] <sabdfl> and it's not seeing my network cards
[11:18] <sabdfl> on an IBM T42
[11:18] <sabdfl> !
[11:18] <sabdfl> ?
[11:18] <sabdfl> jdub: gnarly
[11:18] <Kamion> sabdfl: that debootstrap error is typically a symptom of a bad burn
[11:18] <sabdfl> ok
[11:18] <mdz> as Kamion said
[11:18] <sabdfl> and... this mornings network error?
[11:18] <Kamion> sabdfl: the kernel module ABI got screwed yesterday
[11:18] <fabbione> sabdfl: working on it already
[11:18] <mdz> not seeing your network card is probably the kernel ABI skew
[11:19] <sabdfl> oh, that's alreight then :-)
[11:19] <Kamion> the kernel/initrd and the udebs are almost certainly out of step
[11:19] <fabbione> mdz: i think the simples way is to make 27 = 25.2
[11:19] <fabbione> mdz: and 28 with the new ABI
[11:19] <Kamion> fabbione: please include the #1440 fix in 27
[11:20] <mdz> fabbione: fine with me
[11:20] <Kamion> having it alternately progress and regress is confusing bug reporters
[11:20] <fabbione> Kamion: yes. that was the idea
[11:20] <Kamion> 25.2 did not have the #1440 fix
[11:20] <Kamion> but if you mean to roll back the inotify patch in 27, sure :)
[11:20] <sabdfl> fabbione: i need to get this laptop sorted for jane & claire today, will there be a new installer today to test with?
[11:21] <Kamion> sabdfl: just use yesterday's image
[11:21] <sabdfl> Kamion: 'k
[11:21] <fabbione> sabdfl: it will take not less than 3 hours for the changes to propagate
[11:21] <fabbione> sabdfl: nothing i can do faster
[11:21] <Kamion> the kernel build will take a while, then it would take an installer byhand from elmo, and then new CDs will have to be rolled; all this while I'm in London ;)
[11:21] <jdub> Get:64 http://archive.ubuntu.com hoary/universe libxslt1-python2.4 1.1.12-3ubuntu3 [686B]
[11:21] <Kamion> (leaving in ~1hr)
[11:22] <fabbione> sabdfl:     - CONFIG_CRC32=y on all arches.
[11:22] <fabbione> ops
[11:22] <fabbione> s/sadbfl//
[11:23] <jdub> oh, libxslt1, not libxslt1.1
[11:23] <mdz> fabbione: why?
[11:23] <fabbione> i wonder if this could have caused the ABI change
[11:23] <sabdfl> fabbione: np
[11:23] <fabbione> mdz: config allignment
[11:23] <fabbione> mdz: it was giving some problems at udeb levels since it is a shared module between fb and net
[11:24] <Kamion> the hack-solution Debian applied for that was to put crc32.ko in the kernel-image udeb
[11:24] <mdz> fabbione: for hoary+1 I would like to explore building fewer kernels on i386
[11:24] <sabdfl> Kamion: btw we are updating the ubuntu logo slightly (text blue -> black), i'll file a reminder bug for you to get a new isosplash from jdub / cliff
[11:24] <Kamion> since both fb-modules and nic-*-modules depend on kernel-image
[11:24] <Kamion> sabdfl: ok, no problem
[11:25] <Kamion> but certainly building it in seems a sensible option
[11:25] <fabbione> mdz: fewer? they are only 5...
[11:25] <mdz> fabbione: "only"
[11:25] <fabbione> amd64 builds 4, sparc 2, hppa 4, powerpc unlimited....
[11:26] <mdz> hppa and sparc are irrelevant, powerpc are actually different subarches
[11:26] <fabbione> so it's in the average
[11:26] <fabbione> mdz: yes.. but they still get builded
[11:26] <fabbione> ia64 4
[11:26] <fabbione> so i mean.. it's there with the others
[11:26] <mdz> fabbione: hppa and sparc don't delay releases
[11:26] <fabbione> neither does ia64
[11:26] <mdz> powerpc and i386 do
[11:27] <Kamion> svenl: hm, the /etc/yaboot.conf -> ../install/yaboot.conf symlink doesn't seem to work
[11:27] <fabbione> ok.. than i would say we roll back to 25.1
[11:27] <fabbione> and we apply the debian fix to the crc32 thingy
[11:27] <daniels> the other workaround would be to buy concordia, only with 12GB of RAM, run it in 32-bit mode, and build on a ramdisk
[11:27] <Kamion> svenl: "Config file error: Token is too long near line 0 in file /etc/yaboot.conf"
[11:27] <fabbione> that should do
[11:28] <daniels> or tmpfs or whatever's fashionable these days
[11:28] <Kamion> fabbione: why not just change ABI now?
[11:28] <Kamion> if we're going to do it anyway ...
[11:28] <mdz> daniels: the kernel builds use CONCURRENCY_LEVEL now; that should cut the build time in half
[11:28] <Kamion> mdz: according to elmo, it makes it worse
[11:28] <daniels> fabbione: i'll deal with lrm for the new abi if you give me a reminder when you upload it
[11:28] <mdz> Kamion: because it'd be nice to un-screw the users we just screwed by breaking it
[11:28] <mdz> Kamion: ??
[11:28] <Kamion> true
[11:29] <mdz> worse?
[11:29] <fabbione> no
[11:29] <mdz> I've used CONCURRENCY_LEVEL many times in the past with positive results
[11:29] <fabbione> it's not worste
[11:29] <fabbione> please do not confuse stuff
[11:29] <fabbione> the last kernel invalidated the ccache
[11:29] <Kamion> 13:21 < elmo> fabbione: I don't think that was such a good plan
[11:29] <Kamion> 13:22 < elmo> Build needed 01:05:48, 1425648k disk space
[11:29] <Kamion> 13:22 < elmo> Build needed 00:38:47, 1428100k disk space
[11:29] <Kamion> 13:22 < elmo> first is -26, second is -25.2 .  on amd64, same buildd host
[11:29] <fabbione> that's why it took longer
[11:29] <Kamion> oh, ok
[11:30] <Mithrandir> lamont: (6438); not yet, I got distracted by a shiny new WRT54GS last night, so I didn't finish OOo/ia64
[11:30] <fabbione> you should compare with a version that did invalidate the cache too
[11:30] <mdz> why would it invalidate ccache?
[11:30] <Kamion> new config?
[11:30] <mdz> ccache doesn't seem to be implemented correctly yet anyway
[11:30] <sabdfl> Kamion, jdub: https://bugzilla.ubuntu.com/show_bug.cgi?id=7514
[11:30] <fabbione> mdz: because of the new inotify patch
[11:30] <fabbione> they claim that the ABI was intact
[11:30] <mdz> fabbione: why would that invalidate ccache?
[11:30] <fabbione> but apparently it wasn't
[11:30] <fabbione> because it changes one include file in fs/
[11:30] <daniels> mdz: touch a core header, watch your cache die
[11:30] <fabbione> that means basically rebuilding 3/4 of the kernel
[11:31] <crimsun> fabbione: confirmed that reverting inotify 0.20 -> 0.18 (16 and 15-optional + enable-inotify) allows l-r-m to work.
[11:31] <crimsun> fabbione: just spent the past hour building and testing.
[11:31] <fabbione> crimsun: ah good
[11:31] <fabbione> dilinger: you around?
[11:32] <fabbione> afaik changing one module from M to Y should NOT break the ABI
[11:32] <fabbione> and we saw it with the DRM stuff a while back
[11:32] <fabbione> so if that's the problem we can just revert the idiotify patch
[11:33] <crimsun> fabbione: I left CONFIG_CRC32=y
[11:33] <daniels> the drm stuff wasn't changing from M->Y
[11:33] <crimsun> so that change is orthogonal
[11:33] <mdz> fabbione: bobmitch claims on ubuntu-devel that firmware for acx100 is missing?
[11:33] <crimsun> it's purely the inotify 0.20 stuff
[11:33] <daniels> it was that DRM got reorganised so that all the drivers used core functions, which were built into the kernel
[11:33] <daniels> and fglrx and drm-core just hated each other
[11:33] <mdz> fabbione: adding or removing any symbols changes the ABI, AIUI
[11:33] <daniels> mdz: they're in lrm
[11:34] <mdz> potpal:[~]  dpkg -L linux-restricted-modules-`uname -r` | grep acx
[11:34] <mdz> zsh: done       dpkg -L linux-restricted-modules-`uname -r` |
[11:34] <mdz> zsh: exit 1     grep acx
[11:34] <mdz> daniels: ^^
[11:34] <daniels> they're not called acx
[11:34] <fabbione> mdz: that is weird.. we didn't touch the acx stuff for a long while
[11:34] <mdke> :(
[11:34] <daniels> daniels@catsby:~/canonical/kernel/l-r-m/<IP_ADDRESS>/linux-restricted-modules-2.6.10-<IP_ADDRESS>/acx100% ls
[11:35] <fabbione> daniels: you have an acx.. can you check?
[11:35] <daniels> RADIO0d.BIN  RADIO11.BIN  RADIO15.BIN  TIACX111.BIN  WLANGEN.BIN
[11:35] <mdke> i have acx
[11:35] <mdke> can i help?
[11:35] <daniels> fabbione: it's not in my amd64 right now, but I don't see how it would be broken
[11:35] <mdz> daniels: please follow up on ubuntu-devel;
[11:35] <daniels> i can check on the other side of sleep though
[11:35] <daniels> mdz: wlil do
[11:35] <daniels> alright, off now, later
[11:35] <Kamion> surely the module is just broken for the same reason every other module is broken at the moment
[11:35] <mdz> daniels: he says it was a fresh array 6 install
[11:35] <Kamion> i.e. the ABI change
[11:35] <mdz> Kamion: the base-installer kernel issue was fixed before or after array 6?
[11:36] <Kamion> I think after, checking
[11:36] <mdz> daniels: if it was fixed after array 6, the answer is probably "use preview"
[11:36] <Kamion> or "install linux-386"
[11:36] <crimsun> really, it's solely inotify 0.20's fault.
[11:36] <Kamion>  -- Colin Watson<EMAIL_ADDRESS>Mon,  7 Mar 2005 13:11:31 +0000
[11:36] <Kamion> Array CD 6 was 3 March
[11:38] <mdz> thanks
[11:39] <fabbione> ok.. inotify is reverted.. anything else?
[11:40] <fabbione> mdz: the acx stuff is known to work.. otherwise daniels won't be here irciing...
[11:40] <Kamion> at some point I must send you a BusLogic hotpluggification patch, but not now
[11:40] <fabbione> Kamion: just send it.. i will queue it up for -28
[11:40] <Kamion> I don't have it yet, hence "not now" ;)
[11:41] <fabbione> mdz: ?
[11:41] <mdz> fabbione: ?
[11:41] <fabbione> anything else for 27?
[11:41] <mdz> fix all known boot failures? ;-)
[11:41] <fabbione> mdke: does the acx100 driver work for you?
[11:41] <mdke> yes
[11:42] <mdz> all the other major kernel bugs too if you have time
[11:42] <mdke> fabbione, i copied my firmware over from cd
[11:42] <mdke> fabbione, although it goes down fairly frequently
[11:42] <mdke> but it works
[11:42] <smurfix> Anybody know where mako has misplaced himself? We were supposed to have a meeting at 10:00 UTC
[11:42] <mdz> smurfix: it's before 0600 in mako-land, so I imagine he's misplaced himself in bed
[11:42] <fabbione> mdz: i would like to unbreak the ABI in 27 and work immediatly on 28
[11:42] <mdz> fabbione: sounds good
[11:43] <fabbione> mdz: i have a few tons of security updates to push in
[11:43] <fabbione> that as usual MIGHT break the ABI
[11:43] <fabbione> so 28 is a perfect kernel
[11:43] <smurfix> mdz: he shouldn't have agreed to that time then :-/
[11:44] <mdz> smurfix: perhaps he overslept
[11:45] <smurfix> mdz: He's been offline for the last 10.5 hours, that should be enough sleep :-p
[11:45] <mdz> smurfix: I slept for 11 hours last night
[11:46] <mdke> mmmm
[11:46] <fabbione> i think he also has a life :)
[11:46] <sabdfl> mdz: welcome back to the world of the living :-)
[11:46] <sabdfl> oww
[11:46] <smurfix> fabbione: if he agrees to a meeting time he's not supposed to have one in the meantime ;-)
[11:46] <mdz> bringing me to an average of about 5 hours/night for the past 3 ;-)
[11:46] <sabdfl> kamion: if it's tricky, don't stress for hoary, but if possible please https://bugzilla.ubuntu.com/show_bug.cgi?id=7515
[11:46] <sabdfl> mdz: don't push it, ok
[11:46] <smurfix> mdz: Ouch.
[11:47] <fabbione> sabdfl: on topic of installer questions...
[11:47] <mdz> sabdfl: without major surgery, those questions must be asked after the base system is installed
[11:47] <fabbione> choose-mirror and apt preseeding
[11:48] <fabbione> (at least on netinstall)
[11:48] <sabdfl> fabbione: so with the new bustificated kernel, will network also fail on a normal boot if i update to todays versions?
[11:48] <sabdfl> fabbione: you want those asked, or not asked?
[11:48] <fabbione> it would be very nice to let choose-mirror to ask the question and preseed apt..
[11:48] <mdz> sabdfl: taking it easy is occasionally incompatible with meeting release targets, unfortunately
[11:48] <fabbione> instead of lettign choose-mirror download from archive
[11:48] <fabbione> and ask later
[11:48] <sabdfl> mdz: you're preaching to the choir :-)
[11:49] <mdz> I'm easy like sunday morning
[11:49] <fabbione> sabdfl: it might fail. problem is that i can't reproduce the problem here.. not even with nvidia
[11:50] <mdz> sabdfl: if your network device requires a driver from linux-restricted-modules, it's entirely likely that it will fail
[11:50] <smurfix> Duh? I just updated and locales.postinst is rebuilding every locale *twice*
[11:50] <mdz> smurfix: Kamion touched it last! ;-)
[11:50] <Kamion> sabdfl: it's hard; the implementation of those questions fundamentally relies on having the base system installed
[11:52] <mdz> jdub: thanks for the followup on the wine issue
[11:52] <jdub> mdz: turned out well
[11:52] <Kamion> sabdfl: mm, I agree that choose-mirror really should ask its mirror question; it's not on the default CD install path
[11:53] <Kamion> ah, mdz already said what I said about the base system installation :)
[11:53] <fabbione> also because it's lame to download from archive.u.c and than ask what mirror to use
[11:53] <Kamion> nowadays we do at least default to CC.archive.ubuntu.com there, but still
[11:54] <fabbione> i spend heaps of time downloading from archive each time i need to do a test install
[11:54] <mdz> how many CC.ubuntu.com point to non-canonical mirrors?
[11:54] <fabbione> i can imagine admins with local mirrors
[11:54] <mdz> s/canonical/Canonical/
[11:57] <sabdfl> mdz: i doubt a T42 needs restricted modules... does it?
[11:57] <mdz> sabdfl: the T42 is available with 3 different wireless cards
[11:57] <mdz> one of them is atheros-based, which requires l-r-m
[11:57] <mdz> one is centrino/intel, which doesn't
[11:57] <mdz> I forget what the other is
[11:58] <fabbione> 27 is on the way to incoming
[11:58] <sabdfl> installed an older image
[11:58] <sabdfl> mdz: uses ipw2200 and e1000
[11:58] <mdz> sabdfl: just like my T42, then
[11:58] <mdz> sabdfl: in which case I guarantee that preview works out of the box ;-)
[11:59] <sabdfl> fabbione: are we rolling with the latest ipw* drivers?
[11:59] <fabbione> sabdfl: almost...
[11:59] <mdz> sabdfl: not latest, no.  we stopped blindly pulling code from upstream some time ago
[11:59] <mdz> we ship with the December 20th version of ipw2200
[11:59] <sabdfl> ok
[11:59] <Kamion> sabdfl: so, any other Ubuntu logo changes, or just the colour? if it's just the colour I can probably gimp it up myself
[12:00] <mdz> we made a pass over all the third-party drivers before upstreamversionfreeze and updated them
[12:00] <fabbione> the only exception was inotify in the attempt to get it working
[12:00] <fabbione> but it has been giving more problems than anything else
[12:01] <jdub> Kamion: it'll be a full image change
[12:01] <fabbione> there.. kernel is ACCEPTED and before cron.daily
[12:01] <jdub> Kamion: to match or complement the splash screen
[12:02] <mdz> fabbione: we need to invent the hoary dance for UDU
[12:02] <Kamion> jdub: oh, that's not what I gathered from #7514
[12:02] <fabbione> mdz: agreed...
[12:03] <jdub> Kamion: the logo change will be part of it
[12:03] <fabbione> mdz: YMCA? ;)
[12:03] <jdub> Kamion: but it will be a more general change
[12:03] <Kamion> 'k
[12:03] <Kamion> I need this a week before release
[12:03] <Kamion> preferably a bit earlier, so that the release candidate has a better chance of being final
[12:04] <fabbione> Kamion, mdz: 28 will be up not before the 16
[12:04] <fabbione> and it will change the ABI
[12:05] <fabbione> are we ok for this?
[12:05] <fabbione> or do you want me to delay?
[12:05] <mdz> fabbione: it is guaranteed to change the ABI?
[12:05] <fabbione> mdz: it did in 26... so yes
[12:05] <mdz> RC is the 30th
[12:05] <fabbione> mdz: i can't disclose before the 16
[12:06] <mdz> fabbione: I do not understand why we should cause these headaches for the sake of inotify
[12:06] <fabbione> you know the drill
[12:06] <mdz> which is disabled per default
[12:06] <fabbione> mdz: because the last one works way better than the previous one
[12:06] <mdz> wouldn't it be better to suspend inotify updates until hoary+1
[12:06] <mdz> ?
[12:06] <fabbione> mdz: ok for me
[12:06] <mdz> it may work better, but we have already decided not to use it for Hoary
[12:07] <mdz> fabbione: perhaps even...bendy?
[12:07] <fabbione> ahaha
[12:07] <fabbione> bendy +++
[12:09] <fabbione> i relly can't wait for UDU :)
[12:09] <fabbione> our meetings are so much fun
[12:10] <smurfix> Anybody going to linux.conf.au before UDU?
[12:10] <dholbach> hi mvo
[12:10] <fabbione> not me...
[12:10] <mdz> smurfix: yes, several of us
[12:10] <mvo> hey dholbach
[12:10] <mvo> hi all
[12:10] <smurfix> to, even
[12:11] <thom> morning
[12:11] <fabbione> sabdfl: at linux conf.au you need to get me a Linus signature with something on the line as: "To Fabbione.. that poor kernel maintainer" ;)
[12:12] <thom> mdz: firefox?
[12:12] <fabbione> hey thom
[12:12] <mdz> thom: foxfire?
[12:13] <mdz> fabbione: I thought Linus was not attending this time
[12:13] <fabbione> no idea....
[12:13] <fabbione> hounestly
[12:13] <fabbione> smurfix: is keymapper your toy?
[12:13] <thom> mdz: SU 47d
[12:13] <thom> mdz: but let's not talk about russian fighter jets ;-)
[12:14] <mdz> mozilla-foxbat
[12:14] <dholbach> can somebody make me feel less uneasy about  http://wiki.ubuntu.com/UniverseUnmetDeps ? i know there are some things based on non-free or amd64 issues, but still...
[12:15] <smurfix> fabbione: Yeah
[12:15] <thom> mdz: i'm sure MiG have copyrights on the name ;-)
[12:15] <Kamion> dholbach: compare it with http://ftp-master.debian.org/testing/unstable_probs.html and contemplate what an easy time you have by comparison
[12:16] <fabbione> smurfix: keymapper builds fine but console-data will fail on sparc with this message: make: *** No rule to make target `decision-tree-sparc', needed by `decision-tree'.   Likely cause: Bad deb package
[12:17] <mdz> a keenly intuitive diagnosis
[12:17] <thom> mdz: but yeah, you pinged last night about the 1.0.1 upload?
[12:17] <fabbione> smurfix: ok
[12:18] <smurfix> fabbione: There's a gen_keymap there which needs to be fed a list of keyboards likely to be connected to a Sparc box
[12:18] <fabbione> smurfix: ok...
[12:19] <dholbach> is everyone ok with a wiki page   MorgueCandidates  ?
[12:20] <Kamion> svenl: so, turning on yaboot debug suggests that booting yaboot on the Pegasos with the OF update is then trying to of_open "/pci@80000000/ide@C,1/cdrom@1,0:\etc\yaboot.conf"
[12:26] <GheRivero> res
[12:27] <mdz> thom: yes
[12:27] <Kamion> svenl: but doing "boot /pci@80000000/ide@C,1/cdrom@1,0:\install\yaboot" at least starts up yaboot fine (although I get the same config file error)
[12:27] <mdz> dholbach: what would be the content of this page?
[12:27] <Kamion> svenl: so I think the path is correct
[12:28] <dholbach> mdz: packages we don't want to support any more, which don't make no sense and should be blocked from auto-syncs from debian
[12:29] <Kamion> svenl: yaboot apparently passes part=NULL to of_open here, so I'm not sure why the is_not_iso thing is needed?
[12:29] <YokoZar> When I take a desktop screenshot, and save it to desktop (as default), it didn't show up until I opened the desktop folder in nautilus and hit refresh
[12:29] <mdz> dholbach: candidates for removal, then?
[12:29] <dholbach> mdz: the page would be a place to discuss those packages
[12:29] <YokoZar> Is this something weird I did?  Or is it something weird gnome is doing?
[12:30] <dholbach> mdz: i'm going throught the list, but vdk would be such a case (we have vdk2 and it isnt installable anymore), kudzu (in my eyes, because users complained about broken configuration after the use of it)
[12:30] <thom> mdz: i'm gonna nail down a bunch more bugs before i upload; prolly the middle of the week or so now i have popcon more or less fixed up
[12:30] <dholbach> mdz: that's all i have in mind atm
[12:31] <dholbach> mdz: i think it's good to have a discussion place for those and an institution for that, since universe is... well packed with weird stuff :-)
[12:37] <mdz> dholbach: sounds reasonable
[12:38] <dholbach> mdz: https://www.ubuntulinux.org/wiki/MorgueCandidates
[12:40] <dholbach> mdz: perhaps it could be an item on each of the TB's meetings (correct me, if this is the wrong place for it), so elmo could act after the decisions made then
[12:42] <dholbach> generally users should have the choice, but _a bit_ of a best-of-breed--approach would be a nice thing to focus on
[12:45] <HiddenWolf> Failed to run /usr/sbin/synaptic as user root:
[12:45] <HiddenWolf>  Child terminated with 249 status -> :S
[12:46] <fabbione> Build needed 00:22:01, 1425712k disk space
[12:46] <fabbione> this is on amd64 with ccache :-)
[12:46] <fabbione> (kernel build time btw)
[12:47] <fabbione> almost 50% less than before
[12:47] <Mithrandir> fabbione: nicey
[12:47] <fabbione> told ya
[12:47] <mvo> HiddenWolf: it looks like a message from gksudo that we really should patch out.
[12:48] <HiddenWolf> mvo: just filed a bug about it for synaptic, feel free to solve it ;)
[12:49] <mvo> HiddenWolf: one more for my ever growing list ...
[12:49] <mvo> HiddenWolf: thanks :)
[12:49] <mdz> night all
[12:49] <thom> night mdz
[12:49] <mvo> night mdz
[12:49] <fabbione> night mdz
[12:49] <dholbach> bye mdz
[12:49] <thom> Kamion: cya later
[12:51] <HiddenWolf> mvo: Relax. ;)
[12:52] <svenl> Kamion: yeah, i know, this is the same thing i discovered.
[12:52] <svenl> Kamion: the problem is that the boot command does a "load" while yaboot does only a "read".
[12:52] <svenl> Kamion: and currently the "read" command bypass the filesystem/partition table detection code, and does a plain read.
[12:53] <svenl> Kamion: need to fix that, but time was short.
[01:01] <Kamion> svenl: ok
[01:01] <zul> morning
[01:02] <Mithrandir> sabdfl: btw, I'm hoping to have a look at the ooo2 feasability this weekend.  There were some conflicting build-deps, but seb sorted that out.
[01:06] <fabbione> yay
[01:06] <fabbione> 46 minutes for i386 to build
[01:06] <fabbione> that is good considering it munges arch: all
[01:06] <fabbione> still much better than 1 hour and 30 on my -j15 distcc cluster with only arch: any
[01:08] <Mithrandir> elmo: could you please un-pas tvtime?  I have no idea why it's marked as "i386 (wine) specific"
[01:08] <Mithrandir> elmo: it does at least build on amd64
[01:27] <trukulo> hi ppl
[01:27] <Riddell> how do I change the widget style used by gnome?
[01:28] <trukulo> Riddell, you are asking how to change the widget on ubuntu-devel? ask it on #ubuntu please
[01:28] <Riddell> this is for development purposes
[01:28] <trukulo> ah
[01:29] <trukulo> so : System - Preferences - Theme
[01:29] <trukulo> or you asking files ?
[01:38] <smurfix> fabbione: Has anything changed WRT ipw2200 and/or power handling? I can power the thing down but I can't get it back up :-/
[01:40] <fabbione> nope.. please test again with -27
[01:40] <fabbione> -26 is borked
[01:46] <jdub> Riddell: changing a gconf key; for you guys, i'd recommend dropping in a defaults file
[01:46] <jdub> Riddell: will explain later, have to put pipka to bed
[01:47] <smurfix> fabbione: Just booted -19, doesn't work there either :-/
[01:49] <smurfix> fabbione: I'll attack -27 with a debugging mallet if it doesn't behave ...
[01:51] <fabbione> smurfix: mjg59 is the person to ask.
[01:51] <fabbione> i really can't do anything about it
[01:51] <fabbione> i don't have the hw nor the knowledge to fix it
[01:51] <smurfix> fabbione: I'll bug him if it doesn't work
[01:51] <smurfix> fabbione: thanks
[01:53] <ogra> morning
[01:54] <trukulo> morning ogra
[01:54] <trukulo> oliver, have you seen news? nero on linux (propietary)
[01:54] <Kinnison> jeffy.
[01:55] <zul> hey jbailey
[01:56] <jbailey> Danny!  Chuck!
[01:57] <fabbione> hey jeff
[01:58] <jbailey> Fabio!
[02:03] <sabdfl> Mithrandir: thanks muchly!
[02:05] <Kinnison> It's very very cool
[02:15] <AndyFitz> trash icon concepts,   left or right style .  which one is preferred ?   http://andy.fitzsimon.com.au/trash.png
[02:15] <zul> left
[02:16] <ogra> hehe, right
[02:16] <AndyFitz> ogra, zul,  any particular reasons ?
[02:16] <zul> it looks better for me
[02:20] <ogra> AndyFitz: i just see the left variant in my panel......the outline looks to slim for me for such a small icon (as well as on the evolution,help and ff)
[02:22] <AndyFitz> good point ...  hrm.  I personally like the style of the left one better  but the right one does have the practicality going for it ..
[02:22] <jbailey> AndyFitz: I think I prefer the right because it has some colour to it.
[02:22] <AndyFitz> now that I think about it .. the right one looks like those pipes in maro.. at any moment a giant flower with teeth could come out of your empty wastebasket
[02:23] <jbailey> In the tiny iteration of the full one, I find it hard to tell the different between full and empty.
[02:23] <jbailey> (of the left one)
[02:25] <AndyFitz> they havent been cleaned up yet.   and I don't think they will be able to be ( by hoary's release )
[02:25] <AndyFitz> will finish the other stuff and come back to it later  maybe  on the mailing list
[02:27] <torkel> the right ones, they looks somewhat of what we have in sweden :-)
[03:02] <kent> I would prefer the right one, since the left trashcan does not look half as good as the right one.
[03:06] <dholbach> fabbione: ping
[03:14] <jdub> Kamion: around?
[03:16] <Alessio> sorry, do you have any news about mako? we should have a meeting this morning..
[03:16] <jdub> hmm, haven't seen mako around myself
[03:18] <Alessio> do you have know any way for contact him quckly?
[03:18] <Alessio> *qickly
[03:18] <Alessio> uhm..
[03:19] <dholbach> anyone of the TB crew in here? what's the status of kernel-*-2.4* in universe? and the reasoning behind it? :-)
[03:19] <ogra> smurfix was also waiting for him since 10:00 UTC
[03:21] <Alessio> ogra, me too
[03:21] <Alessio> he have agreed for that time
[03:21] <Alessio> *has
[03:22] <Alessio> ok, thanks
[03:37] <ogra> jdub, is there a chance to use the nice keyboard bell from ppaudio in esd ?
[03:43] <jdub> ogra: nup
[03:43] <ogra> hmm, :-/
[03:43] <ogra> was one of my favorite features....
[03:45] <torkel> ogra: you must be kidding? That was the first thing I turned off
[03:45] <ogra> i loved it
[03:48] <srbaker> whoa.  straw is *really* buggy.
[03:48] <srbaker> what's the "official" gnome-sanctioned RSS aggregator these days?
[03:49] <Nafallo> srbaker: liferea are used by many, myself I use thunderbird :-).
[03:49] <srbaker> Nafallo, yeah, i was using thunderbird.  just looking at lifrerea now
[03:51] <Nafallo> I tried liferea until I saw that Thunderbird would be happy to do the trick for me :-).
[03:55] <jdub> srbaker: blam! is pretty good
[03:55] <srbaker> jdub, i foudn it a little unstable
[03:56] <Mithrandir> the problem with using t-b is it's a bit slow, IME.
[03:56] <Simira> Kamion: ping
[03:57] <srbaker> Mithrandir, right, that's why i'm switching back to balsa.  and finding something new for reading rss
[03:59] <Mithrandir> I'm using liferea which works well except for one bug, which is it resets the position in the story window when refreshing the feeds.
[04:01] <srbaker> huh
[04:02] <Mithrandir> which can be annoying, but isn't a big thing
[04:05] <jon1012> hi everybody :)
[04:12] <fabbione> daniels: mplayer was at fault...
[04:12] <fabbione> daniels: uploaded the new version right now
[04:21] <_d4vid> Ubuntu 5.04-preview is released (GNOME 2.10 included)! Downloads are available at http://releases.ubuntu.com/hoary/. Test it NOW!
[04:23] <Nafallo> _d4vid: this channel didn't already knew that I suppose? ;-)
[04:27] <Burgundavia> no, the entire dev team has their head in the sand
[04:34] <GheRivero> res
[04:34] <jdub> hey ghe
[04:34] <jdub> got your mail
[04:34] <jdub> want to reply in detail, but relaxing a bit on the w/e, will reply on monday :-)
[04:34] <_d4vid> play Silbermond - Symphonie.mp3
[04:35] <GheRivero> jdub, should i wait good news?
[04:35] <jdub> GheRivero: i'm really keen for it, is the short summary ;)
[04:35] <jdub> GheRivero: you coming to UbuntuDownUnder?
[04:36] <GheRivero> no, i'm really far
[04:36] <jdub> i went to mataro ;)
[04:37] <GheRivero> me too, but australia is just in the other side, and my work is not really well paid
[04:38] <jdub> have you thought about requesting sponsorship?
[04:38] <jdub> or not enough time to come, either?
[04:39] <GheRivero> i tough about sponsorship, but i'm afraid i didn't feel comfortable using canonical money. I'm sure there is alot of more people that didn't go to mataro that would like to go to sidney
[04:39] <zul> the next conference should be in north america imho
[04:39] <Treenaks> zul: canada then
[04:39] <zul> even better
[04:40] <jdub> zul: fairly likely it will be south america.
[04:40] <zul> doh!
[04:40] <fabbione> i think the next will be in south africa
[04:40] <fabbione> south america ++++++!
[04:40] <zul> no no...north america...canada...ottawa *cough* *cough*
[04:40] <jdub> ogra: that's not south america ;)
[04:41] <fabbione> CUBA!
[04:41] <Treenaks> jdub: almost :)
[04:41] <ogra> jdub: but near ;)
[04:41] <fabbione> let's go to CUBA!
[04:41] <doko> fabbione: one time galapagos is enough ...
[04:41] <jdub> argentina, brazil, venezuela, ...
[04:41] <fabbione> cuba has bw
[04:41] <fabbione> and more...
[04:41] <Treenaks> jdub: Chile?
[04:41] <fabbione> expecially a lot of more
[04:41] <jdub> Treenaks: possibly
[04:41] <fabbione> GO SPARC GO!
[04:41] <fabbione> it's catching up
[04:42] <fabbione> jdub: flumotion? how do i debug that problem with the grabbing?
[04:42] <zul> more so than usual/
[04:43] <jdub> fabbione: try to run a raw gstreamer line with gst-launch-0.8
[04:43] <fabbione> jdub: is that supposed to handle the grabbing?
[04:44] <jdub> that will allow you to debug more closely to the problem area
[04:44] <fabbione> gst-launch-0.8
[04:44] <fabbione> ERROR: pipeline could not be constructed: empty pipeline not allowed.
[04:45] <jdub> you need to enter a pipeline ;)
[04:45] <jdub> it'll be like this:
[04:46] <jdub> gst-launch-0.8 v4lsrc ! videorate ! ffmpegcolorspace ! xvimagesink
[04:46] <jdub> something like that
[04:46] <jdub> if there's an error, let me know
[04:48] <fabbione> severals
[04:49] <fabbione> jdub: see /msg
[04:49] <fabbione> that's what i get
[04:49] <jdub> wow
[04:49] <jdub> that's the kind of error i'd direct you to #gstreamer about ;)
[04:50] <fabbione> jdub: that's the kind of error the flumotion maintainer should fix for me :P
[04:50] <smurfix> FWIW, that gst command line works perfectly on my system
[04:50] <fabbione> smurfix: here the problem seems to be related to IOCTL
[04:50] <fabbione> xawtv gets along with them
[04:50] <fabbione> and it works
[04:50] <fabbione> flumotion or ffmpeg don't
[04:51] <fabbione> stracing ffmpeg shows that it does some unknown (to the webcam) ioctl
[04:51] <jdub> fabbione: this is a gstreamer issue
[04:51] <fabbione> jdub: ok.. you know the guys in #gstreamer, don't you?
[04:51] <fabbione> i can help debugging and testing...
[04:51] <fabbione> let me join
[04:52] <jdub> fabbione: what kind of webcam do you have?
[04:52] <fabbione> jdub: it's a quickcam from logitech
[04:52] <fabbione> Bus 002 Device 003: ID 046d:08f5 Logitech, Inc.
[04:52] <fabbione> that is supported only by one unofficial driver forked by something else
[04:52] <fabbione> the driver is also called OOPSorama
[04:53] <fabbione> but it works generally
[04:53] <fabbione> at least it doens't die
[04:53] <jdub> heh
[04:53] <jdub> i have a quickcam 4000
[04:53] <fabbione> AH hold on
[04:53] <fabbione> error was bogus
[04:54] <fabbione> i forgot the trick to make it working
[04:54] <fabbione> the one in /msg is the correct one
[04:55] <jdub> try this
[04:55] <jdub> v4lsrc num-buffers=2 ! ...
[04:55] <jdub> the rest is the same as last time
[04:56] <fabbione>  gst-launch-0.8 v4lsrc num-buffers=2 ! videorate ! ffmpegcolorspace ! xvimagesink
[04:56] <fabbione> same error
[04:57] <jdub> bummer
[04:57] <jdub> well, combination of weird driver and odd gstreamer output -> #gstreamer ;)
[04:57] <fabbione> i think there is something else wrong
[04:57] <fabbione> ERROR: from element /pipeline0/v4lsrc0: Could not read from resource.
[04:58] <jdub> that's a relatively generic error
[04:58] <fabbione> it looks like that it can't open the device at all
[04:58] <fabbione> ok.. dude.. /j #gstreamer
[04:58] <fabbione> and introduce me to the guys
[04:58] <fabbione> as your God :)
[04:58] <fabbione> since i have root on your machine :)
[04:58] <fabbione> MUHA MUHA
[04:58] <fabbione> ;)
[05:01] <sivang> howdy all
[05:03] <Simira> hi sivang
[05:05] <sivang> hey Simira, what's up?
[05:06] <ari> the new python-gtk2 crashes streamtuner on startup :(
[05:06] <Simira> sivang: not much, really. translations and stuff, as usual :) You're going to Ubuntu Down Under?
[05:06] <sivang> Simira: no idea :) are you?
[05:07] <Simira> sivang: I hope so ;)
[05:07] <Treenaks> I'm not :(
[05:09] <zenwhen> Haha, i didnt upgrade for a day and got 113MB behind.
[05:10] <zenwhen> Stupid dialup
[05:12] <ogra> jdub: do yo know anything about gnome.sound_init() ?
[05:12] <ogra> (python)
[05:15] <fabbione> jdub: the value for the minimum buffers is hardencoded
[05:15] <fabbione> = the sucks
[05:39] <dilinger> fabbione: hm?
[05:49] <fabbione> dilinger: n/m..
[05:50] <Nafallo> fabbione: care to generate -nogui for amd64?
[05:50] <fabbione> hmmm
[05:51] <fabbione> Nafallo: right now the package build but there is no mplayer binary
[05:51] <fabbione> drwxr-xr-x root/root         0 2005-03-12 16:39:12 ./usr/bin/ is empty
[05:52] <Nafallo> hmm, works on i386 I guess?
[05:52] <fabbione> yes
[05:52] <fabbione> it simply doesn't build anything
[05:52] <fabbione> not even on ppc
[05:53] <fabbione> you need to get ubuntu5
[05:53] <fabbione> i think it is fixable
[05:53] <Nafallo> fabbione: URL? :-)
[05:53] <fabbione> Nafallo: it's in the archive
[05:55] <Nafallo> I better sync then. ubuntu3 showed up here.
[05:55] <Goshawk> is there someone that have packaged a library here?
[06:05] <HiddenWolf> ugh, evolution doesn't work well at all with postscript
[06:05] <Treenaks> HiddenWolf: in what wat?
[06:07] <Treenaks> way even
[06:07] <HiddenWolf> Treenaks: printing an html email from evo puts it on two pages, thunderbird does it one one, looking as intended
[06:08] <fabbione> jdub: i found the problem
[06:09] <fabbione> jdub: basically gst v4l plugin waits for the camera to send frames
[06:09] <fabbione> while xawtv does active polling on the camera
[06:09] <fabbione> the camera doesn't send frames back
[06:09] <fabbione> and gst hangs
[06:09] <fabbione> while xawtv keeps going on with IOCTL
[06:11] <fabbione> i think this should be solved both in the driver and gst
[06:15] <Treenaks> Nafallo: get one :)
[06:16] <Nafallo> Treenaks: trying. all ISPs I've tried want's to give me 0,5 maximum :-P.
[06:17] <Nafallo> they raised the rent, so I'm looking for a smaller apartment anyway.
[06:18] <_d4vid> http://raus.de/crashme
[06:18] <jani> mako ping
[06:18] <HiddenWolf> treenaks: see what I mean: https://bugzilla.ubuntu.com/show_bug.cgi?id=7524
[06:19] <Nafallo> hmm, maybe I can sync with a faster speed when not downloading livecd's via torrent ;-)
[06:24] <dholbach> see you later
[06:24] <fabbione> jdub: YES!
[06:24] <fabbione> jdub: found it!
[06:24] <fabbione> jdub: it's a bug in gstream, but there is a workaround in the driver for the cam
[06:29] <Nafallo> later all!
[06:29] <fabbione> jdub: but flumotion still doesn't love me
[06:31] <jani> mako ping
[06:33] <mako> jani: oi
[06:33] <mako> jani: sorry i missed you yesterday
[06:35] <ogra> mako, :( http://www.grawert.net/wiki_error.png
[06:35] <ogra> any idea ?
[06:36] <mako> ogra: um... not really, were you trying to log into the wiki from www.ubuntu.com ?
[06:36] <mako> ogra: evidently, it only works from www.ubuntulinux.org
[06:36] <ogra> http://www.ubuntulinux.org
[06:36] <mako> ogra: but that looks slightly insane
[06:36] <mako> no idea dude
[06:36] <ogra> it is
[06:36] <ogra> heh, ok
[06:40] <koke> is there any reason to not enabling the zope external editor for the wiki??
[06:41] <koke> I find it very helpful
[06:41] <Treenaks> performance, maybe/
[06:41] <Treenaks> ?
[06:42] <mako> koke: oh yeah dude, it caused big problems
[06:43] <mako> koke: i think, in many/most versions of mozilla, in generated screwed up xhtml
[06:43] <mako> koke: it was buggy and broke our pages frequently
[06:43] <mako> koke: unless i'm thinking of something else?
[06:43] <mako> koke: you can use mozex though
[06:43] <mako> and you can edit any textfield in an external editor
[06:44] <mako> i couldn't live with out that
[06:44] <koke> I've used it only a few times, in a personal test plone, so I didn't saw that :)
[06:44] <mako> mozex.mozdev.org
[06:44] <mako> recently, there were some firefox configuration bugs
[06:44] <mako> that were barring normal configuration of mozex
[06:44] <koke> there's no package?
[06:44] <mako> it's a mozilla extension
[06:44] <mako> you install it by clicking a link
[06:44] <mako> it's just hardly worth packaging unless it's by defaul
[06:44] <koke> :D
[06:45] <mako> and also, it has a firefox bug
[06:45] <mako> but you can set the configuration stuff through about:config
[06:45] <mako> i couldn't live with out it dude
[06:45] <mako> i would *die*
[06:46] <koke> I see :)
[06:50] <koke> mako: which are the keys at about:config?
[06:52] <jani> mako I'm back
[06:52] <jani> I wanted to ask you about
[06:52] <jani> the notary stuff
[06:53] <mako> koke: mozex.command.textarea is the major one
[06:54] <pitti> Hi folks
[06:54] <ogra> hj pitti
[06:54] <koke> I don't have any mozex stuff at about:config but I've found an article using user.js
[06:56] <fabbione> hey pitti
[06:56] <fabbione> hi mako
[06:56] <fabbione> pitti: you have mail
[06:56] <pitti> fabbione: just read it
[06:56] <pitti> fabbione: but I'm a bit in a hurry, just a quick email reading
[06:56] <mako> fabbione: hey dude
[06:57] <pitti> fabbione: but hey, you digged out _tons_ of crack from Debian :-/
[06:57] <mako> koke: you don't hmmmmm..
[06:57] <pitti> i
[06:57] <fabbione> pitti: i am more concerned about the disclosure
[06:57] <fabbione> mako: what's up?
[06:58] <fabbione> pitti: all that stuff is public, so i am not too worried and we have patches handy
[06:59] <koke> mako: ggrreat it's working :D much better now, thanks
[06:59] <mako> koke: pretty nice, yeah? :)
[07:00] <koke> if only vim had syntax highlighting for MoinMoin :P
[07:00] <Treenaks> koke: easy to write -> some regexps & Done
[07:00] <Loevborg> Treenaks, that's not so easy with vim :)
[07:01] <Treenaks> Loevborg: writing vim syntax files is not Hard.. just a lot of manual-reading
[07:02] <Loevborg> Treenaks, I personally consider reading manuals hard (particularly vim regex syntax).
[07:03] <Treenaks> Mithrandir: working OOo bling?
[07:03] <Mithrandir> Treenaks: working ooo bling on ia64 as well, yes.
[07:03] <Mithrandir> definitively bling
[07:03] <Treenaks> Mithrandir: wow
[07:04] <thierry> is there anyway I could change my keyboard configuration the way I like it (my current configuration doesn't work the way I'd like and there's no better one)
[07:04] <koke> Treenaks: it's done http://www.vim.org/scripts/script.php?script_id=725
[07:05] <fabbione> holy carp
[07:05] <Treenaks> fabbione: carp? like.. the fish thingies?
[07:05] <fabbione> mplayer build rule is total crap
[07:05] <fabbione> but it can be fixed somehow :-)
[07:07] <fabbione> ok i can fix it
[07:07] <fabbione> but not tonight
[07:13] <mdz> morning
[07:13] <Treenaks> hi mdz
[07:13] <zul> hi mdz
[07:14] <pitti> Hi mdz
[07:14] <doko> morning mdz
[07:15] <fabbione> hey mdz
[07:16] <fabbione> mdz: any objections if i fix mplayer for ppc/amd64/sparc?
[07:16] <mdz> fabbione: none whatsoever
[07:16] <fabbione> mdz: ok
[07:17] <fabbione> i still have to understand how did you manage to fly over that rules file
[07:19] <mdz> what rules file?
[07:19] <fabbione> the one in mplayer
[07:19] <fabbione> you touched it last (before me)
[07:19] <mdz> yes, to fix the FTBFS
[07:19] <fabbione> yeah
[07:19] <mdz> perhaps not in the ideal way
[07:20] <fabbione> ehhe
[07:20] <fabbione> no problem.. i will make it nicer
[07:20] <mdz> I didn't even look at rules, I don't think
[07:20] <fabbione> now i just want to see if it can build on amd64/ppc
[07:20] <fabbione> mdz: better!
[07:20] <mdz> it's upstream which is broken
[07:20] <fabbione> you spared yourself some pain
[07:20] <fabbione> well more than upstream is the maintainer
[07:20] <mdz> it uses functions from libvorbisenc but does not link with it
[07:20] <fabbione> i rememebr compiling tons of time mplayer manually
[07:21] <fabbione> oh that one yeah
[07:21] <fabbione> but i mean the build system is the sucks
[07:21] <mdz> daniels: ping?
[07:23] <ogra> dholbach, wb
[07:23] <dholbach> hi ogra
[07:23] <dholbach> hi
[07:23] <fabbione> mdz: i think it's like 6 am there
[07:23] <GheRivero> res
[07:25] <pitti> mjg59: here?
[07:25] <ogra> mdz: ping : your strace of hwdb-gui
[07:28] <fabbione> later fellas
[07:28] <zul> toodles fabbione
[07:28] <ogra> ciao fabio
[07:29] <mdz> ogra: pong
[07:29] <mdz> fabbione: daniels was awake until 8am local recently
[07:29] <ogra> mdz, are you sure esd was running at all when you tested ?
[07:30] <ogra> mdz, access("/tmp/.esd/socket", R_OK|W_OK)   = -1 ENOENT (No such file or directory)
[07:30] <ogra> doesnt look like
[07:30] <mdz> ogra: no, I am not, in fact I am fairly certain it was not
[07:30] <ogra> ah, ok
[07:30] <mdz> apparently, esdplay works without esd
[07:30] <ogra> yup, but i dount use esdplay :)
[07:31] <mdz> right, but I used esdplay to test that esd was working :-)
[07:31] <ogra> so i'll do some more tests on esd....
[07:31] <ogra> thanks
[07:46] <mdke> is anyone reporting a major bug in gnome? perhaps it is just my system
[07:46] <jani> is gcc3.2 still needed in universe?
[07:46] <Treenaks> mdke: what's the bug?
[07:46] <mdke> Treenaks, evolution takes 5 minutes to start, gnome-terminal crashes totally
[07:47] <Treenaks> mdke: look in top -> are there a few processes running at 100% CPU time?
[07:47] <mdke> looks clean
[07:48] <mdke> no processes i can see
[07:48] <Treenaks> ok
[07:48] <mdke> says 96% id tho
[07:49] <zenwhen> cd burning with k3b and nautilus has gone from great in warty for me to crap
[07:49] <mdke> gnome-system monitor isn't happy to start either
[07:50] <zenwhen> my system just chugs while a dvd burns, and it can only burn at 2.4x, instead of the 8x it could in warty.
[07:55] <mdke> Treenaks, reboot has solved it. It may have been caused when I added my network device. Bizarre that it should need a reboot tho
[07:55] <zenwhen> oh good, an old windows issue has returned in linux form. Now gnome wants to beleive that a dvd i ejected is stil there even when it isnt and it isnt mounted
[07:55] <zenwhen> lol
[08:01] <dholbach> oh pitti was here *grmbl*
[08:04] <ogra> dholbach, pitti is back :)
[08:04] <dholbach> hi pitti
[08:04] <pitti> Hi
[08:04] <dholbach> pitti: want to have the raw iso files?
[08:04] <pitti> dholbach: "have"?
[08:04] <dholbach> for better rsyncing?
[08:04] <pitti> dholbach: I thought you burn them on DVD?
[08:04] <dholbach> pitti: i was supposed to send them to you?
[08:04] <pitti> dholbach: yes, just burn them
[08:05] <pitti> dholbach: I can get them back with dd :-)
[08:05] <dholbach> ok
[08:05] <pitti> dholbach: you already downloaded them?
[08:05] <dholbach> just another 2 hours and i'm set
[08:05] <pitti> dholbach: cool, thanks a lot
[08:05] <dholbach> de rien
[08:06] <dholbach> pitti: want to see something scary?
[08:06] <pitti> ?
[08:06] <pitti> dholbach: the ultimate root hole?
[08:06] <dholbach> pitti: http://www.ubuntulinux.org/wiki/UniverseUnmetDeps :-)
[08:06] <pitti> sounds like work for you :-)
[08:06] <dholbach> hehe :-)
[08:08] <pitti> dholbach: argh, that's huuuge
[08:08] <dholbach> YES
[08:09] <ogra> yup
[08:13] <pitti> bye folks, dinner & dancing waits for me :-)
[08:13] <dholbach> have fun, pitti!
[08:13] <Treenaks> pitti: good luck & have fun :)
[08:13] <dholbach> et bon apptit
[08:13] <ogra> dancing ?
[08:13] <pitti> you too!
[08:18] <zul> mdz: no i havent tested those vfat synchronization patches
[08:20] <mpt_london> hahaha
[08:20] <mpt_london> "Generates a D-BUS message when new mail arrives"
[08:21] <mpt_london> This Evolution checkbox label brought to you by the RTFM Department
[08:21] <Mithrandir> mpt_london: that sounds plausibly useful
[08:21] <mpt_london> Mithrandir: ... I'm sure it is, if you're one of the ~0.01 percent of people who know what on earth "D-BUS" is
[08:22] <Treenaks> it should just send the message and don't care
[08:22] <Treenaks> you can disable the dbus-sending if you disable the plugin
[08:23] <Mithrandir> mpt_london: yeah, as a pref, it sounds fairly useless.
[08:24] <Treenaks> mpt_london: man dbus
[08:25] <mpt_london> No manual entry for dbus.
[08:28] <Treenaks> hm
[08:28] <Treenaks> dbus-something then
[08:28] <Treenaks> or apt-cache shwo :)
[08:28] <mpt_london> we left Aunt Tillie a long, long time ago, Treenaks :-)
[08:28] <Treenaks> mpt_london: I know :)
[08:30] <koke> elmo, ping?
[08:31] <koke> elmo, I mailed a whitelist to upload@ one week ago, do you know something about?
[08:57] <rubenv> are the apache2 packages in freeze, or will 2.0.53-5 (as in debian unstable) still leak into ubuntu?
[08:57] <rubenv> there are debian debs for PHP5 but they depend on 2.0.53-5
[08:58] <rubenv> hmmm, Maybe I'd rather rebuild them for ubuntu
[09:01] <ogra> rubenv: there are no syncs with debian until the release....
[09:01] <ogra> rubenv: at least not without a good reason (heavy breakage etc)
[09:01] <rubenv> ogra: okay, I'll try to rebuild them manually then
[09:02] <ogra> rubenv: thats really great, i'd like to see them in universe before release
[09:02] <rubenv> it's just for development anyway now
[09:02] <rubenv> i've just grabbed dexter's source pkg, my pbuilder chroot is updating
[09:04] <rubenv> having php5 (in universe) would be nice though
[09:04] <rubenv> makes my life a bit easier ;-)
[09:05] <ogra> rubenv: add it here once its ready for review: https://www.ubuntulinux.org/wiki/MOTUNewPackages
[09:06] <rubenv> ogra: okay, will take some time, I have experience with building seperate packages, not with the packaging process as a whole
[09:06] <rubenv> but i'll manage :)
[09:07] <ogra> rubenv: oh, and i heard roumors that infinity is the debian maintainer
[09:07] <rubenv> ogra: hmmm, strange
[09:07] <ogra> ?
[09:07] <rubenv> let's see if he has more current pkgs then dexter
[09:07] <rubenv> http://people.debian.org/~dexter/dists/php5/
[09:22] <Mithrandir> Kamion: new ooo-amd64 with ia64 support now uploaded, so assuming it builds fine, updating the seeds should be fine.
[09:46] <mdz> seen mvo or pitti today?
[09:47] <Mithrandir> pitti was around a couple of hours back
[09:48] <mdz> need someone to test #7138
[09:51] <Mithrandir> powerpc needed, I guess?
[09:55] <mdz> hmm, maybe that is all that's needed
[09:56] <mdz> in which case I could test it myself
[10:53] <dholbach> oh baby, wiki me harder: http://wiki.ubuntu.com/UniverseUnmetDeps :-)
[10:56] <Keybuk> mdz: have a bug :p
[10:58] <ogra> dholbach, why is ooo2 on this list ?
[10:59] <dholbach> ogra: feel free to remove it... it's not installable, that's why and since i live on amd64 :-)
[10:59] <ogra> dholbach, me too, but its all haggais, so MOTU doesnt need to touch it
[11:00] <ogra> dholbach, removed :)
[11:00] <dholbach> please remove it then... i.e. i won't touch any kernel/mono thing, but it's on the list too - or just put it at the very at of the list
[11:03] <dholbach> hi enrico
[11:03] <enrico> dholbach: hi!
[11:04] <dholbach> enrico: i saw you're the maintainer of debtags and debtags-edit
[11:04] <enrico> dholbach: that's me!
[11:04] <dholbach> could you rebuild them with the current apt?
[11:04] <enrico> dholbach: problems?
[11:04] <dholbach> no.. they're just not installable atm
[11:05] <enrico> gosh, ok
[11:05] <dholbach> no worry, just wanted to mention it
[11:05] <ogra> enrico: i looked over the document previews today
[11:06] <enrico> dholbach: sure, thanks.  Is there a bug reported for it?
[11:06] <dholbach> enrico: no, it's just on https://www.ubuntulinux.org/wiki/UniverseUnmetDeps
[11:08] <enrico> dholbach: I don't understand the issue very well, however I need to chair a docteam meeting on #ubuntu-meeting now: please ping me later
[11:08] <enrico> ogra: want to come to the meeting and tell how it was/
[11:08] <enrico> ?
[11:08] <ogra> already in the channel ;)
[11:09] <mdz> enrico: the libapt ABI has changed in Hoary (more than once, even), so programs using it need to be rebuilt with the current apt
[11:09] <enrico> mdz: what I don't understand is: since Hoary has source-only uploads, how come you just don't trigger a rebuild?
[11:10] <enrico> I'd just need to reupload the source unchanged?
[11:10] <enrico> Into... Hoary or Debian?
[11:10] <mdz> enrico: correct, a source upload is required
[11:10] <mdz> enrico: into Hoary, where the uninstallable package is
[11:10] <dholbach> but a triggered rebuild would be VERY nice ;-)
[11:10] <mdz> we don't do bin-only NMUs
[11:11] <ogra> hmm, we dont do NMUs at all ;)
[11:14] <psy_> NMU?
[11:14] <dholbach> non-maintainer upload
[11:15] <Keybuk> we don't do binary uploads at all either
[11:15] <dholbach> oh my, seems like most packages on UniverseUnmetDeps are broken badly
[11:18] <psy_> ah
[11:26] <psy_> i remember reading something about using different apps to connect to a single gtk-widget. Does anyone here know how that works?
[11:27] <psy_> ehh, not at the same time of-course, i mean different apps connecting to each-others widgets.
[11:31] <Keybuk> bonobo? gtksocket?
[11:34] <psy_> gtksocket? hmm, that sounds familiar (doing a google to see if that's what i mean)
[11:36] <psy_> Keybuk: you're tha best :) thanx
[11:37] <mdz> thom: ping?
[11:37] <mdz> Keybuk: the buildds do binary uploads...
[11:38] <Keybuk> mdz: the gerbils inside do, you mean :p