[00:03] <slangasek> it's been deprecated in Ubuntu and Debian both for a long time, we're just not quite rid of it yet
[00:12] <YokoZar> slangasek: Thanks.  I'm working on merging msttcorefonts cause of bug 905055
[00:12] <ubottu> Launchpad bug 905055 in msttcorefonts (Ubuntu) "Package needs to be Multi-Arch enabled so Multi-Arch packages can depend on it" [Undecided,New] https://launchpad.net/bugs/905055
=== fenris is now known as Guest25296
=== Guest25296 is now known as ejat
[10:45] <S-I4> Is it possible to get tax deductions for donations made to ubuntu?
=== yofel_ is now known as yofel
=== Quintasan_ is now known as Quintasan
=== kalosaurusrex is now known as albrigha
[19:26] <micahg> cjwatson: so, the Ubuntu Studio images are failing to build due to being unable to find the task for ubuntustudio-font-meta, I think I found the issue, but wanted to check with you, it seems that font-meta depends on the graphics task, but it should really be the other way around, does that sound sane?  Also, if there's no dependent task, is something just dropped from STRUCTURE?
[19:42] <cjwatson> micahg: yeah, I was meaning to ask about that - it does kind of look as though graphics ought to inherit from font-meta, to me
[19:43] <cjwatson> bah
[19:43] <cjwatson> micahg: yeah, I was meaning to ask about that - it does kind of look as though graphics ought to inherit from font-meta, to me
[19:43] <cjwatson> micahg: no, don't drop it from STRUCTURE - you can have an empty list of inheritees, but it's probably more sane to have it inherit from minimal or something
[19:44] <cjwatson> or maybe even desktop-common
[19:44] <micahg> ok, thanks, will make the change, would you be able to rerun it after?
[19:44] <cjwatson> sure
[19:44] <cjwatson> (if you drop it entirely from STRUCTURE, the effect will be as if it's just a random file lying around in that branch, not a seed)
[19:45] <micahg> ah, ok, good to know, I pushed up a new revision with the fixes
[19:47] <slangasek> cjwatson: do you know why x-ttcidfont-conf is in the desktop-common seed?  It dates back to the founding of rome^W^W^W revid 1, and seems to be the only thing still keeping defoma in ubuntu-desktop... and is removed in Debian
[19:50] <cjwatson> slangasek: absolutely no idea; it probably seemed like a good idea at the time
[19:50] <slangasek> k
[19:50] <cjwatson> I'd have thought anything that actually needed it would depend on it
[19:50] <slangasek> I think I'll pull it and see if anyone screams then; if something actually needs it it ought to depend directly
[19:50]  * slangasek nods
[19:50] <micahg> cjwatson: can you respin Ubuntu Studio please
[19:51] <slangasek> the package seems to be primarily a defoma hook anyway
[19:51] <cjwatson> micahg: running
[19:51] <micahg> thanks
[19:52] <cjwatson> slangasek: it might have been needed in warty for some reason; but probably not worth figuring out now except destructively :-)
[19:52]  * slangasek grins
[19:53] <stgraber> anyone knows what's happening to language-pack-kde-wae? it's currently uninstallable (because language-pack-kde-wae-base doesn't exist at the same version) and so broke Edubuntu DVD builds for the last two days
[19:53] <cjwatson> I'd look through the pre-revision-control wiki history but somebody has either helpfully deleted it or hidden it VERY well
[19:54] <cjwatson> https://wiki.canonical.com/WartyWarthogDesktopSeed?action=info is the best I can do
[19:56] <cjwatson> https://wiki.canonical.com/WartyWarthogDesktopSeed?action=diff&rev1=74&rev2=75 - editor sabdfl, comment "sort out fonts"
[19:56] <cjwatson> slangasek: ^-
[19:56] <cjwatson> so I suspect the answer is "it looked font-related" :-)
[19:56] <slangasek> heh, fair 'nuff
[19:57] <cjwatson> micahg: failed, might be a slight delay on bzr+ssh -> http propagation or something
[19:57] <cjwatson> oh, no, it needs a publisher run
[19:57] <micahg> cjwatson: ah, ok, can you retry in an hour then?
[19:58] <cjwatson> micahg: more like half an hour but yes
[19:58] <micahg> ok, thanks
[19:59] <micahg> cjwatson: do I need a new meta upload for a STRUCTURE change?
[20:00] <cjwatson> micahg: not unless it results in metapackage dependency changes
[20:01] <cjwatson> micahg: it might be worth experimentally updating to see what happens, though; my suspicion is that you may need to change ubuntustudio-graphics to explicitly depend on ubuntustudio-font-meta (i.e. in debian/control) if you intend that dependency to persist
[20:01] <cjwatson> germinate-update-metapackage isn't great (partly deliberately) at inter-metapackage dependencies
[20:01] <micahg> ah, looks like it'll just update the Task
[20:01] <micahg> oh, wait, that's done separately, nevermind
[20:02] <micahg> cjwatson: it already was that way in the seed
[20:02] <micahg> ah the dependency shows up properly in the generated package
[20:03] <ricotz> hi, is there a proper way to define a build-dep in debian/control like this "libstdc++6:i386 [amd64]"
[20:05] <slangasek> ricotz: cross-arch build-dependencies are not permitted at this time; you can however build-depend on lib32stdc++6 [amd64]
[20:05] <slangasek> which may or may not have the desired result
[20:06] <ricotz> slangasek, i see, the reason doing this is i am having trouble to build-depend on "ia32-libs-multiarch [amd64]"
[20:07] <ricotz> slangasek, https://launchpadlibrarian.net/91366230/buildlog_ubuntu-precise-amd64.fglrx-installer_2%3A8.930-0ubuntu1~xedgers~precise1_FAILEDTOBUILD.txt.gz
[20:08] <ricotz> this might get solved by the next apt update
[20:08] <slangasek> ricotz: split the package based on the architecture of the contents, build the i386 bits only when building the i386 package, and structure the binary package dependencies to pull in the 32-bit-only package when needed
[20:09] <slangasek> consider it an accident that build-depending on ia32-libs-multiarch is working at the moment - one that infinity was encouraging us to fix
[20:09] <ricotz> slangasek, i know, debian is doing this more properly here for fglrx, but i am not the maintainer of the ubuntu packaging here
[20:10] <ricotz> so i not so confident changing it while not be able to actually test this driver myself
[20:10] <slangasek> but you care about the build failure, so I'm telling you the right way for it to be fixed :)
[20:10] <ricotz> slangasek, ok, maybe exp16 will work?
[20:10] <slangasek> no
[20:11] <ricotz> you are right ;)
[20:11] <slangasek> in general, build-depending on ia32-libs-multiarch is going to be fragile because it requires i386 and amd64 versions of your build-dependencies to be in sync in the archive at the time of build
[20:11] <slangasek> so it'll "sometimes" work... at least until the buildds are neutered to not allow pulling i386 packages in
[20:12] <ricotz> slangasek, yeah, i was hoping i have found a calm moment here
[20:12] <ricotz> but this could be a resolver issue as well
[20:12] <ricotz> thanks
[20:16] <slangasek> if you can show that it's a resolver issue, I'm certainly interested to know that
[20:16] <slangasek> but even so, the end goal is to make this configuration *not* work on the buildds :)
[20:25] <ricotz> slangasek, ;)
[20:29] <cjwatson> micahg: I know it was that way in the seed, but a package that's also in an inherited seed will get pruned from the dependencies ...
[20:31]  * cjwatson retries that build
[20:31] <micahg> cjwatson: I looked at the package in the archive and it seemed to have the proper dependency, are you suggesting that respinning will drop it?
[20:33] <cjwatson> micahg: that's what I was saying needed to be tested, yes, and perhaps replaced with an explicit dependency in debian/control if so rather than relying on the substvar
[20:33] <micahg> ah, ok, will test, thanks
[20:51] <slangasek> ricotz: the fglrx-installer package in the archive doesn't appear to have this ia32-libs-multiarch build-dependency?
[20:53] <ricotz> slangasek, i added it to fix resolving shlibs
[20:53] <slangasek> ricotz: ah
[20:53] <ricotz> slangasek, only the stdc++6 libs was still missing
[20:54] <slangasek> yeah, and libstdc++6 is available as a biarch package (lib32stdc++6), so that's the simple route
[20:54] <slangasek> long term, it's better to split the binary packages on architecture lines
[20:54] <ricotz> oh, i see
[20:54] <ricotz> right, i will replace it then
[20:54] <ricotz> for the time being
[20:58] <micahg> cjwatson: you were right about ubuntustudio-font-meta being removed from graphics
[21:01] <infinity> slangasek, ricotz: Worth noting that said neutering (ie: making amd64 buildds no longer multiarch) will be happening the next time the chroots are refreshed, the change to the scripts is already committed.
[21:01] <slangasek> ricotz: oh, in fact looking at the package I believe this is entirely due to an upstream bug
[21:01] <slangasek> $ file arch/x86*/usr/lib*/libSlot*.so
[21:01] <slangasek> arch/x86/usr/lib/libSlotMaximizerAg.so:      ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
[21:01] <slangasek> arch/x86/usr/lib/libSlotMaximizerBe.so:      ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
[21:01] <slangasek> arch/x86_64/usr/lib64/libSlotMaximizerAg.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
[21:02] <slangasek> arch/x86_64/usr/lib64/libSlotMaximizerBe.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
[21:02] <slangasek> $
[21:02] <slangasek> ricotz: upstream seems to have simply included a 32-bit library where a 64-bit library should have been
[21:02] <cjwatson> micahg: and the ubuntustudio DVDs built cleanly
[21:03] <slangasek> ricotz: so having it depend on lib32stdc++6 doesn't actually do anybody any good, AFAICS
[21:03] <astraljava> cjwatson: micahg: Thanks, guys! :)
[21:05] <ricotz> slangasek, ah, i see, this is bad :\