[12:16] <ritvik> I hibernated the system .... after resume my usb keyboard was working but usb mouse was got stuck any idea what logs should I include while filing this bug? 
[01:49] <jsgotangco> good morning
[01:50] <Burgwork> jsgotangco, what is the addy for the fridge people?
[01:51] <jsgotangco> i dunno they have a private list though
[01:51] <jsgotangco> fridge-devel?
[03:01] <mdz> jsgotangco: yes, that's the one
[03:16] <jdub> mdz: would you be comfortable with pulseaudio being setuid (so it can grab realtime priority)?
[03:16] <jdub> mdz: or would you want to attack that a different way?
[03:17] <jdub> mdz: noting that it drops all privs (apart from the realtime capability) on startup... but can also be network-visible
[03:17] <mdz> jdub: if it drops privileges immediately, it shouldn't be a problem
[03:18] <jdub> see #11 in the faq here: http://pulseaudio.org/wiki/Documentation#FrequentlyAskedQuestions
[03:22] <wasabi> What's the current plan with all that stuff, seeing as alsa has dmix now?
[03:22] <Lathiat> i thought dmix had been around for a long time, and was generally kindof working but often broke?
[03:23] <jdub> there are plenty of interesting problems that dmix doesn't solve
[03:23] <jdub> so it's nice that it's there
[03:23] <jdub> but ultimately it is poo
[03:23] <wasabi> caching sound bytes, etc?
[03:23] <jdub> *cough*
[03:23] <jdub> source volume mixing, caching, smart mixing, desktop integration, etc., etc.
[03:24] <wasabi> True. Wondering what the plan is for Pulse AND Alsa/OSS at the same time though.
[03:24] <wasabi> Pulse doesn't seem to fix that on it's own. Looks like it's super smarter about closing devices though.
[03:24] <jdub> directly in ubuntu, no plan
[03:24] <wasabi> Unless you send alsa through pulse... that sounds kinda iffy though
[03:25] <jdub> in general in the desktop community, that is being worked on (and includes pulse in the recipe)
[03:25] <jdub> alsa -> pulse and fus[ed]  for /dev/dsp
[03:26] <wasabi> Is Pulse able to take advantage of hw mixing support if available?
[03:28] <Hobbsee> morning all
[03:33] <Lathiat> crazy, you can have multiple senders and receivers multicasting with this RTP stuff
[03:33] <Lathiat> thats pretty nuts
[03:34] <_ion> Huh? Isn't that pretty much the point of multicasting?
[03:34] <Lathiat> _ion: yeh but with audio :)
[03:34] <Lathiat> and you can combine two stereo sound cards into a virtual surround.. heh
[03:35] <_ion> They will run out of sync eventually.
[03:35] <Lathiat> "Please keep in mind that PulseAudio will constantly adjust the sample rate to compensate for the deviating quartzes of the sound devices. This is not perfect, however. Deviations in a range of 1/44100s (or 1/48000s depending on the sampling frequency) can not be compensated. The human ear will decode these deviations as minor movements (less than 1cm) of the positions of the sound sources you hear."
[03:59] <rodarvus> sladen: ping
[03:59] <rodarvus> I'm merging our X drivers to their Debian counterparts
[04:00] <rodarvus> I noticed you created a half dozen patches for xserver-xorg-driver-i810
[04:01] <rodarvus> but these patches do not apply cleanly to the new version (1.5.1.0)
[04:01] <sladen> rodarvus: most of those are pulls from upstream CVS, they /should/ all be in new upstream pulled via Debian
[04:01] <rodarvus> oh, thats nice
[04:02] <sladen> rodarvus: if any of the issues are still around later in the release cycle I'll approach them again
[04:02] <rodarvus> sladen: I propose we sync from Debian (1.5.1.0) and from there, we can apply patches that are still relevant, if any
[04:03] <sladen> rodarvus: yes, I'd prefer a straight sync, stabilise that and work from there
[04:03] <rodarvus> sladen: nice! thanks a lot!
[04:03] <sladen> rodarvus: if any of our patches haven't gone back to xorg, we've screwed up
[04:03] <rodarvus> :)
[04:04] <sladen> rodarvus: how are you coping with cleaning up the mess left by the package renaming?
[04:05] <rodarvus> sladen: adding Conflicts/Replaces to each of our previous drivers, syncing when possible, merging otherwise
[04:06] <rodarvus> after we are done syncing/merging the drivers, its just a matter of updating xorg to ship xserver-xorg-video-all, instead of xserver-xorg-driver-all
[04:06] <rodarvus> sladen: almost there, btw - I've done 39 drivers today, only two missing (i810 included)
[04:07] <rodarvus> (most of them were almost-sync cases, though)
[04:07] <sladen> rodarvus: oooh, excellent.  
[04:10] <rodarvus> mdz: ping
[04:13] <mdz> rodarvus: pong
[04:14] <rodarvus> mdz: are you able to reject two packages in NEW for me?
[04:14] <mdz> rodarvus: sure
[04:15] <rodarvus> I uploaded xserver-xorg-video-mga and xserver-xorg-video-rendition to NEW, with stripped source code (this code was stripped from Debian version but not from ours)
[04:16] <rodarvus> mdz: thanks
[04:17] <rodarvus> binary blobs which are not dfsg compliant but which we can distribute
[04:50] <Eleaf> hmmmmm
[05:33] <bluefoxicy> agh
[05:35] <bluefoxicy> If anyone cares, I am trying to convince the GCC devs that it is useful to pass function and file to the stack smash protection catch functions so that distro-side we can nab the data as soon as the bug is first triggered and patch the bug as early as possible
[05:36] <bluefoxicy> they do not believe that this is useful, apparently either A) the end user should debug it with a debugger (NOT GOING TO HAPPEN); or B) the developer should debug it with a debugger (IF HE CAN REPRODUCE THE PROBLEM)
[05:37] <bluefoxicy> I am fairly certain there are times when bugs actually get triggered very rarely and are hard to reproduce, so I think we need to be able to opportunisticly collect this data.  How that code gets used is up to distro patching (you could patch libssp0 to log to syslog() for example and then have a daemon watch syslog() and ask the user to send a report back to Ubuntu)
[05:37] <bluefoxicy> anyway.
[05:38] <bluefoxicy> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328 and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28334 (I am more interested in 28328; we can easily do 28334 distro-side but doing 28328 distro side causes BREAKAGE AND INCOMPATIBILITY)
[05:38] <Ubugtu> gcc.gnu.org bug 28328 in other "Stack smash protection non-verbose" [Normal,Unconfirmed]  
[05:38] <bluefoxicy> If anyone is interested.
[07:54] <jsgotangco> \o/
[07:59] <Burgundavia> Seveas: ping
[09:10] <Mithrandir> infinity: (re syck), yes, -O0 makes the testsuite not fail, iirc.  It's the wrong fix, but the code is messy and I don't really care enough to fix the test suite properly.
[09:25] <pitti> Good morning
[09:25] <Kagou> hi
[09:51] <sivang> Good morning
[09:51] <pitti> hi sivang 
[09:52] <sivang> hey pitti , what's up?
[09:54] <freeflying|away> pitti: hi
[09:55] <pitti> hi freeflying|away 
[09:56] <pitti> sivang: yesterday, my first crash report saw the light of the day (or, rather, the space of /var/crash/ :) )
[09:57] <freeflying> pitti: would you mind review a package, it's in main, I do some improvement for it(scim-chewing)
[09:57] <sivang> pitti: heh
[09:59] <sivang> pitti: was it related to SSP on PPC ? :-)
[10:00] <pitti> freeflying: sure, if you send me a debdiff, I can upload it
[10:00] <pitti> sivang: no, just some test crashes to try my new crash-reporter agent
[10:00] <freeflying> pitti: thx, I'd send you soon
[10:00] <pitti> freeflying: I can't judge the functionality, though, I trust you for that :)
[10:02] <sivang> pitti: oh nice, have you uploaded it already so it can be tested?
[10:03] <sivang> pitti: how do you know when a crash has happened also ?
[10:05] <pitti> sivang: no, not yet; it's in bzr if you want to play with it
[10:05] <pitti> sivang: but I still need to add packaging bits so that it works OOTB
[10:05] <pitti> sivang: pure magic :)
[10:09] <pitti> dholbach!
[10:09] <pitti> dholbach: Guten Morgen
[10:09] <dholbach> heyy pitti, good morning everybody
[10:09] <jsgotangco> hello
[10:09] <dholbach> heya jsgotangco
[10:17] <sivang> pitti: :-)
[10:17] <sivang> dholbach: !
[10:17] <sivang> yo jsgotangco 
[10:17] <dholbach> hey sivang
[10:17] <jsgotangco> sivang: hi!
[10:18] <\sh> moins
[10:19] <pitti> hi \sh 
[10:29] <seb128> dholbach: do you know if janimo knows he's supposed to do syncs with Debian for xfce too?
[10:30] <dholbach> seb128: i suppose so, he's on a trip atm - gloubiboulga knows more (and might want to do some of the syncs)
[10:30] <seb128> dholbach: I'm asking because he's doing uploads to edgy atm and those have no sync mention
[10:31] <dholbach> seb128: gloubiboulga, right?
[10:31] <seb128> no
[10:31] <seb128> Changed-By: Jani Monoses <jani@ubuntu.com>
[10:31] <dholbach> hu?
[10:31] <seb128> cf edgy-changes list
[10:31] <dholbach> hum
[10:36] <Seveas> Burgwork, pong
[10:41] <freeflying> pitti: it's not decided by I only, I have talked this with other guys in ubuntu-cn
[10:49] <pitti> hi doko
[10:58] <doko> pitti moin
[11:01] <dholbach> ogra: how is gnome-power-manager coming along?
[11:04] <freeflying> pitti: sent debdiff to you
[11:04] <dholbach> ogra: and yet another gnome-screensaver! :-)
[11:28] <Mithrandir> ogra: are you going to release knot-1 too soonish? 
[11:28] <Mithrandir> Riddell: are you going to release knot-1 too soonish? 
[11:32] <ogra> Mithrandir, end of the week was the planned date, no ?
[11:34] <Mithrandir> ogra: it is, but that means looking at http://people.ubuntu.com/~cjwatson/testing/edgy_probs.html is becoming a better idea by the hour.
[11:35] <ogra> Mithrandir, fixing the seeds is on my list for this week... i *only* have the g-p-m megre to finish  :)
[11:35] <dholbach> ogra: you want to do the gnome-screensaver update?
[11:36] <dholbach> oh
[11:36] <dholbach> seems we didn't do that merge either
[11:36] <ogra> dholbach, how should we merge that :) debian is behind in versions
[11:37] <ogra> i carried the patches over that were not applied upstream yet
[11:37] <dholbach> hu?
[11:37] <dholbach> should be no trouble to merge it, no?
[11:37] <ogra> we have g-s-s 2.15
[11:37] <seb128> ogra: like we did for everything GNOMEish?
[11:37] <ogra> they still have 2.14
[11:37] <seb128> and?
[11:37] <seb128> get their package
[11:38] <seb128> and update to 2.15 from it
[11:38] <ogra> and i merged the patches into 2.15
[11:38] <ogra> additionally i sent most of them upstream (modulo the gconf changes he didnt want)
[11:38] <seb128> job easier for you if everything is upstream
[11:38] <seb128> take the Debian package
[11:38] <seb128> run dch
[11:38] <ogra> so i hope one of the newt version will carry them upstream
[11:38] <seb128> write your changelog
[11:38] <seb128> upload
[11:39] <ogra> we never had a package that was even near the debian one 
[11:39] <seb128> if there is some Ubuntu changes required use them
[11:39] <seb128> that's why we do merges from Debian
[11:39] <seb128> to get packages nearer of them
[11:39] <ogra> we shipped g-s-s one release ahead of them and they packaged it completely differently
[11:39] <seb128> and?
[11:39] <seb128> it there any interest to keep a different packaging?
[11:40] <ogra> since that wont change i we'll have to merge it anyway
[11:40] <seb128> so why do you discuss it?
[11:40] <ogra> i dont see the advantage ...
[11:40] <seb128> I can merge it if you want ...
[11:40] <seb128> I know how to do :p
[11:40] <ogra> i have to merge it *every* release and have to look at their packaging anyway
[11:41] <seb128> why every release?
[11:41] <ogra> so why should we not keep the packaging we have
[11:41] <seb128> I don't get your question
[11:41] <ogra> because we'll be ahead one version in every release
[11:41] <seb128> we try to be near of Debian, i.e: base the packages on Debian when we can
[11:41] <seb128> grumpf
[11:41] <dholbach> anyway we can take good packaging changes, that's not a matter of a version number
[11:41] <ogra> so it doesnt really matter since its every time a manual merge
[11:41] <seb128> let me make it clear for you
[11:41] <seb128> - take the debian package
[11:41] <seb128> - apply the ubuntu changes to it
[11:41] <seb128> - update the package for 2.15
[11:42] <seb128> then you have a 2.15 package merged from Debian
[11:42] <ogra> *sigh* thats so pointless
[11:42] <seb128> and you can update than one when the new version come
[11:42] <seb128> you can argue than merges have not useful
[11:42] <ogra> i have to merge it manually *anyway* 
[11:42] <ogra> whats the point here ? 
[11:42] <seb128> but we decided to merge on Debian
[11:43] <seb128> enough discussion with you, feel free to do whatever you want, if you think your packages should not be merged with Debian that's up to you
[11:44] <dholbach> the point is that we want to stay close to debian and if you're concerned about too much upstream changes, you can run a diff on the debian/ dirs only
[11:44] <ogra> dholbach, my point is that we cant stay close to debian with packages we package a version ahead
[11:45] <Mithrandir> ogra: yes, we can.  The packaging shouldn't be much different.
[11:45] <Mithrandir> it's just a different orig.tar.gz
[11:45] <ogra> especially with packages that are known to be like that *every* new release
[11:45] <dholbach> ogra: we did that for *all* gnome packages
[11:45] <ogra> so why wasnt g-s-s and g-p-m packaged in debian first then ? 
[11:45] <Mithrandir> ogra: that's irrelevant.  Now that they are, they should be merged.
[11:46] <Kamion> ogra: seb128 is kind of an expert in packages that are packaged a version ahead, you know
[11:46] <ogra> i dont think it matters and i'm not really after merging packages with debhelper cdbs mixes and the like
[11:46] <Kamion> ogra: so maybe you shouldn't discount stuff he's saying about that
[11:46] <ogra> yes, i'll merge them *sigh* !
[11:47] <dholbach> ogra: seb128 and I can think of more enjoyable tasks as well :)
[11:47] <Mithrandir> dholbach,seb128 : I realise you guys are insanely busy, as always, but if you'd have any chance of clearing any of your stuff out of http://people.ubuntu.com/~cjwatson/testing/edgy_probs.html , I'd be very, very happy.
[11:47] <ogra> dholbach, i just dont like the extra work for packages that mostly live from our patches
[11:48] <seb128> Mithrandir: if people could process NEW it would really help
[11:48] <dholbach> Mithrandir: gnome 2.15.4 release is just in progress -- ~25 tarballs ahead
[11:48] <seb128> Mithrandir: stuff like new n-c-b blocking python-gnome-desktop breaks a stack of packages for GNOME
[11:48] <Kamion> seb128: I'm working on it
[11:48] <seb128> thank you
[11:49] <Mithrandir> dholbach: ok, coolie.  I hope that'll clear up a bit, then.
[11:49] <seb128> Mithrandir: I'll work on clearing that this afternoon, I'm almost done with my 2.15.4 packages list
[11:49] <Kamion> archive admin is unpleasantly close to a full-time job ATM
[11:49] <Mithrandir> seb128: excellent, thanks.
[11:49] <seb128> np
[11:51] <Kamion> nautilus-cd-burner needs a give-back on !i386 though
[11:51] <Kamion> or something
[11:51] <Kamion> I've accepted it on i386 but that will only buy you so much
[11:52] <Kamion> (and it'll hit NEW again on the other architectures due to an annoying quirk of soyux)
[11:52] <Kamion> soyuz
[11:53] <Zdra> will gnome-mount be integrated in edgy ? I want to test some of my nautilus patch and it's easier if gnome-mount is packaged in edgy :p
[11:53] <pitti> Zdra: I doubt it
[11:54] <pitti> Zdra: it's quite useless in its current state
[11:54] <pitti> Zdra: and it requires cvs head hal, which is quite crackful ATM
[11:54] <Zdra> pitti: ok didn't know that it's experimental :)
[11:55] <Zdra> will try compiling it myself so
[11:56] <Mithrandir> \sh: you broke intlfonts.
[11:56] <Mithrandir> \sh: as in, it calls update-fonts-dir with unsupported arguments.
[11:57] <\sh> Mithrandir: then I have to fix it somehow...
[11:58] <Mithrandir> \sh: make it depend on a version of xfont-utils that actually have --x11r7-layout
[11:59] <\sh> Mithrandir: lemme check
[12:00] <seb128> Kamion: ok, I'll have look on that, thank you
[12:00] <StevenK> Mithrandir: Surely xfonts-utils?
[12:01] <Mithrandir> StevenK: yes, typo.
[12:01] <Kamion> \sh: (I recommend leaving it alone until xfonts-utils is merged, so that you can actually test it)
[12:03] <\sh> Kamion: kk
[12:09] <Mithrandir> doko: ooo is utterly uninstallable on amd64 and sparc.  Care to investigate?
[12:10] <Riddell> Mithrandir: yes, I'd like to release Knot 1. I've not tested any CDs yet and I'd like to have all of KDE 3.5.3 compiled first but it should be doable
[12:10] <Mithrandir> Riddell: half the distro is in pieces, so it's not just you who might have problems releasing on time, though. :-P
[12:11] <Riddell> I can imagine
[12:12] <doko> Mithrandir: a library pulled away?
[12:14] <Mithrandir> doko: ooo-common (2.0.2) depends -core >> 2.0.2, maybe that should be >= ?
[12:15] <pitti> Mithrandir: but 2.0.2-2ubuntu12-1 >> 2.0.2
[12:15] <tseng> shuold all these new python packages have Replaces: and cleanly upgrade?
[12:15] <Mithrandir> pitti: hm, true dat.
[12:15] <tseng> instead of being held back
[12:15] <Mithrandir> pitti: I wonder why it blows up
[12:18] <Kamion> anyone care to help with a mysterious SSP explosion?
[12:18] <dholbach> can somebody give back librsvg on amd64?
[12:19] <tseng> Kamion: it isnt in libgcc is it?
[12:19] <pitti> Kamion: in libgcc?
[12:19] <Mithrandir> doko: oh, it's libc-i386 conflicting with ia32-libs << 1.5 and we have 1.4ubuntu19.
[12:19] <Kamion> actually, no, never mind, valgrind is saying somewhat interesting things too
[12:19] <Kamion> nah, in chpasswd
[12:19] <seb128> dholbach: did GTK 2.10 built?  
[12:19] <seb128> dholbach: because librsvg requires it to build
[12:19] <tseng> moin pitti 
[12:19] <Mithrandir> doko: any chance you could steal that merge from Adam?
[12:19] <pitti> hey tseng
[12:20] <dholbach> seb128: yes, it did, i just did a dist-upgrade which removed 2467924674296426 packages, to check what's going on
[12:20] <dholbach> seb128: with librsvg built we should be a bit better on the track again
[12:20] <seb128> dholbach: like it removed libgnomeui-0 ? :)
[12:20] <dholbach> seb128: then we have a bunch of pygtk apps depending on py2.4-something
[12:20] <dholbach> seb128: no, not that, that built too
[12:20] <seb128> hum
[12:20] <seb128> so it should not remove that many packages then ...
[12:21] <dholbach> maybe it was some less package ;)
[12:21] <seb128> dholbach: python issues are due to gnome-python-desktop waiting on new n-c-b
[12:21] <doko> Mithrandir: and it's gcc-4.1/gcj-4.1 FTBFS ... I love ssp ...
[12:21] <pitti> doko: so maybe we should build gcc-4.1 itself without ssp for now on ppc
[12:22] <pitti> doko: leaving -fs-p enabled on powerpc in the spec file should be fine, TTBOMK it only breaks if gcc itself is built with ssp
[12:24] <tseng> pitti: it is pretty specifically the stack unwinding code in libgcc
[12:24] <pitti> tseng: right
[12:24] <tseng> pitti: which i am guessing fails to properly calculate what part of the stack it is in after adding ssp header/trailer
[12:24] <doko> pitti: yes, figuring out how to do that ;)
[12:24] <tseng> and touchs something it shouldnt
[12:24] <pitti> doko: there are no CFLAGS in the gcc-4.1 source?
[12:25] <Kamion> the problems I'm seeing here seem to be to do with fputs() fetching word-at-a-time from the given string and overflowing buffers by <4 bytes
[12:25] <Mithrandir> doko: oh, joy. :-/
[12:25] <dholbach> can somebody give back devhelp, librsvg on !i386?
[12:26] <Mithrandir> doko: trying not to AWTY; any idea when you'll have it fixed?
[12:26] <Kamion> you need Keybuk or infinity for give-backs
[12:26] <pitti> Kamion: would that be our first bug discovered by ssp then?
[12:26] <doko> Mithrandir: a quick fix would be to just disable ssp on powerpc
[12:27] <pitti> (for gcc-4.1)
[12:27] <Kamion> pitti: shouldn't bugs in fputs() have been discovered before now?
[12:28] <pitti> Kamion: I would expect so...
[12:28] <tseng> alot of people have been using ssp for years, im finding it hard to believe as well
[12:28] <Kamion> I'm not asserting that fputs() is bug-free but it's not my first suspect
[12:28] <Kamion> but at the same time the code looks ok - I'm digging
[12:29] <doko> pitti: the compiler is bootstrapped with itself; so you have to make sure that it defaults to -fstack-protector, the runtime libraries are built using it, but not the compiler itself.
[12:29] <Kamion> ah, maybe valgrind is misleading me here
[12:30] <tseng> doko: the runtime libraries are the trouble
[12:30] <pitti> doko: oh, is libgcc a runtime library?
[12:30] <pitti> doko: maybe it's easier to just enable -fno-stack-protector for libgcc?
[12:30] <pitti> (or all runtime libs)
[12:30] <doko> pitti: yes. hmm, looking at it
[12:31] <slomo> at least for the exception thingie it is only libgcc
[12:31] <tseng> morn slomo 
[12:31] <slomo> hi tseng :)
[12:39] <dholbach> can metacity be given back on !i386 too?
[12:49] <Kamion> interesting, the ssp failure in chpasswd is actually on exit from main() ...
[12:49] <Mithrandir> does it have any atexit handlers or similar registered?
[12:50] <Kamion> good thought, but not that I can see
[12:50] <ogra> dholbach, you didnt want to keep the patched icons in g-p-m iirc ?
[12:51] <dholbach> ogra: i need to double check if the new version does gtk icon theme look up properly
[12:51] <Kamion> aha! got it
[12:51] <dholbach> ogra: safer to keep them in, for the mo
[12:51] <Kamion> a local char[]  was one byte too small
[12:51] <ogra> dholbach, ok, will do ...
[12:51] <dholbach> ogra: merci beaucoup
[12:52] <sivang> hmm, interesting
[12:52] <sivang> Errors were encountered while processing:
[12:52] <sivang>  /var/cache/apt/archives/libscim8c2a_1.4.4-4ubuntu1_i386.deb
[12:52] <sivang> E: Sub-process /usr/bin/dpkg returned an error code (1)
[12:52] <sivang> but hen I did apt-get -f install, and then manually dpkg -i from the cache , it just worked.
[12:53] <sivang> s/hen/when/
[12:53] <slomo> probably missing conflicts
[12:53] <slomo> or replaces
[12:53] <sivang> ah
[12:56] <doko> infinity, Mithrandir, fabbione: gcj-4.1 should be retried on powerpc, sparc, amd64
[12:58] <dholbach> hey Gloubiboulga
[12:59] <Gloubiboulga> hi dholbach, I was /querying you
[12:59] <dholbach> Gloubiboulga: oh? please send again
[12:59] <dholbach> seems i didn't get it
[12:59] <dholbach> Gloubiboulga: you were identified with the network?
[01:00] <Gloubiboulga> dholbach, I am now
[01:04] <slomo> hm, and hal needs a give-back
[01:13] <Riddell> Kamion: do you have enough powers to give back qt4-x11 for recompiling?
[01:14] <Kamion> Riddell: n
[01:15] <Kamion> o
[01:15] <Kamion> Riddell: you need a member of launchpad-buildd-admins
[01:16] <ogra> does pbuilder-satisfydepends take ages for anyone else or is that my edgy over here ?
[01:16] <ogra> (about 1min for every dependency)
[01:16] <Riddell> ogra: doesn't take that long for me
[01:17] <ogra> weird
[01:17] <slomo> ogra: same for me
[01:17] <Riddell> although it's certainly longer than apt-get
[01:17] <ogra> anyone of you using ppc ?
[01:17] <Riddell> nope
[01:17] <dholbach> the new dependency resolver in apt is slower
[01:17] <dholbach> mvo is aware of it
[01:17] <slomo> ogra: it is slow on x86/ppc for me :)
[01:17] <dholbach> it's slower on amd64 too
[01:18] <ogra> slomo, oh, fine then, i'm not feeling so alone anymore :)
[01:18] <pitti> ogra: is it that much better than apt-get build-dep foo?
[01:19] <slomo> ogra: for most of my builds this takes longer than actually building the package ;)
[01:19] <ogra> dholbach, i noticed generl apt slowness, but that pbuilder thing is really extreme :)
[01:21] <ogra> pitti, apt-get build-dep works faster
[01:21] <imbrandon_> ogra, i'm on pcc , need something ?
[01:22] <ogra> imbrandon_, nope, i' on ppc as well :)
[01:22] <ogra> *i'm
[01:22] <imbrandon_> ahh ok
[01:22] <imbrandon_> s/pcc/ppc ;)
[01:56] <Riddell> smurf: are you going to update gnupg2 in debian?  there's a new version out
[01:57] <dholbach> did somebody give back librsvg and devhelp on !i386?
[02:01] <ogra> fun, my system just rebooted out of the blue, half of my HDD content is missing, gnome doesnt work anymore apart from the panels, evo starts an empty window with no widgets ... and my clock is set to 1904
[02:02] <dholbach> ogra: set the date to a proper time and you should be fine again
[02:02] <dholbach> at least gnome should start again fine
[02:03] <ogra> nope
[02:03] <dholbach> hm?
[02:03] <ogra> indeed i set the clock when gdm didnt start 
[02:03] <ogra> which fixed that 
[02:03] <ogra> but i have a ton of bonobo errors
[02:03] <ogra> and it seems half of /usr/bin is missing anyway
[02:04] <dholbach> urg
[02:04] <dholbach> how did you manage to get rid of half of /usr/bin?
[02:04] <ogra> no idea
[02:04] <ogra> the lappie "just rebooted" out of the blue ...
[02:04] <ogra> after the reboot the system was in this condition
[02:04] <dholbach> anything interesting in /var/log/syslog?
[02:05] <ogra> the fun is that it booted fine this morning and i didnt do any upgrades, so there should be any difference 
[02:05] <ogra> nope, already looked
[02:05] <ogra> *shouldnt
[02:05] <ogra> at least my pbuilder seems to work :)
[02:10] <Kamion> 1904 is the Mac epoch; if battery power to the clock fails then it tends to reset to that
[02:11] <ogra> Kamion, but both were ok
[02:11] <ogra> indeed that was the first i checked :)
[02:11] <ogra> (battery is at 100% and power was plugged in)
[02:12] <ogra> i'm not really worried about the timestamp ... my HD worries me ... 
[02:12] <ogra> but apparently all stuff in /home isnt touched
[02:12] <Kamion> battery power to the clock could fail due to a loose connection or something, not necessarily just "out of battery"
[02:12] <ogra> true
[02:34] <ogra> sigh, not even the schema patches apply to the new g-p-m
[02:41] <ogra> grmbl ... pbuilder taking 45mins for the build deps doesnt help either ...
[02:42] <Riddell> pitti: would you be able to do main inclusion review for gnokii and gnupg2 today?  they're blocking large parts of KDE
[02:42] <Hobbsee> ogra: ouch?  why so long?
[02:42] <ogra> Hobbsee, no idea
[02:43] <Hobbsee> ogra: how many MB of updates does it need?  that seems just a bit extreme
[02:43] <ogra> its only the parsing that takes ages ... installing them and setting them up is done in 2 mins
[02:43] <Hobbsee> ah...yeah...i've noticed that
[02:44] <slomo> ogra: build it locally or do pbuilder login and do everything there
[02:44] <ogra> slomo, yes, thats what i will do the next run ... 
[03:00] <ogra> argh
[03:00] <ogra> seb128, dholbach, where is the clealooks engine binary gone ? 
[03:00] <ogra> *clearlooks
[03:01] <seb128> ogra: gtk2-engines-clearlooks package?
[03:01] <seb128> /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so on your disk
[03:01] <ogra> hmm
[03:01] <ogra> i just got a bugreport that its not existent anymore after debian made namechanges
[03:02] <seb128> we are not Debian but Ubuntu :p
[03:02] <ogra> so we'll keep it 
[03:02] <seb128> we didn't did the sync with Debian yet for it because they unsplitted the package
[03:02] <ogra> yeps ...
[03:02] <seb128> not sure if we will keep it splitted, no
[03:03] <ogra> if you consider unsplitting please notify me, because i have to redo parts of ldm then 
[03:03] <seb128> I'll unsplitte this week
[03:04] <seb128> so you are notified
[03:04] <seb128> the new gtk2-engines from today is on the TODO list
[03:04] <seb128> and we will sync with Debian too
[03:04] <ogra> ok
[03:05] <ogra> do we have any slim theme left in a separate package in main ? 
[03:05] <seb128> or do you have a good reason to keep they splitted?
[03:05] <ogra> its smaller
[03:05] <ogra> space is an issue on some thin clients
[03:05] <seb128> that's not like the few themes engines were taking a lot of space
[03:06] <ogra> well, we're talking about 32 to 64MB machines keeping the filesystem in memory :)
[03:06] <ogra> so the less i have in their root the better :)
[03:06] <seb128> right, but we are speaking about something like 200k 
[03:07] <ogra> indeed ...
[03:07] <ogra> but that sums up :)
[03:08] <ogra> just tell me if its done or not ... if its done i have to at least adjust the ldm dependencys
[03:08] <seb128> that's 0.625% of 32M
[03:08] <seb128> I'm not sure that's not worth the extra splitting
[03:08] <ogra> having 10 such packages is 6% already :) 
[03:09] <seb128> which is still not that much
[03:09] <seb128> and you don't have 10 packages changing
[03:09] <seb128> if some k are such an issue just use the stock GTK theme
[03:09] <seb128> install no theme engine at all
[03:09] <ogra> how do you know ? i have the whole of X changing and no idea yet if it grows or shrinks through that 
[03:09] <ogra> so i'm cautious about every byte atm :)
[03:10] <seb128> as said, use no theme engine but stock GTK theme
[03:10] <seb128> it's faster and lighter
[03:10] <ogra> and no, i wont ship a theme in ldm thats based on the default one :)
[03:10] <seb128> so stop complaining
[03:11] <ogra> (or would you ship gdm with the gnome default ?)
[03:11] <seb128> if you really need to space anyway that's easy to make ldm-theme package and include the theme you want to it
[03:11] <seb128> I would be fine shipping the GNOME theme, it's nice :)
[03:12] <ogra> we're talking about what i see if gnome-settings-daemon isnt running ? or is there something else now ?
[03:12] <seb128> gdm theme? I'm speaking about the gdm login screen
[03:13] <seb128> the GTK theme is the greish one but it should be better since GTK 2.8 that it used to be
[03:13] <ogra> i'm speaking about the gtk theme used in there
[03:14] <ogra> the ldm theme itself is just a fullscreen gnomecanvas with some colors
[03:14] <seb128> ah, k
[03:14] <ogra> if python-cairo is ever production ready i'll switch that ... :)
[03:14] <seb128> python-cairo works fine
[03:15] <seb128> and it's in sync with cairo
[03:15] <seb128> what is your issue with it?
[03:15] <ogra> ah, great ...
[03:15] <ogra> it didnt in dapper when i looked 
[03:15] <seb128> it's used by pygtk
[03:15] <ogra> (very early)
[03:15] <seb128> dapper pygtk uses it
[03:15] <seb128> maybe you don't know how to use it? :p
[03:15] <ogra> :P
[03:15] <seb128> pygtk works on dapper or we would have noticed I think :)
[03:16] <ogra> yep
[03:17] <ogra> i or rodarvus (who will implement the ldm changes) will look into it ...
[03:18] <ogra> s/ldm changes/specced ldm changes/
[03:19] <ogra> rodarvus, currently ldm uses a fullscreen gnomecanvas window to theme rendering of that gets quite slow if people add customized themes with fullscreen wallpapers 
[03:19] <ogra> s/theme/theme./
[03:21] <ogra> rodarvus, would be nice to drop canvas in favor of cairo
[03:21] <rodarvus> *nods* you told me that in Paris :)
[03:21] <ogra> oh, right 
[03:21] <ogra> :)
[03:22] <ogra> but its not mandatory for edgy ... its only a nice to have ...
[03:22] <rodarvus> right
[03:22] <ogra> (i doubt we'll have time for such stuff and the current themeing works)
[03:47] <bddebian> Hello
[03:52] <ogra> slomo, does your panel menu work on ppc ? 
[03:53] <slomo> ogra: does it open and close and open and close and so on very fast for you?
[03:53] <ogra> yep
[03:53] <ogra> do you know a workaround ? 
[03:53] <slomo> works fine for me ;)
[03:53] <slomo> but two friends have the same bug on x86 notebooks
[03:54] <ogra> oh, i thought it was ppc specific
[04:24] <Keybuk> rodarvus: ping?
[04:26] <rodarvus> Keybuk: pong
[04:27] <Keybuk> rodarvus: so, I have a whole bunch of X source packages that are "blacklisted" because they appeared in Debian, and hadn't yet appeared in Ubuntu
[04:28] <Keybuk> xbase-clients, xdebconfigurator, xfonts-100dpi, xfonts-75dpi, xfonts-base, xfonts-cyrillic, xfonts-encodings, xfonts-scalable, xfonts-utils, xfree86-driver-synaptics, xprint-utils, xprintidle, xspecs, xutils, xutils-dev
[04:28] <Keybuk> are these all in Ubuntu yet?
[04:29] <rodarvus> no, not yet - Mithrandir is working on the fonts-related packages, the others haven't been dealt with yet
[04:29] <Keybuk> ok
[04:29] <Keybuk> *-video-* have been dealt with now, yes?
[04:29] <rodarvus> *nods*, finally
[04:30] <rodarvus> I'm working on *-input-* for the next hour, likely
[04:30] <Keybuk> ok
[04:33] <Mithrandir> rodarvus: I want to do a bunch of tests, etc on the fonts, so I won't get to that today, sorry.
[04:33] <rodarvus> oh, ok
[04:34] <rodarvus> I still plan to do deal with Mesa later today, so I'm not sure we'll get to these packages today
[04:35] <seb128> iwj: around?
[04:35] <iwj> Hi.
[04:35] <Mithrandir> rodarvus: mesa is independent, though.
[04:35] <seb128> iwj: hey
[04:35] <seb128> libnss
[04:35] <iwj> Yes ?
[04:35] <seb128> libnss3 has no shlibs, which break e-d-s by example which doesn't get its depends on libnss3
[04:35] <rodarvus> Mithrandir: yes, but also a requirement for xorg, and (afaik) a lot of trouble to deal with
[04:35] <seb128> is that on purpose?
[04:36] <iwj> No shlibdeps you mean ?
[04:36] <Mithrandir> rodarvus: you might want to ask infinity about the merge, he said he was going to do it, but turned ill.
[04:36] <seb128> iwj: right
[04:36] <iwj> That's wrong.  Is it broken in Dapper too do you know ?
[04:36] <seb128> iwj: something that would make the packages building with it getting a libnss3 Depends automagically
[04:37] <seb128> iwj: I don't remember having to hack GNOME packages to get the Depends by hand so I supposed it was not broken with dapper
[04:37] <iwj> Hmmm.
[04:37] <seb128> let me check
[04:37] <iwj> How urgently do you need it fixed ?
[04:38] <rodarvus> Mithrandir: oh, thanks - I will
[04:38] <seb128> iwj: we have a good part of GNOME ftbfsing now because packages using libnss3 don't trigger it ... I can workaround e-d-s by forcing the Depends by hand though
[04:38] <rodarvus> last time I talked with him on this subject (last week) he didn't mentioned he would do this merge
[04:38] <iwj> seb128: You mean "quite urgently" :-).  I'll see what I can do .
[04:38] <seb128> iwj: ie: I want to get that fix this week but I'm fine by workarounding for now
[04:39] <seb128> s/by/with
[04:39] <seb128> thank you
[04:39] <iwj> Doesn't gnome use pkgconfig for everything ?
[04:40] <seb128> iwj: it does, why?
[04:40] <iwj> ISTR pkgconfig having some machinery for package dependencies BICBW.
[04:40] <seb128> iwj: e-d-s itself builds fine, the issue is that the shlibs:Depends doesn't list libnss3 ... so the package Depends is missing
[04:41] <iwj> Right.
[04:45] <seb128> iwj: ups, sorry, it was broken for dapper too apparently but we had a "Depends: ${shlibs:Depends}, libnss3" which got dropped during the sync with Debian
[04:45] <sharms> is security.ubuntu.com supposed to be down for maintenance or anything now?
[04:45] <seb128> iwj: I'll put that Depends back for now but it would be nice to get it fixed one day anyway ;)
[04:46] <seb128> same for libnspr4
[04:49] <iwj> seb128: Aha.  Right.  OK.  I was about to say that I couldn't find the change.
[04:49] <iwj> I don't think the version numbers are going to change any time soon so it can safely stay the way it is for now.
[04:50] <seb128> ok
[04:51] <sharms> anyone want to direct me to the proper channel to report security.ubuntu.com is down?
[04:51] <elmo> sharms: it's coming back momentarily
[04:51] <sharms> thanks
[05:05] <Keybuk> rodarvus: btw, these new xserver-xorg-video-* binaries ... they should go in main, yes?
[05:05] <rodarvus> Keybuk: correct
[05:06] <rodarvus> they will replace xserver-xorg-driver-*, as soon as we have all them finished building
[05:06] <Keybuk> we'll need to remove those xserver-xorg-* source and binaries, yes?
[05:06] <Riddell> Keybuk: can you give back a bunch of KDE stuff for me?
[05:06] <rodarvus> Keybuk: actually, if any of the *-driver-* is in universe, then the corresponding -video- should be there too
[05:06] <Riddell> Keybuk: kdeedu, adept, ktorrent, skim, avahi, kscope, kflog, kphone, python-qt3, libkexif
[05:06] <rodarvus> Keybuk: correct
[05:08] <Keybuk> rodarvus: ok, make sure that list is kept around :)
[05:08] <Riddell> pitti: I guess that's a no to my main review request? :)
[05:08] <rodarvus> Keybuk: sure :)
[05:08] <pitti> Riddell: why? I saw the wiki change, but I'm still busy with security stuff
[05:08] <pitti> Riddell: you mean for gnupg2?
[05:09] <Riddell> pitti: and gnokii
[05:09] <Riddell> pitti: whenever you can, but it's blocking lots of KDE bits
[05:09] <pitti> Riddell: oh, is it
[05:09] <pitti> ok, I'll see to it
[05:10] <pitti> Riddell: I tried gnokii with my Nokia mobile, and it worked reasonably; I hope the KDE integration is better than xgnokii :)
[05:16] <jono> hey
[05:17] <slomo> hi jono 
[05:17] <tseng> hi jono 
[05:19] <jono> hi slomo, tseng - hows tricks?
[05:20] <tseng> jono: good, you?
[05:20] <jono> tseng, cool thanks :)
[05:21] <mdz> rodarvus: you may be able to get a launchpad DBA to help you move all of the bugs in launchpad to the new package names
[05:22] <rodarvus> mdz: good you mentioned this, I had this question noted locally here - do I need to do something else besides contacting the LP DBA?
[05:22] <mdz> rodarvus: either that, or write a script
[05:23] <mdz> rodarvus: stub is probably the best person to talk to
[05:24] <rodarvus> mdz: I'll contact stub as soon as *-driver-* is built (and udpated xserver-xorg is uploaded) - thanks for the info!
[05:25] <stub> rodarvus: If I'm not around, open it as a support request on Launchpad
[05:25] <rodarvus> stub: *nods*, thanks
[05:25] <mdz> rodarvus: we don't need for the binaries to be built; malone works with source packages
[05:26] <rodarvus> so this time looks as good as any to request :)
[05:26] <rodarvus> stub: do you want me to send the package list via a LP request?
[05:27] <stub> Sure. I haven't been following the conversation :)
[05:47] <pitti> Riddell: ah, qt4 is back? :) are there actually apps that use it now?
[05:48] <Riddell> pitti: yep
[05:48] <Riddell> speedcrunch for one
[05:48] <Riddell> hwdb will I expect
[05:49] <pitti> Riddell: ok, for 18 months of support this should be good; I was just hesitant for dapper
[05:49] <pitti> Riddell: I'll do qt4, gpg2, and gnokii now; anything else that is urgent?
[05:49] <Hobbsee> pitti: the rest of kde?
[05:49] <pitti> (I'm still buried in pending security updates, so I don't want to spend too much time with reviews)
[05:50] <Hobbsee> really.
[05:50] <ivoks> hug time? :)
[05:51] <Hobbsee> ivoks: sure, but you have to fix a bug first :P
[05:51] <Hobbsee> isnt that the rules for the hug day?
[05:51] <Hobbsee> hey now!
[05:51] <Riddell> pitti: nothing else urgent no
[05:51] <Hobbsee> pitti: you be careful of my steel toe capped boots!
[05:51] <pitti> Hobbsee: tsk, you wear them in this heat?
[05:52] <Hobbsee> pitti: what heat?  it's winter here.
[05:52] <pitti> Hobbsee: I'm barefoot, so be careful :)
[05:52] <pitti> Hobbsee: oh, wrong side of the planet then
[05:52] <Hobbsee> ooh, so i could break your toes.  that would get you out of security stuff for a bit :P
[05:52] <ogra> pitti, .au has no heatwave, its always hot there
[05:52] <Hobbsee> pitti: yeah...
[05:53] <Hobbsee> pitti: it's a bit of a pain - timezones are so crazy.
[05:53] <Hobbsee> ogra: dont poke the lag!  you might hurt it!
[05:53] <ivoks> Hobbsee: is there any snow downunder? :)
[05:53] <pitti> Hobbsee: yes, I never understood Kolumbus -- a flat world would have been *so* much more practical wrt. timezones
[05:53] <Hobbsee> ivoks: a bit further south, yeah.  it's ski season :)
[05:53] <Hobbsee> pitti: LOL!
[05:53] <ogra> ivoks, there were olympic winter games in melbourne once
[05:54] <ivoks> Hobbsee: ski season... /me drools
[05:54] <Hobbsee> ivoks: i hear NZ is good for skiing, too
[05:55] <dholbach> temperature: 30,0 C, feels like: 31,5 C
[05:55] <Hobbsee> pitti: can i have one too please?  MOTU rights, while you're at it?
[05:55] <Hobbsee> :P
[05:55] <ivoks> dholbach: lol
[05:55] <Hobbsee> dholbach: nice :)  
[05:55] <dholbach> ivoks: it's what gweather tells me
[05:55] <ogra> dholbach, pffz, you havent been outside :)
[05:55] <Hobbsee> pitti: hehe thanks
[05:55] <dholbach> ogra: ?!
[05:55] <sivang> Keybuk: when you have time, I've applied your last two comments into SystemCleanUpTool, let me know if it's done or you have more reservations.
[05:55] <dholbach> ogra: i was just out for lunch and took the dog outside :)
[05:55] <ivoks> it was 36 here today :/
[05:55] <sivang> dholbach: here as well! /me melts
[05:55] <ogra> dholbach, feels like 45C here and the air feels liquid
[05:56] <dholbach> ogra: murphy jumped into a small pond - i should head to a lake or something ;)
[05:56] <ogra> heh, yeah ... a wlan equipped one ;)
[05:56] <Hobbsee> ogra: maybe if you got out of the spa, then you'd find that wasnt the case
[05:56] <ogra> Hobbsee, hmm ... good hint :P
[05:56] <Hobbsee> ogra: hehehe
[05:56] <ogra> (as if i had a spa (yet))
[05:57] <Hobbsee> hehe.  yet
[05:57] <pitti> Riddell: gnupg2 report says 'No binaries running as root or suid/sgid.', but that's a lie ;)
[05:57] <Hobbsee> must be the thought of 6am meetings to be at.
[05:57] <ogra> Hobbsee, i'm planning a sauna and a spa for this winter in the cellar i just have to finish the move...
[05:57] <Hobbsee> ogra: nice!  
[05:57] <pitti> Riddell: in fact, I believe it's suid root for the same reason that gnupg was (getting locked memory), but that should be unnecessary since kernel 2.6.8
[05:58] <pitti> Riddell: can you please kill the postinst, postrm, and lintian override and do some tests?
[05:58] <ogra> yay, finally i have a g-p-m package (even without any of our patches but it builds at least) ... now to the patches
[05:59] <ivoks> ok, when did we drop skiing subject and turn over to IT subjects? :)
[05:59] <Riddell> pitti: hmm, the rules file had the setuid setting commented out, didn't look in the postinst script, let me see
[05:59] <Hobbsee> ivoks: you're saying that IT cant be discussed on the skifields?
[06:00] <ivoks> Hobbsee: trust me, it can :)
[06:00] <ivoks> Hobbsee: but with all that snow, only thing on my mind is "leave the trace" :)
[06:01] <Hobbsee> hehe
[06:01] <mdz> does anyone know what's at the root of the pygtk dependency mess?
[06:02] <pitti> Riddell: TBH I'm not really happy about gnokii; supporting it is tough since it needs particular hardware and there are a lot of bugs in Debian's BTS which look a bit troublesome; can it be made optional?
[06:02] <mdz> ah, it's python-gnome2-desktop
[06:02] <slomo> mdz: you mean pygtk itself or gnome-python*? the latter are broken because they're on dep-wait currently because n-c-b is in NEW
[06:02] <mdz> slomo: I mean python-gnome2-desktop / python-gnome2-extras (which are part of ubuntu-desktop)
[06:03] <ogra> grrr ...
[06:03] <Riddell> pitti: it needs to be built with it to support it, but if you're not happy with it I can remove support
[06:03] <mdz> I think it's a matter of something needing rebuilding for the python transition
[06:03] <mdz> doko?
[06:03] <slomo> mdz: yes, exactly... most of gnome is FTBFS because of them atm but it only needs libmetacity and n-c-b accepted from NEW and we're fine again
[06:03] <slomo> or is it building now again? let me check...
[06:04] <pitti> Riddell: do you feel it would be a major crippling?
[06:04] <mdz> slomo: neither of those are in the new queue
[06:05] <slomo> mdz: ok, then i assume that they were accepted a short time ago... p-g-d is now again on needs build, should be fine after it build
[06:05] <Riddell> pitti: I've had a couple of requests for it but nothing major
[06:06] <Riddell> I've had more requests for gpgsm
[06:06] <pitti> that makes more sense and is much better supportability-wise
[06:06] <pitti> and once the suid root madness is fixed, it's good to go
[06:06] <doko> mdz: pong
[06:07] <mdz> doko: python-gnome2-desktop and python-gnome2-extras  cannot be installed together; do you know why?
[06:08] <doko> mdz: no, didn't look yet. let me have a look
[06:09] <pitti> Riddell: qt4-x11 fine for promotion
[06:10] <Riddell> pitti: gpg2 works fine without the setuid bit for me
[06:11] <Riddell> I'll upload a version without that
[06:11] <pitti> Riddell: I expect it just wants it for doing mlock() on 2.4 kernels
[06:11] <pitti> Riddell: that's what gpg 1 used it for
[06:13] <bluefoxicy> * Synchronise with Ubuntu.
[06:13] <bluefoxicy> <3 changelog for apmd
[06:15] <pitti> tseng: ndoc approved for main
[06:15] <siretart> pitti: whats the policy regarding packages, which have some binaries in main and others in universe/multiverse? would it be acceptable to have, say, things like ffmpeg in a sourcepackage in main, but keeping the resulting code in multiverse?
[06:15] <tseng> pitti: thanks.
[06:16] <pitti> siretart: in general, we would like to have all debs of a main source package in main
[06:16] <pitti> siretart: the exception is if some deb pulls in dependencies we do not want in main
[06:16] <siretart> pitti: I'm currently talking about xine. I'd like to merge the 2 source packages, because this split is a real PITA
[06:16] <pitti> siretart: wrt. patents I don't feel qualified enough to answer that
[06:16] <siretart> pitti: who is qualified enough for this? mdz? the TB?
[06:16] <pitti> siretart: jdub or elmo might be good persons to ask
[06:17] <pitti> siretart: personally, I wouldn't mind having one source and two binaries (xine-main and xine-extracodes as debs from one main source)
[06:18] <siretart> pitti: this is what I'd like to do
[06:18] <pitti> siretart: but IANAL, and although I do not believe that a judge would make a difference in which directory on archive.u.c. we place a deb, I defer patent stuff to Jeff or James
[06:18] <pitti> siretart: s/deb/source package/
[06:18] <siretart> jdub: elmo: around? see 3 lines above..
[06:20] <pitti> siretart: the alternative would be to make KDE and xfmedia not use xine, but I don't know whether they have an alternative
[06:20] <siretart> pitti: I don't think they have alternatives. AFAIK they rely on xine
[06:21] <siretart> but if we could just demote the resulting binaries, it would help quite a bit
[06:22] <doko> mdz: gnome-python-desktop is uploaded, needs building
[06:23] <mdz> doko: thanks
[06:23] <slomo> doko, mdz: and it needs libgnome-media-dev binary promoted to main now
[06:23] <doko> mdz: dep-wait, needs libgnome-media-dev
[06:23] <mdz> siretart: main needs to be completely clean, and that includes source packages
[06:24] <mdz> siretart: regardless of where the binaries go
[06:25] <mdz> slomo,doko: done, will be in the next publisher run
[06:25] <mdz> doko: ping me if it doesn't automatically retry
[06:26] <slomo> mdz: thanks :) while at it could you also promote libvisual, libgdiplus and ndoc (source + all binaries)? main inclusion reports are all approved by pitti and stuff is already waiting on it
[06:30] <mdz> slomo: done
[06:30] <slomo> mdz: thanks again :)
[06:32] <mdz> Riddell: which binaries in kdeedu are new?  it's not obvious from the queue output; it shows them all
[06:32] <Riddell> mdz: ogra updated kdeedu.  it's not a major version change so I expect it's just kdeedu-dbg
[06:38] <Kamion> mdz: I use 'm -s edgy -S kdeedu; q info kdeedu' to work it out
[06:39] <Keybuk> Kamion: I use "M -S kdeedu" :p
[06:39] <Keybuk> (M == m -s edgy)
[06:39] <mdz> Kamion: I used apt-cache showsrc|grep-dctrl -sBinary
[06:40] <mdz> the new thunar looks a bit weird
[06:40] <mdz> libthunar-vfs-1 -> libthunar-vfs-1-2
[06:40] <mdz> though, libthunar-vfs-1 contains /usr/lib/libthunar-vfs-1.so.2.1.0 so I guess it's a bug fix
[06:41] <mdz> how did that get into main with the soname not matching the package name?
[06:42] <Kamion> Mithrandir: could you rebuild cdebconf-keystep against the new newt (0.52), please?
[06:42] <Keybuk> mdz: we inherited it from Debian
[06:44] <mdz> Keybuk: we still review stuff for main which comes from Debian
[06:44] <mdz> it's possible that it was changed since the review
[06:48] <Keybuk> mdz: we do?
[06:48] <Keybuk> I just sync them all :)
[06:48] <pitti> Riddell: libifp and kdea11y approved
[06:48] <Keybuk> so afaik do Colin and Adam
[06:48] <Riddell> pitti: thanks pitti :)
[06:54] <Keybuk> mdz: we seriously do not have the time to check every new source and binary from Debian when we do syncs
[06:54] <Keybuk> mdz: there's hundreds of them a day
[06:58] <Keybuk> (though I guess it could have been correct at the MIR point, and then broken by sync)
[07:10] <mdz> Keybuk: new sources go into universe by default, and we only promote them to main with an MIR
[07:11] <mdz> https://wiki.ubuntu.com/MainInclusionReportThunar says it met the library packaging policy as of 2006-01-19
[07:18] <Keybuk> mdz: yup, I see what you mean now :)
[07:21] <mdz> pitti: ping
[07:29] <Riddell> mdz: could you promote a few things to main that pitti approved today?
[07:29] <Riddell> gnupg2: gpgsm
[07:29] <Riddell> kdeaccessibility: kbstate kde-icons-mono kdeaccessibility kmag kmousetool kmouth ksayit kttsd
[07:29] <Riddell> libifp: libifp-dev libifp4
[07:29] <Riddell> and qt4-x11: libqt4-core libqt4-dev libqt4-gui libqt4-qt3support libqt4-sql qt4-doc
[07:31] <Riddell> hmm, gnupg2 has a bunch of build-depends that need looked at
[07:31] <slomo> Riddell: oh, qt4 in main... i'll reenable the dbus and avahi bindings later :)
[07:31] <mdz> Riddell: gnupg2 and kdeaccessibility binaries done
[07:31] <mdz> Riddell: libifp is listed as unreviewed
[07:32] <Riddell> mdz: the wiki page says it's approved https://wiki.kubuntu.org/MainInclusionReportLibIfp
[07:33] <mdz> pitti: please confirm that ifp is approved and just not moved on the wiki page
[07:34] <pitti> mdz: yep, sorry, my network broke down at the right moment
[07:34] <mdz>  o type-handling: type-handling
[07:34] <mdz>    [Reverse-Depends: Edgy supported seed] 
[07:34] <mdz> errr
[07:34] <pitti> *shock*
[07:35] <mdz> Riddell: libifp done
[07:36] <mdz> Riddell: and qt4-x11
[07:36] <pitti> mdz: oh, wiki page already said it was approved
[07:36] <mdz> pitti: yes, just wanted confirmation
[07:36] <Riddell> thanks mdz 
[07:37] <mdz> pitti: btw, it looks like libthunar-vfs-1 was improperly packaged (soname vs. package name) but the inclusion report said that it met the library policy (https://wiki.ubuntu.com/MainInclusionReportThunar)
[07:37] <mdz> type-handling certainly isn't seeded; must be a germinate weirdness
[07:37] <mdz> Kamion: ^^^
[07:37] <Keybuk> mdz: iz germinate bug
[07:38] <Keybuk> type-handling Provides linux
[07:38] <pitti> mdz: thunar> sorry for that
[07:40] <mdz> pitti: doesn't lintian catch that?
[07:40] <pitti> I don't know, but a test for that seems easy
[07:42] <slomo> lintian catches this normally
[07:43] <mdz> Kamion: this shadow upload creeps me out a bit
[07:43] <pitti> mdz: a USN is underway, if you mean that
[07:43] <mdz> pitti: I assume janimo prepared the original report?
[07:43] <pitti> mdz: yes
[07:43] <mdz> pitti: I mean the fix creeps me out :-)
[07:44] <pitti> mdz: h4ck, h4ck :-P
[07:49] <bddebian> h4ck iz g00d
[07:51] <sivang> pitti: security fix which is a h4ck ? :)
[07:55] <rodarvus> any FreeType and (prererably) libxfont wizards around?
[07:55] <rodarvus> I needed to use the following patch -> https://bugs.freedesktop.org/attachment.cgi?id=6033
[07:56] <rodarvus> to get libxfont to compile with libfreetype6-2.2.1-2
[07:57] <rodarvus> it appears to work correctly locally, but I'd like to hear from an experienced voice before uploading it
[07:57] <mdz> rodarvus: no, cleaning up after a security bug in the installer
[07:58] <rodarvus> mdz: *nods*, thanks anyway :)
[08:10] <mdz> rodarvus: is this all xserver-xorg-video-* or are there more to come?
[08:11] <tseng> Keybuk: can you please give back nant, ndoc, nunit2.2, mono-tools everywhere?
[08:12] <rodarvus> mdz: no, all set
[08:13] <mdz> rodarvus: OK, I'll promote them once the publisher is finished
[08:13] <rodarvus> I have a xserver-xorg update ready to upload xserver-xorg-video-all (announced it on #ubuntu-x one hour ago)
[08:14] <rodarvus> mdz: just waiting for the promotion and to check if someone else has valid points against the migration
[08:15] <mdz> rodarvus: go ahead with the upload; it will take two publisher runs before it goes in, and the binaries for xserver-xorg-video-* will be published by then
[08:16] <rodarvus> ok, I'll upload it now, then
[08:18] <rodarvus> upload done
[08:22] <pitti> rodarvus: can I bribe you to do the mesa merge, too?
[08:23] <rodarvus> pitti: I wanted to do this merge today, but I was informed infinity was working (or would work) on it
[08:23] <pitti> oh, ok
[08:23] <rodarvus> but I was unable to find him yet, so I'm unsure on what to do
[08:24] <rodarvus> btw, mesa is apparently one of the packages holding X to be cleanly upgraded
[08:25] <pitti> rodarvus: he's still ill
[08:25] <rodarvus> *nods*
[08:26] <pitti> sladen: are you going to merge linda, or do you want one of us to do it (I'd be fine with merging it)
[08:28] <mdz> rodarvus: infinity mailed warthogs saying he was ill
[08:28] <mdz> ah, pitti mentioned already
[08:28] <maswan> pitti: thank you, nice USN: http://www.acc.umu.se/technical/statistics/ftp/monitordata/index.html.en
[08:29] <pitti> maswan: yes, kernel updates suck... :(
[08:29] <maswan> pitti: Thanks though, we get to test our new cluster, and it seems release-capable without much human intervention. :)
[08:30] <pitti> maswan: when running debmirror today, my quota sighed loudly at me, too
[08:30] <pitti> maswan: glad to be of help :-p
[08:42] <maswan> pitti: :)
[08:51] <slomo> Keybuk: please give-back hal everywhere... builds now
[08:56] <mdz> rodarvus: don't forget to update xserver-xorg to depend on xserver-xorg-video-all
[08:57] <rodarvus> mdz: that was done on my upload, thanks for remembering me, though!
[09:04] <mdz> rodarvus: ah, didn't see it on -changes
[09:05] <rodarvus> mdz: oh, sorry, I must have forgotten to note this specific change :/
[09:05] <rodarvus> s/note/write on changelog/
[09:11] <Kamion> mdz: I know about the germinate weirdness but I haven't had time to investigate it properly yet
[09:12] <Kamion> mdz: suggestions for other approaches to shadow welcome; I couldn't think of any others
[09:13] <mdz> Kamion: cry?
[09:14] <Kamion> did that already
[09:15] <Keybuk> hal 0.5.7-2ubuntu4 - powerpc sparc ia64 i386 amd64
[09:15] <Keybuk> slomo: ^
[09:15] <Keybuk> rodarvus: you missed one
[09:16] <Keybuk> rodarvus: xserver-xorg-video-v4l
[09:16] <slomo> Keybuk: thanks :)
[09:16] <mdz> jdub: UWN issues #2-5 seem to be missing from the fridge
[09:16] <Keybuk> tseng: cannot give back nant or ndoc
[09:16] <rodarvus> Keybuk: let me check
[09:16] <Keybuk> nunit2.2 2.2.0-3ubuntu1 - i386
[09:16] <Keybuk> mono-tools 1.1.11-4 - i386
[09:16] <tseng> Keybuk: what does that mean?
[09:16] <Keybuk> tseng: which bit?
[09:16] <tseng> should i upload a new build?
[09:17] <tseng> "cannot give back"
[09:17] <Keybuk> tseng: nant doesn't have a failed build to give back
[09:17] <Keybuk> the only build is for i386, and it's in "needs building" anyway
[09:17] <Keybuk> ndoc is already successfully built
[09:17] <tseng> ok
[09:17] <rodarvus> Keybuk: indeed, you're right
[09:17] <tseng> Keybuk: thanks.
[09:17] <Keybuk> tseng: if you want ndoc *rebuilt*, you do need to do a new upload
[09:18] <rodarvus> I was merging/syncing the *-video-* drivers based on http://people.ubuntu.com/~fabbione/x-pkgs
[09:18] <tseng> Keybuk: I don't, I will stop believing things slomo says now
[09:18] <rodarvus> Keybuk: I'll do -v4l *now*
[09:18] <tseng> Keybuk: or I misunderstood and he didnt want to give back ndoc
[09:18] <tseng> *shrug*
[09:18] <Keybuk> rodarvus: -v4l is only in Debian -- but will probably still need some touching for the provides, no?
[09:19] <slomo> tseng: i meant you should care for all of them to be fine :) i didn't know which ones needed a give-back or not but i knew that all of them should be fine now
[09:19] <tseng> oh
[09:19] <Keybuk> rodarvus: sorry, ignore that, it's in Ubuntu too (I looked for -video- in ubuntu <g>)
[09:20] <rodarvus> Keybuk: no, actually you're right, I didn't worked on a -v4l packages
[09:20] <rodarvus> (and don't think someone else did)
[09:20] <Keybuk> right -- it needs a merge
[09:29] <Keybuk> pitti: all the ndiswrapper packages moved around and I haven't had a chance to figure out how yet
[09:30] <Keybuk> so if anyone bitches that it's back in universe, that's why
[09:31] <pitti> Riddell: qt4-x11-kdecopy?
[09:31] <Keybuk> they'll probably need another MIR, given the scale of change
[09:31] <Riddell> pitti: what about it?
[09:32] <Riddell> ooh, it's passed new
[09:33] <Riddell> pitti: it's the version of qt4 needed to build kde 4.  I get daily requests from KDE developers for it, thus I supply
[09:33] <Keybuk> Riddell: yeah, I couldn't find any reason to reject it :(
[09:33] <Keybuk> and believed me, I tried

[09:33] <Keybuk> I guess KDE no longer works with qt3?
[09:34] <Riddell> Keybuk: KDE 4 doesn't
[09:34] <Riddell> but KDE 4 is still hardcore developers only area
[09:34] <Keybuk> KDE 4 being newer than what we currently have>?
[09:34] <Keybuk> why do we need qt4 in main though?
[09:35] <Riddell> Keybuk: some non-KDE application already use qt 4
[09:35] <Riddell> Keybuk: and any new applications should use qt 4 and avaid having to port later
[09:35] <Riddell> avoid
[09:35] <rodarvus> Keybuk: xserver-xorg-video-v4l_0.0.1.5-1ubuntu1_source.changes is NEW
[09:35] <Keybuk> so KDE users will have two different widget sets mapped into memory?
[09:36] <Keybuk> does that work?
[09:36] <rodarvus> Keybuk: I'd be forever thankful if you could Accept it ASAP :)
[09:36] <Riddell> Keybuk: yes.  just like how gnome users had to have gtk 1.2 and gtk 2 for a good length of time
[09:36] <Keybuk> rodarvus: checking now
[09:37] <Keybuk> Riddell: right, I just mean in the sense have the Qt people thought of that?
[09:37] <Keybuk> given the symbol clash headache
[09:38] <pitti> Riddell: it just smells like code duplication :)
[09:38] <rodarvus> Keybuk: thanks!
[09:40] <Riddell> Keybuk: qt 3 and 4 have completly different filenames, libqt3-mt.so against libqt4-core.so,libqt4-gui.so etc
[09:40] <Riddell> Keybuk: and different symbol names to match
[09:40] <Riddell> pitti: there's very little duplicated between qt 3 and 4 if that comforts you :)
[09:40] <Keybuk> Riddell: filenames doesn't make a difference, the linker just picks the first one it finds
[09:41] <Riddell> Keybuk: sure, but I'm yet to hear of any linker getting confused between the two, they're very different and not backward compatible
[09:41] <Keybuk> Riddell: ok
[09:42] <Keybuk> I guess they're C++ libraries anyway, so almost certainly have different symbols
[09:42] <pitti> Riddell: I mean duplication of code in qt4-x11 and qt4-x11-kdecopy
[09:42] <Keybuk> pitti: that's a good thing, surely
[09:43] <Keybuk> it'd me much easier if every application included it's own copy of xpdf's code
[09:43] <Keybuk> then we wouldn't have so many upgrade headaches

