[00:09] <mwhudson> oh heh i wrote this too oops
[00:19] <mwhudson> vorlon: is there a more up to date version of https://people.canonical.com/~vorlon/armhf-time_t/ftp-override-map.txt for ubuntu somewhere?
[00:37] <vorlon> mwhudson: no
[00:38] <vorlon> sorry, that was being maintained as input to the ftp team specifically, and any variations from that would basically need to be looked at on a case-by-case basis at this point (e.g. is this a completely new soname with no revdeps yet in Ubuntu so we don't need to rename? is it an Ubuntu-specific package? etc)
[00:39] <vorlon> nuts, notest showing i386 again
[00:39] <vorlon> afk again
[00:39] <mwhudson> vorlon: yes fair enough
[00:54] <mwhudson> uh why is there no entry in Sources for sagemath??
[00:57] <mwhudson> uh i should probably try not to recreate britney here
[01:34] <vorlon> did you mean to ask "Why are we still shipping sagemath"? :)
[01:35] <vorlon> mwhudson: race condition vs a deletion by doko https://launchpad.net/ubuntu/+source/sagemath/+publishinghistory
[01:41] <vorlon> a little NBS cleanup for libcanberra, hopefully cinnamon will be a candidate now
[01:45] <mwhudson> vorlon: ah hah
[01:45] <mwhudson> ok i think i have uploaded all the packages with a build-dep that has been replaced in the t64 transition now
[01:46] <mwhudson> probably not maximally efficiently
[01:49] <vorlon> adsys/armhf deleted and it doesn't have a build-dep on sssd only a runtime dep and I'm not worrying about whether it comes back
[01:49] <vorlon> libsss-nss-idmap-dev staaaaaahp
[01:50] <vorlon> ok sssd armhf binaries on their way out
[02:38] <vorlon> ok well I did a no-change rebuild of cups-browsed locally and it fixed the segfault.  But the no-change rebuild in launchpad still segfaults...
[02:51] <vorlon> ah it's apparmor
[02:51] <vorlon> LP: #2058866
[02:51] -ubottu:#ubuntu-release- Launchpad bug 2058866 in cups-browsed (Ubuntu) "proposed-migration for cups-browsed 2.0.0-0ubuntu8" [Undecided, New] https://launchpad.net/bugs/2058866
[02:52] <vorlon> checking now if it's also reproducible in an amd64 container (since that's also an armhf difference)
[04:31] <mwhudson> something we can just remove https://bugs.launchpad.net/ubuntu/+source/threadscope/+bug/2058878
[04:31] -ubottu:#ubuntu-release- Launchpad bug 2058878 in threadscope (Ubuntu) "please remove threadscope from ubuntu" [Undecided, New]
[04:31] <mwhudson> ubuntu-archive: something we can just remove https://bugs.launchpad.net/ubuntu/+source/threadscope/+bug/2058878
[05:12] <RAOF> mwhudson: I know no-one seems to be caring much about it, but if you _do_ just relax the build depends, does it build?
[05:12] <mwhudson> RAOF: no idea
[05:15] <mwhudson> oh it only takes 2 mins to build, let's find out
[05:18] <mwhudson> RAOF: no
[05:18] <RAOF> Bam.
[05:18] <vorlon> rmadison knows ssreflect bins are removed on riscv64, why doesn't britney >:|
[05:18] <mwhudson> is there some kind of fashion for putting upper bounds on your deps in haskell?
[05:19] <vorlon> haskell generally uses ABI hashes in virtual packages, or do you mean build-deps?
[05:19] <mwhudson> build deps
[05:19] <vorlon> no idea
[05:19] <mwhudson> RAOF: if i remove the other build dep constraint it appears to build...
[05:21] <mwhudson> uploading
[05:21] <RAOF> Huh. I ask because it seems to have been in and out of testing quite a bit, but it _looks_ like the sort of package that might have a quiet userbase.
[05:23] <mwhudson> tpm2-abrmd fails because of open/open64 mocking games on armhf, probably sensible to skip tests there
[05:24] <mwhudson> (i'm about to have dinner though)
[05:25] <vorlon> skip tests, rather than remove armhf binaries from release pocket and fix later?
[07:19] <mwhudson> vorlon: well i don't know. strongswan is in the rdep chain
[07:25] <mwhudson> uploaded a version with tests skipped
[07:59] <vorlon> mwhudson: only as a test revdep
[08:03] <vorlon> britney seems stuck
[08:10] <vorlon> VM is being squirrely, rebooting
[08:16] <vorlon> back up, britney will start again
[08:26] <juliank> I ... should only show builds that actually affect the architecture, lots of arch: all only builds
[08:26] <juliank> For the new reverse-build-depends feature
[09:31] <schopin> sil2100: t64-related RM: LP: #2058912
[09:31] -ubottu:#ubuntu-release- Launchpad bug 2058912 in xwiimote (Ubuntu) "t64: please remove xwiimote and rdeps armhf binaries from noble" [Undecided, New] https://launchpad.net/bugs/2058912
[09:33] <schopin> sil2100: erf, nevermind, it seems they're already removed. juliank I pulled this from one of your report ( https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.reverse.txt ) would it be possible to amend it not to consider these cases?
[09:39] <sil2100> ...!
[09:40] <schopin> Sorry about that :) Live and learn
[09:46] <juliank> schopin: hmm
[09:48] <juliank> schopin: it's still there? xwiimote | 2-4                     | noble/universe          | source, amd64, arm64, armhf, ppc64el, riscv64, s390x
[09:50] <schopin> juliank: I didn't see the file in the "Package Files" section of LP so assumed it was gone, but now I see it?
[09:51] <schopin> Doing too many things at once :/
[10:11] <juliank> schopin: just use rmadison :)
[10:29] <juliank> ftr: amd64 queue is being cleaned up
[10:58] <juliank> ubuntu-archive: remove-package -a armhf -b osmo-bts osmo-pcu # leaf; ftbfs in armhf; blocking libosmoabis10 libosmocodec0 libosmocoding0 libosmocore19 libosmoctrl0 libosmogsm18 libosmotrau2 libosmovty9
[10:58] <juliank> Well I guess osmo-bts is currently in progress building but still we can drop it for now
[10:59] <juliank> global-ben.reversed.txt says: src:osmo-bts: libosmocoding0 - needs a sourceful upload anyhow
[11:00] <juliank> Removing it first makes the transition view easier though
[11:04] <zhsj> after the amd64 queue being cleaned up, is there script to requeue all the missing tests? i see packages being blocked from migration due to pending results on amd64, but no job is queued.
[11:05] <juliank> queue is being cleaned up be patient
[11:05] <juliank> zhsj: andersson1234 is requeuing the tests that were there
[11:05] <zhsj> ack
[11:05] <juliank> zhsj: some tests were purposefully dropped, so rerunning all would be bad
[11:14] <juliank> requeuing will take about 4 hours due to some process issues
[11:19] -queuebot:#ubuntu-release- New sync: piuparts (noble-proposed/primary) [1.4.1]
[11:19] -queuebot:#ubuntu-release- New: accepted piuparts [sync] (noble-proposed) [1.4.1]
[11:21] -queuebot:#ubuntu-release- New binary: piuparts [amd64] (noble-proposed/none) [1.4.1] (no packageset)
[11:22] -queuebot:#ubuntu-release- New binary: piuparts [arm64] (noble-proposed/none) [1.4.1] (no packageset)
[11:23] -queuebot:#ubuntu-release- New binary: piuparts [ppc64el] (noble-proposed/none) [1.4.1] (no packageset)
[11:23] -queuebot:#ubuntu-release- New binary: piuparts [armhf] (noble-proposed/none) [1.4.1] (no packageset)
[11:23] -queuebot:#ubuntu-release- New binary: piuparts [s390x] (noble-proposed/none) [1.4.1] (no packageset)
[11:25] <juliank> I got +q on #ubuntu-devel sigh
[11:29] -queuebot:#ubuntu-release- New: accepted piuparts [amd64] (noble-proposed) [1.4.1]
[11:29] -queuebot:#ubuntu-release- New: accepted piuparts [armhf] (noble-proposed) [1.4.1]
[11:30] -queuebot:#ubuntu-release- New: accepted piuparts [s390x] (noble-proposed) [1.4.1]
[11:30] -queuebot:#ubuntu-release- New: accepted piuparts [arm64] (noble-proposed) [1.4.1]
[11:30] -queuebot:#ubuntu-release- New: accepted piuparts [ppc64el] (noble-proposed) [1.4.1]
[11:39] <seb128> juliank, removed
[11:40] -queuebot:#ubuntu-release- New binary: piuparts [riscv64] (noble-proposed/none) [1.4.1] (no packageset)
[11:42] <juliank> seb128: ta
[12:14] -queuebot:#ubuntu-release- New: accepted piuparts [riscv64] (noble-proposed) [1.4.1]
[12:35] <doko> mwhudson: left a question in the threadscope removal bug
[13:26] <doko> juliank: your rustc uploads failed to build. do you know if we can remove some old versions?
[13:36] <juliank> doko: I do not know, we should ask our Rust person I suppose
[13:37] <juliank>   * rustc-1.74 build-depends on conflicting packages: libllvm17t64=1:17.0.6-9build2 vs libllvm17=1:17.0.6-5build1
[13:37] <juliank>     - chain 1: libllvm17t64:armhf (>= 1:17.0.2)
[13:38] <juliank>     - chain 2: rustc-1.73:armhf -> libllvm17:armhf
[13:38] <juliank> Oh god
[13:38] <juliank> So the rustc compilers build-depend on the older ones so they go bootstrap recursively
[13:39] <juliank> What about Ada?
[13:39] <juliank> 3 packages have unsat BDs
[13:39] <juliank> frog, libgnatcoll-bindings
[13:39] <juliank> oh that's just two
[13:39] <juliank> also we have nfs-ganesha build-depends on conflicting packages: liburcu8t64=0.14.0-3.1 vs liburcu8=0.14.0-3
[13:39] <juliank> I'll go look a bit
[13:40] <juliank> libucto5t64 needs rebuild against libticcutils8t64, curious
[13:41] <juliank> Somehow did not see that
[13:42] <juliank> global-ben doesn't see it
[13:43] <juliank> but the Ada ones, weird
[13:44] <juliank> Oh I guess those are provides
[13:46] <juliank> ok so libxmlada-unicode-dev needs a rebuild
[13:47] <juliank> ah wait wrong arch I look at
[13:47] <juliank> gnat-13-cab06c16 is old
[13:47] <juliank> gnat-13-2eaa09e6 is new
[13:52] <doko> juliank: yes, that should only be a armhf change
[13:52] <doko> libgnatcoll-bindings removed on armhf
[13:58] <juliank> ubuntu-archive: removal for pyfltk https://bugs.launchpad.net/ubuntu/+source/gl-image-display/+bug/2058932
[13:58] -ubottu:#ubuntu-release- Launchpad bug 2058932 in pyfltk (Ubuntu) "RM: pyfltk and rdeps, FTBFS" [Undecided, New]
[13:59] <juliank> doko: I did just upload no-change rebuild for libgnatcoll I believe it though
[14:00] <juliank> which promptly failed with gprbuild: raised CONSTRAINT_ERROR : a-calend.adb:371 overflow check failed
[14:00] <juliank> on armhf
[14:02] <adrien> I thought ada had a different time type with more constraints and range :/
[14:03] <juliank> heh
[14:10] -queuebot:#ubuntu-release- New source: nemos-dev-key (noble-proposed/primary) [1.7]
[14:10] -queuebot:#ubuntu-release- Unapproved: octavia (jammy-proposed/universe) [1:10.1.0-0ubuntu1 => 1:10.1.1-0ubuntu1] (openstack)
[14:14] <sil2100> juliank: on it
[14:15] <sil2100> juliank: I guess removing mrcal as well, right? Since it's a recommends
[14:16] <sil2100> And I suppose only the armhf binaries, right?
[14:16] <sil2100> Or do you want the whoel thing gone?
[14:18] -queuebot:#ubuntu-release- New binary: dante [amd64] (noble-proposed/universe) [1.4.2+dfsg-7.1~willsync1] (no packageset)
[14:19] -queuebot:#ubuntu-release- New binary: dante [arm64] (noble-proposed/universe) [1.4.2+dfsg-7.1~willsync1] (no packageset)
[14:19] -queuebot:#ubuntu-release- New binary: dante [s390x] (noble-proposed/universe) [1.4.2+dfsg-7.1~willsync1] (no packageset)
[14:19] -queuebot:#ubuntu-release- New binary: dante [ppc64el] (noble-proposed/universe) [1.4.2+dfsg-7.1~willsync1] (no packageset)
[14:20] -queuebot:#ubuntu-release- New: rejected nemos-dev-key [source] (noble-proposed) [1.7]
[14:21] -queuebot:#ubuntu-release- Unapproved: motion (mantic-proposed/universe) [4.5.1-3build1 => 4.5.1-3ubuntu0.1] (no packageset)
[14:22] <adrien> pyxplot is missing builds: they failed on all arches, with "*** buffer overflow detected ***: terminated"; I'd like to retry the builds but I don't see a way to do it (now?), is that something that can be triggered?
[14:22] <adrien> I saw that error a few days ago already but I have no idea if it was for the same package so I'd like an up-to-date one (I'm also going to build it locally)
[14:23] <adrien> pyxplot is one of the tests blocking readline, specifically on armhf
[14:23] -queuebot:#ubuntu-release- Unapproved: motion (jammy-proposed/universe) [4.3.2-1 => 4.3.2-1ubuntu0.1] (no packageset)
[14:34] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (jammy-proposed/main) [2.765.40 => 2.765.41] (desktop-core, i386-whitelist)
[14:36] <doko> dbungert: mini-iso-tools now depends on dhcpd (universe). don't we have alternatives already in main?
[14:39] <dbungert> doko: I typoed the depends then.  I'll fix it.
[14:48] <juliank> So there is a bug in autopkgtest causing it not to pick the right version of the package when package is the trigger
[14:48] <juliank> which causes britney to loop and reschedule tests all the time
[14:48] <juliank> for example<EMAIL_ADDRESS>[14:55] -queuebot:#ubuntu-release- New binary: dante [riscv64] (noble-proposed/universe) [1.4.2+dfsg-7.1~willsync1] (no packageset)
[15:03] <apw> /
[15:03] <apw> l/
[15:03]  * apw orders a new keyboard
[15:08] <vorlon> juliank, doko: remove old rusts: we did talk with the kernel team and they are meant to go away
[15:09] <vorlon> sil2100: "since it's a recommends" we don't remove packages for unsatisfied recommends... and are you documenting removal of the reverse-depends in the sync-blocklist repo (extra-removals) or is this not needed?
[15:12] <doko> ok, removing everything before 1.74
[15:13] <vorlon> getting armhf on https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output_notest.txt, that's convenient
[15:13] <vorlon> doko: uh this only applied to 1.62 and 1.68 which were there for kernels, I don't know if there's another reason to keep 1.73, please double-check this with Zixing first
[15:14] <juliank> vorlon: merge my critical britney fix before doing other stuff
[15:14] <juliank> :D
[15:14] <juliank> this one https://code.launchpad.net/~juliank/britney/+git/britney2-ubuntu/+merge/463029
[15:14] <juliank> I haven't told people here but I saw 16 retries for the same package issued by britney
[15:15] <juliank> tl;dr: autopkgtest does not correctly fetch source packages from proposed when triggered with proposed version; paride knows about the bug
[15:17] <tsimonq2> OOC is this expected to retry all non-armhf autopkgtest with all-proposed=1 (iff one has not already been triggered)?
[15:18]  * tsimonq2 crosses his fingers that it'll help with qtbase-opensource-src :)
[15:19] -queuebot:#ubuntu-release- Unapproved: xmms2 (mantic-proposed/universe) [0.8+dfsg-23build1 => 0.8+dfsg-23ubuntu0.1] (no packageset)
[15:21] -queuebot:#ubuntu-release- Unapproved: xmms2 (jammy-proposed/universe) [0.8+dfsg-22build3 => 0.8+dfsg-22ubuntu0.1] (no packageset)
[15:27] <juliank> vorlon: added `"migration-reference/0" not in triggers and` line to not add all-proposed for migration-reference/0 ones :)
[15:29] <vorlon> juliank: thanks
[15:39] <juliank> vorlon: So we know know that it's the combination of throughput and britney requeuing the same I don't know, 100 tests every run that's making amd64 go sideways
[15:40] <juliank> And QA team is cowboying some stuff I think to make sure that workers can't loop anymore
[15:42] <juliank> We have run my script today on all queues so they are all 2-3 times smaller :)
[15:42] <liushuyu> I believe all those "rust-*" packages failed on any architecture could be removed. Most Ubuntu packages use vendored source anyways
[15:43] <vorlon> $ LANG=C join -j1 <(LANG=C sort /tmp/armhf-new-uninstallables.txt) <(LANG=C sort /tmp/julian-recommends-removing.txt) | wc -l
[15:43] <vorlon> 1334
[15:43] <vorlon> $
[15:43] <juliank> kill them
[15:43] <vorlon> juliank: this doesn't look at all armhf binaries from a given source package, AIUI
[15:43] <juliank> correct
[15:43] <vorlon> so that won't unblock migration for all of them
[15:43] <juliank> but that is an acceptable tradeoff at this point IMO
[15:44] <vorlon> but I don't want to just take all of the binaries in the list, map to source packages, and remove all binaries
[15:44] <juliank> Just drop the binaries and see what happens?
[15:44] <vorlon> I will
[15:44] <vorlon> I'm just pointing out the weakness
[15:45] <juliank> TIL join, I always use comm -12
[15:45] <juliank> Also if you want to see uninstallabilities on armhf in britney, just patch britney "random" architecture to armhf ;)
[15:46] <vorlon> of course
[15:46] <vorlon> but as mentioned, the !armhf ones also matter
[15:47] <vorlon> particularly because those don't get fixed by armhf binary removals
[15:47] <juliank> true
[15:48] <vorlon> ok churning through these binary removals now
[15:48] <juliank> I have a list of uninstallabilities on amd64 by dose-distcheck in https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble/proposed.txt
[15:48] <juliank> no wait this is build-depends
[15:48] <juliank> I can create binary depends though
[15:49] <vorlon> yeah I don't care about build-depends today :)
[15:49] <juliank> It's interesting britney findsd 1334 uninstallabilites on armhf
[15:49] <juliank> dose-distcheck has like 20
[15:49] <juliank> But it does proposed + release
[15:50] <juliank> I'd have to construct a Packages file after migration to make it see a more realistic post-migration scenario
[15:50] <vorlon> no, britney finds *3600* uninstallablilities on armhf, when attempting the migration
[15:50] <vorlon> 1334 is the intersection of these with the things you've identified as leaves
[15:51] <juliank> well yes
[15:51] <vorlon> construct a Packages file> so you mean the old implementation of update-output-helper that I rewrote, heh
[15:51] <juliank> hhe
[15:53] <vorlon> alright, so churning through those removals now; gotten to 'c'
[15:53] <vorlon> (calling for removals one at a time because of the O(n^2) issue I mentioned to you before)
[15:57] -queuebot:#ubuntu-release- Unapproved: ngspice (jammy-proposed/universe) [36+ds-1 => 36+ds-1ubuntu0.1] (no packageset)
[16:16] <vorlon> juliank: and your identification of leaf packages on https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/removal-candidates.with-proposed.txt excluded seeded packages, right?  we might want to revisit that
[16:17] <juliank> vorlon: that is correct, yes
[16:17] <juliank> mostly to avoid ubuntu-meta getting deleted
[16:17] <vorlon> heh
[16:17] <vorlon> if anything, desktop flavors might appreciate not having their beta at risk because of their packages being out of date on armhf
[16:17] <juliank> I can make it check if ubuntu-${task} == name or something
[16:17]  * LocutusOfBorg brings a sledgehammer to vorlon for britney
[16:18] <juliank> I just want the key packages of the task really
[16:18] <vorlon> right
[16:18] <juliank> i.e. the meta packages
[16:18] <vorlon> but for all flavors not just ubuntu-*
[16:19] <juliank> should I just ignore section: metapackages maybe?
[16:19] <juliank> hmm let's see
[16:22] <juliank> vorlon: I now check "ubuntu-"+ task or task, which I think catches all of them
[16:22] <juliank> vorlon: I think it's only the mimimal task that becomes ubuntu-minimal?
[16:22] <juliank> For the others, task == name
[16:23] <juliank> vorlon: please do have a look at the file now and see if it has anything bad
[16:24] <juliank> probably should have diffed it
[16:25] <juliank> but I assume you have a local copy :)
[16:25] <juliank> I guess if you join it with brintey, you can use https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/removal-candidates.txt
[16:26] <juliank> otherwise you will not see a package foo in the release pocket that gets broken by migrating bar if there is no foo in proposed?
[16:28] <adrien> what do you prefer for source removals? ask here directly or batch them?
[16:29] <vorlon> adrien: source removals should have bug reports, unless it's a transient removal because the fix is already in -proposed
[16:29] <vorlon> adrien: it can be an existing Debian bug report or a new one in Launchpad
[16:30] <adrien> sorry, I mean, after having create bug reports
[16:30] <adrien> (although I haven't checked yet on debian)
[16:31] <adrien> nothing reported debian-side; removal requests: https://bugs.launchpad.net/ubuntu/+source/pyxplot/+bug/2058940 and https://bugs.launchpad.net/ubuntu/+source/eso-midas/+bug/2058947
[16:31] -ubottu:#ubuntu-release- Launchpad bug 2058940 in pyxplot (Ubuntu) "pyxplot: Please RM due to FTBFS" [Undecided, New]
[16:31] -ubottu:#ubuntu-release- Launchpad bug 2058947 in eso-midas (Ubuntu) "eso-midas: Please RM due to FTBFS" [Undecided, New]
[16:31] <vorlon> adrien: ah - throw us the bug numbers here directly, the "normal" ubuntu-archive queue is not being looked at right now AFAIK
[16:32] <adrien> I'm not entirely happy as I'd prefer to investigate these because they seem similar but too little time and I guess it's the time of the year when we look at even more failures than usual
[16:34] <vorlon> adrien: we all have the impulse to investigate and fix, but now is not the time for this :)
[16:34] <vorlon> ah it looks like riscv64 has caught up on coq, only waiting on mathcomp-analysis and coq-unimath builds now AFAICS
[16:34] <adrien>  :)
[16:37] <vorlon> adrien: in general I prefer output from `reverse-depends src:$src` and `reverse-depends src:$src -a source` as part of the removal bug to clearly document what revdeps there are if any
[16:38] <adrien> ok, I can add that a bit later today (I need to afk a bit)
[16:39] <vorlon> don't worry about it for these first 2, I've already confirmed locally and am removing
[16:40] <vorlon> juliank: so confirming the semantics of https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/removal-candidates.with-proposed.txt it appears that packages are in this list if -proposed has a new version of the source package for the binary, but it's not guaranteed the binary exists yet on armhf.  so some of these might be ftbfs in -proposed, the armhf binary removal will unblock them
[16:40] <vorlon> for migration, and we'll lose track of the armhf build failures?
[16:41] <vorlon> juliank: sorry, I meant ftbfs in -proposed on armhf only
[16:41] <juliank> vorlon: that's correct
[16:41] <juliank> well
[16:41] <juliank> They could ftbfs on other arches too, I don't check
[16:41] <vorlon> juliank: ok. I'm currently going through and getting a list of binaries for which this is the case, and will file bugs
[16:41] <juliank> In this report I only check there is a newer source package
[16:41] <vorlon> right
[16:42] <vorlon> the first one on the list, 0ad, is in -proposed and ftbfs on all archs
[16:42] <juliank> There is one where I also check that were are missing binaries
[16:42] <vorlon> so that's fine :)
[16:42] <juliank> But I don't have one that checks we *have* binaries, because those are not unblockable by removal
[16:42] <juliank> Well ok they might unblock *other* packages
[16:44] -queuebot:#ubuntu-release- Unapproved: lcov (mantic-proposed/universe) [2.0-1ubuntu0.1 => 2.0-1ubuntu0.2] (i386-whitelist)
[16:45] <juliank> vorlon: Do you want that report too?
[16:50] <adrien> vorlon: thanks!
[16:50] <juliank> vorlon: Can we lock the archive now so we don't get new transitions uploaded?
[16:51] <juliank> sil2100: I did not see your pings but the removal requests were for source packages, and ignoring mrcal
[16:51] <sil2100> juliank: ACK
[16:52] <sil2100> I'll keep that in mind for next ones ;)
[16:52] <juliank> sil2100: If it's binary only I send remove-package -b commands with comments here
[16:53] <juliank> I feel like someone else asked for locking the archive already but can't find where :D
[16:55] <juliank> I think I'll ask QA to do queue cleanup tomorrow again
[16:55] <juliank> the amd64 queues are at 7683 items, but cleaned up we are at 7482
[16:55] <juliank> this gets worse with every britney run so a daily purge and requeue sorts that out
[16:58] -queuebot:#ubuntu-release- New binary: mathgl [amd64] (noble-proposed/universe) [8.0.1-7.1] (no packageset)
[16:58] -queuebot:#ubuntu-release- New binary: mathgl [armhf] (noble-proposed/universe) [8.0.1-7.1] (no packageset)
[17:00] -queuebot:#ubuntu-release- New binary: mathgl [ppc64el] (noble-proposed/universe) [8.0.1-7.1] (no packageset)
[17:02] -queuebot:#ubuntu-release- New binary: mathgl [s390x] (noble-proposed/universe) [8.0.1-7.1] (no packageset)
[17:11] -queuebot:#ubuntu-release- New binary: mathgl [arm64] (noble-proposed/universe) [8.0.1-7.1] (no packageset)
[17:19] <juliank> vorlon: sil2100 I propose we also merge https://code.launchpad.net/~juliank/britney/+git/britney2-ubuntu/+merge/463045 to britney for the next run(s) such that it stops queueing the same tests each run
[17:19] <vorlon> juliank: ok, filing 124 update-excuse/time-t bugs for packages whose armhf binaries are being removed, and have built in -proposed but not on armhf
[17:19] <vorlon> juliank: that report too> which report exactly?
[17:20] <juliank> This was the culprit here really I think, we trigger foo with foo/2 and get foo/1 result, result is silently ignored; but pending test was deleted so it gets requeued.
[17:20] <juliank> We have sicne requeued all tests with all-proposed but it takes ages for the queue to be done to the point that it did all the tests that britney is waiting on
[17:20] <juliank> vorlon: leaf packages that have a build in proposes
[17:20] <juliank> *d
[17:21] <vorlon> juliank: lock the archive> at the moment I'm not aware of new transitions coming in that are a problem for us, and managing an unapproved queue is also overhead, for the moment I prefer to leave it as-is
[17:21] <juliank> There are two queues in NEW
[17:21] <juliank> * two transitions in NEW
[17:21] <vorlon> juliank: I don't think that's useful as a separate report, really, since I'm post-processing the existing report to decide what to remove and then further post-processing that to see if I should file bugs
[17:22] <juliank> ok
[17:22] <juliank> I'm scared someone approves libevent or mathgl NEW binaries, it's fine they are there but we should only approve them after beta
[17:22] <juliank> then we can handle a handful extra transitions
[17:23] <vorlon> juliank: I saw your other MP and I haven't worked out for myself if this will actually fix it.  We're seeing cases of britney repeatedly queuing a test when there has been *no* new result since the previous request
[17:24] <juliank> vorlon: Yes I analysed the log and it refetches the same "new" results, because it doesn't "store" the result because it's for an old version
[17:24] <vorlon> so if this is because we're seeing a result but it's invalid and then requeuing, shouldn't we filter them out earlier at the point where it detects these as "new" results?
[17:25] <juliank> vorlon: This is during the import stage from the db
[17:25] <juliank> before it analyzes them
[17:25] <vorlon> ok
[17:25] -queuebot:#ubuntu-release- Unapproved: rejected landscape-client [source] (focal-proposed) [23.02-0ubuntu1~20.04.2]
[17:25] <juliank> It's literally in fetch_sqlite_results helper functions :)
[17:25] -queuebot:#ubuntu-release- Unapproved: rejected landscape-client [source] (jammy-proposed) [23.02-0ubuntu1~22.04.2]
[17:27] <vorlon> I think I'm going to have to look at the code in context to understand
[17:27] <vorlon> before committing it
[17:28] <vorlon> as a general principle, "you got a result from the db but it's not what you wanted" tells me either the schema is wrong or the query is wrong, so I have to assess if I want to go down that rabbit hole right now ;)
[17:28] <juliank> that's true to some extent, we did not install version comparison function inside the table to put them in the query
[17:29] <juliank> and triggers are a string rather than their own table that you join
[17:29] <juliank> so it's hard to query `if any(trigger == name) and trigger_version == version`
[17:29] <juliank> can't even extract the trigger, let alone the version from it
[17:30] <juliank> or rather you'd want WHERE trigger != name OR trigger_version == version
[17:30] <juliank> but you get the idea
[17:31] <juliank> So the query only filters on series, architecture, package being tested, and last run id we imported (which we never update when we ignore new test result, hence you see same tests appear "new" each time)
[17:31] <juliank> It's only add_trigger_to_results() that actually validates the trigger
[17:32] <juliank> and checks that if trigger == package name that the package version is not older (I'd have tested for == but meh)
[17:32] -queuebot:#ubuntu-release- Unapproved: landscape-client (jammy-proposed/main) [23.02-0ubuntu1~22.04.1 => 23.02-0ubuntu1~22.04.2] (ubuntu-server)
[17:34] <juliank> normally you do actually want it to retry rather than lose results so this is not a perfect patch
[17:34] <juliank> the perfect patch would fetch queued.json from autopgktest.u.c and check the queues whether the test is already queued
[17:34] -queuebot:#ubuntu-release- Unapproved: landscape-client (focal-proposed/main) [23.02-0ubuntu1~20.04.1 => 23.02-0ubuntu1~20.04.2] (ubuntu-server)
[17:35] <doko> juliank: don't try to "fox" rustc-* needs a build with a working rust version
[17:35] <juliank> but that is harder to write?
[17:35] <juliank> doko: not fixing any further
[17:36] <juliank> so we want to keep britney's own pending tests but additionally also check queued.json to avoid requeueing tests scheduled otherwise
[17:36] <juliank> but that's too hard this week
[17:37] <juliank> (we want to keep britney's own notion of what is pending in addition such that we can skip tests we don't want to run ;)
[17:38] <vorlon> juliank: ok got it, yes will do a quick pass on the code and merge
[17:41] <juliank> vorlon: So I need to setup britney locally to run rather than just do pyflakes but then I can submit the full blown patch to consult queued.json before sending new tests
[17:41] <juliank> which is nicer than this, but this is minimal and easy to read
[17:41] <vorlon> hmmm we don't already consult queued.json? terrible, terrible
[17:42] <vorlon> also see internal side channel discussion about the fact that queued.json should be a sqlite db itself
[17:43] <juliank> vorlon: uh, I'd rather get rid of the sqlite db we have rather than add more
[17:43] <vorlon> in favor of what
[17:44] <andersson1234> I think queued.json being a sqlite db is feasible but introduces more complexity where it may not be necessary
[17:44] <juliank> it should be a json dump of a postgres db I suppsose
[17:45] <andersson1234> what's the rationale behind making it a db? Where's this side channel discussion also, i missed it
[17:45] <juliank> I haven't fully thought about it :)
[17:46] <vorlon> andersson1234: well queued.json is garbage
[17:46] <vorlon> like literally garbage, because it doesn't get garbage collected
[17:46] <vorlon> and the whole thing gets written out by britney after every single autopkgtest query or result
[17:47] <juliank> I don't follow, it is rendered by cache-amqp
[17:48] <juliank> and cache-amqp needs to visit the entire queue anyway
[17:48] <vorlon> ah wait sorry
[17:48] <vorlon> I was talking about a different .json without checking the name
[17:48] <juliank> You mean the pending test one from britney itself?
[17:48] <juliank> that one is eww
[17:48] <vorlon> yes
[17:49] <vorlon> state/autopkgtest-pending.jso
[17:49] <vorlon> state/autopkgtest-pending.json
[17:49] <juliank> Still need it, because otherwise you can't drop tests from the queues, if britney only consults queued
[17:49] <vorlon> yes, we need it but the fact that it's json is awful
[17:49] <juliank> Or I need to find force-skiptest hints before looking at scheduling tests
[17:50] <juliank> i.e. when scheduling a test, search force-skiptest hint (and cache that)
[17:50] <andersson1234> ah, okay, gotcha, thought u were talking about a-u-c, ignore me :)
[17:50] <vorlon> every time britney schedules a test and there's an upload of a new version before the test result comes in, you get an orphaned entry
[17:50] <juliank> then you can do force-skiptest followed by dequeuing
[17:50] <juliank> and britney sees force-skiptest and doesn't queue any tests despite having no state of what it has queued itself
[17:50] <vorlon> so autopkgtest-pending.json grows without bounds, except for when I once a cycle delete it while britney is quiesced
[17:51] <juliank> Does that sound reasonable? force-skiptest not queueing any tests?
[17:51] <juliank> It can be a bit expensive
[17:51] <vorlon> eh I'm not going to spend the thought on that question right now
[17:51] <vorlon> there's armhf to squash
[17:51] <doko> jbicha: gst-python1.0 ftbfs, test failures. Debian added an extra b-d on pygobject >= 3.48.1-1.1. that's a version we don't have
[17:51] <juliank> I can make britney garbage collect the pending tests too :)
[17:52] <vorlon> doko: there's an open update-excuse bug about this
[17:52] <vorlon> https://bugs.launchpad.net/ubuntu/+source/gst-python1.0/+bug/2057836
[17:52] -ubottu:#ubuntu-release- Launchpad bug 2057836 in pygobject (Ubuntu) "gst-python1.0 fails to build: test failures" [High, Triaged]
[17:52] <vorlon> I know because gst-python is in the list of packages I just removed armhf binaries for, and is built in -proposed on at least one arch (riscv64 because nocheck)
[17:52] <vorlon> juliank: I don't want britney to garbage collect, I want a GC to be able to run in parallel
[17:53] <vorlon> by, you know, having a database allowing multiple writers
[17:53] <vorlon> instead of a json file that's a dump of britney's brain every minute
[17:54] <vorlon> anyway, the round of armhf binary removals from release pocket is done, and 12 bugs left to file against the missing armhf binaries in -proposed
[17:54] <tsimonq2_> CD image lubuntu/noble/daily-live failed to build on 20240325 - FileNotFoundError: [Errno 2] No such file or directory: '/srv/cdimage.ubuntu.com/www/full/mantic/source/20231011.1'
[17:54] <tsimonq2_> uh wat
[17:56] <vorlon> good question
[17:57] <vorlon> I did some nuking of old source builds over the weekend
[17:58] <vorlon> that particular path was a symlink I used to try to hack up building source images for mantic after they were oopsed out of existence
[17:58] <vorlon> so that I could republish them to full/releases/mantic/release/source
[17:58] <vorlon> have dropped the symlink now
[17:59] <juliank> Ah damn I think I wrote the britney <-> queued integration now, but I should ook at it when actually awake and filled with carbs: https://code.launchpad.net/~juliank/britney/+git/britney2-ubuntu/+merge/463049
[17:59] <juliank> (hence still WIP)
[18:00] <mwhudson> vorlon, juliank, doko: please let me know where i should focus my attention today
[18:00] <juliank> yes queued.json containing nested json in a string is funny
[18:00] <juliank> I'll defer to vorlon
[18:00] <juliank> mwhudson: I'll defer to vorlon
[18:00] <mwhudson> (once i've had coffee and breakfast and done the school run)
[18:01] <juliank> I didn't have breakfast and I worked for 9 hours
[18:01] <juliank> :D
[18:01] <juliank> or lunch
[18:01] <juliank> ok I had a banana
[18:01] <vorlon> mwhudson: general guidance I gave this morning, in the absence of any specific urgent delegations from me, is to treat it as one big +1 maintenance exercise now for packages uploaded < 25 days ago
[18:02] <vorlon> I am hoping to have the underbrush cleared within a couple of hours on glib2.0 specifically
[18:02] <vorlon> to be able to recommend specifics
[18:02]  * juliank is mostly doing sidequests of anaylsing and fixing infrastructure
[18:03] <vorlon> why does update_output_notest now list ada crap that wasn't there yesterday
[18:03] <vorlon> mwhudson: ^^ maybe you can answer me that
[18:03] <mwhudson> all the ada stuff is broken on armhf but i thought doko had removed
[18:03] <mwhudson> it
[18:03] <tsimonq2> vorlon: thanks :) kicking off a Lubuntu retry to confirm
[18:03] <vorlon> well the list of new uninstallables on arm64 is now:
[18:03] <vorlon>     * arm64: edubuntu-desktop, edubuntu-desktop-minimal, edubuntu-desktop-raspi, gdm3, gnome, gnome-core, gnome-remote-desktop, gnome-shell, gnome-shell-extension-alphabetical-grid, gnome-shell-extension-manager, gnome-shell-extension-prefs, gnome-shell-pomodoro, ibus-tests, libadasockets12-dev, libcoq-iris, libgmpada12-dev, libgnatcoll-gmp21-dev, libgnatcoll-iconv21-dev, libgnatcoll-lzma4-dev,
[18:03] <vorlon> and none of the ada stuff was there yesterday
[18:03] <vorlon> libgnatcoll-omp3-dev, libgnatcoll-postgres3-dev, libgnatcoll-python3-2-dev, libgnatcoll-readline21-dev, libgnatcoll-sql5-dev, libgnatcoll-sqlite21-dev, libgnatcoll-syslog5-dev, libgnatcoll-xref22-dev, libgnatcoll-zlib4-dev, libgnatcoll21-dev, libgnatprj10-dev, libmutter-13-0, libplplotada5-dev, librust-libslirp-dev, librust-ripcalc-dev, librust-transmission-client-dev, librust-zbus-1-dev,
[18:03] <vorlon> libsoup-3.0-tests, libtemplates-parser16-dev, libxmlada-dom12-dev, libxmlada-input12-dev, libxmlada-sax12-dev, libxmlada-schema12-dev, libxmlada-unicode12-dev, ubuntu-desktop, ubuntu-desktop-minimal, ubuntu-desktop-raspi, ubuntu-gnome-desktop, vanilla-gnome-desktop
[18:03] <vorlon> mwhudson: so run that to ground?
[18:04] <vorlon> because it's a blocker even if we add armhf to broken arches
[18:04] <mwhudson> vorlon: ok
[18:04] <NotEickmeyer> Oof, the raspi world broke.
[18:05] <vorlon> and it looks like mutter regressed in migratability
[18:07] <vorlon> actually it progressed and now other things are broken?
[18:07] <vorlon> because this is an ABI change, yeah
[18:08] <vorlon> doko: ^ I'm not sure why you uploaded mutter, nothing on my side said it was a blocker for getting glib2.0 unstuck. I'm going to block it in britney now so we can calculate an upgrade without it
[18:12] <doko> vorlon: libcanberra t64
[18:12] <vorlon> hmm
[18:12] <vorlon> doko: ok
[18:13] <mwhudson> vorlon: oh the ada nonsense is because britney is trying to migrate gnat
[18:13] <vorlon> doko: I'm not sure if we should trigger rebuilds now of the mutter revdeps or if we should remove their armhf binaries from release pocket; do you have time to analyze this in the next couple of hours? If not I'll look at it at some point today
[18:13] <doko> the ada armhf binaries are removed, those that don't build
[18:13] <vorlon> mwhudson: shall I block that too?
[18:13] <juliank> I'll go paste the corrected queue count with duplicates and obsoletes removed and triggers merged:
[18:13] <juliank> amd64 input: 7722 output: 7474
[18:13] <juliank> i386 input: 797 output: 268
[18:13] <juliank> ppc64el input: 448 output: 365
[18:13] <juliank> s390x input: 430 output: 359
[18:13] <juliank> arm64 input: 1046 output: 873
[18:14] <juliank> armhf input: 0 output: 0
[18:14] <mwhudson> vorlon: i think so, i don't think gnat is entangled in t64 stuff
[18:14] <vorlon> mwhudson: done
[18:15] <juliank> I've asked for i386 to run a merge again so the queue is not at almost 3 times the real size, which should help, even if the current britney run still queues again
[18:15] <juliank> but this way i386 should be done soon
[18:16] <juliank> more space for amd64
[18:16] <mwhudson> right caffeine
[18:16] <doko> mwhudson: I don't think gnat blocking is needed. and it's entangled via plplot
[18:17] <mwhudson> doko: libadasockets12-dev depends on gnat (<< 13), gnat (>= 12),
[18:17] <vorlon> doko: it's not entangled
[18:17] <vorlon> on !armhf
[18:17] <vorlon> which is the priority
[18:17] <vorlon> we can rip out arbitrary quantities of non-ubuntu-core armhf packages from the release pocket to unblock the transition
[18:18] <doko> mwhudson: libadasockets12-dev is gone
[18:19] <doko> vorlon: I'm not sure what you're asking about mutter. why extra test triggers?
[18:22] <vorlon> doko: trigger rebuilds, I said nothing about test triggers
[18:22] <vorlon> doko: mutter can now migrate, but it breaks its revdeps on !armhf because of abi change
[18:22] <vorlon> have you already scheduled builds for these?
[18:22] <doko> no, can do
[18:22] <vorlon> doko: but the question is *should we* right now or should we just remove armhf binaries
[18:23] <vorlon> because we can block mutter and remove armhf binaries, or we can unblock mutter but then its revdeps have to all be rebuilt on !armhf
[18:23] <vorlon> so there's a decision to make
[18:23] <doko> I'll do the uploads first
[18:24] <juliank> can we just calculate the minimal set we need for core and rip out *everything* else
[18:24] <vorlon> juliank: that risks having to rebootstrap more stuff so no
[18:25] <vorlon> and if you mean "demote everything to proposed and let britney sort it out" also no ;)
[18:26] <vorlon> telling britney to let armhf break in the release pocket really is the shortest path when we get to this point
[18:27] <juliank> ack
[18:28] <juliank> I can't wait until we see the real test queue throughput with next britney run
[18:28] <vorlon> coq-iris uploaded, looks like it was the last straggler dependency of libcoq
[18:28] <vorlon> (transitive dep)
[18:28] <juliank> no more interference with requeuing will be nice :)
[18:29] <vorlon> ummm more rust uninstallables than there were before, including librust-libslirp-dev, which juliank will recognize
[18:29] <vorlon> so what did I miss with my previous removals
[18:29] <juliank> hmm
[18:29] <vorlon> rust-zbus-1 != rust-zbus, maybe that's it
[18:30] <juliank> I don't remember anymore the rust-libslirp
[18:30] <vorlon> anyway, nothing particularly interesting here, I'll recurse the revdeps and throw them out
[18:30] <vorlon> juliank: this was the rust-nix thing :)
[18:31] <vorlon> I said hey why is that on your list when I already threw it out
[18:31] <juliank> hmm
[18:31] <vorlon> well apparently I didn't throw it out
[18:31] <juliank> apparently
[18:34] <juliank> vorlon: no wonder we don't see progress on amd64 and i386; britney is (for the last time just now) scheduling 200 duplicate tests on i386 every run
[18:34] <vorlon> grr
[18:34] <vorlon> well let me just delete those all
[18:34] <juliank> above it was 797->268
[18:35] <juliank> now it's i386 input: 964 output: 268
[18:35] <juliank> vorlon: I think tim wanted to merge again but maybe deleting them all is fine too, I don't think we got any new uploads on i386 today?
[18:35] <juliank> in the last hours anyway
[18:36] <vorlon> we can sort that later
[18:36] <juliank> The other architectures only get 30-40 duplicate tests per run which is more decent
[18:36] <vorlon> chances of us being delayed by amd64 test queue not being completed >> chances of us being delayed by a couple of i386 tests that we can schedule by hand in a different queue in a couple hours
[18:37] <vorlon> 979 requests deleted from queue
[18:37] <juliank> ta
[18:37] <vorlon> afk food
[18:37] <juliank> I think britney went through every test 18 times already
[18:37] <juliank> (on i386)
[18:37] <juliank> I'm waiting for my rice cooker but should get some more cabbage
[18:37] <schopin> vorlon: I'd like to upload a new glibc soon-ish (assuming the PPA build goes fine it should be ready), I'm guessing you'd like me to delay until after wednesday (and/or whenever the amd64 autopkgtest thing has been sorted)?
[18:38] <juliank> Best after beta at this point
[18:39] <juliank> sorry schopin
[18:40] <schopin> I was hoping you wouldn't say that :/
[18:40] <schopin> Oh well, c'est la vie.
[19:45]  * Eickmeyer about ready to find cdimage and throw it
[19:45] <Eickmeyer> Today's cron job of Ubuntu Studio isn't showing, iso tracker pointing to it but 404
[19:50] <mwhudson> vorlon: i guess the current update_output_notest.txt is from a run that started before you blocked gnat?
[19:50] <vorlon> mwhudson: would be yes
[19:51] <vorlon> schopin, juliank: I'm ok with new glibc after Wednesday, depending.  It's not too late according to our traditional beta schedule
[19:52] <vorlon> mwhudson: only barely; timestamp says generated at 18:39 and I left for food at 18:37, so basically a race.  but also I'm not sure a notest run updates the hints directory
[20:23] <vorlon> mwhudson: ok so one other thing in the notest output that I still do not have any clue about is the ros uninstallabilities (libdiagnostic-aggregator1d)
[20:24] <vorlon> I cannot reproduce this with update-output-helper + chdist apt
[20:25] <vorlon> so let's see
[20:26] <vorlon> 1) let me land update-output-helper in ubuntu-archive-tools since I've gotten no further feedback on my MP; I ultimately want it in ubuntu-dev-tools but let's at least get it somewhere slightly visible
[20:26] <vorlon> 2) let me dump you commands showing how I run things
[20:27] <mwhudson> vorlon: eh some of these things regress uninstallability on armhf, some on power? that seems odd
[20:27] <vorlon> mwhudson: so if you are (or someone else is) game to look at this: get a current lp:ubuntu-archive-tools (I just pushed), then run:
[20:27] <vorlon> $ wget -O - -q https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output_notest.txt | sed -n -E -e'/trying:.*glib2.0/ { s, -[-a-z0-9.]+/[a-z0-9]+,,g; s/trying: //; s/ /\n/g; p; q }' > /tmp/glib2.0-transition.txt
[20:28] <vorlon> $ ARCH=ppc64el update-output-helper -u
[20:28] <vorlon> $ update-output-helper -f /tmp/glib2.0-transition.txt
[20:28] <vorlon> $ chdist -d "/home/vorlon/.cache/brapt" apt u-a-h install libdiagnostic-aggregator1d
[20:28] <vorlon> behold the lack of failure
[20:30] <vorlon> (the sed command, for the morbidly curious, finds the first entry in u-o-notest that includes glib2.0; deletes all references to binary package removals, which are meaningless to update-output-helper and can't be processed; convert the rest of the list into a one-source-per-line file)
[20:30] <mwhudson>     - splitting the component into single items and retrying them
[20:30] <mwhudson> does this ever help?
[20:30] <vorlon> lol I have no idea
[20:32] <liushuyu> Hi ubuntu-release, what is the status of this FFe? https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/2052985
[20:32] -ubottu:#ubuntu-release- Launchpad bug 2052985 in rustc (Ubuntu) "[FFe] Upgrade Rust to 1.76.0" [Medium, Incomplete]
[20:32] <mwhudson> vorlon: so libdiagnostic-aggregator1d in proposed depends on libroscpp4d which comes from ros-ros-common but i don't know if that's relevant
[20:33] <mwhudson> (britney isn't trying to migrate ros-ros-common)
[20:33] <mwhudson> er depends on libroscpp4dt64'
[20:34] <mwhudson> oh ros-ros-comm
[20:36] <doko> mwhudson: it's dep-wait. synced dh-ros
[20:45] <mwhudson> doko: well ok, still doesn't explain why britney thinks migrating the blob it's currently trying to migrate will make these packages uninstallable
[20:46] <mwhudson> vorlon: what do lines like -libmysql++3v5/amd64 mean in update_output / /tmp/glib2.0-transition.txt ?
[20:46] <doko> mwhudson: because ros-diagnostics isn't yet rebuilt against ros-ros-comm
[20:47] <mwhudson> doko: right! but britney isn't trying to migrate any ros things
[20:48] <vorlon> mwhudson: they mean that my regexp failed to remember + was a valid char and filter them out
[20:48] <vorlon> surprised that update-output-helper didn't choke on this
[20:53] <mwhudson> vorlon: i'm confused maybe britney wasn't trying to migrate gnat after all?
[20:53] <mwhudson> for some inexplicable reason dealing with this file containing lines 100s of ks long is a bit confusing
[20:53] <vorlon> heh
[20:54] <vorlon> mwhudson: you may have raced; current https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output_notest.txt shows no gnat noise
[20:54] <vorlon>     * ppc64el: edubuntu-desktop, edubuntu-desktop-minimal, libcoq-iris, libdiagnostic-aggregator-dev, libdiagnostic-aggregator-tools, libdiagnostic-aggregator1d, libmrpt-ros1bridge-dev, libpcl-ros-dev, libpcl-ros-io0d, librosbag-dev, librosbag-storage-dev, librosbag-storage4d, librosbag4d, librust-libslirp-dev, librust-ripcalc-dev, librust-transmission-client-dev, librust-zbus-1-dev, librviz-dev,
[20:54] <vorlon> libsoup-3.0-tests, mrpt-apps, numptyphysics, pcl-ros-tools, python3-rosbag, ubuntu-desktop, ubuntu-desktop-minimal, ubuntu-gnome-desktop
[20:55] <mwhudson> no i was just confused still
[20:56] <mwhudson> oh i may have made glib2.0-transition.txt out of a different version than i was looking at
[20:56] <vorlon> yeah that's the race I meant :)
[20:59] <vorlon> removed rust-isahc, rust-transmission-client
[21:05] <doko> jamespage: watcher is openstack related, ftbfs in proposed. could be removed
[21:13] <doko> tillkamppeter: please could you have a look at pappl-retrofit? ftbfs in proposed
[21:16] <mwhudson> vorlon: well i'm completely confused too on why u-o-h and britney disagree on this too
[21:16] <mwhudson> vorlon: i suppose it could be some kind of britney bug but ehhh
[21:18] <vorlon> mwhudson: librosbag-storage4d might be the easiest one to walk and figure out, it "only" wants to install 110 packages
[21:19] <vorlon> e-d-s i386 nbs removal from -proposed should unblock gnome-shell
[21:23] -queuebot:#ubuntu-release- Unapproved: qemu (mantic-proposed/main) [1:8.0.4+dfsg-1ubuntu<IP_ADDRESS> => 1:8.0.4+dfsg-1ubuntu<IP_ADDRESS>] (ubuntu-server, virt)
[21:27] <mwhudson> vorlon: could it be the attempts britney is making to remove libtinyxml2-9?
[21:27] <mwhudson> the ros bits depend on that
[21:27] <arraybolt3> ubuntu-release: Any chance someone could look over this FFe? It's a trivial config file change to enable a feature that is already in Lubuntu and is just being bugfixed. https://bugs.launchpad.net/ubuntu/+source/calamares-settings-ubuntu/+bug/2056061
[21:27] -ubottu:#ubuntu-release- Launchpad bug 2056061 in calamares-settings-ubuntu (Ubuntu) "FFe: Calamares customize menu" [Undecided, New]
[21:28] <arraybolt3> tsimonq2: ^
[21:29] <mwhudson> vorlon: yes i think that's it. but why is britney trying to do that??
[21:29] <mwhudson> it's nbs but well
[21:32] <vorlon> ok do I need to try to figure out how to block a removal
[21:32] <vorlon> I'm not sure britney allows that
[21:36] <vorlon> mwhudson: ok well I've added a hint to try to block it but I honestly have no idea if britney will respect that
[21:36] <vorlon> if it doesn't then I guess we're stuck on being able to zero out notest. I could switch it to show *only* armhf uninstallables but that would also not be ideal
[21:37] <vorlon> once we're ready to go, it's straightforward to force things through and just let the ros stuff be broken for a bit
[21:38] <mwhudson> vorlon: yeah i mean force things through let britney delete the nbs tinyxml packages and then republish them?
[21:38] <vorlon> oh I could just delete these packages from the release pocket because there are fixes in -proposed, yeah
[21:38] <mwhudson> yes or that
[21:39] <vorlon> or maybe I just delete them entirely because upstream wants them not shipped in 24.04
[21:40] <vorlon> ahhh but rosbag is from ros-ros-comm which has a billion revdeps, so for now we'll resort to binary removals
[21:55] <vorlon> oh hey, and amd64 view, that's useful (only way to see regressions in arch: all installability)
[21:55] <vorlon> *an
[21:57] <mwhudson> and all the oem kernels?
[21:58] <vorlon> the metapackages
[21:58] <vorlon> from 20.04
[21:58] <vorlon> which probably just need axed
[21:59] <vorlon> I'm looking at intel-opencl-icd which needs a sourceful fix, do you want to look at the metapackages?
[22:01] <vorlon> flask, quart is known (just blocked by flask-babel retest)
[22:01] <vorlon> actually those are arch: all and tested on other archs already which I should have noticed before, so skiptesting flask
[22:08] <vorlon> mwhudson: ok I'm removing linux-tools-generic-hwe-22.04 linux-generic-hwe-22.04 linux-modules-iwlwifi-generic-hwe-22.04 linux-image-generic-hwe-22.04linux-headers-generic-hwe-22.04 from the release pocket which means there's no *regression* in installability anymore
[22:08] <mwhudson> vorlon: sorry, which metapackages?
[22:09] <vorlon> mwhudson: "the oem kernels" - it's not any kernels it's all metapackages
[22:09] <vorlon> because of incomplete deprecation
[22:09] <vorlon> I pinged ppisati_ (and now here as well) to fix this in a future upload
[22:09] <doko> vorlon: ros-diagnostics built
[22:09] <mwhudson> oh i see
[22:10] <vorlon> doko: ok.  I am totally indifferent to ros packages at this point and will throw them out as needed, however :)
[22:10] <vorlon> (already threw out ros-diagnostics)
[22:11] <vorlon> so, everything showing on the current notest report for amd64 now has a resolution in flight.  going afk for a bit
[22:53] <mwhudson>     * s390x: libcoq-iris, libocct-data-exchange-7.6, libocct-draw-7.6, libocct-ocaf-7.6, libocct-visualization-7.6, librust-transmission-client-dev, libsoup-3.0-tests
[22:53] <mwhudson> i haven't seen some of these before...
[22:55] <doko> tonight I gave back some stuck builds, one or two coq-* packages were among these
[22:56] <mwhudson> hmm flask fun
[23:20] <vorlon> mwhudson: I skiptested flask, it should be resolved soon?
[23:20] <vorlon> mwhudson: the occt stuff seemed to be s390x-specific
[23:21] <mwhudson> vorlon: seems very close then?
[23:21] <vorlon> (I did see it once before, don't remember having followed up)
[23:21] <vorlon> yes
[23:27] <vorlon> ah yes occt was another one I couldn't reproduce with u-a-h
[23:27] <vorlon> u-o-h
[23:27] <vorlon> (I should fix the chdist name)
[23:28] <vorlon> oho there we go, Note, selecting 'libocct-data-exchange-7.6t64' instead of 'libocct-data-exchange-7.6'
[23:34] <vorlon> ok so the issue comes down to the opencascade libraries which would be newly NBS after migration also being uninstallable because of a strict versioned dep on occt-misc.  so in the short term I'll just remove these binaries from the release pocket increasing uninstallability count


[00:09] <slangasek> dobey: ok.  Are you taking care of that?
[00:33] <slangasek> dobey: (a simple "yes" here will be enough for me to push the button on sponsoring the upload ;)
[02:43] <dobey> slangasek: yes
[02:49] <slangasek> dobey: ok, uploaded
[02:52] <dobey> slangasek: thanks!
[11:00] <dupondje> some question. There is some bug in firefox/flashplugin caused by a missing apparmor rule
[11:00] <dupondje> file a bug on flashplugin or firefox for that?
[11:00] <dupondje> (flashplayer does not work in firefox because it doesn't have access to /etc/ssl/openssl.cnf)
[11:50] <debfx> dupondje: firefox since it ships the apparmor profile
[14:43] <zbenjamin> cjwatson: good :) since we switched to adb as phablet root is always a bit problematic :)
[15:01] <israel> Hey everyone!  I have a question about Bash and chroot... not sure if this is the right place or not... but here goes
[15:01] <israel> how do I use a bash function as the command for chroot?
[15:02] <israel> i.e. myfunction(){apt-get install programs}
[15:02] <israel> sudo chroot chrootdir myfunction
[15:03] <israel> why doesn't sudo chroot chrootdir "$( myfunction )" work?
[17:12] <mlankhorst> because it isn't run in the chroot
[19:59] <blkperl> slangasek: I think I figured out my nfs issues, idmap is not looking up expired keys sporadically...
[20:00] <slangasek> fun
[20:00] <blkperl> err whats the difference between id_legacy and id_resolv
[20:00] <slangasek> I don't know
[20:00] <slangasek> :)
[20:02] <blkperl> slangasek: so the only thing that works is nfsidmap -c , I don't think the key limit in /proc/user-keys is the issue which is what all the bug tickets focus on
[20:02] <blkperl> and running nfsidmap -c on a 1 minute cron is not a viable workaround :(
[20:10] <blkperl> slangasek: looks like theres a debian bug too https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758870


[06:50] <sam_yan> Hi  when  upstart --user  is running   ,my gnome-session can not start?
[06:52] <sam_yan> can someone help me?
[17:51] <ballmer> there are some features of gnome 3 that aren't suitable for a corporate environment, like the absence of a screen lock with screen saver and the non-intuitive buttons for power down, log off and suspend.  is there someone here involved with customization of gnome for ubuntu?
[17:55] <ballmer> the gnome designers are apparently writing it for hobbyist laptops
[17:55] <ballmer> i chatted with them earlier
[20:44] <craysiii> i feel like you haven't even tried ubuntu gnome if you have those things to say
[20:46] <craysiii> darkxst is there any truth in this? "(09:55:04 AM) ballmer: the gnome designers are apparently writing it for hobbyist laptops"
[21:49] <darkxst> craysiii, so, of course not
[21:49] <darkxst> no
[21:49] <eliasps> darkxst I downgraded to 3.18 and the problems got fixed. I'll upgrade back to 3.19 to see if it happens again
[21:49] <craysiii> lol figured it was just a troll.
[21:50] <darkxst> eliasps, I still havent seen your issues here on 3.19
[21:52] <darkxst> craysiii,  his chat with gnome guys, consisted of only
[21:52] <darkxst> ballmer> i see there are extensions for adding a suspend button to gnome, but none work in 3.16.  is there another way to suspend other than logging off and doing it from the login menu?
[21:55] <craysiii> lol
[23:31] <brody> my wifi dont work on acer e5-552 running ubuntu gnome 15.10
[23:44] <brody> anyone know?
[23:46] <adueppen> brody: have you tried any other flavors? Also yes I know it's you
[23:47] <brody> tryed unity, also apricity
[23:47] <adueppen> brody: what about fedora?
[23:47] <brody> fedora dosent use apt-get tho right>?
[23:48] <adueppen> brody: it comes with GNOME software by default though
[23:49] <brody> i kinda would like to have debains package manger
[23:49] <adueppen> brody: it wouldn't matter too much
[23:49] <brody> ok let me put it on ur usb
[23:53] <brody> nope it dont


[15:10] <militantorc>  <militantorc> What does the much shorter LTS support period mean?
[15:10] <militantorc>  <militantorc> What updates begin to get excluded compared to base Ubuntu after 3 years is over but the base Ubuntu lts is still supported?
[15:10] <militantorc>  <militantorc> I installed directly from an xubuntu iso for the install thats running right now
[15:10] <militantorc>  <militantorc> unlike the previous version lts which I did by apt-get install xubuntu-desktop on a base Ubuntu install
[15:10] <militantorc>  <militantorc> and I just realized that Xubuntu iso only offers 3 years support
[15:10] <militantorc>  <militantorc> while the base gives 5 or 10
[16:04] <sylvain31> militantorc, do you have source URL about that duration?
[16:05] <militantorc> sylvain31, just open the xubuntu website
[16:05] <militantorc> It lists the 3 year period right there
[16:07] <sylvain31> I see: https://ubuntu.com/about/release-cycle vs https://xubuntu.org/help/ "Xubuntu 22.04 (Jammy Jellyfish), supported until April 2025"
[19:24] <sima2> hi, how do I make xubuntu 23.04, X and desktop get back/ present loin screen after screensaver/ standby?
[19:24] <sima2> It is older Dell D620 laptop with 945Gm graphics
[19:25] <sima2> Hmm, maybe because I was asked to disable screen locking on standby/screen saver, before I did an update?..
[19:26] <sima2> let me try now..
[19:28] <sima2> And now when I come back from standby and screen locking on standby and locking on screensaver is turned on, login screen IS displayed.
[19:28] <sima2> So bug might be login dialogue does not come up unless locking on standby on screensaver is not turned on.


 valorie: ping
[21:03] <valorie> pong
[21:03] <valorie> and sure, now is fine to talk about LFNW
[21:03] <valorie> not so much when I was sleeping!
 @valorie, Call me real quick?
[21:05] <valorie> ringing


[00:49] <Riddell> evening, what did I miss today?
[00:50] <Riddell> apachelogger: packagekit fork issue I did try to extent the timeout, there's a patch on the bug and packages in ~jr PPA, but seele still reported having the problem
[00:50] <Riddell> no fix for updates which bring in new packages but that shouldn't be an issue for a stable release?
[00:54] <maco> that mean i should try using kpackagekit again? i've been avoiding it because of the fork thing for a while...
[00:58] <Riddell> maco: try using the packagekit update in ~jr PPA and see if that helps
[00:59] <maco> kk
[01:00]  * Riddell snoozes
[01:04] <maco> :( KPackageKit has "Apply all available updates", "History", "Package", and "Action" in English
[01:05] <maco> and the policykit popup is all english
[01:07] <maco> no errors! yay!
[01:12] <ryanakca> nixternal: Hi, to apply my changes to all HTML files, I would... ?
[01:13] <nixternal> what changes?
[01:28] <ryanakca> nixternal: The theme. I need to add the rounding blurb to all the .html files...
[01:29] <nixternal> so you need to add stuff to the part before <body> and that's it?
[01:29] <nixternal> that could easily be done by scripting
[01:30] <nixternal> if you need to edit/add more, then that would have to be done somewhat manually
[01:30] <nixternal> or...I could probably create a new xsl sheet to build docs against to prevent all of this work :)
[01:31] <ryanakca> Hmmm... probably easier for me just to write a small script. Thanks :)
[01:32] <nixternal> yes, but an xsl for the future would be nicer
[01:32] <nixternal> this is where externals in bzr would be nice
[01:33] <ryanakca> nixternal: Well, shall I get you the blurb to add?
[01:39] <ryanakca> nixternal: Here it is, http://pastebin.ca/1412859
[02:40] <JontheEchidna> the buildds are sloooow still :(
[02:40] <JontheEchidna> my Qt sru isn't set to build for another 7 hours
[02:42] <nhandler> JontheEchidna: Based on what I have heard in -release, SRUs have weird build priorities
[02:44] <vorian> where is the network package that needs testing?
[02:44] <vorian> my atheros is really sucking
[02:45] <vorian> SUCKING
[09:05] <eagles0513875> apachelogger: ping
[12:36] <Riddell> JontheEchidna: did kubuntu_72_remove_startkde_cruft.diff go upstream?
[12:37] <Riddell> apachelogger: did kubuntu_13_startkde_set_country.diff go upstream? (at least for discussion of the issue)
[13:14] <JontheEchidna> Riddell: nope, not as far as I know
[13:14] <eagles0513875> JontheEchidna: regarding the intel issues would it be possible to include some of the older drivers from gutsy and intrepid so that intel gfx users have some choices
[13:15] <JontheEchidna> eagles0513875: there are ppas for that, which is about as good as it will get for now
[13:15] <eagles0513875> ok
[13:15]  * eagles0513875 goes huting for the ppa with those drivers
[13:28] <JontheEchidna> https://edge.launchpad.net/ubuntu/+source/qt4-x11/4.5.0-0ubuntu4.1/+build/987442
[13:28] <JontheEchidna> :(
[13:29] <eagles0513875> JontheEchidna: think tsimpson is working on the bots
[13:30] <JontheEchidna> what about the bots?
[13:31] <eagles0513875> he was revamping them or something recoding adn what not since the bots we had werent doing the trick he was recoding in ruby but i think hes finished and is working on another aspect of them
[13:31] <eagles0513875> !hi
[13:31] <JontheEchidna> what does that have to do with anything, though?
[13:31] <JontheEchidna> I'm just saying that Qt4 has been in queue for 14 hours and still isn't ready for building yet
[13:31] <eagles0513875> doesnt the bot normally even when linking display what hte bug is about i thought thats what the :( was for
[13:31] <eagles0513875> ahhhhh my bad
[13:31] <eagles0513875> misinterpreted the smiley and link
[13:32] <eagles0513875> is there anything i can do to help facilitate the build
[13:42] <JontheEchidna> nope
[13:43] <eagles0513875> ok
[13:43] <eagles0513875> if there is anything for testing let me know
[14:02] <seele> were there any app proposals for Karmic that i should begin reviewing?
[14:41] <Nightrose> http://blog.lydiapintscher.de/2009/04/28/amarok-2-in-kubuntu-jaunty/ <- last comment says there are problems with the current amarok package in the ppa
[14:41] <Nightrose> JontheEchidna: apachelogger: can you please have a look?
[14:41] <Nightrose> or anyone else here who has time?
[14:44] <jjesse> i keep getting notified that my hda intel sound card has stopped working or something similar is there a way to restart the sound system so sound works again without restarting?
[14:48] <maco> wow just saw an interesting email on one of the local mailing lists. it's talking about kubuntu 10.4 (?) and how knetworkmanager (huh?) is broken in it
[14:53] <neversfelde> Nightrose: https://edge.launchpad.net/~kubuntu-experimental/+archive/ppa/+build/985608 Seems that it is not fully build atm, that might be the problem?
[14:53] <Nightrose> neversfelde: possible - build failure or just waiting?
[14:53] <neversfelde> Nightrose: only waiting
[14:53] <Nightrose> ok great
[14:53] <Nightrose> thanks
[14:53] <Nightrose> i'll let the guy know
[14:54] <neversfelde> build of i386 packages starts in 23 hours :)
[14:56] <neversfelde> I think the amarok-common package is not changed
[15:02] <Quintasan> Hiho
[15:18] <astromme> maco: it's a message from the future! We must bow down to our time travelling friends
[15:19] <maco> ^_^
[15:24]  * astromme just read the comments on the amarok post that lydia made. Yuck... I guess the trolls, having found no major issues with 4.2.2, have switched and latched on to amarok. /sigh
[15:26] <Nightrose> astromme: hehe yea - kinda sucks that we didn't get 2.1 ready for jaunty
[15:26] <Nightrose> that would have prevented a lot of it
[15:26] <Nightrose> but well
[15:26] <astromme> Nightrose: absolutely. But on the other hand, you can't rush these things
[15:27] <Nightrose> 2.1 release is soon and then hopefully most people will shut up
[15:27] <Nightrose> right
[15:27] <astromme> and 2.0 is a decent release. I was happy with it
[15:27] <Nightrose> :)
[15:27]  * astromme shrugs
[15:27] <Nightrose> btw: back from berlin again - will check out the current rtm applet when I am back home in a few hours
[15:27] <astromme> Nightrose: btw, pretty soon you won't have to build the rtm stuff any more :). It made it into kdeplasma-addons right before feature freeze
[15:28] <Nightrose> your screenshots look awesome
[15:28] <astromme> :)
[15:28] <Nightrose> \o/
[15:28] <Nightrose> awesome
[15:29] <astromme> So for the next week or two I'm shifting totally to "Do well on my end of year uni exams" and then I'll have time to concentrate on kde again. heh
[15:29] <Nightrose> hehe good luck
[15:44] <Riddell> Tonio_: seen qutecom?
[15:44] <Riddell> just passed through  New queue
[15:45] <Tonio_> Riddell: looked at the code... as messy as openwengo... still lots of openwengo references...
[15:45] <Tonio_> Riddell: I think there's a package on a ppa
[15:45] <Riddell> well it's in the main archive now
[15:46] <Tonio_> Riddell: who got it in ?
[15:46] <Riddell> Maia Kozheva<EMAIL_ADDRESS>om>
[15:46] <Riddell> but I think it's in debian too according to changelog
[15:51] <ScottK> That's LucidFox
[15:56] <Tonio_> Riddell: well I'll test it then... I must say I haven't been in using sip recently, as my new ISP doesn't have a sip service....
[15:56] <Tonio_> Riddell: and as my current hobby is to search for a new job :)
[15:57] <Tonio_> Riddell: now 2 month before my contrat ends, so that's the very only priority :)
[15:58] <Tonio_> Riddell: there are probably plans for sip support within decibel, no ?
[16:00] <Tonio_> Riddell: but as we should forget about kcall I think, since it's unmaintained, maybe qutecom is finally what we should get on the CD...
[16:01] <Tonio_> Riddell: last time I tested it (arround 4 month ago) it looked to me as a quick openwengo fork, pretty unstable one for sure...
[16:02] <Tonio_> Riddell: which archives ? can't find it on packages.ubuntu.com
[16:03] <Tonio_> hum launchpad has it but not p.u.com.... weird...
[16:04] <Riddell> Tonio_: I only just let it through new a few minutes ago
[16:12] <Tonio_> Riddell: ho right
[16:36] <Riddell> vorian: wake up!
[16:40] <eagles0513875> morning to you to Riddell
[16:41] <eagles0513875> apache needs a good poke his bots been in and out of a number of channels all day
[16:56] <Riddell> evening fabo
[16:59] <nixternal> what's the status? can I start merging? REVUing? sponsoring?
[17:00] <Riddell> nixternal: merging you should be able to https://wiki.kubuntu.org/Kubuntu/KarmicKDEMerges
[17:00] <nixternal> w00t
[17:01] <nixternal> anything need to be done now?
[17:01] <Riddell> nixternal: anything that doesn't have a name by it there
[17:01] <Riddell> on wiki page above
[17:01] <nixternal> roger that
[17:01] <Riddell> plus all other other ones on merges.ubuntu.com
[17:01]  * nixternal starts adding his name
[17:01] <Riddell> but I'm not uploading anything yet, mostly waiting on fabo to discuss qt and phonon
[17:02] <nixternal> roger that
[17:02] <Riddell> and if you see vorian about, he's needed for uploading 4.2.3 to a PPA
[17:02] <nixternal> are the builds complete and tested for 4.2.3? are they somewhere that anyone can upload? or is it just on vorian?
[17:03] <Riddell> as far as I know only vorian has them, can't see them in any PPA
[17:03] <eagles0513875> btw anyone need anythign tested including 4.2.3 let me know :)
[17:03] <eagles0513875> also i have a site with about 20 free books that i would like to possibly see in karmic too
[17:07] <neversfelde> nixternal: Hi, are you allowed to publish something for the fridge?
[17:07] <Riddell> books don't tend to go in the archive unless they're developer books
[17:09] <nixternal> neversfelde: yes
[17:10] <nixternal> if it is a calendar/event item, anyone can publish that
[17:10] <eagles0513875> Riddell: thats why i would like to link and see what yall think but i have to get back on mydesktop
[17:10] <eagles0513875> and they are bout 20 books one is of ubuntu
[17:10] <neversfelde> nixternal: it is our interview with JontheEchidna, it would be nice to bring it to a larger audience
[17:10] <neversfelde> http://www.kubuntu-de.org/english/interview-with-kubuntu-developer-jonathan-thomas
[17:11] <eagles0513875> i ready that i learned quite alot about the way things are done at canonical and with the ubuntu line
[17:12] <nixternal> neversfelde: roger that, I will get that up for you, thanks
[17:12] <neversfelde> nixternal: nice :). Thank you
[17:16] <Riddell> nixternal: no holding you back is there? :)
[17:17] <eagles0513875> i think when it comes to the dedication to a distro i dont think there is holding anyone back
[17:17] <nixternal> Riddell: nope :)
[17:26] <nixternal> neversfelde: the story is sitting in the queue awaiting proofing and publishing
[17:27] <neversfelde> nixternal: thank you very much
[17:27] <nixternal> no problemo
[17:27] <Riddell> who will proof and publish?
[17:27] <nixternal> the other news editors
[17:27] <nixternal> Riddell: but iirc, you can do that as well :)
[17:27] <nixternal> or you used to be able to
[17:28] <nixternal> as it seems the news editors are busy either sleeping or with their personal life
[17:28] <eagles0513875> want me to do it
[17:29] <eagles0513875> im a minion so ill do anythign to help
[17:29] <Riddell> well it needs an account, dunno if mine still exists
[17:30] <Riddell> http://fridge.ubuntu.com/user has no username or password fieldn?
[17:30] <nixternal> no, you login via OpenID now
[17:30] <nixternal> through LP
[17:30] <nixternal> and if you are on the news team you have access
[17:30] <nixternal> I think
[17:31] <Riddell> nixternal: ok, how do I view the queue?
[17:31] <nixternal> just under the fridge logo up top, you should see your name, and under that "> administer"?
[17:32] <Riddell> ooh I see it
[17:32] <Riddell> "Interview with a Kubuntu Developer" ?
[17:32] <nixternal> yup
[17:32] <nixternal> all you have to do is publish it and set it to the front page iirc
[17:33] <nixternal> Preview it, then set to "Published" and "Promotoed to front page" before clicking submit
[17:33] <Riddell> approved!
[17:33] <nixternal> woot
[17:34] <nixternal> hrmm, I thought the first rule of the Kubuntu Ninja Club, is you don't talk about the Kubuntu Ninja Club
[17:34] <nixternal> ;)
[17:34] <eagles0513875> lol
[17:34] <eagles0513875> well read what jon said if he tells ya he would have to kill ya
[17:51] <Quintasan> hmm what's with REVU?
[17:53] <nixternal> Riddell: are we dput'ing the merges now or just pushing them to bzr?
[17:53] <Riddell> nixternal: I'm just putting them in bzr
[17:53] <nixternal> roger that
[17:54] <Riddell> since if we change phonon everything will need a recompile anyway
[17:54] <Riddell> but 4.3 beta is out tomorrow or sometime soon so I may just start uploading at some point
[17:56] <nixternal> gotcha
[17:56] <neversfelde> nixternal, Riddell: thanks for publishing
[18:00] <nixternal> np
[18:03] <nixternal> Riddell: what are we doing about the changes in control for the kfreebsd stuff? are we merging those in to our stuff?
[18:03] <eagles0513875> ill keep a look out for 4.3 to start testing
[18:04] <Riddell> nixternal: yes, no reason not to
[18:04] <nixternal> groovy, just wanted to make sure
[18:06]  * smarter just noticed that he was still using amarok-kde4
[18:07] <smarter> guess amarok needs a transitional dummy package
[18:07] <apachelogger> Riddell: re packagekit new package issue ... it is a problem in a release because of backports
[18:07] <eagles0513875> apachelogger: not sure if you are aware yoru bot was in and outa here all morning in a number of channels
[18:08] <apachelogger> Riddell: re set_country patch: not sent upstream, not discussed, though I have been told that suse uses a quite similar approach so one way or another upstream should find a way to do this, especially since it has to be patched in about every distro that cares about l10n
[18:09] <Quintasan> smarter: the package should recommend the actual package right?
[18:09] <smarter> more like depend on it
[18:10] <apachelogger> Riddell: come to think of it, our implementation actually doesn't care if the system language was changed ... granted there is a limited use case to that (e.g. when someone moves from _DE to _US) ... but still a dynamic handling as applied for the actually language would be good to have
[18:11] <smarter> apachelogger: heya, do you know that amarok2.1 from k-e is uninstallable? :]
[18:11] <smarter>   amarok: Depends: amarok-common (= 2:2.0.90mysql5.1.30-0ubuntu1~jaunty1~ppa2) but it is not installable
[18:12] <apachelogger> Nightrose: that issue is bogus ... -common is arch all thus getting built on i386, with that having an approx 600 packages long build queue -common was not built before the other arches (i.e. amd and lpia) had built amarok thus the dependency issue which will/has autoresolve(d) once i386 finished building
[18:13] <Nightrose> apachelogger: heh - alright - thanks
[18:13] <apachelogger> smarter: use a sensible arch :P
[18:13] <smarter> x86 never made any sense really :}
[18:14] <apachelogger> smarter: did you push the ext4 patch of kvpm upstream?
[18:14] <apachelogger> certainly hope so :P
[18:14] <smarter> hmm, no, still on my todo list, I was in contact with upstream for some time but either the guy disappeared or he didn't get my last few mails :/
[18:15]  * smarter put higher in the Notes applet on his desktop
[18:15] <smarter> *puts it
[18:15] <apachelogger> smarter++
[18:15] <eagles0513875> <----- upstream minion and testing minion. anything i can help upstream wise smarter
[18:15] <smarter> hey eagles0513875
[18:16] <eagles0513875> hey smarter
[18:16] <apachelogger> eagles0513875: didn't know, all jussi01's fault anyway ... unless someone found a crash bug in the bot and triggered it various times
[18:16] <smarter> eagles0513875: nothing that I can think of atm :p
[18:16] <eagles0513875> apachelogger: it was randomly joining then leaving then reconnecting then leaving
[18:16] <jussi01> whats my fault?
[18:16] <eagles0513875> hahahaha
[18:16] <Quintasan> :D
[18:16] <eagles0513875> jussi01: apachelogger's bot coming in and out constantly this am
[18:17]  * apachelogger notes that this am is a quite relative statement
[18:17] <eagles0513875> this am cet time
[18:17] <apachelogger> just imagine an aussie saying that :P
[18:17] <eagles0513875> lol
[18:17] <eagles0513875> apache thought you were on strike till thursday :p
[18:17] <apachelogger> Nightrose: still not built btw
[18:17] <neversfelde> apachelogger: I corrected plasma-widget-stasks, it is now using pkg-kde-tools. Can you sponsor it to upload? bug 371906
[18:17] <apachelogger> Nightrose: are the script bindings working yet?
[18:18] <apachelogger> neversfelde: I am on strike!
[18:18] <eagles0513875> hahahah
[18:18] <eagles0513875> thats my fault neversfelde shouldnt have said anything
[18:18] <apachelogger> JontheEchidna: ̂
[18:18] <Quintasan> wait, what? plasma widgets now use pkg-kde-tools?
[18:18] <apachelogger> JontheEchidna: go sponsor
[18:18] <apachelogger> JontheEchidna: and find mer a priate minion!
[18:18] <eagles0513875> and how are you on strike apach if you sent out an email re translations and are workign in here
[18:18] <eagles0513875> <---minion here
[18:18] <Nightrose> apachelogger: Ian fixed something yesterday yes
[18:18] <Quintasan> apachelogger: Reporting captain, arrr!
[18:18] <neversfelde> apachelogger: oh no, aren't you working for the government in austria?
[18:18] <apachelogger> neversfelde, JontheEchidna: actually dislike that change
[18:19] <apachelogger> neversfelde: you shoudl apply it when $next upstream release gets out
[18:19]  * Quintasan sighs
[18:19] <apachelogger> there is no need for it to be uploaded just with that change
[18:19] <neversfelde> apachelogger: mhh ok
[18:19] <apachelogger> neversfelde: on a kubuntu strike
[18:20] <agateau> in case you are interested, Canonical DX team is holding a meeting on #ayatana right now
[18:20] <Quintasan> apachelogger: but new plasmoid packages should use it by default?
[18:20] <apachelogger> Quintasan: all new KDE 4 packages
[18:20] <apachelogger> that includes plasmoids
[18:20] <Quintasan> ok
[18:20] <Quintasan> thanks
[18:21] <neversfelde> apachelogger: I think it is a general strike prohibition :)
[18:21] <apachelogger> nielsslot: Estimated build start:
[18:21] <apachelogger> in 21 hours
[18:21] <apachelogger> Nightrose: ̂
[18:21] <apachelogger> nielsslot: sry
[18:21] <apachelogger> neversfelde: nope
[18:21] <eagles0513875> apachelogger: anything i can do to help facilitate any of this building
[18:21] <apachelogger> neversfelde: plus technically I am not working for the government
[18:21] <Nightrose> pffft 21h? get more build servers!!!!1111eleven
[18:22] <apachelogger> Nightrose: tell whoever is in charge of them
[18:22] <Nightrose> ;-)
[18:22] <jussi01> hello Nightrose!
[18:22] <eagles0513875> <--if i can get wubi ill contribute my quad core desktop to the equation of buildserver
[18:22] <Nightrose> heya jussi01
[18:22]  * apachelogger notes that the estimated time was 12 hours or something
[18:22] <apachelogger> that was yesterday afternoon
[18:22] <Nightrose> Oo
[18:22] <jussi01> apachelogger: you using jussi01.com or ubottu.com  (I always forget)
[18:22] <apachelogger> so it actually went up while it should have been built for roughly half a day :P
[18:22] <apachelogger> jussi01: the former I think
[18:23] <nixternal> kdeaccessibility was easy, no merge needed :)
[18:23] <jussi01> apachelogger: ok, thats good. it had some network issues earlier, all fixed now
[18:23] <apachelogger> ok
[18:25] <eagles0513875> jussi01: thats what i was telling him bout
[18:25] <eagles0513875> jussi01: the bot on off issue
[18:25] <neversfelde> what to to, if a package is waiting for reviewing and there is a new upstream version. Shall I do a normal update of the package and reupload to revu or is that confusing?
[18:26] <apachelogger> neversfelde: just replace what is in revu
[18:26] <apachelogger> but don't change the changelog or anything
[18:26] <neversfelde> ok
[18:27] <Quintasan> Hmm, what should I put in debian/copyright if upstream dood provided his nickname only?
[18:28] <smarter> Quintasan: try to hunt him down :]
[18:28] <Quintasan> hmm name is in his mail
[18:29] <smarter> google is your friend most of the time to get name/mail from nick/mail/name
[18:35] <Quintasan> http://lechio.freehostia.com/daisy.html
[18:35] <Quintasan> looks intresting
[18:35] <neversfelde> Quintasan: I am currently working on it
[18:36] <Quintasan> hm? I already have it :P
[18:36] <neversfelde> Quintasan: 0.0.2 is up in revu and I am updating
[18:36] <Quintasan> hmm ok
[18:37] <Quintasan> are you working on any other plasmoids?
[18:37] <Quintasan> I don't think I want to do something done already
[18:37]  * eagles0513875 here to test if needed
[18:37] <neversfelde> Quintasan: have a look at launchpad, there should be a [needs-packaging] bug, when someone is working on a package
[18:38] <neversfelde> I just learned yesterday :)
[18:38] <Quintasan> I'm just looking at those :P
[18:39] <eagles0513875> Quintasan: not sure if you want to package an updated svn snapshot of kvirc 4.0
[18:40] <eagles0513875> the snap shot currently in jaunty is from the beginning of march
[18:40] <Quintasan> eagles0513875: ok
[18:40] <eagles0513875> let me know when you have packaged it :) willing to update what i got to test
[18:44]  * Quintasan just remembered that he has some yummy cake in the fridge
[18:52] <Quintasan> neversfelde: got a deb package for daisy?
[18:53] <neversfelde> Quintasan: sure, but be careful, it is not reviewed yet and the software seems to be a bit buggy
[18:53] <neversfelde> i386?
[18:54] <Quintasan> neversfelde: I don't care :P I can bork m4h system even without installing experimental packages
[18:54] <Quintasan> amd64
[18:54] <neversfelde> Quintasan: than you have to build it by yourself
[18:54] <Quintasan> :<
[18:54] <neversfelde> http://revu.ubuntuwire.com/p/plasma-widget-daisy
[18:55] <neversfelde> PPA build would not be ready until sunday, I guess^^
[18:55] <Quintasan> aah
[18:55] <Quintasan> sync from debian?
[18:56] <neversfelde> there is no debian package?
[18:58] <Quintasan> nvm, just my babbling :P
[18:59] <nixternal> Riddell: should I do an MIR on libindi for kstars?
[19:00] <Riddell> hum
[19:00] <Riddell> it's already been in main
[19:00] <Riddell> it was part of kdeedu
[19:00] <Riddell> so it shouldn't need one
[19:00] <nixternal> it is in universe, indi 0.5 is in main
[19:01] <nixternal> and according to bug reports, doesn't work with kstars
[19:01] <nixternal> bug 359517
[19:02] <a|wen> we need to get the right libindi in main :)
[19:03] <nixternal> right, and by deping on indi (>= 0.5) and kstars not working with it, but works with libindi0 (>= 0.6), I would say libindi0 is the *right* one
[19:03] <a|wen> nixternal: it surely is ... nobody know how that indi package ended up in main
[19:03] <nixternal> if you build kde from trunk, and install the indi package, it still says it can't find the right package, but if you use libindi0, then it works fine
[19:04] <a|wen> nixternal: true ... known
[19:04] <nixternal> i think because indi sounded more promising than libindi :)
[19:04] <nixternal> thought I would have been looking for libindi*-dev
[19:04] <a|wen> nixternal: but the question is if we need a new MIR (as it is just a new version) or can get them exchanged
[19:05] <a|wen> (or indi probably needs to die if it has no rdepends)
[19:05] <nixternal> libindi is a new version packaged correctly
[19:05] <a|wen> exactly :)
[19:05] <nixternal> kstars is the only rdep on indi
[19:06] <nixternal> and libindi is the correct rdep on the other indi packages
[19:06] <a|wen> so who do we need to ask to get the right libindi in, and the wrong indi out...
[19:07] <Riddell> change-override.py -c main -S libindi   done
[19:07] <nixternal> there you go :)
[19:07] <nixternal> was just going to point to any archive admin
[19:07] <nixternal> didn't want to single Riddell out though :)
[19:07] <a|wen> hehe
[19:07] <a|wen> nice :)
[19:08] <nixternal> Riddell: you didn't run that for real though right?
[19:08] <nixternal> hehe
[19:09] <nixternal> vorian: when you go to put 4.2.3 in the PPA, can you make sure that kstars deps on libindi instead of indi, so I will be able to put a bug to rest and make people happy
[19:12] <a|wen> nixternal: we want to put 4.2.3 in updates ... so don't know if we want to do that; but in a seperate PPA, we for sure need that
[19:12] <ScottK> nixternal: libindi is in Universe for Jaunty, so that's a problem.
[19:12] <nixternal> ScottK: even for the PPAs?
[19:13] <nixternal> oh, didn't know it was going to updates, so strike that vorian :)
[19:13] <ScottK> yeah.
[19:17] <a|wen> nixternal: with the new PPA structure the 4.2.3 will end up in the updates-ppa, but we could probably do the w/libindi version in the experimental-ppa
[19:17] <nixternal> right
[19:19] <Quintasan> http://revu.ubuntuwire.com/p/plasma-widget-pgame <-- anyone?
[19:23]  * JontheEchidna takes a look at the above
[19:24] <JontheEchidna> Quintasan: needs to use pkg-kde-tools rather than kde4.mk, but other than that it looks fine
[19:25] <JontheEchidna> also you can use a standards-version of 3.8.1 if you want to
[19:25] <Quintasan> JontheEchidna: so I'll change it :3
[19:27] <Quintasan> debian-qt-kde.mk <-- this one?
[19:27] <JontheEchidna> ya
[19:29] <JontheEchidna> er
[19:29]  * JontheEchidna double checks
[19:30] <JontheEchidna> yeah, that's right
[19:30] <Quintasan> k, testbuilding now
[19:31] <eagles0513875> how does everyone feel on me building an updated snapshot of kvirc 4.0 to update the one in jaunty repos
[19:32] <Quintasan> eagles0513875: I'm working on it. Some patches don't apply :P
[19:32] <eagles0513875> ahhh ok Quintasan according to the about kvirc build info the one in the repos was build on 7th march almost 3 months old
[19:33] <Quintasan> /usr/share/pkg-kde-tools/qt-kde-team/1/debian-qt-kde.mk:1: /usr/share/cdbs/1/class/kde4.mk: No such file or directory
[19:33] <Quintasan> wth?
[19:33] <Quintasan> I still need cdbs in build deps?
[19:34] <JontheEchidna> yeah, definitely
[19:34] <Quintasan> ah, good to know
[19:34] <JontheEchidna> if it built, linitan would whine at you too :P
[19:36] <maco> hey guys, im kinda confused by something. why does quassel only have 7 strings total in rosetta?
[19:36] <Quintasan> JontheEchidna: it whines at me at every time I build something :P
[19:36] <Quintasan> -at
[19:45] <Quintasan> JontheEchidna: check it now if you can :)
[19:46] <fabo> 20:33 < Quintasan> I still need cdbs in build deps?
[19:46] <Quintasan> fabo: ?
[19:46] <fabo> because you used pkg-kde-tools cdbs stuff
[19:47] <Quintasan> ok, I just though it's meant to replace cdbs :P
[19:47] <fabo> you can use debhelper only if you want
[19:47] <fabo> (with pkg-kde-tools)
[19:48] <fabo> include /usr/share/pkg-kde-tools/makefiles/1/variables.mk
[19:49] <Riddell> nixternal: yes I ran it for real
[19:49] <Riddell> fabo: soo, going to look at qt and phonon?
[19:49] <fabo> Riddell: I replied on release and cc'ed you
[19:49] <fabo> it seems fine to use phonon from QT
[19:51] <Quintasan> hmm
[19:51] <Quintasan> I'm going to get some sleep
[19:51] <Quintasan> night
[19:51] <fabo> good night
[19:52] <Quintasan> apachelogger: http://revu.ubuntuwire.com/details.py?upid=5663
[19:54] <eagles0513875> Quintasan: let me know when kvirc is ready to go and ill begin testing the newer snapshot :)
[20:25] <lex79> apachelogger: http://revu.ubuntuwire.com/details.py?upid=5664
[22:52] <nixternal> oops, merged kdenetwork, not kdemultimedia...now I have another one to add to my todo list :)
[23:44] <JontheEchidna> Looks like akonadi needs another merge
[23:58] <nixternal> hrmm, there are patches in kdemultimedia that were never documented in the changelog
[23:59] <nixternal> hrmm, all of the patches are undocumented


