[00:02] <pitti> cjwatson: my OEM test install hangs at the finish installation stage with 'Disabling netinst CD in sources.list...'
[00:03] <pitti> ah, nevermind; it just got stuck doing apt-get update
[00:04] <EvanCarroll> hrm
[00:10] <keescook> pawalls: okay, cool; thanks.  :)
[00:16] <slangasek> stgraber: ok, fundamentally there seems to be a problem with the tracker's link checker; even after switching the build number and waiting for cdimage.u.c to sync, I still get told for all images that "This build wasn't found on cdimage.ubuntu.com"
[00:16] <slangasek> gnyaah
[00:16] <slangasek> l-u-m FTBFS
[00:17] <slangasek> ... because of the merged -rt support
[00:19] <ogra_cmpc> any xfs pro around ?
[00:19] <ogra_cmpc> /usr/sbin/debootstrap: 317: cannot create /home/ogra/chroot-livecd/test-dev-null: No such device or address
[00:19] <ogra_cmpc> seems i cant create any devices on my xfs partition
[00:19] <ogra_cmpc> its not mounted with nodev or so
[00:24] <cjwatson> ogra_cmpc: hmm
[00:24] <cjwatson> let me see if I can reproduce that here
[00:24] <ogra_cmpc> it works fine on the /boot partitioni have
[00:27] <cjwatson> I introduced that debootstrap check quite recently; it might be buggy
[00:27] <cjwatson> could you put 'set -x' at the top of /usr/share/debootstrap/functions and get a shell trace?
[00:28] <ogra_cmpc> sure
[00:28] <cjwatson> ENODEV, though, that's just weird
[00:28] <cjwatson> not a documented return code from mknod(2)
[00:29] <ogra_cmpc> cjwatson: http://paste.ubuntu-nl.org/49089/
[00:32] <ogra_cmpc> root@ceron:~# mkdir test
[00:32] <ogra_cmpc> root@ceron:~# mknod test/test-dev-null c 1 3 || echo "failed"
[00:32] <ogra_cmpc> root@ceron:~# echo "blah" >test/test-dev-null
[00:32] <ogra_cmpc> bash: test/test-dev-null: No such device or address
[00:32] <ogra_cmpc> root@ceron:~#
[00:32] <cjwatson> ogra_cmpc: any other mount options I should know about?
[00:32] <ogra_cmpc> ogra@ceron:~$ cat /proc/mounts |grep " / "
[00:32] <ogra_cmpc> rootfs / rootfs rw 0 0
[00:32] <ogra_cmpc> /dev/md0 / xfs rw,sunit=128,swidth=256,ikeep,noquota 0 0
[00:33] <cjwatson> xfs, home of mount options nobody else recognises
[00:33] <ogra_cmpc> heh
[00:33] <ogra_cmpc> well, i didnt specify any options at all
[00:33] <ogra_cmpc> its the default teh installer choose
[00:36] <cjwatson> seems to WFM on a fresh XFS partition
[00:37] <cjwatson> s/partition/filesystem/
[00:37] <cjwatson> /home/cjwatson/xfs.disk on /mnt type xfs (rw,loop=/dev/loop0)
[00:37] <cjwatson> sunit and swidth are md things, ikeep and noquota aren't things the installer sets AFAICS, maybe defaults?
[00:37] <ogra_cmpc> hmm
[00:38] <ogra_cmpc> it seems teh xfs deeply ties into teh raid0 below
[00:38] <cjwatson> it's still a weird error though
[00:38] <ogra_cmpc> the suinit and switdh parameters seem to adjust values for the raid striping
[00:39] <cjwatson> might be worth checking dmesg for any errors there
[00:39] <cjwatson> it really looks like it's mounted with something that implies nodev, but I can't see what
[00:39] <ogra_cmpc>    39.130673] Filesystem "md0": Disabling barriers, not supported by the underlying device
[00:39] <ogra_cmpc> well, that should only affect speed
[00:40] <ogra_cmpc> nothing else intresting in dmesg
[00:40] <ogra_cmpc> no fresh errors in any logs either
[00:41] <cjwatson> kernel version?
[00:41] <ogra_cmpc> ogra@ceron:~$ uname -a
[00:41] <ogra_cmpc> Linux ceron 2.6.24-2-generic #1 SMP Fri Dec 14 00:02:38 GMT 2007 i686 GNU/Linux
[00:41] <ogra_cmpc> todays :)
[00:41] <cjwatson> I'm still on 2.6.22, FWIW
[00:41] <cjwatson> so that could explain the difference
[00:42] <ogra_cmpc> i got a .22 on it but i wont go in teh basement and reboot now, to tired ...
[00:42] <ogra_cmpc> hmm, i could fiddle wit grub remotely :)
[00:45] <ogra_cmpc> cjwatson: yep, seems to be a kernel based issue
[00:45] <ogra_cmpc> 2.6.22 works fine
[00:52] <pawalls> keescook, ping
[01:56] <keescook> pawalls: pong!
[02:04] <pawalls> keescook, Patch uploaded and confirmed to fix the OOPS when mounting NFSv4
[02:17] <keescook> pawalls: excellent, so, here's the weird part -- I'm able to mount with nfsv4 without crashes.  :(  Is the failing configuration special in some way?
[02:19] <keescook> pawalls: ah, nm, it seems to be partial hang.
[02:19] <keescook> I'll get stuff spun up -- thanks for sorting out this patch!
[03:27] <IntuitiveNipple> Is there a reason that bluez-utils doesn't build/install sdpd (Bluetooth Service Discovery Protocol daemon)? Because of this, remote devices can't discover services making connections impossible in some cases.
[03:28] <StevenK> IntuitiveNipple: In Hardy?
[03:29] <IntuitiveNipple> I'm using Gutsy, but looks like it's carried forward into Hardy too.
[03:29] <IntuitiveNipple> I've been tracking the changelogs, looked through the bugs, etc., and now working with the source. Trying to find out why it is not built
[03:30] <StevenK> Does it pose security problems if it is?
[03:36] <IntuitiveNipple> It poses a usability problem if SDP isn't available to remote devices - they can't discover any services to connect to! I'm just checking things out with Marcel Holtmann so I can be sure what/why etc :)
[03:38] <Burgundavia> IntuitiveNipple: ask pitti and mjg59
[03:40] <IntuitiveNipple> I think it's more of a 'changing target' issue with the bluez-utils userspace applications. Once I've got a definitive answer I'll post a bug-report if needed.
[03:40] <StevenK> I don't think I like the idea of a daemon broadcasting what I'm running over Bluetooth
[03:41] <IntuitiveNipple> If the BT device isn't discoverable, it ain't available, but when the device is discoverable, I want the darned thing to tell my devices what it can do!
[03:42] <Burgundavia> IntuitiveNipple: I am going to guess it is a security issue
[03:42] <persia> IntuitiveNipple: Might be nice to have a configuration tool to allow exposure of desired services without broadcasting to anyone within 10 metres.
[03:44] <IntuitiveNipple> It appears maybe it isn't. It looks like, along with the other bluez* deamons, the functionality has been incorporated into the hcid daemon, and by default Gutsy/Hardy both configure it to operate the internal SDPD server. The problem is, it isn't exposing the services (on my tests anyhow) even though I've customised the 'class' setting in /etc/bluetooth/hcid.conf as required.
[04:46] <slangasek> Burgundavia: ribbit
[04:48]  * Fujitsu squishes slangasek under his foot.
[04:49]  * Hobbsee tries to remember what a fast X actually feels like
[04:49]  * Fujitsu hugs XAA.
[04:49]  * Hobbsee would hug it, except for the random, exploding crashes
[04:50]  * Fujitsu just has the one or two a day.
[04:55] <Farquad> anyone know if a music player exists that would allow me to add files to a playlist on one computer, then have another node pc play those files when i click play? (a remote controlled client)
[04:55] <Fujitsu> This isn't a support channel.
[04:55] <persia> Farquad: Yes, but you likely want to ask which of them is good for your use case, and how to use them in #ubuntu or #ubuntu-xx.
[04:57] <Farquad> i wasnt asking for support, i was trying to find out if something like this already existed
[04:57] <Hobbsee> which is a support related question, not a developmen tone...
[04:58] <Hobbsee> i think there is, though.  i don't remember what it's called, but i expect google, etc, could help there
[05:03] <Farquad> sorry to interrupt all the conversations going on in here
[05:37] <Hobbsee> note to self:  don't replace current X driver, in an X session.
[05:37] <Fujitsu> That shouldn't normally do much...
[05:38] <Hobbsee> no, but if you end up copying it over to what it's directly using..it appears to mangle your X
[05:38] <StevenK> It should be mmap()'d if it's using it
[05:41] <Hobbsee> unless compiz screwed it over, or something.  *shrug*
[05:43] <Fujitsu> Hah.
[05:45] <Hobbsee> oooh...
[05:45] <Hobbsee> *this* is what fast X feels like
[05:45] <Fujitsu> New driver works?
[05:45] <slangasek> yes, replacing the X driver from within X isn't supposed to break anything
[05:46] <Fujitsu> slangasek: That's what I thought, or upgrades would be a bit difficult.
[05:46] <StevenK> Until you restart X at least. :-P
[05:46] <slangasek> the driver is already loaded in memory, unpacking the new one just means the driver on disk doesn't match the one that's running (due to the magic of POSIX file deletions)
[05:48] <Hobbsee> Fujitsu: no, but i switched from exa to xaa again
[05:48] <Fujitsu> Ahh.
[05:48] <Hobbsee> slangasek: yeah well.  that's what i thought should happen.
[05:48] <Hobbsee> until my screen went bang.
[05:49] <slangasek> seems more plausible that it was StevenK emitting X-interference
[05:49]  * StevenK looks innocent.
[05:50] <Burgundavia> slangasek: rabbit
[05:52] <slangasek> Burgundavia: hiya. were you still going to have time to work on alpha2 release notes? :)
[05:53] <Hobbsee> keep in mind, he'll shoot you if you don't do them
[05:55] <slangasek> now, now, I very rarely shoot people for things they /haven't/ done
[05:55] <Hobbsee> no time like the present to start, then
[05:56]  * Fujitsu thinks slangasek unleashes the Canonical-issue doomsday device in that case.
[06:42] <warp10> Hi all!
[06:48] <musther> Hello
[07:03] <Burgundavia> slangasek: sadly real life intervened, so no
[07:08] <slangasek> ok
[07:09]  * slangasek scribbles something quickly in crayon
[07:26] <dholbach> good morning
[08:03] <Hobbsee> morning pitti!
[08:03] <pitti> Good morning
[08:04]  * pitti yawns
[08:04]  * Hobbsee force feeds pitti some coffee
[08:05] <pitti> argl coffee!
[08:05]  * pitti redirects Hobbsee to some tea
[08:05] <sivang> hi all
[08:10]  * Hobbsee force feeds pitti a mix of coffee and tea, then.
[08:10] <Hobbsee> heya sivang!
[08:10] <pitti> hey sivang
[08:12] <Fujitsu> Hobbsee: That sounds even more revolting than normal coffee. Spoiling perfectly good tea...
[08:12] <Hobbsee> Fujitsu: there is no good tea.
[08:12]  * pitti celebrates the release of apport 0.100
[08:12] <dholbach> Hobbsee: pfffft
[08:12] <dholbach> pitti: ROCK ON :)
[08:12] <StevenK> pitti: My upload of gimp broke :-(
[08:13] <StevenK> As in, it FTBFS
[08:13] <Fujitsu> Hobbsee: Oy. <3 tea.
[08:13] <Fujitsu> pitti: What's new?
[08:13] <slangasek> StevenK!
[08:13] <pitti> Fujitsu: primarily that it doesn't spill core files everywhere with our new kernel
[08:13] <StevenK> slangasek: Hrm?
[08:14] <slangasek> StevenK: I see you uploaded libofa?
[08:14] <StevenK> slangasek: Right
[08:14] <Hobbsee> StevenK: run.  run now.
[08:14] <slangasek> StevenK: you broke kubuntu
[08:14]  * sivang hugs pitti Fujitsu Hobbsee dholbach StevenK 
[08:14]  * Hobbsee hugs sivang
[08:14] <sivang> Hobbsee: thanks, I needed that
[08:14] <dholbach> hey sivang
[08:14]  * Fujitsu hugs sivang.
[08:14] <pitti> Fujitsu: the rest are just fixes to the retracers which were rolled out long ago
[08:14]  * dholbach hugs sivang back
[08:14] <sivang> hey you dholbach my good o' friend :)
[08:14] <Fujitsu> pitti: Aha.
[08:15] <slangasek> StevenK: we're now straddling a package name change for fftw3->libfftw3-3, and the packages conflict and kubuntu needs things depending on both of them
[08:15] <pitti> Fujitsu: but apport is now compatible with a vanilla upstream kernel >= 2.6.24, that's great
[08:15] <sivang> dholbach: I'm sorry for not responding for the patch apply request for hubackup, I've been through a bit like hell during the last couple of months but I'm back in shape
[08:15] <StevenK> slangasek: Right, I'm still cleaning up that mess.
[08:15]  * sivang enjoys the hugging
[08:15] <dholbach> sivang: it's great to hear you're back!
[08:16] <sivang> thanks! =)
[08:16] <Fujitsu> pitti: Oh, nice.
[08:16] <StevenK> slangasek: If you want some packages pushed up the queue, bug me with their source name
[08:16] <slangasek> StevenK: does this mean you have a libtunpimp upload pending, or should I go ahead and upload this no-change rebuild?
[08:16] <sivang> dholbach: I need to apply the branch with the patch there waiting, and then move on to rewrite the backend to use rdiff backup instead of dar
[08:16] <StevenK> slangasek: Ah, libtunepimp. Go ahead with that, I'll follow later tonight with another batch of rebuilds.
[08:16] <dholbach> sivang: ok cool
[08:17] <sivang> and ofcourse, the joy of helping merges, fixing packages etc etc
[08:17] <Hobbsee> StevenK: and risk being killed again?
[08:17] <sivang> dholbach: are you by any chance a CC person ?
[08:17] <StevenK> Not me not being killed.
[08:18] <slangasek> hmm, or should I change libtunepimp so that it's not linking to fftw at all, since it's not using it :P
[08:18] <dholbach> sivang: yes, but I think you can renew your ubuntumembers membership yourself
[08:18] <slangasek> nah, that can be my next upload
[08:20] <sivang> dholbach: it won't let me since it expired, I was too busy and offline to notice the emails
[08:20] <dholbach> sivang: taking a look
[08:20] <sivang> dholbach: thanks
[08:21] <slangasek> StevenK: so is there a reason you uploaded libofa in the middle of a milestone freeze? <smiles sweetly>
[08:21] <StevenK> It wasn't a milestone freeze when I uploaded it.
[08:21] <dholbach> sivang: renewed it
[08:21] <StevenK> It required curl to get fixed and then it was given-back
[08:21] <slangasek> StevenK: timestamp says Dec 19
[08:22] <slangasek> freeze started on Tuesday
[08:22] <sivang> dholbach: thank you!
[08:22] <StevenK> Ah
[08:22] <Hobbsee> StevenK: hint:  blame timezones
[08:22] <StevenK> slangasek: In which case, it completly slipped my mind, sorry
[08:22] <slangasek> right
[08:23] <StevenK> Maybe a little of what Hobbsee said, too
[08:23] <slangasek> note to self to always send out a u-d-a mail at the start of any freeze
[08:23] <StevenK> Yeah, that'd help
[08:23] <sivang> ah, so we're in a freeze now? but probably universe is as usual still open ?
[08:23] <slangasek> StevenK: except I know what way the clock runs, so it was /definitely/ Wednesday for you when you uploaded it ;)
[08:24] <StevenK> Bah, out-smarted again :-P
[08:24] <Hobbsee> slangasek: australian clocks are different.
[08:24] <Hobbsee> slangasek: they run backwards, as we're upside down.
[08:24] <slangasek> that's right, the coriolis force makes them.. .bah
[08:24] <StevenK> Haha
[08:24] <slangasek> anyway
[08:25]  * StevenK runs off to get din-dins
[08:25] <slangasek> at least as much my fault, for thinking I could skimp on announcing a self-imposed freeze
[08:25]  * persia requests that slangasek add a small note about universe on the reminder note to announce freezes.
[08:26]  * sivang wonders how he can catch up with all protocl and workflow changes since last time, or has the DistroPolicyTracker been implemented yet? :-))
[08:26] <slangasek> persia: and miss out on our monthly game of "what does this mean for universe"? ;)
[08:26] <slangasek> persia: yes, ok
[08:26] <persia> slangasek: Thank you :)
[08:26] <sivang> slangasek: heh
[08:26] <persia> slangasek: Feel free to ping me if you need text :)
[08:27] <slangasek> libtunepimp ubuntu2 uploaded
[08:28]  * sivang wonders if http://blog.vaxius.net/?p=19 has a bug reported against it, probably needs a patch revert on the SLUB for folks who have ATI cards
[08:35] <slangasek> StevenK: btw, you know libfftw3-dev still Provides: fftw3-dev?
[08:41] <pitti> (just FAOD, our buildds consider pure virtual package dependencies, so we could even just remove the NBS one)
[08:42] <slangasek> I just did that
[08:42] <slangasek> :)
[08:43] <pitti> sivang: policy> Ubuntu development policies are documented at wiki.ubuntu.com/UbuntuDevelopment; some months ago I documented all the freezes, too, and cleaned them up a bit; it's linked from that page
[08:44] <TheMuso> So with all this new xorg stuff, how is one supposed to tell xorg about one's monitor, if they happen to be using it through a KVM that prevents DDC/monitor probing? I see dpkg-reconfigure xserver-xorg doesn't include monitor options any longer for setting resolutions/refresh rates.
[08:44]  * TheMuso has just done an alternate install with the latest image and run into my above issue.
[08:45] <slangasek> TheMuso: uh, I think step 1) is "file a bug on xserver-xorg"? :)
[08:46] <tjaalton> TheMuso: displayconfig?
[08:46] <TheMuso> slangasek: Ok, I thought removing monitor options from dpkg-reconfigure was intentional.
[08:46] <tjaalton> it is
[08:46] <slangasek> well, ok
[08:47] <tjaalton> but yes, it seems that vmware and KVM have issues with it
[08:47] <tjaalton> but I'm not sure how it worked before
[08:47] <tjaalton> TheMuso: bug 172821
[08:47] <ubotu> Launchpad bug 172821 in xorg-server "[hardy] only get 800x600 in vmware" [Medium,Confirmed] https://launchpad.net/bugs/172821
[08:48] <pitti_> tjaalton: hm, just booted my desktop, X failed with "could not find read-edid blabla"; missing dependency?
[08:49] <pitti_> tjaalton: ooh, I bet that's just because -nvidia-new is uninstallable
[08:49] <tjaalton> right :/
[08:49] <pitti_> and then the failsave X kicks in and fails, too
[08:49] <sivang> pitti_: oh wow, cool :) finally
[08:49] <TheMuso> Ok, so in displayconfig-gtk, how am I supposed to set resolution/refres rate, if the combox boxes have nothing in them?
[08:50] <pitti_> FSVO "failsafe" :)
[08:50] <tjaalton> TheMuso: now that's another problem :)
[08:50]  * TheMuso is in the screen tab
[08:51] <tjaalton> I'll install gutsy on vmware to see how it got it
[08:51] <TheMuso> tjaalton: Remember, I am using my monitor through a KVM that prevents proper monitor probing.
[08:52] <slangasek> TheMuso: what model is that so I know not to get it when I go shopping next month? :)
[08:52] <slangasek> the kvm model, I mean
[08:52] <tjaalton> TheMuso: oh KVM, I thought you meant the virtualization software :)
[08:52] <TheMuso> slangasek: Couldn't tell you at the moment, and I'd have to get sighted assistance to tell me anyway.
[08:52] <slangasek> TheMuso: ok, please don't go to the trouble then
[08:52] <TheMuso> Needless to say, I'll be saving up for a better one.
[08:53] <tjaalton> TheMuso: in that case please file a bug on xorg-server
[08:53] <TheMuso> I liked the fact that it was 4 ports when I got it, and I was assured, dispite not being able to confirm it, that it supported DDC/probing.
[08:53] <TheMuso> tjaalton: Ok.
[08:53] <tjaalton> TheMuso: so you get a crappy resolution with it?
[08:53] <TheMuso> tjaalton: 800x600
[08:54] <tjaalton> yeah..
[08:54] <TheMuso> Yet my monitor is capable of 1680x1050
[08:54] <persia> TheMuso: You may be able to fool displayconfig-gtk if you can download the edid file from somewhere.
[08:54] <TheMuso> persia: edid?
[08:55] <TheMuso> I could also temporarily plug the monitor in directly.
[08:55] <TheMuso> tjaalton: on xorg-server, or xserver-xorg?
[08:56] <tjaalton> TheMuso: the former, it's the source package for xserver-xorg-core
[08:56] <TheMuso> right
[08:56]  * TheMuso goes to do just that.
[08:56] <tjaalton> TheMuso: also, if you have one please attach the good Xorg.0.log
[08:56] <persia> TheMuso: The data read-edid would be getting from the monitor, giving resolution, refresh rates, etc.
[08:56] <TheMuso> persia: RIght.
[08:57] <TheMuso> tjaalton: I can get that from another machine on the same KVM that is correctly configured to work with the monitor.
[08:57] <tjaalton> TheMuso: did it work OOTB?
[08:57] <TheMuso> OOTB?
[08:57] <tjaalton> out-of-the-box
[08:58] <TheMuso> tjaalton: No, I ran dpkg-reconfigure xserver-xorg, this is on hardy, a little while back.,
[08:58] <TheMuso> As I said, KVM not supporting monitor probing.
[08:58] <tjaalton> TheMuso: oh right
[08:58] <tjaalton> yep, and since you can't select a valid resolution you're doomed
[08:58] <TheMuso> Yep.
[09:00] <tjaalton> TheMuso: so, I'm not sure yet if it can be fixed by the server, but at least it should be possible to force the resolution using displayconfig-gtk or similar
[09:01] <TheMuso> Ok
[09:02] <TheMuso> tjaalton: Off hand, is there any bug that is similar, so I'm not creating a dup?
[09:02] <tjaalton> TheMuso: not that I remember
[09:02] <persia> tjaalton: displayconfig-gtk reacts poorly to not having a valid edid and not being able to get one from the monitor.
[09:02] <TheMuso> tjaalton: ok thanks
[09:02] <TheMuso> filing now
[09:03] <tjaalton> persia: yeah, I realize that, but perhaps it could be extended somehow
[09:04] <persia> tjaalton: Right now it asks for an EDID if it can't get one, and generally flails when given the wrong one.  Perhaps defining a generic set for 10 or 15 standard sizes as fallbacks?
[09:05] <TheMuso> or allowing the user to enter the info manually.
[09:06] <TheMuso> WHen I usually run dpkg-reconfigure xserver-xorg, I enter monitor refresh rates, and select resolutions manually.
[09:07] <TheMuso> Bug 177852
[09:07] <ubotu> Launchpad bug 177852 in xorg-server "Unale to manually configure monitor resolution and refresh rate with latest xorg-server in hardy." [Undecided,New] https://launchpad.net/bugs/177852
[09:08] <tjaalton> TheMuso: thanks
[09:09] <TheMuso> tjaalton: np.
[09:24] <kagou> Good morning
[09:34] <pitti> hi kagou
[09:34] <kagou> hey pitti, what's up ?
[09:38] <StevenK> slangasek: I got told this after the 46 uploads I did made the change.
[09:40] <slangasek> StevenK: haha
[09:40] <slangasek> StevenK: well, you get to merge them next release cycle ;
[09:40] <slangasek> )
[09:40] <ion_> Heh
[09:40] <StevenK> Or get a shedload of mail saying "You have lots of merges, can I do them all?"
[09:40] <pitti> argh, these reboots between .24 and .22 are unnerving, brb
[09:41] <slangasek> to balance things out, I'll send you a mail saying "You have lots of merges, can you do them all?"
[09:41] <StevenK> Hah
[09:43] <geser> good morning
[09:43]  * slangasek moos
[09:47] <dholbach> hey pitti, hey mvo
[09:48] <mvo> hey dholbach!
[09:48]  * pitti hugs dholbach
[09:48]  * dholbach hugs pitti and mvo
[09:48] <pitti> dholbach: just rebooted :)
[09:48] <pitti> .24 still has a few wrinkles
[09:57] <geser> Hi pitti
[10:01] <ulaas> anybody interested with install problems (gutsy) on an intel c2duo imac?
[10:07] <ulaas> anybody interested with install problems (gutsy) on an intel c2duo imac?
[10:09] <ion_> Is it just me, or does it echo in here?
[10:09] <ulaas> u?
[10:11]  * Fujitsu notes that it does echo, and that this isn't a support channel.
[10:13] <seb128> echo echo echo
[10:13] <ulaas> easy! :) i know that this is not the support channel. i just thought that people here might be more interested than in #ubuntu
[10:13] <mvo> ohce
[10:14] <seb128> hey mvo
[10:15] <mvo> hey seb128
[10:30] <mjj29> so, my dbus-java build from yesterday was retried, and the b-d installed fine
[10:31] <mjj29> but it still failed because the buildd is not using a UTF-8 locale
[10:32] <slangasek> sounds like a source bug on your end to me ;)
[10:32] <mjj29> (the tests have utf8 string literals to check that utf8, which is the defined format for dbus strings, works; java interprets string literals in the current locale)
[10:33]  * Fujitsu wonders if python-apt can be used to poke around in source caches too.
[10:33] <mjj29> and the tests are run at build time to check for regressions
[10:33] <mjj29> I'm not sure how best to fix this
[10:33] <slangasek> mjj29: there are various examples of packages in the archive that build-depend on locales and generate a copy of locales that they need locally; your package should either do this, or not expect utf8 support
[10:33] <mjj29> slangasek: is there an easy way to find one of these to crib from?
[10:34] <slangasek> mjj29: grep-dctrl -FBuild-Depends locales ? :)
[10:34] <mjj29> slangasek: thanks
[10:35] <slangasek> ipolish looks like a pretty straightforward one
[10:37] <TheMuso> tjaalton: Re the bug I filed, I've just connected the monitor directly, and re-run displayconfig-gtk. The bug has the relevant log and info.
[10:43] <slytherin> pitti: There are several java libs/apps which need to be moved to universe. I have logged a tracking bug which is confirmed by geser. Is there any chance it will get processed today?
[10:43] <tjaalton> TheMuso: ok thanks
[10:53] <pitti> slytherin: yes, can do; however, I just recently promoted a few because OO.o needs them; where's the bug?
[10:54] <slytherin> pitti: bug 176139
[10:54] <ubotu> Launchpad bug 176139 in libtoolbar-java "Please move package to universe" [Wishlist,Confirmed] https://launchpad.net/bugs/176139
[10:56] <pitti> slytherin: ah, from multiverse to universe; that's fine
[10:56] <pitti> slytherin: will get to it in a minute
[10:57] <soren> What's the story about all the different db4.x? I remember we were trying to get rid of one or more of them from main..
[10:57] <slytherin> pitti: Thanks. :-)
[10:57] <pitti> soren: right; if you happen to upload something that can be moved to 4.6 (libdb-dev), please do
[10:57] <pitti> that will cut down the mass-rebuilds later
[10:59] <soren> pitti: I figured as much. I wonder why apache is still built against db4.4..
[10:59] <pitti> soren: not sure; packages which use on-disk transactions are a PITA to migrate, but apache doesn't sound like something that would use them
[11:00] <soren> pitti: Not transactions, no. Rewrite rules.
[11:00] <soren> pitti: ...and they are even worse, as they can be scattered all over the place.
[11:00] <pitti> soren: anyway, if grep -r DB_TXN doesn't bring up anything, then it's safe to move
[11:01] <pitti> (that's a sufficient, but not necessary condition, BTW)
[11:01] <soren> pitti: Oh, apart from transactions, the binary formats are compatible?
[11:01] <pitti> soren: yes; the API might have changed slightly, but most packages I stumbled across just build fine with any version
[11:02] <soren> pitti: Oh, it *builds* fine, I think. The thing I'm worried about are the existing databases of rewrite rules people might have  suddenly stop working.
[11:02] <pitti> soren: the db format itself didn't change, just the transaction log
[11:03] <soren> pitti: Ah, cool. Thanks.
[11:04] <soren> Mithrandir: Can you think of any particular reason why apache must be built against db4.4 ?
[11:05] <thom> has svn changed?
[11:05] <thom> that's always the problem child for apache
[11:06] <soren> thom: Ah..
[11:06] <soren> thom: Not that I know of.
[11:08] <thom> well, that's the one. apr and svn and apache2 need to be in lockstep
[11:08] <soren> Sure. And php, too (which was what I was actually looking at).
[11:08] <thom> otherwise there is wailing and gnashing of teeth
[11:09] <pitti> so we can change them all at the same time?
[11:17] <soren> pitti: I have no clue what would be required to make subversion work with db4.6.
[11:18] <thom> soren: well, it rather depends what the upgrade path is for a db4.4 db to a db4.6 db
[11:18] <soren> pitti: ...but yes, upgrading the all at the same time is the (only) way to go, I believe.
[11:19] <soren> thom: Well, according to pitti, it's only the transaction log that changed, so we'd need to rebuild against db4.6 and make sure that anything that's using libsvn is restarted, otherwise we're in trouble, I suspect.
[11:20] <thom> then rebuilding should be fine, since apache restart will get mod_svn and i assume that the subversion package will restart any long running svnserve processes
[11:21] <thom> check that though
[11:22] <sivang> slomo !
[11:22] <slomo> hi sivang
[11:23] <pitti> hey slomo, how are you?
[11:24] <slomo> pitti: i'm fine, thanks :) and you? :)
[11:25] <pitti> bit stressed, but good (need to find some christmas presents still, though)
[11:25]  * soren decides not to change subversion, apache2, *and* php5 to a new db4.x version on the last day before holiday.
[11:26] <siretart> slomo && sivang ! :)
[11:26] <siretart> slomo: did you have the chance to look at ffmpeg from experimental yet again?
[11:27] <soc> hi
[11:27] <slomo> siretart: works good for me :)
[11:27] <soren> What happened to the alpha, by the way?
[11:28] <soc> does someone know the plans for ati gpus in 8.04?
[11:28] <soc> which driver will be used as a default?
[11:28] <StevenK> pitti: If you have a sec, I want to discuss the gimp SRU. The one I uploaded FTBFS, what is the next step, aside from test building more. :-(
[11:28] <soc> and will the fglrx version in the repos be updated?
[11:28] <slomo> siretart: imho can go to unstable
[11:28] <soc> because 7.11 contains a nasty meory-leak
[11:28] <siretart> slomo: I have rebuilt the archive against the new ffmpeg, but didn't do larger tests yet
[11:28] <siretart> slomo: did you try it on ppc as well?
[11:29] <pitti> StevenK: just upload a fix
[11:29] <slomo> siretart: nope, only x86... and i didn't do larger tests yet but only "used" it :)
[11:29] <siretart> I think sam wants to have another look at the altivec patches before letting it into unstable
[11:29] <thom> soren: heh, seems sensible
[11:29] <siretart> slomo: how do you feel pushing it to hardy?
[11:30] <StevenK> pitti: Suggest for version number, since I seem to loose at picking them.
[11:30] <pitti> StevenK: ...7.10.1?
[11:30] <pitti> 7.11 would be bad :)
[11:31] <slomo> siretart: well, get it into unstable and sync :)
[11:31] <StevenK> Heh, yes
[11:31] <StevenK> pitti: 7.11 is what dch did by default :-)
[11:32] <siretart> slomo: I fear that this will take some more time, and won't make it before hardy freeze
[11:32] <siretart> having it tested in hardy would help here, otoh
[11:34] <siretart> slomo: how about this: we modify mplayer to use its internal ffmpeg, and build a shared ffmpeg library from it, and link the world against that?
[11:34] <slomo> siretart: then better get the experimental ffmpeg to hardy
[11:34] <slomo> siretart: it's from the same day anyway, no? :)
[11:35] <siretart> slomo: exactly for this reason. the 'build ffmpeg from mplayer' approach would leave us with 2 versions of ffmpeg and additional flexibility
[11:35] <slomo> i don't see any advantage in this... but if you think it's better... :)
[11:36] <slomo> bbl
[11:36] <siretart> slomo: wait a sek!
[11:36] <siretart> hm. too late
[11:49] <geser> pitti: have you an idea how an .orig.tar.gz can vanish during build? http://launchpadlibrarian.net/10082300/buildlog_ubuntu-hardy-i386.mush_7.2.5unoff2-25_FAILEDTOBUILD.txt.gz
[11:50] <geser> it builds fine in a hardy pbuilder so perhaps a give-back should be tried
[11:51] <cjwatson> that looks like the package is assuming that its .orig.tar.gz is present in .., which isn't necessarily true on a buildd
[11:51] <cjwatson> I think that's a bug in the package, and it's going to have to find some other way to do the same thing
[11:52] <pitti> whoa, how strange
[11:52] <cjwatson> perhaps using pristine-tar to regenerate the .orig.tar.gz?
[11:52] <zul> hello
[11:52] <pitti> but how can this happen in dpkg-deb?
[11:53] <cjwatson> it's not
[11:53] <cjwatson> read mush/debian/rules
[11:53] <pitti> ah, ok
[11:53] <cjwatson> dpkg-deb is just the previous thing that's done
[11:55] <geser> cjwatson: thanks for the explanation
[11:55] <StevenK> pitti: gimp uploaded, please accept at your leisure.
[12:14] <geser> pitti: as build-depending on sun-java[56]-* seems to work now, please give-back: lucene2 libglazedlists-java jbidwatcher javassist glassfish. Thanks
[12:14] <pitti> geser: \o/ done
[12:16] <Fujitsu> geser: ooh, how'd you manage that?
[12:16] <geser> Fujitsu: infinity did some black magic on the buildds
[12:17] <pitti> Fujitsu: debconf preseeding for the license question
[12:17] <Fujitsu> Ahh.
[12:18] <Fujitsu> I think batik wants that too.
[12:18] <Fujitsu> (giving back, that is. It b-d on some JRE)
[12:18] <slytherin> geser: How is it working?
[12:19] <slytherin> geser: I mean build-depends on sun-jdk?
[12:20] <geser> Fujitsu: I don't think j2sdk1.4 uses the same debconf question
[12:20] <geser> slytherin: if it builds with the sun-java packages updating the build-depends should allow it to get build on the buildds
[12:22] <slytherin> I think then batik build can be fixed. But I will be very much interested to have batik 1.7 when it releases as it compiles with GCJ. :-)
[12:22] <geser> slytherin: any date known for the new release?
[12:23] <slytherin> nope
[12:28] <pitti> tjaalton: hm, xserver-xorg-driver-all wants to go to universe; was this dependency deliberately dropped?
[12:29] <pitti> oh, it's called -video-all nwo
[12:29] <tjaalton> pitti: no that's a new transitional package
[12:29] <pitti> so we should seed it for dapper upgrades
[12:29] <tjaalton> requested by mvo
[12:29] <pitti> ok, seeding; thanks
[12:30] <mvo> pitti: having it in main helps dapper->hardy upgrades
[12:30] <mvo> (and having it at all :)
[12:30] <mvo> thanks pitti (and tjaalton for adding it!)
[12:32] <pitti> committed
[12:33] <jpatrick> hmm, could someone tell me why I've just gotten a "Accepted: pulseaudio 0.9.6-1ubuntu2~feisty1 (source)"?
[12:33] <pitti> jpatrick: because you or someone else from the backporters team requested a feisty backport
[12:33] <jpatrick> ah, ok
[12:36] <pitti> ArneGoetje: FYI, fontforge is depwaiting on libspiro-dev; that needs a MIR, or we demote fontforge to universe (which might be adequate)
[12:39] <stgraber> slangasek: You can rename builds on the tracker (through the milestone management page), the download info page is to be completely reworked as soon as we have a .manifest file on cdimage (parsing the cdimage isn't a good idea at all :))
[12:40] <stgraber> your last night problem was certainly some hardcoded gutsy in the cdimage parser, I'll have a look and get that fixed
[12:42] <stgraber> slangasek: it was indeed some hardcoded "gutsy", I changed them to hardy and it seems to work again
[12:49] <dholbach> MOTU Q&A session in 11 minutes in #ubuntu-classroom
[12:52] <cjwatson> dholbach: I think I'm off your sponsoring hitlist now
[12:53] <pitti> mjj29: ah, I saw your dbus-java commits, thanks
[12:53] <dholbach> cjwatson: I just noticed - thanks a lot for that, you ROCK!
[12:53] <dholbach> cjwatson: and thanks for your input in the MOTU Meeting
[12:54] <Keybuk> seb128: hmm, that was odd; xchat-gnome's lock ups were permanent this morning
[12:56] <seb128> Keybuk: did you try removing pulseaudio?
[12:56] <Keybuk> yes, that's how I got online :-)
[12:56] <Keybuk> oddly enough, this seems to have also made flash sounds work again -- I'm not sure that this is a good thing
[12:59] <seb128> I'm wondering why xchat-gnome hangs when pulseaudio is used though
[13:06] <ogra> Keybuk, you likely need libflashsupport for flash sound with pulse (not sure if tahts also needed for non networked pulse sound though, we need it in ltsp since we use pulse there)
[13:07] <Keybuk> ogra: is that packaged?
[13:07]  * ogra wonders why the binary wasnt built yet ... it was accepted a while ago
[13:07] <ogra> Keybuk, yes, but no binary it seems
[13:10] <jpatrick> pitti: is it normal that that backport should be marked as uploaded by me?
[13:11] <ogra> Keybuk, https://launchpad.net/ubuntu/hardy/+source/libflashsupport/1.9-0ubuntu1
[13:12] <Keybuk> jpatrick: if you requested it, yes
[13:12] <jpatrick> Keybuk: I did not. Nor have I ever touched pulseadio
[13:12] <jpatrick> pulseaudio*
[13:13] <seb128> did you approve the request?
[13:13] <jpatrick> No
[13:13] <seb128> what upload do you speak about?
[13:13] <jpatrick>  pulseaudio 0.9.6-1ubuntu2~feisty1
[13:14] <seb128> no idea about this one, when did you get a mail about the upload?
[13:15] <cjwatson> sounds like somebody made a mistake when doing the backport
[13:15] <cjwatson> it's a manual process ...
[13:15] <dholbach> can somebody give me a debian policy reference to why things like        #!/usr/bin/env python          are discouraged?
[13:15] <jpatrick> yes, I did get a mail about it
[13:16] <dholbach> we're just discussing it in #ubuntu-classroom (MOTU Q&A session)
[13:16] <dholbach> http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html  comes close to the topic
[13:17] <seb128> dholbach: the page seems to have all the required informations
[13:18] <dholbach> ok... so do you know of a "standard list of interpreters"?
[13:18] <persia> seb128: What about non-python use of env?  Is there a general policy, or is it interpreter-specific for python?
[13:19] <seb128> persia: similar situation I would say
[13:19] <persia> seb128: makes sense.  Thanks.
[13:19] <seb128> when using env you are not sure the system version of the interpreter is used
[13:20] <seb128> you are welcome
[13:21] <ogra> ogra@ceron:~/devel/livecd-rootfs/trunk$ grep sanitize livecd.sh
[13:21] <ogra>     I)	UINUM=$(sanitize int "$OPTARG");;
[13:21] <ogra>     m)	OPTMIRROR=$(sanitize url "$OPTARG");;
[13:21] <ogra>     S)	USZ=$(sanitize int "$OPTARG");;
[13:21] <ogra> does anyone have a clue what sanitize is ?
[13:22] <ogra> its no internal function in the script and not sourced anywhere
[13:22] <ogra> (so using -m breaks)
[13:32] <Chipzz> seb128: I'ld say that page does not have all the required information
[13:33] <Chipzz> dholbach: using /usr/bin/env has a big drawback as opposed to just specifying the path (which IMHO you should)
[13:33] <dholbach> Chipzz: thanks we clarified it in the meantime
[13:33] <Chipzz> dholbach: using /usr/bin/env makes it impossible to specify command-line arguments or switches to python (or perl) for example
[13:34] <Chipzz> dholbach: I was not finnished yet ;)
[13:34] <Chipzz> now I am ;)
[13:35] <Robot101> so are there metacity bling packages yet? :)
[13:35] <dholbach> thanks Chipzz
[13:36] <seb128> Robot101: they are called compiz ;-)
[13:37] <Chipzz> dholbach: a simple example in the perl case is #!/usr/bin/perl -w (although you can also do that with use warnings)
[13:37] <seb128> Robot101: otherwise the new version is not uploaded yet but will be likely today
[13:38] <seb128> I'm working on glib and gvfs now though
[13:39] <^sa^> hello. i have some problems about the configuration of my wifi
[13:39] <Chipzz> persia: ^^^ in case your interested (and non-python use of env should be discouraged IMHO)
[13:39] <^sa^> (first of all sorry for my bad english :P i'm italian)
[13:39] <Chipzz> s/your/you're/
[13:39] <Robot101> seb128: I want a window manager, not compiz. :P
[13:40] <persia> Chipzz: Yes.  I saw it.  I'm not a fan of env, more curious about things like #!/usr/bin/make in a script in /usr/bin/
[13:40] <^sa^> the problem is that my wlan works perfectly on the live cd but not on the installed ubuntu
[13:40] <Chipzz> persia: make requires -f :)
[13:40] <jdstrand> ^sa^: no problems with your english, but this is not the right channel.  you'll get more help on #ubuntu
[13:41] <Chipzz> persia: so far make it's impossible to use env in the first place :)
[13:41] <Chipzz> s/far/for/
[13:41] <^sa^> i've gone in ubuntu-it and they couldn't help
[13:41] <^sa^> we tryed almost everything
[13:41] <^sa^> so i supposed it's a bug and i come here to report it
[13:42] <jdstrand> ^sa^: https://bugs.launchpad.net/
[13:42] <cjwatson> ogra: introduced in r29; ask lamont what he was thinking? :)
[13:42] <^sa^> or maybe you have a soluction
[13:42] <^sa^> what can i do?
[13:42] <Chipzz> ^sa^: although this is not a bug report channel, you could ping asac; he may be able to help?
[13:42] <Chipzz> (hopes he won't get asac's wrath over him now :P)
[13:43] <^sa^> ok but i dont know what to write. can't you help me?
[13:43] <Chipzz> no I cannot ;P
[13:43] <^sa^> what should i post in the website?
[13:43] <Chipzz> I'm not an expert wrt wireless drivers
[13:43] <cjwatson> Chipzz: he's on holiday
[13:43] <jdstrand> me either :(
[13:44] <Chipzz> cjwatson: ah, I wanted to ask you about something :)
[13:44] <lamont> cjwatson: context?
[13:44] <lamont> ah.  livecd
[13:45] <Chipzz> cjwatson: wrt to the bug about ubiquity window being to big to fit on small screens (since you're mentoring that bug); what do you think about the recent GTK+ patches wrt natural size as a solution to that bug?
[13:45] <jdstrand> ^sa^: you may find some answers in the link I gave.  If not, report the bug.
[13:45]  * persia is suspicious of "Natural size", having a 200DPI display on one device.
[13:45] <cjwatson> Chipzz: that should go to evand nowadays. It may help, certainly, but I haven't looked at them in any detail; the timezone page will still need to be shrunk I expect
[13:46] <cjwatson> persia: I don't think that's what it means ...?
[13:46] <cjwatson> it's about pixel-level sizing of widgets, not much to do with DPI
[13:46] <Chipzz> persia: it's about widgets not taking up the maximum space they could possess
[13:47] <persia> cjwatson: Ah.  I misunderstood "natural" then.  I feared real-world measurement, which is annoying for handhelds.  Thanks for the clarification.
[13:49] <lamont> cjwatson: no clue on sanitize.
[13:50] <Chipzz> persia: the relevant discussion is at http://mail.gnome.org/archives/gtk-devel-list/2007-November/msg00145.html in case you're interested
[13:51] <persia> Chipzz: Thanks.  That's much clearer than the API docs I was reading :)
[13:51] <Chipzz> cjwatson: anyway, you may want to add a comment on that bug (https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/38442) in case you're not mentoring it anymore? ;)
[13:51] <ubotu> Launchpad bug 38442 in ubiquity "Ubiquity dialogues too large for 800x600 display" [High,Confirmed]
[13:53] <Chipzz> cjwatson: anyway, I added a comment to the bug with a link to the relevant discussion on gtk-devel ;)
[13:54] <Chipzz> (that's a lot of anyways :P)
[14:09] <ion_> The newest fontconfig seems to have a problem with lcdfilter being set as legacy in config.
[14:10] <ion_> Ah, the syntax has changed to lcd_filter=lcdfilterlegacy.
[14:17] <Ubulette> ion_, yes, you need the new libcairo to go with it
[14:19] <seb128> ion_: do you get any error on ugprade or something?
[14:21] <ion_> seb128: Yes, about a config file i created.
[14:22] <seb128> ion_: does that break the update?
[14:22] <ion_> seb128: Nope, they were just warnings.
[14:23] <seb128> ok, so that's alright
[14:23] <ion_> Whatever updated fontconfig caches was printing them.
[14:23] <ion_> Yeah
[14:25] <geser> pitti: please give-back: sleepd wmbattery python-xlib qbankmanager pnscan pmx pica ounit mrwtoppm. Thanks
[14:36] <Mithrandir> soren: db4.4 for apache> svn?
[14:36] <soren> Mithrandir: Yes, thom filled in the blanks.
[14:36] <soren> Mithrandir: Thanks, though.
[14:38] <slytherin> pitti: ping
[14:43] <seb128> slytherin: you should give some context so maybe somebody else can reply
[14:44] <slytherin> As just asked the question on MOTU channel. It has more do to with moving a -doc package from multiverse to universe.
[14:52] <tkamppeter> Anyone can help me on a problem with a a package which we auto-sync from Debian?
[14:52] <persia> tkamppeter: Which package?
[14:52] <tkamppeter> It is about bug 177359, python-cups
[14:52] <ubotu> Launchpad bug 177359 in python-cups "python-cups needs update (system-config-printer.py crashed with SIGSEGV in PyObject_Malloc())" [Medium,Triaged] https://launchpad.net/bugs/177359
[14:53] <tkamppeter> Tim Waugh, upstream author of python-cups and system-config-printer has fixed this bug upstream in python-cups.
[14:55] <persia> tkamppeter: Three choices: 1) backport the changes (likely wasted effort). 2) Work with debian for an update, and request a sync (freeze exception).  3) update the package directly, and make sure Debian uses the same orig.tar.gz.
[14:55] <persia> tkamppeter: Depending on your relationship with the Debian maintainer, one of 2) or 3) is likely easiest.
[15:00] <tkamppeter> persia thanks, Otavio Salvador has offered me collaboration on system-config-printer (git write access at alioth). So I will option 3 and I think he will overtake it (is a straight upstream update, no patches, no changes in debian/).
[15:00] <persia> tkamppeter: Excellent :)
[15:02] <tkamppeter> persia, package is already build, was trivial
[15:02]  * persia blesses upstreams that prepare releases for painless updates
[15:03] <tkamppeter> Haver pitti and doko already left for Christmas?
[15:04] <pitti> re
[15:04] <pitti> was at a phone call
[15:04] <pitti> give me some more minutes to write down my brain status, then I'll catchup
[15:05] <pitti> geser: done
[15:05] <tkamppeter> hi pitt, can you upload some packages into main for me today? python-cups and system-config-printer?
[15:05] <pitti> hm, slytherin left already
[15:05] <pitti> tkamppeter: can you please mail me the URL? I'll try to make it (sorry, still 100 things to get done)
[15:06] <tkamppeter> pitti, I will do so.
[15:06] <persia> pitti: slytherin is investigating, and filed a bug about the multiverse -> universe bit.
[15:14] <tkamppeter_> pitti, python-cups is ready now, biff.
[15:16] <seb128> pitti: did you do something to esd?
[15:25] <pitti> persia: ok, thanks
[15:26] <pitti> seb128: define something? (no, not recently, except for demoting it)
[15:27] <seb128> pitti: I was trying to pbuild the new rhythmbox but libgnome is not installable because it depends on libesd0 or libesd0-alsa which are not available
[15:27] <seb128> pitti: you demoted those then, which explains the issue
[15:27] <pochu> seb128: rhythmbox is mine! :P
[15:27] <pochu> seb128: are you doing it?
[15:27] <pitti> argh, I meant to demote the esound *binary*
[15:27] <seb128> pochu: already uploaded
[15:28] <seb128> pochu: sorry
[15:28] <pochu> heh
[15:28] <pitti> seb128: sorry, fixing
[15:28] <pochu> seb128: no worries, I didn't start it yet ;)
[15:28] <pitti> done
[15:28] <seb128> pitti: danke
[15:29] <seb128> pochu: usually I would have updated the wiki but I wanted that to be done before my holidays
[15:30] <pochu> seb128: do you start them today?
[15:33] <seb128> pochu: yes, after work
[15:34] <seb128> pochu: I expect I'll still be reading mails etc during holidays though
[15:34] <pochu> Merry Christmas then ;-)
[15:38] <geser> pitti: could you also move commons-httpclient from multiverse to universe (a new task in bug #176139) (one binary is already in universe)
[15:39] <seb128> pochu: thanks, to you too ;-)
[15:40] <pitti> geser: done
[15:43] <tkamppeter_> pitti. system-config-printer is now prepared for a crash-free Christmas (4 crashers fixed + 1 in python-cups), see your mail.
[15:43] <pitti> cool :)
[15:43] <pitti> so people can print out all their greeting cards and present labels :)
[15:44] <tkamppeter> Yes, and they can set up their printers which they get as present (at least if the person who has given the present has read OpenPrinting's Christmas list before).
[15:55] <pitti> if they are using hardy anyway
[15:55] <pitti> oh, gone again already
[15:56] <keescook> mjg59: congratz on the phd submission.  :)
[15:56] <mjg59> Thanks!
[16:08] <bigon> is that normal that libc6-amd64 package in installed on my 32bit system?
[16:12] <geser> bigon: I've seen it in my i386 installations too
[16:13] <pitti> bigon: no, that's a bug
[16:13] <bigon> ok
[16:23] <pitti> keescook: do you happen to have an opinion about http://launchpadlibrarian.net/10983343/php5_5.2.3-1ubuntu6.3.dsc.diff ?
[16:23] <pitti> keescook: that's a proposed SRU for php in gutsy, to switch from db4.5 to db4.4
[16:24] <pitti> keescook: that would be in sync with libsvn1 (also 4.4 in gutsy), but I'm a bit nervous about doing that to a stable release
[16:26] <pitti> well, it was always *meant* to link against 4.4 at least
[16:43] <keescook> pitti: well, I've seen a number of db4 issues in php5 that I haven't figured out yet
[16:43] <keescook> pitti: if that solves the crashes that I can't reproduce, then I'm all for it.  ;)
[16:45] <keescook> pitti: I have concerns over php applications that used db4.5  (mediawiki?) but again, I haven't been able to reproduce the issues (173817)
[16:46] <pitti> keescook: sounds like another damned if you do/damned if you don't issue
[16:46] <pitti> (and just reinforces my desire to get rid of the duplication in hardy)
[16:51]  * keescook nods
[17:44] <seb128> pitti: could you give a retry to rhythmbox on all arches? It failed due to the esound to universe
[17:46] <pitti> seb128: done
[17:46] <seb128> pitti: danke
[18:02] <seb128> pitti: rhythmbox failed again the same way, are you sure you promoted libesd*?
[18:02] <pitti> yes, I am
[18:02] <seb128> hum
[18:02] <pitti> the second time I was sure that I used the right commands
[18:03] <pitti> libesd0-dev | 0.2.38-0ubuntu4 |         hardy | amd64, hppa, i386, ia64, lpia, powerpc, sparc
[18:03] <seb128> how long ago was that?
[18:03] <pitti> hm, esound is back in main
[18:03] <pitti> WTH?
[18:03] <pitti> seb128: publisher finished about 10 minutes ago
[18:03]  * pitti gives back again
[18:03] <seb128> ah ok
[18:03] <seb128> thanks
[18:03] <seb128> I though that was some hours ago already
[18:04] <pitti> so, if they all land in universe again now, we have a soyuz bug
[18:04] <pitti> I could have attributed the first failure to my wrecked brain today, but not the second one
[18:13] <dholbach> Merry Christmas and all the best in 2008 to everybody! See you soon again!
[18:13] <pochu> Take care dholbach
[18:13] <dholbach> pochu: you too
[18:16] <jcastro> dholbach: have a good one!
[18:16] <dholbach> jcastro: you too
[18:39] <pitti> warp10: sent you a review of tennix
[18:40] <warp10> Pitti: just got it. Thank you!
[19:24] <shaya> wondering if anyone is working on integrating new fglrx drivers into lrm, impt as they now work on firegl cards (think thinkpads)
[19:30] <sladen> shaya: look at the change logs of the relevant package and find out who has worked on it recently
[19:30] <sladen> shaya: then you can ask them directly
[19:31] <shaya> BenC: you here? :)
[19:31] <BenC> shaya: hardy has latest ati drivers, IIRC
[19:34] <shaya> new ones came out yesterday
[19:34] <shaya> latest package is 12/19
[19:35] <shaya> http://ati.amd.com/support/drivers/linux/linux-firegl.html
[19:38] <BenC> shaya: will be after new year most likely
[19:38] <shaya> ok
[23:09] <TheMuso> slangasek: Thanks a bunch for 1) making ubuntustudio alpha images, and 2) announcing them in the main alpha 2 announcement.
[23:12] <slangasek> TheMuso: my pleasure; unfortunately I don't believe we got any ISO tests of them prior to release, which makes me nervous.  going forward, aside from getting images into a testable state farther in advance, what's the best way to tap you guys about getting them tested before release?
[23:13] <slangasek> TheMuso: (also: would you care to test them now to confirm that it really boots? :/)
[23:13] <TheMuso> slangasek: Well there are a few of us who are testing the dailies regularly, and I've been making sure our seeds are up to date, and we have no uninstallable packages leading up to alpha2, so if the installer gets tested elsewhere, and same with GNOME, that covers us for the most part.
[23:14] <TheMuso> slangasek: I don't have long till I have to get ready to head out, but I'll sync and see if they do boot and install, but I'm reasonably confident that they will be ok.
[23:14] <TheMuso> We are trying to get more community help for testing, but some people in our dev group haven't really bene pulling their weight.
[23:15] <slangasek> TheMuso: right, sounds good
[23:16] <slangasek> TheMuso: in terms of release management and release confidence, if people are testing dailies it would be good to have the results documented on https://iso.qa.stgraber.org; which means it would also be good if I have a designated point of contact that I can notify when candidates are published there
[23:16] <TheMuso> slangasek: And as it is, -rt didn't land for alpha 2 for us, so kernel wise, theres nothing to test, but once -rt lands for later alphas, then we really need to be sure we get good testing, particularly with apps that need such a kernel.
[23:16] <slangasek> sure
[23:16] <TheMuso> slangasek: Right.
[23:16] <TheMuso> -rt as in for 2.6.24
[23:16] <slangasek> yes
[23:17] <slangasek> I know -rt, it caused us some problems during the milestone prep :)
[23:17] <TheMuso> I saw that.
[23:18] <TheMuso> slangasek: As it seems you and I tend to be around at similar times, I am happy to be pinged aobut candidate images in the future. Even if I'm not around, I am idling on IRC< so will get the ping, and test at my earliest convenience.
[23:18] <slangasek> ok
[23:19] <TheMuso> I try at least once a day to check the state of our images, usually right after the latest gets built.
[23:19] <slangasek> right - in the case of a milestone, the time when it gets built becomes variable :-)
[23:19] <TheMuso> I am aware of that.
[23:20] <TheMuso> So around alpha times, I do tend to check more often where possible.
[23:20]  * slangasek nods
[23:30]  * TheMuso kicks off a test install of ubuntustudio, and goes to get ready.
[23:45] <tjaalton> slangasek: hmm, bug 173008 (mentioned on the relnotes) should be fixed now
[23:45] <ubotu> Launchpad bug 173008 in xorg "keyboard selection (dvorak) not preserved after install in hardy" [Medium,Confirmed] https://launchpad.net/bugs/173008
[23:46] <tjaalton> sorry for not closing it in time