[08:42] -queuebot:#ubuntu-release- Unapproved: linux-firmware (focal-proposed/main) [1.187.27 => 1.187.28] (core, kernel)
[08:56] <LocutusOfBorg> hello, sndio and libsoundio are actually not a real transition, they have new release with bugfixes and I changed soname due to upstream changing it, but only new symbols have been added
[08:56] <LocutusOfBorg> I would like to do this transition because sndio has now a pkgconfig file and vlc is requesting it
[08:58] -queuebot:#ubuntu-release- New binary: libsoundio [i386] (jammy-proposed/universe) [2.0.0-1] (i386-whitelist)
[08:58] -queuebot:#ubuntu-release- New binary: sndio [i386] (jammy-proposed/universe) [1.8.1-1~exp2] (i386-whitelist, kubuntu)
[08:58] -queuebot:#ubuntu-release- New binary: sndio [amd64] (jammy-proposed/universe) [1.8.1-1~exp2] (i386-whitelist, kubuntu)
[08:58] -queuebot:#ubuntu-release- New binary: sndio [s390x] (jammy-proposed/universe) [1.8.1-1~exp2] (i386-whitelist, kubuntu)
[08:58] -queuebot:#ubuntu-release- New binary: libsoundio [amd64] (jammy-proposed/universe) [2.0.0-1] (i386-whitelist)
[08:58] -queuebot:#ubuntu-release- New binary: libsoundio [ppc64el] (jammy-proposed/universe) [2.0.0-1] (i386-whitelist)
[08:59] <mwhudson> huh i wonder if we should just use a flavour with more ram for the 'small' ppc64el autopkgtests
[08:59] -queuebot:#ubuntu-release- New binary: libsoundio [s390x] (jammy-proposed/universe) [2.0.0-1] (i386-whitelist)
[08:59] -queuebot:#ubuntu-release- New binary: sndio [ppc64el] (jammy-proposed/universe) [1.8.1-1~exp2] (i386-whitelist, kubuntu)
[08:59] <mwhudson> for whatever reason it's always ppc64el that's getting things killed
[08:59] -queuebot:#ubuntu-release- New binary: libsoundio [armhf] (jammy-proposed/universe) [2.0.0-1] (i386-whitelist)
[08:59] <mwhudson> current example<EMAIL_ADDRESS>[09:00] -queuebot:#ubuntu-release- New binary: libsoundio [arm64] (jammy-proposed/universe) [2.0.0-1] (i386-whitelist)
[09:00] -queuebot:#ubuntu-release- New binary: sndio [armhf] (jammy-proposed/universe) [1.8.1-1~exp2] (i386-whitelist, kubuntu)
[09:00] -queuebot:#ubuntu-release- New binary: sndio [arm64] (jammy-proposed/universe) [1.8.1-1~exp2] (i386-whitelist, kubuntu)
[09:20] -queuebot:#ubuntu-release- New binary: sndio [riscv64] (jammy-proposed/universe) [1.8.1-1~exp2] (i386-whitelist, kubuntu)
[09:22] -queuebot:#ubuntu-release- New binary: libsoundio [riscv64] (jammy-proposed/universe) [2.0.0-1] (i386-whitelist)
[09:44] <seb128> could someone give a retry to https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/jammy/ubuntu-canary ?
[09:58] <doko> Eickmeyer: the old tbb ftbfs. did you even try to rebuild the depending packages before claiming these are regressions? I don't see such uploads ...
[10:08] <juliank> sil2100: I think we should `force-reset-test gsocket/1.4.33-2` for some reason, if you look at netcat-openbsd excuses, it's not always failing, but should be
[10:09] <sil2100> juliank: yeah, it makes sense. Let me do that
[10:10] -queuebot:#ubuntu-release- New: accepted libsoundio [amd64] (jammy-proposed) [2.0.0-1]
[10:10] -queuebot:#ubuntu-release- New: accepted libsoundio [armhf] (jammy-proposed) [2.0.0-1]
[10:11] -queuebot:#ubuntu-release- New: accepted libsoundio [ppc64el] (jammy-proposed) [2.0.0-1]
[10:11] -queuebot:#ubuntu-release- New: accepted libsoundio [s390x] (jammy-proposed) [2.0.0-1]
[10:11] -queuebot:#ubuntu-release- New: accepted sndio [arm64] (jammy-proposed) [1.8.1-1~exp2]
[10:11] -queuebot:#ubuntu-release- New: accepted sndio [i386] (jammy-proposed) [1.8.1-1~exp2]
[10:11] -queuebot:#ubuntu-release- New: accepted sndio [riscv64] (jammy-proposed) [1.8.1-1~exp2]
[10:11] -queuebot:#ubuntu-release- New: accepted libsoundio [arm64] (jammy-proposed) [2.0.0-1]
[10:11] -queuebot:#ubuntu-release- New: accepted libsoundio [riscv64] (jammy-proposed) [2.0.0-1]
[10:11] -queuebot:#ubuntu-release- New: accepted sndio [armhf] (jammy-proposed) [1.8.1-1~exp2]
[10:11] -queuebot:#ubuntu-release- New: accepted sndio [s390x] (jammy-proposed) [1.8.1-1~exp2]
[10:11] -queuebot:#ubuntu-release- New: accepted libsoundio [i386] (jammy-proposed) [2.0.0-1]
[10:11] -queuebot:#ubuntu-release- New: accepted sndio [ppc64el] (jammy-proposed) [1.8.1-1~exp2]
[10:11] -queuebot:#ubuntu-release- New: accepted sndio [amd64] (jammy-proposed) [1.8.1-1~exp2]
[10:15] <sil2100> juliank: should be done now
[10:18] <seb128> sil2100, hey, could you trigger a retry on https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/jammy/ubuntu-canary ?
[10:20] <sil2100> seb128: on it o/
[10:22] <sil2100> seb128: ok, requested via the isotracker - that should work hopefully. If yes, maybe it would be good to give you the powers to do that as well
[10:29] <seb128> sil2100, thanks, and I would like to be able to retry those myself but I'm unsure how the acl are set up, I assumed it was limited to ubuntu-release
[10:30] <sil2100> seb128: I'll check, but I thought that flavor owners potentially had the ACLs to rebuild their own flavors, but maybe I'm misremembering
[10:31] <seb128> sil2100, thanks
[10:34] <sil2100> LocutusOfBorg: heey! Looking at the focal SRU of virtualbox - can you confirm that (and set the tags) that LP: #1944744 is fixed in the focal upload? Thanks!
[10:34] <sil2100> Since right now that one is unverified
[10:36] <LocutusOfBorg> I can confirm sil2100
[10:37] <LocutusOfBorg> thanks
[10:48] <sil2100> LocutusOfBorg: \o/
[11:11] <seb128> hum, why are desktop built failing on
[11:11] <seb128> * Downloading http://people.canonical.com/~ubuntu-archive/seeds/ubuntu.jammy/STRUCTURE
[11:11] <seb128> ! Could not open (any of):
[11:11] <seb128> !   http://people.canonical.com/~ubuntu-archive/seeds/ubuntu.jammy/STRUCTURE
[11:11] <seb128> ?
[11:14] -queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (focal-proposed) [0.103-0ubuntu5~20.04.6]
[11:14] <sil2100> hm, network issues? Let me check the build logs
[11:16] <sil2100> seb128: as it worked fine yesterday, I'd assume this be something with the networking on the builders? Maybe IS or the launchpad team would know more?
[11:16] <sil2100> As otherwise it all looks correct
[11:17] <RikMills> seb128, sil2100: cjwatson had a look at those fails the other week
[11:17] <RikMills> https://irclogs.ubuntu.com/2022/02/25/%23ubuntu-release.html#t18:35
[11:20] <seb128> RikMills, ah, well it's still an issue, ubuntu and ubuntu-canary failed this morning
[11:20] <seb128> and the canary retry done an hour ago also failed
[11:20] <RikMills> so did kubuntu
[11:20] <seb128> :-(
[11:23] -queuebot:#ubuntu-release- New binary: tbb [i386] (jammy-proposed/universe) [2020.3-1ubuntu1] (i386-whitelist, kubuntu)
[11:23] <sil2100> RikMills: thanks for the info o/
[11:26] -queuebot:#ubuntu-release- New binary: tbb [amd64] (jammy-proposed/universe) [2020.3-1ubuntu1] (i386-whitelist, kubuntu)
[11:27] -queuebot:#ubuntu-release- New binary: tbb [s390x] (jammy-proposed/universe) [2020.3-1ubuntu1] (i386-whitelist, kubuntu)
[11:30] -queuebot:#ubuntu-release- New binary: tbb [ppc64el] (jammy-proposed/universe) [2020.3-1ubuntu1] (i386-whitelist, kubuntu)
[11:31] -queuebot:#ubuntu-release- New binary: tbb [riscv64] (jammy-proposed/universe) [2020.3-1ubuntu1] (i386-whitelist, kubuntu)
[11:39] -queuebot:#ubuntu-release- New binary: tbb [armhf] (jammy-proposed/universe) [2020.3-1ubuntu1] (i386-whitelist, kubuntu)
[11:43] -queuebot:#ubuntu-release- New binary: tbb [arm64] (jammy-proposed/universe) [2020.3-1ubuntu1] (i386-whitelist, kubuntu)
[12:22] <xypron> Times of up to 1h for building an initrd on RISC-V are very unsatisfactory. I therefore hope for a feature freeze exception for: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958148
[12:47] -queuebot:#ubuntu-release- Unapproved: command-not-found (bionic-proposed/main) [18.04.5 => 18.04.6] (core)
[12:47] -queuebot:#ubuntu-release- Unapproved: command-not-found (focal-proposed/main) [20.04.5 => 20.04.6] (core)
[12:48] -queuebot:#ubuntu-release- Unapproved: command-not-found (impish-proposed/main) [21.10.0 => 21.10.1] (core)
[12:48] <juliank> sil2100: seems the hint did not help?
[12:49] <juliank> xypron: I think we all agreed that that change is not appropriate, and needs to be reworked to accomodate for other use cases
[12:50] <juliank> Either way it needs a feature freeze exception, so it's worth writing one
[12:51] <juliank> But please consult with waveform_ on the right compression levels, and update the mailing list thread with the findings, give some time to review
[12:52] <juliank> xypron: For details on how feature freeze exceptions work, see https://wiki.ubuntu.com/FreezeExceptionProcess
[12:52] <xypron> juliank: thanks
[12:54] <juliank> xypron: oh yes, and that requires follow up changes to image building so that images are built with zstd -19, as they are built once on fast hardware and used a lot
[12:55] <juliank> xypron: in other news, I managed to delete the gsocket test from the queue, and also uploaded a new gsocket without the flaky tests that cause the cloud hangs. https://launchpad.net/ubuntu/+source/gsocket/1.4.33-2ubuntu1
[12:57] <juliank> We really need to come up with a way to delete items in the queue reliably
[12:58] <xypron> juliank: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html still shows netcat-openbsd waiting for gsocket. But maybe that page is not yet updated.
[12:58] <juliank> atm it's run delete request in a loop, kill processes holding the item, and hope that our delete request snatches them up before another works picks it
[12:59] <juliank> xypron: As I communicated to sil2100 above, it seems our hint was not enough to get britney unstuck/realize that the test has always been failing, that's independent of the item actually being queued or not
[13:01] <juliank> xypron: Essentially britney stores which tests it has submitted, rather than looking at the queues to see which are acutally pending, and then removes tests from its store once results pop up in the autopkgtest.db
[13:15] <sil2100> juliank: oh no...
[13:29] <ricotz> Eickmeyer, hi :), are you going to push the required rebuilds for x264 transition? x264 itself requires a rebuild too for gpac
[13:31] <ricotz> https://people.canonical.com/~ubuntu-archive/transitions/html/auto-gpac.html and https://people.canonical.com/~ubuntu-archive/transitions/html/auto-x264.html
[13:31] <ricotz> LocutusOfBorg, hi :), fyi ^
[13:42] <holmanb> sil2100: if there is time today cloud-init has a queued for -proposed (22.1-14-g2e17a0d6) that we'd like to request review for upload into (bionic|focal|impish)-proposed per https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1961446
[13:42] <holmanb> Please also reject the prior unaccepted cloud-init 22.1-1 uploads that are queued for bionic, focal and impish.
[13:43] <sil2100> holmanb: hey! Let me get to it in a moment, just finishing some FFe reviews o/
[14:00] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (impish-proposed) [22.1-1-gb3d9acdd-0ubuntu1~21.10.1]
[14:02] <xypron> juliank:  will I need a feature freeze exeption if I just enable an additional architecture (riscv64 for docker.io)? Or will this be handled like a new package?
[14:03] -queuebot:#ubuntu-release- New binary: manpages-l10n [amd64] (jammy-proposed/universe) [4.13-4] (no packageset)
[14:04] <juliank> xypron: dependso n the complexity I'd say
[14:04] <juliank> like if you only need to add the architecture to a couple fields vs having to patch shared code
[14:04] <xypron> juliank: %s/arm64/arm64 riscv64/ in control
[14:05] <juliank> to me that sounds reasonable I'd say. Since we don't run autopkgtests on riscv64, there's also no chance it can hold up migrations on tested architectures
[14:07] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (impish-proposed) [22.1-14-g2e17a0d6-0ubuntu1~21.10.1]
[14:10] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (focal-proposed) [22.1-1-gb3d9acdd-0ubuntu1~20.04.1]
[14:11] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (focal-proposed) [22.1-14-g2e17a0d6-0ubuntu1~20.04.1]
[14:12] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (bionic-proposed) [22.1-1-gb3d9acdd-0ubuntu1~18.04.1]
[14:13] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [22.1-14-g2e17a0d6-0ubuntu1~18.04.1]
[14:21] <LocutusOfBorg> ricotz, ack!
[14:21] <LocutusOfBorg> as soon as I finish the current one
[14:31] <holmanb> sil2100: Perfect, thanks!
[14:33] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (impish-proposed) [2.742.4]
[14:35] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.664.40]
[14:35] <ricotz> LocutusOfBorg, thank you!
[14:38] <LocutusOfBorg> I had to patch ccextractor but its ok
[14:45] -queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (impish-proposed) [2:17.0.1-0ubuntu1]
[14:50] -queuebot:#ubuntu-release- Unapproved: accepted heat [source] (impish-proposed) [1:17.0.1-0ubuntu1]
[14:51] -queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (impish-proposed) [4:20.1.1-0ubuntu1]
[14:53] -queuebot:#ubuntu-release- Unapproved: oem-somerville-matira-5-7-meta (focal-proposed/universe) [20.04~ubuntu1 => 20.04~ubuntu2] (canonical-oem-metapackages)
[14:54] -queuebot:#ubuntu-release- Unapproved: rejected oem-somerville-matira-5-7-meta [sync] (focal-proposed) [20.04~ubuntu2]
[14:55] <sil2100> Okay, I think I'm done with SRUs for today - but if you have anything urgent, please ping me
[14:55] -queuebot:#ubuntu-release- Unapproved: accepted oem-somerville-matira-5-7-meta [source] (focal-proposed) [20.04~ubuntu2]
[15:23] <LocutusOfBorg> sil2100, you did already an awesome job :D I'm happy with it!
[15:35] <bdmurray> sil2100: I don't see an Ubuntu Canary here at all https://iso.qa.ubuntu.com/qatracker/series/73/manifest
[15:35] <bdmurray> wrt clicking a rebuild of it
[15:35] <sil2100> bdmurray: it needs adding to the manifest, guess that's one of the steps during meta to make sure the manifest == flavors we want to release
[15:36] <sil2100> Since it's in the Jammy Daily milestone
[16:05] <Eickmeyer> ricotz: I only just woke up for the morning. Looks like someone else did it? (I'm US Pacific time)
[16:12] -queuebot:#ubuntu-release- New sync: python-unicodedata2 (jammy-proposed/primary) [14.0.0+ds-8]
[16:18] <vorlon> tjaalton: LP: #1772588, I've re-removed and blacklisted all the packages for which you re-opened tasks; were those the only changes to be made here at this point?  What should be done with the remaining tasks that were still open, has Adrian taken over maintenance of these also?
[16:21] -queuebot:#ubuntu-release- New: accepted manpages-l10n [amd64] (jammy-proposed) [4.13-4]
[16:26] -queuebot:#ubuntu-release- New: accepted tbb [amd64] (jammy-proposed) [2020.3-1ubuntu1]
[16:26] -queuebot:#ubuntu-release- New: accepted tbb [armhf] (jammy-proposed) [2020.3-1ubuntu1]
[16:26] -queuebot:#ubuntu-release- New: accepted tbb [ppc64el] (jammy-proposed) [2020.3-1ubuntu1]
[16:26] -queuebot:#ubuntu-release- New: accepted tbb [s390x] (jammy-proposed) [2020.3-1ubuntu1]
[16:26] -queuebot:#ubuntu-release- New: accepted tbb [arm64] (jammy-proposed) [2020.3-1ubuntu1]
[16:26] -queuebot:#ubuntu-release- New: accepted tbb [riscv64] (jammy-proposed) [2020.3-1ubuntu1]
[16:26] -queuebot:#ubuntu-release- New: accepted tbb [i386] (jammy-proposed) [2020.3-1ubuntu1]
[16:36] -queuebot:#ubuntu-release- New binary: sdl12-compat [amd64] (jammy-proposed/universe) [1.2.52-3] (no packageset)
[16:36] -queuebot:#ubuntu-release- New binary: sdl12-compat [s390x] (jammy-proposed/universe) [1.2.52-3] (no packageset)
[16:36] -queuebot:#ubuntu-release- New binary: sdl12-compat [ppc64el] (jammy-proposed/universe) [1.2.52-3] (no packageset)
[16:38] -queuebot:#ubuntu-release- New binary: sdl12-compat [arm64] (jammy-proposed/universe) [1.2.52-3] (no packageset)
[16:38] -queuebot:#ubuntu-release- New binary: sdl12-compat [armhf] (jammy-proposed/universe) [1.2.52-3] (no packageset)
[16:38] <vorlon> LocutusOfBorg: pybind11/ppc64el added to big_packages
[16:51] -queuebot:#ubuntu-release- New binary: sdl12-compat [riscv64] (jammy-proposed/universe) [1.2.52-3] (no packageset)
[16:54] <xypron> Could one of the archive admins, please, state if we need a feature freeze exception for https://github.com/tianon/debian-docker/pull/17 , LP #1963920. It adds a new binary package for the riscv64 architecture which was previously no supported. https://wiki.ubuntu.com/FreezeExceptionProcess only talks about new source packages. kanashiro was not sure how to interprete this.
[16:55] <xypron> bdmurray:  ^
[16:57] <vorlon> xypron: FFe is a question for Ubuntu Release, not archive admins, these are two separate teams :)
[16:57] <kanashiro> from my understanding we do not need a FFe but we need to coordinate with a AA the upload
[16:57] <vorlon> xypron: and no you definitely do not need a FFe for adding an architecture to the list in debian/control
[16:58] <vorlon> kanashiro: I'm pretty sure that if the binary already exists, adding it to a new arch does not get caught in binary NEW.  But even if it did this is trivial
[16:59] <xypron> Thanks vorlon for the clarification.
[16:59] <kanashiro> vorlon, ok, so I am going ahead with the upload
[16:59] <vorlon> yes please
[16:59] <kanashiro> thanks for asking here xypron :)
[17:07] <xnox> yeap, all that.
[17:08] <xnox> normally things are good these days, that uploading stuff gets correctly accepted; or stuck in a relevant queue.
[17:08] <xnox> thus one can just upload.
[17:08] <xnox> and we have ways to make things stuck in -proposed (which didn't use to exist)
[17:10] <kanashiro> when I am in doubt I prefer to ask to avoid any mess, this was the first time I faced a situation like this
[17:11] <xnox> =))))
[17:35] <LocutusOfBorg> thanks vorlon
[17:35] <LocutusOfBorg> btw mythtv has been dropped on ppc64el and riscv64
[17:35] <LocutusOfBorg> because upstream is meh about non amd64 and non arm64
[17:36] <vorlon> not a lot of people using their POWER systems to run mythtv, I'm sure
[17:36] <LocutusOfBorg> removing such two archs will finish x264 transition too
[17:36] <LocutusOfBorg> :)
[17:36] <LocutusOfBorg> and well riscv64 is meh
[17:36] <LocutusOfBorg> pybind11 and fakeroot should migrate "soon"
[17:37] <LocutusOfBorg> as well as the 4 transitions done now
[17:42] <sil2100> o/
[18:00] <ricotz> Eickmeyer, hi, don't worry Picard took care of it
[18:20] <Eickmeyer> ricotz: Yeah, saw that, that's why the question.
[18:22] <Eickmeyer> Unrelated: vorlon, cjwatson: Still getting failures for image builds, ongoing since around FF. Any progress made there?
[18:24] <vorlon> Eickmeyer: nothing I can do, particularly; this is between Launchpad and our IS team to get the cloud region's metadata provider sorted out
[18:24] <vorlon> I mean, we could change livecd-rootfs to not use the fallback behavior, but that would impact its utility outside of Launchpad
[18:25] <Eickmeyer> Right, we wouldn't want to do that.
[18:26] <Eickmeyer> Last person to ping me on that was cjwatson, I'll take it to #launchpad.
[18:40] <vorlon> fyi I've just done a pass over NBS and triggered rebuilds for all library revdeps; everything remaining on NBS in a few hours warrants looking at in -proposed to see why it's not done
[18:45] <LocutusOfBorg> vorlon, you mean what is listed as "I: [2022-03-07T18:44:20+0000] - List of old libraries in the target suite (139):" in britney log?
[20:22] <vorlon> LocutusOfBorg: I work from https://people.canonical.com/~ubuntu-archive/nbs.html
[20:24] <LocutusOfBorg> sndio/gpac/x264 should be ok
[20:31] <LocutusOfBorg> vorlon, I'm fixing your rebuilds, e.g. calcium
[20:46] <LocutusOfBorg> all the other are fixed by using c++17
[20:47] <LocutusOfBorg> will fix and upload
[20:50] <LocutusOfBorg> all fixed.
[20:58] <vorlon> LocutusOfBorg: cheers
[21:00] <seb128> do we have any casper review around which would like to check https://code.launchpad.net/~ubuntu-installer/casper/+git/casper/+merge/416098 ?
[21:00] <seb128> reviewer
[21:00] <seb128> if not I might simply end up uploading that without review, it should be a safe enough change
[21:06] <mwhudson> seb128: let me rubber stamp that casper thing
[21:41] <seb128> mwhudson, thx
[22:54] <cjwatson> Eickmeyer: I've been on leave today so haven't pursued this.  Will hopefully do some chasing tomorrow if I get any time between meetings
[23:10] <Eickmeyer> cjwatson: Yeah, we just lost about 230 gmail users on ubuntu-studio-devel@ due to excessive bounces on the build failure notifications, so the situation is pretty bad.
[23:11] <Eickmeyer> Some sort of gmail authentication issue.
[23:29] <Eickmeyer> ubuntu-archive: Does anybody have an extra cycle to look at show-in-file-manager in NEW? It's related to bug 1963694.


