[13:26] <ahasenack> tjaalton: hi, around?
[13:27] <ahasenack> tjaalton: I saw that the freeipa dep8 tests errors are ignored now, in the test itself. I guess the intention is to not have it block other packages
[13:27] <tjaalton> ahasenack: yes
[13:28] <ahasenack> tjaalton: I'm working on fixing the samba+winbind startup issue, for now I'm trying to remove winbind from the test as it's not used, but I saw in catalina.out what looks like another problem:
[13:28] <ahasenack> Caused by: java.lang.UnsupportedClassVersionError: org/mozilla/jss/ssl/SSLSocketListener has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
[13:28] <ahasenack> does that ring a bell?
[13:28] <tjaalton> where's this from?
[13:28] <ahasenack> tjaalton: /var/log/pki/pki-tomcat/catalina.out
[13:29] <tjaalton> ah, you have the fresh libjss-java?
[13:29] <ahasenack> tjaalton: the test run fails like this: https://pastebin.ubuntu.com/p/gs26bM4F8Y/
[13:29] <tjaalton> which builds with jdk11 now
[13:29] <ahasenack> tjaalton: it's disco, I might
[13:29] <tjaalton> 4.5.1-1
[13:29] <ahasenack> yes, that one
[13:30] <tjaalton> dogtag itself needs to be fixed, it'll take a while until new resteasy3.0 with jackson2 provider is available (just uploaded it)
[13:30] <tjaalton> after that dogtag 10.6.8 should be fine, and I've fixed it to build with jdk11
[13:31] <tjaalton> now checking resteasy 3.6.2 if it can replace src:resteasy3.0..
[13:32] <ahasenack> tjaalton: as a workaround for the samba+winbind issue, my intention was to replace the test depends on "@" to a list of packages that excludes freeipa-server-trust-ad, which is what pulls winbind in
[13:33] <ahasenack> but I can't verify that the freeipa tests still run correctly because of the issue I pointed out above
[13:33] <tjaalton> the freeipa test isn't blocking samba, if that's what you're after
[13:33] <ahasenack> it is becuse samba's postinst fails when winbind is running
[13:33] <tjaalton> oh right
[13:33] <ahasenack> it's a samba bug
[13:34] <tjaalton> meh
[13:34] <ahasenack> https://pastebin.ubuntu.com/p/Yc4WPKxQXd/ is what I have, that doesn't trigger the samba bug
[13:34] <tjaalton> yeah that's fine, the ad stuff isn't used there anyway
[13:35] <ahasenack> that installs these packages: https://pastebin.ubuntu.com/p/8GTNNYjVnQ/
[13:35] <ahasenack> we don't get freeipa-tests
[13:35] <tjaalton> that's fine
[13:36] <ahasenack> ok
[13:36] <tjaalton> it's purpose is somewhat unclear to me anyway :)
[13:36] <tjaalton> upstream doesn't use it either
[13:36] <tjaalton> so might just as well drop it, maybe
[13:38] <ahasenack> tjaalton: I'll proposed this: https://pastebin.ubuntu.com/p/vnntfcNWwV/
[13:39] <tjaalton> upload away
[13:39] <ahasenack> I got some comments from ab@samba.org (Alexander) on that issue, but no changes yet
[13:40] <tjaalton> ok
[13:40] <ahasenack> there is a lot of confusion, people see "winbind is running, this must be security = ad or = domain"
[13:58] <doko> didrocks: MIR team meeting
[14:55] <doko> tjaalton: dogtag-pki autopkg tests timing out on amd64, triggered by openjdk-8. could you have a look?
[14:55] <tjaalton> doko: it's WIP, migrating to jdk11
[14:55] <tjaalton> jss migrated, that's causing the timeout
[14:56] <doko> ta
[14:56] <ddstreet> xnox for systemd uploads, do you prefer to check patches into your ubuntu-core-dev systemd repo before a systemd patched pkg is uploaded to the queue?  or do you keep the systemd git up to date after the systemd pkg is sent to -updates?
[14:56] <ddstreet> also thnx for updating disco for the systemd dns bug
[14:57] <xnox> ddstreet, by the time it lands -updates, it's useless, as sru team need access to git repository to review the diff before accepting from unaprooved.
[14:57] <xnox> ddstreet, i'm not sure what your actual question is, but i suspect is that what you really want to know is that no actions are currently needed from you.
[14:58] <ddstreet> xnox i'm asking for future systemd sru uploads, should i instead bug you (or some other core dev) to push the patch into your git before I upload the systemd sru pkg
[14:58] <xnox> ddstreet, as there is a new systemd upload in cosmic unapproved queue with your edns patch; among 6 other bugs
[14:58] <xnox> ddstreet, and bionic is currently blocked on validating snapd specific changes, thus i'm not uploading anything there.
[14:58] <ddstreet> yep thnx for that - this was a question for future systemd sru uploads
[14:58] <xnox> ddstreet, it depends.
[14:59] <xnox> ddstreet, single-patch small srus can go in, however. the larger multi-bug srus have been "hard to review" by the sru team, thus I'm trying to present/show my work in one change per git commit linear format.
[14:59] <ddstreet> ah that makes sense sure
[14:59] <ddstreet> thanks
[15:00] <xnox> ddstreet, for non-urgent things, or staging things whilst there is an existing upload in proposed, git works great for that.
[15:01] <xnox> ddstreet, in general =) i'm very happy about anyone doing systemd work ;-) as long as it gets done from start to finish, and not like leave autopkgtest regressions in security uploads and the like ;-)
[15:01] <xnox> (and however they like)
[15:01] <xnox> and i try to minimize the amount of "boring" stuff they might need to do, after the hard part of figuring out what to fix is done.
[15:03] <ddstreet> xnox much thnx for all your systemd fixing and especially for helping me (and others on my team) apply fixes :)
[15:24] <brainwash> doko: please look into this packaging issue bug 1805197
[15:24] <brainwash> doko: comment #7
[15:43] <dijuremo> Hi, where would be the best place to get some help with Ubuntu 18.04 and grub problems. Seems like the grub package released with 18.04 does *not* have built-in XFS support.
[15:45] <nacc> dijuremo: you want #ubuntu, afaict (support, not development)
[15:48] <TJ-> dijuremo: are your referring to the UEFI signed version?
[15:49] <nacc> dijuremo: if so, it's LP: #1652822
[15:51] <dijuremo> #ubuntu was not helpful at all... :(
[15:52] <dijuremo> Yep, so pretty much I had found that bug, but is there a workaround? I am not so knowledgeable of grub
[15:53] <nacc> dijuremo: that bug lists some workarounds
[15:54] <nacc> cyphermox: --^ do yo uknow?
[15:54] <dijuremo> Do note that bug was opened 2016-12-27, so nothing really has happened in a long time...
[15:54] <dijuremo> The workarounds are *not* permanent, after any kernel install they require manual intervention
[15:55] <nacc> dijuremo: i never said they were?
[15:57] <dijuremo> nacc: I wanted to stick to XFS over ext4, guess this bug and stupid Dropbox are forcing me to change.
[15:57] <nacc> dijuremo: i mean you can do the workaround until the bug is fixed. It looks like Debian has fixed it
[15:59] <cyphermox> xfs is indeed not in the prebuilt grub uefi image
[15:59] <nacc> cyphermox: thanks for confirming
[16:13] <cjwatson> dijuremo: When you say "nothing has happened", I fixed that bug in Debian a bit over a month ago.  Just needs merging (although of course updating a stable release requires more care)
[16:21] <cyphermox> cjwatson: yup, will do soonish
[16:21] <cjwatson> Yep, not a nag :)
[16:21] <nacc> cjwatson: cyphermox: thanks!
[16:23] <cyphermox> :)
[17:01] <dijuremo> nacc: Cannot really do the workaround to deploy hudnreds of machine and risk an update breaking them all...
[17:19] <gQuigs> ubuntu minimal c loud images have grown a lot in cosmic/disco (http://cloud-images.ubuntu.com/minimal/daily/disco/20181129/) - seems to be the inclusion of snap:core/snap:lxd..   is that an intentional change?
[17:20] <rbasak> fginther: ^
[17:24] <nacc> dijuremo: understood
[17:34] <ahasenack> gQuigs: oldest one is http://cloud-images.ubuntu.com/minimal/daily/disco/20181129/ and shows 289M, do you know what the size was before?
[17:35] <gQuigs> ahasenack: just look at bionic - http://cloud-images.ubuntu.com/minimal/daily/bionic/current/
[17:37] <ahasenack> ok, so it's a comparison between distros, I thought initially it was a bump during the development cycle of disco
[17:42] <gQuigs> I think it may have happened during cosmic
[17:42] <gQuigs> dev
[17:43] <Odd_Bloke> gQuigs: rbasak: ahasenack: The increase in minimal image size is due to lxd migrating from a deb to a snap, which did indeed happen during the cosmic development cycle.
[17:57] <gQuigs> can we drop lxd from the minimal image?  it's not really minimal with it...   (report a bug here: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/ ?)
[18:05] <Odd_Bloke> gQuigs: Please do report a bug, against the cloud-images project.
[18:05] <Odd_Bloke> gQuigs: https://bugs.launchpad.net/cloud-images/+filebug
[18:13] <gQuigs> will do, ty
[18:47] <gQuigs> reported -https://bugs.launchpad.net/cloud-images/+bug/1806752