[03:19] <mwhudson> how frequently does launchpad import packages from debian? i can't remember
[04:57] <alkisg> mwhudson: hi; I'm around in case you need any feedback wrt https://code.launchpad.net/~alkisg/ubuntu/+source/isc-dhcp/+git/isc-dhcp/+merge/371861
[07:04] <ackk> rbasak, hi, would you mind reviewing https://code.launchpad.net/~ack/ubuntu/+source/django-piston3/+git/django-piston3/+merge/372061 and if you approve sponsor the upload?
[08:04] <Laney> ddstreet: you might be interested in https://git.launchpad.net/autopkgtest-cloud/log/?h=wip/mojo-juju-2
[08:05] <Laney> this is something that actual humans can deploy (if they have an Openstack)
[08:41] <cjwatson> mwhudson: every six hours
[10:07] <mitya57> sil2100: hi! Please see https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1833536/comments/8 — I think qtbase-opensource-src/bionic-proposed can also be released to -updates
[10:18] <Laney> mwhudson: tobikoch: rcj: do you have any feedback on https://paste.debian.net/1098377/ ? we've got image builds failing now because the partial seeds aren't valid so I was trying for a low-enough-risk way of deferring this to the end
[10:18] <Laney> (untested)
[10:19] <mwhudson> Laney: sounds sane
[10:19] <mwhudson> alkisg: aaargh tomorrow i promise
[10:19] <alkisg> mwhudson: no worries, as long as it makes it for 20.04 :D
[10:21] <mwhudson> alkisg: that's the sort of time frame i should be able to meet
[10:23] <Laney> except that the "-n" should be "-z", otherwise the test is inverted :P
[11:16] <rbasak> ackk: this package is a mess :(
[12:04] <ackk> rbasak, yeah, hopefully we'll be able to move away from it by transitioning to snaps
[12:05] <rbasak> ackk: still the same maintenance issues though?
[12:05] <ackk> rbasak, we have a branch in LP where we track the changes we have from the original pcakage
[12:06] <ackk> rbasak, so we could switch to that instead, or even include it in maas
[12:07] <cjwatson> Laney: Is that what's going on with the mysterious i386 failures on https://launchpad.net/~cloud-images/+livefs/ubuntu/eoan/cpc-buildd/ ?
[12:08] <cjwatson> Laney: (I'm slightly confused because I wouldn't have expected buildd images to have any snaps seeded at all)
[12:09] <ackk> rbasak, it's unfortunately an abandoned project
[12:10] <Laney> cjwatson: I think that's a bug that I've incidentally fixed (not in that diff; I noticed it while running the autopkgtest locally)
[12:10] <Laney> https://git.launchpad.net/livecd-rootfs/tree/live-build/functions#n658 notice the different paths on 658 and 659
[12:10] <Laney> although maybe that but in a different place, reading the message closely
[12:10] <cjwatson> Mm, could be
[12:11] <Laney> probably a missing similar guard somewhere
[12:13] <Laney> or is "iptables: Bad rule (does a matching rule exist in that chain?)." the actual error?
[12:13] <Laney> TIL that we use iptables in livecd-rootfs
[12:14] <Laney> mmm, snap-seed-parse exit(0)s after printing that warning, so it won't be that
[12:21] <Laney> cjwatson: so the iptables -A failed or something?
[12:22] <cjwatson> Tobias asked something about that the other day IIRC
[12:22] <cjwatson> https://irclogs.canonical.com/2019/08/27/%23launchpad-ops.html#t11:00
[12:24] <Laney> Sounds likely
[12:24] <cjwatson> But I have no idea how it could be LP's fault
[12:24] <Laney> any difference that would explain it only happening on i386?
[12:24] <cjwatson> Not that I know of
[12:25] <cjwatson> Tempted to just suggest || true-ing the iptables cleanup command because honestly who cares
[12:26] <Laney> at that point, yes, but if it means that the magic-proxy thing isn't working because the nat rule never got set up
[12:26] <Laney> maybe you'd want to move the failure earlier somehow
[12:26] <cjwatson> The only thing I can think of is that the daemon user's uid might have changed, but that seems fairly spectacularly unlikely
[12:27] <cjwatson> Right, that's definitely possible given that livecd.magic-proxy.log is empty in successful builds
[12:27] <cpaelzer> rafaeldtinoco: ahasenack: could one of you lend me an eye and confirm that this is nonsense => https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/misc/util_misc.c#L718
[12:27] <cjwatson> iptables doesn't seem to be displayng any errors though
[12:28] <cpaelzer> after the assert we can assume expand != NULL, then chunks[i] is set to expand (which as we know is != NULL), and then the check for chunks[i] == NULL should never matter - do you agree?
[12:28] <ahasenack> that's a lot of #idfefs
[12:29] <cpaelzer> unless their ASSERT isn't alsways on or so
[12:29]  * rafaeldtinoco checks
[12:30] <cpaelzer> hmm yeah, just found that their ASSERT isn't always active
[12:30] <cpaelzer> depending on the config it could be https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/include/vm_assert.h#L259
[12:30] <ahasenack> cpaelzer: it's not immediately obvious, there are a lot of assignments to expand before that
[12:31] <ahasenack> ah, wait, you said something more after the ping
[12:32] <ahasenack> ok, you are comparing line 718 (assert) with 721 (another check for null)
[12:32] <cpaelzer> ahasenack: yeah I was wondering if line #722 inside the if could even be reached
[12:33] <cpaelzer> but since then I found that their ASSERT might be on/off depending on the config, and therefore it can enter the if
[12:33] <cpaelzer> that was all I wanted to know - sorry for the noise rafaeldtinoco & ahasenack
[12:33] <ahasenack> rubber duck debugging
[12:33] <ahasenack> worked flawlessly again
[12:34]  * rafaeldtinoco glad he helped
[12:34] <rafaeldtinoco> rofl
[12:35] <cpaelzer> :-)
[12:57] <Laney> cjwatson: I've pushed what I have; did you want to add the "|| true" or something before I upload?
[13:07] <cjwatson> Laney: No, let's see how your changes go I guess
[13:08] <cjwatson> I may be able to see if I can reproduce anything locally
[13:22] <Laney> OK
[13:31] <sil2100> mitya57: I know, I talked with RikMills on -release about that earlier
[13:53] <cpaelzer> ahasenack: rafaeldtinoco: this might be a rubber duck again - is "static inline" now an error?
[13:53] <cpaelzer> http://paste.ubuntu.com/p/dfphNffZW6/
[13:54] <rafaeldtinoco> cpaelzer: welcome to wonderful world of gcc9
[13:54] <rafaeldtinoco> and its new warnings
[13:54] <rafaeldtinoco> ive been facing this all previous week
[13:54] <cpaelzer> I'm ther all day already rafaeldtinoco :-)
[13:56] <cpaelzer> well in the context it is here https://developer.gnome.org/glib/stable/glib-Miscellaneous-Macros.html#G-INLINE-FUNC:CAPS
[13:56] <rafaeldtinoco> cpaelzer: https://gcc.gnu.org/gcc-9/changes.html
[13:56] <rafaeldtinoco> it does not explicitly say its a change
[13:56] <cpaelzer> so I'd just convert it to "static inline" then
[13:56] <cpaelzer> lets see if it then still is an issue
[13:57] <rafaeldtinoco> cpaelzer: its funny because inline is (or used to be) just a hint
[13:57] <rafaeldtinoco> so static would still make sense
[14:00] <cpaelzer> well I'd love to see some more error context on this
[14:00] <cpaelzer> the message doesn't really make sense
[14:00] <cpaelzer> but since I found that it is deprecated lets follow the advice and replace it
[14:00] <cpaelzer> maybe it works or at least has a more graspable error then
[14:12] <rafaeldtinoco> op_query.c:341:2: error: format not a string literal and no format arguments [-Werror=format-security]
[14:12] <rafaeldtinoco> cpaelzer: ^
[14:13]  * rafaeldtinoco wrapping gcc with Wno-error 
[14:13] <rafaeldtinoco> #)
[14:15] <rafaeldtinoco> i wonder why we didn´t catch errors like this ^
[14:15] <rafaeldtinoco> in package upload/sync
[14:15] <rafaeldtinoco> and I do get it now
[14:15] <rafaeldtinoco> do we copy binaries from one version to another ?
[14:29] <rafaeldtinoco> cpaelzer: LOL getopt() loops indefinitely in arm64
[14:29] <rafaeldtinoco> char t = getopt() -> while t != -1
[14:29] <rafaeldtinoco> t will never be -1 =) compiler does not assume -1 == (char)
[14:30] <rafaeldtinoco> (for arm64 only)
[14:30]  * rafaeldtinoco fixing ocfs2-tools upstream
[14:39] <cpaelzer> yay
[14:39] <cpaelzer> nice find rafaeldtinoco
[14:39] <rafaeldtinoco> cpaelzer: similar to the one you found some time ago
[14:39] <rafaeldtinoco> about overflows in arm64
[14:39] <rafaeldtinoco> (char) stays 255 forever
[14:56] <cpaelzer> rafaeldtinoco: you said you fought issues like that last week - any idea why -Wno-error=deprecated-declarations (and some permutations thereof) don't get rid of error: Deprecated pre-processor symbol [-Werror]
[14:56] <cpaelzer> I'd not want to generally unset -Werror
[14:57] <cpaelzer> but it seems that is what it wants to tell me ... :-/
[14:57] <rafaeldtinoco> cpaelzer: whenever this happened to me... debian/rules was overriding somewhere else
[14:59] <cpaelzer> not here, I see it in the commandline
[14:59] <cpaelzer> unless it comes before some re-enable
[15:00] <cpaelzer> ...
[15:00] <rafaeldtinoco> cpaelzer: try LC_FLAGS directly in rules with -Wno-error=
[15:00] <rafaeldtinoco> just to make sure =) ive done it
[15:06] <rafaeldtinoco> export CFLAGS+="-Wno-error=format-security"
[15:06] <rafaeldtinoco> example ^
[15:07] <rafaeldtinoco> without "s
[15:09] <ahasenack> there is a maintainer var  for adding and removing chunks in cflags and friends
[15:20] <rafaeldtinoco> yep, that was just to check if it would be overridden..
[15:20] <rafaeldtinoco> not sure if there is as HARDENING option for no-error
[15:20] <rafaeldtinoco> or you have to specifically add as DEB_CFLAGS (or something like it)
[17:18] <ahasenack> rafaeldtinoco: cpaelzer: is this a known thing with the mysql8 update?
[17:18] <ahasenack> + mysql_install_db --no-defaults --user=mysql --datadir=/<<PKGBUILDDIR>>/mysql_db/data
[17:18] <ahasenack> debian/setup-mysql.sh: 47: mysql_install_db: not found
[17:18] <ahasenack> that's in the php7.2 build
[17:18] <rafaeldtinoco> ahasenack: errr, no ?
[17:18] <rafaeldtinoco> =)
[17:18] <ahasenack> I was wondering if mysql_install_db was renamed or something
[17:18] <rafaeldtinoco> first time I see this :\
 <- extra < ?
