[01:05] <tripelb> Can I root with no PC? just the N7 Alon?
[01:05] <tripelb> Can I root with no PC? just the N7 alone.
[01:50] <scientes> tripelb...not here
[01:50] <scientes> i have the answer...
[07:23] <dholbach> good morning
[08:38] <janimo> ogra_, do we still have freezes and image respins occasionally? Why are there .1 and .2 updates to yesterday's image?
[08:47] <infinity> janimo: Because some people (I was one of them) spun nexus7 by hand.
[08:48] <janimo> infinity, I was more intrigued by the reason actually :) Is this Thursday some sort of alpha or why the urgency?
[08:48] <infinity> janimo: Because the image builder was down for 6 days, and I was testing things when it came back.
[08:48] <janimo> just fixing image build bugs is a good reason
[08:48] <infinity> janimo: Nothing release-related at all.
[08:48] <janimo> infinity, ok
[09:33] <ogra_> janimo, hmm, i dist-upgraded yesterday and have all your changes installed, butu seems acceld is still running and if i stop it i have no rotation
[09:34] <janimo> ogra_, so you have u-d-n-0.49 and gsd -ubuntu3 ?
[09:34] <ogra_> janimo, do we need to do anything for the device permissions perhaps ?
[09:35] <janimo> ogra_, sudo udevadm info --query=property --name=iio:device
[09:35] <janimo> does this show ID_INPUT_ACCELEROMETER=1 among others?
[09:35] <ogra_> i have both packages, yeah
[09:36] <janimo> acceld is started in the X session hook (which I thought I had deleted)
[09:39] <janimo> I planned on installing a fresh image but will wait the first image with these packages in it - yesterday's last does not yet
[09:41] <ogra_> didnt you remove the upstart job for acceld ? the Xsession script checks if it is enabled iirc
[09:41]  * ogra_ checks his code
[09:42] <ogra_> yeah
[09:42] <ogra_> it looks for /sys/bus/iio/devices/iio:device0/buffer/enable
[09:42] <ogra_> janimo, if you are actually sure it works, just wipe acceld completely, it wasnt meant to stay :)
[09:43] <janimo> ogra_, I thought it is only started from the X session hook
[09:43] <janimo> kept the upstart bits as they initialize sysfs attributes with root privileges
[09:45] <ogra_> ah, indeed, you use them too
[09:45] <ogra_> err, no
[09:46] <ogra_> you at least dont read them dircetly, do they affect the /dev behavior ?
[09:51] <janimo> we do not read anything from /dev actually, just from sysfs
[09:53] <janimo> I thought I'd keep acceld along if someone wants to still debug rotation in the near future if g-s-d has issues
[09:57] <ogra_> janimo, you pointed out binary firmware for the accelerometer, where is that ?
[09:57] <ogra_> (or how is it called)
[09:57] <janimo> there exists on android (inside executables) not as a separate file
[09:57] <ogra_> ah, k
[09:57] <apw> ogra_, the driver claims to provide polled interfaces when it has firmware loaded
[09:57] <ogra_> apw, ^^^
[09:57] <janimo> it's a few Kb of microcode only
[09:58] <janimo> apw, it does, but the firmware is not only not free but it is unavailable
[09:58] <janimo> seems to have been partially (?) reverse engineered by the libi2cdev project
[09:58] <apw> well that sucks
[09:58] <pitti> janimo, ogra_: hello
[09:58] <janimo> apw, the dirver indeed even provides orientation as a sysfs attribute when enabled
[09:58] <janimo> pitti, hello
[09:59] <ogra_> hey pitti
[09:59] <apw> janimo, it was the 'poll' able interface i was interested in, but that doesn't work without
[09:59] <janimo> apw, right, my understanding also
[09:59] <apw> so we don't have to poll, sigh
[09:59] <janimo> we may get it to work but it seemed nonobvious techinically and murky license-wise
[09:59] <apw> yeah
[10:00] <janimo> still I plan on looking into it, as this particular sensor is going to be in many other devices
[10:00] <pitti> janimo: do you happen to know if we can use the triggers feature instead of having to poll all the time?
[10:00] <janimo> it is in the galaxy nexus and the transformer at least
[10:00] <janimo> variations of the MPU
[10:00] <ogra_> pitti, i guess only with binary firmware
[10:00] <janimo> pitti, no idea, but I plan on looking at the kernel side to check this
[10:00] <janimo> to see if we can without firmware that is
[10:01] <ogra_> though it shouldnt be to hard to move the acceld logic into the driver, would it ?
[10:01] <janimo> btw android on the nexus7 seems to read the raw data from sysfs, and has no fw loaded
[10:01] <apw> janimo, i've just been reading the driver and all the event driven stuff is dependant on dmp being enabled, and that is dependant on the firmware
[10:01] <janimo> maybe it uses some cleverer approach that eluded me as I did not look much into the kernel
[10:01] <apw> ogra_, to make the kernel poll for you ?
[10:01] <janimo> waking up every 1 s is suboptimal I agree
[10:02] <ogra_> apw, well, the kernel processes these numbers anyway at some point, no ?
[10:02] <apw> ogra_, only on read
[10:02] <janimo> apw, a middle road would be to have a kernel timer, have it do the calculations and only fire a kevent if it detects orientation chaneg
[10:02] <ogra_> hmpf, ok, i thought you could just run them through a filter that sends a trigger
[10:02] <apw> janimo, and that would be better how
[10:02] <janimo> so less process wakeups but policy and hacks in the kernel driver
[10:03] <apw> how would there be less process wakeups, a kernel thread is a process too
[10:03] <janimo> apw, ok, I plead ignorance then. I thought kernel timeouts would be more lightweight somewhat
[10:04] <apw> not really, it would look pretty much the same as a userspace process doing it
[10:04] <apw> the most efficient way would be to find something which is already polling
[10:04] <apw> and poll in that same process
[10:04] <janimo> and piggyback on that?
[10:04] <apw> so you have one wakeup
[10:05]  * pitti cannot think of something else on the desktop which is polling regularly
[10:05] <janimo> I was hoping g-s-d already does that and our poll would just tail on an existing one, but other timeouts in g-s-d are usually largert
[10:05] <pitti> no, g-s-d's orientation/media keys plugins mostly listens to XF86Rotate input events and similar, they don't poll
[10:06] <pitti> so I guess we could at least put luxd and acceld into one C process which does the polling for both
[10:06] <janimo> pitti, I mean other plugins, if they are in the same process (g-s-d) couldn't glibs timeout code wake them up at the same time?
[10:06] <janimo> I was hoping g_timeout_add_second wakes up at second boundaries for this reason
[10:06] <pitti> janimo: that's what I said, there are no polling plugins right now
[10:07] <apw> pitti, cirtainly wherever they go, we should poll them based on one timeout
[10:07] <pitti> we need to introduce one
[10:07] <janimo> pitti, ok. I grepped the source for g_timeout_add and there were a few, but they may not be enabled then
[10:07] <janimo> screensaver and powermanager come to mind
[10:07] <apw> ogra_, when you read those values from sysfs the kernel gets the value 'now' from the actual h/w registers by the looks of it
[10:07] <pitti> janimo: yeah, those use long timeouts, not subsecond polling
[10:07] <apw> so it isn't polling internally
[10:07] <janimo> we'll need similar polling for the light sensor (but I need to check, that may provide some trigger)
[10:08] <janimo> apw, from the buffer which we set the length to 200 at the moment
[10:08] <pitti> janimo: I profiled g-s-d in a running desktop session, it got about 20 wakeups a minute; i. e. it doesn't currently poll devices, but it's as good a place as any to do that
[10:08] <pitti> janimo: e. g. g-s-d's orientation plugin would be ideal in the sense that you can immediately hook into the "action" parts
[10:08] <janimo> we can still tweak the accel to only use low power mode, and use 1.25HZ frequency
[10:08] <janimo> but that only helps with its internal power savings, not the process wakeups
[10:09] <ogra_> pitti, btw, do you know if we already have a list of g-s-d modules we want to disable ?
[10:09] <ogra_> (or who is reviewing it)
[10:09] <pitti> ogra_: yes, http://pad.ubuntu.com/nexus7-desktop-profiling
[10:10] <pitti> ogra_: I came up with three which are definitively "out", and a handful which I'm uncertain about whether we need these features; but as they only add a negligible overhead my feeling is that we should leave them on for now
[10:10] <janimo> pitti, 20 wakeups a minute sound ok. Does the desktop still have frequent waker-uppers? (1/s or more frequent) ?
[10:10] <pitti> janimo: actually, compiz does
[10:11] <pitti> janimo: that wakes up 60 times a second for vsync wakeup etc.
[10:11] <pitti> janimo: (or the unity plugin)
[10:11] <ogra_> pitti, oh, right, i even commented already
[10:11] <pitti> janimo: that's pretty much the only process which wakes up that often
[10:12] <pitti> janimo: it might not actually be bad to put that polling into the unity plugin? it's "our" code anyway so we don't need to maintain huge patches against g-s-d, and can piggyback on the wakeups?
[10:12] <pitti> janimo: oh, the second is firefox when you have JS pages open; but I guess we can safely discard that :)
[10:12] <janimo> pitti, g-s-d was the most straightforward place as it dealt with accel and rotation already
[10:12] <ogra_> janimo, oh, btw, i was wondering if we couldnt "DPMS blank" and unblank the screen before and after rotating ... to hide the screen corruption
[10:13] <janimo> no idea about how it would fit in unity but I am open to the idea
[10:13] <janimo> pitti, or a g-s-d unity plugin?
[10:13]  * janimo has no idea whether such a thing even exists
[10:13] <pitti> janimo: I think g-s-d's orientation plugin is the most obvious one, but will require hard-to-maintain patches and additional wakeups; unity's is the most efficient in terms of wakeups, but might be harder to change
[10:14] <janimo> pitti, this particular patch is small btw, not sure what else we may need in term of orientation
[10:14] <pitti> janimo: g-s-d unity plugin> not right now
[10:16] <janimo> I mostly considered this code as a stop-gap proof of concept until we figure out a better way possibly post 13.04 when we run into more types of accel sensors and have a better idea what may work across them
[10:17] <janimo> pitti, is the etherpad above only about nexus7 g-s-d modules, will we have nexus specific module blacklist?
[10:22] <ogra_> well, i would call it tablet specific
[10:23] <pitti> janimo: no, these three plugins are not really n7 specific; I think we should disable them for all mobile devices
[10:24] <pitti> wacom and color apply even less to phones than to tablets
[10:24] <janimo> pitti, great, I hope we have as little divergence between n7 and the rest as possible
[10:24] <ogra_> actually i think the unity formfactor gsetting needs to be enhanced ... and g-s-d should enable/disable them based on this
[10:24] <pitti> janimo: we can disable those in the -defaults package
[10:25] <ogra_> (it currenly only has "netbook", "desktop" and "automatic" options)
[10:25] <ogra_> pitti, but thats very nexus7 specific, long term g-s-d should detect the right thing
[10:26] <ogra_> (for 13.04 the settings package will surely do though)
[10:26] <pitti> ogra_: we can disable the updates plugin globally even; that's the one which is really useless on ubuntu
[10:27] <pitti> as for color and wacom, that's more like a matter of choice; wacom is actually quite harmless (again, only triggered when you actually have such a device), but color is quite costly because of activating colord
[10:30] <ogra_> which doesnt even work on our LCD
[10:44] <Rjs> ogra_: dpms blank and unblank at rotation sounds like it is working around a bug in the X.org driver (i.e., if the nvidia driver was free software, you'd probably try to fix the screen corruption there?)
[10:44] <Rjs> ... so maybe the right place for a workaround would be in the X server, as some sort of wrapper for rotate requests before they get passed to the nvidia driver? or would that be too intrusive?
[10:44] <Rjs> hmm, or actually, does it use kms or something similar to rotate? if it does, you could possibly work around or even fix the corruption in the kernel driver, which is free software? (also, I've seen lots of display-related patches lately while browsing the linux-tegra list, but I don't know enough of the hardware to know if they have any relevance to the nexus7...)
[10:45] <ogra_> i fear that might be to intrusive since it would also affect sanely working drivers
[10:45] <ogra_> effectively nvidia needs to fix it
[10:46] <ogra_> but there is also compiz or nux that is redrawing really slow, i havent tested on lxde, but i bet the corruption will be a lot less there
[10:55] <janimo> hrw, have you considered uploading a chromebook kernel to ubuntu?
[10:55] <janimo> or some sort of exynos kernel
[10:55] <ogra_> ++
[11:04] <ogra_> janimo, btw udevadm info --query=property --name=iio:device doesnt exist iio:device0 and 1 do though, 0 has the ID_INPUT_ACCELEROMETER=1 property but also 0600 permissions and is root owned (no udev-acl in place)
[11:04] <janimo> ah yes the 0 dropped off in the paste
[11:05] <janimo> ogra_, I don't remember doing anything with udev-acl or permissions
[11:05] <janimo> root owned is ok as we do not read from it
[11:05] <ogra_> well, doesnt the user need read access at least ?
[11:05] <janimo> sysfs is user readable
[11:05] <ogra_> ah, k
[11:05] <ogra_> i thought you read from the device
[11:05] <janimo> no, we coudl read from there too but sysfs seemed simpler
[11:06] <janimo> well doing exactly as the go/dash scripts did, read form sysfs files
[11:06] <janimo> no idea why acceld is still running there though
[11:06] <janimo> and why g-s-d does nothing
[11:07] <janimo> ogra_, ah you mentioned screen blanking above. I guess we could do something to cover the ugly rotation effects
[11:07] <janimo> not sure how blanking would look
[11:07] <janimo> unfortunately we cannot do animated rotation as android does :)
[11:07] <ogra_> hopefully just like "flash to black and back"
[11:08] <ogra_> (WW) TEGRA(0): LVDS-1: Error querying display modes: No such device.
[11:08] <ogra_> i'd really like to know which device it talks about :/
[11:10] <janimo> right, weird xorg.log spa,
[11:10] <janimo> spam
[11:11] <ogra_> well, xrandr prints that too
[11:11] <janimo> you can strace and see what it checks for
[11:11] <janimo> maybe we have some etc permissions wrong?
[11:11] <janimo> I mean /dev permissions
[11:14] <ogra_> i dont think so
[11:15] <ogra_> all tegra* devices are handled by ACLs
[11:15] <ogra_> all nv* devices too
[11:16] <ogra_> oh !
[11:16] <ogra_> i never noticed /dev/lightsensor before
[11:17] <ogra_>  /dev/fb0 and 1 are ACL handled as well
[11:17] <janimo> ogra_, lightsensor is only used for debugging from what I saw
[11:17] <ogra_> ah, k +
[11:17] <ogra_> how sad
[11:17] <janimo> to ioctl on it and toggle printks
[11:17] <ogra_> hmm there is a knvmap
[11:18] <ogra_> nvmap is ACL'ed but not knvmap ... i wonder what that does
[11:19] <ogra_> oh, i tried gpsd for laughs ... seems it connects and initialized the device fine (according to xgps) but it never starts connecting
[11:33] <janimo> ogra_, when are the daily nexus7 images built?
[11:37] <ogra_> 14:something UTC
[11:43] <hrw> janimo: after fosdem I will have kernel which I consider uploadable
[11:46] <suihkulokki> hrw, janimo, I think it should be quite possible to have a single exynos5 kernel supporting arndale/chromebook/nexus10
[11:46] <hrw> suihkulokki: arndale uses 3.8, nexus10 uses 3.4(?), chromebook uses 3.4
[11:48] <hrw> suihkulokki: if someone wants to work on 3.8 for chromebook then I can test from time to time. But prefer something "stable" for each day use
[12:14] <janimo> suihkulokki, that would be great indeed
[12:15] <janimo> hrw, do you know about these? I was pointed to by fabo http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/using-an-upstream-kernel-on-snow
[12:15]  * janimo has no chromebook or any exynos btw, just thinks that having the kernel in 13.04 is a good idea
[12:17] <hrw> janimo: I know
[12:17] <hrw> janimo: note that it also says "text console only for now"
[12:17] <hrw> no x11, no usb, no keyboard, no charging
[12:18] <janimo> hrw, ok I wasn't aware of the status of that effort
[12:18] <janimo> or the uptodatedness of the page
[12:19] <hrw> works: serial (if you have debugboard == work for google), i2c (except one with keyboard and pmic), power button/lid switch, emmc/sd
[12:19] <hrw> not work: x11, usb, i2c4 (keyboard, pmic), display, hdmi, wifi, rtc, trackpad, audio
[12:19] <hrw> but it is good that they list status
[12:20] <hrw> and its 2 months old now so maybe got better
[12:21] <cjwatson> ogra_: bug 1110408 - I may have been a bit confused, as I didn't realise that we'd deliberately switched to portrait mode by default, so it was mostly just an upgrade surprise.  I guess the main bug was that touch was miscalibrated, then, and that no longer seems to be true.  Should I just close it?
[12:21] <ubot2> Launchpad bug 1110408 in ubuntu-defaults-nexus7 (Ubuntu) "Log out → lightdm comes back in portrait mode" [Undecided,New] https://launchpad.net/bugs/1110408
[12:22] <cjwatson> I probably
[12:23] <cjwatson> just hadn't rebooted since some relevant bit of the upgrade, or something
[12:23] <hrw> janimo: new chromebook kernel requires also new opengles driver for which I need to write new packaging with license stuff etc
[12:24] <janimo> cjwatson, that lightdm does not rotate is a bug though, it has some overlap with your experience
[12:24] <janimo> seb128 knows about that too so it's targeted
[12:25] <janimo> hrw, is that package that you needed the license stuff for yesterday?
[12:25] <hrw> yes
[12:25] <cjwatson> janimo: well, ok, but lightdm does now seem to work properly in portrait mode for me ...
[12:25] <cjwatson> as in I can actually touch "Log In"
[12:25] <hrw> I have first version but it complains about debconf not being interactive even when debconf is dialog or readline
[12:26] <janimo> right, so that bug as you said is not valid. It's just that it would show up in portrait when you log out of an otherwise landscape session
[12:26] <janimo> I found this out only yesterday after seeing your report
[12:39] <hrw> janimo: btw - what do I have to check before pushing chromebook kernel to archive?
[12:40] <janimo> hrw, if the packaging (naming, structure) is more or less like other kernels' and there are no ambiguously licensed bits in it it should be ok
[12:41] <hrw> janimo: I used linaro kernel packaging which is based on ubuntu one
[12:41] <janimo> it won't go into the archive unless an archive admin reviews it (infinity most likely) anyway
[12:41] <hrw> sure
[12:41] <janimo> the ac100 and nexus7 kernels are based on linaro packaging too
[12:42] <janimo> and infinity thinks having exynos in archive is a good idea - I asked you because I remembered him saying it :)
[12:42] <hrw> ;)
[12:43] <cjwatson> janimo: OK, so, do you want my bug open or closed?
[12:43] <janimo> hrw, do you know if the SoC on chromebook and nexus10 is the same?
[12:43] <hrw> janimo: iirc same
[12:43] <janimo> cjwatson, closed or renamed to 'no rotation in lightdm' I'd say
[12:43] <hrw> exynos5250
[12:43] <janimo> hrw, great, but likely much different peripherals
[12:44] <hrw> janimo: indeed
[12:44] <janimo> hrw, btw are there inertial sensors on the chromebook?
[12:44] <janimo> accel/gyro/compass like on a mobile
[12:44] <hrw> janimo: no idea really
[12:46] <hrw> git-buildpackage sometimes is nasty but in general roxx
[12:46] <janimo> hrw, doesn't look like from a quick search. Probably not much value in them
[12:46] <jibel> Xorg on my Nexus 7 died with the error http://paste.ubuntu.com/1593004/ while running these tests https://wiki.ubuntu.com/Nexus7/BrowsingSimulation , is it a known issue?
[12:46] <hrw> I need to buy usb3 hub and usb3 case for 3.5" hdd
[12:47] <janimo> jibel, not that  I know of. Do you know if it fails on other similarly specced ARM hw?
[12:47] <hrw> my 320GB hdd is wasting bandwith of exynos5 usb...
[12:47] <ogra_> cjwatson, right close it ... (sorry was afk)
[12:48] <jibel> janimo, no idea, I just have tested on this device
[12:48] <jibel> and didn't find anything interesting on the web yet
[12:49] <janimo> jibel, feel free to file it under the ubuntu-nexus7 project then
[12:49] <jibel> janimo, k
[12:49] <janimo> it will get reproduced and kept track of. thanks
[12:49] <cjwatson> ok, closing, thanks
[12:55] <apw> ogra_, -9.25 in the can and building
[12:55] <ogra_> apw, yep, saw it, thanks
[13:11] <hrw> E: linux-chromebook-3.4 source: build-depends-indep-without-arch-indep
[13:11] <hrw> thats only what left from lintian ;)
[13:16] <janimo> hrw, so your package probably is the cleanest ubuntu kernel package then :)
[13:16]  * janimo wishes we had an uptodate git kernel-package repo which all kernel package sync up with from time to time
[13:17] <hrw> janimo: https://github.com/hrw/chromebook-linux
[13:17] <janimo> it's too much gratuitous divergence in packaging
[13:17] <hrw> janimo: we have such one at Linaro
[13:18] <janimo> hrw, I'd name the package linux-exynos5 or something. There may be a new chromebook or two in the future
[13:18] <hrw> same with exynos5 hardware
[13:19] <hrw> but I understand
[13:19] <hrw> x86 chromebooks for example should be ~fine with default ubuntu kernel
[13:21] <ogra_> janimo, i noticed that my desktop now comes up in portrait by default and you need to rotate it once to activate rotation at all ... did you set the default orientation to "right" in g-s-d ?
[13:21] <ogra_> (should be "normal" in protrait)
[13:24] <ogra_> jibel, hmm, that uses chromium ... afaik out package is pretty outdated and it crashes for me after a while when using it
[13:25] <ogra_> (it breaks all font rendering here, likely due to an incompatible cairo version thats shipped in the chromium package)
[13:25] <janimo> ogra_, yes I noticed that too, I need to see what the issue is :) Maybe the same bug as I ad in acceld
[13:25] <ogra_> yeah
[13:27] <janimo> ogra_, I wonder if we should test all X related bugs in lubuntu as well to rule out compiz/unity/3d
[13:28] <ogra_> would make some sense i guess
[13:28] <ogra_> not that i'm eager to install lxde though :P
[13:28] <jibel> ogra_, it shouldn't make X crash, does it?
[13:28] <ogra_> chromium ? no it just breaks font rendering
[13:29] <ogra_> but the testsuite might break sue to it, no idea
[13:29] <ogra_> *due
[13:57] <janimo> hrw, for the final upload the skipabi and skipmodule bits need to be removed, so these tests get performed
[13:57] <janimo> annoying as they are
[13:59] <hrw> ok, thanks
[13:59] <hrw> did some tweaks and sent package to pbuilder now
[14:17] <ogra_> bug 951827
[14:17] <ubot2> Launchpad bug 951827 in gnome-power-manager (Ubuntu) "Power Statistics window blank" [High,Fix released] https://launchpad.net/bugs/951827
[15:36] <angs> I need to compile wpa_supplicant for a ubuntu-server image for beagleboard. Linux ubuntu2 3.2.0-23-omap #36-Ubuntu Tue Apr 10 20:24:21 UTC 2012 armv7l armv7l armv7l GNU/Linux. can anyone tell me how I can do it?
[15:36] <ogra_> geez, my N4 was just sent ! i only ordered today !
[15:37] <ogra_> angs, whats wrong with the wpa-supplicant package we have in ubuntu ?
[15:39] <angs> I am trying to predefine the cell ID for an ad-hoc wlan and using " bssid=92:4B:23:9D:30:DA " on wpa_Supplicant for it. however it never gets that cell id. on #linux-wireless I am told that the current wpa_supplicant that I am using is too old (0.7.3) and I need a newest one
[15:40] <angs> the latest one is 2.0
[15:41] <angs> is there any instruction how I can compile a package for ubuntu-arm?
[15:49] <ogra_> just compiling it on the board is the easiest
[15:50] <angs> what do I need to do after I download the package on the board? Is there any instruction for that?
[15:50] <ogra_> are you sure about 1.0 ?
[15:50] <ogra_> the latest releas in debian and ubuntu is 1.0
[15:50] <ogra_> err about 2.0 indeed
[15:51] <angs> yeah it is 2.0
[15:52] <ogra_> well, the general triplet of commands should do (configre/make/make install) if you use an upstream source
[15:52] <ogra_> you probably might need some build dependencies installed, i would look at the build deps from the ubuntu package and just make sure you have these
[15:53] <angs> thanks for your help ogra_
[16:30] <cj5> I'm having trouble booting Ubuntu 12.04. After a few tweak to the boot.scr I got to get to the UI, once to the language selection window, otherwise I get the Ubuntu background for a while then it reboots.
[16:30] <cj5> Pandaboard ES
[16:31] <cj5> Wondering what logs files I can look to to diagnose the problem
[16:40] <cj5> actually just found this in the syslog right before reboot - Unable to determine the model from DMI
[17:19] <hrw> janimo: ok, source package renamed to linux-exynos5-3.4 but is binary package linux-image-VER-ABI-chromebook fine?
[17:19] <janimo> hrw, a moment
[17:19] <hrw> ok
[17:21] <ogra_> hrw, thats what we use for ac100 and nexus7, should be good
[17:21] <hrw> cool
[17:22] <hrw> they should give devices some names ;)
[17:23] <Laney> I've got some pretty bad graphical corruption after flashing the current N7 daily. The background isn't rendered properly and half the screen is shifted over (and oem-config is off the side and is unusable). Anyone seen this?
[17:26] <janimo> hrw, should 3.4 be in the source package name? I don't think we have that elsewhere
[17:27] <hrw> can kill
[17:28] <Jef91> Has anyone gotten hardware accelerated video decoding working on the Nexus 7 under Ubuntu?
[17:30] <Laney> https://picasaweb.google.com/lh/photo/25VNEPdfiynNV9ZIrFj15dMTjNZETYmyPJy0liipFm0?feat=directlink
[17:30] <Laney> like that
[17:31] <Jef91> looks painful Laney
[17:32] <janimo> hrw, I'd also say the binary package image should be the same as the source's. I'd suggest using the same scheme as ac100 and nexus
[17:32] <janimo> as they are in the archive and noone complained about their naming :)
[17:32] <janimo> although they are named after the product not the soc
[17:32] <hrw> janimo: they had product names
[17:33] <janimo> I was just thinking the exynos kernel may be used by other devices using that SoC
[17:33] <hrw> if I make linux-daisy or linux-snow + linux-image-3.4.0-5-daisy or linux-image-3.4.0-5-snow who will know what it is?
[17:33] <janimo> hrw, I'd consult infinity on this issue as well
[17:34] <hrw> next week then
[17:34] <janimo> maybe exynos indeed would be too generous if it only worked with chromebook and contained chromebook specific code
[17:34] <hrw> I plan to go to sleep in ~2h
[17:34] <hrw> 04:00 trip to fosdem starts
[17:34] <janimo> hrw, have a good trip and conference!
[17:35] <hrw> thanks
[17:35] <mosasaur> Can I install a version of ubuntu on a galaxy note GT-N7000? I mean native.
[17:42] <mosasaur> https://wiki.ubuntu.com/ARM/DeviceSupport
[17:42] <mosasaur> I suppose that it's not easy
[20:02] <gmulak1> I went to Ubuntu site but cannot find the ARM version to download - help please
[20:14] <Jef91> gmulak1 installing on ARM devices is very different than installing on X86
[20:14] <Jef91> it isn't "one download fits all"
[20:14] <Jef91> Generally installing is different on every device.


