[00:13] <vorlon> dbungert: ok don't filter out rejected_permanently, those are *more* likely to require attention
[00:14] <vorlon> RAOF: indeed, fine to remove things that should be removed
[00:14] <dbungert> vorlon: got it, fixing
[00:15] <dbungert> cpete: this list may be more actionable as it is more focused on regressions and less on missing builds https://paste.ubuntu.com/p/KBtbw5Hctr/
[00:17] <cpete> dbungert: great, thanks!
[00:29] <vpa1977> ppp is missing include for sif6down. Anyone working on it?
[00:37] <mwhudson> cpete: so are you working on a package?
[00:37] <cpete> looking at accountsservice
[00:38] <mwhudson> should this be like the pre-armhf thing where we say in here which package we are looking at?
[00:38] <cpete> works for me
[00:39] <vpa1977> mmm, taking cdrkit?
[00:39] <mwhudson> oh that's a fairly short list!
[00:39] <dbungert> oh, needs to be longer sorry
[00:39] <dbungert> https://paste.ubuntu.com/p/G4spdRJ55X/
[00:39] <mwhudson> didn't cjs get removed on armhf?
[00:39] <mwhudson> dbungert: boo!
[00:39] <cpete> I skipped abseil because I think I read something in scrollback about updates to it? needs checking
[00:40] <dbungert> mwhudson: I need a newer yaml
[00:40] <dbungert> missingbuild only entries are likely to have been retried
[00:40] <mwhudson> ah but cjs has binaries in updates now
[00:41] <mwhudson> vorlon: remove cjs/armhf from noble-updates?
[00:45] <dbungert> I wonder if I should filter missingbuild entirely, it seems unhelpful and people's retry scripts seem effective enough there
[00:48]  * mwhudson glares at i386 regressions
[00:49] <mwhudson> eh these just need to be retried i think
[00:49] <mwhudson> (looking at alsa-lib)
[00:51] <dbungert> taking alsa-utils
[00:52] <arraybolt3> another armhf evaluation party?
[00:53] <dbungert> looking at actionable things related to seeded packages.  The definition of "actionable" is still being worked out
[00:53] <mwhudson> arraybolt3: this is more amd64 focused thanks to xz-utils
[00:53] <dbungert> this list might be pretty good: https://paste.ubuntu.com/p/ktsBMt4rmT/
[00:54] <vorlon> mwhudson: can't remove from noble-updates because launchpad lolz, but I will hint it, thanks
[00:55] <dbungert> taking apache2
[00:56] <liushuyu> Are we having another combing through the -proposed?
[00:56] <mwhudson> vorlon: hnngh
[00:56]  * arraybolt3 is wondering the same thing - preparing to try and help with it if possible
[00:57] <liushuyu> Also I proposed the SRU for a GDB fix (regression since GDB 10) https://code.launchpad.net/~liushuyu-011/ubuntu/+source/gdb/+git/gdb/+merge/463546 ...
[00:57] <liushuyu> ... the accompanying SRU bug: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2059856
[00:57] -ubottu:#ubuntu-release- Launchpad bug 2059856 in gdb "gdb 10.0 fails to examine any global variables in D programs" [Medium, Confirmed]
[00:58] <dbungert> arraybolt3: liushuyu: the list I posted has autopkgtest regressions blocking seeded packages.  Consider looking at those regressions - do they just need a retest click?  Do they have a queued test already?  Real regression?
[00:58] <arraybolt3> awesome
[00:58] <arraybolt3> I'll tentatively grab apparmor then
[00:58] <mwhudson> haha awesome is a source package but not on the list
[00:58] <liushuyu> dbungert: okay, so it's indeed the same activity, with a different set of packages
[00:58] <vpa1977> ok, grabbing appstream
[00:58] <mwhudson> i'll look at apr
[00:59] <liushuyu> taking apr-util
[00:59] <arraybolt3> update-excuses is more trustworthy than last time this time I assume?
[00:59] <mwhudson> yes
[01:02] <arraybolt3> apparmor seems to be hung up trying to install libvirt 10.0.0-2ubuntu6 rather than 10.0.0-2ubuntu7
[01:02] <arraybolt3> in the arm64 autopkgtest
[01:02] <arraybolt3> so I *think* it probably needs retried against all-proposed since the time it was triggered by the newer libvirt, it passed
[01:04] <vpa1977> appstream, tests queued.
[01:04] <vpa1977> taking apt (line 8)
[01:04] <liushuyu> for apr-util: I think it's LP was having a stroke at that moment, some packages have mismatched versions
[01:04] <arraybolt3> and the i386 regressions are just a mess, tons of installability weirdness
[01:05] <arraybolt3> (for apparmor)
[01:05] <liushuyu> are we going to have a re-test or ask someone to hint the test?
[01:05] <arraybolt3> who do I ping to ask for a test retry in a Main package?
[01:06] <sarnold> is there a 386 apparmor? o_O
[01:06] <arraybolt3> sarnold: yup :)
[01:06] <sarnold> I wonder if that's intentional :)
[01:06] <sarnold> sure there's a libapparmor for things but I thought our 386 packages in noble basically existed just for games or something like that
[01:06] <liushuyu> arraybolt3: many people in this channel can do that. Just ask away
[01:07] <arraybolt3> sarnold: well games need confined too don't you think? (not sure if apparmor works that way but whatever)
[01:09] <liushuyu> taking aptitude
[01:10] <mwhudson> taking argyll
[01:10] <arraybolt3> Please retest against all-proposed apparmor. Looks like it's missing needed deps that are still in -proposed.
[01:10] <arraybolt3> taking aribb24
[01:10] <liushuyu> Hmm... Are we just going to re-queue the tests this time?
[01:10] <liushuyu> arraybolt3: Will re-try your test
[01:11] <liushuyu> arraybolt3: ... also against which trigger/package?
[01:12] <arraybolt3> all-proposed?
[01:12] <arraybolt3> ah, I guess you need a trigger package too
[01:12] <arraybolt3> in that case trigger it against libvirt
[01:14] <liushuyu> arraybolt3: done. Retried apparmor/4.0.0-beta3-0ubuntu2 vs 4.0.0-beta3-0ubuntu2 w/ all-proposed=1 on i386
[01:14] <sarnold> I clicked a few buttons onthe apparmor thing let me know if I clicked the right ones or not :)
[01:15] <liushuyu> ... also done on amd64
[01:16] <arraybolt3> liushuyu: I think it also needs done on arm64 and s390x
[01:16] <vorlon> are these regressed tests being retried?
[01:16] <arraybolt3> and armhf
[01:17] <arraybolt3> These are all regressed, yes.
[01:17] <arraybolt3> amd64 actually wasn't regressed, and i386 wasn't going to be considered a regression, I was looking at other things testing against apparmor with my comments about i386 earlier
[01:17] <arraybolt3> sorry, I should have been more clear
[01:19] <liushuyu> arraybolt3: someone else probably already queued those
[01:19] <vorlon> sarnold: you can look at the germinate output if you want to see why apparmor is there on i386; basically we have to have the closure of build-deps of the things we actually care about
[01:20] <liushuyu> aptitude tests retried w/ all-proposed=1
[01:20] <arraybolt3> aribb24 seems to not need any action, all the failures look to be because of other archive in-flux issues
[01:21] <wgrant> Gardened the riscv64 build farm a bit, and we're now looking at about 21h to clear the queue. s390x about 15h.
[01:22] <liushuyu> taking arpack
[01:22] <arraybolt3> taking atkmm1.6
[01:22] <vpa1977> apt - tests failing due to uninstallability, retried with all-proposed
[01:23] <vpa1977> taking at-spi2-core
[01:23] <liushuyu> arpack retried w/ all-proposed=1 due to archive fluctuations
[01:23] <liushuyu> taking "audit"
[01:24] <arraybolt3> atkmm1.6 seems to have nothing that's directly its fault going on, moving on
[01:24] <arraybolt3> taking avahi
[01:28] <liushuyu> retried tests from "audit" w/ all-proposed (unable to install test-depends)
[01:28] <arraybolt3> (I'm assuming a package only needs action taken if there's something directly wrong with *it* causing problems - I think that might not be right in retrospect?)
[01:28] <arraybolt3> (like should I be asking for mass retries for things where all the regressions are just because of badpkg fails?)
[01:29] <liushuyu> arraybolt3: some of those badpkg fails are hard to tell (it might get past the package installation step and failed somewhere in the actual test)
[01:30] <liushuyu> taking base-files
[01:30] <vpa1977> retried all-proposed for at-spi2-core
[01:30] <vpa1977> taking bash
[01:31] <vpa1977> bash/dkim-rotate is failing on armhf due to faketime, please mark as non-regression
[01:31] <liushuyu> base-files tests retried
[01:31] <liushuyu> taking bc
[01:34] <liushuyu> arraybolt3: asking for mass retries for things where all the regressions are just because of badpkg fails? > on the second thought, this may work, although I am unsure it's acceptable to just blindly retry them w/ all-proposed=1
[01:37]  * arraybolt3 just remembered that for non-main things I can actually do retries myself
[01:43] <mwhudson> i'm yet to see a "real" failure tbh
[01:44] <arraybolt3> just threw aribb24's fails back into the fray, some with all-proposed and one with targeted triggers
[01:44] <vpa1977> bash is failing tests due to faketime, badpkg regressions retried with all-proposed
[01:45] <vpa1977> taking bind9
[01:50] <mwhudson> tempted to say we should take the list, mash retry and go to bed
[01:51] <dbungert> mwhudson: that may well be correct.  I went through a lot of filter iterations before I came to something that was actionable at all
[01:53] <arraybolt3> Pretty much everything I'm doing is mashing retry
[01:54] <arraybolt3> I found *one* strange-looking lxc thing a bit ago but I wasn't sure if it was a false positive or not
[01:55] <arraybolt3> Need someone to hit libreoffice:armhf with an all-proposed hammer with trigger avahi
[01:57] <liushuyu> arraybolt3: done
[02:00] <dbungert> mwhudson: so you tell me - do you think we should feed this list into a query on retry-autopkgtest-regressions ?
[02:01] <mwhudson> dbungert: i don't know. the queues are pretty long already :/
[02:01] <arraybolt3> also need nss-mdns:i386 retried, trigger avahi/0.8-13ubuntu5, all-proposed=1
[02:01] <mwhudson> dbungert: but i also don't feel like this analysis is doing anything useful
[02:02] <arraybolt3> ditto with pulseaudio
[02:02] <vpa1977> i kind of seeing badpkg, retry with all-proposed ...
[02:02] <dbungert> ok, pull the plug I say, I'll try to slice the data another way
[02:03] <vpa1977> arraybolt3: done
[02:04] <arraybolt3> ty
[02:04]  * arraybolt3 waits to snag a package until the next list revision appears
[02:05] <dbungert> arraybolt3: see mwhudson's comments above, I think the suggestion is to pause and see if we can get better data
[02:06] <arraybolt3> that sounds like a decent idea
[02:06] <arraybolt3> there are an awful lot of tests in progress, I was starting to wonder if I was just going to bog down the already slammed infra more
[02:06] <arraybolt3> (part of me wishes I had a local build farm and fiber internet so I could do things locally and know if they were going to work or not in the archive. Alas, I don't have either of those :P)
[02:07] -queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (focal-proposed) [6.0.0-0ubuntu8.18]
[03:19] <vorlon> dbungert, mwhudson: is https://paste.ubuntu.com/p/ktsBMt4rmT/ still the list being worked from?
[03:20] <vorlon> vpa1977: fwiw bash was resurrected in the release pocket so is not critical path anymore
[03:23] <mwhudson> vorlon: i think so
[03:43] <dbungert> vorlon: when I excluded autopkgtests the missingbuild items remaining were largely in a state of build pending or in progress.  AFAICT update_excuses.yaml isn't showing something that FTBFS.  And if I focus on autopkgtest to the exclusion of missingbuild, people felt like it was retry bait.  I found one lone item which didn't fit these two categories, libgpod which looks like it needs a MIR
[03:43] <dbungert> on a dependency.
[03:47] <vorlon> which probably means what it actually needs is a change backed out, since it's late to be introducing new MIRs
[03:47] <vorlon> ?
[03:47] <vorlon> but hang on, libgpod is a no-change rebuild vs the release pocket
[03:48] <dbungert> libgpod-dev/amd64 in main cannot depend on libimobiledevice-dev in universe
[03:48] <vorlon> so how does it have this dep now if it didn't before
[03:49] <vorlon> it did have it before so how did it get into the release pocket like this
[03:49] <vorlon> dig dig
[03:50] <vorlon> it was in main, and doko demoted it; unfortunately there's no 'reason' field for override changes. I'll put it back to main
[04:00] <vorlon> so the thing about the missingbuild packages all being build pending or in progress is that they're likely to be in that state because I'm retrying the builds hourly... but that doesn't mean they're going to succeed any time soon.  I think I'm going to back that off now to 4 hours
[04:02] <vorlon> done. I can bring it back up to 1h after folks have had a chance to actually look at the build failures; but at this point I suspect it's probably only the riscv64 qt dep chain that will fix itself with blind retries and everything else needs attention
[04:02] <mwhudson> having them be in needs build all the time does make diagnosing issues hard
[04:02] <mwhudson> anyway i have to go collect a child
[04:03] <dbungert> ok, I can produce a new report of those missingbuild items
[04:04] <vorlon> I also appear to have a list of 3000+ packages that are no-change rebuilds against the release pocket and so are candidates for hinting through without waiting for tests
[04:16] <vorlon> make that 4200
[04:17] <vorlon> and that list is missing some
[04:20] <dbungert> so if we wanted to chase those missing builds then something like this: https://paste.ubuntu.com/p/Zr4r2PvXfV/
[05:05] -queuebot:#ubuntu-release- Unapproved: accepted nullboot [source] (jammy-proposed) [0.5.0-0ubuntu<IP_ADDRESS>]
[05:10] <vorlon> ok, now 4907 packages
[05:14] <dbungert> https://paste.ubuntu.com/p/jFkWdk9k5X/ - build focus, urls, explanation of the filter
[05:14] <vorlon> here is the list of packages I'm proposing to skip tests for based on them being no-change rebuilds vs the release pocket. I have not cross-checked this against the list of seeded packages https://code.launchpad.net/~ubuntu-release/britney/+git/hints-ubuntu/+merge/463559
[05:28] -queuebot:#ubuntu-release- Unapproved: cockpit-podman (jammy-backports/universe) [84-1~bpo22.04.1 => 86-1~bpo22.04.1] (no packageset)
[05:28] -queuebot:#ubuntu-release- Unapproved: cockpit-podman (mantic-backports/universe) [84-1~bpo23.10.1 => 86-1~bpo23.10.1] (no packageset)
[05:29] -queuebot:#ubuntu-release- Unapproved: cockpit (jammy-backports/universe) [311-1~bpo22.04.1 => 314-1~bpo22.04.1] (no packageset)
[05:29] -queuebot:#ubuntu-release- Unapproved: cockpit (mantic-backports/universe) [311-1~bpo23.10.1 => 314-1~bpo23.10.1] (no packageset)
[05:36] <vorlon> this looks like britney queuing tests in a loop again. :/ https://autopkgtest.ubuntu.com/packages/a/apache2/noble/arm64
[06:14] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (xenial-proposed) [<IP_ADDRESS>]
[06:37] -queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (jammy-proposed) [0.140ubuntu13.5]
[06:47] -queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (focal-proposed) [0.136ubuntu6.8]
[07:18] <wgrant> I'm manually chasing the ppc64el/riscv64/s390x KDE build chains this evening, as they're going to take a couple of weeks otherwise.
[07:32] <RikMills> wgrant: kubuntu has a semi smart retry script that I can set going on a loop
[07:32] <RikMills> https://people.ubuntu.com/~rikmills/pdf/2024-04-03-08:26:54-904142.pdf
[07:37] <wgrant> RikMills: Oh, handy :)
[07:38] <RikMills> our build stacks have so many tiers that we need that to get things built in a reasonable time
[07:39] <wgrant> Yeah, I've run into it when bootstrapping new archs. Glad there's some automation now!
[07:41] <RikMills> set it to check and retry candidate builds every hour for now
[07:45] <RikMills> may result in some email spam where things are ftbfs due to deps instead of reporting a depwait in LP
[07:46] <wgrant> Heh, I'm already getting about 1000 failure emails an hour anyway :)
[07:46] <RikMills> that figures!
[09:18] <jamespage> Hi release team - I am working through issues in the openstack package set and I need to sync cloudkitty from debian experimental - along with two new deps which are both in unstable already - to resolve incompatility with python-oslo.db >= 15.0.0 (as in noble)
[09:19] <jamespage> I've tested everything here - https://launchpad.net/~james-page/+archive/ubuntu/caracal/+packages
[09:20] <jamespage> OpenStack Caracal also releases today so I'll be working through final release uploads for the leaf packages in the OpenStack package set this week
[11:16] <RikMills> beta delated until 11th https://discourse.ubuntu.com/t/noble-numbat-beta-delayed-xz-liblzma-security-update/43827
[11:23] <sil2100> I need to coordinate with other release team members, but the Beta freeze will be delayed by a week possibly as well (...so till Monday?)
[11:23] <sil2100> But I need to double check with everyone
[11:24] <sil2100> For now the rebuilds are looking fine, we're trying to migrate them swiftly
[11:24] <sil2100> It's another huge huge huge effort, so it's hard to say anything for certain. But we aim to get the archive cleared our till Friday
[11:26] <sil2100> cjwatson: hey hey! Do you still have the powers to moderate ubuntu-devel-announce@?
[11:26] <sil2100> Since I think my mail is stuck there in moderation
[11:27] <cjwatson> sil2100: done
[11:31] -queuebot:#ubuntu-release- Unapproved: tracker-miners (jammy-proposed/main) [3.3.3-0ubuntu<IP_ADDRESS> => 3.3.3-0ubuntu<IP_ADDRESS>] (ubuntu-desktop, ubuntugnome)
[11:58] <jbicha> gnome-tweaks migrated yesterday out of noble-proposed even though it depends on pygobject 3.48 which didn't migrate yet. I guess it's because tweaks is arch:all & some guardrails were turned off for arch:all for xz-utils mitigation
[12:00] <jbicha> I guess amd64 has widespread uninstallability so probably not much of a concern since we should be able to resolve things later this week
[12:27] <wgrant> vorlon: Turns out that t* onwards actually never got to build because of the frequent retries. I'm giving everything with a reasonable score that hasn't ever been dispatched a score bump.
[12:37] <wgrant> KDE is nearly there -- kwallet-kf5 is building now and kxmlgui will build after this publisher run, which gives us kio.
[14:03] -queuebot:#ubuntu-release- New source: lxml-html-clean (noble-proposed/primary) [0.1.0-0ubuntu1]
[14:30] -queuebot:#ubuntu-release- New: accepted gnome-shell-pomodoro [source] (noble-proposed) [0.25.1-0ubuntu1]
[14:30] -queuebot:#ubuntu-release- New: accepted jami [sync] (noble-proposed) [20231201.0~ds2-1]
[14:34] -queuebot:#ubuntu-release- New: accepted gnome-online-accounts-gtk [source] (noble-proposed) [3.50.1-0ubuntu1]
[14:38] -queuebot:#ubuntu-release- New binary: gnome-online-accounts-gtk [amd64] (noble-proposed/none) [3.50.1-0ubuntu1] (no packageset)
[14:39] -queuebot:#ubuntu-release- New binary: gnome-online-accounts-gtk [armhf] (noble-proposed/none) [3.50.1-0ubuntu1] (no packageset)
[14:41] -queuebot:#ubuntu-release- New binary: gnome-online-accounts-gtk [arm64] (noble-proposed/none) [3.50.1-0ubuntu1] (no packageset)
[15:09] <kanashiro> RAOF I am not sure if you saw the ping from Steve about the runc-app package in NEW for Jammy, Focal and Mantic, would you have the time to take a look at it in your next shift? TIA!
[15:16] <athos> Hi ubuntu-archive, could anyone please remove php-oscarotero-gettext from the sync blocklist? This no longer FTBFS and blocks symfony migration. https://code.launchpad.net/~athos-ribeiro/+git/sync-blocklist/+merge/463602
[15:19] -queuebot:#ubuntu-release- New binary: gnome-online-accounts-gtk [ppc64el] (noble-proposed/universe) [3.50.1-0ubuntu1] (no packageset)
[15:56] <LocutusOfBorg> athos, https://launchpad.net/ubuntu/+source/php-oscarotero-gettext/4.8.7-2
[15:56] <LocutusOfBorg> I didn't unblocklist
[15:56] <LocutusOfBorg> just syncd
[15:59] <athos> Thanks, LocutusOfBorg
[16:08] <schopin> where can I find the list of packages that are allowed to build on i386?
[16:09] <schopin> a11y-profile-manager is blocked in noble-proposed because of a missing i386 build but according to LP, it was never attempted.
[16:11] <Eickmeyer> schopin: It's a packageset, I believe. i386-whitelist.
[16:12] <schopin> ALright, subsidiary question: how does one look at packagesets on LP? I don't believe I've ever needed to before.
[16:13] <Eickmeyer> Huh, that's an excellent question! (I forgot!) XD
[16:14] <cjwatson> edit-acl in lp:ubuntu-archive-tools can show them
[16:14] <cjwatson> edit-acl -S noble -P i386-whitelist query
[16:15] <schopin> thanks!
[16:15] <cjwatson> It's built from lp:~ubuntu-core-dev/ubuntu-seeds/+git/i386
[16:15] <cjwatson> (I believe)
[16:15] <schopin> Ah, perfect, exactly the info I wanted.
[16:18] <schopin> Since it's computed from seeds, I'm wondering if the whole binary removal  didn't screw it up somehow?
[16:18] <Eickmeyer> https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/i386/tree/i386?h=noble
[16:19] <Eickmeyer> It's probably just not there yet?
[16:19] <Eickmeyer> But I don't see it in the seed.
[16:20] <Eickmeyer> Probably needed by something that's seeded there but isn't built yet.
[16:20]  * Eickmeyer is guessing
[16:21] <schopin> Maybe.
[16:23] <RikMills> schopin: you can also see the generated packagesets here; https://ubuntu-archive-team.ubuntu.com/packagesets/noble/
[16:25] <Eickmeyer> ^Thats what I couldn't remember!
[16:25] <Eickmeyer> sil2100: BTW, I locked your post on discorurse as is customary for announcements (noticed you couldn't?).
[16:26] <Eickmeyer> BTW, my spelling for discourse was horrible right then.
[16:30] <sil2100> Eickmeyer: thank you! Yes, I seemed to have no powers to do that!
[16:30] <sil2100> Or at least lacking in knowledge on how to do it, but all the places where I'd expect to see the features were missing it
[16:31] <Eickmeyer> sil2100: Right, I'm showing you have no moderator privileges there, which is required to lock posts.
[16:32] <Eickmeyer> I'll fix that to give you mod privs in the Announcements category.
[16:35] <Eickmeyer> sil2100: Strange, as a member of the release team, you should've been able to do it using the wrench icon in the lower left-hand corner of the post. Either way, it's done.
[16:49] <vorlon> cpaelzer: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/noble/lubuntu/+build/600219
[16:50] <schopin> tsimonq2: are you on top of calamares-settings-ubuntu FTBFS ? I have zero experience in golang...
[16:51] <vorlon> fyi I'm going through https://paste.ubuntu.com/p/fTBTWsTBnD/ and looking at the packages blocked on i386 only, these are likely noble-updates issues that need hinting, so confirming and adding those hints
[16:54] <schopin> if anyone is looking at that list, I've already taken care of accountsservice and am looking at calamares-settings-ubuntu
[17:09] <ahasenack_> vorlon: I'm trying to troubleshoot https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/2058576, but I can't get the noble build-deps installed in armhf, either release or proposed pocket
[17:09] -ubottu:#ubuntu-release- Launchpad bug 2058576 in sssd (Ubuntu) "FTBFS: armhf: build-time test failures" [High, In Progress]
[17:09] <ahasenack_> wait a bit more? Or is there a trick?
[17:13]  * ahasenack_ -> bbl, dentist
[17:27] <bdmurray> I jumped down the list and mpg123 ftbfs on armhf again after a retry
[17:27] <bdmurray> If somebody could take an in depth look at it that would help
[17:30] <liushuyu> bdmurray: seems to be due to time_t transition: debhelper is complaining that it can't find the expected 32-bit symbols
[17:43] <schopin> bdmurray: I'll take a look.
[17:53] <doko> looking at ppp
[17:59] <liushuyu> are we looking at this FTBFS list from top to bottom or picking items at random?
[17:59] <bdmurray> I picked something at random so don't follow my lead. ;-)
[18:00] <doko> haruna/riscv64 is waiting on KDE
[18:00] <liushuyu> opencv failed to build due to numpy removing numpy.distutils (Python 3.12 transition), a patch is needed
[18:03] <vorlon> I've stopped my rebuilds in a loop. Especially if the Kubuntu team have a smarter script, it's better at this point to just run that, and triggering other retries at this point just gets in the way
[18:04] <doko> synced vorbis-tools
[18:04] <doko> ginggs: ^^^ could you look at opencv?
[18:04] <ginggs> doko: sure
[18:06] <liushuyu> doko: if it is not a very big ask, can you update the gdb 15 snapshot to b1741ab0dafd899889faab6e862094a325a6b83c (committed 22 hours ago)? It contained at least two regression fixes
[18:08] <liushuyu> Also, can anyone from the SRU team take a look at https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2059856?
[18:08] -ubottu:#ubuntu-release- Launchpad bug 2059856 in gdb (Ubuntu) "gdb 10.0 fails to examine any global variables in D programs" [Undecided, New]
[18:12] <liushuyu> Okay... I am going to go through the list from top to bottom
[18:13] <liushuyu> ... accountsservice: time_t 64-bit issue on armhf, patch required
[18:13] <doko> synced sdl-mixer1.2
[18:13] <liushuyu> appstream-glib: i386 not built (not on the allowlist)
[18:13] <liushuyu> ark: still building
[18:14] <liushuyu> audiocd-kio: still building
[18:14] <doko> liushuyu: this one not good enough? https://launchpad.net/ubuntu/+source/gdb/<IP_ADDRESS>40403-0ubuntu1
[18:15] <liushuyu> doko: let me check, one second
[18:15] <schopin> liushuyu: accountsservice is already fixed.
[18:15] <schopin> see backlog :)
[18:16] <liushuyu> doko: This one is good enough, sorry did not check the snapshot version
[18:16] <liushuyu> bluedevil: still building
[18:21] <liushuyu> schopin: Okay, the backlog is a bit messy this time around due to non-alphabetic ordering
[18:21] <doko> synced qm-dsp
[18:22] <liushuyu> https://launchpad.net/ubuntu/+source/gst-plugins-good1.0/1.24.0-1ubuntu6/+build/27980479 needs a retry, no log output provided
[18:23] <ginggs> liushuyu: retried
[18:24] <liushuyu> ginggs: Thanks!
[18:26] <doko> merging policykit-1
[18:33] <vorlon> athos: php-oscarotero-gettext unblocked
[18:35] <vorlon> ahasenack_: surely the sssd build-deps should be installable from the union of (noble,noble-updates,noble-proposed) since it built on all other archs?
[18:36] <vorlon> all the packages that were blocked by missing i386 builds have been hinted now.  These are cases where copying to noble-updates brought back i386 binaries which had been deleted, which britney now sees; and they can't be deleted from -updates.
[18:38] <kanashiro> Is there anything specifically that I can help with? Or should I just go through the list and pick something?
[18:38] <vorlon> kanashiro: help figure out why livecd-rootfs is uninstallable in livefs builds https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/noble/lubuntu/+build/600219
[18:38] <vorlon> RUN: /usr/share/launchpad-buildd/bin/builder-prep
[18:38] <vorlon> livecd-rootfs itself isn't seeded in images so isn't currently on the list of targets
[18:39] <vorlon> and in my noble chroot it is installable so I have too much stuff preinstalled to reproduce this
[18:39] <vorlon> maybe you can reproduce it using https://cloud-images.ubuntu.com/buildd/daily/noble/current/
[18:39] <kanashiro> vorlon ack, let me try to reproduce the build failure
[18:47] <doko> fixing openldap
[18:47] <schopin> fixed mpg123 (and started its t64 transition)
[18:48] -queuebot:#ubuntu-release- New binary: mpg123 [amd64] (noble-proposed/main) [1.32.5-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[18:48] -queuebot:#ubuntu-release- New binary: mpg123 [ppc64el] (noble-proposed/main) [1.32.5-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[18:48] -queuebot:#ubuntu-release- New binary: mpg123 [i386] (noble-proposed/main) [1.32.5-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[18:50] <schopin> liushuyu: were you working in order? Which package are you at? :)
[18:50] <vorlon> schopin: I'm going to back this upload out for right now and instead break mpg123 on armhf
[18:50] <vorlon> schopin: then restore your build
[18:50] <RikMills> kde frameworks is getting there: https://people.ubuntu.com/~rikmills/pdf/2024-04-03-19:21:43-933666.pdf
[18:50] -queuebot:#ubuntu-release- New binary: mpg123 [armhf] (noble-proposed/main) [1.32.5-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[18:50] <liushuyu> schopin: Yes, I am currently starting from color-kde
[18:50] -queuebot:#ubuntu-release- New binary: mpg123 [s390x] (noble-proposed/main) [1.32.5-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[18:51] <schopin> vorlon: ACK, fair enough.
[18:51] <vorlon> schopin: but we don't have time to do these things in the "clean" order
[18:51] <liushuyu> I am trying to find a way to filter out all the pending builds
[18:51] <vorlon> schopin: sorry, I should've realized the reason you were asking about this is because it's seeded
[18:51] <schopin> indeed.
[18:52] <vorlon> schopin: so, in particular DON'T start doing any no-change rebuild uploads for the new abi :)
[18:52] <schopin> :-D
[18:53] <schopin> So does that mean that when the armhf build is broken we just hint it through somehow?
[18:53] <vorlon> yeah
[18:53] <vorlon> in britney this is a 'force' hint
[18:53] <vorlon> there's also a 'force-hint' hint, which means not just to ignore out-of-dateness but to ignore regressions in installability
[18:54] -queuebot:#ubuntu-release- New binary: mpg123 [arm64] (noble-proposed/main) [1.32.5-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[18:57] -queuebot:#ubuntu-release- New: accepted mpg123 [amd64] (noble-proposed) [1.32.5-1ubuntu1]
[18:57] -queuebot:#ubuntu-release- New: accepted mpg123 [armhf] (noble-proposed) [1.32.5-1ubuntu1]
[18:57] -queuebot:#ubuntu-release- New: accepted mpg123 [ppc64el] (noble-proposed) [1.32.5-1ubuntu1]
[18:57] -queuebot:#ubuntu-release- New: accepted mpg123 [arm64] (noble-proposed) [1.32.5-1ubuntu1]
[18:57] -queuebot:#ubuntu-release- New: accepted mpg123 [s390x] (noble-proposed) [1.32.5-1ubuntu1]
[18:57] -queuebot:#ubuntu-release- New: accepted mpg123 [i386] (noble-proposed) [1.32.5-1ubuntu1]
[18:58] <sergiodj> hello, I can spare some time now to help with whatever is needed.  is there anything I can do?
[19:02] <dbungert> sergiodj: I'm working on some update_excuses analysis focusing on seeded packages.  Here is a list of "missing" builds as of the last excuses run - https://paste.ubuntu.com/p/pM3FvW55Xm/
[19:02] <schopin> engrampa should be hinted, armhf-only FTBFS. I think it only needs a 'force' rather than 'force-hint'
[19:02] <vorlon> kanashiro: if you need it, apparently https://launchpadlibrarian.net/694289600/livecd.ubuntu-base.rootfs.tar.gz is the actual tarball currently in use by launchpad (livefs builds happen in a container rather than a chroot but the contents should be the same)
[19:02] <schopin> do we have a RT member to ping for quick hinting?
[19:03] <sergiodj> dbungert: thanks, I can take one from the list.
[19:03] <dbungert> sergiodj: cheers
[19:03] <schopin> all the Ds as well as elisa-player are waiting on builds
[19:03] <sergiodj> let me check what's not being worked on (based on the backlog)
[19:04] <schopin> sergiodj: I've just finished engrampa
[19:04] <sergiodj> schopin: ACK.
[19:04] <schopin> evolution-data-server is a case of ghost i386, skipping.
[19:04] <sergiodj> I can take fcitx-cloudpinyin
[19:04] <kanashiro> vorlon thanks for the pointer, I started by trying to install livecd-rootfs in a clean lxd container and it worked, I am starting to take a look at the git repo that builds the images. I'll play with this tarball
[19:05]  * schopin takes a food break.
[19:05] <sergiodj> schopin: oh, is fcitx-cloudpinyin also a case of ghost i386?
[19:05] <sergiodj> let me check
[19:06] <bryceh> vorbis-tools 1.4.2-1build5 FTBFS looks like it should be resolved by 1.4.2-2 which is already in -proposed, but pending publication on riscv64
[19:06] <sergiodj> it seems to be; there's no i386 build failure for fcitx-cloudpinyin on LP.  moving on to "folks" (I skipped fcitx-fbterm because I don't have easy access to an armhf)
[19:08] <schopin> sergiodj: see my conversation with Steve around 15mn ago wrt armhf FTBFS :)
[19:10] <sergiodj> schopin: reading
[19:10] <sil2100> dbungert, vorlon, schopin: are we going in a particular order? Are we coordinating work here?
[19:11]  * schopin goes back to cooking.
[19:11] <sil2100> Or should I just go through the list and act on the first thing I see?
[19:11] <schopin> sil2100: alphabetically.
[19:11] <sil2100> Are we doing the same 'taking' approach? ;)
[19:11] <schopin> but some folks skipped ahead.
[19:11] <doko> so, I synced all packages, which were marked ftbfs on armhf, and had a patch in Debian
[19:11] <doko> and merged a few
[19:12] <doko> scored l-z* packages up on riscv64 and s390x
[19:13] <sil2100> Is folks the last one?
[19:13] <sil2100> Taking geary
[19:14] <sergiodj> I'm starting to look into folks
[19:18] <sergiodj> vorlon: fcitx-fbterm is FTBFSing on armhf and apparently we're supposed to force-hint these cases, so here's a heads up
[19:18] <sergiodj> let me know if you'd like me to look further into the failure
[19:18] <doko> we can't hint ftbfs
[19:18] <schopin> might want to open a bug
[19:19] <bryceh> hi, I can spare some time too, would you like my help with anything?
[19:19] <sergiodj> schopin: according to your conversation with steve above: "So does that mean that when the armhf build is broken we just hint it through somehow?", and the answer was "yes"
[19:19] <doko> sergiodj: removing the fcitx-fbterm armhf binaries, no rdeps
[19:19] <sergiodj> I'm probably misunderstanding something then
[19:19] <sergiodj> doko: thanks
[19:20] <sergiodj> I guess that will do it
[19:20] <doko> wait, https://launchpad.net/ubuntu/+source/fcitx-fbterm/0.2.0-5 I just synced it
[19:21] <sil2100> Ok, geary is actually blocked on folks it seems, so hopefully sergiodj can resolve that and it should just build normally
[19:21] <sergiodj> doko: ah, even better then
[19:21] <sergiodj> and I see that armhf built there
[19:21] <sergiodj> nice
[19:21] <doko> sil2100, sergiodj: I had ignored test results, but then reverted that. maybe do it again?
[19:21] <doko> folks
[19:22] <schopin> sergiodj: I think I used slightly wrong terminology. Steve probably meant "if there are armhf test failure", as in "if the armhf package is broken"
[19:22] <sil2100> I'll take geocode-glib in the meantime
[19:23] <sergiodj> doko: how much effort should we put into fixing these tests? ignoring the failures seems like a last resort, but if that's the recommended action now then I'm OK doing it
[19:23] <sil2100> doko: you mean there was a skiptest?
[19:23] <sergiodj> schopin: ah, thanks for the clarification :)
[19:23] <schopin> sergiodj: we need to build images as soon as possible
[19:24] <schopin> If a test is failing, open a bug and hint it.
[19:24] <schopin> (unless it seems REALLY bad)
[19:24] <sergiodj> this is not a case of hinting, but rather a case of override_dh_auto_test
[19:24] <sergiodj> but yeah, I get what you mean
[19:25] <sergiodj> OK, let me see what I can do here
[19:25] <vpa1977> Good morning, what list are we working off?
[19:26] <sil2100> vpa1977: hello! Welcome to the fun!
[19:26] <sil2100> vpa1977: https://paste.ubuntu.com/p/pM3FvW55Xm/
[19:26] <schopin> sergiodj: I think we don't want to skip the broken tests in d/rules, but rather to just hint that specific version through. Again, unless it's really bad.
[19:27] <sil2100> vpa1977: basically we want to resolve the FTBFSes for the listed packages there, since ADT's we'll most likely hint
[19:27] <sil2100> But we need to deal with other stuff that blocks migration, starting with lack of binaries
[19:27] <sergiodj> schopin: but the package is FTBFSing. without ignoring the test results on d/rules, there's no way to hint the package, right?
[19:27] <vpa1977> looking at gimp-plugin-registry, then
[19:27] <athos> bryceh: from what I understood, we are going through https://paste.ubuntu.com/p/pM3FvW55Xm/ top-down
[19:27] <sergiodj> schopin: that's what I understood when doko said he had ignored test results from the package
[19:28] <jbicha> sergiodj: I did open a bug upstream for folks so I think ignoring the test results for now is ok-ish
[19:28] <athos> last one taken is gimp-plugin-registry, you take the next and let ppl know here :)
[19:28] <sergiodj> jbicha: ACK, thanks
[19:28] <jbicha> bug 2060073
[19:28] -ubottu:#ubuntu-release- Bug 2060073 in folks (Ubuntu) "folks build test failures with glib 2.80" [High, Triaged] https://launchpad.net/bugs/2060073
[19:28] <sil2100> Ah, from what I see all i386 based issues we can handle as resolved, right?
[19:28] <sil2100> Then I'll be moving on
[19:28] <vpa1977> athos: ack, taking gnome-contacts
[19:28] <sergiodj> OK, I'm running a test build here and should be ready to upload soon
[19:28] <athos> I am joining the fun as well I suppose :)
[19:29] <athos> vpa1977: I used that as the last one taken becaouses you took it :x hhehe
[19:29] <sil2100> gnome-desktop is i386 related, skipping
[19:29] <sil2100> Taking gnome-remote-desktop
[19:30] <vpa1977> athos: ok, a race condition - would you like contacts, or plugin-registry? =)
[19:30] <athos> vpa1977: pick one, I will have the other
[19:30] <vpa1977> gnome-contacts - build dep on folks, which is being worked on
[19:30] <vpa1977> athos,
[19:30] <vpa1977> athos: plugin registry for me then
[19:31] <sergiodj> OK, folks uploaded. test results ignored for now. thanks schopin jbicha doko for the discussion
[19:32] <athos> ack, taking gnome-contacts here
[19:33] <athos> someone re-triggered those (build is running). skipping gnome-contacts for now
[19:34] <schopin> It's fine to remove armhf binaries when the only rdep is lxqt, right?
[19:34] <sergiodj> gnome-shell seems to be resolved, too
[19:35] <sergiodj> gnome-desktop doesn't have an i386 FTBFS listed (I think that's what schopin meant with "ghost i386")
[19:35] <sil2100> jbicha: hey! Just to know some context: https://bugs.launchpad.net/ubuntu/+source/gnome-remote-desktop/+bug/2059076 <- is anyone on the desktop team working on the FTBFS on armhf?
[19:35] -ubottu:#ubuntu-release- Launchpad bug 2059076 in gnome-remote-desktop (Ubuntu) "proposed-migration for gnome-remote-desktop 46~rc-0ubuntu2" [Undecided, New]
[19:36] <sil2100> I guess I can unblock it anyway, I see the previous version got pushed to the release pocket without armhf as well
[19:37] <jbicha> sil2100: yeah, gnome-remote-desktop was removed on armhf for time_t so maybe that helps?
[19:37] <sergiodj> someone retriggered gst-plugins-good1.0/arm64.  we'll have to wait and see if the new build fails
[19:37] <jbicha> sergiodj: that was me, gst good has a flaky test that passes eventually :(
[19:37] <liushuyu> I quickly cobbled together a script to scrape the latest build status in that FTBFS list, here is the result: https://pastebin.ubuntu.com/p/33yQPKk95C/
[19:37] <bryceh> I'll look at gtk-sharp3
[19:37] <sergiodj> jbicha: ACK, thanks
[19:38] <sergiodj> looking at gtk2-engines-murrine
[19:38] <liushuyu> (here is the script: https://pastebin.ubuntu.com/p/x8RmJMSSVs/)
[19:38] <sil2100> jbicha: ah, indeed! Thanks
[19:38] <athos> looging at gtkmm2.4
[19:39] <athos> ghost i386
[19:39] <bryceh> are there tips for handling armhf specific issues?
[19:40] <athos> taking krita
[19:40] <liushuyu> bryceh: They need to be handled on a case-by-case basis, there is unfortunately no silver bullet or one-size-fits-all solution
[19:41] <liushuyu> taking gwenview
[19:41] <schopin> bryceh: for that one I'd add the relevant -Werror flag to DEB_CFLAGS_MAINT_APPEND on amd64 to fix it locally.
[19:41] <liushuyu> gwenview was being re-queued
[19:41] <liushuyu> taking indicator-bluetooth
[19:42] <liushuyu> this one is fully built
[19:42] <bryceh> gtk-sharp3 issue matches deb #1067940
[19:42] <schopin> ... which doesn't have a patch :)
[19:42] <bryceh> schopin, ok thx
[19:43] <liushuyu> plasma-framework: dependency problem on riscv64
[19:43] <sergiodj> schopin: I have a tentative patch for gtk2-engines-murrine, are you guys using PPAs to check before uploading, or just upload to the archive and deal with failures as they occur?
[19:44] <sergiodj> (asking because I don't want to impose more on the infrastructure, but OTOH I don't have an armhf machine to test things locally)
[19:44] <schopin> I upload directly.
[19:44] <sergiodj> OK
[19:44] <schopin> Your PPA is on the same infra, after all :)
[19:44] <athos> krita was waiting on libimath-3-1-29; retrying and moving on
[19:47] <sergiodj> exactly why I asked :D
[19:47] <sil2100> Ok, libgweather4, liboauth, liboobs and libphonenumber are all i386, skipping
[19:47] <sil2100> Taking libquicktime
[19:49] <lvoytek> I can also join in now :)
[19:50] <liushuyu> libreoffice: riscv64 waiting on KF5 stuff
[19:50] <sergiodj> gtk2-engines-murrine uploaded
[19:51] <doko> just skip the riscv64/s390x stuff for now, the kde stack is not yet ready, and people are running kde specific retries. see backlog
[19:52] <lvoytek> taking thin-provisioning-tools
[19:52] <liushuyu> taking libcdio
[19:53] <sergiodj> taking mpg123
[19:53] <liushuyu> libcdio seems to be a time_t issue
[19:54] <doko> liushuyu: then make it a transition
[19:54] <doko> sergiodj: no, in NEW
[19:54] <sergiodj> doko: OK, moving on
[19:54] <cpete> still going through?
[19:54] <cpete> if so I'll take nas
[19:55] <athos> taking opencolorio
[19:55] <sergiodj> taking opencv
[19:55] <cpete> oops paste didn't work but seems like it!
[19:55] <schopin> taking openimageio
[19:56] <doko> sergiodj: I was wrong about mpg123. and ginggs fixed opencv
[19:57] <schopin> sergiodj: I had to start the t64 for mpg123, maybe by now the new binaries are published and we can start uploading rebuilds of rdeps?
[19:58] <sil2100> Okay, syncing libquicktime to fix the armhf issue, basically a patch for the missing include
[19:58] <doko> vorlon removed the new mpg123 upload instead, to let the existing package migrate
[19:59] <sergiodj> schopin: sure
[19:59] <sergiodj> schopin: sorry, where are the new binaries?
[19:59] <sergiodj> I only see 1.32.5-1build2 on LP
[19:59] <doko> removed
[20:00] <sergiodj> ah, OK
[20:00] <schopin> oh well :)
[20:00] <sergiodj> OK, moving on, then
[20:00] <sergiodj> opencv is fixed according to doko.  taking openldap
[20:01] <vorlon> and I've now added the hint to ignore the missing armhf binaries
[20:01] <schopin> athos: I think yours is waiting on mine.
[20:01] <jbicha> bryceh: I can take gtk-sharp3
[20:01] <athos> yup, just realized that
[20:01] <athos> I will move on then, schopin
[20:02] <bryceh> @jbicha, ok thanks
[20:02] <athos> taking overlay-scrollbar
[20:03] <sergiodj> I'm retriggering openldap's armhf build because it's failing due to the testsuite, which is a bit flaky on armhf
[20:03] <bryceh> taking policykit-1
[20:03] <schopin> vorlon: could you hint opencolorio and openimagio? I think they need bootstrapping on armhf.
[20:03] <vorlon> eew? how can they still need bootstrapping
[20:03] <vorlon> I'll take a look at them but am currently in standup, and then I need to redo my script for requeuing tests to make it not terrible
[20:04] -queuebot:#ubuntu-release- New: accepted gnome-online-accounts-gtk [amd64] (noble-proposed) [3.50.1-0ubuntu1]
[20:04] -queuebot:#ubuntu-release- New: accepted gnome-online-accounts-gtk [armhf] (noble-proposed) [3.50.1-0ubuntu1]
[20:04] -queuebot:#ubuntu-release- New: accepted gnome-online-accounts-gtk [arm64] (noble-proposed) [3.50.1-0ubuntu1]
[20:04] -queuebot:#ubuntu-release- New: accepted gnome-online-accounts-gtk [ppc64el] (noble-proposed) [3.50.1-0ubuntu1]
[20:04] <sergiodj> taking ppp
[20:06] <sergiodj> I'll sync ppp from experimental.  it seems to fix the problem we're seeing in Ubuntu
[20:06] <sergiodj> s/sync/merge/
[20:09] <sil2100> python-wrapt is i386, skip
[20:09] <sil2100> Taking qm-dsp
[20:09] <doko> sergiodj: already fixed.
[20:09] <doko> sil2100: already fixed
[20:09] <sil2100> doko: thanks!
[20:09] <sergiodj> doko: ppp?
[20:09] <sil2100> Taking sdl-mixer1.2
[20:09] <doko> sil2100: already fixed
[20:10] <doko> sergiodj: yes
[20:10] <vorlon> sergiodj: woah. why do we need to get a sync from experimental to fix a problem with a no-change rebuild?
[20:10] <sergiodj> ah, I see, thanks
[20:10] <sil2100> doko: can you mark those already fixed somehow?
[20:10] <sil2100> Maybe create another list?
[20:10] <doko> how?
[20:10] <doko> sil2100: are you subscribed to noble-changes?
[20:10] <bryceh> ok policykit-1 needs a patch already in debian.  Could either be cherrypicked, or the new version merged.
[20:11] <doko> bryceh: already fixed
[20:11] <sil2100> ok, nvm then
[20:11] <bryceh> doko, oh?
[20:11] <sil2100> Taking thunderbird
[20:12] <doko> bryceh: https://launchpad.net/ubuntu/+source/policykit-1/124-2ubuntu1
[20:12] <sergiodj> taking vorbis-tools
[20:12] <doko> sergiodj: already fixed
[20:12] <sergiodj> hah
[20:12] <sergiodj> OK
[20:12] <sil2100> sergiodj: check noble-changes to see if package is fixed
[20:12] <bryceh> doko, alright
[20:12]  * bryceh --> lunch
[20:12] <sergiodj> alright, only sssd remains.  I'll have to get an armhf to debug that one
[20:14] <dbungert> here is a different sort of log, it shows packages that block other packages, presumably on ADT regressions.  It's a bit different than the previously posted autopkgtest log I did.
[20:14] <dbungert> https://paste.ubuntu.com/p/6TSDHt4g6N/
[20:14] <sil2100> I'll force thunderbird, the set of binaries built in -proposed = the ones in release (+ amd64 of course)
[20:14] <sergiodj> I know ahasenack_ is looking into sssd, so I'll defer to him
[20:18] -queuebot:#ubuntu-release- New: accepted rust-proc-macro-crate-1 [sync] (noble-proposed) [1.3.1-1]
[20:18] <ahasenack_> back
[20:21] <schopin> Alright, new list then :)
[20:21] <schopin> Looking into peony
[20:21] -queuebot:#ubuntu-release- New binary: rust-proc-macro-crate-1 [amd64] (noble-proposed/none) [1.3.1-1] (no packageset)
[20:22] <dbungert> I think there was one straggler from the last list, xsynth-dssi, unless someone has that
[20:23] <schopin> I think it's another case of removed i386 binary.
[20:24] <dbungert> nice.  I'll post an updated missingbuild log when this updates https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.yaml.xz
[20:24] <sergiodj> .xz!!
[20:24] <vorlon> yeah xsynth-dssi is done
[20:24] <sergiodj> ;)
[20:24] -queuebot:#ubuntu-release- New: accepted rust-proc-macro-crate-1 [amd64] (noble-proposed) [1.3.1-1]
[20:24] <schopin> peoni is waiting for riscv64 and s390x builds.
[20:25] <schopin> taking libplist
[20:27] <dbungert> schopin: I should be able to drop waiting/blocked items from the autopkgtest list, would that help?
[20:28] <schopin> I think waitdep could be of value, but those only waiting for builders should probably be dropped.
[20:29] -queuebot:#ubuntu-release- New binary: rust-proc-macro-crate-1 [arm64] (noble-proposed/none) [1.3.1-1] (no packageset)
[20:29] -queuebot:#ubuntu-release- New binary: rust-proc-macro-crate-1 [armhf] (noble-proposed/none) [1.3.1-1] (no packageset)
[20:30] -queuebot:#ubuntu-release- New binary: rust-proc-macro-crate-1 [ppc64el] (noble-proposed/none) [1.3.1-1] (no packageset)
[20:33] <mwhudson> vorlon, kanashiro: livecd-rootfs seems to be installable now https://launchpadlibrarian.net/723008228/buildlog_ubuntu_noble_amd64_test_BUILDING.txt.gz
[20:34] <vorlon> mwhudson: oh, hurray
[20:37] <schopin> do we just skiptest packages when the rdep tests fail because of badpkg?
[20:38] -queuebot:#ubuntu-release- New: accepted rust-proc-macro-crate-1 [arm64] (noble-proposed) [1.3.1-1]
[20:38] -queuebot:#ubuntu-release- New: accepted rust-proc-macro-crate-1 [ppc64el] (noble-proposed) [1.3.1-1]
[20:38] -queuebot:#ubuntu-release- New: accepted rust-proc-macro-crate-1 [armhf] (noble-proposed) [1.3.1-1]
[20:38] <schopin> Also, do we want to re-enable all-proposed?
[20:40] <kanashiro> mwhudson vorlon yay. It is not installable in the chroot I am running with the tarvall Steve gave me, but if it is working on LP that's good enough I guess
[20:41] <mwhudson> kanashiro: i had to remember to set up the preferences to allow it to install packages from -proposed but after that it appears to be installable locally
[20:42] <kanashiro> Yeah, I installed it fine in a lxd container and I think it was configured that way
[20:42] <vorlon> schopin: I wouldn't say that we should categorically skiptest rdep failures.  I'd like to see what things look like after we properly requeue running tests without duplicates; any retries of failed tests are going to end up queued behind those anyway...
[20:42] <vorlon> schopin: (and the only tests I'm requeuing are precisely those that block seeded packages)
[20:47] <schopin> libsmf can be skiptest, the denemo tests passed with the new version installed (the runner gave up with pinning and enabled all proposed)
[20:48] <doko> vorlon: libphonenumber had dependencies on the removed libabsl20230802, blocking libreoffice. please could you check on other deps on libabsl20230802? I'm afk now
[20:52] <ahasenack_> is "do-release-upgrade -d" from mantic to noble blocked, perhaps by accident due to the current state of affairs?
[20:53] <bdmurray> Not by accident
[20:53] <ahasenack_> ok, so since canonistack has no noble images, just mantic... no arm64 in canonistack for me
[20:53] <mwhudson> well you can always edit sources.list
[20:53] <ahasenack_> noble arm64, that is
[20:54] <bdmurray> After juliank's emails and the flux in the archive due to xz-utils we disabled dist-upgrades
[20:54] <mwhudson> with a freshly booted mantic that should work
[20:54] <bdmurray> also yes, remember the old ways
[20:54] <ahasenack_> mwhudson: ok, will try that
[20:57] <vpa1977> I have launched canonistack mantic and then ubuntu-daily:noble lxc container
[20:58] <ahasenack_> ah, indeed, I think I don't need the noble kernel for these tests
[21:02] <doko> vorlon, mwhudson, vpa1977: please after kbookmarks is available on riscv64, retry kdeclarative, then when this is available, retry haruna and libreoffice
[21:02] <doko> now really afk
[21:03] <mwhudson> doko: ak
[21:07] <athos> jbicha: overlay-scrollbar ftbfs due to an implicit declaration introduced in a patch we carry in gtk+2.0 adding some ubuntu_* functions. Have you handled these ones in some specific fashion (supposing we saw the same issue somewhere else)?
[21:08] <jbicha> athos: I wasn't aware of that issue yet. I can add it to my plate though
[21:10] <dbungert> updated missingbuild log, https://paste.ubuntu.com/p/nDWDp3jJqv/   7 insertions(+), 85 deletions(-)
[21:11] <dbungert> no new packages, just build state changes on a few, and many disappeared so nice work
[21:14] <vorlon> schopin: so the problem with "opencolorio and openimagio need bootstrapping" is that I already bootstrapped them :| where did that go
[21:15] <athos> ack; thanks, let me know if you want me to file a bug or just declare those in that gtk+2.0 patch :)
[21:16] <athos> ack qm-dsp
[21:16] <athos> oh, it was taken :)
[21:19] <liushuyu> libcdio fix: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/libcdio/+git/libcdio/+merge/463629
[21:22] <liushuyu> For the new list: dep wait packages: cinnamon krita geary opencolorio
[21:25] <vpa1977> retried kdeclarative https://launchpad.net/ubuntu/+source/kdeclarative/5.115.0-0ubuntu5/+build/27974520
[21:27] <liushuyu> taking overlay-scrollbar
[21:29] <jbicha> liushuyu: I'm handling overlay-scrollbar
[21:29] <liushuyu> more recent build state table https://pastebin.ubuntu.com/p/Nhn8zwh7rH/
[21:29] <liushuyu> jbicha: ah sorry, I will find another one
[21:30] <jbicha> athos: I believe we want gtk+2.0 to migrate first before doing another upload. I suggest we also remove overlay-scrollbar/armhf for now since it has no rdepends, only 1 reverse recommends
[21:33] <vpa1977> jbicha: same for gimp-plugin-registry? I have a fix now, but it will impact the migration.
[21:33] <sergiodj> btw, openldap/armhf is built
[21:34] <liushuyu> gnome-system-tools seems another GTK+ API change
[21:34] <liushuyu> should I hand this over to the desktop people?
[21:36] <liushuyu> It seems like we have cleared the current list
[21:36] <jbicha> vpa1977: gimp-plugin-registry also only have reverse recommends (& it has an autopkgtest) so yes I suggest it be removed on armhf for today
[21:37] <jbicha> gst good has passed its build tests now
[21:39] <jbicha> vpa1977: you can take gnome-system-tools if you want. I have enough for today and it's not a desktop owned package
[21:39] <vpa1977> jbicha: ack
[21:54] <cpete> unexpected afk. Back now. nas looks good.
[21:55] <cpete> liushuyu: >cleared the list. are we on to missing builds then?
[21:55] <vorlon> schopin: opencolorio reuploaded to https://launchpad.net/~canonical-foundations/+archive/ubuntu/archive-bootstrap/+packages
[21:58] <vorlon> doko: I don't see any other revdeps of libabsl20230802
[21:58] <ahasenack_> vpa1977: that lxd trick didn't work in canonistack :/
[21:58] <ahasenack_> $ lxc launch ubuntu-daily:noble/armhf n-armhf
[21:58] <ahasenack_> Creating n-armhf
[21:58] <ahasenack_> Error: Failed instance creation: Failed creating instance record: Requested architecture isn't supported by this host
[21:59] <liushuyu> cpete: the list was about missing builds, all of the items are now either held by someone in this channel for further investigation or already done
[21:59] <ahasenack_> oh, wait a sec
[21:59] <cpete> liushuyu: ack thanks
[22:05] <lvoytek> solved the issue with thin-provisioning-tools, I'll upload the fix
[22:08] <vorlon> ahasenack_: ... on arm64?
[22:09] <ahasenack_> no, that was the mistake. Bitten by shell history, I thought I was just trying again to launch the arm64 instance that had failed before, but I actually launched ppc64el
[22:09] <vorlon> :)
[22:09] <mwhudson> heh
[22:20] <jbicha> gtk+2.0 is staged for upload after proposed gtk+2.0 migrates to fix overlay-scrollbar/armhf build
[22:21] <liushuyu> jbicha: It's very strange that the -Werror is only triggered on armhf (the same warnings are also present on other architectures)
[22:21] <vorlon> hmm why was rasqal on the latest list, I thought I hinted it for i386
[22:22] <vorlon> oh, no, I tried to use a 'forec' hint
[22:23] <vorlon> I don't see anyone mentioning they were looking at caja-extensions?
[22:23] <jbicha> liushuyu: that's intentional to try to limit how much work we have to do right now. it will be an error on all architectures for 24.10 and already is for Debian Unstable
[22:24] <liushuyu> jbicha: I see
[22:24] <vorlon> caja-extensions fixed in Debian, looking at a sync
[22:25] <vorlon> doko already did without mentioning, ok
[22:27] <liushuyu> vorlon: so all that we can do is to wait at the moment?
[22:28] <vorlon> kicking off image builds for all flavors so we can possibly get some interesting build logs
[22:28] <vorlon> liushuyu: I don't know
[22:28] <vorlon> I don't have a big picture view at the moment to say what can or can't be dune
[22:28] <vorlon> done
[22:29] <vorlon> the last list from dbungert is 2 hours old :)
[22:29] <vorlon> wait no 1 hour old
[22:29] <dbungert> right, I updated shortly after the new update_excuses was available
[22:29] <dbungert> the missingbuild log looks pretty good, people here took action on the entire list
[22:31] <vorlon> dbungert: does that mean everything else that's blocked is blocked by tests, not by missing builds?
[22:32] <dbungert> vorlon: for the missingbuilds log, I only reported if there were missing builds on things other than risc-v or s390x.
[22:32] <dbungert> I can remove that filter but the result is probably many cases of waiting for those two arches.
[22:32] <vorlon> dbungert: well I'd like to see that list, s390x is not slow and I can bump build priorities
[22:33] <vorlon> mwhudson: so there may have been one livefs build that got past livecd-rootfs uninstallability but not this one? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/noble/ubuntukylin/+build/600290
[22:33] <vorlon> mwhudson: were you building with -proposed
[22:33] <mwhudson> oh maybe i wasn't
[22:33] <vorlon> mwhudson: well I'm wondering if -proposed is what made your build *work*
[22:33] <jbicha> vorlon: please remove gtk-sharp3 & gbrainy on armhf; they were removed last week for time_t . I have gtk-sharp3 on my todo list for tomorrow
[22:34] <mwhudson> vorlon: oh
[22:34] <mwhudson> vorlon: no proposed here https://launchpad.net/~mwhudson/+livefs/ubuntu/noble/test/+build/600274
[22:34] <liushuyu> according to LP stats, arm64 has a backlog of 935 jobs; armhf 450 jobs; ppc64el 24 jobs; riscv64 1421 jobs; s390x 1600 jobs
[22:34] <mwhudson> there was a ppa enabled though
[22:34] <jbicha> vorlon: please remove overlay-scrollbar/armhf & gimp-plugin-registry/armhf as discussed here
[22:34] <vorlon> jbicha: removed last week from where?
[22:34] <mwhudson> don't think it took any packages from there though
[22:34] <jbicha> vorlon: removed from noble/universe (release)
[22:35] <dbungert> vorlon: https://paste.ubuntu.com/p/zgkBwkCbNk/ - missingbuild log with the risc-v / s390x arch filtering removed
[22:35] <jbicha> vorlon: oops I misread. But could you remove them?
[22:37] <vorlon> jbicha: well gbrainy/armhf is already removed from noble, it grew back in noble-updates and is built in noble-proposed; but yes I'll remove gtk-sharp3 since it has no other revdeps
[22:39] <vorlon> jbicha: didn't I remove gimp-plugin-registry once before?
[22:39] <vorlon> jbicha: I did - that's another case of it growing back in noble-updates. so needs a hint rather than a removal; doing
[22:39] <mwhudson> vorlon: well i don't know what's going on. https://launchpad.net/~mwhudson/+livefs/ubuntu/noble/test/+build/600274 says "pocket release" the build log is clearly looking at updates and proposed
[22:41] <mwhudson> vorlon: if i restrict my local chroot to release only i get a failure like the one in that build log
[22:41] <vorlon> mwhudson: possibly related to the configuration of the ppa you're building in?
[22:41] <vorlon> if your devirt ppa says 'depends on proposed' that probably does it
[22:41] <mwhudson> it does
[22:41] <mwhudson> but i am still a bit surprised that would make the difference
[22:42] <vorlon> well I expect livecd-rootfs to be installable with -proposed enabled
[22:42] <vorlon> given that we've already rebuilt ~everything
[22:43] <mwhudson> so the question i guess is which packages does livecd-rootfs depend on that are not on images
[22:43] <mwhudson> like one of the issues is wget, but that's seeded
[22:44] <mwhudson> gnupg2 might be one of the interesting ones?
[22:44] <mwhudson> ah no gnupg is seeded
[22:44] <vorlon> maybe there's random perl modules
[22:44] <vorlon> debhelper showed up in the list?
[22:46] <mwhudson> it does?
[22:46] <mwhudson> i can't see any dependencies not covered by other work in a few minutes of poking
[22:47] <vorlon> oh sorry, debootstrap not debhelper
[22:47] <mwhudson> deboostrap is because wget
[22:47] <mwhudson> +t as usual
[22:48] <kanashiro> maybe devscripts' dependencies?
[22:48] <kanashiro> there are some perl modules
[22:49] <mwhudson> kanashiro: it's only complaining about gnupg{,2} and python3:any
[22:49] <kanashiro> FWIW this was the installability error I was getting when trying to install livecd-rootfs: https://paste.ubuntu.com/p/MnWv73bJxN/
[22:53] <vorlon> hmmm why did initramfs-tools not end up in my skiptest hint list
[22:54] <vorlon> because a bug means it doesn't handle multi-digit extensions sigh
[22:55] <kanashiro> mwhudson is there a way to check the logs of the error you are seeing? I am not proficient regarding image building but I can try to help/spot something
[22:55] <vpa1977> fixed gnome-system-tools - will upload after testing ppa build
[22:56] <vorlon> ok more skiptest hints incoming (wget is already skiptested)
[22:57] <vorlon> +force-skiptest activity-log-manager/0.9.7-0ubuntu31
[22:59] <kanashiro> are you guys still using this list? https://paste.ubuntu.com/p/fTBTWsTBnD/
[22:59] <kanashiro> is there an order to pick packages?
[22:59]  * vpa1977 afk lunch
[22:59] <cpete> vorlon, dbungert: So is there anything I can do right now to help with xz related rebuild things?
[23:00] <cpete> I think the list has been cleared
[23:01] <dbungert> cpete: So here is a missingbuild log that added builds only missing on risc-v / s390x.  It's bound to be very noisy but there may be some real things in there.  https://paste.ubuntu.com/p/zgkBwkCbNk/
[23:02] <kanashiro> cpete thanks for the info (and good news :)
[23:05] <dbungert> cpete: I also have this log of test regressions that could be analyzed.  I'm still iterating on that log to see if I can filter for more interesting things   https://paste.ubuntu.com/p/fyKKh92r7s/
[23:11] <cpete> dbungert: Thanks for the lists. I'll start combing through.
[23:19] <kanashiro> I am going through the first list and so far I think just folks can be fixed (failing everywhere)
[23:19] <kanashiro> but I recall someone looking at it earlier today, not sure about the outcome
[23:20] <cpete> Looking at the same list. I think calamares-settings-ubuntu needs a rebuild on riscv64
[23:20] <kanashiro> most of the packages are waiting for build on s390x and riscv64
[23:21] <dbungert> kanashiro: yes, that's expected in this more recent list.  The one I posted earlier had those filtered out, where it seemed to be just waiting for s390x/riscv64.
[23:22] <wgrant> Ugh sorry, power failure overnight killed my libkf* rescoring loop, but should be making progress again now.
[23:29] <kanashiro> cpete not sure if someone triggered the rebuild of calamares-settings-ubuntu on riscv64 but it is already in the queue
[23:30] <kanashiro> I triggered some rebuilds on riscv64 which seem to be solved already
[23:30] <cpete> kanashiro: must've, I see it queued now! thanks for the bump
[23:31] <kanashiro> cpete if you need something feel free to ping me, I'll be working a bit more tonight
[23:32] <cpete> kanashiro: Thanks! Will do. I have couple hours left in my day still
[23:42] <mwhudson> kanashiro: i have just beem mutating the sources.list in the noble chroot and running "chroot . apt-get install --dry-run $foo"
[23:42] <kanashiro> I went through the list and apparently what requires more attention is folks and opencv which are failing in all arches
[23:42] <mwhudson> kanashiro: i thought someone uploaded an "ignore the test results" version of folks?
[23:43] <mwhudson> yeah https://launchpad.net/ubuntu/+source/folks/0.15.9-1ubuntu5
[23:43] <sergiodj> mwhudson: I did
[23:43] <sergiodj> opencv is also fixed, btw
[23:43] <mwhudson> opencv is bulding
[23:43] <kanashiro> ah ok :) the report did not catch that yet
[23:44] <kanashiro> so I think we just need time to make it all build
[23:44] <sergiodj> the list is pretty much done.  they're now working on another list which refers to autopkgtest problems
[23:44] <kanashiro> mwhudson I'll try to reproduce that in a chroot
[23:45] <kanashiro> sergiodj do you mean this list? https://paste.ubuntu.com/p/fyKKh92r7s/
[23:45] <sergiodj> kanashiro: yes, I think that's the last version of it
[23:46] <cpete> that looks right. I've been going through the first list but I think Kanashiro's analysis is correct. just waiting on builds for those packages
[23:46] <kanashiro> it was good to make another pass in the first list because I found some build failures on riscv64 which required a rebuild
[23:47] <kanashiro> well, I am going to have dinner now and then get back to this
[23:47] <sergiodj> me too
[23:52] <vorlon> dbungert: https://paste.ubuntu.com/p/zgkBwkCbNk/ generated right before update_excuses published again
[23:52] <dbungert> sure, I'll redo both versions
[23:55] <dbungert> missingbuild with riscv64 / s390x hide_arches https://paste.ubuntu.com/p/dZTF4sN2V9/
[23:55] <dbungert> without https://paste.ubuntu.com/p/Kggk7HvBdJ/
[23:55] <vorlon> btw initramfs-tools and gnupg2 both got picked up in the new list for skiptesting so maybe livecd-rootfs will be clear after this
[23:56] <dbungert> awesome
[23:56] <vorlon> dbungert: hmm that still looks out of date, alsa-plugins was in particular the one I noticed was no longer missing a build
[23:56] <dbungert> err, I had old data
[23:56] <dbungert> yea
[23:58] <dbungert> correction: hide arches https://paste.ubuntu.com/p/tmfydV9SSs/
[23:58] <dbungert> no hide arches https://paste.ubuntu.com/p/H8dDpTvFRN/


