[05:19] <pitti> Good morning
[05:29] <Unit193> Heya.
[05:44] <Unit193> Miiight be good to merge pbuilder, due to things like 788580? (Linked earlier.)
[06:15] <dholbach> good morning
[06:42] <TheMuso> bdrung: Had bug 1464913 filed against portaudio19... I thought things were supposed to be installable alongside either jack version. Am I missing something here?
[08:05] <pitti> wgrant: OOI, do you know how far we are with ppc64el scalingstack support?
[08:07] <wgrant> pitti: https://dogfood.paddev.net/builders/dogfood-bos01-p8-1/+history
[08:08] <wgrant> pitti: I pushed a few hundred builds through it over the weekend, and identified a few issues that we need to fix this week.
[08:08] <pitti> wgrant: oh, that sounds promising!
[08:08] <wgrant> I don't have a reliable ETA, but it should be just a few weeks at this point.
[08:08] <pitti> slangasek: ^ FYI (as we talked about it last week)
[08:09] <pitti> wgrant: I'm resurrecting my wolfe nodes for the umpteenth time now, which keeps reminding me about cloudifying those :)
[08:09] <wgrant> pitti: We're pretty close :)
[08:10] <pitti> wgrant: do you know about the status of armhf?
[08:10] <wgrant> pitti: Only two blocking issues have been identified with ppc64el. Then it's a matter of cleaning it up, getting the various fixes landed to charms and the distro, and redeploying it in a productiony way.
[08:10] <wgrant> pitti: arm64 hardware is in place, but the networking is still being sorted out.
[08:11] <pitti> wgrant: sounds like I should ask for scalingstack credentials nowish, to set it up for x86 testing and gain some experience with it
[08:11] <wgrant> The status of our OpenStack on arm64 is not well known, but it should work once we have a working ovmf.
[08:11] <zyga> pitti: hey, would you have the time to meet with me later today
[08:11] <zyga> pitti: I've sent you an invite
[08:11] <wgrant> I don't expect work to start on arm64 scalingstack until ppc64el is just about done.
[08:11] <wgrant> Best to focus on one thing at a time.
[08:11] <pitti> zyga: you mean later than the "in 50 mins" that my calendar says?
[08:12] <zyga> pitti: yes
[08:12] <zyga> pitti: no, not later :)
[08:12] <zyga> pitti: later when the schedule says
[08:12] <pitti> wgrant: right; there's lots for me to do to get x86 running, I'd like to start with that; I assume that's working reasonably well by now?
[08:12] <zyga> pitti: though we can move if you want :)
[08:12] <pitti> zyga: 11:00 works fine for me
[08:12] <zyga> pitti: thanks, I'll see you then
[08:12] <pitti> still sorting out the over-weekend backlog
[08:16] <wgrant> pitti: Yep, though there's probably not enough capacity right now to move the full load over. We'll be substantially boosting the capacity in the coming weeks as we move the x86 bare metal builders into scalingstack.
[08:17] <pitti> wgrant: ack, but for setting up the system and experimenting with it, getting two or three instances would suffice; is that possible?
[08:18] <pitti> wgrant: the controlling nodes and swift would be in prodstack anyway
[08:18] <wgrant> pitti: Yup, no problem with that at all. An RT can get you creds.
[08:20] <cjwatson> wgrant: Looks like you did a bunch of copies from trusty to vivid or something, which explains some of the weirder failures there?
[08:21] <wgrant> pitti: You'll need the ability to run against multiple scalingstack regions (we have two regions in London that do amd64 for both i386 and amd64, and soon to be a region in Boston that does separate ppc64el, powerpc and arm64/armhf instances.
[08:21] <wgrant> cjwatson: Which?
[08:21] <cjwatson> wgrant: partman-base, say, and possibly perl
[08:21] <wgrant> Ohhh
[08:21] <wgrant> I thought some of the failures were weird.
[08:22] <wgrant> --from-suite doesn't imply --to-suite in populate-archive, I guess.
[08:22] <cjwatson> I guess not ...
[08:23] <wgrant> Anyway, the main purpose of this test was to test the OpenStack setup.
[08:23] <wgrant> And it failed, so the test worked :P
[08:23] <cjwatson> What were the failures?
[08:24] <wgrant> vbuilder-manage fell over totally about 26 hours ago, not in any of the usual ways. I suspect a less intermittent form of the cloud flakiness we were seeing during early testing on Friday, but wasn't able to debug further today.
[08:24] <wgrant> And lots of builds have hung during build-dep installation, which may just be the virtio issue.
[08:24] <wgrant> But instance resets were at least reliable until the entire thing fell over.
[08:57] <xnox> pitti: anything i can do to debug bug 1465196 ?
[08:57] <xnox> Bug #1465196
[08:57] <xnox> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1465196
[08:57] <xnox> NetworkManager-wait-online job deleted to break ordering cycle
[08:58] <pitti> xnox: hm, is that the entire journal for this? there should be some more output showing the actual cycle
[08:58] <pitti> xnox: can you please attach the whole journalctl -b?
[08:59] <zyga-phone> Pitti: rebooting
[09:00] <pitti> zyga-phone: in HO now, but no hurry
[09:00] <xnox> pitti: like this? http://paste.ubuntu.com/11718410/
[09:00] <pitti> xnox: ex-actly
[09:00] <pitti> xnox: so, something in open-iscsi; odd, I thought I fixed these already
[09:00] <xnox> pitti: open-iscsi is the culprit?!
[09:01] <pitti> xnox: ah, maybe not open-scsi + NM
[09:01] <xnox> pitti: i have it installed.... but i'm not using it.
[09:01] <pitti> # Required-Start:    $network $remote_fs
[09:01] <pitti> xnox: right, same old -- rcS init scripts being overly demanding on $remote_fs
[09:01]  * xnox will just purge it.
[09:01] <pitti> that can't work with NM
[09:02] <pitti> xnox: thanks, will adjust the bug
[09:02] <xnox> pitti: do we keep init scripts installed, even when there is native systemd job for them? shouldn't we purge them?
[09:02] <xnox> .... i guess we should switch phone first, and release an lts.
[09:03] <pitti> xnox: meeting now, brb
[09:06] <pitti> xnox: yes, we keep the init scripts installed, but if there's a unit it gets ignored
[11:32] <pete-woods> MacSlow: hi, could you point me to the test plan you normally use when making changes to unity-notifications?
[11:33] <pete-woods> I
[11:33] <pete-woods> I've got a silo together, but can't find the test plan
[11:33] <MacSlow> pete-woods, I of course run the unit-test that come with it...
[11:34] <pete-woods> MacSlow: well obviously, but is there a CI train test plan for *integration* testing
[11:34] <pete-woods> ?
[11:34] <pete-woods> if not, I guess that's fine, I'll just try out a bunch of things that use notifications, e.g. indicator-network
[11:35] <MacSlow> pete-woods, and then there is the notification-related autopilot-tests and a bunch of manual tests I run locally or on the device (lp:unity-notifictaions/examples)
[11:35] <pete-woods> autopilot tests sound good
[11:35] <pete-woods> do you know where they live? I can't see them in the notifications source tree
[11:37] <MacSlow> pete-woods, the notifcation ap-tests live in the lp:unity8/tests/autopilot/unity8/shell/tests
[11:38] <pete-woods> MacSlow: cool, thanks!
[11:39] <MacSlow> pete-woods, you can restrict the ap-testruns to the notifications ones by doing "autopilot3 run unity8.shell.tests.test_notifications"
[11:39] <MacSlow> pete-woods, otherwise it takes ages to go through the whole suite
[11:40] <pete-woods> MacSlow: hmm, for some reason unity8-autopilot won't install on my phone
[12:16] <bdrung> TheMuso: good question.
[13:31] <jamespage> cjwatson, do you have a nice way of translating tags from bzr to git during a migration?  Seems I need to translate invalid characters in some way but can't figure out quite how
[13:36] <cjwatson> jamespage: In all the serious migrations I've done, I've used reposurgeon, which gives you a domain-specific language for applying whatever arbitrary transformations you like.
[13:36] <arges> hallyn: hey, bug 1464175 is in need of sponsorship. are you batching up libvirt updates? otherwise I can push this one
[13:44] <hallyn> arges: there is also https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1455608
[13:44] <arges> hallyn: yup, do you want me to merge and sponsor those?
[13:45] <arges> hallyn: or whatever would be more helpful for you
[13:46] <hallyn> arges: i think t and u still have pkgs awaiting verification, but ye splease i fyo umerge those that'd be great
[13:46] <arges> hallyn: ok will do
[13:46] <hallyn> thanks
[14:11] <dgadomski> hey pitti, could you please shed some light on how gvfs works? From what I see I suspect there is a single gvfsd-fuse filesystem mounted under /run/user/<uid>/gvfs and it can map all sorts of other "filesystems" (e.g. samba shares) as directories under that fuse, is that right?
[14:14] <seb128> dgadomski, it would help if you had specific questions, or stated what you try to achieve/figure out. On #ubuntu-desktop you asked a mtab question, which I replied to saying that pitti might know, but now you changed to ask about gvfs fuse handling, which is a different topic (pitti might still know but I'm less sure for that one)
[14:16] <dgadomski> seb128: alright, the reason for those question is to determine if it is possible to enable ACL on samba shares mounted via nautilus (i.e. gvfs)
[14:16] <LocutusOfBorg1> hi, can somebody from MIR team enlight me about bug 1461517 and bug 1464853?
[14:17] <dgadomski> seb128: for "normal" shares (e.g. mount.cifs) this could be done by passing the cifsacl option to mount
[14:17] <seb128> dgadomski, is your issue with real gvfs access through gio, or with the compat fuse mounnts?
[14:25] <dgadomski> seb128: that's what I'm trying to understand :) I don't entirely get how this works, but the scenario looks like this: 1. user opens a samba share with nautilus, 2. Opens a file there with e.g. gedit, which mechanism is used in that case? gio or the compat fuse mounts?
[14:26] <seb128> dgadomski, gedit = gio
[14:26] <seb128> but it you use e.g libreoffice it might be the fuse mount
[14:28] <dgadomski> seb128: so the actual problem is that the samba share the user want's to use has some ACL rules applied and I would like those acl rules to be respected when the share is mounted via nautlius just like it is if the user mounts it via mount.cifs -o cifsacl
[14:28] <seb128> dgadomski, is that bug impacting both gio and compat mounts?
[14:29] <dgadomski> seb128: yes, both mechanims seem to be acl-unaware
[14:30] <seb128> dgadomski, https://bugzilla.gnome.org/show_bug.cgi?id=623161 ?
[14:31] <seb128> hum, that bug is about windows though
[14:32] <seb128> dgadomski, is that specific to smb or with any protocole? like ssh
[14:33]  * smb is innocent
[14:33] <dgadomski> seb128: I did not try anything else beside smb, give me a sec
[14:37] <pitti> dgadomski: that's right; that's mostly a legacy program interface, i. e. CLI tools etc. which don't use GIO themselves
[14:37] <pitti> dgadomski: so you can e. g. attach an MTP mobile phone or a PtP camera and have a real fs for cp/mv/exiftran, you name it
[14:38] <slangasek> wgrant: "once we have a working ovmf" - ok, where are we at with /that/? :)  I saw a build failure of edk2 over the weekend, so somebody gave it back...
[14:38] <pitti> dgadomski: I don't know how well fuse works with ACLs
[14:38] <pitti> dgadomski: gedit, like all GNOME apps, uses GIO, not the fuse file system
[14:39] <dgadomski> thanks pitti, and is gio capable of working with ACLs?
[14:39] <pitti> dgadomski: I don't know
[14:39] <pitti> dgadomski: server-side ACLs should be totally transparent to the client
[14:39] <pitti> dgadomski: and client-side ACLs should not matter, as this is all per-user, not system-wide
[14:40] <pitti> dgadomski: so I don't quite understand what ACLs have to do with this
[14:45] <dgadomski> pitti: what if a user want's to modify ACLs on the server smb share?
[14:46] <pitti> dgadomski: that's the thing I'm not sure about -- i. e. if that's mapped through GIO
[14:46] <pitti> or if you need smbclient or a similarly specialized tool for that
[14:47] <dgadomski> pitti: one way to do it is to mount the share with mount.cifs -o cifsacl and use getfacl/setfacl or a GUI tool (like eiciel)
[14:50] <dgadomski> pitti: but those tools are unusable with GIO / gvfs fuse, so the question is: is there a possibility to enable it?
[14:51] <pitti> dgadomski: anything is possible, it's free software :) so it mostly depends on finding someone who is interested in adding this support
[14:52] <dgadomski> pitti: can you give me a hint which layer would be appropriate to implement such thing?
[14:53] <pitti> dgadomski: I support GIO for adding the general set/get ACL API, and gvfs' smb-browse module for implementing it for samba/CIFS
[14:55] <dgadomski> pitti: sounds like quite amount of work, thanks for the info
[15:10] <LocutusOfBorg1> mterry, are you sure about fix-double-parsing.patch?
[15:11] <mterry> LocutusOfBorg1, not 100% but the code that it changes is still there in debian
[15:12] <mterry> LocutusOfBorg1, and that patch is relatively recent -- it wasn't in our packaging back when Debian grabbed all our changes
[15:12] <LocutusOfBorg1> oh I see
[15:12] <LocutusOfBorg1> yes, right
[15:12] <LocutusOfBorg1> I checked, but I made a mistake
[15:14] <LocutusOfBorg1> so mterry while you are merging it, do you think for a MIR having the symbols file is a must=
[15:14] <LocutusOfBorg1> ?
[15:14] <LocutusOfBorg1> I need that package into main, because cmake 3.2.2 is waiting for it
[15:14] <mterry> LocutusOfBorg1, not a must, just a strong preference.  But I see the comments about upstream checking ABI
[15:14] <mterry> LocutusOfBorg1, that's what brought me to your sync bug
[15:15] <mterry> LocutusOfBorg1, I'll try to sort this today
[15:15] <LocutusOfBorg1> ok, so if we can forward the patch to Debian we can just sync on the next run
[15:16] <LocutusOfBorg1> (I would like to avoid maintaining a delta there)
[15:16] <LocutusOfBorg1> specially because symbols have been dropped here http://anonscm.debian.org/cgit/collab-maint/libjsoncpp.git/commit/?id=21f33b218735398db17c50e09b46d7fefa39bec8
[15:16] <mterry> LocutusOfBorg1, agreed, deltas suck
[15:21] <LocutusOfBorg1> I sent a mail with the patch to Peter
[15:27] <mterry> LocutusOfBorg1, oh, OK.  I would have used submittodebian when I'm done merging, but that works too.  Was it a debian bug or just an email to him directly?
[15:28] <LocutusOfBorg1> direct mail, but feel free to open a bug
[15:28] <dobey> LocutusOfBorg1: is that my patch?
[15:28] <LocutusOfBorg1> I wasn't aware of the submittodebian tool, how does it work=
[15:28] <LocutusOfBorg1> yes dobey
[15:29] <Mirv> Qt 5.4.2 is now in wily, but will be blocked from migration due to existing KF5 autopkgtests failures
[15:30] <dobey> LocutusOfBorg1: if it still applies it is still relevant, yes. i intended to push it upstream, but i my have been really busy, had difficulty finding where exactly to submit it upstream, and totally forgotten about it
[15:30] <LocutusOfBorg1> dobey, https://github.com/open-source-parsers/jsoncpp
[15:30] <LocutusOfBorg1> they moved to github :)
[15:31] <dobey> LocutusOfBorg1: ah ok, thanks
[15:32] <mterry> LocutusOfBorg1, oh submittodebian is just a little helper for when you're patching ubuntu (or doing a merge with patches) and will automatically open a bug and submit a patch for you (with chances to explain/edit the patch)
[15:32] <dobey> LocutusOfBorg1: i'll see about getting that upstream then, but we do need to keep that patch around
[15:32] <LocutusOfBorg1> so I can't use it :(
[15:32] <LocutusOfBorg1> yes dobey, I hope Peter will merge it in Debian, and then we can sync it (and forget)
[15:33] <dobey> ok
[15:33] <dobey> well, now i need to get lunch. :)
[15:39] <LocutusOfBorg1> have fun!
[15:42] <LocutusOfBorg1> so mterry please use the submittodebian tool then, I would prefer a bug instead :)
[15:42] <LocutusOfBorg1> and thanks for the hard work
[15:43] <mterry> LocutusOfBorg1, my pleasure.  I like converging on no deltas  :)
[15:43] <mterry> LocutusOfBorg1, I've got other work I'm in the middle of, but will try to finish this stuff out / review the MIR today
[15:44] <LocutusOfBorg1> thanks! I started working in Debian to avoid deltas, and now I'm mostly a DD
[15:44] <LocutusOfBorg1> I hope to become an ubuntu developer soonafter DAM processes my nm application
[16:10] <mterry> LocutusOfBorg1, oh nice  :)
[16:48] <arges> hallyn: was trying to verify bug 1425619, but looks like the patch to qemu/trusty got dropped.
[16:48] <arges> hallyn: so we'll need to re-apply the patches for qemu before verifying that one before verifying libvirt etc...
[17:11] <arges> hallyn: i can re-apply that patch and push an update
[17:15] <hallyn> arges: great, thanks
[17:15] <hallyn> wonder how i dropped that
[17:26] <arges> hallyn: i think the security update overrode it
[17:27] <arges> anyway test building
[17:29] <hallyn> ah, ok
[18:24] <Mirv> FYI I'm running Plasma 5 just as good after the Qt 5.4.2 update as before. it seems the same KF5 5.10.0 autopkgtests fail as have failed since the 5.10.0 was uploaded, but now the transition is starting to block non-Kubuntu packages too. if there's someone available from Kubuntu during my sleep hours please discuss how to migrate to release pocket.
[18:26] <Mirv> the list of autopkgtests is at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src - maybe the failing kf5 5.10.0 packages could be overridden
[18:28] <Mirv> (running Plasma 5 == running wily-proposed versions of Qt 5, KF5 etc)
[21:29] <arges> hallyn: /quit
[21:29] <arges> whoops
[22:24] <ScottK> Any idea why http://www.ubuntu.com/legal claims the Canonical contributor agreement is needed " before you begin contributing to Ubuntu"?
[22:24] <ScottK> Seems wrong.
[22:26] <lifeless> define contribution I guess?
[22:26] <lifeless> submitting code to Canonical repositories vs running an ubuntu user group vs patching debian packages to work better on ubuntu...
[22:26] <ScottK> For anything that's Ubuntu (the Linux distribution) such a thing isn't needed.
[22:27] <ScottK> I'd buy if it said something like ... some aspects of ...
[22:27] <lifeless> sure
[22:27] <ScottK> As it is, it's plain wrong.
[22:28] <lifeless> just like some packages require CLAs and patches to them ned to be done directly upstream (or be debt forever)
[22:28] <ScottK> Some upstreams require CLAs.
[22:28] <ScottK> Ubuntu the distro doesn't.
[22:28] <ScottK> Unfortunately, the term Ubuntu is so overloaded it's almost meaningless.
[22:45] <infinity> ScottK: Yeah, the wording there is clearly too broad.  Needs to be vague with something like "before contributing to certain Canonical projects" and a link to the list.
[22:45] <infinity> slangasek: ^-- Can you sort out who to escalate that to?
[22:46] <slangasek> infinity: can you file a bug against https://bugs.launchpad.net/ubuntu-website-content ?
[22:46] <infinity> slangasek: Sure.
[22:50] <infinity> https://bugs.launchpad.net/ubuntu-website-content/+bug/1465430
[22:50] <infinity> slangasek: ^
[22:50] <infinity> Err, really, why is that private by default?
[22:51] <infinity> There.
[22:51] <infinity> ScottK: ^ does that look like an appropriate appraisal of the situation to you?
[22:51] <ScottK> Thanks.
[22:51]  * ScottK looks
[22:51] <sarnold> everything on the website is private by default :/ it's annoying to try to file bugs on behalf of others that way :(
[22:52] <ScottK> infinity: Perfect.
[23:23] <wgrant> slangasek: RT is still a total mess due to the PS4 debacle, so I'm reluctant to throw a bare metal sbuild upgrade ticket at it. If it becomes a blocker, we can build it in a PPA and copy it in.
[23:25] <sladen> sarnold: +1
[23:34] <infinity> wgrant: It's a 1-line hack to make the old sbuild build edk2, we could just get someone to cowboy one of the nonvirts. :P
[23:34] <infinity> wgrant: But I also assume we'll want it backported to the cloud archive.
[23:39] <slangasek> wgrant: ok
[23:45] <infinity> slangasek: Hrm, I see pesign in the queue synced from Debian.  Should we be looking to replace sbsigntool?
[23:46] <slangasek> infinity: AFAIK the only benefit of pesign over sbsigntool is nss, which is a questionable benefit
[23:47] <infinity> slangasek: I would assume the other benefit is active maintenance.
[23:47] <slangasek> infinity: I'm happy to revisit that question when someone points to an actual feature we're missing out on :)
[23:47] <infinity> slangasek: Oh, and no dep on gnu-efi, which means it builds on more arches.  Like ARM/ARM64.
[23:48] <infinity> slangasek: arm64 support might be the killer feature.