[05:58] <pitti> Good morning
[06:23] <darkxst> hey pitti, could you unsubscribe sponsors from Bug 1319897
[06:26] <pitti> darkxst: done, thanks
[06:40] <darkxst> pitti, thanks!
[06:49] <Mirv> mlankhorst: hey! what is the upstream status of the xi2 related Qt patch?
[06:55] <rickspencer3> good morning desktoppers
[06:55]  * rickspencer3 presumes he is the only one up
[06:55] <didrocks> hey rickspencer3! :)
[06:55] <didrocks> no, you're not :p
[06:55] <rickspencer3> bonjour didrocks
[06:55] <didrocks> how is Malta?
[06:55] <rickspencer3> didrocks, it's nice
[06:56] <didrocks> great, hoping that you will have a smooth week as well and enjoy the week-end there! :)
[06:56] <rickspencer3> je parle francais avec lool
[06:56] <rickspencer3> mais, il parle trop vit poir mois
[06:57] <didrocks> héhé, oui, il parle assez vite en effet :)
[06:57] <rickspencer3> didrocks, I suppose we will have quite a smooth week
[06:57] <didrocks> c'est le stress de Paris! :p
[06:57] <rickspencer3> lol
[06:57] <rickspencer3> pauvre lool
[06:57] <didrocks> héhé
[06:59] <lool> mince, j'ai encore parlé trop vite
[06:59] <lool> et avec un bonbon dans la bouche en plus
[06:59] <rickspencer3> lol
[06:59] <didrocks> lool: ah ben la politesse!
[06:59] <didrocks> bravo
[07:01] <mlankhorst> Mirv: uncertain :P
[07:01] <mlankhorst> haven't really tried
[07:03] <Mirv> mlankhorst: I mean, was the patch submitted upstream, or was it assumed it can be dropped off with the next release? I see 5.3 has refactored that code so my first thought would be to drop the patch
[07:04] <Mirv> mlankhorst: I just finished rebasing the patch too, but I don't know if it does more harm than good
[07:05] <mlankhorst> no idea, I haven't looked at the 5.3 version yet. is it available somewhere?
[07:06] <Mirv> mlankhorst: lp:~timo-jyrinki/kubuntu-packaging/qtbase-opensource-src_qt530RC , now includes also the rebased patch. wget http://download.qt-project.org/official_releases/qt/5.3/5.3.0/submodules/qtbase-opensource-src-5.3.0.tar.xz and symlink to get the orig tarball
[07:07] <Mirv> mlankhorst: an already built Qt 5.3 (RC) without the patch is at ppa:canonical-qt5-edgers/qt5-beta2
[07:10] <mlankhorst> ok *takes a look*
[07:14] <mlankhorst> Mirv: would still apply
[07:14] <mlankhorst> but with some twist I guess
[07:15] <mlankhorst> only thing added is support for scrolling devices
[07:15] <mlankhorst> afaict
[07:22] <Mirv> mlankhorst: can you check what I just did for the patch in the above branch and if the rebasing makes sense?
[07:25] <Mirv> so the first three sections of the patch didn't apply directly. the if/else structure had changed so I added the has_touch.. just back in one of those (but I had kind of two options now). the 2nd section was probably nothing special. then in the 3rd section they have renamed bitMask to tabletBitMask among else.
[07:29] <mlankhorst> Mirv: looks good
[07:29] <Mirv> mlankhorst: ok, thanks. so what about the upstreaming of the patch, we can't carry it forever?
[07:30] <mlankhorst> do you want to submit it?
[07:30] <Mirv> mlankhorst: no, I've tried submitting for others before and it doesn't really work too well. so instead I've written instructions that 10+ people have successfully used: https://wiki.canonical.com/UbuntuEngineering/ContributingToQt
[07:30] <mlankhorst> ok but you touched it last, I'll ahve to take your version :P
[07:31] <Mirv> mlankhorst: feel free :)
[07:31] <mlankhorst> can you add me to the group?
[07:31] <Mirv> I can't answer any of the questions they may have about it, but at least now that version of the patch probably would apply to the trunk too
[07:32] <Mirv> mlankhorst: register first, or at least I don't find you yet? but yes it's a matter of seconds to add.
[08:04] <Laney> morning!
[08:09] <didrocks> hey Laney! how are things going?
[08:09] <kenvandine> good morning seb128
[08:12] <seb128> good morning desktopers
[08:12] <pitti> bonjour seb128
[08:12] <pitti> hey kenvandine, rickspencer3
[08:12] <seb128> kenvandine, hey, on european time I see
[08:12] <didrocks> hey pitti!
[08:12] <seb128> lut pitti, wie gehts?
[08:12] <pitti> wow, beaucoup de gens ici aujourd'hui :)
[08:12] <seb128> lut didrocks
[08:13]  * pitti hugs didrocks
[08:13]  * didrocks hugs pitti back
[08:14] <Laney> doing good thanks didrocks! and you?
[08:14] <Laney> & hi everyone else ;-)
[08:14] <didrocks> Laney: I'm great, thanks!
[08:31] <rickspencer3> hi pitti
[08:32]  * rickspencer3 goes to coffee break
[09:02] <Laney> didrocks: seen http://mjg59.dreamwidth.org/31714.html ?
[09:03] <Laney> Seems related to you these days ;)
[09:09] <didrocks> Laney: it's spot on! and exactly my feelings and thoughts :)
[09:19] <seb128> the comments have the typical linux 2009 users, saying that old GNOME was state of the art and GNOME3/Unity destroyed the world
[09:22] <Laney> https://twitter.com/avoidcomments :-)
[09:23] <seb128> lol
[09:28] <ali1234> he raises some good points but misses a key one, which is that remote search is a million times faster than having a local index, even if you have to open a web browser to access it
[09:29] <ogra_> dont say you read the comments !
[09:29] <ali1234> i didn't
[09:30] <ali1234> i tend to forget that other people don't use gmail
[09:30] <ali1234> so when i receive a bug email, i'm already in a web browser. leaving it to use some annoying desktop feature would just be a pain
[09:31] <ali1234> i suspect many of those mac wielding developers are much the same
[09:33] <ali1234> i also suspect they actually like web interfaces
[11:32] <Sweet5hark> https://gerrit.libreoffice.org/#/c/9406/ <- candidante for the commit message of the day ...
[11:37] <mlankhorst> disqualified *points at no libreoffice rule*
[11:40] <Sweet5hark> mlankhorst: no fair!
[11:42] <Sweet5hark> mlankhorst: it even has "enterprise-grade code base" "untimely demise" and "excerise for the interested reader"
[11:45] <didrocks> well, it's nice to think about others and let them filing the logic hole :)
[11:46]  * mlankhorst points at the sign
[11:46] <mlankhorst> sorry, no refunds
[11:47] <didrocks> ahah :)
[11:47] <Sweet5hark> *grumble*
[13:06] <om26er> Laney, regarding ringtone panel in system-settings, how does it play sound ??
[13:07] <Laney> om26er: QML has an Audio component
[13:07] <om26er> Laney, and it talks direct to pulseaudio ?
[13:08] <Laney> I don't know how it works :(
[13:14] <Laney> om26er: From reading the source quickly it looks like it does interface with pulse
[13:14] <Laney> why do you need to know?
[13:15] <om26er> Laney, I am working on automation of ringtone settng and I want to check with the backend if the current selected file is being played or not
[13:16] <Laney> om26er: ah, then http://qt-project.org/doc/qt-5/qml-qtmultimedia-audio.html might be interesting
[13:16] <Laney> it's got some properties and signals
[13:26] <om26er> Laney, thanks
[15:30] <seb128> it's meeting time!
[15:30] <Sweet5hark> aye
[15:30] <seb128> qengho, Sweet5hark, mlankhorst, Laney, tkamppeter, desrt, attente, KombuchaKip: hey, it's meeting time ;-)
[15:31] <Sweet5hark> short list! everyone else on the beach on Malta?
[15:31] <seb128> did I forgot people?
[15:31] <seb128> larsu is off, but he's the only one I think
[15:31] <larsu> indeed
[15:31] <brookswarner> hi Seb128 - i'm here but don't have anything :)
[15:31] <larsu> (oops)
[15:31]  * KombuchaKip waves
[15:31] <seb128> hey brookswarner
[15:32] <seb128> larsu, stay away from IRC ;-)
[15:32] <brookswarner> hey seb
[15:32] <seb128> ok, let's get started
[15:32] <seb128> qengho, hey
[15:32] <qengho> Hey!
[15:32] <qengho> * Chromium security update 34.0.1847.137 almost ready.
[15:32] <qengho> * Found the popup contents bug, menu size bug, window size creep bug is all one common DIP/DP conversion bug. Now fixing.
[15:32] <qengho> * Next, tabs, then input method.
[15:32] <qengho> EOF
[15:33] <mlankhorst> hey
[15:33] <seb128> nice to see you figured that bug out ... and that the session one is next ;-)
[15:33] <qengho> :)
[15:33] <seb128> qengho, thanks
[15:33] <qengho> It was a little tricky
[15:33] <qengho> Thanks.
[15:33] <seb128> let's hope the session one is easier :-)
[15:33] <seb128> Sweet5hark, hey
[15:33] <Sweet5hark> - updated LibreOffice 4.2.4 package in PPA
[15:33] <Sweet5hark> - fixed bug 1296715
[15:33] <Sweet5hark> - backported fix for bug 1219245
[15:33] <Sweet5hark> - re-applied revert for bug 1300283, apparently still needed even with recent upstream changes
[15:33] <Sweet5hark> - build LibreOffice some ~50 times more for bibisect (what you gnome guys call ostree): 4.3 alpha1 to 4.3 beta1 range
[15:33] <Sweet5hark> - forget this previously: when I recently wrote about "foundation work", one thing was pushing for http://blog.documentfoundation.org/2014/05/01/tdf-freelance-job-opening-201405-01-quality-assurance-engineer/ (e.g. writing part of the job description) so that we get a upstream QA engineer at TDF
[15:33] <Sweet5hark> EOF
[15:35] <seb128> Sweet5hark, do you have uploads to get sponsored soon? it feels like those bugfixes are worth a SRU
[15:35] <Sweet5hark> seb128: if nothing horrible happens feedbackwise from the version in the ppa, that one should be SRUed, yes. Lets have it sit there for ~a week though.
[15:36] <seb128> wfm
[15:36] <seb128> Sweet5hark, thanks
[15:36] <seb128> mlankhorst, hey
[15:36] <mlankhorst> Attempting to convince the radeon devs to take the fence patches :/, mesa 10.1.3 SRU testing with piglit, and bisecting the failure. Submitting qt touch patch upstream, more interaction will be needed. Stability fixes for xorg-server (LP: #1208473)
[15:36] <mlankhorst> ^D
[15:37] <seb128> is there an issue with the qt patch?
[15:37] <seb128> or just stuff to tweak?
[15:37] <mlankhorst> I guess they need to rework the input model to always use master devices if available
[15:37] <mlankhorst> but that's a bigger change than just listening to touch devices on master
[15:37] <seb128> ok ... is that something that upstream is going to pick?
[15:38] <seb128> is there an issue with the smaller change you had/can we still SRU that?
[15:38] <mlankhorst> it's sru'd and it works fine
[15:38] <seb128> great
[15:38] <seb128> mlankhorst, thanks
[15:38] <seb128> Laney, hey
[15:38] <Laney> why hello
[15:38] <Laney> • Mainly worked on the unity 8 image; I believe it now boots, don't know about installs though. Most things are in the archive. First lot of stuff is merge into ubuntu-cdimage, waiting for another round of reviews and a Launchpad change before trying a build.
[15:38] <Laney> • Updated gnome-terminal 3.12 patch that larsu supplied me with to add theme transparency back. Only shown if the current theme supports it, so hopefully we can still share the patch as-is with Fedora & co.
[15:38] <Laney> • Fix "automatically report crashes" not persisting in whoopsie-preferences
[15:38] <Laney> • Merge webkit 2.4.2, SRU to trusty
[15:38] <Laney> • Some package updates/merges/syncs: gupnp vte3 (needed for g-t 3.12) accountsservice libnice
[15:38] <Laney> • Review / Multi-Arch fix for ted's new pay-service package (£$¥€ for me)
[15:38] <Laney> ☀
[15:40] <seb128> Laney, thanks for the work on the unity8 image ... do you have an estimate on how much work that launchpad change might be?
[15:40] <Laney> i submitted it
[15:40] <Laney> it's just adding ubuntu-touch to a cron job
[15:40] <Laney> to generate the task fields
[15:40] <Laney> not a code change
[15:41] <seb128> ok, good
[15:41] <seb128> so looks like the changes are small enough that they might be landable this week
[15:41] <seb128> Laney, thanks
[15:41] <Laney> if people get time to review / deploy, yeah
[15:42] <seb128> great
[15:42] <seb128> thanks
[15:42] <seb128> tkamppeter, hey
[15:42] <tkamppeter> - cups-filters: First working version of a rastertopdf filter, without color management support (DeviceGray/DeviceRGB, DeviceCMYK).
[15:42] <tkamppeter> - cups-filters: Fixed PWG Raster output of Poppler-based pdftoraster, it was not compressed.
[15:42] <tkamppeter> - ghostscript: Fixed PWG Raster output, it was not compressed.
[15:42] <tkamppeter> - Bugs.
[15:43] <seb128> tkamppeter, thanks
[15:43] <seb128> desrt, hey
[15:43] <desrt> hey
[15:43] <desrt> very short week for me (double long weekend)
[15:43] <desrt> but i got mir building on fedora, under jhbuild even
[15:43] <seb128> nice!
[15:43] <desrt> took quite some patching, though, so i have to talk to duflu about some upstream changes
[15:43] <seb128> how much hackery needed?
[15:43] <desrt> .... a bit
[15:44] <desrt> there's some lib vs. lib64 issues, some library version trouble (too new features being used from one of the google utility libraries)
[15:44] <desrt> plus the test framework stuff isn't working at all, but it can be disabled
[15:44] <desrt> also docs are a bit broken (ie: 'make && make install' doesn't work -- you need 'make doc' as well, or disable the docs build)
[15:44] <desrt> plus they don't have a proper tarball -- it unpacks in the current dir and has .bzr/ in it
[15:45] <desrt> was mostly a case of figuring out the correct packages that need to be given as build deps
[15:45] <seb128> ok, all those seems reasonable issues, nothing fundamentally Ubuntu specific that would be difficult to resolve
[15:45] <desrt> but i've already gotten some moduleset additions here that i was actually able to have jhbuild drive cmake to install the thing into the correct prefix
[15:45] <seb128> great
[15:45] <desrt> that part actually worked completely perfectly -- and that's where i assumed the most trouble would be
[15:46] <desrt> robert also has a skeleton implementation of the mir backend already done
[15:46] <desrt> seems he did some weekend hacking
[15:46] <seb128> nice
[15:46] <desrt> i'm in transit today (in a few hours) so i may take a chance to try to get those things together on the plane
[15:47] <desrt> looks like this will not be a huge effort after all, at least to get it up to the point that rick specified
[15:47] <desrt> next on the todo list for me, while in malta: gtkapplication hacking
[15:47] <desrt> i'm going to want to talk to the mir guys about what sort of registration they like to see from me
[15:48] <desrt> and how the interaction will go between the high level gtkapplication stuff and the lowlevel gdk stuff
[15:48] <seb128> sounds good
[15:48] <desrt> nothing else to say :)
[15:48] <seb128> so basically robert took the backend part?
[15:48] <desrt> well -- it already existed
[15:48] <seb128> and you are dealing with the build, integration, etc
[15:48] <desrt> from the work done by sam and leslie
[15:48] <seb128> it started from Sam's work?
[15:49] <seb128> k
[15:49] <desrt> i think so -- he sent me a patch, but i didn't look in too much detail today
[15:49] <desrt> i want to get that building as part of the modulset as my next step
[15:49] <desrt> maybe with a better tarball release from upstream
[15:50] <seb128> ok, let's see what we manage to get/put the pieces together next week
[15:50] <seb128> desrt, thanks
[15:50] <seb128> attente, hey
[15:50] <attente> seb128: hey
[15:50] <attente> had to add more changes the the eclipse menu MP to fix a regression, and changes to the gtk patch proposed upstream
[15:50] <attente> the sru from last week for input switching under gnome shell has some issues which aren't easily reproducible, more debugging needed
[15:50] <seb128> desrt, oh, and safe travel!
[15:50] <attente> no progress on the java non-latin shortcuts issues, so can't sru it and will have to maintain the ppa for affected users instead...
[15:50] <attente> eof
[15:50] <desrt> seb128: thanks :)
[15:51] <seb128> attente, is the g-s-d/gnome-shell one creating regressions or just a non perfect fix?
[15:51] <seb128> because "better but not perfect" is fine to copy to updates
[15:52] <attente> seb128: a non-perfect fix
[15:52] <seb128> ok, that's something ;-)
[15:52] <seb128> attente, did the gtk patch got approved? (I didn't check out for updates)
[15:53] <attente> seb128: there was some back-and-forth, but the current one is waiting review
[15:53] <seb128> ok
[15:53] <desrt> attente: the idle-using one?
[15:53] <seb128> attente, thanks
[15:53] <attente> desrt: not using an idle any more
[15:53] <desrt> oh.  interesting.
[15:53] <desrt> i'll take a look
[15:53] <attente> mclasen didn't like it...
[15:53] <desrt> did you test all of the things that were breaking before?
[15:53] <desrt> heh.  figures ;)
[15:53] <desrt> the only patch that he liked so far is the one that broke everything :)
[15:54] <attente> desrt: thanks, hope it's ok...
[15:54] <desrt> meh.  he makes a good point.
[15:54] <attente> it fixes things on our end at least
[15:55] <attente> and there aren't a lot of consumers using submenu-action it seems
[15:55] <desrt> did you add a vtable function to GtkMenuShellClass in a public header?
[15:55] <attente> no, that should be private
[15:55] <desrt> let's talk later
[15:56] <desrt> i think this patch has a pretty big problem...
[15:56] <attente> sorry, i'm wrong, it is public...
[15:56] <attente> ok
[15:57] <seb128> desrt, attente: yeah, you guys can probably discuss it between yourself out of the meeting
[15:57] <seb128> attente, thanks
[15:57] <seb128> KombuchaKip, hey, do you have anything to share this week?
[15:59] <desrt> (seems not)
[15:59] <seb128> yeah
[15:59] <seb128> seems not
[15:59] <seb128> so my turn
[15:59] <seb128>  * Testing on the unity8/desktop iso and session, reported some issues
[15:59] <seb128>  * Discussed a bit click on unity8-desktop with mvo and the current issues
[15:59] <seb128>  * Some u-s-s reviews
[15:59] <seb128>  * Worked on desktop plans for the cycle and slides for the client week
[15:59] <seb128>  * Some bugs triaging
[15:59] <seb128>  * Some trusty SRUs

