[00:00] <seb128> NCommander: that was to point the tarballs I listed on #ubuntu-desktop now
[01:03] <TheMuso> 5~/c
[03:18] <emgent> Riddell: ping
[05:45] <dholbach> good morning
[06:05] <TheMuso> /c
[06:05] <dholbach> does seahorse's gpg agent work for anybody in intrepid?
[06:05] <dholbach> it works fine in hardy for me, but not in intrepid
[06:06] <tseliot> ﻿dholbach: maybe you're experiencing a problem with gnome's keyring
[06:06] <tseliot> did you do a "ssh-add"?
[06:08] <dholbach> tseliot: not that I remember
[06:08] <dholbach> it's a KVM instance (if that matters)
[06:08] <dholbach> I have to type in my gpg passphrase everytime - this sucks :)
[06:09] <tseliot> after doing that the problem with the gnome keyring should go away
[06:09] <tseliot> as regards having to type your password every time, do you use gpg-agent?
[06:10] <nxvl> i always type my passphrase
[06:10] <nxvl> i don;t trust password managers
[06:10] <nxvl> :D
[06:10] <tseliot> dholbach: I meant gnupg-agent
[06:11] <dholbach> tseliot: AFAIK seahorse is a gpg agent
[06:11] <dholbach> at least it was in hardy
[06:12] <dholbach> seahorse-agent is missing from intrepid - hm
[06:12] <nxvl> as a standard answer
[06:13] <nxvl> dholbach: file a bug on launchpad against seahorse
[06:13] <nxvl> :P
[06:14] <dholbach> from seahorse changelog: debian/seahorse.Xsession: remove this one since seahorse-agent has been moved to a different source
[06:15] <nxvl> dholbach: there is the answer
[06:15] <dholbach> it's not a full answer - which different source? :)
[06:16] <nxvl> dholbach: ask seb
[06:17] <nxvl> dholbach: or slomo
[06:17] <dholbach> once they're up, yeah
[07:57] <ion_> summon BenC
[08:01] <pitti> Good morning
[08:01] <pitti> slangasek: p-c-f> thanks, will do
[08:02] <pitti> Riddell: right, I still have troubles with the retracers, p-lp-bugs...; I'll enable apport again by default as soon as this is sorted out
[08:04] <Hobbsee> pitti!
[08:05] <tjaalton> please don't upgrade your xserver-xorg-core just yet ;)
[08:06] <pitti> tjaalton: thanks for the warning :)
[08:06] <pitti> Hobbsee!!!
[08:06] <Hobbsee> :)
[08:06] <RAOF> tjaalton: Full of lack of working?
[08:06] <tjaalton> mouse&kbd won't work with current xorg.conf
[08:06] <tjaalton> autoconfig fails for some reason
[08:06] <RAOF> That could be a small problem, yes.
[08:07] <Hobbsee> ouch
[08:07] <tjaalton> just more the reason to turn input-hotplug on ;)
[08:07] <RAOF> What's the status of synaptics visa vis not requiring SHMConfig in xorg.conf to be useful?
[08:08] <tjaalton> pitti: btw, there's a better solution to the i-h fdi thingy. ajax patched hal-set-property to support --direct, which means that a callout script works now. that means that there's no need to generate an fdi file anymore
[08:08] <Hobbsee> that reminds me.  i should file a bug about the vertical scrolling detection, or lack of it, on a default install.
[08:08] <tjaalton> RAOF: input properties, in xserver master
[08:08] <RAOF> tjaalton: Woot!
[08:09] <pitti> tjaalton: what does --direct do?
[08:09] <tjaalton> RAOF: but needs driver support for it. think xrandr but for input devices
[08:10] <RAOF> tjaalton: Relatively easy changes to make?
[08:10] <tjaalton> pitti: it allows to set the value before the dbus connection works. I played with that approach long ago, but couldn't make it to work because hal complained that the dbus connection was not available
[08:10] <tjaalton> RAOF: no idea..
[08:11] <RAOF> Heh.  Oh, well.  Huzzah for X slowly reducing my personal peeves.  Next thing you know you'll be able to resize the framebuffer at runtime!
[08:11] <tjaalton> pitti: http://cvs.fedoraproject.org/viewcvs/devel/hal/hal-0.5.10-set-property-direct.patch?rev=1.1&view=auto
[08:36] <tjaalton> pitti: ok if I prepare a diff for hal?
[08:37] <pitti> tjaalton: sure, or just commit it to the bzr branch
[08:37] <pitti> but if you are more happy with a diff and want me to review, fine for me
[08:38] <tjaalton> pitti: ok, will do. I guess it's easier to just turn input-hotplug on to fix the mouse/kbd problems :)
[08:39] <pitti> tjaalton: I just promoted xinput, so please feel to add dependencies to it
[08:40] <tjaalton> pitti: ok, cool
[08:40] <pitti> tseliot: did you see the FTBFS of nvidia-173?
[08:42] <Hobbsee> tjaalton: any ETA for a fix on that no-keyboard bug?
[08:42] <tjaalton> Hobbsee: a couple of hours
[08:42] <Hobbsee> tjaalton: cool :)(
[08:42] <tjaalton> Hobbsee: or just add 'Option "AllowEmptyInput" "false" to ServerFlags section
[08:42] <tjaalton> it's the commit that enabled that by default which broke it
[08:43] <tjaalton> and because ServerLayout doesn't have the devices listed, epic fail
[08:44] <Hobbsee> tjaalton: ahh.
[08:45] <tjaalton> but that's needed in order to have a minimal config for input-hotplug, so..
[08:46] <tseliot> pitti: no, I didn't notice the failure
[08:46] <tseliot> link?
[08:47] <StevenK> pitti: Did you dump all of the NBS stuff that ichthux-desktop wanted?
[08:47] <pitti> tseliot: I got an FTBFS email
[08:47] <tseliot> pitti: http://launchpadlibrarian.net/16527069/buildlog_ubuntu-intrepid-i386.nvidia-graphics-drivers-173_173.14.12-0ubuntu1_FAILEDTOBUILD.txt.gz
[08:47] <pitti> StevenK: maybe not all, but if I looked at a package and ichthux-desktop was the only rdepends, I killed it
[08:48] <pitti> tseliot: right, you can get it from the web ui
[08:48] <StevenK> pitti: Ah, okay, so I should vacuum up some of the real NBS things and kill them off?
[08:48] <tseliot> pitti: heck the NVIDIA installer was not executable. Weird it is here
[08:48] <pitti> StevenK: that would be awesome
[08:49] <pitti> tseliot: maybe just add a chmod to debian/rules, for more robustness?
[08:49] <tseliot> pitti: yes, that's what I was thinking of
[08:50] <tseliot> pitti: shall I bump the revision for a new upload?
[08:50] <pitti> tseliot: yes, you need to
[08:51] <tseliot> pitti: ok, just like the PPA
[08:58] <mvo> mdz: the bug in apts apport writer is fixed now, thanks for reporting it!
[08:59] <tseliot> pitti: here are the links
[08:59] <tseliot> http://albertomilone.com/ubuntu/newlrm/pitti/nvidia-graphics-drivers-173_173.14.12-0ubuntu2.diff.gz
[08:59] <tseliot> http://albertomilone.com/ubuntu/newlrm/pitti/nvidia-graphics-drivers-173_173.14.12-0ubuntu2.dsc
[08:59] <tseliot> http://albertomilone.com/ubuntu/newlrm/pitti/nvidia-graphics-drivers-173_173.14.12-0ubuntu2.changes
[08:59] <tseliot> it builds well here even if the installers are not executable
[08:59] <pitti> tseliot: hm, that's 404
[09:00] <tseliot> pitti: only the changes file
[09:00] <pitti> tseliot: ah, I fixed the name, _source.changes
[09:00] <pitti> works now
[09:02] <pitti> tseliot: uploaded, thanks
[09:02] <tseliot> pitti: thanks to you ;)
[09:04] <pitti> seb128: ah, we have libgphoto-gvfs by default now
[09:05] <seb128> pitti: yes, that's early intrepid we can give it some testing ;-)
[09:05] <pitti> indeed
[09:05] <pitti> we just need to adapt g-v-m accordingly
[09:05] <seb128> ah right
[09:05] <seb128> pitti: btw I'm not sure reopening bug #164265 was correct
[09:05] <pitti> seb128: ATM I get an error dialog that it couldn't lock the camera exclusively, or so
[09:06] <pitti> seb128: well, it's differently broken now, although of course for a different reason
[09:06] <pitti> but the original fix is a regression for someone else, so I think it still belongs together?
[09:06] <pitti> seb128: how about I disable g-v-m's autophoto command, and then I unseed it? or do you still see a reason to install g-v-m by default?
[09:06] <seb128> I'm not sure that's the fix which created the regression, was his case working before?
[09:07] <pitti> before it auto-converted aac to mp3 allegedly
[09:07] <seb128> and I'm not a big fan of having a zillions comments on a bug, I usually prefer having clear new bugs about new issues
[09:09] <pitti> I'm ok with closing it and opening a new bug, if you like it better
[09:11] <pitti> seb128: g-v-m uploaded; shall I unseed it now, too?
[09:11] <seb128> pitti: yes, please do
[09:11] <pitti> one daemon less to start :)
[09:13] <pitti> seb128: ah, the "could not exclusively claim device" error is probably the same as for USB harddrives, it tries to mount it twice
[09:14] <seb128> pitti: the mount twice is a gvfs issue fixed in the new tarball I'm going to upload soon
[09:14] <pitti> right, I know, just keeping track
[09:14]  * pitti sponsors ember's gnome updates and hugs him
[09:15] <seb128> pitti: thanks for the sponsoring ;-)
[09:20]  * pitti does a stab at the retracers
[09:35] <tjaalton> pitti: rock, the hal callout script works
[09:35] <pitti> yay
[09:39] <tjaalton> only that now the xserver crashes :)
[09:40] <tjaalton> some patch apparently breaks it.. I'll go hunt some better ones
[09:48] <pitti> seb128: seems you are still attached to the amd64 retracer screen, BTW?
[09:48] <seb128> pitti: I doubt of that or something went wrong because I disconnected yesterday and stopped my laptop since
[09:48] <pitti> seb128: yeah, you have been attached for several days already
[09:49] <ion_> pitti: -x to attach simultaneously, -dR otherwise
[09:49] <pitti> seb128: maybe screen-in-screen or so? :)
[09:49] <pitti> ion_: I know, I used -x
[09:49] <seb128> pitti: lemme try
[09:49] <pitti> it didn't stop me, but it's still a bit weird
[09:49] <pitti> anyway, retracers should work again, the amd64 one retraced several bugs, and the i836 one is consolidating
[09:50] <seb128> pitti: what the
[09:50] <ion_> Is BenC on a vacation or something, btw? Nothing urgent, just curious.
[09:50] <seb128> pitti: "There is no screen to be resumed."
[09:51] <pitti> ion_: I talked to him yesterday
[09:52] <ion_> He seems to have idled for 26 hours.
[09:53] <tjaalton> what the hell, input-hotplug makes the xserver crash, even the old version
[09:53] <tjaalton> sigh..
[09:55] <RAOF> Argh.  Has anyone else noticed unusually poor interactive performance under disc load?
[09:56] <RAOF> Running an aptitude upgrade shouldn't result in second-long pauses in music & keyboard responsiveness.
[10:01] <pitti> did anyone put launchpadlib into a PPA package already?
[10:01] <pitti> RAOF: me, yes
[10:01] <pitti> but I blamed my recent switch from my amd64 desktop to my i386 laptop (docked) and thus the much slower disk
[10:02] <jpds> pitti: james_w appears to have just put source packages on REVU.
[10:02] <james_w> pitti: give me 5 minutes
[10:02] <pitti> oh, wow
[10:02] <pitti> I *knew* there must be someone who couldn't resist :-P
[10:02]  * pitti hugs james_w
[10:03] <james_w> pitti: Intrepid right?
[10:03] <pitti> james_w: not urgent at all, I was just curious, since I took a look at https://help.launchpad.net/API
[10:03] <tjaalton> pitti: seems like evdev is broken. could you sync it from debian-experimental? the version that was synced last night doesn't build
[10:03] <pitti> and this promises to put an end to the p-lp-bugs screenscraping catchup madness
[10:03] <geser> RAOF: with intrepid?
[10:03] <RAOF> pitti: This is my amd64 laptop, and I seem to recall Hardy doing better.
[10:03] <pitti> tjaalton: trying
[10:04] <tjaalton> pitti: with it my xserver is working again..
[10:04] <pitti> tjaalton: which package will depend on xpinput, BTW?
[10:04] <pitti> Updating] xserver-xorg-input-evdev (1:2.0.2-1.lenny1 [Ubuntu] < 1:2.0.3-2 [Debian])
[10:04] <pitti> tjaalton: ^ that ok?
[10:04] <tjaalton> pitti: yes that's fine
[10:05] <pitti> tjaalton: done
[10:05] <tjaalton> pitti: I'm not sure if any package will depend on it just yet
[10:05] <tjaalton> bryce knows better I gues
[10:05] <tjaalton> +s
[10:05] <pitti> tjaalton: bryce did a MIR, and said it was a prerequisite for hotplug
[10:05] <tjaalton> oh.. :)
[10:05] <geser> RAOF: could it be bug 218516?
[10:06] <RAOF> geser: That's unlikely to make sound halt for ~1s, right? :)
[10:06] <geser> RAOF: unlikely
[10:07] <RAOF> geser: No, it's not that bug.
[10:11] <tjaalton> pitti: should the callout script be installed in /usr/lib/hal?
[10:11] <pitti> tjaalton: that sounds fine
[10:11] <tjaalton> k, will put it there
[10:16] <james_w> pitti: might be longer than 5 minutes. They're there, but not going to be built for a while
[10:16] <james_w> https://edge.launchpad.net/~james-w/+archive
[10:20] <seb128> james_w, pitti: debian upgraded policykit to 0.9, maybe something to consider for intrepid too?
[10:20] <pitti> seb128: yes, absolutely
[10:20] <tjaalton> pitti: http://users.tkk.fi/~tjaalton/dpkg/hal.diff
[10:29] <pitti> tjaalton: just one issue: in hal.install, you have
[10:29] <pitti> +debian/debian-setup-keyboard usr/lib/hal
[10:29] <pitti> tjaalton: but that won't automatically make it executable
[10:29] <pitti> tjaalton: if you ship that script in the diff.gz, it will be 644
[10:30] <tjaalton> pitti: ah, ok. I tested it by putting it in usr/bin, so it was 755 then
[10:30] <pitti> tjaalton: and the changelog incorrectly says that debian/rules would install the fdi, which it doesn't (it's hal.install)
[10:31] <tjaalton> well, I removed the lines that removed it :)
[10:31] <pitti> ah, true
[10:31] <pitti> tjaalton: so, either use 'install' in debian/rules right away, or hal.install and a chmod in debian/rules
[10:32] <tjaalton> pitti: ok, will fix it
[10:32] <pitti> tjaalton: thanks
[10:37] <pitti> seb128: ok, i386 retracer is happy
[10:37]  * seb128 hugs pitti
[10:38]  * pitti retags some broken bugs
[10:40] <dholbach> pitti: thekorn is working on wrapping it in pylpbugs
[10:40] <pitti> dholbach: yeah, I know
[10:40] <dholbach> ok :)
[10:40]  * pitti is sooo happy about a stable LP API
[10:41]  * thekorn too :)
[10:41]  * pitti hugs thekorn
[10:41]  * thekorn hugs pitti and dholbach 
[10:41] <pitti> thekorn: so it seems for bug attachments you have to use the raw protocol until launchpadlib supports them natively?
[10:42] <thekorn> pitti, no, it is supported by launchpadlib,
[10:42] <thekorn> to get a collection of attachments use bug.attachments
[10:42] <pitti> One part of Launchpad is exposed through the web service, but not supported by the current version of launchpadlib:
[10:43] <pitti>     * Uploaded files, such as bug attachments
[10:43] <pitti> hmm, so that's already obsolete?
[10:43] <tjaalton> pitti: refresh the diff, updated
[10:43] <thekorn> yes, adding and getting attachments is supported
[10:43] <pitti> nice
[10:44] <pitti> tjaalton: looks fine; happy with it, shall I commit/upload?
[10:44] <tjaalton> pitti: yes please :)
[10:51] <seb128> pitti: yeah for retracings ;-)
[11:06] <mdz> mvo: I see you found the bug, thanks
[11:07] <tjaalton> sigh, so the kernel doesn't seem to handle usb device hotplugs currently
[11:09] <pitti> tjaalton: confirmed, new hal completely breaks X, and after I manually downloaded/built -evdev it all works again now
[11:10] <tjaalton> pitti: yeah, turns out that the version from a while back was busted
[11:10] <pitti> uploaded now
[11:16] <tjaalton> hm, reboot fixed usb woes
[11:18] <Riddell> ogra: I'm moving blinken and kiten to universe since they have dependencies there, if edubuntu wants them we'll need to look at MIRs
[11:21] <soren> j/win 320
[11:21] <soren> gah..
[11:25] <pitti> mvo: for bug 253255, how can I tell update-manager to use the hardy-proposed version for a gutsy->hardy upgrade?
[11:25] <pitti> mvo: (I'd like to keep the current gutsy python-apt and test the u-m workaround)
[11:26] <pitti> ah, I see, --proposed
[11:26] <mvo> pitti: yes, that should work
[11:29] <pitti> mvo: yay, didn't crash any more \o/
[11:31] <mvo> pitti: excellent :)
[11:31] <pitti> mvo: there's a question for you from sbeattie in that bug, FYI
[11:32] <mvo> pitti: thanks, I'm having a look
[11:35] <fabbione> hey guys
[11:36] <soren> fabbione!
[11:36] <soren> dude!
[11:36]  * soren hugs fabbione 
[11:36] <pitti> hey fabbione, *hug*
[11:36] <fabbione> Hejsa nerd :)
[11:36] <soren> ;)
[11:36]  * fabbione hugs everybody
[11:37] <fabbione> how is life in Ubuntu land these days?
[11:37] <pitti> X is broken :)
[11:37] <pitti> what else
[11:38] <fabbione> no news about that :)
[11:38] <fabbione> i did stop updating X and kernel a while ago from intrepid :)
[11:38] <tjaalton> pitti: not anymore! hal fixed that :)
[11:38] <fabbione> maybe at somepoint i should decide to give it another shot ;)
[11:38] <pitti> tjaalton: as soon as the current uploads build and publish, right :)
[11:38] <pitti> fabbione: try this afternoon
[11:38] <tjaalton> pitti: good point :)
[11:39] <fabbione> pitti: maybe tomorrow.. need to work till the end of the day :)
[11:39] <fabbione> did they ever sorted the nvidia driver issue with new X?
[11:40] <pitti> fabbione: the new versions reportedly work fine, but -71 and -96 still have trouble AFAIK
[11:40] <fabbione> yeah i can't use anything != 96 on this machine unfortunately
[11:40] <fabbione> unless i want to start swapping cards around, but that's a major problem
[11:40] <pitti> tseliot: you did some porting on the old versions, so they build now, but don't work with current X; was it that?
[11:41] <fabbione> there is an unresolved symbol loading the X driver
[11:41] <fabbione> the kernel module is fine
[11:41] <pitti> fabbione: are you using the packaged versions, or upstream's installer?
[11:41] <fabbione> packaged
[11:41] <fabbione> there were no new versions from upstream a couple fo weeks ago when i last checked
[11:42] <fabbione> pitti: this machine will be dismessed soon anyway. a new dual quad core is on the way with a slightly more recent gfx
[11:42] <fabbione> or at least turned into something headless
[11:43] <fabbione> dendrobates: http://sources.redhat.com/cluster/wiki/ClusterSummit2008 <- it is going to happen.. BTW..
[11:43] <fabbione> dendrobates: assuming one of your guys want to show up.. there is still time to confirm
[11:44] <fabbione> soren: so how is life in Ålborg?
[11:44] <geser> pitti: what is a good/correct version if one takes a package from intrepid for a bugfix SRU? Would using -1~hardy1 be acceptable?
[11:45] <pitti> mdz, BenC, bdmurray, ogasawara: FYI, "ubuntu-bug -p linux" now DTRT and produces sth. like bug 254926; let me know if you need any other information
[11:45] <soren> fabbione: Pretty good. We're just about ready for the baby now. I had last week off, and got *loads* of stuff done around the house.
[11:45] <pitti> geser: that's the backport schema, and works, yes
[11:45] <fabbione> soren: ahhhhh i didn't know your wife was pregnant! congratulation
[11:45] <fabbione> soren: you will soon share my pain :P
[11:46] <soren> fabbione: Yeah, she's due September 22nd. It's getting close :)
[11:46] <fabbione> soren: oh yeah.. nice..
[11:46] <mdz> pitti: the other thing I meant to bring up in that thread was that some more general syntactic sugar would be nice...can we make 'ubuntu-bug linux' DTRT rather than requiring a flag?
[11:46] <mdz> pitti: then it would be as simple as reportbug
[11:47] <pitti> mdz: so if it's an int, regard it as a PID, otherwise as a package name?
[11:47] <pitti> sure
[11:47] <tseliot> pitti: I wrote a patch so as to make them compile with kernel 2.6.26 but they still won't work with the new Xorg API
[11:47] <mdz> pitti: yeah, that sounds reasonable
[11:48] <fabbione> pitti, tseliot: i doubt you can anything directly to the nvidia driver. AFAIR the requirement for tha symbol is in the userland binary blob
[11:48] <fabbione> so unless you want to patch X to readd that symbol, there is nothing you can do
[11:49] <tseliot> fabbione: you're right. I'm waiting for NVIDIA to add the support for the new X to their legacy drivers
[11:49] <mdz> pitti: we probably only need one of ProcVersionSignature and RunningKernelVersion, no?
[11:50] <mdz> pitti: and ProcVersion is not very interesting if they're running an Ubuntu kernel
[11:50] <pitti> mdz: with an upstream kernel we won't have /proc/version_signature, but right, we should just have one
[11:52] <Riddell> asac: are you going to upload network-manager 0.7 sometime?
[11:53] <mdz> pitti,BenC,bdmurray,ogasawara: FYI, the [modified: blah] spam is bug 250511, which should be fixed to avoid similar spam in every apport bug for the kernel
[11:53] <pitti> asac: wrt. n-m, next Thursday is alpha-4, so please don't wait until the last minute with such an intrusive change
[11:54] <mdz> pitti: I like the username/hostname anonymization, but it is a little strange because it is hard to tell that it is a placeholder
[11:54] <mdz> pitti: I wish we could use italics, but perhaps caps would be better than nothing
[11:55] <mdz> pitti: architecture info is duplicated a lot, too.  I think we should try to trim down the bits which go in the bug description and make it easy to scan visually
[11:56] <pitti> mdz: I'll start with consolidating the four ProcVersion/Uname/RunningKVer fields
[11:57] <pitti> mdz: Architecture and PackageArchitecture make sense for normal packages, but not for the kernel, right
[11:57] <mdz> pitti: what's Architecture? the GNU arch?
[11:57] <mdz> pitti: SourcePackage: linux seems redundant
[11:58] <mdz> for the bug report anyway, it should of course be in the .crash
[11:58] <pitti> mdz: Architecture is dpkg --print-architecture, while PackageArchitecture comes from dpkg -s
[11:58] <pitti> mdz: i. e. i386 firefox .deb on amd64 system
[11:58] <pitti> and uname is the kernel
[11:58] <mdz> pitti: oh. then we should only include PackageArchitecture if it doesn't match Architecture
[11:58] <pitti> i. e. i386 system on amd64 kernel
[11:59] <mdz> I think as a rule of thumb it should try to filter out things which are default
[11:59] <mdz> that way, if something is changed or unexpected, it will be immediately visible
[11:59] <mdz> whereas when there is a lot of information which is usually irrelevant, we will tend to skip over it
[11:59] <pitti> right
[12:00] <pitti> hm, how can I tell (in sh), whether a string is a number?
[12:00] <pitti> ah, test "$x" -gt "0" exits with 2
[12:03] <asac> Riddell: i am waiting for an ack from anyone using b43 driver
[12:03] <DRebellion> vorian, slangasek, just a note on monkeystudio - upstream says that they are already using the Qt Designer from the repositories. They will try to remove a few features and see if they can get QScintilla to work (they need a more up to date version than the repos).
[12:03] <asac> Riddell: that it works at all
[12:05] <asac> Riddell: fwiw, colin had a driver-issue, so once he is back ill get an ack from him that my patch in latest ~network-manager PPA works
[12:08] <mdz> pitti: not sure how portable that is; you could always do a regex or glob match
[12:09] <pitti> mdz: I don't actually rely on two; I use "if test "$1" -gt 0 2>/dev/null"
[12:09] <mdz> asac: I have a variety of weird problems on my laptop with the version in the PPA
[12:09] <mdz> asac: e.g. the applet not appearing
[12:09] <mdz> (even when it's running)
[12:09] <mdz> asac: just last night, it came up and told me I was connected to *both* the wired and wireless networks (both radio buttons filled) which seems wrong
[12:10] <mdz> pitti: sounds reasonable
[12:11] <mdz> pitti: maybe ProcEnviron should be an attachment
[12:12] <mdz> pitti: is ProblemType important in the bug report? if it includes the crash report, it's a crash, otherwise it's not. should be obvious
[12:12] <mdz> also it's in the subject
[12:12] <mdz> pitti: Date is probably not interesting for non-crashes, since it will  be the same as the timestamp on the bug
[12:13] <pitti> mdz: there are a bunch of scripts which parse ProblemType, so I'd like to keep that
[12:13] <pitti> mdz: ProcEnviron> current default is that text values with >= 5 lines become attachments
[12:13] <mdz> pitti: wouldn't a tag be better for scripts?
[12:14] <pitti> just two lines are faster to visually parse than mini-attachments IMHO
[12:14] <mdz> there are already apport-bug and apport-crash, no?
[12:14] <mdz> pitti: true, but for 99% of bugs it is not relevant
[12:14] <pitti> mdz: it would complicate the scripts (since they don't use LP directly for portability), but it would be doable
[12:14] <mdz> pitti: perhaps PATH could be omitted if it's default?
[12:15] <pitti> ok, I'll think about all of the above
[12:16] <pitti> mdz: thanks for your feedback!
[12:18] <mdz> pitti: anytime
[12:19] <pitti> mdz: ok, committed the ubuntu-bug argument sugar
[12:19] <pitti> rest after lunch
[12:23] <mpt> Are there any packages in Restricted that are part of Ubuntu Server?
[12:24]  * mpt doesn't know quite how much sense that question makes
[12:27] <Riddell> mpt: linux-restricted-modules-2.6.26-5-server ?
[12:27] <mpt> and the "linux-server" metapackage, I guess
[12:53] <jdstrand> seb128_: hi! I just noticed in the evolution calendar, if I double click on '4pm' to create an appt, the editor shows it as '8pm', and it also shows up as reminders at '8pm'. My timezone is EDT (-0400). Do you see this behavior?
[12:53] <jdstrand> (this is hardy btw)
[12:56] <seb128_> jdstrand: hi, is that google calendar or a local one?
[12:56] <jdstrand> seb128_: local
[12:56] <jdstrand> seb128_: the 'system' one specifically
[12:56] <dendrobates> fabbione: I'll look into it.
[12:56] <seb128_> jdstrand: did you configure your timezone correctly in the evolution preferences?
[12:57] <jdstrand> seb128_: it says America/New_York, this Adjust for daylight savings checked (that is what it should be (and -0400))
[12:58] <jdstrand> seb128_: I tried changing that to something else, then back, but it's still wrong
[12:58] <seb128_> jdstrand: not a known issue then no
[12:58] <jdstrand> seb128_: and you don't see it yourself?
[12:58] <seb128_> o
[12:58] <seb128_> no
[12:59] <seb128_> what view do you use? and how to create the calendar entry?
[12:59] <jdstrand> seb128_: ok-- I vaguely remember trying to do something to adjust for google calendar back when it didn't work right, and wonder if that was it. I'll try on a new user...
[12:59] <jdstrand> seb128_: thanks
[13:00] <seb128_> no problem
[13:00] <seb128_> google calendar timezone is known to be broken
[13:00] <persia> tjaalton: What sort of testing do you need for bug #44169?  Should plugging in two devices that normally need evdev generate the right result?
[13:00] <seb128_> should be fixed in intrepid now though
[13:00] <jdstrand> seb128_: oh, the view is 'Day view'
[13:01] <jdstrand> seb128_: and creating the calendar entry is just double clicking on a time within day view (eg, double click on 4pm, and the editor shows it as 8pm)
[13:02] <jdstrand> same thing for work week view
[13:03] <seb128_> works fine here, but I'm on intrepid, I don't think that's buggy on hardy though
[13:04] <seb128_> I would have noticed and we would have goten bugs about it
[13:05] <jdstrand> seb128_: same thing with a brand new user
[13:06] <jdstrand> seb128_: went through the wizard, set the timezone to America/New_York via the map, double clicked in calendar-- 4 hours off
[13:06] <seb128_> jdstrand: let me boot my desktop
[13:06] <seb128_> jdstrand: what system timezone do you use?
[13:07] <jdstrand> $ date
[13:07] <jdstrand> Tue Aug  5 08:07:00 EDT 2008
[13:07] <asac> mdz: applet not running -> the applet only shows up if it has a dbus connection to the NetworkManager daemon
[13:08] <asac> mdz: multiple connections -> this is a feature of NM 0.7, its just the UI that is missing the features to disable a connection
[13:09] <asac> the dbus calls exist already.
[13:09] <asac> however, it is still unclear how the final UI will look like.
[13:10] <seb128_> jdstrand: what timezone is listed in the appointment dialog?
[13:10] <jdstrand> America/New_York
[13:10] <mdz> asac: hopefully not a radio button :-)
[13:11] <asac> mdz: yes. imo its hard to keep the applet simple, but still put all the new features in it
[13:11] <ogra> hmm ? how do you work with more than one default route ?
[13:12] <ogra> you still need one to be the default, no ?
[13:12] <asac> mdz: last time i talked to dan (upstream lead) he didnt appeared to be too scared about the applet not being ready yet. sounded like he knew what to do
[13:12] <jdstrand> seb128_: my i386 laptop is ok
[13:12] <asac> ogra: i think the last connection you click on will become the default route
[13:13] <jdstrand> seb128_: (it was a clean hardy install)
[13:13] <asac> so when you are connected to wired 1 + wired 2, then click on wired 1 again it will take over the default route
[13:13] <seb128_> jdstrand: weird, it's ok too here, but I don't get why a new user should be wrong
[13:13] <asac> ogra: are you using the PPA version?
[13:13] <ogra> asac, but if i want to manually force it otherwise a radiobutton would be appropriate
[13:13] <seb128_> jdstrand: I tried changing the evolution timezone to newyork, doesn't make a different, the new appointement dialog still displays the selected time
[13:14] <seb128_> jdstrand: where is the hour wrong? in the "hour" in the dialog to create the calendar entry? or after validating it?
[13:14] <jdstrand> seb128_: what arch is your desktop?
[13:14] <pitti> mvo: any idea about the remaining mirror problem in bug 231966 ?
[13:14] <ogra> asac, i dont use it yet, i was stuck on hardy to make sure all the classmate stuff goes well ... but i've put classmate RC up last night, so i'll upgrade now :)
[13:14] <asac> ogra: there is a hardy build too in the PPA
[13:15] <jdstrand> seb128_: it is wrong in 'Time' section of the appt editor, but I noticed all this because I got reminders that were 4 hours off
[13:15] <asac> ogra: except for drivers there shouldnt be much a difference
[13:15] <seb128_> jdstrand: amd64 but the hardy install is an i386 one
[13:16] <jdstrand> seb128_: I'm amd64/hardy-- I'm going to try an amd64 vm (i386 vm and laptop ok)
[13:16] <seb128_> jdstrand: what timezone do you have in /etc/timezone?
[13:16] <jdstrand> America/New_York
[13:17] <seb128_> ok, so that's not a timezone mismatch
[13:17] <seb128_> let me know how the testing goes
[13:17] <jdstrand> ok
[13:19] <seb128_> jdstrand: so it's also listed at the wrong day in the calendar view?
[13:20] <jdstrand> seb128_: correct day, wrong time (always 4 hours off)
[13:20] <jdstrand> seb128_: it seems to be just my desktop-- the amd64 vm is ok too
[13:21] <jdstrand> seb128_: my desktop went through the hardy devel cycle and was not clean install-- maybe there is some cruft somewhere...
[13:21] <jdstrand> (now to find the cruft...)
[13:21] <seb128_> there should be no cruft which create misbehaviour
[13:21] <seb128_> well, I doubt of that, usually cruft are user configs
[13:21] <seb128_> and you have the issue using a new user too
[13:21] <jdstrand> that's true
[13:23] <jdstrand> seb128_: http://paste.ubuntu.com/34403/
[13:23] <jdstrand> seb128_: with the exception of evolution-webcal, they are all the same version
[13:23] <jdstrand> oh-- no they aren't
[13:23] <mvo> pitti: looking
[13:24] <ogra> mdz, you asked for comments on teh gnome dev stuff, did you look at the gnome-devel metapackage ?
[13:25] <ogra> seems to be what upstream thinks is needed for gnome development
[13:26] <Riddell> lucas, dholbach: about bug 254767, has the gem issue been solved?
[13:26] <dholbach> Riddell: I didn't know there was an issue - best to ask lucas
[13:26] <ogra> Riddell, thanks for taking care of the kdeedu stuff, i'm fine with additions/removals as needed
[13:27] <seb128_> jdstrand: the versions are correct
[13:28] <Riddell> dholbach: if you ack it I assume you know what you're talking about :)
[13:29] <dholbach> Riddell: the only reference to gems is:
[13:29] <dholbach>   * RubyGems did not work completely due to a gem_relude mechanism . This
[13:29] <dholbach>     issue has been fixed. (Closes: #492206)
[13:29] <jdstrand> seb128_: for giggles I md5'd /etc/localtime and it's the same on the desktop and in the vm
[13:31] <persia> I seem to remember some larger conversation about all the different ways that gems were broken during one of the Server Team meetings.  Maybe someone from there knows?
[13:31] <pitti> mdz: ah, ProblemType is tricky; I use that as an anchor to find out where in the description the apport formatted report starts (ProblemType: always comes first, the rest in alphabetical order)
[13:32] <pitti> mdz: I could invent another arbitrary anchor, of course
[13:33] <seb128_> jdstrand: date -u?
[13:34] <jdstrand> $ date -u
[13:34] <jdstrand> Tue Aug  5 12:34:09 UTC 2008
[13:34] <seb128_> ok, everything seems fine, and I don't see why the system configuration should impact on that anyway
[13:34] <seb128_> your evo preferences point to a timezone
[13:35] <jdstrand> seb128_: I just tried changing the timezone to Prague via right click on time panel applet, then changed back, and still wrong
[13:35] <seb128_> and you defined an event in the same timezone
[13:35] <pitti> thekorn: hm, does Bug().date work for you? I just get an XPath-Expr error
[13:35] <seb128_> I did let my system on european time
[13:35] <seb128_> changed the evo calendar to new york
[13:35] <jdstrand> (with an evolution --force-shutdown in between)
[13:35] <pitti> thekorn: same for date_reported
[13:35] <seb128_> it shifted the events in the calendar correctly
[13:35] <seb128_> since the calendar was on new york time then
[13:36] <seb128_> and creating an event was adding it at the right new york time too
[13:38] <jdstrand> seb128_: I just now used evo preferences, changed it to Prague-- double clicked an appt in evo at 12pm-- it shows the Time fields in the edit dialog as 4pm, but the timezone itself is shown as 'Europe/Prague'
[13:38] <jdstrand> odd
[13:39] <pitti> thekorn: ah, works on main branch, just not in intrepid package; nevermind
[13:41] <thekorn> ah, ok
[13:42] <pitti> thekorn: what is the official way to get the date? .date, .date_reported, or .get_date()?
[13:43] <thekorn> pitti, date_reported == date
[13:43] <thekorn> both are properties, get_date is the get function for both
[13:43] <pitti> ok, thanks
[13:49] <Riddell> zul: can you tell me if bug 241041 is ok to sync?
[13:49] <mdz> pitti: indeed, perhaps something even better for visual scanning (like ----)
[13:50] <zul> Riddell: just a sec
[13:52] <zul> Riddell: yeah it is soren is adding support for xen to vmbuilder anyways so it will be depreciated anyways
[13:53]  * ogra is brave and FINALLY runs update-manager -d on his hardy
[13:53] <mvo> ogra: do you have a kvm capable system?
[13:53] <ogra> mvo, vbox only
[13:53] <mvo> ogra: if so, you may want to try the new sandbox upgrade tester first
[13:53] <mvo> ogra: does your system not have the required hardware support for kvm?
[13:53] <ogra> nh, no kvm love for my cpu
[13:53] <ogra> nope, it doesnt
[13:54] <mvo> ogra: aha, ok. then I will need to find another "volunteer" :)
[13:54] <ogra> sorry ... i opted for the cheaper CPU to ge more ram :)
[13:54] <stgraber> ogra: oh, your lappy doesn't have the VT extension ? that's one of those cheap Core2Duo ?
[13:54] <ogra> yep
[13:54]  * mvo mubles something about cheapo
[13:55] <StevenK> I thought all Core 2's had VT. Or was that 64-bit extensions
[13:55] <ogra> but its even in that setup overpowered more ram is more important :)
[13:55] <stgraber> StevenK: they all are 64bit but some aren't VT (discovered that when installing my grandmother's lappy, had to use VB instead of KVM)
[13:55] <ogra> Intel(R) Core(TM)2 Duo CPU T5550  @ 1.83GHz
[13:57] <ogra> i think the T5550 is the biggest one you can get without VT
[13:58] <ogra> (an on a sidenote i really prefer vbox over kvm)
[13:59] <elmo> I'm pretty sure all Core2 have VT, it's just disabled by some BIOSes (sic)
[14:00] <stgraber> elmo: not according to Intel's website
[14:00] <ogra> elmo, then my bios is omitting the option
[14:01] <elmo> stgraber: oh?
[14:01] <soren> stgraber: You're rgith.
[14:01] <soren> right, even.
[14:01] <soren> There are a few Core2Duo models that don't have those options at all.
[14:01] <soren> ...and lots more machines that come with those options disabled in the BIOS.
[14:02] <stgraber> elmo: http://www.intel.com/products/processor_number/chart/core2duo.htm
[14:02] <persia> There are also plenty of new Intel chips that don't have VT (A100, A110, Atom, etc.)
[14:02] <elmo> stgraber: interesting
[14:03] <soren> persia: Only all the low-power things, right?
[14:03] <ogra> well, the atom has HT
[14:03] <Riddell> jdstrand, kees: bug 236051 and bug 238883 going to get reviewed this week?
[14:03] <ogra> at least some models
[14:03] <persia> soren: Right.
[14:04] <persia> ogra: Only the special ones that aren't in many devices yet, and only Atom.
[14:04] <ogra> right
[14:15] <fta> last upgrade (intrepid) killed my laptop. i'm stuck in gdm. usb mouse not detected (but the touchpad is fine) and worse, no keyboard (then no way to log in), except the alt+Fx so I can get in console and login there. Is that a known issue ?
[14:16] <Hobbsee> fta: yes.
[14:16] <fta> Hobbsee, good. bug ? workaround ?
[14:17] <Hobbsee> fta: no idea about #, tjaalto*n mentioned it in here earlier
[14:18] <Hobbsee> fta: add 'Option "AllowEmptyInput" "false" to ServerFlags section
[14:23] <fta> Hobbsee: thanks. it worked.
[14:24] <Hobbsee> fta: \o/ (but really, you should thank tjaalton for the workaround)
[14:25] <fta> tjaalton, thanks for the AllowEmptyInput workaround !
[14:25] <asac> empty input
[14:25] <asac> hah
[14:25] <tjaalton> fta: just update hal and enjoy input-hotplug goodness
[14:25] <asac> i knew that my typing usually doesnt make sense
[14:25] <asac> ;)
[14:25] <fta> eheh
[14:26] <fta> debian bug 492140
[14:26] <asac> "EnableBrainInput" "true"
[14:26] <ogra> *shudder*
[14:26]  * ogra doesnt want all the stuff he thinks on screen 
[14:27] <jdstrand> seb128_: I did 'strace -f evolution -c calendar' but nothing popped out at me as wrong
[14:27] <asac> ogra: you can train that input method ;)
[14:27] <ogra> heh
[14:27] <asac> at least you should train the enter key properly
[14:27] <asac> otherwise your thoughts end up in irc channel
[14:27] <ogra> yeah, that would be evil
[14:27] <persia> asac: We need better HW drivers.  If I send you HW, will you write a driver?
[14:28] <jdstrand> seb128_: (I compared it to the strace in the amd64 vm)
[14:28] <asac> persia: at least the spec is not yet patented - i hope
[14:28] <ogra> persia, better get a good parcel service if you send your brain around :)
[14:28] <asac> and take care that your brain supports hotplug + coldplug ;)
[14:29] <ogra> *g*
[14:29] <fta> tjaalton: which hal do i need ? i have 0.5.11-3~ubuntu4, except for hal-device-manager (0.5.9.1-6ubuntu5)
[14:29] <persia> asac: No, there are several open specs, and good software for BCI devices.  Just not much open source beyond basic data collection, some MIDI generators, and mouse drivers.
[14:30] <tjaalton> fta: ubuntu5
[14:30] <asac> persia: really? ... thats in japan?
[14:30] <persia> asac: Actually, Germany is the only country I know with well-supported commercial devices (sold as medical equipment)
[14:31] <persia> There's some cheap consumer stuff here (and in the states), and better consumer stuff promised soon from various places.  There's also a bunch of hobby stuff.
[14:32] <jdstrand> seb128_: this sounds very similar: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491095
[14:32] <fta> tjaalton, "Published 2 hours ago". I see.. it's coming, great
[14:33] <jdstrand> seb128_: which points to http://bugzilla.gnome.org/show_bug.cgi?id=543517
[14:33] <seb128_> jdstrand: right, and there is no upstream comment
[14:34] <jdstrand> seb128_: as it seems to not 'be just me', I can file a bug too-- would you like it in LP linked to the debian and bugzilla bugs?
[14:34] <seb128_> jdstrand: yes please
[14:34] <jdstrand> ok
[14:48] <pitti> mdz: so, I can read bugs with the "--- " separator now, but since Launchpad doesn't create them that way, I can't actually write them for now; but at least I got the other cleanup now
[14:53] <jdstrand> seb128_: bug #254980
[14:53] <jdstrand> seb128_: it gets even more fun if I 'save' the appointment
[14:54] <jdstrand> seb128_: eg, double click 12pm, shows up in editor as 4pm, save, shows up in evolution as 8pm
[14:54] <jdstrand> seb128_: would you mind reading that bug and letting me know of anything else you need/want
[14:54] <jdstrand> ?
[14:55] <seb128_> jdstrand: thanks for the details, I copied your comment upstream and asked on IRC, the guys who work on the calendar are not connected at the moment but I'll have them to look at the issue when they are
[14:56] <seb128_> jdstrand: the description seems to be detailled enough, nothing else required from my part, let's see if upstream has some ideas
[14:56] <jdstrand> seb128_: cool, thanks
[14:56]  * jdstrand nods
[14:56] <mdz> pitti: cool
[14:57] <mdz> pitti: will you be doing an apport upload soon?
[14:57] <pitti> mdz: yes, planned for today; just collecting some other issues
[14:57] <pitti> mdz: that upload will enable it by default again
[14:58] <pitti> I fixed the retracers this morning (yet again...), so we shuold be good to throw the switch
[14:58] <mdz> pitti: great, thanks
[14:58]  * pitti bows to "scary op" mdz
[14:58] <mdz> pitti: I saw that the launchpad API lib has been released, hopefully that will help things break less
[14:58] <pitti> mdz: oooooooooooooooh yes, I'm looking forward to use it :)
[14:59] <pitti> I read about the ABI and the library this morning and discussed some packaging issues with james_w
[15:02] <soren> Oh, you're packaging it? I won't bother then :)
[15:03] <hwilde> who maintains the  experimental three-way merge of the grub menu.lst when updating kernels
[15:03] <persia> soren: There's a candidate on REVU if you want to play
[15:03] <james_w> packages are built in my PPA as well now
[15:03] <james_w> ~james-w
[15:04] <soren> Coolness.
[15:04] <persia> james_w: Careful: tell everyone that and they won't be looking at the REVU package :)
[15:04] <soren> I've already used the API a bit. It beats the heck out of the horrid screenscraping I used to be doing :)
[15:04] <james_w> Testing welcome, but reviews on REVU would be great as well if you know any python packaging
[15:04] <james_w> persia: true :-)
[15:05]  * soren takes a look
[15:07] <soren> james_w: Does it really need simplejson to build?
[15:07] <james_w> soren: wadllib?
[15:07] <james_w> that needs it for the testsuite
[15:07] <soren> Yup
[15:08] <soren> Oh.
[15:08] <pitti> soren: you haven't used p-lp-bugs so far?
[15:08] <pitti> and did screenscraping yourself?
[15:08] <soren> Yes.
[15:08] <soren> I've not looked at bugs, but people.
[15:09] <pitti> ah
[15:09] <soren> Someone told me py-lp-bugs didn't do that.
[15:09] <pitti> that's true
[15:09]  * sistpoty|work feels scraped
[15:09] <soren> I use it to provide e-mail forwarding for ubuntu-dk members. It kept falling apart, so I'm quite happy with this new API.
[15:27] <pitti> BenC, mdz, ogasawara: FYI, bug 254995 is with the updated apport and some redundancy removed; also "ubuntu-bug linux" DTRT now
[15:38] <BenC> pitti: excellent
[15:38] <ogra_cmpc> soo ... i have no screen anymore after upgrading my laptop
[15:38] <ogra_cmpc> (intel graphics)
[15:38] <persia> ogra: Which chipset?
[15:38] <pitti> BenC: working on bug 241322 now; the requirements are still the same?
[15:38] <ogra_cmpc> moving xorg.conf out of the way at least keeps it from restarting and i have the gdm drum sound
[15:38] <tjaalton> ogra_cmpc: you have the latest evdev and hal installed?
[15:39] <mdz> pitti: you rock
[15:39] <ogra_cmpc> tjaalton, i did a dist-upgrade from hardy just now
[15:39] <ogra_cmpc> thats been my first boot
[15:39] <tjaalton> blank screen sounds like usplash/kernel
[15:39] <pitti> *beam* :)
[15:39] <ogra_cmpc> X seemed not to like my xorg.conf i needed for trh touchscreen
[15:39] <hwilde> ogra_cmpc,  if you run updates you should get more
[15:39] <hwilde> if thats your first boot
[15:39] <ogra_cmpc> so removing that and i hear gdm swtarting
[15:40] <ogra_cmpc> *starting
[15:40] <ogra_cmpc> i booted without splash, no changes
[15:40] <ogra_cmpc> persia, 965 iirc
[15:40] <tjaalton> ogra_cmpc: disable failsafe from gdm.conf and start x with the xorg.conf to see where it fails
[15:41] <ogra_cmpc> well, itrs an old hand crafted xorg.conf
[15:41] <tjaalton> still :)
[15:41] <hwilde> I would ctrl+alt+f1 and run the upgrades
[15:41] <hwilde> but thats jus me
[15:41] <ogra_cmpc> hwilde, there is no consiole
[15:41] <ogra_cmpc> black screen
[15:41] <persia> ogra_cmpc: Ah.  I had what looked like that on a 945 with an upgrade in the last couple hours, but it turned out to be X only listening to one of the mice and ignoring the keyboard (and gdm sleeping)
[15:41] <hwilde> :/
[15:42] <ogra_cmpc> well, gdm drums clearly
[15:42] <tjaalton> ogra_cmpc: I had to switch to the console before usplash to see my screen (965)
[15:42] <ogra_cmpc> hwilde, and which upgrades ? i did a fresh dist upgrade 10 min ago :)
[15:42] <hwilde> I dunno... dist-upgrade just goes from one kernel to the other, then sometimes there are more updates once you are up to the newer kernel
[15:42] <ogra_cmpc> tjaalton, durin usplash ?
[15:43] <ogra_cmpc> i'll try that
[15:43] <tjaalton> ogra_cmpc: yes, as early as possible
[15:43] <zyga> hello everyone :/
[15:43] <ogra_cmpc> hwilde, it installed about 2000 packages etc
[15:43] <ogra_cmpc> oh, funny
[15:43] <hwilde> ogra_cmpc, ok but I will bet you whenever you get back in that there are updates  :)
[15:43] <ogra_cmpc> ctrl-alt-del gives me huuuge letters ion the screen
[15:44] <tjaalton> ogra_cmpc: same here
[15:44] <ogra_cmpc> meh, but switching away in usplash gets me to a black screen again
[15:44] <ogra_cmpc> no console
[15:44] <tjaalton> weird
[15:44] <ogra_cmpc> gdm drums though
[15:45] <tjaalton> oh. you need to shut down the machine
[15:45] <ogra_cmpc> ah, reboot isnt enough ?
[15:45] <tjaalton> nope
[15:46] <ogra_cmpc> same behavior
[15:46] <ogra_cmpc> black screen, backlight on
[15:47] <ogra_cmpc> flashing several times while switching to X, then gdm drumming
[15:47] <ogra_cmpc> bah, and now it looks like i get a fsck :(
[15:48] <tjaalton> heh :)
[15:48] <ogra_cmpc> or something wipes my disk recursively, who knows
[15:49] <BenC> pitti: yes, nothing's changed
[15:50]  * ogra_cmpc waits patientlly ... twiddling thumbs
[15:50] <tseliot> ogra_cmpc: can you boot in recovery mode and get your /var/log/Xorg.0.log?
[15:50] <ogra_cmpc> BenC, GPE storm detected on boot, is that something i should worry about ?
[15:51] <ogra_cmpc> tseliot, i actually belive its the framebuffer misbehaving, but i'll check the file
[15:52] <mdz> my up arrow key is now a shortcut for print screen
[15:52] <ogra_cmpc> how handy
[15:52] <hwilde> I like keytouch
[15:52] <tjaalton> mdz: change the kb model to evdev
[15:52] <mdz> it is actually extremely inconvenient, because it is a key I tend to press several times before I realize what is happening
[15:52] <tjaalton> that should be forced though
[15:53] <BenC> ogra_cmpc: err, sounds bad
[15:53] <ogra_cmpc> ooooh
[15:53] <mdz> tjaalton: thanks...is there a more permanent and automatic fix on the way?
[15:53] <ogra_cmpc> i have X !!!
[15:53] <ogra_cmpc> bootin 10 times with usplash disabled seems to have gotten me there
[15:53] <mdz> tjaalton: my xorg.conf is entirely autogenerated
[15:53] <ogra_cmpc> smells like a race
[15:54] <ogra_cmpc> wrong resolution though
[15:54] <tjaalton> mdz: yes, it should be forced always
[15:54] <mdz> tjaalton: setxkbmap -model evdev didn't fix it
[15:54] <tjaalton> mdz: as evdev, because gnome is borked
[15:54] <mdz> tjaalton: is there a bug number for this?
[15:55] <tjaalton> hm, maybe I need to test the latest fedora patches for real..
[15:55] <tjaalton> mdz: nope
[15:55] <tjaalton> not that I know of anyway
[15:55] <mdz> tjaalton: on which package should I file it?
[15:55] <tjaalton> ogra_cmpc: good for you :)
[15:55] <tjaalton> mdz: xorg-server
[15:55] <ogra_cmpc> so now i run a dpkg-reconfigure xserver-xorg to get a clean xorg.conf ....
[15:56] <tjaalton> ogra_cmpc: it would be nice to know what broke it in the old config
[15:56] <ogra_cmpc> it points the keyboard setup to kbd, should i change that ?
[15:56] <ogra_cmpc> \well, i booted serveral times with no config at all
[15:56] <tjaalton> ogra_cmpc: keyboard/mouse sections are completely ignored now
[15:56] <ogra_cmpc> ah, k
[15:56] <tjaalton> ogra_cmpc: the blank screen bug is different
[15:57] <ogra_cmpc> because i dont have any keyboard input (apart from console switching) in X now
[15:57] <tjaalton> ogra_cmpc: check the version of hal
[15:57] <ogra_cmpc> i would expect the latest but lets see
[15:58] <tjaalton> depends on the mirror you use
[15:58] <ogra_cmpc> bah
[15:58] <ogra_cmpc> ubuntu4
[15:58]  * ogra_cmpc switches mirrors
[15:58] <tjaalton> right, install u5
[15:59] <mdz> tjaalton: bug 255008
[16:01] <persia> tjaalton: Thank you for the vastly improved input subsystem: it detects and autocalibrates my touchscreen now.
[16:02] <ogra_cmpc> sweet !!
[16:02] <tjaalton> mdz: cool
[16:02]  * ogra_cmpc eagerly waits to see that 
[16:02] <tjaalton> persia: that's.. probably unexpected but nice :)
[16:03] <sladen> persia: what model/device do you have?
[16:03] <zyga> does cannonical have a irc channel (for any official/semi official things)?
[16:04] <tjaalton> ogra_cmpc: intel 2.4.0 seems to work a bit better, although console seems broken still
[16:04] <pitti> zyga: C does not have a channel on freenode, or any 'official' channel; we do have a company-internal server, though
[16:04] <persia> sladen: Kohjinsha SR series with a DIALOGUE PenMount USB
[16:05] <ogra_cmpc> hmm, intresting ...
[16:05] <zyga> pitti: I see thanks
[16:05] <ogra_cmpc> NM tells me it adds my DVD to the hal db
[16:06] <tjaalton> bah, blank screen after reboot
[16:06]  * zyga has just received a notice that his employer went belly-up and is now looking for a new job
[16:06] <sladen> tjaalton: back to your earlier question;  PnP provides enumeration; so a check for 'WACf004' ... which shows there's a serial port at 0xf123 irq 0x42;  so kernel pops up /dev/ttyS3;  init.d/*wacom* (in future, HAL), maps that to  /dev/wacom  X (since broken in the last release) spots that I talks Wacom down that symlinked serial port
[16:06] <sladen> persia: okay, USB HID device  ("boring" ;-)
[16:06] <pitti> zyga: if you want to ask any non-Ubuntu business issue, please see http://www.canonical.com/aboutus/contactus
[16:07] <persia> sladen: Yes, well, but it didn't autoclibrate in Hardy.
[16:07] <zyga> thanks
[16:07] <ogra> persia, no touchscreen love for me :/
[16:07] <ogra> and xchats themeing is badly broken
[16:07] <persia> ogra: No?  I thought you said you had the same device at UDS :(
[16:07] <sladen> persia: in hardy it would just be mapped (added together will all other mouse-like input) and read through /dev/input/mouse
[16:08] <sladen> persia: here, X is now treating it as a separate input device
[16:08] <ogra> IDEACOIDC 6680
[16:08] <ogra> thats what i have
[16:08] <persia> sladen: Right, which is significantly more sensible.
[16:08] <ogra> hal reports it as /dev/input/event2
[16:09] <ogra> but doesnt seem to handle it at all
[16:09] <ogra> in hardy it worked but was miscalibrated
[16:09] <sladen> ogra: grep WAC /sys/bus/pnp/devices/*/id  ?
[16:09] <ogra> nothing
[16:09] <ogra> its a USB device
[16:10] <ogra> not sure that registers on pnp
[16:10] <sladen> ogra: no, it wouldn't if it's USB
[16:10] <ogra> and its not wacom compatible either if that was your intention
[16:11] <ogra> it worked fine with the evtouch driver before
[16:11] <persia> ogra: What events does it expose (according to lsinput)?
[16:11] <sladen> (input-utils)
[16:11] <pitti> BenC: ah, the current "kernel crash" mode in the apport UI says "Your system might become unstable now and might need to be restarted."; that was for the original (2 years back) specification, but is not true any more, right? vmcore reading, etc. will happen after the next reboot only
[16:13] <ogra> persia,  http://paste.ubuntu.com/34455/
[16:13] <mdz> pitti: echo c > /proc/sysrq-trigger if you want a real live test :-)
[16:13] <mdz> pitti: yes, the dump will only be there after the system has restarted and written the dump
[16:14] <mdz> pitti: however, I think it would also be useful to capture bugs other than crashes, e.g. BUG() (in which case the message would be appropriate)
[16:14] <mdz> pitti: but that's a separate project
[16:14] <pitti> mdz: ah, I used cp /somefile /var/crash/vmcore so far; but will do that as well :)
[16:14] <BenC> pitti: right
[16:14] <persia> ogra: That matches the list of services on mine :(
[16:15] <ogra> weird
[16:15] <BenC> pitti: if apport can detect that an oops occured without bringing the system down, that old feature is useful
[16:16] <pitti> BenC: not right now, only if something manually triggers it (calls kernel_hook)
[16:16] <tjaalton> ogra: it's probably evtouch which made the server fail then, since the driver doesn't seem to work with xserver 1.5
[16:16] <ogra> meh
[16:16] <pitti> BenC: but let's stash this as a separate project, yes
[16:17] <ogra> tjaalton, and possible fix in sight ?
[16:17] <ogra> i know it needs evtouch
[16:17] <tjaalton> ogra: seems like it's trivial, bug 254848
[16:18]  * ogra tries that ...
[16:18] <ogra> oh, meh, need to update my pbuilder first
[16:18] <mdz> pitti: this was #3 on the apport/kernel list I sent you
[16:19] <ogra> its intresting btw that gdm drops me into a wrong resolution ... the desktop then works as expected
[16:20] <mdz> pitti: do you happen to know if bryce has his X hooks working now?  they don't seem to be in the packages yet
[16:20] <pitti> mdz: haven't heard about this since the sprint
[16:20] <mdz> pitti: it's on the platform team 8.10 list
[16:21] <BenC> pitti: sounds good
[16:33] <BenC> soren: ping...how's the -virtual kernel in intrepid looking for your purposes?
[16:34] <soren> BenC: I must admit I never found the opportunity try it. Could you send me the link again?
[16:38] <BenC> soren: it's in intrepid proper now
[16:38] <BenC> Although I guess I should add it to linux-meta, but linux-image-2.6.26-5-virtual package exists
[16:38] <soren> BenC: Oh, that's why I didn't find it then :)
[16:38] <soren> BenC: I'll take it for a spin tomorrow. I'm a bit tied up right now.
[16:41] <BenC> soren: no rush on my end...just want to make sure it is suitable
[16:48] <fabbione> BenC: what's the deadline to get a couple of kernel modules in before intrepid releases?
[16:48] <BenC> fabbione: ASAP
[16:49] <fabbione> BenC: ASAP is within this week is fine?
[16:49] <fabbione> BenC: or ASAP like 20 days ago?
[17:08] <ogra> (II) XINPUT: Adding extended input device "IDEACO^D  IDC 6680" (type: MOUSE)
[17:08] <ogra> (II) config/hal: Adding input device SynPS/2 Synaptics TouchPad
[17:08] <ogra> (II) LoadModule: "synaptics"
[17:08] <ogra> hmm
[17:09] <ogra> (II) IDEACO^D  IDC 6680: Found mouse buttons
[17:09] <ogra> (II) IDEACO^D  IDC 6680: Configuring as mouse
[17:09] <ogra> bah, just because it has a button it desnt necessarily need to be a mouse you silly thing
[17:10] <BenC> fabbione: this week is good
[17:10] <tkamppeter> Anyone knows whether heno is around? I have sent him a mail yesterday and got no answer.
[17:13] <stgraber> tkamppeter: he's
[17:14] <stgraber> tkamppeter: he sent some mails to ubuntu-qa 30 mins ago
[17:15] <pitti> ogra: wait until X automatically picks up your bluetooth mobile as keyboard
[17:15] <ogra> haha
[17:16] <soren> ogra: What is that IDC 6680 thing really?
[17:16] <ogra> soren, a touchscreen
[17:16] <soren> Ah
[17:16] <soren> Heheh :)
[17:17] <pitti> but shouldn't that be treated as a mouse?
[17:17] <ogra> needing the evtouch driver
[17:17] <ogra> no
[17:18] <ogra> so for the toplevel it loads evdev which might be ok, not sure ... but for the actual /dev/input/event2 device it then loads synaptics
[17:18]  * ogra looks where to put an fdi file to override that
[17:19] <pitti> BenC: new apport with kernel magic uploaded (enabled by default now, too)
[17:19] <tjaalton> ogra: evtouch needs a fdi file to load evtouch for that device
[17:19] <ogra> tjaalton, right
[17:19] <BenC> pitti: sweet, thanks...I'll test it later today
[17:19] <ogra> thats what i figured, but i'm not sure evdev is actually wrong for the topevel device
[17:19] <tjaalton> ogra: /etc/hal/fdi/policy
[17:20] <tjaalton> that's the place for local files
[17:20] <ogra> thanks, i'll play with that
[17:20] <pitti> BenC: so far I copied two random files to /var/crash/vmcore{,.log} and simulated a boot with "sudo /etc/init.d/apport start"
[17:21] <BenC> pitti: I'll try to get a real crash and real vmcore
[17:24] <seb128> pitti: is dbus maintained in bzr? any objection if I do an upload to enable the x11 script again in dbus-x11?
[17:25] <pitti> seb128: no bzr; no, please go ahead, that'll drop another delta to Debian
[17:25] <seb128> thanks
[17:25] <seb128> upstream decided now that dbus is a system thing so they made gnome-session rely on it being started before
[17:26] <pitti> aah
[17:26] <pitti> and they stopped relying on it promoting GNOME env vars?
[17:26] <pitti> (to activated backends)
[17:26] <ogra> they discussed the dbus system art as kernel module in rague
[17:26] <ogra> *part
[17:26] <ogra> *prague
[17:26] <ogra> *sigh*
[17:26]  * pitti hands ogra a new P key
[17:27] <asac> ogra: wasnt that marcel holtmann?
[17:27] <pitti> modprobe dbus? argh
[17:27] <asac> pitti: dbus instead of libnl for instance ;)
[17:27] <ogra> asac, well with (kai) dbus upstream and davidz at the table
[17:27] <elmo> hahahahahahahaha
[17:27] <elmo> seriously?
[17:27] <ogra> and they werent joking
[17:27] <asac> that was one of the use cases according to marcel
[17:28] <pitti> asac: oh, btw, if you upload n-m 0.7, can you please make sure that the init script does not run for rc0 and rc6, to save us another symlink transition later on?
[17:28] <ogra> but there was beer ivolved ... so ...
[17:28] <seb128> pitti: yes
[17:28] <pitti> asac: (I guess 0.7 moves /etc/dbus-1/event.d/25NetworkManager to a proper init script)
[17:29] <asac> yes.
[17:29] <pitti> asac: great, thanks
[17:31] <asac> pitti: is "multiuser" the right?
[17:32] <pitti> asac: no, please don't use multiuser, that's deprecated
[17:32] <asac> ok
[17:32] <pitti> asac: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-June/000430.html
[17:45] <bigon> is it intended that networkmanager is only work after logging in a graphical session?
[17:48] <hwilde> who maintains the  experimental three-way merge of the grub menu.lst when updating kernels
[17:49] <hwilde> nobody wants to take credit? :)
[17:50] <asac> bigon: depedns
[17:50] <asac> bigon: 0.6 needs to get your credentials from keyring, so networks that require secrets (wpa etc.) need a running session
[17:51] <ogra> hwilde, ??
[17:51] <ogra> can you elaborate ?
[17:51] <asac> bigon: open networks and normal wired ones should work even in 0.6
[17:51] <bigon> asac, well logginin in console and try to run nm-tool just after boot doesn't work
[17:52] <ogra> is nm-tool suposed to have any functionality ?
[17:52] <ogra> i thought it was only for reporting avalable interfaces
[17:52] <asac> bigon: plesae check that NetworkManager process is actually running
[17:52] <asac> ogra: right. its just introspection
[17:52] <bigon> asac, networkmanager and networkmanagerdispatcher are running
[17:52] <bigon> as root
[17:53] <asac> sure
[17:53] <asac> bigon: so what does nm-tool give you?
[17:53] <hwilde> ogra, when you run dist-upgrade and it updates the kernel if you have a modified /boot/grub/menu.lst it prompts you what to do, one of the options is experimentla three-way merge,  who is that?
[17:53] <bigon> asac, networkmanager is not running or somethink liketaht
[17:54] <ogra> hwilde, thats ucf taking care of you having changed the wrong bits of the file :) only change the kopt line and it will stay quiet
[17:54] <bigon> but actually both process are there, I loggin in gnome goes back to the console and then I get some results
[17:54] <asac> have you tried to run nm-tool as root?
[17:55] <ogra> hwilde, thats thats by no means experimental and was like that in hardy as well :)
[17:55] <ogra> thats
[17:55] <ogra> -thats i meant
[17:55] <bigon> asac, good question I will reboot and check that
[17:56] <hwilde> ogra, but I want it to maintain my irqpoll routeirq and acpi=off settings  it keeps replacing that at the end of the kernel line
[17:57] <ogra> hwilde, where do you add them ?
[17:57] <ogra> hwilde, # kopt= is the right place ... then run update-grub afterwards, the noise will stop and your kernel lines will have the right settings
[17:58] <pitti> soren: did you see mvo's regression report in bug 234062?
[17:59] <mvo> pitti: we talked about it earlier, I uploaded another sru to -proposed that should fix this regression (give me a sec, I dig out the bugnumber)
[17:59] <hwilde> ogra, cool I did not know kopt.    it also overwrites root=/dev/sda1 with the UUID is there a flag to disable that
[17:59] <mvo> bug 254966
[17:59] <pitti> mvo: ok, thanks
[18:00] <ogra> hwilde, check if you fine the uuid anywhere in that file
[18:00] <ogra> *find
[18:00] <ogra> but uuid is actually the better way, why do you want to keep the old notation (which is going to vanish at some point) ?
[18:01] <ogra> (uuid is likely also in the current kopt line)
[18:02] <bigon> asac, yeah actually nm-tool works as root
[18:02] <ogra> might be because you have no seeion dbus without a graphical session
[18:02] <ogra> *session
[18:02] <ogra> and normal users cant access the system dbus
[18:03] <ogra> that always needs to go through the session bus
[18:03] <ogra> so it will work fine in an xterm/gnome-term but likely not on console
[18:04] <asac> bigon: great.
[18:04] <asac> bigon: what wifi chipset do you have?
[18:06] <hwilde> ogra, I have to clone the image between hundreds of machines so I can't use uuid.   what i'm really asking is if the experimental three way merge could JUST upgrade the kernel version and not touch the rest of the options on that line
[18:06] <norsetto> pitti rulez: https://edge.launchpad.net/~we-love-pitti
[18:06] <pitti> aaargh
[18:06] <bigon> asac, Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection
[18:06] <asac> bigon: ok. then have fun ;)
[18:06] <ogra> hwilde, grub uses kopt since it exists
[18:07] <asac> i am searching for users with b43 driver :)
[18:07] <ogra> hwilde, and there is nothing experimental in ucf
[18:07] <asac> ogra: dont you have something like that?
[18:07] <asac> ;)
[18:07] <bigon> asac, btw I get some warning when rebooting/shutting down, networkmanager says that it has been disconnected from the bug
[18:08] <jdstrand_> pitti: oh, oh-- I should sooo join that team :)
[18:08] <asac> bigon: s/bug/dbus/ ?
[18:08] <ogra> hwilde, i would suggest something like a sed line that catches the kopt line, changes it to your needs and seeds the right UUID for such a case, thats a small script
[18:08] <bigon> asac, yeah :)
[18:09] <asac> bigon: thats known and wont be fixed until NM 0.7
[18:09] <ogra> hwilde, hwo do you know the kernel always calls the disk sda1 ? there is no guarantee at all anymore, its a total matter of luck
[18:11] <bigon> asac, ok thx for your help
[18:11] <ogra> asac, on my old lappie i have a b43 i think ... but thats still on gutsy
[18:11] <ogra> and is amd64 with 1G ram ... which is a lethal combo for b43 (or at least was)
[18:11] <geser> pitti: you are not a member of that team yet? :)
[18:12] <pitti> geser: I deny even the slightest responsibility, or even affiliation to that :)
[18:12] <asac> ogra: please upgrade ;)
[18:12] <ogra> asac, meh
[18:12] <asac> or well. i can also wait till colin returns tomorrow
[18:12] <ogra> how urgent do you need a test
[18:13] <ogra> one upgrade per day is really enough for me :)
[18:13] <jdstrand_> pitti: it's a pretty bad-@#$ picture too, with that smirky/snarl :P
[18:13] <asac> hehe ... it blocks NM 0.7
[18:14] <asac> ogra: you could install i386 hardy on that thing ;)
[18:14] <asac> then its one upgrade + one install ;)
[18:14] <norsetto> jdstrand_: hey, mind you words when you talk about THE pitti
[18:14] <ogra> it has daa i still need to backup
[18:14] <ogra> *data
[18:14] <jdstrand_> norsetto: it was meant as a compliment :)
[18:14] <norsetto> jdstrand_: ;-)
[18:15] <jdstrand_> (in the Chuck Norris vein)
[18:20] <hwilde> ogra, it's sda1 on all of 180+ machines that I have running with that image.  why would that ever change
[18:21] <warp10> norsetto: we plan to print some t-shirts too. Do you want one?
[18:21] <norsetto> warp10: absolutely!
[18:22]  * norsetto plans to have his t-shirt signed
[18:22] <ogra> hwilde, because the kernel or udev decide to
[18:22] <slangasek> you people disturb me
[18:23] <ogra> slangasek, envious ?
[18:23] <warp10> norsetto: signed t-shirts are available at twice the price
[18:23] <slangasek> ogra: frightened
[18:23] <ogra> heh
[18:23] <ogra> slangasek, you choose to take the job ... now live with your rockstar image :P
[18:24] <slangasek> when I signed on, I was told only the community team had to have rockstar images
[18:24] <mvo> I need a good way of saying "All files that have been downloaded so far are kept and do not need to be downloaded again if you decide to run the upgrade again" (context is when the connection drops during a release-upgrader download. any suggestsions?
[18:27] <norsetto> mvo: if you need an hand with sru-verification, I'll be glad to join
[18:28] <mvo> norsetto: hands for this are always welcome! sbeattie and bdmurray are probably better persons to talk to nowdays (I'm doing verifications very rarely only these days)
[18:29] <norsetto> mvo: ok, will do then, thx
[18:32] <tkamppeter> stgraber, thank you for the info.
[18:34] <hwilde> ogra, it's not luck if it's exactly the same on 180 different machines, cmon
[18:34] <hwilde> be realistic here
[18:35] <ogra> hwilde, just dont complain if it breaks
[18:35] <hwilde> ogra, the point is why does updateing the kernel update anything but the kernel?  just update the kernel not the rest of the options
[18:35] <hwilde> in the whole menu.lst all it needs to do is change the number on the kernel, nothing else
[18:35] <ogra> kopt cares for exactly that
[18:36] <hwilde> but it overwrites root=/dev/sda1 with the UUID
[18:36] <ogra> but slangasek might be a better pendant for you to discuss ucf and menu.lst
[18:36] <ogra> only if the UUID is defined soemwhere in the kernel options in that file
[18:36] <ogra> which i suppose it is since its the default
[18:38] <ogra> hwilde, and sda can easily become sdb if for example someone left a backup usb drive plugged in you dont know about ... if that becomes sda1 because the kernel likes to name it like that the backup would be gone
[18:38] <ogra> (and you wouldnt have a bootable first system disk)
[18:38] <ogra> UUID prevents that
[18:39] <hwilde> ogra, UUID does not allow cloning the image to 180 machines
[18:40] <ogra> as i said above, have a script that detects the UUID and adds it in the kopt line properly
[18:42] <sbeattie> norsetto: if you're interested in doing sru verifications, we'd love the help.
[18:43] <norsetto> sbeattie: that would be cool, I just applied to join the team
[19:07] <Kopfgeldjaeger> norsetto_limbo: Thanks for commenting http://revu.ubuntuwire.com/details.py?package=gtkhash -- I'm not sure about 2. I removed some newlines in the manpage. But I can't really really take away the newlines in the description because that would be over 80 chars/line.
[19:07] <Kopfgeldjaeger> mv discussion #ubuntu-motu/
[19:20]  * ogra wonders why evo is missing after his dist-upgarde
[19:31] <ogra> seb128, so evo was nice and duplicated all messages in my inbox for me :P
[19:32] <ogra> hardy->intrepid upgrade
[19:33] <ogra> oh, it only listed them twice after the first new send/recive they are single msgs again
[19:36] <ogra> but why dont i get any windowframes for the evo window :(
[19:39]  * ogra curses ... i want my frames back !
[20:00] <kirkland> ogra_cmpc: try ctrl-m
[20:19] <ogra> yippie, the evo mail notification stopped the annoying blinking !!
[20:20] <ogra> err, hmm no it didnt ... weird
[20:22] <seb128> ogra: so after some testing what issue do you still have? ;-)
[20:22] <ogra> none :)
[20:22] <ogra> it seemed a bit shaky
[20:22] <seb128> did you get 2.23.6?
[20:23] <ogra> having all mails in inbox twice until i did my first poll agan, the blinking notification is much quieter now (stops blinking after a few times)
[20:23] <ogra> 2.24 i thought
[20:23] <ogra> ah, 2.23.6
[20:23] <ogra> yeah
[20:24] <ogra> not sure what the missing window borders were about ... i had the UNR packages installed, i bet they were at fault
[20:24] <ogra> intresting though that it only affected evo
[20:25] <seb128> ogra: they fixed load of bugs this cycle, some hundreds again
[20:26] <ogra> what i really wish for is that the mail notification brigs evo up if i click it ... its annoying to have to click the icon *and* the window list
[20:26] <seb128> ogra: but 2.23.5 and 2.23.6 had quite some changes, they landed the on disk summary code, now disk summary uses sqlite
[20:26] <seb128> right
[20:26] <ogra> i noticed its a bit slower rendering the folders
[20:26] <ogra> especially if they are bg
[20:26] <ogra> *big
[20:27] <seb128> I didn't package 2.23.5 because it was too buggy but 2.23.6 should be mostly alright
[20:27] <seb128> oh?
[20:27] <seb128> how many mails?
[20:27] <ogra> my smallest has about 500, my biggest something like 30000
[20:28] <ogra> the big one takes about 1.5-2 secs until i see the msg list ...
[20:28] <seb128> the new version was freezing for some seconds when opening my mailbox but that has been fixed this afternoon, I'm listing only unread mails and it was being slow at list hidden ones apparently
[20:28] <ogra> before it was rather instantly
[20:28] <seb128> do you have lot of hidden mails there?
[20:28] <ogra> but i can live with a 2sec delay
[20:28] <ogra> not really
[20:28] <seb128> ok, differently issue probably
[20:28] <ogra> i leave all of them visible
[20:29] <ogra> since i use evo as archive tool and search a lot in it
[20:29] <seb128> they are optimizing things, they wanted to get the thing working first before looking too much to performances
[20:29] <seb128> I expect it'll get better again before intrepid
[20:29] <ogra> it was nice to not lose mail this time :)
[20:29] <pedro_> it's way faster to me than in hardy in reading my bugmail folder with about 60000 emails
[20:29] <ogra> i had worse upgrade experiences with it
[20:30] <pedro_> but the summary of the search folders aren't working  :-(
[20:30]  * ogra didnt use search folders for quite some time 
[20:31] <ogra> since gutsy i think
[20:32] <seb128> pedro_: search folder = vfolder?
[20:32] <seb128> I think that was too buggy and they desactivated some functions for now
[20:32] <seb128> I don't use those
[20:33] <pedro_> seb128: yes, but it's known they working on it according to bug http://bugzilla.gnome.org/show_bug.cgi?id=545317
[20:34] <seb128> alright
[20:38] <ogra> seb128, all in all i'm very pleased ... now i'd only like to see all the lexington patches applied to be able to use evo in mobile :P
[20:38] <seb128> ogra: oh, they have changes to evo? did they attach those somewhere?
[20:48] <Adri2000> any archive admin: would you pretty please let the amsn sru go in hardy-proposed? :)) it's bug #243722 and it seems to be affecting more and more people
[20:51] <seb128> Adri2000: you need an sru team member, not an archive admin there
[20:52] <seb128> Adri2000: ah, it has been approved, looking
[20:58] <DRebellion> slangasek, on the topic of monkeystudio: is it ok if the qscintilla source is still included in the source package (for win32/osx builds) but not used?
[20:58] <DRebellion> apachelogger, ^^
[20:58] <slangasek> DRebellion: yes - though I would note that since your .orig.tar.gz is currently built out of svn, it seems trivial to excise it at the same time? :)
[21:00] <seb128> slangasek: hey, could you look at the amsn hardy-proposed sru universe upload Adri2000 just mentionned? I think it's ok to accept but I don't do srus usually so I'm not sure if sru-accept should be used or how guys do those
[21:00] <DRebellion> slangasek, i wouldn't feel confident removing it - the whole source package is quite complex.
[21:00] <seb128> slangasek: it's an universe upload and has been approved so technically it's just waving it in I think, right?
[21:01] <DRebellion> slangasek, plus, i thought we were meant to leave upstream's source well alone
[21:01] <DRebellion> ?
[21:03] <slangasek> DRebellion: when upstream publishes a tarball, it's generally preferred that you not modify it when feasible; but when you're building from a VCS anyway, there's no advantage to an "unmodified" tarball...
[21:03] <lifeless> slangasek: huh?
[21:03] <lifeless> slangasek: why is vcs any less precious than the contents of a tarball; both are hashable for integraty verification by third parties
[21:03] <slangasek> DRebellion: it would just have been nice to be able to omit that chunk of code from e.g., debian/copyright
[21:03] <DRebellion> slangasek, ok, i will ask upstream
[21:04] <DRebellion> wait, no, i'll just remove it myself :P
[21:04] <slangasek> seb128: has it been acked by motu-sru?
[21:04] <seb128> slangasek: yes, see 243722
[21:04] <slangasek> seb128: sru-accept is new, actually, I haven't seen what it does; I'll have a look in a little bit and let you know
[21:04] <seb128> ok thanks
[21:05] <seb128> I guess it's another pitti's toy ;-)
[21:05] <Adri2000> thanks slangasek and seb128 :)
[21:05] <slangasek> lifeless: ok, *if* a straight checkout gets you an appropriate orig.tar.gz, then that's a reasonable concern, yes; if you're running ./autogen.sh as part of the get-orig-tar target, less so...
[21:05] <lifeless> slangasek: true
[21:06] <lifeless> slangasek: I'm of the school that derived content (running autogen) belongs at build-time :)
[21:06] <slangasek> yes... :)
[21:07] <slangasek> seb128: oh, no, sru-accept isn't the one I was thinking of, I've used that tool lots of times ;)
[21:07] <slangasek> seb128: sru-accept is used to tag the bugs appropriately, yes; the actual accept is done the normal way
[21:08] <slangasek> seb128: which you are welcome to do as my attention is divided at the moment, or I'll get it in a bit
[21:08] <seb128> slangasek: ah ok, so you do accept the upload and use sru-accept to update the bug?
[21:08] <slangasek> seb128: correct
[21:09] <seb128> ok, I've to run now but I'll give a look later if you didn't accept this one first, feel free to process it if you have the opportunity, I'll have other occasion to try it later ;-)
[21:10] <slangasek> jdstrand_: <blink> why does ldap gssapi need /dev/tty?
[21:10] <slangasek> seb128: ok, later :)
[21:10] <jdstrand_> slangasek: that's a good question, but apparmor complains otherwise
[21:11] <slangasek> well, eep
[21:12] <slangasek> jdstrand_: heh, and the preceding security upload for some reason commented out debconf-updatepo in debian/rules; wtf?
[21:12] <jdstrand_> slangasek: kees did the last upload
[21:12] <slangasek> kees: wtf? :)
[21:15] <kees> slangasek: which package?  this is something I've been doing for a while to reduce debdiff deltas.
[21:15] <slangasek> kees: openldap2.3
[21:16] <kees> slangasek: has this caused a problem?
[21:16] <slangasek> kees: no, I just noted it in the diff while reviewing an SRU
[21:16] <slangasek> kees: but if debconf-updatepo ever gave you a delta on openldap, let me know so I can scream at someone ;)
[21:17] <kees> slangasek: ah-ha, okay.  Yeah, I do this to avoid a massive diff delta.  It used to always give me deltas due to timestamps changing.
[21:17] <kees> slangasek: I can't say if it happened on openldap itself, but it happened with so many other packages, I just added this to my security update build check list
[21:17] <slangasek> oh, I suspect that was a bug in an older version of debconf-updatepo then
[21:17] <kees> slangasek: afaik, it's harmless to comment out post-release.
[21:17] <kees> slangasek: that could be
[21:36] <Adri2000> slangasek: amsn sru pretty please? :p and while you're at it amsn-data is waiting in intrepid binary new. thanks!
[21:36] <slangasek> Adri2000: amsn is already accepted?
[21:36] <slangasek> er, no
[21:36] <slangasek> hang on, accepted shortly :)
[21:54] <cr3> slangasek: ping, would you happen to be familiar with the build process of the alternate image? I encountered a problem where the netboot kernel is not the same version as the debian packages on the image, bug #255093
[21:55] <cr3> slangasek: I'm wondering if I should perhaps report a bug against launchpad in the event the build process was automated somehow, but I'm just not familiar with launchpad to know
[21:56] <ogra> thats likely being d-i out of sync
[21:56] <cr3> ogra: ah, so the linux and initrd.gz files are provided by the d-i package?
[21:56] <ogra> there was a kernel upload recently and colin is on holiday so he didnt update d-i accordingly
[21:57] <ogra> i think d-i is special in this case
[21:57] <cr3> ogra: that process seems error prone, but I don't want to be pretentious in suggesting it could necessarily be automated. perhaps would there be an appropriate place to report a wishlist for this?
[21:57] <ogra> and needs to be built against the current kernel if we get a new one .... i.e. there are a lot of packages built as udebs
[21:57] <ogra> by the linux package
[21:57] <ogra> d-i will want to pull these in
[21:58] <ogra> cr3, colin hould be back tomorrow, i would discuss it with him before filing a bug
[21:59] <cr3> ogra: ok, worst case, I'll ask if evand could handle this during his holiday next week
[22:00] <ogra> colin will be around for the next alpha
[22:00] <ogra> and i doubt anyone actually takes massive care for dailies for that
[22:03] <cr3> ogra: I finally automated the whole process of testing dailies. as soon as new dailies are detected, I test the builds: ubuntu, kubuntu, mythbuntu, ubuntu-server, ubuntustudio, xubuntu. so, I'll be keeping close tabs on those dailies :)
[22:03] <ogra> thats mad
[22:04] <ogra> nobody really cares for dailies bwing installable
[22:04] <ogra> *being
[22:04] <cr3> ogra: what's the point of an iso image if you can't install it?
[22:04] <stgraber> ogra: we do :)
[22:04] <ogra> in fact the majority before the late alphas will be broken since we upload packages for implementing features that often require a package set in place before something works
[22:05] <ogra> well, if they work thats by occasion ...
[22:05] <ogra> but we only really put deliberate work into alphas to make sure they work
[22:06] <cr3> ogra: what's this "package set in place"?
[22:06] <ogra> well, for example i have compcache on my plate for the liveCD
[22:06] <stgraber> ogra: I guess I found the problem with my VM ... no hald running ?? known issue ?
[22:06] <ogra> one part has to be implemented in initramfs-tools, the other in casper
[22:06] <cr3> ogra: those will also be tested automatically, but it would be reassuring to know that the dailies from a day or two before alpha actuall work
[22:06] <ogra> stgraber, no hal installed on thin clients :)
[22:06] <stgraber> ogra: and no dbus either (hal's dep)
[22:07] <ogra> i never was
[22:07] <stgraber> ogra: it's installed, dbus too
[22:07] <ogra> oh
[22:07] <stgraber> ogra: I guess that was added to Xorg depends
[22:07] <ogra> oh !!!
[22:07] <ogra> thats pretty bad
[22:07] <stgraber> or something similar because I just rebuilt a chroot and got hal and dbus installed
[22:07] <stgraber> and no Xorg input because of hal not running
[22:07] <ogra> bryce, so xorg doesnt work in minimal setups at all anymore ?
[22:08] <cr3> ogra: so compcache might make it in initramfs-tools before or after in casper, so the live and alternate might be different at some point in time, right?
[22:08]  * ogra sighs
[22:08] <ogra> so i have no idea why i put that much work into getting 24M clients to work ... we wont be able to use X on them at all
[22:09] <bryce> ogra, what are you talking about?
[22:09] <ogra> cr3, right ... and now imagine (what isnt the case) that the change to initramfs-tools only works if the change in csper is also there
[22:09] <stgraber> ogra: libhal1 is now a depends of xserver-xorg-core, so it installs dbus and hal in the chroot ...
[22:09] <ogra> bryce, hal and dbus being a hard dep of X now
[22:09] <ogra> bryce, so there is no way anymore to have a minimal setup that runs on low power systems
[22:10] <ogra> one declared target for ltsp was to support 24MB clients ths cycle because we get many requests
[22:11] <ogra> but that would only work with hardcoded xorg.conf (a blame te users would take) ... though running hal and dbus on such systems is not an option, they would run out of ram during boot
[22:11] <bryce> ogra, yeah no secret that xorg was moving to depend on those
[22:11] <tjaalton> ogra: x-x-c depends on libhal already since hardy
[22:12] <ogra> hrm
[22:12] <ogra> but it doesnt work at all without them running anymore
[22:12] <tjaalton> there's a patch pending
[22:12] <ogra> i dont care if tehy sit in the chroot for ltsp clients ...
[22:12] <ogra> but they cant run on minimal HW
[22:13] <ogra> tjaalton, to make x capable of using the old methids ?
[22:13] <ogra> *methods
[22:13] <tjaalton> http://cgit.freedesktop.org/xorg/xserver/commit/?id=2eaed4a10fe5bf727579bca4ab8d4a47c8763a7d
[22:13] <Adri2000> slangasek: thanks for the sru. could you also do amsn-data binary new in intrepid please?
[22:13] <ogra> tjaalton, sweet thanks
[22:14] <ogra> that sounds usable
[22:14] <tjaalton> ogra: all it would need now is to add the input devices in serverlayout
[22:14] <bryce> tjaalton: btw did pitti include my console2fdi.sh script in hal for the keyboard stuff?  (just checking that I can cross it off my todo)
[22:14] <ogra> btw i got nowhere with my touchpad and gave up for now
[22:14] <stgraber> tjaalton: well, we were happy to just run without xorg.conf and IIRC it used to work where it now doesn't (without hal)
[22:15] <tjaalton> stgraber: yes
[22:16] <ogra> we even put a week of work into ldm to support setxkbmap ... :(
[22:16] <tjaalton> bryce: well, hal uses the callout script modified from fedora, so there's no need to generate an fdi file
[22:16] <ogra> i guess thats moot
[22:17] <stgraber> ogra: is the compcache magic supposed to just work if I boot with "-m 24" or do I need to enable it somewhere ?
[22:17] <ogra> (since xkb was the only thing we actually used xorg.conf for )
[22:17] <tjaalton> bryce: which is nice, since there's only one configuration file now (/e/d/console-setup)
[22:17] <cr3> ogra: gotcha, thanks for the use case
[22:17] <ogra> stgraber, see initramfs.conf its documented
[22:17] <tjaalton> stgraber: file a bug about the hal-less problem
[22:18] <stgraber> tjaalton: against ?
[22:18] <ogra> xserver-xorg ?
[22:18] <tjaalton> stgraber: xorg-server
[22:18] <jcristau> stgraber: xserver-xorg-core
[22:18] <tjaalton> yes, source package is xorg-server:)
[22:19] <bryce> tjaalton: callout script?
[22:19] <bryce> tjaalton: so the script I did is unnecessary then?
[22:19] <tjaalton> bryce: basically yes.. now it works just the way colin suggested in december :)
[22:20] <tjaalton> hal just needed one patch that fedora already had
[22:20] <tjaalton> (--direct for hal-set-property)
[22:21] <stgraber> tjaalton: bug 255133
[22:22] <tjaalton> bryce: so, hal runs this script when it founds a device that matches some criteria, see /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi
[22:22] <tjaalton> stgraber: thansk
[22:22] <tjaalton> -ks
[22:22] <ogra> stgraber, can you try to move the ltsp-client-core initscript to a later start ?
[22:22] <jcristau> tjaalton: two ways to fix this afaict. depend on hal, or default allowemptyinput to off.
[22:22] <philsf> does apt-listbugs work with ubuntu?
[22:22] <ogra> (i dont get why dbus and hal dont start at all though)
[22:23] <stgraber> ogra: I can but that shouldn't change anything as after the client booted dbus and hald weren't running
[22:23] <jcristau> tjaalton: i'm a bit tired of fighting it upstream, so. :)
[22:24] <ogra> stgraber, yeah, i'll have to look into that
[22:24] <ogra> bryce, tjaalton thanks a lot for the answers :)
[22:26] <tjaalton> ogra: no problem, sorry for causing a heart-attack ;)
[22:26] <bryce> ogra, glad it's worked out
[22:27] <ogra> tjaalton, well, i could have thought about it myself, bryce was right ... but i didnt actually expect to lose all backwards compatibiity (and luckily the patch you pointed out will retain the bit i need)
[22:28] <ogra> tjaalton, i'm actually upposed to not panic that much anymore ... so sorry for causing trouble first place :)
[22:28] <tjaalton> jcristau: right.. there are two different bugs here..
[22:28] <ogra> *suposed
[22:28] <tjaalton> ogra: hehe
[22:29] <tjaalton> jcristau: this one without the conf and the one that your patch would fix
[22:29] <bryce> tjaalton: so I see there is a 'debian-setup-keyboard' listed in the info.callouts.add key, but what is that, a script, or...?  (it's not in path)
[22:30] <tjaalton> bryce: it's a script, but only meant for hal, see /usr/lib/hal/debian-setup-keyboard
[22:31] <bryce> tjaalton: huh, interesting
[22:34] <Laney> doko: Hey, I don't know if you saw but bug #240884 got fixed upstream. It would be great if we could get a new binutils release with this change in if you have time :)
[23:00] <superm1> tseliot, ping.  I wanted to discuss with you something that i see will turn into a maintenance difficulty of the nvidia drivers
[23:00] <superm1> tseliot, regarding hardcoding exact library versions like nvidia-glx-177.links:usr/lib/libGL.so.177.13 usr/lib/libGL.so.1
[23:03] <tseliot> ﻿superm1: I'm here
[23:04] <superm1> tseliot, so it looks like you are hardcoding the version number in tons of places
[23:04] <tseliot> superm1: did you see the links.in?
[23:05] <superm1> tseliot, oh... this is what i'm getting for grepping the source package and missing the .in files :)
[23:05] <tseliot> the .links files are generated ﻿automatically
[23:05] <superm1> tseliot, okay that's much more sane
[23:05] <tseliot> ﻿superm1: that doesn't waste my time ;)
[23:06] <tseliot> hardcoding the version would
[23:06] <superm1> yeah
[23:06] <ogra> wasting time is only good if beer friends and probably food are involved :)
[23:07] <tseliot> ogra: no hardcoding is involved in that case :-P
[23:08] <ogra> indeed :)
[23:09] <superm1> tseliot, okay looks good then.  sorry for bothering you :)
[23:09] <tseliot> ﻿superm1: no problem :-)
[23:29] <lucas> Riddell: I answered on the LP bug