| robru | veebers: force is fine. Or if you just want to rebuild one you can specify which one. | 00:25 |
|---|---|---|
| veebers | robru: coolio, thanks | 01:10 |
| robru | veebers: you're welcome | 01:18 |
| robru | kgunn: "invalid package" means your silo isn't configured to include that package in the sync. | 01:18 |
| kgunn | robru: i'm not familiar with syncing like that, do you guys do that upload of the src pkg? or how does it work ? | 01:19 |
| robru | kgunn: what request is it? | 01:19 |
| kgunn | robru: sorry, silo 54 alberta's sync of mir to vivid+o | 01:20 |
| robru | kgunn: well for starters this request is totally wrong in every possible way | 01:20 |
| kgunn | lol | 01:20 |
| kgunn | good to know | 01:20 |
| robru | kgunn: you can't mix MPs and syncs. those are different things | 01:20 |
| kgunn | robru: what's your recommendation in this instance ? | 01:21 |
| robru | kgunn: the sync syntax changed a bit but "sync:mir" isn't valid the new way or the old way, that's totally out to lunch. | 01:21 |
| robru | kgunn: what are you trying to do? | 01:21 |
| kgunn | so here's what we got | 01:21 |
| kgunn | mir, usc, qtmir are all in wily properly...and i think we just want to promote all those into vivid+o | 01:21 |
| robru | kgunn: so you just want to copy those three packages from wily to vivid+o without any changes at all? | 01:22 |
| kgunn | robru: correct, rebuilt of course.... | 01:22 |
| kgunn | for gcc considerations | 01:22 |
| robru | kgunn: right | 01:23 |
| kgunn | robru: and actually...i think usc and qtmir can simply be rebuilt | 01:23 |
| robru | kgunn: ok, those MPs are empty. I'm not sure where he got the idea to do that. | 01:23 |
| kgunn | i don't think they differ | 01:23 |
| kgunn | right | 01:23 |
| kgunn | he was flying unguided i think | 01:23 |
| robru | kgunn: empty MPs are only needed if you're doing a no change release of trunk (eg if you landed changes in trunk without using the train). not for syncs. | 01:23 |
| robru | kgunn: ok so here's what you do. empty out the merges field. put the source names you want in the sources field (WITHOUT the 'sync:' bit) | 01:24 |
| robru | kgunn: the rest of the fields look good | 01:24 |
| robru | kgunn: then click assign to configure the silo, then click build and it'll do a source copy that rebuilds against the appropriate gcc | 01:25 |
| kgunn | robru: and if i am syncing like this, even tho there's no diff for qtmir/usc....do i still list those as pkgs in the "manual src" block ? | 01:25 |
| kgunn | which will in effect rebuild them | 01:25 |
| kgunn | ? | 01:25 |
| robru | kgunn: yes, if you don't include them in the sources field then the train won't know what packages to copy in the sync. | 01:26 |
| kgunn | robru: oh and for qtmir-gles...it's kinda weird | 01:26 |
| kgunn | does it autoknow ? | 01:26 |
| robru | kgunn: it auto knows that what you put in the sources field are the names of the packages it's going to sync for you. | 01:27 |
| kgunn | robru: right but as i recall qtmir-gles links to the pkg biuld version from qtmir....which is why we always built it last, unless someone automated that | 01:27 |
| kgunn | e.g. i guess i may need a ppa for qtmir-gles | 01:28 |
| robru | kgunn: ok, you might need an MP for the -gles that updates the debian/watch | 01:28 |
| kgunn | i'll at least get mir/usc/qtmir built...and i can sort the qtmir-gles in the morning | 01:28 |
| robru | kgunn: it's worth trying. I'm not sure off the top of my head how sync code will handle a -gles package. if the PPA accepts the orig.tar it should be fine, if it uses debian/watch it'll get confused. unless you get lucky and get the same silo, lol ;-) | 01:29 |
| kgunn | thanks for the help tho | 01:30 |
| robru | kgunn: you're welcome | 01:30 |
| robru | kgunn: but you can't have any MPs in the silo config, you have to remove the -gles one too | 01:30 |
| robru | kgunn: syncs and MPs are totally incompatible within the same silo | 01:31 |
| robru | kgunn: if -gles doesn't work as a sync you'll have to do it in a separate silo later. | 01:31 |
| robru | kgunn: and you should file a bug about that, that should be supported by the train. in fact the train could go so far as to automatically set debian/watch for you each time so you don't have to worry about it. | 01:32 |
| kgunn | oh...i would like that very much | 01:32 |
| robru | kgunn: file the bug against lp:cupstream2distro | 01:32 |
| robru | shouldn't even be hard, but I have some other priorities first. | 01:32 |
| kgunn | robru: fwiw...i just read scrollback...i left the gles mp in there, and the sync seemed to work ? | 01:33 |
| kgunn | or did i just do something undefined | 01:33 |
| robru | kgunn: it might be working since you specified which packages to build in a way that excluded the -gles mp but generally the behavior of MPs and syncs together in a silo is undefined, I'm not sure what'll happen when you try to build the MP | 01:34 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| robru | who is doing QA at this hour? | 04:45 |
| robru | oh, veebers, it's you | 04:45 |
| robru | you want i should publish that? | 04:45 |
| veebers | robru: heh :-) yes please | 04:46 |
| veebers | robru: speaking of 'at this hour' are you ever offline? ;-) | 04:46 |
| robru | veebers: I usually sleep between 4AM and 4:15AM. | 04:47 |
| veebers | robru: lol ^_^ | 04:47 |
| robru | veebers: just kidding, I usually sleep in actually, but it's only 10pm here! | 04:47 |
| robru | veebers: oooh, look at Mr Fancy Pants fixing his build by ignoring errors! | 04:48 |
| === chihchun_afk is now known as chihchun | ||
| veebers | robru: hah, that's due to new flake8/pep8 rules coming along which I disagree with, but perhaps I will come around to liking them and remove those ignores | 04:59 |
| robru | veebers: heh, yeah, I think dobey got hit by something similar as well, I'm not sure what the new errors are personally | 05:00 |
| alf_ | chihelp: Hi! We have been consistently getting failures in job 'mir-android-vivid-i386-build' for the last day or so: " libboost-all-dev : Depends: libboost-python-dev but it is not going to be installed" | 07:07 |
| alf_ | cihelp: Hi! We have been consistently getting failures in job 'mir-android-vivid-i386-build' for the last day or so: " libboost-all-dev : Depends: libboost-python-dev but it is not going to be installed" | 07:07 |
| alf_ | cihelp: Any idea how we can fix this? It's blocking all mir CI jobs | 07:08 |
| Mirv | bfiller: renatu charles: I got permission to publish 024, but you will need to fix bug #1491255 for the next release, to track API | 07:15 |
| ubot5 | bug 1491255 in indicator-transfer (Ubuntu) "Add .symbols file for tracking API" [High,New] https://launchpad.net/bugs/1491255 | 07:15 |
| Mirv | ogra_: could you merge + publish both https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.wily_remove_friends/+merge/267648 and https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.wily_add_indicator-transfer-download-manager/+merge/269846 (latter needs approval, but it's related to this 024 landing now, adding a plugin package) | 07:16 |
| Mirv | I can upload the vivid overlay meta package change | 07:16 |
| morphis | Mirv: thanks for publishing silo 9 | 07:18 |
| morphis | Mirv: when I setup a sync silo to get something from wily, does it fetch that from the proposed pocket too? | 07:23 |
| Mirv | morphis: no problem. yes I'd say it'd fetch from proposed pocket too, but remains to be seen :) | 07:24 |
| morphis | ok | 07:24 |
| morphis | lets try it | 07:24 |
| Mirv | dbarth__: hi, repeating from yesterday, did you see robert's comments on 052 silo about it being a dual silo but configured for wily for some reason? it's QA granted, so if you want I can reconfigure it as dual again and publish, but we just want to understand why it's marked as 'wily' at the moment. | 07:26 |
| Mirv | bregma: did you see sil2100's comment in bileto last week about additional changes needed to silo 027 / Libertine before it can be published? a symbol file would be best added (the archive admins will want it), and an arch:all correction. | 07:28 |
| morphis | Mirv: seems that this doesn't work: 0.229 does not seem to be a CI Train generated version number, series version change is not supported for non-train uploads. | 07:32 |
| morphis | I remember ... non train upload can't be changed in their release version ... | 07:33 |
| morphis | lets do this different then | 07:33 |
| === zbenjamin_ is now known as zbenjamin | ||
| Mirv | morphis: ah right again, we need to just continue doing manual uploads | 07:34 |
| Mirv | zbenjamin: would you have time today to verify the silo 025 / QtC so that I could publish it? | 07:34 |
| morphis | would be the best if we change lxc-android-config to be citrain based finally ... | 07:34 |
| Mirv | morphis: well that would be something, yes | 07:35 |
| zbenjamin | Mirv: meh i totally forgot about that... multitasking pretty heavily atm :D | 07:35 |
| === chihchun is now known as chihchun_afk | ||
| Mirv | zbenjamin: I know the feeling, no problem :) | 07:36 |
| bzoltan_ | Mirv: who to quick ask to double the size of this PPA? https://launchpad.net/~ubuntu-sdk-team/+archive/ubuntu/tools-development | 07:43 |
| morphis | Mirv: any idea what I have to change for that? never did that before | 07:44 |
| Mirv | bzoltan_: file an internal RT ticket and refer to that on webops channel | 07:44 |
| bzoltan_ | Mirv: OMG .. .really? Still? | 07:44 |
| bzoltan_ | Mirv: I need it in a minute... | 07:45 |
| Mirv | bzoltan_: well that's my guess, they probably get some karma for closing tickets | 07:45 |
| Mirv | morphis: take .bzr-builddeb from eg http://bazaar.launchpad.net/~phablet-team/camera-app/trunk/files - that's probably about it. for the first release, add a manual new changelog entry in your MP with UNRELEASED as status. with those the train might be able to build it. | 07:46 |
| Mirv | morphis: oh right, we need project :D | 07:46 |
| morphis | right | 07:47 |
| Mirv | just a moment | 07:47 |
| Mirv | bzoltan_: well ask the vanguard on webops directly then | 07:47 |
| morphis | Mirv: let me check with ogra_ too | 07:47 |
| morphis | ogra_: is there anything which prevents us from switching lxc-android-config to be citrain based? | 07:47 |
| Mirv | yeah, that should be useful | 07:48 |
| ogra_ | morphis, except of my lazyness to do the fiddling for it there never was one :) | 07:48 |
| Mirv | ogra_: ok, me and morphis can fiddle it then :) | 07:49 |
| ogra_ | :D | 07:49 |
| morphis | ogra_: great! | 07:51 |
| Mirv | morphis: ok you can now push branches against lp:lxc-android-config | 07:51 |
| morphis | Mirv: so is that fine even if we have a version gap between vivid-overlay and wily atm? | 07:51 |
| Mirv | starting with eg the addition of .bzr-builddeb and a new changelog entry, and that can then be tried to be built | 07:51 |
| Mirv | morphis: we could do a vivid branch for overlay | 07:52 |
| morphis | ok | 07:52 |
| Mirv | well, I can do that now too | 07:52 |
| morphis | hm | 07:52 |
| morphis | I would try to prevent us from doing that | 07:52 |
| morphis | just takes more time to merge things etc. | 07:52 |
| morphis | there is one change in wily I need to double check if that causes regressions on vivid | 07:53 |
| Mirv | morphis: well sure, if you think we can land to trunk to overlay, that's always the best | 07:53 |
| === chihchun_afk is now known as chihchun | ||
| psivaa | alf_: do you have the link for the job? | 08:08 |
| alf_ | psivaa: https://jenkins.qa.ubuntu.com/job/mir-android-vivid-i386-build/ | 08:23 |
| psivaa | alf_: ack, thanks. I'm in the middle of debugging something else. will take a look at this in a bit | 08:25 |
| alf_ | psivaa: Great thanks | 08:26 |
| morphis | Mirv: but looks good | 08:32 |
| robru | alf_: generally depending on boost-all-dev is frowned upon, you might be able to make some progress by selecting the individual boost packages you really need. | 08:33 |
| robru | alf_: but other than that i dunno | 08:34 |
| morphis | Mirv: there we go: https://code.launchpad.net/~morphis/lxc-android-config/add-citrain-support/+merge/269859 | 08:37 |
| robru | Mirv: I'm surprised to see 52 in the NEW queue, i thought there was a bug that made publishes skip that | 08:37 |
| mandel | robru, might be very late, but does the ci bot use wily, is it using gcc 5? I'm getting diff symbols in my wily machine than in the bot :-/ | 08:38 |
| robru | mandel: the train uses a pbuilder that matches the series is building for. So you get gcc5 in wily and 4.9 in vivid | 08:39 |
| mandel | robru, hm.. I wonder what is going on :-/ | 08:39 |
| robru | mandel: not sure, I'm not a symbols expert | 08:39 |
| robru | morphis: did you check your packaging against https://wiki.ubuntu.com/DailyRelease/InlinePackaging ? | 08:40 |
| morphis | robru: no | 08:40 |
| mandel | robru, don't worry, at least I'm 100% sure that it is not the bot, that is enough info | 08:41 |
| robru | morphis: those are the official train packaging guidelines, you should probably look it over. Review looks good for what's there but there might be other things missing | 08:41 |
| morphis | robru: it looks so | 08:41 |
| morphis | atleast the build failed | 08:42 |
| robru | abeato: you can't release a wily trunk to vivid, either do a dual silo or branch for vivid | 08:46 |
| robru | morphis: not sure about that error there, can't find the orig.tar... It might be because your trying to change the version from native to nonnative... Try pushing those changes to trunk and then putting a null mp in the silo. | 08:48 |
| abeato | robru, I was trying to see if I could create 2 MPs from one branch, with one MP targeting vivid and the other wily | 08:48 |
| abeato | robru, but does not seem possible | 08:49 |
| Mirv | morphis: ah, you found the wiki page thanks to robert too! | 08:49 |
| morphis | yeah | 08:49 |
| robru | abeato: no, that's a horrible idea. What would happen when they merge to trunk? You'd have conflicting changelogs | 08:49 |
| Mirv | robru: my latest info is that source NEW:s go to the queue (and that's why we don't need to ask preNEW-review for them), while binary new:s are skipped so we need to manually ask for the reviews | 08:49 |
| robru | abeato: if you want to release to both from one trunk you need to do a dual silo | 08:49 |
| morphis | robru: I just changed the packaging bits, but if I understand you right we have to merge my MP now first before going ahead, right? | 08:50 |
| abeato | robru, my idea is that CI train might be able to handle that | 08:50 |
| robru | abeato: is there a reason that you can't use a dual silo? | 08:50 |
| abeato | robru, well after the gcc5 switch we have many projects branched | 08:50 |
| abeato | so I was experimenting a bit | 08:50 |
| Mirv | morphis: I think there's a possibility that train doesn't support native packages anymore, meaning that you need "0.230-0ubuntu1" version number instead | 08:50 |
| morphis | let me try that | 08:51 |
| Mirv | native packages did work at one point but it was more of a bug probably | 08:51 |
| Mirv | and now that lxc-android-config has an upstream project, it's not native anymore to Ubuntu :) | 08:51 |
| Mirv | "kind of" | 08:51 |
| robru | abeato: there is a way to do it from one trunk and keep using dual silo, but it takes a bunch of packaging voodoo. Talk to michi about it he has a proof of concept that works | 08:53 |
| robru | I should get some documentation together for that... | 08:53 |
| === Mirv changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? ping cihelp | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: OTA-6 final freeze in effect, but the vivid-overlay landing gates opened. sil2100 away, small trainguard gap between EEST & RDT (robru daylight saving time) timezones | ||
| abeato | robru, I had actually noticed that there is a silo from him that generates the dependencies dynamically apparently | 08:54 |
| abeato | robru, it would be great if michi or somebody shares that in the mailing list :) | 08:54 |
| robru | Mirv: lol | 08:54 |
| robru | abeato: it's 2 AM for me, I'm afk can't get the details. But michi has a good example if you just read what he did. You can make an override_dh_auto_build that generates the correct debian/control with correct values per distro | 08:56 |
| abeato | robru, thanks, and take some rest | 08:57 |
| robru | abeato: i mean override_dh_auto_clean, grep his source for that and you can see how it works | 08:57 |
| abeato | great | 08:58 |
| robru | abeato: can't sleep, clowns'll eat me | 08:58 |
| abeato | :D | 08:58 |
| morphis | Mirv, robru: just adding -0ubuntu1 doesn't seem to be enough | 08:59 |
| morphis | still asking for the tarball | 08:59 |
| morphis | ah I see | 09:01 |
| morphis | used - instead of + | 09:01 |
| robru | morphis: that is really strange, the whole point of split mode is that it makes thr tarball by dropping the debian dir. Double check you have it set right? I don't see anything obviously wrong... | 09:01 |
| Mirv | morphis: - should be good, I'm testing something on my own | 09:01 |
| Mirv | I don't see anything wrong anymore either | 09:01 |
| morphis | if I used + with a local bzr bd run it doesn't ask anymore for the tarball | 09:02 |
| morphis | and the info "This package has a Debian revision number but there does not seem to be..." goes away | 09:02 |
| robru | Hm | 09:02 |
| morphis | citrain correctly notes: "dch warning: Previous package version was Debian native whilst new version is not" | 09:03 |
| Mirv | I wonder what I managed to do when I get build success without it trying to merge the MP in the first place :D https://ci-train.ubuntu.com/job/ubuntu-landing-002-1-build/213/console | 09:05 |
| Mirv | I was just experimenting based on morphis' branch https://code.launchpad.net/~timo-jyrinki/lxc-android-config/randomtest/+merge/269866 | 09:06 |
| Mirv | morphis: I don't know what's going on in my test silo, but I was trying to add a fake non-native entry plus use a date code (which includes + in upstream version and the - for being a non-native package) | 09:07 |
| robru | Mirv: silo 2 is a manual source...? Force rebuild means it watches the ppa twice as hard i guess. | 09:07 |
| Mirv | morphis: ah, now I notice. delete the debian/bzr-builddeb.conf | 09:08 |
| Mirv | robru: it is not, that's the fun of it. https://requests.ci-train.ubuntu.com/#/ticket/298 | 09:08 |
| Mirv | morphis: and don't change the rest of it, that'll probably fix it | 09:08 |
| robru | morphis: uh "+0ubuntu1" is not a thing that makes sense, if that works it's only by accident. You should try to ape a real version with the date stamp and the train will run with it | 09:08 |
| Mirv | morphis: just keep the 0.230-0ubuntu1 and bzr rm debian/bzr-builddeb.conf | 09:09 |
| robru | Mirv: the console log you linked was silo 2 not 24. | 09:09 |
| morphis | Mirv, robru: done, let me try this now | 09:10 |
| Mirv | robru: wow, quite a coincidence that I actually run a build job for a wrong silo that has the same package :D | 09:10 |
| mzanetti | robru, hey, a small bug report for bileto: when there's a merge conflict in a branch, it prints that with a link to the branch, but the link includes a dot at the end which breaks it | 09:13 |
| robru | morphis: well that looks good, both uploads accepted | 09:14 |
| morphis | yeah! | 09:14 |
| mzanetti | robru, here's an example: https://requests.ci-train.ubuntu.com/#/ticket/285 | 09:14 |
| robru | mzanetti: oh haha. Can you email me with a link to the log that has that? I'll fix it during my shift tomorrow | 09:14 |
| mzanetti | robru, ack | 09:15 |
| === greyback__ is now known as greyback | ||
| mandel | robru, so, this mr https://code.launchpad.net/~mandel/ubuntu-download-manager/wily-add-appid-metadata/+merge/269364 is building on vivid, yet is aiming for wily.. at lets so it says here => https://jenkins.qa.ubuntu.com/job/ubuntu-download-manager-vivid-armhf-ci/28/console | 09:45 |
| mandel | robru, any idea? | 09:46 |
| robru | mandel: yeah that's not the train you looked to there, nothing to do with me | 09:47 |
| Mirv | mandel: it's 2.45am for hi.. okay, he's there | 09:47 |
| mandel | robru, sorry sorry! | 09:48 |
| mandel | Mirv, do you know anything about that? The ci bot using the wrong release.. :-/ | 09:48 |
| robru | Mirv: for some reason at 11 pm i put on a 4 hour YouTube video thinking that was a good idea | 09:48 |
| Mirv | mandel: try highlighting cihelp for that ^ | 09:48 |
| Mirv | robru: sounds wise | 09:48 |
| psivaa | mandel: i'll take a look at this. i'd need some time. digging some other issues at the moment. but i'll make a record of your issue and come back to you | 09:51 |
| mandel | psivaa, ok, is not a show stopper, I'll add a comment in the MR | 09:52 |
| mandel | psivaa, moving to gcc 5 has this problems | 09:52 |
| === alan_g is now known as alan_g|llunch | ||
| === chihchun is now known as chihchun_afk | ||
| cjwatson | Mirv,bzoltan_: for future reference, the place to ask for PPA changes is https://answers.launchpad.net/launchpad, preferably not RT or webops | 10:02 |
| cjwatson | webops can do it of course but we prefer to distribute load away from them where possible | 10:03 |
| kgunn | trainguards so in silo 54, i was doing a src sync from wily to vivid+o, mir and u-s-c built fine, but qtmir just seems to wait and time out | 10:11 |
| kgunn | is something with a twin not capable of being sync'd at all ? | 10:11 |
| robru | kgunn: I'm not aware of any limitations on the non-gles one being synced. Should be the same... | 10:12 |
| kgunn | robru: dude...you're up too :) | 10:13 |
| robru | kgunn: i need help | 10:13 |
| kgunn | robru: so you were helping me last night....and qtmir is the only pkg refusing to build | 10:14 |
| kgunn | as i watched the output file, it just spins saying "qtmir...waiting" | 10:14 |
| kgunn | or no "watching" | 10:14 |
| bzoltan_ | cjwatson: OK | 10:15 |
| robru | kgunn: the fact that it's trying to upload "0ubuntu2" is quite suspect, can you confirm you didn't already sync this version? 0ubuntu1 is either already in the PPA or the archive | 10:17 |
| kgunn | robru: ah...i just found out....someone did something naughty | 10:18 |
| kgunn | vivid+o is ahead of wily | 10:18 |
| robru | Ooh good | 10:18 |
| kgunn | so i just need to land qtmir latest in wily and rebuild....i think | 10:18 |
| kgunn | crap | 10:18 |
| kgunn | this is gonna be a mess | 10:18 |
| kgunn | cause then i think unity-api is involved somehow | 10:18 |
| robru | kgunn: not sure, sorry. | 10:19 |
| kgunn | robru: ok, my teams mess thos | 10:20 |
| kgunn | sorry to bother | 10:20 |
| robru | kgunn: no worries | 10:20 |
| robru | kgunn: the train now supports a way to have dual landings even for packages affected by gcc5 abi but it's a little experimental, you should coordinate with michi, he has a working proof of concept. | 10:22 |
| kgunn | robru: thanks | 10:22 |
| robru | kgunn: it's a little bit voodoo but a nice dual landing would clean up your mess ;-) | 10:22 |
| Mirv | it seems it doesn't hurt I'm having this very late lunch since you two are a fit for each other regarding working hours :) | 10:23 |
| robru | Mirv: send help... I need sleep therapy | 10:24 |
| Mirv | yeah you both do | 10:24 |
| Mirv | this google result seems to be on the topic, but I'm not sure if it's sane https://www.reddit.com/comments/meaq9/the_real_quick_fix_to_get_your_fucked_up_sleep/ | 10:25 |
| abeato | Mirv, how can I abandon a silo? I don't see the option anymore | 10:25 |
| Mirv | abeato: if you have a silo assigned, ask a trainguard to free that up, it also makes the request abandoned | 10:26 |
| robru | abeato: Mirv ONLY_FREE_SILO. | 10:26 |
| robru | Mirv: landers can free their own | 10:27 |
| Mirv | robru: oh! | 10:27 |
| abeato | Mirv, ok please free silo 16 then | 10:27 |
| Mirv | abeato: so, click the Merge & Clean and select ONLY_FREE_SILO | 10:28 |
| Mirv | abeato: new instructions, do not ping but free it up yourself :) | 10:28 |
| abeato | ah, ok | 10:28 |
| abeato | hehe | 10:28 |
| abeato | nice | 10:28 |
| robru | Mirv: i thought you knew, this isn't something that changed recently, landers could always free their own | 10:28 |
| Mirv | the train is really good nowadays, all the features coming together | 10:28 |
| Mirv | robru: I simply didn't know.. | 10:29 |
| robru | Mirv: maybe skim the landingprocess page, i overhauled it last week | 10:30 |
| * Mirv opens https://wiki.ubuntu.com/citrain/LandingProcess | 10:30 | |
| robru | Mirv: there was a hilarious part that used to say "ci airline will be ready ~july 2014" so that was in need of updating ;-) | 10:32 |
| Mirv | robru: any day now! | 10:33 |
| robru | Mirv: OK I'm fading... Goodnight! | 10:37 |
| Mirv | robru: goodnight! | 10:40 |
| === chihchun_afk is now known as chihchun | ||
| === alan_g|llunch is now known as alan_g | ||
| bzoltan_ | cjwatson: how those requests are picked up? | 11:55 |
| cjwatson | bzoltan_: mailed to answer contacts for Launchpad, which includes Launchpad staff | 11:56 |
| bzoltan_ | cjwatson: OK, so eventually somebody will pick up. I managed to fill up the PPA :( I somehow feel that PPAs are not designed to host such content... | 11:58 |
| cjwatson | bzoltan_: how do you mean eventually? you have no pending requests | 11:59 |
| cjwatson | oh, six minutes ago | 11:59 |
| bzoltan_ | cjwatson: just got two uploads rejected | 11:59 |
| cjwatson | bzoltan_: would you mind adding me temporarily to ~ubuntu-sdk-team? then I can make this change (and leave the team immediately afterwards) without having to wait for William to be around | 12:00 |
| cjwatson | I should get round to getting commercial admin privileges for myself :) | 12:01 |
| bzoltan_ | cjwatson: welcome to the team :) i will show you later our backlogs... | 12:02 |
| cjwatson | bzoltan_: ok, sorted (and left :-) ) | 12:03 |
| bzoltan_ | cjwatson: so quickly? I was already looking for a suitable task :D | 12:03 |
| bzoltan_ | cjwatson: Thank you | 12:04 |
| cjwatson | I suspect the LP bug queue is longer than yours, just because it's been around for longer :-) | 12:04 |
| bzoltan_ | cjwatson: Yeps... I admit, we have a decent bug queue... but you know, I think like with kids It is already big enough for being left out without our control. | 12:07 |
| oSoMoN | ubuntu-qa: all webbrowser-app generic-deb-autopilot-runner-vivid-mako CI jobs are failing, they apparently fail to flash the device, is that a known issue?' | 13:05 |
| oSoMoN | (see e.g. https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/3242/console) | 13:06 |
| alesage | oSoMoN, maybe plars knows ^^ | 13:17 |
| === chihchun is now known as chihchun_afk | ||
| mandel | trainguard so, I have a very very interesting question, anyone wants to hear my idea? | 13:42 |
| renatu | Mirv, thanks, for landing silo 24. About the bug #1491255, how do you suggest us to maintain that since the symbols could be different in wily and vivid | 13:43 |
| ubot5 | bug 1491255 in indicator-transfer (Ubuntu) "Add .symbols file for tracking API" [High,New] https://launchpad.net/bugs/1491255 | 13:43 |
| renatu | Mirv, until now we are using the same branch (trunk) for both | 13:43 |
| renatu | Mirv, creating new branches just because of the symbols files does not look good | 13:43 |
| renatu | Mirv, mandel is having this problem right now with download-manager API, | 13:46 |
| mandel | renatu, Mirv so, as I mentioned, my idea is to have packging branches per distro and just keep the symbol issues there | 13:47 |
| mandel | renatu, Mirv and keep the same source in trunk. Then when we create a silo we provide the mr for trun and the mr for the pacaking | 13:48 |
| Mirv | renatu: mandel: right, and it was mentioned michi has a solution for differing symbols too (maybe similar) | 13:54 |
| mandel | Mirv, would be nice to have a hang out, brain storm and get this fix asap | 13:55 |
| mandel | Mirv, I hate to have to do crazy backport branches just for the symbols, and yes, is no ones fault except for cpp | 13:55 |
| michi | mandel, Mirv: have a look at the gen-debian-files script and the rules file in the debian directory in silo 10. | 13:56 |
| michi | That’s pretty much all you need. | 13:56 |
| michi | It’s just the usual substition grind with sed and what not. | 13:56 |
| Mirv | mandel: michi: I haven't done this myself yet, but thanks to michi I've added now https://wiki.ubuntu.com/citrain/LandingProcess#Dual-landing_and_handling_symbols | 14:02 |
| Mirv | renatu: ^ | 14:02 |
| michi | Mirv: reading... | 14:02 |
| Mirv | I think some more documentation on the usage might be handy :) | 14:03 |
| michi | Mirv: The trick with the symbols file is to have only one of them. | 14:03 |
| michi | Either wily or vivid, it doesn’t matter. | 14:03 |
| michi | But don’t try to do a symbols file for both, you’ll go mad that way. | 14:03 |
| michi | Basically, if a symbols file on vivid passes, and the same code is compiled for both vivid and wily, there is no point in having a symbols file for wily too. | 14:04 |
| michi | That’s because, if a vivid symbols file is good, the only differences in the wily symbols file will be due to compiler differences. | 14:04 |
| michi | Different symbol mangling with the new ABI, and differences in inlining. | 14:04 |
| michi | So, adding a symbols file for wily too won’t show anything that a vivid build won’t show. | 14:04 |
| michi | Longer term, the goal is to get rid of symbols files completely because they are the wrong tool for the job. | 14:05 |
| michi | The catch some ABI breaks, but only some. | 14:05 |
| michi | Even in C, there are many ways to break ABI that won’t show up in the symbols file. | 14:06 |
| michi | In C++, there are many more | 14:06 |
| mandel | michi, well, I was told that QA wants them for OTA7 | 14:06 |
| michi | abi-compliance-checker is the way to go for C++ and, if we are honest about it, for C as well. | 14:06 |
| michi | QA needs to learn that symbols files don’t do what they are meant to do. | 14:06 |
| michi | It’s an education campaign. | 14:06 |
| michi | If a symbols file doesn’t pass, that means the ABI is broken. | 14:07 |
| mandel | michi, if we ditch them, we should tell QA, get a company rule and deal with it without symbol files | 14:07 |
| michi | That, by not means, implies that, if a symbols file passes, that the ABI is not broken. | 14:07 |
| michi | abi-compliance-checker. | 14:07 |
| michi | Catches everything a symbols file with catch, plus dozens more cases that a symbols file won’t catch. | 14:07 |
| michi | It’s a far better way to establish whether the ABI is still intact. | 14:08 |
| mandel | michi, I;m also a little worried about upstream projects, in ours we can drop them and then add abi-compliece-checker | 14:08 |
| michi | The problem with acc is that it’s cumbersome to use and difficult to integrate into our CI story | 14:08 |
| mandel | michi, for me, as long as we do not have to mantain two files etc.. I'm ok | 14:08 |
| michi | I’m working on making it more bearable. | 14:08 |
| michi | For now, if you have a symbols file for either wily or vivid, that’s cool. | 14:08 |
| michi | Just don’t try and add a second one. | 14:09 |
| michi | It won’t show you anything new. | 14:09 |
| michi | Maintaining the bloody symbols file has been the bane of our lives for the past two years. | 14:09 |
| michi | There are an unbelievably stupid number of ways in which that can break, with no ABI in danger whatsoever. | 14:10 |
| michi | That’s for C++. | 14:10 |
| michi | For C, it’s not as bad. | 14:10 |
| michi | Check out silo 10, it’l give you the general gist of things. | 14:11 |
| michi | debian/rules and all the .install files are generated on the fly. | 14:11 |
| mandel | michi, so, abi-change-checker, I'm never heard about it, is it new, did we build that? | 14:11 |
| mandel | michi, I'd like to know how it works | 14:11 |
| michi | For scopes-api, it’s more complex than it will be for most projects because we changed the way we name our soversion recently. | 14:11 |
| michi | abi-compliance-checker | 14:11 |
| michi | It’s in the archives. | 14:12 |
| renatu | michi, what I understood is that the symbol files will be mandatory now | 14:12 |
| michi | perl script that reads the symbol table and the headers and does a fairly deep inspection of the ABI *at the source code level*. | 14:12 |
| michi | renatu: the symbols files are useless (mostly) to establish that the ABI is still intact. | 14:12 |
| michi | They don’t do what they are meant to do. | 14:12 |
| michi | Sticking to a policy such as this is not productive. | 14:13 |
| michi | Symbols files catch *some* ABI issues, but nowhere near enough of them to matter. | 14:13 |
| renatu | but the QA team are asking us to create it on the projects to accept our MR | 14:13 |
| michi | They are simply the wrong mechanism to establish ABI compliance. | 14:13 |
| Mirv | michi: renatu: mandel: I have to stop for today but I updated https://wiki.ubuntu.com/citrain/LandingProcess#Dual-landing_and_handling_symbols by parsing the contents of silo 10 + reading michi's initial explanation above | 14:13 |
| mandel | Mirv, good starting point | 14:14 |
| michi | the QA team needs to learn that they are asking for something that causes a lot of maintenance overhead for very little return on investment. | 14:14 |
| renatu | michi, I do not have problems with my .install files the problem will start with symbol files | 14:14 |
| michi | Mirv: | 14:14 |
| michi | Just skimming. | 14:14 |
| michi | hold back on the publishing of this please. | 14:14 |
| michi | the Vivid special-casing is rather unique to our project and won’t apply to most other projects. | 14:15 |
| michi | I’m about to hack this up a little bit more to get rid of the vivid special case altogether. | 14:15 |
| michi | Anyway, the basic idea is simple: have the hook in debian/rules that calls a shell script (or python, whatever). | 14:16 |
| Mirv | michi: it's a wiki :) added a note at the top that it's a bit WIP | 14:16 |
| michi | Then make that script adjust all the soversion stuff, rename files, substitute the first line into the symbols file, generate a shlibs file, and so on. | 14:16 |
| michi | the idea is that, if you compile the exact same source for both vivid and wily, the only differences that matter are in the debian files. | 14:17 |
| michi | So, generate the debian files instead of coddling two different series along. | 14:17 |
| michi | In the end, for identical source, there should be only two things that differ in the final packages: the soname, and the package name. | 14:18 |
| michi | Use a symbols file for vivid, and a shlibs file for wily (until we get abi-compliance-checker working nicely) | 14:19 |
| michi | That way, we are no worse off than we are now, but we don’t have to maintain two series and two symbols files. | 14:19 |
| Mirv | ogra_: can you review https://ci-train.ubuntu.com/job/ubuntu-landing-046-2-publish/lastSuccessfulBuild/artifact/ubuntu-app-launch_content.diff it adds liblibertine-dev dependency and changes to depend on upstart instead of transitional upstart-bin. changelog entry funniness is because of different order wily/vivid landings but seem correct otherwise. | 14:28 |
| Mirv | tedg: you will need to MIR request libertine when you eventually land the new ubuntu-app-launch to wily, even though 046 is vivid overlay only | 14:29 |
| Mirv | depending on the point of view it might be wanted to be done already before 046 can be published to overlay | 14:29 |
| tedg | bregma: ^ | 14:30 |
| Mirv | bregma: tedg: so regarding wily 1. get archive admin to approve it from https://launchpad.net/ubuntu/wily/+queue?queue_state=0&queue_text= 2. file a https://wiki.ubuntu.com/MainInclusionProcess at https://bugs.launchpad.net/ubuntu/+source/libertine 3. when approved, arrange for ubuntu-app-launch release and alert also trainguard so that when publishing it archive admin:s need to be once more contacted | 14:33 |
| Mirv | to do the actual (approved) promotion to main of libertine once ubuntu-app-launch starts needing it | 14:33 |
| kgunn | trainguards long story short, due to proj deps branching (or not) and debian dep numbers....i think i want to do one of 2 things | 14:33 |
| kgunn | 1) can i have 1 silo with MPs and 1 silo with src sync rebuild, and guarantee those go together ? | 14:34 |
| kgunn | or 2) have 1 silo with mp's, then create another silo for the src sync...copy over the binaries from that 2nd silo into the first to make it a guarantee ? | 14:35 |
| ogra_ | Mirv, looks fine ... if it breaks tedg will get no beer at the next sprint ... so ACK ... | 14:37 |
| Mirv | ogra_: serious enough threat, ok! | 14:39 |
| Mirv | kgunn: not understanding the why still, but I'd use 2) ie use a temporary throwaway silo from where you copy when everything is ready to the first silo. it's also easier for QA to test when there's only one final silo. | 14:40 |
| Mirv | I need to go now like I probably said a long time ago :) so please wait for robert to wake up for trainguardings | 14:42 |
| tedg | Wait, wait. Perhaps bregma should be in charge here, I'm not willing to take those risks! | 14:46 |
| tedg | Thanks ogra_ ! | 14:46 |
| nerochiaro | cihelp: does anyone know why this is failing ? looks like infrastructure problems: https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/3244/console | 15:26 |
| alf_ | psivaa: Hi! Did you get a chance to look at the https://jenkins.qa.ubuntu.com/job/mir-android-vivid-i386-build/ failures? Seems like an archive problem? | 15:38 |
| psivaa | alf_: not yet, that's still in the list. sorry being consumed by something else | 15:39 |
| fginther | nerochiaro, it looks like a couple of mako devices have failed. Not sure the cause yet. | 15:55 |
| fginther | nerochiaro, I've triggered a rebuild on that branch | 15:58 |
| tsdgeos | cihelp: all the qmluitests jobs are stuck http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-vivid/ | 15:59 |
| nerochiaro | fginther: ok. if it happens on other branches should I alert you ? | 16:00 |
| fginther | nerochiaro, the failed devices have been taken offline, so new runs should be ok for now. But if this caused other runs to fail, we can restart those too | 16:07 |
| fginther | nerochiaro, but at the moment, there is a shortage of working devices | 16:07 |
| mzanetti | psivaa, what tsdgeos tried to say above is that all the slaves are offline and can't be started by jenkins: http://s-jenkins.ubuntu-ci:8080/label/vivid&&amd64/? | 16:07 |
| fginther | psivaa, the restart of the libvirt service may have broken the connection to s-jenkins. We may have to restart s-jenkins to correct it | 16:12 |
| psivaa | fginther: hmm yea, that could probably be the reason.. | 16:13 |
| fginther | s-jenkins.ubuntu-ci needs a restart, sorry for the short notice | 16:26 |
| === fginther changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? ping cihelp | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: OTA-6 final freeze in effect, but the vivid-overlay landing gates opened. sil2100 away, small trainguard gap between EEST & RDT (robru daylight saving time) timezones, s-jenkins.ubuntu-ci needs a restart | ||
| robru | kgunn: alright, what's the plan? you want two silos? | 17:20 |
| robru | crap | 17:58 |
| * popey creates https://requests.ci-train.ubuntu.com/#/ticket/306 and wonders what happens next.. some bot? | 18:11 | |
| popey | yes, some bot. | 18:15 |
| kgunn | robru: yep, so question is....do you have magical powers to copy over the pkgs from the silo 24 ppa into the silo 54 ppa ? and do i need to add something else to the silo 54 entry in the train ? | 18:24 |
| kgunn | e.g. mir listed in some text block entry to tell the silo 54 configuration that will be there | 18:25 |
| robru | kgunn: I do have magical powers. | 18:26 |
| robru | kgunn: one sec | 18:26 |
| fginther | mzanetti, tsdgeos, the unity-phablet-qmluitests-vivid have been restored | 18:27 |
| mzanetti | fginther, thanks :) | 18:27 |
| robru | kgunn: ok I did the copy. you should now add 'mir' to the sources field of silo 54, do the 'assign' and then do a build with WATCH_ONLY | 18:29 |
| robru | popey: presumably qa will pick that up | 18:35 |
| kgunn | robru: i must be missing something ^ | 18:40 |
| robru | kgunn: yep, you ran a build that deleted all your files but then failed to build anything: https://ci-train.ubuntu.com/job/ubuntu-landing-054-1-build/16/consoleFull so you'll need to rebuild the whole silo now. | 18:42 |
| kgunn | robru: but i marked it as watch? | 18:43 |
| robru | kgunn: but there's nothing to watch, because everything in your silo was previously deleted. you have nothing. you need to rebuild. | 18:43 |
| robru | kgunn: look at the log I pasted, it literally says "deleting everything" and then when it tries to build it fails and stops. | 18:44 |
| kgunn | robru: maybe i misunderstood...i thot silo54 would already be empty, except for mir that you just copied in from silo 24, meaning it | 18:47 |
| kgunn | would "watch" and see mir, but then build the mp's | 18:47 |
| kgunn | and how come when i look in the silo54 ppa i see 6 hrs old pkgs | 18:48 |
| robru | kgunn: i don't... what... | 18:50 |
| robru | kgunn: WATCH_ONLY means that it WATCHes ONLY... I don't understand how you could think that would build anything. | 18:50 |
| robru | kgunn: I also don't understand why you think your silo would be empty? I thought the whole point of this exercise was that you had MPs in there that you'd built? | 18:50 |
| kgunn | robru: sorry, then i didn't express myself properly... and it's kinda long winded so here goes... | 18:51 |
| kgunn | i was trying to get mir that's in wily to vivid+o | 18:51 |
| kgunn | and that mir has an abi break going from old to new in vivid+o | 18:52 |
| kgunn | so i need to rebuild usc & qtmir | 18:52 |
| dobey | err | 18:52 |
| dobey | trainguards: eh? 14:35 -queuebot:#ubuntu-ci-eng- dobey, ubuntu/landing-040: Can't publish: Critical data missing from packagelist. Perhaps try a WATCH_ONLY build: | 18:52 |
| kgunn | can't mix mp's & src sync in silo...so, looked at doing one big src sync from wily, but due to other deps (unity-api & qtmir) | 18:53 |
| robru | dobey: right I was going to look at that, one sec | 18:53 |
| kgunn | that didn't work...so then tried to do all MP's including mir, but then 15.10 v 15.04 complaining ....so | 18:53 |
| kgunn | this was my last idea... | 18:53 |
| robru | kgunn: your silo is in a broken state and needs to be completely rebuilt. however you got those packages into the PPA, they're orphaned because the necessary branches are not in the silo dir. | 18:54 |
| kgunn | do temp silo src sync for mir, so builds mir happily for vivid+o no complaining | 18:54 |
| robru | kgunn: the thing about versions is easy to fix, you need to branch for vivid rather than trying to build your wily trunk for vivid. | 18:54 |
| robru | kgunn: and in your vivid branch you need to s/15.10/15.04/ on the changelog version of the most recent entry. | 18:54 |
| kgunn | so painful to have 2 branches when it's the same damn src | 18:55 |
| robru | kgunn: well michi is working on a solution to that as I mentioned. but it's a lot of extra work | 18:56 |
| robru | dobey: oh crap, I broke everything, hang on | 18:56 |
| dobey | ok | 18:56 |
| kgunn | robru: consider for a moment, dual landing allows me not to have to have 2 damn branches....only reason i can't is someone on a 2 degree separation dpendency decided to have 2 branches for what seems to be no good reason | 18:57 |
| robru | slangasek may be better than I am at explaining why two branches are preferrable ^^ | 18:58 |
| dobey | the problem is because your silo has an MP for some other project which doesn't do dual landings? | 18:58 |
| robru | kgunn: anyway, train has support for the magic that lets you dual land, it's up to you to fix your packaging to make it happen, just follow the way michi's doing it if you really want that | 18:58 |
| slangasek | eh | 18:59 |
| slangasek | I'm not about to dictate that people *should* use separate branches | 18:59 |
| slangasek | however, this kind of drag on dual landings is bound to increase over time | 19:00 |
| robru | dobey: ok I have a fix in trunk, just waiting on IS to roll that out then I can publish it. | 19:00 |
| slangasek | and michi's work isn't ready to land yet in the archive, so I don't recommend adopting that just now if you're trying to unblock something you need landed today | 19:00 |
| dobey | robru: ok | 19:02 |
| robru | dobey: ugh, IS guy is on lunch for 1.5 hours already. are you in a hurry to publish that? | 19:08 |
| dobey | robru: not critical, but want to get it landed asap | 19:09 |
| robru | dobey: k, if you get sick of waiting for IS to roll out my fix you might want to consider getting a core dev to copy the package to the archive manually, and then merging the silo manually. i have no idea when this guy will get back, already pinged him twice. | 19:10 |
| kgunn | slangasek: what specifically do "no recommend adopting if trying to unblock something landing today" | 19:22 |
| robru | dobey: ok sorry for the delay, published | 19:22 |
| dobey | robru: ok, great, thanks | 19:22 |
| robru | kgunn: the packaging changes required to keep dual landing even in the face of gcc5 issues are really staggering, it's not something you can just easily do in a hurry. | 19:22 |
| kgunn | got it | 19:22 |
| kgunn | robru: but dual landing today just rebuilds no ? | 19:23 |
| kgunn | which i like btw | 19:23 |
| kgunn | bin copy seems naughty | 19:23 |
| kgunn | (potentially naughty) | 19:24 |
| robru | kgunn: yes, exactly. dual landing just rebuilds. which is really horribly broken for gcc5 projects because you need to have different binary package names, which means you need to have different debian/control files to achieve that | 19:24 |
| robru | kgunn: so in the train we implemented a hook that allows you to rewrite your debian/control as appropriate for the release you're building for. but it's up to you to write a script that generates the appropriate debian/control | 19:25 |
| robru | kgunn: it's not something you can just drop in and go, it's a really massive architectural shift in your packaging | 19:25 |
| robru | kgunn: if you're curious you can look at what michi's doing in silo 10, it's a big deal | 19:25 |
| kgunn | when you say control file, you're implying hard dep on gcc versions | 19:26 |
| robru | kgunn: no, I'm implying that the actual *names* of the binary packages are different for wily than for vivid. | 19:26 |
| dobey | the ABI is different, therefore package names must be different | 19:26 |
| robru | kgunn: which is not something that debian/control actually supports, so you need to create a meta debian/control that you then pre-process into the correct debian/control as appropriate. | 19:26 |
| dobey | because otherwise libmir0 on one will not be the same as libmir0 on the other | 19:27 |
| robru | kgunn: so eg you'd need to rename debian/control to debian/control.in, and then you'd change "Package: libmirN" to "Package: libmir@SONAME@", and then in your debian/rules you make some magic that figures out what the correct @SONAME@ is for vivid vs wily, and then s/@SONAME@/the series-appropriate soname/ | 19:28 |
| robru | kgunn: but there's a ton of different places you have to do that, it's all over your install files. like I said, not a quick fix | 19:29 |
| robru | kgunn: oh sorry I've only just noticed. that package copy I did for you failed because the same version was already in the PPA. | 19:47 |
| bregma | hey robru I just rebuilt silo 27 with changes requested by archive admins after a NEW review, is there something that needs to be done to upload to the queue again? | 20:06 |
| robru | bregma: yeah it would need to be published again. | 20:06 |
| bregma | robru, do I do that or do you guys do that? | 20:07 |
| * bregma may have been hit on the head and forgotten everything | 20:07 | |
| robru | bregma: I'll do it | 20:07 |
| * bregma was recently on a sprint where his employer is trying to raise an army of sleep-deprived alcoholic zombies | 20:08 | |
| robru | awesome | 20:08 |
| robru | slangasek: can I get you to try publishing request 278? apparently checkupload doesn't like NEW stuff ^^ | 20:09 |
| bregma | is that a bug in the splendid new bileto code? | 20:09 |
| slangasek | it's by design that you can't publish a new package to the archive without signoff of an Ubuntu dev | 20:10 |
| slangasek | I'm on a call right now, I can give it my full attention in about 20 min | 20:10 |
| slangasek | what's with the AttributeError? :) | 20:11 |
| robru | slangasek: attributeerror is coming from lplib, I wrote my code according to spec and caught the ClientError thrown when people aren't authorized to upload. | 20:15 |
| robru | slangasek: ok I have a workaround, just trying to recreate the issue in staging to confirm | 20:43 |
| slangasek | robru: my attempt to publish: https://ci-train.ubuntu.com/job/ubuntu-landing-027-2-publish/49/ | 20:48 |
| slangasek | robru: despite marking 'ack_packaging' | 20:48 |
| robru | slangasek: thanks, it's clearly a bug in lazr, I'm working on a workaround, just poking around in staging. | 20:48 |
| slangasek | ok | 20:49 |
| slangasek | ah it's the same backtrace, innit | 20:49 |
| slangasek | ok then | 20:49 |
| robru | slangasek: heh, ok workaround has succeeded but it's uncovered a bug in my code now ;-) | 20:51 |
| robru | slangasek: so since this is forcing the issue, what's the story for NEW packages? only core devs can publish NEW? | 20:52 |
| * slangasek hands robru the norelco yakshaver 2000 | 20:52 | |
| slangasek | robru: I believe the rule is that core devs and MOTU can upload NEW packages, and other ubuntu-devs cannot | 20:52 |
| slangasek | infinity, cjwatson, wgrant: ^^ can you sanity check me on that? | 20:52 |
| robru | slangasek: is there an lp team for MOTU? how do I check that? | 20:52 |
| infinity | slangasek: MOTU (which core-dev is a subset of) can upload NEW, yes. Fuzzier if you're NEWing something detined for main, since you'll never be able to do a second upload if you're not core-dev, but we hand-wave past that. :P | 20:54 |
| slangasek | robru: can you not rely on the existing checkUpload call to determine this properly? or is this the part that's failing? | 20:54 |
| robru | slangasek: yes that is exactly what is failing | 20:54 |
| slangasek | robru: i.e. I would expect the LP API to tell you "is this person allowed to upload this non-existent package? y/n" | 20:54 |
| infinity | robru: ~motu would be the right team, but obviously hardcoding teams is wrong, since you should be getting the answer from LP. | 20:55 |
| slangasek | robru: what happens if you call checkUpload() without a source package name? | 20:55 |
| robru | slangasek: checkUpload seems to work fine for packages that exist but it explodes horribly with that AttributeError if you call it on a package that isn't in the archive | 20:55 |
| slangasek | try: checkUpload(sourcepackagename=, ...) except AttributeError: checkUpload(...) | 20:55 |
| robru | slangasek: gimme a sec to poke that | 20:56 |
| dobey | that AttributeError looks like a python3 vs python2 api issue | 20:56 |
| dobey | robru: ^^ | 20:56 |
| robru | dobey: yes | 20:56 |
| robru | dobey: I fixed that trivially by monkeypatching. | 20:56 |
| dobey | ah ok | 20:56 |
| jgdx | cihelp: evening, why is webapp tests run for [1]? The params says ubuntu-system-settings test suite only. [1] https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/3252 | 20:57 |
| jgdx | doesn't happen for all builds, but this is not the first time I believe | 20:58 |
| jgdx | in #3214 unity8 tests are run | 20:59 |
| slangasek | robru: hmm bug #821366 | 20:59 |
| ubot5 | bug 821366 in Launchpad itself "IArchive.checkUpload() requires existing sourcepackagename" [High,Triaged] https://launchpad.net/bugs/821366 | 20:59 |
| robru | ah, yes | 20:59 |
| infinity | Only 4 years old. | 20:59 |
| robru | infinity: they'll fix it any day now | 21:01 |
| infinity | robru: So, a gross workaround (which may or may not be better than hardcoding a team) would be to trap the expected error from a nonexistant source, and sub in spn=sendmail (which will never, ever, ever leave universe). :P | 21:03 |
| robru | slangasek: Uncaught exception: ValueError: No value for required parameter 'sourcepackagename' | 21:03 |
| infinity | Err. | 21:04 |
| infinity | sendmail is in main. Nevermind. lolwut. | 21:04 |
| slangasek | heh | 21:04 |
| robru | infinity: sorry I'm just catching up with slangasek's suggestion to omit spn | 21:04 |
| infinity | There would be others that would fit the bill. | 21:04 |
| infinity | But gross hack either way. | 21:04 |
| slangasek | robru: yeah confirmed locally and via api docs that spn is required | 21:04 |
| robru | slangasek: thoughts? hard-code default package name or hard-code team membership | 21:04 |
| infinity | It's the same end result, really. We could change which team has upload rights (but probably not), or we could pick a package we're sure will never leave universe, but it might. | 21:05 |
| robru | slangasek: I can say "if no sourcepub is found, check person's teams for MOTU" or whatever easily enough | 21:05 |
| infinity | The worst fallout from the package hack is that you further restrict uploaders. | 21:05 |
| slangasek | robru: I think it's easier to hard-code a default package name | 21:05 |
| robru | slangasek: ok, what's a good package to use then? if not sendmail? | 21:05 |
| infinity | Now, let me find something in universe that sucks so bad we'll never promote it, but is so ubiquitous that we'll never remove it. | 21:06 |
| slangasek | infinity: would something from multiverse work? | 21:06 |
| infinity | slangasek: Yes. Flash? | 21:06 |
| slangasek | maybe one of those packages that's blacklisted in seeds | 21:06 |
| slangasek | hmm but libavcodec has an soname so that doesn't help | 21:07 |
| slangasek | oh, except source package - so 'libav' | 21:08 |
| slangasek | robru, infinity: ^^ my suggestion for a default source package | 21:08 |
| infinity | flashplugin-installer is mine. | 21:08 |
| robru | slangasek: infinity: oh I just tried it with an empty string and it seems to have worked | 21:09 |
| slangasek | hahwut | 21:09 |
| infinity | Oh? | 21:09 |
| infinity | Well, that works better then. | 21:09 |
| robru | slangasek: infinity: well "worked" in the sense that it told me I'm not authorized | 21:09 |
| infinity | You still need to trap and retry, but that's fine. | 21:09 |
| fginther | jgdx, ah. I found that it was configured to use the wrong workspace directory and it was inadvertently picking up results from another test. Should be fixed shortly. | 21:09 |
| robru | slangasek: can I get you to run this publish job with and without ACK? https://ci-train.staging.ubuntu.com/job/ubuntu-landing-001-2-publish/build?delay=0sec | 21:09 |
| robru | infinity: trap and retry? | 21:10 |
| fginther | jgdx, 'it' being the mako-20 which ran that test. | 21:10 |
| infinity | robru: Rerun it with a personid who has rights? | 21:10 |
| infinity | robru: Well, you need to checkUpload for your spn, then retry if it explodes, no? | 21:10 |
| robru | infinity: well, that would mean finding a person to run the job, not something I can do in the code | 21:10 |
| robru | infinity: no, I call getPublishedSources to confirm my spn exists. if it does I set it, if not, empty string | 21:10 |
| infinity | robru: Oh, or that, sure. Mine was an optimisation to avoid the check except when needed, but if you getPS for other reasons, yours is cleaner. | 21:11 |
| robru | infinity: yeah we need to check the component also | 21:11 |
| robru | infinity: can you run that job I linked ^^ with and without ACK_PACKAGING checked? need to make sure it really works | 21:12 |
| infinity | robru: Is this going to publish a real thing to a real place? | 21:13 |
| robru | infinity: no it's staging | 21:13 |
| robru | not connected to anything. just need to make sure it doesn't say "infinity not authorized to upload" | 21:13 |
| infinity | robru: Okay. The big blue "build" button? | 21:13 |
| robru | infinity: yep | 21:13 |
| infinity | adconrad is missing the Job/Build permission | 21:14 |
| robru | infinity: did you check the teams on SSO when you logged in? | 21:14 |
| robru | infinity: core devs should be authorized | 21:14 |
| infinity | No. If you need teams, shouldn't you set them mandatory in your SSO config? :P | 21:14 |
| robru | infinity: that is the case in production but not in staging | 21:15 |
| robru | infinity: please log out, check the teams, log back in, run the job | 21:15 |
| infinity | Okay, seems to have done a thing when hitting the button without ticking any boxes. | 21:15 |
| robru | infinity: ah, so that's bad then, if it thinks you're not authorized. | 21:16 |
| infinity | Hrm? | 21:16 |
| infinity | It did a thing. Not nothing. | 21:16 |
| infinity | I'm assuming I was authorized. | 21:16 |
| robru | infinity: the thing it did is that it told you you're not authorized to upload a package to universe. I'd consider that a failure, no? | 21:16 |
| infinity | Oh, where do I see that? :P | 21:17 |
| robru | infinity: click through to the console log | 21:17 |
| robru | infinity: I'll try this again with libav. | 21:17 |
| infinity | Man, I love jenkins. | 21:17 |
| robru | infinity: I can't wait to get rid of it ;-) | 21:18 |
| brendand | infinity, here's your prize for being the first person ever to say that! | 21:18 |
| infinity | robru: flashplugin-nonfree, please. | 21:18 |
| infinity | robru: libav will probably get removed some day soon as ffmpeg takes over, and fp-nonfree is multiverse, so a true superset of archive permissions. | 21:18 |
| infinity | brendand: It was said ironically, I can't possibly be the first. | 21:19 |
| brendand | infinity, if said ironically, then no, definitely not the first | 21:19 |
| === fginther changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? ping cihelp | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: OTA-6 final freeze in effect, but the vivid-overlay landing gates opened. sil2100 away, small trainguard gap between EEST & RDT (robru daylight saving time) timezones | ||
| * brendand takes back infinity's prize | 21:19 | |
| robru | infinity: what's the source package name? flashplugin-installer? | 21:19 |
| infinity | robru: flashplugin-nonfree | 21:20 |
| robru | infinity: ok, run that job one more time with debug checked please | 21:21 |
| robru | infinity: ok perfect, thanks | 21:22 |
| robru | infinity: that's confirmed working then, I'll write some tests now | 21:22 |
| infinity | robru: Hey, it even works if I ACK the packaging changes. | 21:23 |
| robru | infinity: yep | 21:23 |
| infinity | 2015-09-02 21:23:12,462 DEBUG Beginning: phase: ackaging | 21:24 |
| infinity | Good ol' ackaging. | 21:24 |
| robru | infinity: it's a portmanteau of ACK and PACKAGING. ;-) | 21:24 |
| infinity | robru: Righto. For when someone needs to pack the ackage. | 21:25 |
| slangasek | robru: https://ci-train.staging.ubuntu.com/job/ubuntu-landing-001-2-publish/build?delay=0sec done; Access Denied | 21:26 |
| robru | slangasek: what? | 21:26 |
| robru | slangasek: also infinity beat you to it, but thanks for trying | 21:26 |
| slangasek | robru: ok :) | 21:26 |
| infinity | robru: If this code is intended to live more than a few minutes, you might want some obnoxiously loud "XXX: AAAACK, STUPID HACK" comments around the fake spn bit. :P | 21:29 |
| robru | infinity: I expect this will be in production for 4-8 years. ;-) | 21:29 |
| robru | infinity: 1-2x the current age of that bug ;-) | 21:29 |
| * infinity wonders how LP's own queue deals with this. | 21:31 | |
| infinity | I would have thought it calls the same method, but, well. Soyuz, man. | 21:31 |
| slangasek | robru: why does staging want to know from SSO that I'm a core-dev, as opposed to just knowing that I'm a ci-train-users? | 21:32 |
| robru | slangasek: because core-dev is required for publishing. | 21:34 |
| slangasek | robru: oh, because that's the existing check, right | 21:35 |
| slangasek | and goes away when this is done ;) | 21:35 |
| robru | slangasek: yeah. jenkins ACLs go by launchpad teams | 21:35 |
| robru | slangasek: you were saying something about code review? https://code.launchpad.net/~robru/cupstream2distro/monkeypatch-lazr/+merge/269988 ;-) | 21:35 |
| slangasek | totes | 21:35 |
| robru | dobey: http://bazaar.launchpad.net/~robru/cupstream2distro/monkeypatch-lazr/revision/1070#citrain/recipes/base.py fun times. fun times. | 21:36 |
| dobey | oh, ugh | 21:37 |
| robru | slangasek: does that mean you'll review or is that sarcasm? ;-) | 21:37 |
| infinity | robru: When you tested an empty spr, did you test None or an empty string? | 21:37 |
| slangasek | robru: I am reviewing | 21:37 |
| robru | infinity: empty string | 21:37 |
| robru | slangasek: thanks | 21:37 |
| slangasek | infinity: both None and emptystring fail | 21:38 |
| infinity | robru: Reading some source here, internally, 'None' would work. Though I'm not sure if that can be represented sanely over an xmlrpc API, which might be the issue. | 21:38 |
| slangasek | (checked with lp-shell) | 21:38 |
| slangasek | No such source package: ''. | 21:38 |
| slangasek | and with None, it's sourcepackagename: Required input is missing. | 21:38 |
| infinity | slangasek: Yeah, could be a serialisation issue or something, might need to explicitly allow null and the empty string as well to make the wire protcol happier. | 21:39 |
| infinity | slangasek: Cause the internal methods totally don't choke on spn=None. | 21:39 |
| infinity | Which is why this works for the real queue. | 21:39 |
| slangasek | robru: approved | 21:40 |
| robru | slangasek: thanks | 21:40 |
| robru | slangasek: ok, seeing as that only affects NEW packages I think I'll roll that out tomorrow batched together with some other stuff. I already did 2 rollouts today, trying not to bother IS too much... | 21:43 |
| slangasek | robru: well, I believe bregma's publication is blocked until this is fixed | 21:45 |
| slangasek | I think you want to at least /ask/ IS for the rollout | 21:45 |
| infinity | slangasek: No, I did bregma's by hand. | 21:45 |
| robru | yeah ^ | 21:46 |
| robru | bregma: although we will need ~ci-train-bot added to ~libertine-team | 21:46 |
| infinity | slangasek: To wily, that is. We could do the same to the overlay, if that's also blocked. | 21:46 |
| robru | infinity: oh I did that already. was that premature? | 21:46 |
| infinity | robru: Oh, if you did vivid-overlay, fine by me, I wasn't sure if it was choking on the same issue. | 21:46 |
| robru | infinity: yeah the publish job was exploding before it got to the part where it copied to vivid | 21:47 |
| bregma | why is it always me? | 21:48 |
| infinity | bregma: Nefarious reasons. | 21:48 |
| robru | bregma: stop making new projects with new teams :-P | 21:48 |
| slangasek | infinity: ah ok | 21:49 |
| bregma | robru, should that silo get merged now? | 21:50 |
| robru | bregma: did you add the bot to the team? | 21:50 |
| bregma | oh, crap, that's what I forgot | 21:50 |
| robru | bregma: after that's done I don't think there's any harm in merging. strictly speaking the train would have waited for the package to migrate fully but the excuses page says "valid candidate" so that should migrate real soon now... | 21:51 |
| infinity | Except that, entertainingly, it thinks libertine breaks itself on arm64. | 21:53 |
| infinity | Impressive. | 21:54 |
| robru | infinity: that excuses page is a bit rubbish if "valid candidate" is a false positive. | 21:54 |
| Laney | Valid for the next stage | 21:55 |
| infinity | robru: It's a two-stage process. | 21:55 |
| Laney | E: Package 'proot' has no installation candidate | 21:55 |
| Laney | That is why | 21:55 |
| robru | infinity: is that something you can wave through or will this require fixes from bregma? | 21:55 |
| Laney | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788113 maybe look at that | 21:56 |
| ubot5 | Debian bug 788113 in src:proot "proot: FTBFS on arm64" [Normal,Open] | 21:56 |
| bregma | grr | 21:56 |
| infinity | What's pulling in proot? | 21:57 |
| infinity | Oh, the python module. | 21:57 |
| Laney | libertine -> libertine-tools -> python3-libertine -> proot | 21:57 |
| infinity | Which is why I didn't see it in the arm64 build log. :P | 21:57 |
| robru | bregma: arm64 is for chumps, i wouldn't support it if I were you. | 21:57 |
| bregma | libertine pulls in proot for the time being because of need in vivid-overlay | 21:57 |
| Laney | That bug has a patch you know | 21:57 |
| Laney | Someone arm64ish could review it | 21:57 |
| infinity | It does indeed. | 21:58 |
| infinity | And I shall. | 21:58 |
| infinity | Okay, that patch alone leads me to believe that proot is gross. | 21:58 |
| robru | bregma: anyway it's sounding like infinity is going to fix proot on arm64 and then you'll be good to go. watch here: https://launchpad.net/ubuntu/+source/libertine and merge when it says "release (universe)" | 21:59 |
| robru | brb | 21:59 |
| * Laney goes to bed happy | 22:00 | |
| infinity | It's going to have the same sadness on ppc*, mind you. | 22:01 |
| infinity | Where proot isn't ported at all. | 22:01 |
| fginther | bregma, speaking of libertine... Should ci for lp:libertine/devel be done on wily or vivid+overlay or something else? | 22:01 |
| bregma | fginther, wily please | 22:02 |
| fginther | bregma, danke | 22:02 |
| * bregma steps out to buy some groceries for his poor starving family | 22:03 | |
| infinity | bregma: OOI, why was fakechroot good enough for later releases, but not trusty? | 22:03 |
| infinity | bregma: Given fakechroot is the same version in trusty->wily, that seems odd. | 22:05 |
| infinity | bregma: (Also, if this is ever meant to be supported, fakechroot has a 2000% better chance at passing an MIR than proot does, from my quick reading of the proot source) | 22:06 |
| fginther | mandel, what's the story on ubuntu-download-manager? That project was never moved to wily. Should it be? | 22:24 |
| bregma | infinity, I don;t know why proot over fakeroot, I'd have to ask ChrisTownsend and he's EOD | 23:38 |
| bregma | hoping to elide proot by the time we need to MIR | 23:38 |
| infinity | bregma: Well, there's code there for both proot and fakechroot, hence the question. (And also no dep on fakechroot, so it'll probably fail to work in those cases). | 23:46 |
| bregma | infinity, we actually did a lot of refactoring at a sprint last week and are aiming to do more in the near future, so either we left some incorrect dependencies in there or we'll find out the hard way we missed some | 23:49 |
| bregma | we're trying to shoe-horn this project into a use it was not designed for on a system that lacks proper support, so we're doing a delicate dance | 23:49 |
| bregma | always good for some laughs and a good story later | 23:50 |
| infinity | bregma: Right. I need to run to dinner. To be continued. But I suspect the proot dep can be dropped today, with a bit of deletion. | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!