[16:00] <seb128> I'm going to be travelling to Malta tomorrow
[16:00] <seb128> then off to visit on thursday/friday
[16:00] <desrt> i've heard that all of the cool kids are going to malta
[16:00] <seb128> so see most of you on monday ;-)
[16:01] <seb128> or before at the hotel/bar/...
[16:01] <Laney> definitely a strict subset
[16:01] <seb128> ok, seems like a wrap then
[16:01] <seb128> thanks everyone!
[16:02] <om26er> seb128, who on your team works/worked on AccountsService ?
[16:02] <desrt> om26er: meish
[16:02] <om26er> need to find a way to read the value of a setting from there
[16:02] <desrt> om26er: i wrote the settings storage interface of it...
[16:02] <desrt> what do you need to know?
[16:03] <KombuchaKip> seb128: Finished refactoring a patch for Mozilla and sent back upstream. If that is accepted, I will begin SRU / PPA process. Now working on a UA issue for ACL related tasks (Eiciel).
[16:03] <om26er> desrt, the phone uses AccountsService to save ringtones, I just want to read from it which is the current ringtone, for automation purposes
[16:03] <desrt> om26er: that's a dbus call
[16:03] <seb128> KombuchaKip, seems similar to the previous week, how much progress did you do?
[16:03] <desrt> what's your environment?  shellscript?  C?  python?
[16:03] <om26er> desrt, python
[16:04] <om26er> bash may work as well.
[16:04] <desrt> om26er: are you using the gobject bindings or native python-dbus?
[16:04] <desrt> also: how much do you know about dbus?
[16:04] <KombuchaKip> seb128: Actually last week I was still correcting the patch after upstream wanted changes. I completed those changes and resubmitted. So far no complaints. Also, I've been working on the ACL issue.
[16:04] <seb128> ok
[16:04] <seb128> KombuchaKip, thanks
[16:04] <KombuchaKip> seb128: And Monday was Victoria Day here.
[16:04] <KombuchaKip> seb128: No problem.
[16:05] <om26er> desrt, not much about dbus, I have tried multiple things. I am trying to access with gi.repository
[16:05] <desrt> om26er: okay.  let me hack up a quick example for you
[16:12] <KombuchaKip> seb128: One other thing, I will be gone for the next ten business days, starting tomorrow on leave (my team already knows, but just giving you a heads up).
[16:15] <KombuchaKip> seb128: Possibly more time after that, but not finalized yet.
[16:18] <om26er> desrt, thanks, I am at the sprint and we are EOD, can you please me ?
[16:19] <om26er> *email
[16:19] <om26er> ;)
[16:19] <desrt> om26er: i'm a couple of minutse from being done
[16:20] <desrt> om26er: something like http://ur1.ca/hcorx
[16:21] <desrt> i can't test it since i don't have the ringtone schema locally...
[16:21] <desrt> you may in fact need to do result.get_variant().get_string()
[16:22] <seb128> back
[16:22] <seb128> (sorry, timeouted without noticing)
[16:22] <om26er> desrt, it says gi._glib.GError: Method 'Get' returned type '(v)', but expected 'v' ?
[16:22] <desrt> oh ya..  change that "v" to "(v)"
[16:22] <desrt> which means you'll also need to do result.get_child_value(0).get_variant().get_string() :)
[16:24] <desrt> om26er: working?
[16:24] <om26er> desrt,   File "<stdin>", line 7
[16:24] <om26er>     GLib.VariantType.new"(v)", Gio.DBusCallFlags.NONE, -1)
[16:24] <om26er>                             ^
[16:24] <om26er> SyntaxError: invalid syntax
[16:25] <Laney> ("(v)"
[16:25] <om26er> yeah
[16:25] <om26er> sorry I was being stupid
[16:26] <om26er> desrt, its returning NoneType
[16:27] <desrt> you're saying print result.get_child_value(0).get_variant().get_string()  ?
[16:27] <desrt> there is no way that i can imagine that NoneType should pop out of that...
[16:28] <desrt> much more likely you should see an exception or a glib critical...
[16:28] <desrt> (strictly speaking you should be checking that the return value is correctly typed -- but i hacked this very quickly)
[16:28] <om26er> desrt, its working now
[16:29] <desrt> great!
[16:29] <desrt> enjoy your evening
[16:29] <om26er> desrt, thank you :)
[17:11] <Laney> night
[17:11] <Laney> happy travels seb128 & desrt!
[17:28] <seb128> Laney, thanks, good luck for the next work day and safe travel this w.e as well!


