[00:04] <cjwatson> alazare619_: You're missing an "install" or "live" as the first argument to add_package.
[00:04] <cjwatson> alazare619_: See my explanation above.
[00:05] <cjwatson> The rest looks OK.
[00:07] <alazare619_> so live add_package install then the rest?
[00:10] <alazare619_> ok im running a test
[00:10] <alazare619_> but i know its going to fail eventually
[00:10] <cjwatson> Just "add_package install", not "live add_package install"
[00:10] <alazare619_> yea thats what i figured
[00:10] <alazare619_> refrenced xubuntu's setup
[00:10] <cjwatson> Like the way it's "add_task install ..." just above
[00:11] <alazare619_> yea
[00:11] <alazare619_> now how can i pass a extra repository over with the auto?
[00:13] <cjwatson> Write a file to config/archives/<some name>.chroot.list, and also to config/archives/<some name>.binary.list if you want it in the running live environment as well as during the build
[00:13] <cjwatson> sources.list format
[00:15] <phoenix_firebrd> the package was successfully built thank you JontheEchidna  and micahg
[00:17] <micahg> phoenix_firebrd: if it works unchanged, you can request an official backport with requestbackport
[00:18] <phoenix_firebrd> micahg: i changed the dependencies
[00:18] <phoenix_firebrd> micahg: i am new to ppa, just learning and testing
[00:18] <micahg> phoenix_firebrd: ah, it's part of the KDE release, I thought it was just a leaf app
[00:19] <phoenix_firebrd> micahg: ya
[00:42] <alazare619_> is there a way cjwatson  to add that to the auto script?
[00:42] <alazare619_> for config
[00:44] <cjwatson> alazare619_: Sure, just use echo or cat - there's at least one example in the existing script I think
[00:44]  * cjwatson -> bed
[00:51] <alazare619_> ok i was thinking an end of script style but just basic shell works?
[01:03] <alazare619_> hey cjwatson building fails with livecd-rootfs
[01:03] <alazare619_> when i use precise
[01:03] <alazare619_> it fails at
[01:03] <alazare619_> P: Begin installing syslinux...
[01:03] <alazare619_> cp: cannot stat `/usr/share/syslinux/themes/ubuntu-oneiric/isolinux-live/*': No such file or directory
[01:04] <alazare619_> syslinux doesnt even install there
[01:19] <alazare619_> cjwatson, you around these parts still?
[01:20] <alazare619_> guess not
[02:51] <alazare619> http://pastebin.com/1LrKbNuP
[02:51] <alazare619> live build seems to fail with livecd-rootfs
[02:51] <alazare619> at a line saying initrid is not in gzip when its set to lzma mode
[04:53] <alazare619> im using the newest live-build and its not creating binary/isolinux
[08:28] <cjwatson> alazare619: install syslinux-themes-ubuntu-oneiric
[08:36] <cjwatson> alazare619: that's a bug in live-build when you use both --initramfs-compression lzma and --binary-images iso/iso-hybrid/usb; I suggest you just drop --initramfs-compression lzma for now, as the extra space saving probably isn't critical for you
[08:36] <cjwatson> definitely something we should fix though
[11:25] <bashed> How does ubuntu recommend you the name of the uninstalled package that you are trying to run a binary off?
[11:26] <penguin42> bashed: It's the command-not-found package
[11:27] <penguin42> bashed: There is a bit of magic at the end of /etc/bash.bashrc that seems to glue it in
[11:27] <bashed> penguin42: Thanks a lot, thats what I needed to know.
[13:14] <alazare619> hey cjwatson ok well i dropped the initramfs compression lzma and im still having an issue with failure to lzcat
[13:16] <alazare619> cjwatson, i change compression to none should it just be empty instead?
[13:27] <hippiehacker> alazare619: what commands are you issuing to create the image? are you starting with an empty directory?
[13:29] <hippiehacker> https://answers.launchpad.net/ubuntu/+source/live-build/+question/200206
[13:30] <hippiehacker> particularly the bit about https://gist.github.com/2978542 where I quickfix the compression in initrd. But I was still unable to get it to work
[13:45] <cjwatson> alazare619: Just don't pass that option at all.
[14:07] <hippiehacker> cjwatson: could you take a look at https://answers.launchpad.net/ubuntu/+source/live-build/+question/200206 ... I've tried using the bzr branches you mentioned, but http://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/view/head:/debian/changelog has errors when I try to run dpkg-buildpackage against it
[14:18] <cjwatson> hippiehacker: I wouldn't expect dpkg-buildpackage to work
[14:19] <cjwatson> We just run it straight from the bzr branch
[14:19] <cjwatson> Afraid I don't have time for anything more detailed right now ...
[14:19] <hippiehacker> cjwatson: no prob
[14:20] <hippiehacker> I was just not sure what to do with the repos and guessed
[16:47] <alazare619> cjwatson, u around?
[22:44] <infinity> bdrung: Dangit, you're going to make me upgrade all my development machines to quantal now? :P
[22:44] <infinity> bdrung: (Or I back out that devscripts change locally...)
[22:46] <slangasek> yerp
[22:50]  * infinity also notes that he entirely missed that bug being assigned to him.
[22:50] <infinity> My bugmail filters might need twiddling.
[22:50] <infinity> slangasek: How was the trip home?
[22:50] <slangasek> infinity: it's quite nice
[22:51] <slangasek> Internet at 30,000 feet is the only way to travel
[22:51] <infinity> Well, aren't we fancy?
[22:51] <infinity> I travel over land so infrequently that I don't get to do such things often.
[22:51] <slangasek> welcome to the future :)
[22:51]  * slangasek nods
[22:54] <cjwatson> phew, the jenkins desktop tests this morning seem to have come through unscathed
[22:54]  * cjwatson utters a cautious and muted yay
[22:57] <infinity> Well, that's firefox and thunderbird fixed on armel.  That seems like enough work for a Saturday.
[23:02] <penguin42> what was up with them?
[23:02] <tumbleweed> infinity: was it rolled into the new upstream firefox releases that appeared minutes later?
[23:03] <infinity> penguin42: Generating armv7 code for an armv5 target.
[23:03] <Laney> that old chestnut
[23:03] <penguin42> infinity: What in?
[23:03] <infinity> tumbleweed: Hrm?
[23:03] <tumbleweed> https://launchpad.net/ubuntu/+source/firefox/14.0.1+build1-0ubuntu1
[23:03] <infinity> penguin42: skia.
[23:03] <infinity> tumbleweed: Oh, bah.
[23:04] <infinity> tumbleweed: So, uhm.  No. :P
[23:04] <tumbleweed> so, fixed for 5 minutes :)
[23:04]  * penguin42 assumes my ARMv7 specific patch has been removed from the ubuntu libc
[23:04]  * infinity fixes that, and pokes chrisccoulson
[23:04] <infinity> penguin42: ?
[23:05] <penguin42> infinity: I had an optimised one of the string routines (can't remember which) that landed in the ubuntu packages before being upstreamed
[23:05] <penguin42> infinity: It wasn't ARMv5 safe at the time it went into the ubuntu package, but was by the time it went upstream
[23:06] <infinity> penguin42: Oh, I fixed that, yeah.
[23:06] <chrisccoulson> huh?
[23:07] <infinity> penguin42: :
[23:07] <infinity>   * arm/local-linaro-cortex-strings.diff: instead of sysdeps/arm, apply
[23:07] <infinity>     to sysdeps/arm/eabi/armv6t2, as it implements routines that aren't
[23:07] <infinity>     supported on old CPUs, and drop memchr.S half of the patch, in
[23:07] <infinity>     favour of the version that's been submitted and accepted upstream.
[23:07] <infinity>   * Make the strchr.S implementation above stop forcing armv7-a, since
[23:07] <infinity>     it works on armv6t2, and moving the path enforces this during build.
[23:07] <infinity> chrisccoulson: Oh, we just collided.  I uploaded armel fixes for tbird/ffox minutes before you uploaded a new upstream. ;)
[23:08] <penguin42> infinity: Ah good
[23:09] <penguin42> infinity: I don't envy the job of getting stuff to work on v5 again  - you're going to end up tripping over Qt, and loads of stuff
[23:09] <infinity> penguin42: Most of it's reasonably happy right now.
[23:10] <infinity> penguin42: Though, to be fair, I haven't done any runtime tests on v5 hardware or full-archive instruction scans to see what breakage is leaking through unnoticed.
[23:10] <infinity> One step at a time, though.
[23:10] <chrisccoulson> seriously? i need to review those. in addition to that, they need to be in bzr (and committed first to the nightly branch, else i have a serious headache keeping track of which of the 24 packaging branches we have for firefox and thunderbird that particular fixes are in)
[23:10] <chrisccoulson> especially this week, when we're in the middle of rebasing all of the branches for the next 6 week release cycle
[23:10] <chrisccoulson> well, we -> I
[23:10] <infinity> chrisccoulson: Do I have commit access to these mystical branches?
[23:11] <infinity> chrisccoulson: Or do you just want to review and apply my two ubuntu1->ubuntu2 diffs and go from there?
[23:11] <infinity> chrisccoulson: (I'm happy to reupload them right now, and you can do with them as you please after that)
[23:12] <infinity> chrisccoulson: Both are appropriate for backporting all the way to lucid, so no patches/series magic mangling required.
[23:13] <chrisccoulson> infinity, they need to go to lp:firefox first (assuming they're not already fixed in mozilla-central), and then i can cherry pick patches to older branches (such as the one that quantal is based off) if they're needed
[23:13] <infinity> chrisccoulson: lp:firefox doesn't seem to contain tbird, unless I'm blind.
[23:14] <chrisccoulson> this week, lp:firefox/aurora will be rebased on lp:firefox, lp:firefox/beta will be rebased on lp:firefox/aurora and then lp:firefox/beta will be uploaded to quantal
[23:14]  * infinity assumes there's an lp:thunderbird, and checks.
[23:14] <chrisccoulson> so anything committed inbetween is likely to get lost along the way ;)
[23:14] <chrisccoulson> infinity, yeah, there is a lp:thunderbird
[23:14] <infinity> chrisccoulson: Alright, and the origs that match those are in the PPA?
[23:15] <infinity> Hrm, or not.
[23:16] <infinity> Or, rather, not in the daily ppa...
[23:16] <infinity> chrisccoulson: Where do I find the orig to match these bzr debian directories?
[23:16] <chrisccoulson> infinity, you can use that branch with the tarballs in the daily PPA if you just update the version number in the changelog
[23:17] <infinity> Oh, I guess the firefox one is close to matching anyway, just not the tbird one.
[23:17] <infinity> But making sure my patches still apply against 16ish is handy, I guess.
[23:18] <infinity> For the record, your workflow is pretty contribution-hostile. :P
[23:19] <chrisccoulson> my workflow is more aligned with the upstream release process
[23:19] <chrisccoulson> and complicated by the fact that there are 24 packaging branches to juggle fixes between ;)
[23:28] <chrisccoulson> infinity, so, https://bugzilla.mozilla.org/show_bug.cgi?id=751814 is already fixed upstream in what will be the next upload to quantal
[23:28] <infinity> chrisccoulson: Mmkay.  I'd still like to fix it now in the 14 version, unless the new upstream is "right nowish".
[23:28]  * Debolaz gets all giddy every time he looks at the plans for wayland.
[23:29] <chrisccoulson> infinity, the first 15.0 beta is next week
[23:30] <infinity> chrisccoulson: The no_neon patch still applies, so I'll commit that to bzr.
[23:31] <chrisccoulson> infinity, what's the upstream bug number for that?
[23:31] <infinity> Haven't filed one yet, since that "fix" is clearly wrong for upstream.
[23:31] <infinity> Just right for us.
[23:31] <chrisccoulson> hmmm, i don't like the sound of that at all
[23:32] <infinity> *sigh*
[23:32] <infinity> We don't enable NEON by default, ever.
[23:32] <infinity> Upstream has a test for it.  Which is also wrong.  It should be a configure option, like all their other optimisations.
[23:32] <infinity> But, for us, it was simple to just remove the check for it, which DTRT.
[23:33] <chrisccoulson> so, this is effectively going to become a permanent patch?
[23:33] <infinity> No, I'll work with Mike on upstreaming something more suitable.
[23:34] <infinity> Just not Right Now(tm).
[23:35] <chrisccoulson> hmmm, ok. IME, people commit patches, forget about them and then we end up carrying them for years ;)
[23:35] <jtaylor> I don'T know the context but you have neon enabled fftw3 in quantal now though its runtime detected
[23:35] <infinity> Well, if that happens, this isn't exactly an onerous patch to maintain.
[23:35] <infinity> But bug me about it if I forget and it annoys you.
[23:36] <jtaylor> I guess thats fine?
[23:36] <infinity> jtaylor: runtime detection is lovely.
[23:36] <infinity> jtaylor: compile-time is broken.
[23:36] <infinity> jtaylor: (No different from the situation for, say, SSE on i386)
[23:37] <chrisccoulson> infinity, ok. i'll just add it to the nightly and aurora branches now then, and it will be in the next quantal upload
[23:37] <infinity> chrisccoulson: Oh, I was just about to commit. :P
[23:37] <chrisccoulson> did it need any changes?
[23:37] <chrisccoulson> oh
[23:37] <infinity> chrisccoulson: (After testing it still applied and maybe jiggering for offsets, cause I'm anal)
[23:37] <chrisccoulson> i'm not sure core-dev can commit to that branch. i was going to fix that at some point
[23:37] <infinity> I guess I'll find out. :)
[23:37] <infinity> You could add me to the team that can, though. :P
[23:38] <chrisccoulson> 1 second, daughter number 1 seems to be waking
[23:40] <chrisccoulson> ah, this is going to be a fun night
[23:41] <chrisccoulson> infinity, ok, added ;)
[23:42] <chrisccoulson> infinity, if you just commit to lp:firefox and lp:thunderbird then, i will merge that changeset to lp:firefox/aurora and lp:thunderbird/aurora
[23:42] <chrisccoulson> (unless you want to do that)
[23:42] <infinity> chrisccoulson: Alright, committed to both.  Other than buildd resources (which tends to be my complaint about you, not the inverse), do you have any issues with me also doing an out-of-band upload of 14.x to quantal to fix things right now?
[23:42] <infinity> chrisccoulson: You can do the merging magic to aurora, I assume that workflow's muscle memory for you. :)
[23:44] <chrisccoulson> infinity, in general, i avoid out-of-band uploads with fixes for non-primary architectures for a couple of reasons in addition to buildd resources. the first one is update fatigue, and the second one is that the build triggers a reupload of our breakpad symbols to mozilla's server
[23:44] <chrisccoulson> which means we use additional storage on their server
[23:45] <alazare619> cjwatson, you around
[23:45] <infinity> chrisccoulson: I assume they have garbage collection of some sort...
[23:45] <infinity> chrisccoulson: (That's a pretty weak argument for keeping things broken)
[23:49] <alazare619> http://pastebin.com/2LLw1PuE
[23:49] <alazare619> im trying to edit the live-build script so it copys the initird and vmlinuz to the name vmlinuz and initrd.lz
[23:50] <alazare619> any idea what i have wrong
[23:50] <alazare619> its returning target is not a directory
[23:51] <chrisccoulson> infinity, well, i don't consider update fatigue to be a weak argument. it's basically a 400MB update for people like me with debug symbols installed, and that's pretty hefty for an update which doesn't fix anything on the architecture i'm using (or any of the primary architectures) ;)
[23:52] <infinity> chrisccoulson: No, I suppose not, but two uploads in rapid succession should mean that most people never see the one in the middle, unless they update every hour.
[23:52]  * infinity shrugs.
[23:53] <chrisccoulson> i don't mind, but i generally try to keep the number of uploads to a minimum :)
[23:53] <infinity> chrisccoulson: To be fair, this *does* fix something on a supported arch as well (armhf also shouldn't have NEON on), if you want to pull the supported/primary card.
[23:53] <chrisccoulson> ah, ok
[23:53] <chrisccoulson> i didn't realize thats
[23:53] <chrisccoulson> **that
[23:53] <chrisccoulson> so, feel free then ;)
[23:54] <alazare619> could anyone refrence the pastebin please and offer some guidance i copied the 3 lines that involve copying from the chroot the init and placing a copy in /binary/casper/
[23:54] <alazare619> but i cant rename that file
[23:56] <infinity> chrisccoulson: Right, uploaded.
[23:56] <alazare619> gives me directory does not exist when doing the mv command
[23:56] <chrisccoulson> thanks