[00:09] <Knives> I'm looking for a Jpdota
[00:10] <Jpdota> Knives: found
[00:52] <kees> andersk: sure, I'll apply it.
[02:12] <fakhriz> hi folks
[02:13] <fakhriz> I have trouble installing my webcam ubuntu 8.1
[02:13] <fakhriz> anybody there
[02:14] <nhandler> fakhriz: This channel is not for support. Try #ubuntu
[02:14] <fakhriz> thx
[05:46] <dholbach> good morning
[06:11] <amason_> hey guys is UXA & DRI2 working in jaunty with -intel ? i know there are known issues with alpha4 and EXA. I was hoping to test out some newer packages and can deal with most things not working
[06:12] <amason_> but obviously the display portion is important
[06:12] <pwnguin> amason_: if you don't get an answer here, ubuntu-x might have your answer
[06:13] <amason_> pwnguin: thanks i'll head over and ask there.
[07:22] <pitti> Good morning
[07:22] <pitti> ScottK: I copied 4.1.4 to i-updates yesterday
[07:22] <pitti> apw: cool, thanks! will review
[07:23] <pitti> maxb: hm, you shouldn't really get a prompt, the file should just go; please file a bug against locales and subscribe me
[08:09] <primes2h> Could someone have a look on this and tell if the package affected is correct? BTW, this bug has an high impact on many many users especially newbies. bug #255651
[08:10] <primes2h> I forgot.. please? :-)
[08:14] <jeromeg> pitti: you seem to have taken care  of a few abiword uploads in the past. I'm working on packaging 2.6.6. Are you interested in reviewing it once I'm done ?
[08:15] <pitti> jeromeg: I can look at it, but please just subscribe ubuntu-main-sponsors, so that it's not blocking on just me
[08:17] <jeromeg> pitti: ok, I'll do that
[08:26] <primes2h> bryce: Could you have a look on this, please? bug #291436
[08:27] <tkamppeter> pitti, hi
[08:27] <pitti> hi tkamppeter
[08:27] <pitti> tkamppeter: please try to test-build cups before committing a patch :)
[08:29] <tkamppeter> pitti, about your upload of CUPS, the pdftopdf filter has to get built in Ghostscript mode. Poppler's pdftopdf has a general bug of not supporting different paper sizes in the output. Can you repackage CUPS with the pdftops filter being Ghostscript-based? Thanks.
[08:33] <tkamppeter> pitti, diod the CUPS not build for you in the form how I uploaded it? For me it built.
[08:34] <tjaalton> primes2h: nothing we can do
[08:34] <primes2h> tjaalton: about the ATI one?
[08:35] <tjaalton> primes2h: yes
[08:36] <pitti> tkamppeter: the test suite failed
[08:36] <pitti> tkamppeter: because it didn't find gs
[08:36] <pitti> tkamppeter: so if we should stop using pdftops from poppler-utils, and start using ghostscript, we need to change the patch again and swap the build-depends and depends instead
[08:42] <pitti> tkamppeter: I just wonder whether switching to gs will give us a different set of bugs?
[08:42] <tkamppeter> pitti, I see. Can you do so? Return to my original patch and add "ghostscript" to BuildDepends and Depends.
[08:44] <pitti> tkamppeter: I can, just wanted to confirm that that's the right thing
[08:44] <pitti> tkamppeter: it's not possible to fix poppler?
[08:44] <tkamppeter> pitti, OK, thanks.
[08:44] <tkamppeter> pitti, I had reported a bug to them, but they do not fix it.
[08:45] <pitti> tkamppeter: okay; can you please open a bug and assign it to me?
[08:54] <tkamppeter> pitti, this is the link to the Poppler bug report: https://bugs.freedesktop.org/show_bug.cgi?id=19777
[08:59] <primes2h> tjaalton: Thanks.
[09:02] <tkamppeter> pitti, bug 329991
[09:02] <pitti> tkamppeter: thanks
[09:06] <tkamppeter> pitti, have you already seen http://bugs.freedesktop.org/show_bug.cgi?id=19968
[09:07] <pitti> maxb: ah, found the problem; will fix
[09:07] <pitti> tkamppeter: I saw the reply, yes; but I can't test it here either
[09:07] <tkamppeter> They have closed it because they cannot reproduce it with their projector, probably theirs reports the default.
[09:08] <tkamppeter> They also they use Intrepid and not Jaunty.
[09:09] <pitti> seb128: btw, the retracer failures are my fault (conffile question in locales); fixing locales...
[09:09] <lool> pitti, tkamppeter: I had this exact same bug, I discussed it at length with seb128 and bryce
[09:09] <seb128> pitti: ok
[09:10] <lool> xrandr (the command-line binary) has a special --preferred flag which makes it *compute* the preferred mode when one isn't advertized; there's no comparable logic in the XRandr API or in GNOME (either libgnome-desktop or g-s-d)
[09:10] <lool> Which is what seemed to be missing
[09:10] <directhex> compute it based on what?
[09:11] <tkamppeter> pitti, lool, bryce, I think, this is a bug in xrandr, as if one starts the X server with the projector plugged, it works correctly. So the X server contains the correct logic. One only needs to use the same logic in xrandr.
[09:11] <lool> directhex: It selects the largest mode you support
[09:11] <lool> directhex: see preferred_mode() in xrandr/xrandr.c
[09:12] <lool> (in the x11-xserver-utils package)
[09:13] <lool> tkamppeter: If you "xrandr --auto" in a Xorg session it works fine, right?
[09:13] <tkamppeter> Perhaps projectors which behave as the one on the Sprint are rare and so it is difficult to convince someone to fix this.
[09:14] <tkamppeter> lool, no, if I do so, I get exactly the problem described in the bug. If I start X with the projector plugged I get the correct result.
[09:14] <lool> My understanding is that in GNOME sessions, all xrandr updates / hotkeys etc. are handled in GSD; I don't quite know whether it's a Xorg bug too
[09:16] <maxb> pitti: thanks! I'll wait for a new glibc to hit the archive before upgrading my remaining jaunty machines, to test
[09:17]  * directhex installs a jaunty VM
[09:21] <jeromeg> pitti: ok, I think I'm for abiword, I attached everything and suscribed ubuntu-main-sponsors
[09:21] <jeromeg> bug #318444
[09:21] <mvo> lool: when I looked into the xrandr util last it had a lot of logic in it that really should be in some sort of library
[09:21] <jeromeg> I hope there aren't many issues because each test build takes 40 minutes here :(
[09:22] <lool> mvo: Yes
[09:22] <lool> mvo: That's exactly what we saw in my case
[09:22] <directhex> jeromeg, try your hand at OOo packaging, then moan about 40 minute build times ;)
[09:24] <jeromeg> directhex: I tried to build ooo one time, and killed the pbuilder after 2 hours :)
[09:25] <directhex> jeromeg, barely 25% in? tsk
[09:29] <tkamppeter> mvo, and the logic which does it correctly with the projector of the sprint is in the X server and not in xrandr ...
[09:42] <pitti> maxb: I uploaded the fix half an hour ago; it's not in glibc, but in "locales" (langpack-locales source), which is fairly small
[09:42] <pitti> maxb: thanks
[09:43] <maxb> "Add alternative dependency to libc6.1, to unbreak ia64." ?
[09:44] <pitti> maxb: no, the next one, in -3
[09:44] <cjwatson> doko: python2.6 binaries accepted now
[09:44] <maxb> Oh. mail being slow, then
[09:46] <geser> so we have now four python versions in the archive?
[09:47] <mok0> geser: 2.3 is still supported?
[09:47] <cjwatson> geser: https://blueprints.launchpad.net/ubuntu/+spec/python-for-jaunty includes dropping 2.4 modules
[09:47] <doko> cjwatson: thanks
[09:47] <geser> mok0: 2.4, 2.5, 2.6 and 3.0
[09:48] <geser> doko: Hi, what are the chances to see python-central 0.6.8 in jaunty? Some packages from universe are in DEPWAIT as they want python-central >= 0.6.8 and jaunty has only 0.6.7ubuntu1.
[09:48] <mok0> cjwatson: any idea how many modules are not supported under 2.5?
[09:48] <mok0> geser: oh cool
[09:49] <cjwatson> mok0: I thought everything was supported
[09:50] <mok0> cjwatson: I'm not sure
[09:50] <mok0> cjwatson: perhaps
[09:50] <mok0> cjwatson: that's why I asked :-)
[09:50] <cjwatson> mok0: I would be surprised if not; about the only thing that has trouble is zope2.x/plone
[09:50] <cjwatson> mok0: everything else is fine AFAIK
[09:50] <mok0> cjwatson: sounds great then
[09:51] <cjwatson> doko: what's up with the i386 build failure on -0ubuntu3 though? is it due to a parallel build?
[09:51] <mok0> cjwatson: Usually Python version upgrades have meant that extension modules had to be corrected
[09:52] <mok0> cjwatson: especially those relying on swig
[09:53] <doko> geser: no, will upload a new version
[09:54] <doko> cjwatson: no, profile based build. will disable this for now. it's a GCC bug
[09:55] <geser> doko: you mean something like python-central 0.6.8ubuntu1 (or even greater)?
[10:05] <cjwatson> mok0: maybe, but we did 2.5 ages ago
[10:05] <mok0> cjwatson: k, thx
[10:20] <lool> doko: Looks like /etc/ld.so.conf.d/<triplet> should be rm_conffiled in glibc
[10:20] <lool> doko: I have /etc/ld.so.conf.d/i486-linux-gnu.conf and /etc/ld.so.conf.d/i486-linux-gnu here
[10:22] <lool> I filed this sa #330029
[10:38] <doko> lool: yes, but it currently doesn't hurt, because only *.conf files are read
[10:41] <lool> doko: Ok
[10:41] <lool> doko: Hmm I don't see how the nosegneg dir is included in hardy; if I ldconfig -p with libc6-xen installed on a hardy xen domU, it doesn't show any nosegneg dirs, only the cmov one
[10:41] <lool> doko: I suspect we miss the xen.conf file
[10:44] <lool> doko: If I create a /etc/ld.so.conf.d/xen.conf with "hwcap 1 nosegneg" and run ldconfig, I see the nosegneg files in the cache now
[10:44] <lool> (in ldconfig -p)
[10:44] <lool> That said, it still prefers the i686 version, which is probably another bug
[10:46] <lool> Hmm TLS is disabled in all cases, so not a big deal
[10:47] <lool> ubuntu-minimal depends on libc6-i686 though, blah
[10:47] <lool> I don't quite see the point of the libc6-xen in Ubuntu since -i686 is built with the same flags
[10:48] <apw> pitti, thanks for looking at my apport  (when you get to it)
[10:48] <apw> pitti, just to say i finally figured out how to test it propoerly with all three interfaces, and did actually test them all
[10:50] <lool> wow three reasons why libc6-xen is uselesss :-/
[10:53] <lool> doko: I filed 330039 on libc6-xen being useless, it might be the result of Ubuntu specific changes
[10:59] <lool> doko: Right, it's Ubuntu-specific; Debian doesn't set nosegneg by default
[11:00] <lool> doko: Perhaps we should drop the xen pass as a result
[11:01] <elmo> why do we nosegneg?
[11:03] <doko> I would have to look, I think I inherited this code
[11:04] <lool> elmo: This seems to be a very old change in Ubuntu
[11:04] <lool>     * i386.mk:
[11:04] <lool>       * readd no-tls-direct-seg-refs to generic libc cflags.
[11:04] <lool> glibc (2.5-0ubuntu1) feisty;  -- Fabio M. Di Nitto <fabbione@ubuntu.com>  Wed, 01 Nov 2006 12:49:55 +0100
[11:05] <elmo> I mean, I'm not complaining, it's a win for Xen ;-)  I just didn't think it was a win in the normal case
[11:06] <lool> I can tel it results in slower i386 assembly, but I don't know by how much
[11:07]  * lool returns to arm
[11:09] <ogra> hmm, new d-i inst built yet ...
[11:09] <cjwatson> it'll need another rebuild today for cdebconf-terminal anyway
[11:09] <cjwatson> ... once I get that built
[11:10] <lool> ogra: It the new NSLU2 kernel in?
[11:10] <ogra> lool, just checking
[11:10] <lool> I didn't see the change from jaunty-changes, but I might have missed it
[11:11] <ogra> yep. looks like we have an 8.22
[11:15] <lool> ogra: In the latest git tip, I see CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y
[11:17] <ogra> yes, somehow the changelog parser missed it
[11:17] <lool> ogra: So it's supposed to be the correct flag?
[11:17] <ogra> i knew it was in there already, was just waiting that it builds
[11:17] <ogra> amit picked it from the debian config he said
[11:17] <ogra> so i assume it is
[11:17] <ogra> we'll know if d-i is there ...
[11:18] <ogra> ... i would have poked around with my script, but since d-i was uploaded anyway i'll just wait for the real thing to appear
[11:18] <ogra> theoretically it should bot now
[11:18] <ogra> *boot
[11:24] <Keybuk> cjwatson: you'll sympathise with this
[11:24] <Keybuk> I've been trying to listen to the Ubuntu UK Podcast
[11:24] <Keybuk> and having the "someone is being wrong on the Internet" issue
[11:25] <ogra> that cant be ... if its n the internet it has to be true ...
[11:26] <directhex> the internet wouldn't... lie to me!
[11:26]  * soren imagines a world that adapts itself in order to make whatever was on the Internet true
[11:26] <ogra> no, its like your TV ... one of the few things that tell the absolute truth in the world :)
[11:26]  * soren fails
[11:26] <pitti> Keybuk: http://xkcd.com/386/ ?
[11:27] <Keybuk> pitti: exactly
[11:30] <ogra> lool, hrm, seems d-i failed badly on all arches anyway
[11:30]  * ogra didnt look before ..
[11:32]  * Keybuk is having the most random issue with jaunty today
[11:32] <Keybuk> it sometimes resolves IPv6 addresses for things
[11:32] <Keybuk> and then declares "Network unreachable"
[11:32] <Keybuk> especially gb.archive.ubuntu.com
[11:34] <Daviey> WAT
[11:34] <Daviey> Keybuk: i wouldn't bother listening to that podcast, full of jerks :)
[12:04] <pitti> tkamppeter: however, it seems that some filters in debian/local/pdf-filters/ still use poppler; that would mean that we'd get a mix of poppler and ghostscript?
[12:34] <asac> doko: have a clue about http://paste.ubuntu.com/118812/ (from http://launchpadlibrarian.net/22674731/buildlog_ubuntu-jaunty-sparc.ppp_2.4.5~git20081126t100229-0ubuntu1_FAILEDTOBUILD.txt.gz)
[12:35] <asac> doko: ?
[12:35] <asac> seems that BIG_ENDIAN and LITTLE_ENDIAN is defined there ;)
[12:36] <asac> doko: the error say: # error Fix asm/byteorder.h to define arch endianness ... so maybe there is something missing on sparc ?
[12:36] <asac> or are you the wrong to ask ;)?
[12:37] <doko> asac: I didn't touch ppp ... maybe fix the configure test?
[12:37] <asac> doko: well. i dont ask because of pp, just wonder if the sparc header might be wrong
[12:38] <asac> doko: what is the configure test supposed to do?
[12:38] <asac> doko: on i386 asm/byteorder.h includes "little_endian.h"
[12:39] <doko> asac: well, have a look at the linux-libc-dev package
[12:39] <asac> doko: do you have a sparc jaunty thing somewher?
[12:39] <ogra> .oO( all the poor sparc dialup users .... )
[12:39] <asac> hehe
[12:39] <asac> ogra: more so about the sparc ppp server providers ;)
[12:39] <ogra> heh, yeah
[12:40] <asac> i hoped i would get feedback on server capabilities from them. but now ...
[12:40] <doko> asac: my sparc machine is currently down, so maybe have a look at faure?
[12:40] <asac> doko: let me check that
[12:42] <asac> doko: hmm ... seems i have no access to that system
[12:43] <asac> oh. so kernel is in manualdepwait for sparc
[12:48] <cody-somerville> Sounds no longer works in Xubuntu. :(
[12:48] <Tm_T> cody-somerville: is it lighter that way?
[12:48] <cody-somerville> no
[12:48] <cody-somerville> Bulkier
[12:48] <cody-somerville> ala PulseAudio
[12:49] <Tm_T> cody-somerville: interesting, I had always the sense of lightness when I played good old "indy500" without sound
[12:49] <cody-somerville> I predict a day of the utmost suffering without my beautiful music : (
[12:50] <Tm_T> cody-somerville: for that reason I always have backup, lp player
[12:50] <Tm_T> cody-somerville: as I spend too much time fiddling with upstream
[12:52] <davmor2> cody-somerville: here borrow mine :)
[12:52]  * davmor2 passes cody-somerville his music to listen to
[12:53] <cody-somerville> I think I hear something... oh wait, no... just the snowplow outside :(
[12:53]  * hyperair wonders what's the state of the intel drivers on jaunty
[12:56] <Keybuk> I wish grub had copy & paste between reboots
[12:56] <ogra> implement it :)
[12:57] <Keybuk> I have too much real work to do
[12:59] <asac> doko: seems asm/byteorder.h includes linux/byteorder.h while it should inlcude linux/byteorder/big_endian.h
[13:00] <asac> doko: so i guess -kernel?
[13:01] <asac> (and drop the #define __BIG_ENDIAN i guess from asm)
[13:09] <tkamppeter> pitti, the mix of Ghostscript and Poppler in the CUPS filters should not be a problem. Conversions from PDF to PS and vice versa are done with GS now, Poppler is only used for pdftopdf, as Poppler has a better API for page management. Poppler does not render the PDF files here, it only takes them apart and puts them together in another order.
[13:09] <pitti> tkamppeter: okay
[13:10] <tkamppeter> pitti, also formerly CUPS uses both Poppler and GS, Poppler for pdftops and Ghostscript for the printer drivers.
[13:13] <jeromeg> anyone available to review abiword 2.6.6 ?
[13:19] <primes2h> Keybuk: Could you have a look on bug #255651 please?
[13:20] <Keybuk> someone filed that one again?
[13:20] <primes2h> In Hardy all worked out of the box, no floppy modules in /etc/modules
[13:20] <primes2h> It has 18 duplicates-
[13:21] <ogra> cjwatson, can we make sure the ixp4xx microcode udeb ends up in the ixp4xx netboot d-i image ?
[13:21] <cjwatson> ogra: sure, what's it called?
[13:22] <ogra> hmm, no idea, i dont see an explicit package on http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-firmware/
[13:22] <ogra> http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-firmware/nic-firmware_1.6_all.udeb ?
[13:22] <ogra> i guess rtg just includes it in the std. binary
[13:23] <ogra> i'll ask
[13:23] <primes2h> Keybuk: I don't know what changed between Hardy and Intrepid so I don't know where to adress it.
[13:23] <Keybuk> primes2h: it's a kernel bug
[13:24] <primes2h> Keybuk: even if module it's not present in /etc/modules in Hardy but floppy works out of the box?
[13:25] <Keybuk> primes2h: a temporary workaround
[13:25] <Keybuk> echo alias acpi*:PNP0700:* floppy > /etc/modprobe.d/makemyfloppywork
[13:25] <_MMA_> Hi all. Anyone from the release team around? The Ubuntu Studio dailies haven't been built since the 2nd. I need to get that remedied.
[13:26] <primes2h> Keybuk: A wordaround is adding floppy in /etc/modules
[13:27] <soren> Keybuk: That doesn't work for me. I had a file called acpi-oh-dear-this-is-not-going-to-work:PNP0700:what-do-I-do in my $PWD, when I did it. Does that matter?
[13:27] <Keybuk> soren: in your PWD ?
[13:27]  * soren should sleep more at night, /me thinks
[13:27] <Keybuk> what did that file contain?
[13:27] <cjwatson> ogra: done
[13:28] <soren> "im in ur $pwd eeting ur modulz"
[13:28] <cjwatson> Keybuk: I think soren is trolling your lack of shell quoting
[13:28] <primes2h> Keybuk: It works but I would like to know what is in charge to let floppy works in Hardy, because no module is present in /etc/modules... Is it built directly in the kernel itself?
[13:29] <Keybuk> primes2h: hardy has a variant of that line in a file in /etc/modprobe.d
[13:29] <Keybuk> in fact, intrepid and jaunty have the same file
[13:29] <lool> soren: haha
[13:29] <Keybuk> it's just that the file doesn't work anymore, because it's wrong ;)
[13:30] <primes2h> Keybuk: How can it be fixed so?
[13:30] <Keybuk> primes2h: it's a one line patch to the kernel
[13:30] <ogra> cjwatson, thanks
[13:30] <cjwatson> _MMA_: one moment
[13:31] <cjwatson> _MMA_: the cron job was apparently commented out; I'm not sure why but can't find a justification for it. I've reenabled it.
[13:31] <Keybuk> primes2h: it's somewhere in my TODO list
[13:31] <Keybuk> assuming the kernel team don't get to it first
[13:32] <primes2h> Keybuk: Unfortunately it's a blocking bug for many many users, newbies firstly...
[13:32] <Keybuk> but there's 10 of them, and 1 of me, so I outnumber them 1-to-10
[13:32] <Keybuk> primes2h: the things above it in my TODO list concern more useful hardware than floppy drives :)
[13:33] <primes2h> Keybuk: ok, but it's just one line... ;-)
[13:33] <Keybuk> yes, but then I have to test it
[13:33] <Keybuk> and I have to use git
[13:33] <Keybuk> which means I have to stab someone afterwards
[13:34] <Keybuk> and then I have to have the "why not work around it in userspace?" argument
[13:34] <Keybuk> at which point, I should probably just commit it upstream
[13:34] <Keybuk> which means it'll turn up in jaunty+1
[13:34] <Keybuk> in summary: one line patches take more effort than entire new features :p
[13:36] <jeromeg> anyone here has a few spare time to review bug #318444 ?
[13:36] <primes2h> Keybuk: I don't want to put pressure on you but unfortunately this kind of bug put away a lot of new users in Ubuntu.. :-)
[13:36] <jeromeg> I won't have much time in the following days, and feature freeze is soon
[13:37] <primes2h> Keybuk: users that are not even able to report a bug...
[13:38] <Keybuk> primes2h: those users will be even more upset if Ubuntu fails to mount their root filesystem
[13:38] <Keybuk> which is amongst the bugs higher up on my list ;)
[13:40] <_MMA_> cjwatson: Oh odd. Thanx for the fix.
[13:40] <primes2h> Keybuk: if I find someone providing a patch for this could you review it? (when you have time, of course) :-)
[13:41] <Keybuk> primes2h: of course
[13:42] <primes2h> Keybuk: Thank you.
[13:42] <azeem> w31
[13:43] <azeem> oops, sorry
[13:46] <PecisDarbs> pitti: hi there, I have that patch for sl-modem-daemon init script, can I send it to you, will you take look at it?
[13:50] <ogra> cjwatson, hmm, i suspect there is more to change for the nslug ... in debian it starts an ssh server after booting
[13:50] <ogra> oh, it does so for me too now, but first asks the kbd questions ...
[13:51]  * ogra guesses that needs special preseeding
[13:53] <cjwatson> ogra: as documented ...
[13:54] <primes2h> Keybuk: just one last thing. Do you mean the patch has to be addressed at the kernel package? Or what else package alternatively?
[13:54] <directhex> slugbuntu?
[13:54]  * ogra wonders what kbd to set ... i guess just gb or us is fine ... nobody will use that anyway
[13:54] <ogra> directhex, yeah :)
[13:54] <ogra> a hommage to the sydney linux user group ;)
[13:56] <cody-somerville> hmm... abiword appears to be in main. I thought it was in universe.
[13:56] <primes2h> Keybuk: I mean, is the bug in the kernel package itself?
[13:57] <Keybuk> primes2h: it's a bug in the kernel source itself
[13:57] <cody-somerville> Can someone do me a big fat favour and review/upload an update prepared by one of the Xubuntu contributors jeromeg for Abiword? https://launchpad.net/bugs/318444
[13:59]  * ogra grins about the nslug loading the PS/2 driver
[14:07] <pitti> PecisDarbs: great! Please attach it to the bug report
[14:20] <ogra> hrm, i dont get where d-i pulls the preseed file from during build
[14:22] <PecisDarbs> pitti: patch attached to bug report with explanation what it does
[14:28] <pitti> PecisDarbs: thanks
[14:39] <cjwatson> ogra: build/config/arm/iop32x/netboot.cfg:29: cp boot/arm/glantank.preseed $(SOME_DEST)/$(EXTRANAME)/glantank/preseed.cfg
[14:39] <cjwatson> that kind of thing presumably
[14:39] <ogra> cjwatson, yeah, seems the default file is assembled in the oldsys-preseed usdb
[14:40] <cjwatson> that's a bit different
[14:40] <ogra> i got a preseed.cfg in the booted d-i but dont see it in the d-i buildlog
[14:40] <ogra> there is no such thing like the iop32x code for ixp4xx
[14:40] <cjwatson> oldsys-preseed is for *dynamic* preseeding based on stuff extracted from the device
[14:40] <ogra> so i assume it comes with a package
[14:40] <cjwatson> ogra: it's not generic, you would have to write it
[14:41] <cjwatson> there is normally no default preseed file
[14:41] <ogra> ah
[14:41] <cjwatson> unless you've modified your local tree with a preseed.cfg
[14:41] <ogra> i was assuming there was one since ixp4xx has so much special setup
[14:41] <ogra> no, i didnt touch my tree
[14:42] <cjwatson> there's no preseed.cfg in the ixp4xx images in the archive
[14:42] <ogra> right
[14:42] <cjwatson> so I don't know why your tree would be picking one up
[14:42] <ogra> but i have /preseed.cfg in the booted d-i on the device
[14:42] <ogra> which makes me assume oldsys-preseed created it somehow
[14:43] <ogra> the values match wahts in oldsys-preseed
[14:43] <cjwatson> ah, right, yes oldsys-preseed would do that at run-time
[14:43] <ogra> right
[14:44] <ogra> cjwatson, btw, dont wait for me with the d-i upload for this ...
[14:44] <cjwatson> I'm waiting for other things at the moment
[14:45] <ogra> ok, just want to make sure ... the team has serial consoles anyway so for internal tests the debconf questions wont get in your way
[14:45] <cjwatson> need debian-installer-utils to publish
[14:45] <ogra> s/your/our/
[14:46]  * ogra goes for some late lunch
[15:17] <ogra> cjwatson, geez, most of the config is hardcoded in the oldsys-preseed script actually
[15:18] <ogra>                         sanity_check_static_config
[15:18] <ogra>                         if [ "$NET_CONFIG" != "static" ]; then
[15:18] <ogra>                                 IPADDRESS=192.168.1.77
[15:18] <ogra> .....
[15:18] <ogra> tsk
[15:18] <ogra> and the static file has exactly the same values ...
[15:18] <cjwatson> hah. Please take that up in a Debian bug report, I don't want to have to figure it out myself
[15:19] <ogra> will do
[15:24] <Keybuk> bryce: why is there an /etc/init.d/xserver-xorg-input-wacom ?
[15:25] <ogra> Keybuk, i wuld guess it calls hal-set-property to adjust the config
[15:25] <Keybuk> it does not
[15:25] <ogra> Keybuk, tablets are tricky since they have multiple input devices
[15:25] <ogra> hmm
[15:25] <Keybuk> it makes symlinks
[15:26] <Keybuk> in fact, it makes one symlink - /dev/input/wacom
[15:26] <ogra> shudder
[15:26] <ogra> now that should be halified ...
[15:27] <ogra> but its probably for backwards compatibility with old xorg.conf setups
[15:27] <sladen> and IIRC it's wrong anyway, as it's not an *input* (HID) device
[15:27] <Keybuk> ah
[15:27] <Keybuk> you misunderstand me
[15:27] <Keybuk> it makes a symlink, in /dev, to a device node, in /dev
[15:27] <Keybuk> based on properties found in /sys
[15:27] <Keybuk> I may be wrong, but we have a daemon entirely dedicated to that purpose
[15:28] <Keybuk> and would you know, xserver-xorg-input-wacom installs a config file for that daemon
[15:28] <Keybuk> and WOULD YOU KNOW it makes a symlink with it ;)
[15:28] <ogra> right, but we had that hardcoded /dev/input/wacom entry in xorg.conf from mr. garret for years
[15:28] <Keybuk> you still miss the point ;)
[15:28] <Keybuk> the symlink is already there by the time this init script runs
[15:28] <sladen> HAL/udev, yes yes yes
[15:28] <ogra> oh
[15:28] <ogra> gets it
[15:29] <ogra>  /me even :)
[15:29] <sladen> but the symlink that bryce (?) added is wrong anyway, so don't duplicate it
[15:29] <soren> sladen: Wacom tablets aren't input devices?
[15:29] <Keybuk> well, yes, having such a symlink is inherently bogus
[15:29] <sladen> soren: no, they're serial ports
[15:29] <soren> sladen: What would you call the thing at the end of it?
[15:30] <soren> I mean.. At the other end of the port?
[15:30] <sladen> soren: an RS-232 transceivever
[15:30]  * soren feels like he's missing half a story here
[15:31] <sladen> the protcol that runs over these serial ports is not HID, or kernel dev/input.  It's a 5-9 byte protocol that must be converted ito HID.  And *that* translated device added to /dev/innput
[15:32] <ogra> though it doesnt need to create the same symlink twice :)
[15:32] <sladen> the purpose of the shell script was to search for such "hidden" serial ports, and then tell X to talk magic protocol to those ports
[15:33] <Keybuk> sladen: no, the shell script doesn't do any of that
[15:33] <sladen> Keybuk: indeed.  However, that's what used to happen when it did work out of the box, which IIRC, it no longer the case...
[15:35] <Keybuk> such a shell script would still be wrong
[15:35] <Keybuk> HAL should do that kind of thing
[15:36] <sladen> Keybuk: agreed.  If there's now a in-kernel wacom driver (that translates to HID) it should be possible to make it all work "correctly"
[15:36] <Keybuk> there certainly seems to be
[16:43] <jeromeg> dholbach: could you please have a look at bug #318444 ?
[16:43] <jeromeg> I would like to get this in before feature freeze
[16:44] <dholbach> jeromeg: I'd prefer if somebody else could take a look at it - I'm quite busy atm - did you ask in #ubuntu-desktop?
[16:45] <jeromeg> dholbach: nope, I'll try that
[16:54] <rgreening> mvo: ping
[16:54] <mvo> rgreening: pong
[16:55] <rgreening> heya. I got a q for you... in the apt backend for kpk, do you know if it supports searching the app-install data (desktop) files for applications?
[16:56] <rgreening> mvo: I am looking at adding a simplified search to kpackagekit, as the default one returns all packages (i.e. libraries, etc) but the end user may only wish to know about applications from the app-install-data package.
[16:56] <rgreening> mvo: but I need some direction on how to set the correct Client Filter (if it exists)
[17:02] <mvo> rgreening: I thnk it does exist, glatzor was doing some work on the packagekit backend, he probably knows the answer better than me
[17:02] <rgreening> ok.
[17:03] <rgreening> glatzor: I have basically everything complete for a Add/Remove simple view in kpackagekit. I need some assistance on setting a filter for app-install desktop entires only.
[17:03] <rgreening> ty mvo
[17:03] <mvo> cheers, sorry that I was not more helpful
[17:04] <glatzor> rgreening, what should the filter return? the application names?
[17:06] <rgreening> glatzor: hey. Well, right now, if you filter on Group, it will return all packages in that group. I'd like to filter out libraries, etc and just return valid Applications from the app-install-data package. I was wondering if that exists?
[17:06] <rgreening> glatzor: like a filter AppOnly option or something
[17:09] <glatzor> rgreening, getting an application view requires a lot more things than just to hide libraries.
[17:09] <rgreening> glatzor: well, that's what I am asking...
[17:09] <rgreening> glatzor: is that backend written?
[17:09] <rgreening> glatzor: I have a ready to go front-end, if there is a backend filter available to use
[17:10] <glatzor> rgreening, there is already some code to map packages to menu entries (desktop files) which is used in the gnome utils
[17:10] <glatzor> but that is not very mature.
[17:10] <rgreening> glatzor: who is working that piece? if anyone?
[17:10] <glatzor> rgreening, e.g. it doesn't not handle multiple applications per package
[17:11] <glatzor> rgreening, richard
[17:11] <rgreening> glatzor: nick for richard?
[17:11] <glatzor> rgreening, I already gave you the recommendation to look at this code at UDS. :)
[17:12] <glatzor> rgreening, hughsie at #packagekit
[17:12] <rgreening> glatzor: ty. UDS was a long while ago. My brain forgot :)
[17:12] <rgreening> glatzor: I'll try richard,
[17:14] <glatzor> rgreening, there is already an infrastructure and terminology in the packagekit api: the basename or gui filter
[17:15] <glatzor> rgreening, but basenames aren't "yet" implemented in the apt backend
[17:16] <rgreening> glatzor: which part is that contained it?
[17:16] <rgreening> glatzor: oh...
[17:16] <glatzor> rgreening, we can take the discussion to #packagekit
[17:24] <rgreening> glatzor: is richard the one working on the basename stuff for the apt backend?
[17:27] <glatzor> rgreening, no. I am the apt backend maintainer and richard is the chief of the whole project :)
[17:28] <rgreening> ok, can you help me then?
[17:28] <glatzor> rgreening, he doesn't work on any other backend than the yum one
[17:28] <glatzor> rgreening, I hope so.
[17:28] <rgreening> glatzor: ok. so, what do we need to do?
[17:29] <rgreening> I can help, if you point me to things to test/try.
[17:32] <rgreening> glatzor: right not my front-end looks liek this... http://imagebin.ca/view/8dy8cR1.html
[17:33] <rgreening> glatzor: basically, whats missing is the ability to show only end-user apps, which comes down to a filter into the app-install-data somehow.
[17:37] <apw> pitti, did you get a chance to look at that apport thingy
[17:38] <kirkland> RainCT: howdy, just got your messages
[17:39] <kirkland> RainCT: regarding your screen-profiles mousewheel issue, can you read https://bugs.edge.launchpad.net/ubuntu/+source/screen-profiles/+bug/328536 and tell me if that's your issue?
[17:39] <RainCT> hi kirkland :)
[17:39] <kirkland> RainCT: please see my explanation in Comment 3
[17:39] <kirkland> RainCT: i think this is what you're experiencing.  if so, i will create a launchpad question/answer for this issue
[17:40] <RainCT> kirkland: I know the workaround, but I think that didn't happen before
[17:40] <RainCT> (workaround = that pgup/pgdown works)
[17:41] <kirkland> RainCT: hmm, okay, then i misunderstand your question
[17:41] <kirkland> RainCT: this is a regression against an earlier screen-profiles?
[17:41] <RainCT> I may be wrong though.. Perhaps I did just never try to scroll with the mouse before :P
[17:41] <kirkland> RainCT: or a regression against the way normal 'screen' works?
[17:41] <kirkland> RainCT: go back to using normal 'screen' for a moment, in a new gnome-terminal window
[17:42] <kirkland> RainCT: select-screen-profile, choose "plain"
[17:42] <RainCT> kirkland: Against normal. I've just tried uninstalling screen-profiles and it doesn't happen
[17:42] <kees> is this about mouse-scrolling?
[17:42] <kirkland> kees: yes
[17:42] <kees> kirkland: what's the expectation, that it _should_ scroll or not?
[17:42] <kirkland> kees: i'm fixing my cryptsetup mess right now too, sorry.
[17:42] <kirkland> kees: my explanation is: https://bugs.edge.launchpad.net/ubuntu/+source/screen-profiles/+bug/328536/comments/3
[17:42] <kees> kirkland: I already uploaded and committed to bzr for cryptsetup
[17:42] <RainCT> (normal screen just does nothing on scroll)
[17:43] <kees> RainCT: under "Profile preferences" in gnome-terminal, under Scrolling, there is a check-box for "Use keystrokes to scroll on alternate screen".
[17:43] <kees> is that the setting you're looking for?
[17:43] <RainCT> my problem isn't exactly the same as in the report though, if I understood it correctly. I have no problems unless I move the mouse whell, in which case I get old stuff.. I have scroll bars disabled and am using terminator
[17:44] <kees> oh, hm
[17:44] <RainCT> kees: that's enabled
[17:44] <s0u][ight> hello where can i find ubuntu staff?
[17:44] <kirkland> RainCT: you have multiple windows open within screen?
[17:45] <kees> RainCT: try turning it off, it may change what you're experiencing
[17:45] <kirkland> s0u][ight: depends on what you're looking for;  post your question, someone will answer if they have the information
[17:46] <s0u][ight> power is being abused in the turkish help forum
[17:46] <RainCT> kirkland: irssi, welcome and shell
[17:46] <RainCT> kees: still the same
[17:46] <s0u][ight> someone posted a question and the forum admins made fun out of him etc., another one supported that guy and he got banned from the forum
[17:46] <kirkland> RainCT: okay, and if you use irssi window for a bit, then switch to shell, and mouse-scroll back, you see irssi data?
[17:47] <RainCT> kirkland: yes
[17:47] <kees> RainCT: hrmpf
[17:48] <kirkland> RainCT: right, so gnome-terminal doesn't really understand that screen has multiple windows running beneath it
[17:48] <persia> s0u][ight, You'd do better to look for a forums admin on #ubuntuforums
[17:49] <RainCT> kirkland: but without the profile it works
[17:49] <kees> kirkland: it can depend on one's TERM -- I think there is a way to have screen's scrolling go off the top of the scroll-back buffer.  normally it's contained, though.
[17:49] <kirkland> RainCT: so with the plain profile, you can open multiple windows?
[17:49] <kirkland> RainCT: switch among windows
[17:49] <RainCT> kirkland: err, ignore my last sentence :)
[17:50] <kirkland> RainCT: roll your mouse wheel and scroll each window's buffer independently?
[17:50] <RainCT> nope :)
[17:50] <kirkland> kees: interesting, i'd love to solve that one
[17:50] <kees> kirkland: yeah, I've never known how to change it.
[17:51] <kirkland> as i understand it, it's a matter of which program traps and uses the mouse's scrollwheel keypresses
[17:51] <kirkland> since gnome-terminal is at the top of the stack, i think it captures it first
[17:51] <kirkland> unless you disable it, and ask it to pass that through to the shell program
[17:51] <kirkland> if we could do that, then we could probably tell screen to prepend an F7 on the beginning of that
[17:52] <kirkland> and voila, we'd have per-window scrolling
[18:06] <pitti> apw: doing right now; good work!
[18:07] <apw> its a lot better than the last one
[18:13] <cjwatson> coo, I think I have LVM handling working in kickseed
[18:13] <cjwatson> but that's enough for the day ...
[19:34] <_010100> can whomever is the mod on ubuntu-devel ML let my explanation of the effect the pulseaudio auto-spawn will have go through?
[19:34] <maco> er...right, joke nick --> real nick
[19:37] <Brujah> Is creative commons licence free enough to be in ubuntu? (for games resources)
[19:37] <maco> 2.5 or 3.0?
[19:37] <maco> i think 3.0 is DFSG-free, but 2.5 isn't
[19:38] <Brujah> f.e. the freesounds project?
[19:38] <maco> which CC license is it?
[19:40] <Brujah> Creative Commons Sampling Plus 1.0 License.
[19:41] <maco> wow that one hasnt been around on creativecommons.org in a while...lemme find the text
[19:43] <maco> actually...there's a list of DFSG-free licenses
[19:43] <maco> and yeah, it's on there
[19:43] <maco> oh wait
[19:43] <maco> in the "incompatible" category
[19:44] <maco> Brujah: http://wiki.debian.org/DFSGLicenses
[19:50] <persia> There's some variance between Ubuntu-free and DFSG-free, for example GFDL and CC-SA 2.5 are Ubuntu-free (if I remember correctly).  One would need to check the ubuntu-devel and sounders mailing list archives to find an actual opinion.
[19:52] <Brujah> so it could be that this licence is ubuntu-free? :-) the debian guys told me they cannot accept it. I use kubuntu so it would work for me :-)
[19:54] <james_w> Brujah: it does seem too restrictive, it would be a candidate for multiverse at the very least though
[19:58] <Brujah> I would rather like to replace everything that causes problems with really free stuff
[19:58] <Brujah> but for the sounds I cannot find nothing
[20:00] <Brujah> Its a dungeon crawling game
[20:00] <Brujah> www.lostlabyrinth.com
[20:00] <Brujah> we use 48 sounds
[20:01] <Brujah> are there any free sounds for dungeon games?
[20:02] <Brujah> there are tiles on sf which we use :-)
[20:02] <maco> Brujah: got a creaky door and a faucet you can make drip?
[20:02] <maco> you can always record some free sounds
[20:03] <Brujah> i lack the equipment I fear. I am a programmer :-)
[20:03] <persia> You don't have a sound card?  You can get a cheap mic (low-quality recordings are best for compression anyway) and attach it.
[20:03] <persia> Post the raw sounds, and ask someone to reformat, etc.
[20:07] <sistpoty> asac: would you volunteer as motu-release delegate for the mozilla team again?
[20:08] <Riddell> Brujah: CC is fine in Ubuntu (except for no-derivs of course)
[20:09] <persia> Riddell, All CC?  I thought we preferred 2.0+, and didn't like 1.0.
[20:09] <persia> (but the sampling license has a different numbering scheme)
[20:10] <Riddell> I don't think I've come across 1.0 licenced stuff, but 2+ is ok for us.  3.0 or up preferred of course since that's better for Debian
[20:10] <maco> the sampling license was retired after 1.0, i think
[20:10] <maco> they got rid of it in june '07
[20:10] <persia> I thought 1.0 was widely panned as being non-free.
[20:11] <persia> Anyway, if there's precedent for the license, it's free to upload.  If not, best to ask the TB.  TB response usually seems to be that anything redistributable can go in multiverse, which makes it easy to get included.
[20:12] <asac> sistpoty: i guess so ;)
[20:12] <sistpoty> asac: excellent, thanks :)
[20:13] <sistpoty> superm1: would you be willing to act as mythbuntu delegate for motu-release for this cycle again?
[20:13] <superm1> sistpoty, yeah should be able to.  i've already been hounding my guys to hit FF, so hopefully there won't need to be too much delegating necessary :)
[20:14] <sistpoty> superm1: cool, thanks!
[20:15] <sistpoty> ogra: and would you like to act as motu-release delegate for netbook remix (or whatever mobile is called nowadays) again?
[20:15] <Brujah> would you accept laby into multiverse? when I remove all the pictures from unknown sources and replace all sounds with cc licenced ones?
[20:17] <ogra> sistpoty, i hve not much to do with image building this release, i'm mostly doing arm ... StevenK does the ubuntu-netbook-remix and ubuntu-mid images, but it might be a bad time for him
[20:18] <sistpoty> ogra: ah, thanks...
[20:18] <ogra> your meeting times are not really aussie friendly
[20:18] <sistpoty> heh
[20:18] <sistpoty> I'll ask at a better time then :)
[20:19] <ogra> siretart, if he cant do it, i can be the fallback though
[20:19] <sistpoty> ogra: cool, thanks :)
[20:27] <geser> slangasek: Hi, could you please give bug #323863 another try and move now also the other binary deb and the source to universe too? thanks.
[22:09] <lamont> Keybuk: around still?
[22:09] <lamont> Keybuk: git clone git://git.debian.org/~lamont/util-linux.git; cd util-linux; git checkout -b foo origin/ubuntu/stable/v2.14
[22:09] <lamont> gets you the current tree
[22:12] <lamont> Keybuk: util-linux doesn't use debian/patches, if that's what you mean
[22:12] <lamont> since that way lies madness
[22:31] <Keybuk> lamont: what's the difference between master and the other branch?
[22:32] <lamont> master is "current devel" - basically all of my branches track karel's branches of the same name
[22:32] <lamont> and then ubuntu/* is a branch from *
[22:32] <Keybuk> but master has a debian directory?
[22:32] <lamont> which reminds me, I need to test 2.14.2-1ubuntu1 and upload it
[22:32] <lamont> sure
[22:33] <Keybuk> pretent that I'm confused by this whole git multiple branches in a branch thing
[22:33] <lamont> master is a debian-ish branch based off of karel's master
[22:33] <Keybuk> so I've done a checkout of your git tree
[22:33] <Keybuk> is that the util-linux package you upload?
[22:33] <lamont> I upload from stable/v2.14 or so - since I don't upload until it releases (or will release before our release, such as 2.14.2~rc2 ish)
[22:34] <superm1> Keybuk, am I to understand this correctly; we're not using upstart to spawn gdm?  I was talking to someone about the priority it starts in Fedora, and they *are* starting it from upstart.  Why not in Ubuntu?
[22:34] <lamont> and within stable/v2.14, I say "debuild -I.git -S" or so
[22:34] <Keybuk> so how do you keep all these changelogs straight?!
[22:34] <lamont> I don't bother with changelog until I'm uploading, and then I grab the 1-liner from each commit, along with it's author, to generate a debian changelog
[22:35] <lamont> that, mixed with never committing debain/ and !debian in the same commit -> love
[22:35] <Keybuk> so how does a changelog end up in master?
[22:35] <Keybuk> is that when 2.14 itself was released?
[22:35] <lamont> see also the commits with a log of 'changelog: release'
[22:35] <Keybuk> so your stable/v2.14 branch is what you actually upload as util-linux right now
[22:36] <lamont> master got a merge of the stable stuff at some point, it's probably seriously diverged
[22:36] <Keybuk> and that is based off Karel's stable/v2.14 branch
[22:36] <Keybuk> where does the ubuntu one come from?
[22:36] <Keybuk> do you just track other people's uploads with it?
[22:36] <lamont> the tag v2.13
[22:36] <lamont> meh
[22:37] <lamont> the head of stable/v2.14 is what I will have uploaded as 2.14.2-1 to debian, and head of ubuntu/stable/v2.14 will be 2.14.2-1ubuntu1 once I reboot my laptoo
[22:37] <lamont> p
[22:37] <lamont> at that point, I'll tag both trees, and push again
[22:38] <Keybuk> and when karel releases 2.15 off master, you'll merge the debian stable/v2.14 back into your master branch?
[22:39] <lamont> possibly even before that, but yes.  2.15 release from karel means: merge my stable/v2.14 and his v2.15 branch to a new stable/v2.15 branch
[22:39] <lamont> and yeah, smack it onto master as well at the same time
[22:39] <Keybuk> and people wonder why I laugh when they say revision control makes packaging easier
[22:39] <lamont> heh
[22:39] <lamont> OTOH, having a debian repo and a !debian repo makes me cry
[22:39] <lamont> so I quit trying
[22:40] <lamont> and directory-per-branch is one of the reasons I went with git instead of bzr when I did my mass exodus from CVS/TLA/arch in 05ish
[22:40] <lamont> that is, bzr's then-insistence on one-directory-one-branch was a major factor in not going there
[22:41] <Keybuk> debian repo and !debian repo?
[22:41] <lamont> I understand that's been fixed since then...:-)
[22:41] <lamont> some people like to have foo-1.1/.bzr and foo-1.1/debian/bzr and then magically do wonders to smash them together into a package to upload
[22:41] <lamont> maybe my failure to understand what they were doing is a factor in the screaming fit I had running from them
[22:43] <lamont> anyway - rebooting, brb (or screaming, pretty sure it'll be the "brb" option)
[22:44] <Keybuk> well, in theory, the Ubuntu diff should go away anyway
[22:44] <Keybuk> the vol_id/blkid thing is fixed upstream
[22:44] <Keybuk> you should just merge the udev hooks into Debian
[22:44] <Keybuk> and the fallback clause stuff should be sent upstream, and merged into Debian too
[22:45] <Keybuk> the udev rules directory change should go into Debian as well
[22:45] <calc> jcastro: how long did it take your lenovo to clear customs?
[22:46] <calc> my laptop has been sitting in US customs for 3 days it appears
[22:47] <directhex> Setting up monodevelop (1.9.2+dfsg-1~pre1~jaunty3) ...
[22:50] <jcastro> calc: 3/4 days
[22:51] <directhex> jcastro, ^^
[22:53] <dtchen> cody-somerville: RE: your e-mail to -devel, please note that *only* ubuntu-desktop seeds PulseAudio. None of {[kx],myth}ubuntu{,studio}-desktop do.
[22:54] <dtchen> cody-somerville: your inaudible audio issue cannot possibly have anything to do with those PulseAudio changes unless you installed pulseaudio explicitly.
[22:56] <ogra> dtchen, wow, do you have a shotcut key for that regex ? :)
[22:56] <ogra> *short
[22:56] <jcastro> directhex: ! awesome
[22:56] <calc> jcastro: ok
[22:57] <directhex> jcastro, needs a bugfixed mono-addins, which is in debian incoming
[22:57] <superm1> dtchen, i think that he was referring to breakage that happens when you install xubuntu-desktop on top of ubuntu-desktop and switch between the two
[22:58] <dtchen> superm1: which is by no means default, but yes, that's one specific test case i'm running locally
[22:59] <superm1> dtchen, yeah.
[23:00] <lamont> Keybuk: though the debian/control diff will not go away until udev has a similar version between the two distros...
[23:00] <dtchen> i've already identified a regression, but its probability of striking that particular use case and the one of only default *-desktop needs more feedback.
[23:00] <lamont> BTW, uploaded, and pushed
[23:01] <dtchen> (referring specifically to autospawn in this instance)
[23:02] <Keybuk> lamont: that's never going to happen :-(
[23:02] <Keybuk> lamont: did you deliberately miss out two ubuntu revisions?
[23:03] <calc> jcastro: i ended up buying a seagate 7200.4 500gb drive for mine, hopefully it won't be hard to swap out
[23:03] <cody-somerville> dtchen, I have ubuntu-desktop installed
[23:03] <cody-somerville> in addition to xubuntu-desktop
[23:06] <lamont> Keybuk: probably not deliberately, no.
[23:07] <lamont> but then, if it's a random upload to ubuntu, i don't always get it back into my tree, esp if it gets superseded before I get to it
[23:08] <persia> lamont, Can you not get it by revision from patches.ubuntu.com or LP?
[23:08] <Keybuk> lamont: gnargh!
[23:08] <Keybuk> lamont: it's ok to miss them when you're doing Debian uploads, but uploading to Ubuntu without checking is just not cool
[23:13] <Keybuk> lamont: need some git help here
[23:13] <Keybuk> I cannot seem to push my branch anywhere with my changes
[23:13] <TheMuso> dtchen: Have you noticed that if an alsa-info URL is broken into two lines in an email, it doesn't work?
[23:14] <RAOF> What would be an appropriate way to debug "Evolution spends the first 30 minutes thrashing the disk after startup"?  strace?
[23:15]  * calc has to remember how to determine how to properly handle the ooo human icons set
[23:16] <lamont> Keybuk: as in I dropped changes?
[23:16] <lamont> which would not be the intention
[23:16] <Keybuk> lamont: so, I've made a git branch with the missing changes
[23:16] <Keybuk> and I've added a changelog
[23:16] <lamont> thanks
[23:16] <Keybuk> now, how the hell do I push this somewhere?
[23:17] <Keybuk> because every time I do, git explodes in a violent array of puke or nothingless
[23:17] <lamont> git push ssh://git.debian.org/public_git/util-linux.git I expect
[23:17] <lamont> er..
[23:17] <lamont> git push ssh://git.debian.org/public_git/util-linux.git ubuntu/stable/v2.14
[23:17] <lamont> or so.
[23:17]  * lamont needs to run for an hour or so, unfortunately
[23:17] <Keybuk> why ubuntu/stable/v2.14?
[23:18] <RAOF> That would be the branch you want to push to, I think.
[23:19] <Keybuk> then I just get:
[23:19] <Keybuk> error: src refspec ubuntu/stable/v2.14 does not match any.
[23:22] <RAOF> Keybuk: What does 'git branch -a' say?
[23:22] <Keybuk> RAOF: lots, what are you looking for specifically?
[23:22] <Keybuk> http://rafb.net/p/YnJptB92.html
[23:23] <RAOF> Keybuk: I was hoping that the one with at * next to it was ubuntu/stable/v2.14
[23:23] <Keybuk> no
[23:23] <Keybuk> I couldn't do that
[23:23] <Keybuk> as soon as I tried to do anything on that branch, git threw me into a nameless branch
[23:23] <Keybuk> so I had to give it a name
[23:23] <Keybuk> thus "ubuntu"
[23:23]  * RAOF hates on git.
[23:23] <Keybuk> all I want to do is push _this_ branch somewhere that lamont can get it
[23:24] <RAOF> Maybe just 'git push origin' will work, then.
[23:24] <Keybuk> I can't push to an http url, can I? :)
[23:24] <RAOF> Mess with .git/config until it's no longer http? :).  I don't really know; I was just trying to help with my fairly minimal git knowledge.
[23:25] <directhex> silly git
[23:25] <Keybuk> how will that help?
[23:25] <Keybuk> I can make it ssh, but I don't have access to that machine
[23:25] <RAOF> Oh.
[23:26] <RAOF> I'm out of my depth then, sorry.
[23:55] <dtchen> cody-somerville: file a bug, then.
[23:56] <dtchen> TheMuso: no. do you mean MUA parsing?
[23:57] <TheMuso> dtchen: No, never mind, I am working around it by going to the web page for the bug.