[00:46] <stokachu> cjwatson: would you be able to weigh in on bug 1172101 when you have time
[00:46] <stokachu> cjwatson: i keep thinking there was a reason why this wasn't done yet
[00:53] <infinity> stokachu: I believe that should Just Work, since d-i images are built with overwriting turned on, so that'll just overwrite the busybox-provided wget.
[00:53] <infinity> stokachu: But simple enough to test.  Grab the d-i sources, build your new wget, toss the udeb in extra-udebs, and build d-i to see what you get.
[00:54] <stokachu> infinity: ah ok, i wasn't sure if there was a political reason for not doing it
[00:54] <infinity> s/extra-udebs/localudebs/
[00:54] <stokachu> ill do some tests to make sure it works
[00:54] <infinity> I can't think of any political reasons against, since we don't include wget in our default images at all.
[00:54] <stokachu> cool sounds good, thanks man
[00:54] <infinity> Now, including wget.udeb in the default images would be a different discussion.
[05:33] <pitti> Good morning
[06:11] <pitti> xnox: did you see anything odd with the new udev on your setup?
[06:33] <geser> could someone do a give-back of file-roller on i386 and amd64 please? looks like LP lost track of those builds (no build log available)
[07:00] <pitti> hmm
[07:00] <pitti> No builds for 'file-roller' found in the Saucy release - it may have been built in a former release.
[07:00] <pitti> oh, -proposed
[07:01] <pitti> geser: done
[07:02] <geser> thanks
[07:06] <mlankhorst> does pbuilder allow you to keep the chroot if a build fails, so you can inspect what happens?
[07:07] <geser> mlankhorst: sort of, you can have a hook which drops you into a shell to investigate
[07:08] <geser> see /usr/share/doc/pbuilder/examples/C10shell
[07:08] <mlankhorst> ah
[07:08] <mlankhorst> cd /tmp/buildd/*/debian/..
[07:08] <mlankhorst> that's actually quite smart..
[07:18] <Mirv> mitya57: hi! thanks for the qtchooser sync! I've a plan now for the saucy uploads, see http://pastebin.ubuntu.com/5666894/
[07:20] <mitya57> Mirv: what does "synced but pkg transition" mean?
[07:21] <Mirv> mitya57: means that the packaging is in sync with Debian, but Ubuntu has an additional package transition from raring that needs eg Replaces:
[07:21] <Mirv> since Debian never had 5.0.1
[07:22] <mitya57> OK, sounds nice. Please subscribe me to the sync requests if you'll be doing any
[07:23] <Mirv> mitya57: ok, I will, unless some coredev helps me in doing syncs directly
[07:26] <mitya57> Mirv: by the way, qtdoc is currently useless, as documentation should be built in each module
[07:26] <mitya57> I'm planning to look at qtbase documentation when I have some time
[07:27] <Mirv> mitya57: I noticed that it indeed gives quite a skeleton of documentation out
[07:27] <mitya57> yes, but only a skeleton
[07:27] <Mirv> so not worth that much, even though with that Qt Creator gets Qt5 documentation topic
[07:27] <Mirv> there are some examples et cetera
[07:27] <Mirv> but no API docs
[07:29] <mitya57> API docs is the most useful thing :)
[07:46] <geser> infinity: as you are TIL for vim: can I grab the vim merge from you or do you plan to do it yourself?
[07:47] <tjaalton> the manual partitioner of the installer has no option to resize ntfs volumes?
[07:47] <tjaalton> saucy installer doesn't seem to recognize win8
[08:07] <infinity> geser: I'll pick it up.  I'd prefer to retain TIL on it.
[08:07] <infinity> @pilot out
[08:07] <seb128> @pilot out
[08:07] <seb128> ups, forgot that yesterday
[08:11] <Laney> mfisch: pretty sure it's supposed to be 14 & 19 UTC currently
[08:12] <Laney> tumbleweed: confirm/deny?
[08:13] <geser> infinity: ok, I just noticed that we probably can drop the delta to add liblaunchpad-integration to the help menu as liblaunchpad-integration got removed since raring
[08:16] <Laney> ah, came up on the ML
[08:43] <zequence> diwic: I linked two branches to this bug report https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1163638
[08:43] <zequence> diwic: I've test built them, so they seem to work ok
[08:43] <zequence> diwic: Would you mind looking at if the patches are well applied?
[08:44] <zequence> ..and documented
[08:44] <zequence> lp:~zequence/+junk/pulseaudio.precise
[08:44] <zequence>  lp:~zequence/+junk/pulseaudio.quantal
[08:45] <diwic> zequence, ok
[08:47] <diwic> zequence, have you also tested the result to make sure the handover actually works now?
[08:48] <zequence> diwic: Only on quantal, and only on a virtual install. I need to do more testing
[08:49] <zequence> but, initially, it seems to work the way it's supposed to
[08:49] <diwic> zequence, nitpick: "Let's pulseaudio let go" <- bad wording in changelog
[08:49] <zequence> Ah, I think I wrote them one too many times :)
[08:51] <diwic> zequence, also on SRUs I think it's always .x, i e not 1:2.1-0ubuntu5 but 1:2.1-0ubuntu4.1
[08:51] <diwic> zequence, it's correct in the precise one but not the quantal one
[08:51] <zequence> ok
[08:55] <zequence> diwic: If that's all you can think of, then I'll happily redo both branches with those changes then
[08:55] <diwic> zequence, that and proper testing
[08:55] <zequence> jack people will be thoroughly happy once the fix is out
[08:56] <zequence> it's one of the most common problems users face, so should make some channels a lot more silent for a while :)
[08:56] <diwic> zequence, sounds good :-)
[09:37] <Laney> bad ircd
[09:46] <rbasak> If in Launchpad an Ubuntu package does not have a SF upstream linked as an upstream project, am I supposed to "register" this in Launchpad in order to make upstream bug tracker functionality work properly? Or is there some other way to do it? It's not clear to me whether "registration" in LP is necessary (whatever that means), or there's some other way to "link" the upstream that isn't hosted on LP.
[09:49]  * rbasak asks in #launchpad
[09:50] <tumbleweed> you can just put the bug URL in the report, and it'll track it, but it can't be added as a task.
[09:51] <rbasak> Yeah, but it would be nice to know how to do it "properly". I've left bugs like that before, so it would be nice to learn how to do it right this time round.
[09:53] <diwic> uhm, I seem to have a directory /home/<user>/.local/share/sounds without execute permissions, so I can't view the directory. This is weird. Any of you running saucy and can do a quick check if you have that too?
[09:54] <diwic> I have no idea who could have created it
[09:54] <diwic> i e what program
[09:55] <geser> diwic: same here: drw-------
[09:56] <diwic> geser, thanks. Do you have any idea of how one can figure out how it got there? It's causing libcanberra to malfunction
[09:57] <seb128> diwic, drwxr-xr-x for me
[09:57] <seb128> created on april 19
[09:58] <diwic> seb128, any contents in it?
[10:00] <seb128> no, empty
[10:02] <geser> my directory got last changed/modified on 2013-05-15
[10:02] <seb128> diwic, I can confirm, it's getting created on login if it doesn't exist and with the permission rw-
[10:02] <seb128> diwic, I just tried with a test user, rm it, log in, the directory is created before you start anything
[10:03] <diwic> seb128, okay, thanks, is there a smart way to figure out what process creates it?
[10:04] <seb128> diwic, not that I know about
[10:05] <cjwatson> strace -f or systemtap or something
[10:05] <seb128> cjwatson, strace what process?
[10:05] <seb128> something on login create that dir, the goal is to figure out what process something is ;-)
[10:05] <cjwatson> strace -f the display manager :)
[10:05] <cjwatson> (not from X ...)
[10:06] <cjwatson> well, maybe that doesn't work with upstart user sessions
[10:06] <geser> seb128, diwic: could it be the last upload of gnome-settings-daemon? the diff mentions a "sounds" directory
[10:06] <cjwatson> something like systemtap should be able to do it, not that I really know how to drive it yet
[10:06] <seb128> geser, I was looking into that yes
[10:06] <diwic> geser, thanks, will have a look
[10:06] <rbasak> The answer was to do the registration. Looks like the upstream project must get an entry in the LP namespace, and then the Ubuntu package can be linked to it and all the nice integration then works.
[10:07] <seb128> geser, diwic:
[10:07] <seb128> debian/patches/git_sound_not_polling.patch:+        if (g_mkdir_with_parents(p, 0600) == 0)
[10:07] <diwic> yep
[10:07] <seb128> geser, diwic: https://git.gnome.org/browse/gnome-settings-daemon/commit/?h=gnome-3-6&id=75b8bae1e71199ea7b19769be1c4f423722dffc7
[10:07] <diwic> that must be it
[10:07] <seb128> is the commit I backported
[10:08] <seb128> that bug comment #2 describe the issue
[10:09] <Laney> s/6/7/ probably
[10:09] <seb128> seems like they screwed that backport
[10:09] <seb128> https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/sound/gsd-sound-manager.c?h=gnome-3-6
[10:09] <seb128> https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/sound/gsd-sound-manager.c?h=gnome-3-8
[10:09] <seb128> has 700
[10:09] <seb128> I will upload a fix and report it upstream
[10:09] <seb128> diwic, do you have a lp bug number for the issue?
[10:09] <Laney> https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=b97a62f56d7f3187c9ab516c8f3c2aa6785665c6
[10:09] <Laney> just needs to be push to 3-6 too I guess
[10:10] <Laney> pushedd
[10:10] <diwic> seb128, no, I was just testing a new version of PulseAudio and discovered this
[10:10] <Laney> argh
[10:10] <seb128> Laney, want to take care of it?
[10:10] <seb128> Laney, upload/ping upstream?
[10:11] <diwic> upstream fixed it with https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=b97a62f56d7f3187c9ab516c8f3c2aa6785665c6
[10:11] <Laney> https://bugzilla.gnome.org/show_bug.cgi?id=694134#c6
[10:11] <seb128> diwic, Laney snapped you ;-)
[10:12] <diwic> seb128, Laney thanks for fixing it. The result is otherwise that testing speakers in gnome sound settings does not work.
[10:13] <seb128> diwic, the sound panel is also unhappy and goes in an infine loop trying to update the timestamp if you try to change a sound effect
[10:13] <Laney> I can upload that cherry-pick, but perhaps we should take care to fix existing broken ones too?
[10:13] <seb128> Laney, it's only in saucy for people who didn't have the directory before and it has been in there for less than a week
[10:14] <seb128> Laney, not sure how many users that set includes ... I guess it wouldn't hurt to add a temporary chmod call to that path in saucy though
[10:15] <Laney> you could probably do something with g_access/g_chmod without too much difficulty
[10:15] <Laney> will do it soon
[10:15] <seb128> right
[10:16] <seb128> Laney, you are on it then? just ping if you need a peer review or something
[10:16] <Laney> sure, cheers
[10:29] <cjwatson> seb128: looks like c2esp could be synced from experimental?
[10:29] <cjwatson> infinity: would be nice to have a debhelper merge when you get a chance
[10:30] <seb128> cjwatson, it can yes ... are you syncing it or should I?
[10:32] <cjwatson> seb128: doesn't really matter I guess, doing now
[10:32] <seb128> cjwatson, right, I just didn't want to dup the action, thanks ;-)
[10:32] <seb128> well I guess whoever would have tried second would just have got a "nothing to sync"
[11:27] <Laney> diwic: uploaded gnome-settings-daemon, thanks for reporting!
[11:33] <seb128> tsdgeos, hey, are you on ubuntu-devel list? tkamppeter emailed it about mupdf/poppler
[12:00] <lool> seb128, tsdgeos: just a heads up: you might want to followup on the thread for the PDF rendering backend for Touch printing stack that Till just started on -devel; e.g. maintenance wise, quality wise etc.
[12:00] <lool> seb128: ah I saw you've seen it already
[12:01] <lool> and pinged tsdgeos :-)
[12:01]  * lool is so half-an-hour late
[12:01] <seb128> lool, yeah, thanks, I'm planning also to follow with "do we have any benchmark showing the performance difference?", because so far it seems it's marketing speech from upstream without facts check
[12:02] <lool> seb128: you mean the lightweightness claims?  yeah
[12:02] <lool> I wonder whether we could throw a bunch of PDFs at both and compare rendering too
[12:02] <lool> (or crashes  :-)
[12:08] <diwic> Laney, thanks for the swift handling :-)
[12:08] <zyga> hi, is jockey supposed to work with precise and -lts-{quantal,raring} kernel?
[12:20] <tvoss> pmcgowan, ping
[12:20] <pmcgowan> hey tvoss
[12:46] <rbasak> What's the current best practice for the pocket in debian/changelog for an SRU? Eg. precise, precise-proposed or precise-updates? All work now, right?
[12:47] <cjwatson> I wouldn't use -updates.  Either precise or precise-proposed is fine.  I've been drifting towards the former.
[12:47] <pitti> rbasak: no, not precise-updates
[12:47] <pitti> rbasak: as for precise vs precise-proposed, they behave the same now
[12:47] <rbasak> OK. I'll use just precise then. Thanks!
[12:47] <rbasak> (precise-proposed always felt a bit wrong as it doesn't actually end up there)
[12:49] <pitti> strictly speaking it also doesn't land in "precise", but in "precise-updates"; but it eliminates the difference between pre- and post-release uploads, so it's nice
[12:51] <cjwatson> precise might either refer to the suite (== release pocket) or to the series as a whole, so that part doesn't bother me
[13:30] <tsdgeos> tkamppeter: why on -devel and not in 	ubuntu-phone ?
[13:30] <ogra_> or both (since it affects both)
[13:31] <tsdgeos> lool: tsdgeos_work@xps:/home/tsdgeos/okularfiles/pdf$ ls -l *.pdf | wc -l
[13:31] <tsdgeos> 1404
[13:33] <tsdgeos> "is the only free software which allows filling and saving PDF form"
[13:34] <tsdgeos> oh really?
[13:34]  * tsdgeos looks at poppler
[13:35] <tsdgeos> ogra_: can you forward me the original email so i can answer to it? (me was not subscribed to -devel) (me hides)
[13:37] <ogra_> tsdgeos, done ... its also in the archives on lists.ubuntu.com indeed
[13:39] <tsdgeos> ogra_: sure, i've read it there
[13:39] <ogra_> ah
[13:40] <tsdgeos> but for a proper answer i need the mail on my mail client
[13:40] <tsdgeos> so headers match, etc
[13:40] <ogra_> hmm, i forwarded as attachment ... might not help ...
[13:41] <tsdgeos> let's see :)
[13:41] <ogra_> bounced now
[13:41] <ogra_> that should have proper headers
[13:45] <tsdgeos> ogra_: second forward better, tx
[14:16] <lool> tsdgeos: this is mainly a convergence topic as printing isn't top priority for touch phones/tablets; -devel seems fine to discuss common topics
[14:19] <tsdgeos> ok, mail subject is "Ubuntu Touch:" didn't mention much on convergence on the content either
[14:29] <tkamppeter> tsdgeos, the missing capability of the Ubuntu desktop to fill forms is then probably caused by the GUI frontends, like evince.
[14:35] <tsdgeos> no clue about evince, in okular we save forms, of course there are bugs, all software has bugs unfortunately :/
[14:36] <sladen> tkamppeter: I'll reply later.  I've been using mupdf for rendering for the last decade, as it produces better results.  It is GPL, whether that's an issue having it as part of the API used by end-user apps
[14:40] <tsdgeos> sladen: do you have any hard data for taht other than a feeling?
[14:40] <tsdgeos> i'd like to see it :-)
[14:40] <tsdgeos> lol, it's cool how pdf.js tells me that http://www.acquerra.com.au/poppler/img_0.pdf won't prbably work when opening it :D
[14:42] <sladen> tsdgeos: works for me
[14:42] <tsdgeos> what works?
[14:43] <sladen> tsdgeos: http://www.acquerra.com.au/poppler/img_0.pdf  works for me [in Firefox, with pdf.js]
[14:43] <tsdgeos> you don't get a nice warning at the top?
[14:43] <tsdgeos> are you on ff21?
[14:44] <tsdgeos> do you see the 3 ducks on the right?
[14:48] <sladen> tsdgeos: firefox 20.0+build1-0ubuntu0.12.04.3
[14:49] <tsdgeos> they problably introduced the warning in ff21
[14:53] <sladen> tsdgeos: what is the warning about?  PDF-1.7 or duplicate trailers, or something else?
[14:54] <tsdgeos> sladen: it just says "This document may not be shown properly"
[14:54] <tsdgeos> which is correct
[14:55] <stgraber> stokachu: alright, looking at your bugs now, sorry for the delay
[14:56] <stokachu> stgraber: no worries, thanks for the help
[14:57] <sladen> tsdgeos: seems the version poppler does equally badly (in a different way)
[14:57] <tsdgeos> sladen: works fine here, can you get a screenshot?
[14:58] <sladen> tsdgeos: 0.18.4-1ubuntu3.1  it's old though
[14:58] <tsdgeos> lol
[14:58] <sladen> tsdgeos: so you likely will not care
[14:58] <tsdgeos> no need for a screenshot then
[15:07] <sladen> ~,
[15:09] <tkamppeter> tsdgeos, sladen, which PDF library does ff21 use? Poppler, MuPDF, Ghostscript, or did they write their own from scratch?
[15:09] <tsdgeos> tkamppeter: pdf.js
[15:09] <tkamppeter> tsdgeos, is this a complete PDF interpreter, not using any external library?
[15:10] <tsdgeos> well, it's using firefox
[15:10] <tsdgeos> :D
[15:10] <tsdgeos> that's a quite big "external library"
[15:10] <sladen> tkamppeter: $browser.$canvas implementation
[15:10] <cjwatson> https://mozillalabs.com/en-US/pdfjs/ "without native code assistance"
[15:10] <tkamppeter> tsdgeos, so the Firefox browser contains a complete PDF interpreter/renderer (at least from version 21 on)?
[15:11] <tsdgeos> yes
[15:11] <tsdgeos> it has for a while
[15:11] <tsdgeos> it's not that good
[15:11] <tsdgeos> but they know it
[15:11] <tsdgeos> which is the first step to fixing it
[15:11] <sladen> no, pdf.js (a bunch of ECMAScript) contains a complete interpreter
[15:11] <ogra_> how about chromium (given there are plans to switch to it by default now)
[15:12] <sladen> it simply does   var canvas = document.createElement('canvas');  and then draws into that
[15:12] <tsdgeos> ogra_: chromium has no pdf rendeer
[15:12] <ogra_> right
[15:12] <tsdgeos> chrome has
[15:12] <tsdgeos> but it's not free soft
[15:12] <ogra_> can chromium use the external one
[15:12] <tkamppeter> tsdgeos, and now they think it is reasonably good and so they started to make it be used by default?
[15:12] <tsdgeos> chromium can use pdf.js
[15:12] <tsdgeos> after all it's js :D
[15:12] <ogra_> heh
[15:12] <sladen> ogra_: fire up pdf.js in Chromium...
[15:13] <Laney> I wouldn't say we're at the stage of planning to switch to Chromium yet
[15:13] <tsdgeos> tkamppeter: i don't think it's reasonably good but that's my opinion
[15:13] <Laney> FWIW
[15:19] <sladen> ogra_:  chromium-browser http://mozilla.github.io/pdf.js/web/viewer.html
[15:20] <sladen> ogra_: (and it's faster than in FF)
[15:23] <psusi> cjwatson: just wanted to make sure you did get the parted merge bundle I sent.. I know you're busy but it's been over a week so I thought I'd check...
[15:23] <ogra_> sladen, a wet sponge is faster than FF
[15:26] <barry> bdmurray, ping
[15:29] <Laney> highvoltage: stgraber: I just noticed that edubuntu has some Xsession.d scripts which look as if they may be crufty, FYI
[15:30] <stgraber> Laney: ah?
[15:30] <Laney> maybe, maybe not, but they caught my eye :-)
[15:30] <Laney> 25edubuntu-menus looks curious
[15:32] <bdmurray> barry: hey
[15:33] <stgraber> Laney: is that edubuntu-menus?
[15:34] <Laney> ya
[15:35] <cjwatson> psusi: I did, UDS was in that week
[15:36] <cjwatson> Which means not a lot else happens :)
[15:37] <stgraber> Laney: right, that package is no longer shipped in Edubuntu and was replaced by edubuntu-menueditor+desktop-profile
[15:37] <tkamppeter> tsdgeos, about the filled forms see https://bugzilla.gnome.org/show_bug.cgi?id=695615 and bug 1153517.
[15:37] <barry> bdmurray: hi.  so over in python-dev, we've got some interesting theories about the pyc corruption problem.  question for you.  from the evidence you've seen, are the pyc files permanently corrupted or do they self repair?  i think we're seeing permanent corruptions, such that users have to take active role in fixing things (e.g. remove the .pyc and re-bytecompile it)
[15:37] <Laney> stgraber: can we remove? :-)
[15:37] <barry> bdmurray: can you confirm?
[15:37] <Laney> I'm simply going through all of the Xsession.d scripts ATM so don't have information like that available (OK, I could have checked ...)
[15:38] <stgraber> Laney: yep, I just checked, not seeded and no rdepends (just a conflict with ubuntustudio-menu), I'll kill it from the archive now (haven't tried that new power yet ;))
[15:38] <Laney> phwoar
[15:38] <bdmurray> barry: yes, from the bugs I've read of the people who've sorted it out they had to do it manually
[15:39] <Laney> the other edubuntu one in edubuntu-live looks like it could become a job
[15:39] <barry> bdmurray: okay, thanks.  guido outlined a scenario where the files could be temporarily corrupted, but should self repair.  i think he's on to something, but we still haven't identified the entire problem.  i still think i might have a fix though
[15:41] <stgraber> Laney: 1 package successfully removed.
[15:42] <Laney> *archive catches on fire*
[15:43] <tsdgeos> tkamppeter: i don't do evince development
[15:44] <tsdgeos> but yeah the fact that we major release old of poppler is not good
[15:44] <tsdgeos> besides the fact that we still don't use libopenjpeg
[15:45] <tsdgeos> but i've decided to not fight that battle anymore and accept we don't care about having good supported jpeg2000 rendering in pdf in ubuntu
[15:47] <seb128> tsdgeos, we would ship new poppler if there was
[15:47] <seb128> - a reliable release schedule
[15:47] <tsdgeos> there is
[15:47] <tsdgeos> there as always been
[15:47] <seb128> - upstream stopped breaking ABI and changing soname forcing us into transitions
[15:47] <tsdgeos> we don't break ABI
[15:48] <seb128> well, you bump sonames
[15:48] <tsdgeos> it's people that use headers we don't support
[15:48] <tsdgeos> soname of the internal library
[15:48] <tsdgeos> noone is supposed to use
[15:48] <tsdgeos> yet people use them
[15:48] <seb128> don't make it public then?
[15:48] <tsdgeos> they are not
[15:48] <seb128> if it's not supposed to be used
[15:48] <seb128> they are installed in /usr/lib
[15:48] <seb128> and the .h are installed
[15:48] <tsdgeos> you use the --install-xpdf-headers swtich
[15:49] <seb128> which is an option provided by upstream ;-)
[15:49] <tsdgeos> that clearly says they are unsupported
[15:49] <psusi> cjwatson: ok, I figured, just wanted to be sure the mail wasn't lost
[15:49] <tsdgeos> "Install unsupported xpdf headers."
[15:49] <tsdgeos> you can't blame us if we change unsupported things
[15:49] <tsdgeos> can you?
[15:49] <tsdgeos> well you can
[15:49] <tsdgeos> but not that i care :D
[15:50] <seb128> tsdgeos, reality is
[15:50] <seb128> $ apt-cache rdepends libpoppler28 | wc -l
[15:50] <seb128> 24
[15:50] <tsdgeos> seb128: and please don't spread fud about not reliable schedule
[15:51] <tsdgeos> seb128: as said, that's not our problem
[15:51] <seb128> tsdgeos, I need to find my old email back, some years ago I emailed about that, and somebody from upstream replied my that poppler was not aligned on GNOME or Ubuntu schedule and have no intention to be
[15:51] <seb128> so maybe that was that
[15:51] <tsdgeos> sure
[15:51] <seb128> schedule is reliable but not working for us
[15:51] <tsdgeos> we have no intention to align to gnome or ubuntu
[15:51] <seb128> ok
[15:51] <tsdgeos> why would we do that stupid thing?
[15:51] <seb128> so don't complain that we can't ship the current version ;-)
[15:52] <seb128> because most distros are aligned on those schedules
[15:52] <seb128> and it would make you have more current versions in distros
[15:52] <tsdgeos> :D
[15:52] <tsdgeos> you really believe that?
[15:52] <seb128> yes
[15:52] <tsdgeos> you've been working on ubuntu for too much D:
[15:52] <psusi> aren't we behind by more than one release though?
[15:52] <seb128> psusi, no
[15:52] <seb128> current is 0.22 and we have 0.20
[15:53] <psusi> ahh, ok then
[15:53] <tsdgeos> seb128: yes you are, 13.04 ships something that was released on October
[15:53] <tsdgeos> while 0.22 was released on December
[15:53] <tsdgeos> that seems pretty out of sync to me
[15:53] <seb128> tsdgeos, where can I find the 0.24 schedule?
[15:53] <psusi> tsdgeos: that's not that long ago ;)
[15:53] <tsdgeos> seb128: on the wiki
[15:54] <seb128> "the wiki"
[15:54]  * seb128 goes the.wiki.com
[15:54] <seb128> k, found ity
[15:54] <seb128> http://freedesktop.org/wiki/Software/poppler
[15:54] <tsdgeos> also know "as google"
[15:54] <Nafallo> seb128: wikipedia is likely "the wiki" these days, fwiw :-)
[15:54] <tsdgeos> "poppler 0.24 schedule"
[15:54] <seb128> I guess we could go for 0.24 this time
[15:55] <seb128> do you plan to change your private soname between now and 0.24? (I guess you do)
[15:55] <tsdgeos> you mean 0.22 and 0.24?
[15:55] <tsdgeos> sure
[15:55] <tsdgeos> 0.23.1 already changed it
[15:55] <psusi> hrm... debian is still on 0.18, even in unstable
[15:56] <tsdgeos> and we'll be changing it if needed
[15:56] <Laney> it's probably the most pressing thing causing distros not to want to update as often as they might
[15:57] <tsdgeos> seb128: can you elaborate on the problem of changing the soname? i mean archlinux gets to use newest poppler release all the time, what's the catch in our side?
[15:57] <seb128> tsdgeos, we need to rebuild all rdepends to pick the new soname
[15:57] <seb128> which includes libreoffice
[15:57] <Laney> perhaps it would be profitable to investigate why people are using private things and try to provide public API?
[15:57] <seb128> which doesn't build atm in saucy with the current toolchain
[15:57] <seb128> tsdgeos, so it means we can't even update poppler atm, until we fix libreoffice's build
[15:58] <seb128> the transition will get stucked otherwise
[15:58] <tsdgeos> seb128: ok, so we have bigger problems :D
[15:58] <seb128> well, libreoffice is being worked
[15:58] <tsdgeos> Laney: well, i'm not going to go out there chasing random people
[15:58] <seb128> but while that's not solved, I can't update poppler
[15:58] <tsdgeos> if people feel the need of a stable api we have a nice mailing list where we don't eat people
[15:58] <tsdgeos> most of times :D
[16:00] <psusi> I'm confused... are you saying poppler provides two libs, and one is supposed to be internal and subject to frequent abi breakage?
[16:01] <tsdgeos> we provide 4 libs
[16:01] <tsdgeos> 3 of those we stable api (qt, glib and purec++ apis)
[16:01] <tsdgeos> and the internal one use by those 3
[16:02] <tsdgeos> whose abi/api changes as we see fit
[16:03] <psusi> I see... and people keep going direct to the internal library eh?  I wonder why...
[16:03] <seb128> but which is still installed in /usr/lib
[16:03] <seb128> with a proper soname versioning
[16:03] <seb128> as a public library
[16:03] <seb128> and its name is "libpoppler" not libpoppler-private
[16:04] <tsdgeos> so?
[16:04] <seb128> so people don't see that it's private
[16:04] <seb128> it's just like any other library
[16:04] <psusi> so it's not very obvious that it's private ;)
[16:04] <tsdgeos> you don't get it's headers unless you agree to install unsupported
[16:04] <seb128> so they use it
[16:04] <seb128> well, distro use the configure flag that you provide
[16:04] <tsdgeos> and btw
[16:04] <tsdgeos> libpoppler-private-dev
[16:04] <seb128> you shouldn't provide it if it's not supported
[16:04] <tsdgeos> ;-)
[16:04] <tsdgeos> that's the package name
[16:04] <tsdgeos> in ubuntu
[16:05] <tsdgeos> tells you something?
[16:05] <seb128> right, debian did that change recently
[16:05] <tsdgeos> wonder why ;-)
[16:05] <seb128> because the upstream naming was not giving the message
[16:05] <seb128> because you guys don't?
[16:05] <Laney> it's not all that many packages to be fair
[16:05] <tsdgeos> because the debian packager is "one of us"
[16:05] <seb128> Laney, no, but it includes libreoffice :p
[16:05] <tsdgeos> and he gets it
[16:06] <tsdgeos> seb128: i can change the library name to
[16:06] <Laney> I'm talking about if there was a push to get people off the private lib
[16:06] <seb128> sure, if everybody gets it wrong, blame it on everybody
[16:06] <tsdgeos> libpopplerprivatedontuseitoryoulldie
[16:06] <tsdgeos> and people will still use it
[16:06] <seb128> easier than trying to think if you maybe could help them
[16:06] <tsdgeos> seb128: i can't help them
[16:06] <tsdgeos> i have no time to help them
[16:06] <tsdgeos> so they have to help themselves
[16:06] <tsdgeos> if they want
[16:06] <psusi> so bottom line is that the fact that people still use this lib and it breaks abi a lot adds some resistance to keeping up to date on the very latest upstream, but hopefully saucy will get updated once this problem with libreoffice is sorted, right?
[16:07] <tsdgeos> to keep using headers that change all the time
[16:07] <tsdgeos> there's not much i can do
[16:08] <seb128> psusi, to 0.22 yes, because it seems like 0.23 is going to change soname on the way again and we don't want to go through a transition every time that happens during the unstable cycle
[16:08] <Laney> there's some scary beasts in there like tex though
[16:08] <seb128> tsdgeos, you shouldn't have provided that unsupported configure option of installing those .h to start
[16:08] <seb128> but oh well
[16:08] <tsdgeos> seb128: blame redhat
[16:08] <seb128> that's done
[16:08] <tsdgeos> they started poppler
[16:08] <tsdgeos> not me
[16:09] <seb128> well, without that we would still have to use xpdf for things I guess
[16:09] <tsdgeos> besides you distros would have done it anyway
[16:09] <seb128> which apparently you, as poppler upstream would prefer
[16:09] <seb128> but yeah, as a distro we prefer using poppler only
[16:09] <cjwatson> transitions wouldn't be so horrible if not for libreoffice being in there
[16:09] <tsdgeos> so don't blame me for doing waht you wanted
[16:09] <tsdgeos> that's kind of nasty
[16:09] <tsdgeos> but you install the headers!
[16:10] <tsdgeos> but we would have installed them anyway if you didn't!
[16:10] <psusi> tsdgeos: I think seb is just lamenting the status quo outloud, rather than really blaming you
[16:11] <tsdgeos> psusi: well "<seb128> tsdgeos, you shouldn't have provided that unsupported configure option of installing those .h to start"
[16:12] <tsdgeos> doesn't seem general lamenting :D
[16:12] <Laney> aaaaaaaaaanyway
[16:12] <seb128> tsdgeos, I'm just responding to you blaming us for using an option upstream provides :p
[16:12] <seb128> but yeah, anyway
[16:12] <Laney> As long as software is using it we don't really have a choice
[16:12] <tsdgeos> anyway it's friday 6pm
[16:12] <tsdgeos> bye guys
[16:13] <seb128> life would be easier if upstream poppler made their private library not-so-private and supported a stabler api for it
[16:13] <Laney> bonne nuit
[16:37] <seb128> stgraber, pitti: could you mark https://code.launchpad.net/~jm-leddy/ubuntu/raring/lupin/fix-670096/+merge/162189 merged or rejected (not sure which one is right, it was targetting raring but got uploaded to saucy)
[16:40] <stgraber> seb128: done
[16:40] <seb128> stgraber, thanks
[16:40] <seb128> stgraber, can you put https://code.launchpad.net/~fehwalker/ubuntu/precise/cobbler/lp1001846/+merge/151352 as work in progress?
[16:42] <stgraber> seb128: done
[16:42] <seb128> stgraber, thanks
[16:42] <seb128> one day we should really get that acl issue fixed...
[16:59] <seb128> stgraber, can you set https://code.launchpad.net/~kentb/ubuntu/raring/ledmon/dell-pcie-ssd-fix_lp1174386/+merge/161696 as merged as well?
[17:01] <stgraber> done
[17:02] <seb128> thanks
[19:38] <stgraber> stokachu: bug 1094319 is missing the SRU paperwork
[19:38] <stokachu> stgraber: even though thats just a piggyback?
[19:38] <stokachu> stgraber: i can add it real quick if required
[19:39] <stgraber> stokachu: yes, every bug listed in the debdiff needs to have a reason why it's being SRUed, a testcase and some risk analysis
[19:39] <stgraber> stokachu: and that last point will be very important when we're talking about splititng the package and introducing a new binary package post-release
[19:40] <stokachu> k gimme a minute ill have it updated
[19:40] <stgraber> (as in, will upgrades from precise => quantal => raring work, did you check that the breaks/replaces/provides are setup properly so we won't get install time file conflicts, ...)
[19:41] <stokachu> stgraber: ive done the rdepends testing
[19:41] <stgraber> the current bug report only sounds like an annoyance (spamming the console), so I think the SRU team will want a bit more than that as a reason to introduce a new binary package
[19:42] <stokachu> stgraber: ive updated the description for the sru
[19:42] <stokachu> stgraber: as far as I can tell regressions should be minimal
[19:42] <stokachu> no hardcoded library paths etc
[20:53] <stgraber> stokachu: diff looks reasonable, test build worked and the binary packages contain what they should, uploaded both packages to the queue
[21:01] <infinity> *blink*
[21:01] <infinity> Unity has decided that firefox and pidgin are the same application group.
[21:01] <infinity> They both show up in the same Alt-` group.
[21:01] <infinity> Has anyone else seen this madness? :P
[21:26] <cody-somerville> infinity: I've seen things like that before, yea. One time it even decided one of my windows didn't exist at all anymore even though it clearly was still there.
[22:53] <stokachu> stgraber: thanks
[23:22] <straemer> I created a patch for the reddit webapp a while ago that's still in a "needs review" state, would someone be able to review it?
[23:22] <straemer> Link: https://code.launchpad.net/~straemer/ubuntu/quantal/unity-webapps-reddit/fix-for-1059882/+merge/151347
[23:29] <straemer> Sorry, my computer crashed there. Did anyone say anything regarding getting my merge request reviewed?
[23:33] <sarnold> straemer: sorry, no one replied..
[23:50] <robru> straemer, your MP is based against the ubuntu quantal package, which is incorrect. In order to make a change against quantal, it first needs to be fixed in Saucy and then SRU'd back to raring and then quantal (SRU is an intensive review process to make sure your changes won't break anything). please rebase your MP against lp:unity-webapps-reddit
[23:51] <straemer> robru: I made the patch long enough ago that quantal would have been the relevant version at the time
[23:52] <robru> straemer, yikes, sorry to hear that. still, lp:unity-webapps-reddit is where it needs to go to today.
[23:55] <robru> straemer, actually, even back then it was still a mistake to propose an MP against a packaging branch. at the time you would have wanted to MP into lp:webapps-applications (which was the upstream trunk that housed *all* of the apps), but now they've been separated into individual projects, so lp:unity-webapps-reddit is the correct place today.