[04:55] <didrocks> good morning
[05:24] <pitti> Bonjour tout le monde !
[06:31] <didrocks> pitti: hey! courir à 7h, c'est difficile :)
[06:32] <mvo> pitti: good morning! thanks for the jenkins forward, I saw it last night, working on the fix right now .)
[06:32]  * didrocks has a sad face due to mvo :p
[06:32] <didrocks> hey mvo!
[06:33] <mvo> didrocks: ohhhhh? what happend?
[06:33] <didrocks> mvo: you pushed some code! and thus, you broke me: https://travis-ci.org/didrocks/ubuntu-developer-tools-center ;)
[06:33] <didrocks> python/pkgsrcrecords.cc:91:58: error: ‘class pkgSrcRecords’ has no member named ‘Step’
[06:33] <didrocks> which is exactly what your commit yesterday was :)
[06:33] <mvo> didrocks: yeah, it needs the latest apt from utopic
[06:34] <didrocks> yeah
[06:34] <didrocks> but this box is on precise
[06:34] <didrocks> I wonder if I can tell pip to branch from a tag or commit rev
[06:34] <mvo> didrocks: so time to figure out how to pip build a specific tag I guess :)
[06:34] <didrocks> mvo: hehe, we agree it seems :)
[06:34] <didrocks> if not, I'll have to bzr branch somewhere
[06:34] <didrocks> (you don't have a release branch, right?)
[06:35] <mvo> didrocks: just the debian/sid branch
[06:35] <mvo> didrocks: but that should be tags for each release
[06:35] <didrocks> yeah, I saw a way to due it with pip + vcs
[06:35] <didrocks> do*
[06:35] <didrocks> not yet for bzr, have to look a little bit more
[06:36] <didrocks> hum, seems the @ can work there
[06:37] <mvo> didrocks: yeah, looks like this is what you want https://coderwall.com/p/-wbo5q
[06:38] <didrocks> mvo: right, I was puzzled yesterday and didn't dig more because I tried /trunk@tag…
[06:38] <didrocks> seems you need /trunk/@tag
[06:38] <didrocks> for bzr
[06:39] <mvo> didrocks: ok
[06:39] <didrocks> $ env/bin/pip install -e bzr+lp:python-apt/@0.9.3.5#egg=apt
[06:39] <didrocks> Obtaining apt from bzr+lp:python-apt/@0.9.3.5#egg=apt
[06:39] <didrocks>   Checking out lp:python-apt/ (to revision 0.9.3.5) to ./env/src/apt
[06:39] <didrocks> works \o/
[06:40] <mvo> didrocks: I guess a alternative would be to make python-apt more clever and add a  configure style test, but its python setuptools so that is not trivial (unfortunately)
[06:40] <mvo> well, maybe it is
[06:40] <didrocks> mvo: yeah, I spent a day again recently on setuptools… not that fun :)
[06:41]  * didrocks pushes to unbreak Travis
[06:41] <didrocks> mvo: oh btw, remember that my home server was down? It wasn't anything which broke in software like mysql or whatever. It was the SD card which went down
[06:42]  * didrocks did the switch this week-end with a new one and put /var/log on tmpfs
[06:42] <sarnold> didrocks: out of curiosity, was that a pandaboard? :)
[06:44] <didrocks> sarnold: no, but similar, a raspberry :)
[06:44] <sarnold> didrocks: ah :)
[06:45] <sarnold> didrocks: I spent a few months with a pandaboard that would wedge from time to time, and eventually irssi would refuse to start no matter how many reboots I tried. I hadn't realized sd cards were so fragile..
[06:45] <sarnold> cripes, mysql on a raspberry? how'd it work? :)
[06:45] <didrocks> sarnold: yeah, mostly it's /var/log in my case as it's a webserver (didrocks.fr)
[06:45] <didrocks> sarnold: the website and mysql are on usb drives :)
[06:45] <sarnold> didrocks: ahhhh. that'd help.
[06:46] <didrocks> yeah, not *that* crazy :)
[07:17] <mvo> didrocks: I don't want you to have a sad face: http://paste.ubuntu.com/7627300/ - configure for poor people
[07:17] <mvo> (like me)
[07:20] <didrocks> mvo: looks excellent nice trick :) (even if it can see being twisted to generate a config.h from setup.py, I think it's way easier compare to what we can achieve directly with setuptools)
[07:21] <mvo> didrocks: oh, I wasn't aware that it supports this kind of tests
[07:22] <didrocks> mvo: there was something I found the other day, I'll give it a look again later, but it wasn't as readable as what you did IIRC
[07:25] <mvo> didrocks: if you can point me to it, I'm happy to have a look - I wait for adt test runs to finish on my local machine, so I have some time :/
[07:29] <pitti> bonjour didrocks ! je suis retour de courier; c'était plus facile aujourd'hui, il a plu cette nuit
[07:29] <pitti> mvo: guten Morgen! danke
[07:29] <didrocks> mvo: it was with https://pythonhosted.org/setuptools/setuptools.html#configuration-file-options and what setopt was doing
[07:30] <didrocks> mvo: and the feature class: https://bitbucket.org/tarek/distribute/src/f4170897eb2c/setuptools/dist.py#cl-664
[07:30] <didrocks> (from what I read, Tarek move it from distribute to setuptools)
[07:30] <didrocks> pitti: quelle chance! ici, il a plu, mais bon, il fait toujours chaud…
[07:31] <pitti> didrocks: ici aussi :)
[07:32] <mvo> thanks didrocks
[07:33] <didrocks> mvo: yw, keep me posted if you find anything interesting!
[07:33] <mvo> didrocks: will do
[07:36] <mvo> pitti: sorry for bothering you, but when i do lxc-ls I can see my utopic container, but when I run adt-run --- adt-virt-lxc utopic it complains that "Error: container utopic is not defined". that seems to be coming from lxc-clone -o utopic. have you seen that before?
[07:37] <pitti> mvo: yes, that's trying to use per-user containers as you don't run the thing as root
[07:37] <pitti> mvo: you usually want --- lxc -es utopic
[07:37] <pitti> mvo: you usually want --- lxc -es adt-utopic
[07:37] <mvo> pitti: oh, silly me, thanks! that does the trick
[07:37] <pitti> mvo: -s -> run lxc commands through sudo, -e -> use ephemeral overlays (much much faster)
[07:38] <pitti> mvo: if you use adt-build-lxc, the name is "adt-<release>", not just <release>
[07:39] <mvo> cool, thanks a bunch
[07:40] <pitti> mvo: gern :)
[07:41] <didrocks> mvo: do you have a mock python-apt instance? (or using it to open my own fake dpkg installation where I can set a state, install pkgs and so on?)
[07:43] <didrocks> seems you are using some kinds of         repo_path = os.path.abspath("./data/test-repo")
[07:43] <didrocks> in the python-apt tests
[07:44] <mvo> didrocks: *cough* yeah, the tests need to run in the tests dir, thats silly
[07:45] <pitti> didrocks: apt.Cache(rootdir=chroot.path) is really nice for that
[07:45] <mvo> didrocks: you can setup the cache with a alternative rootdir, if you then set dir::bin::dpkg to point to a shell wrapper that will work
[07:46] <mvo> didrocks: the shell wrapper needs to set --force-not-root --force-bad-path --root=your-new-rootdir
[07:46] <mvo> didrocks: and then you can even install into this alternative rootdir
[07:46] <didrocks> and the rootdir needs to contains a Packages.gz for an archive state?
[07:46] <mvo> didrocks: well, depends on how far you want to go, you can only include etc/apt/sources.list and call cache.update() so that it gets it itself
[07:47] <mvo> didrocks: or you can provide static data
[07:47] <mvo> didrocks: in var/lib/apt/lists/foo_Packages
[07:48] <didrocks> mvo: pitti: thanks! I guess that's the info I needed :) I'll work on that today to have what I need under tests :)
[08:00] <seb128> good morning desktopers
[08:00] <didrocks> salut seb128
[08:00] <seb128> didrocks, lut!
[08:04] <pitti> bonojur seb128
[08:05] <seb128> pitti, salut! ça va ?
[08:05] <Laney> hey hey
[08:05] <seb128> hey Laney
[08:05] <seb128> how are you?
[08:06] <pitti> seb128: ça va bien ! j'ai couru tous les matins cette semaine, avant qu'il fait chaud :)
[08:06] <pitti> hey Laney, good morning
[08:06] <pitti> seb128: et toi ?
[08:06] <seb128> pitti, tu es comme Didier ;-)
[08:06] <seb128> je viens de me lever moi !
[08:07] <pitti> seb128: je ne peux pas aller à Taekwondo aujourd'hui, à cause de USO
[08:07] <pitti> UOS
[08:07] <seb128> tu as une session qui t'intéresse ce soir ?
[08:08] <pitti> seb128: pas une, deux à meme temps..
[08:08] <Laney> hey seb128 & pitti
[08:08] <pitti> langpacks for touch and systemd for servers
[08:08] <Laney> I'm doing good thanks!
[08:08] <Laney> seems it's not as warm here as it is for you guys ...
[08:09] <didrocks> seb128: j'ai aussi couru pour info (à 6h50)
[08:09] <didrocks> c'était difficile par contre ce matin… le corps n'était pas réveillé :)
[08:10] <didrocks> Laney: well, it's "only" 31 today \o/
[08:10] <Laney> nice...
[08:10] <Laney> is that "shut all of the blinds"?
[08:11] <didrocks> I don't, I don't like darkness :)
[08:11] <didrocks> already, shut all windows
[08:11] <didrocks> stay on the north side
[08:11] <didrocks> and suffer
[08:11] <Laney> work from the cold shower
[08:12] <didrocks> I would really like a water proof laptop and work from a swimming pool
[08:12] <didrocks> *that* would be life!
[08:12] <Laney> expenses time!
[08:12] <pitti> didrocks: my wife has a Toughbook for work, that might do :)
[08:12]  * didrocks files one
[08:13] <ogra_> you can have your rain back if you want !
[08:13] <didrocks> pitti: ahah, yeah! I don't see the water proof part though :)
[08:13] <ogra_> and that golfball sized hail
[08:13] <didrocks> ogra_: waow, any damage?
[08:13] <ogra_> nope, luckily not
[08:14] <ogra_> we have a large glass brick wall (4x3m) ... it was like a concert having the hail hammer it
[08:14] <Laney> don't want to be outside in that...
[08:15] <ogra_> astonishingly nothing broke, even the solar panel on the roof is still fine
[08:17] <Laney> seb128: pmcgowan: There's no dep problem with cross-building u-s-s for armhf that I can see
[08:18] <Laney> it doesn't build though, but for another reason
[08:21] <Laney> /usr/lib/arm-linux-gnueabihf/libapt-pkg.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20'
[08:21] <Laney> this reason
[08:21] <Laney> say what
[08:31] <seb128> Laney, hum, abi change somewhere?
[08:31] <seb128> didrocks, 6h50, ça pique les yeux !
[08:32] <pitti> seb128: non, c'est un bon temps, dans l'été :)
[08:33] <pitti> Laney: in case it happened recently: seems we recently switched the default g++ compiler from 4.8 to 4.9? at least my dist-upgrade this morning brought this in, and marked 4.8 for auto-removal
[08:34] <Laney> lrwxrwxrwx 1 root root 27 Feb 26 14:21 /usr/bin/arm-linux-gnueabihf-g++ -> arm-linux-gnueabihf-g++-4.8
[08:36] <Laney> I think the cross building defaults are done separately
[08:37] <didrocks> seb128: ouai, c'est ce que je me suis dit :)
[08:38] <seb128> larsu, Laney: did you get anywhere with the GTK build?
[08:38] <larsu> seb128: working on it right now
[08:38] <larsu> trying to find commits to backport from master
[08:46] <larsu> Laney: I'm having trouble with the gcc 4.9 update, maybe that's related?
[08:46] <larsu> dpkg: error processing archive /var/cache/apt/archives/gcc-doc_4%3a4.9.0-3ubuntu1_amd64.deb (--unpack):
[08:49] <larsu> ah, install-info is missing the --dir-file parameter
[08:50] <Laney> hm?
[08:50] <larsu> install-info: No dir file specified; try --help for more information.
[08:51] <Laney> you get that when upgrading?
[08:51] <larsu> yes
[08:51] <Laney> ddddddooooooooookkkkkkoooooooooooooooooooooooooooooo
[08:51] <larsu> postinst has the install-info lines, but they're missing that param
[08:51] <larsu> haha
[08:51] <Laney> oh yeah, me too!
[08:51] <larsu> unrelated to your issue of course (now that I've had an actual look at it)
[08:52] <Laney> actually mine is different, that's weird
[08:52] <Laney> Error in `/usr/share/doc-base/gcc-4.9-itm', line 29: format `html' already defined.
[08:52] <larsu> for the same package?
[08:52] <Laney> gcc-doc
[08:52] <larsu> right
[08:54] <Laney> There must be at least one such a section. If there are more, each of them must register files in different formats (e.g. having two Format: HTML sections in one control file is not allowed).
[08:54] <Laney> dear oh dear
[08:54] <Laney> ah yes, if I fix that then I see your error
[08:54] <Laney> okay, building u-s-s without proposed works
[08:54] <larsu> I wonder why I don't get that one
[08:54]  * Laney suspects the new apt
[08:55] <seb128> mvo !!!
[08:55] <Laney> let me check this theory first :P
[08:55] <seb128> Laney, do you know if sbuild complaining about "grep: debian/control: No such file or directory" a standard gotcha or something
[08:55] <Laney> never seen that
[08:56] <Laney> how did you get it?
[08:56] <seb128> sbuild -d utopic --host armhd ubuntu-system-settings*.dsc
[08:56] <seb128> hf
[08:56] <seb128> (sorry typing from another box)
[08:56] <Laney> did you build the chroot right?
[08:57] <Laney> I think you can get No such file or directory if you try to execute wrong-architecture binaries
[08:57] <Laney> mk-sbuild utopic --target=armhf
[08:58] <seb128> I created it using "mk-sbuild --target=armhf --skip-proposed utopic"
[09:01]  * Laney tries
[09:01] <Laney> also yes, it does build with downgraded apt
[09:09] <seb128> Laney, is sbuild logging somewhere?
[09:10] <seb128> in fact it does "E: Core build dependencies not satisfied; skipping"
[09:11] <Laney> it makes a .build file in the current directory
[09:12] <Laney> I just made a new chroot and it seems to be working for me
[09:17] <Laney> yeah it built
[09:17] <Laney> that doesn't let me be very helpful, sorry
[09:18] <seb128> Laney, do you see what's wrong in http://paste.ubuntu.com/7627690/ ?
[09:18] <Laney> yes
[09:18] <Laney> Please generate a key with 'sbuild-update --keygen'
[09:24] <seb128> Laney, thanks, that seems to work
[09:24] <seb128> shrug, https://wiki.ubuntu.com/Touch/CrossCompile could mention it
[09:24] <seb128> or is the "Note - you may want to use -n to disable sbuild's automatic build log email feature which is enabled by default" the suggested workaround for that issue?
[09:24] <Laney> let's make it so
[09:24] <Laney> no
[09:25] <Laney> there we go
[09:25] <seb128> Laney, should I just add $ sbuild-update --keygen to the first section there?
[09:25] <Laney> I did it ;-)
[09:26] <seb128> thanks ;-)
[09:27]  * seb128 does the same to https://wiki.ubuntu.com/CrossBuilding
[09:27] <mvo> seb128: hm, what failed? Laney do you have the full output of the failed gcc-doc?
[09:27] <seb128> mvo, <Laney> /usr/lib/arm-linux-gnueabihf/libapt-pkg.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20'
[09:28] <Laney> mvo: don't worry about gcc-doc, that was a separate problem
[09:28] <Laney> mvo: just filed https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1328838
[09:35] <mvo> seb128: eehhh
[09:35] <mvo> seb128: no idea right now, can check after lunch
[09:35] <seb128> mvo, thanks
[09:35] <seb128> could be a doko issue...
[10:15] <mvo> pitti: for the click autopkgtests I assume I should do the same as I do for apt, i.e. run against the installed click instead of the build tree click (or would it make sense to run against both?)
[10:16] <pitti> mvo: right, against installed click; you can run the tests against the built click during package build, there's little need to repeat them in autopkgtest
[10:17] <pitti> mvo: also, for autopkgtest you often don't need to run the entire upstream test suite; it's usually enough to exercise some "smoke test", i. e. make sure you can build and install some click package
[10:17] <mvo> pitti: the integration tests are pretty heavyweight currently as they build a full click buld chroot
[10:17] <pitti> ah
[10:17] <pitti> mvo: and you don't want to do that during pacakge build then, I suppose?
[10:17] <mvo> pitti: yeah
[10:17] <mvo> pitti: it will take forever on a slow arch
[10:18] <mvo> pitti: the unittests are run of course
[10:18] <pitti> mvo: right, so run them against the installed click in autopkgtest (but notice that we also run the autopkgtests on armhf)
[10:19] <mvo> pitti: ok, will do
[10:20] <mvo> pitti: thanks for your help :)
[10:20] <pitti> gern!
[10:23] <seb128> pitti, hey, did you see my ping about that udisk bug yesterday? do you think it's something you might have cycle to look at? (just asking, if you don't that's fine, we just need to find somebody to look at it then)
[10:23] <seb128> https://bugs.launchpad.net/oem-priority/+bug/1294877
[10:23] <pitti> seb128: yes, I did (and I also saw it in bug mail); not my top priority right now, but I suppose I can get to it in the next weeks
[10:24] <seb128> pitti, ok, if you start looking at it, please let me know ... I'm going to do the same if we do work on it
[10:24] <pitti> seb128: will do, thanks
[10:25] <seb128> pitti, ara pinged about it, it's making the recovery-media-creation tool, used on oobe pre-installed system, bug for quite some users
[10:25] <seb128> so it's on the LTS .1 tofix list
[10:29] <tseliot> seb128: hey, I can't find the new unity-settings-daemon in trusty. How's the SRU going?
[10:29] <seb128> tseliot, https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=unity-settings-daemon
[10:30] <seb128> tseliot, you might want to gently ask the SRU team about getting it reviewed from the queue ;-)
[10:30] <seb128> tseliot, having it accepted would let us free the silo as well, which would be welcome
[10:30] <tseliot> seb128: oh, ok, I thought you'd deal with that too
[10:30] <seb128> well "deal with that"
[10:30] <seb128> I can ping them
[10:31] <seb128> I'm not in the SRU team myself, so I can't review/approve it
[10:31] <tseliot> seb128: somehow I thought you were part of that team. If you could ping them for me, that would be very welcome
[10:32] <Laney> tjaalton: did you see my q about weston yesterday?
[10:33] <seb128> tseliot, k
[10:33] <tseliot> seb128: thanks
[10:43] <Laney> tjaalton: ah sorry, just saw your /away
[10:51] <didrocks> phew, finally got some start of the apt test env in the chroot I need :)
[10:52] <seb128> didrocks, did you fix your issue with the new python-apt version?
[10:52] <didrocks> seb128: oh yeah, quite early in the morning even :)
[10:52] <seb128> nice
[11:46] <didrocks> mvo: based on what you told me this morning, shouldn't apt.apt_pkg.config.set("Dir::Bin::dpkg", "/usr/bin/dpkg2") should fail cache.commit() as it doesn't exist?
[11:47] <didrocks> I wonder why cache.commit() returns true even if the stdout is: debconf: DbDriver "passwords" warning: could not open /var/cache/debconf/passwords.dat: Permission non accordée
[11:47] <didrocks> (permission denied)
[11:47] <didrocks> so maybe it never goes to execute dpkg?
[11:47] <mvo> didrocks: thats a red-herring
[11:47] <mvo> didrocks: with dir::bin::dpkg change it should fail, does it not do that?
[11:48] <didrocks> mvo: yeah, same output and "True"
[11:48] <didrocks> mvo: and it can't install it anyway, I'm not root in that ipython
[12:11] <didrocks> mvo: do you know where you have those kinds of tests? Maybe basing on that, I'll be able to see what I'm doing wrong or missing
[12:11] <didrocks> (python-apt doesn't have test overriding dpkg binary)
[12:12] <mvo> didrocks: https://github.com/mvo5/apt/blob/debian/sid/test/integration/framework#L124
[12:12] <mvo> didrocks: but if you point me to the code you have I can poke around too
[12:13] <didrocks> mvo: yeah, that's some shell scripts, let me try to give you a minimal test you can play with, one sec
[12:30] <didrocks> mvo: here is a simple gist: https://gist.github.com/didrocks/afc625607feab0432e4e
[12:30] <didrocks> it can't install the package because: /usr/bin/dpkg2 doesn't exist (nor the deb)
[12:49] <mvo> didrocks: thanks, I get to it in some minutes, still wrestling with adt, I got distracted by the fact that the unittests fail badly in there and I tried to figure out why, I suspected that LD_PRELOAD is problematic but I can't see anything in adt-run that would prevent it
[12:50] <mvo> (LD_PRELOAD is used in the tests to mock certain libc/libclick symbols)
[12:50] <didrocks> mvo: it wouldn't be the first time (even not at canonical/ubuntu) that I hear about LD_PRELOAD puzzling devs for some tests failing :) good luck!
[12:55] <mvo> didrocks: its just hard to debug, oh well
[12:57] <xnox> mvo: hm, i thought eatmydata is ldpreloaded when running tests, or maybe i am wrong. Let me check.
[12:57] <mvo> xnox: yeah, that used to be the case, not sure if it still is
[12:58] <dro|desrt> saluton, amikoj!
[13:02] <xnox> seb128: porce #ubuntu-desktop sessao Espanol?
[13:02] <xnox> http://pad.ubuntu.com/uos-1406-unity8-desktop-preview-image
[13:05] <xnox> seb128: hm looks like somebody translated it.
[13:05] <didrocks> funny :)
[13:06] <seb128> xnox, wth?
[13:06] <seb128> xnox, seems it was done in http://pad.ubuntu.com/ep/pad/view/uos-1406-unity8-desktop-preview-image/rev.309
[13:06] <xnox> seb128: scrolling through history "unnamed participants" translated it all
[13:07] <seb128> or 308 even
[13:07] <seb128> yeah
[13:07] <didrocks> yeah, 308, "unamed
[13:07] <didrocks> "
[13:07] <didrocks> at least, it's easy to revert (I was going to do that)
[13:07] <xnox> seb128: yeah, i've revert it now.
[13:07] <xnox> (well added english back in)
[13:07] <seb128> well, I copied the workitems to the blueprint
[13:07] <seb128> so I don't care much about the notes
[13:08] <Laney> haha
[13:08] <tjaalton> Laney: yeah go wild wild weston :)
[13:08] <xnox> not sure if we need to check other etherpads for portugeese.
[13:08] <Laney> tjaalton: thanks, already did it ;-)
[13:08] <ogra_> seb128, time to expense a spanish class :)
[13:08] <tjaalton> Laney: cool
[13:08] <seb128> lol
[13:09]  * xnox ponders if google translate did it!
[13:10] <pmcgowan> seb128, so my deps problem resolved itself but I saw there were issues with ftbfs
[13:10] <xnox> seb128: lol, google translate did it
[13:11] <seb128> xnox, google!
[13:11] <seb128> pmcgowan, there is an issue with libapt today it seems
[13:11] <Laney> you can build it without utopic-proposed
[13:12]  * Laney has been doing just that for the MP that just went up
[13:19] <seb128> yeah, I cross built earlier today (using utopic without proposed enabled) and it worked
[13:52]  * dro|desrt eyes clang, suspiciously
[13:53]  * dro|desrt is a big fan of compilers that claim to be other compilers but don't implement their features
[13:54] <larsu> hm? Because clang uses gcc's command line syntax?
[13:54] <dro|desrt> more like because it defines __GNUC__
[13:54] <larsu> oh.
[13:54] <larsu> morning dro|desrt :)
[13:54] <dro|desrt> my atomic improvements broke clang :(
[13:57] <larsu> is anyone using that in production?
[13:57] <larsu> oh, osx I guess
[13:58] <dro|desrt> freebsd 10 as well
[13:58]  * dro|desrt got a bug filed this morning
[13:58] <dro|desrt> (regular jhbuilding doing its job...)
[14:03] <didrocks> mvo: after a break on other things, I retried to have a look, seems like pkg.marked_install is always False, even after the mark_install() call, so maybe the first issue is that? (and so commit() would be almost a no-op, hence the no failure)
[14:04] <mvo> didrocks: hm, you can set apt_pkg.config.set("Debug::pkgProblemResolver", "1") to see why this is
[14:04] <mvo> didrocks: sounds like some dependency that can not be installed maybe?
[14:04] <didrocks> mvo: oh, that would be possible
[14:05] <didrocks> mvo: however, mark_install(), even with the pkgProblemResolver set doesn't return anything
[14:05]  * didrocks reloads the cache
[14:05]  * didrocks tries with a simplier fake repo, with a couple of packages
[14:05] <didrocks> which are all installable
[14:08] <mvo> didrocks: you made me clone it now
[14:08] <didrocks> mvo: no no, concentrate on your adt tests, I didn't want to annoy you (yet ;))
[14:11] <didrocks> mvo: yeah, STOPPPP! it was because of the deps of my mock (abrowser)
[14:11] <didrocks> mvo: weird that mark_install() doesn't say a thing and that commit() returns True
[14:11] <mvo> didrocks: *cough* api sucks
[14:11] <mvo> didrocks: it should probalby return false or raise if it can not be installed
[14:13] <mvo> didrocks: tests are postponed for now btw
[14:13] <mvo> didrocks: well, I made them work
[14:13] <didrocks> mvo: right, I would have expected mark_install() to raise or return False
[14:13] <didrocks> I understand that for "commit()" there is nothing to do then :)
[14:14] <didrocks> ok, so now that it uses my wrapper, next step, seems it wants "var/lib/dpkg/available"
[14:14]  * didrocks fulfills one by one all requirements :)
[14:15] <mvo> didrocks: silly dpkg
[14:15] <mvo> ;)
[14:16] <mvo> didrocks: hm, we currently always return None, so returning true/false shouldn't be too terrible API wise
[14:20] <didrocks> mvo: ah, that would be nice, as I think it's as that moment that we can take the best counter-solution
[14:20]  * didrocks creates all files and directories one by one for this poor dpkg :)
[14:21] <didrocks> ah, interesting error this time:
[14:22] <didrocks> dpkg: error processing archive /home/didrocks/work/ubuntu-developer-tools-center/tests/data/apt/testpackage2_0.0.1_all.deb (--install):
[14:22] <didrocks>  error setting ownership of `/tmp/root/usr.dpkg-new': Operation not permitted
[14:23] <mvo> didrocks: fakeroot
[14:23] <mvo> didrocks: does that help?
[14:24] <didrocks> mvo: indeed
[14:24] <didrocks> so --force-not-root isn't enough
[14:26] <didrocks> but at least, installing and removing through apt in the chroot works now :)
[14:27]  * didrocks puts all the directories and file creation recipe in setUp()
[14:34] <larsu> seb128, Laney: pushed gtk 3.12 test fixes to lp:~larsu/gtk/3-12-test-fixes (sorry it took so long)
[14:34] <larsu> ah wait, that one patch doesn't apply
[14:34]  * larsu should wait until building the package before announcing stuff
[14:36] <seb128> larsu, waiting ;-)
[14:38] <larsu> hm, this change must be introduced by an earlier patch...
[14:38]  * larsu quilts
[14:41]  * larsu slaps himself
[14:42] <seb128> larsu, what was it?
[14:43] <larsu> seb128: the one patch I added needs to be a revert, but wasnt
[14:43] <seb128> oh ok
[14:43] <seb128> speaking of which, it would be cool if there was a "revert diff" tool
[14:43] <seb128> (mentioning it in case somebody knows of one ;-)
[14:43] <larsu> patch -R?
[14:43] <Laney> interdiff diff /dev/null
[14:44] <seb128> larsu, patch -R works to apply a reversed patch, not to add it to a quilt serie
[14:44] <seb128> you need to apply then diff manually
[14:44] <seb128> Laney, thanks
[14:44]  * seb128 tries
[14:45] <larsu> right, I do it in a vcs checkout
[14:45] <larsu> and do a diff after
[14:45] <seb128> right
[14:45] <seb128> which I usually do
[14:45] <larsu> could also use git revert, which does the same thing
[14:45] <seb128> but it's a few steps
[14:45]  * seb128 notes the interdiff tip from Laney
[14:50] <larsu> and all of a sudden, bzr bd doesn't want to build anymore
[14:50] <larsu> dpkg-checkbuilddeps: Unmet build dependencies: dpkg-dev (>= 1.16.0)
[14:50] <larsu> this worked 5 minutes ago
[14:51]  * larsu pushes anyway for Laney and seb128 to have a look
[14:51] <seb128> larsu, did you uninstall anything?
[14:51] <seb128> dpkg -l | grep dpkg-dev
[14:52] <larsu> iU dpkg-dev
[14:52] <larsu> I didn't install or uninstall anything - and I can't right now because of the gcc-doc failure
[14:52] <seb128> k
[14:52] <seb128> well, it's Uinstalled
[14:53] <seb128> it was just failing before hitting the build-depends check before, because the patch was not applying
[14:53] <larsu> doesn't it usually print what patches it tries to apply?
[14:53] <larsu> anyhow, please have a look at the branch when you have time
[14:54] <seb128> it does, but at the build time
[14:54] <seb128> not when preparing the source iirc
[14:54] <seb128> it's prepare the source (which failed before because patch didn't apply)
[14:54] <seb128> check build-depends
[14:54] <seb128> build
[14:54] <larsu> okay
[14:54] <seb128> Laney, there? can you throw that to your sbuild?
[14:55] <larsu> any news on the gcc-doc thing?
[14:55] <Laney> https://launchpad.net/ubuntu/+source/gcc-defaults/1.128ubuntu2
[14:56] <seb128> larsu, it's published, you might want to refresh/retry
[14:56] <larsu> just did, same issue
[14:56] <seb128> :-(
[14:56] <seb128> well it might be that you need manually hacking around
[14:56] <Laney> did you get the new one?
[14:56] <seb128> if it hits issues with the old version
[14:57] <seb128> like in the prerm of the installed one
[14:57] <larsu> Laney: trying to find out, but the version of gcc-doc seems different from the gcc-defaults one?!
[14:57] <seb128> larsu, can you pastebin the log of your error?
[14:57]  * larsu cleans the cache just in case
[14:58] <larsu> seb128: http://paste.ubuntu.com/7628968/
[14:59] <larsu> ah, the old script crashes but it doesn't try the new one since there isn't one
[15:00] <larsu> this is an interesting case
[15:00] <seb128> larsu, try to sudo rm /lib/dpkg/info/gcc-doc.prerm
[15:01] <larsu> there's no lib/dpkg
[15:01] <seb128> shrug
[15:01] <seb128> larsu, /var/lib/dpkg/info
[15:01] <larsu> yep
[15:01] <larsu> seb128: thansk!
[15:02] <seb128> larsu, worked?
[15:03] <larsu> yes
[15:03] <seb128> \o/
[15:03] <seb128> larsu, and now you know why people want system-image updates ;-)
[15:03] <seb128> Laney, can you test build lp:~larsu/gtk/3-12-test-fixes ?
[15:03] <Laney> ok
[15:04] <seb128> Laney, I don't have a clean utopic chroot
[15:04] <seb128> thanks
[15:05] <larsu> seb128: ya
[15:06] <larsu> it did work for Laney in the chroot before, no?
[15:06] <Laney> no
[15:06] <larsu> ah okay
[15:06] <larsu> good :)
[15:06] <Laney> only when the tests were accidentally disabled
[15:07] <Laney> you went for the disabling tests route?
[15:07] <larsu> yes, but not the full dump-a11y test, only the offending ones
[15:07] <larsu> I spent some time trying to untangle the fixes, but it was close to impossible
[15:08] <Laney> okay
[15:08] <larsu> some widgets only got updated after 3.12, but the test fixes for those were in the same patches
[15:08] <Laney> shouldn't the revert be a part of your other patch which makes the change?
[15:09] <Laney> you want it in the patches submitted upstream I think
[15:09] <larsu> hm, good point
[15:09] <Laney> or the test should ensure the setting is true
[15:09] <larsu> it does
[15:09] <Laney> why does it fail then?
[15:10] <larsu> I guess it simply didn't work at all
[15:10] <Laney> or you changed something for the true case too maybe
[15:11] <larsu> I'll put the reverts in the patches, but I need to change location first. will be back in 10 minutes or so
[15:11] <Laney> this is okay for distro
[15:11] <Laney> but I think you want the upstream bug to have it too one way or another
[15:16] <Laney> seb128: this builds
[15:16] <larsu> Laney: not sure tbh - nobody seems to have cared about the tests until now
[15:16] <seb128> Laney, let's ship it!
[15:16] <seb128> Laney, thanks ;-)
[15:16] <seb128> Laney, did you want to do the upload or should I?
[15:17] <Laney> i can
[15:17] <seb128> ok, thanks
[15:17] <Laney> larsu: that sounds concerning
[15:17] <seb128> I'm going to let you do it, since you seem to have changes to do in mind
[15:17] <Laney> don't they get run in continuous or something?
[15:17] <seb128> it's going to be easier than me trying to understand what's the status of the discussion between you and larsu
[15:18] <larsu> Laney: ah wait, the tests only fail on unity,n o?
[15:18] <Laney> no
[15:18] <Laney> there's no unity inside the build chroot
[15:19] <larsu> okay, then nobody noticed?! this is on the 3.12 branch
[15:19] <larsu> not sure if that has continuous testing
[15:19] <Laney> strange
[15:36] <Laney> larsu: http://paste.debian.net/104486/ I was getting at something like this
[15:36] <Laney> or maybe check both true and false with 2 and 1 respectively
[15:36] <Laney> uploaded, btw
[15:38] <larsu> Laney: ah, right. This would mirror the code in a11y-dump.c
[15:38] <larsu> ya, I'll add that to the patch
[15:38] <Laney> that kind of thing
[15:38] <Laney> yep
[15:39] <larsu> still, the colorchooser is broken upstream. I'm preparing a patch myself now instead of trying to backport it from master (becasue of the untabgling problem I talked baout earlier)
[15:41] <Laney> yep
[15:41] <Laney> three breakages, this is only for one of them
[16:13] <seb128> Laney, larsu: https://launchpad.net/ubuntu/+source/gtk+3.0/3.12.2-0ubuntu2 ... GTK build is happy!
[16:13] <larsu> yay
[16:38] <didrocks> mvo_: ok, now that I can play with "weird" states, I can see that for instance, if dpkg returns 1, error() from InstallProgress isn't called, but finish_update() still is (even if you raised an exception around commit()… Not sure if that's wanted.
[16:42] <seb128> charles, tedg: we can discuss it there if you prefer, less noisy
[16:42] <seb128> tedg, "logout" is well hidden to start, since indicator-session has no icon in the panel, then it doesn't work...
[16:43] <charles> heh
[16:43] <charles> that's not the first time indicator-session's lost its icon :/
[16:43] <seb128> charles, it's under unity8, I never saw it there I think
[16:44] <charles> so the real test would be to see if indictor-session -> logout works under unity8
[16:44] <charles> since it's not, the next test would be
[16:44] <charles> to watch dbus and see what indicator-session is calling when Logout gets clicked
[16:44] <seb128> charles, tedg: https://code.launchpad.net/~paulliu/unity8/logout/+merge/216373 didn't land
[16:44] <seb128> I would think it's a pre-require?
[16:45] <charles> seb128, that'll need to land in order for logout to work property, yes
[16:45] <seb128> ok, so that explains why it doesn't work
[16:45] <charles> ya
[16:46] <tedg> charles, Should we just wait and silo these together?
[16:46] <seb128> tedg, you were wrong saying that it should work on stock utopic it seems
[16:46] <tedg> Yeah, I didn't realize that hadn't landed.
[16:46] <charles> if com.canonical.Unity.Session isn't sitting on the bus, indicator-session will fall back to making the gnome logout call
[16:46] <seb128> it would make sense to silo them together
[16:46] <seb128> though we can as well land indicator-session now it if creates no new issue
[16:47] <charles> it doesn't create any new issue
[16:47] <charles> but we won't know that it works until the two patches are tested together
[16:47] <seb128> right, there is little point landing it
[16:47] <seb128> out of the freeing that silo
[16:47] <charles> well, there is that
[16:48] <charles> I don't mind either way
[16:48] <tedg> I'm happy either way. Like getting the MR queue down, it's kinda dead code.
[16:48] <tedg> (today)
[16:48] <seb128> tedg, the only issue is that it might have bugs, but we are not going to know until we have unity8 to test
[16:48] <seb128> but then we add a bugfix mr to the unity8 landing if that's the case
[16:50] <tedg> Yup, it's pretty straight forward on our side. I wouldnt' expect too many bugs, but you never know until you can test it.
[16:50] <tedg> Integration is hard :-)
[16:51] <seb128> tedg, so what do you want to do? land it or clear it?
[16:51] <charles> let's see what timeframe paulliu is looking at for ux-gnueabihf/libQt5Core.so.5.2.1
[16:51] <charles> cd /tmp/buildd/unity8-7.88+14.10.20140606bzr849pkg0utopic212/obj-arm-linux-gnueabihf/tests/mocks/liblightdm/single-passphrase && /usr/bin/cmake -E cmake_symlink_library liblightdm-qt5-3.so.0 liblightdm-qt5-3.so.0 liblightdm-qt5-3.so
[16:51] <charles> make[4]: Leaving directory '/tmp/buildd/unity8-7.88+14.10.20140606bzr849pkg0utopic212/obj-arm-linux-gnueabihf'
[16:51] <charles> /usr/bin/cmake -E cmake_progress_report /tmp/buildd/unity8-7.88+14.10.20140606bzr849pkg0utopic212/obj-arm-linux-gnueabihf/CMakeFiles  35
[16:51] <charles> Built target MockLightDM-single-passphrase
[16:51] <charles> make[3]: Leaving directory '/tmp/buildd/unity8-7.88+14.10.20140606bzr849pkg0utopic212/obj-arm-linux-gnueabihf'
[16:51] <charles> Makefile:126: recipe for target 'all' failed
[16:52] <tedg> Heh
[16:52] <charles> gah, sorry. I was cleaning my clipboard and it went off
[16:52] <charles> let's see what timeframe paulliu is looking at for his MR
[16:52] <tedg> Pinged in #ubuntu-unity
[16:52] <seb128> thanks
[16:59] <mvo_> didrocks: uh, that sounds wrong
[17:00] <didrocks> mvo_: ok, I'm not *that* crazy then :)
[17:00] <mvo_> didrocks: it might be a artifact or a bug
[17:00] <mvo_> didrocks: is your code somewhere?
[17:01] <mvo_> didrocks: I would like to have a look again
[17:04] <mvo_> didrocks: oh, error() is only called when there is a dpkg error (like a error condition reported by dpkg)
[17:05] <mvo_> didrocks: is that maybe misleading?
[17:24] <didrocks> mvo_: oh sorry, didn't see your message (this windows was focused, so no notification)
[17:24] <didrocks> mvo_: so, I just exit 1 in my dpkg wrapper and I don't see error() to be called
[17:25] <didrocks> mvo_: I'll clean this up and give you a real test case tomorrow morning, does this work?
[17:25] <mvo_> didrocks: aha, thats expected (but I agree that its a bit counter-intuitive)
[17:25] <mvo_> didrocks: maybe the error() docstring needs to be clear that its about errors from packages :/
[17:25] <mvo_> didrocks: but +1 for tomorrow, need to prepare a session
[17:25]  * mvo_ waves
[17:26] <didrocks> mvo_: should the update_done() still being called?
[17:26] <didrocks> yeah, let's discuss that tomorrow :)
[17:26] <didrocks> enjoy your session!
[18:10] <Laney> seb128: nice, looks like it's blocking on aptdaemon test failure though
[18:10] <Laney> which started with the new upload
[18:11] <Laney> mmmmmvvvvvooooooooooooooooooo
[18:11] <mvo_> Laney: *weeehhh*
[18:14]  * Laney screams into the sky
[18:40] <mvo_> Laney: sorry for that, I will look at it tomorrow morning
[19:33] <seb128> chrisccoulson, hey
[19:34] <seb128> chrisccoulson, what's the status of the webbrowser fix for unity8-desktop-mir sessions?
[19:34] <seb128> chrisccoulson, it was just mentioned in the session about desktop running clicks
[19:52]  * tedg likes watching mvo read irc
[19:53] <tedg> :-)
[20:05] <mvo_> tedg: :) its this whole UOS is a bit confusing, but I feel like I should help the people watchng the video later when there is no live-irc to watch
[20:05] <mvo_> in parallel
[20:05] <tedg> mvo_, Yeah, in general the sessions happen in context of lots of stuff.
[20:06]  * mvo_ nods
[20:06] <tedg> mvo_, They might be interesting from an archaeological perspective someday :-)
[20:06] <mvo_> lol
[20:06] <mvo_> I'm sure I will enjoy watching myself (sorf-of) young in 20y time
[20:06] <tedg> Heh. In a loop. On the holi-projector.
[20:09] <seb128> tedg, rsalveti, charles: the recent indicator-datetime landing started recommending ubuntu-touch-sounds ... which is not described in the changelog, and an universe packages, which creates a component mismatch entry ... does one of you plan to handle the MIR for that source?
[20:09] <seb128> (did that upload got reviewed by somebody with upload rights?)
[20:11] <rsalveti> I did the landing, and the changelog describes the change to use a different alarm sound, but indeed not the new package
[20:11] <rsalveti> but my mistake, forgot to check mir
[20:12] <seb128> rsalveti, ignore the question about upload rights, so days I forget you are in that set ;-)
[20:12] <seb128> rsalveti, ubuntu-touch-sounds isn't big, it might be fine to bring on the desktop ... was the recommends for touch, or?
[20:13] <seb128> because touch doesn't use recommends
[20:13] <seb128> so either we need to lower that to suggest and rely on the seed to install the sounds
[20:13] <seb128> or we want to bring the sounds on the desktop as well and need to MIR it
[20:13] <seb128> either way works...
[20:14] <rsalveti> the package is already seeded
[20:14] <rsalveti> guess the goal would then to use the same sound on desktop
[20:14] <rsalveti> charles: ^
[20:15] <rsalveti> not sure why the sounds are specific to touch
[20:15] <seb128> well, that's a bit weird, that package only has ringtone and messages sound atm, I think we picked one of those for alarms because we don't have anything better yet
[20:15] <rsalveti> they should just be part of the generic ubuntu sounds package
[20:15] <charles> well, right now we're not playing sounds on desktkop at all
[20:15] <charles> that will probably change as the convergence story comes together
[20:16] <seb128> rsalveti, yeah, it's one of those pieces where it was easier to add a new source
[20:16] <rsalveti> right, but this will be used by unity8-desktop
[20:16] <seb128> the layout and licences are differents
[20:16] <seb128> right, I expect unity8-desktop to seed it
[20:16] <rsalveti> so I guess it might just be easier to MIR it
[20:16] <seb128> k
[20:16] <seb128> I can do that tomorrow if you want
[20:17] <rsalveti> seb128: that would be lovely
[20:17] <charles> seb128, thanks
[20:17] <seb128> k, on my list
[20:17] <seb128> rsalveti, charles: yw
[20:17] <xnox> ** (unity-settings-daemon:2261): WARNING **: Ignoring unknown module 'org.gnome.settings-daemon.plugins.background'
[20:17] <xnox> hm?
[20:18] <seb128> weird indeed
[20:19] <seb128> where do you have that?
[20:22] <seb128> bbiab
[20:28] <tedg> charles, Testing this indicator-power change is kinda a pain, trying to get rid of 20% battery to test the icon with youtube videos.
[20:28] <charles> tedg, that's just one of the burdens you have to shoulder
[20:30]  * charles wonders if there's an app out there deliberately built to burn cycles
[20:30] <charles> (besides Thunderbird, that is)
[20:31]  * tedg thought that was youtube
[20:47] <xnox> seb128: that's in lightdm logs
[20:47] <xnox> seb128: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1329056
[20:47] <xnox> seb128: but i think the logs are miss-matched.
[20:47] <xnox> seb128: as in, they are not from the actual boot failure.
[20:52] <seb128> hum, weird one
[21:31] <robert_ancell> RAOF, up?
[23:48] <RAOF> robert_ancell: Yo!
[23:48] <RAOF> Stupid irc client...
[23:48] <robert_ancell> hah, left it on?
[23:50] <RAOF> No, it just took a strangely long time to resync this morning.
[23:51] <robert_ancell> RAOF, any update on Mir / GTK+ support?
[23:51] <RAOF> robert_ancell: The eventloopy bits, or the other stuff?
[23:51] <robert_ancell> all of it :)
[23:52] <RAOF> I should be able to propose a merge of the eventloopy bit either tomorrow or early next week.
[23:53] <RAOF> Then... we need to design an API for surface-relative surface creation.
[23:54] <robert_ancell> RAOF, any futher thoughts on why we don't just do absolute positioning
[23:56] <RAOF> Well, we'd need to expose quite a lot more information than we currently do to make that useful.
[23:56] <robert_ancell> Such as?
[23:56] <RAOF> And I remain unconvinced that we'll never want to use the flexibility that not exposing the absolute positioning allows.
[23:58] <RAOF> We'd need to expose where the is in the screen coordinate space, after some (but probably not all!) transforms are applied.
[23:58] <RAOF> s/the is/the window is/
[23:59] <RAOF> And update that as, eg: zoom level changes.