=== l3on_ is now known as l3on
[05:55] <pitti> Good morning
[06:57] <didrocks> morning
=== duflu_ is now known as duflu
[07:22] <didrocks> pitti: bonjour! thanks for the tmpfs bug: thanks to that, I've been able to discover that I disabled for tests /tmp on tmpfs and didn't reenable it :)
[07:22] <pitti> lol
[07:22] <pitti> bonjour didrocks
[07:23] <pitti> didrocks: just writing an autopkgtest for tmp cleanup, and will fix afterwards :)
[07:23] <didrocks> pitti: I'm fixing my fstab meanwhile, maybe I should write smoe autopkgtests for my machine :)
[07:30] <larsu> good morning!
[07:30] <didrocks> hey larsu
[07:30] <seb128> hey didrocks larsu pitti
[07:30] <pitti> bonjour seb128
[07:30] <pitti> moin moin larsu
[07:30] <larsu> hi seb128, didrocks, pitti! ça va?
[07:31] <didrocks> ça va bien ! et toi ?
[07:31] <larsu> bien aussi :)
[07:31]  * didrocks is happy to have the ubuntu make running again in CI after all that time !
[07:31] <larsu> \o/
[07:32] <didrocks> also happy with the number of integration tests I added in between to only have one (real but minor) failure :)
[07:33] <pitti> didrocks: hm, http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-ubuntu-make/ looks quite spotless?
[07:34] <didrocks> pitti: I'm talking about daily tests: https://jenkins.qa.ubuntu.com/job/udtc-trusty-tests/
[07:34] <didrocks> pitti: it's testing trunk, then the packaged version, on different archs
[07:34] <didrocks> with the integration tests (so full vm, with acceleration)
[07:35] <didrocks> the yellow are the tests with the current distro package (and so, with one failure)
[07:35] <didrocks> the green is trunk
[07:36] <pitti> ah
[07:36] <didrocks> pitti: there is another job for coverage report: https://jenkins.qa.ubuntu.com/view/All/job/udtc-trusty-tests-collect/label=ps-trusty-desktop-amd64-1/597/console
[07:36] <pitti> 92%? awesome!
[07:37] <pitti> I find it really hard to get > 85% or so, as then you have to run through hard-to-reach error paths
[07:37] <pitti> at least in C
[07:38] <didrocks> pitti: yeah, and I don't collect i386 + amd64, I should do that, because some of them are tested: https://jenkins.qa.ubuntu.com/view/All/job/udtc-trusty-tests-collect/label=ps-trusty-desktop-amd64-1/lastSuccessfulBuild/artifact/html-coverage/_home_ubuntu_ubuntu-make_umake_frameworks_dart.html
[07:38] <pitti> where you need to handle e. g. malloc() returning NULL (ENOMEM), and similar obtuse corner cases
[07:38] <didrocks> for instance
[07:38] <didrocks> yeah, at least, nothing like this in python :)
[07:38] <Noskcaj> didrocks, Do you have time to copy https://launchpad.net/~noskcaj/+archive/ubuntu/appstream-util/+packages to ubuntu vivid?
[07:38] <didrocks> Noskcaj: which ones did you fix?
[07:38] <didrocks> Noskcaj: as I copied most of them, I would appreciate a diff list to recheck :)
[07:39] <didrocks> I guess tali and sweep-foop?
[07:40] <didrocks> Noskcaj: and both of them are new upstream version. I don't see any FFe bug # referenced
[07:40] <didrocks> actually, those were the ones I rejected as well and pinged you about
[07:40] <didrocks> so no change since then…
[07:41] <Noskcaj> didrocks, I didn't get any pings, was just wondering which you'd got to
[07:42] <Noskcaj> The version bumps where because i wanted to actually switch their code to the new tool, but it's not enought to warrant an FFe now
[07:42] <didrocks> 2015-02-18 16:13:05     didrocks        Noskcaj: hey, you didn't change the build-dep here? https://launchpadlibrarian.net/197574606/gpaste_3.14-1_3.14-1ubuntu1.diff.gz
[07:42] <didrocks> 2015-02-18 16:14:51     didrocks        Noskcaj: same for https://launchpadlibrarian.net/198009486/swell-foop_1%3A3.15.4-0ubuntu1_1%3A3.15.90-0ubuntu1.diff.gz
[07:42] <didrocks> 2015-02-18 16:15:15     didrocks        and https://launchpadlibrarian.net/197863665/tali_1%3A3.15.2-0ubuntu1_1%3A3.15.90-0ubuntu1.diff.gz
[07:42] <didrocks> 2015-02-18 16:16:15     didrocks        Noskcaj: the other looks good, promoting appstream-utils to main and copying all others packages
[07:42] <didrocks> 2015-02-18 16:34:47     didrocks        Noskcaj: ok, promoted and all the rest copied over. You will see my name on -changes ML, this is a known restriction of copy-package (you are set as "Changed-By" in the emai
[07:42] <didrocks> l).
[07:42] <didrocks> on that very channel…
[07:47] <Noskcaj> didrocks, ok. I appear as always online, but i don't receive things that happen near to when i connect/disconnect
[07:49] <didrocks> Noskcaj: anyway, no worry, can you fix that and reping me afterwards? If the new release isn't only about appstream support, I guess now that a FFe would be required though
[08:26] <darkxst> Noskcaj, why not just cherry-pick the patches?
[08:26] <Noskcaj> darkxst, I'm doing that now
[08:26] <Noskcaj> didrocks, http://paste.ubuntu.com/10404286/ for gpaste
[08:33] <didrocks> Noskcaj: sponsored
[08:34] <Noskcaj> tali is bugfix only, so i'll make a debdiff for a bump to 3.15
[08:36] <didrocks> sounds good
[08:36] <didrocks> Noskcaj: state it in the changelog, please :)
[08:36] <Noskcaj> will do
[08:46] <willcooke> morning dudes
[08:49] <didrocks> hey willcooke
[08:51] <Noskcaj> didrocks, swell-foop http://paste.ubuntu.com/10404591/
[08:52] <seb128> hey willcooke
[08:53] <didrocks> Noskcaj: fuzz is your patch, fixing
[08:53] <didrocks> in*
[08:54] <Noskcaj> ok, from what?
[08:54] <didrocks> Noskcaj: the upstream cherry-pick
[08:54] <Noskcaj> ok
[09:02] <Noskcaj> didrocks, https://download.gnome.org/sources/tali/3.15/tali-3.15.90.tar.xz http://paste.ubuntu.com/10404737/
[09:03] <willcooke> seb128 @ email re: CI - No hurry on that, I think we can take a week or two to think about it
[09:04] <willcooke> seb128, and thanks for taking it on :)
[09:04] <Noskcaj> Who should i talk to about the appdata-tools rm
[09:04] <seb128> willcooke, k, yw!
[09:05] <Laney> morning
[09:05] <Noskcaj> morning Laney
[09:05] <willcooke> hi Laney
[09:06] <seb128> hey Laney
[09:06] <Noskcaj> Any idea when i can get some dmb responces for my motu application?
[09:08] <Laney> ask the other members
[09:08] <didrocks> hey Laney
[09:08] <didrocks> Noskcaj: finishing something, handling tali then
[09:08] <Noskcaj> ty
[09:13] <didrocks> Laney: do you think I need a FFe for this? https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1425434 it's basically some kind of bug fixing and copying what already works on other theme
[09:13] <ubot5> Launchpad bug 1425434 in xubuntu-artwork (Ubuntu) "Support fsck progress report with systemd" [Undecided,New]
[09:13]  * didrocks grrr at plymouth hide-splash not working…
[09:25] <Laney> didrocks: I commented in the bug :-)
[09:30] <didrocks> thanks Laney :)
[09:30] <didrocks> anyway, I'm testing that I don't typo in the script every themes
[09:30] <didrocks> would take some time, but worth it IMHO
[10:28]  * Laney cries at spotify crashing
=== greyback__ is now known as greyback
[11:37] <didrocks> phew, xubuntu is still using the old plymouth theme with the spinner and progress bar
[11:37] <didrocks> adapted, the code is quite different :)
[12:03] <didrocks> ubuntu studio, again tweaked theme…
[12:05] <didrocks> and no access to their Vcs-Bzr
[12:05] <didrocks> and of course, not up to date bzr :p
=== MacSlow is now known as MacSlow|lunch
=== MacSlow|lunch is now known as MacSlow
[14:27] <tedg> larsu, This bug 1263228 should be an ido bug, not an individual indicator one, no?
[14:27] <ubot5> bug 1263228 in libindicator (Ubuntu) "icons in indicators are small (difficult to view on FullHD display and smaller than was on 12.04)" [High,Triaged] https://launchpad.net/bugs/1263228
[14:27] <tedg> It's the custom menu items not handling resolution scaling, eh?
[14:28] <larsu> tedg: weird, they don't?
[14:28] <larsu> tedg: definitely an ido bug, yes
[14:28] <larsu> indicators don't send size information with their icons
[14:29] <tedg> Yeah, that was my thought, but just checking since you fixed it for i-power :-)
[14:29]  * larsu wonders
[14:30] <tedg> I think you removed the usage of a custom menu item?
[14:30] <larsu> ah, that fix only makes i-power use the new menu item I added so that rectangular icons work
[14:30] <larsu> tedg: no, added :)
[14:30] <tedg> Heh, K
[15:41] <attente_> seb128: hey, i uploaded the fcitx transition packages to https://launchpad.net/~fcitx-team/+archive/ubuntu/fcitx-transition
[15:42] <seb128> attente_, hey, oh ok, I started the work to get that in a silo as well
[15:42] <seb128> we need to ffe approved though
[15:42] <seb128> unsure if somebody can review u-s-s and u-c-c, maybe desrt or larsu or Laney or robert_ancell can help there?
[15:43] <seb128> I'm unsure I'm going to be able to make slots for that this week, but I don't want to block landing either
[15:43] <seb128> if nobody reviews I was just going to go for user testing and land it
[15:43] <attente_> yeah, i'm not sure who can look at it. even i-k isn't yet approved by desrt
[15:44] <attente_> does the u-s-d and u-c-c have to be approved first before the ffe is approved?
[15:44] <seb128> no
[15:46] <attente_> seb128: we can just resubscribe ubuntu-sponsors for https://bugs.launchpad.net/indicator-keyboard/+bug/1363150?
[15:46] <ubot5> Launchpad bug 1363150 in unity-settings-daemon (Ubuntu) "[FFe] Fcitx input method integration in Unity" [Undecided,New]
[15:46] <seb128> attente_, you can, but is that useful? what needs sponsoring that doesn't have a mr yet?
[15:46]  * larsu looks around and doesn't find useful info in the scrollback
[15:47] <attente_> seb128: oh. sorry. i meant ubuntu-release
[15:48] <seb128> attente_, yeah, you should
[15:48] <seb128> larsu, the mps attente_ asked for review in the meeting a bit over a week ago
[15:48] <larsu> ah
[15:48] <seb128> larsu, the 1 3 4 on https://code.launchpad.net/~attente/
[15:49] <larsu> should I have a look?
[15:52] <attente_> larsu: if you have time, i'm not sure who else to ask for this
[15:52] <larsu> okay (won't today, though)
[15:52] <attente_> ok, thanks larsu
[16:05] <qengho> kenvandine: I reproduced that text size problem. Thanks.
[16:05] <kenvandine> qengho, cool
[16:50] <didrocks> Noskcaj: and tali done, all should be sponsored now
[17:23] <pitti> Laney: FTR, new gdk-pixbuf breaks friends: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gdk-pixbuf
[17:23] <pitti> (it's a real failure, not infrastructure or flaky)
[17:23] <Laney> hmm
[17:23] <Laney> lemme see
[17:24] <Laney> pitti: I didn't get emailed about this
[17:24] <pitti> Laney: we only email the last uploader of the failing package, not the uploader of a package that causes a failure someplace else
[17:25] <pitti> and, this was a sync, not an ubuntu upload
[17:28] <Laney> bah
[17:29] <Laney> this version adds "rename-to" to some stuff
[17:29] <Laney> breaks gi API
[17:38] <Laney> pitti: do you know if there's some idiomatic way to rename and keep the original using gi?
[17:38] <pitti> eek, GI ABI break then?
[17:38] <Laney> yes
[17:39] <pitti> Laney: at least not with rename-to, that drops the original name
[17:39] <Laney> gnome bug #670372
[17:39] <ubot5> Gnome bug 670372 in general "Annotate var-arg gdk_pixbuf_save*() as aliases for save*v()" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=670372
[17:39] <Laney> I think we could revert this
[17:41] <pitti> hm, there's no (alias) or similar on https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations
[17:42] <pitti> so far the only backwards compat aliases I'm aware of are in the python overrides
[17:42] <pitti> but these are of course language specific; renaming a public ABI breaks JS, Vala, and other consumers as well
[17:47] <Laney> This adds an attribute "shadows" to the node in the gir file
[17:48] <Laney> I guess you could add another one and update the parser to not overwrite the name in this case
[17:48] <Laney> dont-remove or so
[17:48] <Laney> then a rename-to-and-keep thing, like walters suggests
[17:49] <Laney> larsu: do you know anything about g-i?
=== alex_abreu is now known as alex-abreu
=== alan_g is now known as alan_g|EOD
[19:27] <larsu> Laney: a little. What's the question?
[19:28] <Laney> s'ok, I'll think about it tomorrow
[19:28] <Laney> it's about being able to alias instead of only renaming functions when binding them
[19:30] <larsu> I don't think aliasing is possble
[19:32] <Laney> indeed, was thinking about adding it
[19:32] <larsu> interesting - what's your use case?
[19:32] <Laney> adding rename-to just breaks API now
[19:32] <larsu> (or do you want to talk tomorrow?)
[19:32] <Laney> which is quite often not cool
[19:33] <Laney> so you probably want a way to not do that
[19:33] <larsu> it doesn't break API in a lot of cases
[19:33] <larsu> like renaming deprecated functions
[19:34] <Laney> if anyone's using it then they can't any more
[19:35] <mlankhorst>  /2
[19:35] <larsu> well, you need to rename a new function to the old name
[19:35] <mlankhorst> oops
[19:35] <larsu> mlankhorst: /5!
[19:35] <larsu> Laney: but I see what you mean in general...
[19:35] <larsu> but why would aliasing help? And how would it work?
[19:37] <Laney> In the typelib file you'd generate bindings for the real and renamed-to name
[19:37] <Laney> so that current and new things work
[19:38] <larsu> why can't you just add the function to the library and make it call the old function?
[19:38]  * larsu is unsusre absout the use case
[19:39] <Laney> a new one which is renamed-to the old one?
[19:39] <Laney> seems kinda ugly
[19:39] <larsu> true
[19:39] <Laney> especially if it's only for binding when the binding tools could have the ability to do it
[19:40] <Laney> maybe I'll see if I can do a patch and find out what the g-i guys think
[19:40]  * Laney wonders who they are
[19:41] <larsu> walters did quite some work there iirc
[19:41] <larsu> there's also #introspection on gimpnet
=== thumper is now known as thumper-afk
=== thumper-afk is now known as thumper