[00:09] <slangasek> infinity: say, do you have any plans to merge newer dpkg for trusty?  It would be nice to have DPKG_MAINTSCRIPT_PACKAGE_REFCOUNT from 1.17.2 available for trusty
[00:10] <slangasek> (making multiarch maintscripts more robust)
[00:10] <infinity> slangasek: Yeahp.
[00:10] <slangasek> infinity: ok
[00:11] <infinity> I wonder if it'll break all of bdmurray's custom bug patterns.
[00:11] <infinity> Have you noticed that guillem changed the unpack output (for the better, but changed nonetheless).
[00:11] <slangasek> I didn't notice, no
[00:13] <infinity> Preparing to unpack .../dpkg-dev_1.17.6_all.deb ...
[00:13] <infinity> Unpacking dpkg-dev (1.17.6) over (1.17.5) ...
[00:13] <infinity> Preparing to unpack .../libdpkg-perl_1.17.6_all.deb ...
[00:13] <infinity> Unpacking libdpkg-perl (1.17.6) over (1.17.5) ...
[00:13] <infinity> Much prettier, but also much different.
[00:14] <infinity> Anyhow, I'll merge it tonight or tomorrow.  I suspect the only thing that parses that output is bdmurray's stuff, so we can sort out fixing that.
[00:15] <sarnold> oh that's much prettier :)
[00:19] <bdmurray> infinity: where does that appear?
[00:19] <infinity> bdmurray: dpkg stdout.  If you're using that for any pattern matching on bug signatures, your world is going to be a bit confused.
[00:20] <infinity> Compare to old-stype output:
[00:20] <infinity> Preparing to replace libc6-dev:amd64 2.18-0ubuntu2 (using .../libc6-dev_2.18-0ubuntu5_amd64.deb) ...
[00:20] <infinity> Unpacking replacement libc6-dev:amd64 ...
[00:21] <Logan_> Ooh, that is much nicer.
[02:35] <melodie> hi
[02:36] <melodie> is there someone on board at this time, who has knowledge related to the creation of custom versions, either with debootsrap, or mini iso, or whatever nice clean method can be used? (I know there is a wiki but not up to date with the latest changes, and not accurate enough for a first start)
[02:37] <melodie> I would like to meet with someone who could be a guide in the following days and weeks, act as a mentor for a new remix projet involving next Ubuntu version and Openbox :)
[02:38] <melodie> mainly for the first steps, for I never could remix from scratch, which I would be very eager to learn
[02:40] <Noskcaj> melodie, Couldn't you start with on of the custom cd makers, for the easiest way
[03:36] <melodie> hi again
 is there someone on board at this time, who has knowledge related to the creation of custom versions, either with debootsrap, or mini iso, or whatever nice clean method can be used? (I know there is a wiki but not up to date with the latest changes, and not accurate enough for a first start)
 I would like to meet with someone who could be a guide in the following days and weeks, act as a mentor for a new remix projet involving next Ubuntu version and Openbox :)
 mainly for the first steps, for I never could remix from scratch, which I would be very eager to learn
 melodie, Couldn't you start with on of the custom cd makers, for the easiest way
[03:37] <melodie> Noskcaj left and I missed him. I'll tell him next time: done that so far. would like to get to the higher stage. Here is the achievement so far: http://linuxvillage.org/en/2013/11/bento-ubuntu-remix-rc/
[03:41] <dobey> huh. the logo in the boot screen is not exactly what i would associate with the word "bento" :)
[03:55] <melodie> hi dobey yes, that might be right :)
[03:56] <melodie> however bento should not be associated directly, but rather like a second meaning: the distro where you can add or remove what you want to, from the recipe
[03:57] <melodie> I'll add that I didn't choose the name, it came from a member of the linuxvillage.org forum. now I'd like to learn the other method, from the groundup, because I would like to work on a new project someone started at Launchpad : very much like the one I am doing, but with a few extra ideas which I'm interested about (ToriOS)
[03:58] <melodie> and also if I had been able to start right away from the groundup I would have done that long before
[04:00] <dobey> i don't know anything about the imaging tools
[04:04] <melodie> dobey thanks for talking to me :)
[04:04] <melodie> what time is it in your country?
[04:04] <dobey> 2300
[04:04] <melodie> aha
[04:04] <melodie> are you in NY state?
[04:04] <dobey> no
[04:04] <melodie> or around?
[04:05] <dobey> i am in need-to-suspend state :)
[04:05] <melodie> aha I meant country :D
[04:05] <melodie> I'm in South France and it's super early here, 5:05
[04:07] <shadeslayer> anyone have a clue on http://pastebin.ubuntu.com/6760116/
[04:08] <shadeslayer> ah wait
[04:08]  * shadeslayer looks closely
[04:09] <melodie> shadeslayer from this line:
[04:09] <melodie> make[4]: *** No rule to make target `/usr/lib/libperl.so.5.18.1', needed by `perl/blib/arch/auto/KDECore4/KDECore4.so'.  Stop.
[04:09] <shadeslayer> melodie: right
[04:09] <melodie> I would say there is probably an error in the Makefile
[04:09] <shadeslayer> melodie: so libperl-dev probably should depend on perl-base
[04:09] <melodie> I say that, but I'm no dev
[04:10] <shadeslayer> hm, but perl-base is pulled in
[04:10] <melodie> if you don't get more help about it right on, you might try your guess
[04:10] <shadeslayer> yeah, I've added perl-base to the build-depends
[04:10] <shadeslayer> lets see
[04:10] <melodie> have you had a look at the versions of the packages involved? (libs, devel libs, mainly?)
[04:11] <shadeslayer> melodie: versions?
[04:11] <melodie> yes, if the versions used match the requirements provided upstream
[04:11] <melodie> for each package involved
[04:11] <melodie> (I saw you are working on Trusty, so this might be something to have a look at)
[04:12] <shadeslayer> CMake thinks everything is good
[04:12] <shadeslayer> yep, adding perl-base makes it build
[04:12] <melodie> I am not a dev. Does a dev have to trust CMake blindly? (I'm not a dev... so I don't know if yes or if no)
[04:13] <melodie> great!
[04:13] <shadeslayer> CMake isn't *usually* wrong
[04:13] <melodie> :)
[04:14] <melodie> if you solved it, I'm happy I could encourage you. Just remember, you did it all.
[04:14] <melodie> have you indeed solved it? that ended with a good build?
[04:17] <melodie> shadeslayer ?
[04:17] <shadeslayer> yes
[04:17] <melodie> :)
[04:17] <shadeslayer> though lintian says depending on perl-base without a version is bad
[04:17] <melodie> solved?
[04:18] <shadeslayer> so I'm thinking of depending on perl instead
[04:18] <melodie> you can try
[04:18] <melodie> then you see if that works
[04:19] <melodie> are you mainly someone who builds packages, or do you also write code?
[04:20] <melodie> I see something you said a few minutes ago:
 yeah, I've added perl-base to the build-depends
