[08:25] <DarkTrick> What do I need to do to get the latest version of an app into the repos? (Talking of package `GJiten`, which had no real maintainer for a long time)
[08:46] <Unit193> ...version 2 watchfile, wow.
[10:27] <paride> Hi! src:ulfius is failing to migrate to impish because of an autopkgtest failure, happening on all archs, e.g. for amd64 https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/u/ulfius/20210909_151401_cd5b1@/log.gz
[10:27] <paride> I tracked it down to `::1` not being present in the `no_proxy` env variable, and thus the test fails when trying ipv6 stuff locally
[10:28] <paride> I think `::1` should be treated just like `127.0.0.1` in the autopkgtest environment. wdyt?
[10:36] <paride> or, is there a LP project or something to track bugs of the autopkgtest infra?
[10:36] <paride> ^^ cpaelzer spun off from our work on ulfius
[10:42] <cpaelzer> a bug at https://launchpad.net/autopkgtest-cloud maybe?
[10:44] <paride> which says to file bugs to https://bugs.launchpad.net/auto-package-testing. anyway that's (again!) just what I needed, ty cpaelzer
[11:46] <GunnarHj> mapreri: can you please take a look at this bug:
[11:46] <GunnarHj> https://bugzilla.mozilla.org/show_bug.cgi?id=1732755
[11:46] <GunnarHj> Do you have any thoughts about the discussion there about whether hunspell dictionaries may become incompatible with the hunspell version used by the snap?
[11:49] <mapreri> GunnarHj: reading
[11:51] <GunnarHj> mapreri: Great! Please add possibly input to the bug.
[11:51] <GunnarHj> s/possibly/possible/
[11:51] <mapreri> (not that I don't use snaps anywhere myself though; and I'm very much not going to start just to try that)
[11:53] <GunnarHj> mapreri: No need to. The question is whether there might be a problem to make use of e.g. the latest hunspell dicts from unstable using the bionic version of the hunspell program, etc.
[11:54] <mapreri> GunnarHj: if that's the only question, then it's not going to be a problem
[11:54] <mapreri> the format for the hunspell dicts has been finalized ages ago and it's not really going to change.
[11:55] <GunnarHj> mapreri: Sounds very promising. Can you please say that on the bug?
[11:56] <mapreri> wow, I actually had an account in that bug tracker; I wonder why
[11:58] <GunnarHj> mapreri: Haha, I had too. Proved that I created it 19 years ago. :)
[12:02] <mapreri> GunnarHj: "Created	2011-10-14 06:51:24 PDT (10 years ago)"
[12:02] <mapreri> (19 years ago I would have been 7 yo, that was quite too early for me :D)
[12:03] <mapreri> GunnarHj: I haven't subscribed the bug, so please tell me if you'd like anything else from me.
[12:06] <GunnarHj> mapreri: Will do. Thanks a lot!
[12:31] <cpaelzer> hi juliank - is https://bugs.launchpad.net/auto-package-testing/+bug/1945634 really wishlist or is there a detail that we don't see yet?
[12:31] <cpaelzer> paride: FYI ^^
[12:31] <juliank> cpaelzer: "We added ::1 on Dec 4 2020, but had to revert it on Dec 14 due to LP: #1908136"
[12:32] <juliank> cpaelzer: I marked it as wishlist, because while it would be sensible to have for later releases, it also breaks older ones
[12:32] <juliank> maybe it should be low, I don't know
[12:33] <cpaelzer> now that helps to understand. thanks
[12:33] <cpaelzer> and I guess at the place it is added there is no easy if release >= focal :-/ ?
[12:33] <juliank> cpaelzer: right
[12:34] <cpaelzer> hmm, then I really think ::1 needs to be added, but have no better idea how to achieve that yet :-/
[12:34] <cpaelzer> juliank: does our automation provide other config data e.g. cloud-init user-data to the test-target?
[12:34] <cpaelzer> juliank: if so we might consider adding it with some logic there so that it is added where it works
[12:35] <juliank> there are like 4 places wehre we set this
[12:35] <juliank> I don't know off hand what is what
[12:35] <cpaelzer> ok, thanks for the extra context - at least that helps to understand why it is missing in the first place
[15:28] <KBar> The link to the release notes is opened with gedit: https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/1945658
[15:41] <juliank> KBar: I can't reproduce this on impish, fwiw
[15:42] <juliank> sometimes file assocation get a bit whacky depending on local config
[15:42] <KBar> juliank: you need to boot up a Live session first. Click "Try Ubuntu", let the desktop start and then start the Ubiquity
[15:43] <KBar> installation process
[15:43] <juliank> Ah ok
[15:43] <juliank> I just tried on my real system
[15:43] <KBar> My bad, I should probably clarify that in the bug report
[15:44] <KBar> thanks
[15:49] <juliank> KBar: I was able to reproduce the issue and have flagged it to the relevant team report
[15:50] <juliank> Curios bugs
[15:50] <KBar> Awesome! Thank you. Meanwhile, I'm gonna try to pinpoint the exact culprit, if no one minds.
[15:50] <juliank> sure!
[15:58] <KBar> Ah. I forgot to check whether clicking on the rest of the links yields the same result.
[15:58] <KBar> The ones that appear near on the slides.
[20:24] <KBar> https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/1945658
[20:26] <KBar> I think the issue here is that some of the functions in xdg-settings.in are hard-coded to /text/html
[20:26] <KBar> to/for
[20:28] <kurts_allenai[m]> I'm trying to build SSSD on Ubuntu 20.04, but I keep getting stuck on the configure part
[20:28] <kurts_allenai[m]> "configure: error: Cannot determine Samba's idmap interface version, please use --with-smb-idmap-interface-version"
[20:28] <kurts_allenai[m]> If I try and get past that by manually setting the idmap version, sssd-tools gives me an ELF error every time. How do you build SSSD successfully?
[20:33] <KBar> #1945658 maybe adding text/xml to MIME will fix it but what do I know? I'm not a programmer, sadly. I should have listened to my granny when she to was telling me to learn shell scripting! XD
[20:35] <teward> who's the PoC for the ubuntu-devel listserv?
[20:35] <teward> because... it got spammed.
[20:35] <teward> oh that's an easy one bluh
[20:37] <teward> cjwatson: around?
[20:38] <sarnold> kurts_allenai[m]: if the debian/rules file is a bit impenetrable the build logs may have answers .. https://launchpadlibrarian.net/554173846/buildlog_ubuntu-focal-amd64.sssd_2.2.3-3ubuntu0.7_BUILDING.txt.gz
[20:39] <sarnold> kurts_allenai[m]: if you need other versions you can get tehre from the source package page on launchpad, https://launchpad.net/ubuntu/+source/sssd  -- click on versions, then architecture, then buildlog
[20:43] <kurts_allenai[m]> sarnold: That did it! Thanks! I think the problem was that it wasn't building for x86_64 for whatever reason
[20:44] <sarnold> kurts_allenai[m]: heh, that could do it, yeah :)
[21:48] <cjwatson> teward: ?
[21:48] <cjwatson> (only sort of.  be quick.)
[21:49] <cjwatson> I don't see any ubuntu-devel spam either in my mailbox or in the archives.
[21:50] <teward> cjwatson: two spam items made it to two of teh lists, including ubuntu-devel-announce, any chance you could find and erase those memberships on u-d-a?  Alternatively I could ask IS to do it but I thought i'd ask an admin first
[21:50] <teward> the other went to ubuntu-devel-discuss which I don't think you're an admin on
[21:50] <teward> or rather, i think it only went to announce
[21:50] <teward> and then got a special reply-to
[21:50] <cjwatson> that's odd, how did that get moderated through
[21:51] <teward> no idea, so either it's an exploit in the list system that happened, or someone let them through (hacked creds?)
[21:51] <teward> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2021-September/thread.html  <-- last two items
[21:51] <cjwatson> I already deleted my local copies of the emails on autopilot, and the list archives don't have enough headers
[21:51] <teward> both are typically **hard-blocked** when they deliver to my infrastructure direct to my @ubuntu.com address but now it seems they're hitting the local ones.
[21:51] <cjwatson> (to see more details)
[21:52] <teward> cjwatson: i can just ask IS to do a domain level block if needed, or track it there, but spam DID get to -announce so
[21:53] <cjwatson> I added those to the discard list, though I expect that to be largely a waste of time
[21:53] <cjwatson> please file an RT ticket to ask IS to purge those messages from the archives - I can't do that
[21:53] <teward> yep will do
[21:54] <cjwatson> if it's hacked creds it'll happen again and we can investigate at that point
[21:54] <teward> yep i'll open an IS ticket.
[21:54] <teward> after dinner.
[21:54] <cjwatson> (they weren't list members, btw)
[21:54] <teward> so someone had to let it through moderation, then, I assume.
[21:55] <teward> either way i'll keep an eye out
[21:58] <cjwatson> could just have been an accident, I'm not going to get too excited for now
[22:03] <teward> *shrugs*
[22:04] <teward> cjwatson: rt #36900 for reference.  I made some observations as well as to how hard the inter-pymes stuff hits @ubuntu.com - i have at least three blocked samples from just this week with the same exact contents, they're a well known spam domain at this point to all ubuntu addresses and now the lists (which is new)
[22:04] <teward> either way, IS can handle it now.
[22:05] <cjwatson> aye
[22:05] <cjwatson> thanks
[22:13] <sarnold> funny, it's got a dkim signature
[22:27] <kurts_allenai[m]> sarnold: I was wrong, when building SSSD 2.5.2, I get the same error
[22:27] <kurts_allenai[m]> only on sssd-tools commands like sss_cache
[22:28] <sarnold> aww
[22:28] <kurts_allenai[m]> The odd part is that sssd itself works fine. It's the sssd-tools package that keeps failing after install