[17:19] <rafaeldtinoco> ah nm
[17:19] <ahasenack> no, that's just from launchpad
[17:19] <rafaeldtinoco> yep
[17:20] <ahasenack> mysql-server-core-5.7: /usr/bin/mysql_install_db
[17:20] <ahasenack> let me see if mysql8 has something equivalent
[17:20] <rafaeldtinoco> i was checking that
[17:20] <rafaeldtinoco> yep
[17:20] <rafaeldtinoco> apt-file update here
[17:20] <rafaeldtinoco> err, looks like it doesn´t
[17:21] <rafaeldtinoco> mariadb-server-core-10.3 and percona-xtradb-cluster-server-5.7 only
[17:21] <rafaeldtinoco> i think u found a bug
[17:21] <rafaeldtinoco> =)
[17:23] <ahasenack> rbasak: do you recall something about that mysql_install_db binary/script? It doesn't seem to be available in mysql8
[17:24] <rbasak> ahasenack: yes there's a new way now
[17:24] <ahasenack> rbasak: known bug in php 7.2, or shall I file one?
[17:24]  * ahasenack searches quickly
[17:25] <rbasak> ahasenack: we want to remove src:php7.2 before release.
[17:25] <rbasak> So not worth fixing?
[17:25] <ahasenack> I see
[17:25] <ahasenack> it's in the migration blocking list
[17:25] <rbasak> See the git repository with patches for examples
[17:25] <rbasak> bryce: ^ do you have removal in your list?
[17:26] <ahasenack> bryce is on holiday today
[17:26] <ahasenack> I don't see a card in the daily board
[17:27] <ahasenack> rbasak: I'll respond in the mail thread, I see he saw this already
[17:31] <ahasenack> rbasak: php7.3 started tests now \o/
[17:32] <ahasenack> mediawiki failed, but just on armhf...
[17:32] <ahasenack> heh, it's the only one that actually used mysql8
[17:34] <ahasenack> rbasak: I think a whole bunch of the tests in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php7.3 used mysql-5.7 instead of 8
[17:35] <ahasenack> checked mediawiki and php-horde-db so far
[17:36] <ahasenack> those runs are old, from about 3w ago
[17:38] <ahasenack> they ran before the universe/main dependency issue was solved? I was wondering how they appeared so quickly
[17:59] <rafaeldtinoco> ocfs2-tools in -proposed is broken BTW (and ocfs2-tools in -stable has defrag broken). working on it.
[18:05] <ahasenack> rafaeldtinoco: the defrag command is new in this version, btw
[18:05] <ahasenack> new in 1.8.6, I mean
[18:05] <rafaeldtinoco> ahasenack: yep, its because of an overflow of a small int (char)
[18:05] <rafaeldtinoco> in arm64 it does not overflow =)
[18:05] <ahasenack> rafaeldtinoco: I meant it's not broken in 1.8.5 because it doesn't exist there
[18:06] <rafaeldtinoco> ahh no, its the service name
[18:06] <rafaeldtinoco> but i think its on my end, will flag the bug i just created as invalid
[18:06] <rafaeldtinoco> anytime soon
[18:06] <rafaeldtinoco> hopefully
[18:06] <rafaeldtinoco> yep, it was on my end, i missed the 1st quilt patch
[18:38] <rafaeldtinoco> ahasenack: are u aware of a way to ignore files when using dpkg-source --commit ?
[18:38] <ahasenack> no, I don't think I have ever used --commit
[19:07] <rbasak> rafaeldtinoco: you could use --commit and then pop quilt and delete the file from the patch manually if that helps
[19:08] <rafaeldtinoco> rbasak: quilt pop 1
[19:08] <rafaeldtinoco> and then refresh ?
[19:08] <rafaeldtinoco> ah i see, delete from patch
[19:45] <rafaeldtinoco> [  541.862381] ocfs2: Mounting device (7,0) on (node 0, slot 0) with ordered data mode.
[19:45] <rafaeldtinoco> [  967.650404] INFO: task defragfs.ocfs2:15546 blocked for more than 120 seconds.
[19:45] <rafaeldtinoco> [  967.655841]       Tainted: P           O      5.0.0-27-generic #28-Ubuntu
[19:45] <rafaeldtinoco> [  967.661329] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[19:45] <rafaeldtinoco> [  967.666882] defragfs.ocfs2  D    0 15546   5947 0x00000801
[19:45] <rafaeldtinoco> [  967.672396] Call trace:
[19:45] <rafaeldtinoco> [  967.677892]  __switch_to+0xb8/0x1a8
[19:45] <rafaeldtinoco> [  967.683418]  __schedule+0x358/0x998
[19:45] <rafaeldtinoco> [  967.688882]  schedule+0x30/0x78
[19:45] <rafaeldtinoco> [  967.694283]  rwsem_down_write_failed+0x144/0x258
[19:45] <rafaeldtinoco> [  967.699720]  down_write+0x54/0x58
[19:46] <rafaeldtinoco> ocfs2 is a nightmare
[19:46] <rafaeldtinoco> anyway, fix works
[21:06] <rafaeldtinoco> cpaelzer: I believe that DEB_BUILD_MAINT_OPTIONS=hardening=+all,-format
[21:07] <rafaeldtinoco> would be the appropriate option to handle -Wformat and -Wformat-security options
[21:07] <rafaeldtinoco> -Wformat and -Werror=format-security options, but that does not seem to be working for GCC9 (just tested), this way I had to export CFLAGS to -Wno-errror=format-security
[21:07] <rafaeldtinoco> Ill open a bug as soon as this is over
[21:07] <rafaeldtinoco> (this = my bug)
[21:11] <mwhudson> oh for heavens sake i need to skip another test in golang-golang-x-tools
[21:13] <rafaeldtinoco> its skip tests season!
[21:16] <rafaeldtinoco> cpaelzer: nm, my env CFLAGS is overriding debian/rules one, and it comes from $(dpkg-buildflags --get CFLAGS)
[21:17] <rafaeldtinoco> so correct way to discard format-security warnings (for now, with GCC9) would be DEB_BUILD_MAINT_OPTIONS=hardening=+all,-format
[21:17] <rafaeldtinoco> and, unfortunately, there is quite a few popping up here and there.. so not sure if we should go upstream and do small fixes or just get rid of the errors