[09:43] <pitti> *cough*
[09:43] <Riddell> pitti: oh yes lots, qt4-x11-kdecopy won't get near main though, and the two packages conflict
[09:43] <pitti> Riddell: ah, for universe only? *phew* :)
[09:44] <pitti> Riddell: still confused, if KDE needs it, it'll certainly need to be in main?
[09:44] <Riddell> pitti: qt4-x11-kdecopy is qt 4.2-preview plus some random patches, qt4-x11 is the released 4.1.  KDE 4 will get into sync with stable qt long before we need kde 4 in main
[09:45] <pitti> Riddell: ah, so they are ABI compatible and you can switch between them?
[09:45] <pitti> Riddell: ok, then I love you again :)
[09:58] <crimsun> elmo: ping
[10:07] <seb128> Keybuk, mdz: could you give a retry to the builds for control-center evolution-exchange epiphany-extensions and gnome-panel?
[10:08] <Keybuk> control-center 1:2.15.3-0ubuntu1 - powerpc ia64 sparc i386 amd64
[10:08] <Keybuk> evolution-exchange 2.7.4-0ubuntu1 - powerpc ia64 sparc i386 amd64
[10:08] <Keybuk> epiphany-extensions 2.15.1-0ubuntu2 - powerpc ia64 sparc i386 amd64
[10:08] <Keybuk> gnome-panel 2.14.2-1ubuntu1 - powerpc ia64 sparc i386 amd64
[10:12] <Kamion> Mithrandir: never mind, I've done the cdebconf-keystep upload now
[10:12] <Kamion> Mithrandir: feel free to pull from the .bzr directory in the source upload
[10:28] <seb128> Keybuk: thank you
[10:33] <Keybuk> pitti: two rejected syncs out of two requested
[10:33] <pitti> Keybuk: uh, bad luck today
[10:33] <pitti> Keybuk: gtimelog and myspell-sk?
[10:33] <Keybuk> yeah
[10:34] <pitti> Keybuk: what's wrong with gtimelog?
[10:34] <pitti> we have the current Debian version (I alrady wondered why it doesn't autosync)
[10:34] <Keybuk> pitti: it's already up to date?
[10:34] <Keybuk> it does autosync
[10:34] <pitti>   gtimelog | 0.0+svn65-1debian1 | http://archive.ubuntu.com edgy/universe Packages
[10:35] <pitti> Debian has 1debian2, which brings back the nice report formatting
[10:35] <Keybuk>   gtimelog | 0.0+svn65-1debian1 | edgy/universe | all
[10:35] <Keybuk>   gtimelog | 0.0+svn65-1debian2 | edgy/universe | source
[10:35] <Keybuk> it just hasn't built
[10:35] <pitti> Keybuk: hm, I did my last apt-get update at the time when I filed the sync request, sorry
[10:35] <Keybuk> it only arrived from Debian today, and the buildds are doing X things
[10:35] <pitti> ah, ok
[10:36] <pitti> Keybuk: and myspell-sk?
[10:36] <Keybuk> pitti: different orig.tar.gz sizes
[10:36] <Keybuk> merge it, I'm afraid
[10:36] <pitti> 'k
[10:36] <Keybuk> rodarvus: and as for you ... we can't sync packages that don't exist in Debian <g>
[10:40] <bddebian> heh
[10:43] <rodarvus> Keybuk: oh, sorry, I didn't noticed the package had different name (xfree86-driver-synaptics in debian)
[10:44] <rodarvus> Keybuk: I use a local script to download packages from ubuntu & debian automatically
[10:44] <rodarvus> and "apt-get source xserver-xorg-input-synaptics" (on debian) works just fine - only grabs a package with different name :P
[10:52] <mdz> seb128: why are you uploading a package with a dependency on a newer version of another package that you know doesn't exist yet? ;-)
[10:52] <seb128> mdz: because configure requires it? :)
[10:53] <seb128> mdz: speaking about totem, right?
[10:53] <mdz> seb128: alacarte is the one I noticed
[10:53] <seb128> ah
[10:53] <seb128> hum
[10:53] <seb128> ah, speaking about the changelog
[10:53] <mdz> is totem going to be uninstallable also?
[10:54] <mdz> that's going to make it hard to do a milestone
[10:54] <seb128> the "New version" is the upstream NEWS entry :)
[10:54] <Amaranth> oh, i left that in? :)
[10:54] <seb128> no, alacarte is installable, we have gnome-menus 2.15.4.1, I got vuntz to roll a tarball today before packaging alacarte
[10:54] <seb128> and for totem xine-lib 1.1.2 got uploaded today
[10:54] <seb128> so it's all good :)
[10:55] <mdz> ok, good
[10:55] <Amaranth> i actually didn't change the configure.ac to require 2.15.x, i couldn't get a package for it built :P
[10:55] <seb128> Amaranth: I made the package require 2.15.4.1 ;)
[10:55] <Amaranth> of course
[10:56] <seb128> mdz: is there any CD rolling planned for this week?
[10:57] <mdz> seb128: knot CD 1 was tentatively scheduled for Thursday (see EdgyReleaseSchedule)
[10:57] <seb128> hum, k
[10:57] <seb128> we are almost done with GNOME 2.15.4, only 5-6 tarballs to do tomorrow
[10:57] <seb128> and then we will work to get everything building fine and stabilized
[10:57] <seb128> so GNOME should not been an issue
[10:58] <Kamion> basically as soon as everything works ...
[10:58] <Kamion> well, FSVO "everything"
[10:59] <Kamion> I suspect a mass give-back will clear a lot of issues
[10:59] <seb128> it should
[11:06] <mdz> doko: do you know what the problem is with hpijs vs. foomatic-filters-ppds
[11:06] <mdz> ?
[11:07] <mdz> oh, it's hplip-ppds
[11:08] <mdz> foomatic-filters-ppds pulls in hplip-ppds, and hpijs conflicts with it
[11:09] <mdz> er, s/hpijs/foomatic-db-hpijs/g
[11:17] <mdz> ah, hplip-ppds has been renamed to hpijs-ppds
[11:20] <Kamion> yes, I adjusted the seeds
[11:20] <Kamion> although I didn't do a metapackage upload
[11:20] <mdz> yeah, I just discovered that
[11:20] <mdz> would have saved me some time if you had ;-)
[11:21] <mdz> Kamion: any reason for me not to update ubuntu-meta now?
[11:21] <mdz> in fact it sent me on a wild goose chase trying to figure out what I missed when I grepped the seeds for hplip-ppds and found nothing ;-)
[11:22] <Kamion> mdz: go for it
[11:22] <Kamion> I've just been doing seed updates based on changes in NEW
[11:23] <mdz> Kamion: do you think it would be any faster to ship a bzr checkout in ubuntu-meta and only have to update it?
[11:23] <mdz> it takes ages to pull the seeds from bzr
[11:24] <mdz> I bet rsync would be faster than sftp
[11:25] <bddebian> scp
[11:25] <bddebian> :-)
[11:25] <Kamion> I guess that would be reasonable, although please arrange for it not to be called .bzr so that I don't have to adjust my debuild configuration to explicitly include it every time I upload ubuntu-meta
[11:25] <Kamion> can we rsync from bazaar.launchpad.net though?
[11:25] <Kamion> I think an sftp update of an existing checkout should be pretty fast
[11:35] <Keybuk> Kamion: shall I do a mass give-back?
[11:37] <Kamion> Keybuk: please do
[11:49] <Evaso2> Keybuk: hi Scott any plan to sync network-manager with the debian version 0.6.3?
[11:50] <Keybuk> Evaso2: yes
[11:50] <Evaso2> Keybuk: there are many bugs solve especially now the pptp vpn plugin works fine
[11:50] <Keybuk> no it doesn't
[11:51] <Keybuk> it's still broken
[11:53] <Evaso2> Keybuk: what version have u tried 0.6.9 of pptp plugin?
[11:57] <Evaso2> Keybuk: or 0.7.0 version?
[11:58] <Keybuk> Evaso2: I haven't tried any of them
[11:58] <Keybuk> I just can see they've not fixed the fundamental problem
[11:58] <Evaso2> Kebuk: mppe or the usernam and password?
[11:58] <Keybuk> neither
[11:58] <Keybuk> DNS
[11:59] <Evaso2> Keybuk there is the option to keep the dns from the peer or not
[11:59] <Keybuk> Evaso2: I will talk to you in ~10 minutes
[12:00] <Evaso2> Keybuk: o i'm waiting u will come back