[00:21] rbasak: Please could you merge libapache2-mod-perl2 (or I'll do it if you like, but you touched it last)? [00:21] Needed for Perl 5.22 [00:33] I wonder why do-release-upgrade never works, and then you apt-get -f upgrade and it fixes it (mostly), and then you have like... fontconfig not regenerating font cache because of missing symbols, and you do-release-upgrade again to get to the next distro and all is well. [00:33] pretty cool that it can fail catastrophically and you can say "well fix it" and it does, though. [05:52] Good morning [07:04] hey pitti [07:47] good morning === alkisg is now known as work_alkisg [10:08] Hi I was following this guide https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#librarysymbols [10:08] based on that I created http://paste.ubuntu.com/14086901/ for my use case [10:08] and the symbols file I got is this http://paste.ubuntu.com/14086902/ [10:08] now I wanted to ask for a confirmation about the following [10:09] is that a symbol that was in 2.0 and is still there? [10:09] cirbuf_add_buf_head@DPDK_2.0 2.2 [10:09] and this one, one that shows up in 2.2 but was not there in 2.0? [10:09] _rte_eth_dev_callback_process@DPDK_2.2 2.2 [10:12] cpaelzer: no, it looks like the _2.0 is part of the name [10:18] ginggs: you mean of the symbol name? [10:19] yeah that could be I remember they combine that in the split libraries - I just never realized how it shows up in the combined lib [10:19] cpaelzer: yes, those are versioned symbols [10:19] ginggs: great, now tihngs fall into place - thanks [10:20] that will do until I get further to split the libs anyway === work_alkisg is now known as alkisg === alkisg is now known as work_alkisg [10:45] I found an example that might have been better [10:45] cmdline_poll@DPDK_2.1 2.2 [10:45] that seems to be added with 2.1 and existing in 2.2 [10:46] anyway, builds fine now - thanks once more === tsdgeos_ is now known as tsdgeos [11:21] cpaelzer: yw, but looking at your new example 'cmdline_poll@DPDK_2.1 2.2' the _2.1 is part of the name and #MINVER# is 2.2 === cpaelzer is now known as cpaelzer_afk === work_alkisg is now known as alkisg [11:50] https://bugs.debian.org/808289 [11:50] Debian bug 808289 in src:upstart "proposed RM: upstart -- RoQA; unmaintained" [Normal,Open] === alkisg is now known as work_alkisg [11:56] xnox_2016: hi! Could you please run the tests on this again: lp:~mardy/libaccounts-glib/s390-tests === cpaelzer_afk is now known as cpaelzer [12:09] mardy: IIRC xnox_2016 has said he will be out til next year, is it just about rerunning that on s390 or something more complex? [12:09] cpaelzer: ah, I was wondering about the nick... [12:10] cpaelzer: yes, just run that branch in a s390 builder; is it something that you could do? [12:10] mardy: if it is easy to run I can help [12:10] mardy: well in a builder I cant [12:10] but in a "normal" s390 system if that helps? [12:10] cpaelzer: ah, that's probably even better :-) [12:10] so just autogetn / configure / make / ? [12:11] cpaelzer: yes, but it's better if you run "dpkg-buildpackage -rfakeroot -b -us -us" [12:11] cpaelzer: I know that the tests will fail, and I'd need to see the logs afterwards [12:11] ok, lets see - that system never built anything - a few package installs ahead ... [12:12] mardy: ok I'll let you know and you can identify if it fails at the right spot :-) [12:12] cpaelzer: apt-get build-dep libaccounts-glib should do the trick [12:12] cpaelzer: excellent, thanks a lot! [12:16] mardy: Why not ask for a suitably-configured PPA where you can upload tests for yourself? [12:17] Since you're a Canonical employee so can have devirtualised PPAs ... [12:17] cjwatson: I didn't out of ignorance, I guess :-) [12:17] cjwatson: is it documented somewhere? [12:18] mardy: I don't recall, sorry [12:19] mardy: But create a dedicated PPA for the purpose for yourself, then explain the requirement on https://answers.launchpad.net/launchpad/+addquestion [12:20] cjwatson: excellent, will do that right now then, thanks [12:24] cjwatson: done: https://answers.launchpad.net/launchpad/+question/279601 [12:25] mardy: until you have set up the ppa following the hints of cjwatson you can check if this is what you were looking for http://paste.ubuntu.com/14087452/ [12:26] cpaelzer: lovely, thanks! [12:26] mardy: if the locale issues annoy you I've fixed those now [12:27] cpaelzer: nah, it's fine [12:27] mardy: you're welcome - was worth getting my machine a few packages [12:28] cpaelzer: is there anything special about s390? I wonder why the tests run fine in all other archs, but fail on s390... Maybe something unique about endiannes, pointer size...? [12:28] big endian to start with [12:28] mardy: That PPA is done. [12:28] mardy: PIE is also enabled on s390x by default. [12:28] pointer size is 64bit in ss390x and 31 !31 not 32! in s390 [12:29] but I guess we only do s390x [12:29] But not on the other archs yet. [12:29] wgrant: excellent, thanks [12:30] mardy: in any case you can find the assorted list of "being special" in http://www-01.ibm.com/support/docview.wss?uid=isg2b9de5f05a9d57819852571c500428f9a [12:30] mardy: but not like a short summary :-) [12:31] cpaelzer: ok, I'll keep that handy for later, in case I get really stuck [12:31] wgrant: Ah, thanks for beating me to it. [12:32] mardy: https://wiki.debian.org/ArchitectureSpecificsMemo is really helpful for this kind of question. [12:32] mardy: Doesn't mention Ubuntu-specific things like PIE being enabled on s390x, but otherwise very useful. [12:32] cpaelzer: ^- more useful than single-arch docs for most people :) [12:32] barry: hey! did you get any chance to find out what the issue was on the nose/coverage/html issue? [12:33] cjwatson: I didn't know that, but I like the comparison that can be handy - worth a bookmark, thanks [12:34] And indeed, s390 (not s390x) is irrelevant in Ubuntu and was removed from Debian a while back too. [12:34] cjwatson: hmm am I supposed to fix missing info in there? [12:35] cjwatson: well have no user yet in that wiki [12:36] cpaelzer: Not "supposed to", though I'm sure corrections and clarifications would be welcome (anyone can create an account there AFAIK). Do keep it in roughly the current style though :) [12:36] cjwatson: just missing the huge page sizes, I'll request an account [12:37] Make sure that it actually matches configuration in Debian for that kind of thing. [12:37] cjwatson: I have a debian on s390 to check [12:38] s390x, perhaps? [12:38] cjwatson: wgrant: mardy: one thing that doesn't fit the table but is sometimes worth to know - a cache line is rather long with 256 byte [12:38] I meant s390x [12:38] I guess they can afford that with the hundreds of megabytes of L4... [12:39] cpaelzer: You could add a heading and a bit of free-form text further down the page about that if you wanted. [12:39] cpaelzer: Though does that often affect userspace porting? [12:40] cjwatson: not porting in terms of function but a lot of performance issues with cache line bouncing [12:40] cpaelzer: OK, that's not really the point of this page [12:41] cpaelzer: The point is to provide a reference for a package maintainer scratching their head about why their package works on one set of architectures but not another, and to let them quickly match that up with characteristics of the architectures that do/don't work [12:41] cjwatson: ok thanks, then I'll just add the huge page sizes [12:42] cpaelzer: I would think pretty carefully before turning it into a performance reference [12:42] (though there is a little bit of that relating to alignment) [12:42] cjwatson: I'll omit the cache line thing for now, it is just my old history being s390x performance engineer for a decade that sometimes comes back :-) [12:43] If you did add that, you'd want to explain how userspace ought to take account of it [12:44] cjwatson: that is the reason why I omit the cache line thing on this page, it would require too much space and by that not suit the page as it is [12:47] cpaelzer: hey, would you be able to run a command for me in the build directory? [12:48] mardy: sure [12:48] cpaelzer: in the "tests" directory: make check TEST_CASE=AccountService [12:49] mardy: http://paste.ubuntu.com/14087565/ ? [12:50] cpaelzer: ok, then I need to see the DB, let me find the right command to dump it... [12:51] cpaelzer: I guess just "sqlite3 /tmp/accounts.db" and then a ".dump" from the interactive console [12:52] cpaelzer: ah, but now I see that the tests passed... :-/ [12:52] mardy: http://paste.ubuntu.com/14087577/ here for you anyway [12:53] cpaelzer: yep, that's correct, as expected [12:53] cpaelzer: and make check TEST_CASE=Create ? [12:54] cpaelzer: just tell me if it passes or not [12:54] mardy: fails [12:54] cpaelzer: excellent, then can I see the logs please? [12:55] mardy: => http://paste.ubuntu.com/14087590/ ? [12:55] mardy: both tests have pass=1/Fail=1 [12:56] cpaelzer: weird that the full log is not attached; can you please paste me the tests/accounts-glib-test.sh.log file? [12:57] mardy: http://paste.ubuntu.com/14087600/ [12:57] ah you meant the .log [12:57] mardy: http://paste.ubuntu.com/14087602/ [12:58] cjwatson: with some help from IBM friends I was also able to calrify the float/double columns of that - now s390x looks as it should. Thanks for pointing me there [12:58] cool [12:59] cpaelzer: eh, it's mysterious, looks like the logs from the failing test are completely missing [13:00] mardy: I rerun the test and see that the file is updated [13:00] mardy: so it is not just some old content, it really writes just those few lines [13:01] cpaelzer: yes, I can see that's the correct file, but something is missing; looks like the output of the failed test is being discarded; might be a bug in the check testing tool [13:01] mardy: the log still ends with "task-0: 100%: Checks: 4, Failures: 0, Errors: 0" if I run the TEST_CASE=AccountService instead [13:02] cpaelzer: and what if you try: make check TEST_CASE=Create WRAPPER=time ? [13:02] mardy: /root/s390-tests/libtool: line 10051: exec: time: not found [13:02] let me install [13:03] cjwatson: doing it now. [13:03] rbasak: thanks! [13:05] mardy: the log now at least has some errors http://paste.ubuntu.com/14087637/ [13:05] better? [13:09] cpaelzer: thanks, that's extremely useful! [13:09] mardy: maye even better make check TEST_CASE=Create WRAPPER="ltrace -T -S -r " [13:10] mardy: => http://paste.ubuntu.com/14087659/ [13:10] mardy: just in case you really want to know whats going on below :-) [13:13] cpaelzer: thanks, never used that command, I usually do strace, but this seems even better [13:13] mardy: its combined and a few timing extras [13:13] mardy: and then there is no s390x strace packet yet in the repos [13:18] cpaelzer: it's a bit unfortunate that it doesn't show the first parameter of SYS_open(), just "" [13:18] cpaelzer: actually, it fails to get the string parameters of all the SYS_* functions [13:21] cpaelzer: anyway, the problem is that the test is setings the permissions of a file to read-only, then the library attempts to open the file with O_RDWR, and we'd expect that to fail... but from the logs (both the test logs and the ltrace) I can see that it succeeds to open it [13:21] cpaelzer: what filesystem are you using on /tmp ? [13:22] mardy: /tmp is no extra mount, btu actually on / and that is ext4 [14:06] cjwatson: uploaded. I couldn't run the dep8 tests local (some issue with lxc and xenial) so we'll have to see. [14:09] cjwatson: OOI, we have tons of idle arm64 builders on scalingstack; what's missing to use them as distro buildds? [14:09] rbasak: adt-virt-lxc works well here, what's up? [14:10] pitti: I can't get lxc-start-ephemeral to start a xenial container on vivid (I need to replace my dev VM with something newer) [14:10] So it's not adt-virt-lxc, it's just between me and lxc I think. [14:15] pitti, kernel and qemu updates at least, afaik [14:15] I haven't tried to reproduce in a fresh VM or anything yet; probably easier to just go to Wily or Xenial for a new test VM. [14:15] rbasak: ah yes, high time :) wily host and xenial guest kind of works, but I must pin lxc and lxcfs to wily-release (not -updatse) [14:16] doko: well, if anything the PPA builders should be *more* complicated and demanding as they need stronger virtualization? [14:16] * rbasak do-release-upgrades it [14:16] doko: but we have > 25 PPA builders which are just twiddling thumbs while the 5 distro builders can't keep up, hence I was curious [14:17] It's sort of throwaway (I do merges, builds and tests on it and nothing else really) but it's a pain to set up again because of the large numbers of chroots, lxc template containers, adt-qemu images and stuff I end up with on it. [14:19] rbasak: why would you throw these away? [14:19] * pitti introduces rbasak to the magic of keeping $HOME between installs :) [14:20] I keep /srv too, which is unencrypted and contains all my VMs, containers, and schroots [14:21] I like to know that I can reproduce things and not carry on state indefinitely and get myself stuck later. [14:21] I could script it all, I just haven't (recently). [14:22] So I don't like cruft building up in $HOME. I do carry it forward on my main personal machine, but I don't use that for dev builds and tests as I don't want to drag all of that unnecessarily into my full backups. [14:22] And I don't like maintaining long exclude lists for my full backups. I consider that dangerous. [14:23] Plus it saves me a ton of bandwidth and I get speed by having a machine closer to the archive. [14:23] (or maybe a mirror, I don't know) [14:23] Anyway, this time I'm just doing a do-release-upgrade because I can't be bothered to recreate. I'll probably do it next cycle though. [14:24] It feels good when everything is clean :-) [14:25] didrocks: not yet, but it's first on my list for this morning [14:25] barry: excellent! keep me posted :-) (and good luck for the hunt) [14:25] didrocks: will do! [14:30] rbasak: ah, I do my development in ~/ubuntu and ~/debian which aren't covered by backups, and I have scripts to reproduce all the virt environments [14:30] rbasak: and build stuff in schroots [14:33] If I exclude things from backups then my restores aren't really restores any more, they're "restore and then fix stuff up manually again" which I don't want to have to deal with after a disaster. [14:33] So my full backups are really full backups (I do exclude /proc, /sys and /tmp etc though), so I have more confidence in my DR plan and I will be able to restore and be productive again quickly. [14:34] OTOH my dev VM could explode, which would be annoying since that isn't backed up. But I can recreate it quickly enough to do whatever task I need to do - I won't need it all on the first day after DR. [14:34] I like to have that separation. [14:35] I also do have to make sure that anything on the dev VM I want to keep is mirrored locally. But rsync and git make that easy. [14:35] pitti: They fail to reset a very large percentage of the time, so are currently unusable in practice (they only stay up if idle, pretty much). [14:35] pitti: We have two upgrade tickets sitting with GSA to upgrade qemu and the kernel on the hosts, which we hope will help. [14:35] cjwatson: ah, too bad; thanks, I was curious [14:36] pitti: And yes, those are very high priority because as you say the current five can't keep up, but GSA has been too swamped to deal with these ... [14:42] hmm [14:42] is there a preempt-rt version of the lts-wily kernel for 14.04 anywhere? [14:45] pitti: fyi, upgrading to wily fixed the issue. I don't know if that's because of some side effect though. [14:46] rbasak: ah, then you are lucky; I have to pin the versions on the armhf production machines, but maybe that's an arch specific problem [14:47] rbasak: and if there's still trouble, I hear we have a xenial development series :) === work_alkisg is now known as alkisg [14:47] :) [14:47] Hey someone needs to dogfood the stable release. We'd never know when we need SRUs otherwise :-P [15:06] didrocks: looking now. this is lp:ubuntu-make right? on xenial? what do i need to do to set things up to run the nosetests3 command from your pastebin? (nosetests3 doesn't like the --cov=umake argument) [15:07] barry: lp:ubuntu-make or github :) [15:08] didrocks: ah. what's the url? [15:08] barry: if you install the build-deps, it should like --cov=umake :) [15:08] barry: https://github.com/ubuntu/ubuntu-make [15:08] (but lp:ubuntu-make is supposed to be a mirror) [15:09] barry: so, from this, install the build-deps and run the nosetests3 command I pastebined yesterday [15:09] didrocks: everyday i forget more and more bzr :) [15:09] heh ;) [15:10] barry: basically I have a wrapper "runtests" which is setting the right options, I just copied nosetests3 so that it's easier for you to reproduce this [15:10] barry: oh, and yeah: xenial [15:10] didrocks: [15:10] Ran 1 test in 4.583s [15:10] [15:10] OK [15:10] [15:10] let me try runtests [15:11] (after tweaking the path since i obviously don't have /home/didrocks... :) [15:11] i used a relative path tests/__init__.py - wonder if that makes a difference [15:12] barry: you did use all the options I pasted? [15:12] didrocks: yep [15:12] weird [15:12] (after build-deps) [15:12] so: [15:12] try: [15:12] ./runtests --publish --coverage pep8 [15:13] * barry tries [15:14] didrocks: ran to completion, no problem [15:14] barry: hum, I wonder if a new dep isn't needed then :/ [15:14] barry: I'm having Coverage.py warning: No data was collected. [15:14] pitti: unfortunately the dep8 test still fails because it can't upgrade systemd inside adt-virt-lxc which appears to be a test dep somehow. It times out. I won't worry about it though. I presume that'll get sorted soon. [15:15] barry: same in a clean ubuntu-desktop, with just the build-deps installed [15:15] xenial, right? [15:15] didrocks: could you have some stale data? try cleaning out everything from your git repo and try again? [15:15] (the postinst times out, not adt-virt-lxc) [15:15] barry: good idea [15:15] rbasak: yes, that's what I meant [15:15] didrocks: yep, xenial, though i haven't dist-upgraded this morning yet :) [15:15] Ah, OK [15:15] barry: well, should have failed form yesterda [15:15] barry: let me try a clean repo [15:15] rbasak: that's some lxcfs issue, and downgrading lxcfs and lxc to the release versions WFM [15:15] didrocks: cool [15:15] pitti: so pinning the versions fixes that? [15:15] Right, got it. Thanks. [15:16] rbasak: on the armhf production machines at least; this doesn't happen with the xenial versions [15:16] barry: you're right, WTH? [15:16] clean repo works [15:16] rbasak: so maybe these two are missing an accompanying cgmanager or whatever, I didn't have time to investigte this deeply yet [15:16] barry: so, staled .coverage corrupted data? === cpaelzer is now known as cpaelzer_afk [15:16] didrocks: probably just some stale/broken data. [15:16] didrocks: yep [15:17] barry: well, "happy" at least that's not super bad :) [15:17] that's why this is my favorite git alias: distclean = "clean -dxfi" :) [15:17] ahah :) [15:17] thanks for giving this hint barry! [15:17] didrocks: sure thing! glad it's working [15:18] ;) [15:18] me too [15:22] * didrocks can't see anything and feel tired :) [15:23] feels* [15:23] so, time for week-end, couldn't take any break today [15:23] have a good holidays for those leaving tonight, and happy new years! [15:23] for the others, see you on Monday |m| [15:30] cjwatson, cpaelzer_afk: just for the record, this seems to fix the libaccounts-glib tests for s390x -- so indeed, an endianness issue: https://gitlab.com/accounts-sso/libaccounts-glib/commit/a6c28fea9fa791a85b1809f00cc43d16b87f2b77 [15:33] pitti: and adt-run passed. Thanks! \o/ [15:33] pitti: is there a bug on lxc needing a downgrade? If not I can create one. [15:34] rbasak: I haven't filed one yet, I don't have much more information than just "it breaks"; but if it's happening on your system too, it's not just a quirk of my armhf machines [15:34] pitti: I'll file one then, thanks. [15:34] rbasak: they are running an ancient kernel, but it seems your case is much easier to reproduce [15:34] rbasak: cheers [15:57] pitti: I can't reproduce it any more :-( [15:57] Oh no, I can. I just can't reduce it. [16:00] pitti: filed bug 1527666 [16:00] bug 1527666 in lxc (Ubuntu) "lxc on Wily cannot dist-upgrade Xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1527666 [16:01] rbasak: try with looping systemctl daemon-reload [16:01] that will give the cgroups some exercise [16:01] rbasak: it quite obviously locks up doing some cgroup operations, and these are being channeled through cgmanager/lxcfs [16:02] rbasak: not sure about the details, but that might give you some hint if you try to reduce it [16:02] That doesn't seem to work. [16:02] I'll leave it for now. It is reproducible currently just by running adt-run at least. [16:02] For now, anyway. [16:04] barry: hi, did you notice the ubuntu i386 images have been failing to build with an error from axi? [16:05] Laney: yep, cyphermox pointed me at the build failure. it's a 32bit thing, but i hope to have time today to investigate [16:05] mardy: Indeed, very plausible. [16:05] cool [16:05] rbasak: curious that lxcfs 0.10-0ubuntu2.1 works for you -- that's what I had to downgrade [16:05] oi [16:05] rbasak: anyway, followed up, thanks for filing [16:07] and with that, TTFN -- happy EOL holidays everyone! [16:08] end of line holidays? [16:08] "EOY" [16:08] happy holidays pitti ;) [16:08] all the more proof that I need them :) [16:17] EOL?! [16:17] No thanks. [16:17] EOY maybe :) [16:17] Oh, he said that. === cpaelzer_afk is now known as cpaelzer [17:43] infinity: I'd like to talk to you about Docker. Are you around and free today? I'm gone for Christmas after today so otherwise maybe in January? === cpaelzer is now known as cpaelzer_afk [17:50] rbasak: I'm technically already gone (until January as well). [17:50] quick question, i need to update to boost version 1.39, how may i do that, [17:51] infinity: that's fine. Can I stick something in the calendar in Jaunary? When would be good for you? [17:51] nvrmnd [17:51] im just wasting my time [17:51] * rbasak is never sure what timezone infinity is in [17:51] rbasak: Well, in theory, I'm in MST7MDT. Pick something that's not so early in the morning that I'll want to punch you. [17:52] OK, thanks [17:54] infinity: 1700 UTC == 1000 for you? We can bump it back further if I'm tied up that evening, but I've put it there for now. I hope I'm not about to get a punch! [17:54] oh its not too early in the morning infinity [17:54] rbasak: Nah, 10ish works. [17:56] OK, thanks! [17:56] so how do I interpret update_excuses if it says for a package "Depends: [itself] perl (not considered)"? (where [itself] indicates it depends on itself) [17:58] teward: You're reading it wrong. It's saying that [itself] depends on perl. [17:58] ah OK [17:58] that confused me a little :) [17:58] teward: Makes more sense when you see a source package that produces different binary packages, that's telling you that [binary] depends on [other source]. [17:58] ok [17:59] Oh, actually. No. It is the source package. I lied. [17:59] But still. That's what it means. :P [17:59] :P [17:59] teward: Look at, eg: haskell-cracknum, which shows three deps. [17:59] teward: Makes a bit more sense in that context. [18:00] indeed. [18:00] more concerned about nginx - the perl upload went in, so i'm curious how migration from proposed is impacted by that (nginx 1.9.6-2ubuntu2 was uploaded for a rebuild against the updated perl) [18:01] teward: It'll all go in once the perl transition is done, not much to worry about. [18:01] ok [18:01] teward: http://people.canonical.com/~ubuntu-archive/transitions/html/perl5.22.html [18:01] teward: There's a bit to go still. [18:01] ahh i knew there was a transition tracker somewhere [18:01] * teward needs to bookmark things better [18:02] cjwatson: Speaking of the perl transition, you never did hand that off, like you said you would. Does that mean you're still chipping away at it? [18:04] i assume then before uploading any more nginx versions I should wait for the transition? [18:04] for the transition to complete* [18:04] (being 4 revisions behind is *bad*, i think...) [18:04] teward: You can do more uploads if you want, they'll just be stuck in proposed until the transition is done. [18:04] (and Debian is being slow to update) [18:04] ok [18:06] infinity: I just uploaded another batch of rebuilds, up to libyaml-syck-perl in level 3. Give the tracker an hour or two to catch up and then it's all yours. [18:06] There are bits and pieces from earlier that I haven't touched. [18:06] ok... in a post bzr distributed development world, where 'bzr branch lp:ubuntu/update-notifier' is "ERROR: Not a branch:" [18:06] cjwatson: Sure, I'll wait for arm64 to go idle and see what the state is. [18:06] how should i blame source in a package ? [18:06] cjwatson: Has there been any porting required, or have rebuilds done the trick consistently? [18:07] i want to know why something is the way it is, what is the recommended way of doing that. [18:07] smoser: Read the changelog? [18:07] infinity: Rebuilds and merges have handled most things so far, but I haven't had time to look into anything much non-trivial. [18:07] infinity: It's supposed to have been pretty well-prepared in Debian, though. [18:07] infinity, i'd like somethign that isn't almost guaranteed to be wrong. [18:08] smoser: don't work on software? [18:08] infinity: perlqt isn't in Debian and looks like it needs some fixing. [18:08] http://www.mongodb-is-web-scale.com/ [18:10] is there a plan for something equivalent ? [18:11] * debian/99update-notifier: [18:11] - Now additionally triggers the an asynchronous background update of the [18:11] cached info via update-motd-updates-available hooking into [18:11] APT::Update::Post-Invoke-Success. [18:11] :-( [18:11] smoser: Hopefully earlyish next year I'll have time to finish off my plan to import history from LP using dgit, yes. [18:11] bah. wrong paste location. :-( [18:12] cjwatson, i'm very interested. as my bad paste shows, the thing i was chasing is actually in a changelog, but... i'd rather not depend on it. [18:12] smoser: But, but. Does /dev/null support sharding? [18:13] infinity: i assume that any new upload will automatically get included in the transition tracker/tracking? [18:13] smoser: Yeah, lots of people want it :) [18:13] teward: yes [18:13] cjwatson: OK, thanks [18:13] "As of this moment I officially resign from my job as software engineer and will take up work on the farm shovelling...." [18:22] that sounds like a power play in Agricola [18:24] Hey guys! We wanted to re-build oxide-qt in the archive, sadly it seems the armhf build seems to be segfaulting in the middle [18:24] https://launchpad.net/ubuntu/+source/oxide-qt/1.11.3-0ubuntu2/+build/8458995 [18:24] /usr/lib/gcc/arm-linux-gnueabihf/5/include/arm_neon.h:6831:10: internal compiler error: Segmentation fault [18:24] On the armhf builders - we didn't have that before and this version already built in the past, we're just doing a no-change rebuild [18:24] We retried once but got the same [18:24] Any ideas? [18:30] hey. so https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1527710 [18:30] Launchpad bug 1527710 in update-notifier (Ubuntu) "apt-get update triggers asynchronous task" [Undecided,New] [18:30] sil2100: sounds like you need someone like doko, who knows of the voodoo in there. [18:31] sil2100: did you file a bug? [18:31] I fail, nevermind :) [18:31] i find apt config odd. is there a way that i can 'apt-get .... --option=Post-Invoke-Success' that disabled everything ? [18:42] cjwatson: still on the perl transition? I'd start to finish level 3 after libyaml-syck-perl. === cpaelzer_afk is now known as cpaelzer [19:16] cyphermox: I've stopped for the moment [19:17] cjwatson: well, I'm very slow anyway on account of http://www.xkcd.com/# being totally descriptive of my day. [20:13] cyphermox: ping, that apt-xapian-index bug [20:13] ah? [20:14] okay, so here's the problem. astrometry-data-2mass-00's installed size is 14215209984, and [20:14] >>> log2(14215209984) [20:14] 33.72671635922483 [20:14] [20:14] weee [20:14] axi has a size plugin that stores the installed and package sizes as documents [20:14] so yeah, that won't work [20:15] ultimately, i think it's a bug in xapian1.3-bindings but that's swig so [20:16] so, time to think some more of ripping our software-center? [20:16] cyphermox: we could do one of two things: catch the exception and treat it like -1 (i.e. ignore the size in the plug), or squash the size to sys.maxsize [20:16] hrm [20:16] cyphermox: yep. that *is* happening in 16.04 but robert_ancell is still working on that [20:16] yeah [20:16] well, you know more about a-x-i than I do, what do you feel is the best solution? [20:17] i will report the bug upstream to xapian either way and if they come up with a patch, i'll import that into xapian1.3-bindings [20:17] I think I'd rather break the size obviously rather than squashing it and reporting something that looks possible. [20:17] i'm not actually sure where the installed size is displayed, but the code clearly expects to ignore bogus values. it currently ignores inst_size == -1 [20:17] doko: hey! Any idea why this segfault is happening by any chance? https://launchpad.net/ubuntu/+source/oxide-qt/1.11.3-0ubuntu2/+build/8458995 [20:17] so, it's either dunno or lie :) === cpaelzer is now known as cpaelzer_afk [20:17] i'm inclined to make it == -1 [20:17] yeah [20:18] i.e. not lie, but dunno [20:18] yes [20:18] doko: all other builds went fine, and the oxide source did not change since last version (a no-change rebuild) [20:18] it probably won't affect too many packages. i bet not many are as big as astrometry, but i haven't looked at all [20:18] cyphermox: ok, so agreed, treat it as -1? [20:19] barry: I think that's arguably better than lying about the size. [20:19] cyphermox: agreed. i think i can whip up and test a fix for this quickly [20:19] thx [20:47] cjwatson: ok, I'm back... let me fill in a bug regarding the build segfault - I know this sounds silly, but could it be caused by the perl transition? As I see perl-modules marked for removal at the start of the build [20:51] cjwatson: although the most probable case is gcc 5.3.1... [20:53] sil2100: sorry, I can't look now. it seems unlikely; even if it is, you'll have to deal with it anyway ... [20:53] sil2100: a toolchain change is much more probable [20:53] Yeah [20:54] s/case/reason [20:59] doko: hey! If you could take a look at LP: #1527741 in the nearest time, maybe you would know more about what's causing this failure [20:59] Launchpad bug 1527741 in oxide-qt (Ubuntu) "oxide-qt 1.11.3-0ubuntu2 FTBFS on armhf due to compiler segfault" [Critical,New] https://launchpad.net/bugs/1527741 [21:14]