| darkxst | can we get Ubuntu GNOME ISO size limits bumped up to 1.5GB? | 06:43 |
|---|---|---|
| === ara_ is now known as ara | ||
| slangasek | infinity: well, I pulled in your changes from trusty but that's insufficient, because it goes on to install the ubuntu-live task which also includes various other conflicted libraries | 07:23 |
| * didrocks wonders when slangasek isn't working | 07:24 | |
| slangasek | didrocks: weekends when we're not in the critical path of a terrible g++ transition | 07:24 |
| didrocks | slangasek: good luck! if you need any new hands, this week should be better for me… | 07:25 |
| slangasek | didrocks: the transition tracker has huge piles of libraries that we haven't started the rebuilds for yet, dig in :) | 07:25 |
| didrocks | slangasek: will do! :) | 07:25 |
| arges | infinity: would you be terribly inconvienced if I reviwed the openstack uploads in vivid today | 14:17 |
| infinity | arges: Why would I be inconvenienced if you did my job for me? :P | 15:03 |
| arges | infinity: : ) | 15:03 |
| Laney | slangasek: Had a go at implementing de-duping for the tracker | 15:09 |
| slangasek | Laney: de-duping? you mean for the new-binary-package-name case? | 15:10 |
| === seelaman` is now known as seelaman | ||
| Laney | Yep | 15:11 |
| slangasek | Laney: ok. tdaitx was also looking at this on Friday (and this morning), if you want to compare notes | 15:12 |
| tdaitx | Laney, http://paste.ubuntu.com/12047242/ and http://paste.ubuntu.com/12047866/ | 15:14 |
| tdaitx | in short: if a source package (in Source file) appears more than once, all binaries ("Binary:" field) it declares are removed from Package_arch file except for the ones in the latest (ie. highest version) source package | 15:14 |
| infinity | tdaitx: You can't (reliably) map in that direction, though. Some source packages lie aboutt he binaries they produce and we don't enforce consistency. | 15:15 |
| tdaitx | Laney, slangasek said "I can see that this approach will mask per-architecture build failures, for instance, which I suspect is not what the release team wants" | 15:15 |
| infinity | tdaitx: The only reliable mapping is the Packages file. | 15:15 |
| tdaitx | oh | 15:15 |
| infinity | tdaitx: It might be good enough for a hack today, mind you. JUst saying that it's not accurate for all source->binary mappings, since we're trusting the source package not to lie. | 15:16 |
| tdaitx | indeed | 15:16 |
| infinity | tdaitx: The inverse (checking the Source: field on binaries in Packages) is always correct. | 15:17 |
| Laney | I grabbed the source packages from -proposed's Packages file and then ripped those out of release's | 15:17 |
| infinity | tdaitx: With the hilarious caveat that binaries whose name matches their source don't have a Source field, so you have to check for Source not being set and assume Source==Package | 15:17 |
| infinity | tdaitx: All that said, Laney's solution is probably simpler. :P | 15:18 |
| infinity | tdaitx: But, y'know, consider the above a lesson in apt source parsing in general. | 15:18 |
| tdaitx | Laney, I tried that, but ben does look at the binaries in Packages_arch | 15:18 |
| tdaitx | I mean, it does what infinity suggested: grab the Source from the binary | 15:19 |
| Laney | Yep | 15:19 |
| Laney | I only look at Packages | 15:19 |
| Laney | (and write to) | 15:19 |
| Laney | anyway, sorry for duplicating your work - I wasn't aware :( | 15:20 |
| tdaitx | np | 15:20 |
| tdaitx | Laney, in short: you grab all Source fields from -proposed Packages and proceed to remove the binaries in release Package that have the same Source? | 15:22 |
| Laney | Right, and fall back to Package if Source isn't there | 15:23 |
| Laney | Then spit proposed and release out as Packages_arch | 15:23 |
| Laney | Tool of choice was grep-dctrl | 15:23 |
| slangasek | Laney: are you doing it on a per-arch basis? | 15:24 |
| tdaitx | nice, Laney can you send me the script? I would like to compare what they are (not) ripping out | 15:25 |
| infinity | You'd have to, to get it right. | 15:25 |
| Laney | Yep | 15:25 |
| Laney | tdaitx: It's in go on snakefruit, if you have access | 15:25 |
| tdaitx | not sure I do | 15:26 |
| Laney | I would bet it has some bugs :) | 15:26 |
| Laney | ok | 15:26 |
| infinity | tdaitx: You'll probably find Laney's approach and your approach tearing out the same packages (hopefully), because there aren't many source->binary liars in the archive. If the kernel is in proposed, though, I know it lies. :) | 15:26 |
| * Laney VPNs it up | 15:26 | |
| infinity | (Which is a bug, but it's also a bug that we have no lie detection, so it's allowed to) | 15:26 |
| infinity | Laney: He doesn't have snakefruit, no, I've tried to impress upon IS the importance of not randomly handing out sensitive groups/hosts to people without asking, so I'd be miffed if he did. :P | 15:27 |
| Laney | tdaitx: http://paste.ubuntu.com/12048720/ | 15:27 |
| * tdaitx wishes to had known about grep-dctrl | 15:29 | |
| infinity | tdaitx: By the way, grep-dctrl. HTH. | 15:29 |
| tdaitx | yeah | 15:30 |
| tdaitx | that =) | 15:30 |
| Laney | There's certainly some golfing to be done there. :P | 15:30 |
| Laney | zcatting the same thing twice, oh my | 15:30 |
| infinity | Laney: The second one will be near instant, probably, but yeah, a bit eww. | 15:32 |
| infinity | Laney: And, of course, at that point, output == proposed (doesn't it?), so you could do your filter on output instead. Which will be in cache. | 15:32 |
| infinity | Yeah, that's the first write to output. | 15:33 |
| Laney | Feel free to go shrink it. ;) | 15:33 |
| infinity | Laney: I don't much care, it'd save half a second, at best. Was just engaging in your optimisation thought exercise. :P | 15:34 |
| infinity | (Also, what have I become where I don't think saving half a second is huge? I hate modern computing...) | 15:34 |
| slangasek | infinity: well when you get old and your reaction time slows to 5 seconds for anything... | 15:38 |
| infinity | slangasek: Touche. | 15:45 |
| === tdaitx is now known as tdaitx|lunch | ||
| === tdaitx|lunch is now known as tdaitx | ||
| tdaitx | Laney, infinity, slangasek: packages kept only by Laney's script *or* mine for amd64, ppc64le, and all archs @ http://paste.ubuntu.com/12049566/ | 17:40 |
| tdaitx | hopefully this can tell if either script is removing something that it shouldn't | 17:41 |
| infinity | tdaitx: Well, you can spot-check that with "rmadison <package>" on a few and see what reality says about the situation. | 17:44 |
| infinity | tdaitx: If it exists in both suites and one of you is removing it, you have a bug. | 17:45 |
| tdaitx | infinity, thanks, that's a good tip | 17:46 |
| slangasek | tdaitx: or, for example, if I look at the first package in that list, ruby-gdk3-dbg: ruby-gdk3-dbg comes from ruby-gnome2 source package, ruby-gnome2 source exists in wily-proposed but is not built on any arch; so this should not be removed, laney's script is correct for this one | 17:59 |
| slangasek | tdaitx: and then you get down to line 13, libsigc++-2.0-0c2a built from libsigc++-2.0 source, which exists in wily-proposed, is built for all architectures, and no longer includes this binary package - so your script is the correct one ;) | 18:01 |
| tdaitx | slangasek, I have also confirmed that my script is removing binaries that exist in both series (wily and -proposed), but so far there is another package available from the same source, example: removing libcdr-0.1-1 (wily and -proposed) but keeping libcdr-0.1-1v5 (-proposed) | 18:05 |
| * doko looks for gcc-5 5.2.1 in -release ... | 18:08 | |
| slangasek | tdaitx: in that case, there are two versions of the source package in wily-proposed, and the latest version has dropped the libcdr-0.1-1 binary (in favor of libcdr-0.1-1v5). So it's correct to remove | 18:11 |
| infinity | slangasek: If there are two versions in -proposed with differing binaries, that confuses britney until someone processes the NBS manually (I'll do that). | 18:12 |
| infinity | WOuldn't be shocked if it confused other things too. | 18:12 |
| slangasek | infinity: sure, but "something gets confused" is different from "it should be on the transition tracker" | 18:13 |
| infinity | slangasek: Yeahp, just saying it's harder to sort out those cases correctly sometimes. :) | 18:13 |
| * infinity finds libcoverartcc1 in the same state and fixes. | 18:14 | |
| * infinity hunts for more. | 18:14 | |
| === seelaman is now known as manonmani | ||
| === manonmani is now known as seelaman | ||
| tdaitx | slangasek, ruby-gdk3-dbg is on wily's Sources Binary: field, but not on -proposed's Source Binary: field, is this one case where the Binary: field from -proposed is lying/wrong? | 18:22 |
| slangasek | tdaitx: no, my point is that the package has not been built in wily-proposed yet so it shouldn't be taken off the transition tracker because it's not "done" | 18:23 |
| tdaitx | oh | 18:23 |
| slangasek | this is different than infinity's point that the Sources may lie, but leads to the same conclusion | 18:24 |
| tdaitx | is that the reason it does not show in -proposed's ruby-gnome2 Binary: ? because it was not build yet? | 18:24 |
| infinity | This whole "sync first, then rename" caused quite a mess... | 18:27 |
| infinity | Okay, I think I got all the NBS in proposed. | 18:27 |
| infinity | At least, all the rename-related NBS. | 18:27 |
| infinity | slangasek: http://paste.ubuntu.com/12049946/ cleaning up that might help a bit. | 18:29 |
| infinity | Hopefully we don't see too many more "try to build, then rename later" shenanigans. | 18:29 |
| infinity | s/build/rebuild/ | 18:29 |
| doko | infinity, did you see my gdb ping? | 18:44 |
| infinity | doko: I did, yeah. Rebuilding it and will ask a WeBop to babysit when it stalls again. | 18:45 |
| infinity | doko: Not exactly an ideal workflow going forward, mind you. | 18:45 |
| doko | sure, I can disable the testsuite, which isn't ideal either. | 18:46 |
| infinity | doko: Quite. Disabling the one test might be okay. Finding out why it explodes might also be nice. gdb still tries pretty hard to kill my ppc builders too. | 18:49 |
| infinity | Not that any of that is gdb's fault, it's clearly kernel bugs. | 18:49 |
| infinity | doko: Anyhow, we'll do the hackish thing for today. | 18:50 |
| doko | is oftc irc down? can't connect | 18:54 |
| teward | doko: up for me | 18:54 |
| ScottK | doko: Working here. | 18:56 |
| doko | hmm, nslookup irc.debian.org fails for me from germany, brazil, | 19:00 |
| teward | doko: nslookup on irc6.geo.oftc.net | 19:01 |
| teward | (irc.debian.org is a CNAME to that) | 19:01 |
| teward | ooop | 19:01 |
| teward | doko: actually, looks like OFTC's dns is possibly blown up | 19:01 |
| doko | no, doesn't work either | 19:01 |
| teward | yeah it shouldn't | 19:01 |
| doko | ok, will wait | 19:02 |
| teward | http://paste.ubuntu.com/12050243/ | 19:02 |
| teward | SERVFAIL | 19:02 |
| teward | doko: i could give you the v6 addr for one of their servers now if you want. don't have v4 because it's connected to my bouncer, but.. | 19:03 |
| teward | until they fix DNS anyways | 19:04 |
| doko | getting food first =) | 19:04 |
| teward | mmkay | 19:05 |
| infinity | doko: Curious. The testsuite didn't hang on armhf this time. | 19:05 |
| slangasek | ok, that's strange, I just reloaded http://people.canonical.com/~ubuntu-archive/transitions/html/icu.html and mediawiki2latex has dropped off of there when it shouldn't have | 19:19 |
| slangasek | has someone deployed changes to snakefruit? | 19:19 |
| slangasek | (Laney?) | 19:19 |
| slangasek | oh, no, I see, someone actually fixed mediawiki2latex | 19:20 |
| slangasek | tricky | 19:20 |
| teward | doko: apologies for discussion derailments. But, in the interim: i've made a note to OFTC that their DNS is explodified. sarnold poked that up to people there. beauty.oftc.net is 2604:a880:800:10::870:a001 port +6697 and is up, although DNS won't resolve because i think their DNS exploded. | 19:20 |
| slangasek | and that was Laney too, right attribution wrong change ;) | 19:20 |
| teward | in case anyone else here with v6 who needs to get to OFTC needs to get there... :P | 19:20 |
| slangasek | ok, now this one is *not* due to a fix... mrtrix is broken and FTBFS on armhf, but no longer shows up on http://people.canonical.com/~ubuntu-archive/transitions/html/gtkmm2.4-g++5.html | 19:23 |
| Laney | My thing totally broke for packages which contain "+" :) | 19:26 |
| Laney | I avoided using regex now... | 19:26 |
| slangasek | heh | 19:28 |
| slangasek | Laney: did you deploy any changes to snakefruit, though? I'm trying to figure out why mrtrix is gone from the tracker | 19:28 |
| * Laney looks | 19:29 | |
| Laney | it's showing as unknown | 19:29 |
| slangasek | hrm | 19:30 |
| Laney | for armhf | 19:30 |
| Laney | but why? | 19:30 |
| Laney | oh, because I made it remove the old binaries from Packages - this seems suboptimal | 19:31 |
| slangasek | ok; so the filter is wrong, 5 good + 1 unknown should still show when 'unknown' is checked, surely | 19:31 |
| slangasek | and looking at the package in the archive, it doesn't look 'unknown' to me | 19:31 |
| slangasek | ah, so you did deploy a change :P | 19:32 |
| slangasek | Laney: are you reverting this? | 19:32 |
| Laney | Thinking | 19:33 |
| slangasek | Laney: please revert this ;) | 19:33 |
| doko | slangasek, xnox: any news about the boost1.58 rebuilds? | 19:57 |
| doko | teward, oftc works again | 20:20 |
| slangasek | doko: I haven't been tracking boost, I assumed xnox was doing something with it and that I'd just get in the way if I tried to trigger rebuilds | 20:20 |
| teward | doko: their DNS just came back up yes | 20:21 |
| teward | doko: in any case if it breaks in the future https://pbin.dark-net.net/view/raw/0411bee5 is a 'good server' for now | 20:21 |
| teward | (that'll be there for a week, that pastebin) | 20:21 |
| slangasek | xnox: the scripts I have on hand for batch-uploading don't map to boost, should I hack up a new one or do you have something scripted to go on your side? | 20:37 |
| tdaitx | slangasek, please try to rebuild notmuch, I tried a local build and it went ok | 20:45 |
| tdaitx | robru, ^ in case you can also trigger a rebuild for notmuch | 20:49 |
| robru | tdaitx: so far I trigger rebuilds by asking slangasek to do it ;-) | 20:49 |
| tdaitx | robru, alright then, I will keep pestering him about it | 20:51 |
| tdaitx | robru, slangasek, as for the ceph issue, here is the bug (with fix): http://tracker.ceph.com/issues/11576 | 21:08 |
| robru | cool | 21:08 |
| slangasek | tdaitx: any idea what changed that would make notmuch work again? FWIW I did previously reproduce the build failure locally against wily-proposed | 21:09 |
| tdaitx | slangasek, nope, I tried to reproduce it locally and it build ok | 21:09 |
| slangasek | ok. I'll retry it in launchpad | 21:09 |
| tdaitx | I saw that my env had newer packages and that's it | 21:10 |
| robru | tdaitx: slangasek: https://github.com/ceph/ceph/pull/5122/files so I guess we need to distropatch this fix onto our existing package? | 21:10 |
| robru | or pull a newer upstream? | 21:10 |
| slangasek | robru, tdaitx: the ceph package is owned by the server team and in main, we shouldn't take it upon ourselves to pull a new upstream version without coordinating with them. | 21:12 |
| slangasek | tdaitx: if you have a patch for ceph, you might want to throw it in the direction of smoser | 21:12 |
| slangasek | (e.g. on #ubuntu-devel) | 21:12 |
| doko | tdaitx, LP: #1483403 | 21:13 |
| ubot93 | Launchpad bug 1483403 in ceph (Ubuntu) "ceph FTBFS with boost1.58" [Critical,Confirmed] https://launchpad.net/bugs/1483403 | 21:13 |
| slangasek | ah yes, so posting the patch there and letting the server team pick it up seems like a good approach | 21:14 |
| doko | tdaitx, not much luck | 21:19 |
| doko | slangasek, why didn't you mark clementine and notmuch as removal candidates? | 21:24 |
| slangasek | doko: notmuch because it has revdeps and is popular so I wasn't considering it a removal candidate, but that doesn't mean it can't be removed. clementine, I don't know why ;) | 21:25 |
| slangasek | doko: oh, because the clementine issue is a trivial fix, that's why | 21:39 |
| slangasek | doko: #ifndef Q_MOC_RUN // #include <boost/thingy.hpp> // #endif | 21:40 |
| doko | slangasek, yeah, was talking with sitter about that for kdepim as well | 21:40 |
| doko | slangasek, debian seems to close many transitions as not needed. with their next sourceful uploads, these will appear again in -proposed (because the old binary is still there). how could we avoid this? | 21:41 |
| slangasek | doko: track the ones that are closed as not-needed, we should revert the package name transitions and add a Provides: libfooNv5 for compatibility | 21:42 |
| slangasek | possibly even a Provides: libfooNv5 (= $version), since I hear that works now with apt/dpkg in vivid and wily | 21:43 |
| slangasek | then we rebuild the revdeps (again) if necessary, but it can be a soft transition | 21:43 |
| slangasek | strange, why did numexpr just get into wily? (python3.5 no-change rebuild uploaded 19 days ago) | 21:45 |
| slangasek | because p-m+autopkgtest went wrong | 21:46 |
| tdaitx | notmuch rebuild failed... hmm, I wonder what is "wrong" with my local sbuild | 21:46 |
| slangasek | tdaitx: is your local sbuild configured to build against wily-proposed, or only against wily? | 21:46 |
| tdaitx | I had a wily that had proposed disabled, but I installed/made a new one that includes proposed | 21:47 |
| tdaitx | or at least I thought I did, will check that... again | 21:47 |
| slangasek | ok | 21:48 |
| tdaitx | slangasek, apologies, how can I be sure my schroot is indeed running -proposed? it does show in apt sources.list and I can see gcc5 5.2.1 (instead of 5.1..1) | 21:52 |
| slangasek | tdaitx: well, those are the things I would check also so it sounds like you're there | 21:52 |
| slangasek | tdaitx: are you running the build under sbuild? | 21:52 |
| tdaitx | right | 21:53 |
| tdaitx | yes, I am | 21:53 |
| tdaitx | I will try another build after ceph is done | 21:53 |
| tdaitx | meanwhile I will compare the build logs | 21:53 |
| slangasek | doko: is openvdb on your radar? your last upload went from 4 archs failing with .symbols mismatch, to 6 archs failing with .symbols mismatch | 21:59 |
| doko | slangasek, ok, I'll look | 22:03 |
| tdaitx | slangasek, what's the right way to fetch the package? I'm using pull-lp-source <pkg> wily-proposed | 22:04 |
| infinity | tdaitx: You just need "wily", it'll magically pick the latest version from wily{-updates,-security,-proposed} | 22:05 |
| infinity | tdaitx: Or indeed, no argument, which defaults to the dev release, which is wily. | 22:05 |
| tdaitx | the version matches, but I can see a few differences in the build logs that made me wonder if I actually have the same thing | 22:05 |
| infinity | tdaitx: Such as? | 22:07 |
| infinity | tdaitx: Could be as simple as you comparing a -A build with not. (ie: amd64 on LP builds -A, while all other arches don't, and the sbuild default is withuot, IIRC) | 22:08 |
| doko | infinity, tdaitx: so notmuch succeeds locally here in fresh sid and wily-proposed chroots, with the wily-proposed kernel running | 22:09 |
| tdaitx | meh, not such meaningful changes actually... setup.py running files in a different order (might be ok actually), a few different packages being installed... | 22:10 |
| tdaitx | doko, succeeds locally here as well, 3.19.0-25-generic | 22:14 |
| infinity | doko: Yeah, confirmed here too. So we might just need to disable that one test when run on << 3.19 | 22:18 |
| infinity | Except... That's still sketchy. Cause it built BEFORE all these rebuilds. | 22:18 |
| infinity | And the kernels weren't downgraded. :P | 22:19 |
| infinity | Oh, not in this version, though. Maybe that test is new. | 22:19 |
| infinity | Yeah, okay, same test was failing before the transition too. | 22:20 |
| tdaitx | infinity, any chance we can get a set -x in that test/T160-json.sh script? at least to see where exactly it is failing? | 22:22 |
| infinity | tdaitx: Not easily. | 22:22 |
| infinity | tdaitx: Not without uploading to a PPA with said hack in place. | 22:22 |
| infinity | So, that's kinda suspicious. It was working with 0.17-3, started failing with 0.17-5 ... | 22:24 |
| infinity | It's possible the packaging broke, but seems more likely that coincides with a dependency breaking. | 22:25 |
| infinity | Especially since the packaging didn't change meaningfully between those versions. | 22:25 |
| tdaitx | infinity, sorry, how did you tell it started failing with 0.17-5? | 22:27 |
| infinity | tdaitx: Drilled back through publishing history until I found the earliest one with failures. | 22:28 |
| infinity | tdaitx: https://launchpad.net/ubuntu/+source/notmuch/0.17-5 | 22:28 |
| infinity | And there are zero changes between -3 and -5 to account for it, so it has to be something else than changed (a dep, toolchain, etc) | 22:29 |
| infinity | Same kernel on both builds too. | 22:29 |
| doko | the toolchain doesn't have bugs, it only exposes some | 22:30 |
| infinity | doko: Uh huh. :) | 22:30 |
| doko | well, at least until now I didn't see one for GCC 5 | 22:30 |
| infinity | doko: This isn't gcc-5, this has been breaking since trusty. | 22:31 |
| infinity | Or, utopic rather. | 22:31 |
| doko | yeah, some people are behind with merges ... | 22:31 |
| infinity | doko: This has nothing to do with merges. It's a package without a delta whose autosyncs have been failing for two years. | 22:32 |
| infinity | tdaitx: Your sh -x request: https://launchpad.net/~adconrad/+archive/ubuntu/ppa/+build/7782298 | 22:57 |
| robru | infinity: any low-hanging fruit you can throw my way? I just got a succesful build of clementine and mailed the debdiff to slangasek | 22:58 |
| infinity | robru: No idea, I'm not on top of the transition stuff, since I wasn't involved last week. | 22:58 |
| robru | heh, he told me you'd know since he's afk briefly | 22:58 |
| infinity | robru: He lied. :) | 23:00 |
| robru | well, anybody else know any easy transition bits for a noob to poke at? | 23:00 |
| slangasek | infinity: I said that you would be able to guide, which I have every confidence in even if you don't already know ;) | 23:02 |
| robru | he's back! | 23:02 |
| slangasek | robru: try libktorrent, same basic issue as clementine | 23:03 |
| robru | thanks | 23:03 |
| tdaitx | infinity, bummer, I was setting up my ppa =P | 23:06 |
| tdaitx | infinity, anyway, it is stuck in a loop... it seems to be missing at least one dependency | 23:06 |
| infinity | Oh, maybe the reason it works locally is because my local schroot is a tiny bit fatter than the lp-buildd chroot tarballs. | 23:07 |
| infinity | Bah, we still don't have "apt-get build-dep foo.dsc" | 23:09 |
| infinity | Must be in apt 1.1 | 23:09 |
| tdaitx | I am not sure, mine is supposedly very slim | 23:09 |
| tdaitx | and it still passes | 23:09 |
| infinity | tdaitx: Testing a theory on the one thing I guarantee is different. Sec. | 23:13 |
| * tdaitx still waiting for ceph to finish... doh, forgot parallel build! to kill or not to kill? | 23:14 | |
| infinity | tdaitx: My .bashrc has this at the end, so I never have to think about it: | 23:15 |
| infinity | export DEB_BUILD_OPTIONS="parallel=$(nproc)" | 23:15 |
| tdaitx | indeed | 23:15 |
| infinity | Hrm, purging locales didn't break it. That was my one good guess. | 23:15 |
| * infinity compares an entire dpkg -l with the build log. | 23:16 | |
| tdaitx | so... after uploading to my ppa, how long does it usually take for the builders to grab it? | 23:19 |
| infinity | Bah. Literally identical set of packages installed, still no failure. Not we're in the realm of the bizarre. | 23:23 |
| infinity | tdaitx: Depends on queue depth. | 23:23 |
| infinity | tdaitx: Though, generally, you have to actually upload something first. | 23:31 |
| infinity | (I see nothing in your PPA) | 23:31 |
| ScottK | Now you're getting demanding. | 23:31 |
| infinity | ScottK: I know, I'm a stickler. | 23:31 |
| tdaitx | infinity, but I did run dput and it said the world was good and peaceful | 23:33 |
| tdaitx | did it lie? | 23:33 |
| infinity | tdaitx: dput just fires and forgets. | 23:33 |
| infinity | tdaitx: You either (a) have a REJECT email, if your upload was unacceptable, or you (b) have zero feedback at all if you forgot to sign your upload. | 23:33 |
| infinity | I'm betting on B. | 23:34 |
| tdaitx | I did sign it, dput checked that | 23:34 |
| infinity | Then check your email. :) | 23:34 |
| infinity | (I'm going to assume you signed it with the same key LP knows...) | 23:35 |
| tdaitx | infinity, indeed, it was rejected | 23:35 |
| tdaitx | oh yeah, from the command line it seemed like dput checked even that | 23:35 |
| infinity | dput just checks that it's signed, period, not who it's signed by. Though, if you got a reject, it was the right key. | 23:36 |
| infinity | And something else was wrong. | 23:36 |
| tdaitx | right, I cant submit to wily-proposed | 23:36 |
| infinity | Yeah, get out of that habit anyway. | 23:36 |
| infinity | The correct thing to upload to is always just "$release". | 23:36 |
| infinity | For PPAs without pockets, that works, and for the primary archive, we map $release to $release-proposed on the server side. | 23:37 |
| tdaitx | nice | 23:37 |
| tdaitx | infinity, ha! I was able to reproduce the issue locally | 23:37 |
| infinity | tdaitx: ! | 23:38 |
| tdaitx | infinity, TERM="unknown" sbuild | 23:38 |
| infinity | Ahh! | 23:38 |
| tdaitx | dtach does not like an unknown term | 23:38 |
| infinity | Also, balls. That means our term setup is different from Debian's, where it succeeded on all buildds. | 23:38 |
| tdaitx | I have been bitten by that I don't remember how long ago | 23:38 |
| tdaitx | yes | 23:38 |
| tdaitx | mine was rxvt-unicode, from my own term | 23:39 |
| infinity | Looks like Debian isn't explcitly setting TERM at all, so hard to say what setting is leaking through. | 23:40 |
| infinity | I guess whatever the buildd pid has. | 23:40 |
| infinity | Man, and we tried to hard to be 100% compatible. :P | 23:41 |
| infinity | I even remember when we made this change (which coincides with when this build started failing). | 23:41 |
| infinity | For now, though, a delta to call the testsuite with TERM=vt100 or something will probably work. | 23:41 |
| * infinity tries. | 23:42 | |
| tdaitx | infinity, yeah, that should do it... vt100 or even xterm (I can see it installed on my failed build session) | 23:45 |
| infinity | Already testing vt100, so if that works, that wins. | 23:46 |
| tdaitx | or linux | 23:46 |
| * tdaitx is somewhat happy to have battled against dtach on the past | 23:48 | |
| robru | hey release peeps, I've analyzed http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gcc-5 and found that kservice, libktoblzcheck, kdeclarative, autopilot-gtk, step regresions are more recent than the gcc5 upload (eg, those autopkgtests passed with the initial gcc5 upload then failed later for other reasons) | 23:50 |
| robru | infinity: ^ | 23:53 |
| infinity | tdaitx: Okay, confirmed that this works: http://paste.ubuntu.com/12052461/ | 23:54 |
| infinity | tdaitx: Will upload after making the changelog more manager friendly. | 23:54 |
| tdaitx | infinity, great =) | 23:55 |
| tdaitx | oh yeah, be "nice" on the changelog | 23:55 |
| infinity | tdaitx: Thanks for the analysis! | 23:57 |
| infinity | robru: Your analysis, I'm less sure what to do with. If those are new failures, we kinda still need to know why. | 23:58 |
| robru | infinity: yeah I'm not really sure either. slangasek asked me to look into that. apparently the ones I listed shouldn't block the gcc5 transition | 23:58 |
| tdaitx | infinity, you are welcome =) | 23:58 |
| slangasek | infinity: yes, this is for unblocking gcc-5, not for ignoring the failures wholesale | 23:59 |
| tdaitx | ceph just passed locally | 23:59 |
| tdaitx | one, two down... one, two to go... | 23:59 |
| infinity | slangasek: Check. | 23:59 |
| infinity | robru: So, are those the only regressions britney's hating on? | 23:59 |
| * infinity looks. | 23:59 | |
| robru | infinity: no there's other regressions | 23:59 |
| infinity | Right, in that case, not much I can do about it yet. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!