[00:01] <Unit193> nacc: If it helps, I pasted the log from pbuilder a few days ago, and unstable chroots work.
[00:02] <nacc> Unit193: ok, good to know
=== maclin1 is now known as maclin
[06:58] <cpaelzer> still trying to wrap my head around this bug did we cahnge the default pic/pie behaviour with a recent (maybe gcc) update?
[06:59] <cpaelzer> I see some fallout due to "-fPIE -pie" being dropped and replaced by "-specs=/usr/share/dpkg/no-pie-compile.specs"
[06:59] <cpaelzer> at least that is how it seems so far, still debugging
[06:59] <cpaelzer> or any changes to what hardening=+all does maybe
[07:03] <cpaelzer> I thought that the move was still towards pie
[07:04] <cpaelzer> maybe this package drives dpkg/debhelper nuts t generate the wrong options
=== maclin1 is now known as maclin
[07:32] <cpaelzer> ok down to two things "DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags --get CFLAGS" really looses -fPIE
[07:32] <cpaelzer> maybe assumed to be default without stated now?
[07:32] <cpaelzer> the other thing seems package specific and more debuggin
[07:32] <cpaelzer> g
[08:02] <infinity> cpaelzer: Yes, -fPIE is default on all arches.  It's not "losing" PIE.
[08:06] <cpaelzer> thought so
[08:06] <cpaelzer> only the explicit arg is lost which was a red herring for a bit
[08:06] <cpaelzer> I found the issue deeper down due to no-pie-compile.specs now generated by hardening=+all,-pie
[08:07] <cpaelzer> in my case package A (net-snmp) sets -pie and pakage B (nut) collects the build options of A for plugin builds
[08:07] <cpaelzer> but they fail as they pass CFLAGs to all builds, but LDFLAGs only to some
[08:08] <infinity> cpaelzer: Ahh, yes.  CFLAGS and LDFLAGS both need to be pulled from dpkg-buildflags if you're doing one.
[08:08] <cpaelzer> leading to binaries with no-pie-compile.specs but subsequent links without "no-pie-link.specs"
[08:08] <infinity> cpaelzer: Mismatching them will lead to a very bad time.
[08:08] <cpaelzer> exactly that I'm in
[08:09] <cpaelzer> need to fix the package as it is deep in the auto-generated makefiles, not broken on our side really - we are only the trigger by behaving slightly different
[08:09] <cpaelzer> IMHO it was "wrong" all the time just not breaking anything yet
[08:09] <cpaelzer> infinity: you'll love this quote "In any case, CFLAGS are only -I options, so there is no harm"
[08:09] <cpaelzer> from the broken makefile :-)
[08:10] <infinity> cpaelzer: Well, other option is to just explictly state "CFLAGS=$(dpkg-buildflags --get CFLAGS -fno-pie -no-pie)" and similar for LDFLAGS, if that's then being embedded in some pkgconfig file later or something.
[08:11] <infinity> cpaelzer: And yes, I've run into similarly broken makesfiles (both from upstreams, and broken debian/rules).  I guess, to be fair, pie and pic are on a very short list of options where compiler and linker have to agree.
[08:11] <infinity> cpaelzer: So I don't mind educating people when they mess it up.  The real annoyance is when they argue. :P
=== maclin1 is now known as maclin
[08:33] <ginggs> tsimonq2: f.y.i. nodejs 6.11.2 is now in debian unstable and can be merged
[08:35] <tsimonq2> ginggs: ack
[08:37] <tsimonq2> ginggs: I'll have a patch for you as soon as I can, I need a sponsor ;)
[08:41] <ginggs> tsimonq2: i tested a merge of 6.10.2 some weeks ago in my PPA, if it helps - i'll happy to sponsor!
[08:46] <tsimonq2> ginggs: Ok :D
[08:49] <tsimonq2> ginggs: Let's see how the build goes: https://launchpad.net/~tsimonq2/+archive/ubuntu/universe-upload-testing/+packages
[09:02] <cpaelzer> can building with gcc7 affect the c++ symbols exported?
[09:02] <cpaelzer> I guess so
[09:02] <cpaelzer> but they are so unreadable ...
=== maclin1 is now known as maclin
[09:07] <tsimonq2> cpaelzer: Yep, sometimes there's optional templinst symbols that either appear or go "MISSING"
[09:07] <tsimonq2> cpaelzer: Also, c++filt ftw
[09:08] <cpaelzer> yeah it already has a few templinst
[09:08] <cpaelzer> might just be more now or some not yet tracked
[09:08] <cpaelzer> OTOH what broufht me to look were the missing symbols as it broke the check
[09:10] <cpaelzer> and reading/checking if that might be an issue is next to impossible with the names they have
[09:10] <cpaelzer> newer came by c++filt
[09:10] <cpaelzer> need to take a look
[09:12] <cpaelzer> ah yeah looks good
[09:12] <cpaelzer> thanks tsimonq2
=== lexruee__ is now known as lexruee
[09:13] <tsimonq2> cpaelzer: You're welcome, let me know if you need any assistance with symbols mangling (I've learned quite a bit from Qt packaging) :)
[09:15] <cpaelzer> tsimonq2: to me it appears they are rather trimmed than mangled-names - what do you think? http://paste.ubuntu.com/25324531/
[09:16] <cpaelzer> at the same shlibs diff there are two new templates showing up - I'd almost think gcc7 outputs them slightly different so that they are now more "readable"
[09:16] <cpaelzer> but I'd loke to prove
[09:17] <tsimonq2> cpaelzer: Could you get a paste of the new ones?
[09:17] <cpaelzer> already preparing
[09:17] <cpaelzer> http://paste.ubuntu.com/25324539/
[09:17] <cpaelzer> those can at least be demangled - let me try the tool you recommended
[09:17] <cpaelzer> oh yeah
[09:17] <cpaelzer> that seems to match
[09:18] <cpaelzer> need to this more than with eyes on console now
[09:18] <cpaelzer> please let me know what you think tsimonq2 if that seems odd to you
[09:20] <tsimonq2> cpaelzer: Yeah it does seem to match pretty well
[09:22] <cpaelzer> well then let me fix that and make them replace the old ones in-place
[09:22] <cpaelzer> thanks for your hint on c++filt
[09:22] <cpaelzer> that serves well as "prove" on the reason of the change
[09:23] <tsimonq2> cpaelzer: I have this bookmarked and it might help in general with symbols :) https://pkg-kde.alioth.debian.org/symbolfiles.html
[09:23] <cpaelzer> I think I read that in the past when I had fun in dpdk with that
[09:23] <cpaelzer> thx
[09:23] <tsimonq2> yw :)
=== zyga-ubu1tu is now known as zyga-ubuntu
[10:23] <cpaelzer> slangasek: I saw your collectd upload broke on something around dpdk - let this be my problem, I'll ping you with a solution
[11:12] <ginggs> tsimonq2: for nodejs i think you might need debian/patches/fix_sslv3_test.patch from my PPA
[11:31] <LocutusOfBorg> acheronuk, do you plan to have a look at qtwebkit-opensource-src on i386/armhf?
[11:31] <LocutusOfBorg> some symbols sadness
[11:31] <LocutusOfBorg> I can do it, but I think I'll just make things worse, since I don't know how to deal with them :)
[11:33] <acheronuk> KDE stuff I am ok with. The qt packaging, I have only touched briefly on, and have not had much to do with this time. so tsimonq2 or mitya57 are the people I think
[11:34] <LocutusOfBorg> tsimonq2, is asleep :)
[11:34] <LocutusOfBorg> I see they are ~10 symbols changed, I think I can do it, but I don't know which tool they use to do the magick, I can do it manually but I'm not sure it is error-prone
[11:35] <acheronuk> bah. so much for his 'sleep is for the weak' :P
[11:36] <acheronuk> I guess still this? https://pkg-kde.alioth.debian.org/symbolfiles.html
[11:40] <acheronuk> 26 MB build log is killing my browser!
[11:45] <LocutusOfBorg> acheronuk, you can wget and tail -n 200 after gunzip
[11:45] <LocutusOfBorg> or I can give you the two patches
[11:46] <LocutusOfBorg> I'm trying the command right now
[11:46] <LocutusOfBorg> lets see
[11:47] <acheronuk> I'd rather not touch it myself and wait a few hrs
[11:48] <acheronuk> but if you think your result looks sane, then fair enough
[11:48] <LocutusOfBorg> pkgkde-symbolshelper patch -p libqt5webkit5 -v 5.9.1 < ../buildlog_ubuntu-artful-armhf.qtwebkit-opensource-src_5.9.1+dfsg-2_BUILDING.txt
[11:48] <LocutusOfBorg> this fails
[11:48] <LocutusOfBorg> fails in applying patches
[11:49] <acheronuk> I normally grab all the logs, even the passes and they help
[11:50] <LocutusOfBorg> I'll try the old fashioned manual way instead
[11:50] <acheronuk> then do 'pkgkde-symbolshelper batchpatch -v 5.9.1 ../buildlog_ubuntu-artful*'
[11:51] <LocutusOfBorg> ah ok
[11:51] <acheronuk> which compares and confirms, and makes exceptions etc on some arches, based on what happened overall
[11:51] <acheronuk> but think I only tried with Qt once ever
[11:52] <acheronuk> which has some extra stuff for marking private symbols at the least
=== freyes__ is now known as freyes
[11:55]  * acheronuk is away for now
[12:02] <LocutusOfBorg> tsimonq2, please do it, I'm lost
[12:02] <LocutusOfBorg> :)
[12:03] <cpaelzer> slangasek: I have a working fix complete, will report upstream and provide you with a debdiff so you can upload this fix to artful
[12:03] <cpaelzer> slangasek: I don't want to mess with your "potential" uploads you have in queue for that but I don't know of
[12:03] <cpaelzer> slangasek: just need to report and polish the patch headers to be correct
[12:45] <cpaelzer> slangasek: bug 1711120 is ready for you to pick the debdiff from if you agree with the solution
[12:45] <ubottu> bug 1711120 in collectd (Ubuntu) "dpdk subset fails to configure correctly on i386" [High,Triaged] https://launchpad.net/bugs/1711120
[12:46] <xnox> bdmurray, do you remember where "incomplete language support" code lives? and which packages it installs, etc? i think i need to fix cjk languages to install qt4-fcaitx for us to drop qt4 from main.
[12:46] <xnox> bdmurray, or e.g. i could go easier route and make qt4 gui or some such pull in fcaitx as a recomends.
[14:43] <bdmurray> xnox: I think language-selector-gnome puts a file somewhere so update-notifier notifies you about the incomplete support
[15:11] <powersj> rbasak: nacc: when I run `apt show <package>` should the "Supported" field on an LTS always say 5y?
[15:11] <powersj> clear
[15:11] <powersj> woops lol
[15:12] <nacc> powersj: LP: #1574670
[15:12] <ubottu> Launchpad bug 1574670 in update-manager (Ubuntu Xenial) "ubuntu-support-status returns inaccurate information" [High,Confirmed] https://launchpad.net/bugs/1574670
[15:12] <nacc> powersj: for context, if i had to guess
[15:13] <nacc> slangasek: --^ is someone from foundations working that?
[15:14] <powersj> nacc: yeah someone filed LP: #1710721 looks to be similar
[15:14] <ubottu> Launchpad bug 1710721 in libsdl1.2 (Ubuntu) "This packages have the wrong timeframe set for the xenial LTS release" [Undecided,New] https://launchpad.net/bugs/1710721
[15:18] <nacc> powersj: yeah, i'd dupe it
[15:19] <rharper> slangasek: hi,  was looking at the artful cloud server images at the locales present, and I see both C.UTF-8 and en_US.UTF-8 present (http://paste.ubuntu.com/25326237/) ; if we already have the en_US.UTF-8 generated, is there a need for the C.UTF-8 as well?  also, other than the directory presence (/usr/lib/locale/C.UTF8) is there a way to know if C.UTF8 is available?  I  though that localedef --list might show it, bu
[15:19] <rharper> t it doesn't
[15:31] <xnox> bdmurray, ack! thanks.
[15:33] <slangasek> cpaelzer: cool, thanks, the dpdk i386 failure was the last thing I hadn't figured out.  I'll upload that straightaway!  You've forwarded this to upstream?  (Debian upstream or upstream upstream?)
[15:36] <slangasek> nacc: ubuntu-support-status returns inaccurate information because the metadata in the archive is incorrect; this is on infinity to solve
[15:37] <cpaelzer> slangasek: yes collectd upstream
[15:37] <cpaelzer> slangasek: the issue is in the branch
[15:37] <cpaelzer> linked
[15:37] <slangasek> rharper: C.UTF-8 is always available on Ubuntu and we should be using that intsead of en_US.UTF-8, and we should DROP en_US.UTF-8 as a default locale in artful and forward
[15:37] <cpaelzer> I'll make a note to check build and migration in a-p tomorrow
[15:38] <rharper> slangasek: yes, and shouldn't /etc/default/locale  have LANG=C.UTF-8 or is that not the right thing to do ?
[15:38] <rharper> I do see that locale -a shows C.UTF-8 ; so we can always check for that;
[15:39] <slangasek> rharper: we do need to somewhere select C.UTF-8 as the runtime locale, yes
[15:39] <slangasek> rharper: /etc/default/locale is an appropriate place for it
[15:39] <rharper> IIUC, the locale-gen tooling would never generate a C.UTF-8 (it's part of glibc , i think) ?
[15:41] <nacc> slangasek: ok, are you ok if i put that comment in the bug?
[15:50] <slangasek> nacc: I'm certainly ok with it, it's not me you're pointing the finger at ;)
[15:51] <nacc> infinity: --^ :)
[15:51] <nacc> slangasek: ack
[16:09] <ricotz> hello, is there any chance to force firefox to the artful release pocket? https://launchpad.net/ubuntu/+source/firefox/54.0+build3-0ubuntu1
[16:12] <nacc> ricotz: well, it failed to build on a few archs, it seems like?
[16:12] <nacc> chrisccoulson: --^ I assume is looking into it
[16:13] <ricotz> nacc, I know, and no, he is not looking into it
[16:13] <nacc> ricotz: i see
[16:14] <nacc> ricotz: is it a rustc issue?
[16:15] <ricotz> nacc, no
[16:15] <ricotz> several buildsystem and (smaller) source issues
[16:15] <ricotz> I am hoping firefox 56 will be in a better shape
[16:15] <chrisccoulson> it's the armhf failure that stops it from migrating. The other architectures aren't blocking it
[16:15] <nacc> chrisccoulson: ah ok
[16:15] <nacc> chrisccoulson: ah yes, i see that now
[16:16] <ricotz> chrisccoulson, is this already a webrtc failure there?
[16:16] <chrisccoulson> It's blocked on arm because it just crashes at startup, which causes the startup cache compilation to fail
[16:16] <nacc> heh, that message isn't too helpful
[16:16] <nacc> mozpack.errors.ErrorMessage: Error: Error while running startup cache precompilation
[16:16] <chrisccoulson> Firefox 55 doesn't build a startup cache, so it builds ok now. But it still crashes at startup
[16:18] <ricotz> chrisccoulson, still force it into release
[16:19] <ricotz> I guess having 50.1.0 on the iso is quite something
[16:20] <seb128> ricotz, try arguing with infinity that having firefox outdated is a bigger issue than not having it working on armhf
[16:20] <seb128> I tried that before
[16:20] <seb128> he seems to disagree, so somebody needs to eventually fix firefox
[16:20] <ricotz> we can deal with those failures again with 55 / 56
[16:21] <seb128> as I said I'm not the one to convince
[16:25] <ricotz> seb128, you pinged him already ;)
[16:25] <seb128> ricotz, right, and you think that's going to be enough to convince him? ;-)
[16:25] <ricotz> at least to read
[16:25] <seb128> yeah, let's see
[16:37]  * rbalint looking for sponsor for LP: #1709726
[16:37] <ubottu> Launchpad bug 1709726 in akonadi (Ubuntu) "Breaks reverse build-dependencies by embedding build-time std exception header path" [Undecided,Confirmed] https://launchpad.net/bugs/1709726
[16:43] <LocutusOfBorg> rbalint, thanks!
[17:40] <cpaelzer> slangasek: collectd complete, thanks for the upload
[17:40] <cpaelzer> slangasek: and on your Deb question - my co-maintainer on dpdk is watching the PR
[17:40] <cpaelzer> slangasek: since he has no FF ahead he can be more relaxed to pick the final fix without the extra hop including the suggestedone we did for now
[17:40] <slangasek> cpaelzer: excellent
[17:42] <rharper> slangasek: one follow-up;  locale-gen --lang C.UTF-8 returns an Error, 'C.UTF-8' is not a supported language or locale;  is that expected?  and if someone in cloud-init passes us a locale: C.UTF-8 , currently we just call locale-gen ; so we'll need to fix that up if that's expected behavior of locale-gen
[18:01]  * tsimonq2 stretches
[18:01] <tsimonq2> LocutusOfBorg: ack, will do
[18:07] <slangasek> rharper: ah, I thought cloud-init was being fixed to not regenerate already-present locales?
[18:07] <slangasek> rharper: locale-gen doesn't support generating C.UTF-8 because it's always shipped in the glibc package
[18:17] <rharper> slangasek: is it possible to get those tools (locale-gen and update-locale) to not barf on it (even if it doesn't have to regenerate it) ?
=== tkamppeter_ is now known as tkamppeter
[18:18] <rharper> slangasek: cloud-init currently reads the value (if present) in /etc/default/locale, checks if the value in the file matches what it's been told to configure (defaults currently to en_US.UTF-8, we're looking to change to C.UTF-8)  and then we call update-locale to update the file;
[18:18] <slangasek> rharper: bug report on glibc?  but again, I understood from dpb that cloud-init was being changed to avoid regenerating locales when it doesn't need to, which you know categorically you never need to regenerate C.UTF-8, so why are you trying
[18:20] <rharper> slangasek: C.UTF-8 stuff is new to me at least, we initially implemented not regenerating the default of en_US.UTF-8 if it was present in the /etc/default/locale file;  that value is unset in images today, despite en_US.UTF-8 locale being generated and in the locale-archive file
[18:21] <slangasek> rharper: fwiw there was a mail thread about this back end of May that you were cc:ed on where I said C.UTF-8 was the right default for future releases
[18:22] <rharper> so, one fix is to have the image set LANG="en_US.UTF-8" in /etc/default/locale; that'll work with cloud-init trunk in artful;  if we want to switch to defaulting to C.UTF-8 (which sounds fine to me); I wanted to know how to generate C.UTF-8 (turns out you dont' need to);  We can make further changes to cloud-init to not call locale-gen/update-locale if we;ure using C.UTF-8;  but was worried that if someone at runtime
[18:22] <rharper> were to run either of those tools with LANG=C.UTF-8 in /etc/default/locale; if that would complain
[18:22] <slangasek> rharper: so we need an image change to set up /etc/default/locale to a correct default
[18:23] <slangasek> is the behavior sane when the locale-gen and update-locale commands are absent?  (minimal images)
[18:24] <rharper> behavior of what? cloud-init?  currently none of the images set a value in /etc/default/locale; and cloud-init still defaults to en_US.UTF-8 (as of today, I'm working on a C.UTF-8 branch now)
[18:24] <rharper> if the images switch to setting C.UTF-8 in /etc/default/locale, and I land the C.UTF-8 cloud-init branch, it will skip calling locale-gen/update-locale
[18:25] <rharper> and it sounds like, in our path where we'd want to regenerate, we'd never attempt to call locale-regen/update-locale if the LANG value was C.UTF-8, since it's not something that can be regenerated
[18:25] <slangasek> rharper: behavior of cloud-init.  Minimal images won't have the locales package installed; they don't currently set LANG=C.UTF-8 in /etc/default/locale but they should; if we do those things (including for minimal images on xenial), will cloud-init behave sanely?
[18:26] <rharper> slangasek: we'll need the current branch I'm working on to land for C.UTF-8 support;
[18:26] <rharper> I should have that up today as I now understand more about C.UTF-8 w.r.t regeneration (or the lack of a need to do so)
[18:27] <rharper> slangasek: it does seem odd though that, I cant say 'update-local --locale-file=/etc/default/local LANG=C.UTF-8'  ; is there a reason why that shouldn't work ?
[18:28] <slangasek> rharper: this is literally the first time I have ever heard of the update-locale command
[18:28] <rharper> hehe, me too
[18:37] <rharper> I guess we can pass --no-checks
[18:37] <rharper> that seems reasonable; though I still feel like if it's a valid LANG setting, the tool's check should accept it
[18:37] <rharper> slangasek: is that worth a bug ?
[18:38] <slangasek> rharper: yes, I think so
[18:38] <rharper> ok
[18:38] <rharper> thanks for the help
[18:59] <ahasenack> acheronuk: hi, around?
[19:31] <ahasenack> LocutusOfBorg: hi,
[19:31] <ahasenack> LocutusOfBorg: I caught wind of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868473
[19:31] <ubottu> Debian bug 868473 in dh-acc "dh-acc: Incorrect usage of doit (Dh_Lib)" [Serious,Open]
[19:32] <ahasenack> LocutusOfBorg: there is a dep8 test in qca2 that uses dh_acc, and which fails now because of the warning that dh_acc is sending to stderr
[19:32] <ahasenack> LocutusOfBorg: http://pastebin.ubuntu.com/25327602/
[19:33] <ahasenack> LocutusOfBorg: you seem to have a patch, is it landing soon?
[19:33] <ahasenack> the trail is that my cyrus-sasl2 upload to artful is blocked on that qca2 test failure, and on a kdepim-runtime build failure
[19:45] <ahasenack> hm, looks like a new abi-compliance-checker that is in proposed fixes it
[19:45] <ahasenack> "test in progress"
[19:45]  * ahasenack checks again tomorrow
[19:51] <tsimonq2> rbasak: Ping, I don't know if you're in a US or UK timezone ;)
[19:56] <ahasenack> uk
[19:56] <tsimonq2> ack
[21:25] <LocutusOfBorg> ahasenack, exaactly, proposed is the fix
[21:25] <ahasenack> nice, thanks
[22:11] <nacc> ahasenack: i can rerun your dep8 test with the appropriate srcpkg(s) from -proposed
[22:11] <nacc> ahasenack: if you tell me which ones
[22:15] <acheronuk> LocutusOfBorg: well, unless someone ignore those libkf5eventviews/4:16.12.3-0ubuntu1 and libkf5calendarsupport/4:16.12.3-0ubuntu1, then it will never get our of -proposed
[22:15] <acheronuk> those tests should never run. it's only a bug or glitch in britney that they are
[22:37] <acheronuk> ok. those are overridden now. if the armhf tests will just complete, might have a chance of fixed abi-compliance-checker making it to -release
[23:15] <Unit193> nacc: Hiya!
[23:15] <nacc> Unit193: hey, let me spin a chroot as promised :)
[23:16] <Unit193> No rush, but just wondered.  Danke.
[23:38] <nacc> Unit193: what error do you get?
[23:51] <Unit193> http://paste.openstack.org/show/cGj8uRFD3nm0PKN3D9T8/
[23:53] <nacc> Unit193: what was the cmdline for that?
[23:53] <Unit193> Basically: debootstrap --arch=i386 --include=apt --arch i386 --variant=buildd --force-check-gpg --keyring=/usr/share/keyrings/ubuntu-archive-keyring.gpg artful /var/cache/pbuilder/build/6390
[23:58] <Unit193> nacc: I'm not sure if I should be annoyed or happy, it appears to be working now...
[23:58] <Unit193> Thanks for fixing it!
[23:58] <nacc> heh
[23:58] <Unit193> I'm sorry for wasting your time.
[23:59] <sarnold> it felt a bit like something that 'waiting' would fix, but i'm surprised it fixed so quickly :)
[23:59] <nacc> yeah, i wonder if it was just the gcc-7 transition/mirror latency/etc.
[23:59] <Unit193> sarnold: I thought so too, but hit it sometime before Aug 13.
[23:59] <nacc> glad it works now, regardless