=== walbon is now known as gwalbon_
[08:03] <ginggs> seb128: note libzstd was merged from 1.3.3+dfsg-2 in Debian NEW queue, which was rejected, and a different 1.3.3+dfsg-2 was uploaded. missing at least the udeb stuff
[08:05] <seb128> ginggs, k, then a merge or dropping those changes from Ubuntu as well?
[08:05] <ginggs> seb128: hmm, depends how attached xnox is to those udebs
=== zumbi_ is now known as zumbi
[11:08] <cpaelzer> Skuggen: sil2100: hiho
[11:08] <Skuggen> o/
[11:08] <cpaelzer> sil2100: I'd want for Skuggen to be able to use bileto
[11:08] <cpaelzer> I know the bileto-users LP group
[11:08] <cpaelzer> but there was something else that my brain doesn't want to remember
[11:08] <cpaelzer> sil2100: do you know what else he'd need to fully use it?
[11:09] <rbasak> For background, Skuggen works for MySQL upstream at Oracle. He generally looks after MySQL packaging in Debian and Ubuntu. He's not an uploader currently but I hope he'll get MySQL PPU soon.
[11:30] <sil2100> Hey! Give me a minute guys
=== nOOb__ is now known as LargePrime
[13:23] <sil2100> cpaelzer: sorry it took so long - so, I guess Skuggen would need to do manual uploads to Bileto, right?
[13:23] <sil2100> Skuggen: do you have any upload rights to the archive right now? Could I get your LP id?
[13:24] <sil2100> Since it's a bit tricky right now, we don't have any hard-written policies who should be able to use Bileto, but we have some rules of the thumb - I actually wanted to bring up the topic of Bileto for a while, but we're still not really certain about its fate
[13:24] <sil2100> Maybe it's time for me to start the topic anyway
[13:26] <sil2100> For general Bileto MP-based usage we mostly only require ubuntu membership, but for manual uploads - well, those we usually only gave to people with at least any upload rights to the archive
[13:26] <sil2100> I think Bileto membership should be also reviewed and decided by the DMB, IMO, and that's also one thing I wanted to discuss
[13:27] <cpaelzer> sil2100: yes he'd want to upload to the bileto ppas then
[13:27] <sil2100> But since Bileto is still in bare maintenance mode, well, I guess we'd first have to decide if we want to invest the DMB's time in Bileto membership control
[13:28] <cpaelzer> rbasak: do you know the current state of Skuggen 's upload permissions
[13:28] <cpaelzer> I know more are about to come, but what does he have like now?
[13:29] <sil2100> In case he has no upload permissions, if he really wants to have Bileto upload rights ASAP then I'd recommend attending a DMB meeting for this
[13:29] <sil2100> And maybe actually following the procedures as per any other upload rights
[13:29] <cpaelzer> sil2100: he might have some, but no core-dev or anything similar wide-reaching
[13:30] <cpaelzer> sil2100: this is mostly to allow him to quickly iterate on uploads and trigger dep8 tests
[13:31] <cpaelzer> sil2100: would there be any alternative way to get the "LP base autopkgtest exec of all deps" that Bileto provides to a non Bileto ppa?
[13:34] <rbasak> He currently has no upload access.
[13:34] <rbasak> He intends to apply for MySQL PPU imminently.
[13:34] <rbasak> https://launchpad.net/~lars-tangvald
[13:35] <sil2100> rbasak, cpaelzer: ok, I think in this case I'd defer to the DMB, I think we'd actually need a normal, formal review as for any other PPU access
[13:35] <rbasak> What are the implications of Bileto access in terms of the Ubuntu archive?
[13:36] <sil2100> rbasak: first of all, the user gains access to devirt builders
[13:37] <sil2100> rbasak: also, since there is no ticket-specific ACL in Bileto, having upload access to Bileto PPAs means anyone can affect any other people's ongoing tickets
[13:38] <rbasak> access to devirt builders> I'd say that's more of a matter for infrastructure maintainers - Canonical and therefore Launchpad admins maybe, rather than the DMB?
[13:38] <sil2100> Meaning a melavolent user could upload something to someone's other PPA, which (even though audited) could go unnoticed and therefore get uploaded to the archive
[13:39] <rbasak> That's a bit tricker.
[13:39] <rbasak> trikier
[13:39] <rbasak> trickier
[13:39] <rbasak> \o/
[13:40] <tkamppeter> cyphermox, hi
[13:40] <Skuggen> I don't think it's very urgent, so maybe try to get MySQL PPU access first
[13:40] <rbasak> Yeah that seems the easiest.
[13:41] <sil2100> The unwritten rule so far was that anyone that has at least PPU access is 'trustworthy' enough to use Bileto
[13:41] <rbasak> We would still need to decide if PPU uploaders are permitted to upload to Bileto in general.
[13:41] <rbasak> OK
[13:41] <rbasak> Then we can just do that.
[13:41] <rbasak> Thanks
[13:41] <Skuggen> Right. Thanks :)
[13:42] <sil2100> Skuggen: sorry about that, hope to see your PPU application soon!
[14:01] <tkamppeter> I have a problem with ppc64el. The build of ghostscript gets stuck on it and the build server kills the process after 2 hours, see https://launchpad.net/ubuntu/+source/ghostscript/9.23~dfsg+1-0ubuntu1
[14:01] <tkamppeter> slangasek, could you help on this?
[14:11] <acheronuk> tkamppeter: ah. was just asking in #ubuntu-release about that
[14:11] <acheronuk> being retried, though I am not sure that will help
[14:12] <slangasek> in any event, it means the logs are gone now so I can't guess at the problem
[14:14] <ginggs> tkamppeter: ppc64el in ubuntu defaults to building with -O3, I suggest you try building in your PPA forcing -O2 and seeing what happens
[14:16] <acheronuk> slangasek: drat. build currently hung at the same point, which is then killed at the 150 min timeout without much diagnostic to be honest
[14:18] <acheronuk> slangasek: I have the last log open in a browser tab if you want it?
[14:18] <ginggs> acheronuk: the URL might help
[14:18] <ginggs> i don't think they are removed right away
[14:19] <acheronuk> https://launchpadlibrarian.net/382631754/buildlog_ubuntu-cosmic-ppc64el.ghostscript_9.23~dfsg+1-0ubuntu1_BUILDING.txt.gz
[14:33] <Laney> It'd already failed at least one retry, so this one is quite optimistic.
[14:34] <acheronuk> :/
[14:34] <Laney> "10/08 15:33:54 <ubottu> Review: quiet '$~a' set on Wed Aug  1 14:41:29 2018 in #ubuntu-meeting, link: https://ubottu.com/bans.cgi?log=78631"
[14:34] <Laney> Why did the bot just PM me that?
[14:35] <Laney> Oh, it's asking me to review a channel mode change since I'm an op?
[14:36] <Laney> Yes, I approve of this change ✅
[14:49] <tkamppeter> ginggs, I had used PPAs for some tests some years ago, but they only built for amd64 and i386. how can one make them build for ppc64el?
[14:51] <ahasenack> tkamppeter: it's a checkbox in the details page
[14:52] <ginggs> tkamppeter: go to your PPA in launchpad, click on 'Change details', scroll down to Processors and click on the checkboxes
[15:24] <ahasenack> sil2100: hi, I saw the conversation about bileto earlier, and I would also like bileto rights. I have PPU for landscaoe-client, and ubuntu server packageset. my lp id is ~ahasenack
[15:34] <tkamppeter> ahasenack, ginggs, thanks.
[15:52] <sil2100> ahasenack: hey! Ok, I guess I can work with that, one moment
[16:00] <blackboxsw> hrm, anyone know why I might be getting Error checking signature  during a dput operation for a package upload (line 24) https://pastebin.ubuntu.com/p/Wq3jqvTmgx/?    This is my first time trying to upload with this key (well and a cloud-init upload attempt yesterday)
[16:04] <smoser> blackboxsw: i think it is probalby the local portion of 'dput' that is complaining there.
[16:05] <smoser> it *does* seem to upload.
[16:05] <smoser> blackboxsw: what happens if you just 'gpg --verify ../out/<that-dsc-file>'
[16:07] <blackboxsw> ahhh
[16:07] <blackboxsw> gpg: Good signature from "Chad Smith <chad.smith@canonical.com>" [unknown]
[16:07] <blackboxsw> gpg: WARNING: This key is not certified with a trusted signature!
[16:07] <blackboxsw> gpg:          There is no indication that the signature belongs to the owner
[16:07] <smoser> right. you dont trust yourself.
[16:07] <blackboxsw> I bet I need to edit my signature and add trust
[16:07] <smoser> thats something maybe elizabot can help you with :)
[16:08] <smoser> but if that was the only issue with your cloud-init upload yesterday, i would have expected it to go through
[16:08] <smoser> and it did not seem to.
[16:08] <smoser> curtin did
[16:08] <smoser> https://launchpad.net/ubuntu/+source/curtin/18.1-44-g2b12b8fc-0ubuntu1
[16:10] <blackboxsw> hrm ok just cloud-init didn't then
[16:10] <blackboxsw> https://launchpad.net/ubuntu/+source/cloud-init/18.3-24-gf6249277-0ubuntu1
[16:10] <blackboxsw> which was prior to me associating by new key with my launchpad account
[16:11] <blackboxsw> ok so I might be able to upload a new version of cloud-init to check
[16:13] <smoser> yeah. that makes sense. but id' have thoguht you'd have gotten a rejection or something.
[16:17] <tkamppeter> ginggs, I have compared the end of the log of the ppc64el build of ghostscript with the log of the build on my amd64 machine. It does not hang on a compiler action biut on an action of creation of simple text files (./soobj/aux/echogs call, echogs source is ./base/echogs.c), so -O3/-O2 replacement on gcc calls is most probably not the solution.
[16:19] <ginggs> tkamppeter: so is echogs.c compiled with -O3 or -O2?
[16:29] <cjwatson> blackboxsw,smoser: you don't get a rejection if the key isn't registered in Launchpad
[16:29] <cjwatson> I mean, not a rejection email
[16:29] <tkamppeter> ginggs, this I have to see when the full log gets released and I succeed to catch it before someone else hits the retry button.
[16:38] <blackboxsw> cjwatson: thanks that explains why I didn't see any email about it
[16:48] <tkamppeter> ginggs, slangasek, ahasenack: The ghostscript build finished and I downloaded the log now. Compilation of base/echogs.c (the first compailation at all) uses BOTH -O2 and -O3, what is actually used then?
[16:48] <tkamppeter> Example gcc command line:
[16:48] <tkamppeter> gcc   -fPIC  -O2 -Wdate-time -D_FORTIFY_SOURCE=2  -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -fno-strict-aliasing -Werror=declaration-after-statement -fno-builtin -fno-common -Werror=return-type -DHAVE_STDINT_H=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIBDL=1 -DGX_COLOR_INDEX_TYPE="unsigned long long" -D__USE
[16:48] <tkamppeter> _UNIX98=1  -g -O3 -fdebug-prefix-map=/<<BUILDDIR>>/ghostscript-9.23~dfsg+1=. -fstack-protector-strong -Wformat -Werror=format-security -DUSE_LIBPAPER -I/usr/include/powerpc64le-linux-gnu -fno-strict-aliasing -Wl,-Bsymbolic-functions -Wl,-z,relro -DHAVE_POPEN_PROTO=1 -DHAVE_POPEN_PROTO=1  -I./base -o ./soobj/aux/echogs ./base/echogs.c  -lm -ldl  -lidn -lpaper -ltiff -rdynamic -lfontconfig -lfreetype -lfreetype   -lz
[16:49] <ahasenack> is that what is failing?
[16:50] <slangasek> tkamppeter: later -O option wins
[16:50] <cjwatson>  If you use multiple '-O' options, with or without level numbers, the
[16:50] <cjwatson> last such option is the one that is effective.
[16:50] <cjwatson> says info gcc
[16:50] <ginggs> tkamppeter: i think the second one overrides the first
[16:57] <tkamppeter> Thanks all, so it is actually -O3.
[16:59] <tkamppeter> ahasenack, the shown gcc command line is not failing. It is the one which builds ./sobin/aux/echogs and what is failing is a call of ./sobin/aux/echogs.
[17:00] <tkamppeter> ahasenack, ginggs, slangasek, the failing echogs line is
[17:00] <tkamppeter> ./soobj/aux/echogs -e .dev -a-  ./soobj/xpswrite -include ./soobj/vector -includ
[17:00] <tkamppeter> e ./soobj/libtiff
[17:01] <tkamppeter> It is always this one, which simply hangs indefinitely and gets killed after one and a half hour by the build server.
[17:02] <tkamppeter> There are tons of other echogs lines before which do not fail.
[17:04] <ginggs> tkamppeter: so what happens if echogs is built with -O2 ?
[17:08] <tkamppeter> ginggs, yes, this I could test via PPA. Need to find out now how to override the system-injected -O3 ...
[17:19] <Laney> tkamppeter: export DEB_CFLAGS_MAINT_APPEND = -O2 in debian/rules probably does it
[17:34] <tkamppeter> Laney, thanks.
[23:53] <tsimonq2> Hah, I'm guessing the advice above can help with what I was just about to ask about...
[23:53] <tsimonq2> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905868
[23:53] <ubottu> Debian bug 905868 in gcc-8 "gcc-8: miscompiles vec_sl at -O3 with -fwrapv on ppc64el" [Normal,Open]
[23:53] <tsimonq2> First time but probably not the last I'm going to have to set that flag...