[05:12] RAOF: looks like new dpkg broke colord autopkgtests https://ci.debian.net/packages/c/colord/testing/amd64/ I wonder why test 2 went from SKIP to FAIL === cpaelzer__ is now known as cpaelzer [05:48] dannf: FYI - the requested libvirt uploads are now in the SRU unapproved queue [07:30] cpaelzer__: I think zope.event already made it to main hence my question [07:33] jbicha: Urgh, thanks. I'll take a look today. [08:27] cpaelzer__: doko: didrocks: for MIRs; would we want to add the Debian Perl Group to the list of official bug subscribers? they seem to be subscribing to the packages, and actually paying attention to the MIR bugs even. [08:27] cyphermox: I trust your analyze, so if that fit with your review, that's ok for me [08:28] didrocks: infinity pointed it out; they're very responsive, pay attention to the bugs and all of that. Usually for MIRs we expect some kind of Canonical team, but I don't know that we can't make an exception for highly responsive "upstreams" for stuff that happens to show up a lot for the distro [08:29] ie. devscripts gaining a bunch of depends for various perl magic; lots of it is trivial to review too :) [08:29] I think libhttp-tiny-multipart-perl contained more test code than feature code. [08:30] cyphermox: LGTM then, +1 [08:31] I'll let others give their opinions too :) [08:31] yup [08:31] also, well Perl ;) [08:31] jdstrand: ^ [08:31] didrocks: Perl <3, my first love. [08:32] cyphermox: only on Friday afternoon, before week-end and booze :) [08:32] that's my rule :p [08:35] cyphermox: part of the team subscriber thing is that if canonical is saying we'll support this package, that someone at canonical will notice bugs.. [08:35] cyphermox: .. certainly having the debian perl team subscribed would be quite nice, but that's not the same as saying someone at canonical will review issues as they come in [08:46] nah, that's what I was saying earlier, but the exception doesn't feel too bad considering the kind of packages we're looking at in this case; perhaps we should review those case-by-case [08:47] I mean, here, it's for devscripts, which is low-level distro stuff that we definitely use; it's different than reviewing a new package for the desktop for instance [08:47] good point [08:49] I guess that means it would have to be case-by-case [08:49] cyphermox: I'm all for adding them, but does that group perform uploads to Ubuntu for bug fixes? if not, then we'll only get fixes for the dev release and not stable releases [08:49] bug fixes in SRUs* [08:50] bug fixes in dev releases is great, but users run stable releases (of course) and if no one is looking after taking care of them, I think I defeats the purpose of requiring a bug subscriber [09:08] coreycb: Yo. [09:09] coreycb: chown -R masakari:masakari /var/lib/masakari /etc/masakari [09:09] coreycb: ^-- explain to me why it should own and have write access to its conffiles. [09:15] coreycb: Also, you seem to have two patches - one to disable a failing test on python3.6, and one to fix the test that the other patch disables? [09:25] rbalint: You're a bit optimistic that waylandpp will make it through NEW before feature freeze, right? 😁 [09:28] RAOF, upload date is what counts for ff, not accepted date [09:29] seb128: Yeah, but he should also be uploading the new kodi release that depends on his NEW package, too :) [09:31] ahasenack, cpaelzer_: looked at talloc. looks like both the architecture name and the python version is still encoded ... [09:32] +libpytalloc-util.cpython-37m-x86-64-linux-gnu.so.2 python3-talloc #MINVER# [09:32] + PYTALLOC_UTIL.CPYTHON_37M_X86_64_LINUX_GNU_2.1.15@PYTALLOC_UTIL.CPYTHON_37M_X86_64_LINUX_GNU_2.1.15 2.1.15-0ubuntu2 [09:32] + PYTALLOC_UTIL.PY3_2.1.10@PYTALLOC_UTIL.PY3_2.1.10 2.1.15-0ubuntu2 [09:32] + PYTALLOC_UTIL.PY3_2.1.11@PYTALLOC_UTIL.PY3_2.1.11 2.1.15-0ubuntu2 [09:33] that I don't know how to change [09:36] looking at my old patches, and then asking upstream ... [09:40] ahasenack: samba-technical talks about a nopython build ... [09:47] jdstrand: best point against it, then; but either way we still need someone on the hook for it in Canonical. [10:04] RAOF, well, upload, it will depwait and technically it's before ff :) [10:22] doko: When you remove stuff like https://launchpad.net/ubuntu/+source/libmarc-charset-perl/+publishinghistory "for autopkgtest failures", could we have a bug for reference so we have a clue *what* you removed, and a bit more why? [10:23] doko: LocutusOfBorg is attempting to reintroduce it (which seems reasonable, cause I can't work out how it was reasonable to remove it), but now I have no idea what else was removed at the same time. [10:24] Looks like libmarc-xml-perl is the only rdep in unstable. [10:30] infinity: did you look at the removal message. no, I don't remember why [10:31] doko: Yes. The removal message that said you removed it "for autopkgtest failures". Which is a bit of a piss-poor reason to remove a package. But also, mentions you removed its rdeps, with no mention of what packages those were. [10:31] doko, autopkgtestsuite failed on arm* probably [10:36] infinity: just this, or together with another package? [10:36] hmm, so you cannot see which packages were removed together? [10:36] doko: No. [10:37] crap [10:38] doko: I *think* it was only 2 packages, based on the rdeps in Debian, and those are both back now, but can't say for sure, which is annoying. [10:38] libmarc-xml-perl libmarc-charset-perl [10:38] LocutusOfBorg: Those would be the two I'm assuming. [10:39] and now libcatmandu-marc-perl [10:39] so we don't keep removal logs? [10:39] Oh, also libnet-z3950-simple2zoom-perl [10:39] LocutusOfBorg: Not as batches. [10:40] LocutusOfBorg: The publishing history of a package gives the removal comment. If the comment is useless, \o/ [10:40] ahasenack: there are no rdeps for python2 samba packages, just python-tdb is recommended by bzr-git [10:40] Right, copying libnet-z3950-simple2zoom-perl back in too. [10:40] thanks [10:42] LocutusOfBorg: You might still get to figure out what's up with the autopkgtest failures that doko deleted for back in bionic, if you want this all to migrate. [10:42] LocutusOfBorg: But I'll leave that to you. [10:42] I already had a quick look [10:43] btw, wasn't "kick out to proposed" enough for the perl migration? I don't understand why they were removed [10:44] LocutusOfBorg: I'm with you. [10:44] LocutusOfBorg: Unfortunately, not all AAs agree (and doko isn't alone in his view) [10:44] RAOF, patches are even more welcome than snarky comments ;-) [10:45] rbalint: ? [10:45] rbalint: But less easily generated! [10:45] oh, ok nice to know there are different point of view :) [10:46] LocutusOfBorg: Yeah, I'm working on turning us into one, homogenous hive-mind, but these people and their opinions keep getting in my way. :P [10:48] we should implement auto-removals like Debian is doing ... [10:51] oSoMoN: hi! how is the libreoffice update in bionic going regarding the openjdk-11 support? [10:53] jamespage: Yo. Re, python-os-ken. While "do stuff | :" will technically do what you want, because true always exits 0 regardless of input, I'm pretty sure you meant "||" (or) not "|" (pipe) :P [10:54] infinity: looking [10:54] jamespage: Not remotely reject-worthy, cause hey, it'll work anyway, just thought I'd mention it. [10:54] infinity: thanks indeed you are quite right [10:54] * jamespage commits that fix now [10:55] jamespage: If you're in a nitpicky mood, try a "lintian -I --pedantic" too. [10:56] infinity: looks like I have some updates I need to work into my cookiecutter template [11:23] tdaitx, not sure I understand your question, is openjdk-11 going to be backported to bionic? [11:23] hello [11:24] oSoMoN: yes, it is, we are working on the transition and libreoffice is one of the packages that fail... the way I was told led me to believe you knew about the transition [11:24] sil2100, https://bugs.launchpad.net/ubuntu-image/+bug/1817050 [11:24] Launchpad bug 1817050 in Ubuntu Image "Updating grub-efi breaks classic images" [Undecided,New] [11:25] tdaitx, I didn't, but that's good news as it should finally address that i386 crash [11:26] tdaitx, where can I inspect the failed builds? [11:27] oSoMoN: doko did a rebuild with openjdk-11, you can find it @ http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html [11:31] tdaitx, that looks like an easy one, we'll need that patch: https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/tree/patches/fix-tests-openjdk11.patch?h=ubuntu-disco-6.1 [11:34] tdaitx, I can prepare a PPA with that patch and building against https://launchpad.net/~openjdk-r/+archive/ubuntu/ppa/+packages, to check whether that's all that's neede [11:34] needed [11:34] (after lunch) === led_dark_2 is now known as led_dark_1 [12:48] xnox: Could the test case in bug 1813888 be a bit more descriptive? [12:48] Error: Could not gather data from Launchpad for bug #1813888 (https://launchpad.net/bugs/1813888). The error has been logged [13:23] bdmurray, expanded [13:38] tdaitx, LO building against openjdk-11 in https://launchpad.net/~osomon/+archive/ubuntu/lo-bionic-openjdk11/+packages [14:00] xnox: I reported the geary test failures at https://gitlab.gnome.org/GNOME/geary/issues/259 & https://gitlab.gnome.org/GNOME/geary/issues/260 [14:12] seb128: evolution*, right? [14:12] sil2100, yes [14:14] oSoMoN, looks like chromium is having a sad day... [14:15] LocutusOfBorg, yes, I'm looking at it [14:30] infinity: RAOF: thanks for the review. i've updated the chown and uploaded again. RAOF, i double checked the skipped tests and they are not fixed by the other patch so we need to keep both patches for now. [14:31] and the reason it's 0ubuntu2 is just because it's easier than reverting tags etc in our git source repo [14:44] coreycb: chown -R root:masakari /etc/masakari still doesn't make sense unless it's shipped 750 (and has sensitive data in it) [14:45] infinity: it's 644 so masakari just gets read access. [14:45] let me check again [14:46] it should be 640 for the chown i currently have [14:47] coreycb: Eh? [14:48] infinity: ok it's 644 so are you ok with me keeping that chown and adding a chmod 640? [14:48] coreycb: You have a sqlite DB in /var/lib at 640, you have a log directory at 750. Neither of those is the config dir in /etc [14:48] infinity: i thought we were focused on /etc [14:49] coreycb: I think you mean 755/750, not 644/640, but sure, if /etc/masakari contains secrets that non-root users shouldn't see. [14:50] coreycb: If it doesn't contain secrets, then there's zero reason for the chown (nor a chmod). [14:52] infinity: probably could just use the defaults. nothing should be executable in /etc/masakari though. [14:52] infinity: want me to just switch to no chmod/chown? [14:55] coreycb: ... nothing is executable? [14:56] coreycb: We're talking about the permissions of a directory, not a file. [14:56] infinity: well it's both. it's a postinst script. [14:58] infinity: here's what we currently get out of it: https://paste.ubuntu.com/p/J8kTghGdCz/ [15:01] infinity: /etc/masakari/masakari.conf will have a db password in it. there may be more sensitive bits. [15:01] infinity: definitely open to suggestsions. i'd like to get this right. [15:03] cyphermox, we would like to get https://github.com/jwrdegoede/grub2/commit/0e6652a6981cf5f9cd4b76fedbf3b68d46b2860a.patch in disco for less-boot-flicker (fedora ships it), any opinion? do you want/can you reiew it? should I just upload? [15:13] doko: why is there an empty llvm-config-patch.diff in clazy? I just left it there in the merge I did this morning as was in a hurry, but thought I better ask in case [15:14] *llvm-config.diff [15:15] acheronuk: just remove [15:16] doko: cheers. I figured as much but had to check. I'll do a ubuntu2 later. thanks [15:16] coreycb: If it's just one file, that should be 640, root:masakari, if you genuinely don't know what might be in that directory, 750 root:masakari for the dir is fine. [15:17] coreycb: Right now, it was 755 root:msakari, which makes no sense. [15:19] infinity: ok i'll rework it to 750 root:masakari for the dir [15:20] coreycb: Kay. [15:28] jbicha, thanks! [15:30] xnox: I see you're interested in s390x and geary so you might need to help upstream when you get some time [15:31] jbicha, not really! i want the new geary to migrate! =) [15:31] on amd64 [15:31] well you're more interested in s390x than anyone I know, but I guess not for geary directly [15:32] seb128: I will do it; in the middle of a grub merge right now [15:32] cyphermox, thx [15:41] sil2100: hi, if you have a moment we have a horizon fix in the cosmic unapproved queue that fixes an issue being hit by field engineers upon upgrade from openstack queens to rocky. [15:46] coreycb: hey! I think I can take a look [15:46] sil2100: thanks :) [15:53] thank you bdmurray! [15:56] infinity: i've uploaded masakari with the etc changes. thanks for reviewing this btw. i'll make sure our other packages are inline once this gets accepted. [15:58] coreycb: Accepted. [15:58] seb128: might slip the FF deadline, but I'll do the paperwork if that happens [15:58] infinity: thanks again [15:59] cyphermox, cool, thx [16:33] Laney: I have updated the MP for britney SRU stuffy: https://code.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/+merge/355544 [16:33] Laney: it's good for review although I still need to setup a local britney setup and see how it acts (so no mergy-mergy yet) [16:33] But a code review at least would be highly welcome