[02:00] <KaZeR> wgrant: i can confirm that now my test to upload from a git branch to a launchpad series works as expected
[02:00] <KaZeR> there's one little annoyance tho:
[02:01] <KaZeR> after the upload it is in "need review" state
[02:02] <KaZeR> when reviewing, i see nothing wrong, and if i validate the current values it gets imported (this is actually not related to the series i think, i saw that in trunk too )
[02:03] <wgrant> A cronjob automatically approves things where it can, but it can take an hour or more for it to get to them.
[02:03] <wgrant> But in a new series you'll probably have to approve everything manually the first time, as there are no existing paths to match against.
[02:08] <KaZeR> that makes sense.
[02:08] <KaZeR> thanks a lot. i'll do more tests tomorrow but it's a good step forward for our automation
[02:09] <KaZeR> have a nice $localtime!
[04:47] <helmut> wgrant: hey, long time ago you were the contact to talk to for launchpad's build profile support. is that still the case?
[04:48] <wgrant> helmut: Sure.
[04:48] <wgrant> helmut: Last I heard it was deferred indefinitely.
[04:48] <wgrant> But I haven't kept up to date on it for a while.
[04:48] <helmut> wgrant: meanwhile, the spec changed slightly (dropping the "profile." prefix and using disjunctive normal form)
[04:49] <helmut> wgrant: in particular, the spec finalized, the tooling was fixed and released with debian jessie
[04:49] <helmut> wgrant: furthermore, the tooling (dpkg, apt, sbuild, ...) is now deployed and in use
[04:50] <helmut> wgrant: worse (for you), packages are already using build profiles in debian successfully and need to be stripped so tha they can be imported to launchpad (example: nss)
[04:51] <helmut> wgrant: I believe that it is partially my fault to not having contacted you again after the jessie release that made using profiles feasible in debian. sorry about that.
[04:52] <helmut> wgrant: a week ago, the last (known) missing piece, pbuilder, was nmued. I am not aware of further issues on debian's infrastructure, so I consider profiles implemented there.
[04:52] <helmut> wgrant: do you know which parts in ubuntu need fixing? or how we could find out?
[04:54] <helmut> wgrant: in terms of software versions that are running your infrastructure, check the table at the top of https://wiki.debian.org/BuildProfileSpec
[04:56] <helmut> starting with vivid, you should have dpkg and apt support.
[04:56] <wgrant> Back, sorry. Let me see.
[04:57] <helmut> another example package is gem2deb
[04:57] <wgrant> We upgraded to modern sbuild just a couple of weeks ago, which was one of the remaining known hard bits.
[04:58] <helmut> indeed. sbuild received profile fixes late in the jessie cycle
[04:58] <helmut> sbuild 0.65.0-1 is said to be good
[04:58] <wgrant> The only things we're likely to care about are dpkg, python-apt, and sbuild, I think.
[04:58] <wgrant> As everything else should be running in the chroot.
[04:59] <wgrant> We're using a derivative of sbuild 0.65.2 at the moment.
[04:59] <wgrant> So it should be fine.
[05:00] <helmut> python-apt should be fine in utopic
[05:01] <helmut> on the debian side, dak was the first piece to reject profile using packages due to using python-apt. no changes were necessary beyond upgrading python-apt
[05:02] <wgrant> AFAICS that is probably also the case for us, though our sbuild depwait integration will likely require some further work.
[05:02] <wgrant> I see we've patched out the <cross> in our nss.
[05:05] <helmut> I expect quite a few packages to start using profiles soon. mostly <!nocheck> and <cross> profiles
[05:06] <wgrant> Indeed, it is good to see it finally happening. I'll have a look at what we need to fix.
[05:06] <wgrant> Most of Launchpad except the buildds is still precise, so there will be some python-apt backporting to do, but we're used to that by now!
[05:06] <wgrant> Thanks for keeping us updated.
[05:06] <helmut> wgrant: there are patches for such backports (i.e. implementing the syntax without implementing the feature)
[05:07] <helmut> tell me (or us at #d-bootstrap) which packages you need backports for and with luck we can point you to existing patches
[05:08] <wgrant> Will do. Thanks.
[08:59] <adrien_znc> hi, is it ok to ask general question about launchpad as a service rather than as code?
[09:00] <Tribaal> adrien_znc: it's usually better to acutally ask your questioninstead of asking if you can ask
[09:01] <Tribaal> (also, people might take a long time to answer - just a heads up)
[09:01] <adrien_znc> heh :)
[09:02] <adrien_znc> yeah, I'm quite used to IRC but really didn't know how separate the service and the code are
[09:03] <adrien_znc> let's take the hypothetical situation of launchpad's storage crashing hard: how easy would it be for a project to transition to another (temporary) hosting
[09:03] <adrien_znc> question absolutely not linked to current sourceforge's downtime
[09:06] <cjwatson> I think like most services it depends how much/tightly your project depends on what the service provides.  If it's just a git repository then obviously that's easy to push elsewhere.  But with something like bug tracking you're probably dependent on semantic details that other services won't mirror exactly, and of course URLs in other people's browser histories and such are pretty sticky.
[09:06] <adrien_znc> mingw-w64 is currently hosted on sourceforge and we had started talking about other hosting possibilities and our use of mailing-list restricts a lot what we can do along with our willingness to self-host (mail is such a pita) and with the recent addition of git support, we could probably use launchpad
[09:06] <adrien_znc> it's mostly for mailing-list and git
[09:07] <adrien_znc> that would mean a fairly transparent way to host mailing-lists (even in a degraded way) elsewhere without requiring subscribers to change anything on their side
[09:07] <adrien_znc> "degraded" being mostly for spam stuff if gmail isn't happy (and more often that not, it isn't)
[09:09] <cjwatson> LP mailing lists are going to have List-* headers coming out with launchpad.net addresses/URLs, so a little tricky.  I guess in a disaster recovery situation we could put mail forwarding in place for people if we had to.
[09:10] <cjwatson> (Although in a disaster recovery situation our sysadmins are rather more likely to be focused on getting things up and running again ...)
[09:11] <adrien_znc> yeah, of course :)
[09:11] <adrien_znc> I was wondering if something could be done from DNS on MX (I don't know/practice mail stuff enough so I might be dreaming on that)
[09:14] <cjwatson> All LP mailing lists are on the same MX.
[09:16] <adrien_znc> would it work to set the MX for our domain to LP's when everything goes well and switch it if something goes wrong?
[09:18] <cjwatson> So you could do that and advertise a posting address on your domain, but it wouldn't help with the List-* headers emitted by LP list mail
[09:19] <cjwatson> A lot of posters would likely end up trying to mail the @lists.launchpad.net address, and would expect subscriber management/information to be there
[09:21] <cjwatson> If you decide you don't care about that, and can deal with mirroring subscriber information somehow (I can't remember if that information is exported), then I guess so; although you'd be better off just forwarding mail from the advertised address on your domain (in the sense of a forwarding address, not in the sense of Fwd: actions in mail user agents) rather than playing fragile games with MX records.
[09:29] <adrien_znc> right, thanks :)
[09:30] <adrien_znc> the sourceforge downtimes and lack of control and communication I've seen have been bothering me more and more
[09:30] <adrien_znc> (although someone living in the US told me the support was reactive and I guess it might just be that we're on different schedule)
=== dpm is now known as dpm-afk
=== cgregan1 is now known as cgregan
=== persia__ is now known as persia
=== dpm-afk is now known as dpm