[00:36] <jrwren> UserError: libsound2 isn't part of cloudimg, so its not an issue for ec2, azure, openvz, openstack.
[00:36] <sarnold> is there an easy way to download "newest" build logs for a source package for all supported releases?
[00:38] <UserError> jrwren, i'm sorry I ruined your worldview then :(. It does indeed exist in many of those locations for sound processing support by default.
[00:39] <UserError> as do many unneeded modules even in the minimal VM kernel versions
[00:42] <UserError> https://coderwall.com/p/a56j3w -> https://gist.github.com/steakknife/6086608
[00:52] <psusi> so I'm trying to debug using valgrind and I am being hit with what I can only call an idiocy of Xwindows... while displaying a pop up window, input is locked and you can't alt tab so I can't switch to the terminal running valgrind to tell it yes, I do want to attach gdb now that you noticed the error.. is there a workaround for that?
[00:52] <psusi> ( other than switching to a tty and kill -9ing valgrind )
[00:58] <RAOF> psusi: Welcome to the joy of X11 grabs. Run valgrind from a TTY.
[00:59] <psusi> RAOF, can't you disable or break that stupid lock?  also I just noticed that menus in thunderbird don't seem to do this... I wonder why?
[01:00] <psusi> constantly switching back to a tty to tell valgrind to continue a dozen times before it gets to the real problem does not seem appealing
[01:00] <RAOF> Oh, yes. You can break the lock by enabling the XKB option which allows you to break locks.
[01:00] <psusi> xkb?
[01:01] <RAOF> http://who-t.blogspot.com.au/2012/01/xkb-breaking-grabs-cve-2012-0064.html
[01:02] <sarnold> how have I never heard of control+alt+numpad /*  ??
[01:02] <RAOF> Because we disable it, because it kills your screen lock?
[01:03] <sarnold> exactly, that would have been a pile of fun back at school
[01:06] <psusi> lol
[01:07] <psusi> I remember using that to insert ascii 255 characters into file names in high school
[01:07] <psusi> in DOS it looked like a blank, so you could add it to the end of a file and not be able to tell it was there
[01:07] <psusi> but then you couldn't touch the file or directory if you didn't add the character
[01:07] <psusi> confused the hell out of the teacher when he couldn't see in the directory or delete the file
[01:08] <psusi> then Windows 95 came out and things got even funnier... it would show an _ in place of the 255... and yet still puke when you tried to actually touch the file
[01:08] <sarnold> haha
[01:09] <psusi> I'm sure at one point we had no less than 25 copies of doom on the netware server protected using that little trick
[01:11] <sarnold> awesome :)
[01:12] <psusi> though that wasn't nearly as cool as when a class mate figured out how to use the dos debugger to disassemble login.exe and modify it to connect as a print server object instead of a user... print servers were supervisor equivalent and had no password ;)
[01:13] <sarnold> heh, I never heard of that, either, that also would have been handy to know..
[01:15] <psusi> RAOF, I don't suppose there's a way to make menus NOT grab in the first bloody place? ;)
[01:19] <psusi> RAOF, bah... breaking the lock seems to kill the application
[01:23] <hyperair> odd, why does indicator-application-service refuse to start up after i restart compiz?
[01:26] <RAOF> psusi: No, you can't make menus not grab input; otherwise, they couldn't close when you clicked somewhere else.
[01:27] <psusi> RAOF, why not?  they lose focus when you click elsewhere, and close.. the menus in thunderbird don't grab
[01:28] <RAOF> psusi: Then I suspect the menus in thunderbird are hilariously broken under focus-follows-mouse?
[01:29] <hyperair> oh wait they're back O_O
[01:29] <psusi> wait... so this grab idiocy is all to avoid focus-follows-mouse closing the menu when you move the cursor outside the menu?
[01:30] <RAOF> No, this grab idiocy is the only way guaranteed by the X11 protocol to work.
[01:30] <psusi> for *what* to work?
[01:30] <RAOF> For menus to be able to determine when someone has clicked outside them.
[01:31] <RAOF> Yes, this sucks.
[01:31] <psusi> I don't understand why you would care....
[01:31] <RAOF> Because you want to close the menu when someone clicks outside it?
[01:31] <psusi> so close it when you loose focus?
[01:31] <RAOF> That's standard menu behaviour.
[01:31] <RAOF> There is no guarantee that clicking somewhere else robs you of focus
[01:32] <hyperair> does it not?
[01:32] <psusi> how doesn't it?
[01:32] <RAOF> It's entirely up to the window manager.
[01:32] <hyperair> hmm i suppose it's not directly, yeah
[01:33] <hyperair> psusi: kill compiz repeatedly until it doesn't come back, then try switching focus by clicking =p
[01:33] <psusi> oy ve
[01:33] <psusi> more X11 nicompoopedness
[01:33] <RAOF> Which is why X11 toolkits use the only mechanism guaranteed by the X11 protocol to work :)
[01:33]  * hyperair lols
[01:33] <RAOF> Yeah, this sucks.
[01:34] <psusi> so... what would be so wrong about not closing the menu if your wm is dead and you can't switch to another window?
[01:34] <hyperair> RAOF: is there any window manager around that allows you to click on another window without switching focus?
[01:34] <RAOF> hyperair: Almost certainly.
[01:34] <hyperair> =\
[01:35] <hyperair> so how does it switch focus then?
[01:35] <hyperair> hotkey?
[01:35] <RAOF> Oh, it'd probably switch focus in *some* situation; maybe you need to click on the titlebar or something.
[01:35] <psusi> and X doesn't have a soft grab where you can capture clicks outside your window, but not bloody prevent switching windows?
[01:36] <RAOF> psusi: Correct. “Soft grabs” are “give me a full-blooded grab when $CONDITION”.
[01:36] <RAOF> For $CONDITION that doesn't include “an input event happens outside my window ☺”
[01:37] <psusi> so.. what would be so bad about the menu not closing when you click outside the window and don't loose focus?
[01:37] <RAOF> That's not how a menu is supposed to act?
[01:37] <psusi> so?
[01:37] <psusi> it's also not supposed ot disable alt-tab ;)
[01:37] <RAOF> So toolkits want to provide a menu that provides certain behaviours.
[01:38] <RAOF> Also note that your “lose focus => close menu” breaks under raw X11, because the default behaviour is focus-follows-mouse.
[01:38] <hyperair> derp
[01:38] <psusi> I don't see a problem with the menu closing if you move the mouse to another window
[01:39] <psusi> and have focus-follows-mouse on
[01:39] <hyperair> psusi: what about those times you accidentally move your mouse out of the menu window?
[01:39] <RAOF> Then you're perfectly welcome to write your own toolkit.
[01:39] <RAOF> That doesn't have this behaviour.
[01:39] <RAOF> GTK and Qt both want their menus to behave like menus :P
[01:39] <psusi> how about I just patch gtk to not be stupid? ;)
[01:40] <psusi> I'd like them to behave like menus too... which means not disabling alt-tab
[01:40] <hyperair> eh well at least esc works
[01:40] <psusi> hyperair, yea... unless the app is hung, for instance, by the debugger ;)
[01:40] <hyperair> though you're kinda screwed if the application hangs while a menu is open
[01:40] <hyperair> :)
[01:40] <jrwren> UserError: lol. I promise, you did nothing to my world view.
[01:41]  * psusi wonders when he will be able to swtich to wayland
[01:41] <UserError> The day you install E19
[01:42] <psusi> RAOF, there should at the very least be a setting to disable that behavior in the toolkit... if I wanted to add a patch to do that, what should I search for?  what is the api to grab?
[01:43] <psusi> if only just for debugging ;)
[01:43] <hyperair> psusi: just go look inside the GtkMenu widget code?
[01:43] <psusi> hrm... good idea
[01:43] <RAOF> psusi: You're looking for XGrabCursor, likely.
[01:44] <psusi> export GTK_MENU_NO_GRAB=1
[01:45] <hyperair> nah doesn't look like it
[01:45] <hyperair> grepping shows no XGrabCursor
[01:46] <hyperair> but i see a bunch of XGrabKeys
[01:46] <hyperair> oh i see gdk_device_grab in gtkmenu.c
[01:51] <TJ-> psusi: Would this act as the basis of a workaround, so you can start valgrind/gdb at the correct point? "while ! xprop -name 'New Tab - Mozilla Firefox' | grep -q _NET_WM_STATE_MODAL; do sleep 1; done; xdotool -window id-of-valgrind-window <key-strokes> "
[01:53] <psusi> TJ-, I don't follow... I'm actually running gparted under valgrind and noticed some invalid memory references that sometimes are followed by an actual crash... I can kind of sort of reproduce it by right clicking up a menu at the right time
[01:56] <psusi> funny though... I can't get it to crash when not running under valgrind
[01:56] <TJ-> I was thinking if gparted has a 'modal' window keeping focus, and you need to send input when that appears to the valgrind window to fire up gdb, then a shell fragment like I showed in another terminal can watch for the modal window and when it sees it, can send the key-strokes needed directly to the valgrind/gdb terminal window (thus avoiding the modal focus lock)
[01:57] <TJ-> Obviously, you can tweak the basic idea to trigger on your specific circumstances and windows
[01:59] <infinity> Riddell: Looks like eigen2 was completely removed from Debian in favour of eigen3, but a few things in Ubuntu (almost entirely KDE) still {build-,}depend on it.  Any chance that'll be fixed?
[01:59] <infinity> shadeslayer_: ^
[02:03] <infinity> shadeslayer_: Looks like merging our kdeplasma-addons packaging with Debian (or, at least, pulling eigen3.patch) would sort that package, and probably get it building on ppc64el again (obviously also dropping the arch-restricted build-dep)
[02:28]  * hyperair thinks a gdb session in byobu/screen/tmux would be much more helpful
[02:29] <hyperair> that way you could just connect to it via ssh or from a tty
[02:37] <tarpman> hyperair: ++, also gdbserver
[02:37] <hyperair> oh okay, i didn't know about gdbserver
[02:45] <lifeless> whats the best way to capture a full kernel oops when it happens during cloud-config ?
[02:49] <hyperair> serial connection?
[02:49] <hyperair> netconsole?
[02:56] <lifeless> hyperair: good idea, I'll add a serial connection to the vm
[02:57] <hyperair> :)
[02:57] <lifeless> we were having lockups on that though
[02:57] <lifeless> hopefully I can have cake and eat it
[02:57] <sarnold> lockups on serial? o_O
[03:03] <lifeless> yeah
[03:04] <lifeless> 'fun' and didn't have time to debug...
[04:25] <infinity> ScottK: Any comments on my eigen2/eigen3 observations above to Riddell and shadeslayer_?
[04:26] <ScottK> infinity: About to go to bed and haven't read them yet.  I'll weigh in tomorrow.
[04:26] <infinity> ScottK: Mmkay.
[05:11] <Mirv> Laney: I may not understand the cross-compiling magickry you're trying, but it's possible you need to give qtchooser a specific configuration that understands where to get binaries + libraries
[05:12] <Mirv> or binaries only if libraries are already fine
[05:30] <pitti> Good morning
[05:32] <sarnold> morning pitti, thanks for kicking the retracers yesterday :)
[05:32] <pitti> hey sarnold; thanks for the poke
[05:46] <pitti> sarnold: I adjusted apport to use a per-run temporary launchpadlib cache now, so this shouldn't happen again
[05:47] <sarnold> pitti: oh, cool! :) thanks
[07:52] <dholbach> good morning
[08:07] <taihsiang> hi, I proposed the code merge for fix bug LP: #1284447,  may someone approve the merge and make the update available for users on precise?    https://code.launchpad.net/~taihsiangho/ubuntu/precise/pcmanx-gtk2/fix-for-1284447/+merge/211676
[08:14] <tjaalton> huh, trying to dist-upgrade a machine and I get
[08:14] <tjaalton> The following packages have unmet dependencies: indicator-network : Depends: unity8 (>= 7.82) but it is not going to be installed
[08:15] <tjaalton> claims some pkgs are held..
[08:34] <pitti> tjaalton: you don't happen to have -proposed enabled?
[08:40] <tjaalton> nope..
[09:11] <tjaalton> hrm, jenkins output files don't have a proper mimetype so ffox offers to just save them
[09:11] <tjaalton> shows them as BIN
[09:17] <jamespage> xnox, around? we seem to be hitting issues with MongoDB on ppc64el due to the change in PAGESIZE
[09:17] <jamespage> xnox, wondered if you could help me understand/fixup
[09:43] <Riddell> infinity: will look into eigen today
[09:46] <Laney> Mirv: likewise I don't understand qtchooser, but extending an existing section in cmake fixes it for me - https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/1294186
[09:46] <Laney> ;-)
[10:21] <xnox> jamespage: i'd redirect you to apw =) ppc64el has large pagesizes than any other platform.
[10:21] <xnox> jamespage: db5.3 now does it right, but it is a bit vodoo to me.
[10:30] <xnox> *sigh* https://bugs.launchpad.net/launchpad/+bug/336439
[10:54] <mitya57> Mirv: Sorry, looks like I forgot to bzr add some patches when updating that branch.
[10:55] <mitya57> I will now push a commit that adds them.
[10:57] <Mirv> mitya57: you could just re-merge with the _510 branch too where I added those
[10:57] <Mirv> either way, it's already uploaded to the https://launchpad.net/~ci-train-ppa-service/+archive/landing-017/+packages
[10:57] <mitya57> Ah, I see, you already pushed that
[11:37] <juliank> I just setup a bzr mirror of the python-apt git repository (debian/sid) branch at lp:~juliank/python-apt/debian-sid, maybe that's useful for someone. Note that it does not contain up-to-date mirror lists, those are created by running pre-build.sh
[11:43] <dholbach> hey tkamppeter_ - how are you doing?
[11:44] <dholbach> tkamppeter_, a friend in the office where I go asked me about https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/537970?comments=all - it seems like his company has a customer who would benefit from the bug being fixed - do you know what the state of things is there?
[11:47] <miraiE> hi everyone, how can I make plasma widget Deb package? it's cmake based, and I don't know how to add cmake parameter in debian/rules file
[12:56] <tkamppeter> dholbach, hi
[12:57] <tkamppeter> dholbach, you go to an office? Do you have a second job?
[12:58] <tkamppeter> dholbach, is Rouven Sacha (rouvensacha) your contact concerning this bug?
[13:05] <mpt> Did the behavior of grep change between 13.10 and Trusty? I used to use “ps aux | grep thunder” to tell if Thunderbird is still running, but now that command just hangs
[13:05] <mpt> And it’s not the ps part that’s hanging
[13:06] <jrwren> mpt: that is so crazy that it makes me think you got rooted and the kit replaced grep.
[13:06] <mpt> “touch ~/test && grep ~/test foo” also hangs
[13:06] <cjwatson> no changes at that level in grep
[13:06] <sladen> strace grep?
[13:06] <cjwatson> mpt: that second example is backwards.  you mean  grep foo ~/test
[13:07] <mpt> Aha!
[13:07] <cjwatson> but it shouldn't hang anyway, you should've got an error
[13:07] <mpt> Yeah, “grep foo ~/test” exits immediately
[13:08] <cjwatson> and that doesn't pertain to your first example
[13:08] <cjwatson> what does 'type grep' say?
[13:08] <mpt> grep is hashed (/bin/grep)
[13:08] <cjwatson> ok, so no funny business with aliases
[13:09] <cjwatson> I agree with sladen, the next thing I'd reach for would be ps aux | strace grep thunder
[13:10] <mpt> open("/usr/share/locale-langpack/en/LC_MESSAGES/grep.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
[13:10] <mpt> fstat64(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
[13:10] <mpt> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0xbfdb2a28) = -1 ENOTTY (Inappropriate ioctl for device)
[13:10] <mpt> read(0,
[13:10] <xnox> mpt: what's 'type ps' as well?
[13:10] <mpt> ps is hashed (/bin/ps)
[13:10] <seb128> "(Inappropriate ioctl for device)"?
[13:11] <seb128> mpt, do you use lxc? I wonder if you have an issue similar to the one Laney had recently
[13:11] <seb128> random guessing
[13:11] <xnox> seb128: mpt does use lxc a lot.
[13:11] <mpt> Where “a lot” = “1 hour per week”
[13:11] <cjwatson> seb128: no, successful runs have that same thing
[13:12] <cjwatson> that's just grep checking for the terminal size and finding it's not a terminal
[13:12] <seb128> cjwatson, ok
[13:12] <cjwatson> "read(0," means it's trying to read from stdin and getting no input
[13:12] <cjwatson> so I think I dispute the assertion that ps is not hanging
[13:12] <cjwatson> or at least would like to see further evidence there :)
[13:13] <mpt> “ps aux” by itself completes in real 0m0.028s
[13:13] <cjwatson> no input> more precisely, read on its standard input blocks, which means that the other end hasn't written anything (or not enough to fill a PIPE_BUF) and also hasn't closed its end
[13:13] <cjwatson> maybe pastebin   strace -s1024 -f sh -c "ps aux | grep thunder"
[13:14] <mpt> “ps aux > ~/test && grep thunder ~/test” also works fine
[13:14] <cjwatson> so we can see the whole pipe setup
[13:14] <cjwatson> possibly better bash -c there
[13:14] <cjwatson> assuming you use bash as your interactive shell
[13:14] <mpt> cjwatson, sorry, where would the “bash -c” go?
[13:14] <mpt> at the start?
[13:14] <cjwatson> strace -s1024 -f bash -c "ps aux | grep thunder"
[13:16] <mpt> That’s more than my Terminal buffer
[13:17] <mpt> ok, got it now
[13:19] <mpt> cjwatson, http://paste.ubuntu.com/7119748/
[13:19]  * cjwatson looks
[13:21] <cjwatson> pipe([3, 4])                            = 0
[13:21] <cjwatson> ...
[13:21] <cjwatson> [pid 26509] close(4 <unfinished ...>
[13:21] <cjwatson> [pid 26509] <... close resumed> )       = -1 EBADF (Bad file descriptor)
[13:21] <cjwatson> wtf
[13:21] <cjwatson> oh, no, it had already closed that one
[13:23] <cjwatson> mpt: so that seems to work under strace ...
[13:24] <cjwatson> and nothing seems out of order
[13:24] <mpt> Meanwhile, it has been running in another terminal for 7 minutes now and hasn’t exited
[13:25] <dholbach> tkamppeter, yes, he is - it's a coworking space - I just call it "the office" :)
[13:25] <shadeslayer_> infinity: at the very least I'd like KDE upstream to weigh in on eigen3 migration
[13:25] <sladen> mpt: gdb -p pid_of_running_process    and then ctrl-c inside GDB (if needed)
[13:25] <cjwatson> maybe find the pid of that running grep, ls -l /proc/THAT-PID/fd/0, and try to find that in other /proc/*/fd/
[13:25] <soren> mpt: You could attach strace to the running grep. "strace -p <the pid of grep>"
[13:26] <cjwatson> see what other process is holding the same pipe open
[13:26] <tkamppeter> dholbach, so you do not work at home but rented a place in an office (the "coworking space")?
[13:26] <dholbach> tkamppeter, sometimes like this and sometimes like that
[13:26] <dholbach> :)
[13:26] <ScottK> shadeslayer_: I'd suggest just checking to see if Debian's patch is merged upstream and if it, we go for it.
[13:26] <mpt> soren, forgive me, the only way I know how to find the pid of a process is by running grep on ps in the first place
[13:26] <shadeslayer_> ofcourse, if it's merged then it's alright
[13:27] <mpt> Wait, that’s not true, I can use Find in a text editor
[13:27] <shadeslayer_> ScottK: infinity I also recall seeing some projects switching to eigen3 in 4.12.80, though I can't recall the name
[13:27] <soren> mpt: LOL. Right, of course. My bad :)
[13:27] <ScottK> shadeslayer_: If it's not merged, then ask the Debian people why they haven't upstreamed it.  We ought to get it in 4.13.
[13:27] <tkamppeter> dholbach, the bug seems to be fixed in the current version of Ubuntu. Is your co-worker sticking to an older LTS?
[13:27] <shadeslayer_> *nod*
[13:27] <shadeslayer_> ScottK: I'll have a look at it
[13:27] <dholbach> tkamppeter, precise is the current LTS
[13:27] <ScottK> infinity: ^^^ my opinion
[13:28] <mpt> Process 26532 attached
[13:28] <mpt> read(0,
[13:28] <mpt> soren, ^ well, that was unexciting
[13:29] <tkamppeter> dholbach, the problem seems to be Poppler when I look at the bug report but it is not very clear herewhich change on Poppler fixed it.
[13:30] <soren> mpt: Does this happen only with ps as the input?
[13:31] <mpt> cjwatson, “lr-x------ 1 mpt mpt 64 Mar 19 13:29 /proc/26532/fd/0 -> pipe:[9579047]” … And I don’t understand the second part of your suggestion, sorry
[13:31] <soren> mpt: ls -l /proc/*/fd/* | grep 9579047
[13:31] <dholbach> tkamppeter, ok - so it still needs further investigation, I guess?
[13:32] <mpt> soren, <mpt> “ps aux > ~/test && grep thunder ~/test” also works fine
[13:32] <soren> mpt: Hm... There I go, using grep again.
[13:33] <cjwatson> I would redirect it to a file anyway, because you're going to want to track down the owning process
[13:33] <cjwatson> so  ls -l /proc/*/fd/* >all-fds 2>/dev/null; less all-fds  and then look for 9579047
[13:33] <soren> cjwatson: ls -l /proc/*fd/* will show the full path names, so the owning process hsould be readily available.
[13:34] <mpt> soren, “ls -l /proc/*/fd/* | grep 9579047” has not exited after a minute (I assume it’s quicker than that)
[13:34] <soren> It should be nearly instantaneuos.
[13:34] <miraiE> I've found this https://wiki.ubuntu.com/Packaging/Training/Logs/2009-06-18 and it's what I want to do, but I can't find the debian/* example files
[13:34] <soren> (It's all memory operations)
[13:35] <cjwatson> mpt: redirect to a file to avoid running into whatever the same issue is
[13:35] <soren> mpt: So yeah, what cjwatson said. Pipe it to a file, and use lss.
[13:35] <cjwatson> this is sounding like a broken shell to me, but it's hard to tell ...
[13:35] <mpt> cjwatson, ok, there are three lines with that
[13:35] <cjwatson> you'd get this if the shell failed to close its ends of the pipe it's constructed
[13:36] <mpt> cjwatson, http://paste.ubuntu.com/7119825/
[13:36] <cjwatson> mpt: ps -p 26530 -o pid,args
[13:37] <mpt>   PID COMMAND
[13:37] <mpt> 26530 bash
[13:37] <cjwatson> ok, so as I thought
[13:38] <cjwatson> not that this gets us to a solution, since I'm running current bash in trusty and am not seeing this
[13:38] <soren> mpt: Do you have another user on this system?
[13:38] <mpt> soren, no
[13:39] <soren> mpt: How about the guest account?
[13:39] <mpt> soren, it exists but nobody is logged in to it
[13:40] <soren> mpt: Can you see if it happens if you log in to it?
[13:40] <mpt> (according to indicator-session, at least, and indicator-session never ever lies)
[13:40] <mpt> ok
[13:41] <mlankhorst> can someone remove mesa from proposed? didn't mean to get uploaded to archive
[13:43] <Laney> seb128: ^?
[13:44] <seb128> Laney, mlankhorst: is that a "need more testing but might be ok" thing, e.g proposed block would be enough?
[13:44] <mlankhorst> no
[13:44] <seb128> ok, deleting it then
[13:45] <mlankhorst> it's something that should have gone to a ppa so I could run some piglit tests
[13:47] <mpt> soren, it works fine in the guest session.
[13:47] <mlankhorst> does ubuntu auto reject versions with ~ppa in the name?
[13:48] <mpt> Meanwhile, I can no longer move my mouse pointer in *this* session.
[13:48] <seb128> Laney, mlankhorst: done
[13:49] <mlankhorst> ty
[13:51] <soren> mpt: Interesting.
[13:53] <miraiE> I've done:   dpkg-depcheck cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` -DQT_QMAKE_EXECUTABLE=/usr/bin/qmake-qt4
[13:54] <miraiE> and it printed several depend package
[13:54]  * mpt tries to log out and crashes unity-panel-service
[13:54] <mpt> Stop this operating system I want to get off
[13:55] <miraiE> please, how to convert those command in debian/rules ?
[13:57] <mitya57> miraiE: List those packages in Build-Depends field of debian/control
[13:58] <miraiE> mitya57: okay, I'll try
[14:06] <mpt> cjwatson, so should I report a bug on bash?
[14:09] <cjwatson> mpt: that's my best guess
[14:30] <tkamppeter> dholbach, I have asked the person for more info on the bug.
[14:30] <mpt> cjwatson, ok, reported bug 1294678, thanks for all the instructions
[14:33] <Riddell> infinity: looks like debian has a load of patches to port kde bits to eigen 3 only some of which have been sent upstream and they're still under discussion for issues in the patches.  is there a reason you want to switch or just don't like having two versions of same library?
[14:35] <mpt> (and thanks soren and sladen too)
[14:36] <apw> jamespage, oh goody
[14:38] <ogra_> pitti, would there be a chance to get rid of the xvfb dep in ofono-phonesim-autostart ? it cause quite some havoc in the touch tests (since the initial test setup installs it, so there is always an xserver running)
[14:38] <ogra_> (we are just discussiong it in #ubuntu-ci-eng)
[14:38] <pitti> ogra_: ofono-phonesim is a graphical program, so it needs some X server
[14:39] <pitti> ogra_: it's Qt, so presumably at some day it could also use some "framebuffer Mir", but we don't have that yet AFAIK?
[14:39] <ogra_> on touch ?
[14:39] <ogra_> afaik we only use the sim emulation of it
[14:39] <pitti> and it uses Qt 4 still :/
[14:39] <pitti> ogra_: yes, it's just one program
[14:39] <ogra_> and use the dialer and messaging apps as frontends
[14:40] <pitti> ogra_: how does it interfere, OOI? It's running as a separate user on a private D-BUS with a private Xvfb, I thought it was shielded quite well
[14:41] <ogra_> pitti, well, the constantly running xvfb kind of causes issues ... i would like that ofono-phonesim-autostart only gets installed for the two tests that actually use it, but apparently the current setup doesnt offer this ... so xvfb is contantly running
[14:42] <ogra_> *constantly
[14:42] <pitti> ogra_: right; the whole -autostart packaging trick is because tests run as user and don't have root, so they can't set up phonesim by themselves
[14:42] <ogra_> there are apps and tests that are running on desktop too ... so the running xserver can confuse them
[14:42] <doko> tvoss, https://launchpad.net/ubuntu/+source/dbus-cpp/1.0.0+14.04.20140123.1-0ubuntu1  if this has to be GCC specific, please make it conditional on ppc64el, not having 4.7
[14:42] <pitti> so back then, when we discussed that between fginther, awe, and me, we found that having the test depend on such an o-f-a package would be the best solution
[14:42] <ogra_> (which then results in false negatives for failures)
[14:43] <doko> tvoss, and what was the reason to fall back to 4.7?
[14:43] <tvoss> doko, the platform-api is stuck with gcc 4.7 for the moment
[14:43] <ogra_> pitti, right, but currently it isnt the app test that depends on it but the whole test run
[14:43] <pitti> ogra_: confuse how? it's a separate $DISPLAY, dbus, and everything; phonesim is only feeding ofonod, the "real" UI doesn't even know of its existance
[14:43] <pitti> ogra_: ah, we install all tests and their dependencies at the same time, and then run all tests?
[14:43] <pitti> ogra_: (for image testing, not for MPs)
[14:44] <doko> tvoss, which ppc64el doesn't have
[14:44] <ogra_> pitti, well, today we had the security test fall over because there is an active socket in /tmp/.X11-unix/ for example ... we had other issues before
[14:44] <tvoss> doko, yup. So what do you want me to do exactly?
[14:44] <pitti> ogra_: so how does it confuse other tests? just because of the socket, or does it eat inordinate amounts of CPU/RAM/etc?
[14:44] <ogra_> pitti, we run phablet-click-setup ... which installs all needed extra bits for click tests
[14:44] <ogra_> phonesim is among them
[14:45] <ogra_> while the fix is indeed to only have it for the tests that need it
[14:45] <doko> tvoss: build depends: g++-4.7 [!ppc64el], and change the rules file to use gcc/g++ on ppc64el
[14:45] <ogra_> i was wondering if there isnt a way to also decouple it from X completely
[14:45] <pitti> ogra_: I know how to make the socket invisible (we could run phonesim in an unshared namespace), if it's only that
[14:45] <ogra_> (which is why i pinged you)
[14:45] <tvoss> doko, ack, on my list
[14:46] <pitti> ogra_: right, so we'd need to re-set the device for each test, which sounds expensive
[14:46] <doko> tvoss, thanks
[14:46] <pitti> ogra_: do you think if we hide it "more" that would be ok? then we coudl still install and run all tests at once
[14:46] <ogra_> yeah, the tests already take 5h ... adding more reboots will only add to that
[14:47] <xnox> bfiller: hello, are you around?
[14:47] <ogra_> well, it doesnt feel right to have an xseerver run on the phone at all ... but yeah, hiding might already be an improvemment
[14:47] <bfiller> xnox: yes
[14:47] <dholbach> thanks tkamppeter
[14:47] <xnox> bfiller: can we make a gallery-app branch merge / release into the archive and click?
[14:48] <xnox> bfiller: i'm more interested in the click into the click store with this merge proposal https://code.launchpad.net/~barry/gallery-app/xnox-pkgresources/+merge/210877
[14:48] <bfiller> xnox: we're working on that, see line 15 of CI Train sheet
[14:48] <bfiller> xnox: I can include that MR in the silo so it gets released with the rest
[14:48] <xnox> bfiller: is that for click, or in the archive upload, or both?
[14:48] <pitti> ogra_: well, yes, but that's an intrinsic requirement of ofono-phonesim ATM
[14:49] <ogra_> right, i understand
[14:49] <bfiller> xnox: would be for both, sergiusens or someone I think has to manually do the click release after the deb gets released
[14:49] <pitti> ogra_: of course that could in theory be changed to not show an UI and only be a D-BUS service, but it's not doing that ATM
[14:49]  * jdstrand notes that this is not needed for the security tests to pass
[14:49] <jdstrand> I'm making them less brittle
[14:49] <ogra_> pitti, would be nice if you could put that on your TODO for later :)
[14:49] <sergiusens> bfiller, yeah; is that done?
[14:49] <bfiller> sergiusens: no
[14:49] <sergiusens> bfiller, as in, did it get to trunk?
[14:49] <xnox> bfiller: i see. Yes, please include that merge proposal in the landing (  https://code.launchpad.net/~barry/gallery-app/xnox-pkgresources/+merge/210877  )
[14:49] <bfiller> sergiusens: we found issues
[14:50] <bfiller> xnox: I'll include that in the silo then
[14:50] <barry> xnox, bfiller \o/
[14:50] <xnox> bfiller: it's no-code change, only autopilot testing code fix-up.
[14:50] <ogra_> pitti, i'll nag CI to only have it installed for phone related tests anyway, so on low prio for you :)
[14:50] <bfiller> xnox: ack
[14:50] <pitti> ogra_: hiding the socket, yes; rewriting phonesim, not that much :) (in fact, much of its functionality actually depends on Qt, like sending SMS messages)
[14:50] <bfiller> should be fine
[14:50] <ogra_> ok
[14:50] <pitti> ogra_: bug report appreciated for hiding the socket, with some details
[14:51] <barry> xnox: although i'm not fond of the auto-pruning of empty files (e.g. __init__.py)
[14:51] <xnox> bfiller: sergiusens, barry and myself pretty-much give you 24/7 coverage to respond to any queries as we all can't wait for it to land =)))))
[14:51] <bfiller> xnox, barry : just make sure that merges cleanly with https://code.launchpad.net/~artmello/gallery-app/gallery-app-multiple-bug-fixes/+merge/211154
[14:51] <xnox> bfiller: let me confirm / check that.
[14:53] <xnox> bfiller: "All changes applied successfully."
[14:59] <bfiller> xnox: cool, I'll add it to the silo
[15:03] <dobey> xnox: hi
[15:03] <dobey> xnox: for "dpkg-architecture -aarmhf cmake ../ && make" to work, i need to enable armhf as an arch on my machine, and then install the :armhf versions of all the build-deps?
[15:05] <xnox> dobey: almost, but that will most likely break a few things on your desktop. It's best to use a schroot. E.g. click chroot create / click chroot run, or mk-sbuild --target
[15:05] <xnox> dobey: for simply things (which don't use gl*/qt*) doing it on your desktop is safe as well.
[15:05] <xnox> dobey: are you already using mk-sbuild / sbuild, and what are the projects that you want to cross-compile?
[15:06] <dobey> xnox: i want to compile lp:unity-scope-click. i'm not using sbuild already, no (though i do have it insatlled)
[15:08] <xnox> dobey: test-building here, will let you know in a moment.
[15:09] <dobey> xnox: ok, thanks!
[15:14] <xnox> dobey: unfortunately automatic installation of cross-dependencies fails, as a few *accounts* *oauth* etc things are not Multi-Arch:same.
[15:14] <xnox> dobey: let me see if we can fix this.
[15:14] <dobey> ah, ok
[15:14] <xnox> cjwatson: have you already been "multiarchifying" accounts/oauth/signon things?!
[15:14] <dobey> i'll try sbuild i guess
[15:15] <cjwatson> xnox: some
[15:15] <cjwatson> xnox: I'm specifically working on making ubuntu-sdk-libs-dev:armhf installable on !armhf
[15:16] <xnox> dobey: well, yeah native compilation should work $ mk-sbuild --arch armhf; sbuild --arch *.dsc; will use qemu-user-static and will slowly natively compile. But i'll see if i can fix cross-compilation for that.
[15:16] <cjwatson> xnox: probably overlaps slightly with you but not much.  The things I have in other people's landing queue are dee and libaccounts-glib
[15:16] <xnox> cjwatson: ack. thanks. I'll see which bits i can propose for landing.
[15:18] <dobey> xnox: eh, seems like sbuild will be the fastest option, and i need to do the building /now/, so i'll go with that
[15:19] <dobey> hopefully it doesn't break for some silly reason due to config differences between local sbuild, and what the launchpad builders are doing
[15:19] <infinity> Riddell: It's not even a shared library, it's a static (in 2) headers-only (in 3) set of stubs, so I'm not super concerned, I just ran into the "it's not even in Debian" thing when I was hunting why it was broken on ppc64el.
[15:20] <infinity> Riddell: Fixing it on ppc64el should be trivial, I didn't bother going that route while waiting on KDE/eigen options.
[15:21] <Riddell> infinity: yep, I'll try and send that patch upstream today
[15:21] <dobey> xnox: ugh. "mk-sbuild --target armhf trusty" failed pretty horribly :(
[15:23] <dobey> xnox: http://pastebin.ubuntu.com/7120328/
[15:23] <xnox> dobey: --skip-proposed should help cross-chroots. "--target" creates a "cross-compilation chroot". For qemu-user-static, you want "mk-sbuild --arch=armhf trusty"
[15:24] <xnox> dobey: not sure why it's using "archive.ubuntu.com" for you, as armhf is on "ports.ubuntu.com (us.ports.ubuntu.com).
[15:24] <xnox> dobey: did you customize it somehow?
[15:24] <dobey> xnox: no, i just copied the command from your e-mail, which is mk-sbuild --target armhf trusty
[15:25] <xnox> dobey: oh, maybe it does do ports, just earlier / no included in the pastebin.
[15:25] <xnox> dobey: but, cross-compilation chroot will not work against unity-scope-click at the moment =)
[15:25] <dobey> xnox: no, i don't see ports in the output
[15:26] <dobey> oh
[15:26] <xnox> dobey: right, let me strip my chroots and try from scratch locally here.
[15:27] <dobey> i'll try --arch then
[15:33] <ScottK> Nice thing about doing a lucid backport is at least there's not wait for sparc and ia64 builders ....
[15:33] <dobey> xnox: hrmm, with --arch it is trying to use archive instead of ports, too :(
[15:34] <dobey> xnox: so i'm getting pretty much the exact same failure
[15:34] <xnox> dobey: $ mk-sbuild --arch armhf --name foobar trusty
[15:34] <xnox> /usr/sbin/qemu-debootstrap
[15:34] <xnox> [sudo] password for xnox:
[15:34] <xnox> ion: Running command: debootstrap --arch armhf --foreign --variant=buildd --components=main,restricted,universe,multiverse --include=eatmydata trusty /var/lib/schroot/chroots/foobar-armhf http://ports.ubuntu.com/ubuntu-ports
[15:34] <xnox> ion: Retrieving Release
[15:34] <xnox> dobey: note how it calls ports like on of the first things...
[15:35] <xnox> dobey: what's your host-OS?
[15:36] <infinity> ScottK: Hah, yeah.  You, the kernel team, and the security team.  Pretty much everyone else has given up on lucid SRUs.
[15:36]  * xnox is not sure if for-example qemu-debootstrap / debootstrap / sbuild / mk-sbuild can be affected by user/system configuration files.
[15:36] <xnox> dobey: do you have ~/.mk-sbuild* files?
[15:36] <dobey> i do
[15:36] <pitti> ~/.mk-sbuild.rc exists and is useful, so that can impact mk-sbuild indeed
[15:37] <ogra_> qemu-desbootstrap is just a wrapper around debootstrap ... doesnt know any configs
[15:37] <ScottK> infinity: Keeping the clamav backports going isn't very hard.  Only minor package mods needed.  Nothing compared to what I had to do to keep dapper and hardy in the mix by this point.
[15:37] <xnox> dobey: well, check their content. and probably remove any archive definitions, as correct archies are picked by default anyway.
[15:38] <dobey> ok
[15:40] <infinity> ScottK: Yeah.  When lucid goes away, it should be even more pleasant, thanks to trusty and precise being quite similar on the packaging toolchain front.
[15:41] <infinity> xnox: Erk, did we not fix mk-sbuild to name those chroots properly?
[15:41] <infinity> xnox: We should.
[15:42] <infinity> xnox: (That example above should be /var/lib/schroot/chroots/foobar-amd64-armhf, if it's a cross-chroot)
[15:43] <doko> Mirv, I see that qtjsbackend-opensource-src is removed in Debian. should that be removed for trusty as well?
[15:43] <xnox> infinity: above is correct. "--arch" is "qemu-powered-native", not "amd64-armhf" cross.
[15:44] <xnox> doko: removal request was filed, and infinity removed it from "release pocket" but there is another on in -proposed pocket.
[15:44] <infinity> xnox: Oh, that's a native chroot?
[15:44] <xnox> infinity: can you zap qtjsbackend from -proposed? unless you already have.
[15:44] <xnox> infinity: --arch armhf is native, yes.
[15:44] <cjwatson> I think we fixed the naming ...
[15:45] <infinity> xnox: I didn't catch the whole backscroll, I thought it was a cross chroot.  Nevermind. :P
[15:45] <xnox> infinity: (well it's qemu-debootstrapped, so there is qemu-user-static binary in the chroot, updated on each entry into it, I think.....)
[15:45] <cjwatson>     CHROOT_NAME="${name}-${CHROOT_ARCH}-${TARGET_ARCH}"
[15:45] <cjwatson> yeah
[15:46] <infinity> xnox: Nuked.  Didn't notice the spare copy in proposed.
[15:51] <happyaron> bdmurray: hi, I know that, and as explained it's something required by a cooperation project. so I'd appreciate it can be accepted.
[15:55] <jamespage> apw, care to educate me?
[15:55] <xnox> infinity: cool =)
[16:04] <apw> jamespae, coul dyou point me at the issue you are having, so i can see if it is similar
[16:10] <rbasak> stgraber: have you seen bug 1072518?
[16:10] <rbasak> stgraber: 120 users are complaining that "sudo restart networking" kills dbus
[16:11] <mlankhorst> oh
[16:11] <mlankhorst> hm that could explain things
[16:11] <mlankhorst> I had a bug in xorg-server about something like that with 'no screens found'
[16:12] <xnox> rbasak: my cunning plan is to turn networking into a task job, thus during normal operation it's stopped and thus "stop networking" and "restart networking" does nothing =)
[16:13] <rbasak> xnox: where were you at the UDS session we had on this last week? :)
[16:13] <xnox> rbasak: oh, i was in another session. Maybe i should rewatch it.
[16:14] <stgraber> rbasak: yeah, that boils down to dbus shutting down after networking which is entirely reasonable, except that our whole system depends on dbus
[16:14] <stgraber> xnox: except that we actually need networking to be brought down on shutdown
[16:14] <rbasak> stgraber: do we need to explain in the bug and mark it Won't Fix?
[16:14] <stgraber> xnox: I think we already discussed this :)
[16:15] <infinity> I wish I knew where people got the idea that "restart networking" (and /etc/init.d/networking resart before that) was a good idea.
[16:15] <stgraber> rbasak: yes, I think we should. I believe I "won't fixed" a similar bug against ifupdown a while back
[16:15] <infinity> But we really shouldn't give people such a massive shotgun to apply to their feet either.
[16:15] <xnox> stgraber: i thought splitting it into two tasks should be reasonable: networking -> start on (current start on) and do setup; networking-shutdown -> start on (current stop on condition, do the tear down, emit deconfiguring networking et.al.)
[16:16] <rbasak> stgraber: do you mind doing it with an appropriate comment, please?
[16:16] <stgraber> xnox: that'd probably work, though I'm reasonably sure people will then try and call networking-shutdown + networking...
[16:16] <rbasak> Or maybe duplicate to the other bug?
[16:16] <infinity> stgraber: Why does networking need to be shutdown at all?
[16:16] <xnox> rbasak: stgraber: won't fixed bugs disappear from search results. The current bug is edit by me to shout and tell to "DO NOT DO THAT"
[16:17] <mlankhorst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1235516
[16:17] <infinity> stgraber: Are we trying to be polite and release DHCP leases, or is there some more useful reason?
[16:17] <xnox> rbasak: stgraber: and it "affects" all the right packages people search about this issue.
[16:17] <rbasak> xnox: fair enough, but keeping it open also tells people to expect it to be fixed, including "why isn't it fixed yet?" type comments both on the bug and elsewhere.
[16:17] <rbasak> xnox: "Won't Fix" is the point of a status that tells them otherwise.
[16:18] <rbasak> IMHO, if that means that it doesn't appear in search results and so people don't mark Won't Fix when they should, then that's a symptom that the default search result is wrong.
[16:18] <xnox> stgraber: rbasak: in networking.conf we can do "wall System shutdown initiating in 30s; sleep 30" that should be enough time for people to hit ctrl-c on "restart networking" prompt.
[16:19] <rbasak> xnox: won't that delay system shutdown?
[16:19] <stgraber> infinity: right, we need dhclient to shut down properly, we then want to get dbus to die and after that all network partitions are unmounted so that hopefully we can remount the world r/o at the end and not suffer dataloss
[16:19] <xnox> rbasak: stgraber: or actually, we can bail restarting networking, in pre-stop. Check for events -> if we are going for shutdown, continue. Otherwise bail stopping networking job, and send a Wall explaining what's going on.
[16:20] <infinity> stgraber: umounting network fielsystems shouldn't have anything to do with "networking shutdown".
[16:20] <xnox> rbasak: stgraber: thus it should be interractive-friendly, not delay shutdown, nor change any job/event semantics.
[16:21] <infinity> Having it only run if you're in a shutdown sequence seems sane, if that's reliably doable.
[16:21] <stgraber> xnox: how would you check for the shutdown event?
[16:22]  * infinity misses runlevels. :P
[16:22] <mlankhorst> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/1277553 fun fun
[16:22] <xnox> stgraber: check the UPSTART_EVENT variable set by upstart with reason why "stop on" got triggered. If it's unmounted-remote-filesystems -> we are shutting down.
[16:22] <xnox> stgraber: if it's empty, then we got interractively triggered.
[16:22] <xnox> stgraber: and i can send wall message about it.
[16:23] <infinity> Why message at all if it's interactive?
[16:23] <infinity> Just do nothing.
[16:23] <xnox> (e.g. DO NOT STOP or RESTART NETWORKING) using webdings pictograms to be language neutral =)
[16:23] <xnox> infinity: hm, true.
[16:23] <infinity> "Your system will self destruct in 30 seconds" isn't a helpful upstart job.
[16:24] <stgraber> xnox: so add a pre-stop which does [ -z "$UPSTART_EVENT" ] && echo "Someone tried restarting the networking job, this isn't supported." && exit 1
[16:24] <stgraber> then when they file a bug I can look at the attached networking.log and automatically mark the bug won't fix if I see that string? :)
[16:24] <xnox> stgraber: right, and that string will only end up in /var/log/upstart/networking.log which is fine.
[16:24] <xnox> stgraber: haha about checking the string =)
[16:25] <rbasak> I think you can have Launchpad do that automatically for you :)
[16:25] <rbasak> (eg. suggest it as a dupe of this bug)
[16:26] <jodh> stgraber: make that $UPSTART_STOP_EVENTS
[16:27] <stgraber> jodh: thanks
[16:27] <xnox> jodh: hmmmm..... is pre-stop at all executed for jobs without main process?
[16:28] <stgraber> ok, so added the pre-stop to my todo, will look into this soonish. I'm sure people will still complain even with this but at least they won't trash their systems.
[16:28] <cjwatson> infinity: On the contrary, if my system *is* going to self-destruct in 30 seconds, I totally want an upstart job to tell me :-)
[16:28] <xnox> stgraber: jodh: pre-stop doesn't seem to be executed for a job without a main process =(
[16:29] <xnox> stgraber: jodh: when stopping the job interractively with "stop myjob"
[16:31] <stgraber> and I don't suppose there's a way to prevent the job from switching to stopped state from post-stop (that'd be quite wrong I think...)
[16:31] <xnox> stgraber: well, we could start the job again and bail / not-do ifdown.
[16:32] <xnox> jodh: stgraber: i think it's a bug that pre-stop is not executed if there is no main process.
[16:32] <jodh> xnox: yes, it does appear to be.
[16:33] <xnox> jodh: i guess the logic is /before/ the main process is killed/terminated. But when one doesn't have exec/script stanza, there will _not_ be a main process. It's a virtual job.
[16:34] <jodh> xnox: right, init(5) doesn't make the behaviour clear but maybe not a bug after all. Certainly needs better doc though.
[16:34] <rbasak> Is there any reason for the behaviour to be different, though?
[16:35] <rbasak> It seems that it would be more useful if pre-stop did work in this case. Would that cause any issues anywhere else?
[16:36] <jamespage> apw, https://bugs.launchpad.net/ubuntu/+source/mongodb/+bug/1294747
[16:36] <stgraber> yeah, if we could get pre-stop to work, that'd be quite useful here, I don't like the whole calling start from post-stop thing, that's a massive hack :)
[16:36] <xnox> rbasak: actually you are right, there is no combination where there would be side-effects.
[16:37] <stgraber> pre-start and post-start get executed fine, so it'd make sense to me to also have pre-stop and post-stop, not just post-stop
[16:37] <xnox> stgraber: yeah, plus calling start from post-stop does quite work one gets:
[16:37] <xnox> $ sudo stop foo333
[16:37] <xnox> stop: Job failed while stopping
[16:37] <xnox> stgraber: and in the log it says job is already running.
[16:37] <jodh> xnox/stgraber: can one of you raise a bug on this please?
[16:37] <xnox> jodh: yeah, i will.
[16:50] <xnox> jodh: hm, i can't seem to make pre-stop to bail stopping. With or without main process. I get "stopped/failed" event emitted, yet main process is killed and end result is "stop/waiting"
[16:50] <xnox> jodh: filing full bug report.
[16:55] <xnox> jodh: https://bugs.launchpad.net/upstart/+bug/1294753
[16:58] <xnox> stgraber: with current upstart, splitting networking.conf into two "task jobs" with shutdown one bailing out in "pre-start" is the only way that actually works. It seems that /everything/ can be stopped.
[16:59] <xnox> stgraber: ah, I have something that does work =)
[17:00] <stgraber> xnox: if it's not too much work, I think we should just get the pre-stop stuff in upstart and use it. networking.conf is a major pain to change because of migration code (checksums and other similar fun) so splitting it would make things even worse...
[17:02] <xnox> stgraber: so i have something simple, which works, but has a stray / bogus event>
[17:02] <xnox> start on stopped/failed networking
[17:02] <xnox> pre-stop exec false
[17:03] <xnox> that results in: stop networking => to print networking start/running
[17:03] <xnox> stgraber: "stopped networking" event is emitted. but at the moment nothing is sensitive to "stopped networking" i think.
[17:04] <xnox> stgraber: since "deconfiguring-networking" event is actually used. I'm not sure what happens on the other side of the startpar bridge (sysv-init)
[17:04] <xnox> stgraber: but imho, this would be improvement over "my machine got destructed"
[17:07] <xnox> sorry "post-stop exec false"
[17:10] <rbasak> barry: any plans to fix python3-genshi in Trusty? Looks like there's a fix in Debian now?
[17:11] <rbasak> jodh: well, we want to make "networking" unstoppable, right? And any real service could have respawn disabled and then killed.
[17:12] <xnox> $ sudo stop test2
[17:12] <xnox> stop: Job failed while stopping
[17:12] <xnox> excellent!
[17:12] <xnox> $ sudo cat /var/log/upstart/test2.log
[17:12] <xnox> Stopping or Restarting networking job is not supported. Use ifdown & ifup to reconfigure desired interface.
[17:32] <barry> rbasak: yes, i uploaded the new genshi to debian.  i just need to sync it over
[17:35] <rbasak> barry: thanks! I'll leave you to it I guess.
[17:35] <rbasak> Do you want a bug?
[17:36] <barry> rbasak: nope, jfdi'd it :)
[17:36] <rbasak> barry: thanks!
[17:36] <barry> rbasak: np!
[17:41] <xnox> stgraber: https://launchpadlibrarian.net/170043449/lp1072518.patch i've attached it to the bug report. No idea if i need to adjust anything else when touching that conffile.
[17:41] <apw> jamespage, ok that assertion implies it is a different issue but related.  essentially that assertion is catching the case that the db5.3 was performing and getting broken by
[17:41] <apw> jamespage, if i am reading it right basically it is asaying am i rounding to the OS page size at least, and the answer is no, so it blows up
[17:43] <stgraber> xnox: hmm, so the problem with that is that if I define a new interface in /etc/network/interfaces and then do "stop networking", it'll be brought up :)
[17:43] <stgraber> I think the real fix there is to first make upstart allow the pre-stop and then use that
[17:45] <UserError> The amount of purely ARM cruft has been calculated /  EST
[17:45] <UserError> it is now officially greater than VDPAU would take as a diff
[17:45] <xnox> stgraber: really? which job/event will configure it?
[17:45] <xnox> stgraber: all existing things would be in the state running already, and i don't see how any new ones would be started.
[17:45] <stgraber> xnox: networking
[17:46] <xnox> stgraber: oh, i see!
[17:46] <xnox> stgraber: i should then guard pre-start script agains the same event.
[17:46] <stgraber> yeah, not hackish at all ;)
[17:47] <xnox> stgraber: so if we are started by "stopped networking RESULT=failed PROCESS=post-stop EXIT_STATUS=100" we'd not do "ifup -a" =))))
[17:47] <xnox> stgraber: it is standalone, minimal, and SRUable =)
[17:47] <xnox> stgraber: and doesn't depend on which upstart one is running ;-)
[17:48] <jamespage> apw, thanks for looking
[17:49] <xnox> stgraber: i don't want to introduce unstoppable jobs though. Cause i do think that "stop foo" should be resulting in stopping the main process, regardless of anything, eventually.
[17:50] <apw> jamespage, i would assume what has occured is it has rounded to the filesystem block size, 4K or something and checked it is rounded to the memory one
[17:50] <apw> which in the normal case is the same
[17:52] <xnox> stgraber: actually i'm not sure it's a bad thing for ifup -a to be called, cause this loop is executed on $ restart networking as well.
[17:52] <xnox> stgraber: then you would expect the new interface to be configured.
[18:01] <xnox> stgraber: added a patch to do nothing in pre-start https://launchpadlibrarian.net/170045337/lp1072518-no-start.patch
[18:01] <xnox> stgraber: i'd rather have hacks in one job, then upstart itself =)
[18:04] <stgraber> xnox: ok, thanks for the patch, I'll think about it...
[20:15] <charles> Sarvatt: ping
[20:15] <charles> Sarvatt: I noticed you updated https://bugs.launchpad.net/indicator-datetime/+bug/1244285 earlier today
[20:16] <charles> Sarvatt: were you doing that for bookkeeping (New -> Confirmed) because there was more than one reporter, or are you seeing this yourself?
[20:18] <Sarvatt> charles: I'm not seeing it myself, a friend is and is following that bug. I just added the other project and set it to the same status as the other ones in hopes it would get looked at, sorry if I screwed anything up!
[20:19] <Sarvatt> he could fix it by disabling auto login and make it broken again by turning it back on, thought the new info might help
[20:19] <charles> Sarvatt: no, nothing like that, you didn't screw anything up
[20:20] <charles> Sarvatt: I just wanted to pick your brains first since it would be faster than asking an open question in the ticket :)
[20:20] <charles> thank you though :)
[20:44] <ThiagoCMC> Guys, I just did an "apt-get update / dist-upgrade" on my Ubuntu 14.04 (Unity 7) and there is no more Window Manager... How can I debug it?
[20:44] <ThiagoCMC> I'm running GNOME right now...   :-\
[20:45] <UserError> That's something you Mutter under your breath around here.
[20:51] <infinity> ThiagoCMC: Do you have the terminal log from the dist-upgrade?  Did it remove packages?  Did you let it remove packages without reading which ones?
[20:57] <infinity> jamespage: Hah, the "solution" in the IBM mongo branch to your woes is to disable that test. ;)
[20:58] <infinity> jamespage: Anyhow, there are lots of other changes in the branch, so I'll pull that all in and hopefully unblock you.
[21:08] <ScottK> It would be nice if someone with access would throw http://kitterman.com/ubuntu/libopendbx_1.4.6-5.dsc at a ppc64el PPA and see if it builds.
[21:09] <ScottK> If not, build log please.
[21:10] <Logan_> ScottK: I don't think there are any ppc64el PPA builders atm
[21:11] <ScottK> Logan_: No public ones.
[21:11] <Logan_> :O
[21:11] <ScottK> Or maybe it's just porter boxes.
[21:11] <ScottK> You could be right.
[21:11] <Sarvatt> ScottK: keep your eye on https://launchpad.net/~canonical-x/+archive/x-staging/+builds?build_text=&build_state=all
[21:12] <ScottK> Sarvatt: Thanks.
[21:17] <Sarvatt> ScottK: built fine, https://launchpad.net/~canonical-x/+archive/x-staging/+build/5829072
[21:19] <ScottK> Sarvatt: Yep.  Thanks.  I didn't want to do the upload to Debian, wait, upload to Ubuntu round trip without a test.
[21:58] <jamespage> infinity, well that's a great fix!
[21:58] <jamespage> lol
[22:00] <infinity> jamespage: I think the implication might be that the test is just wrong, but I'm going to talk to the branch maintainer and get his take on it.
[22:07] <ThiagoCMC> guys, is there any problem with Unity and its Window Manager right now? I just upgraded my Ubuntu 14.04 (apt-get dist-upgrade) and the Window Manager doesn't appear (when with Unity 7)... But Gnome session works...
[22:07] <ThiagoCMC> any tips to debug it?!
[22:07] <ThiagoCMC> nothing appear on /var/log/Xorg.0.log either
[22:10] <infinity> ThiagoCMC: Do you have the terminal log from the dist-upgrade?  Did it remove packages?  Did you let it remove packages without reading which ones?
[22:13] <ThiagoCMC> I don't have the terminal logs anymore, sorry, but, I saw no errors there (yes, I always pay attention to the apt-get output)... No package was removed. Also, "apt-get -f install" doesn't point any problems...
[22:14] <sarnold> check /var/log/ there may be some install/remove logs there too
[22:14] <ThiagoCMC> Also, I didn't tried Unity8...    =P
[22:16] <ThiagoCMC> sarnold, no logs about the Unity session startup?
[22:16] <sarnold> ThiagoCMC: I was thikning of /var/log/dpkg.log
[22:27] <ThiagoCMC> Well, never mind... I'll wait a few more weeks for the stable release, so I can go back to Unity again... Tks!!
[22:27] <ThiagoCMC> =)
[22:28] <sarnold> have fun! :)
[22:44] <ThiagoCMC> ^_^