[06:18] <darkxst> pitti, hi, more systemd woes ;( not getting any filesystems (from fstab) mounted, seemingly triggered by glib on ubuntu-desktop ppa
[06:19] <pitti> Good morning
[06:19] <pitti> hey darkxst
[06:20] <pitti> darkxst: oh? would you mind booting with "debug", and put the "journalctl" output to a bug report?
[06:20] <darkxst> hey
[06:21] <darkxst> ok
[06:21] <pitti> darkxst: glib is rather unlikely, but it may have triggered some timing stuff
[06:21] <pitti> s/stuff/difference/
[06:22] <pitti> darkxst: oh, not in #u-desktop any more?
[06:22] <darkxst> pitti, on laptop
[06:22] <pitti> darkxst: so, by the release I plan to fix that "adm" users can access the journal
[06:23] <darkxst> most normal users are in that group?
[06:24] <pitti> darkxst: debian bug 771980
[06:24] <ubottu> Debian bug 771980 in systemd "systemd: /run/log/journal is not readable by the adm group" [Minor,Open] http://bugs.debian.org/771980
[06:24] <pitti> darkxst: no, only the first one (which also gets sudo); other than that, that should be limited to administrators
[06:24] <pitti> darkxst: exactly the same as syslog, BTW
[06:25] <pitti> -rw-r----- 1 syslog adm 809053 Feb  9 07:24 /var/log/syslog
[06:25] <darkxst> pitti, right, so there is really no way to get logs then from apport?
[06:27] <pitti> darkxst: you mean now, or after fixing the above?
[06:27] <pitti> darkxst: nothing regressed under systemd, you can still get syslog etc.; but of course accessing the per-unit journal would be nicer
[06:28] <pitti> darkxst: if you aren't in "adm", then the hook could still ask for it with root privs (you'll get a polkit prompt then, and an admin has to authenticate)
[06:28] <darkxst> pitti, well currently we grab the upstart user logs for say gnome-session
[06:28] <pitti> darkxst: oh, user
[06:28] <pitti> darkxst: nothing has changed for the user session
[06:30] <darkxst> maybe its a GNOME thing? but no user logs with that stuff now
[06:31] <pitti> darkxst: I don't know, did GNOME Ubuntu ever use upstart sessions?
[06:32] <pitti> I thought all of our DEs would
[06:32] <darkxst> pitti, yes
[06:32] <pitti> and session init is still upstart
[06:32] <darkxst> pitti, I am 100% we do not get logs in .cache/upstart
[06:33] <darkxst> and also a couple of wierd bugs due to upstart user sessions disappear
[06:33] <darkxst> under systemd init
[06:33] <pitti> darkxst: oh, indeed; I only have one recent file there, .cache/upstart/unity-panel-service.log
[06:33] <pitti> but also some rotated stuff from yesterday
[06:35] <darkxst> pitti, bug 1419623
[06:35] <ubottu> bug 1419623 in systemd (Ubuntu) "systemd init is no mounting drives from fstab" [Undecided,New] https://launchpad.net/bugs/1419623
[06:44] <darkxst> and bug 1385572 is the reason I think there is no upstart user sessions under systemd init
[06:45] <ubottu> bug 1385572 in upstart (Ubuntu) "gnome-session not shutting down cleanly" [Low,Confirmed] https://launchpad.net/bugs/1385572
=== darkxst is now known as darkxst__
=== darkxst_ is now known as darkxst
[07:02] <pitti> darkxst__: I suppose logging into a VT works and puts you into the root dir; there sudo mount -a should work?
[07:02] <pitti> darkxst__: (just making sure it's not something serious with util-linux or the actual partitions)
[07:02] <darkxst> pitti, yes that is what I have been doing
[07:05] <pitti> cyphermox: oh, nothing wrong with python-dbusmock -- it just detected gnome bug 734466 :)
[07:05] <ubottu> Gnome bug 734466 in nmcli ""nmcli dev wifi" crashes with multiple wifis" [Normal,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=734466
[07:26] <dholbach> good morning
[07:52] <pitti> infinity: hm, the latest "patch" release fixes the dangling symlink problem for most packages, but apparently not glibc yet; I wonder what kind of funky thing it tries to do there, symlink outside the build tree or so?
[07:52] <Mirv> can a core-dev "ack" https://ci-train.ubuntu.com/job/ubuntu-landing-006-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-ui-toolkit_1.1.1403+15.04.20150206-0ubuntu1.diff ? both new build-deps are in main.
[07:58] <infinity> pitti: The new glibc should be fine, no?
[07:59] <infinity> pitti: It unpacks and builds locally, at least.
[07:59] <infinity> pitti: Seems to be going happily on the buildds too.
[07:59] <pitti> Mirv: LGTM
[07:59] <infinity> pitti: No idea, TBH, why -13ubuntu1 is/was sad, but I think we're past that.
[08:00] <pitti> infinity: hm, I still see it on http://d-jenkins.ubuntu-ci:8080/job/vivid-adt-glibc/27/ARCH=i386,label=adt/console which ran on Feb 6
[08:00] <pitti> glibc_2.19-13ubuntu3.dsc
[08:00] <pitti> infinity: ok, if it works locally now I'll investigate, thanks
[08:01] <infinity> pitti: -15ubuntu1 is the one that works.
[08:02] <LocutusOfBorg1> hi people
[08:02] <pitti> hm, why didn't that run
[08:02] <infinity> pitti: It only uploaded 43m ago.
[08:02] <pitti> oh! just from 33 minutes ago :)
[08:06] <Mirv> thanks martin
=== mfisch is now known as Guest22817
[08:41] <pitti> wgrant: hey William, how are you?
[08:42] <pitti> wgrant: not sure if you saw my email about RTM langpack exports the other day, but would we have enough capacity to build them more often? like twice a week?
=== kickinz1|afk is now known as kickinz1
=== work_alkisg is now known as alkisg
[09:00] <alkisg> mvo: Good morning! About the update-manager SRU, and a possible re-upload without the other changes, last Friday you said "I look at this, in a call right now" - did you? Should I wait for a re-upload, or just try to make SRUs out of the other changes included in the same upload?
[09:00] <wgrant> pitti: Ah, missed that. RTM exports only take about 90 minutes, so we can do them daily, particularly since the new DB servers are slowly coming online. I'll have to add a new flag for the persistent full exports, though. How pressing is this?
[09:01] <alkisg> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1415785
[09:01] <ubottu> Launchpad bug 1415785 in update-manager (Ubuntu Precise) "Please remove all ltsp* blacklisting" [High,In progress]
[09:01] <pitti> wgrant: vrr knows more about how pressing it is, but I suppose it's the kind of "the earlier the better", but "not world breaking" class
[09:01] <pitti> wgrant: cjwatson proposed to just add the "export full pack" to the API so that we can set it via cron
[09:02] <wgrant> pitti: If you're happy with that then that's fine too.
[09:02] <wgrant> It's a little easier from our end.
[09:03] <pitti> wgrant: yes, that'd work well enough for me
[09:04] <pitti> le huh? my mouse pointer just became invisible; VT switching and switching between different windows (with different cursor shapes) doesn't help
[09:04] <pitti> is there a trick to make it visible again?
[09:05] <ogra_> wiggle it
[09:05] <ogra_> :)
[09:05] <pitti> mlankhorst, tjaalton ^ do you happen to know?
[09:06] <alkisg> Unplug it from the usb port and plug it again? :)
[09:07] <pitti> alkisg: no; the mouse clearly works (FFM, marking text, clicking, etc.)
[09:07] <pitti> I just don't see the cursor
[09:07] <pitti> (unpluggging, VT switch etc. doesn't help)
[09:08]  * ogra_ hands pitti some http://i.stack.imgur.com/DVuWk.png
[09:08] <pitti> :)
[09:08] <pitti> well *shrug*, I'll just reboot as soon as I can
[09:08] <tjaalton> try restarting compiz?
[09:08] <tjaalton> gtk can hide it, maybe it got stuck
[09:09] <tjaalton> this happens frequently for me when logging in, but it comes back once everything is loaded
[09:11] <pitti> nope, restarting compiz didn't help either
[09:11] <pitti> anyway, probably sun rays / rare graphics driver bug
[09:12] <mlankhorst> pitti: no idea, I know gsd hides the cursor if no mouse is found, annoying with synergy :P
[09:12] <pitti> oh wow, and all of a sudden it popped up again
[09:13] <pitti> mlankhorst: ah, perhaps some weirdness with the thing that hides the touchpad and/or mouse cursor on inactivity
[09:13] <pitti> syndaemon
[09:13] <mlankhorst> sounds likely
[09:14] <tjaalton> is that even used anymore?
[09:14] <tjaalton> guess it shouldn't
[09:14] <pitti> yeah, if you enable the option in control-center
[09:14] <pitti> now I remember that I enabled it in in the train last weekend
[09:14] <tjaalton> sounds legacy
[09:14] <tjaalton> anyway :)
[09:14] <pitti> but I thought that was for disabling the touch pad during typing, not disabling the mouse pointer on inactivity
[09:15] <pitti> we once had something for the latter in the past ("unclutter"), but I thought that has long been obsolete
[09:15] <pitti> and/or went into GTK or whereever
[09:15] <tjaalton> yep
=== kickinz1 is now known as kickinz1|afk
=== kickinz1|afk is now known as kickinz1
=== work_alkisg is now known as alkisg
[09:36] <LocutusOfBorg1> hi people does anybody know if bug 1417716 is affecting virtualbox or sysvinit?
[09:36] <ubottu> bug 1417716 in virtualbox (Ubuntu) "package virtualbox 4.3.18-dfsg-2ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Incomplete] https://launchpad.net/bugs/1417716
[09:36] <LocutusOfBorg1> I can't figure it out
[09:36] <LocutusOfBorg1> seems more bug 1385817
[09:36] <ubottu> bug 1385817 in Release Notes for Ubuntu "initscripts package fails to upgrade if there are local init scripts on the system with no LSB headers" [High,Triaged] https://launchpad.net/bugs/1385817
=== kickinz1 is now known as kickinz1|afk
=== kickinz1|afk is now known as kickinz1
[09:46] <xnox> LocutusOfBorg1: most of the time it's neither.
[09:47] <xnox> LocutusOfBorg1: it's duplicate of "initscripts must have sysv headers"
[09:47] <xnox> bug
=== Tribaal_ is now known as Tribaal
[09:58] <LocutusOfBorg1> thanks xnox :)
[09:58] <LocutusOfBorg1> I was so tempted to close as duplicate
[10:02] <infinity> pitti: That calibre/powerpc failure that references 'Pool(cpu_count)' ... It's not losing its mind because sagari has 24 CPUs, perhaps?
[10:03] <pitti> oh, I didn't even know about it
[10:03] <pitti> I guess I don't get ftbfs mail for autosynced packages
[10:03] <infinity> pitti: Yeah, cause you don't get mail from LP... That.
[10:04] <pitti> thread.error: can't start new thread
[10:04] <seb128> bdmurray, hey, is there a known issue with e.u.c and crossing of lines corresponding to fixed bugs? it seems it stopped doing that since the "... seen" columns indicate series rather than versions?
[10:04] <infinity> pitti: I'm betting that if I re-run it on one of the <= 8 CPU buildds, it'll work fine.  But that's just a wild guess.
[10:04] <pitti> sounds a bit like debian bug 760865
[10:04] <ubottu> Debian bug 760865 in src:calibre "calibre: FTBFS on mips: thread.error: can't start new thread" [Serious,Fixed] http://bugs.debian.org/760865
[10:05] <pitti> I coudl extend the workaround to powerpc
[10:05] <pitti> but that was also just a workaround without truly understanding the issue
[10:06] <infinity> pitti: Yeah, the workaround definitely sounds incorrect. :P
[10:06] <pitti> $ python -c  'from multiprocessing import cpu_count; print(cpu_count())'
[10:06] <pitti> 4
[10:06] <infinity> pitti: And I bet I can reproduce on other machines with sufficiently large numbers of cores/threads.
[10:06] <pitti> so that would print 24, but it cannot actually handle 24 threads?
[10:07] <infinity> pitti: It can handle 24 threads fine, but I suppose it depends on what "handle" means.
[10:07] <mvo> alkisg: hi, sorry for the slow reply, I added a sru header to the bugreport now where it was missing (the https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1402706)
[10:07] <ubottu> Launchpad bug 1402706 in update-manager (Ubuntu Precise) "More explicit wording needed for HWE updates" [High,In progress]
[10:07] <infinity> pitti: 24 threads consuming massive amounts of memmory each could explode, for instance.
[10:07] <alkisg> mvo: hi, I think there are 2 more involved bug reports that lack SRU headers? Let me check...
[10:08] <alkisg> mvo: LP #1415785, #1402706, #1341320, #1343296
[10:08] <ubottu> Launchpad bug 1341320 in update-manager (Ubuntu) "empty apt-get install command suggested by hwe-support-status" [Undecided,Confirmed] https://launchpad.net/bugs/1341320
[10:08] <ubottu> Launchpad bug 1415785 in update-manager (Ubuntu Precise) "Please remove all ltsp* blacklisting" [High,In progress] https://launchpad.net/bugs/1415785
[10:08] <ubottu> Launchpad bug 1343296 in update-manager (Ubuntu) "hwe-support-status does not output all necessary commands for upgrade" [Undecided,New] https://launchpad.net/bugs/1343296
[10:08] <mvo> alkisg: let me check
[10:10] <infinity> pitti: It would be better to find out *why* we're seeing "thread.error: can't start new thread"
[10:10] <infinity> pitti: Cause it's nonsensical to make a blanket statement like "arch $foo can't handle $bar threads", given than a single-core machine can run thousands of threads.
[10:11] <infinity> pitti: But if it's trying to eat a ton of RAM with each, or hitting some bizarre internal counter or something, that would be worth knowing.
[10:11] <infinity> pitti: I figure that replacing the autodetection with a static "200" and testing locally would probably show the same bug.
[10:15] <infinity> pitti: Or, from a random stackoverflow hit: "You're using a 32bit system and running out of virtual memory. One of your libraries is likely spawning threads and not reclaiming them correctly. As a workaround, try reducing the default thread stack size with threading.stack_size."
[10:15] <infinity> pitti: So, maybe just wise to limit your thread count to "NUM_CORES || 8", whichever is smaller, or do so only on 32-bit systems...
[10:16] <infinity> pitti: Seems like python's just exhibiting a bit of suck here. (not surprising, from how much I know about python threading sucking)
=== work_alkisg is now known as alkisg
[10:16] <pitti> infinity: ah yeah, trying with "200" on a low-ram VM or so could work
[10:17] <pitti> (to try and reproduce)
[10:17] <infinity> pitti: Note that that machine is hardly "low RAM".  It's 16G, but yeah, also 32-bit, so python's only getting 2G (or 3G, I can't remmeber what the user/kernel split on ppc32 is).
[10:18] <pitti> ah ok, so "200" on an i386 VM should be reasonably close then
[10:18] <infinity> pitti: So, reproducing on i386 with a large thread count should be easy, I'd think.
[10:18] <infinity> pitti: Yeah.
[10:20] <popey> pitti: seems something changed recently in udev (perhaps) on vivid, as I can no longer "adb devices". adbd has to be started as root. This seems to be a regression over the last week or so.
[10:21] <pitti> popey: i. e. your /dev/usb/... is no longer accessible to you?
[10:22] <pitti> popey: you should get an automatic ACL to it
[10:22] <ogra_> pitti, he can see the device when he runs "adb devices" as root
[10:22] <ogra_> (after adb kill-server on the PC)
[10:22] <pitti> (check lsusb for bus/device number, then getfacl /dev/bus/usb/001/002 and change the numbers accordingly)
[10:23] <infinity> pitti: Anyhow, it would make sense if mips is seeing a similar issue, cause Debian's mips buildds are Cavium CPUs with a ridiculous number of cores, and 32-bit userspace.
[10:23] <ogra_> http://paste.ubuntu.com/10140289/
[10:23] <ogra_> this is what we ship with the android-tools-adb package
[10:23] <infinity> pitti: Which is something no other port has.  I don't think any other 32-bit port goes over 8 cores in any Debian or Ubuntu buildd configuration.
[10:25] <popey> pitti: http://paste.ubuntu.com/10140305/
[10:25]  * ogra_ sees infinity's lanst android upload and thinks we really need to get rid of these win32 build deps at some point 
[10:25] <pitti> user:alan:rw-
[10:25] <pitti> popey: ^ LGTM
[10:25] <popey> hm, so I wonder why adb devices returns no devices then.
[10:26] <ogra_> well, adb didnt change since november
[10:26] <infinity> ogra_: I'm not convinced mingw32 is actually used in the build (a grep in the build log didn't seem to show it being called), but I didn't feel the urge to experiment either.
[10:26] <popey> http://paste.ubuntu.com/10140312/
[10:26] <ogra_> yeah
[10:26] <pitti> hard to tell; perhaps stracing adb as user reveals some EPERM thing someplace else?
[10:27] <pitti> (FTR, works fine here with nexus 4 on current vivid)
[10:27] <popey> hmm, ok. thanks.
[10:27] <pitti> popey: can you run adbd in the foreground? perhaps that already spits out some error message
[10:28] <popey> will try
[10:29] <ogra_> not adbd ... adb
[10:29] <ogra_> adbd is the bit running on the phone
=== work_alkisg is now known as alkisg
[10:30] <pitti> ogra_: ah, ok; I mean the server bit that it forks off into the background
[10:30] <pitti> I don't see a CLI switch to run it in foreground, so I guess strace it is :/
[10:31] <ogra_> right, not sure you can run it easily in the fg
[10:35] <popey> :(
[10:37] <popey> aha!
[10:38] <popey> I think some path has changed and it's found another version of adb? http://paste.ubuntu.com/10140430/
[10:38] <pitti> /home/alan/tools/android/eclipse-adt/sdk/platform-tools/adb
[10:38] <popey> \o/ "/usr/bin/adb devices" works!
[10:38] <pitti> so you have that in your $PATH?
[10:38] <popey> yeah, blame didrocks ㋛
[10:39] <popey> umake :)
[10:39] <popey> looks like it was added to my bashrc
[10:39] <didrocks> popey: that's what you gain by listening to users! :)
[10:39] <popey> I know right!?
[10:39] <didrocks> why the adb version here doesn't work for you? (should I backlog?)
[10:40] <popey> ogra_: did we patch adb in android-tools-adb?
[10:40] <ogra_> popey, sure
[10:40] <didrocks> ah, here we go :)
[10:40] <popey> :)
[10:40] <ogra_> popey, adb abd adbd are both a cmpolete patch
[10:41] <didrocks> popey: I purified your bashrc with upstream goodness :)
[10:41] <popey> I feel blessed.
[10:41] <ogra_> (not sure we make any changes to it though )
[10:41] <ogra_> (for adb that is, adbd is heavily changed)
[10:42]  * popey modifies his bashrc
[10:42]  * popey has learned things today. thanks chaps :)
=== didrocks1 is now known as didrocks
[11:09] <alkisg> mvo: should I help with the SRUs for the other 2 bug reports?
[11:09] <alkisg> (sorry if you talked to me and I didn't receive it, laggy network today here...)
[11:12] <caribou> tkamppeter: Hi, remember the cups fix you sponsored for me recently ?
[11:12] <caribou> tkamppeter: I have just uploaded the debdiffs for Trusty & Utopic. want to sponsor those as well ?
=== alkisg is now known as work_alkisg
[11:27] <tkamppeter> caribou, Utopic I have uploaded now, now I will do Trusty.
=== _salem is now known as salem_
=== MacSlow is now known as MacSlow|lunch
[12:07] <caribou> tkamppeter: perfect! I've already built & tested on both; I'll add the SRU team once you're done
[12:09] <tkamppeter> caribou, Trusty is now done, too.
[12:09] <caribou> tkamppeter: great, thank you !
[12:10] <tkamppeter> caribou, thanks for setting up the CUPS SRUs.
=== damon is now known as ngaio
=== darkbasic_ is now known as darkbasic
=== ara is now known as Guest94549
=== MacSlow|lunch is now known as MacSlow
=== darkbasic_ is now known as darkbasic
[14:13] <tkamppeter> caribou, the CUPS SRU path for Trusty is still blocked by bug 1386241. I will look into what can be done here. The Utopic SRU can already be processed though.
[14:13] <ubottu> bug 1386241 in system-config-printer (Ubuntu Trusty) "Add the full IPP Everywhere support from Utopic to Trusty" [High,Triaged] https://launchpad.net/bugs/1386241
[14:13] <caribou> tkamppeter: ok, thanks for checking that out
=== marcusto_ is now known as marcustomlinson
=== negronjl_ is now known as negronjl_afk
[15:09] <bdmurray> seb128: not, that I'd heard of
=== darkbasic_ is now known as darkbasic
[15:38] <ricotz> mvo, hi, please take a look at the attached debdiff here https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/1399582
[15:38] <ubottu> Launchpad bug 1399582 in aptitude (Ubuntu) "aptitude fails to fetch changelogs because of illformed URL request" [High,Confirmed]
=== Guest22817 is now known as mfisch
=== sabdfl_ is now known as sabdfl
[15:56] <sabdfl> ScottK, wow, that was a fun memory!
[15:56] <sabdfl> or, sort of memory :)
[15:57] <sabdfl> the sea survival training was a bit of a blur
=== kickinz1 is now known as kickinz1|afk
=== a7med is now known as Neo31
[16:47] <bdmurray> seb128: I'm looking into it though, thanks
[16:48] <seb128> bdmurray, can you confirm? want me to report a bug?
[16:51] <bdmurray> seb128: I can confirm, it works better on a filtered page like https://errors.ubuntu.com/?release=Ubuntu%2015.04&package=media-hub&period=day and a bug would be helpful
[16:52] <seb128> bdmurray, against what component?
[16:52] <bdmurray> launchpad.net/errors/
[16:54] <seb128> bdmurray, https://bugs.launchpad.net/errors/+bug/1419878
[16:54] <ubottu> Launchpad bug 1419878 in Errors "default view doesn't seem to cross lines corresponding to fixed bugs" [Undecided,New]
=== rickspencer3_ is now known as rickspencer3
[18:14] <alexbligh1> Dependency question. Package A provides, conflicts, and replaces B. Package C conflicts with package B. The idea here was for an upgrade from A(old) to A to remove package B, but to optionally let a legacy version be reinstalled (package C shares some of the same files as package B). What happens in practice is package C can't be installed without removing A. Any ideas?
[18:15] <cjwatson> alexbligh1: Make the Conflicts from C to B versioned, so that it won't match the Provides.
[18:15] <cjwatson> E.g. <= max-version-that-ever-existed, or even just >= 0
[18:16] <alexbligh1> cjwatson, aha! very clever. Thanks
[19:00] <rharper> hallyn: stgraber:  is there a non-interactive form  of lxc remote add <url> when the password is set?  currently it prompts when password is set, would like to do this automatically
[19:01] <hallyn> rharper: I work around it by adding the client certificsate in the server's certs dir
[19:01] <hallyn> then server doesn't ask for pwd
[19:02] <rharper> hallyn: hrm... for some reason I thought I needed to do the pass bits before the certs were generated
[19:03] <rharper> I'm doing: 1. start lxd locally, 2) lxc config set password <pass>  3)  I want to add the remote  --    4) copy client certs ... but you're saying I can swap 4 and 3 ?
[19:03]  * rharper gives it a go 
[19:04] <hallyn> rharper: yeah just do a 'lxc remote list' first to generate th client certs, copy them over, restart lxd
[19:04] <rharper> cool
[19:04] <hallyn> i've got a juju charm that tries to do this.  (but fails at some point, and i've neglected it)
[19:05] <rharper> I get fingerprint prompt
[19:05] <rharper> hallyn: oh, I should look at what you have then
[19:05]  * rharper is charming lxd/lxc stuff as well 
[19:07] <hallyn> rharper: oh excellent then i may not have to :)  what i've got is at... oh lemme re-push
[19:07] <rharper> hrm, looks like somethin with config trust list might help fill out the client/servercert/local.crt bits...
[19:07] <hallyn> lp:/~serge-hallyn/charms/trusty/ovs-lxd/trunk
[19:08] <hallyn> ?
[19:09] <rharper> http://paste.ubuntu.com/10146613/
[19:09] <rharper> hallyn: I noticed that once I do the remote add, I get a new file in ~/.config/lxc/servercert/<name>.crt
[19:09] <rharper> I assume once that's present (from accepting the fingerprint) that we don't get prompted again
[19:09] <hallyn> right
[19:09] <rharper> but I still want a way to accept the server cert without prompting
[19:09] <hallyn> but 'config trust', if that was implemented, i missed the pull request to od that :)   obviously shouldn't crash though
[19:10] <hallyn> raise a github issue :)
[19:10] <rharper> heh
[19:10] <hallyn> that tych0 chap will get on it in a jiffie
[19:10] <hallyn> uqestion is how would we make that safe?
[19:10] <rharper> right, so what would let me pull down the server cert into the local config  ?
[19:11] <rharper> I assume the same way ssh does it (you put your hands in your ears and supply a parameter that says I don't care)
[19:11] <hallyn> i understnad on a trusted network with auto-instlal it's what you want.  but how do we keep users from then using that to their ec2 host
[19:11] <rharper> but seriously it'd need to be done via some published fingerprint ... maybe gpg keyring publishing ?
[19:11] <hallyn> yeah i think best ot discuss this on a github issue
[19:11]  * rharper is way out of his comfort zone 
[19:12] <hallyn> with certs, or with github issues?
[19:13] <hallyn> btw what are you doing, testing nc-lxd?
[19:15] <rharper> yes, nc-lxd, charming it up while zul works on kilo stuff;
[19:15] <rharper> hallyn: I see now how yuo get the servercert
[19:16] <rharper> in the nc-lxd case, it's eaiser since the server/client are the same machine
[19:16] <rharper> I just need to fish out the lxd server cert file
[19:16] <rharper> copy it to the client config location
[19:16] <rharper> and won't get the prompt
[19:16] <zul> rharper:  im going to be using the unix socket daemon in the next iteration
[19:17] <hallyn> don't make him cry
[19:17] <zul> hallyn:  i dunno...rhaper is a big boy
[19:17] <rharper> sometimes
=== roadmr is now known as roadmr_afk
=== pgraner is now known as pgraner-afk
=== roadmr_afk is now known as roadmr
[20:48] <israel> does anyone know how to set _NET_WM_ICON easily in C++ I haven't been able to easily find documentation on this
[20:59] <dobey> israel: in qt?
[21:00] <israel> No dobey in FLTK... sorry I should have specified this..
[21:00] <israel> I was going to try to simple set it via xkb stuff (or xlib) but I am not very familiar with that
[21:01] <israel> the documentation for xkb is not very good for someone unfamiliar with it
[21:02] <dobey> israel: i think you'd use Fl_Window::iconlabel("exe-name") and it will pull the icon from the theme and set the appropriate x window hints
[21:02] <dobey> xkb is for keyboards
[21:02] <dobey> so i can see how that would be confusing :)
[21:02] <israel> heheh sorry xcb
[21:02] <israel> too many x acronyms
[21:03] <israel> i will try it dobey and let you know
[21:04] <dobey> at least, that's what i gathered from a simple "fltk set window icon" search :)
[21:08] <israel> not quite working.... dobey thanks for the try :)
[21:10] <dobey> israel: if fltk doesn't provide working facilities for it, and you don't care about portability, then you'll need to use Xlib indeed; best place to look at that is probably the gdk-x11 code in gtk+
[21:11] <Noskcaj> cyphermox, What are we still waiting on for bluez5?
[21:15] <israel> thanks dobey  it is GNU/Linux only (JWM specificly)  I will check it out!
[21:32] <cyphermox> Noskcaj: just coordinating things, I'm not convinced that we are waiting on much. You should ask seb though
[21:32] <cyphermox> there's already a PPA with the transition in progress: ppa:ubuntu-desktop/transitions
[21:34] <arges> hallyn: hey
[21:34] <arges> hallyn: almost have this patch done for disabling ksm in vm. found an issue when testing.
[21:34] <hallyn> arges: ok, cool.  i'm doing the merge right now.  head spinning a bit, will bbiab
[21:35] <arges> hallyn: yea no hurry, i'll just post it to the bug when its ready
[21:37] <hallyn> arges: ok, thanks
[21:47] <rharper> hallyn: stgraber: where do you get updated golang package for trusty ?
[22:05] <roaksoax> ScottK: do you have any plans of updating psycopg2 to 2.6 in debian anytime soon?
[22:07] <ScottK> roaksoax: I hadn't noticed it was out.  I can look at doing an upload to experimental.  Possibly as soon as Friday.
[22:07] <roaksoax> ScottK: yeah, I just noticed today. And thanks! Let me know if you do so we can make sure it makes it into vivid
[22:11] <hallyn> rharper: https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxd-daily
[22:11] <rharper> hallyn: thanks!
[23:02] <stgraber> rharper: ubuntu-lxc/lxd-daily
[23:03] <rharper> stgraber: thanks!
=== mwenning is now known as mwenning-rr5
[23:55] <aeoril> How do I use /debian/rules to configure a make environment for an Ubuntu package?  Or, where would I find that info on the web?
[23:56] <aeoril> Should I set up my build environment using this tutorial, or is it out of date?  https://wiki.ubuntu.com/BeginnersTeam/FocusGroups/Development/Devbeginnings
[23:57] <aeoril> (I think the BeginnersTeam was disolved some time ago, IIRC)
[23:57] <sarnold> aeoril: I suggest this instead of the pbuilder: https://wiki.ubuntu.com/SimpleSbuild
[23:57] <aeoril> sarnold hey!  Thanks!
[23:58] <sarnold> aeoril: but e.g. Unit193 said he uses pbuilder, so it's not like pbuilder is wrong; I've heard though that sbuild does a better job approxmiating the buildds
[23:58] <aeoril> sarnold I remember Unit193 - I used to interact with him a lot on #ubuntu-beginners-team or whatever ...