=== JanC is now known as Guest56745
=== JanC_ is now known as JanC
[06:06] <cpaelzer> wgrant: I was unable to get the dbus-test-runner hang to occur in a local qemu based riscv build of dee
[06:06] <cpaelzer> wgrant: I have thrown the bit of info that I found into 1891158
[06:07] <cpaelzer> and unblocked (for now) src:dee by skipping the tests on riscv64 - bumping up the timeout didn't help
[06:08] <cpaelzer> so far just FYI in case you want to subscribe to the bug and/or put it on your "sometime I should get to this" List of things that we all have :-)
[07:35] <seb128> vorlon, firebird3.0 unsatisfiable Build-Depends(-Arch) on i386: recode
[07:35] <seb128> do you know what's going on there? recode seems to be build on i386?
=== Wryhder is now known as Lucas_Gray
[08:45] <xnox> mwhudson:  1 day and 9h later hopefully rustc on riscv64 is now publishing https://launchpad.net/ubuntu/groovy/riscv64/rustc
[08:45] <wgrant> xnox: Nicely done
[08:52] <xnox> wgrant:  well launchpad publication history looks very odd, if i'm doing this again for focal, i think i will do "no change rebuild" such that things all arches are built in the same bileto ppa (which happens to have bootstrap compiler for riscv64 available as a build-dep)
[08:52] <xnox> hopefully, it will publish fine.
[08:54] <wgrant> xnox: What's weird about it?
[08:57] <xnox> wgrant:  at https://launchpad.net/ubuntu/+source/rustc/1.43.0+dfsg1+llvm-1~exp1ubuntu2 buildlog is not yet visible, and riscv64 points at the in-archive build, instead of the copy from bileto.
[08:57] <xnox> (and the build in bileto)
[08:57] <xnox> wgrant:  i think i should upload no-change rebuild after this publishes.
[08:58] <wgrant> xnox: Both builds are there
[08:58] <xnox> https://launchpad.net/ubuntu/groovy/riscv64/rustc/1.43.0+dfsg1+llvm-1~exp1ubuntu2 => i can click under Downloadable files on to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4195/+build/19815578
[08:59] <wgrant> Which is a bit weird, but it happens.
[08:59] <xnox> i found a UI way to find it, so i am good.
[09:04] <xnox> seb128:  rbalint: retriggered systemd tests with plymouth isc-dhcp triggers to hopefully have them pass and everything migrate.
[09:09] <seb128> xnox, thanks
=== Wryhder is now known as Lucas_Gray
[10:13] <xnox> mwhudson:  "rustc unsatisfiable Build-Depends-Indep on amd64: wasi-libc (<= 0.0~git20200114.1fad338++)"
[10:14] <mwhudson> xnox: is that in focal?
[10:15] <xnox> mwhudson:  groovy
[10:15] <mwhudson> xnox: oh
[10:15] <mwhudson> it's fairly easy to hack out the wasm stuff
[10:15] <xnox> mwhudson:  i guess we need to keep up bootstrapping rustc up? cause debian is at 46 now, and we are now at 43
[10:16] <mwhudson> xnox: i guess so
[10:16] <xnox> and one can only jump by one?
[10:16] <mwhudson> so apparently jumping by more than one "usually" works
[10:16] <mwhudson> but officially ye
[10:16] <xnox> mwhudson:  i guess i'll throw 44 build into my bileto PPA, to then throw 45 build into it, to finish with 46?
[10:16] <mwhudson> s
[10:16] <xnox> let me check the contol file restrictions
[10:16] <mwhudson> rustc updates are usually fairly simple, it's cargo ones that are a headache
[10:17] <mwhudson> oh but if we're just merging from debian, that's usually fine
[10:17] <xnox> somehow our cargo is ahead of debian
[10:17] <xnox> but behind upstream
[10:17] <xnox> we are at 44 cargo, upstream is at 46 and debian is at 43
[10:17] <mwhudson> how does debian have rustc 1.46 but not the corresponding cargo?
[10:18] <xnox> oh 46 is in experimental
[10:18] <xnox> debian is at 45 rustc in sid
[10:18] <xnox> with cargo at 43 in sid
[10:18] <xnox> dunno
[10:18] <mwhudson> yeah was going to say, is 1.46 even out yet?
[10:18] <mwhudson> i only update rustc when osomon asks me to :)
[10:19] <xnox> hahhahahahha
[10:19] <xnox> well it can't migrate now, so either new rust, or rebuild with "nowasm"
[10:19] <xnox> but i think we want new rust, no?
[10:19] <mwhudson> let me find the wasm disabling thing
[10:20] <mwhudson> yeah rolling forward probably makes sense
[10:21] <mwhudson> but might be nice to make it migratable before we get there, dunno
[10:21] <mwhudson> xnox: https://git.launchpad.net/~canonical-foundations/ubuntu/+source/rustc/commit/?h=focal-1.43&id=1439259a505ca4053c2a81d726e821213f0c34e9
[10:25] <xnox> mwhudson:  why do we even build it if nothing uses it? =)
[10:25] <mwhudson> xnox: /me points at debian
[10:25] <mwhudson> xnox: although i'm not sure quite what you're asking?
[10:27] <xnox> oh
[10:27] <xnox> but rustc is, well urgh.
[10:27] <xnox> your merge is large.
[10:27] <xnox> i don't want to merge it =)
[10:28] <xnox> i'd like rather rollback wasi-lib or cherrypick things for new one.
[10:29] <xnox> i think we should drop building wasi-lib for now, I don't see the point of it.
[10:33] <xnox> mwhudson:  hm, based on https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox we will need rust 45 soon.
[10:41] <mwhudson> xnox: better get cracking then i guess
[10:44] <xnox> so i'll create bileto ppas that build a sync of 44 & 45.
[10:44] <xnox> which we then will be able to use for the build of rustc which is "merged" properly.
[11:22] <rbasak> What version would be suitable for chromium-browser in Groovy then? 1:0?
[11:22] <rbasak> 1:0ubuntu1 maybe?
[11:24] <rbasak> Looks like it's currently a non-native package
[11:31] <seb128> rbalint, sorry I missed the backlog, what's the issue?
[11:34] <seb128> rbalint, it's a native package, just including an ubuntu revision in the version number?
[11:41] <seb128> ups
[11:42] <rbasak> :)
[11:42] <rbasak> I mean https://lists.ubuntu.com/archives/ubuntu-devel/2020-August/041127.html
[11:42] <seb128> rbalint, sorry, that was for rbasak
[11:42] <seb128> I just saw that
[11:42] <seb128> Olivier is out this week, let's wait monday for him to be back?
[11:42] <rbasak> I thought it might be wise to decide now to save round tripping if I'm unsure when Olivier uploads
[11:42] <rbasak> Ah I didn't realise. Sure, thanks.
[11:42] <seb128> maybe accept that round of SRU meanwhile
[11:43] <rbasak> Can do if you think it's important to land it now?
[11:43] <seb128> to avoid having a concrete upgrade issue after the next security round
[11:43] <seb128> well if a security update in bionic become higher than focal than upgraders from bionic to focal aren't going to get the snap
[11:43] <rbasak> OK sure
[11:43]  * rbasak looks
[11:44] <seb128> that's already the case it seems?
[11:44] <seb128> bionic has 84.0.4147.105-0ubuntu0.18.04.1
[11:44] <seb128> and focal proposed 84.0.4147.89-0ubuntu0.20.04.1
[11:45] <rbasak> Yep so I'll accept this one in the Focal queue, right? That'll bring it up to 84.0.4147.105-0ubuntu0.20.04.1
[11:45] <seb128> yes, that fix the immediate problem
[11:46] <seb128> then we can sort out the epoch use when Olivier is back
[11:46] <seb128> rbasak, thanks!
[11:46] <rbasak> Done - though that's only in proposed
[11:47] <seb128> that's a first step
[11:47] <seb128> we can maybe discuss lowering the testing to less than a week, that's only a version bump
[11:47] <rbasak> I agree that should be fine.
[11:48] <rbasak> Probably best for someone to check the binary transitional package is as expected after it's built though
[11:48] <rbasak> Just to try to detect any human error
[11:49] <seb128> right, I will do that
[11:49] <rbasak> Oh and if possible, today would be better than tomorrow to release - because Friday
[11:49] <rbasak> Thanks!
[11:49] <seb128> np, thank you for the review!
[11:59] <rbasak> vorlon: so you want force-reset-test over SRUing a fixed test? This is a case where the broken test is affecting the SRU of a different package.
[12:00] <rbasak> vorlon: documentation in https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions please? I think what's there is out of date then?
[12:01] <rbasak> vorlon: I'd like a table mapping "situation" to "action expected".
[12:01] <rbasak> Where "action expected" might be "fix the autopkgtest in an SRU", "add a hint (specifying the type of hint)" and so on.
[12:01] <rbasak> Right now I'm not clear on what you intend for those things.
[12:05] <ahasenack> good morning
[12:09] <seb128> ddstreet, so yeah, I was wrong yesterday, software-properties isn't migrating, it's blocked now because it makes livecd-rootfs uninstallable on i386, I expect it's due to the new depends on python3-launchpadlib
[12:10] <ddstreet> seb128 i'm not sure why that is though, python3-launchpadlib is 'all' arch
[12:10] <seb128> that's probably not installable on i386 currently?
[12:11] <Laney> correct
[12:12] <ddstreet> why isn't it installable on i386 if it's 'all' arch?
[12:12] <seb128> ddstreet, yeah, unsure, maybe that's not it, I guess you need to set up an i386 env to try...
[12:13] <ddstreet> ack, i'll look into it, it's confusing though
[12:13] <seb128> indeed, I wish it was easier to locally try those i386 problems :/
[12:14] <Laney> arch:all packages can depend on arch-specific ones
[12:14] <ddstreet> Laney right i get that, and in fact software-properties-common does (and python3-softwareproperties depends on it, and livecd-rootfs depends on that...so not sure how any of this 'worked' already)
[12:15] <ddstreet> ah, ok i see python3-software-properties doesn't dep on any of the other pkgs
[12:25] <Laney> ddstreet: It's probably going to turn out to be that some packages need 'bringing back' on i386 to make it installable again, first step would be to investigate in a chroot to find out what they are
[12:26] <ddstreet> at least python3-cryptography and python3-simplejson
[12:28] <ddstreet> unfortunately the 'livepatch' additions to python3-software-properties didn't actually update the pkg deps, as the new addition of softwareproperties.LivepatchService actually imports softwareproperties.gtk without declaring the dep on software-properties-gtk
[12:28] <ddstreet> i dont want to get into pulling the -gtk deps into i386...
[12:30] <ddstreet> rcj if i'm reading livecd-rootfs right, the only thing it needs python3-software-properties for is to print out a ppa signing_key_fingerprint?
[12:30] <ddstreet> if that's all, i can totally redo that for the livecd-rootfs pkg so we can drop the python3-software-properties dep
[12:31] <ddstreet> (or we could stop building livecd-rootfs for i386...)
[12:36] <cjwatson> Stopping building livecd-rootfs for i386 is not very possible, as it's required as part of having LP builds for i386 at all
[12:37] <cjwatson> (At least in the present configuration.  Other configurations are conceptually possible but would be a good deal of work)
[12:38] <cjwatson> I don't think the software-properties bits are needed to make buildd chroots work though
[12:54] <xnox> mwhudson:  rustc ubuntu archive build record kicked in now. I think you will get weird emails about it failing to upload, but we shall see.
[12:55] <xnox> and 44 build in bileto from debian ftbfs on i386, because llvm9 is gone. So yeah, to bootstrap 44 we will need ubuntu style merge of rustc.
[12:55] <xnox> not sure i want to do that.
[14:06] <xnox> horay
[14:06] <xnox> rbasak:  systemd + isc-dhcp are migrating now
[14:07] <rbasak> Was that for me?
[14:30] <Odd_Bloke> xnox: vorlon: I'd appreciate your thoughts on https://github.com/canonical/cloud-init/pull/514/files#r469464608
=== M_hc[m] is now known as _hc
[14:50] <rafaeldtinoco> FTR: on-going open-iscsi merge (https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/open-iscsi/+git/open-iscsi/+merge/389234)
[14:50] <rafaeldtinoco> vorlon: ^ keeping your delta (the ones I did not merge in debian yet), will cleanup iscsi-root support (and merge things in debian as accepted) as a next step
[14:51] <rafaeldtinoco> im also keeping history as split git-ubuntu merges to keep history to server team when 1.1.1-1 from debian gets imported into usd-importer
[14:52] <rbalint> xnox, \o/
[17:49] <slingamn> i submitted a draft review for a change to software-properties, but i seem to have mistakenly pinged the entire "Ubuntu Core Development Team"
[17:49] <slingamn> any suggestions for  an individual reviewer for a software-properties change?
[18:54] <vorlon> ddstreet: I think we're nearly there on python3-launchpadlib; looks like it should only be 3 python packages that need added to the set (python-cryptography, simplejson, python-cffi)
[18:55] <ddstreet> vorlon awesome, and you want to use the alternate MR, to change livecd-rootfs to use python3-launchpadlib directly?
[18:55] <vorlon> ddstreet: I haven't seen the MP, can you link me to it?
[18:55] <ddstreet> https://code.launchpad.net/~ddstreet/livecd-rootfs/+git/livecd-rootfs/+merge/389260
[18:56] <vorlon> thanks, I'll have a look
[18:57] <vorlon> xnox: why did you copy recode from groovy to groovy-proposed?
[18:59] <vorlon> xnox: ... because you were trying to make firebird3.0 build on i386, I guess... should've used --force-same-destination and copied it back to groovy instead
[19:00] <vorlon> seb128: recode restored in groovy release, so firebird3.0 should be migratable shortly
[19:04] <seb128> vorlon, thanks
[19:38] <vorlon> rbasak: from what I see, https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions already documents this, aside from the s/force-badtest/force-reset-test/ optimization?
[19:39] <vorlon> ddstreet: and python-cryptography is built now on i386 so I believe as soon as we get a publishing run + britney run, software-properties should be good to migrate; if not, feel free to yell
[19:41] <realtime-neil> what's a good and proper way for an _unprivileged_ user to change his/her own locale, console keymap, x11-keymap-{layout,model,variant} --- and have that choice persist across login/reboots ?
[19:43] <vorlon> realtime-neil: an unprivileged user doesn't get to change the console keymap, the console is privileged
[19:44] <realtime-neil> vorlon: understood. what about the other items?
[19:45] <vorlon> realtime-neil: if you're using the Ubuntu Desktop and the necessary locale packages are installed, you should be able to configure everything through Settings -> Region and Language
[19:46] <realtime-neil> What if the "Region & Language" is missing from gnome-control-center?
[19:48] <realtime-neil> vorlon: related question: How does one restore the "Region & Language" tab to the gnome-control-center?
[19:49] <vorlon> realtime-neil: I have no idea how you would have managed to do that; and this is not a user support channel, maybe ask in #ubuntu?
[19:49] <realtime-neil> will do
[21:24] <smoser> anyone else seen this: https://paste.ubuntu.com/p/Hdxt9hMgwG/
[21:25] <smoser> INFO: pkgstripfiles: waiting for lock (cloud-initramfs-rooturl) ...
[21:25] <smoser> keeps repeating
[21:44] <seb128> software-properties did migrate, thanks vorlon!