[02:48] <hallyn> hi - so jdstrand has found that the latest qemu merge into utopic dropped the kvm-img symlink (to qemu-img).  libvirt caches the path it finds at startup so is unhappy.  my q is, should i re-add the link, or should i have qemu restart libvirt at postinst?
[02:49] <hallyn> no wait
[02:50] <hallyn> those have been gone for awhile.
[02:52] <hallyn> jdstrand: so you ran into that bc you upgraded from saucy version;  but kvm-img symlink has actually been gone since trusty.
[03:22] <robert_ancell> Can anyone help me get https://launchpad.net/ubuntu/+source/libgtop2/2.30.0.is.2.30.0-0ubuntu1 out of the NEW queue? I just rebuild all the dependencies to find they rebuilt against the old version :(
[04:47] <pitti> Good morning
[05:07] <pitti> robru: FYI, ubuntu-system-settings-online-accounts regressed its autopkgtest, so it won't land in utopic
[05:07] <pitti> https://jenkins.qa.ubuntu.com/job/utopic-adt-ubuntu-system-settings-online-accounts/161
[05:40] <robru> pitti, thanks for the heads up
[05:41] <robru> pitti, any chance to just retry those? seems transient, like the infra is failing to start the app
[05:42] <pitti> robru: running
[05:42] <robru> pitti, thanks
[05:53] <pitti> robru: nope, still the same crash (on both arches), so this smells like a regression
[05:53] <pitti> "Appears process has already exited"
[05:53] <pitti> seems the app crashes
[05:54] <robru> pitti, hrm, can you ping dbarth about it? I'm EOD, and it's his landing. sorry
[05:54] <pitti> robru: yes
[05:54] <robru> pitti, thanks
[05:56] <ari-tczew> Hello devs! There are a lot of merges still waiting to be sponsored in _main_ and only 2 days left to Feature Freeze. So if somebody got a little bit free time, would be nice to get them into archive ;-)
[05:56] <pitti> robru: mailed him
[05:57] <robru> pitti, thanks!
[06:04] <dholbach> good morning
[06:08] <ari-tczew> hello dholbach
[06:08] <dholbach> hi ari-tczew
[06:40] <pitti> infinity: shoudl the eglibc source be removed from utopic now?
[06:47] <geser> zul: do we need the source package oslo.db (0.2.0-0ubuntu1) in the archive while we also have python-oslo.db (0.3.0-0ubuntu1)? can the former be removed?
[06:57] <Tribaal> dholbach: thanks for the review!
[06:57] <Tribaal> (for ubumirror)
[06:58] <dholbach> anytime
[07:03] <Tribaal> dholbach: for what it's worth, I'm applying for Ubuntu membership in tomorrow's session - your +1 is welcome if you think I'm doing a good enough job :)
[07:04] <Tribaal> (https://wiki.ubuntu.com/Tribaal)
[08:06] <infinity> pitti: Needs me to fix the cross packages to work with glibc-source first, but it can and will be removed after that.
[08:07] <infinity> pitti: Perfectly reasonable to remove it from autopkgtests, though, if you can do that.
[08:07] <pitti> infinity: ah, thanks; I just wondered if it was merely forgotten
[08:07] <pitti> infinity: it will come back, as it still has the xs-testsuite: flag; but it doesn't do much harm
[08:08] <infinity> Just a slight waste of resources every time it's triggered, but yeah.
[08:20] <Tribaal> dholbach: thanks a lot :)
[09:41] <sil2100> wgrant: hey! :)
[09:41] <sil2100> wgrant: so, I noticed something strange just now
[09:42] <sil2100> wgrant: we cleaned out packages from an ubuntu-rtm PPA (silo for CI Train), the PPA doesn't list any packages anymore but we still see them in the Packages file
[09:42] <sil2100> wgrant: as for instance here: http://ppa.launchpad.net/ci-train-ppa-service/landing-001/ubuntu-rtm/dists/14.09/main/binary-armhf/Packages
[09:42] <sil2100> wgrant: and it's like this since hours now
[09:49] <wgrant> 7.1.4+rtm+rtm+rtm+rtm+14.09.20140819-0ubuntu1
[09:49] <wgrant> Impressive version!
[09:49] <mlankhorst> must rtm!
[09:49] <wgrant> sil2100: Is it possible that your deletion raced with build completion?
[09:50] <wgrant> I think it's the normal deletion vs. build race.
[09:51] <wgrant> The armhf build finished just a couple of minutes before the source was deleted, so the binaries missed being deleted.
[09:51] <wgrant> Deleting the source again will properly take the new binaries with it.
[09:51] <sil2100> hmmm, maybe
[10:00] <zul> geser:  former can be removed
[10:10] <cjwatson> sil2100: has the bug that created the multiple +rtm bits been fixed?
[10:11] <sil2100> cjwatson: not yet, robru had some workarounds tried but not much results, I'm stuck in meetings right now
[10:13] <sil2100> cjwatson: but looking at it
[10:14] <sil2100> cjwatson: I'll just modify the regex so that it's not a problem anymore, just need some time to parse it first
[10:17] <infinity> sil2100, cjwatson: So, I wanted to have a chat about RTM versioning in general anyway, nevermind the lollerskates multiple +rtm bits.
[10:18] <infinity> If the policy is utopic first, then "backport" to RTM, the RTM versions should be lower (ie: ~, not +) than the utopic versions.
[10:18] <wgrant> Also the rtm is on the wrong end.
[10:18] <infinity> And it should be at the end, yes.
[10:18] <sil2100> infinity: so... regarding that, it was like that originally but caused problems during uploads
[10:18] <wgrant> Though I guess if we never cross-grade then that's not a problem.
[10:19] <infinity> So, 1.2.3+14.09.20140101-0ubuntu1~rtm
[10:19] <sil2100> infinity: since let's take such an example:
[10:19] <infinity> sil2100: What problems were caused, and was it because of the rtm being in a weird position in the version?
[10:20] <sil2100> infinity: well, most problems come from how CI Train is creating its version numbers
[10:20] <infinity> wgrant: So, yeah, I don't think supporting people going read-write on their phones and having apt-get upgrade work correctly is a big priority, but I don't think having it gratuitously broken when we can just version correctly is reasonable either.
[10:20] <sil2100> infinity: it's doing it like this -> version+series.date-0ubuntu1
[10:21] <infinity> sil2100: It should just create them as it always has, but for rtm, tack ~rtm on the very end, and done.
[10:21] <cjwatson> Not that simple unfortunately
[10:21] <sil2100> infinity: right, but you can't take the same version
[10:21] <sil2100> infinity: since we're not doing a copy of a package from ubuntu to ubuntu-rtm
[10:21] <infinity> ?
[10:21] <cjwatson> Consider an existing package that's 1+14.10.20140819-0ubuntu1
[10:21] <sil2100> infinity: we're cherry picking single fixes, so it's a completely different package
[10:21] <cjwatson> citrain then wanted to upload 1+14.09.20140819-0ubuntu1
[10:22] <cjwatson> Which is less than what was already in that series, so not uploadable
[10:22] <cjwatson> And yeah, what sil2100 said, these aren't necessarily wholesale backports
[10:22] <infinity> Oh, it already has the 14.10 versus 14.09...
[10:22] <infinity> In which case, who cares about the "rtm" being in there at all?
[10:22] <sil2100> infinity: so as cjwatson mentions, this causes some problems because you actually build a new package, so generate a new version
[10:22] <cjwatson> infinity: might clash in the future
[10:23] <infinity> Anyhow, I'm still not seeing the problem, I guess I'm dense.
[10:23] <infinity> PPAs can go backwards (once the previous is deleted), you just can't reuse identical versions.
[10:23] <cjwatson> Doing that in a proper distribution routinely would be terrible though.
[10:23] <cjwatson> I mean, yes, technically possible.  Shouldn't.
[10:24] <infinity> But... RTM and Ubuntu aren't the same distro.
[10:24] <cjwatson> Also, since the upstream tarballs are generated independently, any "rtm" identifier has to be in the upstream part, not the packaging-revision part.
[10:24] <infinity> Oh.
[10:24] <sil2100> infinity: ok, we could do that, but that would mean we would have to force those uploads to happen, and have a shift of versions
[10:24] <wgrant> Oh, ew.
[10:24] <cjwatson> infinity: but Ubuntu has been copied into RTM, including lots of 14.10 versions
[10:24] <infinity> But if we forked 14.10, then upload a new one.
[10:24] <infinity> Derp.
[10:24] <infinity> Kay.
[10:24] <infinity> So, why are we versioning at 14.09?
[10:25] <cjwatson> Because that's when we plan to release
[10:25] <sil2100> That's the series name
[10:25] <sil2100> And yeah, that's probably the reason for that name ;p
[10:25] <cjwatson> Ideally, citrain would look at the history of the package and identify the new version with something related to the last Ubuntu version
[10:25] <infinity> But that means this whole rollback issue is, well, an issue.
[10:25] <infinity> And that we're stuck with inflating "upstream" versions to fix it.
[10:25] <infinity> Which is gross.
[10:25] <infinity> Really gross.
[10:26] <cjwatson> It is nasty, but not fatal
[10:26] <infinity> Nasty, in that all of those upstream components need newer versions in utopic, even if there's not actually been a new upstream release.
[10:26] <Saviq> cjwatson, hey, can you tell us if session dbus / upstart details are supposed to be available to click hooks? otherwise is there a state-of-the-art way to contact the running user session?
[10:27] <cjwatson> I mean, neither that nor going backwards is technically a problem, since we don't expect this to be used via apt very much
[10:27] <cjwatson> But keeping things going forwards is less confusing for humans
[10:27] <cjwatson> infinity: I don't think that's true
[10:27] <Saviq> (from a hook)
[10:27] <infinity> I know catering to apt users is a very low priority, I'd just like to see if it can be made to work correctly anyway.
[10:27] <cjwatson> Saviq: System-level or user-level hooks?
[10:27] <Saviq> cjwatson, user-level
[10:28] <infinity> cjwatson: It's true if we want them to be upgradable at all.  It's not if we pretend those users won't exist.
[10:28] <cjwatson> Saviq: They're run from the user's upstart session, so the usual stuff should be available.
[10:28] <Saviq> cjwatson, basically we need to refresh launcher items on app install/upgrade/uninstall
[10:28] <infinity> 1.2.3+rtm > 1.2.3, so utopic now needs 1.2.4 to compensate.
[10:28] <cjwatson> infinity: Only if we expect people to be able to upgrade from ubuntu-rtm/14.09 to ubuntu/utopic.
[10:29] <infinity> Whereas if the rtm bit was in the datestamp portion of the version, it would not be problematic to fix without new upstream releases.
[10:29] <cjwatson> Which I don't think is a realistically useful requirement.
[10:29] <Saviq> cjwatson, hmm wonder why mzanetti's hook isn't getting them, see anything wrong http://paste.ubuntu.com/8086809/ ?
[10:29] <infinity> cjwatson: I don't think it's unreasonably to suggest it could be made to work, not to go out of our way to do so.
[10:29] <infinity> cjwatson: But given the versioning is completely broken ANYWAY, may as well fix both in one go?
[10:31] <infinity> Indeed, if they were just 14.10 instead of 14.09, new datestamps would solve the ordering issue for the archive, and putting an "rtm" string later would allow us to easily identify forked packages for later analysis.
[10:31] <cjwatson> infinity: I don't have a problem with doing it as UPSTREAM+14.09.20140819+rtm-0ubuntu1 or something; I don't know that it helps much but I haven't thought in great detail about the constraints involved, so if you wanted to go for that kind of thing then be my guest
[10:31] <sil2100> For me it's not a big deal if we switch from rtm+14.09 to 14.09, but I would have to know if we can easily push that to the archives even though there will be an error that the archive already has a never wersion
[10:32] <cjwatson> infinity: The other thing to ensure is uniqueness between ubuntu and ubuntu-rtm; Launchpad itself doesn't require that as such but we should
[10:32] <infinity> cjwatson: Would need to be 14.10, not 14.09, as 14.09 is the reason you have to inflate UPSTREAM.
[10:32] <cjwatson> sil2100: Yeah, it would need to be 14.10 if we did that, I guess, with an extra tag
[10:32] <cjwatson> Which might not be terrible, although it's more special-casing
[10:32] <cjwatson> Hm, wonder if the parent series is available via the API
[10:32] <sil2100> hm, we could do that, but as you meantioned it would be a special case in CI Train as well
[10:33] <sil2100> I don't mind that much, I just have no preference here
[10:33] <wgrant> cjwatson: Not the cross-distro parent series, no.
[10:33] <wgrant> Just the previous one within the distro, if any.
[10:33] <cjwatson> It sure is, via getParentSeries
[10:33] <infinity> cjwatson: So, I was thinking UPSTREAM+14.10.20140819~rtm-0ubuntu1, so that if someone does a utopic and RTM build on the same day, the sort order comes out right.
[10:33] <cjwatson> In [7]: rtm1409.getParentSeries()[0].version
[10:33] <cjwatson> Out[7]: u'14.10'
[10:34] <cjwatson> infinity: seems OK
[10:34] <wgrant> Oh, so it is.
[10:34] <cjwatson> so it's even doable programmatically, which is nice
[10:34] <infinity> Now, the stuff that's had UPSTREAM+rtm(+rtm(+rtm)) versions will need upstream minor bumps to fix them, but everything else would Just Work in a seemingly sane way.
[10:34] <cjwatson> infinity: RTM's going to be flushed in bulk anyway
[10:35] <infinity> cjwatson: Oh, we're starting fresh?  Excellent.
[10:35] <cjwatson> Was going to be today, but we haven't had a promoted image
[10:35] <cjwatson> Basically everything with the exception of ubuntu-keyring will be reset
[10:35] <infinity> Then, yes, unless there are objections or better ideas, can we call UPSTREAM+14.10.20140819~rtm-0ubuntu1 a concensus and make it work?
[10:35] <wgrant> cjwatson: Does derive-distribution know to delete sources that it's going to downgrade?
[10:35] <cjwatson> wgrant: Oh, possibly not.  Does it need to wait a publisher cycle, or is requesting the deletion first sufficient?
[10:36] <wgrant> cjwatson: No need to wait.
[10:36] <infinity> That makes apt upgrades work, and keeps the archive constraint issue under control, so both parties are happy.
[10:36] <wgrant> There just needs to be no active publication with a greater version by the time the dominator runs.
[10:36] <wgrant> Hm, the copier will reject too, I guess.
[10:36] <wgrant> So it needs to be deleted first, but still no need to wait.
[10:36] <cjwatson> Right, I'll sort that out before we flush
[10:37] <cjwatson> sil2100: Could you implement infinity's proposal?  It looks nicer than what we have now.
[10:38]  * cjwatson tries to resist the temptation to try to do a "quick" perl 5.20 transition before FF
[10:39] <infinity> cjwatson: Perl transitions usually are pretty quick, unless a few too many modules got eaten by or spit out of perl-modules.
[10:39] <infinity> cjwatson: (consider that a +1 and offer to help during Debconf, if you feel the urge)
[10:41] <cjwatson> It's looking pretty good in Debian, actually, yeah.  https://release.debian.org/transitions/html/perl5.20.html
[10:41] <sil2100> cjwatson: sure
[10:41] <cjwatson> sil2100: thanks!
[10:41] <infinity> sil2100: \o/
[10:41] <infinity> cjwatson: Yeah, that looks pretty smooth.
[10:42] <cjwatson> Oh, and perl is multiarch now!
[10:42] <cjwatson> That's a pretty hot reason.
[10:42] <infinity> cjwatson: Crank that +1 up to 11.
[10:42] <sil2100> infinity: btw. that +rtm+rtm+rtm was a bug ;p !
[10:42] <infinity> sil2100: Obviously, yes. :)
[10:42] <sil2100> infinity: it wasn't a feature! ;)
[10:42] <Laney> RTMs all the way down
[10:43] <infinity> sil2100: But with Colin's getParentSeries()[0].version discovery, I think my proposal ends up looking a lot cleaner, and solves both your concern and mine in one go.
[10:43] <infinity> sil2100: So, given that we're about to flush the world, a perfect time to fix it. ;)
[10:44] <infinity> sil2100: And thanks in advance!
[10:45] <sil2100> infinity: indeed ;) I guess that makes sense, it's just that by default we wanted to do it as it was before as the version number had the 'series' bit
[10:45] <sil2100> infinity: but it's no problem changing that
[10:50] <cjwatson> doko: Mind if I use https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa to stage the perl 5.20 transition?
[10:50] <cjwatson> (Just the first level or two)
[10:53] <cjwatson> doko: Actually, never mind, I'll use one of my own
[12:29] <cjwatson> infinity: Any objection to me doing a mass retry of failed builds?  I've found quite a few in update_excuses that succeed on retry, and it probably doesn't make sense for me to keep looking manually
[12:31] <doko> cjwatson, utopic should be fine
[12:31] <cjwatson> Maybe I should do it overnight rather than now though.
[12:31] <doko> cjwatson, mass retry: yes, that makes sense. we didn't have a mass retry yet this cycle
[12:33] <cjwatson> doko: perl is nearly finished building in https://launchpad.net/~cjwatson/+archive/ubuntu/devirt/+packages now, then I'll rebuild the important modules
[13:02] <tinoco> back
[13:22] <Saviq> mzanetti
[13:22] <Saviq> not here
[13:32] <pitti> SpamapS: heh, I just noticed "undistract-me" by sheer accident in an apt-cache search -- nice!
[13:48] <mzanetti> cjwatson: hey, not sure what Saviq and tedg already told you... I have the issue that the environment is not set up when my hook is executed. any pointers?
[13:48] <mzanetti> this is the hook: http://paste.ubuntu.com/8089030/
[13:49] <cjwatson> mzanetti: Can you check #ubuntu-touch backlog/logs rather than me repeating it here?
[13:50] <mzanetti> ok
[13:50] <cjwatson> Looks like you were in that channel at the time
[14:28] <SpamapS> pitti: It's a great tool.. I love it.
[14:29] <SpamapS> pitti: thank "jono" tho ;)
[14:40] <cjwatson> jdstrand: I'm working on switching to Perl 5.20, and apparmor fails: https://launchpad.net/~cjwatson/+archive/ubuntu/devirt/+packages
[14:42] <cjwatson> jdstrand: The first bit of this is that there needs to be something to switch debian/libapparmor-perl.install to $Config{vendorarch} rather than /usr/lib/perl5 (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748380), but there are some other matches for "usr/lib/perl5" in apparmor, and I wonder if any policies or databases or whatever would need to be updated?
[14:45] <arges> cjwatson: pitti : hello, i'm trying to use 'copy-proposed-kernel' in the archive tools; and it isn't copying kernels as it normally does. the launchpadlib/login stuff seems fine; and the command completes, but i receive no emails/notifications that the kernel was put into proposed
[14:46] <pitti> arges: for which release?
[14:46] <arges> pitti: precise/trusty
[14:46] <arges> pitti: i've only tried precise at the moment
[14:46] <pitti> arges: hm, nothing in https://launchpad.net/ubuntu/precise/+queue?queue_state=1
[14:46] <arges> also i've updated my tools to revision 885
[14:46] <pitti> arges: I tripped over that recently, stuff now lands in unapproved (where it actually belongs)
[14:47] <jdstrand> jdstrand: ok, I'll take a look at it
[14:47] <cjwatson> arges: Which version?
[14:47] <arges> cjwatson: i'm trying to execute 'copy-proposed-kernel precise linux'
[14:47] <cjwatson> arges: Yeah, which version should it be copying, so that I can grep logs without it taking all week? :)
[14:48] <cjwatson> jdstrand: Thanks.  The requisite perl is only in that PPA for now (copied from Debian)
[14:48] <arges> cjwatson: linux - 3.2.0-68.102
[14:48] <cjwatson> arges: Well, that seems to have copied just fine.  https://launchpad.net/ubuntu/precise/+source/linux/3.2.0-68.102
[14:49] <arges> cjwatson: why didn't it email me, nor do i see it with 'rmadison linux' ?
[14:49] <cjwatson> Former: don't know.  Latter: publication hasn't completed yet
[14:50] <arges> ok...
[14:51] <cjwatson> rmadison looks at the published and mirrored archive on disk
[14:51] <arges> cjwatson: also not sure if its already a known issue but pending-sru's seem to be a bit out of date
[14:52] <cjwatson> arges: Mm, I don't know what the problem is there, but I can see there's a job running at the moment (for ~12 minutes) so hopefully that'll clear soon ...
[14:53] <arges> cjwatson: ok thanks
[14:53] <cjwatson> arges: If not, bdmurray gets the cron mail from that
[14:54] <arges> cjwatson: and now its emailing me... with the last copy-proposed-kernel
[14:54] <arges> wierd
[15:43] <cjwatson> pitti: bug 1358764 looks like a regression from latest util-linux upload
[15:43] <cjwatson> slangasek: ^- (that's the one I mentioned to you as well)
[15:43] <slangasek> yep
[15:43] <cjwatson> just occurred to me I should tell the latest uploader
[15:43] <slangasek> so the difference I notice is that this is the first util-linux rebuilt with the new debhelper that includes the init scripts alongside the upstart jobs
[15:44] <pitti> cjwatson: ah, thanks
[15:44] <slangasek> probably a latent bug then exposed by the rebuild, and I'll take a look at it today
[15:44] <pitti> I suppose the previous debootstrap-ish tests didn't take util-linux from proposed
[15:52] <pitti> cjwatson, slangasek: we have TB meeting in 9 mins -- how urgent is that? is a proper fix tomorrow morning sufficient, or does that need a quick panic fix today? (I don't have much time left today)
[15:53] <ogra_> pitti, it prevents image builds (debootstrap falls over)
[15:53] <cjwatson> it's blocking all image builds and click chroot setup, and rickspencer3 escalated it to me
[15:53] <cjwatson> I think we need something quick
[15:53] <pitti> ok, so "panic fix" it is
[15:53] <ogra_> or a rollback today and a proper fix tomorrow
[15:53] <pitti> presumably we can just drop the init.d script
[15:53] <pitti> as that's the main change
[15:53] <pitti> (wrt. that bug)
[15:54] <pitti> I thought it was better to keep it, as that's the general direction we went to for insserv
[15:56] <pitti> cjwatson, slangasek: http://paste.ubuntu.com/8090000/ test-sbuilding now
[15:58] <pitti> TBH I don't quite understand the insserv error, we do have /etc/init.d/mountdevsubfs.sh (and outside of debootstrap it worked fine), but that shold do for now
[15:58] <pitti> any init.d dependency to hwclock.sh would have been broken until today as well, so obviously that's not much of a problem
[16:00] <pitti> infinity: TB meeting now
[16:00] <slangasek> pitti: that's fine for an emergency fix, but it will leave the stale file on disk for anyone who's already upgraded; I'll work on a proper fix today
[16:00] <pitti> slangasek: does that hurt?
[16:00] <slangasek> not as long as we remember to take care of it all later
[16:00] <pitti> slangasek: I mean, I'd like it to come back, but that needs some deeper fix
[16:01] <cjwatson> thanks to you both
[16:01] <pitti> slangasek: it upgraded and installed fine on several machines as well as the phone, after all
[16:02] <pitti> cjwatson, slangasek: binary debdiff looks ok, installing/upgrading now: http://paste.ubuntu.com/8090037/
[16:03] <pitti> meh, not good
[16:04] <pitti> take 2, building
[16:07] <roadmr> hello folks! mk-sbuild --arch=amd64 utopic fails with this: http://paste.ubuntu.com/8090049/ seems to have trouble installing a bunch of packages :/
[16:10] <pitti> slangasek, cjwatson: http://paste.ubuntu.com/8090061/ built, tested upgrade, tested fresh install (in chroot), worked now
[16:10] <pitti> I didn't test debootstrap yet
[16:10]  * pitti wonders how to do that with a local package
[16:11] <pitti> but TBH I'd just upload it to -proposed and test it once it's published there
[16:11] <pitti> faster turnaround, and very likely to work; WDYT?
[16:11] <pitti> slangasek: ^
[16:11] <pitti> (I can set a block-proposed until that happened)
[16:11] <slangasek> pitti: gah, manual postinst handling of scripts!  Yeah, JFDI
[16:12] <pitti> slangasek: I'll reopen the bug after that, to clean this up properly (put back the script, or clean it up on upgrade)
[16:21] <pitti> cjwatson: do you happen to know whether I can ask debootstrap to include -proposed? It seems it doesn't know about pockets at all
[16:25] <ogra_> isnt there a --components switch ?
[16:25] <ogra_> oh, that wouldnt cover proposed i guess ...
[16:26] <pitti> ogra_: right, that's a pocket, not a component
[16:26] <ogra_> yeah :/
[16:26] <pitti> slangasek, cjwatson: I think I fully understand what's going on now, bug updated
[16:27] <pitti> so I'll probably just drop "block-proposed", let it propagate, verify, and then we wash/rinse/repeat if it really still fails
[16:27] <ogra_> yeah
[16:27] <ogra_> just shovel it through :)
[16:28] <ogra_> cant be worse ;)
[16:29] <slangasek> pitti: the bug is specifically listed as "upgrades from saucy"; I think readding it now should be fine
[16:30] <pitti> slangasek: yeah, that's my hope
[16:30] <slangasek> pitti: and if it breaks something else, we should fix it somewhere else, not by bypassing the rightful dependency
[16:30] <slangasek> (which, btw, does nothing for "transitively essential status", contrary to infinity's changelog entry)
[16:33] <pitti> slangasek: ack; so I'll go with that (but tomorrow morning, when I can do upgrade testing from trusty to utopic + file:// with new util-linux with initscripts dep)
[16:34] <slangasek> pitti: well, I was planning on looking at all of this today, I'm not sure why you were roped into fixing this urgently :)
[16:35] <pitti> cjwatson: well, technically I broke it (uploader), and he pinged me; it seemed to me I was on the hook for this?
[16:35] <pitti> err, slangasek
[16:36] <slangasek> no, /I/ broke it, I changed debhelper ;)
[16:36] <pitti> (wow, two people fighting over getting the blame for breaking the world, yay!)
[16:37] <pitti> slangasek: btw, do you consider the sysvinit merge relevant for FF? it doesn't have much in terms of new features, but it's not a simple change either
[16:37]  * ogra_ guesses cjwatson just doesnt want to lose the place on your couch and quickly pushed it to pitti 
[16:38] <slangasek> pitti: well, how about if I review it with my release hat on as well as my I-hate-sysvinit hat
[16:38] <pitti> haha
[16:38] <pitti> slangasek: but it's simple and robust!
[16:38] <pitti> *cough*
[16:40] <pitti> ogra_: ok, it's built everywhere, so I hope in about 2 hours or so you'll have image builds back
[16:40] <slangasek> simple and robust, like a Bulgarian collective farm worker
[16:40] <pitti> ogra_: in the meantime, enjoy the beautifully colored dmesg :)
[16:40] <ogra_> pitti, thanks !
[16:40] <ogra_> lol
[16:41] <pitti> how can 5.000 lines of intertwined shell scripts be anything else!
[16:41] <ogra_> tall that all these crazy guys that write their stuff in C++
[16:42]  * ogra_ still hopes for a libreoffice shell port one day :)
[16:42] <Laney> someone made us all use Qt :(
[16:42] <pitti> TBH I'm not entirely sure whether I dislike C++ or sysvinit more :)
[16:42] <ogra_> heh
[16:42] <cjwatson> pitti: debootstrap doesn't have any sensible way to process multiple Packages files, so no
[16:42] <pitti> 'nuff trolling for the evening
[16:43] <cjwatson> You might as well just JFDI
[16:43] <pitti> cjwatson: ack, that's what I thought; thanks for confirming
[16:43] <pitti> cjwatson: yeah, I went that route now
[16:43] <cjwatson> You can do it by manually constructing a unified view, but given it's already broken it's not worth it ...
[16:44] <cjwatson> slangasek: well, I roped pitti in because I hadn't debugged it far enough to know that I shouldn't :)
[16:44] <pitti> cjwatson: that's fine; I now know more about insserv and related bugs than I ever desired :)
[16:45] <pitti> (since roughly the Malta sprint, and having fun breaking utopic with xnox)
[16:45] <cjwatson> roadmr: your bug is the same as the subject of the last few pages of discussion here, BTW
[16:46] <roadmr> cjwatson: oh! fun, I'll read the backscroll more carefully, I got a bit distracted
[16:46] <dobey> pitti: does being langpack-ified even provide any useful advantage any more?
[16:47] <pitti> dobey: smaller deb/image size mostly, and the ability to update/add translations post-release/decoupled from landings
[16:48] <dobey> pitti: we have a way to update langpacks and install additional ones on the phone, separate from a full image update?
[16:48] <pitti> dobey: but mostly, we already have langpacks for the packages in main, so we have to use them anyway
[16:48] <pitti> dobey: no, they still come through image updates
[16:49]  * ogra_ scratches head and wonders what udev-finish is or does ... 
[16:49] <pitti> so this is mostly about consistency, and not having 80% of the deb's translations use one method and 20% use the other
[16:49] <ogra_> i just noticed it gets execute on phone suspend
[16:49] <ogra_> *executed
[16:50] <pitti> ogra_: that's a bug; it's supposed to only run during boot, no need to run at suspend
[16:50] <ogra_> pitti, what does it do actually ?
[16:50] <ogra_> the upstart job talks about copying rules around
[16:50] <pitti> ogra_: it only moves dynamic rules which were generated in initramfs/very early boot from /run/ to /etc/udev/rules.d/
[16:51] <pitti> which is pretty much just 70-persistent-net.rules these days
[16:51] <ogra_> oh well, then we should probably override it as a whole
[16:51] <pitti> (totally not interesting on a phone, FTR)
[16:51] <ogra_> since there is no writable target it could use
[16:51] <pitti> ogra_: the more interesting question is what triggers it on suspend
[16:51]  * ogra_ makes a note to add an override .... 
[16:51] <cjwatson> dobey: wouldn't be that hard to do
[16:51] <pitti> start on (startup and filesystem and started udev and stopped udevtrigger and stopped udevmonitor)
[16:52] <ogra_> pitti, yeah, thats too
[16:52] <dobey> cjwatson: what wouldn't be?
[16:52] <pitti> ogra_: do you get udev restarts or anything similar during suspend?
[16:52] <cjwatson> dobey: 17:48 <dobey> pitti: we have a way to update langpacks and install additional ones on the phone, separate from a full image update?
[16:52] <ogra_> pitti, we shouldnt and i dont see any in syslog ...
[16:52] <cjwatson> the last thing you said :)
[16:53] <ogra_> pitti, we stop udev during boot though ... since it would clash with ueventd in the container
[16:53] <ogra_> and only start it again after the container is up and has loaded frimware and stuff
[16:53] <pitti> with an additional glibc patch we could build click langpacks, yes; but not sure whether that's worth the trouble, given how often we'll push out new images anyway
[16:53] <pitti> ogra_: but is it stopped for suspend?
[16:53] <ogra_> pitti, not explicitly, no
[16:54] <pitti> ogra_: but anyway, even if you did, it's a big "and" condition
[16:54] <dobey> cjwatson: eh, i don't much see the point really. i'd rather just get rid of langpacks :)
[16:54] <pitti> ogra_: I wonder if there's some kind of "initctl monitor" to see what's going on
[16:54] <cjwatson> pitti: shouldn't need that, just have a hook symlink them into the right place
[16:54] <ogra_> pitti, yes, got it in front of me
[16:54] <pitti> dobey: fair enough, we just need to do it for the whole distro then
[16:55] <ogra_> i wonder if there is a hack somewhere or some such that calls udevtrigger
[16:55] <cjwatson> dobey: the point would be a carrier that wants to do its own translations for their market
[16:55] <pitti> ogra_: that would be really wrong; but even that wouldn't explain how all 5 conditions would be simultaneously true
[16:55] <dobey> cjwatson: but they can just build a custom image with their translations too.
[16:55] <ogra_> pitti, oh, indeed ... not an "or"
[16:55] <pitti> dobey: not if they are shipped in the actual application debs
[16:55] <cjwatson> dobey: not without modifying our rootfs, which we want to avoid carriers doing
[16:56] <ogra_> pitti, might be it hung until that suspend/resume cycle asnd i just get that syslog line because it finally timed out
[16:56] <cjwatson> dobey: being able to do it in a click package would let them just ship such a thing in their custom tarball
[16:56] <dobey> cjwatson: not if the system just supported translations in /custom or whatever
[16:56] <cjwatson> dobey: the preferred architecture for supporting things in /custom is by way of click packages, where possible
[16:57] <cjwatson> (of course it isn't always possible, but where it is)
[16:57] <dobey> cjwatson: right, but it doesn't mean our translations necessarily need to be in those clicks
[16:57] <cjwatson> sure
[16:58] <jdstrand> hallyn: that's a bummer. with KSM_ENABLED=0 I just saw 4 VMs go down
[16:58] <pitti> ogra_: ah, good point; so you only saw it once, not for each suspend?
[16:59] <ogra_> pitti, well, i'm looking at a syslog on a bug :)
[16:59]  * jdstrand goes back to saucy qemu
[17:00] <dobey> cjwatson: has that been a concern brought up by an carriers? (just curious)
[17:00] <cjwatson> dobey: not that I know of (though I wouldn't necessarily expect to); I'm anticipating
[17:00] <dobey> well, at least my phone doesn't have all the translations for pidgin on it any more :)
[17:01] <cjwatson> that's the other benefit of language packs, makes it much easier to select which translations we want to ship at the last minute
[17:03] <jdstrand> hallyn: (a reboot didn't bring them back)
[17:11] <jdstrand> hallyn: shoot, it was all of my security vms
[17:11] <jdstrand> hallyn: I did the 'uvt update' (ie, the commands stated in the bug) earlier today and they are all gone (with KSM disabled)
[17:12] <jdstrand> sarnold: fyi, ^
[17:17] <bdmurray> cjwatson: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/use-devel/+merge/231427 <- fix for the sru-report
[17:19] <pitti> cjwatson, slangasek: FYI, autopkgtest nodes are super-busy as dbus and other stuff also landed; so if it's urgent, you might consider fast-tracking util-linux?
[17:19] <cjwatson> bdmurray: ah, so my fault, doh
[17:20] <cjwatson> bdmurray: merged, thanks
[17:20] <bdmurray> cjwatson: no problem
[17:20] <cjwatson> arges: ^-
[17:21] <pitti> Laney: FTR, I'm afraid the colord failure looks real
[17:24] <cjwatson> slangasek: I think something like that dependency did show up as a problem in trusty->utopic (in fact IIRC something similar blew up all utopic builds for a while).  Last I heard it was on Michael's plate to investigate as an apt bug)
[17:24] <cjwatson> So I would say on the contrary there are some reasons to believe that reintroducing that dependency would be a problem :-/
[17:28] <slangasek> cjwatson: mm.  Well, we'll have to check what happens
[17:28] <jtaylor> mh microrelease SRUs need an microrelease exception right?
[17:29] <jtaylor> even if I normal non version bumping sru would have the same diff?
[17:30] <cjwatson> pitti: hm, I think I'll leave it as I'm about to finish for the day and don't want to end up breaking something else
[17:36] <pitti> fun, *now* the lxc autopkgtest reproduces the util-linux bug
[17:36]  * pitti wants debootstrap with -proposed to discover these
[17:37] <pitti> Laney: ^ FTR, will re-try once util-linux lands (that's currently blocking dbus)
[17:38] <ogra_> pitti, i thought dbus was blocked on purpose
[17:38] <ogra_> since the landing is scarily huge
[17:49] <pitti> ogra_: ah right, that too
[17:50] <ogra_> phew ... dont scare me :)
[17:50] <pitti> ogra_, slangasek: ok, nevermind the fast-tracking; kdepimlibs is "always failed", the others all suceeded now, so it'll go in with the next publisher
[17:50] <ogra_> yay
[18:17] <pitti> [ubuntu/utopic] util-linux 2.25-8ubuntu2 (Accepted)
[18:18] <pitti> slangasek, ogra_: there you go ^ kthxnight!
[18:18] <slangasek> pitti: g'night
[18:18] <ogra_> pitti, thanks a lot !!!
[18:25] <exarkun> is there anything I can do to bring some attention (and hopefully a resolution) to <https://bugs.launchpad.net/bugs/1356931>?
[19:16] <cjwatson> jdstrand: Any luck with apparmor and perl 5.20?  I was hoping to be able to copy my staging PPA into utopic-proposed tonight or tomorrow, so that I don't have to deal with too much skew
[19:17] <jdstrand> cjwatson: sorry no. I had a rather catastrophic vm and unrelated unity7 situation that really destroyed my productivity
[19:18] <jdstrand> I'm about back to where I was when we last spoke, but I have to get another update out. that said, I plan to look at this tonight/tomorrow morning
[19:27] <cjwatson> jdstrand: OK, thanks.  Something like https://launchpad.net/ubuntu/+source/libtemplate-perl/2.24-1.2 might be a helpful course to follow for the .install part
[19:28] <jdstrand> maybe I can look at it now while waiting for some long running stuff
[19:32] <jdstrand> yes, that will work nicely
[19:33] <jdstrand> cjwatson: so, how does this work with traincon-0?
[19:35] <cjwatson> jdstrand: well, that's part of why I'm being careful to stage in a PPA
[19:36] <cjwatson> jdstrand: I don't think perl realistically affects the phone a whole lot as long as it's generally installable, but also, hopefully we'll manage to get a promoted image soon
[19:39] <jdstrand> cjwatson: I wasn't clear. libapparmor-perl is on the phone, and so is apparmor (of course). so my question is really do you want me to upload to your staging ppa or give you a debdiff, or do something else
[19:40] <sarnold> libapparmor-perl is on the phone? why? are we the only thing dragging in perl?
[19:41] <jdstrand> cjwatson: also, do I need to chmod +x the .install file or is that discovered by the shebang?
[19:42] <jdstrand> sarnold: apparmor depends on it
[19:42] <jdstrand> sarnold: we removed all the stuff that dragged in a ton of perl deps long ago
[19:43] <jdstrand> sarnold: (this is due to aa-exec iirc)
[19:43] <sarnold> jdstrand: yeah, I remmeber being thrilled that apt-get install apparmor-utils no longer drags in 20 megs of perl things, but I can't recall what's left that's in perl
[19:44] <jdstrand> aa-exec. jj wrote a C version, but we haven't moved to it yet
[19:44] <sarnold> jdstrand: ouch! man, I had a C aa-exec four or five years back, I thought jj pushed a C version he wrote slightly later..
[19:45] <jdstrand> it isn't that ouchy. the libapparmor-perl deb is only 27k
[19:46] <jdstrand> I think 120k unpacked
[19:46] <sarnold> but perl is 11-18 megs...
[19:46] <jdstrand> perl is needed on the phone
[19:46] <jdstrand> (dpkg)
[19:47] <sarnold> ohh, okay
[19:48] <jdstrand> yeah, if libapparmor-perl were the last thing keeping perl on the phone, I imagine we'd have a plethora of aa-exec C implementations :)
[19:48] <sarnold> sorry for the distraction but I was quite wrong on several counts, heh
[19:49] <jdstrand> cjwatson: I see libtemplate-perl.install is executable, so I'll do the same
[19:50] <jdstrand> hmm, that may not work right. well, I'll figure it out
[20:11] <exarkun> is there anything I can do to bring some attention (and hopefully a resolution) to <https://bugs.launchpad.net/bugs/1356931>?
[20:17] <jdstrand> cjwatson: I tell you what. I have some preliminary apparmor packages for this. I will test them and when I am satisfied, I will upload them to https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages. I will then ping you and you can copy them into your staging ppa or the archive as desired. does that work?
[20:27] <cjwatson> jdstrand: Oh, right, yeah that last works fine
[20:28] <jdstrand> cool
[20:28] <cjwatson> jdstrand: You need to chmod +x and use a 3.0-ish source format, yes
[20:28] <cjwatson> jdstrand: I'll need to do a without-binaries copy, i.e. rebuild in my PPA
[20:28] <jdstrand> yeah, the +x did work and we already had 3.0 (quilt)
[20:29] <cjwatson> sarnold: yeah, perl is Essential: yes, it ain't going :)
[20:29] <cjwatson> well, perl-base
[20:29] <cjwatson> getting rid of perl/perl-modules might be helpful, but I have no idea how far away we are from that on the phone
[20:29] <jdstrand> thanks
[21:27] <arayaq> Hi! I'm working on bug #1325777, however I've got to a point where I need elementary developers feedback on how to continue, is anyone here?
[21:27] <arayaq> (If not, how can I get an invite to Slack, I don't see aroman around here anymore)
[21:28] <arayaq> oops
[21:28] <arayaq> Wrong channel
[21:28] <dobey> yeah, was going to ask ask in their channel :)
[21:49] <TJ-> quantal archive /ubuntu/dist/quantal* are missing from both archive.ubuntu.com and old-releases.ubuntu.com
[21:52] <TJ-> correction: user was trying the URL old-releases.archive.ubuntu.com ... which redirects silently to archive.ubuntu.com
[23:05] <cjwatson> TJ-: side-effect of the wildcard DNS for non-explicitly-assigned country subdomains
[23:06] <TJ-> cjwatson: Yeah... confused the heck out of me for a moment until I realised the responses were identical :)