[00:03] <infinity> bluesabre: Why are pepole adding zsys for zfs installer support?
[00:04] <infinity> (note that it's not there for Ubuntu desktop, cause it's in universe)
[00:04] <infinity> Oh, Didied filed an MIR a month ago.  Whee.
[00:05] <bluesabre> infinity: Suggestion by Wimpress for better support in 20.04, I believe.
[00:05] <infinity> To be clear, I intent to have a long talk with the desktop team in the morning about their implementation here.
[00:05] <infinity> No other filesystem/storagelayer requires tools be in the desktop seeds.
[00:05] <infinity> This is not how we do this. :P
[00:06] <bluesabre> :)
[00:06] <infinity> But yes, we'll pick up your meta changes if I lose that argument or give up yelling.
[00:06] <bluesabre> I’m just following the pack, happy to make adjustments as you see fit.
[00:08] <infinity> bdmurray: Removing the click hook feels more like an upstream change, not something to do in an Ubuntu revision, surely?
[00:08] <infinity> (I realise we're also upstream, but it's not packaged natively)
[00:09] <infinity> Oh, gross.  It *is* packaged natively, but not *versioned* natively.
[00:09] <infinity> Ick, ick.
[00:32] <rharper> hi, cloud-init has an upload to eoan to fix  a bug that can prevent cloud-init from running in lxd/kvm cloud images,  https://bugs.launchpad.net/cloud-init/+bug/1846511 ; would be good to get this in so eoan cloud-images don't have a busted config in the image
[00:41] <infinity> rharper: Icky.  And accepted.
[00:41] <rharper> infinity: indeed; thanks!
[00:41] <infinity> rharper: I assume that same bug will need all the SRUs too?
[00:41] <rharper> no, it only affected eoan
[00:42] <infinity> Oh, lucky.
[00:42] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (eoan-proposed) [19.2-36-g059d049c-0ubuntu3]
[00:42] <rharper> very
[00:42] <rharper> not looking for another critical sru for cloud-init any time soon
[00:42] <rharper> this was too close for comfort
[00:42] <infinity> I did appreciate the accidental recursion, though.
[00:42] <rharper> hehe
[00:43] <infinity> https://accidentallyquadratic.tumblr.com/
[00:43] <infinity> Doesn't quite belong, but certainly in the spirit of it.
[00:43] <rharper> lol
[00:54] -queuebot:#ubuntu-release- Unapproved: accepted apport [source] (eoan-proposed) [2.20.11-0ubuntu8]
[01:58] -queuebot:#ubuntu-release- Unapproved: partman-auto (eoan-proposed/main) [134ubuntu10 => 134ubuntu11] (core, i386-excludes)
[02:07] -queuebot:#ubuntu-release- Unapproved: ubiquity (eoan-proposed/main) [19.10.17 => 19.10.18] (core)
[02:08] <xnox> updated description of https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1845571 most of the code for "installer media detection" fails on el-torito hybrid images and partman/parted is very confused about it, thus the strict /cdrom grep is the only thing that is preventing to autopartition the cdrom media one is booted from. And the grep needs expanding, now that we properly mount an el-torito
[02:08] <xnox> partition of the cdrom.
[02:09] <xnox> Laney:  infinity: ^
[02:10] <xnox> maybe vorlon too
[02:10]  * xnox sleeps
[02:11] <xnox> happy RC day
[02:24] <tsimonq2> infinity: Oh yeah, so there's another Calamares.
[02:25] <tsimonq2> infinity: Someone forgot to mention that we have an Apport hook that has that path hardcoded. Bleh.
[02:25] <tsimonq2> infinity: Anyway, kc2bez handled it, so that Should be the last Cala for this cycle.
[02:27] <tsimonq2> infinity: Ah, well, the bot that's in here must have derped, because it seems it was accepted. :P
[03:50] <tjaalton> pretty please, intel-* from the queue finish my plate on migration to llvm9 (intel-comput-runtime needed a new version, which needed new -gmmlib, which forced rebuilds of intel-media-*)
[05:12] -queuebot:#ubuntu-release- New: accepted backport-iwlwifi-dkms [source] (eoan-proposed) [7906-0ubuntu1]
[05:14] -queuebot:#ubuntu-release- New binary: backport-iwlwifi-dkms [amd64] (eoan-proposed/universe) [7906-0ubuntu1] (no packageset)
[05:15] <vorlon> tjaalton: it seems libigdgmm9 is seeded on pretty much all of the desktop flavors except for Ubuntu itself, so that's a risky transition to be handling at this point in the cycle; what's the impact if we don't migrate to llvm9 until FF opens?
[05:15] <vorlon> infinity: ^^ and I'll defer to you on actually deciding what to do about these intel packages
[05:17] -queuebot:#ubuntu-release- New: accepted backport-iwlwifi-dkms [amd64] (eoan-proposed) [7906-0ubuntu1]
[06:01] <tjaalton> vorlon: really? the only rdepends for it are intel-media-va-driver* and intel-opencl-icd.. so the other images have the va-driver included?
[06:02] -queuebot:#ubuntu-release- Unapproved: dmraid (eoan-proposed/main) [1.0.0.rc16-8ubuntu1 => 1.0.0.rc16-8ubuntu2] (core)
[06:05] -queuebot:#ubuntu-release- Unapproved: mesa (eoan-proposed/main) [19.2.0-1ubuntu2 => 19.2.1-1ubuntu1] (core, xorg)
[06:05] <tjaalton> mesa ^ is a bugfix release
[06:10] <tjaalton> as for the impact on intel-compute-runtime still on llvm8 while spirv-llvm-translator and opencl-clang moved on to llvm9, I'm not sure
[06:11] -queuebot:#ubuntu-release- Unapproved: accepted partman-auto [source] (eoan-proposed) [134ubuntu11]
[06:11] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (eoan-proposed) [19.10.18]
[06:13] <tjaalton> libigc1 et al pulls in llvm9
[06:13] <tjaalton> libllvm9
[06:14] <tjaalton> I don't see compute-runtime (intel-opencl-icd) to use it directly, so could be fine as is
[06:15] <infinity> tjaalton: I've decided to let it in anyway, please give it some abuse from whatever angles you can think of, though.
[06:15] <infinity> tjaalton: It seems to be on flavour media due to weird twisty dependencies of things like libavcodec. :P
[06:15] -queuebot:#ubuntu-release- Unapproved: accepted intel-compute-runtime [source] (eoan-proposed) [19.39.14278-0ubuntu1]
[06:15] -queuebot:#ubuntu-release- Unapproved: accepted intel-media-driver-non-free [source] (eoan-proposed) [19.2.1+ds1-2ubuntu1]
[06:15] -queuebot:#ubuntu-release- Unapproved: accepted intel-gmmlib [source] (eoan-proposed) [19.3.2+ds1-0ubuntu1]
[06:15] -queuebot:#ubuntu-release- Unapproved: accepted intel-media-driver [source] (eoan-proposed) [19.2.1+dfsg1-2ubuntu1]
[06:16] <tjaalton> ah, via libva2
[06:16] <tjaalton> and va-driver-all
[06:16]  * infinity nods.
[06:17] -queuebot:#ubuntu-release- Unapproved: accepted dmraid [source] (eoan-proposed) [1.0.0.rc16-8ubuntu2]
[06:17] -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (eoan-proposed) [19.2.1-1ubuntu1]
[06:18] -queuebot:#ubuntu-release- New binary: intel-gmmlib [amd64] (eoan-proposed/universe) [19.3.2+ds1-0ubuntu1] (kubuntu)
[06:18] <tjaalton> thanks, I'll figure out a better test-case for opencl than darktable :)
[06:19] -queuebot:#ubuntu-release- Unapproved: firefox (eoan-proposed/main) [69.0.2+build1-0ubuntu2 => 69.0.3+build1-0ubuntu1] (mozilla, ubuntu-desktop)
[06:25] <infinity> tjaalton: intel-gmmlib FTBFS on i386.
[06:25] <infinity> tjaalton: And this one might be in the class of things we actually want working.
[06:26] <tjaalton> bah
[06:26] <tjaalton> I'll check
[06:26] <infinity> [ RUN      ] CTestAuxTable.TestAuxTableContent
[06:26] <infinity> /<<BUILDDIR>>/intel-gmmlib-19.3.2+ds1/Source/GmmLib/ULT/GmmAuxTableULT.cpp:244: Failure
[06:26] <infinity> Value of: val
[06:26] <infinity>   Actual:<PHONE_NUMBER>12864
[06:26] <infinity> Expected: expected
[06:26] <infinity> Which is:<PHONE_NUMBER>3560653824
[06:26] <infinity> [  FAILED  ] CTestAuxTable.TestAuxTableContent (0 ms)
[06:26] <infinity> Truncation of 64-bit type to 32-bit?
[06:27] <infinity> Except<PHONE_NUMBER>12864 is a lot bigger than 32-bits, so no.
[06:30] <tjaalton> this one got added in 19.3.2, nice
[06:34] <infinity> tjaalton: Testing new code, or just new test exposing a bug that was already there?
[06:34] <infinity> (or potentially new test that is, itself, buggy_
[06:34] <infinity> )
[06:35] <tjaalton> new test
[06:35] <tjaalton> and code
[06:35] <tjaalton> a09c68fd3244eee Add Pagetable manager  and auxtable  support.
[06:38] <tjaalton> could just skip tests on i386 for now
[06:38] <tjaalton> filed it upstream
[06:38] <tjaalton> though they're kinda actively dropping support for 32bit
[06:39] <tjaalton> the opencl runtime is amd64 only, for instance
[06:39] <infinity> I don't mind dropping i386 if you can make sure the revdeps all get handled sanely.
[06:39] <infinity> And by tomorrow. :P
[06:40] <tjaalton> yeah I'm looking at it
[06:40] <tjaalton> actually, I don't think the tests were run previously, since they need certain cpu features from the builder
[06:40] <tjaalton> and the check was buggy in the past
[06:41] <tjaalton> hmm no, this test is new and is just buggy
[06:41] <infinity> I'd certainly prefer "fix buggy test/code", if the bug's jumping out at you.
[06:43] <infinity> I'm going to go see if I can catch some sleep so I can catch EU before their EOD in the morning.
[06:43] <infinity> tjaalton: If you find a fix, pass it by someone you trust for review, but feel free to self-accept a fixed upload after triple-checking the debdiff isn't bonkers.
[06:43] <tjaalton> I'll poke them to provide a fix or I'll just skip tests for now. amd64 is proben to pass them now :)
[06:43] <tjaalton> *proven
[06:44] <tjaalton> got it
[06:44] <infinity> tjaalton: Ditto for binary NEW.  It looks fine to me, but not accepting because of the arch skew.
[06:45]  * infinity wanders off.
[08:00] -queuebot:#ubuntu-release- Unapproved: python3.8 (eoan-proposed/universe) [3.8.0~rc1-1 => 3.8.0~rc1-3] (no packageset) (sync)
[08:10] <apw> tjaalton, i am about if you have something to review
[08:17] <tjaalton> apw: not yet
[08:18] <tjaalton> but yes, i'll ping you once I do
[08:43] -queuebot:#ubuntu-release- Unapproved: accepted python3.8 [sync] (eoan-proposed) [3.8.0~rc1-3]
[09:11] -queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (eoan-proposed/main) [1:19.10.13 => 1:19.10.14] (core)
[09:22] <doko> xnox, ginggs: I see you had some successful give backs for http://autopkgtest.ubuntu.com/packages/p/python-sparse/eoan/i386. any idea?
[09:30] -queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (xenial-proposed) [2.27.1-6ubuntu3.9]
[09:33] -queuebot:#ubuntu-release- Unapproved: apt (trusty-proposed/main) [1.0.1ubuntu2.23 => 1.0.1ubuntu2.24] (core)
[09:35] <sil2100> apw: hello o/ Would you have a moment to take a look at ubuntu-release-upgrader? The diff is quite big, but it's due to demotion/translation changes, the actual diff is 3 lines
[09:35] <sil2100> (in eoan of course)
[09:37] <apw> sil2100, sure
[09:39] -queuebot:#ubuntu-release- Unapproved: gnome-nibbles (eoan-proposed/universe) [1:3.34.0-1 => 1:3.34.1-1] (desktop-extra) (sync)
[09:40] -queuebot:#ubuntu-release- Unapproved: quadrapassel (eoan-proposed/universe) [1:3.34.0-1 => 1:3.34.1-1] (desktop-extra) (sync)
[09:41] <ginggs> doko: six seems to be a common trigger in those that passed.  i've just triggered itself to try to see if it has regressed in release
[09:42] <ginggs> maybe six needs another rebuild?  see https://launchpad.net/ubuntu/+source/six/1.12.0-1build1
[09:43] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (eoan-proposed) [1:19.10.14]
[09:43] <sil2100> apw: thanks!
[09:44] -queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu10 => 2.04-1ubuntu11] (core)
[09:45] -queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-ubuntu-dock (eoan-proposed/main) [66ubuntu19.10.2 => 67ubuntu19.10.1] (ubuntu-desktop) (sync)
[09:46] -queuebot:#ubuntu-release- Unapproved: gcc-9 (eoan-proposed/main) [9.2.1-9ubuntu1 => 9.2.1-9ubuntu2] (core)
[09:46] -queuebot:#ubuntu-release- Unapproved: grub2-signed (eoan-proposed/main) [1.126 => 1.127] (core)
[09:46] -queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-desktop-icons (eoan-proposed/main) [19.01.4-1 => 19.10.2-1] (ubuntu-desktop)
[09:47] <doko> ginggs: do you know why that rebuild was necessary? LocutusOfBorg?
[09:48] <ginggs> doko: no idea, I just happened to see it in the changelog
[09:53] <LocutusOfBorg> doko, actually it wasn't, at least to the test log... http://autopkgtest.ubuntu.com/packages/p/python-sparse/eoan/i386
[09:54] -queuebot:#ubuntu-release- Unapproved: iproute2 (eoan-proposed/main) [5.2.0-1ubuntu1 => 5.2.0-1ubuntu2] (core)
[09:54] <LocutusOfBorg> the fix has been in 1.12.0-2 with "Mark autopkgtests as superficial."
[09:54] -queuebot:#ubuntu-release- Unapproved: gnome-maps (eoan-proposed/universe) [3.34.0-1 => 3.34.1-1] (desktop-extra, ubuntu-budgie, ubuntugnome) (sync)
[09:56] <didrocks> Laney: here is the grub2 update fixing the signed kernel filtering we discussed ^ (grub2, grub2-signed and ofc grubzfs-testsuite which was updated for autopkgtests to pass)
[09:56] -queuebot:#ubuntu-release- Unapproved: grubzfs-testsuite (eoan-proposed/universe) [0.4.3 => 0.4.4] (no packageset)
[09:56] <apw> didrocks, did that 'optimisation' patch that was causing non-initialisation of the display get sorted in grub2
[09:57] <apw> (i was expecting it to get dropped i think)
[09:57] <didrocks> apw: hum, I'm unsure about which patch you are talking about, I'm a little bit out of context, was that something we discussed?
[09:57] <apw> didrocks, hmmm, maybe, or maybe it was cyphermox ...
[09:58] <didrocks> apw: that's the second time you are doing that to me on grub2-related things! :) we speak the same language, but with a different accent :p
[09:58] <seb128> apw, is that one that has to do with flickerfree boot? do you have a lp reference?
[09:58] <didrocks> (but more seriously, I think it was with him, because nor a patch not this discussion rings a bell to me)
[09:59] <apw> seb128, right something to do with reducing flicker
[09:59] <seb128> apw, reverting would add the flicker back ... is there a proper report explaining the issue?
[09:59] <Laney> juliank: seems a bit late for that packagekit change ...
[10:00] <juliank> Laney: packagekit?
[10:00] <Laney> HEH
[10:00] <Laney> forget it, I'm looking at disco
[10:00] <juliank> oh that one
[10:01] <apw> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1827203
[10:01] <Laney> scared about it there too, but not my call thankfully :>
[10:01] <seb128> apw, thx
[10:02] <ginggs> doko, LocutusOfBorg: the passing test on 2019-07-30 12:35:34 UTC was with a rebuilt six, and so was 2019-09-02 08:43:44 UTC (0.2.0-2 was obviously built after 0.2.0-1)
[10:02] <juliank> Laney: the change + aptdaemon followup to make that use it is planned to go back all the way to xenial; but need to come up with a better test case I guess
[10:02] <apw> seb128, ok that patch is still in there ... for me i was able to downgrade to the version before that was added and got normal updates
[10:03] <juliank> the current test case stats to check the socket is used and stuff still works correctly
[10:03] <seb128> apw, you pinned your grub? or got it updated again to newer version and didn't see the issue again?
[10:03] <juliank> but it does not actually state to like use a frontend and then close it while stuff is being installed
[10:05] <apw> seb128, i repeatedly pushed it back to an older version which i have in my home
[10:05] <apw> so manually pinned
[10:05] <apw> seb128, let me upgrade now and con
[10:05] <apw> confirm it is still sad
[10:05] <seb128> k, we should investigate the issue then
[10:05] <seb128> but it sounds a bit late to revert, especially that nobody else noticed/complained and cyphermox asked for debug details
[10:06] <seb128> for what we know it could be an hardware issue specific to your machine
[10:06] <apw> seb128, we talked about it at the time, and i had gotten the impression it was a somewhat dodgy change not yet accepted upstream; and it iwas going
[10:06] <apw> seb128, i am sure it is h/w specific in some sense, though this is a common Dell
[10:07] <apw> seb128, the bigger issue to my mind is mostly don't notice it if you don't have the menu turned on and your machine isn't broken
[10:08] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (eoan-proposed) [1.127]
[10:08] -queuebot:#ubuntu-release- Unapproved: accepted grubzfs-testsuite [source] (eoan-proposed) [0.4.4]
[10:08] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (eoan-proposed) [2.04-1ubuntu11]
[10:08] <didrocks> thx!
[10:09] <ginggs> python-sparse/i386 passed in release https://autopkgtest.ubuntu.com/packages/python-sparse/eoan/i386
[10:09] <seb128> apw, right, we should fix it. Reverting would be a bit sad since it would mean that we loose flickerfree boot
[10:10] <apw> seb128, a bit less flicker boot, as we are still doing a panel reset to change the tiling
[10:10] <apw> i guess an option to say, i am poo please don't use it would be fine
[10:11] <seb128> well, that patch is supposed to avoid the mode change in the case the menu isn't displayed
[10:11] <seb128> so it sounds like it's buggy
[10:13] <seb128> also what panel reset is that that? I'm not expert on that stack but my understanding from the upstream work is that it was supposed to be fully flicker free on recent intel cards where i915.fastboot is default now
[10:13] <apw> seb128, isn't the efi framebuffer defined as non-tiled and we want to be tiled by the time we get to X
[10:14] <apw> seb128, but also, i am not keeping up, so take everything i say with a grain of salt
[10:14] <apw> seb128, anyhow will update, reboot, and report back
[10:14] -queuebot:#ubuntu-release- Unapproved: binutils-mingw-w64 (eoan-proposed/universe) [8.3ubuntu2 => 8.3ubuntu3] (no packageset)
[10:14] <seb128> could be, as said I'm not familiar with those details
[10:14] <seb128> apw, thx!
[10:19] -queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu11 => 2.04-1ubuntu11] (core)
[10:32] -queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop [source] (eoan-proposed) [10.5-0ubuntu7]
[10:32] -queuebot:#ubuntu-release- Unapproved: accepted cups-filters [source] (eoan-proposed) [1.25.8-0ubuntu1]
[10:32] -queuebot:#ubuntu-release- Unapproved: accepted firefox [source] (eoan-proposed) [69.0.3+build1-0ubuntu1]
[10:32] -queuebot:#ubuntu-release- Unapproved: accepted quadrapassel [sync] (eoan-proposed) [1:3.34.1-1]
[10:32] -queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-meta [source] (eoan-proposed) [0.197]
[10:32] -queuebot:#ubuntu-release- Unapproved: accepted cups-filters [source] (eoan-proposed) [1.25.10-0ubuntu1]
[10:32] -queuebot:#ubuntu-release- Unapproved: accepted gnome-nibbles [sync] (eoan-proposed) [1:3.34.1-1]
[10:32] -queuebot:#ubuntu-release- Unapproved: accepted xubuntu-meta [source] (eoan-proposed) [2.230]
[10:32] -queuebot:#ubuntu-release- Unapproved: accepted cups-filters [source] (eoan-proposed) [1.25.9-0ubuntu1]
[10:32] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-budgie-meta [source] (eoan-proposed) [0.54]
[10:32] -queuebot:#ubuntu-release- Unapproved: intel-gmmlib (eoan-proposed/universe) [19.3.2+ds1-0ubuntu1 => 19.3.2+ds1-0ubuntu2] (kubuntu)
[10:32] <tjaalton> apw: ^ gmmlib skips all tests now
[10:34] <apw> tjaalton, we couldn't just skip them on i386 ?
[10:36] -queuebot:#ubuntu-release- Unapproved: python2.7 (eoan-proposed/universe) [2.7.16-4 => 2.7.17~rc1-1] (kubuntu)
[10:37] <tjaalton> apw: the tests passed fine on amd64, and this is likely the last upload for eoan, so.. :)
[10:39] <tjaalton> let me test (ha) something
[10:40] -queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu11 => 2.04-1ubuntu11] (core)
[10:46] -queuebot:#ubuntu-release- Unapproved: six (eoan-proposed/main) [1.12.0-2 => 1.12.0-2build1] (core)
[10:49] -queuebot:#ubuntu-release- Unapproved: accepted python2.7 [source] (eoan-proposed) [2.7.17~rc1-1]
[10:49] -queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-dashtodock (eoan-proposed/universe) [66-1 => 67-1] (no packageset) (sync)
[10:49] -queuebot:#ubuntu-release- Unapproved: accepted six [source] (eoan-proposed) [1.12.0-2build1]
[10:49] -queuebot:#ubuntu-release- Unapproved: accepted binutils-mingw-w64 [source] (eoan-proposed) [8.3ubuntu3]
[10:50] <doko> ginggs: ^^^ ok, one more no-change upload, the autopkg testers are idle, so it doesn't hurt
[10:51] <tjaalton> apw: ok, I have another version to upload
[10:51] <apw> tjaalton, go for it
[10:52] <apw> seb128, ok confirmed it is the same with the latest version, i am pretty sure i do not have fastboot=1
[10:52] <apw> (i see a bios 'hit return' thing which is what suppresses that right?)
[10:52] -queuebot:#ubuntu-release- Unapproved: intel-gmmlib (eoan-proposed/universe) [19.3.2+ds1-0ubuntu1 => 19.3.2+ds1-0ubuntu2] (kubuntu)
[10:53] -queuebot:#ubuntu-release- Unapproved: gcc-mingw-w64 (eoan-proposed/universe) [22~exp1ubuntu1 => 22~exp1ubuntu2] (no packageset)
[10:54] -queuebot:#ubuntu-release- Unapproved: rejected intel-gmmlib [source] (eoan-proposed) [19.3.2+ds1-0ubuntu2]
[10:54] -queuebot:#ubuntu-release- Unapproved: cups-filters (eoan-proposed/main) [1.25.10-0ubuntu1 => 1.25.11-0ubuntu1] (desktop-core, ubuntu-server)
[10:55] -queuebot:#ubuntu-release- Unapproved: accepted intel-gmmlib [source] (eoan-proposed) [19.3.2+ds1-0ubuntu2]
[10:55] <apw> tjaalton, ^
[10:56] <tjaalton> apw: thanks!
[10:56] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (eoan-proposed) [2.04-1ubuntu11]
[10:56] -queuebot:#ubuntu-release- Unapproved: flash-kernel (eoan-proposed/main) [3.98ubuntu3 => 3.98ubuntu4] (core)
[10:56] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (eoan-proposed) [2.04-1ubuntu11]
[10:57] -queuebot:#ubuntu-release- Unapproved: rejected flash-kernel [source] (eoan-proposed) [3.98ubuntu4]
[10:57] <apw> doko, i assume this was not irony: "No-change rebuild. For what reason?"
[10:57] -queuebot:#ubuntu-release- Unapproved: flash-kernel (eoan-proposed/main) [3.98ubuntu3 => 3.98ubuntu4] (core)
[10:58] -queuebot:#ubuntu-release- New binary: intel-gmmlib [amd64] (eoan-proposed/universe) [19.3.2+ds1-0ubuntu2] (kubuntu)
[11:00] -queuebot:#ubuntu-release- New binary: intel-gmmlib [i386] (eoan-proposed/universe) [19.3.2+ds1-0ubuntu2] (kubuntu)
[11:01] <LocutusOfBorg> apw, no irony, it worked in the past but we don't know why
[11:01] <LocutusOfBorg> so, if the test automagically works, we can debug it further
[11:01] <LocutusOfBorg> and I plan to do it
[11:03] -queuebot:#ubuntu-release- New: rejected intel-gmmlib [amd64] (eoan-proposed) [19.3.2+ds1-0ubuntu1]
[11:04] -queuebot:#ubuntu-release- New: accepted intel-gmmlib [amd64] (eoan-proposed) [19.3.2+ds1-0ubuntu2]
[11:04] -queuebot:#ubuntu-release- New: accepted intel-gmmlib [i386] (eoan-proposed) [19.3.2+ds1-0ubuntu2]
[11:05] -queuebot:#ubuntu-release- Unapproved: swift (eoan-proposed/main) [2.22.0-0ubuntu1 => 2.22.0-0ubuntu2] (openstack)
[11:06] <doko> apw: no. see above: " ^^^ ok, one more no-change upload, the autopkg testers are idle, so it doesn't hurt"
[11:16] -queuebot:#ubuntu-release- Unapproved: python-stdlib-extensions (eoan-proposed/universe) [2.7.16-2 => 2.7.17~rc1-1] (kubuntu)
[11:32] -queuebot:#ubuntu-release- Unapproved: accepted cups-filters [source] (eoan-proposed) [1.25.11-0ubuntu1]
[11:32] -queuebot:#ubuntu-release- Unapproved: accepted gcc-9 [source] (eoan-proposed) [9.2.1-9ubuntu2]
[11:32] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-dashtodock [sync] (eoan-proposed) [67-1]
[11:32] -queuebot:#ubuntu-release- Unapproved: accepted python-stdlib-extensions [source] (eoan-proposed) [2.7.17~rc1-1]
[11:32] -queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [source] (eoan-proposed) [3.98ubuntu4]
[11:32] -queuebot:#ubuntu-release- Unapproved: accepted iproute2 [source] (eoan-proposed) [5.2.0-1ubuntu2]
[11:32] -queuebot:#ubuntu-release- Unapproved: accepted gnome-maps [sync] (eoan-proposed) [3.34.1-1]
[11:32] -queuebot:#ubuntu-release- Unapproved: accepted swift [source] (eoan-proposed) [2.22.0-0ubuntu2]
[11:51] -queuebot:#ubuntu-release- Unapproved: accepted gcc-mingw-w64 [source] (eoan-proposed) [22~exp1ubuntu2]
[11:56] <doko> rbasak: https://tracker.debian.org/pkg/python-trio  not in Debian, wondering why we need to ship that in Ubuntu?
[11:59] -queuebot:#ubuntu-release- Unapproved: python-msrest (eoan-proposed/universe) [0.6.1-1 => 0.6.1-1ubuntu1] (no packageset)
[12:00] -queuebot:#ubuntu-release- Unapproved: rejected python-msrest [source] (eoan-proposed) [0.6.1-1ubuntu1]
[12:03] <rbasak> doko: what would you prefer to do for Ubuntu? It's fine for a non-LTS I think.
[12:06] -queuebot:#ubuntu-release- Unapproved: linux-aws (eoan-proposed/main) [5.3.0-1002.2 => 5.3.0-1003.3] (core, kernel) (sync)
[12:06] -queuebot:#ubuntu-release- Unapproved: linux-meta-aws (eoan-proposed/main) [<IP_ADDRESS>2.2 => <IP_ADDRESS>3.3] (core, kernel) (sync)
[12:06] -queuebot:#ubuntu-release- Unapproved: linux-meta (eoan-proposed/main) [<IP_ADDRESS>.19 => <IP_ADDRESS>.20] (core, kernel) (sync)
[12:06] -queuebot:#ubuntu-release- Unapproved: linux (eoan-proposed/main) [5.3.0-17.18 => 5.3.0-18.19] (core, kernel) (sync)
[12:06] -queuebot:#ubuntu-release- Unapproved: linux-gcp (eoan-proposed/main) [5.3.0-1003.3 => 5.3.0-1004.4] (core, kernel) (sync)
[12:06] -queuebot:#ubuntu-release- Unapproved: linux-restricted-modules (eoan-proposed/restricted) [5.3.0-17.18 => 5.3.0-18.19] (core, kernel) (sync)
[12:06] -queuebot:#ubuntu-release- Unapproved: linux-meta-gcp (eoan-proposed/main) [<IP_ADDRESS>3.3 => <IP_ADDRESS>4.4] (core, kernel) (sync)
[12:06] -queuebot:#ubuntu-release- Unapproved: python-msrest (eoan-proposed/universe) [0.6.1-1 => 0.6.1-1ubuntu1] (no packageset)
[12:06] <doko> rbasak: I'm currently looking at the python-msrestazure autopkg test failures, and python-trio is in the way, that's why I'm asking
[12:06] -queuebot:#ubuntu-release- New sync: linux-restricted-modules-aws (eoan-proposed/primary) [5.3.0-1003.3]
[12:06] -queuebot:#ubuntu-release- New sync: linux-restricted-modules-gcp (eoan-proposed/primary) [5.3.0-1004.4]
[12:06] -queuebot:#ubuntu-release- Unapproved: linux-kvm (eoan-proposed/main) [5.3.0-1002.2 => 5.3.0-1003.3] (core, kernel) (sync)
[12:06] -queuebot:#ubuntu-release- Unapproved: linux-signed-gcp (eoan-proposed/main) [5.3.0-1003.3 => 5.3.0-1004.4] (core, kernel) (sync)
[12:06] -queuebot:#ubuntu-release- Unapproved: linux-meta-kvm (eoan-proposed/main) [<IP_ADDRESS>2.2 => <IP_ADDRESS>3.3] (core, kernel) (sync)
[12:06] -queuebot:#ubuntu-release- Unapproved: linux-signed (eoan-proposed/main) [5.3.0-17.18 => 5.3.0-18.19+1] (core, kernel) (sync)
[12:07] -queuebot:#ubuntu-release- Unapproved: accepted python-msrest [source] (eoan-proposed) [0.6.1-1ubuntu1]
[12:08] <Laney> wtf
[12:08] <rbasak> doko: looking
[12:09] <Laney> doko: can you please stop accepting your own stuff :(
[12:09] <Laney> I was going to reject that, you typoed override
[12:09] <doko> ouch, ok
[12:10] <Laney> also you didn't make it respect nocheck in DEB_BUILD_OPTIONS which you should really do when overriding dh_auto_test
[12:10] <Laney> bonus also: that might have been accepted by auto-accept but someone has made a syntax error so that bot isn't functioning atm
[12:10] <Laney> /o\
[12:11] <doko> Laney: so, no, then please just override the python-msrestazure autopkg test. fails in the release too
[12:11] <Laney> no you won't fix it?
[12:11] <rbasak> doko: I'm not sure I understand yet. Do you mean the python-msrestazure autopkgtest failures in Ubuntu? How is it being blocked by python-trio?
[12:13] <doko> Laney: no, it's a regression in release? and apparently not in debian
[12:13] <doko> rbasak: I don't care to look. it's blocked in debian because -trio is blocked apparenty?
[12:13] <Laney> this seems like a strange response to me pointing out a typo in your upload
[12:13] <doko> Laney: I'll remove it in -proposed
[12:13] <rbasak> doko: https://tracker.debian.org/pkg/python%2Dmsrestazure says it's in testing? I don't see anything blocked.
[12:14] <apw> Laney, that explains why the autobot has been so quiet
[12:15] <doko> rbasak: no, migration is stalled: https://tracker.debian.org/pkg/python-msrest
[12:15] <rbasak> Ah that's a different source package
[12:15]  * rbasak looks again
[12:16] <Laney> I've just fixed the auto-accept bot, so any future upload will probably just sail in
[12:16] <doko> rbasak: and python-msrestazure 0.6 apparently needs the new msrest
[12:16] <xnox> doko:  although ~ubuntu-archive have powers to accept, process wise ~ubuntu-release should be processing the queue right now.
[12:16] <xnox> doko:  and you are not ~ubuntu-release
[12:17] <xnox> Laney:  yeah, i have noticed some things that was expected to auto-accept and weren't. But i thought maybe it needs manual review.
[12:17] <Laney> xnox: apw: SyntaxError: invalid syntax
[12:17] <Laney>   File "/home/ubuntu-archive/auto-accept", line 12
[12:17] <Laney>     PACKAGESET_WHITELIST = {"ubuntugnome", "edubuntu", "i386-eoan-excludes", "i386-excludes"]
[12:17] <Laney> /o\\\\\\\\\\\\\\\
[12:17] <doko> xnox, I didn't accept my toolchain uploads
[12:17] <xnox> doko:  ok. thanks.
[12:18] <rbasak> doko: OK I think I understand what you're pointing out and why you pinged me now.
[12:18] <rbasak> doko: are you expecting to take any action or asking me to take any action about python-trio?
[12:19] <doko> rbasak: I asked Laney now to ignore the autopkg test failures as a stop gap. I see that we have inconsistant versions, and I don't want to spend time investing these universe packages
[12:20] <Laney> I dunno what's going on to be honest
[12:20] <Laney> I pointed out a typo, and then I got in response what seems like a very strange refusal to re-upload a fixed version
[12:20] <rbasak> I think it's OK to kick out of the release pocket in Ubuntu anything that is being caught up by this, but I don't think it's necessary for python-trio itself.
[12:21] <doko> sure, so that's why I'm asking to ignore the autopkg test for now
[12:24] <rbasak> I would just kick python-msrest out of the release pocket
[12:25] <rbasak> (which might need kicking out python-msrestazure too)
[12:27] <rbasak> Or, consider the current version of 0.5.5-1 in the release pocket good, as it is in Debian
[12:27] <rbasak> And that /0.6.1-1(ubuntu1)?/ is correct in not migrating
[12:27] <rbasak> Since AFAICT the test is revealing a real problem here?
[12:28] <doko> rbasak: it's already broken in the release: http://autopkgtest.ubuntu.com/packages/p/python-msrestazure/eoan/amd64
[12:30] <rbasak> I've not looked in detail to confirm, but it seems to me that the autopkgtest failure in the release pocket is a different root cause
[12:31] <rbasak> IMHO, either some MOTU volunteers to fix this (I'm suggesting that it's not the job of any Canonical employee to fix everything in universe) or we should kick out what we know to be broken in the release pocket.
[12:31] <rbasak> Which might be just python-msrestazure then.
[12:33] -queuebot:#ubuntu-release- Unapproved: flash-kernel (eoan-proposed/main) [3.98ubuntu4 => 3.98ubuntu5] (core)
[12:33] <doko> ... + python-azure, python-azure-storage, python-django-storages, ...
[12:39] <rbasak> Laney: are you available to badtest hint the two reds for mysql-8.0 please? Or would you prefer one or two MPs?
[12:39] <rbasak> Neither are caused by the mysql update
[12:39] <rbasak> (as evidenced by recent failures in tests not triggered by mysql-8.0)
[12:49] -queuebot:#ubuntu-release- Unapproved: python-defaults (eoan-proposed/universe) [2.7.16-1 => 2.7.17-1] (kubuntu)
[12:51] <rbasak> ^ https://code.launchpad.net/~racb/britney/mysql-8.0-migration/+merge/373960
[13:01] <didrocks> sil2100: are the ubuntu-images autopkgtests known to be flaky? The "mount" tests fails on both amd64 and s390x and the grub change we have is unrelated to it
[13:01] <didrocks> (in the history, the tests seemed to be reliable)
[13:16] -queuebot:#ubuntu-release- Unapproved: shoogle (eoan-proposed/universe) [0.1.4-7 => 0.1.4-8] (no packageset) (sync)
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted shoogle [sync] (eoan-proposed) [0.1.4-8]
[13:17] <doko> RikMills: why is python2 (python-defaults) still in the kubuntu set?
[13:21] <RikMills> doko: I have no clue. it is not seeded or 'supported'
[13:33] <sil2100> didrocks: hmm, so I'd have to look at it again, but I feel like there has been some flakyness in mount in the past - can't remember for which arches, let me take a look in a moment
[13:34] <didrocks> sil2100: sure! as long as tomorrow's image has the new grub, it's good :)
[13:34] -queuebot:#ubuntu-release- Unapproved: gnome-session (eoan-proposed/main) [3.34.1-1ubuntu1 => 3.34.1-1ubuntu2] (ubuntu-desktop)
[13:40] <cjwatson> python> https://people.canonical.com/~ubuntu-archive/germinate-output/kubuntu.eoan/rdepends/python-defaults/python near the end shows it: kubuntu-desktop Recommends: konversation Depends: konversation-data Recommends: python
[13:40] <cjwatson> RikMills: ^-
[13:43] -queuebot:#ubuntu-release- Unapproved: thunderbird (eoan-proposed/main) [1:68.1.1+build1-0ubuntu1 => 1:68.1.2+build1-0ubuntu1] (mozilla, ubuntu-desktop)
[13:46] <RikMills> cjwatson: ah. want that fixed
[13:46] <didrocks> sil2100: ok, they were flaky
[13:48] <sil2100> \o/
[13:48] <sil2100> ;p
[13:48] <sil2100> I mean, I shouldn't be happy about that
[13:49] <didrocks> sil2100: heh, don't show it at least ;)
[13:55] <doko> RikMills: fix uploaded, waiting in the queue
[13:55] -queuebot:#ubuntu-release- Unapproved: konversation (eoan-proposed/universe) [1.7.5-1ubuntu2 => 1.7.5-1ubuntu3] (kubuntu)
[13:56] <RikMills> doko: did you fix the current FTBFS in proposed?
[13:57] <doko> RikMills: oops, no. do you want to take the diff for your next upload?
[13:57] <RikMills> needed: https://cgit.kde.org/konversation.git/commit/?h=1.7&id=4d0036617becc26a76fd021138c98aceec4c7b53
[13:57] <doko> RikMills: do you want me to upload?
[13:57] <RikMills> doko: Qt 5.13 in that is a fib ^^ it is another reason
[13:58] <RikMills> doko: if you like, I am doing other things right now
[13:58] <doko> ok, doing
[14:07] -queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (disco-proposed) [0.131ubuntu19.2]
[14:08] -queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (bionic-proposed) [0.130ubuntu3.9]
[14:08] -queuebot:#ubuntu-release- Unapproved: konversation (eoan-proposed/universe) [1.7.5-1ubuntu2 => 1.7.5-1ubuntu3] (kubuntu)
[14:08] -queuebot:#ubuntu-release- Unapproved: rejected konversation [source] (eoan-proposed) [1.7.5-1ubuntu3]
[14:09] -queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.16]
[14:17] -queuebot:#ubuntu-release- Unapproved: openjdk-14 (eoan-proposed/universe) [14~14-2 => 14~18-1] (no packageset)
[14:19] -queuebot:#ubuntu-release- Unapproved: accepted openjdk-14 [source] (eoan-proposed) [14~18-1]
[14:33] -queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [source] (eoan-proposed) [3.98ubuntu5]
[14:33] -queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (eoan-proposed) [1:68.1.2+build1-0ubuntu1]
[14:33] <Laney> rbasak: I'll have a look (was out at lunch)
[14:33] -queuebot:#ubuntu-release- Unapproved: accepted gnome-session [source] (eoan-proposed) [3.34.1-1ubuntu2]
[14:33] <Laney> & getting stabbed in the arm with a needle
[14:33] <Laney> looks like apw did it
[14:48] -queuebot:#ubuntu-release- New: accepted linux-restricted-modules-aws [sync] (eoan-proposed) [5.3.0-1002.2+1]
[14:48] -queuebot:#ubuntu-release- New: accepted linux-restricted-modules-oracle [sync] (eoan-proposed) [5.3.0-1001.1]
[14:48] -queuebot:#ubuntu-release- New: accepted linux-restricted-modules-azure [sync] (eoan-proposed) [5.3.0-1002.2]
[14:51] -queuebot:#ubuntu-release- New: accepted linux-restricted-modules-gcp [sync] (eoan-proposed) [5.3.0-1003.3]
[15:02] -queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (eoan-proposed/main) [149 => 150] (ubuntu-desktop)
[15:12] <apw> infinity, i am assuming you will review the kernels in Unapproved; i have reviewed the corresponding lrms in New and you are free to accept them in sycn
[15:13] <apw> (as i assume you are expecting them)
[15:14] <rbasak> Laney, apw: thank you for poking at MySQL for me. It looks like it's all landed and done now.
[15:25] <Laney> nice one
[15:41] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-430 (eoan-proposed/restricted) [430.50-0ubuntu1 => 430.50-0ubuntu2] (ubuntu-desktop)
[15:41] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-435 (eoan-proposed/restricted) [435.21-0ubuntu1 => 435.21-0ubuntu2] (no packageset)
[15:41] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-340 (eoan-proposed/restricted) [340.107-0ubuntu6 => 340.107-0ubuntu7] (ubuntu-desktop)
[15:41] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (eoan-proposed/restricted) [390.129-0ubuntu1 => 390.129-0ubuntu2] (core)
[15:42] <tseliot> apw, Laney: hey, I know it's not ideal (given the date), but I think it would be worth having the two fixes for nvidia in, unless we want to break dist-upgrades from Disco, or we want suspend to be broken on some systems (see the changelog)
[15:43] <tseliot> these nvidia ^^
[15:43] <tseliot> help would be very welcome
[16:02] -queuebot:#ubuntu-release- Unapproved: accepted python-defaults [source] (eoan-proposed) [2.7.17-1]
[16:08] <doko> ginggs, LocutusOfBorg, apw: so yes, python-sparse/i386 succeeded with the "no-change" six upload
[16:08] <LocutusOfBorg> meh, will look
[16:11] <LocutusOfBorg> doko, no
[16:11] <LocutusOfBorg> 0.2.0-1	python3-defaults/3.7.5-1	2019-10-10 12:32:55 UTC	0h 03m 09s	doko	fail	log   artifacts
[16:11] <LocutusOfBorg> this run was bad, but with latest sparse
[16:12] <LocutusOfBorg> 0.2.0-1	python3-defaults/3.7.5-1	2019-10-10 14:33:35 UTC	0h 03m 29s	doko	pass	log   artifacts
[16:12] <LocutusOfBorg> this one is good with same packages
[16:12] <doko> 0.2.0-1	python3-defaults/3.7.5-1	2019-10-10 14:33:35 UTC	0h 03m 29s	doko	pass
[16:13] <LocutusOfBorg> yes, and the very same run with the very same installed packages failed two hours before
[16:13] <LocutusOfBorg> I would say more flaky test rather than rebuild neede4d
[16:18] <doko> vorlon: django-compat/unknown still needs on override
[16:25] <Laney> tseliot: eek
[16:27] <tseliot> Laney, I wouldn't ask if it weren't really urgent, especially LP: #1830961 . Sorry
[16:27] <Laney> no worries
[16:27] <Laney> but someone other than me might know better about the compiler flags stuff
[16:27] <Laney> apw: got a chance to check them maybe?
[16:28] <apw> sforshee, ^ i think you are our -fcf-protection guru
[16:29] <Laney> delegation in action
[16:30] <tseliot> apw, Laney: those flags are set by the kernel in Eoan, but they are not in Disco, which is a problem when dist-upgrading. sforshee commented here, but I don't know if the fix was backported to 19.04 https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1830961/comments/36
[16:35] <ginggs> doko: i have no idea how!  i diffoscope'd the binaries and they were essentially identical
[16:35] <sforshee> Laney, tseliot: I did send those for sru to b/d, but seems they haven't been released yet
[16:35] <ricotz> hello, vala is currently stuck in -proposed due to some unrelated automake-1.16 test failure, I hoping it is possible to force a transition to get it into the release -- https://launchpad.net/ubuntu/+source/vala/0.44.9-0ubuntu1
[16:35] <sforshee> yes, looks like they are in the -proposed kernels
[16:46] <apw> sforshee, the ones expected to release the monday after release; correct ?
[16:47] <sforshee> apw: yes, unfortunately. When I sent them I thought they would be out before the release, either I was off or there was a delay in the cycle
[16:50] <apw> sforshee, likley the extension of cycle-1 to 4 weeks has skewed things
[16:50] <sforshee> yeah, wasn't paying close enough attention to that I guess
[16:51] <bittin_> RC of 19.10 in 10 minutes
[16:51] <apw> upgrades are triggered by our meta-data updates arn't they? so we might be able to wait on them
[16:53] <tseliot> apw, sforshee: my patch in the nvidia drivers check if the flags are available in the default compiler, and disables that. This should work regardless of whether users have the updated kernel
[16:54] <sforshee> tseliot: but other dkms modules are also affected
[16:54] <sforshee> so unless we can make dkms do likewise ...
[16:54] <apw> sforshee, so one of those "if the dkms upgrades first we are ok, otherwise not" situations
[16:55] <sforshee> apw: well there's no such patch to dkms yet, but yes I suppose then we'd have that situation
[16:55] <infinity> apw: We could delay the meta-release upgrade stuff, but we almost never do for more than a few days for non-LTS.
[16:56] <apw> infinity, right, that, well the kernels for disco would release the monday after rellease
[16:56] <infinity> apw: But if these are scheduled to go out on the Monday post-release, releasing them Wed/Thurs would only be a few business days early.  Maybe we can get testing all done by then?
[16:56] <apw> infinity, would we need to do anyhing more than disco for this ?
[16:57] <infinity> apw: Nope.
[16:57] <apw> sforshee, ok so we need to go back to stable and tell them they need to expedite disco out early
[16:57] <apw> slightly early
[16:57] <infinity> apw: bionic needs to be fixed before disco EOLs (cause then the non-LTS upgrade path from bionic will be to eoan), but right now, bionic upgrades go through disco, so disco is the only place the fix must exist by eoan release.
[16:58] <tseliot> sforshee, oh, right
[16:59] <apw> infinity, i beleive all the kernls are fixed on that cycle, so monday right sforshee ?
[16:59] <sforshee> correct
[17:01] <infinity> apw: Sure, I gathered that, my point is that only disco needs to be expedited, cause the bionic fix isn't (yet) urgent.
[17:01] <apw> infinity, ack, best to be utterly clear
[17:09] <vorlon> infinity: there are some seeded nvidias coming in per tseliot's comments regarding criticality
[17:10] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-435 [source] (eoan-proposed) [435.21-0ubuntu2]
[17:11] <vorlon> there are linked bugs so if these need to be diverted to -updates they can be
[17:12] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-430 [source] (eoan-proposed) [430.50-0ubuntu2]
[17:13] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-390 [source] (eoan-proposed) [390.129-0ubuntu2]
[17:13] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (eoan-proposed) [340.107-0ubuntu7]
[17:13] -queuebot:#ubuntu-release- Unapproved: firewalld (eoan-proposed/universe) [0.7.1-1ubuntu9 => 0.7.2-1] (no packageset) (sync)
[17:14] -queuebot:#ubuntu-release- Unapproved: accepted firewalld [sync] (eoan-proposed) [0.7.2-1]
[17:15] <tomreyn> the 19.10 RC bittin_ announced, would that go to http://cdimage.ubuntu.com/releases/19.10/ ?
[17:16] -queuebot:#ubuntu-release- Unapproved: hedgewars (eoan-proposed/universe) [0.9.25-5build3 => 1.0.0-2] (no packageset) (sync)
[17:16] -queuebot:#ubuntu-release- Unapproved: accepted hedgewars [sync] (eoan-proposed) [1.0.0-2]
[17:20] <infinity> tomreyn: I don't know who or what a bittin_ is, and no, RCs are just the dailies leading up to final release, there's no formal publishing for them.
[17:21] <tomreyn> thanks infinity - i was referring to this above: <bittin_> RC of 19.10 in 10 minutes
[17:21] <RikMills> what?
[17:22] <infinity> Indeed, what? :)
[17:22] <infinity> tomreyn: Let me reiterate the "I don't know who or what a bittin_ is", in the sense that he doesn't speak for the Ubuntu release team. :)
[17:22] <RikMills> oh, in #ubuntu+1
[17:22] <tomreyn> also here
[17:23] <tomreyn> at :51
[17:23] <infinity> So he did.  Right in the middle of a conversation I was in too.
[17:23] <infinity> Mentally filtered it right out. :P
[17:23] <tomreyn> thanks for clarifying, guess i got bittin_ rolled.
[17:24] <infinity> tomreyn: We all get bittin_ sometimes.
[17:25] <infinity> tomreyn: Anyhow, if you're curious about RCs because you want to help test a flavour or two, I expect based on the current state of things that are in flight that the first set will be posted to the ISO tracker sometime late tonight (US Pacificish time).
[17:25] <infinity> Though that depends on how quickly sil2100 can shove langpack updates in.
[17:26] <infinity> And some other bits and bobs.
[17:26] <infinity> Not uncommon for me to spin the first RCs on Saturday from an airport, but I think we'll be earlier than that this cycle.  Maybe.
[17:27] <RikMills> :)
[17:28] <tomreyn> :) good luck there. i'll watch.
[17:29] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [5.0.0-1021.21~18.04.1] (kernel)
[17:30] <RikMills> don't watch. help test. ;)
[17:32] <tomreyn> oh i most likely will (if maybe not the QA way). thanks for the invitation.
[17:39] <sil2100> cwayne, plars, bdmurray: the pi respins have finished building: http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20191010.1/
[17:40] <sil2100> infinity: I'll try to be as fast as possible!
[17:40] <cwayne> sil2100: ack thanks, should get pulled automatically for pi2/3, and plars can take care of 4
[17:41]  * sil2100 whips language-pack-exporter
[17:41] <sil2100> cwayne: thanks! Hopefully those should work on the pi4 fine - but that being said, I didn't check the manifests
[17:41] <sil2100> Anyway, those are test images for now
[17:49] -queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.22 => 229-4ubuntu21.23] (core)
[17:50] -queuebot:#ubuntu-release- Unapproved: dbus (xenial-proposed/main) [1.10.6-1ubuntu3.4 => 1.10.6-1ubuntu3.5] (core)
[18:01] -queuebot:#ubuntu-release- Unapproved: linux-azure (eoan-proposed/main) [5.3.0-1002.2 => 5.3.0-1003.3] (core, kernel) (sync)
[18:01] -queuebot:#ubuntu-release- Unapproved: linux-meta-oracle (eoan-proposed/main) [<IP_ADDRESS>1.1 => <IP_ADDRESS>2.2] (core, kernel) (sync)
[18:01] -queuebot:#ubuntu-release- Unapproved: linux-oracle (eoan-proposed/main) [5.3.0-1001.1 => 5.3.0-1002.2] (core, kernel) (sync)
[18:01] -queuebot:#ubuntu-release- Unapproved: linux-restricted-modules-azure (eoan-proposed/restricted) [5.3.0-1002.2 => 5.3.0-1003.3] (kernel) (sync)
[18:01] -queuebot:#ubuntu-release- Unapproved: linux-meta-azure (eoan-proposed/main) [<IP_ADDRESS>2.19 => <IP_ADDRESS>3.20] (core, kernel) (sync)
[18:01] -queuebot:#ubuntu-release- Unapproved: linux-raspi2 (eoan-proposed/universe) [5.3.0-1006.7 => 5.3.0-1007.8] (kernel) (sync)
[18:01] -queuebot:#ubuntu-release- Unapproved: linux-meta-raspi2 (eoan-proposed/universe) [<IP_ADDRESS>6.2 => <IP_ADDRESS>7.3] (kernel) (sync)
[18:01] -queuebot:#ubuntu-release- Unapproved: linux-restricted-modules-oracle (eoan-proposed/restricted) [5.3.0-1001.1 => 5.3.0-1002.2] (kernel) (sync)
[18:02] -queuebot:#ubuntu-release- Unapproved: linux-signed-azure (eoan-proposed/main) [5.3.0-1002.2 => 5.3.0-1003.3] (core, kernel) (sync)
[18:02] -queuebot:#ubuntu-release- Unapproved: linux-signed-oracle (eoan-proposed/main) [5.3.0-1001.1 => 5.3.0-1002.2] (core, kernel) (sync)
[19:25] <sil2100> Uploading language-packs, will approve them from the queue once they're all there
[19:29] <cyphermox> seb128: vorlon: is ubiquity ready for upload?
[19:30] <cyphermox> well, it doesn't matter really, I guess we'll definitely get a bugfix in to land the translation changes
[20:07] <sil2100> infinity: packages being accepted right now
[20:07] -queuebot:#ubuntu-release- Unapproved: linux-kvm (eoan-proposed/main) [5.3.0-1002.2 => 5.3.0-1003.3] (core, kernel) (sync)
[20:07] -queuebot:#ubuntu-release- Unapproved: linux-meta-kvm (eoan-proposed/main) [<IP_ADDRESS>2.2 => <IP_ADDRESS>3.3] (core, kernel) (sync)
[20:07] -queuebot:#ubuntu-release- Unapproved: linux-signed (eoan-proposed/main) [5.3.0-17.18 => 5.3.0-18.19+1] (core, kernel) (sync)
[20:07] -queuebot:#ubuntu-release- Unapproved: linux-meta-gcp (eoan-proposed/main) [<IP_ADDRESS>3.3 => <IP_ADDRESS>4.4] (core, kernel) (sync)
[20:07] -queuebot:#ubuntu-release- Unapproved: linux-signed-gcp (eoan-proposed/main) [5.3.0-1003.3 => 5.3.0-1004.4] (core, kernel) (sync)
[20:09] -queuebot:#ubuntu-release- Unapproved: linux-aws (eoan-proposed/main) [5.3.0-1002.2 => 5.3.0-1003.3] (core, kernel) (sync)
[20:09] -queuebot:#ubuntu-release- Unapproved: linux-meta-aws (eoan-proposed/main) [<IP_ADDRESS>2.2 => <IP_ADDRESS>3.3] (core, kernel) (sync)
[20:09] -queuebot:#ubuntu-release- Unapproved: linux-restricted-modules (eoan-proposed/restricted) [5.3.0-17.18 => 5.3.0-18.19] (core, kernel) (sync)
[20:09] -queuebot:#ubuntu-release- Unapproved: linux-gcp (eoan-proposed/main) [5.3.0-1003.3 => 5.3.0-1004.4] (core, kernel) (sync)
[20:09] -queuebot:#ubuntu-release- Unapproved: linux (eoan-proposed/main) [5.3.0-17.18 => 5.3.0-18.19] (core, kernel) (sync)
[20:09] -queuebot:#ubuntu-release- Unapproved: linux-meta (eoan-proposed/main) [<IP_ADDRESS>.19 => <IP_ADDRESS>.20] (core, kernel) (sync)
[20:10] -queuebot:#ubuntu-release- Unapproved: konversation (eoan-proposed/universe) [1.7.5-1ubuntu2 => 1.7.5-1ubuntu3] (kubuntu)
[20:10] -queuebot:#ubuntu-release- Unapproved: linux-signed-gcp (eoan-proposed/main) [5.3.0-1003.3 => 5.3.0-1004.4] (core, kernel) (sync)
[20:10] -queuebot:#ubuntu-release- Unapproved: linux-azure (eoan-proposed/main) [5.3.0-1002.2 => 5.3.0-1003.3] (core, kernel) (sync)
[20:10] -queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (eoan-proposed/main) [149 => 150] (ubuntu-desktop)
[20:13] <plars> sil2100: waveform: just to confirm - the pi2/3/4/cm3 all use the same raspi3 image now, correct? any plan to get rid of the raspi2 image there which seems to have a different checksum?
[20:28] <sil2100> plars: ah, good catch! So actually we no longer build any raspi2 images, but apparently cdimage 'copies over' the old images everytime a new build is happening
[20:28] <sil2100> So those images are actually from June
[20:28] <sil2100> (the raspi2 ones)
[20:28] <sil2100> Need to remove those, forgot about this cdimage functionality, just disabling the arch is not enough!
[20:29] <infinity> sil2100: \o/
[20:29] <rbalint> sil2100, could you please merge this for systemd? https://code.launchpad.net/~rbalint/britney/autopkgtest-eoan-hints/+merge/373987
[20:30] <rbalint> sil2100, infinity also could systemd please go in to eoan release?
[20:31] <plars> sil2100: waveform: I have some fixups to somehow do to make some tests work with eoan so things may not show up on the image testing board for now.  But I'm at least booting and checking dmesg, apt-get, etc for now. So far most things are looking ok, but rpi3ap doesn't seem to boot in the lab. I'll try it at home too, but it only gets as far as "Starting kernel ..." then nothing
[20:34] <ginggs> LocutusOfBorg: check in the log of the  	2019-10-10 14:33:35 UTC python-sparse/i386 test to see the actual version of python3-six that was installed
[20:52] <LocutusOfBorg> ginggs, I melded them... no differences in apt
[20:53] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [5.0.0-1021.21~18.04.1]
[20:59] -queuebot:#ubuntu-release- Unapproved: libpcap (eoan-proposed/main) [1.9.0-2build1 => 1.9.1-2] (core) (sync)
[21:02] <vorlon> cyphermox: from seb's commit message I figured the .pot file might also need regenerating in the source branch; I hadn't looked that far yet, can you carry it across the finish line for upload?
[21:06] <cyphermox> sure; I was questioning whether to wait for any last-minute fixes for something else
[21:06] <cyphermox> otoh if we want any translations for it; there might be a chance to get some the sooner it's in rather than later
[21:07] <cyphermox> OTOH, I think I see something odd there; there's already a translatable "Skip" string; looks like this was meant to be composited previously.... but it's also not going to work with shortcuts
[21:09] <seb128>  cyphermox, "Skip" is another string even if technically it's the same word, the translation for that string exists in other templates (e.g nautilus) so it should be easy to just revalidate for translators
[21:45] <cyphermox> seb128: what I mean is that I think this was meant to be composited in; but it never worked
[21:45] <cyphermox> it's irrelevant anyway, we just need to remember how to update the templates.pot file now ;)
[21:45] <cyphermox> I think I figured it out, just trying to get it right
[21:45] <cyphermox> (templates.pot gets updated in one command, but the update is a bit wonky)
[21:48] <cyphermox> heh, I just had the wrong command
[21:48] <cyphermox> seb128: anyway; you okay with me uploading this now?
[21:48] <seb128> cyphermox, well if there is no other change don't bother, I just did an upload of the template to launchpad manually
[21:48] <seb128> so no need of a source upload
[21:50] <cyphermox> ah, cool
[21:50] <cyphermox> you mean debian/real-po/templates.pot manually edited to add _Skip ?
[21:52] <seb128> cyphermox, I downloaded the current one from https://translations.launchpad.net/ubuntu/eoan/+source/ubiquity/+pots/ubiquity-debconf/+export , edited to add the string and uploaded on https://translations.launchpad.net/ubuntu/eoan/+source/ubiquity/+pots/ubiquity-debconf/+upload
[21:52] <seb128> cyphermox, which worked, string is there, https://translations.launchpad.net/ubuntu/eoan/+source/ubiquity/+pots/ubiquity-debconf/fr/30/+translate
[21:55] <cyphermox> cool
[21:56] <seb128> cyphermox, we should use debconf-updatepo to update the tempalte/translations still before the next upload though otherwise my change will be overwriten by the import
[21:56] <cyphermox> fwiw; updating debian/real-po/templates.pot from the debian/ubiquity.templates is as simple as running debconf-updatepo
[21:56] <cyphermox> yup
[21:56] <seb128> so if you want to do that and commit that would be useful
[21:56] <seb128> thx
[21:56] <cyphermox> (I'm applying that)
[21:56] <seb128> great
[21:56] <seb128> thx
[22:15] -queuebot:#ubuntu-release- Unapproved: atk1.0 (eoan-proposed/main) [2.34.0-1 => 2.34.1-1] (core) (sync)
[22:16] -queuebot:#ubuntu-release- Unapproved: at-spi2-core (eoan-proposed/main) [2.34.0-2 => 2.34.0-3] (core) (sync)
[22:16] -queuebot:#ubuntu-release- Unapproved: rejected at-spi2-core [sync] (eoan-proposed) [2.34.0-3]
[22:16] -queuebot:#ubuntu-release- Unapproved: rejected atk1.0 [sync] (eoan-proposed) [2.34.1-1]
[22:17] -queuebot:#ubuntu-release- Unapproved: gnome-calendar (eoan-proposed/main) [3.34.1-1 => 3.34.2-1] (desktop-extra, ubuntu-desktop) (sync)
[22:18] -queuebot:#ubuntu-release- Unapproved: network-manager (eoan-proposed/main) [1.20.4-2ubuntu1 => 1.20.4-2ubuntu2] (desktop-core)
[22:27] -queuebot:#ubuntu-release- Unapproved: ubuntu-settings (eoan-proposed/main) [19.10.2 => 19.10.3] (ubuntu-desktop)
[22:47] -queuebot:#ubuntu-release- Unapproved: accepted apt [source] (trusty-proposed) [1.0.1ubuntu2.24]
[22:51] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.0.0-32.34~18.04.2] (kernel)
[22:51] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.0.0-32.34~18.04.2] (kernel)
[22:51] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (disco-proposed/main) [5.0.0-1005.9] (core, kernel)
[22:51] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.0.0-32.34~18.04.2] (kernel)
[22:51] -queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1025.28] (no packageset)
[22:51] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (disco-proposed) [5.0.0-1005.9]
[22:52] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.0.0-32.34~18.04.2]
[22:52] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.0.0-32.34~18.04.2]
[22:52] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.0.0-32.34~18.04.2]
[22:52] -queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1025.28]
[22:58] -queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1022.22~18.04.3] (kernel)
[23:01] -queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1022.22~18.04.3]
[23:20] -queuebot:#ubuntu-release- Unapproved: gnome-2048 (eoan-proposed/universe) [3.34.0-1 => 3.34.1-1] (ubuntu-budgie) (sync)
[23:21] -queuebot:#ubuntu-release- Unapproved: gnome-tetravex (eoan-proposed/universe) [1:3.34.0-1 => 1:3.34.1-1] (desktop-extra) (sync)
[23:26] -queuebot:#ubuntu-release- Unapproved: gjs (eoan-proposed/main) [1.58.0-1 => 1.58.1-1] (desktop-core, desktop-extra, mozilla) (sync)
[23:30] -queuebot:#ubuntu-release- Unapproved: gpaste (eoan-proposed/universe) [3.34.0-1 => 3.34.1-1] (no packageset) (sync)
[23:30] -queuebot:#ubuntu-release- Unapproved: accepted gpaste [sync] (eoan-proposed) [3.34.1-1]
[23:35] -queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-workspaces-to-dock (eoan-proposed/universe) [51-1 => 52-1] (no packageset) (sync)
[23:36] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-workspaces-to-dock [sync] (eoan-proposed) [52-1]
[23:47] -queuebot:#ubuntu-release- Unapproved: ruby-gnome (eoan-proposed/universe) [3.3.8-2 => 3.4.0-1] (no packageset) (sync)
[23:47] -queuebot:#ubuntu-release- Unapproved: accepted ruby-gnome [sync] (eoan-proposed) [3.4.0-1]


