[00:00] <hallyn> i'll remove the snapshots and re-test
[00:01] <cjwatson> plars: Is it possible to get as far as a working-ish session?
[00:02] <plars> cjwatson: I'm trying the various options at the moment, running in low graphics mode doesn't seem to work
[00:03] <doko> stgraber, https://bugs.launchpad.net/gcc/+bug/1123588
[00:03] <plars> cjwatson: neither does reconfiguring
[00:03] <plars> cjwatson: so no it seems
[00:04] <cjwatson> plars: OK, so this sounds to me as though we shouldn't bother respinning everything for this because it won't be a worthwhile improvement
[00:05] <plars> cjwatson: it is at one point trying to LoadModule: "vboxvideo" in the xorg log and failing to find it it seems
[00:05] <cjwatson> Ah, for details you'll need to talk to X people :)
[00:05] <cjwatson> Of which I am not one
[00:05] <plars> cjwatson: ok, was the libpciaccess fix the only thing different in this image?
[00:06] <plars> cjwatson: I can update the bug
[00:06] <cjwatson> plars: No, it was a general build against -proposed
[00:06] <hallyn> slangasek: bug 1123594
[00:06] <cjwatson> It should have been the only relevant thing, though
[00:13] <cjwatson> ogasawara: Do you think you could add specific directions to either https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop#LTS_Hardware_Enablement_Stack or https://wiki.ubuntu.com/Kernel/LTSEnablementStack (or possibly both) about how to opt into the kernel and X enablement stacks on upgrade?
[00:14] <cjwatson> I just noticed it says "the appropriate meta package" and the like but doesn't actually give commands or specific package names
[00:24] <penguin42> that's interesting; first time I'd read about the HES; I guess that means that bugs found relatively late in Quantal kernel/X become more important because their about to find their way into LTS
[00:26] <cjwatson> penguin42: for 12.04.3 it'll be raring-based (3.8)
[00:29] <penguin42> cjwatson: Yes; I'm just thinking that there has been a tendency to worry more about fixing something in an LTS because it's going to have to stay for the long run, but a bug in a non-LTS might not be SRUd for example
[00:30] <penguin42> it might also make bug triage interesting to try and figure out which series people are actually running when they say it works/fails for them on precise
[01:31] <hallyn> jdstrand: qemu with spice build-dep has been dput'ed
[02:05] <jdstrand> hallyn: ack
[04:18] <Dedunu> hi i need a help
[04:18] <Dedunu> i bzr branched a source of gnome-power-manager
[04:19] <Dedunu> but when im going to build it it gives error althoug i do it on original source (with out any change)
[04:19] <Dedunu> can anybody help me?
[04:34] <chilicui1> Dedunu: which error?, when compiling software you must ensure you have all the dependencies satisfied
[04:41] <Dedunu> debian/rules:6: /usr/share/gnome-pkg-tools/1/rules/uploaders.mk: No such file or directory
[04:41] <Dedunu> debian/rules:7: /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk: No such file or directory
[04:41] <Dedunu> make: *** No rule to make target `/usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk'.  Stop.
[04:41] <Dedunu> dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
[04:41] <Dedunu> debuild: fatal error at line 1350:
[04:41] <Dedunu> dpkg-buildpackage -rfakeroot -d -us -uc -S failed
[04:41] <Dedunu> bzr: ERROR: The build failed.
[04:41] <Dedunu> chilicui1: error is like this
[04:41] <Dedunu> i havent created a chroot enviroment is that the problem?
[04:46] <chilicui1> Dedunu: did you run $ apt-get build-dep before ? , how did you found that problem?, did you use $ dpkg-buildpackage -rfakeroot -us -uc #to compile it?
[04:47] <chilicui1> Dedunu: no, it should work in your system if you meet all the dependencies, the pkg you're trying to compile is the same version of the you current ubuntu setup?, I mean, it may be a little be harder to compile a pkg which is suppose to be installed in ubuntu raring from ubuntu precise
[04:48] <Dedunu> ah is that so
[04:48] <Dedunu> i used bzr builddeb
[04:49] <Dedunu> i installedpackaging-dev
[04:49] <Dedunu> packaging-dev
[04:51] <chilicui1> Dedunu: mm, it's ok, bzr builddeb runs dpkg-buildpackage, so now just be sure you installed the dependencies.., $ apt-get build-dep #also as you've already told.., you branched.., therefore the code you're trying to run should be run against a raring machine, please be sure to compile it in that environment, otherwise the deps may not be the versions you need
[04:51] <ogasawara> cjwatson: I updated both https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop and https://wiki.ubuntu.com/Kernel/LTSEnablementStack with instructions for how to opt into (ie manually install) the kernel and X  enablement meta pkgs
[04:52] <Dedunu> chilicui1: ok thank you
[04:52] <Dedunu> ill try on raring environment
[04:52] <Dedunu> thanks a lot
[04:52] <chilicui1> Dedunu: have fun, good luck
[04:56] <pitti> Good morning
[04:58] <Dedunu> good morning
[07:56] <dholbach> good morning
[08:04] <Dedunu> dholbach: hi
[08:05] <Dedunu> all the day im struggling with a
[08:05] <Dedunu> papercut
[08:05] <Dedunu> i found the bug in that fixed it on code
[08:05] <Dedunu> but i can't build it yet
[08:39] <cjwatson> ogasawara: Great, thanks
[08:48] <Dedunu> chilicui1: stil problem is not solved i can builddeb
[08:48] <Dedunu> :(
[09:04] <hrw> infinity: any chances to get chromebook stuff from NEW?
[09:05] <ogra_> ++
[09:31] <Dedunu> please can anybody help me?
[09:37] <seb128> Dedunu, hi, if you don't state what help you are looking for, not likely
[09:40] <Dedunu> I got source with bzr
[09:40] <Dedunu> of gnome-power-manager
[09:41] <Dedunu> and found the place to edit also i edited it
[09:41] <Dedunu> when im going to build using bzr bd -- -S
[09:41] <Dedunu> it gives and error
[09:41] <Dedunu> dpkg-buildpackage: source package gnome-power-manager
[09:41] <Dedunu> dpkg-buildpackage: source version 3.6.0-1ubuntu1
[09:41] <Dedunu> dpkg-buildpackage: source changed by Dedunu Dhananjaya <admin@dedunu.info>
[09:41] <Dedunu>  dpkg-source --before-build gnome-power-manager-3.6.0
[09:41] <Dedunu>  fakeroot debian/rules clean
[09:41] <Dedunu> debian/rules:6: /usr/share/gnome-pkg-tools/1/rules/uploaders.mk: No such file or directory
[09:41] <Dedunu> debian/rules:7: /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk: No such file or directory
[09:41] <Dedunu> make: *** No rule to make target `/usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk'.  Stop.
[09:41] <Dedunu> dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
[09:41] <Dedunu> debuild: fatal error at line 1350:
[09:41] <Dedunu> dpkg-buildpackage -rfakeroot -d -us -uc -S failed
[09:41] <Dedunu> bzr: ERROR: The build failed.
[09:42] <Dedunu> those are end parts
[09:43] <Dedunu> im using ubuntu 12.04 LTS and i also ran pbuilder-dist raring create before everything
[09:43] <Dedunu> this is my first fix
[09:45] <Dedunu> seb128: can you tell me what should i do?
[09:45] <RAOF> Dedunu: Have you run ‘apt-get build-dep gnome-power-manager’?
[09:45] <Dedunu> nop
[09:46] <Dedunu> i want to build my code
[09:46] <Dedunu> i fixed a problem in it
[09:46] <seb128> what RAOF said
[09:46] <seb128> run that, it will install the packages needed to build gnome-power-manager
[09:46] <seb128> janimo, hey
[09:46] <Dedunu> than you ill try
[09:48] <seb128> janimo, https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1123930
[09:49] <seb128> janimo, can you have a look? it's an important leak in your orientation patch ... also please go through review from now on rather than direct upload, reviews help to catch such errors before they hit users and have to go back through reports
[10:02] <Dedunu> seb128: RAOF: now error is change
[10:02] <Dedunu> d
[10:03] <Dedunu> sorry i would be much obliged to you if you could help me
[10:03] <Dedunu> dpkg-source: warning: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
[10:03] <Dedunu> dpkg-source: warning: Version number suggests Ubuntu changes, but there is no XSBC-Original-Maintainer field
[10:03] <Dedunu> dpkg-source: info: using source format `3.0 (quilt)'
[10:03] <Dedunu> dpkg-source: info: building gnome-power-manager using existing ./gnome-power-manager_3.6.0.orig.tar.xz
[10:03] <Dedunu> dpkg-source: info: local changes detected, the modified files are:
[10:03] <Dedunu>  gnome-power-manager-3.6.0/src/gpm-statistics.c
[10:03] <Dedunu> dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/gnome-power-manager_3.6.0-1ubuntu1.diff.dDUvhp
[10:03] <Dedunu> dpkg-source: info: you can integrate the local changes with dpkg-source --commit
[10:03] <Dedunu> dpkg-buildpackage: error: dpkg-source -b gnome-power-manager-3.6.0 gave error exit status 2
[10:03] <Dedunu> debuild: fatal error at line 1350:
[10:03] <Dedunu> dpkg-buildpackage -rfakeroot -d -us -uc -S failed
[10:03] <Dedunu> bzr: ERROR: The build failed.
[10:04] <pitti> Dedunu: for applying changes to the upstream source, please see http://developer.ubuntu.com/packaging/html/patches-to-packages.html; you can't do that in-plce
[10:04] <pitti> "place"
[10:04] <RAOF> Dedunu: You probably want to use a pastebin for such a lot of text.
[10:04] <seb128> Dedunu, please stop doing big pastes on the channel, use http://paste.ubuntu.com for that
[10:05] <Dedunu> sorry im new to irc
[10:05] <Dedunu> thank you
[10:37] <Dedunu> seb128: RAOF: i patched it using quilt after that what should i do
[10:37] <Dedunu> im sorry
[10:37] <Dedunu> pitti: i did it after that what should i do
[10:37] <seb128> Dedunu, you should be able to run the command then
[10:37] <Dedunu> which command bzr bd -- -S
[10:38] <Dedunu> it is again failing
[10:38] <seb128> bzr revert your inline change if you put it in a quilt patch
[10:38] <seb128> bzr revert src/gpm-statistics.c
[10:38] <seb128> Dedunu, what issue are you working on btw,
[10:38] <seb128> ?
[10:39] <Dedunu> https://bugs.launchpad.net/hundredpapercuts/+bug/923292
[10:39] <seb128> good ;-)
[10:39] <Dedunu> oh im sorry
[10:40] <Dedunu> omg
[10:41] <Dedunu> seb128: i reverted it
[10:41] <Dedunu> seb128: ubottu: is that uploaded to lp?
[10:42] <seb128> Dedunu, ubottu is a bot, it's not going to reply to questions ;-)
[10:42] <Dedunu> im realy new
[10:42] <seb128> Dedunu, you should be able to bzr bd if you reverted it
[10:42] <Dedunu> im very sorry if i annoy you
[10:43] <seb128> Dedunu, no, you don't, everybody has to start and has questions when starting, that's ok ;-)
[10:43] <seb128> Dedunu, I would just ignore IRC if I was annoyed ;-)
[10:43] <Dedunu> thanks
[10:44] <Dedunu> it hasn't revert things
[10:44] <seb128> how so?
[10:44] <Dedunu> my lines are there stil
[10:45] <seb128> can you copy the log to http://paste.ubuntu.com and give the url here?
[10:45] <Dedunu> lines i added are there
[10:45] <seb128> with a bzr diff and bzr status output as well
[10:45] <Dedunu> http://paste.ubuntu.com/1643366/
[10:45] <Dedunu> bzr status is this
[10:46] <Dedunu> bzr diff gives nothing
[10:46] <Dedunu> shall i start from the begining?
[10:46] <Dedunu> first i init a repo
[10:46] <seb128> yeah, not sure what you did
[10:46] <seb128> wait
[10:46] <Dedunu> shall i explain you what i did?
[10:46] <seb128> yes please
[10:46] <seb128> basically you want to
[10:47] <seb128> bzr branch ubuntu:gnome-power-manager
[10:47] <seb128> export QUILT_PATCHES=debian/patches
[10:47] <Dedunu> yeah
[10:47] <seb128> bzr bd-do
[10:48] <seb128> quilt new 923292-fix.patch
[10:48] <seb128> quilt add src/gpm-statistics.c
[10:48] <seb128> edit src/gpm-statistics.c
[10:48] <seb128> quilt refresh
[10:48] <seb128> exit 0
[10:48] <seb128> bzr add debian/patches/923292-fix.patch
[10:48] <seb128> bzr bd
[10:48] <seb128> dch -i "updated changelog for fix"
[10:48] <seb128> as well maybe
[10:49] <Dedunu> how can i test it i want to see whether i works
[10:49] <Dedunu> bzr bd will it give a output
[10:49] <Dedunu> ?
[10:49] <Dedunu> i mean a .deb
[10:49] <seb128> Dedunu, sorry, that's for slightly different bzr format ... ignore the bzr bd-do and exit0 lines
[10:50] <seb128> Dedunu, basically just follow http://developer.ubuntu.com/packaging/html/patches-to-packages.html and that should work
[10:50] <seb128> you should get a patch in debian/patches with your diff
[10:50] <seb128> Dedunu, yes, bzr bd will give you a .deb
[10:50] <Dedunu> hmm
[10:51] <Dedunu> then i cann install deb and see whether it works?
[10:51] <Dedunu> other wise build will fail
[10:51] <Dedunu> ?
[10:51] <seb128> you can install the deb and test it yes
[10:52] <seb128> Dedunu, build will fail? just try to start from scratch following http://developer.ubuntu.com/packaging/html/patches-to-packages.html and tell me if you hit an issue
[10:55] <Dedunu> ok
[10:55] <Dedunu> thank you
[10:55] <Dedunu> very much
[10:56] <seb128> you're welcome
[11:00] <Laney> bah
[11:00] <seb128> Laney, bah?
[11:01] <Laney> seems the qemu update broke launching VMs
[11:01]  * xnox notes to himself not to upgrade
[11:02] <Daviey> Laney: who does THAT?
[11:02] <Laney> xnox: what does getfacl /dev/kvm show for you?
[11:02] <Daviey> Laney: we can't cater for every edge case.
[11:02] <Laney> Daviey: No worries, I heard arch is better anyway.
[11:03] <xnox> Laney: http://paste.ubuntu.com/1643467/
[11:03] <Laney> merci, same as me
[11:03] <xnox> (where tdlk is my user account, naturally)
[11:03] <xnox> Laney: although I may already have the new-new qemu stack
[11:03] <Daviey> fn'ar, Laney - as xnox is pointing to.. ownership is a problem we have been seeing for a little while
[11:03] <Daviey> something seems racey.
[11:03] <seb128> Laney, oh, that got updated, sorry I didn't see it in the middle of all those haskell uploads :p
[11:03] <xnox> Laney: do you use command line? then kvm needs -kvm option.
[11:04] <Laney> xnox: virt-manager or virsh
[11:04] <Laney> lemme file le bug
[11:04] <xnox> Laney: ack. that should "just work always"(tm)
[11:04] <Daviey> xnox: erm, it shouldn't.. it should use kvm by default, and gracefully fall back to non-accelerated
[11:06] <Laney> bug #1123998
[11:10] <Dedunu> seb128: i followed until bzr commit
[11:10] <Dedunu> after that i bzr bd
[11:10] <Dedunu> it got failed
[11:11] <Dedunu> before changing i tried to build it also got failed
[11:12] <seb128> Dedunu, can you pastebin the log with the fail?
[11:13] <Dedunu> seb128: http://paste.ubuntu.com/1643504/ yeah sure this is before change build fail
[11:13] <Dedunu> it is about failed debsign
[11:13] <Dedunu> what is it?
[11:13] <seb128> Dedunu, that didn't fail
[11:13] <seb128> Dedunu, you should have a deb in build-area/
[11:13] <Dedunu> ok
[11:13] <Dedunu>  ill
[11:13] <Dedunu> check
[11:14] <seb128> Dedunu, the message is confusing, it failed to sign the files, which is needed if you want to upload to Ubuntu (because we need to check who has upload rights, etc)
[11:14] <Dedunu> ok
[11:14] <seb128> Dedunu, but signing is not needed for local builds
[11:14] <Dedunu> thanks it is there
[11:14] <Dedunu> now i changed as on tutorial
[11:14] <Dedunu> and bzr commit also i ran
[11:16] <Dedunu> now how should i test my changes?
[11:16] <Dedunu> i got my old deb
[11:16] <Dedunu> where the patch now?
[11:17] <Dedunu> seb128: how to apply my changes on my system now?
[11:18] <seb128> Dedunu, install the deb (sudo dpkg -i build-area/gnome-power-manager*.deb)
[11:19] <Dedunu> is that include my changes?
[11:20] <seb128> if you did a build with your patch commited etc it should
[11:20] <seb128> Dedunu, what's the deb version?
[11:20] <Dedunu> 3.6.0-1
[11:20] <seb128> the name of the deb
[11:20] <seb128> what is the current version in debian/changelog?
[11:21] <Dedunu> how to check it
[11:21] <seb128> Dedunu, editor debian/changelog
[11:22] <seb128> in the checkout of the source
[11:22] <seb128> the first line
[11:22] <Dedunu> there's nothing inside it
[11:22] <Dedunu> im sorry
[11:22] <Dedunu> i developed c/c++ things
[11:22] <Dedunu> never worked with those bzr
[11:23] <seb128> no worry, there is a learning curve ;-)
[11:23] <seb128> are you sure you are in the checkout dir?
[11:23] <seb128> there is a debian/changelog and it has content for sure in there
[11:23] <rbasak> Is there a standard way for an upstart job's pre-script to log a message to the terminal when it fails? Writing to stdout or stderr redirects to /var/log/upstart/<job>.log, which is fine, but isn't so helpful to a sysadmin starting a job by hand. Eg. bug 1121874.
[11:24] <Dedunu> seb128: 3.6.0-1ubuntu1
[11:24] <Dedunu> i was in buildare
[11:24] <Dedunu> a
[11:24] <seb128> Dedunu, ok, so the deb you build should have this number
[11:24] <seb128> Dedunu, try running bzr bd again ?
[11:24] <seb128> 3.6.0-1 was the version you first built
[11:25] <seb128> or you maybe have the 2 debs in build-area if built both?
[11:25] <ogra_> rbasak, there is a "console" option that can be set to print to plymouth
[11:25] <Dedunu> seb128: http://paste.ubuntu.com/1643532/
[11:25] <Dedunu> this is build
[11:25] <Dedunu> i think its failed?
[11:25] <ogra_> rbasak, http://upstart.ubuntu.com/cookbook/#console
[11:25] <rbasak> ogra_: looking, thanks!
[11:26] <seb128> Dedunu, yeah, can you pastebin the output of both "bzr diff" and "bzr status"?
[11:26] <ogra_> i think "console log" or "console output"
[11:27] <Dedunu> seb128: bzr status http://paste.ubuntu.com/1643539/
[11:27] <Dedunu> bzr diff nothing
[11:27] <seb128> Dedunu, bzr add debian/patches/series and try bzr bd again
[11:28] <xnox> bzr add debian/patches .pc
[11:28] <xnox> (also quilt push, but one needs to setup the series file pointer...)
[11:28] <seb128> xnox, he followed http://developer.ubuntu.com/packaging/html/patches-to-packages.html
[11:28] <seb128> which recommends
[11:28] <seb128> bzr add debian/patches/name
[11:29] <seb128> bzr add .pc/*
[11:29] <seb128> that doesn't work for a package that had no patch before and the series not in the vcs...
[11:29] <Dedunu> seb128: http://paste.ubuntu.com/1643540/
[11:29] <xnox> sounds about right, if there was a quilt push and/or commit (bzr bd does quilt push)
[11:29] <Dedunu> i took little bit of time
[11:29] <seb128> Dedunu, ok, great, it's failing in your patch on a code error
[11:29] <xnox> heh, true about first patch ever ;-)
[11:30] <Dedunu> ok than
[11:30] <Dedunu> thanks ill check it
[11:30] <seb128> Dedunu, sorry it was tedious, you should be set now
[11:30] <seb128> bzr commit the addition of the series file
[11:31] <seb128> Dedunu, you might just want to iterate builds by doing ./configure --prefix=/usr && make in your checkout and do "make" until you got the patch right
[11:31] <seb128> rather than going through a bzr bd every time
[11:31] <Dedunu> seb128: ok thanks
[11:31] <seb128> then do it properly once you are happy with the diff and get it to build
[11:33] <rbasak> ogra_: that's making it go to /dev/console rather than the tty "sudo start mysql" is connected to
[11:33] <rbasak> Is the answer just that jobs aren't supposed to talk to root's terminal for manual jobs?
[11:34] <xnox> rbasak: hm? in recent upstart all jobs stdout/stderr is redirected to /var/log/upstart/job.log
[11:34] <ogra_> might be, ask jodh
[11:34] <xnox> rbasak: and stdin is /dev/null
[11:35] <rbasak> xnox: yes, but that doesn't seem optimal
[11:35] <rbasak> (in this case)
[11:35] <xnox> rbasak: it is for most things
[11:35] <rbasak> xnox, jodh: in a pre-script, if it cannot continue, then it makes sense to tell root directly on his terminal if he called "start <job>", right?
[11:35] <xnox> rbasak: lets start from the beginning. What's your usecase / problem? and maybe upstart can help solving it in a different way =)
[11:36] <rbasak> xnox, jodh: bug 1121874
[11:36] <ogra_> you might be able to add a TTY=$(tty) call and redirect explicitly to it ... not sure, depends if you have an environment thats handed to upstart in that case
[11:36] <rbasak> I've amended it to echo to stderr, and that ends up in /var/log/upstart/mysql.log just fine. But I think it makes sense to do better and write to root's  terminal too
[11:36] <xnox> rbasak: usually pre-start should issue stop command, and then the output from strart command will be: foo is stopped, rather than started.
[11:37] <rbasak> Yes, but the reason for the failure isn't obvious. And /var/log/upstart/mysql.log isn't timestamped (though I can run date of course).
[11:38] <xnox> rbasak: the problem is that it uses "exit" instead of "stop" which would correctly print the message that the job is not starting.
[11:38] <xnox> it will not, however print why it didn't start. But at least there will be some feedback.
[11:39] <rbasak> With exit 1: $ sudo start mysql
[11:39] <rbasak> start: Job failed to start
[11:39] <rbasak> With stop: $ sudo start mysql
[11:39] <rbasak> mysql stop/pre-start, process 18925
[11:39] <rbasak> I think the result of "exit 1" is clearer!
[11:40] <xnox> =)
[11:42] <xnox> rbasak: fair enough and it's more consistent with missing my.cfg & failing to load apparmor profile
[11:42] <xnox> which also do not print messages.
[11:43] <ogra_> effectively this test should live inside mysqul imho and just log to syslog
[11:43] <rbasak> ogra_: I'd rather not patch mysql for this if it can be done in a pre-start!
[11:43] <xnox> ogra_: no, because stuff that starts on starting mysql would have fired by then.
[11:44] <rbasak> And I can still log to syslog from the pre-start with logger if I want to.
[11:44] <ogra_> xnox, hmm ? if the upstart job failed nothing depending on it should start
[11:44] <xnox> rbasak: in the pre-start script you can do: echo "`date` Pre-start Sanity checks"
[11:44] <rbasak> I think I understand the options now, thanks. So now the question becomes: what is the standard, or what should the standard be?
[11:45] <xnox> rbasak: and then you get timestamps and reasoning in the /var/log/upstart/mysql.log
[11:45] <rbasak> xnox: yeah I guess that's the best option for now. Thanks!
[11:46] <xnox> ogra_: started - mysql started to run and didn't fail, starting - mysql is about to be launched
[11:46] <xnox> rbasak: possibly more messages for the other two fails (missing my.cnf & failing to load apparmor-profile)
[11:47] <rbasak> xnox: ack
[11:47] <rbasak> I'll fix it up
[11:47] <xnox> jodh: you might want to look at the mysql upstart job, it does some funny stuff in pre-start and post-start =)
[11:49] <xnox> rbasak: upstart cannot predict what is being tested in pre-start or script so the job itself should somehow hint to the user as to what it is doing. And since we log everything, stdout & stderr is your friend.
[11:49] <mjt> why ubuntu uses apparmor instead of selinux?
[11:50] <rbasak> xnox: the post-start is pretty close to http://upstart.ubuntu.com/cookbook/#post-start, no?
[11:50] <mjt> maybe it's possible to (re)use selinux policies from redhat and thus share efforts, instead of developing new set of rules...
[11:50] <xnox> if one increases upstart logging $ initctl log-priority debug then you get detailed events emitted, but they go to like dmesg and not individual job logs.
[11:51] <xnox> mjt: selinux is harder for admins to get right, apparmor offers more flexibility/sanity.
[11:51] <xnox> mjt: although people on #ubuntu-hardened (security team) can answer that question better.
[11:51] <rbasak> mjt: apparmor works really well. Witness all the sysadmins who end up disabling selinux because they don't understand it and it's blocking them
[11:52] <xnox> jdstrand: ^ mjt
[11:54] <rbasak> mjt: why doesn't redhat use apparmor instead of selinux? Then we could share efforts, instead of developing a new set of rules... :-)
[11:54] <Laney> He didn't suggest switching but finding a way to share policies...
[11:55] <rbasak> Good point. Sorry.
[12:03]  * mjt is back (was afk for a bit)
[12:04] <mjt> well. I ended up disabling selinux on a few redhat systems I manage exactly because it was constantly staying on the way
[12:05] <mjt> and it required quite some amount of time to get to actually fixing the problem
[12:09] <janimo> seb128, jibel added a proposed debdiff to the bug
[12:09] <janimo> I have just added one that is
[12:34]  * mjt wonders why, after typing `apparmor suse' in google the first suggestion it offers to complete the search term is `disable'...
[12:34] <seb128> janimo, thanks, I will review it in a bit
[12:36] <xnox> mjt: was the completion "disable apparmor" or "disable suse" ?!
[12:36]  * xnox =D
[12:36] <mjt> heh
[12:39] <mjt> in that context i remember a subject in qemu-devel@ recently -- "Discard improvements" by Paolo Bonzini...
[12:39] <mjt> that meant to be improvements for "discard" command (to a virtual disk), not to discard any improvements made so far...
[12:40] <xnox> yeah, I know.
[12:40] <Nafallo> hello o/
[12:41] <Nafallo> I got an archive question :-)
[12:41] <Nafallo> a package seems to have gone AWOL... cjwatson? :-)
[12:42] <Nafallo> and when I say one, I mean two.
[12:44] <xnox> Nafallo: which src package names?
[12:44] <Nafallo> xnox: not sure, but binary package names would be open-vm-tools and open-vm-dkms
[12:46] <Nafallo> I would imagine the source being open-vm-tools
[12:47] <xnox> Nafallo: https://launchpad.net/ubuntu/+source/open-vm-tools/+publishinghistory it's published in multiverse
[12:47] <xnox> Nafallo: do you have multiverse enabled?
[12:47] <Nafallo> yeah, all of the four
[12:47]  * xnox is waiting for rmadison results....
[12:48] <Nafallo> hrm
[12:48] <Nafallo> for some reason I don't have the package lists for multiverse...
[12:49] <Nafallo> *scratches head*
[12:49] <Nafallo> thanks for checking. seems I've got bigger issues.
[12:49] <xnox> Nafallo: it's on disk on mirrors, either you don't have multiverse enabled or the mirror you are using doesn't have multiverse.
[12:50] <Nafallo> yeah, I don't have the lists in /var/lib/apt/lists, so something isn't right on this server. thanks for confirming :-)
[12:51] <Nafallo> xnox: fixed by magic... I blame the squid proxy.
[13:17] <soren> I wonder why the postgresql security update hasn't propagated to updates yet? I thought that usually happened almost immediately (to offload the security mirrors).
[13:18] <jdstrand> soren: hi! I think that was turned off in preparation for the precise point release
[13:18] <soren> jdstrand: Hey :)
[13:19] <soren> jdstrand: Why wouldn't we want security updates to be included in the point release?
[13:19] <jdstrand> soren: we would, but, aiui, the point release was more or less imminent
[13:19] <jdstrand> testing done, etc
[13:19] <soren> Oh, I see.
[13:20] <soren> Oh, well. As long as it's intentional, it's probably all good.
[13:21] <jdstrand> I think that may all get turned back on today
[13:21] <soren> Cool beans.
[13:27] <cjwatson> soren: I turned it off because we were iterating on candidates and I wanted exact control over what changed in each one
[13:33] <jdstrand> mjt: xnox was right. apparmor is easier to use on many levels. selinux is available in Ubuntu as well. We do work with other distros to share apparmor policy, but sharing policy like this (apparmor or selinux) is difficult because of distro nuances
[13:34] <jdstrand> mjt: if you want some more info, I suggest taking a look at: https://wiki.ubuntu.com/AppArmor (which has a bunch of links for more info)
[13:40] <Dedunu> seb128: i fixed it and finally built it
[13:40] <Dedunu> seb128: thank you lot
[13:40] <seb128> Dedunu, great, you're welcome!
[13:48] <Dedunu> seb128: now i pushed my code to my lp
[13:49] <Dedunu> so i should ask for a sponsership nah?
[13:50] <seb128> Dedunu, did you submit a merge request for it?
[13:52] <Dedunu> seb128: nope
[13:52] <Dedunu> how to request a merge
[13:52] <Dedunu> ?
[13:52] <soren> cjwatson: Ok, cool. I just wanted to make sure it wasn't an unknown problem.
[13:52] <Dedunu> seb128: ubuntu wiki makes me confuse im sorry for asking steps
[13:53] <Dedunu> by step
[13:53] <seb128> Dedunu, http://developer.ubuntu.com/packaging/html/udd-sponsorship.html
[13:55] <Dedunu> seb128: how to find a person to review?
[13:55] <cjwatson> You don't, it goes into the sponsoring queue
[13:56] <seb128> Dedunu, what cjwatson said, see http://reqorts.qa.ubuntu.com/reports/sponsoring/
[13:56] <cjwatson> That is, you don't explicitly find a victim, er, reviewer up-front
[13:56] <Dedunu> seb128: k i got it
[13:56] <Dedunu> seb128: cjwatson: thanks guys
[13:56] <seb128> Dedunu, thanks for the work ;-)
[14:14] <Dedunu> seb128: hey! thank you in advance
[14:23] <jamespage> is anyone in channel familiar with the package importer? I have a requirement I think it might fulfill but have not idea really
[14:23] <jamespage> .win 19
[14:23] <jamespage> gah
[14:27] <caribou> cjwatson: I'm working on an issue on Lucid that you fixed last year on debootstrap 1.0.39 (Debian & Ubuntu)
[14:27] <caribou> cjwatson: it's in precise-update but in my case, the issue is on lucid
[14:27] <caribou> cjwatson: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618920
[14:28] <caribou> cjwatson: I just need one confirmation : if it was to be fixed in Lucid, it would make it into lucid-backport which is currently offering 1.0.37, right ?
[14:29] <caribou> cjwatson: no chance of ever seeing it on the .iso ?
[14:29] <xnox> caribou: yes. You should be able to backport 1.0.39 to lucid.
[14:29] <xnox> caribou: there are no more point lucid releases and hence no more iso releases for lucid.
[14:29] <caribou> xnox: my current issue is that preceed installs off a mounted .iso file are hitting this bug
[14:30] <caribou> xnox: ok, this confirms what I wanted to know
[14:30] <xnox> caribou: net-inst / pxe-boot on the other hand should be able to pick it up (i think)
[14:30] <xnox> not sure if we have preseed option to use backports, we do have presseed options to use -proposed / -updates.
[14:31] <xnox> or you can point to your own archive with just that debootstrap deb.
[14:32] <caribou> xnox: ok, that's what I needed to know
[14:33] <caribou> xnox: thanks
[14:35] <cjwatson> netboot installs pick up udebs from -updates by default, and there's an option to use -proposed for the purpose of validation
[14:35] <xnox> ack.
[14:37] <Dedunu> seb128: if you didn't help me i will not do that
[14:45] <sconklin> @pilot out
[14:45] <caribou> xnox: cjwatson: I see a preseed option for -backport as well, but I suppose that it doesn't apply to udebs
[14:46] <cjwatson> It does not
[14:47] <cjwatson> I wouldn't recommend using backports for this anyway; surely it is a bug fix not a feature backport
[14:47] <caribou> cjwatson: indeed, but that specific fix is in 1.0.39 and 1.0.37 is already in lucid-backport
[14:48] <cjwatson> Yeah but that was for the addition of newer series
[14:48] <cjwatson> Ignore it
[14:49] <cjwatson> Even if we added udeb backport support I wouldn't expect to spend any time backporting *that* to lucid :)
[14:50] <caribou> cjwatson: so what would be the preferred solution : cherrypick this specific patch over 1.0.20ubuntu1.4 which is in lucid-updates ?
[14:50] <cjwatson> The patch should be cherry-pickable in an SRU by somebody with time to do that
[14:50] <cjwatson> Yes
[14:50] <caribou> cjwatson: I have time for that, I'll look into it
[14:53] <caribou> cjwatson: then I'll subscribe the SRU & sponsor for a victim, er sponsor :)
[14:54] <doko> tkamppeter, hplip ping
[14:56] <tkamppeter> doko, hi
[14:57] <doko> tkamppeter, do you know if upstream is preparing a move to python in hplip?
[14:57] <doko> barry, ^^^
[14:59] <tkamppeter> doko, they have used Python all the time, do you mean a switchover to Python 3?
[14:59] <doko> tkamppeter, well, yes ...
[15:00] <doko> tkamppeter, I know that python3-reportlab isn't yet there, but it looks to me this is only used conditionally for pdf and fax
[15:01] <tkamppeter> doko, I could report a bug on HPLIP upstream telling that Python2 is deprecated and they need to switch to Python3.
[15:03] <tkamppeter> doko, pure printing and scanning is even done in C, so for mobile devices one could even install only this core part of HPLIP. Python is only used for admin and GUI stuff.
[15:04] <jdstrand> @pilot in
[15:04] <barry> tkamppeter: +1 for py3.  is there any way to subscribe me to an upstream bug tracker?  i'd be willing to help out
[15:05] <barry> tkamppeter: also, did you see my email about system-config-printer?
[15:06] <tkamppeter> barry, HPLIP uses Launchpad for upstream, so you can upstreamize any Ubuntu HPLIP bug by adding an HPLIP upstream task and you can directly report HPLIP upstream bugs via http://launchpad.net/hplip/ and naturally subscribe to all these.
[15:06] <barry> tkamppeter: perfect, thanks
[15:07] <tkamppeter> barry, there was something about the automatic firmware file download mechanism, was it you who mailed me about that?\
[15:07] <barry> tkamppeter: not me.  i was emailing about s-c-p and py3
[15:09] <tkamppeter> barry, there was no effort about passing it over yet, volunteers welcome, and otherwise postpone this WI in the Blueprint.
[15:09] <barry> tkamppeter: thanks!
[15:10] <tkamppeter> barry, will you report the Py2-is-deprecated-use-Py3 bug to HPLIP upstream?
[15:11] <barry> tkamppeter: doing that right now :)
[15:11] <barry> tkamppeter: do you want me to subscribe you to the bug?
[15:11] <hallyn> pitti: bug 1103022 updated
[15:13] <hallyn> jamespage: ^ that finally shows exactly what is going on (with that part of the bug, ignoring the inotify bug :)
[15:13] <barry> tkamppeter: bug 1124208
[15:14] <xnox> tkamppeter: auto-firmware download somthing like ubuntu-drivers-common ?! highlighting pitti ?!
[15:15] <pitti> hallyn: thanks
[15:15] <pitti> xnox: u-d-common doesn't download anything by itself; it's an API for mapping hardware to apt packages
[15:15] <pitti> (and CLI tools)
[15:16] <hallyn> pitti: do you by any chance know how you can tell if a acl_get_file() result is real or representing regular perms?
[15:17] <xnox> pitti: ah so hplip still will need .debs (in restricted?!) with correct mod-aliases.
[15:17] <xnox> pitti: hmm... I was thinking to use mod-aliases to correctly install mdadm for intel matrix raid instead of dmraid.
[15:17] <pitti> hallyn: no, I've never used libacl; that might be the difference between ACL_TYPE_DEFAULT and ACL_TYPE_ACCESS?
[15:18] <hallyn> pitti: I'm not sure - I *thought* default meant "a default acl", not the regular file perms, but I'm not sure
[15:18] <hallyn> pitti: well, I guess there is *one* way -
[15:19] <hallyn> it's tediuous, but we could check whether acl group == file group owner, and acl perms == file group perms, and if so drop it from the acl...
[15:19] <pitti> xnox: if the printer can be expressed in terms of modaliases, that's the best way; if not, one can write some code to do the detection
[15:19] <hallyn> but that's probably deemed nto right
[15:22] <tkamppeter> barry, thank you very much.
[15:24]  * xnox reboots to test some plymouth
[15:24] <smoser> @pilot in
[15:32] <tkamppeter> xnox, pitti, I am seeing now that I have once switched HPLIP to its own firmware auto-install mechanism but returned to the Ubuntu mechanism due to a bug. I will retry using HPLIP's mechanism so that we can do away with the hack in update-manager (or whereever it was).
[16:02] <Tatuus> Howdy how! Not sure if this is the right place to suggest this, but could it be possible to have an added function to Firefox bookmarks? Kind of which, when i press certain letter on the keyboard, the selection jumps to the start of according alphabetical part on the list? This is in on Windows version of FF already.
[16:03] <smoser> seb128, around ? i'm looking at https://launchpad.net/bugs/1110379
[16:04] <smoser> and wondering if you think lack of LICENSE file in a tarball necessitates .dsfg.orig.tar.gz
[16:09] <dupondje> Sweetshark: there ?
[16:13] <dobey> Tatuus: i think you need to talk to firefox developers about that
[16:14] <Tatuus> Where can i reach Linux FF developers in irc the best ?
[16:14] <dobey> i don't know. i'm sure a quick search on your favorite search engine will tell you though
[16:15] <cjwatson> I'd have thought they'd prefer enhancement requests in bugzilla
[16:15] <dobey> but i'm sure they'll also just tell you to file a bug :)
[16:15] <dobey> right
[16:16] <Tatuus> Well i'll try =) this is "sort of" bug as this function is on the Win version
[16:17] <cjwatson> bugzilla has an "enhancement" severity
[16:17] <cjwatson> per https://bugzilla.mozilla.org/page.cgi?id=fields.html
[16:19] <Tatuus> k thnx
[16:36] <Aristide> Hi !
[16:36] <Aristide> Its possible to test Ubuntu mobile ?
[16:38] <ogra_> Aristide, if you mean ubuntu phone OS, yes, once it is released by end of the month
[16:39] <Aristide> Ok :)
[16:39] <Aristide> ogra_: Its possible to install Ubuntu phone OS on Samsung galaxy Note ?
[16:40] <ogra_> i think the image that will be released will only run on the galaxy nexus first ...
[16:41] <Aristide> Ok
[16:46] <ogra_> LO
[16:46] <ogra_> L
[16:47] <ogra_> i haven an ssh -X session running to my nexus7
[16:47] <ogra_> running dconf-editor from my desktop through it ... and having maliit installed
[16:47] <ogra_> clicking inot a text field actually fires up maliit on my desktop now
[16:48] <seb128> smoser, hey, I had that discussion with ogra_ and cjwatson recently, if the license is included in /usr/share/common-licenses you can do without the license text in the tarball
[16:48] <ogra_> *into
[16:48] <smoser> seb128, thanks. then i'll review that a bit further and maybe upload.
[16:48] <xnox> slangasek: so current mdadm hooks try to display more than 127 characters of text messages, which plymouth doesn't want to print.
[16:48] <ogra_> your debian/changelog needs to point to the license on disk though
[16:49] <seb128> smoser, that would be great, thanks
[16:49] <cjwatson> ogra_: debian/copyright
[16:49] <xnox> slangasek: is it possible to send plymouthd an escape sequence to show bootup messages? e.g. does "display-message" works after "hide-splash" ?
[16:49] <ogra_> err
[16:49] <ogra_> what cjwatson said, sorry
[16:51] <Laney> hmm
[16:52] <Laney> Quintasan_: Did you manage to get non-dbus-activated maliit to work? i.e. via input method selection
[16:52] <Laney> I get the option but the keyboard doesn't appear
[16:52] <Laney> err. wait. I didn't install a keyboard.
[16:52] <Laney> That might help.
[16:55] <Laney> hmm, no, it doesn't help
[16:57] <Laney> seb128: are the retracers ok?
[16:57] <seb128> Laney, let me check, I've s suspicion that the amd64 one is down, I meant to look at it earlier and didn't get to it yet
[16:59] <seb128> Laney, shrug, down for 1.5 weeks
[16:59] <Laney> ha
[16:59] <Laney> moar monitoring
[17:00] <seb128> Laney, well, the idea is that those retracers are going away in profit of the ones from errors.ubuntu.com
[17:01] <seb128> but I don't know if the e.u.c are dealing with launchpad timeout issues, etc any better than the old ones atm
[17:01] <Laney> mmm, but as long as apport wants to keep filing bugs
[17:01] <seb128> Laney, I removed the lock, let's see if that works
[17:01] <Laney> ok
[17:01] <Laney> thanks
[17:01] <seb128> the previous retracing errored-out on a launchpad timeout
[17:02] <seb128> Laney, ev and mpt lobby for disabling apport for good I think, I've been fighting back until we get a way through e.u.c to request for extra infos from the next submitter
[17:02] <seb128> otherwise we are stucked with reports but no content and no way to ask for details
[17:03] <seb128> no content -> no description
[17:03] <seb128> I still think it would be better to have an input field on the submission dialog
[17:03] <seb128> but I think mpt disagrees with that
[17:04] <mpt> seb128, I don't feel strongly either way. I did a design for a comment form, but ev + bdmurray + pitti decided against it.
[17:05] <seb128> mpt, ok, I need to try to convince ev again I guess then ;-)
[17:05] <seb128> I didn't have the feeling that pitti was strongly against in the past
[17:06] <mpt> seb128, as described in the bug report, the replacement way to get more details would be by asking for it to be collected. https://wiki.ubuntu.com/ErrorTracker#extra-info
[17:07] <seb128> mpt, right, that's a plus, I still think the input field would bring value
[17:08] <seb128> mpt, 99% of descriptions are poor or useless but over 1000 reports have 10 descriptions might be enough to see a pattern in what the users were doing
[17:08] <seb128> have->having
[17:08] <Sweetshark> dupondje: pong.
[17:08] <Sweetshark> dupondje: /win 6
[17:10] <doko> barry, are you looking at newt/_snack?
[17:11] <doko> looks like it re-runs the build at install time, and then gets things wrong
[17:37] <slangasek> xnox: sorry, what do you mean by "bootup messages"?
[17:38] <mjt> jdstrand: thank you for (apparmor) references!
[17:41] <xnox> slangasek: something like booting _without_ spash quiet
[17:41] <xnox> such that i can spew loads of messages and they are all visible.
[17:42]  * xnox is thinking to do just a short explanation message  and wait for keystroke with a timeout
[17:42] <xnox> it's better than it currently is, and it's UX friendly to have short message with plymouth instead of paragraphs of scary texts about failed hardware.
[17:46] <jdstrand> mjt: np
[18:03] <GunnarHj> cjwatson: ping?
[18:03] <slangasek> xnox: so 'Esc' will toggle between splash and details
[18:03] <cjwatson> GunnarHj: is it 12.04.2-critical?
[18:03] <GunnarHj> cjwatson: No.
[18:03] <cjwatson> GunnarHj: then not now :-)
[18:03] <slangasek> xnox: but you're asking whether the client can switch the mode?
[18:03]  * cjwatson trying to clean up loose ends
[18:03] <GunnarHj> cjwatson: oK.
[18:03] <cjwatson> GunnarHj: and yes I've seen your localechooser bangla branch, it's on my to-do list ...
[18:03] <xnox> slangasek: yes via plymouth CLI
[18:04] <GunnarHj> cjwatson: Not that. :)
[18:06] <slangasek> xnox: unless you count show-splash/hide-splash, no
[18:08] <xnox> slangasek: ok. i have something to test for now.
[18:09] <seb128> janimo, still around?
[18:09] <seb128> janimo, I guess you didn't use the packaging Vcs for your gnome-settings-daemon uploads? Or you did but forgot to push?
[18:10] <ogra_> seb128, i dont thik he uploaded the latest fix
[18:10] <seb128> ogra_, I'm speaking of the 4 previous revisions
[18:10] <ogra_> (for the memory hole)
[18:10] <ogra_> oh
[18:10] <seb128> ogra_, I was trying to merge the fix in :p
[18:10] <seb128> ogra_, but the vcs is 4 revisions behind
[18:11] <ogra_> well, the old prob that we all dont read Bzr-Vcs
[18:11] <ogra_> since UDD is around
[18:11] <seb128> ogra_, between that and the obvious bug I'm going to get grumpy and ask that people go through merge requests in the futur :p
[18:12] <ogra_> it shouldnt happen more than once per uploader though ...
[18:12] <ogra_> at least i remember it now for desktop packages ... and i did the same mistake in the beginning
[18:13]  * seb128 downloads each version from launchpad and commit manually...
[18:13] <seb128> ogra_, yeah, I curse UDD regularly for those :p
[18:13] <ogra_> i apt-get source my stuff usually ... plain oldschool ...
[18:14] <ogra_> and only for desktop packages i add an extra commit
[18:14] <ogra_> (and for some native foundations packages)
[18:15] <dobey> barry: do you have privilges to upload pyflakes to debian?
[18:17]  * xnox has access to UDD. I should start fixing packages
[18:17] <xnox> dobey: I do ;-)
[18:17] <xnox> or are you after flakey
[18:17] <happyaron> debfx: Hi, I wonder is there any update/plan for LP #1101867? It's a bit annoying without the guest module, :)
[18:17] <dobey> xnox: no, pyflakes. there's a new version that would be very nice to get in (and into raring)
[18:17] <xnox> dobey: ok. let me upload that into experimental & sync.
[18:18]  * xnox waits for raid VM to install anyway
[18:18] <dobey> xnox: 0.6.1 is the version. fixes a few important issues.
[18:19] <dobey> xnox: and thanks! btw, did you find any other motherboards? mine is nice, i just wish the ivybridge kernel driver was fixed
[18:20] <xnox> dobey: right so somebody else commented on my blogpost with a very nice gigabyte suggestion. It beats intel motherboard by having displayport/hdmi/dvi-d/vga as well as a second raid chip. Such that I can write installer support for Intel Matrix and Marvell RAID.
[18:21] <xnox> i think i will go for that one.
[18:21]  * xnox is picking an Intel CPU with AES instruction set at the moment
[18:21] <xnox> and then I should be ready to max out my credit card again /o\
[18:22] <dobey> ah. yeah, the important thing for me to have was 2 DVI ports, as that's the only thing my monitors support
[18:23] <xnox> dobey: well i have dvi-d & vga on my monitors. But I'm open to have DP & hdmi for the future =)
[18:24] <dobey> xnox: right. vga doesn't work well for 2048x1152 on an lcd though :)
[18:24] <xnox> show off =)
[18:26] <penguin42> dobey: One of the 23" Samsung's ?
[18:26] <dobey> penguin42: yeah, two of them :)
[18:26] <penguin42> nice, don't seem to be able to get them anymore; everything is 1920
[18:27] <dobey> penguin42: yeah, they don't make them any more, but you can occasionally find used or refurb models. i want to upgrade, but philips hasn't released the panel i want to consumer production models yet
[18:28] <penguin42> why what spec is it?
[18:29] <dobey> 3840x2160 21 inch
[18:29] <penguin42> hoho oooh
[18:30] <dobey> and probably won't use as much power or weigh as much as the ibm t22s. those things are just ridiculous
[18:30] <stgraber> stgraber@castiana:~/Desktop/netcfg/netcfg-1.68ubuntu17$ xrandr | grep "*"
[18:30] <stgraber>    2560x1080      60.0*+
[18:30] <stgraber> I like having dual-1280x1024 on a single monitor ;)
[18:31] <stgraber> (can get two VMs at 1280x1024 side to side with the Unity decorations without cutting any of it. The display also supports splitting the the area in two, showing an input in the first half and another input in the other)
[18:34] <lifeless> dobey: you have ibm t22s?
[18:34] <dobey> lifeless: no. they're too heavy and power hungry
[18:34] <lifeless> dobey: I was going to say :)
[18:34] <dobey> lifeless: i have samsung 2343bwx
[18:34] <dobey> i do have an old sgi 1600sw sitting in the box though
[18:35] <dobey> that was a really nice monitor
[18:35] <dobey> i need to sell it though
[18:35] <lifeless> hmm, I really should find out how big a monitor my work laptop can drive
[18:35] <lifeless> it has dp
[18:36] <dobey> lifeless: is it a thinkpad?
[18:36] <lifeless> dobey: hah! I work at HP now...
[18:36] <dobey> oh right
[18:36] <theadmin> Alright, I'm new at this so bear with me. I'm trying to make a PPA for a small app I have made (just 3 files, actually), but the process of building a Debian package is amazingly confusing. I seem to have gotten debian/control right, and now I can't get the Makefile correctly. I install into $(DESTDIR)/usr/bin (am I doing that right or...?) but when I bzr builddeb, it complains about being unable to create /usr/bin/appname due to insufficient
[18:36] <theadmin>  permissions (doh). What am I missing? Why isn't $(DESTDIR) being set?
[18:36] <dobey> keeping track of who went where is too much work :)
[18:36] <ScottK> theadmin: You will probably have more luck in #ubuntu-packaging.
[18:37] <theadmin> ScottK: Oh, thanks. Geez, there's so many channels
[18:37] <ScottK> You're welcome.
[18:38] <dobey> doh, i forgot to do an mir
[18:38] <lifeless> dobey: it is a 9470m - http://h10010.www1.hp.com/wwpc/us/en/sm/WF06a/321957-321957-64295-5228908-5228906-5271146.html?dnr=1
[18:41] <dobey> lifeless: i'm not sure what the specs for dp 1.1a are. with 1.1 i think the max is maybe 2560x1600 or something near that
[18:42] <dobey> at least, based on the table in the wikipedia article
[18:43] <lifeless> thanks!
[18:43] <barry> doko: i'm looking now
[18:43] <barry> dobey: i don't think so
[18:43] <dobey> barry: xnox replied saying he did. thanks :)
[18:44] <barry> cool.  hopefully i will soon be able to answer 'yes' too ;)
[18:51] <dobey> mterry: hey, can you do a trivial MIR approval for me? :)
[18:51] <mterry> dobey, looking now
[19:00] <dobey> thanks mterry
[19:01] <mterry> yw!
[19:10] <jdstrand> @pilot out
[20:12] <GunnarHj> slangasek: Hi Steve! There is no plan to backport the latest PAM upload to Precise or Quantal, is there?
[20:12] <slangasek> GunnarHj: nope
[20:12] <slangasek> GunnarHj: nothing from the pam side should be needed in precise/quantal, should it?  and if you want to fix the locale bug, changing lightdm is enough
[20:14] <GunnarHj> slangasek: Right. So most of the Precise tasks at bug 952185 are redundant, I suppose.
[20:15] <slangasek> GunnarHj: well, changing the pam configs (without changing pam) would still help with the ecryptfs problem
[20:16] <GunnarHj> slangasek: Yes, but that aspect is limited to lightdm and gdm, isn't it?
[20:16] <slangasek> GunnarHj: possibly, yes
[20:17] <slangasek> GunnarHj: ah, no; atd, ssh, sudo are also all affected because they use 'auth pam_env.so' at the top of the stack
[20:17] <slangasek> (that's why I added those tasks)
[20:18] <GunnarHj> slangasek: But that has not been an issue, has it? Even if it's not the "right" way...
[20:19] <slangasek> GunnarHj: sure it has
[20:19] <slangasek> GunnarHj: the bug may only have been /reported/ for lightdm logins, but the same problem with not parsing .pam_environment on ecryptfs will affect these other services too
[20:20] <GunnarHj> slangasek: You mean that the environment has been something else than intended?
[20:20] <slangasek> sure
[20:20] <slangasek> actually, for atd this is a low-priority issue
[20:21] <slangasek> because atd never prompts for passwords, so never unlocks an ecryptfs mount
[20:21] <slangasek> but sudo, ssh are certainly affected
[20:22] <GunnarHj> slangasek: Maybe I'm stupid, but if the environment is set correctly at login (by changing lightdm), what's the remaining problem for e.g. sudo?
[20:23] <slangasek> GunnarHj: because sudo is meant to set up the environment based on the /target/ user's .pam_environment file, not the source user's
[20:24] <GunnarHj> slangasek: Aha, that clarifies it for me. Thanks! :)
[20:27] <GunnarHj> slangasek: ... OTOH, root does not have any ~/.pam_environment, at least not set via the UI.
[20:30] <slangasek> GunnarHj: sudo is also used for changing between multiple non-root users, not just from non-root to root; but yes, to the extent that this is a problem it's likely to be because of other environment settings besides locale
[20:30] <slangasek> GunnarHj: so I'm perfectly ok with the atd, sudo tasks being closed 'wontfix' for precise
[20:31] <GunnarHj> slangasek: Ok. I'm just trying to avoid (almost) unnecessary work. ;-)
[21:11] <psusi> cjwatson: I've got a production server here where grub upped and stopped recognizing the lvm inside the raid array.. I'm trying to trace through to see why, but grub-probe has no debug symbols when I build it and I can't figure out the make system... where do I need to shove the -g? ;)
[21:12] <cjwatson> The Debian packaging for grub2 uses -g unconditionally
[21:12] <cjwatson> It goes in HOST_CFLaGS
[21:12] <cjwatson> HOST_CFLAGS
[21:12] <psusi> hrm...
[21:13] <psusi> Reading symbols from /home/psusi/grub2/quantal/grub-probe...(no debugging symbols found)...done.
[21:13] <psusi> bzr branch from lp, configure, make
[21:13] <cjwatson> configure/make => not the Debian packaging :)
[21:13] <psusi> ahh
[21:14] <cjwatson> HOST_CFLAGS='-O0 -g -Wall -Wno-error=unused-result' ./configure --with-platform=pc && make
[21:14] <cjwatson> should do it
[21:16] <psusi> yea, this is very odd.. it was runing 12.04, and that grub just says lvm signature not found when it probes the array... 12.10's actually appears to print out a bunch of invalid garbage in the -vv output when it discovers the array
[21:17] <cjwatson> Might be the gettext bug
[21:17] <cjwatson> I should backport that fix
[21:18] <cjwatson> psusi: You might try http://paste.ubuntu.com/1646455/
[21:18] <cjwatson> If it's that, then it won't necessarily reproduce cleanly in grub-probe (unfortunately)
[21:18] <cjwatson> Though 12.10 should have a superset of that fix
[21:20] <matlock> so, I'd like to build ubuntu with the kernel found in android
[21:20] <ikonia> matlock: what did I JUST tell you in #ubuntu
[21:20] <ikonia> matlock: that this channel is NOT a support channel for the android kernel
[21:21] <ikonia> matlock: less than 20 seconds ago I told you that
[21:21] <matlock> tell #android that
[21:21] <matlock> this is an ubuntu issue
[21:21] <matlock> not #android
[21:21] <ikonia> this is not a support channel
[21:21] <matlock> so what you want me to ask in #ubuntu again?
[21:21] <ikonia> no
[21:22] <matlock> then i shall ask here
[21:22] <ikonia> no idea
[21:22] <ikonia> ubuntu doesn't use the android kernel
[21:22] <ikonia> it's nothing to do with ubuntu and this is not a support channel
[21:22] <matlock> ubuntu for phones does
[21:22] <matlock> then why did they state they do
[21:22] <cjwatson> It's probably simplest to wait until the first Ubuntu phone software release and pick it apart for the necessary bits of userspace support
[21:22] <ikonia> matlock: there is no information on the ubuntu phone, so you don't know that
[21:22] <cjwatson> ikonia: It does
[21:22] <matlock> yes there is
[21:22] <ikonia> cjwatson: has that been announced now ?
[21:22] <cjwatson> Yes
[21:23] <cjwatson> A while back
[21:23] <matlock> galaxy nexus is said to be released with ubuntu this month
[21:23] <ikonia> thank you
[21:23] <ikonia> ????
[21:23] <ikonia> well, try #ubuntu-phone then
[21:23] <ikonia> but this channel isn't a support channel
[21:23] <matlock> omg ty
[21:24] <cjwatson> It's not clear to me that the method of gluing the Android kernel into Ubuntu userspace is exactly a support issue at this point
[21:24] <ikonia> sorry about that, I tried to get him to listen before joining
[21:24] <cjwatson> I think you should leave -devel moderation to us, TBH :)
[21:24] <Quintasan> Laney: I did not try that BUT we are soon going to work on Plasma Active so I will probably have to deal with it sooner or later
[21:24] <psusi> nope, it's got trash in array->name when diskfilter.c:insert_array is called
[21:24] <Quintasan> sorry for no response - uni stuff
[21:24] <cjwatson> It's not always obvious what is and isn't unreasonable to ask here
[21:25] <ikonia> cjwatson: the topic is pretty clear
[21:25] <ikonia> I suggest changing the topic if you want it looser
[21:25] <cjwatson> ikonia: That's sophistry
[21:25] <ikonia> thats what....
[21:25] <cjwatson> ikonia: It's clear if you think that the question was support, which is the exact point at issue
[21:25] <slangasek> well, creating a frankenstein image with an android kernel isn't exactly "app development"
[21:26] <cjwatson> It's legitimate for people to ask how it works; if we get tired of it then we can send them elsewhere
[21:26] <slangasek> nor is it end-user support
[21:26] <ikonia> based on his comments in #ubuntu, it was pretty clear what he wanted
[21:26] <cjwatson> I'm not sure I want to be defended in the aggressive way I saw here
[21:26] <ikonia> what agressive way
[21:26] <cjwatson> The one you used
[21:27] <ikonia> oh you mean the one where you tell someone 5 times that ubuntu-devel isn't the place to ask about how to build an android kernel
[21:27] <ikonia> and he ignores it and still does it
[21:27] <cjwatson> That isn't what he asked here
[21:27] <ikonia> yeah, I guess it's pretty agressive to point out that you've just done the opposite of what you've been told the channel is for
[21:28] <cjwatson> I have no context from #ubuntu, but what I saw was somebody turning up with a reasonable question and you blew their head off.  Please stop it and don't do it again here.
[21:28] <ikonia> building ubuntu with the kernel in android....is running the android kernel in ubuntu, which is what he put in #ubuntu
[21:28] <ikonia> he just worded it slightly different
[21:29] <ikonia> cjwatson: I'm sorry you feel that way
[21:29] <cjwatson> I don't need a non-apology, thanks
[21:29] <ikonia> it wasn't a non-apology
[21:30] <ikonia> please don't try to be sarcastic, I was just being polite and saying sorry
[21:30] <cjwatson> "I'm sorry you feel that way" is a classic non-apology technique, FYI
[21:30] <ikonia> it's just as rude as blowing someones head off
[21:30] <ikonia> oh, so you're telling me that I wasn't apologising
[21:30] <cjwatson> It's the first example in https://en.wikipedia.org/wiki/Non-apology_apology
[21:30] <ikonia> I don't need a wiki page
[21:31] <ikonia> I am sorry my comments made you feel that way
[21:31] <ikonia> is that clearer for you ?
[21:31] <cjwatson> Yes, thanks
[21:33] <marrusl> slangasek, bet you thought I was done asking multi-arch questions.  :)  So... ah... would it be insane to mark alsa-utils and alsa-base multi-arch:foreign?
[21:34] <cjwatson> Those look foreign-able to me ...
[21:34] <slangasek> I concur
[21:34] <slangasek> not that most packages ought to be depending on them
[21:34] <marrusl> cjwatson, slangasek... oh great.  I was trying to determine if they were M-A in debian, and I don't think so yet.
[21:35] <slangasek> but it's not buggy to M-A: foreign them
[21:35] <marrusl> slangasek, well there I agree.  It seems like if you have, let's say, some sort of Chat/IM/AV app.... you don't really have to depend on this.  but others disagree.  ;-)
[21:36] <cjwatson> There are exceptions, but in general we're ahead of Debian on at least M-A: foreign application
[21:36] <cjwatson> Not only due to i386-on-amd64 kind of stuff, but also because of its applicability to cross-building where we've been focusing
[21:36] <slangasek> marrusl: well, depending on alsa-* is contraindicated because *using* alsa interfaces is contraindicated. :)
[21:37] <marrusl> cjwatson, aha, yeah that makes sense.
[21:38] <marrusl> slangasek, aaaand there's that.  But for some reason this particular 3rd party app likes to manipulate alsa directly.  the reasoning for that has never made it's way back to me.
[21:38] <slangasek> yeah, that's not going to work so well when pulseaudio is in the mix
[21:38] <slangasek> but, <shrug>
[21:38] <marrusl> in any case, since it's just a control file change, easier to just make it happen.  I'll file bugs/diffs later.
[21:39] <slangasek> ok
[21:39] <marrusl> yeah, no... I know.  but they feel they know what they're doing.
[21:39] <TheMuso> ...or not worry about it, given an alsa 1.0.26 update is currently in QA testing, and I can queue the change for upload when thats done.
[21:40] <TheMuso> In otIn other words, I've just observed this conversation, and will make the change in the bzr branches now.
[21:41] <slangasek> TheMuso: I guess marrusl may want an SRU to precise as well, but thanks for taking care of raring at least :)
[21:41] <TheMuso> np
[21:42] <marrusl> TheMuso, ROCK!  I need to stop by this channel more often.  :-)
[21:42] <psusi> wow this is weird... grub is finding the raid superblok a second time.. inside the raid array itself
[21:42] <marrusl> and indeed... precise and quantal.  I'll skip the raring patch then and get it going.  thanks again~!
[21:42] <TheMuso> marrusl: You're welcome.
[21:43] <TheMuso> marrusl: Feel free to subscribe me to the qnalta/precise bug, and I'd be happy to take care of things for you.
[21:44] <TheMuso> marrusl: Launchpad nick is themuso.
[21:45] <marrusl> TheMuso, righto.  I'll find it.  that's great.
[21:47] <slangasek> smoser: bug #1124384> mounted-tmp is expected to run synchronously after /tmp is mounted and before the 'filesystem' event is emitted
[21:47] <slangasek> smoser: indeed, I'm working with xnox on what amounts to a converse bug, caused by mounted-tmp taking too long to run and holding things up in mountall
[21:47] <smoser> slangasek, it seems unreliably indeterminable
[21:48] <smoser> wait. what?
[21:48] <smoser> my file created after 'filesystems' event is definitely getting wiped
[21:48] <slangasek> well, that would definitely be a bug
[21:49] <slangasek> and I'm saying there's evidence that seems to contradict the possibility of this bug existing in mountall
[21:49] <slangasek> I guess some logs would help?
[21:49] <slangasek> probably logs of a boot using --verbose
[21:49] <slangasek> to see the ordering of all events (including the start/stop events for mounted-tmp)
[21:54] <smoser> slacker_nl, what about something like this
[21:54] <smoser> sorry slacker_nl
[21:54] <smoser> slangasek,
[21:54] <smoser> http://paste.ubuntu.com/1646616/
[22:00] <smoser> find /tmp '!' -newermm /proc/1
[22:00] <smoser> something to that effect seems like it might work
[22:00] <slangasek> smoser: well, I think that's a workaround for whatever's actually going wrong
[22:00] <slangasek> (and thus it may not be reliable at all)
[22:00] <smoser> no its not.
[22:00] <slangasek> yes, it is
[22:01] <smoser> well, if you're saying thats supposed to block everything
[22:01] <slangasek> because mounted-tmp should *never* be doing what you describe
[22:01] <slangasek> yes, it is supposed to, and everything I've seen elsewhere shows that it is doing so
[22:01] <smoser> slangasek, ok. so what debug do you want here ?
[22:01] <slangasek> and if it's *not*, then we'll have big problems elsewhere
[22:02] <smoser> --debug to mountall ?
[22:02] <slangasek> smoser: upstart logs booted with --verbose
[22:02] <smoser> and --verbose to init ?
[22:02] <slangasek> smoser: the mountall --debug is probably not necessary, but if you want to grab them both at the same time sure
[22:05] <slangasek> smoser: separately, storing such files at fixed locations under /tmp is contraindicated for security reasons; you could probably sidestep this issue by using /run...
[22:06] <psusi> cjwatson: wow... for some reason I had an older md 1.0 superblock at the end of the partition in addition to the correct 1.2 at the start, and grub found the old one first, then when it looked inside the old raid array, saw the new superblock at the start so it tried to stack a new raid array on top of the old raid array and in the processes, came up with a totally corrupt array name
[22:06] <smoser> slangasek, "such files" ?
[22:06] <smoser> ah. yeah. its a test.
[22:06] <slangasek> smoser: /any/ file
[22:06]  * psusi wonders why mdadm wasn't confused by this
[22:10] <infinity> psusi: mdadm looks for 1.2, 1.1, and 1.0 in that order, and breaks on the first one it finds.  So, it would likely explode in the inverse situation (an old 1.2 superblock and a new 1.0 one)
[22:11] <infinity> psusi: The proper answer being "you should never have conflicting superblocks".
[22:13] <smoser> slangasek, http://paste.ubuntu.com/1646687/
[22:14] <smoser> you're interested in the final boot
[22:14] <psusi> infinity: ahh... that explains it... yea, I have no idea how that happend too since I made sure to mdadm --zero-superblock the old one before creating the new
[22:15] <slangasek> smoser: "final boot"? this log has more than one?
[22:15] <psusi> probably a good idea to check all 3 and report an error if more than one is found...
[22:15] <smoser> there is are boot there at line 359
[22:16] <slangasek> smoser: I see references to mounted-tmp from lines 178 to 207 and nothing after
[22:16] <smoser> right. which is very odd.
[22:16] <smoser> but its hard to disagree that a boot occurred in the middle
[22:17] <smoser> :)
[22:18] <slangasek> smoser: this seems to be plymouth-mediated log output, yes?  Can I get the output from upstart as logged to /var/log/dmesg?
[22:19] <smoser> http://paste.ubuntu.com/1646707/
[22:19] <slangasek> hmm, the plymouth disconnect also happens much earlier than it has any right to
[22:20] <smoser> well, it ate a bug lunch of data that was supposed to go to /dev/console, so it took an early nap.
[22:21] <slangasek> smoser: ok.  mounted-tmp is from lines 438 to 467, the filesystem event is line 1251.  So I don't think mountall is your culprit.
[22:21] <smoser> yehah, i noticed that too.
[22:21] <smoser> but i' not completely convinced.
[22:22] <cjwatson> infinity: It's certainly possible that GRUB searches in a different order, though, which I think I would consider a bug
[22:22] <smoser> slangasek, ok. i'll poke more later.
[22:22] <cjwatson> Same way I don't think GRUB should be stricter than (say) parted or Linux about partition tables
[22:22] <slangasek> smoser: well, if the actual failing symptom reproduced on this boot, there's no way it could be due to mounted-tmp, which absolutely finished running before the filesystem event was emitted
[22:23] <smoser> slangasek, would you come in to poke around?
[22:23] <slangasek> smoser: sure - where to?
[22:23] <smoser> ubuntu@ec2-54-234-173-208.compute-1.amazonaws.com
[22:24] <smoser> slangasek, ok. so user-data provided to that instance ends up in '/var/lib/cloud/instance/scripts/runcmd' being written by cloud-config.conf and then being executed.
[22:25] <smoser> to reproduce a semi fresh-boot
[22:25] <slangasek> smoser: ok.  where do I look to see the failure?
[22:25] <smoser> sudo rm -Rf /var/log/cloud-init* /var/lib/cloud
[22:25] <smoser> and reboot
[22:25] <smoser> you *should* have a /tmp/done file
[22:25] <smoser> (i had one once)
[22:26] <smoser> i dont have an easy way for you to change the user-data that is going in
[22:26] <smoser> so 'touch /tmp/done' is all you're going to get.
[22:26] <smoser> :)
[22:26] <slangasek> heh, ack
[22:27] <smoser> unless you patch cloud-init locally there to read that and modify the string
[22:27] <smoser> but i'm out now.
[22:27] <smoser> just /sbin/poweroff when you're done
[22:27] <slangasek> ok, cheers
[22:33] <infinity> cjwatson: Sure, it may well be a bug for GRUB to do things differently, but I think the behaviour with conflicting superblocks is largely undefined anyway.  mdadm with no arguments searches in the way I said, I *think* (I'd have to double-check the code), but usually it's not run without arguments, it knows in advance what to look for, GRUB can't.  And it's always wrong to have multiple conflicting superblocks.
[22:34] <xnox> ikonia: to be honest we want to welcome any kernel/android involvement. the current linux-nexus7 kernel in the archive is an android kernel, although targetting nexus7. If users are more on a technical side of things redirect them to #ubuntu-arm where a mixed friendly support/development happens.
[22:34] <xnox> ikonia: for user-centric enquiries to #ubuntu-phone.
[22:35] <xnox> ikonia: if they end up here =) we have plently of "moderators" here. and typically if someone doesn't listen to one person, there is a slight chance for different people to tell them off ;-)
[22:36]  * xnox and my mate at work used to call-up each other as "higher authority" when customers were getting pissed off with us. Little did they know both of us were actually the same rank within that establishment.
[22:36] <slangasek> smoser: fwiw I've just ruled out mounted-tmp for sure; I edited /etc/init/cloud-config.conf to touch another file under /tmp, and *that* file appears but /tmp/done does not
[22:36] <cjwatson> infinity: Yeah.  It's just troublesome because if something is working in practice then a boot loader is a bad place to find out that it's technically broken.
[22:37] <xnox> infinity: well 0.9,1.1 are in the beginning, 1.0 is at the end, 1.2 is 4k from the beginning. So potentially one can have 3 conflicting superblocks if one tries very hard =)
[22:38] <xnox> and nested mdadm raid levels to confuse things further.
[23:02] <hrw> new version of linux-meta-chromebook and chromium-mali-opengles sent to NEW queue