[04:04] <michel> hello! should I ask about keyserver issues here or in #ubuntu ? (it's been over 20 mins since I upload, and on the terminal I can --recv-keys fine, but on the keyserver web UI it claims my key is not found and launchpad won't import it either)
[04:05] <michel> and... of course it works now
[04:07] <Unit193> ...So I guess neither! :>
[04:09] <JanC> for infrastructure issues #canonical-sysadmin is usually best; or for Launchpad-specific stuff there is #launchpad
[04:12] <mwhudson> complaining about where your upload has gone is always a good way to get it accepted immediately, in my experience
[09:57] <LinuxAspy> The 'anbox' package is broken and needs to be removed from Ubuntu 20.04 LTS's repo. It depends on kernel modules which are not included in Ubuntu or the repo.
[09:57] <ogra> it doesnt
[09:57] <LinuxAspy> It doesn't want?
[09:57] <LinuxAspy> *what
[09:58] <ogra> it does not depend on modules that are not included
[09:58] <LinuxAspy> ogra, not according to Anbox. It failed to start because of missing binder and ashmem modules, which are missing.
[09:59] <ogra> please read the anbox docs and if there is something wrong, please talk to the anbox support (like i told you multiple times now in #ubuntu)
[09:59] <LinuxAspy> ogra, you don't know what you are talking about.
[09:59] <ogra> they are in the kernel package
[09:59] <LinuxAspy> Anbox reports the modules are missing.
[09:59] <LinuxAspy> ogra you told me they are not included.
[09:59] <ogra> so follw the instructions
[09:59] <ogra> i did not
[10:00] <ogra> please talk to the anbox support and follow the docs
[10:00] <LinuxAspy> I searched the repo for binder and ashmem, they are not in there.
[10:00] <ogra> LinuxAspy, please ...
[10:00] <LinuxAspy> ogra just block me if you have a problem. You are starting to do my head in.
[10:02] <ogra> LinuxAspy, https://anbox.io/ scroll down to the "get in touch" section, go to the telegram group that points to
[10:02] <LinuxAspy> The problem is not Anbox, it is Ubuntu.
[10:03] <LinuxAspy> If a user goes to the official app store and installs Anbox, it doesn't work. That is a clear problem for Ubuntu's experience.
[10:03] <ogra> LinuxAspy, this is not a suppport channel
[10:03] <LinuxAspy> ogra you are the one arguing about the semantics. lol geez
[10:03] <LinuxAspy> I have not asked for help with Anbox here.
[10:03] <ogra> LinuxAspy, the modules are included in the ubuntu kernel, the anbox guys know how to load them and use them with anbox
[10:04] <LinuxAspy> I am reporting a quality control problem with Ubuntu.
[10:04] <LinuxAspy> Every app in the app store should work, we have one that doesn't. That's a bad Ubuntu experience.
[10:04] <LinuxAspy> The problem is straight out of the box.
[10:05] <ogra> no, you are refusing to use the correct support place for software from multiverse despite having been pointed to the right support place several times in multiple ubuntu channels
[10:05] <ogra> anbox requires special setup that the anbox support will help you with
[10:05] <LinuxAspy> ogra, we are going around in loops. You are talking about my problem, I am talking about a bad Ubuntu user experience. I can't talk about it anymore. Its draining too much of my energy.
[10:06] <ogra> LinuxAspy, just follow the advise you got a few times now
[10:06] <ogra> this is neither a support channel nor a "complain about ubuntu" channel
[10:07] <LinuxAspy> ogra only you are complaining. I am discussing ways to improve Ubuntu.
[10:07] <LinuxAspy> As I said, we have an app in the app store that does not work out of the box. This is a quality control problem and I think it should be fixed. Ubuntu is the most popular distro and gains the most vendor support for this reason.
[10:08] <ogra> no, you are refusing to follow the setup procedure of a third party software and blame ubuntu
[10:08] <LinuxAspy> The Ubuntu app store is not third party.
[10:08] <LinuxAspy> It was made by Canonical, for Ubuntu.
[10:08] <ogra> please stop it, please go to the anbox support, they help people setting up anbox on ubuntu every day
[10:08] <LinuxAspy> ogra anbox are not the developers of Ubuntu's app store.
[10:09] <ogra> no and the developers of ubuntu app store do not maintain every package this store shows
[10:09] <LinuxAspy> And it is my opinion that every app in the Ubuntu Software app store should work out of the box, and I am here to suggest that.
[10:10] <LinuxAspy> It is a matter of quality control.
[10:10] <LinuxAspy> The Ubuntu Software app is a feature of Ubuntu. A bad end result from a broken app reflects bad on Ubuntu.
[10:11] <LinuxAspy> Does anyone else agree with me?
[10:11] <ogra> if you think there is a bug, the right way of making developers aware is to file it on launchpad, not jumping around screaming in their workplace ...
[10:11] <Unit193> snaps are made by third parties as far as I am aware, there's no way to test for every possible installable snap.  Also, it doesn't really make sense to load all possible modules, for example I won't ever use the android development ones.  You have to realize that some things may require you to...actually do yourself.
[10:11] <LinuxAspy> ogra, you are the one who brought the conflict here, not me. I came here simply to discuss the problem.
[10:11] <ogra> especiaally if you just use that workplace as a fallback for the support channel where you have been told the same thing over and over to get the correct instructions and help
[10:12] <LinuxAspy> Unit193 there is a way to test them. In this case, the app fails to load. That is an obvious problem that can be detected through a quality control process.
[10:13] <LinuxAspy> Unit193 the user should never have to do heavy lifting. That is a poor user experience. Its why people love Windows more than anything. Ubuntu should embrace that engineering in my opinion.
[10:13] <ogra> LinuxAspy, and this is not a channel to discuss this
[10:14] <Unit193> LinuxAspy: Then, go to the publisher of the snap and report such issues, see https://github.com/anbox/anbox/issues/new perhaps.
[10:14] <LinuxAspy> ogra please stop harassing me.
[10:14] <ogra> LinuxAspy, feel fre to go to #ubuntu-offtopic or #ubuntu-discuss ...
[10:15] <LinuxAspy> Unit193 the app I am talking about is Ubuntu Software centre.
[10:15] <ogra> LinuxAspy, so file a bug then
[10:16] <LinuxAspy> ogra I don't have enough passion for Ubuntu to do that. I came here to simply bring the matter to peoples attention.
[10:16] <Unit193> LinuxAspy: So?  Snaps are created by their publishers, not by Ubuntu nor Canonical (though they can be.)  So, you must then go to the publisher.  Right now, it's as if you got a car, put a drink in the cup holder, then when the drink spills you complain to the car maker rather than whoever filled the cup or made the crappy cup.  You're barking up the wrong tree, here.
[10:17] <LinuxAspy> Unit yes but people install it using Ubuntu Software, so when the end result is a failure, it reflects poorly on Ubuntu.
[10:17] <Unit193> So: Talk to Anbox about that.
[10:17] <LinuxAspy> Ubuntu Software is an app that endorses these apps. Not every app in Ubuntu's repo gets listed in Ubuntu Software.
[10:18] <LinuxAspy> Unit193 anbox are not the people who endorses apps in Ubuntu Software.
[10:18] <ogra> LinuxAspy, so what do you want to achieve with the hour you spent complaining now ?
[10:19] <LinuxAspy> ogra a better Ubuntu experience, in case you hadn't realised that by now.
[10:19] <ogra> LinuxAspy, and you believe to stand in front of peoples office desks complaining will achieve that ?
[10:20] <Unit193> LinuxAspy: Perhaps "A better anbox experience" is what you should say?  Also, maybe check out https://github.com/anbox/anbox/issues/2036 - https://github.com/anbox/anbox/issues/2035 - https://github.com/anbox/anbox/issues/2034
[10:20] <LinuxAspy> Its up to Canonical now to decide if it takes onboard my suggestion of introducing a quality control process for apps listed in Ubuntu Software.
[10:20] <ogra> LinuxAspy, the time you invested in that is time you could easily have spent reproting your issue in the place developers look for issues ...
[10:20] <ogra> LinuxAspy, the place to report problems you have with the software store is at https://bugs.launchpad.net/snap-store-desktop/+filebug
[10:20] <LinuxAspy> ogra this is chat for Ubuntu developers, this is the right place.
[10:21] <ogra> LinuxAspy, do you know how to use IRC commands ?
[10:21] <LinuxAspy> ogra basic ones.
[10:21] <ogra> LinuxAspy, if so, can you try the /topic command ... and read what it says ?
[10:21] <Unit193> LinuxAspy: Whether this is the right place or not, you've now said your bit.  So no point in continuing, I'd say?
[10:21] <LinuxAspy> Unit193 do you work for Canonical?
[10:21] <ogra> 👍
[10:22] <Unit193> LinuxAspy: That doesn't actually change the answer.  But no.
[10:23] <LinuxAspy> Ok. You two need to stop arguing and resisting so much. Its really annoying.
[10:23] <ogra> phew ...
[10:23] <Unit193> Heh, ok...
[13:07] <athos> xevious: hey! Did you get the chance to take a look at that patch for #1968228? Otherwise, I can go ahead and prepare the patch and SRU here!
[13:08] <athos> LP: #1968228
[15:31] <frickler> juliank: rbasak sent me here, I have an issue with phased updates when running with a fresh image which already includes a new lib, but apt decides it isn't time yet to install the matching dev lib https://paste.opendev.org/show/bdeolr7cbwqYmdnJ4HQk/
[15:31] <juliank> frickler: it's what it is
[15:33] <juliank> frickler: like this is the opposite of https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1925745
[15:33] <juliank> frickler: this needs to be solved in launchpad, there's nothing we can do about it https://bugs.launchpad.net/launchpad/+bug/1929082
[15:34] <juliank> frickler: well
[15:34] <juliank> this is a bug in whoever built the image
[15:34] <juliank> because images should not be built with packages still phasing at <100%
[15:35] <juliank> but also there's no way to get the previous version due to the launchpad issue
[15:36] <juliank> while the phasing applies at a source package level, if you override it for a binary, it's overriden for that only
[15:36] <juliank> so you'd have to manually install libsystemd-dev=249.11-0ubuntu3.1
[15:37] <juliank> fixing this in apt is a no go because it would mean having to look up all binaries of the source package each time we look up the priority of a package which is expensive
[15:37] <juliank> I believe
[15:39] <juliank> Also I feel like the behavior here is what I want to see
[15:39] <juliank> But I don't want to ever get into the situation where I have to see it
[15:40] <frickler> in this case the old versions would still be available, because they aren't in -updates yet. but the image is build in a chroot which according to https://discourse.ubuntu.com/t/phased-updates-in-apt-in-21-04/20345 uses always-include
[15:41] <juliank> that's correct, and if you want to build images outside of the release cycle where phased updates are driven to 100% or dropped, you have to build without the flag
[15:42] <juliank> Look the chroot hack is a hack so that the builders continued working, it needs to be retired too
[15:43] <juliank> I'm not sure just allowing you to automatically install libsystemd-dev that's "not for you" is ok just because you forced "not for you" libsystemd0 into the system
[15:45] <juliank> We probably *could* do that
[15:45] <juliank> it's just slow
[15:45] <vorlon> juliank: "a bug in whoever built the image" - official daily images for LTS releases certainly do pull in packages that aren't fully phased, and the only thing we've discussed is fixing the phasing in the Packages files so we don't incorrectly list as <100% the packages that are the only version present in the image
[15:46] <vorlon> though in this case, hirsute is mentioned and we don't do daily images of hirsute...
[15:46] <juliank> It means apt woukd have to iterate over all packages in the cache to record installed (source package, source version) pairs, and then look into that when it's figuring out if it's phased
[15:46] <juliank> "overriding phasing due to other binaries from source package installed in phased version"
[15:47] <juliank> seems a crappy workaround for a problem that we should not let get users into in the first problem
[15:48] <juliank> vorlon: yeah, but you can easily see that's wrong, they haven't been phased yet and you don't know if they will be once you have the machine id
[15:48] <juliank> vorlon: hence why launchpad should keep old version and images should not include phased updates
[15:48] <juliank> such that phased updates only hit systems that they should
[15:49] <juliank> unfortunately the cache does not provide us with an index to just the installed packages
[15:50] <rbasak> this is a bug in whoever built the image> is that a cloud image issue?
[15:51] <juliank> first of all, you cannot properly build images until the launchpad issue is resolved
[15:51] <juliank> because you'd get thrown back to release pocket if the only version in updates is phased.
[15:51] <juliank> but once that feature is there, cloud images should use it
[15:52] <frickler> rbasak: in this case it is a self-build image. cloud images for jammy don't seem to get built since the release
[15:53] <juliank> so you can of course set either `APT::Get::Always-Include-Phased-Updates` or `APT::Get::Always-Exclude-Phased-Updates` when building the image
[15:54] <juliank> Also reproducible builds use always-include, they probably should just use a fixed machine-id instead
[15:54] <juliank> like all zeroes :)
[15:56] <juliank> I want to say with previous version kept in launchpad it should default to always-exclude; but arguably that can cause breakage too
[15:57] <juliank> because you promote updates (=3) from proposed to updates, and packages you build will then not be built against =3 but against previous update =2
[15:58] <frickler> yeah, in my case I would argue that in a CI environment, updates should get tested early, so always-include would be the best fit there
[15:59] <frickler> thx for the discussion anyway
[16:00] <juliank> I'm going to think a bit more about the workaround
[16:01] <juliank> piles of hacks :)
[16:01] <juliank> I don't exactly need to iterate over all packages, I can, if I version would be denied by phasing, also query by source package in the hash table, which is somewhat O(1) ish
[16:02] <juliank> then if any Version is installed and has the same SourceVersion, that should work
[16:02] <juliank> not sure if it would need some caching though
[16:03] <juliank> but I have a Private struct to cache that
[16:03] <juliank> I need 2 * number of versions bytes I think
[16:04] <juliank> ~200 kb of RAM
[16:04] <juliank> albeit I actually only need a bit, so 1/8 * number of versions, or realistically 1*number of versions
[16:05] <juliank> I don't think there is a nice variable size bitset template
[16:05] <juliank> also might be a bad tradeoff
[16:07] <juliank> vorlon: So if you have foo=2 (phasing 20%) installed, foo=1 in release, and you want to install foo-something, does that make sense that having installed foo at the "not for you" version also allows you to install all of the other binaries?
[16:07] <vorlon> hmm I think it probably does make senes
[16:10] <juliank> remind me, does new bool[size] zero initialize?
[16:11] <juliank> We can't do this for marked for install though I think, that gets too expensive, as it's dynamic vs static
[16:12] <juliank> MarkInstall("foo=1") suddenly changing the cnadidate for "foo-something" in the same Policy instance would also be slightly consufing
[16:36] <juliank> vorlon, frickler so I think this is what we might want https://paste.ubuntu.com/p/8t2XpKKhgh/
[16:36] <juliank> I'm not sure how often that code will get called
[16:36] <juliank> but it only gets called for stuff that's supposed to not be installed
[16:36] <juliank> I don't know if it works, I need to write test case for it
[19:32] <kanashiro> schopin, fyi I just uploaded ruby-net-ssh version 7.0.0~beta1 to debian with the openssl 3 fixes. Once it is synced into kinetic I'll SRU the needed changes to Jammy
[19:35] <sergiodj> kanashiro: +1
[21:32] <mwhudson> hmm it looks like the vcs-git bits of http://launchpadlibrarian.net/599717071/util-linux_2.38-4ubuntu1_source.changes didn't work?
[21:56] <dbungert> Retest click please? retry-autopkgtest-regressions -s kinetic | grep -E 'trigger=(cif-api|yaz)'