[01:15] <john-cabaj> What's the best way to test locally built deb packages when autotest seems to be looking to pull dependencies from the archive? For example, the package I'm working on generates 15 deb packages. I install them all successfully, but autotest then complains that packages are depending on archive versions rather than my local binaries. I can comment out all /etc/apt/sources, but there are some packages in the archiv
[01:16] <john-cabaj> Hopefully that makes sense
[01:16] <sarnold> john-cabaj: hey :) irc has line length limits, and your message looks like it was cut off at "packages in the archiv"
[01:16] <john-cabaj> Yep. Wasn't sure if that's my client or IRC more generally.
[01:16] <john-cabaj> I can comment out all /etc/apt/sources, but there are some packages in the archive that I do need*
[01:17] <sarnold> heh, it's never very much ..
[01:17] <sarnold> most clients will split long messages into multiple messages to avoid the problems, but not all do :(
[01:17] <zhsj> john-cabaj: bump the package version for your local built?
[01:18] <john-cabaj> zhsj: It's been bumped as part of the manual package sync
[01:18] <john-cabaj> New upstream version
[01:19] <john-cabaj> "Depends: libnvpair3linux (= 2.2.2-0ubuntu8) but 2.2.3-1ubuntu1 is to be installed"
[01:19] <john-cabaj> 2.2.3 is new and installed from a local deb, 2.2.2 is in the archive
[01:20] <zhsj> probably some packages want the old version?
[01:22] <john-cabaj> zhsj: debian/control has "libnvpair3linux (= ${binary:Version})" for the dependency, which I think calls for the same version as was built
[01:23] <sarnold> rebuild that package, locally, too?
[01:24] <john-cabaj> sarnold: It was built with the rest of the source, and also installed
[01:24] <sarnold> john-cabaj: oh *weird*, I figured this was coming via a binary built from a different source
[01:25] <john-cabaj> All deb packages were built from sbuild and chroot. All debs copied to a vanilla LXD instance to test via autotest.
[01:26] <john-cabaj> Agh, not emojis..
[01:26] <john-cabaj> "L X D" instance
[01:28] <sarnold> no worries there, an actual L and X and D came through for us :)
[02:16] <john-cabaj> I think what might be happening is autotest tears down the packages. Then when I try to run a new test, it attempts to re-install, but autotest knows nothing about my local debs.
[02:24] <sarnold> ohhhhhhh
[02:52] <mwhudson> uh what's going on with the src:lxc t64 transition
[03:04] <mwhudson> stgraber: looks like the liblxc1 -> liblxc1t64 transition never made it to ubuntu?
[03:32] <stgraber> mwhudson: yeah, not sure what's going on there. I've made it clear to Aleksandr that at this point I'm not willing to sponsor anything in Ubuntu if the change isn't in Debian first (salsa at least) so I think he had juliank sponsor the most recent change which was just to make it pass adt. If it had been re-synced with Debian instead, it would have gotten the t64 change as part of it.
[03:57] <mwhudson> stgraber: this change was in debian too! but as an nmu so i guess it didn't get caught up in the merge. i've uploaded the rename to ubuntu now anyway
[03:58] <mwhudson> ok i definitely lost the builder lottery on https://launchpad.net/~canonical-foundations/+archive/ubuntu/archive-bootstrap/+build/28113758
[08:18] <cgmb> Could an AA please give the rocm arm64 removals a second look?
[08:18] <cgmb> https://bugs.launchpad.net/ubuntu/+source/stdgpu/+bug/2061048
[08:18] -ubottu:#ubuntu-devel- Launchpad bug 2061048 in stdgpu (Ubuntu) "Please RM arm64 binaries" [Undecided, New]
[08:19] <cgmb> ROCm RDNA 3 support is blocked by that bug. :(
[08:22] <cgmb> HIP RTC is also broken and fixes are blocked by the FUBAR arm64 builds.
=== dviererbe1 is now known as dviererbe
[09:20] <sudip> what is the process to request a rebuild? open a bug report requesting rebuild ?
[09:47] <seb128> sudip, rebuild of?
[09:47] <sudip> seb128: rebuild for bind-dyndb-ldap, it still depends on old bind9-libs but noble-proposed has new version
[10:19] <LocutusOfBorg> cgmb, maybe highlight ubuntu-archive
[10:23] <seb128> sudip, I've uploaded a no-change rebuild now
[10:23] <sudip> thanks seb128
[10:23] <seb128> np!
[10:33] <sudip> also, I have raised LP: #2061612 and added ubuntu-archive to it, do I need to add sponsors also?
[10:33] -ubottu:#ubuntu-devel- Launchpad bug 2061612 in yforth (Ubuntu) "please remove yforth from Noble" [Undecided, New] https://launchpad.net/bugs/2061612
[10:39] <seb128> sudip, no need of sponsor, removed
[10:39] <sudip> great, thanks (again) seb128
[10:39] <seb128> np! :)
[15:04] <athos> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Post-Beta Freeze | Devel of Ubuntu (not support) | packages with removed amd64 binaries that need resolving: https://pad.riseup.net/p/migrate-list-amd64 | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: athos
[15:07] <rbasak> adrien, slyon: need any help with libtracefs?
[15:07] <slyon> rbasak: I'm about to review & sponsor it
[15:07] <rbasak> Perfect. Thanks!
[15:17] <athos> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Post-Beta Freeze | Devel of Ubuntu (not support) | packages with removed amd64 binaries that need resolving: https://pad.riseup.net/p/migrate-list-amd64 | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: N/A
[15:18] <athos> postponing my shift to next week ^ - will work on other noble tasks :)
[15:55] <joelkraehemann> hi all
[15:55] <joelkraehemann> https://gitlab.gnome.org/GNOME/gtk/-/issues/6632
[15:55] -ubottu:#ubuntu-devel- Issue 6632 in GNOME/gtk "crash with GtkSingleSelection in snap sandbox environment and custom file widget" [Opened]
[15:57] <liushuyu> Proper fix for the rust-glib-sys: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/rust-glib-sys/+git/rust-glib-sys/+merge/464548
[15:58] <liushuyu> The patches are based on the patches that I submitted to the upstream (merged today)
[16:17] <liushuyu> Forwarded to Debian as https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/650
[16:17] -ubottu:#ubuntu-devel- Merge 650 in rust-team/debcargo-conf "glib-sys: replace the patches with improved patches" [Opened]
[16:19] <seb128> liushuyu, thanks, sponsored
[16:20] <liushuyu> seb128: Thanks!
[16:56] <joelkraehemann> my snap is affected by this bug
[16:56] <joelkraehemann> https://snapcraft.io/gsequencer-6
[17:02] <seb128> if you want a fix cherrypicked to the sdk the right place to request it is https://github.com/ubuntu/gnome-sdk/issues/
[17:03] <joelkraehemann> great
[17:03] <liushuyu> joelkraehemann: I am guessing this is due to this particular file widget does not work well when being sandboxed and have limited filesystem access. When inside a sandbox, the developer is expected to use XDP protocol to request file access through the sandbox management system
[17:08] <joelkraehemann> https://github.com/ubuntu/gnome-sdk/issues/201
[17:08] -ubottu:#ubuntu-devel- Issue 201 in ubuntu/gnome-sdk "add fixes for GtkSingleSelection" [Open]
[17:09] <joelkraehemann> no the bug is in the GtkSingleSelection code
[17:09] <joelkraehemann> gtk-4 provides only rudimentary file dialog
[17:09] <joelkraehemann> you need to implement your own file dialog.
[17:10] <joelkraehemann> further GtkFileChooserDialog is deprecated
[17:10] <liushuyu> Ah I see
[17:10] <joelkraehemann> :-)
[17:11] <joelkraehemann> https://launchpad.net/~jkraehemann/+snap/snapcraft-gsequencer-6-c0bdfecd426dfd246367a92f6770ae22
[17:11] <liushuyu> Many GUI toolkits have transparent handling of this issue, maybe GTK isn't one of them
[17:12] <joelkraehemann> I don't know much about other but for Gtk I am your man
[17:12] <joelkraehemann> I am using it for 22 years now
[17:14] <joelkraehemann> https://www.nongnu.org/gsequencer/docs/AgsGui-6.0/class.FileWidget.html
[17:14] <liushuyu> joelkraehemann: I see. You then must have known GTK inside-out then
[17:14] <joelkraehemann> not really, more from the outside
[17:14] <joelkraehemann> since gtk2
[17:15] <joelkraehemann> gnome 2 is my favorite desktop
[17:15] <joelkraehemann> this is why I am using mate desktop
[17:15] <liushuyu> ... still, for applications that have "strict" confinement without any explicit filesystem access, the applications have to ask the sandbox for permissions to access a certain path
[17:16] <joelkraehemann> this version checks permissions
[17:16] <liushuyu> okay
[17:17] <joelkraehemann> and has support for sandboxed paths
[17:17] <joelkraehemann> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/app/ags_app_action_util.c?h=6.8.x#n128
[17:17] <joelkraehemann> actually 3 different types of sandbox
[17:17] <joelkraehemann> snap, flatpak and macos
[17:19] <joelkraehemann> and locations are added by XDG_*_DIR environment variables
[17:19] <joelkraehemann> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/widget/ags_file_widget.c?h=6.8.x#n2050
[17:19] <liushuyu> I see. Even Windows has a sandboxed runtime (UWP) now
[17:19] <joelkraehemann> I prefer do distribute as zip file
[17:20] <joelkraehemann> extract and run
[17:21] <joelkraehemann> but is worthy to consider, thank you
[17:21] <liushuyu> sounds like the most common distribution method
[17:21] <liushuyu> joelkraehemann: That's just a mention, using UWP requires you to publish your app onto Microsoft Store (which is a paid service)
[17:21] <joelkraehemann> yeah there are different installers
[17:22] <liushuyu> (people usually avoids that, since you have to pay US$99 to do that)
[17:22] <joelkraehemann> like for macos
[17:23] <liushuyu> joelkraehemann: yes, but iirc this is a one-time fee, instead of yearly like macOS does)
[17:24] <joelkraehemann> now you can verify the crash
[17:24] <joelkraehemann> https://snapcraft.io/gsequencer-6
[17:24] <joelkraehemann> I just update the software using new AgsFileWidget
[17:26] <liushuyu> is this normal? /snap/gsequencer-6/21/gnome-platform/usr/lib/x86_64-linux-gnu/gtk-4.0/4.0.0/media/libmedia-gstreamer.so: undefined symbol: gdk_gl_texture_builder_set_width
[17:27] <joelkraehemann> happened to me too
[17:27] <liushuyu> Okay, yes, it also crashes for me
[17:27] <joelkraehemann> the file dialog?
[17:27] <liushuyu> The file dialog, when navigate to the / path, it crashes
[17:27] <joelkraehemann> exactly
[17:28] <joelkraehemann> this is due to missing fixes
[17:28] <joelkraehemann> gtk4 access death widgets
[17:31] <liushuyu> seb128: also, is it expected that gnome-sdk only supports amd64/arm64/armhf targets? I thought we have other targets like riscv64/s390x/ppc64el
[17:36] <liushuyu> joelkraehemann: oh and also "snap "gsequencer-6" has bad plugs or slots: content (content plug must contain target path)"
[17:41] <joelkraehemann> ok
[17:41] <joelkraehemann> one moment
[17:42] <joelkraehemann> the content plug was new, when I wrote the snapcraft.yaml first
[17:42] <joelkraehemann> not fully implemented
[17:42] <joelkraehemann> I am going to fix this
[17:44] <joelkraehemann> icon-theme uses content plug
[17:45] <joelkraehemann> check XDG_DATA_DIRS
[17:45] <joelkraehemann> liushuyu: can you check my build-packages
[17:46] <joelkraehemann> do I need to install libgtk-4-1
[17:46] <joelkraehemann> or is it provided by core22
[17:46] <joelkraehemann> ?
[17:47] <joelkraehemann> I could expose `midi2xml` binary
[17:53] <liushuyu> joelkraehemann: gnome-sdk should have provided all the GTK related development files
[17:54] <liushuyu> as long as you have the "gnome" extension defined, you should be fine
[18:05] <joelkraehemann> I have removed libgtk-4-1
[18:06] <joelkraehemann> https://bazaar.launchpad.net/~jkraehemann/+junk/gsequencer-6/revision/15
[19:10] <dannf> liushuyu: hi! so I'm trying to figure out what the rationale is for pulling in new rustc upstreams in jammy - I don't see an SRU special case, and the bug closure just looks like "new upstream, backport to jammy" - do you have more info there?
[19:14] <liushuyu> dannf: Rust toolchains are now required by Firefox and Chromium builds, which usually are security updates. Newer Firefox and Chromium often require very new Rust toolchains, so Rust toolchains are uploading as security backports
[19:16] <dannf> ah, I see! are there any guarantees we make to users of those packages wrt backwards compatibility? like does upstream guarantee certain things are true for the versiosn we pull in, or are there things we test for?
[19:17] <dannf> i'm working with someone who is trying to decide if they should follow rustc in Ubuntu or do "something else"
[19:20] <liushuyu> dannf: Unless you are using unstable features (nightly features), Rust toolchains are very stable regarding APIs. You can even compile Rust code from 2015 using current Rust toolchains (you will get a lot of warnings, but still builds)...
[19:20] <liushuyu> ...  Rust upstream does "crater tests" to ensure the compatibility. "crater test" not only test very popular libraries, but it also tests all the libraries on crates.io and all known libraries on GitHub/GitLab that do not publish on crates.io.
[19:20] <liushuyu> One crater run usually takes a month to complete
[19:21] <dannf> great, that helps. thanks @liushuyu !
[19:23] <liushuyu> dannf: You're welcome! Another point is that the in-archive Rust toolchain is not meant for end-user consumption due to our distribution toolchain does not have all the tools/features enabled. The developers looking to build cross-platform Rust applications are still encouraged to use upstream toolchains
[19:26] <dannf> liushuyu: also good to know!
=== JanC is now known as Guest4570
[20:10] <dannf> liushuyu: and what's the deal w/ rustc-1.62 in jammy-updates?
[20:11] <liushuyu> dannf: This was for Linux kernel experiment. Linux kernel now allows Rust modules, but Linux kernel requires very specific version of the Rust toolchain due to using Rust internal stuff
[20:13] <dannf> Is that expected to remain at 1.62 for the support life of jammy, or is that subject to bumps (e.g. w/ HWE kernels)?
[20:14] <liushuyu> dannf: It depends. If the requirements change, then we will also move the target. You can also see there is rustc-1.74 package in Noble
[20:14] <dannf> gotcha, thanks again!
[20:14] <liushuyu> This depends on which Rust version that Linux kernel requires
[22:40] <tertitten> Is there a way to remove the new installer and simply use ubiquity instead? this is for a respin of ubuntu.
[22:42] <jbicha> you would need to build the ISO completely differently to use ubiquity
[22:43] <tertitten> jbicha: I'm kinda already building it quite differently :)
[22:44] <sarnold> or grab the usual ubuntu image and then apt install metapackages and packages by hand -- it wouldn't be exactly like the other flavor but it'd be close
[22:47] <tertitten> Well, I use cubic to build my image, it was a breeze on 23.10, even ubiquity was smoth as far as debranding and own slides goes, however the new installer won't even run properly, the gui dissapairs and seemingly the installation stops, but nope, it's still running and suddenly it's done even though the new installer is nowhere to be seen
[22:53] <sarnold> hah, then you've got something much more interesting going on
[22:53] <sarnold> one of the flavors moved to calamares for reasons I never understood; it might be worth looking to see if you could do the same?
[23:12] <tertitten> sarnold: Yeah, I fear I do have some other problems, I will try again, I read somewhere that ubuntu studio (i believe it was) had similar problems early when using the installer, I'll look into that
[23:13] <Eickmeyer> Ubuntu Studio uses the new installer and it works wonderfully.
[23:15] <Eickmeyer> tertitten: Where the new installer is present, the .iso image uses a "layered" squashfs, which isn't a traditional squashfs that cubic can use, so you're going to run into roadblocks.
[23:16] <Eickmeyer> Sadly, it's nothing we can support here, so you're going to have to contact the cubic developer.
[23:25] <tertitten> Eickmeyer: I am aware of that, and it's the new installer I have problems with, and I am pretty sure that the problems I have is the same as they had, only now I can't seem to find it again. anyway, thanks for input guys
[23:26] <Eickmeyer> tertitten: I'm the lead on Ubuntu Studio, and I'm quite positive that if you're building with cubic (as we do not), it's not.
[23:29] <tertitten> Eickmeyer: strange, mayby
[23:29] <tertitten> ups
[23:29] <tertitten> check here: https://discourse.ubuntu.com/t/help-with-ubuntu-studio-system-installer/41682/4
[23:30] <Eickmeyer> tertitten: I'm the very person who wrote that, and you're not having the same issue. We use Canonical's infrastructure to build our .iso's, not cubic, and not manually.
[23:32] <tertitten> Eickmeyer: OK, i'm sure you are correct, however the debug you pasted in is the same as the ones I where seeing under installation with the new installer.
[23:33] <Eickmeyer> tertitten: At the time, we were using a completely different installer base, not what's being used now, so the entire thing is moot.
[23:34] <Eickmeyer> tertitten: Probably because flutter tends to look the same. But what you're likely seeing is due to cubic's inability to create layered squashfs images.