[05:09] <pitti> Good morning
[05:28] <didrocks> good morning
[05:30] <flocculant> morning pitti didrocks
[05:30] <pitti> bonjour didrocks et flocculant !
[05:31] <didrocks> good morning flocculant, pitti!
[05:34] <flocculant> not sure about good - it's certainly early - woke up at 4 couldn't get back to sleep ...
[05:36] <didrocks> urgh
[08:17]  * didrocks is really annoyed by xnox's pkgconfig merge with debian for his tests :)
[08:17] <didrocks> (finally got the time to have a look at this issue that only happened on "desktop", where pkg-config is installed
[08:17] <didrocks> not like my builders or autopkgtests setup :p
[08:43] <Trevinho> Good morning!
[08:43] <didrocks> hey Trevinho, how are you?
[08:44] <pitti> didrocks: oh, something broken there? the merge happened a month ago already
[08:44] <Trevinho> didrocks: I can say quite well, finally.
[08:44] <Trevinho> didrocks: you?
[08:45] <didrocks> pitti: yeah, the issue is that when you install pkg-config, you have a dpkg hook installed now
[08:46] <didrocks> pitti: and this hook doesn't work well when you use dpkg --root
[08:46] <didrocks> I'm unsure if dpkg --root shouldn't look at the hooks config in the usual dirs
[08:46] <didrocks> or if the hook should be fixed to not mixed with real installation when --root is used
[08:46] <didrocks> Trevinho: I'm good thanks!
[08:47] <pitti> didrocks: interesting, I wasn't aware of this mechanism even
[08:47] <didrocks> pitti: it's passing in builders and autopkgtests because I don't install pkg-config here, so I don't have the guilty hook
[08:47] <didrocks> yeah, I'm doing funky stuff to test adding an architecture and such in my tests :)
[08:48] <didrocks> and the hook hardcode the path, so I can't even just "discare it"
[08:48] <pitti> didrocks: could you just remove the hook for the tests?
[08:48] <pitti> if you don't care about cross-building
[08:49] <didrocks> pitti: how come? It's on the system itself in /etc/dpkg…
[08:49] <didrocks> pitti: so it means running those tests are root
[08:50] <didrocks> (and so, running those as root on my machine… :/)
[08:50] <pitti> didrocks: oh, I thought it breaks your tests
[08:50] <didrocks> it does
[08:50] <pitti> didrocks: ah, for that; so at least you want something nondestructive like sudo mount -o bind /dev/null /usr/share/pkg-config-dpkghook
[08:50] <didrocks> I can't run small tests locally on my machine itself now
[08:50] <pitti> which will make the test -x fail
[08:50] <didrocks> pitti: yeah, but this will require root as well, no?
[08:51] <pitti> didrocks: yes, it does
[08:51] <pitti> didrocks: oh, you call dpkg as user in a temp dir?
[08:51] <didrocks> yep
[08:51] <didrocks> (with fakeroot to install package)
[08:51] <didrocks> and --root=<path>
[08:52] <didrocks> local repo, everything locally brewed :)
[08:52] <pitti> didrocks: so why doesn't that take the dpkg config files from that fakeroot as well?
[08:52] <didrocks> pitti: yeah, I think that's the dpkg bug, it should IMHO
[08:53] <pitti> didrocks: you mean fakechroot bug?
[08:53] <didrocks> no
[08:53] <pitti> oh, fakeroot, not fakechroot
[08:53] <didrocks> fakeroot only
[08:53] <didrocks> I'm still using system dpkg and such
[08:53] <didrocks> just faking hiding dpkg with "dpkg --root…"
[08:53] <didrocks> s/faking//
[08:55] <didrocks> pitti: basically: https://github.com/ubuntu/ubuntu-make/blob/master/tests/small/test_requirements_handler.py#L59
[08:55] <didrocks> maybe there is a DPkg::<something> directive
[08:55]  * didrocks looks
[09:04] <didrocks> argh, it's a linked list when added
[09:04] <didrocks>   /* Add the new hook at the tail of the list to preserve the order. */
[09:04] <didrocks>   **hook_tail = hook_new;
[09:04] <didrocks>   *hook_tail = &hook_new->next;
[09:15] <Trevinho> didrocks: with new unity/launcher integration, we've a dbus dependency with nautilus (not that without it it wont' work, but still)... I was wondering whether. So should I add it to reccomends?
[09:18] <didrocks> pitti: filed a new upstream dpkg bug FYI
[09:19] <didrocks> Trevinho: what happens if nautilus isn't installed?
[09:19] <Trevinho> didrocks: well, launcher icons (the trash and devices one) won't be illuminated, or wont' control any window. They should work as they used to work before
[09:20] <Trevinho> didrocks: so only as a shortcut to open stuff
[09:20] <didrocks> Trevinho: ok, recommends sounds right then
[09:20] <didrocks> Trevinho: btw, not sure if you noticed, be the student updated his patch: https://code.launchpad.net/~mcintire-evan/unity/add_screenshot_shortcut_hints/+merge/280671
[09:21] <didrocks> Trevinho: I'm not sure we have any category matching well where to put this, but I guess, we don't want to expand with another one (and fighting with nux layouting ;))
[09:22] <Trevinho> yeah, I agree
[09:22] <Trevinho> also there's the thing that adding too many stuff might pretend the view to be shown in low resolutions (by low also <= 1366x768)
[09:23] <didrocks> Trevinho: yeah, so I guess where he added it is fine
[09:24] <didrocks> Trevinho: mind reviewing it once more? Will be nice to have it merged before EOW if possible :)
[09:25] <Trevinho> didrocks: yeah, I'd love to do an unity landing before xmas, but not sure it's sane. As I won't be back till 12nd...
[09:25] <larsu> good morning!
[09:26] <Trevinho> didrocks: and well, you might revert in case, but...
[09:26] <didrocks> Trevinho: well, I can consider the "approval" to be +1 for his code in task
[09:26] <didrocks> Trevinho: so, just approve if you feel so, already :)
[09:26] <didrocks> hey larsu
[09:26] <Trevinho> (old Trevinho would have merged it any day, but he's getting more responsible :PO)
[09:28] <larsu> hi didrocks!
[09:30] <didrocks> Trevinho: just review it, if it's good, tell me and I can close the task :)
[09:33] <Trevinho> didrocks: sure, I was in the meeting with kylin before... I'll do that shortly
[09:36] <didrocks> thx
[09:51] <didrocks> hum, one test become racy (only on xenial), seeing the diff, apt 1.1.5 sounds like a good guilty guy
[09:55] <didrocks> mvo: hey, is that expected with new apt that I can (not always), having multiple times the same status reported by the apt binding?
[09:56] <didrocks> mvo: this doesn't happen 100% of the time (with the same test), but if you look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/u/ubuntu-make/20151217_075907@/log.gz, I'm installing one package, one bit, I get twice:
[09:56] <didrocks> 2015-12-17 07:58:38,914 [umake.network.requirements_handler] DEBUG: ['testpackage'] download update: 0.0% of 1
[09:56] <didrocks> 2015-12-17 07:58:38,924 [umake.network.requirements_handler] DEBUG: ['testpackage'] download update: 0.0% of 1
[09:56] <didrocks> (I would expect to have progress triggers only if the percentage changes, even slightly)
[10:03]  * didrocks changed his test to be more resilient against this
[10:14] <mvo> didrocks: the way this works internally is that it call the progress callback periodically so that you don't need your own mainloop (if you set the timeout low enough). this has the side-effect that it will also report non-changes just so that you can refresh your ui
[10:18] <didrocks> mvo: ok, do you confirm that wasn't the case before or I just good lucky over the past 2 years?
[10:19] <didrocks> mvo: changing the tests to take that into account is quite easy for me, just wanted to know if I wasn't dreaming :)
[10:50] <xnox> didrocks, ? =)
[12:31] <didrocks> xnox: see my discussion with pitti about the dpkg trigger and --root suport
=== alan_g is now known as alan_g|lunch
[13:00] <flocculant> didrocks can have 1 cookie, (I'll keep the one for 32 bit warm still, that failed to build) - thanks for fixing that :)
[13:05] <didrocks> flocculant: yw! happy to have found it :)
[13:06] <didrocks> flocculant: bonus: the initramfs is smaller than before the plymouth merge :)
[13:06] <flocculant> :)
[13:31] <xnox> didrocks, i keep wondering to make the 2x plymouth theme the default.
=== alan_g|lunch is now known as alan_g
[13:31] <xnox> not because there are more high-dpi screens than normal, but because both are usable with 2x theme.
[13:33] <cyphermox> xnox: is the current plymouth theme unusable on high-dpi?
[13:33] <cyphermox> I mean, I would agree it likely is quite small, but still
[13:33] <ricotz> hi, could someone sponsor automake-1.15 merge -- https://launchpad.net/~ricotz/+archive/ubuntu/staging/+sourcepub/5781864/+listing-archive-extra
[13:33] <cyphermox> (I have no idea how it looks on high-dpi mind you)
[13:34] <didrocks> xnox: I don't know if there is any info from the script exported for this
[13:34] <didrocks> xnox: part of the issue is that the script will really need a complete rewrite, there is a lot of dead code in the ubuntu logo one
[13:36] <xnox> cyphermox, not usable at all. hence a while back i added a "2x" theme too, which one can manually opt into using update-alternatives.
[13:37] <xnox> didrocks, there are two scripts/themes packaged - 1x and 2x.
[13:38] <xnox> didrocks, is there any api to query screen dpi/scale factor these days as root? e.g. I could query gsettings or somesuch in postinst and automatically opt into 2x theme....
[13:40] <didrocks> xnox: no api AFAIK, (that's why we have the scale thingy in Unity)
[13:40] <didrocks> but query user's info gsettings key (user info) in postinst (root)
[13:40] <didrocks> hem… ;)
[13:40] <cyphermox> xnox: guess from xdpyinfo?
[13:40] <cyphermox> wait nvm, same issue
=== davidcalle_ is now known as davidcalle
=== davidcalle__ is now known as davidcalle_
[14:02] <desrt> good morning, peeps
[14:03]  * ogra_ wonders in that light if leaning back and watching IRC scroll by then counts as peepshow
[14:04] <didrocks> good morning desrt
[14:07] <desrt> didrocks: what are you up to today?
[14:11] <didrocks> desrt: working on moving from jenkins to autopkgtests for ubuntu make tests
[14:11] <didrocks> as the jenkins infra is going down
[14:11] <didrocks> what about you?
[14:11] <desrt> doing my dance back and forth between dconf and glib.  did the dconf release yesterday, so back to glib today to add some new APIs that i can use from the next dconf release :)
[14:12] <didrocks> handy!
[14:12] <desrt> kinda ugly, in fact
[14:12] <desrt> i'm really increasing the coupling of dconf and glib here
[14:12] <desrt> oh well
[14:13] <desrt> in a way the coupling was already there insofar as all GSettingsBackend implementations are expected to be dconf-like
[14:13] <desrt> which is more complicated than it sounds
[14:36] <desrt> so i just got an email from asustor's RT-equivalent
[14:36] <desrt> i filed a ticket about missing files in their GPL package
[14:36] <desrt> i got zero reply from anyone
[14:36] <desrt> and now the system is telling me the ticket is being automatically closed due to inactivity
[14:36] <desrt> suggestions?
[14:36] <desrt> i'd prefer to avoid hiring a lawyer
[15:03] <bzoltan_> Mirv:  is there a known problem with the CI infra?
[15:05] <didrocks> Trevinho: the MP was updated
[15:05] <didrocks> oh you approved \o/
[15:05] <didrocks> rocking
[15:05] <Trevinho> didrocks: yeah :)
[15:29] <didrocks> pitti: probably a stupid question, but I don't find any answer on http://packaging.ubuntu.com/html/auto-pkg-test.html or https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure. What's the directory where I should push artefacts to be saved in swift? (or even with a local adt-run, if they can be stored outside the vm…)
[15:30] <pitti> didrocks: that's in https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html aka /usr/share/doc/autopkgtest/README.package-tests.*
[15:30] <pitti> didrocks: put them into  $ADT_ARTIFACTS/
[15:30] <didrocks> pitti: ah, excellent, thanks for the pointer :)
[15:30] <didrocks> ok!
[15:31] <didrocks> pitti: good news: docker tests run inside the vm without any trickery contrary to jenkins!
[15:31] <pitti> didrocks: with --output-dir=X they will appear in X/artifacts/
[15:31] <pitti> didrocks: nice! with trickery you mean the ssh -tt?
[15:31] <didrocks> yep!
[15:31] <pitti> didrocks: ah, same issue that we had back then
[15:31] <didrocks> indeed :)
[15:31] <didrocks> pitti: the only issue I have is that the testbed is set to something in /tmp (and I have a tmpfs limited to 2G here)
[15:32] <didrocks> so large tests don't run, need to find a way to tell "use the disk, son" ;)
[15:32] <pitti> didrocks: with VM?
[15:33] <pitti>  -o OVERLAY_DIR, --overlay-dir OVERLAY_DIR
[15:33] <pitti>                         Temporary overlay directory (default: in /tmp)
[15:33] <pitti> didrocks: ^ you want that then? perhaps /var/tmp/
[15:33] <pitti> didrocks: 2GB! you only have 4 GB?
[15:33] <didrocks> pitti: I have 8GB, but I like having enough for the browser and such
[15:33] <pitti> ah
[15:34] <didrocks> used 4.5GB here
[15:34] <pitti> didrocks: anyway, so adt-run [...] --- qemu -o /var/tmp/ yourimage.img
[15:34] <didrocks> pitti: excellent, thanks a bunch! :)
[15:35] <didrocks> pitti: I guess I'll be able to do everything is needed on my side. I guess the last things we will check is what's available through the proxy and if sourcing /etc/environment really works for docker
[15:35] <didrocks> (but that can wait January)
[15:36] <pitti> didrocks: right, but that shouldn't be an issue as long as you run tests locally?
[15:36] <didrocks> yep!
[15:36] <didrocks> at least, I'll have a reproduceable local system :)
[15:39] <pitti> Laney: yay prodstack troubles again (IS  knows)
[15:39] <pitti> Laney: I can't ssh into stuff, and all workers died
[15:40] <didrocks> hopefully, Laney is on holidays and won't see that :)
[15:53] <flocculant> I'll screenshot it for him
[15:54] <didrocks> poor Laney :p
[15:55]  * desrt observes the start of the eoy slowdown
[15:59]  * didrocks doesn't feel any slowdown with google code in :p
[16:29] <didrocks> pitti: the testbed isn't kept between tests? It would mean I need to put all tests in the same scripts (as I think we don't want to install ubuntu-desktop 4 times ;))
[16:29] <pitti> didrocks: depends
[16:30] <pitti> didrocks: the test bed is reset if
[16:30] <pitti>  - the current test declares "breaks-testbed", or
[16:30] <pitti> - the current test has Depends: which the next test does not have
[16:30] <didrocks> ahhhh
[16:30] <pitti> didrocks: and yeah, you really want to pre-prepare an image with u-desktop for taht
[16:30] <didrocks> so I need to keep the same Depends list
[16:30] <pitti> didrocks: same, or only add to it
[16:30] <didrocks> ok, let me try this
[16:31] <pitti> didrocks: but I suppose you'll run this more than once
[16:31] <didrocks> yeah :)
[16:31] <pitti> didrocks: so, cp the VM, start it, install u-desktop, and save that
[16:31] <didrocks> pitti: I have the desktop one, but I'm doing a little bit more in setup that just installing u-desktop
[16:31] <didrocks> I was using that just as an example
[16:32] <pitti> didrocks: well, sure -- if it's "cheap" setup that doesn't hurt, but installing u-desktop on a minimal cloud image sucks
[16:32] <didrocks> pitti: yeah, we discussed that, and agreed, we'll need to do something about it :)
[16:32] <didrocks> but let's try to get something ready first
[16:36] <pitti> didrocks: once we run that in production I can work on building desktop-ish images, this is just for not making you weep too much when running locally :)
[16:37] <didrocks> pitti: yeah, I'm already doing that with pleasure when I see that apt install -y ubuntu-desktop is just upgrading ubuntu-desktop package :p
[17:31] <didrocks> time to go, see you tomorrow guys!
=== xnox is now known as xnox_2016
=== alan_g is now known as alan_g|EOD
=== dpm is now known as dpm-afk
[20:21] <alexarnaud> Good evening everyone !
=== dkessel-cloud is now known as dkessel