[16:07] <dobey> pitti: still around?
[20:30] <Letozaf_> balloons, hi
[20:40] <balloons> Letozaf_, hello
[20:41] <Letozaf_> balloons, I am having problems with docviewer, I tried building it but cannot run autopilot test, how does it have to be built ?
[20:42] <Letozaf_> balloons, I tried from the root directory and form a build directory but does not work :(
[20:42] <Letozaf_> balloons, the README file does not say how to
[20:43] <Letozaf_> balloons, and also if I try to install ubuntu-docviewer-app I get a weired error
[20:44] <balloons> Letozaf_, I believe I built it using the standard cmake, make
[20:44] <balloons> what doesn't work?
[20:44] <balloons> it won't launch alone; it needs a file to be passed
[20:44] <Letozaf_> balloons, well I tried that and it builds
[20:45] <Letozaf_> balloons, but if I run autopilot tests they fail
[20:45] <balloons> weird.. with the latest trunk? they should work. Check and make sure you have the proper depends also
[20:46] <Letozaf_> balloons, I installed libpoppler-qt5-dev as the README file says...
[20:46] <balloons> Letozaf_, mmm, what's the log show?
[20:46] <Letozaf_> balloons, I will paste it, just a minute...
[20:47] <Letozaf_> balloons, http://paste.ubuntu.com/9493718/
[20:47] <dobey> who's one board for the coup against manual testing?
[20:47] <dobey> s/one/on/
[20:47] <balloons> Letozaf_, see the "     import com.ubuntu.fileqmlplugin 1.0 " failure?
[20:48]  * Letozaf_ is looking
[20:48] <balloons> dobey, cho cho
[20:48] <Letozaf_> balloons, yes found it
[20:50] <balloons> Letozaf_, did you install qtdeclarative5-poppler-qml-plugin?
[20:50] <Letozaf_> balloons, yes
[20:50] <Letozaf_> balloons, let me check again
[20:51] <Letozaf_> balloons, yes it says it's already installed
[20:51] <balloons> I believe  file-qml-plugin should be in-tree now
[20:51] <balloons> Letozaf_, you can always build it with qtcreator
[20:52]  * Letozaf_ is tryin
[20:52] <Letozaf_> trying
[20:52] <balloons> looks like I built it that way
[20:55] <Letozaf_> balloons,
[20:55] <Letozaf_>  File "/home/letozaf/autopilot-tests/ubuntu-docviewer-app/tests/autopilot/ubuntu_docviewer_app/tests/__init__.py", line 65, in setUp
[20:55] <Letozaf_>     'qml', self.qml)
[20:55] <Letozaf_>   File "/usr/lib/python3.4/posixpath.py", line 82, in join
[20:55] <Letozaf_>     path += b
[20:55] <Letozaf_> TypeError: unsupported operand type(s) for +=: 'NoneType' and 'str'
[20:55] <Letozaf_> :(
[20:55]  * Letozaf_ is looking at the code
[20:56] <balloons> eh?
[20:57] <balloons> Letozaf_, branching the code, opening the branch into the sdk and building it works. Then I run the autopilot tests as desired. It all works for me
[20:58] <Letozaf_> balloons, I will try doing everything all over again, just in case
[20:59] <balloons> Letozaf_, I just did it quickly and it worked fine, but ;-)
[21:02] <balloons> Letozaf_, I have to run, ping if you get it working or not :-)
[21:02] <Letozaf_> balloons, ok thanks
[21:02]  * balloons crosses fingers
[21:02]  * Letozaf_ too
[21:03] <balloons> gl and happy weekend to you
[21:03] <Letozaf_> balloons, happy week end to you too
[21:10] <Letozaf_> balloons, it does not work for me, I get two warnings when building in qtcreator:
[21:10] <Letozaf_> /home/letozaf/autopilot-tests/ubuntu-docviewer-app/src/plugin/poppler-qml-plugin/pdfModel.cpp:44: warning: unused parameter 'parent' [-Wunused-parameter]
[21:10] <Letozaf_>  int PdfModel::rowCount(const QModelIndex & parent) const
[21:10] <Letozaf_>                                             ^
[21:11] <Letozaf_> balloons, and:
[21:11] <Letozaf_> /home/letozaf/autopilot-tests/ubuntu-docviewer-app/src/plugin/poppler-qml-plugin/pageImageProvider.cpp:32: warning: unused parameter 'size' [-Wunused-parameter]
[21:11] <Letozaf_>  QImage PageImageProvider::requestImage(const QString & id, QSize * size, const QSize & requestedSize)
[21:11] <Letozaf_>                                                                     ^