[14:24] <noodles775> jtv: why are you doing slave_status.get('filemap'), rather than get('filemap', None)?
[14:25] <jtv> noodles775: what would that do for me?
[14:25] <noodles775> That's where I'm confused - I can see from your test that it works when filemap is not present as a key...
[14:26] <noodles775> jtv: nm...
[14:26] <jtv> noodles775: to make sure I understand you correctly...  you're just talking about passing a second parameter to dict.get, right?
[14:26] <noodles775> None is the default...
[14:26] <noodles775> r=me
[14:28] <jtv> noodles775: thanks
[14:28]  * noodles775 goes back to hacking at UDS.
[20:01] <rockstar> sinzui, can I get you to review the Branches->Code change?
[20:01] <rockstar> https://code.edge.launchpad.net/~rockstar/launchpad/branches-code/+merge/25249
[20:02] <sinzui> yes
[20:03] <rockstar> sinzui, fank you.
[20:04] <sinzui> rockstar, I pondered the tooltips in the app menu several times
[20:05] <sinzui> rockstar, summary = 'The Code Bazaar' vs 'View related code'. look to be different messages for the samething
[20:06] <sinzui> I doubt there are any tests for the summary because our toolstips are often missing or contradictory
[20:06] <rockstar> sinzui, "The Code Bazaar" was for code.launchpad.net itself I thought.
[20:07] <rockstar> So "View related code" for no context doesn't make sense.
[20:10] <sinzui> rockstar, can project have recipes?
[20:10] <rockstar> sinzui, project can't, but product can (and does)
[20:10] <rockstar> sinzui, project may, in the future, but I can't see a sane use case for it.
[20:10] <sinzui> lib/lp/registry/browser/product.py's summary says branches
[20:11] <sinzui> Do you want to revise it to 'code', add 'recipes', or ignore it
[20:11] <rockstar> sinzui, probably ignore it for now.
[20:12] <rockstar> sinzui, frankly, I didn't even know there WERE summaries until I saw the code.
[20:12] <rockstar> I think the purpose of the tabs is that they shouldn't need explanation...
[20:12] <sinzui> rockstar, bug 211117
[20:12] <mup> Bug #211117: Tooltips on sections don't always show <ui> <launchpad-web:Triaged> <https://launchpad.net/bugs/211117>
[20:13] <sinzui> We should have summaries for every case, and they should help the user, not confuse him
[20:14] <sinzui> rockstar, This bug keeps appear when I listen to user complaints. I have not been able to scope it. I do not know all the places that summaries are missing or wrong
[20:15] <rockstar> sinzui, yeah, working on the tab stuff, I see why that could be.
[20:15] <sinzui> You have an opportunity to fix a few. As I said, you could say "Get Nutella crepes at the bazaar" in everyone and no test will break, but at least they will all be consistent.
[20:15] <rockstar> sinzui, truthfully, I think there was a lot of duplication of code for cases where we only wanted to change a summary for a tab or link to another subdomain.
[20:15] <rockstar> sinzui, okay, I'm happy to fix those.
[20:16] <sinzui> r=me. what you have is fine to land. if you see a summary you want to fix, go ahead
[20:22] <rockstar> sinzui, okay, I'll see if I can fix it.
[21:26] <thumper> rockstar:  I don't like "The Code Bazaar"
[21:26] <thumper> too esoteric
[21:26] <rockstar> thumper, I don't either.
[22:21] <thumper> rockstar: aye
[22:55] <wgrant> rockstar: Hm, why was I dropped from the queue?
[23:15] <rockstar> wgrant, because the queue is something managed by the OCR, not by people needing reviews.
[23:16] <rockstar> wgrant, I've been a stickler about it, and reminded everyone a few weeks back in the reviewer meeting that OCR does not mean "review lackey"  It is the reviewee's job to get a review, not the reviewer's job to just take an existing queue and do it.
[23:25] <wgrant> rockstar: Perhaps the documentation is lacking.
[23:25] <wgrant> I cannot find a definition of how OCR works.
[23:40] <rockstar> wgrant, well, it's mostly a social definition, but one that we've been lacking in letting other people know about.
[23:41] <rockstar> wgrant, basically, it's just polite to say things like "Can I get into your queue?"
[23:41] <rockstar> wgrant, basically, it's not the job of the reviewer to go find reviews.  It's the job of the reviewee to find someone to do the review, regardless of whether they use the on call reviewer or not.
[23:42] <wgrant> rockstar: Yeah, I normally try to do that, except it often fails because there are no reviewers near my timezone (or in this case there was no EU reviewer, and I was at dinner when you appeared)
[23:44] <rockstar> wgrant, yeah, I understand that.  I'm kinda being a pedant specifically to make the point that reviewees don't just say "Review my patch, bitch!" and it's gets reviewed.  :)


