[12:40] <mneptok> eep. opp. ork. uh-huh.
[12:41] <ajmitch> well said, mneptok
[01:34] <zul_> evening
[01:38] <bryce> Riddell: do you think you'll have a chance to upload the kde-guidance patch today?  http://people.ubuntu.com/~bryce/Uploads/
[01:45] <wasabi> Um. Samba/Winbind problem: Winbind password cache is broken in gutsy package. It is fixed in Debian.
[01:46] <wasabi> What's the procedure for asking for the package to be merged these days? And are we beyond that point in freeze yet?
[01:46] <wasabi> Also why can I never find this stuff on the wiki heh
[02:14] <bddebian> Heya
[02:14] <pygi> morning bddebian
[02:14] <bddebian> Hi pygi
[02:14] <pygi> how are you doing?
[02:16] <bddebian> OK thanks. Yourself?
[02:17] <pygi> tired :P
[02:17] <pygi> 2:17AM =)
[02:36] <wasabi> keescook: Actually I think my entire post distils down into two things: a) My mdadm.conf wasn't updated. The wrong uuid was in it. Maybe that was my fault. b) 85-mdadm.rules does not specify --auto=yes
[02:42] <mekius> anyone have any good ideas about how i could install google toolbar onto a custom live cd?
[03:21] <mneptok> could someone please immolate NetworkManager? kthx luv u bai.
[03:21] <zul> get right on it
[03:22] <zul> oh hey mneptok
[03:26] <mneptok> heya Zul
[03:26] <mneptok> there is no Dana.
[03:40] <Amaranth> bryce: why did you move bug 137745 back to compiz? it's a limitation in the X stack
[03:40] <ubotu> Launchpad bug 137745 in compiz "compiz can only used by one user" [Wishlist,New]  https://launchpad.net/bugs/137745
[03:40] <Amaranth> dri, drm, and/or the drivers, something nvidia doesn't use
[03:53] <sbalneav> Evening all
[03:54] <bddebian> Hey sbalneav
[03:55] <sbalneav> hey there bddebian!
[03:56] <sbalneav> Tomorrow's Fix It Friday for Edubuntu!!!
[03:56] <sbalneav> Booked the day off work :)
[04:08] <bddebian> w00t
[04:52] <bluefoxicy> smoothest nipples i've ever felt
[04:52] <bluefoxicy> I mean hi IN
[05:09] <bhale> meh, both of you clean up your act
[05:28] <bddebian> bhale: !!
[06:32] <Hobbsee> <pin drop>
[06:33] <bddebian> BOING
[06:37] <Hobbsee> argh!
[06:38] <keescook> wasabi: 85-mdadm.rules missing --auto=yes could be a bug, yes.  What things were you seeing going wrong with it?
[06:39] <wasabi> Well, on my systems, it simpley "doesn't work". No MD devices appear in iniramfs and I go to console.
[06:39] <wasabi> So, I usually run it manually
[06:39] <wasabi> mdadm --examine --scan > /etc/mdadm/mdadm.conf
[06:39] <wasabi> mdadm --assemble --scan --no-degraded --auto=yes
[06:40] <wasabi> If I don't add auto, it doesn't work. Says /dev/md* doesn't exist.
[06:40] <wasabi> Seeing that udev doesn't add auto......
[06:41] <wasabi> On top of that my mdadm.conf did not have my arrays listed in it. The UUIDs were out of date. Probably because I reconfigured them at some point, or did not configure them from the installer. It makes me wonder if that file is even required though.
[06:41] <wasabi> And udev can't just use --examine.
[06:41] <ajmitch> curious
[06:41] <keescook> wasabi: yeah, the initial creation of the mdadm.conf is critical to this, unfortunately.
[06:41] <ajmitch> lvm & mdadm have been working fine for me in gutsy
[06:41] <wasabi> Is there a reason we don't do --examine and auto detect?
[06:42] <ajmitch> which would mean that I have a working mdadm.conf, I guess :)
[06:42] <wasabi> Since we auto detect everything else, like LVM, I can't see why.
[06:42] <keescook> wasabi: I thought we did, actually.
[06:42] <keescook> wasabi: in that as devices appear, udev tries to start them up.
[06:42] <keescook> I haven't tried having a totally empty mdadm.conf.
[06:42] <wasabi> Well yeah, udev runs mdadm, but without --examine.
[06:42] <wasabi> So it relies on the mdadm.conf copied during update-initramfs
[06:43] <keescook> hm.  I'm of two minds: 1) it should auto-start everything!  2) zomg don't auto-start unless you expect it
[06:43] <wasabi> Yeah. Completely contradictory.
[06:44] <wasabi> If you pick 2, you have a *lot* of issues though.
[06:44] <wasabi> Which I don't think we can reasonable solve right now.
[06:44] <wasabi> That is, you shouldn't auto activate LVM either,e xcept for the root device.
[06:44] <wasabi> And that means you should only active MD's which contribute to the activation of the LVM.
[06:44] <wasabi> But no others.
[06:44] <wasabi> Which is just too hard to think about.
[06:44] <keescook> heh
[06:45] <wasabi> root=md/UUID=UUID-of-MD;lvm/UUID=UUID-of-lvm
[06:45] <wasabi> Get into crap like that.
[06:45] <wasabi> Anways, --auto is a big ommisions. I'm not sure why yours works without it.
[06:46] <wasabi> Unless something else is creating your md* nodes.
[06:46] <wasabi> Clearly if I enter teh initramfs with mount=break, and run the mdadm command without --auto, it says no thanks.
[06:46] <keescook> hunh
[06:46] <keescook> I wonder why I have /dev/md* then.
[06:47] <keescook> I need to get my vmware set up with multiple drives
[06:47] <wasabi> I'm glad those scripts in local-top are gone though.
[06:47] <wasabi> Those were maddening
[06:49] <wasabi> Anyways, I sort of solved it by invoking mdadm twice from udev: once with --examine, another time without, using a temporary config file.
[06:49] <wasabi> tmp=`mktemp`; mdadm --examine --scan > $tmp; mdadm --assemble --scan --auto=yes --no-degraded --config=$tmp
[06:50] <wasabi> That automatically activates all non-degraded arrays known to the system, regardless of the user's mdadm.conf
[06:50] <wasabi> I doubt that's suitable for you though.
[06:50] <wasabi> Because it ignores superblock 1 arrays. ;)
[06:50] <wasabi> or no-super block arrays, as they may be
[06:51] <keescook> so, it seems that 85-mdadm is basically doing its best to start up all the known arrays (mdadm.conf) each time a new linux_raid type device shows up.
[06:51] <wasabi> but i have no idea if those are supported anyways
[06:51] <keescook> we could just say type 1 isn't support.  :)
[06:51] <wasabi> Yeah, except for the lack of auto, that's fine. I still do not understand why you don't need auto.
[06:51] <wasabi> auto is what makes the nodes for me. Nothing else does.
[06:52] <keescook> yeah, I'm honestly a bit confused myself.
[06:52] <wasabi> Do you have some option in mdadm.conf inferring auto?
[06:52] <wasabi> I see, mdadm.conf supports auto added to a listed array.
[06:52] <wasabi> Mine did not have that.
[06:52] <keescook> nope, just DEVICE partitions followed by my ARRAY lines: ARRAY /dev/md0 level=raid1 num-devices=2 UUID=337ca5ec:8f193d47:50a102cf:df548069
[06:52] <wasabi> Hmm. Yours doesn't either.
[06:53] <wasabi> That file was... useful, with non-superblock arrays.
[06:53] <wasabi> I don't think it's useful anymore.
[06:53] <keescook> I don't see a reason why --auto=yes would _hurt_ anything -- I'm just curious why I don't need it
[06:53] <wasabi> Well, jump into an initramfs in premount.
[06:53] <wasabi> And run it. ;)
[06:53] <keescook> which is odd considering Debian switched to requiring it
[06:54] <keescook> I would but that woudl require me rebooting.  :)
[06:54] <keescook> I'm tweaking a vmware profile atm
[06:57] <wasabi> Another bug I've discovered is vgchange -a y is dangerous.
[06:57] <wasabi> But that's another story.
[06:57] <keescook> dangerous how?
[06:57] <wasabi> If you plug in a drive from another LVM set, and it has the same name as an existing one on the system.
[06:57] <wasabi> Activating it puts the system into a state that can't be repaired without rebooting.
[06:58] <keescook> oh yeah, yeah yeah bad bad
[06:58] <wasabi> Because it actually DOES activate the second named one, and result in the user space tools beind unable to distinguish them.
[06:58] <wasabi> So ou can't unactivate it
[06:58] <wasabi> If you vgscan, and then vgrename it, before activating it, it's fine.
[06:58] <keescook> yeah, it's an f'in disaster
[06:58] <keescook> I name all my vgs uniquely now.  I used to just use "systemvg" everywhere.
[06:58] <wasabi> That might be a consideration for the installer to name them automatically.
[06:59] <keescook> perfects example of "enable everything" seriously backfiring
[06:59] <wasabi> Then again, simply preventing vgchange from doing that probably solves the real issue.
[06:59] <wasabi> "Hey, you have tow of these! I"m not activating it!"
[06:59] <wasabi> "Duh!"
[07:01] <wasabi> We could use a dbus signal for broken arrays too.
[07:02] <keescook> mdadm patch to poke hal!  :)
[07:02] <wasabi> totally.
[07:02] <wasabi> then a notification icon can be done
[07:04] <keescook> vgchange> yeah, that would be a more sensible fix.  :)
[07:12] <keescook> wasabi: hmpf, I was able to do a mdadm -C without --auto=yes
[07:14] <wasabi> Weird. What's -C?
[07:14] <wasabi> Ahh, specify config path?
[07:15] <Hobbsee> evand: @ people.ubuntu.com - only canonical employees.  not core dev, not MOTU.  (unfortunately)
[07:15] <wasabi> # auto-create devices with Debian standard permissions
[07:15] <wasabi> CREATE owner=root group=disk mode=0660 auto=yes
[07:16] <wasabi> keescook: I even have that in my file, but it no works.
[07:17] <keescook> wasabi: -C is "create"
[07:17] <wasabi> Hmm. What's creating an array have to do with it?
[07:24] <wasabi> Should we be using UUIDs in /etc/fstab for LVM?
[07:39] <Mithrandir> wasabi: I'm fairly sure you can just do dmsetup remove on the relevant devices and then run vgchange again.
[07:41] <wasabi> LVM is pure dm?
[07:44] <Mithrandir> wasabi: yes, like everything else in 2.6
[07:44] <wasabi> cept md/
[07:44] <Mithrandir> md can be too, at least for raid 1
[07:47] <Hobbsee> good morning Mithrandir!
[07:47] <Mithrandir> morning little green alien.
[07:51] <wasabi> I'm off to bed.
[09:01] <dholbach> good morning
[09:01] <\sh> hey dholbach
[09:02] <mdke> morning dholbach
[09:03] <dholbach> hey \sh, hey mdke
[09:03] <dholbach> mdke: you merged in the changes alright?
[09:03] <mdke> dholbach: I'm doing it now
[09:03] <dholbach> mdke: also changed the version number of the ubuntu-docs upload?
[09:03] <dholbach> rock on
[09:03] <mdke> dholbach: anything else change in ubuntu-docs?
[09:03] <dholbach> no, just the version
[09:05] <mdke> ok, all done. Thanks a lot dholbach for working on that
[09:05] <dholbach> no problem :)
[09:05] <MacSlow> greetings
[09:06] <dholbach> heya MacSlow
[09:06] <mdke> dholbach: I wanted to ask your opinion on something about the possibility of ubuntu-docs using bzr. It's basically this - https://lists.ubuntu.com/archives/ubuntu-doc/2007-August/009160.html
[09:06] <mdke> dholbach: I thought since you know how the tree works, and how lp/bzr works better than me, you might have a view
[09:06] <mdke> not urgent of course
[09:08] <dholbach> mdke: I found the same: the initial checkout was fairly huge and took its time, also the first push to a new branch, but the subsequent merges and pushes were very quick
[09:09] <dholbach> I support you switching to bzr, it's far more inviting than using svn - also lots of people are used to bzr-lp now
[09:09] <mdke> dholbach: sorry, I meant more the second part of the email - speed is not a serious blocker for me
[09:09] <mdke> the second part is more about how we could use lp to improve our current workflow
[09:09] <dholbach> I'd also stick to the tradition of storing everyrthing in bzr - I don't think there's much sense storing the packaging in another branch
[09:10] <dholbach> I don't think it's going to be messy to merge changes between different branches every now and then
[09:10] <mdke> dholbach: so you'd have the same tree as now basically? with the kubuntu/edubuntu stuff there too?
[09:11] <dholbach> you can have kubuntu and edubuntu branches, where those teams work and merge their changes every now and then
[09:11] <dholbach> it's what we do for the seeds for example
[09:11] <dholbach> kubuntu and edubuntu have changes of their own, but merge changes of the ubuntu branch all the time
[09:11] <dholbach> like kubuntu-desktop and ubuntu-desktop differ, but they basically share ubuntu-standard
[09:11] <mdke> so the common documents would be basically kept in each branch and kept up to date with each other?
[09:12] <dholbach> I think that's reasonable
[09:12] <mdke> interesting
[09:12] <dholbach> I mean you can always change the workflow and improve it as you go
[09:13] <mdke> true
[09:13] <dholbach> you could even have a team of different contributors to kubuntu-docs (if that makes sense)
[09:13] <dholbach> so the kubuntu-docs people can add people to their team, because they know them already
[09:14] <mdke> i'm slightly concerned about the teams drawing apart, so i think it would probablybe better for ubuntu-doc-core or something to have commit rights to each, just to make sure everyone keeps working together and knows each other
[09:14] <dholbach> right
[09:14] <dholbach> you *can* keep them all in the same team namespace
[09:15] <dholbach> ~ubuntu-doc/ubuntu-docs/ubuntu-gutsy
[09:15] <dholbach> ~ubuntu-doc/ubuntu-docs/kubuntu-gutsy
[09:15] <dholbach> ~ubuntu-doc/ubuntu-docs/edubuntu-gutsy
[09:15] <dholbach> and so on
[09:15] <mdke> sure
[09:15] <dholbach> you wouldn't need new teams, but you could have them
[09:16] <mdke> ok, that's very helpful, thanks
[09:16] <dholbach> cool
[09:16] <MacSlow> dholbach, what's the correct option to reinstall a package with dpkg? Just: dpkg -i --force package.deb?
[09:17] <dholbach> MacSlow: sudo apt-get install --reinstall <package>?
[09:17] <MacSlow> dholbach, not it's a local package... I compiled myself... skipping some patches for testing.
[09:17] <dholbach> just    sudo dpkg -i bla.deb
[09:55] <cjwatson> dholbach: though, one of these days when I have the time, I plan to merge all the seeds into one big honking branch
[09:55] <cjwatson> I think
[09:56] <dholbach> that sounds good and will save a lot of time, I guess
[09:56] <cjwatson> only concern is what to do with non-core seeds like ubuntustudio and mythbuntu
[09:57] <dholbach> right...
[09:57] <cjwatson> the problem I want to solve is that there are certain seeds that are not logically separate (minimal is by definition the same no matter what flavour you are, for example), but we have to pointlessly merge them anyway or germinate gets confused
[10:00] <kagou> Good morning
[10:03] <siretart> morning
[10:03] <siretart> are we still in freeze for tribe6?
[10:03] <ajmitch> hi siretart
[10:03] <siretart> hey ajmitch
[10:04] <ajmitch> I think there's no tribe6 cd being done, so I don't think there's a freeze
[10:04] <siretart> oh? it has been cancelled?
[10:04] <dholbach> everybody hug thekorn: he implemented Bug.New() in python-launchpad-bugs
[10:04] <StevenK> siretart: -devel-announce
[10:04] <Mithrandir> dholbach: hm, 3.18 of bluez is out, both libs and utils, as well as 0.14.  It fixes some audio related bugs for me.
[10:05] <ajmitch> see Riddell's message to -d-a about 3 days ago
[10:05] <ajmitch> Mithrandir: what are my chances on a UVFe for samba 3.0.25c? it's a bug fix release that I'm wanting to merge
[10:05] <dholbach> Mithrandir: wow... bluez upstream seems to be quite busy
[10:05] <Mithrandir> dholbach: indeed, they're rocking quite a lot.
[10:06] <dholbach> Mithrandir: I'm happy to work on the updates
[10:06] <Mithrandir> dholbach: a quick uupdate here succeeded at least, but I'm wary of granting myself UVFe, so..
[10:06] <Mithrandir> ajmitch: do you have the changelog somewhere?  And have you had the server team's input on it?
[10:07] <siretart> StevenK: I'm now seriously confused. on -devel-announce, Riddell has announced that we should focus now on https://launchpad.net/ubuntu/+milestone/tribe-6 - but there was no mention on a target date, so I assumed the Schedule on GutsyReleaseSchedule is still authoritative
[10:07] <ajmitch> I've talked to soren, and the release notes are at http://samba.org/samba/history/samba-3.0.25c.html
[10:08] <ajmitch> diffstat is fairly small, and there are fixes from 3.0.25b-2 that we don't have either
[10:08] <dholbach> Mithrandir: I can absolve :-)
[10:11] <Mithrandir> ajmitch: I don't see anything particularly scary there, so if soren's happy with it, I say go for it.
[10:16] <dholbach> Mithrandir: I think it's a good thing to update, I'm building the packages right now and will test them
[10:16] <Mithrandir> dholbach: cheers
[10:17] <dholbach> it gets time the mobile team takes care of them ;-)
[10:18] <Mithrandir> yeah, it'll happen.. soon.
[10:19] <dholbach> seb128: what do I need to do if I ship something in usr/lib/gstreamer-0.10?
[10:19] <dholbach> seb128: run dh_scangstcodecs?
[10:19] <seb128> dholbach: yes
[10:20] <dholbach> thanks
[10:20] <Riddell> siretart: there's no freeze, the task is to fix all the tribe 6 bugs
[10:21] <StevenK> siretart: Yourself.
[10:23] <siretart> I see
[10:24] <StevenK> seb128: gimp uploaded, thanks for your help. :-)
[10:24] <seb128> StevenK: thank you for the work on it ;)
[10:25] <StevenK> Mithrandir: Would you mind digging through the logs on drescher to see why pilot-link was rejected? I'd just like a starting point.
[10:26] <seb128> StevenK: there is a pilot-link upload gutsy-changes
[10:26] <seb128> StevenK: what version has been rejected?
[10:26] <Riddell> Mithrandir: could you give back kde4base 3.93.0-0ubuntu1~feisty2
[10:26] <StevenK> Ahhh. I think someone else uploaded it.
[10:26] <Mithrandir> Riddell: given-back
[10:27] <seb128> StevenK: it's from Kitterman
[10:27] <Mithrandir> 08:10:16 DEBUG   MD5 sum of uploaded file does not match existing file in archive
[10:27] <Mithrandir> 08:10:16 DEBUG       Recipients: Steve Kowalik <stevenk@debian.org>, Scott Kitterman <ubuntu@kitterman.com>
[10:27] <StevenK> Yeah, I saw that bit.
[10:28] <StevenK> Ah ha. dholbach uploaded it.
[10:30] <Amaranth> MacSlow: any idea why 132_composite-no-clipping.diff makes everything fall over?
[10:31] <MacSlow> Amaranth, not atm
[10:31] <Amaranth> "Needed by hildon-desktop to prevent home applets from clipping."
[10:32] <Amaranth> it was disabled once for breaking X, then supposedly fixed
[10:32] <Amaranth> err, for breaking compiz
[10:32] <Amaranth> oh that is a pretty evil looking patch
[10:35] <MacSlow> Amaranth, I don't know the history of that patch.
[10:35] <Amaranth> MacSlow: "this patch changes the semantics of manual-redirect Composite windows so that they do not clip sibling or parent drawing"
[10:37] <MacSlow> hm... I wonder what the Xorg folks have to say about that
[10:37] <Amaranth> MacSlow: keithp wrote it
[10:38] <MacSlow> sounds legit then :)
[10:38] <Amaranth> apparently not :)
[10:38] <Mithrandir> even Keith writes buggy code. :-P
[10:38] <MacSlow> I've not tired gutsy with that patch applied on my i915... wonder if it would crash too then...
[10:39] <Amaranth> i've heard reports but the main breakage seems to be nvidia
[10:39] <MacSlow> not that OpenGL-apps would work/render correctly anyway under compiz... since redirected direct GLX isn't working with OSS-drivers yet
[10:39] <Amaranth> there is a branch for that ;)
[10:40] <MacSlow> Amaranth, well I tried that stuff from krh and airlied... but it only crashed my intel-laptop
[10:40] <Amaranth> hehe
[10:40] <MacSlow> haven't tried it since
[10:40] <Amaranth> it probably only (sort of) works on their machines
[10:40] <Amaranth> kind of like nouveau's randr-1.2
[10:40] <MacSlow> airlied admitted that it is still super yound and very unstable
[10:44] <Chipzz> 2619
[10:45] <hunger> Where can I find out more about the xorg-amd driver I installed today?
[10:46] <hunger> Never noticed it before... maybe I should use that:-(
[11:19] <dholbach> cjwatson: are you OK adding bluez-gnome to the recommends of ubuntu-desktop? cf thread on ubuntu-devel@
[11:19] <dholbach> if so, I'd just add it right now and do a ubuntu-meta upload
[11:19] <seb128> dholbach: do it, you already got an approval from mdz and you have a +1 from me ;)
[11:20] <dholbach> rock on - that should be good enough ;-)
[11:21] <mvo> dholbach++
[11:23] <ajmitch> hi mvo :)
[11:23] <mvo> hey ajmitch
[11:27] <cjwatson> dholbach: fine by me
[11:29] <Mithrandir> hmm, I'm making UME create a default user that the UI runs as.  I think I'll be creating /home/ume for it, since the user may well want to store downloaded media or similar there.  Does anybody have a concern over a package creating a user with ~ in /home?
[11:30] <iwj> cjwatson: Yes, I spotted that.  I was confused because one of the mails about the rejections took much longer to arrive.
[11:34] <dholbach> cjwatson: thanks, done
[11:49] <siretart> how does gdm figure out what the display size is? I have a laptop here where xorg-driver-intel and gdm seem to disagree: gdm thinks 1024x768, but the driver is using 1280x800
[11:49] <siretart> (reported as bug #136783, FYI)
[11:49] <ubotu> Launchpad bug 136783 in ubuntu "not using whole widescreen" [High,Confirmed]  https://launchpad.net/bugs/136783
[11:52] <Kopfgeldjaeger> hi
[11:52] <ogra> hmm
[11:53] <ogra> all isos are oversized ?
[11:57] <noah__> not a problem if you're using vmware though. :)
[11:57] <ogra> well, we didnt release a tribe6 CD but imho we should at least have usable isos
[11:58] <ogra> (it isnt a problem if you use DVDRW either for the CD isos or 800M media, but thats not the point)
[12:01] <Riddell> bryce: kees seems to have uploaded guidance before I got to it
[12:16] <pygi> doko, is my survey done?
[12:22] <xerakko> cjwatson: hi
[12:22] <cjwatson> hello
[12:22] <xerakko> cjwatson: Hi
[12:23] <xerakko> I'm working in LliureX
[12:23] <xerakko> an edubuntu based distro
[12:23] <xerakko> and we are going to use
[12:23] <xerakko> germinate
[12:23] <xerakko> Have you written any documentation?
[12:23] <xerakko> about seeds format
[12:24] <cjwatson> man germinate
[12:26] <xerakko> cjwatson: In gutsy... ok
[12:26] <xerakko> thanks
[12:27] <ogra> xerakko, oh, wow, LliureX bases on edubuntu now ?
[12:27] <xerakko> yes :)
[12:28] <ogra> thats awesome news
[12:56] <ogra> mjg59, ping
[01:14] <mjg59> ogra: Hi
[01:14] <ogra> hey
[01:15] <ogra> mjg59, would it be very evil to add dhcpd to the acpi scripts by default zto fix bug 48212 ?
[01:15] <ubotu> Launchpad bug 48212 in ltsp "ltsp's dhcpd fails after server is hibernated" [Wishlist,In progress]  https://launchpad.net/bugs/48212
[01:16] <mjg59> It would be, yes
[01:16] <ogra> why ?
[01:16] <ogra> if i suspend a server i'd like to have all services back
[01:16] <mjg59> If the package needs special casing, have the package drop scripts into suspend.d and resume.d
[01:16] <ogra> ah, ok
[01:17] <ogra> i'll look into that, thanks
[01:37] <sits> hi
[01:37] <sits> who do I talk to about problems with http://codebrowse.launchpad.net/ ?
[01:38] <azeem> sits: #launchpad, I'd say
[01:38] <sits> azeem: cheers
[01:45] <iwj> Gah, the daily is oversized so I can't check my e2fsprogs fix.
[01:50] <ogra> iwj, all of them are :/
[01:51] <ogra> iwj, i resorted to DVDRW for a quick workaround
[02:13] <seb128> Riddell: what do you think about https://bugs.launchpad.net/ubuntu/+source/beagle/+bug/134341/comments/6 ?
[02:13] <ubotu> Launchpad bug 134341 in beagle "beagle ftbfs" [High,Fix committed] 
[02:13] <seb128> Riddell: that's an uvf for the new beagle
[02:14] <seb128> Riddell: the current version doesn't build and the new one seems to be mainly bug fix
[02:15] <Riddell> why is beagle in main anyway?
[02:16] <sits> Riddell: I guess we all love searching
[02:16] <Riddell> seb128: changelog looks fine, if it fixes the fail to build and has been decently tested then go ahead
[02:16] <Riddell> sits: sure, but it duplicates the two other desktop search engines we have in main
[02:16] <seb128> Riddell: because nautilus and yelp build with libbeagle to have support for it at runtime
[02:16] <seb128> Riddell: thanks
[02:16] <Riddell> oh yes, I remember now
[02:18] <sits> Hmm I can search my help... OK I didn't know that
[02:22] <sits> I wonder if I should publish an email detailing the types of bug reports and types of replies (complete with tongue in cheek humour)
[02:34] <rausb0> is it possible to blacklist a module on syslinux boot prompt when booting the live cd?
[02:35] <sits> rausb0: which one?
[02:35] <rausb0> feisty
[02:36] <jdong> I don't think so....
[02:36] <rausb0> hmm. that's bad.
[02:36] <jdong> what module is causing you problems?
[02:36] <rausb0> 8139too
[02:37] <jdong> what's the problem with it?
[02:37] <rausb0> it causes a complete hang when loaded. if built with pio instead of mmio, it works.
[02:38] <jdong> interesting....
[02:39] <rausb0> jdong: the machine is a cheap noname notebook (actual manufacturer is twinview)
[02:39] <jdong> perhaps there's a way to disable detection on the alternate installer
[02:40] <asac> ogra: fyi, bug 123808
[02:40] <ubotu> Launchpad bug 123808 in network-manager "NetworkManager Applet does not recognize ethernet bonding.  " [Undecided,Won't fix]  https://launchpad.net/bugs/123808
[02:40] <rausb0> jdong: maybe, but in this case i just wanted to boot the live cd to test 3d h/w accel for the i945gm card
[02:40] <jdong> rausb0: try 8139too.blacklist=true
[02:40] <rausb0> jdong: thanks, i will try that
[02:40] <jdong> rausb0: according to http://d-i.alioth.debian.org/manual/en.sparc/ch05s02.html it is valid for debian-installer
[02:40] <jdong> (I am not sure if it'll work on the LiveCD though :(
[02:40] <rausb0> jdong: oh, okay
[02:41] <rausb0> jdong: i disassembled the initramfs of the live cd and it looks like udevtrigger loads modules according the present hardware
[02:42] <jdong> right
[02:42] <asac> ogra: how about disabling network manager in thin client setups?
[02:42] <jdong> the debian-installer writes a /etc/modprobe.d/blacklist.local
[02:42] <jdong> that instructs udev not to load the module
[02:43] <rausb0> jdong: creating the blacklist from the command line would be a very useful addon to the live cd too
[02:43] <jdong> rausb0: I can't find any blacklister in casper (the livecd system)...
[02:43] <jdong> rausb0: I agree, it should be a feature request to casper
[02:44] <rausb0> jdong: is casper a ubuntu/debian only thing?
[02:44] <jdong> rausb0: casper is the Ubuntu livecd engine
[02:44] <rausb0> jdong: so its specific to ubuntu?
[02:44] <jdong> correct
[02:44] <rausb0> alright
[02:46] <sits> rausb0: did you say the module worked in some circumstances?
[02:46] <rausb0> sits: it works when compiled with other compile time options, yes
[02:46] <sits> rausb0: ah ok
[02:46] <jdong> (which might be mutually exclusive with another set of hardwrae...)
[02:47] <rausb0> sits: CONFIG_8139TOO_PIO=y
[02:47] <sits> ok
[02:47] <sits> I was wondering if it was a run time module option
[02:47] <rausb0> jdong: yeah, this crappy twinview notebook is the first machine i came across which has problems with 8139too
[02:48] <jdong> http://ubuntu-unleashed.blogspot.com/2007/08/howto-customize-your-own-ubuntu-live-cd.html
[02:48] <jdong> EEP.
[02:48] <jdong> if you want to rebuild the LiveCD.....
[02:48] <jdong> (it's just about the ugliest way to get the job done :D)
[02:49] <jdong> is there a postmount breakpoint in initramfs?
[02:49] <rausb0> jdong: i thought abount remastering too, but it would be much better if it runs with the normal live cd and just some boot param tweaking
[02:49] <jdong> rausb0: there actually may be.
[02:49] <rausb0> sits: no PIO in modinfo 8139too..
[02:53] <jdong> anyone remember how break=init would work?
[02:53] <jdong> I'm thinking we should break=init, then sabotage the 8139too.ko module, then continue booting
[02:53] <rausb0> jdong: :)
[02:53] <jdong> I forgot how to continue booting after a break=
[02:53] <jdong> ugly, but would work.
[02:53] <Mithrandir> "exit"
[02:53] <jdong> cool
[02:53] <rausb0> jdong: maybe:  exec /scriptname
[02:54] <jdong> well that was easy (tm)
[02:54] <sits> jdong: would you even need to break?
[02:54] <jdong> sits: why not?
[02:54] <jdong> sits: I'd expect as soon as udev starts on the main fileystem, the network card would get probed
[02:54] <sits> jdong: I'd have thought you could drop yourself to a shell assuming you didn't need something fundamental to typoe like USB
[02:55] <jdong> sits: eep or maybe 8139too is in initramfs.
[02:55] <rausb0> jdong: problem is, the 8139too is already in initramfs
[02:55] <jdong> rausb0: ok, then break earlier....
[02:55] <jdong> rausb0: break=modules
[02:55] <sits> jdong: ah I hadn't thought it would be initramfs. Would it be loaded right away though or only when a udev script kicked in?
[02:56] <jdong> then just rm /lib/modules/wherever/8139too.ko
[02:56] <jdong> wow this sounds so hackishly wrong :D
[02:56] <ogra> asac, sure, would make sense
[02:56] <rausb0> i didn't know this breakpoint thingy when booting, cool!
[02:57] <jdong> thanks Mithrandir :)
[02:57] <asac> ogra: i assign the bug to you then :)
[02:57] <sits> jdong: what is reading break?
[02:57] <jdong> sits: init script in initramfs
[02:58] <jdong> sits: see /usr/share/initramfs-tools/init
[02:58] <ogra> asac, well, i cant get around having nm in edubuntu-desktop (which is used in ltsp setups as well)
[02:58] <jdong> there are several points where it calls maybe_break
[02:58] <jdong> at various stages before bootup
[02:58] <sits> jdong: interesting. I'll have to remember that
[02:59] <asac> ogra: ogra so what could we do?
[02:59] <ogra> asac, will nm touch anything without the applet running ?
[02:59] <asac> ogra: yes i think so
[02:59] <ogra> gah
[03:00] <asac> i think only things that need user interaction won't happen without applet
[03:00] <sits> I guess while I'm here can I get someone to rate the importance of a bug?
[03:00] <asac> e.g. enter wpa key et al
[03:00] <sits> asac: it might do scanning
[03:00] <ogra> well, i have no wlan here if i'm not logged in (my nm isnt up to date though)
[03:01] <sits> asac: (if networking is enabled) and that might bring the interface up but I haven't looked too closely
[03:01] <asac> ogra: yes, but as sits points out it probably scans, doesn't it?
[03:01] <ogra> and the dhcp server interface for ltsp is set up b ythe installer ain /e/n/i
[03:01] <asac> sits: i think for open networks that might happen ... yes.
[03:01] <Hobbsee> asac: the -10 upload of nm includes the fix that's fixed my ipw3945, presumably?
[03:01] <sits> asac: does it just build up a network list
[03:01] <asac> Hobbsee: no
[03:01] <sits> (or does it still need prompting by nm-appklet for that?)
[03:02] <asac> Hobbsee: i need module update first, because i drop a workaround in 11 that helped some wpa ipw3945 users
[03:02] <Hobbsee> asac: ah right
[03:02] <sits> asac: I've rebuilt one of your ipw3945 modules btw
[03:02] <ogra> asac, so as long as nm doesnt touch static interfaces in /e/n/i nm shouldnt be a problem, i think bonding is a *very* special case
[03:02] <asac> ogra: i will stop nm touching anything in e/n/i
[03:03] <asac> ogra: thats the idea ... mail to u-d should go out today
[03:03] <ogra> well, it doesnt now, just dont re-enable it :)
[03:03] <asac> ogra: no you don't understand ... nm shouldn't even touch auto dhcp interfaces
[03:03] <ogra> (using 0.6.5-0ubuntu9)
[03:03] <asac> ogra: so its not a problem for you then i guess
[03:03] <ogra> oh, ah
[03:03] <sits> asac: I was having DHCP issues on an open AP (which I'm no longer near). Would the problem manifest on encrypted APs too?
[03:04] <ogra> well, the fix for the bug reporter would be to just define all his bonding stuff in /e/n/i ... right
[03:04] <asac> sits: on wep yes ... on wpa it might work without that patch
[03:04] <sits> asac: ah I'm on a WPA network at the moment. OK
[03:05] <sits> (and I'm using different drivers to boot)
[03:05] <asac> sits: so what does modinfo show as version for you now?
[03:06] <asac> sits: i remember that you were not able to setup the right module
[03:06] <ogra> asac, what would help i guess (since he talks about thin client users changing the interface) would be if the autostart script of nm-applet would exit 0 if LTSP_CLIENT is set (which is the case on all ltsp clients)
[03:06] <sits> asac: I'm on different drivers (iwl, hand built) but let me check the ones on disk I built an hour ago
[03:06] <asac> ogra: ok but then why don't you just disable nm-applet?
[03:07] <asac> sits: were did you get those from?
[03:07] <asac> my branch?
[03:07] <sits> asac: yup
[03:07] <sits> asac: 1.2.2d.ubuntu1
[03:07] <asac> ok
[03:07] <asac> sits: if you have that module ... pleast try wpa with the latest opennet nm branch
[03:08] <sits> asac: I doubt I have the space to build network-manager I'm afraid
[03:08] <ogra> asac, i use edubuntu-desktop on workstations, liveCD etc ...
[03:08] <sits> (I have all the bits but only 34Mbyte of space available)
[03:08] <asac> sits: no garbage?
[03:09] <sits> Let me just throw away the unpacked linux-source
[03:09] <asac> sits: that should be enough ;)
[03:09] <sits> OK back to 328Mbytes
[03:09] <sits> (I tried to build nm before so I now I have all the deps)
[03:09] <sits> s/now/know
[03:09] <asac> k
[03:10] <sits> asac: right where's this branch of yours, will it have the patches applied and how do I load the new NM rather than the old one?
[03:11] <asac> sits: you can either just start ./NetworkManager from src/ directory when the build is through ... or install the .debs
[03:11] <asac> sits: https://code.launchpad.net/~asac/network-manager/ubuntu.0.6.x.dev.opennet
[03:11] <sits> asac: remember - I'm currently on a WPA network. Is that OK?
[03:12] <asac> yes
[03:12] <StevenK> infinity: sejong currently hates life: NOT OK : <socket.timeout instance at 0x2ad19eafb0e0>
[03:12] <asac> that branch drops a hack that helped nm to connect for ipw3945 for some ... so its likely that wpa will break with old ipw driver but should work with new.
[03:12] <asac> sits: ^^
[03:17] <Hobbsee> people, how do i get rid of 'X Error: BadDevice, invalid or uninitialized input device 171'?  what actually is it?
[03:18] <ogra> seb128, http://people.ubuntu.com/~ogra/fusa.png shouldnt ogra2 have a checkmark as well here ?
[03:23] <jdong> Hobbsee: wacom
[03:23] <jdong> Hobbsee: look in xorg.conf for tablet devices
[03:23] <Hobbsee> ah, right.
[03:23] <Hobbsee> jdong: thanks
[03:24] <jdong> sure thing
[03:24] <sits> asac: (just preoccupied filing a bug)
[03:26] <seb128> ogra: it's should be unsensitive and checked yes
[03:27] <seb128> ogra: works for me, does it happen on a normal desktop or only on ltsp?
[03:29] <ogra> seb128, yes
[03:29] <ogra> i assume it checks DISPLAY
[03:29] <seb128> ogra: yes what?
[03:29] <ogra> hehe, sorry
[03:29] <ogra> only on ltsp
[03:30] <dholbach> calc: can you please take a look at bug 133793 and ACK the sync request, if it's ok?
[03:30] <ubotu> Launchpad bug 133793 in openoffice.org-voikko "Please sync openoffice.org-voikko from Debian" [Medium,Confirmed]  https://launchpad.net/bugs/133793
[03:30] <dholbach> also bug 134112
[03:30] <ubotu> Launchpad bug 134112 in openoffice.org "added Xb-Npp-xxx tags accordingly to "firefox distro add-on suport" spec" [Undecided,New]  https://launchpad.net/bugs/134112
[03:30] <dholbach> hey mako
[03:31] <ogra> seb128, do you have a possibility to disable autostart if LTSP_CLIENT is set so it doesnt show up on thin clients ?
[03:32] <ogra> (i'm fine to make a patch if not)
[03:33] <sits> seb128: I'm seeing the screensaver kicking in during totem-mozilla. It seems to have been reported before and fixed but I'm looking for where
[03:33] <seb128> ogra: what do you mean? Like doesn't start things in /etc/xdg/autostart?
[03:33] <sits> seb128: any quick ideas (otherwise I'll file a new bug)
[03:33] <Hobbsee> TheMuso: ping
[03:34] <seb128> sits: there is a bug about it
[03:34] <ogra> seb128, yeah, or just exit 0 if LTSP_CLIENT is set
[03:34] <seb128> ogra: it requires code patch but that's trivial, can you open a bug?
[03:34] <ogra> seb128, sure
[03:35] <seb128> ogra: are you sure you don't want things like things like the print applet being started on ltsp clients?
[03:35] <sits> seb128: I've found a closed one that makes reference to another one but I haven't found an open link yet
[03:35] <ogra> seb128, i only dont want fusa
[03:35] <ogra> and nm-applet
[03:36] <seb128> ogra: hum, you just asked to disable autostart on ltsp no?
[03:36] <ogra> no
 seb128, do you have a possibility to disable autostart if LTSP_CLIENT is set so it doesnt show up on thin clients ?
[03:36] <ogra> i asked to disable autostart of fusa on ltsp clients
[03:36] <seb128> ah
[03:36] <ogra> sorry
[03:36] <seb128> that's tricky
[03:36] <ogra> my bad
[03:36] <seb128> the applet is part of the panel profile
[03:36] <seb128> that's not an autostart
[03:37] <ogra> just add "if getenv(LTSP_CLIENT) then exit 0" at the top of fusa ?
[03:37] <seb128> we would change it to a "display the usersname" thing though ;)
[03:37] <ogra> its still its own binary i guess
[03:37] <seb128> well, if it exit 0 the panel will complain that an applet has exited and ask if you want to reload it I think
[03:37] <ogra> oh, evekn with proper exit status ... ? thats bad indeed
[03:39] <ogra> seb128, thats the panel profile in gconf ? or something hardcoded ?
[03:41] <seb128> ogra: gconf
[03:42] <seb128> ogra: the key have no fixed path though and are user datas after first startup
[03:42] <ogra> yeah, i see /usr/share/gconf/defaults/05_panel-default-setup.entries
[03:42] <sits> seb128: OK I see http://bugzilla.gnome.org/show_bug.cgi?id=425469 . Thanks for the tip off
[03:42] <ubotu> Gnome bug 425469 in Browser plugin "Browser plugin should inhibit screensaver" [Normal,Resolved: fixed] 
[03:43] <seb128> ogra: making the applet display the user name would not be good enough for you?
[03:43] <ogra> my prob is that i want fusa on workstations and live systems ....
[03:43] <ogra> thats fine
[03:43] <seb128> k, I'll do that then
[03:43] <seb128> can you open a bug on fast-user-switch-applet?
[03:44] <seb128> so it gives an indication of who is using the computer and doesn't look weird
[03:44] <ogra> so you just disable the pulldown menu ?
[03:44] <ogra> sounds good :)
[03:45] <seb128> ogra: yes
[03:46] <seb128> ogra: or make it display one line with "no user switching on thinclient" or something like that maybe
[03:47] <ogra> yeah, prevents bug reports
[03:47] <dholbach> calc: also bug 5462
[03:47] <ubotu> Launchpad bug 5462 in mc "Dutch translation: wrong shortcut" [Medium,Confirmed]  https://launchpad.net/bugs/5462
[03:47] <ogra> Bug #137980
[03:47] <ubotu> Launchpad bug 137980 in fast-user-switch-applet "fusa should respect thin clients and not offer user switching but show the logged in username" [Undecided,New]  https://launchpad.net/bugs/137980
[03:49] <sits> seb128: ok you've managed to head off one bug today what about this one (again I've done a quick search but nothing has come up)
[03:50] <sits> seb128: gnome-power-manager still "reports" laptop battery information when battery is removed on the fly
[03:50] <seb128> sits: dunno about gnome-power-manager, that's maintained by ogra
[03:50] <sits> seb128: diverted again!
[03:50] <seb128> ;)
[03:51] <sits> seb128: you're doing well today :)
[03:51] <sits> seb128: this isn't over - I'll be asking you again soon enough
[03:52] <sits> ogra: gnome-power-manager still "reports" laptop battery information when battery is removed on the fly - is that a known bug?
[03:53] <ogra> sits, i really only care for g-p-m packaging in the recent times ...
[03:54] <dholbach> doko: do you think the fix for bug 137909 is OK as it is?
[03:54] <ubotu> Launchpad bug 137909 in libobjc-lf2 "FTBFS on ia64 and lpia" [Undecided,Confirmed]  https://launchpad.net/bugs/137909
[03:54] <sits> ogra: where does a bug on g-p-m go?
[03:55] <ogra> to LP
[03:56] <doko> dholbach: does upstream really encode the debian architecture name in their config system? lpia ...
[03:56] <dholbach> doko: I have no idea - it's a sponsoring bug that I'd like somebody to look at - I have no idea if this is the right way to fix it
[03:57] <seb128> sits: upstream is using bugzilla.gnome.org though
[03:57] <ogra> seb128, but richard regulary visits LP and goes through bugs there
[03:57] <sits> seb128: I can never tell if it's an Ubuntu specific feature
[03:57] <sits> seb128: OK what about this bug -
[03:57] <seb128> ogra: ok, nice
[03:58] <sits> seb128: rhythmbox segfaults while holding down enter on aesop's fable example ogg?
[03:58] <seb128> sits: do you have a backtrace of the crash?
[03:58] <ogra> seb128, i hope that wont change now that he's RH employee
[03:59] <dholbach> doko: would you mind following up on the bug?
[03:59] <sits> seb128: it would be useless because I don't think I have debug symbols installed
[03:59] <sits> it's highly reproducible though
[03:59] <sits> (I'll see what I get)
[04:00] <sits> hmm no segfault immediately this time but the application has locked up
[04:01] <dholbach> mvo: also bug 134490
[04:01] <ubotu> Launchpad bug 134490 in apt-watch "Please merge apt-watch (0.3.2-9) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/134490
[04:03] <sits> seb128: ok got a backtrace but its mostly ??
[04:03] <sits> only
[04:03] <sits> #8  0xb7edc58a in rb_entry_view_set_state ()
[04:03] <sits>    from /usr/lib/librhythmbox-core.so.0
[04:03] <sits> #9  0x080708bb in rb_shell_player_playpause ()
[04:05] <calc> dholbach: ok i'll look at them, thanks
[04:05] <dholbach> calc: thanks a lot
[04:05] <seb128> sits: where do you do enter?
[04:06] <ogra> mjg59, http://paste.ubuntu-nl.org/36687/ do you think that would be ok ?
[04:07] <sits> seb128: you have to have it hightlighted in the list of tracks
[04:07] <sits> seb128: so import /usr/share/example-content/fables_01_01_aesop.spx
[04:08] <sits> seb128: then highlight fables_01_01 etc at the bottom
[04:08] <seb128> sits: k, I get the bug easily
[04:08] <sits> seb128: then hold down enter/return for five seconds and let go
[04:08] <sits> seb128: sorry I haven't written up good steps yet
[04:09] <sits> seb128: if it's unreported I'll file it
[04:10] <bddebian> Heya
[04:11] <dholbach> Riddell: there are two qt4-x11 patches on http://daniel.holba.ch/sponsoring - do you think you can take a look at them with your next qt4-x11 upload?
[04:11] <Riddell> dholbach: yes, I know, they're still on my todo
[04:11] <seb128> sits: you can open a bug about it
[04:11] <Riddell> maybe I can do them today before I go away
[04:11] <dholbach> okiedokie
[04:12] <dobey> hey dholbach
[04:12] <sits> seb128: ok will do
[04:12] <dholbach> hey dobey
[04:12] <dobey> what's up?
[04:12] <seb128> hi dobey
[04:12] <dobey> hey seb128
[04:13] <dholbach> mvo: there's also some smart goodness in bug 116222 :)
[04:13] <ubotu> Launchpad bug 116222 in smart "Smart launcher not added to Menu" [Undecided,Confirmed]  https://launchpad.net/bugs/116222
[04:15] <mvo> dholbach: looks like you are in cleanup mode today
[04:15] <dholbach> YES :)
[04:16] <pygi> hey dholbach :)
[04:17] <dholbach> hi pygi
[04:21] <infinity> StevenK: All fixed.  And back to my sick bed with me. :/
[04:23] <ion_> Yay for dpkg triggers. In the previous dist-upgrade, there would have been three runs of ldconfig and two runs of update-initramfs otherwise.
[04:24] <StevenK> infinity: Feel better soon.
[04:24] <StevenK> Ooh. update-initramfs is now down with triggers?
[04:24] <StevenK> Excellent.
[04:27] <lamont> can we have texlive-$lang crap use triggers, too?  or do they already (or did that happen after we stopped syncing sid for gutsy?)
[04:27] <ion_> lamont: The change would be trivial.
[04:28] <cjwatson> ogra: the Depends: acpi-support is wrong
[04:28] <ogra> cjwatson, well, it wont work without the dirs ...
[04:28] <cjwatson> ogra: there's no reason why it needs to depend on acpi-support just to ship some files to enhance acpi-support's behaviour
[04:28] <ogra> oh, wait, sbalneav has a mkdir in there
[04:29] <cjwatson> ogra: err
[04:29] <cjwatson> ogra: you *do* know that dpkg creates directories on installation, don't you?
[04:29] <ogra> heh, yes
[04:29] <cjwatson> and that the dependency would have made no difference to getting the files in place in debian/rules anyway?
[04:29] <ogra> yeah
[04:30] <cjwatson> so, kill the bogus dep :)
[04:30] <ogra> will do :)
[04:30] <cjwatson> as written it will break dhcpd on architectures without acpi-support too
[04:30] <sbalneav> Sorry for the dep :(
[04:31] <cjwatson> not a problem
[04:31] <ogra> sbalneav, since it was my suggestion dont hang your head
[04:31] <ogra> tsk
[04:31] <ogra> canadians
[04:31] <ogra> <-- is to blame, dont belive him
[04:48] <asac> cjwatson: do you have power to approve my post to kernel list?
[04:53] <cjwatson> asac: no - try BenC or lamont
[04:53] <sits> is the source symlink in the lib directory of a running kernel a standard thing?
[04:53] <BenC> kyle and lamont
[04:54] <BenC> sits: yes
[04:54] <sits> BenC: when does it get made?
[04:54] <sits> BenC: just on installation of the headers?
[04:54] <sits> or installation of something else?
[04:54] <BenC> sits: it's standard, but we don't use it
[04:54] <BenC> we use a build symlink
[04:55] <BenC> which gets installed by the matching linux-headers package
[04:55] <BenC> build is standard too
[04:55] <sits> I see build
[04:55] <sits> but I see no source
[04:56] <sits> (but checking another distro like Fedora shows a symlink from source -> build, and checking SUSE shows two symlinks with the source one currently broken)
[04:56] <BenC> source is pretty useless in practice
[04:56] <BenC> unless you do a lot of local builds
[04:56] <sits> I was wondering whether source was legacy or just on those distros which also ship fully compiled source (seemingly rare)
[04:57] <asac> lamont: gratias
[04:57] <sits> BenC: so source isn't made for distro kernels but may be made on others?
[04:57] <BenC> lamont: can you send me admin pw for kernel-team?
[04:57] <BenC> sits: for the most part, source link is optional...it's the build link that matters for third-party module compiles
[04:58] <sits> BenC: I see
[04:58] <sits> BenC: thanks!
[04:58] <BenC> np
[04:58] <lamont> asac: done
[04:58] <lamont> BenC: admin or moderator?
[04:58] <lamont> and yes.
[04:59] <lamont> moderator is easy (I know that one).. admin will take me a little work to dig up
[04:59] <BenC> lamont: just to moderate
[05:01] <mjg59> ogra: Lose the depends on acpi-support?
[05:01] <mjg59> Nothing will break if it's not installed
[05:01] <ogra> mjg59, already happend, cjwatson chimed in here :)
[05:01] <mjg59> Ok, cool
[05:02] <ogra> thanks for looking
[05:02] <sits> right time to test that asac driver
[05:04] <asac> sits: kernel team is already looking ... feedback still appreciated though.
[05:07] <ddaa> Is the gnome-panel "Run Application" dialog known to leak memory like an Alzheimer patient?
[05:07] <seb128> no
[05:07] <mr_pouit> ogra: edubuntu is probably affected by Bug #115952... (I just fixed xubuntu gdm-cdd.conf)
[05:07] <ubotu> Launchpad bug 115952 in gdm "Gutsy: No users are shown in GDM" [Low,Fix released]  https://launchpad.net/bugs/115952
[05:07] <ddaa> seb128: want to try something for me, then?
[05:07] <seb128> ddaa: yes?
[05:08] <ddaa> start top, or the gnome system monitor process list
[05:08] <seb128> hi mr_pouit
[05:08] <ddaa> look at the gnome-panel's memory usage
[05:08] <mr_pouit> hi seb128
[05:08] <ddaa> start the "Run application" dialog
[05:08] <ogra> mr_pouit, that enabled the browser all the time ?
[05:08] <ddaa> type one letter, say, "g"
[05:08] <ddaa> close the dialog
[05:09] <ogra> s/enabled/enables/
[05:09] <ddaa> I have the impression that the completion list stuff has a serious leak
[05:09] <seb128> right,
[05:09] <seb128> it goes up around 0.1meg every time
[05:09] <ddaa> more for me
[05:09] <ddaa> up to 1MB every time
[05:10] <mr_pouit> ogra: themes without browser are still ok, but themes with user lists won't show any user if Browser=True
[05:10] <ddaa> was wondering why it was bloating up to hundreds of MB...
[05:10] <mr_pouit> s/True/False/ sorry
[05:10] <seb128> ddaa: can you open a bug on gnome-panel? I'll have a look later with valgrind
[05:10] <ddaa> sure
[05:10] <seb128> thanks
[05:10] <ddaa> gtk bugz ftw!
[05:11] <seb128> heh
[05:11] <ogra> mr_pouit, i'm not even aware we have en edubuntu browser theme :) i'll check that
[05:11] <seb128> ogra: you don't need to, that will break any browser theme selected
[05:12] <seb128> ogra: like if users switch from the edubuntu theme to the GNOME one with browser
[05:12] <ogra> seb128, oh, right, .conf != theme file, i should stop working for the day
[05:13] <mr_pouit> yeah, I just switched from xubuntu to human with browser to try, and it was broken. I guess this is the new default behavior since gdm 2.19.
[05:14] <mako> ergh, can someone undo that
[05:15] <mr_pouit> seb128: thanks for "fixing" gnome-system-tools btw :)
[05:15] <thom> topicdiff++
[05:15] <seb128> mr_pouit: no problem ;)
[05:15] <mako> thom: thanks dude :)
[05:16] <mako> dholbach: hey dude
[05:16] <thom> no worries mate :)
[05:16] <kekZpriester> what is uvf?
[05:17] <lamont> kekZpriester: upstream version freeze
[05:18] <kekZpriester> thx lamont
[05:19] <ddaa> seb128: bug 138006
[05:19] <ubotu> Launchpad bug 138006 in gnome-panel "Memory leak in "Run Application" dialog" [Undecided,New]  https://launchpad.net/bugs/138006
[05:20] <seb128> ddaa: thanks
[05:25] <ddaa> mh
[05:25] <ddaa> I wonder if my having "assistive" stuff enable makes the leak more serious
[05:26] <ddaa> brb
[05:28] <xhaker> seb128, sorry for messing up the changelog entries. I had my doubts if I should add the debian ones on a merge.
[05:29] <xhaker> seb128, talking about #137531
[05:29] <seb128> xhaker: if you merge on Debian everything from the debian version should be there
[05:29] <seb128> xhaker: that's basically taking the debian version and adding ubuntu changes
[05:29] <seb128> ddaa: likely due to a11y yes
[05:29] <ddaa> bingo, it leaks a lot less with "Assistive Technologies" disabled
[05:29] <seb128> ddaa: or a a part of if, because it's going up there but quite slowly
[05:29] <xhaker> seb128, but we do keep the ubuntu changelog entries too right?
[05:30] <seb128> xhaker: some people do
[05:30] <ddaa> without it, I observer the same as you, about 0.1MB every time
[05:30] <seb128> I don't usually, just summarize in the new changelog entry, but I think most of other people keep those
[05:30] <seb128> ddaa: could you also note what you disabled in the bug?
[05:30] <ddaa> Yup, coming back to the bug.
[05:31] <xhaker> seb128, it looks weird with them I know. I kept them. i've attached a fixed debdiff.
[05:31] <ogra> asac, any big objections against something like that: http://paste.ubuntu-nl.org/36698/ ?
[05:32] <seb128> xhaker: thanks, I'll do a work break soon but I'll look at that again later
[05:32] <xhaker> seb128, should be in your mail queue nevertheless :)
[05:32] <asac> ogra: can't this be done outside of nm-applet somehow? otherwise its ok to have it i guess.
[05:32] <seb128> cool
[05:32] <ogra> asac, (yes its missing brackets, i mean the concept)
[05:33] <ogra> asac, well nm-applet is the most proper place to do it
[05:33] <terlmann> would you devs consider , in future, implementing kernel code that would allow a system reset without a full reboot ?
[05:33] <asac> ogra: the brackets are not the main problem, but the patch direction :)
[05:33] <ogra> otherwise i'd have to go for the autostart function of gnome-session and start maintaining white/blacklists or so
[05:34] <asac> ogra: ok... if you want it pleaes attach it to some bug against network-manager-applet ... as i will start working on applet soon'ish
[05:34] <ogra> asac, well, surggest something better :) thats the usual way we use to make apps behave on thin clients
[05:34] <asac> ogra: ok then thats fine ... is that env distribution specific or an agreed universal standard?
[05:34] <asac> (read: is it worth to get this upstream) ?
[05:34] <ddaa> seb128: bug updated
[05:34] <ogra> asac, i'll put it on bug 123808 since its a part of the fix for that
[05:34] <ubotu> Launchpad bug 123808 in network-manager "NetworkManager Applet does not recognize ethernet bonding.  " [Undecided,Won't fix]  https://launchpad.net/bugs/123808
[05:35] <asac> ogra: ok ... pleaes retitle the bug in that turn as well :)
[05:35] <asac> ogra: and reopen/confirm obviously ;)
[05:35] <asac> ogra: ah ... and reassign to -applet (if you want)
[05:35] <ogra> yup, will do
[05:35] <ogra> now to find a title where i dont have to dicuss 2h with the reporter about :P
[05:36] <terlmann> rot-13 ?
[05:38] <asac> ogra: remember that users can still just send dbus messages manually ... if that bothers you.
[05:38] <ogra> no, it doesnt :)
[05:39] <ogra> i just dont want an easy gui way for joe user to break stuff
[05:39] <asac> ogra: i can already imagine how students make fun of playing with NM :)
[05:40] <asac> ogra: sure ... given that nm won't manage static+auto dhcp interfaces anymore it should be ok i guess.
[05:40] <ogra> yeah
[05:40] <ogra> and students shouldnt be in the admin gropup
[05:40] <ogra> -up
[05:40] <ogra> ogra2@laptop:~$ nm-applet
[05:40] <ogra> ** (nm-applet:14286): WARNING **: <WARN>  nma_dbus_init(): could not acquire its service.  dbus_bus_acquire_service() says: 'Connection ":1.79" is not allowed to own the service "org.freedesktop.NetworkManagerInfo" due to security policies in the configuration file'
[05:41] <ogra> looks really nice :)
[05:41] <asac> hehe
[05:42] <asac> the warning does not really describe what happened accurately ... but still not really wrong:)
[05:42] <ogra> "is not allowed to own the service ... due to security policies in the configuration file" sounds ok to me
[05:43] <asac> ogra: you sure there is no other applet running?
[05:43] <asac> ogra: because thats the message you get then
[05:43] <ogra> ogra is running the applet on the server, ogra2 is on a thin client
[05:44] <ogra> and ogra2 isnt in the admin group ...
[05:45] <asac> ogra: if you are still in bug, plesae add beta milestone
[05:45] <asac> so I won't miss it
[05:45] <ogra> will do
[05:45] <ogra> well, the reporter will surely step on our toes (he's that kind of guy) if it doesnt progress :)
[05:47] <asac> ogra: then he is probably happy now that its not "won't fix anymore" :)
[05:47] <ogra> yeah
[05:48] <ogra> he already complained to the ML about us evil devs that dont fix his bugs :)
[05:48] <ogra> but he's fine again, i sorted that
[05:48] <asac> now, i am the bad guy, and you are the good one ... I am fine with that ;)
[05:50] <ddaa> seb128: by the way, bug 138014
[05:50] <ubotu> Launchpad bug 138014 in gnome-applets "mini_commander_applet manpage still here" [Undecided,New]  https://launchpad.net/bugs/138014
[05:58] <pochu>  we plan to support LTS -> LTS+1 upgrades directly, don't we?
[05:58] <ogra> pochu, yes
[06:00] <pochu> So bug 138013 isn't really a bug :)
[06:00] <ubotu> Launchpad bug 138013 in ubuntu "Migration from 6.06 LTS to 8.04 LTS has to be smooth" [Undecided,New]  https://launchpad.net/bugs/138013
[06:02] <ogra> no :)
[06:03] <ogra> pochu, you can invalideate it with a comment that we plan this feature anyway :)
[06:03] <pochu> Already done ;)
[06:18] <superm1> mvo, ping
[06:25] <superm1> hey mvo.  i was going to ask if you can add mythbuntu-desktop as valid as a desktop package to update-manager
[06:29] <mvo> superm1: sure, I can do this right away
[06:31] <Riddell> lamont: sell it to me
[06:31] <Riddell> (no new features, good reason to have it a bonus)
[06:31] <mvo> superm1: done, will be part of the next upload (thanks for leting me know aobut it!)
[06:31] <xhaker> Riddell, bash completion?
[06:32] <Hobbsee> lamont: hint:  offer beer, or $beverageofchoice
[06:32] <superm1> thx mvo, i didn't mean right away, i would have filed a bug, just wanted to make sure it was cool with you, but thanks for getting it done so quick :)
[06:32] <Riddell> xhaker: so it does have new features?
[06:32] <xhaker> i think it fixes
[06:32] <lamont> Riddell: "Fix "git add -u" data corruption.
[06:32] <lamont> 
[06:32] <lamont>     This applies to 'maint' to fix a rather serious data corruption
[06:32] <lamont>     issue.  When "git add -u" affects a subdirectory in such a way
[06:32] <lamont>     that the only changes to its contents are path removals, the
[06:32] <lamont>     next tree object written out of that index was bogus, as the
[06:32] <lamont>     remove codepath forgot to invalidate the cache-tree entry.
[06:32] <lamont> "
[06:33] <Riddell> that sounds like a good thing
[06:34] <Riddell> lamont: is that the only change or is there a changelog somewhere?
[06:34] <lamont> looking at it now
[06:34] <lamont> someone else just poked me with it, since I'm his ubuntu-guy
[06:36] <lamont> Riddell: there are a few other bug fixes between .4 and .5
[06:36] <lamont> all bug fixes though, new features into at least 1.5.3
[06:37] <milli> lamont: Just looking to get git-core (and friends) 1.5.2.5 instead of 1.5.2.4 to fix that data loss issue.  I would not suggest 1.5.3.x be put in yet (was just released!)
[06:37] <lamont> +   - "git checkout-index" and other commands that checks out
[06:37] <lamont> +     files to the work tree tried unlink(2) on directories,
[06:37] <lamont> +     which is a sane thing to do on sane systems, but not on
[06:37] <lamont> +     Solaris when you are root.
[06:37] <lamont> milli: same thinking
[06:38] <Riddell> lamont: ok, sounds good, go ahead
[06:39] <lamont> given that sid has already rolled to 1.5.3, and etch has 1.5.2.4, I'll just upload 1.5.2.5-2build1 directly to gutsy, rather than praying that a sync gets done before the source gets removed from the debian archive in a couple hours...
[06:40] <lamont> Riddell: sound right"
[06:40] <lamont> ??
[06:40] <Riddell> lamont: sure
[06:41] <mvo> superm1: no problem, its easy/quick enough to add :) just two lines the config file of the upgrader (and I'm working on that one anyway ATM)
[06:41] <milli> lamont: and the feisty backport is 1.5.2.3 ... :(
[06:41] <digisus> Hello! It says "Tribe CD 6 (not released)" on https://wiki.ubuntu.com/GutsyReleaseSchedule -- Is it canceled or postponed?
[06:42] <lamont> milli: and using -backports repositories has always struck me as silly
[06:42] <bryce> digisus: canceled
[06:43] <digisus> bryce: Alright. Thanks.
[06:43] <lamont> ScottK: wanna trigger a backport of git-core 1:1.5.2.5-2build1 to feisty once it shows up in gutsy??
[06:43] <ScottK> lamont: If you can get milli to file the feisty-backports bug, I'd be glad to.
[06:43] <lamont> milli: your ball.
[06:44] <milli> nod
[06:48] <lamont> milli: uploaded
[06:49] <milli> lamont: ty
[06:57] <lamont> ScottK: btw, doing a backport of git-core to feisty will require either backporting asciidoc from gutsy, or dealing with the build-dep...
[06:59] <ScottK> lamont: It takes a core-dev to upload a source backport.  I'd rather change the asciidoc dep.  Would you be up for uploading it?
[06:59] <ScottK> Dunno what else changing asciidoc would affect.
[07:00] <lamont> sigh.  sure
[07:01] <lamont> ah ~feisty1.  chcek
[07:23] <milli> lamont: and ScottK, for the asciidoc build-dep, it is completely safe to change it to (>> 7.0.2)
[07:23] <milli> also may need to change libcurl3-gnutsl-dev --> libcurl3-gnutls-dev  (tsl versus tls typo)
[07:28] <lamont> milli: that's already fxied
[07:36] <lamont> ScottK: want me to close the bug in the upload?  (remind me of the syntax one more time... sigh)
[07:41] <bddebian> heh
[07:41] <davmor2> Riddell: ping
[07:42] <Riddell> hi davmor2
[07:43] <davmor2> Riddell: when the update icon shows up at the beginning it is always a green circle saying no updates.  If you go into adept and manually update though there can be loads.  Is this known?
[07:46] <pygi> oh, iXce !
[07:46] <pygi> long time no see ;)
[07:46] <pygi> how are you doing?
[07:46] <iXce> heya pygi =)
[07:46] <iXce> pretty well, back to school
[07:48] <iXce> erm, I'm having a packaging problem with texlive
[07:48] <iXce> in breezy the file "landscape.sty" was distributed in tetex-extra, but in feisty and gutsy I can't find it anymore
[07:48] <Riddell> davmor2: beginning of what?
[07:48] <iXce> (it seems that the package has entirely been redone around early 2006)
[07:50] <davmor2> Riddell: Sorry not well explained.  When you switch on a machine and start a session.  You get a green circle appear in the task bar which when highlighted says "no updates" or something similar.
[07:51] <sits> Can I convince someone to rate a xorg bug's priority?
[07:51] <davmor2> Riddell: in reality just when I switched on there were 51 updates.  But it still said there were none.
[07:52] <lamont> where would that crowbar go??
[07:52] <lamont> seb128: ??
[07:52] <kylem> through your speakers.
[07:53] <Riddell> davmor2: do you have update-notifier-common installed?
[07:53] <Riddell> davmor2: by the way #kubuntu-devel may be better for KDE related talk
[07:53] <davmor2> Riddell: I will check okay np
[07:59] <bryce> Riddell: unfortunately it appears on my system there is both a kde-guidance and a guidance-backends installed.  I have two copies of xorgconfig.py present, and the one that the kde-guidance fixed is not the one that displayconfig-gtk uses, so I'm still having the same issue.  Any ideas?
[07:59] <Riddell> err, sounds like packaging breakage
[07:59] <Riddell> are they in the same place?
[08:00] <Riddell> guess not with python-support
[08:00] <bddebian> Could a buildd admin please give-back taxbird now that libgeier is built??
[08:00] <Riddell> bryce: the guy to ask is glatzor who isn't online just now
[08:01] <Riddell> bryce: that shouldn't be duplicated as far as I know
[08:02] <bryce> no one is in python-support, the other is in /usr/lib/python2.5
[08:05] <Riddell> mvo: does update-notifier work for users who turn their machines off at night?
[08:05] <Riddell> since it wouldn't do the nightly apt-get update
[08:10] <bddebian> mmm Arby's
[08:10] <Arby> hehe
[08:12] <bryce> Riddell, ahh, I needed guidance-backends, not just kde-guidance.  Works now.
[08:13] <Riddell> bryce: maybe you have an old kde-guidance then
[08:13] <Riddell> I don't have xorgconfig.py in my current version
[08:13] <bryce> could be
[08:13] <bddebian> Is there a list of buildd admins somewhere?
[08:13] <torkel> Riddell: isn't anacron taking care of it when they are turning the machine on?
[08:14] <bryce> possibly I had an old copy of displayconfig-gtk installed with its own guidance backend stuff.  I've checked on a relatively freshly installed machine and also see only one copy of xorgconfig.py there
[08:14] <Amaranth> bryce: why did you reassign bug 137745 to compiz?
[08:14] <ubotu> Launchpad bug 137745 in compiz "compiz can only used by one user" [Wishlist,New]  https://launchpad.net/bugs/137745
[08:16] <desrt> ya... that's definitely not a compiz problem :p
[08:16] <iXce> yeah, quite
[08:16] <desrt> i think it's caused by a double free in the nvidia driver...
[08:17] <Amaranth> hehe
[08:17] <Amaranth> it's a DRI problem
[08:17] <iXce> desrt : which one? :>
[08:17] <bryce> Amaranth: well, it doesn't seem like something I can do anything for within X
[08:17] <Amaranth> bryce: And I can't do anything within compiz :)
[08:18] <Amaranth> bryce: have to redo the way 3d drivers work to fix it
[08:18] <iXce> reassign to mesa?
[08:19] <bryce> Amarath, the reason I put it back to compiz is because ultimately the issue affects compiz, and while "X doesn't support DRI on multiple sessions" could well describe the root cause, I don't think that provides a solution, so I put it into compiz in hopes y'all could come up with a different workaround or something
[08:20] <Amaranth> bryce: there is no workaround, 3d of any kind does not work
[08:20] <Amaranth> should i just close it Won't Fix?
[08:20] <bryce> Amaranth: then perhaps it shold be closed as won't fix
[08:20] <Amaranth> there is no way in hell we can fix it
[08:20] <bryce> yep
[08:20] <mvo> Riddell: it should, anacron will ensure that (if not, that would be a anacron issue)
[08:21] <sladen> is it a DRI problem, or is it a *DRI ownership* problem
[08:21] <cjwatson> surely it *should* be fixed, it's just that it's a difficult upstream problem
[08:21] <bryce> I moved it to be a wishlist, assuming others may complain about it in the future
[08:21] <mjg59> DRI
[08:21] <Riddell> mvo, torkel: right
[08:21] <cjwatson> *we* won't fix is not quite the same as won't fix IMO
[08:22] <Amaranth> sladen: it's dri, drm, or both
[08:22] <bddebian> This is wrong isn't it? pkg-config --modversion evolution-shell-$version
[08:22] <Chipzz> Amaranth: I'ld say not WONTFIX; this is an issue that's not impossible to solve, just very hard to solve, and should be solved upstream
[08:22] <Amaranth> sladen: i know it works with nvidia
[08:22] <Amaranth> Chipzz: and won't be solved for a couple years, if ever
[08:22] <mjg59> Amaranth: Nvidia doesn't use DRI, so it's not especially interesting
[08:22] <Amaranth> I haven't even seen anyone talking about fixing it
[08:22] <Chipzz> Amaranth: yes, but that's no reason to mark it wontfix imo
[08:23] <Amaranth> actually the nouveau driver has the best chance of not having this problem
[08:24] <mjg59> Well, it also won't run compiz, which makes it less relevant to the problem at hand :)
[08:24] <Amaranth> oh, i'm sure it has the problem now :0
[08:25] <Amaranth> but nvidia hardware supports this stuff on it's own
[08:26] <mjg59> It's not a hardware issue. It's just related to how DRI is designed. Nvidia don't use DRI, so don't suffer from this issue.
[08:27] <Chipzz> Amaranth: wontfix means something along the lines of: this bug is bogus, I wont fix it, get lost
[08:27] <sits> cjwatson: CANTFIX?
[08:28] <sits> cjwatson: or UPSTREAM?
[08:29] <bryce> it seems it would be best to have a wishlist bug in compiz describing the general problem, pointing to a second bug either in xorg or upstream that describes the DRI issue in more detail
[08:29] <sits> bryce: almost sounds like you want bug dependencies
[08:30] <cjwatson> sits: neither exists as a resolution in Launchpad, though it's possible to create an upstream task
[08:30] <mathiaz> keescook: I've talked with kylem and he's going to upload a new l-u-m which has a apparmor-modules-2.1 provide.
[08:30] <cjwatson> sits: doesn't need bug dependencies, multiple tasks do the job
[08:30] <mathiaz> keescook: that may break things with apparmor
[08:30] <sits> cjwatson: hmm interesting...
[08:30] <keescook> mathiaz: s'okay, we'll fix 'em.  :)
[08:30] <bryce> sits, well, just a pointer from one bug to another would be sufficient to communicate to future bug reporters "yes we know there is an issue, but the problem really is over here"
[08:31] <keescook> cjwatson: so, whatcha think of pam 0.99?  :)  should I move forward and open a UVFe bug for it?
[08:31] <sits> bryce: the only thing I can quickly think of would be duplicating on an invalid bug. People hate that though
[08:31] <sits> (the invalid bug would contain the information near the top)
[08:31] <cjwatson> keescook: if you think we can shake out issues with it in time, sure
[08:32] <cjwatson> sits: that's a baroque and strange solution
[08:32] <cjwatson> it's not invalid either. it should be left open
[08:32] <lamont> kylem: excellent solution, except that I want the speakers to work.. I just don't want it to announce that I booted the machine to the room full of execs...
[08:32] <keescook> cjwatson: well, that's why I'm looking to you; I'm less familiar with PAM than you, so while I think it's possible, I'm curious to hear other opinions.  :)
[08:32] <lamont> ScottK: git-core_1.5.2.5-2~feisty1 uploaded to feisty-backports
[08:32] <cjwatson> keescook: I wouldn't be so sure about that
[08:33] <cjwatson> keescook: you might as well go ahead with the UVFe request; worst case we say no after looking at it ...
[08:33] <keescook> heh
[08:33] <cjwatson> it's too late in the week for me to think hard about it now
[08:33] <keescook> cjwatson: yeah.  I figure we have to do it some time, and I'd rather shake it out now than in hardy.
[08:33] <keescook> sounds good
[08:33] <sits> cjwatson: I guess I'm not thinking in an articulate enough fashion. I just had the impression it's something that can be only fixed upstream
[08:33] <sits> and won't be fixed directly by someone working in Ubuntu
[08:34] <cjwatson> sits: which is not a reason for us to refuse to accept it in our bug tracking system
[08:34] <cjwatson> if we reject it, somebody will just file it again later; we aren't gaining anything at all by trying to get rid of it
[08:34] <sits> cjwatson: your point of view is far more considered
[08:34] <cjwatson> I'm not trying to browbeat you, I'm just trying to explain
[08:35] <cjwatson> a defect in Ubuntu is a defect regardless of who needs to fix it
[08:35] <cjwatson> now, we might want to open other tasks to log the organisation who needs to fix it
[08:35] <sits> cjwatson: I can see that : ) I'm trying to adjust my viewpoint while still providing a different point of view to you
[08:36] <cjwatson> and drop the priority of the Ubuntu bug way down so that it doesn't interfere with other work
[08:36] <cjwatson> it is certainly important to prioritise what we do
[08:36] <seb128> lamont: system, preferences, sounds?
[08:36] <sits> cjwatson: it sounds like a setting expectations problem. By setting the priority that gives people who arrive at it more information...
[08:36] <cjwatson> we can always explain more in prose
[08:37] <sits> new bugs can be duped on it... The problem can be described in technical detail
[08:37] <Amaranth> grr
[08:37] <sits> cjwatson: Is there anyone else out there who is fixing this?
[08:38] <sits> (or working on something similar?)
[08:38] <Amaranth> now how the hell do i add the upstream bug to a bug report?
[08:38] <cjwatson> I don't know
[08:38] <Amaranth> this seems to change every time i try
[08:38] <sits> Amaranth: Add Project?
[08:38] <cjwatson> Amaranth: "also affects... project"
[08:38] <Amaranth> that only lets me add compiz-settings
[08:39] <cjwatson> Amaranth: "Choose another project"
[08:39] <sits> cjwatson: and is it a small or a big task to solve?
[08:39] <cjwatson> sits: AIUI, very large
[08:39] <sits> cjwatson: but it can be done without client X app changes?
[08:40] <Amaranth> cjwatson: i accidentally added compiz-settings, marked it invalid, and now the UI changed _again_
[08:40] <Amaranth> so i don't have Choose Another Project anymore
[08:40] <Amaranth> I have a Project textbox to put something in
[08:40] <sits> Amaranth: bug #?
[08:40] <cjwatson> sits: I have no idea. I am not the person to ask
[08:40] <Amaranth> https://bugs.launchpad.net/compizsettings/+bug/137745
[08:40] <ubotu> Launchpad bug 137745 in compiz "compiz can only used by one user" [Wishlist,Confirmed] 
[08:40] <Amaranth> oh, bleh
[08:40] <Amaranth> that's why
[08:40] <Amaranth> my URL got changed
[08:40] <sits> cjwatson: sorry my bad
[08:41] <Amaranth> oh, no, that didn't help
[08:41] <Amaranth> sits: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/137745 needs to be linked to https://bugs.freedesktop.org/show_bug.cgi?id=3834
[08:41] <ubotu> Launchpad bug 137745 in compiz "compiz can only used by one user" [Wishlist,Confirmed] 
[08:41] <Amaranth> sits: if you figure out how let me know :)
[08:42] <sits> Amaranth: I think I can guess at the problem
[08:42] <Amaranth> oh?
[08:42] <sits> Amaranth: let me just check
[08:42] <sits> Amaranth: can you visit https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/137745 ?
[08:42] <ubotu> Launchpad bug 137745 in compiz "compiz can only used by one user" [Wishlist,Confirmed] 
[08:42] <sits> Amaranth: and check whether you are logged in?
[08:43] <Amaranth> i am
[08:43] <sits> Then look at the right hand side
[08:43] <lamont> seb128: thanks
[08:43] <sits> Amaranth: (click on the link again)
[08:43] <sits> Amaranth: (the one just pasted)
[08:43] <Amaranth> still logged in
[08:43] <lamont> seb128: and turn off 'play system sounds'?
[08:43] <seb128> lamont: do you want to disable the session sound or the gdm one?
[08:43] <lamont> hrm...
[08:43] <sits> Amaranth: and do you see a while and yellow bar?
[08:43] <lamont> whatever plays the sound when I log in... I want that to be silent.
[08:44] <seb128> lamont: there is "blong" when the login screen is displayed
[08:44] <sits> Amaranth: with also effects: beneath it?
[08:44] <Amaranth> yes
[08:44] <seb128> and the ubuntu sound on login
[08:44] <lamont> ah, right.  both
[08:44] <sits> Amaranth: click Project...
[08:44] <seb128> lamont: for the login sound, select "no sound" for login sound
[08:44] <Amaranth> i get a textbox to input a project that is registered on launchpad
[08:44] <bryce> enter xorg-server
[08:45] <Amaranth> This is the _worst_ UI ever
[08:45] <sits> Amaranth: my bad
[08:45] <sits> Amaranth: back one page
[08:45] <Amaranth> sits: i'm good now
[08:45] <seb128> lamont: for gdm, system, admininistration, login screen, accessibility, uncheck the login screen ready
[08:45] <sits> Amaranth: click on          Distribution/Package
[08:45] <sits> Amaranth: fair enough
[08:45] <Amaranth> sits: no, that isn't the right place either :)
[08:45] <cjwatson> sits: no, don't use distribution/package for this
[08:45] <lamont> seb128: thanks
[08:45] <Amaranth> sits: bryce gave me the fix
[08:45] <sits> I think it's because that bug doesn't have a xorg task
[08:45] <seb128> lamont: you're welcome
[08:45] <sits> oh fair enough
[08:45] <Amaranth> oh, yeah
[08:46] <bddebian> seb128: Are you a buildd admin also?
[08:46] <seb128> bddebian: no, pitti, doko, Mithrandir are
[08:46] <bddebian> Fruck, OK, thanks
[08:46] <bryce> Amarath, yeah it's a pretty confusing UI
[08:47] <cjwatson> bddebian: https://launchpad.net/~launchpad-buildd-admins
[08:47] <cjwatson> bookmark that if you're making requests of buildd admins often
[08:47] <Amaranth> should just give me a project textbox and a bug tracker url box and let me pick
[08:47] <Amaranth> maybe i'll file a bug report :)
[08:47] <bddebian> cjwatson: Will do thank you sir
[08:48] <bddebian> Of course poor Mithrandir seems to be the one around the most lately :-)
[09:02] <Mithrandir> bddebian: give-backs aren't much work, though
[09:02] <bddebian> Mithrandir: OK, well if you get a free sec can you please give back taxbird?
[09:03] <Mithrandir> bddebian: given it's depwait, there's no need, it'll be retried once all the dependencies are in.
[09:05] <bddebian> Is it still dep-wait on libgeier?
[09:06] <bddebian> Do we have visibility of that stuff still?
[09:07] <Mithrandir> https://launchpad.net/ubuntu/+source/taxbird/0.10-1 tells you it's dep-wait
[09:08] <Mithrandir> https://launchpad.net/ubuntu/+source/taxbird/0.10-1/+build/363586 tells you glade-gnome is what it's depwait on
[09:12] <bddebian> Oh, but i386 built?
[09:18] <Riddell> Mithrandir: could you give back kde4pim on amd64 please
[09:22] <ogra> seb128, i'd like to upload http://paste.ubuntu-nl.org/36727/ to fix the issue with sabayon blocking users if no profile is around ...
[09:22] <ogra> any objections ?
[09:22] <seb128> ogra: is the blank line change required?
[09:23] <seb128> ogra: no, do you plan to send the bug on bugzilla.gnome.org?
[09:24] <ogra> sure, we can do that
[09:24] <ogra> indeed the blank change isnt required :)
[09:24] <seb128> ogra: feel free to upload; bonus point if you forward upstream ;)
[09:24] <ogra> heh
[09:25] <ogra> just didnt want to do it blindly :)
[09:25] <ogra> thanks for your time
[09:25] <seb128> ogra: stop
[09:25] <seb128> ogra: use a patch
[09:25] <sbalneav> Hammertime
[09:25] <seb128> rather than changing the source directly
[09:25] <ogra> oh, crap, right
[09:25] <seb128> ogra: thanks ;)
[09:26] <rgl> how can I update do tribe6?   just the usual apt-get dist-upgrade?
[09:26] <ogra> sbalneav, do you want to do that, or should i ?
[09:26] <seb128> ogra: the patch uses simple-patchsys so you can simply copy the change
[09:26] <ogra> (needs cdbs-edit-patch, like you did for denemo)
[09:27] <ScottK> seb128: I noticed that you're a bug contact for nautilus-sendto.  Do you care to review the change in Bug #138010 or just leave it for ubuntu-main-sponsors?
[09:27] <ubotu> Launchpad bug 138010 in nautilus-sendto "Nautilus-sendto suggests obsolete slypheed-claws package" [Low,Triaged]  https://launchpad.net/bugs/138010
[09:27] <rgl> Kmos, there?
[09:27] <ogra> right
[09:28] <seb128> ScottK: feel free to upload
[09:28] <sbalneav> ogra: Since you're going to fw upstream, through lp magic, I'd expect, it ok if you do it? Or are you bushed?
[09:28] <ScottK> seb128: Thanks.  I'll hunt around for a core-dev to do it then.
[09:28] <ogra> sbalneav, i meant redo the patch, but i'm fine :)
[09:28] <seb128> ScottK: ? the package is to universe
[09:29] <seb128> ScottK: ups, I'm tried
[09:29] <ScottK> seb128: nautilus-sendto is in Main.
[09:29] <seb128> tired
[09:29] <sbalneav> What do we need to redo on the patch?
[09:29] <seb128> right, I was think to claws-mail
[09:29] <seb128> ScottK: I'll upload it for you
[09:29] <ScottK> Great.  Thanks.
[09:29] <seb128> no problem
[09:30] <Mithrandir> Riddell: the feisty one that I've given back before and which failed then too?
[09:30] <ogra> sbalneav, instead f being directly in the source, the change should be a separate patch, like the denemo patch you mde before ... since sybaon uses simple-patchsys i can just tweak the file you sent me and make it a patch
[09:30] <ogra> i'm sure i pressed them
[09:30] <Riddell> Mithrandir: yes
[09:31] <Riddell> Mithrandir: it worked for i386 but amd64 still didn't have all the build-deps
[09:31] <Mithrandir> Riddell: ok, given-back
[09:31] <Amaranth> ogra: did your 'a' go on strike?
[09:31] <ogra> aaaaaaaaaaaaaaaaaaa
[09:31] <ogra> doesnt seem like
[09:31] <sbalneav> ogra: If you can do it, go ahead.
[09:32] <sbalneav> I'm testing some boot stuff in ltsp atm
[09:32] <ogra> Amaranth, i used xgl for a while, that has this weird keyboard repetition bug here ... probably my system is exhaused wrt vowels now ...
[09:34] <Amaranth> ogra: hehe, RAOF is still doing some tweaking with Xgl
[09:35] <ogra> i gave up on it
[09:35] <ogra> it eats to muc power for the benefit
[09:35] <ogra> *much
[09:35] <sits> ogra: really?
[09:36] <sits> even more than AIGLX?
[09:36] <Amaranth> I haven't noticed
[09:36] <Amaranth> I would think using the CPU less would help
[09:36] <Amaranth> oh, i know why
[09:36] <Amaranth> it's because with the open source drivers if you aren't using 3d they don't do $REFRESH_RATE interrupts a second
[09:36] <Amaranth> if you use Xgl it always does
[09:37] <ogra> right
[09:37] <sits> Amaranth: wouldn't that affect AIGLX too?
[09:37] <ogra> my fan gets quite busy over time since my machine is maxed out anyway with tons of other tasks
[09:37] <iXce``> yeah, nVidia always refresh all the time anyway ><
[09:37] <sits> (I only ask because I've measured AIGLX usage)
[09:37] <Amaranth> sits: AIGLX only comes into play if you use GLX :)
[09:37] <sits> Amaranth: well if you are using compiz
[09:38] <Amaranth> iXce``: yeah, it's annoying like that
[09:38] <sits> in theory you will be syncing to frame so the interrupts will go up
[09:38] <iXce``> definitely
[09:38] <iXce``> I wish they'd follow AMD soon and help nouveau :/
[09:38] <sits> (In fact once they rise after AIGLX is used on the Intel I have here the interrupts never fall)
[09:38] <Amaranth> sits: If you aren't using GLX how could it do anything?
[09:39] <sits> Amaranth: because often when you enabled compiz you wind up doing the compositing using GL
[09:39] <Amaranth> iXce``: if i switch to the nv driver and disable my wifi i only get something like 13 wakeups a second when idle in X
[09:39] <Amaranth> iXce``: with nvidia and wifi on it's 130, so sad
[09:39] <iXce``> haha
[09:40] <iXce``> I wonder what's the best hardware for that. Intel?
[09:40] <sits> Amaranth: that sounds like a quirk of the NVIDIA drivers (presumably they try and go as fast as possible)
[09:40] <Amaranth> iXce``: yeah
[09:40] <sits> Amaranth: I have an Intel and while disabling interrupts by taking out DRI does drop interrupts the savings in power are comparatively low
[09:40] <Amaranth> sits: no, they just always generate an interrupt on vblank while the open source drivers only do that when a 3d app is running (when it's actually needed)
[09:41] <Amaranth> sits: sure, but it still makes a difference
[09:41] <iXce``> (they'd just need to fix that xgl problem :o)
[09:41] <sits> Amaranth: not if you are using AIGLX
[09:41] <Amaranth> sits: one thing doesn't do much but a bunch of little things add up
[09:41] <sits> (i.e. using compiz without XGL)
[09:41] <Amaranth> sits: AIGLX has become a buzzword :)
[09:41] <Riddell> lamont: you tested that git backport I presume (or is there a bug report?)
[09:41] <Amaranth> sits: what, exactly, are you referring to?
[09:42] <sits> Amaranth: sorry my mistake. The interrupts DO rise when you AIGLX
[09:42] <ScottK> Riddell: There is a bug report.
[09:42] <Amaranth> sits: When you use 3d, yes
[09:42] <sits> but it is exactly the same as if you were drawing anything 3D and syncing to frame
[09:42] <ScottK> Riddell: Bug #138032
[09:42] <ubotu> Launchpad bug 138032 in feisty-backports "Data loss problem with "git add -u"" [Wishlist,In progress]  https://launchpad.net/bugs/138032
[09:42] <sits> but what I am actually saying is
[09:42] <Amaranth> sits: AIGLX is a technique, not a thing
[09:42] <sits> the difference turned out to be 1W
[09:42] <lamont> Riddell: there's a bug report (138032), and i made sure it built...
[09:42] <sits> sorry that's wrong too
[09:42] <sits> 0.1W when I measured it
[09:42] <lamont> I'm actually in the process of updating my feisty machines to that version of git
[09:43] <Amaranth> sits: Yeah, I've always known it wasn't much :)
[09:43] <Amaranth> sits: I was guessing more like 1W though, nice to see it's so low
[09:43] <Riddell> ScottK, lamont: accepting
[09:43] <ScottK> Cool.
[09:43] <Amaranth> I guess I can close all the "disable compiz when running on battery" bugs now :)
[09:43] <ScottK> milli: ^^^
[09:44] <lamont> Riddell: and seems to work OK here.
[09:44] <Riddell> phew
[09:45] <sits> Amaranth: it's the difference (I've just double checked my records) of 20 wakesup -> 80 wakesups per second
[09:45] <Amaranth> sits: nice
[09:46] <sits> Amaranth: there is difference but unless you are getting down below 10 wakeups per second you are only going to save so much power by sleeping for a long time anyway
[09:46] <sits> my tests say that there are bigger savings which are far bigger and better to go for first
[09:46] <sits> e.g. disabling wifi and bluetooth saved 2.4W
[09:47] <Toxicity999> If anyone applicable to the bug hasn't seen, someone found the patch which created many xcrashes in gutsy https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/130325 last few comments, pretty good news. =]  Amaranth this is the one we talked about a while back and that huge forum thread of people QQing was on about.
[09:47] <lamont> Riddell: and in a minute or 6, I'll know if 1.5.2.5 fixes the bug I just ran into...
[09:47] <ubotu> Launchpad bug 130325 in xorg "[nvidia-glx-new]  3D GL apps crash X when using compiz (gutsy)" [Undecided,Confirmed] 
[09:47] <sits> another big win - dimming th escreen saved 2.1W
[09:47] <Amaranth> sits: bluetooth is blacklisted here :)
[09:47] <sits> Amaranth: (this is on a laptop with Intel hardware)
[09:47] <sits> Amaranth: ah but what about wifi?
[09:47] <Amaranth> sits: i wish the wireless wasn't so noisy
[09:47] <Amaranth> it used to be worse though
[09:48] <Amaranth> when powertop first came out with wifi vs without wifi was like 800 wakeups vs 200 wakeups
[09:48] <sits> Amaranth: you may find the bulk of the power was wifi in that combo
[09:48] <Amaranth> now it's the difference between 130 wakeups and 80 or so wakeups
[09:48] <sits> (but turning off bluetooth definitely saves power but probably not as much as dimming the screen)
[09:49] <Amaranth> Toxicity999: that's tricky because hildon needs it
[09:49] <Toxicity999> Oh really? I never skimmed the actual patch.
[09:50] <Amaranth> sits: unfortunately i opted for the 'ultra bright' screen so my lowest setting is brighter than most people's highest setting
[09:50] <Toxicity999> Probably a good 3rd party will distribute a package around for gutsy final, good or bad, that always happens.
[09:50] <sits> Amaranth: I think there are definite bands when it comes to wakeup power usage
[09:50] <Toxicity999> I won't compile xserver for my own uses until gutsy final is out, compiling your own copy of core thigns sort of defeats the purpose of a testing distro release.
[09:51] <Amaranth> sits: it's more what is causing the wakeups
[09:51] <sits> I think you are talking maybe 100s of wakeups reduced to save 0.1W . If you can dim your screen that would save you much more
[09:51] <Toxicity999> So it does fit in to the "We broke it but it's nvidias bug" category?
[09:51] <Amaranth> sits: if it's an interrupt then you're also keeping some other part of the hardware awake
[09:51] <sits> Amaranth: well the only reason you care about wakeups is because you want the CPU to sleep for longer
[09:51] <Amaranth> sits: not always
[09:51] <sits> and the longer it can sleep for the less power it can draw
[09:52] <sits> Amaranth: go on...
[09:52] <Amaranth> sits: for instance powertop offers helpers to disable bluetooth and etc but not because of the wakeups they cause for the CPU
[09:52] <Amaranth> the power usage of the bluetooth itself is the problem, the CPU waking up a little more is a small blip
[09:53] <mathiaz> BenC: I've just download the latest version of linux-ubuntu-modules (linux-ubuntu-modules-2.6.22-11-server_2.6.22-11.25_i386.deb) and the apparmor module is not included.
[09:53] <sits> Toxicity999: hmm. That's the bug I wanted someone to change the priority of
[09:53] <Amaranth> sits: to?
[09:53] <sits> Amaranth: hmm that's a very good point
[09:53] <Toxicity999> sits well I nominated this one, but the thing was a duplicate got accepted for tribe-6, when it was marked, it was taken off iirc.
[09:54] <Toxicity999> so it sort of stifled the process.
[09:54] <sits> Amaranth: I don't know what it should be changed to. That should be down to whoever maintains the package
[09:54] <ogra> cjwatson, is there any udeb that contains mkfifo ? apparently my udeb isnt happy atm with the installer environment
[09:54] <Toxicity999> but if this patch is there to make something else work... then it'd more complicated.
[09:54] <Toxicity999> *it'd
[09:54] <Toxicity999> erg IT'S
[09:55] <sits> Amaranth: I don't want it set to X. I'd just like to see it set. I asked twice but there wasn't a reply. It might be nice if it were assigned too so it wouldn't be forgotten but again that should be down to someone else
[09:55] <Amaranth> Toxicity999: it's also included upstream now so we're going to run into it again right away
[09:55] <Toxicity999> Ah
[09:55] <Toxicity999> Nasty.
[09:55] <Amaranth> not for gutsy but still
[09:55] <BenC> mathiaz: thanks, I'll do a quick upload to fix that
[09:55] <mathiaz> BenC: thanks.
[09:55] <sits> Amaranth: it's hard to know whether its "known" or not you see
[09:56] <Toxicity999> Well once people figure out what kind of damage the whole thing does, either A) a workaround will be found upstream/our end or B) 3 years from now nvidia is all over it.
[09:56] <sits> Amaranth: but it keeps attracting duplicates
[09:56] <Toxicity999> yea there are 6 marked dupes now
[09:56] <Toxicity999> probably tons more.
[09:56] <sits> Amaranth: I didn't know what else to do
[09:56] <sits> Toxicity999: oh? Where?
[09:56] <Toxicity999> the dupes? Should be listed in the original I linked.
[09:56] <Amaranth> i think there are like 4 dupes sitting in compiz waiting to be triaged
[09:57] <sits> Toxicity999: no the "more unduped bugs"?
[09:57] <Toxicity999> that was just a guess.
[09:57] <Amaranth> need to set aside a couple hours for that soon :)
[09:57] <Toxicity999> it's a dupe attracting beast.
[09:57] <Toxicity999> and they all point do different source packages
[09:57] <sits> Toxicity999: it's nothing compared to some other bugs I've seen
[09:57] <ogra> cjwatson, unping, i'll take mknod :)
[09:57] <Toxicity999> atleast we know what is the actual problem now.
[09:57] <Toxicity999> What exactly did the patch fix?
[09:58] <sits> Toxicity999: it's not mild but I hate to say it, it could be worse
[09:58] <Toxicity999> It could
[09:58] <Toxicity999> I mean I can always use my handy dandy mythprep to kill compiz and avant for running mythtv/games
[09:58] <Toxicity999> but it's a hinderence for simple ogl stuff.
[09:58] <Amaranth> Toxicity999: I know it makes hildon and desrt's new gnome-panel work right
[09:59] <Amaranth> Toxicity999: can't say i know the exact details of how it works, i try to stay a little more high level than XComposite hacking :)
[09:59] <Toxicity999> wouldn't it be easier to work around it in those areas than sort of set it up to wait on nvidia though?
[10:00] <Amaranth> no, not really
[10:00] <Toxicity999> Looks like the mailing list is buzzing as well. Reading up on the patch.
[10:01] <BenC> mathiaz: fix uploaded
[10:01] <Amaranth> Toxicity999: what mailing list?
[10:01] <Toxicity999> Haven't looked yet, just googling.
[10:01] <Toxicity999> Wait I just found mom entry where this patch was removed, was it later reintroduced? freaky.
[10:01] <Toxicity999> Way back in July
[10:02] <Amaranth> yeah, funny that
[10:02] <Toxicity999> Yea, removed the 13th, back the 25th.
[10:02] <Amaranth> it was disabled for breaking compiz, then supposedly the patch was updated to fix it so it was reapplied
[10:03] <Toxicity999> must of been some pretty light testing.
[10:03] <Amaranth> or it broke something else
[10:03] <Amaranth> i've been using Xgl since before then so i don't remember anything
[10:03] <sits> or it didn't break open source drivers
[10:04] <sits> (it doesn't appear broken on the Intel I have here for example)
[10:04] <Toxicity999> true
[10:04] <Toxicity999> it never specifically says anything in the notes about nvidia
[10:04] <sits> indeed
[10:04] <Amaranth> this is the double free from inside the nvidia driver, right?
[10:04] <sits> Amaranth: oh if that's the case I'm thinking of a different bug
[10:05] <sits> Amaranth: my bad
[10:05] <Amaranth> sits: nvidia+compiz+gl app == X crash
[10:06] <Amaranth> sits: but the backtrace goes from somewhere inside the nvidia driver to Xfree so i'm guessing it's freeing something twice
[10:06] <Toxicity999> Nasty bugger at that. As much as compiz is used in ubuntu now, people are in for a treat come upgrade day.
[10:06] <sits> Amaranth: going to be tricky to say
[10:06] <Toxicity999> It seems like we broke it, but it exposed a nvidia bug.
[10:07] <Amaranth> Toxicity999: distros with xserver 1.4 will see it too
[10:07] <sits> Amaranth: without the source... (not impossible but very difficult)
[10:07] <Toxicity999> yea
[10:07] <Amaranth> don't think any of them exists but still
[10:07] <Toxicity999> if it's upstream, it will suuuuurely be a hotbutton issue next major distro release party.
[10:07] <sits> Toxicity999: *shrug*
[10:07] <Amaranth> nah, i'm sure nvidia will have fixed it by april
[10:08] <Toxicity999> lol
[10:08] <Amaranth> looks like they just made a bad assumption
[10:08] <sits> Amaranth: if they know about it and they see it as a bug on their end
[10:08] <Amaranth> If they don't know about it they will in about 2 days
[10:08] <Toxicity999> in the mean time it's easy enough user end to compile xserver without the patch, and to distribute a no guarantees package.
[10:08] <Amaranth> (when gentoo users will finish compiling X ;)
[10:08] <Toxicity999> haha
[10:09] <Toxicity999> I'm just happy to finally see what caused it, I have no patience for a bisect.
[10:09] <Toxicity999> now I know how to get around it myself.
[10:09] <Toxicity999> here's hoping nvidia opens up a bit following AMD to avoid this crap >.>
[10:10] <sits> Amaranth: ;)
[10:10] <Amaranth> Toxicity999: they don't really need to, the nouveau guys seem to (in general) know how all the hardware works
[10:10] <Toxicity999> yea
[10:10] <Toxicity999> they did a killer job
[10:10] <sits> Amaranth: it's hard to say if its a double free
[10:10] <Toxicity999> development is racing on that.
[10:10] <Amaranth> they're just polishing the 2d bits while waiting for the ttm stuff to settle
[10:11] <sits> Amaranth: it could just  be wondering off into address space it doesn't own or setting the wrong bit of memory which leads something to deference a piece of memory X doesn't own etc.
[10:11] <Toxicity999> essentially it's going ot be a big debate, should we work around their bug, or leave it to make them fix it. Myself I'll just compile x in a few days-weeks =P
[10:11] <Amaranth> sits: sure but double free is more likely
[10:11] <Toxicity999> My guess too
[10:11] <sits> Amaranth: really? Why?
[10:11] <Toxicity999> it just feels most likely
[10:12] <Amaranth> sits: I dunno, it's the one I do all the time :)
[10:12] <sits> Amaranth: hmm that hasn't been my experience...
[10:12] <Toxicity999> if the patch has been reviewed to be good enough, multiple times, we're keeping up with the specs, it's just their thing.
[10:12] <sits> I'd say off by ones are more common
[10:12] <Amaranth> sits: yay off by one in pointer math
[10:13] <sits> but I'd have to look up the stats on typical bug counts of C code
[10:13] <sits> I don't have my code complete book to hand unfortunately
[10:13] <Amaranth> i suck at memory management, that's why i try to stick to ref counted stuff in C and use a lot of python :)
[10:21] <sbalneav> Mithrandir: You about for some quick UVFe love?
[10:25] <Amaranth> Toxicity999, sits: Seems obvious now. aaronp says that patch changes the ABI so our only options are live with the bug or pull the patch
[10:27] <sits> Amaranth: that makes sense
[10:27] <sits> Amaranth: how did you get hold of aaronp btw?
[10:28] <sits> Amaranth: (I was thinking it might have been an ABI change)
[10:29] <sits> Amaranth: you may want to write that in the bug report...
[10:30] <Amaranth> sits: IRC :)
[10:30] <Amaranth> new driver to match the new ABI coming out 'relatively soon'
[10:31] <Amaranth> but i think that'd require outright using the xserver 1.4 instead of cherry picking things from it
[10:31] <bryce> yup
[10:31] <sits> Amaranth: that makes sense
[10:31] <Amaranth> that explains why the open source drivers don't break
[10:31] <sits> how else would it know which ABI was being targetted?
[10:31] <Amaranth> they got a recompile :)
[10:32] <bryce> UME would be affected if the patch were removed, but I don't think anyone else needs it
[10:33] <Amaranth> bryce: I think our desktop is more important ;)
[10:33] <sits> Amaranth: ah it's you! Now it makes sense. You're the person who always knows what the problem with these bugs is before I even start looking at the bug!
[10:33] <Amaranth> sits: eh?
[10:34] <sits> Amaranth: Travis right?
[10:34] <Amaranth> sits: oh, you did a /whois? :)
[10:34] <Amaranth> yeah
[10:34] <sits> Amaranth: yes I just did because I've been trying to piece it all together...
[10:34] <Amaranth> sits: If I didn't want you to /whois me I wouldn't put my name in there :)
[10:35] <sits> Amaranth: true true. It was very helpful
[10:35] <sits> now I can put a nick to launchpad name
[10:37] <Amaranth> sits: but i can't :)
[10:37] <sits> Amaranth: I still think it would be helpful if a decision could be taken on that bug though. It's only going to rise in popularity...
[10:37] <sits> Amaranth: sure but unlike me you KNOW people :)
[10:37] <Amaranth> sits: that's up to bryce
[10:37] <Amaranth> Well it's probably up to the TB, really
[10:38] <Amaranth> Break the desktop, break ume, or figure out some way to selectively apply the patch
[10:38] <sits> it could be simply turning off compiz by default (so less people stumble into it)..
[10:38] <Amaranth> sits: shh
[10:38] <sits> I don't really have any good answers unfortunately (as could be seen from my cjwatson conversation earlier - I take the wrong direction)
[10:38] <Amaranth> sits: nvidia is about the only place where this stuff actually completely works like it should
[10:39] <bryce> I thought it worked ok with Intel gfx?
[10:39] <sits> Amaranth: but even you were saying the 100 series driver introduced new problems
[10:39] <sits> bryce: it does
[10:39] <Amaranth> sits: Now I dunno
[10:39] <bryce> if this particular bug only occurs against -nvidia, why not just blacklist that driver for compiz for now?
[10:39] <sits> (assuming it is unrelated to the VT switching crashes I periodically see)
[10:39] <Amaranth> sits: my main complaints with the 100.14.11 were this bug and --indirect-rendering not working
[10:40] <Amaranth> bryce: that is probably going to be the last driver we can enable it on :P
[10:40] <Amaranth> bryce: and people are going to turn it on
[10:40] <sits> Amaranth: :)
[10:40] <Amaranth> bryce: it also breaks when you use xcompmgr, xfce compositing, etc
[10:41] <Amaranth> someone thinks "kde shadows are safe, they've always worked" and boom, 3d apps break
[10:41] <sits> Amaranth: s/3D apps/X
[10:41] <Amaranth> sits: X works fine if you don't use said 3d apps :)
[10:42] <sits> Amaranth: heh true
[10:42] <sits> Amaranth: well I'm just glad it's a known issue now
[10:43] <sits> I wanted to give it my best shot to get it to people's conciousness
[10:43] <sits> Amaranth: it's also good you've already talked to an NVIDIA employee about it
[10:44] <Amaranth> *shrug*
[10:44] <Amaranth> i also talked to him about the VT switch problems when compiz is running and those didn't that didn't get fixed until 8 months later :P
[10:44] <Amaranth> (in the 100.14.11 driver)
[10:45] <sits> Amaranth: if they know then if it pops up on their forum they will be aware of things ahead of schedule
[10:46] <sits> There are some things I wish they would change (they advocate a fairly extreme way of installing the .pkg which could get people into trouble)
[10:46] <Amaranth> yeah, if you go on the forums with the ubuntu package they shoo you away
[10:46] <Amaranth> then again they have good reason, we mess things up sometimes :)
[10:46] <sits> and it would be nice if they replied to NVIDIA issues in launchpad (after the reports have been narrowed down)
[10:47] <sits> Amaranth: sure but it's tricky. And I've seen their folks in the SUSE bugzilla
[10:47] <Amaranth> novell probably has some kind of deal with them :P
[10:47] <sits> Amaranth: case in point I noticed someone filed an upstream bug about a slowdown and it turned out they were using XGL
[10:48] <sits> Amaranth: who knows? SUSE doesn't seem that pro binary drivers (having said that they do seem to recommend fglrx for some servers)
[10:49] <sits> (but they don't ship any binary drivers with SLES10SP1)
[10:53] <aquo> I installed ubuntu-minimal with debootstrap and examined the installed packages with aptitude
[10:53] <aquo> libgcc1 has version 4.2.1
[10:53] <aquo> and libstdc++6 has version 4.2.1 too ...
[10:53] <aquo> if i would install gcc it would have version 4.1
[10:53] <aquo> gcc depends on gcc-4.1 ...
[10:54] <aquo> which is the official compiler for gutsy? 4.1 or 4.2?
[10:54] <sistpoty> aquo: apt-cache show gcc -> look at depends field. 4.1
[10:55] <sladen> apt-cache show build-essential | grep Depends
[10:59] <aquo> sistpoty: i know, but is it true?
[11:00] <sistpoty> aquo: I guess it would be a bad idea to change the compiler version so late in the cycle. IOW: yes
[11:01] <aquo> sistpoty: yeah, but why is libgcc 4.2.1 and the compiler 4.1?
[11:01] <aquo> shouldn't have the compiler the same version as the libgcc and libstdc++?
[11:03] <sistpoty> aquo: not too sure. maybe somewhere versioned depends need to be tightened. maybe there are other reasons as well, which I'm not aware of ;)
[12:05] <wasabi> Hmm. New video card no worky on Gutsy.
[12:07] <sistpoty> wasabi: right, the link is missing fwiw
[12:07] <sistpoty> (to libwfb)
[12:08] <wasabi> libwfb?
[12:09] <sistpoty> sorry, /me considered you were having troubles with a nvidia 8000er card
[12:09] <sistpoty> (as I do)
[12:09] <mathiaz> BenC: the apparmor kernel module needs a patch so that the audit messages sent to syslogd are correct.
[12:10] <mathiaz> BenC: I have the patch - how should I proceed ?
[12:10] <mathiaz> BenC: send it to you or file a bug in LP ?
[12:16] <Toxicity999> Hey again, sorry local net imploded. Service was out for a bit =[ Miss any discussion on the nvidia drama?
[12:17] <sistpoty> Toxicity999: I'm working on a fix, however 1) haven't tested it yet, and 2) will need a sponsor then
[12:18] <Toxicity999> Cool, assuming we're both talking about crash crash with compiz and using other ogl apps?
[12:18] <sistpoty> Toxicity999: no, rather about the 8000er series still not working
[12:18] <Toxicity999> ah
[12:19] <Toxicity999> I was going to say anyway, on this note the problem seems to be more we fixed something and the nvidia driver didn't like it =P caused by a specific patch.
[12:27] <cjwatson> aquo: the libgcc ABI is stable enough that it's fine for them to be different, and it makes it easier for us to ship the odd binary built with 4.2 (which may need the newer libgcc)
[12:34] <aquo> cjwatson: is it right that there are packages which depend on libstdc++6-4.2 in the system?
[12:36] <asisak> aquo: you can ask "apt-cache rdepends <package>".
[12:37] <aquo> asisak: i am not asking if it is true, i am asking if it is technically correct
[12:37] <Toxicity999> Whew just added a rather lengthy comment to the bug.
[12:37] <asisak> aquo: sorry then.
[12:38] <cjwatson> aquo: yes, that's OK
[12:38] <Toxicity999> I'm surprised the importance is still undecided, such a showstopper. but then there are tons of bugs to run through.
[12:39] <cjwatson> aquo: err, on second thoughts no it isn't, there's no such package
[12:39] <cjwatson> libstdc++6 is from gcc-4.2
[12:40] <cjwatson> there's libstdc++6-4.2-dev etc., and that's fine
[12:48] <aquo> cjwatson: ok, there are no packages that depend on libstdc++6-4.2, my error
[12:50] <aquo> cjwatson: i just wondered about the fact that libgcc1 is version 4.2.1 and libstdc++6 is version 4.2.1, but everthing else is 4.1 ...
[12:51] <aquo> should i install libstdc++6-4.2-dev or libstdc++6-4.1-dev?