=== didrocks1 is now known as didrocks [08:17] What's the best way to deal with the omap4 image build brokenness? As far as we can tell it's because xserver-xorg-core (and maybe other parts of the X stack) are included as part of the ubuntu-desktop task, which isn't coinstallable with the revert stack included by pvr-omap4. [08:18] The revert stack does Provides the old package names but I guess the real ones are also requested [08:18] mlankhorst: ^ cc [08:19] Laney, you could hackishly script something in live-build.... [08:19] you inspire such confidence [08:20] drop the packages from the list in livecd-rootfs, drop the deps from the package, have a hook script that force installs them at the end of the build [08:20] something like that [08:21] will indeed only work for our images then, not for people that install ubuntu-desktop [08:22] Laney: well I have the conflictless versions [08:22] alternatively, you could implement subarch support in seeds and metapackages so we can make the dep subarch specific :) [08:22] in my own ppa, lets test.. [08:26] I imagine you could implement a remove_package in live-build indeed [08:26] hm *seems* to work [08:26] chdist apt-get saucy-armhf install --dry-run ubuntu-desktop^ xserver-xorg-core-omap-revert xserver-xorg-video-omap-revert xserver-xorg-input-evdev-omap-revert pvr-omap4 [08:26] with deb http://ppa.launchpad.net/mlankhorst/ppa/ubuntu saucy main [08:26] Laney: well remove-package would be hard, you'd end up without a xserver at one point.. [08:26] No, remove it from the list of packages to be installed [08:26] because the problem is that it's trying to install both stacks, right? [08:26] yeah [08:26] in my ppa I 'solved' it by allowing both to be installed [08:26] which seems to work [08:26] as long as it doesnt break at runtime :) [08:26] AFAICS it expands Task: ubuntu-desktop to a list of packages, and then adds pvr-omap4 and some others to the list too [08:26] so if you kill off the old stack from that list ... [08:26] Laney, right [08:26] ah... [08:27] in that case, kill off xserver-xorg-* [08:27] I'll wait for some definitive advice though [08:27] Laney, no, you dont install pvr-omap at the beginning, move it too a hook script that runs at the end and first removes the offending packages, then installs pvr [08:27] is that better? [08:28] dunno [08:28] at least hook scripts are easier to identify and drop :) [08:28] note the dash, you want to keep xserver-xorg :P [08:38] ogra_: subarch support> impossible because it would need to correspond with apt; it's not a matter of a missing feature in seeds [08:38] cjwatson, well, i didnt expect Laney to implement it for that problem anyway :) [08:38] * ogra_ wishes we had kept the nexus7 desktop images for testing instead of the pandas .... would be so much easier [08:38] ogra_: indeed!! [09:12] cjwatson: do you have a recommendation for solving this? [09:15] Laney: the approach you and mlankhorst were talking about above seems vaguely plausible and probably the best you can do for now [09:15] Allowing both to be coinstalled (as mlankhorst said) would simplify things [09:16] His solution is to have Replaces but no Conflicts [09:16] Ah, that's unsafe [09:16] Don't do that [09:16] right [09:16] It can cause files to vanish entirely [09:16] I know, I warned about that :p [09:16] Yeah, that was recognised and it's why I didn't want to do it [09:17] OK I'll work up a remove_package thing later today for review [09:17] is it easy to dry-run that part of live-build? [09:17] You can lb config and see what it does [09:17] Might be easier to just start the build and ctrl-c [09:17] lb config may not be that informative [09:18] never done that, but I'll figure it out [09:18] oops, supposed to patch pilot today [09:18] * Laney shuffles that [09:20] Laney: https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html may help [09:20] Still more or less accurate [09:21] * Laney nods [09:21] I'll get back to you later with any problems I'm sure :-) [13:28] Ah good, that seems to work [13:28] I didn't realise that those add_* functions were building a list which is then evaluated at some later stage, so just trying to remove from it wouldn't work [13:28] So I added support for passing a regexp to exclude to add_task [13:33] If the goal is to add/remove some bits, I would expect "add_package toadd toremove-" to work. [13:33] As it's probably passed straight to apt like that. [13:34] add_package install toadd toremove- even. [13:34] bdmurray: Looks like I got copy-set-phase fractionally wrong. Fixing it up in a subsequent branch now ... [13:34] Bah, etc. [13:35] Laney: ^^ [14:35] infinity: It's removing something from the task expansion [14:36] Maybe though... [14:38] Nah, chdist apt-get saucy-armhf --dry-run install xserver-xorg-core-omap-revert xserver-xorg-core xserver-xorg-core- doesn't work [14:39] Laney: Except that's not what it does... [14:40] what's not what what does? :-) [14:40] Laney: You want ubuntu-desktop^ xserver-xorg-core-omap-revert xserver-xorg-core- [14:41] Yes, that's the same [14:41] Does xserver-xorg-core-omap-revert provide xserver-xorg-core? [14:42] If so, this seems like an apt bug if I can't swap task deps. [14:42] Possibly. [14:42] Sure does [14:42] ubuntu-desktop^ really just expands to the list [14:42] What was wrong with making them coinstallable again? [14:42] but AFAICT we pass the task expansion in anyway [14:43] We need to expand the task and then substitute [14:43] Have a look at livecd-rootfs in precise [14:43] It does basically this [14:45] I see, there you stopped using the tasks [14:46] Path of least reistance due to having to change the tasks post-release. [14:46] Same theory for subarch-specific things where tasks can't do it. [14:47] Can you remember why it specifies libqt4-sql-sqlite notify-osd explicitly? [14:47] I'm still questioning the sanity of maintaining a different Xserver just for Pandas, plus any time investment in making it work. [14:48] Laney: At the time, it was likely because bad alternatives were being chose without forcing the issue. [14:48] Laney: The changelog might know. [14:48] s/chose/chosen/ [14:48] "slightly different dependency resolution" [14:48] ho hum [17:07] The json-c in binary NEW is part of the apache2/php5.5 clustermadness. === Ursinha_ is now known as Ursinha === LordOfTime is now known as LordOfTime|EC2 === vanhoof_ is now known as vanhoof [18:15] cjwatson: The ubuntu-devel list archive ends 11 July. Is there someone that should be contacted about that? [18:15] ScottK: Known... Though that's worse off than some lists. [18:17] OK. [18:17] infinity: If only someone who knew something about mailman worked for Canonical. [18:18] Oh, wait. Hello barry. === barry is now known as bobdobbs === bobdobbs is now known as barry [18:20] i think the u-d mailing list isn't on launchpad. which means it probably needs to be reported to IS, not that i have any special access on either machine [18:26] barry: It's already reported and being looked at. [18:26] infinity: k [20:00] Could somebody binary-NEW json-c, please? [20:01] I need it for the php5.5 transition nightmare thing [20:09] cjwatson: Why the -dbg for one library, but not the other? That seems odd. [20:09] Oh, libjson0 is a transitional package, isn't it? [20:09] Sure is. [20:10] * infinity looks closer and actually reviews these, then. [20:12] cjwatson: doc directory transitioned from a directory to a symlink. Doesn't that cause explodey fun? [20:16] cjwatson: Looks fine otherwise. If I'm wrong/confused about the directory->link migration (I suspect you remember this better than I do), go ahead and self-accept. [20:17] cjwatson: But I vaguely recall some unpack/remove weirdness in dpkg where it unpacks the symlink, then follows it to remove the removed files, which whacks the copyright/changelog in the new directory. [20:18] cjwatson: Oh, unless this is pkgbinarymangler at work, and it's not like that in Debian at all. In which case, I think pitti took precautions to avoid such badness. [20:20] cjwatson: Ahh, no, I'm misremembering, sort of. It was if a preinst mangled it that it broke. And Ondrej diddles it in postinst. It's been a while. And I suspect he learned this from me when we co-maintained PHP, no less. :P [20:31] He claimed to have fixed up such issues, at least - there was a bug about it. [20:31] I'll keep an eye on what it does on upgrade [20:31] Thanks [20:33] i'm slowly starting to wonder if i should be owrried about https://launchpad.net/ubuntu/saucy/+source/dbus/1.6.12-0ubuntu2... seems britney is really slow for this one [20:34] autopkgtest for colord 1.0.1-1ubuntu2: FAIL (Jenkins: public, private) [20:34] autopkgtest for firefox 23.0~b4+build1-0ubuntu1: RUNNING (Jenkins: public, private) [20:34] says http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html [20:34] I thought I had an ignore on colord. [20:35] Oh, I did, but someone updated the package. [20:35] firefox genuinely seems to be running - it's in xpcshell-tests [20:35] Someone updates colord, ostensibly to fix the tests. [20:35] This seems to have no gone as well as hoped. :P [20:35] ah, just many deps to check then [20:35] * infinity updates his hint for now. [20:35] (I think; the logs aren't timestamped adequately) [20:36] * ogra_ bppkmarks [20:36] RAOF: Your attempt to fix the colord tests didn't quite go as planned. [20:36] *book too [20:36] cjwatson, thanks ! [20:38] infinity: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-colord/ARCH=i386,label=adt/lastFailedBuild/console [20:38] Might not be RAOF's fault :-) [20:38] Hah [20:38] Let me see about retrying that then [20:39] Wait. [20:39] I might be reading that wrong [20:39] https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-colord/ARCH=i386,label=adt/lastFailedBuild/artifact/results/dsc0t-make-check-stderr [20:39] dsc0t-make-check FAIL status: 0, stderr: ../../test-driver: line 95: 6191 A... [20:39] ../../test-driver: line 95: 6191 Aborted (core dumped) "$@" > $log_file 2>&1 [20:39] yeah [20:39] make[2]: *** [test-suite.log] Error 1 [20:39] Yeah, genuine failure [20:39] Don't just scroll to the end :P [20:39] libcolord:ERROR:cd-self-test.c:3572:colord_icc_save_func: assertion failed (cd_icc_get_version (icc) == 4.09): (4.08 == 4.09) [20:40] cjwatson: Bah, CLOSE ENOUGH. [20:40] My pam_dwim module would have accepted that as a password. === medberry is now known as med_ [21:55] cjwatson: does http://paste.ubuntu.com/5882340/ look reasonable? If I didn't mess it up, that should add a .marked_good file to any build directory that contains or once contained an image that was published as current with a list of files that were then marked current. [21:56] hmm, actually ignore that, it's wrong [21:57] if a new build shows up and is only marked current for a few arches, then the .marked_good file for the previous build will be updated and some entries removed. I need to change the code to only add stuff there and never remove entries === maxb_ is now known as maxb [22:00] cjwatson: http://paste.ubuntu.com/5882366/ should address that [22:01] cjwatson: if that seems reasonably sane to you, I'll add some checks to the existing tests to ensure the content of the file looks good and I'll push that to cdimage