[00:00] <Etua> Hello, Is anybody here?
[00:09] <wgrant> Etua: Push to lp:~USER_OR_TEAM/gnome-paint/stable. lp:gnome-paint/stable is an alias for gnome-paint's stable series, which you haven't set up.
[00:09] <wgrant> I'd suggest just pushing the branch now, and you can set up the series later if you really need it.
[00:11] <Etua> wgrant, I want it to be official branch, under main address, not the one of user nor the team. How can I do that?
[00:12] <wgrant> Etua: You'd need to create a series at https://launchpad.net/gnome-paint/+addseries. But it's more common to have eg. 1.0, 2.0 and trunk series, not trunk and stable.
[00:13] <wgrant> Etua: I'd really suggest you start without an extra series for now, and wait until you actually need it.
[00:14] <wgrant> The only immediate downside is that you need to include the team name in the branch URL.
[00:16] <Etua> wgrant, Thank you for your help. I may stick to having only one branch, but I'd like to ask for the future. Is having team name in branch URL inevitable even with registered series?
[00:19] <wgrant> Etua: A branch always has a full lp:~OWNER/PROJECT/BRANCH name. Each project series (by default only "trunk" exists) can have a default branch nominated, giving that branch the alias lp:PROJECT/SERIES. And the default branch of the default series gets the lp:PROJECT alias.
[00:19] <wgrant> Most projects don't use multiple series, so they don't even care that series exist.
[00:20] <wgrant> But for projects that main eg. 1.x and 2.x branches, they'll often use series.
[00:20] <wgrant> But once they start maturing -- if you never do updates to stable releases, series don't really buy you anything.
[00:21] <Etua> wgrant, That's all I wanted to know, thanks.
[07:36] <Ionic> hmm, are you limitting the lastest builds display?
[07:37] <Ionic> looks like it's limited to the lastest 5 builds, which is uncomfortable if more than 5 builds have been requested
[07:37] <Ionic> currently we have 6 supported build environments (from precise to bionic)
[09:19] <cjwatson> Ionic: Which latest builds display?  We have several of those in different contexts.
[09:25] <Ionic> cjwatson: in a recipe's view
[09:26] <Ionic> hopefully that's more precise
[09:31] <cjwatson> Ionic: We do need to limit it (well, ideally it'd be paginated and you could page back, but that's some more effort), but file a bug and we can easily bump the size to 10
[09:42] <Ionic> cjwatson: I understand that it needs to be limit, though I'd change the limit to $num_supported_distro_versions :)
[09:43] <Ionic> s/needs to be limit/needs to be limited/
[09:44] <Ionic> will do, of course
[09:45] <cjwatson> That wouldn't work very well since it's possible (and sometimes reasonable) to request builds for a subset of the series that a recipe currently supports.
[09:46] <cjwatson> And you probably wouldn't want to just see the most recent one for each series.
[09:46] <cjwatson> I think ten or so should be OK; it's enough to provide a reasonable amount of context without making the page excessively large if the archive the recipe is building into has lots of architectures enabled.
[09:47] <Ionic> why wouldn't that work? in this case, the limit would be higher than the number of requested builds, so at least all requested builds + an unspecific number of old builds would show up?
[09:48] <cjwatson> Well, I mean it would *work*, but you'd no longer see the most recent build for some series.
[09:48] <cjwatson> Even after just a single manually requested build.
[09:49] <Ionic> yes, but that's also currently the case
[09:49] <cjwatson> Right, but it would not be the case with ten, typically.
[09:49] <cjwatson> I don't think we need to parameterise it, basically.  We have a limit of 10 in some other similar views elsewhere already.
[09:50] <Ionic> yeah, in that case a fixed limit will be easier to implement and show more, assuming that the limit is higher than the number of supported series
[09:50] <cjwatson> Also, the number of supported series is typically about 5, so equal to the default ...
[09:50] <cjwatson> (current default)
[09:50] <cjwatson> currently supported: trusty, xenial, zesty, artful, bionic
[09:51] <Ionic> hm, in that case I wonder why I can still request precise builds
[09:51] <Ionic> you're right, precise seems to be EOL
[09:53] <Ionic> normally launchpad removes EOL'd series from the requested series automatically and won't accept new builds - that's currently not the case for precise
[09:54] <cjwatson> precise is an arguable special case because of ESM.
[09:54] <cjwatson> But it's true it's technically still Supported from LP's point of view.
[09:55] <Ionic> ah, I see, that explains this
[09:59] <ePierre> Hi!
[10:00] <ePierre> I'm having an issue with the python3 version of launchpadlib
[10:01] <cjwatson> ePierre: go on ...
[10:02] <ePierre> cjwatson, I'm trying to upload a binary attachment using the addAttachment() method
[10:02] <ePierre> cjwatson, my file is working fine before the upload, but it's scrambled up once it arrives in launchpad
[10:03] <cjwatson> ePierre: Is the nature of the scrambling identifiable?
[10:05] <ePierre> cjwatson, so for instance, https://bugs.staging.launchpad.net/plainbox/+bug/1728124
[10:05] <ePierre> cjwatson, I'm not sure how to identify this.
[10:05] <ePierre> cjwatson, I tried to compare the binary files, but basically everything is different apart from the headers
[10:05] <cjwatson> ePierre: Which one of those files?
[10:06] <cjwatson> ePierre: And can you put the original somewhere for us?
[10:06] <ePierre> the tgz and the xz files
[10:06] <Ionic> sounds like recompression
[10:06] <ePierre> cjwatson, sure... actually maybe I can try to attach it in the same issue :)
[10:07] <cjwatson> python3-launchpadlib won't be doing recompression
[10:08] <ePierre> cjwatson, posted as attachment in the same issue. I checked and these can be downloaded and opened
[10:09] <ePierre> and if it's recompression, it's not very good because the resulting file is actually bigger than the original :D
[10:12] <ePierre> cjwatson, the rationale behind this is that I'm working on porting a utility that we use to post bug reports on launchpad. It's a python2 utility, I'm porting it to python3
[10:13] <ePierre> cjwatson, I faced some unicode conversion issues in the beginning, but now it's all good, and I checked that my data is OK (I f.write() it somewhere on my HDD just before calling addAttachment() just to make sure it was valid data, and it is)
[10:14] <cjwatson> OK, will look in a bit and see if I can make anything out of it
[10:15] <Ionic> mh, yes, something else seems to be going on
[10:17] <ePierre> cjwatson, thanks a lot. Let me know if you need me to open an issue somewhere or if you need other info
[11:02] <ePierre> cjwatson, I need to go but I'll leave IRC running just in case. Feel free to ping I'll get back to you later
[11:19] <mitya57> Can someone please look what happened to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3020/+build/13668093 ?
[11:19] <mitya57> It says “Finished at 20171102-1036” (> 30 minutes ago) but still in “Currently building” state.
[11:19] <cjwatson> mitya57: It'll still be transferring bits very slowly across the ocean.
[11:20] <cjwatson> Because we don't have the long-fat-pipe mitigation stuff in place for s390x yet.
[11:20] <mitya57> cjwatson, ok, thanks.
[11:20] <cjwatson> Can't do much about it, but if I remember correctly the upcoming bos02 region should have that fixed
[11:23] <mitya57> I am not complaining, just wanted to make sure it's fine :)
[13:17] <Etua> Hello, I think that most of the users does not get notified after my actions. E-mail are sent improperly. Could somebody look at my request on Launchpad anwsers?
[14:59] <Etua> Hello, can somebody review my request. I have a reason to belive that most of Lauchpad contributors was not able to read it.
[15:46] <Saviq> hi all, we're migrating lp:mir to GitHub, how do I go about adding GitHub as a recognized external tracker? https://github.com/MirServer/mir/issues
[15:50] <cjwatson> Saviq: I've added https://bugs.launchpad.net/bugs/bugtrackers/mir-bugs - you should be able to enter mir-bugs as the external bug tracker name on https://bugs.launchpad.net/mir/+configure-bugtracker (leave the project ID blank)
[15:51] <Saviq> cjwatson: ack, thanks!
[15:52] <Saviq> aha, will need to make sure all the project ones have an Ubuntu counterpart, too
[16:32] <nacc> cjwatson: is there a launchpad API to the list of all source packages in debian and ubuntu? not seeing anything obvious on the web api docs
[16:34] <cjwatson> nacc: archive.getPublishedSources(status='Published')?
[16:38] <nacc> cjwatson: if i only eed the names, is that hte best api to use? i'll end up iterating the whole response list and getting a bunch of data from LP that i end up discarding (I think?)
[16:40] <cjwatson> nacc: well, have you considered just looking at the Sources files in the archive rather than using the API?
[16:40] <cjwatson> it'd certainly be a lot faster
[16:41] <nacc> cjwatson: yeah I thinkn that's what I'll end up doing :)
[16:41] <nacc> cjwatson: i suppose this particular query is not about LP at all, thankns!
[16:46] <chrisccoulson> I'm not sure what's going on, but my rust builds keep failing randomly, and I can't reproduce the failures locally
[16:46] <chrisccoulson> both https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/rust-updates/+build/13666158 and https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/rust-updates/+build/13666137 have failed twice now, each time at different places
[16:46] <chrisccoulson> (and one of those is a SIGSEGV)
[16:47] <chrisccoulson> I'm not entirely sure what to do when I can build them ok at home, other than keep hitting retry :/
[16:54] <cjwatson> try matching kernel versions, same parallelisation levels?  try getting a build log at home and diffing?
[18:40] <wxl> hey folks. i'm trying to get a list of ubuntu members emails for the purposes of sending out the poll for the loco council election.
[18:40] <wxl> i've got:
[18:40] <wxl> for person in ubuntumembers.getMembersByStatus("Approved"):
[18:41] <wxl>    print(person.email_address)
[18:41] <wxl> i seem to have got a 503 back
[18:42] <wxl> OOPS-00da48a3777c81e6906850c3dc5fcc42
[18:48] <Etua> Hello, I'd like to enable automatic translations import, but I can't find setting page that is decribed in https://help.launchpad.net/Translations/ImportingFromBazaarBranches Could you help me with that?
[19:00] <Etua> I found it by accident, but I have another question. Why I need pot file, isn't POTFILES.in everything needed for an import?
[19:29] <cjwatson> extracting the pot file often requires project-specific stuff, so LP doesn't attempt to do it for you
[19:29] <cjwatson> custom xgettext settings for example
[19:33] <wxl> cjwatson: since you're awake did you see my oops above?
[21:46] <cjwatson> wxl: It looks moderately easily improvable by some bulk-loading, so please file a bug about it.
[21:46] <cjwatson> wxl: Quote the OOPS ID so that the analysis system keeps it around (it refrains from pruning OOPSes that are mentioned in bugs).
[21:47] <wxl> cjwatson: well i did get it to work SOME of the time, but i'll get a bug report written eventually. in the end, i gave up trying to make that myself as someone else had something better
[21:55] <wxl> cjwatson: is there any way i can get the non-public email addresses of ubuntu members?
[22:18] <cjwatson> wxl: No - if people have requested that they be non-public, then we can't give them out.
[22:18] <cjwatson> Kind of what it says on the tin.
[22:19] <wxl> cjwatson: i was hoping cc membership would provide some degree of extra ability
[22:19] <cjwatson> I'm afraid LP knows not of such things.
[22:19] <wxl> XD
[22:20] <wxl> possible to email all members of ubuntumembers?
[22:22] <cjwatson> Not via LP, as far as I know.  Not sure how we've done this in the past.
[22:22] <wxl> yeah unfortunately everyone's gone and disappeared :)
[22:31] <cjwatson> wxl: members> I have a fix in progress, so if you file the bug it'll give me something to hang QA off :-)
[22:31] <cjwatson> (as in, for the timeout)
[22:31] <wxl> ok ok i'll get there. got a bunch of other stuff on my plate but i'll save the OOPS
[22:31] <cjwatson> ta
[22:32] <wxl> np
[22:32] <cjwatson> wxl: In extremis we could possibly do something like sending the email on your behalf with administrative intervention to get the list, but please see if you can find some other option first
[22:32] <wxl> well the script i found looks at email or tried to get it from GPG keys so that's probably good enough
[22:33] <cjwatson> Ah right
[22:33] <cjwatson> That would make sense
[22:34] <wxl> FYI https://github.com/ahoneybun/lp-election-helper/blob/master/lp-election-helper
[22:34] <cjwatson> Fun little patch though.  Should be something like https://paste.ubuntu.com/25875736/, and I need to write a test specifically for the query count to go with that
[22:34] <Etua> Why Launchpad spoofs my e-mail address, my receipents won't get any messages if they will fail spf and dkim check.
[22:35] <Etua> ?
[22:35] <cjwatson> Etua: It was designed in a former era before such things existed.  There is a bug about it but we haven't had a lot of time ...
[22:38] <Etua> cjwatson, Thanks, I hope it'll be fixed soon.
[23:09] <wgrant> Etua: SPF and DKIM apply to the SMTP sender address, not the From address in the email.
[23:09] <wgrant> Unless you have an unusually restrictive DMARC policy, all checks will pass.
[23:19] <Etua> wgrant, As far as I know I have reject policy, but will implementing softfail help when both: dkim and spf fail?