[02:50] <ccheney> anyone know of any major issues with lucid? i am considering upgrading to it before going to the sprint next week
[02:51] <ccheney> it looks suprisingly stable for an alpha release when i booted up off a usb stick
[02:59]  * ccheney will upgrade and hope it works :)
[03:03] <slangasek> I know of several major issues with lucid, all of which are documented ;)
[03:05] <ccheney> slangasek: major enough i should stick with karmic for main dev machine still?
[03:05]  * ccheney looks through alpha 3 bugs
[03:07] <ccheney> hmm there is an intel wifi bug but those are fairly common in general, heh
[03:07] <ccheney> ah nm i was looking at the wrong bug list
[03:08] <slangasek> ccheney: nothing major enough that I'm stressing about it right now :)
[03:08] <slangasek> OTOH, I'm on Intel, so plymouth works for me
[03:16] <ccheney> slangasek: ok yea me too
[03:16] <ccheney> slangasek: it looks fine to me so far running off usb
[03:59] <jcastro> ccheney: I am having wifi issues (I think we have the same laptop) but I am also suspecting by AP (ymmv etc.)
[04:02] <ccheney> jcastro: ok
[04:02] <ccheney> jcastro: is it just occasional or constant?
[04:02] <ccheney> jcastro: it worked ok for the brief time i was running before i rebooted to back stuff up
[04:02] <jcastro> it's just real flaky, I only noticed it when I was prepping it for the sprint.
[04:03] <jcastro> dropped signal, long timeouts, etc.
[04:05] <ccheney> oh hmm :-\
[04:06] <jcastro> but again, I am suspecting my AP, I'll let you know on monday. :D
[04:06] <ccheney> ok
[04:06] <ccheney> well i'll reinstall to lucid and see how it goes, heh
[04:06] <ccheney> we may end up in the kernel room getting them to hound intel :)
[05:57] <RAOF> Can someone give ndesk-dbus a rebuild prod?  The sync initially failed to build (probably because one of its b-ds hadn't made it through NEW at that point); it builds fine now.
[06:07] <pitti> Good morning
[06:09] <RAOF> Good morning.
[06:17] <pitti> asac: should I remove the firefox-3.5 source package now?
[06:19] <baali> I am getting this error on ubuntu 9.10 "chroot: cannot run command `/bin/bash': Exec format error", any hints?
[06:20] <baali> i have looked links on linuxqustion.org and ubuntu forum and not able to fix this
[06:23] <RAOF> Could be any number of things, and is probably not really on-topic for #ubuntu-devel - #ubuntu is the channel for support.
[06:24] <RAOF> One obvious thing that springs to mind is whether you've built an amd64 chroot and are trying to run it from a 32bit kernel.
[06:25] <Hobbsee> RAOF: prodded
[06:28] <RAOF> Ta muchly.
[06:28] <RAOF> Now, let's boot this new kerenl & see if cowboylaputopu will actually enter a low-power state when I tell it to suspend.
[06:28]  * mneptok falls asleep
[06:30] <RAOF> With bonus check for xorg nouveau-autodetection patch correctness!
[07:56] <didrocks> good morning
[08:02] <dholbach> good morning
[08:14] <dholbach> pitti: do the special keys (xf86mail, xf86audioraisevolume, etc.) work for you in current lucid?
[08:22] <pitti> dholbach: yes, they do
[08:22] <pitti> dholbach: since I maintain the keymap tables, they better do :-P
[08:24] <dholbach> weird, for me they don't with current lucid
[08:24] <dholbach> Xf86HomePage brings up nautilus
[08:25] <pitti> dholbach: and they did work in karmic? very strange
[08:25] <dholbach> yes, they still worked yesterday
[08:25] <pitti> !
[08:25] <pitti> now, udev didn't change at all
[08:25] <pitti> we got a new kernel, though
[08:26]  * dholbach has a look at apt log to find out what changed
[08:26] <pitti> dholbach: I didn't test the hotkeys on my laptop today ete (it's docked); but on the mini they do work
[08:27] <dholbach> let me reboot with the old kernel
[08:27] <didrocks> dholbach: same for me, it works
[08:27] <pitti> s/ete/yet/, bah
[08:28] <dholbach> it's funny when the reboot/shutdown/logout indicator sometimes doesn't show anything :)
[08:28] <dholbach> ok, same with the old kernel
[08:30] <dholbach> weird, I have no idea what could have changed that behaviour
[08:30] <pitti> dholbach: you still have /lib/udev/rules.d/95-keymap.rules ?
[08:31] <dholbach> yep
[08:32] <dholbach> which gconf keys would override that somehow?
[08:32] <dholbach> there was a gconf update, maybe something went funny there
[08:33] <pitti> dholbach: you should first check that the generated keycodes are correct/wrong; /usr/share/doc/udev/README.keymap.txt
[08:33] <dholbach> pitti: so when I open the shortcut preferences and try to change them the Xf86Mail still shows up, when I press it
[08:33] <pitti> i. e. find your keyboard device (findkeyboards) and then keymap -i
[08:33] <pitti> dholbach: or use xev
[08:33] <dholbach> I guess the keycodes are fine, but yeah, let me check
[08:34] <pitti> dholbach: is mail correct or wrong?
[08:34] <pitti> dholbach: start with xev then
[08:34] <dholbach> it's what was in there before
[08:34] <dholbach> but it doesn't start thunderbird for me
[08:34] <dholbach> same goes for raise volume
[08:34] <pitti> ah, then I blame seb128
[08:34] <dholbach> it just doesn't do anything
[08:35] <pitti> dholbach: try in a guest session?
[08:35] <dholbach> pitti: you are a clever man
[08:35] <dholbach> I'll do that
[08:36] <dholbach> pitti: nope, they don't work at all there
[08:36] <dholbach> oh, the guest session is completely busticated
[08:36] <dholbach> I can't click anything in there
[08:36] <dholbach> the mouse pointer moves, but that's it
[08:38] <pitti> hm; FTR it doesn't work for me either; I just get a VT with a mouse cursor, and then I have to reboot
[08:38] <pitti> some weird plymouth/KMS/xorg problem
[08:38] <dholbach> wow
[08:38] <dholbach> ** (gnome-settings-daemon:2833): WARNING **: /usr/lib/gnome-settings-daemon-2.0/libmedia-keys.so: undefined symbol: notify_notification_show
[08:38] <dholbach> ** (gnome-settings-daemon:2833): WARNING **: Cannot load plugin 'Medientasten' since file '/usr/lib/gnome-settings-daemon-2.0/libmedia-keys.so'
[08:38] <dholbach>  cannot be read.
[08:38] <dholbach> ** (gnome-settings-daemon:2833): WARNING **: Error activating plugin 'Medientasten'
[08:39] <dholbach> (gnome-settings-daemon:2833): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
[08:39] <dholbach> (gnome-settings-daemon:2833): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
[08:39] <dholbach> (polkit-gnome-authentication-agent-1:2843): GLib-GObject-WARNING **: cannot register existing type `_PolkitError'
[08:39] <dholbach> (polkit-gnome-authentication-agent-1:2843): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
[08:39] <dholbach> that's /tmp/guest-home.feqBK3/.xsession-errors
[08:39] <pitti> oh, libmedia-keys.so? that seems relevant
[08:39] <dholbach> undefined symbol
[08:39] <pitti> dholbach: ah, confirmed here
[08:39]  * dholbach hears alarm bells ringing
[08:39] <pitti> dholbach: just finished a dist-upgrade on the mini
[08:40] <pitti> itz gnome bug
[08:40] <dholbach> itz ugly
[08:40] <dholbach> didrocks: ^ fix it!
[08:40]  * dholbach hugs didrocks
[08:40] <didrocks> rohhhh ^^
[08:40]  * didrocks hugs dholbach
[08:41]  * dholbach gets another cup of coffee while didrocks fixes it
[08:41] <dholbach> ;-)
[08:42] <didrocks> dholbach: I'm sure you can live without it :p
[08:42]  * didrocks just notices he didn't touch g-s-d contrary to other desktopers ;)
[08:44] <pitti> ah, so that's why the key repetition is broken
[08:44] <dholbach> pitti: "I'm sure you can live without it :p"
[08:48] <pitti> I just reenabled them in the keyboard settings this morning
[08:54] <asac> pitti: sure. thanks!
[08:54] <asac> (ffox 3.5 removal)
[09:01] <geser> could an archive admin please promote van.pydeb (python-van.pydeb) once again to main? it fell once again of it (see also bug #494104 for the last occurance)
[09:02] <pitti> asac: removed then
[09:04] <asac> thx
[09:05] <pitti> geser: sure, doing
[09:41] <ogra> hrm, so the karmic->lucid upgrade stole my nodeadkeys setting
[09:42] <ogra> hrm, even though according to the keyboard settings it is set to nodeadkeys
[09:43] <ogra> aha, deleting the US layout (that wasnt there in karmic and i didnt select it) seems to fix my german setting
[09:43] <ogra> very weird and unintuitive
[09:43] <vish> ogra: kernel 32-12 ?
[09:44] <ogra> -11
[09:44] <ogra> i dont think its anyhow related to the kernel but rather to gnome-settings-daemon or whatever handles the kbd settings atm
[09:44] <vish> k.. , i just noticed something weird with 32-12 update too , it turned off the keypress repeat settings :s
[09:45] <vish> ah , maybe the gsd update did it
[09:45] <ogra> works here with -11 ... i'm just running an upgrade
[09:45] <ogra> lets see if i still have it after thats done :)
[10:16] <ogra> aarrgghh
[10:16] <ogra> mmyy  kkbbdd  ddoouubblleess  eevveerryy  lleetttteerr  ii  ttyyppee  nnooww
[10:17] <ogra> sseeeemmss  ttoo  bbee  rreessttrriicctteedd  ttoo  XX
[10:18] <ogra> ah, better
[10:19] <ogra> so the key repetition sliders in the kbd settings both were completely moved to the left
[10:19] <ogra> seb128, do you have a bug for that ? its scary !
[10:19] <Tm_T> ogra: I was about to ask if you did wear thick gloves (:
[10:19] <ogra> heh
[10:19] <seb128> ogra, dholbach reported an issue with the keybinding code not loading yes
[10:20] <seb128> ogra, but it just disable the gnome settings
[10:20] <ogra> no, its the repetitionm
[10:20] <seb128> it doesn't double anything
[10:20] <seb128> you get what xorg do by default
[10:20] <ogra> take your kbd settings and move both sliders to the very left :)
[10:20] <ogra> thats what i just had
[10:20] <seb128> well this code fails to load
[10:21] <ogra> its g-s-d or whatever manages the kdb settings loosing its defaults
[10:21] <seb128> so the setting should not be revelant
[10:21] <ogra> it surely didnt for me right now
[10:21] <seb128> well the gnome code crashes
[10:21] <seb128> so it's not setting anything
[10:21] <ogra> moving the sliders fixed it
[10:21] <ogra> so it sets it at least *at some point*
[10:21] <seb128> weird
[10:21] <ogra> try it
[10:21] <seb128> anyway I'm off to test the fix for that
[10:21] <seb128> brb
[10:22] <ogra> i can reproduce it by moving both sliders back
[10:22] <seb128> that will be quicker than discussing how the breakage break it for you
[10:22] <seb128> as said the code is crashing and I've a fix ready to test
[10:22] <ogra> ok
[10:22] <seb128> I don't think discussing what side effect the crash has it useful
[10:22] <seb128> let's just fix it
[10:22] <seb128> brb
[10:22] <ogra> no, go ahead, i'll test the fix if its up+
[10:33] <ogra> weird, i now have a "jack control" tool in my media menu ... and it has no close button on the wiondow
[10:39] <EtienneG> pitti, I suffer from bug #454487, and gnome-settings-daemon 2.28.1-0ubuntu3 has been uploaded to karmic-proposed to fix it.  Except, it's not there and I can't find it!  Have it been pulled?
[10:45] <EtienneG> seb128, maybe you would know about the above ... ?
[10:45] <seb128> EtienneG, let me look
[10:46] <EtienneG> seb128, I can see it at https://launchpad.net/ubuntu/+source/gnome-desktop/1:2.28.1-0ubuntu3, but it is neither in karmic-updates nor -proposed
[10:47] <seb128> EtienneG, it is in karmic-updates
[10:47] <seb128> EtienneG, apt-cache policy libgnome-desktop2-11?
[10:48] <seb128> EtienneG, apt-cache policy libgnome-desktop-2-11 rather
[10:48] <EtienneG> seb128, ok, I must have been confused, lemme check
[10:50] <EtienneG> seb128, ah, ok, got it, however, gnome-settings-daemon is still at 2.28.1-0ubuntu2
[10:50] <seb128> right
[10:50] <seb128> that's a different source
[10:50] <EtienneG> and g-s-d is what I actually need :(
[10:50] <seb128> no reason for it to change version
[10:50] <EtienneG> ah, ok
[10:50] <seb128> no
[10:50] <seb128> the bug was in gnome-desktop there
[10:50] <seb128> g-s-d uses the gnome-desktop library
[10:50] <EtienneG> I see
[10:51] <EtienneG> seb128, sorry for the confusion, and thanks a bunch for the help.  i think I am all set.
[10:51] <seb128> you're welcome
[10:51] <seb128> EtienneG, let me know if the update works for you or not
[10:51] <seb128> ie if it fixes your issue
[10:51] <EtienneG> seb128, yes, i will, although I will not be able to test for a while
[10:52] <EtienneG> seb128, the affected system is in a walled network, complicating update
[10:52] <EtienneG> seb128, I am waiting for the mirror and update infrastructure to get setup
[10:52] <seb128> ok
[10:53] <seb128> in any case let us know if that's still an issue with the update when you get it
[10:53] <EtienneG> I was actually checking the status of all the bug i had to handle, and investigating that one.  Seems like the solution is just an update, which is good!
[10:53] <EtienneG> seb128, I sure will
[10:54] <EtienneG> seb128, and thanks again for the prompt response, much appreciated
[10:54] <EtienneG> especially considering you guys must be insanely busy these days
[10:54] <EtienneG> with travelling and stuff
[10:55] <seb128> travelling is tomorrow ;-)
[10:55] <EtienneG> I know, but packing and catch-up has to be today!
[10:55] <EtienneG> I am actually in Europe this week
[11:34] <dupondje> when get packages accepted that are in the lucid queue ? :)
[12:39] <doko_> ccheney: updated the OOo patch in https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/506358 again, please apply before the next try to build. Is the gsi export supposed to work? Afaicr we wanted to make this work for lucid
[12:39] <doko_> asac: ^^^ one chunk missed, hope that the only one
[12:40] <asac> thanks
[12:42] <asac> doko_: btw, the dove hang on pybootchartgui import in python wasnt fixed by updating python ... but by recreating the .pycs afterwards ... any clue why that could be?
[12:42] <asac> thought the .pycs dont have native information
[12:43] <doko_> no clue
[12:48] <pitti> doko_: should I just remove sun-java6 now? or file a bug about it?
[12:48] <pitti> s/file/filed/
[12:49] <doko_> pitti: from my point of view, yes.
[12:49] <pitti> sweet
[13:24] <seb128> dholbach, ogra: bug #514281 btw
[13:24] <seb128> dholbach, ogra: that's your keyboard issue
[13:43] <pitti> fix uploaded now
[13:51] <zul> pitti: the fix for pastedeploy has been uploaded as well
[14:22] <ogra> seb128, bah, pitti broke the really funny description :P ... yeah looks identical
[14:34] <pitti> zul: ah, sweet
[14:34] <pitti> ogra: it wasn't quite -- searchable
[14:35] <zul> pitti: ill go seed it if thats ok
[14:35] <pitti> zul: sure
[14:35] <ogra> pitti, but funny !
[14:36] <pitti> zul: promoted
[14:36] <zul> pitti: thanks
[14:43] <lool> Hmm firefox doesn't start anymore for me
[14:44] <lool> is this a message that I should try chromium?
[14:45] <lool> Starts in safe mode though
[14:46] <asac> lool: greasemonkey package?
[14:47] <asac> remove that and install the .xpi from amo in profile
[14:49] <asac> https://addons.mozilla.org/en-US/firefox/addon/748
[15:02] <sebner> dholbach: you sure the ice won't break in the near future? :P
[15:04] <dholbach> sebner: we'll see
[15:05] <sebner> dholbach: heh, in elementary school we had a small pond and it was fun to slide over it .. until one broke in and was wet up until the hip :D
[15:06] <dholbach> yeah, I can imagine :)
[15:09] <lool> asac: Yup, I had greasemonkey installed; thanks
[15:15] <dholbach> pitti, seb128: thanks for working on those fixes!
[15:15] <pitti> dholbach: does it work for you now?
[15:15] <dholbach> yep
[15:15] <dholbach> all good and happy again
[15:16] <seb128> dholbach, credit goes to pitti there
[15:16] <seb128> I just pointed him to the bug
[15:16] <pitti> well, the blame goes to me as well, so that's only fair :)
[15:16]  * seb128 hugs pitti
[15:16] <pitti> I just didn't want mvo to poke me all the way to Seattle tomorrow; it's hard to escape in a plane :)
[15:17] <mvo> indeed!
[15:17]  * mvo tries his best evil grin
[15:39] <dholbach> final day of https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 22 minutes in #ubuntu-classroom on irc.freenode.net (first up: "Writing Beautiful Code")
[15:39] <geser> dholbach: do you know if the source for http://qa.ubuntu.com/reports/sponsoring/index.html is available somewhere?
[15:40] <dholbach> https://code.edge.launchpad.net/~dholbach/+junk/new-sponsoring
[15:40] <dholbach> geser: ^
[15:41] <geser> thanks, I want to try to add merge proposals to this list
[15:44] <dholbach> geser: not sure that's going to work
[15:44] <dholbach> geser: there's an open bug, let me find it
[15:45] <dholbach> https://bugs.edge.launchpad.net/launchpad-code/+bug/411357
[15:45] <dholbach> geser: that was the reason why I ported it from lpbugs to lplib in the first place :)
[15:45] <dholbach> but if you know something I don't and can fix it, that'd be cool :-D
[15:45]  * dholbach hugs geser
[15:45] <geser> dholbach: https://edge.launchpad.net/+apidoc/#team lists a getMergeProposals() method
[15:46] <dholbach> geser: I think that's merge proposals made by the team or somtehing else which doesn'T make sense
[15:46] <geser> ah, the other way around :(
[16:20] <ogra> apw, http://people.canonical.com/~ogra/osiris-lucid-20100128-2.png desktop is up when IO stops (not at the falsely set red line)
[16:21] <cjwatson> slangasek: BTW, re bug 506717 and your comment there about vga= - vga= is implemented by the 16-bit boot protocol in Linux, and since 9.10 grub2 bypasses that and uses the 32-bit boot protocol by default, so this stuff only works with gfxpayload instead
[16:21] <cjwatson> slangasek: however gfxpayload requires something in the kernel to actually deal with displaying text when video starts up (from its POV) in a non-VGA mode ...
[16:22] <slangasek> oh, hmm
[16:22] <slangasek> interesting
[16:23] <cjwatson> you *can* force grub2 to use the 16-bit bp by editing /etc/grub.d/10_linux to use linux16/initrd16 commands instead of linux/initrd
[16:56] <robbiew> pitti: can we use "DROPPED" as a work item status yet?  /me hasn't been keeping up...apologies.
[16:56] <pitti> robbiew: I apologize likewise; sorry, no time to work on that yet
[16:56] <robbiew> no worries
[16:56] <robbiew> I understand ;)
[16:56] <pitti> robbiew: well, I can add the alias really quickly
[16:57] <robbiew> it's no real rush
[16:57] <pitti> robbiew: but the "postponed to lucid-3" magic will need more time
[16:58] <robbiew> pitti: ack
[16:58] <pitti> robbiew: done
[16:58] <robbiew> heh...thanks
[16:58] <pitti> robbiew: i. e. you can use "dropped" now, with same behaviour as "postponed"
[16:58] <pitti> but it might look nicer in the charts
[16:58] <pitti> s/charts/whiteboards/
[16:58] <robbiew> ;)
[17:09] <ScottK> asac: Bug #514404
[17:10] <asac> thx
[17:42] <ccheney> doko_: yea, it seems to have broken between 3.1.1 and 3.2.0
[18:38] <crimsun> hmm, we can't pass uids to su, correct?  (e.g., sudo -u #foo)
[18:39] <crimsun> the man page at least implies that, but I could have sworn su allowed that.  I guess it's my cruddy memory.
[18:44] <alkisg> crimsun: `su -c whoami username`  ?
[18:45] <crimsun> whoami returns the username, though
[18:45] <slangasek> that's what you want
[18:46] <slangasek> you want something that /takes/ the uid and /returns/ the username, that you can pass to su :)
[18:46] <slangasek> (which whoami doesn't do, since it also only takes names as argumenst)
[18:46] <alkisg> su -c 'cd ~; pwd' angelos
[18:46] <alkisg> Just an example...
[18:46] <tlyu> grep :$targetuid: /etc/passwd
[18:46] <slangasek> alkisg: no
[18:47]  * alkisg didn't see all the convo...
[18:47] <slangasek> crimsun: you want su $(getent passwd $uid | cut -f1 -d:)
[18:47] <slangasek> tlyu: also no; fails badly for other NSS backends
[18:48] <crimsun> slangasek: excellent, thanks. (BTW, this is to fix #498980)
[18:49] <slangasek> crimsun: I'm aware ;)
[18:50] <jpds> I wonder why 'sudo -u 1000 whoami' doesn't work.
[18:51] <crimsun> jpds: you need to use -u #1000
[18:51] <slangasek> jpds: because a) using sudo for this is wrong, b) the entire point of the question is that you have a uid and you want to convert it to an argument you can pass to su
[18:52] <slangasek> so doing sudo to get the argument to pass to su would be doubly wrong ;)
[18:53] <jpds> crimsun: http://pastebin.ubuntu.com/365332/
[18:53] <jpds> slangasek: Just reading what the manpage says. :)
[18:53] <tlyu> jpds: try quoting the "#"?
[18:53] <jpds> Ah.
[19:18] <ari-tczew> wrrrrrr, any sponsor will work on merges for main before FFe?
[19:24] <asac> directhex: mono expert? any idea about: http://launchpadlibrarian.net/38535766/buildlog_ubuntu-lucid-armel.mono_2.4.3%2Bdfsg-1ubuntu1~asac1_FAILEDTOBUILD.txt.gz ?
[19:26] <directhex> asac, fails on arm only?
[19:27] <asac> directhex: yes. i fixed the real build failure ... now i am getting this kind of crack ;)
[19:28] <asac> can i run make VERBOSE=1 or something to give a more verbose command line for the MSC?
[19:28] <asac> MCS
[19:28] <directhex> asac, erm... odd. 2.4.3+dfsg-1 built okay on arm on sid.
[19:29] <directhex> asac, well, it's claiming a bunch of source files are missing. that's about as verbose as it gets really
[19:29] <ogra> directhex, arm on sid is in no way optimized for anything :)
[19:29] <asac> yes. the build failure we got in archive is really because we are building for armv7 ... but that fixed (and i doubt that this is causing this)
[19:29] <asac> where are those .cs things supposed to come from?
[19:29] <asac> SerializationCallbacks.cs etc.?
[19:29] <asac> directhex: ?
[19:29] <ogra> directhex, we build ARMv7 with Thumb2 and NEON (where possible) thats far advanced beyond what debian does ... but narrows the supported HW
[19:30] <asac> thats more info than he needs ;)
[19:30] <ogra> directhex, sadly it exposes code problems where things are hardcoded that shouldnt be, like the issue asac initially fixed
[19:31] <ogra> asac, i just get tired to hear "but it built on sid" form people ... so i like to explain there is a big difference :)
[19:31] <asac> so i have
[19:31] <asac> ogra: yeah. ok
[19:31] <asac> mono-2.4.3+dfsg/mcs/class/corlib/System.Runtime.Serialization/SerializationCallbacks.cs
[19:31] <directhex> asac, the list of files to build is in /mcs/class/corlib/corlib.dll.sources
[19:31] <asac> thats in the source
[19:32] <asac> thats in there
[19:32] <directhex> asac, is there a porter box running the same hardware platform i can tinker with?
[19:32] <ogra> directhex, yes
[19:32] <asac> directhex: i can run commands for you
[19:32] <directhex> or an easy way to build a qemu environment
[19:33] <ogra> directhex, sadly mono is the one thing that doesnt work in qemu :(
[19:33]  * ogra would love to solve that but doesnt knoe how
[19:33] <ogra> *know
[19:33] <asac> directhex: can i enable verbose biulding somehow? i would really like to see what the MCS line is
[19:33] <directhex> asac, i'll ask
[19:34] <asac> make VERBOSE=1 or something
[19:34] <ogra> could it be that there is just missing a path entry ?
[19:34] <asac> tanks
[19:34] <asac> thanks
[19:34] <asac> right. i assume there is something missing/wrong on the MCS command line
[19:34] <asac> but we dont see that ;)
[19:34] <ogra> yeah
[19:35] <directhex> ogra, i don't see what would differ on ARM on ubuntu compared to the rest, as far as that's concerned
[19:35] <ogra> directhex, you mean wrt qemu ?
[19:35] <ogra> or wrt our build flags
[19:35] <directhex> ogra, i mean causing the MCS error asac is seeing
[19:36] <directhex> CS2001 is a very odd thing to see
[19:36] <ogra> well, he changed the code to not use some embedded assmebler and use gcc atomics instead
[19:36] <asac> directhex: this is a second build run ... what is that about?
[19:36] <ogra> that could indeed change behavior and need further changes
[19:37] <asac> having VERBOSE would be nice ;)
[19:37] <directhex> asac, the second run is to run the full test suite. we brought that change in to, um, spot errors on arm
 directhex: make V=1
 I think ;-)
[19:37] <asac> ogra: i doub tit ... either i did it wrong or right
[19:37] <asac> DreamThief: thx
[19:37] <asac> directhex: ^
[19:37]  * asac runsit
[19:37]  * directhex steals some dreams
[19:37] <ogra> heh
[19:38] <directhex> build/rules.make:Q_MCS=$(if $(V),,@echo "MCS     [$(PROFILE)] $(notdir $(@))";)
[19:38] <directhex> yes, i think V is it
[19:39] <directhex> (ARGH AUTOMAKE)
[19:39] <directhex> asac, can i see your arm fix btw? might upstream be interested?
[19:39] <asac> http://paste.ubuntu.com/365373/
[19:39] <asac> directhex: yes. upstream might want that... but first it needs to work ;)
[19:40] <asac> directhex: its in my armel1 ppa
[19:40] <asac> but i can give you the patch cat debian/patches/mono-arm-thumb2-ftbfs.dpatch | pastebinit
[19:40] <asac> cat debian/patches/mono-arm-thumb2-ftbfs.dpatch | pastebinit
[19:40] <asac> http://pastebin.com/f7fbe75c6
[19:40] <asac> http://pastebin.com/f7fbe75c6
[19:40] <asac> oops
[19:40] <asac> its not a perfect fix... would require configure.in patching and check
[19:40] <asac> for gcc atomics
[19:42] <asac> directhex: do you see that the comment  properly specifies the search path somewhere?
[19:42] <asac> command
[19:42] <asac> sorry
[19:42] <asac> http://paste.ubuntu.com/365373/ <- here
[19:42] <ogra> asac, did you check corlib.dll.sources proably there is a path variable in front of the files thats not set ?
[19:43] <asac> no
[19:43] <asac> all relative it seems
[19:43] <directhex> all relative
[19:43] <asac> questinon is to what ;)
[19:43] <directhex> @filename is used instead of a big list of crap on the command line
[19:43] <asac> to MONO_PATH?
[19:44] <asac> yeah
[19:46] <directhex> what's interesting here is there are 433 "missing" files but it's passed a list of 1453
[19:46] <asac> maybe it just stops after X files complaining?
[19:46] <asac> or are there leaps?
[19:47] <directhex> it's stopping after 1020 lines
[19:47] <directhex> anything after System.Runtime.Serialization/SerializationBinder.cs
[19:48] <directhex> i find that interesting
[19:50] <asac> -d:BOOTSTRAP_WITH_OLDLIB
[19:50] <asac> what does that mean?
[19:51] <directhex> i think it's for bootstrapping a new version of a lib with an old version of itself
[19:52] <asac> hmm
[19:52] <asac> so specifying one of those files manually doesnt complain about it missing
[19:52] <directhex> in general though, i think people in gimpnet #monodev are likely to be far more knowledgeable than me
[19:53] <asac> yeah
[19:53] <asac> dont think will get to it today ... should go to bed for a strong travel date tomorrow
[19:57] <asac> thx
 the problem with armv7 is that I can't even test it, cause qemu doesn't support it.
[20:04] <ogra> directhex, our qemu does
[20:04] <ogra> directhex, at least in usermode
[20:04] <directhex> ogra, but not for mono?
[20:05] <ogra> directhex, right
[20:05] <ogra> directhex, it angs hard when isntalling the assmeblies
[20:05] <ogra> *hangs
[20:05] <directhex> ogra, well, that could be a bug too?
[20:06] <directhex> ogra, is armv7 support patched into ubuntu?
[20:06] <ogra> more likely in qemu though
[20:06] <directhex> or is it in upstream qemu>?
[20:06] <ogra> mono works fine on real HW
[20:06] <ogra> directhex, apt-get install qemu-arm-static; sudo build-arm-chroot ...
[20:06] <directhex> hm
[20:06] <ogra> ogra@osiris:/var/build$ LANG=C sudo chroot lucid-test/
[20:06] <ogra> root@osiris:/# uname -m
[20:06] <ogra> armv7l
[20:07] <ogra> directhex, feel free to play with it
[20:07] <ogra> build-arm-chroot takes exactly all argument debootstrap takes and creates you an arm chroot you can just use (thanks to binfmt)
[20:07] <asac> yes
[20:08] <asac> mono might take a bit to build there though
[20:08] <asac> (at least as long as native)
[20:08] <ogra> longer i guess
[20:08] <asac> for chromium it was smilar slow ... both took forever
[20:08] <asac> ;)
[20:08] <ogra> heh
[20:08] <ogra> ok, if the criteria is "forever" then it might be faster even :P
[20:08] <directhex> asac still exists? i thoguht you went to bed
[20:09]  * ogra bets he will meet a very tired asac on the plane tomorrow ... because he cant manage to sleep before he fixed that
[20:09] <directhex> asac, basically, vargaz is eager to help, and he's the high overfiend of the runtime... so it's down to getting a testable encironment
[20:10] <directhex> ogra, is qemu-arm-static from lucid needed?
[20:10] <asac> directhex: most likely. but maybe it works in a lucid chroot (ogra knows)
[20:10] <ogra> try the karmic one, but i think thats only v6
[20:10] <asac> ogra: haha. you are wrong. i cant sleep because i have to get up when i usually get to bed ;)
[20:10] <ogra> lol
[20:11] <ogra> i still havent packed ... i should probably start at some point :)
[20:11] <ogra> though my train only goes at 6:15
[20:11] <asac> lucky you
[20:11] <asac> in wonder if i relaly need to be at airport earlier than 2h ahead ... i really doubt that
[20:12] <ogra> surely not for the inner german flight
[20:12] <asac> its the same security in hamburg
[20:12] <ogra> you will have to be in FFM 2h early
[20:12] <asac> and usually even 1.5h ahead was far too early
[20:13] <asac> on sat morning ;)
[20:18] <ogra> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA !
[20:18] <ogra> god that freenode stuff makes me mad
[20:18] <asac> does that mean anything else?
[20:18] <asac> the +r ?
[20:18] <directhex> asac, is there any way to get access to an ubuntuish arm box with the same odd cpu for someone at novell to look at? afaik he's using a sheevaplug usually to test linux/arm
[20:19]  * ogra has to manually log in to each and every channel ... and to log out from half of them to even change nick
[20:19] <asac> directhex: someone from the team might be able to provide access
[20:19] <directhex> ogra,  AaaaaAAaaaAAAaaAAAAaAAAAA!!! is a fun game
[20:19] <asac> not on the porter boxes
[20:19] <asac> the qemu thing mentioned by ogra is good
[20:19] <ogra> yeah, if only mono would work :(
[20:20] <directhex> asac, the qemu thing emulates the same type of cpu?
[20:20] <asac> oh
[20:20] <asac> [pid 13649] open("System.Collections.Generic/Comparer.cs", O_RDONLY|O_LARGEFILE) = -1 EMFILE (Too many open files)
[20:20] <asac> [pid 13649] getcwd("/home/asac/mono/mono-2.4.3+dfsg/mcs/class/corlib", 261) = 49
[20:20] <asac> [pid 13649] write(2, "error CS2001: Source file `Syste"..., 85error CS2001: Source file `System.Collections.Generic/Comparer.cs' could not be found) = 85
[20:20] <directhex> asac, i wondered
[20:20] <asac> [pid 13649] write(2, "\n", 1
[20:21] <asac> )           = 1
[20:21] <asac> too many open files ;)
[20:21] <asac> hmm
[20:21] <asac> http://paste.ubuntu.com/365390/
[20:21] <asac> that explains it
[20:21] <asac> 1024
[20:21] <directhex> i knew 1020 was a significant number
[20:21] <asac> ;)
[20:21] <directhex> oh for fecks sake... ulimit?
[20:21] <directhex> jeebus, man! fix0r that!
[20:21] <asac> right
[20:21] <asac> hehe
[20:22]  * asac is on it
[20:22] <asac> ogra: ^^
[20:23] <asac> see #is
[20:23] <ogra> yes, i see it
[20:23] <ogra> cant, i'm not in #is atm
[20:23] <asac> ok
[20:23] <asac> ;)
[20:23] <ogra> i thought the open files value would be raised automatically by the kernel
[20:23] <asac> on pegatron?
[20:23] <asac> ;)
[20:24] <ogra> well
[20:24] <ogra> heh
[20:24] <asac> its some kernel we dont know anything about ... so even if your theory is right, i wouldnt be shocked if it didnt work there
[20:24] <ogra> yeah
[20:25] <asac> where are my root powers :(
[20:25] <asac> directhex: anyway to do that in two chunks?
[20:25] <asac> ;)
[20:26] <asac> like catting all files together ;)
[20:26] <ogra> isnt lamont around to raise the ulimit ?
[20:29] <asac> ogra: lagger ;)
[20:29] <asac> no answer yet
[20:30] <ogra> heh
[20:30] <asac> too bad that it failed in my native ppa too
[20:30] <asac> otherwise there would have been hope :)
[20:31] <ogra> he might be in travel prepartion too
[20:31] <ogra> or even in the air
[20:32] <asac> i doubt it
[20:32] <asac> ogra: you are right . arrival= today
[20:32] <ogra> he is supposed to arrive toda
[20:32] <ogra> y
[20:32] <ogra> indeed, i looked before speaking ;)
[20:32] <asac> is there any backup for him?
[20:33] <ogra> no idea
[20:33] <wind-rider> hi
[20:33] <ogra> ping the channel
[20:33] <ogra> and hope for a reply ;)
[20:33] <wind-rider> can i ask a question about how packages depend on each other here?
[20:33] <ogra> wind-rider, #ubuntu-motu would probably be better for that
[20:34] <wind-rider> ogra: ok
[20:36] <directhex> asac, the build system is already freaky enough... raising ulimit is the sensible thing to do
[20:36] <ogra> asac, tesbuil on your babbage ?
[20:36] <ogra> Ütestbuild
[20:44] <asac> directhex: was that done in a different way before?
[20:44] <asac> wonder why it built in karmic
[20:44] <asac> ogra: packed up ... and sd card isnt ready ;) ...
[20:45] <asac> i am quite sure its only this
[20:45] <ogra> ah
[20:45] <ogra> well, mine is packed up as well ...
[20:45] <asac> heh
[20:45] <directhex> asac, there are very very few differences from karmic. mono in lucid is a bugfix release in the same branch
[20:45] <ogra> my HW is the only stuff i have readily packed ....
[20:45] <ogra> who needs undrewear
[20:46] <asac> directhex: right. but that compile line? maybe it was broken in multiple files?
[20:46] <directhex> asac, doubtful. change in the buildd's limits.conf ?
[20:47] <directhex> wait, 1024 is what i have here? @_@
[20:47] <directhex> oddness
[20:47] <asac> or mcs now keeps files open longer for speed up etc?
[20:47] <directhex> 1453 mono-<IP_ADDRESS>+dfsg/mcs/class/corlib/corlib.dll.sources
[20:48] <directhex> yeah, maybe resource leakage
[20:49] <ogra> as i said, usually the limit is automatically raised by the kernel
[20:49] <ogra> but that kernel on the arm buildds is odd
[20:49] <directhex> oh... kernel weirdness then?
[20:50] <ogra> not sure
[20:50] <ogra> i guess we need to verify on a proper lucid system
[20:50] <ogra> which we currently all have teared down
[20:50] <ogra> for traveling
[20:56] <asac> well. we know that it happens on jocote and on one native arm builder
[20:59] <ogra> oh, did you upload already ?
[20:59] <ogra> ah, p3a
[21:02] <asac> p1a?
[21:03] <asac> yes. maybe i will upload and drop a line to lamont asking to give it back when he is done
[21:50] <ScottK> slangasek: Would you have a moment to look at the proposed fix in bug 508073 .  It's an important fix for Kubuntu, but I'm totally unfamiliar with the package.
[22:14] <slangasek> ScottK: oh, yes; have looked at the fix, it's correct, apologies for the broken upload
[22:14] <ScottK> slangasek: Cool.  Will you please sponsor.  I'm just running out the door.
[22:14] <slangasek> yes, will do
[22:14] <ScottK> Thanks
[22:36] <mr_pouit> mathiaz: mmh, you mean, completely delete server & server-ship?
[22:36] <mathiaz> mr_pouit: yes
[22:36] <mr_pouit> I only dropped 'nis' from both
[22:36] <mr_pouit> ah ok
[22:36] <mr_pouit> I'll do this then
[22:36] <mathiaz> mr_pouit: IIUC these files are there because xubuntu seeds were branched from the ubuntu.seeds
[22:37] <mathiaz> mr_pouit: and thus server and server-ship have been around since then
[22:37] <mathiaz> mr_pouit: I don't think that there is a xubuntu server version?
[22:37] <mr_pouit> no
[22:38] <mr_pouit> but Im' not sure. Isn't ship used for the alternate iso?
[22:38] <mathiaz> mr_pouit: well - is there an alternate xubuntu image?
[22:39] <mathiaz> mr_pouit: I'm refering to *server* and *server-ship*
[22:39] <mr_pouit> ah, ok. There's no 'server' file, that's why I was confused ^^
[22:39] <mr_pouit> okay, only server-ship
[22:39] <mr_pouit> I'll drop it
[22:40] <mathiaz> mr_pouit: great thanks
[22:40] <mr_pouit> I guess all the *-server can go as well?
[22:41] <crimsun> mathiaz: do you plan to push your alsa-driver changes to bzr?
[22:41] <mathiaz> crimsun: hm - I thought I did
[22:42] <mathiaz> crimsun: arghh - different rich root support
[22:43] <mathiaz> crimsun: that's why I can push back to lp:~ubuntu-core-dev/alsa-driver/ubuntu.new/
[22:43] <mathiaz> crimsun: *cannot*
[22:44] <crimsun> mathiaz: hmm, okay
[22:44] <mathiaz> crimsun: let me fix that
[22:44] <mr_pouit> bzr is so inefficient with its<PHONE_NUMBER>746 formats :}
[22:48] <mathiaz> crimsun: there - done
[22:49] <crimsun> mathiaz: thanks!
[22:57] <Incubuss> anyone willing to test a bug for me? I'm running Alpha 2 and tried to log into a guest session but it didn't work and left me with a blank screen (thats not the bug though)
[22:57] <Incubuss> so I hit atrl + alt + F1 and logged in and restarted X
[22:58] <Incubuss> when I came back found that everything I had typed had been sent over pidgin to the last person I was talking to...
[23:59] <ccheney> fsck it appears win7 ate my system
[23:59] <ccheney> it messed with the partition table and now i can't boot the system properly
[23:59] <ccheney> er into lucid at all really it appears to just hang


