| slangasek | cyphermox: what was the resolution of the mtu issues in NM? I'm trying to debug flaky wifi on zesty, and while NM hasn't been upgraded recently I notice that the interface is back to an MTU of 1500 | 00:55 |
|---|---|---|
| slangasek | cyphermox: and that furthermore, the NM UI doesn't let me save any edits to the MTU... | 00:56 |
| slangasek | (this may be only part of my issue; I also see 78% packet loss to VPN endpoint) | 00:58 |
| === maclin1 is now known as maclin | ||
| slangasek | cyphermox: looks like I'm seeing packet loss from my laptop on the local link, which is not affecting other devices on my network... so maybe not something that points to NM | 01:16 |
| mwhudson | i wonder if i can rig/wrap dput to do some checking of version number against upload target | 01:27 |
| mwhudson | e.g. if it's ppa target, version number must contain "~ppa" | 01:27 |
| slangasek | cyphermox: right, so... I was just having problems because systemd-resolved and dnsmasq were arguing again and this time pulled the vpn dns server into the fight | 01:29 |
| slangasek | nothing to see here, just packet flooding myself | 01:29 |
| nacc | mwhudson: yeah, it should be doable | 01:35 |
| mwhudson | not uploading $ver-0ubuntu1~16.10 to xenial would be nice too :) | 01:36 |
| nacc | mwhudson: heh, yeah, there are some heuristics we can apply | 01:36 |
| sarnold | oh yeah that'd be nice | 01:36 |
| nacc | mwhudson: i think; we've talked about doing some of those in our git push equivalent of dput | 01:36 |
| sarnold | here's the entry point to a bunch of the security team's heuristics http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/view/head:/build-tools/umt#L539 | 01:37 |
| nacc | mwhudson: (to be implemented, to be clear) | 01:37 |
| mwhudson | in fact, checking for SRU-type versions for non-dev-series uploads would be nice in general | 01:37 |
| nacc | mwhudson: yeah, we already track which series (or at least have a wrapper to LP API) for active and stable series, etc. | 01:37 |
| mwhudson | i've made that mistake every distro opening i've been core dev for so far :) | 01:37 |
| nacc | mwhudson: if you want to file feature-like bugs aginst the importer project, to document ideas, that'd be awesome | 01:37 |
| nacc | as we are working on a proper roadmap, etc. now :) | 01:38 |
| mwhudson | there was a thread about this sort of thing on debian-devel recently i think | 01:38 |
| nacc | and usability issues like that generally are exactly what i'd like to help avoid :) | 01:38 |
| mwhudson | although of course our heuristics would be entirely different | 01:38 |
| mwhudson | nacc: launchpad project name? | 01:38 |
| nacc | mwhudson: if you ahve a pointer, please send it my way, or i can go look tmrw | 01:38 |
| nacc | mwhudson: https://bugs.launchpad.net/usd-importer | 01:39 |
| nacc | mwhudson: not by any means a requirement to file there, but i feel like the server team, at least, is collecting a lot of 'tooling' like requests in there -- and we can lways reassign to other tools as needed, or open tasks | 01:39 |
| mwhudson | nacc: ack | 01:39 |
| nacc | mwhudson: thanks! | 01:41 |
| mwhudson | nacc: https://bugs.launchpad.net/usd-importer/+bug/1690967 | 01:48 |
| ubottu | Launchpad bug 1690967 in usd-importer "check package version number against upload target" [Undecided,New] | 01:48 |
| derp_commander | !info | 03:41 |
| mwhudson | naughty cking, he didn't update-maintainer when he uploaded ltt-control/2.9.3-1ubuntu1 | 03:51 |
| Unit193 | gtk+3.0 (3.22.15-0ubuntu1) artful; urgency=medium | 05:22 |
| Unit193 | * New upstream release 3.12.15 (also includes 14, 13). | 05:22 |
| === klebers__ is now known as klebers | ||
| viral_mutant | I am creating a DEB package with are bunch of .service files . I am bit confused when to use the ‘dh —with systemd’ ? | 07:33 |
| viral_mutant | the dh_installinit automatically puts the service files in appropriate directory | 07:33 |
| viral_mutant | what would —with=systemd do ? | 07:34 |
| mwhudson | viral_mutant: --with=systemd is what ensures dh_installinit gets run at all, i think? | 07:44 |
| mwhudson | uh no | 07:44 |
| mwhudson | sorry, --with=systemd inserts calls to dh_systemd_enable / dh_systemd_start | 07:45 |
| === fabo_ is now known as fabo | ||
| viral_mutant | mwhudson: what would happen if I don’t include —with systemd | 08:37 |
| mwhudson | viral_mutant: i don't know :) | 08:37 |
| viral_mutant | :) | 08:37 |
| sil2100 | jbicha: hey, I'm looking at gnome-desktop3 in the zesty queue right now - I probably need some additional context on how relevant this version-bump is | 09:16 |
| sil2100 | jbicha: since to me right now it doesn't really look like a SRU-valuable change | 09:16 |
| tjaalton | doko: hi, newer mesa seems to ftbfs on ppc64el on xenial, gcc segfaults (yakkety, zesty are fine). https://launchpadlibrarian.net/318462556/buildlog_ubuntu-xenial-ppc64el.mesa_17.0.5-0ubuntu1~16.04.1~2_BUILDING.txt.gz | 09:56 |
| tjaalton | doko: do you have ideas? | 09:56 |
| tjaalton | hmm | 10:04 |
| tjaalton | doko: looks like this was fixed before but since dropped from the package, I'll try forcing -O2 again | 10:05 |
| === klebers_ is now known as klebers | ||
| jamespage | if there is a MIR team member around - bug 1688091 is the MIR review for vine, which is blocking quite a bit of proposed from migration atm (via amqp/kombu dependencies) | 11:49 |
| ubottu | bug 1688091 in vine (Ubuntu) "[MIR] vine" [High,New] https://launchpad.net/bugs/1688091 | 11:49 |
| tjaalton | doko: yep, that fixed it, heh | 12:02 |
| jbicha | sil2100: the gnome-desktop3 SRU is low priority but I think it is useful LP: #1689371 | 12:16 |
| ubottu | Launchpad bug 1689371 in gnome-desktop3 (Ubuntu Zesty) "Update gnome-desktop3 to 3.24.2" [Low,In progress] https://launchpad.net/bugs/1689371 | 12:16 |
| slashd | rbasak, morning I see you talked with dragan about this LP: #1645324. From now on, I'm taking care of this bug, I see that some ppls suggest Dragan to submit in the upstream project first, but in this case it seems that ebtables is nearly "dead" last commits were made in 2015. Nowadays, all the development happen in nft. Do you think Dragan's patch could be eligilble for SRu anyway ? considering that Dragan already submitted | 12:17 |
| slashd | the same patch to Debian ebtables but not upstream. | 12:17 |
| ubottu | Launchpad bug 1645324 in ebtables (Ubuntu Artful) "ebtables: Lock file handling has races" [Medium,In progress] https://launchpad.net/bugs/1645324 | 12:17 |
| sil2100 | jbicha: yeah, but what do those change from the user POV? I mean, it's just a version number change, so without context I fail to see the point to get this released as an SRU | 12:28 |
| sil2100 | Not saying there is no point, just that I possibly lack the context or knowledge | 12:28 |
| jbicha | sil2100: in Artful, the GNOME version number shows up in gnome-control-center (it was patched out in previous Ubuntu versions): https://bicha.net/i/ubuntu-details-1710alpha.png | 12:30 |
| jbicha | since we are SRUing most of the rest of GNOME 3.24.2, the correct version number to report is 3.24.2, but like my bug says it's difficult to find anywhere in 17.04 where this is shown to users | 12:32 |
| jbicha | we did the update once a month ago LP: #1682236 | 12:36 |
| ubottu | Launchpad bug 1682236 in gnome-desktop3 (Ubuntu Zesty) "Update gnome-desktop3 to 3.24.1" [Low,Fix released] https://launchpad.net/bugs/1682236 | 12:36 |
| sil2100 | jbicha: ok, thanks for the context o/ | 12:38 |
| sil2100 | jbicha: while I'm on the gnome-* packages, do you know if there's by any change some test-case for checking if https://bugs.launchpad.net/ubuntu/+source/gnome-maps/+bug/1688702 is fixed? | 12:47 |
| ubottu | Launchpad bug 1688702 in gnome-maps (Ubuntu Zesty) "/usr/bin/gjs-console:11:g_slice_free_chain_with_offset:g_list_free:maps_contact_store_dispose:g_object_unref:release_native_object" [Medium,In progress] | 12:47 |
| sil2100 | jbicha: like, does anyone know when the crash is happening to test if it's fixed or not? | 12:47 |
| cyphermox | slangasek: re: packet flooding yourself> sure, but how come dnsmasq and resolved are arguing? | 13:09 |
| jbicha | sil2100: I don't know how to trigger the gnome-maps crash | 13:13 |
| sil2100 | Might be tricky to validate that one I guess | 13:13 |
| jbicha | the way I validate it is by checking to see if that error is reported with the new version | 13:14 |
| jbicha | but sometimes the error isn't reported yet because not enough people are running the new version | 13:15 |
| sil2100 | Is there a lot of -proposed testers for gnome? | 13:15 |
| jbicha | no, are there a lot of -proposed testers any where? :( | 13:15 |
| * musician_pro si chiede se gmail non stia funzionando solo a lui | 13:23 | |
| rbasak | slashd: can we get the patch committed/uploaded into Debian? That would also alleviate Ubuntu's maintenance burden. | 13:33 |
| sil2100 | jbicha: then it might be a bit troublesome to get it verified once it's in -proposed, right? | 13:42 |
| slashd | rbasak, sure will look at Dragan's debian bug status and continue from there. | 13:44 |
| * rbasak wonders if it's time to unseed ebtables in favour of nftables | 13:45 | |
| rbasak | Relevant rdepends are lxd, neutron, nova, and a reverse recommends of libvirt. | 13:46 |
| rbasak | jamespage, cpaelzer: ^ maybe something to consider for the future? | 13:47 |
| cpaelzer | why does libvirt has to be mentiond in all kind of "old dependency" discussion :-) | 13:47 |
| rbasak | ebtables appears pretty much unmaintained now. | 13:47 |
| rbasak | :-) | 13:47 |
| cpaelzer | rbasak: checked this, but that is not an ubuntu thing - not even Debian | 13:52 |
| cpaelzer | rbasak: the dependency is from upstream and it is more than a bit | 13:52 |
| cpaelzer | rbasak: so while I agree that would be a major upstream dev effort followed by a transition after merging that | 13:52 |
| jbicha | sil2100: it's the same way I verified similar crash reports; but what's the harm if the fix is incomplete? we'll just have to reopen the issue and try again but it doesn't need to reject the update | 13:52 |
| rbasak | cpaelzer: understood, thanks. | 13:52 |
| sil2100 | jbicha: it's just part of the formalities - every update is potentially risky, so it's generally best if we can somehow know if the given upload fixes the bug in mention, not to introduce additional risk for no reason - that's the theory of course | 13:56 |
| sil2100 | That being said I'll review it and if it's all good I'll let it in | 13:57 |
| slashd | rbasak, in another subject, did you have the chance to look the isc-dhcp split binary ? (LP: #1176046) ? | 14:20 |
| ubottu | Launchpad bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Wishlist,In progress] https://launchpad.net/bugs/1176046 | 14:20 |
| rbasak | Not yet, sorry. | 14:20 |
| slashd | rbasak, no problem | 14:20 |
| Laney | sil2100: There used to be a time when the upstream fixes GNOME updates claimed to have were believed. | 14:21 |
| Laney | I think that accidentally went away. Can we get closer back to that situation? | 14:21 |
| seb128 | Laney, what do you mean "were believed"? (sorry missed the start of the discussion) | 14:22 |
| Laney | There was a GNOME Micro Release Exception. | 14:23 |
| Laney | And it said that you don't have to explicitly verify each bug that upstream says is fixed. | 14:23 |
| sil2100 | Laney: I'll approve it as is, but currently I don't see any MRE (or don't know where to look for one) for gnome - maybe that's worth rediscussing then? | 14:25 |
| sil2100 | (checked the upload and it's fineish) | 14:25 |
| Laney | sil2100: The SRU team moved to a more general MRE policy some time ago, and that obsoleted the GNOME one we had before. | 14:25 |
| Laney | But I don't think most GNOME uploads meet the strict criteria that the new rules lay down... | 14:26 |
| Laney | Formal upstream QA documents, autopkgtests, ... | 14:26 |
| sil2100 | Although I would really like that if some upload mentions to be fixing a crash and that being part of the SRU, I would prefer seeing at least a way of verifying if it's really the case | 14:26 |
| sil2100 | At least for the future | 14:27 |
| sil2100 | But I r a noob | 14:27 |
| Laney | So yes, it would be great if we could get back to a frictionless way of uploading new GNOME point releases as SRUs. | 14:27 |
| Laney | https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions?action=recall&rev=59 | 14:29 |
| Laney | You can see the old verification process there | 14:29 |
| seb128 | sil2100, Laney, back then it had been discussed on https://lists.ubuntu.com/archives/technical-board/2012-June/001327.html | 14:44 |
| Laney | Good link, thx | 14:45 |
| seb128 | yw | 14:46 |
| jbicha | sil2100: I am actually able to reproduce the maps crash now so I'll update the SRU bug | 14:50 |
| sil2100 | jbicha: \o/ | 14:50 |
| jbicha | but there's still the point that often there are crash fixes where I can't duplicate the original crash, partly because errors.ubuntu.com gives very little context | 14:50 |
| jbicha | if it's going to be a problem me being unable to verify a likely crash fix, then there's incentive for the SRU uploader to just not mention the LP crash bug # in the SRU… | 14:51 |
| seb128 | e.u.c can tell you if reports stop with the new version | 14:51 |
| seb128 | your verification step can be "check that e.u.c reports don't exist on the new version" | 14:51 |
| jbicha | right, that's what I said in LP: #1688702 | 14:51 |
| ubottu | Launchpad bug 1688702 in gnome-maps (Ubuntu Zesty) "/usr/bin/gjs-console:11:g_slice_free_chain_with_offset:g_list_free:maps_contact_store_dispose:g_object_unref:release_native_object" [Medium,Fix committed] https://launchpad.net/bugs/1688702 | 14:51 |
| seb128 | and if it's not possible to verify you can always state "check that there is no regression" | 14:52 |
| seb128 | even if it doesn't actually fix it, as long as it doesn't create a new issue it should be ok | 14:52 |
| === shadeslayer_ is now known as shadeslayer | ||
| sil2100 | seb128: right, but errors will stop if users stop experiencing those - and there's not too many -proposed users around | 15:00 |
| sil2100 | seb128: so errors will still keep appearing until this goes to -updates for normal users to get them, right? | 15:01 |
| sil2100 | Anyway, it's approved already, but I *personally* don't like the idea of letting in things to from -proposed to -updates without actually verifying if the fix fixed anything | 15:02 |
| santa_ | mdeslaur: hi | 15:03 |
| sil2100 | As that's what I would expect for most SRUs | 15:03 |
| mdeslaur | santa_: hi | 15:03 |
| santa_ | sorry if you are busy with something else, I just wanted to ping you about this security issue https://bugs.launchpad.net/ubuntu/+source/kauth/+bug/1689759 | 15:04 |
| ubottu | Launchpad bug 1689759 in kauth (Ubuntu Yakkety) "CVE 2017-8422 - kauth: Local privilege escalation" [High,In progress] | 15:04 |
| santa_ | because apparently it's not fixed yet in the LTS | 15:04 |
| mdeslaur | santa_: it's community-supported...I see there are debdiffs in the bug. sbeattie is on community-sponsoring duty this week. | 15:06 |
| santa_ | ok | 15:06 |
| seb128 | sil2100, well, errors are matching a version of the package, so the fact you keep getting report isn't an issue, what you are looking for is sign of if there are report coming from the proposed version ... which true, is getting less testing, but new version sometime gets tested in new series | 15:07 |
| sil2100 | seb128: yes, but generally speaking if you don't see any mention of the version from -proposed in errors doesn't explicitly mean it's clean, it might mean: 'no one tested it' as well - or are there some metrics that could say otherwise? | 15:08 |
| sil2100 | I don't like the idea of uncertainty | 15:09 |
| jbicha | sil2100: seb128 is offline | 15:13 |
| sil2100 | jbicha: anyway, all gnome- packages for zesty reviewed and approved o/ | 15:14 |
| Laney | sil2100: Sounds like you're arguing against restoring the MRE | 15:14 |
| Laney | ? | 15:14 |
| sil2100 | Laney: *sigh* I'm not arguing | 15:14 |
| Laney | Umm, I didn't mean arguing in that sense | 15:15 |
| sil2100 | I'm by no means an authoritative person, just saying that having a *reliable* test case is something I require from most SRUs that explicitly mention fixing a given bug, as per the currently standing procedures | 15:16 |
| jbicha | thanks | 15:16 |
| slangasek | cyphermox: I have not yet taken the time to debug the dnsmasq/resolved argument. The dnsmasq is for libvirt, so not NM-related per se | 15:32 |
| cyphermox | oh | 15:39 |
| cyphermox | well, I'll keep an eye out for that kind of issue | 15:39 |
| slangasek | cyphermox: there's probably three elements here: the system resolved, dnsmasq for libvirt, and split DNS for VPN | 15:45 |
| cyphermox | yep | 15:45 |
| slangasek | that seems to be enough to trigger a loop | 15:45 |
| cyphermox | well I should be able to easily trigger this here | 15:46 |
| === JanC_ is now known as JanC | ||
| === boiko__ is now known as boiko | ||
| nacc | rbasak: are you available to discuss git stuff? | 17:34 |
| slangasek | cyphermox: it's possible a fourth element is that I've manually disabled nss_resolve on my host (/etc/nsswitch.conf) in order to force consistent behavior between host and chroots for debugging | 17:59 |
| cyphermox | slangasek: nevertheless we really should have all of that working correctly | 18:10 |
| slangasek | cyphermox: of course - I'm just saying that if you have trouble reproducing it, that might be a factor | 18:10 |
| cyphermox | ok | 18:10 |
| cyphermox | I haven't got to it yet, still busy with netplan and grub. | 18:10 |
| slangasek | or it might be that I'm doing a lot of !A, !CNAME dns lookups | 18:10 |
| slangasek | yeah, I certainly don't think this is a priority for you to dig into | 18:11 |
| cyphermox | AAAA? | 18:11 |
| slangasek | !A* ;) | 18:11 |
| cyphermox | TXT then? | 18:11 |
| cyphermox | (weee) | 18:11 |
| slangasek | MX, TXT, SRV | 18:11 |
| slangasek | (kerberos, local postfix) | 18:11 |
| cyphermox | all the things that work really really well | 18:11 |
| rbasak | nacc: not tonight, sorry | 18:13 |
| nacc | rbasak: ok | 18:13 |
| smoser | anyone successfully use a bluetooth headset with gnome3 shell ? after switching to it (and to gdm3), my bluetooth headset doesn't show up in the sound settings. | 18:27 |
| nacc | smoser: i have used it a few times | 18:30 |
| nacc | smoser: in my case, my bt headset autocnnects, but doesn't work, so i have to go to bt settings, disconnect, then reconnect it and then it works | 18:31 |
| jbicha | smoser: what Ubuntu version are you using? | 18:31 |
| smoser | 17.10 | 18:35 |
| pdeee | rbasak, RAOF I just thought I'd ping about the Certbot SRU | 19:20 |
| rbasak | pdeee: o/ | 19:23 |
| rbasak | pdeee: I need to find some time to sit down and catch up on that :-/ | 19:23 |
| pdeee | rbasak, we'd be happy to schedule a call or work session to get it done | 19:24 |
| pdeee | we've been looking at our analytics and being a little horrified by how many of our users are running the ancient and unecessarily buggy Xenial packages | 19:24 |
| rbasak | pdeee: that's a good idea. What time zone are you in? | 19:24 |
| pdeee | we're on US Pacific time | 19:25 |
| pdeee | San Francisco | 19:25 |
| pdeee | you? | 19:25 |
| rbasak | UTC+1 | 19:25 |
| * pdeee nods | 19:25 | |
| pdeee | we could do a 9am (us) / 6pm (you) call most days | 19:26 |
| rbasak | Let me check my calendar | 19:26 |
| slangasek | pdeee: by chance, has anyone talked to you about possibly migrating this to a snap package? That would seem to be a better overall fit than periodically SRUing | 19:26 |
| rbasak | slangasek: I'm not sure snaps are ready for certbot yet, due to the deep integration needed with existing deb-based packages (apache2, nginx, etc). | 19:28 |
| pdeee | slangasek, apparently someone emailed some of our team members about them, but we haven't evaluated them closely | 19:28 |
| Unit193 | And there'd still be a lot of users on the real package, not the snap. | 19:28 |
| slangasek | fwiw I had taken a brief look at those packages in the SRU queue and gave them a pass, because they're far from being a straightforward fit for the SRU process | 19:29 |
| rbasak | Yeah - we'd need to carry on SRUing until a snap has feature parity and the distro release doesn't carry the deb I think. | 19:29 |
| pdeee | Certbot has been a pain to package. The high level summary of why is: | 19:30 |
| slangasek | rbasak: well, at some point I think we would make the deb in SRU transition to the snap; and yes, there are definitely integration touchpoints to figure out | 19:30 |
| slangasek | Unit193: a snap is also a real package ;) | 19:30 |
| Unit193 | slangasek: Meh, whatever floats your boat... | 19:30 |
| pdeee | 1. pyopenssl and python-cryptography are cffi-based wrappers to openssl. They're the best option for python crypto code today, but they're horribly fragile | 19:30 |
| pdeee | native .deb / .rpm packages are the least-bad answer for getting an unbroken python-cryptography | 19:31 |
| infinity | If only there was a way to talk to openssl without python. | 19:31 |
| pdeee | we somewhat regret not having taken the bullet and just shelled out to openssl for everything Certbot needs from it | 19:32 |
| rbasak | pdeee: how about tomorrow (17 May) at 1700 UTC for an hour? With the goal being to catch up and plan what needs doing next to get this landed. | 19:32 |
| pdeee | there would have been a lot of awful if openssl version < x do A else do B | 19:33 |
| pdeee | rbasak, that works for bmw and I | 19:33 |
| rbasak | pdeee: what do you prefer? Eg. Google Hangout? IRC? Something in the middle? | 19:33 |
| pdeee | I'll also invite our Debian maintainer, though I can't promise his availability | 19:33 |
| rbasak | Sure | 19:33 |
| pdeee | rbasak, Hangouts are good | 19:33 |
| infinity | pdeee: Yeah. I was actually referring to using libssl directly with C, not openssl(1), but also, don't mind my drive-by sarcasm. An interpreted language is probably the right solution for this sort of project, as much as the bindings suck. | 19:33 |
| rbasak | OK, I'll send invites. Can you send me the relevant email addresses? Privately if you wish. | 19:34 |
| pdeee | rbasak, probably faster for me to do it since they're all in my addressbook :) | 19:34 |
| rbasak | Sure :) | 19:34 |
| rbasak | pdeee: that showed up at 1600 UTC for me. Are you sure that's right? It's fine there BTW, just want to make sure we don't miss each other. | 19:38 |
| rbasak | Uh, 1500 UTC. 1600 local. | 19:38 |
| rbasak | Isn't that about 6am for you? | 19:38 |
| infinity | If he's in hawaii. | 19:39 |
| nacc | heh | 19:39 |
| infinity | rbasak: "TZ=America/Eastern date -d '1500 UTC'" (adjust to taste) is your friend if you hate timezones. | 19:40 |
| infinity | Err, well, if that was a timezone. | 19:41 |
| rbasak | I choose to just be friends with UTC instead. Everyone should be UTC's friend :-P | 19:41 |
| infinity | America/New_York even. | 19:41 |
| infinity | Oh, US/ is where Eastern lives. | 19:42 |
| infinity | Silly zoneinfo. | 19:42 |
| pdeee | rbasak, that's odd. 8am here is usually 17:00 in Central Europe... | 19:43 |
| pdeee | unless there's a daylight saving difference, which there shouldn't be? Anyway, happily moving it an hour later :) | 19:44 |
| infinity | pdeee: You're Pacific? | 19:44 |
| pdeee | yes | 19:44 |
| infinity | If so, yes. 8am for you is 1600 for rbasak and 1700 for central Europe, you're not wrong. :P | 19:44 |
| pdeee | oh he said UTC + 1 but he meant daylight savings rather than Central Europe :) | 19:45 |
| infinity | http://paste.ubuntu.com/24588672/ | 19:45 |
| infinity | Right. He meant BST. | 19:45 |
| rbasak | Forget daylight savings. "date -R" -> UTC offset. Know your UTC offset. That's all that's needed :) | 19:46 |
| rbasak | No need for any other timezone knowledge, except that UTC offsets may change due to daylight savings (so is time-of-year sensitive). | 19:46 |
| pdeee | RAOF, presuming if you're in Hobart that you won't want to join us :) | 19:46 |
| infinity | rbasak: UTC offsets confuse all of us who grew up with sysv timezones, because "PST8PDT" is only 8 for a portion of the year, and then our poor North American heads explode. | 19:47 |
| pdeee | RAOF, but I'll send you a calendar invite just in case you're a night owl, and we can take notes in any case | 19:47 |
| infinity | (I'm MST7MDT, and it's never made sense to me... And this is the part of the year where I'm -0600 and confused) | 19:47 |
| nacc | rbasak: do you want me to also join? or are you ok on your own? :) | 19:48 |
| rbasak | infinity: well, that's just "limited knowledge is limited". Anything North America -specific fails internationally. | 19:48 |
| infinity | Well, also, thanks to the US levering daylight savings wider and wider, MST7MDT is 6 a lot more than it's 7. | 19:48 |
| infinity | rbasak: Well, yes, which is why sysv timezones are deprecated, but old habits (and the thought processes that accompany them) die hard. ;) | 19:49 |
| rbasak | nacc: join if you wish. I may want you to review uploads with me later but I don't think we'll cover anything controversial or anything. | 19:49 |
| cjwatson | I'm pretty sure MST7MDT is a cult TV show. | 19:49 |
| nacc | rbasak: ack ok | 19:49 |
| infinity | rbasak: It's just one of those things where I gave up and use date to tell me the truth now because my brain is permanently broken WRT timezones. | 19:49 |
| slangasek | cjwatson: +1 | 19:50 |
| infinity | cjwatson: That's MST3KDT | 19:50 |
| cjwatson | Silly me. | 19:50 |
| infinity | Which would be the episode where they do nothing but voiceovers of Donald Trump speeches. | 19:50 |
| infinity | Which, it turns out, need no alteration to be ridiculous, so it was their vacation episode. | 19:51 |
| nacc | zing | 19:51 |
| pdeee | infinity, on the openssl front, I think my tentative conclusion is that the openssl project should take over maintainership of python-cryptography and pyOpenSSL, so that they can protect those libraries with tests and release them in sync with openssl itself | 19:51 |
| slangasek | barring that, if the tests exist we can+should make sure they're being run as autopkgtests in Ubuntu | 19:52 |
| cjwatson | (autopkgtests ensure that dependencies don't get out of -proposed if they break things depending on them) | 19:53 |
| pdeee | slangasek, they do; when openssl breaks those python bindings it's usually not subtle, so running python-cryptography's tests should be sufficient | 19:54 |
| pdeee | on one memorable occasion, openssl broken them with a security patch | 19:54 |
| infinity | That sounds like openssl alright. | 19:55 |
| santa_ | acheronuk: so ... I think we have the security issues either fixed or with a pending patch. tomorrow I guess I will resume my work on applications. thank you for the fixes you have done today, good job | 20:32 |
| sbeattie | santa_: kauth for xenial/yakkety were published. | 20:34 |
| acheronuk | santa_: that's good. yeah, I just stuck with kicking/prodding the CI today. | 20:36 |
| santa_ | sbeattie: thank you very much! we had a harsh week @ kubuntu :) | 20:37 |
| === mardy_ is now known as mardy | ||
| nacc | rbasak: can you explain again why we wnat the --no-tags option by default? e.g., in that case, a pack exists so git resolves the tag, but there is no .git/refs/tags that correspond (so our copy algorithm doesn't quite work) | 21:24 |
| rbasak | nacc: because git doesn't namespace tags between remotes. So you'd end up pulling or pushing tags to the wrong namespaces. | 21:33 |
| nacc | rbasak: ok, but for the importer's run, i think we do want to fetch tags | 21:34 |
| nacc | rbasak: as it's 'special' | 21:34 |
| rbasak | nacc: sure, but according to a specific refspec surely, rather than refs/tags/*:refs/tags/* which it would do otherwise. | 21:35 |
| nacc | rbasak: oh i see what you're saying | 21:36 |
| nacc | rbasak: ok, yeah, that's true | 21:36 |
| nacc | rbasak: well, my point about the pushing side is that you'd need permissions to do that | 21:36 |
| nacc | rbasak: and it won't push a tag to a new commit without -f | 21:37 |
| nacc | rbasak: so i feel like we're trying to avoid something that doesn't really need to be avoided :) | 21:37 |
| rbasak | Yes, but we're trying to not rely on that, to also protect ~usd-import-team members. | 21:37 |
| nacc | fair enough | 21:37 |
| rbasak | Without --no-tags, I believe it tries to push tags corresponding to any other ref you push. | 21:37 |
| nacc | this isn't for git-push though | 21:37 |
| nacc | this is a fetch opt | 21:38 |
| nacc | oh it's a *remote* opt | 21:38 |
| nacc | i see | 21:38 |
| nacc | rbasak: well, the idea of a refspec then changes the specification again :) | 21:39 |
| nacc | a refspec for tags, i mean | 21:39 |
| nacc | rbasak: or do we leave the refspec for tags in debian/ubuntu remotes, but just simply not fetch them? | 21:42 |
| doko | tjaalton: did we see this ICE on ppc64el earlier? | 22:01 |
| nacc | rbasak: the updated MP successfully imports php7.0 and php7.1 with proper fast-forwarding etc. | 23:51 |
| nacc | rbasak: if you can find time tmrw, i'd like to go through it together | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
