[20:52] <KGB-2> orca pristine-tar 681a8ad Samuel Thibault orca_42.2.orig.tar.xz.delta orca_42.2.orig.tar.xz.id * pristine-tar data for orca_42.2.orig.tar.xz * https://deb.li/3Avzl
[20:52] <KGB-2> orca upstream/stable d04d1d4 Samuel Thibault * pushed 15 commits (first 5 follow) * https://deb.li/FvuM
[20:52] <KGB-2> orca upstream/stable 89ec69d Joanmarie Diggs README.md configure.ac * Post-release version bump * https://deb.li/3gHnz
[20:52] <KGB-2> orca upstream/stable 1e90620 Joanmarie Diggs src/orca/structural_navigation.py * Structural Navigation: Handle unimplemented collection interface error * https://deb.li/ixvds
[20:52] <KGB-2> orca upstream/stable 67d22cd Pawan Chitrakar po/ne.po * Update Nepali translation * https://deb.li/kwaN
[20:52] <KGB-2> orca upstream/stable f5ce43c Joanmarie Diggs src/orca/scripts/web/speech_generator.py * Web: Don't treat DOCUMENT_FRAME as a stop-at role for generating ancestors * https://deb.li/3WIDx
[20:52] <KGB-2> orca upstream/stable 8863130 Joanmarie Diggs src/orca/ (6 files in 2 dirs) * Web: Improve presentation of description lists * https://deb.li/eD4g


