=== genii is now known as genii-core
[00:59] <ahoneybun> xnox, vorlon: tagging you folks as I'm not sure who to tag for slideshow changes in the installer for Kubuntu: https://code.launchpad.net/~aaronhoneycutt/ubiquity-slideshow-ubuntu/kubuntu-jammy/+merge/416000
[00:59] <ahoneybun> mmikowski: ^
[01:00] <vorlon> ahoneybun: I believe this has always been managed by the desktop team; pinging kenvandine who I see has uploaded it in the past
[01:05] <ahoneybun> vorlon: :star: thank you!
[01:25] <kenvandine> hey ahoneybun
[01:28] <kenvandine> ahoneybun: i requested a review from seb128
[01:30] <ahoneybun> thank you kenvandine!
[01:45] <kenvandine> ahoneybun: you're welcome
[08:53] <schopin> tumbleweed: I found an easy way to crash reverse-depends: reverse-depends -b rustc :)
[09:04] <schopin> Anyone knows of a way to get the list of binary packages from a source name? (without having to download the source...)
[09:32] <jbicha> schopin: if you just want to read the file, you can add this as a Chrome search engine/Firefox bookmark: https://sources.debian.org/src/%s/unstable/debian/control/
[09:39] <schopin> jbicha: thanks, but I'm looking for something that can be then scripted :)
[10:33] <cjwatson> schopin: apt-cache showsrc foo | grep ^Binary: ?
[10:38] <schopin> cjwatson: eh. that would have worked indeed! I ended up using custom python-apt code
=== mirespace_ is now known as mirespace
[11:13] <rbasak> schopin: chdist has a src2bin command. But you need a chdist set up of course.
[12:01] <ahasenack> didrocks: hi, morning
[12:01] <ahasenack> didrocks: can you give me a hint at what was the actual failure in this adsys test with my samba 4.15.5 upload? https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/a/adsys/20220224_031434_4d453@/log.gz
[12:39] <didrocks> ahasenack: it seems we can’t start our smbd local daemon to simulate Active Directory smb server
[12:39] <didrocks> maybe the configuration option changed in the new version?
[12:39] <ahasenack> when you say "our smbd" daemon, you mean the normal smbd, but with a custom config?
[12:39] <didrocks> and hey :)
[12:40] <didrocks> indeed, normal smbd, run with a custom config for our package tests
[12:40] <ahasenack> where in the logs is that, more or less?
[12:40] <ahasenack> or the startup is hidden?
[12:40] <ahasenack> definitely some smb.conf options changed, also command line options
[12:41] <ahasenack> but I need a hint. It's fine to tell me to run the test manually, the log was just too much for a first triage, hence my ask
[12:42] <didrocks> ahasenack: yeah, I’m puzzled because on smbd start failure, we do print stderr (not stdout though): https://github.com/ubuntu/adsys/blob/main/internal/testutils/samba.go#L16
[12:42] <didrocks> https://github.com/ubuntu/adsys/blob/main/internal/testutils/samba.go#L43 in particular
[12:42] <didrocks> you can see here how we start it: https://github.com/ubuntu/adsys/blob/main/internal/testutils/samba.go#L21
[12:43] <didrocks> and the config template is at https://github.com/ubuntu/adsys/blob/20e6f962eb87f667f5e29800be0715ab2496a10d/internal/testutils/samba.go#L55
[12:43] <ahasenack> 2022/02/24 03:13:59 Setup: smbd hasn’t started successfully
[12:43] <ahasenack> that's here: https://github.com/ubuntu/adsys/blob/main/internal/testutils/samba.go#L129
[12:43] <ahasenack> you wait for the port to be open?
[12:44] <ahasenack> which port is that, 445/tcp?
[12:45] <didrocks> we wait on the port to be opened, and this one is passed as a parameter, see the template. For the argument we pass in ad tests, once sec, looking
[12:45] <didrocks> 1446
[12:45] <didrocks> https://github.com/ubuntu/adsys/blob/20e6f962eb87f667f5e29800be0715ab2496a10d/cmd/integration_tests/adsys_test.go#L47
[12:46] <ahasenack> huh
[12:46] <didrocks> I think I can make it better to still capture stderr in that case for easier debugging in the future
[12:46] <ahasenack> and I think I have enough to go on, I'll try this locally
[12:46] <ahasenack> see what's up with smbd on that port
[12:46] <ahasenack> thanks
[12:46] <didrocks> np! keep me posted
[12:47] <didrocks> you just need to run go test . in internal/ad/
[12:47] <didrocks> the failure is as the pre-test setup
[12:47] <didrocks> at*
[12:47] <ahasenack> didrocks: I'll file a bug against the adsys package in lp to keep track of it, but it might as well be a samba bug, I'll update the bug when I have new info, but it will be assigned to me for now
[12:48] <didrocks> ahasenack: sure, thanks!
[12:59] <tumbleweed> schopin: hah :)
[13:07] <rbasak> schopin: can we conclude something on https://code.launchpad.net/~eivnaes/ubuntu/+source/ppp/+git/ppp/+merge/415397 please?
[13:08] <rbasak> I don't want to discourage new contributors by waiting until after FF and then telling them it's too late :-/
[13:08] <schopin> rbasak: eivnaes seems invested in the issue so IMO we should take in the patch.
[13:09] <rbasak> OK, thanks. I'll review and upload it if OK then. I'm mostly going to accept the code changes as-is given (and checking that they are) upstream.
[13:09] <rbasak> And assuming there's no other fixes to it landed upstream since.
[13:15] <schopin> rbasak: was my message on the MP itself not clear enough on my +1 for the patch?
[13:16] <rbasak> Oh sorry, I hadn't seen that.
[13:16] <rbasak> Which is odd. The reason I know about the MP in the first place is because I got emailed about it.
[13:17] <rbasak> But yeah, thank you for having done that already, and sorry I hadn't seen it.
[13:17] <schopin> np :)
=== sem2peie- is now known as sem2peie
=== genii-core is now known as genii
=== sem2peie- is now known as sem2peie
=== sem2peie- is now known as sem2peie
[14:14] <oSoMoN> bdmurray, I'm working on bug #1962021, and thinking about what will happen when the firefox deb is merely a wrapper that installs the snap, and a user does `ubuntu-bug firefox`. We'd want the bug to be reported against the firefox snap, to collect all the relevant information. Is there a mechanism in apport to let a package specify that the bug should be reported against another (snap) package?
[14:14] <ubottu> Bug 1962021 in firefox (Ubuntu) "Make the deb package install the firefox snap" [High, In Progress] https://launchpad.net/bugs/1962021
=== sem2peie- is now known as sem2peie
=== sem2peie- is now known as sem2peie
[15:38] <bdmurray> oSoMoN: I'd think just seting the CrashDB section of the report would do see the subiquity package hook.
[15:38] <bdmurray> https://paste.ubuntu.com/p/p7sg8B6MSM/
[15:40] <jeroen___> Hello
[15:40] <jeroen___> I was wondering if it would be possible to upgrade nodejs-16 from debian-experimental for the release: https://packages.debian.org/experimental/libnode-dev
[15:41] <jeroen___> It seems stuck in Debian because it requires to update libicu, but ubuntu has this new icu: https://packages.ubuntu.com/jammy/libicu-dev
[15:42] <jeroen___> nodejs-12, which is currently in ubuntu, will be EOL by the time of the ubuntu-22.04 release: https://nodejs.org/en/about/releases/
[15:47] <jbicha> jeroen___: the version in experimental currently appears to be nodejs 14 (the version numbering can be confusing)
[15:47] <rbasak> jeroen___: that's a very late request - today is feature freeze. If someone wants to do it and take on any consequences they they can, but it's too much for me to take on right now, sorry. I don't know if that'd be the response from others or not though.
[15:48] <jbicha> I feel like updating to a new node version is a really big task and I wouldn't be able to help much with anything that breaks
[16:05] <oSoMoN> bdmurray, would that allow me to bypass the dialog that asks the user to choose whether to report a bug against the snap or the deb? (I just noticed that the snap appears to be selected by default, so that's something, but it would be even better to skip it altogether)
[16:06] <bdmurray> oSoMoN: I'd have to look into that
[16:44] <jeroen___> I had actually requested it before (including in this channel on December 6th) but there was no response. I assumed somebody was on it.
[16:46] <jeroen___> The experimental version in debian actually was nodejs 16 at some point, but I suppose they downgraded to 14 to keep i386 support.
[16:53] <rbasak> Sorry. Generally this kind of task turns out to be much more complicated than some people assume, and big tasks really need volunteers to do the work.
[16:54] <rbasak> I think it's probably too late now.
[16:54] <rbasak> But if an uploader steps up, then great.
[16:55] <rbasak> I'm just being the messenger here - I don't like to leave people hanging.
[16:55] <jeroen___> That's OK, I guess we can set up a PPA. I just thought i would let it know again, in case folks had not realized you are shipping an EOL version of a pretty important pkg...
[16:57] <jeroen___> Perhaps it can be put on the queue for 22.10 then?
[17:07] <lvoytek> hallyn: Before I get the swtpm apparmor profile uploaded, do you think my update for the home directory will cover your use case properly? Thanks! https://code.launchpad.net/~lvoytek/ubuntu/+source/swtpm/+git/swtpm/+merge/415813
[17:25] <rbasak> had not realized you are shipping an EOL version> that's not really a thing for a distribution. Most upstreams do not declare support periods like that. And just because an upstream sets some dates doesn't invalidate distribution's use of them beyond that date. It's been the norm before any upstreams did that.
[17:25] <rbasak> I mean ideally things would align, but as long as upstreams don't support some specific downstream distribution's release schedule, then there are always going to be cases where things mismatch.
[17:26] <rbasak> Put in whose queue? Like I said, we need volunteers. Otherwise it doesn't happen.
[17:27] <rbasak> One thing that is often unappreciated is that there are usually reverse dependencies of packages too, and they often need adjusting to work with the new version. So it's often not just a case of bumping the version of one package.
[17:38] <rbasak> So in ppp 2.4.9-1+1ubuntu3 I'm going to add some symbols
[17:38] <rbasak> The contributor has added things like this to the symbols file:
[17:38] <rbasak> + mppe_clear_keys@Base 2.4.9-1+1~
[17:38] <rbasak> + mppe_get_recv_key@Base 2.4.9-1+1~
[17:38] <rbasak> Is that right? Or should it be 2.4.9-1+1ubuntu3~ ?
[17:39] <rbasak> The only shared objects being shipped are plugins, so maybe it doesn't actually matter?
[17:41] <ahasenack> if an ubuntu patch is adding them, then the ubuntu version should be used
[17:41] <ahasenack> about it being plugins only, unsure, specially if you had a symbols file before
[17:41] <rbasak> I don't even understand why there's a symbols file :-/
[17:41] <ahasenack> yeah
[17:41] <rbasak> https://code.launchpad.net/~eivnaes/ubuntu/+source/ppp/+git/ppp/+merge/415397
[17:42] <rbasak> pppd.so.2.4.9 ppp #MINVER#
[17:42] <rbasak> But the package doesn't ship a pppd.so.2.4.9. Only plugins in /usr/lib/pppd/2.4.9/
[17:43] <xnox> rbasak:  i think the mppe_ functions are exported by pppd.so; with multiple plugins calling functions from pppd.so; in practice we ship all the plugins one can possibly need
[17:43] <ahasenack> what about the symbol removal?
[17:44] <rbasak> Yeah don't know either.
[17:44] <rbasak> xnox: what pppd.so though?
[17:44] <xnox> but in theory, one could also compile a third-party plugin against ppd.so
[17:44] <xnox> blah
[17:44] <xnox> not .so but daemon itself.
[17:44] <xnox> think of this equivalent to mod_apache modules
[17:44] <rbasak> I don't know how those work.
[17:44] <rbasak> I'm just trying to sponsor this
[17:45] <rbasak> If you understand what's going on, I'd appreciate your help in telling me it's correct, or what to adjust ;)
[17:46] <rbasak> https://paste.ubuntu.com/p/sbwkcYmtKB/
[17:46] <hallyn> lvoytek: ah, thanks.  sorry, my @ubuntu.com email is very unreliable.  will look at that today.
[17:46] <xnox> rbasak:  it looks mostly fine. I would only check any reverse build-deps of pppd to make sure they are all fine.
[17:46] <lvoytek> hallyn: Thanks!
[17:46] <hallyn> ("at that" - at the swtpm link, not my email :)
[17:46] <hallyn> thank you
[17:47] <rbasak> $ reverse-depends -b src:ppp
[17:47] <rbasak> ...
[17:47] <rbasak> httplib2.socks.HTTPError: (403, b'Forbidden')
[17:47] <rbasak> :-(
[17:51] <xnox> $ reverse-depends -b src:ppp
[17:51] <xnox> Reverse-Build-Depends
[17:51] <xnox> * connman                       (for ppp-dev)
[17:51] <xnox> * network-manager               (for ppp-dev)
[17:51] <xnox> * network-manager-fortisslvpn   (for ppp-dev)
[17:51] <xnox> * network-manager-l2tp          (for ppp-dev)
[17:52] <xnox> * network-manager-pptp          (for ppp-dev)
[17:52] <xnox> * pptpd                         (for ppp-dev)
[17:52] <rbasak> Thanks
[17:52] <xnox> * rp-pppoe                      (for ppp-dev)
[17:52] <rbasak> I had just managed to poke the same out of grep-dctrl :)
[17:52] <rbasak> What should I check in the reverse build depends?
[17:53] <xnox> i would just rebuild them against the new ppp; to see that they don't break; or like poke the .debs and see which symbols they use (if any) from ppp
[17:55] <rbasak> OK I'll poke them into a PPA. Thanks!
[17:59] <jbicha> hi, I would have expected gnome-shell-extension-appindicator to have autosynced from Debian by now. Is there an issue with the Debian importer?
[18:15] <bdmurray> jbicha: I see the same version in Ubuntu here https://launchpad.net/debian/+source/gnome-shell-extension-appindicator
[18:20] <jbicha> right, we stopped getting Debian imports earlier today https://people.canonical.com/~ubuntu-archive/auto-sync/2022-02-24/
[20:13] <ddstreet> bdmurray can you clarify if FF has already happened, or if this is the final day before FF?  i.e. is jammy FF yet or not?
[20:13] <ahasenack> it's still open, but today is FF, in a few hors
[20:13] <ahasenack> the #ubuntu-release topic has the info
[20:14] <ddstreet> thanks!
[20:18] <bdmurray> ddstreet: events like FF usually happen around EoD in the Pacific time zone
[20:41] <cjwatson> jbicha: Yeah, I just noticed the same thing earlier today and asked for help in ~is
[20:41] <cjwatson> There's some kind of memory exhaustion issue
[20:42] <cjwatson> Might be nice to get a final auto-sync in before FF, given that ...
[20:53] <cjwatson> OK, issue worked around for now, Debian importer running
[20:54] <cjwatson> And I think it would make sense for me to do a manual auto-sync after that, since it hasn't yet been disabled and we missed the last couple of runs
[21:11] <cjwatson> auto-syncing now
[21:18] <bdmurray> thanks
[21:25] <cjwatson> and done
[22:09] <rbasak> ppp rdeps all built successfully in my PPA so I uploaded the contribution. Thanks ahasenack and xnox for your help in reviewing.
=== genii is now known as genii-core