[12:14] <superm1_> evand, http://www.mythbuntu.org/~supermario/mythbuntu/ubiquity-mythbuntu.debdiff  (Note that doesn't have any of my ideas of modularization off gtk-ui.py implemented.  If you like the idea of doing that, I'll be glad to give it a shot)
[12:16] <evand> superm1_: thanks, I'll let you know
[12:17] <superm1_> thanks evand
[12:28] <cjwatson> superm1_: that's possible but I'm really more worried about the glade file
[12:29] <cjwatson> merging that will be a right mess
[12:29] <superm1_> cjwatson, indeed
[12:29] <cjwatson> I'd like there to be a way to split the glade file up into one file per page somehow without affecting the actual layout of the UI, and that way merging would be more sensible
[12:29] <superm1_> cjwatson, is there a way around that that you thinkg can work?
[12:29] <cjwatson> but I have never got anywhere with actually doing that
[12:29] <superm1_> is it on your ubiquity roadmap though?
[12:29] <cjwatson> until that happens, I don't want radical UI changes to be merged into core
[12:30] <cjwatson> not at present, but contributions welcome
[12:30] <cjwatson> mikmorg: I am, but it's late; will you be available tomorrow?
[12:30] <superm1_> after getting the rest of our changes in, I'll see how much work that would be.
[12:31] <superm1_> cjwatson, would you be alright if we committed our package as ubiquity-mythbuntu to universe then until things are ready enough to merge to core?
[12:31] <cjwatson> superm1_: I think the rest of your changes ought to be contingent on this
[12:31] <cjwatson> superm1_: I guess so, provided package names don't clash and it's maintained as a bzr branch
[12:31] <superm1_> yes its in our bzr branch atm.
[12:32] <superm1_> for this release cycle, do you anticipate a lot of changes to the glade file?
[12:32] <cjwatson> always
[12:33] <cjwatson> my worry about ubiquity-mythbuntu (and, btw, have you run that by trademarks@ubuntu.com?) would be that it would be hard to keep it in sync with the core in the ubiquity package if packaged normally
[12:34] <cjwatson> it might be best to include the whole thing in the ubiquity-mythbuntu binary package and conflict with all the ubiquity* packages rather than doing the frontend separation thing
[12:34] <superm1_> I did a merge last night from 1.4.2 to 1.5.3 ubiquity + our changes, and it indeed was very messy
[12:34] <mikmorg> cjwatson: hi
[12:34] <superm1_> sabdfl_ gave us the ok on the mythbuntu name at the last CC meeting
[12:34] <cjwatson> ok
[12:34] <superm1_> but i haven't directly ran it by trademarks@
[12:34] <cjwatson> if sabdfl says it's ok, I doubt there's a need :)
[12:34] <mikmorg> cjwatson: sorry i was afk for a bit, i think i may have found an issue in casper, with 40install_driver_updates
[12:35] <cjwatson> mikmorg: it would not surprise me; that feature wasn't fully tested :-/
[12:35] <mikmorg> he
[12:35] <mikmorg> cjwatson: thanks.
[12:35] <cjwatson> mikmorg: place to start would be to boot with break=top, then run:
[12:35] <superm1_> cjwatson, i'll set our packaging up then to conflict with all ubiquity-* packages and provide our own ubiquity-mythbuntu-* for now
[12:35] <mikmorg> cjwatson: I'm not sure if my co. wants me to pursue this, as it wouldn't help us directly if I did.. but I may take a look off-hours
[12:36] <cjwatson> sed -i 's,/bin/sh,/bin/sh -x,' /scripts/casper-premount/10driver_updates
[12:36] <cjwatson> exit
[12:36] <cjwatson> then get hold of /var/log/casper.log after boot
[12:36] <superm1_> cjwatson, in migrating to a glade file per page, your thinking of moving away from GTKNotebook then?
[12:36] <cjwatson> superm1_: we've separately thought about moving to GtkAssistant, but I'm not sure it needs to be tied to that
[12:37] <cjwatson> superm1_: the per-page glade files could just have some kind of toplevel thing that gets stripped off at run-time
[12:37] <cjwatson> just for the sake of the interface builder
[12:37] <superm1_> ah that can make sense
[12:37] <superm1_> and then merge them all back in
[12:37] <cjwatson> right
[12:37] <superm1_> o
[12:38] <superm1_> can you put them back into a notebook that way too then?
[12:38] <cjwatson> mikmorg: failing that, if you could share the .deb you've been using to test it, we could take it from there
[12:38] <superm1_> as in copy a pygtk gtknotebook page from one glade to another
[12:38] <cjwatson> superm1_: I don't see why not; after all glade builds the notebook at run-time anyway
[12:38] <cjwatson> you take a widget and add it as a page
[12:39] <superm1_> i'll investigate this soon then.  it should be fairly feasible in this thought process
[01:05] <mikmorg> cjwatson: sorry for being afk, i was discussing the possibility of getting around it in feisty :/
[01:05] <mikmorg> unfortunately, doesn't seem like we can
[01:05] <mikmorg> not without too much pain, anyway
[01:06] <cjwatson> mikmorg: hard to say without having got far enough to know what the problem is
[01:07] <cjwatson> mikmorg: if it turns out to be a casper bug, chances are you could just build an updated initrd with a casper patch applied and remaster the CD with that
[01:07] <mikmorg> cjwatson: understood. In any case, I think I may need to file a bug
[01:07] <cjwatson> certainly
[01:07] <cjwatson> please let me know the bug number
[01:07] <mikmorg> cjwatson: respinning costs too much at this point
[01:07] <mikmorg> cjwatson: I definitely will.
[01:08] <mikmorg> cjwatson: I will also include a link to the driver disk iso
[01:08] <cjwatson> thanks, that would be perfect
[01:08] <cjwatson> sorry about this, I very much want to get it working PROPERLY for gutsy
[01:08] <mikmorg> cjwatson: So do we (dell)
[01:09] <cjwatson> aha
[01:09] <cjwatson> doubly so then :)
[01:10] <cjwatson> we can talk about solutions once we've investigated; with luck it'll be something workaroundable
[01:11] <txwikinger> Has the hugging started?
[01:11] <mikmorg> cjwatson: Thank you for your assistance.
[01:12] <cjwatson> mikmorg: no problem
[01:12] <cjwatson> Tim was actually due to come up with a test case so we could do a proper end-to-end on this
[01:13] <cjwatson> no harm in shortcutting ...
[01:16] <mikmorg> cjwatson: Where does Casper track its bugs?
[01:17] <cjwatson> mikmorg: https://bugs.launchpad.net/ubuntu/+source/casper
[01:17] <mikmorg> Thanks.
[01:26] <pygi> siretart, around?
[01:31] <siretart> pygi: yes, but not for that long
[01:31] <pygi> siretart, oki, you needed me for something while I was away
[01:31] <pygi> siretart, so fire away
[01:36] <cjwatson> txwikinger: might be a bit quiet until Europe wakes back up
[01:37] <pygi> cjwatson, but europe is awake =)
[01:38] <cjwatson> I mean without quite so much assistance from coffee
[01:39] <pygi> cjwatson, I never drink coffee? :P
[01:39] <cjwatson> it may not be Ubuntu, but in my off hours I'm making a reasonable dent in both Debian bug 18452 and Debian bug 29448
[01:39] <ubotu> Debian bug 18452 in man-db "man-db: save cat pages in background?" [Wishlist,Open]  http://bugs.debian.org/18452
[01:39] <ubotu> Debian bug 29448 in man-db "man-db: No databases for non-English man hierarchies" [Wishlist,Open]  http://bugs.debian.org/29448
[01:39] <cjwatson> maybe I will nail 18452 before its tenth birthday!
[01:40] <pygi> haha :)
[01:41] <pygi> cjwatson, it took you for years to respond to a comment :p
[01:41] <cjwatson> pygi: what, on 18452?
[01:41] <pygi> yup
[01:41] <pygi> s/for/four
[01:41] <cjwatson> pygi: in my defence, I wasn't the maintainer until 2001
[01:42] <cjwatson> and the package was in a horrible state when I took it on :P
[01:42] <pygi> cjwatson, haha :)
[01:42] <StevenK> Ahh, 2001. Back when we would upload to Debian by pushing the package uphill. Both ways. In the snow!
[01:43] <pygi> cjwatson, but 4 (!) years :P
[01:44] <txwikinger> cjwatson: I am in Europe :D
[01:45] <pygi> txwikinger, same :P
[01:45] <pygi> 1:37AM
[01:48] <cjwatson> hah, and we can now close Debian bug 50612 as well, a mere 7.5 years on
[01:49] <pygi> cjwatson, that's nothing :)
[01:49] <pygi> If it ain't more then 10 years, it's not worth the effort to close it :p
[01:50] <cjwatson> Ubuntu hasn't had time to accumulate *really* crusty bugs yet
[01:52] <pygi> then we shouldn't close any bug :P
[02:12] <pygi> good night
[03:13] <Hobbsee> wtf was uploaded???
[03:13] <mjg59> ?
[03:13] <ajmitch> hi to you too, Hobbsee
[03:13] <Hobbsee> hi ajmitch
[03:13] <ajmitch> what was that outburst over?
[03:13] <Hobbsee> my system is at 100% CPU on both cores, fan on, when usually it would be doing 2% or something
[03:13] <Hobbsee> and it's very very laggy
[03:14] <ajmitch> ah
[03:14] <mjg59> Hobbsee: top?
[03:14] <Hobbsee> cant see what it is yet
[03:14] <Hobbsee> it's normal processes - bzip2, kopete, konversatino
[03:14] <Hobbsee> but they never urn this high
[03:15] <StevenK> No DMA?
[03:15] <Hobbsee> not sure.  i didnt change it
[03:16] <Hobbsee> wow, even dpkg is at 100%
[03:16] <Hobbsee> (it's behaving like ti's got 128mb of ram or something!)
[03:16] <mjg59> Is the load being accounted to processes or to the system?
[03:17] <Hobbsee> as in, is it at CPU% or teh entire system load?
[03:17] <Hobbsee> ti's both
[03:18] <mjg59> In top, does the CPU line have high %us or high %sy?
[03:19] <mjg59> That tells you whether it's time spend in the kernel or time spent in userland
[03:19] <Hobbsee> mjg59: Cpu(s): 59.5%us, 11.8%sy,  0.0%ni, 26.1%id,  0.2%wa,  2.1%hi,  0.3%si,  0.0%st
[03:19] <mjg59> Hm. Hard to tell, then.
[03:19] <Hobbsee> impressive load averages.  top - 11:19:40 up 15 min,  1 user,  load average: 3.11, 3.92, 2.77
[03:20] <Hobbsee> i couldnt even get brandon's that high when it was building multiple blocks of kde
[03:20] <StevenK> Turn off DMA and then try it. :-P
[03:27] <Hobbsee> oookay, that's better.
[03:27] <Hobbsee> mjg59: i dont know *what* that was, but that was weird.
[03:28] <Hobbsee> doesnt take 3 seconds for any screen redraw to take place, fan isnt constantly on, and entire system isnt behaving as if it's on 128mb of ram.     yay!
[03:28] <StevenK> Hobbsee: You rebooted?
[03:28] <Hobbsee> yeah
[03:28] <Hobbsee> tried the windows solution, when nothing else became obvious
[04:35] <mikmorg_> does anyone know why apt-cdrom would hang in casper when booting? Granted, this is not on any gold CD, but I remastered Ubuntu, and added 'piix' to the initrd module loader.. as that is a CD-ROM driver, it could have something to do with it.
[04:36] <mjg59> Does it work if you don't do that?
[04:36] <mikmorg_> It seems apt-cdrom hangs as it requests a name for the CD
[04:36] <mikmorg_> the Please provide a name for this Disc prompt gets put into the casper.log file,
[04:37] <mikmorg_> mjg59: I haven't tried remastering another disk with taking my change out.. its my next step, assuming i feel like wasting another CD.
[04:37] <mjg59> If you can reproduce it without hacking the image, that's probably interesting
[04:38] <mikmorg_> hmm
[04:38] <mikmorg_> I have a golden CD that works fine
[04:38] <mikmorg_> so I'm not sure where the problem is, but I think it has something to do w/ piix being loaded.
[04:38] <mikmorg_> Which begs the question - why did they stop loading the piix driver in Feisty?
[04:39] <mikmorg_> Edgy loaded it :p
[04:39] <mikmorg_> not forcibly, albiet
[04:39] <mjg59> Because it's driven by ata_piix now
[04:40] <mikmorg_> mjg59: the answer I suspected..
[04:40] <mikmorg_> mjg59: However, I have an IDE CD-ROM that won't load in ata_piix
[04:40] <mjg59> Sounds like a kernel bug
[04:41] <mikmorg_> true, but it gets fixed again in 2.6.20-16
[04:41] <mikmorg_> of course, working with gold, i want 2.6.20-15 to work (which is why i'm attempting to backport the changes by loading the old piix).
[04:42] <mikmorg_> anyway, its messy. I was just curious if there were any undocumented concerns with apt-cdrom
[04:50] <Amaranth> mikmorg_: wouldn't it be easier to add 2.6.20-16 to your cd?
[04:50] <mikmorg_> Amaranth: yes :)
[04:50] <mikmorg_> .. but thats too easy.
[05:08] <mikmorg_> so, it seems apt-cdrom isn't stopped from potentially requesting user input in casper-bottom/41apt_cdrom
[05:08] <mikmorg_> i wonder why it asked me this time, but not on gold...
[05:08] <mikmorg_> very odd :/
[05:17] <mikmorg_> nevermind.. found it
[05:18] <mikmorg_> apparently you have to have a '.disk' directory in the root, and since its hidden, my copy must not have included that.. forcing apt-cdrom to request information it didn't get automatically :
[05:18] <mikmorg_> thanks for the tips though
[06:20] <fabbione> morning
[06:21] <Hobbsee> morning fabbione!
[08:41] <pitti> Good morning
[08:41] <shawarma> morning, pitti
[08:41] <pitti> hey shawarma, moin StevenK
[08:42] <Hobbsee> morning pitti!
[08:42] <Hobbsee> morning shawarma
[08:43] <Hobbsee> pitti: save me from the crazy people tomorrow!
[08:44] <pitti> slomo: I just kicked gstreamer, ghostscript looks good
[08:44] <pitti> Hobbsee: context?
[08:44] <Hobbsee> pitti: i have to work tomorrow.  http://community.livejournal.com/customers_suck/22067011.html
[08:44] <Hobbsee> after my exam
[08:44] <slomo> pitti: thanks
[08:44] <pitti> Hobbsee: if it comforts you, I work with crazy people every day :)
[08:45] <Hobbsee> not that type of crazy
[08:45] <crimsun> pitti is slyly implying his own sanity.
[08:46] <coNP> Hey, where is the hug day? Here or in #ubuntu-bugs? Neither topic contains this, however this topic says bug triaging in #ubuntu-bugs, whereas mailing lists say HUG day is held here...
[08:47] <pitti> coNP: here AFAIR
[08:47] <Hobbsee> either/both
[08:47] <Hobbsee> here was the new plan, iirc
[08:47] <coNP> ... seems as an endless recursion :)
[08:48] <Hobbsee> most people are in both channels
[08:48] <persia> coNP: Basically, working on bugs during hug day gets you hugs.  Talk about triage in -bugs and fixes in -devel.
[08:48] <coNP> persia: okay, thanks
[08:53] <Hobbsee> it's dholbach!  look busy, everyone!
[08:53] <dholbach> good morning
[08:53] <dholbach> HAPPY HUG DAY
[08:53] <encompass> Happy Hug Day!
[08:53] <pygi> Hobbsee, :P
[08:53] <dholbach> encompass: and the same to you!
[08:53] <pygi> Hobbsee, I am fixing all the bugs
[08:53] <Hobbsee> good :)
[08:53] <gnomefreak> if we get hugs for triaging what do we get when reporting bugs ;)
[08:54] <pygi> Hobbsee, triage k3b if you've got time then
[08:54] <Hobbsee> gnomefreak: a boot in the rear.
[08:54] <pygi> too many bugs
[08:54] <Hobbsee> gnomefreak: for every bug you file, you need to traiage at least 2.
[08:54] <persia> gnomefreak: Um.  You're going to fix it right after, right?
[08:54] <Hobbsee> pygi: i dont - exam tomorrow
[08:54] <gnomefreak> persia: sadly yes i will b working on it today
[08:54] <encompass> dholbach: thanks
[08:54] <encompass> how do I get started?
[08:55] <Hobbsee> hiya mvo
[08:55] <mvo> hey Hobbsee
[08:55] <encompass> where can I help?
[08:55] <pygi> Hobbsee, ah, oki, exam every day here
[08:57] <dholbach> encompass: https://wiki.ubuntu.com/UbuntuBugDay/20070613 might be a good start
[08:57] <slomo> pitti: built fine :)
[08:58] <pitti> yay
[09:00] <pitti> Hobbsee: customers suck> argh
[09:00] <StevenK> Heh heh
[09:03] <Hobbsee> pitti: yep
[09:03] <Hobbsee> ah there we go.  LJ cuts done.
[09:03] <Hobbsee> pitti: it keeps me sane.  at least a bit.
[09:04] <Hobbsee> morning mdke_!
[09:05] <jamesh> pitti: ping?
[09:08] <coNP> dholbach: should I edit the wikipage above if I started to triage a bug / marked package? Or only if it is donw?
[09:22] <dholbach> jamesh: good work on gnome-vfs-obexftp!
[09:23] <dholbach> jamesh: I just uploaded it to gutsy
[09:23] <jamesh> dholbach: cool!
[09:23] <dholbach> I thought it didn't work, but then I found out that I hadn't paired my mobile phone with my laptop :)
[09:24] <jamesh> dholbach: the README file now contains useful information about that, btw :)
[09:24] <pitti> jamesh: hi
[09:25] <dholbach> jamesh: ah nice ... of course I didn't read the README in advance :)
[09:25] <jamesh> pitti: does your dbgsym repository contain debug symbol packages for stuff released through feisty-security?
[09:26] <pitti> jamesh: it should now
[09:26] <jamesh> pitti: I looked in http://people.ubuntu.com/~pitti/ddebs/pool/main/p/postgresql-8.2/, but didn't see anything for 8.2.4-0ubuntu0.7.04
[09:27] <pitti> jamesh: http://people.ubuntu.com/~pitti/ddebs/dists/feisty-security/main/binary-i386/Packages.gz has a bunch of stuff, but apparently it's not complete
[09:28] <pitti> jamesh: I only fixed the treatment of pockets and multiple releases about two weeks ago; before that, some stuff did get lost unfortunately
[09:28] <jamesh> pitti: ah.
[09:29] <jamesh> pitti: I guess I can try temporarily downgrading libpq5 then
[09:31] <jamesh> pitti: or wait til the next Postgres security vulnerability :)
[09:31] <pitti> jamesh: if you only need dbg symbols for the library, that works well, yes (the client lib wasn't affected by security updates)
[09:31] <ubotu> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress]  https://launchpad.net/bugs/1
[09:32] <dholbach> varka: oh, I didn't write that list initially - I think bdmurray was that
[09:32] <dholbach> varka: but thanks for the hug :)
[09:33] <jamesh> pitti: that's useful to know.  The problem I'm tracking is just on the client side
[09:34] <pygi> Hobbsee, you evil thing! :)
[09:34] <Hobbsee> i closed 6+ yesterday
[09:34] <coNP> "What bug do you want to triage today?"
[09:34] <Hobbsee> that's not good neough?
[09:34] <pygi> Hobbsee, nop
[09:35] <Hobbsee> there was one even milestoned.
[09:35] <pygi> so? :P
[09:35] <Hobbsee> (mind you, i milestoned it :P)
[09:35] <pygi> nop,not good
[09:35] <Hobbsee> awww
[09:38] <dholbach> pitti: is there a bug open about apport (or something having to do with it) leaving ~/core files lying around?
[09:38] <pitti> dholbach: 0-byte files?
[09:38] <dholbach> yes
[09:38] <dholbach> good, just wanted to make sure you knew about it already
[09:39] <pitti> dholbach: that's with 2.6.22-6.13, right?
[09:39] <dholbach> pitti: yes
[09:39] <pitti> dholbach: it might be a fallout from bug 119267
[09:39] <ubotu> Launchpad bug 119267 in linux-source-2.6.22 "apport patches for CORE_REAL_RLIM and limit overriding do not work any more" [High,In progress]  https://launchpad.net/bugs/119267
[09:39] <dholbach> ah ok
[09:40] <pitti> dholbach: I noticed it myself, though, and it made apport's test suite fail
[09:40] <dholbach> ah ok
[09:40] <pitti> dholbach: if we get a kernel with a fix, I'll test it again and see what produces them
[09:41] <dholbach> ok super
[09:43] <bryce_> pitti, ever been to Palazzo Pitti in Florence?
[09:45] <pitti> bryce_: I don't think so :)
[09:45] <bryce_> I'm reading a history of the medici, and keep running into references to pitti palace, so I keep wondering.  ;-)
[09:46] <dholbach> pitti: but Pitt street in Sydney :)
[09:46] <bryce_> you should do what I do, when asked about any relationship to 'Bryce Canyon'.
[09:47] <bryce_> "Yes, it's named after me, of course."
 HAPPY HUG DAY!
