[00:16] <craigbass1976> I've been reading this: https://lists.ubuntu.com/archives/ubuntu-devel/2009-June/028297.html  What was the verdict for someone still on Jaunty?
[00:41] <craigbass1976> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/289852   I tried that stuff too, and still no love
[00:48] <craigbass1976> Anyone know how to get the fix for bug#382379, or have I already got it and it still isn't working?
[03:41] <ccheney`> has anyone been able to get googletalk to work from the hotel?
[03:43] <ccheney`> finally just magically started working
[04:39] <diwic> In what timezone is the schedule on http://summit.ubuntu.com/uds-l/2009-11-16/ ?
[04:39] <diwic> According to http://summit.ubuntu.com/uds-l/ it says EST, but timeanddate.com says dallas is in CST.
[04:41] <Flannel> Dallas is CST
[04:43] <diwic> So http://summit.ubuntu.com/uds-l/ is wrong then?
[04:44] <diwic> And https://launchpad.net/sprints/uds-l says UTC, to add to the confusion
[07:15] <foobarmus> Can anyone tell me if a bunch of video drivers have been removed from recent kernels? I'm beginning to suspect this has happened...
[07:23] <RAOF> foobarmus: Such as?
[07:25] <lifeless> foobarmus: I'm not aware of anything like that.
[07:26] <foobarmus> RAOF: um, I dunno... I have 2 boxes each with a different card... Having trouble getting both Karmic and a recent download of Hardy to spit out anything more than 800x600 on either of them
[07:26] <foobarmus> RAOF: never had this kind of trouble b4... have been using ubuntu for years, on all kinds of hardware
[07:27] <RAOF> What video cards?  The kernel doesn't tend to drop support for anything, but you may well be running into Proprietary Driver Annoyance™
[07:28] <\sh> moins
[07:28] <\sh> guys, the times on summit.u.c are in UTC, right?
[07:28] <foobarmus> RAOF: they are pretty bog standard cards, nvidia maybe... one is about 6 yrs old, the other 3 yrs old
[07:29] <lifeless> nvidia, mmm proprietary hardware
[07:29] <RAOF> foobarmus: Well, nvidia is likely proprietary hell.  Particularly since they'll have dropped support for your card in recent drivers.
[07:30] <foobarmus> have had multiple installs of ubu running on both boxes b4, everything from dapper to Jaunty... now I can't seem to install anything
[07:30] <RAOF> (We now have 4 different versions of the nvidia driver in the repositories)
[07:30] <foobarmus> RAOF: hmmm... so I should go back to an older kernel?
[07:31] <foobarmus> RAOF: or older release?
[07:31] <lifeless> RAOF: is nouveau nvidia or ati?
[07:31] <RAOF> foobarmus: #ubuntu is probably a better place for troubleshooting.  You should be able to get Karmic working on both your systems, but I can't tell you how :)
[07:32] <RAOF> lifeless: nouveau is nvidia.  The radeon is ati.
[07:32] <lifeless> foobarmus: so, #ubuntu, but also try the nouveau driver (or if you are, try the proprietary one)
[07:32] <foobarmus> RAOF: Thanks for the info
[07:32] <foobarmus> lifeless: cheers
[07:32] <RAOF> lifeless: (Fun fact: nouveau is called nouveau because the first (French) developer had a text-substitution alias for 'nv->nouveau')
[09:04] <hyperair> how does one debug an upstart job?
[09:05] <\sh> hyperair: vi /boot/grub/menu.lst add --verbose or --debug to the kernel command line
[09:05] <hyperair> \sh: is there any way i can debug an upstart job without rebooting?
[09:06] <hyperair> $ sudo start apport
[09:06] <hyperair> start: Job failed to start
[09:06] <hyperair> that's all i see
[09:06] <hyperair> running the pre-start script manually in dash or bash works
[09:06] <hyperair> and there's no exec
[09:06] <hyperair> i can't figure out why it's not working
[09:06] <\sh> hyperair, http://upstart.ubuntu.com/wiki/Debugging
[09:09] <\sh> hyperair, eventually because it's not enabled in /etc/default/apport
[09:09] <hyperair> hmmm
[09:09] <hyperair> ah
[09:09] <hyperair> thanks
[09:10] <hyperair> i feel stupid now
[09:10] <hyperair> heh
[09:29] <forscher> hi - could someone tell me how udev does handle keyboards and joysticks to create eventN on hiddevN ?
[14:14] <Tm_T> dendro-afk: hrr, awaynick ):
[16:13] <lool> Do we have a script to "import" a Debian bug into a LP one?
[16:13] <lool> (create a LP bug from a Debian bug)
[16:32] <hdon> i think i just made gnome-terminal crash!
[16:32] <hdon> all my tabs!
[16:32] <hdon> gone!
[16:32] <hdon> :C
[16:33] <cjwatson> yes, well that's a design flaw (robustness) in g-t, isn't it ...
[16:33]  * cjwatson uses pterm O:-)
[16:33] <hdon> gtk 1.2 :O
[16:34] <highvoltage> but does pterm have tabs? ;)
[16:34] <cjwatson> hdon: not in karmic
[16:34] <cjwatson> highvoltage: no, and I like it that way :)
[16:34] <hdon> oh
[16:34] <hdon> i suppose i should upgrade eventually
[16:34] <cjwatson> separate processes => one crash doesn't take out everything
[16:35] <cjwatson> (obviously xterm etc. are the same)
[16:35]  * hdon can't imagine an acceptable circumstance for terminal emulator crash
[16:35] <cjwatson> hdon: sure, but there's this principle called "defence in depth" ...
[16:35] <highvoltage> cjwatson: I guess all the cool people us screen anyway
[16:35] <hdon> cjwatson: xterm instances are in one process?
[16:35] <cjwatson> hdon: each xterm instance is a single process
[16:36] <directhex> perhaps g-t should be a transparent frontend to screen!
[16:36] <hdon> ah, ok. i thought i had entered a parallel universe or something
[16:37] <hdon> holy shit
[16:37] <hdon> lmao
[16:37] <hdon> i ran gnome-terminal --disable-factory so that i could recreate the crash and see what it says
[16:37] <hdon> but when i did it, both of my terminals crashed. *should have seen that coming*
[16:38] <hdon> wow, now i cannot recreate the crash at all
[16:38]  * hdon scratches his head
[16:39] <hdon> hmm, there we go, that did it
[16:39] <hdon> i think i know how to recreate it now
[16:39] <hdon> of course maybe it isn't even in karmic
[16:41] <hdon> oh well i can't mess with this right now
[16:41] <hdon> if someone else wants to investigate, try menu/Terminal/Set Character Encoding/Add\Remove
[16:41] <hdon> and then try adding one
[16:42] <hdon> that caused a crash for me. maybe only if there is more than one gnome-terminal running. i can't be sure
[16:42] <hdon> running with --disable-factory may protect from crash
[16:42] <hdon> cjwatson: i think --disable-factory will get you a new process for each gnome-terminal, but that did not mean the crash didn't take down all my gnome-terminal processes anyway
[16:42] <hdon> i suspect it's some kind of race condition somewhere
[16:43] <hdon> for some shared resource concerning available character encodings
[16:45] <YokoZar> what's the summit IRC channel?
[16:45] <StevenK> #ubuntu-devel-summit
[17:07] <forscher> Could someone tell me how udev detect and handle keyboards and joysticks? Through all changes in Karmic I have lost the path....
[17:08] <forscher> a link to some documentations are pretty welcome!
[17:37] <snnw> Amaranth: ping
[17:41] <Amaranth> snnw: pong
[17:43] <snnw> hi, I noticed in Alacarta's git repository that you started a rewrite in Vala a couple months back. Can you tell me if there are any plans on replacing the python implementation with yours?
[17:45] <snnw> I was writing a few patches for the python one, but if that's a dead end I'd rather work on the newer code base
[17:47] <snnw> If this is not a good time, I can ping you later.
[18:03] <snnw> Amaranth: still there?
[18:12] <Amaranth> snnw: I'd like to see the vala one finished but it's somewhat stalled on libgarcon
[18:12] <Amaranth> snnw: So I doubt the vala one will replace the python one before gnome-shell replaces alacarte completely
[18:18] <snnw> Amaranth: Thanks, I think I'll stick with the python one for now, then. It's kind of nice, working on a small project like this :)
[19:09] <Kartinka> Hey guys, i was hiding some unmounted partitions with DevKit / udev Rules, but i search for a way to hide these partitions completely from the system not only from gnome / nautilus. Can anyone help me?!
[19:09] <craigbass1976> https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/382379   The fix has been released.  How do I go about implementing it?
[19:10] <ebroder> Kartinka: We've told you before - this is not the right channel for this discussion
[19:11] <Kartinka> i search only for sb i won't talk in the chan...
[20:05] <forscher> to which channel did Kartinka go?
[20:06] <Kartinka> here
[20:06] <Kartinka> i'am
[20:06] <Kartinka> ^^
[20:06] <Kartinka> can you help me?
[20:06] <Kartinka> forscher?
[20:34] <jdong> does upstart do a sync anywhere at reboot?
[20:34] <jdong> I'm seeing somewhat reproducible FS data loss when rebooting right after heavy IO
[20:39] <jdong>         if (! no_sync)
[20:39] <jdong>                 sync ();
[20:39] <jdong> hmm. Seems like it should :-/
[20:39]  * jdong blames btrfs
[20:39] <StevenK> Sounds like a good thing to blame :-P
[20:40] <jdong> lol hey hey!
[20:40] <jdong> at least I don't have to iteratively download and md5sum my >500MB files :P
[20:40] <StevenK> Does btrfs actually support sync? :-)
[20:42] <jdong> StevenK: as far as I know, yes :)
[20:43] <ajmitch> you just enjoy the bleeding edge
[20:43]  * soren hugs his XFS filesystems
[20:43]  * jdong switched from XFS to btrfs on this server :)
[20:44] <soren> No sympathy, then.
[20:44] <soren> :)
[20:44] <jdong> partly to help the cause, partly because I was tired of XFS taking 2 minutes to clean pbuilders
[20:44] <jdong> lol nothing actually was lost though :)
[20:45] <soren> jdong: 2 minutes to clean pbuilder? You got that bad unlink performance?
[20:45] <jdong> yeah, on XFS
[20:45] <jdong> any nontrivial pbuilder takes minutes to clean
[20:46] <jdong> unlink performance on XFS for me has been pretty horrible with a collection of small files
[20:46] <soren> Wow.
[20:46] <jdong> I mean, I love XFS -- my media storage partition is still XFS
[20:47] <jdong> but... there's certainly some things that XFS simply wasn't designed to excel at.
[20:49] <soren> I know it has less than stellar unlink performance, but I've never seen anything as bad as what you're describing.
[20:49] <slangasek> any nontrivial pbuilder should use sbuild + schroot w/ LVM snapshots ;)
[20:49] <ebroder> Yeah, I used to think that. My stance now is "any nontrivial build should use PPAs" :-P
[20:50]  * soren uses tarballs for his sbuild
[20:50] <ajmitch> ebroder: depending on your upstream bandwidth :)
[20:50] <ebroder> Oh, also, you don't want LVM snapshots, because their performance sucks, too. You actually want the aufs support added in schroot 1.3
[20:50] <jdong> aufs sounds like a good idea for this
[20:50] <jdong> or.... btfsctl -S....
[20:50] <jdong> *ducks*
[20:50] <soren> It performs better (no overhead of dm_snapshot), it doesn't waste space, it allows bigger builds.. It's pretty awesome.
[20:51] <ebroder> aufs with a tmpfs for the overlay is going to be faster than ~anything that writes to disk, so long as you have the RAM for it
[20:52] <ajmitch> anything that avoids hitting the disk overly much is great on a laptop
[20:52] <soren> Even counting the time it takes to unpack tarballs, it still beats lvm snapshot based sbuilds even for relatively small builds.
[20:52] <sebner> jdong: I'm wondering why btrfs takes that long to mature. Started 2006 afaik, big company behind it and it has the attention of the community. Will be stable in 2010 earliest imho
[20:53] <ajmitch> sebner: given that 2010 is a few weeks away...
[20:53] <jdong> sebner: eh they're playing the game responsibly.
[20:55] <sebner> ajmitch: and lasts 365 days :P
[20:56] <sebner> jdong: isn't game responsibility to push out stuff to early?
[20:57] <jdong> Yes
[20:57] <jdong> It is though
[20:57] <jdong> It's in mainline, easy to build git checkouts...
[20:57] <jdong> Dunno what else one expects
[20:58] <sebner> jdong: with whom do we need to stay in bed in order to get btrfs installable with lucid like fedora offers now :P
[20:58] <yofel> hi, would bug 402188 qualify for a SRU? The patch has been tested in a ppa and works fine.
[21:05] <ebroder> Hmm...when I run 'manage-credentials create -c ubuntu-dev-tools -l 2' on my Karmic machine, then fill out the web form, then hit enter in manage-creds, I get a 401 error
[21:06] <ebroder> Oh wait - classtime. I'll try again later
[21:16] <jdong> sebner: seems like you need to sleep with a debian-installer/ubiquity developer ;-)
[21:16] <jdong> sebner: and possibly a GRUB2 dev too
[21:17] <sebner> jdong: heh, grub2 ubuntu-dev as fedora and suse already support that stuff. We could pull the patch from there
[21:17] <jdong> sebner: wait where'd this patch come from??
[21:18] <jdong> I've been keeping my eye on the associated debian bug and no patch AFAIK
[21:18] <sebner> jdong: fedora/suse?
[21:20] <jdong> well I don't think fedora/suse use grub-probe for this purpose
[21:20] <jdong> namely due to the multi-rooted nature of btrfs, grub-probe cannot identify the device node associated with a btrfs volume
[21:20] <jdong> which causes update-grub to bork out
[21:20] <jdong> a Debianism...
[21:27] <sebner> jdong: it seems they are always ahead of us :P
[21:27] <jdong> often true
[21:28] <sebner> jdong: we are not bleeding/cutting edge enough :P
[21:28] <jdong> nor is OpenSUSE.
[21:29] <sebner> jdong: well, it's suse. I just mentioned it because of btrfs. No one wants suse :P
[21:31] <EtienneG> does someone know if the MIT kerberos are attending UDS-L? They where at UDS Jaunty.  If they are, I would love to have a quick chat with them, got a thorny problem
[21:32] <Pici> 0/64
[22:03] <Fenix|work> Greetings and salutations
[22:04] <Fenix|work> Any rsyslog implementers present?  I'm confused about what/where the template RSYSLOG_TraditionalFileFormat is or points to.
[22:10] <Fenix|work> ok, nm found it.  Is there any reason why high-precision timestamps are turned off?
[22:10] <Riddell> asac, pitti: VPN?
[22:15] <cjwatson> sebner: there's a blueprint for that already, later this week
[22:15] <cjwatson> sebner: there's a grub patch from fedora, but grub2 != grub and it's not trivial to forward-port. In this case the problem is that they are too far behind us :P
[22:16] <cjwatson> sebner: they kind of tossed it over the wall to grub-devel, but haven't volunteered to do the forward-port
[22:17] <cjwatson> jdong: http://lists.gnu.org/archive/html/grub-devel/2009-09/msg00381.html and thread
[22:18] <sebner> cjwatson: heh, nice you catched up as I thought of being punched to death because lucid will be LTS :)
[22:18] <ajmitch> sebner: why did you anticipate a violent death?
[22:19] <cjwatson> no, I'd like to support btrfs. I certainly don't think it should be the default though
[22:19] <ajmitch> I don't think lucid will quite be 'no new features', just sane defaults
[22:20] <sebner> cjwatson: oh well, not even myself considers btrfs "defaultable" ;)
[22:20] <ajmitch> jdong might :)
[22:20] <sebner> cjwatson: I was speaking about fedora12 btw, still wondering if they have grub2 now
[22:22] <cjwatson> sebner: if they have a btrfs patch for grub2, they have not seen fit to contribute it upstream, and upstream is to the best of my knowledge unaware of it
[22:25] <sebner> cjwatson: ah right and so opensuse sticks to grub too. HAHA ubuntu ftw!
[22:28] <jdong> lol never said I want to default to btrfs
[22:28] <jdong> it'd just be nice to make it an available option in the installer
[22:28] <ebroder> Blargh. Did bug #483813 get filed correctly? requestsync errored out in the middle - I didn't realize it had even filed the bug
[22:29] <sebner> jdong: to me it's the same :P
[22:31] <jdong> aren't there supposed to be diffstats and such attached to requestsyncs?
[22:31] <cjwatson> jdong: as an archive admin I wouldn't look at them ... :)
[22:32] <ajmitch> I don't think I've ever seen or attached diffstats
[22:32]  * sebner too
[22:32] <ajmitch> it's more relevant for SRUs & fixes close to release
[22:33] <jdong> it might be freeze exceptions then :)
[22:33] <sebner> anyways
[22:33] <ebroder> I've certainly never seen requestsync attach debdiffs
[22:33]  * sebner wishes a good night everybody! :)
[22:33] <ajmitch> night sebner
[22:33] <jdong> lol at this stage in Lucid I'd expect it to be big-rubber-stamp protocol anyway ;-)
[22:33] <ebroder> Anyway, just wanted to make sure the bug was in place right (not that I'd object to somebody looking at it :-P)
[22:34]  * jdong hands ebroder the subtle bugprod award of the day.
[22:34] <ebroder> *shrug* Or I could wait a week and a half, at which point hopefully I'd be able to ACK it myself
[22:36] <directhex> when was the last autosync run? i'm still not seeing things that have been in squeeze since pre-karmic-release
[22:43] <StevenK> directhex: It's run by hand. I'll run one soonish
[22:45] <ajmitch> StevenK: does the autosync pick up packages from contrib/non-free?
[22:47] <StevenK> ajmitch: It can, not in the same run
[22:59] <slangasek> TheMuso: when you have a chance, I would like to talk with you about the brltty package's init script
[23:21] <forscher> which channel could I ask for udev and eventX ?
[23:33] <bdrung_> does ubuntu accepts 3.0 (quilt) source package uploads?
[23:34] <RAOF> bdrung_: No(t yet)
[23:34] <bdrung_> RAOF: how long do we need to wait? will it be ready for lucid?
[23:35] <ajmitch> probably until the next LP rollout, ask wgrant about it
[23:35] <RAOF> Launchpad hasn't quite grown support for the new source package formats, but wgrant (IIRC) is working on it.  My remembarance is that it should be ready soonish, before Lucid certainly.
[23:35] <bdrung_> thanks.
[23:38] <wgrant> bdrung_, ajmitch, RAOF: It should be supported on 2009-12-05 (LP 3.1.11)
[23:39] <bdrung_> wgrant: thx
[23:41] <rgreening> NCommander: ping
[23:41] <NCommander> rgreening, pong?
[23:41] <rgreening> you available to come to vinoy
[23:41] <rgreening> we have an armel
[23:42] <rgreening> need som advice/help :)
[23:42] <rgreening> me and Riddell
[23:42] <NCommander> rgreening, I saw it earlier, didn't I?
[23:42] <rgreening> dunno
[23:42] <rgreening> but can you pop over
[23:42] <rgreening> NCommander: nope, its a different one
[23:45] <NCommander> rgreening, neat, I'll be there as son as I'm done here
[23:46] <rgreening> k
[23:51] <pitti> Riddell: sorry, had a session right now which I draft
[23:54] <elopss>  why/where/how is the kernel inserting mount options that mount(2) isnt sending it?   (according to both behaviour, and /proc/mounts)
[23:54] <elopss> well /proc/mounts shows mount options that were not provided by mount().  what is the cause of this?
[23:54] <elopss> relatime is the option that's showing up on all my mounts that i want to get rid of
[23:54] <elopss>  and, it didnt do this until i upgraded to 9.10
[23:54] <elopss> but i'm also using kernel .32rc  which might have something to do with it
[23:56] <elopss> anyone?
[23:57] <elopss> the he strictatime  works for some mount commands, but mount.nfs doesnt pass it to mount()   ..  i could write a call to do it, but why the relatime is in there in the first place boggles me.
[23:59] <elopss> hmm?