=== dviererbe1 is now known as dviererbe
=== nnmwxqlrjfvropmn is now known as tozbizcuiihbmdyn
=== tozbizcuiihbmdyn is now known as georgiag
=== JanC is now known as Guest7955
=== guiverc2 is now known as guiverc
=== JanC is now known as Guest4504
=== dviererbe1 is now known as dviererbe
[08:50] <schopin> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Oracular | Patch Pilots: schopin
[09:05] <adrien> Can someone look at https://code.launchpad.net/~adrien/ubuntu/+source/adios2/+git/adios2/+merge/477906 ? I think it is needed for the openmpi transition. Thanks. :)
[09:27] <enyc> Hrrm;  wonder what I should read, which MOTU maintainer or process best approached.
[09:28] <enyc> https://sourceforge.net/p/gscan2pdf/bugs/430/  <- very easy fix in universe 'gscan2pdf' package in ubuntu 24.04LTS needs patching-in ,  not really a backport / whole version
[09:28] -ubottu:#ubuntu-devel- sourceforge.net/p/gscan2pdf/bugs 430 "gscan2pdf not running under Linux Mint 22beta" [Pri: 5, Closed: Fixed]
[09:28] <enyc> confusingly, it affects whomever has an  /etc/upstream-release/  e.g.  unofficial ubuntu variants  but it is really a gscan2pdf bug (fixed) in the ubuntu package
[09:29] <enyc> just needs few line change put into   ubuntu universe package by a MOTU maintainer  so LTS works properly with  the many derivatives  where  /etc/upstream-release/ directory exists
[09:30] <enyc> I should say (fixed upstream)
[09:30] <schopin> enyc: is it fixed in Plucky and Oracular?
[09:31] <schopin> If you feel like it I can actually walk you through the entire process and sponsor an upload for you :)
[09:37] <enyc> schopin: confirmed the patched code is already in  gscan2pdf  Plucky version 2.13.4-4;  noble has 2.13.2-1
[09:37] <enyc> went through deb-src and got the source loaded etc
[09:38] <enyc> schopin: I greatly appreciate your offer; but also wary I shortly need to be hurriedly connecting heating pipes and repairing outside lights and other backlogged irl tasks!
[09:38] <enyc> schopin: I have no doubt this would be instructive, in short; either, can you do this, or; can you guide me another day ?
[09:40] <schopin> Well, right now I'm the current Patch Pilot, which means it's my job for the next few hours to do the guiding and sponsoring (rather than doing the actual work. We don't *always* have a patch pilot on duty but we try to.
[09:41] <schopin> The point of this *is* to be instructive ;)
[09:41] <enyc> schopin: schedule?  here similar time tomorrow?  etc
[09:43] <schopin> I don't think the schedule is publically available, but I do know that bdrung will be on shift tomorrow around noon UTC (1PM CET) and would be happy to help you and/or pick up where we leave off.
[09:46] <schopin> Oh, the schedule is somewhat available, if not very helpful: https://calendar.google.com/calendar/u/0/embed?showPrint=0&showCalendars=0&mode=WEEK&src=Y184ZWRhZjk2OTllYWFmMWFmMmNjYTY2ZTYyOGZkNDEwODQ2ZTkwMjcwNmQ2YTMzMTU1OTNmODhiOTk0ZTZlOWE2QGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20&color=%23F4511E (from https://discourse.ubuntu.com/t/ubuntu-patch-pilots/37705 )
[10:58] <gjolly> hi there, where can I find a [good] documentation on how to run autopkgtest?
[11:00] <Skia> gjolly: you mean locally, or in the infra?
[11:00] <gjolly> Skia: locally
[11:01] <Skia> in any case, a not too bad start is there: https://wiki.ubuntu.com/ProposedMigration#autopkgtests
[11:01] <Skia> otherwise, `man autopkgtest`, and `man autopkgtest-virt-*`
[11:03] <Skia> `zless /usr/share/doc/autopkgtest/README.running-tests.rst.gz` is not too bad also
[11:03] <Skia> and for Ubuntu, there is the `autopkgtest-buildvm-ubuntu-cloud` that is very handy with the `qemu` virt-server
[11:08] <gjolly> Skia: thanks! I think everything I'm looking for is in /usr/share/doc/autopkgtest actually.
[11:10] <Skia> gjolly: nice! This folder just seems to miss mentionning `autopkgtest-buildvm-ubuntu-cloud`, but otherwise should be great
[11:15] <gjolly> Skia: I will check what these `autopkgtest-virt-*` do because I would love to have something like `autopkgtest-virt-azure`
[11:18] <Skia> oh, I see. Then you might want to study how we do in production with OpenStack: in autopkgtest src code, we have `ssh-setup/nova`, that is used in combination with the `ssh` virt-server. You can find the full command line at the top of the logs in autopkgtest.u.c. This `nova` script will spawn the VM, check for SSH access, and then hand back to autopkgtest. It's also responsible for destroying the VM
[11:18] <Skia> and a few other things. I guess that would be a good start to be adapted for `azure`.
[11:19] <Skia> there is even a `ssh-setup/SKELETON` file, that gives the boilerplate to implement such thing
[11:19] <jamespage> doko: could you take a look at bug 2091540 for me - I think there might be a problem with error handling between Python and openssl for the new version of openssl in proposed
[11:20] -ubottu:#ubuntu-devel- Bug 2091540 in python-eventlet (Ubuntu) "ssl test failures with openssl >= 3.4.0" [Undecided, New] https://launchpad.net/bugs/2091540
[11:20] <jamespage> but I may be wrong
[11:20] <Skia> gjolly: https://salsa.debian.org/ci-team/autopkgtest/-/tree/master/ssh-setup
[11:22] <Skia> given that there is already `nova` and `maas` upstream, I guess an `azure` script could likely make its way to the repo, but paride would be better placed to answer that
[11:24] <Skia> you would end-up with a command line looking like this: `autopkgtest ... -- ssh -s azure -- azure_arg1=value ...`
[11:26] <gjolly> Skia: that would be great. Thank you very much for your help. I have a lot of things to read and a few things to try now.
[11:26] <Skia> sure, come back any time if you need further guidance. We don't know azure at all in the team, but it's conceptually the same thing that's running in production on OpenStack.
=== gurupras- is now known as guruprasad
[13:25] <paride> gjolly, hi, this is not the first time an idea likes that comes up, see https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/210
[13:25] -ubottu:#ubuntu-devel- Merge 210 in ci-team/autopkgtest "Add ssh-setup/ec2" [Opened]
[13:25] <paride> gjolly, that's for aws of course
[13:30] <paride> gjolly, as you can see there, there are two concern points: (1) who owns the new functionality? this is something we can define in some sensible way I believe, I don't see it being a blocker. (2) that comment about "a reorganization of the logic in autopkgtest". afaik that idea didn't go far yet, but has not been abandoned, so it's something to
[13:30] <paride> keep in mind
[13:31] <paride> gjolly, also: we'd need something like autopkgtest-build-azure, to prepare azure images to be used as testbeds
[13:32] <paride> toabctl, ^^ that's your MR I mentioned
[13:33] <gjolly> AH I shouldn't be surprised that toabctl tried to do that with AWS already
[13:58] <toabctl> paride, wouldn't it be possible to just use the default ubuntu images on aws or azure and use cloud-init for whatever is required to prepare the testbed? or is there something special required?
[14:41] <adrien> Can someone retry https://launchpad.net/ubuntu/+source/paraview/5.13.1+dfsg-9build2 ? I don't know if it's going to work but I think it's worth a try, thanks. :)
[14:46] <mirespace> ahasenack (or any other sru member if around), when around:  I have been asked for an estimation of when walinuxagent would be SRUprocessed... sorry for the direct ping, and thankyou
[14:57] <mfo> adrien, I retried the failed builds for arm64/armhf/riscv64.
[14:58] <paride> toabctl, well, it should be doable. having a dedicated image is of course going to be faster is you want to run many tests, but it's also a chore to maintain
[14:58] <paride> toabctl, the setup we do on autopkgtest images is basically: https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/setup-commands/setup-testbed?ref_type=heads
[14:58] <paride> which is mostly about minimization
[14:59] <paride> toabctl, autopkgtest-buildvm-ubuntu cloud already uses cloud-init to prepare the image: https://salsa.debian.org/ci-team/autopkgtest/-/blob/a1af98e6106f395372e459bfee936172205ff3f5/tools/autopkgtest-buildvm-ubuntu-cloud#L319
[15:02] <adrien> mfo: thanks! :)
[15:17] <schopin> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Oracular | Patch Pilots: N/A
[18:01] <enr0n> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Oracular | Patch Pilots: enr0n
[18:02] <cpaelzer> enr0n: to Hawaii please then
[18:03] <enr0n> works for me!
[18:12] <ahasenack> juliank: hi, https://ubuntu-archive-team.ubuntu.com/proposed-migration/noble/update_excuses.html#packagekit says packagekit depends on apt also "migrating", but I think that does not apply here in noble, am I right?
[18:13] <ahasenack> no soname change, and I just tested installing new packagekit from noble-proposed without updating apt, seems to work fine
[18:19] <ahasenack> and the test case would have caught something, all good I think
[18:19] <ahasenack> releasing
[18:58] <juliank> ahasenack: it does apply *on armhf*, because the dependencies are broken due to t64 changes in apt
[19:00] <juliank> Nobody noticed before the release, I forgot to put a fixed symbols file into the latest unapproved SRU too
[19:00] <juliank> Or it might be older than the last time this happened
[19:03] <juliank> The C++ mangling changed due to long long long
[19:04] <juliank> I need to push another SRU out on top of the current one with more apt-ftparchive fixes for launchpad, so I can remember updating the symbols file for it and back versioning the symbols it accordingly
[19:06] <juliank> This also affects oracular of course, and plucky still
[19:06] <juliank> The plan for plucky is to bump the soname in January
=== mfo_ is now known as mfo