[05:00] <alkisg> Hello, ppa:ts.sch.gr was given the ability to build armhf, thanks for that.
[05:00] <alkisg> I'm getting build-time segmentation faults in that architecture though, while the others work fine, and while the ports.ubuntu.com builds (of ltsp) are fine
[05:00] <alkisg> Example: https://launchpad.net/~ts.sch.gr/+archive/ubuntu/proposed/+sourcepub/5526518/+listing-archive-extra
[05:01] <alkisg> msgmerge -U se.po ltsp.pot qemu: uncaught target signal 11 (Segmentation fault) - core dumped make[2]: *** [se.po] Segmentation fault (core dumped)
[05:01] <alkisg> I've tried it in a qemu chroot and it works fine... how could I troubleshoot that further? Is it possible that somehow it's an issue with launchpad?
[05:03] <alkisg> It's not possible to get ssh access to troubleshoot it there, is it?
[05:17] <alkisg> Ah. Oh. Test case in qemu:
[05:17] <alkisg> while true; do msgmerge -U da.po ltsp.pot; done
[05:17] <alkisg> 20 times it says: ................................... done.
[05:17] <alkisg> One time it says: qemu: uncaught target signal 11 (Segmentation fault) - core dumped
[05:17] <alkisg> Lovely...
[05:18]  * alkisg tries to put msgmerge in a "try-it-5-times-in-case-it-segfaults" loop...
[05:22] <alkisg> https://bugs.launchpad.net/qemu/+bug/668799
[05:22] <ubot5> Launchpad bug 668799 in Linaro QEMU "qemu-arm segfaults executing msgmerge (gettext)" [Undecided,Fix released]
[05:29] <alkisg> while true; do taskset -c 0 msgmerge -U da.po ltsp.pot; done
[05:29] <alkisg> This works fine
[05:30] <alkisg> Guys, since it's a known problem with qemu/multithreaded apps, and it's not related to the builds that we sent to armhf builds in launchpad,
[05:30] <alkisg> would it be possible to specify that all armhf builds are executed on a single core?
[05:56] <wgrant> alkisg: It's not that simple, unfortunately.
[05:56] <wgrant> qemu-user doesn't like multithreaded code much, even if it's running on a single core.
[05:57] <wgrant> There's no workaround other than doing less threading.
[05:57] <wgrant> Last week we started testing real virtualised armhf and arm64 builds, but there are some kernel bugs we need to work through before that's rolled out onto production.
[05:58] <alkisg> I've sent a test build where I changed Makefile to call `taskset -c 0 msgfmt` etc. But I would like to find a better place for it then in the upstream code, as it's temporary and specific to launchpad builds
[05:59] <alkisg> (local qemu builds work for me with that small change)
[06:01] <wgrant> Oh, does that actually work around it? I'm surprised it's reliable.
[06:01] <wgrant> But we can't easily limit builds to a single core, so it's best that you do that in your packaging.
[06:03] <alkisg> wgrant: do you think that this issue will be solved with the new virtualized infrastructure, in e.g. a few months? If so, I could just fork the packaging for those months, instead of trying to get it to debian...
[06:05] <wgrant> alkisg: Yes, it will definitely be solved when we stop using qemu-user.
[06:05] <alkisg> Thanks a lot wgrant :)
[06:12] <alkisg> Ouch, it's only a little better now with taskset, it succeeds in half of the builds...
[06:13]  * alkisg will just remove msgfmt/msgunfmt from the armhf builds...
[06:21] <wgrant> Yeah, I didn't think that'd be a reliable fix :(
=== alkisg is now known as work_alkisg
=== cmars` is now known as cmars
=== BradCrittenden is now known as Guest53960
=== nickoe_ is now known as nickoe
[17:03] <malenki> anyone knows if I can add a comment to a certain string at https://translations.launchpad.net/?
[17:04] <dobey> malenki: you mean as a developer of a project?
[17:05] <malenki> no. as translator to a string of the translation
[17:07] <dobey> no, i don't think there is any way to comment on the translations themselves
[17:08] <malenki> a pity
[17:09] <malenki> though thanks for the reply
[17:18] <dobey> you can contact whomever made the suggested translation, if you really need to
[17:25] <malenki> dobey, sure
[17:25] <malenki> it would be just useful to comment "this string is refers to xy doing 123" to avoid further mis-translations
[17:26] <malenki> .po (the format launchpad exports translations to) itself supports comments
[17:27] <pipedream> https://answers.launchpad.net/launchpad/+question/272609 need more space in PPA
[17:27] <dobey> yes
[17:27] <pipedream> cool!
[17:27] <pipedream> that was quick
[17:27] <pipedream> (kidding)
[17:27] <dobey> malenki: then the upstream code needs a comment in the source, for that translation
[17:27] <dobey> malenki: so suggest filing a bug with a patch to add it
[17:28] <malenki> dobey, not every translator will look into the source code
[17:28] <malenki> (i'd assume only a small percentage)
[17:28] <dobey> malenki: the comments in the .po files come from the source code
[17:28] <dobey> malenki: they get displayed on launchpad if they exist
[17:28] <dobey> that's how gettext works.
[17:40] <malenki> dobey, i found https://blueprints.launchpad.net/launchpad/+spec/suggestion-approve-rejection-explanation
[17:40] <malenki> but i cannot find if this got implemented and if, how to use it
[17:41] <cjwatson> It wasn't; you can see the open bugs linked to that.
[17:41] <cjwatson> Some of Launchpad's oldest open bugs, in fact.
[17:41] <malenki> awesome
[17:41] <malenki> 10 years celebtraion, anyone? :
[17:41] <malenki> ~;P
[17:43] <cjwatson> It's absolutely a bug, but there are only three of us working on LP at the moment and only one with much experience of the Translations component, so I'm afraid it's unlikely to be done soon.
[17:44] <mgz> random love: needed misc git branch hosting on sunday, remembered I could use launchpad, and it was all super-easy
[17:45] <cjwatson> Glad something's working to people's satisfaction :-)
[17:45] <malenki> cjwatson, thats sad. i commented on #211
[19:00] <pipedream> 2