[00:22] <OvenWerks> Eickmeyer[m]: can we find out if libffi has been updated and python3-cffi or python3-jack-client has not?
[00:23] <OvenWerks> The error in #ubuntustudio does not look like an autojack error.
[00:23] <Eickmeyer> !info python3-jack
[00:23] <Eickmeyer> Do you know the source name?
[00:24] <Eickmeyer> !info python-jack groovy
[00:24] <Eickmeyer> I can't find out right now, no computer in front of me. I'm on my phone typing this, OvenWerks.
[00:24] <OvenWerks> https://packages.ubuntu.com/groovy/python3-jack-client
[00:25] <OvenWerks> no hurry I guess
[00:26] <OvenWerks> !info python3-jack groovy
[00:26] <OvenWerks> !info python3-jack-client groovy
[00:27] <Eickmeyer> OvenWerks: No diff between focal and groovy.
[00:27] <Eickmeyer> https://launchpad.net/ubuntu/+source/python-jack-client
[00:28] <OvenWerks> !python3-cffi
[00:29] <OvenWerks> !info python3-cffi goovy
[00:29] <OvenWerks> !info python3-cffi groovy
[00:29] <OvenWerks> !info python3-cffi focal
 sounds like maybe minor packaging differences
 in -cffi anyways
 but otherwise no core code problems/changes
 OvenWerks in case you are wondering
 -1 was a new upload release, 1build1 in Focal was no change rebuild dropping Py 3.7 (-2 in Debian)
 but Groovy has a newer version
