[00:01] <asac_> sbeattie: ?
[00:02] <sbeattie> asac_: sorry, was just wondering about the nss and nspr tasks of the firefox3 tracking bug 237690
[00:03] <sbeattie> was wondering if they should be marked invalid or fixed-released since they've gone out the door, I think.
[00:04] <sbeattie> (at least for hardy)
[00:05]  * calc is going to get dinner
[00:05]  * beDrung is going to bed
[00:06] <beDrung> calc: i am back in 9 hours for testing
[00:09] <calc> beDrung: ok
[00:19] <liw> slangasek, https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/243375
[00:22] <slangasek> liw: <yoink>
[00:22] <slangasek> liw: I don't suppose there are any bugs on https://bugs.launchpad.net/ubuntu/+source/coreutils we could triage out while we're at it? :)
[00:26] <slangasek> liw: the patch needs to change the maintainer field of the package, in line with https://wiki.ubuntu.com/DebianMaintainerField; care to spin me an updated patch quickly, with this change and also adding the bug number to the changelog?
[00:26] <liw> slangasek, sloppy of me, just a minute
[00:34] <liw> slangasek, updated debdiff in LP
[00:37] <liw> slangasek, wrt triaging: do you mean also fixing them, or just juggling bug states in LP?
[00:38] <slangasek> does someone want to flick the ears of the mysql maintainers for creating metapackages that depend on packages with versioned names which contain executables without versions in their names, that then fail to conflict/replace one another?
[00:38] <slangasek> liw: thanks, grabbing.  As far as triaging, I just meant juggling bug states - it's clear to me by looking at the bug list that no one has been over this page in some time, I already found one invalid bug about a user who wanted ls to not honor LC_COLLATE
[00:39] <slangasek> (bug #201302, that)
[00:40] <slangasek> liw: I understand if you have more high-priority things to do, anyway; I'm just mentioning it in passing because there are always more high-priority things to do, which is how the bug lists get long in the first place :)
[00:41] <liw> slangasek, indeed
[00:41] <liw> I'll stick to doing other things for now, though
[00:44] <liw> slangasek, my two install tests under qemu are still running, by the way
[00:44] <slangasek> pff, slow
[00:44] <liw> (boy qemu is slower than kvm)
[00:48] <liw> actually, I'm going to have dinner before I fall asleep... let's hope the tests finish in the mean time
[00:49] <zul> slangasek: whats wrong with mysql?
[00:49] <slangasek> zul: well, bug #208695
[00:49] <slangasek> zul: which is, basically, a design failure of the packages
[00:50] <slangasek> "yes, we'll have mysql-client-4.1 and mysql-server-4.1 in the archive at the same time, so you can pick between them, and we'll have mysql-client as a metapackage to depend on the default version for you, and then we'll cause upgrade failures when you try to switch mmmkay"
[00:50] <slangasek> heh, s/mysql-server-4.1/mysql-client-5.0/
[00:51] <slangasek> ok, the build-deps for coreutils are disturbing
[00:51] <zul> slangasek: ah yes I remember that one
[00:52] <zul> slangasek: they should kicked in the shins
[00:52] <slangasek> I was opting for something a little less violent, because I never know when he'll decide to get me back at a conference :)
[00:53] <zul> slangasek: heh :)
[00:57] <liw> slangasek, coreutils' build-deps? how are they disturbing?
[00:57] <slangasek> liw: lots of X libs
[00:58] <slangasek> (pulled in indirectly)
[00:58] <liw> oh, indirectly
[01:14] <mitsarionas> hi... could i ask something about autoconf/automake here?
[01:23]  * slangasek eews at 202642
[01:23] <bryce> mitsarionas: this channel isn't the right place for that, unless it's specifically related to ubuntu packaging issues
[01:28] <mitsarionas> bryce: where could i get such an answer?
[01:29] <bryce> mitsarionas: depends on the aspect of your question, but look for a channel/forum devoted to providing software development assistance
[01:31] <mitsarionas> ok, thanx :)
[02:38] <emgent> night
[03:19] <bryce> slangasek: ok I think I'm done looking at -geode for today.  I still can't fathom why the symlink would break LTSP.  I've proposed dropping that change and deploying the remainder, and require the LTSP folks to file a bug explaining what the problem is.
[03:19] <slangasek> bryce: ack, g'night then :)
[03:20] <bryce> slangasek: the "ltsp needs the symlink dropped" is at the level of a rumor as far as I'm concerned
[03:20]  * slangasek nods
[03:20] <bryce> slangasek: anyway I just put a new -geode without that into hardy-proposed which I think you can deploy for 8.04.1
[03:20] <bryce> er, s/I think/I recommend/
[03:21] <slangasek> ok
[03:22] <bryce> trading off "possibly maybe leaving ltsp still broken" against "definitely break people currently configured to use 'amd' and make them rightfully angry" doesn't seem like a good enough trade.
[03:25] <slangasek> yes, the way in which it was presented to me suggested that the presence of the symlink itself might break things because of X trying to grab the driver twice or something; but in that case, we should still be able to stow the symlink in the transitional package for the benefit of those users with static xorg.conf, maybe?
[03:31] <bryce> even there, I don't quite understand how that could happen
[03:32] <bryce> maybe I'm dumb, but I'd really like to see the actual issue documented in a bug report before we put an sru'd change out for it
[03:32] <slangasek> I agree, especially in light of the reservations you've expressed as someone who knows X far better than I
[03:32] <bryce> who knows, maybe there's some other way whatever the issue is can be worked around
[03:33] <slangasek> oh, that reminds me, I owe you a pipe-a quirks bug report :)
[03:33] <bryce> ah yes
[03:33] <bryce> hey I've got two others pending, if you send yours, I can do all three together
[03:33] <slangasek> woohoo
[03:41] <RAOF> cjwatson: You're right about the gnome-do-plugins needing to Replaces gnome-do-plugin-{amarok,rhythmbox}.  I haven't done it yet, in part because there'll be a new gnome-do 0.5 package in Debian soon, and the plugins package will need to change.
[03:41] <slangasek> filed as bug #243405
[03:47] <slangasek> bryce: ^^
[03:50] <bryce> excellent
[04:21] <asobi> question
[04:21] <asobi> is there any plans to have second life in the repo?
[04:25] <Hobbsee> not unless someoen packages ti?
[04:26] <RAOF> Is it actually redistributable?
[04:26] <StevenK> I didn't think it was.
[04:26] <persia> Last I heard there were still remaining issues.
[04:28] <asobi> does anyone like to see it or should i not hope
[04:30] <persia> asobi: It's been discussed several times before.  If you are willing to investigate the licensing, and open a bug reporting that it ought be packaged if the license is indeed free, that would be the best way to proceed.  Note that the existence of this bug will not automatically lead to it being packaged, but it will be the first step in the process.
[04:31] <asobi> oh. i was not aware it had been brought up previously
[04:31] <persia> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages may be helpful if you pursue that route.
[04:31] <bliZZardz> persia : what is the general method to be followed to package a new lib/tool...?
[04:32] <bliZZardz> persia : wow..you answered it :)
[04:32]  * persia tries to anticipate
[04:32]  * bliZZardz bows :)
[04:34] <asobi> i guess there's not enough demand for it
[04:34] <asobi> besides licensing issues
[04:34] <asobi> thanks^^
[05:32] <TheMuso> yay for lost changelog entries. :S
[06:53] <pitti> ScottK: I'm on vac today and off in 10 minutes, so I'm afraid I don't today; doko might
[06:53] <pitti> slangasek: debhelper> of course I don't mind, please go ahead
[06:54]  * Hobbsee throws pitti a gummybear
[06:54] <pitti> slangasek: ugh, backwards C:/R:? might have slipped my attention, but I thought the original patch was correct
[06:54] <pitti> Hobbsee: yay, thanks
[07:07] <calc> gah ppa's only allow release pocket uploads
[07:08]  * calc wishes it would work for any standard pocket name
[07:09] <calc> eg hardy-proposed should work along with hardy
[07:22] <calc> http://www.engadget.com/2008/06/27/celebrate-bill-gates-day-with-us/ <- :-)
[07:24] <slangasek> pitti: yeah, I think we both missed the backwards C:/R:, I looked at the earlier upload and it was there :)
[07:25] <calc> btw the video is very funny if you haven't seen it yet ;-)
[07:25]  * calc wonders how long before /. picks it up
[07:29] <bryce> calc, :-)
[07:31] <calc> bryce: uploading to my ppa now, i had uploaded earlier but it rejected it
[07:31] <calc> bryce: my first upload to a ppa actually, i found out it only accepts release pockets
[07:31] <bryce> yeah ppa's are surprisingly limited
[07:32] <calc> i thought it would be better to upload it there than to a p.d.o directory
[07:32] <calc> er p.u.c
[07:32] <calc> much better than uploading it to p.d.o obviously ;-)
[07:32] <bryce> heh
[07:33] <bryce> yeah I set up some ppa's for xorg stuff, but really I find it a lot easier to use people.u.c
[07:34] <slangasek> liw: did you ever get any results back from those qemu installs?
[07:35] <dholbach> good morning
[07:38] <bryce> heya dholbach
[07:38] <dholbach> hi bryce
[07:47] <bryce> slangasek: btw your quirk is in intrepid, sent upstream, and just now in hardy-proposed.
[08:21]  * calc headed to bed
[08:27] <dholbach> hi seb128
[08:28] <seb128> hey dholbach
[08:28] <slangasek> bryce: thanks :)
[08:29] <slangasek> bryce: hmm, I don't actually see it in the hardy-proposed queue
[08:29] <slangasek> (not that it would go anywhere until after .1, but)
[08:30] <bryce> oops, build system rejected it
[08:30] <bryce> hrmm
[08:31] <slangasek> ... build system?
[08:32] <bryce> well, whatever it's called
[08:32] <bryce> Rejected:
[08:32] <bryce> MD5 sum of uploaded file does not match existing file in archive
[08:32] <bryce> Files specified in DSC are broken or missing, skipping package unpack verification.
[08:32] <slangasek> ah
[08:32] <dholbach> hi mvo
[08:32] <mvo> hey dholbach
[08:36]  * bryce tries again
[09:30] <ion_> Oh noes, a painful new Gtk theme. :-(
[09:33] <ogra> ion_, ?
[09:36] <ion_> ogra: White text on a grey background.
[09:37] <ogra> ah, cool !
[09:38] <ogra> in intrepid ?
[09:38]  * ogra still has to run hardy
[09:38] <ion_> Yes
[09:38] <ogra> nice
[09:38] <ion_> Not that nice. :-)
[09:38] <ogra> i saw a pre-version in prague
[09:39] <bryce> ion_: primer gray?
[09:42] <gnomefreak> yeah i got that as well
[09:42] <gnomefreak> also gajim dont work since the update ;)
[09:42] <gnomefreak> :(
[09:42] <Nafallo> gnomefreak: what update?
[09:43] <gnomefreak> for some reason appearance got changed to custom thats why its like that
[09:43] <gnomefreak> Nafallo: the merge yesterday
[09:43] <gnomefreak> Nafallo: you were in #-mozillateam during this topic
[09:43] <Nafallo> gnomefreak: someone merged it? :-(
[09:43] <Nafallo> gnomefreak: just because I am on a channel doesn't mean I'm actively reading it.
[09:44] <gnomefreak> Nafallo: fta said see doko it seems he dropped patches
[09:44] <gnomefreak> one of them fits the error im getting
[09:44]  * Nafallo headdesks
[09:45] <Nafallo> gnomefreak: ehrm. launchpad know nothing of such a merge...
[09:45] <gnomefreak> Nafallo: fontconfig was merged yesterday
[09:45] <ion_> http://heh.fi/tmp/theme
[09:46] <Nafallo> aha. context helps :-)
[09:46] <gnomefreak> Nafallo: https://edge.launchpad.net/ubuntu/intrepid/+source/fontconfig/2.6.0-1ubuntu1
[09:48] <Nafallo> gnomefreak: oki. I'll look in to it later. thanks for telling me.
[09:48] <seb128> bug #243130
[09:48] <gnomefreak> Nafallo: np i think we found issue in it
[09:48] <gnomefreak> seb128: thanks
[09:49] <seb128> there is a patch waiting for sponsoring
[09:50] <Nafallo> thought it would not be gajim's fault :-)
[09:51] <gnomefreak> Nafallo: well so far its the only app that is affected from what i can see
[09:52] <gnomefreak> im sure there is more but i havent found them yet
[10:12] <cjwatson> RAOF: so should I sync gnome-do-plugins or not? if I do, somebody needs to make sure the Replaces is added in intrepid fairly soon; alternatively, feel free to just upload 0.4.0-1ubuntu1 to intrepid with that directly, or we could leave the whole thing until intrepid+1
[10:13] <RAOF> Is there any reason we can't wait for gnome-do-plugins 0.5 to be sorted out in Debian and then sync that?
[10:14] <RAOF> A: Yes.  Because we'll still need to do the Replaces: dance.  I'll upload a 0.4.0-1ubuntu1.
[10:15] <liw> slangasek, the amd64 qemu install is _still_ running, the i386 just finished (was waiting for me to press a key while I slept)
[10:15] <gnomefreak> Seeker`: i was just informed that patch on the fontconfig bug but i didnt personally look at it
[10:16] <MacSlow> If I have make-targets named like "confflags-gnome" in a debian/rules file... does this imply I need to have additional maintainer-scripts for these to properly work?
[10:30] <dholbach> soren: what do I do if I see only "parallel0 console" in KVM?
[10:30] <dholbach> did I press some funky button somewhere?
[10:33] <liw> I have "ATQ0 V1 E1" on qemu's serial0 console
[10:33] <dholbach> I had a desktop some seconds before, now a black screen that just says "parallel0 console"
[10:33] <dholbach> "Send 'ctrl-alt-f<n>'" seems to do nothing
[10:33] <liw> dholbach, ctrl-alt-3 (not f3) takems me to that console in qemu, try ctrl-alt-1
[10:34] <dholbach> ahhhhh!
[10:34] <dholbach> liw: thanks!
[10:34] <liw> these are qemu/kvm consoles, not linux virtual consoles, thus 123 not f1f2f3
[10:34] <liw> dholbach, you're welcome, I was majorly confused by them myself :)
[10:34] <dholbach> yeah
[10:35] <liw> cjwatson, my alpha1 amd64 installation has "You shouldn't call /sbin/grub-install. Please call /usr/sbin/grub-install instead!" on tty4
[10:36] <liw> cjwatson, it's also probing devices and searching for the GRUB installation directory (find /boot/grub), so I guess that was just a warning... but it hasn't finished the grub installation in 12 hours since
[10:40] <cjwatson> RAOF: because we're past the normal merge deadline
[10:40] <cjwatson> RAOF: there's no reason why the Replaces couldn't be added in Debian, FWIW
[10:41] <cjwatson> liw: that warning in itself is definitely a no-op, because it then execs /usr/sbin/grub-install
[10:41] <liw> cjwatson, yeah, I see that from ps output; strace to /usr/sbin/grub isn't showing any output
[10:42] <cjwatson> liw: did i386 work?
[10:42] <liw> cjwatson, I did an encrypted install with i386, and it worked, but I don't know if it uses grub
[10:43] <liw> yes it does
[10:44] <liw> syslog does not indicate that anything interesting has happened since grub found its installation directory... dhclient did a DHCPREQUEST and got an ack
[10:47] <cjwatson> not sure I know what to do, I'm not in a position to do an amd64 test myself I don't think
[10:47] <liw> anything I can do extract more data?
[10:48] <liw> I'll start another test on amd64 in the mean time
[10:48] <cjwatson> an strace -f -s 1024 of the whole of grub-installer wouldn't hurt
[10:49] <cjwatson> easiest way to do that is to go back at the user/password prompt, set the debconf priority to low, and then go on from there, which will let you work through step by step; when you get to just before grub-installer, attach strace to the main-menu process
[10:49] <cjwatson> I'm groping in the dark though, it could be that grub is just busted on amd64 right now ...
[10:50] <liw> no output from that strace either
[10:50] <liw> ah, going back, just a moment
[10:51] <liw> hm, I killed the grub-install process and the installer is now happily finishing the installation
[10:51] <cjwatson> it may well fail to boot
[10:51] <liw> since the process died, shouldn't it have noticed that and treated it as an error?
[10:52] <liw> indeed, boot seems to fail, does not seem to load grub from bios
[10:52] <cjwatson> I'm rather surprised it didn't
[10:53] <cjwatson> I don't see anything obviously wrong in main-menu or di_exec_mangle_status
[10:54] <cjwatson> oh, I suppose it goes through udpkg
[10:55] <liw> it was running from a postinst script, yes
[10:55] <cjwatson> even so, ought to work
[10:55] <cjwatson> unless busybox sh eats the exit status or something
[10:56] <liw> that would be weird of it, but it wouldn't the first time busybox was weird
[10:56] <liw> (I had to create a tail-recursive shell script once, on a box where busybox's while was broken)
[10:57] <cjwatson> anyway, main-menu bug if you like, I'm not going to investigate right now :)
[10:57] <liw> hm, my second attempt at amd64 resulted in an error at the partitioning stage
[10:57] <liw> "EXT3-fs: group descriptors corrupted"
[10:58] <liw> I'm beginning to suspect qemu
[11:04] <liw> and I get that again on another qemu instance, so it's repeatable
[11:36] <davidedmundson> hey, I have a launchpad question, do I ask here or is there a specific launchpad channel?
[11:36] <sistpoty|work> davidedmundson: #launchpad ;)
[11:36] <jpds> davidedmundson: maybe: #launchpad
[11:36] <davidedmundson> probably should have guessed that..
[11:36] <davidedmundson> ta
[11:38] <liw> slangasek, I had to mark the amd64 qemu test install as a failure :(
[12:15] <james_w> is "sambashare" a group that only Ubuntu would care about?
[12:15] <james_w> (i.e. not Debian?)
[12:16] <james_w> also "lpadmin"
[12:21] <liw> debian has lpadmin
[12:21] <liw> probably created by cups
[12:36] <\sh> bryce: do you happen to know if this gnome screen resolution tool also works with an ATI Fire GL graphics adapator? It has only one dvi output but a bridge to attach two screens
[12:36] <\sh> bryce: it detects both screens but doesn't switch to dual screen mode
[12:44] <wgrant> \sh: Sounds like a bug in fglrx...
[12:46] <\sh> wgrant: I just installed fglrx-envy...
[12:51] <\sh> wgrant: failsafe session works...I think it's more compiz
[12:51] <\sh> wgrant: well, not with dual screen
[12:51] <wgrant> \sh: I don't think Compiz interacts at such a low level. It may be that it won't support DRI over such a large area.
[13:06] <\sh> wgrant: ubuntu fglrx driver doesn't support the firegl...
[13:06] <\sh> let's see for envy
[13:24] <ogra> Keybuk, ping
[13:28] <tseliot> ﻿\sh: ﻿the gnome screen resolution tool won't work with the fglrx driver if you're trying to set up multiple screens. The fglrx driver doesn't support RandR 1.2 yet.
[13:31] <\sh> tseliot: I managed to get it with envy drivers...and the amdcccle
[13:32] <tseliot> ﻿\sh: yes, that's the only tool which should work with the fglrx driver.
[13:34] <\sh> well...it worked..after a reboot it doesn't come up anymore :(
[13:35] <emgent> heya tseliot
[13:36] <tseliot> ﻿emgent: hi
[13:37] <tseliot> ﻿\sh: sorry but I'm not an expert with the fglrx driver and multiple screens.
[13:37] <emgent> "pizza? nah.. this is an italian resturant"
[13:38] <tseliot> ﻿emgent: hehe
[13:38] <\sh> tseliot: well, xorg.conf was zero byte ;) because of a crash...praise beta software ;)
[13:40] <tseliot> ﻿\sh: maybe amdcccle should be launched as root (with sudo) in order to write to your xorg.conf
[13:43] <\sh> tseliot: well, yes..but it's crashing when you are in 3d mode on kde4.1beta2 ;)
[13:44] <tseliot> ﻿\sh: heh
[13:47] <ogra> hmm, since scott doesnt seem to be around, and pitti being on vacation today, does anyone know if with dropping the multiuser argument from update-rc.d the versioned dependency on sysv-rc is still needed ?
[14:09] <penfold_99>  is anyone here working on kvm?
[14:10] <dholbach> penfold_99: try #ubuntu-virt
[14:13] <penfold_99> dholbach: -virt look like a ghost town at the mo so i though i would try here
[14:15] <persia> penfold_99: You may find that even the quietest of Ubuntu channels may spark to life with the posting of an interesting question.
[14:16] <Hobbsee> persia: an interesting, *on topic* question
[14:21] <jdstrand> seb128: hi! is there a way to tell gvfs to rescan the network for samba servers? maybe a HUP or something?
[14:23] <seb128> jdstrand: hey, I don't think so, stop gvfs-smb-browse and it'll respawn automatically?
[14:24] <jdstrand> seb128: ok. I'm new to gvfs, and did just discover gvfs-ls too. I'll play around. thanks!
[14:24] <seb128> jdstrand: is that still about this "playing video on smb shares doesn't work correctly"?
[14:24] <jdstrand> seb128: yes
[14:24] <jdstrand> seb128: so far, I can't reproduce it
[14:25] <seb128> jdstrand: hey me neither, I've a NAS and playing videos on it over smb stills work correctly
[14:25] <jdstrand> seb128: does that NAS use vfat?
[14:26] <seb128> jdstrand: I guess so, not sure how to verify though
[14:26] <jdstrand> seb128: it is something off-the-shelf?
[14:27] <jdstrand> seb128: zul tried a bunch of combinations too, and couldn't reproduce it
[14:27] <beDrung> calc & bryce: wohoo! first test show: ooo 1:2.4.1-1ubuntu2~ppa1 works. I will do more testing and report if there are any regressions.
[14:27] <jdstrand> seb128: I did see, tucked away in one of the attached smb.conf files, that a share had a comment of 'vfat hd'
[14:28] <seb128> jdstrand: yes, that's a landrive network disk doing smb and ftp which we have for some years
[14:28] <jdstrand> seb128: so I'm am going to try that too in the off chance it's a filesystem thing
[14:28] <cjwatson> jcastro: would it be possible to get some packages that are really Ubuntu-specific excluded from the upstream report?
[14:29] <cjwatson> jcastro: for example, for ubiquity and ubuntu-meta it usually doesn't make sense to forward bugs upstream because we *are* upstream
[14:30] <jdstrand> seb128: hey sweet, killing gvfsd-smb-browse worked
[14:32] <jcastro> cjwatson: yes that's on the todo
[14:32] <jcastro> cjwatson: same thing with removing all the redundant kernel ones
[14:32] <cjwatson> jcastro: ok, cool - is it just a hardcoded list right now?
[14:32] <jcastro> yeah it's just autogenerated from launchpad and sorted by open bugs
[14:33] <cjwatson> I mean the list of packages that are checked there
[14:33] <cjwatson> oh, right, you mean you just pick the top n packages?
[14:33] <jcastro> right
[14:33] <cjwatson> gotcha
[14:33]  * ogra restates his quesion since there are now more people in the channel ...
[14:33] <cjwatson> jcastro: I would have looked at the Help tab to answer these questions as the page indicates, but there isn't one ;-)
[14:33] <ogra> does anyone know if with dropping the multiuser argument from update-rc.d the versioned dependency on sysv-rc is still needed ?
[14:33] <jcastro> cjwatson: I am in the middle of putting together a list of improvements for improving the report to send to kiko as we speak actually.
[14:34] <jcastro> cjwatson: yeah that's weird, because it used to be there
[14:34] <cjwatson> ogra: I don't believe so, not if the corresponding Debian version doesn't have it
[14:34] <ogra> cjwatson, thanks then i think i'm through with hotkey-setup and we can just sync ...
[14:35] <ogra> (that was a pita ... not synced since ages and tons of changes)
[14:37] <jcastro> cjwatson: feel free to send any more feedback on the report, I've already gotten ideas from asac/seb128 that will make it more useful
[14:39] <seb128> jdstrand: I get the issue now here playing a video on my etch debian gateway over samba
[14:39] <seb128> jdstrand: downgrading libsmbclient 3.0.28a-1ubuntu4.3 to  3.0.28a-1ubuntu4 make it work correclty
[14:39] <calc> beDrung: great :)
[14:40] <seb128> jdstrand: I can get you details if you need some, the server is a running etch and the disk is an ext3
[14:42] <seb128> jdstrand: hum, it still plays fine after upgrading again, weird
[14:44] <seb128> jdstrand: seems to be an authentification issue
[14:44] <jdstrand> seb128: on phone...
[14:44] <seb128> it was still playing correctly after upgrading because it has the authentification still active
[14:44] <seb128> but login doesn't work using the new libsmbclient
[14:45] <seb128> jdstrand: alright, I'm around if you need informations after your call
[14:59] <MacSlow> Keybuk, I just looked at gimp and GTK+... there seems to be no need to merge anything... already done
[15:01] <seb128> MacSlow: I just updated GTK to 2.13 and we are mostly in sync on debian usually, what did you want to change?
[15:02] <MacSlow> seb128, nothing... I just remember Keybuk's comment from yesterdays meeting where he stated that I should also work on merging gimp and gtk... which has obviously happened already before yesterday
[15:03] <seb128> hum, I didn't read a such comment during the meeting
[15:03] <MacSlow> seb128, like you said... you worked on GTK yourself
[15:03] <seb128> right
[15:07] <MacSlow> seb128, ah... found it... it was from the meeting last week... -> https://wiki.ubuntu.com/DesktopTeam/Meeting/2008-06-19
[15:08] <MacSlow> seb128, the exact list of apps I should merge wasn't stated... for some reason I still had that in the back of my head.
[15:10] <superm1> lamont, elmo , infinity : I have a package that needs to be overridden in p-a-s.  I was referred to one of you to handle it when you get a moment.  The package is coreavc, and it should only build on i386, lpia, and amd64.
[15:11] <lamont> superm1: email is the right way to request that
[15:11] <superm1> lamont, okay.  sorry, wasn't aware of proper procedure
[15:13] <lamont> no worries - finding the file is generally the challenge people have :-)
[15:26] <ion_> Wow. system-config-printer in Intrepid is neat.
[15:42] <geser> mvo: I'm looking why my pbuilder with gdebi tries to install recommends, have you an idea how to get gdebi --apt-line --root ... not list the recommends?
[15:49] <zul> jcastro: ping can you add openldap's its (http://www.openldap.org/its) to your upstream bug list for launchpad. It uses a hacked version of jitterbug
[15:57] <mvo> geser: there is currently no direct support for this, easiest is problably to add "APT::Install-Recommends "false"; to /etc/apt/apt.conf in the pbuilder chroot
[15:57]  * mvo needs to fix that
[16:02] <geser> mvo: I've already tried that
[16:02] <geser> mvo: have you an idea why I get different output depending if I call gdebi from outside the pbuilder (with --root) and from inside? see http://paste.ubuntu.com/23318/
[16:04] <geser> hmm, looks like gdebi takes the apt config from the "host" if called with --root and not the one from the chroot
[16:05] <jdstrand> seb128: hey (long call)-- how is the etch share setup in smb.conf? is there a way to get gvfs to forget it authentication (like the gvfs-samba-browse thing you told me about before)?
[16:05] <mvo> geser: yeah, that sounds like it - that is a bug, could you please file it?
[16:10] <jdstrand> mvo: hi! so I see that apt.conf has the ability to do https, can it also do http basic auth?
[16:10] <seb128> jdstrand: totem is not using gvfs
[16:11] <seb128> jdstrand: not sure, maybe restart gnome-keyring, though if you don't select the option to use this one it should not do it
[16:12] <seb128> jdstrand: the samba server is using security = user and a classic share
[16:12] <seb128> [share]
[16:12] <seb128> comment =
[16:12] <seb128> path = somedir
[16:12] <seb128> guest ok = no
[16:12] <seb128> and I'm using my user login and password to connect
[16:14] <jdstrand> seb128: cool, I check it at and let you know
[16:14] <jdstrand> s/I/I'll/
[16:14] <geser> mvo: filed as bug #243550
[16:15] <mvo> geser: thanks!
[16:18] <jcastro> zul: I don't think lp supports that bug tracker.
[16:18] <zul> jcastro: is there a way to get support added?
[16:18] <jcastro> yeah, I'll need to file a bug with the lp team
[16:19] <jcastro> zul: there's a few projects where we don't have bugtracker support, like CUPS(!) and some other not-so-pupular bug trackers.
[16:19] <zul> jcastro: hmm ok thanks
[16:20] <jcastro> zul: I'll bug someone about adding support. :D
[16:22] <jcastro> zul: looks like a fix was commited for mysql/php bugtracker though
[16:22] <zul> jcastro: sweet :)
[16:42] <jcastro> MacSlow: thanks for your report, I got it all in!
[16:52] <seb128> jdstrand: I can do debugging on the samba issue if required
[17:02] <jdstrand> seb128: thanks. I really want to see if it was a -security update, or the -updates package. -updates came out right before I started on the -security update, so it isn't clear what introduced the problem
[17:02] <jdstrand> (I patched -updates for -security, as per our policy)
[17:18] <beDrung> calc: your ooo version works without any problems on all machines i have tested it. so thumbs up. ooo can go to -proposed
[17:34] <hmuller> Why is it that -lm is not necessary on the gcc command line, when functions from math.h are included?  I've tried ##c and #gcc to no avail.
[17:35] <jdstrand> seb128, zul: well, I still can't reproduce it with a gutsy server, using security = user and the 'classic share'
[17:36] <jdstrand> this is with gutsy and hardy clients
[17:36] <zul> jdstrand: the original bug report was for dapper wasnt it?
[17:36] <jdstrand> zul: dapper server, hardy client. but people have said dapper, gutsy, hardy servers and gutsy and hardy clients
[17:36] <jdstrand> zul: it's just all over the place
[17:37] <zul> jdstrand: yeah that bug report is a mess
[17:38] <jdstrand> zul, I'm going to start focusing on hardy server and clients. I've posted more info in the bug, maybe I'll get more details
[17:39] <zul> jdong: cool
[17:39] <zul> jdstrand: cool
[17:40] <seb128> jdstrand: I rebuilt without the security change, installed the libsmbclient only and that fixes the issue
[17:41] <jdstrand> seb128: so you removed *just* security-CVE-2008-1105.patch and it works?
[17:41] <seb128> yes
[17:41] <jdstrand> seb128: ok, that helps, but I still can't reproduce it locally. can you paste your smb.conf file?
[17:42] <jdstrand> seb128: and are you just using a location of smb://foo/share/file from totem?
[17:42] <jdstrand> s/from/in/
[17:43] <seb128> yes
[17:43] <seb128> I'm calling "totem smb://...." on the command line rather
[17:45] <jdstrand> seb128: are the perms on the file 744 for the file you are accessing (owned by same user as one accessing the share)?
[17:45] <jdstrand> btw, totem smb://... works just fine
[17:46] <seb128> jdstrand: the file 744 owned by an another user
[17:47] <jdstrand> seb128: ok, both work here
[17:47] <seb128> changing the owner to the user makes no difference
[17:47] <jdstrand> seb128: no, here either, just trying to make sure we have the same environment
[17:48] <jdstrand> seb128: do you have the smb.conf file handy?
[17:48] <seb128> jdstrand: sec
[17:49] <pwnguin> ok this is wierd. firefox wants to save a php file when i post a comment on sabdfl's blog =(
[17:50] <kees> seb128: can I pick your brain about tracing a signal connect callback?  I'm not clear where an argument is coming from...
[17:52] <seb128> kees: I've to run in a few minutes but if that's quick I can have a look, tell me about it ;-)
[17:53] <kees> seb128: it's between rhythmbox and totem-pl-parser.  let me paste context
[17:54] <kees> seb128: http://pastebin.osuosl.org/8792
[17:54] <kees> where does "metadata" come from?
[17:55] <kees> I don't see it in the g_signal_connect_object, and the signal definition seems to think it only takes a string?
[17:58] <kees> seb128: oh, nevermind.  I think this is a straight up crasher -- I can't even load _valid_ .pls files.
[18:02] <seb128> kees: ok, didn't look yet, I'm busy on this samba thing and I've to run
[18:27] <calc> beDrung: thanks! :)
[18:37] <calc> slangasek: i have an update for OOo for hardy
[18:37] <calc> slangasek: is it safe to stick it in -proposed or do i need to hold it off a bit
[18:38] <calc> it fixes a crasher bug on gnome/kde
[18:42] <slangasek> calc: doesn't hurt (me) to upload and have it sit in the queue
[18:42] <slangasek> calc: how about bug #220817 along the way?
[18:44] <calc> slangasek: ah yea i should fix that too :)
[18:45] <calc> slangasek: looks like the updates to ooo-build fix at least 3 crashes and fixes amd64 plugin (not sure if we should actually enable building that for a update though)
[18:45] <calc> both the gnome/kde crashes and a svg crash as well
[18:49] <slangasek> no, you shouldn't enable building something in an update that wasn't being built before
[18:52] <calc> ok i'll leave that turned off then
[18:58] <sbeattie> is it intended for post 8.04.1 release?
[19:09] <ogra> cr3, you said your testing of the nsc/geode changes was successfull, didnt you ?
[19:09] <ogra> (we need a comment on the SRU bug)
[19:20] <calc> sbeattie: i guess, it is important but doesn't have to be on the disks
[19:21] <calc> sbeattie: a large number of users (other than myself) under gnome and kde have OOo crash on them, i never was able to reproduce it but i found a patch for it in ooo-build and got an affected user to test it and it works
[19:22] <cr3> ogra: crap, komputes didn't append to the bug? I'll do it for him, one moment...
[19:23] <sbeattie> calc: okay, when it comes through, I'll try to prioritze verifying it.
[19:23] <calc> how do you escape a space using scp?
[19:23] <calc> i'm trying to copy with a space in the filename across the network using scp
[19:23] <ogra> cr3, bug 219630
[19:24] <calc> ah you have to quote and \\ escape it
[19:24] <calc> thats just weird
[19:25] <cr3> ogra: done
[19:26] <ogra> erci
[19:26] <ogra> *merci even
[19:26]  * ogra hugs cr3 
[19:26] <cr3> ogra: right back at ya!
[19:26] <calc> sbeattie: i'll try to get it uploaded by tomorrow
[19:27] <calc> i need to track down the bugs to mark and update the changelog entries, etc
[19:28] <calc> and need to fix and verify the language support bug is actually fixed
[19:57] <slangasek> cr3: bug #219630 - you mentioned using xserver-xorg-video-nsc 1:2.8.3-2ubuntu3.3 successfully, which I guess was an intrepid-only upload - so that comment was just for comparison?
[19:58] <cr3> slangasek: yes, I believe q-funk had provided that driver for testing purposes a little while ago before updates made their way to hardy-proposed
[19:59] <slangasek> cr3: right; only minimally germane to the SRU validation, for which we need tests with the actual hardy-proposed packages (which you've also done, thank you :)
[20:06] <pgib> Hello.  I am a developer for the program LMMS.  (Which is already included in universe)  we are about to release an alpha of the next major release.
[20:06] <pgib> how do I get in touch with the MOTU maintainer for LMMS?
[20:06] <Pici> pgib: #ubuntu-motu
[20:06] <pgib> OK. thanks.
[20:06] <Pici> Which I why I asked what you were looking for ;)
[20:06] <pgib> hm?
[20:07] <Pici> Before, in #ubuntu, but nevermind.
[20:07] <pgib> ah ok - I missed it
[20:08] <pgib> tha channel is _very_ busy
[20:13] <jdstrand> hi slangasek! Would you mind peeking at #241448 and letting me know if I missed anything. seb128 was able to reproduce it with an etch server and hardy client, but I cannot with many different combinations.
[20:17] <slangasek> jdstrand: I think I already tried to reproduce that myself and failed to do so
[20:18] <jdstrand> slangasek: interestingly, seb128 was able to reproduce it with an etch server and hardy client
[20:18] <slangasek> mmmmkay
[20:19] <jdstrand> slangasek: he gave me his smb.conf-- nothing out of the ordinary, except 'security = user'
[20:19] <slangasek> that's not out of the ordinary either, it's the default
[20:19] <jdstrand> I tried with it (well, with path adjustments) and it works fine (on feisty server-- same version as etch)
[20:20] <jdstrand> slangasek: people mentioned DivX 4/5-- tried with different ones, no problems
[20:21] <slangasek> I can't imagine how the codec should make any difference
[20:21] <jdstrand> slangasek: I don't have a large (ie movie length) DivX around, but wonder why file size would be an issue (1 1.7GB MPEG-2 worked fine btw)
[20:21] <jdstrand> slangasek: he did say removing the CVE-2008-1105 from samba and just installing libsmbclient from that build seemed to fix it...
[20:22] <jdstrand> s/CVE-2008-1105/patch for CVE-2008-1105/
[20:22] <jdstrand> anyhoo, it's a mystery to me
[20:24] <slangasek> jdstrand: er, very strange
[20:24] <jdstrand> totally. well, I pushed it back on the user's asking for more info. hopefully something useful will come up
[20:24] <jdstrand> slangasek: thanks
[20:26] <jdstrand> s/user's/users/
[21:13] <slangasek> cody-somerville: hi, have you or anyone else on the xubuntu team had a chance to test out the alpha-1 candidate images?
[21:14] <calc> wow this was easy to fix
[21:14] <calc> it was actually already supposed to be fixed but i managed to break it with the ubuntu changes
[21:16] <sistpoty> slangasek: should bug #184218 still be fixed in hardy? (if so I might make use of my new core-dev powers, or criticize the debdiff *g*()
[21:19] <slangasek> sistpoty: I think that's below the threshold of bugs worth bothering about
[21:20] <sistpoty> slangasek: ok, thanks... could you decline the nomination then?
[21:21] <slangasek> sistpoty: once a nomination's been accepted, "decline the nomination" == "mark the hardy task 'wontfix'"
[21:21] <slangasek> sistpoty: so you're welcome to do this yourself :)
[21:21] <cody-somerville> slangasek, some people are testing right now but I didn't get a chance to upload that SRU we discussed earlier this week
[21:22] <slangasek> cody-somerville: SRU's aren't relevant to alpha-1
[21:22] <cody-somerville> slangasek, oh, alpha-1
[21:22] <slangasek> cody-somerville: is anyone testing alpha-1, or just 8.04.1?
[21:22] <cody-somerville> slangasek, I'm downloading alpha-1 right now
[21:22] <slangasek> ok, cool
[21:22] <sistpoty> slangasek: ah... I thought you'd have the option to reject it (iirc I'm seeing this for nominations of universe)
[21:23] <slangasek> sistpoty: you can only reject a nomination before it's been accepted; this is a UI blemish that we discussed with kiko in Prague
[21:24] <sistpoty> slangasek: ah, thanks for the info
[21:31] <jdstrand> kirkland: so thinking about sessions counters and pam_ecryptfs, if a user logs in and the counter is incremented, then hits ctrl+alt+backspace, what happens? either it works right, or the counter doesn't decrement and we can never get the auto unmount until reboot
[21:31] <jdstrand> I'm just thinking OTOH here
[21:32] <kirkland> jdstrand: i would hope that ctrl-alt-backspace would trigger a session close
[21:32] <kirkland> jdstrand: a generic pam session close, in which case my decrement counter code would run
[21:32] <kirkland> jdstrand: i haven't tested that yet, of course
[21:32] <jdstrand> kirkland: I would hope so too, but it illustrates my line of thinking that the counters, if implemented, would have to be very robust
[21:33] <jdstrand> not that you wouldn't make it robust mind ;)
[21:33] <kirkland> jdstrand: tbh, i've been testing login/ssh heavily in my kvms.... not yet gotten to anything graphical
[21:33] <jdstrand> kirkland: btw, how does it handle multiple logins?
[21:34] <kirkland> jdstrand: mount.ecryptfs_private notices that it's already mounted and exits gracefully
[21:34]  * jdstrand nods
[21:35] <jdstrand> kirkland: could have a little daemon that polls
[21:35] <kirkland> jdstrand: hmm, i think i have an interim solution.........
[21:35] <jdstrand> ecryptfsd
[21:35] <kirkland> jdstrand: there is an ecryptfsd already, but i'm trying to avoid using it
[21:36] <kirkland> jdstrand: here's what i think i'm going to implement for now....
[21:36] <jdstrand> kirkland: does it server this function?
[21:36] <jdstrand> serve
[21:36] <kirkland> jdstrand: no, it's for advanced key management
[21:36] <kirkland> jdstrand: stuff we're not yet using, openssl, public keys, TPM chips
[21:36]  * jdstrand nods
[21:37] <kirkland> okay, so here's what i'm going to do by end of day, so that I can leave this in a functional state.....
[21:37] <kirkland> jdstrand: pam_session_close will unmount the ~/Private directory
[21:37] <kirkland> jdstrand: which might potentially unmount it while other instances of the user are still logged on
[21:38] <kirkland> jdstrand: perhaps inconvenient, but erring on the side of protecting the user's encrypted data....
[21:38] <kirkland> jdstrand: okay, so the UNMOUNTed mountpoint, ~/Private is currently permed 500 (to keep from inadvertently writing data to it)
[21:38] <jdstrand> kirkland: you may run into errors if the user is accessing it at the time of unmount
[21:38] <kirkland> jdstrand: and there's a file in there called....
[21:39] <kirkland> "NOT MOUNTED - Run mount.ecryptfs_private to mount this directory"
[21:39] <kirkland> jdstrand: i'm going to make that a symlink to "mount.ecryptfs_private"
[21:39] <jdstrand> kirkland: a side-step is not to support console or ssh at all yet, and add the pam stuff to gdm
[21:39] <kirkland> jdstrand: ooh, bad.... then i get even more questions as to "why are you working on this?  aren't you on the server team?"
[21:40] <kirkland> jdstrand: nah, it really, really, really belongs in PAM
[21:40] <jdstrand> heh-- well, yes
[21:40] <kirkland> jdstrand: i think i can convince you of that
[21:40] <kirkland> jdstrand: any way.....
[21:40] <jdstrand> kirkland: no, /etc/pam.d/gdm
[21:40] <kirkland> jdstrand: oh,
[21:41] <kirkland> jdstrand: hmm, perhaps....
[21:41] <jdstrand> not *in* gdm, but in the pam stuff for gdm
[21:41] <kirkland> jdstrand: anyway, doing what I described above 1) unmounts, erring on the side of protecting user data, 2) provides an easy mechanism to re-mount (the instructional symlink) for users still logged in
[21:41] <jdstrand> anyhoo-- point taken on server-- I was just thinking of an easy way to get you out of here before your vacation
[21:42] <kirkland> jdstrand: actually, i'm pretty happy with that (1) (2) punch for now.
[21:42] <calc> slangasek: i have a update ready, just working on getting the changelog in shape
[21:43] <calc> slangasek: i have to leave in a bit to help my father build his new pc, but should be able to get the upload done by the end of the night
[21:43]  * slangasek nods
[21:43] <jdstrand> kirkland: sure, it woks fine for the next week or so. it's less than user-friendly in the long run, but you obviously know that :)
[21:43] <kirkland> jdstrand: yup
[21:44] <kirkland> jdstrand: i'm afraid i'm going to need some user accounting gurus to help out here
[21:44] <slangasek> calc: ok.  I'll plan to do a full ISO run before accepting OOo in any case, so that we have as current as possible of images if it fails validation.
[21:44] <kirkland> jdstrand: after i'm back
[21:44] <calc> slangasek: ok sounds good
[21:46] <jdstrand> kirkland: actually, this instructional filename is interesting. I'm not sure how it will fly with platform (eg cjwatson), but if you define your entry points as anything using common-auth, then if people are doing something outside of that, and it's not mounted, then they get the helpful message
[21:46] <jdstrand> kirkland: of course, it kinda blows up if the user removes the file
[21:46] <kirkland> jdstrand: that dir is permed 500
[21:46] <calc> if i want to reference a bug that i am explicitly not fixing in the upload if i just do something like Bug: #foo that won't mark it fixed right?
[21:46] <calc> only if i do LP: #foo does it close it?
[21:46] <kirkland> jdstrand: so it would take a very conscious effort to blow away that file
[21:47] <kirkland> jdstrand: ie, you'd have to +w it, then rm it
[21:47] <jdstrand> kirkland: I *might* be able to swing that, personally ;)
[21:47] <ScottK> calc: To the extent Launchpad's actual behavior matches the documentation, yes.
[21:47]  * calc is referencing that a patch will fix the firefox plugin when rebuilt for intrepid
[21:47] <jdstrand> kirkland: sure
[21:47] <sistpoty> calc: I'm usually using LP: <number> (instead of LP: #<number>) when doing so
[21:47] <kirkland> jdstrand: what i like about symlinking it to the executable is that a user can just double-click in a Nautilus/GUI environment
[21:48] <kirkland> jdstrand: or run it in a CLI
[21:48] <jdstrand> kirkland: it's an interesting idea
[21:48]  * calc is having a hard time tracking down the bug number in any case
[21:48] <sistpoty> poor calc
[21:48] <jdstrand> kirkland: there is the problem of if they click it that way, it is no longer 'counted', but it is 'mounted'
[21:49] <kirkland> jdstrand: i'm ditching the counting all together for now
[21:49] <jdstrand> kirkland: and if you did increment there, which is easy enough, how will you decrement?
[21:49] <kirkland> jdstrand: i have to think that out "robustly"
[21:49]  * calc might have done something dumb like accidentally close the bug
[21:49] <kirkland> jdstrand: there's some code in libpam-mount that sort of does this
[21:49] <kirkland> jdstrand: badly, in my experience, i might add
[21:50] <jdstrand> kirkland: yeah, clearly your current path is good for the short term
[21:50] <kirkland> jdstrand: it uses something called pmvarrun
[21:51] <kirkland> jdstrand: i could make the file name even more descriptive...  "This directory has been unmounted in order to protect your data.  Yadda yadda"  :-)
[21:52] <jdstrand> kirkland: getting back to my daemon idea-- it could be setup to automatically unmount after a while. this coupled with your symlink idea (or maybe something else) might be interesting.
[21:53]  * jdstrand notes that it is surprising how complicated this little problem is
[21:53] <kirkland> jdstrand: yeah, that's a good idea
[21:53] <kirkland> jdstrand: i like the idea of a timeout
[21:54] <calc> is anyone else having timeout problems to bugs.l.n
[21:54] <gpocentek> calc: yes
[21:54] <kirkland> jdstrand: like a screensaver, but for your encrypted data
[21:54] <jdstrand> kirkland: oh nice analogy
[21:54] <calc> gpocentek: glad it isn't just me :)
[21:55] <jdstrand> calc: awfully slow here
[21:55] <jdstrand> calc: it did make it though
[21:55] <calc> jdstrand: it realized i am preparing a ooo upload and went down :)
[21:55] <jdstrand> calc: it is bracing itself
[21:56] <jdstrand> lp takes a deep breath, then... 'ok go!'
[21:57] <ScottK> calc: Your route to launchpad.net doesn't happen to go through iad8.alter.net does it?
[21:57] <kirkland> jdstrand: ln -s /sbin/mount.ecryptfs_private "$MOUNTPOINT"/"THIS DIRECTORY HAS BEEN UNMOUNTED TO PROTECT YOUR DATA --  Run mount.ecryptfs_private to mount again"
[21:58] <kirkland> jdstrand: that'll hold for now ;-)
[21:58] <slangasek> liw, cjwatson, soren: so if we're having issues with intrepid not booting as a guest in KVM, does it make sense to include jeos in alpha-1?  I guess VMWare is also a target for this, so if we tested it there it'd be good to inclued?
[21:58] <slangasek> include
[21:58] <calc> ScottK: no level3 the whole way
[21:58] <calc> ScottK: well once it leaves att anyway
[21:58] <ScottK> OK.  I'm having trouble reaching launchpad too, but it seems packets are getting eaten in there.
[21:58] <calc> its working for me again
[21:59] <liw> slangasek, I don't know what the intrepid/KVM issues are (soren?), but if it doesn't work, then it's not really useful to include jeos, imho
[21:59] <slangasek> liw, cjwatson, soren: oh, it looks like linux-image-virtual is also still a casualty of the kernel reorg, right; ignore me, marking jeos off as "not-for-us"
[21:59] <mpt> kirkland, the instructional filename thing reminds me of "Where are all the files?", which is a small text file that appears if an HFS+ volume is mounted as HFS
[21:59]  * ScottK too.
[21:59] <kirkland> mpt: is that a good think or a bad thing?
[21:59] <slangasek> liw: well, we don't even have the JeOS kernel in intrepid right now, so. :)
[21:59]  * kirkland ducks and covers?
[21:59] <liw> instructional filename?
[21:59] <mpt> kirkland, neither, just a possibly useful precedent
[21:59] <liw> slangasek, kernels are overrated
[21:59] <kirkland> mpt: ah, cool, good to know....
[22:00] <kirkland> mpt: what about symlinking such a file to a script/program that can solve the problem for you?
[22:00] <slangasek> liw: kernels in general, or the Linux kernel in particular :)
[22:00] <kirkland> mpt: that's the one step farther I'm trying to go with this (as a short term, stop gap solution, until we get the rest of the interface business in place)
[22:00] <slangasek> ?
[22:00] <bryce> slangasek: hey, I've got a patch ready for testing on the amd issue
[22:00] <ogra> liw, hmm ? how would you modprobe gnome without a kernel
[22:01] <liw> slangasek, any kernel, we could reduce _so_ much bloat if we had custom-written I/O routines in ASM for each application
[22:01] <slangasek> bryce: am I going to claw my eyes out when I see it? :)
[22:01]  * liw needs to go to bed soon, /me thinks
[22:01] <ogra> slangasek, its pretty sweet ...
[22:01] <mpt> kirkland, that seems like a grand idea to me. Bonus points if you can avoid using the words "mount" or "unmount" :-)
[22:02] <bryce> slangasek: I posed the patch itself to #219630, and am uploading x86 debs for testing here:  http://people.ubuntu.com/~bryce/Testing/geode/
[22:02] <kirkland> mpt: :-)  let me see what I can do!
[22:02] <slangasek> liw: ah yes, TorvalDOS
[22:02] <bryce> slangasek: actually there was very similar code for dealing with ati/atimisc conflicts
[22:03] <slangasek> bryce: hmm, then couldn't this have been done in the same for loop? :)
[22:03] <bryce> slangasek: I tried that initially, but notice that it returns rather than breaks, since it assumes there's only one driver
[22:04] <bryce> if I were to commit this upstream, yeah I'd want to rework that loop so both things can be taken into account
[22:04] <bryce> however keeping it separate I figure makes the patch easier to review/understand
[22:05] <ion_> linux-...-generic in intrepid fails to boot on my 586 laptop because it’s missing cmov. (Will report a bit later.)
[22:06] <slangasek> bryce: well, I don't notice that because the diff doesn't provide that much context :-)
[22:06] <slangasek> ion_: is this a new development? I would have expected cmov to be the baseline for -generic already, and cmovless 586 would need -386
[22:08] <ion_> slangasek: I wouldn’t mind installing -386 if it existed. ;-) I assumed it had been merged to -generic or something. Anyway, i’ve been using hardy -generic without any problem whatsoever in the past.
[22:11] <ion_> If a -386 kernel’s going to be built in the future, i’ll manage with the hardy kernel until that time.
[22:14] <ogra> iirc rtg's plan was to move 386 to universe
[22:14] <ogra> which makes it indeed hard if you need it in the installer
[22:15] <ion_> Heh, indeed.
[22:16]  * ogra just remembers the issue because he was asked about ltsp .... where it doesnt matter if the kernel comes from universe since its netbooting 
[22:18] <ogra> ion_, so, the easy fix is to make your laptop a thin client ... and yu will even have a spare disk then
[22:20] <ion_> ogra: Heh, i wouldn’t mind doing that if i had something to use as a server for said thin client. My desktop box barely handles a single session. :-) I could consider stopping using Gnome, of course...
[22:20] <ogra> well, ltsp runs the session on the server :)
[22:21] <ion_> That’s what i meant, my desktop box isn’t fit to run two sessions simultaneously, unless i make the session more lightweight. I might do that.
[22:22] <ogra> ah, well, gnome cant handle that anyway ... you would have to log out the local user
[22:22] <ion_> Yeah, that, too. :-\
[22:22] <ogra> (at least two times with the same user doesnt work)
[22:23] <ion_> Yeah, i’d want to use the same user and the same session both locally and remotely.
[22:23] <ion_> Read: identical session
[22:24] <ion_> Oh, and firefox doesn’t handle that very well either, unless that’s been fixed. :-\
[22:24] <ogra> yep
[22:24] <ogra> same for openoffice
[22:24] <ion_> For “Office” purposes, i mostly use LyX and Gnumeric.
[22:25]  * ogra doesnt have such "purposes" .... only mail attachments he need to open :)
[22:26] <ion_> Oh well, i could just run xlinks2 in the remote session, that’s what i’m doing on the laptop anyway. It would choke with Firefox. :-)
[22:32] <hunger> Is debian import freeze in effect or was it postponed?
[22:34] <ScottK> Autosync has been run for that last time.  Other than that it really has no effect.
[22:35] <hunger> ScottK: Thanks for the info. I was getting afraid that git-core will not get updated this release cycle:-)
[22:36] <bryce> hunger: I'm sure an exception would be allowed for that
[22:36] <ScottK> All it takes is a developer to deal with it.
[22:37] <ScottK> I'm fairly certain I don't want to be touched it last on Git.
[22:37] <hunger> ScottK: Well, it is not compatible with svn 1.5, so it will probably take a new git release to make both updates possible.
[22:38] <hunger> ... at least I could not build git-core with the subversion backport I have installed.
[23:01] <slangasek> bryce: so this xorg -configure fix is only in your people repo now?
[23:02] <slangasek> bryce: I think we should go ahead with pushing it to -proposed, both to move up the timeline and to make it easier for users to test
[23:04] <bryce> slangasek: alright, I'll put it in hardy-proposed
[23:06] <bryce> slangasek: ok uploading now
[23:06] <slangasek> thx
[23:21] <slangasek> cody-somerville: alpha-1 downloaded ok, or still downloading?
[23:22] <cody-somerville> slangasek, I'm finishing some stuff up for work atm. When do you need it tested by? I thought Alpha 1 was not until July 10th.
[23:22] <slangasek> no, that's alpha 2...
[23:22] <slangasek> alpha 1 is today, with whatever we can manage to get out