[00:02] <stgraber> cjwatson: http://www.stgraber.org/download/ubuntu/lvmcrypto/
[00:02] <cjwatson> ta, looking
[00:03] <cjwatson> "Mounted filesystem?", huh
[00:03] <stgraber> What's weird is that in /dev/mapper I have : sda2_crypt and sda2_cryptp1
[00:04] <stgraber> IIRC I never had things like _cryptp1 on Hardy and I don't really see what it's
[00:04] <cjwatson> p1 sounds like something treating sda2_crypt as a disk-like block device with one partition
[00:05] <cjwatson> parted has been known to make that kind of mistake in the past although I'm not sure whether it would be the thing creating the device node
[00:06] <kirkland> slangasek: https://bugs.launchpad.net/debian/+source/samba/+bug/247087/comments/4
[00:06] <kirkland> slangasek: i think this is what you suggested
[00:16] <slangasek> kirkland: I think what I meant was this:
[00:17] <cjwatson> stgraber: not much to go on in the logs - I'll see if I can reproduce from your test case
[00:17] <slangasek> +		status="0"
[00:17] <slangasek> +		NMBD_DISABLED=`testparm -s --parameter-name='disable netbios' 2>/dev/null`
[00:17] <slangasek> +		if [ "$NMBD_DISABLED" != 'Yes' ]; then
[00:17] <slangasek> +			status_of_proc -p $NMBDPID /usr/sbin/nmbd nmbd || status=$?
[00:17] <slangasek> +		fi
[00:17] <slangasek> +		if [ "$RUN_MODE" != "inetd" ]; then
[00:17] <slangasek> +			status_of_proc -p $SMBDPID /usr/sbin/smbd smbd || status=$?
[00:17] <slangasek>  		fi
[00:17] <slangasek> +		if [ "$NMBD_DISABLED" == 'Yes' -a "$RUN_MODE" == "inetd" ]; then
[00:17] <slangasek> +			status="4"
[00:17] <slangasek> +fi
[00:18] <slangasek> kirkland: i.e., still only check each process if you're supposed to (otherwise status_of_proc will spit out a useless message, no?), and then set the status appropriately at the end if nothing's been done
[00:18] <kirkland> slangasek: ah, okay, so keep the checks
[00:18] <kirkland> slangasek: and conditionally override status=4, if deemed necessary
[00:19] <slangasek> that's my thought
[00:19] <slangasek> you're allowed to have different ones, of course :)
[00:19] <kirkland> slangasek: that certainly makes sense
[00:20] <cjwatson> ps [ == ] is a bashism
[00:20] <slangasek> erk, yes :)
[00:20] <kirkland> slangasek: i'm fixing that too
[00:21] <slangasek> <-- tunnel vision again
[00:22] <cjwatson> stgraber: so "physical volume for encryption" for sda2?
[00:22] <stgraber> yes
[00:23] <elmo> what's R550 support like in Hardy and/or Intrepid?
[00:24] <stgraber> cjwatson: then use it as physical volume for LVM and it'll break when starting LVM configuration
[00:25] <kirkland> slangasek: http://launchpadlibrarian.net/15925572/samba.status.debdiff
[00:25] <kirkland> slangasek: or, rather: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/247087/comments/5
[00:27] <cjwatson> stgraber: it does indeed
[00:30] <slangasek> kirkland: looks pretty good to me
[00:31] <kirkland> slangasek: *pretty* good????
[00:31] <kirkland> slangasek: :-)
[00:31] <kirkland> slangasek: shall I send it to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488275 as well?  (cleaning out the changelog bits, of course)?
[00:32] <slangasek> kirkland: I see no bugs at all in the code - I'll give it a B+ ;)
[00:32] <kirkland> slangasek: or shall I expect you to handle the Debian side of this?
[00:32] <slangasek> kirkland: it would be helpful to me if you would also send it to the Debian side
[00:32] <kirkland> slangasek: and what's it going to take to get it to an "A"?
[00:32] <slangasek> I would /eventually/ handle it there as well, but it would take longer :)
[00:33] <ion_> Cool, i have a time machine. Jul 10 02:27:20 heh dovecot: Time just moved backwards by 1 seconds.   I thought I only saw the fixes for them committed in later upstream versions
[00:47] <cjwatson> slangasek: that's partly what confused me too, I think he meant "fixed in later upstreams and in current Debian"
[00:47] <stgraber> ogra: around ?
[00:47] <stgraber> ogra: LTSP install just failed
[00:47] <ogra> nearly dying, but still somewhat awake
[00:47] <slangasek> cjwatson: well, I'm pretty sure I didn't fix it in Debian :)
[00:48] <ogra> stgraber, known, i didnt have the time yet to check what it is in a VM
[00:48] <stgraber> Failed getting release file file:///cdrom/dists/intrepid/Release
[00:48] <ogra> there is a bug somewhere, let me check
[00:48] <ogra> https://bugs.launchpad.net/bugs/246615
[00:49] <ogra> mean
[00:49] <ogra> i guess we suffer the same issues of d-i unmounting the CD as debian has in lenny
[00:49] <stgraber> as ltsp-build-client is started with in-target I guess you should bind mount /cdrom to /target/cdrom
[00:49] <ogra> can you check if your CD is mounted at all ?
[00:50] <stgraber> CD is mounted in /cdrom
[00:50] <ogra> you shouldnt need to bind mount
[00:50] <ogra> at least you didnt until hardy :)
[00:50] <ogra> i'll inspect that further by end of the week
[00:51] <stgraber> well /cdrom is fine but /target/cdrom is empty so as ltsp-build-client is start after chrooting to /target it won't be able to read the cd-rom
[00:51] <ogra> yeah, but d-i used to care before
[00:52] <ogra> i'd like to inspect that side first
[00:52] <cjwatson> slangasek: ... oh
[00:52] <ogra> but surely not today anymore
[00:52] <cjwatson> I thought I'd stopped d-i doing that for our CDs
[00:52]  * ogra had some pretty hard days ... and just managed to fianlly get a working 8.04.1 cmpc release
[00:53] <ogra> so i'll just crash now as soon as the upload is through ...
[00:54] <ogra> cjwatson, it can as well be that ltsp simply runs to late
[00:56] <ogra> stgraber, the bug above indicates that there are also other errors, i doubt it would even work with CD mounted
[00:57] <cjwatson> oh, yeah, definitely solve problems in order
[00:58] <stgraber> ogra: I haven't tried ltsp-build-client in Intrepid other than that ISO testing so I don't know what would have happened if it didn't fail with that missing cd-rom error
[00:58] <cjwatson> ogra: I don't think it should be too early
[00:58] <cjwatson> stgraber: but it looked like it was the other way round, "Failed getting release file" after the cp error
[00:59] <cjwatson> anyway, can't unpick this and dm-crypt at the same time
[00:59] <ogra> cjwatson, no hurry, i wont touch it tonight anymore and there are definately more issues
[01:09] <emgent> nixternal: Thanks for your vote :)
[03:02] <nixternal> emgent: no problem, you deserved it!
[03:03] <emgent> nixternal: hehe thanks :)
[03:03] <emgent> nixternal: solved problem with copy/paste ? :)
[03:18] <nixternal> I will shortly by going back to Mutt :)
[03:20] <emgent> hehe nice :)
[03:33] <jdong> nixternal: ugh I've been stuck using evolution and gmail.com this summer; my job is keeping me so busy I've had no time to configure a muttrc
[03:33] <jdong> and it's down to my last straw of patience now
[03:33] <jdong> by the way, hi everyone, long time no see. I'm not dead, I just have been swamped with work...
[03:33] <jdong> *goes disappear for another 3 weeks*
[03:34] <RAOF> jdong: Howdie.  Have fun! :)
[03:34] <jdong> btw, vorian , while I'm here, congrats. You deserve it!
[03:35] <vorian> thanks man :)
[03:35] <vorian> jdong: don't work too hard
[03:35] <vorian> and don't get fired
[03:35] <jdong> lol, trying not to. On both counts. but I think that's somehow mutually exclusive
[03:35] <vorian> haha
[03:36] <LaserJock> hi jdong
[03:36] <jdong> hey LaserJock :)
[03:57] <nixternal> jdong: ya, I am using Evolution now for work email and switched my home/personal/ubuntu/kde/debian email to Kontact KDE4
[03:57] <nixternal> I just hate setting up Mutt again, it takes so long to get down
[03:58] <nixternal> Evolution has one good thing, and that is decent Exchange via OWA support, but the rest of it is just garbage
[04:00] <jdong> nixternal: yeah the only good thing for me about evolution was that it responds faster than gmail over my weak wifi and was set up in 4 clicks
[05:27] <orbisvicis> what package tool downloads .dsc files ?
[05:29] <TheMuso> orbisvicis: dget
[05:29] <orbisvicis> thanks
[05:35] <Awsoonn> are we on track for an alpha 2 today?
[05:35] <Awsoonn> anyone with insight?
[05:52] <Hobbsee> are the ~motu memberships supposed to expire?
[06:05] <orbisvicis> when i need to edit source of a package with patches, i need to create a diff .. is that a diff of my revision with the original, or the original with all the previous patches applied ?
[06:06] <orbisvicis> and then drop it into patches
[06:15] <LaserJock> Hobbsee: how do you mean?
[06:16] <Hobbsee> LaserJock: as in, am i supposed to ask someone to renew them, or is it deprecated?
[06:17] <LaserJock> Hobbsee: no, I believe you want to renew it
[06:17] <LaserJock> individual membership in ~ubuntu-dev is what was deprecated
[06:18] <LaserJock> in favor of holding ~motu and ~ubuntu-core-dev
[06:18] <Hobbsee> oh
[06:18]  * Hobbsee already renewed that one
[06:19] <LaserJock> :-)
[06:22] <Awsoonn> orbisvicis: when you make your patch, it should generally not require the other patches to be already applied, otherwise you will need to make special notes about what patches need applying first
[06:26] <orbisvicis> Awsoonn, that makes life easy. are there any requirements when running diif, say -ruN etc
[06:28] <Awsoonn> That is out of my memory right now
[06:29] <LaserJock> I generally use diff -aurN
[06:30] <orbisvicis> as long as there isnt a standard i have to adhere to
[06:30] <orbisvicis> ok, thanks
[06:30] <orbisvicis> ill patch it tomorrow
[06:36] <dholbach> good morning
[06:36] <Hobbsee> hey dholbach
[06:36] <Hobbsee> dholbach: can you renew my membership in ~motu please?
[06:37] <dholbach> Hobbsee: you should be able to do that yourself - wasn't there a link in the mail?
[06:37] <dholbach> I got a mail saying that you already renewed it?
[06:38] <dholbach> Hobbsee: ^
[06:38] <dholbach> Hobbsee: expires 2009-07-17
[06:38] <Hobbsee> dholbach: oh, sorry, ~ubuntu-dev
[06:38]  * Hobbsee got both today
[06:38] <dholbach> ubuntu-dev you can let expire
[06:39] <dholbach> in the end only ubuntu-core-dev and motu will be member of ubuntu-dev
[06:39] <Hobbsee> ah
[06:39] <LaserJock> Hobbsee: what I said ;-)
[06:39]  * LaserJock is glad to find he's not totally lost touch :-)
[06:41] <Hobbsee> heh
[06:43] <Hobbsee> LaserJock: i thought we were depreciating the term "motu".  oh well
[06:44] <LaserJock> no, I don't think so
[06:44] <LaserJock> eventually the Main/Universe split will probably go away, but I think MOTU may even survive that
[07:04] <dholbach> soren, pitti: the kernel boots in kvm now, but X doesn't start (uses 100% CPU)
[07:08] <dholbach> X starts with the old kernel though
[07:08] <dholbach> and the mouse in KVM only works if I remove the /etc/X11/xorg.conf (on the other hand only 800x600 now)
[07:08] <dholbach> intrepid is fun :-)
[07:09] <Awsoonn> does this mean progress for vbox too?
[07:39] <dholbach> ara: just commented on your ldtp patch - let me know once you updated it and I'll take a look at it again :-)
[07:39] <ara> dholbach: ok, i'll have a look
[07:39] <ara> thanks
[07:42] <soren> dholbach: Figures. :(
[07:44] <dholbach_> doko: what do you think about bug 240884?
[07:44] <dholbach> it seems to be important for bug 237175
[07:51] <ara> dholbach: maybe this is no longer needed anymore. they have release the ldtp 1.2 and the debian maintainer has already fixed the dependency problem. once he uploads the debian pkg we could just sync with it
[07:56] <dholbach> ara: ah excellent - could you update the bug report once that has happened?
[07:56] <ara> dholbach: sure, i will :)
[07:57] <dholbach> ara: gracias!
[08:11] <seb128> sbeattie, kees: just read your mail about glib, I just copied the upstream NEWS as usual, it's still using the system pcre, is that an issue for you?
[08:11] <dholbach> hi seb128
[08:11] <seb128> (not replying to the mail because they are filtering smtp at GUADEC)
[08:11] <seb128> hey dholbach
[08:12] <seb128> pitti: doh about gtkhtml, can't fix it this week but the updates fix a low priority issue
[08:15] <Hellow> Hello
[08:17] <seb128> dholbach: I can have a look at the sponsor queue while you on holidays
[08:18] <dholbach> seb128: that'd be awesome!
[08:18]  * dholbach hugs seb
[08:18]  * seb128 hugs dholbach
[08:27] <pitti> Good morning
[08:27] <pitti> dholbach: X doesn't start> try without usplash
[08:28] <pitti> dholbach: or try blacklisting the 'uvesafb' module
[08:28] <pitti> seb128: thanks
[08:29] <seb128> pitti: ups, "the update fixes a low priority security issue" it was supposed to be
[08:29] <seb128> pitti: I'm a bit annoyed that it was waiting for a week and has been rejected, no big deal I'll upload monday using the right bug number
[08:31] <Hobbsee> heya pitti!
[08:31] <seb128> hello Hobbsee
[08:32] <Hobbsee> hey seb128!
[08:40] <tseliot> pitti: did you upload the drivers to Intrepid?
[08:40] <superm1> pitti, is it possible to yank something out of hardy-updates that is causing some bad breakage for people (but the proper fix is in hardy-proposed waiting to enter hardy-updates)?
[08:41] <pitti> tseliot: no, shall I?
[08:41] <pitti> superm1: ugh! which package, which bug?
[08:41] <superm1> pitti, bug 243930
[08:42] <tseliot> pitti: you told me that you wanted to include them in time for Alpha 2
[08:42] <pitti> superm1: ah, *phew*, that's at least not a grave regression from hardy final, since wl wasn't present at all
[08:42] <pitti> tseliot: right, I just wasn't sure who would upload them
[08:42] <superm1> pitti, well i'd like to understand how it even got introduced though
[08:42] <superm1> because there was one lrm upload before it, specifically that touched 'wl'
[08:43] <superm1> it must not have been tested
[08:43] <superm1> pitti, it is going to break anyone who gets a factory image from dell with a broadcom card though
[08:43] <tseliot> pitti: I would be glad if you could do the upload for me
[08:44] <superm1> (since the expectation is that the updates are in hardy-updates when they update for the first time)
[08:44] <pitti> superm1: right, it's still bad, no doubt
[08:44] <pitti> superm1: so, the bug got an overwhelming amount of positive feedback
[08:44] <superm1> pitti, yeah from what i see
[08:44] <pitti> superm1: I feel we shouldn't wait for 7 days to push it to -updates
[08:45] <superm1> i was just made aware of this earlier this evening
[08:45] <superm1> pitti, yeah
[08:45] <pitti> tseliot: sure, I will
[08:45] <tseliot> pitti: thanks :-)
[08:46] <pitti> superm1: the diff was trivial (one-liner in Makefile), so it didn't touch anything else than wl
[08:46] <pitti> superm1: I'm going to copy it to -updates now
[08:46] <superm1> pitti, wonderful, thanks
[08:46] <superm1> pitti, i'll talk to the kernel guys tomorrow about how/why this happened then to make sure it doesnt ever happen in the future
[08:46] <pitti> superm1: thanks, that would be nice
[08:49] <tjaalton> stupid, stupid emacs... disabling the splash works only if you set it in your own .emacs
[08:50] <pitti> hah, sticky branding :)
[08:50] <pitti> tjaalton: but well, that can certainly be patched :-P
[08:50] <tjaalton> pitti: I bet, but for hardy?-)
[08:50] <pitti> PPAs FTW
[08:51] <tjaalton> ugh, maybe I'll write a wrapper which uses --no-splash
[08:55] <pitti> tseliot: nvidia-settings as well? was it tested?
[08:56] <pitti> tseliot: do I need to change anything in the source or can I just copy it verbatim from your PPA?
[08:57] <tseliot> pitti: superm1 told me that he has sponsored nvidia-settings for intrepid: https://edge.launchpad.net/ubuntu/+source/nvidia-settings/1.0+20080304-0ubuntu3
[08:57] <tseliot> pitti: the rest can be copied as it is
[08:57] <pitti> ah, nice
[08:59] <tjaalton> tseliot: I tried installing another version of nvidia-glx, and X fails to start after that. debugging why
[09:00] <tseliot> tjaalton: which version?
[09:00] <tseliot> I have tried them all (except for 71)
[09:01] <tseliot> which builds though
[09:01] <tjaalton> I had another version installed, then installed another one and then it fails to start
[09:02] <tseliot> tjaalton: can you tell me which versions then?
[09:02] <tjaalton> 173 ->96
[09:03] <tseliot> tjaalton: what does the /var/log/Xorg.0.log says?
[09:03] <pitti> tseliot: all copied; some builds started very soon and thus will fail to upload, but I'll care for them (retrying them)
[09:03] <tjaalton> tseliot: failsafe.. need to kill that first
[09:03] <pitti> tseliot: (that was unavoidable due to some soyuz restrictions, sorry)
[09:03] <tseliot> pitti: thanks
[09:04] <tseliot> tjaalton: ok, let me know
[09:05] <tjaalton> tseliot: ah, maybe just because the other drivers don't work with 1.5?
[09:05] <tjaalton> undefined symbol
[09:05] <tjaalton> so it fails to load nvidia_drv.so
[09:05] <pitti> tseliot: hm, bah; can you please check your email and tell me what soyuz complains about?
[09:06] <tseliot> pitti: nothing has arrived yet. I'll let you know
[09:06] <tseliot> tjaalton: does DKMS fail when it tries to build the module?
[09:07] <tjaalton> tseliot: no, it's not the kernel module but X driver that fails
[09:07] <tjaalton> the module loads fine
[09:08] <tseliot> tjaalton: when did you upload xserver 1.5
[09:08] <tseliot> ?
[09:08] <tjaalton> last week, but it was usable by tuesday
[09:08] <tjaalton> *on tuesday
[09:10] <tseliot> tjaalton: can you give me the line with the error?
[09:10] <tjaalton> (II) Loading /usr/lib/xorg/modules/drivers//nvidia_drv.so
[09:10] <tjaalton> dlopen: /usr/lib/xorg/modules/drivers//nvidia_drv.so: undefined symbol: miZeroLineScreenIndex
[09:10] <tjaalton> (EE) Failed to load /usr/lib/xorg/modules/drivers//nvidia_drv.so
[09:12] <tjaalton> see http://www.nabble.com/xorg-server-problem-td15226827.html
[09:13] <tseliot> tjaalton: the xserver ABI might be the cause of your problem
[09:13] <tjaalton> that's what I meant
[09:13] <tjaalton> nvidia should release new version of the legacy drivers
[09:13] <tjaalton> versions
[09:14] <tseliot> tjaalton: read this: http://www.nvnews.net/vbulletin/showpost.php?p=1461694&postcount=4
[09:14] <tseliot> and this: http://www.nvnews.net/vbulletin/showpost.php?p=1456802&postcount=2
[09:14] <tjaalton> funny that 173 supports it
[09:15] <tjaalton> those are old posts btw
[09:15] <doko> dholbach: -g shouldn't be used both for cc and as
[09:15] <tjaalton> fedora9 shipped with this, so it's not like there was no demand
[09:16] <tseliot> tjaalton: can you try setting RenderAccel to Off in the Device section of your xorg.conf and starting x with startx -- -ignoreABI
[09:16] <tseliot> ?
[09:17] <pitti> tseliot: ah, all built and in NEW now, processing
[09:18] <tjaalton> tseliot: ok, a sec
[09:18] <tseliot> pitti: good
[09:18] <pitti> E: nvidia-glx-71-dev: maintainer-script-calls-init-script-directly postinst:9
[09:19] <pitti> tseliot: hm, they still have an init script?
[09:19] <tseliot> pitti: let me check
[09:19] <pitti> tseliot: hm, seems they don't
[09:19] <tjaalton> tseliot: 'Option "RenderAccel" "false"'? Still fails with -ignoreABI
[09:21] <tseliot> tjaalton: sigh
[09:21] <tseliot> pitti: it's true, it calls /etc/init.d/nvidia-glx-71 start in the postinst of the -dev package o_O
[09:23] <tseliot> pitti: I'll see if the that init file is called from somewhere else, remove it and repackage the whole thing. I'll let you know
[09:23] <tseliot> tjaalton: at least 2 packages out of 4 will work...
[09:23] <tjaalton> tseliot: yep..
[09:25] <pitti> tseliot: another nitpick: I don't think that the i386 -kernel-source needs to ship nv-kernel.o.x86_64, and the amd64 one nv-kernel.o
[09:25] <pitti> tseliot: would save 10 MB in the packages
[09:26] <pitti> tseliot: ok, NEWed
[09:27] <tseliot> pitti: I'll look into that too
[09:28] <dholbach> doko: do you think you could follow up on the bug report about that?
[09:45] <gp> hi
[09:46] <gp> all my systems in office started behaving strangely around 8 pm ist
[09:46] <gp> all services super slow in lan
[09:46] <gp> but if i ssh my local computer by ip it takes lot of time
[09:47] <beuno> gp, this is *still* the wrong channel to ask for support
[09:47] <gp> tomm if its now fixed I will be blamed
[09:47] <Hobbsee> support in #ubuntu, no?
[09:47] <Hobbsee> beuno: wasn't this guy here last night, asking for support?
[09:47] <beuno> Hobbsee, he was  :)    and good evening to you
[09:48] <Hobbsee> beuno: evening :)
[09:48] <gp> yeah but the problem presists
[09:48] <beuno> gp, well, this being the wrong channel to ask for support still persists
[09:48] <gp> oks
[09:48] <beuno> you should head to #ubuntu, or try mailing lists/forums
[09:49] <gp> i hope its not  bug in ubuntu or something
[09:49] <gp> its happens in 100% ubuntu network in office
[09:49]  * beuno sighs
[09:50] <gp> windows box was working fine
[09:50] <Hobbsee> and, again, it's still the wrong channel.
[09:50] <gp> ok bye
[09:50] <Hobbsee> and you won't get support here.
[09:52] <RAOF> Given that nvidia discussion up there, I'd like to jump on the tail end:  I'm going to need to update xserver-xgl, since mesa no longer builds one of it's build-deps.
[09:53] <RAOF> While I'm at it, I'd like to blacklist all the drivers that running Xgl no longer makes sense for.  This essentially means: every driver but the 7-series nvidia driver.
[09:55] <tseliot> pitti: see if the new source looks better
[09:55] <Hobbsee> RAOF: pre or post alpha?
[09:55] <RAOF> Hobbsee: Post alpha.
[09:55] <tjaalton> RAOF: woo!
[09:55] <Hobbsee> ah, right
[09:55] <RAOF> tjaalton: No.  It'd be "Woo" if I was saying "Please remove xserver-xgl from the archives" :)
[09:55] <tjaalton> RAOF: hehe :)
[09:56] <Hobbsee> oh, -xgl.  that's that universe crack anyway, isn't it?
[09:56] <RAOF> Damn straight.
[09:56] <gp> #unbuntu == newbeee ??
[09:56] <RAOF> I can at least minimise the accidental damage, though, with only one minor problem: how do you detect the old'n'crusty driver?
[09:56] <Hobbsee> gp: #ubuntu == support channel.
[09:56] <gp> hehehehe
[09:57] <RAOF> Hm... alternatively I suppose I could check for t_f_p, and refuse to start if t_f_p is available.
[09:57] <RAOF> Now that I think of it, that seems a much better idea.  Test for the feature, not the driver version!
[09:58] <gp> i better ask google for support then
[09:58] <RAOF> I wonder if there's been a xgl commit in the last, say, 12 months...
[09:59] <savvas> how do you apply debdiffs?
[09:59] <RAOF> Oooh, a mere 4 months ago!
[10:00] <RAOF> Oh, and it looks like it doesn't misreport it's xrandr version anymore.  Joy!
[10:00] <RAOF> savvas: With 'patch'
[10:01] <dholbach> emgent: congratulations!
[10:01] <savvas> RAOF: patch < file.debdiff ?
[10:01] <nekostar> sup all ^^
[10:01] <RAOF> savvas: Pretty much.  You may want -p0 or -p1 or something.
[10:01] <savvas> hm.. ok, i'll read about that, thanks
[10:01] <RAOF> savvas: But debdiffs are just a normal, everyday diff.
[10:02] <nekostar> i've an honest non-fanboy question. do the group of you here consider hardy a truely successful release? compair say to edgy or fiesty
[10:02] <tjaalton> nekostar: wrong place for that
[10:03] <nekostar> tjaalton i was just curious as to how basic this is all gonna get is all tjaalton
[10:03] <nekostar> as i'm just walking in ;)
[10:04] <Hobbsee> nekostar: they're all successful.
[10:04] <Hobbsee> at least, have been so far.
[10:05] <nekostar> i would differ as to hardy and feisty, but apparently thats offtopic.
[10:05] <nekostar> anyway how does this work? i've not participated here before, sorry.
[10:05] <RAOF> Yup.  On-topic for #ubuntu-devel currently is: nvidia driver fun, bitching about Xgl, and... stuff.
[10:05] <RAOF> :)
[10:05] <Hobbsee> nekostar: as you'll see in the /topic, it's a channel to discuss development of ubuntu.  it's not a soapbox.
[10:05] <nekostar> heh sup RAOF ;)
[10:06] <nekostar> Hobbsee lets not fight today, i'm just not in it. i've already looked in the topic, thus the back to business question.... RAOF thanx.
[10:07] <savvas> RAOF: and if the patch involves a directory renaming (package version change) it does that automatically?
[10:07] <RAOF> tjaalton: There's nothing which replaces mesa-swx11-source, is there?
[10:07] <tjaalton> RAOF: nope.. does it still need that for something?
[10:07] <RAOF> tjaalton: Yes.  Xgl symlinks mesa source into its build tree.
[10:07] <tjaalton> yuck
[10:07] <RAOF> Hell, yes.
[10:09] <RAOF> I think Suse still use it.  I don't know how; it's never been released, and has had about 20 commits in the last year.
[10:09] <RAOF> Maintained by that famous recluse, David Reveman.  Maybe they've got some private repository where Xgl doesn't suck.
[10:10] <tjaalton> vnc4 is another user of mesa-swx11-source
[10:10] <tjaalton> and probably just as painful to migrate
[10:11] <RAOF> Why does vnc include mesa sources??
[10:11] <tjaalton> it includes xorg sources too, so why not?-)
[10:11] <RAOF> Heh.
[10:12] <RAOF> Man, that must be fun to maintain.
[10:12] <_max_> anyone happen to know what ubuntu 8.04 uses under the hood of "remote desktop"
[10:12] <emgent> dholbach: big thanks :)
[10:12] <nekostar> _max_ vnc via vino?
[10:12] <soren> _max_: In terms of...?
[10:13] <_max_> well i used the gui, set a password, worked fine,.. some jackass at work wanted another password since he cant memorize more than 1 pass, so i changed pass, and now neither of the passwords (old or new) works to login.
[10:13]  * gnomefreak not seeing nvidia fun :(
[10:13] <_max_> i couldn't find the daemon it was using so i rebooted the machine, and now the service doesn't even seem to have started.
[10:13] <_max_> ssh works so wanna edit config via ssh and restart daemon.
[10:15] <tjaalton> sheesh, the debian version of vnc4 still has xfree4.3.0 in it
[10:15] <RAOF> Surely there have been some security holes found in that?
[10:15] <tjaalton> but our version is not any better, with xserver-1.0.2
[10:16] <asac> RAOF: did you test gnash?
[10:16] <RAOF> asac: Yes.  It works, except for video.
[10:17] <asac> RAOF: yeah. same here. not sure, but the crash looks gstreamer related
[10:17] <RAOF> asac: Also, our flashplugin alternatives system is weird.
[10:18] <asac> pitti: could you let in nspr/nss SRU that fix regression introduced by current -proposed package (#245122)?
[10:18] <asac> pitti: i attacted the diffs on top of current -proposed packages to that bug
[10:19] <asac> pitti: ok, the current langpacks in ppa look good for proposed too
[10:19] <asac> ArneGoetje: ^^
[10:20] <pitti> asac: thanks, will do
[10:20] <pitti> nice
[10:22] <asac> RAOF: the alternative system is dumb yes.
[10:25] <_max_> okey "vino" seems really easy to setup, when it works.
[10:25] <tjaalton> RAOF: the reason why vnc4 build-deps on mesa source is that the old xorg-server it includes needed that.. sigh, I'll try to update vnc4
[10:25] <_max_> but trying to fiddle with it when it doesn't works is a friggin nightmware
[10:25] <_max_> *mare
[10:25] <RAOF> tjaalton: Rock on!
[10:25] <RAOF> Man, the brokenness exposed by a simple change :)
[10:27] <tjaalton> yeah :)
[10:27] <RAOF> Is there any chance of the mesa-source package making a comeback?
[10:27] <RAOF> Or should I be exploring different options?
[10:27] <tjaalton> could be, need to ask the debian guys
[10:28] <tjaalton> drop xserver-xgl?-)
[10:28]  * RAOF can just see and apt-get source command as a part of xserver-xgl's new get-orig-source target :)
[10:29] <RAOF> That'd be very nice, yes.  But there's still some hardware that it's useful on, and I don't particularly want to break that.
[10:29] <gnomefreak> doesnt new ati drivers fix the -xgl issue AFAIK that was the last one to be fixed
[10:30] <tjaalton> RAOF: you mentioned some nvidia chips? the blob doesn't work?
[10:30] <RAOF> gnomefreak: No.  nvidia-glx-legacy (or whatever it's called now) doesn't have t_f_p, and never will.
[10:30] <RAOF> I hear we have _yet another_ nvidia blob?
[10:30] <gnomefreak> ah yeah they wouldnt change it now i forgot legacy
[10:30] <tjaalton> yes, -173. -177 will drop support for GF5
[10:30] <RAOF> They're obviously aiming for the "most annoying to support" award of 2008.
[10:31] <gnomefreak> gf5 as in like 5200 5500?
[10:31] <tjaalton> yes
[10:31] <gnomefreak> crap
[10:31] <gnomefreak> i have 5200 :(
[10:31] <RAOF> gnomefreak: You've dropped of the "currently supported list"? :)
[10:31] <RAOF> Hah.
[10:31] <tjaalton> RAOF: ok, so the new nvidia-glx-71 doesn't work with t_f_p
[10:31] <RAOF> Man, they're not even ancient.
[10:32] <tjaalton> gnomefreak: we have maybe 200 machines (on linux) with 5200
[10:32] <gnomefreak> i have 3
[10:33] <gnomefreak> so this means i wont be using -173 or -177?
[10:33] <tjaalton> gnomefreak: -173 works
[10:33] <tjaalton> the last one
[10:33] <gnomefreak> ah cool
[10:34] <RAOF> At least when AMD drop support they're dropping support for cards with good open-source support.
[10:34] <RAOF> Uuur.
[10:35] <gnomefreak> should i bother with the PPA builds of nvidia or are we looking at a fix soon?
[10:35] <tjaalton> gnomefreak: they are in NEW
[10:35] <gnomefreak> ah sweet thanks
[10:37] <pitti> emgent: oh, welcome to the MOTU ranks!
[10:44] <emgent> pitti: thanks :)
[10:51] <pitti> gnomefreak, tjaalton: no, I NEWed them an hour ago, they should appear on archive.u.c. in about 10 minutes
[10:51] <tseliot> pitti: did you have a look at the ubuntu4 revision?
[10:52] <pitti> tseliot: not yet, sorry
[10:52] <tseliot> pitti: or are you referring to ubuntu3?
[10:52] <tseliot> ah, ok
[10:52] <pitti> ubuntu3 is in the archive for now
[10:52] <pitti> I'll look at ubuntu4 after finishing SRU processing
[10:53] <tseliot> pitti: by the way the init file would be called only if it existed. The postinst of nvidia-glx-ver removes it
[10:53] <tseliot> it's all fixed in ubuntu4
[10:53] <pitti> nice, thanks
[10:55] <jordi> crimsun: ping?
[10:56] <nekostar> pong?
[10:56] <nekostar> oo 51000 msec response... lively day ;)
[11:19] <pitti> tseliot: hm, isn't kernel.o.x86_64 needed on amd64?
[11:19] <pitti> tseliot: seems it's now gone from both i386 and amd64?
[11:22] <tseliot> pitti: ok, but nv-kernel.o is there right?
[11:22] <pitti> tseliot: right
[11:23] <pitti> well, it should be anyway, I just read the source debdiff, haven't checked the binaries
[11:23] <tseliot> pitti: that file will be taken from either the 32bit or the 64bit folder according to arch
[11:23] <pitti> +       #cp $(CURDIR)/$(dirname_x86_64)/usr/src/nv/nv-kernel.o $(CURDIR)/debian/temp/modules/nvidia-kernel/nv/nv-kernel.o.x86_64 || true
[11:23] <tseliot> pitti: the name of the file has to be nv-kernel.o
[11:23] <pitti> tseliot: I meant that
[11:23] <pitti> tseliot: shouldn't that be enclosed in some "if [ "`uname -m`" = ... ]" like test?
[11:24] <tseliot> pitti: it takes the name of the folder from the upstream_info
[11:24] <tseliot> which tests the arch
[11:25] <tseliot> pitti: it does something like if [ "$DEB_BUILD_ARCH" = "amd64" ] ; then
[11:25] <pitti> tseliot: ah, nice
[11:25] <tseliot> DIRNAME=NVIDIA-Linux-x86_64-${RELEASE}-pkg2
[11:26] <tseliot> pitti: by the way, I have almost finished the kernel postinst.d hook
[11:26] <pitti> nice, you made debconf work for that?
[11:27] <tseliot> pitti: debconf is called from a shell script /etc/kernel/postinst.d
[11:27] <slytherin> archive-admins: Please clear xml-commons-external from NEW to allow review of an update of batik. :-)
[11:28] <tseliot> pitti: the template is filled out according to the output of my Python script
[11:28] <tseliot> pitti: it works well :-) I'll send you the code ASAP
[11:36] <Caponetta> Hi
[11:37] <Caponetta> can someone help me. Im tryign to contact the developers of Moblin. Ive got ideas and i want to help and learn.
[11:37] <ln-> don't forget to use apostrophes.
[11:37] <cjwatson> Caponetta: #ubuntu-mobile
[11:37] <ogra> Caponetta, #ubuntu-mobile would probably be the better channel for his
[11:38] <Caponetta> Ok thank you
[11:39] <Caponetta> and ln i am pressing the apostraphe key its not showing..
[11:39] <ln-> i bet you are pressing the wrong key...
[11:39] <ln-> nevermind
[11:40] <ogra> punctuation is overrated anyway :)
[11:43] <soren> I've got a /dev/mapper/1ATA_ST3250620AS_6QE1D4GB2... Where might that be coming from?
[11:44] <soren> Oh, I know. Never mind.
[12:04] <pitti> tseliot: copied
[12:04] <tseliot> pitti: thanks a lot
[12:04] <pitti> tseliot: you deserve the thanks :)
[12:05] <pitti> tseliot: I see one major problem ATM: the -modalias packages are in multiverse, too, ATM
[12:05] <pitti> tseliot: so until we move everything to restricted, we can't ship/install them by default
[12:05] <pitti> tseliot: I put them into multiverse for now, due to alpha-2 freeze and everything
[12:05] <tseliot> pitti: ah, ok
[12:06] <pitti> but after alpha-2, l-r-m should just stop building nvidia-glx* and we can drop those and move the new ones into restricted
[12:06] <pitti> tseliot: can we talk about jockey/modalias/nvidia-glx-XXX integration at some point next week?
[12:07] <tseliot> pitti: sure. In the meantime, have a look at this: http://albertomilone.com/updater.png
[12:07] <norsetto> tseliot: do you know anything about dkms failing to build ati modules in intrepid?
[12:07] <pitti> tseliot: rocking!
[12:08] <tseliot> norsetto: it might depend on either the kernel (2.6.26) or on the new xserver ABI
[12:08] <tseliot> pitti: I'll send you the package later
[12:08]  * tseliot goes to lunch
[12:09] <norsetto> tseliot: don't eat too many orecchiette ...
[12:09] <tseliot> norsetto: ok, spaghetti then :-P
[12:09] <tseliot> later
[12:09] <norsetto> tseliot: hmmm, which reminds me that its lunch time for me too ;-)
[12:12] <pitti> mmm pasta
[12:13] <asac> pitti: will the langpacks go to intrepid directly?
[12:13] <pitti> asac: we don't build intrepid packs yet, since we don't have Rosetta exports yet
[12:13] <asac> pitti: right. just wondered if you copy the -proposed upload to intrepid
[12:14] <pitti> asac: yes, we can do that
[12:14] <asac> great
[12:14] <pitti> well, hm, not any more actually
[12:14] <asac> oh no :(
[12:14] <pitti> since intrepid got fresh builds, due to the recommends->suggests changes
[12:14] <asac> ok. i think intrepid users have then to chew an untranslated firefox for ... not sure how long :)
[12:15] <pitti> tseliot: the modalias lists don't have a package name ATM; so I need to fix that in jockey itself to use the modalias file name? tricky, but doable
[12:15] <norsetto> asac: so, is there life after death?
[12:15] <pitti> asac: hm, works fine for German, at least; is it special, or are the intrepid packs just recent enough?
[12:16] <asac> pitti: no ... ill upload 3.0.1 today ... which will disable the langpacks for you
[12:16] <pitti> ah
[12:16] <asac> pitti: the new langpacks mitigate that in future
[12:16] <pitti> asac: ABI breakage?
[12:16] <asac> i wasnt just brave enough to open up maxVersion in the 3.0.0 upload
[12:16] <pitti> in the 2.0 and 1.5 eras, older langpacks worked well with newer versions
[12:16] <asac> pitti: no. i intentionally kept 3.0 as maxVersio nin last upload because i feared that mozilla might change strings
[12:17] <asac> the new langpacks have 3.0.*
[12:17] <pitti> ah, ok
[12:17] <asac> (which is why i needed those in the first place)
[12:17] <pitti> asac: hm, "today"> keep alpha-2 in mind
[12:17] <asac> pitti: hmm
[12:17] <pitti> might not be entirely suitable at this point
[12:17] <impi226> hi... i am here because i want to take part in the development of ubuntu... but i don't know how to start... is there anyone here who can give me a good starting point?
[12:18] <asac> pitti: when are images done?
[12:18] <pitti> impi226: https://wiki.ubuntu.com/ContributeToUbuntu is a good starting point IMHO, with a wide range of things you can help with
[12:18] <norsetto> impi226: https://wiki.ubuntu.com/MOTU/GettingStarted is a good starting point
[12:18] <pitti> impi226: if you are particualrly interested in package development, you should give #ubuntu-motu a visit
[12:19] <impi226> i already read this articles
[12:19] <pitti> great!
[12:19] <norsetto> impi226: so, what is the problem? Perhaps we should move to #ubuntu-motu since that channel is more appropriate
[12:20] <asac> norsetto: you mean life after mplayer?
[12:20] <impi226> but okay
[12:20] <norsetto> asac: lol
[12:20] <asac> norsetto: i'll do them in the same batch that I'll do the debian security uploads
[12:20] <asac> which should happen really soon :/
[12:21] <asac> given that i manage to unbreak my etch/sid chroots
[12:21] <norsetto> asac: ok, I think you haven't read my last email yet then :-)
[12:21] <asac> norsetto: when send?
[12:21] <norsetto> asac: Monday 16:46:04
[12:22] <asac> i should have read that by now
[12:22] <asac> let me check
[12:24] <asac> norsetto: Jul 2 is last mail i got
[12:25]  * norsetto hopes this is not another joke :-(
[12:25] <asac> I'd love so say that its a joke, but i dont see that mail
[12:27] <norsetto> asac: ok, I'll resend it, you gave me once another email address but I think I lost that, do you mind giving it to me again?
[12:29] <norsetto> asac: anyhow, in a nutshell the question was: for mplayerplug-in and gecko-mediaplayer, should we make the transition to xulrunner-1.9 for intrepid (and break things for 1.8 based browsers) or not?
[12:33] <asac> norsetto: ill have to think about it
[12:33] <norsetto> asac: I can imagine ;-) danke!
[12:34] <slytherin> archive-admins: Please clear xml-commons-external from NEW to allow review of an update of batik. :-)
[12:37] <asac> norsetto: we can use 1.8 as as long as its still in intrepid
[13:19] <norsetto> asac: ok, makes sense to me
[13:19] <asac> norsetto: do you build depend on iceape-dev in debian?
[13:20] <norsetto> asac: yes
[13:24] <asac> fine
[13:39] <norsetto> asac: to be clear, the packages as they are build and work out of the box in both ubuntu and debian, there is no ubuntu specific bit which needs to be added to the debian packages
[13:49] <asac> ok good
[13:49] <asac> norsetto: not even flip build-depends?
[13:50] <norsetto> asac: nope :-) We are luky that libxul-dev is no more in Debian
[13:50] <asac> norsetto: hmm. how do the build-depends look like?
[13:51] <norsetto> asac: for gecko-mediaplayer? libxul-dev | iceape-dev
[13:52] <asac> norsetto: i guess that will fail on the buildds
[13:53] <asac> i think buildds dont try fallback build-depends
[13:53] <asac> at least i had a similar issue with enigmail
[13:53] <norsetto> asac: will it? It works on my unstable pbuilder
[13:53] <norsetto> asac: what? They just look for the first one and if not found bail out? Why bother with the fallbacks then!?!?
[13:54] <cjwatson> Debian and Ubuntu differ in this respect
[13:54] <asac> norsetto: as far as i understand its because the buildd cannot tell whether the primary build-depend is missing intentionally or if it should just wait for it
[13:54] <cjwatson> Debian doesn't try fallback build-dependencies; Ubuntu does
[13:54] <cjwatson> (IIRC, anyway)
[13:54] <asac> cjwatson: ubuntu does?
[13:55] <cjwatson> this is because in Ubuntu's case the fallback one might be in universe and there might be a working one in main
[13:55] <asac> norsetto: if so, flip them ... e.g. make libxul-dev secondary
[13:55] <norsetto> cjwatson, asac: oh gosh (/me bump his head against the wall)
[13:55] <cjwatson> (now lamont will turn up and tell me I have hideously misremembered)
[13:55] <asac> ok cool. i can then do enigmail in this way too ;)
[13:55] <lamont> huh!??
[13:55]  * norsetto bump Deb and Ian heads against the wall too
[13:55] <pitti> it definitively did that in the past, and allowed us to sync some packages and avoid a pointless delta
[13:55] <pitti> not sure whether it's still true, though
[13:56] <pitti> but it worked for stuff like "b-deps: links | elinks"
[13:56] <asac> cjwatson: even if its wrong, you gave us hope for a while :). which is a good thing.
[13:56] <cjwatson> yay, a successful invocation
[13:56] <norsetto> asac: we can't reverse, or it will use iceape-dev in Ubuntu too as a build-dep
[13:56] <asac> norsetto: we dont have iceape-dev
[13:56] <asac> norsetto: if we had that, we wont have a problem at all
[13:56] <lamont> cjwatson: debian always only tries the first one.  this uber-perl-hacker I know (thanks cjwatson) wrote a nice sbuild patch to try all of them for existance and take one if found, specifically because of main build-dep: universe | main
[13:56] <norsetto> asac: last I checked, we did have it !?
[13:56] <asac> norsetto: i think only in gutsy
[13:57] <norsetto> asac: iceape-dev | 1.1.9+nobinonly-0ubuntu1 | intrepid/universe | all
[13:57] <asac> norsetto: oh. so it came back ;)
[13:57] <asac> fine
[13:57] <lamont> cjwatson: so yes, you misremembered :-p
[13:57] <asac> norsetto: hmm. thats a transitional package for seamonkey
[13:58] <asac> norsetto: we have to fix seamonkey first, before we can use that
[13:58] <cjwatson> lamont: erm, I did? that matches the description I gave above
[13:58] <cjwatson> and I was about to say "yay, I remembered correctly"
[13:58] <asac> damn
[13:58] <asac> quite a short time of happiness ;)
[13:58] <cjwatson> except I meant to say "in Ubuntu's case the primary one might be in universe but there might be a working fallback one in main"
[13:59] <soren> cjwatson: FYI: https://lists.ubuntu.com/archives/kernel-team/2008-July/002701.html  <--- Fixes Intrepid guests in kvm.
[14:00] <cjwatson> ooh, thanks!
[14:00]  * soren bows
[14:01] <soren> Happy to be of service.
[14:02] <lamont> cjwatson: right.
[14:03] <lamont> so yeah, you remember.
[14:13] <tmmoyer> I am trying to do some custom work with the installer, and was wondering if anyone could tell me what I need to add to /etc/apt/sources.list to be able to fetch packages like finish-install and other udebs used by the installer?
[14:14] <Lrrr> tmmoyer: lemme see
[14:16] <Lrrr> tmmoyer: If you do apt-cache showsrc finish-install, do you get any output?
[14:16] <tjaalton> asac: shouldn't ff3 read a site-wide config from /etc/ff-3.0/pref/*
[14:16] <tmmoyer> Lrrr: yes it does show the information for finish-install
[14:17] <asac> tjaalton: it should
[14:17] <tjaalton> asac: also, ff3 doesn't seem to use /usr/share/ubuntu-artwork/home/*index.html anymore
[14:17] <Lrrr> tmmoyer: the you can fetch the source to it, so you don't need to add anything particular in your sources.list
[14:17] <asac> tjaalton: install ubufox to get the best homepage experience
[14:17] <tjaalton> asac: is there a way to debug the startup?
[14:17] <asac> tjaalton: the startup`
[14:17] <asac> ?
[14:18] <asac> is there a bug?
[14:18] <Lrrr> tmmoyer: But installer development is done through launchpad.  You can fetch the last version of the individial installer packages there.
[14:18] <tjaalton> asac: ubufox is installed.. I'll check it out. startup meaning that what it loads on startup
[14:18] <asac> tjaalton: 1st. check that the default home page is really the default ;)
[14:18] <asac> in preferences -> Content (iirc)
[14:18] <cjwatson> tmmoyer: regular 'apt-get source' will work; actually installing udebs on a normal system is a very bad idea
[14:19] <asac> err, Main :)
[14:19] <cjwatson> tmmoyer: http://wiki.ubuntu.com/InstallerDevelopment
[14:19] <tmmoyer> cjwatson: I'm not installing them on my system, I am getting the source and modifying some of the packages
[14:19] <tjaalton> asac: yes, it shows the ubufox page, but I'd like to change that :)
[14:19] <cjwatson> tmmoyer: right, so Lrrr's answer is correct, i.e. "nothing"
[14:20] <tmmoyer> Lrrr: Since I am customizing to a specific release, I would prefer to use the same packages as are already being used by the installer
[14:20] <asac> tjaalton: then whats the problem?
[14:20] <cjwatson> tmmoyer: so if you have the appropriate deb-src lines for that release then you'll be just fine
[14:20] <tmmoyer> cjwatson: thanks
[14:20] <tjaalton> asac: system wide..
[14:21] <asac> good point ;)
[14:21] <asac> tjaalton: what you could do is introducing a locked pref
[14:22] <asac> tjaalton: that should prevent it from being overwritten
[14:23] <tjaalton> asac: the problem is that users should be able to change it. we used to have a locked pref because there was no alternative, until I noticed the ubuntu-artwork stuff
[14:23] <ScottK> slangasek: Debian claims to have fixed Bug 138189 - Should that wait until after alpha2 or do you want a fix nowish?
[14:25] <asac> tjaalton: ill think about the options
[14:25] <tjaalton> asac: cool, thanks
[14:26] <lamont> dear firefox.  if I switch to a different tab while you're fetching a page, I really _DO_NOT_WANT_ you to automatically yank me away from what I'm doing to visually smack me in the face with the finally-fetched web page.  I'll get back to it, honest.
[14:26] <lamont> no love
[14:26] <liw> lamont, firefox does that? ugh
[14:26] <lamont> yeah.
[14:26] <lamont> laggy links for the los
[14:26] <lamont> s
[14:26] <tedg> I hate that too.  Epiphany.
[14:27] <liw> tedg, hmm, my epiphany doesn't do that
[14:27] <tedg> Now that FF redid their search bar to make it more like Epiphany it's one of the biggest reasons I still use Epiphany.
[14:28] <tjaalton> asac: maybe I can modify ubuntu-mods.js and distribute it
[14:29] <asac> tjaalton: we should add preferences for "other" homepages in ubufox imo
[14:29] <asac> so admins can add their ubufox.online.homepage and ubufox.offline.homepage and ubufox.always.offline settings in /etc/
[14:30] <tjaalton> asac: ok, that would be nice
[14:30] <asac> the other thing is that firefoxs load order should not do 1. package, 2. /etc/ 3. extensions, 4. profile, but 1. package, 2. extensions, 3. /etc/, 4. profile
[14:30] <tjaalton> yeah...
[14:30] <asac> i think thats a bug - which might be not-so-easy to fix
[14:35] <asac> tjaalton: #247281
[14:38] <tjaalton> asac: ok, so actually, it _did_ load my file from /etc/ff-3.0/pref, but only those settings that hasn't been set by ubufox :)
[14:38] <norsetto> asac: ok, we now have iceape-dev only as a b-d for gecko-mediaplayer (a small delta for us but a big leap for humankind, etc. etc.)
[14:38] <asac> tjaalton: yeah. thats what the bug is about ;)
[14:38] <asac> norsetto: does it build with iceape-dev?
[14:39] <asac> norsetto: and more important: does it work in xulrunner-1.9 still
[14:39] <norsetto> asap: in Debian you mean, or in Ubuntu?
[14:39] <norsetto> asap?
[14:39] <tjaalton> asac: ok, so I'll change what I can in ubuntu-mods.js
[14:39] <tjaalton> directly
[14:39] <norsetto> asac: in Debian you mean, or in Ubuntu?
[14:40] <norsetto> asac: it builds in both, but we don't want to build with that in Ubuntu, we will have to change it everytime
[14:40] <asac> norsetto: in ubuntu
[14:40] <asac> norsetto: we want to build with that in the end
[14:40] <asac> norsetto: i think it just doesnt work atm
[14:41] <asac> norsetto: please confirm that it breaks in xulrunner-1.9 if build with current iceape-dev
[14:41] <norsetto> asac: to builds it builds, I know because I tested that already, I can check to see if the plugin works with firefox-3.0
[14:43] <asac> tjaalton: maybe we should fix firefox extension manager to read a syspref directory for every extension as well
[14:43] <asac> that might be simple
[14:44] <asac> tjaalton: for now you can dump a link ZZsystem-config.js to your /etc/firefox-3.0/pref/myprefs.js in the ubufox defaults/preferences directory
[14:44] <asac> tjaalton: does that help?
[14:45] <norsetto> asac: back to square 0, with latest iceape-dev in intrepid it doesn't even build, I could try to see if I can patch the configure stuff
[14:45] <tjaalton> asac: ok, I'll try
[14:45] <asac> norsetto: ok. makes sense. I will take that into account when i fix seamonkey
[14:46] <asac> norsetto: so for now we have to change the build-depends i guess
[14:46] <norsetto> asac: so far yes, everything else should still be cool for Debian
[14:47] <tjaalton> asac: yeah, that works :)
[14:47] <asac> tjaalton: good
[14:48] <norsetto> asac: its looking for iceape-plugin.pc and iceape-xpcom.pc
[14:51] <asac> norsetto: yes. i think we will ship compatibility links in the iceape-dev package
[14:57] <norsetto> asac: hmmm, there is something fishy in there, there was a check for seamonkey already, but was misspelled as seamokey, but even correcting that it still doesn't find the .pc files
[14:57] <asac> norsetto: strange
[14:58] <norsetto> asac: ahhh, I see why, libnspr-dev its not a depends of seamonkey-dev
[14:59] <asac> norsetto: add libnspr4-dev then. shouldnt hurt in debian
[15:00] <norsetto> asac: yes, its already dragged in by iceape-dev in any case for them
[15:04] <norsetto> asac: ok, now it fails because it doesn't find the xpidl compiler
[15:07] <asac> norsetto: hmm. yeah. i think we need libxul-dev until i fix seamonkey to ship the complete sdk
[15:08] <norsetto> asac: yes, alas there is no xpidl in seamonkey-dev
[15:10] <sladen> what's Agostino Russo's latest IRC nick?
[15:12] <evand> sladen: xivulon
[15:15] <norsetto> asac: I'm just amazed at how you guys can manage to keep a brain sane with all this iceape/seamonkey/firefox/xulrunner/xulrunner-1.9 stuff
[15:22] <wereHamster> Hardy doesn't use xorg autoconfiguration, and uses the xkb keyboard driver. Are there any plans to change that in the next release?
[15:28] <Kano> hi, what is scrollkeeper and why does it take ages when i install some packages while registering documents with scrollkeeper?
[15:29] <wereHamster> Kano: have you tried asking google?
[15:29] <persia> Kano: Insufficient implementation of dpkg-triggers
[15:30] <Kano> persia: when will it be fixed?
[15:30] <persia> Kano: Sometime after someone builds a working trigger for scrollkeeper, and submits patches for all packages that use scrollkeeper.
[15:35] <Kano> persia: how to disable that man-db trigger
[15:36] <ogra> persia, upstream works on a scrollkeeper replacement i was told
[15:37] <ogra> so with a little luck scrollkeeper will die soon :)
[15:37] <kirkland> cjwatson: could have you a look at the patch for https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/247103 at your earliest convenience?
[15:38] <persia> ogra: Excellent news!
[15:39] <ogra> persia, http://live.gnome.org/Yelp/Spoon
[15:39] <ogra> for reference
[15:40] <persia> http://rarian.freedesktop.org/
[15:40] <seb128> what is the discussion about?
[15:41] <ogra> seb128, just a question about scrollkeeper slowness
[15:41] <seb128> alright
[15:42] <seb128> we will switch in intrepid soon
[15:42] <ogra> yay
[15:42] <seb128> not this week though, I'm busy at GUADEC
[15:42] <ogra> bah, slacker
[15:42] <ogra> :)
[15:43] <ogra> how is istanbul ?
[15:43] <seb128> great
[15:43] <seb128> the weather is a bit too hot during the day though
[15:43] <Hobbsee> how hot?
[15:44] <seb128> over 30°C
[15:44] <seb128> which is probably nothing for you
[15:44] <StevenK> Can we swap?
[15:44] <Hobbsee> yummy!
[15:44] <Hobbsee> that's still reasonably warm.  people here would be complaining at that sort of temperature.
[15:44]  * Hobbsee would actually be warm at that temperature, though :P
[15:44] <seb128> on holidays that's alright
[15:45] <Lrrr> I'd complain.  It is humid?
[15:45] <seb128> 62% humidity apparently
[15:46] <seb128> looking quickly on a weather website
[15:46] <Hobbsee> ouch.
[15:46] <Lrrr> that's less than where I live can deliver.
[15:48] <seb128> alright, enough IRC for now, see you later
[15:49] <ogra> seb128, enjoy :)
[16:05] <cjwatson> stgraber: fix for your encrypted LVM bug in progress
[16:05] <cjwatson> stgraber: did you file a bug for it? (if you didn't, don't worry, just want to know so I can close it)
[16:10] <cjwatson> hmm, except that it created /dev/mapper/system-root and then randomly removed it. odd
[16:10] <Hobbsee> strange.  since when does networking not work in an intrepid chroot?
[16:10] <Hobbsee> (when the host does)
[16:11] <soren> What doesn't work?
[16:11] <Hobbsee> apt-get update
[16:11] <StevenK> How doesn't it work?
[16:11] <Hobbsee> (if you're meaning me)
[16:11] <soren> Hobbsee: I did.
[16:11] <StevenK> Hobbsee: Perhaps /etc/resolv.conf didn't get copied?
[16:11] <Hobbsee> Err http://ppa.launchpad.net intrepid Release.gpg
[16:11] <Hobbsee>   Could not resolve 'ppa.launchpad.net'
[16:11] <soren> Hobbsee: Do you have a resolv.conf in there?
[16:11] <Hobbsee> StevenK: it was working when i last booted there...
[16:11] <soren> That's what they all say.
[16:12] <StevenK> Heh
[16:12] <Hobbsee> yes, it's blank.
[16:12] <Hobbsee> # generated by NetworkManager, do not edit!
[16:12] <ogra> StevenK, since whne does it get copied automatically ?
[16:12] <StevenK> Which would explain why it can't resolve names ... :-)
[16:12] <soren> Unblank it.
[16:12] <Hobbsee> apart from ^
[16:12] <StevenK> ogra: I thought debootstrap did that ...
[16:12]  * ogra definately never had a resolv.conf in the ltsp chroots
[16:12] <soren> Nope.
[16:12] <ogra> i have a plugin in the chroot builder for that
[16:12] <Hobbsee> oh, so if n/m's not running on the system, it all falls over and dies?  great.
[16:13] <soren> How do you get into the chroot?
[16:13] <soren> pbuilder, schroot or just plain chroot?
[16:13] <Hobbsee> chroot
[16:13]  * Hobbsee copies the host system version in.  there we are.
[16:14] <cjwatson> StevenK: yes, it does
[16:14] <cjwatson>         conditional_cp /etc/resolv.conf "$TARGET"
[16:14] <StevenK> Hah, I win.
[16:14] <StevenK> :-P
[16:14] <ogra> cjwatson, hmm ? how do i trigger that ?
[16:14] <ogra> its not done by default for me
[16:14] <ogra> and never was
[16:15]  * ogra would love to drop that plugin from ltsp
[16:15] <cjwatson> (since forever, I think)
[16:15] <ogra> hmm
[16:16] <cjwatson> it's done by default. perhaps when debootstrap runs for you /etc/resolv.conf doesn't exist
[16:16] <ogra> ltsp-build-client by defalt uses network packages ...
[16:16] <ogra> so indeed it exists on the server i run it on
[16:16] <cjwatson> in d-i, you run ltsp-build-client chrooted into /target, yes?
[16:16] <Hobbsee> cjwatson: if you're talking to me, i doubt that's the case, as this is a proper intrepid system, on another partition
[16:17] <cjwatson> at one point in the past, /etc/resolv.conf wasn't copied by that point
[16:17] <cjwatson> Hobbsee: was talking to ogra
[16:17] <Hobbsee> cjwatson: ah, sorry.  couldn't tlel.
[16:17] <ogra> cjwatson, yes, but i'm talking about a normal manual run of ltsp-build-client
[16:17] <cjwatson> Hobbsee: in your case it looks like NM was confused at the time
[16:17] <ogra> i see that function should also copy /etc/hostname
[16:17] <ogra> which definately doesnt happen either here
[16:18]  * soren concurs
[16:18] <cjwatson> ogra: afraid I don't know, you'll have to dig into it
[16:18] <ogra> yeah, just looking at the code ...
[16:18] <ogra> but all we do is call debootstrap ... no special stuff there
[16:18]  * cjwatson suggests set -x in debootstrap
[16:19] <ogra> hmm, its run from first_stage_install and i acually have all changes that function does ...
[16:21] <ogra> intresting ... in my development chroots its actually correct, just not in ltsp client chroots
[16:21]  * soren tries a vm-builder run with sh -x debootstrap
[16:22] <ogra> ogra@osiris:~/Devel/ltsp$ grep debootstrap ltsp-trunk/server/plugins/ltsp-build-client/Ubuntu/010-debootstrap
[16:22] <ogra>         debootstrap $DEBOOTSTRAPOPTS --arch $ARCH $DIST $ROOT $MIRROR
[16:22] <ogra> DEBOOTSTRAPOPTS is usually empty ....
[16:22]  * ogra scratches head
[16:39] <stgraber> cjwatson: hi, no I didn't file a bug for it, just reported it as a failed for Manual partitioning on the ISO tracker.
[16:44] <orbisvicis> when patches are numbered 000 to 030, etc does that mean anything when i create my patch, 031 ?
[16:51] <cjwatson> orbisvicis: it's just ordering, that's all
[16:52] <orbisvicis> cjwatson, i still patch my changes against the original /sources/file.c ?
[16:53] <tseliot> does anybody know who approves the messages in the ubuntu-devel mailing list?
[16:53] <cjwatson> orbisvicis: depends on the patch system
[16:53] <cjwatson> orbisvicis: with dpatch, for instance, you should read the documentation for dpatch-edit-patch and use it
[16:53] <cjwatson> tseliot: me and others. Why?
[16:54] <ogra> orbisvicis, use a patch tool like dpatch-edit-patch or wahtever your package uses ... it might be that other patches touched the file before
[16:54] <orbisvicis> ogra, thats what i worried about
[16:54] <orbisvicis> howeverm i only see 30 patches, no config files for anypatch systems
[16:54] <tseliot> cjwatson: I sent a message to the mailing list to add useful information on the drivers in Intrepid but I received as a reply that it's a moderated list
[16:55] <cjwatson> tseliot: that is correct
[16:55] <cjwatson> orbisvicis: https://wiki.ubuntu.com/MOTU/School/PatchingSources
[16:55] <evand> approved
[16:56] <cjwatson> tseliot: there is no need to ask about moderation - we're pretty well on top of the queue
[16:56] <cjwatson> it's generally processed several times per working day
[16:56] <orbisvicis> cjwatson, ty. any links like that for pbuilder ?
[16:57] <cjwatson> orbisvicis: the wiki has an excellent search feature
[16:57] <tseliot> evand: thanks
[16:57] <cjwatson> (sorry, apparently I should have pointed to https://wiki.ubuntu.com/PackagingGuide/PatchSystems instead)
[16:57] <tseliot> cjwatson: sorry, it was my 1st message in the mailing list
[17:00] <orbisvicis> cjwatson, id like to know why pdebuilder doesnt need to be root to build a package when the base dir is /var/cache/pbuilder and owned by root. and how i can tell the difference between fakeroot and other files
[17:01] <cjwatson> orbisvicis: the only reason root is required to build a package is to get file ownerships right, and fakeroot simulates enough stuff to allow that to work without root. Most uses of pbuilder only *read* the base tarball from /var/cache/pbuilder and unpack it elsewhere; they don't write to /var/cache/pbuilder.
[17:02] <cjwatson> orbisvicis: please take further questions like this to #ubuntu-motu
[17:03] <orbisvicis> cjwatson, thanks
[17:39] <slangasek> ScottK: 138189> better after alpha2; how was it fixed in Debian?
[17:40] <ScottK> slangasek: Changed the name of the .so that it links to.  I swear I tried the same thing and it didn't work.
[17:40] <slangasek> ScottK: as in, libpython2.5.so -> libpython2.5.so.1.0?
[17:41] <ScottK> Yes.
[17:41] <slangasek> that is the right fix, but kde-guidance still has to be rebuilt after the change is made in pykdeextensions
[17:41] <ScottK> Yes.
[17:41] <ScottK> Also need to drop the libpythonize-dev dependency too (I think that was it, I have notes).
[17:43] <ScottK> slangasek: We are close to dropping the KDE front ends for that package (for KDE4 alternatives).  Once the KDE specific stuff is gone, I intend to rename the source package to not have kde in the name.
[17:46] <slangasek> so did the Debian maintainers do anything about ensuring smooth upgrades? (conflicts with old versions of kde-guidance?)
[17:46] <ScottK> No.  We're ahead of them in the transition.  For guidance-power-manager (which was ported to KDE4 and is in a separate package) we've done that.
[17:46] <ScottK> For the display stuff, it's yet to be done.
[17:47] <ScottK> Debian will get this fun post-Lenny.
[18:01] <alex-weej> in light of the recent mails on devel-discuss, i filed this bug with the "regression" tag
[18:01] <alex-weej> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/247335
[18:01] <alex-weej> did i do it right?
[18:15] <cjwatson> http://people.ubuntu.com/~cjwatson/ubuntu-policy/ - work in progress
[18:21] <soren> cjwatson: Interesting.
[18:22] <soren> cjwatson: We talked about renaming Vcs- headers to XS-Debian-Vcs- a while back... Will that be mentioned?
[18:23] <cjwatson> XS-Original- actually
[18:23] <cjwatson> like XSBC-Original-Maintainer
[18:24] <cjwatson> Vcs-* isn't mentioned yet, so I'm unsure about doing that
[18:25] <soren> cjwatson: Sure?
[18:25] <cjwatson> BTW, for those who weren't in the UDS session, the plan is to get something vaguely right and then open it up for group maintenance, so you send a patch to ubuntu-devel, get somebody to second it, then get it applied
[18:25]  * soren looks for the thread on the ml..
[18:25] <cjwatson> <cjwatson@sarantium ~/src/ubuntu/debian-policy/debian-policy>$ grep -i vcs policy.sgml
[18:25] <cjwatson> <cjwatson@sarantium ~/src/ubuntu/debian-policy/debian-policy>$
[18:25] <soren> Oh, they're not even mentioned in Debian's..
[18:26] <cjwatson> there is a changelog entry mentioning adding Vcs-Browser and Vcs-Git, but it's talking about the debian-policy package's own control file
[18:26] <norsetto> soren: they are in the maintainers guide IIRC
[18:26] <soren> https://lists.ubuntu.com/archives/ubuntu-devel/2007-March/023366.html You suggested it yourself, and mdz seconded it... I've been renaming them to XS-Vcs-Debian myself. :/
[18:27] <soren> "it" being using "Debian" rather than "Original".
[18:27] <cjwatson> hmm, yeah
[18:27] <cjwatson> I don't seem to have adopted that myself yet, but fair point
[18:28] <soren> It's worth considering.
[18:28] <cjwatson> XS-Vcs-Debian definitely seems irregular, should be XS-Debian-Vcs if anything
[18:29] <soren> Did I say XS-Vcs-Debian? That was certainly a mistake if I did.
[18:29] <cjwatson> the only major thing in UbuntuPackagingChanges that I haven't applied yet is the LSB init script stuff
[18:29]  * soren wanders off to the store..
[19:00] <BenC> is there a param to pass on the kernel command line to tell the livecd which xorg driver to use?
[19:01] <ogra> you could boot in commandline mode and fiddle with the config
[19:01] <ogra> it has a textmode option iirc
[19:02] <hwilde> where is the src for the /sbin/init  binary ?
[19:03] <ogra> hwilde, totally depends on your distro ;)
[19:04] <ogra> for recent fedora and ubuntu its in upstart ... for others likely in some sysv-init package
[19:05] <hwilde> why is it called upstart this is so confusing
[19:05] <ogra> hwilde, whoops ignore that
[19:05] <ogra> i thought i was in #ltsp :)
[19:05] <ogra> its indeed in upstart :)
[19:06] <hwilde> lol
[19:06] <hwilde> I usually am in ltsp too
[19:06] <hwilde> just not right now
[19:06] <ogra> its called like that because its creator picked that name ... its a new concept and that the binary is called init is just for compatibility reasons i guess
[19:07] <ogra> if you dont do that all apps relying on it to be called like that will have to be patched
[19:07] <hwilde> ok so umm I have the src now
[19:07] <laga> eg the kernel ;)
[19:08] <ogra> (i.e. if you would call it /sbin/upstart instead)
[19:08] <hwilde> upstart-0.3.9
[19:08] <hwilde> but where is the src for /sbin/init
[19:08] <hwilde> oh maybe in the init directory
[19:09] <hwilde> man... rough day
[19:09] <ogra> :)
[19:09] <hwilde> ok now here is what I don't understand
[19:09] <hwilde> if /sbin/init calls /etc/init.d/rc.local
[19:10] <hwilde> where is rc.local referenced in the upstart src ??
[19:11] <james_w> hwilde: see /etc/rc2.d/S99rc.local
[19:13] <hwilde> james_w, ok fair enough, but what calls /etc/rc2.d/S99rc.local
[19:14] <ogra> hwilde, init is dumb, it just walks the rc dir of the initlevel
[19:14] <hwilde> so init runs through every file in /etc/rc2.d
[19:14] <hwilde> /etc/rc2.d/S99rc.local calls /etc/init.d/rc.local
[19:14] <ogra> what exactly are you trying ?
[19:15] <hwilde> and /etc/init.d/rc.local calls /etc/rc.local ?
[19:15] <hwilde> I'm just trying to unravel the boot sequence
[19:15] <ogra> right, if /etc/rc.local is executable the initscript calls it
[19:28] <cjwatson> /etc/rc2.d/S99rc.local *is* /etc/init.d/rc.local (symlink), it doesn't call it
[19:29] <cjwatson> /etc/init.d/rc walks through the runlevel directory
[19:29] <ogra> ah right
[19:29] <cjwatson> /etc/event.d/rc[0-6] calls /etc/init.d/rc
[19:29] <cjwatson> upstart reads /etc/event.d/* natively
[19:29] <ogra> not init on its own
[19:30] <cjwatson> however, it might be less confusing to walk through that the other way round if you're trying to understand the boot sequence: rather than taking a script and trying to figure out what calls it, start from init and figure out what it calls
[19:33] <hwilde> except init doesn't really exist, it's called upstart
[19:33] <hwilde> and it doesn't actually reference anything, it walks through the entire /etc/rcX.d directory
[19:33] <hwilde> and those files doesn't actually exist, they are simlinks
[19:33] <hwilde> other than that it's really straightforward
[19:35] <cjwatson> nothing there is especially non-straightforward
[19:35] <cjwatson> packages often provide binaries that are not identical to the name of the source package
[19:35] <cjwatson> walking through directories is completely standard for extensible programs
[19:35] <cjwatson> symlinks are trivial Unix functionality
[19:36] <cjwatson> you only find it difficult to unpick because you're working from the bottom up :)
[19:36] <cjwatson> don't do that, and it will be easier
[19:39] <hwilde> the real problem is some noob copied /etc/rc.local to /etc/init.d/rc.local
[19:39] <hwilde> then things didn't work the way they expected
[19:39] <hwilde> then they started editing things
[19:39] <ogra> yay, fun
[19:39] <hwilde> now I have to untangle it
[19:39] <hwilde> but i'm not even sure how it was supposed to be in the first place
[19:39] <hwilde> never had to look into that bc i've never messed it up
[19:40] <ogra> reinstalling initscripts should give you the original /etc/init.d/rc.local back ...
[19:41] <cjwatson> err
[19:41] <ogra> not ?
[19:41] <cjwatson> only if you use the dpkg --force-confnew option
[19:41] <cjwatson> it's a conffile - you only get a resolution prompt if it has changed on both sides
[19:42] <cjwatson> personally, if I didn't know the tools inside out, I would find another system running the same version of Ubuntu and 'diff -ru' the two /etc directories
[19:42] <ogra> meh, indeed
[19:43] <cjwatson> then you will be able to see the differences in files you know got clobbered, and undo them
[19:43] <cjwatson> (DO NOT JUST BLAT A NEW /etc OVER THE OLD ONE)
[19:43] <sbeattie> BTW, is there a way to get dpkg to report which files are marked as conffiles?
[19:44] <cjwatson> they're all in Conffiles: fields in the status file
[19:44] <pitti> sbeattie: dpkg -s <packagename> shows them for a particular package
[19:44] <cjwatson> 'dpkg -s' on a given package name will show them
[19:44] <cjwatson> snap
[19:44] <pitti> sbeattie: /var/lib/dpkg/status has a list of all known ones, too
[19:44] <sbeattie> ah, there we are. Thanks pitti and cjwatson
[19:45] <cjwatson> rather than reading /var/lib/dpkg/status directly, install dctrl-tools and run: grep-status -sPackage,Conffiles -rFConffiles .
[19:45] <cjwatson> that'll show everything
[19:46] <cjwatson> (the dot at the end is part of the command, not a full stop)
[19:47] <sbeattie> ah, regex for any char
[19:47] <Lrrr> bzr shelve is fiiine
[19:48] <cjwatson> way ahead of you :-): http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2006-01-09-bzr-shelve.html
[19:48] <Lrrr> I'm a Mercurial guy.
[19:49] <Lrrr> hg record sucks a bit compared to that.
[19:50] <sbeattie> Lrrr: do you use mqueues?
[19:51] <Lrrr> sbeattie: Not really.
[19:51] <cjwatson> the problem with 'hg record' (and the similar 'darcs record') is that you end up committing something that has never existed in isolation, and therefore by definition cannot have been tested in isolation, in your working tree
[19:51] <Lrrr> sbeattie: I've used it though.
[19:52] <Lrrr> sbeattie: But I see you might mean that you can use mq in way similar to shelve.  If so, you are probably right.
[19:52] <sbeattie> Well, maybe.
[19:53] <sbeattie> I'm a longtime quilt user and found shelves counterintuitive, though the hunk-by-hunk nature of shelve is nice.
[19:54] <sbeattie> but I haven't tried the bzr loom plugin yet, either.
[19:54] <Lrrr> My discovery of hg record is rather recent, so I have not grown use to anything yet.
[20:08] <pitti> speaking about bzr, "bzr rebase" FTW, too
[20:13] <Lrrr> bzr has so much nice things but still feels slower than Mercurial
[20:22] <slytherin> asac: is xulrunner-1.9-dev supposed to libxul-dev?
[20:26] <Lrrr> cjwatson: Germinate question again.  I want to manager 2 distributions sharing seed names in a single meta-package.  Is there some kind of way to make the seed outputs not overwrite each other or do I need to patch germinate again?
[20:29] <asac> slytherin: ?
[20:30] <geser> asac: add a "replace" to his question
[20:31] <slytherin> asac: I was trying to merge classpath from debian. Debian doesn't have xulrunner-1.9-dev yet so the package compiles fine there. When I replace libxul-dev with xulrunner-1.9-dev the gcjwebplugin fails to build. Reason seems to be that plugin related header files are in wrong path.
[20:44] <Amaranth> anyone know what the heck is going on with xorg? something broke compiz
[20:46] <kirkland> So I'm writing an MIR for a source package that produces multiple binaries, of which the *only* one I actually need in main is the library/headers one
[20:46] <kirkland> Can I propose that only that binary package be promoted to main?
[20:48] <asac> slytherin: doesnt debian have xulrunner-dev instead?
[20:48] <slytherin> kirkland: why do you want it that way?
[20:48] <kirkland> slytherin: b/c i only need the library as a build dependency for another MIR.  the other binary packages have daemons, open network ports, etc.
[20:49] <_MMA_> slytherin: Because like he said he only cares about 1 of the binaries.
[20:49] <_MMA_> gah. too late.
[20:50] <cjwatson> Lrrr: I'd just run germinate-update-metapackage twice in two different temporary directories
[20:50] <cjwatson> or maybe not even temporary
[20:51] <slytherin> asac: yes, didn't see it. But the problem remains that headers files nsIPlugin*.h are in path /usr/include/xulrunner-1.9/unstable/ instead of /usr/include/xulrunner-1.9/stable/ in case of xulrunner*-dev
[20:52] <cjwatson> e.g. (cd ubuntu && germinate-update-metapackage --bzr); (cd kubuntu && germinate-update-metapackage --bzr) and then use ubuntu/desktop-* and kubuntu/desktop-* as sources for substvars
[20:52] <cjwatson> kirkland: yes, you may, although the source package will go into main
[20:55] <Lrrr> cjwatson: Oh I think I see what you mean thank you.
[20:56] <ScottK> kirkland: I just did that for sendmail so I could get libmilter-dev into Main.
[20:58] <asac> slytherin: well. you need to use libxul-unstable.pc to get unstable headers.  doesnt debian use that?
[20:59] <slytherin> asac: AFAIK, classpath is still using libxul-dev as build depends. It hasn't been ported to build with xulrunner*-dev
[21:00] <Lrrr> cjwatson: no, not really, I need to run it from the root of the package source tree so I can't have seperate directories
[21:01] <cjwatson> Lrrr: why do you need to run it from the root?
[21:01] <cjwatson> oh, debian/control check
[21:01] <cjwatson> how about I add an --output-directory option
[21:02] <asac> slytherin: not sure what classpath does. maybe the port would just use libxul-unstable.pc
[21:03] <Lrrr> cjwatson: well, yeah, that would suit me, but do you want me to add it since it's not immediately useful to you?
[21:04] <cjwatson> well, I'd already started, but you can if you like ...
[21:04] <cjwatson> (go for it)
[21:05] <cjwatson> calc: the installer should now let you enter raw byte values by suffixing 'B'
[21:06] <slytherin> asac: classpath looks for pkg-config in following order, mozilla-plugin, firefox-plugin, xulrunner-plugin, mozilla-firefox-plugin, seamonkey-plugin, iceape-plugin. So the first one it finds is I guess mozilla-plugin which doesn't include path for unstable directory.
[21:06] <Amaranth> can any of you confirm bug 247088
[21:06] <cjwatson> so '2147483648B' == 2G(i)B
[21:06] <cjwatson> should at least help work around problems even though it's not all the way there yet
[21:07] <asac> slytherin: mozilla-plugin is just basic plugin api. nsIPlugin should be xpcom are there tests for mozilla-xpcom?
[21:07] <Lrrr> good python practice for meee
[21:09] <slytherin> asac: No, there are -xpcom tests for everything else except mozilla
[21:09] <_MMA_> Amaranth: I can't here.
[21:09] <kirkland> cjwatson: good, thanks.  i've tried to indicate such in https://wiki.ubuntu.com/MainInclusionReportTrousers
[21:10] <asac> slytherin: huh? whatelse would require xpcom if not mozilla?
[21:10] <asac> or do you mean firefox-xpcom etc.?
[21:11] <slytherin> asac: yes, the tests are like firefox-plugin, firefox-xpcom, then next xulrunner-plugin, xulrunner-xpcom etc.
[21:13] <_MMA_> Amaranth: I can't reproduce any way I try. I'm always asked for my password.
[21:13] <slytherin> asac: leave it now. It is midnight for me. I will try to debug tomorrow.
[21:13] <Amaranth> _MMA_: same here
[21:13] <Amaranth> dunno what is going on there
[21:14] <_MMA_> Amaranth: I actually *tried* to do this about 6 months ago. No luck then either.
[21:16] <_MMA_> Amaranth: Tried to bypass a locked screen with various Compiz effects that is.
[21:17] <cjwatson> kirkland: should be fine
[21:17] <kirkland> cjwatson: thanks.
[21:17] <cjwatson> kirkland: (remove question marks when you've answered questions, e.g. "vigorous ?" -> "vigorous")
[21:17] <kirkland> cjwatson: okay
[21:18] <kirkland> cjwatson: fwiw, i think the particular build dependency in question is not necessary.  i've email the debian maintainer about softening it.
[21:18] <kirkland> cjwatson: so that particular MIR may be null and void
[21:18] <cjwatson> I didn't look at the report all that hard :)
[21:19] <Amaranth> _MMA_: did you bind a plain mouse button to expo?
[21:20] <Amaranth> _MMA_: so just hitting button 3 will activate it
[21:20] <kirkland> cjwatson: ;-)  btw, did you catch my ping earlier about an openssh-server init script patch?
[21:21] <cjwatson> kirkland: uploaded a few minutes ago ...
[21:21] <_MMA_> Amaranth: Oh. I see. I mis-read that. I tried with keybindings and screenedges.
[21:21] <kirkland> cjwatson: ah, nice.
[21:21] <Amaranth> _MMA_: I remember trying this when we had a hack in compiz to prevent such things but now that we rely on the X server it may have broken
[21:21] <kirkland> cjwatson: shall I open a Debian bug after the  updated library function makes it into Debian?
[21:22] <Amaranth> and I'm on OS X right now so...
[21:25] <_MMA_> Amaranth: Ok. Tried with button3 on 2 boxes. 1 Intel, the other nVidia. No dice. Asks for password.
[21:25] <cjwatson> kirkland: no need, I sync from time to time anyway
[21:25] <kirkland> cjwatson: cool, thanks.
[21:26] <Amaranth> _MMA_: did you make the password dialog pop up then try to activate expo or try to activate expo and it popped up the password dialog instead?
[21:26] <_MMA_> Both
[21:27] <Amaranth> _MMA_: alright, thanks
[21:27] <kirkland> slangasek: I think that only leaves the init script patch for samba awaiting sponsorship/upload (bug #247087)  ;-)
[21:34] <slangasek> kirkland: after the alpha, yes. :)
[21:34] <kirkland> slangasek: ah, gotcha ;-)
[21:40] <Lrrr> cjwatson: I've pushed the change to my personnal Germinate branch.  There is 2 or 3 changesets you might want to see there too but nothing that important.
[22:03] <kirkland> is it possible within launchpad to set a bug as a blocker for another bug?
[22:03] <pitti> kirkland: no, it isn't
[22:04] <kirkland> hrm
[22:27] <cjwatson> Lrrr: where's that?
[22:49] <jcole> can someone enlighten me of why we dont also rebuild mini.iso everytime a new kernel is released -> /ubuntu/dists/hardy/main/installer-i386/current/images/netboot/mini.iso
[22:49] <jcole> s/we/ubuntu
[22:49] <jcole> lol
[22:50] <jcole> it cannot find the modules for d-i since the kernel is newer
[22:50] <cjwatson> jcole: /ubuntu/dists/hardy-updates/ - enjoy
[22:51] <cjwatson> note that the kernel is in hardy-updates too
[22:51] <cjwatson> so match them up
[22:51] <jcole> cjwatson: i would kiss you, but im both straight and too far from you
[22:52] <cjwatson> perhaps that is just as well ;-)
[22:53] <rgb> Hello.
[22:53] <rgb> A question.  Is it already known that the last update seriously screwed up audio?
[22:55] <slangasek> rgb: that's a little vague, but there haven't been any major reports of audio regressions that I'm aware of, no
[22:56] <greg-g> rgb: to report a new sound bug, see this page: https://wiki.ubuntu.com/DebuggingSoundProblems
[22:56] <greg-g> the section titled "Reporting Sound Bugs" is what you want to follow
[22:57] <rgb> No, I'd rather just know if anyone else has stopped by who also have music and video playback stop after x ammount of seconds.
[22:57] <rgb> Ranging from 10 to about 25 seconds.
[22:58] <slangasek> rgb: no, and since you're the only one so far experiencing it, reporting a bug is the only reliable way to see that it gets fixed; so far, you haven't even said which update this happened with
[22:58] <rgb> The latest.
[22:59] <slangasek> sorry, that means nothing; the latest what?  the latest release, the latest point release, the latest package added to -updates, the latest kernel in intrepid?
[23:00] <slangasek> you'll have to give us a reference point that lets us understand what "latest" means to you
[23:00] <rgb> The latest updates of all the packets, how am I supposed to know what that update is called?  They're all rolling.
[23:00] <rgb> Today, last 24 hours, huge ammount of new packets.
[23:01] <greg-g> rgb: honestly, the best thing to do is to report a bug following the instructions on the page I linked.
[23:01] <rgb> I will, it's just that I'm severely pissed since even after completely reinstalling Hardy and then running the updates, it's still fucked.
[23:02] <slangasek> ok, so you're running hardy; that's a starting point
[23:03] <greg-g> Sorry for your issues, and that sounds like a bug that should be reported.  however, I am not experiencing the same issue so I can not report it for you.
[23:03] <slangasek> do you have hardy-proposed enabled in your software sources, or only hardy-updates? ("Pre-released updates" vs. "Recommended updates")
[23:04] <Chipzz> rgb: not that you're doing so currently, but slight hint: if you want to take out your anger on someone, #ubuntu-devel is not the place to do it
[23:04] <rgb> I know, don't worry, I already vented most of my anger.
[23:05] <Chipzz> rgb: there have been people who did such things before; as such ;)
[23:06] <rgb> Lessee, before reinstall I had selected Multiverse and Universe next to the default iirc.
[23:06] <rgb> Lemme check the standard setting for repositories.
[23:06] <rgb> Main, Universe, Restricted and Multiverse are selected by default.
[23:06] <rgb> Which I used since this reinstall.
[23:06] <Chipzz> rgb: that shouldn't matter (I think)
[23:06] <rgb> Chipzz, I can understand.
[23:07] <Chipzz> though you're right that universe and multiverse are not officially supported
[23:07] <rgb> Hardy-proposed and hardy-backports are not selected under the updates slangasek.
[23:07] <rgb> So Security and Updates only.
[23:08] <stgraber> rgb: if you run "aplay /usr/share/sounds/login.wav" from a terminal, do you get any sound ?
[23:09] <slangasek> ok; there have been some packages moved from hardy-proposed to hardy-updates in the last couple of days, but I don't remember that any of these were sound-related
[23:09] <slangasek> the only one that I guess might be would be the kernel itself
[23:09] <stgraber> (just trying to find the package that could have caused the regression)
[23:09] <slangasek> hmm, no, that's not recently-moved
[23:09] <stgraber> slangasek: -19 was a long time ago IIRC
[23:09] <slangasek> right
[23:09] <stgraber> any pulse update recently pushed to -updates ?
[23:09] <slangasek> no, there have been no pulse updates at all
[23:09] <slangasek> nor alsa updates
[23:10] <rgb> slangasek: I thought it was the kernal also, so did a bunch of degrades to the oldest version.  No success.
[23:10] <stgraber> bah, would have been too easy :)
[23:10] <rgb> stgraber: Probably, will test now.
[23:11] <slangasek> rgb: really, filing a bug should be your next step; given that there are no obviously-guilty packages that have been updated in the past couple of days, you'll need the help of someone who knows the sound packages closely, and not just people like me trying to guess based on what they see in the archive
[23:11] <crimsun> instead of beating around the bush, run the alsa-info.sh script referenced at wiki/DebuggingSoundProblems.
[23:11] <rgb> Atm I cannot play it, but I have a video running in the background for testing purposes.  It keeps dying every random 10 to 30 seconds and continues another (greater) random ammount of seconds later.
[23:12] <_MMA_> There was a restricted modules update yesterday. Are the nVidia drivers only for GFX or do they apply to nForce boards as well?
[23:13] <rgb> I don't have an nForce board.
[23:13] <_MMA_> k
[23:13] <crimsun> _MMA_: graphics.
[23:13] <rgb> So that doesn't apply to me.
[23:13] <stgraber> _MMA_: AFAIK the nvidia chipset has its drivers in the kernel
[23:13] <_MMA_> nm me then. :P
[23:13] <norsetto> rgb: is that a laptop or you have external speakers?
[23:14] <rgb> It's a desktop.
[23:14] <crimsun> (nforce audio is provided by i810_audio, snd-intel8x0, or nvsound - plus the associated ac'97 codec driver, respectively.  Only when dealing with nvsound is it irrelevant.)
[23:14] <rgb> Connected to my stereo.
[23:14] <norsetto> rgb: check your cable then
[23:14] <rgb> norsetto: I can get sound.
[23:14] <rgb> I hear sound.
[23:15] <rgb> The problem is the sudden and random stopping.
[23:15] <rgb> And after a while continuing.
[23:15] <crimsun> also, why is this discussion occurring here?
[23:15] <norsetto> rgb: you said comes and go, that typically a cable problem
[23:15] <rgb> norsetto: You would think so.  But when also the video stops I doubt it's a cable problem.
[23:16] <rgb> And I have done nothing about my cabling in months.
[23:16] <norsetto> rgb: then its not just a sound problem, which is what you have reported so far
[23:16] <rgb> And seeing as everything worked fine 2 days ago.
[23:16] <rgb> Possibly.
[23:16] <rgb> But it also happens in audacious where there's no video.
[23:17] <rgb> Hence my main hunch was that the sound was destroying everything.
[23:17] <crimsun> nice one, but no.
[23:17] <crimsun> and if you continue to rant without actually providing useful debugging info, it's pretty futile.
[23:18] <rgb> Sorry that I'm not able to do everything at once n_n
[23:18] <crimsun> again, multiple have pointed you to the wiki/DebuggingSoundProblems page.  I specifically mentioned the alsa-info.sh bash script that you need to download invoke via bash in a terminal.
[23:18] <alex_mayorga> hello all devs, can somebady take a quick look at my last comment on bug #121111 please?
[23:18] <rgb> http://pastebin.ca/1068602  <<< Utils script uploaded that.
[23:18] <alex_mayorga> I hadn't renamed the bug, but seem to be recurring on Intrepid alphas, thanks in advance
[23:19] <rgb> crimsun: I had read it, I was already reading the Wiki but did not wish to keep people here waiting too long.  Hence the delay in numerous things.
[23:19] <crimsun> rgb: I'm happy to help you in #ubuntu.  This channel isn't appropriate.
[23:20] <rgb> I was there, too loud and didn't get through.  Will go there again.
[23:20] <slangasek> alex_mayorga: I recommend that you open a new bug; even with the same symptoms and the same workaround, it may not be the same issue anymore, and it's easier for developers to merge two reports that are the same than to winnow out information from two unrelated bugs being reported in the same bug number
[23:21] <alex_mayorga> slangasek, thanks will do
[23:45] <Lrrr> cjwatson: lp:~fdgonthier/germinate/fdg