[00:54] <OvenWerks> teward: SystemError: ffi_prep_closure(): bad user_data (it seems that the version of the libffi library seen at runtime is different from the 'ffi.h' file seen at compile-time)
 groovy has 1.14.2 thoug hso there is a difference
 (I dumb xD)
[00:58] <teward> OvenWerks: any chance there's a bug on this?  Also is this in Groovy or Hirsuite you notice?  (Curious where you found it)
[01:33] <OvenWerks> teward: it is from someone on #ubunutustudio. Operating SystemUbuntu 20.10
[01:35] <OvenWerks> the irc logs seem to have missed most of the conversation
[01:36] <OvenWerks> https://irclogs.ubuntu.com/2020/10/31/%23ubuntustudio.html nope I was wrong it seems to be two days back
[01:37]  * OvenWerks heads for supper cooking
[15:43] <Eickmeyer[m]> teward: Any chance you have time for a quick, rather trivial, upload (by comparison to other stuff I've flung your way): https://launchpad.net/agordejo
[15:43]  * Eickmeyer[m] hopes to apply for MOTU by the end of this month to take that burden
 changelog is wrong.  Hirsuite is the target
 not Groovy
 since that cycle's over
 Eickmeyer[m]: ^ error #1
[15:46] <Eickmeyer[m]> teward: Oof, I may not have pushed that. 2 secs.
[15:47] <Eickmeyer[m]> teward: Now try.
[15:47] <Eickmeyer[m]> teward: s/hirsuite/hirsute ^
 hirsute*
[15:48] <Eickmeyer[m]> hehe
 lol
 building local sbuild env now
[15:49] <Eickmeyer[m]> 👍
 looks like it didnt fail to build in hirsute, but there's Lintian warn level things (and it doesn't come as 'clean')
 but that may be my fault