[04:20] <shadeslayer> I do both, though more of building packages
[04:21] <melodie> shadeslayer as far as I know, if libperl-dev pulls in perl-base then you should not have to add perl-base to the build depends
[04:21] <infinity> perl-base doesn't need to be in build-depends, it's Essential.
[04:21] <tarpman> perl-base in build-depends seems odd. it's already essential (and your paste shows it's installed before your build ever starts)
[04:21] <melodie> infinity :D
[04:21] <tarpman> ... hi infinity :D
[04:21] <shadeslayer> infinity: tarpman I know, but adding perl-base to depends fixes the build
[04:22] <melodie> this is odd
[04:22] <melodie> do the versions match?
[04:22] <infinity> shadeslayer: I'd assume your science is faulty here, then.
[04:23] <shadeslayer> possibly
[04:24] <shadeslayer> I am still unsure how to fix this in the PPA though :/
[04:26] <melodie> shadeslayer if no one can help you better right now, what about trying the product of your build in a real install in a Trusty environment, with the debug mode? Maybe you could find something?
[04:27] <infinity> shadeslayer: Well, for starters, why is the makefile looking for libperl.so.5.18.1 when you probably have libperl.so.5.18.2 installed?
[04:27] <infinity> -- Found PerlLibs: /usr/lib/libperl.so.5.18.2 (found version "5.18.2")
[04:27] <infinity> No rule to make target `/usr/lib/libperl.so.5.18.1'
[04:27] <infinity> That's pretty suspect.
[04:27] <hyperair> required by perl/blib/arch/auto/KDECore4/KDECore4.so
[04:27] <hyperair> perhaps perl/blib/arch/auto/KDECore4/KDECore4.so has a greater mtime
[04:28] <TJ-> shadeslayer: You need to add to the Makefile, "-Wno-undef" for "kdecore/src/CMakeFiles/kdecore4.dir/kdecore4handlers.o" at least
[04:28] <hyperair> i don't think you can edit the makefile directly with cmake
[04:28] <TJ-> shadeslayer: You may also need "-Wno-switch-default"
[04:29] <shadeslayer> sure, that probably gets rid of the warnings, but what about the real issue
[04:30] <hyperair> no wait i mixed up
[04:30] <hyperair> hmm
[04:30] <melodie> shadeslayer according to the answers 3 persons just gave you, what do you think about what infinity just told you about the versions of libperl?
[04:30] <melodie> hi Noskcaj :)
[04:31] <melodie> Noskcaj I read your answer a moment ago, my answer to yours is this one: http://linuxvillage.org/en/2013/11/bento-ubuntu-remix-rc/
[04:32] <shadeslayer> aha
[04:32] <shadeslayer> infinity: good catch
[04:32] <melodie> so now I'd like to learn deeper, and learn how to start from scratch
[04:32] <Noskcaj> hey melodie
[04:32] <melodie> :)
[04:32] <Noskcaj> ok. I can't really help you with that then
[04:33] <melodie> Noskcaj I knew it, however if you know anyone who could help me, or could help me find who can help me, that would be most welcome. I'm following these two projects, related to creating new versions:
[04:33] <Noskcaj> I think Unit might know. He's on the lubuntu channels and phill's channel
[04:33] <melodie> https://answers.launchpad.net/ubuntu/+source/debian-cd/+question/240037
[04:34] <melodie> and this one:
[04:34] <melodie> https://launchpad.net/~torios
[04:35] <melodie> Noskcaj strange that phillw didn't say about Unit at the question page
[04:35] <Noskcaj> just a guess, since he helps with making extra xubntu isos
[04:36] <melodie> ok
[04:36] <melodie> what are extra ubuntu isos?
[04:36] <melodie> xubuntu*
[04:36] <tarpman> melodie: have you looked at ubuntu-defaults-builder?
[04:36] <melodie> tarpman ? first time I hear about that
[04:37] <melodie> would you have a link?
[04:37] <tarpman> melodie: apt-get install ubuntu-defaults-builder; man ubuntu-defaults-image; man ubuntu-defaults-template
[04:38] <Noskcaj> melodie, Different temporary test ISOs. Unit193 is his full irc nick
[04:38] <melodie> tarpman I grab all this and keep it for further look. thank you very much.
[04:38] <melodie> Noskcaj I know I met him already. I'll keep that in mind
[04:38] <Noskcaj> ok
[04:38] <tarpman> melodie: http://packages.ubuntu.com/search?keywords=ubuntu-defaults lists some existing defaults packages in the archive that work with that tool
[04:39] <melodie> tarpman what do you think about the question asked by Fabrizio Balliano here? https://answers.launchpad.net/ubuntu/+source/debian-cd/+question/240037
[04:39]  * tarpman -> afk, sorry
[04:39] <melodie> oh ok
[04:39] <melodie> thanks :)
[04:40] <melodie> leaving now. Noskcaj have a nice day. ubuntu developers : Happy New Year 2014 to all! Thanks for all!
[04:40] <melodie> :)
[05:42] <pitti> Good morning
[05:47] <RAOF> pitti: Oh, I've found and fixed (pending upload) the lcms2 bug causing the colord autopkgtest failure.
[05:50] <pitti> RAOF: oooh, splendid! so there was indeed some miscalculation somewhere?
[05:51] <RAOF> pitti: Yeah, lcms2 (and, for that matter, colord) has a braindead API that stores a dotted version in a float.
[05:51] <pitti> haha
[05:51] <pitti> version 1.999999734?
[05:52] <RAOF> Indeed.
[05:52] <RAOF> And lcms2 wasn't rounding, it was floor()ing.
[05:52] <pitti> well, I mean, strings are *expensive*
[05:52] <pitti> RAOF: so it was a real bug after all
[05:52] <RAOF> The ICC format has a byte and two nibbles storing that value.
[05:53] <RAOF> I have no idea why lcms2 decided that a floating point value (which *can't actually store* the full range of valid versions!) was a good idea.
[05:53] <RAOF> ie: ICC version 4.10.2 is a valid ICC version. What are you going to store that in as a float?
[05:53] <RAOF> Gah!
[06:58] <RAOF> pitti: Now that the autopkgtests should be fixed, feel like testing it by uploading colord 1.0.6 from the tag in alioth git? :)
[07:11] <pitti> RAOF: sure
[07:13] <pitti> RAOF: sbuilding
[07:16] <pitti> RAOF: uploaded
[07:25] <pitti> "Jenkins Fixed - trusty-adt-colord 39"
[07:25] <pitti> RAOF, infinity: ^ \o/
[08:04] <dholbach> good morning
[08:25] <doko> pitti: do you take care about the libgweather transition?
[08:26] <pitti> doko: Noskcaj was going to, and seb128 wanted to do evolution
[09:05] <ara> Hello!
[09:05] <Leagnus> good day to everyone!
[09:05] <ara> Someone in the SRU team could approve these two uploads, please? https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=notify-osd
[09:06] <seb128> ara, hey ;-)
[09:06] <ara> seb128, :)
[09:07] <seb128> ara, we don't have much europeans doing SRU reviews nowadays I think, if you don't get a reply try again in the afternoon, or ping directly slangasek bdmurray infinity (just did for you;-)
[09:08] <ara> seb128, well, RAOF should be online still, i.e. ;-)
[09:08] <seb128> that's a good point!
[09:08] <RAOF> ara: Well, it's 8pm for RAOF, but I'll have a look at it :)
[09:08] <ara> RAOF, already 8pm! (wow)
[09:09] <seb128> RAOF, with that heat wave, isn't that the time when it start being cold enough that your brain can start working again? ;-)
[09:09] <ara> RAOF, thanks, if you are already EOD, don't worry, I will ping someone later when the Americas wake up
[09:09] <RAOF> seb128: Ah, today has been nicely mild; about 22C or thereabouts.
[09:10] <RAOF> Tomorrow will be hotter, though.
[09:10] <RAOF> Hobart's far enough south to be spared the frankly ridiculous 46C or whatever Adelaide has reached.
[09:10] <seb128> RAOF, oh, ok, you are not on the crazy spot of .au ;-) I was reading about the 43°C in Melbourn, tennis player are not really happy about it
[09:12] <Leagnus> 	i think Unity is nice
[09:12] <Leagnus> 	but file manager with panel in it
[09:12] <Leagnus> 	which reacts on LMK (left mouse key), MMK (middle ~) RMK (right ~) is sufficent if
[09:12] <Leagnus> 	there will be panels with info on it
[09:12] <Leagnus> 	or with run software buttons
[09:12] <Leagnus> 	that appear depending on context
[09:12] <Leagnus> 	or certain windows.
[09:12] <Leagnus> 	So special file manager plus special launch / info panels is sufficent environment for me.
[09:12] <Leagnus> 	But how to realize it?
[09:19] <ggvaberi> hello. can anyone recoment some link/tutorial, for prepare application tray icons correctly? I need to let my application to have correct reaction when user change icon-theme. for example from dark to light...
[09:33] <seb128> RAOF, thanks for approving the notify-osd SRUs!
[09:33] <seb128> ara, ^
[09:35] <ara> RAOF, thanks!!
[09:37] <doko> seb128, folks ftbfs ping
[09:37] <seb128> doko, what about it?
[09:37] <seb128> I've no idea about that package
[09:38] <doko> seb128, ftbfs, desktop package ... https://launchpad.net/ubuntu/+archive/test-rebuild-20140108/+build/5424633
[09:39] <seb128> k
[09:40] <doko> thanks
[09:40] <zyga> good morning :-)
[09:40] <doko> zyga!
[09:41] <zyga> doko: finally setup my stuff at home, I'll get that autopackagetest fixed today
[09:42] <doko> thanks!
[10:02] <doko> yolanda, fstat and qping ping
[10:02] <yolanda> hi doko
[10:02] <doko> ahh, no qstat and fping =)
[10:03] <doko> yolanda, could you re-add the recommends as suggests?
[10:05] <yolanda> doko, i was told to remove them, because they were already in the extra package
[10:05] <yolanda> isn't that ok?
[10:06] <doko> ahh, ok, maybe add  a comment
[10:07] <doko> in the bug report and the changelog
[10:08] <yolanda> doko, so i leave them in extra, and also add to main nagios-plugins in suggests?
[10:09] <doko> yolanda, yes, you could do that, or just say in the changelog, that you dropped these because they are already in extra
[10:09] <doko> s
[10:10] <yolanda> doko, ok, better second option
[10:10] <doko> so that dumb people like me do understand it too
[10:10] <yolanda> heh
[10:10] <yolanda> i'll resend a debdiff
[10:18] <fishor> hello devs, is it possible  to make ubuntu-installer automatically create ext4 with 64bit enable? This option is needed to eanable methadata checksum. In my work on repair and datarecovery i noticed relativly big amount of hdd with silent corruptions. So checksumming getting more and more important. With SSDs situation is not really better :/
[10:19] <fishor> it will be just great it methadata checksum would be enabled by default, but suddenly it is not "stable" or good tested.
[10:20] <fishor> first step in easy testing will be ext4 with 64bit support.
[10:25] <mapreri> I'm trying to understand why pinta is not auto-syncing with debian, even if the last version hit testing a month ago. Can someone check it?
[10:27] <zyga> mapreri: maybe it's in -proposed?
[10:27] <Laney> it is not
[10:27] <mapreri> nope
[10:27] <Laney> that *is* interesting
[10:27] <Laney> cjwatson: ^?
[10:32] <cjwatson> Laney,mapreri: investigating
[10:36] <cjwatson> argh, impeded by Debian apparently having just dropped Sources.bz2 in favour of Sources.xz (which isn't the cause of this problem, since auto-sync has been running happily in general)
[10:58] <mitya57> dholbach: Alles Gute zum Geburtstag!
[10:58] <pitti> ooh!
[10:58] <pitti> dholbach: alles Gute! *hug*
[10:59] <dholbach> thanks mitya57, thanks pitti!
[11:02] <ochosi> oh, congrats dholbach
[11:06] <doko> seb128, are you now test-building on i386 so that you don't see ftbfs on amd64? ;p
[11:07] <cjwatson> mapreri: (attacking with pdb)
[11:10] <cjwatson> mapreri: oh, I see, it's confused by the existence of https://launchpad.net/ubuntu/quantal/+source/pinta/1.4-1~ubuntu12.10
[11:11] <cjwatson> mapreri: I shall try to limit that check
[11:12] <seb128> doko, I'm using i386 yes
[11:13] <seb128> doko, I don't understand how stuff like incorrect linking don't show up there though, is the toolchain buggy on i386 and doesn't stop on those errors?
[11:13] <cjwatson> incorrect linking should show up on i386
[11:13] <cjwatson> usually does for me
[11:14] <Laney> oops, that's an illegal backport
[11:15] <ogra_> sue it !
[11:17] <seb128> cjwatson, doko, dunno why https://launchpad.net/ubuntu/+source/glade/3.16.1-0ubuntu1 builds on i386, there is no -lm in the build log ... anyway, fixing the bug
[11:17] <doko> thanks
[11:21] <cjwatson> seb128: maybe it has something to do with ceil being an ifunc on amd64.  *shrug* dunno
[11:25] <cjwatson> mapreri: OK, sorry about that, fixed (http://bazaar.launchpad.net/+branch/ubuntu-archive-tools/revision/807) - next auto-sync run in 5h35m or so will pull it in
[12:00] <pitti> jodh: oh dear, this test_conf_preload failed again on i386, but succeeded on amd64: https://jenkins.qa.ubuntu.com/job/trusty-adt-upstart/52/ARCH=amd64,label=adt/console
[12:00] <pitti> jodh: I'll retry; is that known-racy?
[12:02] <Laney> mmm, update-manager failed
[12:10] <mapreri> cjwatson: sorry, I was having launch. Good to know, thanks! :)
[12:11] <pitti> jodh: retry worked
[12:11] <pitti> Laney: fix uploaded
[12:13] <Laney> pitti: hm, you didn't need to add at-spi2-core to test-deps?
[12:13] <pitti> Laney: apparently not, why?
[12:13] <pitti> I guess it's transitively pulled in by u-m's dependencies?
[12:13] <Laney> oh I see
[12:13] <Laney> that's just a warning
[12:14] <pitti> Laney: it was just the new pep8 error
[12:14] <Laney> nod
[12:14] <Laney> I saw "** (nosetests3:11651): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files"
[12:17]  * zyga is seriously impressed by ubuntu phone image QA process, *that* is the way to go! :-)
[12:19] <ogra_> zyga, lots and lots to be improved, but we're getting there :)
[12:19] <zyga> ogra_: yeah but the *direction* is right
[12:19] <ogra_> yep
[12:35] <mdeslaur> pitti: thanks for fixing update-manager, mdeslaur--
[12:35] <Laney> haha, I like your change mdeslaur
[12:36] <Laney> did you ask design? :P
[12:36] <mdeslaur> Laney: it's based on mpt's design in that bug
[12:37] <Laney> oh, neat, I thought it was a deliberate thing
[12:54] <pitti> jibel: FYI, I usertagged autopkgtest issues in Debian: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=autopkgtest;users=autopkgtest-devel@lists.alioth.debian.org
[12:55] <pitti> jibel: ^ these are just the ones reported by me; I think you submitted a few as well, which mail address do you usualy use?
[12:55] <pitti> jibel: ah, http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=jean-baptiste.lallement@canonical.com
[12:56] <pitti> tagged those, too
[13:28] <mitya57> wgrant: Hi, can you please forward your arm64 support patches for qt4 upstream? We have *too* may local patches now, so it would be nice if we can reduce that via forwarding
[13:34] <wgrant> mitya57: Linaro and RH people are working on it upstream at present, AIUI.
[13:34] <wgrant> I saw some patches moving around a week ago.
[13:35] <mitya57> wgrant: Ah, good to know. Were they the original patch authors?
[13:35] <wgrant> My patches were just fixes to Linaro's.
[13:35] <wgrant> So yeah, it's mostly driven by Linaro people.
[13:35] <mitya57> Ok, thanks for the info
[13:36] <mitya57> (So far I have only seen patches for Qt 5 landed in 5.2, but Qt 4 is different)
[13:41] <pitti> cjwatson, xnox: has there already been some discussion about the perl 5.18.2 transition? (it's stuck in -proposed, makes a gazillion packages uninstallable, etc.); presumably it just requires the 63 rebuilds?
[13:42] <cjwatson> pitti: oh, I didn't notice it
[13:42] <cjwatson> pitti: I'll take care of it
[13:43] <pitti> I just noticed it as lintian's autopkgtest started failing (I have an "autopkgtest cleanup day" today)
[13:43] <pitti> cjwatson: ok; I'm happy to help out if you want
[13:43] <pitti> $ grep perlapi-5.18.1 /var/lib/apt/lists/*i386*_Packages | wc -l
[13:43] <pitti> 540
[13:43] <pitti> ouch, could be some more rebuilds
[13:43] <cjwatson> yeah, they're usually trivial though
[13:44] <pitti> yes, just a lot of them
[13:44] <cjwatson> I'll sort out a tracker first
[13:47] <cjwatson> pitti: it's nothing like that bad
[13:47] <cjwatson> pitti: perl-base still provides perlapi-5.18.1
[13:47] <cjwatson> pitti: it's just the stuff in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734650
[13:48] <cjwatson> (probably - I'll still set up a tracker to check for other Ubuntu-specific things)
[13:49] <pitti> ah, nice; that looks rather harmless indeed
[13:50] <pitti> and we already have libperl-apireference-perl and libmodule-corelist-perl (the two sourceful uploads)
[14:06] <cjwatson> pitti: http://people.canonical.com/~ubuntu-archive/transitions/perl5.18.2.html agrees; I've uploaded those four rebuilds
[14:07] <pitti> cjwatson: many thanks
[15:53] <barry> doko: can you try to give back python-fixtures in your test rebuild?
[15:54] <barry> doko: nm
[15:55] <doko> barry, should I? -configglue didn't migrate to trusty yet
[15:55] <barry> doko: i think both those need the b-d on python3-all.  just uploaded new ones of both.  i forgot to specify the right chroot in my local test build
[15:56] <barry> doko: so no worries, new uploads should fix both of those
[15:57] <doko> ok
[15:57] <dholbach> infinity, do you have any idea what might need to be done to fix 1265625? or what it looks like to you?
[15:58] <barry> doko: i suspect there are a bunch of failures related to b-d on python3 instead of python3-all
[16:00] <doko> barry, I think so. I think we should do the fixes like you did. if we cannot for some reason, we should upload the package to the ubuntu-toolchain-r/python3 ppa
[16:00] <barry> doko: agreed.  i am also filing bugs or fixing svn in debian
[16:01] <barry> doko: i've pinged upstream genshi - they're looking at it.  yay for ast changes in 3.4
[16:05] <infinity> dholbach: There's not really enough information there to even know what the bug is.
[16:05] <ogra_> infinity, come on, its his birthday
[16:05] <ogra_> pull out your crystal ball !
[16:07] <infinity> dholbach: It could certainly be 1248642 though, to which the solution is "stop using crap non-free drivers".
[16:09] <Snow-Man> pitti: around..?
[16:10] <pitti> hey Snow-Man
[16:10] <Snow-Man> pitti: Have you been following pgsql-hackers at all wrt the ALTER SYSTEM SET and conf.d stuff?
[16:10] <pitti> Snow-Man: no, I'm not on that list
[16:10] <Snow-Man> pitti: Well, it's kind of impactful wrt the packaging and whatnot.
[16:10] <Snow-Man> pitti: would love to get your feedback and thoughts on it..
[16:12] <Snow-Man> pitti: http://www.postgresql.org/message-id/52D6D914.8090207@agliodbs.com
[16:12] <Snow-Man> pitti: That's the start of the "small" thread about these things.
[16:12] <pitti> Snow-Man: thanks; queueing for reading
[16:12] <Snow-Man> k
[16:26] <dholbach> infinity, hrm, thanks
[16:37] <doko> slangasek, cjwatson: why are postings to ubuntu-devel moderated?
[16:37] <cjwatson> I assume you mean "for you", since they've been moderated in general for years
[16:37] <doko> yep
[16:37] <cjwatson> there may have been a regression in the thing that auto-whitelists all Ubuntu developers, since didrocks reported something similar
[16:38] <cjwatson> but I have no access to that.  please ask #is
[16:38] <doko> thanks
[16:40] <pitti> doko: looking into libgweather transition, BTW (some things already done, some things  blocked by upload ban of packages that affect phone)
[16:40] <doko> pitti, I thought that did end
[16:41] <pitti> there was another regression, so it was put up again
[16:41] <cjwatson> I'm looking into the libwebp transition
[16:43] <pitti> doko: so gnome-panel and gnome-clocks are done now, evolution-data-server blocked by phone ban, looking at evolution; that should be it
[16:44] <doko> pitti, evolution-data-server needs a fix, see bug #1266492
[16:44] <pitti> doko: right; e-d-s is on seb128's list
[16:57] <doko> barry, see my email to u-d-a, told that people should complain here on the channel about the 3.4 failures
[16:58] <barry> doko: cool, reading
[16:59] <barry> doko: looks good
[17:07] <pitti> doko: FTR, I prepared evolution, but it needs e-d-s, so will need to wait for the lifting of the phone upload freeze
[17:08] <pitti> seb128: ^ actually, we could upload them to -proposed and set a propagation blocker bug, so that stuff can build in -proposed without breaking the phone?
[17:08] <seb128> pitti, let's do that tomorrow morning if the block is still in place
[17:08] <pitti> *nod*
[17:09] <ogra_> block will still be in place for 5-6h before we even have test results
[17:16] <seb128> ogra_, well, tomorrow I might just decide to step over your block and get some work done :p
[17:16] <ogra_> seb128, tomorrow it should be fine ... i dont care btw, the only person you make really unhappy is didrocks q
[17:16] <ogra_> (well, and asac )
[17:17] <ogra_> (dont call it "my blocker" :P)
[17:17] <seb128> ogra_, you are included in the group that put that blocker in place :p
[17:17] <ogra_> i'm just sitting on the side nodding
[17:17] <seb128> but yeah, having that lifted tomorrow would be nice
[17:18] <seb128> let's see how things look in the morning
[17:18] <ogra_> yeah, the image is close to be done ...
[17:18] <ogra_> then its like 5h to get test results from the autotests
[17:19] <didrocks> we'll get dogfooding results first, I trust my popey more than the 500 AP tests ;)
[17:19] <seb128> ogra_, you need to feed more hamsters to the test setup or something
[17:19] <ogra_> seb128, the tests only take minutes
[17:19] <ogra_> seb128, publishing the results on the dashboard takes so long
[17:19] <popey> lol
[17:20] <didrocks> we should change ci.ubuntu.com with "popey approved" yes/no
[17:20] <didrocks> it's either 0 or 100%
[17:20] <didrocks> :)
[17:20] <pitti> barry: oh, you sponsored numpy?
[17:20] <pitti> barry: this breaks a few packages, like pandas
[17:20] <pitti> https://jenkins.qa.ubuntu.com/job/trusty-adt-pandas/22/ARCH=i386,label=adt/
[17:21] <pitti> barry: I followed up in the MP, seems Julian was aware of that
[17:22] <pitti> jibel: ^ seems numpy wasn't held back by the pandas breakage; I've run into that several times (known-broken packages got propagated), do we still actually hold back packages when they fail?
[17:22] <pitti> jibel: or did we disable that?
[17:42] <jibel> pitti, it is not disabled. The only run I found of pandas has been triggered by eglibc and there is not result at all for the tuple numpy/pandas
[17:45] <asac> seb128: man, there is no block. just check with us, work on a special approach while we are ain alert (like testing more etc.)
[17:46] <asac> no big deal really ... if you have an urgent landing, we will help landing it as much as we can
[17:46] <ogra_> asac, e-s-d drags in a good chunk of changes with its rdeps
[17:46] <asac> but just uploading without talking while your peers are fighting fires
[17:46] <asac> is just not nice
[17:46] <asac> talk, offer and receive help
[17:58] <bcurtiswx> mthaddon, howdy
[18:03] <barry> pitti, jtaylor: ack.  let me know if you need anything
[18:05] <pitti> jibel: FYI, I filed bug 1269886 for the bzr autopkgtest failure; looks like it started to fail since python 2.7.6-5
[18:05] <pitti> vila: seems you maintain bzr these days mostly? Is that something you can look into?
[18:05] <jtaylor> barry: what was to ack? scrolled of my backlog
[18:05] <pitti> jtaylor: updating python-numpy reverse dependencies that now fail with the new numpy
[18:05] <pitti> (like panda)
[18:05] <barry> jtaylor: that ^^ :)
[18:06] <jtaylor> yes thats known
[18:06] <jtaylor> will be fixed
[18:07] <jtaylor> pitti: just synced scipy, I'm expecting adt failure, but that will be fixed on the new upstream due maybe this weekend
[18:08] <pitti> jtaylor: thanks
[18:08] <vila> pitti: forget about that one, it's transient
[18:08] <pitti> vila: well, the history of https://jenkins.qa.ubuntu.com/job/trusty-adt-bzr/ doesn't look that transient
[18:08] <vila> pitti: damn
[18:09] <pitti> vila: https://jenkins.qa.ubuntu.com/job/saucy-adt-bzr/ too
[18:09] <pitti> vila: it is rather unlikely that it started to fail consistently on the exact same time when python2.7 was updated with some upstream changes
[18:09] <pitti> vila: I mean, it's rather likely
[18:11] <bcurtiswx> mthaddon, You can catch me in #ubuntu-us-dc most times.
[18:12] <zyga> pitti: out of curiosity, how do you read the actual failure from, say: https://jenkins.qa.ubuntu.com/job/saucy-adt-bzr/18/testReport/
[18:12] <vila> pitti: rhmm, can't reproduce locally >-/
[18:12] <zyga> pitti: (how do you know what really failed?)
[18:14] <pitti> zyga: seems the saucy logs are gone
[18:14] <zyga> ah
[18:14] <zyga> ok
[18:15]  * zyga wishes for lava-like test introspection from log files
[18:15] <bdmurray> hallyn: could you update bug 1244694 with SRU information?
[18:15] <pitti> zyga: usually it's https://jenkins.qa.ubuntu.com/job/trusty-adt-bzr/? -> choose build -> choose architecture -> console log
[18:15] <pitti> (or look at the individual test stdout/stderr file)
[18:15] <vila> pitti: and saucy succeed too so that would explain why I can't reproduce, I'm late upgrading to trusty :-/
[18:16] <pitti> vila: right; as I said in the bug this started with python2.7 2.7.6-5
[18:16] <vila> pitti: but that python version is not available for saucy right ?
[18:16] <vila> pitti: (trying to catch up)
[18:18] <vila> pitti: wait, even rmadison doesn't know about 2.7..6-5 where do you get that one ?
[18:18] <pitti> python2.7 | 2.7.6-5          | trusty           | source, amd64, arm64, armhf, i386, powerpc, ppc64el
[18:18] <pitti> vila: it's in trusty
[18:19] <infinity> And sid.
[18:19]  * vila blinks
[18:19] <vila> wow, why is there a difference between python and python2.7 ?
[18:19] <infinity> vila: python is a metapackage build from python-defaults, python2.7 is the real binary.
[18:19] <infinity> s/build/built/
[18:19] <vila> (given  python | 2.7.5-5ubuntu3   | trusty          | amd64, arm64, armhf, i386, powerpc, ppc64el that is)
[18:20] <vila> infinity: wow, thanks
[18:20] <vila> confusing though
[18:20] <infinity> A bit.  doko tries to keep the versions vaguely in sync to avoid too much confusion, but I guess he's a bit behind on the .5->.6 bump.
[18:21] <vila> infinity: ha ok
[18:21] <infinity> (And the version isn't actually meaningful, except for the confusion bit)
[18:21] <vila> infinity: right, poor me ;)
[18:23] <hallyn> adam_g: ^ you told me you would fill in SRU info for bug 1244694 ?
[18:25] <pitti> vila: should be reproducible in a chroot/schroot, I guess
[18:25] <pitti> anyway, need to leave for today, good night!
[18:26] <vila> pitti: right, according to qblame, is the same MP that introduced all the other transient failures.. will comment on the bug
[18:37] <adam_g> hallyn, i said i would test it once it was accepted to proposed :)
[18:37] <adam_g> hallyn, but ill fill in the SRU data if you'd like
[18:37] <hallyn> 22:43 < hallyn> that is, to -proposed, so awaiting a SRU justification from you :)
[18:37] <hallyn> 22:44 < adam_g> hallyn, cool.
[18:37] <hallyn> miscommunication then, sorry.  but yeah please do
[18:48] <adam_g> hallyn, bdmurray https://bugs.launchpad.net/nova/+bug/1244694 updated
[18:54] <hallyn> adam_g: thanks!
[19:02] <zyga> barry: any chance for signalfd/eventfd in python anytime soon?
[19:05] <barry> zyga: probably not.  there's this: https://pypi.python.org/pypi/python-signalfd but afaict nobody's proposed anything for python proper, and 3.4's in feature freeze.
[19:11] <zyga> barry: I saw that, I want python3 version :/
[19:11] <zyga> barry: I may just try and propsoe one for 3.4, it's very useful and I'd love to see it
[19:11] <zyga> barry: though I'm not sure how hard it would be to get into the core, since it would (probably) change how python does signals and that's across the board :/
[19:11] <barry> zyga: it's too late for 3.4.  i would highly suggest contributing to the pypi project (hosted on lp), get it all happy, and then propose it for 3.5
[19:11] <zyga> for 3.5 then
[19:45] <jodh> infinity: what do you make of #16 on https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1269731.
[19:47] <jodh> infinity: as you stated yesterday, I cannot see how the eglibc changes as documented could cause this.
[19:48] <infinity> jodh: Given that someone else said that downgrading to -0ubuntu2 didn't help, I'd blame bad science on the part of the other person.
[19:48] <jodh> infinity: has to be, unless it's gcc?
[19:49] <jodh> infinity: ...which seems also to have changed around this time.
[19:49] <infinity> jodh: Would be nice if any of us could reproduce it...
[19:50] <jodh> infinity: agreed :(
[19:51] <infinity> "I can't speak for him, but I can say that I have tried 2.18-0ubuntu5 and 2.18-0ubuntu2 and I get a KP with both of them with I run "sudo telinit u"."
[19:51] <seb128> so, "fun", ubuntu-wallpapers has a file with ' chars in the filename and those listed in the .install
[19:51] <seb128> that started failing in trusty in the test rebuild
[19:51] <infinity> So, that seems to rule out the 4->5 claims, and it's something far more subtle...
[19:51] <seb128> works if you use \'
[19:51] <seb128> is that a wanted debhelper change? a bug in ubuntu-wallpapers?
[19:52] <infinity> seb128: I'd say unquoted 's are asking for trouble...
[19:52] <seb128> infinity, right, they were working until recently though
[19:53] <seb128> should I just add some \ \ in the .install and declare that a fix? or is that something that should be investigated on the debhelper side to know if that's a wanted behaviour change?
[19:54] <infinity> seb128: Yeah, I'm not seeing an explicit mention of it in the changelog.
[19:54] <seb128> yeah, me neither
[19:54] <infinity> seb128: Maybe fallout from:
[19:54] <infinity>   * dh_install, dh_installdocs, dh_clean: Fix uses of find -exec
[19:54] <infinity>     which cause it to ignore exit status of the commands run.
[19:54] <infinity>     Closes: 719598
[19:54] <infinity> Maybe.
[19:58] <infinity> seb128: So, the find -exec call was replaced with find -print0 | xargs -0 -I ... {} ...
[20:01] <seb128> infinity, so probably unwanted side effect ... I wonder if there is any other package weird enough to use a ' in a filename listed in a .install, I'm unsure that's worth the effort of a bug report or that I care enough to even report it
[20:01] <seb128> infinity, wdyt?
[20:02] <infinity> seb128: Well, it's a behavioural regression.  If we can sort out a proper fix that DTRT in all the cases we can think of, I'm happy to file the bug with joeyh.
[20:03] <infinity> seb128: Otherwise, the dh_install manpage should mention that shell special chars need to be quotes in .install files, which it doesn't currently.
[20:03] <seb128> infinity, want to handle that? ;-)
[20:03] <infinity> And, indeed, the use of -print0 | xargs -0 usually implies that the called wanted to avoid the need for quoting.
[20:03] <infinity> But I suspect -I {} foils that.
[20:03] <infinity> s/called/caller/
[20:03] <slangasek> {} foils everything
[20:04] <infinity> slangasek: Opinions?
[20:05] <slangasek> infinity: attempting to formulate one now
[20:07] <slangasek> infinity: I got nothin'.  I do think it's a debhelper bug, though I don't see a good way to solve it using find+xargs
[20:09] <infinity> Hrm.
[20:09] <TJ-> jodh: have you examined the #1269731 traces in detail?
[20:09] <infinity> A quick reduced testcase of 'find . -type f -print0 | xargs -0 -I {} cp {} {}2' doesn't actually show it failing on files with ' in the name...
[20:10] <infinity> So, maybe my guess about the errant commit is wrong.
[20:11]  * infinity grabs ubuntu-wallpapers to see what it's doing.
[20:25] <infinity> Ever weirder, Gota_D'água_by_Eiti_Kimura.jpg copies just fine before THE_'OUT'_STANDING_by_ydristi.jpg fails.
[20:37] <miseria> "no estoy de acuerdo con la pena de muerte, al final las leyes sobrenaturales nos tienen condenados a morir" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
[20:45] <infinity> slangasek: Ugh, gets more interesting.  The working dh_install from saucy fails on trusty.
[20:45] <infinity> slangasek: So, time to go witch-hunting.
[20:59] <Logan_> mfisch: Around?
[20:59] <mfisch> Logan_: yep whats up
[21:01] <Logan_> mfisch: https://launchpad.net/ubuntu/+source/gwyddion/2.33-1ubuntu1 Do you know if the Unity global menu fix is still necessary in the latest upstream release of gwyddion?
[21:02] <Logan_> Because I either want to merge or sync. I most likely don't need the change I implemented in 2.33-1ubuntu2.
[21:03] <mfisch> Logan_: no I'm not sure, I probably left it in just to be on the safe side
[21:03] <mfisch> Logan_: what change did you make?
[21:03] <Logan_> I did an autoreconf to get new libtool macros for ppc64el, but they did a libtool update upstream.
[21:03] <Logan_> So do you want to merge with just that Unity patch?
[21:06] <mfisch> Logan_: I'm on a business trip so unlikely to update it anytime soon, can you do it?
[21:06] <Logan_> Sure!
[21:08] <seb128> doko, did you saw https://bugs.launchpad.net/ubuntu/+source/pycurl/+bug/1269532 ?
[21:10] <mfisch> Logan_: I've generally not asked the previous uploader of something unless they're the maintainer when I did previously nobody seemed to care
[21:11] <Logan_> Usually people prefer that you ask. I haven't done that a lot in the past, though...
[21:11] <Logan_> It's supposed to prevent duplicated work.
[21:22] <mfisch> Logan_: sure and thanks for taking it
[21:22] <mfisch> Logan_: you have blanket permission to merge or sync anything I did ;)
[21:27] <Logan_> Sweet. :)
[21:42] <barry> infinity: can you give back python-greenlet to doko's test rebuild?
[21:43] <infinity> barry: Done.
[21:43] <barry> thx
[22:02] <barry> infinity: i have another one for you: python-httpretty
[22:03] <infinity> barry: That one's dep-wait...
[22:03] <infinity> barry: Because it build-deps on python-sure, which is in universe.
[22:04] <barry> infinity: ah.  gotcha, thanks
[22:38] <hallyn> has anyone gotten usb-creator-gtk to work this year?
[22:40] <infinity> hallyn: I'm sure people cause it to run occasionally, and write things to USB keys.  I'm less convinced that the results are ever sensible.
[22:41] <hallyn> infinity: i'm just doing dd right now and will mangle some free space into the remainder by hand...  was wondering if there is a better way :)
[22:42] <infinity> hallyn: The better way would probably be to fix usb-creator.  It's something we really need to do before we ship 14.04 anyway, but so far no one's volunteered, and I don't think anyone's yet been voluntold. :P
[22:43] <infinity> slangasek: Was Foundations going to take ownership of that mess and try to render it slightly more sensible?  I vaguely recall comments to that effect.
[22:45] <hallyn> infinity: hm.  since it has the name "-gtk" at the end I've historically avoided lookin at it :)
[22:45] <hallyn> but as i do want to make a usb boot stick for traveling, maybe i should seehow fixable it is
[22:45] <hallyn> for a mere mortal
[22:48] <slangasek> infinity: I recall that xnox did some updates already to move it to udisks2 recently
[22:48] <slangasek> that's not the same as saying Foundations is taking ownership of the whole mess :P
[22:49] <infinity> slangasek: Perhaps that was wishful thinking on my part.
[22:50] <infinity> slangasek: We probably should put it through some testing and shake out some of the nastier bugs, though.  Usually, when people complain their USB sticks don't boot, we say "are you using usb-creator?  Yeah, don't do that, here's a dd command".
[22:50] <infinity> slangasek: Which seems suboptimal.
[22:50] <hallyn> infinity: ppl get that far?  it always refuses to allow me to hit 'install', only 'erase' button works, and that hangs
[22:51] <hallyn> i'll dig deeper though, hopefully tonight
[22:52] <infinity> Oh neat, guillem moved the setlocale() stuff to a common libdpkg function.  We get to patch one spot instead of 7 now.
[22:52] <infinity> \o/
[22:53] <hallyn> is that in usb-creator?
[22:54] <infinity> hallyn: No, dpkg. :P
[22:54] <hallyn> ah
[23:10] <shadeslayer> cjwatson: do you have a link handy to the page that lists the build status of KDE packages? ( the one accessible via Launchpad )
[23:10]  * shadeslayer has lost it :(
[23:23] <slangasek> infinity: I agree, we should test all these things; I just don't know if we're going to make any headway on that this cycle
[23:23] <slangasek> the plate is rather full, and balanced on a stick