=== ycheng-afk is now known as ycheng
=== timrc is now known as timrc-afk
=== neunon_ is now known as neunon
[04:54] <pitti> Good morning
[04:55] <pitti> mapreri: scribus> nice!
[04:56] <pitti> mapreri: synced
=== timrc-afk is now known as timrc
=== timrc is now known as timrc-afk
=== ycheng is now known as ycheng-brb
=== ycheng-brb is now known as ycheng
[08:38] <mapreri> pitti: thanks! :D
[08:39] <mapreri> pitti: I didn't think your backlog goes so far in the past (I limited mine to 1000 rows, and this channel produces a lot more in 4-5 days..) :) I was about to email you ??
[08:39] <mapreri> ^^ *
[08:41] <pitti> mapreri: I just keep the entire backup, it was just since Thursday evening (I was off on Friday)
[08:42] <mapreri> pitti: out of curiosity: what bnc do you use? (I use znc)
[08:43] <pitti> mapreri: I recently moved to bip, znc stopped working for no apparent reason with freenode ("failed to connect")
[08:44] <mapreri> ok
[08:50] <pitti> stgraber, hallyn_: do we still need http://paste.ubuntu.com/7829207/ for systemd/logind 208? now systemd-shim and cgmanager do the cgroups creation, so I suppose that takes care of this?
[08:51] <pitti> stgraber, hallyn_: that patch doesn't work as-is any more anyway, /etc/systemd/{system,user}.conf now have a JoinControllers
[08:54] <stgraber> pitti: can you get me the post-login output of /proc/self/cgroup on a system with systemd/logind 208 using cgmanager and without this patch?
[08:54] <stgraber> pitti: should be easy to figure out whether we need something like this patch or not with that output
[08:56] <pitti> stgraber: http://paste.ubuntu.com/7829223/
[08:56] <pitti> stgraber: systemd-208pitti1, cgmanager running, running upstart
[08:57] <stgraber> pitti: looks good, so if that's what we get without the config, then we don't need it
[08:57] <pitti> stgraber: that doesn't have any of our Ubuntu patches
[08:57] <pitti> stgraber: cool, thanks for confirming!
[08:57] <pitti> stgraber: I'd like to get in 208 soon, to fix bug 1343802
[08:57] <ubottu> bug 1343802 in systemd (Ubuntu) "Installation of cgmanager prevents booting with systemd" [High,Triaged] https://launchpad.net/bugs/1343802
[09:06] <xnox> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox
=== ycheng is now known as ycheng-afk
[09:16] <darkxst> hey xnox, can you take a look at bug 1343815 during your shift
[09:16] <ubottu> bug 1343815 in gnome-bluetooth (Ubuntu) "Introspection of GnomeBluetooth.Column is broken" [Undecided,New] https://launchpad.net/bugs/1343815
=== Ursinha-afk is now known as Ursinha
[10:26] <norbert> is it possible to make a simple rename request here related to the description of a package maintained by the "Ubuntu Core Developers"?
[10:29] <xnox> norbert: well, what specifically are you after? which package?
[10:29] <norbert> xnox: http://packages.ubuntu.com/trusty/nvidia-current says "Transitional package for nvidia-current" (try apt-cache search nvidia-current yourself, to see the description), which is a circular description; it should say "[...] for nvidia-304"
[10:30] <cjwatson> sarnold: Any progress on the librevenge MIR?
[10:31] <xnox> norbert: yeah that's a bit odd. Can you please open the bug with " $ ubuntu-bug nvidia-graphics-drivers-304 " and then give me the bug # here? I'll assign it to the right person to look into.
[10:35] <norbert> xnox: I cannot, because I don't need nvidia-304
[10:35] <norbert> it's just something I noticed
[10:35] <xnox> norbert: it should file the bug, wheather that package is installed or not.
[10:35] <xnox> norbert: or open one manually via launchpad url.
[10:36] <norbert> what I needed was nvidia-331, therefore I had to figure out if nvidia-current was what I needed - it wasn't
[10:36] <norbert> no, it says "The problem cannot be reported: The report belongs to a package that is not installed."
[10:36] <xnox> darn.
[10:36] <norbert> so, <norbert> is it possible to make a simple rename request here related to the description of a package maintained by the "Ubuntu Core Developers"?
[10:37] <norbert> instead of having to go through whatever trouble (launchpad or whatever) I might need to otherwise :)
[10:37] <norbert> I have tons of bugs to report
[10:37] <norbert> it just always takes so much time
[10:37] <norbert> mostly because I'm constantly being referred to other projects/places
[10:38] <xnox> norbert: well, using another human to file bugs for you via irc in total takes even more time, don't you think?
[10:38] <norbert> no, I don't
[10:38] <norbert> it did this time, though
[10:38] <norbert> anyways, it's not an important issue, maybe one day someone will fix it
[10:38] <norbert> good day :)
[10:38] <xnox> norbert: filed as https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-304/+bug/1346187
[10:38] <ubottu> Ubuntu bug 1346187 in nvidia-graphics-drivers-304 (Ubuntu) "nvidia-current has recursive description" [Undecided,New]
[10:38] <xnox> norbert: subscribe if you want.
[10:38] <xnox> *sigh*
[11:55] <doko> jamespage, do you see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754859 with the new ceph?
[11:55] <ubottu> Debian bug 754859 in ceph "ceph command hangs in Jessie after update (python 2.7.8 suspected)" [Important,Open]
=== MacSlow is now known as MacSlow|lunch
[12:17] <ansgar> Hi, I want dune-grid/ppc64el and its rdepends removed. The new version depends on libalberta-dev which doesn't built on ppc64el.
[12:18] <ansgar> (as it build-depends on clang on powerpc due to gcc not able to do constant-folding for long doubles.)
=== _salem is now known as salem_
=== anthonyf` is now known as anthonyf
[12:26] <xnox> hm, we don't have clang on ppc64el.....
[12:28] <xnox> right ELFv2 ABI patches needed.
[12:32] <xnox> ansgar: filed https://bugs.launchpad.net/ubuntu/+source/dune-grid/+bug/1346252 subscribed Ubuntu Archive Admins to action.
[12:32] <ubottu> Ubuntu bug 1346252 in dune-grid (Ubuntu) "RM bin dune-grid/ppc64el only, build-depends on missing clang/llvm" [Medium,Triaged]
[12:46] <ansgar> xnox: Thanks.
=== MacSlow|lunch is now known as MacSlow
[12:59] <bluesabre> xnox: what are the requirements for adding packages to the xubuntu packageset?  I found a few shipped by xubuntu, but not included in the packageset (https://lists.ubuntu.com/archives/devel-permissions/2014-July/000702.html)
[13:00] <bluesabre> or, they didn't appear to be when I searched for the set
[13:00] <Laney> bluesabre: We got the mail, It'll get sorted.
[13:00] <bluesabre> Laney: ok, thanks.
[13:00] <Laney> s/,/./
[13:00] <Laney> Will poke at DMB stuff after lunch
[13:00]  * Laney afk
[13:03] <xnox> bluesabre: mailing devel permissions is the right way. Just wait for DMB member to process / acknowledge / comment on the requests.
[13:03] <xnox> bluesabre: for newly approved packageset it takes time to get them in the right order. You are the first with upload rights into it, after all.
[13:04] <bluesabre> ok, just wanted to verify.  I know that things can get lost over the weekend :)
[13:11] <pitti> stgraber, hallyn_: FYI, I filed bug 1346199 to test systemd 208 with the new cgmanager/shim
[13:12] <ubottu> bug 1346199 in systemd (Ubuntu) "Needs testing in -proposed: systemd 208" [High,In progress] https://launchpad.net/bugs/1346199
[13:12] <pitti> feedback appreciated!
[13:21] <hallyn_> pitti: great, I'll test on a few vms
[13:21] <pitti> hallyn_: I have it running on my workstation and clean utopic VM, and now on the phone
[13:37] <pitti> stgraber: I now tested them with system-level containers; I'd appreciate if you could test them with user-level containers too
[13:39] <stgraber> pitti: sure, let me setup a VM (not feeling like dist-upgrading my laptop thousand of km away from home and hours before I'm on vacation :))
[13:40] <pitti> stgraber: oops sorry, didn't know that
[13:40] <pitti> stgraber: enjoy your vacation!
[13:40] <stgraber> pitti: thanks. I'm still working for the next 2 hours or so, should be plenty of time to test all that in a VM
=== jpds_ is now known as jpds
[13:42] <pitti> jodh, hallyn_: do you know why test_util_check_env failed the "cgroup sandbox" test in https://jenkins.qa.ubuntu.com/job/utopic-adt-upstart/66/ARCH=i386,label=adt/consoleText ?
[13:42] <pitti> jodh, hallyn_: could this be because systemd-shim now pulls in cgmanager, and previous tests thus didn't run with cgmanager?
[13:42] <pitti> (null):dbus_error.c:69: Unhandled error from nih_dbus_error_raise: invalid request
[13:44] <hallyn_> pitti: hm, not sure.  will have to look at the testcase
[13:50] <jodh> hallyn_, pitti: looks like the non-priv test is not running in a logind cpuset cgroup and is trying to create a top-level cgroup.
[13:57] <hallyn_> jodh: still collecting all my morning data - do you have a link to the actual test source handy?
=== psivaa is now known as psivaa-afk
[13:59] <jodh> hallyn_: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/upstart/utopic/view/head:/test/tests/test_util_check_env.c
[14:00] <hallyn_> jodh: so what's the easiest way to have a cgroup created?  have the testcase ssh to localhost?
[14:00] <hallyn_> or is there a root script that can do it for us?
[14:04] <jodh> hallyn_: I don't think the upstart tests should be managing that. Clearly, something changed in the env to now cause this test to fail in the jenkins env (works fine on the buildd's and locally). But, the test should prolly check to see if they are already in a cgroup and if not, print a warning and skip that test (as we do for overlayfs).
[14:05] <pitti> jodh, hallyn_: ah, that's relying on logind to create new cgroups?
[14:05] <pitti> jodh, hallyn_: so, it could be that this fails because systemd 208 in utopic-proposed completely changes that
[14:06] <hallyn_> pitti: changes it, but if it worked in 204 with stgraber's patch, then it shoudl still work now...  so my question remains, how did it previously get its own cgroup?
[14:06] <pitti> but merely installing systemd (it's not installed by default in the autopkgtest env, thus only if you depend on it) won't retroactively create cgroups for running sessions, so I don't quite see what changed there
[14:06] <hallyn_> right
[14:06] <pitti> hallyn_: I don't know, I'm afraid
[14:07] <pitti> the other bit that obviously changed recently is the addition of cgmanager to depends
[14:07] <pitti> so, let me run the upstart tests locally without -proposed
[14:07] <pitti> if they fail due to that, it's due to installation of cgmanager
[14:07] <pitti> if they succeed, it's due to the new systemd
[14:07] <pitti> (in both cases, "most likely")
[14:07] <hallyn_> oh, well, the test doesn't run if cgmanager isn't installed
[14:07] <hallyn_> so, that's what changed :)
[14:08] <pitti> ah!
[14:08] <hallyn_> jodh: so teh testcase could simply try 'cgm create memory xxx', and if that fails, say "sorry i'm not in my own cgroup; exit"
[14:08] <pitti> but upstart doesn't build- or test-depends on cgmanager
[14:08] <pitti> so it wasn't installed before
[14:08] <hallyn_> exactly
[14:08] <pitti> so upstart's test should fail in utopic (without -proposed)
[14:09] <pitti> I'll run it anyway to double-check
[14:09] <hallyn_> pitti: hm?  no, it shouldn't fail, it should see that cgmanager is not installed and not run.
[14:10] <pitti> hallyn_: oh right, as we don't install systemd-shim in these VMs, sorry
[14:10] <pitti> so adding cgmanager as a test dep should cause the failure then
[14:11] <hallyn_> yup
[14:17] <pitti> jodh, hallyn_: captured that in bug 1346337
[14:17] <ubottu> bug 1346337 in upstart (Ubuntu) "test_util_check_env "cgroup sandbox" test fails with cgmanager installed" [Undecided,New] https://launchpad.net/bugs/1346337
[14:18] <pitti> jibel: ^ FYI, upstart autopkgtest failure
[14:18] <hallyn_> jodh: are you going to add that check, or did you want me to?
[14:25] <xnox> hm, yeah. so upstart doesn't build well with cgroups support enabled, yet in the environment where cgroups setup is configured and denied.
=== barry` is now known as barry_
=== barry_ is now known as barry
[14:28] <xnox> hallyn_: pitti: ideally we'd want to be able to excercise that test though as autopackage test, instead of a unit test. yeah, it should gracefully skip then. and we'd manually run it e.g. as root to test that it does work with cgroups.
[14:28] <pitti> sounds good
[14:29] <hallyn_> the lxc tests auto-run as root;  could the upstart tests just run as root but then su to non-root to actually exec each test?
[14:29]  * hallyn_ should actually grab the source
[14:32] <jodh> hallyn_: feel free to tweak. imho, it's a bad idea to start hacking around with the dep8 tests unduly at this stage of the upstart project. Let's be clear - we still only run a subset of the DEP-8'able tests upstart provides due to infrastructure issues (such as running safely as root).
[14:33] <hallyn_> jodh: so you mean feel free to tweak to not run if we're not in the right cgroup?  is the right thing to do it in lp:upstart and let that push up, or to do it in the utopic package?
[14:33] <jodh> hallyn_: I guess that skip logic should be fine in lp:upstart and we can cherry-pick into ubuntu.
=== zyga is now known as zyga-snorkel
[14:35] <shadeslayer> ev: ping, https://errors.ubuntu.com/?user=kubuntu-bugs&period=month never seems to work
=== psivaa-afk is now known as psivaa
=== greyback is now known as greyback|away
[14:46] <ogra_> pitti, http://paste.ubuntu.com/7830102/ ... i wonder if there is a less intrusive way to suppress kern.log (pinging you because i know you used to merge everything into syslog initially)
[14:48] <ogra_> i suspect adding a 51-kern-override.conf that redirects to /dev/null would mean it still eats CPU cycles to process the log
[14:49] <pitti> ogra_: hm, could we rather drop them from syslog instead?
[14:49] <ogra_> we want to get rid of everything but syslog in touch
[14:50] <ogra_> so you only have to check two logs (androids logcat or ubuntus syslog)
[14:50] <pitti> ah, ok
[14:50] <pitti> ogra_: so, LGTM
[14:50] <ogra_> but yeah, if we could solve it on another level
[14:51] <ogra_> i wouldnt object and simply keep kern.log ... (i.e. if i dont have to maintain a hack because the distro package simply keeps them apart)
[14:51] <stgraber> ogra_: there's a much cleaner way to configure rsyslog to your needs
[14:51] <ogra_> stgraber, ah, tell me ...
[14:52] <ogra_> i was assuming there was, but the only thing i could think of was to redirect to /dev/null in a higher versioned override
[14:52] <ogra_> which surely wont suppress the processing
[14:52] <stgraber> ogra_: you can drop a file before 50-default.conf (say 40-touch.conf) which defines the targets you care about (copy/paste from -default.conf) and then ends with "*.* ~"
[14:52] <ogra_> ah, cool
[14:52] <stgraber> ogra_: "*.* ~" means, stop processing everything at this point
[14:52] <pitti> oh, nice
[14:52] <ogra_> thanks !
[14:52]  * ogra_ will just add it to lxc-android-config then
[14:52] <stgraber> I just happened to do some complex remote syslog config last night :)
[14:53] <ogra_> awesome :)
[15:03] <xnox> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== greyback|away is now known as greyback
[15:11] <stgraber> pitti: just to check, to try systemd on utopic I just need to pass init=/lib/systemd/systemd correct?
[15:12] <pitti> stgraber: correct
[15:13] <stgraber> pitti: I don't get the same /proc/self/cgroup as you do here...
[15:14] <pitti> stgraber: I gave you the output under upstart this morning
[15:14] <stgraber> pitti: ah right, well, we want this to be the same under both upstart and systemd
[15:15] <pitti> stgraber: ok, so we most likely need to use that JoinControllers= thing in /etc/systemd/system.conf?
[15:15] <stgraber> pitti: I guess so then, yeah
[15:16] <stgraber> pitti: anyway, rebooting back into upstart now to check that we haven't regressed unprivileged containers there at least :)
[15:16] <stgraber> (would be kind of neat if there was a magic "all" value for that which just gets all the controllers from /proc/cgroups and joins them all)
=== desrt|ses is now known as desrt
[15:22] <pitti> stgraber: so what did you do there, run a container under systemd as pid1? what's the "good" and "bad" condition, so that I can verify the change?
[15:22] <pitti> stgraber: (I suppose you'll be AFK any minute now)
[15:23] <stgraber> pitti: I'm currently testing an unprivileged container under upstart with the new logind using the shim, so far things look good on that front.
[15:23] <stgraber> pitti: if using systemd as pid1 instead this will just completely fail at the moment as the cgroup controllers aren't setup properly
[15:24] <stgraber> pitti: confirmed, unprivileged containers run fine with upstart as pid1 + logind 208. So we're at least not regressing things.
[15:25]  * stgraber reboots with systemd and will play with JoinControllers see if that does the trick
[15:25] <pitti> stgraber: at least that seems to be the most direct equivalent of the old logind option
[15:26] <stgraber> pitti: ok, so joincontrollers isn't what we want at all, that variable is to co-mount controllers and we certainly don't want to do that
[15:28] <stgraber> pitti: what we want is for the first pid of a user session to be added to all the cgroup controllers instead of just name=systemd
[15:34] <stgraber> pitti: actually, we should also set joincontrollers but to an empty value, to avoid systemd co-mounting cpu and cpuset which may be problematic in some cases (we've worked around it in cgmanager but I'd much rather we don't have to)
=== zyga-snorkel is now known as zyga
[15:43] <stgraber> pitti, hallyn_: summary sent by e-mail
[15:43] <pitti> stgraber: merci
[15:45] <rbasak> kentb: around? I'm looking at your debdiffs in bug 1343407 now, and have a few review comments. Want to do this now so we can get it landed ASAP?
[15:45] <ubottu> bug 1343407 in ipmitool (Ubuntu) "Add support for Dell PowerEdge 13G servers" [Undecided,Incomplete] https://launchpad.net/bugs/1343407
[15:46] <kentb> rbasak, sure
[15:46] <rbasak> kentb: so in no particular order as I'm just going through it now.
[15:47] <rbasak> kentb: in the changelog, you should probably refer to the actual file you added to debian/patches rather than just the directory.
[15:47] <kentb> ok
[15:47] <rbasak> That's useful for people doing future merges
[15:47] <kentb> right. makes sense.
[15:48] <rbasak> kentb: thank you for adding the dep-3 headers to the patch. Just a couple of minor corrections to that.
[15:48] <rbasak> Since this patch has been sent upstream but not submitted, it technically originates from the patch author, and not from upstream.
[15:48] <stgraber> hallyn_: oh, also, just noticed/win 50
[15:48] <kentb> rbasak, ah. ok. got it.
[15:49] <stgraber> oops, that was a mess, ignore that :)
[15:49] <rbasak> So we need to drop the Origin field, and a new Forwarded field should point to the upstream URL you referred to in the bug.
[15:49] <rbasak> kentb: other than that the patch file looks perfect, assuming it's identical to the patch forwarded upstream.
[15:50] <kentb> rbasak, ok. I'll fix that and post new debdiff in a bit.  Patch is identical to the upstream one.
[15:50] <rbasak> kentb: finally, for trusty, no need to fix Standards-Version. We just ignore that for SRUs since they need to be the minimal fix.
[15:50] <kentb> rbasak, ok. thanks for the review!
[15:51] <roadmr> hey folks! I'm seeing some strange behavior with the hwe stacks on 12.04.x. apt-get install glmark2-es2 on 12.04.4 works OK, but the same on 12.04.{2,3} wants to remove most of the pre-installed x packages (unless I manually install libegl1-mesa-lts-{raring,quantal})
[15:51] <rbasak> kentb: thanks. THat's everything so far - all very minor. One really really minor thing (don't bother changing it) is that starting the patch with 113 because it's the next available number will probably just confuse a future merge if Debian use 113 also.
[15:51] <kentb> ko
[15:51] <kentb> err ok
[15:51] <rbasak> kentb: I would just not bother with a number, or start it "ubuntu-" or something. But that's so minor I'm sure others will do something different and that's perfectly fine. The name doesn't really matter and I see that you were just trying to follow the pattern, which is reasonable.
[15:52] <roadmr> also, if I try to install a package which depends or recommends on glmark2-es2, I get either the "remove all existing hwe stack packages" problem, or failure to install due to unmet dependencies... so when glmark2-es2 is not a directly installed package, dependency resolution is having a bit of trouble
[15:52] <kentb> rbasak,  understood. thanks for the tip!
[15:53] <rbasak> kentb: I am happy to fix these up before test/upload if you like. No need for you to go round with a debdiff again.
[15:53] <kentb> rbasak, ok. go right ahead.
[15:53] <rbasak> ack
[15:54] <kentb> thanks!
=== Guest32427 is now known as mfisch
=== mfisch is now known as Guest60831
[15:56] <rbasak> kentb: ah, for the SRU to Trusty, we'll need the paperwork filled out in the bug. Instructions at https://wiki.ubuntu.com/StableReleaseUpdates#Procedure (step 3).
[15:57] <rbasak> kentb: do you mind doing that while I finish fixes/review/upload?
[15:58] <rbasak> kentb: the test case would probably just be an expanded version of "run X on 13G; success case: Y displayed; failure case: Z displayed".
[16:03] <kentb> rbasak, ok
[16:03] <kentb> rbasak, I'll work on that
[16:11] <kentb> rbasak, I'll have that posted in the next little while.  I need to head over to the Dell Linux lab and I'll finish up from there.
[16:12] <rbasak> kentb: OK, no problem.
=== Ursinha is now known as Ursinha-afk
[16:34] <roadmr> is there a way to say "I want the libgles2-mesa-lts-* package for whichever enablement stack I have installed" ? how can I programmatically determine which stack I have? Is there a cleverer way than some sort of mapping from installed point release (12.04.2,3,4) to which stack I have?
[16:39] <cjwatson> Anyone know what's up with the shotwell autopkgtest failure?
[16:39] <Laney> glib breaks it
[16:40] <cjwatson> Oh bother.  Is that fixable reasonably quickly?  It's holding up the libav transition now
[16:40] <Laney> I bisected and filed a bug upstream
[16:40] <Laney> in what way?
[16:40] <Laney> You could block glib + skip shotwell
[16:40] <cjwatson> causes gst-libav1.0 to be invalidated
[16:42] <Laney> Either do that or remove glib2.0 from propose
[16:42] <Laney> This upload ain't gettin in in any event
[16:43] <Laney> It did include some new symbols though
[16:44] <Laney> But it's got a symbols file so everything will have versioned dependencies and therefore wouldn't have migrated
[16:45] <sarnold> cjwatson: I've started the librevenge mir, I don't know if I'll be able to finish it today though
[16:47] <rbasak> kentb: oh, one more thing. Need to run "update-maintainer" to fix the Maintainer field according to https://wiki.ubuntu.com/DebianMaintainerField. I missed that and uploaded without. I won't worry about it except for next time.
[16:48] <cjwatson> Laney: pretty sure my transition is cursed
[16:48] <cjwatson> sarnold: thanks
[16:50] <Laney> cjwatson: I'd say remove glib2.0 if you want
[17:11] <cjwatson> Laney: ok, removed - do you think you could rebuild banshee and harfbuzz a bit later once glib2.0/utopic-proposed disappears from rmadison?
[17:12] <cjwatson> those are the two rdeps listed in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[17:25] <kentb> rbasak, ok.  I'm filling out sru stuff right now
=== roadmr is now known as roadmr_afk
[18:13] <j_f-f> Many thanks for doing my work
=== timrc-afk is now known as timrc
=== roadmr_afk is now known as roadmr
=== Ursinha-afk is now known as Ursinha
=== timrc is now known as timrc-afk
=== Ursinha is now known as Ursinha-afk
=== timrc-afk is now known as timrc
=== Ursinha-afk is now known as Ursinha
[20:49] <ari-tczew> is there any ppc64el PPA, where can I test building packages/ patches?
[20:49] <cjwatson> I'm afraid that that's only possible in devirtualised PPAs right now, which are only accessible to Canonical employees.
[20:49] <cjwatson> We can test-build fixes for you on request if need be
[20:50] <cjwatson> (Though not me just now - time to read bedtime stories)
[20:51] <ari-tczew> would be nice to make free one PPA for ubuntu developers with difficult archs like ppc64el, powerpc etc.
=== kentb is now known as kentb-out
=== salem_ is now known as _salem