=== jamesh__ is now known as jamesh
[01:51] <alazare619> alazare619> hey whats the format for a repository to be included in the chroot phase of livecd-rootfs
[01:51] <alazare619> <alazare619> let me pastebin the setup i have
[01:51] <alazare619> <alazare619> http://pastebin.com/RwRN9VQV
[01:52] <TheMuso> alazare619: You should use the ubuntu-defaults-builder package if you want to add another archive like a PPA.
[01:52] <alazare619> ive been told this many times
[01:52] <alazare619> im not trying to build gtk etc
[01:52] <alazare619> im building a ubuntu base from scratch
=== jalcine is now known as Jacky
[03:21] <pitti> Good morning
=== cpg is now known as cpg|away
=== jsgotangco is now known as greeneggsnospam
=== cpg|away is now known as cpg
=== zyga-afk is now known as zyga
=== tkamppeter_ is now known as tkamppeter
=== Quintasan_ is now known as Quintasan
=== MacSlow is now known as MacSlow|lunch
=== cpg is now known as cpg|away
=== _salem is now known as salem_
=== apachelogger___ is now known as apachelogger____
=== apachelogger____ is now known as apachelogger___
=== MacSlow|lunch is now known as MacSlow
[13:31] <ev> mpt: in case you wanted a closer look at those lines: http://10.20.66.185/
[14:12] <oly> hi, after a few pointers with packaging python software, i have successfully built a deb but one thing that concerns me is where its going to install to
[14:12] <oly> looking in rules and control files there does not seem to be any where i have setup a path
[14:13] <oly> does that mean all files would install to root ie /
[14:13] <oly> currently i have /project/sourcecode and /project/debian with the packaging files
[14:14] <directhex> the convention is that packages use --prefix=/usr, and debhelper sets various parameters to set this. i don't know about python packaging specifically though
[14:14] <tumbleweed> python modules get installed into the python dist-packages directory
[14:14] <tumbleweed> if tehy aren't there, they aren't importable
[14:14] <oly> well the path i need to install to is /usr/lib/rhythmbox/plugins/
[14:15] <tumbleweed> aah, then tell it to do that
[14:15] <tumbleweed> dh_auto_install -- --install-lib /usr/lib/rhythmbox/plugins/ (or something like that)
[14:15] <cjwatson> To answer the general question, once you've built the .deb you can use 'dpkg -c foo.deb' to see its filesystem tree
[14:16] <oly> okay i will look into dh_auto_install been following guides but could not find any that explained how you handle installing files to different locations
[14:16] <ogra_> or dpkg -L foo if the package is installed already
[14:16] <oly> okay, yeah i have not installed it on the basis i have no idea where the files would be going :)
[14:17] <tumbleweed> even easier, just run "debc" in the build directory, after building
[14:17] <ogra_> use dpkg -c foo.deb then, as cjwatson suggested
[14:18] <tumbleweed> ogra_: as to what I was suggesting with dh_auto_install, that's an override, so:
[14:18] <tumbleweed> override_dh_auto_install:
[14:19] <tumbleweed>         dh_auto_install -- --install-lib .......
[14:21] <oly> okay cheers for the info given me some thing to look into :)
[14:21] <tumbleweed> under the hood, it's just passing that as an argument to setup.py install
[15:20] <mterry> shadeslayer, uploaded opencv fix and threw over to Debian for ya.  Thanks!
[15:24] <mterry> shadeslayer, I did edit the patch slightly.  You dropped the (>= 3.9.4) requirement on libtiff-dev.  I figured that ought to still be there
[15:26] <ScottK> mterry: libtiff-dev is a virtual package, so versions are meaningless.
[15:28] <mterry> ScottK, oh hmm.  touche.  shadeslayer, sorry for doubting you.  :)
[15:44] <Riddell> mdeslaur: this says requires openmotif http://www.citrix.com/English/ss/downloads/details.asp?downloadId=2323812&productId=1689163
[15:44] <mdeslaur> Riddell: yeah, just saw that...thanks
[16:02] <tumbleweed> stgraber: ta (verifying my SRUs)
[16:04] <stgraber> tumbleweed: np, that was an easy one ;)
[16:13] <oly> got another pacakging query any one know what these messages are telling me and how i can fix them :)
[16:13] <oly> dh_prep: No compatibility level specified in debian/compat
[16:13] <oly> dh_prep: This package will soon FTBFS; time to fix it!
[16:13] <oly> the debian/compat is in particular confusing as i have the file with value 7 in it
[16:14] <cjwatson> You must have it in the wrong place, or it must have some other stuff in it as well, or something
[16:15] <cjwatson> cat -et debian/compat
[16:15] <oly> that return 7$
[16:15] <oly> not sure where the $ came from
[16:15] <cjwatson> That's from cat -e
[16:15] <cjwatson> man cat
[16:15] <cjwatson> So you must have the file in the wrong place, I guess
[16:16] <oly> lol, not sure how as all my other packaging files are in the same place ie in ./debian
[16:16] <oly> if it was the wrong place i would expect nothing to work :)
[16:17] <oly> will dig a bit further :)
[16:17] <oly> whats this one telling me This package will soon FTBFS; time to fix it
[16:17] <oly> no idea what FTBFS stands for
[16:17] <ogra_> failed to build from source
[16:17] <oly> guessing its deprecation style notice and i should be using something else
[16:18] <oly> aha thats usefull to know thanks :)
[16:18] <ogra_> (or failing or fails ... not sure about the exact grammar here)
[16:19] <oly> at least that gives me some clues :)
[16:21] <oly> not that it helps me figure out what i will need fix, but googling that may give better results
[16:22] <cjwatson> If you want further help you probably need to put the whole source package somewhere that somebody else can look at it
[16:23] <oly> okay one sec i have it on launchpad
[16:31] <cjwatson> oly: Sure, I could look at a package / build log / etc. on Launchpad
[16:32] <oly> yeah jsut need to setup this machine so i can upload to launchpad again, i formatted it recently :p
[16:46] <oly> lol silly me trying to upload the code outlined the issue obviously i have to commit the files before packaging picks them up :)
[16:52] <SpamapS> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: SpamapS
[16:53] <SpamapS> hallyn: https://code.launchpad.net/~serge-hallyn/ubuntu/quantal/pulseaudio/pa-upstart/+merge/112650 .. hey can you fix the spelling mistakes in the changelog?
[16:53] <ogra_> hmm, since when did we stop adding users to the dialout group ?
[16:54]  * ogra_ just noticed that he cant use an usb to serial adapter on a fresh precise install
[16:55] <hallyn> SpamapS: you accuse me of spelling errors?  no scotch for you!
[16:55] <hallyn> lemme check
[16:55] <SpamapS> mmmm scotch
[16:56] <SpamapS> hallyn: how would you feel about completely deprecating /etc/default/pulseaudio as part of this switch?
[16:57] <hallyn> SpamapS: i don't particularly care :)  how do we properly do this without upsetting users?
[16:57] <hallyn> SpamapS: setting ":set spell" in vim, how do I correctly spell SpamapS?  :)
[16:57] <SpamapS> hallyn: if we replace the file with a comment that says "# This file is deprecated please edit /etc/init/pulseaudio.conf directly" then they'll get prompted for the config file merge
[16:58] <SpamapS> hallyn: "superamazingdude"
[16:58] <hallyn> they'll only get prompted if they had made changes then?
[16:58] <hallyn> (cause i hate HATE prompts)
[17:01] <hallyn> SpamapS: updated and pushed (but not yet tested)
[17:03] <SpamapS> hallyn: you've got conflicts ;)
[17:03] <hallyn> feh, how come bzr push didn't tell me that
[17:04] <SpamapS> +	[ -r /etc/default/pulseaudio ] && . /etc/default/pulseaudio
[17:04] <stgraber> slangasek: I'm taking a look at the sysvinit merge as one of the bugfixes is on the list for 12.04.1. Let me know if you already had some of it done somewhere.
[17:04] <SpamapS> hallyn: because you pushed to your branch, not to the target
[17:04] <SpamapS> hallyn: so now that you've deprecated /etc/default/pulseaudio, you should remove that line
[17:04] <slangasek> stgraber: I haven't started on it, but please be very careful about reviewing the Debian changes... *particularly* the ones with my name on them
[17:05] <slangasek> stgraber: because there are some changes in there regarding upstart compat in Debian that are not ready to go in, as-is, for Ubuntu
[17:05] <hallyn> SpamapS: yup, merging and fixing
[17:05] <hallyn> (bzr ci helps too)
[17:05] <SpamapS> slangasek: so, does it make sense to use /run even if you're not expecting something to start in early boot, or should things just continue using /var/run indefinitely if they never expect to be early boot (like pulseaudio)
[17:06] <stgraber> slangasek: yeah, looking at the delta we had and the amount of changes in Debian since the last release I'm starting to wonder if I really want to spend all that time on the merge and shouldn't instead just cherry-pick the bit I need (the /run/shm fix) ;)
[17:06] <hallyn> stgraber: i do apologize for dumping that merge on you.  but ^ that's why I fjeered to do it myself :)
[17:09] <hallyn> stgraber: d'oh, luke merged the upstart change.  canceling that merge request
[17:09] <slangasek> SpamapS: I would go by whatever we put in debian-policy about this.  In terms of technical implementation, /run and /var/run are equally fine for quantal, and one is a symlink to the other /anyway/, but if this needs to be in Debian too, a pre-dep is still needed until after the wheezy release; the FHS itself hasn't been updated to obsolete /var/run
[17:10] <slangasek> SpamapS: so my own position is to not do any work to move things to /run unless they're early-boot
[17:11] <hallyn> SpamapS: too bad i can't just 'cancel' the request without deleting it - there is valuable info in there
[17:14] <SpamapS> slangasek: so with PA being converted to an upstart job.. its not so much "doing work" as "making a choice"
[17:14] <SpamapS> hallyn: ok so the item is merged?
[17:15] <hallyn> SpamapS: yeah, though without the changes you'd recommended
[17:15] <SpamapS> hallyn: well good we can now optimize ;)
[17:15] <stgraber> hallyn: diffing the postinsts, looks like that's the bit we want right? http://paste.ubuntu.com/1102118/
[17:15] <SpamapS> hallyn: its one of those death-by-1000-papercuts things.. but I am on board now with fully deprecating all /etc/default files used in upstart jobs
[17:16] <SpamapS> hallyn: and in this case its a nice win because the pre-start will just spawn one /bin/sh, see the env var, and stop/exit
[17:16] <SpamapS> for 90% of systems anyway
[17:17] <SpamapS> actually...
[17:17] <slangasek> SpamapS: converted to an upstart job> howso?
[17:17] <SpamapS> I wonder if we shouldn't promote a different thing entirely in this case
[17:17] <hallyn> SpamapS: othe rchanges you'd suggested too, like not startong on starting udev
[17:17] <SpamapS> why are we using an env var?
[17:17] <hallyn> SpamapS: what are the implications of not using env?
[17:17] <slangasek> SpamapS: are we changing how we're starting pa?  We've always started it per-user
[17:17] <SpamapS> hallyn: realistically.. we should just have the start on commented out, and a comment in there '# Uncomment this line to enable system mode'
[17:18] <SpamapS> slangasek: the init.d script was for the off case
[17:18] <SpamapS> or rather
[17:18] <SpamapS> system case
[17:18] <hallyn> stgraber: (looking, trying to remember)
[17:18] <SpamapS> slangasek: it still defaults to not starting
[17:18] <slangasek> SpamapS: right, ok
[17:18] <SpamapS> but.. I'm looking at it and realizing it really shouldn't have a start on
[17:18] <slangasek> SpamapS: so I would use /var/run, but I also don't think it's a big deal either way in that case
[17:18] <stgraber> hallyn: that matches the git commit by slangasek and covers my understanding of the problem, though I'm not sure if we need more than just that bit
[17:18] <SpamapS> slangasek: agreed
[17:18] <slangasek> it's not like we're going to try to push a pa upstart job to Debian before wheezy
[17:19] <SpamapS> yeah, and we're also not going to backport this to pre-oneiric
[17:19] <hallyn> stgraber: I"m not sure,
[17:19] <hallyn> stgraber: long as we're cherrypicking, https://bugs.launchpad.net/launchpad/+bug/974584/comments/21
[17:19] <ubottu> Launchpad bug 974584 in sysvinit (Ubuntu Quantal) "Semaphores cannot be created in lxc container" [High,Triaged]
[17:21] <hallyn> stgraber: they're not *quite* the same...  iow slangasek's suggestion would have been ' ! mountpoint /dev/shm', not /dev
[17:21] <SpamapS> hallyn: so.. to wrap this up. I would remove the PULSEAUDIO_SYSTEM_START env var, and just replace that with a commented out start on
[17:21] <hallyn> SpamapS: and still replace mkdir/chown/chmod with install :)
[17:21] <hallyn> and fix the commented-out start on, and remove the .default
[17:22] <SpamapS> hallyn: right
[17:22] <SpamapS> hallyn: any idea whats with the post-start stuff?
[17:22] <SpamapS> that seems like things that PA should be doing on its own
[17:24] <hallyn> SpamapS: agreed, though i do recall the sysvinit script did it too.  yes we coudl just patch the daemon to do it
[17:24] <SpamapS> hallyn: just seems like thats the wrong place to do it
[17:24] <SpamapS> hallyn: anyway, I'll move on from this item.. bump me when you have an update and I'll take a gander
=== jdstrand_ is now known as jdstrand
[17:26] <hallyn> sigh
[17:30] <hallyn> SpamapS: yeah I don't see any existing code for setting ownership of the the cookies.  Perhaps someone should push that upstream (configurable), but that won't likely be me
[17:31] <SpamapS> hallyn: yeah just leave it
[17:31] <SpamapS> hallyn: seems like the "system mode" of PA is a corner case anyway
[17:34] <stgraber> hallyn: my diff was against what's in Debian which doesn't match what's in git. What's in git looks better: http://paste.ubuntu.com/1102146/
[17:35] <stgraber> hallyn: and I agree that the mountpoint check should only be against /dev/shm as slangasek suggested
[17:36] <hallyn> stgraber: great.
[17:36] <stgraber> hallyn: pushing http://paste.ubuntu.com/1102150/ to a PPA for quantal and precise, will do some tests before I'm confident uploading that :)
[17:48] <seb128>  @SRU team: is there any motivated member who wants to review the unity precise SRU just uploaded? we would like to get it early rather than late to keep open the possibility to do another SRU round for the 12.04.1 desktop freeze
[17:48] <seb128>  
[17:48] <seb128> some notes
[17:48] <seb128>  - the list of bugs fixed in that SRU is quite long
[17:48] <seb128>  - some of the bugs are not fully SRU-rules-compliant yet, but the vast majority is, the #ps guys are working on finishing testcases etc for the remaining ones
[17:48] <seb128>  (I don't think we should block the SRU on that)
[17:48] <seb128>  - the update got quite some solid testing already, some people are running it for a week and it went through several round of checkbox manual test and automatic testing
[17:48] <seb128>  with some issues found and fixed during the week
[17:48] <seb128>  
[17:48] <seb128>  to do it short: it's going to be a bit tricky to review but it got solid automated and manual testing and we are confident it should create no issue
[17:48] <seb128>  ;-)
[17:49] <seb128> SpamapS, bdmurray, ScottK, slangasek, infinity: ^
[17:50]  * ScottK is about to leave for his daughter's art show, so no.
[17:50] <seb128> ScottK, thanks for replying anyway, enjoy the show ;-)
[17:51] <slangasek> seb128: I have a train ride this evening which should be good for some SRU reviewing... but AIUI mdadm is still blocking on me so that's my first priority
[17:51] <SpamapS> seb128: I'm on patch pilot today, and slangasek won't be able to do his normal SRU shift today I think. So I think you're down to bdmurray and infinity. ;)
[17:52] <bdmurray> infinity: said he'd take slangasek's shift
[17:52] <seb128> well I tried my chance anyway, I was expecting it would be hard to get review today ;-)
[17:52] <SpamapS> seb128: I can look at the bugs w/o docs and see if they're worth waving through tho
[17:52] <bdmurray> I may have some time in my afternoon
[17:52] <seb128> slangasek, maybe the week of ppa, checkbox, automatic testing, jenkins etc gives you enough confidence to have an half an hour look in the train to spot anything stupid and if you don't wave it in? ;-)
[17:53] <infinity> I'll be doing some of vorlon's SRUy bits today, yeah.  But if he wants unity, it's all his. :P
[17:53] <seb128> well anyway I wanted to give some context
[17:54] <seb128> it will get it when it gets in
[17:54] <slangasek> seb128: maybe... it's mostly a question of whether I have enough half hours ;)
[17:54] <seb128> thanks guys ;-)
=== cpg|away is now known as cpg
[19:43] <shadeslayer> mterry: thanks for the upload
[19:50] <shadeslayer> small problem though, it's in dep wait, apparently it can't find libtiff-dev
[19:52] <shadeslayer> well ... I think maybe because you versioned it ...
[19:56] <shadeslayer> yep
[20:02] <stgraber> hallyn, slangasek: so, while testing the fix for bug 974584 I found an even more common bug (that was likely thought to be 974584). Complete fix now looks like: http://paste.ubuntu.com/1102362/
[20:02] <ubottu> Launchpad bug 974584 in sysvinit (Ubuntu Quantal) "Semaphores cannot be created in lxc container" [High,Triaged] https://launchpad.net/bugs/974584
[20:03] <stgraber> I tested it in lxc and it seems to do the right thing here and I believe I guarded it even that it shouldn't affect any other scenario, but I'd really like to have you two take a look at it :)
[20:03] <hallyn> stgraber: looking
[20:04] <shadeslayer> so, could someone re-fix opencv ? ( Drop the versioning for libtiff-dev )
[20:04] <stgraber> slangasek: basically, we have a workaround in lxc to make /dev/shm a symlink to /run/shm but it only works when /run/shm exist, which stopped being true late in the 12.04 cycle, so quite a lot of containers are still broken...
[20:05] <stgraber> slangasek: that code I added detects these cases and fixes them before the rest of the code is executed. Without that bit, any initscripts update (or even reinstall) will fail in lxc (as apparmor will block the bind-mount)
[20:06] <stgraber> hallyn: it looks like the "mountpoint -d" is magic enough to work at detecting bind-mounts, but if you know of a better way of detecting these, I'm happy to change the check
[20:06] <hallyn> stgraber: no apart from picking through /proc/self/mountinfo - mountpoint -d is better
[20:06] <hallyn> stgraber: but, can th emv work right if something is actively using the devshm?
[20:10] <stgraber> hallyn: I expect some problems around that actually but I can't think of a better way to deal with it to be honnest... as long as all processes using a given shm entry have it open, it won't be a problem. I guess it'd probably become a problem if something else tries to open it before from the new location while some others still read it from the old/non-existing location.
[20:15] <hallyn> stgraber: if anything caches the inodes #, i s waht i was thinking
[20:18] <stgraber> hallyn: it also depends whether they are currently using /run/shm or /dev/shm, I'm trying to check that part now
[20:20] <hallyn> stgraber: i supposeit *might* be safer to do something like "mv /dev/shm /dev/shm.bak; rsync -va /dev/shm.bak/ /run/shm/; compat_link /run/shm /dev/shm"
[20:22] <stgraber> hallyn: the only difference I see with that approach is that you can still "see" the files, but the result for something using the shm entry should be identical
[20:22] <stgraber> as anything that has an open fd will still be able to read/write and anything that doesn't won't know to look in /dev/shm.bak so will access the copy in /run/shm
[20:24] <hallyn> stgraber: yup
[20:24] <hallyn> but note if you don't do that, if something has a /dev/shm/xyz file open, your mv may fail, making upgrade fail (non-reproducibly)
[20:25] <hallyn> i don't know if that's a real concern or not, just bringing it up
[20:25] <jderose> hello, i'm hoping to find someone able to review/sponsor this couchdb 1.2.0 package - https://bugs.launchpad.net/ubuntu/+source/couchdb/+bug/1022515
[20:25] <ubottu> Launchpad bug 1022515 in couchdb (Ubuntu) "Please sync (sort of) couchdb 1.2.0-1 from Debian unstable" [Undecided,Confirmed]
[20:26] <stgraber> hallyn: why would mv fail if a file is open? I thought only Windows did that :)
[20:26] <hallyn> stgraber: bc mv accross devices will 'cp; rm' right?
[20:27] <stgraber> right, but you can rm a file that's still open
[20:27] <hallyn> maybe it won't fail, maybe just the inode will be kept open.  true
[20:27] <hallyn> stgraber: yeah nm.  go with what you've got :)
[20:28] <stgraber> still doing one more test to see whether when both /dev/shm and /run/shm exist, entries are created in /run or /dev by default, to see how bad it's going to be on upgrade ;)
[20:30] <mhall119> jderose: my usual go-to guys are all in Europe and gone for the weekend already :(
[20:31] <jderose> mhall119: now prob, thank you :)
[20:31] <jderose> mhall119: so when is the deadline for this sort of change without an exception?
[20:32] <mhall119> lets check the schedule
[20:32] <mhall119> Feature Freeze is the week of Aug. 23rd
[20:33] <jderose> okay, good to know, thanks
[20:33] <mhall119> np
=== yofel_ is now known as yofel
[20:38] <george_e> Who do I need to talk to to get access to this page: https://chinstrap.canonical.com/~racarr/unity-web-api-docs/unity-web-api-reference.html
[20:38] <george_e> Apparently I don't have permission to access it.
[20:41] <stgraber> george_e: chinstreap is Canonical-only IIRC, if it's meant to be public, racarr should move it to lillypilly (people.canonical.com) that's publicly accessible
[20:41] <ScottK> george_e: First you have to get hired by Canonical.
[20:41] <george_e> Oh... okay. Is there a copy of the documentation somewhere else that I can read?
[20:44] <tumbleweed> google turns up http://developer.ubuntu.com/api/ubuntu-12.04/javascript/index.html
[20:48] <george_e> tumbleweed: Ah, thanks.
[20:49] <stgraber> the exact same page is actually: http://developer.ubuntu.com/api/ubuntu-12.04/javascript/unity-web-api-reference.html
[20:49] <stgraber> but he's gone, so I guess he found the link :)
[20:49]  * tumbleweed didn't stop to read it, but it looked unity-web-api ish
[20:49] <tumbleweed> :)
[20:52] <stgraber> hallyn, slangasek: did a bunch more tests and can't find anything obviously wrong with that change. Will push to quantal now so I can properly test debootstrap and will also push to precise-proposed. If anything else comes to mind, please shout and I'll fix.
[20:53] <stgraber> will test in quantal with debootstrap as soon as it's published and do a precise => quantal container upgrade, these are the last checks I can't easily do with the PPA
[20:53] <hallyn> stgraber: great, thanks
=== cpg is now known as cpg|away
[21:27] <SpamapS> hallyn: one more nit-pick..  pre-start is only one line, so it can be 'pre-start exec install ...'
[21:38] <hallyn> i didn't know you could od that
[21:45] <hallyn> SpamapS: pushed
[21:47] <SpamapS> hallyn: yeah, the less script's, the less forks, the less microseconds wasted ;)
[21:47] <hallyn> i'd like to see my boot time below 7 secs, so +1
[21:47] <SpamapS> actually no.. no fork saved.. but one exec saved
[21:48] <SpamapS> hallyn: you also have the issue with lightdm needing to slow down right?
[21:48] <hallyn> SpamapS: not any more.  whatever suggestion you had made worked for me
[21:49] <hallyn> SpamapS: i'm playing with vde2.  getting ready to push on its MIR.  especially since vdeqemu no longer ships with vde2.  (could be wrong, thought you'd been interested in the past)
=== salem_ is now known as _salem
[22:03] <SpamapS> hallyn: uploading now (finally)
[22:10] <hallyn> SpamapS: \o/
[23:20] <SpamapS> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== cpg|away is now known as cpg