=== tumbleweed_ is now known as tumbleweed === stokachu_ is now known as stokachu [00:46] cjwatson: would you be able to weigh in on bug 1172101 when you have time [00:46] cjwatson: i keep thinking there was a reason why this wasn't done yet [00:53] 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] 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] infinity: ah ok, i wasn't sure if there was a political reason for not doing it [00:54] s/extra-udebs/localudebs/ [00:54] ill do some tests to make sure it works [00:54] I can't think of any political reasons against, since we don't include wget in our default images at all. [00:54] cool sounds good, thanks man [00:54] Now, including wget.udeb in the default images would be a different discussion. === BenC- is now known as BenC === Ursinha is now known as Ursinha-afk === mnepton is now known as mneptok === _salem is now known as salem_ === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem === _salem is now known as salem_ === achiang` is now known as achiang === salem_ is now known as _salem === Guest3570 is now known as kirkland === kirkland is now known as Guest50630 [05:33] Good morning === kirkland_ is now known as kirkland [06:11] xnox: did you see anything odd with the new udev on your setup? === Guest65132 is now known as Zic [06:33] 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] hmm [07:00] No builds for 'file-roller' found in the Saucy release - it may have been built in a former release. [07:00] oh, -proposed [07:01] geser: done [07:02] thanks [07:06] does pbuilder allow you to keep the chroot if a build fails, so you can inspect what happens? [07:07] mlankhorst: sort of, you can have a hook which drops you into a shell to investigate [07:08] see /usr/share/doc/pbuilder/examples/C10shell [07:08] ah [07:08] cd /tmp/buildd/*/debian/.. [07:08] that's actually quite smart.. [07:18] mitya57: hi! thanks for the qtchooser sync! I've a plan now for the saucy uploads, see http://pastebin.ubuntu.com/5666894/ [07:20] Mirv: what does "synced but pkg transition" mean? [07:21] 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] since Debian never had 5.0.1 [07:22] OK, sounds nice. Please subscribe me to the sync requests if you'll be doing any [07:23] mitya57: ok, I will, unless some coredev helps me in doing syncs directly [07:26] Mirv: by the way, qtdoc is currently useless, as documentation should be built in each module [07:26] I'm planning to look at qtbase documentation when I have some time [07:27] mitya57: I noticed that it indeed gives quite a skeleton of documentation out [07:27] yes, but only a skeleton [07:27] so not worth that much, even though with that Qt Creator gets Qt5 documentation topic [07:27] there are some examples et cetera [07:27] but no API docs [07:29] API docs is the most useful thing :) === doko_ is now known as doko [07:46] 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] the manual partitioner of the installer has no option to resize ntfs volumes? [07:47] saucy installer doesn't seem to recognize win8 === megha is now known as hack === hack is now known as baba [08:07] geser: I'll pick it up. I'd prefer to retain TIL on it. [08:07] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128 [08:07] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [08:07] ups, forgot that yesterday [08:11] mfisch: pretty sure it's supposed to be 14 & 19 UTC currently [08:12] tumbleweed: confirm/deny? [08:13] 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] ah, came up on the ML [08:43] diwic: I linked two branches to this bug report https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1163638 [08:43] Launchpad bug 1163638 in pulseaudio (Ubuntu) "pulseaudio fails to release card to jack" [Undecided,Confirmed] [08:43] diwic: I've test built them, so they seem to work ok [08:43] diwic: Would you mind looking at if the patches are well applied? [08:44] ..and documented [08:44] lp:~zequence/+junk/pulseaudio.precise [08:44] lp:~zequence/+junk/pulseaudio.quantal [08:45] zequence, ok [08:47] zequence, have you also tested the result to make sure the handover actually works now? [08:48] diwic: Only on quantal, and only on a virtual install. I need to do more testing [08:49] but, initially, it seems to work the way it's supposed to [08:49] zequence, nitpick: "Let's pulseaudio let go" <- bad wording in changelog [08:49] Ah, I think I wrote them one too many times :) [08:51] 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] zequence, it's correct in the precise one but not the quantal one [08:51] ok === gusch is now known as gusch|away [08:55] diwic: If that's all you can think of, then I'll happily redo both branches with those changes then [08:55] zequence, that and proper testing [08:55] jack people will be thoroughly happy once the fix is out [08:56] it's one of the most common problems users face, so should make some channels a lot more silent for a while :) [08:56] zequence, sounds good :-) === rajaniemi.freenode.net changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128 === sraue_ is now known as sraue [09:37] bad ircd === Laney changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [09:46] 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] 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] 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] uhm, I seem to have a directory /home//.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] I have no idea who could have created it [09:54] i e what program [09:55] diwic: same here: drw------- [09:56] 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] diwic, drwxr-xr-x for me [09:57] created on april 19 [09:58] seb128, any contents in it? [10:00] no, empty [10:02] my directory got last changed/modified on 2013-05-15 [10:02] diwic, I can confirm, it's getting created on login if it doesn't exist and with the permission rw- [10:02] diwic, I just tried with a test user, rm it, log in, the directory is created before you start anything [10:03] seb128, okay, thanks, is there a smart way to figure out what process creates it? [10:04] diwic, not that I know about [10:05] strace -f or systemtap or something [10:05] cjwatson, strace what process? [10:05] something on login create that dir, the goal is to figure out what process something is ;-) [10:05] strace -f the display manager :) [10:05] (not from X ...) [10:06] well, maybe that doesn't work with upstart user sessions [10:06] seb128, diwic: could it be the last upload of gnome-settings-daemon? the diff mentions a "sounds" directory [10:06] something like systemtap should be able to do it, not that I really know how to drive it yet [10:06] geser, I was looking into that yes [10:06] geser, thanks, will have a look [10:06] 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] geser, diwic: [10:07] debian/patches/git_sound_not_polling.patch:+ if (g_mkdir_with_parents(p, 0600) == 0) [10:07] yep [10:07] geser, diwic: https://git.gnome.org/browse/gnome-settings-daemon/commit/?h=gnome-3-6&id=75b8bae1e71199ea7b19769be1c4f423722dffc7 [10:07] that must be it [10:07] is the commit I backported [10:08] that bug comment #2 describe the issue [10:09] s/6/7/ probably [10:09] seems like they screwed that backport [10:09] https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/sound/gsd-sound-manager.c?h=gnome-3-6 [10:09] https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/sound/gsd-sound-manager.c?h=gnome-3-8 [10:09] has 700 [10:09] I will upload a fix and report it upstream [10:09] diwic, do you have a lp bug number for the issue? [10:09] https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=b97a62f56d7f3187c9ab516c8f3c2aa6785665c6 [10:09] just needs to be push to 3-6 too I guess [10:10] pushedd [10:10] seb128, no, I was just testing a new version of PulseAudio and discovered this [10:10] argh [10:10] Laney, want to take care of it? [10:10] Laney, upload/ping upstream? [10:11] upstream fixed it with https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=b97a62f56d7f3187c9ab516c8f3c2aa6785665c6 [10:11] https://bugzilla.gnome.org/show_bug.cgi?id=694134#c6 [10:11] Gnome bug 694134 in general "g-s-d sets an inotify watch on ~/.local/share/sounds, which normally does not exist.. and causes polling" [Normal,Resolved: fixed] [10:11] diwic, Laney snapped you ;-) [10:12] seb128, Laney thanks for fixing it. The result is otherwise that testing speakers in gnome sound settings does not work. [10:13] 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] I can upload that cherry-pick, but perhaps we should take care to fix existing broken ones too? [10:13] 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] 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] you could probably do something with g_access/g_chmod without too much difficulty [10:15] will do it soon [10:15] right [10:16] Laney, you are on it then? just ping if you need a peer review or something [10:16] sure, cheers [10:29] seb128: looks like c2esp could be synced from experimental? [10:29] infinity: would be nice to have a debhelper merge when you get a chance [10:30] cjwatson, it can yes ... are you syncing it or should I? [10:32] seb128: doesn't really matter I guess, doing now === gusch|away is now known as gusch [10:32] cjwatson, right, I just didn't want to dup the action, thanks ;-) [10:32] well I guess whoever would have tried second would just have got a "nothing to sync" === Mez_ is now known as Mez [11:27] diwic: uploaded gnome-settings-daemon, thanks for reporting! === MacSlow is now known as MacSlow|lunch [11:33] tsdgeos, hey, are you on ubuntu-devel list? tkamppeter emailed it about mupdf/poppler === mmrazik is now known as mmrazik|afk [12:00] 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] seb128: ah I saw you've seen it already [12:01] and pinged tsdgeos :-) [12:01] * lool is so half-an-hour late [12:01] 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] seb128: you mean the lightweightness claims? yeah [12:02] I wonder whether we could throw a bunch of PDFs at both and compare rendering too [12:02] (or crashes :-) [12:08] Laney, thanks for the swift handling :-) [12:08] hi, is jockey supposed to work with precise and -lts-{quantal,raring} kernel? [12:20] pmcgowan, ping [12:20] hey tvoss === MacSlow|lunch is now known as MacSlow === mmrazik|afk is now known as mmrazik [12:46] 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] I wouldn't use -updates. Either precise or precise-proposed is fine. I've been drifting towards the former. [12:47] rbasak: no, not precise-updates [12:47] rbasak: as for precise vs precise-proposed, they behave the same now [12:47] OK. I'll use just precise then. Thanks! [12:47] (precise-proposed always felt a bit wrong as it doesn't actually end up there) [12:49] 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 === wedgwood_away is now known as wedgwood [12:51] precise might either refer to the suite (== release pocket) or to the series as a whole, so that part doesn't bother me === greyback is now known as greyback|lunch [13:30] tkamppeter: why on -devel and not in ubuntu-phone ? [13:30] or both (since it affects both) [13:31] lool: tsdgeos_work@xps:/home/tsdgeos/okularfiles/pdf$ ls -l *.pdf | wc -l [13:31] 1404 === henrix_ is now known as henrix [13:33] "is the only free software which allows filling and saving PDF form" [13:34] oh really? [13:34] * tsdgeos looks at poppler [13:35] ogra_: can you forward me the original email so i can answer to it? (me was not subscribed to -devel) (me hides) [13:37] tsdgeos, done ... its also in the archives on lists.ubuntu.com indeed [13:39] ogra_: sure, i've read it there [13:39] ah [13:40] but for a proper answer i need the mail on my mail client [13:40] so headers match, etc [13:40] hmm, i forwarded as attachment ... might not help ... [13:41] let's see :) [13:41] bounced now === greyback|lunch is now known as greyback [13:41] that should have proper headers [13:45] ogra_: second forward better, tx === kentb-out is now known as kentb === francisco is now known as Guest99200 [14:16] 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] ok, mail subject is "Ubuntu Touch:" didn't mention much on convergence on the content either [14:29] tsdgeos, the missing capability of the Ubuntu desktop to fill forms is then probably caused by the GUI frontends, like evince. [14:35] no clue about evince, in okular we save forms, of course there are bugs, all software has bugs unfortunately :/ [14:36] 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 === _salem is now known as salem_ [14:40] sladen: do you have any hard data for taht other than a feeling? [14:40] i'd like to see it :-) [14:40] 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] tsdgeos: works for me [14:42] what works? [14:43] tsdgeos: http://www.acquerra.com.au/poppler/img_0.pdf works for me [in Firefox, with pdf.js] [14:43] you don't get a nice warning at the top? [14:43] are you on ff21? [14:44] do you see the 3 ducks on the right? [14:48] tsdgeos: firefox 20.0+build1-0ubuntu0.12.04.3 [14:49] they problably introduced the warning in ff21 === jml_ is now known as jml [14:53] tsdgeos: what is the warning about? PDF-1.7 or duplicate trailers, or something else? [14:54] sladen: it just says "This document may not be shown properly" [14:54] which is correct [14:55] stokachu: alright, looking at your bugs now, sorry for the delay [14:56] stgraber: no worries, thanks for the help [14:57] tsdgeos: seems the version poppler does equally badly (in a different way) [14:57] sladen: works fine here, can you get a screenshot? [14:58] tsdgeos: 0.18.4-1ubuntu3.1 it's old though [14:58] lol [14:58] tsdgeos: so you likely will not care [14:58] no need for a screenshot then === francisco is now known as Guest36497 [15:07] ~, [15:09] tsdgeos, sladen, which PDF library does ff21 use? Poppler, MuPDF, Ghostscript, or did they write their own from scratch? [15:09] tkamppeter: pdf.js [15:09] tsdgeos, is this a complete PDF interpreter, not using any external library? [15:10] well, it's using firefox [15:10] :D [15:10] that's a quite big "external library" [15:10] tkamppeter: $browser.$canvas implementation [15:10] https://mozillalabs.com/en-US/pdfjs/ "without native code assistance" [15:10] tsdgeos, so the Firefox browser contains a complete PDF interpreter/renderer (at least from version 21 on)? [15:11] yes [15:11] it has for a while [15:11] it's not that good [15:11] but they know it [15:11] which is the first step to fixing it [15:11] no, pdf.js (a bunch of ECMAScript) contains a complete interpreter [15:11] how about chromium (given there are plans to switch to it by default now) [15:12] it simply does var canvas = document.createElement('canvas'); and then draws into that [15:12] ogra_: chromium has no pdf rendeer [15:12] right [15:12] chrome has [15:12] but it's not free soft [15:12] can chromium use the external one [15:12] tsdgeos, and now they think it is reasonably good and so they started to make it be used by default? [15:12] chromium can use pdf.js [15:12] after all it's js :D [15:12] heh [15:12] ogra_: fire up pdf.js in Chromium... [15:13] I wouldn't say we're at the stage of planning to switch to Chromium yet [15:13] tkamppeter: i don't think it's reasonably good but that's my opinion [15:13] FWIW [15:19] ogra_: chromium-browser http://mozilla.github.io/pdf.js/web/viewer.html [15:20] ogra_: (and it's faster than in FF) [15:23] 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] sladen, a wet sponge is faster than FF [15:26] bdmurray, ping [15:29] highvoltage: stgraber: I just noticed that edubuntu has some Xsession.d scripts which look as if they may be crufty, FYI [15:30] Laney: ah? [15:30] maybe, maybe not, but they caught my eye :-) [15:30] 25edubuntu-menus looks curious [15:32] barry: hey [15:33] Laney: is that edubuntu-menus? [15:34] ya [15:35] psusi: I did, UDS was in that week [15:36] Which means not a lot else happens :) [15:37] Laney: right, that package is no longer shipped in Edubuntu and was replaced by edubuntu-menueditor+desktop-profile [15:37] tsdgeos, about the filled forms see https://bugzilla.gnome.org/show_bug.cgi?id=695615 and bug 1153517. [15:37] 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] Gnome bug 695615 in PDF "evince does not save filled PDF forms" [Critical,Unconfirmed] [15:37] stgraber: can we remove? :-) [15:37] bdmurray: can you confirm? [15:37] bug 1153517 in poppler (Ubuntu) "evince does not save filled PDF forms" [High,Triaged] https://launchpad.net/bugs/1153517 === slangase` is now known as slangasek [15:37] 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] 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] phwoar [15:38] barry: yes, from the bugs I've read of the people who've sorted it out they had to do it manually [15:39] the other edubuntu one in edubuntu-live looks like it could become a job [15:39] 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] Laney: 1 package successfully removed. [15:42] *archive catches on fire* === gusch is now known as gusch|away [15:43] tkamppeter: i don't do evince development [15:44] but yeah the fact that we major release old of poppler is not good [15:44] besides the fact that we still don't use libopenjpeg [15:45] 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] tsdgeos, we would ship new poppler if there was [15:47] - a reliable release schedule [15:47] there is [15:47] there as always been [15:47] - upstream stopped breaking ABI and changing soname forcing us into transitions [15:47] we don't break ABI [15:48] well, you bump sonames [15:48] it's people that use headers we don't support [15:48] soname of the internal library [15:48] noone is supposed to use [15:48] yet people use them [15:48] don't make it public then? [15:48] they are not [15:48] if it's not supposed to be used [15:48] they are installed in /usr/lib === mmrazik is now known as mmrazik|afk [15:48] and the .h are installed [15:48] you use the --install-xpdf-headers swtich [15:49] which is an option provided by upstream ;-) [15:49] that clearly says they are unsupported [15:49] cjwatson: ok, I figured, just wanted to be sure the mail wasn't lost [15:49] "Install unsupported xpdf headers." [15:49] you can't blame us if we change unsupported things [15:49] can you? [15:49] well you can [15:49] but not that i care :D [15:50] tsdgeos, reality is [15:50] $ apt-cache rdepends libpoppler28 | wc -l [15:50] 24 [15:50] seb128: and please don't spread fud about not reliable schedule [15:51] seb128: as said, that's not our problem [15:51] 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] so maybe that was that [15:51] sure [15:51] schedule is reliable but not working for us [15:51] we have no intention to align to gnome or ubuntu [15:51] ok [15:51] why would we do that stupid thing? [15:51] so don't complain that we can't ship the current version ;-) [15:52] because most distros are aligned on those schedules [15:52] and it would make you have more current versions in distros [15:52] :D [15:52] you really believe that? [15:52] yes [15:52] you've been working on ubuntu for too much D: [15:52] aren't we behind by more than one release though? [15:52] psusi, no [15:52] current is 0.22 and we have 0.20 [15:53] ahh, ok then [15:53] seb128: yes you are, 13.04 ships something that was released on October [15:53] while 0.22 was released on December [15:53] that seems pretty out of sync to me [15:53] tsdgeos, where can I find the 0.24 schedule? [15:53] tsdgeos: that's not that long ago ;) [15:53] seb128: on the wiki [15:54] "the wiki" [15:54] * seb128 goes the.wiki.com [15:54] k, found ity [15:54] http://freedesktop.org/wiki/Software/poppler [15:54] also know "as google" [15:54] seb128: wikipedia is likely "the wiki" these days, fwiw :-) [15:54] "poppler 0.24 schedule" [15:54] I guess we could go for 0.24 this time [15:55] do you plan to change your private soname between now and 0.24? (I guess you do) [15:55] you mean 0.22 and 0.24? [15:55] sure [15:55] 0.23.1 already changed it [15:55] hrm... debian is still on 0.18, even in unstable [15:56] and we'll be changing it if needed [15:56] it's probably the most pressing thing causing distros not to want to update as often as they might [15:57] 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] tsdgeos, we need to rebuild all rdepends to pick the new soname [15:57] which includes libreoffice [15:57] perhaps it would be profitable to investigate why people are using private things and try to provide public API? [15:57] which doesn't build atm in saucy with the current toolchain [15:57] tsdgeos, so it means we can't even update poppler atm, until we fix libreoffice's build [15:58] the transition will get stucked otherwise [15:58] seb128: ok, so we have bigger problems :D [15:58] well, libreoffice is being worked [15:58] Laney: well, i'm not going to go out there chasing random people [15:58] but while that's not solved, I can't update poppler [15:58] if people feel the need of a stable api we have a nice mailing list where we don't eat people [15:58] most of times :D [16:00] 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] we provide 4 libs [16:01] 3 of those we stable api (qt, glib and purec++ apis) [16:01] and the internal one use by those 3 [16:02] whose abi/api changes as we see fit [16:03] I see... and people keep going direct to the internal library eh? I wonder why... [16:03] but which is still installed in /usr/lib [16:03] with a proper soname versioning [16:03] as a public library [16:03] and its name is "libpoppler" not libpoppler-private [16:04] so? [16:04] so people don't see that it's private [16:04] it's just like any other library [16:04] so it's not very obvious that it's private ;) [16:04] you don't get it's headers unless you agree to install unsupported [16:04] so they use it [16:04] well, distro use the configure flag that you provide [16:04] and btw [16:04] libpoppler-private-dev [16:04] you shouldn't provide it if it's not supported [16:04] ;-) [16:04] that's the package name [16:04] in ubuntu [16:05] tells you something? [16:05] right, debian did that change recently [16:05] wonder why ;-) [16:05] because the upstream naming was not giving the message [16:05] because you guys don't? [16:05] it's not all that many packages to be fair [16:05] because the debian packager is "one of us" [16:05] Laney, no, but it includes libreoffice :p [16:05] and he gets it [16:06] seb128: i can change the library name to [16:06] I'm talking about if there was a push to get people off the private lib [16:06] sure, if everybody gets it wrong, blame it on everybody [16:06] libpopplerprivatedontuseitoryoulldie [16:06] and people will still use it [16:06] easier than trying to think if you maybe could help them [16:06] seb128: i can't help them [16:06] i have no time to help them [16:06] so they have to help themselves [16:06] if they want [16:06] 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] to keep using headers that change all the time [16:07] there's not much i can do [16:08] 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] there's some scary beasts in there like tex though [16:08] tsdgeos, you shouldn't have provided that unsupported configure option of installing those .h to start [16:08] but oh well [16:08]