=== Guest18637 is now known as DarrenS
=== ssweeny` is now known as ssweeny
=== Logan__ is now known as Logan_
=== balloons_ is now known as balloons
=== kentb is now known as kentb-out
=== marga- is now known as marga
[03:10] <pitti> Good morning
[03:11] <ajmitch> morning pitti
=== FlannelKing is now known as Flannel
=== jono is now known as Guest7396
=== wgrant_ is now known as wgrant
=== Mirv_ is now known as Mirv
=== Guest37357 is now known as G
[05:39] <tjaalton> cjwatson: right, it didn't work yet the other night
[05:49] <tjaalton> cjwatson: went fine this time
[06:04] <vipzrx> how can I found the gcc search path for include<XXXX.h> ?
[06:22] <ScottK> Any reason canonical-qt5-edgers PPA is building 5.0.1 when both 5.0.2 and 5.1 are out?
[06:30] <vipzrx> ScottK:  hello
[06:30] <vipzrx> I want to know the location of some header files in a .c file , how can I di it ?
[06:36] <pitti> vipzrx: check the output of e. g. echo '#include <stdio.h>' | gcc -E -
[06:37] <vipzrx> thank you pitti
[06:38] <vipzrx> I am raeding the android source code with emacs+cedet
[06:40] <vipzrx> when I am reading the source code , the cecet tells me that it can not find some header files location . Now I must tell the cedet where are these header files /
[06:40] <pitti> vipzrx: http://stackoverflow.com/questions/344317/where-does-gcc-look-for-c-and-c-header-files
[06:41] <vipzrx> On the other hand ,the source of android is builded with export TARGET_TOOLS_PREFIX=prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8-linaro/bin/arm-linux-androideabi-
[06:41] <vipzrx> it is not the native gcc
[06:42] <vipzrx> http://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html  I have read this ,but I have no idea.sorry
[07:03] <vipzrx> pitti:  ?
[07:04] <vipzrx> I am using a cross toolchain for arm
[07:04] <vipzrx> export TARGET_TOOLS_PREFIX=prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8-linaro/bin/arm-linux-androideabi-
[07:05] <pitti> vipzrx: I gave you the link to stackoverflow; just call the cross gcc instead of just "gcc"
[07:06] <vipzrx> I got a error
[07:06] <vipzrx> http://paste.ubuntu.com/5864027/
[07:08] <vipzrx> http://paste.ubuntu.com/5864030/
[07:09] <vipzrx> zai
[07:12] <pitti> well, obviously you didn't install the header files
=== Zdra is now known as xclaesse
[07:13] <vipzrx> I have got the linaro android source
[07:15] <vipzrx> /home/jb/Documents/soft/soft_src/panda-linaro/system/core/init/init.c
[07:15] <vipzrx> http://snapshots.linaro.org/android/~linaro-android-member-ti/panda-linaro/347/linaro_android_build_cmds.sh
[07:16] <vipzrx> linaro does not ask to isntall the header , I think
[07:17] <vipzrx> linaro_android_build_cmds.sh is the autorun script to download the source and build the android
[07:38] <dholbach> good morning
[07:47] <seb128> slangasek, thanks for uploading the configglue revert
[07:50] <infinity> @pilot out
[07:50] <infinity> *cough*
[07:51] <infinity> Hrm, the bot seems to have died.
[08:13] <mlankhorst> so it would seem :o
[08:21] <mwhudson> doko: hi, i have a python test suite hang on armhf ig you want a look
[08:22] <doko> mwhudson, not really this week ...
[08:22] <mwhudson> :)
[08:22] <mwhudson> doko: i'll file a bug when i've figured something out
[08:24] <sil2100> Wellark_: ping!
=== Adri2000_ is now known as Adri2000
[08:26] <mwhudson> doko: the hanging test case is in a class called SignalsTest which makes me unhappy
[08:31] <cjwatson> tjaalton: Thanks
[08:37] <xnox> cjwatson: is http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-archive.html#s-multiverse authoritative ? Since http://www.ubuntu.com/about/about-ubuntu/licensing doesn't say multiverse requirements.
[08:38] <cjwatson> xnox: Yes
[08:38] <xnox> thanks.
[08:39] <cjwatson> Once upon a time there was something useful elsewhere about that, I think, but in any case that was common understanding among archive admins when I wrote it
[08:41] <xnox> cjwatson: i think there are packages in multiverse that discriminate against persons, groups or against fields of endeavour. Is that ok?
[08:44] <cjwatson> xnox: Yes
[08:44] <xnox> ok.
[08:44] <cjwatson> xnox: (as explicitly stated in the link you gave)
[08:45] <xnox> cjwatson: =))))
[08:45] <xnox> ah, need more coffee.
=== ivoks_ is now known as ivoks
=== mote is now known as Guest32532
[10:29] <caribou> cjwatson: infinity: I'm still having issues with my dante/autotool issue you helped with yesterday. where should I go to ask for help ?J
[10:29] <caribou> not sure #ubuntu-devel is the appropriate place
[10:31] <cjwatson> caribou: pastebin the failure
[10:31] <cjwatson> (and your current working patch)
=== tkamppeter_ is now known as tkamppeter
[10:34] <caribou> cjwatson: ok, I'll reproduce again as I'm working on two options
[10:38] <caribou> cjwatson: http://paste.ubuntu.com/5864483/
[10:38] <caribou> cjwatson: as you suggested yesterday, I investigated the source of the compilation failure
[10:39] <caribou> cjwatson: which seems to be caused by a missing HAVE_EXTRA_OSF_SYMBOLS which has nothing to do with us
[10:39] <cjwatson> caribou: It may not be relevant but given that clean rule you should drop your dh_override_clean and instead call dh_autoreconf_clean just before the two dh_clean calls
[10:40] <cjwatson> Indeed you can also drop "cp /usr/share/misc/config.guess /usr/share/misc/config.sub ." and drop the "config.guess config.sub" arguments from dh_clean, since dh_autoreconf[_clean] will take care of those
[10:40] <cjwatson> now let's look at the actual failure ...
[10:42] <cjwatson> Those are configure-generated type names so I can certainly see why that might be related
[11:00] <cjwatson> caribou: You really ought to be doing this work in saucy first, BTW.  Just trying to build it now
[11:00] <caribou> cjwatson: indeed
[11:01] <caribou> cjwatson: I'm pondering if just going with changing configure.ac & configure would be less of a waste of time
[11:01] <cjwatson> caribou: Let me have a look first
[11:02] <cjwatson> The problem is, it might be slightly less of a waste of time for you, but it's leaving a problem for future developers
[11:02] <cjwatson> We should try to avoid generated scripts in the archive that break when regenerated
=== MacSlow is now known as MacSlow|lunch
[11:15] <cjwatson> The difference is because new versions of Autoconf cause AC_AIX to be equivalent to AC_USE_SYSTEM_EXTENSIONS, but dante's very strange generation of sockaddr argument types apparently can't cope with the way glibc declares things when _GNU_SOURCE is in effect.  The most pragmatic fix appears to be to add a patch commenting out "AC_AIX" in configure.ac, since we clearly don't care about that.
[11:15] <cjwatson> caribou: ^
[11:15] <cjwatson> caribou: But OMG, somebody has *already* left a timebomb in dante: look at debian/patches/03-configure.patch
[11:15] <cjwatson> That's a horrifyingly bad patch
[11:15] <cjwatson> caribou: So maybe your best alternative is to go with the flow and patch both configure.ac and configure after all :-(
[11:16] <cjwatson> Given that the Debian maintainer has been either negligent or incompetent in this case
[11:17] <cjwatson> (You might patch out the "sleep 10" while you're at it so that configure is less annoying about options it doesn't recognise ...)
[11:17] <caribou> cjwatson: hmm ok I'll take your advice on that
[11:18] <cjwatson> The alternative is taking on the tech debt of refactoring 03-configure.patch as a proper patch to the source files, or calling configure in a different way, or whatever
[11:18] <caribou> cjwatson: If I may ask, can you add a task for saucy to the LP bug so I can go back to SRU logic ?
[11:18] <caribou> https://bugs.launchpad.net/ubuntu/+source/dante/+bug/816153
[11:18] <ubottu> Launchpad bug 816153 in dante (Ubuntu Precise) "dante-server using the wrong libc.so" [Medium,In progress]
[11:18] <cjwatson> caribou: the task without a series is implicitly for saucy.
[11:19] <cjwatson> no need to create an explicit saucy task.
[11:19] <caribou> cjwatson: ah, ok, wasn't sure
[11:19] <cjwatson> I'm going to file a Debian bug about that patch to a generated file
[11:19]  * caribou must review the wiki again before sending the email to be added to UbuntuBugControl
[11:21] <caribou> cjwatson: once again thanks for the help & advice
[11:21] <infinity> Note that there's probably a semi-valid reason the current patch only touches configure and not configure.ac
[11:21] <infinity> Patching both appears to trip maintainer mode and try to regen.  Yay abuse of autotools.
[11:21] <infinity> (But yes, the right thing to do in Debian would be to make dh_autoreconf work with the package)
[11:21] <cjwatson> But hence dh-autoreconf.
[11:22] <cjwatson> I'll send a bug with detailed advice.
[11:22] <infinity> The above was just my hinting that caribou's path of least resistance (especially for an SRU) would be to patch *only* congfigure, as wrong and ugly as that sounds.
[11:23] <cjwatson> You may, sadly, be right.
[11:23] <caribou> infinity: I would prefer to go the dh-autoreconf way as well, if it was not so time consuming for a package that seems rather 'dormant'
[11:23] <infinity> caribou: Well, dh-autoreconf is the right thing to suggest in Debian and try to get fixed.
[11:23] <infinity> caribou: For an SRU, the minimally invasive 1-line patch directly to configure will get the job done, though.
[11:24] <infinity> (And has precedence in the current broken packaging)(
[11:25]  * infinity notes that the Debian patch to configure is also incorrect for other reasons...
[11:25] <infinity> Hardcoded path to libdl that no longer lives there.
[11:25] <infinity> Whee.
[11:26] <caribou> infinity: out of curiosity, can quilt touch the same file with to separate patches ? I mean my patch will come on top of this 03- one, right ?
[11:27] <infinity> Yeah, you can patch the same file as many times as you want.
[11:27] <infinity> They just have to stack.
[11:27] <caribou> infinity: ok, thanks
[11:27] <caribou> I'll get the debdiffs in after lunch
[11:30] <caribou> I will also try to summarize our discussions in the bug to leave a trace of the analysis
[11:32] <shadeslayer> Laney: question, account-plugin-groupwise depends on empathy, any reason why? aren't each of the account-plugins designed to work with the Telepathy framework? or do they only work specifically with empathy?
[11:32] <cjwatson> caribou: You might need to fix the libdl path too, for much the same reason.  I noticed it mentioned in another bug
[11:32] <shadeslayer> Laney: the other account plugins depend on empathy as well
[11:32] <caribou> cjwatson: ok, will do
[11:33] <Laney> shadeslayer: Not sure - I guess it was like that before I touched the package
[11:33] <Laney> shadeslayer: Ask kenvandine maybe
[11:33] <shadeslayer> Laney: same thing with unity-asset-pool
[11:34] <caribou> cjwatson: https://bugs.launchpad.net/ubuntu/+source/dante/+bug/890887 ?
[11:34] <ubottu> Launchpad bug 890887 in dante (Ubuntu) "socksify try to LD_PRELOAD a missing library" [Undecided,Confirmed]
[11:34] <shadeslayer> not quite sure why it's there in Depends, imho unity should depend on that, and not the account plugins
[11:34] <shadeslayer> ( and unity already does )
[11:34] <shadeslayer> will ask kenvandine when he comes online
[11:34] <Laney> presumably it uses icons only provided there?
[11:34] <infinity> caribou: In fixing the libdl path, revert the Debian patch that hardcodes it and go back to fixing the detection code like you did for libc.
[11:35] <infinity> caribou: Cause hardcoding won't work in a multiarch world, obviously.
[11:35] <caribou> infinity: indeed. ok, I'll work on that & come back here so you can review the changes if you don't mind
[11:35] <caribou> though that will be part of the sponsoring phase anyway
[11:36] <infinity> caribou: *nod*
[11:36] <infinity> caribou: I can sponsor all the uploads once we're happy with them.
[11:36] <cjwatson> caribou: Yes, though I only skim-read it
[11:37] <caribou> good. lunchtime now
[11:39] <shadeslayer> Laney: not sure, I see some icons in the source
[11:39] <shadeslayer> Laney: ./data/icons/hicolor_apps_48x48_im-facebook.png
=== MacSlow|lunch is now known as MacSlow
[12:14] <cjwatson> caribou: FYI, I filed Debian #716681
[12:14] <ubottu> Debian bug 716681 in dante "dante: patches generated configure file without corresponding patches to true source; incredibly confusing build system" [Normal,Open] http://bugs.debian.org/716681
[12:28] <sil2100> Wellark_: hi! Are you around right now?
[12:35] <caribou> cjwatson: looking at the bug; now that I'm at it, would be be too much work to try to fix this myself (with some help from charitable  souls) ?
=== cmagina-away is now known as cmagina
[12:39] <cjwatson> caribou: Don't know, depends how much you fancy diving into the deeper corners of the autotools
[12:39] <cjwatson> caribou: The fix will probably wind up being too complex for precise, at least ...
[12:40] <caribou> cjwatson: hmm, I think I have better use of my current cycles; PlusOne being one of them
[12:40] <caribou> cjwatson: ok, will go for the easy way out
=== _salem is now known as salem_
[13:23] <smoser> @pilot in
[13:23] <smoser> @pilot-in
[13:23] <udevbot_> Error: "pilot-in" is not a valid command.
[13:23] <ev> pitti: apologies for the delay. I've fixed the problems pointed out in https://code.launchpad.net/~ev/apport/automatic-reporting/+merge/173553
[13:24] <smoser> udevbot_, doesn't want to pilot-in me.
[13:24] <udevbot_> Error: "doesn't" is not a valid command.
[13:25] <ogra_> your first command was ok ...
[13:25] <ogra_> not sure why it didnt pick it up
[13:26] <seb128> ogra_, smoser: should the bot be op to be able to change the topic?
[13:26] <ogra_> seems infinity had issues with it too (when signing off from it)
[13:26] <seb128> dholbach, ^ do you know?
[13:26] <ogra_> oh, since when is the topic not changeable anymore
[13:27] <ogra_> thats crap
[13:27] <pitti> ev: splendid, thanks! I responded with two final nitpicks
[13:27] <infinity> Probably since services exploded yesterday.
[13:27] <infinity> Could use a channel op to fix it.
[13:27] <geser> so you are the pilot till it gets fixed? :)
[13:27] <infinity> geser: Apparently. :P
[13:27] <ev> pitti: will fix and merge! Thanks!
[13:28] <ev> exciting!
[13:28] <infinity> @pilot out
=== udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[13:28] <infinity> cjwatson: Thanks.
[13:28] <cjwatson> np
[13:29] <cjwatson> Though udevbot was supposed to have +t anyway.
[13:29] <ev> We're getting quite close with the mobile crash reporting stuff. If only I could get system-settings (QML) to not produce a solid black window since upgrading virtualbox.
[13:29] <cjwatson> I bet it isn't identified.
[13:29] <seb128> no fun, I was looking forward having infinity being sponsor every day :p
[13:30] <smoser> @pilot in
=== udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smoser
=== kentb-out is now known as kentb
[13:47] <dholbach> seb128, :)
[13:47] <seb128> dholbach, unping ;-)
=== achiang` is now known as achiang
[14:08] <caribou> can someone explain the use of $QUILT_STAMPFN in debian/rules ?
[14:08] <caribou> or point to where  I can find info
[14:09] <infinity> caribou: See /usr/share/quilt/quilt.make
[14:10] <caribou> infinity: thanks
=== plars_ is now known as plars
[14:22] <shadeslayer> kenvandine: hi, I was wondering why each of the account-plugin packages made from empathy ( the source ) depend on empathy ( the binary )
[14:23] <kenvandine> because they depend on a private lib empathy ships
[14:23] <kenvandine> empathy upstream maintains that
[14:23] <kenvandine> it is far from ideal
=== TerminX_ is now known as TerminX
[14:31] <slangasek> seb128: configglue revert> sure thing - did that fix all the problems you were seeing?
[14:33] <seb128> slangasek, yes, u1 works correctly again (file syncing, sharing, control panel, indicator)
[14:47] <dholbach> barry, are you planning to upload some of the downloader changes to saucy soon?
[14:48] <barry> dholbach: do you mean the new download service, or the client updater?
[14:48] <dholbach> barry, I think the former
[14:49] <barry> dholbach: check with mandel; he was working on a packaging branch
=== shirgall_ is now known as shirgall
[14:55] <caribou> if I touch configure.ac & configure from upstream tarball, what do I need to do to have them appear as pristine ?
[14:55] <dholbach> barry, I was just wondering if it'd make sense to get it on the images soon, so stuff can start using it, even if it's not 100% there yet
[14:56] <caribou> right now, I must touch aclocal.m4 & Makefile.in to have it build
[14:56] <caribou> so I suppose that there is a cleaner way of doing this
[14:56] <barry> dholbach: yes, i think it is worth doing, even though the upgrader client doesn't use it yet.  i'm not sure whether the click infrastructure uses it yet, but my guess is no
[14:57] <barry> dholbach: i don't see mandel online atm
[14:57] <infinity> caribou: Is patching configure alone not enough?  Given that the package already does this, it would seem like it would be.
[14:58] <caribou> infinity: just wanted to follow previous advices & touch them both. I guess it's useless given the current nature of the package
[14:58] <caribou> infinity: I would still be curious to know how it's done
[14:59] <infinity> caribou: Yeah, your path of least resistance here is just to do what the maintainer's already done, as wrong as it is.  Half-assing an in between solution isn't worth the effort.
[14:59] <caribou> infinity: well other than dh-autoreconf which *is* the proper way
[14:59] <caribou> infinity: true
[15:00] <caribou> infinity: but is there a way to do that, if it was the correct way ?
[15:01] <caribou> infinity: I was a bit surprized as I tried your patch of  yesterday and got the same result. Maybe I'm using quilt the wrong way
[15:01] <infinity> caribou: There are ways to touch all the right files in the right order to fool it, but it's not worth the effort.  The autotools-dev README used to have an in-depth explanation that they've now replaced with "use dh_autoreconf".
[15:01] <infinity> caribou: My patch will still trip maintainer mode.  If you drop the change to configure.ac, it should be fine.
[15:02] <caribou> infinity: ok. what's maintainer mode btw ?
[15:03] <infinity> caribou: It's autotools' way of saying "I'm the upstream maintainer of this project, and when I change files, I want you to regenerate everything".
[15:03] <caribou> infinity: ah; ok
[15:03] <infinity> caribou: Generally meant to be turned off in make dist when generating a tarball for distribution, but not everyone does.
=== mbarnett` is now known as mbarnett
[15:17] <cjwatson> caribou: Having to touch individual files is only a problem if you aren't using autoreconf.
[15:17] <cjwatson> caribou: But we've already established that you can't do that here, sadly.
[15:18] <cjwatson> There isn't a correct way to do it because you're in incorrect land.
[15:18] <caribou> cjwatson: indeed. I'll follow infinity's advice & only touch configure
=== kirkland` is now known as kirkland
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
[16:07] <Laney> zul: your recent python-coverage upload took away /usr/bin/python-coverage
[16:09] <zul> Laney:  crap ill fix it
[16:09] <Laney> zul: also I think you installed a load of python3 files into python-coverage by mistake
[16:09] <Laney> e.g. try to install both packages at the same time
[16:10] <zul> Laney:  k
[16:47] <doko> infinity, where are you?
[16:48] <infinity> doko: Upstairs, where the wired internet doesn't suck. :P
[16:48] <infinity> doko: What's up?
[17:25] <pindonga> hi barry dobey
[17:25] <pindonga> just wanted to let you know I've updated the configglue mp
[17:25] <pindonga> after your reviews
[17:29] <doko> xnox, could you merge lvm2 again, or update the config.* for arm64?
[17:29] <doko> dannf`, ^^^
[17:29] <doko> away in a few minutes
[17:30] <dobey> pindonga: hi. i saw. thanks
[17:31] <pindonga> dobey, ty
[17:36] <doko> https://launchpad.net/ubuntu/+source/apr/1.4.8-1ubuntu1
[17:54] <ahasenack> hi, I don't know if somebody can help with a silly issue with an upstart job
[17:54] <ahasenack> I can't get "console output" to actually allow my job to print out anything
[17:55] <ahasenack> lemme pastebin
[17:55] <ahasenack> http://pastebin.ubuntu.com/5865682/
[17:55] <ahasenack> what am I missing?
[17:56] <ahasenack> the real job is something else. It's failing to start and printing the reason to stderr, but I don't see it when I start it, and I'm debugging why
[17:56] <ahasenack> this on precise, upstart 1.5
[17:57] <smoser> console output is /dev/console
[17:57] <smoser> ahasenack,
[17:57] <smoser> i thikn you rpbably want 'console owner'
[17:57] <ahasenack> so, physical screen
[17:58] <ahasenack> console owner didn't change a thing
[17:58] <smoser> well, /dev/console. (that could be ttyS0 or a vga device, which might have gotten re-tied up to console-9 or something)
[17:59] <smoser> oh.
[17:59] <ahasenack> and exit status is 0
[17:59] <smoser> well hten i'm not sure.
[17:59] <smoser> if you just want to see the output
[17:59] <smoser> then upstart stores that for you in /var/log/upstart
[18:00] <ahasenack> yeah, with console log
[18:00] <ahasenack> not the other options
[18:01] <ahasenack> I get exit status 1 if I add "task" to the config
[18:01] <ahasenack> since this isn't a daemon
[18:03] <smoser> well that makes sense.
[18:03] <smoser> i swear that console owner used to do whtat you want.
[18:03] <smoser> but i dont know.
[18:03] <smoser> and the documentation disagrees with my memory
[18:05] <ahasenack> even the 6.4.3.1 example doesn't work 100% like it says there, I get the msg in /var/log/syslog, but nothing in my "console" (ssh)
[18:09] <ahasenack> slangasek: hi, around? Do you know what's missing to get the "echo" output in my terminal in this paste? http://pastebin.ubuntu.com/5865727/
[18:26] <dobey> it *is* ok to have a package which is in universe, listed in the Depends section of debian/tests/control for a package that is in main, right?
[18:31] <slangasek> ahasenack: the output never goes to the terminal; 'console output' goes to /dev/console
[18:32] <ahasenack> slangasek: is there a way for it to go to the terminal?
[18:32] <slangasek> ahasenack: no
[18:32] <slangasek> ahasenack: unless you want to wrap things to dump /var/log/upstart/$job
[18:32] <ahasenack> slangasek: so if I'm deploying something remotely, I can't see the errors I would if this were a normal sysv initscript? Like
[18:32] <ahasenack> ssh server service foo restart
[18:33] <ahasenack> I will have to check that /var/log/upstart/$job file and use "console log"?
[18:34] <smoser> console log is the deafult.
[18:35] <smoser> when i'm debugging i often wrap any scripts in
[18:35] <smoser> { } >/tmp/my.log 2>&1
[18:36] <ahasenack> well, it's not debugging, the service is reporting why it doesn't start, but it's lost
[18:36] <ahasenack> the caller has to check another log file to try to find out, and even make sure the lines in that log file are recent
[18:37] <ahasenack> meh
[18:37] <smoser> yeah.
[18:37] <ahasenack> all because go doesn't work
[18:37] <ahasenack> fork
[18:37] <ahasenack> not work
[18:37] <ahasenack> so I was switching to upstart, so I wouldn't have to use start-stop-daemon's -b (background), where I can't check if the service startup worked or not
[18:53] <slangasek> ahasenack: right - so arguably, this is a feature enhancement we should consider for the 'service' command, to have it tail the log file for the job
[18:55] <ahasenack> slangasek: is the upstart log for the job overwritten in each invocation?
[18:55] <slangasek> ahasenack: no, it's appended
[18:55] <ahasenack> ok, so it's not just tail the last line, there could be old stuff in there
[18:59] <slangasek> yeah; you'd want service to do something like: if [ -e /var/log/upstart/$job.log ]; then tail -n 0 -f /var/log/upstart/ssh.log &; tail_pid=$!; fi; start $job; if [ -n "$tail_pid" ]; then kill $tail_pid; else cat /var/log/upstart/$job.log; fi
[18:59] <dobey> slangasek: can you answer my question? just want to clarify that autopkgtests for packages in main can depend on packages in universe, before i dput it :)
[19:00] <slangasek> dobey: I don't know of any reason they couldn't
[19:00] <slangasek> jibel: ^^ can you confirm that autopkgtests can use deps from universe?
[19:02] <dobey> right, i just wanted to confirm the restrictions weren't the same as build-depends for the package itself not being able to use packages from universe
[19:02] <Laney> It's fine - I've done it with glib's autopkgtests
[19:02] <Laney> I didn't even think of that to be honest ...
[19:02] <dobey> ok
[19:02] <dobey> great
[19:03] <Laney> Tell me this is a fixed software-center :-)
[19:04] <dobey> no, this is me adding autopkgtest support to ubuntuone-client :)
[19:04] <jbicha> dobey: speaking of software-center could you take another look at bug 1163886 some time?
[19:04] <ubottu> bug 1163886 in software-center (Ubuntu) "software-center crashed with signal 5 with WebKit 2.0+" [High,Confirmed] https://launchpad.net/bugs/1163886
[19:05] <dobey> jbicha: is that the weird badmatch thing?
[19:05] <jbicha> yeah, baddrawable
[19:05] <dobey> no this is different, not the gtk+ thing
[19:06] <dobey> yay javascript. thank you for suddenly making my pgup/pgdn keys not work on this page :(
[19:07] <dobey> or maybe just a weird keynav bug in firefox :-/
[19:08] <dobey> jbicha: actually, i have not seen the gtk+ one at all on saucy, even though it already has gtk+ 3.8
[19:08] <jibel> dobey, I confirm there is no such restriction
[19:09] <dobey> jibel: cool, thanks
[19:09] <dobey> jbicha: what is the ppa url for the gnome3 ppa?
[19:12] <jbicha> ppa:gnome3-team/gnome3
[19:22] <dobey> the atmostone() issue in adt-run, yes
[19:22] <dobey> aka TestDirectory: not working at all
[19:23] <jibel> right, I fixed it when you discovered it, and pitti merged it yesterday
[19:23] <jibel> you're the first using this directive since it exists apparently :)
[19:25] <smoser> @pilot out
=== udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[19:26] <dobey> jibel: ah, great. yeah, kind of disappointing the test runner doesn't have tests, though :)
[19:26] <dobey> (among other things. that code is somewhat disturbing)
[19:28] <dobey> now gotta fix ubuntu-meta
=== Cimi_ is now known as Cimi
=== LordOfTime is now known as TheLordOfTime
=== udevbot_ is now known as udevbot
=== popey_ is now known as popey
=== holmes.freenode.net changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smoser
[19:42] <xnox> doko: dannf`:  "xnox, could you merge lvm2 again, or update the config.* for arm64?" lvm2 2.02.98-1ubuntu2 (Accepted)
=== mfisch` is now known as mfisch
[19:42] <dobey> wow, networking is really poor inside virtualbox (or maybe it's saucy, haven't tried other versions lately)
=== masACC is now known as maswan
=== BenC- is now known as BenC
=== LordOfTime is now known as LordOfTime|EC2
[20:56] <xnox> dobey_: ev had all sorts of interesting troubles with virtualbox lately =)
=== dobey_ is now known as dobey
[21:06] <dobey> xnox: on raring host?
[21:07] <xnox> dobey: on mac os x host
[21:09] <dobey> xnox: i'm on raring host, so nothing there has changed really. lots have changed in saucy though. so not sure if it's just stuff broken in saucy when running in vbox, or what.
[21:50] <barry> slangasek: okay, so i have a new python-configglue 1.1.2 which un-reverts your change, updates to the new upstream, and removes the Build-Dep on python-configparser.  seems to work locally for me.  fingers crossed.
[21:50] <slangasek> barry: tested with ubuntuone-syncdaemon? :)
[21:51] <barry> slangasek: i installed it on a vm, rebooted, and u1 file sync still seems happy
[21:51] <slangasek> cool
[21:51] <slangasek> +1
[21:52] <barry> slangasek: hopefully you won't have to revert my unrevert of your revert again tonight after my eod :)
[21:52] <slangasek> hah
[21:52] <slangasek> fortunately the fix is a new upstream version, so the ugly version number goes away :)
[21:53] <barry> yep :)
[21:53] <stokachu> bazaar.launchpad.net down for anyone else?
[21:54] <sarnold> stokachu: I was redirected to https://launchpad.net/
[21:54] <stokachu> hmm what about this link https://bazaar.launchpad.net/~charmers/charms/precise/python-moinmoin/trunk/view/head:/hooks/install
[21:54] <sarnold> stokachu: .. and bzr up in a tree ran without issue
[21:54] <sarnold> stokachu: 503
[21:55] <stokachu> ok i need to check if anyone's reported it yet
[21:57] <sarnold> stokachu: thanks, under investigation now :)
[21:57] <stokachu> sarnold: ah oops i just posted in #launchpad so dis-regard that one :D
=== cmagina is now known as cmagina-away
=== kentb is now known as kentb-out
[22:52] <dobey> Laney: am sure you're gone now, but there's an issue with the branch import of software-center in saucy, which i've pinged wgrant about already so hopefully he'll fix it. i'll get a new software-center uploaded in the morning (hopefully without having to do it the old-school annoying way of apt-get source and modify things).
=== Ursinha is now known as Ursinha-afk
[23:51] <asac> 01:50 < asac> ouch ... i think it really happened... i lost core dev unnoticed once and for all (as i dont really have a reason get it back):)
[23:51] <asac> 01:50 < asac> i am not even an ubuntu member anymore
[23:51] <asac> 01:50 < asac> thats brutal :)
[23:52] <asac>  well... guess expiring without me noticing is reason enough to justify at least loosing dev :)