[05:17] <pitti> Good morning
[05:32] <infinity> pitti: Just the man I've been waiting for.
[05:32] <pitti> hey infinity
[05:33] <infinity> pitti: We need adt-britney love for wily.
[05:33] <pitti> infinity: yep, jibel will set up the wily jobs this morning
[05:34] <pitti> I'll create VMs in the meantime (with the usual dist-upgrade hackery until we have daily cloud images)
[05:49] <pitti> wgrant, infinity: is the ddeb magic turned on in LP now?
[05:50] <pitti>  pkg-create-dbgsym | 0.65        | wily             | source, all
[05:50] <pitti> oops!
[05:50]  * pitti copies from vivid-updates
[05:55] <infinity> pitti: I'm not sure what the state of the magic is.
[05:59] <pitti> https://launchpad.net/ubuntu/+source/dfc/3.0.5-0.1/+build/7385174
[05:59] <pitti> that's a recent build
[05:59] <pitti> apparently it's on \o/
[06:03] <Unit193> You're going to want to talk to Debian about ddebs soon, I believe.
[06:07] <pitti> infinity: all the old stuff in vivid-proposed is going to be moved to wily, right? so that enabling -proposed stops being a potential disaster
[06:07] <pitti> wily-proposed, I mean
[06:08] <infinity> pitti: It's all moved as of about now.
[06:08] <infinity> pitti: Plus a publisher cycle.
[06:08] <pitti> yay, thanks
[06:09] <RAOF> Now's probably a reasonable time for some AA training...
[06:09] <infinity> RAOF: A few hours ago before I copied all of thise stuff by hand would have been a better time.
[06:09] <RAOF> infinity: Hah!
[06:10] <infinity> pitti: I *think* britney is ready to go, but hard to tell since it explodes with "OMG ADT NO WORKIE, POOF".
[06:11] <infinity> pitti: But, I'm working on the theory that once that's fixed, it'll Just Work.
[06:11] <wgrant> pitti: ddebs are enabled on most archives that matter, but I haven't done a recheck that I caught all of them.
[06:11] <wgrant> Will do so now.
[06:11] <pitti> wgrant: at least looks good for wily builds
[06:11] <pitti> wgrant: I copied the latest mangler now
[06:11] <infinity> Something's actually built in wily that created ddebs?
[06:11] <pitti> infinity: yes, e. g. https://launchpad.net/ubuntu/+source/dfc/3.0.5-0.1/+build/7385174
[06:11] <wgrant> pitti: Yeah, the primary archive, security PPAs and silos have all been enabled since Thur/Fri.
[06:12] <pitti> wgrant: I'll walk through https://launchpad.net/ubuntu/+source/dfc/3.0.5-0.1/+build/7385174 and see if any of the failures were due to the old mangler
[06:12] <pitti> wgrant: sorry, through https://launchpad.net/ubuntu/wily/+builds?build_text=&build_state=failed&arch_tag=all
[06:12] <infinity> Oh wow, that magically started building.  Huh.
[06:12] <infinity> Must have missed a mass give-back right before release. :/
[06:12] <infinity> Oh well.
[06:12] <wgrant> infinity: Copied to proposed.
[06:12] <wgrant> Oh, right, that's what you mean.
[06:17] <pitti> wgrant: ok, all the FTBFSes are not due to the old mangler, so all good
[06:32] <pitti> wily testbed VMs created in CI
[06:39] <pitti> infinity: https://launchpad.net/ubuntu/+source/jemalloc/3.6.0-3 looks like a leftover, ok to remove that from vivid-proposed?
[06:40] <pitti> or was that on purpose by any chance? (I suppose you moved over with a script, so odd that this one got stuck halfway)
[06:40] <infinity> pitti: Script.  Hah.  No, it was by hand, I just missed deleting that one.
[06:41] <pitti> infinity: well, script == for p in <packages>; do copy-package; remove-package; done
[06:41] <infinity> pitti: I should script it, but it needs to be smarter than "copy to x, delete from y" because LP treats with and without binaries differently depending on if there are completed builds or not.
[06:41] <infinity> pitti: Anyhow, deleting.
[06:41] <pitti> ah, ouch
[06:42] <pitti> infinity: ah, for built ones we need to copy the binaries, I see
[06:42] <infinity> pitti: We do, and you can't say "copy with binaries" for all of them, cause LP tosses a fit if there are no binaries. :P
[06:43] <infinity> Still, not that hard to script, just do the binary check first, I'm just allergic to the LP API, and doing it by hand gives me a chance to examine what's in proposed.
[07:50] <pitti> jibel, infinity: I'm not sure if the snakefruit setup is complete -- http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html still points to adt-vivid-* jobs, not adt-wily-* ?
[07:51] <infinity> pitti: It's not running, because it crashes when your end doesn't work. :P
[07:51] <infinity> pitti: Lemme try one by hand.
[07:51] <pitti> infinity: right, jibel is setting that up right now; he just wondered who set up britney, and I wondered if it needs more changes
[07:52] <infinity> pitti: I did, but it might not be completely right.  No idea.
[07:52] <pitti> infinity: nah, don't bother yet
[07:55] <jibel> pitti, infinity the CI infra doesn't know about wily yet, and I am not allowed to update the code on jenkins master
[07:56] <pitti> meh - CI vanguard o'clock?
[07:57] <jibel> someone's on it
[07:57] <LocutusOfBorg1> sil2100, was it ok to review? I don't remember
[07:57] <LocutusOfBorg1> oops s/ sil2100 / Unit193
[07:58] <sil2100> !
[07:58] <pete-woods> pitti: just nagging you about this MR again https://github.com/martinpitt/python-dbusmock/pull/9/files
[07:58] <pitti> pete-woods: ack, nag taken :)
[07:58] <pete-woods> :)
[08:08] <Laney> @pilot in
[08:09] <Laney> mdeslaur / arges: ↑ lies?
[09:29] <infinity> pitti: When the autopkgtest stuff is all working, can you let cjwatson know?  I'm handing off to him, since it's 3:30am here.
[09:29] <pitti> infinity: ack, will do
[09:29] <pitti> infinity: sleep well!
[09:30] <pitti> infinity: looks mostly ok now, just the queue is awfully long
[09:52] <Laney> jamespage: hiya, could you take a peek at bug #1374999 - nothing to sponsor currently, right? could unsubscribe ubuntu-sponsors then.
[09:53] <jamespage> Laney, agreed - I'll get tinoco to ping me directly once he has something ready - I need to coordinate that with other openstack updates anyway
[09:53] <jamespage> Laney, unsubbed sponsors
[09:53] <Laney> thanks!
[09:53]  * Laney is Purging Old Stuff
[09:56] <jamespage> Laney, nice one
[10:00] <LocutusOfBorg1> is the wily import started?
[10:01] <LocutusOfBorg1> I see something has been built for vivid
[10:01] <LocutusOfBorg1> s/vivid/wily
[10:02] <cjwatson> only sort of
[10:02] <cjwatson> please stop asking for the time being, we'll tell people when it starts
[10:05] <LocutusOfBorg1> thanks, sorry if I'm bothering, I asked many syncs from experimental, I would like to see if they are now sync'd from unstable again
[10:05] <pitti> LocutusOfBorg1: they will be
[10:06] <LocutusOfBorg1> thanks!
[10:54] <pitti> cjwatson, infinity: ah, distro-info bug fixed, and the queue is catching up -- first wily test results! http://d-jenkins.ubuntu-ci:8080/view/Wily/view/AutoPkgTest/
[10:56] <pitti> aptdaemon failure seems genuine, I figure some distro-info/python-apt/whatever needing an update for wily
[11:01] <mdeslaur> @pilot out
[11:01] <mdeslaur> Laney: thanks, forgot to check out apparently
[12:02] <tinoco> jamespage: hello james, freyes has taken this case. i remember my fix did not fix it entirely (at least for all cases, emc backend did work though)
[12:02] <tinoco> freyes: pls update james regarding the iscsi volume detach issue whenever you have something
[12:02] <tinoco> jamespage: thank you!
[12:47] <cjwatson> pitti: So I'm a little confused, do you know why http://people.canonical.com/~ubuntu-archive/proposed-migration/wily/update_excuses.html thinks aptdaemon passed?
[12:48] <cjwatson> oh, maybe that just needs to be rerun
[12:48] <pitti> jibel: ^ could it be that vivid's results.history was copied after that ran?
[12:48] <pitti> cjwatson: me too
[12:49] <cjwatson> I'll try rerunning p-m
[12:53] <cjwatson> 2015-05-05 12:52:54,113 DEBUG cmd: ['rsync', '-a', '--remove-source-files', 'rsync://tachash.ubuntu-ci/boottest/wily/out/', '/home/ubuntu-archive/proposed-migration/boottest/data/boottest/wily-proposed/krillin/work']
[12:53] <cjwatson> rsync: change_dir "/wily/out" (in boottest) failed: No such file or directory (2)
[12:53] <cjwatson> rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1536) [Receiver=3.0.9]
[12:53] <cjwatson> pitti,jibel: ^- noticed by chance in p-m logs
[12:53] <pitti> oh, I specifically didn't change RELEASE= for boottest
[12:53] <jibel> psivaa, fginther ^
[12:53] <pitti> in lp:a-p-t
[12:54] <pitti> AFAIUI we do *not* want to move the phone to wily
[12:54] <pitti> but keep vivid, or vivid+PPA, or a vivid-based RTM release or something
[12:54] <pitti> so boottest should not run on wily, at least not right now
[12:54] <cjwatson> we don't want to move the phone to wily yet, but we also don't want to let the quality of wily drift
[12:54] <pitti> psivaa, fginther ^
[12:54] <cjwatson> (per slangasek)
[12:55] <pitti> ah, so will we have a channel for wily touch builds, but don't advertise it?
[12:55] <cjwatson> that was my understanding
[12:55] <cjwatson> ICBW
[12:58] <jibel> pitti, cjwatson a possible explanation is that aptdaemon/policykit passed in vivid, and the result is still valid in wily because policykit didn't retrigger a test of aptdaemon in wily ie policykit in wily didn't break aptdaemon.
[12:58] <pitti> ok; so I guess CI needs to create these dirs
[13:24] <fginther> pitti, jibel, I've created the rsync dirs on tachash for boottest. Will take a closer look at what boottest should really be testing in a moment
[13:38] <dholbach> slangasek, can you join #ubuntu-uds and #ubuntu-uds-core-1?
[13:39] <Laney> @pilot out
[13:40]  * dholbach hugs Laney and arges
[13:40] <arges> oops I forgot to pilot out : )
[13:41] <arges> @pilot out
[13:42]  * Laney hugs dholbach back
[13:45] <cjwatson> jibel: I guess that makes sense, but why did aptdaemon run in wily at all then?
[13:49] <slangasek> dholbach: done
[13:49] <dholbach> great
[13:53] <Orphis> Hey, does anybody know what's the progress of apt "by-hash" update status?
[13:54] <rbasak> "chdist create" for wily, when running on vivid, didn't seem to create or populate .chdist/.../etc/apt/trusted.gpg.d/ I get gpgv failure warnings. Is this a bug?
[13:54] <jibel> cjwatson, I don't know yet, 8 package tests have been triggered because packages were considered newer in wily, but the version is the same in vivid, and there is no new upload in wily
[13:54] <Orphis> And is there any plan on using it in future Ubuntu release?
[13:55] <rbasak> Orphis: I think support in apt will get synced this cycle. Then it needs to be enabled in the archive, and we need to switch to InRelease. I'm not sure about the status of those two parts. I think we're still planning on switching to it. mvo may know more but I don't see him online right now.
[13:55] <Orphis> rbasak: Do you know if apt-ftparchive supports generating repositories for this format?
[13:55] <rbasak> I don't think it does right now.
[13:56] <rbasak> I did have a script that takes a regular archive and adds the by-hash information.
[13:56] <rbasak> Not sure what happened to it.
[13:56] <Orphis> That's "easy" to add on top of existing index generation scripts though
[13:56] <rbasak> Right. The by-hash design allows for the extra stuff to be added to downstream mirrors even without upstream support.
[13:56] <cjwatson> We'd certainly want to support it in Launchpad, rather than messing about on mirrors.
[13:57] <Orphis> Is Launchpad the main ubuntu repository?
[13:57] <rbasak> Sure - it's easier to test by decoupling that though.
[13:57] <cjwatson> Orphis: Yes.
[13:57] <rbasak> (eg. on a local mirror)
[13:57] <cjwatson> Rather, Launchpad is the software that (among other things) publishes the repository.
[13:58] <Orphis> Mirrors will probably have to be smarter when mirroring, like handle packages first, then by-hash, then (In)Release(.gpg)
[13:58] <rbasak> "cp -a ~/.chdist/{vivid,wily}/etc/apt/trusted.gpg.d" fixed my chdist issue. Not sure if it's a bug in chdist or not.
[13:58] <cjwatson> Orphis: Mirrors already have to mirror pool then dists.
[13:59] <Orphis> Right, but they should still do a smart dists mirroring not to break everything :)
[13:59] <ev> can you statically link LGPL v2 code in a GPLv3 codebase?
[13:59] <cjwatson> I think they already have to do that too.
[13:59] <Orphis> Great
[13:59] <rbasak> Orphis: or, simplify the smarts to say "sync new files first, then modified files, then deleted files". Pool then dists would also work but best to sync deleted files last in that case.
[13:59] <Orphis> Do you know what software they're using?
[14:00] <rbasak> Oh, and InRelease last after everything else in dists.
[14:00] <Orphis> rbasak: That's a smarter way to do it too, yes
[14:00] <Orphis> Indeed
[14:00]  * zyga wonders what generates https://ftp-master.debian.org/new.html
[14:00] <zyga> and if there's an API for it
[14:01] <cjwatson> software> varies but we recommend https://wiki.ubuntu.com/Mirrors/Scripts
[14:01] <cjwatson> deletion isn't a big issue due to the stay of execution
[14:03] <Orphis> To serve the internal repository at my company, I have some software that is smart enough to keep a session based on the IP address of the client and keeps multiple versions of the index. When an update session starts (through Release.gpg or InRelease download), it tracks which index it should serve and avoids all issues. And on the other side, the index is updated automically using a smart symbolic link
[14:04] <cjwatson> yeah nobody wants to do that on public Ubuntu mirrors though :)
[14:04] <Orphis> It works great even for frequent updates of the repository and serves the right index, provided no 2 machines with the same IP are updating at the same time during an update
[14:04] <Orphis> Indeed
[14:04] <cjwatson> and anyway NAT
[14:04] <Orphis> I'm just looking for a solution that would work for my infrastructure to mirror your packages properly in different sites
[14:05] <Orphis> Yes, it's good for a private infra, not so much for external people, although that would reduce errors for people and shouldn't add more
[14:05] <Orphis> It's not 100% fail-safe and is transparent to old clients
[14:06] <Orphis> When it works, it works, when it doesn't, there would have been an error anyway without it
[14:07] <Orphis> How often is the ubuntu index regenerated? And how long does it usually take?
[14:07] <cjwatson> usually multiple times per hour
[14:07] <cjwatson> how long> depends exactly what you mean by that question ...
[14:08] <Orphis> How much time is spent between the moment you ask for the index to be built and it's actually done?
[14:09] <cjwatson> ev: yes, http://www.erisian.com.au/wordpress/2007/07/06/gplv3-and-debian has a summary
[14:11] <cjwatson> Orphis: (a) nobody asks for it explicitly (b) varies quite a bit depending on how much work it has to do; typical would be around 5-15 minutes
[14:11] <cjwatson> Orphis: that isn't relevant to mirrors though ...
[14:12] <cjwatson> I mean, frequency can be, but publisher runtime isn't
[14:12] <Orphis> No, but it's interesting to compare infrastructures of big repositories :)
[14:12] <cjwatson> right
[14:13] <Orphis> We have continuous deployment for some software, so we publish it in our repository and we block on the indexing. Having a fast indexing is always nice then
[14:13] <smoser> hey. bug 1446767
[14:13] <smoser> is in vivid-proposed.
[14:14] <smoser> is it acceptable to sign and upload 4.3.1-5ubuntu2.1  ? to wily ?
[14:14] <smoser> or.. how should that be done.
[14:14] <smoser> binary copy?
[14:15] <cjwatson> just copy with binaries to wily-proposed, if it isn't there already.
[14:16] <cjwatson> Orphis: small repositories there isn't really a good excuse for taking more than a small number of seconds :)
[14:16] <Orphis> cjwatson: Well, I have a big one!
[14:17] <Orphis> With multiple copies of some packages for gradual rollouts and stuff
[14:20] <Orphis> cjwatson: While you're around, something a bit related I couldn't get an answer for. Is trusty-updates a superset of trusty-security?
[14:20] <smoser> cjwatson, i don't do this very often.. can you confirm http://paste.ubuntu.com/10990160/ is right?
[14:21] <smoser> er.. do i coyp to wily-proposed
[14:22] <cjwatson> smoser: You should copy to wily-proposed, indeed.
[14:22] <cjwatson> smoser: Otherwise it's fine.
[14:22] <smoser> thanks
[14:23] <cjwatson> Orphis: More or less.  All updates to -security are automatically copied into -updates provided that they don't clash.
[14:24] <doko_> xnox, barry: isn't the python session now ongoing?
[14:24] <cjwatson> Orphis: There's a slight delay on that, and in any case -security still exists separately in part because that means we can point users' sources.list files at security.ubuntu.com for that suite, so that they get security updates quickly regardless of the vagaries of mirroring.
[14:24] <Orphis> cjwatson: So one should be safe enough to use only updates and not security, provided the updates repository is properly mirrored
[14:25] <cjwatson> Orphis: I can't recommend it, but I've explained the behaviour.
[14:25] <Orphis> Thank you
[14:25] <Orphis> Updates aren't applied automatically, so the slight delay is probably not relevant in that case
[14:25] <Orphis> Well, in *my* case
[14:25] <cjwatson> Probably not.
[14:27] <barry> doko: in 90m i think
[14:27] <xnox> doko: UTC time is 14:27
[14:28] <dholbach> doko, http://summit.ubuntu.com/uos-1505/2015-05-05/ - as barry said
[14:28] <doko> argh, won't be there then
[14:28] <xnox> doko: that's alright, it's not like we've been planning python3-only for a few years now....
[14:28] <ev> cjwatson: thanks!
[14:28] <barry> doko: darn.  can you pvtmsg me any links you want to share?  e.g. py3 work needing done?
[14:32] <xnox> where can i get recent go for 14.04 ?
[14:33] <doko> xnox, apt-get install gccgo
[14:34] <xnox> doko: what version of go does that translate to on 14.04?
[14:34] <doko> ahh, 14.04, the ubuntu-toolchain-r/test PPA
[14:34] <doko> 1.4.2
[14:35] <xnox> well i need at least 1.3 i think
[14:37] <xnox> hm i wonder if there is environment variable to do -compiler gccgo
[14:38] <doko> barry, xnox: for python3.5 in 15.10, somebody would need to sit down and see, if we have the resources to do 3.5 as supported version, or if it's too early (will be beta status at this time)
[14:38] <doko> xnox, GCCGO
[14:50] <cjwatson> pitti: do you know of any reason not to open at this point?  there's the lack of boottests, but I think we can live with that in the short term
[14:51] <pitti> cjwatson: fine from my POV;  if the toolchain (gcc 5?) is set?
[14:52] <cjwatson> apparently set, gcc 5 not default yet
[14:52] <cjwatson> (and not for opening)
[14:52] <cjwatson> I just want to get branch-distro sorted
[14:54] <pitti> cjwatson: do we have a newer distro-info and debootstrap already?
[14:54] <pitti> quite some stuff will fail without that, I figure
[14:54] <cjwatson> pitti: no, but be my guest
[14:54] <cjwatson> pitti: well, we do have a newer distro-info-data
[14:54] <pitti> cjwatson: ok; I have two UOS sessions now, noted for tomorrow morning
[14:54] <pitti> cjwatson: yes, that's what I meant
[14:54] <cjwatson> debootstrap isn't opening-critical
[14:54] <pitti> right, I locally added the symlink to the CI machines
[14:55] <pitti> they have wily containers now
[15:22] <rbasak> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.vivid/rdepends/python2.7/ works but http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.vivid/rdepends/python2.7 redirects to http://people.canonical.com/germinate-output/ubuntu.vivid/rdepends/python2.7/ which then 404s (dropped off ~ubuntu-archive)
[15:22] <cjwatson> we'll start up auto-syncs soon
[15:22] <cjwatson> rbasak: sounds like a bug in the IS-managed proxy on lillypilly
[15:22] <rbasak> cjwatson: I'll file an RT then I guess? Thanks.
[15:22] <cjwatson> I think
[15:23] <cjwatson> it probably needs to rewrite the redirect or something
[15:29] <dholbach> woohooo!
[15:55] <pitti> cjwatson: \o/
[15:56] <pitti> cjwatson: https://launchpad.net/ubuntu/wily/+builds?build_text=&build_state=built&arch_tag=amd64 doesn't have builds with ddebs that are more than 30 mins old yes, but I'll check tomorrow that the ddeb import worked
[15:56] <pitti> cjwatson: at least they are being produced and published in LP now, so we won't lose them \o/
[16:00] <bdmurray> barry: where are we with the python-pip SRU?
[16:37] <smoser> anyone have thoughts on http://paste.ubuntu.com/10990807/
[16:37] <cjwatson> smoser: I'd strongly suggest talking with the Debian vim maintainers
[16:37] <cjwatson> they may have past experience
[16:38] <smoser> essentially replace python with python3 in vim. it doesn't actually build (a python3 test fails), but wonder if its the  right thing to do to replace Provides.
[16:38] <cjwatson> and Debian is targeting a pretty widespread switch to python3 for stretch so there's no good reason for this to be Ubuntu-specific
[16:38] <cjwatson> also, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729924
[16:38] <cjwatson> past history there you're skating over :)
[16:39] <smoser> cjwatson, thanks.
[16:47] <pitti> stgraber: lxc/wily failed because of debootstrap missing wily, I'll upload that
[16:48] <stgraber> pitti: yeah, I assumed it'd be something like that so I didn't even bother checking
[16:48] <stgraber> pitti: I usually start worrying about adt around a week after the series opened :)
[16:49] <pitti> cjwatson: uploaded debootstrap FTR
[16:50] <pitti> oh, Laney beat me to it
[16:50] <pitti> meh @ pull-lp-source not working yet
[16:50] <Laney> pow pow pow
[17:25] <zyga> barry: do you know, perhaps, what generates the debian NEW index? https://ftp-master.debian.org/new.html
[17:25] <zyga> barry: I wanted to write an app that loads the same data and presents it in a QML app
[18:00] <Laney> zyga: you could parse https://ftp-master.debian.org/new.822
[18:08] <zyga> Laney: fantastic, that's excactly what I wanted!
[19:47] <Noskcaj> How can i see what packages i have upload rights for?
[20:12] <bdmurray> seb128: In case you didn't notice the vivid line is fixed now.
[20:36] <seb128> bdmurray, did notice; thanks
[21:25] <utlemming> pitti, stgraber: which package provides the preseed files on the cdrom?