[00:47] <rsalveti> TheMuso: hey, do you have the src packages for pulse 6 around?
[00:47] <rsalveti> TheMuso: could be the one you used to get the binaries for http://people.canonical.com/~themuso/pulse6-armhf/
[00:48] <rsalveti> finally getting to validate it and wanted to review a few changes
[01:44] <rsalveti> TheMuso: seems to be in sync with http://anonscm.debian.org/cgit/pkg-pulseaudio/pulseaudio.git/, so will use that :-)
[02:49] <hallyn> arges: \o
[03:04] <TheMuso> rsalveti: Pretty much, sorry was busy. The only change in the ubuntu branch of the git repo is using bluez 5, I just have to flip back to bluez 4 before doing the final upload.
[03:05] <rsalveti> TheMuso: right, cool
[04:13] <rsalveti> TheMuso: when rebuilding it locally it failed when executing the tests:
[04:13] <rsalveti> FAIL: once-test
[04:14] <rsalveti> both vivid and rtm, did you get that as well?
[04:14] <TheMuso> rsalveti: What architecture?
[04:14] <rsalveti> TheMuso: armhf
[04:14] <TheMuso> rsalveti: Interesting, because I built it on real hardware and they passed.
[04:14] <TheMuso> THey did fail for me in a qemu enabled chroot./
[04:15] <rsalveti> hm
[04:15] <TheMuso> rsalveti: And FWIW< the desktop team ppa is now enabled for armhf, and I got no failure there either with my recent upload.
[04:16] <TheMuso> The transitions PPA.
[04:16] <rsalveti> TheMuso: yeah, might be kernel
[04:16] <rsalveti> http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-August/021066.html
[04:16] <rsalveti> >>
[04:16] <rsalveti> >> tests/once-test.c:74:F:once:once_test:0: Assertion
[04:16] <rsalveti> >> 'pthread_setaffinity_np(pthread_self(), sizeof(mask), &mask) == 0'
[04:16] <rsalveti> >> failed
[04:16] <rsalveti> the same one I'm getting
[04:18] <TheMuso> Can't remember what tests failed for me, since they weren't set to be verbose, but I know they did.
[04:23] <pitti> jdstrand: on the phone is still quite some work to be done for systemd pid 1, that won't happen in time for vivid
[04:23] <pitti> tyhicks: 1-2 weeks sounds like that should b perfectly applicable for an FFE
[04:23] <pitti> mitya57: right, that just recently started failing, without a change in paramiko itself
[04:24] <pitti> mitya57: python3-crypto does indeed not get installed any more
[04:25]  * pitti looks
[04:27] <Unit193> pitti: So what's the changes for systemd as default init in utopic?  A couple of us in the Xubuntu team have been wondering.
[04:28] <pitti> Unit193: vivid, I take it :)
[04:28] <Unit193> pitti: Think you'll pull in 219 since you got it mostly ready for exp?  Also, good morning!
[04:28] <pitti> Unit193: good morning!
[04:28] <Unit193> Err, yes, that..
[04:28] <pitti> Unit193: yes, I'll merge it today
[04:29] <pitti> Unit193: you mean how we'll actually do the switch? that should mostly be a seed change, but needs testing on upgrades of course
[04:29] <Unit193> pitti: Well, more of when/if it'll still hit for vivid, ff being so soon.
[04:31] <pitti> Unit193: we discussed this yesterday; still depends on bug 1312976; and to some degree on bug 1409639, but that's both scheduled to happen in March, and we could fall back to booting these instances with upstart
[04:31] <Unit193> pitti: Aha, sorry I missed that one.  Thanks!
[04:49] <rsalveti> TheMuso: one change I saw that was missing: http://paste.ubuntu.com/10284738/
[04:56] <TheMuso> rsalveti: Good catch, will add.
[05:01] <TheMuso> rsalveti: Ok thats committed to the ubuntu branch.
[05:01] <rsalveti> TheMuso: great, thanks
[05:02] <TheMuso> rsalveti: Thank you for catching it. :)
[05:02] <rsalveti> TheMuso: with the bluez4 build did you explicitly disabled bluez5?
[05:03] <TheMuso> rsalveti: No, but I certainly can do that, and was actually thinking of doing so.
[05:04] <rsalveti> TheMuso: yeah, might be better for now
[05:04] <rsalveti> until we officially move to bluez5
[05:04] <TheMuso> SOunds reasonable.
[05:09] <TheMuso> Ok, committed, so I don't forget.
[05:13] <ari-tczew> cjwatson: MoM is hanging on. (Generated at 2015-02-17 21:13:12 UTC.)
[05:43] <rsalveti> TheMuso: so +1 after testing it, feel free to push to vivid
[05:43] <rsalveti> at least from my perspective
[05:43] <rsalveti> just replied the thread
[05:52] <TheMuso> rsalveti: Ok cool. I've been running it on x86-64 in its various rc releases for a couple of months now, and whilst I haven't gone out of my way to test anything in particular, all seems ok for me here too.
[05:53] <rsalveti> TheMuso: awesome
[05:57] <Mirv> any early bird or late bird (bird=core-dev) to ack two pretty simple packaging changes to be landed? https://ci-train.ubuntu.com/job/ubuntu-landing-011-2-publish/lastSuccessfulBuild/artifact/packaging_changes_dbus-test-runner_15.04.0+15.04.20150218-0ubuntu1.diff + https://ci-train.ubuntu.com/job/ubuntu-landing-025-2-publish/17/artifact/packaging_changes_webbrowser-app_0.23+15.04.20150217.1-0ubuntu1.diff
[05:59] <Mirv> oSoMoN did not explicitly state the latter's packaging changes in the changelog unfortunately, but they are in more detail at https://code.launchpad.net/~osomon/webbrowser-app/workaround-bug-1417118/+merge/248564 + https://code.launchpad.net/~osomon/webbrowser-app/on-close-requested/+merge/240437
[06:31] <aeoril> darkxst does sbuild require a debian/Ubuntu package format?
[06:43] <darkxst> aeoril, yes
[06:44] <darkxst> you can login to a shell though and do manual builds, although thats probably better suited to a schroot
[07:00] <mitya57> Mirv: in case you still need an ACK for those two changes, they LGTM
[07:01] <Mirv> mitya57: \o/ yes, thank you. and if I didn't congratulate earlier on your core-dev:ness, I do it now. but I think I did :)
[07:02] <mitya57> Thanks :)
[07:02] <mitya57> You should also become one!
[07:04] <Mirv> probably :) I usually take the slow route, but people are nudging me about it.
[07:19] <seb128> slangasek, hey, any news about the systemd transition?
[08:20] <aeoril> darkxst so all the patches in ChangLog will get applied to the stuff in src, resulting in an altered code base?  The code in src in the trusty package of libvte is dated pre-2011, but the latest patch in ChangeLog is dated 2013
[08:28] <aeoril> darkxst I saw this:  http://packaging.ubuntu.com/html/patches-to-packages.html  I talked about quilt - now I am not sure what ChangeLog is for ...
[08:32] <aeoril> darkxst I am not talking about debian/changelog, but ChangeLog in the directory with configure, autogen.sh, etc.
[08:43] <aeoril> darkxst I went ahead and e-mailed a detailed report to chpe and asked for help
[08:59] <darkxst> aeoril, Changelog is upstreams, debian/changelog is for debian/ubuntu packaging
[08:59] <darkxst> quilt and debian/patches/series controls what patches are applied in a package
[09:01] <aeoril> quilt and debian/patches/series control debian/ubuntu packages?
[09:01] <aeoril> darkxst ^
[09:01] <darkxst> aeoril, distro patches are applied with quilt
[09:01] <darkxst> they live in debian/patches
[09:02] <darkxst> and series defines which and in what order they are applied
[09:02] <aeoril> darkxst yes, those patches in ChangeLog seem to be upstream patches.  It appears to have the form of a diff
[09:02] <aeoril> series of diffs*
[09:03] <darkxst> aeoril, you lost me here, debian/ubuntu patches maybe cherry-picked from upstream, but regardless they will be in debian/patches/ folder
[09:04] <aeoril> darkxst I have made great progress.  I have found the code in vte and gnome-terminal where the child process is executed (in this case, vim, or whatever is fired off with the -e option)
[09:04] <aeoril> darkxst no, the ChangeLog upstream patches file seems to be a series of diffs
[09:06] <darkxst> gnome-terminal doesnt even have changelog
[09:06] <darkxst> nor does vte
[09:07] <darkxst> so I have no idea still, what you are talking about
[09:08] <aeoril> darkxst why would the code in src predate 2011 for the trusty libvte?  The latest patches in the upstream patches file (ChangeLog) are dated 2013.  The ChangeLog I am talking about is in the "root" directory - the same one as configure is in, or autogen.sh
[09:09] <aeoril> darkxst I thought you said earlier ChangeLog was upstream patches ...
[09:09] <aeoril> (as opposed to debian/changelog)
[09:09] <aeoril> [02:59] <darkxst> aeoril, Changelog is upstreams, debian/changelog is for debian/ubuntu packaging
[09:10] <darkxst> aeoril, idk, changelog is documentation, its makes no sense for patches to be in there
[09:10] <aeoril> darkxst so the ChangeLog I am talking about in the same directory as configure and autogen.sh doesn't actually do anything?
[09:10] <darkxst> further these days with git, changelogs are useless
[09:11] <darkxst> aeoril, it really shouldnt
[09:12] <darkxst> it really should be a diff either, but even if it is I don't see how it would get applied during build (it can't)
[09:12] <aeoril> darkxst I am very confused then - the code in src in the trusty source package seems to predate 2011 - that seems very old
[09:13] <darkxst> aeoril, trusty may have had gnome-terminal 3.6?
[09:16] <aeoril> darkxst I am talking about libvte (vte3).  It is ostensibly version 34.9.  From the git repo, 34.9 seems to be a commit dated 2013
[09:17] <darkxst> aeoril, I am sure you will figure it out!
[09:17] <aeoril> (using git log and searching for "34.9" I found a commit whose comment is "version 0.34.9" dated 2013)
[09:17] <aeoril> ok, sorry - I'll stop bothering you
[09:18] <aeoril> darkxst like I said, I sent an e-mail to chpe, so I am hoping that ends well.  Night.
[09:19] <darkxst> it won't if the email was about the questions you just asked me!
[09:20] <aeoril> darkxst no, not at all - I just told him the overall problem mentioning the race condition and if he remembered code to fix that
[09:21] <aeoril> darkxst the questions I have just been asking have nothing to do with chpe - they are Ubuntu packaging questions
[09:21] <aeoril> debuan/ubuntu
[09:22] <aeoril> debian*
[09:26] <darkxst> aeoril, ok, ping me again when/if you are really stuck,
[10:23] <Mirv> Trevinho: hey! I was checking your pyotherside branch, but I get the following diff when comparing to actual git checkout of https://github.com/thp/pyotherside.git (the last commit on 20150111): http://pastebin.ubuntu.com/10288344/ - do you think you've made an error? both seem to build (I did some slight modifications to packaging)
[10:51] <Mirv> Trevinho: having diff:d both from current 1.2.0 and your branch to the actual git master, yes it'd look like you've older git snapshot so I'll just go with the newer that seems to work as well
[10:54] <flexiondotorg> Is there anyone in here who can review the Upload Queue? - https://launchpad.net/ubuntu/vivid/+queue
[11:12] <Riddell> didrocks: what news from touch team and bluez5?
[11:13] <didrocks> Riddell: they enabled two devices, still 2 which are more complex
[11:14] <didrocks> Riddell: I wanted to know if they would get in time for FF, they aren't sure, ricmm is the one working on it
[11:14] <didrocks> need to test something, rebooting quickly
[11:22] <flexiondotorg> pitti, Could I request some assistance please?
[11:22] <pitti> that's a really nasty trick question!
[11:23] <pitti> (forgot the :) )
[11:23] <flexiondotorg> pitti, The "glue" package for Ubuntu MATE were uploaded last Friday. They are in the upload queue.
[11:24] <flexiondotorg> pitti, Could you find someone to review them please?
[11:24] <flexiondotorg> https://launchpad.net/ubuntu/vivid/+queue
[11:25] <flexiondotorg> All the *ubuntu-mate* packages and yuyo-gtk-theme are the ones I'm interested in.
[11:26] <pitti> I'll spend some time on the queue after finishing my current SRU package
[11:27] <flexiondotorg> pitti, Many thanks.
[11:28] <pitti> utlemming: do you need bug 1420544 for precise, too?
[11:55] <pitti> flexiondotorg: why does grub2-themes-ubuntu-mate have a transitional grub-theme-ubuntu-mate package? that doesn't exist at all in Ubuntu?
[11:55] <flexiondotorg> pitti, Ah. That isn't required. Agreed.
[11:55] <flexiondotorg> It is a hangover from when those packages were shipped via a PPA.
[11:56] <pitti> flexiondotorg: ok; want to reupload without it? I'll reject it from the queue in the meantime and will re-review after uploading?
[11:56] <pitti> (looks ok otherwise)
[11:56] <flexiondotorg> pitti, I will update the source package. But I have no upload rights.
[11:56] <pitti> flexiondotorg: happy to sponsor it from vcs-bzr
[11:57] <flexiondotorg> pitti, Thanks.
[11:57] <flexiondotorg> Do I need to bump the version?
[11:57] <pitti> flexiondotorg: no
[11:59] <flexiondotorg> pitti, Do you want a new package-request bug?
[11:59] <pitti> flexiondotorg: no, just tell me when you fixed, tested, and pushed
[11:59] <pitti> (bzr push, I mean)
[11:59] <flexiondotorg> pitti, It is done.
[12:00] <pitti> flexiondotorg: rest NEWed
[12:00] <flexiondotorg> pitti, ?
[12:00] <pitti> flexiondotorg: I mean, I NEWed the other packages
[12:00] <flexiondotorg> pitti, Thank you 😁
[12:01] <flexiondotorg> pitti, Also yuyo-gtk-theme is the official Ubuntu MATE theme.
[12:02] <pitti> yep, getting there :)
[12:02] <flexiondotorg> pitti, Right you are :)
[12:03] <flexiondotorg> pitti, Question. If I find bugs in any of those packages I can request new version be uploaded after FF right?
[12:03] <pitti> flexiondotorg: sure; bugs can be fixed until the bitter end
[12:03] <flexiondotorg> Thought so
[12:03] <pitti> i. e. right until when we prepare the final images
[12:10] <pitti> flexiondotorg: "mate-meta" has a nice ring to it :)
[12:11] <flexiondotorg> ;-0
[12:14] <pitti> flexiondotorg: is it really desirable to ship both gtk 2 and 3 themes in yuyo-gtk-theme? that'll pull in gtk 2 even if you don't want/need it?
[12:14] <flexiondotorg> pitti, Yes.
[12:14] <flexiondotorg> MATE is currently built against GTK2.
[12:15] <flexiondotorg> But the themes can integrate with GTK3 applications.
[12:15] <flexiondotorg> So little bits of MATE use GTK3.
[12:15] <pitti> ah, ok
[12:15] <flexiondotorg> *Some
[12:29] <flexiondotorg> pitti, There are some package that Ubuntu MATE depends on not uploaded yet.
[12:30] <flexiondotorg> pitti, The plan was to get those package uploaded to Debian. But we are not going to make it before the Vivid FF.
[12:31] <flexiondotorg> pitti, Do you anticipate any difficulty in getting sync exemptions for a few Debian packages after FF?
[12:32] <Mirv> flexiondotorg: pitti: related to MATE, I'm also waiting for some archive admin to review the binNEW compiz-mate package at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-021/+packages , summary of packaging changes https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/32/artifact/packaging_changes_compiz_1%3A0.9.12.1+15.04.20150213-0ubuntu1.diff”
[12:32] <Mirv> I mean, preNEW review, since that's how the train works
[12:34] <rbasak> stgraber: on the kimchi (NEW) high port issue, it seems that the web app can't be changed to not use the root as the URL path.
[12:34] <rbasak> stgraber: is this a sufficient reason to leave it for now, as the user will face a URL change later anyway to fix it properly?
[12:34] <rbasak> can't (easily) be changed, anyway.
[12:35] <rbasak> Upstream's concerned that he can't prepare a patch in time for feature freeze, so the only alternative is an FFe I think.
[12:36] <flexiondotorg> Mirv, Thanks for the info.
[12:36] <flexiondotorg> Mirv, pitti is ubiquity-slideshow-ubuntu-mate also held in a queue somewhere?
[12:37] <Mirv> flexiondotorg: does not seem like it. compiz is just part of the CI Train so it does not show in the normal queues that it's waiting for approval (and it also needs manual pinging of archive admins like I'm now doing)
[12:38] <flexiondotorg> Mirv, Understood. Thanks.
[13:01] <pitti> flexiondotorg: not in https://launchpad.net/ubuntu/vivid/+queue?queue_state=0
[13:04] <flexiondotorg> pitti, Thanks.
[13:05] <pitti>  ubiquity-slideshow-ubuntu-mate | 92 | vivid | all
[13:05] <pitti> flexiondotorg: ^ seems fine? :-)
[13:05] <flexiondotorg> pitti, I've also been collaborating with the Xubuntu team.
[13:05] <flexiondotorg> pitti, They have uploaded lightdm-gtk-greeter-settings which is required by both Xubuntu and Ubuntu MATE
[13:05] <flexiondotorg> pitti, Thanks for clarifying ubiquity-slideshow-ubuntu-mate
[13:16] <mitya57> pitti: did you manage to figure out what's wrong with paramiko?
[13:17] <mitya57> I see that in a new build dependencies are still not installed
[13:17] <pitti> mitya57: didn't get to that yet; still on my list
[13:18] <mitya57> ok
[14:26] <didrocks> @pilot in
[14:26] <seb128> hallyn, pitti, didrocks, is cgmanager supposed to run under systemd with https://launchpad.net/ubuntu/+source/cgmanager/0.35-1?
[14:27] <seb128>    Loaded: loaded (/lib/systemd/system/cgmanager.service; disabled; vendor preset: enabled)
[14:27] <seb128> but it's inactive, not sure why
[14:27] <pitti> seb128: on fresh installs, yes; if you upgraded from earlier vivid, the postinst doesn't enable itself
[14:27] <seb128> oh ok
[14:27] <seb128> why not?
[14:27] <pitti> the changelog seemed to suggest that was on purpose, but I don't know why
[14:28] <pitti> these days we need cgmanager mostly on the phone under systemd, AFAIUI
[14:28] <didrocks> bug #1400394
[14:28] <didrocks> ah no, that was for the --enable
[14:29] <didrocks> pitti: it should be enabled on upgrade from the changelog?
[14:29]  * didrocks looks at the postinst
[14:30] <didrocks> pitti: it is enabled by default, but I guess seb128 upgraded while we still had --no-enable on cgmanager
[14:31] <seb128> didrocks, pitti, I'm asking because my unity8-desktop-next box still fails to start anything on vivid/systemd
[14:31] <seb128> right
[14:31] <seb128> I though that some upgrade would make untiy8 start working
[14:31] <didrocks> seb128: yeah, if you upgraded before, you are screwed
[14:31] <seb128> that seems suboptimal :-/
[14:31] <didrocks> seb128: well, hence the long discussion on preset and default upgrades :)
[14:32] <didrocks> that's exactly an example where we need that
[14:32] <didrocks> not sure where xnox is with this patch as he decided to go on this while I proposed my help, but seems things are stuck now
[14:33] <xnox> didrocks: que?
[14:33] <xnox> didrocks: well, didn't address last review comments - code purge, yet.
[14:33] <didrocks> xnox: I didn't see you posting another patch from the reviews comments
[14:34] <xnox> didrocks: yeah, you are faster with the plymouth things =)
[14:34] <didrocks> yeah, I would have hope we (ubuntu) can get it this cycle, but so close to FF, sounds hard now :p
[14:34] <xnox> argh. i see =)
[14:34] <didrocks> xnox: I don't want that we pile up debts with wrongly enabled/disabled services like cgmanager
[14:35] <xnox> true.
[14:35] <didrocks> seb128: so for now, I would say systemctl enable by hand
[14:35] <seb128> didrocks, k, thanks
[14:55] <pitti> mitya57: looking now; indeed this reproduces quite easily/fast with adt-run paramiko -d --- schroot vivid
[14:59] <pitti> mitya57: oh! got it
[14:59] <pitti> Package-Type: deb
[14:59] <pitti> who does that.. ;)
[14:59]  * pitti fixes autopkgtest's parser
[15:08] <mitya57> pitti: haha
[15:08] <pitti> mitya57: fix+test pushed, rolled out, paramiko running again
[15:09] <mitya57> thanks!
[15:10] <pitti> mitya57: ...green!
[15:11] <mitya57> \o/
[16:14] <stgraber> rbasak: New packages don't require FFes
[16:15] <stgraber> rbasak: well, unless you intend to ship that thing in main or on a media
[16:15] <rbasak> Oh. I didn't know that. I have filed FFes for them in the past, and had them approved.
[16:16] <rbasak> stgraber: so you want this fixed in time for release? I'll ask for that, thanks.
[16:43] <didrocks> @pilot out
[17:13] <flexiondotorg> pitti, Thanks for your help today :)
[19:43] <Noskcaj> Can we sync handbrake 0.10 from debian exp?
[19:45] <mdeslaur> Noskcaj: you might want to add this if you do: http://paste.ubuntu.com/10295495/
[21:23] <flexiondotorg> cyphermox, Hello
[21:24] <cyphermox> flexiondotorg: hey
[21:24] <cyphermox> how are you?
[21:24] <flexiondotorg> Very well. Yourself?
[21:25] <TheMuso> rsalveti: webrtc-audio-processing has an approved MIR: Bug 1325859
[21:25] <flexiondotorg> So, pitti got the remaining Ubuntu MATE into the official archive today.
[21:25] <flexiondotorg> cyphermox, ^^^^^
[21:25] <flexiondotorg> cyphermox, There are still a few packages missing from the official archive that Ubuntu MATE requires.
[21:26] <flexiondotorg> cyphermox, But the ubuntu-mate-meta package is there.
[21:26] <flexiondotorg> cyphermox, Can we (and I mean you here) start "trying" to build Ubuntu MATE image so I can at least see error logs and therefore what needs fixing?
[21:30] <cyphermox> I think so, but maybe not today
[21:31] <flexiondotorg> cyphermox, OK. No probs.
[21:31] <flexiondotorg> cyphermox, When do you think we can ty this?
[21:32] <cyphermox> flexiondotorg: I think it would end up being when infinity is no longer super-busy with trusty .2 release to review https://code.launchpad.net/~mathieu-tl/ubuntu-cdimage/ubuntu-mate/+merge/247939
[21:32] <cyphermox> ^^ and check if we didn't forget something else
[21:32] <flexiondotorg> cyphermox, I've got 2 more packages that are going in via Debian. Possibly one that won't make it now because the docs are GFDL so that will require a change to the seeds and meta package.
[21:32] <cyphermox> ok
[21:33] <flexiondotorg> cyphermox, Sure, no problem.
[21:33] <cyphermox> well if you want to do the seed changes (because a missing, non-existing package will definitely make builds fail), I'll sponsor the metapacakge updates
[21:33] <cyphermox> all up to whether debian can release your packages so we can sync them
[21:34] <cjwatson> I'll review the cdimage branch
[21:34] <cyphermox> cjwatson: cool, thanks.
[21:51] <cyphermox> cjwatson: do you have an idea of about how long the builds take, on average?
[21:51] <infinity> flexiondotorg: For the GFDL docs, you can do a main/nonfree split in Debian, and then in Ubuntu just introduce a tiny delta to make A depend on B if you wanted them both installed together or whatever.
[21:51] <cyphermox> that way it would be easier for me to come up with a good crontab time
[21:51] <infinity> cjwatson: Thanks for reviewing.
[21:52] <infinity> cyphermox: crontab times are most irrelevant now, just slam it in somewhere.
[21:52] <cyphermox> ok
[21:52] <flexiondotorg> infinity, Thanks or the info.
[21:52] <flexiondotorg> infinity, We are discussing this option now.
[21:52] <infinity> cyphermox: I intend to pull all that staggered cron madness out at some point and just do it all in parallel at panic-o-clock, when I find a good time for that to be.
[21:52] <cjwatson> cyphermox: <1hr I guess?  it's not really a big problem now that we have livefs in LP
[21:52] <cyphermox> ahah cool ;)
[21:53] <cjwatson> cyphermox: it just seems odd to have most of the builds staggered and then these two starting on top of each other.  I agree with infinity's long-term plan there though
[21:53] <rsalveti> TheMuso: why it's not yet in main then?
[21:54] <rsalveti> TheMuso: https://launchpad.net/ubuntu/+source/webrtc-audio-processing
[21:54] <rsalveti> TheMuso: still shows as universe
[21:54] <cyphermox> cjwatson: not a problem, I picked random different numbers.
[21:54] <infinity> cjwatson: Did you ever give any thought to the unhandled-exit (SIGINT, maybe?) issue that causes ftpsync locking to break, or were you leaving that bug for me to learn to love your codebase more? :P
[21:55] <infinity> Well, less about learning to love your code and more about learning how traps in python work.
[21:55] <infinity> But that's probable a Google and a stackexchange away. :P
[21:56] <cjwatson> I was pretty much leaving it for you.  It's not SIGINT, though, because SIGINT turns into a KeyboardInterrupt exception and that should be handled by the semaphore context manager stuff.
[21:57] <cjwatson> Could be some signal that the Python runtime doesn't turn into an exception, such as SIGTERM.
[21:57] <infinity> cjwatson: Kay.  I guess it'll take some experimenting to figure out if I can reproduce it.
[21:57] <cjwatson> I think it's still only a hypothesis though.
[21:57] <infinity> cjwatson: And then hope that whatever I reproduced is actually what's happening.
[21:57] <cjwatson> Quite
[21:57] <infinity> cjwatson: But if TERM's unhandled, that's worth fixing even if it's not the actual problem.
[21:58] <infinity> cjwatson: Seems plausible, though, if people are starting backgrounded builds and then being filled with regret.  kill(1) is always close at hand.
[21:59] <cjwatson> Could be.  I'm sceptical, it seems to happen a bit often for that.
[21:59] <cjwatson> I'd suggest adding some logging of the semaphore state as a first step.
[22:00] <cjwatson> That way we stand some chance of debugging, because one of the problems here is that we only find out about it days after whatever actually went wrong.
[22:00] <infinity> I'd say it happens too often for manual start/kill to account for it, but the touch/core/snappy/etc people seem to do a lot of manual building.
[22:00] <infinity> rsalveti did several today while I was point releasing. :P
[22:01] <rsalveti> right, indeed common
[22:01] <rsalveti> :-)
[22:02] <cjwatson> manual builds, yes, but I would have thought "argh, Ctrl-c" was a much more common response to regret than "argh, find another shell, look up pid, kill"
[22:03] <TheMuso> rsalveti: No idea...
[22:05] <infinity> cjwatson: Don't know about others, but I'm sort of 33/33/33 between start-and-background, screen-and-start-in-foreground, and start-in-foreground-oh-crap-no-screen.
[22:05] <rsalveti> infinity: do you know why webrtc-audio-processing is still in universe? it should have moved to main by looking at https://bugs.launchpad.net/ubuntu/+source/webrtc-audio-processing/+bug/1325859
[22:05] <infinity> cjwatson: So, I'd have a 33% chance of needing to kill if there was regret. :P
[22:06] <infinity> rsalveti: If I had to guess, I'd say it fell back into universe due to nothing depending on it.
[22:06] <rsalveti> infinity: could be, it took a few months for the new pulseaudio to land
[22:07] <cjwatson> ah, I have an "s" wrapper which is exec ssh -t "$1" screen -ARD
[22:07] <cjwatson> so it's actually less typing for me to ssh-and-screen than just ssh
[22:07] <rsalveti> infinity: what should I do to request it to be moved to main again?
[22:07] <infinity> rsalveti: This is enough.
[22:07] <infinity> rsalveti: Is something trying to build against it and failing?
[22:07] <rsalveti> infinity: pulseaudio 6, had to revert that dependency to make it to build (so I could get an image for wider testing)
[22:08] <rsalveti> and now checking why that package was in universe
[22:08] <infinity> rsalveti: I don't see it showing up in component-mismatches.  Oh, cause you reverted.
[22:08] <rsalveti> TheMuso just found out about this mir
[22:08] <infinity> rsalveti: So, yeah, I can re-promote, but use it today, please, or it'll just get bumped down by someone else again.
[22:08] <rsalveti> infinity: yup, can revert my revert right after
[22:08] <infinity> rsalveti: Go nuts.  Re-promoting now.
[22:08] <rsalveti> infinity: lovely, thanks!
[22:31] <cyphermox> cjwatson: infinity: would it be too early or too taxing on resources to kick off an ubuntu-mate build to check where we're at?
[22:34] <cjwatson> cyphermox: I don't much care but don't know if it gets in the way of trusty point releasing
[22:34] <cjwatson> oh, might need to create the livefs object in LP
[22:36] <cjwatson> that's done, https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-mate
[22:36] <infinity> cyphermox: Won't hurt my feelings if you try, I'm most concerned that if you're merging code into ubuntu-cdimage and pulling it on nusakan, you might introduce a bug that breaks me if I have to respin.
[22:37] <infinity> cyphermox: Resource contention shouldn't be an issue though.
[22:37] <infinity> cyphermox: Of course, we may have another ubiquity bug to hunt down, if elfy's crash wasn't cosmic rays. :P
[22:38] <cjwatson> infinity: er yeah oops kind of too late on that bit
[22:39] <cjwatson> wind back a revision if you care :)
[22:39] <infinity> cjwatson: You haven't been gone long enough to be a cowboy yet.
[22:42] <cjwatson> yee-ha
[22:43] <flexiondotorg> cyphermox, I think the ubiquity-slideshow-ubuntu-mate package is broken somehow.
[22:43] <flexiondotorg> When I look at the other slideshow packages for other flavours version 92 is shown as in [unviverse].
[22:44] <flexiondotorg> http://packages.ubuntu.com/vivid/ubiquity-slideshow-xubuntu
[22:44] <flexiondotorg> Package: ubiquity-slideshow-xubuntu (92) [universe]
[22:44] <flexiondotorg> But this is how it reads for http://packages.ubuntu.com/vivid/ubiquity-slideshow-ubuntu-mate
[22:44] <flexiondotorg> Package: ubiquity-slideshow-ubuntu-mate (92)
[22:45] <flexiondotorg> cyphermox, Consequently ubiquity-slideshow-ubuntu-mate is not installable.
[22:49] <cyphermox> ah, right
[22:50] <infinity> Having it in main wouldn't make it uninstallable.
[22:50] <infinity> Though it shouldn't be there, I assume.
[22:50]  * infinity demotes.
[22:50] <flexiondotorg> infinity, Thanks.
[22:51] <flexiondotorg> infinity, Many, many people helped upload stuff last Friday. I lost track of who did what but it seems ubiquity-slideshow-ubuntu-mate was misplaced.
[22:51] <infinity> flexiondotorg: If you're having installability issues, that wasn't it, for the record.
[22:51] <cyphermox> infinity: if anything breaks, we'll need to add a new test I guess.
[22:51] <flexiondotorg> I don't think it should be in 'main'.
[22:51] <infinity> flexiondotorg: It was in main because it's produced by a source in main, and it defaulted there.
[22:52] <infinity> flexiondotorg: Not a big deal.  universe is a superset of main, your ISO contains lots (and lots) of packages in main. :P
[22:52] <flexiondotorg> infinity, Thanks for your help.
[22:53] <flexiondotorg> infinity, How soon will that repo change be reflected?
[22:53] <infinity> flexiondotorg: 30-60 minutes.
[22:53] <flexiondotorg> Perfect
[22:54] <cjwatson> you have no reason to wait for it for anything, though
[22:55] <flexiondotorg> cjwatson, I still have my cobbled together iso build system so I can test stuff.
[22:55] <flexiondotorg> That is complaining that ubiquity-slideshow-ubuntu-mate is missing.
[22:56] <cjwatson> I find it very difficult to believe that that is due to it being in main
[22:56] <cjwatson> as infinity says, a large number of critical packages that you use are in main
[22:56] <cjwatson> unless you're actually manually downloading it from pool/universe/blah
[22:56] <flexiondotorg> It does appear to know it is in main.
[22:57] <flexiondotorg> Or wasin main.
[22:57] <flexiondotorg> I use live-build.
[23:11] <rsalveti> infinity: seems just the arm64 package is waiting for the missing dep: https://launchpad.net/ubuntu/+source/pulseaudio/1:6.0-0ubuntu3/+build/6990338
[23:11] <rsalveti> which is available (guess migrating to main still?) https://launchpad.net/ubuntu/+source/webrtc-audio-processing
[23:12] <infinity> rsalveti: Just started building too soon, I imagine.
[23:12] <infinity> rsalveti: A retry should make it happy.
[23:12] <rsalveti> great, thanks
[23:18] <cyphermox> flexiondotorg: I'd expect live-build to get it the right way, not downloading "manually" but rather building a proper livefs with debootstrap or something, could you paste the errors if it still fails later, just in case? I'll look when I get back
[23:18] <flexiondotorg> cyphermox, Sure.
[23:18] <flexiondotorg> cyphermox, I may try again tomorrow. So, I'll ping you then if there is a problem.
[23:20] <cyphermox> ok