[14:30] <lordpsyan> I know this is probably the wrong place, but finding help has become extremely difficult. I need to configure ircd-hybrid. I can make a connection, but logging in seems to not work.
[14:32] <Pici> lordpsyan: Well, if you have a look at the /topic , you can see that this isn't really the right place either.  The folks in #freenode should be able to point you in the right direction for finding the channel for that.
[14:32] <lordpsyan> Pici: Thanks.
[15:45] <compengi> how many ubuntu helping bots for loco teams you got?
[15:49] <jpds> compengi: We have ubottu (main bot) and ubot3 (backup).
[15:51] <nizarus> compengi, for loco teams we got locobot_4 to log conversations
[15:52] <nizarus> but these days nothing is logged
[15:53] <jpds> nizarus: Oh? Something wrong?
[15:54] <nizarus> yes jpds
[15:54] <nizarus> look at : http://logs.ubuntu-eu.org/free/2008/08/03/
[15:54] <nizarus> and http://logs.ubuntu-eu.org/free/2008/08/04/
[15:55] <Rafik> jpds, we contacted ubuntu-eu admins about this issue. Many other ops reported the same thing here on this channel
[15:55] <jpds> I didn't know that. Thanks.
[15:56] <nizarus> for not at all jpds
[15:57] <Rafik> jpds, yw, you can do any thing with this ?
[15:57] <jpds> Rafik: No, I'm afraid; I'm not part of the ubuntu-eu team.
[15:57] <compengi> jpds, but as i can see that ubot3 is not so stable
[15:58] <compengi> it's connection is timed out now for example
[15:58] <nizarus> jpds, locobot_2 also don't log anything
[15:58] <jpds> compengi: It's on a volunteer's connection.
[15:58] <jpds> nizarus: Appears that nothing is being logged...
[15:59] <compengi> jpds, yeah i  know. what i was trying to say, is that i got a 9MB connection down and 8MB connection up. i could host a bot of yours
[15:59] <Rafik> nizarus, all LoCoBots have the same issue
[16:01] <nizarus> Rafik, jpds, i think that this issue started with the apparition of locobot_4_2
[16:02] <nizarus> but downgrading it seem's that it havent solve th issue :/
[16:02] <Rafik> nizarus, let's pray :)
[16:03] <jpds> compengi: I'm not sure what the process for hosting backup bots is; I suggest sending a mail to<EMAIL_ADDRESS>- explaining what you'd like to do/bandwidth you have, etc.
[16:04] <compengi> jpds, Okay..
[16:05] <jpds> compengi: See: https://lists.ubuntu.com/mailman/listinfo/ubuntu-irc if you're not subscribed to it.
[16:30] <jpds> compengi: Mail got through, thanks!
[16:31] <compengi> jpds, welcome :D
[16:31] <jpds> ompaul: ^
[16:32] <ompaul> jpds, similar idea iirc
[19:14] <pressenter> Good afternoon.
[19:14] <pressenter> Please lookout for user ga-ma.
[19:14] <pressenter> He's a troll/flamer.
[19:15] <pressenter> Banned already on #ubuntu-pl, now sitting in #ubuntu.
[19:36] <jpds> pressenter: Should he do anything wrong, please call us with !o.ps (without the ".") in the channel.
[19:36] <Pici> in #ubuntu, that is.
[19:44] <pressenter> Ok, thank you.
[22:39] <nizarus> bug report about Locobot : https://bugs.edge.launchpad.net/ubuntu-bots/+bug/254782


