[00:00] <apb1963> Which bug?  The bug in Qt?
[00:00] <sarnold> yes
[00:00] <apb1963> No
[00:02] <apb1963> It was suggested I install 4.8.5.. since the bug is in 4.8.2, it doesn't seem likely that anyone will care.
[00:05] <sarnold> except we've decided to support 12.04 LTS for another three years..
[00:06] <apb1963> that's the story yes
[00:10] <apb1963> Lord, there's page after page after page of how to report a bug and I've yet to find the link to actually report the bug.
[00:10] <sarnold> apb1963: try: ubuntu-bug konversation
[00:12] <apb1963> And is that different from https://bugs.kde.org/show_bug.cgi?id=329793
[00:12] <sarnold> apb1963: yes, that would be filed in the launchpad bug tracker, where probably ScottK would find it and look into it..
[00:13] <apb1963> great.  Thank you for that.
[00:13] <apb1963> ugh
[00:13] <apb1963> apport crashed
[00:13] <sarnold> o_O
[00:14] <sarnold> you very well might have a funky system, hehe. is there anything informative in dmesg or /var/log/  about it?
[00:14] <sarnold> (I had a system with machine check exceptions, it wasn't much fun..)
[00:16] <apb1963> you mean besides neverending dhcp requests?  No.
[00:17] <sarnold> :(
[00:17] <apb1963> so... ubuntu-bug apport then?
[00:17] <sarnold> worth a shot, it just might work.. :)
[00:18] <sarnold> (it _should_ work, but it already crashed once on you..)
[00:18] <apb1963> wait.... just noticed this.... prepare for minor flooding
[00:18] <apb1963> ubuntu-bug konversation
[00:18] <apb1963> python: ../../src/xcb_io.c:529: _XAllocID: Assertion `ret != inval_id' failed.
[00:18] <apb1963> KCrash: Application '' crashing...
[00:18] <apb1963> KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
[00:18] <apb1963> sock_file=/home/apb/.kde/socket-asterisk.saveabunny.com/kdeinit4__0
[00:18] <apb1963> QSocketNotifier: Invalid socket 68 and type 'Read', disabling...
[00:19] <apb1963> here's how I came to be... first I installed the mini iso for i386... then I installed kubuntu-desktop... and other stuff.
[00:19] <Logan_> apb1963: Have you updated?
[00:20] <apb1963> Every 20 minutes
[00:20] <Logan_> apt-cache show apport
[00:20] <Logan_> Which version do you have?
[00:20] <apb1963> Version: 2.0.1-0ubuntu17.6
[00:21] <Logan_> Hmm, yeah, you're updated.
[00:21] <apb1963> Depends: python (>= 2.6), python-apport (>= 2.0.1-0ubuntu5), lsb-base (>= 3.0-6), python-gi, gir1.2-glib-2.0 (>= 1.29.17), sysv-rc (>= 2.86.ds1-14.1ubuntu2), upstart-job
[00:22] <Logan_> You might want to take this to #ubuntu. This is a development channel.
[00:22] <apb1963> That's where I started 6 hours ago
[00:22] <Logan_> Or maybe even #kubuntu.
[00:23] <apb1963> So crashing software is not a development problem
[00:23] <Logan_> Well, it's more of a support problem if it's not occurring in a development release.
[00:23] <apb1963> yeah, they both passed the buck
[00:25] <apb1963> as did #kde, #kde-devel, #plasma and #konversation... though admittedly it's a library issue so it's amazing they were among the most helpful.
[00:26] <apb1963> Until finally someone said:
 I mean, I thought the idea behind LTS was 'get bigfixes really long'
[00:26] <apb1963> [Tuesday, January 14, 2014] [03:46:24 PM] <Sho_> *bugfixes
[00:26] <apb1963> [Tuesday, January 14, 2014] [03:47:00 PM] <PovAddictW> fsvo "bugfixes"
[00:26] <apb1963> [Tuesday, January 14, 2014] [03:48:03 PM] <PovAddictW> actually, 4.8.5 isn't available even in the latest ubuntu
[00:26] <apb1963> [Tuesday, January 14, 2014] [03:50:43 PM] <apb1963> who normally takes care of something like that?
[00:26] <apb1963> [Tuesday, January 14, 2014] [03:52:37 PM] <PovAddictW> ubuntu developers
[00:27] <apb1963> And so I came here
[00:28] <sarnold> apb1963: well, you can start with this: https://bugs.launchpad.net/ubuntu/+source/konversation/+filebug -- be sure to refernce the kde.org bugreport you filed earlier; it'd be a help if you could copy and paste the traceback, too.
[00:29] <sarnold> apb1963: once it's done, run "apport-collect <bugnumber>" -- and see if that runs or crashes..
[00:30] <apb1963> i'm actually installing debug symbols now
[00:30] <apb1963> what do I fill in for <bugnumber> ?
[00:31] <sarnold> whatever bug number you get from filing the bug manually at https://bugs.launchpad.net/ubuntu/+source/konversation/+filebug
[00:35] <apb1963> got it
[00:38] <apb1963> not positive since I got no feedback... but I think it's done.
[00:38] <apb1963> still waiting on debug symbols for apport
[00:39] <sarnold> apb1963: what bug number?
[00:41] <apb1963> apport-collect 1269199
[02:21] <YokoZar> bdrung: https://github.com/YokoZar/ppa-stats   <-- What do you think for inclusion in ubuntu-dev-tools ?
[02:22] <YokoZar> (gets download counts for a PPA)
[04:19] <Logan_> mfisch: Are you around?
[06:05] <doko> barry, for simple rebuilds which require 3.4 as the default we now have the https://launchpad.net/~ubuntu-toolchain-r/+archive/python3 ppa.
[06:43] <pitti> Good morning
[06:49] <pitti> infinity, RAOF: can you please set an exfail for colord 1.0.5-1's autopkgtest? colord newer worked
[06:49] <pitti> (holding up systemd)
[06:49] <RAOF> Bah, sorry.
[06:53] <RAOF> pitti: I don't know how to set an exfail, sorry.
[06:53] <doko> pitti, do you feel good enough to look at zeitgeist test failures?
[06:54] <pitti> RAOF: right, that was more like a CC:
[06:54] <doko> https://launchpad.net/ubuntu/+archive/test-rebuild-20140108/+build/5433297
[06:55] <pitti> seiflotfy__: ^
[06:56] <pitti> seiflotfy__: not very verbose, thanks to that silly automake parallel runner :(
[06:56] <doko> which timezone is he?
[06:56] <pitti> British or Central European, I think
[06:56] <pitti> so, still a bit early for hackers
[06:58] <seiflotfy__> doko: i thought i fixed thoise
[06:58] <seiflotfy__> let me have a closer look
[06:58] <seiflotfy__> vala keeps changing and zeitgeist keeps breaking
[06:58] <doko> seiflotfy__, seen in a test rebuild, so you need to update to trusty
[07:00] <seiflotfy__> thi is based on the latest release not git right?
[07:00] <doko> seiflotfy__, what you find in trusty
[07:00] <doko> 0.9.14-0ubuntu3
[07:03] <seiflotfy__> where can i find the source of this package?
[07:05] <seiflotfy__> doko:
[07:06] <seiflotfy__> nm
[07:06] <doko> apt-get source zeitgeist, if you are running trusty
[07:06] <doko> or dget <find the dsc file>
[07:06] <pitti> seiflotfy__: it's upstream 0.9.14 plus a few patches: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/zeitgeist/trusty/files/head:/debian/patches/
[07:07] <pitti> seiflotfy__: the first two patches are harmless, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/zeitgeist/trusty/view/head:/debian/patches/pre_populator.patch looks more interesting
[07:07] <seiflotfy__> ouh nice
[07:10] <pitti> seiflotfy__: more generally, I think there was a way to make failures less ridiculously useless with the automake 1.13 parallel runner
[07:10] <pitti> i. e. more than just "FAILhahagofigure"
[07:10] <seiflotfy__> i think i know what it is
[07:11] <seiflotfy__> but cant do patching right now
[07:11] <pitti> some "verbose" flag, if only I could remember
[07:12] <seiflotfy__> doko: pitti can one of view try someting for me please?
[07:13] <pitti> seiflotfy__: sure
[07:13] <seiflotfy__> pull the latest code from git and tell me if it works for you "make check"
[07:13] <seiflotfy__> because we had a "not building" issue when vala 22 came out and we fixed it just recently
[07:15] <seiflotfy__> pitti: ?
[07:16] <pitti> seiflotfy__: yes, on it; currently in daily dist-upgrade, need to wait until I get apt again for its build deps
[07:16] <seiflotfy__> ok cool
[07:16] <pitti> http://cgit.freedesktop.org/zeitgeist/zeitgeist/ ?
[07:19] <pitti> seiflotfy__: I try building the package with http://cgit.freedesktop.org/zeitgeist/zeitgeist/commit/?id=42f0f6b0f17a584b703981b8a392c3225c7a8e98 until the git checkout finishes (that takes a while)
[07:20] <seiflotfy__> yes sir
[07:20] <seiflotfy__> thats the patch
[07:21] <pitti> seiflotfy__: indeed, that helps quite a bit
[07:22] <pitti> now test/c has two failures
[07:22] <pitti> test/direct now succeeds
[07:22] <seiflotfy__> oh man, vala can really take a toll on me sometimes
[07:22] <seiflotfy__> ok upgrading a vm here  test this
[07:23] <pitti> seiflotfy__: git checkout done, building trunk here
[07:23] <pitti> seiflotfy__: the previous patch doesn't look like a vala-ism, though?
[07:23] <seiflotfy__> it is
[07:23] <seiflotfy__> because it worked with vala 20
[07:23] <seiflotfy__> but not with vala 22
[07:23] <seiflotfy__> we did not commit any changes in 6 months
[07:23] <seiflotfy__> so we did this to fix it for vala 22
[07:24] <pitti> oh, you disabled optimize_variant_allocation()
[07:24] <seiflotfy__> yes sir
[07:24] <pitti> trunk "make check" WFM
[07:25] <seiflotfy__> show me the failure print out for test/c
[07:25] <seiflotfy__> i have thin i know what it is
[07:26] <pitti> could be because package build runs tests under fakeroot or something; "fakeroot make check" fails early, but our package has some "disable_failing_tests.patch" for that AFAICS; hang on
[07:26] <doko> pitti, which b-d am I missing when I see
[07:27] <doko> telepathy-farstream/Makefile.am:69: HAVE_INTROSPECTION does not appear in AM_CONDITIONAL
[07:27] <pitti> seiflotfy__: http://paste.ubuntu.com/6754838/
[07:28] <pitti> doko: probably "gobject-introspection"?
[07:29] <doko> thanks
[07:29] <seiflotfy__> pitti: fixing it
[07:30] <pitti> seiflotfy__: oh, you have an idea? it happens during package build, but not with a plain "make check", even in our package tree
[07:30] <pitti> probably the package build cleans the environment
[07:30] <pitti> seiflotfy__: ah -- "env -i make check" in trunk reproduces it
[07:30] <pitti> seiflotfy__: for you, too?
[07:31] <seiflotfy__> yeah
[07:31] <seiflotfy__> it stilly
[07:31] <seiflotfy__> in test/c/test-event.c line 29
[07:31] <seiflotfy__> 39
[07:31] <seiflotfy__> sorry
[07:32] <seiflotfy__> setting the xdg directory fails
[07:32] <seiflotfy__> it used to be
[07:32] <seiflotfy__>   if (old_xdg_data_dirs != NULL)
[07:32] <seiflotfy__>     old_xdg_data_dirs = g_getenv ("XDG_DATA_DIRS");
[07:32] <seiflotfy__> but that segfaulted when i did make checks
[07:33] <pitti> seiflotfy__: oh, so in teardown() the g_setenv() gets a NULL
[07:33] <seiflotfy__> yeah
[07:33] <pitti> seiflotfy__: indeed, no XDG_DATA_DIRS during package build
[07:33] <pitti> so that's a simple fix
[07:33] <seiflotfy__> can you send me a patch or so
[07:33] <seiflotfy__> i need to shower and dress up (and get spanked at work)
[07:35] <seiflotfy__> pitti: ^
[07:35] <pitti> seiflotfy__: yes, on it
[07:37] <pitti> seiflotfy__: http://people.canonical.com/~pitti/tmp/0001-Fix-unit-test-failure-if-XDG_DATA_DIRS-is-not-set.patch
[07:37] <pitti> seiflotfy__: want me to attach that to a bug report, or can you just push it? (it's trivial)
[07:38] <seiflotfy__> bug if poosible
[07:40] <pitti> seiflotfy__: https://bugs.freedesktop.org/show_bug.cgi?id=73651
[07:45] <pitti> doko: zeitgeist fix upstreamed ^ and test-built in sbuild, uploaded
[07:48] <doko> pitti, seiflotfy__: nice!
[07:54] <doko> pitti, fyi, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140108-trusty.html
[07:54] <doko> will send an announcement later today
[08:03] <dholbach> good morning
[08:07] <pitti> hey dholbach
[08:08] <dholbach> hey pitti
[08:17] <pitti> doko: looking at cdbs test failures -- is dh_python2 supposed to stop moving files to /usr/share/pyshared/ ?
[08:18] <pitti> the package calls dh_python2 and then expects /usr/share/pyshared/testing/foo.py; but there is only ./usr/lib/python2.7/dist-packages/testing/
[08:18] <Logan_> doesn't it still create symlinks?
[08:18] <Logan_> I could be wrong, though
[08:18] <doko> pitti, yes, disabled that. upstream did start working around it for some reason
[08:18] <pitti> that's what I thought; file in /usr/share/pyshared/
[08:18] <pitti> and symlinks in /usr/lib/python*
[08:19] <doko> had to revert some upstream commits
[08:19] <doko> need to forward and propose that to debian
[08:19] <pitti> hm, I remember http://bugs.python.org/issue19352, but that was only for unittests, not general module loading
[08:20] <pitti> doko: forward the reversion of upstream commits, or drop the /usr/share/pyshared/ moving?
[08:20] <pitti> doko: in other words, should I adjust cdbs' tests to not expect /pyshared any more, or will pyshared reappear soon?
[08:21] <doko> pitti, no, it should not reappear. but when you forward, please say that this is not yet in debian
[08:21] <pitti> ack
[08:22] <pitti> doko: ah, from https://launchpad.net/ubuntu/+source/dh-python/1.20131021-1ubuntu5 ?
[08:24] <doko> yes
[08:25] <doko> pitti, looks like you were even involved with that: http://bugs.python.org/issue19352 ;p
[08:25] <pitti> doko: right, what I wrote 5 mins ago; but that was only for unittest
[08:26] <pitti> doko: and I uploaded a reversion of that patch to fix that (you said "go ahead" with that back then)
[08:26] <doko> sure
[08:27] <twb> Is there a standard place in a lp ppa that says "this isn't in main because <details>" ?
[08:28] <twb> Specifically I'm looking at https://launchpad.net/~arminha/+archive/python-aosd-release and I can't see such a thing; plan B is to email the maintainer (who is also upstream) and ask him.
[08:28] <pitti> doko: http://paste.ubuntu.com/6755022/ works now; does the changelog entry make sense?
[08:29] <doko> pitti, sounds fine
[08:29] <pitti> doko: ack, uploading and forwarding
[08:29] <Logan_> twb: no, there is no standard for that - better to do your plan B
[08:29] <twb> OK, thanks.
[08:29] <doko> pitti, does the test succeed without and with it?
[08:29] <pitti> twb: PPAs don't care much about components
[08:30] <pitti> doko: sorry, without what?
[08:30] <doko> pyshared
[08:30] <pitti> doko: tests currently fail because dh_python doesn't do pyshared any more
[08:30] <pitti> that's the reason for the FTBFS
[08:30] <doko> pitti, right, but does your updated version succeed in debian too?
[08:31] <pitti> i. e. dpkg -c | grep -q '/usr/share/pyshared/testing/foo.py'
[08:31] <pitti> fails
[08:31] <pitti> doko: I'll sbuild it in sid as well to make double-sure, but I don't see why not -- there's still the symlink, right?
[08:31] <doko> yes
[08:32] <zyga> good morning :-)
[08:32] <pitti> if that file wouldn't exist, python couldn't import it; that's how I wrote the changelog
[08:32] <pitti> hey zyga
[08:48] <pitti> doko: looking at pkgbinarymangler, too
[09:06] <Laney> hmm
[09:06] <Laney> anyone using debmirror? I started getting "rsync error: error in rsync protocol data stream (code 12) at io.c(605) [Receiver=3.0.9]
[09:06] <Laney> Warning: failed to use rsync to download extra files.
[09:06] <Laney> " lately
[09:07] <zyga> Laney: I was using it extensively until recently
[09:07] <zyga> Laney: which repository caused that problem for you?
[09:07] <Laney> yeah, the cronspam doesn't say sadly
[09:07] <zyga> Laney: (though I never saw anything like that)
[09:07] <Laney> it's doing ubuntu, ports and debian
[09:08] <zyga> Laney: hmm, well, I haven't kept my mirror up to date for a few weeks so I don't know
[09:08] <zyga> Laney: but I should be able to tell you if I see that later today
[09:08] <Laney> okay
[09:18] <doko> pitti, the folks ftbfs looks vala related
[09:29] <pitti> doko: pkgbinarymangler FTBFS fix uploaded
[09:53] <ekarlso> -/win 22
[10:15] <didrocks> hum
[10:15] <didrocks> Your mail to 'ubuntu-devel' with the subject
[10:15] <didrocks>     Post by non-developer to moderated list.
[10:15] <didrocks> I sent from didrocks@ubuntu.com
[10:17] <doko> didrocks, demoted ;p
[10:18] <didrocks> doko: seems so ;)
[10:18] <seiflotfy__> pitti: your patch works fine
[10:18] <seiflotfy__> pitti: trying to release a new package
[10:18] <doko> didrocks, you can re-enable that by fixing ten ftbfs issues ;)
[10:18] <didrocks> no, still in it seems: https://launchpad.net/~ubuntu-core-dev/+members#active ;)
[10:18] <pitti> seiflotfy__: ah, good; I added the patch to our package, it built fine now
[10:18] <didrocks> doko: can I get a cookie then? ;)
[10:18] <seiflotfy__> but it keeps complaining about install -D ../../../doc/libzeitgeist/zeitgeist-gtkdoc-index.sgml docs_c/zeitgeist-2.0-docs.xml
[10:18] <seiflotfy__> install: cannot stat ‘../../../doc/libzeitgeist/zeitgeist-gtkdoc-index.sgml’: No such file or directory
[10:18] <pitti> seiflotfy__: so, no urgency from my side
[10:19] <doko> didrocks, not only one, ten!
[10:19] <pitti> seiflotfy__: hm, autogen.sh'ed without --enable-gtk-doc or so?
[10:19] <didrocks> heh
[10:19] <seiflotfy__> o hyeah
[10:19] <seiflotfy__> my bad
[10:19] <seiflotfy__> ok will roll out a release then :D
[10:27] <seiflotfy__> pitti: will release on friday? is this ok? can you guys use the current git status...
[10:27] <seiflotfy__> ?
[10:27] <pitti> seiflotfy__: as I said, not urgent for us, I added the patch to our package already
[10:29] <seiflotfy__> ok cool
[10:48] <pitti> @pilot in
[11:11] <doko> mlankhorst, do you care about the libxcb transition?
[11:12] <mlankhorst> erm why?
[11:13] <doko> mlankhorst, soname change?
[11:13] <mlankhorst> hm not particularly care, but it sounds like something that would need solving :/
[11:13] <doko> then please do
[11:15] <mlankhorst> did any soname change then? I thought it was just adding present/dri3
[11:16] <seb128> mlankhorst, http://packages.qa.debian.org/libx/libxcb/news/20131227T000024Z.html has "Rename libxcb-sync0 for SONAME bump. "
[11:16] <mlankhorst> oh indeed
[11:17] <mlankhorst> libqt5gui5 and kde-window-manager depend on it, it seems
[11:17] <doko> mlankhorst, honestly you should be aware of such changes *before* you upload ;p
[11:21] <mlankhorst> if it was anything important or commonly used thing I would have noticed at least
[11:22] <doko> seb128, do you know why nobody added the ubuntu fonts to the fontconfig conf?
[11:22] <seb128> doko, I guess because nobody is actively maintaining fontconfig
[11:22] <doko> seb128, then why are you uploading new upstreams? ;-P
[11:25] <seb128> doko, because nobody else does and that's better than nothing ;-)
[11:26] <doko> seb128, could you merge the debian changes? would like to avoid interaction ...
[11:27] <seb128> doko, is there anything in there we specially need?
[11:27] <seb128> that merge is non trivial and I would prefer to let it to somebody who knows fontconfig a bit better than me
[11:31] <Laney> I don't know that it's safe to add the Ubuntu font there yet
[11:31] <Laney> sladen or someone knowledgable on the subject would be better to ask
[11:32] <darkxst> Laney, thanks for getting the cogl transition rolling ;)
[11:32] <Laney> darkxst: np, it's basically done now
[11:32] <Laney> looking at the last issue
[11:33] <doko> Laney, well, why not? the ubuntu fonts are not that new. is sladen still working on these?
[11:33] <Laney> somewhat
[11:34] <Laney> It's whether they can be substituted for other fonts without it looking weird
[11:34] <Laney> why don't you try it on your system?
[11:34] <seb128> well, it's not easy to try if you don't know what to look for
[11:34] <seb128> like you might need to look at office documents to see if it impacts on layouting there
[11:35] <doko> Laney, send me a patch and I'll check. just was looking at why openjdk didn't use these. and it's using fontconfig now
[11:35] <Laney> nice try :P
[11:36] <Laney> how do I get to a BPPH on launchpad's web interface?
[11:37] <cjwatson> https://launchpad.net/ubuntu/trusty/i386/groff-base
[11:37] <Laney> ta
[11:37] <cjwatson> You can search from the distroarchseries I think, but I find memorising the URL pattern easier :)
[11:37] <Laney> ok that doesn't help
[11:38] <cjwatson> (OK, you need to append the version to get the BPPH as such)
[11:38] <cjwatson> What are you looking for?
[11:38] <Laney> what happened to toonloop/arm64?
[11:38] <Laney> cogl transition, see update_output
[11:39] <cjwatson> That was in p-m's output before the cogl transition
[11:39] <cjwatson> update_excuses is clearer in this case; it's depending on things not ported yet
[11:40] <Laney> so it never migrated on arm64
[11:40] <Laney> ?
[11:40] <cjwatson> Indeed
[11:41] <cjwatson> If it weren't built on arm64/ppc64el at all, it would be OK, but since it is it isn't allowed to increase the uninstallable count
[11:41] <cjwatson> It might actually be simplest to port gstreamer0.10-plugins-bad and mencoder
[11:41] <cjwatson> (Haven't looked at what's blocking those)
[11:44] <mitya57> Hi, I need some advice on bug 1269203. If the package tries to overwrite files in libqt4-dbus:[ARCH], is Breaks/Replaces on libqt4-dbus (<< ...) not enough?
[11:45] <mitya57> Do I need Breaks/Replaces on libqt4-dbus:any in that case?
[11:51]  * s1aden reads scrollback re Laney and doko
[11:53] <sladen> Laney: there are certainly some fallbacks we could set to eg. have the monospace fallover to other monospace fonts, (rather than to something proportional in cases like arabic)
[11:54] <sladen> Laney: I guess it was not necessary to add it, since external documents coming are requesting things like "Times" "Helvetica", and those are what you need to provide substitutes for
[11:54] <sladen> Laney: whereas something asking for Ubuntu, on an Ubuntu system is likely wanting Ubuntu
[11:55] <sladen> Laney: (and going to suceed)
[11:56] <doko> sladen, I was reading #937200 and #1003857
[11:57] <doko> so should apps asking for serif or sans get dejagnu or ubuntu?
[11:59] <doko> dejavu even
[12:08] <mlankhorst> ok just a rebuild bump for qtbase-opensource-src and kde-workspace is enough for the libxcb-sync transition
[12:08] <mlankhorst> abi didn't even changed, just some symbols were removed and that triggered the soname bump
[12:15] <Laney> cjwatson: oh, it migrated anyway
[12:17] <pitti> happyaron: should I sponsor bug 1266520, or are you on it? (also relevant for Debian)
[12:41] <Riddell> mlankhorst: give us a ping if there's a change to be merged into kde-workspace packaging branch
[12:44] <streulma> hello, I see nothing difference between 13.10 and 14.04 for the moment
[12:44] <Laney> at least your system isn't broken :P
[12:45]  * ogra_ sees massive differences ... on his phones and tablets :)
[12:46] <mitya57> hello, I see nothing difference between Ubuntu and OS X for the moment
[12:46]  * mitya57 hides
[12:46] <Laney> we have a modern bash version
[12:46] <ogra_> mitya57, you forgot to mention the versions :P
[12:47] <mlankhorst> Riddell: ok
[12:47] <mitya57> And gcc :P
[12:47] <mlankhorst> Riddell: no change rebuild incoming :P
[12:47] <streulma> is it normal that the ubuntu sound is lower at starting dvd?
[12:48] <ogra_> streulma, see the channel topic, this is no support channel, please go to #ubuntu for support
[12:48] <streulma> the tamtam is different from earlier versions
[12:48] <streulma> I speak about trusty :p
[12:48] <Laney> try #ubuntu+1
[12:48] <ogra_> right
[12:52] <Riddell> mlankhorst: got a debdiff?
[12:53] <mlankhorst> https://launchpad.net/ubuntu/+source/kde-workspace/4:4.11.5-0ubuntu2 somewhere
[12:54] <Riddell> :)
[13:36] <mlankhorst> doko: ping
[13:52] <pitti> tjaalton, mlankhorst: is https://code.launchpad.net/~mitya57/ubuntu/trusty/xkeyboard-config/2.10.1-1ubuntu1/+merge/200141 something you want to handle in your team? (e. g. a two-way merge with Debian, some of our changes are useful for Debian as well)
[13:52] <mlankhorst> I thought xkeyboard was generic low level stuff, not x specific?
[13:53] <pitti> I don't know -- it's just a question
[13:53] <pitti> I'm happy to review/sponsor it, too
[13:54] <tjaalton> hmm, could push some of that to debian
[13:55] <tjaalton> mlankhorst: it's on package-status.html, and x-swat is sub'd to the bugs ,)
[13:55] <tjaalton> ;)
[13:56] <mlankhorst> well if you want to take it
[13:56] <mitya57> I didn't forward my changes to Debian because I prefer to get them applied upstream first
[13:57] <mlankhorst> erm for debian the changes should go into upstream first, because of policy :P
[13:57] <mitya57> Didn't know about that, but I agree :)
[13:58] <tjaalton> i'm fine with pushing the merge to trusty as-is
[13:59] <tjaalton> but stuff like multiarch and split xkb-data-i18n could probably be used by debian as well
[13:59] <mlankhorst> yeah
[13:59] <tjaalton> mitya57: are you a member of pkg-xorg on alioth?
[13:59] <mlankhorst> I'm testing why I get a kernel panic with nouveau from time to time atm
[13:59] <mitya57> tjaalton: No :(
[13:59] <tjaalton> mitya57: it's trivial to get accepted
[13:59] <mitya57> Please push it yourself if you can (and agree with the changes)
[14:00] <tjaalton> sure
[14:00] <tjaalton> but we host our git branches there as well
[14:01] <tjaalton> so you could just merge there and directly ask us to sponsor (we're on #ubuntu-x)
[14:01] <tjaalton> in the future I mean :)
[14:01] <mitya57> ok, will know
[14:02] <mlankhorst> yeah git is preferred :)
[14:04] <mitya57> pitti: thanks for sponsoring all my packages!
[14:06] <pitti> mitya57: yw!
[14:08] <doko> mlankhorst, just ask
[14:09] <mlankhorst> doko: how do I use hardening-wrapper in xorg-server?
[14:09] <doko> mlankhorst, ugh ... never did use this. maybe ask jdstrand or mdeslaur?
[14:10] <mdeslaur> mlankhorst: sbeattie can provide guidance when he arrives
[14:12] <pitti> tjaalton, mitya57: ok, not touching xkeybaord-config then?
[14:12] <tjaalton> pitti: nah feel free to
[14:12] <pitti> ack
[14:22] <doko> pitti: don't know who is responsible for platform-api ... but it sits in component-mismatches, and I doubt we want lcov in main
[14:25] <rharper> hallyn: https://code.launchpad.net/~raharper/qa-regression-testing/scripts-test-qemu-fixups  -- this passes all 22 tests on a trusty vm -- I'm going to run against the previous releases next to make sure I didn't regress any tests
[14:27] <pitti> doko: that was tvoss, I think
[14:30] <hallyn> rharper: awesome, thanks
[14:30] <rharper> np
[14:30] <rharper> hallyn: once I confirm I didn't regress, should I propose for merging ?
[14:31] <hallyn> rharper: yeah that'd be good
[14:31] <rharper> cool
[14:31] <hallyn> rharper: we can ask whether jdstrand wants to review it, if not I *think* I can merge it
[14:32] <rharper> ok
[14:32] <hallyn> jdstrand: speaking of reviews, who should I be bribing^Wasking about getting a security review of the cgmanager package at lp:~serge-hallyn/+junk/cgmanager ?
[14:33] <hallyn> jdstrand: aside from a security review of the code,I'd also like to re-review the design to discuss whether I'm opening up any possibilities for unprivileged users to abuse privileged ones
[14:34] <hallyn> jdstrand: so if anyone from security team will be in london we could do it in person there perhaps
[14:34] <jdstrand> re that merge> isn't that going to fail on earlier releases?
[14:34] <infinity> pitti: colord hint bumped.  Is there a Debian bug, or anyone with an urge to fix it? :P
[14:35] <jdstrand> hallyn: re cgmanager> probably sarnold (code mostly) and mdeslaur (design mostly)
[14:35] <jdstrand> hallyn: we won't be
[14:35] <pitti> infinity: thanks; RAOF looked into it recently, but there's still one failure left (no bug ATM)
[14:36] <hallyn> jdstrand: I haven't looked at the merge proposal yet for qrt
[14:36] <jdstrand> rharper (and hallyn): it seems the test-qemu.py fixes need to be made trusty-specific and remain unchanged for earlier releases. we use these scripts for security updates
[14:36] <hallyn> jdstrand: thanks, I'll ping them both then
[14:37] <hallyn> jdstrand: rharper: right, so the changes need to be put under checks for the lsb_release, as is done throughout that file (and in http://people.canonical.com/~serge/qrt-qemu.diff)
[14:37] <hallyn> biab
[14:38] <doko> dholbach, you sponsored Jackson Doak's libstatgrab upload which ftbfs everywhere
[14:38] <dholbach> doko, I pinged him about it
[14:38] <dholbach> doko, I tested it locally
[14:39] <rharper> jdstrand:  what about tagging a release of the testsuite prior to the fixes?  it does seem odd to skip tests altogether on releases that can run the commands but the test case is just not written correctly
[14:46] <jdstrand> rharper: tagging doesn't work with the way the scripts are run-- plus it would be hard to get new tests. if the test is wrong, can it be fixed to work on all releases?
[14:46] <rharper> jdstrand: yes -- that's my next step
[14:46] <rharper> I need to re-run the updated suite on the previous releases
[14:47] <rharper> there are a few older release (like older than say 10.x ) that probably don't have monitor commands to do the new hotplug
[14:47] <rharper> but otherwise, it should run on all releases
[14:47] <rharper> a few changes need the special casing since the monitor output changed between releases
[14:47] <rharper> so, let me re-work the patch and provide results  on passing; how far back do I need to run ?
[14:47] <rharper> release-wise
[14:48] <jdstrand> rharper: it is fine to remove tests/etc for EOL releases. however, qemu still gets support on 10.04, so it needs to work there
[14:48] <rharper> ok, so 10.04 up to current ?
[14:48] <rharper> or just the LTSes between 10.04 and now ?
[14:48] <jdstrand> rharper: 10.04, 12.04, 12.10, 13.04, 13.10 and 14.04 are the current supported releases
[14:48] <rharper> ok
[14:48] <rharper> perfect
[14:49] <jdstrand> rharper: thanks! :)
[14:49] <rharper> np
[14:58] <knocte> ubuntu's default bluetooth manager is an app that depends on gtk2?
[15:02] <pitti> dholbach: ok, that looks better: http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html
[15:02] <pitti> @pilot out
[15:02] <dholbach> pitti, you're a hero!
[15:03] <teward> pitti: thanks for sponsoring the wireshark ftbfs fix :)  purely curious, though, why are we ahead of Debian with Gtk 3.10+?
[15:04] <pitti> teward: let's rather say Debian is behind a lot; first there was the wheezy release, and now I'm not sure what's blocking the update in Debian
[15:05] <teward> pitti: heh
[15:05] <teward> pitti: well, at least one of the FTBFS caused by Ubuntu having gtk 3.10+ is fixed, thanks again.
[15:36] <mlankhorst> weird, how did libqt5gui5 get promoted to main while libxcb-sync1 is still only in -proposed?
[15:41] <infinity> mlankhorst: s/main/release/ ... Very confusing to use the wrong terminology.
[15:41] <mlankhorst> oops
[15:41] <infinity> mlankhorst: And the answer is simple, your rebuild was against libxcb-sync0.. Check a build log.
[15:41] <mlankhorst> hm
[15:41] <infinity> libxcb-sync0-dev is in build-deps.
[15:41] <mlankhorst> that shouldn't have happened..
[15:41] <mlankhorst> ah right
[15:42] <mlankhorst> it can still be explicitly installed
[15:42] <mlankhorst> and provides ends up as noop
[15:43] <mlankhorst> the new package provides libxcb-sync0-dev, so it pulled it in on my local build
[15:44] <infinity> mlankhorst: Ew, really?  foo1-dev doesn't provide foo0-dev in any sane meaning of the word.
[15:44] <zyga> I'm getting WIFSTOPPED on waitid for a child that failed to exeve(), I'm trying to understand why but all my searches turn out negative
[15:45] <mlankhorst> infinity: some symbols were removed and that was a reason for a soname bump
[15:45] <infinity> mlankhorst: Does someone really think this is a good thing to do?  Will foo2-dev provide foo1-dev and foo0-dev just to avoid fixing build-deps?
[15:45] <infinity> mlankhorst: No, no.  The SONAME bump is good, I'm not saying it's not.  I'm saying the provides is bogus.
[15:45] <zyga> does anyone know why waitid() returns such a value? the code after execve() just called _exit() with a status code I can see
[15:45] <zyga> (see in si_status)
[15:45] <mlankhorst> wasn't me who did it, no idea why it was done..
[15:45] <infinity> mlankhorst: If there's never any intent to offer multiple versions of that dev package, it should be "libxcb-sync-dev", and fix all the build-deps once, so future no-change rebuilds work right.
[15:45] <mitya57> mlankhorst: try http://anonscm.debian.org/gitweb/?p=pkg-kde/qt/qtbase.git;a=commitdiff;h=374b4205a374d4070e95b144fce03391789702bb
[15:46] <mlankhorst> yeah
[15:46] <infinity> Ahh, and indeed, that's what they've done going forward.
[15:46] <infinity> So, yeah.  Fix the build-deps. :P
[15:47] <infinity> (base)adconrad@cthulhu:~$ reverse-depends -b libxcb-sync0-dev
[15:47] <infinity> Reverse-Build-Depends
[15:47] <infinity> [15:47] <infinity> * kde-workspace
[15:47] <infinity> * libkscreen
[15:47] <infinity> * qtbase-opensource-src
[15:48] <mlankhorst> hm libkscreen build-depends on it? didn't show up in reverse-depends libxcb-sync0
[15:48] <infinity> Looks like render0, shape0, shm0, xfixes0 (and who knows how many others) will have this same issue soon.
[15:48] <infinity> mlankhorst: It build-depends on it.  Could be spurious if it doesn't actually link against it.  But it should still be looked at and fixed.
[15:51] <mlankhorst> well from the source I guess it looks if it exists, nothing seems to use it :P
[15:52] <infinity> mlankhorst: Well, the proper fix would probably be submitting a patch to upstream to stop doing that, but the path of least resistance is certainly just fixing the build-dep to be unversioned and handwaving. :P
[15:53] <mlankhorst> yeah
[15:56] <mlankhorst> well, should be fixed in https://mblankhorst.nl/etc/sponsor.tar
[16:00] <TJ-> Why are the packaging branches for upstart out-of-sync with what is in the archives? The changelogs don't even show the released version yet contain UNRELEASED versions later than the released version. (checked both ubuntu/trusty/upstart and ubuntu/upstart)
[16:03] <mitya57> TJ-: check package-import.ubuntu.com
[16:04] <mitya57> TJ-: also, I believe upstart packaging is maintained in some other place
[16:05] <TJ-> mitya57: *sigh* well, the branches I pulled have changes dated 8th January... sure is confusing. Package import failed due to VersionNotPresent... but the source path shows natty ... makes no sense to me!
[16:06] <mitya57> Hum, no, only Debian package uses Vcs, it is quite different from Ubuntu
[16:07] <TJ-> mitya57: I'm on about bzr branch lp:ubuntu/trusty/upstart etc.
[16:07] <mitya57> TJ-: Right, that is broken. It's not easy to fix it, try something different (like filing bugs with debdiffs)
[16:08] <mitya57> If the changelogs contain UNRELEASED, that probably means someone broke it
[16:08] <TJ-> mitya57: Yeah... very much so. I've just pulled upstream and it has no debian/ directory at all!
[16:09] <TJ-> mitya57: I was hoping to work on tracking down a kernel panic killing init when doing "dpkg --configure -a"
[16:09] <mitya57> TJ-: hm, no, contents of lp:ubuntu/upstart look up-to-date
[16:10] <cyphermox> knocte: no, gnome-bluetooth depends on gtk3
[16:10] <mitya57> TJ-: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/upstart/trusty/view/head:/debian/changelog
[16:11] <jodh> mitya57, TJ-: UNRELEASED as there are pending fixes in the bzr branch not yet in the archive version. However, it does look like one of the recent changes to changelog has pasted in some extraneous (old) entries.
[16:12] <TJ-> jodh: good catch... I didn't go too far into the changelog once I say a 1.10-??? entry
[16:13] <TJ-> jodh: my sanity is restored... thanks :)
[16:13] <mitya57> I still need some advice for bug 1269203. The package tries to overwrite files in libqt4-dbus:[ARCH]. I added Breaks/Replaces on libqt4-dbus (<< ...), but that looks not enough. Do I need a B/R on libqt4-dbus:any instead?
[16:18] <TJ-> Reported. bug #1269487
[16:26] <jodh> TJ-: thanks
[16:29] <infinity> mitya57: That should work as-is...
[16:31] <mitya57> infinity: Right, but it doesn't. I thought my ubuntu3 upload would fix that, but that bug says it has ubuntu3 installed
[16:37] <infinity> mitya57: Not arguing that the log doesn't show what it does, just that it makes no sense, cause it shouldn't. :/
[16:38] <infinity> mitya57: Might have to do some local testing and see if I can reproduce it at all...
[16:40] <mitya57> infinity: that would be nice, I ran out of ideas
[16:41] <mitya57> bug 1269297 is similar, but that is i386 package on amd64 system
[16:45] <infinity> mitya57: Weeeird.  So, on the first bug, the actual logfile shows -2ubuntu1, not -2ubuntu3...
[16:45] <infinity> mitya57: And the second bug shows -2ubuntu2
[16:45] <happyaron> pitti: thanks, it's already on my list, :)
[16:45] <mitya57> infinity: Interesting
[16:45] <infinity> mitya57: So, maybe apport's doing something very silly here.
[16:46] <infinity> mitya57: If you check the DpkgTerminalLog for each, neither one is using your latest.
[16:46] <mitya57> pitti: ^ any ideas? apport is putting wrong package version into the bug report
[16:47] <infinity> mitya57: So, if you can't reproduce this with -2ubuntu3 (and I don't see why you could), I'd just close both (and any dupes) with "fixed in -2ubuntu3".
[16:48] <mitya57> I will mark them as dupes when/if pitti looks
[16:48] <mitya57> infinity: thanks for finding the issue, btw!
[17:00] <pitti> infinity, mitya57: well, this would be the version you upgrade *from*, not *to*, right?
[17:02] <infinity> pitti: Check the bug. U-Boot 2013.04-mustang_sw_1.08.12-beta_rc (Oct 18 2013 - 15:19:00)
[17:02] <infinity> Er,
[17:02] <infinity> pitti: https://launchpad.net/bugs/1269203
[17:02] <infinity> pitti: The bug title and metadata claims the bug is in 4:4.8.5+git192-g085f851+dfsg-2ubuntu3, but the Dpkg Log clearly shows it's -2ubuntu1
[17:03] <infinity> pitti: Is apport doing some lpapi thing to get the version or some such?  It's obviouly not reporting on the version that was actually attempting install.
[17:03] <mitya57> Right, "Unpacking libqtdbus4:amd64 (from .../libqtdbus4_4%3a4.8.5+git192-g085f851+dfsg-2ubuntu1_amd64.deb)"
[17:03] <mitya57> That doesn't sound like "from"
[17:04] <infinity> Speaking of... If apport does manual parsing of the dpkg output, it's going to get even more confused after the next merge. :/
[17:04] <infinity> guillem changed that output.
[17:04] <pitti> infinity: apt calls /usr/share/apport/package_hook with an explicit --package (but without the version) when the actual problem happens; and then, when you report it, apport collects the remaining info, including the package version
[17:05] <pitti> infinity: so I suppose what happened is this:
[17:05] <pitti> - dist-upgrade
[17:05] <pitti> - failed to unpack -2ubuntu1, created an apport report
[17:05] <pitti> - the user further upgraded to -2ubuntu3
[17:05] <infinity> Or apt-get updated.
[17:05] <pitti> - only *then* the user filed that apport report
[17:05] <infinity> If it's using apt-cache, you wouldn't need to actually upgrade, just update.
[17:05] <infinity> So, there'd be a race there with the apt cronjob, even without human interaction.
[17:06] <pitti> i. e. we should capture the affected package version right away in this case, not just during data collection in the UI
[17:06] <doko> infinity, dpkg merge ping (to keep pitti busy)
[17:06] <infinity> Heh.
[17:07] <pitti> infinity: no, it's using python-apt with the "installed" paackage version, so it's not due to apt-get update (indexes don't matter)
[17:08] <mitya57> Shouldn't the version number be inserted when report is generated, not when it's filed?
[17:08] <pitti> ideally yes
[17:20] <TJ-> infinity: can I ping you about bug #1269405  ... might be an emerging issue since the upload yesterday
[17:32] <cjwatson> TJ-: if "telinit u" is causing a reboot then that's more a jodh thing
[17:32] <cjwatson> libc is just one of a number of packages that uses it
[17:34] <infinity> Indeed, not a glibc issue, and just confirmed that a glibc upgrade here works fine.
[17:38] <TJ-> cjwatson: infinity: thanks... will dig deeper
[17:39] <jodh> cjwatson: yes, but what's weird is that it's just started happening seemingly and upstart hasn't changed in a couple of months now.
[17:41] <cjwatson> nor has dbus
[17:41] <TJ-> There are some invasive changes to recent glibc uploads... I've got an affected user who has reverted to glibc  2.18-0ubuntu2 and it still shows up; he is going to try older kernels later today.
[17:41] <cjwatson> that would suggest that the invasive changes aren't relevant, then :)
[17:43] <infinity> TJ-: Which "invasive changes" are those?
[17:44] <infinity> TJ-: (Hint, between ubuntu2 and ubuntu5, there's exactly one patch that affects amd64)
[17:45] <TJ-> cjwatson: infinity: the debian experimental merge. So ...ubuntu2 showing the issue suggests the bug has either been latent, or a change elsewhere (linux maybe) is triggering it
[17:46] <cjwatson> or the other possibility, that it has nothing to do with eglibc at all
[17:46] <infinity> TJ-: Or it's, perhaps, an upstart job that's common to those systems and confusing upstart.
[17:46] <TJ-> infinity: Yes, I saw that... I've been working through trying to narrow down the possibilities ... I'll wait for the user to report back on older kernels
[17:50] <Laney> I've had that a few times actually
[17:51] <Laney> I was suspecting flaky hardware but now that I think about it some of the times were during dist-upgrades
[17:51]  * Laney loves being concrete
[18:01] <jodh> Laney: if you can you recreate the issue, please add details to the bug. Also, any sign of /var/log/upstart/upstart.state on your system?
[18:02] <Laney> jodh: no, and I will do now that I have an alternate suspect
[18:02] <Laney> It's happened several times so I'm confident we'll see it again
[18:39] <barry> @pilot in
[18:45] <seb128> xnox, hey, is there anything blocking bug #967229 to get uploaded to trusty?
[18:47] <slangasek> probably the main blocker is that it touches both lightdm and plymouth, and needs to be vetted for versioned deps/breaks and to make sure other DMs (or DM-less server systems) don't break as a side effect
[18:49] <seb128> slangasek, would it help if some of us test those changes?
[18:50] <slangasek> seb128: I can't say; I looked briefly at the diff to see if it was something I could push through quickly, saw the extent of the changes and backed away.  I think we should wait for xnox to follow through
[18:51] <seb128> ok, wfm
[18:51] <seb128> I pinged mostly because I saw ara's comment and it looks like something we should try to land early in the cycle rather than late
[18:51] <seb128> it can wait on xnox to be back for sure though ;-)
[18:51] <seb128> slangasek, thanks!
[18:51] <slangasek> n/p
[19:20] <mitya57> doko: Can you please submit your Qt4 arm64 patch upstream? It would be nice to have it included in 4.8.6 so that we can reduce the number of Ubuntu-specific patches.
[19:22] <doko> mitya57, it's not mine, it's the one from Fedora, and then fixed to work
[19:30] <mitya57> doko: Hm, OK, the author is hrw?
[19:30] <doko> I think so
[19:33] <barry> jtaylor: i'm guessing that https://code.launchpad.net/~jtaylor/ubuntu/trusty/python-numpy/new-upstream/+merge/200473 is the one you wanted me to review, right?  the mp is against the wrong branch, so the diff is, um, unusable ;)
[19:34] <jtaylor> barry: I think its right
[19:35] <barry> jtaylor: oh, yes, you're right it's against the right branch.  the diff is still useless ;)  btw, debian experimental has 1:1.8.0-1.  have you tried that to see if it fixes the issues?  should we just sync from exp?
[19:36] <jtaylor> we can't
[19:36] <jtaylor> no matplotlib in main
[19:36] <jtaylor> this one should go in first: https://code.launchpad.net/~jtaylor/ubuntu/trusty/cython/numpy-fix/+merge/201837
[19:36] <jtaylor> though technically no, as its jsut a test fix
[19:37] <barry> jtaylor: well, merge (sync + delta)
[19:37] <jtaylor> barry: might as well use the branch then, it contains more bugfixes
[19:37] <jtaylor> its based on the stable branch of numpy
[19:38] <barry> jtaylor: okay, that's what i was wondering - sounds like all the needed fixes are not yet in the debian branch
[19:38] <jtaylor> we might be able to replace it with 1.8.1 before trusty release
[19:38] <jtaylor> they will go into debian on unstable upload
[19:39] <jtaylor> barry: added a small addition to cython merge
[19:39] <barry> jtaylor: okay, let me look at the cython one first
[19:40] <jtaylor> that too will get synced over by 0.20 later
[19:47] <mitya57> wgrant: I see you also have authored some Qt4 patches (aarch64_fix_atomic_set.patch & aarch64_fix_jsc.patch). Did you forward them upstream?
[19:55] <jtaylor> barry: mind if I bump the upstream commit of numpy? just allows dropping two patches
[19:55] <jtaylor> memoryview*patch
[20:27] <bdrung> YokoZar: yes. that fits into u-d-t
[21:21] <jtaylor> barry: my cython test build finally succeeded :)
[21:22] <barry> jtaylor: \o/  i got distracted.  i'll look at your cython branch now
[21:22] <jtaylor> barry: I'll push a new numpy if you didn't already look at it
[21:23] <barry> jtaylor: please do, thanks
[21:25] <Fudge> are unity keybinds like shift super 1 supposed to still spawn another instance of Nautilus? Or is this intentionally not the case any longer.
[21:27] <stokachu> barry: have you run into issues where you package a python3 only version but dh still tries to run pyversions?
[21:27] <jtaylor> stokachu: have you disabled pysupport?
[21:27] <jtaylor> its run by default (or is this off now?)
[21:28] <barry> stokachu: py3-only?  no.
[21:28] <stokachu> hmm
[21:28] <jtaylor> I think newer compats should turn it off
[21:28] <barry> jtaylor: i think so too
[21:28] <stokachu> i dont have anything using python2 but it still tries to copy files to the 2.7 build directories
[21:28] <jtaylor> which compat?
[21:28] <stokachu> 9
[21:28] <barry> stokachu: branch or package?
[21:28] <barry> stokachu: which branch or package?
[21:29] <stokachu> barry: its private but i can paste the debian files
[21:29] <barry> stokachu: d/rules and d/control to start with
[21:29] <stokachu> ok one sec
[21:29] <jtaylor> a buildlog would be interesting
[21:30] <stokachu> barry: http://paste.ubuntu.com/6758565/
[21:30] <barry> jtaylor: yep
[21:30] <stokachu> and the build log i have http://paste.ubuntu.com/6758566/
[21:31] <stokachu> one sec i have another log of the actual debuild
[21:32] <jtaylor> hm I think I saw this before
[21:32] <stokachu> http://paste.ubuntu.com/6758574/
[21:32] <stokachu> this show where it copies stuff over to xxxx2.7
[21:32] <stokachu> like line 5
[21:32] <stokachu> 52
[21:33] <jtaylor> yes you have to disable python2 explicitly
[21:33] <jtaylor> basically vice versa of what you have to do for python3
[21:33] <stokachu> like a Conflict?
[21:33] <jtaylor> no override dh_auto_build
[21:33] <jtaylor> and all others
[21:34] <stokachu> that makes me sad
[21:34] <jtaylor> you could use pybuild, it should be able to deal with py3 only
[21:34] <stokachu> ah ive never used pybuild ill need to read up on it
[21:34] <barry> +1 for pybuild
[21:34] <barry> stokachu: https://wiki.debian.org/Python/LibraryStyleGuide
[21:34] <barry> stokachu: i just looked at system-image's packaging (it's py3 only)
[21:35] <barry> override_dh_auto_build: $(PYTHON3:%=build-python%)
[21:35] <barry> PYTHON3=$(shell py3versions -dvr)
[21:35] <barry> but i haven't switched it over to pybuild yet
[21:35] <stokachu> so should i use this way or pybuild?
[21:35] <jtaylor> yes just regular py3 packaging overriding everything, with the twist of disabling the provided ones instead of running them for py2
[21:35] <jtaylor> pybuild will be cleaner
[21:35] <jtaylor> depends on your backpoprt requirements
[21:35] <barry> jtaylor: agreed!
[21:36] <stokachu> so for backports i could switch it out to distutils?
[21:36] <stokachu> if using pybuild
[21:36] <jtaylor> with switchout = rewrite yes
[21:36] <jtaylor> pybuild and old python packaging are quire different
[21:36] <jtaylor> from the rules style
[21:36] <barry> isn't pybuild available in (some) backports?
[21:36] <stokachu> ok
[21:37] <jtaylor> its not yet in anything older than saucy
[21:37] <jtaylor> and saucy has a buggy version
[21:37] <jtaylor> for binary extensions at elast
[21:37] <jtaylor> and you have the backports depending on backports issue if thats not fixed yet
[21:38] <barry> blarg
[21:38] <stokachu> thanks guys going to try with pybuild
[21:38] <jtaylor> pybuild also gives you pypy support
[21:39] <stokachu> interesting, that may be beneficial for my other package
[21:39] <jtaylor> pybuild with binary extensions debug and pypy: http://anonscm.debian.org/viewvc/python-modules/packages/pyzmq/trunk/debian/rules?revision=27065&view=markup
[21:39] <stokachu> it supports py2, py3
[21:39] <jtaylor> relatively simple % the pyzmq specifics
[21:39] <barry> you might be able to get away with just PYBUILD_NAME
[21:39] <barry> instead of all those DESTDIRs
[21:40] <jtaylor> might be that its already a little outdated
[21:43] <barry> stokachu, jtaylor here's what i use for flufl.i18n (py2 and py3, but still)
[21:43] <barry> https://alioth.debian.org/scm/viewvc.php/packages/flufl.i18n/trunk/debian/rules?view=markup&revision=26544&root=python-modules
[21:44] <barry> jtaylor: for the cython patch, is there an upstream tracker issue open for this?
[21:44] <jtaylor> it just adds python-..NAME packages I guess?
[21:44] <stokachu> nice im testing my build now with pybuild
[21:44] <jtaylor> barry: a mailing list post, its in the 0.20.x branch
[21:44] <jtaylor> I thin k I forgot the commit id
[21:45] <jtaylor> but its going to be obsoleted by sync soon anyway
[21:45] <barry> jtaylor: so no Bug: header for the quilt patch
[21:45] <jtaylor> I can add the id if you haven'T started a build yet
[21:45] <barry> jtaylor: i haven't, go for it
[21:45] <jtaylor> k
[21:47] <TJ-> Anyone know of an issue when installing on UEFI whereby the boot menu option isn't added? I've tracked the failure down to "Can't access efivars filesystem at /sys/firmware/efi/efivars, aborting" when installing 'secureboot-db' even though the live installer booted in, and recognised, UEFI mode.
[21:48] <jtaylor> barry: added
[21:49] <barry> jtaylor: thanks.  i'll test build and upload if it looks good
[21:49] <jtaylor> don't bother if you don't have at least 2 hours time
[21:49] <barry> jtaylor: wow, really?  last time i built cython it took a while but not *that* long
[21:49] <jtaylor> we have an extra cython
[21:49] <jtaylor> python
[21:50] <jtaylor> maybe your machine is also faster :)
[21:50] <barry> jtaylor: the patch looks fine to me.  if i just sponsor it for you, will you watch for ftbfs?
[21:50] <jtaylor> barry: yes I'll get the 0.20 sync
[21:51] <jtaylor> cython is broken with python3.4
[21:51] <jtaylor> currently its just ignored
[21:51] <barry> jtaylor: sounds good.  if the build looks like it's going to take 2h, i'll kill it and just sponsor
[21:51] <stokachu> yay successful!
[21:51] <barry> stokachu: \o/
[21:52]  * barry is rather curious to see if his machine *is* faster :)
[21:52] <jtaylor> it was quite a bit longer than 2 hours on mine let me check how long exactly
[21:53] <jtaylor> about 3hour 15 minutes, but I was building scipy on the machine in the meantime too
[21:54] <barry> ouch.  okay, let see how far it gets while i make some tea :)
[21:55] <jtaylor> good that we don't ahve 4 pythons anymore :)
[21:55] <jtaylor> = 8 builds with debug
[21:55] <jtaylor> but in return we have pypy :/
[22:03] <stokachu> so with pybuild do i have to do anything special to have my package built as a private module?
[22:03] <stokachu> https://github.com/sosreport/sosreport/blob/master/debian/rules
[22:03] <stokachu> previously that is what i was doing to make that happen
[22:08] <jtaylor> probably --install-args or --install-dir
[22:09] <jtaylor> the former should allow you to do the same thing as your old rules
[22:09] <stokachu> ok
[22:09] <jtaylor> but don't know for sure, never tried it for private
[22:18] <stokachu> yea looks like setting PYBUILD_INSTALL_DIR will do it
[22:26] <barry> jtaylor: it's still running, so i'm going to push the cython branch
[22:27] <jtaylor> barry: should be fine, and its not a runtime dependency
[22:27] <jtaylor> so it shouldn't even lock stuff in proposed if it fails
[22:27] <barry> yep.  okay, so back to numpy
[22:28] <jtaylor> thx :)
[22:29] <jtaylor> I convinced the debian maintainer to accept the ubuntu diff (dh_python2 etc)
[22:29] <jtaylor> so its easier to manage
[22:29] <jtaylor> basically just the matplotlib patch and build depend
[22:29] <jtaylor> and ppcel64
[22:30] <jtaylor> (compared to debian svn)
[22:30] <barry> great!
[22:32] <barry> jtaylor: hmm, i'm getting merge conflicts for lp:~jtaylor/ubuntu/trusty/python-numpy/new-upstream against ubuntu:python-numpy
[22:37] <jtaylor> barry: no idea about that, I never merge in udd, just bzr-buildpackage and cowbuilder
[22:38] <jtaylor> whats the checksum of the orig you got?
[22:38] <jtaylor> might be due to quilt files? I never figured out how to deal with those inb zr
[22:38] <jtaylor> I think they are not applied
[22:38] <jtaylor> (how I like it)
[22:38] <barry> jtaylor: probably yeah.  quilt is always tricky
[22:39] <barry> jtaylor: i can't bzr bd when there are conflicts, so i'll just have to try your branch
[22:40] <barry> jtaylor: the conflicts don't happen in debian/ so i can still review that
[22:48] <barry> jtaylor: i think instead of adding a return to the top of test_basic2() in test_ctypeslib.py, it would be better to add a skip, something like:
[22:48] <barry> @dec.skip('Skipped as per debian/patches/python3-soabi.patch')
[22:48] <udevbot> Error: "dec.skip('Skipped" is not a valid command.
[22:49] <jtaylor> the effect is the same
[22:49] <jtaylor> I don't really like the patch
[22:50] <barry> jtaylor: yes, but better documented and less mysterious when looking at the file
[22:50] <barry> me neither, but i can't think of anything better
[22:53] <jtaylor> should I add the skip? I don#t think anyone will look at it
[22:53] <jtaylor> the file not the patch
[22:54] <jtaylor> the patch has a description
[22:55] <barry> jtaylor: i've done it here
[22:55] <jtaylor> k thx
[23:22] <RAOF> infinity: The colord autopkgtest failure is infuriating. It fails *only* on our Jenkins hardware as far as I can tell, not anywhere else.
[23:25] <jtaylor> welcome to the club
[23:25] <jtaylor> skimage the same
[23:27] <jtaylor> (the pre py3.4 failure)
[23:33] <barry> jtaylor: cython build finished:
[23:33] <barry> Build needed 01:29:26, 381920k disc space
[23:35] <jtaylor> your machine is a lot faster than mine :)
[23:36] <barry> :)
[23:46] <barry> jtaylor: numpy uploaded
[23:46] <jtaylor> great thanks :D
[23:47] <jtaylor> now I can start getting the science stack in order :D
[23:49] <barry> jtaylor: good luck!
[23:49] <barry> @pilot out