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