[00:00] <slangasek> well, --install-layout=deb is an argument to distutils/setuptools, which isn't being used here... so I think that's an ignorable warning
[00:00] <stokachu> ok
[00:01] <doko> this warning is ... interesting. but you should ignore it if the results look ok
[00:02] <stokachu> yea as far as i can tell the file layout is what it warns about
[00:03] <stokachu> slangasek: https://github.com/battlemidget/sosreport/blob/debian-packaging/debian/rules
[00:03] <stokachu> lintian sosreport_2.3-3_amd64.deb
[00:03] <stokachu> W: sosreport: extra-license-file usr/share/sos/LICENSE
[00:03] <stokachu> does the rules file look right?
[00:10] <stokachu> that is the last lintian error and its taking me forever to figure out lol
[00:15] <slangasek> stokachu: that looks right to me
[00:16] <stokachu> slangasek: should it be something like $(CURDIR)/debian/$(PACKAGE)/usr/share/sos/LICENSE
[00:17] <slangasek> hmm
[00:17] <slangasek> stokachu: yes, I suppose it should after all
[00:18] <slangasek> stokachu: sorry, I'm used to dh_auto_install acting on debian/tmp, not debian/$pkg, because that's what it does in the multiple-binary case
[00:18] <stokachu> ahhh
[00:18] <stokachu> i was reading back through the log and saw the directory structure so lemme try that
[00:22] <stokachu> slangasek: yay success
[01:18] <celso_> sarnold: are you here?
[01:22] <celso_> well, for those who are here and heard my history of a bug, after i installed the updates a few each time, i found the problem it was random. i thought it ws because of a file corrupted of some bug in some file but it wasn't, it seems.  Probably, after my ubuntu's updates installations, it doesn't update correctly the initramfs, so, after the long work, updating the initramfs will fix it. strangely its only afects me when i am us
[01:24] <celso_> by the way, sorry for my bad english.
[01:24] <celso_> and thanks for the help.
[03:25] <pitti> Good morning
[03:31] <pitti> slangasek: ah, your pkexec PAM env patch landed upstream, good
[03:33] <pitti> so we can put that change into Debian
[03:39] <pitti> [done]
[04:49] <pitti> tkamppeter_: wrt. your cups upload, don't you want to merge with the Debian changes in git? (-4) there are more fixes, like the one you gave to me yesterday about the web UI triggering an AppArmor violation
[04:50] <pitti> tkamppeter_: oh, I guess you don't want the cups-server-common split?
[05:17] <dunkel2> hello
[06:20] <tkamppeter> pitti, yes, it is the cups-server-common split why I stopped syncing cups.
[06:41] <dholbach> good morning
[06:41] <tkamppeter> pitti, your apparmor fix is now ported to Ubuntu and uploaded as cups 1.6.2-1ubuntu5.
[06:49] <dholbach> RAOF, happy birthday!
[06:49] <RAOF> dholbach: Thank you!
[07:12] <shadeslayer> RAOF: happy birthday :)
[07:13] <didrocks> happy birthday RAOF ;)
[07:14] <RAOF> Thanks!
[08:22] <Laney> tkamppeter: can you reupload cups with -v please? so that all the bugs get closed
[08:22] <Laney> that or merge the versions into ubuntu4 since this didn't get accepted yet
[08:45] <tkamppeter> Laney, uploaded all in one shot as -1ubuntu4 now.
[08:46] <Laney> merci!
[09:13] <seb128> hum, I never remember
[09:13] <seb128> does it work to have .install.<arch> files?
[09:13] <seb128> like binary.install.i386 and binary.install.amd64?
[09:14] <cjwatson> yes, see debhelper(7)
[09:14] <OdyX> tkamppeter: aye, nice.
[09:14] <cjwatson> but remember that they entirely override .install - if you need to combine them then you'll need to generate those files
[09:15] <cjwatson> you could also use dh-exec(1) as an alternative
[09:15] <seb128> cjwatson, thanks, I was looking at man dh_install
[09:16] <seb128> cjwatson, that's for streamer-fluendo-plugins-partner, it's basically one .so to install, and a different one for i386 and amd64
[09:16] <seb128> we had 2 sources but that doesn't seem required, I'm merging them
[09:16] <seb128> the .install.<arch> will do ;-)
[09:18] <seb128> in fact that already uses dh-exec
[09:18] <seb128> so I can build on that
[11:06] <pitti> Committed revision 666.
[11:06] <pitti> beware of 3v1l!
[11:06] <jussi> pitti: you are of the devil...? :D :P
[11:06]  * jussi hugs pitti
[11:06]  * pitti hugs you back
[11:07] <pitti> that was a commit to NM to add integration tests with simulated wifi devices
[11:07] <pitti> so, not that far from "evil" indeed :)
[12:02] <celso_> sarnold, i found the problem.
[12:04] <celso_> it seems the update manager wasn't updating the initramfs, so, leaving my boot broken. i updated the initramfs manualy and it fixed the problem.
[12:21] <stgraber> for those interested, we'll have a Google hangout on air in 40min (http://ubuntuonair.com) about image based updates and our plan for Ubuntu Touch. I'll send a summary with links to the video and wiki page to the ubuntu-devel ML after the meeting.
[12:39] <smoser> cjwatson, thanks for following up wrt the text mode.  I did find what i wanted, but it wasn't so straight forward.  the issue is that i was hoping to use 'kvm -curses' which does not do vesa, and the default media has a vesa menu.
[12:41] <smoser> i was able to rebuild with menu.c32 rather than vesamenu.c32 to get what i wanted.  also have to modify kernel cmdline params to have 'nomodeset' and (possibly) 'fb=false'
[13:01] <voldyman> hi, i want to make an indicator using appindicator in vala. something like the current sound indicator. can someone point me to docs? or an example code? the doc i found at ubuntu.com is very sparse
[13:11] <cjwatson> Laney: does https://launchpadlibrarian.net/137180694/buildlog_ubuntu-raring-armhf.gitit_0.10.2-1ubuntu2_FAILEDTOBUILD.txt.gz make any sense to you?
[13:11] <cjwatson> built fine on other arches
[13:18] <cjwatson> stgraber: the other defence you could add is an expiry date on the index
[13:19] <cjwatson> on the signed object, that is
[13:19] <cjwatson> not perfect in the face of wrong clocks on the client though
[13:19] <stgraber> cjwatson: good point, I currently include a generate date, so we could at least have the client refuse anything older than the last one
[13:20] <cjwatson> (as in, there are two problems: an attacker also intercepting ntp.u.c or whatever; and an accidental wrong date causing people to be innocently unable to upgrade)
[13:20] <cjwatson> so it may not be the right answer, just worth considering
[13:32] <Laney> cjwatson: I don't understand on the face of it why that would be arch specific
[13:32] <Laney> does the code have some ifdefs or similar?
[13:35] <Laney> hm, parseImportDecl comes from ghc
[13:36] <cjwatson> Laney: ah, parseImportDecl is #ifdef GHCI
[13:36] <cjwatson> (in ghc itself)
[13:36] <Laney> that'd do it
[13:36] <cjwatson> Laney: so this is really a missing build-dep on ghc-ghci, I guess
[13:36]  * Laney nods
[13:40]  * cjwatson removes the binaries then
[13:43] <Laney> I wonder if the 'else' branch of that #if would work
[13:43] <Laney> I can't see that findModule and mkModuleName are conditional
[13:52] <Laney> my testing appears to show that those two functions are there on armhf still
[13:52] <Laney> so this might be rescuable
[13:53] <cjwatson> that'd be nice.  no interesting rdeps so it's not a disaster if not
[13:55] <Laney> still, would be nice to have gitit the application
[13:57] <cjwatson> yeah, I care more about applications than the libraries along the way :)
[14:14] <tseliot> pitti: do you still have the python test file to reproduce bug #804662 ?
[14:14] <OdyX>  /win 26
[14:41] <Hammerhead2011-S> Hi All
[14:42] <Hammerhead2011-S> I see that this Bug #1102484  was "fix released" Can someone help me out with how to get the fix? an update from apt-get does not seem to do it....
[14:43] <zyga> jodh: ping
[14:44] <jodh> zyga: hi
[14:44] <zyga> jodh: upstart-file-bridge running in the user session fails to write a PID file
[14:44] <zyga> jodh: cat ~/.cache/upstart/upstart-file-bridge.log
[14:44] <jodh> zyga: ignore it - it's harmless (and already fixed upstream).
[14:45] <jodh> zyga: doesn't stop the bridge working fully.
[14:45] <zyga> jodh: cool, thanks
[14:45] <zyga> jodh: this could be used to start an arduino sketch after plugging in arduno :)
[14:45] <zyga> jodh: or asking the user if they want to install the right software
[14:45]  * zyga likes that a lot
[14:46] <jodh> zyga: the bug # is 1163103 btw.
[14:46] <zyga> and it would play nice with uctrl "control center" for hw geeks
[14:48] <zyga> jodh: is :sys: a "namespace" for events from the system upstart?
[14:50] <jodh> zyga: yes, see upstart-events-bridge(8).
[15:25] <med_> slangasek, how do we get walinuxagent out of -proposed and into distro today?
[15:25] <med_> stokachu, ^
[15:28] <xnox> med_: which distro?
[15:29] <med_> precise and quantal
[15:29] <med_> xnox
[15:29] <med_> trying to get them into updates
[15:30] <Laney> Packages usually age there for seven days before moving over
[15:31] <xnox> med_: and we do not release -updates on Fridays, becuase if regression happens there is very little people over the weekend to fix things up.
[15:31] <cjwatson> we can waive the seven-day waiting period for critical reasons (sounds like this may be), but indeed I'd much prefer to release end of Sunday / start of Monday if possible
[15:32] <med_> utlemming, ^ does that do us any good?
[15:32] <med_> cjwatson, pretty time crit.
[15:32] <med_> (many thanks for the eyeballs/feedback guys)
[15:33] <cjwatson> to be fair the only users this would break are basically azure images, and it's been tested there
[15:33] <med_> yep
[15:33] <utlemming> med_, cjwatson: if we can have it by SOD Monday, then it should be okay
[15:33] <med_> and that's where/why it is needed.
[15:33] <cjwatson> med_,utlemming: what's your availability over the weekend in the event of a problem?
[15:34] <med_> so Sunday would work
[15:34] <med_> cjwatson, I'm flying to OpenStack but generally avaiable after 1pm Pacific
[15:34] <cjwatson> if you're available, I'm happy enough to waive the waiting period and release now, to unblock
[15:34] <med_> +1
[15:34] <cjwatson> just don't want the possibility of a regression with nobody around
[15:35] <utlemming> +1, we'll make this a crit sit for the cloud images, and make absolutely sure things go smoothly
[15:35] <med_> I'm avaiable today and tomorrow and Sunday
[15:35] <cjwatson> ok, releasing
[15:35] <utlemming> same here
[15:35] <utlemming> cjwatson: thank you kindly
[15:36] <cjwatson> xnox is right in general though, this isn't a precedent :)
[15:37] <med_> cjwatson, xnox, Laney : many thanks. Sorry for the exception (and we're both working on getting further upstream in the process to avoid this.)
[15:37] <Laney> np, hope it goes smoothly
[15:38] <utlemming> cjwatson: agreed....we were content to let this go through the regular process, but the process ran out of time
[15:38] <cjwatson> right, if we're going to have to waive anyway, I'd rather do so earlier than later to allow more time to iterate if necessary
[15:38] <cjwatson> just to explain rationale for now rather than Sunday evening
[15:39] <xnox> utlemming: it's just something to factor in - that a fix accepted into -proposed on Friday-Sunday can only be release on Monday the week after.
[15:43] <cjwatson> Laney: gitit> no, afraid not.  setContext and compileExpr are only defined #if GHCI.
[15:45] <cjwatson> Laney: Though I suppose disabling plugins might work
[15:45] <Laney> ah, I only checked findModule and mkWhateverItIs
[15:47] <stokachu> cjwatson: ill be around this weekend as well
[15:47] <stokachu> if any regressions pop up from azure
[15:48] <Laney> seems there is a flag for plugins, so try passing -f-plugins
[15:48] <cjwatson> Yeah, was just trying that
[15:48] <cjwatson> You think that'd be OK in Debian as a better-than-nothing option?
[15:49] <Laney> yeah I think so, do you?
[15:49] <Laney> maybe document it somewhere or other
[15:49] <cjwatson> Yeah
[15:49] <cjwatson> README.Debian I suppose
[17:09] <GridCube> jbicha, ping
[17:11] <seb128> barry, doko: do you have any idea about the issue in https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/1162124 ?
[17:11] <seb128> it seems quite frequent according to error.ubuntu.com
[17:11] <seb128> it fails to import "io"
[17:20] <jbicha> GridCube: what's up?
[17:21] <GridCube> :) hi jbicha i noticed that you edited last the wiki entry for the irc redirection, can i pm you with some questions?
[17:26] <jbicha> GridCube: #ubuntu is probably a better place for general questions about IRC on Ubuntu
[17:26] <GridCube> no, its not about that its about adding a new subdir to the /IRC/ wiki
[17:29] <barry> seb128: i think that's a dupe of a bug that doko has been working on
[17:29] <seb128> barry, ok, "known issue" then?
[17:29] <seb128> barry, do you know the master bug number by any chance?
[17:29] <barry> seb128: yes, i think so.  let me see if i can find it.
[17:29] <seb128> barry, thanks
[17:34] <barry> seb128: bug 1165172
[17:34] <seb128> barry, thanks!
[17:35] <barry> np :)
[17:35] <seb128> nice to see it's already fixed as well ;-)
[17:35] <barry> time machine ftw!
[17:37] <Hammerhead2011-S> I see that this Bug #1102484  was "fix released" Can someone help me out with how to get the fix? an update from apt-get does not seem to do it....
[17:37] <Hammerhead2011-S> any help would be greatly appreciated
[17:39] <Hammerhead2011-S> I use this program a lot.
[17:39] <Hammerhead2011-S> Do I need to be in a different group asking this question?
[17:40] <GridCube> jbicha, sorry to bother you :( its that #ubuntu-wiki its empty
[17:53] <jbicha> GridCube: oh, as long as you're trying to make things better you can edit the wiki how you like, you can log in with your Launchpad account
[17:53] <GridCube> jbicha, :) thanks, i did a proper question on #ubuntu-doc just now
[17:54] <GridCube> sorry to have bothered you
[19:32] <GunnarHj> slangasek: ping?
[19:58] <slangasek> GunnarHj: hi
[20:20] <GunnarHj> slangasek: Didn't Jamie say he's fine with the patch at bug 1155327? I mean, you don't really need anyone else to review it to upload it, right? ;-)
[20:21] <slangasek> jdstrand: ^^ bug #1155327 - I'm not sure if you've acked this patch, or just withdrawn your objection to the principle
[20:21] <slangasek> I'm still not sure how good of a workaround it is
[20:22] <slangasek> because I don't know *why* libGL is used by skype/qtwebkit
[20:22] <jdstrand> slangasek: I've withdrawn my objection to the idea of supplying a skype workaround
[20:22] <slangasek> if it actually needs it, using mesa in place of the binary driver will give wrong results
[20:22] <GunnarHj> Me neither. I have no clue. But it works. :)
[20:23] <jdstrand> slangasek: I don't really have any other insight. I think if we were going to do this, the script should be updated to use 'exec ...' rather than backgrounding the process and to reference the upstream bug in the script and the debian/changelog
[20:23] <slangasek> the dependency tree is skype -> libQtWebkit -> libQtOpenGL -> libGL
[20:23] <slangasek> jdstrand: agreed
[20:23] <slangasek> GunnarHj: could you make the changes jdstrand suggests?
[20:24] <jdstrand> slangasek: the only other concern I had is how much leeway we have with the package since it is in partner (I forgot about that)
[20:24] <slangasek> well, we do diverge from upstream's own package
[20:24] <jdstrand> k, then it seems reasonable. you'd know better than I
[20:24] <slangasek> so I can do whatever's needed here, though I'll want to give folks a heads-up that I'm doing it
[20:25]  * jdstrand nods
[20:25] <GunnarHj> slangasek: Sure, I can adjust the patch like that.
[20:26] <jdstrand> I'll comment in the bug
[20:36] <slangasek> Mirv: so regarding skype/qtwebkit/nvidia... I'm not sure lack of crash reports points to this being skype-specific, given how useless the backtrace is
[20:40] <lifeless> it might be measurement bias
[21:33] <GunnarHj> slangasek, jdstrand: Ready to go. :)
[23:22] <Acibi> Hi, I got a question about 13.04..
[23:23] <Acibi> Is gksu will be install by default in the final release?
[23:24] <slangasek> Acibi: there are no changes planned between now and release for the set of default packages
[23:25] <slangasek> I believe, from a quick archive check, that gksu is included as part of the liveCD environment but is *not* included by default when installing
[23:26] <Acibi> Yeah, I've seen this..
[23:26] <Acibi> Thanks.
[23:26] <slangasek> gksu should certainly be regarded as deprecated in favor of policykit
[23:27] <sarnold> is 'ubuntu-core' the line to look at in the 'seeded-in-ubuntu' output?
[23:27] <slangasek> sarnold: how do you mean?
[23:28] <sarnold> slangasek: seeded-in-ubuntu -b pksu shows 'ubuntu: ' and 'xubuntu: ' and similar lines.. but seeded-in-ubuntu -b dash or -b bash both show 'ubuntu-core: ' lines...
[23:28] <sarnold> slangasek: I'm curious if these lines are an indicator of what will be installed by default or not
[23:29] <sarnold> or, do you just have to know the installer and what it does? :)
[23:29] <slangasek> sarnold: nope; 'ubuntu-core' refers there to the ubuntu-core /image/
[23:30] <slangasek> sarnold: in this case, I looked at 'apt-cache show gksu | grep Task' - the purpose of seeded-in-ubuntu is to tell you whether the package impacts an image, it doesn't give information about live env vs. install
[23:30] <sarnold> slangasek: ah! thanks :)
[23:30] <slangasek> in this case, I'm uncertain why gksu shows up on daily-preinstalled
[23:31] <slangasek> that smells funny to me
[23:32] <Acibi> So still unclear if it will be there? :P
[23:32] <slangasek> Acibi: not unclear unless you're using a "preinstall" image, which only applies to nexus7
[23:33] <Acibi> mmhh kk.
[23:34] <slangasek> right, it's only present on the preinstalled image because ubiquity uses it; so after first-boot when ubiquity runs, gksu is probably removed from that case too
[23:34] <slangasek> Acibi: why the interest in gksu?  It is, as I said, deprecated in favor of policykit
[23:36] <Acibi> Use in our application, used to write global preferences as root in a file, kind of parental control.
[23:36] <Acibi> We used it to launch the script that write the data, so it prompt the user for the password.
[23:37] <slangasek> right; well, if your app is provided as a package, that package should depend on gksu whether or not it's available by default
[23:37] <Acibi> The problem is there, not provided as a package ;)
[23:39] <Acibi> I'll try to figure something, maybe using pkexec to install gksu for now, but in long term I'll have to use only pkexec I presume ;)
[23:40] <slangasek> why use pkexec to install gksu instead of just using pkexec to run your script?
[23:42] <Acibi> gksu is also used to launch the graphical installer of the application, as I understand how policykit work, we would have to add that installer to the list of binarie who can run as root...
[23:43] <slangasek> pkexec will let an admin user run any arbitrary command, it just prompts for a password in the default policy
[23:43] <slangasek> ... which seems to be equivalent to what gksu gives you anyway
[23:45] <GunnarHj> slangasek: How would you do "gksu gedit /usr/bin/skype"? (I usually use sudo instead, but I have been told I shouldn't.)
[23:46] <slangasek> GunnarHj: 'pkexec gedit /usr/bin/skype'?
[23:46] <jbicha> slangasek: WARNING **: Could not open X display
[23:46] <Acibi> ;)
[23:46] <slangasek> hmm, really?
[23:47] <Acibi> gEdit must ben in the config file
[23:47] <GunnarHj> $ pkexec gedit /usr/bin/skype
[23:47] <GunnarHj> No protocol specified
[23:47] <mbiebl> running X apps needs explicit configuration
[23:47] <GunnarHj> ** (gedit:5937): WARNING **: Could not open X display
[23:47] <GunnarHj> Cannot open display:
[23:47] <jbicha> slangasek: yeah that's a security feature or something
[23:47] <slangasek> ah
[23:47] <GunnarHj> Run '/usr/bin/gedit --help' to see a full list of available command line options.
[23:48] <mbiebl> see /usr/share/polkit-1/actions/org.debian.pkexec.gnome-system-log.policy as an example
[23:48] <Acibi> So what? I should use pkexec to launch a non-X app who will add configuration??
[23:48] <mbiebl> sorry, I don't understand your question
[23:51] <Acibi> I currently have an installer, that client run to install the app. We currently launch the installer with gksu (and beesu on Fedora). What should I do now? Use pkexec to create the config file and then launch the installer with pkexec??
[23:52] <jbicha> Acibi: the easiest way for now is just to make your package depend on gksu, see debian/control
[23:53] <sarnold> Acibi: speaking as J Random User, _easiest_ would be for you guys to prepare a .deb package and provide an apt repository, so it could be installed via 'sudo apt-get install neat-acibi-thing' or the software center or whatever... :)
[23:54] <jbicha> or you could have your installer package install the .policy file and then use pkexec like gnome-system-log does on Debian
[23:54] <jbicha> or synaptic or gparted do on Ubuntu
[23:54] <Acibi> jbicha : Not distributing the apps in the form of a package :P
[23:55] <jbicha> uh, you should
[23:55] <Acibi> I'll take a look! Thanks!
[23:55] <Acibi> Yeah, I know... Not my decision.
[23:56] <Acibi> Kind of a miracle that we have a linux version of the product :P
[23:56] <jbicha> tell them that some guy on the Internet told them to make a .deb ;)
[23:57] <Acibi> Ahahaha ;)
[23:58] <Acibi> They don't really like big changes :P Make me scream in my head all the time :P