[00:01] doko: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52445 [00:01] gcc.gnu.org bug 52445 in tree-optimization "[4.6 Regression] conditional store replacement causes segfault in generated code" [Normal,Assigned] [00:01] doko: There are a few long threads around arm-linux and other lists about how that bug causes some kernel driver miscompilations. === cpg|away is now known as cpg [00:02] Now, if only I could remember who it was who brought it to my attention a few weeks ago... === fisted_ is now known as fisted === Guest5764 is now known as vibhav === vibhav is now known as Guest74795 === Guest74795 is now known as vibhav === vibhav is now known as Guest65373 === Guest65373 is now known as vibhav === vibhav is now known as Guest79079 === Guest79079 is now known as vibhav === vibhav is now known as Guest84459 === Guest84459 is now known as vibhav [01:14] jdstrand: Disabling normal.mod doesn't make sense. That's the module that provides the menu. [01:16] jdstrand: You should be able to copy /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed into your environment as grubx64.efi and execute it from firmware configured to trust the Canonical key (or via shim from firmware configured to trust the Microsoft key). [01:18] jdstrand: Or, if you already have an installed system that you're booting in OVMF rather than trying to bootstrap one from scratch, install the grub-efi-amd64-signed package and run 'grub-install --uefi-secure-boot'. [01:18] jdstrand: (I believe I have a work item to make that the default even on non-SB systems, with a few associated tweaks) [01:19] jdstrand: And rereading, it sounds as though you probably want the latter approach. [01:20] jdstrand: A message refusing to load normal.mod indicates that you've tried to sign a minimal GRUB image (perhaps the one generated by plain grub-efi-amd64) that's expecting to load much of its brain from /boot/grub/x86_64-efi/*.mod - but GRUB insmod is forbidden in secure boot because all the boot loader code must be signed. [01:41] The only rdp client I can get to connect is rdesktop, none of the rdp clients I've tried in 10.10 will connect. Is there some library that I need to add or something? [01:42] Sorry. None of the rdp clients with GUI front ends will connect. CLI is fine. [01:44] 10.10 is long out of support in any case. This isn't a help channel, but certainly not for old releases. [01:44] Shinobi: This isn't a support channel, try #ubuntu. Also, 10.10 is an EOL product, you might want to try 12.04 (or later) before asking for help. [01:44] ScottK: Jinx. [01:44] ;-) [01:46] infinity: Sorry. Nobody seemed to know in Ubuntu, so I thought I'd see if someone may have known. I plan to upgrade to 12.04 tonight. [01:56] Shinobi: I seem to recall some serious bugs that were fixed somewhat recently in one of the other rdp clients === Tonio_ is now known as Tonio_aw [02:54] cjwatson: thanks-- let me try grub-install --uefi-secure-boot. I that sounds like the missing piece-- but you gave a lot of info I can play with. much appreciated [03:08] cjwatson: that was exactly it. perfect-o! [03:09] cjwatson: huge thanks. I'll fiddle with the other options later as well (ie, Canonical key, shim, etc) === attente is now known as attente_zzz [05:37] Good morning [05:39] hi [06:22] infinity: do you plan to do an initramfs-tools merge soon, or want me to ignore the warning in u-d-common for now? [06:25] pitti: I plan to merge tonight or (more realistically) first thing in the morning. That eglibc upload I just did a couple of hours ago was occupying me. [06:26] infinity: ah cool, thanks! [06:43] doko_: Ugh. Shouldn't there be a /usr/include/i686-linux-gnu to match the cross target, rather than i386-linux-gnu to match the Debian arch (or maybe one a symlink to the other)? [06:44] doko_: Or maybe I get to special-case i?86 in glibc's configure and it won't be upstreamable. [06:45] * infinity ponders. [06:48] doko_: Yeah, all the stuff that used to be in /usr/include/c++/4.7/`g++ -dumpmachine` is now in /usr/include/$DEB_HOST_MULTIARCH/c++/4.7 which is subtly different on i386. [06:52] doko_: Oh, I guess I can conditionally use g++ -print-multiarch and still have this upstreamable. [06:52] * infinity kicks himself for only testing on amd64 and powerpc. [07:21] pitti: You wake up too early. It always makes me thing (very incorrectly) that I can start talking to other Germans and expect a response. :P [07:21] s/thing/think/ [07:21] hah, hardly [07:21] infinity: I usually start between 5:30 and 6:30 these days [07:22] pitti: I often stop around then... [07:23] So, now that armel's out of the archive, can we get rid of i386 too? [07:23] I'm sick of its quirks. [07:47] good morning [07:57] hey dholbach [07:57] hi pitti === smb` is now known as smb [08:13] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach [08:21] doko_: Alright, fix uploaded for glibc/i386, you can ignore my whining about dumpmachine versus multiarch. [08:21] dholbach: hey, FYI, I'll have to swap my pilot timing for Thu/Fri I guess [08:22] didrocks, sure - I'll leave that to you - I split up my patch pilot session yesterday/today because there was no other way [08:22] dholbach: ok ;) [08:23] Daviey: are you aware of the maas autopkgtest failure? It's reproducible locally as well (https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-maas/lastFailedBuild/ARCH=amd64,label=albali/) [08:23] Daviey: looks like a dependency or component mismatch issue === agateau_ is now known as agateau [08:25] didrocks, do you know if there's plans to get the new libnice from Debian experimental? it seems to be needed for bug 1078991 [08:25] Launchpad bug 1078991 in farstream (Ubuntu) "Sync farstream-0.2 0.2.2-1 (universe) from Debian experimental (main)" [Wishlist,Triaged] https://launchpad.net/bugs/1078991 [08:26] Setting up tgt (1:1.0.17-1ubuntu3) ... [08:26] start: Job failed to start [08:26] invoke-rc.d: initscript tgt, action "start" failed. [08:26] dpkg: error processing tgt (--configure): [08:26] subprocess installed post-installation script returned error exit status 1 [08:26] pitti / Daviey : That's your bug ^^ [08:27] dholbach: I didn't hear about any blocker on that, it seems it didn't change its soname, and have gstreamer 0.10 and 1.0 bindings [08:27] dholbach: so if you want to test/sync… ;) [08:28] why did Robert file a sync request for this and not just sync it? [08:28] Maybe he still lives in the past and no one's told him he can sync things? [08:29] pitti: i am now :).. thanks. We'll get that fixed up today. [08:29] dholbach: maybe he's not aware we can sync directly [08:30] Curious, tgt starts here just fine. [08:33] Daviey: great, thanks; I start prodding people now as soon this will become critical path, and you couldn't land uploads any more when their tests fail [08:33] I got a lot of them fixed, but I can't keep up with them all [08:33] pitti: Curiously, I can't make it fail locally. [08:33] (Not that I care terribly, cause I should be napping, but I figured I'd give it a try) [08:34] "run-adt-test -s maas" fails with the same reason [08:34] pitti: Sure, I was just installing the package that failed to start, rather than running the full test environment. [08:35] pitti: Perhaps it fails to start because the daemon relies on a recent kernel? [08:35] pitti: well, fixing it directly in the archive wouldn't last.. as this package is strictly managed via bzr. [08:36] infinity: the kernel in the VM is just as recent as raring is [08:38] Was just a thought, since I can't make it die in a quick test here. [08:41] mvo: do you happen to understand the metaclass magic in aptdaemon in https://code.launchpad.net/~pitti/aptdaemon/pygobject-fixes/+merge/134942 ? [08:41] mvo: I wondered if it can/should be fixed, or just dropped completely for simplicity [08:43] infinity, Daviey: "sudo apt-get install tgt" in a VM reproduces it well [08:43] I'll file a bug with the details [08:43] pitti: Right, it's the "in a VM" bit I'm missing here. :P [08:43] pitti: Worked fine in a chroot on bare metal, which is curious. [08:46] Daviey: I filed bug 1081495 with the output of tgtd [08:46] Launchpad bug 1081495 in tgt (Ubuntu) "E: Sub-process /usr/bin/dpkg returned an error code (1)" [Undecided,New] https://launchpad.net/bugs/1081495 [08:46] pitti: Oh, out of curiosity, do you have autopkgtests for eglibc, binutils, and gcc? [08:46] infinity: no, we don't [08:46] infinity: well, the new eglibc triggered all autopkgtests that we have of course [08:47] so we do rdepends check [08:47] but not for eglibc itself [08:47] pitti: I'd suggest (since things like "try to rebuild the whole archive lololol" would be pointless) they their tests should consist of each one triggering a rebuild test of the other two. [08:47] pitti: If upgrading any of those three manages to keep the testsuite of the others passing, that's a win. [08:48] infinity: i. e. the test script woudl more or less be "apt-get build-dep binutils; apt-get source -b binutils", right? [08:48] pitti: (This came up today after I just spent hours fixing a regression in glibc due to the new gcc, and the inverse happens all the time too) [08:48] pitti: Yeahp. [08:49] pitti: Oh, and linux-libc-dev (so, the linux source package) should also trigger those three to a rebuild test, same reason. [08:49] pitti: If linux-libc-dev's headers survive the GCC and glibc testsuites, they're good enough for regular users. :P [08:49] (And if they break regular users but not the toolchain, I'd humbly suggest the users are wrong) [08:50] *cough* [08:50] hehe [08:52] Definitely would have been nice to know when gcc and the kernel were uploaded (so, a couple of weeks ago) that they broke glibc, instead of finding out today while I was uploading for other reasons. [08:53] But, yeah, toolchain rdep testing needs to have some sane limits, cause I assume our resources aren't infinite (and our time certainly isn't, when we start plugging this in as a britney blocker) [08:53] so binutils seems to have a proper Vcs-Bzr:; gcc-4.7 is just apt-get source/UDD? [08:53] pitti: apt-get source is the only "proper" way to get any of them for a rebuild test... [08:53] infinity: yeah, bintuils and glibc tests are bearable, but gcc does take some time [08:53] pitti: We don't want to know if something staged in a VCS is broken, we want to know if the archive is. [08:54] infinity: no, I mean for adding the autopkgtests [08:54] these need to go into their source [08:54] pitti: Oh. These end up in the source package themselves? [08:54] yes [08:54] pitti: Right, forward the binutils and gcc ones to doko, the eglibc one to me, and the linux one to apw, then. [08:54] okay [08:54] pitti: I'd rather have a modicum of control over how often toolchains get uploaded for non-critical things. :) [08:55] yeah, I wasn't going to upload them just for that, hence I was looking for the VCSes [08:55] Righto. eglibc's VCS header is a filthy lie, I need to fix that. [08:56] And no idea about doko's. [08:56] And the kernel's isn't a lie, but you can't commit to it. :P [08:57] pitti: To cut down on the pain, we could potentially refine the tests to do something like only build a single pass of libc6 and run the tests, only build a single kernel, etc. Most of these things take so effin' long cause they build 4 times. [08:57] yeah [08:58] let's put that into a bug to keep track of the status and have a place to attach patches to [08:58] Be my guest. I'm thinking a nap at 2am might not be a bad plan. [08:59] * infinity snickers at jcm getting flooded off freenode. [09:00] pitti: If you file a big meta bug, can you toss me the number? I suck at bugmail filtering about as much as someone who doesn't put much effort into filtering bugmail. [09:00] (I should probably fix that some day) [09:01] infinity: bug 1081500 [09:01] Launchpad bug 1081500 in linux (Ubuntu) "Add autopkgtest for mutual rebuild-testing amongst glibc, linux-libc-dev, gcc, and binutils" [Undecided,New] https://launchpad.net/bugs/1081500 [09:02] pitti: Great. I look forward to patches that teach me all about autopkgtest by example. ;) [09:03] infinity: http://developer.ubuntu.com/packaging/html/auto-pkg-test.html : [09:03] :) [09:03] I don't accept HTML patches. [09:04] nah, I'll send a first one, and maybe a second [09:04] I expect they will look pretty much alike, except for the "only build one flavour" bit [09:04] The only one flavour bit may take some refinement. [09:05] The kernel's pretty good at it (you can call individual targets out of debian/rules), glibc might actually take some wrangling to convince it to try. [09:05] I'm happy to do that bit myself. :P [09:06] Anyhow, nap time before morning meetings. [09:06] yeah, once we enable those on armhf, any speedup will be greatly appreciated [09:07] Gah, and that override bug. [09:07] * infinity promotes kernels to main before going to bed. [09:07] good times [09:08] infinity: what TZ is infintytime aligned with atm ? [09:08] lifeless: all of them :) [09:08] lifeless: I reside in MST7MDT, I'm currently awake in... Actually, close to that. It's only 2am. Not a horrible bedtime. [09:09] pitti: I think that would get a dividebyzero error :) === Tonio_aw is now known as Tonio_ === Tonio_ is now known as Tonio_aw [09:43] jdstrand: cool === Tonio_aw is now known as Tonio_ [09:46] cjwatson: Having to override all the kernels in raring again after britney promoted them reminded me to be annoyed by that bug. Did you have something filed for it? [09:46] cjwatson: (Still wildly confused by why this happens for proposed->release but not proposed->updates, unless britney's somehow copying differently than sru-release does...) === Sweetsha1k is now known as Sweetshark [09:47] I don't think I filed one [09:47] I was just doing morning "oh, images failed, oh look, component-mismatches" [09:48] But the output suggests you beat me to it [09:48] Yeah, c-m is a lie, I already fixed. [09:48] Thankfully, you didn't notice until the publisher started. :P [09:48] That double-override-eats-binaries bug is also a lovely one. [09:49] And likely to get stumbled on a lot while this current "oops, I forget everything during migration" business is going on and people scrable to fix the release pocket. [09:49] s/scrable/scramble/ [09:49] Overriding twice to main doesn't count, though, since that doesn't actually produce new pubs. [09:50] Even if it was previously in universe? [09:50] * infinity is unfamiliar with that bit, and is suddenly happy he is. [09:54] infinity: By the time of the second override attempt, it's now in main so doesn't get re-overridden. [09:55] (Sorry, I was busy trolling a phone scammer.) [09:57] hey cjwatson, it's been 10+ minutes I tried to copy 3 components from the ubuntu-unity ppa to the archive, and it seems the first attempt failed :/ any way to see what happened? [09:58] tkamppeter_, hello - do you think you can have a look at https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/1069324 and see if you can upload the patch? [09:58] Launchpad bug 1069324 in hplip (Ubuntu) "diagnose_queues.py crashed with NameError in su_sudo(): global name 'utils' is not defined" [Medium,Triaged] [09:58] didrocks: If it failed, you should have gotten an email with an OOPS in it. Maybe. [09:58] infinity: the thing is that the bot is https://launchpad.net/~ps-jenkins and it's a ML. But mmrazik isn't around to check them [09:59] There's a bot auto-copying from PPAs to the archive? [09:59] infinity: Yeah, didrocks and I agreed on this [09:59] Fair enough. [09:59] didrocks: Package name? [10:00] cjwatson: indicator-sound, indicator-power and indicator-messages [10:00] "Cannot copy DDEBs to a primary archive" [10:01] ah, so we need to ask for removing the ddebs from the ppa [10:01] Hmm [10:01] (would have been useful for the autopilot crash though) [10:01] Yeah. [10:01] infinity: actually, didn't we want to enable that for the main archive? [10:01] pitti: We do, yes. Hit me up tomorrow, and we'll talk. :) [10:01] like if autopilot crashed with a stack, we would use those ddebs to debug [10:01] Nothing would take care of rebuilding the ddebs for the main archive, if you remove them [10:01] didrocks: It's a devirt PPA, right? [10:01] to replace those apache servers [10:02] Which would mean that errors.u.c will be unable to display useful tracebacks for those packages [10:02] cjwatson: No need to rebuild them. The trick is to do the same thing the kernel PPA does. [10:02] infinity: yeah, it's building on all archs [10:02] infinity: I thought you wanted to go to sleep an hour ago :) [10:02] cjwatson: Which is to act like the primary archive. [10:02] cjwatson: right, but the tests are runned before copying to the main archive, so being able to debug there was useful [10:02] cjwatson: IOW, not have the flag on that publishes ddebs in .changes [10:02] dholbach, I've already asked him to do that :) [10:02] mitya57, ok, perfect :) [10:03] infinity: And they then get picked up for ddebs.u.c? [10:03] Presumably as long as versions never clash. [10:03] cjwatson: Sure, they're all slammed in public_html. [10:03] Right. [10:03] The real solution is some JFDIing by pitti and I to switch this all over. [10:03] how does the kernel do to have ddebs? [10:03] as it's not rebuilt [10:03] And then scour the world for PPAs that do weird things and make them do what didrocks's does. [10:04] didrocks: The kernel's PPA acts just like the primary archive. It builds ddebs, but doesn't upload them. [10:04] didrocks: And they get scraped off the buildds by pitti's evil script, the same as they are for the primary archive. [10:04] cjwatson: we'd eventually like to stop having to stage them on the buildds for 7 days and those rather unreliable apache servers to publish them; I'd much rather pull them from the librarian [10:04] infinity: ah, ok, so evil hack :) [10:04] But yes, we should fix all of this hackish crap. [10:04] didrocks: In infinity's proposal, you'd debug by getting the ddebs from ddebs.ubuntu.com instead. [10:05] My proposal is the "right way" to do things today. [10:05] It may not be in a few days, if pitti and I get some ducks in a row. [10:05] well, ddebs.u.c. would continue to only publish Ubuntu ddebs; but copying packages from PPA into the ubuntu archive shoudl copy the ddebs along? [10:05] (The right way to do things if your PPA is essentially an extension of the primary archive, like kernel and security are) [10:06] pitti: In some new world order that might be possible, sure. I'm aware of the plans. [10:06] pitti: Yeah, in the new world order, ddebs would be attached to build records, and copying with binaries will get the ddebs too. [10:06] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [10:06] pitti: That part looks like it might need an LP patch, but likely just removing a check. [10:07] (We probably also need to test and make sure that the publisher doesn't try to vomit ddebs on disk when they show up in the primary archive) [10:07] I guess I might need to dust off a local LP instance tomorrow, since I don't have dogfood to play with. :/ [10:08] Aaaanyhow. pitti's right, I'm supposed to be asleep. [10:08] how can I help to make things happen? :) [10:08] didrocks: Depends on which things. [10:08] sing "soft kitty" to infinity, so that he gets to sleep, and is awake tomorrow? :-) [10:09] pitti: can do that :) [10:09] * infinity might not appreciate this so much. [10:09] infinity: I'm not really familiar with the whole copy to ddeb.u.c process, but if you think I can be of any help [10:09] infinity: Better to construct a unit test that exercises it, since you'll want one of those to go with any change anyway. === tkamppeter_ is now known as tkamppeter [10:10] cjwatson: Sure, this doesn't preclude the value of doing actual end-to-end testing to make sure it does what you think you claim the unit test is testing. [10:10] didrocks: For the meantime, you could copy without binaries. I know that strictly that partially invalidates your testing, but confirming that the source builds sensible binaries in autopilot is still a lot better than nothing. [10:11] cjwatson: well, if it's just a question of days, I think I'll better to wait [10:11] Or, he could ask webops to twiddle his PPA to make it look "like the kernel team's". [10:11] dholbach, I can do so. Simply for Raring or as Quantal SRU? [10:11] mitya57, ^? [10:11] But if you do that, you need to trat it like the primary archive, never reuse version numbers (even if you delete something), etc. [10:11] didrocks: It could be more than days to get this all tested and sane. I'm not about to commit. [10:12] didrocks: But it's seconds to make your PPA behave differently. [10:12] infinity: I already do that, depends on the timing for the "proper fix" in your mind [10:12] infinity: ok, so right now, asking webops to twiddle the PPA seems to more robust idea? [10:12] the* [10:12] tkamppeter, it would be good to have this SRUed if you plan a SRU, otherwise I don't think it's worth that [10:12] waiting for the real fix? [10:12] didrocks: Either that or, as Colin suggests, copying source-only. [10:13] didrocks: But the kernel PPA method DTRT for now. [10:13] I'm not confortable with that, as we won't have in proposed the real stack/build order we tested [10:13] didrocks: Where "the right thing" is "exactly the same awful hack as the primary archive". [10:13] infinity: yeah, I understood that ;) do you have anyone in mind knowledgeable about it in IS? [10:13] Don't do that, ask webops. It's an alias. [10:14] Duty admins highlight on it. [10:14] ok, doing so :) [10:14] (#launchpad-ops, internal) [10:14] thanks cjwatson, doing that right now :) [10:15] cjwatson: Actually, they prefer #webops. [10:15] Ah, that works too [10:16] ah, too late :) [10:18] hi barry [10:19] barry: do you know python's cElementTree code? If yes, maybe you can take a look at http://bugs.python.org/msg175235? [10:20] (this is cause of debian bug 692285) [10:20] Debian bug 692285 in src:python-docutils "python-docutils: FTBFS with Python 3.3: TypeError: must be Element, not _ElementInterfaceWrapper" [Important,Open] http://bugs.debian.org/692285 [10:42] doko_: Oh, for the love of... How am I meant to divine the mystery path for the multilib c++ includes? *sigh* [10:42] :-) [10:43] gcc -v? [10:43] Yeah, I was avoiding using the whole output of gcc -v, since it includes paths I might not want. [10:46] Not much point in using nostdinc if you then end up appending all of stdinc's paths to your call. [10:47] gcc -print-file-name=include [10:47] Wrong one. [10:47] Are there others? :P [10:47] What I'm after is /usr/include/c++/4.7 /usr/include/c++/4.7/backward /usr/include/x86_64-linux-gnu/c++/4.7 [10:48] That last one is a bitch to construct for multilib builds. [10:48] Since it ends up as /usr/include/x86_64-linux-gnu/c++/4.7/32 or /usr/include/x86_64-linux-gnu/c++/4.7/x32 [10:48] Rather than using the target triplet. [10:48] (I suppose to avoid clashing with the multiarch version of same) [10:49] g++ -E -x c++ - -v < /dev/null [10:50] Yes, I know. That's where I copied and pasted the above from. [10:50] But the list also includes things I don't want. [10:50] yeah :/ [10:50] If I could guarantee the top three were always the ones I want, I'd go with that. [10:50] But I'm not sure that's a sane assumption. [10:51] (Though currently true) [10:54] |grep c++ ? :P [10:54] mlankhorst: Well, that's definitely correct today. Almost certainly not upstreamable. [10:54] mlankhorst: But meh. For now, it might do. [10:55] what are you trying though [10:55] and if it's meant for upstream, you could just add a -dump-includes to gcc or something [10:55] Hrm? This is the glibc test suite. [10:55] Which worked fine in hackish ways until doko's new gcc. [10:56] still, could be better in long term to just get it over with and add it, even though that menas dealing with gcc coding style.. [10:56] * mlankhorst shivers === pcarrier_ is now known as pcarrier [11:00] Ahh, -print-multi-directory gets me that... [11:00] Hmm, has libnss-files started to autocreate /etc/{protocols,services} or something? [11:00] Except I can't get the multiarch dir in the same invocation, cause that ends up wrong. [11:00] * cjwatson is trying to debug chroot weirdness [11:00] cjwatson: No, schroot copies those in unless you tell it not to. [11:00] Oh is *that* it [11:00] OK, thanks [11:00] /etc/schroot/default/copyfiles [11:01] Or, no. /etc/schroot/default/nssdatabases [11:01] That one. [11:01] And in mine, #services and #protocols are commented out. :P [11:01] didrocks: ^ please try the "soft kitty" approach :) [11:01] Likely due to debugging a weird unreproducible "should have build-depended on netbase" build failure. [11:01] Right, that explains rather a lot of failures any time netbase gets upgraded. [11:02] Or rather, installed, since it isn't in the base. [11:02] pitti: yeah, it seems that's really needed, he will never stop! :) === Quintasan_ is now known as Quintasan [11:08] pitti: WRT your reverse-dep analysis, note that any of those packages having build-deps on each other is purely due to versioned build-deps (which can, and often do, go away). [11:08] pitti: Since all of those packages are build-essential, they don't need to be in build-deps at all. :P [11:09] infinity: right, I was mostly checking how the current deps would work wiht our current parser [11:09] pitti: I suspect that relying on rdep triggering to always work for that set is either asking us to always carry build-dep cruft (which seems wrong), or just being naive. :) [11:10] infinity: are services and protocols the only ones you have commented out there? [11:10] infinity: I'm just discussing that with apw [11:10] infinity: we can probably introduce an XS-Test-Depends: field or something like that [11:10] cjwatson: Yeah, none others have caused me personal grief. [11:10] OK, great [11:10] * cjwatson tweaks his charm [11:10] infinity: problem is that debian/tests/control isn't exposed in the apt indexes, so we cannot trigger on changes of pure test dependencies right now [11:11] infinity: (mind you, this is stretching what autopkgtest was designed for quite a lot, so we need to make up things here) [11:11] infinity, apw: of course we could also just special-case those four pacakges and hardcode their mutual trigger dependencies in our scripts [11:12] pitti: That was sort of what I was suggesting when I brought it up. [11:12] pitti: I thought it would be something server-side, not in the packages. [11:12] XS-Testsuite-Depends: i suspect if we do it there [11:12] we still need to add the actual tests to the packages [11:12] Yeah, we need the tests in packages, I'm fine with that. [11:13] Does anyone in Debian use this stuff (ie: is it upstreamable without annoying people with "useless cruft")? [11:13] infinity: no, the tests themselves should be in the packages, but I'm ok with hardcoding the depends set for this particualr "mini rebuild test" case [11:13] infinity: yes, we upstream a lot of tests [11:13] Alright, cool. [11:13] they are supposed to run in http://jenkins.debian.net/ at some point [11:13] infinity: dep-8 is a Debian standard, after all :) [11:13] The only slight problem with hardcoding the set is that one of these four packages keeps changing its name. [11:13] * infinity glares at gcc-X.X [11:14] infinity: ah, if only there was some way of expressing that with a pattern or so.. [11:14] "regular patterns" or "globby expressions" or so [11:14] pitti: Well, but if you express it as a regex, you just triggered a rebuild of ALL gcc versions in the archive, when that may or may not be what we want. Actually, maybe it would be. [11:15] But we wouldn't want the inverse. [11:15] That's the problem. [11:15] When gcc-4.5 revs (if it's still in the archive, too lazy to look), we don't care that it can't build the kenrel and glibc properly. [11:15] infinity: anyway, hardcoding this in the scripts requires manual maintenance anyway; having to change it with each new compiler version isn't that big of a deal [11:15] Nor do we care if gcc-4.8 can't do either of those things. [11:15] (yet) [11:15] infinity: but it can parse the defualt version from the "gcc" metapackage [11:16] But we do care if glibc makes gcc-4.8 worse. [11:16] pitti: If only it were that simple. ;) [11:16] pitti: (Last cycle, the default gcc was 4.7, but glibc was built with 4.6, not sure what the kernel used) [11:16] so the source packages expressing that works no? [11:16] apw: Yeah, expressing things in the source package might make more sense. [11:16] as i am saying linux -> gcc-4.7 [11:16] infinity: but that's fine -- glibc would then have a gcc-4.6 build dep, and the normal reverse dep parsing would kick in [11:17] pitti: Oh, fair. [11:17] I think I'll skip on the brown-paper-bag glibc upload tonight and finally go nap. [11:18] And fix this in the morning with an ugly non-upstreamable hammer. [11:18] And die a little inside. [11:18] pitti, so i think you are saying the following is enough: http://paste.ubuntu.com/1374603/ [11:19] apw: looks good, except that we don't implement XS-Testsuite-Depends ATM === _salem is now known as salem_ [11:19] apw: and in fact we might not use that yet, as it's not covered by DEP-8 [11:19] apw: I think we should start with hardcoding those [11:19] apw: And if that header actually worked, you'd want binutils in there too. [11:19] infinity, i think i already dep on that in reality, so its ok [11:19] not needed, linux-source pulls in binutisl [11:20] though it might be clearer indeed [11:20] ack [11:20] Eh. While it's okay that there's an implicit one, I'd prefer being explicit. [11:20] (Thinking of my specific glibc use-case where build-deps come and go more often than people I date) [11:21] well, if no part of linux depends on eglibc, do we actually need to test that then? [11:21] pitti: I'm trying to sort out what that header will mean. [11:21] i am expecting to need to test eglibc will still build after linux publishes [11:21] pitti: Is it "when this is upgraded, test these" or "when these are upgraded, test this"? [11:21] as it consumes my binary packages [11:22] infinity: the latter [11:22] apw: Yes, I want to test eglibc when linux-libc-dev lands. The inverse isn't necessary. [11:22] but as I said, I wouldn't add this new header just yet [11:22] and instead put that into lp:auto-package-testing for now [11:22] we can clean it up when it works and we can convince Debian to adopt the header into DEP-8 [11:22] (and Debian's autopkgtest) [11:23] pitti: Oh, and as to the DEB_BUILD_OPTIONS=whatever thing, that would probably be a DEB_BUILD_PROFILE in the new world. [11:23] DEB_BUILD_PROFILE=autopkgtest or something. [11:23] WFM :) I just wanted to take a variable taht already exists [11:23] pitti, ok so i'll add it commented out so we remember [11:24] Yeah, this is precisely why DEB_STAGE was changed to DEB_BUILD_PROFILE, so it could be genericized into a "mangle your build order/output" thing. [11:24] pitti, when you are expressing those, linux-libc-dev only ever comes from linux [11:25] infinity: it should be "rebuild-test", not "autopktest", IMHO (we'd want that for the full rebuild tests too, I think) [11:25] pitti, so DEB_BUILD_PROFILE=autopkgtest or DEB_BUILD_PROFILE=rebuild-test [11:25] apw: right, but we'd set that in lp:auto-package-testing globally then [11:26] indeed, just adjusting my support within the package [11:26] a package can't set the environment in autopkgtest [11:26] pitti: I dunno. A full rebuild test should just be a normal build. [11:26] pitti: (My current glibc build failure wouldn't be a failure if I wasn't building the second pass, actually) :P [11:27] infinity, i am proposing to use it to build just the first flavour on each arch [11:27] infinity, for the autopkgtest case [11:27] apw: Right, which is why I think it's wrong for it to be for "all rebuild tests". [11:27] so if it's wrong for the "all rebuild tests", how is it not wrong for the "mini rebuild test"? [11:28] pitti: It's a speed-versus-accuracy tradeoff. The "right" thing to do when uploading a new toolchain is to rebuild test the whole archive before we let the toolchain in. We're not going to do that, cause we'll get lynched. [11:28] pitti: So, autopkgtest as a blocker to migration needs to hit good test coverage without being too heavy. [11:29] okay [11:29] pitti: A full rebuild test is async, and can be as heavy as you want. [11:29] well, except that it still takes like a month on arm :) [11:29] Not true. [11:29] The last time was because buildds kept ABORTing every few minutes. [11:29] The time before that, armhf finished before amd64. [11:29] infinity, g++ -E -x c++ - -v < /dev/null | fgrep /c++/ [11:29] People have short memories. [11:30] doko_: Yeah, I was going to settle on the grep c++ solution. [11:30] doko_: Is that guaranteed to always only be the internal includes? [11:30] apw: oh, and you might want to add a bug ref to #1081500 to the commit ? [11:30] doko_: Like, in an unstreamably reliable way? [11:30] ig glibc is that backward, it even includes the backward headers [11:30] pitti, will do [11:30] bug 1081500 [11:30] Launchpad bug 1081500 in linux (Ubuntu) "Add autopkgtest for mutual rebuild-testing amongst glibc, linux-libc-dev, gcc, and binutils" [Low,Triaged] https://launchpad.net/bugs/1081500 [11:30] once you lot hash out what the DEB_PROFILE is going to be [11:31] doko_: It might not actually need the backward ones, but it does need the tricky-to-construct arch-path ones. :P [11:32] apw: Doesn't matter, we can change it once guillem tells us we're wrong. [11:32] apw: so DEB_PROFILE=autopkgtest WFM at the moment [11:32] (s/DEB_PROFILE/DEB_BUILD_PROFILE) [11:32] / [11:32] ifeq ($(DEB_BUILD_PROFILE),autopkgtest) [11:33] apw: I bet you're having a good laugh now about having implemented all that do_* stuff reusably. :/ [11:33] * infinity suspects he's going to have to take some dull scissors to glibc to make this work. [11:33] ifneq (,$(ADTTMP)) ? [11:34] infinity, i am feeling somewhat smug at having rejected those original crosscompile patches about 4 times before implementing them right indeed :) [11:34] pitti, so i guess are you happy enough for me to push these to our package for the next upload ? [11:35]