[00:14] ximion, what's the ubuntu package / project that generates the dep11 data? Trying to assign bug 1626494 to the correct place [00:14] bug 1626494 in gnome-software (Ubuntu) "Some app screenshots wrongly stretched in Ubuntu version of Gnome Software" [Undecided,Confirmed] https://launchpad.net/bugs/1626494 [00:28] robert_ancell: previously appstream-dep11, but soon it will be appstream-generator [00:29] assign to appstream-generator, if the bug is fixed in asgen already, we can close it as soon as it is deployed at Ubuntu [00:29] ximion, ok [00:29] robert_ancell: jap, that bug is indeed fixed [00:29] or rather, has never been present in asgen :P [00:30] so we just need Laney to flip the switch and make the new data available - I hope this will happen for Yakkety, still [00:30] ximion, will this happen in Xenial? [00:30] I've assigned to both, so we know which one has the issue [00:33] robert_ancell: unfortunately we can't update the frozen metadata in Xenial properly :( [00:34] ximion, why not? [00:34] since the image sizes are encoded in the AppStream metadata which is frozen, updating the image alone won't help [00:34] robert_ancell: would require uploading new data into the Xenial suite and re-signing the InRelease file [00:34] ximion, why is the metadata frozen? Doesn't it need to be updated if you SRU something? [00:35] robert_ancell: jup, then it will be updated for that particular SRU [00:35] so we would need to make a dummy upload of that package to fix the issue [00:35] which is pretty dumb [00:35] surely we can trigger an update of the whole file [01:39] robert_ancell: doesn't help if the archive won't sign the file... [01:39] would be awesome to get an exception for that [01:40] all alternative solutions are basically hacks [01:40] I'll ask around [01:40] one could make an override file for the -updates suites, but that would then mix data from the base suite with new data in a very unclean way [01:41] one could also package the updated files in a .deb package as an update [01:42] that would probably be not very invasive [01:42] also a hack, but maybe the best one after updating the file directly [05:04] Good morning === hikiko is now known as hikiko|off [07:52] o/ [07:53] 'lo willcooke [07:54] evening duflu, how goes? [07:54] willcooke: Afternoon. Goes OK. You? [07:56] oh, it's still afternoon for you? [07:56] Australia is a big place :) [07:57] willcooke: Yes, sorry. This side is basically asia [07:57] :)) [08:02] hello [08:10] how do Laney [08:11] hey willcooke [08:12] bit of a chill today [08:12] Verily [08:13] I thought about busting out the ol tog rated socks [08:13] String vest here [08:14] what, what? Whining about the weather, what a terribly British thing to do [08:14] hey willcooke Laney duflu [08:14] Morning seb128 [08:14] tally-ho pip pip and all that [08:14] OH and I got a new fiver last night for the first time [08:14] which is exciting [08:14] tried to destroy it of course [08:15] hi davmor2 and seb128 and duflu :-) [08:15] happy friday [08:15] * duflu is reminded he hasn't seen a new AU fiver yet [08:15] Laney: use fire [08:15] Laney, the plastic ones? [08:15] happy friday indeed! [08:15] Laney: Morning and Happy Friday to you too [08:16] seb128: https://www.thenewfiver.co.uk/ [08:16] what a website [08:17] that's money well spent [08:17] why would you need to advertize your currency?! [08:17] it's not like people were ponding not using money [08:18] well it did make me shed some patriotic tears [08:18] haha [08:19] I should check if any of them are in the first batch [08:19] you can sell those ones for £200 [08:20] over 5k notes have been chewed or eaten in 2015, people are weird [08:21] website is nice but I don't like much how the image don't slide with the content but get replaced [08:21] can't pinpoint it but it feels weird [08:26] I like the side-on view especially [09:13] hey seb128, Laney, and willcooke! [09:13] hey pitti [09:13] hey pitti, happy friday! [09:13] pitti in getting up late shocker [09:13] pitti, did cyphermox speak to you about https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1626108 [09:14] Ubuntu bug 1626108 in Ubuntu CD Images "Ubiquity session isn't setting up 3rd party hardware drivers" [Undecided,Fix released] [09:14] seb128: bon vendredi ! [09:14] Laney: well, I said good morning at 6:45 :) [09:14] I just didn't pay attention to IRC the last hour [09:14] /at 06:45 /say hello [09:14] :P [09:14] how are you? [09:15] slightly more relaxed now; yesterday was madness [09:15] lots of fun with linux 4.8, scalingstack network/image failure etc. [09:15] you meant you went to bed at 6:45? [09:15] that was a short night [09:15] ;-) [09:16] I had a beer and a grappa yesterday evening at our favourite Italian, I needed that :) [09:16] haha [09:16] do you have any plan for the w.e already? [09:17] seb128: yes, indeed -- I'm in a train to Berlin now [09:17] 85th birthday of Annett's grandma tomorrow (near Berlin), then go to larsu and go to systemd.conf next week [09:17] ah, you second office ;-) [09:17] nice [09:17] give a hug to Lars for me! [09:17] le bureau roulant ! [09:18] * larsu waves [09:18] ah, larsuland! [09:18] it is a good land [09:19] * larsu agrees [09:19] go for some peanut sauce [09:19] hey larsu ;-) [09:19] hi seb128! ça ca? [09:19] *va [09:19] 'sup Laney? [09:19] Laney, if you like peanut sauce you should get kip sate in octobre in denhaag [09:19] larsu, oui, et toi ? [09:19] Laney: will remember, although not a peanut fan [09:19] larsu, holidays tonight for me :-) [09:20] seb128: nickel! Looking forward to having pitti around next week [09:20] *beam* [09:21] he's a good guest, I can recommend him ;-) [09:21] seb128 made me run, wash the dishes, work from 4 am to 12 pm, and drink coffee! [09:22] * pitti hugs seb128, it was great to visit you! [09:22] pitti: ok, leave that out and just have the falafel then :P [09:22] seb128: looking forward to you taking us to all the best places [09:22] oooooooh you should choose the team dinner venue [09:22] lol [09:23] * seb128 hugs pitti back [09:23] Laney, I can do that :-) [09:23] larsu: not much, ribs still hurt a bit from surfing :-o [09:23] got some couchsurfers coming tonight [09:24] Laney: not sure if that's bad because your ribs hurt or good because you went surfing ;) [09:24] oh, pitti does dishes? Awesome! [09:24] respect the waves lol === vigo is now known as vigo-afk [09:25] larsu, you need to feed him icecream though otherwise he's not working as well [09:25] seb128: that's really not going to be a problem... [09:25] *really* [09:26] :-) [09:28] c'est toujours l'heure de la glace ! *yummy* [09:28] mais maintenant c'est l'heure de système D [09:29] *giggle* [09:30] tjaalton, hey, do you know if anything changed with xorg keyboard layout handling in yakkety? [09:30] livecd has no layout showing configured at all [09:30] on xenial it has fr and us when picking french locale [09:30] pitti, ^ or maybe you know, unsure how much is coming from lower stack/console setup/systemd [09:33] qengho, chrisccoulson, willcooke, so we got chromium/firefox/libreoffice updates out, are we missing anything to desactivate the old google api key and switch to the new ones? [09:33] seb128, aiui, just waiting a little while to make sure "everyone" has switched [09:33] willcooke, well, the key is over the quota and is not working, what difference does it make whether they switched or not? [09:34] good call [09:34] :-) [09:34] we are in a situation where it works for nobody [09:34] if we switch it's going to work for those who upgraded [09:34] which is an improvement whatever the number of upgraders is [09:44] [09:45] pitti, good catch finding that it has to do with systemd user session [09:45] now to know what bits it doesn't like... [09:45] it's not the indicator since that's an optional part and just display the status it doesn't do the session config [09:45] when I disable the systmed user session in Xsession.d/00upstart, then gsettings shows de and us again [09:45] so maybe ibus or unity-settings-daemon [09:45] thanks for figuring that out [09:45] the "de" should come from /etc/default/keyboard [09:46] I'm going to file a bug after lunch and try to poke a bit more to it [09:46] not sure where the "us" comes from, that's always there apparently [09:46] yes [09:46] it's there because it's needed for e.g ctrl-C/X/V to work in any layout [09:46] so u-s-d always add it [09:47] I should make sure to log bugs and tag them this afternoon [09:49] but lunch first, bbiab [09:54] seb128, willcooke, switching it also breaks other APIs which currently aren't over the quota (eg, safebrowsing is the one that immediately springs to mind) [09:54] Although it's probably ok to switch now [10:09] seb128: yeah it's somewhere else [10:11] I should probably upload firefox to yakket [10:11] yakkety, even [10:14] I see the current firefox 48 in yakkety that built everywhere except for s390 and ppc now fails to build everywhere except for x86 and x86-64 in doko's archive rebuild [10:14] Awesome [10:48] seb128: "well, the key is over the quota and is not working". There are like 30 parts to the API. 1 of them isn't working. [11:48] qengho, can we limit the use of the key? like say it's not one to be used for geoloc? or is everything or nothing? [11:49] qengho, also what are the users out of firefox/chromium/libreoffice which got updated to use the new one? [11:50] seb128: that's a really good question about limits. I don't know if the capabilities apply to a single key or to the org. I'll find out. [11:50] seb128: I don't understand your second question. [11:52] qengho, we updated firefox/chromium/libreoffice to use the new key, is there anything else that needs updated? or what's the factor now to not transition over? with chromium/firefox security updates out with the new key I expect most of our users are transitionning to those ... do we have numbers/graphs about the number of requests from the new ones? [11:55] seb128: Nothing else needs updating except the program of whoever is abusing our key. Ha ha. [11:55] well at least we have different keys now... [11:55] qengho, do you have stats on the use of the new ones? [11:56] they are working right? but just have lower quota? [11:56] seb128: We don't have stats per key, because that is disabled in the administration interface. [11:56] I don't know why.^ [11:56] Or how.^ [11:56] do we have anyone we know at google that we can ask? [12:05] seb128: I don't know anyone close to this subject. I'll ask the person I know, if he's back from vacation. [12:05] k [12:05] thanks [12:10] Laney: not sure how you manage to get all these weird bugs ^^ [12:10] did you check if curl had any bugfixes in its DNS code recently? [12:11] nope [12:11] I saw your conversation with robert_ancell [12:12] would be good if you didn't imply it was just a matter of me flicking a switch [12:12] and there is no exception, the release won't be re-published [12:12] imagine it - all xenial users will hit the archive to download the indices over again [12:12] not going to happen [12:14] Laney: jup - I think shipping updated files in a package would be okay though [12:17] maybe [12:17] how would that work? [12:20] feels like publishing it via -updates could somehow be nice [12:21] s/could somehow/somehow could/ [12:21] * Laney has europeanitis [12:26] ximion: the trace goes down into glibc [12:26] man it feel really unlikely that there are bugs here to me [12:32] and of course it's not as easy as flipping a switch - I don't remember much of yesterday night's conversation, but I also think I mentioned that I hope it will be ready for Yakkety [12:32] yeah [12:32] which hopefully implies that it's not an easy task ^^ [12:33] don't want anyone to get their hopes up there :P [12:33] want to run for a while to see how common these weird crashes are anyway [12:33] having stuff in -updates will be really messy, because we would need to merge data there (old data into SRU data) [12:34] ubuntu@juju-stg-ue-appstream-back-machine-1:/srv/appstream/logs/2016/09$ grep "Segmentation fault" *.log [12:34] jup, the curl one goes deep [12:34] 22_0900.log:Segmentation fault (core dumped) [12:34] 22_1000.log:Segmentation fault (core dumped) [12:34] 22_1600.log:2016-09-22 16:08:14 - INFO: Completed procSegmentation fault (core dumped) [12:34] 23_0100.log:Segmentation fault (core dumped) [12:34] 23_0900.log:2016-09-2Segmentation fault (core dumped) [12:34] 23_1000.log:Segmentation fault (core dumped) [12:34] oh sh* [12:34] 23_1025.log:Segmentation fault (core dumped) [12:35] looks like we need to fix this [12:35] no results between 0100 and 0900 because it hung at 0200 [12:35] ;-) [12:42] hello people, and happy friday! [12:43] hey desrt, happy friday to you! [12:43] hi desrt! [12:43] * desrt is getting pumped for the weekend [12:43] via lux! [12:44] my first toronto anomaly [12:45] * seb128 is trying to understand what desrt is saying [12:45] thought you uninstalled that [12:45] for 2 days [12:45] just long enough to ensure that my streak was broken :) [12:46] seb128: from time to time (a few times a year) in ingress is some event called 'anomaly' where the rules of the game are changed at a point that is focused in a particular place [12:46] tomorrow, that place is downtown toronto, practically centred on my house [12:46] oh ok [12:46] they pulled that trick out to make you come back! [12:46] which seems to have worked... ;-) [12:47] i never intended to leave for good. i just wanted to break my streak at an event 360 (the top badge tier) to make sure i didn't end up with a sick incentive to continue to 400, ... or 500, ... or ... [12:47] *even 360 [12:47] lol [12:48] "...on the 361st day, Desrt rested." [12:49] uninstalling is a bit of a symbolic gesture and a guard against accidentally opening the app and hacking something... when you mindlessly do something every single day for a year, you get a bit auto-pilot about it [12:49] it's a common tactic in this situation :) === vigo-afk is now known as vigo [13:29] What would cause the temporary non-pinned icons that show on the launcher when you run a program to not show up towards the end but instead showing up as the 3rd icon from the top every time? It just started happening on one of my desktop machines very recently and this without changing anything being pinned on the launcher [13:30] Trevinho, ^ [13:30] odd [13:30] mhmh [13:31] It's not full either, about 75% [13:31] is that xenial? [13:31] yes [13:31] I don't seem to able to influence where those show up from this point either [13:31] it happened in the past because of a race of bamf and unity calls, but this shouldn't happen now [13:32] or.... well... it could be caused by the new "starting" flag [13:32] which... andyrock did. Could be because of that... mhmh [13:32] Trevinho, was that a recent SRU change or released with 16.04? [13:32] ? [13:33] jhodapp: can you open a bug with few steps to reproduce the issue? [13:33] andyrock, well I don't know how to reproduce it, that's part of the problem [13:34] it just started happening [13:34] andyrock, and continues to happen any time I open an app not pinned on the launcher [13:34] which app? any app? [13:34] yes [13:34] any [13:35] did you try to restart unity? [13:35] yup [13:35] 16.04? [13:35] correct [13:35] andyrock, I'd be happy to file a bug with this info if it's good enough [13:36] a screencast of the issue would help too [13:36] andyrock, sure np [13:36] kk [13:36] send me the link when you're done [13:36] andyrock, awesome thanks [13:40] andyrock: one thing I thought it could happen is that... I'm not sure wether we're flagging the starting-icons as seen in unity... But it should be... [13:41] well what's weird is that it's the first time this problem is reported [13:42] andyrock, yeah and I've been running 16.04 on this machine for quite some time but it just all of a sudden started happening [13:50] Laney: well, this is terrible and we need to fix the bug - I have never seen it in Debian, and KDE Neon and elementary and Arch also never reported it [13:51] (so, the hanging thread might be in the langpack code, and something is fishy about the curl downloads of packages) [14:17] ximion: haha [14:17] the hang is in seedContentsData [14:19] Laney: so it is a write issue then [14:19] I hope the NOTLS change didn't break it then... [14:20] (if it did, the LMDB docs lie) [14:22] the Debian extraction runs are crazy slow now... 40min (but for some weird reason it's *always* around 40min, no matter if there were 10 or 30 packages processed) [14:29] did you profile it? [14:30] Laney: I just looked at the log timestamps [14:30] oh, yes I did, but at some time in May, a lot has change dsince then [14:31] timestamps is ok [14:31] package extraction was still the most time-consuming step, followed by any operation onvolving searching icons and then on the third place screenshot downloading [14:31] where's most of the 40 minutes being spent? [14:32] data export... takes 4min [14:32] that isn't right [14:32] https://appstream.debian.org/logs/2016/09/ [14:33] I need to look at this, that is taking too long [14:33] turn on --verbose [14:33] oh, actually, it's rendering HTML there too [14:33] I have this suspicion that it might be doing Translation- stuff too often [14:33] so likely that and parsing all the data is a culprit [14:34] you can logInfo with some ID everytime it does that [14:34] want to see how much it happens in your logs [14:34] (another useless hint everyone else would have thought of got served, by me :P) [14:34] there's already some logDebug there [14:37] Laney: while turning on verbose mode, I noticed that today's run didn't produce a proper log [14:37] the reason is that it crashed [14:37] /o\ [14:37] WHAT HAVE WE DONE! [14:38] I am running https://github.com/ximion/appstream-generator/commit/12ca9be289eb615a73b8372c0e4108609580a341 now [14:38] now, if I just knew the working version that was running before I uploaded the broken one yesterday... [14:39] can't tell what that does [14:39] could somebody try to add a google account through u-c-c -> uoa on yakkety and let me know if the webview goes white for them as well when focussing the textentry? [14:39] yeah, I think the last working version was https://github.com/ximion/appstream-generator/commit/dd87662d7f3dbdfe2dafaad0fcd2223be7a72bd9 [14:40] Laney: so, some commit in the range of be7a72bd9..9580a341 probably did something bad [14:40] seb128: yup [14:40] Laney, it does? [14:41] yes [14:41] Laney, thanks for confirming [14:41] np [14:41] ximion: that TLS thing is the most suspicious isn't it [14:41] can you run under gdb? [14:42] Laney: if I could be sure that it crashes then... The first run this morning at 8:10 succeeded [14:42] the current one at 14:10 didn't [14:42] indeed [14:42] it sometimes works [14:43] * Laney is gdbing [14:43] this stuff is annoying to debug [14:43] the TLS thing indeed is the thing I would place my bets on [14:44] jup - it's highly parallel and also takes a while [14:44] debugging anything threaded is always a pain [14:44] but if we disable threads, it will probably work :P [14:45] in the last log, there is no line telling about a segfault, btw [14:45] the log just ends [14:45] do you put stderr in there? [14:46] exec >> "$LOGFILE" 2>&1 [14:46] mmm [14:47] it ends prematurely though, and the only way that could have happened is by the command crashing [14:47] it didn't execute the run for stretch at all [14:47] so, this was either the OOM killer killing the script instead of asgen, or it crashed and the buffer wasn't written to disk [14:48] OOM would say "Killed" or something and you would see it in dmesg [14:48] unfortunately I have no access to any system logs [14:48] otherwise I would know more already :P [14:48] O_O [14:49] DSA machines are highly restricted [14:49] dmesg works [14:49] [116865.646259] appstream-gener[14057]: segfault at 8 ip 00007fe4d30f5835 sp 00007fc4c63967c0 error 4 in libgio-2.0.so.0.4800.0[7fe4d3082000+181000] [14:49] [138390.878702] appstream-gener[673]: segfault at 8 ip 00007faafe825835 sp 00007f8af1ac67c0 error 4 in libgio-2.0.so.0.4800.0[7faafe7b2000+181000] [14:49] [159892.877074] appstream-gener[18486]: segfault at 8 ip 00007f431c97b835 sp 00007f230fc1c7c0 error 4 in libgio-2.0.so.0.4800.0[7f431c908000+181000] [14:49] indeed! [14:49] mekeel% [14:50] gio... [14:50] [ 204.048422] [sched_delayed] sched: RT throttling activated [14:50] [116865.646259] appstream-gener[14057]: segfault at 8 ip 00007fe4d30f5835 sp 00007fc4c63967c0 error 4 in libgio-2.0.so.0.4800.0[7fe4d3082000+181000] [14:50] [138390.878702] appstream-gener[673]: segfault at 8 ip 00007faafe825835 sp 00007f8af1ac67c0 error 4 in libgio-2.0.so.0.4800.0[7faafe7b2000+181000] [14:50] [159892.877074] appstream-gener[18486]: segfault at 8 ip 00007f431c97b835 sp 00007f230fc1c7c0 error 4 in libgio-2.0.so.0.4800.0[7f431c908000+181000] [14:50] deja vu [14:50] jup... why GIO? [14:50] meh [14:50] run it under gdb [14:50] Laney: have you seen that bug already? === JanC is now known as Guest73904 === JanC_ is now known as JanC [14:51] no just the ones I filed [14:51] although if you look at the latest log http://appstream.staging.ubuntu.com/logs/2016/09/23_1400.log [14:51] oh great :( [14:51] that happened later on in the run [14:52] ah [14:52] could have been at the start of the backports run [14:52] * Laney adds some more info to the script [14:55] Laney: I wonder if the script was still running when I added --verbose [14:55] because the logfile now has a "cannot execute command "bose"" at the bottom :D [14:55] super weird... can I tell dmesg to show timestamps? [14:56] dmesg -T [14:56] it also looks like all asgen commands ran through, at least they updated the timestamps information, which is the very last stepp [14:57] Laney: hehe ^^ [14:58] [Mo Sep 19 20:14:35 2016] appstream-gener[14057]: segfault at 8 ip 00007fe4d30f5835 sp 00007fc4c63967c0 error 4 in libgio-2.0.so.0.4800.0[7fe4d3082000+181000] [14:58] [Di Sep 20 02:13:20 2016] appstream-gener[673]: segfault at 8 ip 00007faafe825835 sp 00007f8af1ac67c0 error 4 in libgio-2.0.so.0.4800.0[7faafe7b2000+181000] [14:58] [Di Sep 20 08:11:42 2016] appstream-gener[18486]: segfault at 8 ip 00007f431c97b835 sp 00007f230fc1c7c0 error 4 in libgio-2.0.so.0.4800.0[7f431c908000+181000] [14:58] software sucks [14:58] Laney: so maybe I broke it myself by editing a script that was still running [14:58] let's go become farmers [15:00] bah [15:00] my lab is currently solving sofware issues with hardware workarounds [15:00] it's working under gdb [15:00] because we have an electrical engineer :P [15:00] * Laney modifies the script [15:01] run in foreground, run the asgen under gdb [15:01] hah, like the one bug I had a few years back which just *never* appeared in valgrind and gdb :P [15:01] it's probably just because I do one run at a time here [15:01] but the real run is yakkety yakkety-proposed yakkety-updates yakkety-security yakkety-backports [15:01] and cleanup [15:02] higher chance that one of them breaks [15:02] Laney: since cleanup is super-expensive, I only do it once a week [15:02] I am currently running asgen manually with --verbose, so you can get information about how often it does what [15:02] hm, didn't notice it being that slow [15:03] because you have a way faster machine than mekeel is [15:03] `asgen forget` is super fast [15:05] ASGEN="gdb -ex 'handle SIGUSR1 SIGUSR2 pass nostop noprint' -ex run --args ${BASE_DIR}/appstream-generator/build/appstream-generator --verbose" [15:05] winning [15:05] ^^ [15:05] btw, you can put that "don't handle SIGUSR" stuff into some gdb config file [15:05] * ximion did that at home [15:06] sensible [15:06] I pretty much never want to halt on a SIGUSR anyway [15:07] anyway, I need to run (back home) - will be back soonish [15:08] happy riding [15:42] I got the crash, and it's SCARY === bschaefer_ is now known as bschaefer [16:05] Laney: any interesting events while I am gone? [16:05] *was [16:06] yes [16:06] but not in a good way [16:06] (or was the interesting event that you left for the weekend? ;-P) [16:06] grr [16:06] so -pthread didn't help [16:06] it's a different crash [16:06] one second [16:07] the couchsurfers just turned up [16:07] need to go say hi [16:19] HAHA [16:19]