[04:49] <pitti> barry: any luck with oneconf?
[04:49] <pitti> Good morning
[06:52] <dholbach> good morning
[07:17] <pitti> who maintains bzr these days?
[07:18] <dholbach> pitti, asomething did a few uploads to Debian and we synced/merged from there AFAIK
[07:18] <pitti> its test_gpg.py bits fail with "pgmeError: (7, 150, u'Invalid crypto engine')", I guess that needs some actual domain knowledge
[07:21] <pitti> jelmer: ^ would you have an idea why this happens?
[07:41] <geser> pitti: see also bug #1196253 (same error message) but no solution
[07:42] <pitti> geser: right, dholbach pointed that out, too; so that smells like a bug/missing dependency of libgpgme
[07:42] <pitti> could be fallout from https://launchpad.net/ubuntu/+source/gpgme1.0/1.4.2-0.1ubuntu2
[07:58] <geser> pitti: sounds very likely as the build log contains: "GnuPG path:      /usr/bin/gpg2". And if then gnupg2 is not installed it could produce the error you see (did you have gnupg2 installed or not?)
[07:59] <pitti> geser: not sure, some dependency might pull it in
[07:59] <pitti> geser: which build log did you look at?
[08:00] <geser> pitti: https://launchpadlibrarian.net/143289079/buildlog_ubuntu-saucy-amd64.gpgme1.0_1.4.2-0.1ubuntu2_UPLOADING.txt.gz
[08:00] <pitti> geser: oh, build-depends gnupg2
[08:00] <geser> it was from "GPGME v1.4.2 has been configured as follows:" after the configure run
[08:01] <pitti> so we'll need to flip that as well
[08:02] <geser> looks like the gnupg version (gnupg or gnupg2) has to match in build-depends and depends
[08:02] <pitti> geser: hah, I get the same error when calling "seahorse"
[08:03] <pitti> so nice, this pointed out an actual regression then
[08:03] <pitti> seb128: ^ FYI, in case you stumble over a searhorse bug that it doesn't show gpg any more
[08:06] <seb128> pitti, thanks
[08:10] <pitti> seb128: do we actually need the "gnupg | gnupg2"? seems we can only build it against either
[08:10] <Laney> wasn't it a dep chain thing?
[08:11] <pitti> ah, KDE once added gpg2 support
[08:11] <pitti> it might actually be enought to add back a gnupg build dep to support both, I'll try that now
[08:11] <pitti> http://launchpadlibrarian.net/24055413/gpgme1.0_1.1.8-2ubuntu1_1.1.8-2ubuntu2.diff.gz
[08:11] <pitti> was the original change
[08:15] <seb128> pitti, I don't really know, that was there before I touched that stack
[08:15] <pitti> seb128: right, I think I know what to do
[08:15] <seb128> pitti, good
[08:44] <pitti> jelmer: unping, I uplaoded a fixed gpgme1.0
[08:47] <pitti> barry: FYI, I uploaded oneconf with dropping the XS-Testsuite header, so that this will stop being run in jenkins and block propagation
[10:00] <jdoles> Why doesn't this demo work on Ubuntu? https://github.com/juneym/php-gettext-demo (clone it, follow the instructions, which involve only generating a locale, and run php index.php).
[10:05] <sladen> jdoles: it's quite broad; a bit like "why doesn't my computer work".  What is the specific command you run that fails, and the specific error message you get when you run that command (the reason to lead you to believe that it is not working as intended)
[10:06] <sladen> jdoles: with that, the best is to search for the same error message, and if not found to find a report in Launchpad, so that people who know the software in question can have a look
[10:09] <jdoles> sladen: it's like 10 lines of code...
[10:09] <jdoles> sladen: and I didn't write it.
[10:09] <jdoles> sladen: I do think it *should* work.
[10:09] <jdoles> sladen: it's *trivial* to reproduce.
[10:09] <jdoles> sladen: it takes like 1 whole minute.
[10:10] <jdoles> sladen: so, you could have reproduced it 4 times already.
[10:12] <jdoles> sladen: and I just verified that it does work on Debian Wheezy.
[10:13] <pitti> Laney: can you please do the magic to allow oneconf 0.3.4 to propagate? I remove its broken autopkgtest
[10:13] <Laney> pitti: still needs hitting in that case?
[10:14] <jdoles> Is there anyone remotely intelligent here?
[10:16] <Laney> pitti: (will do, but it'd be good to get that bug fixed)
[10:18] <sladen> jdoles: yes, what makes you believe that /it is not working/
[10:18] <jdoles> sladen: I run it and I see no translation.
[10:18] <sladen> jdoles: riiight
[10:18] <jdoles> sladen: I do the same on Debian and it does.
[10:18] <cjwatson> jdoles: Works fine provided you follow the instructions on the page to generate the locales
[10:18] <jdoles> cjwatson: that's what you say.
[10:18] <jdoles> cjwatson: I did follow the instructions.
[10:19] <cjwatson> jdoles: Because I just tested it ...
[10:19] <jdoles> cjwatson: on Ubuntu 12.04 LTS?
[10:19] <cjwatson> (Note that you need to generate en_US.UTF-8 as well)
[10:19] <jdoles> cjwatson: I already had that one.
[10:19] <cjwatson> Happy to try that but you'll need to wait a moment.
[10:19] <Laney> pitti: (done)
[10:21] <jdoles> sladen: can you also perhaps keep your arrogant mouth shut? You have not _at_all_ proven to have any problem solving capability.
[10:21] <cjwatson> jdoles: It's also possible that you have LC_ALL set in your environment, which would override LC_MESSAGES.
[10:22] <jdoles> cjwatson: no, that's not possible.
[10:22] <cjwatson> jdoles: (However, please stop being abusive.)
[10:22] <jdoles> cjwatson: because I unset LC_ALL.
[10:22] <sladen> jdoles: having replicated that on 12.04.2, I /don't/ get translationed messages with the default config
[10:23] <pitti> Laney: thanks
[10:23] <jdoles> sladen: so, that would mean you are seeing the same bug.
[10:23] <cjwatson> jdoles: Works for me on precise.
[10:23] <cjwatson> jdoles: Proof: http://paste.ubuntu.com/5928494/
[10:24] <cjwatson> That's an entirely clean precise environment
[10:24] <sladen> jdoles: concur.  Remember that context is needed; when code runs (executes) it may not be immediately apparent what is different to normal.  The crucial information here is that a japanese message should be appearing
[10:25] <jdoles> cjwatson: I think the main problem is that it also silently fails.
[10:25] <jdoles> cjwatson: but that is more of a PHP problem and not related to packaging.
[10:25] <cjwatson> Well, the C-level gettext interface is a bit like that; it prefers issuing untranslated text rather than errors.
[10:25] <jdoles> A rather stupid design.
[10:25] <cjwatson> No, it makes sense for its problem domain.
[10:26] <jdoles> It should log to a file when there is a problem.
[10:26] <cjwatson> Packages are often only partially translated.
[10:26] <jdoles> Or to some socket or configurable.
[10:26] <cjwatson> It's still not remotely clear what's happening in your case.  strace might help.
[10:26] <jdoles> Silently failing is a design flaw for any component.
[10:26] <sladen> not necessarily if you are a webpage generator
[10:26] <cjwatson> setlocale does produce errors, which no doubt it's possible to get PHP's gettext interface to not ignore.
[10:27] <sladen> (however a choice of when to error is something that would be better raised with the authors of PHP)
[10:27] <jdoles> cjwatson: strace shows useful information.
[10:27] <cjwatson> Can you share it?
[10:30] <jdoles> Now it works :/
[10:30] <jdoles> Let me see whether I do know the cause now.
[10:31] <jdoles> If so, there is a dependency error in Ubuntu packaging.
[10:31] <sladen> jdoles: did you apt-get install php-gettext ?
[10:31] <sladen> jdoles: (I did this, and found no change)
[10:31] <slangasek> if he hadn't, php should've given errors immediately about undeclared functions
[10:32] <jdoles> sladen: yes, I did, but that doesn't make a difference.
[10:32] <jdoles> It does work now, but I don't recall me doing anything which should have caused that.
[10:32] <cjwatson> I slightly question whether this can be a dependency error given that my paste shows it working in a clean chroot with nothing beyond php5-cli (and, admittedly, git); but perhaps details will help
[10:32] <jdoles> I did do apt-get install php-gettext and removed it again.
[10:33] <cjwatson> php-gettext was not installed in my environment at any point
[10:33] <jdoles> Before that command it didn't work, after the installation it did, and after the removal it also did.
[10:34] <jdoles> cjwatson: I think we will never know what caused it.
[10:34] <cjwatson> My best suggestion is to try to reproduce in a clean environment, perhaps by iteratively bringing such a thing closer to your real environment.
[10:35] <sladen> now I
[10:35] <slangasek> ah; yes, the php-gettext package bypasses C gettext, yuck
[10:35] <cjwatson> mk-sbuild + schroot + overlayfs makes throwaway chroots pretty trivial to use.
[10:35] <jdoles> cjwatson: how fast does that command run and does it cache downloads?
[10:36] <jdoles> cjwatson: (and on what hardware)
[10:37] <cjwatson> mk-sbuild runs debootstrap under the hood, so it takes a while depending on your connection.  Downloads can be cached by setting up schroot to mount a persistent filesystem location onto /var/cache/apt/archives/ inside the chroot, although I think most people don't bother and just use either a local mirror or an apt proxy.
[10:37] <cjwatson> I ran the command I pasted while talking to you so you can infer it only takes minutes.  Reasonable laptop, nothing special, doesn't particularly take much out of the host hardware.
[10:38] <cjwatson> (mk-sbuild only needs to be run once for a given release/architecture combination, and then you just occasionally update it with sbuild-update.)
[10:40] <sladen> right,   LANGUAGE="" php index.php  works; anything else doesn't
[10:41] <cjwatson> LANGUAGE overrides LC_MESSAGES, as documented by gettext
[10:41] <cjwatson> Indeed, LANGUAGE even overrides LC_ALL for the purposes of the messages category
[10:42] <sladen> jdoles:  set | grep LANGUAGE
[10:43] <sladen> which I presume is coming from /etc/default/locale
[10:44] <sladen> which I have dated 2011-12-15 (ie. early in the development cycle).  cjwatson: is that not now set on later installs?
[10:45] <slangasek> well, the above test was with a chroot that wouldn't have used the installer
[10:46] <cjwatson> Whether it's set depends on the details of the installation.
[10:46] <cjwatson> In any case, if you want to override LC_MESSAGES and guarantee that to be effective then in general you must unset LC_ALL and LANGUAGE.
[10:47] <cjwatson> So I'd class that as a bug in this demo script.
[10:47] <cjwatson> Even if it happens, by luck, to work in some environments.
[10:47]  * slangasek nods
[10:51] <infinity> I'd say that script assumes your server runs in C.
[10:51] <infinity> Which isn't an unfair assumption, but still not a safe one.
[10:54] <sladen> jdoles: I've pushed a fixed version to github, and sent a pull request:  https://github.com/juneym/php-gettext-demo/pull/1
[10:57] <pitti> ev: does whoopsie write a log file by default? I can't find one in /var/log/
[10:57] <pitti> ev: I have two crash reports with .upload tags, but they apparently don't get uploaded
[11:00] <sladen> cjwatson: done, with added --author kudos
[11:00] <cjwatson> ta
[11:07] <pitti> ev: I stopped whoopsie, and ran "sudo CRASH_DB_URL=https://daisy.ubuntu.com whoopsie -f", but that's also not picking up the two *.crash/*.upload files?
[11:08] <pitti> ev: oh, it actually does pick them up, just doesn't tell me about them
[11:21] <pitti> cjwatson, jibel: how can adt-britney be poked to reconsider pygobject? the failing oneconf test was removed (in the archive and private jenkins); does it need to be removed from the public jenkins instance first (that needs retoaded), or does it just need a nudge?
[11:21] <cjwatson> Public Jenkins instance doesn't matter.
[11:23] <cjwatson> Not sure what the most-correct way to deal with the rest is (we could force it, but maybe that isn't optimal).  Needs jibel
[11:23] <pitti> cjwatson: I guess I could just reupload the package, I was just curious whether there's a cheaper way
[11:24] <pitti> cjwatson: thanks, will ask jibel
[11:24] <cjwatson> Certainly don't reupload
[11:24] <jibel> pitti, no really cheap way, I can resubmit a test manually to avoid an upload
[11:24] <cjwatson> *A* cheaper way is to have a member of ~ubuntu-release force it, but on general principles I'd prefer to see if it's fixable in the code
[11:24] <cjwatson> jibel: There's no test to resubmit
[11:25] <cjwatson> Since this is a matter of a test being removed and adt-britney incorrectly not noticing
[11:25] <pitti> jibel: all rdepends tests succeeded except oneconf, whose test just got removed (that's in saucy now)
[11:26] <jibel> ah right, that'd mean forcing a pass on oneconf or removing the entry from the history
[11:27] <Mirv> is it intentional https://lists.ubuntu.com/archives/saucy-changes/2013-July/thread.html seems stalled since last week's Monday?
[11:27] <Laney> no, but known
[11:28] <cjwatson> jibel: adt-britney can't detect that it no longer has an XS-Testsuite: autopkgtest?
[11:28] <ev> pitti: it's not very verbose by default, but what logging it does goes into /var/log/upstart/whoopsie.log
[11:28] <cjwatson> jibel: I don't mind forcing the odd one, but this has happened a couple of times now so chances are we'll miss some
[11:28] <ev> pitti: feel free to add and commit any additional log statements you
[11:28] <ev> ned
[11:28] <ev> need even
[11:31] <pitti> jibel: I guess it needs some brain surgery in its state files?
[11:32] <pitti> ev: that just says "Using lock path: /var/lock/whoopsie/lock", nothign about uploading or checking files?
[11:34] <cjwatson> jibel: If you can suggest where I need to perform surgery, I can attempt it
[11:35] <ev> pitti: hmm, it *should* be logging more than that. whoopsie.c has a nonzero number of printf statements in it.
[11:35] <ev> so maybe it hasn't actually processed them for some reason
[11:40] <jibel> cjwatson, you can remove the line "oneconf 0.3.3 FAIL pygobject 3.9.5-0ubuntu1" from proposed-migration/autopkgtest/data/adt/saucy-proposed/amd64/work/results.history
[11:41] <cjwatson> jibel: Done, thanks
[11:41] <cjwatson> (Oops, p-m was running, hopefully I didn't confuse it)
[11:41] <dholbach> @pilot in
[11:42] <cjwatson> $ head -n1 /home/ubuntu-archive/proposed-migration/var/data-b2/output/Delta
[11:42] <cjwatson> pygobject 3.9.5-0ubuntu1
[11:42] <cjwatson> evidently not too badly
[11:42] <cjwatson> pitti: done
[11:42] <cjwatson> jibel: thanks
[11:44] <darkxst> dholbach, are you able to look at gjs update on NEW queue?
[11:44] <dholbach> darkxst, I'm sorry, I'm not an archive admin
[11:44] <dholbach> but somebody of these folks (https://launchpad.net/~ubuntu-archive/+members) might be able to help you out
[11:46] <darkxst> dholbach, ok
[11:47] <infinity> I'll give it a jab.
[11:48] <darkxst> infinity, thanks
[11:50] <infinity> darkxst: No plan for libgjs to actually get a real SOVER? :P
[11:50] <infinity> Package: libgjs0d
[11:50] <infinity> Replaces: libgjs0, libgjs0a, libgjs0b, libgjs0c
[11:50] <infinity> -rw-r--r-- root/root    209784 2013-07-30 00:40 ./usr/lib/libgjs.so.0.0.0
[11:50] <infinity> This seems to be a house of cards.
[11:50] <infinity> But, a well-established one, at least.
[11:52] <infinity> darkxst: Accepted.  If you can ever convince upstream to use sane so versions, that would be nice.
[11:55] <darkxst> infinity, I was just following the tradition (from debian)
[11:55] <infinity> darkxst: Yeah, I'm not arguing you were doing anything wrong there (nor has Debian, really, this sort of abuse is what an SOVER of 0 is meant for), but it still would be nice if people just versioned the library. :P
[11:56] <infinity> darkxst: Of course, that depends on how many rdeps it has.  If it's always simple and painless to transition, maybe no one really cares.
[11:57] <StevenK> infinity: Library releases are for OCD people. Just ask mplayer.
[12:03] <darkxst> infinity, I suppose the gnome guys don't bother, since your not reallly meant to mix n match releases in their eyes
[12:04] <infinity> darkxst: I'd say "that's not excuse for making partial upgrades--and upgrading in general--harder", but I know what distros most of upstream GNOME run, and "upgrading" is still a confusing concept for them. ;)
[12:04] <infinity> s/that's not/that's no/
[12:05] <infinity> darkxst: Anyhow, in this particular case, it's a bit of a "meh".  This has clearly worked in the past, and will continue to work.  It just need a full transition, and it's a bit of a burden on apt's resolver if it needs to upgrade that library and all its rdeps in one block, but it's not rocket surgery.
[12:12] <darkxst> infinity, right. though try convince upstream of that ;)
[12:14] <pitti> cjwatson: cheers!
[12:59] <jdoles> cjwatson: gettext can't switch language in a multi-threaded way, can it? (only one language per process) Do you know something which can do that?
[12:59] <jdoles> cjwatson: the advantage of using gettext is that there are lots of translation tools available, but if one can only switch 'domain' instead of language, that's not going to help anything.
[13:01] <Mirv> oh dear, precise doesn't support Build-Depends-Indep similarly to quantal and forwards
[13:02] <Mirv> not a big problem for this one package, but for 20 packages with next Qt update it might pose a bit of hindrance to have things differently for precise
[13:03] <cjwatson> jdoles: There's a uselocale function which supposedly can be used instead of setlocale to set a per-thread locale (undocumented in manpages or the libc info documentation, but see http://pubs.opengroup.org/onlinepubs/9699919799/functions/uselocale.html).  I've never used it myself since I avoid threads like the plague.
[13:04] <jdoles> cjwatson: why do you avoid threads like the plague? Don't you trust yourself or don't you trust everyone else?
[13:05] <cjwatson> jdoles: I'm not sure I trust anyone, including myself, to reason correctly about some of the worse corners of threads.  Event-driven programming is much easier to reason about.
[13:05] <jdoles> cjwatson: event-driven being message passing?
[13:06] <cjwatson> Message passing is a bit more specific.
[13:07] <cjwatson> For a typical Internet server, the event-driven model usually centres around a poll loop or similar, and you then make sure that the response to each event uses only non-blocking I/O.
[13:07] <cjwatson> You probably have one worker process per CPU core so that you make effective use of the hardware.
[13:10] <cjwatson> For example, nginx works this way.  (I've never worked on nginx directly, but I've worked on things with similar architectures.)
[13:14] <jdoles> cjwatson: I get about 10Krequests/sec and I am not sure what I am saturating, but it's certainly not the CPU.
[13:16] <rbasak> http://www.kegel.com/c10k.html for a pretty good summary of concurrent I/O techniques
[13:17] <cjwatson> requests/sec is a poor measure; concurrent connections is a much better one.
[13:18] <jdoles> cjwatson: how many of those should I get for reasonable performance?
[13:20] <jdoles> I can get -n 10000 -c 10000, but when I do that with more, it breaks.
[13:21] <jdoles> Perhaps lack of memory.
[13:21] <cjwatson> Ten years ago (when I was last working on this stuff full-time) I'd have considered anything that couldn't do thousands of concurrent connections not-fit-for-purpose.
[13:22] <cjwatson> I'd hope things have moved on since then.
[13:23] <cjwatson> Saturating memory would be pretty terrible.  Obviously it depends what you're doing but nginx claims on the order of 2.5MB of RAM per 10000 connections.
[13:24] <cjwatson> Usually the limit on decent event-driven servers winds up being the event source they're using, so select vs. poll vs. /dev/epoll etc.
[13:26] <jdoles> cjwatson: in this case it is nginx that was falling over.
[13:26] <jdoles> cjwatson: 768 worker_connections are not enough
[13:26] <cjwatson> With a threaded server I'd expect the scheduler to run into trouble first, assuming you'd managed to write a program that never does anything wrong with the POSIX threads API.
[13:26] <jdoles> I will increase that limit.
[13:26] <cjwatson> jdoles: Well, like I say, I haven't worked on nginx directly.  I'm talking about the model.
[13:26] <dholbach> jcastro, is https://code.launchpad.net/~tribaal/ubuntu/saucy/juju-core/add-bash-completion/+merge/177287 something that should go into juju upstream instead?
[13:27] <cjwatson> (I worked on Zeus back in the dawn of time.  Sadly proprietary and now apparently mostly discontinued though.)
[13:29] <jdoles> cjwatson: do you think this is reasonable? http://paste.kde.org/p9d351457/
[13:29] <jdoles> cjwatson: ab -n 100000 -c 10000 <url>
[13:29] <jdoles> There are no failed requests, just some really slow ones.
[13:31] <jcastro> dholbach: yea I believe so, should I get someone upstream to check it out?
[13:31] <jdoles> Twitter talked about 22MB/s it seems I am pushing more than that here on one machine.
[13:33] <cjwatson> jdoles: It certainly used to be that ab itself started running into problems before good-enough servers did.
[13:33] <cjwatson> Like I say it's been a decade.
[13:34] <cjwatson> (My memory of the history is that Zeus wrote ab and contributed it to the Apache project; but then they had several more improvements internally that I don't think were ever released.  There are some other tools like siege that I think used to be better.)
[13:35] <dholbach_> jcastro, is https://code.launchpad.net/~tribaal/ubuntu/saucy/juju-core/add-bash-completion/+merge/177287 something that should go into juju upstream instead?
[13:36] <jcastro> dholbach: I believe so
[13:37] <dholbach> jcastro, can you find somebody to get it upstream? :)
[13:37] <jcastro> dholbach: what's the next step, have someone upstream review it or do I need assign something to someone in launchpad or ?
[13:37] <dholbach> jcastro, just ask around if they want to add it there and if they do, I'll ask for this MP to be closed
[13:37] <jcastro> got it, thanks
[13:47] <dholbach> seb128, looks like https://code.launchpad.net/~adam-stokes/ubuntu-seeds/ubuntu.saucy/+merge/177469 would add sosreport to desktop recommends - is this what you'd want?
[13:49] <seb128> dholbach, I would prefer not adding new python2 code to the default installation ... any way that could be ported to python3?
[13:49] <seb128> stokachu, ^
[14:20] <dholbach> ScottK, Riddell: I just had a look at https://code.launchpad.net/~ari-tczew/ubuntu/saucy/networkmanagement/lp-1205545/+merge/177297 and it looks good to me - I just wanted to confirm if http://paste.ubuntu.com/5929192/ (debdiff of the resulting .deb files) looks OK to you too?
[14:20] <dholbach> it looks like the header files should not have been included in the shipped package in the first place, right?
[14:21]  * Riddell looks
[14:26] <Riddell> dholbach: the libraries have different so name versions presumably it was build on a different version of kdelibs, if the packaging doesn't care about that then it looks good to me
[14:27] <dholbach> Riddell, at least it builds fine for me
[14:27] <Riddell> dholbach: yeah go ahead then thanks
[14:27] <dholbach> rock and roll
[14:27] <dholbach> thanks!
[14:42] <JackYu> barry, hi, do you have more comments on the bugs (bug #1203931 and bug #1203958) I filed?
[14:44] <barry> JackYu: i'm sorry, i'm totally slammed with other work right now.  can you ping me again in a couple of days? ;)
[14:44] <barry> JackYu: or maybe ping dholbach if he's still patch piloting
[14:45] <dholbach> I'm not a scope expert, so somebody from the desktop team would be good - I can do a general packaging review though
[14:46] <seb128> dholbach, there is nothing else than packaging review to do there
[14:46] <dholbach> ok
[14:46] <dholbach> I'll check them out in a bit
[14:48] <seb128> dholbach, I would appreciate if you sponsor them, so I can review them in NEW for the Kylin guys
[14:48] <seb128> dholbach, if I sponsor I can't do NEW review as well
[14:48] <dholbach> sure sure
[14:49] <JackYu> barry, dholbach, seb128, thanks:)
[14:53] <JackYu> dholbach, if you have any feedback or suggestion, please let me know.
[14:53] <dholbach> will do
[14:53] <JackYu> :)
[15:09] <dholbach> JackYu, seb128: video looks good - uploading
[15:09] <dholbach> JackYu, seb128: photo needs a bit of work
[15:11] <seb128> dholbach, thanks
[15:12] <JackYu> dholbach, thanks, we will improve  photo according to your comments asap.
[15:13] <dobey> jbicha: the removal of *.omf is because there's no more scrollkeeper?
[15:14] <jbicha> dobey: I don't know all the details but scrollkeeper is unnecessary these days
[15:14] <dobey> jbicha: right. just want to understand why the omf is deleted. does the new stuff not use the omf files?
[15:16] <jbicha> right
[15:16] <dobey> ok
[15:17] <jbicha> scrollkeeper was before my time so I'm honestly not even sure what it was used for
[15:18] <dobey> it was the help docs indexing stuff
[15:19]  * dobey would happily just get rid of the "help" docs for most apps anyway
[15:40] <dholbach> JackYu, seb128: so I run into http://paste.ubuntu.com/5929456/ - it seems like the tarball in bug 1203958 has a debian/ directory included already
[15:41] <dholbach> so I think I don't need to use lp:~jingjing20061278/unity-china-photo-scope/unity-china-photo-scope.pkg for packaging, right?
[15:41] <dholbach> I tried to debug the build in a number of ways, but didn't succeed yet
[15:41] <dholbach> the setup.py uses a local build_i18n_ext.py script which I'm a bit unsure about
[15:42] <dholbach> ./build_i18n_ext.py and ./setup.py both seem to use python2, while the rest of the code uses python3
[15:44] <dholbach> also it looks like Architecture should be "all" and not "any"
[15:47] <JackYu> dholbach, let me check.
[15:55] <infinity> pitti: I've probably asked you this before, but does your optipng magic parallelise at all?
[15:55] <infinity> pitti: With all our buildds being multi-core, and that part of the build taking forever, it would be nice if it did...
[15:56] <dholbach> JackYu, seb128: I'll add my findings to the bug report
[15:56] <dholbach> unfortunately I'm not able to fix it :-/
[15:57] <dholbach> I tried to compare with a bunch of other packages using "--with translations,python3"
[15:57] <dholbach> but I still was unable to fix it
[15:57] <dholbach> @pilot out
[15:57] <seb128> ok
[15:57] <seb128> dholbach, thanks for the help/reviews
[15:57] <pitti> infinity: no it doesn't at the moment; that would mean splitting into (up to) parallel=N processes within the wrapped dpkg-deb, right?
[15:58] <JackYu> dholbach, thank you. we will debug it and ping you tomorrow  (it's middle night here:)).
[15:58] <infinity> pitti: Or something, yeah.  Though, I guess dh_builddeb itself can parallelize, if one runs dh --parallel, so maybe that's the real answer.
[15:58] <dholbach> ok - all the bes then! :)
[15:59] <infinity> pitti: Oh, but that doesn't help on sources with a single massive binary package full of PNGs.
[15:59] <pitti> infinity: indeed, dh_builddeb already forks off dpkg-builddeb N times
[16:00] <pitti> infinity: oh arg, I know why
[16:00] <pitti> bug 893826
[16:00] <pitti> infinity: we actually override dh_builddeb to avoid exactly this
[16:01] <infinity> pitti: Oh, that actually works in our favour here.
[16:01] <infinity> pitti: Cause we then have control over this and don't have to balance "maybe it's parallel" with "maybe it's not" and try not to starve our CPUs.
[16:01] <pitti> infinity: so if we want to parallelize, we need a more clever way to predict which symlink will be done where
[16:02] <pitti> infinity: or save the original parallel value and fork off processes ourselves
[16:02] <infinity> pitti: We can just always assume we're serially processing debs when we get to dpkg-deb --build, and then use DEB_BUILD_OPTIONS=parallel to fork more optipng bits.
[16:03] <pitti> infinity: right, the dh_builddeb wrapper could export something based on the original $D_B_O
[16:04]  * infinity grabs the mangler source to see how mangled it is these days.
[16:09]  * pitti waves good night
[16:12] <infinity> pitti: Toodles.
[18:44] <gQuigs> I was wondering if all the desktop related lucid bugs on here: http://people.canonical.com/~ubuntu-archive/pending-sru.html could just be closed
[18:44] <gQuigs> for example: xserver-xorg-video-openchrome, gnome-power-manager and moon (moonlight)
[19:18] <gQuigs> one other (unrelated) question:  Will saucy stay on being synced from Weezy?   While Saucy+1 LTS will be based on Jesse?
[19:51] <jtaylor> saucy is synced from debian unstable
[19:51] <jtaylor> same with saucy+1
[19:52] <jtaylor> though at this stage automatic syncs are disabled but manual syncs still possible
[19:53] <jtaylor> gQuigs: ^
[19:53] <gQuigs> jtaylor: I was told to check this page to see what it is derived from: https://launchpad.net/ubuntu/saucy
[19:53] <gQuigs> which says Wheezy..  is it just wrong?
[19:55] <jtaylor> I'd say its wrong, wheezy is based on a state almost a year old while saucy is still very similar to current debian unstable
[19:58] <sarnold> is it possible to sync from debian experimental? or must packages migrate to unstable or testing first?
[19:58] <jtaylor> its possible, if there is a good reason
[19:59] <jtaylor> its common during debian freeze where experimental is used as unstable replacement, but now you shouldn't in general
[19:59] <gQuigs> hmm.. I can't find anything synced to saucy yet...
[19:59] <jtaylor> as experimental is again used for what its named
[19:59] <sarnold> ahh, makes sense..
[19:59] <gQuigs> but raring looks to be definitely based on Wheezy (and it was testing at the time)
[19:59] <jtaylor> gQuigs: what are you looking at?
[20:00] <gQuigs> http://packages.debian.org/search?keywords=squid3+&searchon=names&suite=all&section=all  vs http://packages.ubuntu.com/search?suite=all&arch=any&searchon=names&keywords=squid3
[20:00] <gQuigs> same thing with puppet (for raring)
[20:01] <jtaylor> that has a ubuntu diff, so its needs manual merging
[20:01] <jtaylor> it was updated atwo eeks ago but its still stuck in proposed
[20:02] <jtaylor> https://launchpad.net/ubuntu/+source/squid3
[20:02] <seb128> sarnold, what do you want to get synced?
[20:03] <roaksoax> mterry: howdy! any ideas why crmsh has not been promoted to main?
[20:04] <sarnold> seb128: pdns; the powerdns team is thinking of treating 3.3 as a LTS themselves, so I think it'd be nice to have in saucy before 14.04 LTS.. http://packages.debian.org/experimental/pdns-server
[20:04] <mterry> roaksoax, looking
[20:04] <seb128> sarnold, do you know why it's in experimental and not unstable?
[20:04] <sarnold> (though I doubt the powerdns guys intend six years of support)
[20:04] <gQuigs> oh ok, so when puppet eventually autosyncs, puppet 3.2.1 should be pulled from debian unstable?  (https://launchpad.net/ubuntu/+source/puppet)
[20:05] <sarnold> seb128: no. the debian maintainer is not too pleased with ubuntu as a whole, so I've decided to not push his buttons any further by asking :)
[20:05] <mterry> roaksoax, I just think it hasn't happened yet.  Maybe poke an archive admin
[20:05] <jtaylor> gQuigs: puppet is up to date in saucy
[20:05] <roaksoax> mterry: will do! thanks!
[20:05] <sarnold> seb128: I believe there is conf.d/ style changes in configuration though, I believe that caused a fair amount of extra effort.
[20:06] <seb128> sarnold, ok, there is a good chance it lands in unstable before the next LTS, we can wait for a bit (or just sync if somebody is looking after it)...
[20:07] <sarnold> seb128: cool, thanks :)
[20:10] <gQuigs> jtaylor: damn, sorry - you are right;  package.u.com failed me :/
[20:10] <jtaylor> gQuigs: launchpad and the debian pts are better sources of information
[20:11] <jtaylor> protip: bind a keyword search to http://packages.qa.debian.org/common/index.html?src=%s
[20:13]  * SpamapS updates aging "on dev release since maverick" box to saucy wondering "will this be the upgrade that kills it?"
[20:55] <doko> slomo__, seb128: I hate gst-plugins ...
[20:55] <doko> why is libgstreamer-plugins-base0.10-dev built form gst-plugins, and not from gstreamer itself?
[21:02] <seb128> doko, because gstreamer is a framework and the plugins are optional/different sources?
[21:02] <doko> seb128, yes, but the plugins comes with a rat tail of dependencies
[21:03] <seb128> doko, base not much, but the other ones do...
[21:03] <doko> different question, how do I build plugins-base as a DEB_STAGE=stage1 build without these deps?
[21:04] <doko> my problem is libtheora, and maybe gnomegvfs
[21:04] <doko> so being able to build without these two would be good
[21:06] <seb128> I don't know about gst to answer that...
[21:07] <doko> seb128, so slomo__ ?
[21:07] <seb128> yes
[21:12] <slomo__> doko: just disable those plugins then, remove from build deps and remove the two files from debian/*.install
[21:15] <Laney> doko: you might like --disable-external too
[21:51] <doko> Laney, how do I tell cdbs not to build a certain package?
[22:00] <Taggg> hi, can anyone tell me the proper branch to propose this fix be merged into? https://code.launchpad.net/~mar-kolya/ubuntu/raring/acpid/fix-for-1184831
[22:00] <Taggg> i'm not sure if i should propose merge into raring, saucy, or something else?
[22:02] <sarnold> Taggg: I believe the usual approach is to propose to devel first to make sure the bug doesn't come back in the future :)
[22:02] <Taggg> sarnold: would that be this? https://code.launchpad.net/~ubuntu-branches/ubuntu/saucy/acpid/saucy
[22:04] <Taggg> sarnold: i'm not too familiar with the series/milestone terminology
[22:05] <sarnold> Taggg: yes, that looks correct
[22:06] <Taggg> sarnold: great thanks! one more question: how long do merge requests typically take to go through?
[22:06] <sarnold> Taggg: hrm, dunno, but patch pilots do look at the backlog of patches daily to move things along
[22:09] <cjwatson> gQuigs: Trust me, it's definitely synced from unstable, as was raring - I operate the auto-sync.  Launchpad's derivation information is wrong because it was hard to make it correct, but it's also basically irrelevant.
[22:09] <Taggg> sarnold: so what's the difference between proposing a merge into raring and raring-proposed?
[22:10] <Taggg> sarnold: is raring-proposed for bigger more-disruptive changes?
[22:10] <cjwatson> Stable releases aren't for disruptive changes at all.  Virtually all changes belong in saucy, the current development series
[22:10] <sarnold> Taggg: yes, raring-proposed is used for Stable Release Updates -- people who have reported bugs can find the fixes in the -proposed area, test them out, and mark the validation in the bug a success or failure
[22:10] <cjwatson> raring* is only for things following https://wiki.ubuntu.com/StableReleaseUpdates
[22:13] <Taggg> sarnold, cjwatson: great thanks! yeah i'm not doing an SRU, haha, so saucy it is :)
[22:21] <doko> Laney, works! now how to teach cdbs ...
[23:55] <cjwatson> wg 27
[23:55] <cjwatson> sorry