[00:19] -queuebot:#ubuntu-release- New source: plasma-wallpaper-dynamic (groovy-proposed/primary) [3.3.3-0ubuntu1]
[00:21] -queuebot:#ubuntu-release- New source: jack-mixer (groovy-proposed/primary) [13-0ubuntu1]
[00:35] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-189.219] (core, kernel)
=== sysop is now known as Guest27913
[00:37] <vorlon> LocutusOfBorg: yeah, x264 just picked up another entangled transition from just-synced libcdio, so dumping contextfree now
=== Guest27913 is now known as Bashing-om
[01:16] -queuebot:#ubuntu-release- New binary: ntopng [amd64] (groovy-proposed/universe) [3.8.1+dfsg1-1build1] (no packageset)
[01:22] -queuebot:#ubuntu-release- New binary: ntopng [armhf] (groovy-proposed/universe) [3.8.1+dfsg1-1build1] (no packageset)
[05:46] -queuebot:#ubuntu-release- New: accepted ntopng [amd64] (groovy-proposed) [3.8.1+dfsg1-1build1]
[05:46] -queuebot:#ubuntu-release- New: accepted ntopng [armhf] (groovy-proposed) [3.8.1+dfsg1-1build1]
[06:48] <Mirv> has the topic ever been discussed whether it could or should be prevented that urls like https://releases.ubuntu.com/20.04/ubuntu-20.04-desktop-amd64.iso stop working on the day of .1 release etc?
[06:48] <Mirv> or if that's preferable instead
[06:49] <Mirv> I could see it's preferable from letting people always use the official pages, but the official pages aren't localized so LoCos tend to maintain their own pages
[07:06] <Mirv> I'm also still missing Lubuntu 14.04 from old-releases, while it has been removed from releases
[07:28] <LocutusOfBorg> vorlon, you know, haskell-cborg-json might need another hammer? haskell-cborg-json unsatisfiable Build-Depends(-Arch) on armhf: libghc-cborg-dev (>= 0.2)
[07:37] <LocutusOfBorg> ghc: 8.8.4-1	proposed (universe)	8 hours ago
[07:37] <LocutusOfBorg> world: why do you hate me so much?
[07:38] <vorlon> LocutusOfBorg: sorry, that was an NBS binary in -proposed; I managed to remove -dev but not -prof
[07:38] -queuebot:#ubuntu-release- New: accepted hg-git [amd64] (groovy-proposed) [0.9.0-1]
[07:38] -queuebot:#ubuntu-release- New: accepted pytest-twisted [amd64] (groovy-proposed) [1.12-1]
[07:40] <LocutusOfBorg> vorlon, I would rollback ghc when it finishes building, so we can let this haskell migrate and start rebuilds?
[07:40] <vorlon> Mirv: I don't recall this having been discussed
[07:40] <LocutusOfBorg> thanks for doing it :)
[07:40] <LocutusOfBorg> (the json removal)
[07:40] <LocutusOfBorg> btw x264 rebuilds missed mythtv, I issued it now
[07:41] <vorlon> LocutusOfBorg: so this is rolling back to 8.8.3-3?
[07:41] <LocutusOfBorg> not sure if you left it behind because it was in multiverse, or something else :D
[07:41] <LocutusOfBorg> vorlon, rolling it back, will let the current mini transition end
[07:41] <vorlon> yeah, I didn't have multiverse enabled in my sources when I ran that script, sorry
[07:41] <LocutusOfBorg> but better wait for it to finish building? :)
[07:41] <vorlon> ok; in that case, catch me in my morning if no one else takes care of it
[07:42] <LocutusOfBorg> oh nice to know, I always wonder if people do not issue rebuilds because they know about some ftbfs or such
[07:42] <LocutusOfBorg> well, riscv64/armhf takes days to finish
[07:42] <LocutusOfBorg> I'm wondering if we should just kick it out
[07:42] <LocutusOfBorg> in days, the current ghc transition will end, I'm at level 18...
[07:42] <LocutusOfBorg> we can upload 8.8.4-1build1
[07:43] <LocutusOfBorg> so, if you want to kick it out, please go ahead :D
[07:46] <vorlon> done
[07:47] <vorlon> (rolling back ghc)
[07:49] <vorlon> rolling back dovecot :P
[08:00] <seb128> hey vorlon , I see you went for rolling back libreoffice, I guess it means no icu migration before next week now?
[08:00] <seb128> with hoping that the revert doesn't get the armhf issue...
[08:02] <seb128> (which I'm not convinced about since 6.4.5 autopkgtests are green on the focal SRU which is the same source so it could be a toolchain or rdepends issue)
[08:02] <Laney> I would have waited to hear back from us :/
[08:02] <Laney> I was quite deliberate in my use of skiptest vs badtest
[08:11] <LocutusOfBorg> tjaalton, what is happening?
[08:11] <LocutusOfBorg> dpkg: error processing archive /tmp/apt-dpkg-install-IzpqYj/460-libraspberrypi0_0~20200520+git2fe4ca3-0ubuntu1_armhf.deb (--unpack):
[08:11] <LocutusOfBorg>  trying to overwrite '/usr/lib/arm-linux-gnueabihf/libEGL.so', which is also in package libegl-dev:armhf 1.3.2-1
[08:12] <LocutusOfBorg> (mythtv fails to build on armhf) ^^
[08:14] <tjaalton> where?
[08:17] <LocutusOfBorg> mythtv on armhf
[08:17] <tjaalton> what's libraspberrypi0?
[08:17] <LocutusOfBorg> who knows?
[08:17] <tjaalton> complain to it's maintainer
[08:17] <LocutusOfBorg>  libraspberrypi0 | 0~20200520+git2fe4ca3-0ubuntu1 | groovy/universe | arm64, armhf
[08:17] <LocutusOfBorg> ok its mesa related, this is why I'm pinging you
[08:18] <tjaalton> libegl-dev is built by libglvnd
[08:18] <tjaalton> and it's the right place to have these
[08:19] <LocutusOfBorg> maybe on raspberrypi they need to break/replaces them?
[08:19] <tjaalton> pull-lp-source says it's not in ubuntu
[08:20] <LocutusOfBorg> tjaalton, not build on amd64
[08:20] <LocutusOfBorg> found it https://launchpad.net/ubuntu/+source/raspberrypi-userland/0~20200520+git2fe4ca3-0ubuntu1
[08:20] <LocutusOfBorg> waveform, ^^
[08:20] <LocutusOfBorg> I blame you :p
[08:27] <LocutusOfBorg> for now I'm removing libraspberrypi dependency on armhf
[08:29] <tjaalton> libEGL.so (and libGLESv2.so) are only built on armhf for some reason, arm64 doesn't build those
[08:30] <LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/libglvnd/+bug/1891613
[08:30] <ubot5> Ubuntu bug 1891613 in raspberrypi-userland (Ubuntu) "libraspberrypi0 not installable" [High,Confirmed]
[08:30] <LocutusOfBorg> tjaalton, ^^ if you want to provide some input, I opened a bug
[08:30] <tjaalton> wrong target
[08:30] <tjaalton> ah it had both
[08:30] <tjaalton> I already commented the packaging bug
[08:31] <tjaalton> breaks/replaces would be wrong, as the system would still have libEGL.so.1 from libglvnd
[08:32] <tjaalton> libegl1 deb
[08:39] <LocutusOfBorg> thanks
[08:55] <seb128> Laney, thanks for the by team change review!
[08:57] <Laney> np
[08:57] <Laney> thanks for the change :>
[09:05] <seb128> Laney, I was thinking also adding the 'implicit depends' info to the report, does that make sense to you? it would give some context for e.g libcdio ... but things changed there right? those used to be candidate but fail in update_excuses no?
[09:11] <Laney> seb128: might get too noisy?
[09:11] <Laney> you could maybe say 'breaks some other packages, see excuses'
[09:13] <seb128> right, those lists are a bit long, that might be an option
[09:16] <seb128> or maybe it's ok if that's a list space separate of source names without an entry for each arch?
[09:16] <seb128> Laney, thanks for the input, I will try and see how the reports looks like
[09:43] <juliank> Laney: Just saw the email with the instances without autopkgtests, are you looking into that by any chance?
[09:44] <juliank> Oh I see ones from 9 hours ago, I guess spam filter ate the ones in between
[09:44] <Laney> juliank: nop
[09:45] <juliank> so many errors, aargh!
[09:45] <juliank> are tests still running?
[09:45] <juliank> the queues seem empty
[09:46] <Laney> yes it looks ok
[09:46] <Laney> are you talking about bos02?
[09:47] <juliank> bos02 seemed to cause some errors last night
[09:47] <juliank> also is there a bug in urllib3?
[09:48] <juliank> ah but yes, these errors are all bos02
[09:48] <Laney> maybe there was some overnight blip
[09:48] <juliank> Traceback (most recent call last):
[09:48] <juliank>   File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 377, in _make_request
[09:48] <juliank>     httplib_response = conn.getresponse(buffering=True)
[09:48] <juliank> TypeError: getresponse() got an unexpected keyword argument 'buffering'
[09:48] <Laney> if those instances are stuck deleting, ask the ~IS vanguard to reset-state active && delete them
[09:48] <juliank> hmm
[09:48] <juliank> this is weird
[09:48] <juliank> :D
[09:49] <Laney> dunno what that is
[09:49] <juliank> the errror is WARNING:root:instance adt-groovy-s390x-emboss-20200813-193914 (29072e49-ea49-40b1-97ff-5bf1283648ad) has no associated autopkgtest (auth_url: http://keystone.infra.bos02.scalingstack:5000/v2.0/)
[09:49] <juliank> for a bunch of them
[09:49] <Laney> they look stuck, it happens when the cloud has a sad sometimes
[09:49] <Laney> go ask IS to intervene per ^
[09:49] <Laney> perhaps that situation also tickles a bug in the openstack client tools :(
[09:51] <juliank> I'll retry and look if it still happens
[09:57] <Laney> cheers!
[09:57] -queuebot:#ubuntu-release- Unapproved: accepted bind9-libs [source] (focal-proposed) [1:9.11.16+dfsg-3~ubuntu1]
[10:13] -queuebot:#ubuntu-release- Unapproved: accepted build-essential [source] (focal-proposed) [12.8ubuntu1.1]
[10:17] -queuebot:#ubuntu-release- New binary: build-essential [amd64] (focal-proposed/main) [12.8ubuntu1.1] (core, i386-whitelist)
[10:36] <waveform> LocutusOfBorg, thanks for the ping - taking a look
[10:50] <doko> Laney: LO succeeded to build in the groovy test rebuild
[11:29] <tjaalton> waveform: you probably shouldn't need to build libEGL etc on armhf, check why it does build them and disable by force if necessary
[11:30] <waveform> tjaalton, indeed - it's building a brcm-specific EGL for use on the pi0-3 apparently (and the arm64 builds done't include them as the pi4 only supports the mesa drivers and the pi foundation only (officially) support arm64 on the pi4)
[11:31] <tjaalton> ugh
[11:34] <waveform> just digging into the cleanest way of dealing with this - apparently there are some vaguely important use-cases where the brcm-specific EGL is needed, but the library seems to build both libEGL and libbrcmEGL (+all the rest) so I'll try and excise the former and leave the latter
[11:35] <tjaalton> so the worst-case scenario is that you rename the conflicting libs (to have a .1), then add diversions
[11:36] <tjaalton> libGLESv2.so -> libGLESv2.so.2
[11:43] -queuebot:#ubuntu-release- New binary: budgie-wallpapers [amd64] (groovy-proposed/universe) [20.10] (personal-fossfreedom, ubuntu-budgie)
[11:44] <tjaalton> waveform: I think the entrypoint for the brcm-stuff is in libEGL/GLESv2, so looks like you can't avoid shipping them
[11:47] <waveform> actually I'm not so sure about that ... just noticed libEGL.so has exactly the same size as libbrcmEGL.so which makes me ... suspicious - just digging into the CMake stuff
[11:48] <waveform> ah yes, just compiled from the same source with different names below the comment "# recommended names to use to avoid conflicts with mesa libs" :)
[11:49] <waveform> so, should be okay to exclude the "mesa-named" duplicates and just leave the brcm ones
[11:50] <tjaalton> okay..
[12:00] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.664.5]
[12:02] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (bionic-proposed) [2.525.46]
[12:05] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.47]
[12:07] <LocutusOfBorg> waveform, can you please ping back once you have a fix?
[12:07] <waveform> LocutusOfBorg, will do
[12:07] <LocutusOfBorg> so I can fix mythtv :D
[12:10] -queuebot:#ubuntu-release- Unapproved: rejected intel-microcode [source] (bionic-proposed) [3.20191115.1ubuntu0.18.04.3]
[12:43] <waveform> LocutusOfBorg, added a patch to LP: #1891613
[12:43] <ubot5> Launchpad bug 1891613 in raspberrypi-userland (Ubuntu) "libraspberrypi0 not installable" [High,Confirmed] https://launchpad.net/bugs/1891613
[13:02] -queuebot:#ubuntu-release- Builds: 42 entries have been added, updated or disabled
[14:11] <LocutusOfBorg> waveform, sponsoring
[14:41] -queuebot:#ubuntu-release- New binary: linux-signed-azure-4.15 [amd64] (bionic-proposed/main) [4.15.0-1093.103] (no packageset)
[15:32] <vorlon> Laney, seb128: if you're comfortable with a skiptest on libreoffice, we can still cancel out this rebuild and revive the 6.4.5 binaries
[15:35] <vorlon> but what the heck do we do with node-redis anyway, it regresses on arm64 with a no-change rebuild of nodejs
[15:36] <Laney> vorlon: I only skiptested some other things which were waiting on this libreoffice
[15:36] <Laney> let's see how your 6.4.4 pans out, if that fails too then I have some gcc-9 builds in progress which might (or might not) fare better
[15:39] <rbalint> vorlon, i've just started reproducing node-redis, will see how it goes
[15:40] <seb128> Laney, but then we still need to wait for days of libreoffice rdepends validating their autopkgtests, including retries because we know those are flaky
[15:40] <vorlon> rbalint: bdmurray said he got it to work in canonistack, so maybe this is something that needs to be added to the big_test list instead of long_test?
[15:40] <vorlon> we have individual test timeouts, which were maybe borderline before and succeed in a heftier environment
[15:40] <rbalint> vorlon, sounds possible
[15:41] <seb128> Laney, vorlon , I've a feeling it's going to take at least another week until we clear our a libreoffice rebuilds :/
[15:41] <rbalint> vorlon, also if it passes locally we can just hint it
[15:42] <bdmurray> speaking of node-redis I'll remove it from long_tests since that was an error
[15:42] <vorlon> seb128: I hope not, 6.4.5 builds only need 19h and if the tests are /working/, that should only be another 100h
[15:42] <vorlon> sorry, 10h ;)
[15:42] <vorlon> bdmurray: do you want to go ahead and add it to big_tests at the same time and we'll see what happens?
[15:42] <bdmurray> vorlon: okay
[15:42] <seb128> vorlon, let's see on monday I guess
[15:42] <Laney> seb128: libreoffice only has a few rdepends, it's not that bad
[15:43] -queuebot:#ubuntu-release- New binary: haskell-gi-pango [ppc64el] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
[15:43] <seb128> Laney, right, I guess it's ok when we don't have a backlog of 3 days on armhf as we had recently
[15:44] -queuebot:#ubuntu-release- New binary: haskell-gi-pango [amd64] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
[15:44] -queuebot:#ubuntu-release- New binary: haskell-gi-pango [s390x] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
[15:45] <rbalint> vorlon, bdmurray ok, then i don't try reproducing node-redis again, moving on to other packages
[15:46] <bdmurray> vorlon: updated
[15:50] <vorlon> tjaalton: fwiw livecd-rootfs 2.525.47 was accepted despite being built with wrong -v option, and there's no SRU tracking for the bug linked from the 2.525.46 changelog...
[15:55] <bdmurray> LocutusOfBorg: juliank suggested another packaging change for bug 1886748 - moving libomp-9-dev from a Recommends to a Suggests of clang-9. Would that work for you?
[15:55] <ubot5> bug 1886748 in ubuntu-release-upgrader (Ubuntu Focal) "upgrade from 18.04 to 20.04 fails to calculate if libomp5 is installed" [High,Confirmed] https://launchpad.net/bugs/1886748
[15:56] <juliank> I feel like I want to have distribution upgrade hints for apt at some point
[15:56] <juliank> but also this would be hard to hint :D
[15:57] <juliank> I should just get a new state of the art solver done
[15:59] -queuebot:#ubuntu-release- New binary: haskell-gi-pango [arm64] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
[16:02] <vorlon> bdmurray: workers restarted with updated config, if you want to retry node-redis
[16:05]  * Laney fixes .manifest on ancientminister to unbreak sync-mirrors
[16:06] <bdmurray> vorlon: I've pushed the button
[16:07] <Laney> no idea why it was only budgie triggering that
[16:10] <vorlon> xnox: did you not have a git branch somewhere for the proposed grub preinst work?
[16:15] <rbalint> ubuntu-archive, could you please demote rust-tokio-core do groovy-proposed due to LP: #1891679 to unblock other rust packages?
[16:16] <ubot5> Launchpad bug 1891679 in rust-tokio-core (Ubuntu) " rust-tokio-core: FTBFS: build-dependency not installable: librust-scoped-tls-0.1+default-dev" [Undecided,New] https://launchpad.net/bugs/1891679
[16:16] <rbalint> ubuntu-archive or i should ask for a batch later
[16:17] <vorlon> rbalint: demote> no, but I'll remove it
[16:18] <vorlon> the package build-depends on an obsolete version, so it's not going to come back without a sourceful fix - so I don't want this cluttering -proposed, I want it removed to leave the Debian maintainers to deal with it
[16:18] <LocutusOfBorg> bdmurray, I don't understand to be honest, if it works, I'll be happy
[16:19] <rbalint> vorlon, ack, thanks, would you be open to demotions for packages that can migrate in theory later>
[16:19] <rbalint> ?
[16:19] <vorlon> rbalint: yes
[16:23] <vorlon> xnox: n/m, found the preinst mp, thanks
[16:23] <vorlon> rbalint: yes
[16:25] <doko> vorlon: tjaalton wants a SRU template for your pycurl SRU
[16:28] <vorlon> fair
[16:29] -queuebot:#ubuntu-release- Unapproved: gnome-shell (bionic-proposed/main) [3.28.4-0ubuntu18.04.3 => 3.28.4-0ubuntu18.04.4] (desktop-extra, mozilla, ubuntu-desktop)
[16:34] <vorlon> tjaalton, doko: added
[16:37] <xnox> vorlon:  i'm discussing it with debian maintainer, and we don't want preinst work.
[16:37] <vorlon> xnox: why?
[16:37] <xnox> vorlon:  adding checks in postinst, to check that devices exist before calling grub-install. Such that MBR and /boot never get out of sync.
[16:37] <xnox> vorlon:  having newer modules in /usr/lib is ok (and like non-matching the ones in /boot)
[16:38] <xnox> vorlon:  also it's my action to follow up on all that.
[16:38] <vorlon> xnox: having them in /usr/lib allows for the possibility that other packages might call grub-install behind our back despite grub-pc not being configured
[16:38] <xnox> vorlon:  apart from cloud-init, which we are the ones pushing to call grub-install, what else calls grub-install?
[16:39] <xnox> other packages only call update-grub that regenerates grub.cfg, but doesn't update mbr/efi.
[16:39] <xnox> (and i consider shim-signed/grub-* packages to be cooperating ones)
[16:39] <vorlon> xnox: and if it's a non-interactive upgrade, your only choice in the postinst is to exit 1, which leaves the package unconfigured; don't we think that's worse that having it fail to unpack?
[16:40] <vorlon> xnox: yeah and shim only calls grub-install for the efi target, so not affected.  Ok, if we expect nothing to call grub-install behind our backs, then that part is reasonable
[16:40] <xnox> vorlon:  failing preinst will leave the system in a worse state, aborting upgrade transaction much earlier.
[16:40] <xnox> (with a lot more packages unpacked, and not configured)
[16:41] <vorlon> xnox: I don't see why this is a worse state
[16:42] <vorlon> unpacked but not configured> do-release-upgrade attempts to clean this up
[16:47] <xnox> vorlon:  if that's your agrument, surely it should be 'config' and not 'preinst'. and it will none-the-less duplicate a lot of the question logic, no?
[16:47] <vorlon> xnox: config does not block the upgrade.
[16:47] <vorlon> apt ignores non-zero exit values when invoking the config scripts in the pre- stage
[16:48] <LocutusOfBorg> waveform, and it migrated, thanks for fixing so quickly
[16:48] <xnox> amazing
[16:48] <waveform> LocutusOfBorg, no prob - slightly embarrassed I didn't notice the armhf issue before! (spending too much time on arm64 :)
[16:49] <xnox> vorlon:  i feel that postinst fixes are a must. preinst fixes are nice to have. in the context of non-interactive upgrades => postinst is what we must fix.
[16:49] <vorlon> xnox: fair.  but we also need to fix the behavior of grub-install itself
[16:49] <xnox> vorlon:  in terms of do-release-upgrade, i feel there might not even be any need to fix anything, becuase it is interactive, and the failed-devices debconf flow is asked.
[16:50] <vorlon> the user might have set a non-interactive frontend for do-release-upgrade, I think?
[16:50] <xnox> vorlon:  and yes, behaviour of grub-install itself is suboptimal, and needs to be fixed upstream. That is a separate task from maintainer scripts stuff.
[16:50] <vorlon> xnox: it is a separate task, but also blocking for turning on 20.04 upgrades
[16:50] <xnox> vorlon:  and what colin is fixing is not just "exit 1" but "do not attempt to call grub-install when devices are non-existant" meaning exit 1 is before attempting to bork the machines.
[16:51] <xnox> with that fix alone, it would be enough to turn on upgrades. As postinst will fail non-interactively without borking things up.
[16:51] <xnox> and interactively there is failed-devices flow to correctly upgrade.
[16:51] <xnox> without a huge code dump of preinst changes or grub-install itself fixes.
[16:52] <xnox> also i'm failing at not working =)
[16:52] <xnox> vorlon:  i'd like to see postinst changes that colin is thinking off, to prevent calling grub-install on any devices, if any of the install-devices are missing.
[16:52] <vorlon> that's fine
[16:52] <vorlon> we still have the weird case in amazon where grub-install is called for a device that exists, then strangely fails
[16:53] <xnox> (that seems to achieve what we desired with preinst, whilst keeping all that in postinst)
[16:53] <vorlon> amazon?  azure
[16:53] <xnox> azure yes.
[16:53] <xnox> on a single serial which i am still debugging.
[16:53] <vorlon> regardless, despite being uncommon, I'd like us to have grub-install itself robustified before turning on upgrades
[16:53] <xnox> i have copies of what is in azure, and what we have locally, that do not match.
[16:53] <vorlon> anyway, this can all wait until Monday
[16:53] <xnox> it seems like an image got somehow missbuilt/missuploaded
[16:54] <xnox> "I'd like us to have grub-install itself robustified before turning on upgrades" => ack.
[16:54] <vorlon> I just was making sure we had a proper tracking bug for this (whose description / scope can be amended as appropriate) to make it clear to the release team what is blocking turning on upgrades
[16:55] <xnox> ack
[16:58] <xnox> vorlon:  it really does feel like "grub-install" was only ever meant as install, and was never meant to be "upgrade"
[17:08] <rbalint> vorlon, rust-gtk was removed with 'broken with new dh-cargo', but it is now in testing in Debian again
[17:09] <rbalint> vorlon, could you please resurrect it to groovy-proposed or is should get more confirmation that it would work?
[17:09] <rbalint> vorlon, or i should upload it with build1 myself
[17:15] <Laney> rbalint: you should be able to do the copy back to proposed yourself, just fyi - assuming no rebuid is needed vs the previous binaries
[17:15] <Laney> bye o/
[17:23] <rbalint> Laney, wow, thanks!
[17:23] -queuebot:#ubuntu-release- New sync: rust-gtk (groovy-proposed/primary) [0.7.0-1]
[17:42] -queuebot:#ubuntu-release- Packageset: Added redkite to ubuntustudio in groovy
[17:54] <vorlon> rbalint: yeah, copy-package -b -e $version --force-same-destination -s groovy-proposed $srcpkg
[18:49] <rbalint> vorlon, it worked, but i still need it to be accepted from NEW :-)
[18:49] <rbalint> vorlon, so please accept it
[18:56] -queuebot:#ubuntu-release- New binary: haskell-gi-pango [armhf] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
[18:58] -queuebot:#ubuntu-release- New binary: haskell-gi-pango [riscv64] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
[19:05] <sergiodj> friendly ping to archive-admin re. the telegraf package that's sitting on the NEW queue.  thanks
[19:46] -queuebot:#ubuntu-release- Unapproved: ceph (focal-proposed/main) [15.2.3-0ubuntu0.20.04.1 => 15.2.3-0ubuntu0.20.04.2] (desktop-core, ubuntu-server)
[20:58] <LocutusOfBorg> please process haskell-gi-pango ^^
[21:26] <rbalint> ubuntu-archive please remove predictprotein https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963927
[21:26] <ubot5> Debian bug 963927 in predictprotein "predictprotein:Unusable, fails with: Assigning non-zero to $[ is no longer possible" [Serious,Open]
[21:27] <rbalint> ubuntu-archive please demote rust-crossbeam to groovy-proposed , it is removed from testing, too, and blocks rust-crossbeam-utils
=== sysop is now known as Guest23943
=== Guest23943 is now known as Bashing-om
[23:47] <bdmurray> vorlon: node-redis still failed