[15:19] <zxmpi> code bread. chance of white christmas for some ttps://m.independent.ie/irish-news/chance-of-a-white-christmas-for-some-areas-with-dry-conditions-turning-cold-and-unsettled-next-week-41162665.html


[00:00] <huats> night seb128
[08:14] <crevette> hello good morning
[08:28] <seb128> mvo: hello
[08:28] <mvo> hey seb128
[08:28] <seb128> mvo: I assigned some trivial sponsoring bugs to you let me know if that's not ok and I will not do it again ;-)
[08:29] <seb128> mvo: some trivial apt things waiting for weeks
[08:29] <seb128> the list was several pages long and I decided to help a bit on it so dholbach doesn't have a nervous breakdown ;-)
[08:29] <mvo> seb128: what wsa the bugnumber for the apt thing?
[08:29]  * pitti hugs seb128
[08:30] <crevette> hello seb128 and pitti
[08:30] <seb128> mvo: bug #263089 bug #224460
[08:30] <crevette> and mvo
[08:30]  * seb128 hugs pitti
[08:30] <seb128> lut crevette
[08:31] <seb128> mvo: the translation one should be easy to review, not sure about the other one, you might want to unsubscribe sponsors if that requires extra thinking or discussions
[08:32] <seb128> pitti: what do you think about bug #201495? I will try to ping davidz on IRC to get upstream review
[08:32] <seb128> mvo: bug #274407 also is a one liner upstream change
[08:33] <seb128> mvo: and bug #298296 is a typo fix should be trivial
[08:35] <pitti> seb128: generally looks good, but I haven't really scrutinized the patch; if David is happy with it, sure
[08:36] <mvo> seb128: thanks, two of them are fix commited, the other needs some love
[08:36] <seb128> pitti: ok, I will try to get davidz to review it
[08:36] <pitti> thanks!
[08:36] <seb128> mvo: can you unsubscribe the sponsor team on those which need work?
[08:37] <seb128> or give me the number so I can do it for you
[08:39] <seb128> mvo: not sure what you mean by fix commited btw, the update manager typo fix is fix commited since november, or you mean you commited the fix to your bzr now?
[08:39] <mvo> seb128: the apt-cache one is probably for apt 0.8 (where some breakage of the output format is ok)
[08:39] <mvo> seb128: the compiz one I need to talk about with upstream, I'm not sure about possible side effects
[08:40] <mvo> seb128: the other ones look good and are merged :)
[08:40] <seb128> mvo: there is a pointer to the upstream bug, they commited the change there with a comment explaining what it does
[08:40] <seb128> mvo: ok thanks
[08:42] <mvo> seb128: aha, excellent. it should be in the compiz 0.8 branch then :) I will upload that this week
[08:42] <didrocks> hi seb128, mvo & pitti!
[08:42] <didrocks> seb128: no, it was not me for pidgin update :)
[08:43] <seb128> mvo: good
[08:44] <seb128> didrocks: hello, ok
[08:46] <didrocks> seb128: https://code.edge.launchpad.net/~didrocks/evince/ubuntu should be ready now :)
[08:47] <crevette>  I seen chriscoulson did the merge request throught launchpad yesterday
[08:49] <seb128> didrocks: excellent
[08:49] <seb128> crevette: right, and I wanted to ping mvo about that
[08:49] <didrocks> seb128: once done, I will have just one question on gnome-python (but later, I do not have the time now)
[08:49] <seb128> mvo: for this totem fix, you just bzr get lp-url and bzr merge directory?
[08:50] <crevette> mvo: if you have time to merge lp:~bmillemathias/+junk/bluez-ubuntu to bluez and lp:~bmillemathias/+junk/ubuntu-obex-data-server-4.x in obex-data-server I'd be thanksfull
[08:50] <seb128> didrocks: ask now while I'm not too busy ;-)
[08:51] <didrocks> seb128: I have to check something before, you think it will be ok in less than 10 minutes ? ;)
[08:51]  * crevette raise its hand for the next question
[08:51] <crevette> raises
[08:51] <seb128> didrocks: sure
[08:51] <seb128> crevette: don't ask to ask just ask ;-)
[08:53] <crevette> okay, I tried to package nautilus-sendto-universe, with the dh_install, si now I have my *so but also /tmp/buildd in my package so Iwonder if you had time to help me with this
[08:53] <crevette> and my package is still a bit hackish
[08:55] <crevette> http://pastebin.com/m2a4874d3 is the diff between nautilus-sendto and -universe
[08:55] <seb128> crevette: just copy nautilus-sendto
[08:55] <seb128> crevette: looking
[08:55] <crevette> http://pastebin.com/m5f6bb8e8 is the content of the package now
[08:57] <crevette> I'm a bit puzzled by the content of my nautilus-sendto-universe.install
[08:57] <mvo> crevette: thanks, merging now
[08:57] <seb128> crevette: right, your --prefix= is wrong
[08:58] <seb128> use DEB_DESTDIR := debian/tmp rather
[08:58] <mvo> seb128: yes, ideally a bzr branch, but a patch is fine. for the merge of chris I will probably just diff it myself (unless he is here today and I can ask him to publish his branch)
[08:58] <seb128> the --prefix is where you will get things installed on your system
[08:58] <seb128> mvo: pitti did sponsor the totem* updates yesterday
[08:59] <mvo> seb128: did he merge them into bzr too?
[08:59] <pitti> yes he did
[08:59] <mvo> cool!
[08:59] <seb128> mvo: and he was there yesterday and didn't notice those were using bzr, he said he would be doing updates using it now
[08:59] <mvo> thanks pitti
[08:59] <mvo> hm, so the warning in apt should be more prominent?
[08:59] <seb128> right
[08:59] <seb128> it seems people are used to not read things apt display
[09:00] <seb128> I've to admit that after doing some thousand apt-get source I don't read the screen either
[09:00] <seb128> just apt-get source, switch to something else, get back there after download and start on the update
[09:00] <seb128> I do read it now because I know about some people using bzr
[09:00] <seb128> but when you are not aware of that ...
[09:01] <seb128> I'm not sure the way the message is displayed is the issue though
[09:01] <seb128> it's just habits which need to be changed
[09:03] <mvo> crevette: bluez bzr is merged, thanks again (I noticed it got uploaded already, right?)
[09:03] <crevette> mvo: yep it is, thanks a lot
[09:03] <crevette> mvo: if there is a better way to ping you on IRC tell me
[09:03] <seb128> mvo: I did upload obex-data-server and bluez yesterday yes
[09:04] <mvo> crevette: irc works fine for me
[09:06] <mvo> crevette: obex-data-server merge too, thanks again!
[09:07]  * seb128 hugs mvo
[09:07] <crevette> thanks a lot
[09:07] <didrocks> seb128: this issue already exists in previous gnome-python package. When executing dh_install --list-missing I have that:
[09:07] <didrocks> /usr/lib/python-support/python-gnome2/python2.5/gtk-2.0/bonobo/
[09:07] <didrocks> and yes, python-gnome2.install is : http://paste.ubuntu.com/116383/
[09:08] <didrocks> oupss, wrong paste for first reference. dh_install give me: dh_install: python-gnome2 missing files (/usr/lib/python*/site-packages/gtk-2.0/bonobo/*.{py,so}), aborting
[09:08] <didrocks> and the reason is that data are copied into /usr/lib/python-support/python-gnome2/python2.5/gtk-2.0/bonobo/
[09:08] <didrocks> I think this is a dh_pysupport thing, which is not detected by dh_install --list-missing, right?
[09:12] <seb128> didrocks: it's likely indeed
[09:13] <didrocks> seb128: so, it will be hard to check for missing files :/
[09:14] <seb128> right
[09:14] <seb128> well the package doesn't change so much
[09:14] <seb128> read the NEWS
[09:14] <seb128> list new things otherwise assume it's correct
[09:14] <didrocks> yes, but it was more for information indeed :)
[09:15] <didrocks> so a bonus question is this case :)
[09:15] <didrocks> in the package, there is a patch, that change some Makefile.am
[09:15] <didrocks> as usually ^^
[09:15] <crevette> seb128: it seems passing DEB_DESTDIR := debian/tmp fails the package to build --> "libtool: install: `debian/tmp/usr/lib/nautilus-sendto/plugins' must be an absolute directory name"
[09:16] <didrocks> but the patch that apply it to configure is not used (commented in dpatch): http://paste.ubuntu.com/116386/
[09:16] <didrocks> so, if this patch is no more necessary, we can bump it
[09:16] <crevette> should I pass $(CURDIR) ?
[09:17] <seb128> crevette: right
[09:17] <crevette> thanks
[09:17] <seb128> you're welcome
[09:17] <seb128> didrocks: bump it?
[09:18] <didrocks> seb128: remove it, sorry
[09:19] <seb128> didrocks: we discussed this update and said to keep the patch but comment it since it's only useful when building for several python versions which is not the case at the moment but it will be useful again when python 2.6 is there?
[09:19] <didrocks> seb128: ok, so, there is even no need that I refresh 99-runaclocal+autoconf+automake.dpatch
[09:19] <didrocks> atm
[09:20] <seb128> no
[09:20] <didrocks> seb128: is there a documentation somewhere explaining exactly how this is handled when having serveral python versions? (I am a bit confused with this patch)
[09:21] <didrocks> just we don't specify an explicit PYTHON_LIBS version...
[09:21] <seb128> didrocks: "this" being?
[09:21] <seb128> didrocks: I don't remember the details about this change, the idea was to not depends on a specific python version
[09:22] <seb128> ie not having a hard depends on python2.4 when building for 2.4 and 2.5
[09:22] <seb128> the change might not be correct
[09:22] <seb128> but it was having the right effect
[09:22] <seb128> there was no depends on a specific python version
[09:22] <didrocks> seb128: ok, so, I will only keep the main idea for the moment and go further to understand this if the need is still present :)
[09:23] <didrocks> seb128: thanks a lot. I think the update will be soon available
[09:23] <seb128> thinking about it now it might be better to just add a line in debian rules to not calculate shlib:Depends for this .so
[09:23] <didrocks> seb128: yes, it can be wiser, maybe
[09:23] <seb128> but as said I don't really care right now, it's not required in the current version
[09:23] <seb128> thanks ;-)
[09:23] <didrocks> seb128: ok, will see when needed ^^
[09:23] <didrocks> you're welcome!
[09:24] <crevette> ls
[09:24] <crevette> oups :)
[09:29] <seb128> hey MacSlow huats
[09:29] <huats> hey seb128
[09:29] <MacSlow> hey seb128
[09:29] <seb128> huats: you worked late!
[09:29] <huats> (and MacSlow too of course)
[09:29] <didrocks> hey MacSlow & huats
[09:30] <huats> seb128: I have put the right .diff.gz...
[09:30] <huats> seb128: sorry...
[09:30] <huats> I think my yes were not opened enough
[09:30] <MacSlow> hey huats, didrocks
[09:30] <seb128> huats: that's ok, seeing the time where you added the diff.gz you should have been to bed ;-)
[09:30] <huats> seb128: thanks
[09:31] <huats> have you seen my email ?
[09:31] <huats> the patches for the libs are working (on my computer)
[09:31] <seb128> huats: yes
[09:31] <seb128> and you commented on the upstream bug which is good ;-)
[09:33] <huats> :)
[09:38] <seb128> hey tseliot
[09:39] <tseliot> hey seb128
[09:39] <tseliot> I'll get back to you with the patches soon. I was too tired to work on them yesterday
[09:41] <seb128> ok
[09:45] <seb128> hey rickspencer3
[09:45] <rickspencer3> hey seb
[09:45] <rickspencer3> good morning
[09:46] <seb128> how is the london sprint going ?
[09:46] <rickspencer3> loooong
[09:46] <rickspencer3> we're just starting day 4
[09:46] <rickspencer3> :)
[09:46] <seb128> ;-)
[09:46] <rickspencer3> how was the sprint for you?
[09:49] <seb128> excellent as usual ;-)
[09:49] <seb128> we got a lot done and it was nice to see everybody
[09:50] <rickspencer3> me too
[09:57] <asac> rickspencer31: mpt: did you meet mconnor yet?
[09:58] <mpt> asac, I did, yesterday afternoon
[10:00] <seb128> slomo: do you know if gstreamer is still supposed to have issue on online stream song changes nowadays?
[10:00] <seb128> slomo: ie bug #327475
[10:05] <slomo> seb128: should work nowadays if totem would use playbin2... and it will probably not be ported for 2.26 because it's too late now and everbody is busy
[10:05] <slomo> seb128: so it's essentially a totem bug, gstreamer is fixed ;)
[10:05] <seb128> slomo: ok what I though, thanks for confirming
[10:06] <seb128> somebody should clean all those bugs
[10:06] <seb128> there is probably a lot of those which will be fixed when totem uses the new playbin version
[10:07] <slomo> seb128: oh and rhythmbox has the "same" bug of course... and banshee... and... ;)
[10:07] <seb128> right
[10:08] <slomo> hadess is aware of the issue though and i bet there's also a bug on totem already
[10:08] <seb128> right
[10:08] <seb128> gnome bug #542663
[10:11] <slomo> thanks
[10:12] <didrocks> seb128: if you have nobody for pidgin, as other updates seems ok, I can handle it too
[10:12] <seb128> didrocks: let me check
[10:12] <seb128> I did ping somebody about that some days ago so I don't want to duplicate work
[10:13] <seb128> there is other task if you are looking for work though ;-)
[10:13] <didrocks> why not ^^
[10:13] <seb128> didrocks: bug #316636, seems nobody is actively working on it
[10:14] <didrocks> seb128: ok
[10:14] <didrocks> I assigned it to myself
[10:15] <seb128> thanks
[10:16] <seb128> didrocks: I'm going to sponsor a new pidgin revision now so make sure you get this change when you do the update ;-)
[10:17] <didrocks> seb128: ok, which revision, so that I can be sure?
[10:17] <seb128> didrocks: 0ubuntu3
[10:17] <didrocks> oh well, I will give a look at jaunty-changes
[10:18] <didrocks> ok :)
[10:18] <seb128> didrocks: http://launchpadlibrarian.net/22437717/pidgin_2.5.3-0ubuntu3.debdiff
[10:18] <didrocks> "Windows Live" -> who cares ? :)
[10:18]  * didrocks runs...
[10:19] <seb128> ;-)
[10:28] <crevette> seb128: the package nautilus-sendto-universe is done, however I think it needs some review, 1) on copyright because I don't know if I should let or remove the creator of the nautilus-sendto package; 2) on control.in for dependency, I set a dependency on nautilus-sendto on the same version than nautilus-sendto-universe
[10:29] <crevette> I put the code on http://bazaar.launchpad.net/~bmillemathias/nautilus-sendto/ubuntu/revision/1
[10:30] <seb128> crevette: let me look at it
[10:31] <seb128> crevette: you should update the description
[10:33] <seb128> crevette: would be nice to have "this package ships the extra feature which require universe dependencies" or something around those lines
[10:33] <seb128> crevette: also why did you add yourself as upstream author in the copyright?
[10:34] <seb128> crevette: what you put in the README would be nice in the description
[10:34] <crevette> ah right I did the README.Debian but forgot that
[10:34] <crevette> should I add myself to author ?
[10:34] <crevette> I thought I should add myselft as I modified the package
[10:34] <seb128> crevette: use rather source:Version that binary:Version for the depends I would say
[10:34] <seb128> crevette: you added yourself in the upstream authors list ...
[10:35] <seb128> crevette: upstream means GNOME, the people writting the code
[10:35] <seb128> crevette: you can add a line after the first one to say that you added changed to it
[10:35] <seb128> ie, this package was debianised by ... and modified for ubuntu by ...
[10:37] <seb128> crevette: you can also clean the depends on bluez, thunderbird, etc since those are not required for the universe variant
[10:37] <seb128> otherwise the update looks correct
[10:38] <crevette> "otherwise" :)
[10:38] <crevette> I wonder what is it remains :
[10:38] <crevette> )
[10:39] <didrocks> seb128: I wonder what's the difference between ${binary:Version} and ${source:Version}, as all packages must have the same Version?
[10:42] <seb128> didrocks: what do you mean must have the same version?
[10:43] <seb128> didrocks: crevette is adding a nautilus-sendto-universe source which builds a nautilus-sendto-universe binary which depends on nautilus-sendto
[10:43] <seb128> didrocks: ie those are different source packages so they can be out of sync
[10:43] <didrocks> seb128: oh ok, and ${binary:Version} will be replaced by nautilus-sendto version?
[10:44] <seb128> no
[10:44] <seb128> not sure to understand your question
[10:44] <didrocks> by nautilus-sendto-universe version
[10:44] <seb128> binary:Version is the version of the package itself not from an another one
[10:44] <didrocks> hum, I do not how ${binary:Version} and ${source:Version} can be different
[10:44] <didrocks> see*
[10:45] <seb128> binNMUs
[10:45] <didrocks> (you talk previously to replace binary by source)
[10:45] <didrocks> right, in this case :)
[10:45] <crevette> source can be 1.1.1 and binary 1.1.1-0ubuntu15 ?
[10:45] <seb128> we don't have that in ubuntu right now though ;-)
[10:45] <seb128> but still
[10:45] <seb128> not a recent to not use the correct one
[10:45] <seb128> reason
[10:46] <didrocks> ok, didn't think about binNMU, but right ;)
[10:46] <crevette> so nautilus-sendo-universe can still be installed if it source matches with the one from nautilus-sendto
[10:46] <crevette> binNMU ?
[10:46] <didrocks> (seb128: thanks)
[10:46] <didrocks> crevette: binary-only non-maintainer upload
[10:49] <seb128> crevette: debian can do rebuilds of the same source if required
[10:49] <seb128> so the binaries version doesn't match the source one
[10:49] <seb128> ie source can be 1-1 and binaries 1-1.1
[10:50] <jpds> seb128: re: bug #319182 - I tried making a debdiff but it prints out all upstream changes too.
[10:51] <asac> lool: hmmm ... not on -mobile anymore?
[10:52] <seb128> jpds: right, that's the idea, having an idea of what changed and if the upgrade is a good thing ;-)
[10:56] <seb128> I'm away for half an hour or so, brb
[10:57] <seb128> I will look at the evince and gnome-keyring sponsoring request then
[10:57] <didrocks> seb128: ok, I will be around in case of questions :)
[10:57] <seb128> cool
[10:57] <seb128> brb
[11:00] <asac> lool: are moblin mailing lists known to be down?
[11:00] <asac> i sent patches, but they don't get through ;)
[11:04] <lool> asac: ?
[11:07] <lool> asac: You need to use lists.moblin.org
[11:07] <lool> asac: The @moblin.org addresses will timeout
[11:07] <lool> asac: (yay!)
[11:08] <asac> lool: ah ok ;)
[11:09] <pitti>  /quit
[11:10] <Tm_T> pitti: and /exit went to a bar
[11:51] <jpds> seb128: Stuff requested added to python-gdata bug.
[11:51] <seb128> ok, I will have a look to that after lunch
[12:11] <Davedan> how can I edit a file with a gui editor as root?
[12:12] <Davedan> on the terminal I can just do: sudo nano filename, but I don't no how to do the same with a gui editor
[12:13] <rickspencer3> Davedan: I'm not sure if this is your question, but most people invoke the graphical editor from the command line as root
[12:14] <rickspencer3> There's also a channel called #ubuntu that may be better suited for a question like this (assuming i understand your question)
[12:14] <pitti> hey rickspencer3
[12:14] <pitti> Tm_T: :)
[12:15] <rickspencer3> hey pitti
[12:20] <jpds> !gksudo > Davedan
[12:22] <Davedan> thanks. I'm reading it
[12:37] <asac> mvo: apt-transport-https: Depends: libapt-pkg-libc6.9-6-4.7 ... broken!
[12:38] <asac> transitional state?
[12:40] <mvo> asac: transitional
[12:41] <asac> mvo: one archive pulse or should i wait till tomorrow?
[12:41] <mvo> asac: one more arcive pulse
[12:42] <asac> cool. thx
[13:12] <seb128> huats: gnome-keyring update uploaded ;-)
[13:12] <seb128> huats: good work, that was really a non trivial one
[13:12] <huats> seb128: cool
[13:13] <huats> seb128: thanks :)
[13:13] <huats> i though it was really easy, that is why i decided to put the gcalctool diff.gz :)
[13:13] <huats> it was funnier ;)
[13:14] <seb128> ;-)
[13:14] <huats> seb128: if you have things to do, please let me know
[13:14] <huats> otherwise I'll give a shot at finishing libgda
[13:15] <seb128> there is gnome-doc-utils to update which should be easy if you want to do it
[13:15] <huats> so that I can tackle teh anjuta after
[13:15] <seb128> otherwise you can continue on libgda, anjuta, etc
[13:15] <huats> of I'll take that one too...
[13:15] <seb128> cool
[13:15] <huats> (libgda is almost done...)
[13:15]  * calc is at sun and got his internet working :)
[13:15] <seb128> libgda is blocking didrocks too I think
[13:16] <huats> seb128: it is
[13:16] <huats> seb128: i was thinking of the pb gcalctool update
[13:16] <huats> since we won't have the SRU
[13:16] <seb128> what do you mean by pb there?
[13:16] <huats> seb128: sorry
[13:17] <huats> currently the intrepid version returns some wrong results
[13:17] <huats> (in some specific cases)
[13:17] <huats> (that was the reason why I asked for a SRU)
[13:17] <huats> and i was wondering since the packing iis done, if it worth putting it on my ppa...
[13:17] <seb128> that seems worth a sru
[13:18] <seb128> wrong maths is not good
[13:18] <huats> so that users can have it
[13:18] <huats> I know...
[13:18] <seb128> why has the sru idea being discarded?
[13:19] <seb128> I though there was no bugs worth a sru in the update
[13:19] <huats> https://bugs.edge.launchpad.net/ubuntu/+source/gcalctool/+bug/306702
[13:25] <rickspencer3> bryce: 327175
[13:26] <rickspencer3> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/327175
[13:26]  * didrocks nodes
[13:28] <didrocks> (and this gcalctool issue seems important. No conversion from deg to rad is some kind of basic stuff :/)
[13:29] <seb128> didrocks: depends of your users, not really in non scientific world
[13:29] <seb128> I've to admit I've not used anything than degrees since school
[13:30] <didrocks> seb128: sure, I used more my hp49 when having to make more complicated calculation
[13:31] <didrocks> seb128: and also, I never used more complicated things than % from the day I finished my engineering studies. That's a shame :/
[13:31] <seb128> welcome to the real world ;-)
[13:32] <seb128> I doubt many people use the desktop calculator to do something else that simple maths
[13:32] <seb128> the people who need to do maths in their work have probably better tools and the other ones just do basic maths usually
[13:35] <seb128> Laney: hi, f-spot failted to build on the buildds
[13:35] <seb128> Laney: http://launchpadlibrarian.net/22442383/buildlog_ubuntu-jaunty-i386.f-spot_<IP_ADDRESS>-1ubuntu1_FAILEDTOBUILD.txt.gz
[13:35] <seb128> Laney: do you have any idea about the issue? it built correctly locally
[13:37] <didrocks> seb128: yes, RPN rocks on HP calculator \o/
[13:38] <seb128> I own a texas calculator and I'm not using rpn ;-)
[13:39] <didrocks> rpn is good, other things are just evil :-)
[13:39] <didrocks> seb128: once you know that you have to use 2 [enter] 2 [+], everything's ok :)
[13:41] <Laney> seb128: Uh
[13:42] <Laney>    * C# compiler: /usr/bin/mcs
[13:42] <Laney> this is what I told you yesterday
[13:42] <seb128> it worked locally though
[13:43] <Laney> How did you build?
[13:43] <seb128> let's wait for the new revision to be uploaded to debian and sync that next then ;-)
[13:43] <seb128> apt-get source, cd source, debuild
[13:43] <Laney> jaunty?
[13:43] <seb128> yes
[13:43] <huats> seb128: http://launchpadlibrarian.net/22442821/buildlog_ubuntu-jaunty-hppa.gnome-keyring_2.25.90-0ubuntu1_FAILEDTOBUILD.txt.gz
[13:43] <seb128> but I might not be uptodate
[13:43] <huats> :(
[13:44] <huats> (failed on hppa and armel)
[13:44] <Laney> I guess you have mcs.exe installed, it would have failed for you in pbuilder
[13:44] <seb128> huats: kick upstream for using -Werror in tarballs
[13:45] <seb128> Laney: indeed
[13:45] <Laney> easy fix if you want to do it, otherwise you can wait for the sync
[13:45] <huats> seb128: but it builds fine on my pbuilder which is supposed to work like the build system :(
[13:45] <Laney> meebey has been unwell though, don't know when he'll sponsor it
[13:46] <seb128> huats: some errors are arch specific
[13:46] <huats> seb128: ok
[13:46] <seb128> huats: 32 against 64 bits, etc
[13:46] <huats> yeah
[13:46] <seb128> toolchain difference
[13:46] <asac> mvo: compiz complains about software rasterizer ... is that anything i can enable/disable in xorg?
[13:47]  * asac would love to use compiz on his ati card
[13:50] <seb128> huats: ok, so you can work on a gnome-keyring update to not use -Werror if you want now ;-)
[13:51] <huats> According to the changelog, it is related to : "add -Werror back in when --enable-tests is configured."
[13:51] <huats> and we do have the --enable-tests configured
[13:52] <mvo> asac: what ati card do you have?
[13:55] <seb128> huats: right, not sure why pochu did enable that in debian, let's not use this configure option
[14:00] <huats> seb128: ok
[14:01] <asac> mvo: VGA compatible controller: ATI Technologies Inc R580 [Radeon X1900]
[14:01] <asac> mvo: i enabled compise in xorg.conf ... didnt stop X to work at least ;)
[14:01] <asac> glxgears works too
[14:02] <asac> s/compise/composite/
[14:04] <mvo> asac: hm, interessting. but compiz does not work? because of the software raster issue
[14:04] <mvo> hmmm
[14:04] <mvo> there is a force option
[14:05] <asac> mvo: what option should i try?
[14:05] <asac> Checking for Software Rasterizer: present.
[14:05] <asac> Software rasterizer detected, abortingaborting and using fallback: /usr/bin/metacity
[14:05] <asac> mvo: maybe there is a xorg.conf option to enable hardware rasterizer
[14:06] <asac> ?
[14:06] <asac> also grep Composite /var/log/Xorg.0.log
[14:06] <asac> [    0.265380] (**) Extension "Composite" is enabled
[14:06] <mvo> asac: try "SKIP_CHECKS=yes compiz
[14:06]  * asac feels brave ;)
[14:07] <huats> seb128: have you touches anything on the update ? or can I start from the version I have put on LP  ?
[14:07] <seb128> huats: you can use the lp version
[14:09] <asac> mvo: without --replace?
[14:10] <asac> hmm ... seems to not work. i get a white screen
[14:10] <seb128> somebody told me during the sprint that it was always doing replace
[14:10] <asac> ah ok. doesnt make a difference anyway
[14:15] <mvo> asac: should work
[14:15] <Amaranth> asac: perhaps you have a permissions problem on /dev/dri/card0
[14:16] <Amaranth> that was causing the same kind of problem on intel for me at one point
[14:16]  * asac looks
[14:16] <Amaranth> it should be 666
[14:16] <asac> Amaranth: there is no such /dev entry
[14:16] <Amaranth> well then
[14:17] <Amaranth> fglrx?
[14:17] <Amaranth> if not, there is your problem :P
[14:17] <asac> Amaranth: no ati
[14:17] <asac> glxinfo  | grep direct
[14:17] <asac> direct rendering: Yes
[14:18] <Amaranth> yeah, exactly what mine would say
[14:18] <asac> glxinfo  | grep Raster
[14:18] <asac> OpenGL renderer string: Software Rasterizer
[14:18] <Amaranth> pastebin your xorg.0.log and the full output of glxinfo
[14:18] <asac> http://paste.ubuntu.com/116457/ (glxinfo)
[14:18] <asac> http://paste.ubuntu.com/116460/ (xorg log)
[14:19] <asac> Amaranth: ^
[14:22] <seb128> didrocks: the update looks correct, the short description could be better though, and maybe change the hildon mention to say "by the mobile team request" rather than saying it's not needed, it's rather than it needs to be rewritten I think
[14:25] <didrocks> seb128: ok. I change these
[14:29] <mvo> asac: did SKIP_CHECKS=yes not help?
[14:29] <mvo> asac: you should at least see a diffrent error message :)
[14:30] <seb128> mvo: he got a white screen apparently
[14:30] <mvo> aha
[14:30] <asac> mvo: heh. well, i get a white screen :)
[14:30] <asac> it continues and spits out a bunch of meta city warnings/errors
[14:36] <asac> mvo: http://paste.ubuntu.com/116464/
[14:38] <asac> hell whats going on
[14:38] <asac> i have compiz now ... i think
[14:39] <asac> what i did was run compiz -c -> then it locked up and i restarted gdm from console
[14:39] <asac> mvo: ^^
[14:39] <asac> let me try EXA now (currently have XAA enforced)
[14:40] <mvo> asac: ha! that might be the issue
[14:41] <asac> mvo: well ... so now compiz is on ... (it was before with XAA even)
[14:41] <asac> but its snail slow
[14:41] <mvo> asac: is it still using software for the rastering? I guess its simply that the hardware support is not yet there for your card
[14:41] <asac> hmmm seems its just composite
[14:42] <asac> desktop effects is off
[14:42] <asac> let me try
[14:44]  * asac gives up
[14:44] <asac> back to Xaa without composite and metacity ;)
[14:58] <pitti> ArneGoetje, bryce, Riddell: here?
[15:00] <asac> 1500UTC?
[15:00] <pitti> oh, we start at :30 nowadays, right
[15:00] <asac> heh
[15:00] <asac> i think before that it was 1600UTC
[15:01] <pitti> right, it's actually 16:30
[15:01] <Amaranth> oops, cable guy showed up
[15:01] <didrocks> asac: pitti : you just have to make a bisection between your two thoughts :)
[15:02] <Amaranth> asac: reading now
[15:02] <Riddell> hi
[15:03] <asac> so in 30 or 90 minutes ;)?`
[15:04]  * asac confused ... logs into his calendar
[15:04] <asac> ok meeting is in 90 minutes according to calendar ;)
[15:04] <bluesmoke_> [    0.651249] (WW) RADEON(0): Direct rendering disabled
[15:04] <bluesmoke_> [    0.651352] (II) RADEON(0): XAA Render acceleration unsupported on Radeon 9500/9700 and newer. Please use EXA instead.
[15:04] <bluesmoke_> [    0.651372] (II) RADEON(0): Render acceleration disabled
[15:05] <asac> Amaranth: i tried EXA ... didnt help.
[15:05] <Amaranth> asac: So using XAA is actually the same as disabling all acceleration, apparently
[15:05] <Amaranth> hmm
[15:05] <asac> not sure if i get the same error though
[15:05] <Amaranth> [    0.651228] (==) RADEON(0): Backing store disabled
[15:05] <bryce> pitti: yep
[15:05] <Amaranth> You got some funny thing in xorg.conf?
[15:06] <seb128> asac: 85 minutes indeed
[15:06] <asac> Ampelbein: Option          "AccelMethod"            "XAA"  Option "XAANoOffscreenPixmaps" "true"
[15:06] <asac> those are the only options
[15:06] <asac> let me check for the error output when running EXA
[15:06]  * asac fiddles with xorg.conf
[15:07] <pitti> bryce: sorry, mixed up time; still 1:30 hours to go
[15:07] <bryce> pitti: yeah, seemed a bit early.  ;-)  If not for the jet lag I'd still be asleep. ;-)
[15:08] <Amaranth> asac: you also apparently have some extra input options setup although that shouldn't matter to this
[15:08] <Amaranth> asac: sudo mv /etc/X11/xorg.conf ~      then restart X :)
[15:08] <Amaranth> That's what bryce always says, anyway
[15:09] <asac> Amaranth: ... in the past i ended up in bad situations with no xorg.conf ... but i can try
[15:09] <asac> let me first try SKIP_CHECKS with EXA again
[15:10] <seb128> asac: try UXA ;-)
[15:10] <Amaranth> don't use SKIP_CHECKS unless it's failing on a blacklist
[15:10] <Amaranth> everything else being checked is "compiz doesn't work without this" stuff
[15:11] <bryce> pitti: say, how can I get the source for usplash 0.5.27?
[15:11] <pitti> bryce: debcheckout -a usplash
[15:11] <pitti> bryce: and then branch off the 0.5.27 tag
[15:12] <bryce> pitti: thanks
[15:12] <pitti> bryce: or download it from https://edge.launchpad.net/ubuntu/+source/usplash
[15:13] <asac> so without xorg.conf i end up with C64 screen resolution on my 24" monitor ;)
[15:13] <asac> but lets check whether it helps for compiz
[15:13] <Amaranth> haha
[15:14] <asac> so software randerization is still on -> now trying SKIP_CHECK again
[15:14] <bryce>  64 RAM SYSTEM  38911 BASIC BYTES FREE
[15:14] <bryce> READY.
[15:14] <Amaranth> asac: With software rendering you're either going to get a white screen or 1 frame every 5 seconds which will look like it froze
[15:15] <pitti> bryce: C64 ♥
[15:18] <asac> [    0.710959] (==) RADEON(0): Backing store disabled
[15:18] <asac> [    0.710978] (WW) RADEON(0): Direct rendering disabled
[15:18] <asac> but i get direct rendering: in glxinfo
[15:18] <asac> [    0.711019] (II) RADEON(0): EXA Composite requires CP on R5xx/IGP
[15:18] <asac> what does that mean?
[15:18] <asac> CP?
[15:19] <asac> i think UXA fell back to EXA
[15:19] <bryce> asac, don't think UXA is available for -ati yet
[15:20] <asac> argh ... gnome-terminal is soooo slow with EXA
[15:20]  * asac goes back to XAA
[15:20] <bryce> hmm, I'm running EXA on a R5xx here with no perf problems
[15:21] <seb128> didrocks: evince uploaded now
[15:21] <asac> bryce: really?
[15:21] <asac> bryce: you must have magic hands ;)
[15:21] <didrocks> seb128: thanks :-)
[15:22] <bryce> (**) RADEON(0): Using EXA acceleration architecture
[15:22] <bryce> 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV535 [Radeon X1650 Series] [1002:71c7] (rev 9e)
[15:23] <bryce> asac: I had problems getting it working on an R6xx card, but R5xx has been fine
[15:23] <mvo> for my Radeon Mobility X1400 it works pretty well too
[15:23] <bryce> small cursor corruption sometimes, but that's minor
[15:24] <asac> R580 [Radeon X1900]
[15:24] <asac> probably too gamerish ;)
[15:25] <bryce> asac: if you have a bug open on it, I can forward it upstream for you at least.
[15:26] <asac> bryce: cant you use the "EXA slow on ati by default" bug i opened?
[15:26] <bryce> asac: yes I can.
[15:27] <asac> let me find that
[15:28] <asac> sigh ... bryce what is the source package for ati again?
[15:28] <bryce> xserver-xorg-video-ati
[15:28] <bryce> didn't see a bug by you there... looking through your reported bugs
[15:30] <asac> hmm
[15:30] <asac> where did it go :/
[15:30] <asac> maybe reassigned?
[15:30] <bryce> the launchpad ogre ate it?
[15:30] <bryce> maybe, but no bugs mentioning "EXA" in your reported bugs list
[15:30] <asac> against what?
[15:31] <bryce> against anything
[15:31] <asac> i didnt find any from me against -ati ;)
[15:31] <asac> Bug 315889
[15:31] <asac> what happend to that :(
[15:32] <asac> went to hal and duped ;)
[15:32] <asac> is that the correct rational for that bug?
[15:32] <bryce> ahh...  we did have some issues related to the /dev/dri/* permissions that ended up being a hal typo
[15:32] <bryce> but that's fixed since a couple weeks or so
[15:33] <asac> ok i undupe
[15:34] <huats> how can I testrun gnome-doc-tool ? does anybody see a way ?
[15:35] <asac> bryce: done.
[15:36] <asac> bryce: hmm. i see that i have still fglrx module loaded. could that be the problem?
[15:36] <bryce> yes
[15:36] <bryce> purge that
[15:36] <mvo> aha, right
[15:36] <mvo> the fglxrx problem
[15:37] <asac> heh
[15:37] <asac> so its a known issue ;)?
[15:37]  * asac feels like this could help
[15:38] <bryce> asac: yeah many issues arise from having leftover bits of fglrx installed when using -ati
[15:38] <bryce> probably #1 issue we have with ATI in general
[15:38] <seb128> due to the libGL divert?
[15:39] <seb128> I got bitten by that too
[15:39] <asac> so fglrx-source should Break: -ati driver?
[15:39] <bryce> libgl* conflicts are the most common
[15:39] <asac> performance looks good on exa now
[15:39] <asac> great
[15:39] <bryce> sweet
[15:39] <asac> now going for compiz ;)
[15:40] <asac> too bad still software rasterizer
[15:40] <Tm_T> asac: try Kwin instead (;)
[15:40] <asac> but ok ... enough achieved for today ;) -> EXA
[15:40] <bryce> asac, :-)
[15:41] <bryce> some more info is available at https://help.ubuntu.com/community/RadeonDriver
[15:43] <bryce> asac, (and I'm curious whether this helps your sauerbraten issue at all)
[15:43] <huats> seb128: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-keyring/+bug/327643
[15:44] <asac> bryce: sauerbraten ;)?
[15:44] <seb128> looks german
[15:45] <seb128> huats: uploaded
[15:45] <huats> seb128: ok
[15:45] <huats> great !
[15:49] <asac> bryce: ok so this didnt help for my ET QW game ;)
[15:49] <asac> still performing slow
[15:49] <asac> but well
[15:49] <asac> back to work ;)
[15:50]  * bryce returns to playing with usplash diffs
[15:51] <bryce> ok, reverting kees' last change and building my own debs seems to work ok
[15:52] <seb128> and do you get the issue using the current version and building your own debs?
[15:52] <bryce> seb128: that's next
[15:52] <seb128> ok
[15:57] <Davedan> hi. when I'm trying to type a single quote ' in the command line I get ` only on the seccond press
[15:57] <Davedan> how can I fix/change that?
[15:59] <bryce> weird, I can't drag my panels around anymore after an xrandr clone event
[16:00] <seb128> bryce: you have to use alt to dnd those in jaunty (just in case you didn't know that's required now)
[16:00] <bryce> AHHH
[16:00] <bryce> seb128: ok didn't know that
[16:01] <seb128> it was too easy to dnd them by mistake and get confused users before
[16:01] <bryce> seb128: well that should cut down on confused users
[16:01] <seb128> right
[16:01] <bryce> yeah, both my mother and wife have gotten things messed up due to it
[16:01] <bryce> when I visit my mother I always have to straighten out her toolbars from whereever they got stuck ;-)
[16:01] <bryce> er s/toolbars/panels/
[16:03] <seb128> should not happen in jaunty then ;-)
[16:04] <bryce> guess that's going to be a nice complement to ctrl-alt-backspace going away
[16:04] <Davedan> anyone knows what can cause the single quote button not to work?
[16:04] <bryce> Davedan: many things
[16:05] <Davedan> I didn't change anything in the setup
[16:05] <bryce> hal, xkeyboard-config, hardware problem, on and on
[16:05] <bryce> Davedan: did you review /var/log/dpkg.log for recently changed packages?
[16:05] <Davedan> bryce: no. what do I need to do?
[16:05] <bryce> try downgrading things that look like viable candidates (debs may still be in your /var/cache/apt/)
[16:05] <Davedan> this is a clean install
[16:06] <Davedan> I didn't put anything that should mess with UI or keyboard
[16:06] <bryce> what keyboard layout?  us?
[16:06] <Davedan> only apache, mysql stuff
[16:06] <Davedan> yes
[16:06] <seb128> do you get the same issue in gtk applications?
[16:06] <bryce> what kind of keyboard?  anything unusual?
[16:06] <Davedan> Microsoft wireless
[16:06] <bryce> mm.  usb?
[16:06] <Davedan> yes
[16:07] <bryce> got another keyboard you could test with?
[16:07] <Davedan> yes
[16:07] <bryce> that'll be the easiest thing to test first
[16:07] <seb128> do you get the same issue in gtk applications?
[16:08] <Davedan> let me check both things
[16:08] <Davedan> yes I get the same issue with gedit
[16:09] <Davedan> I'll check a different keyboard but it'll require a restart
[16:09] <Davedan> thanks
[16:10] <Davedan> maybe it'll be simpler. does double quotes and single quotes do the same in the command line?
[16:10] <bryce> Davedan: often
[16:10] <bryce> Davedan: another thing to try is to run 'xev' and see if it receives your ' key
[16:11] <Davedan> what 'xev' does?
[16:11] <bryce> Davedan: I assume ' and " are on the same key?  and the latter works but not the former?
[16:11] <Davedan> yes
[16:11] <bryce> Davedan: it prints the keycodes received by the system at the X layer
[16:12] <mvo> ember: thanks a lot for the brasero update, doing it now
[16:12] <Davedan>  bryce: I see that but don't understand what to do with it
[16:12] <ember> cool, thanks.
[16:13] <Davedan> sombody said something about composing
[16:15]  * asac grabs some food
[16:16] <seb128> asac: getting energy for the meeting? ;-)
[16:17]  * bryce --> coffee
[16:17]  * pitti -> sponsoring
[16:17] <pitti> :)
[16:18]  * seb128 hugs pitti
[16:18] <pitti> I did mutt and lintian, doing monodoc and squid now
[16:22] <crevette> hey
[16:23] <Davedan> bryce: changing the layout from US internation to UK fix it. thanks!
[16:24] <crevette> seb128: I've updated my branch for nautilus-sendto-universe with you comments, what should I do now? I guess I should open a bug to have this package included in universe now.
[16:24] <Davedan> now I have to work :(
[16:24] <seb128> crevette: right
[16:24] <crevette> Okay I'll do that tonight
[16:24] <seb128> crevette: open a bug on ubuntu and subscribe the universe sponsor team to the bug
[16:24] <crevette> Need to go back home, my 2 days off are finished :/
[16:25] <crevette> yep
[16:25] <seb128> see you later!
[16:25] <crevette> see you
[16:26] <pitti> seb128: shall I do gnome-themes?
[16:27] <calc> where should i tell this user to file the bug? https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/267371/comments/40
[16:27] <calc> that particular comment on the bug
[16:27] <calc> seb128: i'm guessing it might be gvfs but not completely certain
[16:27] <seb128> pitti: yes please, I've done enough sponsoring for today, I will sponsor gnome-desktop for tseliot when ready but everything else is free for upload
[16:28] <pitti> seb128: ack
[16:28] <seb128> danke
[16:29] <seb128> calc: the comment is not especially clear on how exactly to trigger the bug, if there is exact steps on how to trigger the bug that would be nice, then open it on bugzilla.gnome.org
[16:29] <calc> ok
[16:30] <pitti> *DING* meeting time
[16:30] <seb128> *DONG*
[16:30] <asac> hi
[16:30] <pitti> ArneGoetje, Riddell, tkamppeter: ping?
[16:31]  * calc isn't sure if he'll be here the whole meeting but will be here at least part of it
[16:31] <pitti> calc: that's ok, I already marked you as "excused" :)
[16:31] <pitti> calc: how's the Sun?
[16:31] <seb128> anybody on jaunty amd64 to run "chrpath -l /usr/lib/python-support/python-gconf/python2.5/gtk-2.0/gconf.so"?
[16:31] <calc> pitti: pretty good :)
[16:31] <asac> hope better than our Snow here ;)
[16:31] <seb128> that's for bug #327671
[16:31] <calc> snowed here this morning, heh
[16:32] <asac> calc: are you in hamburg ;)?
[16:32] <tseliot> seb128: sorry but my bzr seems broken and I can't push my changes
[16:32] <pitti> everyone made it back in one piece?
[16:32]  * pitti enjoyed the sprint, and we got great work done
[16:32] <seb128> tseliot: can you upload the debdiff on your webpage?
[16:32] <Riddell> hi
[16:32] <tseliot> seb128: sure
[16:32] <calc> asac: yea
[16:33] <pitti> Riddell: Hey Mr. KDEMaster!
[16:33] <tkamppeter> hi
[16:34] <pitti> ok, let's start
[16:34] <pitti> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-02-10
[16:34] <pitti> has the current reports and agenda
[16:34] <tseliot> seb128: is it ok if I use version 1:2.25.5-0ubuntu2
[16:34] <tseliot> ?
[16:34] <pitti> nobody sent in agenda items, not surprising at this time, though :)
[16:34] <pitti> = Outstanding actions from last meeting =
[16:35] <pitti> Riddell: are you still blocking on anything MIRish?
[16:35] <Riddell> no I think I'm good now
[16:35] <bryce> Davedan: ok cool good to hear
[16:35] <pitti> cool
[16:35] <pitti> for the graphical installer, I'll take the action point of getting this discussed
[16:36] <asac> Riddell: note: ask you can see in my activity report i talked to upstream about jsapi policy ... seems that things are moving
[16:36] <seb128> tseliot: yes
[16:36] <Riddell> asac: oh nice
[16:36] <pitti> ACTION: pitti to discuss graphical installer requirements with Steve George, Colin, and Rick
[16:36] <asac> Riddell: with some luck we can get that for jaunty ... but dont want to promise too much yet
[16:36] <Riddell> asac: right.  it's not a major issue if not
[16:37] <pitti> asac: is that blocking something?
[16:37] <pitti> ok, seems not
[16:37] <asac> pitti: i think having google gadgets
[16:37] <asac> on kde desktop
[16:37] <asac> in main
[16:37] <pitti> right, I remember the stable ABI discussion
[16:37] <Riddell> yeah, fun but not a required feature
[16:37] <asac> sure. thought it was shiny though
[16:38] <asac> and shiny is good (havent tested myself)
[16:38] <pitti> *bling* :)
[16:38] <pitti> ok, [16:38] <pitti> The queue was immense on the weekend, and thanks to the unstoppable Seb it's much less scary now
[16:38] <seb128> ;-)
[16:38] <pitti> but still scary enough that we should put some extra effort into it
[16:38]  * pitti hugs seb128
[16:38]  * asac hugs seb128
[16:39] <asac> also for prodding me
[16:39]  * seb128 hugs pitti asac
[16:39] <pitti> it's really great to see so many contributors doing gnome updates, etc!
[16:39] <seb128> indeed!
[16:39] <mvo> yeah, cheers to them
[16:39] <pitti> so, all hands appreciated there
[16:39] <bryce> pitti: between the poor network, and the many questions on X stuff, I didn't get to sponsoring last week
[16:40] <pitti> bryce: nobody did, that's ok (I didn't really expect anyone)
[16:40] <bryce> ah, that would explain why we're behind then
[16:40] <pitti> it's not a very efficient thing to do while we are all together :)
[16:40] <pitti> bryce: exactly
[16:40] <tseliot> seb128: http://albertomilone.com/ubuntu/gnome/jaunty/gnome-desktop_2.25.5-0ubuntu2.debdiff
[16:40] <pitti> that wasn't meant as a blame, just as information that we should catch up this week
[16:41] <pitti> [16:41] <pitti> I updated https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus today
[16:41] <pitti> kudos to everyone, we halved the bug list since last week
[16:41] <pitti> there's one thing which is new, bug 309482
[16:42] <pitti> bryce: would you have some time to take a look at it and ask for the right debug info?
[16:42] <pitti> it was originally filed against oem-setup, but apparently it's an -nv bug
[16:42] <pitti> otherwise I'm quite happy about the current status; anything from you?
[16:43] <bryce> pitti: ok
[16:44] <pitti> bryce: thank  you
[16:44] <bryce> pitti: there's several X problems I'm tracking (some of which are now fixed), but generally things are ok for this stage of the release
[16:44] <asac> now that i found why my ati driver was slow with EXA i am happy for the moment
[16:44] <pitti> right in time for getting back from the sprint, suspend and hibernate gives me some issues (crashes after some 10 minutes), but I'll handle that as a bug report
[16:45] <pitti> Anything else we should talk about?
[16:45] <asac> right. i didnt file a bug yet, but once i came back home my laptop now auto log-outs when i suspend
[16:45] <bryce> pitti: yep I'm following up on a number of reports done during the sprint, we've gotten some patches from upstream, etc.
[16:45] <pitti> asac: sure that this isn't X crashing?
[16:45] <bryce> asac: check your /var/log/gdm/*.log files to see if X is crashing
[16:45] <asac> pitti: could be ... i will check that now
[16:46] <pitti> AOB, 2nd?
[16:46] <seb128> thanks pitti ;-)
[16:46] <bryce> pitti: your PowerManagement graphviz diagram looks nice (would be better in inkscape, but...) ;-)
[16:46] <pitti> bryce: heh, but I wanted to learn dot :)
[16:46] <bryce> pitti: how is hal ?
[16:47] <pitti> bryce: and after nudging some of the edges a bit, it actually looks "good enough" imho
[16:47] <asac> i wonder if the points on the WorksItems page should reflect the important things i plan to do for jaunty
[16:47] <pitti> bryce: "how"?
[16:47] <asac> or just what came out of specs
[16:47] <bryce> pitti: any major issues?
[16:47] <pitti> asac: they are meant to do both
[16:47] <pitti> bryce: nothing now TTBOMK; it basically didn't change since hardy, except for a handful of bug fixes
[16:47] <pitti> but I keep hammering on hal-info
[16:47] <asac> ok i think there need to be a bunch more items on it then
[16:47] <pitti> fixing bugs, quirks, and keymaps by the dozen :)
[16:48]  * pitti pats his commit access, that's really helpful
[16:48] <asac> i will try to give an additional list
[16:48] <pitti> asac: I think it's actually both
[16:48] <asac> i think i will check with rick ;)
[16:48] <pitti> asac: i. e. a breakdown of separable issues from specs, as well as other things which need to be done
[16:49] <pitti> asac: it's meant to project our progress on work we committed to, to see when/if we are falling behind
[16:49] <asac> right. i think its only spec stuff so far for me
[16:49] <pitti> asac: I suppose you have quite a bunch of non-spec things, too?
[16:49] <asac> and my specs are rather lowish
[16:49] <pitti> this is quite a new tool, so we need to improve it a bit (and of course also check out whether it suits us at all)
[16:49]  * pitti waves at rickspencer31
[16:50]  * calc has something to bring up
[16:50] <pitti> so we need shiny graphs :)
[16:50] <pitti> calc: go ahead, please
[16:50] <calc> Riddell: do we want to disable KDE support, i mentioned this in my status report but i didn't know whether we actually want to go ahead with it or not
[16:51] <calc> background on this for others is OOo has KDE integration but only for KDE 3 which requires the kdelibs4 be on the cd's
[16:51] <Riddell> calc: I think not
[16:51] <calc> Mandriva has already dropped KDE support in their release
[16:51] <Riddell> we're not desperate for that extra space on the CD and not having nice widgets is really ugly
[16:51] <calc> Riddell: ok that is fine with me :)
[16:51] <pitti> is that actually widgets, or more like file selector and print dialog?
[16:51] <Riddell> pitti: both
[16:51] <calc> just wanted to know for certain since i will need to do an upload about as soon as i get home from hamburg
[16:52] <pitti> (loosing the latter would really be sad, I think)
[16:52] <calc> pitti: all of it
[16:52] <calc> Riddell: if you can find someone knowledgable enough to do the porting work that would be very helpful :)
[16:52] <calc> Kendy from Novell doesn't apparently have the time to do it anytime soon
[16:52] <Riddell> it would indeed
[16:54] <pitti> ok, so we can note down as a decision to leave everything in place for jaunty
[16:54] <calc> yes that is fine :)
[16:54] <pitti> Riddell: how's the Kubuntu CD space-wise, once all mysqlish stuff gets added?
[16:55] <Riddell> pitti: still 30 to 40MB free
[16:55] <pitti> wow, nice
[16:55] <asac> sounds efficient
[16:55] <pitti> well, I guess it doesn't have langpacks yet
[16:55] <Riddell> right
[16:56] <seb128> pitti: speaking about CD space did you look at how much the GNOME updates changed on the ubuntu CD thanks to your changes?
[16:56] <pitti> seb128: not recently; once all are done, it should amount to some 10 MB on the desktop
[16:57] <calc> room for java on the desktop now :)
[16:57] <seb128> we rebuilt most of GNOME this week
[16:57] <seb128> no, room for translations on the desktop rather
[16:57] <calc> heh
[16:58] <pitti> looking at /usr/share/gconf/schemas/, many packages are already converted, but some big ones are still missing
[16:58] <pitti> -rw-r--r-- 1 root root 1256414 2008-12-09 20:13 ekiga.schemas
[16:58] <pitti> -rw-r--r-- 1 root root 1248978 2009-01-13 12:13 metacity.schemas
[16:58] <pitti> being the two biggest ones
[16:58] <mclasen> may I ask where those gconf patches are ?
[16:59] <seb128> mclasen: http://bugzilla.gnome.org/show_bug.cgi?id=568845
[16:59] <pitti> seb beat me to it
[17:00] <pitti> I still need to find some time to apply some enhancement proposals I got from the feedback there
[17:00]  * mclasen thinks it is funny how an intltool bug gets turned into a feature here...
[17:00] <pitti> mclasen: intltool bug?
[17:00] <dobey> eh?
[17:00] <mclasen> pitti: that it leaves all those translations in the mo files
[17:00] <pitti> mclasen: that was by design, not a bug
[17:00] <mclasen> after mergeing them back into whereever they came from
[17:00] <dobey> it's not a bug, and it's not intltool
[17:01] <dobey> that's how gettext works
[17:01] <pitti> anyway, that's post-meeting stuff
[17:01] <pitti> seems we are done otherwise, though
[17:01] <mclasen> dobey: intltool is what takes strings out of xml, puts them  in a po
[17:01] <pitti> so, thanks everyone
[17:01] <mclasen> and merges translations back into xml, no ?
[17:01] <pitti> [end of meeting]
[17:01] <seb128> thanks pitti
[17:01] <asac> thanks!
[17:01] <pitti> mclasen: no, out of a po, into an xml
[17:01] <mclasen> and in the process it forgets to remove the translations from the mo file
[17:01] <mclasen> I've filed a bug about it
[17:02] <dobey> intltool doens't put anything in mo files
[17:02] <pitti> mclasen: there's another step that xgettext's the template xml files into pots
[17:02] <dobey> and it may or may not merge back into one or more xml files
[17:02] <pitti> mclasen: but that's exactly the wrong way around...
[17:02] <mclasen> whatever, the end result is: if your project is using intltool, your mo files are larger than they should be
[17:02] <bryce> pitti: thanks
[17:02] <mclasen> we can certainly discuss this away from being an intltool bug
[17:02] <pitti> they shuold stay in the mo and stop being replicated all over the place (.desktop, .schema, .directory, .icon, and whatnot)
[17:03] <pitti> putting bundled static translations into text files makes it so utterly hard to update them
[17:03]  * rickspencer31 waves
[17:03] <pitti> rickspencer31: right on time :)
[17:03] <seb128> ;-)
[17:04] <rickspencer3> :)
[17:04]  * mclasen stops pointless intltool debate, best to avoid it
[17:04] <pitti> mclasen: also, chances are that the same string is used in other places (such as teh code itself), so you can't just remove everything from the .mo files which gets merged into a .schema or .desktop
[17:05] <pitti> mclasen: I wasn't saying that intltool would DTRT, it clearly doesn't
[17:05] <mclasen> pitti: of course you cannot just remove all strings
[17:05] <mclasen> in our rpms, I use msgmerge to filter out whats unneeded
[17:06] <pitti> mclasen: ah, seems everyone has their own little build wrappers :)
[17:07] <pitti> mclasen: but in the case of .schema files, how do you solve the duplication of translations in /usr/share/gconf/schemas/ and /var/lib/gconf/defaults/%gconf-tree-$LANGCODE.xml?
[17:07] <pitti> (well, I guess they aren't in the same path in other distros, but they are certainly somewhere)
[17:07] <mclasen> pitti: I am open to the idea that going via gettext() might be right for schemas
[17:08] <mclasen> the really right solution for gconf would be to keep all translations client-side in gconf-editor, I guess
[17:09] <pitti> mclasen: you mean in g-e's PO files?
[17:09] <mclasen> no, I mean there should be no need for gconfd to open all the worlds .mo files
[17:10] <mclasen> gconf-editor could do that,
[17:10] <pitti> absolutely
[17:10] <mclasen> in some future replacement of gconf
[17:10] <pitti> it shuold happen in the client-side library only
[17:11] <pitti> and in fact my patch does that (or at least means to)
[17:11] <pitti> I haven't checked whether gconfd itself calls gconf_schema_get_{long,short}_desc(), though
[17:12] <pitti> (if it would, then not doing so would certainly be a worthwhile optimization)
[17:17] <seb128> pitti: do you use an amd64 jaunty right now?
[17:17] <pitti> seb128: no, but I can rsync and boot a live CD if that helps you?
[17:18] <seb128> don't bother
[17:18] <pitti> just did a fresh install yesterday, but again i386
[17:18] <pitti> but yay ext4 :)
[17:18] <seb128> ;-)
[17:18] <seb128> that's for bug #327671
[17:19] <pitti> seb128: you just need to check whether it has an rpath, or test a fix?
[17:19] <pitti> (the former should be independent of the host platform)
[17:20] <seb128> test if there is a rpath
[17:20] <seb128> are you sure? I though that was an amd64 issue
[17:20] <seb128> I don't have an rpath on my i386 install
[17:20] <pitti> seb128: I mean, download the deb, extract it, run chrpath on it
[17:21] <seb128> good idea thanks
[17:28] <davmor2> anyone else having issues with pure grey title bars?
[17:33] <davmor2> http://www.davmor2.co.uk/greytitles.png shows terminal and FF
[17:36] <Amaranth> davmor2: nvidia?
[17:37] <davmor2> Amaranth: err yes
[17:37] <Amaranth> I don't have a fix, I just know nvidia is your problem
[17:38] <davmor2> Amaranth: Okay ta just wondered about it :)#
[17:38] <Amaranth> davmor2: that's compiz, right?
[17:39] <davmor2> Amaranth: Yes compiz is enabled
[17:40] <Amaranth> davmor2: There is a bug report for that, although the latest 180 driver should have fixed it
[17:41] <davmor2> Amaranth: that is the 180 driver.  I'm only smoke testing so I'll try again tomorrow and see if it is fixed then :)
[17:49] <rickspencer3> asac: I saw the role up from the team meeting today
[17:49] <rickspencer3> wrt work items
[17:51] <asac> rickspencer3: yes, go ahead
[17:52] <rickspencer3> asac: don't stress about it. Just update the items there and we can talk when I am back online next week
[17:53] <asac> rickspencer3: ok.
[17:53] <rickspencer3> It shouldn't cause any anxiety, it's just a way for me to judge (numericaly) how much progress we are making
[17:53] <rickspencer3> we can talk about how to make it more accurate, but I don't want it to cause more than 5 minutes of extra work a week
[17:54] <asac> rickspencer3: right, i will send you a list of items that should on there anyway i guess.
[17:54] <rickspencer3> if you want
[17:54] <rickspencer3> that would be great
[17:54] <asac> not many. just a few additions ;)
[17:54] <rickspencer3> you can just add them to the wiki if you want
[17:54] <asac> ok cool. i think i can figure the syntax ;)
[17:54] <rickspencer3> but email me if that's easier for you
[17:55] <rickspencer3> lol
[17:55] <asac> rickspencer3: one more thing. i subscribed you to two bugs as they are about things where we interface with/deliver to dx team. let me know if thats ok or if you want some other procedure for that
[17:56] <rickspencer3> asac: actually, I thought that was a really good idea
[17:56] <rickspencer3> feel free to do so for other bugs if that would help
[17:56] <asac> right, thought was a good thing for you to be in the loop for inter-team stuff
[18:24] <pitti> rickspencer31: right now the process of updating those seems quite unclear to me -- does that happen in reports, or we directly edit the wiki page, or the blueprint status?
[18:24] <rickspencer31> pitti: i dunno
[18:25] <rickspencer31> I just thought it would be easy this week for everyone to update the wiki for this week, and then I can run my script and generate that little table
[18:25] <pitti> rickspencer31: ah, forgot that, sorry
[18:25] <pitti> rickspencer3: I'll do it ASAP
[18:25] <rickspencer3> NO RUSH
[18:26] <rickspencer3> I really wanted this to be a low stress, 5 minute a week thing to help roughly track progress
[18:26] <pitti> rickspencer3: so you aren't generating the wiki page automatically, it's the primary source?
[18:26]  * pitti waves good night, 'nuff for today
[18:26] <rickspencer3> pitti: correct. it is not auto generated
[18:27] <seb128> 'night pitti
[18:27] <rickspencer3> just my script to extract the statts
[18:27]  * rickspencer3 'night
[18:29] <Laney> seb128: Hi, do you want a debdiff to fix f-spot? Or an LP bug?
[18:29] <Laney> or just wait for sync?
[18:30] <seb128> Laney: I'm about to go for diner, can you attach the debdiff to the previous bug or open a new one as you want?
[18:30] <seb128> do you know when it will be uploaded to debian?
[18:30] <Laney> nope
[18:30] <Laney> probably in the next days
[18:33] <Laney> seb128: it's on bug #293305
[18:36] <seb128> Laney: thanks
[18:36] <Laney> np
[21:05] <dashua> Amaranth: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/327794


[06:34] <pitti> Bonjour tout le monde !
[06:35] <duflu> Bonjour tout le monde, et pitti
[06:54] <duflu> pitti: Unrelated to recent discussions -- if I have a crash on startup and it gets uploaded, can I find via the filesystem which error/bug/URL it was?
[06:54] <duflu> I don't have working X, only VT login
[06:55] <sarnold> /var/crash/ ?
[06:56] <duflu> sarnold: Yes, files in /var/crash, but no URL to tell me where it went to or which existing bug it is
[06:56] <duflu> And no X either. Just a console
[06:57] <duflu> I wonder, can I look my machine up on errors.ubuntu by some ID?
[07:01] <duflu> I take it back. Unity7 in software mode eventually started after about 10 minutes
[07:35] <willcooke> Laney, https://launchpad.net/~attente/+archive/ubuntu/gnome-software/+sourcepub/6363890/+listing-archive-extra
[07:36] <willcooke> Laney, https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=
[07:51] <seb128> willcooke, teaching upload queues and ppas to Laney? ;-)
[07:51] <willcooke> someone has to
[07:51] <Laney> I'm learning something
[07:51] <Laney> PPAs don't have -proposed you know
[07:51] <seb128> right
[07:51] <pitti> Laney: that's configurable
[07:51] <seb128> but we upload to "version" for years
[07:52] <seb128> and have the archive redirect to proposed
[07:52] <pitti> and -- seb128, Laney: OHAI!
[07:52] <seb128> hey pitti
[07:52] <willcooke> obligatory: http://25.media.tumblr.com/tumblr_m4jt8mkkUX1qdojzho1_500.png
[07:53] <seb128> Laney, what's the issue with not having proposed? xenial is closed so uploads are going to go to proposed anyway no?
[07:56] <seb128> the https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text= view has the correct "proposed" pocket info
[07:58] <Laney> HAHA
[07:58] <Laney> don't worry about this you guys
[08:00] <Laney> hi pitti ;-)
[08:00] <Laney> such worker spam
[08:00] <pitti> Laney: yeah :/ but  as long as they are squeaking, they are alive
[08:00] <pitti> Laney: the days when I wished I had asked IS for cleaning up the quota DB last week..
[08:01] <pitti> but there's also this weird "invalid version" (with the newline and duplicate version), haven't looked at that yet
[08:01] <pitti> I'm currently working on a little script to filter out requests from particular triggers, so that we can go easy on the perl tests
[08:02] <pitti> (there's not much change, no need to run 2500 tests on 4 arches
[08:02] <pitti> well, I'm going to write that script, that is; still need to fix my juju-local install
[08:11] <seb128> Trevinho, andyrock, bug #1575452 seems an annoying issue (I can confirm)
[08:38] <Trevinho> seb128: that was actually a designed feature... Ask JohnLea if you want know more
[08:38]  * Trevinho had to spend some day in order to do that
[08:38] <Trevinho> s
[08:39] <seb128> Trevinho, what is a feature? not being able to focus the copy dialog?
[08:39] <seb128> can't click on it in the launcher, can alt-tab, by design?
[08:40] <seb128> but you can click/alt-tab if you open a nautilus dialog first and then click again
[08:46] <Trevinho> seb128: in theory the only wa to access to that should have been alt+tab
[08:46] <Trevinho> seb128: or alt+tab + arrows
[08:56] <Trevinho> seb128: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/784804
[08:57] <Trevinho> seb128: I fixed that on 13/01/12 ;P
[09:01] <seb128> Trevinho, that bug doesn't say that alt-tab should skip the item, it only speaks about focus when clicking on the icon
[09:02] <Trevinho> seb128: yeah... In fact alt+tab should see it
[09:03] <seb128> does the click thing makes sense as well? the bug rational seemed to be because unity was not able to tell appart different nautilus windows
[09:03] <seb128> but now it does?
[10:42] <andyrock> seb128: https://code.launchpad.net/~azzar1/gtk/lp-1574693-shadows/+merge/293082
[10:42] <seb128> andyrock, can you get desrt and/or Trevinho to review?
[10:42] <andyrock> Trevinho: ^^^
[10:42] <Trevinho> I will
[10:42] <Trevinho> seb128: actually desrt already suggested that change in the first rivew
[10:42] <Trevinho> review*
[10:51] <seb128> Trevinho, k
[10:51] <seb128> so +1 it
[10:56] <Trevinho> seb128: oh, wait... andyrock there's one more thing maybe
[11:37] <willcooke> desktoppers - are you snapping in the big room or do you want to come back in to the smaller one?
[11:37] <robert_ancell_> big room
[11:37] <seb128> robert_ancell_, too cold in the meeting one
[11:37] <seb128> ups
[11:37] <seb128> willcooke, ^
[11:38]  * flocculant thinks willcooke should alias desktoppers for crocodiles ...
[11:38] <willcooke> ack
[11:38] <willcooke> omw in a mo
[11:46] <desrt> om a ni wmo
[11:48] <Trevinho> willcooke: yeah, finished a patch and co,ing
[11:48] <Trevinho> ah never mind... it's on the big room :)
[11:51] <Laney> wo ai ni
[12:45] <jcastro> If I have screen tearing in games in unity on nvidia where do I need to start investigating?
[13:21] <pitti> seb128: oh, gotcha evolution translations!
[13:21] <pitti> since when is evo in universe?
[13:22] <ogra_> oh, yes, please ... i'd like my evo in german again :)
[13:22] <ogra_> pitti, trusty i think
[13:22] <ogra_> when thunderbird entered
[13:22] <pitti> ogra_: yep, bug 1545212
[13:23] <ogra_> (i actually didnt notice it was english until i took a screenshot of another bug ... definitely to much english in my brain )
[13:23] <pitti> ogra_: Inglisch heh?
[13:23] <ogra_> hah
[13:23] <pitti> on parle français ici !
[13:24] <seb128> pitti, feb I would say?
[13:24] <ogra_> Putain !
[13:24] <pitti> anyway, what a nasty bug, this affects quite a bunch of packages/domains
[13:25] <seb128> pitti, what was it?
[13:25] <jcastro> seb128: willcooke: where you guys serious about hosting our own firmware update service? If that is the case lmk now, marco would like to start writing the charm
[13:25] <pitti> seb128: really stupid :( http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/revision/562
[13:25] <desrt> jcastro: i think the situation is fine as-is
[13:26] <ogra_> jcastro, hughsie seems pretty happy ... he even shows off with the numbers
[13:27] <jcastro> yeah, and I know that openshift can scale and all that stuff, I just noticed discussion last week if it makes sense to depend on a third party service for things like that or if it should be more like an ntp-pool.
[13:28] <jcastro> anyway, not my decision to make, I'm just saying our team can help if that's the case
[13:28] <desrt> jcastro: please don't make hughsie unhappy.  he's very nice to us :)
[13:28] <seb128> pitti, oh, got catch!
[13:29] <pitti> Laney: oh, speaking of openstack, did you ever find a solution for the appstream downloads to prodstack?
[13:29] <seb128> jcastro, the service rely on rh cloud hosting parts apparently, so not likely easy to get our version, willcooke is talking to upstream to see how we can collaborate
[13:30] <jcastro> seb128: ack
[13:30] <jcastro> desrt: I'm like hughsie fan #1, no worries
[13:31] <Laney> pitti: some split between the webservers and the service
[13:32] <Laney> so yeah, it got fixed
[13:35] <Laney> and I got to learn all about load balancing
[13:35] <Laney> attempted to learn about mojo but gave up
[13:37] <pitti> Laney: ah, good to hear!
[13:37] <pitti> Laney: so, no proxying through a scalingstack instance after all :)
[14:14] <hikiko> Trevinho, andyrock: https://code.launchpad.net/~hikiko/compiz/compiz.scale-bottomYoffset https://code.launchpad.net/~hikiko/unity/unity.scale-launcher-at-the-bottom (the scale) I'm fixing the expo now
[14:16] <desrt> seb128: http://patchwork.sourceware.org/patch/7679/
[14:16] <willcooke> seb128, just writing here so I don't forgot:  a LP tag for snap bugs is "snapd-interfaces"   (is that right jdstrand?)
[14:16] <jdstrand> seb128, willcooke: snapd-interface
[14:16] <willcooke> thx jdstrand
[14:16] <seb128> jdstrand, thanks
[16:04] <seb128> night


[06:16] <apw> manjo, there is not tags on unstable ... you'd be better off basing them on where you want them applied
[07:10] <LocutusOfBorg> please please take the virtualbox modules from xenial and put in kernel
[07:10] <LocutusOfBorg> serious fixes for xorg 1.18 and rootless mode
[07:10] <LocutusOfBorg> you don't need the xorg-legacy package anymore
[07:10] <LocutusOfBorg> (guest-modules of course)
[07:11] <LocutusOfBorg> you can even see the patch (diff from the -2 and -3)
[07:23] <infinity> Might be a bit late for that.
[07:25] <apw> infinity, i guess i should at least queue those up in case there is any kind of respin for some other reaosn
[07:25]  * infinity nods.
[07:26] <infinity> apw: And test build it for sanity.  The update is rather... Extensive.
[07:26] <apw> sigh
[07:26] <apw> we love extensive changes after freeze, please bring it on
[07:26] <infinity> Yup.
[07:27] <infinity> apw: I love how the update script tells you how to grab and unpack the deb instead of just, y'know, grabbing and unpacking the deb.
[07:27] <apw> oh it has no version
[07:28] <infinity> If it took a version arg instead of a path, it could wget and unpack and import.
[07:28] <infinity> Or if could just pull-lp-source the latest from the current series with no args.
[07:28] <infinity> s/if/it/
[07:28] <infinity> But whatever.  I just always find it entertaining when the comments of a shell script are effectively more shell script. :)
[07:29] <apw> yeah lazyness on my part for sure
[07:29] <infinity> "Execute these shell commands before calling this shell command."
[07:31] <infinity> Err, pull-lp-source wouldn't work.  But you know what I mean.  Query the version somehow and wget from the pool, I guess.
[07:31] <infinity> I wasn't being critical so much as amused, though. :)
[07:46] <apw> yep, it clearly should take a version at least
[07:46] <apw> LocutusOfBorg, gads why is this about 10 billion lines
[09:31] <LocutusOfBorg> apw, I think the kernel module is not so extensive
[09:31] <LocutusOfBorg> unfortunately I had to take the whole patch, to be safe ;)
[09:31] <LocutusOfBorg> they had to implement a new driver, working with rootless xorg
[09:31] <LocutusOfBorg> otherwise it wouldn't work at all
[09:36] <LocutusOfBorg> looking at src/Vbox/Additions/linux changes, it isn't so scary
[09:36] <LocutusOfBorg> https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=cc16e5049641855149fe9d6b091415bebcc58d3d
[09:36] <LocutusOfBorg> and many fixes are ifdefs for the kernel 4.6 (sigh I already got two bug reports about people not being able to build it damn)
[09:37] <infinity> Oh?
[09:37] <infinity> Built fine for me.
[09:37] <infinity> Won't insert, because I have secureboot enabled, but... :P
[09:37] <apw> infinity, heh
[09:41] <LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1569989
[09:42] <ubot5`> Launchpad bug 1569989 in virtualbox (Ubuntu) "virtualbox-dkms 5.0.16-dfsg-2: virtualbox kernel module failed to build for kernel 4.6 [error: implicit declaration of function ‘page_cache_release’]" [Undecided,Fix released]
[09:42] <LocutusOfBorg> I remember another one with the same issue, but on guest-dkms
[09:44] <LocutusOfBorg> it affect host and guest, by sharedfolders module as you can see with a find on the above commitid on virtualbox.git
[09:44] <LocutusOfBorg> that page_cache_release is used in three places
[09:44] <LocutusOfBorg> infinity, you might have built only the video driver? :)
[11:40] <apw> infinity, LocutusOfBorg, ok build tested and pull-request out .. if we have a respin we can try and slip it in
[11:41] <LocutusOfBorg> <3 apw
[12:24] <LocutusOfBorg> apw, do you have any git link? I would like to one day understand more about the ubuntu kernel
[12:24] <LocutusOfBorg> and maybe ask pull-requests by myself :)
[12:24] <apw> LocutusOfBorg, is on our kernel-team@ list
[12:25] <LocutusOfBorg> oh... no git?
[12:25] <apw> the pull request contains the git
[12:26] <LocutusOfBorg> thanks
[12:26] <LocutusOfBorg> yeah
[12:26] <LocutusOfBorg> so you just grab the virtualbox-guest-source and commit the files?
[12:27] <LocutusOfBorg> BTW I'm not upstream, but meh :)
[12:29] <apw> LocutusOfBorg, you are "my upstream" though
[12:36] <LocutusOfBorg> :)