[00:03] <johanbr> asac: Unfortunately I've been really busy and will be busy for the next few weeks, so I haven't had time to look at vpnc not working. Not sure if you have had time to take a look...
[00:03] <asac> johanbr: thats ok. i think there is a real issue. ill test myself as soon as possible
[00:59] <pwnguin> did anyone else get quasi mailbombed at their ubuntu.com address?
[01:21] <Adri2000> any archive admin could please move the amsn sru to -updates? (at least the hardy one)
[02:01] <pwnguin> so it wasn't me!
[02:06] <shaya> is intrepid suffering from whats in here?
[02:07] <shaya> http://pavelmachek.livejournal.com/60867.html?view=123331#t123331
[02:07] <shaya> 2.6.26.1 bug?
[02:07] <shaya> my T42p fan has been going crazy lately
[02:11] <Hobbsee> ask in #ubuntu+1, where the users of intrepid usually hide?
[02:11] <Hobbsee> (although some developers are running intrepid)
[02:46] <TheMuso> Is anybody else able to boot the latest ubuntu amd64 intrepid daily in kvm under hardy?
[02:50] <NCommander> TheMuso, I'm running the latest ubuntu amd64 intrepid on real metal if that helps
[02:51] <TheMuso> NCommander: No, it doesn't. I am also doing so on another box.
[02:56]  * NCommander plays with dak
[03:54] <moquist> if I have multiple binary packages building from a single source package, should the package name prefix in templates be the source package name, or the binary package name(s)?
[03:54] <RAOF> moquist: You mean foo.install, foo.preinst, etc?
[03:55] <moquist> i.e., src pkg moodle builds moodle-mysql and moodle-postgresql. should templates have only moodle/... entires, or moodle-mysql/..., moodle/..., and moodle-postgresql/... ?
[03:55] <RAOF> moquist: They should be binary package names.
[03:56] <RAOF> I'm not sure what you mean by "templates" in this setting.
[03:56] <moquist> RAOF: OK, so Template: <binpkg>/<question>
[03:56] <RAOF> This is debconf, right?  I've approximately no experience there :)
[03:56] <moquist> RAOF: http://rafb.net/p/wSgfUZ27.html
[03:57] <moquist> line 62 should maybe read: Template: moodle-mysql/dba_password
[03:57] <moquist> RAOF: yes, debconf
[03:59] <RAOF> I'm not sure, but my *guess* is that you'd actually need it to be in a different templates file; one for the moodle-mysql binary package, one for the moodle-postgresql binary package, etc.
[03:59] <RAOF> That's a guess based on the behaviour of other tools; I'm not familiar with debconf.
[04:01] <james_w> hey moquist
[04:01] <james_w> I think binary package name is correct
[04:01] <james_w> if there are any that apply to both then you can do shared entries
[04:02] <RAOF> So, I've got a question in return: how does one switch the CPU and IO schedulers at runtime?  I'd like to see if different schedulers have better than the abysmal interactive performance I'm currently seeing under IO load.
[04:02] <james_w> RAOF: there's a sysfs key
[04:02] <RAOF> james_w: I suspected as much.  Any details of the top of your head?
[04:03] <james_w> just searching now
[04:03] <james_w>  /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor looks pretty good
[04:03] <james_w> for the CPU at least
[04:03] <RAOF> That's going to be the CPUFreq governor, not the scheduler
[04:04] <RAOF> IE: when should I throttle the CPU back.
[04:04] <james_w> oh, yeah, sorry
[04:04] <james_w> find /sys -name "*sched*"
[04:05] <james_w> that lists a couple of things
[04:05] <james_w> perhaps block device schedulers can be changed, but not others
[04:07] <RAOF> Yeah, possibly.
[04:07] <moquist> james_w: hi! and thx
[04:07] <moquist> that was my guess, too
[04:08] <moquist> just one templates file, even though I have moodle.config and moodle-mysql.config, right?
[04:08] <moquist> (it builds, so I'm guessing that's right)
[04:10] <james_w> I'm not sure, I can't remember how it works
[04:10] <moquist> well, I'll test soon. :)
[04:11] <james_w> if you have moodle.templates then try installing -mysql, it will soon fail if you need two
[04:11] <james_w> I'm glad to see you're still fighting away at this
[04:12] <moquist> me too...I'm not sure of the timing here, but I still have hopes of getting this into debian in time for it to get pulled into intrepid
[04:13] <moquist> james_w: if you have a moment, I'd appreciate your thoughts on http://revu.ubuntuwire.com/details.py?package=vpnywhere
[04:13] <james_w> Debian is frozen which may be a hiccup
[04:13] <james_w> but there is still time
[04:13] <james_w> moquist: is this related?
[04:14] <moquist> james_w: only in that it's a package I made. we discussed this one a couple times at UDS. *shrug*
[04:14] <james_w> that's fine
[04:14] <james_w> I'll take a look tomorrow. It's late and I've been drinking, not helpful for review.
[04:14] <moquist> james_w: heh - cheers, then. :)
[04:18] <warren> Is chvt located at /usr/bin/chvt on Ubuntu?
[04:19] <james_w> warren: yep, apparently
[04:19] <warren> k
[04:23] <cathyal> is the indian language hindi possible on irssi?
[04:23] <cathyal> or say on x-chat
[04:24] <cathyal> any indians in the room
[04:25] <cathyal> anyone good with translations
[04:25] <ScottK> cathyal: This is an English channel.  You might try #ubuntu-in
[04:26] <cathyal> thanks
[04:30] <bryce> heya james_w
[04:30] <james_w> hey bryce
[04:31] <james_w> bryce: did you see Federico's patches?
[04:31] <bryce> james_w, couple bzr questions for you if you have a moment?
[04:31] <james_w> sure
[04:31] <bryce> could you come to #inkscape?
[04:32] <bryce> actually nevermind, I'll ask here and just copy answers...
[04:32] <james_w> I can do that
[04:32] <bryce> last time we looked at switching to bzr for Inkscape, the two issues that stopped us were a) Windows UI, and b) EOL handling
[04:33] <bryce> james_w: do you know if the status on either of these has changed drastically in the last few months?
[04:34] <james_w> for a) Mark Hammond (big pywin32 dude) has been contracted to make TortoiseBzr rock, and work is starting to progress on that
[04:35] <james_w> there's also bzr-gtk and bzr-qt, which are improving a lot, especially the latter I believe, which is apparently more windows for some reason
[04:36] <james_w> for b) there is work ongoing, 1.6 out this week will kind of be able to do it, but you would probably want 1.7, out next month to have it work well
[04:46] <bryce> thanks for the answers james.  probably when those changes hit, Jon Cruz will take an interest
[04:47] <james_w> cool
[04:47] <james_w> bryce: do you have an opinion on Federico's patches?
[04:48] <bryce> I peeked at the screenshot and it looks like nice eye candy
[04:48] <bryce> we're not to FF yet, so I think we could definitely pull the patch in
[04:49] <bryce> it's up to seb128 though.  he might prefer waiting until the patch is upstream
[04:50] <james_w> yeah, it's up to seb128
[04:50] <james_w> I was going to reply to ask about theming
[04:51] <james_w> I don't know how it picks the colours, but the one in the screen shot wouldn't sit well in Ubuntu
[04:52] <bryce> I'd gotten a suggestion from mirco on how to pick colors from the current theme
[04:52] <bryce> I can find it and forward it if you're interested
[04:53] <james_w> that would be good
[04:54] <james_w> it's something we want anyway, but may help with this
[05:35] <dholbach> good morning
[05:59] <pitti> Good morning
[06:01] <StevenK> Morning pitti
[06:01] <dholbach> hi pitti
[06:05] <pitti> dholbach: btw, no sponsor bugs for me in the next two weeks, please (I'll be on holiday the next two weeks, and wrestle with alpha-4 this week)
[06:06] <nxvl> nooooooooo
[06:06] <nxvl> what are we going to do without pitti for 2 weeks!
[06:06] <nxvl>  /o\
[06:06] <nxvl> :D
[06:07] <dholbach> pitti: OK
[06:07]  * dholbach hugs super-pitti
[06:07]  * nxvl HUGS pitti too
[06:08] <dholbach> pitti: what do we do in cases where we sync a new package from debian and it ftbfs, but we have a patch for the ftbfs already?
[06:08] <dholbach> sync, then upload the fix?
[06:08] <dholbach> get the fix to debian, then sync?
[06:08] <StevenK> Does it FTBFS in Debian too?
[06:09] <dholbach> bug 256821
[06:09] <dholbach> seems it doesn't
[06:09] <StevenK> What's the patch?
[06:09] <dholbach> it's in the bug
[06:10] <StevenK> Ah, I know why that is
[06:10] <pitti> dholbach: Keybuk told me that it is cleaner to sync and then apply the patch
[06:11] <StevenK> dholbach: I suspect that is libc6 2.8 fall out
[06:11] <dholbach> pitti: OK, I'll ack then sync then
[06:11] <nxvl> dholbach: that's an ubuntu only issue due the compiler flags IIRC
[06:11] <pitti> dholbach: that is, for MoM, otherwise it doesn't matter at all
[06:11]  * pitti hugs back nxvl and dholbach
[06:11] <StevenK> I suspect Debian will hit the same issue when they hit libc6 2.8
[06:12] <pitti> I forwarded a couple of "glibc 2.8 ftbfs" patches to Debian, they were all gladly accepted
[06:12] <nxvl> dholbach: https://wiki.ubuntu.com/CompilerFlags
[06:12] <nxvl> dholbach: under -D_FORTIFY_SOURCE=2
[06:13] <StevenK> nxvl: Given the error, I doubt it's because of compiler flags
[06:13] <nxvl> StevenK: that error is listed on that wiki
[06:13] <nxvl> but i haven't check it closer
[06:13] <nxvl> pitti: can you please confirm me about the versioning of this package, i find it odd
[06:13] <nxvl> pitti: http://revu.ubuntuwire.com/details.py?package=mythstream-parser-google
[06:14] <StevenK> nxvl: So, fix the error. libc likes it when you call functions correctly.
[06:15] <nxvl> i have patched it before
[06:15]  * nxvl looks
[06:15] <pitti> nxvl: indeed it is
[06:16] <pitti> nxvl: two ubuntus in the version number sounds wrong; the uploaded should make up his mind whether it's a native or upstream project
[06:16] <nxvl> pitti: thank you, can i quote you on revu?
[06:16] <pitti> sure
[06:16] <nxvl> :D
[06:19] <nxvl> StevenK: taking a closer look to the patch in that bug report is exactly what it says on the wiki
[06:19] <nxvl> dholbach: i hardly thing it is an ubuntu only bug
[06:20] <dholbach> nxvl: I asked Neil to forward the patch
[06:20] <nxvl> s/hardly/really/
[06:21] <nxvl> dholbach: i would test it in debian before sending it, or ask the DM to include it for downstream compatibilty
[06:22] <nxvl> because they won't find it as a bug
[06:22] <nxvl> found it
[06:22] <dholbach> nxvl: <StevenK> I suspect Debian will hit the same issue when they hit libc6 2.8
[06:23] <nxvl> mysql-gui-tools_5.0 has the same problem
[06:23] <nxvl> and fixed
[06:23] <nxvl> dholbach: yeah, maybe it is a libc issue
[06:23]  * nxvl checks in experimental
[06:23] <kirkland> pitti: how are the alpha4 cd's coming along?
[06:24] <pitti> kirkland: nobody tested the new desktop CDs in the last 7 hours, doing that now; but I hope they'll work now
[06:24] <pitti> kirkland: by and large they should be okay now
[06:25] <kirkland> pitti: cool, i'll do some server testing in the morning
[06:25] <pitti> kirkland: servers look pretty good, 9/10 tests done
[06:25] <kirkland> pitti: oh, zul must have kicked some butt then :-)
[06:25] <kirkland> pitti: when does the archive re-open?  when can i get a fix for mdadm sponsored?
[06:25] <pitti> see http://iso.qa.ubuntu.com/qatracker/build/all
[06:26] <kirkland> yup
[06:26] <pitti> we urgently need kubuntu testing, and ubuntu desktop
[06:31] <kirkland> pitti: okay, i'll see what I can do tomorrow ;-)  i'm calling it a night
[06:33] <nxvl> StevenK: it builded without problems on sid (libc6 2.7-13) and in experimental (libc6 2.8+20080809-1) so it may be a compiler flag issue
[06:34] <nxvl> just tested
[06:37] <nxvl> pitti: that reminds me, how are the complierflags, libtool, libc changes managed? thay take place only at the start of the development cycle or at any time?
[06:43] <superm1> pitti, i know i was seeing some gvfsd trash related crash after install on the desktop disks
[06:43] <superm1> i wasn't at a location that i could submit a crash report when i was seeing it though
[06:54] <pitti> superm1: yep, plenty of reports about that one
[06:55] <pitti> nxvl: pretty much at the start usually
[06:55] <superm1> pitti, ah okay then i wont worry about reproducing it again
[06:55] <pitti> nxvl: since they are very prone to break a lot
[06:55] <pitti> superm1: right
[06:55] <nxvl> pitti: yes, that why i was thinking about it, since if they change we will need to rebuild a big part of the archive to check for breakages
[06:58] <pitti> nxvl: that is, in Ubuntu we generally limit it to the start of a cycle; in Debian, changes happen during cyles, too, since they are much longer
[06:58] <nxvl> :D
[06:58] <nxvl> pitti: thank you for clarification
[06:59] <pitti> superm1: ubuntu desktop CD, ubiquity works fine now; thanks again
[06:59] <superm1> pitti, no problem.  glad it was easy to identify :)
[07:43]  * mneptok douses pitti in chocolate and kerosene
[07:44] <StevenK> Chocolate *and* kerosene?
[07:45] <StevenK> I've heard about dark chocolate, but that's a little much. :-P
[07:45] <lifeless> only after you burn it
[08:43] <pitti> mneptok: owch
[08:50] <mneptok> pitti: it's just that i think of you as hot and sweet. or something like that. :P
[08:52] <Treenaks> mneptok: are you part of the Pitti Fanboy team on launchpad yet then? :)
[08:53] <torkel> mneptok: Crème pitti? :-)
[08:53] <mneptok> Treenaks: i refuse to join any club that would have me as a member. i have some prinicples.
[08:53] <Treenaks> mneptok: maybe you'll be rejected, I'm not the team admin
[09:00] <pitti> re
[09:00]  * pitti drops a metric ton of gummybears onto mneptok
[09:02]  * mneptok gleefully frees himself
[09:02] <mneptok> NOM NOM NOM
[09:14] <liw> "NOM NOM NOM"?
[09:15] <Treenaks> liw: http://www.urbandictionary.com/define.php?term=nom
[09:16] <liw> thanks
[09:16]  * lukehasnoname is away: sleep
[09:17] <ion_> lukehasnoname: Thanks a lot for the information! We were just wondering about that.
[09:18] <ion_> liw: The equivalent of "nam" in Finnish. :-)
[09:18] <ion_> Hm, perhaps not exactly.
[09:28] <seb128> pitti: arg, it did it again, bug #257803
[09:28] <seb128> pitti: the retracer removed everything including the debug stacktrace
[09:35] <mdz> pitti: bug 195749 doesn't include a DistroRelease field...is that because we need to add it to the kernel hook?
[10:14] <pitti> seb128: hm, if it does that often, maybe stop it for now?
[10:15] <pitti> mdz: that was reported with the aaaaancient kernel hook (which we never really used in our kernel pacakge)
[10:16] <pitti> indeed that one didn't add OS info, like DistroRelease
[10:22] <mdz> pitti: ah, ok
[10:22] <mdz> pitti: that was the first apport-kernel bug I have seen, didn't notice how old it was
[10:27] <seb128> pitti: it just does when retracing again a bug
[10:27] <seb128> pitti: I did retag this one because the retracer didn't have the new gedit version yet
[10:30] <tseliot> pitti: I managed to write something which should work with the way you implemented the progress bar in Jockey. I had to subclass apt.Cache. Now I have only a question on progress_cb(phase, current, total): phase is either 'download' or 'install' but what are "current" and "total"? Is current the current percentage of work and total 100% or do you have something different in mind?
[10:31] <pitti> tseliot: the only requirement is that current eventually reaches total
[10:31] <pitti> tseliot: could be number of pacakges, or percent, or whatever you need
[10:31] <pitti> total == 1.0, and current = 0.37, or total = 1000 and current = 372
[10:31] <pitti> or total == 5 (packages) and current == 2 (second package)
[10:32] <tseliot> pitti: great, I'll use the percentage
[10:33] <tseliot> pitti: oh, another thing, is it ok if I make the apt part run on a different thread?
[10:33] <pitti> tseliot: sure, if that helps
[10:34] <tseliot> pitti: yes, that's what I used in my implementation
[10:37] <pitti> seb128: it's done in apport/crashdb_impl/launchpad.py, close_duplicate(); nowhere else; so I think the duplicate detection is on crack and tries to mark the bug as a dup of itself
[10:37] <seb128> pitti: maybe it needs a "if dup_number == bug_number" case?
[10:37] <pitti> seb128: I think a simple "if id == master: return" at the top of that function should be a good enough patch for the retracers until I'm back from vacation; please report a bug agout it
[10:37] <pitti> seb128: 'zactly :-P
[10:37] <seb128> pitti: ok thanks
[10:38] <pitti> seb128: if you do that in the chroots, the next apport package update will overwrite it, but then we should have a better solution anyway
[10:38] <seb128> pitti: ok, I'll do the change
[10:39] <seb128> thanks!
[10:39]  * seb128 hugs pitti
[10:40] <slytherin> Can anyone please tell me if anyone is working on packaging elisa 0.5.5?
[10:41] <pitti> lool: ^
[10:42] <lool> Hey; I'm not currently, but philn might have prepared something in pkg-gstreamer svn
[10:42] <lool> At least 0.5.4 is ready there
[10:42] <lool> And 0.5.5 should be easy to get
[10:42] <lool> slytherin: ^
[10:43] <seb128> lool: do you know if somebody from the mobile team will do the cheese 2.23 update?
[10:45] <lool> seb128: Gary said he was interested, but this was a while ago
[10:45] <lool> seb128: I'm basically the sponsor here; we had hildon bits to push in earlier cheese, but this now all upstream and merged and all
[10:46] <seb128> lool: right, I let the updates on the side because I don't use cheese and you guys do it usually but we had none of the 2.23 update
[10:46] <lool> I don't even have a webcam, so I'm quite a bad tester for cheese  ;)
[10:46] <seb128> right, me neither
[10:46] <seb128> anybody interested to update cheese?
[10:46] <lool> seb128: If you like, drop tremolux an email and ask him for a status update?
[10:46] <seb128> lool: ok, I'll do that, thanks
[10:47] <lool> seb128: I'm happy to do the reviewing and sponsoring of his work or of somebody's else; it just doesn't make sense for me to do it as I don't have a webcam to test!
[10:47] <seb128> right
[10:52] <slytherin> seb128: I can test cheese on intrepid. I will see if I can update it to but that will be after Monday.
[10:52] <seb128> slytherin: ok, thanks
[10:53] <slytherin> lool: Thanks for elisa info. I hope I will find it in repositories before FF. :-)
[11:22] <ogra> seb128, !!!
[11:22] <ogra> Unable to retrieve message
[11:22] <ogra> Cannot create folder lock on /home/ogra/.evolution/mail/local/Inbox: Too many open files
[11:22] <ogra> my evo misbehaves
[11:22] <seb128> hey ogra! nice to see you back, how are you?
[11:22] <ogra> fine, thanks :)
[11:23] <seb128> ogra: close and restart it?
[11:23] <seb128> it seems to leak file descriptors in some cases
[11:23] <ogra> i wasnt actually bad apart from the 15 mins .... they only kept me locked in for a week to do tests
[11:23] <ogra> lets see, closing now
[11:24] <ogra> ah, yeah, better now
[11:25] <seb128> cool, there is a bug about the issue already so no need to open one
[11:25] <ogra> seb128, beyond that it seems to have gotten slower over the last week ...
[11:25] <seb128> since the 2.23.6 update you mean?
[11:25] <ogra> after the initial upgrade from hardy to intrepid it took about 1-2sec switching folders
[11:25] <seb128> that's the first version using sqlite for summary storage
[11:25] <ogra> now that can take up to 5-10
[11:26] <seb128> there is still some optimization work needed
[11:26] <seb128> they are working on it a lot, wait for tarball next week to see if things are better
[11:26] <ogra> yeah, i just noticed it seems to have degraded since the first upgrade
[11:26] <seb128> the new code was not really optimized for some cases
[11:27] <seb128> I had evo freeze for some seconds when using my bugmails box for example, which was due to the hidden messages handling
[11:27] <ogra> (i'm not complaining, just giving feedback :) )
[11:27] <seb128> I hide everything which is read there, they fixed the bug in svn
[11:27] <seb128> but there is likely some other non optimized cases
[11:28] <seb128> they are working on it and really responsive to issue reported so file a bug if you still get the issue in the new version
[11:30] <ogra> yeah, i have no hidden msgs ... but lots of folders wih big amounts of mails
[11:32] <tseliot> pitti: I get this error now: http://pastebin.com/m4371b4c0 . If I run my program outside of Jockey it works well. Maybe is it because of what you do in dbus_sync_call_signal_wrapper() (in backend). I wouldn't know. Any ideas? It's all in my branch: ~albertomilone/jockey/ubuntu-core-xkit
[11:34] <ogra> seb128, right, i'll wait for the next tarball, lets see :)
[11:39] <pitti> tseliot: what do you try to do?
[11:40] <pitti> tseliot: do you call a function which takes very long to execute?
[11:40] <tseliot> pitti: I only clicked on a new driver, typed in the password for policykit and then that error shows up
[11:41] <tseliot> pitti: I use python-apt to install the package
[11:41] <pitti> tseliot: maybe d-bus is not thread-safe enough to do that, I don't know :(
[11:41] <tseliot> pitti: if you have a look at install_package in oslib you will see what I'm doing
[11:42] <pitti> tseliot: sorry, no time right now
[11:42] <tseliot> pitti: ok, no problem. I'll see if I can find something with Google about the error
[11:47] <seb128> tseliot: you are not subscribed to the nvidia-graphics-drivers-177 bugs?
[11:48] <seb128> tseliot: there is quite come crasher for nvidia users in intrepid for some days when using compiz, I've reassigned bugs there
[11:49] <tseliot> seb128: yes, I'm subscribed. I've been very busy though. What's the number of the bugreport?
[11:49] <seb128> tseliot: are you sure you are subscribed? you are not listed on bugs
[11:50] <tseliot> seb128:  I see it in my "bugs" folder in my mail client. I'm part of the X team
[11:50] <seb128> ah ok
[11:51] <seb128> tseliot: https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bugs, all the crashes in _nv*
[11:52] <tseliot> seb128: ok, let me have a look at those reports
[11:53] <seb128> tseliot: they don't seem really useful, I just wanted to let you know that quite some nvidia users seem to have compiz crashing in intrepid
[11:54] <tseliot> seb128: thanks for bringing this to my attention
[11:54] <seb128> you're welcome ;-)
[11:59] <tseliot> seb128: BTW do you have a look at my 3 lines patch here? http://bugzilla.gnome.org/show_bug.cgi?id=546969
[12:00] <seb128> tseliot: GNOME will roll new tarballs next week, I'll try to get the patch reviewed before that
[12:00] <tseliot> seb128: thanks a lot ;)
[12:00] <seb128> thank you for working on the bug ;-)
[12:14] <didrocks> hi all ;)
[12:15] <didrocks> pitti: when you will have the time, I'm interesting to know how NBS are calculated.
[12:15] <didrocks> Indeed, it seems to not look at package dependencies as some times, we have 3 dependecies for one source package. ldd on the binary seems to not put the same result...
[12:18] <MaximLevitsky> The desktop effects currently doesn't respect ccsm settings, will this be fixed/
[12:18] <MaximLevitsky> ?
[12:19] <MaximLevitsky> I meant if I select advanced/basic there the custom settings are cleared
[12:20] <MaximLevitsky> I would like to use this dialog to switch between compiz and metacity, but without alerting the settings
[12:32] <persia> didrocks: NBS is based on declared binary package dependencies.  This may not match the current source package (if successful builds have yet to publish (common in cases where the build fails)), and may not match ldd or similar tools depending on both the correctness of the analysis of those tools and the declared dependencies.
[12:34] <mneptok> persia: konban-wa
[12:35] <persia> こんばんは
[12:36] <mneptok> persia: the convincing argument. "you can lose weight just by blinking in the summer."
[12:37] <didrocks> persia: thanks a lot and that guide me through my second (big) technical questions: how ${shlibs:Depends} are calculated regarding build dependencie, it assumes runtime ones? :)
[12:38] <persia> didrocks: man dh_shlibdeps for an overview, and read /usr/bin/dh_shlibdeps for the details.
[12:38] <didrocks> ok, I will give it a look ;)
[12:39] <Adri2000> any archive admin could please move the amsn sru to -updates? (at least the hardy one)
[12:43] <sistpoty|work> didrocks: if you're looking for insight, https://wiki.ubuntu.com/MOTU/School/LibraryPackaging might be helpful (but it's quite a read)
[12:45] <didrocks> sistpoty|work: thanks for the link, I will add it to my reading schedule :)
[12:52] <MaximLevitsky> I have one quesion, is the 'NEEDED' section needed :-)
[12:52] <MaximLevitsky> without it linker won't find the symbols?
[12:53] <sistpoty|work> MaximLevitsky: well, you could do without, if the shared object defines all the symbols itself I guess, but I wouldn't know a use case for this right now
[12:54] <MaximLevitsky> sistpoty|work: I don't understand you (I once did a deep research on linking, but forgot most of it now)
[12:55] <MaximLevitsky> I mean if a library needs a symbol from external library, does it have to add that library as NEEDED ?
[12:55] <sistpoty|work> MaximLevitsky: yes
[12:55] <MaximLevitsky> sistpoty|work:  this is great
[12:56] <MaximLevitsky> sistpoty|work: I remember that I once tried to understand how to write a depends.exe equivalent for linux
[12:57]  * sistpoty|work wouldn't know what a depends.exe is in the first place *g*
[12:57] <MaximLevitsky> Long long time ago (about 8 years from now I used and programmed in windows_
[12:58] <MaximLevitsky> depends.exe shows you what libraries(dlls) are needed for this application, and for each dll, it shows list of symbols
[12:59] <MaximLevitsky> that app use, and list  of symbols that dll exports
[12:59] <sistpoty|work> so a mixture of ldd and objdump, right?
[12:59] <MaximLevitsky> http://www.dependencywalker.com/
[13:00] <MaximLevitsky> more or less, but it gets the information directly from .exe, and .dll
[13:00] <MaximLevitsky> linking is a bit different there
[13:00] <MaximLevitsky> each app has a list of dlls that it needs
[13:01] <MaximLevitsky> and for each dll there is a list of symbols it needs
[13:01] <MaximLevitsky> here in ELF there is just a list of all symbols
[13:02] <MaximLevitsky> so to know from where the symbol come, one needs to know what libraries the app needs
[13:02] <MaximLevitsky> I was thinking that ld.so just searches all libraries on the system for any symbol
[13:03] <MaximLevitsky> using cache to speed this up
[13:05] <sistpoty|work> erm, no. library resolution is done exactly with the NEEDED entries
[13:05] <MaximLevitsky> sistpoty|work: this is just great
[13:06] <MaximLevitsky> sistpoty|work:  although if I were to write such program, I will probably need to parse outputs of objdump and ldd, right?
[13:07] <MaximLevitsky> elf probably has platform specific differencies
[13:07] <sistpoty|work> MaximLevitsky: sorry, am not 100% sure about ELF internals, but I guess I'd use objdump (or readelf) as a base
[13:07] <MaximLevitsky> Btw ldd is just a frontend to ld.so
[13:08] <MaximLevitsky> just a script that exports some env variable, and then runs the program, and this makes ld.so output the depedencies, and exit
[13:09] <MaximLevitsky> this is what I remember from that old study
[13:11] <MaximLevitsky> sistpoty|work:  another interesting this is that global data variables in a library are reverse exported
[13:11] <MaximLevitsky> app exports the variable to the library
[13:13] <MaximLevitsky> sistpoty|work: thanks for information
[13:15] <MaximLevitsky> Btw, why all devel packages install .a libraries?
[13:15] <MaximLevitsky> who uses static linking those days?
[13:16] <MaximLevitsky> As I understand to write code against a library you need .h files and .so normal library, thats all
[13:46] <ogra> Keybuk, if i run telinit 6 (or shutdown -r -now) and get "Unable to send message: Connection refused", do you have a hint for me for what i should look to make that functional ?
[13:46] <ogra> (that shows up recently in my classmate installer out of the blue)
[13:47] <Keybuk> ogra: not running init?
[13:47] <ogra> right, i run a script that fires up the cmpcinstaller
[13:47] <ogra> but it used to work in the last builds
[13:47] <ogra> (about a week ago)
[13:47] <ulaas> anyone interested on  an initramfs issue with hardy? or #ubuntu is the way?
[13:47] <Keybuk> if you're not running Upstart, you obviously can't do things like change the runlevel?
[13:48] <ogra> was there any change in hardy-updates within the last week ?
[13:48] <ogra> i dont need to ... i used to just run "reboot -fp" which should just trgger the kernel
[13:48] <Keybuk> no, no change
[13:48] <Keybuk> if you do reboot -f, you are just telling the kernel
[13:48] <ogra> but thats getting stuck ... so i looked at shutdown ...
[13:49] <Keybuk> if it's getting stuck, that's a kernel bug
[13:49] <ogra> ah, k so it must be a kernel issue
[13:49] <Keybuk> telinit and shutdown won't work, and I would be surprised if _they_ worked last week ;)
[13:49]  * ogra waits for smb then 
[13:49] <ogra> who apparently built the new classmate kernel for colin last week
[13:49] <ogra> Keybuk, thanks that was the missing info :)
[13:50] <ogra> no, i never used or tried telinit or shutdown ... i just didnt understand why they exposed the msg
[13:50] <ogra> but its logical since i ont use upstart or normal init
[13:59] <pitti> jpds: yay, great to see buildd.py getting so many improvements :)
[13:59] <seb128> pitti: oh? where?
[13:59] <pitti> seb128: ubuntu-dev-tools 0.39ubuntu1
[14:00] <seb128> ah good
[14:00] <pitti> one thing less to maintain personally in my ~/bin :)
[14:01]  * pitti kills the one on people.u.c.
[14:03]  * pitti sobs at the obviously broken listadmin
[14:04] <lool> And I was looking at launchpad web pages to see buildd status, sigh
[14:04] <pitti> lool: buildd.py does that as well
[14:04] <lool> I think I'll hack buildd to unset https_proxy though
[14:04] <lool> pitti: Yeah, that's what I discovered!
[14:04] <pitti> I also have yet another wrapper giveback which calls buildd.py repeatedly with a set of packages
[14:04] <lool> pitti: That I was stupidly browsing web pages instead of typing a command line!
[14:04] <pitti> but that's trivial
[14:05] <pitti> lool: wiki.ubuntu.com/Specs/GettingRidOfTheDesktop
[14:05] <lool> pitti: EPAGE
[14:06] <Hobbsee> broken listadmin?  :(
[14:06] <pitti> just shows "nothing in queue" for all lists
[14:06] <Hobbsee> ah, yes.
[14:07] <pitti> which made me first think "wow, thanks elmo for installing a great spam filter"
[14:07] <Hobbsee> hahahaha
[14:07] <Hobbsee> yes, that's what i thought, too
[14:07] <pitti> but when I actually looked at the web page, they are full with requests
[14:09] <Keybuk> who's Chris Coulson?
[14:10] <james_w> Keybuk: he's a bug triager, quite active currently
[14:11] <Keybuk> does he IRC?
[14:12] <Hobbsee> Keybuk: as ChrisCoulson
[14:12] <Hobbsee> apparently
[14:16] <X-Seti> I may have a bug for you guys, this is ubuntu 8.04, and 8.10 with 1Gig of ram installed, Swap is being heavy used, alot of HD activity. ?
[14:17] <X-Seti> I know this isnt the support channel, but whats been changed since 7.10?
[14:17] <liw> "almost everything" is a good guess
[14:17] <ion_> You installed and started the memory-hungry piece of software.
[14:18] <X-Seti> is there a way to reduce HD load, running a server like this, im ganna go through some HDś
[14:19] <X-Seti> I know the beauty of ubuntu, but ive never seen it be so HD heavy
[14:19] <X-Seti> ok, im going to debug a tool i think might be the problem and postbin you the outs..
[14:19] <liw> X-Seti, use the top command (on the command line) or gnome-system-monitor or some other tool to see what is using the memory; before you know that, any changes you make are pure guesswork
[14:22] <ion_> Hit > once in top and it sorts by memory usage.
[14:25] <X-Seti> interesting.
[14:27] <liw> "RSS" is the relevant column, I think
[14:29] <X-Seti> trying to compare something, i have 2 machines with 8.10 and 8.04
[14:30] <X-Seti> i think the problem is network manager
[14:30] <ion_> How much resident memory has it allocated?
[14:35] <pitti> seb128: ugh; apt-get install from relatively small (retracer) chroots: 12.1 MB pidgin vs. 31.6 MB telepathy
[14:35] <pitti> (packed .debs)
[14:36] <seb128> pitti: be careful, pidgin is a GTK application where telepathy uses the GNOME stack
[14:36] <seb128> pitti: you should try to apt-install it on a livecd rather
[14:36] <pitti> right, it pulls in libcamel, e-d-s and a lot of stuff we already have
[14:36] <pitti> seb128: I guess in the end we just have to change the seeds, build a CD, and look what comes out of it
[14:37] <pitti> seb128: did you stop the amd64 retracer on purpose after the chroot upgrade?
[14:39] <ulaas> pitti: where should i go for my boot problem with hardy kernels..
[14:39] <ulaas> i use an md array for root
[14:41] <pitti> ulaas: which problem?
[14:42] <ulaas> pitti: upgraded from dapper to hardy with do-release-upgrade. now initramfs prompt comes at boot with new kernels. my old dapper kernel boots fine. I have my / on raid1 md
[14:43] <seb128> pitti: oh, no, I switched to the i386 one while it was doing the upgrade and forgot to reconnect to the screen and restart it
[14:45] <ulaas> pitti: any recommendations?
[14:45] <pitti> meeting
[14:49] <pitti> ulaas: I'd check the root parameter in grub, and which devices are present in the initramfs shell (/dev/...)
[14:49] <pitti> ulaas: I don't know how well you know linux, like "/dev/" -- at which level should we guide you?
[14:49] <pitti> seb128: restarted
[14:50] <pitti> ulaas: it could be that the newly built initramfs somehow missed the lvm and mdadm packages, or the root device changed
[14:50] <seb128> pitti: danke
[14:52] <ulaas> i have built the initrd  a few times manually as well. i have tried to comment out uuid entries in fstab and replace with /dev substitutes. i may be able to check if initramfs loads the correct modules but i think it does. you can guide me hardcore :)
[14:53] <ion_> tkamppeter: Hm, so there must be a change to /usr/share/ppd/openprinting/HP/hp_LaserJet_2300.ppd.gz in order to get the PDF filter path to work for my printer? Is that something that could be done automatically?
[14:53] <ulaas> i am just near the my server! and can try anytink you ask right away..
[14:54] <ulaas> pitti: as more info i ve tried -16 and -19 both generic and server
[14:56] <tkamppeter> ion_, for now all CUPS Raster drivers and all foomatic-rip-based drivers run through PDF, at least when the input datra
[14:56] <tkamppeter> data is PDF or an image.
[14:56] <pitti> ulaas: ah, UUIDs are good, please keep them
[14:56] <pitti> ulaas: are they present in /dev/disks/by-uuid/ in the initramfs prompt?
[14:57] <ulaas> pitti: i am rebooting now...
[14:57] <tkamppeter> Today I will upload an updated foomatic-db to make also all RICOH PPDs use the PDF workflow.
[14:58] <tkamppeter> ion_, native PostScript printer PPDs do not do a PDF workflow as they have no cupsFilter line. Try to force the PDF workflow by:
[14:59] <ion_> tkamppeter: Yeah, this is a postscript printer.
[15:00] <tkamppeter> 1. Add "application/vnd.cups-pdf application/vnd.cups-postscript 0 pdftops" to /etc/cups/mime.convs
[15:00] <ion_> tkamppeter: Could the cups package itself do that?
[15:00] <tkamppeter> 2. Remove the executable bit from "pstops"
[15:00] <tkamppeter> 3. Restart the CUPS daemon
[15:01] <ion_> tkamppeter: Because if it could, i could prepare a patch.
[15:01] <tkamppeter> Then report whther printing still works for you, especially whether you can supply options to the jobs and the options are correctly executed by the printer.
[15:01] <tkamppeter> Try also to priont from OOo with options.
[15:01] <ion_> Ok, i’ll do that.
[15:02] <tkamppeter> ion_, patches welcome
[15:05] <ulaas> pitti: booted into initramfs. i can see that the by-uuids are there. but may be different from the ones than fstab? should i make sure?
[15:06] <Keybuk>  15:06:28 up 136 days,  5:02,  1 user,  load average: 10.29, 4.75, 2.52
[15:06] <Keybuk> eep
[15:11] <pitti> ulaas: are you using only RAID, or LVM etc. as well?
[15:11] <pitti> ulaas: does it have a particular error message? cannot "find" or "mount" the root fs, etc.?
[15:13] <ulaas> only raid. and i get Alert! cannot find /dev/root error. there is no /dev/root  instead i have /dev/rootmirror/root and also swap
[15:13] <ulaas> oh wait i have /dev/root
[15:13] <pitti> ulaas: what is the root= parameter in grub?
[15:13] <ulaas> pitti : good question i have lilo
[15:14] <pitti> ulaas: lilo.conf has the parameters, too
[15:14] <ulaas> pitti: will boot into old kernel and let you know. but before what do you thşnk about the uuids. if they are different in fstab and by-uuid folder, does it effect?
[15:15] <pitti> ulaas: yes, definitively
[15:16] <pitti> they need to be identical to the letter in order to find the partition
[15:16] <ulaas> pitti: cool. will check that first
[15:16] <ogra> pitti, did my initramfs-tools and casper changes from yesterday make it on the CDs ?
[15:16] <ogra> (or was there some kind of freeze in place i missed)
[15:17] <pitti> ogra: the alternates are from Tuesday, so not there
[15:17] <pitti> the desktops got rebuilt due to the ubiquity bug, so it should be there
[15:17] <ogra> casper :)
[15:17] <pitti> check the .list/.manifest files :)
[15:17] <ogra> good
[15:17] <ogra> i need some testing of that stuff and promised colin to have it in alpha4
[15:18] <ogra> bah
[15:18] <ogra> casper 1.138 :(
[15:18] <ogra> one version to old
[15:18] <pitti> sorry, I wasn't aware that you needed to squeeze something on alpha4
[15:19] <ogra> i was late only pushed it in last night
[15:19] <ogra> the builds are from yesterday afternoon
[15:19] <ogra> well, thats hw it goes :/
[15:19] <ogra> *how
[15:20] <ogra> colin wanted ot have support for live on 256M back in place but i guess that then has to wait for alpha5
[15:20] <ogra> the code is at least there now
[15:21] <ulaas> pitti: uuids are ok. i have checked lilo.conf and root=/dev/mapper/rootmirror-root. worth a try for /dev/rootmirror/root ?
[15:21] <pitti> ulaas: hm, /dev/rootmirror/root doesn't sound standard at all
[15:21] <pitti> ulaas: ideally it should just be root=UUID=DEADBEEF
[15:22] <ogra> pitti, in case you run nto any showstopper and rebuild, please please ping me so i know the stuff went in
[15:22] <ulaas> pitti: if you are positive that lilo is ok with uuids i can punch it in..
[15:23] <pitti> ogra: don't think so, sorry; I'm about to release, all images are tested
[15:23] <ogra> oki
[15:23] <pitti> ulaas: lilo shouldn't care
[15:23] <pitti> ulaas: it's just a parameter passed to the kernel
[15:23] <pitti> ulaas: lilo only cares about your /boot/ partition
[15:23] <pitti> which you have to set in, erm, lilo is been a while...
[15:24] <pitti> ulaas: right, root = /dev/whateveryourrootpartitionis in lilo.conf
[15:24] <ulaas> pitti: i am always ok with grub if it suports md boot partitions. does it?
[15:25] <ulaas> ok i will try root=/dev/rootmirror/root
[15:25] <pitti> ulaas: sorry, that was BS, don't believe me
[15:25] <pitti> ulaas: the /boot partition is figured out by lilo automatically, taken from the image= parameter
[15:26] <pitti> ulaas: so boot=UUID=12345 should work
[15:26] <pitti> ulaas: I don't think grub can have /boot on RAID; ICBW, but don't rely on it
[15:26] <ulaas> pitti: deal! I ll let you know.
[15:26] <pitti> ulaas: argh
[15:26] <pitti> ulaas: not boot=UUID, but root=UUID, of course
[15:26] <pitti> ulaas: sorry, doing too much other stuff
[15:26] <ulaas> pitti: dont worry. i got it
[15:27] <pitti> ulaas: you should be able to change that on the lilo prompt, shuoldn't it? then you don't need to re-lilo all the time
[15:28] <ulaas> pitti: i believe it depends if you set that up.? what was that? "prompt" in lilo.conf?
[15:28] <pitti> yeah
[15:36] <tseliot> pitti: I did it!!! We have nice progress bar now in Jockey!
[15:36]  * pitti dances around
[15:37] <pitti> tseliot: yay!
[15:38] <tseliot> pitti: I have yet to try the KDE progress bar though. The mechanism works.
[15:38] <tseliot> pitti: gobject.threads_init() and glib.init_threads() are required for threading, that was the problem
[15:39] <pitti> tseliot: I wouldn't have known that either
[15:39] <tseliot> pitti: let's thank Google then ;)
[15:40] <ulaas> pitti: done! uuid is good. Should i file a bug? if yes for which component?
[15:40]  * tseliot tries jockey-kde
[15:41] <pitti> Keybuk: which package rewrote devices to UUIDs on upgrade again? udev?
[15:41] <pitti> ulaas: we might not have an automigration for lilo, I'm not sure; I think Keybuk needs to take over here
[15:41] <pitti> ulaas: but glad to hear that it worked
[15:43] <ulaas> pitti: hmm not yet! :) ı have appended from lilo prompt. when it is in lilo.conf it is a syntax error. can it be with quoets? ("")
[15:43] <ulaas> lets google
[15:44] <pitti> ulaas: according to man lilo.conf, you can use key = "value"
[15:45] <Keybuk> pitti: I think it's in udev or vol_id
[15:45] <ulaas> ı am a genius :) so as you are :)
[15:45] <ulaas> Keybuk: i think you watched the conversation.
[15:46] <ulaas> Keybuk: do you need somethink from me? this may be an important one. from LTS to LTS may be a common upgrade
[15:47] <Keybuk> ulaas: err?
[15:47] <Keybuk> assume that I did not watch a conversation
[15:47] <tseliot> pitti: the funny thing is that now Jockey installs the driver only if I start the backend with sudo...
[15:47] <pitti> tseliot: as opposed to getting it autolaunched from d-bus?
[15:47] <tseliot> pitti: however the progress bar works for kde too
[15:47] <tseliot> pitti: yes
[15:48] <BenC> Can someone please tell gnome-terminal to stop crashing when I try to select text with the mouse
[15:48] <pitti> tseliot: try changing the .service file to use --logfile=/tmp/jockey-backend.log
[15:48] <pitti> tseliot: last time it was due to d-bus not setting any $PATH
[15:48] <pitti> tseliot: or other environment variable
[15:48] <dholbach> BenC: I filed the bug yesterday - seems it's fixed in vte upstream already
[15:48] <pitti> tseliot: oh, and --debug, of course
[15:48] <ulaas> Keybuk: ok.! i have upgraded my dapper to hardy. which is on a raid1 MD array. then i goot initramfs prompt with hardy kernels when booting. old dapper kernel boots fine.
[15:49] <pitti> tseliot: then you get a nice log even from autospawned daemon
[15:49]  * pitti phews and is glad that alpha-4 is out
[15:49] <Keybuk> ulaas: no idea without extensive debugging, I'm afraid
[15:49] <BenC> dholbach: ah, thanks, saves me the time of filing a bug...any chance you have a deb of the fixed version?
[15:49] <ulaas> Keybuk: after a research with pitti he found out that root=UUID=dhjdhdh is better than what dapper had.
[15:49] <ulaas> Keybuk: in lilo.conf
[15:49] <pitti> Keybuk: do we do lilo.conf automigration to uuids?
[15:49] <Keybuk> no
[15:49] <pitti> Keybuk: or just in grub's menu.list?
[15:50] <pitti> ok, that explains it then
[15:50] <dholbach> BenC: no, I'm sorry - I leave that to mvo and seb128 :)
[15:50] <Keybuk> if we do, it'll be in lilo's postinst
[15:50] <Keybuk> we may skip raid, lvm, etc.
[15:50] <seb128> mvo: ^ can you do the vte update?
[15:51] <Keybuk> since we didn't deal with those in dapper
[15:51] <Keybuk> and we may have forgotten lilo since
[15:51] <ulaas> Keybuk: so people wıth MD roots may have the same problem right?
[15:51] <mvo> seb128: yes
[15:51] <seb128> thanks
[15:51] <mvo> dholbach: what is the bugnumber?
[15:51] <Keybuk> ulaas: only if they use lilo
[15:51] <dholbach> mvo: need to check
[15:51] <seb128> mvo: http://download.gnome.org/sources/vte/0.17/vte-0.17.2.tar.gz
[15:52] <ulaas> Keybuk:  i see! if you are not interested with details i gotta go.. do you?
[15:52] <pedro_> mvo: bug 256769
[15:52] <mvo> thanks pedro_
[15:52] <Keybuk> ulaas: not at the moment, sorry
[15:52] <Keybuk> others will be interested
[15:52] <ulaas> Keybuk: no problem i am a registered member at launchpad. Easy to find.
[15:53] <ulaas> pitti: thanks for the quaility time :)
[15:53] <seb128> dholbach: could you do the brasero update sponsoring? tomorrow is an holiday and I've still lot to do today, would be nice to have the new version uploaded though
[15:53] <tseliot> pitti: basically I get the policykit dialog, then the progress bar shows up for a few seconds without progressing and nothing happens. Here's the log: http://pastebin.com/m33310df0
[15:53] <dholbach> seb128: will do
[15:53] <seb128> dholbach: danke
[15:57] <pitti> tseliot: hm, seems you need to add some logging.debug() calls of your own
[15:58] <tseliot> pitti: ok, I'll do it and see what happens
[16:01] <seb128> dholbach: could be interesting to use http://svn.gnome.org/viewvc/brasero?view=revision&revision=1084 too in the update if you can, upstream asked to try the change, that can wait for next version too though
[16:02] <seb128> dholbach: don't bother, they roll tarball often enough
[16:03] <dholbach> seb128: ok
[16:10] <asac> pitti: congrats on getting alpha-4 out in time
[16:10] <pitti> asac: thanks
[16:10] <pitti> I almost forgot how painful that was :)
[16:10] <asac> pitti: so the the livecd fix from mario work?
[16:10] <pitti> asac: yes
[16:10] <seb128> does anybody else have refresh issues in emacs in intrepid?
[16:10]  * seb128 hugs pitti
[16:10] <asac> pitti: cool, rock on.
[16:11] <seb128> pitti: does that mean we can upload crack again? ;-)
[16:11] <pitti> seb128: go wild!
[16:11] <seb128> ;-)
[16:11] <pitti> seb128: vim is fine *duck*
[16:11] <asac> yay ... me looking at what NM snapshot might be wild enough ;)
[16:11] <seb128> pitti: I'm using gedit ;-)
[16:11] <seb128> asac: do you know about static config not working in nm0.7?
[16:11] <seb128> asac: the ok button stays inactive
[16:12] <tseliot> mvo: would it be possible to make apt.Cache.commit() look like this? def commit(self, fetchProgress=None, installProgress=None, optionalObject=None):
[16:12] <asac> seb128: it has rough edges
[16:12] <asac> seb128: which button?
[16:12] <asac> seb128: ah static IP
[16:12] <asac> (for a moment i thought you meant "system config"
[16:12] <asac> )
[16:12] <asac> seb128: wireless?
[16:12] <seb128> asac: right click on the nm icon, edit connection, choose a static interface, edit, ipv4 settings, set to manual, the button stay unactive
[16:13] <seb128> asac: no, wired eth
[16:13] <tseliot> mvo: never mind, ignore my request
[16:14] <asac> seb128: i think i saw that issue when i was still on that snapshot. but i am long gone on more recent snapshots. its fixed there. upload will probably happen today or tomorrow ( i am trying to flash out final issues in VPN)
[16:14] <asac> seb128: you could check that in ~network-manager PPA ... or just wait a few more hours
[16:14] <seb128> asac: ok, so need to open a bug
[16:14] <asac> seb128: i dont think so.
[16:15] <seb128> ok cool
[16:15] <asac> seb128: did you add DNS server as well?
[16:15] <seb128> I don't need the change, somebody just raised the issue on the chan yesterday
[16:15] <asac> ah ok
[16:15] <seb128> asac: I tried to file all the entries, ip, mask, gateway, dns, domain, etc
[16:16] <seb128> but the button stays unactive
[16:16] <asac> ok. then thats really the issue i vaguely remember
[16:16] <seb128> I'll try after the update
[16:16] <asac> thanks
[16:17] <dholbach> seb128: done
[16:17]  * seb128 hugs dholbach
[16:17] <seb128> thank you
[16:17] <dholbach> de rien
[16:17]  * dholbach hugs seb128 back
[16:30] <soren> Anyone still on hardy and wants to test a kvm fix for me? It's supposed to fix X in Intrepid guests. (not the mouse stuff, though. Just getting X rolling)
[16:30] <dholbach> soren: me me me me!
[16:30] <soren> dholbach: Awesome. Kernel version?
[16:30] <soren> -20, by any chance?
[16:31] <soren> amd64?
[16:31] <dholbach> -20 amd64, yes
[16:31] <soren> Whee.
[16:32] <soren> dholbach: I'll just compile them especially for you :)
[16:33] <dholbach> soren: give me the love!
[16:35] <soren> dholbach: http://people.ubuntu.com/~soren/kvm-test/
[16:36] <soren> dholbach: sudo bash -c 'rmmod kvm-intel ; rmmod kvm ; insmod ./kvm.ko ; insmod ./kvm-intel.ko'
[16:36] <soren> (or amd, obviously, if that's what you're on)
[16:36] <dholbach> just a minute
[16:36] <soren> Sure.
[16:37] <tseliot> pitti: problem solved. I had to set os.environ["PATH"] and os.environ["DEBIAN_FRONTEND"] in oslib. Now it works.
[16:37] <pitti> tseliot: hah, $PATH again
[16:37] <soren> dholbach: Wow, those modules are big...
[16:37] <soren> dholbach: Er... I'm sure there's some sort of reasonable explanation for that.
[16:38] <soren> Ah, they're not stripped.
[16:38] <pitti> tseliot: did you set DEBIAN_FRONTEND to noninteractive?
[16:38] <tseliot> pitti: yes
[16:38] <pitti> tseliot: interesting, which program does python-apt call? I thought it was pure python
[16:39] <tseliot> pitti: only mvo can answer to this ;)
[16:39] <pitti> tseliot: or strace -f -e execve :)
[16:40] <mvo> tseliot: hm? I missed the earlier part
[16:40] <mvo> aha
[16:41] <tseliot> mvo: jockey starts a dbus service which should call python apt when requested by the client
[16:41] <mvo> tseliot: that is a good question, I think that dpkg gets unhappy when it can not find certain apps, so if the path does not include e.g. /sbin it could fail I guess
[16:42] <pitti> aah, indeed, that was it
[16:42] <pitti> because in my first version I called /usr/sbin/apt-get, and that just failed with the same error (dpkg wanting $PATH)
[16:42] <pitti>         env = {
[16:42] <pitti>             'DEBIAN_FRONTEND': 'noninteractive',
[16:42] <pitti>             'PATH': '/sbin:/usr/sbin:/bin:/usr/bin'
[16:42] <tseliot> mvo: ok, this would make sense
[16:42] <pitti>         }
[16:42] <pitti> tseliot: ^ is what I have
[16:43] <pitti> tseliot: I believe that shuold work for python-apt as well
[16:43] <tseliot> pitti: no, it doesn't
[16:43] <pitti> oh?
[16:43] <pitti> tseliot: you need more in $PATH?
[16:43] <tseliot> pitti: this is why I had to use os.environ
[16:43] <pitti> tseliot: right, of course
[16:43] <pitti> tseliot: I meant the variables and their value
[16:43] <dholbach> soren: so the modules work and everything?
[16:43] <dholbach> soren: I'm not going to die or something?
[16:44] <tseliot> pitti: ah, ok then you're right
[16:44] <pitti> tseliot: I can pass it to subprocess.Popen()'s env argument, with p-apt you can't
[16:44] <soren> dholbach: No, they should be fine.
[16:45] <tseliot> pitti: yes, I noticed that. I didn't pay enough attention to this and I ended up assuming that the env dictionary would magically work
[16:45] <pitti> ah, no
[16:45] <tseliot> pitti: of course not, I didn't notice that it was a simple dictionary...
[16:46] <dholbach> soren: now I should be able to boot the intrepid kernel and X starts?
[16:46] <tseliot> pitti: I'll clean the files a bit and push this commit soon
[16:46] <soren> dholbach: That's the theory, yes.
[16:48] <tseliot> mpt: can you give an advise on Jockey's UI, please?
[16:48] <pitti> tseliot: is x-kit still in http://bazaar.launchpad.net/~albertomilone/xorgparser/main/
[16:48] <soren> dholbach: You mouse might still be acting up, but X should come up.
[16:49] <tseliot> pitti: yes, it's there
[16:49] <dholbach> soren: black screen, let me try without xorg.conf
[16:50] <soren> Ok, so there's more to it than I thought. The patch I applied there fixes it in Intrepid.
[16:50] <seb128> ArneGoetje: hi, do you plan to add the hunspell dictionnaries to the language support writting depends for languages where those are available?
[16:50] <soren> dholbach: I ran the command I sent?
[16:50] <dholbach> soren: yes, just re-ran everything to make sure the modules weren't loaded before I started, trying again
[16:51] <ArneGoetje> seb128: yes
[16:51] <seb128> ArneGoetje: ok good, thanks
[16:51] <dholbach> soren: no... no love here :-/
[16:51] <soren> dholbach: Ok. Thanks for testing.
[16:51] <pitti> tseliot: hm, if I run "PYTHONPATH=. tests/run", I just get failures with No such file or directory: '/home/martin/ubuntu/tmp/xorgparser/xorg.conf'
[16:51] <seb128> ArneGoetje: that's still missing for the spellchecking spec and feature freeze is soon
[16:51]  * dholbach hugs soren
[16:52] <pitti> tseliot: shouldn't this work on a temporary file which is created in setUp() or so?
[16:53] <tseliot> pitti: you can override the default settings. The default xorg.conf is the file included in the tests directory
[16:53] <tseliot> pitti: therefore you should enter that directory and run ./run from there
[16:54] <tseliot> pitti: or you can have a look at the README to see how "run" works
[16:58] <mvo> BenC: new vte uploaded to fix the crash when selecting text
[16:59] <tseliot> pitti: why do you call progress_cb with only 2 arguments when you remove packages and 3 when installing them?
[17:00] <BenC> mvo: thanks!
[17:03] <seb128> bigon: hi, bug #257189 is because the omf directory is not shipped in any deb
[17:03] <pitti> tseliot: aah, thanks
[17:03] <pitti> tseliot: because there is no 'phase' on uninstall
[17:04] <pitti> tseliot: README, tsk, noone reads that...
[17:04]  * pitti hugs tseliot, just kidding
[17:04] <tseliot> pitti: fine, I just wanted to make sure that it could work
[17:04] <tseliot> pitti: ;)
[17:04] <pitti> peopel should totally rename them to SECRET_STUFF_CLASSIFIED.txt
[17:04] <Keybuk> pitti: I think i might stir up more controversy in the kernel/plumbing community next week
[17:05] <Keybuk> by suggesting that the kernel just make device nodes in /sys, so all udev has to do is chmod(), chown() and make symlinks in /dev
[17:05] <tseliot> pitti: or PLEASE_DO_NOT_READ_UNDER_ANY_CIRCUMSTANCE.txt
[17:05] <pitti> tseliot: PYTHONPATH=. tests/run  -i tests/xorg.conf doesn't work either, though
[17:06] <tseliot> pitti: what's the error?
[17:07] <pitti> No such file or directory: '/home/martin/ubuntu/tmp/xorgparser/xorg.conf'
[17:07] <pitti> tseliot: I'd just like to call the test suite during build of the package
[17:07] <tseliot> pitti: and is there such file?
[17:07] <pitti> tseliot: no, it should be xorgparser/tests/xorg.conf
[17:07] <pitti> tseliot: if I specify -i tests/xorg.conf
[17:07] <pitti> no?
[17:08] <tseliot> the answer should be in settings.py
[17:08] <tseliot> pitti: ^^
[17:08] <pitti> inputFile = "tests/xorg.conf"
[17:09]  * pitti recognizes the code structure in tests/run :)
[17:10] <tseliot> pitti: can you paste this into settings.py? http://pastebin.com/d1fd6d7d
[17:10] <pitti> tseliot: no difference
[17:10] <tseliot> pitti: it works here. Did you install the package before running the tests?
[17:11] <pitti> tseliot: no, I run it with PYTHONPATH=.
[17:11] <pitti> tseliot: anyway, debian/rules could use
[17:11] <pitti> (cd tests; PYTHONPATH=.. ./run)
[17:11] <pitti> that works
[17:11] <pitti> tseliot: that could look like
[17:11] <pitti> common-post-build-indep:
[17:12] <pitti> erm, "::" at the end
[17:12] <pitti> common-post-build-indep::
[17:12] <pitti>         (cd tests; PYTHONPATH=.. ./run)
[17:12] <pitti> provided that ./setup.py clean or debian/rules clean removes the test output and settings.py again
[17:13] <tseliot> pitti: does it work if you run each test singularly?
[17:17] <metavoid> pitti, does ubuntu have gnomesu installed by default, or with what *su it goes with?
[17:17] <tseliot> pitti: BTW I have just pushed an update to my xkit branch of Jockey. I have yet to clean xorg_driver.py and to add the tests though.
[17:21] <pitti> metavoid: gksu and gksudo
[17:21] <metavoid> pitti, that's a problem :(
[17:22] <metavoid> pitti, i'm looking for a common su for several distributions
[17:22] <pitti> tseliot: btw, do you have the python-apt change in a separate branch?
[17:22] <pitti> tseliot: I could merge that quickly into trunk, whereas I can't merge/upload the xkit branch so quickly
[17:23] <pitti> tseliot: (I'm currently reviewing/uploading x-kit, but that needs to get to the archive and main first)
[17:23] <tseliot> pitti: I can create a new branch for the apt part
[17:24] <pitti> tseliot: the two are unrelated, right? so it's easier to review if split by feature
[17:24] <pitti> tseliot: oh, sorry, there's something that slipped past me before: the package name needs to be python-xkit
[17:24] <pitti> tseliot: Python policy for consistent package names
[17:25] <pitti> tseliot: shall I create a branch with my changes?
[17:25] <tseliot> pitti: yes, they don't depend on each ether
[17:25] <pitti> tseliot: I'll do some minor tweaks to x-kit packaging and upload
[17:25] <tseliot> pitti: sure, thanks
[17:37] <tseliot> pitti: ok, I restored the original nvidia.py, fglrx.py and xorg_driver.py. The rest should be ok. It's all in this branch: ~albertomilone/jockey/ubuntu-core-apt
[17:38] <pitti> sudo dpkg -i ../python-xkit_0.3.4_all.deb
[17:38]  * pitti whistles
[17:39] <pitti> tseliot: ok, uploaded, will beat through NEW in a minute; I put my changes into bzr; can you please do "bzr pull lp:~pitti/xorgparser/packaging-fixes"?
[17:39] <tseliot> heh
[17:39] <tseliot> pitti: sure
[17:39] <pitti> tseliot: if you pull, it won't be a merge, but since I used your branch for Vcs-Bzr:, pull will look cleaner
[17:40] <mpt> tseliot, any specific part of it, or the whole thing?
[17:40] <pitti> ^ I think that refers to "how to represent the recommended driver"?
[17:41] <tseliot> mpt: we need to highlight the recommended version of a driver when more than 1 is provided. Have a look at these screen shots: http://albertomilone.com/ubuntu/jockey/jockey-bold.png
[17:41] <tseliot> http://albertomilone.com/ubuntu/jockey/jockey-underline.png
[17:41] <tseliot> http://albertomilone.com/ubuntu/jockey/jockey-recommended.png
[17:41] <tseliot> http://albertomilone.com/ubuntu/jockey/jockey-kde-bold.png
[17:42] <hwilde> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/244779
[17:42] <tseliot> pitti: ok, pulled
[17:43] <pitti> tseliot: please review bzr log and the diffs, and let me know if anything is unclear to you, or you have objections
[17:44] <mpt> That intro text is depressingly long
[17:45] <hwilde> mpt, thats ok nobody reads it :)
[17:45] <mpt> If it was shorter, more people would read it
[17:45] <hwilde> you could do one of those lightbulby things for the curious
[17:45] <mpt> tseliot, what's the difference between "Enabled" and "In use"?
[17:46] <tseliot> mpt: Enabled means installed and set in the xorg.conf (I guess) while In use means that the module is loaded
[17:46] <hwilde> you can enable proprietary drivers for something that is not in use, like maybe a removable media
[17:47] <hwilde> doesn't quite apply to your video card
[17:47] <superm1> hwilde, really?  i thought that it won't show up on the list unless the hardware is detected
[17:47] <hwilde> like a wireless card
[17:47] <hwilde> you can enable atheros or whatever, but it won't be in use if you eject the card
[17:47] <tseliot> hwilde: you can try it with your toaster too ;)
[17:47] <pitti> tseliot: that branch has some is_recommended changes, I guess those are leftovers and I can kill them from that merge?
[17:47] <pitti> +        col1.set_attributes(text_renderer, markup=3)
[17:47] <pitti> tseliot: ^ what does that do?
[17:48] <pitti> tseliot: is that for the 'recommended' string?
[17:48] <mpt> hwilde, so something can switch from "In use" to "Not in use", or vice versa, without a restart?
[17:48] <tseliot> pitti: no, don't remove them, that's the way we highlight the recommended driver version
[17:48] <hwilde> mpt,  I think it would switch from "In Use"  to "Enabled"
[17:48] <pitti> tseliot: hm, when I merge from ubuntu-core-apt, bzr st says it is also merging in x-kit support et al
[17:49] <pitti> tseliot: support for recommended driver should be merged to trunk, not to ubuntu
[17:49] <tseliot> pitti: col1.set_attributes(text_renderer, markup=3) says that column 3 should use the markup (e.g. <b></b>)
[17:49] <mpt> hwilde, but it's already marked as "Enabled"
[17:49] <pitti> tseliot: I think I'll just cherrypick the last 3 commits and merge the recommended parts to trunk
[17:49] <pitti> tseliot: oh, I see, the last commit was "remove x-kit stuff" :)
[17:50] <tseliot> pitti: yes, right ;)
[17:50] <pitti> tseliot: I guess that branch is pretty damaged, it should just be removed afterwards, but nevermind; I'll figure it out
[17:50] <tseliot> pitti: ok
[17:50] <hwilde> mpt,  so what is the difference?
[17:50] <mpt> hwilde, that's what I'm asking y'all :-)
[17:50] <pitti> tseliot: and I think I'll wait for mpt's verdict for merging the recommended support
[17:50] <tseliot> mpt: which one do you suggest that we use? Bold, underline, etc. or what?
[17:51] <mpt> tseliot, so the mundane answer to your question is, I don't understand what the bold or the underline by itself is supposed to mean
[17:51] <tseliot> pitti: ok, no problem.
[17:52] <mpt> I mean, you've told me that it means "Recommended", but I wouldn't have guessed that without you having told me.
[17:52] <tseliot> mpt: shall we use "[Recommended]" then?
[17:52] <hwilde> mpt, oh I am not much for semantics.   or guis for that matter.      or proprietary drivers :)
[17:52] <mpt> That would be better than the other two, yes
[17:52] <mpt> However, that would still leave me wondering why they were checkboxes and not radio buttons
[17:52] <mpt> and also why the non-recommended options were offered at all.
[17:53] <tseliot> mpt: you should ask pitti about the rest of the GUI
[17:53] <mpt> If I need to make a choice, help me make an informed choice, otherwise don't bother. :-)
[17:53] <tseliot> mpt: about the non-recommended options there is a reason.
[17:53] <hwilde> how about a slider bar that goes between "proprietary" and "free" and the users just slide it where they feel comfortable  ;)
[17:54] <totopalma> hi pitti :) can you take a look at bug #234754 please? :)
[17:54] <tseliot> mpt: sometimes your cards are supported by one or more versions of the driver. We follow a certain criterion to determine which one you should install, however users might think differently
[17:54] <pitti> totopalma: sorry, not right now, about to runout
[17:55] <totopalma> pitti, ok
[17:55] <pitti> totopalma: please subscribe me and ask the question in the bug
[17:55] <pitti> tseliot: any chance we could call gobject.threads_init() in oslib.py?
[17:55] <pitti> tseliot: that would be cleaner, I'll move it there
[17:55] <mpt> tseliot, ok, what's the criterion?
[17:56] <pitti> tseliot: hm, will take me a while to merge, I don't like "from foo import *" etc.
[17:56] <tseliot> mpt: for example if you have 2 cards you might choose to select a driver which makes both of them work even though it's not the latest version which your new card supports. Sometimes you might want to ignore the old card and simply install the latest release of the driver because of its new features and make use of only you newer card
[17:56] <tseliot> etc.
[17:57]  * mpt admires his shiny new triple-boot startup menu
[17:57] <tseliot> pitti: what's the problem with gobject.threads_init()? that should be called before you perform those operations
[17:58] <pitti> tseliot: right, but not in backend.py, we only need it in the ubuntu branch for python-apt
[17:58] <pitti> tseliot: i moved it to OSLib.__init__()
[17:58] <tseliot> pitti: ok, but make sure that it works there ;)
[17:58] <pitti> tseliot: yep, sure
[17:59] <pitti> tseliot: do I actually need the TextFetchProgress stuff, or was that just for testing?
[17:59] <mpt> tseliot, ok, so to be useful I think this list needs to give the benefit and drawback of each of the options
[18:01] <pitti> tseliot: oh, "myobject", I see
[18:01] <tseliot> mpt: right. This would make sense only when users have 2 cards plugged in, otherwise the latest version is recommended. What should I say in the latter case?
[18:02] <mpt> tseliot, why would you want two graphic cards to work at the same time?
[18:02] <tseliot> pitti: feel free to change the names, I had to pass an object in order to access the percentage from the outside
[18:02] <ogra> mpt, for two monitors
[18:02] <mpt> aha
[18:02] <tseliot> ogra: right
[18:03] <ogra> if you take two multihead cards even for four monitors .. though i doubt you find that wide mousepads :P
[18:04] <pitti> tseliot: this fails the test suite, I'll track it down
[18:04] <mpt> so for example, "Lets both your displays work, but does not allow Suspend."
[18:05] <moquist_> ogra: nearly done (again) with moodle 1.9.1
[18:05] <mpt> I guess there are all sorts of complicated reasons why you can't present a message like that
[18:05] <ogra> moquist_, yay
[18:06] <tseliot> mpt: if users have a problem with the recommended driver version, they will try another version. This is how it works (usually)
[18:06] <tseliot> mpt: for example maybe the recommended driver has a regression and you install another version, etc.
[18:07]  * mpt now has blue/black streaks all across his display :-/
[18:09] <mpt> tseliot, so what's the procedure for trying them? Do you need to restart between each one?
[18:09] <tseliot> mpt: yes, a restart is required (for common users...)
[18:10] <Treenaks> Am I the only one who keeps clicking "Remove from panel" instead of "Empty trash" ?
[18:15] <pitti> tseliot: hm, I don't understand why this needs a separate thread - the outer thread just sleeps anyway?
[18:16] <tseliot> pitti: don't you need to run the while loop after you start the installation so that you can pass the "percent" with the progress_cb function?
[18:17] <tseliot> until the process is complete
[18:17] <pitti> tseliot: right, but wouldn't it be easier to pass the callback down to the FetchProgress/Installprogress objects, and their pulse/updateStatus methods call that directly?
[18:18] <pitti> tseliot: ok, let me play around with this
[18:19] <mpt> tseliot, so if at all possible, I suggest presenting a human-readable explanation of what the selected driver does, in a second pane underneath the first. Otherwise I don't think jockey will be useful to nearly as many people as it could be.
[18:19] <tseliot> pitti: aah, calling that function directly from there. You would only have to pass that function instead of the object then
[18:19] <mpt> Since it's presenting options without giving people the info they need to decide.
[18:19] <pitti> tseliot: right, passing the callback down instead of the status up
[18:20] <Adri2000> pitti: could you please move the the hardy amsn sru to -updates? (bug #243722)
[18:20] <tseliot> pitti: yes, that would be possible
[18:20] <pitti> tseliot: ok, playing more
[18:21] <tseliot> mpt: ok, I'll think about it. Thanks for your help
[18:21] <pitti> Adri2000: hardy and feisty are verified AFAICS, leaving gutsy and dapper
[18:22] <mpt> tseliot, no problem, thanks for asking :-)
[18:22] <Adri2000> pitti: feisty has one "works for me" (+ mine of course), is that enough?
[18:22] <pitti> Adri2000: for me it is
[18:23] <Adri2000> ok
[18:29] <pitti> ok, I'm off for today
[18:30]  * tseliot > dinner
[18:34] <tkamppeter> pitti, hi
[18:34] <tkamppeter> pitti, I have uploaded a new CUPS to SVN, this time with texttopdf
[18:35] <tkamppeter> can you upload it to Derbian and Ubuntu. Thanks.
[18:37] <ogra> tkamppeter, he just said goodnight ... it is probably better if you mail him to make sure he gets the request
[18:38] <tkamppeter> ogra, the "pitti has quit" did not appear, he always closes hios client when he leaves.
[18:40] <jpds> pitti: 'Tis a very nifty script indeed :)
[18:44] <kirkland> bryce: ping
[18:45] <bryce> heya kirkland
[18:46] <kirkland> bryce: hey, thought i'd run something X11-ish by you....
[18:46] <kirkland> bryce: Bug #257825, with patch
[18:58] <BenC> pitti, mdz: Updated my findings on bug 255635
[18:58] <BenC> pitti, mdz: In short, it's not a kernel bug
[19:01] <Kopfgeldjaeger> Does ufw output the iptable commands it uses anywhere?
[19:03] <bryce> kirkland: mm, I think there may be a better solution than xorg.conf for this
[19:03] <kirkland> bryce: i figured as much.... i'm all ears
[19:04] <kirkland> bryce: basically, i want to be able to move my hard drive back and forth among multiple (ok, 2 for now) similar-but-not-the-same laptops, and have X just work (tm)
[19:04] <bryce> kirkland: yeah
[19:04] <bryce> kirkland: I think the right direction to go for this use case is the "no xorg.conf"
[19:04] <kirkland> bryce: and i recognize this is perhaps a little hackish, especially with xorg.conf going away and all
[19:04] <jcristau> kirkland: that already works, just not with nvidia?
[19:04] <BenC> bryce: btw, the gem patch doesn't apply to 2.6.26 or 2.6.27...missing some other updates in drm subsystem...any idea what those updates are?
[19:04] <kirkland> jcristau: then it doesn't work for me (or any of the other nvidia users out there)
[19:05] <BenC> bryce: I'm guessing it's something in -mm, but I hate to guess on this
[19:05] <bryce> BenC: no I don't, hmm
[19:06] <bryce> BenC: want me to put you in touch with keithp?  I bet he's the one to go to about this.
[19:06] <BenC> bryce: yeah, please
[19:07] <bryce> kirkland: -nv or -nvidia ?
[19:08] <kirkland> bryce: well, i'm still having better experience (resolution, 3d) with -nvidia, unfortunately
[19:08] <kirkland> bryce: i try -nv once a week or so, just to check, though ;-)
[19:08] <bryce> ok, so when you go xorg.conf-less, it comes up as -nv?
[19:08] <jcristau> nv won't get better anytime soon
[19:08] <bryce> agreed
[19:08] <jcristau> seeing how it's maintained by the same people as nvidia, and they want you to use the blob
[19:09] <kirkland> bryce: not sure....  gimme a minute to save all of my buffers and I'll restart X
[19:09] <batsquid> the guided setup of ubuntu server 8.04 lts is great, but there's one place i always need help. partition disks. could more help be provided on each option here? Guided - use entire disk and set up LVM (Logical Volume Manager i presume, but i can't figure out if i want to do that). I have a 40GB disk and i want to use 1.5xRAM (768MB) for swap - or so i have been recommended. this screen is somewhat confusing
[19:09] <emgent> hello people
[19:11] <batsquid> or is swap taken care of under the hood by 8.04 ?
[19:12] <bryce> BenC: email away
[19:13] <warren> hey, did do you folks have any URL's with flash confirmed to cause Flash 10 to crash?
[19:13] <warren> i'm trying to nail down a reproducer
[19:13] <warren> I found one on sourceforge.net, but I need to reload until a random flash ad appears before it crashes.
[19:13] <warren> so it isn't easy to reproduce there
[19:13] <ogra> warren, asac might know if he's still around at that time of day
[19:13] <bryce> kirkland: ok anyway in general (not considering proprietary vs. open) for such a case is to just make the xserver aware that it needs to use thus and such driver for thus and such hardware
[19:14] <ion_> pitti: I already mentioned this to tkamppeter, but here’s a diff for cups (against current svn) consisting of a couple of bugfixes, http://heh.fi/tmp/cups.debdiff
[19:14] <bryce> kirkland: I suspect the issue is that if it boots with -nv and "basically" work, there's not really a strong enough reason to force it to default to -nvidia for every user of that hardware
[19:15] <kirkland> bryce: okay, i'm booted xorg.conf-less
[19:15] <BenC> bryce: thanks
[19:15] <kirkland> bryce: the resolution is right, but the color depth isn't
[19:15] <bryce> but I agree with jcristau that waiting for nv to get better is a watching-the-paint-dry exercise
[19:16] <kirkland> bryce: how can I tell for sure what driver I'm using?  lsmod shows the nvidia driver loaded, but X isn't necessarily using that, right?
[19:17] <bryce> look in /var/log/Xorg.0.log
[19:17] <kirkland> bryce:         "Builtin Default nv Screen 0" for depth/fbbpp 24/32
[19:17] <bryce> grep LoadModule should do it
[19:17] <mtrudel> asac: I think I found a bug, presumably in network-manager-vpnc, in the version from the network-manager team PPA on Launchpad... the standard report a bug tool in Launchpad doesn't seem to me like the best of ways to report it, because I guess it would end up with the "normal" versions of NM in ubuntu? is there a better way to report what I've found?
[19:18] <kirkland> bryce: (II) LoadModule: "nv", but it also loaded "vesa"
[19:18] <kirkland> bryce: the rough color gradients make it look more like vesa
[19:18] <asac> mtrudel: what is your problem?
[19:18] <bryce> I think that's normal for xorg.conf-less boot
[19:19] <asac> mtrudel: the vpnc plugin is known to still have issues with the authentication dialog. if you see that: i am working on getting a fix out as soon as possible
[19:19] <mtrudel> ah, i see
[19:19] <bryce> ok yep so loading "nv" by default as I thought
[19:19] <asac> mtrudel: yes. most likely thats your issue
[19:20] <mtrudel> that's precisely the problem I was having... looking a little bit at how to fix that, but given that I'm at work, the time I can put to this is limited :)
[19:20] <kirkland> bryce: so perhaps maintain a list of hardware that prefers the nvidia module?
[19:21] <kirkland> bryce: how can I force it to use nvidia?
[19:21] <bryce> kirkland: we've got such a thing already, although I don't remember if it's set up for nvidia
[19:22] <bryce> look in /usr/share/xserver-xorg/pci/
[19:22] <asac> mtrudel: if you want to contribute to network-manager, feel free to jump in ... there are other things you could do - after your work :-P
[19:22] <kirkland> bryce: k, i see nv.ids, but no nvidia.ids
[19:22] <mtrudel> asac: already did some time ago, one patch even got in universe :)
[19:23] <bryce> I think we need to talk with tseliot, as he was working on hooking in envy/jockey and the proprietary drivers to use either the same or an analogous setup
[19:23] <asac> mtrudel: good.
[19:23] <bryce> so possibly there's already a solution in place we can reuse
[19:23] <kirkland> bryce: excellent, please point me the way
[19:23] <kirkland> bryce: i'm happy to seed that nvidia database with my card info :-)
[19:24] <mtrudel> i'm already pretty sure i've found something, but I'm struggling a bit with the patches
[19:24] <bryce> kirkland: of course that also leaves the question of if we should prefer proprietary drivers in all cases where it works better, or only in cases where the hardware works no other way
[19:24] <bryce> I suspect for Ubuntu the principle is the latter not the former
[19:24] <kirkland> bryce: IMHO, when it works "better" ....
[19:24] <kirkland> bryce: yes, for Ubuntu, I agree
[19:25] <kirkland> bryce: it's both sad and frustrating to pay for hardware, and not be able to use it, when there is a way to do so
[19:25] <bryce> yeah no kidding
[19:26] <bryce> hmm
[19:26] <kirkland> bryce: that question could be discussed, i suppose, on ubuntu-devel@, in case others have opinions
[19:26] <bryce> kirkland: probably a good idea
[19:26] <kirkland> bryce: but I hope we're in the majority ;-)
[19:26] <bryce> kirkland: now, turning to your patch, I don't dislike it in principle.  It might be a good way to go.
[19:26] <kirkland> bryce: it's a neat, opt-in hack
[19:27] <bryce> the downsides are, that it's really solving a pretty specific use case (just -nvidia would need it I think)
[19:27] <kirkland> bryce: as soon as you have your xorg.conf set up the way you want, you "sign" it with "/etc/init.d/x11-common hwsign"
[19:27] <bryce> however, I could see it get expanded to cover other kinds of wonky hardware or stuff not well supported by X's normal hotplug stuff
[19:27] <kirkland> bryce: and subsequent boots will always load that xorg.conf into place
[19:28] <bryce> of course it could be argued that such cases should be handled by fixing the hotplug, not via a workaround.
[19:28] <bryce> but it's a pretty clean workaround as far as workarounds go
[19:28] <kirkland> bryce: true, the idea behind it could also solve some silly minor issues to do with me changing the networking hardware, etc. from underneath the installed OS
[19:29] <kirkland> bryce: fortunately, i have the same eth/ath drivers in both laptops...  but in one machine, they're eth0/ath0, and in the other, they're eth1/ath1 :-)
[19:29] <bryce> there's also a potential downside in that it could confuse users - like if they signed their xorg.conf, then used some other tool that updated their xorg.conf, then rebooted it restores the original signed one
[19:30] <bryce> so I think if we go forward with it, we need to ensure it gets integrated or made compatible with X-kit, to detect and prevent such a situation
[19:30] <kirkland> bryce: okay, i'm not familiar with X-kit....
[19:31] <bryce> in fact maybe we should think a bit more generically about alternate xorg.conf's, such as backup versions
[19:31] <kirkland> bryce: true...  I have 20+ xorg.conf's in my /etc/X11 :-P
[19:31] <bryce> X-kit is a new python xorg.conf parser library tseliot is putting together, that we'll be using with envyng and other tools
[19:32] <bryce> I wonder if we could stick them all in bzr ;-)
[19:32] <bryce> anyway, could you post an email summarizing the situation to ubuntu-x@?
[19:33] <kirkland> bryce: um, different that the description in the bug?
[19:34] <bryce> the description is fine I think
[19:34] <kirkland> bryce: okay, I'll write a one or two liner, and point to the bug
[19:35] <bryce> maybe include our discussion above
[19:35] <kirkland> bryce: sure, i'll summarize that
[19:35] <bryce> cool.  and make sure to mention the need for making this work with envyng/jockey, since it involves -nvidia
[19:36] <kirkland> bryce: right, it sounds like it's mostly a matter of insufficient support for nvidia kit
[19:36] <bryce> x-kit is uploaded to universe if you want to check it out
[19:36] <bryce> yep
[19:36] <kirkland> bryce: will do
[19:36] <bryce> I'll comment a bit on the bug too
[19:37] <kirkland> okay.  i'm going to maintain an x11-common package with this patch in my ppa until we settle on something
[19:38] <bryce> great
[19:48] <cody-somerville> Is cjwatson on vacation or something?
[19:48] <cody-somerville> Wait a tick, I can answer that question myself
[19:48] <bryce> cody-somerville, yep
[19:49] <bryce> cody-somerville, evand and slangasek are gone as well
[19:49] <cody-somerville> All the people I wanted to talk to :/
[19:49] <cody-somerville> They must have done this to me on purpose.
[19:49]  * cody-somerville grumbles.
[19:50] <superm1> bryce, how long they all gone for, you know?
[19:53] <tseliot> kirkland: what happens when you change your graphics card? A new xorg.conf is generated?
[19:54] <kirkland> tseliot: please clarify that question....
[19:55] <bryce> superm1: cjwatson is gone for the week.  the others are at debconf iirc so will be back after that.
[19:56] <kirkland> tseliot: what do you mean?
[19:56] <tseliot> kirkland: let's assume that you have an xorg.conf and a geforce 7300. You sign the xorg.conf. Then you buy a new NVIDIA card. What would happen at this point?
[20:03] <tseliot> kirkland: if what I write doesn't make any sense to you it might be because I'm quite tired ;)
[20:04] <kirkland> tseliot: ;-) .....
[20:04] <kirkland> tseliot: you boot your machine and it attempts to run with the old xorg.conf ... maybe it works, maybe it doesn't...  in any case, my suggested code hasn't taken any action yet
[20:05] <kirkland> tseliot: either it "just works", or you hack around until you get to the point at which it "works"
[20:05] <kirkland> tseliot: then you would consciously make the decision to "sign" this xorg.conf with hash of your current hw VGA configuration reported by lspci
[20:06] <kirkland> tseliot: by running "/etc/init.d/x11-common hwsign"
[20:06] <kirkland> tseliot: that copies the current xorg.conf, which you're "certifying", to a new xorg.conf appended with a md5sum of your hw configuration
[20:07] <kirkland> tseliot: on subsequent boots, if a change in hardware (lspci | grep VGA) is detected....
[20:07] <kirkland> tseliot: x11-common will look for a "signed" xorg.conf matching the md5sum
[20:07] <kirkland> tseliot: and if found, that one is used
[20:07] <kirkland> tseliot: otherwise, no additional action is taken
[20:08] <kirkland> tseliot: so to answer your question, really, it's just the conscious step of "certifying" your working xorg.conf by running the "hwsign" init script action
[20:08] <kirkland> tseliot: perhaps that could be more automatic with this x-kit thing?
[20:08] <tseliot> kirkland: aah, I understand now. It's more or less what I suggested here: http://ubuntuforums.org/showpost.php?p=1368826&postcount=10
[20:09] <tseliot> kirkland: of course your solution is a lot saner
[20:11] <tseliot> kirkland: it depends on what you would like to do with X-Kit
[20:12] <kirkland> tseliot: Yup :-)
[20:13] <kirkland> tseliot: hashing it gives uglier filenames, but a virtually infinite space for avoiding collisions
[20:14] <joaopinto> gnome-terminal is crashing when selecting a section is of text, is anyone aware of a record for this bug ?
[20:15] <tseliot> kirkland: this trick wouldn't work if you wanted to switch between fglrx and nvidia and vice versa
[20:15] <kirkland> tseliot: because of the gl libraries?
[20:16] <jcristau> tseliot: or between fglrx or nvidia and anything else, really
[20:21] <tseliot> kirkland: yes
[20:21] <tseliot> jcristau: heh
[20:21] <jcristau> what?
[20:22] <kirkland> tseliot: well, i think it's better than nothing.  you lose 3d capability, but still get premium resolution and bit depth, i think
[20:29] <tseliot> kirkland: yes, right. And signing the xorg.conf would be something which should be (deliberately) done by the user, therefore I don't see any problem with this approach
[20:29] <tseliot> jcristau: never mind
[20:29] <kirkland> tseliot: good, i'm in agreement with that point
[20:30] <kirkland> tseliot: bryce had some good thoughts about better management of multiple xorg.conf's
[20:30] <kirkland> tseliot: and extending this approach to other changing hw (wacom tablets, etc.)
[20:30] <bryce> kewl, thought he would :-)
[20:33] <tseliot> kirkland: yes, I read what bryce wrote before (in this chat session)
[20:34] <kirkland> tseliot: ah, good
[20:34] <tseliot> kirkland, bryce: if you need a hand, I'll be glad to help
[20:34] <mkrufky> is anybody here going to the Linux Plumbers conference?
[20:34] <kirkland> mkrufky: i've heard rtg talk about going
[20:35] <mkrufky> cool
[20:35] <superm1> tseliot, kirkland you know we could always register an alternatives system for libGL
[20:35] <superm1> it would make for less ugly diversion magic
[20:35] <mkrufky> im trying to justify why my boss should pay for me to attend
[20:35] <kirkland> superm1: that's what I suggested!
[20:35] <superm1> kirkland, haha, i just stepped in and saw the tail end of the convo
[20:35] <kirkland> superm1: sorry, that was a couple of days ago
[20:36] <superm1> kirkland, unfortunately at least in the fglrx case, there are more diverted libraries too
[20:36] <superm1> libdri i believe is the main one
[20:36] <superm1> i would understand resistance to registering libGL with the alternatives system though
[20:36] <bryce> tseliot, kirkland: regarding the situation of plugging in new hardware, booting and failing, well we could also consider integrating the failsafe-x to be aware of this xorg.conf-alternates system, so it would popup a screen offering the option of trying any previously saved xorg.conf's in the system
[20:37] <kirkland> superm1: Aug 08 02:43:22 *       kirkland wonders if it would be possible to make those libs update-alternatives savvy....
[20:37] <bryce> tseliot, kirkland: as well as an option to regenerate a stock xorg.conf, and/or running with no xorg.conf.  And one day maybe something fancier ala displayconfig-gtk
[20:37] <kirkland> superm1: Aug 08 02:43:42 <tjaalton>      uh no please, dpkg-divert is enough of a nightmare :)
[20:38] <tjaalton> we could just apply the patch to prefer "nvidia" if it's installed
[20:38] <tseliot> bryce: I really like this idea.
[20:38] <tjaalton> and similar one for fgrlx
[20:38] <tjaalton> -lrx
[20:38] <superm1> tjaalton, you mean to prefer the nvidia or fglrx libGL's via a different name if installed?
[20:39] <tseliot> tjaalton: a lot of people would complain about Aaron Plattner's patch
[20:39] <tjaalton> superm1: no, let the xserver pick nvidia if it's installed
[20:39] <tjaalton> tseliot: who would?
[20:39] <tseliot> tjaalton: I wouldn't
[20:39] <tjaalton> upstream said that it's a distro thing
[20:40] <kirkland> bryce: sure, and you could sort those xorg.conf's by reversed-date (most recently used)
[20:40] <superm1> that particular patch was just for choosing the modules if available and prevents the necessity of xorg.conf modifications in the first place, right?
[20:40] <tjaalton> btw, is x-kit hal-aware? does it edit fdi-files for input drivers?
[20:41] <tseliot> tjaalton: no, I haven't worked on that yet. Any links to how fdi files work?
[20:41] <tjaalton> superm1: right, it would pick the blob even if you didn't have xorg.conf
[20:41] <tjaalton> tseliot: hal documentation
[20:41] <tseliot> tjaalton: I meant, Any links on how...
[20:41] <tjaalton> tseliot: hehe, no :)
[20:41] <bryce> tseliot: see http://wiki.ubuntu.com/X/Config
[20:41] <tseliot> tjaalton: ok, I'll have a look at it
[20:41] <bryce> I put some explanations of fdi files and examples there
[20:41] <superm1> tjaalton, yeah if there is no opposition at the distro level, i think a patch like that would be welcomed for users
[20:42] <tjaalton> superm1: that would also make a part of jockey/xkit obsolete
[20:43] <superm1> tjaalton, indeed
[20:43] <tseliot> bryce, tjaalton: so that's a simple xml file. It would be trivial to manipulate
[20:43] <tjaalton> tbh I haven't looked at x-kit at all yet :)
[20:44] <superm1> tjaalton, would a similar patch be possible to also check if you are loading fglrx/nvidia to use a different libGL so that no diversions or alternatives were necessary (maybe install it somewhere else instead)?
[20:44] <tseliot> bryce, tjaalton: I can write a module for X-Kit to deal with fdi files
[20:45] <tjaalton> superm1: I'm not sure..
[20:45] <tjaalton> tseliot: cool
[20:45] <bryce> tseliot: excellent
[20:45] <jcristau> superm1: no matter how much you patch X you're not going to change where ld.so looks for libGL.so.1
[20:45] <superm1> jcristau, yeah that's what i was thinking
[20:49] <superm1> tjaalton, why do you think alternatives would be more complex than diversions?  It would at least allow you to have multiple things installed simultaneously.  eg if you wanted to try multiple different nvidia driver versions, or possibly switch back and forth between open and closed source without making package installation changes
[20:49] <psyke83> hi, I packaged the latest flashplugin-nonfree release. This latest release has new dependencies (libcurl3, libnss3-1d and others) and works fine for 32bit users, but not 64bit, as it needs the 32bit version of these libraries. Do I really need to update the ia32-libs package with these new dependencies or can they be packaged separately (like lib32asound2)?
[20:50] <tjaalton> superm1: maybe it could work.. it would be a surprise if no-one had thought about it before :)
[20:50] <superm1> tjaalton, well at least it would prevent each driver from having to know about every other possible driver
[20:51] <superm1> tjaalton, eg if there is an nvidia -180 release, don't have to update conflicts/replaces on the other 4
[20:52] <tjaalton> superm1: hmm right
[20:52] <tjaalton> superm1: you are welcome to demonstrate it in action ;)
[20:52] <superm1> tjaalton, well lets see, when's feature freeze.
[20:52] <tjaalton> handling diversions is ugly, it can't be worse :)
[20:53] <tjaalton> two weeks from now?
[20:53] <superm1> i'll see if i have time to mess with it on one of my -nvidia machines before then
[20:53] <superm1> if not, then we can plan to try for ubuntu+1
[20:54] <tseliot> superm1: let me know how it goes
[20:54] <tseliot> superm1: if it goes... ;)
[20:54] <tjaalton> by then we'll have 3D support for r6xx and nouveau released and... :)
[20:54] <tjaalton> I'll get me coat ->
[20:55] <superm1> tseliot, i'll have a handful of patches if it goes well :)  the worry with it though about generating packages for earlier ubuntu releases
[20:55] <superm1> at least for the -fglrx case. i'll see though
[20:56] <psyke83> superm1, the only practical problem with your idea is that the "nvidia-all" package would become quite bloated to hold the new/legacy/legacy-old packages, or else it could dynamically grab the upstream tarball like flashplugin-nonfree :)
[20:57] <superm1> psyke83, nvidia-all package?  i didn't realize that such a package existed
[20:57] <superm1> they are their own source packages now
[20:58] <psyke83> superm1, well, I thought that if all the binaries were in the same package, it would cause bloat... but perhaps I misunderstood your idea about using the update-alternatives, sorry ;)
[21:10] <slangasek> bryce: evand is on vacation, not at DebConf; I've just arrived home from DebConf today, it'll be at least a few hours before I'm fully spun up again though
[21:11] <slangasek> cody-somerville: if you have a question, asking it may improve your place in the queue ;)
[21:11] <cody-somerville> slangasek, https://pastebin.canonical.com/8177/
[21:12] <bryce> slangasek: ah ok
[21:16] <slangasek> cody-somerville: hmm; what's the question? :)
[21:16] <cody-somerville> slangasek, would that sort of report between daily builds be useful for the distro team?
[21:16] <cody-somerville> or just useful somehow
[21:24] <mathiaz> kirkland: I've put up my comments for your update-motd package on REVU
[21:24] <kirkland> mathiaz: awesome, thanks!
[21:39] <LaserJock> who takes care of pidgin? desktop team?
[21:54] <BenC> LaserJock: it certainly isn't the kernel team :)
[21:54] <LaserJock> phew, good to know ;-)
[21:55] <LaserJock> wouldn't want to have to deal with those crazies ;-p
[21:56] <BenC> hehe
[22:35] <warren> asac: ping
[22:36] <asac> warren: yes?
[22:37] <warren> asac: are you interested in joining a theoretical new mailing list to collaboratively discuss nspluginwrapper issues and development?  (I'm pretty fed up with the lack of an upstream list and everyone going through Gwenole, especially when he disappears for weeks at a time.)
[22:39] <warren> asac: for example, I'm running into issues that are either nspluginwrapper, firefox or Flash 10 bugs.  I currently have nowhere to post my findings where others could possibly help isolate the cause of a problem.
[22:39] <asac> warren: i sometimes wonder if nspluginwrapper could be be maintained by mozilla upstream
[22:39] <warren> asac: Adobe is interested in joining
[22:39] <nenolod> i would prefer for nspluginwrapper to be rewritten
[22:39] <nenolod> ;p
[22:40] <asac> warren: but yes. why not
[22:40] <warren> asac: yes, my thought exactly, although I think creating a community around it is an intermediate step toward that goal.
[22:40] <asac> warren: if adobe wants to contribute this might make sense
[22:40] <pwnguin> adobe wants open source to deal with this STL guy they hired
[22:41] <warren> STL?
[22:41] <pwnguin> i cant remember his name. russian i think
[22:41] <pwnguin> standard template library
[22:41] <nenolod> also, matthew garrett is totally my hero :P
[22:42] <pwnguin> heh
[22:42] <pwnguin> well
[22:42] <pwnguin> im not convinced that the third party didn't make up the logs to continue "teh lolz"
[22:43] <pwnguin> (i didnt anticipate they'd fold, so I wrote their advertisers instead =/ )
[22:44] <nenolod> that ryan guy is a total dumbass
[22:44] <pwnguin> im surprised he knew and could use the bios decoding stuff
[22:45] <nenolod> i must wonder how he managed to get slashdotted too
[22:45] <nenolod> pwnguin, well, he didn't understand what he was seeing fully
[22:45] <pwnguin> he got slashdotted becaus ubuntu forums is a conduit for stupid =(
[22:46] <pwnguin> and slashdot decided they needed to jump on the stupid bandwagon and emulate digg
[22:47] <nenolod> because flaming manufacturers is a GREAT way to get them to do what you want
[22:47] <pwnguin> heh
[22:47] <pwnguin> seems like it
[22:47] <nenolod> it's all a HUGE conspiracy
[22:47] <nenolod> the BIOS author couldn't be incompetent, no way
[22:47] <nenolod> M$ writes every BIOS ever
[22:48] <nenolod> i am being sarcastic if you didn't notice ;p
[22:48] <pwnguin> at any rate, paying any more attention to this is counterproductive
[22:48] <nenolod> i agree
[22:48] <nenolod> it's not even funny lolz
[22:48] <nenolod> it is just dumb
[22:49] <pwnguin> it stopped being funny lolz a long time ago, and it certainly didnt get funny now that i have to convince CFO.com to unsubscribe me from 20 of their email alerts
[22:50] <nenolod> you too? :P
[22:50]  * LaserJock feels left out
[22:51] <pwnguin> LaserJock: you were smart enough to  not give an email address on that guy's blog
[22:52] <LaserJock> didn't particularly feel it was worth the effort, now I'm glad I didn't
[22:53] <ion_> pwnguin: Why not forward those messages to some.appropriate.user@cfo.com instead?
[22:54] <pwnguin> ion_: what you fail to realize is, that cfo is a drop in the bucket
[22:54] <pwnguin> ion_: imagine you wrote a web spider, who's only job was to look for email subscription pages
[22:55] <pwnguin> most of them have confirmation processes
[22:55] <pwnguin> its easy enough to just ignore these, but a substantial fraction are configured... differently
[23:00] <pwnguin> my favorites are the ones that set passwords
[23:00] <pwnguin> to unsubscribe, just enter your email and password
[23:12] <nenolod> pwnguin, for the record, iptables does well with the rest of them. it seems everyone who demonstrated to him otherwise on any medium where he could easily find e-mail addresses is being targeted :(
[23:31] <mathiaz> kirkland: the sticky point will be how to handle motd
[23:31] <mathiaz> kirkland: especially that you copy motd in the postinst
[23:31] <mathiaz> kirkland: but motd is updated on every boot
[23:31] <kirkland> mathiaz: by what?
[23:32] <mathiaz> kirkland: /etc/init.d/bootmish.sh
[23:32] <ogra> /etc/init.d/bootmisc.sh
[23:33] <kirkland> mathiaz: i installed /etc/rc.*/update-motd at 90
[23:34] <kirkland> mathiaz: bootmisc is at 55
[23:34] <kirkland> ogra: thanks!  and welcome back, btw!!!
[23:34] <ogra> :)
[23:35] <mathiaz> kirkland: but you don't copy /var/run/motd to /var/run/motd.head from the init script
[23:35] <mathiaz> kirkland: you just do that on postinst
[23:35] <kirkland> mathiaz: right, I'll fix the init script ;-)
[23:36] <kirkland> mathiaz: hmm, it is sticky, though, i see what you mean
[23:43] <ion_> tkamppeter, pitti: Patch URLs changed: both are in http://heh.fi/tmp/cups/ now. 01-bugfixes contains bugfixes. 02-pdf implements the PDF filter chain for PostScript printers. Settings such as economy mode and DPI seem to work, even from OOo.
[23:45] <ion_> tkamppeter, pitti: If you make changes to the svn before you’re ready to add one or both of those patches, feel free to ask me to rebase them to svn HEAD.