/srv/irclogs.ubuntu.com/2015/06/15/#ubuntu-devel.txt

=== Cydrobolt is now known as cydrobolt
=== anthonyf is now known as Guest37830
pittiGood morning05:19
Unit193Heya.05:29
Unit193Miiight be good to merge pbuilder, due to things like 788580? (Linked earlier.)05:44
dholbachgood morning06:15
TheMusobdrung: Had bug 1464913 filed against portaudio19... I thought things were supposed to be installable alongside either jack version. Am I missing something here?06:42
ubottubug 1464913 in portaudio19 (Ubuntu) "portaudio19-dev can't be installed without conflicts " [Undecided,New] https://launchpad.net/bugs/146491306:42
pittiwgrant: OOI, do you know how far we are with ppc64el scalingstack support?08:05
wgrantpitti: https://dogfood.paddev.net/builders/dogfood-bos01-p8-1/+history08:07
wgrantpitti: 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
pittiwgrant: oh, that sounds promising!08:08
wgrantI don't have a reliable ETA, but it should be just a few weeks at this point.08:08
pittislangasek: ^ FYI (as we talked about it last week)08:08
pittiwgrant: I'm resurrecting my wolfe nodes for the umpteenth time now, which keeps reminding me about cloudifying those :)08:09
wgrantpitti: We're pretty close :)08:09
pittiwgrant: do you know about the status of armhf?08:10
wgrantpitti: 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
wgrantpitti: arm64 hardware is in place, but the networking is still being sorted out.08:10
pittiwgrant: sounds like I should ask for scalingstack credentials nowish, to set it up for x86 testing and gain some experience with it08:11
wgrantThe status of our OpenStack on arm64 is not well known, but it should work once we have a working ovmf.08:11
zygapitti: hey, would you have the time to meet with me later today08:11
zygapitti: I've sent you an invite08:11
wgrantI don't expect work to start on arm64 scalingstack until ppc64el is just about done.08:11
wgrantBest to focus on one thing at a time.08:11
pittizyga: you mean later than the "in 50 mins" that my calendar says?08:11
zygapitti: yes08:12
zygapitti: no, not later :)08:12
zygapitti: later when the schedule says08:12
pittiwgrant: 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
zygapitti: though we can move if you want :)08:12
pittizyga: 11:00 works fine for me08:12
zygapitti: thanks, I'll see you then08:12
pittistill sorting out the over-weekend backlog08:12
wgrantpitti: 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:16
pittiwgrant: ack, but for setting up the system and experimenting with it, getting two or three instances would suffice; is that possible?08:17
pittiwgrant: the controlling nodes and swift would be in prodstack anyway08:18
wgrantpitti: Yup, no problem with that at all. An RT can get you creds.08:18
cjwatsonwgrant: Looks like you did a bunch of copies from trusty to vivid or something, which explains some of the weirder failures there?08:20
wgrantpitti: 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
wgrantcjwatson: Which?08:21
cjwatsonwgrant: partman-base, say, and possibly perl08:21
wgrantOhhh08:21
wgrantI thought some of the failures were weird.08:21
wgrant--from-suite doesn't imply --to-suite in populate-archive, I guess.08:22
cjwatsonI guess not ...08:22
wgrantAnyway, the main purpose of this test was to test the OpenStack setup.08:23
wgrantAnd it failed, so the test worked :P08:23
cjwatsonWhat were the failures?08:23
wgrantvbuilder-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
wgrantAnd lots of builds have hung during build-dep installation, which may just be the virtio issue.08:24
wgrantBut instance resets were at least reliable until the entire thing fell over.08:24
xnoxpitti: anything i can do to debug bug 1465196 ?08:57
ubottubug 1465196 in systemd (Ubuntu) "NetworkManager-wait-online job deleted to break ordering cycle" [Undecided,New] https://launchpad.net/bugs/146519608:57
xnoxBug #146519608:57
xnoxhttps://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/146519608:57
xnoxNetworkManager-wait-online job deleted to break ordering cycle08:57
pittixnox: hm, is that the entire journal for this? there should be some more output showing the actual cycle08:58
pittixnox: can you please attach the whole journalctl -b?08:58
zyga-phonePitti: rebooting08:59
pittizyga-phone: in HO now, but no hurry09:00
xnoxpitti: like this? http://paste.ubuntu.com/11718410/09:00
pittixnox: ex-actly09:00
pittixnox: so, something in open-iscsi; odd, I thought I fixed these already09:00
xnoxpitti: open-iscsi is the culprit?!09:00
pittixnox: ah, maybe not open-scsi + NM09:01
xnoxpitti: i have it installed.... but i'm not using it.09:01
pitti# Required-Start:    $network $remote_fs09:01
pittixnox: right, same old -- rcS init scripts being overly demanding on $remote_fs09:01
* xnox will just purge it.09:01
pittithat can't work with NM09:01
pittixnox: thanks, will adjust the bug09:02
xnoxpitti: 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:02
pittixnox: meeting now, brb09:03
pittixnox: yes, we keep the init scripts installed, but if there's a unit it gets ignored09:06
=== vrruiz_ is now known as rvr
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
pete-woodsMacSlow: hi, could you point me to the test plan you normally use when making changes to unity-notifications?11:32
pete-woodsI11:33
pete-woodsI've got a silo together, but can't find the test plan11:33
MacSlowpete-woods, I of course run the unit-test that come with it...11:33
pete-woodsMacSlow: well obviously, but is there a CI train test plan for *integration* testing11:34
pete-woods?11:34
pete-woodsif not, I guess that's fine, I'll just try out a bunch of things that use notifications, e.g. indicator-network11:34
MacSlowpete-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-woodsautopilot tests sound good11:35
pete-woodsdo you know where they live? I can't see them in the notifications source tree11:35
MacSlowpete-woods, the notifcation ap-tests live in the lp:unity8/tests/autopilot/unity8/shell/tests11:37
pete-woodsMacSlow: cool, thanks!11:38
MacSlowpete-woods, you can restrict the ap-testruns to the notifications ones by doing "autopilot3 run unity8.shell.tests.test_notifications"11:39
MacSlowpete-woods, otherwise it takes ages to go through the whole suite11:39
pete-woodsMacSlow: hmm, for some reason unity8-autopilot won't install on my phone11:40
=== _salem is now known as salem_
=== MacSlow is now known as MacSlow|lunch
bdrungTheMuso: good question.12:16
=== salem_ is now known as _salem
=== anthonyf is now known as Guest35437
=== pgraner-afk is now known as pgraner
=== MacSlow|lunch is now known as MacSlow
jamespagecjwatson, 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 how13:31
=== _salem is now known as salem_
cjwatsonjamespage: 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
argeshallyn: hey, bug 1464175 is in need of sponsorship. are you batching up libvirt updates? otherwise I can push this one13:36
ubottubug 1464175 in libvirt (Ubuntu Vivid) "virObjectUnref() libvirtd killed by SIGSEGV" [Undecided,In progress] https://launchpad.net/bugs/146417513:36
hallynarges: there is also https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/145560813:44
ubottuUbuntu bug 1455608 in libvirt (Ubuntu Vivid) "upstart job state switched to running before the sock file created" [High,In progress]13:44
argeshallyn: yup, do you want me to merge and sponsor those?13:44
argeshallyn: or whatever would be more helpful for you13:45
hallynarges: i think t and u still have pkgs awaiting verification, but ye splease i fyo umerge those that'd be great13:46
argeshallyn: ok will do13:46
hallynthanks13:46
=== salem_ is now known as _salem
dgadomskihey 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:11
seb128dgadomski, 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:14
dgadomskiseb128: 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
LocutusOfBorg1hi, can somebody from MIR team enlight me about bug 1461517 and bug 1464853?14:16
ubottubug 1461517 in libjsoncpp (Ubuntu) "[MIR] libjsoncpp" [Undecided,Incomplete] https://launchpad.net/bugs/146151714:16
ubottubug 1464853 in libjsoncpp (Ubuntu) "Sync libjsoncpp 0.10.2-3 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/146485314:16
dgadomskiseb128: for "normal" shares (e.g. mount.cifs) this could be done by passing the cifsacl option to mount14:17
seb128dgadomski, is your issue with real gvfs access through gio, or with the compat fuse mounnts?14:17
dgadomskiseb128: 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:25
seb128dgadomski, gedit = gio14:26
seb128but it you use e.g libreoffice it might be the fuse mount14:26
dgadomskiseb128: 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 cifsacl14:28
seb128dgadomski, is that bug impacting both gio and compat mounts?14:28
dgadomskiseb128: yes, both mechanims seem to be acl-unaware14:29
seb128dgadomski, https://bugzilla.gnome.org/show_bug.cgi?id=623161 ?14:30
ubottuGnome bug 623161 in gio "file ACL are not preserved when saving file in gedit" [Normal,New]14:30
seb128hum, that bug is about windows though14:31
seb128dgadomski, is that specific to smb or with any protocole? like ssh14:32
* smb is innocent14:33
dgadomskiseb128: I did not try anything else beside smb, give me a sec14:33
pittidgadomski: that's right; that's mostly a legacy program interface, i. e. CLI tools etc. which don't use GIO themselves14:37
pittidgadomski: 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 it14:37
slangasekwgrant: "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
pittidgadomski: I don't know how well fuse works with ACLs14:38
pittidgadomski: gedit, like all GNOME apps, uses GIO, not the fuse file system14:38
dgadomskithanks pitti, and is gio capable of working with ACLs?14:39
pittidgadomski: I don't know14:39
pittidgadomski: server-side ACLs should be totally transparent to the client14:39
pittidgadomski: and client-side ACLs should not matter, as this is all per-user, not system-wide14:39
pittidgadomski: so I don't quite understand what ACLs have to do with this14:40
dgadomskipitti: what if a user want's to modify ACLs on the server smb share?14:45
pittidgadomski: that's the thing I'm not sure about -- i. e. if that's mapped through GIO14:46
pittior if you need smbclient or a similarly specialized tool for that14:46
dgadomskipitti: 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:47
dgadomskipitti: but those tools are unusable with GIO / gvfs fuse, so the question is: is there a possibility to enable it?14:50
pittidgadomski: anything is possible, it's free software :) so it mostly depends on finding someone who is interested in adding this support14:51
dgadomskipitti: can you give me a hint which layer would be appropriate to implement such thing?14:52
pittidgadomski: I support GIO for adding the general set/get ACL API, and gvfs' smb-browse module for implementing it for samba/CIFS14:53
dgadomskipitti: sounds like quite amount of work, thanks for the info14:55
=== _salem is now known as salem_
LocutusOfBorg1mterry, are you sure about fix-double-parsing.patch?15:10
mterryLocutusOfBorg1, not 100% but the code that it changes is still there in debian15:11
mterryLocutusOfBorg1, and that patch is relatively recent -- it wasn't in our packaging back when Debian grabbed all our changes15:12
LocutusOfBorg1oh I see15:12
LocutusOfBorg1yes, right15:12
LocutusOfBorg1I checked, but I made a mistake15:12
LocutusOfBorg1so mterry while you are merging it, do you think for a MIR having the symbols file is a must=15:14
LocutusOfBorg1?15:14
LocutusOfBorg1I need that package into main, because cmake 3.2.2 is waiting for it15:14
mterryLocutusOfBorg1, not a must, just a strong preference.  But I see the comments about upstream checking ABI15:14
mterryLocutusOfBorg1, that's what brought me to your sync bug15:14
mterryLocutusOfBorg1, I'll try to sort this today15:15
LocutusOfBorg1ok, so if we can forward the patch to Debian we can just sync on the next run15:15
LocutusOfBorg1(I would like to avoid maintaining a delta there)15:16
LocutusOfBorg1specially because symbols have been dropped here http://anonscm.debian.org/cgit/collab-maint/libjsoncpp.git/commit/?id=21f33b218735398db17c50e09b46d7fefa39bec815:16
mterryLocutusOfBorg1, agreed, deltas suck15:16
LocutusOfBorg1I sent a mail with the patch to Peter15:21
mterryLocutusOfBorg1, 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:27
LocutusOfBorg1direct mail, but feel free to open a bug15:28
dobeyLocutusOfBorg1: is that my patch?15:28
LocutusOfBorg1I wasn't aware of the submittodebian tool, how does it work=15:28
LocutusOfBorg1yes dobey15:28
MirvQt 5.4.2 is now in wily, but will be blocked from migration due to existing KF5 autopkgtests failures15:29
dobeyLocutusOfBorg1: 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 it15:30
LocutusOfBorg1dobey, https://github.com/open-source-parsers/jsoncpp15:30
LocutusOfBorg1they moved to github :)15:30
dobeyLocutusOfBorg1: ah ok, thanks15:31
mterryLocutusOfBorg1, 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
dobeyLocutusOfBorg1: i'll see about getting that upstream then, but we do need to keep that patch around15:32
LocutusOfBorg1so I can't use it :(15:32
LocutusOfBorg1yes dobey, I hope Peter will merge it in Debian, and then we can sync it (and forget)15:32
dobeyok15:33
=== salem_ is now known as _salem
dobeywell, now i need to get lunch. :)15:33
LocutusOfBorg1have fun!15:39
LocutusOfBorg1so mterry please use the submittodebian tool then, I would prefer a bug instead :)15:42
LocutusOfBorg1and thanks for the hard work15:42
mterryLocutusOfBorg1, my pleasure.  I like converging on no deltas  :)15:43
mterryLocutusOfBorg1, I've got other work I'm in the middle of, but will try to finish this stuff out / review the MIR today15:43
LocutusOfBorg1thanks! I started working in Debian to avoid deltas, and now I'm mostly a DD15:44
LocutusOfBorg1I hope to become an ubuntu developer soonafter DAM processes my nm application15:44
=== dpm is now known as dpm-afk
mterryLocutusOfBorg1, oh nice  :)16:10
=== _salem is now known as salem_
argeshallyn: was trying to verify bug 1425619, but looks like the patch to qemu/trusty got dropped.16:48
ubottubug 1425619 in ubuntu-cloud-archive "Migration fails between QEMU 1.5 and QEMU 2.0" [Undecided,New] https://launchpad.net/bugs/142561916:48
argeshallyn: so we'll need to re-apply the patches for qemu before verifying that one before verifying libvirt etc...16:48
argeshallyn: i can re-apply that patch and push an update17:11
hallynarges: great, thanks17:15
hallynwonder how i dropped that17:15
argeshallyn: i think the security update overrode it17:26
argesanyway test building17:27
hallynah, ok17:29
=== utlemming_away is now known as utlemming
MirvFYI 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:24
Mirvthe 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 overridden18:26
Mirv(running Plasma 5 == running wily-proposed versions of Qt 5, KF5 etc)18:28
=== pgraner is now known as pgraner-dr
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
=== salem_ is now known as _salem
=== alexisb is now known as alexisb_lunch
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== alexisb_lunch is now known as alexisb
argeshallyn: /quit21:29
argeswhoops21:29
=== athairus is now known as afkthairus
=== _salem is now known as salem_
ScottKAny idea why http://www.ubuntu.com/legal claims the Canonical contributor agreement is needed " before you begin contributing to Ubuntu"?22:24
ScottKSeems wrong.22:24
lifelessdefine contribution I guess?22:26
lifelesssubmitting code to Canonical repositories vs running an ubuntu user group vs patching debian packages to work better on ubuntu...22:26
ScottKFor anything that's Ubuntu (the Linux distribution) such a thing isn't needed.22:26
ScottKI'd buy if it said something like ... some aspects of ...22:27
lifelesssure22:27
ScottKAs it is, it's plain wrong.22:27
lifelessjust like some packages require CLAs and patches to them ned to be done directly upstream (or be debt forever)22:28
ScottKSome upstreams require CLAs.22:28
ScottKUbuntu the distro doesn't.22:28
ScottKUnfortunately, the term Ubuntu is so overloaded it's almost meaningless.22:28
infinityScottK: 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
infinityslangasek: ^-- Can you sort out who to escalate that to?22:45
slangasekinfinity: can you file a bug against https://bugs.launchpad.net/ubuntu-website-content ?22:46
infinityslangasek: Sure.22:46
infinityhttps://bugs.launchpad.net/ubuntu-website-content/+bug/146543022:50
ubottuError: ubuntu bug 1465430 not found22:50
infinityslangasek: ^22:50
infinityErr, really, why is that private by default?22:50
infinityThere.22:51
infinityScottK: ^ does that look like an appropriate appraisal of the situation to you?22:51
ScottKThanks.22:51
* ScottK looks22:51
sarnoldeverything on the website is private by default :/ it's annoying to try to file bugs on behalf of others that way :(22:51
ScottKinfinity: Perfect.22:52
wgrantslangasek: 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:23
sladensarnold: +123:25
infinitywgrant: It's a 1-line hack to make the old sbuild build edk2, we could just get someone to cowboy one of the nonvirts. :P23:34
infinitywgrant: But I also assume we'll want it backported to the cloud archive.23:34
slangasekwgrant: ok23:39
infinityslangasek: Hrm, I see pesign in the queue synced from Debian.  Should we be looking to replace sbsigntool?23:45
slangasekinfinity: AFAIK the only benefit of pesign over sbsigntool is nss, which is a questionable benefit23:46
infinityslangasek: I would assume the other benefit is active maintenance.23:47
=== anthonyf is now known as Guest93759
slangasekinfinity: I'm happy to revisit that question when someone points to an actual feature we're missing out on :)23:47
infinityslangasek: Oh, and no dep on gnu-efi, which means it builds on more arches.  Like ARM/ARM64.23:47
infinityslangasek: arm64 support might be the killer feature.23:48

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!