| dholbach | good morning | 06:55 |
|---|---|---|
| pitti | hey dholbach, how are you? | 06:57 |
| dholbach | hey pitti :) | 06:58 |
| === _salem is now known as salem_ | ||
| gema | dholbach: at what time do the tuesday lightning talks finish? | 13:10 |
| gema | dholbach: I haven't managed to find the agenda beyond summit | 13:11 |
| dholbach | it's in summit | 13:11 |
| dholbach | giving open week talk right now | 13:11 |
| dholbach | sorry | 13:11 |
| * gema goes back | 13:11 | |
| gema | dholbach: no worries, I will be here later | 13:11 |
| === dholbach_ is now known as dholbach | ||
| davmor2 | gema: http://summit.ubuntu.com/uds-r/2012-10-30/ | 13:42 |
| gema | davmor2: I was looking for the after 6pm activities | 13:42 |
| gema | davmor2: I am on the case already, I think there is some miscomunication , talking to msm and dholbach about it | 13:43 |
| === Ursinha-afk is now known as Ursinha | ||
| === yofel_ is now known as yofel | ||
| === alourie|work is now known as alourie_work | ||
| bdmurray | who could I speak to about jenkins dist upgrade testing and conffiles? | 18:33 |
| bdmurray | this to be specific - https://jenkins.qa.ubuntu.com/view/Quantal/view/Upgrade%20Testing%20Dashboard/job/quantal-upgrade-precise-desktop/ARCH=amd64,LTS=non-lts,PROFILE=desktop,label=upgrade-test/198/ | 18:34 |
| bdmurray | hggdh: do you know? ^ | 18:38 |
| hggdh | bdmurray: psivaa, or jibel would be the best bets. Good chance plars is also up-to-date | 18:39 |
| plars | bdmurray: yes, those fail every so often, some have had bugs submitted on them, tbh though not all have bugs submitted yet because it's a *lot* of failures in some cases, and at many times, are not well received. We need to talk about what a better solution to this might be | 18:41 |
| plars | clearly opening a single bug to cover all of them is wrong, but manually opening an individual bug for each one doesn't seem ideal either | 18:41 |
| bdmurray | plars: the conf file test would be more useful if we knew what the file looked like on disk | 18:42 |
| bdmurray | for example with release-upgrades we only have the version from the package release-upgrades.dpkg-ist | 18:42 |
| bdmurray | I'd like to know what /etc/update-manager/release-upgrades looks like on that system | 18:42 |
| bdmurray | also looking at apt-term.log from that specific test it doesn't look like the precise system is fully up to date as it has software-properties version 0.82.7.2 and 0.82.7.3 is current | 18:45 |
| bdmurray | plars: how can this be sorted out? | 18:46 |
| plars | bdmurray: is that always useful? my understanding of these files are basically things that are not in the new package any longer, and should have been moved to a different location, or removed entirely as part of the upgrade. Also, they may not always be text | 18:47 |
| plars | bdmurray: I'm sure the file could be saved it that's really useful, I'm just not sure I understand why it would be useful if the file is no longer in the new version | 18:48 |
| bdmurray | plars: in this particular instance we can see the following: | 18:49 |
| bdmurray | Configuration file `/etc/update-manager/release-upgrades' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. | 18:50 |
| plars | bdmurray: sorry, was on the phone and trying to look into this, from the one you pointed at it looks like python-ubuntuone-storageprotocol is the only thing that had obsolete conffiles, so I may have thought you were asking something else | 18:50 |
| bdmurray | so its the contents of the text file that changed | 18:50 |
| bdmurray | and the results I have are what the new text file looks like | 18:50 |
| bdmurray | which I could have found myself by looking at the package | 18:50 |
| plars | bdmurray: yes, the release-upgrades file is modified so that precise will upgrade to quantal by changing Prompt=lts to Prompt=normal | 18:50 |
| bdmurray | and Prompt=normal is what comes with ubuntu-release-upgrader in quantal | 18:51 |
| bdmurray | so there shouldn't have been a conffile prompt at all | 18:52 |
| bdmurray | but without seeing what release-upgrades is from that system its hard to tell... | 18:52 |
| plars | bdmurray: there's no complaint in the conffiles about the release-upgrades file | 18:52 |
| plars | bdmurray: take a look at https://jenkins.qa.ubuntu.com/view/Quantal/view/Upgrade%20Testing%20Dashboard/job/quantal-upgrade-precise-desktop/ARCH=amd64,LTS=non-lts,PROFILE=desktop,label=upgrade-test/198/artifact/results/obsolete_conffiles.log | 18:53 |
| plars | that's the only packages it found with obsolete conffiles | 18:53 |
| plars | the release-upgrades file *has* to be modified to do the upgrade, otherwise there's no upgrade to test | 18:53 |
| bdmurray | obsolete is not the same thing as modified | 18:53 |
| plars | and the release-upgrades file is not the source of the conffiles test failure | 18:53 |
| bdmurray | see the apt log at https://jenkins.qa.ubuntu.com/view/Quantal/view/Upgrade%20Testing%20Dashboard/job/quantal-upgrade-precise-desktop/ARCH=amd64,LTS=non-lts,PROFILE=desktop,label=upgrade-test/198/artifact/results/apt-term.log | 18:53 |
| plars | bdmurray: but release upgrades is not the obsolete conffile, /etc/ssl/certs/ValiCert_Class_2_VA.pem is | 18:54 |
| bdmurray | and look for Configuration file | 18:54 |
| plars | bdmurray: sure, that's fine - not a failure | 18:54 |
| plars | bdmurray: the only failure from the tests that were executed in this job was the obsolete conffiles test | 18:55 |
| bdmurray | okay, it might not make the test fail but it makes for a bad upgrade experience | 18:55 |
| plars | and that had nothing to do with the file you are referencing | 18:55 |
| plars | bdmurray: that's plausible, and to my understanding, expected if you hand modify a file so that you can force an upgrade from an lts release. I'm not sure if anyone has tried filing a bug for this, but my impression is that this is expected and normal | 18:56 |
| plars | and that hopefully you know you're going to get offered that suggestion since you hand-edited the file | 18:56 |
| plars | bdmurray: in the normal process of an upgrade to a new release, say q->r, it would not be necessary to modify that to get the upgrade to happen, and there should be no warning from dpkg | 18:57 |
| bdmurray | I've done many a dist-ugprade, from P to Q, after having modified release-upgrades and have never gotten a conffile prompt. So I'm curious what is going in these tests. | 18:57 |
| bdmurray | maybe there is extra white space in the Prompt line? | 18:58 |
| plars | bdmurray: you're right, that one should fall below the threshold and not get actually prompted. Are you sure it doesn't show up in the log anyway though? | 19:00 |
| plars | bdmurray: looking at the autoupgrade code, what's basically getting run in this test is DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade | 19:02 |
| plars | bdmurray: to be clear though, this is not the failure in the conffiles test that is referenced in that job | 19:02 |
| bdmurray | plars: okay, I understand that. why are the .dpkg-dist files included though? if they are useful for something it should include the conffile on disk | 19:03 |
| plars | bdmurray: looking | 19:06 |
| bdmurray | thanks | 19:07 |
| plars | bdmurray: those are normally picked up and reported as possibly unexpected, but the release-upgrades one is specifically whitelisted from the report. At some point those are all getting attached to the job for debugging even if it's whitelisted. I'm not sure where off the top of my head, would need to dig a bit more | 19:07 |
| plars | bdmurray: in this case though, it's specifically not reported as a failure because we expect it on this file, same for sudoers | 19:07 |
| plars | bdmurray: I see where actually, I can fix it up. The cp is done before the whitelist is evaluated | 19:09 |
| bdmurray | I don't think it should be expected on the release-upgrades file | 19:10 |
| plars | bdmurray: yes, it's expected because we manually modify the file | 19:11 |
| bdmurray | but if you are manually modifying it to what the new release has then there won't be a conflict | 19:14 |
| plars | bdmurray: in this case, it has been modified to what the new one should have, but I suspect it detects that the file has been modified, regardless of whether that's identical to what would be in the upgraded file. I don't know the guts of how the upgrade detects modified files though | 19:18 |
| plars | and in the case of an upgrade *to* a lts release, the file would certainly not match what the new file would have in it | 19:18 |
| bdmurray | well that's true from non-lts to lts it would generate a modified conf file prompt | 19:20 |
| plars | bdmurray: I agree, I think it would be nice if it actually checked to see if the modified file was a zero-diff against what it would change to, but I don't think that's how it works (I don't know the details though) | 19:31 |
| bdmurray | plars: so what will happen with white listed things? will they no longer appear as artifacts? | 19:44 |
| plars | bdmurray: I need to talk to others, theres no real harm in having those 2 (the only whitelisted files) show up as artifacts as they are not big. As it stands, they are not reported as failures due to the whitelisting. I could have it go remove the whitelisted files from the directory where artifacts are picked up | 19:45 |
| plars | bdmurray: currently, it's basically just looking for all the .dpkg-dist files on the system and copying them across, then once it has them, it checks to see if there are any besides those two and reports them as a possible problem | 19:45 |
| plars | it could be that sometimes it's useful to have them there just in case, but I don't think they've every been terribly useful | 19:46 |
| bdmurray | if you are going to report them as a possible problem it would be less confusing if the white list were published somewhere or the conffile from the system were included | 19:46 |
| plars | bdmurray: the whitelist is in the code itself, and corresponds to the files that are modified by the test | 19:47 |
| plars | bdmurray: but those are *not* reported as a possible problem | 19:47 |
| bdmurray | plars: where is the link to the code? | 19:47 |
| plars | bdmurray: https://code.launchpad.net/auto-upgrade-testing | 19:48 |
| bdmurray | plars: it might be helpful to include that on the results page | 19:49 |
| plars | bdmurray: it can be found by looking at the log, showing where it pulled code from to run. But I get what you're saying. jenkins is pretty raw currently and leaves it to the person reviewing the results to just know and understand a lot of things rather than making it really clear what the failure is | 19:51 |
| plars | and I think that's something that could stand improvement | 19:51 |
| === salem_ is now known as _salem | ||
| Noskcaj | phillw, wxl: is the netboot testcase ready for upload? | 20:46 |
| phillw | Noskcaj: as far as i know, we're waiting on wxl to get a new power unit for his test machine. | 22:02 |
| phillw | Noskcaj: the testcase is 'uploaded', it just needs to be copied over for when the Daily Respins start... which should be shortly after UDS. | 22:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!