mwhudson | how frequently does launchpad import packages from debian? i can't remember | 03:19 |
---|---|---|
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 | 04:57 |
=== cpaelzer_ is now known as cpaelzer | ||
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? | 07:04 |
Laney | ddstreet: you might be interested in https://git.launchpad.net/autopkgtest-cloud/log/?h=wip/mojo-juju-2 | 08:04 |
Laney | this is something that actual humans can deploy (if they have an Openstack) | 08:05 |
cjwatson | mwhudson: every six hours | 08:41 |
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:07 |
ubottu | Launchpad bug 1833536 in qtbase-opensource-src (Ubuntu Bionic) "QuiteRSS crashes intermittently" [Undecided,Fix committed] | 10:07 |
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:18 |
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:19 |
mwhudson | alkisg: that's the sort of time frame i should be able to meet | 10:21 |
Laney | except that the "-n" should be "-z", otherwise the test is inverted :P | 10:23 |
rbasak | ackk: this package is a mess :( | 11:16 |
ackk | rbasak, yeah, hopefully we'll be able to move away from it by transitioning to snaps | 12:04 |
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:05 |
ackk | rbasak, so we could switch to that instead, or even include it in maas | 12:06 |
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:07 |
cjwatson | Laney: (I'm slightly confused because I wouldn't have expected buildd images to have any snaps seeded at all) | 12:08 |
ackk | rbasak, it's unfortunately an abandoned project | 12:09 |
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:10 |
Laney | probably a missing similar guard somewhere | 12:11 |
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:13 |
Laney | mmm, snap-seed-parse exit(0)s after printing that warning, so it won't be that | 12:14 |
Laney | cjwatson: so the iptables -A failed or something? | 12:21 |
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:22 |
=== ricab is now known as ricab|lunch | ||
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:24 |
cjwatson | Tempted to just suggest || true-ing the iptables cleanup command because honestly who cares | 12:25 |
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:26 |
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:27 |
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:28 |
cpaelzer | unless their ASSERT isn't alsways on or so | 12:29 |
* rafaeldtinoco checks | 12:29 | |
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:30 |
ahasenack | ah, wait, you said something more after the ping | 12:31 |
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:32 |
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:33 |
* rafaeldtinoco glad he helped | 12:34 | |
rafaeldtinoco | rofl | 12:34 |
cpaelzer | :-) | 12:35 |
Laney | cjwatson: I've pushed what I have; did you want to add the "|| true" or something before I upload? | 12:57 |
cjwatson | Laney: No, let's see how your changes go I guess | 13:07 |
cjwatson | I may be able to see if I can reproduce anything locally | 13:08 |
Laney | OK | 13:22 |
=== Wryhder is now known as Lucas_Gray | ||
sil2100 | mitya57: I know, I talked with RikMills on -release about that earlier | 13:31 |
=== ricab|lunch is now known as ricab | ||
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:53 |
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:54 |
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:56 |
rafaeldtinoco | cpaelzer: its funny because inline is (or used to be) just a hint | 13:57 |
rafaeldtinoco | so static would still make sense | 13:57 |
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:00 |
rafaeldtinoco | op_query.c:341:2: error: format not a string literal and no format arguments [-Werror=format-security] | 14:12 |
rafaeldtinoco | cpaelzer: ^ | 14:12 |
* rafaeldtinoco wrapping gcc with Wno-error | 14:13 | |
rafaeldtinoco | #) | 14:13 |
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:15 |
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:29 |
rafaeldtinoco | (for arm64 only) | 14:30 |
* rafaeldtinoco fixing ocfs2-tools upstream | 14:30 | |
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:39 |
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:56 |
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:57 |
cpaelzer | not here, I see it in the commandline | 14:59 |
cpaelzer | unless it comes before some re-enable | 14:59 |
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:00 |
rafaeldtinoco | export CFLAGS+="-Wno-error=format-security" | 15:06 |
rafaeldtinoco | example ^ | 15:06 |
rafaeldtinoco | without "s | 15:07 |
ahasenack | there is a maintainer var for adding and removing chunks in cflags and friends | 15:09 |
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) | 15:20 |
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 :\ | 17:18 |
rafaeldtinoco | <PKGBUILDDIR>> <- extra < ? | 17:18 |
rafaeldtinoco | ah nm | 17:19 |
ahasenack | no, that's just from launchpad | 17:19 |
rafaeldtinoco | yep | 17:19 |
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:20 |
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:21 |
ahasenack | rbasak: do you recall something about that mysql_install_db binary/script? It doesn't seem to be available in mysql8 | 17:23 |
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:24 | |
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:25 |
ahasenack | bryce is on holiday today | 17:26 |
ahasenack | I don't see a card in the daily board | 17:26 |
ahasenack | rbasak: I'll respond in the mail thread, I see he saw this already | 17:27 |
ahasenack | rbasak: php7.3 started tests now \o/ | 17:31 |
ahasenack | mediawiki failed, but just on armhf... | 17:32 |
ahasenack | heh, it's the only one that actually used mysql8 | 17:32 |
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:34 |
ahasenack | checked mediawiki and php-horde-db so far | 17:35 |
ahasenack | those runs are old, from about 3w ago | 17:36 |
ahasenack | they ran before the universe/main dependency issue was solved? I was wondering how they appeared so quickly | 17:38 |
rafaeldtinoco | ocfs2-tools in -proposed is broken BTW (and ocfs2-tools in -stable has defrag broken). working on it. | 17:59 |
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:05 |
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:06 |
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 | 18:38 |
rbasak | rafaeldtinoco: you could use --commit and then pop quilt and delete the file from the patch manually if that helps | 19:07 |
rafaeldtinoco | rbasak: quilt pop 1 | 19:08 |
rafaeldtinoco | and then refresh ? | 19:08 |
rafaeldtinoco | ah i see, delete from patch | 19:08 |
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:45 |
rafaeldtinoco | ocfs2 is a nightmare | 19:46 |
rafaeldtinoco | anyway, fix works | 19:46 |
rafaeldtinoco | cpaelzer: I believe that DEB_BUILD_MAINT_OPTIONS=hardening=+all,-format | 21:06 |
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:07 |
mwhudson | oh for heavens sake i need to skip another test in golang-golang-x-tools | 21:11 |
rafaeldtinoco | its skip tests season! | 21:13 |
rafaeldtinoco | cpaelzer: nm, my env CFLAGS is overriding debian/rules one, and it comes from $(dpkg-buildflags --get CFLAGS) | 21:16 |
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 | 21:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!