| === vibhav is now known as Guest80328 | ||
| 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:36 |
| 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:38 |
| UserError | as do many unneeded modules even in the minimal VM kernel versions | 00:39 |
| UserError | https://coderwall.com/p/a56j3w -> https://gist.github.com/steakknife/6086608 | 00:42 |
| 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:52 |
| RAOF | psusi: Welcome to the joy of X11 grabs. Run valgrind from a TTY. | 00:58 |
| 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? | 00:59 |
| 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:00 |
| RAOF | http://who-t.blogspot.com.au/2012/01/xkb-breaking-grabs-cve-2012-0064.html | 01:01 |
| ubottu | xkeyboard-config before 2.5 in X.Org before 7.6 enables certain XKB debugging functions by default, which allows physically proximate attackers to bypass an X screen lock via keyboard combinations that break the input grab. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0064) | 01:01 |
| sarnold | how have I never heard of control+alt+numpad /* ?? | 01:02 |
| RAOF | Because we disable it, because it kills your screen lock? | 01:02 |
| sarnold | exactly, that would have been a pile of fun back at school | 01:03 |
| psusi | lol | 01:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| sarnold | awesome :) | 01:11 |
| 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:12 |
| sarnold | heh, I never heard of that, either, that also would have been handy to know.. | 01:13 |
| psusi | RAOF, I don't suppose there's a way to make menus NOT grab in the first bloody place? ;) | 01:15 |
| psusi | RAOF, bah... breaking the lock seems to kill the application | 01:19 |
| hyperair | odd, why does indicator-application-service refuse to start up after i restart compiz? | 01:23 |
| RAOF | psusi: No, you can't make menus not grab input; otherwise, they couldn't close when you clicked somewhere else. | 01:26 |
| psusi | RAOF, why not? they lose focus when you click elsewhere, and close.. the menus in thunderbird don't grab | 01:27 |
| RAOF | psusi: Then I suspect the menus in thunderbird are hilariously broken under focus-follows-mouse? | 01:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| * psusi wonders when he will be able to swtich to wayland | 01:41 | |
| UserError | The day you install E19 | 01:41 |
| 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:42 |
| 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:43 |
| psusi | export GTK_MENU_NO_GRAB=1 | 01:44 |
| hyperair | nah doesn't look like it | 01:45 |
| hyperair | grepping shows no XGrabCursor | 01:45 |
| hyperair | but i see a bunch of XGrabKeys | 01:46 |
| hyperair | oh i see gdk_device_grab in gtkmenu.c | 01:46 |
| 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:51 |
| 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:53 |
| 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:56 |
| TJ- | Obviously, you can tweak the basic idea to trigger on your specific circumstances and windows | 01:57 |
| 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_: ^ | 01:59 |
| 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:03 |
| * hyperair thinks a gdb session in byobu/screen/tmux would be much more helpful | 02:28 | |
| hyperair | that way you could just connect to it via ssh or from a tty | 02:29 |
| tarpman | hyperair: ++, also gdbserver | 02:37 |
| hyperair | oh okay, i didn't know about gdbserver | 02:37 |
| lifeless | whats the best way to capture a full kernel oops when it happens during cloud-config ? | 02:45 |
| hyperair | serial connection? | 02:49 |
| hyperair | netconsole? | 02:49 |
| lifeless | hyperair: good idea, I'll add a serial connection to the vm | 02:56 |
| 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 | 02:57 |
| lifeless | yeah | 03:03 |
| lifeless | 'fun' and didn't have time to debug... | 03:04 |
| === FJKong_AFK is now known as FJKong | ||
| infinity | ScottK: Any comments on my eigen2/eigen3 observations above to Riddell and shadeslayer_? | 04:25 |
| ScottK | infinity: About to go to bed and haven't read them yet. I'll weigh in tomorrow. | 04:26 |
| infinity | ScottK: Mmkay. | 04:26 |
| 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:11 |
| Mirv | or binaries only if libraries are already fine | 05:12 |
| pitti | Good morning | 05:30 |
| sarnold | morning pitti, thanks for kicking the retracers yesterday :) | 05:32 |
| pitti | hey sarnold; thanks for the poke | 05:32 |
| pitti | sarnold: I adjusted apport to use a per-run temporary launchpadlib cache now, so this shouldn't happen again | 05:46 |
| sarnold | pitti: oh, cool! :) thanks | 05:47 |
| === vibhav is now known as Guest86949 | ||
| dholbach | good morning | 07:52 |
| 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:07 |
| ubottu | Launchpad bug 1284447 in pcmanx-gtk2 (Ubuntu Trusty) "middle click could not close the tab you selected by middle click" [Low,In progress] https://launchpad.net/bugs/1284447 | 08:07 |
| 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:14 |
| tjaalton | claims some pkgs are held.. | 08:15 |
| pitti | tjaalton: you don't happen to have -proposed enabled? | 08:34 |
| tjaalton | nope.. | 08:40 |
| === Ursinha is now known as Ursinha-afk | ||
| 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:11 |
| === Ursinha-afk is now known as Ursinha | ||
| === davidcalle_ is now known as davidcalle | ||
| 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:17 |
| Riddell | infinity: will look into eigen today | 09:43 |
| 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 |
| ubottu | Launchpad bug 1294186 in qtbase-opensource-src (Ubuntu) "Cross-building broken in qt 5.2" [High,Triaged] | 09:46 |
| Laney | ;-) | 09:46 |
| 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:21 |
| xnox | *sigh* https://bugs.launchpad.net/launchpad/+bug/336439 | 10:30 |
| ubottu | Launchpad bug 336439 in Launchpad itself "No notification on conflicts in merge proposals" [Low,Triaged] | 10:30 |
| mitya57 | Mirv: Sorry, looks like I forgot to bzr add some patches when updating that branch. | 10:54 |
| mitya57 | I will now push a commit that adds them. | 10:55 |
| 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 | 10:57 |
| === MacSlow is now known as MacSlow|lunch | ||
| 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:37 |
| dholbach | hey tkamppeter_ - how are you doing? | 11:43 |
| 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:44 |
| ubottu | Launchpad bug 537970 in poppler (Ubuntu) "Evince does not print images in some pdf files." [High,Confirmed] | 11:44 |
| 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 | 11:47 |
| === tkamppeter_ is now known as tkamppeter | ||
| === alai_afk is now known as alai | ||
| tkamppeter | dholbach, hi | 12:56 |
| tkamppeter | dholbach, you go to an office? Do you have a second job? | 12:57 |
| tkamppeter | dholbach, is Rouven Sacha (rouvensacha) your contact concerning this bug? | 12:58 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| cjwatson | I agree with sladen, the next thing I'd reach for would be ps aux | strace grep thunder | 13:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| mpt | That’s more than my Terminal buffer | 13:16 |
| mpt | ok, got it now | 13:17 |
| mpt | cjwatson, http://paste.ubuntu.com/7119748/ | 13:19 |
| * cjwatson looks | 13:19 | |
| 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 |
| === _salem is now known as salem_ | ||
| cjwatson | oh, no, it had already closed that one | 13:21 |
| cjwatson | mpt: so that seems to work under strace ... | 13:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| mpt | Process 26532 attached | 13:28 |
| mpt | read(0, | 13:28 |
| mpt | soren, ^ well, that was unexciting | 13:28 |
| 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:29 |
| soren | mpt: Does this happen only with ps as the input? | 13:30 |
| 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:31 |
| mpt | soren, <mpt> “ps aux > ~/test && grep thunder ~/test” also works fine | 13:32 |
| soren | mpt: Hm... There I go, using grep again. | 13:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| mpt | cjwatson, http://paste.ubuntu.com/7119825/ | 13:36 |
| cjwatson | mpt: ps -p 26530 -o pid,args | 13:36 |
| mpt | PID COMMAND | 13:37 |
| mpt | 26530 bash | 13:37 |
| cjwatson | ok, so as I thought | 13:37 |
| 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:38 |
| soren | mpt: How about the guest account? | 13:39 |
| mpt | soren, it exists but nobody is logged in to it | 13:39 |
| 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:40 |
| mlankhorst | can someone remove mesa from proposed? didn't mean to get uploaded to archive | 13:41 |
| Laney | seb128: ^? | 13:43 |
| 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:44 |
| mlankhorst | it's something that should have gone to a ppa so I could run some piglit tests | 13:45 |
| mpt | soren, it works fine in the guest session. | 13:47 |
| mlankhorst | does ubuntu auto reject versions with ~ppa in the name? | 13:47 |
| mpt | Meanwhile, I can no longer move my mouse pointer in *this* session. | 13:48 |
| seb128 | Laney, mlankhorst: done | 13:48 |
| mlankhorst | ty | 13:49 |
| soren | mpt: Interesting. | 13:51 |
| miraiE | I've done: dpkg-depcheck cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` -DQT_QMAKE_EXECUTABLE=/usr/bin/qmake-qt4 | 13:53 |
| 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:54 |
| miraiE | please, how to convert those command in debian/rules ? | 13:55 |
| mitya57 | miraiE: List those packages in Build-Depends field of debian/control | 13:57 |
| miraiE | mitya57: okay, I'll try | 13:58 |
| === marcoceppi is now known as marcoceppi-mobil | ||
| === MacSlow|lunch is now known as MacSlow | ||
| mpt | cjwatson, so should I report a bug on bash? | 14:06 |
| cjwatson | mpt: that's my best guess | 14:09 |
| 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:30 |
| ubottu | bug 1294678 in bash (Ubuntu) "grep waits forever for piped input" [Undecided,New] https://launchpad.net/bugs/1294678 | 14:30 |
| 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:33 |
| mpt | (and thanks soren and sladen too) | 14:35 |
| apw | jamespage, oh goody | 14:36 |
| === retoaded_afk is now known as retoaded | ||
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| xnox | bfiller: "All changes applied successfully." | 14:53 |
| === marcoceppi-mobil is now known as marcoceppi | ||
| bfiller | xnox: cool, I'll add it to the silo | 14:59 |
| === marcoceppi is now known as marco-traveling | ||
| 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:03 |
| 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:05 |
| dobey | xnox: i want to compile lp:unity-scope-click. i'm not using sbuild already, no (though i do have it insatlled) | 15:06 |
| xnox | dobey: test-building here, will let you know in a moment. | 15:08 |
| dobey | xnox: ok, thanks! | 15:09 |
| 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:14 |
| cjwatson | xnox: some | 15:15 |
| cjwatson | xnox: I'm specifically working on making ubuntu-sdk-libs-dev:armhf installable on !armhf | 15:15 |
| 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:16 |
| 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:18 |
| 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:19 |
| infinity | Riddell: Fixing it on ppc64el should be trivial, I didn't bother going that route while waiting on KDE/eigen options. | 15:20 |
| 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:21 |
| 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:23 |
| 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:24 |
| 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:25 |
| dobey | oh | 15:26 |
| xnox | dobey: right, let me strip my chroots and try from scratch locally here. | 15:26 |
| dobey | i'll try --arch then | 15:27 |
| 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:33 |
| 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:34 |
| xnox | dobey: what's your host-OS? | 15:35 |
| 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:36 |
| 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:37 |
| dobey | ok | 15:38 |
| === cmagina-away is now known as cmagina | ||
| 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:40 |
| infinity | xnox: Erk, did we not fix mk-sbuild to name those chroots properly? | 15:41 |
| infinity | xnox: We should. | 15:41 |
| infinity | xnox: (That example above should be /var/lib/schroot/chroots/foobar-amd64-armhf, if it's a cross-chroot) | 15:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| infinity | xnox: Nuked. Didn't notice the spare copy in proposed. | 15:46 |
| 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:51 |
| jamespage | apw, care to educate me? | 15:55 |
| xnox | infinity: cool =) | 15:55 |
| apw | jamespae, coul dyou point me at the issue you are having, so i can see if it is similar | 16:04 |
| rbasak | stgraber: have you seen bug 1072518? | 16:10 |
| ubottu | bug 1072518 in dbus (Ubuntu) "Restart networking crashes dbus and the desktop manager" [High,Confirmed] https://launchpad.net/bugs/1072518 | 16:10 |
| rbasak | stgraber: 120 users are complaining that "sudo restart networking" kills dbus | 16:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| mlankhorst | https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1235516 | 16:17 |
| ubottu | Launchpad bug 1235516 in xorg-server (Ubuntu) "service networking restart causes Xorg crash" [Undecided,Confirmed] | 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| * infinity misses runlevels. :P | 16:22 | |
| mlankhorst | https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/1277553 fun fun | 16:22 |
| ubottu | Launchpad bug 1277985 in xorg-server (Ubuntu) "duplicate for #1277553 Xorg crashed with SIGABRT in OsAbort(no screens found)" [Medium,Incomplete] | 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| jodh | stgraber: make that $UPSTART_STOP_EVENTS | 16:26 |
| stgraber | jodh: thanks | 16:27 |
| xnox | jodh: hmmmm..... is pre-stop at all executed for jobs without main process? | 16:27 |
| 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:28 |
| xnox | stgraber: jodh: when stopping the job interractively with "stop myjob" | 16:29 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| jamespage | apw, https://bugs.launchpad.net/ubuntu/+source/mongodb/+bug/1294747 | 16:36 |
| ubottu | Launchpad bug 1294747 in mongodb (Ubuntu) "mongodb on ppc64el with 64k pagesize" [Undecided,New] | 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:36 |
| 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:37 |
| 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:50 |
| xnox | jodh: https://bugs.launchpad.net/upstart/+bug/1294753 | 16:55 |
| ubottu | Launchpad bug 1294753 in upstart "pre-stop exec false => should prevent the job getting stopped" [Undecided,New] | 16:55 |
| 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:58 |
| xnox | stgraber: ah, I have something that does work =) | 16:59 |
| 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:00 |
| 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:02 |
| 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:03 |
| 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:04 |
| xnox | sorry "post-stop exec false" | 17:07 |
| === bfiller is now known as bfiller_afk | ||
| rbasak | barry: any plans to fix python3-genshi in Trusty? Looks like there's a fix in Debian now? | 17:10 |
| rbasak | jodh: well, we want to make "networking" unstoppable, right? And any real service could have respawn disabled and then killed. | 17:11 |
| 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:12 |
| === Mez_ is now known as Mez | ||
| === cmagina is now known as cmagina-away | ||
| barry | rbasak: yes, i uploaded the new genshi to debian. i just need to sync it over | 17:32 |
| rbasak | barry: thanks! I'll leave you to it I guess. | 17:35 |
| rbasak | Do you want a bug? | 17:35 |
| barry | rbasak: nope, jfdi'd it :) | 17:36 |
| rbasak | barry: thanks! | 17:36 |
| === cmagina-away is now known as cmagina | ||
| barry | rbasak: np! | 17:36 |
| 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:41 |
| 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:43 |
| 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:45 |
| xnox | stgraber: oh, i see! | 17:46 |
| xnox | stgraber: i should then guard pre-start script agains the same event. | 17:46 |
| === cmagina is now known as cmagina-away | ||
| stgraber | yeah, not hackish at all ;) | 17:46 |
| 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:47 |
| === cmagina-away is now known as cmagina | ||
| jamespage | apw, thanks for looking | 17:48 |
| 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:49 |
| 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:50 |
| 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. | 17:52 |
| 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:01 |
| stgraber | xnox: ok, thanks for the patch, I'll think about it... | 18:04 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === jackson is now known as Guest40265 | ||
| === bfiller_afk is now known as bfiller | ||
| === Guest40265 is now known as Noskcaj | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === charles_ is now known as charles | ||
| charles | Sarvatt: ping | 20:15 |
| charles | Sarvatt: I noticed you updated https://bugs.launchpad.net/indicator-datetime/+bug/1244285 earlier today | 20:15 |
| ubottu | Launchpad bug 1244285 in indicator-datetime (Ubuntu) "Date/time sometimes doesn’t appear in menu bar, settings greyed out (Ubuntu 13.10, 14.04)" [Medium,Triaged] | 20:15 |
| charles | Sarvatt: were you doing that for bookkeeping (New -> Confirmed) because there was more than one reporter, or are you seeing this yourself? | 20:16 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:44 |
| UserError | That's something you Mutter under your breath around here. | 20:45 |
| 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:51 |
| infinity | jamespage: Hah, the "solution" in the IBM mongo branch to your woes is to disable that test. ;) | 20:57 |
| infinity | jamespage: Anyhow, there are lots of other changes in the branch, so I'll pull that all in and hopefully unblock you. | 20:58 |
| 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:08 |
| ScottK | If not, build log please. | 21:09 |
| === cmagina is now known as cmagina-away | ||
| Logan_ | ScottK: I don't think there are any ppc64el PPA builders atm | 21:10 |
| 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:11 |
| ScottK | Sarvatt: Thanks. | 21:12 |
| Sarvatt | ScottK: built fine, https://launchpad.net/~canonical-x/+archive/x-staging/+build/5829072 | 21:17 |
| ScottK | Sarvatt: Yep. Thanks. I didn't want to do the upload to Debian, wait, upload to Ubuntu round trip without a test. | 21:19 |
| jamespage | infinity, well that's a great fix! | 21:58 |
| jamespage | lol | 21:58 |
| 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:00 |
| 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:07 |
| 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:10 |
| === cmagina-away is now known as cmagina | ||
| 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:13 |
| sarnold | check /var/log/ there may be some install/remove logs there too | 22:14 |
| ThiagoCMC | Also, I didn't tried Unity8... =P | 22:14 |
| ThiagoCMC | sarnold, no logs about the Unity session startup? | 22:16 |
| sarnold | ThiagoCMC: I was thikning of /var/log/dpkg.log | 22:16 |
| === bfiller is now known as bfiller_afk | ||
| 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:27 |
| sarnold | have fun! :) | 22:28 |
| ThiagoCMC | ^_^ | 22:44 |
| === cmagina is now known as cmagina-away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!