[03:37] <oSoMoN> trainguards: can I have a silo for line 56, please?
[03:38] <oSoMoN> (I’ll also need a binary copy into that silo, once assigned)
[03:39] <robru> oSoMoN: on it
[03:39] <robru> oSoMoN: didn't I just do an oxide-qt for yo?
[03:39] <oSoMoN> robru, that was for 1.7.4, yesterday
[03:40] <oSoMoN> robru, but we found more critical issues, which were fixed in 1.7.5 and 1.7.6, now we need to land the fixes
[03:40] <robru> oSoMoN: heh, ok
[03:40]  * robru is totally out of the loop
[03:41] <robru> oSoMoN: what's the PPA to copy from?
[03:41] <oSoMoN> robru, https://launchpad.net/~phablet-team/+archive/ubuntu/ppa/+packages
[03:41] <robru> oSoMoN: thanks
[03:42] <robru> oSoMoN: ok, copy looks good. feel free to run build job
[03:42] <oSoMoN> robru, thanks!
[03:42] <robru> oSoMoN: you're welcome!
[04:24] <Mirv> early oSoMoN :) (or late)
[04:50] <ToyKeeper> Most likely going to need some pay-ui fixes before this next milestone...  nobody has been able to get an app purchase to work.
[08:21] <davmor2> Saviq: Don't think you're getting off that lightly....oh no sir.....now it will be blaming you twice.......once for leaving that team and again for not fixing it before leaving ;)  Enjoy your excursion into magic pendants :D
[08:21] <Saviq> davmor2, tx ;)
[08:23] <Mirv> ;) happy journey to server, Saviq
[08:23] <sil2100> ;)
[08:24] <Laney> Serviq
[08:27] <fgimenez> hi trainguards, i need permission for requesting a silo
[08:28] <fgimenez> trainguards, could you help me with this please?
[08:28] <sil2100> fgimenez: hey, sure, I can add you to the permission lists - do you know the essentials of how the CI Train works?
[08:29] <fgimenez> sil2100, more or less, i'm following https://wiki.ubuntu.com/citrain/LandingProcess
[08:30] <sil2100> Ok then, let me add you in this case but remember to poke us whenever you have any questions
[08:32] <sil2100> fgimenez: you should be set-up now
[08:32] <fgimenez> sil2100, thanks a lot :) we have the MR ready and i have a link for the test plan
[08:32] <fgimenez> sil2100, ok thx!
[09:51] <sil2100> fgimenez: assigning a silo - just make sure no existing AP tests regress with the new autopilot :)
[09:52] <sil2100> fgimenez: ...actually, it seems I can't assign a silo since we're out of free silos
[09:52] <fgimenez> sil2100, ok thanks! yep that's it :)
[09:53] <sil2100> Mirv: do we need silo 18 now?
[09:54] <Mirv> sil2100: well it'd be the testbed for further upstream work, but as silos are full I can free it for now (I've also checked no recent upstream activity on the branches)
[09:56] <Mirv> freed
[09:57] <sil2100> Mirv: thanks :) Let's hope we can open up the gates soon
[09:57] <sil2100> Mirv: I guess since we won't be using ubuntu-rtm anymore, might be a good idea to increase the number of silo PPAs
[09:58] <sil2100> Since we don't have ephemeral PPAs yet
[09:58] <sil2100> Having both stable and 'w' in only 30 silos will be hell
[10:18] <Mirv> that's true
[11:11]  * Mirv makes a deal about XPS 13 Developer Edition \o/
[11:22] <popey> Mirv: blog your experience pls :)
[11:22] <popey> Mirv: I'm considering just keeping my x220 till it dies.
[11:29]  * sil2100 off to prepare lunch
[11:35] <tsdgeos> cihelp: Can we make MR created by community members also get run in CI?
[11:35] <tsdgeos> Like https://code.launchpad.net/~feng-kylin/unity8/openPrepopulatedScopeInManageDash/+merge/257616 doesn't get run automatically because it's a community member (or that's the only difference i could find to any other MR)
[11:36] <tsdgeos> so i have to trigger a CI build manually
[11:36] <tsdgeos> which is a bit suboptimal
[11:37] <popey> isn't it because the person isn't in the team
[11:37] <popey> not that they're community
[11:37] <popey> community core apps developers have CI run against their merges just fine.
[11:37] <popey> but if a random drive by community person does a merge then it doesn't because they're not in the team.
[11:38] <popey> tsdgeos: ^
[11:38] <tsdgeos> maybe
[11:38] <tsdgeos> still i think it makes sense to get run CI all the time
[11:38] <tsdgeos> what does it matter if they are on the team or not?
[11:39] <popey> drive by malicious code executed on our hardware?
[11:39] <popey> (I suspect)
[11:41] <tsdgeos> i feel that's a rare possibility compared to the burden of me having to trigger builds manually
[11:41] <tsdgeos> but oh well
[11:42] <fgimenez> trainguards, sorry, don't know if this is already done, is there a free silo for the AP request?
[11:51] <Mirv> popey: I'll blog about it, yes
[11:53] <Mirv> fgimenez: you have the silo already, 018
[11:53] <fgimenez> Mirv, ok thanks!
[12:49] <pmcgowan> sil2100, whats the latest
[12:53] <pmcgowan> sil2100, sorry disconnected
[14:29] <pmcgowan> sil2100, jibel update?
[14:29] <sil2100> pmcgowan: hey!
[14:29] <sil2100> pmcgowan: we sent out e-mails to you
[14:29] <sil2100> Check your mail ;)
[14:29] <pmcgowan> ok will look
[14:30] <jibel> pmcgowan, I just sent the testing report
[14:30] <sil2100> pmcgowan: in the meantime jibel finished the final formal report, it should be sent out soon (if it wasn't yet)
[14:32] <sil2100> kenvandine: you'll have to wait probably, we're out of vivid silo ;)
[14:32] <kenvandine> sil2100, no rush on the vivid silo
[14:32] <kenvandine> but we are rushed for an rtm silo, which i already assigned :)
[14:33] <kenvandine> pmcgowan, ^^ building now, so far on schedule :)
[14:34] <sil2100> oSoMoN_: hey! How's testing of oxide-qt 1.7.6 going?
[14:34] <pmcgowan> sil2100, jibel even the wizard crash requires specific back forward and timing to hit
[14:34] <pmcgowan> so not sure thats a blocker
[14:34] <oSoMoN_> sil2100, on it, looking good so far, should be good for QA validation very soon
[14:35] <pmcgowan> only the browser crash seems worthy of discusuion
[14:37] <sil2100> pmcgowan: the store issues also seem webbrowser related
[14:42] <davmor2> sil2100: that is my best guess and might not be at all
[14:45] <davmor2> sil2100, pmcgowan: I'm assuming that the intial screen is a webview that creates a frame and is then destroyed to open the ubuntu one account web frame instead.  At that point crashes.  It seemed the most logical explanation considering it works when you have a u1 account
[14:46] <pmcgowan> davmor2, that would be good as we have that fix in progress
[14:47] <jibel> pmcgowan, re wizard if mterry_ is sure that back/forward is key to triggering the bug, I'm fine to not block on it.
[14:47] <sil2100> pmcgowan: anyway, if the wizard bug requires specific steps to reproduce then I suppose it would be fine to let it slip for this release
[14:47] <sil2100> I just didn't want new users to curse when trying to change their language ;)
[14:48] <pmcgowan> yeah if it needs a back with specific timing I would not block
[14:48] <jibel> pmcgowan, bug 1450243 is a blocker IMO, the only way out is to reboot
[14:48] <pmcgowan> jibel, we can address that in day one update though
[14:48] <pmcgowan> user wont hit it in first hour?
[14:49] <jibel> if they don't try to purchase something in first hour they won't hit it
[14:49] <pmcgowan> since we have only a handful of purchases in last months
[14:50] <pmcgowan> I would say no
[14:50] <sil2100> mterry_: ping
[14:55] <pmcgowan> jibel, do we still have the issue with the version string? I was thinking that was sortof critical but maybe not for one image
[14:58] <sil2100> jibel: how much time do you think would be needed to re-run 30% of tests due to the oxide-qt landing?
[14:59] <jibel> pmcgowan, the version string is fine on this image. It must be confirmed on an image where the rootfs didn't change.
[14:59] <om26er> Kaleo, Hi!
[14:59] <om26er> Kaleo, I reported camera-app test failures a few days ago. Can you look into those now ?
[15:09] <jibel> sil2100, last time it took 3 hours with 2 testers
[15:11] <sil2100> jibel: so in theory if we land the new oxide-qt in the nearest time we would sill be able to get the image re tested today by the US crew, right?
[15:11] <Kaleo> om26er, sure
[15:12] <om26er> Kaleo, I fixed one of them, the MR is here: https://code.launchpad.net/~om26er/camera-app/test-fix/+merge/256382
[15:13] <jibel> sil2100, in theory yes
[15:13] <sil2100> jibel: well, it indeed depends when we get oxide in, since image builds take a while too... ok, thanks :)
[15:14] <Kaleo> om26er, 2 to go?
[15:14] <sil2100> pmcgowan: so, what's the decision from your side? We try to get the webbrowser issues fixed (new oxide), retest and done?
[15:14] <Kaleo> https://bugs.launchpad.net/camera-app/+bug/1444655
[15:14] <Kaleo> https://bugs.launchpad.net/camera-app/+bug/1444645
[15:14] <om26er> Kaleo, yep
[15:14] <rvr> sil2100: If we begin to test the pending silos, anything to take into account?
[15:15] <sil2100> rvr: the highest priority, as it's a blocker fix, would be silo 28 - but it's not ready yet
[15:16] <sil2100> rvr: not much else that would be safe to land to vivid right now
[15:16] <sil2100> rvr: we have a few good ubuntu-rtm silos that need releasing, but they're not set as ready for QA yet
[15:16] <sil2100> pstolowski: how's the scopes fix RTM testing going?
[15:16] <rvr> sil2100: I have one for RTM in the queue
[15:17] <rvr> sil2100: ubuntu-rtm/landing-002 - gst-plugins-good0.10,qtmultimedia-opensource-src,qtmultimedia-opensource-src-gles : rsalveti
[15:17] <rsalveti> there is another one coming in a minute
[15:17] <rsalveti> hotfix, rtm
[15:17] <pmcgowan> sil2100, yes land oxide fix and retest
[15:18] <sil2100> rvr: yeah, well, that one I think was meant to land as well, but I think it wasn't signed-off yet since it probably needed a bit more testing
[15:18] <sil2100> But it's targetted to land indeed
[15:18] <sil2100> pmcgowan: ok, thanks
[15:18] <om26er> renatu, Hi!
[15:18] <rvr> rsalveti: Silo 4?
[15:19] <rsalveti> rvr: yeah, silo 4, just moved to QA
[15:20] <pstolowski> sil2100, not good unfortunately :(. we've just found a few moments ago that this fix, when backported, uncovers some other issues that affect only RTM. Fixing it proper would need a great chunk of other trunk code to be backported. I'm currently preparing a workaround for the favorites bug that can be applied on the shell plugin side
[15:20] <rvr> rsalveti: "On airplane mode battery discharge more rapidly than with airplane mode off"
[15:21] <rvr> rsalveti: So this requires leaving the phone some hours to discharge, right?
[15:22] <rsalveti> rvr: I added more info to the bug, but yeah, that is the best way to check
[15:23] <rvr> rsalveti: Ok
[15:24] <pstolowski> sil2100, can you reconfigure silo 3 for me? it's failing because I changed it to shell plugin
[15:24] <sil2100> pstolowski: sure
[15:24] <john-mcaleely> jibel, sil2100 just to check - the vivid tarball for krillin is still in queue for +1, yes?
[15:25] <sil2100> john-mcaleely: yes, sorry about that, RC and hot-fix OTA are in the way ;)
[15:25] <sil2100> john-mcaleely: still in the queue
[15:25] <renatu> om26er, hi
[15:25] <john-mcaleely> no worries. just don't want to miss the news when it arrives :-)
[15:25] <om26er> renatu, I left a comment on https://code.launchpad.net/~renatofilho/address-book-app/fix-test_import_from_sim/+merge/256204
[15:25] <sil2100> rvr: this might be a good thing to work on if no vivid-blocker or rtm silos are ready
[15:25] <sil2100> ^
[15:25] <om26er> renatu, can you please fix that so we can merge that fix
[15:25] <renatu> ok
[15:26] <renatu> om26er, btw it is on  silo 20
[15:26] <rvr> sil2100: Yeah
[15:27] <om26er> renatu, hmm, ok we can rename the test later.
[15:27] <renatu> om26er, I can rename it now before it lands
[15:27] <mandel> trainguards can I get silo 005 reconfigured?? We need to add location-service to it else the fix does not work
[15:28] <om26er> renatu, that'd be great.
[15:29] <sil2100> mandel: on it
[15:29] <sil2100> mandel: I assume ubuntu silo 005, right?
[15:29] <ogra_> sil2100, i have another initramfs-tools-ubuntu-touch dput to do ... (just FYI ... as always this will only get used and tested from a device tarball build later)
[15:29] <pmcgowan> elopio, is silo 0 ready for qa?
[15:30] <renatu> om26er, done, could you approve it?
[15:30] <pmcgowan> sil2100, rvr for rtm we want silos 0 and 4
[15:30] <elopio> pmcgowan: wrong ping? I don't know what's in silo 0.
[15:30] <om26er> renatu, done.
[15:30] <pmcgowan> elopio, sorry :(
[15:30] <renatu> om26er, thanks
[15:30] <rvr> pmcgowan: Not 2?
[15:31] <sil2100> ogra_: hope it doesn't introduce any big changes, since we're almost done with the RC
[15:31] <pmcgowan> rvr, oh yeah we sadi 2 as well
[15:31] <pmcgowan> overooked it
[15:31] <rvr> pmcgowan: Ok, so 0, 2 and 4
[15:31] <pmcgowan> ack
[15:32] <ogra_> sil2100, it is needed for factory images, else all devices will only use 8GB, even the ones that have 32 ... (it resizes the userdata FS on first boot in the factory)
[15:32] <ogra_> sil2100, we need the binary built in the PPA to actually test it ... but it is irrelevant on the rootfs (only used in the initrd in the device tarball)
[15:33] <sil2100> ogra_: ok, makes sense
[15:33] <pmcgowan> ogra_, is that going into todays image for rc?
[15:33] <rvr> RTM silo 0 is not marked for QA sign off yet
[15:33] <pmcgowan> ogra_, we had defered the resizing stuff
[15:34] <ogra_> pmcgowan, oh ? i was told it has to be ready be EOW ... but anyway it ia an all manual process to pull that bit into the device tarball, so no risk here
[15:34] <ogra_> s/ia/is/
[15:35] <pmcgowan> ogra_, so does it dynamically resize on first boot now?
[15:35] <pmcgowan> vs fixed size
[15:35] <ogra_> it checks how much space is unused and if thats above a threshold it will expand the FS to the full disk size
[15:35] <rsalveti> ogra_: pmcgowan: iirc we're using 16gb by default
[15:35] <ogra_> ah
[15:35] <rsalveti> which is the device we are currently using
[15:35] <rsalveti> but, we need the resizing
[15:36]  * ogra_ didnt know the exact number
[15:36] <rsalveti> just not required to land for the factory image
[15:36] <pmcgowan> right not today
[15:36] <rsalveti> yeah
[15:36] <pmcgowan> ok
[15:36] <pmcgowan> sil2100, ^^
[15:36] <ogra_> pmcgowan, yeah, but we need the binary in the PPA to actually be able to test it
[15:36] <pmcgowan> ok
[15:36] <ogra_> else we are stuck
[15:36] <pmcgowan> I see
[15:36] <pmcgowan> ok
[15:36] <pmcgowan> so its there but not turned on
[15:36] <ogra_> no worries, it wont actually land anywhere
[15:37] <pmcgowan> ok
[15:37] <ogra_> (apart from showing up on the changes indeed ... )
[15:37]  * ogra_ dputs
[15:50] <oSoMoN_> ubuntu-qa: silo 28 (with oxide 1.7.6) is ready for validation
[15:50] <rvr> oSoMoN_: Ack
[16:02] <sil2100> jibel: meeting!
[16:10] <mterry_> sil2100, sorry, was afk
[16:10] <mterry_> sil2100, but am here for a moment  :)
[16:11] <sil2100> mterry_: a question about the wizard crash
[16:11] <sil2100> mterry_: does it require some really specific steps, or is it easily reproducible?
[16:12] <mterry_> sil2100, fairly easily reproducable.  Just have to change language, go forward, go back, repeat a few times
[16:13] <mterry_> sil2100, can that change be silo'd?  I'm on vacation for the next 8 days and won't be able to babysit it, but I'd like to see it land
[16:16] <rsalveti> sil2100: jibel: going to create another silo now for a small, contained fix, that fixes the size of the booting logo (spinning ubuntu logo)
[16:16] <pmcgowan> mterry_, you have a fix?
[16:16] <rsalveti> should be ready in a few
[16:16] <mterry_> pmcgowan, https://code.launchpad.net/~unity-team/qmenumodel/nullify-state-variant/+merge/257902
[16:17] <mterry_> pmcgowan, already top-approved
[16:19] <pmcgowan> sil2100, jibel so we can try to take that fix as well, and there is a cosmetic fix to the boot logo in 26 that we can take as well
[16:19] <pmcgowan> that being the wizard crash fix
[16:32] <sil2100> mterry: is the fix tested? When would it be ready for QA sign-off?
[16:36] <rvr> sil2100: Silo 28 is empty
[16:37] <rvr> sil2100: Oh, right, creating the new image, don't mind
[16:38] <sil2100> pmcgowan: so, we landed oxide - you  think I should wait for the wizard fix before kicking a new image?
[16:38] <sil2100> Or the spinner fix?
[16:39] <ogra_> sil2100, why not kick an image inbetween
[16:39] <ogra_> so the oxide fix gets some real life testing already
[16:39] <pmcgowan> sil2100, spinner fix is ready for a quick verifiction
[16:39] <ogra_> it is not like image builds cost us anything (except time, that we have while waiting for the rest)
[16:39] <pmcgowan> sure we can kick it twice is you want
[16:40] <pmcgowan> sil2100, seems someone can check the boot logo in a few mins
[16:41] <sil2100> pmcgowan: few mins to QA verification?
[16:41] <kenvandine> sil2100, can i grab a vivid silo now?  or is there someone else ahead of me in the queue?
[16:41] <pmcgowan> sil2100, for qa its been ready
[16:42] <sil2100> pmcgowan: oh, it's ready for QA?
[16:43] <sil2100> kenvandine: not sure if we won't need one for mterry's fix
[16:43] <kenvandine> ok
[16:43] <kenvandine> his is more important
[16:44] <kenvandine> the click update bug isn't really going to be noticed by vivid users, it's really just critical for rtm
[16:44] <sil2100> pmcgowan, ogra_, jibel: I'll kick a new image now and then we can re-kick in case the spinner lands (and maybe the wizard)
[16:44] <kenvandine> but i do want to get it landed in trunk soon
[16:44] <ogra_> +1
[16:45] <pmcgowan> sil2100, its not yet marked couple mins it seems
[16:45] <pmcgowan> so yeah go ahead
[16:46] <rsalveti> sil2100: pmcgowan: already tested with the deb, just waiting the jenkins job to show that it is built and tested
[16:46] <rsalveti> should take just a few minutes
[16:46] <rsalveti> if we can test it right away, I'd wait this silo
[16:47] <rsalveti> I'd wait until we land this silo
[16:49] <pstolowski> sil2100, the favorites fix in rtm silo 3 is good to go
[16:52] <cwayne> \o/
[16:54] <robru> rsalveti: what's the status of silo 15? it looks a bit stale and isn't in the qa queue...
[16:54] <sil2100> \o/
[16:55] <sil2100> ogra_: where's imgbot?!
[16:55] <rsalveti> robru: it was but then a dput happened
[16:55] <rsalveti> still need to check it
[16:55] <rsalveti> sil2100: pmcgowan: silo 26 is ready for QA
[16:55] <robru> rsalveti: also silo 13 ;-) We're out of silos so it's possible to free any that'd be great
[16:56] <ogra_> sil2100, damn ... dead it seems ... and i have no access to my home machine atm :(
[16:56] <rsalveti> robru: I think we can free 19
[16:56] <rsalveti> ogra_: can we free silo 19?
[16:56] <rsalveti> or is there any other work you need to do in there
[16:56] <sil2100> Noooo poor imgbot!
[16:57] <kenvandine> i'll free silo 16
[16:57] <robru> kenvandine: thanks
[16:57] <kenvandine> done
[16:57] <rsalveti> robru: released 15
[16:58] <rsalveti> but we'll have the same issue soon
[16:58] <rsalveti> as we already got a big pile of silos waiting the freeze to be released
[16:58] <kenvandine> what about silo 0?  that was for mwc, and quite old
[16:58] <sil2100> rsalveti: shouldn't take long, the RC is almost good
[16:58] <kenvandine> or did we want to keep that around?
[16:59] <rsalveti> sil2100: famous last words
[17:00] <robru> kenvandine: kgunn had requested that silo relatively recently... although if he's done with it now it would be nice to free, yeah
[17:00] <kenvandine> ok, we have 2 free now :)
[17:00] <robru> kenvandine: rsalveti: great, thanks guys
[17:04] <kenvandine> now that we have 2 free, do you guys mind if i grab one?
[17:04] <kenvandine> that'll still leave one for mterry's fix
[17:04] <robru> kenvandine: bah, we just freed them up!
[17:04] <kenvandine> this is why :)
[17:04] <robru> kenvandine: j/k, but as long as it's not an SRU it should be fine
[17:04] <kenvandine> it's not
[17:05] <robru> kenvandine: k, go fo it
[17:05] <kenvandine> robru, and since i set col L, it should publish properly right?
[17:06] <robru> kenvandine: yep, as long as you set column L before assigning it's all good
[17:06] <kenvandine> great
[17:06]  * kenvandine is nervous now :)
[17:07] <robru> kenvandine: yeah you can see 'stable-phone-overlay' in the dashboard, it's good
[17:07] <kenvandine> i see
[17:12] <mterry> sil2100, you asked if my crash fix was tested, ready for QA -- it was by me, the fixer
[17:18] <ogra_> imgbot, stunt
[17:18]  * imgbot rolls on its back and purrs
[17:18] <ogra_> sil2100, ^^
[17:18] <sil2100> Ah ha!
[17:18] <sil2100> It's back! :)
[17:19] <davmor2> sil2100: it never left you just weren't looking in the right place ;)
[17:23] <renatu> elopio, all changes merged on: https://code.launchpad.net/~renatofilho/address-book-app/fix-test_import_from_sim/+merge/256204
[17:23] <renatu> elopio, could you approve it?
[17:23] <ogra_> sil2100, flowers go to my GF for being my remote typist ;)
[17:23] <elopio> renatu: yes, thanks.
[17:28] <mandel> sil2100, yes, but rsalveti took care of it, thx!
[17:49] <kenvandine> crap... dep wait... guess i need to refactor my tests to not depend on ubuntu-sdk-libs
[17:52] <om26er> ricmm, where do I find the test plan for USC ? the one attached to the spreadsheet is non-existent.
[17:54] <om26er> rsalveti, do you know ? ^
[17:55] <rsalveti> om26er: not sure we have one
[17:57] <om26er> rsalveti, interesting, what should I test apart from making sure the Ubuntu logo is bigger on boot ? :)
[17:57] <rsalveti> om26er: that was the only change
[17:57] <om26er> rsalveti, I guess that code only runs on device boot ? so if it boots then things are fine ?
[17:58] <rsalveti> om26er: that code yeah
[17:58] <rsalveti> om26er: you'll see a big difference on arale
[17:58] <om26er> rsalveti, yeah, I noted
[18:10] <imgbot> [18:10] <imgbot> [18:42] <ricmm> om26er_: as salveti said, the only binary that changed is the actual spinner program
[18:42] <ricmm> which is different than usc itself
[18:42] <ricmm> however, just making use the phone boots to unity and you can use apps and so on it means its fine
[19:01] <rsalveti> sil2100: pmcgowan: ricmm: publishing silo 26
[19:02] <sil2100> Did it pass sign-off? :)
[19:02] <sil2100> Ah, it did
[19:03] <ogra_> so whats left ?
[19:03] <sil2100> I'm semi-EOD now so missed it
[19:03] <pmcgowan> mterry, do you have a silo yet?
[19:03] <sil2100> The wizard fix
[19:03] <sil2100> But I don't see it in a silo yet
[19:03] <sil2100> mterry: how far are you with the fix?
[19:03] <mterry> sil2100, pmcgowan: no --- I thought I saw you guys putting it in a silo...
[19:03] <mterry> sil2100, the fix is ready and top-approved.  a one-liner
[19:04] <sil2100> Uh oh :)
[19:04] <sil2100> mterry: do you ahve a moment to put in a request?
[19:04] <mterry> sil2100, https://code.launchpad.net/~unity-team/qmenumodel/nullify-state-variant/+merge/257902
[19:04] <mterry> sil2100, ok...
[19:04] <sil2100> mterry: if you're busy I can do that
[19:04] <mterry> sil2100, in a meeting now, but will be done soon
[19:04] <sil2100> mterry: ok, creating one then
[19:05] <mterry> sil2100, ok thanks -- sorry I dropped the ball on that
[19:05] <mterry> I thought I saw you folks talking about a silo with a few tiny fixes, including the crash one
[19:05]  * mterry is not on top of things today
[19:06] <robru> mterry: I'm afraid there are zero silos available.
[19:06] <ogra_> kick one out then
[19:06] <ogra_> we need it for RC
[19:06] <mterry> robru, boo
[19:06] <robru> ogra_: well I did two already, but then they filled up again. I'm not sure what others are freeable
[19:07] <ogra_> just be evil (we will point people at you later)
[19:07] <robru> oh heh, 26 just freed...
[19:07] <ogra_> yep
[19:07] <ogra_> :)
[19:08] <robru> mterry: k ^
[19:09] <sil2100> Building the silo
[19:09] <sil2100> ;)
[19:10]  * mterry hugs robru
[19:10]  * mterry also throws an arm around sil2100
[19:11] <ogra_> and what about powerpc ?
[19:18] <rsalveti> pmcgowan: can you add the milestone for https://bugs.launchpad.net/powerd/+bug/1450568 ? it's quite high as if a process holding a wakelock dies, the lock itself wasn't going away with the process
[19:19] <rsalveti> this fixes it, releases once the process that requested it goes away from the bus
[19:19] <rsalveti> pmcgowan: fix already in a silo, testing, and waiting qa
[19:19] <rsalveti> could be one of the reasons why a unity8 crash could end up draining the battery
[19:20] <ogra_> +1
[19:20] <rsalveti> *tested
[19:23] <sil2100> \o/
[19:47] <sil2100> mterry: are you testing silo 26? :)
[19:47] <sil2100> mterry: please switch it to tested whenever it's ready for QA sign-off
[19:47] <sil2100> It's the only critical thing we need before kicking a new image
[19:49] <pmcgowan> sil2100, any qa around?
[19:49] <jibel> pmcgowan, qa is around
[19:50] <pmcgowan> there he is
[19:50] <pmcgowan> jibel, silo 16 has a wakelock fix if we want it
[19:51] <pmcgowan> jibel, and rtm 0 4 and 5 all ready
[19:51] <pmcgowan> jibel, what moves a silo from needs signoff to ready to test?
[19:52] <jibel> pmcgowan, manual review
[19:52] <jibel> essentially check the diff, changelog, bugs, and approved for a milestone
[19:52] <pmcgowan> gotcha
[19:53] <pmcgowan> jibel, what do you think about ubuntu 16, rsalveti  wanted to land it
[19:53] <pmcgowan> probably more important for rtm really
[19:53] <jibel> it's nice to have as long as it is not too invasive.
[19:53] <pmcgowan> its a one liner when an app disappears
[19:55] <pmcgowan> jibel, we could wait on vivid, ut get it out sooner in rtm
[19:55] <pmcgowan> but
[19:57] <sil2100> I want mterry's fix in vivid ASAP
[20:19] <pmcgowan> sil2100, seems it requires a fresh flash
[20:19] <pmcgowan> so not sure how we even test it
[20:24] <pmcgowan> sil2100, ok I got it with just a wizard re-enable
[20:28] <pmcgowan> sil2100, with the fix I cannot hang the wizard
[20:28] <pmcgowan> without it I hung it in 4 tries
[20:29] <pmcgowan> tested on 29
[20:29] <pmcgowan> arale
[20:30] <sil2100> Nice
[20:30] <om26er_> pmcgowan, what are the steps I should try to reproduce. I was not able to reproduce the crash yesterday.
[20:30] <sil2100> Ok, I say the silo is tested locally now, let's hand it over to QA
[20:31] <om26er_> now I need to be able to reproduce it so that I can validate the silo
[20:31] <pmcgowan> om26er_, I eneabled the wizard, change language continue back change language continue back etc
[20:31] <pmcgowan> on te continue it hung for me
[20:31] <pmcgowan> blank screen
[20:31] <sil2100> om26er_: silo 26 ready for sign-off, pmcgowan can give you useful info :)
[20:31] <pmcgowan> om26er_, but you  need to change the language
[20:33] <om26er_> pmcgowan, aah, finally.
[20:33] <om26er_> took me 8 language switches
[20:33] <pmcgowan> om26er_, awesome
[20:34] <om26er_> sil2100, any testplan to run ?
[20:40] <pmcgowan> tedg, how do we test a change to qmenumodel per https://code.launchpad.net/~unity-team/qmenumodel/nullify-state-variant/+merge/257902
[20:43] <pmcgowan> om26er_, I would say verify indicators and settings still work properly
[21:04] <rsalveti> pmcgowan: so silo rtm 6 is ready for QA
[21:09] <om26er_> pmcgowan, silo 26 approved.
[21:10] <pmcgowan> om26er_, woot
[21:12] <pmcgowan> will land it and trigger a build
[21:29] <om26er_> pmcgowan, do we know if bug 1446584 affects arale as well ?
[21:32] <pmcgowan> om26er_, it does yes
[21:33] <pmcgowan> om26er_, silo 16 and 30 are both battery related that are slated for rtm ota
[21:34] <om26er_> pmcgowan, they are showing up as vivid silos, not RTM on the board.
[21:35] <pmcgowan> om26er_, there are sios for both
[21:35] <pmcgowan> om26er_, we wanted to stop landings for vivid though
[21:35] <pmcgowan> unfortunately out of time
[21:35] <pedronis> silo 4 is the rtm silo matching silo 30
[21:36] <pedronis> if I understand things
[21:40] <sil2100> Publishing
[21:42] <sil2100> pmcgowan: once the silo migrates I'll kick a new image
[21:42] <pmcgowan> sil2100, vg sir
[21:42] <pmcgowan> I think we lock now
[21:42]  * pmcgowan crosses fingers
[21:42] <rsalveti> alright
[21:42] <rsalveti> then sil2100 will take care of it :-)
[21:42]  * rsalveti gets back to the camera bug
[21:43] <sil2100> :) Yeah, I'm still around
[21:50] <sil2100> Ok, building the image
[21:51] <sil2100> o/
[21:51]  * sil2100 off now
[21:51] <ricmm> o/
[21:51] <sil2100> If anything, tomorrow there's a national holiday, so I'll be only around briefly
[21:51] <sil2100> See you!
[21:55] <imgbot> [22:21] <robru> bfiller_: no silos available, sorry
[22:22] <robru> bfiller_: I'll send an email asking people to free any that aren't needed
[22:22] <bfiller_> robru: thanks
[22:22] <robru> bfiller_: it's been tight all day. as soon as I free one, one more fills it up...
[22:43] <robru> mzanetti: camako: are you guys using silo 0? I just noticed kgunn is on holiday
[22:44] <camako> robru, kgunn put anpok in charge of it. Yes we are using it.
[22:44] <robru> camako: ok thanks
[22:50] <davidbarth> silo 003 good for qa, if you want to reclaim some more silos
[22:51] <robru> davidbarth: thanks for moving that along!
[23:17] <ogra_> imgbot, status 189 vivid
[23:18] <imgbot> Status: succeeded, Started: 2015-04-30 21:51:39 UTC, Finished: 2015-04-30 22:43:37 UTC
[23:18] <imgbot> Build URL: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/+build/25965
[23:18] <imgbot> Changelog: http://people.canonical.com/~ogra/touch-image-stats/189.changes
[23:18] <ogra_> aha
[23:25] <bfiller_> robru: mind reconfiguring silo 28
[23:25] <bfiller_> robru: added a new package
[23:26] <robru> bfiller_: sure, one sec.
[23:27] <robru> bfiller_: ok done.
[23:27] <bfiller_> robru: thanks
[23:28] <robru> bfiller_: you're welcome!


