[00:45] <nacc> cpaelzer: hrm, i was able to backport the patches so kopanocore buillds, but now it's faililg dep8, willl debug before you need to review
[02:46] <zzz> hi. im trying to figure out why df and lsblk output is incompatible for an internal drive. fs shows 472M Size, however lsblk correctly shows a 15G partition
[02:46] <zzz> *df
[02:48] <TJ-> zzz: partitions and file-systems can be different sizes
[02:56] <zzz> TJ- how can i make the file system 15G? the drive is empty
[02:59] <sarnold> are you *confident* it's empty? this feels weird
[03:00] <yer> any sendmail gurus in here
[03:01] <TJ-> zzz: if the partition contains the file-system it suggests you've enlarged the partition at some point
[03:01] <zzz> no. old eee pc with 2 internal ssd: 4G + 15G
[03:01] <zzz> clean ubuntu server install
[03:02] <TJ-> zzz: best to show us: "pastebinit <( lsblk; df )"
[03:02] <zzz> http://paste.ubuntu.com/26503665/
[03:02] <zzz> sdb1 is the part in question
[03:03] <zzz> https://paste.ubuntu.com/26503670/ for humans
[03:05] <zzz> im not experienced with this stuff
[03:06] <sarnold> "timemachine" .. is this an HFS+ or similar filesystem? do you care about it's contents at all?
[03:09] <zzz> no, it's ext4. i just mounted it for macos' time machine but it uses a sparse bundle
[03:09] <zzz> dont care about contents at all
[03:11] <sarnold> alright; I *think* you can probably just umount /media/timemachine ; mke2fs -t ext4 -j /dev/sdb1
[03:11] <sarnold> I haven't driven mke2fs by hand in ages..
[03:13] <TJ-> zzz: if it's ext you can just do "sudo resize2fs /dev/sdb1" without un-mounting it
[03:14] <TJ-> ext can do online resize for extending, but not shrinking
[03:14] <zzz> thanks guys. i'm reading up on it jut to feel safe. any idea of what couldve caused smth like this?
[03:14] <sarnold> I thought about that, but didn't want to shortchange the filesystem on inodes.
[03:15] <sarnold> zzz: the easiest way I could think of to create this would be to dd a filesystem from one tiny partition to this partition.
[03:27] <zzz> ok it seems to have solved it
[03:28] <zzz> how can i ever repay you
[03:28] <sarnold> pass it along :)
[03:28] <zzz> you know i will. thank you
[03:29] <sarnold> you're welcome ;) have fun
[04:40] <yer> any network guys in here?
[04:41] <yer> got a TL-R600VPN router doin some weird shit
[04:43] <yer> keeps setting a IP adress to be a DMZ host, and its an address that we have never used .... port forwardings appearing by them selfs
[04:43] <yer> selves
[04:43] <yer> scary
[06:41] <cpaelzer> nacc: all the qemu train blocks on the new queue with src:ipxe-qemu-256k-compat
[06:41] <cpaelzer> nacc: I'm on it in the sense that I ping infinity on a daily base who said he is gonna take a look
[06:45] <cpaelzer> waiting with kopano until you set status to ready-to-review then
[07:01] <lordievader> Good morning
[08:23] <jamespage> coreycb: the wireshark pkg-config in xenial is foobar - so I'm going to patch out the wireshark support from libvirt for the xenial/queens backport
[08:23] <jamespage> we don't need that for openstack...
[08:37] <davidjmemmett_> Morning all
[08:38] <davidjmemmett_> Has anyone else experienced any freezes using artful on EC2 (using c5 instances)? I can sometimes boot a machine, sometimes it hangs forever, sometimes it freezes and dies after a few minutes
[09:52] <rbasak> davidjmemmett_: yes, on this channel
[09:53] <rbasak> davidjmemmett_: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1746806
[09:53] <ubottu> Launchpad bug 1746806 in sssd (Ubuntu) "sssd appears to crash AWS c5 and m5 instances, cause 100% CPU" [Undecided,Confirmed]
[10:00] <davidjmemmett_> Yup, that’s the one, cheers rbasak
[10:02] <rbasak> davidjmemmett_: please mark yourself as affected
[10:02] <davidjmemmett_> Will do
[10:04] <rbasak> davidjmemmett_: is it sssd related for you as well?
[10:05] <davidjmemmett_> Yes, using it for LDAP with
[10:05] <davidjmemmett_> ^auth
[10:05] <rbasak> Please could you comment on the bug? The data point is useful I think.
[10:05] <rbasak> Since it could be a kernel regression or a latent sssd bug merely exposed by a newer kernel
[10:06] <rbasak> If everyone affected says it's only with sssd, then that points to an sssd bug. OTOH if we get reports from users not using sssd, then more likely a kernel bug.
[10:48] <jamespage> coreycb: just tripped on that missing deb dbgsym thing with libvirt in queens-staging
[11:38] <coreycb> jamespage: afaik it's not due to debhelper or dh-autoreconf. It recreated with artful versions of those.
[11:40] <coreycb> jamespage: also turned on dbgsyms in a xenial-pike ppa and had no problem building the queens python-coverage
[11:41] <ahasenack> rbasak: hi, thanks for the zstd feedback, I'm looking into it now
[11:41] <ahasenack> rbasak: a question
[11:41] <ahasenack> rbasak: "Rather than "dist-upgrade" on Xenial, could you please check that the new zstd is pulled in on a plain "apt-get upgrade" and via the update manager? "
[11:41] <rbasak> o/
[11:41] <jamespage> coreycb: hmm so its a mix of newer debhelpers + ppa with debug symbols enabled?
[11:41] <ahasenack> rbasak: when you say update-manager, you mean the desktop UI thingy that prompts for upgrades?
[11:41] <rbasak> ahasenack: right
[11:41] <ahasenack> ok
[11:41] <rbasak> ahasenack: because that's the most common use case, right?
[11:42] <ahasenack> I suppose :)
[11:42] <rbasak> I ask because I know dist-upgrade can be more clever. But we need the zstd update to work even when users don't use dist-upgrade for the entire SRU to be useful, AIUI.
[11:43] <rbasak> And I don't know off the top of my head exactly what update-manager does.
[11:43] <ahasenack> I'll start with upgrade
[11:43] <ahasenack> thanks
[11:43] <ahasenack> I rarely use upgrade nowadays, indeed
[11:43] <rbasak> If someone says "it definitely does the equivalent of 'apt-get upgrade' and 'apt-get upgrade' works" and I believe this person then no need to test :)
[11:43] <ahasenack> I'm happy with dist-upgrade's behavior of stopping and showing what NEW packages it would install
[11:44] <ahasenack> nah, the test is easy
[11:44] <ahasenack> I don't mind it
[11:44] <ahasenack> I just don't know what to do if it fails :)
[11:44] <rbasak> As long as you understand why I'm asking :)
[11:44] <ahasenack> s/don't/won't/
[11:44] <rbasak> Yeah I don't know either
[11:45] <ahasenack> I remember in the past apt upgrade pulling in new packages. It probably depends (hah)
[11:47] <coreycb> jamespage: seems so, maybe it's one of the other debhelper deps that was backported
[11:47] <jamespage> coreycb: might be - just trying something else
[11:48] <jamespage> alot of the behaviour in a PPA is PPA specific so I'm wondering whether this is generally broken
[11:48] <jamespage> for later debhelper revs in PPA's with debug symbols enabled...
[12:32] <ahasenack> rbasak: apt upgrade and desktop GUI upgrade tests passed, looking at your other points now
[12:32] <ahasenack> (I updated the bug)
[13:15] <jamespage> coreycb: its a dpkg/debhelper incompat
[13:15] <jamespage> debhelper is doing something new with regards to ddeb's
[13:15] <jamespage> dpkg carries:
[13:15] <jamespage>     - dpkg-gencontrol: Fix Package-Type override handling for ddeb support.
[13:16] <coreycb> jamespage: aha, that looks like it
[13:17] <coreycb> jamespage: do you wan to attempt backporting dpkg?
[13:17] <coreycb> want
[13:17] <coreycb> jamespage: reviewing pxc 5.7 now btw
[13:23] <jamespage> coreycb: hmm
[13:23] <jamespage> maybe
[13:25] <ahasenack> rbasak: replied in the MP about --devunversioned, and you are right about the missing dh_auto_build bit in bionic (also replied in the MP). Will fix the later and push
[13:35] <jamespage> coreycb: debhelper @ 10.2.5ubuntu2 is where the behavioural change for ddebs happened - requiring a new dpkg for compat
[13:37] <coreycb> jamespage: ok. just noticed we have 10.2.2 in pike.
[13:37] <jamespage> coreycb: not entirely convinced I want dpkg in the UCA
[13:38] <jamespage> coreycb: yeah that does the old style ddeb generation
[13:38] <coreycb> jamespage: yeah
[13:38] <jamespage> kinda two choice here - either we do something with dpkg or we switch UCA debhelper back to the old style
[13:39] <coreycb> jamespage: old style seems sensible
[13:47] <ahasenack> rbasak: pushed, and the ppa is building a new bionic test upload with that as well (https://launchpad.net/~ahasenack/+archive/ubuntu/zstd-backport-1717040/+packages)
[13:47] <ahasenack> it takes a while because the tests are run at build time, and they are a bit long
[13:49] <jamespage> coreycb: ok I think I figured out where to tweak that
[13:55] <rbasak> ahasenack: ack
[14:10] <jamespage> coreycb: https://launchpad.net/~james-page/+archive/ubuntu/queens/+build/14300947 rebuilding with debhelper patches
[14:11] <jamespage> coreycb: I forgot how much hassle the final UCA pocket for an Ubuntu LTS is
[14:11] <jamespage> 2 years of deltas...
[14:12] <coreycb> jamespage: sure is. we can reset to just backporting to bionic next release.
[14:12] <coreycb> jamespage: hopefully ppa builds are faster today. they were painfully slow yesterday.
[14:13] <jamespage> coreycb: yup
[14:13] <jamespage> nice easy peasy
[14:13] <jamespage> coreycb: ca-patches per pocket - http://paste.ubuntu.com/26505879/
[14:13] <coreycb> jamespage: i see a trend :)
[14:46] <jamespage> coreycb: bah so close with debhelper - now generating .deb for dbgsym, but ddeb into the control file...
[14:46]  * jamespage sighs
[14:49] <jamespage> coreycb: ok take 10
[14:49] <coreycb> jamespage: lol
[14:49] <jamespage> I think I see what needs to happen
[14:51] <jamespage> coreycb: maybe just run those pxc maintainer scripts through https://github.com/mvdan/sh
[14:52] <coreycb> jamespage: oh nice
[14:52] <coreycb> jamespage: will do
[14:54] <jamespage> coreycb: I did
[14:54] <jamespage> pushed as new commit on my branch
[14:54] <coreycb> jamespage: ah thx
[16:12] <rbasak> ahasenack: could you edit the bug description according to https://bugs.launchpad.net/ubuntu/+source/libzstd/+bug/1717040/comments/44 please?
[16:12] <ubottu> Launchpad bug 1717040 in libzstd (Ubuntu Bionic) "Please backport libzstd 1.3.1+dfsg-1 (universe) from artful" [Undecided,In progress]
[16:12] <ahasenack> rbasak: sure
[16:43] <ejat> <ejat> hi ..
[16:43] <ejat> <ejat> i used openstack-telemetry charms .. 2 services got problem (mongodb & neutron-gateway)  .. juju status output : http://paste.ubuntu.com/26506527/
[16:43] <ejat> <ejat> mongodb log output: https://paste.ubuntu.com/26506520/
[16:43] <ejat> <ejat> neutron-gateway: https://paste.ubuntu.com/26506512/
[17:39] <rbasak> nacc: on your corosync question. Which particular path are you trying to tackle?
[17:45] <renatosilva> I occasionally get an email with title "test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )", why?
[17:46] <renatosilva> content says: "/etc/cron.daily/logrotate: Warning: apache2.service changed on disk. Run 'systemctl daemon-reload' to reload units."
[17:47] <renatosilva> I want to understand how exactly this cron email has been activated since I can't remember doing this manually
[17:47] <dpb1> usually because apache2 has been updated, and it's asking you to reload the daemon
[17:48] <renatosilva> dpb1: that's what the message says, yes, meaning the auto-update I have configured is hopefully working but... I would expect the system to reload apache after _auto-updating on a server_
[17:49] <renatosilva> how was cron allowed to send me email? is that a default configuration?
[17:49] <renatosilva> why the system bothers me with this useless email about apache? why not just reload it?
[17:56] <dpb1> how often do you get it?
[17:57] <dpb1> not sure about cron "allowed" to send you an email.  that depends on how you have things configured.  I think by default it sends to the root user on the system, as a way of notifying you of what happened.  it's standard cron behavior
[17:57] <nacc> rbasak: i'm thinking that if pacemaer upgrades before corosynnc finishes (runs its postinst), we don't need the flag
[17:57] <nacc> rbasak: because a systemd unit that is partof the other will follow the state transitions
[17:58] <nacc> rbasak: in which case, we don't nened the /run flag for upgraders, as it will nnaturally be enforced (unless they modified the units manually, in which case it's a separate case)
[18:04] <rbasak> I wonder if a versioned Conflicts would suffice. But we don't usually use those, so I'd like someone to confirm that we actually want that and it won't have any inadvertent side-effects.
[18:05] <rbasak> Have the new corosync Conflict on older pacemaker (or vice versa).
[18:05] <rbasak> Then they can't even both be unpacked at once.
[18:05] <rbasak> Hopefully apt will resolve that to upgrade the pacemaker first.
[18:05] <rbasak> But is this really needed?
[18:06] <rbasak> I think we understand the Breaks path well, we have to use this path for older releases anyway, and it's only temporary.
[18:06] <rbasak> So while I think you're probably right, does doing it your way add additional risk and complexity?
[18:07] <rbasak> One issue with Conflicts is that it can be quite constraining in terms of possible upgrade paths, which is why AIUI it's generally frowned upon in favour of Breaks where possible.
[18:21] <nacc> rbasak: ok -- yeah, it was more about minimizing the delta
[18:21] <renatosilva> dpb1: ok, first I wanted to know how cron came up to doing it, that explains it then, it's, default config
[18:21] <nacc> rbasak: i agree with what you are saying, in principle (also for my own edification)
[18:22] <dpb1> renatosilva: yes, cron will email the result of any script that fails (returns a non-zero code) or has any output of any kind.  All other cases, it stays silent
[18:22] <renatosilva> dpb1: but it's a useless notification in this case, I wonder why isn't apache just reloaded instead
[18:22] <dpb1> renatosilva: how often do you get it
[18:24] <dpb1> renatosilva: a quick google search turns up that it could be simply a buggy update with systemd
[18:25] <renatosilva> dpb1: randomly really, enough to get me annoyed.... in the past I would get like a few a month, not sure... then it was quite some time since last occurrence, and today it came back... I believe it's as often as apache package gets auto-updated, and I had some time without it because I think auto-updates were just not working
[18:25] <dpb1> renatosilva: could it be tied to reboots?
[18:26] <renatosilva> unexpected reboots then, but I don't think so
[18:26] <dpb1> renatosilva: anyway, please file a bug against apache2 in ubuntu with this behavior
[18:26] <dpb1> https://bugs.launchpad.net/ubuntu/+source/apache2/+filebug
[18:27] <dpb1> you can even use `ubuntu-bug apache2` from the command line
[21:00] <coreycb> wolsen: jamespage: stable point releases are underway for newton, ocata, and pike. bug 1747067, bug 1747066, and bug 1747065.
[21:00] <ubottu> bug 1747067 in Ubuntu Cloud Archive newton "[SRU] newton stable releases" [Undecided,New] https://launchpad.net/bugs/1747067
[21:00] <ubottu> bug 1747066 in Ubuntu Cloud Archive ocata "[SRU] ocata stable releases" [Undecided,New] https://launchpad.net/bugs/1747066
[21:00] <ubottu> bug 1747065 in nova (Ubuntu Artful) " [SRU] pike stable releases" [Undecided,New] https://launchpad.net/bugs/1747065
[21:00] <wolsen> awesome coreycb - thanks much!
[21:00] <coreycb> wolsen: np!
=== zzz is now known as dskljfhsalkdfjha
=== dskljfhsalkdfjha is now known as dskljfhsalkdfjhx
=== dskljfhsalkdfjhx is now known as gfskljfhsalkdfjh
=== gfskljfhsalkdfjh is now known as z0_
=== z0_ is now known as z0
=== z0 is now known as zzz
[22:44] <nacc> powersj: how hard would it be to change our CI to use git-ubuntu.self-test from the built snap starting at https://code.launchpad.net/~nacc/usd-importer/+git/usd-importer/+merge/337104
[22:44] <nacc> or even as its own custom pipeline for now?
[22:45] <powersj> options 1) change nothing till you land 2) I could update the job manually and run it against that branch to get a result or 3) update the job now use that going forward
[22:45] <nacc> powersj: well, the problem is CI will fail with it
[22:45] <nacc> powersj: for 1)
[22:45] <powersj> a 2nd pipeline is, interesting, but would be rather confusing with multiple votes right?
[22:45] <nacc> yeah, i expect to see the old fail and the new succeed, if that makes sense
[22:45] <nacc> we would then decommision the old once this lands
[22:48] <nacc> powersj: we can also talk about it on monday with rbasak
[22:48] <nacc> dpb1: --^ just an fyi the above is delaying our phasing (not anyone's fault, just necessary changes)
[22:48] <powersj> how many open branches are there? is it a big concern to break older reviews?
[22:48] <nacc> I think I'm the only one trying to land anything right now :)
[22:49] <nacc> we can wait to see what rbasak thinks
[22:49] <powersj> then on Monday I would propose, let's get the CI happy with your branch and use that going forward
[22:49] <nacc> yeah i thin kthat's the right approach too
[22:56] <rbasak> nacc, powersj: I'm happy either way
[22:56] <nacc> rbasak: ok, i think the move to snap the scripts was easier than i expected
[22:56] <rbasak> As long as one of the two mechanisms is capable of passing when you're don e:)
[22:56] <nacc> rbasak: so we can do all the self-test for CI i the snap
[22:56] <nacc> lint + pytest of the gitubuntu/ dir
[22:56] <powersj> rbasak: go enjoy your friday night
[22:56] <powersj> :P
[22:57] <nacc> heh
[23:02] <rbasak> We've been enjoying online furniture shopping :)
[23:04] <dpb1> nacc: OK, let's chat about it on monday with powersj if you have some ideas
[23:10] <powersj> rbasak: would using the built snap's self-test imply that we no longer need the pipeline given we would get rid of the tox and pytest steps?
[23:11] <powersj> err that was meant for nacc ^
[23:11] <powersj> hopefully he continues his exhilarating furniture shopping ;)