[00:26] <Frederick> hello folks is anyhone around?
[00:26] <Corey> A few of us.  Most are not.
[00:26] <rww> Frederick: howdy
[00:28] <rww> Frederick: something we can help you with?
[00:29] <Frederick> rww: Ive been banned from the main chan
[00:29] <Frederick> I wonder if I can be re-admited
[00:29] <rww> Frederick: why were you banned?
[00:30] <Frederick> rww: I asked from help to get a ubuntu lappy connected to the ethernet but as it was a bit customized (and I was naive to comment it) a operator said it was unsuported and I should leave I tried to talk to other people and got banned. But it should be appended to my account you should be able to see the reason.
[00:31] <rww> Frederick: I can, I was asking to get your point of view on it :)
[00:32] <Frederick> rww: I'm sad about it I really have a problem with that box and that is serious bussiness
[00:32] <Corey> Frederick: If the box is unsupported, it's unsupported.
[00:32] <Corey> Ask the question elsewhere?
[00:32] <Frederick> Corey: I could ask at #linux people ther would be friendlier thou my box is ubuntu with some custom packages
[00:33] <rww> Frederick: here's the issue as I see it, looking at the channel logs from the incident. #ubuntu is very strictly for technical support with Ubuntu (as in the operating system we distribute ourselves) and certain recognized derivatives. Other derivatives, like the one it sounds like you're using, we can't support because we don't know what changes they make.
[00:34] <rww> If I were using such a derivatives, I'd pop in an Ubuntu liveCD and try to reproduce the problem, then ask in #ubuntu if I can
[00:34] <Frederick> rww: they change the initial package set
[00:34] <Frederick> rww: but my issue was 99% something trivial
[00:34] <rww> Frederick: so it consists entirely of Ubuntu packages and the only difference is which are installed (from Ubuntu's repositories) by default?
[00:35] <rww> no configuration changes or anything like that?
[00:35] <rww> and yeah, it may seem trivial, but we have to draw the line somewhere, and "we don't ship it, so we don't support it" is that line
[00:37] <Frederick> rww: man I work for a very big company and I use ssl to get access to a very confidential system and I coukdl not manage that to work im using a vmware box now but I was really confident I could use ubuntu as my safe lappy
[00:37] <Frederick> rww: no config changes afaik
[00:37] <rww> Frederick: and there's the issue. You don't know what changes were made, and we don't know what changes were made, and neither of us have any idea if that's relevant to your problem. Hence what jrib said, put in a LiveCD and try to replicate the issue.
[00:38] <rww> and if an Ubuntu LiveCD has the same issue, then feel free to ask in #ubuntu (once we get this ban sorted out), but otherwise it's not really fair to ask us to support something that neither of us understand the details of
[00:38] <Frederick> rww: trying to do it right now on vmware
[00:39] <rww> Alrighty. If I unban you from #ubuntu, do you promise to follow that procedure (loading up an actual upstream Ubuntu instance and troubleshooting on there) when asking for help?
[00:39] <Frederick> sure
[00:40] <rww> Okay. I've removed your ban. Please try /join #ubuntu to make sure it was removed properly.
[00:41] <Frederick> thank you
[00:42] <rww> Welcome. Thanks for understanding :). (Once you're all sorted, please /part #ubuntu-ops so that we can keep track of whether people still need op assistance.)
[00:46] <Corey> rww: Nice job.
[00:46] <phillw> text book... I may copy that and use it as teaching notes.
[00:47] <rww> @mark #ubuntu-ops Frederick removed ban, user promised to check with Ubuntu LiveCD before asking for help in #ubuntu as a condition of unbanning
[00:49] <phillw> btw, what is the command to look at the ban list on a channel?
[00:49] <rww> phillw: /mode #channelname b
[00:50] <phillw> (01:49:42) End of ban list ... didn't think we had any active bans in place.
[00:52] <phillw> sort of half looking forward to becomming official and our 1st trolls land. all I can say is may the Lord have mercy upon the 1st troll... the rotweilers have dressed up nicely in puppy clothes :P
[02:54] <h00k> !away > mrono
[03:20] <bioterror> http://termite.apcdn.com/full/45571.gif
[03:20] <h00k> bioterror: can we help you?
[03:21] <h00k> Unit193: can we help you?
[03:21] <Unit193> h00k: I've been told to join as I'm an Lubuntu op
[03:21] <IdleOne> bioterror: are you serious?
[03:21] <h00k> Unit193: cool. Hi.
[03:21] <Unit193> Hello!
[03:21] <h00k> bioterror: if you don't have anything in here, please /part as we have a no-idle policy.
[03:22] <Unit193> He's also an op
[03:22] <bioterror> oh, sorry. wrong window it was
[03:22] <IdleOne> Who told you to join?
[03:23] <h00k> bioterror: be sure to check where you're posting things, especially as an op.
[03:23] <IdleOne> afaik #lubuntu is not yet a core channel. core channel ops are invited here by the IRCC.
[03:24] <Flannel> IdleOne: I imagine there was confusion about that given today's email thread
[03:25] <IdleOne> am I missing a subscription?
[03:25] <rww> IdleOne: ubuntu-irc was discussing the IRCC meeting agenda today
[03:25] <rww> but yes, #lubuntu is not yet a core channel and unless someone on IRCC has stated otherwise without telling the IRC Team, #lubuntu ops should not be in here
[03:26] <phillw> rww, then I will send out YET another email telling them all to leave :(
[03:26] <rww> or rather, "#lubuntu ops in here are valid targets for the idle policy, which rww only enforces on random days and leaves to discretion of other ops otherwise", but it probably ends up meaning the same thing
[03:26] <phillw> bioterror: please /part... I will be following
[03:27] <Unit193> Will do!
[04:52] <Myrtti> M0hi: hi
[04:52] <M0hi> hey Myrtti
[04:52] <Myrtti> how can we help?
[04:53] <rww> the email you received was in error, please don't idle in #ubuntu-ops unless and until #lubuntu is made a core channel, thanks
[04:54] <M0hi> rww: thanks
[04:54] <M0hi> bye all
[05:01] <tsimpson> Pici: ubottu won't reply to people it doesn't share channels with mostly because it (Encyclopedia) doesn't send any messages to people it doesn't share channels with. mostly to stop people abusing the bot to send messages to random people etc
[05:33] <Myrtti> meh
[09:47] <ikonia> hello head_victim
[09:49] <elky> head_victim, hey, if you're here because of phill's mail earlier, he's jumped the gun a little bit. the lubuntu stuff is still in discussion phase, nothing's been decided yet.
[09:52] <LjL> ikonia: do you know for sure it's illegal to use a proxy that bypasses the "security" whatever backwards country he lives in enforces?
[09:52] <LjL> if not, i don't think you should stop him from asking
[09:52] <head_victim> elky: ahh ok, and gday ikonia
[09:52] <ikonia> LjL: not at all, but he's telling me that country is blocking his use of TOR, therefore bypassing that isn't something we should support
[09:52] <ikonia> LjL: wasn't suggesting it was illegal, just not something we should be doing
[09:52] <LjL> why?
[09:52] <ikonia> same way I wouldn't help somone get around their work firewall
[09:53] <ikonia> LjL: because the official ubuntu channel shouldn't be helping users bypass restrictions by their ISP/Company/whatever
[09:53] <LjL> well you don't have to help, but i disagree it shouldn't be supported
[09:53] <LjL> the official ubuntu channels frowns upon illegal things
[09:53] <ikonia> I don't think it's something an official channel should be doing, and something that's always been non-challanged
[09:53] <LjL> if it's not illegal, why should it be forbidden
[09:53] <LjL> it's been challenged by me a number of times
[09:54] <ikonia> LjL: if you are blocked from doing something, is circumventing it in line with the intention of the project /
[09:54] <ikonia> LjL: apologies, I've never seen it challanged before
[09:54] <LjL> !dvde
[09:54] <LjL> !dvd
[09:54] <LjL> feel free to remove that factoid?
[09:54] <ikonia> LjL: if you feel it goes against it, please do
[09:55] <LjL> i feel it goes against what you think shouldn't be allowed in #ubuntu, the only difference is that i don't think it shouldn't be allowed
[09:55] <ikonia> LjL: if you feel strongly about it, lets sort it out with the team
[09:55] <LjL> and honestly i don't see that many people other than you insisting so much on things that may remotely be illegal but probably not
[09:56] <ikonia> I'm not interested if it's legal or not
[09:56] <ikonia> if your ISP puts a block on that, we should not be helping bypass it
[09:56] <ikonia> you have a choice of accepting that, getting help from somewhere else or changing ISP
[09:57] <LjL> just show me the rule that says that
[09:57] <ikonia> there isn't one, there aren't specifc rules
[09:57] <LjL> if there is not a rule, then you're free to use your common sense to decide whether or not to help people with that
[09:57] <LjL> but you shouldn't say that nobody is allowed
[09:58] <ikonia> sorry, no
[09:58] <ikonia> bypassing restrictions
[09:58] <ikonia> that's not something I believe we should be allowing in the official channel, I'd be happy to discuss it with the group to get clarification.
[09:58] <ikonia> if you want to help him, feel free to pm him
[09:59] <ikonia> sorry, that wasn't meant to sound condencending
[09:59] <LjL> i'll do something else
[09:59] <ikonia> LjL: that's uncalled for
[11:38] <elky> hi AtomicSpark.  We do not tolerate racism.
[11:41] <elky> Is that clear, AtomicSpark?
[11:41] <AtomicSpark> Yes.
[11:44] <elky> Ok, then you may leave here.
[11:51] <elky> @mark AtomicSpark Regarding "<AtomicSpark> Naw, he sounds pretty white. The fact that even if he used words correctly, he'd still be wrong, makes me think he's just dumb." has agreed that it is clear to him that veiled racism isn't permitted
[13:47] <nyuszika7h> Sorry for my previous edit request, it was by accident..
[13:48] <nyuszika7h> I forgot that ' !command' is also parsed by ubottu.
[13:50] <macer1> I just wanted to cancel edit request about !macer1: I was just testing.
[13:57] <ikonia> no problem
[13:59] <macer1> Can I have a factoid about me that will be saying about my launchpad profile and wiki page?
[14:02] <knome> no
[14:02] <macer1> why?
[14:02] <Pici> We don't do personal factoids.
[14:03] <Pici> 'vanity' factoids.
[14:04] <macer1> "ubuntu members" can't have it too?
[14:17] <ikonia> macer1: sorry, no-one does
[14:17] <macer1> ok, I understand
[14:17] <ikonia> thanks
[14:17] <macer1> Maybe some new feauture like...!launchpad user?
[14:18] <ikonia> no
[14:20] <macer1> :(
[14:20] <macer1> ok
[14:20] <ikonia> thanks.
[14:22] <macer1> btw, what are requirements to become op of #ubuntu channels?
[14:22] <Pici> !canibeanop
[14:23] <macer1> thanks for links, I will look at it :)
[14:25] <macer1> oh
[14:25] <macer1> first link is dead
[14:25] <Pici> topyli: your website is dead.
[14:25] <macer1> thank you google for google cache ;D
[15:25] <ikonia> jrib: that makes total sense that "compname" would = username, rather than computer name?????
[15:31] <ikonia> false
[15:32] <jrib> nice...
[15:34] <Myrtti> macer1: hiya
[15:34] <macer1> Myrtti, hi
[15:36] <Myrtti> macer1: was there anything else we could help with, or is there anything unfinished?
[15:37] <macer1> I think everything is finished ;)
[15:38] <Myrtti> ok, have a nice evening then :-)
[15:38] <macer1> Myrtti, thanks :)
[15:47] <ikonia> macer1: there is a no-idle policy in this channel, which means if you don't need anything else, we ask that you leave the channel so that others needing assistance are free to recieve it
[15:47] <macer1> ikonia, ok
[15:47] <ikonia> thanks
[15:48] <macer1> I was hoping to watch what is going on here...
[15:48] <ikonia> sorry, that's not something we allow at this time
[15:48] <Myrtti> !logs
[15:50] <macer1> ok
[15:50] <macer1> so I am leaving...
[15:50] <macer1> bye
[16:33] <ikonia> Monotoko: hello, how can we help you today ?
[16:33] <Monotoko> hey guys! I did something stupid about a week ago while playing with scripts in mIRC (pasted a bash.org quote in a lot of channels) and I got banned from #ubuntu
[16:33] <Monotoko> I accepted the ban, but I'm just wondering when I can go back in...?
[16:33] <ikonia> Monotoko: can you give me a minute please.
[16:33] <Monotoko> sure
[16:34] <ikonia> Monotoko: it will just take a few moment to grab the info I need
[16:35] <Monotoko> sure I can wait :)
[16:36] <ikonia> I don't believe that was a bash quote
[16:36] <ikonia> I believe that was you just trying to get people to close their terminal windows
[16:37] <ikonia> I don't believe it was a script either
[16:37] <Monotoko> not a bash quote, a quote from bash.org
[16:37] <ikonia> I don't believe a quote from bash.org
[16:37] <Monotoko> it's a site with a lot of funny IRC quotes
[16:37] <ikonia> and even if it was, I don't believe it was a script, as you joined and it was the first thing you said
[16:37] <ikonia> that's my personal opinion.
[16:38] <Monotoko> I connect through a BNC, I just started it up but okay...then how long is the ban for?
[16:38] <ikonia> the fact that you used your nickname to "help" the quote be funny suggests you knew exactly what you where doing
[16:38] <ikonia> the quote was "have just encounted a fatal error...press alt+f4 to fix immediatly"
[16:38] <ikonia> you set your nickname to "you"
[16:39] <ikonia> so you could do "/me have just encounted a fatal error...press alt+f4"
[16:39] <ikonia> which would give you
[16:39] <ikonia> you have just encounted a fatal error...press alt+f4
[16:39] <Monotoko> yes, it was supposed to go into another channel that's the thing...I'm not denying that it came from me
[16:39] <ikonia> have just encounted a fatal error...press alt+f4
[16:39] <ikonia> which would look like a system error on screen
[16:40] <Monotoko> it just went into every channel I was in at the time (across about 15 networks...)
[16:40] <ikonia> it was supposed to go into one channel, but you managed to hit a whole lot from what I'm seeing
[16:40] <Monotoko> yeah...a script gone wrong, and I'm sorry about it
[16:40] <ikonia> ok, so if I remove the ban now, which I'm happy to do
[16:41] <ikonia> you can assure me you will not run any scripts on the client that is connected to the ubuntu channel ?
[16:41] <Monotoko> that would be amazing, and I won't do anything like that again
[16:41] <ikonia> ok.
[16:41] <Monotoko> thank you :)
[16:42] <ikonia> ok, I've removed the ban, but please grow up and don't try to trick people into closing terminals.
[16:42] <Monotoko> will do, thank you again for removing the ban
[16:42] <ikonia> no problem.
[16:42] <ikonia> you're welcome to leave this channel and join #ubuntu
[16:42] <Monotoko> still unable to join...
[16:43] <ikonia> try again
[16:43] <Monotoko> I'm in :)
[16:43] <Monotoko> ty
[16:43] <ikonia> ok, great
[17:46] <Myrtti> this is getting old
[17:47] <ikonia> Pici: did I put a ban forward on that guy or did I mess it up
[17:47] <Pici> ikonia: different ip.
[17:48] <ikonia> so I see
[17:48] <ikonia><EMAIL_ADDRESS>[17:48] <ikonia> took me a while to find it
[19:48] <IdleOne> Lots of young people wanting to become ops/members for "vanity" reasons lately
[19:48] <IdleOne> I fear Ubuntu is going the way of Hollywood
[19:49] <oCean> Wait, there's an Ubuntu The Movie coming?
[19:49] <IdleOne> in 3D
[19:50] <oCean> Starring: All Your Fav Ops!
[20:51] <h00k> except this guy. I'll do sound and lighting.


