=== FJKong_afk is now known as FJKong [01:16] infinity: oh. hope you're feeling better. are you still around? [01:25] dobey: Ish. [01:28] infinity: just uploaded a new ubuntuone-client for saucy-proposed, and about to do the same for precise-proposed, if you could accept them? [01:36] dobey: I will have a look, yeahp. [01:37] infinity: and precise-proposed uploaded too. thanks much. i'll test as soon as they're built in -proposed [01:41] dobey: Done and done. [01:43] thanks! [01:58] * dobey wonders how long it will take for them to show up in the archive === beisner- is now known as beisner === sz0 is now known as sz0` [02:18] sigh, i wonder if it's virtualbox that makes setting the time so difficult, or what [02:22] dobey: "date -s ..."? [02:23] dobey: Preferably in the VM, not in the host, if you value your sanity. [02:23] sanity? what's that? [02:24] in saucy i can set the date ok from the system settings [02:24] but in the precise vm it keeps automatically changing back to the current date [02:24] no idea why [02:25] dobey: Some "use network time" tickbox being overexhuberant, perhaps? [02:25] dobey: But setting it from a terminal should do fine, I'd think. [02:25] maybe, but i unchecked it (you can't actually change the date with the radio button set to "automatic") [02:26] nope, date -s doesn't help [02:27] Your VM hates you... [02:27] it set it for a few seconds, but by the time i typed the command to start u1 and connect, it had already changed back :( [02:27] I'd suggest ntpd is running, but ntpd usually gives up if you're too far out of sync with reality. [02:28] ps doesn't show any ntpd [02:28] whee [02:30] and i unplugged the network and it still gets reset [02:30] so yeah, precise vm is hating me [02:30] I can't imagine what would be resetting it. [02:31] yeah, me either :( [02:31] If in doubt, blame g-s-d? [02:31] wfm [02:31] Though killing g-s-d wouldn't be so helpful if what you're testing needs it. :P [02:32] ok, so the notifications are still weird on precise (but i think tthat's a bigger bug in the code that we don't really have time to fix at this point) [02:32] I wouldn't be aboe blaming indicator-datetime, or similar, either. But I'm just grasping at straws, without staring at the VM in question. [02:32] but the connecting post-june-1 fix is working right on precise [02:32] s/aboe/above/ [02:33] dobey: If you're happy enough with the state of those packages, then, we'll just let 'em in. [02:33] dobey: I don't want to delay any longer unless you think you can fix the weird notification thing in short order. [02:35] infinity: i don't think we can fix it. i just now changed the bug to verification-done and added a comment to that effect. i think we should push the update out now [02:36] dobey: Alrighty. Doing. [02:37] mdeslaur: Around? [02:37] infinity: thanks a lot for your help with this. [02:37] jdstrand: Or you? [02:37] Oh, wait, I think the security team might be on European time... [02:39] infinity: what's up? [02:39] mdeslaur: Any qualms about me pushing the above ubuntuone-client update to precise-security as well, overwriting what you have in the pocket? [02:40] mdeslaur: I think it'd be monumentally confusing to the 2 people who run security-only without updates when the package explodes and stops working correctly on Jun 1. :) [02:40] infinity: no qualms at all, go right ahead [02:40] mdeslaur: Ta. [02:40] does it need to be rebuilt with only -security though? [02:41] Seems pretty unlikely, but maybe I should have double-checked before hitting enter. [02:41] * infinity quickly goes to look at deps. [02:42] mdeslaur: binary deps all looks safe. [02:44] infinity: cool === FJKong is now known as FJKong_afk [02:45] hooray [02:51] mdeslaur: Speaking of things that aren't technically security updates but screw with people who run security-only, I wonder if we should chat about tzdata sometime. [02:52] hrm, interesting [02:52] yeah, I guess that could go into -security too [02:52] mdeslaur: I mean, the part where we've never had complaints either means no one actually runs security-only, or the people who do are all in regions with stable timezones. :) [02:53] mdeslaur: Cause you tend to notice pretty quickly when tzdata is wrong for you. [02:53] I've always been really curious as to how many people actually do run -security only [02:53] Me too. I'm not even sure how we'd go about mocking pseudo-metrics for that, let alone good ones. [02:54] Could start with maybe looking for desktop apps that are out of sync between security and updates and reporting crashes to errors. [02:54] when someone enables unattended updates during the server image install, that's security only, right? [02:54] Not sure. [02:54] is the implicit conversion to pointer failure really necessary on amd64? it only inevitably causes a problem on ia64, and Debian only checked on ia64 buildds (but we fail builds on amd64 as well) [02:55] Unattended-Upgrade::Allowed-Origins { [02:55] "${distro_id}:${distro_codename}-security"; [02:55] }; [02:55] hrm, interesting [02:55] mdeslaur: The default conffile comments out other pockets, so yeah, I guess. [02:55] /etc/apt/apt.conf.d/50unattended-upgrades [02:55] weird [02:56] I always thought it would be used more by server users than desktop users [02:56] Logan_: Yes. [02:56] my server has backports and updates in the list when i do "apt-get update" [02:56] Logan_: It's actually worse on amd64 than ia64, in that it's a guaranteed runtime explosion on ia64, and it's nondeterministic "wheeee!" on amd64. [02:56] dobey: when done manually, yes [02:56] infinity: I see - but then why doesn't Debian do it? [02:56] dobey: when done automatically by unattended-updates, no [02:57] Logan_: Plus, it's always a bug. And a bad one. Even on 32-bit arches, it usually points to a bad bug elsewhere (like an implicit declaration). [02:57] mdeslaur: oh, that's kind of weird [02:57] Logan_: Debian failed for it on ia64 because LaMont ran those buildds. Guess who wrote the code that fails it on our buildds? :) [02:57] I see :P [02:58] Logan_: Anyhow, I'm the one at "fault" for extending the check to all 64-bit arches, but with good reason. [02:58] Logan_: I'm tempted to extend the check to all implicit declarations as well, as they cause more interestingly subtle bugs. [02:58] what's weird is that I just synced over your delta for jmagick because I didn't get any references to "implicitly" in my pbuilder log, but it happened on the build [02:58] any idea why that's the case? [02:58] *buildd [03:00] I'll obviously reinstate your changes, but I don't get why I didn't get those warnings in my local build [03:00] Logan_: What arch was your local build on? [03:00] amd64 [03:00] Also, wow, this code is a mess. I must have been very tempted to rewrite half of it last time I was in there. [03:02] should I use sbuild instead or something? or would that not make a difference? [03:03] Logan_: I don't see why it would make a difference. I'm doing a test build here. [03:05] infinity: oh wait - is the line "Function `getByteArrayFieldValue' implicitly converted to pointer at magick_MagickImage.c:3454" injected into the log? [03:05] because it occurs right beneath a warning in the buildd log [03:05] and that's what I grepped for in my local build log [03:05] Ahh, yes, that's inserted. :) [03:05] grrr :P [03:05] rewriting history [03:06] * Logan_ begrudgingly reintroduces the delta [03:07] Logan_: http://bazaar.launchpad.net/~canonical-launchpad-branches/launchpad-buildd/trunk/view/head:/lpbuildd/check_implicit_pointer_functions.py [03:07] Logan_: That's responsible for the insertion. [03:07] ah, I see [03:08] I think I'll also forward your patch to Debian once I upload this, unless you want to [03:08] It's already there. [03:08] tbh, it should be upstream [03:08] oh [03:08] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727776 [03:08] Debian bug 727776 in jmagick "jmagick implictly declares getByteArrayFieldValue due to missing prototype" [Important,Open] [03:09] alright, reupped with the patch [03:10] thanks as always :P [03:10] Reading that build log just makes me cry. [03:10] How do people never actually check the output of their compilers? [03:12] I like all of the deprecated functions [03:12] That's to be expected, as the thing they're building against moves on... [03:12] But all the type mismatches have probably been there since day 1. [03:12] I don't think that's an underlying API moving. [03:12] That's just lazy programming. [03:13] erm [03:13] one of the functions they use, DestroyImages, has been deprecated in ImageMagick since 2002 [03:13] Hahahaha. [03:13] Okay, some lazy there too then. :) [03:17] If we turned on -Wall -Wextra -Werror, we could probably reduce the archive size by 90%. [03:17] So tempting. [03:18] we're not supposed to babysit upstream :P [03:20] as nice as it would be to remove warnings from all packages in the archive, it ain't gonna happen with our limited devs [03:20] I know. It's a pipe dream I'll never realize. [03:21] So, I'll go back to nursing my flu instead. === sz0` is now known as sz0 === sz0 is now known as sz0` === Ursinha is now known as Ursinha-afk === elky_ is now known as elky === Ursinha-afk is now known as Ursinha [05:22] Good morning [05:49] dobey, infinity: Yeah, Virtualbox does mess with the clock [05:49] I think it keeps the VM's hardware clock synced with the host or something [05:50] Which is annoying if you need to mess with the clock inside the VM [05:50] But I think there's a way to turn it off -- if not in the GUI, then with vboxmanage [05:50] michagogo: That's completely broken behaviour... [05:50] Of course, the best way to avoid it is to use kvm or Xen. :P [05:50] Heh, starting to google for "virtualbox disable..." first suggestion is "time sync" [05:55] infinity: You'll be in Malta next week, right? === Ursinha is now known as Ursinha-afk [05:59] RAOF: Aye. [05:59] siretart: I'm rejecting the libav binaries from the queue, so we don't half-start the transition on 4/6 arches. [05:59] siretart: If you need help figure out the arm64/ppc64el build failures (in both cases, it looks like perhaps bad assumptions about the compatibility of vector assembly), ask. [06:01] infinity: Rad. It might be time to get to that AA training. [06:03] RAOF: Yeah. I'm trying to get arges to be a limited-scope AA just to be able to back me up for kernel SRU stuff (which requires AA because reasons), so maybe the three of us should spend some quality time together. [06:05] cjwatson, xnox: I got a ucf prompt on upgrade from trusty->utopic for /etc/kernel-img.conf. Does d-i or ubiquity set this up for us on install, or was this my own doing? [06:06] slangasek: d-i creates it, I believe, but what on earth thinks it owns it all of a sudden? === Ursinha-afk is now known as Ursinha [06:06] infinity: "kernel-common", because Manoj woke up [06:06] And by “requires AA because reasons” what you mean is “needs to be a member of ~ubuntu-archive because LP permissions”, as *I'm* a member of ~ubuntu-archive for the same reasons. [06:06] slangasek: Ah-ha. So, yeah, it was completely unowned in Ubuntu until then. [06:07] RAOF: Yeah, that. ;) [06:07] RAOF: But if we have people we "shouldn't" have in ~ubuntu-archive, I also want to make sure they're prepared to flex those permissions sanely when needed. [06:07] (Or to remove them) [06:08] (Or to get notes from their mothers promising they won't touch anything) [06:08] That's what I've done :) [06:08] People ask for things not-SRU-related, and I say “sorry, no can do” ☺ [06:08] slangasek: Did kernel-common always "own" it, and we only just recently pulled it in as a dep of something else? [06:08] slangasek: I don't have it installed here... [06:09] infinity: no, from the changelog kernel-common is a new package; I had kernel-package installed for $reasons, and on upgrade it pulled in the new kernel-common [06:09] slangasek: Indeed, new in sid and utopic. [06:10] slangasek: So, that's entirely Manoj's fail. He can't just take over a config file like that. Go forth and smack him. [06:10] infinity: so I think we want to fix kernel-common to /actually/ install a file that matches what the installer does, or else launch the new package out of an airlock if we don't want it in utopic [06:10] infinity: is this a bug also in Debian? [06:10] slangasek: Yeahp. [06:10] infinity: you want to do the smacking? :) [06:10] slangasek: kernel-img.conf has the same semantics there, both its use in kernel postsints, and its unowned (until now) status. [06:10] slangasek: You discovered it, smack on. [06:11] infinity: you seem to have a better handle on the details, surely the smack would be more effective from you :) [06:11] slangasek: I tried. Can't tab complete his name in #debian-devel. I give up. [06:18] infinity: relatedly, why do we still create /vmlinuz and /initrd.img links by default? That's silly [06:19] slangasek: You mean why do we not default to link_in_boot=yes, or why have the links at all? [06:20] infinity: if we're going to have them at all, they should be in /boot, not somewhere that may be a separate filesystem; and the bootloader no longer uses them on x86 so we should probably not have them at all [06:20] slangasek: Except for the 7 people who still use lilo, yeah, no one else uses them, I imagine. [06:21] slangasek: But absolutely agreed that if we have them, they should be in boot (and I always alter my config to do so). [06:21] me too [06:22] Anyhow, looks like the kernel-common thing was an overzealous reply to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626216 [06:22] Debian bug 626216 in kernel-package "Manpage should live in a different package" [Minor,Fixed] [06:22] I'm thinking just putting the manpage in linux-base and keeping the rest alone would have been saner. :P [06:22] I have do_symlinks = no, and yet /vmlinuz is a symlink to latest kernel [06:23] StevenK: That's because it's do_symlink [06:23] Hah [06:23] I also don't have a kernel-img.conf manual page, which is helpful [06:24] Oh, hrm. No. It's do_symlink in the code, but do_symlinks in the config file. Whee. [06:24] Hahaha [06:24] infinity: Is this where I say "You're welcome." and back away slowly? :-P === Adri2000_ is now known as Adri2000 [06:56] Hi, can I ask somebody of the buildd team to retry a build failed? [06:56] https://launchpad.net/ubuntu/+source/wxwidgets3.0 [06:56] https://launchpad.net/ubuntu/+source/wxwidgets3.0/3.0.0-3/+build/6030586 [06:57] don't know, "compiler segmentation fault" doko_ do you have any idea? [06:57] maybe just a retry is enough === fginther` is now known as fginther [07:09] LocutusOfBorg1: Retried, but I bet it fails again. [07:10] thanks infinity I hope not :p [07:11] I would like to upload some packages that use wx3.0 on debian [07:12] I don't want to see them in proposed until somebody retries/processes them, and I need at least the wx -3 release [07:12] because of the new package [07:19] pitti: Your patches to do rebuilds with dpkg-buildpackage for linux/glibc fail because there's no fakeroot. That needs to be in the deps. [07:19] * infinity wonders if this is worth killing his sid build to fix... === _salem is now known as salem_ [07:23] infinity, pitti, yeah the rebuild fixes for linux fail for lack of fakeroot as well [07:23] apw: Yeah, that's where I noticed the bug, and am now fixing it in glibc. ;) [07:24] infinity, so ... why isn't that build-essential [07:24] ie ... already installed [07:24] apw: Because it's not. gain-root is buildd-specific. [07:24] apw: http://paste.ubuntu.com/7504510/ [07:24] apw: That's what I'm applying to glibc, something similar should do for the kernel. [07:25] :( g++: internal compiler error: Segmentation fault (program cc1plus) [07:25] Please submit a full bug report, [07:25] infinity, oh, i see ... unexpected but ok ... will get that applied to the kernel, not sure i want to upload for it though, uggg [07:25] LocutusOfBorg1: File a bug on gcc-4.8 and poke doko about it. [07:25] apw: Don't bother uploading for it, just queue it up. [07:26] infinity, also is there anything i can _test_ these changes on do you know [07:26] apw: I'll just be naughty and ignore the -2.6 tests, if the other tests pass. [07:26] infinity, thanks :) [07:26] apw: There's a magic wiki page somewhere about how to do adt at home. I always lose it... [07:27] apw: http://packaging.ubuntu.com/html/auto-pkg-test.html [07:27] infinity, also does the error line in p-m make sense to you, the version it reports for linux [07:27] apw: The version there is completely bogus, yes. [07:27] jibel: What's up with that? [07:28] jibel, http://paste.ubuntu.com/7504521/ is what it was saying [07:29] jibel, everything is right there in the sense there is a regression, but it is not in that version of linux [07:30] ok wilco [07:31] does anybody knows why cppcheck is still in proposed queue? https://launchpad.net/ubuntu/+source/cppcheck [07:32] LocutusOfBorg1: Causes two packages to become uninstallable. [07:33] Or, rather, the tinyxml2 transition does. [07:33] Why is there a library in those metapackages? :/ [07:34] * infinity fixes... [07:37] thanks :) [07:37] doko_, ----> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1322485 [07:37] Launchpad bug 1322485 in gcc-4.8 (Ubuntu) "wxwidgets3.0 arm64 fails to build with gcc 4.8" [Undecided,New] [07:42] apw, infinity looking [07:45] jibel: It's not actually causing a problem currently, but the reporting having the wrong version is definitely confusing. :P [07:48] infinity, right, and in the logs of britney it's the correct version "Collected autopkgtest status for linux_3.15.0-2.6/linux_3.15.0-2.6: FAIL" I'll investigate further after the sprint today === klubko is now known as naivka === FJKong_afk is now known as FJKong [08:21] hey [08:22] mvo: running update-manager on utopic today I've noticed that checkboxes next to package names are cropped (about 30% on the left) [08:26] zyga: I can reproduce this, thanks! this smells like iz gtk bug because I don't think we changed update-manager in utopc much. just a internal change fo the meta-index stuff, nothing in the UI [08:27] mvo: yeah, I suspect that as well [08:27] mvo: want a bug report for that? [08:27] * zyga wonders how to file that bug ;) [08:27] if I use ubuntu-bug it will say packages are outdated [08:28] zyga: lets discuss in malta, then I can nudge seb128 diretly to fix it :P [08:28] if I update I cannot show the bug ;0 [08:28] zyga: hihi [08:28] heh, sure :) [08:28] mvo: I'm not in malta btw [08:28] mvo: are you guys still there? [08:28] zyga: aha, ok. I will fly there sunday [08:28] oh, I heard some folks are there for a week or so [08:28] nice place to sprint! [08:29] zyga: I never went there, I'm curious about it [08:29] mvo: 'iz gtk bug'... Haven't seen that in a while. :) [08:29] I don't see that problem btw and gtk hasn't really changed in utopic yet [08:30] infinity: soon it will be "iz qt bug" :P [08:30] Laney: oh? hm, hm [08:31] well, unless I don't know what I'm looking for :) [08:32] it looks like http://ubuntuone.com/0ZlmWracPK89WzWSAUMAdf [08:33] Laney: the gtk treeview paints the "triangles" wrong and cuts parts of the text. once a expander is clicked (or theme is changed) it is ok again. simple resize is not sufficient [08:38] Laney: http://ctrlv.in/335583 [08:40] Laney: Getting the most out of that service before June 1? :P === sz0` is now known as sz0 [08:41] if a package does not work at all as it does not support the software version in trusty, but a new upstream version does, can one SRU the new upstream? [08:42] (subversion 1.8 and eclipse subversion plugin are the packages in question) [08:42] jtaylor: If that's literally the only way to fix it, perhaps. [08:42] infinity: Old habits die hard :P [08:42] jtaylor: I assume it's the plugin you're talking about, not updating SVN itself? [08:43] infinity: tinyxml library is used by gallery-app click. [08:43] yes [08:43] technically its a java library the plugin uses [08:43] jtaylor: How scary is the delta, and can the necessary bits be backported? [08:43] didn't look [08:43] I'm wondering if can safe looking as there is zero regression potential [08:43] it can't get worse than does not work at all [08:44] xnox: Yeah, I saw the note in the seeds when I fixed it. Gross that we're seeding libraries due to underrepresented (or unrepresentable) deps. [08:44] infinity: hence it's in the touch seed, i've filed bug to either get tinyxml into the click itself, during click build. or move from tinyxml to qt. [08:44] infinity: cause camera-app click to longer depends on tinyxml. [08:44] jtaylor: Yeah, that's a pretty valid argument, I'd still like to see the proposed diff. :) [08:45] svnclientadapter is the source [08:46] You'd think 1.8 would work with 1.8... [08:46] Silly people. [08:47] I don't think the versions are coupled [08:47] utopic has 1.10 [08:47] I'll check if a rebuild works first [08:47] jtaylor: Is it svnclientadapter or libsvn-java that's the problem? [08:48] (installing utopic in trusty works fine) [08:48] the adapter [08:48] its got a version == 1.7 check in it [08:51] Are you getting this string? "Incompatible JavaHL library loaded. Subversion 1.7.x required." [08:51] yes [08:51] the diff to utopic is not large [08:51] but I don't see time well spent in backporting [08:51] Theoretically, the package had a patch for that... [08:52] Oh, no it didn't, I can't read. [08:53] I'll file a bug that the package should have a stricter svn dependency [08:53] But that one delta to src/javahl/org/tigris/subversion/svnclientadapter/javahl/JhlClientAdapterFactory.java might fix it. [08:53] yes, but is it really worthwhile testing if that is enough? [08:53] infinity, apw: argh, sorry about that; thanks [08:54] upstream tested utopic with 1.8 [08:54] so we should use that for trusty [08:54] apw: right, I don't think you need to upload just for that -- new kernels come often enough anyway? :-) [08:54] instead of trying to do a partial backport [08:54] pitti: Should this be the right fix? http://anonscm.debian.org/viewvc/pkg-glibc?view=revision&revision=6105 [08:55] pitti: Identical commit was made to the kernel. [08:55] jtaylor: Sure, bumping the version might be the saner thing to do, just want to explore options. [08:55] jtaylor: It's certainly not an enormously scary diff. [08:56] apw: BTW, http://people.canonical.com/~pitti/tmp/linux-autopkgtest/ are the updated tests for linux-exynos5 (now including fakeroot) [08:56] apw: that also restricts the test to armhf, to avoid a failure on x86 [08:56] infinity: looks good; -rfakeroot should be the default these days though? [08:57] pitti: It is, but if we're explicitly depending on a specific gainroot, I feel we should also explicitly call it. [08:57] *nod* [08:58] pitti: Why the need to restrict tests to armhf when the source only produces armhf binaries? That seems like a test infra issue, not something that should be literring tests. [08:58] pitti: It makes exactly zero sense to run tests on an arch the package doesn't build for. [08:59] ah, I guess we could apply some debian/control parsing magic to find that out, yes [08:59] pitti: Or just read the .dsc [08:59] pitti: Oh, but you only work with unpacked trees? [09:00] Anyhow, that package is also buggy and claims to build arch:all packages that it can't possibly. [09:00] infinity: tree, .dsc, or (as in production) apt-get source [09:00] I fixed that in linux-ppc long ago, I guess the stupid carried over. :P [09:00] so debian/control it is [09:00] pitti: Kay, apt-get source gets you a .dsc, which is much easier to parse than control in this case. [09:00] But meh. [09:01] First, control needs to be fixed to stop pretending it builds things it doesn't. [09:01] apw: Where is the exynos5 git? [09:01] xnox: does the click package in question actually link against tinyxml directly, or is it perhaps via libmediainfo? [09:01] well, needs to work for anything, so debian/control it is; but the parsing isn't the problem really, it's figuring out from the Architecture: fields whether or not this applies [09:01] xnox: (compare gallery-app.deb) [09:01] infinity, now why did i need to know that already this week [09:02] pitti: Sure. In this case, you'd (rightly) guess wrong, I think, since there are arch:all debs, but there shouldn't be. [09:02] Oh, wait, the git is right there in the control. I wonder if it's right. [09:03] cjwatson: actually, i think you are right. I'll test that out. [09:03] infinity, i'd assume it is git://kernel.ubuntu.com/hwe/ubuntu-trusty-meta-exynos5.git [09:03] infinity, i'd assume it is git://kernel.ubuntu.com/hwe/ubuntu-trusty-exynos5.git [09:03] apw: Yeah, that's what I'm cloning right now. [09:03] apw: Do you have write access to that, or do I need to bug ike with a patch? [09:04] i should have, but will check [09:04] infinity, that repo is _ahead_ of the archive [09:04] apw: That seems reasonable... [09:05] zinc needs a go-faster button. [09:06] i do have write access to it indeed, though this out of sync fun makes life trixy [09:08] xnox: objdump -p | grep NEEDED should show it [09:09] cjwatson: right. it has NEEDED libmediainfo.so.0, and no mentions of tinyxml. [09:10] cjwatson: so infinity's seed change can go it & unblock that transition. [09:10] xnox: It's already in... [09:11] final: cppcheck,libmediainfo,tinyxml2,ubuntu-touch-meta [09:11] SUCCESS (26/0) [09:11] i wonder if i should be subscribed to -changes mailing list =) [09:11] I had to do that update by hand, though. Turns out ./update doesn't work so well when the thing you're seeding only exists in proposed... [09:11] Quite annoying. [09:22] it sounds like the correct seed change (given the intent) would actually have been to seed libmediainfo0 directly. [09:25] Perhaps, yes. I was just following the ABI change, this was before anyone did analysis into the why. [09:25] libmediainfo0 appears to already be there anyway. [09:26] So libtinyxml and libzen could both go away from the seed, I'd think. [09:27] But I'll leave that to someone who knows more about this stack. [09:28] pitti: So, the bug where exynos5 claims to build packages it doesn't will be fixed in the next upload, at which point a parsing of debian/control or .dsc will return nothing but armhf. [09:28] pitti: Which, to me, seems much saner than arch-restricting the test in the source, but YMMV. [09:33] pitti: OTOH, I'm not sure there's value in that test in that source anyway. The point of the glibc/linux/binutils/gcc rebuilt test circle is just to make sure no part of the toolchain breaks another part. I'm not sure there's much extra value in making sure every out-of-tree kernel builds. [09:35] hallyn: So I belatedly looked through your log from last night. Your problem is that your preseed file isn't being read at all. You either need to add file-preseed to your image (build/pkg-lists/netboot/common, probably), or (perhaps easier) given that you're embedding the preseed file in the initrd anyway, just embed it specifically as "/preseed.cfg", at which point it will be read automatically and you can drop the file= boot ... [09:35] ... parameter. [09:36] (We should perhaps add file-preseed to netboot images at some point, since it's in Debian's) === vrruiz_ is now known as rvr === salem_ is now known as _salem [11:15] infinity: yes, I could really use some help on those two ftbfs. for arm64, I guess it would be a matter of identifying the upstream commits in master that need to be backported. Please tell me and I see to include them for 10.2 [11:15] infinity: for ppc64, I have no idea what this is supposed to mean, nor what could be causing it: /usr/bin/ld: libavcodec/libavcodec.a(fft_altivec_s.o): ABI version 1 is not compatible with ABI version 2 output [11:16] siretart: It means it's trying to link a big-endian and little-endian object together. [11:16] siretart: Which probably means the Altivec bits are endian-specific. [11:16] I guess we could disable altivec on ppc64 and neon on arm64 [11:16] siretart: Which should be fixed, but the easiest solution would be to disable altivec on ppc64el. [11:17] do we have PPA where I could do the testbuilds, or can you take care of that? [11:17] siretart: And I haven't looked at the neon code in question, but it's probably similarly buggy in assuming neon == armv7t2 or some such. [11:17] siretart: I can do some test builds for you, though possibly not right this instant. [11:18] no problem, take your time [11:18] if we can push this transition before the beta, that'd be great [11:18] siretart: That seems like a pretty doable goal. [11:19] while the transition is not fully over, libav reached testing yesterday, and going with libav9 is imo a no-go for utopic [11:19] siretart: So, with libav9, was it using altivec on ppc64el and neon on armv8? [11:19] siretart: If so, we should perhaps figure out what broke in each case. [11:19] siretart: But I'd suspect it never was before, and now it's detecting "correctly", which happens to be incorrectly for the code in question. [11:20] that's entirely possible [11:21] if you need help, you might want to talk to jannau on #libav-devel@freenode, he was doing most of the aarch64 work lately [11:21] siretart: Well, I'd happily just turn off both SIMD options and sort it out later, my only concern is that fixing it later might change the ABI. [11:22] --disable-neon in debian/confflags should do the trick then [11:23] in that case they will use the plain C version [11:23] I don't have ABI concerns here === MacSlow is now known as MacSlow|lunch [11:23] siretart: You don't have ABI concerns because you don't care if it breaks, or because you're positive the alternate SIMD implementations are opaquely hidden behind a stable ABI? :) [11:25] infinity: cjwatson: should cross-pkg-config, allow cross-compiling against non-multiarched libraries? [11:26] Err. I'd be inclined to say probably, since the worst it can do is make errors more confusing [11:27] cjwatson: ack, and it would unblock a lot of cross-compilation queries i'm getting in #ubuntu-unity, for leaf -dev packages that are not multiarched yet. [11:27] I don't think it's vital, since there are other fixes possible, but it probably smooths the path [11:27] How is it currently preventing it? [11:28] infinity: commented out /usr/lib/pkgconfig from PKG_CONFIG_LIBDIR in /usr/share/pkg-config-crosswrapper [11:28] It says " # If you want to allow use of un-multiarched -dev packages for crossing [11:28] # (at the risk of finding build-arch stuff you didn't want, if not in a clean chroot) [11:29] # Uncomment the next line: [11:29] " [11:29] My opinion on the spur of the moment on IRC doesn't necessarily override reasoned argument that you might find in the history, of course [11:30] xnox: Hrm. Perhaps changing that to be keyed off an environment variable instead of encouraging people to edit the script? :P [11:31] infinity: by default, it is keyed off environment. [11:31] cjwatson: Laney: infinity: i'm thinking this might be a simple regression, cause package was forced synced. [11:31] xnox: I can absolutely understand the reasoning. The errors would be confusing to the "average" person if they had wrong-arch libs found because of that. [11:32] xnox: Err, no, I mean that particular bit keyed off environment, not asking people to set the entire PKG_CONFIG_LIBDIR themselves. [11:32] Well, previous edition of pkg-config-wrapper was a two-liner: [11:32] triplet=`basename $0 | sed -e 's:-pkg-config::'` [11:32] PKG_CONFIG_PATH=/usr/lib/${triplet}/pkgconfig:/usr/${triplet}/lib/pkgconfig pkg-config $@ [11:33] xnox: So, that was buggy in that it missed /usr/share, and it also missed the directory you're talking about. [11:33] * xnox ponders what are the differences between PKG_CONFIG_LIBDIR & PKG_CONFIG_PATH [11:34] infinity: we used to prepend multiarch paths, now we replace all paths with multiarch-only without original. [11:34] which is regressing cross-buildability of a lot of touch stuff in ubuntu. [11:35] xnox: That's not what your paste implied. [11:35] I've already eaten this change for a few libraries, but letting people opt back in might be a good idea [11:35] xnox: Anyhow, if we were including /usr/lib/pkgconfig before, and no one was complaining about it being confusing, go ahead and uncomment that line. If you're positive that's how it used to work. Your paste certainly doesn't imply what you said, though. [11:36] Oh, I see. [11:37] PKG_CONFIG_PATH behaves differently. [11:37] Kay. [11:38] xnox: Yeah, possibly just the path of least reistance to uncomment that line in Ubuntu, since that was the previous status quo, if no one was complaining about the occasional breakage. [11:38]