[04:32] <suji11> hi, here is my package http://revu.ubuntuwire.com/p/iok , i couldn't understand the last comment, can anyone explain to me?
[04:52] <arand> suji11: #uubntu-motu would be more appropriate for packaging help.
[04:53] <suji11>  arand: ok
[05:17] <pabs3> does anyone know when the Debian import freeze for Lucid is?
[05:17] <micahg> pabs3: Thursday
[05:18] <pabs3> thanks
[07:13] <tjaalton> slangasek: bah, still hangs with .33rc7. the session works for a while (terminal, access to home), but launching nautilus breaks it for good
[08:46] <Speedy1> www.search2.net
[09:16] <pitti> Good morning
[09:26] <Keybuk> ev: confirmed; automation doesn't work with 20100210 either
[09:26] <Keybuk> (or 20090209.1)
[09:26] <ev> Keybuk: indeed, already looking into it.  Appears to be a casper bug, but I'm still digging.
[09:49] <dholbach> bah, my desktop machine hung itself for the second time today and there's nothing in syslog
[09:50] <dholbach> and gdm doesn't show up properly either
[09:50] <seb128> dholbach, do you have plytmouth installed there?
[09:50] <Keybuk> "hung itself" ?
[09:51] <dholbach> Keybuk: like the mouse pointer does not move any more, I can't ssh in, music stutters like a broken record, etc :)
[09:51] <dholbach> seb128: yes
[09:52] <seb128> dholbach, try uninstalling it
[09:52] <seb128> my box stop freezing since I removed it
[09:52] <dholbach> seb128: will let you know in a bit
[09:52] <sebner> seb128: the plymouth/gdm freeze seems fixed /here though. Just did a normal boot. (I used a workaround the past week)
[09:52] <seb128> sebner, not there, I just did some testing for slangasek
[09:52] <seb128> I got it 3 times in a row today
[09:52] <seb128> until I uninstalled plymouth again
[09:52] <dholbach> sebner: it works on my laptop (i386, intel graphics) too, just not on my desktop (amd64, nv)
[09:53] <seb128> it's racy
[09:53] <dholbach> Keybuk: but at least magic sysrq still worked
[09:53] <seb128> so it will not happen every time
[09:53] <dholbach> seb128: yay - problem "fixed"! ;)
[09:54] <sebner> seb128: dholbach : Well, as I said, I was seeing it too the whole past week (with nvidia) but tried a normal boot today and it worked. Maybe it was just luck
[09:54] <dholbach> I hope that'll fix the kernel/whatever hang too :-)
[09:54] <seb128> dholbach, ;-)
[09:55] <seb128> I blame it on Keybuk for forcing plymouth on everybody and running away ;-)
[09:55] <sebner> dholbach: the funny thing is that on my box I'm seeing "self-healing" pretty often xD
[09:56] <Keybuk> not heard of that one being plymouth related
[09:56] <Keybuk> if X is up, plymouth shouldn't be running
[09:57] <sladen> another excellent one is if you shut the laptop lid during boot, and then reopen it to try and log in...
[09:57] <dholbach> Keybuk: I'm sure the hang is unrelated to plymouth :)
[09:59] <seb128> Keybuk, launchpad bug #516412
[09:59] <Keybuk> only if your boot is very very fast and you never see plymouth
[09:59] <seb128> Keybuk, it's still the same vt1 conflict issue I think
[10:00] <Keybuk> like I said, only if your boot is very fast ;)
[10:00] <Keybuk> otherwise X will be on vt7
[10:00] <seb128> my boot is not very fast
[10:00] <seb128> it's my d630
[10:00] <seb128> it takes some 45 seconds to boot
[10:00] <Keybuk> do you see the ubuntu logo?
[10:01] <chrisccoulson> i get X running on vt7 too, and i still see it crash when hitting enter
[10:01] <Keybuk> chrisccoulson: then that's unrelated to plymouth afaik
[10:01] <chrisccoulson> Keybuk - when i have plymouth installed, I noticed that all my keyboard input gets routed to the VT that X is running on
[10:01] <seb128> Keybuk, I see "Starting up..." for 15 seconds, "_" in text for 3 seconds, plymouth for 3 seconds, empty screen with xorg cursor for 3 seconds
[10:01] <seb128> then session
[10:01] <chrisccoulson> if i stop X, everything I've ever typed is on the underlying VT
[10:01] <seb128> then box crash when I hit enter
[10:02] <Keybuk> seb128: I can't see how that's caused by plymouth
[10:02] <Keybuk> sounds more like an X bug
[10:02] <seb128> I doesn't happen without plymouth
[10:02] <seb128> so it's an interaction between both
[10:02] <seb128> slangasek says that plymouth is not supposed to exit that early
[10:02] <Keybuk> but plymouth has already exited by the time X starts, right?
[10:03] <seb128> ie I should still have plymouth on the spinning cursor time
[10:03] <dholbach> boohoooo, the machine hung again :-(((((
[10:03]  * dholbach is very unhappy
[10:03] <Keybuk> oh, does plymouth segfault for you?
[10:03] <seb128> not that I know, at least it doesn't trigger apport
[10:03] <seb128> but it's only displayed for some 3 seconds
[10:03] <Keybuk> do you have a segfault message in kernel dmesg?
[10:03] <seb128> ie it goes away before having xorg displayed
[10:04] <Keybuk> yeah, sounds like plymouth crashed
[10:05] <seb128> no crash mention in the logs
[10:06] <seb128> it's a shame that the only 2 people not getting that issue are slangasek and you ;-)
[10:07] <seb128> in any case I can get debug informations if you need some
[10:07] <seb128> it happens pretty consistently there
[10:08] <Keybuk> I'll take a look after FF
[10:09] <seb128> ok thanks
[10:23] <dupondje> mvo: had some time yet ? ;)
[10:24] <mvo> dupondje: still on my list, but todo should be fine
[10:26] <mdz> is anyone else getting emailed about build failures in the kubuntu-ppa-staging PPA?
[10:28] <sbeattie> mdz: oh yes. It's going to the ubuntu-reviews list, for some strange reason.
[10:29] <mdz> Riddell: ^^
[10:31] <persia> I think it's also going to all members of some group, to which kubuntu-devel belongs, and hitting ubuntu-core-dev as a result.
[10:40]  * Keybuk wonders why he's now getting kubuntu build failure logs in his inbox
[10:40] <Tm_T> we thought you haven't had enough mails yet
[10:40]  * Tm_T hides
[10:41] <Keybuk> tm_T: I'll forward you the 2,000 odd mails in my LP folder shall I? :p
[10:42] <Tm_T> Keybuk: sure, I already have several thousand unread mails here
[10:47] <maxb> Which package determines that Ctrl+Alt+F1 means VT switch when in X? I'm trying to determine what changed on my lucid system such that it now VT-switches with plain Alt+Fx even when in X
[10:49] <Keybuk> maxb: linux-image-generic...
[10:49] <Keybuk> actually I think the Ctrl-Alt thing may be xorg-server ;)
[10:50] <maxb> Was about to say... didn't think I'd updated the kernel in the last few days
[10:51] <Keybuk> it's not an update or change
[10:52] <Keybuk> it's a bug
[10:52] <Keybuk> I suspect this to be the same bug that causes people's X servers to crash when they press Enter
[10:54] <maxb> crash as in display freezes on the last displayed image? I've seen that too
[10:54] <maxb> *blink* and the password I typed into gdm was displayed after the Login: prompt from a text getty after I quit X
[10:59] <Keybuk> yeah
[10:59] <Keybuk> you have the same bug then
[11:01] <seb128> maxb, uninstall plymouth...
[11:02]  * maxb does that
[11:20] <tkamppeter> I need help: When there are updates available, update-manager gets somehow started automatically, probably via D-Bus. I want to do so with the firmware installation tool of HPLIP. Someone knows how this works?
[11:20] <tkamppeter> Can I use libnotify for that?
[11:21] <cjwatson> it's done explicitly in update-notifier; grep that package and you should find it
[11:23] <tkamppeter> cjwatson: Thanks
[11:31] <pitti> tkamppeter: jockey recently grew the ability to listen for "needs firmware" uevents, and launch if it found something (currently used for  DVB-T sticks, which need firmware)
[11:32] <pitti> (the listening to those firmware events is also implemented in update-notifier)
[11:35] <tkamppeter> pitti, I have the following situation:
[11:36] <tkamppeter> HPLIP recognizes with the UDEV rule /lib/udev/rules.d/56-hpmud_support.rules whether a printer needs a proprietary plug-in in order to work with HPLIP.
[11:37] <tkamppeter> pitti, the udev rule simply runs "hp-mkuri -c" with the model name of the discovered printer in an env variable.
[11:39] <tkamppeter> pitti, hp-mkuri checks whether the printer needs the plugin, and if yes, it simply generates a notification uing libnotify, telling the user to run the appropriate utility (which is part of HPLIP, "hp-plugin").
[11:39] <tkamppeter> pitti, I want that hp-mkuri starts the utility directly in that case.
[11:40] <tkamppeter> pitti, and that with a not too big patch on hp-mkuri, so that I can contribute the patch upstream to HPLIP.
[11:40] <pitti> tkamppeter: how does it currently connect to libnotify? udev rules run as root, and are not attached to a particular user (session)?
[11:41] <pitti> tkamppeter: ah, so it's not "firmware" in the linux sense? (/lib/firmware/)
[11:42] <pitti> tkamppeter: can you please put /lib/udev/rules.d/56-hpmud_support.rules in a pastebin? (sorry, I don't have it installed)
[11:42] <tkamppeter> pitti, no, the firmware is not installed into /lib/firmware and the plugin can contain other things than firmware, like color profiles or binary-only driver add-ons.
[11:43] <pitti> tkamppeter: ok, so it's more like a general package
[11:43] <pitti> tkamppeter: that sounds like a case for jockey, except that it doesn't do hotplugging without further support (from update-notifier)
[11:43] <tkamppeter> pitti, http://pastebin.ubuntu.com/373145/
[11:44] <pitti> RUN+="bin/sh -c '/usr/bin/hp-mkuri -c &'"
[11:44] <pitti> ??
[11:44] <pitti> why doesn't it just run hp-mkuri straight away?
[11:45] <tkamppeter> pitti, here is the source of hp-mkuri: http://pastebin.ubuntu.com/373147/
[11:46] <tkamppeter> See especially the notify() function which generates desktop notification bubbles via libnotify.
[11:46] <pitti> tkamppeter: so, adding this match to update-notifier looks straightforward (the firmware bit already listens to gudev and has an event handler)
[11:46] <pitti> (and drop that rule)
[11:47] <tkamppeter> pitti, I do not know why the UDEV rule launches the program through a subshell, when I run hp-mkuri manually it exits already while the notification bubble is still there.
[11:47] <pitti> tkamppeter: I meant, why does it need that sh -c & hackery?
[11:48] <pitti> tkamppeter: but anyway, if the rule goes away in favor of changing update-notifier, it won't matter anyway
[11:48] <tkamppeter> pitti, perhaps due to its non-zero exit codes, but for that one could also do "hp-mkuri || :"
[11:48] <pitti> it shouldn't care
[11:48] <soren> Do we do anything to reduce swappiness when swap is on an SSD?
[11:49] <ogra> soren, i doubt that, usually the controller should care with recent SSDs
[11:49] <soren> ogra: What do you mean?
[11:49] <ogra> soren, on recent SSDs the controller does the wear out levelling
[11:50] <soren> Ah.
[11:50] <ogra> so it shouldnt matter what your swappiness is set to with newer HW
[11:50] <cjwatson> mvo: do you know what's going on with the return of bug 507842?  I'm seeing it here too
[11:50] <tkamppeter> pitti, I would like more to modify the notify() function in hp-mkuri as this is more streamlined with upstream. I do not need to add a dependency on update-notifier, so it is easier forgetting it accepted upstream.
[11:51] <ogra> soren, indeed there is that grey area of SSDs that dont do that ... i know cking did a lot of SSD work, he might be able to tell you what is on/off wrt SSD handling today
[11:51] <persia> ogra: That heavily depends on the filesystem used and the filesystems supported by the FTL (although many common FTLs do support ext2/3 now)
[11:51] <ogra> persia, swap is swap :)
[11:52] <ogra> unless you use a swapfile on top of a filesystem indeed :)
[11:52] <soren> persia: FTL?
[11:52] <persia> ogra: Ah, right.  I have no idea if any available FTLs treat swap well.  I seem to remember a discussion regarding using swapfiles to work around that.
[11:52] <persia> soren: Flash-Translation-Layer : is the embedded computer that sits between the disk interface and the flash.
[11:52] <pitti> tkamppeter: this uses some weird trick to talk to an user session; I don't even see how it is supposed to work in the first place; it doesn't even do setuid(), let alone dbus connections to any user's session
[11:53] <mvo> cjwatson: re 507842> I have a look
[11:53] <pitti> tkamppeter: the update-notifier support would be ubuntu only indeed; nothing for upstream
[11:53] <ogra> one solution with older SSDs was to have a swapfile and copy that around all the time ... i played with that, but thats horribly slow and wasteful
[11:53] <persia> Another solution is to use raw flash and UBI, but that requires motherboard support (and separate flash)
[11:53] <ogra> well, or use a modern SSD :)
[11:54] <ogra> with a proper controller
[11:54] <ogra> its a matter of price
[11:54] <tkamppeter> pitti, you mean libnotify uses this weird trick? notify() in hp-mkuri only calls functions/methods of libnotify.
[11:54]  * soren thinks his Intel X-25M is modern enough
[11:54] <ogra> yeah, definately
[11:54] <soren> Wow. This thing boots fast!
[11:54] <ogra> soren, bootchart ?
[11:54] <persia> soren: Check with Intel regarding swap support in the FTL.  You may find you want a swapfile.
[11:54] <pitti> tkamppeter: yeah, and that's what I don't understand; I can't believe that this works at all
[11:55] <ogra> soren, i have a samsung, with the upgrade to lucid my system went from 45 to under 10sec
[11:55] <persia> (But you don't have to copy the swapfile around with an FTL that supports the underlying filesystem)
[11:55] <soren> ogra: Yeah, I'm way under 10 sec.
[11:55] <tkamppeter> pitti, is libnotify shouting into the D-Bus and some user session daemon (notify-osd?) is listening and showing the bubbles?
[11:55] <ogra> soren, i'm talking desktop though :)
[11:55] <soren> ogra: Me too.
[11:55] <ogra> wow
[11:56] <pitti> tkamppeter: it's not "the" d-bus; notifications are happening on the session bus, which is per-user
[11:56] <pitti> and an udev rule doesn't have their addresses
[11:56] <soren> ogra: It feels way less than 10 sec, at least. /me is doing a bootchart now.
[11:56] <pitti> tkamppeter: did you test that this current rule actually works?
[11:56] <ogra> soren, temporary use autologin to get reliable measures
[11:57] <soren> ogra: I'm using ecryptfs, so no can do.
[11:57] <soren> ogra: Oh, i guess I could create a dummy user to test it.
[11:57] <cjwatson> mvo: ta
[11:57] <ogra> my fastest was 8sec so far ... but it went up a little with the latest plymouth changes
[11:57] <tkamppeter> pitti, yes. I have the HP LaserJet 1020 which needs firmware. I have removed the plug-in and then power-cycled the printer and I got a notification bubble.
[11:57] <ogra> its constantly around 9.5 now
[11:58] <tkamppeter> pitti, the bubble showed 30 sec.
[11:58] <pitti> magic
[11:58] <tkamppeter> pitti, and the bubble is in notify-osd style (black transparent with white text).
[11:59] <tkamppeter> pitti, the magic must be inside libnotify.
[11:59] <pitti> apparently so
[12:00] <tkamppeter> pitti, it works both by power-cycling the printer (then hp-mkuri runs as root) and by calling hp-mkuri on the command line (then it runs as me).
[12:00] <mvo> lool: hi, do you have a moment to talk about the latest python-central changes?
[12:00] <pitti> tkamppeter: so, you can't use libnotify to launch a program in the user session, so if you want to do that, you need to patch update-notifier
[12:01] <tkamppeter> pitti, I do not know enough about the capabilities of libnotify, perhaps it can.
[12:02] <pitti> tkamppeter: with notification-daemon you could attach an action, which could then launch a program
[12:02] <pitti> but notify-osd doesn't have actions
[12:04] <tkamppeter> pitti, notification-daemon is not used in Ubuntu any more?
[12:04] <pitti> tkamppeter: not by default
[12:06] <tkamppeter> pitti, and hplip has a working dbus server only if hplip-gui is installed which is also not done by default in Ubuntu.
[12:07] <pitti> tkamppeter: the session d-bus is launched by gnome, independent of hplip-gui
[12:08] <tkamppeter> pitti, how can I make use of the session d-bus the simplest way to let the udev rule launch an interactive program?
[12:08] <pitti> oh, you mean it exports a service over dbus, nevermind
[12:08] <pitti> tkamppeter: you can't
[12:08] <pitti> tkamppeter: you need a program in the user session to listen to udev events (such as update-notifier)
[12:08] <pitti> which then can launch a program
[12:09] <tkamppeter> pitti, how will it work by using update-notifier?
[12:09] <tkamppeter> pitti, does it require a change in update-notifier?
[12:09] <pitti> tkamppeter: update-notifier already sets up a handler for udev events (currently for firmware); this needs to be extended to match on that printer
[12:09] <pitti> tkamppeter: yes, it does
[12:12] <tkamppeter> pitti, is there some general d-bus listener in the user's desktop session which I can use without modifying it?
[12:12] <pitti> tkamppeter: no, mvo and I have always talked about this, but we never got to that
[12:13] <pitti> tkamppeter: update-notifier should be fine, the code is our's, and easy
[12:13]  * pitti needs to run out for some 30 mins
[12:13] <Keybuk> long-term, the idea would be that Upstart could be that general listener, even in the desktop session case
[12:13] <Keybuk> but that's YEARS off
[12:14] <tkamppeter> pitti, OK, can you do the changes on update-notifier?
[12:19] <mvo> tkamppeter: what is required? I can probably do it too
[12:21] <tkamppeter> mvo, the program hp-mkuri (written in C, http://pastebin.ubuntu.com/373147/) should send a message to somewhere telling that a certain command line should be executed in the user's session, to run a GUI application.
[12:25] <tkamppeter> mvo, the command line to be called is not a straight command line but a shell script one-line, like "if python -c 'import PyQt4.QtGui' 2>/dev/null; then gksu -- hp-plugin -u; else gksu -- xterm -T 'HPLIP Plugin Installation' -sb -rightbar -e hp-plugin -i; fi" so that it works on all Ubuntu systems.
[12:25] <mvo> tkamppeter: but the command line is not send as wel, right? that will be encoded in the session and the singal just is there to know which one to pick ?
[12:26] <mvo> tkamppeter: so when a signal like "plugin_installation_required" then u-n should call the above command?
[12:26] <tkamppeter> mvo, one could send the command line, but one could also send only a signal. The command line does not depend onm the printer model or on its connection type.
[12:27] <tkamppeter> mvo, but I would like that the HPLIP Ubuntu package provides this command line, because the command line can change with changes in future HPLIP versions.
[12:27] <mvo> tkamppeter: sending a commandline like this is scary, I would prefer to have it encoded inside u-n
[12:28] <mvo> tkamppeter: so just the signal, if future version require a different one, then I'm happy to update update-notifier
[12:28] <tkamppeter> mvo, we could put it into a file which is part of the hplip package, and the part of u-n which executes it, reads this file,
[12:29] <mvo> tkamppeter: thats ok
[12:29] <chrisccoulson> mvo - on the topic of u-n - do you think u-n should check it is on the active console before doing things like launching update-manager and showing the reboot dialog?
[12:29] <mvo> chrisccoulson: yes, good idea!
[12:30] <chrisccoulson> mvo - want me to provide a patch to do that?
[12:30] <chrisccoulson> (if i get the chance)
[12:30] <mvo> tkamppeter: I can make the required changes if you give me the signal name
[12:30] <mvo> chrisccoulson: YES :-)
[12:30] <chrisccoulson> cool, i'll try and look at that :)
[12:30] <chrisccoulson> right, lunch time. bbiab
[12:30] <tkamppeter> mvo, can you tell me where I should put the file and how to name it? Do not make it a conffile (not in /etc/) as it is only package- and not user-/system-dependent and so conffile update complications should get avoided.
[12:31] <tkamppeter> mvo, I do not have a signal name yet and also do no know how to send such type of signal. Can you tell me what I have to do?
[12:32] <mvo> tkamppeter: ok, lets take that off the channel into private conversation then. I can help with that
[12:33] <tkamppeter> mvo, OK.
[12:36] <lool> mvo: Sure, but I'm about to go for lunch
[12:36] <lool> mvo: Do you have issues with them?
[12:40] <mvo> lool: I have a debdiff for review that fixes the most recent change http://paste.ubuntu.com/373188/ - I think its still not ideal, but works in my tests
[12:41] <lool> mvo: That's odd, I tested the code and it worked for me; do you have a sample control where it fails?
[12:41] <mvo> lool: sure, try the atspi one
[12:42] <lool> mvo: Oh it's comments
[12:42] <mvo> lool: the problem is that paraborder is set to "0" on the first line that is not a \n - but that means that control files with # this is autogenerated\ndo not\nedit\n\n will not work
[12:42] <mvo> lool: so if you are fine with the above debdiff I will upload now and rebuild pyatspi
[12:42] <pitti> re
[12:43] <lool> mvo: how about http://paste.ubuntu.com/373190/ instead?
[12:43] <pitti> mvo, tkamppeter: we shouldn't use hp-mkuri in the middle, I think; update-notifier can just listen to the device event directly and fire up the gui
[12:43] <lool> mvo: Sorry about that BTW, I forgot to handle comments, but I wanted to stop parsing of XS-PV in binary packages
[12:44] <mvo> lool: yeah, that is fine as well
[12:44] <lool> mvo: Ok; I think my change is closer to what dpkg-dev does
[12:44] <lool> see /usr/share/perl5/Dpkg/Cdata.pm
[12:45] <mvo> lool: fine with me
[12:45] <lool> mvo: uploading
[12:46] <lool> done
[12:46] <lool> mvo: Sorry again for the trouble
[12:46] <lool> mvo: Next thing on my list would be to turn on include-links by default in a PPA
[12:46]  * lool lunch &
[12:46] <mvo> lool: nice, thanks
[12:47] <tkamppeter> pittim I do not know whether it is a good idea, as the UDEV rule is also subject to change with the HPLIP package, and so hplip should provide it.
[12:48] <tkamppeter> pitti: ^^
[12:53] <pitti> tkamppeter: make the udev rule ENV{ID_HPLIP_CHECK}="1" and only test the property in update-notifier, not the vendor/product ID directly?
[12:54] <mvo> tkamppeter, pitti: we can make u-n run a script provided by hplip when we get such a event
[12:54] <pitti> mvo: I thought that was by and large already there?
[12:54] <mvo> pitti: yes
[12:55] <mvo> pitti: I just wanted to decouple what is run from the u-n code, so that hplip can provide the command in a script
[12:55] <pitti> that makes sense
[12:57] <tkamppeter> pitti, mvo, hp-mkuri is needed to check whether a download of the plugin is really necessary. It sends notifications only if the HP device really needs the plugin and if the plugin is not yet installed.
[12:57] <mvo> and hp-mkuri needs to run as root? or could it run as the user?
[12:57] <tkamppeter> pitti, mvo, therefore I want to send the signal out of hp-mkuri, to not need to re-implement how to determine which device needs the plugin.
[12:58] <pitti> mvo: does u-n listen to the system bus?
[12:58] <pitti> if it does, hp-mkuri could send a signal to the system bus which u-n could pick up
[12:59] <tkamppeter> pitti, mvo, hp-mkuri works also running as me. It gets the model by env variable, so it does not need to access the printer.
[13:00] <tkamppeter> pitti, mvo, so you can see how the notification looks like by running: hp_model='HP LaserJet 1020' hp-mkuri -c; echo $?
[13:00] <tkamppeter> pitti, mvo, no printer needs to be connected for that.
[13:08] <mvo> tkamppeter: if its enough if it runs as the user we could just make it part of the script in hplip that u-n triggers ?
[13:17] <tkamppeter> Yes, then u-n can trigger the script on any HP printer, simply when /lib/udev/rules.d/40-hplip.rules has set ENV{ID_HPLIP}="1"
[13:18] <tkamppeter> Only problem is that we also need to know the printer model somehow without the script needing to re-detect.
[13:18] <tkamppeter> hp-mkuri needs the model in an env variable. /lib/udev/rules.d/56-hpmud_support.rules has it simply at hand.
[13:19] <tkamppeter> pitti, mvo, ^^^^
[13:29] <pitti> asac: so it's still necessary to apply dozens and dozens of thumb2 patches to all kinds of packages? I thought that got fixed in gcc proper?
[13:29] <ogra> pitti, that doesnt fix the broken code that uses hardcoded asm
[13:30] <pitti> ah, so that's not just the workaround any more that we applied to gtk and such
[13:30] <ogra> there are lots of packages that use asm to add arm support, asm thats not supported in thumb2 mode
[13:30] <asac> pitti: not sure what you mean
[13:31] <ogra> pitti, https://wiki.ubuntu.com/ARM/Thumb2
[13:31] <asac> pitti: there was a implicit-it fix that helped for a good bunch
[13:31] <asac> the rest is assembler that isnt valid and needs to get ported
[13:31] <ogra> pitti, look at "assembler errors" at that wikipage
[13:32] <asac> pitti: could you upload postgresql at some point before alpha3?
[13:32] <asac> iirc my patch is fix committed there
[13:33] <pitti> asac: I meant thsi: http://launchpadlibrarian.net/36400628/glib2.0_2.23.0-1ubuntu1_2.23.0-1ubuntu2.diff.gz
[13:33] <asac> pitti: https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList ... thats the fulll list of packages with assembler issues
[13:33]  * asac  checks
[13:33] <pitti> asac: yep, can do, it went to testing right before the sprint
[13:33] <asac> pitti: yes
[13:33] <asac> thats the kind of patches we do
[13:33] <asac> atomics
[13:33] <asac> and other stuff
[13:34] <asac> for atomics we can replace assembler with gcc atomic built-ins
[13:34] <asac> for other stuff we need to add different assembler
[13:35] <asac> https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
[13:35] <asac> thats the howto
[13:35] <lool> pitti: the glib fix is upstream now
[13:35] <lool> It's not a patch anymore
[13:35] <asac> right
[13:35] <pitti> ah, I remembered that it was a workaround for a gcc fix
[13:35] <pitti> thanks
[13:35] <asac> pitti: there was something else ... called "implicit-it"
[13:35] <lool> It's a workaround to use gcc's functions instead of the builtin assembler implementation
[13:36] <asac> we added that to a few packages in the beginning, but then doko made that default for gcc
[13:36] <lool> Oh right, that's probably what pitti recalls
[13:36] <asac> yes
[14:07] <tkamppeter> pitti, mvo: Any comments on my last messages?
[14:08] <james_w> was there anything that stops us from uploading v3 formats to lucid directly?
[14:08] <james_w> does that LP bug mean that you will only be able to upload -0ubuntu1 packages?
[14:09] <cjwatson> v3 (.orig).tar.gz ought
[14:09] <cjwatson> to work
[14:09] <james_w> but not .bz2?
[14:10] <cjwatson> .bz2 and others were believed to be buggy, yes
[14:11] <james_w> ok, I'll stop implementing it then :-)
[14:12] <cjwatson> ?
[14:12] <cjwatson> it should be fine for native packages
[14:13] <cjwatson> which was the one I particularly cared about :-)
[14:13] <cjwatson> (dpkg)
[14:14] <james_w> sorry, I mean I'll stop implementing the bit that makes v3 source packages with .bz2 tarballs
[14:15] <james_w> I have the import part
[14:27] <cjwatson> james_w: ah, right
[14:27] <james_w> I've added a --v3 flag to merge-upstream that will make it not repack .bz2 tarballs, should be good for this release
[14:28] <james_w> we can make it more automatic when the toolchain is up to it
[14:30] <cjwatson> james_w: pristine-tar can repack bz2 - it's xz it has trouble with, if that's the problem you mean
[14:31] <cjwatson> james_w: is there a current bzr-builddeb release branch that doesn't require bzr 2.1?
[14:34] <james_w> cjwatson: that too, but I don't want to automatically create packages that will lead to problems later with Launchpad
[14:34] <cjwatson> mm, fair enough
[14:35] <james_w> cjwatson: no, unfortunately not. You can just edit __init__.py to comment out that block if you want.
[14:35] <james_w> it's for the changelog merge support
[14:35] <cjwatson> I just reverted to r398 :-)
[14:39] <mvo> pitti: does "dbus-send --system --dest=com.hp.hplip --type=signal /com/hp/hplip com.hp.hplip.NeedFirmware" in the backend as a singal name make sense to you? for signaling u-n?
[14:41] <sabdfl> Processing triggers for initramfs-tools ...
[14:41] <sabdfl> update-initramfs: Generating /boot/initrd.img-2.6.32-12-generic
[14:41] <sabdfl> cpio: ./lib/udev/firmware.sh: Function stat failed: No such file or directory
[14:41] <sabdfl> update-initramfs: failed for /boot/initrd.img-2.6.32-12-generic
[14:41] <sabdfl> should I be worried about that?
[14:41] <sabdfl> just happened on an update, i'm reluctant to reboot till i can get it sorted
[14:42] <sebner> sabdfl: did the update fail or did you just read the message? Because I did a update some minutes ago (with gui) without problems
[14:43] <sabdfl> hmm.. was doing it under aptitude. i have some ppa's but don't think there's a kernel package in 'em
[14:43] <sabdfl> it did say i needed to do dpkg --configure -a
[14:43] <sabdfl> so i think it failed
[14:45] <sebner> sabdfl: oh, seeing it too now. I don't use PPAs so ..
[14:47]  * sebner waves at Keybuk 
[14:50] <cjwatson> sabdfl: bug 519855
[14:51] <sabdfl> cjwatson: should i not reboot, or just go ahead?
[14:51] <cjwatson> I'm not sure yet
[14:51] <cjwatson> firmware.sh was converted to C
[14:52] <ion> The old initramfs should still be there unchanged.
[14:53] <sebner> cjwatson: It set it to confirmed and there is already a patch
[14:53] <cjwatson> I was just writing the obvious patch :)
[14:54] <sebner> ah heh
[14:54] <cjwatson> sabdfl: you should be able to apply http://launchpadlibrarian.net/39011493/udev-firmware.patch and then 'update-initramfs -u' again
[14:58] <sabdfl> cjwatson: i don't mind waiting for it to come via update if it won't hose my system on reboot
[14:58] <sabdfl> or should i just be the guinea pig
[14:59] <sebner> sabdfl: in the worst case you might be able to do the "workaround" in the recovery shell :P
[14:59] <sabdfl> ok. if you don't see me again soon....
[14:59] <kklimonda> I've just applied the patch, updated initramfs and rebooted - all works fine
[14:59] <sabdfl> anybody reboot without the patch?
[15:00] <kklimonda> sabdfl, someone on ubuntuforums did and it worked
[15:00] <sabdfl> ok, see you all soon then, and thanks for the help
[15:00] <sebner> kklimonda: bah, you are spoiling all the fun :P
[15:00] <sebner> sabdfl: hf!
[15:01] <cjwatson> reboot without the patch> that will depend on details of your hardware
[15:01] <cjwatson> i.e. whether you need firmware to be loaded in order to mount the root filesystem
[15:02] <cjwatson> most systems don't, but a few SCSI systems need the firmware loader
[15:02] <cjwatson> as do things like NFS-root over network devices that need firmware
[15:06] <kklimonda> cjwatson, hmm.. but if update-initramfs fails older version of initramfs is going to be used which still has /lib/udev/firmware.sh - at which point is it going to fail to boot?
[15:07] <cjwatson> kklimonda: dunno
[15:09] <cjwatson> mvo: do you want to mark foundations-lucid-dynamic-cdrom-handling as implemented (I figure you should get the karma!), or do you want to do something about the postponed WI there?
[15:12] <mbudde> kenvandine: Is there python-appindicator 0.0.12 build for karmic?
[15:12] <micahg> kees: ping re PIE for xulrunner
[15:13] <cjwatson> Keybuk: BTW, you asked about my initramfs-tools branch at the end of last week; as far as I can tell I pushed the changes to bzr before I uploaded them, and everything looked up to date when I checked independently
[15:14] <kenvandine> mbudde, oh... no... i need to do that in the ppa
[15:15] <kenvandine> mbudde, i'll ping you when it is
[15:15] <mvo> cjwatson: karma!
[15:16] <mvo> cjwatson: I mark it implemented :) thanks. the remaining item is really small, I will see what I can do about it, but its not a big issue in the UI
[15:16] <JFo> Keybuk, I wonder if you would be interested in looking over some "Deleting plymouth seems to have fixed/created issues" bugs I have on the kernel?
[15:16] <JFo> for instance bug 518452
[15:16] <cjwatson> mvo: righto
[15:16] <mbudde> kenvandine: great!
[15:43] <dholbach> Riddell: could it be that kdebase in the kubuntu-ppa has ubuntu-devel@lists.u.c set as Maintainer address?
[15:44] <t3rm1n4l> hi
[15:44] <t3rm1n4l> i tried to load "record" module X11 on 9.10
[15:44] <t3rm1n4l> but i couldnt
[15:44] <t3rm1n4l> i heard it is broken
[15:51] <BlackZ> t3rm1n4l, I think it's better to ask in #ubuntu - if you think it's a bug you can report it (see https://launchpad.net/ubuntu/+filebug/) thanks
[15:55] <pitti> mvo: signal> looks fine to me
[15:58] <dholbach> Riddell: kdepim4 and kdeutils4 too - we get mails on ubuntu-reviews because of that
[16:06] <cjwatson> dholbach: isn't it just kubuntu-ninjas -> kubuntu-dev -> ubuntu-core-dev or some such
[16:07] <cjwatson> some team along the kubuntu bit of the chain probably needs to get a contact address set
[16:07] <dholbach> ah ok
[16:07] <cjwatson> it's not particularly new, just that some stuff failed recently
[16:40] <tkamppeter> keybuk, hi
[16:43] <cjwatson> for those who were asking: I've done a new-source run, mostly.  I left out a few packages which collided with other source packages or whatever and needed some manual inspection; if you're still missing anything that's in testing and you can't figure out why it isn't in lucid, shout
[16:43] <Keybuk> cjwatson: did you do contrib and non-free too?
[16:44] <persia> cjwatson: swt-gtk came up earlier : does that apply only for NEW sources, or also outstanding syncs?
[16:44]  * ogra just wants that one package that magically fixes all our bugs ... but i guess that wasnt even uploaded to debian yet :)
[16:45] <sebner> cjohnston: alien-arena
[16:45] <sebner> *cjwatson
[16:45] <sebner> I guess that counts for contrib
[16:45] <sebner> Keybuk: ^
[16:45] <Keybuk> ogra: did you boot with "nobugs" on the kernel command-line?
[16:45] <Laney> that's not new-source :)
[16:46] <ogra> Keybuk, awww, that might be it :)
[16:51] <tjaalton> slangasek: http://linux-nfs.org/pipermail/nfsv4/2010-February/012075.html
[16:52] <tjaalton> slangasek: so we might want to pull those for the lucid kernel. I'll try the patches tomorrow
[17:02] <cjwatson> Keybuk: yes
[17:02] <cjwatson> persia: I didn't do outstanding syncs, is there a bug open about this one or is it just a sync from testing?
[17:03] <cjwatson> ... the latter apparently.  I'll do it now
[17:03] <persia> cjwatson: Just a sync from testing : I don't mean to escalate it if it's in the category of "not done yet" rather than "something is wonky".
[17:03] <sebner> cjwatson: alien-arena is in testing
[17:04] <sebner> not new-source though
[17:05] <sebner> cjwatson: will you also do a normal autosync run?
[17:06] <cjwatson> sebner: it's running right now
[17:06] <cjwatson> sebner: yes, I already did alien-arena, thanks
[17:07] <sebner> cjwatson: cool, thanks :)
[17:07] <cjwatson> oh, maybe not, that's autosync not new
[17:08] <cjwatson> I'll do it, it's running
[17:08] <sebner> heh
[17:08] <cjwatson> E: swt-gtk is trying to override libswt-gtk-3.5-java_3.5.1+repack~3-0ubuntu1 without -f/--force.
[17:08] <cjwatson> persia: which of swt-gtk and eclipse should win?
[17:08]  * persia runs off to get an expert opinion
[17:09] <cjwatson> if the answer is swt-gtk, then eclipse still needs to be modified to stop building that package, or the next upload will fail
[17:10] <persia> Right.  I've asked nthykier, but there may be some time before I get the answer.  Given the work being done to get a working eclipse into Debian before sqeeze freeze, I suspect there's a good chance that this is sortable with the next eclipse upload.
[17:12] <persia> But at least now I know why it wasn't working.  Is the sync blocked in a useful way, or will this problem come inevitably?
[17:12] <cjwatson> EPARSE?
[17:13] <persia> cjwatson: Will the "E: swt-gtk is trying to override libswt-gtk-3.5-java_3.5.1+repack~3-0ubuntu1 ..." error continue to block the sync until I get an answer, or is it certain that eclipse needs to be modified and reuploaded?
[17:14] <cjwatson> persia: we can override the error if instructed appropriately, although eclipse *should* still see an upload around the same time if at all possible; in the meantime, the sync will continue to fail
[17:15] <persia> cjwatson: The sync failing for now is the best behaviour.  I'll sort it between those working on eclipse and those depending on swt-gtk and try to get the sync and upload organised this week.
[17:16] <cjwatson> ok, blacklisted for the moment with a comment referring to you
[17:16] <cjwatson> wow, somebody using .orig-COMPONENT.tar.gz (wmaker-data)
[17:17] <persia> Thanks.  I'll file a bug to unblacklist once it's sorted.
[17:25] <Keybuk> cjwatson: you can always count on those Window Maker guys to be ahead of the curve
[17:25] <Keybuk> it's the way they cling onto a window manager that was popular in the 90s
[17:28] <ion> keybuk: Our present desktop still clings onto the style of window management that was popular in the 90s. :-P
[17:29] <Keybuk> ion: I've bitched about this a lot too
[17:42] <geser> cjwatson: is there a list somewhere with failed autosyncs so they can get investigated?
[17:42] <cjwatson> geser: sadly not, the toolset makes it hard to generate too
[17:42] <cjwatson> what happens is you run sync-source.py -a and it falls over somewhere
[17:43] <cjwatson> then you have to blacklist it and run sync-source.py -a, which starts over again from the beginning
[17:43] <cjwatson> repeat until very bored
[17:43] <geser> oh
[18:11] <cjwatson> sebner: alien-arena runs into some crazy unpack failure too.  do you care about it?  http://paste.ubuntu.com/373384/
[18:11] <cjwatson> this is dpkg-dev 1.15.4ubuntu2~0.CAT.8.04; not *that* old but I suppose it might have been fixed in dpkg since then
[18:12] <sebner> cjwatson: I'll take a look
[18:12] <cjwatson> blacklisted for now, anyway; FWIW the sync blacklist is here: http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
[18:24] <sebner> cjwatson: local lucid pbuilder fails, dpkg-source -x works locally though
[18:25] <cjwatson> who knows ...
[18:26] <sebner> heh
[18:48] <pecisk> it is known when Evo 2.29.x versions will roll in Lucid?
[18:50] <persia> pecisk: Never precisely, because of the wide number of factors involved.
[18:53] <seb128> pecisk, never
[18:54] <seb128> 2.29 is a rewrite of many component
[18:54] <seb128> switching bonobo to dbus
[18:54] <seb128> and bonoboui to gtk
[18:54] <seb128> we don't think it's stable enough for a lts
[18:54] <seb128> and other distro will ship 2.28 for their lts as well
[18:54] <seb128> ie rhel6
[18:55] <pecisk> :(
[18:55] <pecisk> well, it's understandable reasoing
[18:56] <seb128> you will probably have a ppa for 2.30 somewhere
[18:56] <pecisk> seb128, yep, I thought about it
[18:57] <pecisk> so it's probably worth to roll out my own PPA for it then
[18:57] <pecisk> thanks for info :)
[19:03] <nxvl> kirkland: hey, are you around?
[19:03] <nxvl> kirkland: i just reported this bug: Bug #520004, and tracker it down until a fix you made
[19:03] <kirkland> nxvl: yo
[19:04] <nxvl> it seems that /script/functions is missing
[19:04] <kirkland> nxvl: i think that's a dupe
[19:04] <kirkland> bug 519855
[19:05] <kirkland> nxvl: you can hack it by symlinking firmware to firmware.sh
[19:05] <nxvl> kirkland: and the scripts/function thing is just a warning that can be ignored?
[19:06] <kirkland> nxvl: i'm not sure; i know that the firmware thing will break you though
[19:06] <nxvl> kirkland: just testing the firmware thing
[19:07] <nxvl> kirkland: huh, it looks like it worked, thanks, i got the other message aswell tought, but it worked
[19:07] <nxvl> kirkland: thank you
[19:08] <kirkland> nxvl: no problemo
[19:26] <smoser> slangasek, is there anything i can do for you for bug 504883
[19:26] <smoser> i would really like to see it fixed sooner rather than later, as running cloud-init much earlier could cause some issues for me.
[19:35] <Chipzz> directhex: you were at fosdem?
[19:35] <directhex> aye
[19:38] <Chipzz> cool :)
[19:39] <slangasek> smoser: it's turned over to Keybuk now for follow-up with udev upstream
[19:40] <smoser> is it something that will likely be fixed in alpha3 or beta1 ? or should i just plan on it not being fixed.  any thoughts?
[19:41] <slangasek> smoser: ask Keybuk :)
[19:41] <slangasek> if you're saying it *should* be fixed sooner in order to not push your changes back too far, we can milestone it, but you should still talk to Keybuk to see what he thinks our options are
[19:42] <smoser> ok. thanks. I'll try Keybuk tomorrow at a more reasonable hour.
[21:01] <pitti> urgh, our ancient lvm2 breaks more and more stuff :(
[21:02] <pitti> kees: ^ is it still a possibility to merge it with Debian?
[21:02] <persia> Do we at least have a good excuse to have an ancient lvm2?
[21:02] <ogra> persia, *because*
[21:02] <pitti> I guess just nobody had the guts/time to merge it
[21:02]  * persia did specify "good"
[21:03] <pitti> it's ancient, thus it's hard, thus it becomes even older, and harder
[21:06]  * pitti waves good night
[21:11] <kees> pitti: I was planning to merge today, unless you want to take it?
[21:12] <kees> oh, no, you're sleeping. :)
[21:14]  * slangasek chuckles
[21:14] <micahg> kees: did you need us to backport the PIE build hardening to karmic and jaunty for xulrunner 1.9.1?
[21:15] <kees> micahg: no thanks, I don't want to introduce changes like that for pre-lucid.
[21:16] <apw> anyone else seeing their password in plain text in seahorse in an up-to-date lucid?
[21:16] <apw> (for gpg)
[21:16] <micahg> kees: great, it should go into lucid with the 1.9.1.8 release next week
[21:19] <kees> micahg: cool
[21:21] <ogra> apw, not here
[21:22] <apw> ogra, what is with this machine
[21:22] <ogra> adunno
[21:29] <TheMuso> apw: Yeah I saw that yesterday.
[21:29] <apw> TheMuso, not good ... gone again today?
[21:29]  * apw updates to find out
[21:30]  * TheMuso does also.
[21:57] <shtylman_> \sh: I responded to the google perftools issue... its kinda unclear to me cause launchpad shows the package (libunwind)
[21:57] <shtylman_> maybe its not built yet?
[22:08] <EagleScreen> hi
[22:09] <Guest94638> I see that usplash is in universe in lucid, is it going to be replaced by another tool?
[22:13] <TheMuso> Guest94638: Plymouth has replaced usplash.
[22:14] <Guest94638> I see
[22:50] <directhex> asac, well, mono on arm built okay - any idea if it *works*?
[22:52] <directhex> 325 test(s) passed. 39 test(s) did not pass.
[22:52] <asac> directhex: not tried yet, isnt there a test suite run during build we could look at?
[22:52] <asac> right
[22:52] <directhex> hrm. wonder how that compares to karmic
[22:52] <asac> directhex: what is the fail ratio on i386?
[22:52] <directhex> 0 on i386/amd64
[22:52] <directhex> 0 on ppc. 4 on sparc, 1 on itanium
[22:53] <directhex> let's check arm on karmic
[22:53] <directhex> 321 test(s) passed. 40 test(s) did not pass.
[22:53] <directhex> aha, not so bad after all
[22:54] <asac> ;)
[22:55] <directhex> assuming it worked on karmic, anyway
[22:55] <asac> directhex: is there a test summary in log so we can check what actually failed?
[22:55] <asac> directhex: afaik, mono had issues on arm in karmic
[22:56] <directhex> asac, yes, there is. http://launchpadlibrarian.net/39020256/buildlog_ubuntu-lucid-armel.mono_2.4.3%2Bdfsg-1ubuntu2_FULLYBUILT.txt.gz - search for "did not pass" and scroll up or down
[22:57] <asac> hmm. often not really obvious  what it does
[22:57] <directhex> oh... actually, search for "show time", that's where the suite starts
[22:58]  * asac looks at exception6.cs
[22:59] <asac> directhex: does that failed 512(2) mean that it returned exit code 2?
[23:01] <directhex> honestly, i'm not sure. i've never really dug too deep into the test suite
[23:02] <asac> kk
[23:02] <ogra> hmm
[23:02] <ogra> apart from lp-integration and nautilus everything built
[23:02] <asac> assuming it means 2 ... it would mean that mono doesnt throw exception for overflow of Int.MaxValue
[23:02] <asac> on arm :/
[23:03] <asac> maybe i should really try --with-jit=no
[23:04] <ogra> ** (/usr/lib/mono/2.0/gacutil.exe:9843): CRITICAL **: _wapi_shm_file_open: shared file [/root/.wapi/shared_data-huito-Linux-armv7l-312-12-0] open error: Permission denied
[23:04] <ogra> fun
[23:04] <asac> what is .wapi?
[23:04] <ogra> no idea, directhex ?
[23:04] <asac> hmm. weatherapi
[23:04] <asac> python-pywapi
[23:04] <directhex> i think it's a thing it uses for storing semaphores. i think you can disable it
[23:04] <ogra> http://launchpadlibrarian.net/39023420/buildlog_ubuntu-lucid-armel.launchpad-integration_0.1.33_FAILEDTOBUILD.txt.gz
[23:04] <directhex> hang on
[23:04] <asac> but not sure, because that is python ;)
[23:05] <crypt-0> does this have anything to do with monodevelop?
[23:05] <ogra> why does it try to open /root/.wapi ?
[23:06] <ogra> it shoudnt try to access /root on the buildd
[23:06] <ogra> ** (/usr/lib/mono/2.0/gacutil.exe:2810): CRITICAL **: _wapi_shm_file_open: shared file [/root/.wapi/shared_data-palmer-Linux-i686-312-12-0] open error: Permission denied
[23:06] <directhex> ogra, it's trying to do that on the buildd? i think we're supposed to be disabling that via debian/rules environment
[23:06] <asac> yes. its proably something trying to load profile data ;)
[23:06] <ogra> aha, same thing on x86
[23:07] <ogra> directhex, yeah, the package is screwed on all arches
[23:07] <ogra> seems it was completely repackaged in cdbs
[23:08] <ogra> i wonder why
[23:08] <ogra> - Revert from DH7 to CDBS and correctly do CLI build
[23:08] <ogra> heh
[23:08] <asac> who maintains that?
[23:08] <asac> yeah .... great move ;)
[23:08] <ogra> not as correctly as expected :)
[23:08] <ogra> uploaded by robert_ancell
[23:09] <directhex> aha
[23:10] <directhex> ogra, to stop .wapi being an issue, it's neccessary to export an environment variable. i guess it's missing from launchpad-integration?
[23:10] <ogra> likely
[23:10] <ogra> well, i wont fix it tonight ;)
[23:10] <asac> ogra: nautilus seems to be waiting for a builder (e.g. didnt fail)?
[23:11] <directhex> yeah, seems the export is missing
[23:11] <ogra> i just gave it back, it was failing before due to indicator-app not being done
[23:11] <ogra> but i-a is published now
[23:11] <directhex> export MONO_SHARED_DIR=$(CURDIR)
[23:11] <ogra> next run should succeed
[23:11] <directhex> ^^ add that to debian/rules for launchpad-integration
[23:11] <directhex> should fix it
[23:12] <Caesar> zul: ping
[23:14] <TheMuso> 1/c
[23:15] <seb128> ogra, asac: lpi uses cdbs for years
[23:15] <ogra> seb128, then i wonder about that changelog entry
[23:16] <seb128> ogra, asac: robert_ancell changed it to dh7 to fix a mono binding packaging issue but broke all cdbs magic rules on the way
[23:16] <seb128> so we did revert to cdbs
[23:16] <ogra> ah
[23:16] <seb128> and fixed the mono build differently
[23:16]  * ogra didnt know
[23:16] <ogra> no, you didnt :)
[23:16] <bdrung> can a core-dev unsubscribe u-m-s from bug #407649 please?
[23:16] <seb128> ogra, they copied the debian wiki snippet
[23:17] <ogra> export MONO_SHARED_DIR=$(CURDIR) seems to be missing according to directhex
[23:17] <seb128> why do we need that?
[23:17] <seb128> and is dh7 doing that for you?
[23:18] <ogra> * (/usr/lib/mono/2.0/gacutil.exe:9843): CRITICAL **: _wapi_shm_file_open: shared file [/root/.wapi/shared_data-huito-Linux-armv7l-312-12-0] open error: Permission denied
[23:18] <ogra> it tries to import stuff from /root
[23:18] <ogra> same on all arches
[23:18] <Laney> it is used for IPC afaik
[23:18] <directhex> yeah, ipc semaphore nonsense
[23:19] <directhex> it stores them in $MONO_SHARED_DIR/.wapi
[23:19] <Laney> you want to export MONO_DISABLE_SHM = 1
[23:19] <Laney> or use cli.make
[23:19] <directhex> oh, that works too
[23:19] <robert_ancell> cli.make required dh7 :)
[23:19] <Laney> nah
[23:20] <Laney> well, it exports DH_OPTIONS too, but I would hope that that's harmless
[23:21] <Laney> if you do directhex's solution, you should make sure to clean up after it in clean:
[23:21] <robert_ancell> Laney, DH_OPTIONS makes everything complain in <dh7
[23:21] <Laney> what has that?
[23:21] <Laney> and isn't it just a warning?
[23:21] <Laney> a pointless discussion anyway since we are talking about one export :)
[23:22] <seb128> RAOF has it all fixed apparently
[23:22] <Caesar> I was wondering if someone would be able to sponsor an upload for me? It's a patch in #519119
[23:22]  * robert_ancell wishes we could migrate everything to dh7 overnight
[23:22] <RAOF> dh7 is much clearer when you're doing strange things :)
[23:23] <persia> robert_ancell: Too much breaks right now, but the time is coming.
[23:23] <ogra> robert_ancell, upload dh7-automigration
[23:23] <ogra> (and hope it does what the name says :) =
[23:23] <persia> robert_ancell: Make python-central dh7 compatible :)
[23:23] <cjwatson> ... it isn't?
[23:23] <Laney> someone should port the magic that is done by cdbs for gnomish things to DH7
[23:24] <cjwatson> Laney: yes, definitely
[23:24] <asac> bdrung: done
[23:25] <bdrung> asac: thanks
[23:26] <bdrung> asac: now you are my victim. ;) can you ack bug #517854 and sponsor bug #515230?
[23:26] <seb128> robert_ancell, you don't want to migrate anything gnomish to dh7
[23:26] <ogra> Caesar, why did you assign it to zul ?
[23:27] <seb128> robert_ancell, we would loose language pack magic and all the gnome magic for gconf, schemas, etc
[23:27] <robert_ancell> seb128, we need a dh7 sprint
[23:27] <Caesar> ogra: because we'd talked about it
[23:27] <ogra> ah
[23:27] <Caesar> he'd also created the problem I was trying to fix
[23:27] <Caesar> But he also said he'd upload it yesterday, and he hasn't
[23:28] <seb128> robert_ancell, I've better to do that rewritting working packages with an another packaging system I think ;-)
[23:28] <ogra> right, doing that now
[23:28] <Caesar> awesome, thanks
[23:28] <persia> robert_ancell: If you *do* want to migrate the gnomish stuff, you might find the recent changes in pkg-kde-tools a reasonable guide to how to do it.
[23:29] <robert_ancell> persia, not planning on doing it any time soon but thanks for the tip
[23:30] <ogra> Caesar, hmm, seems he already uploaded it
[23:30] <Caesar> ORLY?
[23:30]  * Caesar consults rmadison
[23:31] <Caesar> Huh
[23:31] <ogra> https://launchpad.net/ubuntu/lucid/+source/autofs5/5.0.4-3.1ubuntu3
[23:31] <ogra> :)
[23:31] <Caesar> Sorry to waste your time
[23:31] <ogra> no waste happened :)
[23:32] <ogra> i'm just idling in front of my lappie waiting for image builds to finish :)
[23:32] <Caesar> Ah :-)
[23:34] <cjwatson> the reason to migrate that stuff to dh7 is that then it would be possible to use that stuff in packages that are already using dh7 for other reasons
[23:34] <cjwatson> (the vast bulk of which don't care, but a few do)
[23:34] <cjwatson> or it seems likely that a few do anyway
[23:34] <cjwatson> by "migrate to" I mean "add support for it in"
[23:49] <highvoltage> hmm, I never realised that windows server also had its own release cadence: http://www.engadget.com/2010/02/10/microsoft-employee-raves-about-windows-next-in-a-blog-post-bl/
[23:50] <slangasek> aaaah, why is seahorse prompting for my passphrase in cleartext?
[23:50] <jdong> haha
[23:51] <ogra> slangasek, apw complained about that before, he might have filed a bug (or TheMuso wh saw it too) i couldnt reproduce it here
[23:51] <seb128> slangasek, I've a suspicious it's due to the upstream change to change the secure text entry widget
[23:52] <seb128> slangasek, bug #520099
[23:52] <seb128> it's probably wrongly assigned to seahorse rather seahorse-plugins though
[23:52] <slangasek> ok
[23:53] <seb128> slangasek, http://git.gnome.org/browse/seahorse-plugins/commit/?id=ed6f046ff86e34925acb8ec045b150d26137d472
[23:53] <seb128> would be my guess as faulty commit
[23:54]  * slangasek fiddles the bug state
[23:54] <slangasek> seb128: thanks
[23:54] <seb128> np
[23:54] <seb128> I will debug that tomorrow if nobody does before
[23:55] <seb128> slangasek, I'm wondering if that's again a bug due to the input method you use
[23:56] <seb128> or rather happening only when using one
[23:56] <seb128> we had one of those previous cycle
[23:56] <seb128> can you try without XIM_... or whatever the variable is called?
[23:57] <seb128> GTK_IM_MODULE=xim
[23:57] <seb128> slangasek, try unsetting GTK_IM_MODULE?