[08:39] <seb128> fossfreedom, hey, saw your message from yesterday. I don't think it's know, did you report a bug? can you share the journal from a failed login/session?
[09:30] <fossfreedom> Will do tonight seb128 ... but someone else reported this to me yesterday and I suspect it may be the same issue bug #1796437 since I installed the daily with the restricted installer options in a qemu VM
[09:33] <seb128> fossfreedom, I see, interesting
[11:28] <gpiccoli> Hi sil2100, vorlon - I'd like to ask about mdadm. As discussed last week, we should drop the dannf 's version from proposed while kernel team figures out the kernel counter-part of the raid0 layout issue. And then, if possible, upload the following verion to proposed: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1847924
[11:29] <gpiccoli> s/verion/version
[11:47] <sil2100> gpiccoli: ok, on it right now - I actually started looking at it last time but then got preempted
[11:49] <gpiccoli> Awesome sil2100, really appreciated =)
[12:15] <sil2100> rbasak: hey! So I'm reviewing gpiccoli's mdadm right now and I think it looks okayish now - since you were the original reviewer I wanted to know your feelings about it before I proceed
[13:42] <rbasak> sil2100: o/
[13:42] <rbasak> Thank you for the ping.
[13:43] <rbasak> I haven't had a chance to look yet, but I think you're on the same page as me on that one so if you're happy I'm happy.
[13:47] <ahasenack> I retrigger krb5/i386 dep8 with all-proposed=1. I can't reproduce that dependency error from the log in a lxd container with i386 arch added and proposed enabled
[13:50] <AsciiWolf> hi, has someone here rights to sync packages from Debian? if so, could please someone sync steam and related packages? it is still on version 1.0.0.54 (even on latest Ubuntu Focal) that is really old and does not contain proper udev rules from Steam Controller or VR
[13:52] <AsciiWolf> there was a proposal to remove the steam package completely from Ubuntu (see https://bugs.launchpad.net/ubuntu/+source/steam/+bug/1759715), maybe it was added to sync blacklist, but not actually removed?
[13:52] <ahasenack> AsciiWolf: it has a delta, that's why it wasn't auto-synced
[13:53] <ahasenack> see changelog: https://launchpad.net/ubuntu/+source/steam/1:1.0.0.54+repack-5ubuntu1
[13:53] <ahasenack> tsimonq2: you are the current TIL :)
[13:53] <ahasenack> ^
[13:59] <ahasenack> can anybody tell what happened to the galera-arbitrator-3 binary from https://launchpad.net/ubuntu/+source/galera-3/25.3.28-2/+build/18262764 ?
[14:00] <ahasenack> I don't see it in the focal/amd64 archive
[14:01] <ahasenack> rbasak: any idea? ^
[14:02] <cjwatson> https://launchpad.net/ubuntu/focal/amd64/galera-arbitrator-3
[14:02] <cjwatson> Deleted on 2020-01-16 by Steve Langasek: NBS
[14:04] <ahasenack> hm, https://launchpad.net/ubuntu/+source/galera-3/+publishinghistory doesn't even go that far, stops in december 2019
[14:06] <ahasenack> cjwatson: how did you get that link, to the binary package? From https://launchpad.net/ubuntu/+source/galera-3/25.3.28-2 somewhere?
[14:08] <cjwatson> regrettably that's a URL structure you just have to know :(
[14:08] <ahasenack> ok
[14:08] <ahasenack> so a binary was removed, but the source is still there, and we have dep8 tests failing because galera-arbitrator-3 no longer exists
[14:08] <cjwatson> although the section under "Binary packages" from e.g. https://launchpad.net/ubuntu/+source/galera-3/25.3.28-2/+build/18262764 links to under it
[14:09] <ahasenack> ah, "Binary packages built by this source"
[14:09] <cjwatson> A removal with the reason "NBS" implies that the source package doesn't actually build it any more
[14:09] <ahasenack> that's good enough
[14:09] <ahasenack> cjwatson: but then the other binary should have been removed too I think
[14:10] <ahasenack> let me try to build it
[14:10] <ahasenack> or maybe we want to transition to galera-4 instead of having both
[14:10] <ahasenack> (different source)
[14:10] <cjwatson> I admit I'm a little confused about why this was NBS
[14:11] <cjwatson> https://launchpad.net/ubuntu/+source/galera-3/+publishinghistory suggests it's still there
[14:11] <cjwatson> since the most recent version built that binary
[14:11] <cjwatson> vorlon: ^- would you care to investigate/clarify?
[14:12] <cjwatson> NBS removals are usually in bulk, but this does look a bit weird
[14:16] <ahasenack> it just built fine in current focal-proposed
[14:24] <ahasenack> vorlon: also, when you have a moment, I don't know how to solve https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/k/krb5/20200121_135633_61618@/log.gz
[14:24] <ahasenack> # apt install build-essential
[14:24] <ahasenack>  build-essential : Depends: libc6-dev but it is not going to be installed or
[14:24] <ahasenack>                             libc-dev
[14:24] <ahasenack>                    Depends: g++ (>= 4:9.2) but it is not going to be installed
[14:25] <ahasenack> goes all the way down to installing linux-libc-dev which wants to remove a bunch of :i386 packages
[14:45] <Odd_Bloke> Is it Subiquity or SUbiquity?  (I'm seeing both capitalisations in places, and want to know which ones I should be proposing fixes for. :)
[14:47] <ahasenack> I only saw subiquity so far
[14:48] <ahasenack> rafaeldtinoco: the net-snmp update_output.txt list is smaller, did you check what is missing yet? I saw that google-cloud-print-connector migrated, that was the last one?
[14:49] <rafaeldtinoco> ahasenack: i checked them all
[14:49] <rafaeldtinoco> and updated the card ... but I *think*
[14:49] <rafaeldtinoco> they were all done
[14:49] <rafaeldtinoco> let me see the card
[14:49] <ahasenack>     * i386: cluster-glue, colord, colord-tests, corosync-notifyd, libopenhpi-dev, libsane, libsane-dev, libsane1, openhpi-plugin-ipmi, openhpi-plugin-snmp-bc, openipmi, php7.3-snmp, sane-utils
[14:49] <ahasenack> that is the current output
[14:49] <rafaeldtinoco> frr missing s390x
[14:49] <rafaeldtinoco> php7.3 arm64 3 issues
[14:50] <rafaeldtinoco> s390-tools needs approval by hand
[14:50] <rafaeldtinoco> sane-backends failed on gscan2pdf arm64
[14:50] <rafaeldtinoco> those were the last issues i could see
[14:50] <rafaeldtinoco> for the revdependencie on libsnmp35
[14:52]  * ahasenack checks revdeps in focal-proposed
[14:54] <ahasenack> hm, still many revdeps for libsnmp30
[14:54] <ahasenack> libsnmp35 is the new one, right
[14:55] <rafaeldtinoco> yep
[14:56] <ahasenack> hm, reverse-depends isn't very smart, it's listing wnmd-snmp even though there is a build that doesn't depend in libsnmp30
[14:56] <ahasenack> there could be an option to only consider the latest version of a package, if multiple come up
[14:59] <rafaeldtinoco> yep =(
[15:00] <ahasenack> rafaeldtinoco: weird, google-cloud-print-connector still depends on libsnmp30
[15:00] <ahasenack> 1.12-1ubuntu1
[15:03] <ahasenack> that's weird, build logs show it pulling in libsnmp35
[15:03] <ahasenack> but in the end:  Depends: libavahi-client3 (>= 0.6.16), libavahi-common3 (>= 0.6.16), libc6 (>= 2.4), libcups2 (>= 1.7.0), libsnmp30
[15:04]  * ahasenack checks if that isn't hardcoded
[15:04] <ahasenack> argh
[15:04] <ahasenack> rafaeldtinoco: you have a hardcoded libsnmp30 in d/control in that package
[15:05] <rafaeldtinoco> =(
[15:05] <rafaeldtinoco> damn
[15:05] <rafaeldtinoco> i might have missed hardcoded libsnmp30
[15:07] <rafaeldtinoco> you have to teach me the secret language you use to read the flags in the other excuses file
[15:07] <rafaeldtinoco> =)
[15:08] <ahasenack> oh, it's simple, it's always bad news
[15:09] <ahasenack> :)
[15:09] <ahasenack> do a rebuild of that package without that hardcoded dep and just make sure the automatic libsnmp35 dep is added, then it's good to upload
[15:09] <ahasenack> and check if that came from debian
[15:10] <ahasenack> might want to suggest the fix to them as well
[15:10] <rafaeldtinoco> +1
[15:10] <rafaeldtinoco> thx for checking all this
[15:10] <rafaeldtinoco> ive been scripting for ours now
[15:10] <rafaeldtinoco> need a coffee
[15:14] <ahasenack> rafaeldtinoco: zabbix also needs a rebuild
[15:14] <rafaeldtinoco> same issue ?
[15:14] <rafaeldtinoco> i think i missed all hardcoded libsnmp30
[15:14] <rafaeldtinoco> i assumed they were not hardcoded
[15:14] <ahasenack> it's in your card, but shows a dep on the lib
[15:14] <ahasenack> let me check d/control
[15:14] <rafaeldtinoco> do not assume, check <- rule missed
[15:15] <ahasenack> no, this one doesn't have libsnmp30 hardcoded
[15:15] <ahasenack> where is your rebuild?
[15:16] <ahasenack> https://launchpad.net/ubuntu/+source/zabbix/+publishinghistory I don't see it
[15:18]  * rafaeldtinoco checks
[15:18] <ahasenack> I'm going over it just because it's my triage/migration day :)
[15:19] <rafaeldtinoco> AH
[15:19] <ahasenack> so I see what is stuck and check why
[15:19] <rafaeldtinoco> i thought the new build had fied the dep issue
[15:19] <rafaeldtinoco> so I didnt upload it for a new build
[15:26] <ahasenack> rafaeldtinoco: s390-tools is stuck because another source, called s390-tools-signed (https://launchpad.net/ubuntu/+source/s390-tools-signed) needs to match the same version
[15:26] <ahasenack> it looks a bit weird. xnox, can you confirm? ^
[15:27] <ahasenack> just needhttps://launchpad.net/ubuntu/+source/s390-tools and  need to match like that?
[15:27] <ahasenack> if one is rebuilt/bumped, the other needs to as well?
[15:38] <rafaeldtinoco> ahasenack: when I saw
[15:38] <rafaeldtinoco> s390-tools needed autorization for migration
[15:41] <ahasenack> ok
[15:41] <ahasenack> right now it's "s390-tools/s390x unsatisfiable Depends: s390-tools-signed (= 2.11.0-0ubuntu2) "
[15:41] <ahasenack> and it will block on openssl too
[15:43] <gpiccoli> tnx a lot sil2100 and rbasak =)
[15:43] <gpiccoli> sil2100, guess we should drop the current proposed for disco too
[15:43] <gpiccoli> I didnt worked a debdiff for disco since the eol is in 3 days
[17:40] <ahasenack> rafaeldtinoco: just so we don't overstep on each other, are you going to do those remaining net-snmp related fixes/uploads, or should I?
[17:40] <ahasenack> I don't mind either way
[17:41] <rafaeldtinoco> it's really low in my queue's priority ordering
[17:42] <rafaeldtinoco> for now I'll consider you are doing it until you tell me to take it back
[17:42] <rafaeldtinoco> sounds good ?
[17:42] <rafaeldtinoco> (and tku if it does)
[17:48] <ahasenack> rafaeldtinoco: cool
[18:06] <vorlon> cjwatson, ahasenack: note that the galera-arbitrator-3 binary package I deleted was not built from the galera-3 source, but by a different source package which in turn had been removed from Debian unstable.  I was processing https://people.canonical.com/~ubuntu-archive/testing/focal_outdate_all.txt for $reasons and noticed this.  A no-change rebuild of galera-3 would bring it back, or I guess we
[18:06] <vorlon> could do a binary copy of the current version.  This would be older than the 26.4.3-1 I deleted but that was only ever in focal
[18:07] <vorlon> ahasenack: that krb5 autopkgtest failure looks similar to the ones that have been plaguing us on the gnome stack lately, and I don't know what's regressed and haven't been able to reproduce it locally
[18:07] <vorlon> ahasenack: installing build-essential:amd64 is expected to work, and /does/ work, but something's gone wrong somewhere that I've not been able to see
[18:08] <ahasenack> vorlon: I do see that build-essential failure locally on a container
[18:08] <ahasenack> vorlon: i can do a galera-3 no-change rebuild
[18:08] <vorlon> oh?
[18:08] <vorlon> ahasenack: let me try to just resuscitate it first with a binary copy
[18:09] <ahasenack> vorlon: https://pastebin.ubuntu.com/p/B4mfTxGGcT/
[18:09] <ahasenack> valorie: ack on galera-3
[18:09] <vorlon> ahasenack: ok so what does it think these conflict with?
[18:09] <vorlon> ah
[18:09] <ahasenack> vorlon: libc6-dev with linux-libc-dev, and linux-libc-dev tried to remove many *-dev:i386 packages
[18:10] <vorlon> linux-libc-dev is missing in focal-proposed
[18:10] <vorlon> so look for a linux build failure
[18:10] <vorlon> tests with --all-proposed are going to fail until that's resolved
[18:10] <ahasenack> https://pastebin.ubuntu.com/p/dR9c4q8CZG/
[18:10] <ahasenack> yeah, linux is red
[18:17] <ahasenack> vorlon: the "fix" for  s390-tools/s390x unsatisfiable Depends: s390-tools-signed (= 2.11.0-0ubuntu2) is to just do a rebuild of s390-tools-signed, now that s390-tools 2.11.0-0u2 is in f-proposed?
[18:17] <vorlon> ahasenack: and for base packages that have libraries preinstalled in the autopkgtest VM image, testing /without/ all-proposed doesn't work until we fix autopkgtest to properly set pins for both the native and cross-arch packages; so maybe I'll work on that
[18:17] <vorlon> ahasenack: sounds correct to me
[18:17] <ahasenack> ok
[18:17] <ahasenack> today is my day to chase down packages stuck in migration :)
[18:29] <ahasenack> rafaeldtinoco: I'm baffled, there is no mention of snmp at all in the google-cloud-print-connector source code. I'm trying to track down why/when it was added, but this is old
[18:30] <ahasenack> no binary it produces is dynamically linked with it
[18:30] <rafaeldtinoco> :\
[18:30] <rafaeldtinoco> lmtal
[18:31] <rafaeldtinoco> commit 4edc895
[18:31] <rafaeldtinoco> Merge: 5999b5a 6373ee6
[18:31] <rafaeldtinoco> Author: Vitaly Buka <vitalybuka@gmail.com>
[18:31] <rafaeldtinoco> Date:   Thu Feb 25 01:11:22 2016
[18:31] <rafaeldtinoco>     Merge pull request #192 from jacobmarble/rm-snmp
[18:31] <rafaeldtinoco>     Remove SNMP support.
[18:31] <rafaeldtinoco> ahasenack: ^
[18:31] <rafaeldtinoco> i guess thats because of this
[18:31] <rafaeldtinoco> =)
[18:32] <ahasenack> ohh
[18:32] <ahasenack> good idea, check commit history
[18:32] <rafaeldtinoco> i keep all upstream repos i ever played with
[18:32] <rafaeldtinoco> updating in background
[18:32] <rafaeldtinoco> so things like this are faster
[18:32] <ahasenack> I just cloned, but didn't think of checking *that* history
[18:32] <rafaeldtinoco> it was removed in 2016
[18:32] <rafaeldtinoco> but this pkg wasnt touched since disco
[18:32] <rafaeldtinoco> iirc
[18:32] <ahasenack> thanks a lot, that makes it easier
[18:32] <rafaeldtinoco> sure!
[18:48] <ahasenack> rafaeldtinoco: https://pastebin.ubuntu.com/p/Y5QsK8jVvr/ ? Also submitted to debian at https://salsa.debian.org/go-team/packages/google-cloud-print-connector/merge_requests/1/diffs
[18:48]  * rafaeldtinoco checks
[18:49] <rafaeldtinoco> ahasenack: im +1, in doubt of big uri though
[18:49] <rafaeldtinoco> would it be better commit "xxxx" ?
[18:49] <ahasenack> it's within 80chars
[18:50] <ahasenack> I shortened the hash
[18:50] <rafaeldtinoco> yep, and its just a click away
[18:50] <rafaeldtinoco> im +1
[20:14] <vorlon> ahasenack: I've pushed a fix to the deployed autopkgtest branch that should correct the mis-pinning of cross packages and have retriggered krb5/i386 for openssl; let's see if this does it
[20:14] <ahasenack> vorlon: nice, thanks
[20:15] <vorlon> ahasenack: and galera-3 binaries are re-published now
[20:15] <ahasenack> vorlon: I triggered the galera-3 tests under openssl
[20:15] <vorlon> ok
[20:16] <ahasenack> vorlon: I think http://autopkgtest.ubuntu.com/packages/g/gnutls28/focal/i386 is also the same problem wrt build-essential
[20:35] <vorlon> ahasenack: voilà, krb5/i386 passed
[20:36] <ahasenack> yay!
[20:36] <vorlon> as did libssh
[20:36] <vorlon> waiting to see results on gnutls28
[20:41] <ahasenack> vorlon: so openssl will only remain stuck because of the kernel
[20:50] <vorlon> ahasenack: have you talked to the kernel team about that?  I'm not sure what the failure there is (though it's clearly not caused by openssl)
[20:50] <ahasenack> vorlon: no, xnox told me last week that "the kernel bug" was known and they were working on it
[20:50] <ahasenack> they == kernel team
[20:50] <vorlon> such tellings should come with links to bugs
[20:50] <vorlon> :)
[20:50] <ahasenack> yep, trust but verify :)_
[20:52] <ahasenack> vorlon: "jan 16 09:37:46 <xnox>  i.e. linux => is being fixed by kernel team (python2 fallout)
[20:52] <ahasenack> "
[20:52] <vorlon> so anyway, I'll let openssl et al through if/when the kernel is the only blocker
[20:53] <ahasenack> "jan 16 09:40:58 <xnox>  ahasenack:  i think we will be waiting on linux anyway atm. It is in progress being fixed, as per emails i got this morning."
[20:53] <vorlon> right, that explains the build logs showing failures due to python-dev.  it doesn't explain the errors about linux source failing to unpack
[20:53] <ahasenack> vorlon: ok, thanks
[20:54] <ahasenack> autopkgtest [17:03:40]: ERROR: erroneous package: rules extract failed with exit code 1
[20:54] <ahasenack> weird
[20:54] <ahasenack> disk full?
[20:55] <vorlon> the VMs are single-use so there shouldn't be anything else taking up space, and we test bigger sources than the kernel
[20:56] <ahasenack> what was that package with a gigabyte, some latex/tetex font :)
[21:00] <sarnold> 2.2 gig tarball? :)
[21:00] <sarnold> -rw-r--r-- 1 lp_publish lp_publish 2261434398 Jul 23  2018 unidic-mecab_2.3.0+dfsg.orig.tar.gz
[21:01] <ahasenack> wow
[21:21] <ahasenack> vorlon: galera-3/arm64 is the only remaining red, and that's because the new run hasn't completed yet
[21:21] <ahasenack> apart from linux, that is
[21:21] <ahasenack> (this about openssl, sorry, writing it all backwards)
[22:48] <WoC> oC
[22:54] <WoC> Thais may be known already, but the installation iso (current version), both the 18.04.* and 19.10, the grub installation will fail when installing on a amd64 type computer with legacy BIOS and GPT partitions, even if the bios is able to handle the GPT and the special BIOS partition
[23:56] <vorlon> ahasenack: could postgresql-plperl-12 be changed to Depend: perl:any instead of perl?