[08:25] 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] ...version 2 watchfile, wow. [10:27] 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] 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] I think `::1` should be treated just like `127.0.0.1` in the autopkgtest environment. wdyt? [10:36] or, is there a LP project or something to track bugs of the autopkgtest infra? [10:36] ^^ cpaelzer spun off from our work on ulfius [10:42] a bug at https://launchpad.net/autopkgtest-cloud maybe? [10:44] 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] mapreri: can you please take a look at this bug: [11:46] https://bugzilla.mozilla.org/show_bug.cgi?id=1732755 [11:46] 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:46] Mozilla bug 1732755 in Release Engineering "Firefox snap cannot access host's hunspell dictionaries for spellchecking" [--, Unconfirmed] [11:49] GunnarHj: reading [11:51] mapreri: Great! Please add possibly input to the bug. [11:51] s/possibly/possible/ [11:51] (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] 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] GunnarHj: if that's the only question, then it's not going to be a problem [11:54] the format for the hunspell dicts has been finalized ages ago and it's not really going to change. [11:55] mapreri: Sounds very promising. Can you please say that on the bug? [11:56] wow, I actually had an account in that bug tracker; I wonder why [11:58] mapreri: Haha, I had too. Proved that I created it 19 years ago. :) [12:02] GunnarHj: "Created 2011-10-14 06:51:24 PDT (10 years ago)" [12:02] (19 years ago I would have been 7 yo, that was quite too early for me :D) [12:03] GunnarHj: I haven't subscribed the bug, so please tell me if you'd like anything else from me. [12:06] mapreri: Will do. Thanks a lot! [12:31] 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] Launchpad bug 1945634 in Auto Package Testing "autopkgtest environment should have ::1 in no_proxy" [Wishlist, Triaged] [12:31] paride: FYI ^^ [12:31] cpaelzer: "We added ::1 on Dec 4 2020, but had to revert it on Dec 14 due to LP: #1908136" [12:31] Launchpad bug 1908136 in curl (Ubuntu Bionic) "no_proxy=::1 is not honored by curl in Bionic and earlier versions" [Undecided, New] https://launchpad.net/bugs/1908136 [12:32] cpaelzer: I marked it as wishlist, because while it would be sensible to have for later releases, it also breaks older ones [12:32] maybe it should be low, I don't know [12:33] now that helps to understand. thanks [12:33] and I guess at the place it is added there is no easy if release >= focal :-/ ? [12:33] cpaelzer: right [12:34] hmm, then I really think ::1 needs to be added, but have no better idea how to achieve that yet :-/ [12:34] juliank: does our automation provide other config data e.g. cloud-init user-data to the test-target? [12:34] juliank: if so we might consider adding it with some logic there so that it is added where it works [12:35] there are like 4 places wehre we set this [12:35] I don't know off hand what is what [12:35] ok, thanks for the extra context - at least that helps to understand why it is missing in the first place === cpaelzer_ is now known as cpaelzer === doko_ is now known as doko === genii-core is now known as genii [15:28] The link to the release notes is opened with gedit: https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/1945658 [15:29] Launchpad bug 1945658 in xdg-utils (Ubuntu) "The link to the release notes is opened with gedit" [Undecided, Confirmed] [15:41] KBar: I can't reproduce this on impish, fwiw [15:42] sometimes file assocation get a bit whacky depending on local config [15:42] juliank: you need to boot up a Live session first. Click "Try Ubuntu", let the desktop start and then start the Ubiquity [15:43] installation process [15:43] Ah ok [15:43] I just tried on my real system [15:43] My bad, I should probably clarify that in the bug report [15:44] thanks [15:49] KBar: I was able to reproduce the issue and have flagged it to the relevant team report [15:50] Curios bugs [15:50] Awesome! Thank you. Meanwhile, I'm gonna try to pinpoint the exact culprit, if no one minds. [15:50] sure! [15:58] Ah. I forgot to check whether clicking on the rest of the links yields the same result. [15:58] The ones that appear near on the slides. === toabctl_ is now known as toabctl === paulw2 is now known as PaulW2U === Beret- is now known as Beret === paulw2 is now known as PaulW2U === dbungert1 is now known as dbungert === JanC_ is now known as JanC [20:24] https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/1945658 [20:24] Launchpad bug 1945658 in xdg-utils (Ubuntu) "Link to release notes on Ubiquity language plugin page is opened with gedit" [Undecided, Triaged] [20:26] I think the issue here is that some of the functions in xdg-settings.in are hard-coded to /text/html [20:26] to/for [20:28] I'm trying to build SSSD on Ubuntu 20.04, but I keep getting stuck on the configure part [20:28] "configure: error: Cannot determine Samba's idmap interface version, please use --with-smb-idmap-interface-version" [20:28] 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] #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] who's the PoC for the ubuntu-devel listserv? [20:35] because... it got spammed. [20:35] oh that's an easy one bluh [20:37] cjwatson: around? [20:38] 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] 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] sarnold: That did it! Thanks! I think the problem was that it wasn't building for x86_64 for whatever reason [20:44] kurts_allenai[m]: heh, that could do it, yeah :) === pizzaiolo is now known as pizza === locutusofborg_ is now known as locutusofborg [21:48] teward: ? [21:48] (only sort of. be quick.) [21:49] I don't see any ubuntu-devel spam either in my mailbox or in the archives. [21:50] 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] the other went to ubuntu-devel-discuss which I don't think you're an admin on [21:50] or rather, i think it only went to announce [21:50] and then got a special reply-to [21:50] that's odd, how did that get moderated through [21:51] no idea, so either it's an exploit in the list system that happened, or someone let them through (hacked creds?) [21:51] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2021-September/thread.html <-- last two items [21:51] I already deleted my local copies of the emails on autopilot, and the list archives don't have enough headers [21:51] 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] (to see more details) [21:52] 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] I added those to the discard list, though I expect that to be largely a waste of time [21:53] please file an RT ticket to ask IS to purge those messages from the archives - I can't do that [21:53] yep will do [21:54] if it's hacked creds it'll happen again and we can investigate at that point [21:54] yep i'll open an IS ticket. [21:54] after dinner. [21:54] (they weren't list members, btw) [21:54] so someone had to let it through moderation, then, I assume. [21:55] either way i'll keep an eye out [21:58] could just have been an accident, I'm not going to get too excited for now [22:03] *shrugs* [22:04] 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] either way, IS can handle it now. [22:05] aye [22:05] thanks [22:13] funny, it's got a dkim signature [22:27] sarnold: I was wrong, when building SSSD 2.5.2, I get the same error [22:27] only on sssd-tools commands like sss_cache [22:28] aww === TheMaster is now known as Unit193 [22:28] The odd part is that sssd itself works fine. It's the sssd-tools package that keeps failing after install === genii is now known as genii-core