| pitti | Good morning | 05:29 |
|---|---|---|
| pitti | wgrant: hm, did anything go wrong with a recent LP rollout or so? a bug list like https://bugs.launchpad.net/ubuntu/+source/autopkgtest is now missing the "sort by" UI, and on bugs the tasks don't have expanders any more | 07:25 |
| wgrant | pitti: Hm, maybe one of the apache upgrades went awry. | 07:27 |
| pitti | it's also really slow this morning | 07:29 |
| seb128 | pitti, the "order by" headers are displayed here | 07:31 |
| pitti | hm, not here, I tried various pacakges | 07:31 |
| wgrant | seb128: JS is cached very heavily. | 07:31 |
| Unit193 | Does that if JS isn't on. | 07:31 |
| wgrant | It's just because pitti's been lazy lately and clearly hasn't looked at any bug pages :P | 07:32 |
| pitti | wgrant: heh yes, it's called "holidays" :) | 07:32 |
| dholbach | good morning | 07:37 |
| pitti | wgrant: I've looked at dozens of bug pages today, what can I do to flush/update the cache? | 07:39 |
| wgrant | pitti: Oh, sorry. To clarify, JS serving was broken by an apache upgraded an hour ago, but it only affects people who haven't used LP yet this week. | 07:40 |
| wgrant | We're debugging. | 07:40 |
| pitti | wgrant: ah, that clarifies it; thanks :) | 07:42 |
| wgrant | pitti: Should be fixed now. An arguably slightly overzealous mod-wsgi CVE fix. | 08:01 |
| pitti | wgrant: yay, thanks | 08:09 |
| pitti | seb128, tyhicks: (post-holiday catch-up): what's the latest word on bug 1430557? AFAIR you two looked into this two weeks ago? | 08:16 |
| ubottu | bug 1430557 in schroot (Ubuntu) "sbuild / schroot unmounted encrypted home directory" [High,Triaged] https://launchpad.net/bugs/1430557 | 08:16 |
| seb128 | pitti, see comments #6 to #9 on https://bugs.launchpad.net/ubuntu/+source/click/+bug/1427264 | 08:18 |
| ubottu | Launchpad bug 1427264 in click (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,Triaged] | 08:18 |
| seb128 | pitti, basically with systemd mounts use MS_SHARED and it's suggested to rprivate or rslave | 08:18 |
| seb128 | not sure what's the status of getting that change actually uploaded though | 08:20 |
| Unit193 | pitti: You were gone, hope you had fun. I was going to comment, netbook had a fun version of the systemd daemon-reload bug, plymouth would start back up, while in an active session. :P | 09:07 |
| pitti | Unit193: yep, I know; I sometimes get that in a VM | 09:07 |
| dz0ny | hehe | 09:07 |
| dz0ny | happened few times when gnome-session crashed | 09:08 |
| Unit193 | It's...Interesting. Simple plymouth quit works at least, so mildly amusing. | 09:08 |
| * dz0ny disables plymouth right after purging that chat and music app, tracker and online accounts thingy | 09:10 | |
| darkxst | dz0ny, would like to see a backtrace of that gnome-session crash if you can get one | 09:11 |
| darkxst | hey Unit193, pitti | 09:12 |
| Unit193 | darkxst: Howdy. | 09:12 |
| dz0ny | darkxst: can't be done, something about core dum not having right number of bytes | 09:12 |
| dz0ny | and tty was disabled after that | 09:13 |
| darkxst | Unit193, I started refactoring ppa-versions to use regex and what not, hold of playing with it for a few days | 09:13 |
| dz0ny | i had to reinstall everything | 09:13 |
| dz0ny | but if it happens again you will get it :) | 09:13 |
| darkxst | dz0ny, I see that sometimes on our retracers (invalid core dumps) | 09:14 |
| Unit193 | darkxst: Nice, hopefully not too much effort to merge. :P | 09:14 |
| darkxst | dz0ny, is it the login session or greeter session that is crashing? | 09:15 |
| dz0ny | login-session | 09:15 |
| darkxst | dz0ny, replace gnome-session with a wrapper, and then use ssh to attach to the gdb session | 09:16 |
| dz0ny | mhm | 09:16 |
| dz0ny | darkxst: the important thing is, that it didn't happened since re-install | 09:17 |
| darkxst | ok | 09:18 |
| seb128 | didrocks, pitti, do you have standard templates/wiki instructions for bugs like https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1436691 ? | 09:47 |
| ubottu | Launchpad bug 1436691 in upstart (Ubuntu) "Essential files are missing" [Undecided,New] | 09:47 |
| pitti | seb128: that one seems pretty clear, it seems the upgrade missed the installation of upstart-sysv? | 09:48 |
| seb128 | pitti, do we know how is that possible? | 09:48 |
| pitti | an apt log would certainly be helpful | 09:49 |
| === davidcalle_ is now known as davidcalle | ||
| didrocks | I guess the upgrade should have installed systemd-sysv instead (as we ensure to at least have one init) | 09:53 |
| didrocks | seb128: can you get the logs for that one? (as you pinged us about it, you know the guy or just looking at random upstart bugs?) | 09:53 |
| seb128 | didrocks, I'm just looking at the most recent reported bugs on launchpad, just to see the feedback from beta | 09:54 |
| seb128 | going through the first 10 pages or so | 09:54 |
| didrocks | ah ok :) | 09:54 |
| === greyback_ is now known as greyback | ||
| === dholbach_ is now known as dholbach | ||
| === stokachu_ is now known as stokachu | ||
| === Noskcaj_ is now known as Noskcaj | ||
| === freeflying__ is now known as freeflying | ||
| === beisner- is now known as beisner | ||
| === henrix_ is now known as henrix | ||
| === Logan_ is now known as Logan | ||
| === neunon_ is now known as neunon | ||
| === dholbach_ is now known as dholbach | ||
| === _salem is now known as salem_ | ||
| Odd_Bloke | Is there a common way of checking if a service is running which will work under upstart and systemd? | 11:51 |
| Odd_Bloke | invoke-rc.d looks like it has a different output format and different return codes. | 11:52 |
| === MacSlow is now known as MacSlow|lunch | ||
| === masACC is now known as maswan | ||
| flexiondotorg | cjwatson I've been stuck on the motorway for 3 hours. Using phone for IRC. | 12:00 |
| flexiondotorg | Caja is in the upload queue. | 12:01 |
| flexiondotorg | Fixss | 12:01 |
| flexiondotorg | Fixes a segfault. Can you find someone who can let it into the vivid archive please? | 12:01 |
| cjwatson | Ask on #ubuntu-release | 12:01 |
| cjwatson | That's a release team thing, I'm not in that any more | 12:02 |
| flexiondotorg | I'm going to be stuck here till 4pm | 12:02 |
| flexiondotorg | OK. Will fiddle with IRC toget to release | 12:02 |
| cjwatson | Sorry but I can't proxy for you on this | 12:02 |
| cjwatson | Fighting with juju | 12:02 |
| === buxy_bak is now known as buxy | ||
| ogra_ | infinity, oh, is the glibc in proposed supposed to be the only fix i need to make media playback work on the phone again, do you know ? | 12:11 |
| ogra_ | (or are there pulse changes/rebuild required) | 12:11 |
| * ogra_ would happily test but i dont want to trash my install | 12:11 | |
| ogra_ | bah, being brave and just instlling the packages wasnt such a good idea it seems ... | 12:20 |
| pitti | Odd_Bloke: "service foo status" isn't too bad, unfortunately under upstart it returns a wrong exit code (always 0), so you need to parse its output too | 12:21 |
| === BenC- is now known as BenC | ||
| cjwatson | pitti: Welcome back! Do you need anything from us in order to be able to prepare ddeb-retriever for new ddebs? | 12:32 |
| === MacSlow|lunch is now known as MacSlow | ||
| pitti | cjwatson: mostly just time, I'm afraid; so if anyone wants to take a stab at this, it might get done faster | 12:33 |
| cjwatson | I did have a look but was having difficulty getting my head around d-r's model of what it caches where | 12:33 |
| pitti | between the post-holiday backlog, easter holidays, and me getting dragged into the snappy sprint there won't be that much time left in the next few weeks | 12:34 |
| cjwatson | Do you have a local test setup or anything? | 12:34 |
| pitti | cjwatson: no, I don't; there's a test suite which mocks some stuff, but not a full "run against fake launchpad" integration test | 12:34 |
| cjwatson | Well, I guess I mean more a local staging site than tests as such | 12:34 |
| cjwatson | Something to play around with | 12:34 |
| cjwatson | I suppose I could just stub out the actual downloads | 12:35 |
| pitti | cjwatson: no, so far I just ran it against production, usually against a temp data dir | 12:35 |
| pitti | and just download the stuff from today, etc. | 12:35 |
| cjwatson | Oh, you can do that? That would help I guess | 12:35 |
| cjwatson | And I do have germanium access | 12:35 |
| pitti | cjwatson: yes, that's --archive-root | 12:35 |
| pitti | ~/www → ubuntu, ~/www/ubuntu-rtm → RTM | 12:36 |
| cyphermox | hey pitti! | 12:47 |
| pitti | hey cyphermox, how are you? | 12:47 |
| LocutusOfBorg1 | Hi Folks, what does this mean? https://jenkins.qa.ubuntu.com/job/vivid-adt-libvncserver/16/console | 12:48 |
| cyphermox | pitti: pretty good, you? | 12:48 |
| LocutusOfBorg1 | I see a failed but I don't understand what | 12:48 |
| cyphermox | LocutusOfBorg1: means there was a failure in jenkins | 12:48 |
| LocutusOfBorg1 | yes, but I see SUCCESS and after "FAILED" | 12:49 |
| === Pici` is now known as Pici | ||
| LocutusOfBorg1 | I understand what is jenkins, but I don't understand the failure | 12:49 |
| cyphermox | yeah, it couldn't pass on the right state from the executors to the upstream job | 12:50 |
| cyphermox | we can rerun this I guess | 12:50 |
| LocutusOfBorg1 | (ok so I understood correctly the output) | 12:50 |
| LocutusOfBorg1 | spurious failure | 12:51 |
| LocutusOfBorg1 | I don't know however why I did receive the mail, but nevermind | 12:51 |
| LocutusOfBorg1 | pitti, ^^^^ | 12:52 |
| LocutusOfBorg1 | :) | 12:52 |
| pitti | cyphermox: quite well, I really enjoyed the holidays | 12:56 |
| pitti | LocutusOfBorg1: another jenkins b0rkage, I'm afraid | 12:56 |
| pitti | I'll retry the failed tests | 12:56 |
| cjwatson | pitti: Hm, OK. I doubt I'll get to it today, but perhaps soon, then. | 12:57 |
| LocutusOfBorg1 | thanks as usual! | 12:58 |
| === doko_ is now known as doko | ||
| === mako_ is now known as mako | ||
| infinity | ogra_: Should be, yes. | 13:41 |
| ogra_ | well ... | 13:42 |
| ogra_ | http://paste.ubuntu.com/10683761/ | 13:42 |
| ogra_ | :( | 13:42 |
| ogra_ | i only installed libc-bin, libc6 and multiarch-support ... | 13:42 |
| ogra_ | rsalveti, is just trying to repro | 13:43 |
| tyhicks | pitti: I need to find some time to look at my proposed solution in LP: #1427264 closer - I was told that it doesn't work for trusty schroots | 13:49 |
| ubottu | Launchpad bug 1427264 in click (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,Triaged] https://launchpad.net/bugs/1427264 | 13:49 |
| Riddell | mvo: | 13:58 |
| Riddell | mvo: any thoughts on bug 1426132 ? the upgrade from utopic wants to install baloo4 rather than baloo-kf5 | 14:00 |
| ubottu | bug 1426132 in baloo-kf5 (Ubuntu) "baloo is not replaced by baloo-kf5 on dist upgrade" [Critical,Triaged] https://launchpad.net/bugs/1426132 | 14:00 |
| Riddell | which breaks kubuntu-desktop from installing | 14:00 |
| rsalveti | ogra_: yeah, fails to boot here as well =\ | 14:02 |
| rsalveti | latest mako image + new glibc | 14:02 |
| rsalveti | makes no sense though | 14:03 |
| rsalveti | the boottest for it went fine | 14:03 |
| rsalveti | https://jenkins.qa.ubuntu.com/job/vivid-boottest-glibc/lastBuild/ | 14:03 |
| mvo | Riddell: meh, that looks bad. if you (or someone else) can reproduce it, I wonder if it also happens with vivid apt? | 14:05 |
| mvo | Riddell: i.e. if apt is upgraded first (and only apt and its direct dependencies) before doing the upgrade | 14:06 |
| infinity | rsalveti: Makes shockingly little sense, given the single-line patch whose outcome could only be either "be broken the same as before" or "be fixed". But maybe the build corrupted? | 14:07 |
| rsalveti | infinity: yeah, the patch would not cause this for sure | 14:08 |
| rsalveti | still checking what failed to start | 14:08 |
| Riddell | mvo: I can reproduce it, I'm on a system now which has just failed with the problem | 14:09 |
| mvo | Riddell: do you happen t have a snapshot of the state before? | 14:10 |
| mvo | Riddell: that is the most interessting part :) | 14:10 |
| mvo | Riddell: anything special that needs to be done to get into this state? or is it just "upgrade kubuntu 14.10 to 15.04" ? | 14:10 |
| Riddell | mvo: no but it's just a fresh kubuntu utopic install no changes | 14:11 |
| infinity | mvo: I think the bug report has the hint, in that it's removing two packages to install one. apt doesn't generally like that. | 14:11 |
| Riddell | I added a "baloo" transitional package last night but it doesn't seem to have helped | 14:11 |
| rsalveti | infinity: ogra_: unity-system-compositor: error while loading shared libraries: libGLESv2.so.2: cannot open shared object file: No such file or directory | 14:13 |
| infinity | Riddell: The transitional package will just make it worse, since you got all the versions wrong. | 14:13 |
| rsalveti | so it seems to be an issue with ld | 14:13 |
| rsalveti | infinity: ogra_: ldconfig fixes it | 14:15 |
| Riddell | infinity: what makes you say I got the versions wrong? | 14:15 |
| infinity | Riddell: Package: baloo-kf5 | 14:15 |
| rsalveti | still unclear why this didn't automatically happen though | 14:15 |
| infinity | Replaces: baloo (<< 5.0) | 14:15 |
| infinity | Riddell: But baloo has an epoch. | 14:15 |
| infinity | rsalveti: The postinst should be running ldconfig... | 14:15 |
| * infinity tests this on x86. | 14:16 | |
| ogra_ | rsalveti, wow, i would have expected the libc postinst to call that | 14:17 |
| infinity | It triggers it. | 14:18 |
| infinity | And it worked fine here. | 14:18 |
| infinity | Just now. | 14:18 |
| * infinity tries on armhf to be sure. | 14:19 | |
| ogra_ | rsalveti, yeah, confirmed, i got my session back | 14:19 |
| ogra_ | i assume we wouldnt have seen that in an actual image build since *something* would have called ldcondifg at some point | 14:20 |
| infinity | Yes, libc-bin and libc6 both. | 14:21 |
| infinity | And any number of other packages. | 14:21 |
| ogra_ | yay, and i can listen to streaming radio and switch channels again :) | 14:22 |
| ogra_ | so the root cause is definitely fixed | 14:22 |
| infinity | How were you installing the packages on your phone? | 14:22 |
| infinity | Cause, seriously, literally the last thing the postinst for libc6 does is call ldconfig on configure. | 14:23 |
| infinity | And just confirmed it works fine on armhf too. | 14:23 |
| ogra_ | wget them to a dir in ~/ ... remount / rw ... dpkg -i *.deb ... remount / ro ... reboot | 14:23 |
| infinity | So, it's very specific to your environment. | 14:23 |
| ogra_ | could be | 14:23 |
| seb128 | rsalveti had the same issue though? | 14:24 |
| ogra_ | yeah | 14:24 |
| infinity | seb128: I meant "his environment" as in the phone, not *his* phone. | 14:24 |
| seb128 | oh, ok :-) | 14:24 |
| ogra_ | right, rsalveti has the same environment | 14:24 |
| geser | pitti: Hi, do you know by chance if the systemd (packaging) helpers cope well with a backslash in a unit name? (run-vmblock\x2dfuse.mount) | 14:25 |
| infinity | ogra_: Processing triggers for libc-bin (2.21-0ubuntu4) ... | 14:26 |
| infinity | ogra_: That's code for "running ldconfig now". :P | 14:26 |
| infinity | ogra_: And certainly produces sane ldconfiggish results for me here. | 14:26 |
| ogra_ | yeah, i know | 14:26 |
| ogra_ | running it manually got me fixed | 14:26 |
| ogra_ | seems for some reason the postinst didnt run though | 14:27 |
| infinity | ogra_: That's a bit strange. | 14:27 |
| ogra_ | right, since davmor2 obviously saw the issues when he tested the initial upload ... so it must have been run for him back then | 14:27 |
| infinity | ogra_: Yeah, and working for reboot tests, which effectively just do dpkg -i && reboot, right? | 14:28 |
| ogra_ | no idea what they do :) | 14:29 |
| ogra_ | they might make the system completely writable and reboot with writable rootfs first ... while i only remounted rw temporary | 14:29 |
| ogra_ | not sure how rsalveti did his install | 14:29 |
| davmor2 | ogra_: I just enabled the repo and did sudo apt install libc-bin libc6 multiarch-support | 14:29 |
| ogra_ | davmor2, right, so on a fully writable system | 14:30 |
| davmor2 | ogra_: yeap | 14:30 |
| davmor2 | ogra_: did phablet-config writable-image | 14:30 |
| ogra_ | yeah | 14:30 |
| ogra_ | i didnt ... | 14:30 |
| ogra_ | rsalveti, how did you install ? | 14:30 |
| infinity | ogra_: Oh, so you might have had bits of /etc redirected or other weirdness? | 14:31 |
| ogra_ | infinity, well, technically these bits are also there in davmor2'S case | 14:31 |
| ogra_ | it is just that / is rw from boot on, the bind mount farm gets processeed in both cases | 14:32 |
| ogra_ | thats why i waiting to hear how rsalveti installed | 14:32 |
| ogra_ | and if his system is completely or just temporary writable ... if we used the same method then it is surely caused by this | 14:33 |
| davmor2 | ogra_: from his mail | 14:33 |
| davmor2 | For the lazy ones: | 14:33 |
| davmor2 | (from host) $ phablet-config writable-image | 14:33 |
| davmor2 | (from target): | 14:33 |
| davmor2 | phablet@ubuntu-phablet:~$ sudo apt-add-repository ppa:rsalveti/ppa | 14:33 |
| davmor2 | phablet@ubuntu-phablet:~$ sudo apt-get update | 14:33 |
| davmor2 | phablet@ubuntu-phablet:~$ sudo apt-get install libc-bin libc6 multiarch-support | 14:33 |
| davmor2 | phablet@ubuntu-phablet:~$ sudo reboot | 14:33 |
| rsalveti | ogra_: infinity: just dpkg -i | 14:33 |
| ogra_ | davmor2, i'm taking about the test a few mins ago | 14:33 |
| ogra_ | using the proposed package | 14:33 |
| ogra_ | (not the ppa) | 14:33 |
| davmor2 | ogra_: ah fair enough :) | 14:34 |
| ogra_ | rsalveti, on a fully writable system ? | 14:34 |
| ogra_ | or did you remount | 14:34 |
| infinity | Yeah, the PPA package wouldn't require an ldconfig. | 14:34 |
| infinity | But the proposed one does. | 14:34 |
| rsalveti | ogra_: infinity: fully writable: http://paste.ubuntu.com/10684062/ | 14:34 |
| infinity | However, the postinst should be running. | 14:34 |
| infinity | So it shouldn't matter. | 14:34 |
| rsalveti | ops, that's a replace from the same version | 14:34 |
| rsalveti | let me find out the previous output | 14:34 |
| ogra_ | yeah, seems then the mounting doesnt have any effect :/ | 14:34 |
| ogra_ | right, i had the same output | 14:35 |
| ogra_ | no word about triggers | 14:35 |
| infinity | rsalveti: Replace for the same version should still be running the libc-bin triggers. | 14:35 |
| infinity | This will all get papered over in an image build anyway, but WTF. | 14:35 |
| rsalveti | then this is already enough to show up the issue | 14:36 |
| === davidcalle_ is now known as davidcalle | ||
| infinity | rsalveti: A manual dpkg -i (replacing, not upgrading, same as you) here runs triggers just fine. So there's something deeply wrong with the phone filesystem. :/ | 14:38 |
| infinity | This isn't happening on a filesystem with no inotify support, is it? | 14:39 |
| rsalveti | nops | 14:42 |
| ogra_ | infinity, no-install-recommends and we dont use ubuntu-standard ... that would be the two most significant changes (beyond the bindmount farm) | 14:53 |
| infinity | ogra_: Yeah, neither of those two things make a difference. Especially not when running dpkg -i on a single deb. | 14:57 |
| ogra_ | right | 14:57 |
| infinity | ogra_: I feel like this is a puzzling thing I want to know the answer to, but like it's also not really relevant to this specific fix. The only thing that made it relevant is that that upgrade requires an ldconfig run. | 14:58 |
| ogra_ | right, i think we can put it into a box and re-visit it once such a prob arises again | 14:59 |
| dmsimard | Hi guys. Could I get a few pairs of eyes on what I believe to be an important bug.. ? https://bugs.launchpad.net/initramfs-tools/+bug/1436098 | 15:00 |
| ubottu | Launchpad bug 1436098 in initramfs-tools "Pre-seeding linux-generic-lts-utopic in a trusty install lacks the utopic kernel initrd and results in a kernel panic at first boot" [Undecided,New] | 15:00 |
| Odd_Bloke | Is there any harm in having a service that doesn't exist in After= in a systemd service definition? | 15:02 |
| infinity | dmsimard: Responded. | 15:03 |
| doko | Mirv, qt ping | 15:04 |
| infinity | ogra_: Well, there's certainly a bug here that affects your QA process if triggers don't get run on manual installs. | 15:04 |
| dmsimard | infinity: Thanks. | 15:07 |
| === lool- is now known as lool | ||
| === eam_ is now known as eam | ||
| ogra_ | infinity, can you let me know once the package migrated, so i can spin a new image ? | 15:28 |
| ogra_ | (i assume that happens today ?) | 15:28 |
| infinity | ogra_: The plan was to have it happen this morning, but we're still arguing with one last beta bug that we may or may not fix. | 15:30 |
| infinity | ogra_: Though, if we do fix the beta bug, I'll probably let glibc in on that respin anyway. | 15:31 |
| ogra_ | ok | 15:31 |
| strikov | pitti: o/ | 16:22 |
| === Sugi is now known as Guest88961 | ||
| strikov | pitti: i'm mostly done with juju packaging for vivid and have one question; in the bug you proposed a way to run upstart-dependent tests by installing upstart from the test itself: https://bugs.launchpad.net/juju-core/+bug/1409639/comments/13 | 16:23 |
| ubottu | Launchpad bug 1409639 in juju-core (Ubuntu Vivid) "juju needs to support systemd for >= vivid" [High,Triaged] | 16:23 |
| pitti | hey strikov | 16:24 |
| strikov | pitti: what is simpler/better to do: (a) create juju 1.22 package w/o this fix and manually move it from -proposed to -released or (b) to include this hack into the tests | 16:24 |
| pitti | strikov: your choice really -- if you want to continue running the tests for upstart, let the test install upstart-sysv; otherwise disable the test in d/t/control | 16:26 |
| pitti | strikov: personally I think (b) is better as you keep testing both init systems | 16:26 |
| pitti | strikov: or, an intermediate approach would be to have the test check which init system you are using, and skip tests for the "other" one | 16:27 |
| pitti | strikov: i. e. the "under upstart" test skips itself under vivid, but runs under <= utopic, and the "under systemd" test skips itself for <= utopic | 16:27 |
| pitti | strikov: check with [ -d /run/systemd/system ] if systemd is running; if not, you can assume upstart (under ubuntu) | 16:28 |
| strikov | pitti: thanks a lot! i thought a bit and i like your point about testing both upstart and systemd; theoretically juju should support both on vivid so it might be useful to verify that | 16:34 |
| pitti | strikov: I meant that you usually want to make the same package work on all releases, don't you? | 16:34 |
| pitti | strikov: so keeping the tests identical too might be easier to maintain | 16:35 |
| strikov | pitti: yes, so if current init method is system -- i check juju against it, then switch to upstart and check it as well; if i'm using upstart -- i check juju only against upstart | 16:36 |
| pitti | strikov: note that since I typed that comment the package you need to install changed to "upstart-sysv" | 16:37 |
| strikov | pitti: i already met this issue ;) | 16:38 |
| strikov | pitti: does /tmp/autopkgtest-reboot requires any root permissions for the test? | 16:38 |
| pitti | strikov: yes, you must call it as root | 16:38 |
| strikov | pitti: ack, tnx | 16:39 |
| didrocks | phew | 16:50 |
| * didrocks hates fiber operators | 16:50 | |
| didrocks | they unplugged me to plug another one | 16:50 |
| pitti | wb didrocks! | 16:51 |
| didrocks | had to go to the cave | 16:51 |
| didrocks | find my fiber number | 16:51 |
| didrocks | and replug myself | 16:51 |
| seb128 | didrocks, anyone has access to the board? they don't have in a closed box?! | 16:53 |
| rbasak | We have that problem here with POTS. Technicians who can't find dial tones assume pairs aren't in use and use them for something else. So doing things like DSL with no POTS voice service is dangerous. | 16:53 |
| didrocks | seb128: well, they have torx screws | 16:53 |
| seb128 | no lock? | 16:53 |
| didrocks | seb128: and didn't even need to go upstair | 16:53 |
| seb128 | weird... | 16:53 |
| didrocks | there was a screwdriver next to it :p | 16:54 |
| didrocks | just too a long time to find the right cable | 16:54 |
| didrocks | well, first identifying it was this | 16:54 |
| didrocks | and no a random issue on line | 16:54 |
| seb128 | didrocks, smart thinking, I wouldn't even have though about going to the cave to check the arrival myself I think ;-) | 16:55 |
| seb128 | like I would have blamed their side or the modem or the street cable... | 16:55 |
| didrocks | seb128: well, I know where it was, so really worthed a check :p | 16:55 |
| seb128 | :-) | 16:56 |
| seb128 | didrocks, you left just when pitti said he had to revert one of your systemd changes, I first though you rage closed IRC ;-) | 16:56 |
| didrocks | ahah, seems like it was a nice timing! | 16:57 |
| pitti | heh, I thought the same | 16:57 |
| pitti | I was afraid of didrocks saying "oh no, not another one" and breaking down in tears | 16:57 |
| * pitti hugs didrocks | 16:57 | |
| * didrocks hugs pitti back | 16:58 | |
| didrocks | no, blame lazy fiber technicians :p | 16:58 |
| * seb128 hugs didrocks and pitti | 16:58 | |
| pitti | oh, hugfest! | 16:58 |
| seb128 | :-) | 16:59 |
| * pitti donne une accolade retour à seb128 | 16:59 | |
| * didrocks hugs seb128 back | 16:59 | |
| shadeslayer | bdmurray: uf, sorry about that | 17:25 |
| shadeslayer | I'll add it to my todo list | 17:25 |
| strikov | To fix tomcat7 tests I need to update keys and certs inside the source tree (old ones expired). I'd usually come up with a patch inside d/patches but some of the files I need to update are binaries. Is there any non-destructive way (patch but not source tree modification) to do that? Thanks. | 17:38 |
| mdeslaur | strikov: yeah, source format 3.0 supports binary files...but I can never remember the magic incantation to do it...let me search a bit | 17:42 |
| strikov | mdeslaur: thanks | 17:43 |
| mdeslaur | strikov: you modify the binary files in the tree and you add the path to a file called debian/source/include-binaries | 17:45 |
| strikov | mdeslaur: i don't do any quilt magic manually, right? | 17:46 |
| mdeslaur | nope, all files listed in debian/source/include-binaries will get put in the debian tarball | 17:47 |
| strikov | mdeslaur: awesome, thanks! | 17:47 |
| mdeslaur | strikov: ah! an example: https://launchpad.net/ubuntu/+source/serf/1.3.3-1ubuntu0.1 | 17:47 |
| === gusnan_ is now known as gusnan | ||
| strikov | mdeslaur: that worked, again thanks for helping | 18:32 |
| mdeslaur | strikov: cool, np! | 18:32 |
| LocutusOfBorg1 | nk | 19:11 |
| LocutusOfBorg1 | hi developers, syncing tomcat 7.0.56-2 from debian will fix the build failures | 19:11 |
| LocutusOfBorg1 | a.k.a. 1432715 | 19:11 |
| LocutusOfBorg1 | I guess | 19:11 |
| === lifeless1 is now known as lifeless | ||
| === Quintasan_ is now known as Quintasan | ||
| Riddell | mvo: so no ideas on baloo packaging? | 20:19 |
| mvo | Riddell: not right now, sorry but I had a super busy day, I can try to reproduce tomorrow morning | 20:22 |
| Riddell | mvo: thanks, it's really weird I've no idea why it would want baloo4 at all | 20:23 |
| mvo | Riddell: it looks a lot like a ordering bug in apt, we had those before, really hard to track down unfortunately, but maybe if I can reproduce I can create a easy(?) workaround | 20:26 |
| doko | roaksoax, your maas upload removes slangasek's changes, and doesn't change the python django dependency ... | 20:46 |
| roaksoax | doko: the maas upload didn't remove slangasek 's changes since we backported those changes to 1.7 | 20:49 |
| doko | ahh | 20:49 |
| roaksoax | doko: but yes, it is missing the changes for packaging, which I'll take care of | 20:49 |
| roaksoax | doko: i was hoping we would release 1.8 this week, but seems might not happen | 20:49 |
| teward | hey stupid question but why did I get jenkins emails this morning...? if anyone knows | 20:52 |
| infinity | teward: The content of the mail might be informative... | 20:54 |
| teward | infinity: Jenkins Failure - vivid-adt-nginx 42 | 20:55 |
| teward | neither of the links there actually resolved (E:NoDataReturned) | 20:55 |
| teward | more curious why I got em | 20:56 |
| infinity | teward: I'd assume you got them because you uploaded the last nginx. | 20:57 |
| teward | ahhh ok | 20:58 |
| infinity | teward: You should have gotten a followed "Fixed" mail, by the looks of things. | 20:58 |
| teward | infinity: indeed. wondering why it died initially though, cause it looks like the next build worked fine | 20:59 |
| infinity | s/followed/followup/ | 20:59 |
| teward | was there something up with jenkins on the first one? | 20:59 |
| infinity | teward: Looks like a weird infra problem, as it seems to have registered a success as a failure. :P | 21:00 |
| teward | indeed, it's why i was curious :) | 21:00 |
| infinity | Given that pitti manually kicked off the next build, I guess he is/was aware of it. | 21:00 |
| teward | infinity: so, I should only be concerned if it actually has failures? | 21:01 |
| teward | (and not this weird infra problem) | 21:01 |
| infinity | teward: Yeah. | 21:01 |
| teward | cool, i can put away the hard drive with all the nginx packages i've done work on xD | 21:01 |
| teward | thanks | 21:01 |
| teward | (also is the first time I've ever had an email from jenkins) | 21:02 |
| infinity | You're lucky. | 21:03 |
| infinity | I get flapping testsuite spam all the time. Lots of tests really need fixing, as does the infrastructure running them. :/ | 21:03 |
| teward | infinity: heheh. My last nginx build in sbuild exploded with a nondeterministic build failure and no apparent reason for it to fail but meh | 21:06 |
| teward | rebuilding the chroots now just in case it's a chroot problem, but meh | 21:06 |
| teward | so i hear you (got a lot of alerts last night xD) | 21:06 |
| doko | infinity, just found https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1386524 | 21:18 |
| ubottu | Launchpad bug 1386524 in valgrind (Ubuntu) "Update Ubuntu 14.04 with full Valgrind LE support." [Undecided,New] | 21:18 |
| doko | would you mind updating to 1.10.1 to the version in vivid? | 21:18 |
| infinity | doko: Does valgrind have a decent testsuite that it actually passes, and/or any other way to validate it meaningfully? | 21:25 |
| infinity | doko: On the one hand, "it's just a debugging tool" makes a good argument for updating it, since it shouldn't affect anyone at runtime, on the other hand "it's just a debugging tool" means it's less useful on an LTS when we expect most active development to be happening in 15.04, 15.10, etc. | 21:26 |
| infinity | doko: Sooo... Maybe! | 21:26 |
| micahg | doko: any reason to keep around gcc in universe? I'd like to file removal requests (or work towards that where appropriate) | 21:32 |
| infinity | micahg: gcc-4.8? It still has things that build-dep on it. | 21:32 |
| micahg | was starting with 4.4, but asking in general | 21:33 |
| === salem_ is now known as _salem | ||
| doko | micahg, well, fixing build failures would be more important ;) | 22:23 |
| micahg | doko: I started looking into some of those also, but some of the compilers have build failures as well and this is one way of addressing ;) | 22:24 |
| infinity | doko: What's the rationale for the new upstream version of tbb? | 22:38 |
| doko | infinity, builds on arm64 and ppc64el | 22:50 |
| infinity | doko: I like that rationale. Too painful to backport specific fixes, I assume? | 22:55 |
| doko | infinity, well, I started looking, but gave up | 22:56 |
| infinity | doko: Wait, the version in unstable builds on arm64 and ppc64el | 22:56 |
| doko | infinity, yes, but not in -proposed | 22:56 |
| doko | I cancelled the ppc64el build, but that one fails too. my testbuild is in doko/toolchain | 22:57 |
| infinity | Weird. Fair enough. | 22:57 |
| infinity | The rdep list is short, I assume you're prepared to deal with fallout if someone screams. | 22:57 |
| doko | mdeslaur, libgcrypt11 doesn't like you | 22:57 |
| infinity | Looks like it should stop producing libgcrypt11-dev | 22:59 |
| infinity | Though, if 20 produces 11-dev, does that imply that we can safely just rebuild the world and drop 11 entirely? | 23:00 |
| infinity | I'm all for that. | 23:00 |
| sarnold | where did 1.5.4-3+really1.6.2-4ubuntu1 come from? IU don't see it here: https://launchpad.net/ubuntu/+source/libgcrypt11/+publishinghistory | 23:02 |
| infinity | sarnold: libgcrypt20 produces it. | 23:02 |
| infinity | sarnold: Hence the next couple of lines I typed. :P | 23:03 |
| sarnold | infinity: aha :) thanks | 23:03 |
| infinity | In my copious free time this evening, I might try rebuilding all the libcgrypt11 rdeps. If they're all happy with 20, we'll just rebuild the world and drop 11 like a bad habit. | 23:04 |
| infinity | If they're not happy with 20, we need to revert this weird 11-dev == 20 assumption. | 23:05 |
| infinity | So, worth the test regardless. | 23:05 |
| === greyback__ is now known as greyback | ||
| === tmpRAOF is now known as RAOF | ||
| mdeslaur | infinity: I was making a libgcrypt11 package without -dev, should I wait? | 23:30 |
| infinity | mdeslaur: Well, if the supposed claim that 20 == 11 is true, we should aim to drop 11. | 23:31 |
| infinity | mdeslaur: And if it's not true, we need a new 11 with a version-bumped 11-dev and the 11-dev from 20 dropped. | 23:31 |
| infinity | mdeslaur: So, yeah, no point in your upload, IMO. | 23:31 |
| mdeslaur | ok, I'll wait to see what your test rebuild shows | 23:31 |
| mdeslaur | infinity: let me know how it turns out | 23:32 |
| infinity | mdeslaur: Yeahp. | 23:33 |
| doko | crap, the gmp ftbfs on armhf persists | 23:38 |
| === gusnan is now known as Guest40762 | ||
| infinity | doko: That looks a lot like a glibc testsuite failure that binutils 2.26 (or, something backported from 2.26 to your 2.25 branch) caused. | 23:42 |
| infinity | doko: Had to do with mixing and matching PIE and non-PIE code. | 23:42 |
| infinity | doko: Though, why you'd only see it on armhf is a mystery, so it's probably not that issue, just looks like it. | 23:42 |
| infinity | doko: But, maybe compiling that test with some PIE would make it happy. Who knows. :P | 23:43 |
| doko | well, I'll have to check. but I already reverted that hjl patch | 23:45 |
| infinity | Oh, did you? I didn't notice cause I'd already future-proofed my testsuite anyway. | 23:46 |
| infinity | Anyhow, it's probably not that regardless, cause that wouldn't be just ARM. | 23:47 |
| doko | ahh, it's another one | 23:51 |
| doko | PR 15228 | 23:52 |
| doko | https://sourceware.org/bugzilla/show_bug.cgi?id=18167 | 23:55 |
| ubottu | sourceware.org bug 18167 in ld "[2.25 regression] binutils fails to link gmp on ARM32" [Normal,New] | 23:55 |
| doko | that will be for tomorrow ... | 23:56 |
| infinity | doko: Nice to see amodra calling out hjl's cowboy code. :P | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!