| === DalekSec_ is now known as DalekSec | ||
| === henrix_ is now known as henrix | ||
| pitti | Good morning | 05:29 |
|---|---|---|
| Logan_ | Why are the build queues so clogged? Did someone do a mass rebuild? | 05:39 |
| Logan_ | Ah, I see. | 05:39 |
| * Logan_ eyes dojo. | 05:39 | |
| Logan_ | And doko. | 05:39 |
| pitti | Logan_: they have a low build score, so any "regular" upload trumps them | 05:46 |
| Logan_ | Gotcha. | 05:46 |
| dholbach | good morning | 08:14 |
| mitya57 | Good morning dholbach! | 08:16 |
| dholbach | hi mitya57 | 08:17 |
| dholbach | mitya57, what do you think about getting a new ubuntu-packaging-guide into Debian? | 08:17 |
| mitya57 | dholbach: I don't have upload rights for it, so ask Andrew | 08:21 |
| dholbach | mitya57, sure... just wanted to ask if you generally agreed ;-) | 08:24 |
| mitya57 | dholbach: I generally agree :) | 08:34 |
| directhex | <directhex> Laney, ok, i'm only working a half day today. what can i usefully do? | 08:39 |
| directhex | sorry, i have flaky wifi | 08:39 |
| dholbach | mitya57, cool :) | 08:48 |
| Laney | directhex: If you want to work on migration, the issues are at the end of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt | 09:08 |
| pitti | # su -c whoami nobody | 09:22 |
| pitti | This account is currently not available. | 09:22 |
| pitti | cjwatson: ^ ah, shell was changed for "nobody" as well? | 09:22 |
| * pitti goes to fix postgresql for that | 09:22 | |
| seb128 | hum | 09:22 |
| seb128 | doko, is that known? | 09:22 |
| seb128 | " Preparing to replace tcl-dev:i386 8.6.0-0ubuntu1 (using .../tcl-dev_8.6.0+6_i386.deb) ... | 09:22 |
| seb128 | Unpacking replacement tcl-dev:i386 ... | 09:22 |
| seb128 | dpkg: error processing /var/cache/apt/archives/tcl-dev_8.6.0+6_i386.deb (--unpack): | 09:22 |
| seb128 | trying to overwrite '/usr/lib/i386-linux-gnu/libtcl.so', which is also in package tcl-lib:i386 8.6.0-0ubuntu1 | 09:22 |
| seb128 | " | 09:22 |
| pitti | cjwatson: that change came quite surprisingly, I'm sure it breaks more stuff than just phonesim and postgresql | 09:22 |
| doko | seb128, ahh, my bad ... will fix | 09:23 |
| seb128 | doko, thanks | 09:23 |
| directhex | "dput ubuntu foo.changes" will go into -proposed by default nowadays, right? i don't need to pass any special parameters? | 09:35 |
| Laney | yep | 09:37 |
| Laney | with Distribution: trusty in your changes file for example | 09:37 |
| directhex | ok, cool | 09:40 |
| Smit-Tay__ | Can anyone please explain why attempting to install 32 bit development libraries should result in this: http://pastebin.com/QbqZuCZR | 09:49 |
| Smit-Tay__ | I am trying to target both x86 and x86_64 from Ubuntu 12.04 x86_64 | 09:50 |
| directhex | oh for the love of... can someone with adequate special snowflake designation please merge libgpod from debian experimental? it's just adding armhf to the supported mono arches list. which could feasibly be done in experimental now too but i don't want to poke that without hyperair's say so | 09:52 |
| directhex | (it's blocking banshee build) | 09:52 |
| hyperair | directhex: i did | 09:52 |
| hyperair | it's been sitting in the sponsoring queue for god knows how long now | 09:52 |
| hyperair | i should probably apply for ppu access | 09:52 |
| directhex | hyperair, gnome team sponsoring queue? | 09:52 |
| hyperair | um ubuntu-sponsors i think | 09:53 |
| hyperair | but uh, i didn't know it could be done in experimental | 09:53 |
| hyperair | but if it can be, that makes things a lot easier | 09:53 |
| hyperair | when did it start working in exp? | 09:53 |
| directhex | experimental has armhf mono. well, it will do when it actually gets around to building (a month in the buildd queue so far! a month!) | 09:53 |
| directhex | but the experimental mono source package has working armhf binaries in trusty-proposed and raspbian so i'm quite confident | 09:54 |
| Laney | hyperair: I'll look at that | 09:59 |
| Laney | god knows how long is since the first btw ;-) | 10:00 |
| Smit-Tay__ | Has anyone here got time to explain something to me ? | 10:01 |
| === Mez_ is now known as Mez | ||
| seb128 | directhex, what is "gnome team sponsoring queue"? for sure the GNOME team should look at their set it the normal queue rather than creating a new system? | 10:01 |
| Laney | they mean the ubuntu desktop team | 10:01 |
| directhex | seb128, i thought hyperair was talking about a delay in sponsoring on debian's side | 10:01 |
| Laney | o rly | 10:02 |
| seb128 | directhex, oh, ok | 10:02 |
| directhex | seb128, (since the change necessitating a merge can go into debian in experimental) | 10:02 |
| directhex | Laney, i'll merge tasque | 10:03 |
| seb128 | directhex, ok, I just saw that there was a libgpod in the ubuntu sponsoring queue | 10:03 |
| seb128 | but if we can sync that would be even better | 10:03 |
| directhex | hyperair's vanished, so the timing sucks :/ | 10:04 |
| directhex | seb128, can we accept the merge for now, with a view to syncing in future? | 10:04 |
| seb128 | directhex, sure | 10:05 |
| seb128 | I'm going to have a look later, if nobody beats me to it | 10:05 |
| seb128 | I want to finish what I'm doing atm first though | 10:05 |
| Laney | I'm looking now | 10:05 |
| seb128 | Laney, thanks | 10:06 |
| Laney | np | 10:06 |
| Laney | directhex: done | 10:19 |
| directhex | yay | 10:19 |
| Laney | it already had armhf in the arch lists so I don't know which fix was important :P | 10:20 |
| cjwatson | pitti: I guess; I've been putting it off for ten years, but then Russ came along with a patch to make base-passwd support debconf prompting | 10:38 |
| doko | cjwatson, xnox: do you remember why tcl-lib had a .so symlink in the package (and not tcl-dev)? | 10:39 |
| cjwatson | no ... | 10:39 |
| cjwatson | pitti: trying to grep via codesearch now | 10:51 |
| directhex | oh hamburgers. MIR for gtk#3 needed -_- | 10:55 |
| directhex | (blocking libgpod build) | 10:55 |
| directhex | i assume i can't just recycle https://wiki.ubuntu.com/MainInclusionReportGtkSharp2 from 2005 | 10:59 |
| Laney | I'd hope it wouldn't need a report as it's a new series of code already in main | 10:59 |
| === davmor2_ is now known as davmor2 | ||
| cjwatson | pitti: http://ubuntu-codesearch.surgut.co.uk/search?weighted=1&q=su+.*nobody doesn't look too bad, but I'm collecting bug reports in http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=base-passwd@packages.debian.org;tag=shell-fallout | 11:13 |
| pitti | cjwatson: ah, thanks; I uploaded a fixed postgresql-common to sid, should autosync soon | 11:14 |
| rbasak | !regression-alert | 11:23 |
| ubottu | bdmurray, cjwatson, Daviey, didrocks, doko, infinity, jdstrand, pitti, RAOF, Riddell, ScottK, seb128, skaet, slangasek, SpamapS, stgraber: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive | 11:23 |
| rbasak | bug 1267385 | 11:23 |
| ubottu | bug 1267385 in puppet (Ubuntu) "Default file mode now 0600 instead of 0644 (regression in CVE-2013-4969 fix)" [Undecided,New] https://launchpad.net/bugs/1267385 | 11:23 |
| rbasak | I've verified this. | 11:23 |
| rbasak | Specifically that 2.7.11-1ubuntu2.6 regresses 2.7.11-1ubuntu2 in a way that I think is quite serious. | 11:24 |
| rbasak | mdeslaur: ^^^ | 11:24 |
| rbasak | I think this will regress puppet-based redeploys to cloud instances. | 11:27 |
| === _salem is now known as salem_ | ||
| SpamapS | rbasak: I happen to be awake ATM. What do you think should happen? Ram a fix through, or remove the offending package until a better fix can be done? | 11:39 |
| rbasak | SpamapS: good question. I was hoping to leave the security team to answer that question. | 11:41 |
| rbasak | I think this almost certainly will regress a !small group of people. Better to hold the fix back a day, I think. | 11:41 |
| rbasak | Then again, the proposed fix does seem quite trivial. | 11:43 |
| * rbasak doesn't know | 11:43 | |
| SpamapS | rbasak: yeah security team will likely have somebody on it quicker than I can figure out what we should do :) | 11:46 |
| === pete-woods is now known as pete-woods|fight | ||
| === pete-woods|fight is now known as pete-woods|away | ||
| === cody-somerville_ is now known as cody-somerville | ||
| === tkamppeter__ is now known as tkamppeter | ||
| === highvolt1ge is now known as highvoltage | ||
| apachelogger | who's responsible for getting new translation templates accepted from the import queue? | 12:25 |
| mitya57 | dpm: looks like it's you ^^ | 12:29 |
| mdeslaur | rbasak: ok, taking care of it now, I'll push emergency updates | 12:29 |
| mdeslaur | rbasak: thanks! | 12:29 |
| seb128 | apachelogger, not sure we have anyone atm in charge of that, dpm has the access to do it if needed though so you can ping him I gues | 12:30 |
| apachelogger | seb128: mh, thanks | 12:31 |
| apachelogger | dpm: would be great if you could get the following through https://translations.launchpad.net/ubuntu/trusty/+source/kdesudo/+imports and https://translations.launchpad.net/ubuntu/trusty/+source/kde-config-whoopsie/+imports | 12:32 |
| rbasak | Thanks! | 12:35 |
| xnox | doko: i think i had "default" versions of tcl-lib / tk-lib, but debian decided it was redundant to have "defaults" versions off those packages, thus "naked/versionless" .so symlinks are provided in the tk-dev / tcl-dev defaults packages in debian. | 12:36 |
| doko | xnox, ok, so I'll drop these then, and add a replaces | 12:44 |
| === Sweetsha1k is now known as Sweetshark | ||
| === Trevinho_ is now known as Trevinho | ||
| === pete-woods|away is now known as pete-woods | ||
| hyperair | directhex: lol a month in buildd queue?! | 13:13 |
| hyperair | directhex: surely one could make it go faster by using an armhf VM on an i386 machine? | 13:14 |
| directhex | https://buildd.debian.org/status/architecture.php?a=armhf&suite=experimental | 13:14 |
| hyperair | wtf. | 13:14 |
| === zequence_ is now known as zequence | ||
| hyperair | is the queue broken? | 13:14 |
| hyperair | i mean are all the buildd's broken? | 13:15 |
| hyperair | no wait i see a lot of installed stuff | 13:15 |
| hyperair | recently even | 13:15 |
| hyperair | oh dear, i see webkit building. that's gonna take a while | 13:15 |
| mitya57 | hyperair: both armel and armhf are sloowly catching up | 13:16 |
| hyperair | slowly eh | 13:16 |
| mitya57 | Yes, the Qt stack was waiting for about three weeks, and only now it's building | 13:16 |
| jamespage | doko, do you have a list of gccgo fixes that have been backported to the 4.8.x version we have in trusty? | 13:35 |
| cjwatson | directhex: have you checked with #debian-buildd about that? More recent stuff has built; that looks like configuration error rather than giant queue to me | 13:38 |
| cjwatson | I suspect maybe it's just not properly configured to build experimental, since I see grub2 in Needs-Build too | 13:38 |
| directhex | cjwatson, there was a multi-week backlog in sid which has only just cleared | 13:39 |
| directhex | sid always takes precedence over experimental afaik | 13:39 |
| cjwatson | I see | 13:39 |
| doko | jamespage, not an explicit list, just see the README.Debian for the list of patches applied | 13:42 |
| pitti | cjwatson: considering the rather large list (http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=base-passwd@packages.debian.org&tag=shell-fallout), would it be suitable to keep that change in unstable for longer than just 5 days? | 13:55 |
| robotfuel | Mirv: ping | 13:56 |
| cjwatson | pitti: I dunno, I think I've got everything in the archive now | 13:56 |
| * pitti grabs debian bug 734740 then | 13:57 | |
| ubottu | Debian bug 734740 in autopkgtest "test_tmpdir_for_other_users fails because of the base-passwd shell change" [Serious,Open] http://bugs.debian.org/734740 | 13:57 |
| cjwatson | though I did apparently read past autopkgtest in the codesearch output | 13:58 |
| * cjwatson rechecks | 13:58 | |
| cjwatson | I missed nvi too, fixing that now | 13:59 |
| cjwatson | pitti: feel free to ask the release team if you want. With the exception of autopkgtest, the new RC bugs are in quite minor packages, so I'm not panicking | 14:01 |
| cjwatson | ah, nvi is QA-owned, I'll just upload that directly | 14:01 |
| pitti | cjwatson: ah, ok; I haven't checked all the bugs for how serious they actually are | 14:01 |
| cjwatson | pitti: I tried to triage as I was filing them, so the severities should generally be about right | 14:01 |
| pitti | (I guess "medium" importance was not actually intended, just due to the new default :) ) | 14:02 |
| cjwatson | Right, I probably would've gone for low if I'd thought about it; I'm not used to the new default yet | 14:02 |
| pitti | yeah, me neither | 14:02 |
| pitti | fortunately I mostly seem to fall into that trap in test suites, so it's not such a biggie | 14:04 |
| cjwatson | There were a couple of test suites I didn't report bugs on, but they were in code that wasn't actually run in Debian builds | 14:04 |
| cjwatson | I also QA-uploaded gnats | 14:05 |
| cjwatson | And I guess I might have missed a few due to line-wrapping, though I think that's relatively unlikely in this case | 14:07 |
| === dobey_ is now known as dobey | ||
| ogra_ | jodh, i remember at some point seeing a graphical dependency map for upstart jobs, googling doesnt really get me much, do you know of any vizualization tool ? | 14:11 |
| jodh | ogra_: man initctl2dot | 14:12 |
| ogra_ | jodh, perfect ... bad google ... didnt give even a hint | 14:12 |
| cjwatson | barry,zul: There's a new python-passlib source in unstable which appears to mostly supersede passlib, although the package in Debian doesn't include Python 3 support. At least plinth is stuck in trusty-proposed because it needs the new upstream version. Do you think you could merge all this, preferably switching to Debian's choice of source package name? | 14:18 |
| zul | cjwatson: sure | 14:19 |
| cjwatson | thanks | 14:19 |
| barry | zul: thanks. i'm around if you want a review | 14:21 |
| zul | barry: coolio | 14:21 |
| barry | zul, cjwatson looks like debian is a minor version behind pypi too | 14:22 |
| barry | zul: if you want, after you merge, i can submit patches to deb maintainer for any ubuntu deltas | 14:23 |
| barry | (including python3-passlib) | 14:23 |
| zul | barry: ill forward them off | 14:24 |
| barry | zul: awesome, thanks | 14:25 |
| === kirkland` is now known as kirkland | ||
| === oSoMoN_ is now known as oSoMoN | ||
| stgraber | @pilot out | 15:49 |
| === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| cjwatson | doko: do you need somebody to sort out the gcc-4.8-arm64-cross build failures? | 15:59 |
| doko | cjwatson, that had low prio for me. didn't look at it yet | 15:59 |
| cjwatson | I guess I can work around it by forcibly installing the trusty (not -proposed) versions | 16:00 |
| === greyback is now known as greyback|away | ||
| leighman | getting Packaging branch status: OUT-OF-DATE for xserver-xorg-intel-package - what should I do? | 16:04 |
| infinity | leighman: pull-lp-source xserver-xorg-intel-package | 16:05 |
| leighman | infinity: is it likely to be a while before it's fixed? | 16:09 |
| infinity | Erm, that would be xserver-xorg-intel, of course, not xserver-xorg-intel-package - | 16:10 |
| infinity | what should I do? | 16:10 |
| infinity | Whee, cut and paste fail. | 16:10 |
| infinity | Oh, not even xserver-xorg-intel... Well, whatever you were trying to branch, get the source from the archive instead was my point. :P | 16:11 |
| infinity | leighman: Branches can wedge and get out of date. xnox sometimes looks at that when he's told about it, but the archive is always the authoritative source. | 16:11 |
| leighman | yeh, xserver-xorg-video-intel sorry | 16:11 |
| infinity | leighman: Looks like that branch hasn't been used since raring. So, yeah, I'd recommend just using the archive source. | 16:12 |
| leighman | infinity: how can you tell that? | 16:13 |
| infinity | xnox: lp:ubuntu/xserver-xorg-video-intel seems to have been in a fancy wedged state since ~raring (or early saucy). Care to work some magic to wipe it out and reimport clean? | 16:13 |
| infinity | leighman: Well, the branch has 2:2.21.9-0ubuntu2 in it, the archive has 2:2.99.907-0ubuntu1 ... | 16:14 |
| xnox | infinity: i could, if i learn the right amount of magic. as per slangasek i was using too big of a hammer which shattered everything to pieces, beyond repair. | 16:14 |
| infinity | xnox: Oh, fun. Was this in regards to the eglibc hammer you applied for me that didn't actually DTRT according to people who care (ie: not me)? | 16:16 |
| xnox | infinity: correct. | 16:16 |
| slangasek | xnox, infinity: yeah, requeue-package --full doesn't keep the tag database in sync with the branches, which ensures the next import will fail again | 16:17 |
| xnox | slangasek: so what should be done instead? | 16:19 |
| infinity | slangasek: What's the correct way to just wipe out a branch history and reset to sane, then? (I suspect this is often what we want for horribly out-of-date and broken branches) | 16:26 |
| infinity | Expecially for ones where it's obvious that the source isn't actually maintained in said branch, just imported on upload. | 16:26 |
| hallyn | so where is the best place to find a list of currently valid architectures for ubuntu? (i.e. powerpcspe) | 16:27 |
| infinity | hallyn: powerpcspe isn't an Ubuntu arch. | 16:27 |
| infinity | hallyn: Or do you mean valid dpkg arches? | 16:28 |
| infinity | hallyn: Current trusty arches are listed at https://launchpad.net/ubuntu/trusty/ | 16:28 |
| hallyn | oh i'm sorry, i was looking at a *debian* bug. i thought it was an ubuntu one. sorry. | 16:28 |
| hallyn | infinity: cool, useful, thanks. | 16:28 |
| slangasek | infinity, xnox: for that particular import error, I don't know the answer... it's not one of the import failures I know how to fix. xnox, do you know what that failure actually means? | 16:28 |
| infinity | hallyn: For Debian, the answer is muddier, cause you could say "I only care about arches that are in unstable" or "I only care about arches that are in testing" or "I'm not a jerk, and I'll accept patches for any arch that dpkg supports". | 16:29 |
| infinity | hallyn: I suspect my wording of those three options highlights my preference. :) | 16:29 |
| hallyn | infinity: i'd probably go with the latter, but I suspect mjt will chime in anyway | 16:29 |
| infinity | hallyn: For the record, though, powerpcspe is in neither unstable or testing, only on debian-ports, so pretty much every bug regarding it is wishlist. That said, non-disruptive patches for ports arches are what allows them to eventually get to be primary ones, so I prefer to be nice where I can. | 16:31 |
| hallyn | what the heck *is* powerpcspe :) /me googles | 16:32 |
| hallyn | holy cow. ps3. | 16:32 |
| infinity | hallyn: It's a (sadly, ABI-incompatible) PPC subarch for certain SOCs that don't play nicely with standard PPC/POWER. | 16:32 |
| hallyn | i had figured it was something new, not something old :) | 16:32 |
| infinity | hallyn: And yes, the ps3 is in that list. :P | 16:32 |
| hallyn | i remember cell was a hot thing at ibm 5 years ago or so | 16:32 |
| hallyn | or 8 | 16:32 |
| infinity | hallyn: There are some newer Freescale SOCs that fall in that list too, though the latest and shiniest from them can run standard powerpc/ppc64. | 16:32 |
| doko | err, the ps3 runs ppc64 fine. at least it still does on my ps3 | 16:45 |
| === medberry is now known as med_ | ||
| leighman | infinity: basically want an easy way to do a .906 package but looks like that is not to be :) | 16:59 |
| infinity | doko: The main core is a standard ppc64 core, Cell is not. If you want to run on cell instead of the main core, you need ppcspe. | 16:59 |
| infinity | Well, I guess the whole thing is called "Cell", but that's a single ppc64 core, and 8 SPE cores. | 17:00 |
| infinity | leighman: Take the 907 package in the archive and roll back? :P | 17:02 |
| leighman | infinity: yerrrr | 17:02 |
| === greyback|away is now known as greyback | ||
| === timrc is now known as timrc-afk | ||
| === timrc-afk is now known as timrc | ||
| cjwatson | infinity: libtool M-A: allowed - hmm. This seems to mean we have to change everything that build-depends: libtool to build-depend on libtool:any instead, not too sure what will happen with dh-autoreconf build-dependencies, and we can't reasonably do that until Debian has made the same change because it'd involve a zillion Ubuntu deltas. | 17:50 |
| cjwatson | infinity: I can't help thinking that this was totally the wrong trade-off in order to avoid having to fix a tiny handful of packages that care about /usr/bin/libtool. | 17:51 |
| infinity | cjwatson: Direct build-deps wouldn't need to change. I can't see why they would. | 17:52 |
| infinity | cjwatson: Some indirect ones might need to, but I'm not actually sure if there'd be many of those, if any. | 17:52 |
| cjwatson | infinity: They totally do because otherwise they default to libtool:<foreign> when cross-compiling. | 17:52 |
| cjwatson | infinity: http://people.canonical.com/~cjwatson/cross/arm64/trusty/acl_2.2.52-1_arm64-20140109-1652 | 17:52 |
| cjwatson | And, I expect, a buttload of others in that cross-build run | 17:52 |
| infinity | cjwatson: Erm, wha? | 17:53 |
| cjwatson | So I fear that this has massively regressed our cross-building | 17:53 |
| infinity | cjwatson: build-dep: foo will default to HOST_ARCH. | 17:53 |
| infinity | cjwatson: build-dep: foo:any will default to BUILD_ARCH | 17:53 |
| cjwatson | Right. Which is arm64 here, because I'm cross-building from amd64 to arm64. | 17:53 |
| infinity | cjwatson: I'd contend that 99% of libtool build-deps want HOST_ARCH. | 17:53 |
| cjwatson | Er, hmm, but what are we going to do about the cpp dep then | 17:53 |
| cjwatson | We don't want cpp:host | 17:53 |
| cjwatson | I'm actually a bit confused about why cpp is M-A: allowed. Because you might want to find out defines of some other arch? | 17:54 |
| cjwatson | Debian #630853 | 17:54 |
| ubottu | Debian bug 630853 in cpp "cpp: multi-arch: foreign or multi-arch: allowed?" [Wishlist,Fixed] http://bugs.debian.org/630853 | 17:54 |
| infinity | cjwatson: Oh, I hadn't thought of libtool's deps. Hrm. | 17:54 |
| infinity | cjwatson: Maybe the right answer really is to just drop /usr/bin/libtool entirely. | 17:55 |
| cjwatson | The libtool-bin solution avoided this | 17:55 |
| infinity | cjwatson: I was just undoing the split in the way that seemed to make most sense, since the split itself is a bit pointless. | 17:55 |
| infinity | The libtool-bin solution doesn't really solve anything, does it? Things that build-dep on libtool-bin still have the same issues (foreign or allowed, whichever one does, each appears to be wrong). People who install libtool to get /usr/bin/libtool don't. | 17:56 |
| infinity | It just moves the problem to another package, it doesn't solve it. | 17:56 |
| cjwatson | Another package that hardly anything has to care about, though | 17:57 |
| cjwatson | Why does libtool depend directly on cpp, anyway? | 17:57 |
| infinity | Well, how is it any different than having libtool itself just be what it was a month ago? | 17:57 |
| cjwatson | It doesn't seem to use it ... | 17:57 |
| infinity | And fixing things that fail to cross because they incorrectly assume /usr/bin/libtool is for HOST_ARCH. | 17:57 |
| cjwatson | libtool was M-A: foreign a month ago, so most things just worked fine because they didn't use /usr/bin/libtool and generated their own one the way you're supposed to. | 17:58 |
| cjwatson | If you do what you're supposed to do then you don't care what arch the libtool package is. | 17:58 |
| infinity | Sure. So, we could go back to that. I actually think "allowed" looked more correct, but I hadn't thought to look at the deps it pulled in. | 17:58 |
| cjwatson | libtool-bin could've been M-A: allowed, maybe | 17:58 |
| infinity | The MultiArchCross spec certainly implied that allowed would give me the sane behaviour. | 17:58 |
| cjwatson | Or even M-A: none | 17:58 |
| cjwatson | Dropping the cpp dep alone probably won't help, anyway, since there's still the gcc dep. | 17:59 |
| cjwatson | doko: ^- opinions on the above? | 17:59 |
| cjwatson | infinity: In fact, doko's split libtool-bin was M-A: none | 18:01 |
| cjwatson | infinity: So it didn't have this problem - if you needed /usr/bin/libtool you could b-d on that and you'd get the host version | 18:01 |
| cjwatson | infinity: I think the split version was better in every way apart from being "ugly" and meaning that a few packages have to adapt | 18:02 |
| cjwatson | infinity: It certainly seems clearly better for cross-building | 18:02 |
| cjwatson | infinity: I'm sorry I didn't notice this problem when you were talking about reverting it ... | 18:02 |
| infinity | cjwatson: And people. But meh. If you want to reintroduce the split, go nuts. It just seems entirely wrong to install libtool and not get libtool out of the deal. | 18:02 |
| cjwatson | Well, the long-term goal AIUI is to drop /usr/bin/libtool | 18:03 |
| cjwatson | But having *some* way you can get it is a bit friendlier than that | 18:03 |
| infinity | cjwatson: I don't mind a bit of a revert war here. But following up to the Debian bug with the current state of affairs in Ubuntu and reasoning would also be helpful. | 18:05 |
| cjwatson | Yeah, I was just starting that | 18:05 |
| infinity | cjwatson: Other than the dependency on cpp, the M-A:allowed thing looked like exactly what the MACross spec would want me to do with a package like this. :/ | 18:05 |
| doko | cjwatson, for trusty maybe revert the split, and make it foreign again. there are too many build failures for now. I'll summarize these once the main rebuild is finished. but probably not the right time to start fixing all these now | 18:06 |
| cjwatson | This is very reminiscent of the abortive M-A: allowed -ing of gettext | 18:06 |
| cjwatson | doko: Failures due to missing /usr/bin/libtool? | 18:06 |
| doko | yes, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140108-trusty.html is still running with the split package, will try to summarize tomorrow | 18:07 |
| cjwatson | doko: Ugh, OK. That sounds like (as Kurt suggested) we want a targeted test rebuild of just this change. | 18:09 |
| cjwatson | doko: The test rebuild of main has 13 hours to go on i386 - how about we revert the split tomorrow? I can wait until then | 18:09 |
| doko | cjwatson, K | 18:09 |
| doko | ok | 18:09 |
| infinity | Well, the split's already reverted in the archive, it's just allowed instead of foriegn. | 18:09 |
| infinity | So, if you revert that too, we're back to square 1. | 18:10 |
| infinity | But doko's building against a split PPA version, that's all. | 18:10 |
| infinity | (And that would need a revision bump to keep ahead of an archive upload) | 18:10 |
| doko | ohh, ppc64el did finish first, even armhf is still running | 18:12 |
| cjwatson | Well, not if we decide the split is too much trouble and want to ditch it for the copy archive too | 18:12 |
| cjwatson | doko: failures are quick :) | 18:12 |
| doko | heh, there aren't that many more | 18:13 |
| cjwatson | (Also, as Kurt says, with the split, the libtool package itself could be Architecture: all.) | 18:15 |
| cjwatson | infinity: heh, working through the analysis here is interesting | 18:58 |
| cjwatson | infinity: it turns out, AFAICT, that if you try to do the "obvious" thing with the split where you make libtool depend on libtool-bin, there's no way to arrange the multiarch annotations so that you actually gain anything useful | 18:59 |
| infinity | cjwatson: Indeed. | 19:02 |
| === josepht_ is now known as josepht | ||
| sbeattie | doko: FYI, the apparmor libtool failure is bogus, is fixed upstream, and will be fixed in the archive soon. | 19:05 |
| xnox | cjwatson: i did not anticipate such libtool fallout. Indeed i have a very "Depends:" centric view of it rather, "Build-Depends:" one as required here. | 19:30 |
| doko | infinity, please have a look at the gdb build on toyol. builds since yesterday | 20:14 |
| infinity | doko: I assume something's spinning in the background. | 20:25 |
| * infinity finds someone to look. | 20:25 | |
| doko | ok, will ask launchpad operators next time | 20:29 |
| directhex | Laney, so we should be able to sync enough stuff to get dbus# to transition in trusty - except for the gtk#3 main issue | 21:04 |
| infinity | doko: Just to be confusing, it's lp-ops for x86/armhf/powerpc, and me for arm64/ppc64el (until we get those machines in a sane enough state to hand them over) | 21:07 |
| infinity | doko: s/lp-ops/webops/ | 21:07 |
| Noskcaj | kirkland, Any chance of a testdrive release soonish, since Vbox 4.3 is now in trusty | 21:19 |
| kirkland | Noskcaj: yeah, perhaps...have you tested trunk? are you happy with it? are there any outstanding merges still waiting? | 21:29 |
| bdmurray | arges: just to be clear the openvswitch SRU is meant to supercede the current one in -proposed correct? | 21:29 |
| arges | bdmurray: hi. No it fixes the previous 1.4.6 upload | 21:29 |
| Noskcaj | kirkland, I'll branch now and do some testing. I think the only other branch is the gtk3 stuff, and really i need you or andres to help with that, since my glade has never worked | 21:29 |
| Noskcaj | And gtk3 is a requirement for python3 | 21:30 |
| arges | bdmurray: sorry yes, it does superceede it | 21:30 |
| kirkland | Noskcaj: cool -- let me know if current trunk is good for you, and sure, I'll cut/upload a release | 21:30 |
| kirkland | Noskcaj: and we can work the gtk3 stuff after | 21:31 |
| Noskcaj | And this release should probably go to debian, if you can set me as the maintainer. | 21:31 |
| bdmurray | arges: got it, thanks | 21:31 |
| === salem_ is now known as _salem | ||
| smagoun | cyphermox: hey, just as heads-up that I'm still running your network-manager and I still haven't seen a single 'authentication failed' dialog. By now I would expect to have seen 3 or 4 of them | 21:31 |
| === rickspencer3_ is now known as rickspencer3 | ||
| Noskcaj | kirkland, testdrive-gtk won't launch locally, but i think that's something i broke by using the setup.py and part of the .deb. If it launches for you, we should be good to go. | 21:45 |
| cyphermox | smagoun: cool! | 21:50 |
| smagoun | cyphermox: I'll keep this running over the weekend (things always break on weekends - right?) and post an update in the bug on Monday. Does that work for you? | 21:51 |
| cyphermox | sure | 22:00 |
| cyphermox | I already updated the bug, note that I marked it as a duplicate of another | 22:00 |
| cyphermox | I pushed the patch over to upstream, some people started to look at it | 22:00 |
| kirkland | Noskcaj: hmm, odd, I'd be very interested to know exactly what's wrong then | 22:24 |
| Noskcaj | kirkland, I went normal repo version, testdrive.deb, setup.py, so i've broken a lot of stuff. http://paste.ubuntu.com/6723364/ was my error | 22:25 |
| === freeflying is now known as freeflying_away | ||
| Aaron | wow how sexy it's the python error | 23:02 |
| Aaron | hey to who do i speak about a channel? | 23:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!