=== mhall119 is now known as mhall119|fossetc
=== happyaro1 is now known as happyaron
=== maclin1 is now known as maclin
[04:06] <pitti> Good morning
[04:15] <TheMuso> Hey pitti, how are you?
[04:25] <pitti> hey TheMuso! a bit tired still, but good, thanks! how about yourself?
[04:27] <TheMuso> pitti: Not too bad thanks, glad to have air conditioning here today, 40+ degrees in Sydney, can't wait for the southerly cool change so I can open my windows again. :)
[04:27] <pitti> urgh, steaming
[04:27] <TheMuso> Pretty much.
[04:33] <pitti> Laney: meh, more weird MemoryErrors and segfaults -- time to reboot this box
[04:33] <pitti> Laney: maybe the piled up ksplices eventually made the kernel's head explode
[05:51] <darkxst> pitti, how did this manage to migrate through proposed? bug 1518035
[05:51] <ubot5> bug 1518035 in libjpeg9 (Ubuntu) "package libjpeg-progs 1:9a-2ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/man/man1/djpeg.1.gz', which is also in package libjpeg-turbo-progs 1.3.0-0ubuntu2" [Undecided,New] https://launchpad.net/bugs/1518035
[05:52] <pitti> darkxst: we don't do upgrade tests as part of proposed-migration
[05:52] <pitti> apparently a fresh install works
[05:57] <darkxst> pitti, right that makes sense
[06:06] <didrocks> good morning
[06:14] <pitti> bonjour didrocks !
[06:20] <hikiko> Morning !
[06:27] <didrocks> good morning pitti, hikiko!
[06:39] <pitti> Laney: dbus tests are reeeeally unhappy, the root tests keep timing out
[06:39]  * pitti cancels the currently running ones, no point
[06:52] <seb128> good morning desktopers
[06:52] <seb128> hey didrocks, pitti
[06:52] <seb128> pitti, Laney is off today :-/
[06:52] <pitti> bonjour seb128 !
[06:52] <seb128> though I would not be surprised if he reads IRC
[06:57] <didrocks> re seb128
[06:58] <didrocks> Laney: preventively: "go away"! :)
[08:04] <pitti> ok, that should have cleared a lot of -proposed stuff
[08:06] <seb128> pitti, "that"?
[08:07] <pitti> seb128: retrying tests, adding hints, retrying some failed builds
[08:07] <seb128> ah, ok
[08:07] <pitti> a lot of arm64 builds failed in a weird way
[08:07]  * seb128 wonders what transitions is the solid block at the bottom of update_output
[08:07] <pitti> seb128: and bringing moah powah to my clouds, so the queues finally cleared up \o/
[08:08] <pitti> seb128: isn't that just the concatenation of everything it tries to migrate?
[08:08] <pitti> that "autohinter" thing
[08:08] <seb128> does it always does that?
[08:09] <pitti> there's certainly a bunch of valid candidates which wait for finishing lib transitions, like imobiledevice
[08:09] <seb128> libimobiledevice seems to miss a upower rebuild
[08:10] <seb128> pitti, did you have any content to include for that one or should we go for a no change?
[08:10] <pitti> ah, easy; want me to, or are you on it?
[08:10] <seb128> I can do it
[08:10] <pitti> heh
[08:10] <seb128> just wanted to check if you had actually patches pending or something
[08:10] <pitti> seb128: I suppose your "upload a no-change rebuild" script is as good as everyone else's :)
[08:10] <seb128> doing it then ;-)
[08:11] <pitti> cheers
[08:11] <seb128> yw!
[08:21] <larsu> happy Friday!
[08:21] <seb128> hey larsu, happy friday!
[08:21] <seb128> wie gehts?
[08:23] <Trevinho> morning
[08:27] <seb128> hey Trevinho!
[08:27] <Trevinho> hey seb128
[08:28] <seb128> how are you?
[08:28] <larsu> seb128: gut danke. und idr?
[08:28] <larsu> *dir
[08:28] <didrocks> happy Friday larsu, Trevinho!
[08:28] <larsu> hi Trevinho! Sup?
[08:28] <seb128> larsu, auch gut, danke :-)
[08:28] <larsu> bonjour didrocks
[08:38] <Trevinho> hi larsu .... Trying to fix my broken head... :-/
[08:40] <larsu> Trevinho: oh what's up?
[08:42] <Trevinho> larsu: still the same.... I've not been able to fix myself yet. Trying to fight with nightly panic attacks.
[08:42] <larsu> Trevinho: sorry to hear. All the best!
[08:42] <Trevinho> larsu: thanks
[08:43] <pitti> hey larsu!
[08:43] <pitti> hello Trevinho
[08:43]  * seb128 just spent ~1.5 hours going through the 300 or so "most recently changed" bugs on launchpad, enough triaging for today
[08:44] <seb128> (trying to do a bit of that every day since wily to keep on top of new issues reported/important ones)
[08:44] <larsu> morgen pitti! Wie gehts?
[08:44] <Trevinho> hi pitti
[08:44] <larsu> seb128: good work! Thanks
[08:44] <pitti> larsu: prima, danke!
[08:44] <seb128> :-)
[08:45] <seb128> shotwell is another unhappy program because of the glib file monitor improvements :-/
[08:45] <seb128> segfault when editing photos with an external editor
[08:45]  * pitti hugs seb128
[08:46]  * seb128 hugs pitti back
[08:49] <larsu> seb128: "improvements"
[08:50] <seb128> larsu, yeah :-)
[08:52]  * didrocks will not get the card of backward compatibility in term of behaviors :p
[08:52] <larsu> didrocks: that would mean we could never fix behaviour bugs
[08:52] <larsu> there's a balance
[08:52] <larsu> but yeah ... this situation is breaking all kinds of things
[08:53] <didrocks> larsu: well, some frameworks do that and add new calls
[08:53] <didrocks> or flags to enable the new "fixed" behavior
[08:53] <didrocks> larsu: the extreme would be to fix "this" in javascript for instance :p
[08:53] <didrocks> it's the kind of things we do, and thus, the result in crashing apps…
[08:56] <larsu> indeed
[08:56] <larsu> like I say, it's a balance :)
[08:58] <larsu> seb128: which nautilus version do you need the menubar patch for? Will we stay on 3.14?
[08:58] <seb128> larsu, 3.18
[08:58] <larsu> nice :)
[08:58] <seb128> larsu, no, if we were to stay on 3.14 we wouldn't need a patch since that has a menubar :p
[08:58] <larsu> not for me :/
[08:58] <seb128> well or at least our package has one
[08:59] <seb128> but it's built on old code
[08:59] <larsu> ah, restart
[08:59] <seb128> which got rewriten to use moder gaction, etc
[08:59] <larsu> weird
[08:59] <larsu> right right
[09:06] <larsu> woah, got asked about which login manager I want to use, again
[09:12] <larsu> and I need to restart nautilus after logging in before I have correct fonts or the global menubar
[09:12]  * larsu blames xsettings not being there from the beginning
[09:12] <didrocks> pitti: do you know well how subprocess and os.environ interacts? I'm really puzzled on some weird behaviors when running tests…
[09:14] <larsu> hm firefox theme as well
[09:14] <larsu> is anyone else seeing this?
[09:20] <seb128> larsu, I don't
[09:20] <seb128> but I didn't upgrade yet today
[09:22] <happyaron> where is the latest snappy image?
[09:25] <seb128> happyaron, #snappy should know
[09:37] <pitti> didrocks: normally the spawned process should inherit the parent's env, unless you explicitly set env=
[09:37] <happyaron> seb128: thanks, :)
[09:37] <didrocks> pitti: agreed, it's not what happens here though
[09:38] <didrocks> pitti: I have reduced it to few lines, and it behaves different if I have one test class or multiple…
[09:56] <didrocks> pitti: if you have a minute, I have a gist to reproduce the issue: https://gist.github.com/didrocks/ae12d61138090b837c18
[09:57] <pitti> didrocks: oh, are you sure that assigning the whole os.environ array works?
[09:58] <pitti> didrocks: I'm not sure, but I faintly remember having run into this before too
[09:58] <pitti> didrocks: untested, but can you try instead:
[09:58] <didrocks> pitti: it does from the output, like the output doesn't contain http_proxy for instance
[09:58] <pitti> os.environ.clear()
[09:58] <pitti> os.environ.update(self.original_env)
[09:58] <didrocks> ah
[09:59] <didrocks> pitti: but it's still weird that a impacts b, isn't it?
[09:59] <pitti> i. e. keep the os.environ dict object itself unchanged, but only change its keys
[09:59] <didrocks> let me try
[09:59] <didrocks> (I can see that SHELL is restored though)
[10:00] <didrocks> pitti: yeah, it passes now :)
[10:00] <didrocks> I'm still unsure what happens under the hood though
[10:00] <didrocks> ohhhhhhh, I see
[10:00] <didrocks> so, what happens is that subprocess still reference os.environ, the original one
[10:00] <pitti> didrocks: os.environ is "magic" -- changing the reference to a different object apparenlty loses that magic
[10:00] <didrocks> not the one we replaced
[10:00] <pitti> and you assign it to a normal "dumb" dict
[10:01] <pitti> right
[10:01] <pitti> you shouldn't change the object itself (i. e. the reference to it)
[10:01] <didrocks> that's why it still got the env variable only if a ran
[10:01] <didrocks> happened before*
[10:01] <didrocks> pitti: it all makes sense now :)
[10:01] <didrocks> thanks a bunch, I was really fighting on that one (first, to reduce at that state)
[10:02] <didrocks> and so, if I only ran b, there was no issue, because I didn't touch os.environ assignement before
[10:02] <didrocks> still weird that in this magic, when I changed b, it was changing the new os.environ that I assigned
[10:02] <didrocks> but subprocess keeps using the old os.environ
[10:02] <didrocks> even if not called before
[10:03] <pitti> self.original_env = os.environ.copy()
[10:03] <pitti> didrocks: ^ maybe the .copy() just returns an ordinary dict, not the special "magic" one that actually calls setenv()?
[10:03] <pitti> but I don't know for sure
[10:04] <didrocks> pitti: that would make sense, indeed
[10:04] <pitti> just as far as "never assign os.environ", got burned and only remembered the "don't do that then"
[10:04] <didrocks> so we don't have anymore _Environ
[10:04] <didrocks> and so, it doesn't setenv()
[10:04] <didrocks> ahah :)
[10:04] <didrocks> pitti: rightly noted now!
[10:04] <didrocks> thanks a lot
[10:04]  * didrocks hugs pitti
[10:05] <pitti> de rien !
[10:26] <Laney> pitti: ERROR:../../test/uid-permissions.c:129:test_uae: assertion failed (dbus_message_get_type (m) == DBUS_MESSAGE_TYPE_METHOD_RETURN): (3 == 2) <- there's a related UpdateActivationEnvironment change in this release - check with smcv?
[10:26] <Laney> might be that this should fail now
[10:27] <Laney> (3 is error)
[10:32] <seb128> hey Laney
[10:37] <Laney> hi seb128
[10:37]  * Laney is looking at cake recipes
[10:37] <Laney> what's up?
[10:37] <seb128> how did the cake go?
[10:37] <Laney> not made yet
[10:37] <seb128> oh, not done yet :-)
[10:37] <seb128> new gtk migrated!
[10:38] <Laney> so I saw
[10:38] <Laney> yay cloud
[10:40] <Laney> someone can follow up with that dbus thing if they want or I can look on monday
[10:46] <seb128> if somebody things it's urgent I can have a look
[10:46] <seb128> otherwise I think it can wait monday
[10:51] <Laney> https://bugs.freedesktop.org/show_bug.cgi?id=93036
[10:51] <ubot5> Freedesktop bug 93036 in core "/uid-permissions/uae/root test fails with 1.10.4" [Normal,New]
[10:51]  * Laney goes to buy more ingredients now
[10:51] <Laney> later!
[10:51] <seb128> Laney, have fun!
[10:52] <seb128> oh, good, libimobiledevice transition went through
[10:52] <Sweet5hark> hmmm, no will.cooke in here today?
[10:52] <seb128> he said he would swap the morning
[10:52] <seb128> he should be there after lunch
[10:52] <seb128> speaking of lunch I start being hungry ;-)
[10:53]  * didrocks does as well, going out for lunch, see you later guys :)
[10:53] <seb128> didrocks, enjoy!
[10:53] <didrocks> thanks, you too seb128
[11:25] <pitti> Laney: FYI, memory errors seem to be real; committed https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=17776035 and will re-deploy once the queue settled down
[12:26] <desrt> hello desktop-types.  i hope you are having a good morning.
[12:40] <seb128> hey desrt, happy friday!
[12:40] <desrt> indeed!
=== hikiko is now known as hikiko|ln
=== alan_g is now known as alan_g|lunch
=== dpm is now known as dpm-afk
=== hikiko|ln is now known as hikiko
[13:56] <didrocks> phew, all tests passed, finally! :p
[13:56] <pitti> didrocks: \o/
[13:57] <didrocks> pitti: thanks again! And with the large tests refactoring, I divided the testing time by two!
[13:57] <didrocks> (~50 minutes vs 1h40)
[13:57] <pitti> wow
=== alan_g|lunch is now known as alan_g
[14:14]  * didrocks celebrated with pushing 3 new tests
=== dpm-afk is now known as dpm
[14:51] <didrocks> tkamppeter: hey, why is hplip depending on pexpect? It seems just to be for testing, right? So build-dep, but not runtime dep?
[14:52] <didrocks> hum, seems that hplip has a pexpect embeeded version…
[14:53] <didrocks> and the dep was added in 2009 with the idea of removing the embeeded version
[14:53] <didrocks> which wasn't done in 5 years :p
[14:53] <didrocks> 6*
[14:54] <didrocks> ok, they are using pexpect in utils.py for handling some subprocess and giving password and such to it (urgh)
[14:56] <tkamppeter> didrocks, this is not done by me but by the Debian folks, perhaps a Debian bug should get reported.
[14:56] <didrocks> tkamppeter: mind opening one? are you maintaining this stack as well? :)
[14:56] <didrocks> tkamppeter: sounds like this kind of things shouldn't even be in main
[14:57] <didrocks> maybe I should ask for some security team review, but passing password to subprocess sounds like something I would have kicked the MIR out
[15:02] <didrocks> seb128: mind creating a https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/ubuntu-make-builddeps ppa?
[15:02] <didrocks> I want to ensure that testing/build-deps are not installed on user's machine if they add the ubuntu make ppa
[15:03] <didrocks> (like… pexpect that we install by default :/)
[15:03] <seb128> didrocks, done
[15:03] <didrocks> thanks!
[15:05] <seb128> yw!
[15:18] <didrocks> Sweet5hark: it seems that willcooke is here. I think you were looking for him ^
[15:18] <didrocks> btw, good morning willcooke :-)
[15:18] <willcooke> morning
[15:31] <Sweet5hark> heya! :)
[15:32] <Sweet5hark> willcooke: was just wondering about the lack of feedback on the 2oitg thing ... but I assume, if this is "morning" you are sprinting somewhere in the US?
[15:32] <willcooke> Sweet5hark, just swapped some hours this week
[15:33] <willcooke> Sweet5hark, seen you mail, but not digested it yet
[16:29] <attente> how does someone grep the archive?
[16:31] <didrocks> attente: what do you mean, grepping through all the sources ?
[16:32] <attente> didrocks: yeah. i think Laney had a web interface for it, but the url doesn't work any more
[16:32] <didrocks> attente: oh, I don't know about a web interface. archive admins can grep directly in the source file system, but that's it
[16:33] <didrocks> attente: if you only look for file names, though, you can do it throuh a web interface
[16:34] <attente> didrocks: could you do a couple greps for me? i'm looking for QT_IM_MODULE and maliitphablet
[16:34] <didrocks> attente: quite late to do that (I'm leaving in ~10 minutes), could do on Monday for sure
[16:34] <didrocks> or if seb128 is still there for some times, he might (or wait for Laney if he thinks there is a web interface)
[16:34] <attente> ah, ok, sure. have a good w.e!
[16:35] <didrocks> thanks (not left yet, but soon) ;)
[16:35] <seb128> I don't know of an handy way no
[16:35] <seb128> jdstrand had a script I think
[16:35] <seb128> Laney had a https://codesearch.debian.net/ equivalent up somewhere
[16:35] <seb128> but unsure if that's still a thing
[16:36] <attente> yeah, i think it used to be http://ubuntu-codesearch.surgut.co.uk/, but it hasn't been online in a while
[16:54]  * didrocks goes, see you on Monday guys!
[16:54] <willcooke> see ya didrocks
[16:54] <didrocks> have a good week-end willcooke :)
=== popey_ is now known as popey
[17:09] <seb128> have a good w.e!
[17:11] <willcooke> see ya seb128
[17:11] <seb128> see you on monday ;-)
[17:19] <Trevinho> guys, have nice weekend !
[17:20] <willcooke> see ya Trevinho
[17:20] <Trevinho> willcooke: see u
=== alan_g is now known as alan_g|EOD
[19:13] <willcooke> g'night