[13:00] <BluesKaj> Hiyas all
[15:12] <alekksander> BluesKaj: aye
[15:27] <BluesKaj> hi alekksander
 I have installed Kubuntu 18.10 on my Laptop(Thinkpad T440) but now I facing a problem, when I resume from suspend my trackpad dont work. I have installed Kubuntu 18.04 previously and there was no such problem, the problems appeares after installing kubuntu 18.10
[19:34] <Alexfrench> 18.04 is a lts no ?
[19:35] <diogenes_> yes
[19:35] <diogenes_> super LTS, for 10 years
[19:35] <Alexfrench> so why do not use it a time that's i am doing on my laptop too
[19:36] <Alexfrench> this way i just do updates
[19:36] <diogenes_> Alexfrench, i didn't understand what you mean
[19:37] <acheronuk> Kubuntu LTS is supported for 3 years
[19:37] <diogenes_> oh ok, i just heard that Ubuntu extended the support for 10 yeqrs
[19:37] <diogenes_> years*
[19:38] <acheronuk> diogenes_: Ubuntu desktop is still 5 years. Flavours is 3 years
[19:39] <acheronuk> the '10 years' as far as I'm aware is just extended paid support for server/cloud
[19:44] <diogenes_> acheronuk, ok thanks.
[19:58] <Alexfrench> sorry i ha kids so i am not always present
[19:58] <Alexfrench> have
[20:05] <diogenes_> Alexfrench, congrats!
[20:07] <Alexfrench> thanks it is hard but it is life
[20:18] <diogenes_> at least there will be someone to visit us when we end up in the nursing home lol