[10:41] <Odd_Bloke> smoser: I'd like to split the walinuxagent stuff in to a separate file (with a view to perhaps making it a standalone library in the future); does that sound reasonable?  If so, where would be the best location for it in the tree?
[12:59] <smoser> Odd_Bloke, well, there is a sources/helpers/openstack.py
[12:59] <smoser> seems similar ?
[12:59] <Odd_Bloke> Yeah, that would probably make sense.
[13:50] <Odd_Bloke> smoser: Apologies for MP-related email noise; I'm going to split walinuxagent stuff out to a helper package and then resubmit the MP.
[13:50] <smoser> ok


[00:04] <kbulgrien> interesting... bzr status sometimes fails to report status if the file happens to not have read perms for the user.
[00:05] <kbulgrien> ie `bzr add this; bzr status` shows added.
[00:05] <kbulgrien> `bzr add this; chmod a-r this; bzr status` shows nothing
[00:06] <kbulgrien> `bzr add this; chmod a-r this; bzr status this` shows status
[00:06] <kbulgrien> really, there's a good reason I'd like status in this case...
[00:07] <kbulgrien> but I guess that's kind of wierd.  oh well.
[00:07] <kbulgrien> hmm. I wonder if that is true for both heavy and light checkouts.  I'm in a light checkout.
[00:10] <kbulgrien> hmm. something happened.  maybe I was crosseyed.  It's now showing status.
[00:11] <kbulgrien> I was crosseyed.
[00:25] <kbulgrien> hum. somehow I have made things so bzr status hangs.
[00:27] <kbulgrien> strace is unhelpful
[00:29] <kbulgrien> I guess I am hosed.  I don't know how to fix.
[00:31] <kbulgrien> bzr check shows nothing bad.
[01:00] <kbulgrien> afaict, only bzr status is messed.
[01:02] <kbulgrien> And as long as I put in explicit file names, bzr status is ok, just not `bzr status` or it hangs solid.
[02:41] <kbulgrien> appears that 2.5.0 has the problem fixed.\
[02:58] <kbulgrien> for that matter 2.4.2 is fixed.
[03:32] <kbulgrien> head is hurting.  having hard time figuring out what I did wrong.  set up repo, init an area under it, checked out somewhere else. added, committed, but can't see anything going into the repo.
[03:33] <kbulgrien> Anyone want to help.  Shared repo tutorial isnt very tutorial
[03:56] <stlsaint> i changed my default python now bzr has stopped working
[04:16] <bob2> what did you change it to
[04:16] <bob2> kbulgrien, it's unclear what you did
[04:17] <bob2> pastebin shell history?
[04:23] <kbulgrien> well, shell history is so scattered, not sure pastebin will help here.
[04:24] <kbulgrien> I guess I could pastebin a reconstruction
[04:24] <kbulgrien> I don't know how to set up a new "lockstep" project.
[04:25] <kbulgrien> I've obviously done it wrong because there is nothing going into the shared repo
[04:25] <kbulgrien> I can't push or pull
[04:25] <kbulgrien> It says there's nothing.
[04:26] <kbulgrien> the shared repo data shows the revision that is in my checkout, but all the goods are in the checkout and won't go up into the repo
[04:29] <bob2> I think you're just confused about trees vs branches
[04:29] <kbulgrien> I come from cvs background
[04:30] <bob2> condolences
[04:30] <kbulgrien> it works
[04:30] <kbulgrien> no need to feel sorry
[04:30] <bob2> anyway, it's still not clear what you're saying, to me
[04:31] <bob2> do you mean "I made a repo, with init-repo --no-trees, then did 'bzr init' in some dir, then added and commited some files, then pushed to the repo, but the 'branch' dir, in the repo, is empty?"?
[04:33] <kbulgrien> bzr init-repo --no-trees top; bzr init-repo --no-trees top/mid; bzr init top/mid/bot;
[04:34] <kbulgrien> somewhere else I did bzr checkout --lightweight top/mid/bot .
[04:34] <kbulgrien> I probably should not have done --lightweight
[04:34] <kbulgrien> I did adds and commits in the checkout.
[04:34] <bob2> why did you make two nested repositories?
[04:35] <bob2> and is the problem you're asking about that 'top/mid/bot' doesn't have all your files in it?
[04:35] <kbulgrien> I thought I was making a repository for multiple projects
[04:35] <bob2> not sure what you mean
[04:35] <bob2> but you don't need (or want) to nest repos
[04:35] <bob2> just init a branch somewhere inside the repository
[04:36] <kbulgrien> yes, there are no files in top/mid/bot
[04:36] <bob2> that's what no-trees means
[04:36] <bob2> all the rev data is in .bzr in the /repo root/ and .bzr in the /branch/ has some pointers (and no data itself)
[04:36] <kbulgrien> then why do docs say to use no-trees for centralized server repos
[04:36] <bob2> because it's a good idea
[04:36] <bob2> since 'bzr push' doesn't update checked out files
[04:36] <kbulgrien> what is a centralized server if it has no data
[04:36] <bob2> and newbies get immensely confused by that
[04:36] <bob2> :-/
[04:37] <bob2> it has /all the revision data/
[04:37] <bob2> 15:36:28 < bob2> all the rev data is in .bzr in the /repo root/ and .bzr in the /branch/ has some pointers (and no data itself)
[04:37] <kbulgrien> The commit comments don't do me any good without the data
[04:37] <bob2> you're confused
[04:37] <bob2> all the data is there
[04:37] <bob2> there is just no checked out copies of the working tree
[04:37] <bob2> that's what --no-trees does - not check out the files
[04:37] <kbulgrien> I am looking at the file system.
[04:37] <kbulgrien> there is no data
[04:37] <kbulgrien> only meta data
[04:38] <bob2> false, fortunately
[04:38] <bob2> one last time: all the revision data is in the .bzr dir of the /repository/ (ie in the root), the .bzr dir in the /branch in the repo/ just refers to the revision data in the repo itself
[04:39] <kbulgrien>  du
[04:39] <kbulgrien> 1.0K	./.bzr/branch-lock
[04:39] <kbulgrien> 1.0K	./.bzr/branch/lock
[04:39] <kbulgrien> 5.0K	./.bzr/branch
[04:39] <kbulgrien> 9.0K	./.bzr
[04:39] <kbulgrien> 10K	.
[04:39] <bob2> this is all unrelated to whether there is a workign tree or not
[04:39] <kbulgrien> I committed more than 10k
[04:39] <bob2> please read what I said
[04:39] <bob2> that's the contents of top/mid/bot/.bzr
[04:39] <bob2> "the .bzr dir in the /branch in the repo/ just refers to the revision data in the repo itself"
[04:39] <bob2> "all the revision data is in the .bzr dir of the /repository/ (ie in the root)" -> du -sh top/mid/.bzr
[04:40] <kbulgrien> ok
[04:40] <kbulgrien> I see that
[04:41] <kbulgrien> I think
[04:42] <kbulgrien> yes. I see a repository folder that has packs and stuff.
[04:42] <bob2> bzr has branches (mutable pointers to a revision), repositories (big piles of revision data) and working trees (your checked out files, with enough info to be able to get pristine copies)
[04:42] <bob2> ^ important model information
[04:46] <kbulgrien> well, I can see what youre saying, but setting up a repository to me isn't nearly so clear as for cvs.
[04:46] <kbulgrien> I don't know that I've done what I wanted to do.
[04:47] <bob2> I'd start over
[04:47] <bob2> cd /srv/bzr ; bzr init-repo --no-trees something
[04:47] <bob2> mkdir something/projectname/branchname
[04:47] <bob2> cd !$
[04:47] <bob2> bzr init
[04:47] <kbulgrien> you do nothing at the projectname level?
[04:47] <bob2> cd ~/something
[04:48] <bob2> bzr checkout /srv/bzr/something/projectname/branchname projectname
[04:48] <bob2> cd projectname
[04:49] <bob2> bzr add .... ; bzr commit -m'first commit111'
[04:49] <bob2> correct
[04:49] <kbulgrien> ok
[04:50] <bob2> ^ so it's just a matter of: make a repo (one time thing), make a branch in it (per-branch thing), check it out somewhere and then use it
[04:54] <kbulgrien> ok, thanks for your patience.
[04:54] <bob2> progress?
[04:55] <kbulgrien> well, I'm doing something a bit unconventional, so the setup is a little more complex than that.
[04:55] <bob2> unconventional how?
[04:55] <kbulgrien> perms and stuff
[04:56] <kbulgrien> I'm trying to version control changes I make to an OS.
[04:57] <bob2> do you mean /etc
[04:57] <kbulgrien> yeah, but sparsely
[04:57] <kbulgrien> I only track what I mess with.
[04:58] <bob2> I'd not bother and instead use etckeeper
[04:59] <kbulgrien> I'll look it up.  Part of the thing is that I need/want to learn bzr so I can transition workk over.
[05:00] <kbulgrien> I'm not really using it to preserve etc, but to preserve the knowledge of what I have to tweak to do what I want to do.
[05:00] <kbulgrien> I'm not really backing up etc per se.
[05:02] <kbulgrien> ah, its a frontend to bzr...
[05:02] <kbulgrien> to do this in cvs I wrote my own front end
[05:02] <bob2> (and git and hg)
[05:02] <kbulgrien> ok
[05:02] <kbulgrien> well, then it bears looking at for sure.
[05:03] <kbulgrien> I already had to make a wrapper script for files I had to sudo to get access to.
[05:03] <kbulgrien> but it was way simpler than what I had to do for cvs
[05:13] <kbulgrien> cool
[05:13] <kbulgrien> okay, managed to even keep the history in the checkout
[05:13] <kbulgrien> and then I checked out somewhere else and got the goods.
[05:14] <kbulgrien> I was able to push the original checkout into the remade repository.
[05:15] <kbulgrien> now the data is under "top/.bzr""
[05:16] <kbulgrien> well even if I should have used etckeeper for this, it gave me a real world problem to solve that forced some learning.
[05:17] <kbulgrien> in the process, I found that 2.3.1 (mageia) had a bug with respect to no read perms in the checkout.
[07:35] <sbarcteam> hi.
[07:35] <sbarcteam> Let's assume I have a repository at rev. N
[07:37] <sbarcteam> I have a checkout branch (with bound=True)
[07:37] <sbarcteam> at location B at the same revision.
[07:37] <sbarcteam> (the 1st repo is at location A)
[07:38] <sbarcteam> now, I am doing changes in B, and do a normal commit (not the one with --local)
[07:38] <sbarcteam> and before that commmit I do some changes in A
[07:38] <sbarcteam> and do not commit them.
[07:39] <sbarcteam> so, I have 1) dirty working dir, 2) updates on the way already in the repo history
[07:39] <sbarcteam> I want to merge both the update and the dirty working dir.
[07:39] <sbarcteam> what is the right (bzr) way to do this ?
[07:40] <sbarcteam> I thought I could commit the dirty work dir, but bzr doesn't allow.
[07:42] <lifeless> you can commit --local, or you can just update.
[07:42] <lifeless> I would just update.
[07:43] <sbarcteam> #lifeless: so, If I commit --local and then
[07:43] <sbarcteam> there's importance to not
[07:43] <lifeless> or you could shelve the work, and then update and then unshelve
[07:43] <sbarcteam> shelving is not a good idea.
[07:44] <sbarcteam> It is a running django code.
[07:44] <sbarcteam> So I want to commit the work running, and merge it off-line, test it and only then to deploy the merged code.
[07:44] <sbarcteam> What would happen if I uncommit on the location B.
[07:44] <sbarcteam> then commit on A,
[07:45] <lifeless> you can use merge --uncommitted to grab the uncommitted work.
[07:45] <sbarcteam> then update on B
[07:45] <sbarcteam> and remerge.
[07:45] <lifeless> that work work too
[07:45] <sbarcteam> OK.
[07:46] <sbarcteam> So: on B (the checkout branch) uncommit the last merge, then on A: commit changes, then on B: update, and merge.
[07:46] <sbarcteam> right ?
[07:46] <sbarcteam> (and then I'd have to update A of course)
[07:49] <lifeless> yes
[10:00] <wilx> Can bzr sign-my-commits not use keychain/gpg-agent?
[12:27] <hno> Is it possible to "unmerge" a merge in such way that it do not get expunged from the originating branch if it later pulls/merges changes?
[12:28] <wilx> I do not understand the question entirely. However, it is possible to uncommit the last commit.
[14:16] <maxb> hno: Only if you can uncommit the merge commit, or arrange for the originating branch to (merge; revert .) the unmerging commit
[15:01] <hno> maxb, ok, not quite what I am looking for.
[15:02] <hno> It's very unlikely it's the last commit. May be many versions back, and development in the branch may have continued after merge.
[15:07] <hno> I guess what I am really looking for is kind of a large distributed bzr-loom with loose threading.


[05:53] -queuebot:#ubuntu-release- Unapproved: cockpit (disco-backports/universe) [194-1~ubuntu19.04.1 => 195-1~ubuntu19.04.1] (no packageset)
[06:06] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (disco-backports) [195-1~ubuntu19.04.1]
[06:07] -queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [194-1~ubuntu18.04.1 => 195-1~ubuntu18.04.1] (no packageset)
[06:07] -queuebot:#ubuntu-release- Unapproved: cockpit (cosmic-backports/universe) [194-1~ubuntu18.10.1 => 195-1~ubuntu18.10.1] (no packageset)
[06:07] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [195-1~ubuntu18.04.1]
[06:07] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (cosmic-backports) [195-1~ubuntu18.10.1]
[08:09] -queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (bionic-proposed) [2:1.19.6-1ubuntu4.3]
[08:41] -queuebot:#ubuntu-release- Unapproved: libreoffice (bionic-proposed/main) [1:6.0.7-0ubuntu<IP_ADDRESS> => 1:6.0.7-0ubuntu<IP_ADDRESS>] (kubuntu, ubuntu-desktop)
[08:43] -queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (bionic-proposed/main) [1:6.0.7-0ubuntu<IP_ADDRESS> => 1:6.0.7-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[08:48] <Laney> sil2100: (just flipped gnome-shell back to v-done now you've released yaru [thanks for that])
[08:49] <sil2100> Laney: ACK o/
[08:49]  * sil2100 looks at gnome-shell and mutter then
[08:49] <Laney> 😘
[08:52] -queuebot:#ubuntu-release- Unapproved: libreoffice (cosmic-proposed/main) [1:6.1.6-0ubuntu<IP_ADDRESS> => 1:6.1.6-0ubuntu<IP_ADDRESS>] (kubuntu, ubuntu-desktop)
[08:53] -queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (cosmic-proposed/main) [1:6.1.6-0ubuntu<IP_ADDRESS> => 1:6.1.6-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[10:18] -queuebot:#ubuntu-release- New source: indicator-notifications (eoan-proposed/primary) [0.3.3-0ubuntu1]
[10:19] -queuebot:#ubuntu-release- New: rejected indicator-notifications [source] (eoan-proposed) [0.3.3-0ubuntu1]
[10:19] -queuebot:#ubuntu-release- New: accepted indicator-notifications [source] (eoan-proposed) [0.3.3-0ubuntu1]
[10:21] -queuebot:#ubuntu-release- New binary: indicator-notifications [amd64] (eoan-proposed/none) [0.3.3-0ubuntu1] (no packageset)
[10:21] -queuebot:#ubuntu-release- New binary: indicator-notifications [ppc64el] (eoan-proposed/none) [0.3.3-0ubuntu1] (no packageset)
[10:21] -queuebot:#ubuntu-release- New binary: indicator-notifications [i386] (eoan-proposed/none) [0.3.3-0ubuntu1] (no packageset)
[10:21] -queuebot:#ubuntu-release- New binary: indicator-notifications [s390x] (eoan-proposed/none) [0.3.3-0ubuntu1] (no packageset)
[10:22] -queuebot:#ubuntu-release- New binary: indicator-notifications [arm64] (eoan-proposed/none) [0.3.3-0ubuntu1] (no packageset)
[10:22] -queuebot:#ubuntu-release- New binary: indicator-notifications [armhf] (eoan-proposed/none) [0.3.3-0ubuntu1] (no packageset)
[11:08] -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20190521-0ubuntu1~16.04.0 => 20190522-0ubuntu1~16.04.0] (ubuntu-cloud)
[11:08] -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (bionic-proposed/universe) [20190521-0ubuntu1~18.04.0 => 20190522-0ubuntu1~18.04.0] (ubuntu-cloud)
[11:08] -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (disco-proposed/main) [20190521-0ubuntu1~19.04.0 => 20190522-0ubuntu1~19.04.0] (core, ubuntu-cloud)
[11:09] -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (cosmic-proposed/main) [20190521-0ubuntu1~18.10.0 => 20190522-0ubuntu1~18.10.0] (ubuntu-cloud)
[11:12] <rbalint> sil2100, ^ please accept the gce-compute-image-packages when you have time
[11:27] -queuebot:#ubuntu-release- Unapproved: libgeo-coder-googlev3-perl (bionic-proposed/universe) [0.16-1 => 0.16-1ubuntu0.1] (no packageset)
[11:51] -queuebot:#ubuntu-release- Unapproved: qemu (disco-proposed/main) [1:3.1+dfsg-2ubuntu3.1 => 1:3.1+dfsg-2ubuntu3.2] (ubuntu-server, virt)
[11:52] -queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.14 => 1:2.11+dfsg-1ubuntu7.15] (ubuntu-server, virt)
[11:53] -queuebot:#ubuntu-release- Unapproved: qemu (cosmic-proposed/main) [1:2.12+dfsg-3ubuntu8.8 => 1:2.12+dfsg-3ubuntu8.9] (ubuntu-server, virt)
[11:55] -queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.26 => 1.3.1-1ubuntu10.27] (ubuntu-server, virt)
[11:57] -queuebot:#ubuntu-release- Unapproved: libvirt (bionic-proposed/main) [4.0.0-1ubuntu8.10 => 4.0.0-1ubuntu8.11] (ubuntu-server, virt)
[11:58] -queuebot:#ubuntu-release- Unapproved: libvirt (cosmic-proposed/main) [4.6.0-2ubuntu3.5 => 4.6.0-2ubuntu3.6] (ubuntu-server, virt)
[12:04] <cpaelzer> hi, things are mostly good, but I have to ask to cancel the just appeared libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.26 => 1.3.1-1ubuntu10.27]
[12:04] <cpaelzer> sil2100: rbasak: could one of you do that?
[12:04] <cpaelzer> the others are good but for just this particular one I need another round of test/dev/verify to be sure the upload does the right thing
[12:51] <cpaelzer> I'd want to repeat my request for someone to please cancel  libvirt xenial-proposed 1.3.1-1ubuntu10.27 from -unapproved
[12:56] <sil2100> cpaelzer: you mean, reject it?
[12:56] <sil2100> On it o/
[12:58] -queuebot:#ubuntu-release- Unapproved: rejected libvirt [source] (xenial-proposed) [1.3.1-1ubuntu10.27]
[13:00] -queuebot:#ubuntu-release- New: accepted indicator-notifications [amd64] (eoan-proposed) [0.3.3-0ubuntu1]
[13:00] -queuebot:#ubuntu-release- New: accepted indicator-notifications [armhf] (eoan-proposed) [0.3.3-0ubuntu1]
[13:00] -queuebot:#ubuntu-release- New: accepted indicator-notifications [ppc64el] (eoan-proposed) [0.3.3-0ubuntu1]
[13:00] -queuebot:#ubuntu-release- New: accepted indicator-notifications [arm64] (eoan-proposed) [0.3.3-0ubuntu1]
[13:00] -queuebot:#ubuntu-release- New: accepted indicator-notifications [s390x] (eoan-proposed) [0.3.3-0ubuntu1]
[13:01] -queuebot:#ubuntu-release- New: accepted indicator-notifications [i386] (eoan-proposed) [0.3.3-0ubuntu1]
[13:25] <cpaelzer> thank you sil2100
[14:06] <sil2100> huh, is qa.ubuntuwire.org down?
[14:30] <Laney> looks like it
[14:31] -queuebot:#ubuntu-release- Unapproved: apport (xenial-proposed/main) [2.20.1-0ubuntu2.18 => 2.20.1-0ubuntu2.19] (core)
[14:40] <mparillo> It finally came up for me. I wonder if the google problems are affecting many seemingly-unrelated sites
[14:54] <jamespage> afternoon
[14:54] <jamespage> pls can the neutron upload in bionic proposed be rejected; need to include a cherry pick for a functional regression
[15:24] <xnox> vorlon:  would you please look at https://bugs.launchpad.net/ubuntu/bionic/+source/libgeo-coder-googlev3-perl/+bug/1831443 ? is that an ok way to request hints? or review/accept the sru that effectively skips the offending online tests.
[15:28]  * Laney is making progress on a juju-2-ified autopkgtest-cloud
[15:32] -queuebot:#ubuntu-release- Unapproved: accepted glusterfs [source] (bionic-proposed) [3.13.2-1ubuntu1]
[15:35] <slashd> sil2100, thanks for glusterfs approval ^
[15:37] <sil2100> o/
[15:56] -queuebot:#ubuntu-release- Unapproved: accepted cups [source] (disco-proposed) [2.2.10-4ubuntu2]
[16:06] -queuebot:#ubuntu-release- Unapproved: accepted cups [source] (cosmic-proposed) [2.2.8-5ubuntu1.4]
[16:11] -queuebot:#ubuntu-release- Unapproved: accepted cups [source] (bionic-proposed) [2.2.7-1ubuntu2.6]
[16:12] -queuebot:#ubuntu-release- Unapproved: accepted cups [source] (xenial-proposed) [2.1.3-4ubuntu0.9]
[16:15] <ddstreet> sil2100 i see you retried the corosync failure in disco - it looks like that's failing because it can't find/download the corosync src in disco?  Could that be because there is only a corosync pkg in disco-release, and the corosync pkgs in disco-proposed were superceded and then the last one deleted when it was moved to eoan?
[16:22] -queuebot:#ubuntu-release- New: accepted ubuntustudio-look [amd64] (eoan-proposed) [0.61]
[16:27] <teward> sil2100: thanks for ^ that I'm sure Eickmeyer is very happy that was binNEW ACCEPTED
[16:27] <teward> :)
[16:27] <Eickmeyer> YEP!
[16:27] <Eickmeyer> \o/
[16:27] <teward> (assuming that was you sil2100 since I poked earlier xD)
[16:29] <sil2100> yw!
[16:31] <sil2100> ddstreet: I remember retrying it once because I was a bit surprised with the 'unknown' field, in the end I didn't find the time to track down the actual reason
[16:46] <ddstreet> sil2100 yeah adt couldn't find a src for it to download, so it didn't know what version it was trying to test
[16:47] <ddstreet> i'll try to repro locally, i think it's because there are corosync packages in disco-proposed that were superceded and the last disco-proposed version was deleted when it moved into eoan
[16:47] <ddstreet> but not really sure
[16:49] <sil2100> Eickmeyer: I'm reviewing your lsp-plugins upload right now - is there any NEW-package bug for that where I could leave feedback?
[16:49] <Eickmeyer> sil2100: Yes, hang on...
[16:49] <sil2100> ddstreet: hm, might be possible, didn't see that happening before though
[16:50] <Eickmeyer> sil2100: bug 1827288
[16:51] <teward> sil2100: correct me if i'm wrong but that should also be filed against bare Ubuntu too right?
[16:52] <sil2100> teward: probably, but I don't think that's a strict requirement
[16:52] <teward> just thought i'd ask :p
[16:52] <sil2100> What I do like is when the NEW package bug is attached to the changelog, if possible
[16:52] <sil2100> ;)
[16:53] <teward> :P
[16:53] <teward> true statement i see that's missing here
[16:59] <Eickmeyer> sil2100, teward: Just filed it against bare Ubuntu.
[17:01] <Eickmeyer> I can fix that changelog too, sil2100. Do we want to do a re-upload once I do?
[17:01]  * Eickmeyer can't upload that one
[17:04] <sil2100> Eickmeyer: I left some comments on the bug
[17:04] <Eickmeyer> Ok
[17:04] <sil2100> Eickmeyer: I need to EOD soon, but let's touch base tomorrow
[17:04] <Eickmeyer> sil2100: Works for me.
[17:05] <sil2100> Eickmeyer: take a look at those and respond on the bug, and then I can re-upload + approve it tomorrow if needed ;)
[17:05] <Eickmeyer> sil2100: Sounds good. :)
[17:05] <sil2100> Eickmeyer: ...but in case I forget myself, please do poke me about it
[17:05] <sil2100> o/
[17:06] <Eickmeyer> sil2100: Will do. Have a good one!
[17:06] <teward> sil2100: thanks for looking at them anyways
[17:06] <teward> enjoy your night :)
[17:06] <sil2100> Thanks!
[17:12] -queuebot:#ubuntu-release- New binary: swaybg [amd64] (eoan-proposed/none) [1.0-1] (no packageset)
[17:12] -queuebot:#ubuntu-release- New binary: swaybg [i386] (eoan-proposed/none) [1.0-1] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: swaybg [ppc64el] (eoan-proposed/none) [1.0-1] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: swaybg [s390x] (eoan-proposed/none) [1.0-1] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: swaybg [arm64] (eoan-proposed/none) [1.0-1] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: swaybg [armhf] (eoan-proposed/none) [1.0-1] (no packageset)
[17:30] <rbalint> infinity, please accept the gce-compute-image-packages srus if you have time today
[17:32] <vorlon> xnox: I'd still really prefer MPs instead of bugs, but yeah that looks fine, I'll land the hint (for bionic only; http://autopkgtest.ubuntu.com/packages/libg/libgeo-coder-googlev3-perl shows no tests for xenial).  also do you know about retry-autopkgtest-regressions --no-proposed?
[17:32] <infinity> rbalint: I'll have a look later today.
[17:36] -queuebot:#ubuntu-release- Unapproved: rejected libgeo-coder-googlev3-perl [source] (bionic-proposed) [0.16-1ubuntu0.1]
[17:36] <vorlon> xnox: please also transfer https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386/comments/52 into the sru bug description (i.e. fix up 'regression potential')
[19:08] <Eickmeyer> vorlon: Regarding lsp-plugins, the upstream developer made a few fixes. Do you think this would fix the test issue? https://github.com/sadko4u/lsp-plugins/issues/50
[19:08] <gitbot> sadko4u issue 50 in lsp-plugins "Tests fail on debian/ubuntu build " [Hotfix, Feature Request, Open]
[19:16] <vorlon> Eickmeyer: try it and see? :)
[19:17] <Eickmeyer> vorlon: Ok
[19:19] <ddstreet> xnox looks like you got corosync-qdevice version 3 into disco-release, but it seems corosync itself version 3 didn't make it into disco-release...you or vorlon want to comment on lp #1831492, as i'm not sure how to fix that mismatch
[19:20] <ddstreet> besides the obvious 'release corosync version 3 to match, into disco-updates'
[19:51] -queuebot:#ubuntu-release- Unapproved: dahdi-linux (bionic-proposed/universe) [1:2.11.1~dfsg-1ubuntu4 => 1:2.11.1~dfsg-1ubuntu4.1] (no packageset)
[19:56] -queuebot:#ubuntu-release- Unapproved: sysdig (bionic-proposed/universe) [0.19.1-1ubuntu1 => 0.19.1-1ubuntu1.1] (no packageset)
[20:18] <Eickmeyer> vorlon: We have a successful build including tests. \o/
[20:24] <vorlon> ddstreet: so I appreciate that corosync is not in particularly good shape in disco (cf LP: #1826045), but I'm not sure why we should care about this for a non-LTS release; if what you're after is getting systemd through, we should demonstrate that this test is broken in the release pocket, update the hints to reflect that, and move on
[20:25] <vorlon> Eickmeyer: the "build twice, test this one, ship that one" you commented in the bug, or something better?
[20:26] <Eickmeyer> vorlon: no, the upstream developer fixed the test suite, I added patches. Builds with test, no errors.
[20:26] <vorlon> ah nice
[20:29] <Eickmeyer> vorlon: I removed your comments (and the override_dh_auto_test:) line from debian/rules since it's no longer necessary.
[20:44] -queuebot:#ubuntu-release- New binary: u-boot [arm64] (eoan-proposed/main) [2019.04+dfsg-2ubuntu1] (core)
[20:55] <ddstreet> vorlon we shouldn't care about corosync, pacemaker, pcs in disco?  i mean this isn't just autopkgtest failures, this is actual problems with the packages...if the opinion is we don't care about the packages in disco, then why not just upgrade both pacemaker and corosync to the next major version, which will fix both problems?
[21:01] <vorlon> ddstreet: because that's more work than doing nothing
[21:01] <vorlon> so why is it worth doing more work?
[21:02] <ddstreet> er, because it's broken?
[21:02] <vorlon> and nothing in that autopkgtest log reads to me as saying anything about the state of the corosync package
[21:02] <ddstreet> well i explained it in the lp bug
[21:03] <ddstreet> corosync-qdevice was split out from corosync at version 3
[21:03] <ddstreet> so it will now be actually literally impossible to release any more version <3 corosync builds for disco
[21:03] <vorlon> ok but what does that have to do with 'apt-source corosync' apparently failing in the autopkgtest log?
[21:04] <ddstreet> did you read my bug?  it explains it in detail
[21:04] <vorlon> your bug does not explain the answer to the question I just asked
[21:04] <ddstreet> about what is has to do with 'apt-source corosync' in the adt log?
[21:04] <vorlon> "because the testbed can't find the corosync source" the corosync source hasn't gone anywhere
[21:05] <ddstreet> there is no corosync source for the corosync-qdevice version
[21:05] <ddstreet> vorlon if you read the 'other info' section i think it explains it
[21:05] <ddstreet> if you still aren't clear, please let me know
[21:06] <vorlon> ok
[21:07] <vorlon> so, that still doesn't say to me that the corosync package is broken
[21:08] <vorlon> it says that the package can't be SRUed without also dropping those binaries from the source
[21:08] <ddstreet> well, anyone installing corosync-qdevice and/or corosync-qnetd will get the wrong (version 3) binaryies
[21:08] <ddstreet> i don't know if you consider that broken or not, but it's certainly not right in my book
[21:09] <ddstreet> anyway, i'm about eod, if you have more thoughts on it or want to just hint britney and wontfix the bug, feel free
[21:10] <vorlon> it also looks to me like runner/autopkgtest is not buggy in the way you describe, but instead does a bidirectional check so it is only comparing versions of binary packages that list this source package as their source
[21:11] <ddstreet> vorlon it's not buggy, i don't say that adt is buggy anywhere
[21:11] <ddstreet> it's doing exactly what it should be
[21:11] <ddstreet> the problem is corosync-qdevice at v3 along with corosync at v2, both existing together
[21:12] <ddstreet> anywho, add q to the bug if you still don't understand - i'm eod
[21:12] <vorlon> if it's doing what you say, that's certainly not what it's supposed to be doing
[21:13] <ddstreet> vorlon i think you still don't understand what the problem is, because adt is doing things right
[21:13] -queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [19.0.2-1ubuntu1~18.04.1 => 19.0.2-1ubuntu1.1~18.04.1] (core, xorg)
[21:13] -queuebot:#ubuntu-release- Unapproved: mesa (disco-proposed/main) [19.0.2-1ubuntu1 => 19.0.2-1ubuntu1.1] (core, xorg)
[21:14] <vorlon> ddstreet: there's nothing right about mapping source to binaries to source and coming up with a source package version number for a different package
[21:14] <vorlon> and there is code in here to /guard against that case/
[21:15] <ddstreet> well, it found this problem, didn't it ;-)
[21:40] <vorlon> ddstreet: runner/autopkgtest, line 469, is intended to filter out binaries that are listed in this source package but whose current source is not this source package.  It fails because it's using \b to bound the package name and that matches the boundary between c and - in 'corosync-qdevice'.
[21:44] <vorlon> ddstreet: correction, it doesn't fail because the bit above that already filters it out (show=$(apt-cache show $pkg=$pkg_candidate | grep "^Source:" || true) <-- empty because src_pkg == bin_pkg and there's no Source: line)
[21:45] <vorlon> ddstreet: but then it hits corosync-qnetd, which does fail in the manner described
[23:48] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (disco-proposed) [2.578.5]
[23:49] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (cosmic-proposed) [2.542.5]
[23:50] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.26]