[00:14] <mok0> I am fixing a piece of code that's giving me a bunch of warnings:  "deprecated conversion from string constant to ‘char*’" . The code becomes really ugly when you have to cast every string constant. What is the rationale behind this change of the C language?
[00:15] <ln-> if you have to cast every string constant, that sounds a lot like you're doing something wrong.
[00:15] <ln-> but what do i know, i'm not an ubuntu developer.
[00:16] <LaserJock> mok0: seems like I've read something about that recently, but can't for the life of me remember where
[00:17] <ln-> mok0: how about showing a piece of code that gives these warnings?
[00:18] <ion_> mok0: AFAIU a string constant should either go to a const char * or be strduped.
[00:20] <mok0> I can pastebin some code
[00:20] <mok0> you'll see it looks ugly
[00:20] <mok0> wait, I'll paste a oneliner here.
[00:21] <mok0>  if (showprogress) StartProgress((char *)"Locating Bonds",atom.size() );
[00:21] <mok0> every time there's a string constant, you have to cast it :-(
[00:21] <ln-> i'd say: You're Doing It Wrong
[00:21] <ion_> char *foo = "bar";  /* wrong, either use const char * or strdup */
[00:21] <geser> mok0: what does StartProgress expect? a char *?
[00:22] <mok0> const char *
[00:22] <geser> then remove the (char *)
[00:22] <mok0> Then you get the compiler error
[00:22] <mok0> warning
[00:22] <geser> Hi bddebian
[00:23] <bddebian> heya geser
[00:23] <ion_> mok0: Are you sure StartProgress expects a const char *? Please recheck.
[00:24] <mok0> ion_: it doesn't matter what it expects. I tried changing it
[00:24] <mok0> ion_: either way, you get the same warning
[00:25] <mok0> even in an initializer: const char *str = "Hello world";
[00:26] <mok0> This is g++ 4.2.3 from hardy
[00:26] <mok0> using -Wall
[00:27] <mok0> But it's going to give us tens of thousands of warnings from existing code :-(
[00:29] <geser> mok0: I just checked: I get the warning for "char * foo = "bar";" but not for "const char * foo = "bar";"
[00:29] <geser> mok0: luckily it just warnings an not errors
[00:31] <mok0> geser: what about in a function call ?
[00:31] <mok0> geser: I think I read somewhere that the policy recommends compilation with -Wall
[00:36] <geser> mok0: http://paste.ubuntu.com/3925/ (ignore the linking error)
[00:36] <geser> mok0: gcc (GCC) 4.2.3 20080114 (prerelease) (Ubuntu 4.2.2-7ubuntu1)
[00:37] <mok0> geser: you are getting the same warning
[00:37] <mok0> geser: I can't tell if it's both functions
[00:37] <mok0> ... or only func1
[00:38] <geser> mok0: I get it only for the func1 call
[00:38] <mok0> hmm
[00:38] <ln-> mok0: but doesn't that paste show the opposite of what you claimed?
[00:38] <mok0> ln-: I claimed that changing the function didn't make a difference.
[00:38] <mok0> geser shows that I am wrong
[00:39]  * mok0 wants to check again
[00:39] <geser> mok0: did you also changed the prototype in the header?
[00:40]  * mok0 forgot to change the prototype :-(
[00:42] <ln-> 02:15 < ln-> if you have to cast every string constant, that sounds a lot like you're doing something wrong.
[00:42]  * ln- can foresee the future.
[00:42] <mok0> ln-: Yeah.
[00:47] <mok0> ln-: the solution is to make string constants "const char
[00:47] <mok0> "const char *"
[00:48] <ln-> yes, but it's not a "string", it's a pointer.
[00:48] <mok0> ln-: aie
[00:49] <mok0> const char *str = "hello world";
[00:49] <mok0> but: char *str = "hello";  is commonplace
[00:52] <geser> but also wrong as you can't modify str without a segfault
[00:52] <geser> and the compiler will only warn you for const char *
[00:53] <mok0> geser: ? the compiler accepts the latter
[00:53] <mok0> former
[00:53] <mok0> sorry
[00:54] <geser> "hello" is by definition a const char *, so assigning it to a char * isn't wise
[00:54] <mok0> geser: yes
[00:54] <ln-> actually, you can modify str, but not *str
[00:55] <mok0> ln-: so, you can invalidate the pointer?
[00:55] <geser> ln-: yes, unprecise wording from my side
[00:56] <mok0> But, still, char *str = "hello"; is used all over the place, so there are going to be lots of things to change
[00:57] <ln-> mok0: not only invalidate, but you can make it point somewhere else.
[00:57]  * geser thinks about the difference between "const char *" and "char * const" again
[00:58] <geser> mok0: buggy code should be fixed instead of disable the warning
[00:58] <mok0> geser: exactly, that's what I mean
[00:59] <mok0> geser: Perhaps I'm ignorant, but I think the warning is pretty new
[00:59] <mok0> geser: I've never had to deal with it before
[01:04] <geser> mok0: I've seen it only recently too (since hardy, but I didn't look much at build logs during gutsy development)
[01:38] <berto-> hi everyone.  i am running 6.06.1 LTS server and compiled a Xen 3.0.4 kernel.  When I boot into the Xen kernel I lose my SATA tape drive (Quantum DLT-V4).  Anyone know if there are any special modules I need besides st and sg that are built into the Ubuntu kernel?
[01:40] <persia> berto-: It's a weekend, so most developers are not present.  Also, you might want #ubuntu, as that appears to be a support question.
[01:41] <berto-> persia: ok, thanks.  i've tried in #ubuntu, i'll try again.
[01:42] <persia> berto-: You might also try answers.launchpad.net/ubuntu/ if nobody currently around has an answer.
[01:42] <berto-> persia: will do, thanks!
[01:51] <berto-> persia: no luck in #ubuntu; i've posted a question on launchpad (https://answers.launchpad.net/ubuntu/+question/23184)  thanks for the tip!
[01:52] <persia> berto-: Your welcome.
[04:18] <linos2> anyone know where I could find a list of gcc command syntax for pentium and amd athlon processors
[04:20] <LaserJock> linos2: have you checked the gcc man/info pages?
[04:21] <linos2> LaserJock, no.. let me check. thanks
[04:25] <linos2> LaserJock, I am trying to find out information about the i586-mingw32msvc-gcc command.  I don't have it in my man pages.  Do you know where I could find this on the net?
[04:28] <LaserJock> linos2: google? sorry, I'm not much help
[04:28] <linos2> LaserJock, thanks anyway
[04:44] <coastGNU> lamont: ping
[04:50] <coastGNU> lamont: Is there a chance that #186274 (debian bug-No.462662) will make it to hardy before feature freeze?
[05:14] <linos2> can someone tell me what is the file name gentoo equivalent make.conf under ubuntu called?  thanks inadvance
[05:16] <persia> linos2: No direct equivalent
[05:16] <linos2> persia, where are the flags set under ubuntu kde desktop version edgy eft?
[05:18] <persia> linos2: Likely in the individual packages, although I think KDE has some commonality.  apt-get source for the package that interests you, and look in the rules file.
[05:18] <linos2> persia, ok thank you very much
[05:19] <linos2> persia, one last question, where is the file that contains the CPU type?
[05:19] <LaserJock> persia: those would just be additional flags no? aren't there common flags given to all?
[05:19] <LaserJock> linos2: /proc/cpuinfo?
[05:19] <persia> LaserJock: I don't think so.  debian/rules is just a makefile.
[05:39] <Nafallo> !weekend
[05:39] <ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
[05:45] <lamont> coastGNU: 462662 is on my list to evaluate - at first blush, the patch looks not-unreasonable.
[05:45] <lamont> given the submitter, I'm inclined to trust it
[05:50] <lamont> coastGNU: esp since feature freeze is 2 weeks away
[06:42] <coastGNU> lamont: submitter; thats why I told it Joey :)) Thanks a lot.
[06:42] <lamont> heh. ok
[06:42] <lamont> anyway, it'll be in the next upload
[06:42] <lamont> and patch filed upstream
[06:44] <coastGNU> I'm writing an article about oem setup of all major community distributions for the german freeX magazine. So giving that the patch will make it into hyrdy that would be a tremendous example how fast a suggestion makes it into a debian package. ;)
[06:44] <coastGNU> s/hyrdy/hardy/
[10:52] <lool> A wave of FUD on Ubuntu SRUs is spreading on Planet GNOME :-/
[10:54]  * Fujitsu sighs.
[10:54] <Fujitsu> `common sense actions'
[10:54] <Fujitsu> It's common sense to update packages in stable releases without a good reason. I see.
[10:57] <lool> It's completely unfounded critics: the examples taken are glomm which is supposed to have serious bugs rendering it unusable but not visible in Launchpad -- if true this warrants a SRU; gnome-games which saw a SRU for gutsy already; and gnome-games being out of date in *hardy* while it simply didn't build because of a new build-dep which needs promotion to main
[10:58] <lool> And then everybody running screaming that you should run Fedora instead
[11:09] <geser> does Fedora have a "better" SRU policy?
[11:12] <Fujitsu> geser: I believe they just push new upstreams.
[14:18] <Mithrandir>  │ A new version of configuration file /var/run/grub/menu.lst is available, but the   │
[14:18] <Mithrandir> wtf?
[14:19] <Mithrandir> configuration files in /var/run, now that's a new one.
[15:08] <snikker> i've got some trouble to run vmware (libpng12 error) after the update of some packages, i'm under gutsy on amd64
[15:12] <ScottK2> snikker: See /topic.  This isn't a support channel.
[15:13] <snikker> ScottK2: yes, i know, but i've already tried yesterday in #ubuntu with no success... now i try again..
[15:16] <Seveas> snikker, that doesn't make this a support channel.
[15:17] <snikker> Seveas: ok, sorry for that...
[15:17] <ln-> yeah, next you will be instructed to get a support contract.
[15:19] <\sh> ln-, ?
[15:21] <Nafallo> \sh: get a support contract ;-)
[15:29] <\sh> Nafallo, ;)))
[15:30] <\sh> who do I need to bribe to add more libs to ia32-libs?
[15:40] <ln-> keescook: what does " Declined  for Dapper  by Kees Cook  "  mean in this context: https://bugs.launchpad.net/bugs/cve/2006-7229 ?
[15:41] <geser> \sh: ia32-libs is in universe and TIL is pitti
[15:43] <\sh> geser, well, if it's in universe I could do all by myself...great....
[15:51] <\sh> ln-, because it's already fixed in linux-source-2.6.15_2.6.15-26.47?
[15:51] <\sh> ln-, http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-source-2.6.15/linux-source-2.6.15_2.6.15-26.47/changelog
[15:51] <\sh>  * skge: Update to version in 2.6.17, to obtain fixes and D-Link DGE-530T
[15:51] <\sh>     support.
[15:51] <\sh>     - Malone: #55847
[15:53] <ln-> and when is this linux-source-2.6.15_2.6.15-26.47 coming out, or is it out already?
[15:53] <ln-> because... the latest Dapper kernel still suffers from this bug.
[15:54] <ln-> that is, 2.6.15-51-686.
[15:58] <\sh> ln-, it was already released
[15:59] <\sh> ln-, if this issue still exists, please ping benC on ubuntu-kernel and ask why the fix is not working anymore...
[15:59] <\sh> 2.6.15-51 looks like a dapper-proposed kernel to me
[16:02] <Nafallo> \sh: the fix is not working cause the user has the wrong kernel :-)
[16:02] <Nafallo> so no need to ping Ben about it.
[16:03] <ln-> what is "the wrong kernel", and what would be "the right kernel"?
[16:03] <\sh> Nafallo, well, the proposed kernel series could be the next -security upload, so it should contain the 2.6.17 skge source as described in the changelog :)
[16:04] <Nafallo> \sh: but it isn't from what I remember
[16:04] <Nafallo> the 50 ABIs are something weird and obscure :-P
[16:04] <\sh> Nafallo, then something went wrong with it...so the -kernel guys are the right people to ask why...
[16:04] <ln-> 2.6.15-51-686 came through apt as a normal update.
[16:05] <Nafallo> ln-: what happens if you use 26.47 or later?
[16:05] <calc> has anyone noticed that nautilus can't open text documents unless they end in .txt now?
[16:05] <\sh> ln-, check your sources.list please..if you have dapper-proposed enabled
[16:05] <calc> its something that appears to have changed in gnome/nautilus in the past couple weeks
[16:05] <calc> it says "There is no application installed for this file type"
[16:05] <calc> for a text file i have called "irc.channels"
[16:06] <ln-> \sh: no, i don't have.
[16:06] <Nafallo> calc: lots of stuff has that. docx, rar, zip amongst other.
[16:06] <calc> Nafallo: huh?
[16:07] <calc> Nafallo: this is just bog standard text edited with vi, before gnome/nautilus knew how to open it, i think it probably used 'file' to determine what it was, now it seems it must be using the file extension
[16:07] <Nafallo> calc: that they are not associatied. at least here.
[16:07]  * calc probably needs to ping seb128
[16:07] <calc> looks like he isn't online right now though
[16:09] <ln-> Nafallo: 26.47 is in dapper-proposed or something?
[16:09] <calc> Nafallo: but yea i know what you mean wrt docx, etc
[16:09] <calc> Nafallo: this is happening on just a standard text file
[16:09] <calc> ccheney@desktop-c2d:~/Desktop$ file irc.channels
[16:09] <calc> irc.channels: ASCII text
[16:09] <calc> nautilus should be able to figure that one out (it used to anyway)
[16:09] <\sh> ln-, the last dapper-security kernel image is Package: linux-image-2.6.15-25-686 as far I can read the Packages.gz from dapper-security
[16:11] <\sh> ln-, and Package: linux-image-2.6.15-51-686 comes from dapper-proposed
[16:11] <\sh> ln-, so you have somehow dapper-proposed channel activated somehow
[16:11] <ln-> err.. we used 2.6.15-25-686 something like more than 6 months ago, since then there have been -26, -27, -28 and -29, and now -51.
[16:12] <Nafallo> https://edge.launchpad.net/ubuntu/+source/linux-source-2.6.15
[16:12] <\sh> well dapper-security is the latest kernel-image linux-image-2.6.15-29-686 to be more accurate
[16:13] <crimsun> linux-source-2.6.15 | 2.6.15-51.64 | dapper-updates | source, all
[16:15] <\sh> crimsun, bah...that's why I don't use -updates on my dapper server ;)
[16:25] <ln-> actually, i don't think i'll be spending any more time trying to get this bug fixed.  if a trivial vulnerability cannot be fixed in 15 months, then it obviously cannot and will not.
[16:25] <\sh> ln-, as I said, ask BenC .. he knows why this is not anymore in the -updates kernel...
[16:26] <ln-> "anymore"? has it been at some point?
[16:27] <\sh> ln-, in the -security kernel skge source was updated to the 2.6.17 skge source...so yes, -security kernel has (should have) the fix ready...I don't know why -updates kernel doesn't have, but I'm not using -updates packages at all, only -security
[16:28] <ln-> \sh: are you referring to 2.6.15-26.47 in the changelog, and the line: "skge: Update to version in 2.6.17, to obtain fixes and D-Link DGE-530T support." ?
[16:29] <\sh> ,
[16:29] <\sh> ln-, yes
[16:29] <ln-> \sh: in that case, take a close look at this bug report: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/65631
[16:29] <ubotu> Launchpad bug 65631 in linux-source-2.6.15 "skge driver broken: invalid call to spin_unlock causes system crash" [Medium,Fix committed]
[16:29] <ln-> i.e. the one related to the CVE report.
[16:30] <ln-> \sh: it appears that the update from 2.6.17 was exactly when the driver was *broken*, not fixed.
[16:37] <\sh> ln-, then something really strange happend, and it's still a bug for the kernel guys...
[17:42] <CarlFK> UsePAM fell out of hardy's /etc/ssh/sshd_config - where can I see proof, and maybe a reason not to file a bug report?
[17:43] <Chipzz> debian changelog would be a good place to start
[17:44] <CarlFK> according to #debian, it is still in
[17:44] <Chipzz> no, the debian changelog of the package
[17:44] <Chipzz> lemme give ou a hint
[17:44] <CarlFK> ah - is this the most recient: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssh/openssh_4.7p1-2/changelog
[17:45] <Chipzz> zless /usr/share/doc/openssh-server/changelog.Debian.gz
[17:50] <CarlFK> "    - Remove hacks to support the old PAM configuration scheme."   think that applies to
[17:50] <CarlFK> UsePAM?  the change caused an account to get locked out
[17:52] <CarlFK> er, that sounds like a migration issue.  fresh box, same setup that worked on gutsy doesn't work on hardy
[18:02] <CarlFK> cjwatson your name is on openssh_4.7p1-2/changelog - should I assign a bug against it to you?
[18:02] <CarlFK> hi buddy :)
[18:03] <Nafallo> CarlFK: you never assign bugs to anyone else.
[18:04] <Nafallo> CarlFK: I'm sure Colin has OpenSSH as bug contact.
[18:04] <CarlFK> Nafallo: are you saying that as the general policy, or did you scan my bug reportting history and see a trend? :)
[18:05] <Nafallo> CarlFK: I'm saying that is the policy.
[18:05] <Nafallo> CarlFK: subscribe, but not assign.
[18:06] <CarlFK> Nafallo: figured.  it just happens that 90% of the bugs I find seem to fall into Colin's inbox
[18:11] <\sh> who is responsible for the ubotu bot?
[18:12] <Mithrandir> \sh: seveas, I believe
[18:13] <\sh> Mithrandir, thx
[18:13] <ln-> where is the discussion about the recent xorg update that broke things?
[18:13] <ln-> the why-it-happened-and-how-to-prevent-it discussion.
[18:15] <\sh> ln-, on the ML?
[18:15] <\sh> ln-, if there was such a discussion, then on the ML or in one of the bug reports
[18:16] <ln-> one of the bug reports it was implied that there would be such a discussion, and i was wondering if someone has a url to it, if it ever took place.
[18:44] <\sh> what could trigger an restart of trackerd even with trackerd disabled in gnome-session management?
[18:46] <ion_> Some program querying its DBus interface, i think.
[19:32] <zoke> are we shipping hardy with NM 0.7 ?
[19:41] <Riddell> evand: seen this? http://ubuntuforums.org/showthread.php?p=4214799
[20:33] <Skiessl> can someone make a multithreaded version of pdfcrack? :/ it's too slow atm
[20:53]  * Mithrandir kicks java in the nuts.
[20:56] <Mithrandir> I can choose between icedtea which doesn't contain HTTPS/SSL support or j2re1.4 which dies with java_vm: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
[20:56]  * Mithrandir sighs and goes to do something else.
[20:57] <Fujitsu> There's an environment variable you can set to fix that error.
[20:57] <Mithrandir> X_STAB_HARDER?
[20:57] <Fujitsu> Hah.
[20:58] <Fujitsu> LIBXCB_ALLOW_SLOPPY_LOCK, perhaps.
[20:58] <Fujitsu> Set it to 1.
[20:58] <Jultomten> I'm having trouble with Apache 2.2.4/Ubuntu 7.10 hanging after a while, answering connections but not providing any responses. Anyone feel like helping me debug it? It's hung right now.
[21:03] <persia> Mithrandir: Running sed -i 's/XINERAMA/FAKEEXTN/g' /opt/sun-jdk-<IP_ADDRESS>/jre/lib/i386/xawt/libmawt.so for sun-java6-bin is also reported to work (see bug #87947)
[21:03] <ubotu> Launchpad bug 87947 in libx11 "xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." [Medium,Fix released] https://launchpad.net/bugs/87947
[21:06] <Chipzz> Jultomten: this channel is not for support
[22:16] <jdong> vorian: hey, ktorrent-kde4 3.0~rc1 is out, ktorrent.org, you gonna grab it?
[22:16] <vorian> jdong: sure\
[22:18] <jdong> vorian: awesome :)
[22:18] <vorian> jdong: what version were we going with here?
[22:18] <jdong> vorian: 1:3.0~rc1 should work?
[22:19] <vorian> ah, right
[22:19] <vorian> :)
[22:19] <jdong> http://ktorrent.org/downloads/3.0rc1/
[22:19] <vorian> already working on it jdong :)
[22:19] <jdong> :)
[22:19] <jdong> one step ahead :)
[22:36] <jdong> vorian: you got the watchfile okay, or do I need to give you the one I just wrote for 2.x.x?
[22:37] <vorian> jdong: this worked for me
[22:37] <vorian> http://ktorrent.org/downloads/([0-9].*)/ktorrent-(.*)\.tar\.bz2
[22:38] <vorian> (and notated on the changelog)
[22:38] <jdong> vorian: I'd do (^3\.[\d\.]+) for the directory
[22:38] <vorian> I'll give it a whirl
[22:39] <jdong> vorian: currently both give the same result but it's better if we more explicitly catch the 3.x.x series
[22:39] <vorian> good point
[23:11] <bryce> lool: I've also heard sru-related issues from other corners
[23:12] <bryce> lool: I myself have felt the process to be rather bureaucratic and overly time consuming
[23:13] <bryce> lool: unfortunately, when I raised the concern (particular as related to sru's for X drivers), the sense seemed to be "It's good that it's hard and time consuming to do sru's, that way people won't bother doing them unless it's extremely important."
[23:14] <bryce> lool: yet I think in actuality the result is people also aren't doing sru's even when it *is* important.
[23:15] <bryce> lool: I also worry that out of hand dismissing complaints about the sru process, may result in hiding real problems that may end up hurting Ubuntu longer term
[23:16] <LaserJock> bryce: I think perhaps a "backporting only" policy is also a bit frustrating for upstreams that do bug-fix only releases
[23:17] <bryce> LaserJock: that's certainly true
[23:17] <jcastro> bryce: LaserJock: I just sent a mail to the upstream guys wrt. the SRU policy
[23:19] <bryce> LaserJock: it's ironic that with Inkscape, I put a lot of extra effort to ensure we got 0.45.0 out in time for Feisty feature freeze - which we did but missed several important bugs in the process - and then put out a subsequent 0.45.1 bugfix-only release to fix the issues, but it ended up that every release EXCEPT Ubuntu benefitted from the bugfix release.
[23:19] <bryce> er, "every distro EXCEPT Ubuntu..."
[23:19] <jcastro> bryce: I think revisiting the SRU policy might be a good idea
[23:19] <elmo> bryce: well you could avoid that by targeting beta, like gnome does/we do with gnome
[23:19] <jcastro> especially if upstream is jumping up and down
[23:19] <LaserJock> elmo: but that's only to a certain extent
[23:20] <elmo> and I'd like to balance 'woo SRUs for all' by reminding people that we can only take so many 'blue screen of death' SRUs...
[23:20] <LaserJock> elmo: what about bug fixes after Ubuntu's release
[23:20] <bryce> elmo, well, we'll see... we're going to be in a similar situation this time around
[23:21] <LaserJock> elmo: yes, but should we punish *all* packages for that? It seems to me that some sort of differentiation between X and kernel type packages that are hardware-related and more difficult to ensure no regressions and desktop packages that have a much lower risk of "big" problems
[23:22] <LaserJock> seems to me that 1-2 weeks of -proposed testing should easily determine if a SRU is gonna work or not
[23:23] <LaserJock> that first sentence wasn't "well formed" exactly
[23:24] <LaserJock> just trying to say that our exposure to risk is fairly dependent on the type of software and how upstream does releases
[23:26] <elmo> LaserJock: sure.  but there's also sometimes a big disconnect between upstreams and the impacts of changes they're making
[23:26] <elmo> on users
[23:26] <elmo> you say 1-2 weeks of -proposed testing is enough for anyone, but I'd ask how we know it's getting tested in proposed
[23:27] <bryce> LaserJock: agreed - particularly in the case of a discrete end application like Inkscape, the worst damage that can occur would be that inkscape would be broken, but it would certainly be not in our upstream interest to risk that
[23:27] <elmo> stuff going into -updates scares the hell out of me.  -security is a necessary evil, but I (and I'm just one data point of course), would run around disabling -updates on users computers if the SRU policy got any more slack
[23:27] <bryce> I can see a strict policy being more important with kernel, driver, or library updates
[23:28] <jcastro> bryce: I was just brainstorming that a "desktop SRU" might be a good idea
[23:28] <elmo> I don't understand the fixation on hardware related packages.  if someone takes out thunderbird in -updates, it might as well be X, for users in our office, f.e.
[23:28] <jcastro> for desktop apps
[23:28] <elmo> no mail - no work
[23:28] <jcastro> elmo: but what if you get an explicit message from upstream to ship an upgrade?
[23:28] <LaserJock> elmo: true, but testing is easier, in general
[23:29]  * Fujitsu notes that we have enough breakage in -security, and daren't think what a slacker SRU policy would do.
[23:29] <elmo> jcastro: that should be taken into account, but it's not gospel, any more than we don't ship completely unmodified packages from upstream as a rule
[23:30] <jcastro> elmo: fair enough
[23:30] <elmo> LaserJock: yeah, that's a fair point
[23:30] <LaserJock> Fujitsu: but if upstream is fixing bugs for our users why should we not get those fixes to users?
[23:30] <elmo> it's possibly worth pointing out that the last couple of major breakages in -security have come from _upstream's fixes_
[23:30] <emgent> heya
[23:30] <Fujitsu> elmo: Exactly.
[23:31] <Fujitsu> Samba, X...
[23:31] <LaserJock> yes, that can certainly happen
[23:31] <elmo> LaserJock: hello, false dichotomy ;-)
[23:31] <jcastro> elmo: and on top of that, some upstreams do bugfixes only on certain branches, and some do new feature work
[23:31] <jcastro> it's a tough problem to fix
[23:31] <LaserJock> but throwing out the baby with the bath water is not helpful
[23:31] <bryce> I'd never argue that testing should not be thoroughly done or that the process should be "slacker"; but that the sru process as currently written is extremely labor intensive to whomever wishes to push the sru along, and is likely resulting in people not wishing to help in the sru process, with the consequence that justifiably important sru's are not getting through.
[23:31] <LaserJock> if what we need is more testing then fine, let's get better testing
[23:32] <LaserJock> but our current policy is to basically not even let a lot of things get that far
[23:32] <Fujitsu> Where do we get better testing?
[23:32] <elmo> LaserJock: err, how so?
[23:32] <jcastro> is there an lp query that shows pending SRUs that haven't been applied?
[23:33] <bryce> also, as the SRU page indicates, SRU != security updates
[23:33] <bryce> security updates have a much slacker process than the SRU process
[23:33] <LaserJock> elmo: our current policy is turning off people because of "excessive bureaucracy" and we have a "backport only" policy rather than allowing a new upstream release
[23:33] <bryce> since they can't wait several weeks or months to go out
[23:33] <LaserJock> Fujitsu: well, the guy I talk to said maybe some better PR "Get the latest gnome early!!" might help
[23:34] <LaserJock> as far as I can tell very few people are being recruited to test
[23:36] <bryce> LaserJock: I had really good results recruiting testers via the forums for checking my Xorg packages during gutsy
[23:36] <LaserJock> I certainly don't have the solutions here, but it seems that Ubuntu is much stricter for SRU than other distros
[23:36] <bryce> agreed
[23:36] <Burgundavia> fedora is loser, but then has isuses with that
[23:37] <asac> bryce: well you can get general feedback, but you will miss corner cases ... and those are mostly the ones that regress in such an upstream-bugfix-only-release
[23:37] <LaserJock> and it makes me wonder if were fixing a lack of testing by using stricter policy
[23:37] <LaserJock> *we're
[23:37] <Fujitsu> Fedora appears to push new upstream versions for security fixes, even if they have other fixes/features.
[23:38] <asac> LaserJock: we allow reviewing by that policy ... and reduce the risk of regressions
[23:38] <LaserJock> asac: but a lot of people look at the policy and just don't bother
[23:38] <LaserJock> I would think that the "weeding" out should be done at testing time, not paperwork time
[23:38] <elmo> so, one thing I don't understand about "it's too bureaucratic" - can you give a concrete suggestion of how it could be made less so?
[23:39] <LaserJock> elmo: well, if you look at Fedora basically any developer can push to -updates and the often push new upstream release
[23:40] <LaserJock> or rather to a -proposed like repo
[23:40] <elmo> LaserJock: so you're advocating removing the entire SRU process?
[23:40] <asac> LaserJock: well ... testing is good, but as i said above, its not enough: you will surely miss corner cases.
[23:40] <bryce> elmo: I would point to the length of https://wiki.ubuntu.com/StableReleaseUpdates as a starting point - it's tiring to read let alone follow all the steps
[23:40] <LaserJock> elmo: umm, I guess I'm saying that that seems to work for others
[23:40] <jcastro> elmo: http://blogs.gnome.org/phomes/2008/01/26/ubuntu-update-policy-suckage/
[23:40] <Fujitsu> Does it work?
[23:41] <LaserJock> elmo: I'm not convinced that we need *no* SRU policy, but perhaps a significantly looser one would still work
[23:41] <jcastro> LaserJock: I don't think comparing to fedora is fair
[23:41] <LaserJock> oh?
[23:41] <LaserJock> why not?
[23:41] <jcastro> they specifically don't have a "stable" release like we do
[23:42] <Fujitsu> Don't they?
[23:42] <jcastro> they like, push new major kernels, dbus, etc., to their "stable" release
[23:42] <LaserJock> but they have a very succesfull product
[23:42] <Fujitsu> Ew.
[23:42] <jcastro> "stable" being defined as "unchanging"
[23:42] <broonie> Automated building of SRU candidates without an ack from the team might be helpful for jollying the process along (this may be happening now, duno).
[23:42] <LaserJock> jcastro: but that's exactly what people are often upset about
[23:43] <jcastro> LaserJock: that depends.
[23:43] <asac> LaserJock: you usually don't know the voice of those that are happy - even though they might be the majority
[23:43] <jcastro> If I was deploying something, in production, I don't want major new versions, I want something unchanging
[23:43] <elmo> LaserJock: dude
[23:43] <elmo> LaserJock: you're never going to make everyone happy
[23:43] <bryce> elmo: there are a lot of "musts" which are sometimes difficult to do.  For example, you "must" provide a test case to reproduce the issue.  In many cases users will tell you "X randomly fails," and confirm that such and such a patch fixes it.  But then you're left having to translate "randomly fails" into a reproduceable test case.  I usually just give up and refuse to sru the fix.
[23:43] <LaserJock> elmo: granted
[23:43] <geser> people will also complain if one updates of hundred breaks their system
[23:44] <jcastro> ^^^
[23:44] <elmo> LaserJock: if you removed the SRU process like you suggested, I would start a blog just so I could rail about how much Ubuntu sucks
[23:44] <Fujitsu> geser: Rightly so.
[23:44] <LaserJock> but it seems like we're working much more on the assumption that our stable releases are "stable" and "bug free" than is reality
[23:44] <elmo> LaserJock: some of us value stability and can deal with known bugs vs the risk of regressing production environments
[23:44] <jcastro> elmo: he didn't suggest removing the SRU process, just relaxing it
[23:44] <elmo> jcastro: actually he did
[23:44] <bryce> elmo: I also ran into massive bureaucracy with trying to get 0.45.1 into feisty.  That bug fix release had several dozen patches to fix a wide variety of issues reported upstream.  It was reviewed and only 4-5 were deemed "critical fixes".
[23:44] <crimsun> does Ubuntu have a release manager who can kindly override SRU policy?  (where "kindly" obviously implies "sanely")
[23:44] <LaserJock> elmo: no, I didn't, I said that was what Fedora did
[23:45] <LaserJock> elmo: I said previously that I think relaxing it might be a sane thing, but not getting rid of it entirely
[23:45] <jcastro> I don't think that doing something because Fedora does it is a good idea either.
[23:45] <LaserJock> no, of course not
[23:46] <LaserJock> I'm just trying to look at examples
[23:46] <bryce> elmo: unfortunately, the main issue users complained about wasn't included in that list, and 2-3 of the fixes were hard to describe.  Also, extracting those specific 4-5 fixes from the set was time consuming since upstream hadn't individually called out each patch.
[23:46] <jcastro> fair enough
[23:46] <Fujitsu> bryce: One should shoot upstream in that case. If you stab them enough, they normally eventually release sane patches.
[23:46] <LaserJock> because if upstreams are saying "Ubuntu is a problem because it's not taking our bug fixes" I'd like to know it it's really us or if that's a general problem with all distros
[23:46] <elmo> Fujitsu: ha ha.  bryce == upstream
[23:47] <elmo> bryce: sure, I'm not arguing the current practice is perfect.  and perhaps y'all should get a similar exemption to the gnome guys
[23:47] <LaserJock> crimsun: that'd be nice
[23:47] <jcastro> I think that there should be an SRU process where upstream can say "we're upstream and we'd like this version to be the one in a stable ubuntu release."
[23:47] <elmo> bryce: I'm just super leary of more breakage in -updates, and think the 'make SRUs easier' crowd are waving their hands a little vigourously ;-)
[23:47] <broonie> It might also help if the process were more directly implemented in Launchpad - given the latency involved it'd be good to avoid procedural errors.
[23:47] <bryce> Fujitsu: trust me, I was thinking seriously of shooting myself after going through all this!
[23:48] <elmo> broonie: yes, that jumped out at me too
[23:48] <elmo> there's a lot of manual fluff in there that could at worse be scripted, or better yet have built-in LP support
[23:48] <LaserJock> yep
[23:49] <superted> does anyone know if there will be any regularity to language packs in hardy and if so how often they will be realeased?
[23:49] <LaserJock> elmo: I think I'd advocate "make SRUs saner" over "make SRUs easier"
[23:49] <asac> LaserJock: for that you need to state what is not sane atm
[23:49] <asac> ?
[23:49] <LaserJock> asac: blanket policies
[23:49] <LaserJock> lots of manual work
[23:50] <LaserJock> when, as elmo said, a lot of this should be in LP
[23:50] <bryce> elmo, it seems that the only two options are excessive hand waving, or just ignoring the whole SRU process and let users suffer
[23:50] <bryce> I hate to admit that I've pretty much adopted the second option.
[23:50] <jcastro> asac: but in this case, bryce is upstream, shouldn't he have direct control of how his package is represented in ubuntu?
[23:50] <elmo> bryce: I strongly disagree
[23:51] <elmo> bryce: the problem is both you and laserjock are complaining but unwilling to break things down into _specific_ things which could be improved
[23:51] <LaserJock> elmo: ok, let me break it down, at least as far as I can see it
[23:52] <LaserJock> 1) better tracking of upstream release of stable series
[23:52] <geser> jcastro: that assumes a sane upstream that only wants a bugfix release in a stable distro and not the last and "best" release of their software
[23:52] <LaserJock> 2) some sort of classification or tiering that make high-risk packages harder to break and low-risk packages easier to update
[23:53] <LaserJock> 3) increased testing efforts
[23:53] <jcastro> geser: yep. that's what makes this so hard. You can't have a blanket policy if you want to make everyone happy, it really all depends per-project
[23:53] <jcastro> which is why this is so hard
[23:53] <LaserJock> those are a few things that I think might help
[23:53] <bryce> elmo, ok I thought I was being specific enough:  Reduce the number of steps, quantity of labor, and number of iterations with reviewers/approvers involved in filing an SRU.
[23:53] <jcastro> you can't just blindly say "upgrade at will, you're upstream."
[23:54] <asac> jcastro: in general i would say no. upstream will always push to fix as many bugs as possible, so their application is perceived as prefect as possible to the majority of their users. the distro itself is more scared about regressions that might hit a minority of production deployments.
[23:54] <elmo> asac++
[23:54] <jcastro> asac: probably because upstreams mostly care about their package, not how it affects the rest of the distro
[23:54] <LaserJock> asac: right, so we're trying to get as many fixes with the least amount of regressions
[23:54] <asac> jcastro: for bryce case, i don't know ... their is certainly a conflict and it depends on how he resolves this in his own heart
[23:54] <elmo> bryce: well, umm, not being funny, but 'reduce the number of steps' isn't specific.  "take out step 5, it's unnecessary for this reason" would be specific
[23:55] <bryce> elmo, I went through a number of ideas with pitti at the previous sprint, but basically got told, no, no, no, no.  So I gathered there was little benefit to try giving specific change requests; everything just gets denied.
[23:55] <jcastro> asac: for example in your case, if we blindly accepted FF's upgrades and just upgraded everything, half the distro would break
[23:55] <asac> jcastro: right ... well fixing bugs will benefit them more, but we have to be the ones denying requests so we can really claim to provide a stable distro
[23:56] <crimsun> bryce: did you suggest a $release-proposed-upstream component?
[23:56] <jcastro> bryce: out of curiosity, do you guys have an inkscape ppa?
[23:56] <asac> jcastro: yes ... unfortunately firefox is really a case where we do this ... and i always start to pray after the upload - which is why how hard it is to guaranteee regression-freeness.
[23:56] <elmo> (I have to run away - interesting discussion though...)
[23:56] <jcastro> nite elmo
[23:56] <LaserJock> asac: but FF is a bit of a tough case
[23:56] <asac> (i try to review as hard as possible, but there are 200 bug fixes vs. 70 security fixes in such a release)
[23:57] <asac> LaserJock: yes, but we track them carefully ... we have to think about all packages if we want to come up with a policy
[23:57] <asac> there might be upstreams with really strict policies ... but there might be ones with slacky policies
[23:57] <LaserJock> asac: but that's my point, we need finer grained policy. A blanket policy doesn't seem to really suffice
[23:57] <jcastro> asac: EXACTLY!
[23:57] <bryce> jcastro: yes we do
[23:57] <asac> but those that have strict policies usually provide individual patches anyway
[23:58] <asac> and thus providing them as "backports" shouldn't be a problem
[23:59] <asac> LaserJock: well ... the reviewer somewhat has to decide and who can bend the policy. its mostly about what is "critical" and how risky do those patches look like
[23:59] <asac> so its not really a blanket policy atm imo


[13:11] <rsalveti> hey, created a new ppa but the ppa public key is not yet available at keyserver.ubuntu.com (for more than one hour already), is there any known issue related to keyserver.ubuntu.com?
[13:11] <rsalveti> issue seems similar to https://answers.launchpad.net/launchpad/+question/670589
[13:12] <rsalveti> the ppa I created earlier today: https://launchpad.net/~fio-maintainers/+archive/ubuntu/ppa
[13:16] <rsalveti> more of the same issue https://answers.launchpad.net/launchpad/+question/670706


[02:22] <JackyAlcine> So I'm reading about Wayland and Natty, is it as great as they claim? No tearing?
[02:30] <lifeless> not yet :) early days still
[02:31] <JackyAlcine> I'm curious; I want to get int some hardcore soon, after I harness GTK+
[14:04] <ricotz> Sweetshark, hello :-), are you going to add libreoffice packages for lucid to the ppa as well?


[11:17] <Mirv> greyback: can you slip https://code.launchpad.net/~timo-jyrinki/qtubuntu/build_dep_libinput-dev_qt55/+merge/254365 into a landing at some point?
[11:17] <greyback> Mirv: ack, will do
[11:18] <Mirv> thanks, not a huge problem but nice to have for no-change rebuild tests
[13:02] <kgunn> dednick: just following up on inline video/audio, ready to rock?
[13:02] <kgunn> as in land :)
[13:36] <dednick> kgunn: still some issues
[13:37] <dednick> jim is working on them
[22:06] <hggdh> this is cool (but wrong) updated Wily to latest, rebooted; dual-monitor setup lost, reset it; got a message on a different pane to accept/reject the config (found it 1200 seconds later)
[22:07] <hggdh> the message currently states the config will be reversed in -1246 seconds


 test
 hey it works!
[14:47] <ahoneybun> test
[15:06] <ahoneybun> tes
[15:06] <UbuntuFL-tgBot> No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id!
[15:06] <UbuntuFL-tgBot> UbuntuFL_bot was removed by: ahoneybun
[15:06] <UbuntuFL-tgBot> UbuntuFL_bot was added by: ahoneybun
 @UbuntuFL_bot
 Yea I got that now
 @km
 @KMyers this bot reports to IRC from telegram
[15:07] <ahoneybun> and to telegram from IRC
 :)
[15:08] <ahoneybun> mhall119: ping
 @KMyers think the bot will help?
 https://twitter.com/usbfl/status/764631682074816513
[15:55] <Kilos> greetings everyone
 heyo Kilos
[15:56] <Kilos> hmm...
[15:57] <Kilos> you communicate via the bot?
[15:57] <ahoneybun> only when we are on telegram
[15:57] <Kilos> oh cool
[15:57] <ahoneybun> I just set it up now
[16:00] <Kilos> from what to what?
 \n /me tries things
 <br> /me tries things
 Trying to break the not?
 *bot
 \0A /me tries things
 @AdamOutler is hacking again
 :D
 \x0A /me tries things
 I can't see the other chat.  Is it working?
 I never log into IRC
 Your always are
 I was hoping to see an announcement from bot that he tries things in the other chat.
 Its workinf
 he did a |/me" command?
 "/me"?
[18:28] <ahoneybun>  \n /me tries things
 because the next step is to /kick or /leave, which I wouldn't do.
 You have no power in the channel though
 ok.
 Funny that one did not go though
 maybe he's blacklisted certain commands, which is good.
[18:30] <UbuntuFL-tgBot> * ahoneybun test
[18:30] <UbuntuFL-tgBot> * ahoneybun goes though
 ok. so there's no way to /kline him.
 I just coded up some switches for around my house  https://github.com/adamoutler/SmartThingsPublic/blob/master/devicetypes/adamoutler/lightify-dimming-switch-zigbee.src/lightify-dimming-switch-zigbee.groovy
 It's about darn time I finished these.  This code runs on 8 different switches in my house.
 I should have known you would try to break it
 Of course, I try to break everything.  It's what I do.
 This will hopefully make the group more reacheble
 Have you not seen his job description?
 The not?
 Oh Adam
 Yeah?
 I meant to add to what @Ivoriesablaze said
 Oh, yeah.  I'm a Senior Embedded System Security Engineer II.  I break things for a living.
 Ha, at least you dont have a made-up title
 What do you have?
 Senior Technical Engineer - Basically it means I do it all
 heh.  So who has the made up title?
 Me
 XD
 It sounds official.
 I run the Research and Development department and a few backend systems. I am also a SPOF 6 years running
 Going live in a couple minutes http://bit.ly/Ivories
 how can I edit the startup applications in Unity/GNOME from cli?
 Just add a shortcut to the application in ~/.config/autostart/
 well I had it in that and need to stop it
 Mycroft issue
 Oh, in your case it would be a bit different as you are running it in headless mode (i assume)
 yea trying to vnc into it
 since Unity is still running anyway
 Then your best bet would be to set it as an init.d script
 One moment so I can find a tutorial for you
 the point it that I need to end one
 http://tempvariable.blogspot.com/2009/07/how-to-add-program-to-run-at-startup-in.html
 stop the current way
 first
 Oh, then you need to find the process ID (ps -aux) and kill it
 but it would just start again on reboot
 Then remove the application from the startup
 that's the issue!
 it's headless
 no GUI
 Then it is likely an init.d script
 cd into /etc/init.d/ and try to find it
 Then do a sudo chmod -x NameOfApplication
 don;t see it
 then do a sudo update-rc.d -f NameOfApplication remove
 What is the output of initctl list
 it's in .config/autostart
 My tamagotchi got dysentery
 http://aralai.net/misc/tamagotchi.png
 The simply move the item in .config/autostart to somewhere else
 I removed it
 @RazPi - That is scary
 going to do it a better way
 @KMyers what is the better way?
 Init scripts
 http://tempvariable.blogspot.com/2009/07/how-to-add-program-to-run-at-startup-in.html
 got it
 insserv: warning: script 'mycroft' missing LSB tags and overrides
 You should be fine
 http://paste.ubuntu.com/23056365/
 @KMyers
 http://arstechnica.com/gadgets/2016/08/seagate-unveils-60tb-ssd-the-worlds-largest-hard-drive/
 @ahoneybun, the fuck? I thought distrowatch defaulted to https
 http://arstechnica.co.uk/information-technology/2016/08/chrome-starts-retiring-flash-in-favour-of-html5/
 @Km
 @KMyers we are heading out at 7pm to Pembroke Pines City Center to walk around and catch pokemans. You want to come?
 I think I will have to pass today, Family just came into town
 Ok.  Cool.  Next time then.  We usually go out sometime during the week.
 What time?
 At around 7 we are leaving.
 so 7:30 ish
 You want to come @ahoneybun?  My car is full.
 So... My stream was empty again
 Thinking about it
 @AdamOutler
 Cool.  We're just going to go to the Pembroke Pines city center at around 1930 and catch some Pokemon.
 Never mind, I'll stop bringing it up in here
 Sorry @Ivoriesablaze - been busy today
 *this week
[23:12] <UbuntuFL-tgBot> * ahoneybun wonders where @AdamOutler is talking about
 mm
 @AdamOutler address?