[00:00] <hallyn_> infinity: extracting the arm64 ubuntu core image for saucy, i get /lib/ld-linux-aarch64.so.1: No such file or directory when i try to run something.  should that exist, or does that mean my interpreter is bogus?
[00:23] <infinity> hallyn_: It should and does exist...
[00:38] <brainwash> is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632598 a security related issue? is does affected ubuntu and the debian report is still open
[00:39] <brainwash> woops, "it does affect ubuntu", that's what I tried to type :)
[00:43] <hallyn_> infinity: huh.  it's not here in mine.
[00:44] <hallyn_> wait.  now it is.  wtf
[00:45] <hallyn_> a few sips of duvel must be what fixed it
[00:45] <hallyn_> now i have to move everything to a vm :)   FATAL: kernel too old
[01:07] <sarnold> cjwatson: brainwash asks ^^ about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632598 -- is there a reason why the grub.cfg is left world-readable? My inclination is to take the patch proposed by Francesco but perhaps forcing the mode regardless of password vs password_pbkdf2
[03:24] <rsalveti> slangasek: xnox: ogra_: the goal of the emulator is to simulate a real device, using the supported path we use
[03:25] <rsalveti> as we want it to be the main "hardware" to support our CI
[03:25] <rsalveti> so we want to make sure it's as close as possible with our supported solution
[03:25] <rsalveti> but it also works with the old flipped model, we can have a tutorial for that if needed
[03:26] <rsalveti> I tested that locally, it's just that it's not what we want to officially support
[03:26] <rsalveti> and I think we can better support the porters in a different way
[03:27] <rsalveti> xnox: I believe we want to support both CM and AOSP, when we rebase to kitkat
[03:27] <rsalveti> as we can't just ignore the porters
[03:27] <rsalveti> I still don't know how we'll manage that, but something to keep in mind
[06:08] <pitti> Good morning
[06:25] <pitti> slangasek: ah, I couldn't agree more to your "UDD" response wrt. "don't commit to them"
[07:42] <cjwatson> sarnold: It's very irritating for debugging when grub.cfg is world-unreadable; I'm inclined to take Francesco's patch
[07:42] <cjwatson> (more or less directly)
[07:57] <didrocks> enjoy Debian miniconf cjwatson :)
[08:05] <pitti> gnargh, alioth down for a week now :/
[08:05] <cjwatson> annoying isn't it
[08:08] <pitti> muchly
[08:20] <pitti> does anyone know whether it's possible to exclude debian/patches/ from a Launchpad build recipe? https://help.launchpad.net/Packaging/SourceBuilds/Recipes has nothing in that area
[08:21] <pitti> but my daily builds keep failing because it tries to apply the 00git_*.patch cherrypicks to trunk
[08:27] <diwic> pitti, I don't think it's possible
[08:27] <pitti> diwic: ah, I was afraid of that
[08:28] <diwic> pitti, hmm, maybe you can take an empty branch and use the nest command ?
[08:28] <diwic> pitti, like, overwriting it with an empty directory or something
[08:28] <diwic> pitti, not sure it works, but could be worth a try
[08:29] <pitti> diwic: I have a feeling it's additive, but it's a nice idea
[08:29] <pitti> diwic: well, that branch could have an empty debian/patches/series, which shold overwrite the old one
[08:29] <diwic> pitti, yeah
[08:30] <diwic> pitti, it's possible it complains that the directory already exists though, in which case you have to do some ugly scripting instead (like erasing all patches first in the clean target or something)
[08:31] <pitti> diwic: that's too late -- dpkg-source will complain about the patches on unpack?
[08:31]  * pitti tries that "empty series" trick
[08:32] <diwic> pitti, actually, if you look in the src for making recipes, there is some way to run a shell command, but it seems to be turned off on the launchpad server
[08:32] <pitti> heh, it better be :)
[08:33] <diwic> pitti, this is from my vague memory from a year ago or more
[08:33] <diwic> pitti, anyway, since you have magical lp powers maybe it's turned on for you...
[08:33]  * pitti creates the marvellous piece of two years of engineering lp:~pitti/+junk/empty-series
[08:45] <pitti> ok, not that easy (https://launchpadlibrarian.net/156547038/buildlog.txt.gz)
[09:26] <pitti> I'm looking for a libc function or shell tool which produces a (line-by-line) merged pipeline from two pipelines; essentially the opposite of tee; any ideas?
[09:26] <pitti> use case: I want to tee stdout and stderr, and merge the combined result into a log file
[09:27] <pitti> I think you can open a FIFO several times for writing, but that might potentially garble lines
[09:30] <StevenK> pitti: 'paste' ?
[09:30] <rbasak> pitti: could annotate-output help you here? It'll run a command, take its stdout and stderr and combine them to stdout
[09:30] <rbasak> pitti: (on a line by line basis)
[09:31] <pitti> rbasak: in principle yes, except for the annotation bits
[09:31] <pitti> StevenK: ah, that sounds just like I was looking for, thanks!
[09:31]  * rbasak wonders if socat has a suitable option
[09:42] <pitti> StevenK: ah no, that does some magic tricks with joining lines with tabs, and they need to match in number
[09:43] <StevenK> pitti: You might be able to get away with -d\n, but I'm not sure.
[09:43] <pitti> StevenK: that still reads lines pairwise
[09:43] <pitti> StevenK: I'll try with plain FIFOs
[09:43] <pitti> that should by and large work; stdout/err work no different, after all
[09:43] <StevenK> 2>&1 ? :-P
[09:44] <pitti> I want to retain the original stdout/stderr, not merge them together
[09:46] <ogra_> use tmp files ?
[09:46] <ogra_> (and post-process them)
[09:46] <pitti> ogra_: how would that help?
[09:47] <pitti> nah, you can't open a file for writing twice
[09:47] <ogra_> one for each command and then merge tzhem afterwards
[09:47] <pitti> I think I'll use one tee for stdout -> stdout + FIFO, another tee for stderr -> stderr + FIFO, and a cat from FIFO to logfile
[09:47] <pitti> ogra_: you don't know how to interleave them, though, and you wouldn't get realtime logfiles
[09:48] <ogra_> indeed
[09:50] <rbasak> pitti: for the effort that would take, have you considered writing a quick Python script?
[09:50] <pitti> rbasak: that is a python script, it's called "adt-run" :)
[09:50] <pitti> rbasak: I want to simplify the rather convoluted way of logging
[09:50] <rbasak> pitti: I'm not sure that qualifies :-P
[09:51] <pitti> I want to do it in one place, not spread over all the code
[09:51] <rbasak> It looks more like a Perl script to me
[09:51] <pitti> rbasak: heh, yes
[09:51] <pitti> rbasak: although I spent some time to make it a little better
[09:51] <rbasak> I saw the changelog entries. I appreciate it!
[09:51] <pitti> rbasak: and I am doing some refactoring/cleanup to make it a bit more comprehensible
[09:52] <pitti> rbasak: I still don't understand these AutoFile classes at all, but that'll be the next step after cleaning up the output/logging handling
[11:57] <slacko253281> hi guys
[11:58] <slacko253281> i have question about pst, do you have any idea which application can read pst files from outlook so i can use it?
[12:05] <slacko253281> hi guys
[12:08] <pitti> slacko253281: evolution with the evolution-plugins package allegedly can
[12:15] <ogra_> dholbach, !!! congrats
[12:15] <ogra_> "Condorcet-Sieger: schlägt jeden anderen Kandidaten" ....
[12:16] <ogra_> stop beating the other candidates though :P
[12:26] <dholbach> ogra_, you're such a troll :)
[12:26]  * dholbach hugs ogra_
[12:26] <seb128> ok, so wpasupplicant is on top of e.u.c (which was expected since we cleaned the other issues) ... who is looking at that component?
[12:26] <seb128> cyphermox, stgraber: is that one of you? ;-)
[12:27] <seb128> mvo, update-manager is second, please help on bug #1024590 ;-)
[12:27]  * ogra_ hugs dholbach 
[12:28] <seb128> ev, bdmurray: is there anything we can do to debug/fix non working retracings on e.u.c? e.g https://errors.ubuntu.com/problem/bbbc7a7db95644fe731284a597366bf199bae00a is not very useful without more info
[12:56] <seb128> pitti, hum, for some reasons it seems http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt still isn't happy with gnome-icon-theme
[13:37] <seb128> diwic, hey, in case you didn't notice, your g-c-c test ppa for that raring user failed to build, looks like a typo in the patch you added there
[13:37] <mvo> seb128: hey seb128, sorry for letting you down on this, you asked me some days ago already, I just didn't mangaed to find time yet :/
[13:38] <seb128> oh, a mvo
[13:38]  * seb128 hugs mvo
[13:38] <seb128> mvo, no worry, sorry for being impatient, I'm exited by the LTS coming and trying to clean e.u.c issues ;-)
[13:38] <diwic> seb128, thanks for the heads up. I did notice, and blamed myself for forgetting to test-compile the stuff before sending to the ppa. And then other things happened and I forgot to fix and upload a new one
[13:40] <seb128> diwic, np, thanks for helping debugging that one!
[13:52] <ogra_> hmpf
[13:52] <ogra_> software-center is really crashy for me in trusty
[14:02] <seb128> ogra_, backtrace?
[14:03] <ogra_> seb128, seems to be X/compiz/Gdk related
[14:03] <ogra_> http://paste.ubuntu.com/6415934/
[14:03] <seb128> shrug
[14:03] <seb128> ogra_, can you get a stracktrace?
[14:04]  * ogra_ bets it would go away after a reboot ... 
[14:04] <seb128> ogra_, export GDK_SYNCHRONIZE=1
[14:05] <seb128> $ gdb python
[14:05] <seb128> (gdb) r /usr/bin/software-center
[14:05] <seb128> ... get the issue
[14:05] <seb128> (gdb) bt
[14:06] <seb128> ogra_, ^
[14:06] <seb128> oh, I get those as well
[14:06] <seb128> webkitgtk, shrug
[14:07] <seb128> ogra_, could be https://bugs.webkit.org/show_bug.cgi?id=123480
[14:07] <ogra_> seb128, http://paste.ubuntu.com/6415950/
[14:08] <seb128> hate webkit
[14:08] <seb128> the new version seems to make things even buggier for s-c :/ (that was already one of the most reported saucy issues)
[14:08] <ogra_> bah
[14:09] <seb128> ogra_, yeah, it's the same stacktrace that the bug I gave the url to
[14:09] <ogra_> yup
[14:09] <ogra_> just looking at it
[14:09] <ogra_> sigh
[14:15] <seb128> I wonder why the log has
[14:15] <seb128> [000:004] Using Gtk2 toolkit
[14:16] <seb128> dobey, isn't s-c using gtk3?
[14:34] <arun_> Guys anyone here freom dev team
[14:57] <doko> xnox, looking at http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt, boost demotions. how did we handle these in the past? should these be kept in universe?
[14:59] <stgraber> seb128: that's usually cyphermox
[14:59] <pitti> seb128: I guess it's because there's the failed deja-dup test; we need to restart it, once the DC is back
[15:00] <seb128> pitti, it's weird, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says "valid candidate", aren't tests on that report?
[15:00] <cyphermox> stgraber: I'm looking into it
[15:00] <seb128> cyphermox, stgraber: thanks ;-)
[15:00] <pitti> seb128: g-i-t-symbolic has the failed test
[15:00] <cyphermox> the thing is, there is not one successful trace, and I wasn't able to retrace it myself either
[15:00] <cyphermox> trying some more
[15:00] <seb128> pitti, oh ok, that would explain it indeed, danke
[15:01] <seb128> cyphermox, do you have some dumps?
[15:01] <pitti> seb128: but the "private jenkins" URL now points into the void, as the IPs changed
[15:01] <cyphermox> seb128: yeah
[15:01] <seb128> or are you able to reproduce the bug?
[15:01] <cyphermox> not able to reproduce, no
[15:01] <cyphermox> I have no idea how, nothing mentions it :)
[15:02] <mitya57> Mirv: hi, I just saw your PPU application — I think it'll be a good idea to create a packageset containing all qt packages so that other people (like me :P) can easily request access to it.
[15:06] <doko> pitti, hunspell-br wants to demote, anything changed in the language-* stuff?
[15:08] <pitti> doko: you mean it wants to *pro*mote? (because that's what c-m says)
[15:08] <pitti> doko: we seed all the dictionaries, yes
[15:11] <doko> ok, will do
[15:22] <saiarcot895> How long does it take for a backports request to be processed?
[15:34] <pitti> seb128: ah, I updated VPN config for the new DNS, I started http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-deja-dup/
[15:34] <seb128> pitti, danke
[15:34] <pitti> jibel, cjwatson: can we update the excuses page for the private jenkins URLs from the IP to d-jenkins.ubuntu-ci ?
[15:37] <Laney> pitti: cjwatson: doing
[15:38] <stgraber> are the IPs the same at least?
[15:38] <stgraber> otherwise we'll need to get IS to update all the firewalls again
[15:40] <pitti> stgraber: no, they all changed, hence my question
[15:40] <stgraber> pitti: well, we can change our config in the scripts to use the name, but firewall rules all use IPS
[15:41] <stgraber> pitti: so we still need someone from CI to send a list of old ip => new ip to IS so they can update all the firewalls accordingly
[15:41] <Laney> Not sure what the path for jobs to get submitted is
[15:49] <jibel> stgraber, IP changed, but I don't know yet if services that hosted autopkgtest will move or not to another server
[15:50] <Laney> jibel: It should ideally get a DNS record
[15:50] <jibel> Laney, there is a DNS record now, just don't have the confirmation of name of the machine
[15:51] <pitti> jibel: d-jenkins.ubuntu-ci works here
[15:51] <jibel> pitti, right, but the gateway with the lab seems to still be jiufeng
[15:51] <Laney> Is it the same for submission and viewing?
[15:51] <pitti> there's also an s-jenkins, q-jenkins, and possibly others; I read "d-" as "distro"?
[15:52] <pitti> Laney: AFAICS, yes
[15:52] <Laney> The IPs were different before
[15:52] <pitti> yeah, I have two different IPs in my browser history, but they seemed to be aliases
[16:40] <cjwatson> $ syncpackage -f grub2
[16:40] <cjwatson> ^- commands that feel REALLY good to run
[16:43] <mitya57> cjwatson: \o/
[16:52] <xnox> doko: if it's binaries only, it should be safe to demote them. at times some get "recovered" and are usually pulled back in without much fuss. I think infinity demoted *53* ones after that transition was done. And main has transitioned to boost1.54, so it is safe to demote those that are not needed.
[16:52] <doko> ok, thanks
[16:53] <ogra_> infinity, http://www.mail-archive.com/u-boot@lists.denx.de/msg125968.html ... in case you want our panda images to also support the new svtronics panda ...
[16:58] <infinity> ogra_: That patch is vile.  I assume someone will commit something less hackishly gross upstream at some point.
[16:58] <ogra_> yeah, its not actually a beauty
[17:47] <pitti> bdmurray, infinity, stgraber: can I nag you about looking at the systemd-shim saucy SRU?
[18:17] <sarnold> cjwatson: thanks (re: grub.cfg, francisco's patch)
[18:27] <bdmurray> pitti: I'll review it
[19:42] <barry> @pilot in
[20:54] <bdmurray> slangasek: bug 1241385 is interesting in that the already installed and configured message comes after an "unexpected end of file or stream" for the same package
[21:12] <slangasek> bdmurray: ah; so in that case, it seems like there was an error from the dpkg --unpack command, which wasn't handled before sending a follow-on dpkg --configure command?
[21:17] <infinity> barry: Why did you sponsor that memcached upload? :/
[21:18] <bdmurray> slangasek: that sounds right to me
[21:18] <infinity> barry: Gratuitous patch diffs, plus it's FTBFS, plus poor style in the one new patch...
[21:18] <barry> infinity: i fixed it :)
[21:19] <barry> well, it builds locally, at least on amd64
[21:20] <slangasek> infinity: say hello to the Cambridge pub full of Debianers
[21:20] <infinity> slangasek: I didn't pub tonight, I'm fluish and trying not to kill myself.
[21:21] <slangasek> ah
[21:21] <infinity> barry: Given that it only built on i386, I'm assuming it builds with "-b" but not "-B".
[21:22] <infinity> barry: Which is likely because quilt doesn't appear to run with -B...
[21:23] <slangasek> cjwatson: so I'm having a poke at kernel package cross-buildability; I'm surprised to find openssl in the list of unsatisfied cross-build-deps.  Was that not M-A: foreign at one point?
[21:24] <infinity> Erm...
[21:24] <infinity> Ew.
[21:24] <infinity> barry: Yeah, you shouldn't have accepted this patch. :P
[21:25] <infinity> barry: Mixing and matching old-style and dh(1) is unpredictable and never right.
[21:27] <infinity> barry: Better to just manually call dh_autoreconf and dh_autoreconf_clean at the right parts of the series (right before configure, and right before dh_quilt_unpatch, probably)
[22:16] <bdmurray> slangasek: so I think I've found dozens of bugs where dpkg tries to configure a package that failed to unpack, does consolidating them all make sense?
[22:20] <slangasek> bdmurray: yes
[22:23] <barry> infinity: well, let's see if this one fixes the ftbfs
[22:43] <orbisvicis> is there a tool to list all uninstalled dependencies of a deb ?
[22:46] <sladen> orbisvicis: not quite; but  apt-get -f install
[22:46] <sladen> orbisvicis: will fix it
[22:46] <sarnold> orbisvicis: apt-get install --dry-run  <packagename> does a good job, if apt knows about the package
[22:46] <sladen> orbisvicis: or apt-get install -n ..   or apt-get install and Ctrl-c
[22:48] <infinity> barry: The whole '%:\ndh $@' bit should have gone away when you did that too.
[22:48] <infinity> barry: And autoreconf should come after quilt_patch, since some patches touch reconf bits.
[22:49] <infinity> barry: How about I just fix it? :)
[22:50] <barry> infinity: clearly my isp is totally f*cked this evening, so please dtrt.  thanks ;)
[22:51] <infinity> barry: Done.
[22:54] <infinity> Oh lolz, except now it's broken on i386.  *headdesk*
[22:54] <infinity> S'pose I should test this properly instead of shotgunning a fix.
[22:55] <infinity> Oh, this is probably the patch itself actually breaking with autoreconf.
[22:55] <infinity> So, this wasn't even tested by the person you sponsored for, as it wouldn't have had the desired effect.
[23:02] <barry> @pilot out
[23:03] <barry> infinity: i did actually test the local builds and it seemed to do as advertised
[23:04] <barry> sigh.  i give up.  maybe my intarwebs will be happier tomorrow
[23:48] <brainwash> cjwatson: should I file a launchpad report for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632598 ? still not sure if this is an issue which should be addressed and fixed eventually
[23:52] <rsalveti> hm, seems the simplejson package is empty now
[23:53] <rsalveti> can't run any lp script anymore