[12:12] <Riddell> ok
[12:31] <__keybuk> hmm, interested
[12:32] <__keybuk> failed to resume from hibernate; I guess that's an initramfs bug because it seemed to suspend ok
[12:32] <Keybuk> suspend-to-ram worked, but the ipw3495 needed rmmod/modprobe on resume
[12:32] <Keybuk> mjg59: any clue to the first?
[12:33] <mjg59> Define "failed"
[12:33] <Keybuk> mjg59: it (new laptop) appeared to hibernate just fine (other than a few USB messages)
[12:34] <Keybuk> when power button pushed to resume, booted, GRUB, then just continued the usual boot sequence but leaving the suspended image in the swap partition rather than resuming from it
[12:34] <mjg59> Check /etc/initramfs-tools/conf.d/resume
[12:34] <Keybuk> that had RESUME=UUID=$(uuid of swap partition)
[12:35] <mjg59> Ok. So that should really have worked.
[12:36] <Keybuk> yeah
[12:36] <mjg59> What does dmesg say?
[12:36] <wasabi> So.. Ubuntu philosophy question. What do we all agree to mean by "Just Works".
[12:36] <wasabi> Just Works, under specific circumstances?
[12:36] <wasabi> Just Works, for home users?
[12:36] <HrdwrBoB> Just Works for as many people as possible
[12:36] <Keybuk> mjg59: nothing obvious, any particular string to grep for?
[12:37] <mjg59> Keybuk: There should be an "Attempting manual resume"
[12:37] <Keybuk> mjg59: no string like that in dmesg
[12:37] <wasabi> Just Works, if you edit 3 environmental variables?
[12:37] <mjg59> Keybuk: Is this feisty or edgy?
[12:37] <Keybuk> mjg59: feisty
[12:37] <mjg59> Hm
[12:37] <fadey> hi
[12:37] <mjg59> What kernel version?
[12:37] <Keybuk> mjg59: 2.6.20-3
[12:37] <mjg59> Right.
[12:37] <mdke> wasabi: just works, all the time.
[12:37] <mjg59> There's been some changes in 2.6.20 upstream that may have broken things.
[12:38] <Keybuk> dunno if it's related, but I saw some kinit resume messages when I wasn't trying to resume
[12:38] <mjg59> Can you try a 2.6.19 kernel?
[12:38] <wasabi> mdke: Does twisting environmental variables fall under Just Works?
[12:38] <Keybuk> but those messages weren't shown when I was
[12:38] <wasabi> Just Works, for admins adept at editing login scripts, maybe.
[12:38] <mjg59> wasabi: No
[12:38] <mdke> wasabi: no, the nature of having a philosophy is that you can't achieve it all the time
[12:39] <mdke> it's an ideal
[12:39] <Keybuk> mjg59: I'll debug a bit more tomorrow and get back to you
[12:39] <mdke> my philosophy is to go to bed early, but I never do
[12:39] <wasabi> https://launchpad.net/ubuntu/+source/beagle/+bug/77768
[12:39] <Ubugtu> Malone bug 77768 in beagle "should not store indexes in ~" [Unknown,Rejected]  
[12:39] <mjg59> There are situations where it's impossible to Just Work. There are other situations where Just Working would comprimse the Just Working of some other situation
[12:39] <Keybuk> jdub claims it works fine on this machine in edgy, so I'm guessing it's just a feisty bug
[12:39] <mdke> Ubuntu is much better than I am at that
[12:39] <mdke> mjg59: well put! :)
[12:40] <mjg59> wasabi: I disagree with the assertion that the Beagle data is system specific. In the common case, it isn't.
[12:41] <wasabi> It makes no distinction about indexed files in ~ or /foo
[12:41] <mjg59> The default setup is that Beagle indexes the home directory.
[12:41] <wasabi> So, unfortunatly, it sort of is.
[12:41] <mjg59> Not /whatever
[12:41] <wasabi> Hmm. That's true.
[12:41] <mjg59> Therefore, with the default setup it makes sense that Beagle's information be stored there
[12:41] <wasabi> I'd still argue that it doesn't belong in ~ for transiate cache reasons.
[12:41] <mjg59> It's not a transient cache
[12:41] <wasabi> Sure it is. It can be regenerated.
[12:41] <jdub> bah, keybuk left
[12:41] <wasabi> 100%.
[12:42] <mjg59> And the application won't work until it has been regenerated, which may take a long time
[12:42] <wasabi> Hmm. The application will "work". It will say the cache needs to be built, please wait.
[12:42] <wasabi> Okay, let me just bring up my actual real world circumstance.
[12:42] <wasabi> My ~'s are AFS mounted.
[12:42] <mjg59> An argument that I /would/ agree with is that if directories outside ~ are indexed, they should be tagged with the hostname
[12:43] <wasabi> Pssh. I completely disagree. No other platform does it that way, for good reason.
[12:43] <mjg59> So beagle can determine whether the result is relevant on the current host
[12:43] <mjg59> ?
[12:43] <mjg59> No, beagle should do it
[12:43] <wasabi> a) I cannot store sockets in ~. As sockets are used to connect to LOCAL processes, they have no place in a directory which is designed to be sharable between multiple hosts.
[12:43] <wasabi> b) Access to the files isn't safe over AFS or NFS. No locking.
[12:44] <mjg59> It's entirely possible to implement safe locking over AFS or NFS
[12:44] <mjg59> And, uh, you can't store sockets in ~? What sort of toy filesystem is this?
[12:44] <wasabi> AFS.
[12:45] <wasabi> ...
[12:46] <wasabi> I'm also not sure if searching 400MB of index data over AFS is going to be very entertaining.
[12:47] <mjg59> It's not like it does a linear search
[12:47] <wasabi> Sure.
[12:48] <wasabi> Anyways, Windows doesn't do it. Index data there is per-host... stored in a special per-host-per-user dir... for a very good reason anyways.
[12:48] <mjg59> But anyway. The argument that it should be put in /var would break another Just Works situation, where /var is not configured to be large enough for a large number of users to have large files there
[12:48] <wasabi> ...
[12:48] <mjg59> If home directories are shared, it's reasonable for user-specific information to be stored there. See gconf, for example.
[12:48] <wasabi> I don't think I can really accept that argument.
[12:48] <wasabi> You make /var big enough to hold what it needs to hold. heh.
[12:48] <wasabi> Or the installer does.
[12:49] <mjg59> Well, no, that's not the case on thin clients
[12:49] <wasabi> gconf does it because host-specific settings aren't in gconf.
[12:49] <mjg59> They so are
[12:49] <wasabi> Except for a few cases like powermanagement and friends.
[12:49] <mjg59> Screen resolution, for instance
[12:49] <wasabi> *sigh* I think that's wrong too.
[12:49] <mjg59> Tough.
[12:49] <mjg59> The Unix Way(tm) is for user-specific information to be in ~
[12:49] <wasabi> I guess my only defense left is to pull the Windows card. They didn't do it. For good reason.
[12:50] <wasabi> heh.
[12:50] <wasabi> =(
[12:50] <wasabi> mjg59: You mean like crontabs?
[12:50] <mjg59> You keep saying "for good reason", but you haven't said what that reason is
[12:50] <wasabi> I've listed a number of them.
[12:50] <wasabi> I think I can give a pretty good argument that the number of office workstations with a small /var is lower than the number with a network mounted ~
[12:50] <mjg59> You've said that AFS is broken, that doing locking on AFS is hard and that performance may be reduced
[12:50] <wasabi> And again, we desire Just Works in the majoirty of cases.
[12:51] <bhale> i havent said anything, but i am in agreement with mjg59 
[12:51] <bhale> if that matters.
[12:51] <wasabi> It's disappointing. I just know it's not going to be acceptable in most of hte network environments where I am trying to replace windows.
[12:51] <wasabi> For the reasons I listed.
[12:51] <wasabi> It's huge massive data. It doesn't need to be network mounted, it shouldn't.
[12:52] <_ion> bhale: My left brain hemisphere agrees, but the right one disageres.
[12:52] <bhale> do you need to use beagle in this environment?
[12:52] <mjg59> Now, in counterargument, I'm going to say that if I run beagle on one machine in a cluster, I don't want to have to wait for an extended period of time for Beagle to reindex my files just because I've moved to another machine.
[12:52] <wasabi> bhale: Seeking to replace windows, I do.
[12:52] <mjg59> That isn't Just Working. It's stupid.
[12:52] <wasabi> Since we use their indexing service.
[12:53] <mjg59> It results in massive duplication of data, lower performance and  beagle having to look for new and altered files every time I log in
[12:53] <wasabi> mjg59: I agree. I think then perhaps with that argument /var/cache isn't the best place for it, or that perhaps a cluster should deal with sharing some known location of per-user/per-host data.
[12:53] <wasabi> But I don't any more agree that ~ is the best place for it.
[12:53] <wasabi> Nor do I think the number of people running clusters in that situation is greater than the number of office desktops.
[12:54] <bhale> dave_largo works on beagle for a thin client type network
[12:54] <bhale> a few central servers
[12:54] <bhale> lots of workstations/users
[12:54] <mjg59> If AFS can't handle sockets in ~, that's an argument for keeping sockets in /tmp
[12:54] <bhale> he might have some interesting parallels
[12:54] <wasabi> I guess maybe this is a market we haven't really gotten traction in much.
[12:54] <wasabi> WHich is why it's not yet a problem.
[12:54] <wasabi> I deal with large office environments. Desktops, with central user management policies. AD, Windows.
[12:55] <mjg59> If beagle isn't handling file locking over network mounted filesystems, then that's a bug in beagle
[12:55] <mjg59> Those are both valid technical concerns, and if they cause problems then they should (and can) be fixed
[12:55] <wasabi> Well, I sort of have a real feeling that sockets on a network mounted file system are stupid sounding.
[12:55] <mjg59> Why?
[12:55] <mjg59> You encode the hostname into them, and they work fine
[12:56] <wasabi> Bah. SIllyness.
[12:56] <mjg59> While they're running?
[12:56] <mjg59> I suggest not doing that
[12:56] <wasabi> No. Windows makes me reboot. =)
[12:56] <mjg59> That's fine. You recreate the socket on boot
[12:56] <mjg59> Or login, or whatever
[12:57] <wasabi> And that isn't odd that you're going all the way across the network to facilitate two local programs talking to each other?
[12:57] <mjg59> Uh. Dude.
[12:57] <mjg59> That's really not how sockets work.
[12:57] <wasabi> I know. The data doesn't move across the network.
[12:57] <wasabi> I know that stuff.
[12:57] <wasabi> But it's silly that you have to create a file over there, to talk over here.
[12:58] <mjg59> Why? It's an atomic operation.
[12:58] <mjg59> It'll be one round trip to the server
[12:58] <wasabi> This is a completely tangent minor technical complaint/argument.
[12:59] <wasabi> I don't particularily care if you do in fact make a file on a remote system to talk to the same system... but it's technically silly.
[12:59] <mjg59> Yes, but it's the strongest technical argument you've brought up
[12:59] <wasabi> =(
[12:59] <mjg59> I'm sorry, but "Windows doesn't work like that" isn't a compelling argument
[01:00] <wasabi> Yes, i know.
[01:00] <mjg59> We're different from Windows in a large number of ways, and that's something that has to be factored into conversion costs
[01:00] <wasabi> I didn't mean to use it as a compelling argument.
[01:01] <wasabi> This argument isn't worth having right now. I will give it another try when more people are using Linux in circumstances like that.
[01:01] <mjg59> There are millions of people using Linux in circumstances like that
[01:01] <mjg59> I used to admin a network of ~100 of them
[01:01] <wasabi> I must live in a cave then. Heh.
[01:02] <mjg59> NFS ~, local /
[01:02] <mjg59> Everything went in ~, since it was the only stuff we backed up
[01:02] <wasabi> See, I would be pretty unhappy if I ran my backup program and it snarfed up 10GB of indexes.
[01:03] <mjg59> Well, that's a trivial exclusion in the backup options
[01:03] <wasabi> Not for the people who set up the networks I work on.
[01:03] <mjg59> You probably don't want to backup the Firefox cache either...
[01:03] <wasabi> Yup. You're right.
[01:03] <wasabi> Which is why IE does not store it's cache in the roaming portion of a user's profile.
[01:03] <wasabi> It goes nicely in Local Settings.
[01:03] <wasabi> .evolution is another example.
[01:04] <Nafallo> hmm
[01:04] <wasabi> Luckily outlook puts it's client side cache in Local Settings too.
[01:04] <mjg59> Evolution stores your mail there. That's very much per user, not per system
[01:04] <wasabi> It's cached data in any networked environment I've been in.
[01:04] <wasabi> Nobody uses POP anymore.
[01:05] <Nafallo> my parents use POP ;-)
[01:05] <wasabi> Ahh. Good point. Home users do.
[01:05] <lifeless> wasabi: people use POP
[01:05] <lifeless> wasabi: even corporate folk choose to
[01:05] <wasabi> And I agree, POP goes in ~.
[01:05] <wasabi> IMAP doesn't...
[01:05] <Nafallo> but my parents are stupid so... ;-)
[01:05] <HrdwrBoB> we mandated that people don't use POP
[01:05] <HrdwrBoB> because they are generally useless and lose their mail
[01:06] <mjg59> Unix and Unix-type operating systems have never guaranteed any significant user-specific storage outside ~, and large quantities of software are built around that assumption
[01:06] <wasabi> mjg59: Curiously, why is crontab an exception?
[01:06] <wasabi> crontab imo is a great one.
[01:06] <wasabi> It does it perfectly. :0
[01:06] <wasabi> per-user/per-host.
[01:06] <mjg59> Because cron jos are executed even when the user isn't logged in
[01:06] <mjg59> Which means you can't guarantee access to their home directory
[01:08] <wasabi> I'm also not particularly interested in obeying any definition of "Unix and Unix-type" that mandates such things if those things don't in fact line up with what I need them to do to get the job done.
[01:08] <wasabi> Just as good as relying on "But windows does it!"
[01:09] <mjg59> "Unix does it like this" is not a compelling argument for changing the behaviour of a Windows app. But it /is/ a compelling argument for deciding the behaviour of a Unix app.
[01:10] <mjg59> If your argument is "Linux doesn't behave like Windows, and therefore we face increased migration costs", then you're right.
[01:10] <wasabi> No, that's not my argument.
[01:10] <wasabi> My argument is I have some jobs that need to be done, jobs which I believe Ubuntu does in fact claim to function properly with.
[01:11] <wasabi> That is, a non-thin client desktop, connected to a central server for a user's ~ data.
[01:11] <mjg59> How does Beagle placing its indexes in ~ prevent any jobs?
[01:12] <wasabi> it makes the Just Workyness of a configuration like that less Just Worky.
[01:12] <mjg59> How?
[01:12] <wasabi> a) indexes generate Really Really slow, access to them is also sluggish. They are huge amounts of data after all, they index people's email full text.
[01:12] <wasabi> b) They are huge. They take up server space which doesn't in fact need to be consumed.
[01:13] <lifeless> wasabi: meh, those are not the issue
[01:13] <wasabi> c) sockets don't work, this isn't a primary concern of mine, because I do agree AFS has a problem.
[01:13] <wasabi> What's the issue then? That I'm not deploying thin clients?
[01:13] <wasabi> Or that I'm network mounting ~?
[01:13] <wasabi> Or that I chose AFS?
[01:14] <mjg59> (a) - no. The rate of index generation is not limited by write speed.
[01:14] <lifeless> mjg59: if beagle places indexes in ~, and it indexes the machine I'm logged in on, then with a NFS mounted homedir, the beagle index needs to represent two separate machines in one physical index
[01:14] <wasabi> Dude. My index files are 500MB.
[01:14] <wasabi> Just for me.
[01:14] <lifeless> mjg59: or be split per host in the users homedir.
[01:14] <mjg59> lifeless: Please refer to the beginning of the conversation
[01:14] <wasabi> You're telling me it magiked 500MB across a 100MBs network?
[01:14] <lifeless> mjg59: I thought I had ;).
[01:14] <mjg59> wasabi: On startup, beagle indexes very slowly.
[01:15] <mjg59> At no point will it be i/o bound.
[01:15] <wasabi> Sure, but it also kills the network.
[01:15] <mjg59> No, it doesn;t.
[01:15] <mjg59> The data is trickled across.
[01:15] <wasabi> ...
[01:15] <wasabi> Well, I have experiences that say otherwise. Are you suggesting it's a beagle bug that it doesn't attempt to write slower than possible?
[01:16] <mjg59> I'm saying that Beagle does not generate 500MB of indexes in the first 5 minutes, yes
[01:16] <wasabi> Takes longer than 5 minutes. =)
[01:17] <wasabi> Now, curiously, how does beagle actually implement a search that doesn't require reading a large portion of the 500MB over the network?
[01:17] <mjg59> (c) is clearly nothing to do with the indexes
[01:18] <wasabi> Oh, hey, I take that back.
[01:18] <wasabi> 3.4G    .beagle/
[01:18] <wasabi> Hadn't actually checked in a few days. ;)
[01:18] <shackan> ugh
[01:19] <shackan> that's just your home?
[01:19] <wasabi> I have a lot of email.
[01:19] <wasabi> Also, it's network shares.
[01:19] <wasabi> Some...
[01:19] <wasabi> actually, probably not. I don't think I ever got it to index those.
[01:19] <mjg59> wasabi: Given that it's able to fully answer my queries in much less time than it would take to read 500MB off the disk, it clearly can
[01:19] <wasabi> mjg59: Local ~?
[01:20] <mjg59> I am, sadly, not an expert on the state of the art in the sort of data structures used in indexing
[01:20] <mjg59> Yes, local ~
[01:20] <wasabi> It's probably mmaped and pretty warm.
[01:20] <mjg59> No
[01:20] <shackan> well, it surely is not a linear search so it's never going to have to slurp the whole half gig from disk
[01:20] <mjg59> But what I'd assume at the very least is that it's a tree
[01:21] <wasabi> argh. it uses absolute symlinks too.
[01:22] <mjg59> For logfiles - that's hardly an issue...
[01:22] <Nafallo> hi jono :-)
[01:22] <jono> hey
[01:23] <wasabi> Well. I can't argue this anymore. I have work to do. If nothing else I really think it's silly to store 3.2GB of non-critical data in something which is generally considered critical: ~
[01:23] <wasabi> night
[01:31] <maxb> What is the proper thing to do when a severe bug (package totally unusable) is filed in Launchpad, but no maintainer responds, even after 3 months have passed?
[01:31] <crimsun> which bug?
[01:32] <maxb> 62748
[01:32] <crimsun> bug 62748
[01:32] <Ubugtu> Malone bug 62748 in subversion "2.0.55-4ubuntu4 update causes svn failure" [Undecided,Confirmed]  https://launchpad.net/bugs/62748
[01:34] <crimsun> maxb: if you feel inclined, please follow https://wiki.ubuntu.com/StableReleaseUpdates
[01:37] <maxb> crimsun: That wiki page seems to be instructions for package maintainers, no?
[01:37] <crimsun> maxb: it's not limited to maintainers, no.
[01:40] <maxb> Anyone can upload to <release>-proposed ?
[01:40] <crimsun> no, in this case, only ubuntu-core-dev
[01:40] <LaserJock> maxb: not actually upload, but prepare an upload sure
[01:41] <crimsun> anyone may prepare an SRU debdiff, however, as LaserJock mentioned
[02:01] <maxb> I've added a debdiff to the bug. The rest of the SRU procedure really looks like it needs participation from maintainer, even if I can help it along in places. I guess I'll hang around on IRC and try to initiate communication that way.
[02:02] <crimsun> which bug #?
[02:02] <crimsun> (it helps immensely when you provide this information up front so we don't have to ping-pong)
[02:03] <crimsun> btw, file a new bug for an SRU
[02:05] <maxb> Same bug number as before
[02:05] <maxb> bug 62748
[02:05] <Ubugtu> Malone bug 62748 in subversion "2.0.55-4ubuntu4 update causes svn failure" [Undecided,Confirmed]  https://launchpad.net/bugs/62748
[02:05] <crimsun> it'll help the SRU team if you collapse only the relevant info into a new bug report
[02:06] <bddebian> Heya
[02:08] <crimsun> maxb: use the SRU versioning, please: 2.0.55-4ubuntu4.1~proposed1; the distro is "edgy-proposed"; please state the rationale in debian/changelog for filing an SRU debdiff in the first place; attach the actual debdiff (not just inline)
[02:10] <sistpoty> crimsun: btw.: what would be the version for the actual upload actually? ~distribution1 (which would score lower than ~proposed1)?
[02:11] <sistpoty> upload to -updates actually
[02:11] <crimsun> sistpoty: 2.0.55-4ubuntu4.1
[02:11] <sistpoty> crimsun: ah, makes sense :)
[02:11] <keescook> g'night folks
[02:11] <sistpoty> gn8 keescook
[02:11] <Nafallo> oh. I thought .X was for -security only :-)
[03:32] <okaratas> hello
[03:44] <somerville32> hi
[05:27] <tonyyarusso> cjwatson, any others: We're going to spotlight the process for Main Inclusion Requestions for the Ubuntu Weekly Newsletter, so if you'd like to talk to me about that, give any guidance on the article, or throw out some great quotes I can attribute, join #tonyyarusso and let me know.
[05:31] <tonyyarusso> Any core devs actually (his name was on the wiki as last editor is all)
[05:32] <tonyyarusso> Any time in the next couple of days.  We plan to release this edition on the 8th.
[05:36] <tonyyarusso> (If I'm not there, but tonyyserver is, you can leave a message and it will be logged)
[06:02] <StevenK> mpt: Too slow. I have done but not commited or pushed a first stab at Debian packaging.
[06:02] <StevenK> mpt: (For About window). I've spent a grand total of 30 minutes on it, so if you've done it, I'm happy to bin it.
[06:09] <mpt> StevenK, thank you
[06:10] <StevenK> mpt: Also some changes to AboutWindow.py that allow it to work both ways, either running from . or installed from a package
[06:11] <StevenK> mpt: I was planning on adding a menu file stuffing an entry into the System menu, and then commiting and pushing
[06:11] <mpt> StevenK, does that replace the existing "About Ubuntu" item?
[06:12] <mpt> (it should)
[06:12] <StevenK> Which is harder.
[06:12] <mpt> ah :-)
[06:12] <StevenK> Yes it should, I wasn't planning on enforcing that.
[06:15] <StevenK> gnome-panel-data: /usr/share/applications/ubuntu-about.desktop
[06:15] <StevenK> Oh, icky.
[06:18] <StevenK> mpt: I'm also going to kill the icons that aren't *ubuntu.
[06:19] <StevenK> Since they have been unceremoniously killed from the glade file.
[06:22] <mpt> Hey, I was very ceremonious
[06:23] <mpt> I lit a candle and everything
[06:25] <StevenK> :-P
[06:35] <StevenK> mpt: Hrm. My .desktop file doesn't work.
[06:37] <Hobbsee> StevenK: try lighting a candle for it :P
[06:39] <StevenK> Hah
[06:49] <StevenK> Hrm. I don't get it.
[06:57] <fabbione> who broke locales?
[06:59] <StevenK> mpt: Commited and pushed.
[06:59] <StevenK> mpt: The .desktop file needs sorting out, and I'd like to see it run on a PowerPC
[07:04] <crimsun> cjwatson: please reject murrine_0.40.1-0ubuntu1 from NEW; a ship-shape source package with proper pedigree (from clearlooks, etc., in a CREDITS file) will be uploaded
[09:00] <fabbione> The following packages have unmet dependencies:
[09:00] <fabbione>   evolution-data-server: Breaks: evolution-exchange (< 2.9.4) but 2.8.2-0ubuntu1 is to be installed
[09:00] <fabbione> E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
[09:00] <fabbione> E: Internal error, problem resolver broke stuff
[09:00] <fabbione> mvo: ^^^?
[09:01] <mvo> fabbione: please install the latest apt directly and then do a dist-upgrade
[09:01] <mvo> (a bug in the breaks field implementation)
[09:01] <fabbione> apt-get install apt
[09:01] <mvo> yes
[09:01] <fabbione> apt is already the newest version.
[09:01] <fabbione> Version: 0.6.46.4ubuntu6
[09:01] <fabbione>  ?
[09:02] <mvo> oh. that is a new problem then. strange enough, it looks exactly like the old problem :)
[09:02] <fabbione> mvo: this is ok sparc
[09:02] <fabbione> the machine was not updated for a couple of weeks
[09:03] <fabbione> mvo: dist-upgrade seems to work... the error was when invoking with dselect
[09:04] <mvo> fabbione: ok. so when pressing [Install]  in dselect it bombed out?
[09:04] <fabbione> mvo: yes..
[09:04] <mvo> fabbione: had someone teached the dselect resolver about breaks yet?
[09:04] <mvo> s/had/has/ 
[09:04] <fabbione> mvo: i thought that dselect/dpkg already knew about Breaks
[09:05] <fabbione> at least i recall using dselect in edgy when we had breaks enabled
[09:05] <fabbione> but does Breaks: support ABS ? :P
[09:05] <mvo> fabbione: HAHA
[09:06] <fabbione> time for a shower
[09:06] <fabbione> brb
[09:08] <mvo> fabbione: I'm testing it in a chroot now
[09:08] <fabbione> mvo: ok..
[09:51] <Mithrandir> crimsun: rejected
[09:53] <crimsun> Mithrandir: thanks
[11:31] <gnomefreak> is it just me or is feisty main repo down
[12:32] <Mithrandir> siretart: does libxine1-console => universe sound ok with you?  -gnome and -kde to main? (And -ffmpeg to main?)
[12:43] <Keybuk> Mithrandir: you know a little about xkb?
[12:43] <Keybuk> why is the Windows key now suddenly <Mod4><Hyper> ?! :)
[12:44] <Mithrandir> it is?  For me it's Super.
[12:44] <Keybuk> it's Super for me on edgy
[12:44] <Keybuk> but on feisty, it appears to be weird
[12:45] <Keybuk> both machines running feisty exhibit it
[12:45] <fabbione> something is broken in locale too
[12:46] <Mithrandir> somebody said something this morning about locales being broken, I'm not sure how and such, though
[12:46] <fabbione> this smells of libx11-6 borkage
[12:47] <fabbione> no.. not even
[12:47] <Keybuk> hmm
[12:47] <Keybuk> my edgy machine has it too
[12:47] <Keybuk> weird
[12:48] <fabbione> hmm it looks like something didn't run locale-gen
[12:48] <fabbione> oh well i am hungry :)
[12:54] <Keybuk> mjg59: I'm assuming you never fixed GNOME Power Manager to not override the ondemand governor?
[12:59] <mjg59> No, upstream were meant to be fixing it
[12:59] <ogra> i think upstream agreed on it on the ML already
[12:59] <ogra> should be fixed in the next package
[01:00] <Keybuk> ok, cool
[01:01] <ogra> i wonder if we really need that power hostory tool in the system tools menu ... 
[01:01] <ogra> *history
[01:05] <siretart> Mithrandir: I'm okay with that, whereas I don't see quite the point. in previous versions of ubuntu, everything was in main
[01:05] <siretart> Mithrandir: why do you want -ffmpeg in universe?
[01:06] <siretart> Mithrandir: in the TB meeting, we agreed that -ffmpeg may enter main, but MUST NOT be in the ship seed, so that it doesn't go near a live cd
[01:06] <Mithrandir> siretart: if everything used to be in main, I'm fine with keeping it that way; it's mostly a "try to keep main as small as possible" reflex.
[01:07] <siretart> Mithrandir: yes, with the split we indeed have that oppurtunity. I split the package mainly to get more sane depend lines
[01:07] <Mithrandir> siretart: if you'd like it all in main, I'm fine with that.  At least until it shows up as "unused" in the anastacia output.
[01:08] <siretart> Mithrandir: okay, then lets put them all in main for now, and reconsider later about what output plugins we want to support for feisty
[01:08] <siretart> (I'm of course for all ;)
[01:09] <Mithrandir> siretart: ok.
[01:13] <elmo> is network manager meant to get along with madwifi/atheros chipsets?
[01:14] <fabbione> elmo: did you get my /msg about the sparc kernel?
[01:14] <elmo> fabbione: err, not sure - which one/when?
[01:14] <elmo> artigas is running that debug kernel you gave me las tyear
[01:14] <fabbione> elmo: the one to test on the buildd
[01:14] <fabbione> perfect
[01:14] <fabbione> thanks
[01:14] <siretart> elmo: depends on what madwifi. it is known to make problems with madwifi-old, and there are successful reports with madwifi-ng
[01:15] <elmo> siretart: what does edgy default to ?
[01:15] <siretart> details: -old did not support 'background' scanning
[01:15] <Ng> edgy uess madwifi-ng
[01:15] <Ng> network managet should work with it (does on my laptop and desktop)
[01:15] <siretart> dapper was with madwifi-old
[01:15] <elmo> hmm, ok - so what's the magic to turn network manager on?
[01:15] <elmo> I thought it was disabling the auto lines in /etc/n/i
[01:15] <mjg59> edgy only uses madwifi-ng under certain circumstances
[01:15] <mjg59> Oh. Maybe not.
[01:15] <Ng> elmo: removing the device entirely from interfaces seems to work
[01:16] <mjg59> Actually, I can't remember
[01:16] <siretart> elmo: do you have both a  'wifi0' and an 'ath0' device, or just an 'ath0'?
[01:16] <siretart> with wifi0 you are on madwifi-ng
[01:16] <elmo> siretart: I think both
[01:17] <Keybuk> elmo: comment both the auto and iface lines in /e/n/i
[01:17] <elmo> Keybuk: ah, ok
[01:17] <Keybuk> then give network manager a kick (/etc/dbus/event.d/25NetworkManager restart)
[01:24] <elmo> Keybuk: rock, thanks, that worked
[01:25] <elmo> btw, what's still blocking network manager by default?
[01:25] <Keybuk> lack of easy static configuration
[01:25] <Keybuk> tollef has a spec about it
[01:32] <siretart> elmo: and reliability. my gf is complaining that nm works only sometimes. then she uses ifup ath0=home to get her interface up
[01:32] <siretart> using ipw2100/edgy
[02:25] <siretart> how is unattended triggered after installing?
[02:29] <Nafallo> siretart: /etc/cron.daily/apt IIRC
[02:30] <Riddell> today's daily CD boots with a kernel panic saying "no init found"
[02:30] <elmo> BenC: stupid question - but something does remove /var/run/do-not-supsend, right? ;-)
[02:31] <BenC> elmo: /var/run is cleaned on reboot, right?
[02:32] <BenC> update-notifier also writes a file there for when a reboot is needed
[02:32] <BenC> err, the reboot notifier I mean
[02:32] <BenC>  /usr/share/update-notifier/notify-reboot-required
[02:33] <elmo> BenC: ah, ok, I guess it does
[02:33] <elmo> tho, interestingly I can't see where in edgy, offhand
[02:33] <siretart> Nafallo: ah, but only after enabling it by reading that file, and setting the config variable
[02:33] <elmo> /etc/init.d/bootclean only seems to clean /tmp
[02:33] <siretart> Nafallo: if you know it, good, but I think it is quite unobvious. hmm
[02:34] <Mithrandir> BenC: /var/run is a tmpfs.
[02:34] <BenC> that's right
[02:35] <Mithrandir> so, well, nothing "clears" it per se, but it's not persistent.
[02:35] <elmo> ah, then the comments in the init.d files should be fixed
[02:35] <elmo> mountall-bootclean.sh:  # Clean /tmp, /var/lock, /var/run
[02:35] <Nafallo> siretart: sure. but standard is to use unattended if installed, isn't it? :-) and there is something in some GUI somewhere :-)
[02:36] <siretart> Nafallo: no, I just installed it on dapper, and it was NOT used by default
[02:36] <siretart> Nafallo: and I didn't see any gui to enable it yet 
[02:36] <Nafallo> oh. how mean.
[02:38] <Nafallo> siretart: software-properties have a tickbox for it in feisty anyway :-)
[02:38] <siretart> Nafallo: ah, I think I found it. okay
[02:48] <iwj> Keybuk: Do you want be CC'd on mails between me and Tim Mueller about this gstreamer codec stuff ?
[02:48] <iwj> mdz is currently on the CC list.
[02:53] <Keybuk> iwj: sure, if there's something you want me to be aware of or just want it tracked
[02:54] <iwj> Oh, and is there a distro meeting today and if so (a) when and (b) it seems not to have been announced anywhere ...
[02:54] <iwj> Keybuk: I think it might be helpful.  I'll forward you the last two and CC you from now on.
[02:55] <Keybuk> ok
[02:56] <Hobbsee> iwj: by not announcing, it keeps you on your toes :P
[02:56] <iwj> Hobbsee: It might keep us on our toes tomorrow when we discover we've missed it ...
[03:00] <Mithrandir> pitti: just the man I was looking for.
[03:00] <Mithrandir> pitti: I have trouble getting hot-plugged encrypted devices to be mounted automatically.
[03:00] <Mithrandir> it sets up the dm-crypt target, but then stops.
[03:00] <pitti> Mithrandir: did you comment out the udev rule that disables the dev nodes?
[03:01] <Mithrandir> pitti: no?
[03:01] <pitti> /etc/udev/rules.d/20-names.rules, #KERNEL=="dm-[0-9] *",                   NAME=""
[03:01] <pitti> Mithrandir: ^ disable this
[03:02] <pitti> Mithrandir: it's currently disabled due to the race condition, udev-device-mapper spec will fix this
[03:03] <Mithrandir> pitti: yay, that fixed it.
[03:03] <Mithrandir> thanks.
[03:03] <iwj> So the most obvious way of automatically grabbing the gstreamer plugin metadata and dumping it into an appropriate file is a new dh_ command.  Is there anything I should watch out for when augmenting debhelper ?
[03:03] <iwj> cjwatson: ^
[03:04] <cjwatson> urgh, does it have to be a debhelper extension?
[03:04] <iwj> No, it doesn't.  Is that bad ?
[03:05] <iwj> But it will help because it really wants to write some files into the debian/<package> tree.
[03:05] <cjwatson> it's just that joeyh has been antsy about Ubuntu-specific debhelper extensions for a long time
[03:05] <cjwatson> can it go in a development package that all the relevant packages already build-depend on, rather than into debhelper core?
[03:05] <iwj> I could make it a random shell command in gst-foobar.
[03:05] <cjwatson> it could still use the debhelper libraries for uniformity; there are other programs that already do that I think
[03:06] <iwj> But you'd end up having to specify more boilerplate in the rules file.
[03:06] <iwj> Oh, really ?
[03:06] <cjwatson> (phone call, I'll get back to you)
[03:06] <Keybuk> why can't we put it into Debhelper, but name it uh_* ?
[03:06] <iwj> OK.
[03:06] <cjwatson> dh_consoledata IIRC
[03:06] <iwj> cjwatson: Will look, thanks.
[03:18] <pitti> ogra: so 2.6.20-4.5 should make us happy again \o/
[03:18] <ogra> YAY !!
[03:19] <ogra> i havent read the changelog, i'm reviewing ltsp patches the whole day already ... thanks for notifying
[03:22] <iwj> cjwatson: dh_consoledata is very helpful, thanks.
[03:25] <Hobbsee> Mithrandir: question: if a source is in main, do we have to file a MIR to get one of the binaries in main too?
[03:26] <Mithrandir> Hobbsee: no
[03:26] <Hobbsee> Mithrandir: cool.  didnt think so
[03:27] <siretart> YAY. xine-lib_1.1.3 reached the mirrors! :)
[03:28] <pitti> siretart: is that an unified source package again?
[03:28] <siretart> pitti: as discussed with the technical board, it comes with the pristine upstream tarball, read: with included ffmpeg
[03:28] <pitti> hunger: ?
[03:29] <siretart> pitti: that ffmpeg copy does only decode, however. 
[03:29] <siretart> pitti: I'll link against external ffmpeg as soon as it enters main (if it does, of course)
[03:29] <hunger> pitti: since the new OOo is in the archives (before xmas) I can not upgrade since language-support-en and language-support-de have broken dependencies.
[03:31] <pitti> hunger: ah, these are broken deps of the oo-help/l10n packages against ooo-core/common
[03:31] <pitti> doko: ^
[03:32] <doko> pitti, Mithrandir: still in NEW?
[03:32] <pitti> ah, might be
[03:32] <Mithrandir> doko: nope
[03:32] <hunger> pitti: IIRC gimp-help-de is not satisfyable in language-pack-de as well... I'll check again once aptitude is done downloading kernels:-)
[03:33] <pitti> doko: I don't see anything OO related in NEW
[03:33] <doko> pitti: then it's in feisty.
[03:34] <hunger> doko: I definitly am having the dependency problems in feisty even now:-(
[03:34] <giskard> ciao
[03:35] <Mithrandir> doko: openoffice.org-l10n-sv for instance has a Conflicts: openoffice.org-core (<< 2.0.4), openoffice.org-core (>= 2.0.4.1), this doesn't really look right?
[03:35] <doko> looking ...
[03:35] <pitti> doko: openoffice.org-l10n-de depends on openoffice.org-common (< 2.0.5), but common is 2.1.something
[03:36] <hunger> ... and -server-bigiron as well!
[03:44] <mneptok> hunger: the all-perceiving aptitude forsees new hardware purchases *handwave*
[03:45] <hunger> mneptok: Damn... I knew I shouldn't have installed the sylvester edition of aptitude;-)
[03:46] <mneptok> :)
[03:48] <bddebian> Heya
[03:49] <Mithrandir> doko: debian/rules first sets BASE_VERSION:=$(UPSTREAM_VERSION), then it's later overridden to be 2.0.4
[03:49] <Mithrandir> doko: I suspect this is the problem.
[03:50] <hunger> New feisty kernel postinst scripts fail here.
[03:50] <cjwatson> iwj: excellent
[03:52] <cjwatson> iwj: using the library should help get DH_COMPAT handling right for the most part, which is the main subtlety
[03:57] <iwj> cjwatson: Right.
[03:59] <pitti> cjwatson: the recent Australian timezone change (bug 72125) bumped the urgency of timezone-upgrades spec a bit; of course this very bug can be fixed without problems, but I think we should find a more generic solution to put the latest TZ data into all stable releases
[03:59] <Ubugtu> Malone bug 72125 in tzdata "Daylight Saving changes in Western Australia" [High,In progress]  https://launchpad.net/bugs/72125
[04:00] <pitti> cjwatson: the thing we need to do is to offer TZ reconfiguration if a TZ is removed/merged/split
[04:01] <pitti> cjwatson: the postinst currently uses tzconfig in the postinst, which is ugly and violates DP
[04:01] <cjwatson> pitti: removals are very rare, aren't they?
[04:01] <pitti> cjwatson: is there something debconf'ish (d-i like) we could use?
[04:01] <cjwatson> and merges normally leave the old one around
[04:01] <pitti> cjwatson: certainly removals are rare, but I saw TZ merges
[04:01] <pitti> and splits
[04:01] <cjwatson> but the old TZ usually remains valid
[04:02] <cjwatson> for splits, people can reconfigure from the desktop if they find that their timezone is wrong, can't they?
[04:02] <pitti> cjwatson: right
[04:02] <cjwatson> I'd be inclined not to overcomplicate the upgrade process - people notice if their computer's time is wrong
[04:02] <cjwatson> and the problems are in pretty rare cases
[04:02] <pitti> cjwatson: my feeling is that this is a rare enough special case to justify the usage of tzconfig if the current TZ doesn't exist any more
[04:02] <iwj> cjwatson: notice> But they generally try to fix it by adjusting it or reckon it's too hard.
[04:03] <pitti> cjwatson: we can detect if the set of available TZs for the user's continent has changed and ask him again, but I wouldn't do that with tzconfig
[04:03] <cjwatson> pitti: as long as the upgrade tool will do something reasonably sensible (i.e. pop up a terminal window rather than break), I'd be happy with that
[04:03] <cjwatson> pitti: d-i has tzsetup, but I don't think it's suitable for use outside d-i yet
[04:03] <pitti> cjwatson: u-mgr currently opens the terminal if the package installation doesn't proceed for 30 seconds
[04:04] <pitti> i. e. when it asks a question on the command line and expects input
[04:04] <cjwatson> I would like it to be, but it has fiddly dependencies
[04:04] <pitti> cjwatson: ok, then d-i tzsetup doesn't sound appropriate at least for stable release upgrades
[04:04] <cjwatson> not yet at least
[04:04] <pitti> cjwatson: ok, then my other idea is the following:
[04:04] <cjwatson> maybe at some point in the future
[04:05] <iwj> pitti: Couldn't you use cleverness with process groups and SIGTTIN for this ?
[04:05] <pitti> cjwatson: I write some diff magic that checks for removed TZs of two versions, prints them out, and we handle those as special cases in the postinst
[04:06] <cjwatson> I'm still inclined to ignore merges. Removals we obviously have to deal with, if they actually happen (I think they would constitute a mistake in tzdata, though). Can we detect whether splits really affect the user's timezone on a finer granularity than continent?
[04:06] <cjwatson> perhaps this is rare enough that we can just special-case everything
[04:06] <cjwatson> that might be easier than overengineering autodetection
[04:06] <iwj> cjwatson: detect> No, because the user might have selected a nearby place in the installer knowing that the timezone was the same.
[04:06] <pitti> I didn't see those splits/merges in the recent updates, but I did see them in 2006l or 2006m
[04:07] <cjwatson> iwj: seems like the sort of thing that's a lot easier to special-case when it happens (we can probably guess "nearby" closely enough)
[04:07] <cjwatson> or we could pop up a notification suggesting that people use the city chooser in g-s-t, which is pretty similar to the one in ubiquity
[04:07] <pitti> cjwatson: for feisty we might implement some more niceness, like detecting for changed TZs on your continent and adding a notification bubble that points to the Gnome TZ setup tool
[04:07] <iwj> If we knew the set of places they were offered we might be able to second-guess them since they ought to have picked somewhere close to their real location but I think this depends too much on the user having considered that the timezone might split.  That's not the kind of foresight that we should be expecting.
[04:08] <cjwatson> (in fact ubiquity's code is descended from evolution via g-s-t)
[04:08] <cjwatson> how about changing time-admin to say "if your time is wrong by some number of hours, consider making sure that your time zone is right <button>"
[04:08] <iwj> In general if any substantial bit of the territory covered by a timezone is to be split off, we should probably just ask.
[04:09] <iwj> Well, time-admin should find out whether ntp is working.  If it is then the user shouldn't be adjusting the time at all.
[04:09] <pitti> cjwatson: sounds good
[04:09] <cjwatson> iwj: yes, I just don't want to have to ask folks who chose Los Angeles time when some bit of Indiana gets split
[04:09] <cjwatson> so I think continental granularity is too coarse
[04:09] <iwj> cjwatson: Do we record that they said LA or do we reduce it to PST ?
[04:09] <pitti> cjwatson: ok, we seem to agree that handling the rare special cases in the postinst is the right thing for stable-updates
[04:09] <cjwatson> iwj: it's recorded as America/Los_Angeles
[04:09] <iwj> And indeed this is rare.
[04:10] <iwj> cjwatson: Oh, good.
[04:10] <cjwatson> oh, hang on, that might not be true for the US
[04:10] <cjwatson> for most countries we use the city zones, anyway
[04:10] <cjwatson> I forget the precise details
[04:13] <cjwatson> no, having checked, ubiquity will always record the city name. In d-i you don't have the city selector and in the case of the US we only prompt for Eastern, Central, Mountain, Pacific, Alaska, Hawaii, Arizona, East Indiana, Samoa
[04:13] <cjwatson> there are special cases for 21 countries in d-i to produce more useful timezone choices than you can get from just grepping zone.tab
[04:14] <cjwatson> (since a lot of the entries in zone.tab are only of historical interest)
[04:14] <cjwatson> pitti: yes, I think that's the easiest to audit for correctness
[04:16] <pitti> cjwatson: and as a fallback I would use the already existing tzconfig call, just to have something better than a dangling tz symlink
[04:17] <cjwatson> I'm still very surprised that tzdata would actually delete a timezone
[04:17] <cjwatson> surely they realise how much of a pain migration is (and Paul Eggert is normally pretty sensible)
[04:24] <pitti> cjwatson: ok, I checked, since breezy there actually was only one removal (America/Coral_Harbour)
[04:25] <pitti> cjwatson: so I'll just add postinst code to automatically transition this to whatever replaced it and we should be good
[04:28] <pitti> ah, merged to America/Atikokan, so this is easy
[04:30] <ph8> anyone here got #ubuntu ops? spammers ahoy
[04:39] <tkamppeter> Someone around who can introduce packages from the NEW queue into the distro? SpliX, the driver for Samsung lasers is still did not make it into the distro.
[05:26] <cjwatson> Riddell: I've moved the grub configuration stuff in ubiquity to an Advanced... dialog - I *think* the KDE frontend changes I made are pretty close, and I'll try to test them before upload if you can't, but I'd appreciate a second look
[05:31] <Riddell> cjwatson: I tried to test a daily CD this morning but it kernel paniced, I'll take a look at the bzr version now
[05:36] <twb> Mithrand1r: nag, nag
[05:56] <BenC> Keybuk: ping
[05:57] <Keybuk> BenC: yo
[05:57] <BenC> Keybuk: I have a kernel patch that implements /sys/bus/disable_auto_probe, do you want a kernel patch, or a kernel image deb to start testing udev?
[05:58] <Keybuk> image deb would be perfect
[05:59] <siretart> Riddell: do you know of anything (amarok or other stuff) which could/would be blocked for xine-lib 1.1.4?
[06:00] <Riddell> siretart: shouldn't think so, might be an idea to check that kaffeine keeps working but I see no reason why not
[06:01] <BenC> Keybuk: Ok, I'll have one on rookery for you by your morning
[06:01] <siretart> Riddell: I'm asking because I've heared that there might be an 1.1.4 release this month, in which case I'd consider it for feisty
[06:01] <BenC> Keybuk: i386 or amd64?
[06:02] <Riddell> Mithrandir: fancy doing an archive change?  libopenobex1.0 and binaries needs moved out of main and libopenobex and binaries moved in
[06:02] <Riddell> siretart: let me know when you have packages and I'll give them a test
[06:02] <Keybuk> BenC: i386
[06:03] <fbenites> hi!
[06:04] <fbenites> how does ubuntu create menu.lst?
[06:04] <fbenites> i wanted to use these routine...
[06:04] <fbenites> i want
[06:04] <BenC> fbenites: It tells you in the file :) update-grub is the program
[06:04] <siretart> Riddell: okay.
[06:07] <fbenites> BenC: where can i get the sources?
[06:07] <fbenites> i would like to build a menu, like grub does... would be it hard?
[06:08] <BenC> fbenites: The program is shell, so the source is right there
[06:09] <Riddell> Mithrandir: see my archive request?
[06:45] <pitti> is there anyone on i386 who could apport-retrace a crash report from bug 73104 for me? I only have powerpc available ATM
[06:45] <Ubugtu> Malone bug 73104 in apport "apport-checkreports crashes" [Undecided,Unconfirmed]  https://launchpad.net/bugs/73104
[06:47] <BenC> pitti: Is it possible that this was the gdb/kernel bug?
[06:48] <BenC> Oh wait, that's on edgy/2.6.17
[06:48] <pitti> BenC: in edgy?
[06:48] <BenC> not the same bug
[06:48] <pitti> ah
[06:48] <pitti> I get a lot of bugs about sigsegvs of python in apport-gtk
[06:49] <jdong> that should be on the list of things that only happen in really bad dreams ;-)
[06:49] <jdong> segfaulting python
[06:49] <BenC> pitti: I ran apport-retrace on it and it just returned with no messages
[06:50] <pitti> BenC: oh, in particular I need it run with -d
[06:50] <pitti> BenC: that will regenerate the stack trace with debug symbols
[06:50] <pitti> BenC: and perhaps with -c to remove the core dump after retracing
[06:51] <pitti> BenC: or, instead of -c, just -s for stdout output
[06:51] <BenC>   File "/usr/bin/apport-retrace", line 129, in prepare_debugdir
[06:51] <BenC>     assert ldd.returncode == 0
[06:51] <BenC> do I need to run it as root?
[06:51] <pitti> BenC: argh, that's a bug in the edgy version of apport-retrace
[06:51] <pitti> BenC: fixed in the feisty version
[06:51] <BenC> heh
[06:52] <somerville32> jdong: update-manager segfaults if you try to run it with no x environment :P
[06:52] <jdong> wow
[06:52] <pitti> BenC: ah, I just found a i386 box where I'm root, so I'll do it in pbuilder; thanks anyway
[06:53] <BenC> pitti: Ok
[06:54] <elmo> pitti: what's the magic to make a user's foreign-os partition auto-visible on the desktop?
[06:55] <pitti> elmo: mount it to /media
[06:56] <elmo> hmm, doesn't seem to do anything
[06:56] <pitti> elmo: in edgy?
[06:56] <elmo> yah
[06:56] <elmo> it's an intel mac and a hfsplus disk on a sata drive, if it makes a difference
[06:57] <pitti> elmo: ah, right, this requires a hal and a session restart because hal doesn't notice manual mounts
[06:58] <elmo> pitti: ok, tryting that, thanks
[06:59] <elmo> BenC/kylem: while I'm here, do you know off hand of bug reports about the edgy kernel panicing on boot irregularly (maybe 1/10) on intel macpro's?
[06:59] <elmo> whining about IO-APIC
[07:00] <BenC> elmo: Something about the timer?
[07:00] <kylem> i don'tbelieve i've seen a bug report offhand, but i seem to recall hearing about it before.
[07:00] <elmo> BenC: yeah
[07:00] <BenC> elmo: Yeah, it's a kernel bug that should be fixed in feisty
[07:01] <BenC> quiet the quirk, not sure we can safely backport a fix without possible regressions for other x86's
[07:03] <elmo> BenC: cool, thanks
[07:19] <BenC> Keybuk: Did you notice in 2.6.20 there's now a /sys/module/*/drivers/ sub-directory for each module?
[07:19] <BenC> with symlinks to the actual drivers for the module
[07:21] <Keybuk> yes
[07:22] <Keybuk> but that's not the most useful bit
[07:22] <Keybuk> UEVENT[1167866647.245114]  add@/bus/pci/drivers/ipw3945
[07:22] <Keybuk> ^ that's MUCH more useful <g>
[07:22] <Keybuk> (from SUBSYSTEM=="drivers")
[07:29] <BenC> sweet, it works
[07:29] <BenC> manually binded a PCI device to the ohci1394 driver with auto probe disabled
[07:30] <elmo> we had ~ support in breezy, right?
[07:30] <elmo> in version numbers
[07:33] <jdong> BenC: whoa, you can do that?
[07:34] <jdong> elmo: IIRC that worked in Warty fine too
[07:34] <jdong> elmo: so your answer is a definite yes :)
[07:34] <BenC> Keybuk: Kernel is uploading to rookery now. If you can provide me with a working udev to go with it when you get it ready, I'd appreciate it
[07:34] <BenC> jdong: Technically you can bind/unbind right now, but the auto-probe disabling is new
[07:34] <jdong> like if I have a UMS device that doesn't get detected as usb-storage, I can force-bind it?
[07:34] <BenC> no, that wont work
[07:35] <jdong> aww :(
[07:35] <BenC> you can with PCI devices, but I don't think you can do it with USB
[07:35] <jdong> BenC: is it easy to force a usb-id to be a usb-storage device @ the source level?
[07:35] <jdong> I'd like to be able to rip some firmware off a DAP in flash-mode
[07:35] <BenC> jdong: Should be a simple line or two
[07:35] <jdong> cool
[07:35] <jdong> I'll have to do that in a sec
[07:37] <BenC> Keybuk: p.u.c/~bcollins/kernels/for-keybuk/
[07:38] <somerville32> I'd like to propose demoting xchat-gnome and promoting xchat back to main because: 1) I'd like to promote an irc client (and xchat > xchat-gnome now that the usability issues have been resolved) to the xubuntu-desktop seeds 2) xchat-gnome isn't in ubuntu-desktp anymore
[07:40] <Keybuk> BenC: does the auto-probe disable probing for all subsystems, or just pci?
[07:41] <hunger> I keep getting dangling symlinks in /usr/share/man. Is there some trick to stop that? Maybe to even make sure that none end up in packages?
[07:41] <BenC> Keybuk: everything
[07:41] <BenC> Keybuk: It stops it in {driver,device}_attach
[07:41] <Keybuk> BenC: so it should be possible to bind jdong's usb device to the usb-storage driver, no?
[07:42] <BenC> Keybuk: Ah, true, it should be
[07:42] <Keybuk> it'll behave as if its probe function found that device, and carry on from there
[07:42] <jdong> cool
[07:42] <Keybuk> of course, it may fall over some check in the driver for device ids, or even hit an assert_not_reached or something <g>
[07:42] <jdong> :D
[07:43] <BenC> I wonder if bind enforces bus<->driver sanity
[07:43] <jdong> that's the fun part, Keybuk :)
[07:43] <BenC> I suspect it has to
[07:43] <BenC> Yeah, it only searches for device on the bus the driver is registered to
[07:43] <Keybuk> BenC: if you poke into bind, does it check against the driver tables ?
[07:43] <Keybuk> right, you can't bind a pci device to a usb driver
[07:43] <BenC> good, I was worried about that :)
[07:44] <Keybuk> jdong: find the usb storage device in /sys/bus/usb/devices
[07:44] <somerville32> cjwatson, ping
[07:44] <Keybuk> it'll have a name something like 1-2:2.0 and be one of the top-level symlinks
[07:44] <BenC> That's helpful too for the UI, because if someone wants to force bind a driver, I just need to check the bus, and iterate the drivers registered to it
[07:44] <jdong> Keybuk: will this require a feisty kernel? am currently not on feisty... :(
[07:44] <Keybuk> jdong: no, this will work on edgy
[07:44] <jdong>  cool
[07:45] <BenC> jdong: bind works back to dapper I believe
[07:45] <BenC> maybe even breezy
[07:45] <jdong> Keybuk: k, I'm in
[07:45] <Keybuk> jdong: does it have a product file in it that matches the device?
[07:46] <jdong> Keybuk: what kind of file am I looking for?
[07:46] <BenC> jdong: Might be easier if you identified the device from lsusb and matched it in sysfs
[07:47] <jdong> I got am in the devices folder for the correct device...
[07:47] <Keybuk> ok
[07:47] <jdong> jdong-laptop:/sys/bus/usb/devices/5-3
[07:47] <Keybuk> jdong: cat product
[07:47] <Keybuk> what does that say?
[07:47] <jdong> doesn't exist
[07:47] <Keybuk> do bInterface* files exist?
[07:47] <jdong> yes
[07:48] <Keybuk> what's the name of the directory you're in?  (pwd)
[07:48] <Keybuk> just the last bit
[07:48] <jdong>  /sys/bus/usb/devices/5-3/5-3:1.0
[07:48] <Keybuk> ok
[07:48] <BenC> Keybuk: /sys/bus/disable-auto-probe accepts [YyNnFfTt01] .* for turning it on/off
[07:48] <Keybuk> load the usb-storage module by hand (modprobe)
[07:48] <Keybuk> then (as root) echo -n 5-3:1.0 > /sys/bus/usb/drivers/usb-storage/bind
[07:48] <BenC> Keybuk: catting it will show either "true" or "false"
[07:49] <Keybuk> BenC: sweet
[07:49] <jdong> bash: echo: write error: No such device
[07:49] <BenC> check dmesg and see if the probe failed
[07:49] <jdong> no new entries in dmesg
[07:50] <BenC> I think you just use the 5-3
[07:50] <jdong> tried that too
[07:50] <jdong> same error
[07:52] <BenC> you might need to escape the :
[07:52] <jdong> ah
[07:52] <jdong> let's try :)
[07:52] <jdong> aww still no luck
[07:53] <Keybuk> BenC: reading driver_bind (at least the comment), it still checks the device's table
[07:53] <BenC> Keybuk: new_id
[07:53] <Keybuk> usb doesn't have a new_id
[07:54] <Keybuk> or does it now?
[07:54] <BenC> does for me
[07:54] <jdong> I think it does
[07:54] <jdong>  /sys/bus/usb/drivers/usb-storage/new_id
[07:55] <BenC> jdong: Try echo'ing your vendor/device id's into that file
[07:55] <BenC> you can get that easily from lsusb
[07:55] <Keybuk> BenC: I'd be really tempted to make bind a forced thing :p
[07:56] <jdong> what's the syntax for the ID?
[07:56] <jdong>  echo -n '071b:3202' > /sys/bus/usb/drivers/usb-storage/new_id
[07:56] <jdong> bash: echo: write error: Invalid argument
[07:56] <Keybuk> 071b/3202
[07:56] <jdong> oh
[07:56] <Keybuk> uh
[07:56] <Keybuk> 071b 3203
[07:56] <Keybuk> sorry
[07:56] <Keybuk> " " not "/" or ":" :p
[07:57] <jdong> yay, kernel oops!
[07:57] <BenC> sweet
[07:57] <jdong> [17202142.412000]  BUG: unable to handle kernel paging request at virtual address 773c83a8
[07:57] <jdong> whoo!
[07:57] <BenC> don't report it, I'll reject it and assign it to elmo
[07:57] <jdong> ha!
[07:57] <jdong> "kernel oops when forcing a device to bind to usb-storage" :D
[07:58] <Keybuk> Rejected: DDTT
[07:58] <BenC> technically, I think it is a bug, but it may be unavoidable
[07:58] <jdong> lol
[07:58] <jdong> I bet it's not a standard usb-storage device
[07:58] <jdong> oh well, time to get the firmware from their FTP server then
[07:59] <jdong> at a whopping 0.2KB/s
[08:01] <jdong> btw, related note...
[08:01] <jdong> is there any way in software to force an unbound USB port to pump out more current than 100mA?
[08:02] <jdong> Rockbox/iPod just leeches from the USB voltage pins without being a device
[08:02] <jdong> so it can only get 100mA of current
[08:02] <jdong> which needless to say isn't even enough to power the hard drive :D
[08:04] <iwj> Keybuk, cjwatson: Am I to take it that there is no meeting later either ?  There didn't seem to be one at 1600 and I still haven't seen any announcement anywhere.
[08:04] <Keybuk> iwj: distro-team
[08:04] <Keybuk> (no meeting this week)
[08:05] <iwj> Hmm, when was that mail sent ?
[08:05] <Riddell> cjwatson: some fixes for KDE ubiquity http://kubuntu.org/~jriddell/tmp/ubiquity.diff
[08:05] <Keybuk> ~1400
[08:06] <iwj> It's possible that I mistook it for spam.  I had many thousands ...
[08:06] <Keybuk> there seemed little point having a meeting since the general paste would be "DONE: Holiday" and we're speaking to everyone individually anyway
[08:06] <iwj> Right, that's fair enough.  I just didn't want to be AWOL :-).
[08:07] <iwj> Any time we can do without those meetings I'm in favour.
[08:07] <Riddell> cjwatson: laying out the advanced partitioner nicer, need to translate later for the URL label, couple of variable names corrected, layout fixes to last page
[08:07] <Riddell> cjwatson: let me know if I'm ok to commit
[08:10] <iwj> Ooops.  SAUCE is upset with fiordland.
[08:12] <vdepizzol> http://br.archive.ubuntu.com mirror seems not working correcly
[08:12] <vdepizzol> a lot of package are corrupted
[08:13] <mdke> vdepizzol: you can report it to mirrors@ubuntu.com
[08:39] <iwj> Ohhhh, in _this_ package I'm supposed to run automake by hand.  I'm a fool.
[09:37] <lifeless> morning
[09:38] <Nafallo> lifeless: evening :-)
[09:44] <doko> keescook: I updated the pie-support patch for gdb-6.6, seeing about 50 more test failures, however I do see these with gdb-6.5 as well ...
[09:45] <keescook> doko: I saw you did the update, thanks.  do mean the same tests failed between 6.5 and 6.6?
[09:46] <keescook> When looking at the tests from the pie update I did, it was hard to compare due to all the broken tests from the earlier lack of gnuhash support.
[09:46] <doko> keescook: I just checked the number of failures and compared the build log.
[09:46] <doko> gnuhash support should be fixed now upstream
[09:47] <keescook> right, I meant, when I tried to compare the edgy builds to the _good_ feisty builds, it was about the same.
[09:48] <keescook> did you see more failures building 6.6-0ubuntu1 than were in 6.5.dfsg-2ubuntu3 ?
[09:48] <doko> no
[09:48] <lifeless> are there any tools for determining memory use of a program effectively ?
[09:48] <neuralis> lifeless: define 'effectively'
[09:48] <doko> but with 6.6 without the pie patches, I only had 50 failures, 6.5 had at least 100
[09:49] <jdong> lifeless: oh god.... there's a kernel patch that does a better job of comparing memory usage
[09:49] <jdong> it was used in that kde vs gnome vs xfce vs fluxbox memory usage comparison blogpost
[09:49] <neuralis> lifeless: depending on what you're after, take a look at exmap (kernel module)
[09:49] <jdong> yes, exmap, that's the name
[09:49] <lifeless> neuralis: able to run around the program (to get short lived programs), and return ... lets see
[09:49] <jdong> but it seems like gauging memory usage is always a really touchy subject :)
[09:50] <lifeless> oh it is
[09:50] <keescook> doko: ah, I see what you mean, the pie support may be breaking stuff.  Yeah, that's what I meant early.  I couldn't compare non-pie vs pie on feisty because the feisty gdb didn't work at all due to the gnuhash stuff.
[09:50] <lifeless> but the folk here have spent considerable time on it
[09:50] <lifeless> ;)
[09:50] <neuralis> lifeless: alternatively, there's a visually unappealing python app that parses smaps from /proc/ to monitor memory use that a SoC student wrote for olpc
[09:51] <neuralis> lifeless: http://dev.laptop.org/git.do?p=projects/soc-memphis
[09:51] <hunger> neuralis: Would be nice to have in feisty:-)
[09:53] <somerville32> I'd like to propose demoting xchat-gnome and promoting xchat back to main because I'd like to promote an irc client (and xchat > xchat-gnome now that the usability issues have been resolved) to the xubuntu-desktop seeds
[09:53] <neuralis> hunger: well, it'd be useful if someone packaged it, yes. i don't think he knows debian packaging.
[09:53] <cassidy> somerville32: what's your problem with xchat-gnome ?
[09:54] <jdong> somerville32: first make xchat use libnotify like xchat-gnome does, and I'll comply too :D
[09:54] <mdke> somerville32: can't you have both in main?
[09:55] <somerville32> mdke: xchat was dropped because xchat-gnome was promoted but I don't see why not
[09:55] <somerville32> Crimsun said it would likely require the coordination of the promotion of xchat and the demotion of xchat-gnome to have the MIR approved for xchat
[09:55] <cassidy> xchat-gnome is a better choice for most users
[09:56] <Amaranth> woo xchat-gnome :)
[09:56] <mdke> most Gnome users, presumably
[09:56] <somerville32> xchat-gnome pulls in gnome libs
[09:57] <somerville32> Obviously that would be unacceptable in Xubuntu
[09:57] <srbaker> hey, anyone here getting impressive battery life with thinkpads?
[09:57] <srbaker> like, 6hrs +?
[09:58] <somerville32> Do you think it would be possible for them both to be in main?
[09:59] <jdong> srbaker: I have a dell P3 with dual new batteries getting 8hrs or so on average, 6 hrs when compiling
[10:22] <lifeless> cjwatson: around ?
[10:24] <lifeless> or for the floor: when two packages [e.g. binutils and binutils-multiarch]  have the same file, should both packages know about the diversion, or is it sufficient for only one to know. If only one needs to know, what about when there is no unpacking order guaranteed, do both need to know then ?
[10:29] <elmo> lifeless: it's sufficent for one to know
[10:29] <elmo> unpacking order doesn't matter
[10:29] <elmo> if b-m is unpacked first, it'll still (pre-emptively) register the diversions.  if b is unpacked first, it'll just work
[10:29] <elmo> at least, that's how I understand it to work based on observation over the years, I've not actually read the code
[10:31] <lifeless> elmo: ok, sweet. thanks. that means I can check reflexively in the analysis
[10:31] <Keybuk> hmm
[10:31] <Keybuk> how do I make the X-Chat notification icon only visible when there's a new message?
[10:33] <Nafallo> Keybuk: make a patch I would guess :-P
[10:39] <Keybuk> Nafallo: heh
[10:39] <Keybuk> I've had my fill of contributing patches to X-Chat
[10:39] <Nafallo> hmm. it doesn't blink :-P
[10:39] <Nafallo> either...
[10:47] <dthacker> hello, a few members of our LoCo team are going to do some Feisty testing tonight using the wiki testing procedures.  Is there any value in testing the latest daily build, or should we just work with the 20061025(.1) builds?
[10:55] <hunger> dthacker: I would personaly not use daily since the language support packages do not work for me (OOo seems to have some broken depends).
[10:55] <hunger> dthacker: But I am just a user. Let's see whether you get some feedback from one of the devs.
[10:58] <mdke> dthacker: the sort of people who might be able to answer your question are sfllaw, Mithrandir, cjwatson (just hilighting them in case they are around)
[11:00] <dthacker> mdke: tnx.  I'll be here for another hour or so.   
[11:06] <dthacker> hunger: it's just for testing.  We're supposed to find bugs. :)
[11:07] <sfllaw> dthacker: Reporting the latest builds are probably best.
[11:07] <sfllaw> You'll catch a lot of early breakage that way.
[11:07] <mdke> if you're looking for installer bugs, surely the latest build
[11:07] <sfllaw> Of course, you aren't putting this on production systems!
[11:07] <sfllaw> :)
[11:07] <hunger> dthacker: Well, it is hard to find bugs if the stuff does not install properly:-|
[11:09] <dthacker> sfllaw: no production machines.  should we add results to the matrix here?https://wiki.ubuntu.com/Testing/Current
[11:09] <sfllaw> dthacker: That would be a good place.
[11:09] <sfllaw> dthacker: Also, file bugs for the faults you find.
[11:09] <dthacker> can do.  Thank you for helping us. 
[11:10] <sfllaw> No no, thank you!
[11:10] <sfllaw> Without you guys, we'd be nothing.
[11:10] <mdke> hugs all round
[11:10] <dthacker> yay hugs!
[11:11] <sistpoty> did dapper have /var/run as tmpfs already, or was this introduced in edgy?
[11:12] <sfllaw> sistpoty: I'm pretty sure it was a tmpfs, but I can go back and look.
[11:12] <sfllaw> sistpoty: Is this important?
[11:12] <lifeless> the universe will end
[11:12] <sistpoty> sfllaw: for a universe sru request
[11:13] <lifeless> sfllaw: http://people.ubuntu.com/~robertc/possible-conflicts.txt
[11:13] <sfllaw> sistpoty: Lemme fire it up.
[11:13] <sistpoty> thx
[11:13] <sfllaw> lifeless: Urgh.
[11:13] <sfllaw> lifeless: (That is the sound of an aneurism.)
[11:13] <lifeless> sfllaw: packaging defects
[11:14] <sfllaw> This is cross-package?
[11:14] <lifeless> yah
[11:15] <sfllaw> Ah, that's why lintian/linda didn't catch them.
[11:15] <lifeless> yah
[11:31] <Mithrandir> Riddell: no, sorry.
[11:47] <lifeless> sfllaw: it takes 7 minutes to do an analysis run currently :).
[11:48] <lifeless> sfllaw: I'm happy with that:)
[11:48] <twb> Mithrandir: nag, nag
[11:54] <lifeless> random question, whats the smallest package anyone has seen that has diversions ?
[11:55] <doko> lifeless: dash?
[11:56] <lifeless> doko: oh, in preinst I mean
[11:56] <lifeless> where the package cant unpack unless it diverts
[11:57] <lifeless> slocate will do
[11:57] <lifeless> thanks :)
[11:58] <doko> binutils is another prominent one, creating diversions in a loop
[11:58] <lifeless> yah, I cant parse that
[11:58] <lifeless> in the not-worth-it-yet-bin
[12:01] <Mithrandir> twb: try nagging me again in nine-ten hours?
[12:01] <twb> Mithrandir: no worries
[12:02] <Mithrandir> thanks