[10:09] <bongmode> hello
[10:10] <bongmode> i got a little problem with my ubuntu gnome 14.04: i created a launcher with menulibre, then deleted the newly created 2nd internet application group and that was the moment my gnome desktop disappeared andd it also doesnt show up anymore on login
[10:11] <bongmode> im on terminal right now
[10:17] <CraHan> Time to change the channel topic? :)
[13:00] <majod> id like to customize the login screen in 14.04, change background, etc,...how can i do that?
[14:37] <majod> hi. i have some issues with fglrx drivers, have tearing when moving windows around...no problems with open source drivers...whats the problem?
[14:50] <ohUmbrella> Quick one - is it sane to update to 14.04 via the built-in manager?  I'm running on a VM and can back up the image, but was wondering if this tends to cause strange issues down the road
[14:59] <DASPRiD> majod, have you enabled vsync?
[15:00] <majod> DASPRiD: yes its "always on". however, tearing appears only on top part of screen. no tearing on rest of the screen
[15:02] <DASPRiD> mh, must be a driver bug then
[15:02] <majod> ok so how to solve
[15:02] <DASPRiD> http://www.reddit.com/r/linux/comments/1nl4t2/fglrxs_tearfree_desktop_feature/
[15:03] <DASPRiD> first google result ;)
[15:03] <majod> awesome. i read it alredy.
[15:03] <majod> ;)
[15:04] <DASPRiD> does it help?
[15:04] <majod> when i enable tear-free, the whole desktop is very laggy and slow
[15:04] <DASPRiD> well, did you disable vsync as suggested?
[15:04] <majod> ok, not "very", but theres noticable difference...but yes, the tearing disappears
[15:05] <DASPRiD> (vsync => always off)
[15:06] <majod> disabling vsync is even worse. tearing everywhere
[15:06] <DASPRiD> strange, they say that this solved it for many (tear free enabled and vsync disabled)
[15:08] <majod> for me the smoothest result is disabling tear free and enabling vsync. thats the best, the only con is tearing on top part of the screen, nowhere else
[15:10] <majod> im curious what happens in games. downloading dota, will see.
[15:12] <majod> oh also. i would like to reduce swap partition, i installed ubuntu with automatic partitioning and now i have 8GB swap partition. this calculations are absolutely ridiculous but whatever...is there any way how to cut 7GB from swap and put it to other partition?
[15:12] <DASPRiD> how much ram do you have?
[15:12] <majod> 8GB...
[15:12] <DASPRiD> well, you'd need 8gb for hibernation if you use that
[15:12] <majod> i dont
[15:13] <DASPRiD> i have disabled swap completely, but then i have 32gb…
[15:13] <majod> ok, that makes sense, i forgot that
[15:13] <majod> i didnt use swap on windows...i think it would be ok on ubuntu too, but ...just to be sure
[15:13] <DASPRiD> well, 8gb could still hit their limit with a vm or something
[15:13] <majod> i use VMs too :) but give them 4GB only
[15:14] <DASPRiD> you can change the partition size, although you'd have to do that frm a live system
[15:14] <majod> so its possible to take free space from one partition and assign it to another?
[15:14] <DASPRiD> sure
[15:14] <majod> awesome, thanks for help :)
[15:15] <DASPRiD> depending on where the partitions are located, some bytes may have to be shifted
[15:15] <majod> oh alright
[15:15] <DASPRiD> boot into live system and use gparted, should be pretty straight forward
[15:15] <majod> i have ubuntu gnome installatino on usb, is it possible from that?
[15:15] <DASPRiD> sure
[15:15] <majod> is gparted on there? because its not in installed OS
[15:16] <DASPRiD> nope, just sudo apt-get install gparted
[15:16] <majod> you can install on live usb? :O
[15:16] <DASPRiD> sure
[15:16] <DASPRiD> it's just not permanent
[15:16] <majod> hmm. amazing.
[15:16] <majod> gonna try dota now.
[15:16] <DASPRiD> http://stuff.dasprids.de/screenshots/2014/04/20/171656.png
[15:17] <DASPRiD> you'll have a dialog like that thre
[15:17] <majod> alright. i think ill figure it out once i see it
[15:17] <DASPRiD> great :)
[15:48] <majod> i had to remove fglrx. idk why its absolutely unusable. had 10fps in dota2...with open source drivers its 60...also desktop is much snappier
[15:48] <majod> too bad video hw acceleration is not working
[18:51] <BlitzHere> Okay, can anyone help me set up a samba share? I'm not sure how it works but I want to be able to access my home folder from both my phone and tablet
[18:52] <BlitzHere> I set the floder to share and samba is installed, but what are the Server host, user name and password that I have to enter on my mobile device?
[18:53] <DASPRiD> by default, your desktop user and pw
[18:53] <DASPRiD> and host ist the ip of your computer
[18:57] <BlitzHere> Ah, okay
[19:01] <BlitzHere> Odd, why does my router show two instances of my computer with two different mac addresses and two different IPs with DHCP leases expiring 4 seconds apart
[19:15] <BlitzHere> Ok, so, it turns out that ubuntu gave my router two different mac addresses and is connected simultaneously via ethernet cable and WiFi. Is this normal?
 Thanks, allowing anonymous logins worked. A bit insecure but should do the job for now, and my network is private anyway
[23:54] <MathCubes> Hello can anyone help me?