| rbasak | enyc: I don't see any reason why SRU or backports processes to Xenial and Trusty can't start now. | 00:14 |
|---|---|---|
| === maclin1 is now known as maclin | ||
| tsimonq2 | Can I please get some clarification on what it means for Foundations to triage bugs? | 01:16 |
| tsimonq2 | So when e.g. rls-bb-incoming is added, it goes in a queue, I believe. | 01:16 |
| tsimonq2 | At what point is it assumed that Foundations has an eye on it? | 01:16 |
| tsimonq2 | Like, I see e.g. bug 1742147 where the tag "id-5a578f7753948dd556e87182" was added and rls-bb-incoming was removed. | 01:17 |
| ubottu | bug 1742147 in ubuntu-release-upgrader (Ubuntu Bionic) "upgrade from 17.10 to 18.04 fails with triggers looping" [Critical,Confirmed] https://launchpad.net/bugs/1742147 | 01:17 |
| tsimonq2 | From there, I am a bit confused. It doesn't explicitly show on the bug report that any progress was made, yet that tag was removed, so it seems that *something* was done. | 01:18 |
| jdonald | Looks like we have the flags now to fix Firefox on Bionic (and Trusty) armhf: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1711337 | 01:39 |
| ubottu | Launchpad bug 1711337 in firefox (Ubuntu) "Firefox crashes at start on armv7L after 55.0.1 update" [Undecided,Confirmed] | 01:39 |
| jdonald | Is there someone here with access to change build flags used by Launchpad? | 01:40 |
| tsimonq2 | jdonald: It depends. | 01:49 |
| tsimonq2 | If the build flags can be done in the packaging, chrisccoulson is the person to talk to. | 01:49 |
| tsimonq2 | If you need Special Magic done on the builders themselves, talk to a Launchpad administrator such as cjwatson. | 01:49 |
| tsimonq2 | I Have Not Looked Yet but let me see. | 01:50 |
| tsimonq2 | This is probably a packaging change that needs to be done. | 01:51 |
| * Son_Goku waves at sabdfl | 02:02 | |
| doko | tsimonq2: are you working on the node-js migration to the release pocket? | 08:50 |
| tsimonq2 | doko: Yes. | 08:51 |
| cjwatson | tsimonq2: To a good first approximation Launchpad is never involved in setting build flags. :-) (There are a tiny number of exceptions, but the fewer the better) | 09:18 |
| tsimonq2 | cjwatson: That's why I thought it should be done in the packaging. | 09:19 |
| cjwatson | Indeed. | 09:22 |
| xnox | tsimonq2, "remove tag + assign to series" => means it's committed to be fixed that cycle. | 09:31 |
| xnox | tsimonq2, "id-<foo>" is foundations-internal project management of tasks, and is no significance (could be assigned, could be in the backlog...) | 09:31 |
| tsimonq2 | xnox: So then how do I know if someone in Foundations is working on it? | 09:32 |
| tsimonq2 | Like, are there notes on the foundations-internal side? | 09:33 |
| tsimonq2 | I guess my point is, if I want to fix a bug tagged like that, I don't want to disrupt anything or duplicate work if there's something I can't see. | 09:36 |
| xnox | tsimonq2, there are no notes on the foundations-internal side, as that is private foundations trello boards | 09:38 |
| xnox | tsimonq2, it's a public bug, you will see public merge proposal if its done. and we would really love to review merge proposals =) | 09:39 |
| xnox | tsimonq2, note that than one might need multiple fixes -> e.g. fix those specific packages to use no-await triggers and upload that; develop something in release-upgrader to be smart and self resolve trigger loops. | 09:39 |
| tsimonq2 | xnox: Right. | 09:40 |
| tsimonq2 | xnox: My ultimate goal in digging into these types of bugs is to learn and apply that to fixing future bugs faster. So I'm not entirely sure how the triggers really work quite yet, but it shouldn't be too hard to learn. ;) | 09:43 |
| juliank | Laney: I'm noticing that ubuntu-release-upgrader and update-manager autopkgtests fail to connect to changelogs.ubuntu.com via HTTPS, same test via HTTP works fine. I was wondering if you could check manually in an autopkgtest environment, in case that's simply firewall blocking access and needing unblock | 09:44 |
| juliank | Like run nc changelogs.ubuntu.com 443 and write GET / HTTP/1.0 to it. | 09:46 |
| juliank | It then answers with bad request | 09:47 |
| juliank | because I'm talking plain to a TLS server :D | 09:47 |
| cjwatson | juliank: Yes, this is a clear firewall bug | 09:55 |
| cjwatson | juliank: Grab lp:~canonical-is-firewall-configs/canonical-is-firewalls/+git/firewall-configs and look at rules/is/changelogs.yaml | 09:55 |
| juliank | cjwatson: thanks | 09:56 |
| cjwatson | juliank: See https://docs.admin.canonical.com/is-firewalls/mojo-is-firewalls/user/ for how to propose a fix | 09:57 |
| Laney | cheers | 09:57 |
| cjwatson | (These are all Canonical-only links - sorry to the rest of the channel) | 09:57 |
| xnox | tsimonq2, https://lintian.debian.org/tags/uses-implicit-await-trigger.html | 10:12 |
| xnox | tsimonq2, and links from there to the debian bug report | 10:12 |
| acheronuk | can anyone suggest who is best to approach to get the debdiff in comment #21 of LP: #1572244 actioned/uploaded? | 11:03 |
| ubottu | Launchpad bug 1572244 in casper (Ubuntu Bionic) "Kubuntu requires that the WiFi password be entered twice before WiFi can be used" [Medium,Confirmed] https://launchpad.net/bugs/1572244 | 11:03 |
| rbasak | Maybe cyphermox: ^ | 11:54 |
| rbasak | acheronuk: also subscribe ~ubuntu-sponsors to the bug, though I'd want to check with someone appropriate on the foundations team before sponsoring it. | 11:55 |
| acheronuk | rbasak: yeah, as it's in main I held off | 11:55 |
| acheronuk | sponsors subbed | 11:58 |
| ahasenack | Laney: hey, good morning, did you see my ping from a few days ago about gvfs? Are you preparing a new upload by any chance? | 12:11 |
| Laney | ahasenack: I saw it. I'm going to upload at some point, and I'll look at the test then. | 12:15 |
| ahasenack | Laney: is there a way to tell how frequently people hit the retry button for gvfs? | 12:16 |
| Laney | The first request for a trigger/version/package triple will be the one from proposed-migration, and the subsequent ones manual retries. | 12:18 |
| Laney | If you want to gather data to lobby our team though, you don't need to. | 12:18 |
| ahasenack | just wanted some confirmation it's flaky for others as well :) | 12:19 |
| ahasenack | could you then perhaps please click the retry button for my samba upload then? | 12:19 |
| Laney | Okay. | 12:19 |
| ahasenack | Laney: https://pastebin.ubuntu.com/p/yhBhSJjdhG/ 5-10s | 12:23 |
| ahasenack | the one really failing is unmount_api(), but I changed it in the other too for consistency | 12:23 |
| Laney | ahasenack: if you could, it'd be nice to test that | 12:24 |
| ahasenack | I can test that, but since I can't reproduce the failure, it would just tell me the code works | 12:24 |
| ahasenack | it's only happening in excuses | 12:24 |
| Laney | You can upload to a PPA and then we can run the test there | 12:25 |
| ahasenack | ok | 12:25 |
| Laney | 5 seconds already feels like it should be long enough, so maybe this is something else | 12:26 |
| Laney | we'll see I guess | 12:26 |
| ahasenack | Laney: it could definitely be something else | 12:26 |
| Laney | cheers! | 12:26 |
| ahasenack | Laney: since the failure to unmount is about "filesystem is in use" | 12:26 |
| Laney | ahasenack: I bumped the existing hints to apply to this version instead of retrying btw | 12:40 |
| Laney | it's skipped on ppc64el already | 12:40 |
| ahasenack | on s390, you mean | 12:48 |
| ahasenack | the error in s390x is different, though | 12:49 |
| Laney | no | 12:51 |
| Laney | I mean ppc64el | 12:51 |
| tsimonq2 | xnox: ack, thanks | 12:54 |
| ahasenack | Laney: https://launchpad.net/~ahasenack/+archive/ubuntu/gvfs-test-fixes-1713098/+packages has that timeout bump. We would need that ppa enabled for ppc, though, right? | 13:15 |
| Laney | ahasenack: you should be able to do it in the settings | 13:16 |
| Laney | "change details" | 13:16 |
| ahasenack | oh, indeed | 13:16 |
| ahasenack | I thought it would need a trip to rt/webops | 13:16 |
| Laney | I think if you copy the package back on top of itself using copy-package it'll generate the missing build records? | 13:17 |
| ahasenack | I'll try | 13:17 |
| ahasenack | no, it doesn't like it. I'll bump the ~ppaN suffix and reupload | 13:18 |
| Laney | what did it do? | 13:19 |
| ahasenack | said version already existed | 13:20 |
| enyc | rbasak: ok, can you point me at the SRU and backports process so I do it -- or you start? -- Xenial-case is much simpler (but STRONGLY advise keep byte-for-byte original xenial mke2fs.conf). Does it START as a Backport or START as an SRU?. Trusty, is more complicated, as documented. | 13:23 |
| rbasak | enyc: https://wiki.ubuntu.com/UbuntuBackports and https://wiki.ubuntu.com/StableReleaseUpdates. An SRU is more likely to be refused under the SRU policy. | 13:25 |
| rbasak | For an SRU it might be worth getting a +1 from the SRU team first. | 13:25 |
| rbasak | I'm on the SRU team, but I should probably defer to one of the others. | 13:25 |
| enyc | rbasak: right, but what ''practically helps'' in this case? does it HELP to get a PPA out? does it HELP to get a backport done first, intending it to later become an SRU ? | 13:25 |
| rbasak | enyc: yes I'm assuming that SRUs wouldn't change default behaviour at all. | 13:25 |
| enyc | rbasak: in pparticular, this (somehow) needs considerable ''regression analysis testing'' however we can get that ? | 13:26 |
| Laney | ahasenack: I triggered 5 runs each on amd64 & i386 | 13:26 |
| rbasak | enyc: good question | 13:26 |
| enyc | rbasak: can you ask that (initial) question of your colleagues and come back with suggestions? | 13:27 |
| ahasenack | Laney: ok | 13:27 |
| rbasak | enyc: both for a backport and an SRU the reviewing teams will expect that the person driving has at least done some informal testing and verification. Doing that in a PPA allows easier sharing, so sure that'll help without any increased effort really. | 13:28 |
| enyc | rbasak: does PPA / build system provide mechanism to 'build for all architectures' [and more the point, run the PPA build through ubuntu build-system], not just "upload my own binaries on limited arches" ? | 13:31 |
| cjwatson | you can enable architectures of your choice on a PPA's "change details" page | 13:31 |
| cjwatson | I don't know what "ubuntu build-system" you are referring to | 13:31 |
| enyc | as in, ubuntu/launchpad/build-system/PPA-system/conincal somewhere "builds" your PPA from source, it doesn't just distribute source/binaries you give-it only... | 13:32 |
| cjwatson | backports in general do not become SRUs; they're a different path | 13:32 |
| enyc | nods | 13:32 |
| cjwatson | that's how PPAs work. you don't have to do anything to invoke that behaviour | 13:33 |
| enyc | ok, all new to me =) | 13:33 |
| cjwatson | in particular it is not possible to upload your own binaries to a PPA | 13:33 |
| rbasak | enyc: I posted this: https://lists.ubuntu.com/archives/ubuntu-devel/2018-March/040250.html | 13:33 |
| enyc | right. I recall that sort of thing changing in debian maintainers system at some point... they CHANGED to a sysetm where all binaries have to be built in controlled-environment. | 13:33 |
| cjwatson | no | 13:34 |
| cjwatson | that is not true | 13:34 |
| cjwatson | Debian has source-only uploads now, yes, and that's a big improvement as they become normalised; but it's still possible for developers to upload their own binaries | 13:34 |
| enyc | okies | 13:34 |
| enyc | maybe the 'have to be built' part applies to release versions, at least | 13:35 |
| enyc | nm, would have to check facts and all that | 13:35 |
| cjwatson | no, you just have a slightly exaggerated view :) | 13:35 |
| cjwatson | the way source packages in PPAs are built is very close to identical to how source packages in Ubuntu are built. there are a few differences, and PPAs have to be configured in a particular way if the intent is to actually copy the binaries from them into Ubuntu verbatim; but that isn't usually necessary, and for testing they're nearly always good enough | 13:36 |
| Laney | ahasenack: https://paste.ubuntu.com/p/tXS2dnzYVy/ | 13:36 |
| cyphermox | acheronuk: rbasak: ack, I will sponsor that if it's not done yet... | 13:45 |
| acheronuk | cyphermox: thanks. much appreciated | 13:46 |
| ahasenack | Laney: ppc builds are done | 13:57 |
| ahasenack | Laney: I also have https://launchpad.net/~ahasenack/+archive/ubuntu/unchanged-gvfs/+packages to compare with, if you want | 13:57 |
| ahasenack | grr, or so I thought | 13:58 |
| * ahasenack hates ppas sometimes | 13:58 | |
| ahasenack | "already uploaded, blabla" | 13:58 |
| TJ- | Anyone here responsible for checking the ubuntu-devel mailing list moderation queue? I sent to the list on the 17th for the ext4 metadata_csum thread but it's not appeared as yet | 14:10 |
| cjwatson | I can do that, one moment | 14:11 |
| cjwatson | done | 14:11 |
| TJ- | cjwatson: many thanks :) | 14:12 |
| rbasak | TJ-: thank you for posting those use cases. That's helpful. | 14:16 |
| TJ- | rbasak: I just noticed a rather vital typo! "If the exported block devices have been formatted by a //18.04// clent then operations on the 16.04 SAN host may fail" | 14:17 |
| rbasak | I didn't notice. I understood the use cases from the general idea :) | 14:18 |
| TJ- | yeah... weird how our brains can do that... probably proof we're not A.I. in a holgraphic universe, or something. Or maybe, it just shows how bad my typing is! | 14:19 |
| rbasak | TJ-: thanks. Now I just noticed that the subject says "backwards" when it should say "forwards". | 14:21 |
| TJ- | I know of a few installations where the SAN hosts will remain on 16.04 but virtualisation clients may be on 18.04 where this could become an issue. I've got one-such here although it's not 'mission critical' | 14:23 |
| TJ- | I wonder if we can get some love for this before 18.04? It's quite an issue now UEFI-SB is more popular and breaks a key part of FDE Bug #1565950 | 14:27 |
| ubottu | bug 1565950 in grub2 (Ubuntu) "Grub 2 fails to boot a kernel on a luks encrypted volume with Secure Boot enabled" [Medium,Confirmed] https://launchpad.net/bugs/1565950 | 14:27 |
| TJ- | This is an issue where /boot/ is encrypted and the modules need to be built-in to GRUB's core image, which for the -signed packages, aren't currently included | 14:28 |
| === caravena_ is now known as caravena | ||
| Saviq | hey, what's the best way to get the Ubuntu release code in debian/rules? lsb_release isn't installed on the builders | 14:50 |
| rbasak | Build-Depend on lsb-release? | 14:50 |
| rbasak | That's the common way I've seen in the past. | 14:50 |
| Saviq | ohkay :) | 14:53 |
| LocutusOfBorg | distrelease:= $(shell lsb_release -cs) | 14:53 |
| LocutusOfBorg | this is what gcc does... | 14:53 |
| LocutusOfBorg | also, https://codesearch.debian.net/search?q=lsb-release+path%3Arules | 14:54 |
| juliank | Saviq: the best way is dpkg-vendor --derives-from ubuntu | 14:55 |
| rbasak | LocutusOfBorg: yeah but the build-dep is needed, which I think was the question :) | 14:55 |
| juliank | ah sorry, misread | 14:55 |
| * juliank read it as ubuntu-specific code | 14:56 | |
| juliank | but you meant the codename | 14:56 |
| juliank | *facepalm* | 14:56 |
| Saviq | yeah, I need to switch features on different Ubuntu releases | 14:56 |
| jdonald | Thanks tsimonq2 | 15:16 |
| jdonald | I actually emailed Chris Coulson some weeks ago about merely changing the status of that ticket he had touched last year. I never heard back so I figured he was no longer active at Canonical. | 15:17 |
| jdonald | But I see chrisccoulson here on IRC, and he's the one who added flags to this build last year, so fingers crossed that he can do so again. | 15:17 |
| apw | Saviq, can you use the series name from changelog ? | 15:21 |
| LocutusOfBorg | rbasak, yes I got it, but the "additional dependency needed" was already solved, I wanted to point out the actual code :) | 15:23 |
| LocutusOfBorg | btw Saviq can you enlight me about "what" differs between ubuntu releases? | 15:24 |
| LocutusOfBorg | differing wrt codenames is usually wrong | 15:24 |
| LocutusOfBorg | you know for sure better than me, but sometimes better use "features" to discriminate stuff, e.g. packages versions or similar | 15:25 |
| LocutusOfBorg | stuff gets backported, upgraded and so on (think wrt hwe packages) | 15:25 |
| LocutusOfBorg | so, basing an assumption on "xenial will keep kernel 4.4 forever" is wrong | 15:25 |
| rbasak | LocutusOfBorg: https://lists.ubuntu.com/archives/ubuntu-devel/2017-December/040093.html is one example though I don't know what Saviq's specific case is here. | 15:26 |
| LocutusOfBorg | rbasak, yes, something similar to what I was thinking | 15:29 |
| xnox | Saviq, if in debian/rules: include /usr/share/dpkg/default.mk and then you will have access to $(DEB_DISTRIBUTION) | 15:30 |
| LocutusOfBorg | xnox, won't help I would say... | 15:30 |
| xnox | Saviq, do note you should be using patter matching / starts-with type of matching on it, to catch things like "xenial xenial-proposed xenial-updates xenial-security xenial-backports" | 15:30 |
| Saviq | xnox: lsb-release would never return something like that, would it? | 15:31 |
| xnox | Saviq, this is not based on lsb-release, but based on debian/changelog -> specifically based on who you are building for; not where you are building it on. | 15:31 |
| xnox | Saviq, it uses dpkg-parsechangelog -SDistribution | 15:32 |
| rbasak | Saviq: please make sure that building on the Ubuntu dev release always works including for unknown names. Otherwise rebuilding might break when a new series is opened. | 15:32 |
| xnox | Saviq, i would advise against lsb-release. | 15:32 |
| LocutusOfBorg | and remember, people uses "devel" as codename too | 15:32 |
| xnox | Saviq, can you ellaborate as to what you are actually after to detect, in more detail? | 15:33 |
| xnox | Saviq, and is it at build-time, configure time, runtime, test time, during end-user usage..... ? | 15:33 |
| * xnox recommends using $(DEB_DISTRIBUTION) in debian/rules and search for known things, e.g. trusty,xenial,artful,bionic, assume everything else is newer/better. | 15:35 | |
| Saviq | xnox: well, that's waht I'm trying to do, bud DEB_DISTRIBUTION isn't set by default? | 15:35 |
| xnox | Saviq, did you miss this: | 15:36 |
| xnox | Saviq, if in debian/rules: include /usr/share/dpkg/default.mk and then you will have access to $(DEB_DISTRIBUTION) | 15:36 |
| Saviq | I have that included :\ | 15:36 |
| xnox | Saviq, it's a MAKE variable, not environment variable.... | 15:36 |
| Saviq | aha, that may explain things | 15:36 |
| xnox | Saviq, maybe you need to export it again.... | 15:37 |
| Saviq | I only need it in a $(filter), so I suppose curly brackets.. | 15:39 |
| cjwatson | $(...) nests | 15:39 |
| xnox | Saviq, round =) not curly | 15:39 |
| * xnox calls () round, and {} curly =) | 15:39 | |
| xnox | $(DEB_DISTRIBUTION) | 15:39 |
| cjwatson | both ${variable_name} and $(variable_name) work in make FWIW | 15:40 |
| xnox | oh | 15:40 |
| xnox | ok | 15:40 |
| xnox | today i learned..... | 15:40 |
| cjwatson | or for functions, for that matter | 15:40 |
| cjwatson | though I'm not sure I've ever seen functions used with ${..} | 15:41 |
| xnox | https://stackoverflow.com/questions/25185607/whats-the-difference-between-parenthesis-and-curly-bracket-syntax-in-ma says no difference | 15:41 |
| Saviq | ok then I'm doing something wrong, back to it | 15:42 |
| xnox | Saviq, paste a diff to pastebin, for me/us to see and check? | 15:42 |
| persia | Most make implementations should support ${func arg,arg,arg} | 15:42 |
| cjwatson | right, I just don't think I've ever actually seen anyone trying to use it :) | 15:43 |
| cjwatson | for whatever reason | 15:43 |
| benpicco | Why is mono in Ubuntu stuck at such an old version? Is the package orphaned? | 15:51 |
| nacc | benpicco: 4.6.2.7 in bionic | 15:53 |
| benpicco | nacc: the latest upstream release is 5.10.0.160 | 15:53 |
| ogra_ | ubuntus mono comes from debian ... | 15:54 |
| ogra_ | (IIRC) | 15:54 |
| ogra_ | so whatever is in debian at the time of the import freeze of an ubuntu release will be in the ubuntu archive | 15:54 |
| xnox | benpicco, mono is available; but not widely used at all. E.g. none of the packages in main use mono. | 15:54 |
| xnox | hence not much cared about either | 15:55 |
| xnox | benpicco, what do you want to use it for? | 15:55 |
| benpicco | xnox: renode, which is a firmware simulation tool | 15:55 |
| nacc | benpicco: what ogra said, as well | 15:55 |
| xnox | benpicco, ask upstream to provide a snap for it? | 15:56 |
| xnox | benpicco, (possibly with whichever mono they recommend) | 15:56 |
| ogra_ | +1 | 15:56 |
| benpicco | xnox: upstream already provides a repository for Ubuntu 16.04 which works fine, I was just wondering why it's not included in ubuntu | 15:56 |
| xnox | out of "big" mono things we have tomboy, banshee, smuxi apps. | 15:57 |
| xnox | benpicco, probably because nobody packaged it for distribution, and went through sponsorship process to provide it. | 15:57 |
| xnox | benpicco, if there is an archive for it already, building a snap should be fairly straightforward, then it will be available on all ubuntu systems; always latest stable; via $ snap install renode | 15:58 |
| Saviq | xnox: http://paste.ubuntu.com/p/TxqxDvqkXm/ | 15:58 |
| persia | From a quick look, it looks like the folk that used to care for Mono in Debian and Ubuntu have moved on to other things. At least one of them is still active upstream, and may appreciate an offer of help. | 16:00 |
| xnox | Saviq, so, when debian/changelog top entry is "bionic", you are comparing ifneq(bionic,) -> which false -> meaning -DMIR_EGL_SUPPORTED=OFF is not added. | 16:02 |
| xnox | sorry, got this wrong | 16:03 |
| xnox | rewind | 16:03 |
| Saviq | yeah, filter-out | 16:04 |
| xnox | Saviq, hmmm | 16:04 |
| xnox | Saviq, that looks invalid syntax, there no? | 16:04 |
| * xnox counts brackets | 16:05 | |
| Saviq | xnox: I'm actually down to http://paste.ubuntu.com/p/8GFDsdmkxq/ | 16:05 |
| Saviq | since the binary won't be there when DMIR_EGL_SUPPORTED=OFF | 16:06 |
| xnox | Saviq, it works here for me, your patch, just fine.... | 16:08 |
| xnox | Saviq, you are updating debian/changelog top line right? to say mir (0.30.0.1-0ubuntu3) bionic; urgency=medium -> then build? | 16:09 |
| Saviq | xnox: yeah I think that's good now across xenial, artful, bionic, which we care about | 16:09 |
| xnox | Saviq, you are updating debian/changelog top line right? to say mir (0.30.0.1-0ubuntu3) xenial; urgency=medium -> then build? | 16:09 |
| Saviq | xnox: yeah, changelog gets "real" when building for real | 16:09 |
| xnox | so you are all good =) cool. | 16:10 |
| Saviq | xnox: I think so, will report back if not - btw, any pointers on debugging this, other than rebuilding from scratch over and over again? | 16:11 |
| xnox | Saviq, well, to test here locally, I added | 16:11 |
| xnox | snos: | 16:11 |
| xnox | echo done | 16:11 |
| xnox | Saviq, just _after_ your lines that configure variables and print the info thing. | 16:12 |
| xnox | and called ./debian/rules snos | 16:12 |
| Saviq | ack | 16:12 |
| xnox | Saviq, you can make dh_install fail with "exit 1" just before doing the real dh_install -> then backup the dir; and change changelog/do reruns without exit 1, using $ debuild -- binary -> which should pick up where dh_install left off. | 16:13 |
| Saviq | nifty, will try that, thanks :) | 16:14 |
| jbicha | btw, tomboy and banshee are scheduled for removal from Debian Testing next month 😢 | 16:20 |
| Saviq | NOOOOoooooo..... | 16:55 |
| jbicha | shutter too | 16:59 |
| === mhcerri_ is now known as mhcerri | ||
| izznogooood | jbicha, flameshot | 18:05 |
| sarnold | bdmurray: 1756640 has a HookError_source_ubiquity.txt that shows some python2 -> python3 errors still exist. Can you recall if this has already been "fixed" .. but is still on the distributed isos? | 19:14 |
| bdmurray | sarnold: Should have been fixed in 2.20.8-0ubuntu7 of apport which is Bionic only. | 19:16 |
| sarnold | bdmurray: great! thanks :) | 19:16 |
| bdmurray | sarnold: Did you see the discussion regarding journalerrors? | 19:17 |
| sarnold | bdmurray: hrm. I know I once complained about systemd's tools ellipsizing away all the useful content, but that's it; was there something else? | 19:19 |
| bdmurray | sarnold: systemd journal errors and security concerns like bug 1738581 | 19:20 |
| ubottu | bug 1738581 in apport (Ubuntu) "apport is leaking environment variables (including passwords!) to public bug reports" [High,Fix released] https://launchpad.net/bugs/1738581 | 19:20 |
| sarnold | bdmurray: oh, I missed seb's comment here | 19:21 |
| bdmurray | sarnold: A discussion was also started on ubuntu-devel | 19:21 |
| sarnold | bdmurray: heh, looks like some folks had a busy weekend... | 19:24 |
| === Elimin8r is now known as Elimin8er | ||
| tyhicks | mwhudson: hello! do you have any insight into why the docker.io build tests are failing? | 20:41 |
| tyhicks | https://launchpad.net/ubuntu/+source/docker.io/17.03.2-0ubuntu4 | 20:41 |
| tyhicks | mwhudson: the docker-in-lxd autopkgtest was broken on bionic so I updated it so that I could unwedge my apparmor upload | 20:42 |
| tyhicks | mwhudson: however, there's an unrelated build test failure that fails even when rebuilding 17.03.2-0ubuntu3 (without my changes) | 20:43 |
| tyhicks | mwhudson: I spent some time poking around and it looks like a docker and golang 1.10 incompatibility: https://github.com/moby/moby/pull/35739#issuecomment-350385654 | 22:36 |
| tyhicks | mwhudson: I'm in over my head and I'm hoping you know what to do here | 22:36 |
| === xevious_ is now known as xevious | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!