[02:55] <hallyn> stgraber: bug 1321854 (in shadow) patch looks good to me.  (you've done the recent uploads so i don't wanna step on toes...)
[05:03] <pitti> Good morning
[05:14] <infinity> stgraber: "int i1;"... Do they not have j where you come from?
[05:20] <pitti> *chuckle*
[06:00] <stgraber> infinity: that's odd, I see that code in there, but I have no recollection of writing it, i1 clearly isn't my coding style (but I'm pretty much the only one who ever touched that code, so I'm likely to blame...)
[06:13] <infinity> stgraber: Maybe someone snuck into your place in the middle of the night and changed all your variables?
[06:19] <dholbach> good morning
[06:20] <didrocks> hey dholbach!
[06:23] <dholbach> salut didrocks - comment ça va?
[06:23] <didrocks> dholbach: ça va bien, et toi ?
[06:25] <dholbach> très bien, merci :)
[07:37] <mpt> Whatever happened to the “trivial” bug tag?
[07:37] <mpt> Ah, it became “bitesize”
[08:35] <xnox> bah, my irc proxy lost the game
[08:35] <xnox> and doko is not here now =(
[08:37] <xnox> dholbach: "less funny qt4 apps" how funny are they? do they look like windows 95?
[08:40] <xnox> hallyn: the version symbol doesn't matter, but there are two new functions. Find out which upstream release they appeared in, and add it to symbols file with that version e.g. "2.4"
[08:41] <xnox> dholbach: when qt4 apps look that funny, it most likely means that unity-settings-daemon (or gnome-settings-daemon) are not operational.
[08:42] <xnox> mdeslaur: and in systemd unit file, one can declare what reload command does as a script...
[08:44] <Laney> guten tag xnox
[08:44] <Laney> it's certainly not a lack of *-s-d, you'd notice that way quicker
[08:45] <xnox> Laney: guten tag =) Ich kann nicht sechen wenn ich IRC verlassen habe.
[08:45] <seb128> xnox, welcome back!
[08:45] <ogra_> lol
[08:45]  * seb128 assumes you were off, I don't see I saw you active on IRC this week
[08:45] <Laney> haha
[08:45] <xnox> seb128: yeap.
[08:46] <xnox> but i had to restart the proxy this morning, thus working off irclogs.ubuntu.com
[08:46] <Laney> no logs?
[08:46] <xnox> i have some logs.... not all
[08:47] <seb128> well, just assume that if people need something they are going to ping you again
[08:47] <xnox> seb128: but i like reading about funny breakages over the past days =)
[08:48] <Laney> mumble's theme is indeed wrong
[08:48] <Laney> hrm
[08:49] <seb128> yeah, I noticed as well with virtualbox
[08:49] <Laney> how does that work?
[08:51] <seb128> not sure
[08:51] <seb128> shrug, https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.6+dfsg-1ubuntu1
[08:51] <seb128> 30M diff.gz, who wants to review it?
[08:59] <seb128> Laney, do you look at it? I start looking but I don't want us to dup work
[09:03] <Laney> seb128: was looking, yeah
[09:03] <Laney> Riddell: mitya57: do you know how qt4 gtk theming it supposed to work?
[09:04] <Laney> It's "Desktop Settings (Default)" in qtconfig-qt4, if I set it to "GTK+" then things look normal
[09:04] <Laney> so maybe it's not detecting right?
[09:05] <Riddell> maybe, it detects the window manager I think to work out what theme to use
[09:05] <seb128> Laney, https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/1305294
[09:05] <seb128> get the source, grep for GNOME_DESKTOP_SESSION_ID?
[09:05]  * seb128 is downloading, but it's taking a bit
[09:07] <Laney> seb128: indeed, that is correct
[09:08] <Laney> what was setting that before?
[09:12] <seb128> Laney, that is still set in utopic for me
[09:12] <Laney> not here
[09:13] <Laney> seems it's set by gnome-session
[09:13] <seb128> OH
[09:13] <seb128> it's set in /proc/pidof gnome-session/environ
[09:13] <seb128> not in compiz
[09:13] <Laney> hahaha
[09:14] <seb128> I bet it's the move to start compiz from an upstart job
[09:14] <seb128> xnox, !!!
[09:14] <Laney> yes
[09:15] <xnox> isn't GNOME_DESKTOP_SESSION_ID the deprecated one?
[09:15] <seb128> it is
[09:15] <xnox> or is that current?
[09:15] <Laney> it needs to be set
[09:15] <seb128> but see https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/1305294
[09:15] <Laney> to anything, for this qt detection
[09:15] <Laney> or we could change Qt ...
[09:15] <xnox> we had an upstart job that sets it to bogus value for Qt.
[09:15] <seb128> right
[09:15] <Laney> where?
[09:15] <Laney> I have no such job
[09:16] <xnox> in /usr/share/upstart/sessions/gnome-session.conf
[09:16] <seb128> well, that's only for gnome-session
[09:16] <seb128> compiz/unity doesn't get it set
[09:16] <xnox> right. hm
[09:16] <seb128> which means when you start apps from unity you get no theme
[09:16] <Laney> oh yes, the ordering is wrong
[09:16] <xnox> i thought we did do $ initctl set-env
[09:17] <seb128> what ordering?
[09:17] <seb128> dholbach, ^ btw, your theme issue is being discussed
[09:20] <Laney> it needs to be set-env but also unity can start before gnome-session I think
[09:26] <seb128> that issue is not really new
[09:26] <seb128> well it is for unity since it didn't have it when gnome-session was running compiz, rather than having an upstart job
[09:26] <seb128> bug the bug I listed just before describe a similar issue when using indicator-sound in trusty
[09:29] <xnox> Laney: seb128: should we just stick a GNOME id into e.g. /etc/X11/Xsession.d/ or whatever it is called?
[09:29] <Laney> could just put it in xsession-init.conf
[09:29] <xnox> but i guess, then we will set it too many times. Do we actually want that always set?
[09:30] <xnox> or e.g. it shouldn't be set on Kubuntu?
[09:30] <seb128> we don't want it see under non gnome-session sessions
[09:30] <Laney> [ "$SESSIONTYPE" = "gnome-session" ] && initctl ...
[09:31] <xnox> seb128: hm, and xubuntu/lunubuntu etc also want it, no? there is no gnome-session running but it does want gtk styling?
[09:31] <xnox> (well maybe not lxqt)
[09:31] <seb128> well, historically it was gnome-session setting it
[09:31] <Laney> it's set by gnome-session
[09:31] <Laney> so let's just keep that keying
[09:31] <seb128> so if we want to get back to that
[09:31] <seb128> it's only a qt4 thing anyway
[09:31] <seb128> qt5 doesn't have that issue
[09:34] <Laney> will upload it to xsession-init.conf
[09:34] <Laney> xnox: confirm/deny
[09:34] <xnox> Laney: i think that should be fine.
[09:34] <xnox> Laney: long term, I thought we wanted to patch qt4 to not care about that variable.
[09:35] <Laney> yeah I can't think of a better one off the top of my head
[09:36] <xnox> on my desktop url-dispatcher was held back, instead of removing upstart-app-launch & installing ubuntu-app-launch
[09:43] <dholbach> seb128, thanks - I'll have a look at the bug
[09:44] <Laney> xnox: grh, test failed in test build
[09:44] <Laney> "104 - ensure job gets given default environment"
[09:45] <Laney> and it's left a stray process
[09:45] <Laney> naughty
[09:49] <seb128> dholbach, well, the bug is not that informative, just take it as "it's being worked by some our best people, so no worry it's going to be resolved" ;-)
[09:52] <seb128> cjwatson, xnox: is anyone looking at the daily-live isos not having a boot menu since syslinux 6?
[09:52] <cjwatson> seb128: I've spent some time looking at it but not got very far yet
[09:53] <xnox> cjwatson: should broken cd be stashed and syslinux reverted to 4?
[09:53] <cjwatson> I can see that it gets into gfxboot-theme-ubuntu, since I can insert trace statements there and have them take effect
[09:53] <cjwatson> xnox: I think that would be very intrusive at this point
[09:53] <seb128> is there a workaround to start the install mode?
[09:53] <cjwatson> Now that I'm emerging from the livefs work I'll have another look at it today
[09:53] <seb128> you can hit enter and it boots in the live session
[09:53] <seb128> cjwatson, thanks
[09:54] <xnox> cjwatson: can maybe-ubuntu become the default boot option? cause at the moment the current default ends up as "nothing" e.g. boot into live session
[09:54] <xnox> cjwatson: i didn't manage to trace where "maybe-ubiquity" is set as the default.
[09:54] <xnox> (on most products)
[09:55] <Laney> grump
[09:55] <Laney> xnox: can you build upstart in sbuild atm?
[09:56] <xnox> Laney: typically yes, one must disable eatmydata & not build on top of overlayfs.
[09:56] <xnox> Laney: just commit things to lp:ubuntu/upstart and I can pull / upload.
[09:56] <Laney> oh okay, the latter could be me
[09:57] <xnox> hence i have e.g. utopic-plain-amd64 schroot config that disables overlayfs & eatmydata.
[09:59] <shadeslayer> I don't suppose there's a way to pull all the latest build logs for a package?
[09:59] <cjwatson> xnox: no, would rather not attempt workarounds, shouldn't be too hard to fix
[09:59] <cjwatson> shadeslayer: easy enough with launchpadlib
[09:59] <shadeslayer> right, so nothing pre written then :)
[09:59] <cjwatson> there's a build_log_url attribute on builds
[09:59] <cjwatson> don't know of one
[10:00] <shadeslayer> ok, I shall write one
[10:08] <dholbach> seb128, I like the sound of "it's being worked by some our best people, so no worry it's going to be resolved" a lot
[10:08] <seb128> dholbach, ;-)
[10:08] <Laney> I gave up building locally and uploaded to a PPA
[10:08] <xnox> Laney: builds fine here.
[10:08] <xnox> Laney: virt PPA may fail, due to old kernel.
[10:08]  * Laney unleet powers
[10:09] <xnox> ion: Built successfully
[10:09] <xnox> Laney: push to lp:ubuntu/upstart, and I'll test build & upload.
[10:09] <Laney> what is ion?
[10:10] <xnox> Laney: it's "I: built successfully" with color-code from sbuild, copy&paste artifact
[10:10] <Laney> I see
[10:12] <Laney> xnox: okay, pushed
[10:13] <infinity> xnox: By "color-code" you mean "it contained a tab". ;)
[10:13] <infinity> Or, not even.
[10:14] <infinity> "i: foo" in many clients will auto-expand "i:" as if you tab-completed.
[10:14] <xnox> infinity: "i believe what i see" =))) i've copied green text, hence I called it color coded =))))
[10:14] <infinity> xnox: Yeah, I think it was just auto-expansion messing with you.
[10:14] <infinity> (Since ion is in this channel and all)
[10:14] <xnox> infinity: right, silly xchat =)
[10:15] <xnox> shouldn't mangle pastes
[10:16] <GunnarHj> pitti: ping?
[10:21] <dholbach> elopio, happy birthday! :)
[10:21] <Laney> xnox: did actually build in $ppa ;-)
[10:34] <Laney> xnox: uploading myself then
[10:39] <seb128> Laney, is that something we should SRU as well?
[10:39] <Laney> Could do I guess
[10:39] <seb128> Laney, oh, and seems like xnox already uploaded
[10:39] <Laney> oh
[10:39] <Laney> that little terror
[10:40] <Laney> he took the Changed-By :P
[10:40] <Laney> anyway if they're preparing an upstart SRU then I suppose it could go in there
[10:40] <seb128> right
[10:40] <seb128> xnox, can you make that happen?
[10:41] <Laney> jodh: got a trusty upstart sru in the works?
[10:47] <xnox> Laney: i have a few things that need cherry-picking into trusty. enough by now to make an SRU release.
[10:47] <xnox> Laney: does this actually affect trusty as well? didn't think compiz was spawned as upstart job back then.
[10:48] <Laney> it affects the indicators there
[10:48] <Laney> see the bug report, that's from a trusty user
[10:49] <xnox> aha.
[10:49] <xnox> yeap, i remember that.
[10:49] <Laney> but same root cause
[10:49] <Laney> environment not set early enough
[10:49] <xnox> (vlc staring looking odd)
[10:56] <xnox> Laney: "[10:56]  * xnox skipped that in the review, but now noticed it when cherry-picking into trusty
[10:56] <Laney> didn't do that on purpose
[10:56] <xnox> ack.
[11:18] <xnox> Laney: for trusty, do we also want adding "unity8-x11" & "unity8-mir" to upstart-xsessions?
[11:18] <xnox> Laney: no bug reference in the utopic upload.
[11:20] <Laney> xnox: hrm, don't think that's worth it
[11:20] <Laney> I think the trusty unity8 sessions are what they are
[11:21] <xnox> Laney: well, pretty crappy without upstart, no?!
[11:25] <Laney> xnox: It ran some script to start unity8 manually
[11:25] <Laney> so it did work
[11:26] <Laney> I don't know if other jobs will require modification too
[11:31] <xnox> right, and I don't want to be testing that. alright.
[11:31] <Laney> xnox: you know the executable bit isn't preserved in the source package?
[11:31] <xnox> Laney: correct, because of source 1.0 format.
[11:31] <Laney> jus' sayin'
[11:31] <Laney> :-)
[11:31] <xnox> Laney: we typically use $ bzr bd -S, to build the source package.
[11:31] <xnox> Laney: you are the first one to touch it "differently" =)
[11:32] <Laney> it's because I modified it in a source package then cp-ed it back in
[11:32] <xnox> ah, even more obscure.
[11:32] <xnox> #1317727, #1305294, #1174272 enough for an SRU
[11:40] <xnox> Laney: can you add tescase/impact/description/etc SRU bits to bug #1305294? Or should i?
[11:41] <pitti> hey GunnarHj
[11:41] <GunnarHj> pitti: Hi Martin!
[11:42] <GunnarHj> pitti: Since you didn't respond instantly, I just sent a mail to you and dpm_.
[11:42] <pitti> GunnarHj: ah, good
[11:43] <seb128> hey pitti, wie gehts?
[11:44] <Laney> xnox: there we go
[11:45] <xnox> ta
[11:46] <pitti> hey seb128; gut, danke! et toi ?
[11:46] <seb128> pitti, je vais bien, merci !
[11:56] <dpm_> thanks GunnarHj for the e-mail, I'll try to reply with my thoughts asap
[11:56] <GunnarHj> dpm_: Ok, great!
[12:18] <tkamppeter> OdyX, I have fixed Debian bug 752146 in the GIT of cups-filters. Can you upload it to Debian, so that it syncs in Ubuntu? Thanks.
[13:11] <xnox> cjwatson: i have a "fix" for isolinux =)
[13:12] <xnox> cjwatson: our bootlogo cpio archive only has init, without all other files.
[13:12] <xnox> if all other files are included inside it, then all is fine
[13:12] <xnox>  sudo cpio -ivd < bootlogo
[13:13] <xnox> ls init *.tr *.hlp *.pcx back.jpg gfxboot.cfg langlist | cat | cpio -o > bootlogo
[13:13] <xnox> it appears that file access outside of the bootlogo archive is no longer operational and there is upstream discussion about it
[13:14] <xnox> http://www.syslinux.org/archives/2013-July/020398.html
[13:19] <xnox> not sure where repacking of "bootlogo" file should happen.
[14:06] <cjwatson> xnox: ah, that's a hassle
[14:06] <cjwatson> xnox: thanks for tracking that down, I should be able to sort it out in debian-cd or something
[14:09] <xnox> cjwatson: right, i'm working out on which files to include, cause one also needs *.fnt and maybe others.
[14:10] <xnox> cjwatson: but not just $ ls -1 * | cpio -o > bootlogo, cause then one gets options one shouldn't see. E.g. "back..." -> which does nothing / crashes the installer
[14:10] <cjwatson> Well, that I can probably work out by grepping gfxboot-theme-ubuntu code
[14:10] <xnox> cjwatson: and "Help" button, which i've never seen before, like ever. It has explanation text about each of the Fn keys etc.
[14:10] <cjwatson> Fairly limited number of operators that open files
[14:11] <cjwatson> Yes, I know about all of this :)
[14:11] <xnox> =)))) ok
[14:11] <xnox> cjwatson: i rest my case, and handing over to you =)
[14:11] <cjwatson> This is pretty problematic because a lot of this stuff we're relying on not having to duplicate in and out of the bootlogo archive.
[14:12] <cjwatson> I'll look at it but it's at least somewhat tempting to patch those functions back in.  Will have to have a design think.
[14:13] <cjwatson> I'm particularly concerned about having to have things like gfxboot.cfg duplicated inside and out.  It will confuse the hell out of anyone trying to customise the image.
[14:14] <xnox> yeah, it is ugly.
[14:14] <cjwatson> And the assertion about GRUB in that mailing list post is just bizarre.  GRUB needs no such thing, it has all the filesystem handling code you might ever want.
[14:14] <xnox> the mailing list thread ended with "anyone please step up and tell us if you need this functionality" shame it only took us a few years to spot the problem.
[14:15] <cjwatson> Is that mailing list available in mbox form somewhere so I can reply to that usefully?
[14:15] <xnox> cjwatson: what are our chances to switching to pure grub2? does it have any gfxboot prettiness we can leverage on par with current theme?
[14:15] <cjwatson> I tried a while back but ran out of time
[14:15] <cjwatson> I'd prefer that ultimately, but it will take a while
[14:16] <cjwatson> Oh yikes, it's the whole COMBOOT API?
[14:16] <cjwatson> Argh
[14:18]  * cjwatson finds the mbox archives
[14:24] <xnox> wgrant: please join #ubuntu+1-maint for idling & mentoring folks =)
[14:25] <bdmurray> seb128: https://errors.ubuntu.com/oops/b0a749da-f7d3-11e3-b432-fa163e707a72
[14:25] <bdmurray> seb128: that now has a link to the bucket / problem in it
[14:26] <bdmurray> seb128: although the retrace failed
[14:27] <bdmurray> seb128: http://pastebin.ubuntu.com/7674870/ <- missing debug symbol packages
[14:28] <xnox> cjwatson: it's milestone week for flavours next week, and we'll need working images. hence tracking the above regression down =)
[14:29] <seb128> bdmurray, thanks
[14:30] <hallyn> netcf - fix symbols
[14:30] <hallyn> ask for sync of netcf from experimental
[14:30] <seb128> bdmurray, weird, those packages are not in the bt I think, they shouldn't fail the retrace
[14:30] <hallyn> huh
[14:30] <hallyn> my insert key is ging mad
[14:31] <cjwatson> xnox: Yeah, thanks for the effort.  I'll get a workaround in place before I leave this evening, if at all possible
[14:33] <bdmurray> seb128: iirc apport also does a look of stuff in procmaps and install those packages too
[14:34] <seb128> bdmurray, k, I'm unsure why that failed, I'm going to try to submit it again to see
[15:02] <cjwatson> xnox: Right, that's hopefully sorted; with any luck I'll even have time to test that end-to-end before I leave, although I'm racing against the clock
[15:03] <cjwatson> I think there's one remaining bug, namely that the "Other Options" menu will have changed contents for live images, I think
[15:03] <cjwatson> But that isn't fatal and I can sort it out next week
[15:07] <xnox> yeah, not fatal at all, given that one can specify those by typing anyway.
[15:07] <xnox> (well those that are listed there in e.g. trusty images)
[15:08] <cjwatson> The rest seems to work again in my hacky test harness thing
[15:14] <desrt> hi.  is there a recommended board config (qemu switch -M) to use for an arm machine that's SMP capable and supported by the kernel (ie: no abort due to unsupported board on startup)?
[15:15] <cjwatson> xnox: Thanks again for tracking that down.  Would've taken me ages
[15:16] <xnox> np
[15:30] <manjo> Riddell, there is a fix in upstream debian for the k3b build break in utopic https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739312#51 can you please merge that change ?
[15:30] <Riddell> manjo: yeah I'll take a look when I can (may be monday, hope not)
[15:31] <manjo> Riddell, would you like me to open a bug with info and assign to you ?
[15:32] <Riddell> manjo: sure
[15:37] <manjo> Riddell, https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/1332591
[15:38] <Riddell> thanks manjo
[15:38] <jamespage> stgraber, whats your opinion on bug 1068756 ?
[15:39] <jamespage> stgraber, IMHO this creates alot of complexity if not disabled on server
[15:49] <cjwatson> xnox: OK, it's kind of wonky but we at least get something on server now
[15:49] <cjwatson> kicking a desktop respin, won't be around to watch it finish
[15:49] <cjwatson> I'll have another look on Sunday/Monday and see what remains
[15:56] <manjo> Logan_, there is an upstream fix for kradio4 build failure https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748147#12 can you please sync or merge that change ?
[16:09] <stgraber> jamespage: right, we had a chat about that during vUDS I think (or something), thing is, privacy extensions do make sense on some kind of servers and clearly don't on other (say a mail server) and it's hard to have it set to the right value everywhere...
[16:10] <jamespage> stgraber, it becomes complex in environments with firewalls with egress filtering
[16:10] <stgraber> jamespage: but I think I agree that for cloud instances and default server install, we probably want privacy extensions off. Making sure that we however don't change the behavior for people upgrading.
[16:10] <jamespage> stgraber, +1 on that approach
[16:11] <stgraber> jamespage: personally I have it disabled on all my servers (specifically for the egress firewalling bit) and on for all desktops and test systems, though representing that through packaging may be tricky (because the definition of server and desktop itself is pretty lburry)
[16:39] <catbus1> Hi, anyone know the difference between the server images downloaded on http://www.ubuntu.com/download/server/ and http://www.ubuntu.com/download/cloud?
[16:42] <hallyn> xnox: hey, so i'm trying to make sense of libnetcf1.symbols.  each new version of libnetcf1 puts ncf_{get,put}_aug in private symbols (using src/netcf.syms) for the very latest version.  Am I right in assuming that's a problem upstream?
[16:45] <xnox> reading
[16:46] <jamespage> stgraber, where does it get configured from?
[16:46] <stgraber> jamespage: procps
[16:46] <hallyn> xnox: eh, well they are private symbols so i guess it doesn't matter
[16:47] <xnox> hallyn: well. yes and no.
[16:47] <stgraber> jamespage: /etc/sysctl.d/10-ipv6-privacy.conf
[16:47] <xnox> hallyn: it's marked private & thus can change, but it is public since it's exported and I can link against it.
[16:48] <xnox> hallyn: thus the same method should be employed as for e.g. eglibc private symbols. Strict version control on (>= 0.2.4 & << 0.2.5~)
[16:48] <hallyn> so they're doing the right thing
[16:49] <xnox> hallyn: since you want to force rebuilds, upon new upstream release.
[16:49] <xnox> hallyn: yeap, such that things that used NETCF_PRIVATE (0.2.3) symbol will have to be rebuild with (0.2.4), and 0.2.5, and etc.
[16:50] <hallyn> cool.  should have a debdiff soon adding symbols to libnetcf1.symbols
[16:50] <hallyn> hm, sitll have one error (though pkg finished building)
[16:51] <hallyn> i guess it doesn't like empty sections
[16:52] <xnox> hallyn: checkout e.g. /var/lib/dpkg/info/libc6:amd64.symbols, it has example of how to version control private symbols at the very top.
[16:53] <xnox> well actually multiple examples.
[16:53] <hallyn> xnox: oh ok - i'd looked at eglibc but it seemed to have nothing
[16:54] <xnox> hallyn: source package has build machinery to gererate common arch & OS specific patches and then generate symbols files based on that.
[16:54] <peba> https://launchpad.net/ubuntu/trusty/armhf       #should this link work ? currently I get just timeout error ?
[16:54] <xnox> hallyn: thus it's best to look at the resultant contents generated in the binaries themself.
[16:54] <hallyn> xnox: what I have so far is:  http://paste.ubuntu.com/7675612/
[16:55] <xnox> no, that's not quite what you want.
[16:55] <hallyn> feh
[16:58] <xnox> the whole symbols file looks odd, as debian revvision shouldn't be present.
[16:58] <xnox> (symver)NETCF_PRIVATE_0.2.4 1:0.2.4
[16:58] <xnox> is one thing you want
[16:59] <xnox> and then you want to define alternative dependency template & ask to use that for private symbols.
[17:02] <xnox> hallyn: i think that's more correct http://paste.ubuntu.com/7675655/
[17:03] <xnox> hallyn: not tested, just going off libc6 example and $ man deb-symbols which explains the grammar of the symbols file
[17:04] <xnox> at the moment, anything that uses NETCF_PRIVATE_0.2.3 symbol ends up with a dependency "libnetcf1 (>= 1:0.2.3)" but should end up with an upper restriction as well.
[17:05] <xnox> due to private, yet exposed symbol, thus infact public.
[17:05] <hallyn> xnox: so what, the package's symbosl file will be autogenerated by merging that file with src/netcf.syms?
[17:06] <xnox> hallyn: huh, no. src/netcf.syms is used to generate the symbols file of the library. debian/libnetcf1.symbols is used by dpkg-gensymbols & etc tools to correlate that you as a maintainer have assigned desired dependencies for a given symbol usage.
[17:07] <hallyn> hm, how come https://wiki.debian.org/UsingSymbolsFiles doesn't point ot deb-symbols((5)? thanks )
[17:07] <xnox> expanded debian/libnetcf1.symbols is stored inside the deb of libnetcf1.deb and on disk at /var/lib/dpkg/info/*.symbols
[17:08] <xnox> and when other things link against libenetcf1, symbols are cross-checked to generate substitues in the ${shlibs:Depends}
[17:09] <xnox> previously people had to write out ${shlibs:Depends} by hand =) now, only library maintainer has to do it once, and everyone gets correct deps.
[17:12] <xnox> hallyn: i think that debdiff is correct, but do check that by e.g. building a dummy package which uses ncf_put_aug symbol
[17:12] <xnox> hallyn: it's shlib:Depends should end up with >> 0.2.4 << 0.2.5
[17:13] <dobey> how do i get the requisite upstart processes running on the user's session bus, without starting a whole new X session? just dbus and upstart only?
[17:13] <xnox> hallyn: and other packages just >> 1:0.2.2
[17:14] <xnox> dobey: i'm not sure what you mean, you can trivially join existing upstart session. All you need is the matching UPSTART_SESSION variable which are a in /run/user/$UID/upstart/sessions/
[17:14] <dobey> xnox: i don't have an existing upstart session
[17:15] <dobey> xnox: i'm trying to test some stuff in an lxc and it requires upstart
[17:15] <xnox> dobey: oh, i see. You can start a new user upstart session by spawning $ init --user
[17:15] <xnox> dobey: it does need e.g. XDG_RUNTIME_DIR and HOME set.
[17:15] <dobey> won't init --user try to start x and everything?
[17:15] <dobey> and probably cause horrible problems inside an lxc?
[17:16] <xnox> dobey: that will emit startup event and start everything that keys on it in /usr/share/upstart/sessions, which doesn't start X, display manager starts it for us.
[17:16] <dobey> because with lxc, the $HOME from my host is bind mounted inside the lxc as the home
[17:16] <xnox> dobey: you can choose to pass --no-startup-event
[17:16] <xnox> dobey: then nothing will be running, unless you manually do $ start job-name
[17:17] <xnox> dobey: i'm talking about environment variable. so you can do e.g. HOME=$(mktemp -d) XDG_RUNTIME_DIR=$(mktemp -d) init --user --no-startup (that should work)
[17:18] <xnox> dobey: can you explain what you are trying to test, and why you need a new upstart user session?
[17:19] <xnox> dobey: and minimal lxc container has no user session jobs installed, thus actually in a typical lxc container spawning a new user session will do nothing.
[17:19] <dobey> xnox: i'm trying to test pay-service and i need an upstart user session because it starts the ui via ubuntu-app-launch
[17:20] <xnox> dobey: won't you need a bit more than just upstart user session to start ui? you will need X or Mir as well, no?
[17:21] <xnox> dobey: i'm not quite sure how testable UIs are started via ubuntu-app-launch, since they will be contained.
[17:21] <dobey> bug i keep getting errors like error getting unix process id for org.freedesktop.DBus: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get PID of name 'org.freedesktop.DBus': no such name
[17:21] <xnox> dobey: look into autopilot code, it has code to start apps via ubuntu-app-launch I belive.
[17:22] <xnox> dobey: well, you need dbus started as well. so do $ start dbus
[17:22] <dobey> xnox: i have X bound to my host X
[17:22] <dobey> dbus is running
[17:22] <xnox> check your environment.
[17:22] <xnox> you may have inherited to much of environment variables from your host.
[17:22] <xnox> dobey: how did you enter the lxc container?
[17:23] <xnox> what's your $ env
[17:23] <xnox> before starting anything?
[17:23] <dobey> ** (process:29958): WARNING **: Unable to find job 'application-click': GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name com.ubuntu.Upstart was not provided by any .service files
[17:23] <xnox> you don't want to be doing lxc-attach --keep-env
[17:23] <dobey> anyway
[17:23] <dobey> entered lxc via ssh
[17:24] <dobey> com.ubuntu.Upstart is not on the session bus, which is my current problem
[17:24] <xnox> dobey: how did you start session dbus? (note not the system one)
[17:24] <xnox> let me do a quick script to make it clear
[17:25] <xnox> cause after spawning session dbus, session upstart should join it.
[17:25] <smoser> can i get an archive admin to NAK cloud-init in
[17:25] <smoser>  https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=cloud-init
[17:25] <xnox> dobey: via initctl notify-dbus-address "$DBUS_SESSION_BUS_ADDRESS" in the post-start of the session dbus
[17:25] <smoser> i'm wnting to re-upload with fix for bug 1325746
[17:26] <dobey> xnox: i killed everything and "start dbus"
[17:27] <xnox> dobey: that will start system dbus in the lxc container, unless you sourced and set UPSTART_SESSION environmental variable to operate agains the session init you spawned in the lxc container.
[17:27] <xnox> cause you need a session dbus to be started via session upstart
[17:28] <dobey> xnox: i didn't run it as sudo, so it would be impossible for it to start a system bus without being root
[17:28] <dobey> but it started a session bus
[17:28]  * dobey kills everything
[17:29] <dobey> xnox: do i need to init --user -- zsh or something?
[17:30] <xnox> dobey: well $ init --user &
[17:30] <xnox> dobey: that will give you pid of session init.
[17:30] <xnox> dobey: next you need to fine the session file in the XDG_RUNTIME_DIR of the session init. which will have something liek UPSTART_SESSION=unix:abstract=/com/ubuntu/upstart-session/1000/18004 in it
[17:30] <dobey> whee, that sucked. did pkill -9 ssh in the lxc and it killed my host X
[17:30] <xnox> then you need that variable in your environment.
[17:31] <hallyn> xnox: (of course that debdiff should use 1:0.2.4-2 rather than 1:0.2.4-1ubuntu1 :)  building a test.  i've read through a few more readings on the symbosl stuff and it still doesn't maek sense to me, but
[17:31] <xnox> once you have that variable in your environment, you will be operating against session init by default.
[17:31] <hallyn> oh, now i see
[17:31] <dobey> hmm
[17:31] <hallyn> so the debian/libnetcf1.symbosl file lists all the symbol versions which are in this library
[17:31] <dobey> life was so much simpler when all you had to do was `eval something`
[17:31] <xnox> then $ start dbus, or to be sure UPSTART_SESSION=unix:abstract=/..... initctl start dbus
[17:31] <hallyn> that's why it cant' have the private symbols for older versions.  gotcha
[17:33] <xnox> hallyn: right, well "the debian/libnetcf1.symbols file lists the minimal version constraints one must have on this library when using a particular symbol"
[17:34] <xnox> when one starts out, one typically slaps ITP version number on all of them, or if there is good historical documentation as to what/when/where was introduced one can accurately set correct minimal versions.
[17:34] <xnox> thus e.g. ensuring that fairly conservative software can be still installed on older releases.
[17:35] <xnox> e.g. ubuntu-emulator-bin can be compiled on utopic, yet installed on precise. As only a handfull libraries are used and only stable/old symbols from there.
[17:35] <xnox> on all symbols files are properly maintained/versioned.
[17:35] <seb128> xnox, you still plan to upload that upstart fix before the w.e right?
[17:36] <xnox> dobey: in upstart test-suite we have python scripts to spawn user session for testing et.al. you might want to look into that.
[17:36] <xnox> seb128: yes.
[17:36] <seb128> thanks
[17:39] <dobey> xnox: i want our reliance on mir for security on the phone to not make it such a pain to actually develop and test our stuff on a normal system :)
[17:41] <guest27497> how to make an os like ubuntu ?
[17:43] <guest27497> #ubuntu how to make an Os
[17:43] <xnox> dobey: one should be able to launch things and UI without using ubuntu-app-launch.
[17:44] <xnox> dobey: and without user-session init.
[17:44] <dobey> xnox: yes, i can just run any app directly with qmlscne foo.qml normally
[17:44] <xnox> dobey: and i'm sceptical of dbus service launching UI.
[17:44] <dobey> xnox: the problem is that pay-service always launches the UI with ubuntu-app-launch
[17:45] <xnox> dobey: how is that not sufficient for testing? you'd test pieces individually.
[17:45] <dobey> and i don't know how to test the full process of the service without that
[17:45] <xnox> dobey: sounds very odd, can you not mock it out?
[17:45] <dobey> xnox: because i'm writing code that uses the pay service, and i'm trying to test that my code behaves correctly in response to what the pay-service sends it
[17:45] <dobey> xnox: in unit tests sure, but i'm trying to do live testing
[17:46] <xnox> dobey: oh, so you are not even testing the ui? so yeah, payment service should be better and not try to do silly things with ui, when it's only used on api level....
[17:46] <xnox> dobey: i'd talk to payment-service folks about it.
[17:46] <dobey> well i'm not trying to test the UI, but the UI coming up is part of the process
[17:47] <dobey> there is no way to test my code without that UI coming up
[17:48] <xnox> dobey: discuss it with tedg and the like people.
[17:49] <xnox> dobey: cause it sounds like getting a better testing interraction between the two would be better.
[17:49] <xnox> dobey: e.g. in ubiquity i did make adjustments and made it behave different when driven by testability framework, instead of launched normally, without taking a significantly different code-path.
[17:49] <xnox> But rather provide hooks for a service to plug into ubiquity.
[17:49] <dobey> xnox: yes i've been moaning about these issues to ted all morning too
[17:50] <dobey> but i don't think there is anything specifically for pay-service to make this easier
[17:50] <dobey> it's a general problem, not a pay-service problem
[17:51] <xnox> dobey: well if you are writting gui stuff you can (abuse) autopilot. If your unit-tests are executed from python autopilot stuff, you have a full blown thing to make things work.
[17:51] <xnox> dobey: also why are you using an lxc container?
[17:51] <dobey> xnox: because i want to keep my production environment on lts
[17:51] <xnox> ..
[17:52] <xnox> dobey: i thought you work in R&D =) and not in stable maintenance support teams. I find it's easier to spin up stable releases in VMs, containers, etc. Rather than the other way around.
[17:53] <dobey> xnox: i wish i worked in R&D. we don't have any R&D :) we have D
[17:53] <dobey> xnox: i find it's easier to keep my system working correctly, on lts releases :)
[17:53] <xnox> dobey: working with ubuntu-app-launch only sounds strange, especially when one should be able to launch things on unity7/legacy desktops
[17:54] <xnox> dobey: and I understand that ubuntu-app-launch can only do launching on the converged stack.
[17:54] <xnox> dobey: hehe. I tend to believe that I am in R&D =)
[17:56] <dobey> xnox: i work in stress management ;)
[18:06] <hallyn> xnox:  yeah, success i think.  symbols for pkg not accessing ncf_get_aug: Depends: libc6 (>= 2.2.5), libnetcf1 (>= 1:0.2.2)
[18:06] <hallyn> (s/symbols/deps, obviously)
[18:06] <hallyn> xnox: for pkg with such access: Depends: libc6 (>= 2.2.5), libnetcf1 (>> 1:0.2.4), libnetcf1 (<< 1:0.2.5)
[18:07] <xnox> \o/
[18:08] <xnox> hallyn: i think that's exactly what we need =)
[18:10] <hallyn> xnox: do you mind then updating the version for debian and pushing to experimetnal?
[18:11] <xnox> hallyn: nah, i provided the patch to the maintainer, he can do the rest =)
[18:13] <hallyn> xnox: haha, but i don't have the rights to push :)  but ok, i'll integrate and ask someone else to sponsor (who may then find somethign else i messed up while he's at it :)
[18:13] <hallyn> xnox: thanks
[18:14] <xnox> hallyn: well, you can push to the git repo right? and dput .dsc onto mentors.debian.net?
[18:14] <xnox> hallyn: i'm happy to do the sponsoring & upload it into experimental and/or sid.
[18:15] <xnox> hallyn: but I don't want to like NMU it, nor take credit for testing, I threw that together without even test-building it.
[18:18] <hallyn> xnox: another thing wrong in the pkg i think - there isnt' actually a git tree for the packaging
[18:18] <hallyn> I'll remove that
[18:19] <xnox> hallyn: oh, yeah. Better to not point anywhere, if that's not up-to-date / actually really used.
[18:20] <hallyn> perhaps i should request a tree on git.debian.org.
[18:21] <hallyn> xnox: thanks again :)
[18:23] <dobey> well finally managed to get upstart and dbus in the lxc
[18:24] <dobey> but launching the app fails with a SIGABRT :(
[18:25] <xnox> dobey: yeah \o/ and no /o\
[18:29] <dobey> ah
[18:29] <dobey> because aa-exec-click :(
[18:31] <hallyn> barry: hi!  would you mind sponsoring http://people.canonical.com/~serge/netcf-src-0.2.4-2/netcf_0.2.4-2.dsc into debian experimental?
[18:48] <xnox> dobey: which brings us back to -> payments service should be able to avoid things.
[18:52] <dobey> xnox: i still don't think this is a pay-service issue
[18:52] <xnox> dobey: replace aa-exec-click with e.g. #!/bin/sh \n exec $@ ?
[18:53] <xnox> dobey: lxc container, may not be capable of apparmor confinments, unless set up to work with those. I'm not sure which capabilities the container should have for apparmor to be operational.
[18:53] <xnox> and well, debug aa-exec-click itself, as to find out what's failing. Missing installed policies? or some such.
[18:54] <sarnold> xnox: you guessed it exactly, apparmor doesn't yet do nested profiles
[18:54] <stgraber> xnox: currently apparmor doesn't support profile stacking, so containers can't set a profile for things running inside them. It's something jjohansen1 has been working on for a while though and we should have this finally implemented for 15.04.
[18:55] <stgraber> xnox: until then, you may be able to run a contained app inside an LXC container if you turn off apparmor for the container (lxc.aa_profile = unconfined), set "lxc.cap.drop =" (so that mac_* aren't dropped) and then in theory apparmor in the container will be allowed to load new profiles into the kernel and move tasks to using it
[18:55] <jjohansen1> xnox: so currently its an either OR situation. Either lxc has apparmor enforcing on the container (current situation), OR you can disable the lxc mediation on the container, and set up an apparmor namespace for the container and have apparmor mediation in the container.
[18:56] <jjohansen1> the second option isn't directly supported atm, so it takes a little work
[18:56] <xnox> stgraber: or like fix payment-service to be testable without requiring (A) upstart user session (B) session dbus (C) graphics (D) ubuntu-app-launch (E) apparmor (F) doing all of above on LTS machine using development trunks.
[18:56] <dobey> xnox: i'm ok with exec $@, but one can't just do exec $@, as the arguments to aa-exec-click are in fact arguments to it. what to actually run is passed after --
[18:57]  * dobey doesn't quite remember how to deal with that in shell
[18:57] <xnox> dobey: man getopt
[18:58] <stgraber> dobey: loop through $* and call shift until you see --, then exec with $* ?
[18:58] <xnox> yeah, ^ sounds better
[18:59] <stgraber> for arg in $*; do
[18:59] <stgraber>     [ "$arg" != "--" ] && shift && continue
[18:59] <stgraber>     shift && break
[18:59] <stgraber> done
[18:59] <stgraber> exec $*
[19:01] <dobey> eh, but i'm still back to the problem of the click not finding the included c++ module; the same as if i just run qmlscene foo
[19:12] <dobey> yay, finally got it
[19:14] <dobey> or not :-/
[19:18] <dobey> u-a-l still aborts when it tries to launch the app
[19:26] <ion> stgraber: I think you want to use "$@" (also: ‘for arg in "$@"’ is equivalent to ‘for arg’).
[19:28] <stgraber> ion: shouldn't really make a difference in this case, but yes, $@ is usually better
[19:30] <ogra_> using case instead of [] too :)
[19:31] <stgraber> ogra_: I wanted it to be compact, case, entry, default, esac is pretty long for the same result :)
[19:31] <ogra_> true ... if its only one thing you match it wont make much of a difference
[19:46] <dobey> sigh
[20:28] <slangasek> stgraber: you certainly should be using "$@" here instead of $*; for anything that takes arbitrary arguments you can't assume there are none that require quoting (e.g., arbitrary filenames)
[20:28] <slangasek> and therefore one should always use $@ in such constructions instead of $*, because people are prone to cargo-culting bad habits ;)
[20:40] <ScottK> rbasak: I think if someone merged pycurl, then python-tornado could be a sync.