[06:25] <Unit193> > xfce4-settings
[06:26] <flocculant> > xfce4-desktop
[06:27] <Unit193> Making a note, we're behind with that one and it's a bugfix release.
[06:27] <flocculant> that makes a bit more sense :p
[06:27] <Unit193> (I think Blue said it's good to grab, and I keep forgetting.)
[06:29] <Unit193> Everything else is klar.
[06:29] <knome> alles klar, der komissar!


[01:22] <andrew> InHisName: no, I was still up at that hour
[04:07] <InHisName> This must be your morning time, andrew
[04:40] <waltman> InHisName: The day is a different length on andrew's homeworld.
[04:41] <InHisName> Or more like he is (-12) time zone
[04:42] <waltman> New Year's Eve can do that to a person...
[09:37] <andrew> Why are you only talking about me when I'm away?
[09:37] <andrew> Meh.
[09:37] <andrew> Also,
[09:37] <andrew> Morning!
[09:38] <andrew> (And no, I didn't just get up, I'm slowly heading to bed.
[09:38] <andrew> Yes, even at this hour.)
[10:34] <JonathanD> Morning.
[10:37] <rmg51> morning JonathanD
[10:44] <JonathanD> hey rmg51
[12:29] <InHisName> G'nite andrew
[12:29] <InHisName> good morning JonathanD and Randy and anyone else awake
[13:02] <teddy-dbear> morning
[13:23] <waltman> morning
[13:49] <ChinnoDog> sup peeeeps
[16:05] <morecheese> happy new year all!
[16:17] <Sadin> you too!
[16:21] <ChinnoDog> hooray for 2012
[16:22] <Sadin> ChinnoDog
[16:22] <Sadin> just moved from CentOS  to Debian 6 on my VPS how would i search for packages using apt-get
[16:28] <Joe_CoT> Sadin, use apt-cache search
[16:29] <Sadin> okay thanks!
[16:29] <Joe_CoT> or just look through them on packages.debian.org
[16:29] <Sadin> alrighty
[17:09] <ChinnoDog> I just discovered I am working on a company holiday
[17:09]  * ChinnoDog headdesk
[20:26] <waltman> ChinnoDog: it's a national holiday today.
[20:27] <andrew> good morning
[20:57] <teddy-dbear> the bot is awake! ;-)
[20:58] <teddy-dbear> just in time for me to leave :-D


