[03:04] wgrant: hmm, which modal had the multi-step process, I thought it was 'link a related branch' on +bug, but that doesn't seem to be it [03:06] I must be going mad, I was looking at it yesterday... [04:41] blr: +sharing is multi-step [04:41] blr: BugTask:+index's branch picker is highly customised. [04:41] Well, not highly. [04:41] But quite. [04:46] wgrant: ah thanks, yes it was sharing. [13:48] Quick question: I need to rebuild a package on my ppa for armh. armh builds have already been approved. How do I get an uploaded package to be rebuilt for armh? [13:48] it seems that ubuntu-build might be the correct tool to use for this, but I can't figure out the right syntax for working with ppa builds [13:48] satmandu: If armhf was turned on after you uploaded the package in question, you'll need to upload it again. [13:49] That is, bump the version in debian/changelog but make no other changes. [13:49] that's what I thought. ok thanks [13:49] I could check if you told us which PPA. [13:49] Oh, https://launchpad.net/~satadru-umich/+archive/ubuntu/sernet-samba/+packages I guess [13:50] ppa:satadru-umich/sernet-samba [13:50] yup that's it [13:50] Yes, bump version and reupload. Future uploads will have armhf builds created by default. [13:51] ok will do. Thanks for the help! === xnox_ is now known as xnox [16:08] Can I ask a build question? [16:09] my amd64 build took 16 min [16:09] but the armhf build seems to be stuck. [16:09] I want to be a good ubuntu citizen... [16:09] is there anything I'm doing wrong? [16:10] amd64 build: https://launchpad.net/~satadru-umich/+archive/ubuntu/sernet-samba/+build/7672673 [16:10] current armh build: https://launchpad.net/builders/lgw01-53 [17:03] satmandu: armhf builds run via qemu-user-static. It's not very robust, and some things (particularly, but not limited to, just about anything involving threading) just plain don't work. [17:04] Hmmm. ok. But the only way to store builds as a ppa is to have them compiled through the qemu-user-static, right? I can't build the packages locally and then upload them? [17:05] Correct. [17:05] ok :) [17:05] We'll be bringing proper virtualised ARM builds online in the next couple of months or so. [17:05] understood. [17:06] That should make many things better. [17:38] Does the i386 build process often cause permissions issues during build? Getting a crash here: https://launchpadlibrarian.net/212115290/buildlog_ubuntu-vivid-i386.samba_99%3A4.1.19-11_BUILDING.txt.gz [17:41] satmandu: The difference between amd64 and i386 here is that (for >= vivid) amd64 builds the architecture-independent components as well. You can reproduce this locally using sbuild -A vs. sbuild --no-arch-all. [17:41] Also, that isn't a permissions issue; read the error message closely. [17:41] the directory isn't being created... [17:42] Right, that's not permissions. :-) [17:42] I think it's confused about wanting a /tmp/ folder [17:42] but it works ok on amd64 [17:42] Your build is probably only creating it in the architecture-independent case. [17:42] right [17:43] I don't see how /tmp/ has anything to do with it. [17:43] just say /var/lib folders earlier as /tmp/var/lib etc etc... [17:43] I'm just going to try these builds locally then [17:43] You mean debian/tmp/var/lib [17:43] to see if they work [17:44] yes [17:44] Is there any way to see why this is stuck before I cancel it? https://launchpad.net/~satadru-umich/+archive/ubuntu/sernet-samba/+build/7673738 [17:45] satmandu: Not really, no. [17:46] Pretty sure your builds are just doomed on armhf for now :-( [17:46] so it would seem [17:46] satmandu: sernet-samba-common is Architecture: all - this means that it is only built in builds that build architecture-independent packages. [17:47] satmandu: So debian/sernet-samba-common/ won't have been created by other bits of the packaging process for architecture-dependent-only builds, such as i386. [17:48] satmandu: The correct fix with modern-ish versions of debhelper, such as that in vivid, is to change "override_dh_fixperms" to "override_dh_fixperms-indep", since you only need to override the arch-indep behaviour there. [17:48] noted [17:55] Is there a good way to build debs locally from the dsc & changes files to replicate what launchpad is doing? [17:55] good = best practices [17:55] aside from this: https://help.ubuntu.com/community/UpdatingADeb [17:56] satmandu: https://wiki.ubuntu.com/SimpleSbuild [20:36] morning [20:52] evening [20:53] how's things cjwatson? [20:53] I think I have most of the initial pieces for snap building put together, just got sidetracked into fixing https://bugs.launchpad.net/launchpad/+bug/1424672 [20:53] Bug #1424672: LiveFS builds cancelled before they start sort above other builds in history

