[00:16] <slangasek> doko_: since you did the merge of directfb, and deliberately re-enabled the build-dep on libts-dev, does that mean you're approving this as an MIR? :)
[00:31] <slangasek> soren: is bug #196850 fixed in intrepid, or is it still just "Committed" somewhere?
[00:57] <slangasek> pitti: do you happen to recall why you marked bug #229499 as 'fix committed' for intrepid?
[01:34] <slangasek> jelmer: so, er, is there really no better way to tell the difference between a directory and a file in svn than trying to get a list of files within it?
[01:34] <slangasek> jelmer: (I say, having had to nuke my cache of the pkg-samba repo and now watching the wheels spin again while it repopulates)
[01:35] <slangasek> maybe there is a better way, and you're using it in the newer version of bzr-svn, and I'm just annoying you with my questions :)
[01:36] <emgent> moin
[02:28] <slangasek> zul: grmbl; there's a new samba 3.2.0-4 that'll need merged, brown-paper bag bug in -3
[02:29] <zul> slangasek: yep saw the commit Ill do it first thing tomorrow when I get downtown
[02:29] <slangasek> zul: ok, cheers
[04:34] <Awsoonn> hi all, I am wondering if there are some helpful souls here that might mentor me in fixing a simple bug
[04:35] <Awsoonn> bug 250681 is simple enough, I apt-get source irssi
[04:35] <Awsoonn> found the string that needs changing
[04:36] <Awsoonn> changed it, but now what should I do? I think I need to make a deb diff or something right?
[04:37]  * Awsoonn wants to learn the ropes
[04:38] <Awsoonn> when I got the source, it came with a diff.gz; do I need to apply that to the source first? So many questions for you guys
[04:41] <ogra> Awsoonn, try #ubuntu-motu, they can point you to the right docs and info
[04:41] <Awsoonn> ogra: TY
[05:17] <superm1> slangasek, god you were right about that debian maintainer for libsmbios
[05:17] <superm1> slangasek, would you mind chiming in on debian bug 491795?
[05:18] <slangasek> superm1: hrm, I thought I was careful to say very little that I could be right about ;)
[05:18] <superm1> slangasek, well just hard headed about things
[05:19] <superm1> along the lines of "its not broke yet in debian because we havent switched to a newer libtool, and this is the way it should be done"
[05:31] <slangasek> superm1: I think I'm lacking the necessary patience to deal with that tonight; maybe tomorrow...
[06:45] <soren> slangasek: re bug 196850: It certainly should be fix released. Thanks for the pointer.
[07:15] <pitti> Good morning
[07:16] <pitti> slangasek: I thought if the fix was available for hardy, it could be uploaded to intrepid, too; nothing particular beyond that
[07:17] <StevenK> pitti: Mind casting your eye over https://bugs.edge.launchpad.net/ubuntu/+source/policykit/+bug/250619 ?
[07:20] <pitti> StevenK: I totally agree to that
[07:22] <pitti> StevenK: please upload if you want, otherwise I'll do it later (I have to leave for a bit)
[07:22] <StevenK> pitti: Happy to upload the patch, just wanted you to check it first.
[08:05] <nxvl> pitti: around?
[08:56] <Wubbbi> mvo: I have added you as a Subscriber for the bug 249850 ... is that ok? :)
[09:26] <pitti> hi nxvl
[09:26] <seb128> where is scott when you need him ;-)
[09:27] <fabbione> hey guys
[09:27] <fabbione> how is life in Ubuntu land?
[09:27]  * pitti hugs fabbione
[09:27] <pitti> Padre!
[09:27]  * fabbione hugs pitti
[09:27] <seb128> hey fabbione, good!
[09:27] <pitti> very intrepid
[09:27] <fabbione> seb128: hey Mr. Gnome :)
[09:27] <fabbione> pitti: ehehe
[09:29]  * fabbione grrrrs at linux-libc-dev
[09:35] <pitti> superm1: does hal need a fix in bug 189814?
[09:40] <pitti> bryce, tjaalton: WDYT about http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=66fb253082ea42179180303393e48846208987fa ? I think that makes sense, although it was reverted again upstream
[09:56] <tseliot> mvo: please ping me when you want to solve the problem with Update Manager and the NVIDIA drivers in Intrepid. There's a Python module ready for this.
[09:59] <mvo> tseliot: lets do it now, where can I see the python module? do we have a bugnumber or something as a reference?
[10:00] <tseliot> mvo: install nvidia-common from this PPA: https://launchpad.net/~lrm-intrepid/+archive
[10:00]  * tseliot looks for the bugreport
[10:03] <tseliot> mvo: maybe this one: https://bugs.edge.launchpad.net/ubuntu/+source/update-manager/+bug/249329
[10:03] <mvo> tseliot: NvidiaDetector ?
[10:04] <tseliot> mvo: yes
[10:05] <tseliot> mvo: it detects drivers with an old name scheme (e.g. nvidia-glx, -new, etc.), does hardware detection and returns the name of the driver to install
[10:06] <mvo> tseliot: ok, so the old names go away complettely?
[10:06] <tseliot> mvo: yes, there are only nvidia-glx-177, nvidia-glx-173, nvidia-glx-96, nvidia-glx-71
[10:07] <mvo> tseliot: ok, excellent
[10:07] <tseliot> mvo: you might have to change your blacklist too
[10:07] <mvo> tseliot: I start with removing the old names from the removal blacklist
[10:08] <mvo> tseliot: is there any package level (via transitional packages or anything like this) transition going on for the hardy->intrepid upgrade?
[10:08] <pitti> tseliot: I'll try and adapt the jockey nvidia handler for the new packages today/tomorrow
[10:09] <tseliot> pitti: great, let me know if you need help with Jockey
[10:09] <pitti> tseliot: the -modalias packages have the package names now? If so, then this should be straightforward (takes some programming, though)
[10:10] <tseliot> mvo: no, since supported hardware has changed too much. This is why we rely on both the Debconf warning in nvidia-common and on Update Manager to select and install the right driver for the card.
[10:10] <tseliot> pitti: yes, they do
[10:13] <tseliot> mvo: if you read here: http://albertomilone.com/wordpress/?p=212 where it says "How does nvidia-common work?" you will see how the Debconf check will work if users decide to dist-upgrade from the command line instead of using Update Manager
[10:13] <mvo> tseliot: ok. when do you think will nvidia-common arrive in the archive? I need to build-dep on it than because the release-upgrader will have to ship a copy of the dection code
[10:14] <tseliot> mvo: I don't have upload privileges. I think nvidia-common is ready though
[10:14] <tseliot> pitti: thoughts on this?
[10:15] <mvo> its a new package so it has to go through pitti review anyway :) (or mathiases)
[10:15] <pitti> tseliot: last time I looked at it it was fairly ok (see my email response); I didn't test it personlly , though
[10:15] <pitti> but since this is blocking both of you now, I'll review/upload/NEW it right now
[10:15] <pitti> tseliot: lrm-intrepid PPA?
[10:15] <tseliot> pitti: yes, it's there
[10:16] <pitti> Show files  nvidia-common - 0.1-0ubuntu12  ?
[10:16] <pitti> tseliot: hm, I guess I can just check it out of bzr somewhere?
[10:17] <tseliot> pitti: you can get the latest (ubuntu12). I haven't set up a bzr branch yet
[10:17] <pitti> ok, fine
[10:18] <pitti> tseliot: hm, the diff.gz has patches, how weird :)
[10:18] <pitti> tseliot: I guess it should be pretty much a native package for now
[10:18] <pitti> tseliot: can I give you some review comments right here, or do you want an email?
[10:18] <tseliot> mvo: it will be sufficient to make an object of the NvidiaDetection class without any parameter. This should return either None (if no compatible driver can be found) or the name of the appropriate package
[10:19] <tseliot> pitti: maybe an email would be better. Thanks
[10:22] <mvo> tseliot: I just looked at it, does it require stuff in /usr/share/jockey/modaliases/ that is not yet in intrepid? for me that dir does not contain a lot (but my intrepid is not fully up-to-date)
[10:22] <tseliot> mvo: if you install nvidia-common and its dependencies (which are currently in multiverse in Intrepid) then it will be ok
[10:22] <mvo> tseliot: basicly I need to ship those files that are required in update-manager as well, because the upgrader can not relie on stuff from intrepid package, it needs to ship the data on its own
[10:23] <jmunro> is this the right channel to look for ubuntu packaging advice/support?
[10:23] <tseliot> mvo: can't we ship those 3 small packages with the CD (when they are moved to main)?
[10:24] <joaopinto> jmunro, #ubuntu-moty is probably a better place
[10:24] <joaopinto> ops, motu
[10:24] <tseliot> mvo: nvidia-{177|173|96|71}-modaliases are very small
[10:24] <jmunro> thanks joaopinto
[10:24] <mvo> tseliot: when the upgrader runs, its runs on hardy (ether net or cd) - its fine to have the three files included if they are small, that is no issue.
[10:25] <tseliot> mvo: but the modaliases will change every time the drivers are updated
[10:25] <seb128> slangasek: hey, could you have a look to bug #235560 and tell me if you think that's a samba issue?
[10:26] <tseliot> mvo: furthermore, as pitti said, the lists of the supported hardware may be different on 32 and 64bit
[10:26] <pitti> ^ I don't know whether this is actually ture
[10:26] <pitti> true
[10:27] <mvo> tseliot: oh, they are not arch=all ..... hmmm
[10:27] <pitti> or was just a red herring from our hackish way to extract the vendor/model lists from the X driver binaries
[10:27] <tseliot> pitti: we can't control what NVIDIA and AMD do ;)
[10:29] <mvo> tseliot: could you check if the lists are the same? if they are, then I have a lot less problems, if they are not, than I need to ponder about this problem a bit more
[10:29]  * tseliot checks the modalias files
[10:31] <mvo> tseliot: thanks
[10:33] <tseliot> mvo: for nvidia-glx-173 the files are identical
[10:33] <pitti> tseliot, mvo: package reviewed, I mailed you
[10:33] <pitti> I wouldn't like to upload it right now, but after fixing the list it should be good
[10:34] <pitti> should not take more than an hour to fix it up
[10:34] <tseliot> pitti: great, I'll have a look at it as soon as it arrives
[10:34]  * pitti hugs tseliot for his outstanding owrk
[10:34]  * tseliot blushes
[10:34] <pitti> tseliot: I'm just a little more picky about this, since it will go into main
[10:35] <pitti> (well, I'd list the bugs for any universe package, too, but for NEWing I mean)
[10:35] <tseliot> pitti: feel free to be as picky as you like with me ;)
[10:35] <tseliot> pitti: I'll make sure the package is suitable for inclusion in main
[10:38]  * pitti chuckles about the new LP UI -- "bragging rights"
[10:38] <mvo> tseliot, pitti: will the modaliases packages move to restricted at some point (instead of multiverse)?
[10:38] <tseliot> mvo: the modaliases are identical for 177 too. Ok, there is no difference between 64 and 32 bit in the modaliases
[10:38] <pitti> mvo: yes, absolutely
[10:38] <pitti> mvo: the drivers themselves, too
[10:39] <pitti> mvo: I need the modalias lists as jockey Recommends: as well
[10:39] <mvo> tseliot: excellent, thanks for confirming
[10:42] <mvo> how often will the nvidia drivers be updated after the intrepid release (in -updates)? if that is going to happen very infrequently I will just build-dep on the modaliases files in update-manager and copy them into the release-upgrader tarball. if it does happen a lot, then a more flexible aproach is needed
[10:43] <tseliot> mvo: updates will be done as backports from Intrepid+1 to Intrepid therefore there shouldn't be problems with Update Manager
[10:44] <tseliot> mvo: we won't do SRUs as we're doing for Hardy in multiverse
[10:44] <mvo> tseliot: ok, I go with the build-dep approach then
[10:44] <tseliot> mvo: ok
[10:46] <pitti> tseliot: oh, we won't? I thought we'd at least add new driver versions post-release, much similar to what the -envy packages do in hardy right now?
[10:47] <pitti> mvo: can the upgrader download the files from somewhere else prior to starting the upgrade? doesn't it already download a blob?
[10:47] <tseliot> pitti: with -envy there's a certain amount of risk but you still have the packages in the lrm. In intrepid we should still have something stable which doesn't change, I guess.
[10:47] <pitti> tseliot: I agree, but adding newer versions (e. g. as intrepid+1 -> intrepid backports) should be ok?
[10:48] <tseliot> pitti: and maybe the backports will keep happy the ones who want the latest driver
[10:48] <pitti> like, nvidia-192 backported to intrepid
[10:48] <tseliot> pitti: ah, adding a completely new package, you mean. I wouldn't know
[10:49] <tseliot> pitti: if you think that using -updates is better, I'm with you on this
[10:49] <pitti> -backports or -updates doesn't matter much, as long as jockey/envy can pick it up
[10:50] <tseliot> pitti: they don't matter much to me since I'm going to make the packages anyway ;)
[10:50] <mvo> pitti: sure, it could do that too, it will just add more waiting and more stress the mirrors. downloading stuff is fragile in release times, the mirrors are all very loaded. if it has no (or hardly none) disadvantages I would rather want to have it included
[10:51] <pitti> mvo: *nod*
[10:51] <pitti> I was just curious
[10:55] <tseliot> mvo: another thing. Maybe reinstalling libgl1-mesa-glx and xserver-xorg-core (before doing the dist-upgrade) could help if users made use of the NVIDIA installer from NVIDIA's website. See this problem which I solved: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/250486
[10:56] <mvo> tseliot: could you please make the nvidia-common stuff available via bzr? I would like to make some (small) modification to it to make it easier for me to embed it
[10:57] <tseliot> mvo: sure
[11:00] <mvo> what is the reason that we have 4 modaliases package? would it be possible to have them in a sinle package? or have a meta-package that depends on all available ones so that in the future I don't need to manually update the build-depends on them?
[11:01] <pitti> tricky
[11:02] <pitti> mvo, tseliot: what about adding all of them to nvidia-common?
[11:02] <mvo> sounds good to me
[11:02] <pitti> that makes sense anyway, and then you can just b-dep on n-common
[11:02] <pitti> hm, hang on
[11:02] <pitti> can we b-dep on them in the first place? they'll be in restricted
[11:03] <pitti> main -> restricted dependencies -> evil
[11:03] <tseliot> mvo: 4 modaliases packages are made when the 4 drivers are built
[11:03]  * mvo nods
[11:04] <tseliot> pitti,mvo: I'm afraid I don't understand your suggestion
[11:04] <pitti> packages in main can only depend and b-dep on main packages
[11:04] <mvo> its not terrible important, it would just be nice. as long as someone reminds me when new modaliases packages become available to update the build-depends in update-manager
[11:05] <pitti> mvo: but that doesn't work either way
[11:05] <pitti> if we want to do that at all, then the least evil thing (IMHO) we can do is to have the -modalias packages in main and the rest in restricted
[11:05] <pitti> 'source in restricted' and 'one binary of it in main' is against the common practice, too, but less evil than b-depending on restricted packages
[11:05] <pitti> cjwatson: WDYT?
[11:07] <mvo> pitti: meh, right
[11:08] <cjwatson> pitti: (I'm off sick today, but happened to be looking) we already do that with linux-meta
[11:09] <mvo> cjwatson: the plague?
[11:09] <cjwatson> it's not without problems, but can be done with care
[11:09] <cjwatson> mvo: aye
[11:09] <mvo> cjwatson: get well! it hit me fully with >39°C over the weekend
[11:10] <cjwatson> I think I had the worst of it last night, but will be sleeping the rest off today
[11:10] <Mithrandir> canonical has reinstated the distro plague?
[11:10] <pitti> cjwatson: oh, sorry for bothering; get well soon!
[11:10] <Mithrandir> or rather, distro sprint plague.
[11:11] <seb128> anybody around having a clue about libtool who could look to the error on http://paste.ubuntu.com/29259?
[11:11] <pitti> it hit Pedro, then Michael, then Colin; noone else so far, AFAICS
[11:12] <seb128> that's gnome-system-monitor which doesn't want to build using libtool2, not sure what to change though
[11:13] <tseliot> mvo: my bazaar branch is here. NOTE: it doesn't contain the correction which pitti suggested and the branch has not been scanned yet
[11:13] <Mithrandir> seb128: it's C++ and doesn't have a AC_PROG_CXX before the libtool macros?
[11:13] <tseliot> mvo: https://launchpad.net/nvidia-common
[11:14] <seb128> Mithrandir: I did add
[11:14] <seb128> "
[11:14] <seb128>     AC_PROG_CXX
[11:14] <seb128>     AC_PROG_LIBTOOL"
[11:14] <seb128> Mithrandir: but that makes no difference
[11:14] <Mithrandir> seb128: and reran aclocal and auto*?
[11:14] <seb128> libtoolize -c -f && autoconf && aclocal
[11:14] <Mithrandir> that's the wrong order; aclocal; automake; autoconf
[11:14] <Mithrandir> s/;/:/
[11:15] <seb128> is automake required there?
[11:15] <Mithrandir> hm, no, it shouldn't be.
[11:15] <pitti> maybe just autoreconf -f?
[11:15] <Mithrandir> anyway, aclocal before autoconf
[11:16] <seb128> it gives http://paste.ubuntu.com/29261/ now
[11:17] <jcristau> seb128: missing AC_PROG_CC?
[11:17] <seb128> jcristau: is AC_PROG_CC required if I'm already using AC_PROG_CXX?
[11:18] <jcristau> seb128: if you want to build c stuff, not just c++, i'd say yes
[11:19] <seb128> doesn't seem to make a difference
[11:19] <seb128> I hate autotools ;-)
[11:22] <Mithrandir> seb128: this is libtool's way of loving you back.
[11:26] <mvo> tseliot: please check bzr+ssh://bazaar.launchpad.net/%7Emvo/nvidia-common/mvo/ for some smallish additions
[11:27] <cjwatson> order> use autoreconf
[11:30] <seb128> cjwatson: doesn't make a difference, I think the configure.in needs some other changes
[11:30] <seb128> where is scott? ;-)
[11:31] <seb128> ups, in fact no, autoreconf -v -f works
[11:31] <seb128> cjwatson: thanks
[11:31] <tseliot> mvo: ok, thanks. It looks good and you also corrected a typo.
[11:32] <cjwatson> seb128: get in the queue, I mailed Scott about a new (different) libtool problem yesterday ;-)
[11:34] <mvo> tseliot: how is the interface supposed to be used? I call selectDriver() to get the one that I am supposed to use? and getDriver() to see what is currently installed (and should be removed)?
[11:35] <mvo> tseliot: thanks for reviewing my changes
[11:35] <AlexCONRAD> hello, I'm trying to figure out how I can make glxinfo not to display "client glx vendor string: SGI". I'm trying to benefit of Adobe Flash 9 hardware acceleration in full screen.
[11:35] <tseliot> mvo: just create an object and see what it returns (without calling any method)
[11:35] <AlexCONRAD> from the Adobe Flash linux team: the Flash Player requires that the client glx vendor string be something besides "SGI". Official drivers from, e.g., ATI and Nvidia hopefully do not have "SGI" in this field (check the 'glxinfo' command, for this string and for the extensions listed above)
[11:35] <laga> these guys must be smoking weird stuff.
[11:35] <Kano> patch mesa ;)
[11:36] <AlexCONRAD> installing propietary drivers from ati (or from the restricted drivers in xubuntu), I still get SGI
[11:37] <tseliot> AlexCONRAD: if you file a bugreport on launchpad I'll have a look at it later
[11:37] <AlexCONRAD> here's Adobe's blog regarding this issue: http://blogs.adobe.com/penguin.swf/2008/05/flash_uses_the_gpu.html
[11:38] <tseliot> mvo: if doing so seems weird to you I can change it
[11:40] <mvo> tseliot: I would prefer something that I call from within python, maybe a @property like driverpkg or drivername ?
[11:41] <mvo> tseliot: it looks like "selectDriver()" does that, correct?
[11:41] <tseliot> mvo: yes, that's what you need
[11:44] <AlexCONRAD> tseliot: I'm doing a bug report right now. Should I provide a specific package?
[11:45] <tseliot> AlexCONRAD: linux-restricted-modules
[11:45] <AlexCONRAD> ok
[11:45] <laga> can someone recommend a log rotation tool? like logrotate, but less broken (eg runs more then once each day)
[11:47] <mvo> tseliot: ok, I think then I have all the bits in place now in the code, the outstanding issue is only "main"<->"restirected" barrier
[11:49] <tseliot> mvo: ok, I'll apply your corrections (and pitti's) and push them into my branch soon
[11:49] <pitti> mvo: I think I'll move the -modalias packages to main
[11:50] <pitti> mvo, tseliot: so I think that nvidia-common should depen: on the modalias packages, and u-m should b-dep on n-common; ok with you?
[11:50]  * pitti cnat tpye toady
[11:50] <mvo> pitti: that sounds excellent
[11:50] <tseliot> pitti: ok
[11:52]  * mvo hugs pitti and tseliot
[11:52]  * pitti bounces
[11:52]  * tseliot hugs pitti and mvo
[11:55] <mvo> tseliot: I also need a way to figure out if a old nvidia driver was installed before the upgrade (I don't want to transition people without the binary driver to a binary driver on pgrades). I will just use the oldPackages list for this in getDrivers, does that sound reasonable?
[11:57] <tseliot> mvo: what do you mean? If a driver with an old scheme was installed, selectDriver() will return None. Maybe I'm missing the point
[11:59] <mvo> tseliot: oh? maybe I haven't got the interface yet :) on upgrade from hardy->intrepid I want to know a) is a nvidia binary driver installed. if so, then I want to install a new nvidia driver with the new naming schema
[12:00] <mvo> tseliot: it looks like "printSelection" is doing that, correct?
[12:01] <jcristau> it's amazing how much work you guys put into supporting those broken drivers
[12:02] <tseliot> mvo: getDrivers() returns True if an old driver was installed
[12:03] <tseliot> jcristau: I'm convinced that our users should have the best experience with Ubuntu even though this is not extremely easy with proprietary drivers
[12:04] <tseliot> mvo: printSelection() is thought only to interact with bash/debconf
[12:04] <laga> regarding upstart - will upstart be used more widely in intrepid? eg in mysql and other stuff in main?
[12:06] <mvo> jcristau: true
[12:07] <jcristau> (by amazing i mean sad)
[12:08] <Wubbbi> jcristau: why sad? oO ... lol thats good not sad
[12:08] <Mithrandir> jcristau: too many people need them. :-/
[12:08] <mvo> tseliot: could you please merge again from my tree? this gives me access to oldPackages and then I can check the install status in my code slightly more efficiently
[12:08] <Wubbbi> Mithrandir: like me :D
[12:09] <Mithrandir> Wubbbi: you're happy you need crappy non-free drivers?
[12:09] <jcristau> Mithrandir: sometimes i wonder if the same amount of work put into improving free drivers wouldn't be a better use of everyone's time
[12:09] <Wubbbi> I mean if where is a Free Nvidia driver, which can 3D like the Nvidia one, I will use the free. But now The Nvidia Driver is simpy the best ^^
[12:10] <Mithrandir> jcristau: long-term I'm fairly sure it'd be, but short term less so.
[12:10] <Mithrandir> jcristau: it'd be nice if 8.10 could ship nouveau though..
[12:10] <Mithrandir> it's bloody stable for me.
[12:10] <pitti> would anyone have time to try out my first pre-alpha-test version of my guest session script? (http://people.ubuntu.com/~pitti/tmp/guest-session.py, run with sudo)
[12:10] <Wubbbi> Mithrandir: no I'm not happy. But I need it.
[12:10] <tseliot> mvo: sorry if it sounds noobish but having always worked by myself I don't know how to merge branches in bzr
[12:11] <Wubbbi> I also hate OpenOffice, but I need it for work :(
[12:11] <mvo> tseliot: no problem, just run "bzr merge bzr+ssh://bazaar.launchpad.net/~mvo/nvidia-common/mvo/"
[12:11] <Wubbbi> I Like Koffice or Goffice more
[12:11] <pitti> tseliot, mvo: s/bzr+ssh/http/
[12:12] <pitti> actually, just "lp:~mvo/nvidia-common/mvo" should do
[12:13] <pitti> bryce, tjaalton: I heard some rumours that the X server sends out a signal of some kind once it's started up and clients can connect to it; do you know details about that?
[12:14] <tseliot> mvo: ok, merged. pitti: yes, using http did the trick
[12:14] <pitti> tseliot: (explanation: bzr+ssh:// is write access, and you can't write to a branch owned by mvo)
[12:15] <tseliot> pitti: ah, ok, it makes sense now. Thanks
[12:16] <cjwatson> you can use bzr+ssh: for read access too nowadays
[12:16] <tseliot> cjwatson: doing so gave me this error: Permission denied (publickey).
[12:16] <tseliot> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
[12:16] <cjwatson> <cjwatson@sarantium ~>$ bzr get bzr+ssh://bazaar.launchpad.net/~mvo/nvidia-common/mvo/
[12:16] <cjwatson> Branched 4 revision(s).
[12:16] <mvo> tseliot: great, you bzr pushed  as well? I will do some final testing after lunch and then I think the branch is ready
[12:17] <pitti> cjwatson: oh, neat
[12:17] <pitti> cjwatson: so I guess "lp:" is nothing more than a string subst for bzr+ssh://code.launchpad.net/ nowadays
[12:17] <jcristau> pitti: the server looks if the sigusr1 handler is set to sig_ign when it starts. if so, it sends sigusr1 to its parent after init
[12:18] <tseliot> mvo: pushed now
[12:18] <cjwatson> tseliot: that suggests that you don't have ssh configured to use your LP username when sshing to bazaar.launchpad.net<EMAIL_ADDRESS>would have done it
[12:18] <pitti> jcristau: nice, thanks!
[12:18] <cjwatson> tseliot: but it's easier to put this in ~/.ssh/config and then you can forget about it for ever more:
[12:18] <cjwatson> Host bazaar.launchpad.net
[12:18] <cjwatson>         User albertomilone
[12:19] <tseliot> cjwatson: thanks a lot :-)
[12:20] <mvo> tseliot: thanks, I have it now
[12:21] <tseliot> pitti,mvo: I'm going to have a break for lunch now, therefore, unless you've got something urgent to tell me, I'll go now
[12:25]  * tseliot >> lunch
[12:28] <emgent> moin
[12:28] <AlexCONRAD> tseliot: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/250792
[12:29] <mvo> tseliot: could you please merge again from my branch when you come back?
[12:34]  * mvo -> lunch
[13:49] <pitti> seb128: do you have a minute to give a test to my guest session script?
[13:51] <seb128> pitti: yes
[13:51] <pitti> seb128: http://people.ubuntu.com/~pitti/tmp/guest-session.py
[13:51] <pitti> seb128: just running it from your normal session through sudo should work
[13:52] <pitti> it starts the guest session, and as soon as you leave it, it returns back to your's
[13:52] <pitti> it doesn't lock screen yet or anything, just barely sets it up
[13:52] <pitti> PolicyKit, mounting, network-manager etc. should work already
[13:53] <seb128> pitti: is that likely to crash my xsession?
[13:53] <pitti> seb128: no, your own should be fine
[13:53] <pitti> it's possible that the guest session crashes, though
[13:53] <seb128> alright, trying
[13:59] <seb128_> re
[13:59] <seb128_> I knew it would crash my box :-p
[14:00] <seb128_> hum, brb
[14:00] <seb128> re
[14:00] <pitti> seb128: ugh, sorry for that; any idea when/how?
[14:01] <seb128> I would tend to blame VT switch
[14:01] <pitti> seb128: oh, compiz?
[14:01] <pitti> what did you see so far? it just crashed immediately?
[14:02] <seb128> so it loged me in the guest session after some seconds
[14:02] <seb128> the session is usable
[14:02] <seb128> switching user doesn't work though, can't find Xauthority
[14:03] <seb128> the sound card is not available
[14:03] <seb128> and it froze when I tried to log out
[14:03] <pitti> in the guest session?
[14:04] <pitti> the script outputs some debug info, but I guess you didn't see that any more
[14:04] <pitti> it also leaves a debug log in /tmp/guest_*
[14:04] <pitti> .Xauthority? weird, that file should be there; without it, you can't even start the session
[14:05] <pitti> seb128: does a normal gdmflexiserver work for you?
[14:05] <seb128> pitti: tried to use the fusa to switch to your normal user?
[14:05] <pitti> seb128: no, I didn't try that yet; sec, doing
[14:06] <seb128> pitti: "work" in which way? do you mean "does it crash your box on logout too"?
[14:08] <pitti> seb128: fusa doesn't work for me either, thanks for pointing out
[14:09] <pitti> seb128: well, yes; "work" in the sense of "starts a new session, session runs normally, and you can stop it, and switch"
[14:09] <tseliot> mvo: merged and pushed again
[14:11] <seb128> pitti: let me switch IRC to my laptop
[14:12]  * tseliot shuts down his computer. A storm is coming
[14:14] <seb128> pitti: alright, the box crashes the same way when closing a gdmflexiserver session
[14:15] <Riddell> bash question, what does the @ mean at the start of this?  @if [ ! -x "$(DH_SAMEVERSIONDEPS)" ]; then chmod a+x "$(DH_SAMEVERSIONDEPS)"; fi;
[14:15] <pitti> Riddell: is that Make?
[14:15] <jcristau> sounds like a make question
[14:16] <Riddell> pitti: yes
[14:16] <StevenK> Riddell: That's Make. "Don't echo the line before running it"
[14:16] <Riddell> doesn't sound too important then, thanks.
[14:17] <pitti> seb128: I see; maybe you can try disabling compiz?
[14:17] <pitti> (did you get compiz in the guest?)
[14:18] <seb128> you think it's due to compiz? I'm not sure now but I don't think compiz works out of the first session, xorg limitation
[14:19] <seb128> no I didn't anyway, that's intrepid and gnome-session doesn't default to compiz
[14:20] <pitti> ah, ok
[14:20] <pitti> hm, no idea then, I'm afraid
[14:21] <pitti> if it happens even with gdmflexiserver, it's beyond my current knowledge :(
[14:22] <seb128> the syslog has a general protection error in wacom_drv.so and then the restart
[14:22] <seb128> and I couldn't ssh to the box after the crash either so it seems linux didn't like it
[14:24] <sistpoty|work> hm... current daily gives me read errors from the iso when simulating in faumachine... has anyone observed this on a real box?
[14:26] <tseliot> I'm back
[14:28] <tseliot> AlexCONRAD: what's the bugreport which you filed?
[14:28] <AlexCONRAD> tseliot: let me find it again
[14:28] <AlexCONRAD> tseliot: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/250792
[14:34] <tseliot> AlexCONRAD: ok, thanks
[14:37] <superm1> pitti, yes it does
[14:37] <superm1> both hal and libsmbios
[14:40] <pitti> re
[14:40] <mvo> tseliot: I finished my changes in a bzr branch of update-manager now, please prod me when the new nvidia-common is available in the archive, I merge the changes into mainline then. thanks for your work on this!
[14:40] <pitti> seb128: ok, thanks for testing so far!
[14:41]  * pitti hugs seb128, sorry for the trouble
[14:41] <tseliot> mvo: thanks to you ;)
[14:41] <tseliot> mvo: I'll ping you as soon as it's done
[14:42]  * seb128 hugs pitti, you're welcome
[14:42] <seb128> pitti: I'll try on my laptop a bit later, but I'm building gtk+ now and don't want to crash the box
[14:43] <Riddell> grr, cdbs has gained a new dependency in universe
[14:43] <pitti> seb128: right, by any means
[14:43] <pitti> Riddell: hm? it didn't change for a long time?
[14:43] <pitti> Depends: debhelper (>= 5.0.30), fdupes, intltool
[14:43] <pitti> looks fine to me...
[14:44] <Riddell> pitti: build dependency
[14:44] <Riddell> dvipdfmx
[14:44] <Riddell> needed by texlive-xetex
[14:45] <pitti> right, that; there's a MIR for it
[14:48] <hwilde> Mail In Rebate?
[14:48] <pitti> Main Inclusion Request
[14:49] <ogra> Monk In Rage
[14:51] <mathiaz> zul: could you merge samba 3.2.0-4 from debian ? It's an important fixe
[14:51] <jcristau> mathiaz: you mean like https://lists.ubuntu.com/archives/intrepid-changes/2008-July/003931.html?
[14:51] <ogra> mathiaz, you should really subscribe to intrepid-changes
[14:52] <mathiaz> well - I'm just processing my inbox in chronological order
[14:56] <zul> mathiaz: already done
[14:57] <mathiaz> zul: are you subscribed to the pkg-samba-maint mailing list ?
[14:58] <zul> mathiaz: yep and slangasek told me last night as well
[15:02] <pitti> superm1: did you send the libsmbios patch upstream somewhere?
[15:02] <superm1> pitti, yeah its in upstream git already
[15:02] <superm1> i listed the link on the bug report
[15:03] <superm1> mebrown will be doing a libsmbios release in the next week to two weeks, so i'll submit the hal patch upstream once there is a new libsmbios "release" for hal to depend on
[15:03] <pitti> superm1: ah, great; I'm uploading it now
[15:03] <superm1> pitti, great thanks
[15:03] <superm1> you might consider if you can cross pocket copy, i've already got them built on the ppa
[15:03] <superm1> i wasnt sure if you could cross pocket copy to proposed from a ppa though
[15:04]  * pitti runs the missing update-maintainer first
[15:05] <pitti> superm1: I'd rather not, component handling sucks with copy-package from a PPA
[15:05] <superm1> pitti, ah okay
[15:05]  * soren kicks the useless rc.local prompt on initscripts upgrades
[15:07] <pitti> soren: bug 246550
[15:07] <soren> I know.
[15:07]  * soren is testing a patch for it.
[15:08] <soren> Whuh.... Is apt-get not installed by debootstrap in Intrepid anymore?
[15:08] <pitti> that would be weird
[15:08] <soren> It would, wouldn't it?
[15:09] <soren> Maybe it's my mk-sbuild-chroot script that's misbehaving. :/
[15:09] <superm1> soren, try to rerun /finish.sh in the schroot then perhaps
[15:10]  * soren can't spot apt in debootstrap's output..
[15:10] <soren> superm1: finish.sh installs additional packages /using/ apt-get :)
[15:10] <superm1> oh right :)
[15:11] <soren> Task: minimal, minimal
[15:11] <soren> Looks like fun :)
[15:27] <slangasek> seb128: hum, that certainly could be a samba issue, but it's not one that I've encountered; that's kind of an opaque error message, in any case
[15:27] <soren> Oh, apt is no longer build-essential.
[15:28] <soren> Is that intentional?
[15:28] <slangasek> seb128: any chance they're running the aborted hardy-proposed version of gvfs?
[15:30] <seb128> slangasek: did you read the current comment on the bug? and they could, but there is a new upstream version available in hardy-proposed for some time now so that's not really likely
[15:31] <seb128> grrr new libtool
[15:31] <slangasek> seb128: oh.  that's a "wtf, don't do that" bug.
[15:31] <slangasek> seb128: hang on, I have a Debian bug # for that somewhere
[15:31] <seb128> slangasek: ah, thanks
[15:33] <slangasek> seb128: Debian bug #459972
[15:33] <seb128> slangasek: thanks, will you add a comment on the bug and reassign to the proper place? ;-)
[15:34] <slangasek> seb128: summary: a) using wins for hosts is not the common case, b) if you do you have to set up your smb.conf to not cause recursion, c) use DNS already, it's 2008
[15:34] <slangasek> heh, when I come on shift, yes :)
[15:34] <seb128> no hurry ;-)
[15:35] <soren> Er.. how do I in bzr show the contents of a file as per revision X?
[15:35] <soren> Oh, bzr cat.
[15:47] <soren> cjwatson: apt doesn't get marked as build-essential anymore (see http://archive.ubuntu.com/ubuntu/dists/intrepid/main/binary-amd64/Packages.gz).. Germinate bug?
[15:48] <soren> The seed looks fine: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.intrepid/annotate/1223?file_id=buildessential-20070623200333-d1ogpjgj3twv53i0-2
[15:48] <cody-somerville> What does reason "none" mean for a reject? :P
[15:49] <soren> cody-somerville: I /think/ it means that whoever rejected it didn't bother to state a reason. Usually that means that they've sent you a separate e-mail about it or pung you on IRC.
[15:49] <cjwatson> I don't believe that the tools allow stating a reason right now, at least not the command-line tools
[15:50] <soren> Oh.
[15:50] <cody-somerville> How do I find out who rejected codeblocks?
[15:51] <slangasek> brute-forcing the list of possible culprits :)
[15:51] <slangasek> (wasn't me!)
[15:51] <cjwatson> soren: somebody pushed it up to required, and it's listed in http://people.ubuntu.com/~ubuntu-archive/priority-mismatches.txt
[15:52] <ogra> cjwatson, fyi the discussed changes to apply different partition sizes on the 4G cmpc are in the recent image
[15:52] <cjwatson> but apparently by adding a dependency somewhere else - oh, possibly by Recommends
[15:52] <pitti> superm1: so, all done (hardy+intrepid libsmbios+hal), bug updated; testing feedback appreciated!
[15:52] <cjwatson> ogra: thanks
[15:52] <cjwatson> soren: germinate recently got upgraded on drescher/mawson, so I expect it's a consequence of newly-handled Recommends there
[15:52] <soren> cjwatson: Oh, and then germinate removes it from build-essential so that it'd only get listed once?
[15:52] <cjwatson> right, build-essential inherits from required
[15:53] <soren> Ok, got it.
[15:53] <cjwatson> the fix is either for an archive admin to promote it to required, or for the recommends to be dropped to <=suggests, or for germinate not to consider recommends in the required seed
[15:53] <soren> Ok, I'll hand-hold debootstrap --variant=buildd for now..
[15:53] <cjwatson> can it wait until tomorrow? technically I'm off sick today
[15:53] <soren> cjwatson: Oh, sure, sure.
[15:53] <soren> go back to bed. :)
[15:56] <pitti> soren: thanks for the sysvinit fix!
[15:58] <pitti> Riddell: can you please commit your cdbs changes to lp:~ubuntu-core-dev/cdbs/ubuntu/ ?
[15:58] <tseliot> pitti,mvo: I have applied the corrections and pushed them into my main branch
[15:59] <slangasek> seb128: are you managing this scrollkeeper->rarian switch?
[15:59] <Riddell> pitti: oh right sorry, forgot about that
[15:59] <Riddell> BenC: bug 250848 for you
[16:00] <slangasek> seb128: livefs build failure because rarian-compat conflicts with scrollkeeper; I guess scrollkeeper is still seeded?
[16:00] <BenC> Riddell: ok
[16:00] <slangasek> hmm, apparently not seeded
[16:00] <slangasek> BenC: when you fix grub, please mind to commit to the bzr branch :)
[16:01] <seb128> slangasek: I'm not aware of anything to manage for the scrollkeeper to rarian change
[16:01] <slangasek> seb128: ok, well, something's breaking the livefs builds :)
[16:01] <seb128> do you have details on the error?
[16:01] <slangasek> The following packages have unmet dependencies:
[16:01] <slangasek>   rarian-compat: Conflicts: scrollkeeper
[16:01] <slangasek> E: Broken packages
[16:02] <slangasek> that's all the log shows; I can't reproduce it in a clean chroot using only 'apt-get install ubuntu-desktop', so the root cause is somewhere deeper
[16:02] <seb128> slangasek: maybe something in the CD build script?
[16:02] <soren> pitti: Sure :)
[16:02] <seb128> slangasek: note that rarian-compat conflicts,replaces,provides scrollkeeper
[16:04] <slangasek> seb128: nothing is left that has a versioned dep on scrollkeeper?
[16:04] <seb128> not that I know
[16:04] <seb128> and ubuntu-desktop and rarian-compat are installed on my machines
[16:04] <slangasek> trying to install 'apt-get install ubuntu-live^' in a chroot, doesn't give me any errors either
[16:05] <slangasek> and that's what the livecd does
[16:05] <slangasek> (plus bits)
[16:05] <seb128> slangasek: when did you run this cd build?
[16:05] <BenC> Riddell: in what situation is this bug occuring?
[16:06] <pitti> I just checked with grep-dctrl, no versioned dpeendendies to scrollkeeper in main
[16:06] <Riddell> BenC: creating the livefs
[16:06] <Riddell> BenC: also in my chroot just installing grub
[16:06] <slangasek> BenC: I think that kernel-helper -i shouldn't be called in the postinst when [ -z "$2" ]
[16:07] <slangasek> but maybe there are some reasons you'd want to call it on first install
[16:07] <BenC> Riddell: That's what I thought....how can I detect this situation...or do you think I can just ignore the fact that it doesn't exist?
[16:08] <seb128> slangasek: so, the CD build try was today?
[16:09] <slangasek> seb128: yes, and also yesterday
[16:09] <seb128> slangasek: yesterday rarian-compat was in universe
[16:09] <slangasek> then perhaps it gave a different error yesterday :)
[16:09] <seb128> cjwatson mentionned moving it back to main again
[16:10] <pitti> but that was this (late) morning
[16:10] <seb128> no idea about today's issue though, works fine for me on my machines
[16:10] <pitti> later than the CD cron jobs
[16:10] <slangasek> pitti: I just did another buildlive run to check, though
[16:10] <pitti> ah, ok
[16:11] <pitti> tseliot: so nvidia-common is in bzr now? or will you upload to ppa again?
[16:14] <tseliot> pitti: it's in my bzr. I'll upload it to my PPA now
[16:15] <pitti> tseliot: I'm happy to pull from your bzr, that's faster, especially for future updates
[16:15] <tseliot> pitti: perfect. Let's use bzr then
[16:16] <pitti> tseliot: lp:what?
[16:17] <cjwatson> seb128: I moved it yesterday IIRC
[16:17] <cjwatson> pitti: this morning> I think you're mixed up, I'm sure it was yesterday
[16:18] <cjwatson> slangasek: try 'apt-get install ubuntu-desktop^' rather than ubuntu-desktop
[16:18] <cjwatson> Package: scrollkeeper
[16:18] <cjwatson> Task: ubuntu-desktop, edubuntu-desktop, edubuntu-desktop-kde, xubuntu-desktop
[16:18] <cjwatson> that can't be helping
[16:18] <tseliot> pitti: lp:nvidia-common
[16:18] <slangasek> cjwatson: aha, bingo
[16:18] <slangasek> cjwatson: so that needs an ubuntu-meta upload to fix?
[16:18] <slangasek> (et al.)
[16:19] <cjwatson> I thought there'd already been one
[16:19] <ogra> how does edubuntu-desktop-kde ge in there ?
[16:19] <ogra> *get
[16:19] <cjwatson> never mind that for now :)
[16:19] <cjwatson> slangasek: germinate on drescher claims it's directly seeded
[16:20] <Riddell> BenC: moi?  if I knew how to fix it I wouldn't be bugging you :)
[16:20] <slangasek> cjwatson: hrm
[16:20] <slangasek> cjwatson: not since the 17th
[16:20] <cjwatson> as does http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.intrepid/desktop
[16:20] <slangasek> things are failing to see the seed updates?
[16:21] <pitti> nothing in my seed grep any more, hmm
[16:21] <cjwatson> yeah, http://people.ubuntu.com/~ubuntu-archive/seeds/ubuntu.intrepid/ is stuck
[16:21] <cjwatson> investigating
[16:21] <cjwatson> stuck on a lock
[16:22]  * BenC is uploading a new grub now
[16:23] <BenC> slangasek: last I tried, I couldn't commit to grub bzr...
[16:24] <slangasek> BenC: what was the error?  There was a bzr bug shortly before the hardy release that might've prevented it at that time, but it's been working fine for me
[16:24] <slangasek> (ever since, I mean)
[16:25] <pitti> tseliot: please commit back the COPYING file
[16:25] <pitti> tseliot: it's necessary to have a full copy of the license in the source tarball
[16:25] <pitti> tseliot: (it was there before)
[16:25] <cjwatson> moreover, stuck on a nonexistent lock.  Is Bug 59695 going to be fixed for intrepid, and how? If you can link me to this question being answered, that's cool, but I haven't seen anything on the wiki.
[16:26] <slangasek> lukehasnoname: Ubuntu doesn't have individual package maintainers; I've touched acpi-support a couple of times for specific reasons, but it's not my area of responsibility
[16:27] <tseliot> pitti: ? http://bazaar.launchpad.net/~albertomilone/nvidia-common/main/files
[16:27] <tseliot> pitti: it's there
[16:27] <pitti> tseliot: argh, ignore me; I'm retarted
[16:27] <pitti> retarded, even
[16:27] <tseliot> pitti: we're all tired, I guess ;)
[16:28] <lukehasnoname> slangasek: Ya, I knew you aren't the sole maintainer, but I saw your name on the bug list, so I figured you might have info. I should have stated that better. Do you have info? Does anyone?
[16:28] <slangasek> lukehasnoname: but the load/unload cycle one is very hairy - I didn't think acpi-support was currently to blame for anything in that area
[16:29] <ogra> seb128, if you actually plan to have a SRU for bug 247507, could you note that on the bug ?
[16:29] <BenC> slangasek: uploaded new grub, but didn't check on bzr yet...IIRC, it was perms (or maybe me just not knowing how)
[16:29] <ogra> wow, the bugbot isnt the fastest today
[16:29] <slangasek> BenC: the official branch is in ~ubuntu-core-dev, you should have access to that AFAIK?
[16:29] <cjwatson> slangasek: I've fixed the stuck lock; should clear through the archive shortly
[16:29] <slangasek> cjwatson: great, thanks
[16:30] <slangasek> BenC: bzr push bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/grub/ubuntu/ - WFM
[16:30] <slangasek> BenC: if you were using an http-only url for the pull, you have to change it for the push
[16:30] <cjwatson> ogra: the edubuntu-desktop-kde entry is due to edubuntu-docs's Depends
[16:30] <BenC> slangasek: I'll try to update the bzr branch
[16:30] <slangasek> BenC: thanks
[16:31] <cjwatson> BenC: it's easiest to just do 'bzr checkout bzr+ssh://...', and then commits will autopush
[16:31] <BenC> cjwatson: right, that's what I'm used to
[16:33] <seb128> ogra: would be nice but there is way too much to do for me right now so I doubt I'll work on this change any time soon, trying to catch up on things after 2 weeks travelling, new GNOME this week, hardy updates and intrepid, etc etc etc
[16:33] <pitti> tkamppeter: any chance you could upload a recent s-c-p snapshot to intrepid soon? I need it for the new jockey
[16:33] <ogra> seb128, ok, understood ... i dont really know which function i have to patch, else i would do it
[16:36] <pitti> tseliot, mvo: nvidia-common uploaded and NEWed to main
[16:36] <tseliot> pitti: great :-D
[16:36] <slangasek> lukehasnoname: so can you point to something specifically in acpi-support that's doing the wrong thing?  That bug log is horrifically long
[16:36]  * pitti promotes nvidia-graphics-* to restricted
[16:37] <lukehasnoname> slangasek: ehh lemme look
[16:38] <pitti> tseliot, mvo: -modaliases promoted to main, other stuff to restricted
[16:38] <tseliot> pitti: fantastic :-)
[16:38] <mvo> Riddell: do you know if martin böhm would be interessted in some gdebi-kde work again? I would like to talk about using a konsole-less approach with him there too (just like in update-manager)
[16:38] <mvo> pitti: great, thanks
[16:39] <pitti> packagekit-kde!! (*cough*)
[16:41] <mvo> pitti: even that will benefit from that
[16:41] <tseliot> mvo: if you're referring to a KDE4 port of gdebi-kde you can use a qProcess and display the output in a textview. I don't know how well would it work with Debconf and other things that require user interaction though
[16:42] <seb128> ogra: ok, vuntz has a solution for you (you should be on #ubuntu-desktop ;-), they have an opensuse patch that should fix your issue
[16:42] <Riddell> mvo: I suspect he doesn't want to work on it any more
[16:42] <Riddell> mvo: but there was someone working on a qt 4 port of it which would have to include that
[16:43] <mvo> tseliot: yeah, for the kde dist-upgrade we did something like this (but with basic terminal emulation)
[16:43] <Riddell> mvo: I'm going out now, I'll look it up when i get back
[16:43] <mvo> Riddell: if you could make him get in touch with me about this, that would be great, I would love to get the simple solution from update-manager
[16:44] <mvo> Riddell: sure, no rush -and thanks
[16:44] <tseliot> pitti: does packagekit support debconf already?
[16:45] <pitti> tseliot: no, it doesn't
[16:45] <pitti> (that's why it's not a general replacement yet)
[16:45] <tseliot> pitti: too bad
[17:03] <BenC> slangasek: $ bzr co<EMAIL_ADDRESS>[17:03] <BenC> bzr: ERROR: Repository KnitPackRepository('file:///home/bcollins/ubuntu/.bzr/repository/') is not compatible with repository<EMAIL_ADDRESS>[17:03] <slangasek> hum
[17:04] <slangasek> what version of bzr is that?
[17:06] <james_w> I'm guessing that the grub branch is a bzr-svn import.
[17:07] <BenC> slangasek: latest in intrepid
[17:07] <james_w> BenC: do you have /home/bcollins/.bzr/repository/ ?
[17:08] <BenC> james_w: I deleted it though
[17:08] <BenC> james_w: actually, no, that doesn't exist
[17:08] <slangasek> james_w: ah, /half/ of it is a bzr-svn import >:)
[17:09] <james_w> ah yeah, I remember.
[17:09] <james_w> BenC: does it work if you try in /tmp/ ?
[17:09] <pitti> mdomsch_YOW: "Year Of Warcraft"? :)
[17:10] <seb128> asac, pitti: around?
[17:10] <mario_limonciell> i think YOW is the initials for the airport in ottawa if i'm not mistaken
[17:10] <seb128> https://bugs.edge.launchpad.net/ubuntu/+source/epiphany-browser/+bug/250763 has been opened today
[17:10] <pitti> tseliot: that should do: http://bazaar.launchpad.net/~jockey-hackers/jockey/trunk/revision/327 ; I'll have a look at the nivida handler now
[17:10] <pitti> seb128: bonsoir
[17:10] <seb128> and mpt just had the same issue after upgrading firefox in hardy
[17:11] <asac> seb128: strange ... i tested passwords here
[17:11] <mdomsch_YOW> mario_limonciell, bingo
[17:11] <seb128> asac: bookmarks nuked too for mpt apparently
[17:11] <pitti> eww
[17:11] <mpt> I lost bookmarks and history. I don't know whether I would have lost passwords, because I never save passwords.
[17:12] <pitti> asac: will epiphany-browser | 2.22.2-0ubuntu<IP_ADDRESS> (previous version) work with the new xulrunner?
[17:13] <pitti> i. e. if we need to pull epy, do we need to pull xulrunner, too?
[17:13] <asac> it should
[17:13] <asac> i have it installed here
[17:13] <seb128> what did you guys pushed to security or updates today?
[17:13] <pitti> mpt: if you downgrade to the previous epiphany-browser, do you get them back?
[17:13] <pitti> seb128: firefox, xulrunner, epiphany
[17:13] <asac> epiphany?
[17:13] <seb128> so the full combo, hum
[17:13] <asac> ouch
[17:13] <seb128> asac: "ouch"?
[17:13] <asac> i didnt specifically verify that
[17:14] <pitti> hm, you told me I should?
[17:14] <seb128> the epiphany change was a one liner to the printing scale code
[17:14] <asac> pitti: i said multiple times "just ffox/xul"
[17:14] <seb128> no reason to not
[17:14] <pitti> uh
[17:14] <asac> anyway. lets see
[17:14] <asac> i cannot reproduce password not remembered issues
[17:14] <pitti> so, we need to test it with the old epy, to see whether it's in epy itself, or in xul
[17:14] <tseliot> pitti: yes, that should work
[17:14] <seb128> I've several hardy box not upgraded so I can do some testing if you guys want me to test something
[17:15] <pitti> asac: not password, bookmark
[17:15] <mpt> pitti, I'd like to try that. How do I downgrade?
[17:15] <asac> bookmarks are remembered for me now
[17:15] <pitti> ls /var/cache/apt/archives/epiphany-browser
[17:15] <pitti> mpt: ^ if you do that, any hits?
[17:16] <mpt> No such file or directory
[17:16] <pitti> argh
[17:16] <pitti> ls /var/cache/apt/archives/epiphany-browser*
[17:16] <pitti> mpt: forgot the *
[17:16] <mpt> No such file or directory
[17:16] <pitti> that's weird; it should have at least the latest one
[17:16] <seb128> mpt: grep installed /var/log/dpkg.log
[17:16] <seb128> mpt: what is listed for today?
[17:16] <mpt> The only things starting with "e" in that directory are evolution*
[17:17] <tseliot> pitti: I'll have another look at it tomorrow, just to be sure
[17:18] <pitti> tseliot: I'll get ot it later, seems this epy regression needs full attention now
[17:18] <mpt> seb128, language packs, firefox-2 stuff, libsoundtouch1c2, and libc6.
[17:18] <seb128> I don't get why the firefox2 update would impact on xul1.9 applications
[17:18] <seb128> asac: ^?
[17:18] <mpt> It could have been just a coincidence
[17:18] <pitti> mpt: dpkg -l epiphany-browser -> which version does it show?
[17:19] <mpt> ii  epiphany-brows 2.22.2-0ubuntu Intuitive web browser - dummy package
[17:19] <pitti> argh, silly dpkg
[17:19]  * mpt wonders how on earth something can be intuitive and a dummy at the same time
[17:19] <pitti> mpt: dpkg -l epiphany-browser |grep ^ii
[17:19] <seb128> mpt: 2 persons having a similar issue on the same day when we got nothing like this in ages is weird coincidence, I prefer to triple check that
[17:19] <mpt> pitti, 2.22.2-0ubuntu<IP_ADDRESS>
[17:20] <pitti> so, that's the old one
[17:20] <pitti> not the one which went into -updates today
[17:20] <mpt> I didn't see any Epiphany updates in update-manager
[17:20] <mpt> just Firefox and language packs
[17:21] <seb128> firefox being firefox2 which epiphany is not using
[17:21] <pitti> mpt: dpkg -l xulrunner-1.9|grep ^ii
[17:21] <mpt> pitti, 1.9+nobinonly-0ubuntu<IP_ADDRESS>
[17:21] <asac> thats still the old one
[17:21] <pitti> ok, that's also the old one
[17:22] <pitti> today <IP_ADDRESS>+build1+nobinonly-0ubuntu<IP_ADDRESS> went to -updates
[17:22] <asac> good luck ;)
[17:22] <pitti> mpt: ok, thanks so far
[17:22] <asac> seb128: that thing was more than a week in -proposed. is there really no other bug about something similar?
[17:22] <pitti> so apparently it is not related to today's updates at alll
[17:22] <seb128> asac: could the firefox2 update impact on running epiphany instances?
[17:22] <asac> not that i can think off. they are unrelated
[17:22] <seb128> asac: no, I would have nothing, I read all the incoming bugs mails I receive
[17:23] <seb128> s/nothing/noticed
[17:23] <seb128> maybe just a weird coincidence
[17:23] <asac> seb128: yeah. what was the bug filed today?
[17:23] <pitti> I asked for the precise versions in the bug now
[17:23] <seb128> asac: https://bugs.edge.launchpad.net/ubuntu/+source/epiphany-browser/+bug/250763 was filed 6 hours ago
[17:24] <pitti> asac: 6 hours ago
[17:24] <asac> ok thats not related then
[17:24] <asac> or
[17:24] <seb128> asac: and mpt just mentioned his issue on #epiphany some minutes ago
[17:24] <pitti> that was before I moved the new stuff to -updates
[17:24] <asac> would be quick
[17:24] <seb128> mpt did update those
[17:24] <seb128> but he did get the firefox2 update
[17:24] <seb128> s/did/didn't, can't type
[17:25] <mpt> It happened shortly after I installed the firefox 2 update
[17:25] <mpt> (I have both FF2 and FF3 installed for testing purposes)
[17:25] <pitti> maybe these two share the same profile, and something went wrong with profile managemnet?
[17:25] <asac> mpt: right. that will only cause pain for firefox (when switching back and forward)
[17:25] <asac> pitti: i doubt that. unless mpt uses manually setup profiles of course
[17:26] <mpt> I do not
[17:26] <mpt> (though I'm tempted, because it's mildly irritating that every time I launch FF3 after using FF2 I get the Ubuntu start page)
[17:26] <asac> mpt: and what happens if you starte ffx2 after ff3?
[17:26] <mpt> asac, I get my home page as expected
[17:27] <asac> ok
[17:38] <seb128> asac, pitti: just installed the firefox-2 current version on an hardy box, didn't crash epiphany, upgrading to today's xulrunner and firefox update didn't create any issue either
[17:38] <seb128> I'll keep an eye for similar issues
[17:38] <pitti> I subscribed to the bug, too
[17:38] <seb128> but so far it could just be a coincidence
[17:40] <AlexCONRAD> tseliot: update of bug 250792
[17:40]  * asac hugs seb128
[17:40] <asac> now i can sleep better
[17:40] <mpt> seb128, also, "Web History (Epiphany)" and "Web Bookmarks (Epiphany)" turned themselves off in Deskbar Preferences
[17:40] <mpt> (maybe because they couldn't find the necessary data)
[17:41] <seb128> mpt: do you still have bookmarks in .gnome2/epiphany/ephy-bookmarks.xml or some backup files in this directory?
[17:42] <tseliot> AlexCONRAD: I'll have a look at it ASAP
[17:43] <huats> Is the kind of licence like that one http://revu.ubuntuwire.com/revu1-incoming/tktreectrl-0807181630/tktreectrl-2.2.5/license.terms is allowed in ubuntu?
[17:43] <huats>  it is the one commonly used in tcl pakage
[17:43] <huats>  ...
[17:43] <mpt> seb128, hey, this directory contains a couple of desktop background pictures I'd lost, thanks :-)
[17:43] <huats> it is the same than the one used in the tcl/tk license terms http://www.tcl.tk/software/tcltk/license.html
[17:43] <huats> apparently elmo, you might be the person to ask :)
[17:44] <pitti> the last paragraph is a bit hard to interpret
[17:44] <pitti> first, it limits usage by governments, and then the last sentence almost, but not quite, reverts the limitation
[17:44] <pitti> (it just says "use and distribute", not "modify")
[17:45] <mpt> seb128, but yes, it contains a backup that has most of the missing bookmarks
[17:46] <pitti> tseliot: hmm, now that all four modules are just called 'nvidia', I can only have one handler instead of three; so I wonder which xorg.conf options I should apply to each of those versions...
[17:46] <pitti> tseliot: I can still tell them apart by looking at the package name, of course
[17:46] <slangasek> pitti: the definition of "Restricted Rights" in US law basically means "getting a copy of this on behalf of the government doesn't automatically give you special privileges"
[17:47] <slangasek> so I don't think that's a problem
[17:47] <elmo> huats: I am not an archive admin, but I think it's fine
[17:48] <huats> elmo: pitti told me that you might be a good person to ask :)
[17:48] <pitti> elmo: thanks for reviewing
[17:48] <huats> elmo: thanks for your opinion :)
[17:49] <huats> pitti: thanks too :)
[17:51] <tseliot> pitti: yes, the module is always "nvidia". There are no specific options for each driver. If Jockey can tell one model from the other then some card-specific options can be applied.
[17:52] <pitti> tseliot: for now I think I'll just continue to use the few I have in hardy
[17:52] <pitti> tseliot: (-71: AllowGLXWithComposite, UseEdidFreqs; -96: AddARGBGLXVisuals)
[17:52] <pitti> tseliot: at some point I'd like to merge the much better option mapping you have in envy
[17:53] <pitti> but for getting in the initial support for the new packages I'll just use those coarse ones
[17:54] <pitti> tseliot: do you happen to know if I can set AllowGLXWithComposite in the screen section, too? or just in the Driver section?
[17:54] <tseliot> pitti: wise choice. I'll give you a hand with this. I have yet to make EnvyNG work on Intrepid. Maybe disabling the dri2 module would be nice too.
[17:54] <tseliot> pitti: we should include X-Kit too
[17:54] <pitti> tseliot: dri2> for all versions? yes, I can do that easily
[17:54] <pitti> remove_modules=['dri', 'GLcore']
[17:54] <pitti> ^ current code
[17:54] <pitti> so I'll add dri2?
[17:54] <tseliot> pitti: yes, for all versions
[17:55] <tseliot> pitti: removing "dri2" is not enough. You will have to set Disable "dri2"
[17:55] <pitti> in which section?
[17:55] <tseliot> pitti: you can do that with X-Kit ;)
[17:55] <tseliot> in the Module section
[17:56] <pitti> tseliot: getting there, getting there... but I'd like to push out something working for alpha-3, if possible
[17:56] <seb128> mpt: ephy-bookmarks.xml has most of the bookmarks? or do you have a backup which have those? do you get any error if you run epiphany on a command line?
[17:56] <mpt> seb128, ephy-bookmarks.xml did not, but there were two backup files, one of which contained most of them
[17:57] <seb128> ephy-bookmarks.xml was empty?
[17:57] <seb128> do you have anything about epiphany in .xsession-errors?
[17:58] <mpt> ephy-bookmarks.xml wasn't empty, it contained the bookmarks that I'd added since I lost them all
[17:58] <tseliot> pitti: disabling "dri2" is not extremely important but users will report a driver failure as being caused by "dri2" if you don't disable it. The nvidia driver will still work
[17:58] <mpt> When I run Epiphany from a command line I get "(epiphany-browser:32738): GLib-GObject-WARNING **: value "((GaProtocol) 2)" of type `GaProtocol' is invalid or out of range for property `flags' of type `GaProtocol'" and "(epiphany-browser:32738): GLib-CRITICAL **: g_hash_table_unref: assertion `hash_table != NULL' failed"
[17:59] <mpt> seb128, and when I close Epiphany with Ctrl W it says "Segmentation fault", though when I close it with the title bar close button it exits properly
[17:59] <mpt> (I'm guessing that's a whole different bug)
[18:00] <seb128> the other bugs are similar warning, but yes could be a different issue
[18:00] <seb128> asac: ^ any idea about those?
[18:00] <mpt> aha
[18:00] <mpt> /home/mpt/.gnome2/epiphany/ephy-bookmarks.xml:162: parser error : expected '>' <parent id="5"/>
[18:01] <mpt> /home/mpt/.gnome2/epiphany/ephy-bookmarks.xml:162: parser error : Opening and en
[18:01] <mpt> ding tag mismatch: property line 0 and unparseable
[18:01] <mpt> That explains a lot :-)
[18:01] <tseliot> pitti: about AllowGLXWithComposite: http://pastebin.com/d2ce43337
[18:01] <tseliot> pitti: are you sure that enabling it is still a good idea?
[18:02] <asac> mpt: is that file broken?
[18:02] <pitti> tseliot: not first hand, I just got it from bug reports
[18:02] <pitti> tseliot: I can drop it for now and try to find a tester who uses -legacy
[18:02] <pitti> sorry, -96 in newspeak
[18:02] <mpt> asac, I guess it was (I've restored it from backup since then)
[18:03]  * mpt looks forward to XML 5 and more tolerant XML parsers
[18:03] <tseliot> pitti: currently 71 and 96 don't work at all because of the new Xserver ABI :-/
[18:03] <pitti> heh, ok
[18:03] <asac> mpt: if it was broken like in "not-complete" then you most likely had a crash while ephy synched bookmarks
[18:03] <pitti> well, I just drop it for now, thne
[18:03] <asac> thats the only explanation i have at hand
[18:03]  * ion_ looks forward to S-exps. :-)
[18:03] <mpt> s/forward to S-exps/backward to S-exps/
[18:03]  * mpt flees
[18:04] <ion_> Yeah
[18:04] <mpt> Anyway, S-expressions aren't any more fault-tolerant than XML -- they're theoretically less fault-tolerant, precisely because they're more concise
[18:57] <joeythesaint> s
[19:15] <ompaul> Treenaks, mark - pm at this time
[20:04] <emgent> heya
[21:36] <hwilde> so, how do you unset the root password if someobdy set it
[21:37] <hwilde> !root
[21:38] <slangasek> hwilde: by editing /etc/shadow, but that question seems a bit off-topic here
[21:38] <hwilde> nobody else knows :(
[21:38] <slangasek> (there are other tools that can be used to edit /etc/shadow for you, but I never remember what they are, so I just edit /etc/shadow)
[21:38] <mkrufky> seriously, dont worry about the roor password
[21:38] <mkrufky> root
[21:38] <hwilde> people are setting the root pw
[21:38] <mkrufky> somebody set it?  who cares?
[21:39] <mkrufky> use sudo anyway
[21:39]  * hwilde stares at mkrufky
[21:39] <mkrufky> disable root login in ssh
[21:39] <mkrufky> (should be disabled by default anyway, no?)
[21:40] <hwilde> roor is cool tho :)
[21:40] <hwilde> nice typo
[22:01] <slangasek> BenC: grub 0.97-29ubuntu29 still fails to install in the livefs build chroots
[22:03] <ion_> benc: A wrong value (1 instead of 0) seems to have slipped into fail_exit_val in kernel-helper -i.
[22:06] <asac> ogra: there? where is the latest hardy cmpc image?
[22:06] <ogra> asac, usual place :)
[22:07] <ogra> http://people.ubuntu.com/~ogra/classmate/images/hardy/
[22:08] <asac> ogra: is that known to work?
[22:08] <ogra> asac, https://bugs.launchpad.net/cmpc/+bugs the fix commited bugs look for confirmation (even though you might not have the HW for many of them)
[22:08] <ogra> well, it works fine here on my 1.5 HW
[22:09] <ogra> i dont test on 1.0 anymore but would be good to hear if it works there indeed
[22:22] <BenC> slangasek, ion_: whoops
[22:22] <BenC> slangasek: I thought I tested it, but I guess I didn't hit the proper situation
[22:25] <ion_> benc: It would be nice if it printed something like "$0: No vmlinuz, exiting.", btw.
[22:25] <BenC> slangasek: Uploaded fixed one (exit val at 0)
[22:25] <slangasek> ok, cheers
[22:55] <alex-weej> ogra: hi
[22:56] <ogra> alex-weej, hey, i have to relocate (hop in a taxi etc) but will be online later again
[22:57] <ogra> i was about to suggest we take that off list :) great that you had the same thought
[23:05] <mathiaz> slangasek: about the slapd cnconfig migration I sent to the pkg-openldap-maintainer list, is there a chance it will get accepted for lenny ?
[23:06] <slangasek> mathiaz: I think so, yes
[23:06] <slangasek> mathiaz: currently queued up behind PAM upstream merges in my brain, though :)m
[23:06] <mathiaz> slangasek: how does the debian freeze work then ?
[23:07] <slangasek> mathiaz: well, today a member of the Debian release team who will remain nameless declared that "vorlon can do whatever he wants" ;P
[23:07] <mathiaz> slangasek: right... I see your point :D
[23:08] <slangasek> mathiaz: in the early stages, the Debian freeze is mostly about getting the archive into a consistent state; this takes longer in Debian than in Ubuntu, in part because Debian sets the bar higher
[23:09] <slangasek> things like changing the slapd config setup, while significant, are self-contained and don't bother the release team so much
[23:09] <mathiaz> slangasek: ok
[23:09] <ogra> and NMUs are harder than team maintenance
[23:09] <slangasek> unless they happen in the last weeks before release, and cause a regression ;)
[23:09]  * ogra twiddles thumbs waiting for the shuttle to arrive
[23:20] <asac> ogra: works fine on 1.0 for me. quite nice actually. tbird ;)
[23:21] <ogra> heh, yeah, i have to drop something big for openoffice
[23:21] <Nafallo> ogra: you're buying a shuttle? new development box?
[23:21] <ogra> and evo was the heavyweight that lost
[23:21] <asac> yay
[23:23] <ion_> ogra: Light a match afterwards.
[23:25] <nxvl> cjwatson: around?
[23:54] <android6011> I have a slight problem booting, I get the "starting up" then something abotu GPE Storm Detected, if I press the power button it continues to boot, but if I don't it hangs. I was just wondering if there is a bug report for this