[00:05] <Bashing-om> xu-help78w: ^^Workie :D ... "open (13: Permission denied)" means that "sudo" is required. python-tk is available.
[00:10] <xu-help78w> What a simple error ... Embarrassing !! ... the web page I was looking at assumed I knew to do that !!
[00:10] <xu-help78w> THANKS so much !!!!
[00:12] <Bashing-om> xu-help78w: Hey - we all have those moments :P We watch the backside for ya :F
[02:07] <xu-irc58w> Anybody, know when is LTS 18.04 going to be able to be upgraded using do-release-upgrade? Is there another method I should be using?
[02:12] <tomreyn> search the web for    ubuntu 20.04 release announcement
[02:12] <tomreyn> that's assuming you're meaning to upgrade to that
[02:13] <Bashing-om> xu-irc58w: ^^ Too: The upgrade path opens with the .1 release ( August) . There is the -d switch however to upgrade now.
[02:15] <xu-irc58w> Thanks, I I remember checking in with you guys back in June and I thought July was mentioned. Thanks for the update. I'm muking with -d; something is broken, but I will do more triage before bugging you guys.
[02:16] <Bashing-om> xu-irc58w: The .1 release has been pushed to August.
[02:18] <xu-irc58w> That's fair, this is free software. I appreciate the work you guys are doing!
[02:18] <Bashing-om> xu-irc58w: Source: https://lists.ubuntu.com/archives/ubuntu-release/2020-June/004980.html .
[03:35] <xu-irc58w> Running "do-release-upgrade --allow-third-party --mode=desktop -d" bails out...
[03:36] <xu-irc58w> Looking in /var/log/dist-upgrade/main.log I see a line "ERROR Dist-upgrade failed: 'E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.'"
[03:40] <xu-irc58w> Looking in "/var/log/dist-upgrade/apt.log" I see a bunch of messages about holds but they're for very fundamental packages like python2.
[03:41] <tomreyn> purge packages from all ppas, then disable all ppa configurations, then try again
[03:42] <tomreyn> if it still reports the same you can install and run apt-forktracer to identiy packages you ay not want to keep installed.
[03:47] <xu-irc58w> I'm pretty darned sure I have no PPAs set up and consequently no packages installed from them ("grep -r -i ppa /etc/apt/" has no results)
[03:47] <xu-irc58w> And I also get no lines printed from running apt-forktracer
[03:50] <xu-irc58w> Also, "apt-mark showhold" brings back no held packages
[03:50] <xu-irc58w> Any ideas on alternative lines of inquiry into do-release-upgrade's behavior in this situation?
[04:18] <sekhog> Hello!
[14:48] <alexeightsix> i installed dockbarx, how do i change what monitor its displayed on?
[15:49] <xubuntu21i> hi, i'm just installing xubuntu 20.04. did the installer install the correct nvidia drivers? or do i have to do this using the gui where i choose the driver the system uses?
[23:21] <xserverhelp> hi, how would i stop the xserver in xubuntu 20.04? i need to stop it to install nvidia driver
[23:26] <well_laid_lawn> !nvidia
[23:45] <n-iCe> hi
[23:53] <n-iCe> hikdnj


