| === jbicha is now known as Guest19466 | ||
| pitti | good morning | 05:10 |
|---|---|---|
| pitti | sarnold: thanks for pointing out; seems something again swallowed the failure cron mail :/ | 05:11 |
| pitti | sarnold: restarted | 05:12 |
| pitti | wgrant: hm, saucy langpack export is supposed to happen twice a week now, right? but https://translations.launchpad.net/ubuntu/saucy/+language-packs still doesn't have any packs | 06:03 |
| === 65MAANWI2 is now known as tvoss | ||
| === smb` is now known as smb | ||
| === gusch_ is now known as gusch | ||
| pitti | dobey: FYI, bug 1197005 | 07:26 |
| ubottu | bug 1197005 in autopkgtest (Ubuntu) "Add "expect stderr" restriction" [Medium,Triaged] https://launchpad.net/bugs/1197005 | 07:26 |
| === doko_ is now known as doko | ||
| doko | jibel, pitti: looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html, and trying to understand why two test for perl fail ... | 08:09 |
| pitti | doko: adequate just recently got a new test via debian which fails; that can probably be overridden by the release team with a badtest marker | 08:10 |
| doko | saucy-adt-adequate doesn't show any useful hints, at least I can't see any | 08:10 |
| pitti | abi-compliance-checker also never succeeded, so its test needs to be fixed | 08:10 |
| pitti | adequate SKIP Test breaks testbed but testbed does not advertise revert-full-system | 08:11 |
| pitti | ah yes | 08:11 |
| pitti | we need to teach autopkgtest that this is ok when running in a VM, I'll think about that | 08:12 |
| pitti | in the meantime, a badtest marker should do | 08:12 |
| doko | does debian run these tests at all? | 08:13 |
| doko | pitti, ^^^ | 08:19 |
| pitti | doko: not in a central jenkins instance | 08:19 |
| pitti | (at the moment) | 08:19 |
| Laney | I haven't managed to get the same environment that jenkins provides, especially wrt. internet access | 08:22 |
| Laney | see- software-center was passing in run-adt-test for me | 08:23 |
| * Laney forces adequate | 08:23 | |
| Laney | pitti: shouldn't that have been regarded as a pass anyway though? | 08:24 |
| Laney | all tests skipped because we don't know how to run them | 08:24 |
| pitti | Laney: yes, it should | 08:25 |
| pitti | Laney: we still want to know about those, but ideally it woudln't block propagation in this case | 08:25 |
| Laney | yeah | 08:25 |
| Laney | some kind of pass-but-investigate-me state | 08:26 |
| === Noskcaj10 is now known as Noskcaj | ||
| sil2100 | gema: hi! | 08:45 |
| sil2100 | gema: I have filled in 2 bugs that are currently blocking the daily-release of the unity stack | 08:45 |
| sil2100 | gema: LP: #1202972 and LP: #1202976 | 08:45 |
| ubottu | Launchpad bug 1202972 in Unity "Nux ABI break without Unity dependencies bump" [High,New] https://launchpad.net/bugs/1202972 | 08:45 |
| ubottu | Launchpad bug 1202976 in Unity "Unity preview autopilot integration tests failing" [High,New] https://launchpad.net/bugs/1202976 | 08:45 |
| gema | sil2100: are those bugs in the code or in the tests or where? | 08:46 |
| sil2100 | gema: the first one I might be able to help with, but the autopilot test failures needs some attention from upstream | 08:46 |
| doko | pitti: how often is the autopkgtest information in update_excuses updated? (looking at the failing test for gcc-4.8, which now passes) | 08:46 |
| sil2100 | gema: about the test failures, hm, not sure what's wrong really - those look more like real failures, or something | 08:46 |
| gema | sil2100: ack | 08:47 |
| pitti | doko: I guess each time the publisher runs, so something like every 20 mins presumably | 08:47 |
| sil2100 | gema: someone from the unity team I think should check those out | 08:47 |
| gema | sil2100: we are working on triaging problems on a pad today: http://pad.ubuntu.com/test-triaging | 08:47 |
| gema | sil2100: I added your bugs to my list | 08:47 |
| didrocks | thanks sil2100, gema ;) | 08:48 |
| gema | didrocks: anything else that is blocking you, add to that pad, plz | 08:49 |
| didrocks | gema: I asked sil2100 to add those, all the rest is published and AP tests run successfully on the desktop | 08:49 |
| didrocks | (and are now copied to distro) | 08:50 |
| didrocks | gema: there are mir-related fixes/issues we are working on, but it's not in distro yet :) | 08:50 |
| gema | didrocks: ok | 08:51 |
| sil2100 | There's also a webapps problem, but I'll look into that later, I have hoped Robert resolved the issue yesterday | 08:51 |
| didrocks | sil2100: he did an additional merge for components | 08:52 |
| didrocks | sil2100: maybe he didn't get that deployed or the full list right | 08:52 |
| doko | pitti, strange, because the successful test run was at 4:52am | 08:52 |
| pitti | doko: you mean the scipy one, right? | 08:53 |
| doko | pitti, yes | 08:53 |
| pitti | jibel, cjwatson: ^ any idea why https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-python-scipy/ succeeded hours ago, but http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html still shows it as FAIL? | 08:53 |
| jibel | pitti, looking | 08:54 |
| jibel | pitti, odd, I see no record of the successful build apart the result in jenkins | 09:04 |
| pitti | jibel: while I'm hackign on autopkgptest, anything else that is urgent on your list? | 09:21 |
| pitti | https://launchpad.net/ubuntu/+source/autopkgtest/+bugs?orderby=status :) | 09:22 |
| === tvoss_ is now known as tvoss|benchmark_ | ||
| === tvoss|benchmark_ is now known as tvoss_ | ||
| jibel | pitti, nothing else urgent on my list | 10:14 |
| === Sweetsha1k is now known as Sweetshark | ||
| pitti | jibel: d'accord, merci | 10:14 |
| jibel | pitti, oh, there was the LXC driver | 10:14 |
| jibel | is it something that you think is ready to merge upstream? | 10:14 |
| * pitti looks for the MP | 10:15 | |
| pitti | https://code.launchpad.net/~racb/ubuntu/saucy/autopkgtest/lxc/+merge/172856 | 10:15 |
| pitti | jibel: it looks okay from my POV, I just haven't tested it yet as I don't have a real container setup | 10:16 |
| jibel | pitti, okay, I'll do more test with that backend and update the MP | 10:16 |
| rbasak | xnox: I still haven't been able to reproduce your apache 2.4 upgrade failure. AFAICT, since the modules used to depend on apache2.2-common and that package no longer exists, and the new ones depend on apache2-api-20120211, the apache 2.4 postinsts generally runs first, and then the module ones. So I can't find a combination that breaks. | 10:42 |
| seb128 | cjwatson, hey, do you have click packages example somewhere to download? (I want to install some on my touch image to play with click list and the system settings ui) | 10:45 |
| ogra_ | seb128, http://people.canonical.com/~sergiusens/click_packages/ | 10:50 |
| ogra_ | they are also in todays image | 10:50 |
| ogra_ | oh, wait, old url | 10:50 |
| ogra_ | seb128, http://people.canonical.com/~ubuntu-archive/click_packages/ | 10:51 |
| ogra_ | thats the right one | 10:51 |
| xnox | rbasak: let me roll back to july 18th 10am and upgrade again. | 10:53 |
| rbasak | xnox: if you could grab the unpack/configure ordering on the upgrade when it fails, that'd be awesome. And which package's postinst failed? | 11:00 |
| === MacSlow is now known as MacSlow|lunch | ||
| xnox | rbasak: apache2 post-inst failed. | 11:03 |
| xnox | due to broken config. | 11:03 |
| xnox | (well not acceptable config) | 11:03 |
| apw | pitti, hey ... we have just had an autopkgtest failure on nova, following a xen upload, and it says there is a dependancy issue, is there any way to find out what the dep issue is reported in the log for this jenkins job: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-nova/ARCH=amd64,label=adt/lastBuild/ | 11:04 |
| seb128 | ogra_, thanks | 11:05 |
| rbasak | xnox: do you know which file? Is this an incompatible change to a custom config, or the default config supplied by a package? | 11:07 |
| xnox | rbasak: so i had perl, php5, wsgi apache2 modules installed and enabled with apache2 preform server, at postinst of apache2 (2.4) it was failing to load php5 (2.2) module due to abi incompatibity. Doing the same scenario but dist-upgrade from raring, results in proper ordering (php before apache-php module before apache itself) | 11:10 |
| * rbasak pokes | 11:17 | |
| rbasak | xnox: do you think there's a bug here, or if this needs further investigation? I haven't managed to figure out how to get that scenario to happen at all, since the old libapache2-mod-php5 depends on apache2.2-common, and the new apache2-bin conflicts with apache2.2-common. So how does apache2's postinst (which Depends on apache2-bin) get run while the old libapache2-mod-php5 is still configured? | 11:21 |
| xnox | =/ | 11:25 |
| rbasak | xnox: could you pastebin me a log of the failure case, maybe? Or are you unable to reproduce it now? | 11:37 |
| pitti | apw: http://people.canonical.com/~ubuntu-archive/testing/saucy-proposed_probs.html has quite some hints | 11:45 |
| pitti | apw: otherwise, enable saucy-proposed in sbuild/chroot/locally and dig down with apt-get | 11:45 |
| === ara is now known as Guest69887 | ||
| doko | yolanda, are you currently doing +1 maintenance? | 12:11 |
| yolanda | doko, what do you mean? | 12:12 |
| doko | yolanda, ok probably not ;) | 12:12 |
| doko | yolanda, could you put source uploads for your lua5.2 fixes to p.o.c, or chinstrap? | 12:13 |
| yolanda | doko, i created MMP | 12:13 |
| yolanda | MP | 12:13 |
| yolanda | do you want the urls? | 12:13 |
| doko | well, with merges, I have to create the packages myself ... | 12:14 |
| yolanda | doko, what do you need then, the debdiffs? | 12:24 |
| yolanda | i can push them | 12:24 |
| doko | yolanda, no, diff.gz, dsc, and changes file | 12:30 |
| yolanda | doko, ok, let me push them | 12:31 |
| === MacSlow|lunch is now known as MacSlow | ||
| yolanda | doko, pushed, they are in /home/yolanda in chinstrap | 12:41 |
| doko | yolanda, not readable | 12:43 |
| yolanda | permissions? | 12:43 |
| yolanda | i added +r | 12:44 |
| doko | yolanda, one more thing about rubyluabridge, could you check if it builds with the default gcc? | 12:46 |
| yolanda | doko, not sure i understand you, sorry | 12:47 |
| doko | yolanda, it build-depends on gcc-4.6 | 12:47 |
| doko | and for rrdtool, could we consider removing the ruby1.8 package? | 12:48 |
| yolanda | doko, about rubyluabridge, i'll try to unpin the dependency | 12:48 |
| yolanda | for rrdtool, i don't know, if that is needed or not | 12:49 |
| yolanda | if you think it could be removed we can push it | 12:50 |
| ev_ | if someone could new whoopsie-preferences, I'd greatly appreciate it: https://launchpad.net/ubuntu/saucy/+queue?queue_state=0&queue_text=whoopsie-preferences | 12:51 |
| === ssweeny` is now known as ssweeny | ||
| doko | $ apt-cache rdepends librrd-ruby1.8 | 12:59 |
| doko | librrd-ruby1.8 | 12:59 |
| doko | Reverse Depends: | 12:59 |
| doko | librrd-ruby | 12:59 |
| doko | rrdtool-dbg | 12:59 |
| doko | yolanda, ^^^ | 12:59 |
| doko | looks fine for removal | 13:00 |
| dobey | pitti: cool. what's the exact restriction flag? and when can i start using it? :) | 13:00 |
| pitti | dobey: when> in a few hours, when it autosyncs from Debian | 13:00 |
| doko | ev_, looking | 13:00 |
| ev_ | thansk | 13:00 |
| pitti | dobey: Restrictions: allow-stderr | 13:00 |
| dobey | pitti: ah, great. thanks! | 13:01 |
| doko | ev_, symbols file? | 13:02 |
| yolanda | doko, ok, i'll do it | 13:07 |
| ev_ | doko: hm? Why is that necessary? | 13:07 |
| doko | ev_, well, not necessary, but good style, and usually required for promotion to main | 13:08 |
| doko | but if this stay in universe, it's probably ok | 13:08 |
| ev_ | am I missing something? I don't see GTK+ or cairo shipping a .symbols file. | 13:09 |
| ev_ | doko: it's intended for main | 13:09 |
| doko | ev_, complain to seb128 or didrocks | 13:09 |
| ev_ | doko: if you point me in the direction of a dh9 package that does this right, I'll happily fix it as 0.4 | 13:10 |
| seb128 | ev_, ls /var/lib/dpkg/info/libgtk-3-0*symbols ? | 13:10 |
| seb128 | ev_, ls /var/lib/dpkg/info/libcairo*symbols | 13:11 |
| ev_ | oh, I was assuming they'd be output in dpkg -L | 13:11 |
| ev_ | which is obviously not the case | 13:11 |
| seb128 | no, that's like postinst, etc | 13:11 |
| ev_ | indeed | 13:11 |
| cjwatson | libpipeline is a simple dh9 library package that has .symbols | 13:11 |
| seb128 | ev_, you don't have a lot to do, just run dpkg-gensymbols in the build tree after build to generate the file | 13:12 |
| seb128 | ev_, typically dpkg-gensymbols -p<lib> -v<version> -Odebian/<lib>.symbols | 13:12 |
| cjwatson | for a library you wrote yourself it's fairly easy to handcraft it too | 13:13 |
| ev_ | fixing | 13:14 |
| seb128 | ev_, you might want to "export DPKG_GENSYMBOLS_CHECK_LEVEL=4" in the rules as well (to stop the build on .symbols being outdated, so you don't forget to keep it uptodate ... the default behaviour is to just print the diff during the build) | 13:14 |
| ev_ | thanks guys | 13:14 |
| seb128 | yw | 13:14 |
| emper0r | hi | 13:18 |
| emper0r | got trouble with chattr.. flag permisions when activate +i options | 13:18 |
| emper0r | any idea ? | 13:18 |
| emper0r | debian works fine | 13:19 |
| === _salem is now known as salem_ | ||
| ev_ | doko: fixed as whoopsie-preferences 0.4 | 13:40 |
| dobey | xnox: ping | 13:40 |
| yolanda | doko, rubyluabridge builds fine with default g++ | 13:42 |
| doko | ev_: why 0.0.0, when you only have versions like 0.x? anyway, accepting | 13:45 |
| === psivaa is now known as psivaa-afk | ||
| yolanda | doko, do you want me to resend rubyluabridge or you are ok with setting the g++ dependency? | 13:56 |
| doko | yolanda, I'll do it | 13:57 |
| doko | thanks for checking | 13:57 |
| yolanda | np | 13:57 |
| yolanda | working in the 1.8 drop of rrdtool now | 13:57 |
| doko | uploaded | 13:59 |
| yolanda | doko, should we drop the librrd-ruby1.8 package? | 14:02 |
| doko | yolanda, yes, I think so. keep in mind there is a dependency on it in librrd-ruby | 14:05 |
| dobey | xnox: i'm having some trouble trying to add a --version-script to ubuntuone-credentials. it seems UbuntuOne::* being global and everything else local isn't enough to actually link to the library. the tests program is failing to link due to missing vtables :( | 14:15 |
| doko | dobey, can you paste the script, and the missing symbols? | 14:18 |
| dobey | sure, one second | 14:20 |
| yolanda | doko, pushed new files for rrdtool to chinstrap | 14:20 |
| dobey | doko: http://pastebin.ubuntu.com/5890930/ | 14:21 |
| yolanda | doko, did you see the FTBFS for rubyluabridge? do you know what's the problem? | 14:21 |
| dobey | doko: also, i'm not sure why, but for some reason cmake seems to want to pass the -Wl,--version-script= to the link line of the text program too, though i've only defined it for the library target :-/ | 14:22 |
| dobey | not sure if that is relevant | 14:22 |
| doko | dobey, well, the vtable for UbuntuOne* are missing | 14:22 |
| === mpt_ is now known as mpt | ||
| dobey | doko: yes, but why? | 14:23 |
| doko | because they don't match? | 14:23 |
| dobey | you can't define "vtable for *" in the version script | 14:23 |
| doko | use the unmangled names | 14:23 |
| doko | mangled | 14:23 |
| doko | yolanda, no, didn't look yet | 14:23 |
| dobey | i don't understand | 14:23 |
| doko | dobey, how do the mangled symbols for the vtables look like? | 14:25 |
| dobey | doko: ah, i don't know | 14:27 |
| doko | dobey, find out, and then add this outside the extern C, but inside the global section | 14:30 |
| dobey | ok, i'll try. thanks | 14:31 |
| seb128 | ev_, hum | 14:34 |
| seb128 | dpkg: error processing whoopsie-preferences_0.4_i386.deb (--install): | 14:34 |
| seb128 | trying to overwrite '/usr/bin/whoopsie-preferences', which is also in package activity-log-manager 0.9.7-0ubuntu3 | 14:34 |
| ev_ | oh, I thought I handled that with a breaks/replaces | 14:34 |
| seb128 | ev_, ^ known issue? | 14:34 |
| seb128 | you break/replaces << 0.9.7 | 14:34 |
| seb128 | but I've 0.9.7-0ubuntu3 which is > 0.9.7 | 14:35 |
| seb128 | while still shipping that file | 14:35 |
| ev_ | seb128: argh, sorry about that | 14:36 |
| ev_ | uploading a << 0.9.8 | 14:36 |
| seb128 | ev_, do you plan to get activity-log-manager 0.9.8 uploaded as well? | 14:37 |
| ev_ | seb128: yes: https://code.launchpad.net/~ev/activity-log-manager/split-out-diagnostics-service/+merge/175820 and https://bugs.launchpad.net/ubuntu/+source/activity-log-manager/+bug/1203042 | 14:37 |
| ubottu | Ubuntu bug 1203042 in activity-log-manager (Ubuntu) "Clean up packaging for 0.9.8" [Undecided,New] | 14:37 |
| doko | ev_, that won't help with upgrades, you need a new w-p too | 14:37 |
| ev_ | doko: hm? If whoopsie breaks && replaces on << activity-log-manager 0.9.8, surely that fixes it? | 14:38 |
| seb128 | ev_, ok, I'm going to block the ubuntu-system-settings merge on that to happen, otherwise you will make it conflict with ubuntu-desktop | 14:38 |
| ev_ | seb128: *nods* | 14:38 |
| ev_ | thanks for the catch | 14:38 |
| seb128 | np | 14:38 |
| seb128 | ev_, is whoopsie-preferences supposed to show an UI? | 14:38 |
| ev_ | still working on addressing the other points in the ubuntu-system-settings MP | 14:38 |
| ev_ | seb128: it's just a DBus service. The UI is provided by ubuntu-system-settings and activity-log-manager. | 14:39 |
| doko | ev_ ahh, I thought you would upload activity-log-manager | 14:39 |
| seb128 | ev_, ok, you might want to move the binary out of /usr/bin then, it's a bit confusing | 14:39 |
| ev_ | doko: ah, I understand your previous statement now. Thanks for the warning all the same :) | 14:39 |
| ev_ | seb128: sure, will do | 14:39 |
| seb128 | thanks | 14:39 |
| ev_ | /usr/share/whoopsie-preferences/whoopsie-preferences? | 14:39 |
| seb128 | ev_, I was thinking /usr/lib/whopsie... but in fact quite some services ship in /usr/bin so maybe don't bother | 14:41 |
| ev_ | okay | 14:41 |
| stgraber | slangasek: ok, so the SB bug is confirmed to be fixed on saucy. I just did a test install in a non-SB OVMF VM and I properly boot through shim post-install | 15:09 |
| stgraber | oh, but I didn't get linux-signed... that's odd | 15:11 |
| stgraber | hmm, grep seems to indicate a base-installer change may also be needed... | 15:14 |
| === cyphermox_ is now known as cyphermox | ||
| rbasak | xnox: I think I have it. On raring I installed libapache2-mod-php5, then changed sources.list to saucy, then "apt-get install libapache2-mod-php5". That gives me a postinst failure with apache complaining about an undefined symbol in libphp5.so. Does that sound familiar? | 15:16 |
| stgraber | cjwatson: would that explain it? (linux-image-signed being removed by ubiquity even though 'linux-signed-generic%s' % altmeta is in the keep list because the kernel code in base-installer checks for SecureBoot too) | 15:16 |
| rbasak | It tried to bring in the new apache 2.4 as expected, but didn't succeed. | 15:17 |
| stgraber | cjwatson: if so, I'll drop that code in base-installer too (always have it return linux-image-signed if the system is UEFI) | 15:18 |
| dobey | doko: hrmm, i'm not quite sure how i can get the mangled string for the vtables :-/ nm output when built without the symbols file, just prints "v vtable for Foo::Bar" too :-/ | 15:20 |
| dobey | and LD_DEBUG=symbols doesn't help much either | 15:21 |
| jbicha | rbasak: I think that's bug 1202653 | 15:22 |
| ubottu | bug 1202653 in apache2 (Ubuntu) "package apache2 2.4.4-6ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/1202653 | 15:22 |
| rbasak | jbicha: that's it. Thanks! | 15:24 |
| stgraber | cjwatson: just noticed you're off today, so I'll just do the change in base-installer, rebuild ubiquity and re-test this afternoon, if that works then I can prepare a cheryr-pick of that whole stuff for precise (starting to sound unlikely to be ready today though) | 15:25 |
| rbasak | I've reproduced in Debian so I'll file there. | 15:25 |
| slangasek | stgraber: great :) | 15:40 |
| slangasek | ev_, seb128, pitti: who is managing the launchpad retracers now? I keep noticing that they're being bursty in their retracing (just saw some retraces of 7-day-old bug reports), which I guess means someone unblocked something but I suspect the root cause has not been addressed | 16:03 |
| seb128 | slangasek, it's mostly pitti, I've access to them but don't watch them too much those days | 16:04 |
| seb128 | slangasek, they usually go down hitting transient issues | 16:04 |
| seb128 | like launchpad timeouts | 16:04 |
| slangasek | ok | 16:04 |
| seb128 | then they don't restart until somebody look at the issue and removes the lock | 16:04 |
| slangasek | but it seems that when someone notices, they just clear it, which means the problem never gets any better :) | 16:04 |
| seb128 | the problem being "launchpad timeouts" most of the time | 16:05 |
| seb128 | which is not something easy to fix :/ | 16:05 |
| slangasek | well, I would say the problem is the retracer can't handle a launchpad timeout gracefully | 16:05 |
| seb128 | right | 16:05 |
| slangasek | stgraber: signed kernel> even without the Lenovo issue, that's what we want | 16:06 |
| seb128 | I'm sure pitti would welcome patches on apport to improve that ;-) | 16:06 |
| seb128 | (hint hint hint;-) | 16:06 |
| slangasek | well, if someone can point me at a backtrace or something of the retracer.. :) | 16:07 |
| seb128 | slangasek, I'm starting wondering if we should just drop bug reporting to launchpad/those retracers | 16:07 |
| seb128 | and claim that e.u.c is the way to go | 16:07 |
| slangasek | is errors not using the same retracers? | 16:07 |
| seb128 | no | 16:07 |
| slangasek | ok | 16:07 |
| slangasek | so I still find it useful to have launchpad backtraces for my own crashes... when they get retraced successfully | 16:08 |
| seb128 | slangasek, ssh porter-i386.canonical.com; sudo -u ubuntu-archive -i; less log/amd64.txt | 16:10 |
| seb128 | slangasek, if you want to see the retracer logs | 16:10 |
| slangasek | ok, thanks | 16:10 |
| seb128 | slangasek, http://paste.ubuntu.com/5891264/ seems a typical timeout one | 16:10 |
| hyperair | micahg: ping. are you maintaining gtk-theme-config? | 16:16 |
| === _ffio_ is now known as ffio | ||
| === fginther is now known as fginther|lunch | ||
| zul | mterry: ping I wanted to get #1203124 and #1203122 on your radar (horizon is blocked on these) | 17:22 |
| === gallth is now known as tgall | ||
| === fginther|lunch is now known as fginther | ||
| === bschaefer_ is now known as bschaefer | ||
| dobey | bah. finally get the vtable issue "fixed" and now cmake's target_link_libraries is buggy, and appending the linker flags to all targets in the build, rather than only the one i specified :( | 18:25 |
| infinity | dobey: With --as-needed, that shouldn't matter terribly, should it? | 18:26 |
| dobey | infinity: it matters if i want different version scripts for different libraries in the same source tree. | 18:27 |
| infinity | dobey: Oh, I jumped in in the middle, didn't realise you were talking about linker scripts, thought you just meant -lfoo stuff. | 18:28 |
| dobey | well, any flags i add. while --as-needed my "fix" linking of unneeded libs, it doesn't fix symbols not being exported due to the version script, in libs where they should be exported :-/ | 18:29 |
| doko | dobey, I'm always eager to ask somebody else about cmake. so please become an expert ;-P | 18:29 |
| dobey | doko: i'm tired of being an expert on build systems :) | 18:32 |
| olli_ | ;) | 19:17 |
| infinity | xnox: So, uhm. My upgrade just now killed init. | 19:42 |
| infinity | xnox: That seems less than ideal. | 19:42 |
| infinity | xnox: The kernel panic this inevitably causes made it a bit difficult to see exactly what package was being unpacked/configured at the time, but libjson-c and upstart were both in the upgrade set. | 19:44 |
| infinity | xnox: Smells of stateful re-exec gone horribly wrong, perhaps? | 19:45 |
| infinity | xnox: Ahh, it was definitely libjson-c2's postinst, since that was all "dpkg --configure -a" had to do when I ran it. | 19:45 |
| infinity | xnox: So, yeah. re-exec shouldn't kill init. Please. :) | 19:45 |
| infinity | stgraber: jodh: slangasek: ^^ | 19:46 |
| zul | can someone promote oslo-sphinx please (https://bugs.launchpad.net/ubuntu/+source/oslo-sphinx/+bug/1199872) its blocking nova from building | 19:46 |
| ubottu | Ubuntu bug 1199872 in oslo-sphinx (Ubuntu) "[MIR] oslo-sphinx" [High,Fix released] | 19:46 |
| infinity | zul: When I have a functional laptop again, sure. | 19:47 |
| zul | infinity: thanks | 19:48 |
| jodh | infinity: please raise an apport bug when you can so someone can look at the captured state data. | 19:52 |
| infinity | jodh: I'm not sure what data there is to capture, given that dead init == kernel panic. | 19:52 |
| jodh | infinity: just use apport - it does the magic :) | 19:52 |
| infinity | I'm dubious, but sure. :P | 19:52 |
| jodh | infinity: also, please note on the bug if you had been building package in a chroot prior to the upgrade. | 19:53 |
| infinity | (I have to finish the upgrade first, my desktop no worky, all I have is consoles) | 19:53 |
| jodh | infinity: who needs more ? :) | 19:53 |
| infinity | jodh: I may or may not have had active schroot sessions. No idea. | 19:53 |
| slangasek | infinity: the segv handler for pid 1 is the same as for any other, you hopefully have a crash report in /var/crash | 19:53 |
| slangasek | infinity: is this a saucy host? | 19:53 |
| infinity | slangasek: saucy host, yes. And sure, I have an sbin_init in /var/crash, but it's 0-length. See above, re: kernel panic when init dies. | 19:54 |
| slangasek | infinity: the kernel doesn't panic until the segv handler ends. | 19:54 |
| slangasek | infinity: what version of upstart did you have installed at the time? | 19:55 |
| infinity | That theory doesn't jibe with the mode 000 0-length file in /var/crash, but sure. | 19:55 |
| slangasek | that just means the crash handler didn't sensibly fsync | 19:55 |
| slangasek | and it's not a theory, that's how it's all desined | 19:55 |
| slangasek | designed | 19:55 |
| infinity | slangasek: 1.9.1-0ubuntu1 | 19:56 |
| slangasek | infinity: ok. that's the buggy one, so you were caught by bug #1199778 | 19:56 |
| infinity | Well, okay, if the handler doesn't fsync, then that's a slightly broken design. ;) | 19:56 |
| ubottu | bug 1199778 in upstart (Ubuntu Raring) "upstart crashes if re-exec'ed with active chroot sessions" [Undecided,New] https://launchpad.net/bugs/1199778 | 19:56 |
| slangasek | do you have chroots that don't correctly divert invoke-rc.d? (policy-rc.d et al) | 19:57 |
| infinity | Well, I was caught by that if I had active chroots. But it's a fair chance I did, because I'm me. | 19:57 |
| infinity | I don't know for sure, mind you. | 19:57 |
| infinity | slangasek: All my schroots use a policy-rc.d | 19:57 |
| slangasek | it's not just "active chroots", it's "chroots that upstart has managed to run services under" | 19:57 |
| jodh | infinity: see if you have a /var/log/upstart/upstart.state file | 19:57 |
| infinity | Hold on. Upgrade done, let me reboot and see if I have a desktop again. | 19:58 |
| slangasek | and yes, there may be a bug report somewhere about the lack of fsync for apport when handling init | 19:58 |
| infinity | Or should I check for said file before I reboot and make it sad? | 19:58 |
| slangasek | or maybe it was just an IRC conversation I had with ev or bdmurray | 19:58 |
| slangasek | infinity: the reboot won't cause the file to be created | 19:58 |
| infinity | Ahh, I have no such file anyway. | 19:58 |
| slangasek | ok | 19:58 |
| infinity | So, while I have a sane policy-rc.d, I do note that upstart does spew syslog with sadness about configuration directories disappearing every time a chroot is torn down. | 19:59 |
| infinity | So, it's clearly doing something in there. | 19:59 |
| slangasek | hum. | 19:59 |
| infinity | Even though I'd prefer it didn't. | 19:59 |
| infinity | Let me reboot so I can more usefully be a copy-and-pastey person. | 19:59 |
| slangasek | upstart only knows about the chroot if something inside the chroot talks to it | 20:00 |
| slangasek | which policy-rc.d should be sufficient to prevent | 20:00 |
| infinity | Hrm. Maybe that hasn't happened in a while. Or my grep-fu sucks. Or it's somehow magically avoiding syslog. | 20:04 |
| infinity | (I tend to notice the vomit in the ringbuffer) | 20:04 |
| infinity | Great, now I can't sort out how to trigger the upstart/dmesg vomit. So, either it was a bug/misfeature that's been fixed, or I have no idea under what conditions I make it happen. | 20:10 |
| infinity | Oh, wait. Hah. Just made it happen. | 20:10 |
| infinity | [ 580.782353] init: /var/lib/schroot/mount/saucy-amd64-5bf993dc-9abc-458b-b9c4-b1af3e38ba44/etc/init: Configuration directory deleted | 20:10 |
| infinity | slangasek: So, all I did in that schroot was a dist-upgrade that pulled in the new libjson-c2 and upstart. | 20:11 |
| infinity | slangasek: But maybe the new upstart also fixes this somehow? | 20:11 |
| infinity | (I wouldn't expect it to be touching the chroot at all, though...) | 20:11 |
| infinity | Of course, if my schroots don't trigger ischroot(1)... | 20:12 |
| infinity | Double-U Tee Eff... | 20:12 |
| infinity | Oh, wait. Yes they do. I was reading the return backwards. | 20:13 |
| infinity | slangasek: So, I am actually fairly curious about how upstart decides it wants to latch on to my chroot. | 20:14 |
| infinity | slangasek: And the winner is: upgrading udev in the chroot. | 20:17 |
| === ircleuser is now known as GoogleSourcer | ||
| xnox | infinity: argh. | 20:38 |
| infinity | xnox: False alarm on the dead init, if it's the bug that was just fixed (since I was on the previous version). | 20:39 |
| xnox | infinity: i think in the last update we put back the asserts in the stateful re-exec, believing that chroot session bug was fixed. | 20:39 |
| infinity | xnox: Though, the part where upgrading udev in a chroot appears to make upstart decide my chroot is its plaything is very curious. | 20:39 |
| xnox | infinity: the bug was in the "new version" asserting upon deserialisation.... | 20:39 |
| infinity | (And yes, I have a policy-rc.d that is correctly stopping udev's restart in postinst) | 20:39 |
| xnox | infinity: and host upstart, should ignore re-exec requests comming from chroot session. | 20:40 |
| xnox | i think you can still be pointing to a real bug here. | 20:41 |
| infinity | xnox: http://paste.ubuntu.com/5892015/ | 20:42 |
| infinity | xnox: That's possibly just cosmetic, but it's curious that it cares about files in my chroot AT ALL. | 20:42 |
| slangasek | infinity: so the upstart postinst calls 'initctl version' even when in a chroot, to figure out based on the running version what upgrade path to use; and it does this even when in a chroot. We discussed this, but jodh was sure this wouldn't be enough to trigger creation of a chroot session on the host upstart | 20:46 |
| slangasek | oh, upgrading udev | 20:47 |
| slangasek | that's interesting | 20:47 |
| infinity | slangasek: Yeah, indeed. | 20:48 |
| infinity | slangasek: And my policy-rc.d is clearly working, as seen in the paste. | 20:48 |
| === salem_ is now known as _salem | ||
| infinity | slangasek: So, Whiskey Tango Foxtrot. | 20:48 |
| slangasek | infinity: so all the udev postinst does is 'invoke-rc.d udev restart' | 20:48 |
| infinity | slangasek: Right, and that bit's being denied. | 20:48 |
| infinity | slangasek: Hence the WTF. | 20:49 |
| slangasek | fun | 20:49 |
| infinity | slangasek: Verified it's not my chroot setup. Enter/exit without doing anything is non-spew-inducing, as is entering the chroot and upgrading some other things. | 20:49 |
| infinity | So it's clearly udev, but. Wha? | 20:49 |
| slangasek | what release is in the chroot | 20:50 |
| slangasek | ? | 20:50 |
| infinity | slangasek: Amusingly, upgrading upstart doesn't trigger this. So, yay you. Boo, udev. | 20:50 |
| infinity | slangasek: Based on the prompt, I'm guessing that's saucy. :P | 20:50 |
| slangasek | right, because udev's misbehavior can't possibly be my fault ;) | 20:51 |
| infinity | Oh, you mean what upstart release? | 20:51 |
| infinity | 1.8-0ubuntu7 | 20:51 |
| slangasek | no, I meant what OS release | 20:51 |
| infinity | saucy-amd64 | 20:51 |
| slangasek | but apparently somewhat out of date? | 20:52 |
| s1lence | Does anybody from canonical in here have a way to reach the legal team? The images of the ubuntu edge were mirrored to imgur and canonical should probably file a takedown request. | 20:52 |
| infinity | lil bit, yeah. | 20:52 |
| s1lence | I know this is the inappropriate channel but I don't know where else to ask | 20:52 |
| xnox | s1lence: not sure what "imgur" is. Do you have a link? and what images? most of our images are allowed to be redistributed..... | 20:53 |
| infinity | xnox: imgur is an image hosting site, and... Wait. You've never heard of it? | 20:53 |
| infinity | xnox: Do you have teh internetz over there? | 20:54 |
| xnox | infinity: i use emacs.... =) | 20:54 |
| s1lence | xnox, imgur is an image hosting service for reddit, I have a link i'll pm you. The part of the server with the images 403'd within a few minuites | 20:54 |
| slangasek | infinity: so invoke-rc.d calls 'initctl version' before doing anything else, including before checking policy-rc.d. Can you check whether calling 'initctl version' in the chroot is sufficient to reproduce? | 20:54 |
| infinity | slangasek: Ahh, doing that before checking policy seems wrong regardless, no? (but will check) | 20:55 |
| slangasek | no, because initctl version is supposed to be innocuous | 20:55 |
| slangasek | and invoke-rc.d is overdesigned in such a way that it has to know what the "normal" policy is before calling policy-rc.d | 20:55 |
| infinity | slangasek: That didn't trigger the bug, no. | 20:56 |
| * infinity installs some random something else with an upstart job to see if this is just invoke-rc.d, or something fundamentally weird and udevy. | 20:57 | |
| slangasek | mmk | 20:58 |
| infinity | Right, so same thing installing sshd. | 20:58 |
| slangasek | infinity: how about 'initctl show-config'? | 20:58 |
| infinity | slangasek: Yep, that does it. | 20:59 |
| slangasek | infinity: please file a bug on upstart+sysvinit | 20:59 |
| slangasek | infinity: also, please try 'telinit u' (after saving any open documents :P) to confirm that this no longer crashes init | 21:00 |
| infinity | slangasek: ow. | 21:06 |
| slangasek | infinity: does that mean it crashed init? | 21:06 |
| infinity | Sure did. | 21:06 |
| slangasek | xnox: ^^ your move. | 21:06 |
| * xnox reads. | 21:07 | |
| infinity | Let me do this fresh for a clean reproducer. | 21:07 |
| infinity | Okay, so. | 21:09 |
| infinity | schroot (with overlay) | 21:10 |
| infinity | initctl show-config (in chroot) | 21:10 |
| infinity | exit chroot | 21:10 |
| infinity | sudo telinit u | 21:10 |
| infinity | Boom. | 21:10 |
| xnox | slangasek: i'd ponder the following move - Castling: upload revert to remove asserts & file in https://wiki.kubuntu.org/UbuntuDevelopment/RevertLog | 21:10 |
| infinity | Not 100%, though. I had to try a few times. | 21:10 |
| xnox | or let me work from that to see a fix. | 21:10 |
| slangasek | xnox: what version do you expect to revert to? 1.9.1-0ubuntu1 also crashed | 21:11 |
| * xnox uses http://people.canonical.com/~jhunt/upstart/scripts/get_state.sh | 21:11 | |
| xnox | slangasek: good point. | 21:11 |
| slangasek | as for removing asserts that are causing init to crash when it shouldn't, that sounds like a prima facie good idea to me | 21:12 |
| infinity | Huh, and that spam really doesn't end up in syslog, only in the kernel ringbuffer, that's why my grep-fu wasn't finding it. | 21:12 |
| slangasek | right, something has gone wonky over the last few cycles wrt upstart's kernel ringbuffer messages not making it to syslog | 21:13 |
| slangasek | I think this may have been a kernel change, not sure | 21:13 |
| xnox | slangasek: i had a report from a precise user about that. which if not reproducible with 12.04.0 would certanly point at the kernel. | 21:14 |
| infinity | slangasek: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1203188 <-- For the spam. | 21:15 |
| ubottu | Ubuntu bug 1203188 in upstart (Ubuntu) "initctl show-config in ephemeral chroot causes dmesg spam" [Undecided,New] | 21:15 |
| infinity | slangasek: I guess we don't need a bug for the crash, we can just re-open the closed one? | 21:15 |
| xnox | infinity: yeah, reopen. | 21:16 |
| infinity | xnox: Reopened and commented. | 21:17 |
| slangasek | infinity: I wanted a separate bug about the fact that invoke-rc.d was triggering the creation of a chroot session in upstart | 21:18 |
| slangasek | which is lower priority than "having a chroot session in upstart causes upstart re-exec to explode" | 21:18 |
| infinity | slangasek: Sure, that's the bug I filed. Or, can be made to say that. :P | 21:18 |
| * slangasek nods | 21:19 | |
| * infinity is now paranoid about using his chroots. Or upgrading anything. Ever. | 21:21 | |
| * xnox is running testsuite against the dump after "show-config & exit chroot" | 21:24 | |
| xnox | infinity: use --no-sessions for init (can be a kernel arg), but then you will not be able to start any daemons in your chroots (which might be advisable) | 21:25 |
| xnox | it "Disable chroot sessions." | 21:25 |
| infinity | xnox: Not starting daemons in my chroots is generally a feature. | 21:27 |
| infinity | xnox: --no-sessions passed directly to the kernel, you say? | 21:27 |
| xnox | infinity: yeah, that supposedly gets passed to init with our magic integration. Documentation: http://upstart.ubuntu.com/cookbook/#add-verbose-or-debug-to-the-kernel-command-line | 21:29 |
| * infinity adds that to /etc/default/grub and gives it a whirl. | 21:29 | |
| infinity | xnox: That worked a treat. <3 | 21:34 |
| xnox | infinity: your welcome =) | 21:35 |
| xnox | infinity: (null):session.c:513: Not reached assertion failed in session_from_index | 21:38 |
| xnox | \o/ | 21:38 |
| * xnox has a unit test. | 21:39 | |
| xnox | slangasek: smells like we do not tear down session completly when it's gone..... | 21:39 |
| xnox | infinity: cute, upstart still has all jobclasses in memory, even after you quit chroot session and thus goes berserk when it realises they are not there on re-exec /o\ | 21:42 |
| infinity | shadeslayer: Wouldn't it make sense to upload kde4libs before all the things that build-depend on it? :P | 21:54 |
| === sraue_ is now known as sraue | ||
| shadeslayer | infinity: true, but our automation script just prepares all the packages and uploads them, but yeah, you're right :) | 22:18 |
| shadeslayer | anyway, gtg, early flight tomorrow, night! :) | 22:20 |
| infinity | 'Night. | 22:20 |
| xnox | infinity: http://paste.ubuntu.com/5892302/ | 22:22 |
| infinity | xnox: Oops. | 22:23 |
| xnox | infinity: that also means, we have not yet ever statefully re-exec with a chroot session and has always been falling back to non-state-re-exec. | 22:23 |
| xnox | infinity: i'm gonna write a few more tests here, before doing merge proposal..... | 22:23 |
| infinity | xnox: Shiny. I no longer care, of course, because --no-sessions has made me happier than I've been in years. | 22:25 |
| infinity | xnox: But I imagine other users of ephemeral chroots (Colin, Andy, y'know, people we like) might be grumpy about their machines panicking. ;) | 22:25 |
| xnox | infinity: i wonder if pitti can be recruited to write upstart re-exec tests, afterall should be interesting for developer in test =) | 22:32 |
| xnox | infinity: at least i am adding tests for all the bugs we are catching with chroot re-execs here. | 22:32 |
| slangasek | xnox: re-exec is not expected to preserve any state for chroot sessions at this point. It *is* expected to not blow up init... | 22:45 |
| xnox | slangasek: by the looks of it, we never clean up chroot sessions, even after chroot path is deleted. | 22:46 |
| slangasek | so I hear | 22:47 |
| xnox | slangasek: and as I said, over when the first blow-up of init happened, that there shouldn't be any asserts on the deserialisation path, and instead they should bail out into stateless re-exec. But still be inspirit of "do not preserve chroot sessions, and try to statefully re-exec host init" | 22:48 |
| slangasek | yes, I agree | 22:49 |
| xnox | slangasek: also the function in question, had an obvious bug, and it doesn't seem to have a unit-test. http://paste.ubuntu.com/5892302/ | 22:50 |
| xnox | slangasek: infinity: i think we got lucky, cause both you and I had _2_ sessions, instead of just one =) | 22:52 |
| xnox | still doing full build, and full test here. | 22:53 |
| slangasek | xnox: ok, cheers | 22:53 |
| slangasek | mdeslaur: there's a libjpeg-turbo SRU sponsored by you in the queue, that has no bug references | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!