[07:19] <lordievader> Good morning
[09:41] <coreycb> jamespage: 5 smoke failures on bionic-stein-updates. trying proposed now.
[09:51] <omlet> Hi
[09:51] <omlet> I installed a 18.04 server with automatic lvm partition layout
[09:52] <omlet> with 240Go disk, the ubuntu-lv is only 4go
[09:52] <omlet> and now full...
[09:52] <omlet> I tried to extend and it's ok
[09:52] <lordievader> 4Gb is quite small for a root-fs....
[09:52] <omlet> yes :/
[09:53] <omlet> when I boot now it showing no space...
[09:53] <lordievader> Did you forget to extend the fs?
[09:53] <omlet> I tried resize2fs but it can't find valid filesystem block
[09:54] <omlet> I tried: resize2fs /dev/ubuntu-vg/ubuntu-lv
[09:54] <lordievader> Could you pastebin the output of `sudo pvs`, `sudo vgs` and `sudo lvs`?
[09:54] <omlet> "Filesystem has unsupported read-only features"
[09:55] <omlet> I'm in live cd right now :p
[09:55] <omlet> Trying to paste that
[09:57] <omlet> https://pastebin.com/GDa69fXa
[09:58] <omlet> looks good to me :/
[10:00] <lordievader> You forgot the `sudo lvs` 😉
[10:02] <omlet> lordievader: sorry https://pastebin.com/4r3mR9c1
[10:05] <lordievader> Yes, that looks good. `sudo resize2fs /dev/ubuntu-vg/ubuntu-lv` gave an error?
[10:05] <omlet> I'm on 16.04 live
[10:05] <lordievader> Also, why are you using LVM if you only have a single paritition claming all the space?
[10:05] <omlet> it says e2fsck get a newer version
[10:06] <omlet> that was auto during installing
[10:06] <omlet> my bad :/
[10:07] <omlet> will try from 18.04 livecd
[10:22] <omlet> resize2fs ok via 18.04 livecd....
[10:22] <omlet> thanks lordievader
[11:06] <jamespage> coreycb: +1 great!
[11:07] <coreycb> jamespage: well, up to 13 on proposed but getting there and it might just be limited to nova api
[11:25] <jamespage> coreycb: ok
[11:25] <jamespage> I'll take a peek as well
[11:26] <kstenerud> Does anyone know what this lintian error means, or how to fix it?
[11:26] <kstenerud> E: libphp7.2-embed: package-must-activate-ldconfig-trigger usr/lib/libphp7.2.so
[11:28] <kstenerud> cpaelzer rbasak Do you guys know?
[11:29] <rbasak> kstenerud: I do, but the full detail is a bit complex to explain. Have you done any Googling on this?
[11:29] <rbasak> kstenerud: start by trying to understand what ldconfig does
[11:29] <kstenerud> yes. All I get for any lintian errors is a list of lintian reports
[11:30] <rbasak> kstenerud: and then what dpkg triggers do.
[11:30] <kstenerud> but nothing about an explanation of what the error codes mean
[11:30] <kstenerud> The actual meaning of the lintian errors seems to have been lost in time, not documented anywhere
[11:31] <rbasak> First hit: https://lintian.debian.org/tags/package-must-activate-ldconfig-trigger.html
[11:31] <rbasak> Does the extended description at the top there not explain it?
[11:32] <kstenerud> oh hang on yeah just saw that. I didn't notice the yellow bit at the top, only the list of failing packages
[11:33] <kstenerud> rbasak: But one other question: The error only shows up in an sbuild, not when I run lintian manually. What does sbuild do differently to get the different error list?
[11:35] <rbasak> kstenerud: sbuild runs the version of lintian that's in the target release. That might be different perhaps?
[11:36] <rbasak> Besides that, lintian has a bunch of severity and reportingg options that might be affecting the output. Also, finally, lintian runs some checks on the sources and others on the built binaries. When you run locally are you doing both?
[11:36] <kstenerud> I'm just running it on the dsc file
[11:37] <kstenerud> so I'd need to run it against the deb file then?
[11:38] <rbasak> All the generated deb files, yes.
[11:39] <kstenerud> ok thanks
[11:53] <jamespage> coreycb: hmm ImagePropertiesFilter is removing all hosts
[12:48] <coreycb> jamespage: ah yeah that's interesting
[13:26] <rbasak> Happy mailman day everyone!
[15:14] <nacc> kstenerud: is that a lintian error not present in debian?
[15:14] <kstenerud> nacc: I'm not sure. I'm trying to port over php 7.2.15 from upstream
[15:15] <kstenerud> I'm trying adding libphp-embed.triggers to see if that helps
[15:18] <nacc> kstenerud: well, i mean, it's already in bionic and cosmic
[15:19] <kstenerud> yeah, but they were upgraded from 7.2.10, whereas devel is at 7.2.11
[15:19] <nacc> kstenerud: is that error present in the pkg currently in dd ?
[15:19] <kstenerud> how would I check?
[15:20] <nacc> kstenerud: you can run lintian on those src and debs, no?
[15:20] <nacc> on 7.2.11-3build2, that is
[15:25] <kstenerud> oh
[15:25] <kstenerud> tested 7.2.15 on bionic, passes with no warnings/errors
[15:25] <kstenerud> let's see about disco
[15:28] <kstenerud> 7.2.11 also passes
[15:28] <nacc> interesting, so it could be a lintian change in coordination with a srcpkg change?
[15:30] <kstenerud> I don't really know how this all works tbh
[15:30] <nacc> you only get the error from the binary debs? or from the srcpkg?
[15:30] <kstenerud> I get it when I try to sbuild
[15:30] <kstenerud> not from the source
[15:30] <nacc> oh
[15:31] <kstenerud> I've been chasing down how to do triggers because that's what the docs say to add
[15:31] <nacc> well, i mean sbuild is building the src :)
[15:31] <kstenerud> but adding debian/triggers didn't help, so now I'm trying debian/libphp-embed.triggers
[15:33] <nacc> https://lintian.debian.org/full/team+pkg-php@tracker.debian.org.html#php7.3_7.3.1-1
[15:33] <nacc> so it's a bug in the debian package too
[15:34] <kstenerud> hmm weird I wonder why I'm not triggering it when I run it on the deb myself?
[15:54] <nacc> kstenerud: so sanity check, build the exact same sourc pacakge in a bionic sbuild
[15:54] <nacc> kstenerud: if it doesn't error, it's a behavior change in lintian, which seems themost likely
[15:54] <kstenerud> ok
[15:54] <kstenerud> but regardless, isn't the error going to cause it to be rejected in lp?
[15:54] <nacc> kstenerud: the build fails?
[15:55] <kstenerud> the build ends with status successful, and lintian fail
[15:56] <nacc> kstenerud: well, 7.3.2-3 built on disco
[15:56] <nacc> https://launchpad.net/ubuntu/+source/php7.3/7.3.2-3
[16:06] <nacc> kstenerud: does the srcpkg invoke dh_makeshlibs?
[16:07] <kstenerud> actually since it's the same behavior in debian, we don't want to harden it more than them
[16:16] <nacc> kstenerud: yeah
[16:16] <nacc> kstenerud: my point above was that you're just doing an upstream update, which doens't change any packaging, which means it's not a regression, afaict from what is already in DD
[19:58] <Elagost> anyone have any experience running a local apt mirror?
[20:02] <lordcirth> Elagost, what's your actual question?
[20:03] <Elagost> I'm trying to run do-release-upgrade on a server behind a local apt mirror. There are some files 404's on beause they're not in my pool, but I thought I had everything appropriately mirrored.
[20:03] <Elagost> Is there a way to ensure I have a complete set of packages a server's going to need for an upgrade in mirror/ubuntu/pool/ ?
[20:04] <Elagost> Is there, somewhere, an example /etc/apt/mirror.list that I can look at?
[20:04] <Elagost> Trying to migrate our 14.04 servers to at least 16.04.
[20:05] <Elagost> This guide was pretty helpful with getting the meta-release files, etc. http://blog.ef.net/2012/10/26/unbutu-release-upgrade-with-local-apt-mirror.html
[20:06] <Elagost> but when i actually do-release-upgrade on the client machine, it 404's on DLing a bunch of packages that were not in its list of packages it was going to upgrade in the first place.
[20:12] <JanC> dependencies?
[20:12] <Elagost> Likely. it's upgrading most of the packages on the system anyway.
[20:13] <Elagost> but they ideally should be mirrored already; I'm pretty sure there's something in the mirror that I just don't have.
[20:14] <sarnold> how did you populate your mirror?
[20:14] <Elagost> using apt-mirror.
[20:14] <sarnold> are you sure the 404s are packages and not something hosted outside the archive? (I have to admit I'm shockingly unaware of how do-release-upgrade works..)
[20:16] <JanC> it's the commandline version of update-manager, so it should disable all non-standard repositories
[20:17] <Elagost> they're 404ing on something with the repo IP in it, but in pool/main/...etc...
[20:17] <sdeziel> Elagost: maybe you could paste the output you are seeing?
[20:19] <JanC> is it giving the 404s as errors or as info/warnings?
[20:19] <Elagost> I'm not running the upgrades from this machine; it's a totally network isolated environment on a separate machine. I'll get output soon as I can.
[20:19] <Elagost> the apt-mirror server is the only one with internet access.
[20:20] <Elagost> And it's aborting the upgrade because of the 404s, so pretty confident they're errors.
[20:22] <sdeziel> Elagost: could you tell some of the package names that got 404?
[20:23] <Elagost> 'zerofre' is one of them. It's looking for 1.0.3, and my apt mirror is hosting 1.0.2. It has the targz files and dsc files for 1.0.3, and the upgrade is requesting 1.0.3, but for some reason my mirror doesn't have the .deb for it.
[20:23] <Elagost> I think there's something wrong with my apt-mirror.
[20:24] <Elagost> But not sure what sort of stuff I should have in my /etc/apt/mirror.list. Just spitballing at this point, then re running apt-mirror and waiting for it to finish another 30GB at this point.
[20:26] <sdeziel> Elagost: OK, zerofree was not updated recently so that rules out the hypothesis that maybe the release file was pointing to an update published after your mirror sync'ed.
[20:27] <Elagost> yeah, I've repeatedly run apt-mirror today after adding new repos. Not sure what all is the recommended default.
[20:27] <Elagost> can't find documentation on it.
[20:28] <sarnold> I think most mirrors are using the double-rsync method
[20:31] <Elagost> apt-mirror's man page: "* It never produces an inconsistend mirror including while mirroring" :)
[20:49] <Elagost> Well, now I'm mirroring security.ubuntu.com as well as us.archive.ubuntu.com. That should help in some way at least.
[20:49] <lordcirth> Elagost, are you sure you need a mirror? Most people who want a mirror would be better off with a caching proxy
[20:52] <Elagost> lordcirth: That might be better. It was set up this way before I got here though :)
[20:54] <sarnold> definitely caching proxy would be way less bandwidth
[20:54] <Elagost> exactly; there are a lot of packages here that I don't need. but it's a drop in the bucket compared to some of our other servers!
[20:55] <sarnold> nod, a lot of laptops could host a full archive mirror :)
[20:55] <sarnold> rpi with a usb enclosure..
[20:56] <Elagost> that would be awful!
[22:36]  * keithzg[m] swears by apt-cacher-ng