[00:25] <Riddell> siretart: how does this patch look to you? http://www.kubuntu.org/~jriddell/tmp/xine-lib-1.1.15-cpp-compilation.diff
[00:31] <kirkland> slangasek: any known tool chain issues at the moment?
[00:32] <kirkland> slangasek: i can't compile qemu from sources right now on an up-to-date intrepid; same problem in my ppa
[00:32] <kirkland> http://launchpadlibrarian.net/17939088/buildlog_ubuntu-intrepid-amd64.qemu_0.9.1-5ubuntu3_FAILEDTOBUILD.txt.gz
[00:40] <slangasek> kirkland: nope, this is the first I've heard of a possible toolchain issue
[00:41] <aliguori> kirkland, you don't have a <linux/dirent.h>?
[00:43] <aliguori> fwiw, 0.9.1 is ancient
[00:43] <aliguori> svn no longer depends on linux/dirent.h
[00:43] <kirkland> aliguori: it's kind of late in Intrepid to do a merge
[00:43] <kirkland> aliguori: we're almost up against Beta Freeze
[00:44] <kirkland> looks like it's missing a build dependency on linux-headers
[00:44] <aliguori> is linux-headers /usr/include/linux?
[00:44] <aliguori> or /lib/modules/$(uname -r)/build/include?
[00:44] <aliguori> b/c qemu uses /usr/include/linux
[00:44] <kirkland> aliguori: ah
[00:44] <aliguori> that should come with glibc i would think
[00:44] <slangasek> dirent.h doesn't appear to be part of linux-libc-dev, i.e., not part of the headers linux exports for userspace
[00:45] <kirkland> libc6-dev: /usr/include/dirent.h
[00:45] <aliguori> kirkland, well svn now uses <dirent.h> and not <linux/dirent.h> so you may be able to get away with just changing it like that
[00:46] <kirkland> aliguori: in linux-user/syscall.c:#include <linux/dirent.h>
[00:46] <aliguori> yeah, i know
[00:46] <kirkland> aliguori: okay, i'll try that
[00:46] <kirkland> aliguori: we'll merge up qemu as soon as Jaunty opens
[00:46] <kirkland> slangasek: am i correct in assuming that it's too late for a merge?
[00:47] <slangasek> um it's a bit late without a pretty good justification :)
[00:48] <kirkland> slangasek: yeah, i'm not willing to fight this one
[00:48] <kirkland> aliguori: btw, debian has 0.9.1-6
[00:48] <kirkland> aliguori: what's upstream at?
[01:08] <hikenboot> no one in #ubuntu seems to know...anyone in here know if the python libaries (any of them in ubuntu) have been minimized to include just the libraries used in xen?
[01:10] <ogra> slangasek, i have a bug i'd like to nominate for beta so it gets on you radar, but obviously i cant nominate bug 67366 since it was initially filed wrongly for baltix, now the balitx RM would have to approve a nomination ... can you put it on your radar somehow nontheless ?
[01:14] <slangasek> ogra: try https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/67366?
[01:14] <ogra> lol
[01:14] <ogra> silly ...
[01:14] <ogra> i just clicked the link in the mail
[01:15] <aliguori> kirkland, we have a problem with releases..  i think 0.9.1 is about a year old (but it's the latest)
[01:16] <kirkland> aliguori: okay
[01:16] <kirkland> aliguori: comparitively few people use qemu itself in ubuntu (it's in universe)
[01:17] <kirkland> aliguori: i'd say most people use the bits built into the kvm package
[01:23] <davismj> hello
[01:24] <kirkland> aliguori: looks like that solved the build issue, thanks
[01:24] <davismj> np
[01:24] <kirkland> aliguori: i'm going to apply that patch (evdev one) to qemu in Ubuntu Universe
[01:29]  * ion_ chuckles at Keybuk’s module-init-tools changelog entry.
[01:30] <kirkland> slangasek: is it too late to get that kvm patch sponsored?
[01:30] <kirkland> slangasek: mathiaz has reminded me that beta freeze has started :-/
[01:33] <slangasek> kirkland: do you have a debdiff somewhere?
[01:33] <slangasek> (I haven't technically pushed the button yet for the freeze, anyway :)
[01:34] <kirkland> slangasek:  https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/258389
[01:42] <slangasek> TheMuso: libcanberra-gnome added to desktop> was this discussed somewhere, and do you know how much space it'll cost us on the CDs?
[01:43] <TheMuso> slangasek: It wasn't discussed, however sound events are somewhat broken without it. As for size, I'm just double checking, but its about 6/8KB.
[01:45] <TheMuso> slangasek: yep 8KB.
[01:46] <slangasek> ok
[01:47] <TheMuso> slangasek: If need be, I can squash the ubuntu sounds down even further to get another 400/500KB space freed up.
[01:47] <slangasek> TheMuso: I think 8KB will be ok :)
[01:47] <TheMuso> slangasek: I was thinking of space for other things.
[01:48] <slangasek> TheMuso: given that we're not currently oversized, I'd rather not have us twiddling that this late in the cycle
[01:48] <TheMuso> slangasek: Ok.
[01:59] <slangasek> kirkland: why are so many of these keys mapped to 0x0, and is that a regression?
[01:59] <kirkland> slangasek: i duplicated the aliguori's code from gtk-vnc
[02:00] <kirkland> aliguori: can you answer that?
[02:02] <kirkland> slangasek: i tested all of the keys on my thinkpad
[02:02] <slangasek> sure
[02:02] <slangasek> but your thinkpad probably doesn't have any of these Japanese keys :-)
[02:03] <slangasek> is there any other lib linkage needed for Xkb functions?
[02:03] <slangasek> that's certainly not core libX11
[02:04] <kirkland> slangasek: guilty on the no Japanese keys
[02:05] <kirkland> slangasek: not sure about other libX11 linkage, that -lX11 was what i needed to get it to build
[02:05] <slangasek> I fear that the xkb symbols are being resolved incidentally only
[02:05] <slangasek> ah, no - they are in libX11
[02:05] <slangasek> (surprising, to me)
[02:05] <kirkland> slangasek: why's that/
[02:05] <slangasek> ok, will upload shortly
[02:06] <kirkland> slangasek: i found what i needed in /usr/lib/X11/*
[02:06] <slangasek> why is it surprising?  Because X11 is much, much older than Xkb :)
[02:06] <kirkland> slangasek: okay, and what did you do to verify?
[02:06] <slangasek> objdump -T /usr/lib/libX11.so | grep .text.*Xkb
[02:07] <slangasek> (should be grep \\.text.*Xkb, but)
[02:07] <kirkland> slangasek: cool, thanks.
[02:08] <slangasek> uploading
[02:09] <ykphuah> asac: you there?
[02:10] <ogra> ykphuah, that would be a lot of luck ... 3am here
[02:10] <ykphuah> ogra: ah, do you know what time he is usually online?
[02:10] <ogra> CEST office time and later
[02:11] <ykphuah> CEST office time will be like, 5 hours from now?
[02:11] <ogra> yeah, 5-7 ... depending if he's up early :)
[02:11] <ykphuah> alright, thanks ogra
[02:19] <Burgundavia> ogra: isn't evtouch usable in kde as well?
[04:20] <NCommander> StevenK, yo?
[04:31] <NCommander> slangasek, ping
[04:32] <NCommander> pitti, ping?
[04:33] <Hobbsee> NCommander: too late / too early
[04:33] <NCommander> Hobbsee, know anyone of ubuntu-sru who lives?
[04:33] <NCommander> at this time
[04:33] <jdong> for i in /ircfs/freenode/#ubuntu-devel/nicks/*; do sleep 1m; echo "$i: (yo|ping)"; done
[04:33] <jdong> :)
[04:33] <NCommander> s/-devel/-sri/g
[04:33] <NCommander> :-)
[04:34] <NCommander> er
[04:34] <NCommander> s/-sri/-sru/g
[04:34] <Hobbsee> NCommander: not currently
[04:38]  * NCommander notes that its kinda pathetic he has a full set of Ubuntu port machines
[04:38] <NCommander> or access to them at the very least
[04:56] <bdmurray> NCommander: maybe sbeattie
[04:57] <sbeattie> NCommander: I'm around, but do not have archive privs. What do you need?
[04:57] <NCommander> sbeattie, I have a PowerPC SRU fix that's been sitting for awhile
[04:57] <NCommander> Its got three verifications, I need someone who can push it through
[05:00] <sbeattie> NCommander: which one is that?
[05:00] <NCommander> miro (source gnome-python-extras)
[05:00] <NCommander> Let me find it
[05:00] <NCommander> sbeattie, https://bugs.edge.launchpad.net/ubuntu/hardy/+source/gnome-python-extras/+bug/181068
[05:46] <siretart> Riddell: excellent!
[05:53] <dholbach> good morning
[06:15] <NCommander> hey dholbach
[06:15] <NCommander> does anyone know who admins packages.ubuntu.com?
[06:15] <dholbach> hi NCommander
[06:15] <dholbach> NCommander: I'd say the IS team
[06:15] <NCommander> It looks like one single person
[06:15] <NCommander> I wanted to see if its possible to get the Ubuntu ports listed
[06:17] <nxvl> NCommander: Keybuk
[06:17] <NCommander> Keybuk, I've been looking at the packages scripts, I'd like to talk to you on getting the Ubuntu ports listed :-)
[08:41] <mvo> pitti: on my intrepid system jockey offer me to install fglrx, however that breaks the system very badly (no xserver 1.5 support, diverts libdri.so that misses symbols). should I file a bug that it does not offer this driver or is that a known issue already
[08:53] <tseliot> mvo: maybe we should make jockey conflict with fglrx-modaliases then
[08:56] <tseliot> mvo, pitti: or maybe I can make jockey blacklist certain drivers
[08:59] <mvo> tseliot: blacklist sounds like a good and flexible solution to me
[09:00] <tseliot> mvo: good. If pitti agrees, I will implement this.
[09:03] <Chipzz> not sure exactly how provides work
[09:03] <Chipzz> but wouldn't a provide on the xserver api
[09:04] <Chipzz> and then a conflicts from the xserver on previous apis be a nicer solution?
[09:06] <RAOF> That's already implemented; xserver-xorg(-core ?) provides something like xserver-video-abi-2.1.  And so the fglrx package could indeed conflict with that.
[09:07] <tseliot> ah, so you suggest that we hardcode the abi, hmm...
[09:07] <RAOF> But that sounds like a less-friendly solution than blacklists.
[09:08] <RAOF> Because that'll make jockey say "hey, you've got a driver you could install!", except it'd be lying, because it's uninstallable.
[09:08] <cjwatson> NCommander: Keybuk maintains patches.ubuntu.com, not packages.ubuntu.com - nxvl was mistaken
[09:09] <cjwatson> NCommander: AFAIK it's still Frank Lichtenheld (djpig on IRC though he's probably not on Ubuntu channels)
[09:09] <RAOF> tseliot: The open drivers already depend on the exported abi, so making nvidia & fglrx depend on it to wouldn't be a bad thing.
[09:09] <tjaalton> RAOF: they already do
[09:09] <RAOF> But I'd think you'd probably want a blacklist as well, so you don't present impossible to install options.
[09:09] <tseliot> RAOF: they already do
[09:09] <RAOF> So why can you install fglrx?
[09:10] <tseliot> we rebuild them every time the ABI changes
[09:10] <tseliot> RAOF: because it was rebuilt
[09:10] <slangasek> NCommander: ehm, how do you have three verifications on an sru fix if ubuntu-sru has only just now been subscribed to the bug?
[09:10] <tjaalton> RAOF: actually, fglrx doesn't, nvidia does
[09:10] <slangasek> NCommander: verifications are done on packages that have been uploaded to hardy-proposed...
[09:11] <RAOF> tjaalton: Yeah.  I was just looking at xorg-driver-fglrx and there's no mention of the abi :)
[09:11] <cjwatson> slangasek: for 181068? according to the bug, pitti accepted it into -proposed on the 12th
[09:11] <tseliot> tjaalton: ah, didn't superm1|away do the same thing for fglrx?
[09:12] <tjaalton> tseliot: doesn't seem like it
[09:12] <cjwatson> as it happens I only see two verifications
[09:12] <tseliot> we even talked about it
[09:12] <cjwatson> but anyway
[09:12] <slangasek> cjwatson: hrm, then who forgot to subscribe ubuntu-sru? :)
[09:12] <tjaalton> that's why it is left installed on upgrade
[09:12] <tjaalton> when it should be purged instead
[09:12] <slangasek> ah, 'miro' was a red herring, I do see an SRU pending for gnome-python-extras
[09:14] <tseliot> tjaalton: ok, understood
[09:16] <Chipzz> RAOF: well I was actually thinking the other way around
[09:17] <Chipzz> have fglrx provide xserver-video-abi-2.1, and have the xserver conflict with all versions below what it "provides"
[09:18] <Chipzz> that way you don't have to upgrade the fglrx package to conflict on the xserver package when a new ABI is released
[09:19] <RAOF> Chipzz: Right.  I've just reminded myself; that _is_ the way the drivers do it - nvidia appears to provide xserver-video-4, for example.
[09:21] <tjaalton> I'll add it
[09:21] <Chipzz> OTOH you could have the fglrx package Depend on a specific abi version too
[09:22] <Chipzz> which I guess is probably the nicer solution, as your list of conflicts won't keep growing as more ABI versions are released
[09:23] <tjaalton> the server doesn't Provide the ABI, so that doesn't work
[09:24] <tjaalton> hm, the server also doesn't conflict -2.1 or -2.9
[09:28] <Chipzz> tjaalton: I was not saying that's the way it's done; just pointing out a possible way of doing it
[09:29] <pitti> Good morning
[09:29] <tjaalton> Chipzz: sure, and I think it has been discussed at some point
[09:30] <pitti> apachelogger: hm, that's indeed a known problem; we could do something about "explaining the reason", but not much else, I'm afraid
[09:30] <pitti> NCommander: hi
[09:30] <pitti> mvo: there are plenty of bug reports about it, so no new bug necessary
[09:30] <mvo> ok, thanks pitti
[09:30] <pitti> tseliot, mvo: no problem, we can just not ship the fglrx handler for a while
[09:31] <pitti> tseliot, mvo: a related question is what to do on upgrades
[09:31] <seb128> hello pitti mvo
[09:31]  * pitti hugs seb128
[09:31] <mvo> pitti: the current plan (discussed via mail last week) is to warn about it on upgrades and if the user still continues, transition him from fglrx to ati
[09:31] <mvo> hey seb128
[09:31]  * seb128 hugs pitti
[09:32] <pitti> mvo: with update-manager and python-xkit?
[09:32] <mvo> pitti: the same for nvidia-glx-71 and -96 (unless we get updates here that make those work)
[09:32] <pitti> mvo: or shall we proxy that in jockey itself?
[09:32] <mvo> pitti: yes, that is the current plan
[09:32] <tkamppeter> pitti, have you seen my mail, about bug 269311?
[09:32] <mvo> pitti: I don't mind either way, it seems like at least the warning stuff needs to go into u-m
[09:32] <pitti> tkamppeter: haven't read mail yet (sorry, slept in, still a bit ill)
[09:32] <mvo> pitti: and for the removal probably as well, because fglrx needs to be purged
[09:32] <pitti> mvo: right
[09:36] <Koon> pitti: did you see nijaba's email about the nagios2/3 in main mess ? Filed bug 273871 to fix it for intrepid
[09:37] <pitti> tkamppeter: btw, in case you plan to upload an s-c-p which uses search_driver(), that needs a FF exception
[09:37] <pitti> Koon: yep, saw it
[09:37] <pitti> Koon: everything is a bit slow, I seem to be a bottleneck for a thousand things, sorry
[09:37] <pitti> Koon: I'll get to it today
[09:38] <Koon> pitti: great, thx
[09:38] <tkamppeter> pitti, I have already uploaded it, as I was assuming that the Feature of driver download was already accepted, due to your Jockey uploads.
[09:40] <tseliot> pitti: but if we did that wouldn't we have to port the new code to older releases of Ubuntu (since they don't have the new jockey)
[09:41] <tkamppeter> pitti, the patch to fix Jockey's search_driver() API change (reopened bug 269311) I have already applied to Jockey. It is a 2-byte patch, only the output signature which you have forgotten. Should I upload it (I only need to debsign and dput)?
[09:42] <pitti> tkamppeter: oh, crap, I forgot that indeed
[09:42] <pitti> tkamppeter: please do, and send me the patch, so that I can incorporate it into bzr
[09:49] <tkamppeter> pitti, jockey_0.5~alpha1-0ubuntu6 uploaded
[09:51] <tkamppeter> pitti, patch sent by mail.
[09:59] <pitti> tkamppeter: thanks
[10:54] <Tonio_> hi there
[10:55] <Tonio_> can someone drop current kdesudo upload in the intrepid pipe ?
[10:55] <Tonio_> it'll ftbfs due to stupid zsh script that corrupted main.cpp...
[11:01] <cjwatson> Tonio_: the archive isn't frozen, so no, we can't
[11:02] <cjwatson> just upload a fix following it
[11:03] <Tonio_> cjwatson: oki but with a orig.tar.gz that changes it'll be rejected right ?
[11:03] <Tonio_> I have to make a patch, probably...
[11:03] <cjwatson> correct. you'll have to patch it
[11:03] <Tonio_> hum ok
[11:03] <cjwatson> (or bump the upstream version number, but you might not want to do that for the usual reasons)
[11:04] <Tonio_> cjwatson: exactly ;)
[11:04] <Tonio_> okay thanks
[11:06] <wgrant> How precisely does an Ubuntu developer break the orig.tar.gz?
[11:06] <Tonio_> wgrant: cause I'm also upstream :)
[11:06] <wgrant> Tonio_: Ah, that would help.
[11:06] <Tonio_> hehe
[11:19] <pitti> tseliot: can bug 251107 be considered as the "reference" bug for "71 and 96 don't work in intrepid"?
[11:21] <tseliot> pitti: yes, that's the one
[12:06] <mdz> sbeattie: regression_tracker.html is very slow to render in Firefox for some reason; do you know why?
[12:11] <mdz> asac: my firefox keeps resizing so that the window title bar and status bar are behind the panels. have you ever seen that happen?
[12:12] <asac> mdz: i have never seen that on my own. i think two days ago someone complained about that though.
[12:12] <asac> mdz: maybe related to compiz?
[12:12] <mdz> asac: certainly possible.  I'm not sure how to debug it though
[12:12] <asac> mdz: are you using firefox in "maximized" window state?
[12:13] <mdz> asac: yes
[12:13] <mdz> asac: of course, I have several other windows maximized (including this one) which behave normally
[12:14] <mdz> so something is different about firefox
[12:14] <mdz> what's better? istanbul or gtk-recordmydesktop?
[12:14] <asac> mdz: ok. but firefox always is that way when maximized? or only sometimes?
[12:14] <mdz> asac: it starts out correct, but then (usually when switching desktops/focus) it suddenly goes behind the panels
[12:15] <mdz> asac: I'll capture a video and file a bug on compiz
[12:15] <asac> mdz: please subscribe me to that bug so i get the mails
[12:16] <mdz> asac: bug 240736 matches my symptoms
[12:16] <mdz> except I don't have a docking station
[12:16] <mdz> I did connect an external VGA on Tuesday, though I don't remember if that's when this started happening or not
[12:17] <asac> mdz: hmm. thats a hardy report even
[12:20] <kwwii> seb128: I was asked to clean out the unecessary/ugly themes from the gnome-themes package. Thought I should ask you first how best to do it
[12:21] <asac> hmm. cant reproduce on hardy with compiz :/
[12:21] <seb128> kwwii: do we real need to do this? that's one of those things which breaks upgrade for people using those themes
[12:22] <seb128> kwwii: the best way is to create a new binary containing those themes, I can do that if you open a bug listing the themes to drop, but that will break upgrades
[12:24] <mdz> asac: see my comment
[12:24] <mdz> asac: I think it's related to xrandr somehow
[12:24]  * asac looking
[12:25] <seb128> kwwii: btw since you are on IRC, could you change the folder-copy and folder-move icons in human-icon-theme to stock_folder-copy and stock_folder-move which are the name evolution is using since hardy (that makes some icons look ugly)?
[12:26] <seb128> kwwii: and did you read the gnome-session bugs? we need icons for the actions there
[12:26] <asac> mdz: is the window really in "maximized" state when you switch back or just maximized, but in normal state (where you can resize it)
[12:27] <mdz> asac: I restarted compiz and can't reproduce, I'm going to try to find a recipe to get it back into the bad state
[12:30] <kwwii> seb128: sabdfl asked me to remove the extra gnome themes, I'll mention the upgrade issue and see what he says
[12:31] <seb128> we already had this discussion before dapper
[12:31] <kwwii> seb128: should I move the icons to those names or just make a symlink to those names?
[12:31] <seb128> as you want, would just be nice to have the stock_ variants available
[12:31] <mdz> asac: I can't get it to happen anymore :-/
[12:32] <seb128> kwwii: renaming should be already, gnome-icon-theme use the stock_ naming
[12:32] <mdz> asac: when I switched back to it, it would be in a strange state.  if I would press F11 twice (as in the bug) it would get it back in the right place, but the window would not be focused
[12:32] <seb128> lunch time, bbl
[12:32] <mdz> asac: and clicking on the title bar would not focus it
[12:32] <kwwii> seb128: ok, I can take care of that
[12:32] <seb128> thanks
[12:32] <kwwii> and I will look into the session bug later today as well
[12:37] <ogra> mdz, in case you want to try something on your Q1 http://www.umpcportal.com/2008/09/ubuntu-mobile-edition-news-and-first-boot-video/ :)
[12:39] <mdz> ogra: I don't have one anymore
[12:39] <ogra> oh
[12:40] <ogra> thats sad ...
[12:41] <amitk> soren: seen any bugs about kvm not giving back the mouse lately?
[12:48] <cjwatson> ogra: looks like an excellent review
[12:48] <ogra> yeah
[12:48] <ogra> i'm drowning in feedback mail :)
[12:49] <mdz> asac: I have got it in the broken state again, can I collect some info for you?
[12:50] <asac> yes. copy localstore.rdf from your profile
[12:50] <asac> mdz: then check whether the window is really in a "maximized" state or if its just maximized, but in resizable state
[12:50] <mdz> asac: I don't know how to tell whether it's truly maximized, because there's no window border
[12:50] <asac> mdz: let me check something
[12:50] <mdz> asac: alt+f10 does nothing
[12:51] <asac> mdz: alt+f8?
[12:51] <mdz> asac: nothing
[12:51] <asac> also try alt + space  and see if the "resize" is greyed out
[12:51] <asac> hmm
[12:51] <mdz> asac: alt+f9 minimizes
[12:51] <mdz> but restoring it puts it back in the same place
[12:52] <mdz> asac: alt+space shows 'unmaximize' option
[12:52] <mdz> but "resize" is not grayed out
[12:52] <asac> mdz: urgh
[12:53] <asac> mdz: so the window is somewhere in the limbo between being "normal" and "maximized" ... strange
[12:53] <asac> localstore.rdf might have some info on what firefox thinks the window is
[12:53] <mdz> asac: emailed
[12:54] <soren> amitk: Doesn't ring a bell, no.
[12:54] <soren> amitk: SDL frontend?
[12:54] <soren> amitk: And when did it start?
[12:57] <asac> mdz: in localstore.rdf the window is correctly in "maximized" state
[12:57] <asac> mdz: howver it still has the dimensions ... which most likely are the dimensions remembered for "normal" mode
[12:57] <mdz> asac: I can't figure out how to get it into this state, though I have succeeded once
[12:58] <asac> mdz: question is why its in a hybrid state for the window manager
[12:58] <mdz> asac: resize is not greyed out for me even when it is in a correctly maximised state
[12:59] <asac> mdz: yeah. my bet is that ffox sets "maximized" and then sets dimensions and compiz gets confused and puts the window in this confusing state
[13:00] <asac> mvo: ^^
[13:00] <asac> mvo: window in compize in "maximized" state still has "resize" enabled in window menu
[13:00] <asac> mvo: but also has the "unmaximize" option
[13:01] <asac> mvo: any idea what might confuse compiz here?
[13:08] <Peaker> hey, what process is required for some python libraries to go into Ubuntu?
[13:09] <kwwii> seb128: that session icon problem is not an icon problem but a code problem (there are two open bugs about it)
[13:10] <kwwii> seb128: the apps/gnome-session-* icons exist (although I found a bug in the spelling of the hibernate icon in the human theme)
[13:10] <seb128> kwwii: not really
[13:10] <kwwii> the arrow which is too small is the actions/refresh* icon
[13:11] <seb128> kwwii: looks like we don't want to use the previous non standard naming square icons
[13:11] <seb128> kwwii: icons used now
[13:11] <seb128> #define GSM_ICON_LOGOUT    "system-log-out"
[13:11] <seb128> #define GSM_ICON_SWITCH    "system-users"
[13:11] <seb128> #define GSM_ICON_SHUTDOWN  "system-shutdown"
[13:11] <seb128> #define GSM_ICON_REBOOT    "view-refresh"
[13:12] <seb128> #define GSM_ICON_HIBERNATE "drive-harddisk"
[13:12] <seb128> #define GSM_ICON_SLEEP     "sleep"
[13:12] <seb128> kwwii: it would be nice to keep those standard names and do symlinks in the icon theme if required
[13:13] <amitk> soren: since Monday I think. I use it through the Virtual Machine Manager UI running an XP in KVM.
[13:13] <kwwii> seb128: yeah, I can make links to the right names...I just did not want to start trying to redraw icons in larger sizes :-)
[13:13] <seb128> kwwii: because gnome-session-* are ubuntu specific naming and that would break other icon theme (the dialog work correctly using clearlooks now)
[13:13] <amitk> soren: and I have kvm-source installed
[13:14] <soren> amitk: Is it possible that it started happening a couple of weeks ago?
[13:14] <soren> amitk: There was a new gtk-vnc upload on the 11th.
[13:15] <kwwii> seb128: cool, I will add the links in the human icon theme package, along with the other stuff you mentioned and a couple of things I just noticed
[13:15] <cjwatson> bryce: apparently http://people.ubuntu.com/~bryce/Milestones/milestones_current.html hasn't been updated for ages - there's a bug listed there that was closed on 27 August
[13:15] <seb128> kwwii: not sure if the old dialog icons will look great in the new dialogs though, the squares for shutdown for example was good in the grid dialog but might not be as good in the new one, I'll let you decide about that though
[13:15] <seb128> kwwii: thanks
[13:16] <amitk> soren: it is possible, I was away in Portland last week.
[13:16] <seb128> kwwii: oh and sorry about the lack of reply on sponsoring, I've been crawling under a montains of GNOME 2.24 update this week and when I wanted to ping you were not on IRC
[13:16] <amitk> soren: so it was part of a huge set of updates
[13:18] <kwwii> seb128: no worries, I found other victims :-)
[13:23] <seb128> TheMuso: are you around to speak about sound themes?
[13:23] <TheMuso> seb128: Certainly am.
[13:23] <seb128> TheMuso: I was wondering if somebody is working on the freedesktop-sound-theme
[13:24] <TheMuso> seb128: In what way exactly? Because it wasn't packaged, I have put it into the ubuntu-sounds package for now. We can split it out in Jaunty.
[13:24] <seb128> oh, that's why it conflicts
[13:24] <seb128> I've it packaged locally using the debian packaging
[13:24] <seb128> and ubuntu-sounds conflict on /usr/share/sounds/freedesktop/index.theme
[13:24] <TheMuso> Oh there is debian packaging? I didn't find it when I originally tried looking for it.
[13:25] <seb128> TheMuso: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486559
[13:25] <seb128> TheMuso: http://git.debian.org/?p=collab-maint/freedesktop-sound-theme.git;a=summary
[13:25] <TheMuso> Oh ok. If you want to bring that into Ubuntu, I can remove it from the ubuntu-sounds package if thats any help.
[13:25] <seb128> I didn't upload because I've been busy and the tarball doesn't ship the licenses which are used which I think will be an issue to get it through NEW
[13:26] <TheMuso> Right.
[13:26]  * TheMuso hecks the upstrea tarball again.
[13:26] <seb128> TheMuso: well, I've to admit I've been too busy to continue on that, if somebody wants to take over the task that would be welcome
[13:26] <seb128> I think it would be nice to have in intrepid
[13:26] <seb128> and I'm not sure adding to ubuntu-sounds is really a thing to do
[13:27] <seb128> did you update the copyright to reflect all that, does it have all the required licenses, etc?
[13:27] <TheMuso> seb128: Nor do I really, but I couldn't think of something better at the time.
[13:27] <seb128> I would much prefer having the freedesktop and ubuntu sound themes as different binaries
[13:27] <TheMuso> This is what I am about to go and chase up.
[13:27] <TheMuso> so would I.
[13:28] <TheMuso> There is a README file in the freedesktop tarball that outlines the origins of the sounds and their licenses, but it doesn't appear there is much more than that.
[13:28] <seb128> right
[13:29] <seb128> TheMuso: do you think you could have a look at getting that upload? or are you too busy right now?
[13:29] <seb128> now not being today but before intrepid
[13:30] <TheMuso> seb128: Yes I could have a look at getting that uploaded, just got to track down copyright/licensing, which may not be easy.
[13:30] <seb128> I think the copyright are ok, as you said they are listed in the readme
[13:31] <seb128> the issue is probably having the corresponding licenses in the tarball
[13:31] <seb128> maybe we should ping lennart about that
[13:31] <TheMuso> Yeah.
[13:31] <TheMuso> I'll jump on the ml for it and ask.
[13:31] <seb128> thanks
[13:32] <seb128> another quick question, are you going to update pulseaudio in intrepid? any reason to not do it? you seem to be backporting patches rather
[13:33] <TheMuso> seb128: Too many users with playback/stream switching issues with 0.9.11/0.9.12. For one, a USB sound card I have completely crashes pulseaudio with newer versions, and another user had issues trying to switch a stream between onboard audio and US speakers. There needs a fair bit of stuff fixed in pulse, as well as alsa for these.
[13:34] <seb128> alright
[14:01] <PecisDarbs> hi people, Intrepid won't have Vinagre 2.24, will it? as I understand, it was released too late. Sad.
[14:04] <cjwatson> PecisDarbs:    vinagre | 2.24.0-0ubuntu1 |      intrepid | source, amd64, i386
[14:04] <cjwatson> i.e. it's already there
[14:04] <PecisDarbs> hmmmmm
[14:05] <PecisDarbs> ok, I updated this morning, maybe it rolled during day
[14:05] <seb128> no, it has been rolled on monday
[14:05] <Burgundavia> PecisDarbs: gnome has a standing upstream freeze exception
[14:05] <seb128> try changing mirror
[14:05] <PecisDarbs> ok
[14:05] <PecisDarbs> thanks for info
[14:05] <Burgundavia> likely it was just that poor seb128 was overworked getting all of .24 in on time
[14:05] <cjwatson> Burgundavia: or read what seb128 wrote ;-)
[14:06] <Burgundavia> cjwatson: is 6am for me, am allowed to be slow
[14:07] <jcastro> evand: has anyone shown interest in backporting usb-creator to hardy? Might be a good way to expand the testing audience.
[14:08] <seb128> jcastro: at this stage intrepid already has quite an audience, usually enough to keep us busy
[14:09] <seb128> jcastro: I'm speaking for desktop at least, not sure about your specific case ;-)
[14:09] <jcastro> seb128: I was just referring to his call for testing, people in the forums were asking if they can test on hardy as well
[14:09] <evand> jcastro: there was a bug filed about a requirement for it and it's something that's been requested more than once.
[14:10] <jcastro> ah, okey
[14:10] <evand> I'll try to find time for a backport of it, though I'm very much focused on bug fixing at the moment.
[14:10] <jcastro> evand: I was hoping to get contribution from someone in the group of people asking.
[14:10] <evand> ah
[14:26] <evocallaghan> Maybe this place will not be full of n00bs
[14:26] <evocallaghan> Hi lads
[14:26] <evocallaghan> What is the LiveCD compressed with ? bzip, gunzip, LZMA ?
[14:26] <ldp> umm
[14:26] <pitti> evocallaghan: gzip
[14:27] <evocallaghan> Someone said to me squashfs
[14:27] <cjwatson> evocallaghan: squashfs uses zlib, which is what gzip is based on
[14:27] <evocallaghan> ok
[14:27] <evocallaghan> Thank you
[14:27] <cjwatson> there is an lzma variant of squashfs, but we don't use that at present (it has even less chance of making it upstream at the moment ...)
[14:27] <ogra> pitti, is there a way to tell hal to re-read a device deliberately ?
[14:28] <pitti> ogra: re-read? you mean re-probe the hardware?
[14:28] <ogra> i have fixed up the touchscreen calibration tool in evtouch ... works fine but you have to restart your session to make xorg accept the change
[14:28] <evocallaghan> LZMA has a bit more overhead
[14:28] <pitti> ogra: haven't tried, but maybe udevadm trigger [some mixture of --subsystem-match and --attr-match]
[14:28] <ogra> so i wonder if there is a way to make that apply on the fly
[14:28] <evocallaghan> I have a working version here
[14:29] <pitti> ogra: well, at worst you could restart hal
[14:29] <ogra> nope
[14:29] <cjwatson> yes, we use it in certain limited contexts (limited exactly because the memory overhead for decompression is high)
[14:29] <ogra> ignored by xorg
[14:29] <pitti> ogra: if restarting hal doesn't help to update the xorg evdev driver, then udevadm trigger won't either
[14:29] <cjwatson> I'd be pretty concerned about the memory overhead for the whole live CD; we only just got the requirements back down inside 256MB, and there's not a whole lot of headroom there
[14:30] <ogra> pitti, evtouch :)
[14:30] <ogra> not dev
[14:30] <cjwatson> requirements for installation from live CD, that is
[14:30] <evocallaghan> Gezz, this place is far more sane then #ubuntu O_o
[14:31] <evocallaghan> Well I am building my own Live opensolaris CD
[14:31] <StevenK> cjwatson: It's back down from the 300 odd it was for Hardy?
[14:31] <ldp> evocallaghan: does that surprise you?
[14:31] <evocallaghan> Just wondering what you guys where using
[14:31] <evocallaghan> ldp:No idea, I don't hang around these parts of the _inter_web :p
[14:31] <ldp> :D
[14:34] <cjwatson> StevenK: yeah, due to compcache
[14:34] <StevenK> \o/
[14:37] <Lazy> Hi, I don't know if this is the right channel but this bug report seems important to me and nobody has commented it. https://bugs.launchpad.net/ubuntu/+source/tor/+bug/261693
[14:39] <jdong> Lazy: well we are well past feature freeze and bordering into beta freeze; is there an extremely important reason why this version is needed over the current shipping version? (i.e. is tor going to stop working for the older client?)
[14:39] <jdong> Lazy: i have to leave pretty soon, but if this is the case then state so on the bug report
[14:40] <apachelogger> pitti: I guess explaining it would be a good improvement already.
[14:40] <ldp> brb people Badminton practice time
[14:41] <Lazy> I'm not sure if it will break but Debian has already included it and it contains several fixes to security
[14:45] <cjwatson> the bug says "major feature enhancements", which is normally a reason for the package *not* to be included after feature freeze
[14:45] <cjwatson> therefore, somebody needs to be more explicit in the bug about the exact nature and importance of the bug fixes
[14:50] <Lazy> cjwatson: Thanks for the clarification. When I get home from work I will write about the bug fixes and new features to the bug report so you guys can decide wether to include the new version or not.
[15:00] <evand> pitti: doko: If you have a free moment, could you please look at MIR bug 268137
[15:16] <kirkland> \sh: hey, saw your blog post, if you add your question to the bottom of https://wiki.ubuntu.com/EncryptedPrivateDirectory, i'll answer it inline there
[15:21] <ykphuah> asac: you there?
[15:23] <MacSlow> kwwii, just wondering ... wasn't initially the white color in NewHuman (used for list-views, icon-views & co) meant to be a bit more greyish?
[15:31] <kwwii> MacSlow: yes, it was
[15:31] <kwwii> but that made default office documents in OOo the same color
[15:46] <liw> kwwii, I've been thinking lately that it would be handy if the dark theme could make the focused window a bit more prominent (and perhaps the current tab in an unfocused gnome-terminal window less prominent)
[15:48] <ykphuah1> asac: you there
[15:49] <asac> ykphuah1: whats up?
[15:49] <ykphuah1> asac: about the patch for NetworkManager
[15:49] <asac> ykphuah1: which?
[15:51] <ogra> Riddell, whats the KDE equivalent of xdialog/zenity ?
[15:51] <ykphuah1> asac: bug 191889
[15:51] <Riddell> ogra: you'd never guess it, kdialog!
[15:51] <ogra> hum
[15:51] <ogra> that doesnt have its own package it seems
[15:52] <ogra> i want to make the touchscreen calibration work on KDE as well ...
[15:52] <ogra> so i need to know the Recommands line
[15:52] <Riddell> it's part of kdebase-bin
[15:52] <ogra> ah
[15:52] <asac> ykphuah1: ah. yeah. thanks for working on that
[15:53] <ogra> sigh
[15:53] <ogra> that gets me 80M
[15:53] <asac> ykphuah: you think you can make a patch that looks for IP being set on unmanaged devices?
[15:59] <radix> mathiaz: Hi, so I made some changes to landscape-config, but it still returns non-0 exit codes
[15:59] <radix> mathiaz: because that makes the most sense for other reasons. are you still happy to add a "|| true" to the command?
[16:00] <mathiaz> radix: how is the "unable to register because d-bus isn't running" scenario handled now ?
[16:01] <radix> mathiaz: a nice message is printed and exit code 2 is returned
[16:01] <radix> instead of a giant traceback
[16:02] <radix> (it still maintains the behavior to record the registration details and will register when the client starts)
[16:03] <james_w> is "#!/bin/sh -e" equivalent to "#!/bin/sh\nset -e" ?
[16:03] <mathiaz> radix: could it be possible to add an option --ok-no-registration so that it returns 0 if the registration isn't successful ?
[16:05] <radix> mathiaz: hmm, thinking
[16:05] <radix> mathiaz: I guess a "--no-register" option is no good because you can't tell whether you're running from the installer or from a regular environment?
[16:06] <mathiaz> radix: right
[16:06] <radix> mathiaz: I can definitely add an --ok-no-register
[16:06] <mathiaz> radix: look at the oknodo option from start-stop-daemon
[16:06] <radix> ok cool
[16:07] <mathiaz> radix: that option as the same purpose for starting daemons in init script
[16:13] <sbeattie> mdz_: I'm unable to reproduce the slow rendering here (3.0.1,hardy) but it's quite likely I'm doing something bogus. I'll poke at it a bit.
[16:17] <mdz_> sbeattie: this is on current intrepid
[16:18] <kwwii> liw: yeah, they might get darker or lighter...or more transparent
[16:25] <superm1> pitti, "not" shipping the handler doesn't have to be the solution right now.  jockey doesn't depend on the modaliases yet, so simply leaving it like that would prevent it from being offered via jockey
[16:26] <pitti> superm1: right that
[16:30] <radix> mathiaz: Ok, I implemented --ok-no-register with unit tests, going to do some more manual testing
[16:30] <mathiaz> radix: awesome ! Thanks for working on this :)
[16:30] <mathiaz> radix: are you going to roll a new release ?
[16:30]  * evocallaghan steps back out to his solaris box.
[16:31] <evocallaghan> Thanks all.
[16:31] <radix> mathiaz: probably, but it's getting tricky
[16:31] <radix> mathiaz: I may have to call it 1.0.21.1 or something
[16:31] <radix> since our trunk has diverged to get some new features
[16:31] <mathiaz> radix: if that's too complicated we can just release a new ubuntu revision of the package.
[16:32] <radix> mathiaz: well, actually, I could just give you a branch with version number changed to 1.0.21.1
[16:32] <radix> mathiaz: the main thing is we want to be able to know what version users are using... we track version numbers in the server
[16:33] <radix> the client uploads its version number, and it'd suck to have two different codebases sending the same version number
[16:33] <mathiaz> radix: ok - then 1.0.21.1 is the way to go
[16:33] <radix> mathiaz: ok, I'll have this branch ready for you as soon as we do a bit oftesting - I need to get into a dbus-less environment
[16:34] <mathiaz> radix: great
[16:41] <pitti> cjwatson: do you know any reason (installer-wise) why the first user should be put into group "fuse"? (I just locally fixed fuse to use our usual "current foreground console" policy for /dev/fuse)
[16:41] <pitti> cjwatson: if not, I'd like to just throw that out again
[16:43] <cjwatson> there's nothing in the installer itself that needs it
[16:43] <pitti> cjwatson: right, I mean I almost fell into some trap with removing cdrom/plugdev
[16:43] <cjwatson> feel free to change it in lp:~ubuntu-core-dev/user-setup/ubuntu
[16:43] <pitti> cjwatson: with the fstab issue for cdroms
[16:43] <pitti> cjwatson: ok, thank you
[16:43] <cjwatson> right, that one is hard
[16:43] <mathiaz> radix: another option to track versions is to integrate the ubuntu revision number in the number reported by landscape-client.
[16:44] <cjwatson> ntfs-3g is the only thing in the installer that needs fuse, and in an installer context it's run as root
[16:44] <pitti> cjwatson: I'm not going to stab cdrom again for intrepid, but this "fuse" thing annoys me
[16:44] <cjwatson> so I think it'll be OK
[16:44] <pitti> \o/
[16:44] <mathiaz> radix: on way to do that is to provide it at build time.
[16:44] <pitti> ♪ another one bites the dust ♫
[16:45] <pitti> cjwatson: we cannot really rely on the user being in that group, but we need to to resolve the mess of libgphoto camera handling in gnome
[16:47] <StevenK> cjwatson: Can you commit and push your changes of livecd-rootfs to the bzr tree?
[16:48] <StevenK> ogra: You too, after cjwatson.
[16:48] <ogra> didnt i push ? oh, sorry
[16:48] <StevenK> Wait, it could be me being idiotic
[16:48] <StevenK> bzr update is a no-op for non-bound branches
[16:49] <ogra> i think i pushed
[16:49] <cjwatson> I use a bound branch for livecd-rootfs, so it's always current
[16:49] <ogra> i remember messing up the tags
[16:49] <StevenK> bzr: ERROR: Tags not supported by BzrBranch5
[16:50] <StevenK> Whee
[16:51] <cjwatson> ogra: so should r207 have tag 0.69 rather than r206?
[16:52] <ogra> i usually dont set DEBEMAIL to force me to look at the changelog before doing dpkg-buildpackage ... so yes, 206 has the right address in the changelog
[16:52] <ogra> errr 207
[16:53] <jdong> StevenK: oh quit whining about that error. It used to be far less intuitive :D
[16:53] <StevenK> jdong: :-P
[16:53] <StevenK> Then bzr was complaining that it couldn't add tags and died.
[16:53] <StevenK> bzr upgrade followed by bzr pull was insisting the tree was up-to-date.
[16:53] <cjwatson> ogra: I've moved the tag
[16:54] <ogra> gracias
[16:54] <ogra> i couldnt anymore after i had pushed i found
[16:54] <StevenK> cjwatson: How did you move it?
[16:54] <ogra> locally i bet :)
[16:54] <cjwatson> bzr tag -r207 --force 0.69
[16:54] <ogra> oh
[16:54] <ogra> meh
[16:54] <ogra> *that easy*
[16:54] <StevenK> I don't get that change here, though
[16:55] <ogra> well, you have a tag anyway
[16:55] <ogra> it just moved places
[16:55] <StevenK> After bzr pull was insisting wrong things, I took a leaf from cjwatson's book and bound it
[16:55] <cjwatson> $ bzr tags -d sftp://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk
[16:55] <cjwatson> 0.68                 204
[16:55] <cjwatson> 0.69                 207
[16:55] <cjwatson> (or bzr+ssh://)
[16:55] <StevenK> bzr update isn't updating that metadata, though
[16:56] <cjwatson> you have two choices: (1) it sounds like a bug, and #bzr might be able to help (2) move your branch aside for future analysis and check it out from scratch
[16:57] <StevenK> Heh, yay. bzr update does nothing, but bzr pull says there are conflicting tags
[16:58] <cjwatson> if you've mucked about with it locally but not pushed, well, you're now diverged; I don't know if merging helps
[16:58] <cjwatson> oh
[16:59] <cjwatson> bzr pull --overwrite (assuming no local changes)
[16:59] <cjwatson> the bzr 0.91rc1 NEWS file says:
[16:59] <cjwatson>    * Overwrite conflicting tags by ``push`` and ``pull`` if the
[16:59] <cjwatson>      ``--overwrite`` option is specified.  (Lukáš Lalinský, #93947)
[16:59] <StevenK> There are local changes, but it's one line
[16:59] <cjwatson> but if you're now bound, 'bzr unbind' first
[16:59] <cjwatson> then bind again after pulling
[17:03] <pitti> seb128: unfuse-ification complete \o/
[17:03] <seb128> pitti: ;-)
[17:08] <ogra> pitti, erm, were these changes tested in environments without polkit and friends (i.e. ltspfs) ?
[17:08] <ogra> there are no fgconsoles for ltsp users ...
[17:08] <pitti> ogra: the fuse group still exists
[17:08] <pitti> ogra: if you are in it, you don't need pk
[17:08] <ogra> ok
[17:08] <pitti> ogra: ah, so you need the installer to put users into fuse?
[17:09] <pitti> s/users/the first user/
[17:09] <ogra> well, users admin
[17:09] <ogra> but that has a patch unless that was dropped
[17:09] <pitti> ogra: if so, I need to revert the installer bit (I woudln't like it, but so be it)
[17:09] <pitti> ogra: I didn't touch users-admin
[17:09] <ogra> right, then its fine ... i can just tell the admin to check the box
[17:10] <pitti> ogra: what I did is (1) create the auto-acl magic for /dev/fuse (it's still root:fuse 660) and (2) change user-setup to not put the initial user into 'fuse'
[17:10] <ogra> err, no i cant since polkit doesnt allow access to users-admin for ltsp users ... hmmm
[17:10] <pitti> ogra: I don't think we can actually get rid of the system group anytime soon, just not put the first user into it/rely on users being in fuse
[17:10] <ogra> does that work for ntfs from initramfs ? afaik there is no ACL applied yet
[17:11] <ogra> (yet as in at that point of booting)
[17:11] <pitti> ogra: the ACL just applies to /dev/
[17:11] <ogra> even in intramfs ?
[17:11] <pitti> the ACL is set by hal once an user starts a session
[17:11] <ogra> (i thounght it requires hal)
[17:11] <pitti> that's way after initramfs
[17:12] <pitti> ogra: unless you actually keep your runtime /dev/ on ntfs all the time?
[17:12] <ogra> but ntfs3g as cjwatson implemented it fires in initrmfs iirc
[17:12] <pitti> *confused*
[17:12] <pitti> ogra: what does ntfs3g have to do with it?
[17:12] <ogra> it uses fuse
[17:12] <pitti> users being in the "fuse" group -> not at all related to things happening in initramfs?
[17:13] <ogra> not sure why or what for, but that was the reason why fuse got pulled into initramfs
[17:13] <pitti> yeah, that's fine
[17:13] <pitti> if your / lives on ntfs, for example
[17:13] <pitti> but that all happens as root
[17:13] <ogra> cjwatson might be able to comment, he made that change iirc
[17:13] <ogra> ah, right
[17:14] <Keybuk> cjwatson: so, err, I just booted the current daily-live
[17:15] <Keybuk> http://people.ubuntu.com/~scott/retro-live-cd.png
[17:17] <ogra> should that also show cu and ram usage ?  :)
[17:17] <ogra> *cpu
[17:17] <ogra> *shouldnt
[17:17] <Keybuk> ogra: I was thinking it should show a big ubuntu logo, and look a bit more like gdm :p
[17:18] <ogra> well ... you cant have everything ...
[17:18] <ogra> :)
[17:18] <Keybuk> there's no Xorg.log, so it doesn't look like it even started
[17:19] <ogra> gdm works on tuesdays build of ubuntu-mobile
[17:19] <ogra> might be X's fault then
[17:19] <tjaalton> can't be if there's no log
[17:19] <ogra> weird
[17:20] <jcristau> it's never X's fault anyway
[17:20] <ogra> lol
[17:20] <ogra> right :)
[17:20] <Hew> Keybuk: Why was bug 189406 changed to wishlist? It is not a cosmetic request, but a regression of a key feature.
[17:21] <ogra> Keybuk, tried startx ?
[17:23] <mvo> Hew: but the version information is certainly still available in the changelog, no?
[17:24] <Hew> mvo: No, it's not. Often (especially in development), the changelog is not available. Also, the current version is not shown. It is very useful to have "version x to version y" displayed for each item. Currently I have to do with with synaptic, so I haven't used update-manager in ages.
[17:25] <mvo> Hew: would you be ok with a gconf key to enable it?
[17:26] <Hew> mvo: I would, as I mentioned in a comment a while ago, but I still think it should be enabled by default.
[17:26] <mvo> Hew: ok, thanks. I will bring it up with our usability person again
[17:27] <Hew> mvo: Thank you. I feel it's important to get this fixed before Intrepid release.
[17:28] <tedg> Keybuk: See, I told you the FUSA applet got moved in more recent live CDs ;)
[17:35] <cjwatson> Keybuk: yeah, we decided that X is for losers
[17:35] <cjwatson> (I'll have a look once I've rsynced to current)
[17:56] <geser> is the beta freeze already in effect?
[17:57] <mathiaz> geser: yes
[17:57] <seb128> mathiaz: since when?
[17:58] <mathiaz> seb128: according to the ReleaseSchedule, it's at 00:00 UTC on the day.
[17:58] <mathiaz> seb128: but may be slangasek hasn't pushed the button yet.
[17:58] <seb128> mathiaz: he hasn't ;-)
[17:58] <cjwatson> https://launchpad.net/ubuntu/intrepid -> "Status: Active Development"
[17:58] <cjwatson> when that's changed, it will say "Pre-Release Freeze"
[18:00] <pitti> tkamppeter: please commit the changes of your cups upload to bzr
[18:04] <NCommander> \o/ - my HPPA intrepid install works
[18:04] <ogra> heh hppa
[18:05] <NCommander> Yes, yes I know
[18:05] <NCommander> I had to ask HP for access to a developers box
[18:05] <NCommander> But now I have root on an Ubuntu intrepid hppa install
[18:06] <NCommander> that's wrong in many ways :-/
[18:08] <tkamppeter> pitti, sorry, forgot the "bzr push"
[18:09] <pitti> tkamppeter: FYI, I just fixed the progress dialog and d-bus timeout if you do a d-bus call
[18:09] <pitti> tkamppeter: (in jockey)
[18:10] <pitti> I guess you stumbled upon that (there was no progress dialog, etc.)
[18:12] <slangasek> cjwatson: it looks like I still don't have access to the button to start the freeze in LP; could you do that now?
[18:13] <tkamppeter> pitti, "bzr push --remember bzr+ssh://till-guest@bzr.debian.org/bzr/pkg-cups/cups/debian-trunk" does not work for me.
[18:13] <tkamppeter> I get
[18:13] <tkamppeter> Format <RepositoryFormatKnit3> for file:///home/till/ubuntu/cups/bzr/debian-trunk/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance
[18:14] <pitti> tkamppeter: that's just a warning, I get it, too
[18:14] <tkamppeter> and then it hangs infinitely.
[18:14] <tkamppeter> Now I got a
[18:14] <tkamppeter> ssh: connect to host bzr.debian.org port 22: Connection timed out
[18:14] <tkamppeter> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
[18:14] <pitti> tkamppeter: does "ssh till-guest@bzr.debian.org" work for you?
[18:14] <pitti> (apparently that's the problem)
[18:15] <pitti> (WFM)
[18:15] <tkamppeter> ssh till-guest@bzr.debian.org
[18:15] <tkamppeter> and nothing happens, probably until the timeout.
[18:15] <cjwatson> slangasek: let me see if I have it ...
[18:15] <pitti> tkamppeter: try with -vv
[18:15] <pitti> slangasek: I always asked in #is
[18:16] <cjwatson> slangasek: nope, I don't seem to have it. You need an LP admin (#launchpad or #is)
[18:16] <slangasek> ah
[18:16] <tkamppeter> OpenSSH_5.1p1 Debian-1ubuntu2, OpenSSL 0.9.8g 19 Oct 2007
[18:16] <tkamppeter> debug1: Reading configuration data /etc/ssh/ssh_config
[18:16] <tkamppeter> debug1: Applying options for *
[18:16] <tkamppeter> debug2: ssh_connect: needpriv 0
[18:16] <tkamppeter> debug1: Connecting to bzr.debian.org [217.196.43.134] port 22.
[18:16] <tkamppeter> and then nothing.
[18:16] <pitti> tkamppeter: ah, please don't quote the entire output, pastebin
[18:17] <pitti> tkamppeter: it works for me; problem with your ISP?
[18:17] <tkamppeter> Can it be that the SSH daemon on bzr.debian.org has crashed?
[18:19] <cjwatson> tkamppeter: no, since it works for others (including me).
[18:21] <slangasek> here we go :)
[18:21] <ogra> oh
[18:21] <ogra> that wasnt in effect yet ?
[18:21] <mvo> weeeh
[18:21]  * ogra thought it was since 00:00 UTC
[18:22] <cjwatson> you should know that advertised times != actual times :)
[18:22] <ogra> as usual
[18:22] <ogra> i just thought i make my generic freeze comment :P
[18:22] <slangasek> :-)
[18:23] <ogra> herdware enablement has a rolling exception, right ? i'm expecting a bunch of fdi files for touchscreen devices after the success of ubuntu-mobile that i'd like to add to the touchscreen driver
[18:23] <tkamppeter> pitti, I can ssh to OpenPrinting
[18:24] <tkamppeter> I can ping bzr.debian.org
[18:25] <pitti> tkamppeter: can you ssh from openprinting to bzr.d.o?
[18:25]  * ogra reboots after dist upgrade
[18:26] <tkamppeter> When I traceroute it, the traceroute ends at trent.core.telegraaf.net (217.196.40.15) and no at 217.196.43.134. But it exits with status 0.
[18:28] <tkamppeter> Doing ssh from OpenPrinting ssh gets much further, it hangs after saying "debug2: we sent a publickey packet, wait for reply", probably because I do not have my private key on OP.
[18:28] <tedg> slangasek: So... I just got told that GIMP is expecting to release 2.6.0 on Monday.
[18:28] <ion_> tedg: Was it the one with GEGL support?
[18:28] <tedg> ion_: I believe so.
[18:28] <pitti> tkamppeter: ssh foo2bzr.d.o asks me for a password, though
[18:28] <ion_> Awesome²
[18:29] <tedg> slangasek: Considering we don't have any of the 2.5.x snapshots in Intrepid -- what's the chance of a miracle?
[18:29] <tedg> :)
[18:30] <tkamppeter> pitti, did a second try on OpenPrinting and now I got to the password prompt. After entering my password I arrived on Alioth.
[18:31] <bdmurray> tkamppeter: we now have cupsys and cups packages receiving bugs in Launchpad.  Is there a need to consolidate these?
[18:32] <tkamppeter> bdmurray, I think so. Many users did not perceive that cupsys was renamed to cups and continue reporting on cupsys.
[18:32] <slangasek> tedg: I'm sure there's a good epistemological answer to that question, somewhere; but as for gimp 2.6 being accepted for intrepid, there'd probably need to be a pretty compelling reason
[18:32] <tkamppeter> It would be a great Launchpad feature to auto-redirect such reports.
[18:33] <pitti> tkamppeter: well, it's still "cupsys" in all stable releases
[18:33] <ogra> yay, my login sound is back
[18:33] <tedg> slangasek: I think the compelling reason would be that every reporter reviewing the release would fixate on it if we didn't have it :-/
[18:33] <tedg> slangasek: Especially if Fedora does.
[18:33] <geser> slangasek: has the beta freeze any effect on packages in universe? like needed exceptions
[18:34] <bdmurray> pitti: I can see it being confusing to have 2 places for bugs though
[18:34] <pitti> right, it is
[18:36] <tkamppeter> pitti, bzr.debian.org returned to work I have uploaded the bzr now.
[18:36] <pitti> tkamppeter: nice, thanks
[18:38] <slangasek> tedg: ah, yes, because those reporters are always disappointed when they can't use the newest gimp features to write their articles, are they :)
[18:38] <slangasek> anyway, it's not like they won't find something else even more trivial to fixate on, that we've overlooke :)
[18:39] <slangasek> geser: nope, see u-d-a
[18:39] <tedg> slangasek: No, more because they're looking for _something_ to say that Fedora is better at ;)
[18:39] <slangasek> heh
[18:41] <tkamppeter> pitti, you told that you "just fixed the progress dialog and d-bus timeout if you do a d-bus call". Did you upload it to somewhere?
[18:41] <pitti> tkamppeter: not yet
[19:09] <slangasek> +test -f /usr/share/acpi-support/state-funcs || exit 0
[19:10] <slangasek> bryce: that's an interesting addition, considering that file is shipped in the very same package :)
[19:11] <bryce> slangasek: it seems that xubuntu replaces the acpi system, but many of these scripts stay in place for some reason
[19:11] <bryce> slangasek: so debian added those checks so the scripts don't trigger if acpi-support has been replaced
[19:11] <slangasek> bryce: ... um.
[19:12] <slangasek> well, I guess these are all conffiles, so they're still present when the package is removde
[19:12] <slangasek> so remove acpi-support + leave acpid installed --> failing scripts <shrug>
[19:13] <bryce> yeah
[19:14] <bryce> it comprised the most #lines in the diff between us and debian, so since it was a trivial change, I figured it was a harmless change that'd at least minimize the size of the diff between us and them
[19:14] <bryce> plus if it helps xubuntu, why not
[19:14] <bryce> although I'd guess by now they must have gotten some other way to work around it
[19:17] <ogra> slangasek, please let xf86-input-evtouch through ...
[19:18] <ogra> (universe)
[19:18] <didrocks> norsetto: I really think that vuntz can really be a great help on the update page :-)
[19:20] <superm1> why does xubuntu not use acpi-support in the first place though?
[19:22] <superm1> bryce, and looking at the rdepends, acpi-support is still part of xubuntu-desktop in the first place?
[19:24] <slangasek> I think the rationale given there is a bit mangled, really
[19:24] <slangasek> the real issue is that you can remove acpi-support and it will leave behind the conffiles, which should play as nicely as possible
[19:24]  * bryce nods
[19:24] <pitti> slangasek: I fixed the spawning of the "searching driver" progress dialog in jockey, and updated translations; is that still ok for beta, or do you just accept beta-milestoned fixes now?
[19:25] <slangasek> pitti: I'll take that one, at least today
[19:26] <bryce> sorry I misrembered it as "xubuntu", it was for eeepc-acpi-scripts
[19:26] <bryce> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469556
[19:28]  * ogra goes out for dinner
[19:30] <superm1> they couldn't just adapt the existing acpi-scripts for eee support?  yick..
[19:30] <slangasek> that's a bit dodgy, yes :)
[19:51] <pitti> slangasek: ok, uploaded; shall I ack it myself, or do you want to review it?
[19:52] <slangasek> if it's not urgent, I can review it later today
[19:52] <pitti> ok, thanks
[19:57] <slangasek> pitti: are you able to confirm the comment in bug #274085 that ekiga is part of gnome (i.e., standing exception)?
[20:06] <tedg> slangasek: I don't believe that Ekiga is part of GNOME.
[20:06] <slangasek> tedg: hmm, it's featured prominently at http://library.gnome.org/misc/release-notes/2.24/#rnusers.ekiga
[20:07] <tedg> And it's in GNOME SVN...
[20:07] <Treenaks> but its version is a bit off
[20:07] <tedg> It's not on this list: http://www.gnome.org/projects/
[20:07]  * NCommander pokes landscape with a stick
[20:07] <tedg> But, well, Sodipodi is :)
[20:08] <slangasek> tedg: right, and so is xmms... :)
[20:08] <slangasek> actually, GNOME meeting is listed there too :)
[20:08] <pochu> tedg: it's in the desktop set: ftp://ftp.gnome.org/pub/gnome/desktop/2.24/2.24.0/sources/
[20:09] <Treenaks> that _is_ a limited set..
[20:09] <pochu> but it's part of GNOME
[20:09] <pochu> and ekiga is part of the Desktop set
[20:09] <pochu> so ekiga is part of GNOME ;-)
[20:10] <slangasek> right, so I guess the only real question is whether the desktop team is going to take responsibility for updating it for beta :)
[20:10] <Treenaks> slangasek: all we need is a milestoned bug ;)
[20:17] <Treenaks> Should I report it as a bug that the ati driver has probed my display 1168 times in 1 session?
[20:17] <Treenaks> and continues to do so, every few minutes?
[20:18] <norsetto> didrocks: well, what I need now is somebody that can design a decent html page ;-)
[20:28] <pitti> re
[20:28] <terminator_> tseliot  When will the 96.43.07 drivers for nvidia cards be ready
[20:28] <pitti> slangasek: hm, so far I didn't think it was
[20:29] <pitti> slangasek: hm, http://ftp.acc.umu.se/pub/gnome/sources/ekiga/3.0/, interesting
[20:29] <tseliot> terminator_: I wish I knew it...
[20:30] <pitti> slangasek: but ok, its presence in ftp://ftp.gnome.org/pub/gnome/desktop/2.24/2.24.0/sources/ convinces me
[20:30] <terminator_> tseliot I can't wait to try them out with my old machine.
[20:30] <pitti> slangasek: I just find it worrying that we didn't get 3.0 alpha/beta releases, as with all the other gnome components (that worries me more than being/not being part of official gnome)
[20:30] <elmo> O  [  26: Damien Sandras      ] Ekiga branched for GNOME 2.24
[20:31] <pochu> pitti: and whether they will release point updates with the rest of GNOME ;)
[20:31] <elmo> from desktop-devel-list@gnome.org, cc'ed release-team@gnome.org, for whatever that's worth
[20:31] <terminator_> tseliot thanks
[20:33] <tkamppeter> pitti, I have added a patch for python-cupshelpers to bug 269454.
[20:40] <alex-weej> i accidentally the Guest user
[20:40] <alex-weej> is that bad?
[20:41] <alex-weej> *deleted* :P
[20:41] <alex-weej> did it via the users-admin
[20:41] <pitti> alex-weej: it will be recreated automatically
[20:41] <alex-weej> i actually thought i had created it myself
[20:41] <alex-weej> because my guest session wasn't working - it would load the wallpaper and that was it
[20:41] <alex-weej> but when i deleted the user it started working
[20:42] <alex-weej> though gnome-settings-daemon seems to fail. i get the inbuilt GTK theme
[20:42] <alex-weej> and also when i switched back to my normal user
[20:42] <alex-weej> it locked the guest session
[20:42] <pitti> alex-weej: did you have a real (uid >= 1000) "guest" user before?
[20:42] <alex-weej> and wanted a password to unlock ....
[20:42] <pitti> alex-weej: locked> known bug
[20:42] <alex-weej> ok
[20:42] <slangasek> pitti: yes, it worries me as well; but are we better off holding back ekiga than updating it for beta?
[20:42] <alex-weej> guest:x:121:1001:Guest,,,:/tmp/guest-home.m12816:/bin/bash
[20:43] <pitti> slangasek: if we want to have it in intrepid, I'd rather have it now than post-beta
[20:43] <slangasek> yes, by "holding back ekiga" I meant "holding back ekiga for release" :)
[20:43] <pitti> is there a PPA we can test?
[20:43] <pitti> oh
[20:44] <slangasek> a ppa of ekiga? not AFAIK :/
[20:44] <infinity> pitti: I would argue that 2.9.xx was "3.0 beta", given the version scheme.
[20:45] <pitti> slangasek: it would violate just about every freeze we have, plus require a lot of work which we better spend on other things now, so I lean towards "no" tbh
[20:45] <alex-weej> pitti: i have a /home/guest folder --- so i guess i created that user myself?
[20:45] <pitti> infinity: yes, it would be, if only it was in intrepid---we have 2.0.12
[20:45] <slangasek> pitti: well, GNOME also routinely violates the freeze, the difference being that it violates it incrementally via the betas :)
[20:45] <pitti> alex-weej: yes, the gdm guest session uses /tmp/
[20:45] <infinity> pitti: Yeah, I see that.  :/
[20:45] <alex-weej> ekiga should get on gnome release cycle...
[20:45] <slangasek> s/GNOME/the rest of &/
[20:46] <infinity> pitti: I was just responding to the "I never saw any betas" comment.
[20:46] <seb128> what is the discussion about?
[20:46] <alex-weej> ekiga 3 in intrepid
[20:46] <pitti> infinity: yeah, I meant "in intrepid"
[20:46] <slangasek> seb128: bug #274085
[20:46] <seb128> ubuntu lacks somebody interested in maintaining ekiga
[20:46] <seb128> especiall the broken libs it depends on
[20:46] <slangasek> seb128: ekiga is apparently part of GNOME 2.24, but there haven't been any updates to the pre-releases ... ah :/
[20:46] <seb128> but updating to ekiga3 would be a good idea
[20:47] <seb128> slangasek: right, I think technically it's in the GNOME desktop set, they just suck at rolling tarballs and have broken libs and nobody seems to be interest in working on updating it for debian or ubuntu
[20:47] <slangasek> hrm, what are the broken libs?
[20:47] <seb128> dholbach was doing it for a while but nobody else picked since
[20:48] <seb128> slangasek: apparently ptlib is doing weird things, ask dholbach when he's around, he complained a lot while he was doing the update
[20:48] <slangasek> oh, just ptlib then :)
[20:49] <elmo> I remember their packaging from debian as being, err junichi inspired
[20:49] <seb128> libopal could be in the same case
[20:51] <seb128> elmo: hey, any way to have python-apt it the hardy environment on ronne? I would like to have a go at restarting the hardy retracers now
[20:51] <infinity> seb128: I can do that.
[20:51] <seb128> elmo: I'll file a r-t and give it a try later otherwise, there is no real hurry
[20:51] <seb128> infinity: that would be nice thanks, the i386 and amd64 hardy chroots on ronne
[20:51] <slangasek> seb128: the libraries don't concern me, then, so much as the lack of anybody keeping an eye on it and the absence of pre-release testing in Ubuntu
[20:52] <slangasek> if we do update it to 3.0, will someone from desktop keep an eye on it?
[20:52] <slangasek> (and for that matter, who will do the update?)
[20:52] <seb128> slangasek: I know upstream is unhappy about us shipping outdated version and we already had some explanations rounds about that
[20:52] <infinity> seb128: Done.
[20:53] <seb128> slangasek: I was talking about that to lool today, upstream has snapshot for ubuntu, would be nice to have whoever is doing those working directly in ubuntu
[20:55] <slangasek> pitti: oh, it appears there is a ppa: https://launchpad.net/~sevmek/+archive
[20:55] <seb128> slangasek: really try to talk to lool about it, he has been testing the recent snapshot for mobile apparently
[20:55] <slangasek> ok
[20:55] <slangasek> lool: ping (but I'm out to lunch now, so take your time responding :)
[20:56] <seb128> I think he's the best placed to give you an opinion on the new version
[20:56] <seb128> infinity: thanks for the ronne install ;-)
[20:57] <norsetto> hi seb128
[20:57] <seb128> hey norsetto
[21:05] <radix> mathiaz: hi
[21:05] <radix> mathiaz: I think I have a branch ready for you
[21:06] <radix> mathiaz: with the caveat that it seems a traceback will still be printed :(
[21:06] <mathiaz> radix: ok - I'll have a look at it then
[21:06] <radix> it's awkward, because a traceback is actually being printed by landscape-client itself
[21:06] <radix> when landscape-config tries to start it
[21:07] <mathiaz> radix: the traceback is not such a big issue.
[21:07] <mathiaz> radix: the main point is that the postinst script doesn't fail if the registration cannot be completed.
[21:07] <radix> right ok
[21:07] <radix> that is definitely the case now
[21:07] <mathiaz> radix: and I'd try to avoid adding || true to the script
[21:08] <radix> mathiaz: the branch is lp:~radix/landscape-client/minor-intrepid-fixes
[21:08] <radix> mathiaz: it has one minor change unrelated to landscape-config: a lowering of a timeout related to package management in landscape
[21:08] <radix> it doesn't actually change any functionality, just makes it so errors about package management are reported much more quickly (~1h instead of ~1d)
[21:12] <sbeh> hi, "localedef --no-archive --magic=20051014 -i en_US -c -f UTF-8 en_US.UTF-8" hangs at 100% cpu reproducable and "strace -p `pidof localedef`" gives no output, what can i do to determine whats causing this problem?
[21:21] <james_w> is http://paste.ubuntu.com/50619/ an abomination that should never see the light of day?
[21:21] <lool> slangasek: pong
[21:24] <lool> james_w: That looks clean to me, but what does it fix?  Was it run by upstream?
[21:24] <james_w> lool: no, it wasn't yet
[21:25] <james_w> the configure script sets HAVE_DECL_GETPWNAM, and then the code checks for HAVE_GETPWNAM
[21:25] <james_w> that patch makes it set both
[21:25] <james_w> I think perhaps just having the code check for HAVE_DECL_GETPWNAM might be cleaner
[21:25] <james_w> it's fixed in the new upstream, but the patch seems a little larger than necessary
[21:26] <lool> james_w: I guess the HAVE_DECL_GETPWNAM stuff should be dropped -- unless it has special per-arch handling, in which case you want to fix this part rather than piggy-backing on the AC_CHECK_FUNC
[21:26] <lool> or FUNCS
[21:26] <james_w> I don't think there's any special handling, comments indicate it's for migw32
[21:26] <lool> james_w: Ah it's fixed in a new upstream which renames the ifdef and all?  Then I don't think it matters either way, but it's perhaps clearer to use their fix
[21:27] <james_w> the new upstream still sets the _DECL_ one, but also sets HAVE_GETPWNAM and only uses that
[21:30] <lool> james_w: Ok; if the DECL one isn't used in the source anymore, feel free to only grab the fix for the HAVE_GETPWNAM ifdef only for now; sounds good
[21:30] <radix> mathiaz: I bumped the version number to 1.0.21.1 in that branch but haven't touched anything in debian/
[21:30] <mathiaz> radix: right - I'm looking at it now.
[21:30] <mathiaz> radix: I guess you'll publish it a new tarball soon.
[21:31] <radix> mathiaz: yeah I'll put one up on launchpad
[21:45] <pitti> hm, https://wiki.ubuntu.com/UbuntuWorldWide is pretty emtpy ...
[21:47] <pitti> kwwii: any chance you could mail me your jockey icon svgs soon?
[21:47] <pitti> kwwii: (I think you have them ready already, and just forgot to send them)
[21:47] <IntuitiveNipple> Keybuk: ping
[21:48] <tkamppeter> pitti, I have upstreamized the s-c-p Jockey client patch now.
[21:50] <tkamppeter> pitti, and s-c-p is now ready for your driver descriptions as in bug 269454
[21:51] <pitti> tkamppeter: rock, thanks! you can upload s-c-p, btw, it'll just undergo review
[21:52] <tkamppeter> pitti, on the two screenshots of your Jockey release announcements I have seen a small UI flaw: You explain to dumb GNOME users what "proprietary" means but assume that KDE users are the absolute experts and do not explain it.
[21:53] <pitti> tkamppeter: good point, you just found a bug in the KDE UI
[21:54] <pitti> tkamppeter: something to fix tomorrow, though, I'll go to bed now
[21:54] <tkamppeter> pitti, s-c-p uploaded, do I have to report a bug and subscribe someone to it?
[21:55] <pitti> tkamppeter: just filing a bug about the missing window subtitle myself
[21:55] <pitti> tkamppeter: for s-c-p? the changelog should refer to #269454
[21:55] <tkamppeter> pitti, I mean for a beta freeze exception
[21:55] <pitti> tkamppeter: no, that's fine
[21:56] <pitti> tkamppeter: bug 274558, FYI
[21:57] <pitti> good night everyone!
[22:02] <slangasek> lool: hi, did you see the discussion above about ekiga?
[22:03] <lool> slangasek: Not the above one, I had one with seb128 earlier on #ubuntu-desktop; scrolling back now
[22:03] <slangasek> ok
[22:04] <lool> slangasek: Right, so what I was saying was that the architectural, UI, and general changes in the new ekiga are really worthwhile to try to get; I mentionned UI as one point where we'd need some doc team ack first though
[22:05] <lool> My testing showed a very broken ekiga back then, but most issues I raised were either already fixed or fixed subsequently
[22:05] <lool> It would need some retesting now
[22:05] <slangasek> lool: well, the UI freeze as currently structured doesn't require doc team ack, just notification
[22:05] <slangasek> the bigger issue is that we're now all the way into beta freeze, and there doesn't seem to have been any activity on getting the new version into intrepid (until now)
[22:05] <lool> I know opal/ptlib have historically been a pain to deal with, but the upstream changes should make them less painful hopefully
[22:05] <slangasek> upstream changes in opal/ptlib?
[22:05] <slangasek> or in ekiga?
[22:06] <lool> In opal/ptlib
[22:06] <lool> They worked on the build system somewhat
[22:06] <slangasek> does that mean we need to pull new upstream versions of those libs for this ekiga drop, or does it mean there are already upstream fixes in intrepid for those problems?
[22:07] <lool> Hmm usually you need to update ptlib, opal, and ekiga to the latest versions as a chunk
[22:07] <ogra> lool, hmm, yeah, i think the desktop-common task is what pulls in the stuff to mid
[22:08] <lool> Concerning the build changes, I don't know their substance but I do know that I had many issues with the build of these libs in the past and would welcome progress on the build scripts :)
[22:08] <lool> ogra: See!  :)
[22:08] <ogra> so let me drop that from the seeds for you
[22:08] <lool> ogra: So we use some lower level seed for hardy's mid/mobile and for intrepid's seeds (until now)
[22:09] <lool> ogra: Perhaps you should use the same thing as structure?  I don't know what the field is used for, but we should look it up
[22:09] <ogra> right, but you will likely run into the same probs i had if you add packages that have recommends
[22:09] <ogra> i know the mobile seed is fine now, colin fixed it, i trues him in that regard :)
[22:09] <ogra> *trust
[22:10] <lool> slangasek: I need to grab all this stuff if you want a more in depth look at it; I agree with prior comments here that we need someone caring more about this GNOME substack, it didn't see enough love
[22:10] <lool> (and that's true in Debian as well BTW)
[22:10] <ogra> oh, mid uses minimal in STRUCTURE :)
[22:10] <lool> ogra: Yeah
[22:10]  * ogra adjusts
[22:11] <ogra> sorry, that was my fault ... i just copied the task headers from mobile without checking
[22:12] <slangasek> lool: do you know if ekiga works right with alsa bluetooth yet? :)
[22:13] <ogra> slangasek, btw, i think uswsusp breaks with usplash or something like that, i remember i discussed it before with matthew
[22:13] <lool> slangasek: I should have all the hardware to test now, but never tried that yet
[22:14] <slangasek> ogra: right, that sounds familiar
[22:14] <slangasek> lool: hmm, perhaps I should test here; last time I tested that was with hardy
[22:14] <lool> slangasek: I think this ekiga and libs update deserves some formal ppa preparation and mini testing
[22:14] <lool> despite being GNOME stuff
[22:14] <slangasek> agreed
[22:14] <lool> The only open question would be whom lalala
[22:14]  * lool looks around
[22:15] <lool> Ah crap, I just walked over this bluetooth headset
[22:15] <ogra> heh
[22:15] <ogra> hmm, so ubuntu.mobile doesnt seem to install grub
[22:16] <ogra> according to my users the install works flawless ... but they end up with error 15 after reboot
[22:16] <ogra> was that the same issue persia had ?
[22:16] <lool> ogra: THat's the meta kernel image missing I think
[22:16] <ogra> with mid ...
[22:16] <lool> ogra: But are you building wiht lpia?
[22:16] <ogra> nope
[22:16] <lool> I thought your image was i386
[22:16] <ogra> generic
[22:16] <lool> Ah
[22:17] <ogra> but the error seems the same ...
[22:17] <lool> ogra: Blah then it's likely we have an unrelated issue from the meta
[22:17] <ogra> i'm not sure but we might need the grub-.install thingie from d-i in pool on the image ...
[22:17]  * ogra thinks he remembers something similar being on the livecd
[22:18] <ogra> hmm, no
[22:18] <ogra> only oem-config there
[22:18] <lool> Could you frobble with this thingie and see if it helps?
[22:19] <ogra> i will, but not tnight anymore
[22:19] <lool> Oh sure
[22:19] <ogra> i'll donate my workday to it tomorrow ... i want an installable ubuntu.mobile now that the seed is fixed
[22:20] <lool> ogra: Did you push the new mobile-meta?
[22:20] <ogra> the task fix, i'm still running update
[22:20] <lool> pedal harder
[22:21] <ogra> oh, great ... the fdi i got for evtouch for fijitsu was taken with a device where the touchscreen was switched to wacom mode in the BIOS
[22:21]  * ogra headdesks
[22:21] <ogra> the user just sent me a fixed lshal
[22:22]  * ogra sees slangasek hasnt approved xf86-input-evtouch yet ....
[22:22] <ogra> slangasek, can you reject it so i save a version number ?
[22:23] <slangasek> hum, ok
[22:23] <slangasek> yes, rejecting
[22:23] <ogra> thanks :)
[22:23] <ogra> i'll upload a new one before going to bed
[22:23] <slangasek> ok
[22:23]  * ogra hates to add HW info for devices he doesnt have the HW for to check ...
[22:24] <ogra> i wouldnt be a good hal maintainer ... i truest what people mail me :o)
[22:24] <ogra> lool, didnt fix it :/
[22:24] <ogra> lool, http://paste.ubuntu.com/50629/
[22:24] <ogra> though its less now
[22:25] <ogra> oh, well, and it has such unimportant stuff like udev in it ...
[22:25] <ogra> i guess its right
[22:26] <ogra> please check that list, if you agree i'll upload
[22:26] <lool> ogra: Might be the result of other seed updates in the minimal set
[22:26] <ogra> it all looks reasonable
[22:26] <lool> It really looks like it comes from that task header though
[22:27] <ogra> well, you surely want things like lsb-release or module-init-tools
[22:27] <lool> ogra: I don't quite see why these should be pulled by ubuntu-mobile; they are pulled by ubuntu-minimal already
[22:28] <ogra> Added ubuntu-minimal to mid
[22:28] <ogra> i guess thats why
[22:28]  * lool wonders what netcat does in minimal
[22:28] <ogra> i use it in ltsp ... but i think it was there before
[22:29] <lool> Sounds like standard
[22:29]  * ogra cant remember writing a MIR at least
[22:29] <lool> "eject" blah
[22:30] <ogra> well, gnupg and initramfstoold make sense :)
[22:30] <lool> ogra: Anyway, I don't understand enough what the headers do at the top of the seed and these new deps sound bogus to me
[22:30] <lool> ogra: Other meta packages don't depend on this stuff
[22:30] <ogra> *initramfs-tools
[22:30] <ogra> its the deps of minimal
[22:30] <lool> ogra: I wonder whether you should rather use mid / mobile in this task header
[22:31] <lool> ogra: But we don't want to have the deps of minimal, we only want minimal to be installed and do its job I think
[22:31] <lool> ubuntu-desktop doesn't depend on these, nor even on ubuntu-minimal
[22:31] <ogra> desktop definately pulls in minimal
[22:32] <lool> The seed, but not the package?
[22:32] <ogra> yeah
[22:32] <ogra> the task :)
[22:32] <lool> Exactly, so I don't see why we should add his list of deps to ubuntu-mid or mobile meta
[22:33] <ogra> well, i can drop the task header from mid
[22:33] <ogra> shall i ?
[22:33] <lool> Well shouldn't it read "mid"?  I don't know what it does, so I really can't tell
[22:33] <lool> ogra: Shall I grab some doc and read up what it's for?
[22:34] <ogra> lool, if you know where thats documented
[22:34] <lool> It replaces the seed_map/seed thing
[22:35] <lool> man/germinate-update-metapackage.1
[22:37] <ogra> lool, doesnt talk abotu tasks in seed headers
[22:38] <lool> It's used in update-metapackage.py, seed_packages() to select mapped seeds
[22:39] <lool> Perhaps it's used in other software as well too
[22:40] <lool> ogra: Anyway, it looks like for desktop this allows pulling the desktop-common packages as additional direct deps of the desktop meta
[22:40] <lool> ogra: And we don't need that
[22:40] <ogra> not in mid
[22:40] <lool> ogra: So either not having the header or listing the seed name in the header is the correct thing to do here I think
[22:40] <lool> ogra: Unless we want some mobile-common or mid-common
[22:41] <ogra> nah, i want mobile to be the same as desktop with slight modifications
[22:41] <lool> I think we don't need the header as the header in desktop only lists common
[22:41] <ogra> but mid is indeed a different thing
[22:42] <lool> Grmpf, someone decided to remove "unused" seeds
[22:42] <ogra> so i'll keep it in desktop and drop it completely from mid ... but dont shout at me if you end up with recomends you didnt want
[22:42] <ogra> i think that was persia
[22:42] <ogra> though StevenK merged it
[22:42] <lool> Yeah, read that
[22:42] <lool> ogra: Why would we end up with recommends we didn't want?
[22:43] <ogra> becaue you have no task handling anymore without the headers
[22:43] <lool> ogra: I don't quite know what pushed you into adding the headers, perhaps you want to double check with cjwatson tomorrow what they are for, and which ones to drop?
[22:43] <ogra> the task makes sure that seed deps are fulfilled first
[22:43] <lool> ogra: We don't need to remove all headers, just the last one...
[22:44] <lool> Task-Seeds
[22:44] <ogra> ah, k
[22:44] <ogra> pushed
[22:45] <lool> ogra:  mid -> MID sounds (Mobile Internet Devices, it's spelled MID on wikipedia as well)
[22:45] <lool> +better
[22:47] <ogra> pushed too
[22:48] <lool> ogra: Check e.g. the server seed, it doesn't have this Task-Seed header
[22:49] <ogra> lets see ...
[22:49] <ogra> update is running
[22:53] <lool> ogra: Hmm you didn't fix the mobile seed
[22:53] <lool> (I did)
[22:54] <ogra> huh ?
[22:55] <ogra> the mobile seed is fine as colin set it up
[22:55] <lool> It was using Task-Seeds desktop-common
[22:55] <lool> Oh that's actually what you want
[22:55] <ogra> right
[22:56] <ogra> desktop-common != ubuntu-desktop
[22:56] <lool> ogra: As I was saying above, you might want to reconsider that choice
[22:56] <lool> Yeah, I know how desktop-common is used right now
[22:56] <ogra> ok
[22:56] <lool> pushed the readdition, sorry
[22:56] <ogra> well, i wonder how that affects my currently running update of meta
[22:57] <ogra> ../mobile-meta-1.116
[22:57] <ogra> Added landscape-common to mobile-recommends
[22:57] <ogra> Added linux-headers-lpia to mobile-recommends [lpia]
[22:57] <ogra> Added powernowd to mid-recommends
[22:57] <ogra> looks better :)
[22:57] <ogra> shall i upload ?
[22:57] <lool> Sure
[22:57] <ogra> okidokie
[22:57] <lool> ogra: What I was saying earlier is that desktop-common is higher level and pulls in lots of stuff
[22:58] <lool> So you will end up running syslog, or having tools that you don't care about etc.
[22:58] <ogra> lets see what i get
[22:58] <ogra> i dont think syslog is wong ...
[22:58] <lool> And one of the targets was to shrink the image size to a minimum
[22:59] <ogra> well, i actually want ubuntu-desktop with different setup and themeing for mobile
[22:59] <ogra> and dropping some toplevel apps
[22:59] <lool> I think it depends, but I tend to agree with people not running syslog on their phone, I'd be inclined not to install in on mids, and probably wouldn't be sure of the point in netbooks
[22:59] <ogra> but benefit from the work the distro team does on the rest of the seeds, so i dont have to care
[23:00] <ogra> you dont want ubuntu.mobile on a phone :)
[23:01] <kwwii> pitti: yes, I can send them to you once I clean them up...still not happy with the open source icon but I have the svg's...do you need png files for different sizes?
[23:01] <lool> What I'm trying to say is that the two end of the scales exist: phones and laptops, and there's a point where you definitely don't want things like syslog
[23:01] <ogra> i know the oem team has patches to syslog to log a lot less
[23:01] <ogra> and for jaunty i want to review these patches and include tehm where they are suitable
[23:02] <ogra> i dont even run syslog here on my lappie ... for startup speed reasons ...
[23:02] <ogra> on SSD netbooks/MIDs you definately want a special policy that makes them write less frequently
[23:03] <ogra> lool, we need someone to approve the upload btw (beta freeze)
[23:04] <lool> yup
[23:06] <ogra> slangasek, ^^^ one mobile-meta approval waiting for your powers ... btw is there anyone else beyond you i can bug ... feels odd to put everything on your sholders (or do you prefer to have total control ?)
[23:07]  * lool pictures the "Total Control" keyboard in slangasek's basement
[23:09] <ogra> the two key kbd with fist sized buttons "yay" "nay"
[23:09] <sleepster> how can I add a package to the ubuntu repositories?
[23:10] <ogra> sleepster, https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[23:10] <sleepster> thanks
[23:17] <kwwii> pitti: I just sent you the svgs per email
[23:20] <slangasek> ogra: anyone else in ubuntu-release can also approve things :)
[23:21] <slangasek> (but this time of day, I think that's just me, for all intents and purposes)
[23:21] <ogra> ok
[23:21] <ogra> i think that question is as generic as my traditional freeze comment :)
[23:22] <bryce> cjwatson: btw, the milestones page moved here:  http://bryceharrington.org/X/Milestones/
[23:22] <bryce> cjwatson: elmo had asked that scripts not scp stuff to people.ubuntu.com anymore, so I've had to migrate all my scripts onto my own HW now
[23:22] <bryce> I've stuck a redirect in
[23:27] <IntuitiveNipple> bryce: ping
[23:29] <slangasek> pitti: do you have any idea about this console-kit crasher bug?
[23:30] <mathiaz> slangasek: could you have a look at bug 274573 and let me know if that suits a BetaFreeze Exception ?
[23:34] <slangasek> mathiaz: rather large set of changes to test_configuration.py, no changelog explaining why they're needed?
[23:34] <fta> I have a problem with python-gnome2-extras-dev (not installable) http://launchpadlibrarian.net/17965516/buildlog_ubuntu-intrepid-i386.miro_2.0~svn20080925r8059-0ubuntu1~fta1_FAILEDTOBUILD.txt.gz
[23:34] <mathiaz> slangasek: they're test cases for the option that has been added.
[23:35] <slangasek> mathiaz: I meant the 'filename' stuff, but it looks like this has just been refactored
[23:35] <slangasek> mathiaz: yes, looks ok
[23:36] <radix> sorry yeah, I was getting really annoyed by the duplication in those tests
[23:36] <slangasek> :)
[23:36] <radix> I probably should have delayed the refactoring
[23:38] <mathiaz> slangasek: ok - uploading.
[23:40] <bryce> IntuitiveNipple: yeah?
[23:41] <bryce> IntuitiveNipple: fwiw, it's better to just ask a question rather than pinging.  If I'm around I can answer it immediately without waiting for another roundtrip with you.  If I'm not around, then others can have a shot at answering it.
[23:42] <IntuitiveNipple> bryce: do you have 5 mins to give me an insight into libxft2, re bug #145244 - I've got a user in south-africa I'm doing remote support for. Hardy updated to 2.1.12-2ubuntu5 and since then gdmgreeter goes mad and they can't log-in. (this is on i386)
[23:43] <IntuitiveNipple> bryce: I suspect it is specific to your knowledge of the latest patch, from the changelog
[23:45]  * bryce looks
[23:47] <IntuitiveNipple> bryce: I've been back-tracing the source-code after capturing the symbol-not-found issue with strace, and one thing I did notice was it looks like the liXft... patch doesn't actually do anything since it depends on #ifdef FC_LCD_FILTER which isn't set anyplace
[23:48] <IntuitiveNipple> s/liXft.../libXft.../
[23:49] <bryce> which patch is this?
[23:49] <IntuitiveNipple> bryce: I'm just pinning the package back to the previous version to test
[23:49] <IntuitiveNipple> the patch that doesn't seem to actually get used is libXft-2.1.10-lcd-filter-3.patch
[23:50] <IntuitiveNipple> bryce: it is applied... but what's in it doesn't look to be #ifdef-ed in - i've not gone as far as capturing the preprocessor output yet though
[23:51] <IntuitiveNipple> but that patch is instrumental in the symbol_not_found FT_Library_SetLcdFilter that causes gdmgreeter to endlessly spin and fail without drawing the log-in dialog
[23:52] <bryce> Intuitive, hmm looks like you're right.  I didn't author the patch though; I just did a merge to debian and kept it in.  Keybuk is probably the better one to ask about it
[23:53] <IntuitiveNipple> bryce: no, I realise that, but I just wondered if you might save me some brain-frying with any insight
[23:53] <IntuitiveNipple> I pinged Keybuk earlier but no reply so far
[23:53] <IntuitiveNipple> I'm pinning the user's packages back to the previous version now, see if that solves it
[23:53] <IntuitiveNipple> I'll also update that bug report
[23:53] <bryce> well, probably the easiest thing would be to just slap more #ifdef's around the use of that symbol
[23:54] <IntuitiveNipple> My solution here was to add to CFLAGS += -DFT_LCD_FILTER so that code is added
[23:54]  * bryce looks some more
[23:55] <bryce> does that make the issue go away?
[23:55] <IntuitiveNipple> and strangely that builds for me on my amd64, but *not* on the user's i386 :)
[23:55] <IntuitiveNipple> well,it would make sense, because with that defined, the code in the patch is included, which causes libXft to be dyn-linked to libfreetype6 which contains the missing symbol
[23:55] <bryce> hmm, from what I can see, that define shouldn't make a difference
[23:56] <bryce> ah, dynamic linking.  hmm
[23:56] <IntuitiveNipple> yeah, it's a minefield!
[23:56] <IntuitiveNipple> my brain is fried trying to get up to speed on it
[23:56] <slangasek> pff, dynamic linking is a piece of cake, you just have to remember these 17 simple rules:
[23:56]  * IntuitiveNipple laughs
[23:57] <IntuitiveNipple> Bryce: don't stress on it - I'll sort the user for now, and update the bug and produce a fixed package debdiff
[23:57] <bryce> ok cool
[23:57] <IntuitiveNipple> I was just hoping someone already knew the answer :0
[23:58] <bryce> yeah I'd suggest getting Keybuk's input on it, this isn't a patch I'm terribly familiar with
[23:58] <IntuitiveNipple> It looks like its been added in and out several times in a tug of war, too
[23:58] <bryce> it's a bit complicated; it'd be nice to see this go upstream or something
[23:59] <IntuitiveNipple> yeah :)