[00:36] Is there some kind of historical data where you can see what package versions a PPA had in mid to late 2016? :D [00:36] I'm not looking for debs, just information [00:39] a wild Peng_ appears [00:40] Peng_: if you can get to "view package details", then "view all builds", you can find a list of previous things [00:40] Peng_: the ppa I'm most familiar with has builds from 2008 listed [00:44] Ahh! [00:46] The PPA I was looking at had two builds under "view all builds". I just found that they use a second PPA for building and then copy the packages. [00:46] That PPA has all the history, though it only goes back to 2016-11. Maybe they had a secret third PPA. [00:46] Thank you! [00:48] Peng_: aha :) interesting method, hehe [08:00] teward: https://dev.launchpad.net/Getting [08:01] Bug notification handling is done in lib/lp/bugs/mail/bugnotificationbuilder.py, though quite a lot of grepping around will be necessary [08:02] (Ideally bug notifications would be converted to the general framework in lib/lp/services/mail/basemailer.py) [08:58] Lord-Kamina: Well ... I can't say I'm very impressed with dput-ng. I could reproduce the problem you described, but only if my SSH private key has a passphrase set. [08:59] Lord-Kamina: I don't know why this would have changed at your end though. It seems to be entirely a client-side bug. [08:59] What benefits does dput-ng provide over dput? [08:59] Besides bugs [09:00] Lord-Kamina: If you want to check whether it's the same problem, then try applying https://paste.ubuntu.com/p/R67VTysypr/ to /usr/lib/python2.7/dist-packages/dput/uploaders/sftp.py [09:01] For me it said "PasswordRequiredException: Private key file is encrypted" [09:03] Yeah, I can't answer as to its benefits [09:05] But its SFTP implementation is clearly broken and shouldn't be used unless fixed quite a bit (at least passphrase support) [09:05] Maybe its FTP implementation works. I haven't tried [09:06] There are various bug reports on https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=dput-ng concerning the sftp uploader - not sure any of them are specifically this [10:13] hey there, launchpad translations question [10:14] https://translations.launchpad.net/ubuntu/focal/+source/libpeas is a bit in a buggy state [10:15] the upstream template is 'libpeas-1.0' but launchpad still has 'libpeas' , is there a way to delete one of those? [10:15] ideally I would like to delete libpeas-1.0 and rename libpeas to libpeas-1.0 since the old 'libpeas' is what is correctly translated [14:34] wgrant Honestly I don't know. I expect most likely the guide I read a few years ago used dput-ng because reasons and maybe at some point it was in fact better than regular dput. *shrugs* [14:51] cjwatson: then I assume basemailer.py also needs some dmarc love/attention? [14:52] (grepping isn't new to me thanks to some larger and much worse in-house python stuff I've been rewriting lol) [14:55] teward: The whole thing will, but each individual mail handler is likely to need individual thought and attention for how people interact with it and what the right way to substitute From is [14:55] teward: But we can generally do things one at a time [14:55] makes sense. [14:55] bug mailer shouldn't be too hard. [14:56] though Reply-To is sometimes not respected by endpoint mail clients in rare cases (read: MS Outlook/Exchange in rare cases) [14:56] I'm also interested in making sure that the conversations still look sensible in people's mail clients [14:57] Since it's still real people at the other end, not just impersonal notifications from the bug tracker [14:59] cjwatson: that's where it gets... tricky. The way we handled this in-house was to alter the "From" field's display name by sender and have the sane recipient address underneath the hood. I.E. for a listserv named "Test123" with test123@example.com the From field became "'Thomas Ward via Test123' " (obviously using the format function I'm just writing this out by hand because reasons) [14:59] the display name changes [14:59] but the underlying address doesn't [14:59] DMARC is a PITA though if you REALLY want to make listservs compliant [14:59] or other kind of relay-mailers, etc. [15:00] it LOOKS like get_bugmail_from_address is what'd need revised here for DMARC compat, but that's an all-or-nothing change :/ [15:01] ... but would eliminate the Bjorn oddball handling case [15:01] that'd get murky fast. [15:01] cjwatson: I think the overarching question is: how critical / important does DMARC compatibility for email notifications, etc. rank on the scale of "Things that Should Get Done" [15:03] *loads the LP repo up in Pycharm for reasons* [15:04] also, what version of Python are you guys using to drive LP? [15:05] (necessary so I create the right local venv) [15:06] teward: If you've used rocketfuel (from https://dev.launchpad.net/Running ), then just doing 'make' should do you. https://dev.launchpad.net/Running/LXD is also useful as rocketfuel will install system things [15:06] (otherwise, python 2.7) [15:06] tomwardill: not looking to run :P [15:07] specifically on xenial, although it may work on other versions [15:07] tomwardill: looking for devcompat [15:07] 'cause I Py3 everything xD [15:07] so if i need to compat for 2.7 i'll compat for 2.7 :P [15:07] fair enough [15:09] teward: I don't know [15:09] We should improve from where we are now :) [15:10] teward: And you definitely want to use https://dev.launchpad.net/Running/LXD rather than just a straight virtualenv [15:10] cjwatson: correct, but the venv is so I can isntall things so PyCharm can resolve depends [15:10] not *running* the thing [15:10] ;) [15:10] teward: Even if only running the tests [15:10] just want it to stop throwing RED everywhere while I type :) [15:10] i'll do a runtest later [15:10] in the Normal Way [15:10] :) [15:10] teward: I believe there are ways to get pycharm to look into a container [15:11] cjwatson: but i found where the call to get_bugmail_from_address (and the actual mail constructor happens) - lib/lp/bugs/scripts/bugnotification.py->construct_email_notifications which in turn calls get_bugmail_from_address from bugnotificationbuilder.py [15:11] Sure, sounds broadly plausible [15:12] so your builder isn't actually building the message xD [15:12] Bug notifications are unnecessarily complicated and I'm sure there are several quirks [15:12] yeah this is one of them, but i know where the from constructor needs adjusted now at least [15:13] Notice that get_bugmail_from_address does already produce somewhat more dmarc-friendly From headers in some cases [15:14] cjwatson: correct. but if we condense all the cases together, we have a few edge cases where there won't be DMARC-friendly [15:14] basically, anywhere where we pull a non-lp address into the From header breaks DMARC [15:14] What are the edge cases where that would still need to happen? [15:14] none [15:14] but there's special handling for janitor [15:15] The special handling for janitor just sends as Launchpad Bug Tracker <12345@bugs.launchpad.net>, so I don't quite understand [15:16] yeah for its from constructor it needs a special display name [15:16] I think we should at least consider starting with just applying the behaviour in the hide_email_addresses case across the board [15:16] that's what would happen [15:16] give me a sec and I'll share my diff [15:17] I expect quite a lot of test suite fallout too of course [15:18] indeed. but i haven't touched tests yet. https://paste.ubuntu.com/p/36gW2R6ZtX/ is the theoretical code reduction that'd happen [15:18] taking out MOST of the returns and the handling cases and dropping simply to handling displayname in an if/else and then just a single return [15:18] that SHOULD handle all the cases for bug notification emails but again, E:UNTESTED right now [15:18] Right, that was broadly what I was thinking, indeed [15:18] it drastically reduces the size of the constructor though [15:19] at least, for the From header [15:19] and i'll run some tests locally [15:19] but first [15:19] Coffee and Food [15:19] E:REQUIREDITEMS [15:19] Since it already works for people who hide email addresses, which is lots, it presumably can't go that badly wrong [15:20] *true*. I haven't even dug yet into the tests lol. Going to do the Tried and True method of "JFDI" in the test env without running tests yet. [15:20] i'll clean tests later xD [15:20] but again, food and coffee. [15:21] i'm surprised i'm even awake right now without those :P [15:22] teward: As for py3, we'd like to get there too and there's a fair bit of work in progress, but as you can see there's a lot of code [15:22] "bin/with-xvfb bin/test -vvct lp.bugs" should (a) take a while (b) be enough to find most of the test fallout [15:23] truth. I'd try a Py3 conversion but i don't have the cycles to do a full conversion, so I'm targeting the DMARC stuff here xD once you go to Py 3.7+ though you can take most of those "%s" formatted strings, etc. and use f-strings which are *a lot* nicer. [15:23] I haven't persuaded all my colleagues of the niceness of f-strings yet. (3.6 has them too) [15:23] (also kiiiiinda helps that I've had to rewrite three in-house listserv platforms using my dmarcmsg library on PyPI for those listservs xD) [15:24] https://git.launchpad.net/~cjwatson/launchpad/log/?h=py3 is my extremely messy semi-port [15:24] Been working on that on and off since late last year [15:24] indeed. [15:25] (Well, and longer if you count dependencies) [15:25] cjwatson: remind me because E:NotFullyVersed but how do I just push this to my own code section where I can actually commit? I remember the evil BZR way not sure if it's straightforward for LPGIT [15:25] (currently versed in Salsa, Gitlab, and standard Git/Gitea atm :P) [15:25] (i.e. my own branch) [15:25] OH GOOD THE COFFEE IS DONE [15:26] https://help.launchpad.net/Code/Git#Configuring_Git and then "git remote add teward lp:~teward/launchpad; git push -u teward yourbranchname" [15:26] (also, #launchpad-dev maybe) [15:26] yep moving there [15:28] teward: I am probably also obliged to point out https://dev.launchpad.net/ContributorAgreement before you go much further [15:29] (sorry, but you know how it is ...)