[00:11] <bcurtiswx> robert_ancell, hi
[00:11] <robert_ancell> bcurtiswx, hello
[00:11] <bcurtiswx> robert_ancell, who could I talk to about the webapps design ?
[00:12] <robert_ancell> bcurtiswx, design or implementation?
[00:13] <bcurtiswx> not sure, it's about getting rid of the chromium icon in the side bar when it's only webapps loaded
[00:14] <robert_ancell> bcurtiswx, did you file a bug? I think racarr worked on it but I don't know a lot of details about the project
[00:14] <bcurtiswx> robert_ancell, not yet, figured I'd chat with someone before.
=== VD is now known as Guest59294
[01:48] <desrt> robert_ancell: you get a chance to play with those USB things yet, or waiting for logind?
[01:48] <robert_ancell> desrt, I turned on on and got video through it but it really needs logind/udev to make them work properly
[01:50] <desrt> makes sense
[01:50] <desrt> hopefully soon
[01:50]  * desrt is hearing reports that gnome-shell under llvmpipe is hilariously fast these days
[01:51] <desrt> would be really nice to see it on one of those
=== VD is now known as Guest38297
[02:39] <duflu> desrt: Compiz under llvmpipe isn't too bad either. But Unity needs some improving yet
[02:49] <desrt> duflu: apparently ajax is actively improving llvmpipe as well
[02:50] <duflu> desrt: ajax is a handle I assume? :)
[02:58] <desrt> ya :p
[02:58] <desrt> adam jackson
[02:58] <desrt> x hacker extraordinare
[03:00] <duflu> desrt: Yeah I googled
[03:02] <duflu> desrt: Weirdly, compiz llvmpipe performance used to be better before we "supported" it... bug 1025586
[03:02] <ubot2> Launchpad bug 1025586 in compiz (Ubuntu) "[0.9.8 r3110 regression] [LLVMpipe] Dragging windows around is much slower with compiz 0.9.8 than 0.9.7 (using LLVMpipe)" [High,Triaged] https://launchpad.net/bugs/1025586
[03:02] <duflu> Though back then there were hideous graphical glitches too
[03:04] <Sarvatt> http://pkgs.fedoraproject.org/cgit/mesa.git/tree/mesa-8.0-llvmpipe-shmget.patch not being in upstream mesa doesn't help :)
[03:05] <duflu> Sarvatt: Interesting. Why not upstream?
=== Ursinha is now known as Ursinha-afk
[04:44] <mfisch> robert_ancell: ping
[04:44] <robert_ancell> mfisch, hello
[04:44] <mfisch> robert_ancell: I never did get bzr merge-upstream to work for curl, but I did the update
[04:45] <mfisch> robert_ancell: the reviewer suggested that I should just merge from debian experimental instead, which makes sense
[04:46] <robert_ancell> yeah, they debian updated
[04:46] <mfisch> I think I missed the update or it happened after I started
[04:47] <robert_ancell> mfisch, I didn't see it updated until you had finished. It can be guess work to tell if debian is keeping up to date or now
[04:47] <robert_ancell> not
[04:47] <mfisch> so we have ubuntu patches still, so I need to see what debian did
[04:47] <mfisch> we can't just copy theirs in
[04:49] <robert_ancell> mfisch, oh yeah, you have to merge with them
[05:59] <didrocks> good morning
[06:01] <RAOF> Yo yo didrocks yo!
[06:01] <didrocks> hey RAOF!
[08:35] <chrisccoulson_> good morning everyone
[08:36] <didrocks> hey chrisccoulson_, how are you?
[08:36] <chrisccoulson_> wow, only 2 work days left!#
[08:36] <chrisccoulson_> hi didrocks, i'm good thanks. how are you?
[08:36] <didrocks> chrisccoulson_: I've thanksfully more than 2 work days left (seeing the amount of work remaining ;))
[08:36] <didrocks> but good, it's light festival in my city starting tonight!
[08:38] <didrocks> if you want to see last year teaser: http://www.youtube.com/watch?v=8PqBQMeUZP0 :)
[08:39]  * duflu moves to Lyon
[08:39] <didrocks> ;)
[08:40] <duflu> There's /too much/ daylight in Perth. Along with the heat it's repressing
[08:40] <duflu> Though today is cool
[08:40] <didrocks> duflu: this year, the light festival will maybe happen under snow (snowing lightly, but snowing today) :)
[08:41] <didrocks> will be fun in the streets, during the week-end in particular, there are an estimation of 4 millions people coming just for the festival (but hopefully it's across the city)
[08:41] <pitti> Good morning
[08:41] <chrisccoulson_> hmm, my firefox nightlies have been failing because i added a xpi file to the packaging and forgot to add it to debian/source/include-binaries
[08:41] <chrisccoulson_> hi pitti
[08:41] <duflu> didrocks: You win. We had a quick taste of Summer the other day. 37 degrees. That will soon become normal...
[08:41] <didrocks> hey pitti :)
[08:41] <didrocks> duflu: heh! ;)
[08:43] <chrisccoulson_> didrocks, the lights look quite nice ;)
[08:44] <didrocks> chrisccoulson_: they really are :) Also there is the tradition of every citizen putting some small lamps next to their windows the 8 of December
[08:45]  * didrocks refers to http://timoetnous.unblog.fr/files/2009/12/fetelumiere2009lumignon.jpg
=== chrisccoulson_ is now known as chrisccoulson
[08:46] <didrocks> basically, there are some history (http://en.wikipedia.org/wiki/Festival_of_Lights_(Lyon)), but for 10 years, it's a real city-size events :)
[09:12] <xclaesse> would be great if taping "play" multimedia key starts rhythmbox in background
[09:13] <xclaesse> atm it works only  if I first lauch rb manually
[09:31] <seb128> xclaesse, right, that's a gnome-settings-daemon upstream wishlist (or rhythmbox one) ... the keybinding makes g-s-d send a dbus signal, but since rhythmbox is not running...
[09:31] <seb128> xclaesse, seems like rb should be dbus activated when that happens
[09:32] <seb128> not sure how the sound indicator does it because it works there, if you click play it will start rb and play
[09:32] <xclaesse> seb128, do you have a bug # for that?
[09:33] <xclaesse> seb128, hm good point about sound indicator
[09:33] <xclaesse> it present the rb window though, I personally would let it hidden
[09:34] <seb128> xclaesse, https://bugzilla.gnome.org/show_bug.cgi?id=687831
[09:34] <ubot2> Gnome bug 687831 in media-keys "Pressing "play" should launch the last used media player" [Normal,New]
[09:34] <xclaesse> it's not really consistent, if I start rb, play, close window, then pause. Then I click play again in the indicator it won't show the window...
[09:35] <seb128> xclaesse, that's a good point, I guess that's a rb bug, it always start by showing it's ui rather than restoring its previous state
[09:35]  * xclaesse sees rb a bit like empathy: a UI for a service that runs on background
[09:35] <seb128> xclaesse, yeah, but rb doesn't have clean backend separation :p
[09:36] <xclaesse> I know, it's already an ubuntu specific patch that you can close the window and still play music
[09:40]  * didrocks agrees on the service view
[09:40] <didrocks> IIRC, I did an UDS session some years ago about those :)
[09:44] <xclaesse> didrocks, seb128: what's the package for the music indicator?
[09:44] <didrocks> indicator-sound
[09:44] <xclaesse> thx
[09:49] <psivaa> didrocks: just to let you know that the live-session compiz crash is still occurring with compiz: 1:0.9.9~daily12.12.05 and unity: 6.12.0daily12.12.05
[09:49] <didrocks> psivaa: ah ok, can you report the latest stacktrace please?
[09:49] <didrocks> psivaa: it will be easier to debug that way
[09:50] <didrocks> psivaa: then, just ping me with the bug # please, I'll add to the list :)
[09:50] <psivaa> didrocks: ack
[09:50] <didrocks> thanks :)
[09:52] <xclaesse> didrocks, seb128: reported that one: https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1087186
[09:52] <ubot2> Launchpad bug 1087186 in indicator-sound (Ubuntu) ""play" when rb is not running should not popup its window" [Undecided,New]
[09:52] <seb128> xclaesse, thanks
[09:54] <didrocks> psivaa: there is maybe a fix in the ppa soon, but IIRC, you had trouble testing with that, right?
[09:54] <didrocks> (someone not on the distro)
[09:54] <psivaa> didrocks: yes, it's not proving easy testing live session in persistent mode with VMs
[09:55] <didrocks> psivaa: will be good to see why, at least, that will enable to test the potential fix
[09:55] <didrocks> or workaround rather
[09:58] <psivaa> well even with today's images doing a pkill -9 X solves the issue
=== tkamppeter_ is now known as tkamppeter
=== Quintasan_ is now known as Quintasan
=== attente_zzz is now known as attente
[13:03] <cyphermox> good morning
=== Ursinha-afk is now known as Ursinha
[13:16] <mdeslaur> didrocks: uhm, whatever you described in bug 1037164 sounds like a completely different issue to me...
[13:16] <ubot2> Launchpad bug 1037164 in compiz (Ubuntu Quantal) "Clicking on semi-maximized windows in a different workspace produce unexpected results" [Medium,Triaged] https://launchpad.net/bugs/1037164
[13:17] <mdeslaur> didrocks: the original bug had nothing to do with semi-maximized windows
[13:17] <didrocks> mdeslaur: duflu pointed that it should be the same root cause
[13:17] <mdeslaur> hrm, ok then
[13:17] <didrocks> when I asked for filing a different one, he just asked me to comment on it
=== Sweetsha1k is now known as Sweetshark
[14:34] <kenvandine> didrocks, is dee set to autoland?
[14:35] <didrocks> kenvandine: not yet for the unity release stack
[14:35] <didrocks> until autopilot is on
[14:35] <kenvandine> ok, mind if i do a manual upload of dee?  it is completely broken right now for python3
[14:35] <kenvandine> my branch has been merged into trunk
[14:39] <psivaa> hello, bug 1080674 is starting to impact more people and it does not appear to be kernel related
[14:39] <ubot2> Launchpad bug 1080674 in xserver-xorg-video-cirrus (Ubuntu) "[QEMU] Corrupted desktop screen for raring desktop installation in QEMU guest (Cirrus graphics)" [Undecided,Confirmed] https://launchpad.net/bugs/1080674
[14:40] <psivaa> it would be helpful to know if there will be a fix soon
[14:45] <didrocks> kenvandine: oh no worry at all :)
[14:45] <didrocks> kenvandine: just ensure it's merged upstream then
[14:45] <kenvandine> will do
[14:46] <didrocks> kenvandine: speaking of ensuring… :) https://code.launchpad.net/~ps-jenkins/signon-keyring-extension/latestsnapshot/+merge/138380
[14:46] <didrocks> can you harrass the jenkins master so that it's merged
[14:46] <didrocks> ?
[14:46] <chrisccoulson> hmmm, chrome doesn't support JS proxies? :/
[14:46] <didrocks> I tried to reapprove it when I saw the PASS but nothing, looking at the trace, it's a jenkins issue
[14:46] <kenvandine> sure
[14:47] <didrocks> thanks :)
[14:47] <kenvandine> i really need to setup vpn so i can see those logs
[14:53] <didrocks> kenvandine: you will need it for the daily build as well :)
[15:08] <ricotz> didrocks, hi
[15:08] <ricotz> didrocks, i guess a merge-proposal is needed even for tiny things? http://paste.debian.net/plain/214732
[15:09] <ricotz> didrocks, btw any plans to enable the git/vapi build for bamf package?
[15:09] <ricotz> s/git/gir
[15:22] <kenvandine> didrocks, https://code.launchpad.net/~ken-vandine/dee/1.2.0daily12.12.06-0ubuntu1/+merge/138480
[15:23] <didrocks> ricotz: oh yeah, do you want to submit that upstream?( sorry in meetings)
[15:23] <didrocks> ricotz: for the bamf one, I need to check if gir/vapi are working, back on the time, they were not perfect at all :)
[15:23] <didrocks> kenvandine: oh, you used the daily notation! :)
[15:23] <kenvandine> i had to
[15:23] <didrocks> had to?
[15:24] <didrocks> oh
[15:24] <didrocks> --split
[15:24] <didrocks> so same tarball :)
[15:24] <kenvandine> 1.2.0daily12.12.05-0ubuntu1 is > 1.2.0baily12.12.06-0ubuntu1
[15:24] <kenvandine> whoops
[15:24] <kenvandine> 1.2.0daily12.12.05-0ubuntu1 is > 1.2.0bzr12.12.06-0ubuntu1
[15:24] <didrocks> yeah, you couldn't use 1.2.0daily12.12.05-0ubuntu2 because of --split
[15:24] <kenvandine> ah, yeah that too
[15:25] <didrocks> ahah, you didn't thought about it! I see ;)
[15:25] <didrocks> kenvandine: btw, approved :)
[15:25] <kenvandine> :-D
[15:25] <kenvandine> thx
[15:27] <didrocks> kenvandine: on the signon thing: if you see that in let's say, 4 hours, it's not getting merged, can you do it manually?
[15:27] <didrocks> kenvandine: it will block the next daily only if anything has to be pushed otherwise
[15:27] <kenvandine> yeah
[15:27] <didrocks> thanks!
[15:27] <kenvandine> i am not sure where rvr is
[15:27] <didrocks> kenvandine: you can still ask to fghinter if he's not here today
[16:00] <ricotz> didrocks, i submitted some introspection fixes in the past and using the bamf vapi myself
[16:01] <didrocks> ricotz: oh good, a bzr branch around for it? :)
[16:01] <ricotz> so it seems fine to have it built i think
[16:01] <ricotz> didrocks, currently not
[16:01]  * didrocks will review it once ready :)
[16:01] <ricotz> didrocks, this small fix is though
[16:02] <didrocks> ricotz: do you have a link to the merge proposal? I didn't see it
[16:02] <ricotz> didrocks, didnt made one yet, since it is pretty minor, will do right away
[16:03] <didrocks> thanks!
[16:06] <ricotz> didrocks, https://code.launchpad.net/~ricotz/bamf/annotation-fix/+merge/138493
[16:06] <didrocks> ricotz: thanks! mterry ^
[16:07] <mterry> looking
[16:11] <ricotz> mterry, also using uint64 doesnt seems appropriate http://paste.debian.net/plain/214748
[16:11] <ricotz> not sure if this is actually used and would be considered a break
[16:12] <mterry> ricotz, well, I'm slightly confused.  the gdk API seems to treat them as pointers, where something as large as 64 would make some sense if we're being forced to be explicit.  But other uses of xid (like over dbus) typically define them as 32
[16:12] <mterry> ricotz, so I'm assuming that 32 is appropriate
[16:12] <ricotz> mterry, yeah tabsource also uses uint32
[16:14] <dobey> xids should be 32bit everywhere in gdk afaik
[16:19] <ricotz> mterry, i guess you need to reapprove due the missing commit message
[16:20] <mterry> ricotz, done
[16:21] <Sweetshark> ricotz: did you see 3.6.4 in the libreoffice ppa btw?
[16:22] <ricotz> Sweetshark, oh, not yet, i havent looked lately
[16:24] <ricotz> Sweetshark, are those the *same* tarballs as rc3?
[16:24] <Sweetshark> ricotz: I hope not!
[16:25] <ricotz> no you had a repack in your ppa irc
[16:25] <ricotz> so those are same again now
[16:25] <ricotz> nevermind i will take a look later
[16:25] <mterry> Sweetshark, what is the difference between bug 1034558 and bug 1034560 ?
[16:25] <ubot2> Launchpad bug 1034558 in pentaho-reporting-flow-engine (Ubuntu) "[MIR] libbase-java, libsac-java, libxml-java, libflute-java, libpentaho-reporting-flow-engine-java, liblayout-java" [Undecided,New] https://launchpad.net/bugs/1034558
[16:25] <ubot2> Launchpad bug 1034560 in libloader (Ubuntu) "[MIR] libloader-java, libformula-java, librepository-java, libfonts-java, libserializer-java " [Undecided,Incomplete] https://launchpad.net/bugs/1034560
[16:25] <mterry> They both seem to be for the same proximate cause of the report builder
[16:26] <Sweetshark> desrt: can you comment on bug 1086868 comment 7? I assume gimp doesnt use GMenuModel yet, and would cause the same additional deps once it does, right?
[16:26] <ubot2> Launchpad bug 1086868 in libreoffice (Ubuntu) "No global menu in Plasma (KDE) session in Raring" [Undecided,Won't fix] https://launchpad.net/bugs/1086868
[16:27] <Sweetshark> mterry: yes. IIRC they were split after a quick chat with seb128 along the lines of 'no more than ~5 packages on one bug' ...
[16:28] <desrt> Sweetshark: i don't understand the question
[16:28] <mterry> Sweetshark, ok, if that's all no biggie.  I don't mind giant bugs if they are just MIRs, but two bugs isn't a problem either  :)
[16:28] <desrt> what does this have to do with GIMP?
[16:28] <desrt> oh.  i see.
[16:28] <desrt> GIMP is still using the dbusmenu 'sucker' approach
[16:29] <desrt> i guess the KDE plasma stuff does not speak GMenuModel yet
[16:29] <Sweetshark> desrt: hrhr, is 'sucker' the official marketing term?
[16:29] <desrt> Sweetshark: it's a fairly accurate description :)
[16:31] <Sweetshark> desrt: hmm, thats not the only issue. if libreoffice is running in on a kde-desktop, it will mimic kde (and use some native kde file pickers etc.). same for gtk. and the menumodel is in the -gtk mimicing code (and thats a Good Thing(tm)).
[16:33] <Sweetshark> desrt: so to get the menu (even if they would be supported by plasma) one would need to teach libreoffice to use the gtk mimicking even on kde. As gtk is themed as qt on kde it shouldnt be too much of an issue (except for the few truely native dialogs like file chooser/print).
[16:34] <desrt> i think the kde plasma thingy just needs to speak gmenumodel
[16:34] <desrt> one way or another it's going to have to do that eventually
[16:34] <desrt> otherwise people are going to be upset when GIMP stops working next
[16:35] <desrt> (attente is working now on making that a reality)
[16:38] <Sweetshark> desrt: yep. still, even if plasma knows about GMenuModel, one would need to tweak libreoffice to default to the -gtk plugin (as that plugin is the only one which has the GMenuModel stuff) and thereby get native gtk-filepickers instead of qt-filepickers. whatever, they are better anyway.
[16:39] <Sweetshark> (or plumb the gmenumodel stuff into the -kde plugin too)
[16:44] <seb128> didrocks, mterry: can we get https://code.launchpad.net/~laney/unity-lens-music/gstreamer1.0/+merge/134310 reviewed/merged, we got totem/rb/etc using gst1
[16:47] <didrocks> mterry: just a note when you review it, I think debian/changelog should be bumped as there is a bump in configure.ac
[16:47] <didrocks> hum, ignore me :)
[16:47]  * didrocks needs coffee
[16:48] <didrocks> but I still think that debian/changelog will conflict once merged (as we did a daily release)
[16:48] <mterry> didrocks, seb128: seems harmless from a quick review.  will build and test.
[16:48] <mterry> didrocks, yar
[16:48] <seb128> mterry, thanks
[16:48] <didrocks> mterry: I'm a little bit afraid of what bzr merge is doing, I think it's duplicating the changelog in that case
[16:49]  * didrocks just does a trial out of curiousity
[16:49] <didrocks> ah no, conflict, good :)
[16:49] <didrocks> but still weird result of the 3 way merge :)
[16:57] <didrocks> seb128: it seems that upstream a-l-m isn't active anymore, do you know who to contact for https://code.launchpad.net/~malizor/activity-log-manager/fix-967150/+merge/125556 ?
[17:05] <seb128> didrocks, we should try to contact seif to see if we can hand us the project or add us as admins
[17:05] <didrocks> yeah
[17:05] <seb128> didrocks, do you want to do it or should I?
[17:05] <didrocks> seb128: if you have time tomorrow, please do it, if not, just hand it over to me for next week :)
[17:06] <seb128> didrocks, ok, writing an email so it's done
[17:06] <didrocks> seb128: great! :)
[17:54] <pitti> seb128: Monsieur! est-ce que tu as une minute?
[17:55] <seb128> pitti, salut, oui
[17:55] <pitti> seb128: we are just discussing crashes on errors.u.c. again, and wondering how we can eventually stop sending everything to both daisy and LP
[17:56] <pitti> seb128: so AFAIUI, your (and mine) main concern about this was that for some problems we need an interactive communication channel with the reporter, right?
[17:56] <seb128> yes
[17:56] <pitti> seb128: but in the general case, we want crashes to be on errors.u.c, and not upload everything twice
[17:56] <seb128> well, "interactive" would be great
[17:56] <pitti> seb128: so how about this:
[17:57] <seb128> but a minimal step would be to let users write a descriptions
[17:57] <seb128> so we could go through the descriptions to get infos
[17:57] <seb128> e.g firefox is doing that
[17:57] <pitti> seb128: problem with descriptions is that we'll get tons of them, and nobody would read them all
[17:57] <seb128> well, it's often useful
[17:57] <pitti> seb128: so the idea that we have is this:
[17:57] <pitti> - apport shows the crash
[17:57] <pitti> - apport asks daisy "do you know about this problem"
[17:57] <seb128> you would go through 15 and see "ok, quite some of those people are speaking about login with another user"
[17:58] <seb128> pitti, (sorry, I'm reading now)
[17:58] <pitti> - daisy then replies with "no", "yes", or "yes, and a developer requested an LP bug"
[17:58] <pitti> seb128: as part of the general "problem specific hooks" (this will be a checkbox)
[17:59] <pitti> and as soon as the next reporter actually does submit an LP bug, the requestor gets a notificatoin pointing to the new bug
[17:59] <pitti> the bug will have a link to the details on errors and the crash signature
[17:59] <pitti> and once such a bug exists, daisy would stop requesting further bugs
[17:59] <seb128> pitti, that would work for me I think, it means we can engage a conversation for the bugs we care about and cut the noise for the others
[17:59] <pitti> this gives us the general communication channel for the stuff where we want it
[18:00] <seb128> pitti, yeah, +1 from me ;-)
[18:00] <pitti> and at the same time allows us to (1) avoid the noise nobody looks at, and (2) mothball our Launchpad retracers
[18:00] <pitti> seb128: and for the cases where we can collect additional infos noninteractively we can use the new "for the next n times run this additional hook" feature
[18:01] <seb128> pitti, yeah, that seems great to me
[18:01] <pitti> très bien!
[18:02]  * pitti te donne une accolade
[18:02] <seb128> pitti, but don't turn the launchpad side off before the feature is added to e.u.c :p
[18:02]  * seb128 donee une accolade à pitti en retour
[18:02] <seb128> "donne" even
=== m_conley_away is now known as m_conley
[18:21] <cyphermox> seb128: yo
[18:21] <cyphermox> have you seen the new upload of evolution-indicator in the queue?
[18:22] <cyphermox> nevermind, I fail
[18:22] <cyphermox> thanks ;)
[18:23] <seb128> cyphermox, yw ;-)
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== attente is now known as attente_zzz
[20:32] <Sweetshark> ricotz: https://skyfromme.wordpress.com/2012/11/26/building-libreoffice-easily-killing-an-urban-myth/comment-page-1/#comment-697 <- people are really pushy to get libreoffice backports. you should suggest selling it as an premium enterprise service to him ...
[20:34] <micahg> Sweetshark: I was going to ask if you or ricotz have any interest in official (-backports) backports for libreoffice
[20:38] <Sweetshark> micahg: I wouldnt be able to handle that on current workload. Also IMHO this is something that is a perfect reason to become an ubuntu advantage customer, isnt it?
[20:38] <micahg> Sweetshark: nope
[20:38] <jbicha> do new LO releases require updated dependencies though?
[20:39] <ricotz> Sweetshark, lol, i guess he should be happy with 3.5.7, but i will look at getting 3.6.4 for precise, but no eta yet
[20:39] <micahg> some new deps aren't a problem, it depends how far down the stack it goes on whether or not the testing will be onerous
[20:40] <ricotz> there are some deps like cmis which needs to be updated
[20:41] <micahg> libreoffice is the only rdep, no problem :)
[20:41] <ricotz> but it is pretty much backportable, i will dare to look into 3.6.4 for lucid too though
[20:41] <jbicha> micahg: backports can depend on other backports now?
[20:42] <micahg> jbicha: umm, well, when infinity fixes it...(if it's a new source/binary, then yes right now)
[20:42] <micahg> s/source//
=== lifeless_ is now known as lifeless
[20:44] <Sweetshark> micahg: well, if its not, we are definitely understaffed for libreoffice ;>
[20:44] <ricotz> micahg, for the ppa builds i like backporting as much as possible of the closer deps
[20:44] <ricotz> Sweetshark, right
[20:45] <micahg> ricotz: yeah, well, the more you backport, the more stuff you have to test when it's official
[20:45] <Sweetshark> jbicha: depends. you can switch most of the deps from an external version to an internal one, but that brings its own set of problems.
[20:46] <ricotz> micahg, yeah :\, that is why i like the ppa way
[20:46] <micahg> ricotz: right, but that's less discoverable :)
[20:46] <micahg> with backports on by default now, it would be nice for people to have an option in software center for a newer version
[20:47] <ricotz> right
[20:47] <jbicha> we needs a Trusted PPA program where good official PPAs like LO & the Mozilla Beta PPA can be highlighted
[20:48] <Sweetshark> micahg: but backports would also mean doing ARM in addition. the libreoffice PPA is amd64/i386 only. that will again make a huge difference.
[20:48] <mlankhorst> trust is that which can betray you. :P
[20:49] <ricotz> Sweetshark, adding arm support to the ppa is possible though
[20:49] <micahg> Sweetshark: not sure what you mean by "doing ARM", you get ARM builds for free with an official backport
[20:50] <micahg> anyways, just wanted to throw it out there, it's definitely optional from my perspective
[20:55] <Sweetshark> micahg: note that libreoffice does ~8 (plus 3-4 prereleases) microreleases per cycles, multiply by at least 3 supported releases (dev-release, last non-LTS, last LTS). you have ~30 releases (when not backporting the prereleases everywhere). A full LO release takes _at_ least 1 day when done right (create tarballs, build locally, tested locally, dput to ppa, build in ppa, build in ppa again because of lack of fs-space, user testing in p
[20:56] <micahg> Sweetshark: -backports backports are ideally straight backports from a later series, so it should be a matter of testing that everything builds/installs/runs
[20:56] <micahg> Sweetshark: and there's no saying that you have to backport every release
=== attente_zzz is now known as attente
[20:58] <Sweetshark> a cycle has ~115 workdays. at one day per release its some 25% of worktime, at three its 75% of worktime -- given that you also have som 25% for administration, coordination, conferences, that is a full commitment.
[20:59] <micahg> Sweetshark: it wasn't a worktime request...
[20:59] <Sweetshark> under the unrealistic assumption that there is nothing to be done really on the packaging itself etc. ....
[21:00] <Sweetshark> micahg: sure ;) -- its just that alot has changed since OOo with their sleepy one major, one minor release per year ;)
[21:01] <Sweetshark> micahg: libreoffice ARM builds are never 'for free' ;)
[21:02] <micahg> Sweetshark: TBH, I don't see the connection, I was just wondering if you or ricotz considered official backports, that's all, I'm aware of the backports PPA and since the topic was brought up, I figured to mention it
[21:08] <Sweetshark> micahg: which connection? anyway: I would only consider backports, if I had enough wiggle room to ensure to regularly update them. I dont see that at all now. If ricotz is volunteering, kudos to him, but it did not exactly sound like that currently.
[21:10] <micahg> Sweetshark: connection between # of releases and backports. anyways, it's voluntary, just wanted to plant the seed in case someone wanted to make it happen
=== You're now known as ubuntulog
=== m_conley is now known as m_conley_away