[12:03] <LostSoul_> Hi
[12:04] <LostSoul_> I'm getting in exim4:
[12:04] <LostSoul_><EMAIL_ADDRESS>Unrouteable address
[12:04] <LostSoul_> Any ideas?
[12:08] <iGeni> whe i make 1 of my servers sync with ntp  can i let all my other server sync to that internal server?
[12:08] <iGeni> instead of putting them all open
[22:25] <arcsky> hi guys i have problem with openvpn. it doesnt start when i do /etc/ini.t/openvpn start
[22:37] <pmatulis> arcsky: what ubuntu release are you using? openvpn may be using upstart, not sysvinit. try 'sudo service openvpn start' ?
[22:42] <TheEagerPadawan> hi, i've set up a nginx web server on my desktop and a apache virtually (virtualbox) in bridged mode. Both systems can ping each other. However when i try to wget a file on the virtualserver that is hosted by the nginx on the desktop it doesn't work, sadly enough
[22:48] <pmatulis> TheEagerPadawan: elaborate on 'doesn't work'
[22:48] <pmatulis> i.e. is it a web server error or a network error?
[22:49] <TheEagerPadawan> pmatulis: when i try to wget it doesn't start the download
[22:50] <pmatulis> TheEagerPadawan: check the web server logs to see if the request is detected
[22:51] <pmatulis> TheEagerPadawan: if detected, see if the logs can illuminate what the problem is
[22:52] <TheEagerPadawan> pmatulis: logs don't seem to say anything regarded to the download i'm trying to do
[22:52] <pmatulis> TheEagerPadawan: if not detected, forget the application layer, and go to the network layer. see if you get a response on port 80 (assuming using port 80)
[22:53] <pmatulis> nc -vz <ip address> 80
[22:54] <pmatulis> if no response, see if the desktop is listening on the port
[22:55] <TheEagerPadawan> pmatulis: got ya, thanks seems like the virtual can't reach desktop on port 80
[22:56] <pmatulis> then on desktop:
[22:56] <pmatulis> sudo lsof -i4tcp:80 -n -P
[22:56] <pmatulis> should get similar to:
[22:56] <pmatulis> nginx   993 www-data    6u  IPv4   9021      0t0  TCP *:80 (LISTEN)
[22:57] <TheEagerPadawan> nope
[22:58] <pmatulis> TheEagerPadawan: then nginx is not running
[22:58] <pmatulis> sudo service nginx start
[22:59] <TheEagerPadawan> pmatulis: what if i told you it is running
[22:59] <JanC> not configured correctly
[22:59] <JanC> ?
[23:00] <pmatulis> TheEagerPadawan: yeah, so something is just wrong with nginx
[23:01] <TheEagerPadawan> seems like that the lsof only pops up when i'm actually browsing to such said website on the desktop
[23:01] <TheEagerPadawan> by using the private ip
[23:04] <pmatulis> TheEagerPadawan: using inted/xinetd ?
[23:04] <TheEagerPadawan> pmatulis: http://www.tiikoni.com/tis/view/?id=3367282
[23:04] <pmatulis> *inetd
[23:05] <TheEagerPadawan> no, on both cases
[23:05] <pmatulis> TheEagerPadawan: does the wget command work from the desktop?
[23:06] <TheEagerPadawan> let me see
[23:06] <pmatulis> using <IP_ADDRESS>
[23:06] <TheEagerPadawan> that would be <IP_ADDRESS> wgetting from <IP_ADDRESS>
[23:08] <TheEagerPadawan> yes that works
[23:08] <TheEagerPadawan> it just the virtual that doesn't seem to get access to port 80 on the desktop
[23:11] <pmatulis> well, it sounds like a configuration problem
[23:11] <TheEagerPadawan> welp i atleast i know who to hit over the head tomorrow ;)