[08:17] <Laney> 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] <Laney> The revert stack does Provides the old package names but I guess the real ones are also requested
[08:18] <Laney> mlankhorst: ^ cc
[08:19] <ogra_> Laney, you could hackishly script something in live-build....
[08:19] <Laney> you inspire such confidence
[08:20] <ogra_> 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] <ogra_> something like that
[08:21] <ogra_> will indeed only work for our images then, not for people that install ubuntu-desktop
[08:22] <mlankhorst> Laney: well I have the conflictless versions
[08:22] <ogra_> alternatively, you could implement subarch support in seeds and metapackages so we can make the dep subarch specific :)
[08:22] <mlankhorst> in my own ppa, lets test..
[08:26] <Laney> I imagine you could implement a remove_package in live-build indeed
[08:26] <mlankhorst> hm *seems* to work
[08:26] <mlankhorst>  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] <mlankhorst> with deb http://ppa.launchpad.net/mlankhorst/ppa/ubuntu saucy main
[08:26] <mlankhorst> Laney: well remove-package would be hard, you'd end up without a xserver at one point..
[08:26] <Laney> No, remove it from the list of packages to be installed
[08:26] <Laney> because the problem is that it's trying to install both stacks, right?
[08:26] <mlankhorst> yeah
[08:26] <mlankhorst> in my ppa I 'solved' it by allowing both to be installed
[08:26] <mlankhorst> which seems to work
[08:26] <ogra_> as  long as it doesnt break at runtime :)
[08:26] <Laney> 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] <Laney> so if you kill off the old stack from that list ...
[08:26] <ogra_> Laney, right
[08:26] <mlankhorst> ah...
[08:27] <mlankhorst> in that case, kill off xserver-xorg-*
[08:27] <Laney> I'll wait for some definitive advice though
[08:27] <ogra_> 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] <Laney> is that better?
[08:28] <ogra_> dunno
[08:28] <ogra_> at least hook scripts are easier to identify and drop :)
[08:28] <mlankhorst> note the dash, you want to keep xserver-xorg :P
[08:38] <cjwatson> 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] <ogra_> 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] <mlankhorst> ogra_: indeed!!
[09:12] <Laney> cjwatson: do you have a recommendation for solving this?
[09:15] <cjwatson> Laney: the approach you and mlankhorst were talking about above seems vaguely plausible and probably the best you can do for now
[09:15] <cjwatson> Allowing both to be coinstalled (as mlankhorst said) would simplify things
[09:16] <Laney> His solution is to have Replaces but no Conflicts
[09:16] <cjwatson> Ah, that's unsafe
[09:16] <cjwatson> Don't do that
[09:16] <Laney> right
[09:16] <cjwatson> It can cause files to vanish entirely
[09:16] <mlankhorst> I know, I warned about that :p
[09:16] <Laney> Yeah, that was recognised and it's why I didn't want to do it
[09:17] <Laney> OK I'll work up a remove_package thing later today for review
[09:17] <Laney> is it easy to dry-run that part of live-build?
[09:17] <cjwatson> You can lb config and see what it does
[09:17] <cjwatson> Might be easier to just start the build and ctrl-c
[09:17] <cjwatson> lb config may not be that informative
[09:18] <Laney> never done that, but I'll figure it out
[09:18] <Laney> oops, supposed to patch pilot today
[09:18]  * Laney shuffles that
[09:20] <cjwatson> Laney: https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html may help
[09:20] <cjwatson> Still more or less accurate
[09:21]  * Laney nods
[09:21] <Laney> I'll get back to you later with any problems I'm sure :-)
[13:28] <Laney> Ah good, that seems to work
[13:28] <Laney> 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] <Laney> So I added support for passing a regexp to exclude to add_task
[13:33] <infinity> If the goal is to add/remove some bits, I would expect "add_package toadd toremove-" to work.
[13:33] <infinity> As it's probably passed straight to apt like that.
[13:34] <infinity> add_package install toadd toremove- even.
[13:34] <cjwatson> bdmurray: Looks like I got copy-set-phase fractionally wrong.  Fixing it up in a subsequent branch now ...
[13:34] <cjwatson> Bah, etc.
[13:35] <infinity> Laney: ^^
[14:35] <Laney> infinity: It's removing something from the task expansion
[14:36] <Laney> Maybe though...
[14:38] <Laney> 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] <infinity> Laney: Except that's not what it does...
[14:40] <Laney> what's not what what does? :-)
[14:40] <infinity> Laney: You want ubuntu-desktop^ xserver-xorg-core-omap-revert xserver-xorg-core-
[14:41] <Laney> Yes, that's the same
[14:41] <infinity> Does xserver-xorg-core-omap-revert provide xserver-xorg-core?
[14:42] <infinity> If so, this seems like an apt bug if I can't swap task deps.
[14:42] <infinity> Possibly.
[14:42] <Laney> Sure does
[14:42] <cjwatson> ubuntu-desktop^ really just expands to the list
[14:42] <infinity> What was wrong with making them coinstallable again?
[14:42] <Laney> but AFAICT we pass the task expansion in anyway
[14:43] <cjwatson> We need to expand the task and then substitute
[14:43] <cjwatson> Have a look at livecd-rootfs in precise
[14:43] <cjwatson> It does basically this
[14:45] <Laney> I see, there you stopped using the tasks
[14:46] <infinity> Path of least reistance due to having to change the tasks post-release.
[14:46] <cjwatson> Same theory for subarch-specific things where tasks can't do it.
[14:47] <Laney> Can you remember why it specifies libqt4-sql-sqlite notify-osd explicitly?
[14:47] <infinity> I'm still questioning the sanity of maintaining a different Xserver just for Pandas, plus any time investment in making it work.
[14:48] <infinity> Laney: At the time, it was likely because bad alternatives were being chose without forcing the issue.
[14:48] <infinity> Laney: The changelog might know.
[14:48] <infinity> s/chose/chosen/
[14:48] <Laney> "slightly different dependency resolution"
[14:48] <Laney> ho hum
[17:07] <cjwatson> The json-c in binary NEW is part of the apache2/php5.5 clustermadness.
[18:15] <ScottK> cjwatson: The ubuntu-devel list archive ends 11 July.  Is there someone that should be contacted about that?
[18:15] <infinity> ScottK: Known... Though that's worse off than some lists.
[18:17] <ScottK> OK.
[18:17] <ScottK> infinity: If only someone who knew something about mailman worked for Canonical.
[18:18] <ScottK> Oh, wait.  Hello barry.
[18:20] <barry> 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] <infinity> barry: It's already reported and being looked at.
[18:26] <barry> infinity: k
[20:00] <cjwatson> Could somebody binary-NEW json-c, please?
[20:01] <cjwatson> I need it for the php5.5 transition nightmare thing
[20:09] <infinity> cjwatson: Why the -dbg for one library, but not the other?  That seems odd.
[20:09] <infinity> Oh, libjson0 is a transitional package, isn't it?
[20:09] <infinity> Sure is.
[20:10]  * infinity looks closer and actually reviews these, then.
[20:12] <infinity> cjwatson: doc directory transitioned from a directory to a symlink.  Doesn't that cause explodey fun?
[20:16] <infinity> 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] <infinity> 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] <infinity> 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] <infinity> 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] <cjwatson> He claimed to have fixed up such issues, at least - there was a bug about it.
[20:31] <cjwatson> I'll keep an eye on what it does on upgrade
[20:31] <cjwatson> Thanks
[20:33] <ogra_> 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] <cjwatson> autopkgtest for colord 1.0.1-1ubuntu2: FAIL (Jenkins: public, private)
[20:34] <cjwatson> autopkgtest for firefox 23.0~b4+build1-0ubuntu1: RUNNING (Jenkins: public, private)
[20:34] <cjwatson> says http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[20:34] <infinity> I thought I had an ignore on colord.
[20:35] <infinity> Oh, I did, but someone updated the package.
[20:35] <cjwatson> firefox genuinely seems to be running - it's in xpcshell-tests
[20:35] <infinity> Someone updates colord, ostensibly to fix the tests.
[20:35] <infinity> This seems to have no gone as well as hoped. :P
[20:35] <ogra_> ah, just many deps to check then
[20:35]  * infinity updates his hint for now.
[20:35] <cjwatson> (I think; the logs aren't timestamped adequately)
[20:36]  * ogra_ bppkmarks
[20:36] <infinity> RAOF: Your attempt to fix the colord tests didn't quite go as planned.
[20:36] <ogra_> *book too
[20:36] <ogra_> cjwatson, thanks !
[20:38] <Laney> infinity: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-colord/ARCH=i386,label=adt/lastFailedBuild/console
[20:38] <Laney> Might not be RAOF's fault :-)
[20:38] <cjwatson> Hah
[20:38] <cjwatson> Let me see about retrying that then
[20:39] <Laney> Wait.
[20:39] <Laney> I might be reading that wrong
[20:39] <Laney> 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] <cjwatson> dsc0t-make-check     FAIL status: 0, stderr: ../../test-driver: line 95:  6191 A...
[20:39] <infinity> ../../test-driver: line 95:  6191 Aborted                 (core dumped) "$@" > $log_file 2>&1
[20:39] <Laney> yeah
[20:39] <infinity> make[2]: *** [test-suite.log] Error 1
[20:39] <cjwatson> Yeah, genuine failure
[20:39] <Laney> Don't just scroll to the end :P
[20:39] <cjwatson> 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] <infinity> cjwatson: Bah, CLOSE ENOUGH.
[20:40] <infinity> My pam_dwim module would have accepted that as a password.
[21:55] <stgraber> 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] <stgraber> hmm, actually ignore that, it's wrong
[21:57] <stgraber> 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
[22:00] <stgraber> cjwatson: http://paste.ubuntu.com/5882366/ should address that
[22:01] <stgraber> 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