| cjwatson | maxb: my non-flippant answer is in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204; that would be automatable in bzr-builddeb, I'm sure | 00:00 |
|---|---|---|
| ubot2 | Debian bug 572204 in dpkg-dev "dpkg-dev: maintainer workflow problems with 3.0 (quilt) and VCS" [Wishlist,Open] | 00:00 |
| * cjwatson -> bed | 00:02 | |
| * maxb drops a quick mail to u-distributed-devel@ about this | 00:04 | |
| cjwatson | I think at the time it seemed quite intrusive, but now bzr-builddeb is doing lots of quilt munging already ... | 00:05 |
| * skaet --> EOd | 02:20 | |
| slangasek | skaet: 'night | 02:28 |
| ScottK | Nice. caph and chort both building the same package on the same arch at the same time. | 03:25 |
| pitti | slangasek: as I said, I don't veto gnome-session, I just don't think it's very useful or wise | 05:00 |
| slangasek | pitti: yep - I understand your position, my point is merely that the arguments here are no different during a freeze than not | 05:01 |
| pitti | slangasek: yes, I agree | 05:01 |
| pitti | it's not risky at all | 05:01 |
| pitti | oh, someone rejected it? | 05:02 |
| slangasek | anyway, I would love for there to be a non-sucky session manager solution that upstream would back... in the meantime, I'll take what I can get ;) | 05:02 |
| pitti | I reject one of the two kubunut-default-settings (identical), leaving the other one as per pad | 05:02 |
| * slangasek nods | 05:03 | |
| slangasek | I really don't think kubuntu-default-settings needs to block on plymouth, but it shouldn't matter as plymouth should come later today (according to cjwatson) | 05:03 |
| pitti | slangasek: | 05:04 |
| pitti | -Command: /usr/lib/update-notifier/package-data-downloader | 05:04 |
| pitti | +Command: gksudo /usr/lib/update-notifier/package-data-downloader | 05:04 |
| pitti | slangasek: does that file not apply to Kubuntu? | 05:04 |
| pitti | (also, "gksu" is the canonical command, but not a biggie) | 05:04 |
| pitti | argh, so once again powerpc backlog is causing trouble | 05:06 |
| slangasek | pitti: well.... I don't see any available alternative that works in kubuntu (see changelog, & bug comments about policykit not happening for final) | 05:06 |
| slangasek | so calling gksudo, so that it fails only on Kubuntu, is better than calling the raw command and having it fail everywhere | 05:06 |
| pitti | hm, but these two changes together don't make much sense to me | 05:07 |
| pitti | sudo does not keep the proxy variables from the user, so we rely on the user to have clicked "apply system wide" when configuring the proxy | 05:08 |
| pitti | but wouldn't that set the proxy in apt, too? | 05:08 |
| pitti | ah, you hope that the general proxy in /etc/environment is better for the auxiliary downloads than apt's, I see | 05:09 |
| slangasek | yeah | 05:11 |
| slangasek | it's imperfect, but, well, apparently there are some large deployments of Ubuntu whose proxy usage conflicts with my previous assumption | 05:12 |
| slangasek | users relying on the apt proxy setting for package data downloads before couldn't get ubuntu-restricted-extras anyway... because msttcorefonts implemented this one way, flashplugin-nonfree implemented it the other way | 05:13 |
| pitti | didrocks: good morning | 05:17 |
| pitti | didrocks: is the unity FTBFS on arm due to the nux changes? | 05:17 |
| didrocks | hey pitti :) | 05:17 |
| didrocks | pitti: hum, can be yeah, let me look | 05:18 |
| pitti | slangasek: I'll move some built -proposed stuff to release now (eglibc, etc.), ok? | 05:19 |
| slangasek | pitti: if powerpc is caught up, sure - it wasn't last I'd looked | 05:20 |
| pitti | yes, for glibc; it's currently chewing on the KDE rebuilds | 05:20 |
| pitti | I guess infinity nudged it a bit :) | 05:21 |
| didrocks | pitti: so: | 05:24 |
| didrocks | https://launchpadlibrarian.net/101498332/buildlog_ubuntu-precise-armhf.unity_5.8.0%2Bbzr2276ubuntu0%2B677_FAILEDTOBUILD.txt.gz didn't built on armhf | 05:24 |
| didrocks | https://launchpadlibrarian.net/101346712/buildlog_ubuntu-precise-armhf.unity_5.8.0%2Bbzr2275ubuntu0%2B677_BUILDING.txt.gz built | 05:24 |
| didrocks | the libnux version commit between the two isn't meaningfull | 05:24 |
| didrocks | looking for compiz | 05:24 |
| didrocks | as linaro changed compiz as well | 05:24 |
| didrocks | (the packaging is the same, so it's not the nux change) | 05:25 |
| pitti | erk, accidentally copied to -updates; please ignore the following flood of new/rejects in -updates | 05:25 |
| didrocks | pitti: the only thing that seems to be have meaningfully changes is compiz | 05:26 |
| didrocks | pitti: so it's the linaro patch for compiz | 05:26 |
| didrocks | pitti: can try in a ppa building unity with the previous compiz (without their patch) | 05:26 |
| pitti | didrocks: you have an arm PPA? | 05:26 |
| didrocks | pitti: I do ;) | 05:27 |
| didrocks | (well, the unity one) | 05:27 |
| didrocks | not really done for that, but I guess it can be used for that | 05:27 |
| pitti | didrocks: ok, please prod me for build score bumps if needed | 05:27 |
| didrocks | pitti: it's already a priority ppa, heh ;) | 05:28 |
| didrocks | ok, compiz first | 05:28 |
| * pitti hugs didrocks | 05:28 | |
| * didrocks hugs pitti back | 05:29 | |
| pitti | so, -proposed flushed as much as possible | 05:30 |
| slangasek | did samba make it into the flushed set? I see that it's published now, and I was watching for it | 05:36 |
| didrocks | pitti: oh wait | 05:38 |
| pitti | slangasek: yes | 05:38 |
| slangasek | ok, cool | 05:38 |
| didrocks | pitti: https://launchpad.net/ubuntu/+source/compiz/1:0.9.7.6-0ubuntu1 no give back done? | 05:38 |
| didrocks | pitti: it seems to be some archive skew to me | 05:38 |
| pitti | erk, that looks bad; these can be retried? | 05:38 |
| didrocks | yeah, failing due to kde-workspace-dev | 05:38 |
| didrocks | so I guess some arch skew because of kde? | 05:39 |
| pitti | retried, bumping | 05:39 |
| didrocks | thanks | 05:39 |
| didrocks | pitti: that still doesn't fix the FTBFS on armel, I uploaded compiz in the ppa | 05:39 |
| didrocks | waiting for armhf to build to retry unity | 05:39 |
| didrocks | (in the ppa) | 05:40 |
| rsalveti | weird, maybe the unity issue might be related with the compiz changes | 05:41 |
| rsalveti | let me rebuild compiz locally to see if I can also reproduce it here | 05:41 |
| didrocks | rsalveti: thanks! I can say that from my build logs, armhf started to fail to build once the compiz version with the armel patch was made available | 05:42 |
| didrocks | libnux just had an irrelevant commit change between the two | 05:42 |
| didrocks | and the rest of the stack didn't change | 05:42 |
| rsalveti | yeah | 05:43 |
| didrocks | pitti: thanks for the give back, compiz rebuilt on amd64 in the archive | 05:53 |
| didrocks | pitti: maybe you will till be able to score the build a little bit more for the ppa: https://launchpad.net/~unity-team/+archive/ppa/+build/3402499 | 05:54 |
| pitti | didrocks: done | 05:54 |
| didrocks | sweet! :) | 05:55 |
| didrocks | pitti: argh, I need to remove some build-dep as well on armel for the ppa, one sec | 06:01 |
| * didrocks not really happy with the intrusive changes that linaro introduced at the last minute… | 06:02 | |
| rsalveti | hm, locally compiz failed to build because of the way the extra patch is applied | 06:08 |
| rsalveti | when generating the source it failed to remove the already applied patches, because the gles related one was not removed before the others | 06:08 |
| didrocks | rsalveti: interesting, it built on the ppa, so I guess the way the patch is applied/unapplied is right (and ogra checked it) | 06:09 |
| didrocks | pitti: a small help? https://launchpad.net/~unity-team/+archive/ppa/+build/3402518 ;) | 06:09 |
| rsalveti | didrocks: yeah, could be related with my local options | 06:09 |
| pitti | didrocks: I can't get it below 27 minutes, sorry | 06:09 |
| pitti | the buildds seem all busy | 06:09 |
| rsalveti | I got the debs, just failed in the end | 06:09 |
| didrocks | pitti: ok, let's see how it goes | 06:10 |
| rsalveti | let me check compiz-plugins-main now | 06:10 |
| didrocks | rsalveti: seeing the source, the failure seems to really be due to an interface that compiz proposed that has been removed for unity | 06:10 |
| didrocks | seems that the patch wasn't tested against unity | 06:10 |
| rsalveti | that's weird, I know alf tested it with unity as well | 06:11 |
| rsalveti | maybe because of an upstream update? | 06:11 |
| didrocks | rsalveti: can be yeah | 06:11 |
| didrocks | rsalveti: however, the first version we had a failure on armhf is not touching the file which is failing | 06:12 |
| didrocks | (and not including it) | 06:12 |
| pitti | splendid, amd64 builders build three gccs in parallel | 06:13 |
| didrocks | so the only obvious diff I can see between the two builds is this compiz armel patch | 06:13 |
| rsalveti | hm, ok | 06:13 |
| * rsalveti loves icecc, building compiz in minutes | 06:13 | |
| rsalveti | I know that ogra_ was fighting with an upstream rebase/update | 06:14 |
| didrocks | rsalveti: yeah, and alf_ reupdated the patch | 06:14 |
| rsalveti | maybe something was removed or missed during the patch update | 06:14 |
| didrocks | the patch update was done by alf, so I though he tested it against last unity :) | 06:14 |
| rsalveti | compiz-plugins-main also built fine, trying unity now | 06:16 |
| didrocks | rsalveti: unity isn't that fast to build even with icecc, isn't it? ;) | 06:26 |
| didrocks | (and be happy, the tests are not building, which doubles the compilation time ;)) | 06:26 |
| rsalveti | didrocks: seems the unity package is not yet enabling gles compatible builds | 06:26 |
| rsalveti | not using BUILD_GLES nor USE_GLES | 06:26 |
| rsalveti | well, it's a lot better than using one single host :-) | 06:27 |
| didrocks | rsalveti: well, nothing was merged upstream for opengles, that's what I was telling yesterday | 06:27 |
| rsalveti | got 5 different machines here | 06:27 |
| rsalveti | the support seems to be already avialable at upstream, just not enabled at the package | 06:27 |
| rsalveti | let me try to build it with GLES | 06:27 |
| didrocks | rsalveti: ok, keep me posted | 06:27 |
| didrocks | (nobody told me anything about the new option, I thought ogra will take care of this as it was part of the deal) | 06:28 |
| rsalveti | nux was still building for GL until yesterday, so that's seems to still be a wip | 06:29 |
| rsalveti | the focus was more at compiz, because it needed the extra big patch | 06:29 |
| didrocks | right ;) let's figure unity out now | 06:29 |
| didrocks | if there is an option to enable for unity on armhf, we can do that | 06:29 |
| rsalveti | yup | 06:29 |
| didrocks | (as anyway, before, it was simply useless on that arch) | 06:29 |
| rsalveti | yeah | 06:30 |
| pitti | my evo-exchange upload reverts the previous upload which can't possibly work (FTBFS) | 06:36 |
| pitti | review appreciated | 06:37 |
| pitti | infinity: if you have a sec, can you please look at evolution-exchange? | 06:40 |
| pitti | wrt. http://people.canonical.com/~ubuntu-archive/testing/precise_outdate.html, I pinged ev about whoopsie, uploaded fix for evo-exchange, retried network-manager (arch skew), and compiz is needs buildl | 06:41 |
| pitti | and ran NBS for the old linux bits | 06:42 |
| pitti | didrocks: compiz built everywhere (in precise) | 06:43 |
| pitti | didrocks: when that's published, does it make any sense to retry unity, or are you still figuring that out? | 06:43 |
| didrocks | pitti: I don't think so, as the diff of the FTBFS I showed before was with the new compiz (and the armel patch was already here) | 06:44 |
| rsalveti | pitti: not yet, it'll fail | 06:44 |
| didrocks | so, two choices from here: | 06:44 |
| rsalveti | hm, got the following now: | 06:44 |
| pitti | ok, so we'll either need a new unity, or revert compiz? | 06:44 |
| didrocks | - either rsalveti enabled the right option in upstream unity | 06:44 |
| rsalveti | /home/linaro/compiz/unity-5.8.0/plugins/unityshell/src/unityshell.cpp:610:2: error: #warning Panel shadow not properly implemented for GLES2 [-Werror=cpp] | 06:44 |
| didrocks | and this work | 06:44 |
| didrocks | - either my ppa test build shows that the armel patch is guilty (compiz is still building) and we revert the armel patch | 06:44 |
| didrocks | I think everyone will prefer #1 | 06:44 |
| pitti | ok, I'll let you guys figure this out | 06:45 |
| * pitti toddles off for a bit | 06:45 | |
| didrocks | ironically this means that for a week, we couldn't rebuild unity if we needed due to the compiz armel patch ;) | 06:45 |
| didrocks | rsalveti: your warning is happening with the opengles option enabled? | 06:46 |
| rsalveti | yup, and it's part of the code | 06:46 |
| rsalveti | but it's failing because of -Werror | 06:46 |
| rsalveti | so I believe this is expected | 06:47 |
| didrocks | yeah, we try to keep the source cleaned :) | 06:47 |
| didrocks | rsalveti: any progress? | 07:03 |
| rsalveti | didrocks: still building | 07:03 |
| didrocks | ok, unity's story ;) building builing ;) | 07:03 |
| rsalveti | didrocks: check bug 980544 | 07:10 |
| ubot2 | Launchpad bug 980544 in unity "Unity should be built with OpenGL ES2.0 support at ARM " [High,In progress] https://launchpad.net/bugs/980544 | 07:10 |
| rsalveti | didrocks: added a debdiff with the packaging changes there | 07:10 |
| rsalveti | and finally got it to build here | 07:10 |
| rsalveti | with gles we need to use -DDISABLE_MAINTAINER_CFLAGS=ON | 07:10 |
| didrocks | rsalveti: ok, so no additional patch, what about the warning you had? | 07:11 |
| didrocks | ah | 07:11 |
| rsalveti | because it's not completely implemented | 07:11 |
| didrocks | you disbale maintainer cflags | 07:11 |
| didrocks | so no Werror | 07:11 |
| didrocks | fine with me anyway, as its on arm only :) | 07:11 |
| didrocks | it's* | 07:11 |
| rsalveti | yeah | 07:11 |
| didrocks | rsalveti: need sponsoring? | 07:11 |
| rsalveti | arm/gles support is kind of experimental at this phase, so should be fine | 07:11 |
| rsalveti | didrocks: yup | 07:11 |
| didrocks | doing then | 07:11 |
| rsalveti | didrocks: thanks | 07:12 |
| didrocks | (just changing debian/changeog to target -proposed) | 07:12 |
| rsalveti | sure | 07:12 |
| didrocks | ah, rejection before you didn't pick the last changelog, fixing that :) | 07:12 |
| rsalveti | there's a new release on proposes, right? | 07:13 |
| rsalveti | proposed | 07:13 |
| didrocks | yeah ;) | 07:13 |
| didrocks | done, no worry! | 07:13 |
| rsalveti | great, thanks | 07:13 |
| didrocks | thank to you for the quick look :) | 07:14 |
| rsalveti | np | 07:14 |
| didrocks | pitti: available and waiting approval ^ | 07:21 |
| pitti | wohoo | 07:21 |
| pitti | ok, looks like a no-change for x86 | 07:22 |
| didrocks | indeed | 07:22 |
| pitti | didrocks: I guess I should wait until compiz is published everywhere in precise? or does it have b-deps? | 07:22 |
| pitti | (still pending publishing on armhf and i386) | 07:23 |
| didrocks | pitti: maybe better to wait, the armel patch changed. I know there is no ABI change for x86, but as we saw, the armel diff is big ;) | 07:23 |
| pitti | ok, I'll better wait | 07:23 |
| infinity | pitti: evo-exchange is straightforward enough. | 07:39 |
| ogra_ | didrocks, ouch, i was somewhat relying on upstream to include an arch sepcific default when they included the patch, sorry | 08:19 |
| didrocks | ogra_: no worry, all sorted out now :) | 08:19 |
| didrocks | ogra_: but this whole arm story hasn't been painless ;) | 08:19 |
| ogra_ | yeah, i see, thanks so much and sorry again | 08:19 |
| ogra_ | didrocks, no, it hasnt, thats why i asked for having all patches ready by last UDS so we could have them in before A1 :P | 08:20 |
| ogra_ | well, at least we'll have it in Q | 08:20 |
| ogra_ | from the beginning | 08:20 |
| didrocks | ogra_: yeah, it's just the timing which made it worse… but well, it's in now, let's hope that the story in Q will be better :) | 08:20 |
| didrocks | right! | 08:20 |
| jamespage | has final freeze been announced yet? piloting this morning and want to ensure that I'm focussed on the right things... | 08:47 |
| pitti | didrocks: ok, compiz is published, accepting unity | 08:56 |
| didrocks | pitti: sweet! | 08:56 |
| * pitti bumps build score | 08:56 | |
| RAOF | We're not in final freeze yet, right? | 08:57 |
| pitti | we are supposed to be | 08:57 |
| RAOF | Shall someone update the topic in #ubuntu-devel, then? | 08:58 |
| * ogra_ guesses once kate gets up we are | 08:59 | |
| ogra_ | RAOF, there was no official announcement yet | 08:59 |
| ogra_ | (unless i missed it) | 08:59 |
| pitti | cjwatson: should we move linux-ti-omap4 from -proposed to release, or do you want to stage d-i in -proposed for that as well? | 09:01 |
| RAOF | Ok :) | 09:01 |
| pitti | RAOF: in practice we've been frozen for a week already anyway | 09:01 |
| RAOF | Right, but final freeze changes whether or not I upload this xxi-synatpics | 09:02 |
| ogra_ | RAOF, -proposed is open as well ;) | 09:02 |
| Daviey | maas-enlist incoming, basically a Arch s/all/any change. My upload, please can someone else review. | 09:16 |
| Daviey | (also accept the bin NEW's) | 09:17 |
| pitti | didrocks: meh @ unity armhf FTBFS :/ | 09:19 |
| pitti | OPENGL_gl_LIBRARY (ADVANCED) | 09:19 |
| didrocks | rsalveti: ^ | 09:19 |
| pitti | not found | 09:19 |
| pitti | missing build dep? | 09:20 |
| didrocks | rsalveti: any special build-dep for opengles? | 09:20 |
| didrocks | rsalveti: the compiz-dev and nux are supposed to provide everything | 09:20 |
| didrocks | pitti: ^ | 09:20 |
| didrocks | ogra_: maybe you have a clue on this stack | 09:20 |
| pitti | didrocks: we'll keep control-center in -proposed until unity and -2d are released, right? | 09:21 |
| didrocks | pitti: yeah, because it's using an unity-2d new gsettings key | 09:21 |
| didrocks | so will crash without it | 09:21 |
| didrocks | I didn't want to put an explicit dep or breaks just for that | 09:22 |
| pitti | right, that's what I meant | 09:22 |
| didrocks | pitti: ok, I'm not found of to have unity stalled on proposed forever. The deal was that if arm fails because of the linaro patch, we can go ahead and they have to fix it | 09:23 |
| didrocks | pitti: if it's not fixed in one hour, should we revert all the linaro changes? | 09:23 |
| pitti | didrocks: WFM | 09:23 |
| didrocks | ogra_: in case you didn't see ^ | 09:24 |
| ogra_ | i did have a reconnect | 09:24 |
| ogra_ | seems i miss the beginning | 09:24 |
| infinity | You didn't give people much chance to respond. :P | 09:24 |
| * ogra_ just noticed that lubuntu-desktop doesnt have armhf support at all :/ | 09:24 | |
| ogra_ | didrocks, whats the issue ? how can i help ? | 09:25 |
| infinity | ogra_: At a quick glance, it looks like compiz-dev is missing dependencies. | 09:25 |
| ogra_ | hmm, it shouldnt, i used the linaro branches for the deps ... | 09:26 |
| infinity | Though, maybe not.. | 09:26 |
| * ogra_ downloads the source package | 09:26 | |
| didrocks | OPENGL_gl_LIBRARY (ADVANCED) | 09:26 |
| didrocks | ogra_: it's unity which FTBFS | 09:26 |
| ogra_ | hmpf | 09:27 |
| infinity | Kay, compiz-dev's deps are fine. | 09:27 |
| infinity | So, it's the CMake test that's wrong, I assume. | 09:27 |
| didrocks | yeah, can be the CMake one I guess | 09:27 |
| * tumbleweed hopes we get a name for Q soon | 09:29 | |
| infinity | Or is the GLES support in Unity not mutually exclusive with GL? If so, then it just needs libgl1-mesa-dev installed too. | 09:29 |
| ogra_ | no. it should have the same !armhf/armhf setup as compiz | 09:29 |
| infinity | ogra_: Kay, then I contend that the CMake test is wrong, and probably looking for libgl unconditionally, even if the source doesn't need it when building for EGL. | 09:30 |
| ogra_ | right | 09:30 |
| infinity | pitti: I see no advantage in leaving the ti-omap kernel in -proposed... | 09:31 |
| infinity | pitti: We kinda want it for image builds too. | 09:31 |
| pitti | infinity: right, but it's an ABI bump, so needs to go along with a d-i upload and seed changes | 09:32 |
| infinity | pitti: Yeahp. | 09:32 |
| * ogra_ pinged alf, i think he has a unity packaging branch somewhere | 09:33 | |
| didrocks | ogra_: keep us posted, I wanted to have feedback on the upgrade before the week-end, but I guess this won't happen :( | 09:35 |
| ogra_ | didrocks, lets see ... i found the linaro packaging branch, doesnt seem it touches any cmake stuff nor deps | 09:36 |
| ogra_ | didrocks, hmm, are all compiz builds published already ? could be that compiz-dev is to old | 09:39 |
| pitti | yes, I waited for that | 09:39 |
| ogra_ | (seems the versioned dep is outdated) | 09:40 |
| ogra_ | ok | 09:40 |
| didrocks | ogra_: well, it's not a versioned dep because there is no ABI change | 09:40 |
| didrocks | at least on i386/amd64 not sure what happened on arm | 09:40 |
| ogra_ | GLES support was added ... i reflected that in the versioned dep in compiz-dev but indeed not in unity | 09:41 |
| ogra_ | but if compiz is up to date that doesnt matter anyway | 09:41 |
| infinity | Well, you can tell from the build log if it was. | 09:41 |
| didrocks | ogra_: right | 09:41 |
| infinity | (and it was) | 09:43 |
| ogra_ | AHA ! | 09:45 |
| ogra_ | http://bazaar.launchpad.net/~linaro-maintainers/unity/overlay/revision/20 | 09:45 |
| ogra_ | "Disable standalone-clients as it forces opengl (testing related)" | 09:45 |
| didrocks | ogra_: so we will need your quilt hack | 09:46 |
| ogra_ | yup, looks like | 09:46 |
| didrocks | for arm only | 09:46 |
| didrocks | ogra_: I can give it a try, but not build to confirm | 09:46 |
| didrocks | apart from pushing to a ppa | 09:47 |
| ogra_ | right, let me make sure thats the only missing thing first though | 09:47 |
| didrocks | yep | 09:47 |
| ogra_ | did you plan to have that -proposed upload in the release ? | 09:47 |
| didrocks | ogra_: what do you mean? | 09:48 |
| ogra_ | or is that a zero day update ? | 09:48 |
| didrocks | ogra_: oh, it's in the release | 09:48 |
| ogra_ | ok | 09:48 |
| ogra_ | just wanted to know about the time pressure ;) | 09:48 |
| didrocks | well, I guess it's high :p I rushed to get everything in shape yesterday evening | 09:48 |
| didrocks | and hoped I can have a quiet Friday :p | 09:49 |
| ogra_ | yeah | 09:49 |
| didrocks | but pinged 5s after connection because of arm :( | 09:49 |
| ogra_ | i only noticed it was uploaded to -proposed | 09:49 |
| ogra_ | so i thought i'd better ask | 09:49 |
| didrocks | ogra_: yeah, please upload with -v also | 09:49 |
| didrocks | (to include the 2 previous ones) | 09:49 |
| ogra_ | anyway, doesnt look like there is anything in the linaro branch that touches any other cmake stuff | 09:50 |
| didrocks | so that bugs are closed when syncing | 09:50 |
| ogra_ | so i guess that patch is it, let me add the quilt stuff and to an armel testbuild | 09:50 |
| didrocks | great ;) | 09:50 |
| infinity | ogra_: Please do test locally in a clean chroot before uploading another FTBFS. ;) | 09:50 |
| ogra_ | infinity, indeed :P | 09:50 |
| === debfx_ is now known as debfx | ||
| cjwatson | slangasek: gksudo> you could use something like ubiquity's wrapper that tries to escalate using whatever means is available | 10:13 |
| cjwatson | pitti: no point staging d-i in -proposed for ti-omap4, we should just move it | 10:13 |
| pitti | cjwatson: ack, doing that then | 10:13 |
| ogra_ | gah, ricardo made his -Werror dircetly in the code | 10:22 |
| ogra_ | +change | 10:22 |
| * infinity notes that doing all the proposed->release copies as syncs makes pitti looks very active on -changes... | 10:23 | |
| pitti | I hope in the not too distant future that's going to be done by a bot :) | 10:23 |
| didrocks | what? pitti isn't a bot? how can he possibly achieve that much work then? ;) | 10:26 |
| ogra_ | phew, finally building ... | 10:29 |
| ogra_ | and passed the error :) | 10:29 |
| didrocks | sweet, let's wait for it to successfully finish building | 10:29 |
| ogra_ | indeed :) | 10:29 |
| ogra_ | didrocks, do you think we could disable -Werror across the board for the release ? seemingly that option leaves me with a modified Cmake setup, so dpkg-source complains about upstream changes when trying to roll a source package on arm | 10:51 |
| didrocks | ogra_: I prefer keeping -Werror for non arm if possible (and so, please ask linaro to fix the arm case), it saved us from some issues that happened in the pasts | 10:53 |
| ogra_ | ok | 10:53 |
| ogra_ | i dont think its that important :) | 10:54 |
| didrocks | ogra_: TBH, dpkg-source should already complain when I'm cherry-picking patches from upstream, it just enables us to see what files are touched ;) | 10:55 |
| didrocks | (I bzr merge upstream-branch in packaging branch) | 10:56 |
| ogra_ | didrocks, i pushed my changes (UNRELEASED yet) to lp:~ubuntu-desktop/unity/ubuntu/ ... so you could start a PPA build i suppose if you want | 10:58 |
| ogra_ | oh crap ! | 10:58 |
| didrocks | hum? | 10:58 |
| ogra_ | failed | 10:58 |
| didrocks | ah :( | 10:58 |
| didrocks | ogra_: aren't the linaro guys around to help us on this? | 10:59 |
| ogra_ | apparently not | 10:59 |
| didrocks | I'm just about considering reverting if that can't be fixed | 10:59 |
| ogra_ | alf is greek ... its good friday in the greek chruch today | 10:59 |
| didrocks | pitti: wdyt? ^ | 10:59 |
| * ogra_ found another patch ... gimme a sec | 10:59 | |
| didrocks | ok | 10:59 |
| ogra_ | ah, no, seems unrelated | 11:00 |
| ogra_ | didrocks, would you keep my package changes but drop the patch ? that way we can easily SRU a new patch in ... | 11:01 |
| didrocks | ogra_: I want the release team to agree first, but yeah, dropping the patch and the custom .install file in compiz should be enough, right? | 11:02 |
| ogra_ | didrocks, err, why compiz ? | 11:02 |
| ogra_ | compiz is fine | 11:02 |
| ogra_ | i'm only talking about unity, i would like to have the package prepared as well as we can so i only need to dump that single quilt patch in | 11:03 |
| didrocks | ogra_: no, it's compiz on arm which doesn't provided the opengl-es dep | 11:03 |
| didrocks | ogra_: you are talking about the revert first, right? | 11:03 |
| ogra_ | i'm only talking about unity | 11:03 |
| didrocks | ogra_: right, but basically, since you landed the compiz patch a week ago, we can't build unity on armel | 11:03 |
| ogra_ | if there need to be fixes in compiz i would prefer to keep them as small as possible ... as long as it builds it wont do no harm | 11:04 |
| didrocks | because compiz is providing opengles build-dep | 11:04 |
| didrocks | so unity has opengles build-dep only on arm | 11:04 |
| ogra_ | it doesnt build if you revert the changes ricardo made ? | 11:04 |
| ogra_ | hmpf | 11:04 |
| didrocks | ogra_: no, ricardo did those changes because it FTBFS | 11:04 |
| ogra_ | right, that was the bit of the conversation i missed above | 11:04 |
| * ogra_ curses loudly | 11:05 | |
| didrocks | so that would mean: reverting compiz and c-p-m | 11:05 |
| didrocks | the arm part | 11:05 |
| ogra_ | yeah, thats a very bad idea | 11:05 |
| didrocks | well, unity can't build for a week since those patches were introduced into ubuntu | 11:05 |
| didrocks | (on arm) | 11:06 |
| ogra_ | you didnt tell me ... i thought all was fine (though i also though the unity changes were in since ages since i was told everything for this was done upstream and we wouldnt need to care) | 11:06 |
| didrocks | ogra_: well I didn't know until this morning, remember that you uploaded it in the archive whereas we were testing a newer version in the ppa? :) | 11:07 |
| ogra_ | yeah | 11:07 |
| didrocks | so we never got the issue until this morning | 11:07 |
| ogra_ | didrocks, do you mind if we wait until ricardo gets up again, probably he has an easy fix in the drawer | 11:07 |
| didrocks | ogra_: let's see with the release team | 11:07 |
| didrocks | I was hoping getting feedback on the new release today | 11:07 |
| ogra_ | it survives 80% of the build and fails in a single declaration atm | 11:08 |
| didrocks | but seems that despite rushing and working like mad yesterday, it's not possible | 11:08 |
| didrocks | or we can as well declare the armel image failing to build this week-end | 11:08 |
| didrocks | and copying to the release pocket for now | 11:08 |
| ogra_ | i'm really sorry for that, i hinestly was 100% convinced we dont need to touch the unity package at all | 11:08 |
| ogra_ | i dont think LP allows that ... we had a similar issue in B2 | 11:09 |
| didrocks | ogra_: no worry, I would have prefered that linaro gave the patch to you sooner and not at the last minute ;) | 11:09 |
| didrocks | ah? | 11:09 |
| ogra_ | you need to copy over all arches or you lose | 11:09 |
| didrocks | ok | 11:09 |
| ogra_ | intrestingly the build seems to fail in a nux function | 11:10 |
| ogra_ | hmm, how did libglu1-mesa end up in the chroot, that cant work | 11:11 |
| ogra_ | seems the former nux version pulled that in | 11:12 |
| * ogra_ retires the build | 11:13 | |
| ogra_ | *retries | 11:13 |
| ogra_ | :) | 11:13 |
| didrocks | both were valid :p | 11:14 |
| ogra_ | haha | 11:14 |
| didrocks | ogra_: https://code.launchpad.net/~linaro-graphics-wg/unity/fix-gles2-build/+merge/101087 | 11:18 |
| * ogra_ looks | 11:18 | |
| didrocks | I saw that patch pending, told to ricardo this morning that some patchs were not approved (as we agreed) in unity and he answered that nothing was pending for him | 11:18 |
| * ogra_ hugs didrocks, thats the one | 11:18 | |
| ogra_ | well, at least thats the file it failed in | 11:19 |
| didrocks | ogra_: testing with it? ;) | 11:19 |
| didrocks | ok, let's cross fingers | 11:19 |
| ogra_ | not yet, let me add it | 11:19 |
| didrocks | ogra_: you can bzr merge it directly | 11:19 |
| ogra_ | k | 11:19 |
| didrocks | (as it's an ifdef) | 11:19 |
| didrocks | it that works, I'll accept it upstream, even if that's not what we agreed on first :/ | 11:20 |
| ogra_ | yeah, pretty much nothing is ... | 11:20 |
| ogra_ | building again | 11:22 |
| pitti | didrocks: I don't think we can copy unity to precise without completely breaking arm, can we? | 11:37 |
| ogra_ | not if the binaries are missing, no | 11:37 |
| didrocks | pitti: no, we can't, let's hope that the branch I pointed ogra too will fix it | 11:37 |
| pitti | right, we'd potentially end up releasing with NBS | 11:37 |
| ogra_ | will break -desktop deps | 11:37 |
| * ogra_ is confident the patch will make it work | 11:38 | |
| pitti | I think we should upload a reversion of compiz, then build unity against it, move both to release | 11:38 |
| pitti | and then we can re-stage compiz/unity with gles in -proposed | 11:38 |
| ogra_ | build is at 34% | 11:38 |
| didrocks | pitti: it's compiz, compiz-plugins-main, nux and then unity | 11:38 |
| ogra_ | pitti, that measn SRUing a 300-400k patch | 11:38 |
| didrocks | so not that straightforward :) | 11:38 |
| ogra_ | *means | 11:38 |
| ogra_ | i would love to avoid that | 11:38 |
| pitti | well, if you SRU something that jst enables a 300 k patch in debian/patches/series, the net effect is the very same | 11:39 |
| pitti | SRUs are bound by regression potential, not primarily by patch size (although the two certainly correlate) | 11:39 |
| ogra_ | its also package changes that have to be reverted across the chain ... | 11:39 |
| ogra_ | (and re-enabled for the SRU) | 11:39 |
| pitti | well, other suggestions appreciated | 11:40 |
| didrocks | pitti: I pointed ogra to an unity patch that can help | 11:40 |
| pitti | but we are supposed to have a releasable image since today, and right now we don't | 11:40 |
| ogra_ | i would really prefer to get it into a building state now ... keep possible fixes for SRUs then | 11:40 |
| didrocks | pitti: even if the first deal was linaro was "only compiz and c-p-m" | 11:40 |
| ogra_ | but reverting the world is hell | 11:40 |
| didrocks | but it seems they broke the deal | 11:40 |
| didrocks | which doesn't really make me happy about how hard they pushed it and how they delivered it | 11:41 |
| pitti | so, if the gles-enabled unity can be made to work this afternoon, sure, but it doesn't currently look like we'd have a robust and solid plan for that | 11:41 |
| didrocks | but that's another story | 11:41 |
| ogra_ | right, deal was no ifdefs and package changes for unity and nux ... but we cant change that now | 11:41 |
| pitti | this really sounds like something which ought to be staged up in -proposed without blocking the current release | 11:41 |
| didrocks | pitti: 13:40:30 didrocks | pitti: I pointed ogra to an unity patch that can help | 11:41 |
| pitti | we could also release precise with unity 5.8, but I'm not sure folks would be happy about that | 11:42 |
| didrocks | it's building right now | 11:42 |
| ogra_ | pitti, how long is your definition of afternoon ;) | 11:42 |
| ogra_ | build is at 38% | 11:42 |
| ogra_ | should be done soon | 11:42 |
| pitti | ogra_: given that the stuff needs a couple of hours to build, we should get it in before release team meeting IMHO | 11:42 |
| ogra_ | (if it survives) | 11:42 |
| ogra_ | pitti, its only unity itself | 11:43 |
| ogra_ | wont need a couple of hours | 11:43 |
| pitti | not if we need to revert compiz/c-p-m/nux/whatever, too | 11:43 |
| ogra_ | oh, you mean the reverting | 11:44 |
| * ogra_ was thinking positive :) | 11:44 | |
| pitti | well, that's like the third or fourth patch we are trying now; if it works now, fine, but none of this sounds very reliable TBH | 11:45 |
| pitti | the result will not have been tested _at all_ | 11:45 |
| ogra_ | doesnt matter ... if we revert the patches it segfaults completely | 11:45 |
| ogra_ | these patches are all arm only on which without the patches unity doesnt work at all | 11:45 |
| pitti | so whichever solution gets us a working unity stack in precise by EOD | 11:45 |
| ogra_ | great | 11:45 |
| cjwatson | hm, http://qa.ubuntuwire.com/ftbfs/ doesn't seem to be answering me | 11:47 |
| * ogra_ noticed that last night already but thought it was my side since i had LAN issues | 11:47 | |
| infinity | pitti: I'm pretty unhappy about the current state too, but reverting will leave ARM just as broken. We could copy everything (despite the missing ARM binaries), and let the next upload sort it out. | 11:49 |
| infinity | It's not like we care about ever having the current version build on ARM (cause it can't). | 11:49 |
| pitti | infinity: that would introduce NBS again | 11:50 |
| pitti | err, what? unity always built on arm before | 11:50 |
| ogra_ | the unity build takes 1h ... i'm 50% through ... | 11:50 |
| ogra_ | lets just see if it finishes | 11:50 |
| didrocks | it built but never started as there is no opengl capable hw, right? | 11:50 |
| infinity | No, I mean the current version won't build, so copying it won't hurt (cause it won't magically build later). | 11:50 |
| ogra_ | pitti, it built but wasnt executable | 11:50 |
| pitti | infinity: right, hence introducing NBS | 11:51 |
| infinity | And yeah, what ogra said. | 11:51 |
| infinity | pitti: NBS on one arch for a day isn't world-ending, surely. | 11:51 |
| pitti | well, _I_ won't copy it | 11:51 |
| infinity | pitti: The concern for !arm seems to just be having the whole stack in and working, no? | 11:51 |
| pitti | just about the last thing I want to do at this point is deliberately introducing archive breakage and broken image builds | 11:51 |
| infinity | Whereas, for ARM, it's either broken, or broken, or we fix it. :P | 11:51 |
| infinity | (ie: reverting just takes it from broken to broken, for the sake of archive tidyness) | 11:52 |
| pitti | arm images curretnly have unity-2d workign, and this is also blocking unity-2d, gnome-control-cetner, and nux for precise | 11:52 |
| infinity | The only real option is fixing it. | 11:52 |
| pitti | it's not as simple as "make it work on arm" | 11:52 |
| * ogra_ thinks it is as simple as "get that next upload to build" | 11:53 | |
| infinity | Yeah. | 11:53 |
| pitti | ogra_: FSVO "simple".. | 11:53 |
| pitti | infinity: reverting the compiz/cpm uploads and uplaoding the unity that was actually tested is a real option | 11:55 |
| didrocks | at least, I confirm it's what worked on the ppa | 11:55 |
| infinity | And nux. | 11:55 |
| didrocks | right, nux in addition now | 11:55 |
| infinity | pitti: That all takes a lot longer than just hunting down what's broken, I suspect. | 11:56 |
| didrocks | pitti: well, you mean, reverting the arm part of compiz/cpm, isn't it? | 11:56 |
| pitti | infinity: *shrug*, given that several people desperately fight with this problem for at least 7 hours now.. | 11:56 |
| infinity | (And isn't dealing with breakage half the point of staging in -proposed?) | 11:56 |
| pitti | sure | 11:57 |
| pitti | but I disagree that it's ok to copy it to precise at this point | 11:57 |
| infinity | Sure, so don't. | 11:57 |
| pitti | so if we don't revert, and don't get this to work, we'll just release with 5. | 11:57 |
| pitti | 5.8 | 11:57 |
| infinity | That's the part I don't follow. | 11:57 |
| pitti | and I'd rather relelase with 5.10 | 11:57 |
| infinity | We release in 15 days. Holding up this pocket copy for a day doesn't magically make the world explode. | 11:58 |
| pitti | as that also unblocks a few other things, including UIFEs | 11:58 |
| pitti | and has been tested in the PPA | 11:58 |
| * infinity notes that it hasn't build on PPC either... | 12:00 | |
| infinity | built* | 12:01 |
| pitti | didrocks: is the current (precise) unity 5.8.0-0ubuntu2 even buildable with the new compiz that's in precise? | 12:04 |
| didrocks | pitti: no, that's what I told above ^ | 12:04 |
| pitti | ok, that's what I figured | 12:04 |
| didrocks | pitti: my bet is that since last Friday and the compiz upload that was done unnoticed why we were testing the new version, it's not buildable | 12:05 |
| didrocks | but I never tried, we always had the newer version in the ppa | 12:05 |
| didrocks | it's 90% sure it's not (if not more) | 12:05 |
| ogra_ | ok, its in unitydialog ... i think i'm past the last failure | 12:13 |
| * ogra_ crosses fingers for the last 25% to go | 12:14 | |
| ogra_ | dh_builddeb | 12:20 |
| ogra_ | dpkg-deb: building package `unity' in `../unity_5.10.0-0ubuntu2_armhf.deb'. | 12:20 |
| ogra_ | dpkg-deb: building package `unity-services' in `../unity-services_5.10.0-0ubuntu2_armhf.deb'. | 12:20 |
| ogra_ | dpkg-deb: building package `unity-common' in `../unity-common_5.10.0-0ubuntu2_all.deb'. | 12:20 |
| ogra_ | .... | 12:21 |
| ogra_ | DONE ! | 12:21 |
| pitti | ogra_: \o/ | 12:21 |
| ogra_ | didrocks, could i ask you to roll the new package i'm scared i'll catch the wrong branches again or some such | 12:21 |
| ogra_ | i merged the linaro patch and all my patches and pushed everything to lp:~ubuntu-desktop/unity/ubuntu/ | 12:22 |
| didrocks | ogra_: ok, looking | 12:23 |
| seb128 | ogra_, switch to v3 format ... is that needed? | 12:23 |
| ogra_ | tellk me if i did anythign wrong | 12:24 |
| ogra_ | seb128, yes, for the subarch specific patching | 12:24 |
| seb128 | ogra_, it creates issues with cherrypick done with bzr merge for sources like dx ones | 12:24 |
| ogra_ | it needs full quilt support | 12:24 |
| seb128 | not cool :-( | 12:24 |
| didrocks | yeah, not cool :/ | 12:24 |
| didrocks | we wanted to avoid v3 | 12:24 |
| * ogra_ wanted to avoid touching unity ... sorry | 12:24 | |
| didrocks | ogra_: don't you want to do the same trick than with compiz? | 12:25 |
| ogra_ | if you can make quilt properly work with dh_quilt_patch/unpatch another way, please revert | 12:25 |
| didrocks | ah you need | 12:25 |
| seb128 | ogra_, debian/patches/series.armel@ .. is the "@" right there? | 12:25 |
| didrocks | why v3 is needed then? | 12:26 |
| ogra_ | didrocks, yeah, it is the exact same thing | 12:26 |
| didrocks | seb128: yeah, symlink | 12:26 |
| ogra_ | seb128, yes, it links to armhf | 12:26 |
| seb128 | oh ok | 12:26 |
| didrocks | but a build-dep on quilt and dh --with quilt should be enough, isn't it? | 12:26 |
| seb128 | didrocks, ogra_: thanks ;-) (learning every day) | 12:26 |
| didrocks | without v3? | 12:26 |
| ogra_ | didrocks, hmm, not sure, does that properly trigger debhelpers scripts ? | 12:27 |
| didrocks | I think so | 12:27 |
| didrocks | ogra_: let me push something and tell me if that applies on bzr bd | 12:27 |
| ogra_ | all i need is that override_dh_quilt_patch/unpatch work | 12:28 |
| cjwatson | dh --with quilt will work with overrides | 12:28 |
| ogra_ | i didnt think thats doable without v3.0 ... if it is, i'm fine | 12:28 |
| cjwatson | if anything I'd have expected 3.0 (quilt) to make matters harder in this case, not easier | 12:28 |
| didrocks | yeah, it's called | 12:29 |
| ogra_ | then just revert the 3.0 stuff | 12:29 |
| didrocks | hum | 12:30 |
| ogra_ | issues ? | 12:30 |
| didrocks | yeah, dpkg-source complains about diff not serializable | 12:30 |
| didrocks | however, the changes are just in plugins/unityshell/src/DashController.cpp | 12:30 |
| didrocks | plugins/unityshell/src/OverlayRenderer.cpp | 12:30 |
| didrocks | services/CMakeLists.txt | 12:30 |
| didrocks | oh | 12:30 |
| didrocks | the symlink maybe? | 12:30 |
| ogra_ | i think its the first change from ricardo | 12:31 |
| didrocks | debian/patches/disable_standalone-clients.patch? | 12:31 |
| ogra_ | no, that one was in the source directly | 12:31 |
| ogra_ | before i added anything | 12:32 |
| didrocks | no, the issue was the symlink | 12:32 |
| ogra_ | seems configure ran before the tarball was rolled, i had complaints here as well and had to revert the changes that override_dh_gencontrol had produced | 12:32 |
| ogra_ | really ?!? | 12:32 |
| didrocks | yeah | 12:32 |
| * ogra_ has never had issues with symlinks in bzr | 12:33 | |
| ogra_ | weird | 12:33 |
| didrocks | ogra_: source 3 only? :p | 12:33 |
| cjwatson | 1.0 diffs don't support symlinks not in the original tarball, indeed | 12:33 |
| ogra_ | oh | 12:33 |
| * ogra_ echoes seb128 (learning every day) | 12:34 | |
| didrocks | ok, override_dh_quilt_unpatch and override_dh_quilt_patch are called | 12:34 |
| ogra_ | yay | 12:34 |
| ogra_ | cjwatson, i only had symlinks in the debian dir | 12:34 |
| infinity | ogra_: Right, "not in the original tarball". | 12:36 |
| didrocks | ogra_: pushed, do you want a last sanity check? (just start the build to ensure the patch is applied?) | 12:36 |
| infinity | ogra_: As in, diff.gz can't represent a symlink. | 12:36 |
| ogra_ | err | 12:36 |
| ogra_ | i missed the "not" :P | 12:36 |
| ogra_ | thanks for repeating ti for that old blind man :) | 12:37 |
| ogra_ | *it | 12:37 |
| infinity | (Though, I thought it just represented it as a dereferenced copy of the file...) | 12:37 |
| cjwatson | actually maybe it can, I'm sure I remember using symlinks in debian/ pre-3.0 | 12:37 |
| ogra_ | didrocks, pulling | 12:37 |
| cjwatson | yeah, don't take my word as gospel here, I don't have time to check properly right now | 12:37 |
| didrocks | dpkg-source yielled at me though ;) | 12:37 |
| didrocks | cjwatson: ^ | 12:37 |
| infinity | didrocks: I assume you just did a cp -a and called it good? :P | 12:38 |
| didrocks | infinity: bzr rm, cp -a and bzr add yeah, because bzr wasn't happy I cheated on a symlink :) | 12:38 |
| infinity | cjwatson: Actually, I'm betting the remembering symlinks pre-3.0 was always in native packages. | 12:39 |
| infinity | cjwatson: Cause there really is no way to sanely represent a symlink in pre-3.0 non-native. After the first pack/unpack, it would be a copy. | 12:39 |
| cjwatson | oh, could well be, yes | 12:39 |
| * ogra_ twiddles thumbs ... why is bzr so slow now | 12:39 | |
| infinity | (And I think dpkg just says "no" instead of giving you that confusing result) | 12:40 |
| cjwatson | yeah | 12:41 |
| * didrocks is just a dput away once ogra_ confirms the patch is applied on his armel system :) | 12:42 | |
| ogra_ | yeah, seems my pandas network connection is a bit unhappy, bzr pull takes a century here | 12:42 |
| ogra_ | didrocks, applies, i'll leave the build run so we can see weverthing is right | 12:45 |
| ogra_ | *everything | 12:45 |
| didrocks | \o/ | 12:45 |
| didrocks | ok, pushing | 12:45 |
| ogra_ | thanks for taking over that bit | 12:46 |
| didrocks | as I guess we don't want to wait on your build again :) | 12:46 |
| didrocks | ogra_: thanks for looking into the issue and trying the branch I pointed ;) | 12:46 |
| ogra_ | nah, just as additional measure :) | 12:46 |
| ogra_ | well, without you pointiing at it i would have given up | 12:46 |
| didrocks | ogra_: I'm forced to approve the branch upstream now :p | 12:46 |
| * ogra_ thinks there will have to be a lot beer flowing back and forth at UDS | 12:47 | |
| didrocks | heh, as usual, ;) | 12:47 |
| didrocks | pitti: ^ you maybe heard about that… an incoming unity fixing some issues on arm we might care about ;) | 12:51 |
| pitti | didrocks: no idea what you are talking about, I'll just reject it | 12:52 |
| didrocks | pitti: please do reject ;) | 12:52 |
| infinity | Oh look, langpack spam day. | 12:53 |
| pitti | at it | 12:53 |
| * infinity goes to update the i386 chroot to keep build times down. | 12:53 | |
| * pitti disables the automatic langpack cron job now; we'll get a fresh -base rebuild next Tuesday | 12:53 | |
| pitti | infinity: ok, cancelling my q accept run until you're done; thanks | 12:55 |
| ogra_ | yay, and lubuntu-desktop is finally installable on armhf | 12:55 |
| infinity | pitti: Nah, accept away. No point delaying. | 12:55 |
| pitti | ack | 12:55 |
| infinity | New chroot will be there in a few minutes. | 12:56 |
| * infinity gives allspice to i386. | 12:56 | |
| pitti | didrocks: do we need to reupload unity-2d for that, or is that fine? (ISTR that it build-deps on unity) | 13:00 |
| === bladernr_afk is now known as bladernr_ | ||
| didrocks | pitti: it doesn't, at east, I didn't spot an ABI break | 13:01 |
| didrocks | pitti: I'll test from proposed right now | 13:01 |
| pitti | cjwatson: want me to upload d-i for new l-ti-omap4, or are you already at it? | 13:01 |
| pitti | (and seeds) | 13:01 |
| cjwatson | pitti: go ahead, I've been working on a couple of other things | 13:02 |
| pitti | ack | 13:02 |
| cjwatson | looking into a workaround for bug 922949 | 13:02 |
| ubot2 | Launchpad bug 922949 in apt "installation process can crash due to an issue with one package when choosing "install updates" as part of the install" [High,Triaged] https://launchpad.net/bugs/922949 | 13:02 |
| infinity | pitti: I did the seeds. | 13:03 |
| infinity | pitti: I can do d-i too, if you like. | 13:03 |
| pitti | I don't mind much either way, it's mostly mechanical anyway | 13:04 |
| * infinity nods. | 13:04 | |
| pitti | flip a coin? | 13:04 |
| infinity | Heh. I'll do it in just a second. ;) | 13:05 |
| infinity | Just want to make sure I didn't break the world with the new i386 chroot. | 13:05 |
| infinity | World looks decidedly unbroken. | 13:08 |
| infinity | pitti: Uploaded. | 13:15 |
| pitti | cheers, will review in a bit | 13:15 |
| ScottK | Daviey: horizon just made component mismatches explode. You may want to have someone look into it. | 13:42 |
| ogra_ | didrocks, oh, just FYI, the other build is done too | 13:46 |
| didrocks | ogra_: nice to hear! Now let's wait a little bit less anxiously :) | 13:47 |
| ogra_ | yeah :) | 13:47 |
| ogra_ | infinity, oh, btw, did you change the omap4 cmdline in debian-cd yet (vram=40 ... and dropping the memory hole etc) | 13:50 |
| infinity | Did rsalveti file that bug for me and I missed it? | 13:53 |
| infinity | Dropping the memory hole can't be done until 3.3+, AIUI, it was just the vram bump we need for now... | 13:53 |
| infinity | (Which can also be dropped in 3.3+) | 13:53 |
| ogra_ | i dont think he filed any bug | 13:54 |
| ogra_ | i just remembered you had a conversation about it with him | 13:54 |
| infinity | Yeah, which ended in "file a bug so I don't forget". :P | 13:55 |
| ogra_ | if you didnt do it i'll make sure it happens before release | 13:55 |
| ogra_ | wforget it | 13:55 |
| ogra_ | *e just shouldnt forget ot | 13:55 |
| ogra_ | sigh, why is my system swallowing letters | 13:55 |
| ogra_ | whole words actually | 13:55 |
| infinity | If it's only debian-cd, it's a quick change. I'll do it right now. | 13:56 |
| infinity | I wasn't sure if it popped up in other places. | 13:56 |
| infinity | But I can't find it in flash-kernel. | 13:56 |
| infinity | So... | 13:56 |
| ogra_ | its in omap4_boot | 13:56 |
| ogra_ | flash-kernel shouldnt touch the cmdline (f-k-i should though, but we dont use it) | 13:56 |
| infinity | Oh, right, I meant to fix that. | 13:56 |
| infinity | Drat. | 13:56 |
| infinity | Not enough hours in the day. | 13:57 |
| infinity | For Q, I guess. | 13:57 |
| ogra_ | what ? | 13:57 |
| ogra_ | the cmdline fix ? | 13:57 |
| ogra_ | or f-k | 13:57 |
| infinity | Yeah, make f-k-i DTRT with custom command lines and such. | 13:57 |
| ogra_ | ah, k | 13:57 |
| infinity | Was just some caro-culting from grub-installer that I didn't get to, but I'm not going to do it now. | 13:58 |
| ogra_ | well, for preinstalled thats moot | 13:58 |
| ogra_ | since f-k isnt used for anything but mkimage there anyway ... | 13:58 |
| ogra_ | its debian-cd and jasper | 13:58 |
| ogra_ | but jasper only takes the existing cmdline and parses the serial and debconf bits out ... the rest is used unmodified ... so the change is debian-cd only | 13:59 |
| infinity | Right, I meant fixing f-k-i to actually do sensible things in the face of custom commandlines. :P | 13:59 |
| infinity | debian-cd is already fixed. | 13:59 |
| infinity | Well, when I commit. | 13:59 |
| ogra_ | well, lets revisit the "burn jasper" spec in Q | 14:00 |
| ogra_ | and actually implement the fixes we defined | 14:00 |
| ogra_ | f-k-i was one of the bits iirc | 14:00 |
| infinity | We might be getting dangerously close to just dropping preinstalled entirely. I dunno. | 14:00 |
| ogra_ | or that, yeah | 14:00 |
| ogra_ | which will still need f-k-i touching though | 14:01 |
| ogra_ | and i would still like to work on the "d-i as tarball installer" bit | 14:02 |
| ogra_ | (which is indeed more ac100 than preinstalled) | 14:02 |
| Daviey | ScottK: looking, thanks | 14:09 |
| cjwatson | sent the foundations report now, sorry that was late | 14:09 |
| cjwatson | ^- that's the reupload expected from last night | 14:17 |
| cjwatson | works around our oldest rls-p-tracking bug sufficiently to consider it closed for now, yay | 14:17 |
| ScottK | cjwatson: Does that include the Kubuntu changes too? | 14:18 |
| cjwatson | yes | 14:18 |
| ScottK | Cool. Thanks. | 14:19 |
| cjwatson | though I didn't verify against the rejected upload, it was what was in bzr | 14:19 |
| ScottK | That should be correct. The same person did both. | 14:19 |
| cjwatson | ok | 14:19 |
| brendand | skaet - no release meeting today? | 14:26 |
| ogra_ | brendand, in 30min, no ? | 14:26 |
| skaet | brendand, there's a release meeting today. 1500 GMT | 14:26 |
| skaet | brendand, can you please summarize in the meeting or in email, who each of the bugs you've listed as blockers is waiting on? | 14:49 |
| skaet | (ie. waiting on validation, waiting on fix - is what I'm trying to understand) | 14:50 |
| pitti | hey skaet | 14:50 |
| pitti | didrocks: so once unity is built in -proposed, do we need any other packages? | 14:51 |
| skaet | hiya pitti, just doing the pass through the weeklies to find out issues. | 14:51 |
| * skaet still sees we're pending unity builds... | 14:51 | |
| didrocks | pitti: no, everything should be fine, copy g-c-c, nux, unity, unity-2d | 14:52 |
| pitti | skaet: yeah, that was a bit of a pain, but should hopefully be good now | 14:52 |
| skaet | am thinking that once its build, recreating the images before tonight and seeing if we've got issues before the weekend would be prudent. | 14:52 |
| didrocks | and life will be beautiful ;) | 14:52 |
| pitti | didrocks: ack; just wanted to triple-check | 14:52 |
| pitti | skaet: *nod* | 14:52 |
| skaet | :) | 14:52 |
| * skaet likes tripple checking..... | 14:52 | |
| pitti | still waiting on powerpc, once again | 14:52 |
| pitti | (as we have done all day for flushing -proposed ...) | 14:52 |
| ScottK | I think it's been over three days since a Universe package got built on powerpc. | 14:54 |
| ScottK | Will the kde-workspace/qt4-x11 syncs that just showed up in the queue cause the packages to get rebuilt? | 14:58 |
| ScottK | That certainly isn't what we want. | 14:58 |
| pitti | no | 14:58 |
| pitti | they include binaries | 14:58 |
| ScottK | OK. | 14:59 |
| pitti | that's the very point of using -proposed, after all | 14:59 |
| pitti | I'm waiting until they built on all arches, then move them over | 14:59 |
| pitti | we got some 40 of them yesterday to update the .pot, I think | 14:59 |
| ScottK | Yes. Precisely my concern. The LP U/I gives no indication that the binaries are included. | 14:59 |
| ScottK | That was the reason. | 14:59 |
| pitti | it's exactly the same script as we use for releasing SRUs, FYI | 14:59 |
| pitti | (in case you are curious, it's sru-release in lp:ubuntu-archive-tools) | 15:00 |
| ScottK | Interesting. | 15:00 |
| ScottK | Does it still have to be run in the data center or can any archive admin run it? | 15:00 |
| pitti | ScottK: the latter | 15:02 |
| pitti | it's lplib | 15:02 |
| pitti | I don't use the DC at all any more for SRU work | 15:02 |
| ScottK | Interesting. | 15:02 |
| pitti | the new version cannot time out any more, as it's fully async | 15:02 |
| pitti | so we also process kernels that way now | 15:03 |
| pitti | ah, for them I do need DC access for change-override | 15:03 |
| ScottK | So I could do that for non-AA SRU people. | 15:03 |
| === bulldog98_ is now known as bulldog98 | ||
| cjwatson | ScottK: yep | 15:08 |
| slangasek | cjwatson: is that ubiquity escalation wrapper in a package that we could pull in? | 15:08 |
| cjwatson | slangasek: no | 15:08 |
| slangasek | ok | 15:08 |
| slangasek | I'm going to stand pat for .0 then :) | 15:08 |
| cjwatson | slangasek: you'd need to extract bits from lp:ubiquity bin/ubiquity-wrapper | 15:08 |
| cjwatson | and probably tweak | 15:08 |
| cjwatson | dunno if you need the tedious dbus and xauth munging | 15:09 |
| cjwatson | (actually not dbus) | 15:09 |
| === bladernr_ is now known as bladernr_afk | ||
| === bladernr_afk is now known as bladernr_ | ||
| rsalveti | didrocks: ogra_: I'm back | 15:18 |
| rsalveti | what is the extra change that needed to land at unity | 15:18 |
| ogra_ | rsalveti, to late, all fixed :P | 15:18 |
| didrocks | rsalveti: it's all sorted, seems I was right, a change was needed :p | 15:19 |
| rsalveti | seems my build worked fine because for some reason libgl1 was also included during the build | 15:19 |
| ScottK | ^^^ was me | 15:19 |
| ogra_ | rsalveti, the fix is already merged upstream by didrocks | 15:19 |
| rsalveti | then not causing the ftbfs while build the tests | 15:19 |
| ogra_ | yeah | 15:19 |
| ogra_ | i had a similar issue doing the testbuild here | 15:19 |
| rsalveti | let me check the changes | 15:19 |
| ogra_ | older nux had pulled in libgl1 to the chroot | 15:19 |
| rsalveti | which packages got changed? just unity? | 15:20 |
| ogra_ | yep | 15:20 |
| ogra_ | one quilt patch and one upstream fix additionally to your change | 15:20 |
| rsalveti | the upstream fix kinds of surprised me, I thought it was all in | 15:21 |
| ogra_ | it was a linaro merge request | 15:21 |
| rsalveti | oh, it was approved way back | 15:22 |
| ogra_ | apparently missed or late | 15:22 |
| rsalveti | just not merged | 15:22 |
| ogra_ | yeah | 15:22 |
| ogra_ | well, all done now, and i belive infinity also changed to vram=40 already | 15:22 |
| rsalveti | ogra_: removed the mem whole also? | 15:23 |
| ogra_ | so in tomorrows image unity should be testable | 15:23 |
| ogra_ | i think so ... | 15:23 |
| ogra_ | ask him ;) | 15:23 |
| rsalveti | ended up not opening I bug directly because I thought you'd do the changes :-) | 15:23 |
| rsalveti | but seems infinity did it all | 15:23 |
| ogra_ | we talked about both ... but i didnt check if he did it | 15:23 |
| rsalveti | ok | 15:23 |
| ogra_ | yeah, he was on it already, else i had done it | 15:23 |
| rsalveti | <infinity> Dropping the memory hole can't be done until 3.3+, AIUI, it was just the vram bump we need for now... | 15:24 |
| ogra_ | thats wrong | 15:24 |
| rsalveti | well, we're not going to get video decoding at all with this kernel | 15:24 |
| ogra_ | right | 15:24 |
| rsalveti | we don't have a compatible kernel and userspace for it | 15:24 |
| ogra_ | thats whys we want to drop it and keep the ram for the system | 15:25 |
| ogra_ | well, if there is anything missing i'll fix it, i know whats needed | 15:25 |
| ogra_ | no worries | 15:25 |
| rsalveti | ok :-) | 15:25 |
| pitti | unity built on all arches now, at last! | 15:26 |
| ogra_ | \o/ | 15:26 |
| ScottK | skaet: It was a mail to ubuntu-devel on stuff to discuss at UDS. | 15:26 |
| rsalveti | \o/ | 15:28 |
| === doko_ is now known as doko | ||
| pitti | cjwatson: just spoke with seb128; he and I can team up on Monday to work on a fix, if you think bug 942539 should be rls-p-tracking, ubuntu-12.04 milestoned, and all that | 15:42 |
| ubot2 | Launchpad bug 942539 in nautilus "Ubiquity desktop icon text looks messy" [Medium,Triaged] https://launchpad.net/bugs/942539 | 15:42 |
| pitti | it's certainly a visual wart | 15:42 |
| cjwatson | I think it should be, yes - it seems like it shouldn't be that intrusive a fix, once identified | 15:43 |
| seb128 | pitti, I've pinged upstream nautilus in case they have a clue where to start looking at it | 15:43 |
| pitti | cjwatson: yes, I agree; we basically need to teach it to not break on '.' unless followed by whitespace | 15:43 |
| cjwatson | thanks | 15:44 |
| ev | jdstrand: might I convince you to have a gander at bug https://bugs.launchpad.net/ubuntu/+source/syslinux-legacy/+bug/966135 ? | 15:44 |
| ubot2 | Launchpad bug 966135 in syslinux-legacy "[MIR] syslinux-legacy" [Undecided,New] | 15:44 |
| ev | there's candy and other delicious things inside | 15:44 |
| ev | pay no attention to ubot2 | 15:45 |
| seb128 | pitti, I fear it's not going to be "that easy", unicode text wrapping have lot of rules and can be complex, but let's see | 15:45 |
| jdstrand | ev: sure | 15:45 |
| ev | cheers | 15:45 |
| pitti | seb128, cjwatson: I updated the bug | 15:45 |
| seb128 | pitti, ok, I got a pointer for upstream, I'm looking at it | 15:46 |
| seb128 | pitti, http://git.gnome.org/browse/nautilus/tree/libnautilus-private/nautilus-icon-canvas-item.c#n1479 | 15:46 |
| seb128 | if (*p == '_' || *p == '-' || (*p == '.' && ZERO_OR_THREE_DIGITS (p+1))) { | 15:47 |
| seb128 | /* Ensure that we allow to break after '_' or '.' characters, | 15:47 |
| seb128 | * if they are not likely to be part of a version information, to | 15:47 |
| seb128 | * not break wrapping of foobar-0.0.1. | 15:47 |
| seb128 | * Wrap before IPs and long numbers, though. */ | 15:47 |
| seb128 | pitti, should be easy now that I know where to look at ;-) | 15:47 |
| pitti | ah, indeed | 15:47 |
| didrocks | oh great :) | 15:47 |
| pitti | http://people.canonical.com/~ubuntu-archive/testing/precise-proposed_probs.html | 15:53 |
| pitti | \o/ | 15:53 |
| pitti | all clear again | 15:53 |
| pitti | so, just waiting for the publisher to pick up the powerpc unity binary, then we can flush the lot | 15:54 |
| skaet | \o/ | 15:56 |
| pitti | and http://people.canonical.com/~ubuntu-archive/testing/precise_outdate.html is starting to look sane again, too | 15:56 |
| pitti | ev knows about that and is on it | 15:56 |
| * pitti flushes NBS | 15:57 | |
| rsalveti | infinity: jbicha: ogra_: I attached the debdiff for bug 935124, if it's still useful | 16:01 |
| ubot2 | Launchpad bug 935124 in gnome-shell "gnome-shell version 3.3.92-0ubuntu1 FTBFS on armhf in precise" [High,In progress] https://launchpad.net/bugs/935124 | 16:01 |
| jbicha | rsalveti: it's definitely useful, so it builds on ARM with that patch? | 16:01 |
| rsalveti | jbicha: yup | 16:02 |
| pitti | didrocks: do you want to have the honor of copying the stuff to -release? I fixed teh tool since the last time | 16:02 |
| ogra_ | does it run ? | 16:02 |
| ogra_ | or does it only fix the build failure | 16:02 |
| pitti | didrocks: (I can do it, just asking) | 16:02 |
| didrocks | pitti: let me do that, it's a nice way to finish the week! :) | 16:02 |
| * ogra_ cant imagine it runs without a lot more changes | 16:02 | |
| pitti | didrocks: it's sru-release -r precise unity unity-2d ... | 16:02 |
| didrocks | pitti: sweet! doing ;) | 16:03 |
| pitti | didrocks: mind the "-r" to copy to release instead of -updates | 16:03 |
| rsalveti | ogra_: I'm still to fully test it, but clutter/cogl is running and fixed for gles | 16:03 |
| pitti | didrocks: hold your horses | 16:03 |
| didrocks | yeah? | 16:03 |
| ogra_ | rsalveti, oh, cool ! | 16:03 |
| pitti | didrocks: still needs to be published, should be in a couple of mins | 16:03 |
| rsalveti | and the fixes I proposed at the debdiff are all from upstream | 16:03 |
| pitti | didrocks: https://launchpad.net/ubuntu/+source/unity/5.10.0-0ubuntu3 | 16:03 |
| didrocks | pitti: ok, just the time to finish an email then! ;) | 16:03 |
| pitti | didrocks: ppc is "accepted" | 16:03 |
| didrocks | looking | 16:03 |
| slangasek | skaet: verdict is in; we're changing the armhf PI to the new, really-really-agreed-upstream path | 16:03 |
| slangasek | skaet: so that's the glibc and gcc uploads we discussed earlier - infinity will drive | 16:04 |
| ogra_ | rsalveti, well, definitely SRU-worthy even if it wont make release | 16:04 |
| pitti | didrocks: the publisher starts at :03, and it should be published (in LP's mind) shortly after | 16:04 |
| rsalveti | ogra_: yeah | 16:04 |
| pitti | didrocks: (it does not actually need to be on archive.u.c., which takes some 30 mins) | 16:04 |
| didrocks | pitti: ok, just published on launchpad? | 16:04 |
| pitti | didrocks: yes, i. e. in the DB (not necessary to be on archive.u.c.) | 16:04 |
| didrocks | ok, thanks, will deal with that :) | 16:05 |
| pitti | didrocks: and there we go | 16:05 |
| * pitti waves the black-white flag | 16:05 | |
| ogra_ | wrooom | 16:05 |
| didrocks | go go go ;) | 16:06 |
| pitti | didrocks: wohoo! now go approve them | 16:08 |
| cjwatson | slangasek: so a symlink, and binaries built after the gcc change will use the new path? | 16:08 |
| didrocks | pitti: and done! :) | 16:08 |
| * pitti flushes two more | 16:09 | |
| * ogra_ hears the gurgling sound | 16:09 | |
| slangasek | cjwatson: yes | 16:09 |
| slangasek | cjwatson: and I guess we keep the symlink until 14.04 | 16:09 |
| cjwatson | presumably, and make sure everything gets rebuilt | 16:09 |
| slangasek | infinity: ^^ probably a good thing to notate in the source package.. | 16:10 |
| cjwatson | until *after* 14.04 | 16:10 |
| slangasek | yes | 16:10 |
| slangasek | cjwatson, jodh: so the plymouth change is a "temporary workaround" - this is the stopgap checking for the reference in the specific list before deallocing? | 16:11 |
| cjwatson | that's right | 16:11 |
| slangasek | ok | 16:11 |
| cjwatson | or indeed before doing anything with the event source | 16:11 |
| slangasek | you guys think that'll hold up? | 16:11 |
| cjwatson | it looks solid so far | 16:11 |
| slangasek | ok cool | 16:12 |
| slangasek | I guess the bug traffic will let us know if we're wrong | 16:12 |
| skaet | slangasek, infinity. understood. -proposed please. | 16:12 |
| jodh | slangasek: still investigating epoll semantics and adding instrumentation to plymouth... | 16:12 |
| slangasek | do we want to assume that all the other crashes are the same bug? | 16:12 |
| slangasek | skaet: definitely | 16:12 |
| slangasek | jodh: ack :) | 16:12 |
| cjwatson | anything that's a crash somewhere under ply_event_loop_process_pending_events that seems to be due to a bogus event source pointer is probably this | 16:13 |
| infinity | slangasek: We have no symlink to worry about. | 16:13 |
| slangasek | infinity: what now? /lib/arm-linux-gnueabihf/ld-linux.so.3 ? | 16:14 |
| infinity | slangasek: We install *all* our PIs to multiarch paths anyway, and then link from the compiler-derived location. | 16:14 |
| jodh | slangasek: adding in extra asserts, we see epoll_ctl calls failing and some of the errno handling is dubious, however we still can't yet pin down the exact cause. | 16:14 |
| slangasek | infinity: oh... so this is The Right Thing going forward anyway | 16:14 |
| slangasek | check | 16:14 |
| cjwatson | jodh: I'm still not entirely convinced that those epoll_ctl failures are causes rather than symptoms, though | 16:15 |
| infinity | slangasek: Now, this may take some wrangling in glibc once I do a couple of rounds of rebuilds and realise it's about to do something silly, but I'll find that out today. | 16:15 |
| slangasek | yep, understood | 16:15 |
| cjwatson | you'd see a failing epoll_ctl if it tried to remove a source that had already been removd | 16:15 |
| cjwatson | *removed | 16:15 |
| jodh | cjwatson: right - could well be, however the asserts fire pretty consistently - I can guarantee a crash within 2 invocations of plymouthd which is significant I think compared to what we were seeing yesterday. | 16:17 |
| cjwatson | so the question is whether that has anything to do with the bug, or just a spurious double-removal | 16:18 |
| ev | fixing the whoopsie unit tests on arm is going to have to spill over into the weekend / monday | 16:18 |
| pitti | good night everyone, have a nice weekend! | 16:19 |
| ev | pitti: and you! | 16:19 |
| didrocks | have a nice week-end pitti ;) | 16:21 |
| skaet | have good weekend pitti, thanks! | 16:21 |
| jodh | cjwatson: it's invalid on the very first call to ply_event_loop_remove_source_node(). | 16:21 |
| cjwatson | curious | 16:22 |
| cjwatson | jodh: so that sounds like something closing an fd before disconnecting the epoll source | 16:26 |
| jodh | cjwatson: confirmed its the source->fd that's invalid. will look for rogue closes... | 16:32 |
| slangasek | infinity: are you bumping shlibs for libc6, or how are you expressing the dependency on the new PI path for binaries built with the new gcc? | 16:33 |
| cjwatson | I tried a quick audit and it wasn't trivial to find; I wouldn't be confident we'd got them all | 16:33 |
| cjwatson | so I'm glad we have the workaround in place as insurance | 16:33 |
| cjwatson | slangasek: for that matter, how would we express that shlibs for binaries built between new gcc and new libc? | 16:33 |
| cjwatson | we might have to put armhf on manual for the duration ... | 16:34 |
| cjwatson | or perhaps do it all in a PPA | 16:34 |
| slangasek | cjwatson: if it's via -proposed? | 16:34 |
| cjwatson | we'd have to make sure that nothing else landed in -proposed; I'm not that confident in our communication over extended periods | 16:35 |
| slangasek | right | 16:35 |
| slangasek | so | 16:35 |
| cjwatson | a non-virt PPA would be safer | 16:35 |
| slangasek | the bootstrap is eglibc->gcc->eglibc | 16:35 |
| slangasek | the first eglibc that adds the new PI path can also add the bumped shlibs | 16:35 |
| slangasek | it's slightly overbroad, but safe | 16:36 |
| cjwatson | oh, the new PI is in the first eglibc? | 16:36 |
| slangasek | yes, AIUI / IIRC | 16:36 |
| slangasek | infinity: ^^ can you confirm? | 16:36 |
| slangasek | jdstrand: is the 'ubiquity' task on bug #980772 a misunderstanding? ubiquity is only used for desktop CDs, and the bug report says this only applies to non-desktop | 16:38 |
| ubot2 | Launchpad bug 980772 in ubiquity "Various files and directories created with odd permissions on precise" [High,New] https://launchpad.net/bugs/980772 | 16:38 |
| cjwatson | the bug report lists desktop problems ... | 16:39 |
| cjwatson | albeit one I can't reproduce | 16:39 |
| slangasek | "The desktop install does not seem to be affected:" | 16:39 |
| cjwatson | "Other directories: | 16:40 |
| cjwatson | drwsrwsrwt 2 root root 40 Apr 13 06:59 /run/initramfs/ (desktop and server)" | 16:40 |
| slangasek | oh | 16:40 |
| slangasek | lala | 16:40 |
| infinity | slangasek: I wasn't entirely sure I was going to care about upgrade paths, given that this is unreleased, but I could bump shlibs on armhf, sure. | 16:40 |
| slangasek | infinity: these aren't the last binaries being built in precise; we'd certainly like out-of-order upgrades to not explode on impact over the next two weeks | 16:40 |
| jodh | cjwatson: looks like ply_boot_connection_free() is closing the fd source->fd refers to. | 16:40 |
| * jodh -> afk | 16:41 | |
| infinity | slangasek: Sure, I'll do that, then. | 16:41 |
| infinity | slangasek: I was going to have to for Debian anyway, where I certainly have less control over things like the buildd network. | 16:41 |
| infinity | slangasek: So, I'll bump shlibs for both. | 16:41 |
| infinity | cjwatson / slangasek: As for "in between" issues, I'm not bootstrapping it in the archive, unless people give me a really solid excuse to. | 16:43 |
| slangasek | infinity: because we don't trust your scary out-of-archive binaries :P | 16:43 |
| infinity | cjwatson / slangasek: I have to do test builds locally anyway, to make sure everything's just so, so once those are done, I can toss them on archive-team.internal, and pull them in for one gcc and eglibc build. | 16:43 |
| slangasek | yeah, ok | 16:44 |
| cjwatson | jodh: so http://paste.ubuntu.com/928183/, maybe | 16:44 |
| slangasek | infinity: it spares powerpc some pain, so I guess that's best | 16:44 |
| cjwatson | jodh: (assuming that's the only event loop user with this problem) | 16:44 |
| infinity | slangasek: It's how I did the rest of the port, why stop now? ;) | 16:44 |
| * infinity goes back to setting his local ARM machines on fire. | 16:44 | |
| * pitti pleasantly sees that today's image is _well_ under the limit | 16:45 | |
| pitti | thanks Tim Gardner | 16:45 |
| infinity | slangasek: The only other question I have is if you'll be cool with me swapping in Michael Hope's GCC patch instead of the one we've been using. Our compiler is broken for any non-glibc targets (which would matter if people wanted to use Ubuntu to develop for uclibc, bionic, etc) | 16:46 |
| slangasek | pitti: what did he jettison? :-) | 16:46 |
| cjwatson | unused firmware | 16:46 |
| slangasek | sweet | 16:46 |
| pitti | throwing out obsolete firmware from linux-firmware | 16:46 |
| slangasek | infinity: I haven't seen the delta; want to throw it my way for pre-approval? | 16:46 |
| infinity | slangasek: It's patching an entirely different file (ie: the right one). | 16:47 |
| slangasek | jdstrand: bug #980772 again - did you use encrypted home dirs when installing? | 16:47 |
| ubot2 | Launchpad bug 980772 in ubiquity "Various files and directories created with odd permissions on precise" [High,New] https://launchpad.net/bugs/980772 | 16:47 |
| slangasek | infinity: then can you throw me two deltas? | 16:47 |
| infinity | slangasek: http://lists.linaro.org/pipermail/cross-distro/2012-April/000160.html | 16:49 |
| slangasek | cjwatson: aha, I'm seeing bug #980772 on an upgrade - so this isn't the installer, it's something amok with initramfs or a udev rule at boot time | 16:49 |
| ubot2 | Launchpad bug 980772 in ubiquity "Various files and directories created with odd permissions on precise" [High,New] https://launchpad.net/bugs/980772 | 16:49 |
| cjwatson | slangasek: heh, we commented two seconds apart | 16:49 |
| infinity | slangasek: http://paste.ubuntu.com/928192/ <-- Our current patch | 16:49 |
| cjwatson | slangasek: how about /media | 16:49 |
| slangasek | :-) | 16:49 |
| cjwatson | ? | 16:49 |
| slangasek | /media is fine for me | 16:50 |
| slangasek | (new install and also upgrade) | 16:50 |
| cjwatson | well, I stand by my Incomplete status :) | 16:50 |
| slangasek | yes :) | 16:50 |
| cjwatson | installer bugs with no logs => not fun | 16:50 |
| jdstrand | slangasek: yes | 16:51 |
| slangasek | ok | 16:51 |
| slangasek | I'm tentatively blaming cryptsetup | 16:51 |
| slangasek | jdstrand: is cryptsetup there on the server test too? | 16:51 |
| jdstrand | slangasek: 2:1.4.1-2ubuntu3 | 16:52 |
| slangasek | yep | 16:52 |
| slangasek | now the question is, why/where | 16:52 |
| cjwatson | can somebody review ubiquity in the queue, so I can nuke the rls-p-tracking tag off apt? | 16:52 |
| cjwatson | (problem with tags for this: they can't be bug-task-specific) | 16:53 |
| * skaet nods at that | 16:53 | |
| jdstrand | I should note that these are just straight up iso installs in a vm. for desktop, I used encrypted home and 3rd party. for server encrypted home and all tasks in tasksel (except manual). otherwise default installs | 16:53 |
| jdstrand | slangasek, cjwatson | 16:53 |
| jdstrand | ^ | 16:53 |
| jdstrand | cjwatson: which logs do you want? | 16:53 |
| gotwig | hey | 16:53 |
| jdstrand | the machine is still up | 16:54 |
| slangasek | plymouth touches /run/initramfs if it's in the initramfs, which it is if cryptsetup is installed | 16:54 |
| gotwig | critical broken package for precise !! : https://bugs.launchpad.net/ubuntu/+source/npm/+bug/863094 | 16:54 |
| ubot2 | Launchpad bug 863094 in npm "npm versions less than 1.1 will not work with registry.npmjs.org" [Unknown,Fix released] | 16:54 |
| cjwatson | jdstrand: the standard installer log is /var/log/installer/syslog | 16:54 |
| cjwatson | jdstrand: but it doesn't sound like this is actually an installer bug anyway | 16:54 |
| jdstrand | it might not be the installer btw-- I just didn't know where else to put it | 16:54 |
| jdstrand | (but I'm sure you know that :) | 16:54 |
| jdstrand | heh | 16:54 |
| gotwig | please help | 16:54 |
| cjwatson | gotwig: please don't shout at us | 16:55 |
| gotwig | cjwatson: oups... sry | 16:55 |
| slangasek | cjwatson: looking at ubiquity | 16:55 |
| gotwig | cjwatson: you know, its important.... | 16:55 |
| cjwatson | SpamapS: ^- can you look at the npm bug above? | 16:55 |
| * gotwig likes to use a packaged node.js | 16:55 | |
| * SpamapS looks | 16:55 | |
| SpamapS | perhaps we should move the discussion to #ubuntu-motu though? | 16:55 |
| cjwatson | yeah, not really a -release matter | 16:56 |
| JohnLea | slangasek; hyia, would it be possible to take a look at bug #959339 ? This is a really critical bug that seems to have fallen through the cracks on the Unity 3d side, and we are trying to get it fixed in time for SRU-0 | 16:56 |
| ubot2 | Launchpad bug 959339 in unity "Launcher, Alt-Tab - clicking on launcher item or selecting a app in Alt-Tab raises all app windows, not just most recently focused" [Critical,In progress] https://launchpad.net/bugs/959339 | 16:56 |
| gotwig | SpamapS: I reported it there, too... | 16:56 |
| slangasek | JohnLea: I'm a bit contended at the moment; perhaps another release-teamer can look | 16:57 |
| slangasek | cjwatson: has the ubiquity change been tested in anger? I'm not going to effectively review the exception handling here | 16:58 |
| JohnLea | slangasek, np, thx | 16:59 |
| skaet | JohnLea, its being targetted to SRU-0. | 16:59 |
| cjwatson | slangasek: I can't reproduce the corruption itself, but I've given it a straight run-through in an install that was doing language pack downloading, and confirmed that language packs are still downloaded correctly | 16:59 |
| cjwatson | (and installed) | 17:00 |
| cjwatson | slangasek: I can see if I can forcibly corrupt things in situ or something | 17:00 |
| JohnLea | skaet; and that is all good at your end? I'm trying to get everything lined up for the fix for this bug to be landed. | 17:00 |
| slangasek | cjwatson: nah, I'm satisfied if we haven't regressed in the non-corrupted case | 17:01 |
| cjwatson | IOError is what the consumer of this code is expecting in the "the network ate my homework" case | 17:01 |
| slangasek | got it | 17:01 |
| infinity | JohnLea: FWIW, I think it should be fixed. Shame it was broken in the first place. :P | 17:01 |
| slangasek | that was about to be my question :-) | 17:01 |
| slangasek | cjwatson: accepted | 17:02 |
| cjwatson | and the result of IOError is "shrug, log it, carry on" | 17:02 |
| cjwatson | great, thanks | 17:02 |
| skaet | JohnLea, been reading through the bug. possibly this is something to cherry pick a fix up for. Want you and didrocks on the same page thought before we do. | 17:02 |
| jdstrand | slangasek, cjwatson: ok, updated the bug with the installer logs and an updated description for what install options I used | 17:02 |
| didrocks | skaet: hum, it's changing the behavior | 17:02 |
| didrocks | skaet: so if you click on an icon in the launcher, you won't get the same action | 17:02 |
| didrocks | skaet: my recommendation is either get it early next week, like before tuesday | 17:03 |
| didrocks | or not | 17:03 |
| didrocks | as changing a behavior post release is bad | 17:03 |
| infinity | didrocks: It's bringing the behaviour in line with 2d, and yeah, if there's a solid patch ready to do, I say soon, soon, soon. | 17:03 |
| infinity | s/do/go/ | 17:03 |
| didrocks | infinity: agreed, I'm arguing on that one for 8 monthes as you can see on the bug :) | 17:03 |
| skaet | didrocks, yes, agree, by monday actually would be the preference if we want to cherry pick this up. Not happy with it, at all. | 17:03 |
| infinity | Yeah. :/ | 17:03 |
| didrocks | skaet: so am I… | 17:04 |
| infinity | didrocks: If it can be done over the weekend, some of us are a bit flexible in what we call "work hours" (ie: me) | 17:04 |
| skaet | Don't think it should be SRU0 material. | 17:04 |
| infinity | didrocks: I'd happily review and accept it anytime, as long as it's Really Soon. | 17:04 |
| skaet | i'll be around as well this weekend. | 17:05 |
| didrocks | infinity: I won't be here on the week-end, I'm already crossing the 80 hours this week ;) | 17:05 |
| didrocks | but let me try to get people on that | 17:05 |
| infinity | didrocks: Great. Have your people call our people. | 17:05 |
| infinity | didrocks: (Our people can sponsor too, if you're the only uploader they have...) | 17:06 |
| didrocks | infinity: sure, just bzr branch lp:~ubuntu-desktop/unity/ubuntu and bzr merge the branch | 17:07 |
| didrocks | (full source derived from upstream branch FTW \o/) | 17:07 |
| ogra_ | ++ | 17:07 |
| didrocks | I'm just trying to find anyone right now ;) | 17:07 |
| infinity | didrocks: Check. ;) | 17:07 |
| * ogra_ wishes that bug would have come up this morning | 17:08 | |
| ogra_ | we could have easily included the fix | 17:08 |
| ogra_ | while waiting for arm testbuilds | 17:08 |
| didrocks | ogra_: indeed | 17:09 |
| slangasek | infinity: gcc patch looks safe enough | 17:10 |
| slangasek | infinity: michaelh1's gcc patch looks good to me... will you test that armel doesn't get broken before uploading? | 17:11 |
| infinity | slangasek: Yeah. | 17:12 |
| infinity | slangasek: I've got a weekend to burn CPU time, I'll make sure I get it all just right. | 17:12 |
| slangasek | great, thanks | 17:13 |
| infinity | (I do like that he tested so extensively, though, gives me some confidence) | 17:13 |
| cjwatson | slangasek: hmm. good news, it didn't crash when I forcibly corrupted a file; bad news, it didn't notice either | 17:22 |
| cjwatson | bah | 17:22 |
| slangasek | heh | 17:22 |
| * cjwatson goes to do a better job | 17:22 | |
| cjwatson | (or rather, it did crash, but not any worse than before) | 17:22 |
| cjwatson | sorry, I clearly should have tried that | 17:23 |
| skaet | ogra_, is there an ordering between the linux-ac100, and linux-meta-ac100 we're going to need to worry about in the acceptance ordering. (ie. don't accept meta until the linux-ac100 is through?) | 17:31 |
| slangasek | that's the general rule for linux meta packages, yes | 17:31 |
| ogra_ | skaet, well, same as for the normal kernels | 17:31 |
| ogra_ | (what slangasek said) | 17:32 |
| skaet | NCommander, can you please look at the linux-ac100 and linux-meta-ac100? | 17:32 |
| cjwatson | though it doesn't break the archive if you don't | 17:32 |
| infinity | skaet: Accepting it all at once is fine. | 17:32 |
| cjwatson | oh, wait, *that* ordering | 17:32 |
| cjwatson | it doesn't break the archive if you accept linux-ac100 without linux-meta-ac100 | 17:32 |
| cjwatson | the other way round would | 17:33 |
| infinity | Yeah, but the other way around shouldn't happen. | 17:33 |
| infinity | Since linux-ac100 is in binary NEW. | 17:33 |
| cjwatson | indeed, would have to be archive admin asleep at the wheel | 17:33 |
| skaet | yeah, spotted it and didn't realize initially that linux-ac100 was in NEW. | 17:33 |
| infinity | So, it's all the same round. | 17:33 |
| * skaet noting | 17:33 | |
| infinity | Did someone already accept the armhf build? | 17:33 |
| skaet | not sure... | 17:33 |
| infinity | Looks like. | 17:33 |
| * infinity accepts the armel. | 17:34 | |
| infinity | (and the meta) | 17:35 |
| skaet | thanks infinity, NCommander, ignore request. | 17:35 |
| zul | can someone accept horizon..it fixes a regression that was introduced in the last upload | 17:44 |
| infinity | zul: It might have to be in the queue first. | 17:46 |
| zul | it is.. | 17:46 |
| zul | -queuebot/#ubuntu-release- Unapproved: accepted horizon [source] (precise-release) [2012.1-0ubuntu4] | 17:46 |
| infinity | zul: Err, note the "accepted" there. | 17:46 |
| zul | right...nm.....im going back to sleep :P | 17:46 |
| skaet | launchpad is timing out on trying to approve software-center for me. (It has fixes we want to get in, and seems sane from scan perspective). | 17:58 |
| skaet | can someone else try and see if they have better luck goosing it through the queue? | 17:59 |
| skaet | I've been trying and timing out for last 15+ minutes | 17:59 |
| infinity | skaet: Done. | 18:00 |
| skaet | Thanks infinity. | 18:01 |
| cjwatson | slangasek: ah, I think my ubiquity workaround just failed to handle epochs | 18:06 |
| cjwatson | silly python-apt making life hard | 18:06 |
| slangasek | heh | 18:07 |
| infinity | pitti: I assume this apport workaround is just meant to be closing a large race window with a smaller one? | 18:27 |
| infinity | pitti: Did mvo's small patch to GTK+ scare you too much to go that route? | 18:30 |
| slangasek | jdstrand: thanks for this bug - I've never seen a value like that passed to chmod before, makes for interesting reading ;) | 19:13 |
| slangasek | jdstrand: is your filesystem perms audit something that could be wired up to QA's daily upgrade+install tests as a pass/fail? | 19:13 |
| cjwatson | slangasek: wow what | 19:16 |
| slangasek | cjwatson: when you failed to reproduce this, were you on i386 by chance? | 19:16 |
| cjwatson | yes | 19:16 |
| cjwatson | but jdstrand said i386 | 19:16 |
| slangasek | oh, did he? | 19:16 |
| cjwatson | wait, no he didn't | 19:16 |
| cjwatson | gah, I managed to misread 12.04 as i386, I think | 19:17 |
| cjwatson | that would have saved some time :-/ | 19:17 |
| slangasek | org_mask = cur_mask = (mode_t)-1L; | 19:17 |
| slangasek | haha what | 19:17 |
| jdstrand | no | 19:17 |
| jdstrand | I was on amd64 | 19:17 |
| jdstrand | slangasek: sure-- it is just part of qrt | 19:18 |
| jdstrand | pass fail might be difficult | 19:18 |
| jdstrand | but someone interested could do it | 19:18 |
| slangasek | jdstrand: well, "pass" could be "no bogons found", and everything else a failure? | 19:19 |
| cjwatson | (mode_t)-1L is a sentinel value there | 19:19 |
| jdstrand | (it is part of the security team's release cycle duties to run these tests and compare to previous releases/milestones | 19:19 |
| jdstrand | ) | 19:19 |
| cjwatson | I suspect the bug is in parse_mode | 19:19 |
| cjwatson | er bb_parse_mode | 19:19 |
| jdstrand | QRT/install/get_file_info | 19:19 |
| cjwatson | hm, maybe not actually, mkdir -m isn't used here | 19:20 |
| slangasek | jdstrand: would having it in the jenkins automation save you guys time? | 19:20 |
| jdstrand | slangasek: eh.. | 19:21 |
| jdstrand | probably not | 19:21 |
| slangasek | ok then | 19:21 |
| jdstrand | it isn't a pass/fail with me | 19:21 |
| jdstrand | there is a lot of manual inspection | 19:21 |
| slangasek | I was just thinking it might be nice to know about this sort of thing earlier in the cycle | 19:21 |
| jdstrand | eg, things like those permissions are pass fail, but then even just changing group ownership on a directory, etc | 19:22 |
| cjwatson | so why is mkdir calling chmod when called without -m? | 19:22 |
| jdstrand | we investigate it and see if it is ok and then document it | 19:22 |
| cjwatson | oh | 19:22 |
| cjwatson | mode_t mode = (mode_t)(-1); | 19:22 |
| cjwatson | != (mode_t)(-1L) | 19:22 |
| ubot2 | Factoid 'mode_t)(-1L)' not found | 19:22 |
| jdstrand | slangasek: I can try to make these happen earlier in the cycle | 19:22 |
| cjwatson | shut up ubot2 | 19:22 |
| cjwatson | that's in coreutils/mkdir.c | 19:22 |
| jdstrand | normally we shoot for beta and then again with rc | 19:22 |
| jdstrand | but beta didn't happen due to being crazy busy | 19:23 |
| cjwatson | slangasek: http://git.busybox.net/busybox/commit/?id=af36ba206f7cf0eef77a82af741766a2d03c51ad | 19:24 |
| slangasek | bingo | 19:24 |
| slangasek | cjwatson: thanks | 19:24 |
| cjwatson | np | 19:24 |
| * skaet --> appt, back later. | 19:25 | |
| slangasek | though this only fixes mkdir, so doesn't explain what jdstrand saw under /dev | 19:26 |
| slangasek | so maybe there's a corresponding bug + fix for mknod | 19:27 |
| cjwatson | not sure I see anything relevant upstram | 19:29 |
| cjwatson | +e | 19:29 |
| cjwatson | surely udev doesn't shell out to mknod though? | 19:30 |
| slangasek | I'm not convinced these are udev's doing | 19:30 |
| slangasek | /dev/autofs? what the heck is that? | 19:30 |
| cjwatson | rules/rules.d/50-udev-default.rules:94:KERNEL=="tun", MODE="0666", OPTIONS+="static_node=net/tun" | 19:30 |
| slangasek | no /dev/autofs in my /var/log/udev | 19:31 |
| cjwatson | /* set sticky bit, so we do not remove the node on module unload */ | 19:31 |
| cjwatson | mode |= 01000; | 19:31 |
| cjwatson | in udev | 19:31 |
| slangasek | so do we think that's non-buggy? | 19:32 |
| cjwatson | so that will account for at least some of those | 19:32 |
| cjwatson | it's an exotic use for the sticky bit, but it seems entirely deliberate (it's in the udev ChangeLog for 174, even) and not totally unreasonable | 19:33 |
| jdstrand | oh | 19:33 |
| jdstrand | fascinating | 19:33 |
| slangasek | ok | 19:33 |
| cjwatson | it's not like it means anything else | 19:33 |
| slangasek | uploading just the busybox fix then | 19:33 |
| jdstrand | I will document that | 19:33 |
| jdstrand | does that account for all of the sticky bits? | 19:34 |
| cjwatson | I think so; udev forces the sticky bit on devices that the kernel tells it to create in some cases, too | 19:34 |
| cjwatson | you can grep -r sticky yourself :-) | 19:34 |
| cjwatson | I can't think how it would be security-harmful | 19:35 |
| jdstrand | cjwatson: cool. thanks | 19:36 |
| * jdstrand documents | 19:36 | |
| slangasek | bdmurray: when you reproduced bug #874774... did it only happen for you on the first boot after install? | 19:36 |
| ubot2 | Launchpad bug 874774 in cryptsetup "could not mount /dev/mapper/cryptswap1" [High,Triaged] https://launchpad.net/bugs/874774 | 19:36 |
| slangasek | bdmurray: because that's what I've gotten here :P | 19:36 |
| cjwatson | I don't know at the moment why it's only applied to some device nodes and not others | 19:37 |
| cjwatson | busybox LGTM, accepting | 19:38 |
| cjwatson | we'll probably want a d-i upload later to pull that in | 19:39 |
| bdmurray | slangasek: I didn't watch the 2nd boot closely but could check again | 19:40 |
| cjwatson | can somebody review my go-around on ubiquity? | 19:40 |
| jdstrand | cjwatson: thanks for looking at those sticky files btw-- I got distracted by the tty business and forgot to circle back around | 19:41 |
| cjwatson | this time it correctly detected corruption and smoothly elected not to install language packs | 19:41 |
| cjwatson | np | 19:41 |
| cjwatson | hmm, busybox-initramfs doesn't actually call update-initramfs on upgrade; I hope there'll be something else that does that before release | 19:43 |
| cjwatson | there was a circularity problem with it doing so way back in the old days | 19:43 |
| cjwatson | I don't know if there still is, and there may not be since that was before we had triggers, but I'm not entirely certain I want to find out just now | 19:44 |
| slangasek | unless jdstrand thinks this is USN-worthy, I'm inclined not to worry about it... it's a DoS if someone fills /run, but it seems to only be that one dir that's affected and we can count on a kernel SRU soon enough | 19:45 |
| slangasek | looking at ubiquity | 19:46 |
| slangasek | webkit's cache> oho | 19:50 |
| cjwatson | not quite sure if it will do the job but certainly worth a shot | 19:50 |
| slangasek | yep | 19:50 |
| cjwatson | and it doesn't regress installation, at least | 19:50 |
| slangasek | ubiquity accepted | 19:51 |
| slangasek | reviewing django-nose (MIR prereq, python-support deprecation) | 19:51 |
| jdstrand | slangasek: and thank you for digging in and fixing busybox. kinda a neat bug :) | 19:56 |
| slangasek | no worries | 19:56 |
| slangasek | those are always the fun amd64 bugs | 19:56 |
| slangasek | the unfun ones are the 50th time a GNOME application segfaults in gobject because the upstream gtk docs give bad advice that seduces people into not being 64-bit-clean | 19:57 |
| slangasek | y'know, I've never done an install in asturianu before | 19:58 |
| slangasek | let's give it a try | 19:59 |
| jdstrand | heh | 20:11 |
| slangasek | lamont: welcome to final freeze? :P | 20:11 |
| lamont | slangasek: I discussed it with scottk before uploading | 20:11 |
| slangasek | ok :) | 20:11 |
| lamont | bind9 is me fixing my "chown 644" typo | 20:12 |
| jdstrand | SpamapS: fyi, just noticed that python-ceph Depends on librgw1, but we don't build librgw1 any more | 20:12 |
| lamont | postfix is one that fails to _start_ _sometimes_ because of a typo in the ssl cert handling | 20:12 |
| * jdstrand looks curiously at the same version of unity building in two different native ppas and taking up powerpc's resources | 20:15 | |
| jdstrand | SpamapS: ok, filed 981130 and assigned to you so we wouldn't lose it. feel free to reassign/etc | 20:18 |
| * ScottK is reviewing bind9 and postfix | 20:23 | |
| ScottK | jdstrand: I'm sure it's critical due to the large Unity on Power userbase. | 20:30 |
| jdstrand | hehe | 20:30 |
| jdstrand | one finished. it just looked funny | 20:30 |
| SpamapS | jdstrand: will look into it. | 20:33 |
| bdmurray | slangasek: the cryptswap message appeared again on my 3rd(?) bot | 20:45 |
| slangasek | bdmurray: interesting, ok | 20:45 |
| slangasek | so it seems to be racy in some way | 20:45 |
| slangasek | or there are multiple causes | 20:45 |
| slangasek | bdmurray: do you have /var/log/upstart/cryptdisks-enable.log on this system? | 20:55 |
| cjwatson | ah, good, openjdk-{6,7} have both finished | 20:58 |
| * cjwatson copies | 20:58 | |
| bdmurray | slangasek: http://paste.ubuntu.com/928514/ | 20:58 |
| slangasek | bdmurray: yep, looking familiar | 20:59 |
| cjwatson | yay for job logging | 20:59 |
| slangasek | yep :) | 20:59 |
| cjwatson | made use of it in anger yesterday when working on mountall, too | 20:59 |
| cjwatson | cleaned up the pad too | 21:02 |
| cjwatson | copying ubiquity, which has built | 21:26 |
| cjwatson | stgraber: ^- "/primary"? | 21:26 |
| cjwatson | syncs from a PPA causing confusion maybe? | 21:26 |
| cjwatson | or something to do with them being new? | 21:27 |
| cjwatson | ... they're syncs from Debian, not from a PPA, it seems | 21:28 |
| cjwatson | SpamapS: is there an FFe for all the node-* stuff? | 21:28 |
| ScottK | cjwatson: There is. I'm taking care of it. | 21:28 |
| cjwatson | OK, cool | 21:28 |
| stgraber | cjwatson: Were these new source packages or just binary? | 21:31 |
| cjwatson | stgraber: source | 21:31 |
| cjwatson | syncs of source packages from Debian, not previously in Ubuntu | 21:31 |
| stgraber | cjwatson: I seem to remember writting some code where it'd print the archive name (primary or partner) when it can't figure out a component (as a new source, as far as LP is concerned, doesn't have a component yet) | 21:32 |
| stgraber | that's mostly useful to spot partner uploads really | 21:32 |
| cjwatson | mm - but in this case it's printing the archive name from Debian, which is dubiously useful without qualification | 21:32 |
| stgraber | >>> list(lp.distributions['ubuntu'].archives) | 21:34 |
| stgraber | [<archive at https://api.launchpad.net/1.0/ubuntu/+archive/primary>, <archive at https://api.launchpad.net/1.0/ubuntu/+archive/partner>] | 21:34 |
| stgraber | cjwatson: ^ | 21:34 |
| cjwatson | stgraber: oh, the web UI said "Sync from Primary Archive for Debian GNU/Linux" or some such, so I thought that was what you were using | 21:38 |
| cjwatson | OK, fair enough | 21:38 |
| cjwatson | >>> list(lp.distributions['debian'].archives) | 21:39 |
| cjwatson | [<archive at https://api.launchpad.net/1.0/debian/+archive/primary>] | 21:39 |
| slangasek | cjwatson: 848915> I'm getting the overall impression that "partial upgrade" is more trouble than it's worth and we should kill it off as an option | 21:39 |
| slangasek | cjwatson: there's a bug from mpt about this which I think mvo has weighed in on, let me fetch | 21:39 |
| cjwatson | slangasek: so am I, but I'm not going to do that now | 21:39 |
| cjwatson | yeah, I believe I've seen it | 21:39 |
| slangasek | ok | 21:39 |
| slangasek | you think it's too high-risk? | 21:40 |
| slangasek | it would be a small change to just never present that option | 21:40 |
| cjwatson | I don't want to suddenly find out that we needed it after all for some reason and then have to fix this bug anyway ... | 21:40 |
| slangasek | sure | 21:41 |
| cjwatson | I don't feel I know u-m well enough to judge that | 21:41 |
| cjwatson | but based on experience from ubiquity it seems that this bug shouldn't be too hard to fix directly - *if* we can reproduce it | 21:41 |
| slangasek | fair enough | 21:41 |
| slangasek | bug #955022 was the one, fwiw | 21:57 |
| ubot2 | Launchpad bug 955022 in update-manager ""Not all updates can be installed" requires a decision most people can't make" [Medium,Confirmed] https://launchpad.net/bugs/955022 | 21:57 |
| cjwatson | slangasek: I'm sceptical that this actually has anything to do with partial upgrade mode, anyway | 22:04 |
| slangasek | fair 'nuff | 22:04 |
| cjwatson | slangasek: out of 17 duplicates, only two have "PythonArgs: ['/usr/bin/update-manager', '--dist-upgrade']", and the rest have other arguments | 22:05 |
| cjwatson | slangasek: also, only one of those bugs is from the final oneiric version or newer | 22:05 |
| slangasek | interesting | 22:06 |
| cjwatson | which might just mean poor duplication, but | 22:06 |
| slangasek | or was there a bug pattern for this? | 22:06 |
| cjwatson | oh, could be, I should check | 22:07 |
| cjwatson | I don't see a bug pattern | 22:09 |
| cjwatson | there's one mention in bug 350988 of running update-manager from cron and it getting upset | 22:11 |
| ubot2 | Launchpad bug 350988 in update-manager "update 8.10 to 9.04 ==> Pb with udevinfo (not found)" [Undecided,Opinion] https://launchpad.net/bugs/350988 | 22:11 |
| cjwatson | to which I say meh | 22:11 |
| NCommander | skaet: bah, sorry about that | 22:11 |
| cjwatson | all but three of the bugs had recently upgraded from natty to oneiric, and two of the remainder from oneiric beta to oneiric; recently enough that they might not have restarted yet, perhaps | 22:14 |
| cjwatson | two of the bugs used --no-focus-on-map, I think implying that it was launched from update-notifier | 22:23 |
| cjwatson | can't reproduce it that way either. trying a natty install | 22:36 |
| === yofel_ is now known as yofel | ||
| === ogra_- is now known as ogra_ | ||
| === lan3y is now known as Laney | ||
| === Laney is now known as Guest91745 | ||
| === Guest91745 is now known as Laney | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!