[04:55] good morning [05:24] Bonjour tout le monde ! [06:31] pitti: hey! courir à 7h, c'est difficile :) [06:32] 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] hey mvo! [06:33] didrocks: ohhhhh? what happend? [06:33] mvo: you pushed some code! and thus, you broke me: https://travis-ci.org/didrocks/ubuntu-developer-tools-center ;) [06:33] python/pkgsrcrecords.cc:91:58: error: ‘class pkgSrcRecords’ has no member named ‘Step’ [06:33] which is exactly what your commit yesterday was :) [06:33] didrocks: yeah, it needs the latest apt from utopic [06:34] yeah [06:34] but this box is on precise [06:34] I wonder if I can tell pip to branch from a tag or commit rev [06:34] didrocks: so time to figure out how to pip build a specific tag I guess :) [06:34] mvo: hehe, we agree it seems :) [06:34] if not, I'll have to bzr branch somewhere [06:34] (you don't have a release branch, right?) [06:35] didrocks: just the debian/sid branch [06:35] didrocks: but that should be tags for each release [06:35] yeah, I saw a way to due it with pip + vcs [06:35] do* [06:35] not yet for bzr, have to look a little bit more [06:36] hum, seems the @ can work there [06:37] didrocks: yeah, looks like this is what you want https://coderwall.com/p/-wbo5q [06:38] mvo: right, I was puzzled yesterday and didn't dig more because I tried /trunk@tag… [06:38] seems you need /trunk/@tag [06:38] for bzr [06:39] didrocks: ok [06:39] $ env/bin/pip install -e bzr+lp:python-apt/@0.9.3.5#egg=apt [06:39] Obtaining apt from bzr+lp:python-apt/@0.9.3.5#egg=apt [06:39] Checking out lp:python-apt/ (to revision 0.9.3.5) to ./env/src/apt [06:39] works \o/ [06:40] 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] well, maybe it is [06:40] mvo: yeah, I spent a day again recently on setuptools… not that fun :) [06:41] * didrocks pushes to unbreak Travis [06:41] 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] didrocks: out of curiosity, was that a pandaboard? :) [06:44] sarnold: no, but similar, a raspberry :) [06:44] didrocks: ah :) [06:45] 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] cripes, mysql on a raspberry? how'd it work? :) [06:45] sarnold: yeah, mostly it's /var/log in my case as it's a webserver (didrocks.fr) [06:45] sarnold: the website and mysql are on usb drives :) [06:45] didrocks: ahhhh. that'd help. [06:46] yeah, not *that* crazy :) [07:17] didrocks: I don't want you to have a sad face: http://paste.ubuntu.com/7627300/ - configure for poor people [07:17] (like me) [07:20] 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] didrocks: oh, I wasn't aware that it supports this kind of tests [07:22] 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] 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] bonjour didrocks ! je suis retour de courier; c'était plus facile aujourd'hui, il a plu cette nuit [07:29] mvo: guten Morgen! danke [07:29] mvo: it was with https://pythonhosted.org/setuptools/setuptools.html#configuration-file-options and what setopt was doing [07:30] mvo: and the feature class: https://bitbucket.org/tarek/distribute/src/f4170897eb2c/setuptools/dist.py#cl-664 [07:30] (from what I read, Tarek move it from distribute to setuptools) [07:30] pitti: quelle chance! ici, il a plu, mais bon, il fait toujours chaud… [07:31] didrocks: ici aussi :) [07:32] thanks didrocks [07:33] mvo: yw, keep me posted if you find anything interesting! [07:33] didrocks: will do [07:36] 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] mvo: yes, that's trying to use per-user containers as you don't run the thing as root [07:37] mvo: you usually want --- lxc -es utopic [07:37] mvo: you usually want --- lxc -es adt-utopic [07:37] pitti: oh, silly me, thanks! that does the trick [07:37] mvo: -s -> run lxc commands through sudo, -e -> use ephemeral overlays (much much faster) [07:38] mvo: if you use adt-build-lxc, the name is "adt-", not just [07:39] cool, thanks a bunch [07:40] mvo: gern :) [07:41] 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] seems you are using some kinds of repo_path = os.path.abspath("./data/test-repo") [07:43] in the python-apt tests [07:44] didrocks: *cough* yeah, the tests need to run in the tests dir, thats silly [07:45] didrocks: apt.Cache(rootdir=chroot.path) is really nice for that [07:45] 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] didrocks: the shell wrapper needs to set --force-not-root --force-bad-path --root=your-new-rootdir [07:46] didrocks: and then you can even install into this alternative rootdir [07:46] and the rootdir needs to contains a Packages.gz for an archive state? [07:46] 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] didrocks: or you can provide static data [07:47] didrocks: in var/lib/apt/lists/foo_Packages [07:48] 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] good morning desktopers [08:00] salut seb128 [08:00] didrocks, lut! [08:04] bonojur seb128 [08:05] pitti, salut! ça va ? [08:05] hey hey [08:05] hey Laney [08:05] how are you? [08:06] seb128: ça va bien ! j'ai couru tous les matins cette semaine, avant qu'il fait chaud :) [08:06] hey Laney, good morning [08:06] seb128: et toi ? [08:06] pitti, tu es comme Didier ;-) [08:06] je viens de me lever moi ! [08:07] seb128: je ne peux pas aller à Taekwondo aujourd'hui, à cause de USO [08:07] UOS [08:07] tu as une session qui t'intéresse ce soir ? [08:08] seb128: pas une, deux à meme temps.. [08:08] hey seb128 & pitti [08:08] langpacks for touch and systemd for servers [08:08] I'm doing good thanks! [08:08] seems it's not as warm here as it is for you guys ... [08:09] seb128: j'ai aussi couru pour info (à 6h50) [08:09] c'était difficile par contre ce matin… le corps n'était pas réveillé :) [08:10] Laney: well, it's "only" 31 today \o/ [08:10] nice... [08:10] is that "shut all of the blinds"? [08:11] I don't, I don't like darkness :) [08:11] already, shut all windows [08:11] stay on the north side [08:11] and suffer [08:11] work from the cold shower [08:12] I would really like a water proof laptop and work from a swimming pool [08:12] *that* would be life! [08:12] expenses time! [08:12] didrocks: my wife has a Toughbook for work, that might do :) [08:12] * didrocks files one [08:13] you can have your rain back if you want ! [08:13] pitti: ahah, yeah! I don't see the water proof part though :) [08:13] and that golfball sized hail [08:13] ogra_: waow, any damage? [08:13] nope, luckily not [08:14] we have a large glass brick wall (4x3m) ... it was like a concert having the hail hammer it [08:14] don't want to be outside in that... [08:15] astonishingly nothing broke, even the solar panel on the roof is still fine [08:17] seb128: pmcgowan: There's no dep problem with cross-building u-s-s for armhf that I can see [08:18] it doesn't build though, but for another reason [08:21] /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] this reason [08:21] say what [08:31] Laney, hum, abi change somewhere? [08:31] didrocks, 6h50, ça pique les yeux ! [08:32] seb128: non, c'est un bon temps, dans l'été :) [08:33] 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] lrwxrwxrwx 1 root root 27 Feb 26 14:21 /usr/bin/arm-linux-gnueabihf-g++ -> arm-linux-gnueabihf-g++-4.8 [08:36] I think the cross building defaults are done separately [08:37] seb128: ouai, c'est ce que je me suis dit :) [08:38] larsu, Laney: did you get anywhere with the GTK build? [08:38] seb128: working on it right now [08:38] trying to find commits to backport from master [08:46] Laney: I'm having trouble with the gcc 4.9 update, maybe that's related? [08:46] dpkg: error processing archive /var/cache/apt/archives/gcc-doc_4%3a4.9.0-3ubuntu1_amd64.deb (--unpack): [08:49] ah, install-info is missing the --dir-file parameter [08:50] hm? [08:50] install-info: No dir file specified; try --help for more information. [08:51] you get that when upgrading? [08:51] yes [08:51] ddddddooooooooookkkkkkoooooooooooooooooooooooooooooo [08:51] postinst has the install-info lines, but they're missing that param [08:51] haha [08:51] oh yeah, me too! [08:51] unrelated to your issue of course (now that I've had an actual look at it) [08:52] actually mine is different, that's weird [08:52] Error in `/usr/share/doc-base/gcc-4.9-itm', line 29: format `html' already defined. [08:52] for the same package? [08:52] gcc-doc [08:52] right [08:54] 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] dear oh dear [08:54] ah yes, if I fix that then I see your error [08:54] okay, building u-s-s without proposed works [08:54] I wonder why I don't get that one [08:54] * Laney suspects the new apt [08:55] mvo !!! [08:55] let me check this theory first :P [08:55] Laney, do you know if sbuild complaining about "grep: debian/control: No such file or directory" a standard gotcha or something [08:55] never seen that [08:56] how did you get it? [08:56] sbuild -d utopic --host armhd ubuntu-system-settings*.dsc [08:56] hf [08:56] (sorry typing from another box) [08:56] did you build the chroot right? [08:57] I think you can get No such file or directory if you try to execute wrong-architecture binaries [08:57] mk-sbuild utopic --target=armhf [08:58] I created it using "mk-sbuild --target=armhf --skip-proposed utopic" [09:01] * Laney tries [09:01] also yes, it does build with downgraded apt [09:09] Laney, is sbuild logging somewhere? [09:10] in fact it does "E: Core build dependencies not satisfied; skipping" [09:11] it makes a .build file in the current directory [09:12] I just made a new chroot and it seems to be working for me [09:17] yeah it built [09:17] that doesn't let me be very helpful, sorry [09:18] Laney, do you see what's wrong in http://paste.ubuntu.com/7627690/ ? [09:18] yes [09:18] Please generate a key with 'sbuild-update --keygen' [09:24] Laney, thanks, that seems to work [09:24] shrug, https://wiki.ubuntu.com/Touch/CrossCompile could mention it [09:24] 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] let's make it so [09:24] no [09:25] there we go [09:25] Laney, should I just add $ sbuild-update --keygen to the first section there? [09:25] I did it ;-) [09:26] thanks ;-) [09:27] * seb128 does the same to https://wiki.ubuntu.com/CrossBuilding [09:27] seb128: hm, what failed? Laney do you have the full output of the failed gcc-doc? [09:27] mvo, /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] mvo: don't worry about gcc-doc, that was a separate problem [09:28] mvo: just filed https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1328838 [09:29] Ubuntu bug 1328838 in apt (Ubuntu) "Can't x-build ubuntu-system-settings with 1.0.4ubuntu1: /usr/lib/arm-linux-gnueabihf/libapt-pkg.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20'" [Undecided,New] [09:35] seb128: eehhh [09:35] seb128: no idea right now, can check after lunch [09:35] mvo, thanks [09:35] could be a doko issue... [10:15] 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] 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] 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] pitti: the integration tests are pretty heavyweight currently as they build a full click buld chroot [10:17] ah [10:17] mvo: and you don't want to do that during pacakge build then, I suppose? [10:17] pitti: yeah [10:17] pitti: it will take forever on a slow arch [10:18] pitti: the unittests are run of course [10:18] mvo: right, so run them against the installed click in autopkgtest (but notice that we also run the autopkgtests on armhf) [10:19] pitti: ok, will do [10:20] pitti: thanks for your help :) [10:20] gern! [10:23] 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] https://bugs.launchpad.net/oem-priority/+bug/1294877 [10:23] Ubuntu bug 1294877 in OEM Priority Project "usb-creator fails to wipe usb device when the device has ext4 partition" [Undecided,Triaged] [10:23] 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] 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] seb128: will do, thanks [10:25] 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] so it's on the LTS .1 tofix list [10:29] seb128: hey, I can't find the new unity-settings-daemon in trusty. How's the SRU going? [10:29] tseliot, https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=unity-settings-daemon [10:30] tseliot, you might want to gently ask the SRU team about getting it reviewed from the queue ;-) [10:30] tseliot, having it accepted would let us free the silo as well, which would be welcome [10:30] seb128: oh, ok, I thought you'd deal with that too [10:30] well "deal with that" [10:30] I can ping them [10:31] I'm not in the SRU team myself, so I can't review/approve it [10:31] seb128: somehow I thought you were part of that team. If you could ping them for me, that would be very welcome [10:32] tjaalton: did you see my q about weston yesterday? [10:33] tseliot, k [10:33] seb128: thanks === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === alan_g is now known as alan_g|afk [10:43] tjaalton: ah sorry, just saw your /away === alan_g|afk is now known as alan_g [10:51] phew, finally got some start of the apt test env in the chroot I need :) [10:52] didrocks, did you fix your issue with the new python-apt version? [10:52] seb128: oh yeah, quite early in the morning even :) [10:52] nice === MacSlow is now known as MacSlow|lunch [11:46] 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] 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] (permission denied) [11:47] so maybe it never goes to execute dpkg? [11:47] didrocks: thats a red-herring [11:47] didrocks: with dir::bin::dpkg change it should fail, does it not do that? [11:48] mvo: yeah, same output and "True" [11:48] mvo: and it can't install it anyway, I'm not root in that ipython === alan_g is now known as alan_g|lunch [12:11] 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] (python-apt doesn't have test overriding dpkg binary) [12:12] didrocks: https://github.com/mvo5/apt/blob/debian/sid/test/integration/framework#L124 [12:12] didrocks: but if you point me to the code you have I can poke around too [12:13] mvo: yeah, that's some shell scripts, let me try to give you a minimal test you can play with, one sec [12:30] mvo: here is a simple gist: https://gist.github.com/didrocks/afc625607feab0432e4e [12:30] it can't install the package because: /usr/bin/dpkg2 doesn't exist (nor the deb) === alan_g|lunch is now known as alan_g === pitti_ is now known as pitti [12:49] 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] (LD_PRELOAD is used in the tests to mock certain libc/libclick symbols) [12:50] 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] didrocks: its just hard to debug, oh well [12:57] mvo: hm, i thought eatmydata is ldpreloaded when running tests, or maybe i am wrong. Let me check. [12:57] xnox: yeah, that used to be the case, not sure if it still is [12:58] saluton, amikoj! [13:02] seb128: porce #ubuntu-desktop sessao Espanol? [13:02] http://pad.ubuntu.com/uos-1406-unity8-desktop-preview-image [13:05] seb128: hm looks like somebody translated it. [13:05] funny :) [13:06] xnox, wth? [13:06] xnox, seems it was done in http://pad.ubuntu.com/ep/pad/view/uos-1406-unity8-desktop-preview-image/rev.309 [13:06] seb128: scrolling through history "unnamed participants" translated it all [13:07] or 308 even [13:07] yeah [13:07] yeah, 308, "unamed [13:07] " [13:07] at least, it's easy to revert (I was going to do that) [13:07] seb128: yeah, i've revert it now. [13:07] (well added english back in) [13:07] well, I copied the workitems to the blueprint [13:07] so I don't care much about the notes [13:08] haha [13:08] Laney: yeah go wild wild weston :) [13:08] not sure if we need to check other etherpads for portugeese. [13:08] tjaalton: thanks, already did it ;-) [13:08] seb128, time to expense a spanish class :) [13:08] Laney: cool [13:08] lol === l3on_ is now known as l3on [13:09] * xnox ponders if google translate did it! [13:10] seb128, so my deps problem resolved itself but I saw there were issues with ftbfs [13:10] seb128: lol, google translate did it [13:11] xnox, google! [13:11] pmcgowan, there is an issue with libapt today it seems [13:11] you can build it without utopic-proposed [13:12] * Laney has been doing just that for the MP that just went up === rickspencer3_ is now known as rickspencer3 [13:19] 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] hm? Because clang uses gcc's command line syntax? [13:54] more like because it defines __GNUC__ [13:54] oh. [13:54] morning dro|desrt :) [13:54] my atomic improvements broke clang :( === olli_ is now known as olli [13:57] is anyone using that in production? [13:57] oh, osx I guess [13:58] freebsd 10 as well [13:58] * dro|desrt got a bug filed this morning [13:58] (regular jhbuilding doing its job...) [14:03] 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] didrocks: hm, you can set apt_pkg.config.set("Debug::pkgProblemResolver", "1") to see why this is [14:04] didrocks: sounds like some dependency that can not be installed maybe? [14:04] mvo: oh, that would be possible [14:05] 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] which are all installable [14:08] didrocks: you made me clone it now [14:08] mvo: no no, concentrate on your adt tests, I didn't want to annoy you (yet ;)) [14:11] mvo: yeah, STOPPPP! it was because of the deps of my mock (abrowser) [14:11] mvo: weird that mark_install() doesn't say a thing and that commit() returns True [14:11] didrocks: *cough* api sucks [14:11] didrocks: it should probalby return false or raise if it can not be installed [14:13] didrocks: tests are postponed for now btw [14:13] didrocks: well, I made them work [14:13] mvo: right, I would have expected mark_install() to raise or return False [14:13] I understand that for "commit()" there is nothing to do then :) [14:14] 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] didrocks: silly dpkg [14:15] ;) [14:16] didrocks: hm, we currently always return None, so returning true/false shouldn't be too terrible API wise [14:20] 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] ah, interesting error this time: [14:22] dpkg: error processing archive /home/didrocks/work/ubuntu-developer-tools-center/tests/data/apt/testpackage2_0.0.1_all.deb (--install): [14:22] error setting ownership of `/tmp/root/usr.dpkg-new': Operation not permitted [14:23] didrocks: fakeroot [14:23] didrocks: does that help? [14:24] mvo: indeed [14:24] so --force-not-root isn't enough [14:26] 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() === alan_g is now known as alan_g|tea [14:34] seb128, Laney: pushed gtk 3.12 test fixes to lp:~larsu/gtk/3-12-test-fixes (sorry it took so long) [14:34] ah wait, that one patch doesn't apply [14:34] * larsu should wait until building the package before announcing stuff [14:36] larsu, waiting ;-) [14:38] hm, this change must be introduced by an earlier patch... [14:38] * larsu quilts === alan_g|tea is now known as alan_g === m_conley_away is now known as m_conley [14:41] * larsu slaps himself [14:42] larsu, what was it? [14:43] seb128: the one patch I added needs to be a revert, but wasnt [14:43] oh ok [14:43] speaking of which, it would be cool if there was a "revert diff" tool [14:43] (mentioning it in case somebody knows of one ;-) [14:43] patch -R? [14:43] interdiff diff /dev/null [14:44] larsu, patch -R works to apply a reversed patch, not to add it to a quilt serie [14:44] you need to apply then diff manually [14:44] Laney, thanks [14:44] * seb128 tries [14:45] right, I do it in a vcs checkout [14:45] and do a diff after [14:45] right [14:45] which I usually do [14:45] could also use git revert, which does the same thing [14:45] but it's a few steps [14:45] * seb128 notes the interdiff tip from Laney [14:50] and all of a sudden, bzr bd doesn't want to build anymore [14:50] dpkg-checkbuilddeps: Unmet build dependencies: dpkg-dev (>= 1.16.0) [14:50] this worked 5 minutes ago [14:51] * larsu pushes anyway for Laney and seb128 to have a look [14:51] larsu, did you uninstall anything? [14:51] dpkg -l | grep dpkg-dev [14:52] iU dpkg-dev [14:52] I didn't install or uninstall anything - and I can't right now because of the gcc-doc failure [14:52] k [14:52] well, it's Uinstalled [14:53] it was just failing before hitting the build-depends check before, because the patch was not applying [14:53] doesn't it usually print what patches it tries to apply? [14:53] anyhow, please have a look at the branch when you have time [14:54] it does, but at the build time [14:54] not when preparing the source iirc [14:54] it's prepare the source (which failed before because patch didn't apply) [14:54] check build-depends [14:54] build [14:54] okay [14:54] Laney, there? can you throw that to your sbuild? [14:55] any news on the gcc-doc thing? [14:55] https://launchpad.net/ubuntu/+source/gcc-defaults/1.128ubuntu2 [14:56] larsu, it's published, you might want to refresh/retry [14:56] just did, same issue [14:56] :-( [14:56] well it might be that you need manually hacking around [14:56] did you get the new one? [14:56] if it hits issues with the old version [14:57] like in the prerm of the installed one [14:57] Laney: trying to find out, but the version of gcc-doc seems different from the gcc-defaults one?! [14:57] larsu, can you pastebin the log of your error? [14:57] * larsu cleans the cache just in case [14:58] seb128: http://paste.ubuntu.com/7628968/ [14:59] ah, the old script crashes but it doesn't try the new one since there isn't one [15:00] this is an interesting case [15:00] larsu, try to sudo rm /lib/dpkg/info/gcc-doc.prerm [15:01] there's no lib/dpkg [15:01] shrug [15:01] larsu, /var/lib/dpkg/info [15:01] yep [15:01] seb128: thansk! [15:02] larsu, worked? [15:03] yes [15:03] \o/ [15:03] larsu, and now you know why people want system-image updates ;-) [15:03] Laney, can you test build lp:~larsu/gtk/3-12-test-fixes ? [15:03] ok [15:04] Laney, I don't have a clean utopic chroot [15:04] thanks [15:05]