[16:04] <Eickmeyer[m]> @teward001: Might be, had a clean PPA build.
 i think it's a typo on my end before i repulled
 running build again
[16:05] <Eickmeyer[m]> eesh.
 but i think the no-man-page error is still grave enough
[16:05] <Eickmeyer[m]> Upstream is notified.
 E: agordejo changes: bad-distribution-in-changes-file hirsute <— wow, hirsute lintian needs fixed xD
 W: agordejo: no-manual-page usr/bin/nsm-data <— also yeah this is a failure case
[16:07] <Eickmeyer[m]> @teward001: We've had things go through without manpages, and I literally just ran lintian and got no warnings at all.
[16:08] <Eickmeyer[m]> Holup... nm, I see that. We can lintian-override it pretty easily explaining that upstream is aware.
[16:10] <Eickmeyer[m]> @teward001 I did get an error for sensible-utils against the binary, so I'll have to fix that for d/control.
 @teward001 Feel free to re-pull, got those lintian issues hammered out. Realized I didn't exactly file an upstream issue, I told the developer directly in #lad.
 lol
 ok
 give me a few - lunchtime
[16:48] <Eickmeyer[m]> 👍
 yep no lintian errors here
 uploaded to hirsute new
[17:38] <Eickmeyer[m]> @teward001 Thanks!
[17:44] <OvenWerks> Eickmeyer: I was thinking it would be nice to use zita-mu1 as a jack backend. This would allow an overall audio level setup... however, zita-mu1 has no remote control possibilities: MIDI, OSC, Keyboard shortcuts, etc.
[17:45] <Eickmeyer[m]> Yeah, that's not good for any MIDI devices, clearly.
[17:46] <OvenWerks> Eickmeyer: I was thnking more of the keyboard media controls (mute, vol+, vol-)
[17:46] <Eickmeyer[m]> Oh, right. Can't do that anyway except for with pulse.
[17:47] <Eickmeyer[m]> I have a MIDI controller that I pretty much use to control jack-mixer launched via Agordejo.
[17:47] <OvenWerks> It is easy enough to capture the keystrokes and change them to whatever (midi, OSC etc) if that was available.
[17:47] <OvenWerks> mu1 has nice metering :)
[17:48] <Eickmeyer[m]> I mean, do we want to use that as an expermental backend?
[17:48] <OvenWerks> and 20.04 has no jack-mixer
[17:48] <Eickmeyer[m]> I backported jack-mixer to the PPA.
[17:49] <OvenWerks> I guess I have that turned off so it doesn't affect my work on controls.
[17:49] <Eickmeyer[m]> Gotcha. You can always cherry-pick the .deb.
[17:51] <OvenWerks> no nsm?
[17:51] <OvenWerks> no ubuntustudio-menu?
[17:52] <Eickmeyer[m]> new-session-manager is in there....
[17:52] <OvenWerks> I guess it is not an update
[17:52] <OvenWerks>  :)
[17:53] <Eickmeyer[m]> The binary name had to be linuxaudio-new-session-manager
[18:11] <Eickmeyer[m]> OvenWerks: Just backported -menu for the jack-menu and elisa fixes.
[18:11] <Eickmeyer[m]> *jack-mixer
[18:21] <OvenWerks> jack-mixer suggests patchage?
[18:23] <Eickmeyer[m]> That's a leftover.
[18:23] <Eickmeyer[m]> All I did was update the Debian package.
[18:23] <OvenWerks> Eickmeyer[m]: I thought there was suppoed to be a link from nsm to linuxaudio-new-session-manager for compatability
[18:24] <Eickmeyer[m]> There is. It's built-in to the binary.
[18:24] <Eickmeyer[m]> It's merely a symlink.
[18:24] <OvenWerks> Command 'nsm' not found,
[18:24] <Eickmeyer[m]> Because it's not nsm. It's "non-session-manager".
[18:25] <Eickmeyer[m]> It's never been nsm.
[18:25] <OvenWerks> ah
[18:26] <Eickmeyer[m]> Either way, I'd rather directly support new-session-manager anyhow, or via agordejo (new-session-manager is used as its backend). The non-* tools need to die in a fire.
[18:26] <OvenWerks> Eickmeyer[m]: in controls the button should say new session manager then
[18:27] <Eickmeyer[m]> Indeed. Directly execute new-session-manager, not the symlink. The symlink is just there for backwards compatibility.
[18:27] <OvenWerks> ok. And I will have it point at linuxaudio-new-session-manager directly
[18:27] <Eickmeyer[m]> No, the binary executable is new-session-manager.
[18:28] <Eickmeyer[m]> The package name is linuxaudio-new-session-manager by archive admin request.
[18:28] <OvenWerks> ok
[18:29] <OvenWerks> $ new-session-manager
[18:29] <OvenWerks> new-session-manager: command not found
[18:29] <Eickmeyer[m]> Sorry, nsm-legacy-guiu
[18:29] <Eickmeyer[m]> *nsm-legacy-gui
[18:30] <OvenWerks> I wonder how that works in arch...
[18:31] <Eickmeyer[m]> Should be the same, that's the generated binary name.
[18:31] <OvenWerks> ok
[18:46] <OvenWerks> fixed in controls (on my machine ;)
[18:47] <Eickmeyer[m]> Cool.
[18:47] <Eickmeyer[m]> With as much activity as we're seeing (merge requests, etc.) I'm not going to tag it for pre-release until you feel ready.


