[00:06] <jtaylor> hm I seem to have applied the patches wrongly
[00:07] <jtaylor> the upstream patches do work error less, but the py3 output is less useful
[00:16] <jtaylor> yup, just be being dumb again, the upstream patches work for me
[00:16] <jtaylor> slangasek: ^
[00:17] <jtaylor> < goes to bed, bye
[00:32] <barry> StevenK: fix committed sounds right-ish at least, since python's roundup doesn't really have a fix released status, and nothing's really fix released until the next python (patch) version, which isn't tracked in round up.
[00:33] <StevenK> barry: Do you want to add that to the bug and change the status as you see fit, then?
[00:34] <barry> StevenK: i just added a comment. let's see if lifeless responds before setting status
[00:35] <StevenK> barry: Thanks
[00:47] <lifeless> barry: url ?
[00:59] <infinity> @pilot out
[03:10] <slangasek> cjohnston, mhall119: do you have any idea why there are duplicate sessions for a blueprint, and can you tell me how to get rid of one of them? http://summit.ubuntu.com/uds-1311/meeting/22028/core-1311-dmraid2mdadm/ http://summit.ubuntu.com/uds-1311/meeting/22017/transitioning-to-use-mdadm-by-default-for-some-of-the-fakeraid-devices/
[04:24] <pitti> Good morning
[05:05] <rbasak> infinity: I'm not sure how to test libapache2-mod-svn without also relying on svnadmin and svn to work :)
[05:06] <infinity> rbasak: Heh.  Well, I like it anyway.  It's the complete opposite of unit testing, but the build-time tests do a fair job of that.  Your test is a great one-shot "yeahp, pretty much the whole package still works when installed".
[05:06] <rbasak> A happy coincidence :)
[05:06]  * infinity curses firebird, which appears to hate him on arm64.
[05:07]  * rbasak appreciates the praise. Thank you!
[05:08] <pitti> infinity: would you mind adding a "bad test" override for debtags? someone added an XS-Testsuite: without actually having tests; I removed the jobs from jenkins, but britney still thinks it's "failed"
[05:08] <infinity> pitti: Sure, if it's removed and won't have a sad next time.
[05:08] <pitti> infinity: no, the override can go again once it propagated
[05:09] <pitti> infinity: I would just have updated the autopkgtest status file, if I could remember to which host britney moved to :)
[05:09] <infinity> pitti: Done.
[05:09] <pitti> infinity: cheers
[05:09] <infinity> pitti: And nakefruit.
[05:09] <infinity> snakefruit, too.
[05:10] <infinity> The first barrier of entry is deciphering my typos.
[05:10] <pitti> ah, thanks
[05:12]  * infinity decides he cares a lot less about porting firebird2.5 to arm64 than he did an hour ago and finds something less stupid to do.
[09:23] <tseliot> pitti: https://jenkins.qa.ubuntu.com/job/trusty-adt-ubuntu-drivers-common/10/ :)
[09:23] <pitti> tseliot: indeed, thanks for fixing!
[09:24] <tseliot> :)
[09:25] <tseliot> pitti: oh, BTW, where do you suggest that I file a bug report on the python gtk (gir) bindings?
[09:26] <pitti> tseliot: that'd be gtk+3.0
[09:26] <tseliot> pitti: yes, the 3.0 ones
[09:27] <tseliot> pitti: or do you mean that I should file the report against the source of gtk+3.0?
[09:27] <pitti> tseliot: right, as that builds the Gtk GIR bindings
[09:27] <tseliot> pitti: ok, thanks
[10:33] <seb128> cjwatson, hey, how do you determine if config.guess/sub have support for arm64?
[10:40] <pitti> seb128: check if config.guess contains "aarch64"
[10:40] <pitti> "aarch64:Linux:" more specifically
[10:41] <seb128> pitti, danke
[10:42] <seb128> cjwatson, I'm syncing libisoburn (it's on your merge list, the only diff was running dh-autoreconf to have an updated config.guess/sub for arm64, the new version is Debian has those recent enough)
[10:42] <xnox> slangasek: hm, i filed a blueprint _and_ did the propose a session "simple form" on summit.u.c. So the earlier "manual" one needs killing, i.e. kill http://summit.ubuntu.com/uds-1311/meeting/22017/transitioning-to-use-mdadm-by-default-for-some-of-the-fakeraid-devices/
[10:42] <xnox> cjohnston: ^
[10:43] <seb128> cjwatson, doh, ignore that, we already have the new version in trusty-proposed it seems (I didn't have proposed enabled)
[10:43] <seb128> cjwatson, well, I updated libisofs which unblocked the depwait at least :p
[10:44] <seb128> pitti, thanks CurrentDesktop btw ;-) oh, and hey ;-)
[10:53] <cjwatson> seb128: grep aarch64 config.{guess,sub}
[10:53] <cjwatson> oh, pitti got there
[10:53] <seb128> cjwatson, thanks ... yes ;-)
[10:53] <cjwatson> seb128: right, I was assuming you'd get to libisofs :)
[10:53] <cjwatson> I went through the same sync decision last week
[10:53] <pitti> seb128: ça va :)
[10:53] <seb128> cjwatson, ;-)
[10:53] <pitti> seb128: rmadison FTW!
[10:54] <seb128> cjwatson, did you have a good trip back btw?
[10:54] <seb128> pitti, indeed
[10:54] <pitti> since the archive stuff moved to a new server, rmadison is actually usable again
[10:54] <cjwatson> meh, as good as you can get for that duration :)
[10:54] <cjwatson> slept a bit and the plane didn't crash
[10:55] <cjwatson> I've been vaguely meaning to have merges.u.c look at both trusty and trusty-proposed so that we don't have this duplicate-work window
[11:34] <xnox> ev: can you make me an admin of https://launchpad.net/~timezonemap-team ?
[11:35]  * Laney sniggers
[11:44] <ev> xnox: done
[11:47] <xnox> Laney: I think you are now the highest contributor to timezonemap. And as the one who touch it last, you are now the maintainer ;-)
[11:47] <Laney> Someone must have witten all the existing code :-)
[11:47] <Laney> anyway, review iz good
[11:48] <xnox> Laney: well ev copycatted some of it, then passed the maintainance baton to me, and now it's you =) it's a desktop component anyway ;-)
[11:48] <Laney> but ta
[11:48] <sladen> xnox: ev: talking of which, did the original 2.7MB 'tz_map.svgz' get included?
[11:49] <Laney> haha, it's both desktop & installer
[11:49] <xnox> sladen: i have it in an email somewhere. Let me check.
[11:49] <Laney> destroy the silo
[11:50] <sladen> xnox: ev: it was PD derived from a CIA map (confirmed by kwwii), and sabdfl okay'ed shipping it (based on the CIA's PD statement)
[11:50] <sladen> xnox: if so, you can probably finally close off bug #651064
[11:51] <xnox> sladen: pushed.
[11:51] <Laney> phwoar
[11:51] <Laney> that calls for a release
[11:53] <Laney> xnox: do you need to make it use that somehow?
[11:53] <xnox> sladen: well I committed the original .svg into timezonempa, but I don't know how to render the timezone pixmap.
[11:53] <Laney> also, didn't put it in src/data?
[11:54] <Laney> which already has some countryInfo1.svg thing
[11:54] <xnox> Laney: oh.
[11:55] <Laney> yeah I guess there is something more to be done here
[11:55] <xnox> sladen: if you can update the rendered.pngs that would help the original svg and rendered.pngs are in src/data in lp:timezonemap
[11:56] <xnox> sladen: similarly russia has moved one timezone to the right across the board, so I general refresh of timezones rendered pngs would be nice.
[12:01] <brainwash> is this behavior intended? bug 1248137
[12:02] <brainwash> I read about this issue some time ago in this channel, some processes still remain alive after session logout
[12:02] <brainwash> upstart?
[12:04] <pitti> we didn't enable logind's option to kill all remaining processes after logout, mostly for safety
[12:04] <pitti> (as it would make it impossible to leave stuff running in the background deliberately)
[12:04] <pitti> brainwash: check "ps aux | grep <username>" after logout for leftovers?
[12:05] <brainwash> pitti: it's not my report, but I'll try to confirm it
[12:06] <brainwash> pitti: did you already take a look at the new dbus-monitor logs which got added to the logind suspend/resume report?
[12:06] <pitti> not yet, no
[12:08] <brainwash> this issue is causing way too trouble, we need to fix it asap :)
[12:08] <brainwash> because most users are forced to reboot their system, if they are not aware of any workaround
[12:12] <pitti> yeah, I know; I need to grab desrt, but I didn't reach him yesterday
[12:18] <seb128> pitti, he might not be back before a few days, he was taking some swap days for thanksgiving and travelling
[12:24] <pitti> seb128: ah, thanks for letting me know
[12:25] <seb128> pitti, yw
[12:39] <mati75> hello, I'm looking for sponsor this package: https://launchpad.net/~mati75/+archive/lubuntu/+sourcepub/3642755/+listing-archive-extra
[13:01] <tseliot> pitti: shall I also file bug 1248152 upstream?
[13:16] <pitti> tseliot: sorry, back from lunch
[13:19] <pitti> tseliot: followed up to the bug
[13:21] <tseliot> pitti: ah, thanks. Is the .new() method documented somewhere?
[13:22] <tseliot> pitti: as in when to use it
[13:23] <tseliot> pitti: as opposed to simply calling ClassName()
[13:23] <pitti> tseliot: it's rather that *not* using the _new() method isn't documented well
[13:25] <pitti> https://wiki.gnome.org/PyGObject/IntrospectionPorting#Constructors
[13:26] <pitti> tseliot: so, ^ usually you have the choice between a class' constructor (often there are several ones, like gtk_button_new_with_label), or a GObject constructor which you pass initial properties
[13:26] <pitti> and usually a class constructor should do nothing else than setting the properties from its arguments, but some classes violate that (like GtkFileChooserWidget)
[13:26] <pitti> in that case you have to use the real constructor
[13:27] <tseliot> pitti: so there's no way to know for sure until you try?
[13:28] <pitti> tseliot: calling the class constructor should always work
[13:28] <pitti> tseliot: calling the GObject constructor should work in most cases these days, but it seems you found a case where it doesn't
[13:28] <pitti> that part is worth a bugzilla report as it will also break e. g. loading from a GtkBuilder file
[13:29] <tseliot> pitti: are you going to file it yourself or shall I? (you definitely have more context to do it)
[13:29] <pitti> tseliot: so Gtk.FileChooserWidget(self, Gtk.FileChooserAction.SELECT_FOLDER) does not make any sense at all (both the self, and the positional flag argument), I'm currently checking why it doesn't raise an exception
[13:30] <pitti> tseliot: I can file it if you want
[13:30] <tseliot> pitti: yes please
[13:36] <pitti> tseliot: filed upstream bug for pygobject and linked to the LP bug
[13:36] <tseliot> pitti: great, thanks!
[13:58] <mhall119> slangasek: was one of them entered manually into summit
[13:58] <mhall119> ?
[13:59] <mhall119> slangasek: or was an old BP removed from Launchpad?
[14:00]  * mhall119 blames xnox either way
[14:03] <xnox> mhall119: yes, i manually entered into summit.
[14:04] <xnox> mhall119: do you have powers to delete the manual one?
[14:04] <mhall119> yes I do
[14:04] <mhall119> xnox: slangasek: done
[14:04] <xnox> mhall119: delete this one - http://summit.ubuntu.com/uds-1311/meeting/22017/transitioning-to-use-mdadm-by-default-for-some-of-the-fakeraid-devices/
[14:05] <xnox> mhall119: \o/ thanks.
[14:42] <pitti> cjwatson: OOI, why is dell-recovery on http://people.canonical.com/~ubuntu-archive/transitions/html/hal.html ?
[14:42] <pitti> cjwatson: it has Depends: udisks | devicekit-disks | hal (of course all of these are obsolete, but it shouldn't really pull in hal)
[14:43] <pitti> i. e. is that just a bug with alternative dependencies, or shouldn't hal be in the transition tracker in the first place?
[14:46] <cjwatson> pitti: *shrug* the config has .depends ~ /hal/
[14:46] <cjwatson> sorry, rather: .depends ~ /(^| )hal([ ,]|$)/
[14:46] <xnox> pitti: well the stanza for bad is ".depends ~ /(^| )hal([ ,]|$)/ " which is don't specify alternate "hal" dep.
[14:47] <xnox> snap.
[14:47] <cjwatson> pitti: you could just ignore it :)
[14:47] <cjwatson> I see dff still Recommends: hal
[14:56] <brainwash> the pulseaudio user process keeps the logind session alive after session logout, is this a known issue? I recall reading about this some time ago in this channel
[14:56] <brainwash> bug 1248137
[15:21] <tseliot> stgraber: why did you reject nvidia-prime for precise-proposed?
[15:23] <stgraber> tseliot: what? The only nvidia-prime related stuff I did today was release two SRUs into -updates, didn't do any rejecting
[15:24] <tseliot> stgraber: Rejected: nvidia-prime 0.4.2~hybrid0.0.1 in precise (source has no binaries to be copied)
[15:24] <stgraber> oh, that's LP, not me :)
[15:24] <stgraber> let me try and see what happened there
[15:25] <stgraber> tseliot: doh, I know what's going on, let me try to sort it out
[15:25] <tseliot> stgraber: thanks
[15:27] <stgraber> tseliot: basically it's one of those packages that got introduced post-release, so the binaries end up in New every time. Apparently nobody processed that one for some reason, so the testers grabbed the binaries straight from the librarian and the copy failed since the binaries weren't actually in -proposed
[15:27] <stgraber> tseliot: I just accepted the binaries into -proposed now and will retry a copy once that's published
[15:28] <tseliot> stgraber: oh, I see. Thanks for your help
[16:04] <tseliot> stgraber: also can you have a look at bug 1246735 when you have the time, please?
[16:06] <davmor2> tseliot: oooooohhh
[16:23] <tseliot> davmor2: yep :)
[16:29] <slangasek> mhall119: ta
[16:39] <barry> mitya57: hi :)
[16:50] <mitya57> hi barry!
[16:51] <mitya57> Actually I may leave soon, so if you have something long, please send mails instead…
[16:51] <barry> mitya57: thanks for helping out with coverage :)  i'd like to see how ben responds before we do the merge.  otoh, i suppose we can merge now and resync later based on his responses
[16:51] <barry> mitya57: naw, we can use email.  just wanted to say hey
[16:51] <mitya57> Yes, and if we don't merge now we can include the fix for debug packages when it's ready
[16:51] <barry> mitya57: yep
[16:53] <seb128> slangasek, what do you mean by "The GNOME stack should be handling the suspend suppression"?
[16:53] <slangasek> seb128: it's GNOME components that are responsible both for the reboot signal and the suspend trigger
[16:54] <slangasek> upstart has nothing to do with this
[16:54] <seb128> slangasek, do you call logind "GNOME components"?
[16:54] <slangasek> seb128: ah, is this not handled on the gnome-settings-daemon side?
[16:55] <slangasek> do we signal logind directly to request a reboot?
[16:55] <seb128> slangasek, that bug happens if you close your lid during shutdown, at a time where there is no session open
[16:55] <seb128> slangasek, e.g if you close the lid on the plymonth shutdown screen
[16:56] <seb128> slangasek, I'm not sure how a GNOME component could be still holding an inhibitor at this time
[16:56] <slangasek> seb128: ah, ok; I understood it as "close lid during shutdown while the session is still open but shutdown has been requested"
[16:56] <slangasek> if it's after the session has exited, then yeah, that's obviously a logind bug, so feel free to reassign
[16:56] <seb128> slangasek, no, and I can confirm that bug, I've the plymonth logo displayed for 5-10s here, if I close the lid during that time it goes to suspend
[16:56] <seb128> slangasek, doing that, thanks
[17:32] <rbasak> What are we supposed to do for the Maintainer field for Ubuntu-only packages in universe for new packages? I've seen it be "Ubuntu Developers" and also an individual person. Are we supposed to use one or the other?
[17:50] <xnox> rbasak: as long as it has "ubuntu.com" somewhere in the string it's fine. =)
[17:51] <xnox> rbasak: if it's the typical one the devel-discus mailing list, it's fine. If you put your email in there, you'll get upload notifications for it even if somebody else does the upload.
[17:53] <rbasak> xnox: thanks. I'm reviewing/sponsoring for someone else (@ubuntu.com), so just wanted to check that non devel-discuss was acceptable.
[17:53] <xnox> rbasak: yeah, anything is ok.
[17:55] <Laney> It doesn't mean they are the maintainer though
[18:07] <mati75> I have question where I can find sponsor for Ubuntu patched package?
[18:10] <TheLordOfTime> is someone here with permissions to approve a bug nomination for Saucy able to do so on https://bugs.launchpad.net/ubuntu/+source/nautilus-dropbox/+bug/1242413?
[18:10] <TheLordOfTime> it was requested in -bugs to get it nominated and set accordingly for an SRU, with a claim that this is already fixed in Trusty
[18:22] <ivanka> hi seb128 - you around?
[18:24] <seb128> ivanka-train, hey, yes
[18:25] <ivanka-train> seb128, How are you?
[18:25] <seb128> ivanka-train, I'm good thanks! How are you?
[18:25]  * ivanka-train has a question, of course
[18:26] <seb128> ivanka-train, I was expecting so ;-)
[18:26] <seb128> ivanka-train, let me guess, you upgraded to 13.10 and have an issue?
[18:27] <ivanka-train> seb128, I am very well
[18:27] <ivanka-train> seb128, you are so clever! :-)
[18:27] <seb128> ;-)
[18:27] <ivanka-train> seb128, my battery life has disappeared
[18:27]  * xnox is intrigued
[18:27] <seb128> ivanka-train, you mean the battery indicator?
[18:28] <ivanka-train> ivanka-train, no, i mean that I have gone from having a couple of hours of battery life to 19 minutes
[18:29] <ivanka-train> I mean seb128 ^
[18:29]  * ivanka-train has started talking to herself now
[18:29] <seb128> ivanka-train, is the estimation wrong or is your battery drained out like that?
[18:29] <seb128> ivanka-train, what's your CPU usage in top/gnome-system-monitor?
[18:31] <ivanka-train> seb128, it seems to get drained out
[18:31] <seb128> ivanka-train, check the cpu usage, just in case something max it out
[18:31] <ivanka-train> seb128, it looks like 10%
[18:31] <seb128> ivanka-train, if not, I would tend to say your battery is having hardware issues
[18:31] <seb128> ivanka-train, how old is the battery?
[18:32] <ivanka-train> seb128, it is a couple of years old but it seems a weird coincidence that it dies all of a sudden, no?
[18:32] <seb128> ivanka-train, you can click on the indicator -> battery line -> battery in the sidepane
[18:33] <ivanka-train> seb128, hmm - it looks like the capacity is down to 8%...how annoying!
[18:33] <ivanka-train> actually it is about to die now and I am on the train
[18:33] <ivanka-train> seb128, I am going to drop off rudely
[18:33] <seb128> ivanka-train, looks like an hardware issue, battery to get buggy like that
[18:34] <ivanka-train> seb128, thanks for your help - I will check out a new battery and report back
[18:34] <seb128> ivanka-train, the Ubuntu upgrade is probably a coincidence timing
[18:34] <seb128> ivanka-train, good luck
[18:34] <seb128> ivanka-train, have a nice evening!
[18:34] <jtaylor> is it worth filing bugs for crashes when /tmp is not writable?
[18:34] <ivanka-train> seb128, thank you!
[18:34] <jtaylor> a collegue somehow made it read only and lots of unity related stuff just crashed
[18:34] <jtaylor> e.g. unity-scope-loader, firefox due to the menu integration (probably) etc.
[18:35] <seb128> jtaylor, not really worth it, code could handle a buggy system better (same as no space on disk) but in reality that's still a buggy system
[18:35] <jtaylor> but I guess non writeable /tmp is unusual
[18:35] <seb128> jtaylor, e.g you can file those but I expect they are not going to be ranked high on priority lists
[18:37] <jtaylor>  /tmp is cleared on boot in ubuntu, shouldn't it also restore permissions on boot?
[18:37] <xnox> ivanka-train: you can try this drain the battery until it will not turn on, leave it off and fully charge for e.g. 3 hours. Perform that 3 times. It should recover and make battery capacity increase.
[18:37] <jtaylor> it was owned by some random user with 700
[18:37] <seb128> xnox, you missed her it seems
[18:37] <xnox> =(
[18:38] <seb128> xnox, how much do you expect those charge cycles to change things?
[18:39] <seb128> jtaylor, /etc/init/mounted-tmp.conf
[18:43] <jtaylor> so thats no it should not reown the folder?
[18:44] <seb128> jtaylor, I'm not sure what it's supposed to do, the upstart job reacts on tmp being "mounted" it seems ...
[18:45] <seb128> jtaylor, I guess you need somebody from foundations to reply to that question, e.g maybe xnox knows ;-)
[18:45] <jtaylor> so far I see the script will overlay a working tmp if its full, but not if the permissinos are wrong
[19:09] <Serus> Hi
[19:12] <Serus> Can I import a keyboard map from my raspberry pi? my current maps are a tiny little bit different from what I want
[19:14] <sladen> Serus: what operating system are you running on the Raspberry Pi?
[19:14] <Serus> raspbian
[19:14] <sladen> Serus: if it is something Linuxy (very likely) then somewhere it will be using kernel and X keymaps, which is the same as Ubuntu (based on Debian) uses under the hood
[19:15] <Serus> raspbian is also based on debian
[19:15] <sladen> Serus: Raspbian is based on Debian too.  What is the keymaps you are wanting to import called?
[19:15] <Serus> Dutch - US international
[19:16] <Serus> the English (US) - US international behaves different
[19:16] <Serus> for example I now do this when I try to type "I'm"
[19:16] <Serus> I´m
[19:16] <Serus> Iḿ*
[19:17] <Serus> Which is pretty annoying, since I switch between windows and ubuntu. And it's even more annoying when programming.
[19:18] <sladen> Serus: in Ubuntu, open "system settings"; type 'keyboard', click 'Keyboard layout', click [+] (bottom left), type 'Dutch', select "Dutch US international" from the list (if it is there)
[19:19] <Serus> It's not there.
[19:19] <Serus> Running ubuntu 12.04
[19:19] <Serus> Should I do a dist upgrade
[19:19] <sladen> Serus: no, hold on
[19:20] <Serus> Ok
[19:22] <sladen> Serus: apologies, need to re-aquint myself with where keyboard layouts are kept
[19:22] <Serus> /usr/share/
[19:23] <Serus> /usr/share/X11/xkbd
[19:23] <Serus> /usr/share/X11/xkbd/symbols *
[19:25] <sladen> Serus: yes, thankyou.  They are from the 'xkb-data' package
[19:26] <Serus> That one is installed
[19:27] <sladen> Serus: dpkg -l xkb-data   on Raspbian, what version is shown?
[19:27] <sladen> Serus: on ubuntu 12.04 LTS, you probably have 2.5-1ubuntu1.3?
[19:28] <Serus> I need to setup my ssh server on the raspberry pi with a few new keys for ubuntu
[19:28] <Serus> yes, thats the version I have on ubuntu
[19:29] <Serus> If you give me a moment, I reboot into windows and see what version I have on the pi
[19:29] <Serus> brb
[19:36] <Serus> Ok I'm in windows now
[19:36] <Serus> Only now my sound is gone O.o
[19:39] <sladen> Serus: btw, you can copy your existing ssh private keys from the windows partition to ~/.ssh/
[19:39] <sladen> Serus: in Ubuntu
[19:39] <Serus> they are putty keys
[19:39] <Serus> will they work?
[19:43] <sladen> Serus: use puttygen to convert them to the standard format
[19:44] <Serus> Export OpenSSH key right?
[19:45] <sladen> Serus: if you're already back in Ubuntu;   sudo apt-get install putty   then run 'puttygen foo.ppk -O private-openssh -o foo_private
[19:45] <Serus> I'm still in windows
[19:46] <sladen> Serus: http://84kids.com/how-to-convert-your-putty-key-to-openssh-format/  this suggests that under MS Windows  puttygen is GUI, and that there is a Tools->Export OpenSSH key menu
[19:47] <Serus> Yeah I did that
[19:48] <Serus> Ok, I'll go back to ubuntu
[19:48] <Serus> brb
[19:52] <Serus> Ok I'm back
[19:56] <sladen> Serus: any how; either manually copy+add your desired keyboard layout; or find a newer .deb containing the Dutch US int layout
[19:56] <Serus> ok
[19:56] <sladen> Serus: did you find out what version you had on the Pi?
[19:57] <Serus> Yeah, I'll check it
[19:57] <Serus> because I saw it on windows, but now I'll copy+paste it
[20:05] <Serus> Ok I'm finally in
[20:05] <Serus> ii  xkb-data       2.5.1-3      all          X Keyboard Extension (XKB) config
[20:06] <Serus> that's the output on the raspberry pi
[20:20] <sladen> Serus: is (on Rasbian), "Dutch US International" (exactly that string) available in the GUI
[20:20] <sladen> Serus: I've installed a new xkb-data on an Ubuntu 12.04 LTS machine, and not (yet) made it come up
[20:21] <Serus> not (yet) made it come up?
[20:21] <sladen> Serus: I have not yet made "Dutch US International" appear as an available option in the keyboard configuration
[20:22] <Serus> well Iḿ used to selecting a language and then selecting a layout for that language.
[20:22] <Serus> Which makes the layout behave slightly different.
[20:22] <sladen> Serus: in the console?  Or the GUI?
[20:23] <Serus> I used raspi-config from the console. But for some reason that won't work from ssh on ubuntu
[20:23] <hallyn_> tjaalton: around?
[20:24] <Serus> let me try via remote desktop
[20:24] <sladen> Serus: do you mean "raspi-config" won't work over SSH;  or you make a selection but it doesn't make a difference over SSH?
[20:24] <Serus> it won't work over ssh
[20:24] <sladen> Serus: do you mean "raspi-config" won't work over SSH;  or you make a selection but it doesn't make a difference over SSH?
[20:26] <Serus> I don't get to see the screen where I can select a keyboard layout
[20:26] <sladen> Serus: if it is the first; what error does it show.  If it is the second, it is probably because the keyboard configuration is the one of the MS Windows/Ubuntu
[20:27] <sladen> Serus: do you get the command prompt back?
[20:27] <Serus> yes
[20:28] <Serus> I get the message that it's loading keymaps
[20:28] <Serus> and then it stopts
[20:28] <sladen> Serus: are you running 'sudo raspi-config'  or just  'raspi-config'
[20:28] <Serus> stops*
[20:28] <Serus> sudo raspi-config
[20:29] <tjaalton> hallyn_: sorry, forgot to check the fbtfs..
[20:29] <tjaalton> ftbfs
[20:29] <Serus> It also happens over RDP
[20:29] <Serus> guess I'll reboot it
[20:30] <hallyn_> tjaalton: near as I can tell it should just need libxext-dev in build-deps
[20:30] <hallyn_> why it gets pulled in automatically on x86 i'm not sure
[20:31] <Serus> Also it could've been loading the windows keymap
[20:38] <tjaalton> hallyn_: ok, i'll investigate a bit and fix it, thanks for testing
[20:46] <hallyn_> tjaalton: thanks.
[22:18] <utlemming> is there a definitive place to look up info on cgroups? i.e. all the things that it can do?
[22:19] <infinity> utlemming: Ask Lennart, obviously.  According to him, no one else understands them.
[22:19] <infinity> (But, more seriously, stgraber and hallyn might be able to point you at some decent writeups/docs/whatever)
[22:19] <infinity> stgraber: ^
[22:20] <stgraber> ;)
[22:20] <stgraber> utlemming: most documentation is in the kernel tree, there's typically a .txt file per controller listing all the keys and valid values
[22:20] <stgraber> utlemming: https://www.kernel.org/doc/Documentation/cgroups/
[22:51] <hallyn_> infinity: so fwiw the patchset applies cleanly on top of trusty's package.  I'm first going to build and test that with no aarch64 target actually enabled - though our testsuites don't do much if any lniux-user testing (hm).  then i'll enable the aarch64 arch and see how that goes
[22:51] <hallyn_> (over next few days)
[22:56] <infinity> hallyn_: Awesome, thanks.
[22:56] <infinity> hallyn_: Bonus points if you push those changes to Debian too, so they don't have to do it all over again.
[22:56] <infinity> hallyn_: (And so we agree on pathnames and such)
[22:57] <hallyn_> infinity: yeah i'll talk to mjt after testing
[22:57] <hallyn_> (now, off to dinner.)