[20:53] (since the livefs and snap code are *cough* suspiciously similar, so I didn't want to import that bug) [20:54] cjwatson: hoping to get onto the squid authentication service soon, trying to get the 2-stage clientside ref picker sorted. [20:54] * cjwatson nods [20:54] discussed oauth/bearer token auth vs basic auth with wgrant yesterday, he seemed to think basic should suffice [21:02] I didn't totally follow, but the arguments sounded plausible :) [21:03] internal auth? we use basic auth everywhere I think, except for the things where it's easier to use tokens because they already terminate sso [21:07] cjwatson: I'm trying one last armhf build.. which appears to be going albeit slowly. (The compile is running much faster on my raspberry pi sitting next to me.) [21:07] So slow that I should cancel it to not be a drain on the build servers? [21:07] https://launchpad.net/~satadru-umich/+archive/ubuntu/sernet-samba/+build/7674252 [21:22] satmandu: We have plenty of build resources at the moment. If it actually works then it's fine. [22:25] cjwatson: Thanks. [22:51] cjwatson: Does this look like a hung compile to you? https://launchpad.net/builders/lgw01-54 [22:52] I can't debug it any further from my end. [22:54] satmandu: qemu-user-static is quite slow. You pretty much have to watch the build log to see if it changes. [23:01] satmandu: Yeah, basically no way to tell. Leave it for a few hours; if it's idle with no output for too long then the builder should kill it anyway. [23:14] Understood. Thanks again. === Peng_ is now known as Peng [23:42] Hi, loggerhead fails to display tabs as tabs in a diff. Tabs displayed as tabs: http://paste.ubuntu.com/11908410/ - tabs displayed as spaces: http://bazaar.launchpad.net/~ubuntu-core-dev/command-not-found/ubuntu/revision/190/zsh_command_not_found [23:42] In case you ever wondered why cron logs three useless spaces every hour to syslog ... someone mixed up tabs with spaces in /etc/crontab, so this is not only an only academicially relevant issue [23:48] And your paste service is suboptimal, correctly pasting a tab-idented file from a terminal into a browser is complicated and error-prone (at least I failed in doing so, I inserted an additional space). A way to upload a file and a way to download w/o logging in would be helpful (paste.debian.net is way better at this), it's also ugly in lynx (but paste.debian.net is even more ugly in lynx). Good night [23:49] pastebinit supports non-browser upload to paste.u.c [23:50] the login requirement is annoying but it mitigated some quite serious attacks aiui (I don't remember the details - it isn't a Launchpad service) [23:50] Sounds good, such a tool is a great addition, but no replacement for an upload button in the html page. [23:50] we don't maintain it [23:51] loggerhead should be easily enough fixable, but could you please file a bug so we don't forget? [23:51] Ok, I think the tab vs spaces issue in loggerhead is still valid [23:51] irc doesn't make a good bug tracker [23:52] I'm goging to bed soonish, you could just paste what I wrote into a bug report since you are more familiar with launchpad :) [23:52] I'm going to bed *now*, and on phone so no easy paste [23:53] so no, not really ... [23:53] Ok, I'll try to remember this when I login into launchpad next time :)