[10:45] <mpt> kemmko, a three-column window I designed a few years ago: https://bug619866.bugzilla-attachments.gnome.org/attachment.cgi?id=183091
[10:55] <kemmko> and it has a bottom edge!
[10:55] <kemmko> mpt:  see above, and thanks
[10:56] <kemmko> mpt:  I am not that worried about design but more about the behaviour of each panel especially if the app goes from phone/tablet to desktop environment
[10:57] <mpt> kemmko, I think we’ve discussed this before … Generally panes are replaced by hierarchy. For example Mail is three-pane on a Mac, two-pane on an iPad, one-pane on an iPhone.
[10:58] <mpt> Replaced by hierarchy as the screen gets smaller, I mean.
[10:59] <kemmko> mpt:  here is the thing, in many cases we don not need as three panel layout
[10:59] <kemmko> mpt:  at least for our convergent apps, it works just fine with the 2 panel for tablet/desktop
[11:00] <mpt> kemmko, well, sure, you don’t *need* it, you could just use hierarchy regardless of screen size. But there’s a reason mail clients usually aren’t one- or even two-pane on a desktop: it’s annoying.
[11:01] <mpt> Specifically it slows navigation and scanning of adjacent/new items.
[11:05] <kemmko> mpt:  actually many are in a two panel mode
[11:07] <mpt> kemmko, especially back in the 1990s when the standard display size was 800*600, two-pane was more common or a more prominent option. <http://www-archive.mozilla.org/mailnews/specs/threepane/images/Mail2.gif>
[11:07] <mpt> (You can still configure Thunderbird to do that now, it just takes more work.)
[11:08] <kemmko> mpt:  this panels are staked one on top of each other, I am talking about the ones next to each other
[11:20] <mpt> kemmko, ok, so when you said two panel mode, you meant three panes in two columns? Yes, that’s still common (I use it), but three-column is increasingly common because average PC screen size+resolution is still increasing. If the screen is large enough for three columns, doing that lets you see more of a message, therefore reduces the probability that you need to scroll to read a message.
[11:23] <kemmko> mpt:  I never talked about "panes" always about panels and those are columns
[11:23] <mpt> kemmko, sorry, I’m not familiar with the difference between a pane and a panel :-)
[11:24] <kemmko> mpt:  np
[11:24] <kemmko> mpt:  at the moment I am looking into default behaviour for two panels/columns for desktop…
[11:25] <kemmko> mpt:  a 3 panel/column one will come be defined at a later point, we didn't have the time to look into that so far
[11:26] <mpt> ok


[00:39] <TinyNatty> Hi. I'm having some trouble with upstart. I'm no longer able to access my services.
[00:53] <TinyNatty> Is there a way to verify that I'm upstart is running and not something else?
[00:57] <JanC> run 'initctl version' maybe?
[01:06] <TinyNatty> Thanks. I'm getting the error: initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
[01:06] <TinyNatty> That's the same error I get when I try to use the service command.
[01:56] <JanC> which probably means upstart is not running...
[01:57] <Natty> Yeah, not sure how that happened. Turned out a reboot fixed it.