[09:53] <Hobbsee> hiya seb128
[09:53] <Hobbsee> HAPPY FREEZING DAY
[09:53] <seb128> morning bryce_ pygi dholbach Hobbsee
[09:53] <seb128> Hobbsee: my weather applet indicates 19C, it's not freezing ;)
[09:53] <varka> Hobbsee: oh, i think my english is quite to poor to understand that article completely but thanks anyway
[09:54] <dholbach> 18C here
[09:54] <Hobbsee> seb128: it's 10C here, or there abouts
[09:54] <Hobbsee> seb128: i dont do cold weather.
[09:54] <varka> 23 degrees already here
[09:54] <`23meg> hi all
[09:54] <Hobbsee> nice...i'll swap
[09:54] <`23meg> 35C here
[09:54] <Hobbsee> hiya `23meg
[09:54] <Hobbsee> `23meg: i'm jealous.
[09:55] <seb128> Hobbsee: there is no freeze starting today, is it?
[09:55] <`23meg> hi Hobbsee
[09:55] <Hobbsee> seb128: no - just temperature
[09:55] <`23meg> Hobbsee, do you say "g'day mate"?
[09:55] <Hobbsee> seb128: unless you count Hobbsee --> FrozenHobbsee
[09:55] <seb128> :)
[09:55] <Hobbsee> `23meg: not usually together.  i'll sometimes call people mate though
[09:55] <Hobbsee> then remember that its' an aussie thing
[09:56] <bryce_> it is??
[09:56] <Hobbsee> i believe so
[09:56] <`23meg> it's the most common greeting in Australia
[09:56] <Hobbsee> of course.  we're teaching our pet kangaroos to say it, too.
[09:57] <`23meg> everyone says it all the time
[09:57] <bryce_> ah, I must just irc with too many aussies then ;-)
[09:57] <`23meg> maybe the cockatoos
[09:57] <Hobbsee> heh
[09:58] <bryce_> obviously just a consequence of staying up too late in the PST timezone ;-)
[09:58] <Hobbsee> timezones are stuffed.
[09:59] <Hobbsee> bryce_: wha'ts the current PST time?
[10:00] <Hobbsee> er, and london and german
[10:00] <Hobbsee> occasionally
[10:00] <Hobbsee> where they're listed on kclock
[10:00] <bryce_> Hobbsee: 1am
[10:00] <bryce_> hacker hour!
[10:00] <Hobbsee> yep
[10:01] <Hobbsee> ahhh.  US-type time.
[10:01] <bryce_> time to get all that funky code checked in
[10:02] <pitti> infinity: do you have an idea why http://yellow.buildd/~buildd/ddebs/20070609/ does not have the libc6 dbgsyms? (it only has one package at all); https://launchpad.net/+builds/+build/346590 shows that glibc was built at that day on yellow
[10:02] <Hobbsee> hrm.  perhaps i am colder than i realised.
[10:02] <gnomefreak> Hobbsee: is there a way to view sparc query for a package (it seems to have issue building)?
[10:03] <Hobbsee> i cant actually write a SMS
[10:03] <pitti> gnomefreak: 'view sparc query'?
[10:03] <Hobbsee> gnomefreak: as in, the sparc biuld log?
[10:03] <gnomefreak> yes
[10:07] <pitti> gnomefreak: the build logs are public, and you can even watch the builds live
[10:07] <gnomefreak> where do i find that?
[10:07] <gnomefreak> im on the source page atm
[10:07] <pitti> gnomefreak: https://launchpad.net/ubuntu/+source/<sourcepackage>
[10:07] <Hobbsee> click on the version that you want to view - the number
[10:07] <pitti> gnomefreak: click on the version you are interested in, then on the build architecture
[10:07] <gnomefreak> yeah im there it doesnt give really anything
[10:07] <pitti> gnomefreak: which package?
[10:07] <asac> pitti: i think gnomefreak wonders about the sparc backlog
[10:07] <Hobbsee> it gives you a sparc link, click on that
[10:07] <gnomefreak> maybe because its needs building
[10:07] <Hobbsee> ahhh
[10:07] <asac> is sparc fully utilized? have there been issues?
[10:07] <pitti> gnomefreak: so, please reformulate your question to be something concrete
[10:07] <asac> e.g. gnash hasn't even been touched
[10:07] <pitti> gnomefreak: you need the sparc build log of a particular package?
[10:07] <pitti> gnomefreak: or need to know which packages need to be built on sparc?
[10:07] <gnomefreak> it needs to be built for iceape
[10:07] <gnomefreak> i thought it failed but seems it just hasnt been tried
[10:07] <pitti> gnomefreak: https://launchpad.net/+builds
[10:08] <pitti> gnomefreak: both sparc buildds are just busy
[10:08] <gnomefreak> ah ok i see now
[10:09] <asac> ... building glibc :)
[10:09] <gnomefreak> yep
[10:10] <gnomefreak> ty pitti
[10:10] <pitti> gnomefreak: you're welcome
[10:23] <pitti> hi txwikinger
[10:23] <txwikinger2> hi pitti
[10:24] <fabbione> Keybuk: got a minute? i am having a very stupid issue with multipath-tools not loading dm-mod at boot time and failing to do it's job.... what's the best place now to trick these kind of things?
[10:24] <pitti> txwikinger: https://wiki.ubuntu.com/UbuntuBugDay/20070613 has some
[10:24] <txwikinger2> Yep pitti.. already there ;)
[10:25] <Keybuk> fabbione: to load at boot time?  force_load_modules in the initramfs hook is the usual way
[10:26] <fabbione> Keybuk: hmmm ok... thanks
[10:26] <fabbione> Keybuk: oh... right... nevermind.. found it..
[10:31] <fabbione> it used to be done by the initscript we killed
[10:31] <fabbione> oh feh....
[10:33] <Keybuk> fabbione | head | wall? :p
[10:33] <fabbione> Keybuk: yeah kind.. i think i just found a frigging annoying bug....
[10:33] <fabbione> the old init script took care of modprobing.. and it was ok
[10:33] <fabbione> now that we moved to udev, there is nothing modprobing it directly
[10:34] <fabbione> if not because there is other stuff loaded, like lvm2
[10:34] <fabbione> the problem shows only when you install plain multipath-tools
[10:34] <Keybuk> ahh
[10:34] <Keybuk> yeah
[10:34] <Keybuk> the whole loading of modules with unattached hardware issue is an interesting one
[10:35] <fabbione> i guess i could just load it from the udev rule...
[10:35] <fabbione> and prepare a feisty SRU... *srhug*
[10:36] <fabbione> mp-tools are not initramfs.. and they don't need to be
[10:36] <Keybuk> how would loading it from the udev rule help?
[10:41] <Keybuk> usually the udev rules don't happen until the module has been loaded
[10:41] <fabbione> the udev rules is executed each time there is a real device showing up .. like sda...
[10:41] <Keybuk> ahh
[10:41] <Keybuk> yes, that would make a lot of sense
[10:41] <fabbione> basically something like:
[10:41] <Keybuk> I've been thinking about extending 90-modprobe.rules for this case
[10:41] <fabbione> - real device appear
[10:41] <fabbione> - add it to the multipath pool
[10:41] <Keybuk> since we have sufficient vol_id information, we could optimistically load dm-mod, dm-snapshot, dm-crypt, etc.
[10:41] <Keybuk> does loading the module cause something to be created that you can hook a udev rule off?
[10:41] <fabbione> nope...
[10:41] <Keybuk> ah, so that needs working out
[10:41] <fabbione> dm-multipath is a plugin
[10:41] <fabbione> there is no extra device
[10:41] <Keybuk> because otherwise you do the modprobe, and you can't guarantee that the next command will be able to use the module yet
[10:41] <fabbione> and the devices that appear are in /dev/mapper...
[10:41] <Keybuk> is there a next command?
[10:41] <Keybuk> (to set up the devicemapper stuff)
[10:41] <fabbione> Keybuk: see /msh
[10:41] <fabbione> msg even
[10:41] <fabbione> the lines before that are irrelevant for this case (so you don't ask why there is a label ;))
[10:41] <North>  /msh
[11:15] <heno> erk, the wiki is slow and error prone for tracking bug day activity
[11:15] <heno> we need a bugday tracker ...
[11:18] <fabbione> dear world, thanks for exploding right in my face...
[11:46] <popey> I have a machine that kernel panics when I modprobe a particular module, i cant see the whole panic message because it goes off the top of the screen. i tried using "vga=ask" on boot to set mode to something higher, but part way through the boot process it gets reverted back to 80x25! Anyone know what does that and why? and more importantly how else I can capture a kernel panic message?
[11:46] <azeem> popey: serial console
[11:46] <popey> azeem: it's a laptop, there is no serial console
[11:47] <azeem> oh, wrong channel anyway
[11:47] <popey> what? me?
[11:48] <popey> azeem: so tell me, where should I ask that question?
[11:53] <pygi> siretart, morning
[11:53] <siretart> hey pygi
[12:00] <fabbione> Keybuk: it looks like that modprobing in the udev rule is fine as timing goes.
[12:00] <fabbione> now the worst thing to check... does it affect feisty too..?
[12:00] <fabbione> or this is due to a kernel behaviour change...
[12:02] <pygi> siretart, how are you doing?
[12:08] <siretart> pygi: oh, fine
[12:08] <Keybuk> fabbione: it's interesting that libdevmapper doesn't modprobe itself
[12:08] <cjwatson> pitti: I'm trying to figure out what's going on with the retrace of bug 113033
[12:08] <ubotu> Launchpad bug 113033 in openssh "[apport]  ssh crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/113033
[12:08] <cjwatson> pitti: the top frame of the broken retrace has the same address as the top frame of the original stacktrace, which is in the dynamic linker
[12:08] <cjwatson> pitti: I don't understand how it could be going wrong inside the dynamic linker like that
[12:08] <cjwatson> pitti: unless the fact that ssh is built with -fPIE in feisty is breaking retracing?
[12:11] <fabbione> Keybuk: might be a change in gutsy.. i don't remember feisty being affected by this problem.. but i am checking now
[12:11] <pygi> siretart, nice
[12:12] <pitti> cjwatson: looking
[12:13] <pitti> cjwatson: according to ProcMaps.txt, the crash is actually in /lib/ld-2.5.so
[12:15] <pochu> Happy Hug Day!!
[12:15] <pitti> cjwatson: darn, my amd64 retracer log only starts at May 21, so it's not there; I'll retrace it manually
[12:15] <pitti> cjwatson: and we lost the libc6 debug symbols for feisty unfortunately
[12:15] <cjwatson> pitti: well, /lib64/ld-linux-x86-64.so.2 -> /lib/ld-2.5.so
[12:16] <pitti> cjwatson: I made ddeb-retriever smart enough to really work with multiple releases now, before there was a race condition and manual switching involved
[12:16] <pitti> ah, right
[12:16] <cjwatson> some of the addresses in the trace are on the stack, which is weird
[12:16] <cjwatson> I wonder if it's just jumped off into oblivion
[12:16] <cjwatson> pitti: I tried retracing on ronne and got the same result
[12:17] <fabbione> Keybuk: feisty is the same.... it doesn't autoload the module...
[12:17] <pitti> WARNING: libc6-dbgsym is not available
[12:17] <pitti> whine
[12:19] <pitti> cjwatson: how much work should we invest into that crash? we could attempt to rebuild glibc in a feisty chroot to get dbgsyms which might or might not match
[12:19] <cjwatson> pitti: *shrug* it's just another on the list, nothing massively special
[12:19] <cjwatson> only reason to rebuild glibc would be if you think it might be useful for other packages
[12:19] <pitti> cjwatson: but if it is that broken anyway (IP in .stack) then it won't give us much, I guess
[12:20] <pygi> dholbach, thanks
[12:20] <cjwatson> I'll ask for reproduction on gutsy
[12:20] <shawarma> pitti: Have you asked around if someone perhaps has it cached?
[12:20] <dholbach> pygi: brasero upload?
[12:20] <pygi> dholbach, yup
[12:20] <pitti> cjwatson: desktop team isn't terribly interested in feisty crashes any more, so I didn't do anything about it so far
[12:20] <pitti> shawarma: no, I didn't
[12:20] <dholbach> pygi: no problem
[12:20] <pitti> shawarma: will do, good idea
[12:21] <pygi> dholbach, I wanted to look after it today, but since you did ... ^_^
[12:21] <pygi> dholbach, anything I could do for you?
[12:21] <cjwatson> openssh just jumped forward three upstream versions, so I guess I won't be interested for long either, but I was just going through the bug list
[12:25] <dholbach> pygi: join the HUG DAY
[12:25] <pygi> dholbach, hardly. exam soon :) But I fix bugs everyday ^_^
[12:25] <dholbach> rock
[12:25] <dholbach> :-)
[12:25] <pygi> dholbach, ^_^
[12:25] <pygi> dholbach, gabble 0.5.5 (in feisty) is pretty unstable :(
[12:25] <pygi> same with that telepathy-glib in there :(
[12:25] <dholbach> pygi: if somebody steps up to extract small and focused patches from new upstream releases, we can go through the stable release updates procedure
[12:25] <dholbach> pygi: we can't just backport all of it
[12:25] <pygi> dholbach, I understand, yea
[12:25] <pitti> shawarma: sent
[12:25] <pitti> cjwatson: so, let's wait a few days whether the dbgsyms turn up again, and then we can reattempt it
[12:28] <cjwatson> pitti: ok
[12:28] <pygi> dholbach, lemme look up malone's bug list on gabble
[12:28] <pygi> meh, one bug reported
[12:28] <pygi> I guess people file bugs against applications that use it then
[12:30] <fabbione> can somebody please add feisty-updates as milestone in LP?
[12:30] <Keybuk> fabbione: no
[12:30] <Keybuk> the bug should have a feisty task added
[12:30] <Keybuk> edit the url to include /feisty/ and click the button that appears
[12:32] <pygi> dholbach, mind re-enabling me in telepathy team pls?
[12:33] <dholbach> pygi: will you re-subscribe to the mailing list?
[12:34] <pygi> dholbach, sure, if you gimme the url to it :)
[12:34] <dholbach> http://groups.google.com/group/ubuntu-telepathy
[12:34] <dholbach> pygi: done
[12:35] <pygi> dholbach, thanks
[12:35] <pygi> dholbach, yup, I never un-subscribed
[12:35] <dholbach> ok good
[12:36] <pygi> dholbach, I hope to have an initial Fama IM release in a week or so as well
[12:37] <pygi> but we need tapioca-glib at least for that o.O
[12:37] <dholbach> there you have something to do :)
[12:37] <pygi> :P
[12:37] <pygi> law exam, that's what I have to do today :p
[12:38] <pygi> (exam in 2 hours, hehe :))
[12:38] <fabbione> hmm something is changed .. i can only nominate SRU.. before i used to be able to add Tasks directly
[12:39] <pitti> fabbione: right, weeks-old bug now
[12:39] <seb128> fabbione: yes, that has been discussed on the distro team list some weeks ago
[12:39] <sheikh> HI
[12:39] <pitti> fabbione: you need to modify the url to say ubuntu/gutsy/foo... instead of ubuntu/foo
[12:40] <fabbione> pitti: feh ok..
[12:40] <sheikh> can ne one help me to start learning ubuntu devel
[12:40] <seb128> pitti: can you accept a task this way? I though that was restricted to drivers
[12:40] <fabbione> seb128: thanks
[12:41] <pitti> seb128: yes, you can create a task with that
[12:43] <fabbione> pitti: with no rush... #120177
[12:44] <sheikh> some one out there
[12:45] <sheikh> I need a lil help regarding ubunut
[12:45] <pitti> fabbione: that looks weird; you attempt a modprobe on each and every block device addition/change? that's going to be a lot
[12:49] <pygi> dholbach, we can't yet build wilde? (or can it be built with free java stack?)
[12:50] <Keybuk> cjwatson: random Q ...
[12:50] <Keybuk> cjwatson: don't suppose you know exactly what utmp is for? :p
[12:51] <pygi> Keybuk, to find out users currently using the system?
[12:52] <dholbach> pygi: we'd need 4 java modules packaged for that
[12:52] <Keybuk> so what's wtmp for? :p
[12:52] <dholbach> pygi: you could start with java-dbus which ftbfs currently
[12:52] <Chipzz> Keybuk: utmp is log of logins, wtmp of failed logins (IIRC)
[12:52] <shawarma> Keybuk: man 5 utmp ?
[12:53] <Keybuk> shawarma: this manpage isn't helping
[12:53] <Keybuk> see ... things like w and last still seem to work
[12:53] <dholbach> pygi: and afaik telepathy-wilde has been abandoned after the SoC project
[12:53] <pygi> Keybuk, Chipzz, wtmp is a log of all login's and logout's, regardless
[12:53] <pygi> dholbach, meh, ok then :(
[12:53] <dholbach> pygi: I think that once there is a telepathy-purple we'll be better off
[12:53] <pygi> dholbach, yup
[12:53] <shawarma> Keybuk: ..yet they shouldn't , because... ?
[12:53] <Keybuk> shawarma: because I don't know what's supposed to go into utmp, so never write anything there
[12:53] <pygi> Keybuk, you aren't really supposed to leave utmp writeable
[12:54] <Keybuk> according to the utmp(5) manpage, init is supposed to be quite active in writing things there :p
[12:54] <pygi> Keybuk, mhm ... seriously, you should forbid writing there
[12:54] <pygi> a security risk
[12:54] <Keybuk> pygi: so if nothing writes to it, what's it for? :p
[12:55] <cjwatson> pygi: I think you're confusing matters; it's group-utmp-writable
[12:55] <cjwatson> obviously it shouldn't be world-writable
[12:55] <pygi> Keybuk, problem is that it's very error prone, and a lot of system programs depend on it's integrity
[12:55] <cjwatson> Keybuk: login and sshd and stuff write there
[12:55] <shawarma> Keybuk: We write to it from an init script, I think..
[12:55] <pygi> cjwatson, meh, you're right
[12:55] <Chipzz> heh ok, wtmp is all logins, btmp is bad logins
[12:55] <cjwatson> Keybuk: which is why w and last and such work
[12:55] <pygi> cjwatson, my bad
[12:55] <shawarma> Keybuk: bootmisc.sh
[12:56] <Keybuk> cjwatson: right, but what writes the logout bit?
[12:56] <shawarma> Keybuk: That script is probably doing what init used to do.
[12:56] <pygi> dholbach, no point in packaging then
[12:56] <shawarma> Keybuk: Ask inotify?
[12:57] <cjwatson> Keybuk: don't know offhand, I assumed it was done when the relevant login process exited
[12:57] <shawarma> Keybuk: Or does inotify only tell that "something" is accessing a file.
[12:57] <cjwatson> certainly sshd records logouts itself
[12:58] <cjwatson> (see loginrec.c)
[12:58] <Keybuk> yeah, I don't think login/getty do
[12:58] <cjwatson> that I don't know
[12:58] <Keybuk> if I do "last -f /var/run/utmp", gettys show up as "tty1 ... gone - no logout"
[12:59] <Keybuk> likewise for wtmp
[12:59] <cjwatson> maybe that's what init is supposed to do
[12:59] <cjwatson> seems obvious for it to do cleanup from processes that failed to exit properly
[12:59] <shawarma> Keybuk: login(1) mentions it..
[01:00] <cjwatson> login isn't responsible for clearing up
[01:00] <cjwatson> nor apparently is getty. I think init's meant to do that.
[01:01] <shawarma> cjwatson: Precisely. That's what the man page says. :)
[01:01] <Keybuk> the confusing bit about this manpage is that it lies anyway
[01:01] <Keybuk> The first entries ever created result from init(8) processing inittab(5). Before an entry is processed, though, init(8) cleans up utmp by setting ut_type to DEAD_PROCESS, clearing ut_user, ut_host, and ut_time with null bytes for each record which ut_type is not DEAD_PROCESS or RUN_LVL and where no process with PID ut_pid exists. If no empty record with the needed ut_id can be found, init creates a new one. It sets ut_id from the inittab, ut_pid
[01:01] <Keybuk> and ut_time to the current values, and ut_type to INIT_PROCESS.
[01:01] <cjwatson> shawarma: ah yes
[01:01] <Keybuk> --
[01:01] <Keybuk> sysvinit doesn't do that
[01:03] <cjwatson> sysvinit appears to do the DEAD_PROCESS thing after reading inittab but before actually executing things from there
[01:03] <Keybuk> it does DEAD_PROCESS when things die
[01:03] <pitti> hi juliux
[01:03] <cjwatson> mm, right
[01:04] <juliux> hi pitti
[01:04] <cjwatson> ./debian/changelog:1061:  * Do not try to clean up utmp in init itself (Bug#9022)
[01:04] <cjwatson> (unfortunately that bug is lost)
[01:04] <ubotu> Launchpad bug 40908 in gnome-power-manager "Sleep button puts computer to sleep" [Medium,Needs info]  https://launchpad.net/bugs/40908
[01:05] <pitti> "Unexpected error: success"
[01:05] <cjwatson> like shawarma says, I think the bootmisc.c thing supersedes what init used to do
[01:05] <Keybuk> yeah, it wipes utmp on boot
[01:06] <Keybuk> but one surely needs to attack wtmp still, otherwise there will be obsolete entries from before the reboot?
[01:06] <shawarma> Keybuk: Note that the utmp man page explicitly says it's likely to be outdated.
[01:06] <shawarma> Keybuk: BUGS section at the end.
[01:07] <shawarma> Keybuk: So you should (as you've clearly discovered) take anything in it with a grain of salt.
[01:07] <cjwatson> if there's no logout record, then things like last(1) basically look for the next reboot record and say "down" or "crash" as appropriate
[01:08] <cjwatson> that is, if there's no logout record and the entry in question predates a shutdown/reboot record
[01:08] <cjwatson> ./debian/changelog:1061:  * Do not try to clean up utmp in init itself (Bug#9022)
[01:08] <cjwatson> damn
[01:08] <cjwatson> $ last | grep reboot | head -n1
[01:08] <cjwatson> reboot   system boot  2.6.22-6-powerpc Wed Jun 13 09:56 - 12:08  (02:12)
[01:09] <Chipzz> Keybuk: last uses wtmp; if you wipe that, you can only see logins since the last reboot?
[01:09] <cjwatson> you might not be writing them, but something is ...
[01:09] <Chipzz> Keybuk: I really think you're wrong there
[01:09] <Keybuk> Chipzz: wrong where?
[01:09] <cjwatson> Chipzz: he means set them to DEAD_PROCESS not actually wipe the file
[01:09] <Keybuk> I can't be wrong, I don't know what I'm talking about
[01:09] <cjwatson> but I don't think that's necessary
[01:09] <Chipzz> Keybuk: wiping wtmp at boot
[01:09] <Keybuk> Chipzz: utmp, not wtmp
[01:09] <Chipzz> 13:06 < Keybuk> but one surely needs to attack wtmp still, otherwise there will be obsolete entries from before the reboot?
[01:09] <cjwatson> obsolete entries in wtmp from before the reboot are useful information
[01:10] <Chipzz> attack != wipe ?
[01:10] <cjwatson> they tell you that somebody was logged in when the system went down
[01:10] <Keybuk> cjwatson: good point
[01:10] <Keybuk> so, err, what writes the reboot record in the sysv wold?
[01:10] <Keybuk> world?
[01:10] <Chipzz> cjwatson: which is exactly what I was pointing out ;)
[01:11] <cjwatson> ./src/init.c:2179:                      write_utmp_wtmp("reboot", "~~", 0, BOOT_TIME, "~");
[01:12] <Keybuk> cjwatson: that happens way before any useful filesystem is writable
[01:12] <cjwatson> there's another bit that accounts for that
[01:12] <cjwatson> see src/utmp.c
[01:12] <cjwatson> also halt and shutdown write shutdown records
[01:12] <shawarma> Keybuk: Which part of reboot are you talking about? The shutting down bit, or the starting up again bit?
[01:13] <shawarma> Keybuk: Starting up is bootmisc.sh it seems. Shutting down should (hopefully) be after the filesystems are writable. :)
[01:13] <cjwatson> upstart appears to write reboot records but not shutdown records
[01:14] <cjwatson> shawarma: it's more than bootmisc.sh
[01:14] <Keybuk> cjwatson: ah, it repeatedly tries to write the reboot record every time it tries to write anything
[01:14] <cjwatson> correct
[01:14] <Keybuk> cjwatson: yeah, upstart is largely sloppy at writing anything into utmp or wtmp
[01:15] <Keybuk> the only exceptions are the runlevel and a reboot record when we switch into rc2
[01:16] <shawarma> cjwatson: Yes, I see. My bad.
[01:16] <cjwatson> damnit, having trouble finding a Debian box that has rebooted recently
[01:17] <Keybuk> (the fact that nobody's actually noticed that it's pretty bad at it makes me think that nobody *really* uses (or trusts) this stuff :p)
[01:17] <Keybuk> cjwatson: I'm comparing with a dapper box
[01:18] <Keybuk> coNP: s/no/no known/
[01:18] <coNP> no untriaged = no reported AND untriaged, of course, unreported bugs cannot be triaged at all :)
[01:18] <Keybuk> cjwatson: it strikes me that, at the least, upstart should have the ability to maintain a utmp record for a job
[01:19] <cjwatson> yeah, clean reboots in sysvinit-land seem to have a shutdown record followed by a reboot record
[01:19] <cjwatson> unclean reboots just have a reboot record
[01:19] <Keybuk> ie. "utmp 1" in the job file means you'll get INIT_PROCESS when that job is spawned and DEAD_PROCESS when it dies
[01:19] <Keybuk> (for a ut_id of "1")
[01:19] <fabbione> pitti: only the first time is "slow".. once the module is loaded, it's not an issue.
[01:20] <cjwatson> and last(1) tells the difference between "down" and "crash" by looking for shutdown records
[01:20] <fabbione> pitti: and you don't know if the module has been unloaded when you get the "next" block device
[01:20] <cjwatson> so the visible difference in Ubuntu is likely that you'll never see last(1) saying "crash"
[01:20] <fabbione> pitti: so no matter.. you need to make sure it's there for multipath to work
[01:20] <Keybuk> pitti: *shrug* we attempt a modprobe on each and every device change, pretty much <g>
[01:20] <pitti> fabbione: (see my comment in the bug)
[01:20] <fabbione> pitti: doing so
[01:20] <pitti> fabbione: why do we need to be concerned about module unloading? that doesn't ever happen automatically AFAIK
[01:21] <Keybuk> cjwatson: but it does :-/
[01:21] <fabbione> pitti: no it does not happen automatically but let say that you do something manually and you replug a SAN (hotswappable disks) you want to make sure it's loaded and working properly
[01:21] <Keybuk> cjwatson: you mean last should always say "crash" and not "down", no?
[01:21] <Keybuk> since we never have a shutdown record
[01:22] <cjwatson> sorry, yeah, that's what I meant. but that appears not to be the case
[01:22] <pitti> fabbione: but if someone manually rmmods, then he certainly has a reason to?
[01:22] <fabbione> pitti: i also don't want to use /etc/modules.. see /etc/udev/rules.d/90-*
[01:22] <cjwatson> ah
[01:23] <cjwatson> last also interprets recorded transitions to runlevels 0 and 6 as indicating clean shutdowns
[01:23] <pitti> fabbione: so, if Keybuk as our udev expert is happy with the modprobe hammering, I'm good; but I at least want to understand it :)
[01:23] <fabbione> pitti: that happens no matter what.. like Keybuk says.. we do it for other stuff too and it seems to be ok
[01:23] <Keybuk> cjwatson: it does, where do you see that?
[01:24] <Keybuk> pitti: modprobe is cheap in the already loaded case - since it checks whether it's already loaded - same cost as doing the same check in udev
[01:24] <cjwatson> Keybuk: search for SHUTDOWN_TIME, third occurrence
[01:24] <fabbione> pitti: i did try a boot with sd[a-z]  and root on sdr to test this... no matter how fast i could login there were no modprobe processes hanging around
[01:24] <cjwatson> so 'last -x' on Debian goes:
[01:24] <cjwatson> runlevel (to lvl 2)   2.6.18-4-amd64   Tue Jun  5 10:53 - 10:15 (1+23:22)
[01:24] <cjwatson> reboot   system boot  2.6.18-4-amd64   Tue Jun  5 10:53 - 10:15 (1+23:22)
[01:24] <cjwatson> shutdown system down  2.6.18-4-amd64   Mon Jun  4 15:45 - 10:53  (19:07)
[01:24] <cjwatson> runlevel (to lvl 6)   2.6.18-4-amd64   Mon Jun  4 15:45 - 15:45  (00:00)
[01:24] <cjwatson> while 'last -x' with upstart goes:
[01:24] <Keybuk> cjwatson: in last.c ?
[01:24] <cjwatson> runlevel (to lvl 2)   2.6.22-6-powerpc Wed Jun 13 09:56 - 12:23  (02:27)
[01:24] <cjwatson> reboot   system boot  2.6.22-6-powerpc Wed Jun 13 09:56 - 12:23  (02:27)
[01:24] <cjwatson> runlevel (to lvl 0)   2.6.22-6-powerpc Wed Jun 13 04:41 - 09:56  (05:14)
[01:24] <cjwatson> Keybuk: yeah
[01:24] <Keybuk> cjwatson: which last.c? :p
[01:25] <cjwatson> Keybuk: sorry, I mean fifth occurrence. sysvinit/src/last.c c line 783
[01:25] <cjwatson> s/c line/c. line/
[01:25] <Keybuk> ohh, I was looking at the one in util-linux
[01:25] <Keybuk> d'oh
[01:26] <iwj> It's been slightly broken at least since pam because the pam people didn't know either.
[01:26] <pitti> fabbione: ok, bug updated
[01:26] <cjwatson> I'm not sure util-linux's version is complete
[01:26] <fabbione> pitti: ehhe ok thanks :)
[01:26] <cjwatson> it's certainly a lot less readable :)
[01:27] <iwj> You should definitely write a dead record when a getty/login ends.
[01:27] <iwj> And NB that utmp is a weird fixed-record concurrent-access database.
[01:28] <iwj> You must never change what a particular slot in utmp refers to.
[01:29] <txwikinger2> thanks varka :)
[01:34] <cjwatson> hmm, whoops, creating /dev/loop1 as a character device doesn't work so well
[02:32] <WB|Diego> ^^
[02:33] <WB|Diego> All developers were great, I love you all
[02:33] <WB|Diego> Good work
[02:34] <WB|Diego> Further so !
[02:34] <WB|Diego> THX
[02:45] <seb128> fabbione: why did you subscribe ubuntu-archive to bug #120177?
[02:45] <ubotu> Launchpad bug 120177 in multipath-tools "dm-multipath not autoloaded causes multipath to fail" [Undecided,In progress]  https://launchpad.net/bugs/120177
[02:46] <seb128> fabbione: do you want ubuntu-sru?
[02:46] <fabbione> seb128: there is already ubuntu-sru...
[02:46] <pitti> seb128: he does, yes
[02:47] <fabbione> he upload will be reviewed by the SRU archive administrators during regularly scheduled processing, and approved if it meets the above criteria. Archive administrators should verify that the package delta matches the debdiff attached to the bug report.
[02:47] <fabbione> The ubuntu-archive team member who accepts the package into -proposed should:
[02:47] <fabbione> this is from SRU...
[02:47] <fabbione> it mentions ubuntu-archive specifically
[02:47] <pitti> fabbione: for subscription it only mentions -sru
[02:47] <pitti> but no big deal
[02:48] <fabbione> ok...
[02:48] <seb128> right, just wondering because usually ubuntu-archive is not subscribed and I'm not sure of what I was supposed to do on the bug
[02:48] <seb128> I'll let it to pitti
[02:48] <fabbione> seb128: ok.. i thought i had to sub it..
[02:48] <fabbione> seb128: my bad..
[02:48] <seb128> fabbione: that's alright ;)
[02:58] <pitti> heno: the list of possible actions on the wiki page should include searching for and marking as dup
[02:59] <heno> pitti: you mean on the hug day page?
[02:59] <pitti> yes
[03:00] <heno> pitti: The idea is to just present a subset of possible triage activities to start with. The theme might change for next time
[03:00] <fabbione> later guys
[03:00] <heno> pitti: Brian has been selecting these themes
[03:01] <Hobbsee> evening calc
[03:01] <pitti> heno: I mean the "To mark it off the list you should:" list
[03:01] <heno> I happen do be doing something completely different today; closing 'fixed elsewhere bugs'
[03:01] <heno> pitti: ok, I'll look
[03:03] <heno> pitti: got you now. fixed, thanks
[03:04] <pitti> heno: thanks
[03:08] <pitti> heno: erk, sorry, I broke your lock
[03:08] <pitti> heno: I added the dup marking to the second list, too
[03:08] <Hobbsee> superm1_: cjwatson: what does mythtv-ubiquity bugs get filed under?
[03:11] <evand> hrm/t
[03:11] <evand> whoops
[03:12] <calc> Hobbsee: good morning ;)
[03:22] <dholbach> keescook, seb128, doko: ok if I make somebody of you admin of ubuntu-main-sponsors?
[03:23] <seb128> dholbach: what is the job about? ;)
[03:23] <ogra> hmm, no seveas
[03:23] <dholbach> seb128: approving ubuntu-core-dev members who apply
[03:23] <ogra> dholbach, you are CC as well ?
[03:23] <dholbach> ogra: yes
[03:24] <ogra> dholbach, can i kindly ask for renewal of my membership before it expires ?
[03:24] <seb128> dholbach: isn't that TB job? ;)
[03:24] <dholbach> seb128: ubuntu-core-dev is a requirement, before somebody wants to join ubuntu-main-sponsors
[03:25] <seb128> dholbach: ah, alright
[03:25] <seb128> dholbach: you can make me admin if you want
[03:25] <dholbach> seb128: it's just that pitti left the team and we should have backup admins
[03:25] <seb128> dholbach: alright
[03:26] <dholbach> seb128: thanks seb128
[03:26] <seb128> you're welcome
[03:27] <pitti> dholbach: sorry for that, but I haven't been active in that team for months; ENOTIME :/
[03:28] <dholbach> pitti: that's what I guessed - no problem
[03:31] <emanuel__> hi
[03:31] <calc> dholbach: happen to know when the next CC meeting will be?
[03:37] <evand> Hobbsee: as there's no source package for mythbuntu, perhaps just tag it and we'll deal with it when there is one.
[03:37] <superm1_> Hobbsee, atm the Mythbuntu project on launchpad
[03:37] <Hobbsee> evand: i stuck it under ubiquity
[03:37] <evand> ok
[03:37] <StevenK> calc: Does http://fridge.ubuntu.com tell you?
[03:37] <dholbach> calc: no, to be honest - I'll mail community-council and ask for a new date
[03:37] <pitti> shawarma: bug 19889 approved for SRU, please upload
[03:37] <ubotu> Launchpad bug 19889 in sysklogd "sysklogd: Large file support is broken in dapper" [Medium,In progress]  https://launchpad.net/bugs/19889
[03:37] <dholbach> calc: I'll let you know
[03:38] <calc> dholbach: ok thanks :)
[03:38] <calc> StevenK: no that was the problem ;) it has been over 2 weeks since the last one and no date is set yet
[03:39] <StevenK> Ahh, right
[03:39] <shawarma> pitti: Which version should I give it? The wiki page is a little vague with regard to that.
[03:41] <shawarma> pitti: It's currently 1.4.1-17ubuntu7.
[03:42] <shawarma> pitti: There's not 1.4.1-17ubuntu8.. Should I make it 1.4.1-17ubuntu7.1 for -proposed and bump it to ubuntu8 for -updates (when the time comes) ?
[03:44] <superm1_> cjwatson, I toyed with separating the glade file into multiple parts yesterday, and almost have it done - but is there a cleaner way of copying a widget over to the notebook than using unparent()?
[03:48] <cjwatson> superm1: not sure, not an expert
[03:48] <superm1> cjwatson, okay i'll continue to poke around then.
[03:48] <Chipzz> superm1: also not an expert but I think not
[03:50] <reic> i wanna hug some1, is there anything solved yet? ^^
[03:50] <superm1> Chipzz, there was a warning in the API saying that the function is only intended for use in child classes that redefine the parent, so wanted to make sure
[04:12] <dholbach> ogra: new gnome-power-manager
[04:23] <pitti> shawarma: ubuntu8 or 7.1 is both fine
[04:23] <pitti> shawarma: and we don't do -updates uploads any more, so it won't change there
[04:23] <shawarma> pitti: Huh? Where does it get uploaded to ten?
[04:23] <shawarma> then*
[04:23] <pitti> shawarma: it doesn't, it's copied verbatim from -proposed
[04:23] <pitti> shawarma: new soyuz tool 'copy-package'; I announced that the other day on u-d-a
[04:25] <shawarma> pitti: Where? Can't find it in the ml archive..
[04:25] <pitti> shawarma: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-May/000288.html
[04:25] <shawarma> pitti: got it.
[04:26] <pitti> shawarma: the wiki page is also updated, so above mail is not that important
[04:27] <shawarma> pitti: Well, if you (like me) thought we still did the no-change re-upload dance, it's vital information. :)
[04:28] <shawarma> pitti: Otherwise I'd just think the wiki page was missing that bit of info.
[04:29] <pitti> shawarma: hm, which part do you think is unclear? I'm all for deconfusing it
[04:35] <shawarma> pitti: I'm not sure. Maybe I'm just trying to do too many things at once..
[04:36] <shawarma> pitti: How about DebianMaintainerField? Should I implement that in this package?
[04:37] <pitti> shawarma: not for dapper, only for feisty and upwards
[04:37] <pitti> CRaMLiNG: *hug*
[04:38] <Hobbsee> hiya CRaMLiNG  :)
[04:38] <CRaMLiNG> thanks for that great OS =)
[04:38] <shawarma> pitti: Alright. Wasn't sure if it was distro specific or "time of upload" specific.
[04:39] <pitti> shawarma: we didn't test the dapper package tools with XSBC-, and in fact there is one known bug in dpkg, so we mustn't take the risk
[04:44] <shawarma> pitti: Alright.
[05:00] <racarr> Err. I forget
[05:00] <racarr> what is the option to make focus not follow mouse?
[05:00] <mvo> racarr: in metacity? or compiz :) ?
[05:00] <racarr> oh
[05:00] <racarr> wrong channel -_-
[05:00] <racarr> I thought I was in #opencompositing-dev :P
[05:00] <mvo> heh :)
[05:21] <pitti> mvo: hmm @ bug 107431: I thought this was already handled in some SRU?
[05:21] <ubotu> Launchpad bug 107431 in update-manager "cdromupgrade calls gksu" [High,Fix committed]  https://launchpad.net/bugs/107431
[05:23] <mvo> pitti: yes, I close it
[05:24] <mvo> pitti: well, it is fixed in gutsy at least.
[05:27] <mikmorg> hello.
[05:27] <bdmurray> mikmorg: hello
[05:28] <boenki> hello! If someone really wants to get hugged, can you fix this anyoing bug finally!? https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/85216
[05:28] <ubotu> Launchpad bug 85216 in gnome-panel "gnome-desktop-item-edit should change the Name= key" [High,Confirmed]
[05:29] <zasf> hi all
[05:29] <mikmorg> does anyone know where the /target path in casper/ubiquity gets created/mounted?
[05:29] <zasf> pitti:Hi Martin
[05:30] <boenki> or could someone just assign the above mentioned bug to the right people!?
[05:31] <seb128> heno: I have dropped 34_at_properties_onboard_and_new_interface.patch and 81_get_rid_of_orca_main_window.patch from the gnome-control-center 2.19.3 update, upstream changed quite some code and nothing apply. Could anybody from a11y look if they are still required and should be rewritten or something?
[05:31] <boenki> I wonder if they know about it at all, cause it doesn't seem to be to difficult to fix
[05:31] <pitti> zasf: hi
[05:31] <iwj> Seen elsewhere:
[05:32] <iwj> 16:17 <iwj> 16:17 <steph> Hm.  This atomic force microscope controller has Kubuntu embedded in it.
[05:32] <zasf> pitti: are you busy? I'd like to chat a bit about r-d-m
[05:32] <heno> seb128: I'll have a look
[05:33] <pitti> zasf: reasonably; what's r-d-m?
[05:33] <seb128> heno: thank you
[05:33] <seb128> desrt: around?
[05:33] <zasf> pitti: restricted drivers manager
[05:33] <zasf> pitti: I did some coding for fun, I'd like to know what you think
[05:33] <zasf> pitti: I wrote you an email and got no feedback
[05:34] <pitti> zasf: oh, weird, when?
[05:34] <seb128> pitti: if you have a minute could you look at compizconfig-binding in NEW? I've packaged it so I would prefer having somebody else doing the NEWing
[05:34] <seb128> pitti: it's a small an easy one
[05:34] <zasf> pitti: last week
[05:34] <pitti> seb128: right, will do
[05:34] <seb128> danke
[05:35] <mikmorg> Has anyone here done any testing/writing of the driver update system in casper?
[05:37] <evand> mikmorg: cjwatson wrote it.  I don't think anyone's tested it yet :)
[05:38] <mikmorg> evand: ok, thanks
[05:38] <mikmorg> seems i am the first :p
[05:41] <pitti> seb128: indeed, small and nice; accepted
[05:41] <seb128> pitti: danke
[05:41] <keescook> dholbach: if you don't already have enough ubuntu-main-sponsors admins, feel free to add me.  :)
[05:42] <pitti> seb128: are you doing some other source NEW today? I'll do some on Friday, but the current queue is so long, I won't manage this alone
[05:42] <pitti> morning keescook
[05:42] <seb128> pitti: yes, will do some now
[05:42] <keescook> hiya pitti
[05:42] <seb128> pitti: I wanted to get GTK+2.11 uploaded first, which is done now ;)
[05:42] <Riddell> iwj: wow
[05:42] <seb128> hey keescook
[05:42] <dholbach> keescook: done :)
[05:43] <keescook> hiya seb128 :)
[05:43] <keescook> dholbach: so to approve folks, it's just a matter of    if user in ubuntu-core-dev: approve   ?
[05:43] <iwj> Riddell: Thought you might like to hear that one :-).
[05:44] <keescook> bdmurray: so, we're hanging out in here or u-bugs for hug day?
[05:44] <dholbach> keescook: yes
[05:44] <bdmurray> keescook: that is correct
[05:45] <dholbach> keescook: being ubuntu-core-dev means that they should roughly know what they do, so it should be fine, if they propose themselves :)
[05:46] <evand> mikmorg: what's the problem?
[05:47] <mikmorg> evand: actually there are 2
[05:47] <bdmurray> seb128: could you look at the valgrind log in bug 114678?
[05:47] <ubotu> Launchpad bug 114678 in Ubuntu "memory corruption on ubuntu 7.04" [Undecided,Needs info]  https://launchpad.net/bugs/114678
[05:47] <mikmorg> evand: casper and ubiquity both make the mistake of not installing the deb packages which are imported into /var/cache
[05:47] <seb128> bdmurray: looking
[05:48] <mikmorg> the code is there, but its broken
[05:48] <mikmorg> seems that chroot is misused in both cases, although i've only really looked at casper
[05:48] <mikmorg> evand: I'll let you know the bug # when I'm done w/ the writeup
[05:49] <cjwatson> mikmorg: /target is mounted by the partitioning in ubiquity
[05:49] <cjwatson> s/partitioning/partitioner/
[05:49] <seb128> bdmurray: the log is a debug one and shows an error
[05:49] <evand> mikmorg: I was just going to ask :)
[05:49] <seb128> bdmurray: but "/usr/local/bin/mu-mh/folders" is not an Ubuntu package, it's a local build
[05:50] <mikmorg> cjwatson: good morning, and thanks.
[05:50] <cjwatson> mikmorg: I'm not seeing what's wrong with casper's use of chroot, but maybe I'm blind
[05:50] <boenki> I'll just ask again if someone can have a look in https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/85216
[05:50] <ubotu> Launchpad bug 85216 in gnome-panel "gnome-desktop-item-edit should change the Name= key" [High,Confirmed]
[05:50] <seb128> bdmurray: I'll comment on it
[05:50] <bdmurray> seb128: okay, thanks
[05:50] <seb128> you're welcome
[05:51] <mikmorg> cjwatson: it has me looking hard, too.. the paths are definitely messed up though.
[05:51] <cjwatson> mikmorg: how so?
[05:52] <mikmorg> cjwatson: It is looking for /var/cache/driver-updates//root/var/cache/driver-updates/tg3_i386.deb, on line 35 of 40install_driver_updates in casper-bottom
[05:52] <mikmorg> (where obviously, the file resides as /var/cache/driver-updates/tg3_i386.deb)
[05:53] <cjwatson> oh!
[05:53] <cjwatson> argh, good catch
[05:53] <evand> heh
[05:53] <mikmorg> thank you.
[05:53] <cjwatson> I can fix that
[05:54] <mikmorg> I'll go ahead and report the bug - however,
[05:54] <mikmorg> I believe the bug is two-headed
[05:54] <cjwatson> sure, it may well have a couple of bits
[05:54] <mikmorg> Ubiquity doesn't seem to install it either
[05:54] <cjwatson> yes, the code in casper/ubiquity-hooks/40install_driver_updates is nearly identical and needs the same fix
[05:54] <mikmorg> i was just investigating that part of it
[05:54] <mikmorg> yes, i assumed that was the case
[05:55] <mikmorg> so i'll report the bug immediately, seeing as how not much more needs said.
[05:56] <cjwatson> mikmorg: do you have a bzr checkout of casper there?
[05:56] <mikmorg> bug #120217
[05:56] <ubotu> Launchpad bug 120217 in casper "Driver Updates not being installed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120217
[05:56] <mikmorg> cjwatson: yes
[05:57] <cjwatson> I'll check in a proposed fix in just a minute or two, then
[05:57] <mikmorg> great, thank you.
[05:58] <mikmorg> I'll test it for you, however, i will just quickly remaster an already exploded iso instead of rebuilding casper
[05:58] <cjwatson> mikmorg: even better
[06:03] <seb128> ogra: there is a new gnome-power-manager available
[06:04] <ogra> seb128, yes, thanks dholbach already pinged
[06:04] <seb128> k
[06:05] <seb128> you're welcome ;)
[06:05] <seb128> I forgot that dholbach is polling on the update list quite often ;)
[06:06] <cjwatson> mikmorg: ok, committed, revision 386
[06:06] <cjwatson> mikmorg: greatly appreciate you testing it out
[06:07] <cjwatson> mount: Mounting /cdrom on /root/cdrom failed: Invalid argument
[06:07] <cjwatson> that's odd
[06:08] <cjwatson> though actually it's probably because we already did mount -o move earlier
[06:14] <mikmorg> cjwatson: great, I'll get testing.. it'll take a while for me to transfer files to my network though.
[06:16] <mikmorg> cjwatson: i am not familiar with bzr... could you tell me how i can diff head to last?
[06:17] <mikmorg> nevermind.. i think i got it
[06:17] <bdmurray> cjwatson: I noticed that the initramfs doesn't include fdisk yesterday is there a reason?
[06:17] <seb128> mjg59: xserver-xorg-video-avivo include/radeon_reg.h is "Copyright 2000 ATI Technologies Inc., Markham, Ontario, and VA Linux Systems Inc., Fremont, California." but that's not mentioned in debian/copyright
[06:18] <seb128> mjg59: "avivotool/xf86i2c.c: * Copyright (C) 1998 Itai Nahshon, Michael Schimek" also
[06:22] <desrt> seb128; hey.  what's up?
[06:23] <seb128> desrt: hey, is the gdk compositing example supposed to work correctly on gutsy with GTK 2.11.2 or does it need some xorg patching?
[06:23] <mikmorg> cjwatson: I also have a couple enhancement requests from my team.. I will be posting them on launchpad today. Thanks for all of your help.
[06:23] <desrt> seb128; xorg patching
[06:23] <desrt> seb128; and some cairo patching, probably :)
[06:23] <seb128> desrt: it displays a red border and the content of the bottom layer on my desktop
[06:23] <seb128> but not on a button, and it's not refreshed correctly
[06:24] <desrt> can you get me a screenshot, maybe?
[06:24] <desrt> i'd expect it to simply display one of those regions that looks like the app died
[06:24] <desrt> like a non-refreshing show-what-was-there-before thing
[06:24] <desrt> if that's the case then you're dealing with an X server that needs to be patched
[06:25] <seb128> desrt: alright, your description matches the behaviour
[06:25] <seb128> desrt: do you have a pointer to the xorg upstream patch maybe? ;)
[06:25] <seb128> and to the cairo changes we need
[06:25] <desrt> keith wrote xorg-list saying he was merging the patch
[06:25] <desrt> but then he didn't
[06:26] <desrt> and then he disappeared
[06:26] <seb128> ah, k
[06:26] <seb128> I read that he was going to merge it
[06:26] <desrt> cairo changes are trivial.  one moment.
[06:26] <seb128> and I though it was done
[06:26] <seb128> thanks
[06:26] <desrt> i think behdad might have even merged the cairo changes last night
[06:26] <desrt> http://bugs.freedesktop.org/show_bug.cgi?id=10329  <-- cairo
[06:26] <ubotu> Freedesktop bug 10329 in xlib backend "add support for "recursive" xlib surfaces" [Normal,New]
[06:27] <cjwatson> mikmorg: head to last?
[06:27] <desrt> http://lists.freedesktop.org/archives/xorg/2007-March/022423.html  <-- xorg
[06:27] <cjwatson> bdmurray: probably just nobody came up with a good use for it yet. I think rescue mode and/or the live CD is better than trying to do that in the initramfs, TBH
[06:28] <cjwatson> mikmorg: 'bzr diff -r385..386' gives you just that revision, though
[06:28] <mikmorg> cjwatson: thanks.
[06:28] <desrt> seb128; that previous patch was for 7.1
[06:28] <desrt> an improved (ie: bigger?) patch for 7.2 is here: http://lists.freedesktop.org/archives/xorg/2007-March/022668.html
[06:29] <seb128> desrt: ok, thanks
[06:29] <desrt> http://lists.freedesktop.org/archives/xorg/2007-April/024218.html
[06:30] <desrt> ^ keith saying he's merging it (???)
[06:30] <mikmorg> cjwatson: maybe you could tell me what you think of these ideas before i post them
[06:30] <bdmurray> cjwatson: What happened to me was my md arrays were not all started and I wasn't positive which partitions needed to be added.
[06:30] <mikmorg> cjwatson: (even though I probably still will ;)
[06:30] <mikmorg> We also should file a new launchpad bug, enhancement request, to allow updated installer files to come from that same driver CD.  That way, we can patch the gold CDs at runtime with the driver CD.  Red Hat does this with their anaconda updates.img media.
[06:31] <mikmorg> and my favorite..
[06:31] <mikmorg> We also should file yet another new launchpad bug, enhancement request, to allow that driver/updates CD to be a USB key. :-)
[06:34] <cjwatson> mikmorg: first scares the willies out of me but I can see how it'd be useful
[06:34] <calc> what is the status of the hardware database getting a frontend, etc?
[06:35] <cjwatson> mikmorg: second seems entirely sensible
[06:36] <mikmorg> cjwatson: yes, the first would have been useful in cases such as this one
[06:37] <mikmorg> cjwatson: the idea of being able to manually overcome any problem in the installation process
[06:37] <pygi> hey
[06:37] <mikmorg> (without remastering)
[06:39] <cjwatson> mikmorg: yeah, though updating casper on the fly from inside casper could be tricky
[06:39] <cjwatson> in excelsis
[06:40] <mikmorg> cjwatson: agreed
[06:41] <mikmorg> cjwatson: how about adding a scripts/casper-hooks folder, which a 3rdparty could install debs into
[06:41] <mikmorg> that would be run right before casper-bottom
[06:42] <mikmorg> the driver disk could be checked for a 'casper-hooks' folder
[06:42] <cjwatson> so, ideally there'd be something run before *sourcing* casper-bottom
[06:43] <cjwatson> then scripts in there could sed -i /scripts/casper-bottom/blah on the fly
[06:43] <mikmorg> exactly
[06:43] <cjwatson> and yes, maybe have /scripts/casper-premount/10driver_updates copy scripts over from a defined directory on the update image
[06:43] <mikmorg> as long as casper-bottom is read OTF, after casper-hooks runs, there shouldn't be any problem
[06:43] <cjwatson> and .debs
[06:44] <cjwatson> it is
[06:44] <cjwatson> sorry, I thought they were sourced for some reason, but they're not, they're just called. so that's ok
[06:46] <mikmorg> cjwatson: great. I'll post them in a bit. I'm burning the remastered Feisty right now
[06:46] <cjwatson> mikmorg: would supplying updated .debs be a reasonable approach for you, in general?
[06:47] <mikmorg> cjwatson: what kind of .deb are you suggesting?
[06:47] <cjwatson> mikmorg: in this case, say, a fixed version of ubiquity-casper
[06:48] <mikmorg> cjwatson: I'm not sure what "ubiquity-casper" encompases
[06:48] <cjwatson> anaconda's updates.img apparently just has you supply *.py files in a flat directory structure, but our installer is a bit more modular than that
[06:48] <cjwatson> mikmorg: ubiquity-casper is where the ubiquity-hooks scripts go; it's installation hooks for ubiquity supplied by casper
[06:49] <mikmorg> cjwatson: Ok, I thought that might be true. The only issue is, the hooks I'm suggesting would possibly require running before casper-bottom
[06:49] <cjwatson> (the concept is that if you were running ubiquity on top of a different live CD infrastructure, you could theoretically have that infrastructure provide hooks to repeat the appropriate bits of hardware configuration in the installed system; not that anyone's done this with anything other than casper AFAIK)
[06:49] <cjwatson> mikmorg: yeah, I think we have to supply more than one set of hooks
[06:50] <cjwatson> because anything running before casper-bottom can't get at /root
[06:50] <cjwatson> actually, hmm, that's not quite true is it
[06:50] <mikmorg> cjwatson: Exactly. If we had one set of hooks that ran before casper-bottom, we could use that set of hooks to install another set of hooks (ie. ubiquity-casper.deb)
[06:51] <mikmorg> So I think the most important modification would be to allow hooks prior to casper-bottom.
[06:51] <cjwatson> yeah, I think that's probably the common case though and that we ought to supply something special for that rather than asking people to roll it for themselves
[06:51] <mikmorg> thats fine, too.
[06:51] <cjwatson> I certainly don't disagree that that is necessary and (logically) sufficient
[06:52] <cjwatson> just trying to explore what's reasonable as syntactic sugar, if you see what I mean
[06:52] <mikmorg> thats fine
[06:52] <mikmorg> i'm just trying to reduce the work
[06:52] <mikmorg> :)
[06:53] <cjwatson> *shrug* it's either wodge of code or wodge of documentation ;-)
[06:53] <mikmorg> tuche
[06:57] <mikmorg> ok, i'm heading out to lunch
[07:13] <bdmurray> bryyce: what would need for bug 96213?
[07:13] <ubotu> Launchpad bug 96213 in Ubuntu "won't install on Dell 640m with 1400x900 screen" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96213
[07:17] <karloo> why
[07:17] <brycerr> hm
[07:18] <brycerr> well, we need to know what graphics card and driver he's using, so need xorg.conf and/or Xorg.0.log
[07:18] <karloo> why
[07:19] <brycerr> also, if it is an intel graphics then whether or not 915resolution is installed
[07:20] <bdmurray> okay, Xorg.0.log will contain chipset information for the graphics card then?
[07:20] <brycerr> he says he does know how to make it install, so it would be nice for him to outline the steps; that should make it clearer what change is needed
[07:20] <brycerr> I suspect it's a dupe of 3731
[07:20] <brycerr> (or one of its variants
[07:23] <brycerr> Hobbsee, but whhhyyyy??  ;-)
[07:23] <brycerr> lol :-)
[07:24] <brycerr> bdmurray, I need to spend like a good week of quality time with 3731.  *sigh*
[07:26] <mjg59_> seb128: Hm. Are you able to send me a copy of the packages again?
[07:53] <seb128> mjg59: http://people.ubuntu.com/~seb128/xserver-xorg-video-avivo/
[07:54] <mjg59> seb128: Thanks
[07:55] <seb128> np
[08:21] <mikmorg> cjwatson: Hello again.
[08:46] <gerundium> /gerundium hugs all_you_great_developers_working_for_ubuntu
[09:06] <CMooney> I have beer and want to learn to hunt bugs.
[09:07] <persia> CMooney: There's a lot of action in #ubuntu-bugs right now, despite the published documentation :)
[09:08] <CMooney> ah right, thanks.
[10:33] <brycerr> huh...  could someone do a ls -lh ~/.xsession-errors ?
[10:34] <elmo> -rw-r--r-- 1 james james 60K 2007-06-13 21:16 /home/james/.xsession-errors
[10:34] <brycerr> hmm, mine is 1.6G.
[10:35] <brycerr> looks like mostly due to "alarm-queue"
[10:36] <seb128> for how long is your session running?
[10:37] <seb128> and what desktop do you use?
[10:37] <seb128> gdm cleans the file on login and it has a limit
[10:37] <brycerr> seb128, less than a day (this is the dell 1505n laptop)
[10:38] <brycerr> I'm using stock gnome ubuntu, running gutsy
[10:38] <seb128> brycerr: that is weird
[10:39] <seb128> you use gdm to log in?
[10:39] <brycerr> yup
[10:39] <brycerr> this is running compiz too btw, if that matters
[10:39] <seb128> no, should not
[10:40] <brycerr> I haven't installed the latest updates for evolution, maybe that'd fix it?
[10:40] <seb128> the messages are "normal"
[10:40] <seb128> what is not is that the error log takes 1.6G
[10:41] <seb128> it used to stop logging after a limit which was like 1M
[10:41] <seb128> maybe it's broken on gutsy
[10:41] <seb128> the amount of message is not normal though
[10:41] <brycerr> hmm, gdm appears not to be running
[10:42] <brycerr> l# /etc/init.d/gdm start
[10:42] <brycerr>  * Not starting GNOME Display Manager (gdm); it is not the default display manager.
[10:42] <seb128> ah
[10:42] <seb128> there you go
[10:42] <brycerr> ok cool
[10:42] <brycerr> I probably turned it off to muss with bulletproof x stuff and forgot
[10:42] <seb128> so you are not using a stock install ;)
[10:43] <brycerr> heh, guess not ;-)
[10:43] <brycerr> how quickly things diverge
[10:43] <seb128> I'll have a look at stopping evolution to print all those debug lines
[10:43] <seb128> usually that's not really an issue since gdm clean things and there is a log limit
[10:45] <brycerr> btw, I'm poking around with the Wacom entries that are put into xorg.conf by default even when wacom's are not present
[10:46] <brycerr> seb128 (or anyone), do you have any idea why those are there?  I'm wondering if we just took them out, if it'd hurt anyone
[10:46] <brycerr> s/anyone/very many people/
[10:46] <sparkiegeek> is this the right place to ask about problems building a binary package from an "apt-get source <package>" ?
[10:48] <sparkiegeek> more specifically building meld and having issues with make and .po files
[10:49] <seb128> brycerr: no idea about the watcom thing
[10:51] <tepsipakki> brycerr: mjg59 seems to be the one who did it :)
[10:52] <brycerr> tepsipakki, really?  interesting -- do you know of a debian bug id for it?
[10:52] <mjg59_> brycerr: Yes, it means tablets work
[10:53] <brycerr> mjg59, can we conditionalize it so it only gets added to xorg.conf if a tablet is actually present?
[10:53] <tepsipakki> brycerr: there was no mention of one, and it's one of our changes
[10:53] <mjg59> brycerr: Not trivially, no
[10:54] <mjg59> brycerr: Given that it doesn't break anything (or if it does, then it's something that's broken already...)
[10:55] <tepsipakki> kde programs complain something, but that's harmless
[10:56] <mjg59> When we move over to hotplugged input devices, it's not as much of a problem
[10:56] <tepsipakki> true
[10:57] <brycerr> will the input hotplug allow us to safely drop it at that point?
[10:57] <mjg59> Not immediately
[10:57] <tepsipakki> maybe, if the driver supports input hotplug
[10:57] <mjg59> Hal would need to be taught about them
[10:58] <tepsipakki> so it is going to use hal after all :)
[10:58] <mjg59> Any policy manager that's sane for us is probably going to be hal-based, I suspect
[10:58] <mjg59> This may not be true of everyone
[11:12] <tepsipakki> brycerr: magnus vigerlof should know how wacom is doing hotplug-wise
[11:13] <brycerr> tepsipakki, ok
[11:14] <brycerr> tepsipakki, which package provides dexconf?  I see it's present in xorg-7.2/debian/local/, but that doesn't appear to contain the wacom changes
[11:15] <tepsipakki> brycerr: doesn't? It should
[11:16] <tepsipakki> is it the vanilla debian version you are looking at?
[11:19] <brycerr> hmm
[11:19] <brycerr> ahh, yeah, I get it
[11:20] <sn0> \bitchx/
[11:20] <brycerr> I'd added debian experimental to my sources so I could track the stuff in experimental with my current versions page
[11:20] <brycerr> but that screws up pulling source
[11:21] <tepsipakki> yes, and you can't tell apt-get where to pull sources
[11:21] <tepsipakki> since that doesn't work for source packages
[11:21] <brycerr> yup, lil' bugger
[11:21] <brycerr> fortunately I have more ubuntu machines on hand ;-)
[11:22] <tepsipakki> just do a grab-merge.sh xorg :)
[11:22] <brycerr> speaking of which...  have you looked at fglrx?  I gather we probalby shouldn't merge xorg until we've upgraded fglrx
[11:23] <tepsipakki> no I haven't, but now that you mentioned it.. there are some drivers which Provides: xserver-xorg-video
[11:23] <tepsipakki> but it should be x-x-v-1.0
[11:24] <tepsipakki> then that change to xorg could be dropped
[11:24] <tepsipakki> but sure, the newest fglrx should work with 1.3
[11:25] <tepsipakki> mjg59: are you going to maintain the -avivo driver, or do you mind if the package is adopted by debian XSF?
[11:25] <mjg59> tepsipakki: No objection to that
[11:26] <mjg59> I just wanted it packaged so I could stop building it from source :)
[11:26] <mjg59> tepsipakki: Note that it only contains a couple of PCI IDs right now
[11:26] <tepsipakki> mjg59: ok, I'll pass that forward (same applies to libpciaccess)
[11:26] <mjg59> Should be safe to add more with some testing
[11:26] <mjg59> But r580 is still unhappy
[11:27] <bdmurray> mjg59: I was looking at bug 119826 regarding Fn keys on a laptop.  Would that belong in hotkey-setup or acpi?
[11:27] <ubotu> Launchpad bug 119826 in acpi-support "Fn key doen not work on compaq presario laptop in Xubuntu feisty" [Wishlist,Confirmed]  https://launchpad.net/bugs/119826
[11:28] <bdmurray> I swear it didn't used to have a package
[11:30] <mjg59> bdmurray: Doesn't look like either
[11:30] <mjg59> bdmurray: For some reason, any time anything mentions acpi it gets assigned to acpi-support
[11:30] <mjg59> Despite it basically never being an acpi-support problem
[11:30] <mjg59> bdmurray: Arguably a hal issue, partially a kernel issue
[11:32] <bdmurray> mjg59: Could you elaborate a bit or point me at something to read?
[11:33] <mjg59> bdmurray: Something needs to send those events to userspace - it /could/ be done in acpi-support, but it makes more sense for the kernel to generate KEY_BRIGHTNESSUP and KEY_BRIGHTNESSDOWN (since that's all acpi-support oculd do)
[11:33] <mjg59> Then something needs support for editing the brightness via the acpi interface
[11:33] <mjg59> And then something needs to handle policy
[11:44] <keescook> mjg59: how are most brightness buttons handled currently?
[11:45] <peanutb_> 20000 hugs to whoever closes bug 1
[11:45] <ubotu> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress]  https://launchpad.net/bugs/1
[11:46] <mjg59> keescook: Either in hardware or via gnome-power-manager
[11:48] <keescook> mjg59: so it seems that "my brightness keys don't work" bugs are best filed against gnome-power-manager than acpi-support?
[11:48] <mjg59> keescook: acpi-support is always the wrong answer
[11:48] <keescook> hah.  :)
[11:48] <mjg59> It's either a hal issue or a kernel issue
[11:48] <mjg59> g-p-m ought to deal with any case that can be handled
[11:49] <mjg59> It just says "Oh, here's a backlight hal can control" and "Oh, I just got a keypress telling me to change the brightness"
[11:49] <keescook> is g-p-m running for folks with xubuntu?
[11:49] <mjg59> Dunno
[11:49] <mjg59> I have too little time to examine varient distros :)
[11:49] <keescook> heh
[11:49] <brycerr> xubuntu needs no stinkin' backlighting!
[11:50] <brycerr> (sorry, couldn't resist)
[11:51] <calc> mjg59: hmm maintainer of acpi-support probably knows where to reassign the bug? ;)
[11:52] <calc> throw the hot potato to acpi-support and it will bounce it to the right location, heh
[11:52] <cjwatson> calc: I get the impression mjg59 has got fed up of doing that ;-)
[11:52] <mjg59> calc: Right now I've got no time to handle any bugmail, let alone stuff that's been assigned to me because people have an insufficient understanding of how stuff works to assign it to the proper place in the first place...
[11:53] <calc> i assigned some today to acpi-support, but at least one of them i think really belonged to it, unless hal is supposed to do it
[11:53] <calc> wrt potentially unmounting filesystems on hibernate
[11:53] <calc> mjg59: ok
[11:53] <calc> iirc it got marked wishlist in any case
[11:53] <mjg59> acpi-support is probably right in that case, though it'll be rejected as not being a bug :)
[11:54] <calc> mjg59: for that one in particular user hibernates ubuntu boots into windows changes files and resumes linux and doesn't see files
[11:55] <Chenson> damn, bug #1 is still in progress. https://bugs.launchpad.net/ubuntu/+bug/1  *hehe*
[11:55] <calc> mostly user error since the vast majority of the time a file will be open somewhere on the fs so that it can't be unmounted anyway
[11:55] <ubotu> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress]  https://launchpad.net/bugs/1
[11:55] <mjg59> Yes. Don't do that :)
[11:55] <mjg59> Well, really the issue is that our entire approach to hibernation is broken
[11:55] <mjg59> I plan to fix that
[11:55] <calc> mjg59: eh?
[11:56] <mjg59> If anyone else can touch the filesystem, we shouldn't be keeping the file cache
[11:56] <calc> to force the user to boot back into ubuntu on power on? ;)
[11:56] <mjg59> Alternatively, we could make it impossible for anyone else to touch the filesystem. But that one might suck a bit.
[11:56] <calc> yea
[11:56] <mjg59> So I prefer the first
[11:57] <calc> i didn't realize you could dump the file cache, that sounds like it could work out well