Unit193nacc: If it helps, I pasted the log from pbuilder a few days ago, and unstable chroots work.00:01
naccUnit193: ok, good to know00:02
=== maclin1 is now known as maclin
cpaelzerstill trying to wrap my head around this bug did we cahnge the default pic/pie behaviour with a recent (maybe gcc) update?06:58
cpaelzerI see some fallout due to "-fPIE -pie" being dropped and replaced by "-specs=/usr/share/dpkg/no-pie-compile.specs"06:59
cpaelzerat least that is how it seems so far, still debugging06:59
cpaelzeror any changes to what hardening=+all does maybe06:59
cpaelzerI thought that the move was still towards pie07:03
cpaelzermaybe this package drives dpkg/debhelper nuts t generate the wrong options07:04
=== maclin1 is now known as maclin
cpaelzerok down to two things "DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags --get CFLAGS" really looses -fPIE07:32
cpaelzermaybe assumed to be default without stated now?07:32
cpaelzerthe other thing seems package specific and more debuggin07:32
infinitycpaelzer: Yes, -fPIE is default on all arches.  It's not "losing" PIE.08:02
cpaelzerthought so08:06
cpaelzeronly the explicit arg is lost which was a red herring for a bit08:06
cpaelzerI found the issue deeper down due to no-pie-compile.specs now generated by hardening=+all,-pie08:06
cpaelzerin my case package A (net-snmp) sets -pie and pakage B (nut) collects the build options of A for plugin builds08:07
cpaelzerbut they fail as they pass CFLAGs to all builds, but LDFLAGs only to some08:07
infinitycpaelzer: Ahh, yes.  CFLAGS and LDFLAGS both need to be pulled from dpkg-buildflags if you're doing one.08:08
cpaelzerleading to binaries with no-pie-compile.specs but subsequent links without "no-pie-link.specs"08:08
infinitycpaelzer: Mismatching them will lead to a very bad time.08:08
cpaelzerexactly that I'm in08:08
cpaelzerneed 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 different08:09
cpaelzerIMHO it was "wrong" all the time just not breaking anything yet08:09
cpaelzerinfinity: you'll love this quote "In any case, CFLAGS are only -I options, so there is no harm"08:09
cpaelzerfrom the broken makefile :-)08:09
infinitycpaelzer: 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:10
infinitycpaelzer: 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
infinitycpaelzer: So I don't mind educating people when they mess it up.  The real annoyance is when they argue. :P08:11
=== maclin1 is now known as maclin
ginggstsimonq2: f.y.i. nodejs 6.11.2 is now in debian unstable and can be merged08:33
tsimonq2ginggs: ack08:35
tsimonq2ginggs: I'll have a patch for you as soon as I can, I need a sponsor ;)08:37
ginggstsimonq2: i tested a merge of 6.10.2 some weeks ago in my PPA, if it helps - i'll happy to sponsor!08:41
tsimonq2ginggs: Ok :D08:46
tsimonq2ginggs: Let's see how the build goes: https://launchpad.net/~tsimonq2/+archive/ubuntu/universe-upload-testing/+packages08:49
cpaelzercan building with gcc7 affect the c++ symbols exported?09:02
cpaelzerI guess so09:02
cpaelzerbut they are so unreadable ...09:02
=== maclin1 is now known as maclin
tsimonq2cpaelzer: Yep, sometimes there's optional templinst symbols that either appear or go "MISSING"09:07
tsimonq2cpaelzer: Also, c++filt ftw09:07
cpaelzeryeah it already has a few templinst09:08
cpaelzermight just be more now or some not yet tracked09:08
cpaelzerOTOH what broufht me to look were the missing symbols as it broke the check09:08
cpaelzerand reading/checking if that might be an issue is next to impossible with the names they have09:10
cpaelzernewer came by c++filt09:10
cpaelzerneed to take a look09:10
cpaelzerah yeah looks good09:12
cpaelzerthanks tsimonq209:12
=== lexruee__ is now known as lexruee
tsimonq2cpaelzer: You're welcome, let me know if you need any assistance with symbols mangling (I've learned quite a bit from Qt packaging) :)09:13
cpaelzertsimonq2: to me it appears they are rather trimmed than mangled-names - what do you think? http://paste.ubuntu.com/25324531/09:15
cpaelzerat 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
cpaelzerbut I'd loke to prove09:16
tsimonq2cpaelzer: Could you get a paste of the new ones?09:17
cpaelzeralready preparing09:17
cpaelzerthose can at least be demangled - let me try the tool you recommended09:17
cpaelzeroh yeah09:17
cpaelzerthat seems to match09:17
cpaelzerneed to this more than with eyes on console now09:18
cpaelzerplease let me know what you think tsimonq2 if that seems odd to you09:18
tsimonq2cpaelzer: Yeah it does seem to match pretty well09:20
cpaelzerwell then let me fix that and make them replace the old ones in-place09:22
cpaelzerthanks for your hint on c++filt09:22
cpaelzerthat serves well as "prove" on the reason of the change09:22
tsimonq2cpaelzer: I have this bookmarked and it might help in general with symbols :) https://pkg-kde.alioth.debian.org/symbolfiles.html09:23
cpaelzerI think I read that in the past when I had fun in dpdk with that09:23
tsimonq2yw :)09:23
=== zyga-ubu1tu is now known as zyga-ubuntu
cpaelzerslangasek: I saw your collectd upload broke on something around dpdk - let this be my problem, I'll ping you with a solution10:23
ginggstsimonq2: for nodejs i think you might need debian/patches/fix_sslv3_test.patch from my PPA11:12
LocutusOfBorgacheronuk, do you plan to have a look at qtwebkit-opensource-src on i386/armhf?11:31
LocutusOfBorgsome symbols sadness11:31
LocutusOfBorgI can do it, but I think I'll just make things worse, since I don't know how to deal with them :)11:31
acheronukKDE 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 think11:33
LocutusOfBorgtsimonq2, is asleep :)11:34
LocutusOfBorgI 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-prone11:34
acheronukbah. so much for his 'sleep is for the weak' :P11:35
acheronukI guess still this? https://pkg-kde.alioth.debian.org/symbolfiles.html11:36
acheronuk26 MB build log is killing my browser!11:40
LocutusOfBorgacheronuk, you can wget and tail -n 200 after gunzip11:45
LocutusOfBorgor I can give you the two patches11:45
LocutusOfBorgI'm trying the command right now11:46
LocutusOfBorglets see11:46
acheronukI'd rather not touch it myself and wait a few hrs11:47
acheronukbut if you think your result looks sane, then fair enough11:48
LocutusOfBorgpkgkde-symbolshelper patch -p libqt5webkit5 -v 5.9.1 < ../buildlog_ubuntu-artful-armhf.qtwebkit-opensource-src_5.9.1+dfsg-2_BUILDING.txt11:48
LocutusOfBorgthis fails11:48
LocutusOfBorgfails in applying patches11:48
acheronukI normally grab all the logs, even the passes and they help11:49
LocutusOfBorgI'll try the old fashioned manual way instead11:50
acheronukthen do 'pkgkde-symbolshelper batchpatch -v 5.9.1 ../buildlog_ubuntu-artful*'11:50
LocutusOfBorgah ok11:51
acheronukwhich compares and confirms, and makes exceptions etc on some arches, based on what happened overall11:51
acheronukbut think I only tried with Qt once ever11:51
acheronukwhich has some extra stuff for marking private symbols at the least11:52
=== freyes__ is now known as freyes
* acheronuk is away for now11:55
LocutusOfBorgtsimonq2, please do it, I'm lost12:02
cpaelzerslangasek: I have a working fix complete, will report upstream and provide you with a debdiff so you can upload this fix to artful12:03
cpaelzerslangasek: I don't want to mess with your "potential" uploads you have in queue for that but I don't know of12:03
cpaelzerslangasek: just need to report and polish the patch headers to be correct12:03
cpaelzerslangasek: bug 1711120 is ready for you to pick the debdiff from if you agree with the solution12:45
ubottubug 1711120 in collectd (Ubuntu) "dpdk subset fails to configure correctly on i386" [High,Triaged] https://launchpad.net/bugs/171112012:45
xnoxbdmurray, 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
xnoxbdmurray, or e.g. i could go easier route and make qt4 gui or some such pull in fcaitx as a recomends.12:46
bdmurrayxnox: I think language-selector-gnome puts a file somewhere so update-notifier notifies you about the incomplete support14:43
powersjrbasak: nacc: when I run `apt show <package>` should the "Supported" field on an LTS always say 5y?15:11
powersjwoops lol15:11
naccpowersj: LP: #157467015:12
ubottuLaunchpad bug 1574670 in update-manager (Ubuntu Xenial) "ubuntu-support-status returns inaccurate information" [High,Confirmed] https://launchpad.net/bugs/157467015:12
naccpowersj: for context, if i had to guess15:12
naccslangasek: --^ is someone from foundations working that?15:13
powersjnacc: yeah someone filed LP: #1710721 looks to be similar15:14
ubottuLaunchpad bug 1710721 in libsdl1.2 (Ubuntu) "This packages have the wrong timeframe set for the xenial LTS release" [Undecided,New] https://launchpad.net/bugs/171072115:14
naccpowersj: yeah, i'd dupe it15:18
rharperslangasek: 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, bu15:19
rharpert it doesn't15:19
xnoxbdmurray, ack! thanks.15:31
slangasekcpaelzer: 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:33
slangaseknacc: ubuntu-support-status returns inaccurate information because the metadata in the archive is incorrect; this is on infinity to solve15:36
cpaelzerslangasek: yes collectd upstream15:37
cpaelzerslangasek: the issue is in the branch15:37
slangasekrharper: 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 forward15:37
cpaelzerI'll make a note to check build and migration in a-p tomorrow15:37
rharperslangasek: yes, and shouldn't /etc/default/locale  have LANG=C.UTF-8 or is that not the right thing to do ?15:38
rharperI do see that locale -a shows C.UTF-8 ; so we can always check for that;15:38
slangasekrharper: we do need to somewhere select C.UTF-8 as the runtime locale, yes15:39
slangasekrharper: /etc/default/locale is an appropriate place for it15:39
rharperIIUC, the locale-gen tooling would never generate a C.UTF-8 (it's part of glibc , i think) ?15:39
naccslangasek: ok, are you ok if i put that comment in the bug?15:41
slangaseknacc: I'm certainly ok with it, it's not me you're pointing the finger at ;)15:50
naccinfinity: --^ :)15:51
naccslangasek: ack15:51
ricotzhello, is there any chance to force firefox to the artful release pocket? https://launchpad.net/ubuntu/+source/firefox/54.0+build3-0ubuntu116:09
naccricotz: well, it failed to build on a few archs, it seems like?16:12
naccchrisccoulson: --^ I assume is looking into it16:12
ricotznacc, I know, and no, he is not looking into it16:13
naccricotz: i see16:13
naccricotz: is it a rustc issue?16:14
ricotznacc, no16:15
ricotzseveral buildsystem and (smaller) source issues16:15
ricotzI am hoping firefox 56 will be in a better shape16:15
chrisccoulsonit's the armhf failure that stops it from migrating. The other architectures aren't blocking it16:15
naccchrisccoulson: ah ok16:15
naccchrisccoulson: ah yes, i see that now16:15
ricotzchrisccoulson, is this already a webrtc failure there?16:16
chrisccoulsonIt's blocked on arm because it just crashes at startup, which causes the startup cache compilation to fail16:16
naccheh, that message isn't too helpful16:16
naccmozpack.errors.ErrorMessage: Error: Error while running startup cache precompilation16:16
chrisccoulsonFirefox 55 doesn't build a startup cache, so it builds ok now. But it still crashes at startup16:16
ricotzchrisccoulson, still force it into release16:18
ricotzI guess having 50.1.0 on the iso is quite something16:19
seb128ricotz, try arguing with infinity that having firefox outdated is a bigger issue than not having it working on armhf16:20
seb128I tried that before16:20
seb128he seems to disagree, so somebody needs to eventually fix firefox16:20
ricotzwe can deal with those failures again with 55 / 5616:20
seb128as I said I'm not the one to convince16:21
ricotzseb128, you pinged him already ;)16:25
seb128ricotz, right, and you think that's going to be enough to convince him? ;-)16:25
ricotzat least to read16:25
seb128yeah, let's see16:25
* rbalint looking for sponsor for LP: #170972616:37
ubottuLaunchpad bug 1709726 in akonadi (Ubuntu) "Breaks reverse build-dependencies by embedding build-time std exception header path" [Undecided,Confirmed] https://launchpad.net/bugs/170972616:37
LocutusOfBorgrbalint, thanks!16:43
cpaelzerslangasek: collectd complete, thanks for the upload17:40
cpaelzerslangasek: and on your Deb question - my co-maintainer on dpdk is watching the PR17:40
cpaelzerslangasek: 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 now17:40
slangasekcpaelzer: excellent17:40
rharperslangasek: 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-gen17:42
* tsimonq2 stretches18:01
tsimonq2LocutusOfBorg: ack, will do18:01
slangasekrharper: ah, I thought cloud-init was being fixed to not regenerate already-present locales?18:07
slangasekrharper: locale-gen doesn't support generating C.UTF-8 because it's always shipped in the glibc package18:07
rharperslangasek: 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) ?18:17
=== tkamppeter_ is now known as tkamppeter
rharperslangasek: 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
slangasekrharper: 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 trying18:18
rharperslangasek: 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 file18:20
slangasekrharper: 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 releases18:21
rharperso, 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 runtime18:22
rharperwere to run either of those tools with LANG=C.UTF-8 in /etc/default/locale; if that would complain18:22
slangasekrharper: so we need an image change to set up /etc/default/locale to a correct default18:22
slangasekis the behavior sane when the locale-gen and update-locale commands are absent?  (minimal images)18:23
rharperbehavior 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
rharperif 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-locale18:24
rharperand 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 regenerated18:25
slangasekrharper: 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:25
rharperslangasek: we'll need the current branch I'm working on to land for C.UTF-8 support;18:26
rharperI 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:26
rharperslangasek: 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:27
slangasekrharper: this is literally the first time I have ever heard of the update-locale command18:28
rharperhehe, me too18:28
rharperI guess we can pass --no-checks18:37
rharperthat seems reasonable; though I still feel like if it's a valid LANG setting, the tool's check should accept it18:37
rharperslangasek: is that worth a bug ?18:37
slangasekrharper: yes, I think so18:38
rharperthanks for the help18:38
ahasenackacheronuk: hi, around?18:59
ahasenackLocutusOfBorg: hi,19:31
ahasenackLocutusOfBorg: I caught wind of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=86847319:31
ubottuDebian bug 868473 in dh-acc "dh-acc: Incorrect usage of doit (Dh_Lib)" [Serious,Open]19:31
ahasenackLocutusOfBorg: 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 stderr19:32
ahasenackLocutusOfBorg: http://pastebin.ubuntu.com/25327602/19:32
ahasenackLocutusOfBorg: you seem to have a patch, is it landing soon?19:33
ahasenackthe trail is that my cyrus-sasl2 upload to artful is blocked on that qca2 test failure, and on a kdepim-runtime build failure19:33
ahasenackhm, looks like a new abi-compliance-checker that is in proposed fixes it19:45
ahasenack"test in progress"19:45
* ahasenack checks again tomorrow19:45
tsimonq2rbasak: Ping, I don't know if you're in a US or UK timezone ;)19:51
LocutusOfBorgahasenack, exaactly, proposed is the fix21:25
ahasenacknice, thanks21:25
naccahasenack: i can rerun your dep8 test with the appropriate srcpkg(s) from -proposed22:11
naccahasenack: if you tell me which ones22:11
acheronukLocutusOfBorg: 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 -proposed22:15
acheronukthose tests should never run. it's only a bug or glitch in britney that they are22:15
acheronukok. those are overridden now. if the armhf tests will just complete, might have a chance of fixed abi-compliance-checker making it to -release22:37
Unit193nacc: Hiya!23:15
naccUnit193: hey, let me spin a chroot as promised :)23:15
Unit193No rush, but just wondered.  Danke.23:16
naccUnit193: what error do you get?23:38
naccUnit193: what was the cmdline for that?23:53
Unit193Basically: 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/639023:53
Unit193nacc: I'm not sure if I should be annoyed or happy, it appears to be working now...23:58
Unit193Thanks for fixing it!23:58
Unit193I'm sorry for wasting your time.23:58
sarnoldit felt a bit like something that 'waiting' would fix, but i'm surprised it fixed so quickly :)23:59
naccyeah, i wonder if it was just the gcc-7 transition/mirror latency/etc.23:59
Unit193sarnold: I thought so too, but hit it sometime before Aug 13.23:59
naccglad it works now, regardless23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!