[03:53] <Fudge> any truth to roumers about a Ubuntu mate remix?
[03:54] <Fudge> roumors
[03:58] <cjwatson> Fudge: I've heard some noises about it, but it hasn't reached the point of people coming to the release team asking for official builds yet.
[03:58] <cjwatson> I think there is some work happening on it though.
[04:07] <Fudge> thanks very much cjwatson
[04:08] <Fudge> we were thinking of a meta package for Vinux users who love the old Gnome2 feel but personally I like Unity
[05:21] <pitti> Good morning
[05:22] <pitti> Noskcaj: are iodbc and unixodbc now installable in parallel, or did Debian's psqlodbc now drop support for iodbc?
[05:42] <pitti> doko_: I forwarded the unity-scope-click autopkgtest failure to dobey; seems the new gcc now emits a new warning which makes it FTBFS
[05:42] <pitti> doko_: that's the one that holds back the gcc-4.0 upload, FYI
[08:54] <cristian_c> Hi
[08:54] <cristian_c> I was testing a wifi guide to enable the EOL repositories
[08:55] <cristian_c> apt-get update is working, but apt-get install no
[08:56] <Laney> doko: are you aware of gcc-doc bustage?
[08:56] <cristian_c> I get many 404 not found
[08:56] <cristian_c> *s
[08:57] <cristian_c> Investigating, I discovered that EOL repositories are not updated
[08:58] <cristian_c> I was suggested to open a bug report for these problems
[09:00] <cristian_c> Can you confirm this problem and explain how to open the report in my case?
[09:00] <pcarrier> hi! I've been frustrating by the gdb/ddeb experience on precise. coming from the el world, after a debuginfo-install I get source listings out of the box when inspecting core dumps
[09:00] <pcarrier> am I missing something to make it work?
[09:02] <pcarrier> for example, here I'm pretty sure I installed the correct version of rsyslogd-dbgsym, yet gdb doesn't find the source:
[09:02] <pcarrier> #3  0x00000000004319a6 in qqueueEnqObj (pThis=0x23d6d80, flowCtlType=eFLOWCTL_NO_DELAY, pUsr=<optimized out>) at queue.c:2400
[09:02] <pcarrier> 2400 queue.c: No such file or directory.
[09:38] <seb128> do we have a script that does "fetch all the debs from a ppa build"?
[10:31] <darkxst> seb128, as in all debs for a single package? no idea if there is a script I just do it with apt pinning
[10:32] <seb128> darkxst, I don't want to use apt, typically I just want to wget/download the debs from a build page, like https://launchpad.net/~ci-train-ppa-service/+archive/landing-019/+build/6072535
[10:32] <seb128> that's for local reviewing, not for installing
[10:33] <darkxst> seb128, source or binary?
[10:34] <shadeslayer> bdmurray: none of the issues listed on http://people.canonical.com/~ubuntu-archive/phased-updates.html against kde-workspace can be found
[10:34] <seb128> hey SRU team, could anyone review unity-settings-daemon in the trusty SRU queue? it fixes an important issue with touch screen configs that the oem team would be happy to see resolved
[10:35] <shadeslayer> oh
[10:35] <seb128> darkxst, binaries, I get dget the .dsc for source, but e.g the url I just copied a > 10 debs
[10:35] <seb128> darkxst, it's a bit annoying to click on them all and click download for each
[10:36] <darkxst> seb128, pretty sure you could the urls in less than 10 lines of python, but I dont have a script
[10:36] <seb128> darkxst, right, I was just asking in case we had a standard script is some devtools collection
[10:36] <seb128> I'm going to write one myself otheriwse
[10:36] <seb128> just trying to avoid reinventing things
[10:37] <seb128> thanks for replying though ;-)
[10:37] <mlankhorst> Laney: I've reviewed my code and found some more missing unlock paths, can you try  mesa - 10.1.3-0ubuntu1+ppa1 from the canonical-x/x-staging ppa?
[10:37] <Laney> mlankhorst: okay, in a short while
[10:37] <Laney> is this going upstream?
[10:37] <seb128> bdmurray, infinity, stgraber, arges, slangasek, ..., ^ see the unity-settings-daemon ping some lines earlier, if one of you could have a look this week that would be nice ;-)
[10:37] <mlankhorst> eventually
[10:38] <mlankhorst> need to review it some more first
[10:40] <zbenjamin> can anyone tell me what getprop "ro.product.cpu.abi" would return on a amd64 machine?
[10:40] <zbenjamin> would it be also x86
[10:41] <ogra_> zbenjamin, only if you have an android running on your amd64 :)
[10:41] <ogra_> (i doubt there are amd64 android builds)
[10:42] <zbenjamin> ogra_: i see, it will still be a 32bit build hmmm
[10:42] <ogra_> what are you trying to do ?
[10:42] <zbenjamin> ogra_: i need to map the devices abi to the abi inside QtCreator and right now i look for a way to find out whats the correct way
[10:43] <ogra_> for the using the emulator ?
[10:45] <ogra_> (i mean, do you look for the arch of the host or of the target system ? getprop will not be available on desktops, only indsie ubuntu touch VMs or real HW)
[10:45] <ogra_> *inside
[10:50] <zbenjamin> ogra_: for the target system
[10:51] <ogra_> for that using getprop should be okayish
[10:51] <zbenjamin> i could use uname i guess
[10:51] <ogra_> yeah, that works for sure
[10:51] <zbenjamin> ogra_: thx
[10:51] <ogra_> and will even work once we have actual x86 tablets etc
[10:51]  * zbenjamin --> lunch
[10:51] <ogra_> (that dont use an android container)
[10:52] <zbenjamin> ogra_: yeah thats what i had in mind
[10:52] <zbenjamin> bbl
[10:52] <ogra_> note that it wont return debian arches that way though
[10:53] <ogra_> phablet@ubuntu-phablet:~$ uname -m
[10:53] <ogra_> armv7l
[11:44] <xnox> zbenjamin: uname returns the kernel, not the userspace abi. Uname can be amd64, yet userspace i386.
[11:44] <xnox> zbenjamin: i think you want $ dpkg --print-architecture
[11:45] <xnox> zbenjamin: but thanks to qemu-user-static for example I can execute armhf, i386 and amd64 binaries on my amd64 machine.
[11:46] <xnox> ev: errors.ubuntu.com is not showing a graph =(
[11:50] <ev> xnox: we just cut over to a new database. That will return ~tomorrow.
[11:50] <xnox> ev: =( ok.
[13:32] <zbenjamin> xnox: what i need is the architecture/abi i have to use to compile apps for the device
[13:33] <xnox> zbenjamin: at the moment we have two: armhf (all devices + emulator) and i386 (emulator)
[13:33] <xnox> zbenjamin: adb shell dpkg --architecture, will tell you the architecture device is running.
[13:34] <xnox> --print-architecture that is
[13:35] <cjwatson> seb128: script> citrain in phablet-tools-citrain is sort of close
[13:37] <ogra_> did that land already ?
[13:37] <cjwatson> Well, I have it from ppa:phablet-team/tools
[13:37] <ogra_> oh, it is a separate package
[13:38] <ogra_> yeah, i thought it was supposed to be merged into phablet-tools
[13:38] <cjwatson> it's in utopic though
[13:38] <ogra_> (it did ... but only on source level ... produces its own binary)
[14:05] <ev> make experts: is there any way of having a match-anything rule that doesn't try to evaluate files? I'm trying to have a fallback rule that effectively passes an argument to another rule, so that I can do `make name.of.test.to.run`
[14:05] <ev> and then a rule (with dependencies) gets executed, passing name.of.test.to.run as a command line argument
[14:07] <cjwatson> does declaring the non-file-based-target in .PHONY help?
[14:15] <ev> cjwatson: nope - so perhaps I'm doing something entirely wrong here: http://paste.ubuntu.com/7628766/
[14:15] <ev> $@ ends up being the first file in the directory, Makefile
[14:15] <jtaylor> ev: have a variable with ?=
[14:16] <jtaylor> e.g. TESTS ?= $(wildcard *runfiles)
[14:16] <jtaylor> make TESTS=on-ythis-file-please
[14:16] <jtaylor> like regular make check
[14:16] <jtaylor> automake check
[14:17] <ev> yeah, I guess I could fall back to that. It just looks ugly and creates inconsistency between running ./run-tests with arguments and feeding something an env var.
[14:18] <ev> but I'm already abusing make for this
[14:19] <jtaylor> its not an env variable its a make variable
[14:19] <ev> indeed
[14:20] <mlankhorst> Laney: ping? :P
[14:20] <Laney> not yet sorry
[14:28] <pitti> cjwatson: is there something like "click uninstall", or is that simply "sudo rm -r /opt/click.ubuntu.com/com.ubuntu.calculator/" ?
[14:29] <pitti> I found "unregister --all-users", but that's not the same
[14:30] <ogra_> pitti, adb shell click unregister --user=phablet $PACKAGE
[14:31] <cjwatson> pitti: unregister
[14:31] <doko> dobey, could you have a look at https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-unity-scope-click/lastBuild/?  not sure if pitti already told you
[14:31] <cjwatson> Don't just do rm -r, you'll leave bits behind
[14:33] <seb128> cjwatson, thanks
[14:34] <pitti> cjwatson: I tried that (with and without --all-users), it still leaves /opt/click.ubuntu.com/com.ubuntu.calculator/* behind
[14:34] <pitti> that just hides it
[14:35] <cjwatson> pitti: in general that depends whether the app is running
[14:36] <cjwatson> it should get GCed eventually; normally, don't worry about it
[14:36] <pitti> cjwatson: ah, ok; thanks!
[14:36] <cjwatson> --all-users likely isn't what you want unless it was registered with --all-users to start with
[14:36] <pitti> cjwatson: I don't know how it was registered; it's installed by default
[14:38] <pitti> cjwatson: use case: for testing a local .click I wanted to ensure that no other version is installed, and then click install that one; but perhaps I don't need to do that cleanup
[14:38] <cjwatson> you don't
[14:38] <cjwatson> any user-installed version will override things installed by default
[14:38] <cjwatson> the installed-by-default stuff will be in /usr/share/click/preinstalled/, not /opt/click.ubuntu.com/, and it is generally not possible to remove those (unless the image is writable)
[14:38] <cjwatson> so we don't try, we just hide it
[14:39] <cjwatson> but anyway the structure of the database makes that sort of care unnecessary
[14:39] <cjwatson> https://click.readthedocs.org/en/latest/databases.html FWIW
[14:39] <pitti> hmm; apparently I managed to actually remove /opt/click.ubuntu.com/com.ubuntu.calculator/1.3.279/ (as on current image), but still have 1.3.277/ (my local install), and now can't unregister/remove the latter
[14:40] <pitti> cjwatson: thanks
[14:40] <cjwatson> look through /opt/click.ubuntu.com/.click/, there might be a @gcinuse thing somewhere
[14:40] <pitti> ah, 276 was in the image, 279 came as an app update
[14:41] <cjwatson> in any case, it isn't supposed to matter - the version that's actually used is looked up dynamically in the .click directories
[14:41] <cjwatson> stray versions are allowed to hang around a bit
[15:00] <dobey> doko: yes. will have a fix in a few minutes
[15:15] <zbenjamin> xnox: thx
[16:00] <rbasak> infinity: ping, re: juju-core powerpc ftbfs
[16:16] <infinity> rbasak: Yo.  I'm still trying to get to the bottom of it.  But, as I said yesterday, why should a utopic FTBFS be holding up trusty in any way?  We already know it builds on trusty.
[16:16] <rbasak> Sorry, I must have missed your reply.
[16:17] <rbasak> I wanted Fix Released status in Utopic for an SRU to Trusty. But I guess having it in utopic-proposed is enough?
[16:18] <infinity> rbasak: Having it in proposed is enough.
[16:18] <infinity> rbasak: The point of that rule isn't that development users are more important and must get the fix first, the point is for the fix to not get lost/forgotten in the devel release.  Uploaded, or even commited to a branch that you guarantee will get uploaded, is good enough.
[16:19] <rbasak> OK, thanks. I'll work on the SRU.
[16:46] <ogra_> did we switch the compiler default to 4.9 already ?
[16:46] <hallyn> xnox: hey, you're DD right?  Would you mind taking a look at http://people.canonical.com/~serge/netcf-src-0.2.4/netcf_0.2.4-1.dsc and potentially sponsoring it?
[16:46] <hallyn> xnox: normally ahs3 uploads for me but he's swamped with real life
[16:46] <xnox> hallyn: sure.
[16:46] <hallyn> xnox: thanks!
[16:47] <ricmm> ogra_: lemme know if I missed the reply
[16:48] <xnox> hallyn: i need to sprint somewhere with you, to get keys cross-signed.
[16:48] <ogra_> doko, did we swithc the compiler default to 4.9 already ?
[16:48]  * xnox hasn't seen verification failed in a long time.
[16:48] <ricmm> xnox: hey, are we using 4.9 by default in u now?
[16:48] <ricmm> or doko
[16:50] <xnox> ogra_: ricmm: i believe we use 4.9 by default from now on. Let me find out when that happened.
[16:50] <ogra_> must have been very recent
[16:51] <xnox> ogra_: it's about a month late.
[16:51] <xnox> ricmm: older compilers are still available and you can choose to use an older one.
[16:52] <hallyn> xnox: are you going to be at linuxcon chicago or plumbers dusseldorf?
[16:52] <xnox> ogra_: as off 2 hours ago.
[16:52] <ogra_> hah !
[16:52] <hallyn> anyway come up with a pretext i love to sprint :)
[16:52] <ogra_> ricmm, so that might be your prob :)
[16:53] <ricmm> it is indeed
[16:53] <ricmm> I just checked, the first failing build is using 4.9
[16:53] <ricmm> instead of 4.8
[16:53] <ricmm> boom headshot
[16:53] <ricmm> I'm never landing my stuff
[16:53] <ogra_> oh my
[16:53] <xnox> slangasek: ^ can i go to linuxcon chicago or plubmers dusseldorf? Or have a cloud vs core stand-off sprint =)
[16:53] <cjwatson> as he said you can Build-Depends: gcc-4.8 and set CC=gcc-4.8, or similar
[16:54] <ogra_> right
[16:54] <xnox> ricmm: build-depend on gcc-4.8 set 4.8 compiler. Or give me the build failure and maybe i can fix it for you?
[16:54] <cjwatson> though clearly this is technical debt
[16:54] <slangasek> xnox: ... to get keys cross-signed with hallyn?
[16:54] <xnox> ricmm: what's the build log?
[16:54] <ogra_> cjwatson, just that this needs a change of the MP and means re-testing everything again
[16:54] <xnox> slangasek: yes.
[16:54] <cjwatson> ogra_: sure
[16:54] <ricmm> xnox: this is a tough header-based thing with dbus-cpp
[16:54] <ricmm> its not a build failure, its a runtime hashtable explosion
[16:54] <xnox> ricmm: that's fine, what's the build failure? =)
[16:54] <ricmm> so maybe an ABI break somewhere
[16:54] <ogra_> cjwatson, ricmm is only trying to land that since 4 weeks :P
[16:54] <slangasek> xnox: try to be more circumspect about your motives
[16:54] <ogra_> it was done today :)
[16:54] <cjwatson> ogra_: this isn't really a helpful line of argument ...
[16:55] <ricmm> there is no argument, forget about it all
[16:55] <ogra_> not a line of argument at all ...
[16:55] <xnox> ricmm: i believe dbus-cpp is compiled with 4.7, maybe we need to recompile dbus-cpp with 4.9
[16:55] <ogra_> just a comment
[16:55] <ricmm> I'll have this thing work 4.8 and bye bye
[16:55] <ricmm> dbus-cpp is 4.8
[16:55] <ricmm> probably will need a recompile yea
[16:55] <ricmm> I'll figure it out dont worry
[16:55] <ricmm> just wanted to know when the change had happened
[16:55] <ricmm> to confirm
[16:55] <ricmm> thanks
[16:57] <hallyn> lol.  xnox: slangasek ain't gonna go for that one :)
[16:58] <hallyn> xnox: i bet we can come up with very good reasons.  systemd.vs.cgmanager.vs.lxc comes to mind
[16:58] <hallyn> which is very much inplay at both linuxcon and plumbers, in fact
[16:59] <cjwatson> ricmm: perhaps this is simply that dbus-cpp is hardcoding 4.8 and something built on it is failing to hardcode 4.8 and was assuming that default gcc == 4.8
[16:59] <cjwatson> or something like that
[17:01] <hallyn> mdeslaur: stgraber: (zul:)  if no objections i'll push http://paste.ubuntu.com/7629496/
[17:02] <mdeslaur> hallyn: fine with me
[17:02] <hallyn> mdeslaur: on the topic, are you actively working on the $)(*&)%(* required for virt-manager merge, or are we all just hoping someone else does it?  :)
[17:02] <hallyn> i'll try to look into it assuming you do not have time.
[17:03] <hallyn> or, that's right, you were mentioning something new that may be easier to have ppl switch to?
[17:03] <stgraber> hallyn: LGTM
[17:03] <hallyn> thx, pushing
[17:03] <mdeslaur> hallyn: I've done it, it's just that there are a zillion MIR bugs to file
[17:03] <hallyn> mdeslaur: right, that's waht i meant
[17:03] <mdeslaur> hallyn: give me a couple of days, and I'll take a look
[17:03] <hallyn> although,
[17:03] <hallyn> virt-manager isn't in main is it?
[17:03] <mdeslaur> yeah, it is
[17:04] <hallyn> egads
[17:04] <mdeslaur> right
[17:04] <mdeslaur> might be easier to demote it :P
[17:04] <hallyn> ok - thanks, happy to wait :)
[17:04] <hallyn> yes,
[17:04] <mdeslaur> is it part of anything strategic that we ship?
[17:04] <hallyn> i'm not sure anyone uses it on server anyway...
[17:04] <hallyn> not that i know of
[17:04] <mdeslaur> ok, I'll look into that possibility too
[17:05] <hallyn> jamespage: smoser: ^ do you know if virt-manager needs to be in main for any particular reason?
[17:05] <hallyn> the only thing rdepending on it is ubuntu-virt-mgmt :)  which sounds like a bogus metapackage
[17:06] <hallyn> oh and is in universe anyway
[17:06]  * sarnold weighs how many MIRs might be needed vs having a simple bloody tool that can show which VMs are actually running...
[17:07] <smoser> hallyn, i dont have a good reason off the top of my head
[17:08] <hallyn> sarnold: simple tool like xterm -e "while :; do virsh list; sleep 5m; done"
[17:08] <hallyn> :)
[17:08]  * sarnold hugs hallyn 
[17:08] <hallyn> lol
[17:20] <rbasak> hallyn: you know about watch, right? "watch -n300 virsh list"
[17:29] <hallyn> i do
[17:30] <hallyn> but what can i say i like manually looping
[17:33] <rbasak> You like doing what? :)
[17:34] <sarnold> the man likes to control his own loops
[17:34] <sarnold> he'd have used goto except shell makes that hard :)
[17:35] <doko> ricmm, what exactly is the issue? didn't see a reply when xnox or ogra_ were asking
[17:35] <ogra_> doko, dbus-cpp is compiled against 4.7 or 4.8
[17:35] <ogra_> that caused a bunch of build issues now
[17:35] <doko> ogra_, and why is this an issue?
[17:36] <ogra_> dunno ... they are working on porting it now ...
[17:36] <xnox> doko: no reply either.
[17:36] <ogra_> (no worries, it was just the info that the default switched that was important )
[17:36] <xnox> ricmm: can you please give us projects which need fixing?
[17:37] <xnox> ricmm: doko and I, are both from foundations team and we are ultimately responsible to get all packages fixed for 4.9.
[17:38] <ogra_> xnox, silo 007
[17:39] <ogra_> rebuilding the location-service FTBFS due to dbus-test-runner timing out
[17:40] <ogra_> xnox, doko, seems a simple rebuild of dbus-cpp fixes everything ... it was just that nobody was aware the default had changed
[17:46] <doko> ogra_, xnox: it's suspicious that a simple rebuild fixes things ...
[17:46] <ogra_> well, dbus-cpp is special :)
[18:50] <doko> dobey, thanks for the fix
[18:50] <dobey> no problem :)
[19:15] <pitti> jcastro: hey! so I'm trying "juju quickstart" as in your tutorial, as that looked really nice; I get http://paste.ubuntu.com/7630057/ and now it's just hanging
[19:15] <pitti> jcastro: and no running wget; any idea how I can check what's going on?
[19:15] <jcastro> pitti, can you ping frankban on #juju-gui? Marco and I are in the middle of another session
[19:15] <pitti> jcastro: strace is just in an endless futex wait
[19:15] <pitti> jcastro: sure, thanks
[19:38] <xnox> tedg: !!!!
[19:38] <tedg> ?
[19:38] <xnox> tedg: oh, surprisingly it wasn't you this time =)
[19:39] <xnox> tedg: indicator-datetime adding a semi-bogus recommends =)
[19:39] <tedg> ?
[19:39] <xnox> bug 1309063
[19:40] <xnox> pulls in ubuntu-touch-sounds
[19:40] <xnox> into all instalations of indicator-datetime => everywhere
[19:41] <tedg> xnox, not sure that's a bad thing? how else would we ensure we had an alarm sound?
[19:56] <xnox> tedg: indicator-datetime does alarms on xubuntu & unity7 ?!
[19:56] <xnox> tedg: and it should fallback to the desktop sound theme -> thus get alarm sound from the theme
[19:56] <xnox> not a file on disk
[19:57] <tedg> xnox, I believe the issue there is that the mechanisms on the phone aren't theme aware.
[19:57] <tedg> xnox, And we will do alarms if someone uses that Ubuntu SDK to set them.
[19:59] <xnox> k, cool.
[19:59] <xnox> weird, i thought sounds came from the same themeing capability as icons.
[20:00] <xnox> and i thought we do have that in the sdk -> well, pure qt
[20:01] <tedg> xnox, It's similar, but just a matter of programming :-)
[22:36] <slangasek> ricmm, doko: bug #1329089 filed
[22:37] <slangasek> ricmm, doko: I think I'm going to revert the gcc-defaults change, until we have a handle on the cause of this incompatibility
[23:08] <infinity> slangasek: You'd think that if this was a fundamental ABI breakage issue, we'd have seen it in a lot of testsuite during the 4.9 rebuild tests, since most of them would have been running against 4.8-built libraries.
[23:08] <infinity> slangasek: Is it possibly that dbus-cpp itself is just doing something Very Bad?
[23:08] <slangasek> infinity: interestingly we've turned up that at the time of the archive rebuild, several of these components were hard-coded to use a different compiler /earlier/ than 4.8
[23:08] <slangasek> so it's possible that this was a 4.8-specific ABI breakage
[23:09] <infinity> slangasek: Or possible that these components are somehow crazy. :P
[23:10] <slangasek> you don't blame the python script when the interpreter segfaults, and you don't blame the library when the ABI output by the compiler changes
[23:10] <infinity> slangasek: You do when the library does things against spec that intentionally break its ABI, but yes, point taken.
[23:17] <doko> slangasek, so is there anybody available from the phone team who can tell what the failing test is supposed to test?
[23:18] <slangasek> doko: ricmm might be able to; but I know this was holding up a stalled landing, so he's been busy working around it on his side and may not be in a position to discuss it right now
[23:39] <infinity> slangasek: dbus-cpp is tvoss's baby, isn't it?  Maybe he could shed some light on if it's doing something naughty with C++ that it shouldn't.
[23:39] <slangasek> infinity: in an appropriate timezone, probably
[23:40] <slangasek> in the meantime, I've reverted the default compiler to 4.8, so we're not under time pressure
[23:41] <infinity> You bumped the epoch instead of just mangling versions?  Fun.
[23:42] <infinity> I guess that's easier than making gcc_4.8 depend on gcc-4.9
[23:42] <infinity> Err, other way around.
[23:43] <doko> well, bumping the epoch should be a no-go
[23:43] <infinity> doko: It's already been done.
[23:43] <slangasek> doko: how does that follow?
[23:44] <slangasek> or rather: what would you expect to do in a revert if not an epoch?
[23:44] <doko> because any synced versioned deps will be meaningless in ubuntu from now on
[23:44] <cjwatson> the +really convention is less intrusive
[23:45] <cjwatson> less permanently intrusive I mean
[23:45] <doko> slangasek, just change the dependencies
[23:45] <cjwatson> do we have time to undo the epoch with archive hackery?  that's kind of scary
[23:45] <slangasek> cjwatson: sure, but much more error-prone for a metapackage that munges the binary version numbers of each individual binary at build time
[23:45] <infinity> It's still in proposed, we could thwack it.
[23:46] <slangasek> doko: as the Debian maintainer, why would you not just bump the epoch in Debian too?
[23:46] <slangasek> it already has an epoch there
[23:46] <slangasek> it's not like revving the epoch would cost you anything
[23:46] <cjwatson> I've stopped p-m so that we have time to finish this discussion
[23:46] <slangasek> cjwatson: thanks
[23:46] <cjwatson> will block gcc-defaults now, this was just quicker
[23:47] <slangasek> fwiw I don't like the idea of either +really, or having a mismatch between the binary package version and the compiler version it depends on; I think the epoch is least-bad here
[23:48] <cjwatson> I don't object to the epoch if doko accepts it in Debian but I think that Ubuntu-specific epoch changes should be avoided at nearly all costs
[23:48] <infinity> slangasek: The epoch is least bad, long-term, but I assume this is only a day-or-two-long solution while we hunt the issue.
[23:48] <infinity> And for a couple of days, ugly version tricks seem to make more sense.  But meh.
[23:48] <cjwatson> ok, gcc-defaults blocked, p-m unstopped
[23:48] <slangasek> infinity: again, error-prone
[23:49] <doko> I'll look at fixing the dependencies now
[23:49] <cjwatson> surely only "error-prone" in gcc-defaults' own build process, and that doesn't take long to check
[23:49] <slangasek> doko: ok, if you want to own this, I defer to you
[23:50] <slangasek> doko: though if you wanted to just agree to revving the epoch in Debian, you could go to sleep instead ;)
[23:50] <doko> I do not want to ... but it looks I'll have to if I do not want to bump the epoch
[23:50] <slangasek> why do you object to bumping the epoch?