[01:51] <dmcglone> Hi all
[02:02] <Cheri703> o/
[02:22] <canthus13> blargh.
[02:25] <dmcglone1> switched rooms... LOL
[02:29] <canthus13> http://www.youtube.com/watch?v=etU_wtP5Pck&feature=related
[02:31] <dmcglone1> what was the purpose of it?
[02:32] <dmcglone1> I couldn't make out what she was saying
[02:34] <dmcglone1> canthus13: ?
[02:37] <canthus13> dmcglone1: I just thought it was creepy...
[02:39] <dmcglone1> did she say what the device was for? If it was for what I was thinking then no need to explain.. LOL
[02:41]  * skellat waves
[02:42]  * canthus13 waves skellat.
[02:42] <dmcglone1> hello skellat
[02:42] <skellat> Howdy
[02:42] <skellat> How goes it?
[02:42] <dmcglone1> how's it goin
[02:42] <dmcglone1> ha
[02:42] <skellat> It has been a weird enough day here in Ashtabula County
[02:42] <dmcglone1> I'm just sitting here with my heating pad on my back
[02:43] <skellat> dmcglone1: What caused?
[02:43] <dmcglone1> whats going on there?
[02:44] <dmcglone1> skellat: I have had a bad back since '94 the cause of this time around was a bike ride :-/
[02:44] <dmcglone1> 3 freakin weeks ago
[02:45] <dmcglone1> past 2 or 3 days it's been feeling a lot better.  LOL
[03:10] <canthus13> http://www.photoblip.com/pictures/2623/gumball-machine-warning.html
[03:16] <skellat> canthus13: Creative marketing for a dentist's office?
[03:37] <canthus13> skellat: Heh.
[07:31] <Unit193> I just got back from 2 good movies :P
[19:08] <TheErk> Hola
[19:08] <Cheri703> hi
[19:11] <TheErk> sup?
[19:12] <Cheri703> getting ready to root my nook
[19:34]  * canthus13 snickers.
[19:35] <Unit193> canthus13!!
[19:35] <canthus13> :D
[19:37] <canthus13> Cheri703: so soon? I thought you were gonna wait a while...
[19:38] <Cheri703> well, I was waiting for it to get easier
[19:38] <Cheri703> and for a launcher that'd work with it
[19:38] <Cheri703> both of those have been met
[19:38] <Cheri703> so...I'm going for it
[19:38] <canthus13> Ah.
[19:38] <canthus13> Cool. :)  Good luck.
[19:40] <Cheri703> thanks :)
[19:41] <TheErk> And the purpose of this is?
[19:42] <Unit193> I guess I should say howdy to TheErk...
[19:42] <Unit193> Na... ;)
[19:47] <Unit193> skellat: Howdy!
[19:47] <skellat> Hello
[19:47] <skellat> How goes it?
[19:48] <Unit193> Bloody computer keeps freezing up (Getting faster/heppening more)
[19:49] <skellat> Yikes
[19:49] <skellat> Which one is dying?
[19:50] <Unit193> It's not the newist/main, but it's the one I use the most!
[19:51] <skellat> What arch?
[19:51] <Unit193> Optiplex GX260 is the model
[19:52] <skellat> Ah, x86
[19:52] <skellat> How does the heat sink look?  Does it need to have new thermal paste put on it and the heat sink re-seated?
[19:53] <skellat> We had to do that for Dad's x86 box recently
[19:54] <Unit193> I don't think so... But I might not know...
[19:54] <Cheri703> TheErk: the purpose of rooting nook?
[19:57] <TheErk> yes ma'am
[19:58] <Cheri703> it is running full android 2.1 I can put other apps on it, both as backup for phone apps (putting a map program on there) and to enhance usability of the nook for reading functions as well. several people are installing the kindle app for android so they can use the nook for any ebook format
[19:59] <Cheri703> others are going to be hacking further so they end up with a small e-ink tablet
[20:00] <skrappjaw> howdy
[20:00] <skrappjaw> whats this you are talking about?
[20:03] <Unit193> skellat: Pics in a sec, do you have a sec?
[20:03] <skrappjaw> Cher703: I started work on my PS3 ubuntu controller mod.
[20:04] <skrappjaw> the PS button now has the ubuntu emblem. It looks really slick. Next is painting the controller base white and orange on top.
[20:07] <Cheri703> skrappjaw: I just rooted my nook :D
[20:09] <skrappjaw> nice
[20:10] <Unit193> Can't be CPU overheat because the computer will stay on... But it's not display because I can't remote into it
[20:15] <skellat> Sorry...I had to wander away...
[20:16] <Unit193> No problem! It's back online (for now...)
[20:18] <skellat> Cool.  I gotta go prep for work tonight so I will catch y'all hopefully around 2130-2200 maybe...
[20:42]  * Cheri703 is rooted and running some other stuff :D
[20:45] <canthus13> Cheri703: ...
[20:45] <Cheri703> yeah yeah
[20:45] <canthus13> Sorry.
[20:45] <Cheri703> I got a launcher on there, and I'm installing some apps
[20:45]  * canthus13 has such a hard time keeping a straight face with that word.
[20:45] <Cheri703> mmmhm
[20:49]  * canthus13 grins.
[20:49]  * canthus13 refuses to grow up. :)
[21:04] <skrappjaw> the old world meaning for the word F*ck had to do with planting.
[21:04] <skrappjaw> no joke. learned that from a linguist in the US Army.
[21:09] <skrappjaw> or at least it was used that way. Probably due to old germanic definitions that deal with copulation, or propagation.
[22:56]  * Cheri703 is content now :)
[22:56] <Cheri703> we are headed off to the drive in theater tonight with some friends