[02:41] <mfisch> robert_ancell: I ran info an issue merging manpages, bzr claims the branches have diverged
[02:41] <robert_ancell> mfisch, merging which manpages?
[02:41] <mfisch> robert_ancell: the manpages package
[02:42] <robert_ancell> oh, that package is fun
[02:43] <mfisch> bzr gave up halfway through the mege
[02:43] <mfisch> I did spend some time cleaning up the bug list, resolved a bunch, incompleted a bunch more
[02:44] <mfisch> I'm going to take debian and try to merge our stuff on top of it instead
[03:01] <mfisch> robert_ancell: I'm going to propose that we drop the Ubuntu modifications, I'll email you and see what you think
[03:01] <mfisch> it would make everyone's life easier not to hold these changes and they're mostly incorporated upstream
[04:01] <Mirv> morn
[06:00] <didrocks> cyphermox: hey, you didn't update your WI. Had to do it for you :/
[06:41] <didrocks> jibel: salut (quand tu seras là). No more magners :/
[06:46] <jibel> didrocks, Hello, I noticed that :/
[06:47] <jibel> didrocks, riding my kids to school, back in 10min
[06:48] <didrocks> jibel: ttyl :)
[06:48] <didrocks> magners still pong though)
[06:51] <mlankhorst> morning
[06:51] <didrocks> hey mlankhorst
[06:51] <mlankhorst> oh excusez-moi, bonjour!
[06:51] <mlankhorst> riri
[06:53] <didrocks> héhé
[07:04] <jibel> didrocks, similar problem than last Monday
[07:05] <mlankhorst> didrocks: at what point will unity land in saucy?
[07:07] <jibel> didrocks, there is no good option right now, if we keep it in this state there is a chance the machine will completely hang in the next few hours, if I restart it there is 99% chance to completely lose connectivity to the lab.
[07:07] <jibel> didrocks, I'll go for option 1 and wait for someone with a hammer in Lex around 10:00UTC
[07:10] <highvoltage> AAAA/win 21
[07:17] <didrocks> mlankhorst: at the same time than touch will be able to land in saucy
[07:17] <didrocks> mlankhorst: which is now blocked on the phone fundation team
[07:17] <didrocks> jibel: yeah
[07:18] <didrocks> jibel: seems like it's our better chance
[07:55] <Laney> morning
[07:56] <seb128> hey Laney, hey desktopers
[07:56] <seb128> Laney, how are you?
[07:57] <mlankhorst> morning laney
[07:57] <Laney> seb128: good thanks
[07:57] <Laney> you?
[07:57] <Laney> g'day mlankhorst
[07:57] <seb128> I'm good as well
[07:58] <seb128> Laney, since Sweetshark got libreoffice to build I was thinking of uploading the new poppler, mitya57 prepared the transition in a ppa so it should be an easy one to get through ... any objection?
[08:01] <Laney> seb128: no, not that I can think of
[08:01] <Laney> tkamppeter__: ^?
[08:12] <tkamppeter> Laney, seb128, go ahead with the Poppler update, nothing bad of it is known to me, and it solves the filled-form-saving bug.
[08:18] <mitya57> The PPA was only to ensure that everything builds, please don't copy from there but reupload
[08:19] <Laney> mitya57: were patches required?
[08:19] <seb128> mitya57, you can't copy from a virtual ppa (missing archs) and I was not planning to do that
[08:19] <Laney> you can copy source only
[08:19] <Laney> one reason I've been using 'archive' version numbers in the evo-3.8 PPA
[08:19] <seb128> right
[08:20] <Laney> but yeah, you should intend to do that beforehand
[08:20] <mitya57> Okular and inkscape need some unrelated to poppler fixes
[08:20] <mitya57> (branches linked to the bug)
[08:21] <Laney> ok
[08:21] <Laney> I want to do empathy 3.8 first and then can start helping out on that if needed
[08:22] <seb128> Laney, it should be fine, I will start on it and let you know if I need help this afternoon
[08:23] <Laney> cool
[08:24] <mitya57> Note that I haven't tested libreoffice with new poppler yet
[09:54] <mitya57> seb128: looks like Riddell uploaded fixed okular, so only inkscape needs not rebuild-only upload
[09:55] <mitya57> Riddell: btw, it ftbfs on armhf, looks like one more line should be removed from libokularcore2abi1.symbols
[10:14] <Riddell> mitya57: ok thanks, I'm going to review all my kde merges today
[10:15] <seb128> Riddell, will you fix/reupload okular then? (just asking since we will need it to build to complete the poppler transition)
[10:16] <Riddell> seb128: yeah I'll get onto it shortly
[10:16] <seb128> Riddell, thanks
[10:20] <seb128> chrisccoulson, hey, how much do you hate ppc today? ;-)
[10:20] <chrisccoulson> hey seb128
[10:20] <chrisccoulson> how come?
[10:20] <chrisccoulson> i hate it as much as ever ;)
[10:21] <seb128> chrisccoulson, I saw that firefox is stucked in saucy-proposed because it failed to build on ppc
[10:21] <chrisccoulson> it's going to be stuck there forever then ;)
[10:21] <seb128> :-(
[10:22] <chrisccoulson> it sucks that we block migration because of ppc
[10:22] <seb128> right, I argued about that in the past
[10:24] <chrisccoulson> i wonder whether to just turn off the powerpc build entirely
[10:26] <seb128> I guess that wouldn't be the end of the world
[10:26] <seb128> the efforts spent to fix it don't seem worth the benefit
[11:14] <xnox> Laney: based on errors, saucy's currently top crasher is libproxy, where pxgsettings core dumps when run (without or any args, even e.g. --help)
[11:14] <xnox> have you tried poking it yet?
[11:15] <seb128> xnox, yes, the code is stupid and the patch trivial
[11:15] <Laney> I was hoping for upstream to reply
[11:15] <seb128> Laney, let's just drop that loop, it's cleaning on exit which is not required...
[11:16] <seb128> Laney, do you want me to upload that?
[11:16] <Laney> sure or I will later after my epic battle with empathy results in my victory
[11:17] <xnox> seb128, Laney: cool.
[11:17]  * xnox goes back to testing updated lvm2
[11:17] <Laney> I've been submitting that crash every time I get it btw so I may be responsible for a lot of the instances
[11:22] <seb128> it's weird, I never saw it here
[11:23] <Laney> nobody else complained to me about it which is why I didn't fix it urgently
[11:23] <Laney> figuring it's config dependent
[11:23] <seb128> well I get the segfault if I run that command
[11:23] <seb128> I suspect you have proxy somewhat enabled that's why you see it
[11:25] <Laney> shouldn't do
[11:25] <seb128> Laney, xnox: fix uploaded
[11:26] <Laney> ty
[11:26] <seb128> Laney, gsettings list-recursively org.gnome.system.proxy
[11:26] <seb128> can you pastebin that?
[11:27] <Laney> seb128: http://paste.ubuntu.com/5716409/
[11:27] <Laney> the localhost:8080 socks proxy is probably something I did
[11:28] <Laney> s/socks/http/
[11:28] <seb128> Laney, seems similar to my config, maybe I'm just not using a program using proxy through gio here ;-)
[11:28] <seb128> Laney, anyway I verified the fix works with the pxgsettings command line
[11:28] <Laney> oh well
[11:28] <Laney> great
[11:28] <seb128> Laney, I'm using pidgin and not empathy, which might be it :p
[11:31] <Laney> hmm
[11:31] <Laney> does it make sense to keep having all the account-plugins-* packages now that you don't need a .so for each of them?
[11:32] <seb128> what do you need?
[11:32] <seb128> I'm not familiar with how uoa works
[11:32] <seb128> what changed?
[11:32] <seb128> maybe better to ask ken when he will be online
[11:33] <Laney> you just need one plugin afaict
[11:33] <Laney> rather than having /usr/lib/libaccount-plugin-1.0/providers/*.so for each service
[11:35] <Laney> I suppose to not have them all listed by default
[11:37] <seb128> Laney, is that a change in 3.8..?
[11:38] <Laney> yep
[11:38] <seb128> on my saucy system, account-plugin-jabber: /usr/lib/libaccount-plugin-1.0/providers/libjabber.so for example
[11:38] <seb128> oh
[11:38] <Laney> it was done by m ardy
[11:39]  * Laney tries a build without them but with the same package structure
[11:40] <seb128> Laney, http://bugzilla.gnome.org/691418 I see
[11:40] <ubot2> Gnome bug 691418 in UOA "Use a shared plugin for all empathy providers" [Normal,Resolved: fixed]
[11:40] <Laney> yeah
[11:43] <seb128> Laney, does it still have the .service files?
[11:43] <seb128> e.g /usr/share/accounts/services/jabber-im.service
[11:44] <seb128> Laney, one thing to avoid would be to have all the "small/non usual providers" cluttering the accounts list, atm we only have the one installed listed in the control center
[11:44] <seb128> we probably want to avoid having 15 items in that list including stuff nobody use
[11:46] <Laney> seb128: yes, .service and .provider are still there
[11:46] <Laney> I'll keep the split for now
[11:46] <seb128> k
[11:49] <asac> seb128: who owns "Networking & Telephony story" on your side?
[11:49] <asac> cypher or stgraber?
[11:50] <seb128> asac, cyphermox
[11:51] <xclaesse> When upgrading the kernel, I get that error: cp: cannot stat '/module-files.d/libpango1.0-0.modules': No such file or directory
[11:51] <xclaesse> could be broken because of gnome3 ppa
[11:51] <xclaesse> anyone knows a workaround for that?
[11:51] <xclaesse> it happens when doing update-initramfs: Generating /boot/initrd.img-3.8.0-22-generic
[11:54] <seb128> xclaesse, is that saucy ?
[11:54] <xclaesse> seb128, raring
[11:55] <xclaesse> with some ppa like https://launchpad.net/~ubuntu-desktop/+archive/ppa and https://launchpad.net/~gnome3-team/+archive/gnome3
[11:56] <seb128> xclaesse, dpkg -l | grep pango?
[11:57] <xclaesse> seb128, http://pastebin.com/MhSx4rHL
[11:57] <seb128> shrug
[11:58] <seb128> you got bitten by ricotz's ppa, check with him
[11:58] <seb128> he tends to have packages pretty much on the "edge" side
[11:58] <seb128> I would avoid that ppa if I was you
[12:00] <xclaesse> yeah, I probably shouldn't have added those ppa :(
[12:01] <seb128> xclaesse, try to ppa-purge it
[12:01] <xclaesse> all I wanted is EDS 3.8 for the UOA integration
[12:01] <seb128> or at least re-install pango from raring
[12:11] <ricotz> xclaesse, if you have gnome3-stating ppa enabled you can wait for the plymouth update
[12:17] <ricotz> seb128, hi :), thanks for pinging me, but you could try to avoid scaring people away
[12:18] <seb128> ricotz, hey, did I scare people away?
[12:18] <ricotz> seb128, not sure, he doesnt answer ;)
[12:18] <seb128> ricotz, but that error seems to suggest you took the debian packaging change from pango which impact on initramfs and plymouth and pushed to a stable serie, that's probably something most users don't want to opt in for
[12:20] <ricotz> seb128, yes, i am fine with that in the staging ppa
[12:21] <seb128> ricotz, I wouldn't want to opt in for a ppa which impact on my initramfs, userspace is fine, boot stuff a bit less ... but just my opinion
[12:21] <ricotz> seb128, ok
[12:22] <sil2100> didrocks: if anything, I pushed an updated python-evdev to the packaging branch of mine, you can take a look when you have a moment ;)
[12:22] <sil2100> https://code.launchpad.net/~sil2100/python-evdev/debian
[12:22] <sil2100> Now I disappear, so see you later guys!
[12:41] <mitya57> cyphermox: can you please review (the fixed version of) https://code.launchpad.net/~abelloni/ubuntu-themes/3.8_fixes/+merge/161439 ?
[13:11] <seb128> hum
[13:11] <seb128> mitya57, you forgot packages in your poppler rdepends list, e.g xpdf is not in there and doesn't build with a simple rebuild :/
[13:13] <mitya57> seb128: oh it depends on libpoppler-private-dev which I didn't check
[13:13] <seb128> mitya57, shrug
[13:13] <mitya57> let me look at the build log
[13:13] <seb128> mitya57, rdepends libpoppler18 is what I did
[13:14] <mitya57> seb128: was it a local build? can you please paste the log somewhere?
[13:15] <seb128> mitya57,
[13:15] <seb128> -c -o build/GlobalParams.o build/GlobalParams.cc
[13:15] <seb128> build/GlobalParams.cc: In constructor ‘GlobalParams::GlobalParams(char*)’:
[13:15] <seb128> build/GlobalParams.cc:656:37: error: ‘getHomeDir’ was not declared in this scope
[13:15] <seb128>    baseDir = appendToPath(getHomeDir(), ".xpdf");
[13:23] <mitya57> getHomeDir() was removed in http://cgit.freedesktop.org/poppler/poppler/commit/?id=44bf99a7b8
[13:24] <seb128> mitya57, can you work on a build fix?
[13:24] <mitya57> seb128: sure
[13:24] <seb128> mitya57, thanks
[13:49] <mitya57> tsdgeos: is it safe to replace getHomeDir() with just getenv("HOME") in Ubuntu? (^)
[13:50] <tsdgeos> mitya57: what do you need it for?
[13:51] <mitya57> tsdgeos: xpdf uses it (see seb128's message above_
[13:51] <tsdgeos> ah
[13:51] <tsdgeos> well, don't break xpdf then :D
[13:51] <tsdgeos> xpdf != popplre
[13:52] <tsdgeos> if i was xpdf author i'd complain to people packaging something they call xpdf but is not, but obviously i'm not the xpdf author :D
[14:06] <cyphermox> mitya57: looking...
[14:06] <seb128> mitya57, hum, gdcm fails to build as well, though I'm not sure if that's due to poppler (https://launchpad.net/ubuntu/saucy/+source/gdcm/2.2.3-1ubuntu1)
[14:06] <Laney> mitya57: reverse-depends -b src:poppler for future reference
[14:06] <Laney> maybe without -b too to pick up indirect bds
[14:07] <attente> seb128, do you know how to properly update the .po files in g-c-c?
[14:07] <seb128> attente, you mean?
[14:07] <seb128> attente, the po are not in g-c-c, we export translation from launchpad ... or do you mean the template?
[14:08] <mitya57> seb128: this looks like gcc 4.8
[14:08] <seb128> :-(
[14:08] <mitya57> let me fix xpdf first, and then I'll maybe look
[14:08] <seb128> thanks
[14:09] <attente> seb128, to add new msgid's to the po files extracted from the source code of the changes to the panel i've made
[14:09] <seb128> attente, in a nutshell:
[14:09] <seb128> - use _() around your strings
[14:09] <seb128> - lists the source in po/POTFILES.in
[14:10] <seb128> - you can generate a template to check if your strings are listed with "cd po: intltool-update --pot"
[14:10] <seb128> that gives you a .pot in po/ which lists all the strings marked for translation
[14:10] <seb128> - that template is generated at build time, imported in launchpad
[14:11] <seb128> - translators do their work
[14:11] <seb128> - we export the translations in language packs
[14:11] <seb128>  
[14:11] <attente> _() is only for c code, right? what does one do if the string is in a GtkBuilder ui file for example?
[14:11] <seb128> attente, so basically just do the first 3 steps, if your string is listed you are all set, the buildd magic will do the work for you
[14:11] <seb128> attente, translation=yes
[14:12] <attente> seb128, awesome, thanks :)
[14:12] <seb128> ups
[14:12] <seb128> attente, translatable="yes" rather
[14:12] <seb128> attente, see e.g /usr/share/gnome-control-center/ui/gnome-region-panel.ui
[14:12] <seb128>     <property name="title" translatable="yes">Region and Language</property>
[14:12] <seb128> same for labels, etc
[14:13] <attente> heh, glade already puts those in automatically it seems
[14:13] <seb128> yes
[14:13] <Laney> speaking of translations, is it normal to have LP push back to trunk or a separate branch when setting a project up for translating?
[14:13] <seb128> Laney, it depends how the project is set up
[14:13] <seb128> some want direct commit
[14:13] <seb128> some prefer to manually merge the translation before doing a release
[14:13] <cyphermox> mitya57: approved.
[14:14] <Laney> I set it up for ubuntu-release-upgrader but going to another branch
[14:14] <Laney> seems like it would be easier to have it just go to trunk
[14:14] <seb128> yeah, lightdm seems to do that
[14:14] <seb128> maybe ask dpm, he probably knows better the details
[14:14] <dpm> hey
[14:15] <seb128> dpm, hey ;-)
[14:15] <Laney> the magic three letters
[14:15] <dpm> hello desktop folks :)
[14:16] <mitya57> cyphermox: thanks!
[14:16] <dpm> Laney, seb128, I always recommend setting the exports branch to trunk. This makes it much easier, as then the full process is automated and no one has to go and manually merge the translations branch to trunk, which in my experience tends to be forgotten
[14:17] <Laney> dpm: that's what I just noticed
[14:17] <Laney> will do that, assuming I can find the option again
[14:18] <dpm> Laney, yeah the UI is a bit difficult to navigate, it also often takes me a while to find it. The thing to remember is that translation exports are set for a given series
[14:18] <Laney> yep, got it
[14:18] <dpm> cool
[14:18] <dpm> Laney, also, if translations are done in LP, the best setting for imports is "Templates only"
[14:19] <dpm> unless you want to do a one-off import of existing PO files that were done outside of LP
[14:19] <dpm> then you'd choose "Template and translations"
[14:20]  * dpm has a todo to document translations setup best practices
[14:20] <Laney> I had it on templates and translation files
[14:45] <mitya57> seb128: I think the less ugly solution will be to have a cut down version of getHomeDir() inside GlobalParams.cc
[14:46] <mitya57> seb128: I'm on a sid machine now, so can't test locally, so pushed to ppa
[14:46] <mitya57> and to lp:~mitya57/ubuntu/saucy/xpdf/fix-for-poppler-0.22
[14:46] <seb128> mitya57, copy works for me
[14:46] <seb128> mitya57, ok, I can try it here
[14:58] <seb128> mitya57, fails to build
[14:58] <seb128> build/XPDFViewer.cc: In member function ‘void XPDFViewer::initOpenDialog()’:
[14:58] <seb128> build/XPDFViewer.cc:2978:52: error: ‘makePathAbsolute’ was not declared in this scope
[14:58] <seb128>         core->getDoc()->getFileName()->getCString()));
[15:00] <mitya57> :(
[15:05] <mitya57> I will now try to force including of xpdf's gfile.h instead of poppler's one, maybe that'll be easier
[15:13] <tsdgeos> seb128: mitya57: yes basically we removed lots of stuff from the gfile and stuff that was unused
[15:20] <seb128> I'm out for some exercice, back in ~1h
[15:31] <mitya57> tsdgeos: anything except makePathAbsolute and getHomeDir?
[15:31] <tsdgeos> mitya57: not sure what you mean
[15:33] <mitya57> tsdgeos: these are two functions you definitely removed, and both were used by Xpdf
[15:33] <tsdgeos> yes
[15:33] <mitya57> *by Ubuntu's Xpdf
[15:34] <tsdgeos> xpdf should not be using poppler
[15:34] <mitya57> tsdgeos: I think this is the only way to have it maintained, as upstream seems dead
[15:34] <tsdgeos> mitya57: it's not dead, just veeeeeeeeeeery slow on releases
[15:35] <tsdgeos> mitya57: anyway, if you are patching xpdf to use poppler, you may as well patch xpdf and add the functions poppler removed
[15:36] <mitya57> tsdgeos: those functions are there, but debian/rules prepends "pkg-config --cflags poppler" to build args, so it tries to use Poppler's headers
[15:48]  * Laney watches kenvandine's epic fight with PS Jenkins bot
[15:48] <kenvandine> indeed
[15:49] <kenvandine> it says xvfb-run failed to start
[15:49] <kenvandine> that can't be because of laney's branch :)
[15:50] <Laney> you'd hope so :P
[16:03] <mitya57> seb128: back?
[16:07] <mitya57> bad /me. 43min != 1h
[16:15] <kenvandine> Laney, i'm at a loss... tests run fine in pbuilder but not in jenkins anymore... grrrr
[16:15] <kenvandine> Laney i guess i need to summon the jenkins masters :)
[16:16] <Laney> bah!
[16:16] <Laney> I assume it's going to affect more than just this project though
[16:17] <kenvandine> yeah... :/
[16:18] <kenvandine> it's worked fine for months...
[16:19] <kenvandine> fginther, do you have any ideas why suddenly running tests that use xvfb-run in jenkins fails?
[16:19] <kenvandine> xvfb-run: error: Xvfb failed to start
[16:19] <kenvandine> is the error
[16:21] <kenvandine> fginther, it's autolanding for the friends stack that started to fail, which we did just change the ci_defaults from raring to saucy
[16:25] <fginther> kenvandine, hmmm, perhaps there's something broken in saucy?
[16:26] <fginther> kenvandine, we can try a few tests with raring and comparing the results
[16:26] <kenvandine> works in pbuilder
[16:26] <kenvandine> for saucy
[16:26] <kenvandine> i have no idea what to try next...
[16:29] <seb128> mitya57, back
[16:30] <mitya57> seb128: do you think we can do what tsdgeos says?
[16:30] <mitya57> (drop all poppler-related patches and build without poppler)
[16:31] <mhr3> kenvandine, do you run xvfb-run with -a?
[16:31] <mitya57> otherwise I'll give you another patch that copies makePathAbsolute to XPDFViewer.cc
[16:31] <seb128> mitya57, what did he suggest?
[16:31] <kenvandine> mhr3, nope
 well, don't break xpdf then :D
 if i was xpdf author i'd complain to people packaging something they call xpdf but is not, but obviously i'm not the xpdf author :D
[16:32] <mhr3> kenvandine, you should :)
[16:32] <seb128> mitya57, I would prefer to use copy those functions of that works
[16:32] <mitya57> ok
[16:32] <kenvandine> mhr3, good point :)
[16:32] <fginther> kenvandine, I'll look into it, maybe there is something wrong on the host
[16:32] <kenvandine> but it has always worked
[16:32] <seb128> mitya57, or check with the security team, the reason we made xpdf use poppler was easier security maintenance since xpdf doesn't keep on top of their issues
[16:33] <seb128> mitya57, but for what I'm concerned we could stop maintaining xpdf or drop it from the archive
[16:33] <seb128> it was important 10 years ago but we got some better viewers since
[16:34] <fginther> kenvandine, we could be running into port resource issues. I'll take a look after lunch
[16:34] <kenvandine> fginther, thx
[16:34] <kenvandine> i'll give it a try with -a too
[16:38] <seb128> Sweetshark, grararr, libreoffice failed to build with
[16:38] <seb128> "Checking correctness of source dependencies...
[16:38] <seb128> After installing, the following source dependencies are still unsatisfied:
[16:38] <seb128> libhsqldb-java(inst 2.2.9+dfsg-3ubuntu1 >= conflicted 1.8.1~)"
[16:43] <mitya57> seb128: branch updated, please try to build this
[16:43] <mitya57> (but +1 to dropping xpdf completely)
[16:44] <mitya57> seb128: will look at gdcm tomorrow
[16:44] <seb128> mitya57, thanks, no hurry we will be blocked on libreoffice for a while it seems
[16:44] <seb128> cf what I just copied
[16:44] <Laney> err
[16:44] <seb128> well "while"
[16:45] <seb128> need Sweetshark to be back (today is an holiday for him) and then we will need at least a day for the builds
[16:45] <Laney> does it really Build-Conflict on a version which is implied by the Build-Depends?
[16:45] <seb128> mitya57, http://paste.ubuntu.com/5717337/
[16:45] <Laney> I don't understand how that ever built if so
[16:45] <Laney> must be misreading
[16:46] <seb128> Laney, that's the diff of that upload: https://launchpadlibrarian.net/141103518/libreoffice_1%3A4.0.2-0ubuntu1_1%3A4.0.2-0ubuntu2.diff.gz
[16:46] <Laney> ah, no, 1.8.1 vs 1.8.0.10
[16:46] <Laney> so as soon as that package was upgraded LO was broken
[16:46] <Laney> still ...
[16:46] <seb128> it built in a ppa
[16:46] <seb128> I don't get it
[16:47] <Laney> see https://launchpad.net/ubuntu/+source/hsqldb
[16:47] <mitya57> seb128: so let's wait until tomorrow when I'll be at my saucy machine
[16:47] <seb128> mitya57, ok
[16:47] <seb128> Laney, shrug, I guess the ppa doesn't use proposed :/
[16:47] <seb128> nor do I
[16:47] <Laney> apparently not, it's not the default
[16:48] <seb128> so we didn't see that before upload
[16:48] <seb128> "fun"
[16:48] <mitya57> I wanted to check if xpdf is popular in Ubuntu and noticed that popcon.ubuntu.com is still not working :/
[16:48] <Laney> "For safety, add a build-conflicts against libhsqldb-java (>> 1.8.1~)"
[16:48] <Laney> that's quite some safety
[16:49] <seb128> it's protecting you to have a chance to have libreoffice to ever build
[16:49] <seb128> :p
[16:49] <Laney> saving buildd time :P
[16:54] <seb128> Laney, http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commitdiff;h=bf27df32a74473a045605a8e7b02b5586a6ebcd8
[16:54] <Laney> yeah
[16:54] <seb128> it seems like that's a buggy conflicts and should just be dropped
[16:55] <seb128> I think I will drop the
[16:55] <seb128> ifneq (,$(filter hsqldb, $(SYSTEM_STUFF)))
[16:56] <seb128>         perl -pi -e "s/(Build-Conflicts: .*)/\1,libhsqldb-java (>= $(HSQLDB_TOONEWVER)~),/" debian/control
[16:56] <seb128> endif
[16:56] <jbicha> seb128: howdy
[16:56] <seb128> jbicha, hey
[16:57] <jbicha> seb128: is there anything else I should do to coordinate handling bug 1185869 ?
[16:57] <ubot2> Launchpad bug 1185869 in gnome-shell (Ubuntu) "Update gnome-shell to 3.8" [Undecided,New] https://launchpad.net/bugs/1185869
[16:58] <Laney> does it work with the new eds?
[16:59] <Laney> seb128: Digging slightly it seems that the modified build-dep is because _rene_ uploaded a forked source package of the old version of hsqldb
[16:59] <jbicha> Laney: yes as we've had gnome-shell 3.8 in the staging ppa with e-d-s 3.8 for a while
[16:59] <Laney> so it keeps using the old series
[16:59] <mitya57> jbicha: are you going to update gsettings-desktop-schemas also?
[16:59] <Sweetshark> seb128: heh, java guys doing updates in proposed, creating pain? welcome to my world.
[16:59] <Laney> we might want to upload that thing too
[17:00] <Laney> that's hsqldb1.8.0 source package
[17:00] <jbicha> mitya57: yes, there's two schemas that were dropped that we're patching back in since we're still using them
[17:01] <Laney> where does the transition come from?
[17:02] <Laney> it might be safer to wait until after eds to avoid entangling things
[17:02] <seb128> jbicha, nothing special, can gsettings-desktop-schemas be uploaded first or does it break things?
[17:02] <mitya57> jbicha: this will break metacity, please commit the patch from gnome #697801 then (at least upstream, and I'll then cherry-pick it)
[17:02] <ubot2> Gnome bug 697801 in general "Alt+Tab doesn't work in Metacity with gsettings-desktop-schemas 3.8" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=697801
[17:03] <seb128> Sweetshark, what do you recommend doing? just dropping the lines I pointed
[17:03] <mitya57> (ther first one, second is not too necessary)
[17:03] <seb128> Laney, you seem to have a better grasp that me in that libreoffice issue ... what do you recommend doing
[17:03] <jbicha> Debian has the schemas break gnome-shell << 3.7.90 because of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701619
[17:03] <ubot2> Debian bug 701619 in gsettings-desktop-schemas "gsettings-desktop-schemas: Updating gnome-themes-standard to 3.7.90 broke switching windows in gnome-shell 3.6" [Normal,Fixed]
[17:03] <Laney> I think we have to take that hsqldb1.8.0 package
[17:03] <seb128> (sorry just back from exercice and catching up with backlog)
[17:03] <mitya57> jbicha: I know, as I'm the reporter :)
[17:03] <jbicha> but I can drop that change as we know that gnome-shell is broken anyway if we want to just update the schemas separately
[17:04] <Sweetshark> seb128: mom, checking git blame for those lines.
[17:04] <seb128> Laney, will that fix the conflict? how so?
[17:04] <Laney> it will not, but if you look at the LO commit he updated the BD too to use a package from it
[17:04] <Laney> I assume because the new series doesn't work
[17:04] <seb128> jbicha, no, that's ok, I just like to have things landing in chunks when possible rather than all together
[17:04] <seb128> easier for testing and debugging
[17:04] <Sweetshark> seb128: do you know why that hsqldb stuff is stuck so long in proposed?
[17:05] <Laney> let me go and ask jamespage if he'll do the update
[17:05] <Sweetshark> seb128: because there might be extra fun in for us, if building lo against it doesnt run against the 1.8 in saucy (non-proposed) ...
[17:05] <Laney> it's a transition
[17:06] <seb128> Sweetshark, if I read http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt  correctly, because libreoffice needs to transition to use the new one :p
[17:06] <seb128> skipped: hsqldb (538 <- 132)
[17:06] <seb128>     got: 91+0: i-91
[17:06] <seb128>     * i386: jodconverter, libjodconverter-java, libreoffice, libreoffice-base, libreoffice-report-builder, libreoffice-report-builder-bin, libreoffice-subsequentcheckbase
[17:06] <jbicha> mitya57: I can sponsor metacity for you
[17:07] <Laney> pinged jamespage in #ubuntu-devel
[17:07] <seb128> thanks
[17:08] <mitya57> There's some chance I get MOTU permissions on Monday, so that won't be needed
[17:08] <Laney> could probably manage to do it myself tomorrow though if necessary
[17:08] <mitya57> ah, no, it's in main, probably because compiz uses libmetacity
[17:09] <mitya57> jbicha: so, "sponsor" it upstream please :)
[17:14] <mitya57> jbicha: thanks (though you decided to commit the second one also for some reason)
[17:14] <jbicha> mitya57: does it need to be reverted?
[17:15] <mitya57> jbicha: no, but it's pointless for me
[17:15] <Sweetshark> seb128: http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commitdiff;h=6cc45869;hp=c7d7b35581a0d730a20684b02a28e5605ff99eea <- seemed to have been a better-be-safe-than-sorry commit, waaay back then.
[17:15] <mitya57> anyway Florian requested it, so let's keep it
[17:16] <seb128> Sweetshark, Laney, what's the issue if we just drop that conflicts?
[17:16] <jbicha> Laney: ok I'll do the transition after the e-d-s one is finished
[17:17] <Laney> seb128: I think the issue is that it doesn't work against hsqldb 2
[17:17] <Laney> otherwise _rene_ wouldn't have bothered to fork the package
[17:17] <Laney> that's just a guess though
[17:19] <Sweetshark> seb128: upstream LibreOffice configure checks hard on hsqlsb >= 1.8.0.9 and < 1.8.1 even with the upcoming LibreOffice 4.1.x.
[17:19] <Laney> It's OK, I'm preparing the upload
[17:20] <Laney> so we'll just be able to take the renamed build-dep
[17:20] <Sweetshark> seb128: How can such an update land in -proposed, and I havent even heard about that? That completely breaks LibreOffice Base -- hard, I assume.
[17:21] <seb128> Sweetshark, that's why it didn't go out of proposed :p
[17:21] <seb128> Sweetshark, I guess jamespages didn't notice it would break libreoffice
[17:21] <seb128> it's not obvious from outside
[17:22] <Laney> it's a good idea to make your archive PPAs and distro chroots build against -proposed to notice this kind of thing early
[17:24] <Sweetshark> seb128: Long term, there are these options: a/ kill that update with fire (I like this option) b/ patch out the tests in LO configure and hope it works a little bit (I hate this option) c/ use the internal copy of hsqldb in libreoffice (meh, break all tries to use system integration, or people using the system hsqldb to open LO Base files)
[17:25] <seb128> Sweetshark, well, it seems like debian/rene reuploaded the old version of hsqlsb as a separate source (what Laney is doing for us)
[17:25] <seb128> but I'm not sure if that's any better than using the libreoffice copy...
[17:26] <Sweetshark> Laney: I usually do so that on the last build before upload, I wont do it for every build as that would kill build time when you depend on 1/3 of main ....
[17:26] <xnox> Sweetshark: i did point out updated hsqlsb in saucy-proposed to you a few times.... ever since I was poking it after holiday =)
[17:27] <xnox> but it was hard to notice with all the other things breaking libreoffice build in saucy already.
[17:30] <Sweetshark> seb128: so, to resolve this emergency, using the internal copy is surely the quickest way. We still should seriously discuss if that hsqldb thing should go in saucy for real though ...
[17:31]  * didrocks waves good evening
[17:31] <Laney> It's fine, I've got the package upload ready so it's just a matter of updating LO to use the new package name (that git patch)
[17:32] <seb128> Laney, want to do that?
[17:32] <Laney> yes, just waiting for cjwatson to reply to me
[17:32] <seb128> Laney, great, thanks
[17:32] <Laney> he was debugging why the autosyncer didn't get it
[17:32] <seb128> it can wait tomorrow
[17:32] <seb128> though if we upload today we might win half a day of build time
[17:35] <seb128> Sweetshark, btw I hate libreoffice, I had to make 6GB of free space to run debuild -S and it maxed out io on my ssd for over 5 minutes to pack the source
[17:36] <Sweetshark> xnox: If I manually check every of the 1000 LibreOffice deps on every update of them, we would never see a release, so without a big fat "this will break stuff" (read: at least an email) warning, it flies under the radar.
[17:37] <Sweetshark> seb128: heh, 6GB? why dont you pack in RAM? its faster and with 32GB you will barely notice ... ;P
[17:38] <xnox> Sweetshark: sure. but at least with hsqlsb case, libreoffice had tight build-conflicts which are easy to check for statically =) (without actually building libreoffice)
[17:38] <seb128> lol
[17:38] <seb128> Sweetshark, I'm 28GB short of that bar :p
[17:42] <Sweetshark> xnox: that yields quite a lot false positives though, as the update to a new LO major (4.0->4.1) solves a lot of those (and makes _me_ need some updates in dependencies). Fixing Deps for 4.0, when we aim for 4.1 is thus a lot of wasted ressources. Yeah, I know 'rolling releases' yaddayadda ;) -- LibreOffice sure isnt rolling wrt its dependencies ...
[17:43] <seb128> some days it seems like libreoffice is more complicated that the rest of the desktop united :p
[17:43] <czajkowski> seb128: +1
[17:43] <czajkowski> some days...:)
[18:11] <mhr3> seb128, we still support powerpc?
[18:36] <asac> this facebook online accounts feature ... is that officially buggy?
[18:36] <asac> it seems to annoy me more than it does :)
[18:37] <asac> it seems to open browser for authentication regularly without being asked
[18:37] <asac> and then if i log in, i get a SECURITY WARNING PAGE
[18:37] <asac> "Success
[18:37] <asac> SECURITY WARNING: Please treat the URL above as you would your password and do not share it with anyone.
[18:37] <asac> "
[18:37] <asac> looks buggy, but sounds like success. but in fact it didnt really succeed :)
[18:38] <kenvandine> asac, yeah... facebook is doing something evil
[18:38] <asac> online accuonts still offline and opens browser again in a couple of minutes :)
[18:38] <kenvandine> redirects to a non-ssl page during login
[18:38] <kenvandine> https://developers.facebook.com/bugs/449221825171392
[18:38] <kenvandine> is the bug
[18:39] <asac> is that the only way to do this auth
[18:39] <asac> >
[18:39] <asac> ?
[18:39] <kenvandine> yes
[18:39] <asac> maybe we use one of a few variants
[18:39] <kenvandine> the only way we could work around it is to allow non-ssl
[18:39] <asac> and the one we use is something they disregard
[18:39] <kenvandine> which is not cool...
[18:39] <asac> ok... so its the official way to do it according to their api docs?
[18:39] <kenvandine> yes
[18:39] <asac> is that  risk for all applications that auth?
[18:39] <kenvandine> they've fixed it before
[18:40] <kenvandine> and it regressed
[18:40] <asac> why doesnt this go out to vendor sec etc. as a big deadl?
[18:40] <kenvandine> apparently
[18:40] <asac> feels like it might mean that now all facebook apps
[18:40] <asac> from 3rd party might reveal secrets that might allow folks to continue the session
[18:40] <asac> in clear text
[18:40] <kenvandine> right
[18:40] <asac> jdstrand: ^^
[18:40] <asac> jdstrand: is there a real risk?
[18:40] <kenvandine> jdstrand, this is why you wanted to enforce ssl :)
[18:41] <asac> if so, why hasn't this getting thorough news coverage :)
[18:41] <kenvandine> last time it happened they fixed it in just a couple days
[18:41] <kenvandine> not so responsive this time
[18:41] <sarnold> perhaps no on accesses facebook through apis?
[18:41] <asac> i am sure thats not the case
[18:41] <kenvandine> yeah, lots of people do
[18:41] <asac> that api is prominently documented
[18:42] <sarnold> asac: and if you're going to raise a stink, full-disclosure is probably the better ranting ground :)
[18:42] <asac> and its the most important web service in the world
[18:42] <asac> there must be loads of users :)
[18:42] <sarnold> so it's not just us? :)
[18:42] <kenvandine> sarnold, nope... can't be
[18:42] <asac> thats whaty i found interesting to hear
[18:42] <kenvandine> but we enforce ssl
[18:42] <asac> that there is a real sniffing risk
[18:42] <kenvandine> so it fails
[18:42] <asac> and lots of people use it ... still its not getting a big hype :)
[18:42] <asac> so i hoped we use a weird way of doing things
[18:43] <kenvandine> i think most people just don't notice the http redirect
[18:43] <kenvandine> it then gets another redirect to https
[18:43] <kenvandine> but there is one insecure redirect in the middle
[18:44] <asac> and that redirect really has private info?
[18:44] <kenvandine> during the security review this was raised as a concern and they made sure we fail on non-ssl connections
[18:44] <asac> guess so :)
[18:44] <asac> hmm
[18:44] <asac> i dont think we should just make our users believe
[18:44] <asac> that its a bug in our system
[18:44] <asac> if we break stuff like that we might want to replace it with a dialog telling people that facebook was turned off because its inseure :)|
[18:45] <asac> anyway... off ... thanks for explaining, will probably get reminded to talk more soon anyway :)
[18:45] <kenvandine> good idea
[18:45] <kenvandine> :)
[18:46] <seb128> mhr3, hey, powerpc: yes
[18:46] <jdstrand> hrmmm
[18:46] <jdstrand> I thought that https was supposed to be officially supported by them? I seem to remember them blogging about it or something
[18:48] <kenvandine> jdstrand, it is
[18:48] <kenvandine> they broke something in their login process
[18:48] <seb128> jdstrand, it's a bug, they fixed it already once but it's back
[18:48] <kenvandine> it happened a few months ago too
[18:48] <jdstrand> that sucks
[18:48] <kenvandine> and they fixed it
[18:48] <kenvandine> and now regressed
[18:48] <jdstrand> https://developers.facebook.com/bugs/449221825171392
[18:48] <jdstrand> that is a big bug number :)
[18:48] <kenvandine> hehe
[19:11] <fginther> kenvandine, xvfb issue appears to be resolved for now. The problem was that the build of another package failed, but the xvfb process was left hung (and therefore held on to port 99)
[19:12] <kenvandine> whew
[19:12] <kenvandine> thanks fginther!
[19:12] <fginther> kenvandine, no problem. it is likely to happen again someday, test should use -a when possible
[19:13] <kenvandine> fginther, i added that
[19:14] <kenvandine> but that branch failed too...
[19:14] <kenvandine> CI did rather
[19:14] <fginther> hmmm
[19:14] <kenvandine> different error
[19:14] <kenvandine> aborted after satisfy depends
[19:38] <rostam> Hi the pthread library in Ubuntu 12.04 is located at /usr/lib/x86_64-linux  for 64 bit and /usr/lib/i386-linux-gnu for 32 bit.   I am creating multi-threaded application, how could I write a generic linker command so it link to appropriate library? thx
[19:39] <sarnold> rostam: wouldn't that be gcc ... -lpthread  ?
[19:40] <rostam> sarnold: yes but the -L<path to library directory>  is my question?
[19:41] <sarnold> rostam: ah. I've never needed that, so never looked. heh.
[19:41] <sarnold> sorry :)